I have just been thrashing around trying to find why all the CD and DVD writing software on a Debian system suddenly stopped working. It would write some of the disc but then fail after writing an indeterminate amount of data with "Logical Unit Communication CRC Error (ULTRA-DMA/32)" (along with other blah depending on which particular package I was trying to use).
Attempting to find clues to the cause of the problem by googling for such errors in relation to Linux led me into a long and ultimately irrelevant diversion into all the stupid shite that has arisen out of Joerg Schilling and Eduard Bloch bitching and whining at each other over pointless licensing crap which none of the end users give a living fuck about but nevertheless have to suffer the consequences of. I am not going to take one side or the other in the debate, since as far as I can make out they are both as bad as each other, both comparably guilty of creating confusion among end users and hindering the resolution of bugs by their insistence on being babyish cunts over stupid fucking copyright shit, and providing a compelling example in favour of the argument that we will all be a fuck sight better off once the whole stupid-arse shitey notion of copyright is abandoned altogether as an obsolete relic which has no place in a time when copying stuff is so utterly trivial as the present. And in any case it turns out to be a complete red herring that has fuck all to do with the matter in hand.
Dropping the Linux-specific terms from the search query revealed that Windows users have been having exactly the same problem - and even encountering the same bloody error message, identical not only in wording but in capitalisation, spacing and punctuation; which is intriguing, as it seems to imply that Windows and Linux are using the same library under the hood to communicate with CD drives. The error started showing up at around the same time too - 2008, with a few instances from late 2007. However, there is an important difference in that in the Windows arena we don't have all the Schilling-vs-Bloch idiotic crap smothering the whole business in a distracting fog of irrelevant shite, so the signal to noise ratio is a whole lot better and the discussions end up identifying the real cause of the problem: CABLES.
It seems to have been around late 2007 that CD/DVD drive manufacturers started making their ordinary run-of-the-mill ATAPI drives support UDMA66 and higher. Fuck only knows why since the actual drive itself is not fast enough to take advantage of the higher potential maximum transfer rate.
There is no fucking point whatsoever in making CD/DVD drives support massively fast bus speeds, because the drive mechanism can't provide data at anything like that rate to begin with. When you are reading a great big file off a CD or DVD the transfer rate is limited by how fast the drive can get the raw data off the disk, which is a lot slower than the bus can transmit it. When you are reading small files, the main speed limitation is the seek time, which is bleeding forever compared to a hard drive; transferring the data takes no time compared to the time it takes to find the file on the disk in the first place.
This additional capability is not only completely fucking useless, it's worse than that - it positively fucks things up, and the manufacturers who decided to implement it need a bloody good boot up the arse. So do the writers of the BIOSes on motherboards that may be used with it.
UDMA66 requires an 80-conductor IDE cable to work properly. With the old 40-conductor cables it fucks up in an unpredictable way and produces errors at random times. It is supposed to be possible to detect whether an 80-conductor or 40-conductor cable is installed - the motherboard-end plug (blue plug) on an 80-conductor cable connects pin 34 to ground, whereas on a 40-conductor cable this does not happen, so the IDE driver can look at this pin to determine what cable is installed.
Both in Windows and in Linux, however, the IDE driver does not do this. It is supposed to, but it usually doesn't work. Which is shit. And for something so simple to be wrong the same way in two totally different OSes there must be something really stupid going on.
My best guess, at the moment, as to what the "something really stupid" might be, is that the BIOS writers are dicks who just assume that there is always going to be an 80-conductor cable installed and fill in the PCI config data accordingly again without bothering to look at pin 34, and the authors of the drivers for Linux, at least, do not know how. For instance, in the Linux kernel (version 3.12) source code for pata_atiixp.c we find this labelled as "cable detection code":
/* Hack from drivers/ide/pci. Really we want to know how to do the raw detection not play follow the bios mode guess */ pci_read_config_byte(pdev, ATIIXP_IDE_UDMA_MODE + ap->port_no, &udma); if ((udma & 0x07) >= 0x04 || (udma & 0x70) >= 0x40) return ATA_CBL_PATA80; return ATA_CBL_PATA40;
...and there are similar things in the code for other IDE chipset drivers.
The problem seems to begin with the motherboard chipsets themselves and the designers who use them - certainly so in the case of the chipset on my motherboard (AMD RS780, not exactly uncommon). This chipset - and presumably also others which show up this problem - does not have any dedicated facility for sensing the state of pin 34. You have to use one of the several general-purpose I/O pins it has, or else some other I/O facility altogether. This means that how pin 34 is sensed - if it is sensed at all - is potentially different for every different motherboard.
In Linux, therefore, the driver writers have no option but to "play follow the bios mode guess". This excuse does not apply in Windows, though, where it is standard practice to provide a CD of motherboard-specific drivers along with the motherboard, and for these drivers also to be available on the motherboard manufacturer's website. And there is no fucking excuse whatsoever for the BIOS writers to fail to include correct code for sensing pin 34 since dealing with quirks like that is a major part of what the BIOS is fucking for.
That these errors are so common and largely OS-independent is good evidence that the BIOS writers are being lazy-ass cunts who ought to be sacked, and the same goes for the authors of the Windows drivers who don't have the excuse of having to work without documentation. For fuck's sake, the fucking great cunts. Well, either that or the designers of the motherboards never bothered to include pin 34 sensing in the first place, in which case they are fucking great cunts.
So what has been happening is that people have been buying new/replacement CD/DVD drives on which the stupid fucking cunts of manufacturers have pointlessly provided UDMA66 (or higher) capability, plugging them into their system's existing 40-conductor cables which worked perfectly well with their old drive, and finding that the bastard thing doesn't work for no apparent reason. Confusion and mayhem ensue.
In my case the situation was a little different. I was installing a couple of new hard drives in one of my boxes and so needed a cable to connect them with. I had plenty of 40-conductor cables lying about but no 80-conductor ones. I did, however, have another box in which the DVD drive was connected using an 80-conductor cable - pointlessly, as I thought, since a DVD drive can't make use of the higher speed transfer capability. So I took that cable out, used it to connect the new hard drives in the other box, and used one of my 40-conductor cables to connect the DVD drive. I didn't try writing any DVDs for a month or so after doing this, and by the time I did come to write one, I had forgotten that the last time I had successfully written one was before I'd swapped the cables.
Thanks a fucking lot, stupid cunt manufacturers insisting on making your drives support a transfer rate which they are not fast enough to gain any benefit from. Thanks a fucking lot, stupid shite-arsed lazy cunts of BIOS writers who are too flaming bone idle to include actual fucking cable detection code - or cunts of motherboard designers who are too flaming bone idle to route two bleeding PCB tracks, whichever it is. (Piss easy PCB tracks, too, since they only have DC on them.)
Fortunately, in Linux at least - I have no idea about Windows, of course - it is possible to get round this problem purely in software, so I could fix it and get on with writing DVDs without having to fuck around getting another 80-conductor cable.
For one thing, it ought to be possible to use hdparm to reconfigure the drive to use UDMA33 or lower. It turns out that it isn't, though, because the drive rejects the command like a great massive cunt. Once the interface has been configured for a speed which doesn't actually work no communication with the drive is possible so it can't be reconfigured.
It is possible, however, to fix it by means of kernel boot parameters. This did mean I had to shut the machine down and reboot it, but at least I didn't have to wait to get hold of cables and could get going again straight away.
The output from dmesg includes this:
[ 1.452579] ata2.00: ATAPI: HL-DT-ST DVD-RW_GSA-H41N, RA00, max UDMA/66 [ 1.452646] ata2.01: ATAPI: Hewlett-Packard CD-Writer Plus 9100, 1.0c, max UDMA/33
...the first entry being the DVD drive which had stopped working, the second being a CD writer which did still work. This shows that the drives are on ATA bus 2, as devices 00 and 01. I therefore appended to the kernel boot parameters this:
libata.force=2:40c
...which translates as "force the driver to configure ATA bus 2 appropriately for a 40-conductor cable". And dmesg confirms that it has the desired effect:
[ 0.000000] Kernel command line: root=/dev/sda3 ro libata.force=2:40c ..................... [ 1.452511] ata2: FORCE: cable set to 40c [ 1.452579] ata2.00: ATAPI: HL-DT-ST DVD-RW_GSA-H41N, RA00, max UDMA/66 [ 1.452646] ata2.01: ATAPI: Hewlett-Packard CD-Writer Plus 9100, 1.0c, max UDMA/33 [ 1.452722] ata2.00: limited to UDMA/33 due to 40-wire cable [ 1.468453] ata2.00: configured for UDMA/33 [ 1.484460] ata2.01: configured for UDMA/33
...and indeed I now found that I could write DVDs again. Everything was working and I was not getting any cunty errors. (Though I am still thoroughly pissed off at having to go to all this fucking hassle to overcome the consequences of the DVD drive manufacturer's pointless stupidity in making the fucking thing uselessly support UDMA66 in the first place. Stupid fucking wankers.)
Back to Pigeon's Nest
Be kind to pigeons