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:
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.
Other (possibly relevent) boot-time messages (in order
of appearance):
IBM machine detected. Enabling interrupts during APM calls.
kernel: PIIX4: IDE controller on PCI bus 00 dev 11
PIIX4: chipset revision 1
PIIX4: not 100%% native mode: will probe irqs later
ide0: BM-DMA at 0xfff0-0xfff7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xfff8-0xffff, BIOS settings: hdc:DMA, hdd:pio
hda: QUANTUM FIREBALL EX3.2A, ATA DISK drive
hdc: SONY CD-ROM CDU5221, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
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
Gerald Britton wrote:
>
> 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
Right. Thanks. I'll try it (hdparm -X66 actually, my drive only
supports udma2). (I know that it will work. I just want to know what's
_exactly_ wrong with my setup ;)
-ioj
.
Mark Hahn wrote:
> > _sometimes_ I get the following message from the kernel
> > after resuming from APM standby mode:
>
> right, no big surprise there - the bios fails to properly
> restore the ide controller's state.
Hmmm... I had had some trouble with the BIOS previously;
Specifically, the machine would hang whenever I wanted it to
power-off _or_ reboot (kernel 2.2.16 - 2.2.14 probably had a workaround
which later got dropped). But a BIOS upgrade from IBM fixed that and
some other irrelevent problems; The documentation with the flash didn't
mention anything about DMA (specifically - it may have been hidden in
some fixes said to be necessary for WinNT 5 beta).
> > ide_dmaproc: chipset supported ide_dma_timeout func only: 14
>
> are you sure this happens near in time to the following?
Yes. and this too:
hda: timeout waiting for DMA
Just before the message from ide_dmaproc()
> > hda: drive not ready for command
>
> that's not good.
What does this mean?
> > IBM machine detected. Enabling interrupts during APM calls.
>
> have you tried without this feature?
Not exactly; Some docs I found at the IBM site recommended the user
to configure the kernel to:
(1) Enable APM
(2) Enable PM at boot-time
(3) Enable interrupts during APM BIOS calls.
It seems that 2.4 kernels detects this and enables interrupts
automatically... I've yet to see what would break if I enable
apm_idled...
Thanks.
-ioj
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Andre -- Would you be willing to point us to where we can get it and play
with it? I'm sure there are a lot of people here who would like to see
your work. I, for one, am not sure where to get it though. :(
-Jacob
On Sat, 8 Dec 2001, Andre Hedrick wrote:
> 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
Jacob Luna Lundberg wrote:
> Andre -- Would you be willing to point us to where we can get it and play
> with it? I'm sure there are a lot of people here who would like to see
> your work. I, for one, am not sure where to get it though. :(
>
> -Jacob
I'd be a willing guinea pig too, if I knew where to look.
Fran?ois
> On Sat, 8 Dec 2001, Andre Hedrick wrote:
>
>
>>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
>>
>
> -
> 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/
>
>
Me Too!
cu
jjs
Fran?ois Cami wrote:
> Jacob Luna Lundberg wrote:
>
> > Andre -- Would you be willing to point us to where we can get it and play
> > with it? I'm sure there are a lot of people here who would like to see
> > your work. I, for one, am not sure where to get it though. :(
> >
> > -Jacob
>
> I'd be a willing guinea pig too, if I knew where to look.
>
> Fran?ois
>
> > On Sat, 8 Dec 2001, Andre Hedrick wrote:
> >
> >
> >>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
> >>
> >
> > -
> > 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/
> >
> >
>
> -
> 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/
>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
Andre,
Any chance of some further details on this work. AFAIKT you've been the
foremost contributor of cutting-edge IDE updates for quite some time now. I
find it astonishing that Linus would have inexplicably started refusing your
code. At least point us in the right direction so we can try the new stuff
out.
Simon
On Sun, 9 Dec 2001, Simon Turvey wrote:
>
> >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
>
> Andre,
> Any chance of some further details on this work. AFAIKT you've been the
> foremost contributor of cutting-edge IDE updates for quite some time now. I
> find it astonishing that Linus would have inexplicably started refusing your
> code. At least point us in the right direction so we can try the new stuff
> out.
>
> Simon
I am working on a final update right now. This is after fixing the driver
to perform correct data-transport layers. This is linux soft-raid 0 w/
four drives. The are 4-20GB drives partitioned to make two md devices to
isolate peformance boundaries.
Writing superblocks and filesystem accounting information: done
No size specified, using 510 MB
Size is MB, BlkSz is Bytes, Read, Write, and Seeks are MB/sec
File Block Num Seq Read Rand Read Seq Write Rand Write
Dir Size Size Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
------- ------ ------- --- ----------- ----------- ----------- -----------
. 510 4096 1 84.75 57.1% 1.081 1.17% 79.80 43.9% 4.285 2.46%
. 510 4096 2 78.88 52.8% 1.171 0.97% 73.64 48.8% 4.411 3.67%
. 510 4096 4 74.04 51.3% 1.402 1.16% 73.77 51.9% 4.391 3.65%
. 510 4096 8 67.93 47.9% 1.623 1.42% 71.43 52.1% 4.360 3.62%
File './Bonnie.943', size: 1073741824, volumes: 1
Writing with putc()... done: 9709 kB/s 98.9 %CPU
Rewriting... done: 49883 kB/s 41.4 %CPU
Writing intelligently...done: 99026 kB/s 50.0 %CPU
Reading with getc()... done: 9663 kB/s 99.1 %CPU
Reading intelligently...done: 89632 kB/s 55.0 %CPU
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek-
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)-
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
1*1024 9709 98.9 99026 50.0 49883 41.4 9663 99.1 89632 55.0 344.2 4.0
Wrote 38184 Meg / 78201343 blocks 0 Meg / 0 blocks
Device length: 40038825984 Bytes / 38184 Meg / 37 Gig
Total Diameter Sequential Pattern Write Test = 96.10 MB/Sec (397.35 Seconds)
Read 38183Meg (78198784 blocks)
Read failed on block number 78200832 at offset 40038825984 ( 0 / 512 )
Error: Input/output error
Could not find block: 78200833 for reading.
Error: Invalid argument
Read 38184Meg (78200833 blocks)
Device length: 40038825984 Bytes / 38184 Meg / 37 Gig
Total Diameter Sequential Pattern Read Test = 75.68 MB/Sec (504.53 Seconds)
Device passed! Seek OverRun!
The test has an overrun on the last request under lseek, working on fixing.
The slower read rate is a direct result of using a pattern buffer check
and comparison (write/read/verify/compare/contest-errors). Details later
but the drive(s) are faster than reported. These rates are using EXT2 for
the FS.
Regards,
Andre Hedrick
CEO/President, LAD Storage Consulting Group
Linux ATA Development
Linux Disk Certification Project