IDE driver: CBLID revisited

I saw a thread about CBLID detection from earlier this year, and have encountered an issue with this.

The complexity of this situation can only be exceeded by the likely narrowness of its application, so bear with me.

I have an old Maxtor 91360U4. This is a 13.6 BB, UDMA-66 drive that was made August 27, 1999. For a few years I ran this as a UDMA-33 drive connected with a 40-wire cable to a VIA 82C586B South Bridge. It was very happy there, except for a few "lost interrupt" incidents due to cable overheating caused by an even older Micropolis SCSI drive. (Anyway, I *believe* that's what it was.)

Now comes a new motherboard with a VIA 8235 South Bridge, which is UDMA-133 capable. I install the Maxtor 91360U4 with an 80-wire cable. There are two OSes on it, Linux 2.4.17 and NetBSD 1.5.1. When I boot NetBSD 1.5.1, it quickly encounters CRC errors during read operations, and ratchets down the mode; so I shut it down, at which point it vaporizes itself by trashing the file system metadata during write operations.

Linux 2.4.17 fares better. Failing to recognize the 8235 chip, it leaves things alone, apparently, and seems to run OK. I've forgotten what mode it winds up using.

2.4.20 recognizes the chip, but ratchets down the mode during kernel autoconfiguration. I think it winds up using DMA mode 0. It operates safely but slowly.

It emerges that the drive implements IDENTIFY DEVICE word 93 oddly. Bits 15-14 are correct (01b), but bit 13 is exactly upside down (0 with an 80-wire cable, 1 with a 40-wire cable).

The 8235, meanwhile, does have bits in a register that indicate BIOS detection of cable types (from each CBLID wire connected to a GPIO pin, apparently).

Since I'm running the IDE driver with VIA chipset support built-in, the driver enforces UDMA-66 with a 40-wire cable and UDMA-33 with an 80-wire cable. This is because the VIA chipset test for UDMA-66 -- in function pci_init_via82cxxx() -- ignores the cable type bit, but looks at the timing bits. But the timing bits are the same for UDMA-33 and UDMA-66.
Meanwhile, the drive test finds the upside down cable type bit from
IDENTIFY DEVICE word 93.

I succeeded in hacking 2.4.20 so it gets this right, by #ifdef'ing out a couple of checks on IDENTIFY DEVICE word 93, and forcing the test in pci_init_via82cxxx() to depend on the chipset cable type bit. The drive now runs at UDMA-66, and seems to coexist fine as slave to a Maxtor 6Y080P0, an 80 BB UDMA-133 drive running in UDMA-133 mode (the drive I'm on as we speak).

Before rushing forward with a patch, however....

With this motherboard, I'm not sure I really need the VIA chipset support in the IDE driver anyway. Without it (or maybe even with it), I could use the 'ideX=ata66' and 'ideX=dma' parameters. Or could I?!?

But even so, that wouldn't necessarily address the situation for someone else with this drive, who has a VIA chipset somewhere between the 586B and 8235 and maybe a BIOS that doesn't initialize the best mode properly.

I was told by VIA that the cable type reporting bits are there "since" the first 8233 chip (device ID 0x3074).

Aside from that, I gotta say, the IDE driver really has gotten kind of large and complicated, probably from trying to deal with a zillion different oddball situations, much like this one.

Comments? Questions? Discussion?

-- Jim Howard <[email protected]>

Indeed, since 6 means (6+2)*7.5ns which is 60ns, which is the correct threshold. I probably forgot to subtract the '2' ...

Please can you make patches for 2.4 and 2.6?

Vojtech Pavlik
SuSE Labs, SuSE CR

I aleady downloaded. Anyway, I probably should go through this, I've never made any patches for Linux. Good thing it's not very urgent.

(Maybe after reading that you'll *prefer* to make them yourself....;)

-- Jim Howard <[email protected]>