Gerald,
Like I told you in the other forum. I have the solutions just my work is
being refused. Don't know if I have absolutely pissed off the
king-penguin or what but there is no reason to submit when I know it is
not going to be accepted -- regardless that it is in exact compliance to
the ANSI/NCITS rules that I am now one of the co-authors.
Regards,
Andre Hedrick
CEO/President, LAD Storage Consulting Group
Linux ATA Development
Linux Disk Certification Project
On Fri, 7 Dec 2001, Gerald Britton wrote:
> On Fri, Dec 07, 2001 at 05:30:14PM -0600, Ishan Oshadi Jayawardena wrote:
> > Greetings.
> > I run Linux on an IBM PC300GL with Intel's
> > 82371AB PIIX4 chipset. With DMA enabled (by doing a
> > hdparm -d1 /dev/hda) on the hdd, I
> > _sometimes_ get the following message from the kernel
> > after resuming from APM standby mode:
>
> I have very similar behavior on an IBM Thinkpad T23. It's got this IDE
> controller:
>
> 00:1f.1 IDE interface: Intel Corporation: Unknown device 248a (rev 01)
> Subsystem: IBM: Unknown device 0220
>
> And, I also only sometimes get roughly:
>
> ide_dmaproc: chipset supported ide_dma_lostirq func only: 13
> hda: lost interrupt
> ide_dmaproc: chipset supported ide_dma_timeout func only: 14
>
> > ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> > hda: status error: status=0x59 { DriveReady SeekComplete DataRequest
> > Error }
> > hda: status error: error=0x84 { DriveStatusError BadCRC }
> > hda: drive not ready for command
> >
> > then the drive stalls for a few seconds, and the driver
> > disables DMA. This behaviour doesn't seem to depend on the
> > kernel version (current: 2.4.14; error seen with 2.2 series also.)
> > The weird thing is that this is not reliably reproducable; most of
> > the time the system goes to apm standby (not suspend) and resumes fine.
>
> Unfortunately, when mine hits this condition, it seems to never recover
> from it. It also seems to only happen sometimes and I've been unable to
> reliably reproduce the problem. I told Andre about the problem and he
> suggested doing a "hdparm -d0 -X08 /dev/hda" prior to suspend and that
> seems to work around the problem. I "hdparm -d1 -X69 /dev/hda" on resume
> to get it back to speedy udma5 mode. I think the problem is the BIOS doing
> things to the IDE chipset during the suspend, and the driver not properly
> correcting the changes on resume.
>
> -- Gerald
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:13 EST