Re: Off-by-one in both LIBATA and IDE drivers

[Robert Hancock <hancockrwd@gmail.com>]

Norman Diamond wrote:
>> I assume that ATA_PIIX is set in the configuration.. The lspci -vn and
>> dmesg output from when it fails to detect would be useful.
> 
> Yes, and built in (not even as a module).
> 
> Sorry I'm away from the machine, but even near the machine it's a pain to
> copy text exactly because it's running under Slax (live CD) with no network
> shares.  Even when quoting a dump from the TASKFILE breakage in a later
> kernel I had to read and type by hand.
> 
> I think the PIIX4 devices of VMware server are well known.  Besides vendor
> 8086 and device 7111, VMware's subsystem is coded into LIBATA's PIIX 
> driver.
> 
> For the same PIIX4 devices on a real machine the subsystem is different but
> they're still vendor 8086 and device 7111.
> 
> If I omit hda=noprobe hdb=noprobe hdc=noprobe hdd=noprobe then dmesg shows
> the old IDE driver probing properly, assigning hda to the hard drive and 
> hdc
> to Slax's CD-ROM.  After that LIBATA 3.0 loads but has nothing to do.
> 
> If I include the four noprobes (or as another experiment, ide0=noprobe
> ide1=noprobe hda=none hdb=none hdc=none hdd=none), dmesg shows something
> recognizing that PIIX4 isn't completely native (as always), then the old 
> IDE
> drivers obediently ignoring those devices and reasonably proceeding to 
> probe
> and find nothing on ide2, ide3, ide4, and ide5.  After that LIBATA 3.0 
> loads
> and still does nothing, even though we know what it should be doing.

ata_piix should definitely attach to 8086/7111 regardless of the 
subsystem IDs. I can't really explain why it's not. You should at least 
be seeing a message about the ata_piix version, if not then somehow the 
driver probe function isn't even being called..

> 
> In comparison, I did the same experiments again on Dell and Lenovo machines
> whose BIOSes set ICH7M chipsets to present ATA interfaces, with no 
> option to
> present AHCI interfaces.  If I omit the noprobes then the old IDE drivers
> take over, the hard drive and DVD drive run UDMA to the ICH7M chips, and 
> the
> old IDE drivers run PIO to the ICH7M's ATA interfaces on hda and hdc (with
> no option to enable use_dma).  If I include the noprobes then the old IDE
> drivers obediently refrain, and this them LIBATA 3.0 takes over as it
> should.
> 
> As a workaround I recompiled Slax's kernel 2.6.24.3 and Slax's other stuff,
> with the old IDE drivers changed to modules instead of built in, and LIBATA
> built in the same as before.  Now LIBATA 3.0 takes over as it should, both
> for PIIX4 and ICH7M.  But I still worry that someone's going to have
> chipsets from UMC or ALi or AMD or VIA or SIS or something, where the old
> IDE drivers are necessary, and who knows if this is going to work.  I don't
> have all the machines I need for testing.

The old IDE drivers shouldn't be necessary on any of those, at least not 
in current kernels. I don't know what the state of all of those libata 
drivers in 2.6.24 was.

> 
> On a different tangent, LIBATA's off-by-one error was present in 2.6.20.  I
> booted that Slax with no modification on a machine with ICH7M, a Toshiba
> 250GB hard drive got /dev/sda with DMA, and the DVD drive got /dev/hdc 
> and I
> forgot to check if it got DMA.  Three dd commands should have all failed:
> dd if=/dev/sda of=/dev/null bs=512 skip=268435455 count=1
> dd if=/dev/sda of=/dev/null bs=512 skip=268435448 count=8
> dd if=/dev/sda of=/dev/null bs=512 skip=268435440 count=16
> Somehow the third one worked.  Two error messages and one silence, 100%
> repro.  OK, I'm not the only one pulling hair out over this stuff.  I
> noticed LIBATA's blacklists for broken firmware in various devices.
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/