"hde: timeout waiting for DMA": message gone, same behaviour

"hde: timeout waiting for DMA": message gone, same behaviour

[Greg Ward]

Having problems with an ATA/100 drive under Linux 2.4.{2,9}.

drive: Seagate Barracuda IV 80 GB (ST380021A)
motherboard: ASUS A7V (VIA Apollo KT133 chipset)
ide0, ide1: VIA VT82C686A
ide2, ide3: Promise PDC20265 (these are the ATA/100 interfaces)
  (all four IDE interfaces are right on the motherboard)

I have tried connecting the drive to both ide0 and ide2, with both a
40-conductor and 80-conductor cable.

Under 2.4.2, there was a very lengthy delay at boot time with this
output:
  Partition check:
   hda:hda: timeout waiting for DMA
  ide_dmaproc: chipset supported ide_dma_timeout func only: 14
  hda: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
  [...repeat 2 times...]
  hda: DMA disabled
  ide0: reset: success
   hda1

Eventually the system booted, but the drive was really slow (no DMA).
When I forced DMA on ("hdparm -d1 /dev/hda"), I got the same lengthy
sequence of output as I had at boot time, and eventually the kernel
turned DMA off again.

So far nothing new -- from the linux-kernel archive, I'm not the first
person to report this problem in early 2.4 kernels.

Under 2.4.9, the boot-time delay is not quite as long, but it's still
there.  And it's not nearly as noisy.  However, the end-result is the
same: DMA is disabled for this drive; it's a lot slower than an ATA/100
drive ought to be; if I force DMA back on, the first access to the drive
has another looong delay that results in the kernel turning DMA back
off.  Grumble.

This is a brand-new drive and brand-new cable.  The motherboard's only
about 9 months old.

So: is this in fact a kernel problem? or is it more likely to be a cable
problem, a motherboard problem, or a hard drive problem?

Thanks --

        Greg
-- 
Greg Ward - Linux geek                                  gward@python.net
http://starship.python.net/~gward/
Jesus Saves -- and you can too, by redeeming these valuable coupons!

Re: "hde: timeout waiting for DMA": message gone, same behaviour

[Vojtech Pavlik]

On Fri, Sep 21, 2001 at 01:44:02PM -0400, Greg Ward wrote:
> Having problems with an ATA/100 drive under Linux 2.4.{2,9}.
> 
> drive: Seagate Barracuda IV 80 GB (ST380021A)
> motherboard: ASUS A7V (VIA Apollo KT133 chipset)
> ide0, ide1: VIA VT82C686A
> ide2, ide3: Promise PDC20265 (these are the ATA/100 interfaces)
>   (all four IDE interfaces are right on the motherboard)
> 
> I have tried connecting the drive to both ide0 and ide2, with both a
> 40-conductor and 80-conductor cable.
> 
> Under 2.4.2, there was a very lengthy delay at boot time with this
> output:
>   Partition check:
>    hda:hda: timeout waiting for DMA
>   ide_dmaproc: chipset supported ide_dma_timeout func only: 14
>   hda: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
>   [...repeat 2 times...]
>   hda: DMA disabled
>   ide0: reset: success
>    hda1
> 
> Eventually the system booted, but the drive was really slow (no DMA).
> When I forced DMA on ("hdparm -d1 /dev/hda"), I got the same lengthy
> sequence of output as I had at boot time, and eventually the kernel
> turned DMA off again.
> 
> So far nothing new -- from the linux-kernel archive, I'm not the first
> person to report this problem in early 2.4 kernels.
> 
> Under 2.4.9, the boot-time delay is not quite as long, but it's still
> there.  And it's not nearly as noisy.  However, the end-result is the
> same: DMA is disabled for this drive; it's a lot slower than an ATA/100
> drive ought to be; if I force DMA back on, the first access to the drive
> has another looong delay that results in the kernel turning DMA back
> off.  Grumble.
> 
> This is a brand-new drive and brand-new cable.  The motherboard's only
> about 9 months old.
> 
> So: is this in fact a kernel problem? or is it more likely to be a cable
> problem, a motherboard problem, or a hard drive problem?

Do you have the VIA IDE support enabled?

-- 
Vojtech Pavlik
SuSE Labs

Re: "hde: timeout waiting for DMA": message gone, same behaviour

[Greg Ward]

[my ATA/100 problem]
> Under 2.4.9, the boot-time delay is not quite as long, but it's still
> there.  And it's not nearly as noisy.  However, the end-result is the
> same: DMA is disabled for this drive; it's a lot slower than an ATA/100
> drive ought to be; if I force DMA back on, the first access to the drive
> has another looong delay that results in the kernel turning DMA back
> off.  Grumble.
> 
> This is a brand-new drive and brand-new cable.  The motherboard's only
> about 9 months old.
> 
> So: is this in fact a kernel problem? or is it more likely to be a cable
> problem, a motherboard problem, or a hard drive problem?

On 21 September 2001, Vojtech Pavlik said:
> Do you have the VIA IDE support enabled?

I have tried it both ways, but I think only with 2.4.2.  I've only tried
one 2.4.9 build, and that was with CONFIG_BLK_DEV_VIA82CXXX=y.  I've
just done another build with slightly different config settings
(suggestion from Mark Hahn), but haven't tried it yet.  It still has
both the VIA and Promise (CONFIG_BLK_DEV_PDC202XX=y) support enabled.

I'll report back when I've tried this kernel build.

        Greg
-- 
Greg Ward - Linux weenie                                gward@python.net
http://starship.python.net/~gward/
If ignorance is bliss, why aren't there more happy people?

Re: "hde: timeout waiting for DMA": message gone, same behaviour

[Greg Ward]

[Vojtech Pavlik]
> Do you have the VIA IDE support enabled?

[my response]
> I have tried it both ways, but I think only with 2.4.2.  I've only tried
> one 2.4.9 build, and that was with CONFIG_BLK_DEV_VIA82CXXX=y.  I've
> just done another build with slightly different config settings
> (suggestion from Mark Hahn), but haven't tried it yet.  It still has
> both the VIA and Promise (CONFIG_BLK_DEV_PDC202XX=y) support enabled.
> 
> I'll report back when I've tried this kernel build.

Still no luck with this slightly tweaked kernel config.

