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