Messages in this thread Patch in this message | | | Date | Mon, 4 Oct 2004 19:36:21 +0200 | From | Jens Axboe <> | Subject | Re: Fw: Re: 2.6.9-rc2-mm4 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |