Date: Fri, 17 Oct 2008 00:15:10 +0100 From: "Steven Hartland" <killing@multiplay.co.uk> To: "Antony Mawer" <fbsd-stable@mawer.org>, "Jeremy Chadwick" <koitsu@FreeBSD.org> Cc: freebsd-stable@freebsd.org, "Andrey V. Elsukov" <bu7cher@yandex.ru>, kib@freebsd.org, sos@freebsd.org Subject: Re: Request for testing: ata(4) MFC Message-ID: <ACF0BD8AF9124428AA567442AE2B0E22@multiplay.co.uk> References: <676151223134689@webmail38.yandex.ru> <20081005004808.GA70137@icarus.home.lan> <48E99C18.6070602@yandex.ru> <20081006051211.GA10542@icarus.home.lan> <20081010115855.GA31707@icarus.home.lan><20081016071700.GA2793@icarus.home.lan> <48F7B865.2040604@mawer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
You must be very careful with using less than 48bit addressing when both
the drive and the controller supports it as some disks report errors at
none standard crossover points.
I saw this first hand with the highpoint driver where it totally trashed
the RAID volumes. The solution was to "always" use 48bit addressing if
the drive supports / requires it.
Regards
Steve
> I started looking at the moment, as the original 28->48bit crossover bug was in the same function not so long ago (ata-all.c
> rev1.280). The 48-bit LBA changes are introduced from ata-all.c rev1.282, which was the port multiplier changes. The logic just
> doesn't seem quite right to it to me, but
>
> I'm not an expert on the code or on ATA, so all of this could just be amateur mis-interpretation. From my reading of it, the
> code does this:
>
> /*
> * Check to see if we need to use a 48-bit command in place of the
> * standard 28-bit command, and if so, substitute as appropriate
> */
> IF ((request_lba_addr + lba_count) >= max addressable by 28-bit LBA
> or lba_count > 256) and device supports 48-bit LBA THEN
> /*
> * The request either:
> *
> * - extends past the 28-bit boundary
> * - is for more than 256 sectors
> *
> * which necessitates the use of 48-bit LBA. Translate commands
> * into their 48-bit equivalents.
> */
> ...
> ELSEIF the device supports 48-bit lba:
> /*
> * We prefer (need?) to use the 48-bit equivalents of these
> * commands regardless of what the LBA address of the reqest is
> */
> ...
> END IF
>
> In rev 1.282, the ATA_READ_NATIVE_MAX_ADDRESS was moved down to the "ELSE" case of the IF statement. In otherwords, when the
> request is beyond the 28-bit boundary, OR it's > 256 sectors, ATA_READ_NATIVE_MAX_ADDRESS won't be translated...
>
> Søren, is this change intentional, or should it be also added to the switch statement in the top half of the IF block?
>
> The ATA code appears to be very lightly commented, which no doubt is something of a barrier to entry to those who are not
> familiar with issues such as the above... would any volunteers be helpful to help comment and/or document some of the code? We
> would likely need to confer with Søren and others to ensure that our interpretation was accurate, but it would certainly make
> tracking down issues easier for those unfamiliar with the code...
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ACF0BD8AF9124428AA567442AE2B0E22>