A few hours ago I downloaded .../i386/ISO-IMAGES/4.9-RC1-i386-disc1.iso and made kern/mfsroot floppies from it. If I enable my ICH5R SATA controller in "native" mode, the 4.9-RC1 GENERIC kernel hangs solidly (only the system reset button can unwedge it) during device configuration. The last line of bootstrap monologue written by the kernel is: plip0" <PLIP network interface> on ppbus0 If I do a "boot -v", the kernel continues with: bpf: lp0 attached ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) cs0: not probed (disabled) sn0: not probed (disabled) isa-probe-children: probing PnP devices before it hangs. If I boot with the ICH5R SATA enabled in legacy mode, the kernel does not hang. It continues from this point with the output: BIOS Geometries: 0: 03fffe4f 0..1023=1024 cylinders, 0..254=255 heads, 1..63=63 sectors 1: ... ... and so forth. The system finishes booting and /stand/sysinstall starts. I would guess that the bug is in the ata controller/disk driver. The 4.9-20030914-PRERELEASE GENERIC kernel also hangs if the ICH5R SATA controller is enabled in native mode, though not at the same point. It wedges when the controller is first probed. Dan Strick strick@covad.net
On Mon, Sep 29, 2003 at 11:01:27PM -0700, Dan Strick wrote:> The 4.9-20030914-PRERELEASE GENERIC kernel also hangs if the ICH5R SATA > controller is enabled in native mode, though not at the same point. > It wedges when the controller is first probed.I'm waiting to hear back from Soeren about the SATA issues, but I suspect we'll have to update the hardware/release notes to specify that legacy mode must be used. I've added this to our known issues list for 4.9. Will be updated on the website within 8 hours : http://www.freebsd.org/releases/4.9R/qa.html http://www.freebsd.org/releases/4.9R/todo.html - Murray -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 155 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20030930/0c675283/attachment.bin
On Mon, 29 Sep 2003, I wrote:>> > A few hours ago I downloaded .../i386/ISO-IMAGES/4.9-RC1-i386-disc1.iso > and made kern/mfsroot floppies from it. If I enable my ICH5R SATA > controller in "native" mode, the 4.9-RC1 GENERIC kernel hangs solidly > (only the system reset button can unwedge it) during device configuration. > The last line of bootstrap monologue written by the kernel is: > > ... >>Then I attempted to find out where in the system startup procedure the kernel was wedging by inserting printf()s in the kernel source and narrowed it down to a point in /sys/i386/i386/autoconf.c, near the end of the function configure(): /* * Now we're ready to handle (pending) interrupts. * XXX this is slightly misplaced. */ spl0(); Apparently one of the interrupt handlers is effectively stuck in an infinite loop at high priority. In retrospect this is not much of a surprise, given the problem symptom. I am not sure how to proceed. The FreeBSD kernel is a little strange to me. Since the kernel wedges so hard, there it no way to interrupt it and force a core dump or take a stack trace. The system reset button wipes out everything. I am not sure that my system can save a useful core dump anyway since I have 1 GB of main memory and only 64 MB of swap space. (This may seem like an odd configuration, but if you consider the current price of main memory and some other things it starts to make sense.) If necessary, I can find some disk space for the dump. I also don't know exactly how to force a core dump or use gdb on the FreeBSD kernel. My past kernel experience was with PDP-11/VAX Unix and SunOS. Is there any documentation or manual pages for such procedures? I can't really find any. (I am aware of the man pages for gdb, ddb, and savecore.) Suggestions would be appreciated. In the mean time, I may try to instrument the kernel interrupt routines. Does printf() work in an interrupt context? If not, is there an alternative? Dan Strick strick@covad.net
Ddb works even though the system seemed solidly wedged! (unexpected) The kernel seems to be spending all of its time fielding ata and uhci interrupts. I don't know what this means... Perhaps I won't be needing a kernel core dump after all, but just in case, how do I cause one from inside ddb? Dan Strick strick@covad.net