Environment: 2.4.0-test4 kernel, Jailbait 6 distribution, 200MHZ I-Opener IDT Winchip C6 w/ 32MB memory, using UHCI "JE" driver, compiled statically in the kernel, pegasus sometimes compiled in, sometimes modular (no difference). Note, I have 2 I-Openers and 2 Linksys USB adapters and they all behave the same way. The switch is a Netgear SW510 10/100 switch, with the Linksys plugged into one of the 10BaseT plugs. The driver doesn't always work once booted: try to ping a machine in the network, the link light comes on, the activity light does nothing upon ping (when it works, I can see the ping in the activity light). When under load, it eventually stops communicating. This is most easily repeatable running a remote xawtv on a server (that has a tv tuner card) and displaying it on the I-Opener. You'd expect a 10BaseT or USB connection to not keep up with video frames, but, I can do this on other 10BaseT machines on the network and xawtv may fail (very seldom), but the network card continues to function. On the I-Opener, failure occurs rapidly (best case: it once lasted fr 30 minutes), the machine is still alive, but the network is dead (can't ping out or in). Panics occur in the following cases: 1) adapter removal, 2) driver module removal, and 3) resume from system suspend. Given the nature of the panics (the machine locks up tight), I can't perform a ksymoops. All panics are after "ifconfig eth0 down" (same happens with the IF configured up, but you'd expect some of these operations to fail with the interface up). First, yank adapter... a mile of garbage printk's (like shown for the "apm -s" example below, but are gone before I can study them) are followed by a mile of call trace addresses, i.e. something recursive is happening... the kernel call stack gets unnaturally deep. The final message is: > Aiee, killing interrup handler > kernel BUG at sem.c:995 Resume from suspend acts like it's trying to re-instantiate the pegasus driver... Upon "apm -s" (apm is not part of the Jailbait distribution, I added it), followed by resume: >usb.c: USB new device connect, assigned device number 2 > URB ... urbp ... > QH ... > td 0: ... > ...e0 Stalled CRC/Timeo Length=7ff MaxLen =3f DT0 EndPt=1 Dev=2, PID=69(IN) >(buf=... > td 1: > ...e3 SPD Active Length=0 MaxLen=3f DT1 EndPt=1 Dev=2, PID=69(IN) (buf=..."> > td 2: > ...e3 SPD Active Length=0 MaxLen=3f DT0 EndPt=1 Dev=2, PID=69(IN) (buf=..."> > td 3: This pattern repeats through "td 10", followed by: > td 23: ... > ...e3 SPD IOC Active Length=0 MaxLen=3f DT1 EndPt=1 Dev=2, PID=69(IN) >(buf=..."> >eth0: Linksys USB100TX The above pattern repeats for more screens than I can <shift-PGUP> on, but only the last screen concerns the Linksys adapter. Any subsequent ethernet activity, i.e. run "ifconfig" or "ping", causes a panic: > Unable to handle kernel null pointer dereference at virtual address <zero> > ...<call stack> > Aiee, killing interrup handler > Kernel panic: Attempted to kill idle task! > In interrupt handler - not syncing Note that if the pegasus driver is never loaded, "apm -s" followed by resume has no problems (the USB driver prints about two lines of info from hc_reset following resume). When trying to remove the pegasus driver module... >usb.c:deregistering driver pegasus >Unable to handle kernel null pointer dereference at virtual address <non-zero> >...<call stack> >Aiee, killing interrup handler >Kernel panic: Attempted to kill idle task! >In interrupt handler - not syncing What do you think? Chris --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
