Re: [ACPI] IDE failure on ACPI resume
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] IDE failure on ACPI resume
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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] IDE failure on ACPI resume
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] IDE failure on ACPI resume
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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] IDE failure on ACPI resume
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] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] IDE failure on ACPI resume
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] IDE failure on ACPI resume
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] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] IDE failure on ACPI resume
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] IDE failure on ACPI resume
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] IDE failure on ACPI resume
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