Here are the relevant config variables ("grep '=y' .config", copy lines
from CONFIG_IDE to CONFIG_SCSI):

  CONFIG_IDE=y
  CONFIG_BLK_DEV_IDE=y
  CONFIG_BLK_DEV_IDEDISK=y
  CONFIG_IDEDISK_MULTI_MODE=y
  CONFIG_BLK_DEV_IDECD=y
  CONFIG_BLK_DEV_IDEPCI=y
  CONFIG_IDEPCI_SHARE_IRQ=y
  CONFIG_BLK_DEV_IDEDMA_PCI=y
  CONFIG_BLK_DEV_ADMA=y
  CONFIG_IDEDMA_PCI_AUTO=y
  CONFIG_BLK_DEV_IDEDMA=y
  CONFIG_BLK_DEV_PDC202XX=y
  CONFIG_PDC202XX_BURST=y
  CONFIG_PDC202XX_FORCE=y
  CONFIG_BLK_DEV_VIA82CXXX=y
  CONFIG_IDEDMA_AUTO=y
  CONFIG_BLK_DEV_IDE_MODES=y

Is there any point in upgrading to a kernel beyond 2.4.9?  Or has the
relevant code not been touched lately?

        Greg
-- 
Greg Ward - Python bigot                                gward@python.net
http://starship.python.net/~gward/
Do radioactive cats have 18 half-lives?

Re: "hde: timeout waiting for DMA": message gone, same behaviour

[Vojtech Pavlik]

On Fri, Sep 21, 2001 at 03:49:03PM -0400, Greg Ward wrote:

> [Vojtech Pavlik]
> > Do you have the VIA IDE support enabled?
> 
> [my response]
> > I have tried it both ways, but I think only with 2.4.2.  I've only tried
> > one 2.4.9 build, and that was with CONFIG_BLK_DEV_VIA82CXXX=y.  I've
> > just done another build with slightly different config settings
> > (suggestion from Mark Hahn), but haven't tried it yet.  It still has
> > both the VIA and Promise (CONFIG_BLK_DEV_PDC202XX=y) support enabled.
> > 
> > I'll report back when I've tried this kernel build.
> 
> Still no luck with this slightly tweaked kernel config.
> 
> Here are the relevant config variables ("grep '=y' .config", copy lines
> from CONFIG_IDE to CONFIG_SCSI):
> 
>   CONFIG_IDE=y
>   CONFIG_BLK_DEV_IDE=y
>   CONFIG_BLK_DEV_IDEDISK=y
>   CONFIG_IDEDISK_MULTI_MODE=y
>   CONFIG_BLK_DEV_IDECD=y
>   CONFIG_BLK_DEV_IDEPCI=y
>   CONFIG_IDEPCI_SHARE_IRQ=y
>   CONFIG_BLK_DEV_IDEDMA_PCI=y
>   CONFIG_BLK_DEV_ADMA=y
>   CONFIG_IDEDMA_PCI_AUTO=y
>   CONFIG_BLK_DEV_IDEDMA=y
>   CONFIG_BLK_DEV_PDC202XX=y
>   CONFIG_PDC202XX_BURST=y
>   CONFIG_PDC202XX_FORCE=y
>   CONFIG_BLK_DEV_VIA82CXXX=y
>   CONFIG_IDEDMA_AUTO=y
>   CONFIG_BLK_DEV_IDE_MODES=y
> 
> Is there any point in upgrading to a kernel beyond 2.4.9?  Or has the
> relevant code not been touched lately?

There were updates in 2.4.9-pre2 in the VIA driver, so it might be worth
trying. Also disabling CONFIG_IDEDMA_AUTO may work, but you'll get slow
performance. Afterwards, though, you can do hdparm -i /dev/hd* and cat
/proc/ide/via, which will tell us interesting information, which may
lead us further to solving the problem. Btw, what clock and multiplier
your CPU is?

-- 
Vojtech Pavlik
SuSE Labs

Re: "hde: timeout waiting for DMA": message gone, same behaviour

[Greg Ward]

On 21 September 2001, Vojtech Pavlik said:
> There were updates in 2.4.9-pre2 in the VIA driver, so it might be worth
> trying. Also disabling CONFIG_IDEDMA_AUTO may work, but you'll get slow
> performance.

OK, I've just rebooted with CONFIG_IDEDMA_AUTO not set.  Same thing
happens; kernel prints "hde: timeout waiting for DMA" at boot time,
"hdparm /dev/hde" reports DMA on, and "dd if=/dev/hde of=/dev/null
count=1" takes about 20 sec to complete.  (Hmmm: in previous builds,
the kernel would turn DMA off for me after that long DMA timeout delay.
It no longer does so.  If I "hdparm -d0 /dev/hde", then there's no
long delay on read.)

> Afterwards, though, you can do hdparm -i /dev/hd*

cthulhu:~# hdparm -i /dev/hde

/dev/hde:

 Model=ST380021A, FwRev=3.05, SerialNo=3HV03HSB
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4 
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 

> and cat /proc/ide/via

OK, but the VIA controller is ide0 and ide1, which are unused -- nothing
is connected to either one.  The only IDE device in the system right now
is the brand-new Seagate 80 GB ATA/100 drive at hde1 (on ide2, which is
controlled by the Promise chip).  So here's the kernel's picture of both
the VIA and Promise controllers:

cthulhu:~# cat /proc/ide/via 
----------VIA BusMastering IDE Configuration----------------
Driver Version:                     3.23
South Bridge:                       VIA vt82c686a
Revision:                           ISA 0x22 IDE 0x10
Highest DMA rate:                   UDMA66
BM-DMA base:                        0xd800
PCI clock:                          33MHz
Master Read  Cycle IRDY:            0ws
Master Write Cycle IRDY:            0ws
BM IDE Status Register Read Retry:  yes
Max DRDY Pulse Width:               No limit
-----------------------Primary IDE-------Secondary IDE------
Read DMA FIFO flush:          yes                 yes
End Sector FIFO flush:         no                  no
Prefetch Buffer:               no                  no
Post Write Buffer:             no                  no
Enabled:                      yes                 yes
Simplex only:                  no                  no
Cable Type:                   40w                 40w
-------------------drive0----drive1----drive2----drive3-----
Transfer Mode:        PIO       PIO       PIO       PIO
Address Setup:      120ns     120ns     120ns     120ns
Cmd Active:         480ns     480ns     480ns     480ns
Cmd Recovery:       480ns     480ns     480ns     480ns
Data Active:        330ns     330ns     330ns     330ns
Data Recovery:      270ns     270ns     270ns     270ns
Cycle Time:         600ns     600ns     600ns     600ns
Transfer Rate:    3.3MB/s   3.3MB/s   3.3MB/s   3.3MB/s
cthulhu:~# cat /proc/ide/pdc202xx 

                                PDC20265 Chipset.
------------------------------- General Status ---------------------------------
Burst Mode                           : enabled
Host Mode                            : Normal
Bus Clocking                         : 33 PCI Internal
IO pad select                        : 10 mA
Status Polling Period                : 0
Interrupt Check Status Polling Delay : 0
--------------- Primary Channel ---------------- Secondary Channel -------------
                enabled                          enabled 
