From: Marcin Dalecki <dalecki@evision.ag>
To: Petr Vandrovec <VANDROVE@vc.cvut.cz>
Cc: lkml <linux-kernel@vger.kernel.org>,
axboe@suse.de, torvalds@transmeta.com
Subject: Re: IDE lockups with 2.5.28...
Date: Fri, 26 Jul 2002 12:30:08 +0200 [thread overview]
Message-ID: <3D4124B0.2060901@evision.ag> (raw)
In-Reply-To: 322E1A1760@vcnet.vc.cvut.cz
Petr Vandrovec wrote:
> Well, no. Both of these loop have completely different terminating conditions.
> You exit when IDE hardware is busy, while SCSI exits if hardware is busy,
> or when there is nothing to do. Fundamental difference.
Shit - you are right. We look until the next request sets IDE_BUSY as a
side effect.... I just wanted to close the window between clear we clear
IDE_BUSY in ata_irq_handler just before recalling do_request to set it
immediately on again.
Should be both of course.
>>Same allies to blk_stop_queue().
>
>
> So your request_fn is invoked for each of queues which had pending
> requests. Upper layer cannot expect that you are using two queues,
> but hardware really wants to use only one. Shared queue_lock is there
> for hardware which can start one request at a time (one set of
> registers...), but can have requests to the different devices
> in progress.
Yes theoretically yes. The problem is only that queue_lock doesn't as
advertized becouse the request_fn are *releasing* the spin lock at a
point where the QUEUE_FLAG_STOP doesn't have any usefull value.
> P.S.: I did not saw IDE 105. Does it exist?
I think I did send it under a wrong topic. Please look for Re:
Linux-2.5.28.
next prev parent reply other threads:[~2002-07-26 10:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-26 10:00 IDE lockups with 2.5.28 Petr Vandrovec
2002-07-26 10:30 ` Marcin Dalecki [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-07-26 10:46 Petr Vandrovec
2002-07-26 10:30 Petr Vandrovec
2002-07-26 10:31 ` Marcin Dalecki
2002-07-25 17:22 Petr Vandrovec
2002-07-26 2:09 ` Marcin Dalecki
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=3D4124B0.2060901@evision.ag \
--to=dalecki@evision.ag \
--cc=VANDROVE@vc.cvut.cz \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=martin@dalecki.de \
--cc=torvalds@transmeta.com \
/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.