Date: Fri, 26 Feb 2010 11:03:37 +0100 From: Torfinn Ingolfsen <torfing@broadpark.no> To: freebsd-stable@freebsd.org Subject: Re: panic - sleeping thread on FreeBSD 8.0-stable / amd64 Message-ID: <20100226110337.70d1a758.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20100220233546.GA36973@icarus.home.lan> References: <20100131144217.ca08e965.torfinn.ingolfsen@broadpark.no> <20100131175639.86ba9aee.torfinn.ingolfsen@broadpark.no> <20100207163631.da7205fc.torfinn.ingolfsen@broadpark.no> <20100213192404.5e15b5eb.torfinn.ingolfsen@broadpark.no> <20100217091625.d0e74570.torfinn.ingolfsen@broadpark.no> <20100220202108.e1dd1b74.torfinn.ingolfsen@broadpark.no> <20100220193718.GA33214@icarus.home.lan> <20100220224959.c424dd9e.torfinn.ingolfsen@broadpark.no> <20100220233546.GA36973@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 20 Feb 2010 15:35:46 -0800 Jeremy Chadwick <freebsd@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@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100226110337.70d1a758.torfinn.ingolfsen>