--------------------------------------------------
Here is a message for you from http://web2mail.com
The easy way to read and send POP email on the web
--------------------------------------------------

My employer is using Linux as a boot-loader of sorts which eventually boots

another OS. We have some proprietary code which runs in real mode between the

time Linux runs and the next operating system is chain-booted (we use kexec

return to real mode after Linux). This proprietary code makes use of the BIOS

disk calls via int13. In short we need to the BIOS Int13 after Linux.



Our system seems to work well on most machines, however it does not work on any

machine that make use of AHCI. As soon as we make the first Int13 call after 
the 

Linux AHCI driver has been initialized, the machine goes off into the weeds. 



I been looking though your archives and reading the AHCI spec. It seems clear

that the hardware has at least some state contained within it; I'm wondering if

there is any hope of putting the chip back to a known state that the BIOS will

be able to handle. 



1)In reading the AHCI spec, I notice in chapter 10.6 they talk about a bit that

when set by the OS driver, control of the AHCI hardware is irrevocably passed to

the OS, your driver does not seem to touch that bit so I'm hoping that it is

reasonable to pass back control to the BIOS by either resetting the chip or

simply placing it into a quiescent state.

2)I also have noticed that you do not do anything special when the AHCI module

is removed. That is, you simply use the ata_pci_remove_one() function instead of

one particular to the AHCI chip. 



Could anyone lend some guidance as to what has to be done to put the hardware

back into a sane state for BIOS, or if there is a good reason that this is not

achievable. 



Any prior work or manuals that I should “rtfm” or other wisdom would be greatly

appreciated.



Thank you.



Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to