66 Clocking     enabled                          disabled
           Mode PCI                         Mode PCI   
                FIFO Empty                       FIFO Empty  
--------------- drive0 --------- drive1 -------- drive0 ---------- drive1 ------
DMA enabled:    no               yes             no                no 
DMA Mode:       UDMA 4           NOTSET          NOTSET            NOTSET
PIO Mode:       PIO 4            NOTSET           NOTSET            NOTSET

> which will tell us interesting information, which may
> lead us further to solving the problem.

Well, I hope it means something to you!  

> Btw, what clock and multiplier
> your CPU is?

800 MHz Athlon.  Not sure what the multiplier is -- I don't mess with
that stuff.

        Greg
-- 
Greg Ward - Unix bigot                                  gward@python.net
http://starship.python.net/~gward/
The world is coming to an end.  Please log off.

Re: "hde: timeout waiting for DMA": message gone, same behaviour

[Vojtech Pavlik]

On Fri, Sep 21, 2001 at 04:43:04PM -0400, Greg Ward wrote:
> On 21 September 2001, Vojtech Pavlik said:
> > There were updates in 2.4.9-pre2 in the VIA driver, so it might be worth
> > trying. Also disabling CONFIG_IDEDMA_AUTO may work, but you'll get slow
> > performance.
> 
> OK, I've just rebooted with CONFIG_IDEDMA_AUTO not set.  Same thing
> happens; kernel prints "hde: timeout waiting for DMA" at boot time,
> "hdparm /dev/hde" reports DMA on, and "dd if=/dev/hde of=/dev/null
> count=1" takes about 20 sec to complete.  (Hmmm: in previous builds,
> the kernel would turn DMA off for me after that long DMA timeout delay.
> It no longer does so.  If I "hdparm -d0 /dev/hde", then there's no
> long delay on read.)
> 
> > Afterwards, though, you can do hdparm -i /dev/hd*
> 
> cthulhu:~# hdparm -i /dev/hde
> 
> /dev/hde:
> 
>  Model=ST380021A, FwRev=3.05, SerialNo=3HV03HSB
>  Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
>  RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
>  BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=16
>  CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488
>  IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
>  PIO modes: pio0 pio1 pio2 pio3 pio4 
>  DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 

Looks good, drive set to UDMA100 ...

> 
> > and cat /proc/ide/via
> 
> OK, but the VIA controller is ide0 and ide1, which are unused -- nothing
> is connected to either one.  The only IDE device in the system right now
> is the brand-new Seagate 80 GB ATA/100 drive at hde1 (on ide2, which is
> controlled by the Promise chip).

Oh, but I can't help you much with the Promise chip. I may help you get
the drive working on UDMA66 off the VIA chip, tho.

> So here's the kernel's picture of both
> the VIA and Promise controllers:
> 
> cthulhu:~# cat /proc/ide/via 
> ----------VIA BusMastering IDE Configuration----------------
> Driver Version:                     3.23
> South Bridge:                       VIA vt82c686a
> Revision:                           ISA 0x22 IDE 0x10
> Highest DMA rate:                   UDMA66
> BM-DMA base:                        0xd800
> PCI clock:                          33MHz
> Master Read  Cycle IRDY:            0ws
> Master Write Cycle IRDY:            0ws
> BM IDE Status Register Read Retry:  yes
> Max DRDY Pulse Width:               No limit
> -----------------------Primary IDE-------Secondary IDE------
> Read DMA FIFO flush:          yes                 yes
> End Sector FIFO flush:         no                  no
> Prefetch Buffer:               no                  no
> Post Write Buffer:             no                  no
> Enabled:                      yes                 yes
> Simplex only:                  no                  no
> Cable Type:                   40w                 40w
> -------------------drive0----drive1----drive2----drive3-----
> Transfer Mode:        PIO       PIO       PIO       PIO
> Address Setup:      120ns     120ns     120ns     120ns
> Cmd Active:         480ns     480ns     480ns     480ns
> Cmd Recovery:       480ns     480ns     480ns     480ns
> Data Active:        330ns     330ns     330ns     330ns
> Data Recovery:      270ns     270ns     270ns     270ns
> Cycle Time:         600ns     600ns     600ns     600ns
> Transfer Rate:    3.3MB/s   3.3MB/s   3.3MB/s   3.3MB/s

Looks OK, no drives present.

> cthulhu:~# cat /proc/ide/pdc202xx 
> 
>                                 PDC20265 Chipset.
> ------------------------------- General Status ---------------------------------
> Burst Mode                           : enabled
> Host Mode                            : Normal
> Bus Clocking                         : 33 PCI Internal
> IO pad select                        : 10 mA
> Status Polling Period                : 0
> Interrupt Check Status Polling Delay : 0
> --------------- Primary Channel ---------------- Secondary Channel -------------
>                 enabled                          enabled 
> 66 Clocking     enabled                          disabled
>            Mode PCI                         Mode PCI   
>                 FIFO Empty                       FIFO Empty  
> --------------- drive0 --------- drive1 -------- drive0 ---------- drive1 ------
> DMA enabled:    no               yes             no                no 
> DMA Mode:       UDMA 4           NOTSET          NOTSET            NOTSET
> PIO Mode:       PIO 4            NOTSET           NOTSET            NOTSET

Controller set to UDMA66. This may be a problem ...

Can you try 'hdparm -X68 -d1 /dev/hde'? This should enable UDMA66 on the
drive as well. This won't be top speed, but could work ...

> > which will tell us interesting information, which may
> > lead us further to solving the problem.
> 
> Well, I hope it means something to you!  
> 
> > Btw, what clock and multiplier
> > your CPU is?
> 
> 800 MHz Athlon.  Not sure what the multiplier is -- I don't mess with
> that stuff.

That's OK.

> -- 
> Greg Ward - Unix bigot                                  gward@python.net
> http://starship.python.net/~gward/
> The world is coming to an end.  Please log off.

-- 
Vojtech Pavlik
SuSE Labs

Re: "hde: timeout waiting for DMA": message gone, same behaviour

[David Grant]

I'm not an expert user, just someone who's been trying feeble-ly to get
Linux working for the past 3 months on my new computer.  I have a Promise
chip (PDC20265) and Via vt86c686b on my A7V133.  I get these DMA timeout
errors when I am even trying to install Linux!  I did manage to get Redhat
7.1 installed a few months ago, as well as Debian 2.2r3.  I'm not sure if
that was a fluke or not.  The only thing that I changed with my setup since
then that might have affected things, is that I upgraded the ASUS bios at
some point.  Anyways, at this point in time, no version of Linux will
install.  After the installer starts to install a few packages (sometimes
10, sometimes 100), the installer halts, the hard disk light stays on, and
if I use CTRL-ALT-F4, I see these DMA timeout errors.  The hard drive is
unresponsive unless I do a cold boot, as opossed to warm boot.

