This message is from the T13 list server.
On Fri, 20 Feb 2004 11:02:41 -0800, Eschmann, Michael K wrote: >This message is from the T13 list server. >Hale, The flow you suggest is heavy-handed. Might I suggest some more >lenient methods? Read more below. MKE. Heavy handed? Who me? Gosh... I thought I was just describing the way some popular OSs operate? :) >If you find a disabled controller, the device doesn't implement device >hiding, which is probably a bad idea. However an OS doesn't need to >blue-screen, just don't start a driver for this controller or the driver >should just not set up device objects for itself or run any ATA/ATAPI >device command cycles. OK, but that would require a few extra "if" statements, blue screens are less complex to implement, aren't they? :) >The BAR should never be -1, and if they are programmed for anything that >seems unexpected (memory, plus 0 or -1 address) the driver doesn't need >to bugcheck, but rather can re-program the controller for legacy >operation. OK... That brings up a bunch of additional issues like what to do if that doesn't work or if changing the BAR values messes up some other controller's operation or some previously initialized device driver's operation? >If BAR4 is bad the driver must run PIO cycles. OK, I'll have to look at 1510 and see if BAR4 "not supported" is "legal". >The worst idea is to bugcheck just because the BAR's are programmed and >the controller is set for legacy operation. PCI enumerators have no >idea that we're legacy when it sees BAR's to fill out, so it just fills >them out. A question that should be asked of the PCI bus designers is this: Why is a controller allowed to use system resources with having those resources described in the PCI config space? Why does an ATA controller in legacy mode show "zero" in the BAR locations? This is really stupid - how can this be called "plug and play"? >And finally there's no limitation to running DMA cycles if you can't >take an interrupt. I sort of agree, but how do you know when it is safe to set the BMIDE Start/Stop bit to zero if you don't use the BMIDE Interrupt bit or you can not see the BMIDE Interrupt bit set to 1 (because some other part of the system's software resets it so fast that your software can't see it, which is what can happen if you don't use the actual interrupt)? >Running without interrupts is SOP for Windows during >Crashdump and Hibernation file writing. When under an OS the OS must >deal with the interrupt mapping, and in DOS the BIOS will map the >interrupt to one of the base IRQ's (15 or lower). Yep. Hale *** Hale Landis *** www.ata-atapi.com ***
