On Thu, 2005-04-07 at 16:45 +0200, Jens Axboe wrote:
So clear -request_queue instead.
Will do. Did you want me to look after your patch and add this, or do
you want to send it to Linus (after the purdah is over)?
James
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
On Wed, Apr 06 2005, James Bottomley wrote:
On Wed, 2005-04-06 at 21:08 +0200, Jens Axboe wrote:
I think the correct model for all of this is that the block driver
shouldn't care (or be tied to) the scsi one. Thus, as long as SCSI can
reject requests from a queue whose device has been
On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote:
On Wed, Apr 06 2005, James Bottomley wrote:
My proposal is to correct this by moving the data back to the correct
object, and make any object using it hold a reference, so this would
make the provider of the block request_fn hold a
On Thu, Apr 07, 2005 at 09:18:38AM -0400, James Bottomley wrote:
On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote:
On Wed, Apr 06 2005, James Bottomley wrote:
My proposal is to correct this by moving the data back to the correct
object, and make any object using it hold a reference, so
On Thu, Apr 07 2005, James Bottomley wrote:
On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote:
On Wed, Apr 06 2005, James Bottomley wrote:
My proposal is to correct this by moving the data back to the correct
object, and make any object using it hold a reference, so this would
make
On Thu, 2005-04-07 at 14:22 +0100, Christoph Hellwig wrote:
Do we really need the sdev_lock pointer? There's just a single place
where we're using it and the code would be much more clear if it had just
one name.
Humour me for a while. I don't believe we have any way the lock can be
used
On Thu, Apr 07 2005, James Bottomley wrote:
On Thu, 2005-04-07 at 15:32 +0200, Jens Axboe wrote:
I think Christophs point is that why add sdev_lock as a pointer, instead
of just killing it? It's only used in one location, so it's not really
that confusing (and a comment could fix that).
On Tue, Mar 29 2005, Jens Axboe wrote:
On Tue, Mar 29 2005, Chris Rankin wrote:
I have one IDE hard disc, but I was using a USB memory stick at one
point. (Notice the usb-storage and vfat modules in my list.) Could
that be the troublesome SCSI device?
--- Jens Axboe [EMAIL
@@ -324,6 +334,7 @@
issue_flush_fn *issue_flush_fn;
prepare_flush_fn*prepare_flush_fn;
end_flush_fn*end_flush_fn;
+ release_queue_data_fn *release_queue_data_fn;
/*
* Auto-unplugging state
where does this function method
Jens Axboe wrote:
On Wed, Apr 06 2005, Arjan van de Ven wrote:
@@ -324,6 +334,7 @@
issue_flush_fn *issue_flush_fn;
prepare_flush_fn*prepare_flush_fn;
end_flush_fn*end_flush_fn;
+ release_queue_data_fn *release_queue_data_fn;
/*
On Tue, 2005-03-29 at 14:03 +0200, Jens Axboe wrote:
It is quite a serious problem, not just for CFQ. SCSI referencing is
badly broken there.
OK ... I accept that with regard to the queue lock.
However, rather than trying to work out a way to tie all the refcounted
objects together, what about
On Wed, Apr 06 2005, James Bottomley wrote:
On Tue, 2005-03-29 at 14:03 +0200, Jens Axboe wrote:
It is quite a serious problem, not just for CFQ. SCSI referencing is
badly broken there.
OK ... I accept that with regard to the queue lock.
It is much deeper than that. The recent hack to
On Wed, Apr 06 2005, Tejun Heo wrote:
Jens Axboe wrote:
On Wed, Apr 06 2005, Arjan van de Ven wrote:
@@ -324,6 +334,7 @@
issue_flush_fn *issue_flush_fn;
prepare_flush_fn*prepare_flush_fn;
end_flush_fn*end_flush_fn;
+ release_queue_data_fn
On Wed, 2005-04-06 at 19:58 +0200, Jens Axboe wrote:
I rather like the queue lock being a pointer, so you can share at
whatever level you want. Lets not grow the request_queue a full lock
just to work around a bug elsewhere.
I'm not proposing that it not be a pointer, merely that it could be
On Wed, Apr 06 2005, James Bottomley wrote:
On Wed, 2005-04-06 at 19:58 +0200, Jens Axboe wrote:
I rather like the queue lock being a pointer, so you can share at
whatever level you want. Lets not grow the request_queue a full lock
just to work around a bug elsewhere.
I'm not proposing
Tejun Heo [EMAIL PROTECTED] wrote:
Jens Axboe wrote:
On Wed, Apr 06 2005, Arjan van de Ven wrote:
@@ -324,6 +334,7 @@
issue_flush_fn *issue_flush_fn;
prepare_flush_fn*prepare_flush_fn;
end_flush_fn*end_flush_fn;
+ release_queue_data_fn
On Wed, 2005-04-06 at 21:08 +0200, Jens Axboe wrote:
I think the correct model for all of this is that the block driver
shouldn't care (or be tied to) the scsi one. Thus, as long as SCSI can
reject requests from a queue whose device has been released (without
checking the device) then
On Tue, Mar 29 2005, Chris Rankin wrote:
(please don't top post)
--- Jens Axboe [EMAIL PROTECTED] wrote:
On Sun, Mar 27 2005, Chris Rankin wrote:
[gcc-3.4.3, Linux-2.6.11-SMP, Dual P4 Xeon with HT enabled]
Hi,
My Linux 2.6.11 box oopsed when I tried to logout. I have switched
I have one IDE hard disc, but I was using a USB memory stick at one
point. (Notice the usb-storage and vfat modules in my list.) Could
that be the troublesome SCSI device?
--- Jens Axboe [EMAIL PROTECTED] wrote:
Yes, it probably is. What happens is that you insert the stick and do io
On Tue, Mar 29 2005, Chris Rankin wrote:
I have one IDE hard disc, but I was using a USB memory stick at one
point. (Notice the usb-storage and vfat modules in my list.) Could
that be the troublesome SCSI device?
--- Jens Axboe [EMAIL PROTECTED] wrote:
Yes, it probably is. What
20 matches
Mail list logo