Sorry for broadcasting this across the linux kernel mailing list.  I can't
provide any lspci info., etc.. because I'm kind of new to Linux, and also,
this bug is not allowing me to install Linux period.  And BTW, Windows runs
with no problems on both IDE controllers, so I know it's not my PC.  I know
lots of people who have gotten this motherboard and similar motherboards to
work.  But I can't, and since I am just an everyday user who is trying to
run Linux on my PC, I think these bugs are important to fix.  Or at least it
needs to be made public knowledge what someone like me needs to do to get it
working.  (Although I'm not blaming anyone working on the kernel.  I can
only blame the people at Via and Promise for only been semi-cooperative with
kernel development at best).

David Grant

----- Original Message -----
From: "Vojtech Pavlik" <vojtech@suse.cz>
To: "Greg Ward" <gward@python.net>
Cc: <bugs@linux-ide.org>; <linux-kernel@vger.kernel.org>
Sent: Saturday, September 22, 2001 1:04 AM
Subject: Re: "hde: timeout waiting for DMA": message gone, same behaviour


> On Fri, Sep 21, 2001 at 04:43:04PM -0400, Greg Ward wrote:
> > On 21 September 2001, Vojtech Pavlik said:
> > > There were updates in 2.4.9-pre2 in the VIA driver, so it might be
worth
> > > trying. Also disabling CONFIG_IDEDMA_AUTO may work, but you'll get
slow
> > > performance.
> >
> > OK, I've just rebooted with CONFIG_IDEDMA_AUTO not set.  Same thing
> > happens; kernel prints "hde: timeout waiting for DMA" at boot time,
> > "hdparm /dev/hde" reports DMA on, and "dd if=/dev/hde of=/dev/null
> > count=1" takes about 20 sec to complete.  (Hmmm: in previous builds,
> > the kernel would turn DMA off for me after that long DMA timeout delay.
> > It no longer does so.  If I "hdparm -d0 /dev/hde", then there's no
> > long delay on read.)
> >

Re: "hde: timeout waiting for DMA": message gone, same behaviour

[Eyal Lebedinsky]

I had the pleasure of a visit from the DMA fairy before. I found two
things that sometimes help.

1) reorganize the PCI cards to alter the interrupt sharing. This is
   a tiresome trial-and-error process that worked for me. When you
   find a working setup, close the case and use it [1].

2) Are you using APIC? try booting "noapic" and see how it goes

[1] The good old ham radio method of fixing a radio. Poke around with
a screwdriver, pushing the bits (these was in the days of valves and
such)
around until at some point, touching some object, the problem (whistle,
noise, cracking) stops. Solder the screwdriver to that object.

--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.anu.edu.au/eyal/>

Re: "hde: timeout waiting for DMA": message gone, same behaviour

[Greg Ward]

On 22 September 2001, David Grant said:
> I'm not an expert user, just someone who's been trying feeble-ly to get
> Linux working for the past 3 months on my new computer.  I have a Promise
> chip (PDC20265) and Via vt86c686b on my A7V133.  I get these DMA timeout
> errors when I am even trying to install Linux!

A-ha, so I do not struggle alone.  That's comforting, in a way.

Most likely, you get DMA timeout errors when attempting to install Linux
for the same reason as I get them when booting: the first time Linux
tries to read the disk, it waits and waits and waits.  Depending on your
kernel version and which IDE interface you're using, it eventually gives
up... or it locks up.  (I had the lockup problem with kernel 2.4.2 and
the suspect drive on my Promise IDE interface.  On the VIA interface, it
booted eventually after ~60 sec of timeout errors.  Under 2.4.9, the
kernel doesn't take as long to timeout, and it's not as noisy as it was
under 2.4.2, but the underlying problem is still there: no DMA.)

BTW, you wouldn't happen to know which kernel version was in the Linux
distros you attempted to install, would you?  Not that it
matters... 2.4.9 doesn't work for me, and I haven't heard anyone telling
me to upgrade to the latest bleeding edge 2.4.10.preXX or 2.4.9acYY.

> [...] no version of Linux will
> install.  After the installer starts to install a few packages (sometimes
> 10, sometimes 100), the installer halts, the hard disk light stays on, and
> if I use CTRL-ALT-F4, I see these DMA timeout errors.  The hard drive is
> unresponsive unless I do a cold boot, as opossed to warm boot.

That sounds like problems I saw in the linux-kernel archive from a few
months back: intermittent, not-always-there, takes-a-while-to-manifest
DMA timeouts.  The DMA timeout I'm experiencing is always there, 100%
reliable, and manifests with the first attempt to read a sector from the
disk (the hunt for partitions).

For the record, I'm starting to suspect either a bad cable or a bad
drive.  I've had positive reports from two people with the ASUS A7V
motherboard and ATA/100 drives under Linux 2.4, so it's certainly
possible.  I just need to find someone with some redundant hardware that
I can play with.  Or get my hands on Seagate's diagnostic tool, which
they don't make terribly easy to access if you don't use Windows.
(Annoying irony: the only reason you need Windows is to run their
program that writes a floppy disk image; you then boot that disk.  But
the image is embedded in the .exe file, and they don't seem to make the
image available separately.  ARGGGHHH!!!)

        Greg
-- 
Greg Ward - just another /P(erl|ython)/ hacker          gward@python.net
http://starship.python.net/~gward/
"I know a lot about art, but I don't know what I like!"

Re: "hde: timeout waiting for DMA": message gone, same behaviour

[Alan Cox]

> up... or it locks up.  (I had the lockup problem with kernel 2.4.2 and
> the suspect drive on my Promise IDE interface.  On the VIA interface, it
> booted eventually after ~60 sec of timeout errors.  Under 2.4.9, the
> kernel doesn't take as long to timeout, and it's not as noisy as it was
> under 2.4.2, but the underlying problem is still there: no DMA.)

The timeout is it issuing DMA requests that failed. 

> > 10, sometimes 100), the installer halts, the hard disk light stays on, and
> > if I use CTRL-ALT-F4, I see these DMA timeout errors.  The hard drive is
> > unresponsive unless I do a cold boot, as opossed to warm boot.

For RH and other stuff that picked up the RH diffs (now in Linus 2.4.7+
tree or so) you can boot with the option "ide=nodma"

> drive.  I've had positive reports from two people with the ASUS A7V
> motherboard and ATA/100 drives under Linux 2.4, so it's certainly
> possible.  I just need to find someone with some redundant hardware that

