> places where the bit must be twiddled. Its easier to leave the bit in
> the BIOS-initialized state, and ignore the hardware bit's existence in
> software, if we know the behavior in the controller is hardwired. Less
> room for software bugs that way, IMO.
The AMD docs don't categorically an
Alan wrote:
Deleting the ata_pci_clear_simplex() call, then adding
ATA_FLAG_IGN_SIMPLEX to the ata_port_info info[] array, is also worth
trying.
I think I know what is going on here. Firstly the simplex bits
need re-clearing on a resume. On my todo list now I'm back
If the bit does not actua
> Deleting the ata_pci_clear_simplex() call, then adding
> ATA_FLAG_IGN_SIMPLEX to the ata_port_info info[] array, is also worth
> trying.
I think I know what is going on here. Firstly the simplex bits
need re-clearing on a resume. On my todo list now I'm back
-
To unsubscribe from this list: se
Jeff Garzik wrote:
> Robert Hancock wrote:
> >Yes, the fact that it's going into simplex mode is the problem, it
> >wasn't in simplex to start with. It looks like pata_amd does an
> >ata_pci_clear_simplex only for certain chip models, maybe this model
> >needs it as well?
>
> Deleting the ata_p
Robert Hancock wrote:
Tobias Diedrich wrote:
Possibly a known issue:
After resume pata_amd drops from UDMA/33 to PIO on my system.
Reloading the module puts both attached optical drives (master and
slave) back to UDMA/33.
AFAICS "simplex DMA is claimed by other device, disabling DMA" seems
to
Tobias Diedrich wrote:
Possibly a known issue:
After resume pata_amd drops from UDMA/33 to PIO on my system.
Reloading the module puts both attached optical drives (master and
slave) back to UDMA/33.
AFAICS "simplex DMA is claimed by other device, disabling DMA" seems
to be causing it to drop t
6 matches
Mail list logo
