On Wed, Dec 27 2000, Andrea Arcangeli wrote:
> I think right behaviour of the blkdev layer is to BUG() if the driver eats
> requests while the device is plugged.
The device is supposed to know what it's doing. Sure it defeats the
elevators work a bit, but again the driver should know best. Beside
On Wed, Nov 29, 2000 at 12:56:44PM +0100, [EMAIL PROTECTED] wrote:
>
>
> Hi,
> I experienced disk hangs with linux-2.4.0-test11 on S/390 and after
> some debugging I found the cause. It the new method of unplugging
> block devices that doesn't go along with the S/390 disk driver:
>
> /*
> * r
On Wed, Nov 29 2000, Linus Torvalds wrote:
> I would much rather actually go back to the original setup, which did
> nothing at all if the queue wasn't plugged in the first place.
But that potentially breaks devices that either don't use plugging
or alternatively implement their own, because q->p
On Wed, 29 Nov 2000, Jens Axboe wrote:
>
> I agree with your reasoning, even if the s390 behaviour is a bit
> "non-standard" wrt block devices. Linus, could you apply?
>
> --- drivers/block/ll_rw_blk.c~Wed Nov 29 15:17:33 2000
> +++ drivers/block/ll_rw_blk.c Wed Nov 29 15:18:43 2000
>
On Wed, Nov 29 2000, [EMAIL PROTECTED] wrote:
> request queue to put them on its internal queue. You could argue
> that it shouldn't dequeue request if q->plugged == 1. On the other
> hand why not, before the disk has nothing to do. Anyway the result
I agree with your reasoning, even if the s390
Hi,
I experienced disk hangs with linux-2.4.0-test11 on S/390 and after
some debugging I found the cause. It the new method of unplugging
block devices that doesn't go along with the S/390 disk driver:
/*
* remove the plug and let it rip..
*/
static inline void __generic_unplug_device(request
6 matches
Mail list logo