Older trees take one DMA timeout and go PIO. That turns out to be bad
because very very occasionally other things (I guess drive calibration etc)
will cause the DMA to timeout.

With the 2.4.9-ac tree I have two boxes which get DMA timeouts. One of them
very very rarely and the retry recovers nicely, the other DMA does not work
and after poking around I discovered windows also disables DMA on this
mini notebook..

Re: "hde: timeout waiting for DMA": message gone, same behaviour

[David Grant]

>
> BTW, you wouldn't happen to know which kernel version was in the Linux
> distros you attempted to install, would you?  Not that it
> matters... 2.4.9 doesn't work for me, and I haven't heard anyone telling
> me to upgrade to the latest bleeding edge 2.4.10.preXX or 2.4.9acYY.

Redhat 7.1 uses 2.4.2-2 (redhat version).  Debian uses 2.2.19-pre17?
something weird like that.  Mandrake uses 2.4.8 (which I now believe had no
changes to VIA and/or Promise code).  I'm still wondering when Alan Cox's
fixes went into the Linus code.  And I'm still trying to figure out why
Alan's code is called via82cxxx, while Vojtech's is called vt82cxxx.  So
either someone renamed Alan's version back to vt82cxxx to integrate into the
main kernel tree, or it never got included???  But I know Vojtech's recent
fixes are still in the latest pre (2.4.10-pre1 I think).

So from what you are saying and what I'm saying, 2.4.8 and 2.4.9 don't work.
2.4.9 should have included Alan's fixes since he originally patched them to
2.4.6-ac5.  So his fixes don't seem to fix OUR problem.  The only hope left
might be Vojtech's changes, which are in 2.4.10-pre1.  But I doubt that
these are major changes, or else, like you say, someone would have told us
to upgrade to that kernel.

> > [...] no version of Linux will
> > install.  After the installer starts to install a few packages
(sometimes
> > 10, sometimes 100), the installer halts, the hard disk light stays on,
and
> > if I use CTRL-ALT-F4, I see these DMA timeout errors.  The hard drive is
> > unresponsive unless I do a cold boot, as opossed to warm boot.
>
> That sounds like problems I saw in the linux-kernel archive from a few
> months back: intermittent, not-always-there, takes-a-while-to-manifest
> DMA timeouts.  The DMA timeout I'm experiencing is always there, 100%
> reliable, and manifests with the first attempt to read a sector from the
> disk (the hunt for partitions).

The time that I got Linux installed (not sure how I got it installed without
a DMA timeout, probably just a fluke), it used to fail every time I booted.
Well it booted the first time, crashed a few minutes later, and then every
time I booted after that it halted while tring to fschk and repair the disk
since it was unmounted when it crashed the first time.  So I did have some
consistency there like you.

> For the record, I'm starting to suspect either a bad cable or a bad
> drive.  I've had positive reports from two people with the ASUS A7V
> motherboard and ATA/100 drives under Linux 2.4, so it's certainly
> possible.  I just need to find someone with some redundant hardware that
> I can play with.

I actually just had an idea which just came to me.  I have added a little
bit of hardware since I first started playing with Linux.  I added a network
card.  This could have been around the time that I started having trouble
installed Linux period.  And I also remember my BIOS warning me as I started
my computer, "The PCI device you just added will be sharing an IRQ with
'Promise IDE Controller'.  You must alter the BIOS settings manually if
these devices don't support IRQ sharing."  So, I could see how that could
cause my Promise to not work properly, but the VIA too?  I'm haven't done
any looking into the IRQ for the Southbridge any whether there is any
sharing.  I also added a USB webcam, but I don't think that will do
anything.

Also, if someone could explain to me personally over e-mail how Linux
handle's IRQs and stuff, that would be nice.  Specifically, I'm wondering
about something I read in the Mandrake installer guide.  It said that I
should change the BIOS setting: "Plug & Play Computer" to "No".  I currently
have had it set to "Yes," and this is what I used when I tried to install
Redhat and it used to work.  I'm just confused as to what exactly this BIOS
setting does.

Thanks,

David Grant

Re: "hde: timeout waiting for DMA": message gone, same behaviour

[Vojtech Pavlik]

On Sat, Sep 22, 2001 at 01:07:39PM -0700, David Grant wrote:
> >
> > BTW, you wouldn't happen to know which kernel version was in the Linux
> > distros you attempted to install, would you?  Not that it
> > matters... 2.4.9 doesn't work for me, and I haven't heard anyone telling
> > me to upgrade to the latest bleeding edge 2.4.10.preXX or 2.4.9acYY.
> 
> Redhat 7.1 uses 2.4.2-2 (redhat version).  Debian uses 2.2.19-pre17?
> something weird like that.  Mandrake uses 2.4.8 (which I now believe had no
> changes to VIA and/or Promise code).  I'm still wondering when Alan Cox's
> fixes went into the Linus code.  And I'm still trying to figure out why
> Alan's code is called via82cxxx, while Vojtech's is called vt82cxxx.  So
> either someone renamed Alan's version back to vt82cxxx to integrate into the
> main kernel tree, or it never got included???  But I know Vojtech's recent
> fixes are still in the latest pre (2.4.10-pre1 I think).

It's only via82cxxx, and is in quite recent versions in both the latest
Alan's and Linus's kernels ... 

> So from what you are saying and what I'm saying, 2.4.8 and 2.4.9 don't work.
> 2.4.9 should have included Alan's fixes since he originally patched them to
> 2.4.6-ac5.  So his fixes don't seem to fix OUR problem.  The only hope left
> might be Vojtech's changes, which are in 2.4.10-pre1.  But I doubt that
> these are major changes, or else, like you say, someone would have told us
> to upgrade to that kernel.

No, they only affected 686b's and newer chips.

> I actually just had an idea which just came to me.  I have added a little
> bit of hardware since I first started playing with Linux.  I added a network
> card.  This could have been around the time that I started having trouble
> installed Linux period.  And I also remember my BIOS warning me as I started
> my computer, "The PCI device you just added will be sharing an IRQ with
> 'Promise IDE Controller'.  You must alter the BIOS settings manually if
> these devices don't support IRQ sharing."  So, I could see how that could
> cause my Promise to not work properly, but the VIA too?  I'm haven't done
> any looking into the IRQ for the Southbridge any whether there is any
> sharing.  I also added a USB webcam, but I don't think that will do
> anything.
> 
> Also, if someone could explain to me personally over e-mail how Linux
> handle's IRQs and stuff, that would be nice.  Specifically, I'm wondering
> about something I read in the Mandrake installer guide.  It said that I
> should change the BIOS setting: "Plug & Play Computer" to "No".  I currently
> have had it set to "Yes," and this is what I used when I tried to install
> Redhat and it used to work.  I'm just confused as to what exactly this BIOS
> setting does.

