Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Feb 2008 18:49:44 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        SXren Schmidt <sos@freebsd.org>
Cc:        cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org
Subject:   Re: cvs commit: src/sys/dev/ata ata-all.h ata-chipset.c ata-dma.c ata-lowlevel.c
Message-ID:  <200802111849.44512.jhb@freebsd.org>
In-Reply-To: <200712131147.lBDBlaFi066300@repoman.freebsd.org>
References:  <200712131147.lBDBlaFi066300@repoman.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 13 December 2007 06:47:36 am SXren Schmidt wrote:
> sos         2007-12-13 11:47:36 UTC
> 
>   FreeBSD src repository
> 
>   Modified files:
>     sys/dev/ata          ata-all.h ata-chipset.c ata-dma.c 
>                          ata-lowlevel.c 
>   Log:
>   Implement a workaround of the datacorruption problem on serverworks HT1000 
chipsets.
>   The HT1000 DMA engine seems to not always like 64K transfers and sometimes 
barfs data all over memory leading to instant chrash and burn.
>   Also fix 48bit adressing issues, apparently newer chips needs 16bit writes 
and not the usual fifo thing.
>   
>   HW donated by: Travis Mikalson at TerraNovaNet

I'm not sure how best to fix it, but it seems that this broke crash dumps on 
the HT1000 chipset:

exit1() at exit1+0x39d
sys_exit() at sys_exit+0xe
ia32_syscall() at ia32_syscall+0x256
Xint0x80_syscall() at Xint0x80_syscall+0x5d
Uptime: 5d0h51m55s
Physical memory: 4084 MB
Dumping 325 MB:ata2: FAILURE - oversized DMA transfer attempt 65536 > 64512
ad4: setting up DMA failed

** DUMP FAILED (ERROR 5) **
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
cpu_reset: Restarting BSP

I'm guessing that the atadev->max_iosize is still set to 64k somehow (DMA 
default) for the ata disk when it does the check in ad_strategy(), but I'm 
not sure how as for the HT1000 chipset at least ch->dma->max_iosize is set to 
63k in the controller allocate routine which should be run before the child 
disk devices are probed and attached AFAICT.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200802111849.44512.jhb>