From: Arno Wagner on
Previously Svend Olaf Mikkelsen <svolaf(a)partitionsupport.com> wrote:
> As example the problem is present with the Prolific PL-2506
> Hi-Speed USB to IDE Bridge Controller, the version I have, and the
> Seagate ST3160212A disk with firmware 3.AAJ.

> The problem is not present with the same chip and the Hitachi "Hitachi
> HDS721616PLAT80" disk with firmware P22OA8BA.

Ok, so this is either a disk or a controller issue that is triggerd
by use of a mix of LBA 28 and LBA 48 commands in a border situation
(namely sector 268435455, i.e. 2^28-1). Since the LBA commands
are created by the USB-to-ATA device, this would then not be OS
specific, as USB uses SCSI sector numbers (32 or 64 bit) anyways
and users of other OSes would be equally at risk.

> I am not certain who to blame, if any. One question is if a disk
> should be able to read sector 268435455 using LBA 28-bit commands,
> according to the ATA specifications.

I hat a look into an ATA-8 Command Set draft (Jan 2006) and it says in
4.1 that IDENTIFY DEVICE will return the number of sectors plus one
which (in 28 bit mode) may not exceed 0xfffffff, i.e. the number of
addressable secors in 28 bit mode is 268435454 at the most. However
for actual sector numbers it seems 268435455 is allowed (but can not
happen unless a 48 bit IDENTIFY DEVICE was used). My guess
is that some HDD manufacturers screwed up and actually kept the
LBA 28 commands at the limit that an LBA 28 IDENTIFY DEVICE imposes,
even if that limit is not present with LBA 48. At the same time
the USB-to-ATA bridge designers were careless and did not either
use LBA 48 from 268435455 onwards (or generally), which, given the
not too clear wording in the spec, would have been a good idea.

Arno
From: Arno Wagner on
Previously Svend Olaf Mikkelsen <svolaf(a)partitionsupport.com> wrote:
> On Sun, 26 Aug 2007 12:17:21 -0700, "Eric Gisin" <gisin(a)uniserve.com>
> wrote:

>>But Windows NT only issues LBA-32 sector nums, which IDE drivers translate.
>>The USB drives always get a SCSI LBA-32 sector, which the drive translates.
>>
>>The problem drives should be tested on OSX and Lunix.

> In a system with the problem present in Windows, this command did read
> the sector correctly in Linux:

> dd if=/dev/sda of=sector.bin bs=512 count=1 skip=268435455

> I do not know why the result is different between Windows and Linux.

Very interesting. This should not be happening as far as I can tell.
At least if the problem is only an over-optimistic SCSI 320bit sector
number to LBA 28 conversion. This probably means thet Winsows is
(mis-)configuring something, while Linux is not.

> With a 255 heads, 63 sectors geometry this is cylinder 16709, head 85,
> sector 16. I attempted to read the sector in Windows 2000 using
> Findpart, but it failed. I could read the sector by reading 2 sectors
> at the previous address,

That would be consistent with a problem with the secor address
in the command and no problem in the disk-internal handling
of sector numbers.

> and then edit the file using Windows edit,
> and after that it matched the sector read in Linux:

> C:\>findpart getsect 4 16709 85 16 1 sector.bin noheader
> Some sectors could not be read.

> C:\>findpart getsect 4 16709 85 15 2 sector.bin noheader
> File already exists.

> C:\>del sector.bin

> C:\>findpart getsect 4 16709 85 15 2 sector.bin noheader
> OK

> C:\>edit /64 sector.bin

> C:\>fc /b sector.bin l:\*.*
> Comparing files SECTOR.BIN and L:\SECTOR.BIN
> FC: no differences encountered

> C:\>

I think I have an idea: Linux may be reading sectors earlier
because of some pecularities in its read-ahead strategy.
For example it may align reads on dividable-by-4 block
numbers. This would give the behaviour you demonstrate above.

I think without diving into the USB and/or SCSI code this may be
difficult to find out.

Anyways, valuable information! Thanks!

Arno
From: Arno Wagner on
Previously Arno Wagner <me(a)privacy.net> wrote:
> Previously Svend Olaf Mikkelsen <svolaf(a)partitionsupport.com> wrote:
[...]
> I think I have an idea: Linux may be reading sectors earlier
> because of some pecularities in its read-ahead strategy.
> For example it may align reads on dividable-by-4 block
> numbers. This would give the behaviour you demonstrate above.
>
> I think without diving into the USB and/or SCSI code this may be
> difficult to find out.

