Matthias;

Strangely, I get these failures whenever I pull the power adaptor out
of my Thinkpad 701C running with a 3C589....

Very strange.

Matthias Drochner writes:
> When I boot a -current kernel on a machine with a 3c509 ISA
> ethernet card and type "halt" at the "boot device:" prompt, a
> message
> ep0: adapter failure (ffff)
> appears and the system hangs (probably in the while loop in
> epstop() - I don't know why the stack trace below doesn't show it).
> 
> This looks a bit like a driver problem, and perhaps there can be
> something improved (that's why cc to Jonathan).
> But the "failure" message comes from the elink3 interrupt routine,
> and as I understand it, there should not be an interrupt at this time.
> boot() calls a splhigh() before the shutdownhooks.
> 
> Here is the stacktrace:
> 
> #0  Debugger () at ../../../../arch/i386/i386/kgdb_interface.c:163
> #1  0xf81b1cee in sget () at ../../../../arch/i386/isa/pccons.c:1551
> #2  0xf81b0b89 in pcintr (arg=0xf86abdc0)
>     at ../../../../arch/i386/isa/pccons.c:636
> #3  0xf8100f2f in ?? ()
> #4  0xf810a941 in epreset (sc=0xf86ac800) at ../../../../dev/ic/elink3.c:1176
> #5  0xf8109fc5 in epintr (arg=0xf86ac800) at ../../../../dev/ic/elink3.c:796
> #6  0xf81015fb in ?? ()
> #7  0xf810ab28 in epshutdown (arg=0xf86ac800)
>     at ../../../../dev/ic/elink3.c:1241
> #8  0xf811cfff in doshutdownhooks () at ../../../../kern/kern_subr.c:263
> #9  0xf818a11f in boot (howto=8, bootstr=0x0)
>     at ../../../../arch/i386/i386/machdep.c:984
> #10 0xf811db5a in parsedisk (str=0xf81deea0 "halt", len=4, defpart=0,
>     nam2blk=0xf81c7d18, devp=0xf81dee9c) at ../../../../kern/kern_subr.c:777
> #11 0xf811dab0 in getdisk (str=0xf81deea0 "halt", len=4, defpart=0,
>     nam2blk=0xf81c7d18, devp=0xf81dee9c) at ../../../../kern/kern_subr.c:743
> #12 0xf811d427 in setroot (bootdv=0x0, bootpartition=0, nam2blk=0xf81c7d18)
>     at ../../../../kern/kern_subr.c:462
> #13 0xf81876f0 in configure () at ../../../../arch/i386/i386/autoconf.c:113
> #14 0xf818973c in cpu_startup () at ../../../../arch/i386/i386/machdep.c:329
> #15 0xf8113fe9 in main (framep=0x0) at ../../../../kern/init_main.c:189
> 
> To track down things further, I placed a breakpoint at Xintr10
> (the 3c509 uses intr 10 in my case) and single-stepped to the point where
> the corresponding bit in cpl is checked:
> 
> 0xf81015c4 in ?? ()
> 1: x/i $eip  0xf81015c4 <Xintr10+56>:   testb  $0x4,0xf81cff35
> (gdb)
> 0xf81015cb in ?? ()
> 1: x/i $eip  0xf81015cb <Xintr10+63>:   jne    0xf8101638 <Xhold10>
> (gdb)
> 0xf81015cd in ?? ()
> 1: x/i $eip  0xf81015cd <Xresume10>:    movl   0xf81cff34,%eax
> (gdb)
> 0xf81015d2 in ?? ()
> 1: x/i $eip  0xf81015d2 <Xresume10+5>:  pushl  %eax
> (gdb) info reg $eax
> eax            0x0      0
> (gdb) print &cpl
> $5 = (int *) 0xf81cff34
> (gdb) print cpl
> $6 = -1
> 
> The CPU obviously reads cpl as 0.
> 
> Who can explain this?
> 
> best regards
> Matthias Drochner