Subject: Re: internal modem bug
To: Don Ray <firstname.lastname@example.org>
From: Jay Nelson <email@example.com>
Date: 03/17/1998 18:33:24
This is just a wag -- but if getty's causing a problem, make sure
(on the modem) that echoing is turned off and verify that &C1, &K3,
&S1 and &D2 (usr) or &D3 (zoom) is set.
I'd be curious to see if that changed anything.
On Tue, 17 Mar 1998, Don Ray wrote:
>Recently I posted to these lists a problem I'm experiencing with lock-ups
>when modem connections are dropped. I have more info now and I'll
>re-describe the scenario:
>NetBSD i386 1.2 or 1.2.1
>All makes/models Pentium systems I can find.
>Internal modem (I've tried USRobotics Sportster (28.8 & 33.6), Zoom
> -any com #n, any irq #n
>Any kernel (ie. GENERICADP)
>After setting up the modem to auto-answer, hardware flow control etc. put a
>getty on it's tty (w/ or w/o rtscts). On another computer, dial into the
>modem and log in (note: just a normal dial-in, no ppp). See that everything
>works just fine. On the local console of the box you've dialed into, start a
>ping to localhost (or anywhere). After a few packets have echoed, exit the
>dial-in connection window from the other computer. Note how the local
>console is now completely un-responsive and the pings are no longer echoing.
>After a few minutes, dial back in. Note how the console unfreezes the moment
>the modem picks up (before negotiation) and your ping packets start echoing
>again -- right where they left off (no long echo-time, no dropped packets!)
>Somehow 100% of the CPU is being hogged by the init process for the internal
>I've ktraced init and it's children and find it going into a sigsuspend on
>the getty and not getting woke-up with a SIGALRM(?) until the modem becomes
>active again. But it's grabbing the whole system as if a NON_BLOCKING open
>However, external modems connected to the serial ports do not exhibit this
>problem. Also, neither internal nor external modems exhibit this under 1.3
>Are ISA modem cards supported in 1.2 and 1.2.1? If upgrading to 1.3 is not
>an option for me, what kernel code would I need to hack to correct this?
>Now that I've defined the problem a bit better, anyone else seen this?
>Any help would be appreciated.
>Don Ray - Service Technologies