Re: new Areca driver in 2.6.16-rc6-mm2 appears to be broken

From: erich
Date: Fri Mar 31 2006 - 03:33:51 EST


Dear Jens Axboe,

I have done this test as your request but it still there.
But more less.
I have modify #define ARCMSR_MAX_XFER_SECTORS 4096 => 512.
It had worked all of this morning on bonnie++ , iometer and my copy/compare test script.
All machines in my lab.do not have this message again.

Best Regards
Erich Chen


----- Original Message ----- From: "Jens Axboe" <axboe@xxxxxxx>
To: "Andrew Morton" <akpm@xxxxxxxx>
Cc: "James Bottomley" <James.Bottomley@xxxxxxxxxxxx>; <erich@xxxxxxxxxxxx>
Sent: Friday, March 31, 2006 3:42 PM
Subject: Re: new Areca driver in 2.6.16-rc6-mm2 appears to be broken



(irk, Erich wasn't in the cc, sorry to Andrew and James for getting this
mail twice)

On Thu, Mar 30 2006, Andrew Morton wrote:
"erich" <erich@xxxxxxxxxxxx> wrote:
>
> Dear Chris Caputo,
>
> Thanks you to conform this issue again, my colleague assisted me and > to
> double check my older version driver yesterday.
> and the old driver is working fine as your mention before.
>
> The ARCMSR_MAX_XFER_SECTORS is the reason why cause "attempt to access
> beyond end of device".
>
> #define ARCMSR_MAX_XFER_SECTORS
> 256 -----old
> #define ARCMSR_MAX_XFER_SECTORS
> 4096 -----new

That seems odd. ARCMSR_MAX_XFER_SECTORS just gets put into
scsi_host_template.max_sectors. Could it be a scsi core buglet?

Perhaps the larger max sectors setting is causing read-ahead to be
overly optimistic and going beyond the end? Should not happen.

Erich, can you try and shrink read-ahead on that device and retest?
Basically just do

# echo 0 > /sys/block/sdX/queue/read_ahead_kb

and see if it still complains.

--
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/