Re: Fw: Re: 2.6.9-rc2-mm4

[Borislav Petkov <petkov@uni-muenster.de>]

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.