From: Aniket Malatpure <aniket@sgi.com>
To: Taavo Raykoff <traykoff@snet.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.4.18 IDE channels block each other under load?
Date: Mon, 22 Jul 2002 13:08:08 -0700 [thread overview]
Message-ID: <3D3C6628.37AA6167@sgi.com> (raw)
In-Reply-To: fa.e5te67v.1s3m1qr@ifi.uio.no
Hi
In the IDE Protocol, only 1 DMA transfer can take place on the bus at
one time.
So if the IDE bus is busy doing the DMA transfer for 1 drive, the other
drive cannot receive any commands.
I guess what does happen is that the IDE driver in the kernel doesnt
distribute commands in a "fair" manner between drive 0 & drive 1. If it
receives commands for drive 0, it keeps sending those commands to the
drive 0, one after the other, without checking if there is a command for
drive 1.
A driver distributing commands in a "fair" manner would send 1 command
to drive 0, check if there is a command for drive 1, if there is, it
would send a command to drive 1, then send the next command to drive 0
and so on...
The above is a guess...would anyone care to verify?
Thanks
Aniket
Taavo Raykoff wrote:
>
> Can someone tell me what is going on here?
>
> dd if=/dev/zero of=/dev/hda bs=1024 count=1000000
>
> then in another vt:
> fdisk /dev/hdc, then immediately press "q".
>
> fdisk "hangs" for a long, long time.
> ps -aux says state of dd and fdisk are both "D"
> strace says fdisk is hanging on the close()
> /proc/interrupts tell me that ide1 (/dev/hdc) is getting no
> int activity for a long, long time. ide0 is very busy.
>
> It is not just dd/fdisk. Any intensive writes on one IDE
> channel (direct to the hd? device) seem to block any IO on
> the other device.
>
> Intel SAI2 MB, ServerWorks IDE chipset, 2.4.18, two IDE
> hard drives /dev/hda and /dev/hdc, 1024MB RAM, RH73 kernel
> build.
>
> Also seen on Promise PDCx IDE controllers hanging off the PCI.
>
> hdparm settings appear to have no influence on this behavior.
>
> Thanks,
> TR.
>
> -
> 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/
next parent reply other threads:[~2002-07-22 20:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.e5te67v.1s3m1qr@ifi.uio.no>
2002-07-22 20:08 ` Aniket Malatpure [this message]
2002-07-22 21:09 ` 2.4.18 IDE channels block each other under load? Andre Hedrick
2002-07-30 17:27 Roman Kagan
[not found] <Pine.LNX.4.33.0207221750210.22553-100000@coffee.psychology.mcmaster.ca>
2002-07-22 23:04 ` T.Raykoff
2002-07-30 16:18 ` Bill Davidsen
-- strict thread matches above, loose matches on Subject: below --
2002-06-21 14:03 Taavo Raykoff
2002-06-21 14:17 ` Roy Sigurd Karlsbakk
2002-06-21 15:14 ` T.Raykoff
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=3D3C6628.37AA6167@sgi.com \
--to=aniket@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=traykoff@snet.net \
/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.