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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
