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