Re: DMA problems w/ PIIX3 IDE, 2.4.20-pre4-ac2

Re: DMA problems w/ PIIX3 IDE, 2.4.20-pre4-ac2

[Jan-Hinnerk Reichert]

Florian Hinzmann wrote:

> Hi!
> 
> I have problems with DMA mode at one of my boxes ( more technical
> details at the end of this mail ).
[...] 
> But I do issue a "hdparm -d0" for each of them at bootup currently and
> they are running fine then. Enabling DMA with "hdparm -d1" (or not using
> hdparm at all) leads to errors like the following quite fast and
> reproducable:
> 
> kernel: hdb: dma_timer_expiry: dma status == 0x60
> kernel: hdb: timeout waiting for DMA
> kernel: hdb: timeout waiting for DMA
> kernel: hdb: (__ide_dma_test_irq) called while not waiting
> kernel: hdb: status error: status=0x58 { DriveReady SeekComplete
> DataRequest } kernel:
> kernel: hdb: drive not ready for command
> 
> Turning DMA off again stops these.
> 
> 
> I'd love to hear any experience other people have with this mainboard
> or even some statement if DMA is supposed to work with my setup.

I had some problems like this using 2.4.17 on a PIIX3 board (don't know the 
board type). The problems disappeared after switching to 2.4.19. 
Unforunately I had to change the processor and processor fan about the same 
time.

