Date: Sun, 19 Aug 2007 11:28:26 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@deepcore.dk> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Graham <gbradley@rocketmail.com>, freebsd-geom@FreeBSD.ORG Subject: Re: kern/115572: ata disk bug Message-ID: <46C80D3A.4020507@deepcore.dk> In-Reply-To: <83156.1187508376@critter.freebsd.dk> References: <83156.1187508376@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote:
> In message <200708182120.l7ILKBvF046099@freefall.freebsd.org>, Graham writes:
>
>
>> 2. attempt (say)....
>> rabbit# dd if=/dev/zero of=/dev/ad4s1 oseek=2097151 count=1 bs=64k
>> and the result is....
>> dd: /dev/ad4s1: Input/output error
>> 1+0 records in
>> 0+0 records out
>> 0 bytes transferred in 0.000325 secs (0 bytes/sec)
>>
>> (If dd is performed on the raw drive, /dev/ad4 then block boundary is
>> always a power of 2, and blocksize a smaller power of 2. That's always
>> ok. But we can't assume we use drives that way.)
>>
>> So a transfer which starts in the 28-bit zone, but extends over into
>> the 48-bit region, fails. Such transfers happen in the superblock of
>> certain size drives, and that plays havoc. The sector mapping of gbde
>> can do this, but soft-update gets screwed by this happening. It's not
>> actually to do with the crypto as I first suspected.
>>
>
> This is a problem in the ata disk driver.
>
Yeah, the crossover point from using 28bit to 48bit addressing is
flawed, below patch should fix that:
--- ata-all.c 23 Feb 2007 16:25:08 -0000 1.279
+++ ata-all.c 19 Aug 2007 09:25:58 -0000
@@ -738,7 +738,7 @@
atadev->flags &= ~ATA_D_48BIT_ACTIVE;
- if ((request->u.ata.lba >= ATA_MAX_28BIT_LBA ||
+ if (((request->u.ata.lba + request->u.ata.count) >=
ATA_MAX_28BIT_LBA ||
request->u.ata.count > 256) &&
atadev->param.support.command2 & ATA_SUPPORT_ADDRESS48) {
-Søren
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46C80D3A.4020507>