> If BIOS hasn't run, UDMA timing wouldn't have been programmed and as > such the speed won't be limited. So, there should be no harm done in > that case. Even if something goes really wrong, the worst happens is > capping speed to udma33. Which is bad and leaves people with mysterious performance problems that randomly appear in a new release. You have error handling code that will do UDMA change down, you've fixed the disk side detect. We don't need to destroy the pata_amd driver as well nor the IDE AMD driver. You get whatever the chip has loaded. The BIOS may pick PIO modes only, the BIOS may not have been run so the UDMA bits could be arbitary. You may even get wrongly capped values. Also another case you broke is kexec. > So, I think the benefit (correct configuration on most machines) easily > outweighs the danger (incorrectly capping speed to working udma33 on > non-PC). Yours is the first complaint I've seen about this hardware detection in *THREE* years. Its a bigger problem with libata but thats because of the drive side detect and also because currently we work on the basis in libata that host side detect defines cable, while old ide (when behaving and correctly working) works on the basis that if the host says 80wire and the drive says 40 wire (or vice versa) then its 40. Alan - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