I tend to believe that this problem was related to CPU temperature not to 
kernel bugs. I don't have any means of measuring CPU temperature on this 
board. But the old CPU certainly burnt out, because the fan was not 
working too well ;-(((

Re: DMA problems w/ PIIX3 IDE, 2.4.20-pre4-ac2

[Andre Hedrick]

Yep I had that problem too and fixed it.
Please try a newer pre5-acX


On Sat, 14 Sep 2002, Jan-Hinnerk Reichert wrote:

> Florian Hinzmann wrote:
> 
> > Hi!
> > 
> > I have problems with DMA mode at one of my boxes ( more technical
> > details at the end of this mail ).
> [...] 
> > But I do issue a "hdparm -d0" for each of them at bootup currently and
> > they are running fine then. Enabling DMA with "hdparm -d1" (or not using
> > hdparm at all) leads to errors like the following quite fast and
> > reproducable:
> > 
> > kernel: hdb: dma_timer_expiry: dma status == 0x60
> > kernel: hdb: timeout waiting for DMA
> > kernel: hdb: timeout waiting for DMA
> > kernel: hdb: (__ide_dma_test_irq) called while not waiting
> > kernel: hdb: status error: status=0x58 { DriveReady SeekComplete
> > DataRequest } kernel:
> > kernel: hdb: drive not ready for command
> > 
> > Turning DMA off again stops these.
> > 
> > 
> > I'd love to hear any experience other people have with this mainboard
> > or even some statement if DMA is supposed to work with my setup.
> 
> I had some problems like this using 2.4.17 on a PIIX3 board (don't know the 
> board type). The problems disappeared after switching to 2.4.19. 
> Unforunately I had to change the processor and processor fan about the same 
> time.
> 
> I tend to believe that this problem was related to CPU temperature not to 
> kernel bugs. I don't have any means of measuring CPU temperature on this 
> board. But the old CPU certainly burnt out, because the fan was not 
> working too well ;-(((
> 
> -
> 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/
> 

Andre Hedrick
LAD Storage Consulting Group

Re: DMA problems w/ PIIX3 IDE, 2.4.20-pre4-ac2

[Florian Hinzmann]

On 14-Sep-2002 Andre Hedrick wrote:

> Yep I had that problem too and fixed it.
> Please try a newer pre5-acX

Problem is still there with 2.4.20-pre5-ac6:

kernel: hdd: dma_timer_expiry: dma status == 0x60
kernel: hdd: timeout waiting for DMA
kernel: hdd: timeout waiting for DMA
kernel: hdd: (__ide_dma_test_irq) called while not waiting
kernel: hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
kernel: 
kernel: hdd: drive not ready for command
kernel: blk: queue c02e50e0, I/O limit 4095Mb (mask 0xffffffff)


No high load (wether cpu or disk io) is needed for this to happen.


In my initial mail I said the machine is running stable with DMA turned off.
This is not true for latest 2.4.20pre5 kernels. When I start one or two bigger 
file copy operations it usually takes less than one minute and I get errors 
like these (running 2.4.20-pre5-ac6 for this output):

kernel: hdb: status timeout: status=0xd0 { Busy }
kernel: 
kernel: hdb: no DRQ after issuing WRITE
kernel: ide0: reset: success
kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
kernel: hdb: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=97567071, high=5, lo
kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
kernel: hdb: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=97567071, high=5, lo
kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
kernel: hdb: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=97567071, high=5, lo
kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
kernel: hdb: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=97567071, high=5, lo
kernel: ide0: reset: success
kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
kernel: hdb: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=97567071, high=5, lo
kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
kernel: hdb: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=97567071, high=5, lo
kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
kernel: hdb: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=97567071, high=5, lo
kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
kernel: hdb: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=97567071, high=5, lo
kernel: ide0: reset: success
kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
kernel: hdb: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=97567071, high=5, lo
kernel: end_request: I/O error, dev 03:41 (hdb), sector 97567008


2.4.20-pre5-ac6 does not work for me with or without DMA. Using 2.4.19 that
machine is running stable with DMA turned off. Would it be interesting to hear
wich 2.4.20-preX-acY kernel was first to break pio mode at my machine?


  Regards
      Florian



--
  Florian Hinzmann                         private: f.hinzmann@hamburg.de
                                            Debian: fh@debian.org
PGP Key / ID: 1024D/B4071A65
Fingerprint : F9AB 00C1 3E3A 8125 DD3F  DF1C DF79 A374 B407 1A65

Re: DMA problems w/ PIIX3 IDE, 2.4.20-pre4-ac2

[Alan Cox]

On Mon, 2002-09-16 at 12:17, Florian Hinzmann wrote:
> kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
> kernel: hdb: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=97567071, high=5, lo
> kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }

Which is the drive reporting a physical media error

Re: DMA problems w/ PIIX3 IDE, 2.4.20-pre4-ac2

[Florian Hinzmann]

On 16-Sep-2002 Alan Cox wrote:
> On Mon, 2002-09-16 at 12:17, Florian Hinzmann wrote:
>> kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
>> kernel: hdb: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=97567071, high=5, lo
>> kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
> 
> Which is the drive reporting a physical media error

Which seems to exist only while using the named combinations of DMA access
and kernel versions. While using i.e. 2.4.19 without DMA I can access the same data,
dd the whole disk to /dev/null or run badblock checks without finding
any physical media errors.

2.4.19 should complain, too, if there is a physical error indeed, right?


  Regards
      Florian



--
  Florian Hinzmann                         private: f.hinzmann@hamburg.de
                                            Debian: fh@debian.org
PGP Key / ID: 1024D/B4071A65
Fingerprint : F9AB 00C1 3E3A 8125 DD3F  DF1C DF79 A374 B407 1A65

Re: DMA problems w/ PIIX3 IDE, 2.4.20-pre4-ac2

[Alan Cox]

On Mon, 2002-09-16 at 15:26, Florian Hinzmann wrote:
> 
> On 16-Sep-2002 Alan Cox wrote:
> > On Mon, 2002-09-16 at 12:17, Florian Hinzmann wrote:
> >> kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
> >> kernel: hdb: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=97567071, high=5, lo
> >> kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
> > 
> > Which is the drive reporting a physical media error
> 
> Which seems to exist only while using the named combinations of DMA access
> and kernel versions. While using i.e. 2.4.19 without DMA I can access the same data,
> dd the whole disk to /dev/null or run badblock checks without finding
> any physical media errors.
> 
> 2.4.19 should complain, too, if there is a physical error indeed, right?

The "sectoridnotfound" return is from the drive. That makes it very hard
to believe it isnt a physical error

Re: DMA problems w/ PIIX3 IDE, 2.4.20-pre4-ac2

[Florian Hinzmann]

Hello Alan!


On 16-Sep-2002 Alan Cox wrote:
> On Mon, 2002-09-16 at 15:26, Florian Hinzmann wrote:
>> 
>> On 16-Sep-2002 Alan Cox wrote:
>> > On Mon, 2002-09-16 at 12:17, Florian Hinzmann wrote:
>> >> kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
>> >> kernel: hdb: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=97567071, high=5, lo
>> >> kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
>> > 
>> > Which is the drive reporting a physical media error
>> 
>> Which seems to exist only while using the named combinations of DMA access
>> and kernel versions. While using i.e. 2.4.19 without DMA I can access the same data,
>> dd the whole disk to /dev/null or run badblock checks without finding
>> any physical media errors.
>> 
>> 2.4.19 should complain, too, if there is a physical error indeed, right?
> 
> The "sectoridnotfound" return is from the drive. That makes it very hard
> to believe it isnt a physical error

This is what makes me believe it:

- I get "SectorIdNotFound" with differing sector numbers at three physical hard disk drives.
  At least two of this drives are not very old. One of them was bought only a few weeks
  ago.
- I had several occasions where I got this error while copying one given file. After rebooting
  (the same kernel with the same settings) accessing the same file was fine. 
- I can reproduce this errors starting to copy random groups of files from that disks
  within one or two minutes. That makes me think it is not one special area at the disk(s).
  On the other hand I can start several copy commands at once using the same commands
  as before without getting any errors with i.e. 2.4.19 without DMA. It is running then
  running stable for a long time (I think I tried times up to one hour).


My BIOS doesn't like disks larger than 32GB. Therefore the three disks are jumpered to
appear as 32GB (Maxtor disks) and I am using setmax resp. CONFIG_IDEDISK_STROKE to 
unclip them. 
Maybe this setup has something to do with the possibly bogus SectorIdNotFound message?


I am eager to sort this out. I would like to do the following:

- First, prove the drives don't have physical media errors. Is running "e2fsck -c" 
  sufficient? Do you have other suggestions to stress test my drives?

- Second, try hard to exclude other possible reasons for my drive returning that
  message. 
  While digging the archives I found one mail stating an old/broken/weak power supply
  caused that messages and a new one made them go away. I have already built in 
  a stronger and newer power supply - it did not change anything. 
  I changed nearly every part of that box in the past. Any ideas what else might 
  produce this errors? Too much heat? Cabling?

- Third, take a look at the software again. Is there anything I could try to help
  debugging this, i.e. trying every -ac release since 2.4.19 and find out which
  version is the first with this errors?


I would highly appreciate some guidance as I am trying to solve this for
months now and I am somehow aimless at this point.


  Regards
      Florian


--
  Florian Hinzmann                         private: f.hinzmann@hamburg.de
                                            Debian: fh@debian.org
PGP Key / ID: 1024D/B4071A65
Fingerprint : F9AB 00C1 3E3A 8125 DD3F  DF1C DF79 A374 B407 1A65

Re: DMA problems w/ PIIX3 IDE, 2.4.20-pre4-ac2

[Jan-Hinnerk Reichert]

Am Montag, 16. September 2002 16:46 schrieb Alan Cox:
> On Mon, 2002-09-16 at 15:26, Florian Hinzmann wrote:
> > On 16-Sep-2002 Alan Cox wrote:
> > > On Mon, 2002-09-16 at 12:17, Florian Hinzmann wrote:
> > >> kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete
> > >> DataRequest Error } kernel: hdb: read_intr: error=0x10 {
> > >> SectorIdNotFound }, LBAsect=97567071, high=5, lo kernel: hdb:
> > >> read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
> > >
> > > Which is the drive reporting a physical media error
> >
> > Which seems to exist only while using the named combinations of DMA
> > access and kernel versions. While using i.e. 2.4.19 without DMA I can
> > access the same data, dd the whole disk to /dev/null or run badblock
> > checks without finding any physical media errors.
> >
> > 2.4.19 should complain, too, if there is a physical error indeed, right?
>
> The "sectoridnotfound" return is from the drive. That makes it very hard
> to believe it isnt a physical error

Is the LBA sector number in the error coming from the drive?

Is the drive addressed with LBA or CHS?

Is it possible that this error occurs if the LBA (or CHS) is out of bound? 
(e.g. 40GB drive shouldn't have sector 97567071)

Re: DMA problems w/ PIIX3 IDE, 2.4.20-pre4-ac2

[Daniela Engert]

On 16 Sep 2002 15:46:35 +0100, Alan Cox wrote:

>On Mon, 2002-09-16 at 15:26, Florian Hinzmann wrote:

>> > On Mon, 2002-09-16 at 12:17, Florian Hinzmann wrote:
>> >> kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
>> >> kernel: hdb: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=97567071, high=5, lo
>> >> kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
>> > 
>> > Which is the drive reporting a physical media error
>> 
>> Which seems to exist only while using the named combinations of DMA access
>> and kernel versions. While using i.e. 2.4.19 without DMA I can access the same data,
>> dd the whole disk to /dev/null or run badblock checks without finding
>> any physical media errors.
>> 
>> 2.4.19 should complain, too, if there is a physical error indeed, right?
>
>The "sectoridnotfound" return is from the drive. That makes it very hard
>to believe it isnt a physical error

It might be a seek beyond end-of-media error as well (see ATA spec for
error reporting in this case: either ABRT or IDNF shall be set)!

Ciao,
  Dani

problem solved - late answer.. (was: Re: DMA problems w/ PIIX3 IDE, 2.4.20-pre4-ac2)

[Florian Hinzmann]

Hello!

Quite some months ago I raised some questions, got some answers and 
continued working silently until my problem was solved. While digging 
the archives for yet another IDE problem today I realized I did
not send any message to you guys nor to the list afterwards.

Just in case someone is interested or cares still:

1) Sorry for not sending a "problem solved" mail when it was solved
2) My box is running smoothly again. It was neither a kernel issue
   nor a hardware problem with the disks. Different kernel versions 
   did behave differently, but the cause of it all seems to be a broken
   CPU (or broken jumper settings). 
   Installing a new CPU made all problems go away. And the box is
   rock solid with or without IDE-DMA turned on.


    Regards
        Florian
   

P.S: A little block quoted below in case someone wants to remember what
     this was about:

On 16 Sep 2002 15:46:35 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Mon, 2002-09-16 at 15:26, Florian Hinzmann wrote:
> > 
> > On 16-Sep-2002 Alan Cox wrote:
> > > On Mon, 2002-09-16 at 12:17, Florian Hinzmann wrote:
> > >> kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
> > >> kernel: hdb: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=97567071, high=5, lo
> > >> kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
> > > 
> > > Which is the drive reporting a physical media error
> > 
> > Which seems to exist only while using the named combinations of DMA access
> > and kernel versions. While using i.e. 2.4.19 without DMA I can access the same data,
> > dd the whole disk to /dev/null or run badblock checks without finding
> > any physical media errors.
> > 
> > 2.4.19 should complain, too, if there is a physical error indeed, right?
> 
> The "sectoridnotfound" return is from the drive. That makes it very hard
> to believe it isnt a physical error
>

-- 
  Florian Hinzmann                         private: f.hinzmann@hamburg.de
                                            Debian: fh@debian.org
PGP Key / ID: 1024D/B4071A65
Fingerprint : F9AB 00C1 3E3A 8125 DD3F  DF1C DF79 A374 B407 1A65

Re: DMA problems w/ PIIX3 IDE, 2.4.20-pre4-ac2

[Russell King]

On Mon, Sep 16, 2002 at 04:26:24PM +0200, Florian Hinzmann wrote:
> 
> On 16-Sep-2002 Alan Cox wrote:
> > On Mon, 2002-09-16 at 12:17, Florian Hinzmann wrote:
> >> kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
> >> kernel: hdb: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=97567071, high=5, lo
> >> kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
> > 
> > Which is the drive reporting a physical media error
> 
> Which seems to exist only while using the named combinations of DMA access
> and kernel versions. While using i.e. 2.4.19 without DMA I can access the same data,
> dd the whole disk to /dev/null or run badblock checks without finding
> any physical media errors.

Let me get this straight.  If you run this exact procedure, what happens?

1. start with DMA turned on
2. dd the whole disk to /dev/null
3. disable DMA
4. dd the whole disk to /dev/null
5. re-enable DMA
6. dd the whole disk to /dev/null
7. disable DMA
8. dd the whole disk to /dev/null

Are you saying that steps 2 and 6 produce a sectoridnotfound error, while
step 4 and 8 works without problem?

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: DMA problems w/ PIIX3 IDE, 2.4.20-pre4-ac2

[Florian Hinzmann]

Hello!


On 14-Sep-2002 Jan-Hinnerk Reichert wrote:

> Florian Hinzmann wrote:

>> I have problems with DMA mode at one of my boxes ( more technical
>> details at the end of this mail ).
> [...] 
>> But I do issue a "hdparm -d0" for each of them at bootup currently and
>> they are running fine then. Enabling DMA with "hdparm -d1" (or not using
>> hdparm at all) leads to errors like the following quite fast and
>> reproducable:
>> 
>> kernel: hdb: dma_timer_expiry: dma status == 0x60
>> kernel: hdb: timeout waiting for DMA
>> kernel: hdb: timeout waiting for DMA
>> kernel: hdb: (__ide_dma_test_irq) called while not waiting
>> kernel: hdb: status error: status=0x58 { DriveReady SeekComplete
>> DataRequest } kernel:
>> kernel: hdb: drive not ready for command
>> 
>> Turning DMA off again stops these.
>> 
>> 
>> I'd love to hear any experience other people have with this mainboard
>> or even some statement if DMA is supposed to work with my setup.
> 
> I had some problems like this using 2.4.17 on a PIIX3 board (don't know the 
> board type). The problems disappeared after switching to 2.4.19. 
> Unforunately I had to change the processor and processor fan about the same 
> time.
> 
> I tend to believe that this problem was related to CPU temperature not to 

I don't think cpu temperature is the problem in my case. The fan is 
working well and the box is running stable with high load for hours/days
while there is no heavy disk activity. But copying files for some minutes 
kills it reliably.
But I will try to watch this more closely.  Might running the CPU with 
100MHz instead of 200MHz to keep it cooler be worth a try? I could try to 
find another CPU to put into my machine, too.


Greetings
     Florian



--
  Florian Hinzmann                         private: f.hinzmann@hamburg.de
                                            Debian: fh@debian.org
PGP Key / ID: 1024D/B4071A65
Fingerprint : F9AB 00C1 3E3A 8125 DD3F  DF1C DF79 A374 B407 1A65