Date: Tue, 09 Jun 2009 09:59:54 +0200 From: Bartosz Stec <admin@kkip.pl> To: Adam K Kirchhoff <adamk@voicenet.com> Cc: freebsd-stable@freebsd.org Subject: Re: Problems with PATA disk Message-ID: <4A2E167A.3000902@kkip.pl> In-Reply-To: <20090608104334.59a4718c@voicenet.com> References: <20090608101837.79c3b7d7@voicenet.com> <20090608104334.59a4718c@voicenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Adam K Kirchhoff wrote:
>> atapci1@pci0:5:3:0: class=0x018000 card=0x3375105a chip=0x3375105a rev=0x020
>> vendor = 'Promise Technology Inc'
>> device = 'PDC20375(??) FastTrak SATA150 TX2plus Controller'
>> class = mass storage
>>
This happens frequently with Promise TX2/TX4 (less frequently in
RELENG-7 than RELENG-6) and issue is probably related to controller
driver.
>
> GEOM_LABEL: Label ufsid/4a296b573007b5f2 removed.
> Jun 8 14:35:42 memory last message repeated 7 times
> ad14: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly
> ad14: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly
> ad14: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly
> ad14: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly
> acd0: WARNING - TEST_UNIT_READY taskqueue timeout - completing request directly
> ad14: WARNING - SET_MULTI taskqueue timeout - completing request directly
> ad15: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly
> ad15: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly
> ad15: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly
> ad15: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly
> ad15: WARNING - SET_MULTI taskqueue timeout - completing request directly
> ad15: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=470440143
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x188
> fault code = supervisor read, page not present
> instruction pointer = 0x20:0xc07d4d94
> stack pointer = 0x28:0xc62f9c00
> frame pointer = 0x28:0xc62f9c18
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 23 (swi6: task queue)
> trap number = 12
> panic: page fault
> cpuid = 0
> Uptime: 1m56s
> Physical memory: 3058 MB
> Dumping 113 MB: 98 82 66 50 34 18 2
> Dump complete
> Automatic reboot in 15 seconds - press a key on the console to abort
> Rebooting...
> cpu_reset: Stopping other CPUs
>
> Unfortunately, nothing showed up in /var/crash, which I think is odd.
> I'll update my -STABLE, rebuild my kernel with debugging, and hope to
> catch something next time.
>
>
In this case controller probably loose whole drive (disconnected and
dissapear from 'atacontrol list'), that's why you see no core dropped,
and powering machine off and on let it recognize the drive again. I have
this issue from time to time with TX4, but fortunately i have 2 disks in
gmirror, so when one drive disconnect I force rebuilding mirro by just
powering machine off and on.
You're using 7.2-stable, so it seems that OS upgrade won't help you
(after upgrade from FreeBSD 6 to 7 issue has been seen 80% less
frequently for me), so my one and only suggestion for you is using
different PATA controller if you can.
--
Bartosz Stec
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A2E167A.3000902>