The PnP stuff is for ISA PnP cards. If you don't have those, it's
irrelevant. When "PnP OS Installed" is set to "No", the BIOS does the
ISAPnP initialization. If it is set to "Yes", it skips that step. Linux
prefers to have the ISAPnP cards pre-initialized, though it can do it
all by itself.

-- 
Vojtech Pavlik
SuSE Labs

Re: "hde: timeout waiting for DMA": message gone, same behaviour

[Eric W. Biederman]

Vojtech Pavlik <vojtech@suse.cz> writes:

> The PnP stuff is for ISA PnP cards. If you don't have those, it's
> irrelevant. When "PnP OS Installed" is set to "No", the BIOS does the
> ISAPnP initialization. If it is set to "Yes", it skips that step. Linux
> prefers to have the ISAPnP cards pre-initialized, though it can do it
> all by itself.

"PnP OS Installed" applies to PCI as well as ISA PnP.  The rule is
something like all possible boot devices must be initialized but that
is all. 

Eric

Re: "hde: timeout waiting for DMA": message gone, same behaviour

[Vojtech Pavlik]

On Mon, Sep 24, 2001 at 12:37:32PM -0600, Eric W. Biederman wrote:

> > The PnP stuff is for ISA PnP cards. If you don't have those, it's
> > irrelevant. When "PnP OS Installed" is set to "No", the BIOS does the
> > ISAPnP initialization. If it is set to "Yes", it skips that step. Linux
> > prefers to have the ISAPnP cards pre-initialized, though it can do it
> > all by itself.
> 
> "PnP OS Installed" applies to PCI as well as ISA PnP.  The rule is
> something like all possible boot devices must be initialized but that
> is all. 

Well, I know of no BIOS that would, with PnP OS Installed set to Yes not
configure all PCI cards in the system.

-- 
Vojtech Pavlik
SuSE Labs

Re: "hde: timeout waiting for DMA": message gone, same behaviour

[Kevin P. Fleming]

I have multiple machines here that do exactly that. If "PNP OS" is set to
_Yes_, only possible boot devices are initialized. When I boot a machine
with good ol'd DOS (to use Symantec Ghost), the network cards are unusable
unless PNP OS is set to No, because no interrupt has been assigned. And yes,
these are PCI network cards.

----- Original Message -----
From: "Vojtech Pavlik" <vojtech@suse.cz>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "David Grant" <davidgrant79@hotmail.com>; "Greg Ward"
<gward@python.net>; <bugs@linux-ide.org>; <linux-kernel@vger.kernel.org>
Sent: Monday, September 24, 2001 3:44 PM
Subject: Re: "hde: timeout waiting for DMA": message gone, same behaviour


> On Mon, Sep 24, 2001 at 12:37:32PM -0600, Eric W. Biederman wrote:
>
> > > The PnP stuff is for ISA PnP cards. If you don't have those, it's
> > > irrelevant. When "PnP OS Installed" is set to "No", the BIOS does the
> > > ISAPnP initialization. If it is set to "Yes", it skips that step.
Linux
> > > prefers to have the ISAPnP cards pre-initialized, though it can do it
> > > all by itself.
> >
> > "PnP OS Installed" applies to PCI as well as ISA PnP.  The rule is
> > something like all possible boot devices must be initialized but that
> > is all.
>
> Well, I know of no BIOS that would, with PnP OS Installed set to Yes not
> configure all PCI cards in the system.
>
> --
> Vojtech Pavlik
> SuSE Labs
> -
> 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/
>
>
>

Re: "hde: timeout waiting for DMA": message gone, same behaviour

[Maxwell Spangler]

[deleted information about ide DMA timeouts and alan writes:]

On Sat, 22 Sep 2001, Alan Cox wrote:
> The timeout is it issuing DMA requests that failed.

> Older trees take one DMA timeout and go PIO. That turns out to be bad
> because very very occasionally other things (I guess drive calibration etc)
> will cause the DMA to timeout.
>
> With the 2.4.9-ac tree I have two boxes which get DMA timeouts. One of them
> very very rarely and the retry recovers nicely, the other DMA does not work
> and after poking around I discovered windows also disables DMA on this
> mini notebook..

I have an otherwise rock solid system which has been experiencing DMA timeouts
for some time.  This is a Tyan Tiger100 (Intel BX chipset) with two PII-400Mhz
processors, 512M Corsair RAM, at least one Promise Ultra66 or Ultra100
controller, and two IBM Deskstar drives.

When it runs, it runs well, but occasionally I'll find this in the logs.  This
hsould be 2.2.8:

Sep 13 22:19:50 tyan kernel: hde: timeout waiting for DMA
Sep 13 22:19:52 tyan kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14
Sep 13 22:19:52 tyan kernel: hde: irq timeout: status=0x50 { DriveReady SeekComplete }
Sep 13 22:20:12 tyan kernel: hde: timeout waiting for DMA
Sep 13 22:20:13 tyan kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14
Sep 13 22:20:13 tyan kernel: hde: irq timeout: status=0x50 { DriveReady SeekComplete }
Sep 13 22:20:34 tyan kernel: hde: timeout waiting for DMA
Sep 13 22:20:35 tyan kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14
Sep 13 22:20:35 tyan kernel: hde: irq timeout: status=0x50 { DriveReady SeekComplete }
Sep 13 22:20:56 tyan kernel: hde: timeout waiting for DMA
Sep 13 22:20:56 tyan kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14
Sep 13 22:20:56 tyan kernel: hde: irq timeout: status=0x50 { DriveReady SeekComplete }
Sep 13 22:20:59 tyan kernel: hde: DMA disabled
Sep 13 22:20:59 tyan kernel: ide2: reset: success
Sep 14 04:02:19 tyan kernel: hdg: timeout waiting for DMA
Sep 14 04:02:20 tyan kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14
Sep 14 04:02:20 tyan kernel: hdg: irq timeout: status=0x50 { DriveReady SeekComplete }
Sep 14 04:02:29 tyan kernel: hde: lost interrupt
Sep 14 04:02:41 tyan kernel: hdg: timeout waiting for DMA
Sep 14 04:02:42 tyan kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14
Sep 14 04:02:42 tyan kernel: hdg: irq timeout: status=0x50 { DriveReady SeekComplete }
Sep 14 04:03:03 tyan kernel: hdg: timeout waiting for DMA
Sep 14 04:03:04 tyan kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14
Sep 14 04:03:04 tyan kernel: hdg: irq timeout: status=0x50 { DriveReady SeekComplete }
Sep 14 04:03:13 tyan kernel: hde: lost interrupt
Sep 14 04:03:25 tyan kernel: hdg: timeout waiting for DMA
Sep 14 04:03:25 tyan kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14
Sep 14 04:03:25 tyan kernel: hdg: irq timeout: status=0x50 { DriveReady SeekComplete }
Sep 14 04:03:25 tyan kernel: hdg: DMA disabled
Sep 14 04:03:26 tyan kernel: ide3: reset: success
Sep 14 04:04:17 tyan kernel: hde: status error: status=0x58 { DriveReady SeekComplete DataRequest }
Sep 14 04:04:17 tyan kernel: hde: drive not ready for command
Sep 14 04:04:34 tyan kernel: hde: status error: status=0x58 { DriveReady SeekComplete DataRequest }
Sep 14 04:04:34 tyan kernel: hde: drive not ready for command
Sep 14 04:04:42 tyan kernel: hdg: status error: status=0x58 { DriveReady SeekComplete DataRequest }
Sep 14 04:04:42 tyan kernel: hdg: drive not ready for command
Sep 14 10:20:33 tyan kernel: hde: irq timeout: status=0xd0 { Busy }
Sep 14 10:20:34 tyan kernel: ide2: reset: success

