Cameron Grant wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> > I did that and it still hangs. Let me see if it's for the same reason.
> > Maybe *sc is getting stepped on somehow?
> very odd. i have no idea what is going on.
> i have committed bits, so try again in a few hours.
Okay, I've rebuilt the kernel and rerun the test, again doing remote
debugging. As I thought, the zeroed *sc was a quirk of that debugging
session. The same hang is happening to me as is happening to the other
guy with a hang at 0x600 (sorry, I forgot his name and didn't retain the
email).
Here's the backtrace:
#0 nm_rd (sc=0xc0d83100, regno=1536, size=2)
at ../../dev/sound/pci/neomagic.c:142
#1 0xc0207267 in nm_rdcd (devinfo=0xc0d83100, regno=0)
at ../../dev/sound/pci/neomagic.c:232
#2 0xc020293e in ac97_init (codec=0xc0d83000)
at ../../dev/sound/pcm/ac97.c:251
#3 0xc0202b16 in ac97mix_init (m=0xc073d30c) at ../../dev/sound/pcm/ac97.c:304
#4 0xc0205854 in mixer_init (d=0xc073d200, m=0xc0288c40, devinfo=0xc0d83000)
at ../../dev/sound/pcm/mixer.c:53
#5 0xc0207b4b in nm_pci_attach (dev=0xc0d87280)
at ../../dev/sound/pci/neomagic.c:595
#6 0xc011e1be in DEVICE_ATTACH (dev=0xc0d87280) at device_if.c:63
#7 0xc0148b87 in device_probe_and_attach (dev=0xc0d87280)
at ../../kern/subr_bus.c:1137
#8 0xc0149876 in bus_generic_attach (dev=0xc0d87480)
at ../../kern/subr_bus.c:1831
#9 0xc011e1be in DEVICE_ATTACH (dev=0xc0d87480) at device_if.c:63
#10 0xc0148b87 in device_probe_and_attach (dev=0xc0d87480)
at ../../kern/subr_bus.c:1137
#11 0xc0149876 in bus_generic_attach (dev=0xc0d87b80)
at ../../kern/subr_bus.c:1831
#12 0xc01cd235 in pcib_attach (dev=0xc0d87b80) at ../../pci/pcisupport.c:747
#13 0xc011e1be in DEVICE_ATTACH (dev=0xc0d87b80) at device_if.c:63
#14 0xc0148b87 in device_probe_and_attach (dev=0xc0d87b80)
at ../../kern/subr_bus.c:1137
#15 0xc0149876 in bus_generic_attach (dev=0xc0d87d80)
at ../../kern/subr_bus.c:1831
#16 0xc011e1be in DEVICE_ATTACH (dev=0xc0d87d80) at device_if.c:63
#17 0xc0148b87 in device_probe_and_attach (dev=0xc0d87d80)
at ../../kern/subr_bus.c:1137
#18 0xc0149876 in bus_generic_attach (dev=0xc0d86000)
at ../../kern/subr_bus.c:1831
#19 0xc011e1be in DEVICE_ATTACH (dev=0xc0d86000) at device_if.c:63
#20 0xc0148b87 in device_probe_and_attach (dev=0xc0d86000)
at ../../kern/subr_bus.c:1137
#21 0xc0149876 in bus_generic_attach (dev=0xc0d86080)
at ../../kern/subr_bus.c:1831
#22 0xc0231579 in nexus_attach (dev=0xc0d86080) at ../../i386/i386/nexus.c:199
#23 0xc011e1be in DEVICE_ATTACH (dev=0xc0d86080) at device_if.c:63
#24 0xc0148b87 in device_probe_and_attach (dev=0xc0d86080)
at ../../kern/subr_bus.c:1137
#25 0xc0149db6 in root_bus_configure () at ../../kern/subr_bus.c:2214
#26 0xc0227e58 in configure (dummy=0x0) at ../../i386/i386/autoconf.c:146
#27 0xc0133118 in mi_startup (framep=0xc0326fb4) at ../../kern/init_main.c:217
(kgdb) print /x regno
$1 = 0x600
The hang is happening on the "movzwl (%ebx,%eax,1),%eax" at nm_rd+80:
(kgdb) s
146 return bus_space_read_2(st, sh, regno);
(kgdb) print $eip
$2 = (void *) 0xc0207054
(kgdb) stepi
0xc0207056 146 return bus_space_read_2(st, sh, regno);
(kgdb) stepi
198 #if defined(_I386_BUS_MEMIO_H_)
(kgdb) print $eip
$3 = (void *) 0xc0207060
That's this instruction:
0xc0207060 <nm_rd+80>: movzwl (%ebx,%eax,1),%eax
(kgdb) print /x $ebx
$5 = 0x600
(kgdb) print /x $eax
$6 = 0xc87d2000
$eax being 0xc87d2000 seems a little odd, but I don't remember my 80x86
assembly well enough to say whether it's right or wrong.
In the meantime, I'll try Nick Sayer's trick.
--
Frank Mayhar [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
