On Fri, Apr 08 2005, James Bottomley wrote:
> 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)?
Just queue it with the
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-kerne
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 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).
Because any use of sdev->request_queue->queue_lo
On Thu, Apr 07 2005, James Bottomley wrote:
> 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.
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 a
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
>
On Thu, Apr 07 2005, Christoph Hellwig wrote:
> 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
>
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 refer
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 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 h
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) t
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_queu
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 pro
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, 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_q
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
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 abou
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 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;
> >
> > /*
> > *
> @@ -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
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 Ax
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
>> > 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
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 logo
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:
> On Sun, Mar 27 2005, Chris Rankin wrote:
> > [gcc-3.4.3, Linux-2.6.11-SMP, Dual P
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 to using
> the anticipatory
> scheduler instead.
>
> Cheers,
> Chris
>
> NMI Watchdog detected LOCKUP on CPU1, e
[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 to using the
anticipatory
scheduler instead.
Cheers,
Chris
NMI Watchdog detected LOCKUP on CPU1, eip c0275cc7, registers:
Modules linked in: snd_pcm_oss snd_mixer_
28 matches
Mail list logo
