Attached is the latest SATA patch (and BK info).

When I turned on the PATA support in libata to do some ATAPI development 
on my ICH5, I reproduced the behavior that Fabio Coatti was seeing on 
his box.  This patch fixed my PATA interface, here's hoping it fixes 
Fabio's problem as well.

Tech info for Bart:  The ATA_DMA_INTR bit in ATA_DMA_STATUS is 
apparently set whenever the INTRQ line (emulated under SATA) indicates 
an interrupt...  even for non-DMA commands.  I did not expect this, at 
least :)

Judging from some of the ICH-related bug reports, I'm willing to bet 
that the IDE driver needs to do what libata is now going, WRT interrupt 
acknowledgement.  Also...  for the case in combined mode, where IDE 
driver and libata driver share the hardware, the IDE driver needs to 
talk to the BMDMA registers that it is not allowed to access.

IMO once ATAPI is working (very soon), the easiest thing to do would be 
to let libata handle PATA for the combined mode case.  This would 
eliminate all the nasty ____request_resource stuff (which Marcelo 
rightly objected to), and should allow for a clean fix to this 
sharing-hardware problem.

In theory, it is always an ugly situation when two drivers talk to a 
single PCI device simultaneously...

	Jeff