All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vojtech Pavlik <vojtech@suse.cz>
To: Greg Ward <gward@python.net>
Cc: bugs@linux-ide.org, linux-kernel@vger.kernel.org
Subject: Re: "hde: timeout waiting for DMA": message gone, same behaviour
Date: Sat, 22 Sep 2001 10:04:51 +0200	[thread overview]
Message-ID: <20010922100451.A2229@suse.cz> (raw)
In-Reply-To: <20010921134402.A975@gerg.ca> <20010921205356.A1104@suse.cz> <20010921150806.A2453@gerg.ca> <20010921154903.A621@gerg.ca> <20010921215622.A1282@suse.cz> <20010921164304.A545@gerg.ca>
In-Reply-To: <20010921164304.A545@gerg.ca>; from gward@python.net on Fri, Sep 21, 2001 at 04:43:04PM -0400

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

  reply	other threads:[~2001-09-22  8:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-21 17:44 "hde: timeout waiting for DMA": message gone, same behaviour Greg Ward
2001-09-21 18:53 ` Vojtech Pavlik
2001-09-21 19:08   ` Greg Ward
2001-09-21 19:49     ` Greg Ward
2001-09-21 19:56       ` Vojtech Pavlik
2001-09-21 20:43         ` Greg Ward
2001-09-22  8:04           ` Vojtech Pavlik [this message]
2001-09-22 10:53             ` David Grant
2001-09-22 13:40               ` Eyal Lebedinsky
2001-09-22 15:09               ` Greg Ward
2001-09-22 15:58                 ` Alan Cox
2001-09-25 20:23                   ` Maxwell Spangler
2001-09-26  2:02                     ` David Grant
2001-09-26  2:18                       ` Maxwell Spangler
2001-09-22 20:07                 ` David Grant
2001-09-24  8:35                   ` Vojtech Pavlik
2001-09-24 18:37                     ` Eric W. Biederman
2001-09-24 22:44                       ` Vojtech Pavlik
2001-09-25  0:15                         ` Kevin P. Fleming
2001-10-01 14:03 ` Greg Ward

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010922100451.A2229@suse.cz \
    --to=vojtech@suse.cz \
    --cc=bugs@linux-ide.org \
    --cc=gward@python.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.