panic - sleeping thread on FreeBSD 8.0-stable / amd64

Torfinn Ingolfsen torfing at broadpark.no
Fri Feb 26 11:04:10 UTC 2010


On Sat, 20 Feb 2010 15:35:46 -0800
Jeremy Chadwick <freebsd at jdc.parodius.com> wrote:

After five days - a new crash. From /var/log/messages:
Feb 26 00:57:39 kg-f2 ntpd[55453]: kernel time sync status change 6001
Feb 26 01:39:40 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 0000007f
Feb 26 01:39:40 kg-f2 kernel: ata5: hardware reset timeout
Feb 26 10:44:54 kg-f2 syslogd: kernel boot file is /boot/kernel/kernel

> Let's backtrack a bit.  I've gone back and read through all of your
> previous posts on this matter, and so far all the problems are happening
> on ata5 and ata6.  No timeouts or anomalies have appeared on any other
> ports -- just those two. 

It seems you are right.

> The kernel error messages indicate that
> commands submit to the controller took longer than 10 seconds to get a
> response, so the OS does a force-reset of the ports in attempt to get
> things working again.
> 
> We can safely rule out the Silicon Image controller (otherwise "ataX"
> wouldn't be involved), which leaves the AMD SB700 SATA controller and
> the AMD SB700 PATA controller.

And there is nothing connected to the pata controller.

> What exact disks (e.g. adX) are attached to ata5 and ata6?

root at kg-f2# dmesg | grep ata5
ata5: <ATA channel 3> on atapci0
ata5: [ITHREAD]
ad10: 953869MB <SAMSUNG HD103SJ 1AJ100E4> at ata5-master UDMA100 SATA 3Gb/s
root at kg-f2# dmesg | grep ata6
ata6: <ATA channel 4> on atapci0
ata6: [ITHREAD]
ad12: 953869MB <SAMSUNG HD103SJ 1AJ100E4> at ata6-master UDMA100 SATA 3Gb/s

> You haven't provided dmesg output in any of your posts,

No, I didn't. I did state that full dmesg's and more info was available on the freebsd web page[1] for the machine 
in one of my first posts.

> and atacontrol/pciconf is
> not sufficient (I should really improve atacontrol by printing this
> information.  I'll work on that in a few minutes).

Cool, I would really like that feature.

> Some Linux users have reported AHCI-related issues with the SB600
> southbridge, but the core of the problem turned out to be MSI on certain
> AMD northbridges (specifically RS480, RS400, and RS200).  By disabling
> MSI entirely they were able to achieve stability.  The FreeBSD
> equivalent would be to set the following in loader.conf and reboot:
> 
> hw.pci.enable_msix="0"
> hw.pci.enable_msi="0"

I will try that now. It might take five days or more to get an answer.

> The Linux quirk fix for this:
> 
> http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=blob_plain;f=queue-2.6.21/pci-quirks-disable-msi-on-rs400-200-and-rs480.patch;hb=05ab505f2909acf3a614d3e6a32271c4c1f8a69d
> 
> Your board has an AMD 740G northbridge, but it might be worth trying the
> MSI disable trick anyway.  If it doesn't fix the problem then definitely
> re-enable MSI.  Isn't hardware fun?  ;-)

Always. ;^)


References:
1) http://sites.google.com/site/tingox/ga-ma74gm-s2h_freebsd

-- 
Torfinn



More information about the freebsd-stable mailing list