Re: 1-way modem
- From: ibuprofin@xxxxxxxxxxxxxxxxxxxxxx (Moe Trin)
- Date: Fri, 29 Feb 2008 13:35:37 -0600
On Fri, 29 Feb 2008, in the Usenet newsgroup comp.os.linux.hardware, in article
<KRIxj.4659$A93.2571@trndny08>, Time Waster wrote:
Just upgrade from 2.6.9 to 2.6.18 (RHEL4.6 to RHEL 5), and my dialup
is malfunctioning. I can turn ppp debug on, and see that LCP config
requests are being sent, I can snoop the other side and see that
it's sending the LCP ACK's back, but there's no sign of them back
on the original side.
What KIND of modem? External? Internal? Built-in? PCI? USB? ISA? How
is is connected to the computer? What shows up in /var/log/messages
at boot time related to the appropriate serial port? Which serial
driver is being used? Is it appropriate to your unspecified hardware?
Are you using some form of 'connect' option such as '/usr/sbin/chat' to
dial the modem? Set that tool into the debug or verbose mode (for
'/usr/sbin/chat', add the -v option), and look at the resulting logs.
Does the modem respond (more or less) instantly?
Jul 3 09:55:00 gtech chat[925]: send (AT&F1)
Jul 3 09:55:01 gtech chat[925]: expect (OK)
Jul 3 09:55:01 gtech chat[925]: AT&F1
Jul 3 09:55:01 gtech chat[925]: OK
Jul 3 09:55:01 gtech chat[925]: -- got it
or is there a 19 second delay?
Jul 3 09:55:00 gtech chat[925]: send (AT&F1)
Jul 3 09:55:01 gtech chat[925]: expect (OK)
Jul 3 09:55:20 gtech chat[925]: AT&F1
Jul 3 09:55:20 gtech chat[925]: OK
Jul 3 09:55:20 gtech chat[925]: -- got it
The latter is an indication that the interrupts are screwed up - either
the serial port is using a different IRQ from what the kernel expects,
or (in the case of non-PCI hardware) an IRQ sharing problem (ISA and
most built-in serial ports do not tolerate shared interrupts).
I also tried a manual test of using minicom to dialing another box, manually
ATAing from minicom, the connect happens, but only when I type on host-A
does it show up on destination host-B. Not the reverse.
On the upgraded box, is minicom using an appropriate (as defined by the
manufacturer) modem init string? (That usually means something like AT&F0
or AT&F1, and NOT "ATZ" which may just reset the modem to what-ever you
may have saved into NVRAM.) Are the modem commands being echoed back?
Does the echo or the result code occur within a fraction of a second, or
is there a long (up to a half minute) delay? Does your modem have lights
on it, and are they blinking appropriately? (If no lights, there are a
number of applications that can mimic these lights - "modemlights" is
but one example.)
Looking at a working case, I see that stty -a < /dev/ttyS0 (the modem
port) looks the same, and setserial -a /dev/ttyS0 is basically the same
(I tried setting it to auto_irq with no diff). Looking at
/proc/tty/driver/serial during the PPP negotiation seem to only show
transmissions, not receptions.
Fire up minicom. Look at the contents of /proc/interrupts:
7: 969503 + serial
(Here, the modem is configured to use IRQ 7, because other devices are
using the so-called "standard" values of 4 or 3. Note also that the data
is only present when some application is actually USING the interrupt.)
In minicom, press the A, T, and return key - which should send the
Hayes command prefix to the modem. The modem should respond with a
non-error result - the number 0 if non-verbal result codes are selected,
or the letters "OK". Now look again at /proc/interrupts:
7: 969515 + serial
Echoing the command, and then producing the "verbal result" here caused
12 interrupts. What do _you_ see on your system?
Old guy
.
- References:
- 1-way modem
- From: Time Waster
- 1-way modem
- Prev by Date: Re: Linux Printer Driver
- Next by Date: Re: Streaming different audio on multiple sound cards simultaneously
- Previous by thread: Re: 1-way modem
- Index(es):
Relevant Pages
|
