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" <[email protected]>
To: "Andrew Morton" <[email protected]>
Cc: "James Bottomley" <[email protected]>; <[email protected]>
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" <[email protected]> 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
>