Messages in this thread | | | From | Borislav Petkov <> | Subject | Re: Fw: Re: 2.6.9-rc2-mm4 | Date | Mon, 4 Oct 2004 22:12:31 +0200 |
| |
On Monday 04 October 2004 19:36, Jens Axboe wrote: > 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.
Yeah, that was it. Two lines in the log:
Oct 4 22:07:04 zmei kernel: 3145728 rejected Oct 4 22:07:04 zmei kernel: 3145728 rejected
Hmm, so this means that my dvd drive is sending too big requests. What do we do: firmware upgrade?
Regards, Boris. - 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/
| |