Come to think of it, it may be that Linux typically reads (and
writes?) 1kB or 2kB aligned on an address divisible by 2 or 4
respectively. Maybe only on SCSI, maybe on USB storage, maybe
generally. On a fast browse through the sources of 2.6.18.8 I did not
find anything relevant.

This may mean that testing the presence of the problem under Linux
could need a single-secor write (if Linux does that). If Linux
allways does at least 1kB accesses aligned on an even address, then
the problem would not manifest itself. If it only does this on
reading, the problem could well be present for a single-sector
write.

Can you overwrite the critical sector with dd and then see
whether it changed?

Arno
From: Folkert Rienstra on
Arno Wagner wrote in message news:5jdm1bF3s60eiU1(a)mid.individual.net
> Previously Svend Olaf Mikkelsen <svolaf(a)partitionsupport.com> wrote:
> > When the Windows 2000/XP USB 128 GB problem is present, sector
> > 268435455 cannot be addressed.
>
> > It happens when an LBA 28-bit command is sent to the disk, and the
> > disk only supports LBA 48-bit commands for addressing that sector.
>
> > The problem can be detected using the Findpart version 4.87 GB32
> > program:
>
>
> > GB32, version FP 4.87 Copyright Svend Olaf Mikkelsen, 2007.
>
> > OS: Windows 5.0.2195 Service Pack 4
>
> > Disk: 4 Cylinders: 19457 Heads: 255 Sectors: 63 MB: 152625
>
> > Comparing sector 0 to 999 with an area later on the disk:
>
> > Distance 4096*255*63: 0 matches.
> > Distance 65536*16*63: 0 matches.
> > Distance 65536*15*63: 0 matches.
>
> > No known 32 GB problems were observed.
>
> > The Windows 2000/XP USB 128 GB problem is present.
>
>
> > The program also detects other 32 GB and 128 GB problems, such as the
> > Windows 98 USB 128 GB problem, which is kind of more severe, since
> > sector 268435455 is just not read or written when addressed, without
> > any warnings.
> > --
> > Svend Olaf
> > http://www.partitionsupport.com/utilities.htm

> Just like MS to screw up the most important things like disk drivers.

Babblebot, what exactly did you not understand in

" It happens when an LBA 28-bit command is sent to the disk, and the
disk only supports LBA 48-bit commands for addressing that sector"
(ie sector 268435455)

> When is this problem present?

Babblebot, what exactly did you not understand in

" It happens when an LBA 28-bit command is sent to the disk, and the
disk only supports LBA 48-bit commands for addressing that sector."
(ie sector 268435455)

> Generally or only in some instances?

How does this sound, babblebot:

" It happens when an LBA 28-bit command is sent to the disk, and the
disk only supports LBA 48-bit commands for addressing that sector."

>
> Arno
From: Folkert Rienstra on
Eric Gisin wrote in message news:13d3m6b2msgac98(a)corp.supernews.com
> But Windows NT only issues LBA-32 sector nums, which IDE drivers translate.

> The USB drives always get a SCSI LBA-32 sector, which the drive translates.

So it can't be a Windows (or any other OS) error.

>
> The problem drives should be tested on OSX and Lunix.
>
> "Svend Olaf Mikkelsen" <svolaf(a)partitionsupport.com> wrote in message> news:46d27304.15468312(a)news.inet.tele.dk...
> > When the Windows 2000/XP USB 128 GB problem is present, sector
> > 268435455 cannot be addressed.
> >
> > It happens when an LBA 28-bit command is sent to the disk, and the
> > disk only supports LBA 48-bit commands for addressing that sector.
> >
> > The problem can be detected using the Findpart version 4.87 GB32
> > program:
> >
> >
> > GB32, version FP 4.87 Copyright Svend Olaf Mikkelsen, 2007.
> >
> > OS: Windows 5.0.2195 Service Pack 4
> >
> > Disk: 4 Cylinders: 19457 Heads: 255 Sectors: 63 MB: 152625
> >
> > Comparing sector 0 to 999 with an area later on the disk:
> >
> > Distance 4096*255*63: 0 matches.
> > Distance 65536*16*63: 0 matches.
> > Distance 65536*15*63: 0 matches.
> >
> > No known 32 GB problems were observed.
> >
> > The Windows 2000/XP USB 128 GB problem is present.