I've regularly found this occuring at 4AM.  Anybody have any idea why?
Perhaps the drive is sleeping due to no other activity and sudenly the cron
activities attempt to use the drive before it's ready?

A reboot resets my system to happy operation but it happens again some hours
or days later.

I'm on 2.2.10 now--wondering if the behaviour to retry DMA timeouts more than
once is in my kernel?

Nice to see someone else is having this problem other than me.

fyi:

[root@tyan /root]# lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev
03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev
03)
00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:11.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
00:12.0 Unknown mass storage controller: Promise Technology, Inc. 20262 (rev
01)
00:13.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 02)
00:14.0 SCSI storage controller: BusLogic BT-946C (BA80C30) [MultiMaster 10]
(rev 08)
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 82)

-------------------------------------------------------------------------------
Maxwell Spangler
Program Writer
Greenbelt, Maryland, U.S.A.
Washington D.C. Metropolitan Area

Re: "hde: timeout waiting for DMA": message gone, same behaviour

[David Grant]

Those messages are almost identical to the ones I get.  Except it happens to
me when I try to install Linux.  Just curious, Max, when did this start
happening?  You say it's an otherwise rock solid system, but was there ever
a time when it didn't do this?  Some people have suspected (with my system)
that the problem may come from IRQ sharing problems.  It looks like Max
isn't using any IRQ sharing with his Promise card, but he is with his Intel
on-board IDE controller, from the lspci listing.  So my other question for
Max is, where are your two hard drives connected to???  I hope I don't sound
completely like I don't know what I'm talking about.

David Grant

>
> Sep 13 22:19:50 tyan kernel: hde: timeout waiting for DMA
> Sep 13 22:19:52 tyan kernel: ide_dmaproc: chipset supported
ide_dma_timeout func only: 14
> Sep 13 22:19:52 tyan kernel: hde: irq timeout: status=0x50 { DriveReady
SeekComplete }
> Sep 13 22:20:12 tyan kernel: hde: timeout waiting for DMA
> Sep 13 22:20:13 tyan kernel: ide_dmaproc: chipset supported
ide_dma_timeout func only: 14
> Sep 13 22:20:13 tyan kernel: hde: irq timeout: status=0x50 { DriveReady
SeekComplete }
> Sep 13 22:20:34 tyan kernel: hde: timeout waiting for DMA
> Sep 13 22:20:35 tyan kernel: ide_dmaproc: chipset supported
ide_dma_timeout func only: 14
> Sep 13 22:20:35 tyan kernel: hde: irq timeout: status=0x50 { DriveReady
SeekComplete }
> Sep 13 22:20:56 tyan kernel: hde: timeout waiting for DMA
> Sep 13 22:20:56 tyan kernel: ide_dmaproc: chipset supported
ide_dma_timeout func only: 14
> Sep 13 22:20:56 tyan kernel: hde: irq timeout: status=0x50 { DriveReady
SeekComplete }
> Sep 13 22:20:59 tyan kernel: hde: DMA disabled
> Sep 13 22:20:59 tyan kernel: ide2: reset: success
> Sep 14 04:02:19 tyan kernel: hdg: timeout waiting for DMA
> Sep 14 04:02:20 tyan kernel: ide_dmaproc: chipset supported
ide_dma_timeout func only: 14
> Sep 14 04:02:20 tyan kernel: hdg: irq timeout: status=0x50 { DriveReady
SeekComplete }
> Sep 14 04:02:29 tyan kernel: hde: lost interrupt
> Sep 14 04:02:41 tyan kernel: hdg: timeout waiting for DMA
> Sep 14 04:02:42 tyan kernel: ide_dmaproc: chipset supported
ide_dma_timeout func only: 14
> Sep 14 04:02:42 tyan kernel: hdg: irq timeout: status=0x50 { DriveReady
SeekComplete }
> Sep 14 04:03:03 tyan kernel: hdg: timeout waiting for DMA
> Sep 14 04:03:04 tyan kernel: ide_dmaproc: chipset supported
ide_dma_timeout func only: 14
> Sep 14 04:03:04 tyan kernel: hdg: irq timeout: status=0x50 { DriveReady
SeekComplete }
> Sep 14 04:03:13 tyan kernel: hde: lost interrupt
> Sep 14 04:03:25 tyan kernel: hdg: timeout waiting for DMA
> Sep 14 04:03:25 tyan kernel: ide_dmaproc: chipset supported
ide_dma_timeout func only: 14
> Sep 14 04:03:25 tyan kernel: hdg: irq timeout: status=0x50 { DriveReady
SeekComplete }
> Sep 14 04:03:25 tyan kernel: hdg: DMA disabled
> Sep 14 04:03:26 tyan kernel: ide3: reset: success
> Sep 14 04:04:17 tyan kernel: hde: status error: status=0x58 { DriveReady
SeekComplete DataRequest }
> Sep 14 04:04:17 tyan kernel: hde: drive not ready for command
> Sep 14 04:04:34 tyan kernel: hde: status error: status=0x58 { DriveReady
SeekComplete DataRequest }
> Sep 14 04:04:34 tyan kernel: hde: drive not ready for command
> Sep 14 04:04:42 tyan kernel: hdg: status error: status=0x58 { DriveReady
SeekComplete DataRequest }
> Sep 14 04:04:42 tyan kernel: hdg: drive not ready for command
> Sep 14 10:20:33 tyan kernel: hde: irq timeout: status=0xd0 { Busy }
> Sep 14 10:20:34 tyan kernel: ide2: reset: success
>

