Re: Fw: Re: 2.6.9-rc2-mm4

[Jens Axboe]

On Mon, Oct 04 2004, Borislav Petkov wrote:
> Ok here we go,
> 
> final results:
> 
>  2.6.8-rc1: OK
>  2.6.8-rc2: OK
>  2.6.8-rc3: OK
>  2.6.8-rc3-bk1: OK
>  2.6.8-rc3-bk2: OK
>  2.6.8-rc3-bk3: OK
>  2.6.8-rc3-bk4: OK
>  2.6.8-rc4: BUG!
> 
> So, assuming that everything went fine during testing, the bug got introduced 
> in the transition between 2.6.8-rc3-bk4 and 2.6.8-rc4.

That's some nice testing, thank you. Try backing out this hunk:

diff -urp linux-2.6.8-rc3-bk4/drivers/block/scsi_ioctl.c linux-2.6.8-rc4/drivers/block/scsi_ioctl.c
--- linux-2.6.8-rc3-bk4/drivers/block/scsi_ioctl.c	2004-08-03 23:28:51.000000000 +0200
+++ linux-2.6.8-rc4/drivers/block/scsi_ioctl.c	2004-08-10 04:24:08.000000000 +0200
@@ -90,7 +90,7 @@ static int sg_set_reserved_size(request_
 	if (size < 0)
 		return -EINVAL;
 	if (size > (q->max_sectors << 9))
-		return -EINVAL;
+		size = q->max_sectors << 9;
 
 	q->sg_reserved_size = size;
 	return 0;

It's the only thing that sticks out, and it could easily explain it if
your cd ripper starts issuing requests that are too big. Maybe even add
a printk() here, so it will look like this in the kernel you test:

	if (size > (q->sectors << 9)) {
		printk("%u rejected\n", size);
		return -EINVAL;
	}

to verify.

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/