> 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
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
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
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
> 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:
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: send
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
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
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
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 to
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
12 matches
Mail list logo
