On resume, an HP nc6220 fails during resuming of the IDE devices. In
this section of code from ide-iops.c:
stat = hwif->INB(hwif->io_ports[IDE_STATUS_OFFSET]);
if ((stat & BUSY_STAT) == 0)
return 0;
/*
* Assume a value of 0xff means nothing is connected to
* the interface and it doesn't implement the pull-down
* resistor on D7.
*/
if (stat == 0xff)
return -ENODEV;
0xff is read and ENODEV returned. This results in
hda: bus not ready on wakeup
hda: drive not ready on wakeup
and then the machine sits there until some later command times out. It
seems that reading anything off the IDE bus just results in 0xff being
read.
The IDE controller is an Intel ICH6. Another HP laptop with an identical
chipset works fine, which makes me suspicious of the BIOS. Is the fact
that Linux doesn't seem to run the GTF, STM or GTM methods likely to be
relevant here?
--
Matthew Garrett | [email protected]
Matthew Garrett wrote:
> On resume, an HP nc6220 fails during resuming of the IDE devices. In
> this section of code from ide-iops.c:
>
> stat = hwif->INB(hwif->io_ports[IDE_STATUS_OFFSET]);
> if ((stat & BUSY_STAT) == 0)
> return 0;
> /*
> * Assume a value of 0xff means nothing is connected to
> * the interface and it doesn't implement the pull-down
> * resistor on D7.
> */
> if (stat == 0xff)
> return -ENODEV;
>
> 0xff is read and ENODEV returned. This results in
Sounds like PCI not being completely restored. We had to work around
some weird ATA issues in FreeBSD with the status register being invalid
for quite a while after resume. A retry loop was the solution.
--
Nate
On Sun, 2005-03-13 at 20:53 -0800, Nate Lawson wrote:
> Sounds like PCI not being completely restored. We had to work around
> some weird ATA issues in FreeBSD with the status register being invalid
> for quite a while after resume. A retry loop was the solution.
FreeBSD seems to fail in the same way on the same hardware,
unfortunately. I'm leaning towards suspecting that we need to be doing
something with the contents of the _GTF method, but by the looks of that
that requires us to be able to work out which methods correspond to
which hardware. Is anyone working on implementing this?
--
Matthew Garrett | [email protected]
Matthew Garrett wrote:
> On Sun, 2005-03-13 at 20:53 -0800, Nate Lawson wrote:
>
>
>>Sounds like PCI not being completely restored. We had to work around
>>some weird ATA issues in FreeBSD with the status register being invalid
>>for quite a while after resume. A retry loop was the solution.
>
>
> FreeBSD seems to fail in the same way on the same hardware,
> unfortunately. I'm leaning towards suspecting that we need to be doing
> something with the contents of the _GTF method, but by the looks of that
> that requires us to be able to work out which methods correspond to
> which hardware. Is anyone working on implementing this?
>
Very interesting. I was hoping to someday have _GTF et al implemented
but the ATA knowledge required was above my head. I also strongly
suspected that the info published by _GTF would likely be invalid. Does
Windows actually use that method or just hardcoded ATA initialization?
--
Nate
On Thu, 2005-03-17 at 12:34 -0800, Nate Lawson wrote:
> Very interesting. I was hoping to someday have _GTF et al implemented
> but the ATA knowledge required was above my head. I also strongly
> suspected that the info published by _GTF would likely be invalid. Does
> Windows actually use that method or just hardcoded ATA initialization?
I believe that Windows does use the _GTF methods.
--
Matthew Garrett | [email protected]
Matthew Garrett wrote:
> On Thu, 2005-03-17 at 12:34 -0800, Nate Lawson wrote:
>>Very interesting. I was hoping to someday have _GTF et al implemented
>>but the ATA knowledge required was above my head. I also strongly
>>suspected that the info published by _GTF would likely be invalid. Does
>>Windows actually use that method or just hardcoded ATA initialization?
>
> I believe that Windows does use the _GTF methods.
You are correct. A quick scan of my w2k drivers shows atapi.sys uses
the _GTF, _GTM, and _STM methods.
--
Nate