[root@tyan /root]# lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
(rev
03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev
03)
00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:11.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
00:12.0 Unknown mass storage controller: Promise Technology, Inc. 20262 (rev
01)
00:13.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 02)
00:14.0 SCSI storage controller: BusLogic BT-946C (BA80C30) [MultiMaster 10]
(rev 08)
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev
82)

Re: "hde: timeout waiting for DMA": message gone, same behaviour

[Maxwell Spangler]

On Tue, 25 Sep 2001, David Grant wrote:

> Those messages are almost identical to the ones I get.  Except it happens to
> me when I try to install Linux.  Just curious, Max, when did this start
> happening?

I'd like to say when I started using Andre Hedrick unified EIDE driver a long
time ago in order to use the Promise cards, but I'm not sure about this.

I'm no kernel guy, but I suspect this is simply a case when the drive isn't
ready for a command and the driver is not capable of waiting for it or
preparing it to be ready--it's just trying, failing and moving on.

The system is still useable, but I want to work in DMA mode--can't afford to
give up the CPU time working in PIO mode.

>  You say it's an otherwise rock solid system, but was there ever
> a time when it didn't do this?

No archive of logs to go through, but I do believe there was a time when I
didn't get this.. 2.2 kernels with the onboard PIIX4 controller and without
the unified EIDE driver..?  Hard to say--a while ago at least.

>  Some people have suspected (with my system)
> that the problem may come from IRQ sharing problems.  It looks like Max
> isn't using any IRQ sharing with his Promise card, but he is with his Intel
> on-board IDE controller, from the lspci listing.

[maxwell@tyan /proc]$ cat interrupts
           CPU0       CPU1
  0:    4590063    5120609    IO-APIC-edge  timer
  1:      18970      19924    IO-APIC-edge  keyboard
  2:          0          0          XT-PIC  cascade
  8:          0          1    IO-APIC-edge  rtc
 15:       8538       8467    IO-APIC-edge  ide1
 16:       3035       3139   IO-APIC-level  BusLogic BT-958
 17:    2545359    2636066   IO-APIC-level  eth0
 18:     122943     123120   IO-APIC-level  ide2, ide3
 19:      86785      89530   IO-APIC-level  es1371, usb-uhci
NMI:          0          0
LOC:    9710744    9710742
ERR:          0
MIS:          0

>  So my other question for
> Max is, where are your two hard drives connected to???  I hope I don't sound
> completely like I don't know what I'm talking about.

# dmesg (edited):

Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100%% native mode: will probe irqs later
    ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
PDC20262: IDE controller on PCI bus 00 dev 90
PDC20262: chipset revision 1
PDC20262: not 100%% native mode: will probe irqs later
PDC20262: ROM enabled at 0xfebd0000
PDC20262: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
    ide2: BM-DMA at 0xef00-0xef07, BIOS settings: hde:DMA, hdf:pio
    ide3: BM-DMA at 0xef08-0xef0f, BIOS settings: hdg:DMA, hdh:pio
hdc: ATAPI CD-ROM DRIVE 40X MAXIMUM, ATAPI CD/DVD-ROM drive
hde: IBM-DJNA-372200, ATA DISK drive
hdg: IBM-DPTA-372050, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0xefe0-0xefe7,0xeff2 on irq 18
ide3 at 0xefa8-0xefaf,0xefa6 on irq 18
hde: 44150400 sectors (22605 MB) w/1966KiB Cache, CHS=43800/16/63, UDMA(33)
hdg: 40088160 sectors (20525 MB) w/1961KiB Cache, CHS=39770/16/63, UDMA(66)
hdc: ATAPI 40X CD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Partition check:
 hde: [PTBL] [2748/255/63] hde1 hde2 hde3 < hde5 hde6 hde7 hde8 hde9 >
 hdg: hdg1

My EIDE cdrom is on the onbard PIIX4 controller, part of the BX chipset, and
my two 22 and 20G IBM drives are on the Promise Ultra66 controller's primary
and secondary channels as masters--no slaves on either channel.

fwiw:

[root@tyan /root]# hdparm -v /dev/hde

/dev/hde:
 multcount    = 16 (on)
 I/O support  =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 nowerr       =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 2748/255/63, sectors = 44150400, start = 0
[root@tyan /root]# hdparm -v /dev/hdg

/dev/hdg:
 multcount    = 16 (on)
 I/O support  =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 nowerr       =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 39770/16/63, sectors = 40088160, start = 0
[root@tyan /root]#

I don't mess with these much.. Anybody want to suggest anything, I'll try it,
but I'm happy with moderate performance that's reliable...

-------------------------------------------------------------------------------
Maxwell Spangler
Program Writer
Greenbelt, Maryland, U.S.A.
Washington D.C. Metropolitan Area

Re: "hde: timeout waiting for DMA": message gone, same behaviour

[Greg Ward]

On 21 September 2001, I said:
> Having problems with an ATA/100 drive under Linux 2.4.{2,9}.
[...]
>   Partition check:
>    hda:hda: timeout waiting for DMA
>   ide_dmaproc: chipset supported ide_dma_timeout func only: 14
>   hda: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
>   [...repeat 2 times...]
>   hda: DMA disabled
>   ide0: reset: success
>    hda1

After a lengthy thread with many helpful tips from lots of people, I
have resolved this problem.  It was a bad hard drive after all.  I tried
the drive in two separate computers, with four operating systems (Linux,
Windows 98, MS-DOS, and DR-DOS).
  * Linux had the problems described ("DMA timeout" message)
  * Windows 98 didn't complain or have lengthy timeouts, but it
    turned DMA off on the drive in question
  * MS-DOS (version 5.0 and 6.22, booted from a floppy) crashed cold on
    bootup -- probably as soon as it tried to read the MBR of the disk
  * DR-DOS didn't complain or crash

In my humble estimation, Linux 2.4.9 and 2.4.10 deal with this "DMA
timeout" problem about as well as can be expected.  One revision the
kernel IDE folks might consider is that, as soon as a DMA timeout is
detected, turn off DMA on the affected drive.  This is what Linux 2.4.2
did, and it at least avoided repeating the lengthy timeout delays I
experienced with 2.4.2 on bootup.  With 2.4.9/10, the timeout delay
repeated every time I accessed the drive until I explicitly turned DMA
off with "hdparm -d0".

Many thanks to all who had suggestions and ideas.  I love the Linux
community, almost as much as I hate flaky hardware.  ;-)

        Greg
-- 
Greg Ward - programmer-at-large                         gward@python.net
http://starship.python.net/~gward/
Life is too short for ordinary music.