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

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

[erich]

Dear Chris Caputo,

Could you tell me about the file system of testing volume on bonnie++ ?
Does this issue come from different driver update?
I had done more two weeks of long time testing on three machines with 
bonnie++ and iometer benchmark utility.
I have not got this phenomena in ext3 file system and reiserfs filesystem.
But I can reproduce this message immediately on large file "900MB" copy from 
ARECA RAID volume format with ext2 file system.
The ext2 file system seem have this bug after linux kernel version 2.6.3.
I do same operation at linux 2.6.3 , it works fine.
Now I am researching the files system kernel source, I hope you can help me 
to clear up the issue that what's happen with it

Best Regartds
Erich Chen
----- Original Message ----- 
From: "Chris Caputo" <ccaputo@alt.net>
To: "Erich Chen" <erich@areca.com.tw>
Sent: Wednesday, March 22, 2006 7:45 AM
Subject: new Areca driver in 2.6.16-rc6-mm2 appears to be broken


> Erich,
>
> The new Areca driver in 2.6.16-rc6-mm2 is broken as far as I can tell.
>
> I applied the Areca driver in Linux 2.6.16-rc6-mm2 to a 2.6.15.6 as
> follows:
>
>  cd /usr/src
>  wget 
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc6/2.6.16-rc6-mm2/broken-out/areca-raid-linux-scsi-driver.patch
>  wget 
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc6/2.6.16-rc6-mm2/broken-out/areca-raid-linux-scsi-driver-update4.patch
>  cd /usr/src/linux
>  cat ../areca-raid-linux-scsi-driver.patch | patch -p1
>  cat ../areca-raid-linux-scsi-driver-update4.patch | patch -p1
>
> After compiling a new 2.6.15.6 kernel with the driver I was able to boot
> and things appeared fine until I ran a bonnie++ test.  During the test the
> following started spewing endlessly and the system was unusable:
>
>  ...
>  attempt to access beyond end of device
>  sdb1: rw=0, want=134744080, limit=128002016
>  attempt to access beyond end of device
>  sdb1: rw=0, want=134744080, limit=128002016
>  attempt to access beyond end of device
>  sdb1: rw=0, want=134744080, limit=128002016
>  attempt to access beyond end of device
>  sdb1: rw=0, want=134744080, limit=128002016
>  attempt to access beyond end of device
>  sdb1: rw=0, want=134744080, limit=128002016
>  attempt to access beyond end of device
>  sdb1: rw=0, want=134744080, limit=128002016
>  attempt to access beyond end of device
>  sdb1: rw=0, want=134744080, limit=128002016
>  ...
>
> When only "areca-raid-linux-scsi-driver.patch" is used, the system works
> fine for bonnie++ tests and general usage.
>
> The system is as follows:
>
>  AMD Opteron 280 dual-core 2.4ghz.  Revision E6, 256KB L1, 2048KB L2.
>  SuperMicro H8DAE (rev 1.11)
>  8 gigabytes (4 * 2GB PC3200/DDR400 REG ECC)
>  Areca Tekram ARC-1160ML SATAII 16-port multi-lane with 256 megs RAM
>  Areca ARC-6120 Battery Backup Module
>  Four (4) Seagate ST3250823AS 250GB
>  Twelve (12) Western Digital WD2500JD 250GB
>
> Info on the RAID config is below.
>
> Please let me know how I can assist.
>
> Thank you,
> Chris Caputo
>
> ---
>
> # areca rsf info
> Num Name             Disks TotalCap  FreeCap DiskChannels       State
> ===============================================================================
> 1  Raid Set # 00       14 3500.0GB    0.0GB FG3456789ABCDE     Normal
> ===============================================================================
> GuiErrMsg<0x00>: Success.
>
> # areca vsf info
> # Name             Raid# Level   Capacity Ch/Id/Lun  State
> ===============================================================================
> 1 ARC-1160-VOL#00    1   Raid0+1   19.0GB 00/00/00   Normal
> 2 ARC-1160-VOL#01    1   Raid0+1 1731.0GB 00/01/00   Normal
> ===============================================================================
> GuiErrMsg<0x00>: Success.
>
> # areca disk info
> Ch   ModelName        Serial#          FirmRev     Capacity  State
> ===============================================================================
> 1   ST3250823AS      4ND1JKDW         3.03         250.1GB  HotSpare
> 2   ST3250823AS      4ND1HEKE         3.03         250.1GB  HotSpare
> 3   ST3250823AS      4ND1DEFN         3.03         250.1GB  RaidSet 
> Member(1)
> 4   ST3250823AS      4ND1E37B         3.03         250.1GB  RaidSet 
> Member(1)
> 5   WDC WD2500JD-00  WD-WMAEH1416638  02.05D02     250.1GB  RaidSet 
> Member(1)
> 6   WDC WD2500JD-00  WD-WMAEH1415477  02.05D02     250.1GB  RaidSet 
> Member(1)
> 7   WDC WD2500JD-00  WD-WMAEH1408943  02.05D02     250.1GB  RaidSet 
> Member(1)
> 8   WDC WD2500JD-00  WD-WMAEH1428940  02.05D02     250.1GB  RaidSet 
> Member(1)
> 9   WDC WD2500JD-00  WD-WMAEH1416508  02.05D02     250.1GB  RaidSet 
> Member(1)
> 10   WDC WD2500JD-00  WD-WMAEH1416317  02.05D02     250.1GB  RaidSet 
> Member(1)
> 11   WDC WD2500JD-00  WD-WMAEH1596552  02.05D02     250.1GB  RaidSet 
> Member(1)
> 12   WDC WD2500SD-01  WD-WMAL71480351  08.02D08     250.1GB  RaidSet 
> Member(1)
> 13   WDC WD2500JD-00  WD-WMAEH1408933  02.05D02     250.1GB  RaidSet 
> Member(1)
> 14   WDC WD2500JD-00  WD-WMAEH1398573  02.05D02     250.1GB  RaidSet 
> Member(1)
> 15   WDC WD2500JD-00  WD-WMAEH1409027  02.05D02     250.1GB  RaidSet 
> Member(1)
> 16   WDC WD2500SD-01  WD-WMAL72085064  08.02D08     250.1GB  RaidSet 
> Member(1)
> ===============================================================================
> GuiErrMsg<0x00>: Success. 

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

[Chris Caputo]

I confirm I saw the problem while testing with ext2 and these two patches:

   areca-raid-linux-scsi-driver.patch
   areca-raid-linux-scsi-driver-update4.patch

Did update4 change the way the driver informs the scsi subsystem about the 
dimensions of a volume, or the sector size, etc?

Chris

On Thu, 30 Mar 2006, erich wrote:
> Dear Chris Caputo,
> 
> Could you tell me about the file system of testing volume on bonnie++ ?
> Does this issue come from different driver update?
> I had done more two weeks of long time testing on three machines with bonnie++
> and iometer benchmark utility.
> I have not got this phenomena in ext3 file system and reiserfs filesystem.
> But I can reproduce this message immediately on large file "900MB" copy from
> ARECA RAID volume format with ext2 file system.
> The ext2 file system seem have this bug after linux kernel version 2.6.3.
> I do same operation at linux 2.6.3 , it works fine.
> Now I am researching the files system kernel source, I hope you can help me to
> clear up the issue that what's happen with it
> 
> Best Regartds
> Erich Chen
> ----- Original Message ----- From: "Chris Caputo" <ccaputo@alt.net>
> To: "Erich Chen" <erich@areca.com.tw>
> Sent: Wednesday, March 22, 2006 7:45 AM
> Subject: new Areca driver in 2.6.16-rc6-mm2 appears to be broken
> 
> 
> > Erich,
> >
> > The new Areca driver in 2.6.16-rc6-mm2 is broken as far as I can tell.
> >
> > I applied the Areca driver in Linux 2.6.16-rc6-mm2 to a 2.6.15.6 as
> > follows:
> >
> >  cd /usr/src
> >  wget 
> > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc6/2.6.16-rc6-mm2/broken-out/areca-raid-linux-scsi-driver.patch
> > wget
> > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc6/2.6.16-rc6-mm2/broken-out/areca-raid-linux-scsi-driver-update4.patch
> >  cd /usr/src/linux
> >  cat ../areca-raid-linux-scsi-driver.patch | patch -p1
> >  cat ../areca-raid-linux-scsi-driver-update4.patch | patch -p1
> >
> > After compiling a new 2.6.15.6 kernel with the driver I was able to boot
> > and things appeared fine until I ran a bonnie++ test.  During the test the
> > following started spewing endlessly and the system was unusable:
> >
> >  ...
> >  attempt to access beyond end of device
> >  sdb1: rw=0, want=134744080, limit=128002016
> >  attempt to access beyond end of device
> >  sdb1: rw=0, want=134744080, limit=128002016
> >  attempt to access beyond end of device
> >  sdb1: rw=0, want=134744080, limit=128002016
> >  attempt to access beyond end of device
> >  sdb1: rw=0, want=134744080, limit=128002016
> >  attempt to access beyond end of device
> >  sdb1: rw=0, want=134744080, limit=128002016
> >  attempt to access beyond end of device
> >  sdb1: rw=0, want=134744080, limit=128002016
> >  attempt to access beyond end of device
> >  sdb1: rw=0, want=134744080, limit=128002016
> >  ...
> >
> > When only "areca-raid-linux-scsi-driver.patch" is used, the system works
> > fine for bonnie++ tests and general usage.
> >
> > The system is as follows:
> >
> >  AMD Opteron 280 dual-core 2.4ghz.  Revision E6, 256KB L1, 2048KB L2.
> >  SuperMicro H8DAE (rev 1.11)
> >  8 gigabytes (4 * 2GB PC3200/DDR400 REG ECC)
> >  Areca Tekram ARC-1160ML SATAII 16-port multi-lane with 256 megs RAM
> >  Areca ARC-6120 Battery Backup Module
> >  Four (4) Seagate ST3250823AS 250GB
> >  Twelve (12) Western Digital WD2500JD 250GB
> >
> > Info on the RAID config is below.
> >
> > Please let me know how I can assist.
> >
> > Thank you,
> > Chris Caputo
> >
> > ---
> >
> > # areca rsf info
> > Num Name             Disks TotalCap  FreeCap DiskChannels       State
> > ===============================================================================
> > 1  Raid Set # 00       14 3500.0GB    0.0GB FG3456789ABCDE     Normal
> > ===============================================================================
> > GuiErrMsg<0x00>: Success.
> >
> > # areca vsf info
> > # Name             Raid# Level   Capacity Ch/Id/Lun  State
> > ===============================================================================
> > 1 ARC-1160-VOL#00    1   Raid0+1   19.0GB 00/00/00   Normal
> > 2 ARC-1160-VOL#01    1   Raid0+1 1731.0GB 00/01/00   Normal
> > ===============================================================================
> > GuiErrMsg<0x00>: Success.
> >
> > # areca disk info
> > Ch   ModelName        Serial#          FirmRev     Capacity  State
> > ===============================================================================
> > 1   ST3250823AS      4ND1JKDW         3.03         250.1GB  HotSpare
> > 2   ST3250823AS      4ND1HEKE         3.03         250.1GB  HotSpare
> > 3   ST3250823AS      4ND1DEFN         3.03         250.1GB  RaidSet
> > Member(1)
> > 4   ST3250823AS      4ND1E37B         3.03         250.1GB  RaidSet
> > Member(1)
> > 5   WDC WD2500JD-00  WD-WMAEH1416638  02.05D02     250.1GB  RaidSet
> > Member(1)
> > 6   WDC WD2500JD-00  WD-WMAEH1415477  02.05D02     250.1GB  RaidSet
> > Member(1)
> > 7   WDC WD2500JD-00  WD-WMAEH1408943  02.05D02     250.1GB  RaidSet
> > Member(1)
> > 8   WDC WD2500JD-00  WD-WMAEH1428940  02.05D02     250.1GB  RaidSet
> > Member(1)
> > 9   WDC WD2500JD-00  WD-WMAEH1416508  02.05D02     250.1GB  RaidSet
> > Member(1)
> > 10   WDC WD2500JD-00  WD-WMAEH1416317  02.05D02     250.1GB  RaidSet
> > Member(1)
> > 11   WDC WD2500JD-00  WD-WMAEH1596552  02.05D02     250.1GB  RaidSet
> > Member(1)
> > 12   WDC WD2500SD-01  WD-WMAL71480351  08.02D08     250.1GB  RaidSet
> > Member(1)
> > 13   WDC WD2500JD-00  WD-WMAEH1408933  02.05D02     250.1GB  RaidSet
> > Member(1)
> > 14   WDC WD2500JD-00  WD-WMAEH1398573  02.05D02     250.1GB  RaidSet
> > Member(1)
> > 15   WDC WD2500JD-00  WD-WMAEH1409027  02.05D02     250.1GB  RaidSet
> > Member(1)
> > 16   WDC WD2500SD-01  WD-WMAL72085064  08.02D08     250.1GB  RaidSet
> > Member(1)
> > ===============================================================================
> > GuiErrMsg<0x00>: Success. 
> 
> 

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

[erich]

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@suse.de>
To: "Andrew Morton" <akpm@osdl.org>
Cc: "James Bottomley" <James.Bottomley@steeleye.com>; <erich@areca.com.tw>
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@areca.com.tw> 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
> 

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

[erich]

Dear Jens Axboe,

I had found a big difference of generic_make_request(struct bio *bio)
got message : sdb1: rw=0, want=...., limit=.....


*****************
** TEST 1
*****************

I used "MAX_XFER_SECTORS  4096" driver to do mkfs.ext2 with ARECA RAID 
volume sdb1.
and copy a big file (900MB) into sdb1.
If I copy this file from sdb1, the message rw=.... ,want=......, 
limit=...... will appear immediately.

When I reboot the system and used  "MAX_XFER_SECTORS  512" driver.
I copy this big file from sdb1, the message rw=.... ,want=......, 
limit=...... still appear immediately.

When I redo mkfs.ext2 with ARECA RAID volume sdb1 (used  "MAX_XFER_SECTORS 
512")
and copy the same file (900MB) into sdb1.
I copy this file from sdb1 again,the message rw=.... ,want=......, 
limit=...... disappear.

****************
** TEST 2
****************

When I do another test with "MAX_XFER_SECTORS  4096" driver

#echo 0 > /sys/block/sdb/queue/read_ahead_kb
#mkfs.ext2 /dev/sdb1

then copy the same file (900MB) into sdb1.
I copy this file from sdb1 again,the message rw=.... ,want=......, 
limit=...... disappear.
Even I redo "echo 4096 > /sys/block/sdb/queue/read_ahead_kb" with ARECA RAID 
volume.
The message rw=.... ,want=......, limit=...... never appear at my "copy 
compare" test script.

Now I can say the bug come from "block read ahead".

And this bug will certainly appear when do "mkfs.ext2" if read_ahead_kb 
value large enough.


Best Regards
Erich Chen
----- Original Message ----- 
From: "Jens Axboe" <axboe@suse.de>
To: "Andrew Morton" <akpm@osdl.org>
Cc: "James Bottomley" <James.Bottomley@steeleye.com>; <erich@areca.com.tw>
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@areca.com.tw> 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
> 

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

[Jens Axboe]

On Wed, Apr 12 2006, erich wrote:
> Dear Jens Axboe,
> 
> I had found a big difference of generic_make_request(struct bio *bio)
> got message : sdb1: rw=0, want=...., limit=.....
> 
> 
> *****************
> ** TEST 1
> *****************
> 
> I used "MAX_XFER_SECTORS  4096" driver to do mkfs.ext2 with ARECA RAID 
> volume sdb1.
> and copy a big file (900MB) into sdb1.
> If I copy this file from sdb1, the message rw=.... ,want=......, 
> limit=...... will appear immediately.
> 
> When I reboot the system and used  "MAX_XFER_SECTORS  512" driver.
> I copy this big file from sdb1, the message rw=.... ,want=......, 
> limit=...... still appear immediately.

This to me looks like you have a corrupted fs after using the 4k sectors
as the max transfer setting. I would look for a bug in the driver that
could explain this. Or perhaps the hardware.

Can you try and boot with MAX_XFER_SECTORS at 4096 and run mkfs + copy
big file to the partition. umount, then boot a kernel with
MAX_XFER_SECTORS at 512 and do a full fsck of that partition.


-- 
Jens Axboe

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

[erich]

Dear Jens Axboe,

About your request :

******************************************
** boot with driver MAX_XFER_SECTORS 4096
******************************************
#mkfs.ext2 /dev/sda1
#mount /dev/sda1 /mnt/sda1
#cp /root/aa /mnt/sda1/
#reboot
******************************************
** boot with driver MAX_XFER_SECTORS 512
******************************************
#fsck /dev/sda1
/dev/sda1:clean,.............
#mount /dev/sda1 /mnt/sda1
#cp /mnt/sda1/aa /home
cp: reading '/mnt/sda1/aa' : input/output error
 got message : sda1: rw=0, want=...., limit=..... dump

Best Regards
Erich Chen

----- Original Message ----- 
From: "Jens Axboe" <axboe@suse.de>
To: "erich" <erich@areca.com.tw>
Cc: <dax@gurulabs.com>; ""(????????????)??????O"" <billion.wu@areca.com.tw>; 
"Al Viro" <viro@ftp.linux.org.uk>; "Andrew Morton" <akpm@osdl.org>; 
"Randy.Dunlap" <rdunlap@xenotime.net>; "Matti Aarnio" 
<matti.aarnio@zmailer.org>; <linux-kernel@vger.kernel.org>; "James 
Bottomley" <James.Bottomley@steeleye.com>; "Chris Caputo" <ccaputo@alt.net>
Sent: Wednesday, April 19, 2006 6:40 PM
Subject: Re: new Areca driver in 2.6.16-rc6-mm2 appears to be broken


> On Wed, Apr 12 2006, erich wrote:
>> Dear Jens Axboe,
>>
>> I had found a big difference of generic_make_request(struct bio *bio)
>> got message : sdb1: rw=0, want=...., limit=.....
>>
>>
>> *****************
>> ** TEST 1
>> *****************
>>
>> I used "MAX_XFER_SECTORS  4096" driver to do mkfs.ext2 with ARECA RAID
>> volume sdb1.
>> and copy a big file (900MB) into sdb1.
>> If I copy this file from sdb1, the message rw=.... ,want=......,
>> limit=...... will appear immediately.
>>
>> When I reboot the system and used  "MAX_XFER_SECTORS  512" driver.
>> I copy this big file from sdb1, the message rw=.... ,want=......,
>> limit=...... still appear immediately.
>
> This to me looks like you have a corrupted fs after using the 4k sectors
> as the max transfer setting. I would look for a bug in the driver that
> could explain this. Or perhaps the hardware.
>
> Can you try and boot with MAX_XFER_SECTORS at 4096 and run mkfs + copy
> big file to the partition. umount, then boot a kernel with
> MAX_XFER_SECTORS at 512 and do a full fsck of that partition.
>
>
> -- 
> Jens Axboe
> 

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

[Jens Axboe]

On Wed, Apr 19 2006, erich wrote:
> Dear Jens Axboe,
> 
> About your request :
> 
> ******************************************
> ** boot with driver MAX_XFER_SECTORS 4096
> ******************************************
> #mkfs.ext2 /dev/sda1
> #mount /dev/sda1 /mnt/sda1
> #cp /root/aa /mnt/sda1/
> #reboot
> ******************************************
> ** boot with driver MAX_XFER_SECTORS 512
> ******************************************
> #fsck /dev/sda1
> /dev/sda1:clean,.............

fsck -fy /dev/sda1

You need to force a full check, the partition should be clean when you
do this so fsck wont do anything.


-- 
Jens Axboe

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

[erich]

[-- Attachment #1: Type: text/plain, Size: 2077 bytes --]

Dear Jens Axboe,

I  do "fsck -fy /dev/sda1" on driver MAX_XFER_SECTORS 512.
The file system was not clean.
I attach mesg.txt for you refer to.

=====================================
== boot with driver MAX_XFER_SECTORS 4096
=====================================
#mkfs.ext2 /dev/sda1
#reboot
=====================================
== boot with driver MAX_XFER_SECTORS 512
=====================================
#fsck -fy /dev/sda1
/dev/sda1:clean,.............
#reboot
=====================================
== boot with driver MAX_XFER_SECTORS 4096
=====================================
#mount /dev/sda1 /mnt/sda1
#cp /root/aa /mnt/sda1
#reboot
=====================================
== boot with driver MAX_XFER_SECTORS 512
=====================================
#fsck -fy /dev/sda1
/dev/sda1: no clean,........and dump message such as the attach file 
mesg.txt.

Best Regards
Erich Chen
----- Original Message ----- 
From: "Jens Axboe" <axboe@suse.de>
To: "erich" <erich@areca.com.tw>
Cc: <dax@gurulabs.com>; <billion.wu@areca.com.tw>; "Al Viro" 
<viro@ftp.linux.org.uk>; "Andrew Morton" <akpm@osdl.org>; "Randy.Dunlap" 
<rdunlap@xenotime.net>; "Matti Aarnio" <matti.aarnio@zmailer.org>; 
<linux-kernel@vger.kernel.org>; "James Bottomley" 
<James.Bottomley@steeleye.com>; "Chris Caputo" <ccaputo@alt.net>
Sent: Wednesday, April 19, 2006 9:19 PM
Subject: Re: new Areca driver in 2.6.16-rc6-mm2 appears to be broken


> On Wed, Apr 19 2006, erich wrote:
>> Dear Jens Axboe,
>>
>> About your request :
>>
>> ******************************************
>> ** boot with driver MAX_XFER_SECTORS 4096
>> ******************************************
>> #mkfs.ext2 /dev/sda1
>> #mount /dev/sda1 /mnt/sda1
>> #cp /root/aa /mnt/sda1/
>> #reboot
>> ******************************************
>> ** boot with driver MAX_XFER_SECTORS 512
>> ******************************************
>> #fsck /dev/sda1
>> /dev/sda1:clean,.............
>
> fsck -fy /dev/sda1
>
> You need to force a full check, the partition should be clean when you
> do this so fsck wont do anything.
>
>
> -- 
> Jens Axboe
> 

[-- Attachment #2: mesg.txt --]
[-- Type: text/plain, Size: 2268 bytes --]

fsck 1.38 (30-Jun-2005)
e2fsck 1.38 (30-Jun-2005)
Pass 1: Checking inodes, blocks, and sizes
Inode 12 has illegal block(s).  Clear? yes

Illegal block #2060 (4294967295) in inode 12.  CLEARED.
Illegal block #2062 (4294967295) in inode 12.  CLEARED.
Illegal block #2064 (4294967295) in inode 12.  CLEARED.
Illegal block #2066 (4294967295) in inode 12.  CLEARED.
Illegal block #2068 (4294967295) in inode 12.  CLEARED.
Illegal block #2070 (4294967295) in inode 12.  CLEARED.
Illegal block #2072 (4294967295) in inode 12.  CLEARED.
Illegal block #2074 (4294967295) in inode 12.  CLEARED.
Illegal block #2076 (4294967295) in inode 12.  CLEARED.
Illegal block #2078 (4294967295) in inode 12.  CLEARED.
Illegal block #2080 (4294967295) in inode 12.  CLEARED.
Too many illegal blocks in inode 12.
Clear inode? yes

Restarting e2fsck from the beginning...
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Entry 'aa' in / (2) has deleted/unused inode 12.  Clear? yes

Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(14336--32767) -(33288--65535) -(66050--98303) -(98824--131071) -(131586--163839) -(164360--196607) -(197
122--229375) -(229896--248594)
Fix? yes

Free blocks count wrong for group #0 (13811, counted=32243).
Fix? yes

Free blocks count wrong for group #1 (0, counted=32248).
Fix? yes

Free blocks count wrong for group #2 (0, counted=32254).
Fix? yes

Free blocks count wrong for group #3 (0, counted=32248).
Fix? yes

Free blocks count wrong for group #4 (0, counted=32254).
Fix? yes

Free blocks count wrong for group #5 (0, counted=32248).
Fix? yes

Free blocks count wrong for group #6 (0, counted=32254).
Fix? yes

Free blocks count wrong for group #7 (13549, counted=32248).
Fix? yes

Free blocks count wrong (18993611, counted=19224248).
Fix? yes

Inode bitmap differences:  -12
Fix? yes

Free inodes count wrong for group #0 (16372, counted=16373).
Fix? yes

Free inodes count wrong (9781236, counted=9781237).
Fix? yes


/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda1: 11/9781248 files (0.0% non-contiguous), 306941/19531189 blocks
linux:~ #

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

[Jens Axboe]

On Thu, Apr 20 2006, erich wrote:
> Dear Jens Axboe,
> 
> I  do "fsck -fy /dev/sda1" on driver MAX_XFER_SECTORS 512.
> The file system was not clean.
> I attach mesg.txt for you refer to.
> 
> =====================================
> == boot with driver MAX_XFER_SECTORS 4096
> =====================================
> #mkfs.ext2 /dev/sda1
> #reboot
> =====================================
> == boot with driver MAX_XFER_SECTORS 512
> =====================================
> #fsck -fy /dev/sda1
> /dev/sda1:clean,.............
> #reboot
> =====================================
> == boot with driver MAX_XFER_SECTORS 4096
> =====================================
> #mount /dev/sda1 /mnt/sda1
> #cp /root/aa /mnt/sda1
> #reboot
> =====================================
> == boot with driver MAX_XFER_SECTORS 512
> =====================================
> #fsck -fy /dev/sda1
> /dev/sda1: no clean,........and dump message such as the attach file 
> mesg.txt.

So the conclusion is that your driver and/or hardware corrupts data when
you set MAX_XFER_SECTORS too high. I can't help you anymore with this,
you should be in the best position to debug the driver and/or hardware
:-)

It could be that the higher setting just exposes another transfer
setting bug, like maximum number of segments or segment size, etc.

-- 
Jens Axboe

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

[erich]

Dear Dear Jens Axboe,

Thanks for your notification and advice.
Areca's firmware has max sg entries of 38 limit.
In my debug driver I had add this condition check.
But no one request more than 38 sg.
Both transfer length all have a lot of requests equal with 38 sg.
But why it ocur only at 4096 sectors?
If the /sys/block/sda/queue/max_sectors_kb equal 256 all operation running 
well.
But if I modify it more than 256, the bug appeared.
I  will do more research about why there were a lot of requests equal with 
38 sg in all file system.
And only it ocur at the volume that format with mkfs.ext2.
Thanks again.

Best Regards
Erich Chen

----- Original Message ----- 
From: "Jens Axboe" <axboe@suse.de>
To: "erich" <erich@areca.com.tw>
Cc: <dax@gurulabs.com>; <billion.wu@areca.com.tw>; "Al Viro" 
<viro@ftp.linux.org.uk>; "Andrew Morton" <akpm@osdl.org>; "Randy.Dunlap" 
<rdunlap@xenotime.net>; "Matti Aarnio" <matti.aarnio@zmailer.org>; 
<linux-kernel@vger.kernel.org>; "James Bottomley" 
<James.Bottomley@steeleye.com>; "Chris Caputo" <ccaputo@alt.net>
Sent: Thursday, April 20, 2006 2:42 PM
Subject: Re: new Areca driver in 2.6.16-rc6-mm2 appears to be broken


> On Thu, Apr 20 2006, erich wrote:
>> Dear Jens Axboe,
>>
>> I  do "fsck -fy /dev/sda1" on driver MAX_XFER_SECTORS 512.
>> The file system was not clean.
>> I attach mesg.txt for you refer to.
>>
>> =====================================
>> == boot with driver MAX_XFER_SECTORS 4096
>> =====================================
>> #mkfs.ext2 /dev/sda1
>> #reboot
>> =====================================
>> == boot with driver MAX_XFER_SECTORS 512
>> =====================================
>> #fsck -fy /dev/sda1
>> /dev/sda1:clean,.............
>> #reboot
>> =====================================
>> == boot with driver MAX_XFER_SECTORS 4096
>> =====================================
>> #mount /dev/sda1 /mnt/sda1
>> #cp /root/aa /mnt/sda1
>> #reboot
>> =====================================
>> == boot with driver MAX_XFER_SECTORS 512
>> =====================================
>> #fsck -fy /dev/sda1
>> /dev/sda1: no clean,........and dump message such as the attach file
>> mesg.txt.
>
> So the conclusion is that your driver and/or hardware corrupts data when
> you set MAX_XFER_SECTORS too high. I can't help you anymore with this,
> you should be in the best position to debug the driver and/or hardware
> :-)
>
> It could be that the higher setting just exposes another transfer
> setting bug, like maximum number of segments or segment size, etc.
>
> -- 
> Jens Axboe
> 

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

[Jens Axboe]

(don't top post!)

On Thu, Apr 20 2006, erich wrote:
> Dear Dear Jens Axboe,
> 
> Thanks for your notification and advice.
> Areca's firmware has max sg entries of 38 limit.
> In my debug driver I had add this condition check.
> But no one request more than 38 sg.
> Both transfer length all have a lot of requests equal with 38 sg.
> But why it ocur only at 4096 sectors?
> If the /sys/block/sda/queue/max_sectors_kb equal 256 all operation running 
> well.
> But if I modify it more than 256, the bug appeared.
> I  will do more research about why there were a lot of requests equal with 
> 38 sg in all file system.

It was just a suggestion, the bug might very well be just the size of
the transfer itself and nothing SG related. All I can say for sure is
that I'd be very surprised if this fs corruption isn't due to the
hardware mangling the data for large transfers.

> And only it ocur at the volume that format with mkfs.ext2.

Most likely a coincidence, try running eg dbench or other stress tests
on the fs with larger xfer size and I'm sure it'll corrupt eventually as
well.


-- 
Jens Axboe

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

[erich]

Dear Dear Jens Axboe,

I will try debench on the fs with larger xfer size when I enter my Lab. next 
time.
In the previous testing I do iometer and bonnie++ bench with ext3 riserfs 
file system.
I have test the transfer size from 2K to 5M with random/sequence read/write 
each term 2 hours.
When those three testing platforms all have completion.
There were not any one message appear as this.
I have done same testing with ext2 512 sectors and all done well.
I will find the difference of each LBA value , request length between 512 
sectors and 4096 sectors.

Best Regards
Erich Chen
----- Original Message ----- 
From: "Jens Axboe" <axboe@suse.de>
To: "erich" <erich@areca.com.tw>
Cc: <dax@gurulabs.com>; <billion.wu@areca.com.tw>; "Al Viro" 
<viro@ftp.linux.org.uk>; "Andrew Morton" <akpm@osdl.org>; "Randy.Dunlap" 
<rdunlap@xenotime.net>; "Matti Aarnio" <matti.aarnio@zmailer.org>; 
<linux-kernel@vger.kernel.org>; "James Bottomley" 
<James.Bottomley@steeleye.com>; "Chris Caputo" <ccaputo@alt.net>
Sent: Thursday, April 20, 2006 4:23 PM
Subject: Re: new Areca driver in 2.6.16-rc6-mm2 appears to be broken


>
> (don't top post!)
>
> On Thu, Apr 20 2006, erich wrote:
>> Dear Dear Jens Axboe,
>>
>> Thanks for your notification and advice.
>> Areca's firmware has max sg entries of 38 limit.
>> In my debug driver I had add this condition check.
>> But no one request more than 38 sg.
>> Both transfer length all have a lot of requests equal with 38 sg.
>> But why it ocur only at 4096 sectors?
>> If the /sys/block/sda/queue/max_sectors_kb equal 256 all operation 
>> running
>> well.
>> But if I modify it more than 256, the bug appeared.
>> I  will do more research about why there were a lot of requests equal 
>> with
>> 38 sg in all file system.
>
> It was just a suggestion, the bug might very well be just the size of
> the transfer itself and nothing SG related. All I can say for sure is
> that I'd be very surprised if this fs corruption isn't due to the
> hardware mangling the data for large transfers.
>
>> And only it ocur at the volume that format with mkfs.ext2.
>
> Most likely a coincidence, try running eg dbench or other stress tests
> on the fs with larger xfer size and I'm sure it'll corrupt eventually as
> well.
>
>
> -- 
> Jens Axboe
> 

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

[Jens Axboe]

Erich, please stop top posting! I've asked you several times now.

On Thu, Apr 20 2006, erich wrote:
> Dear Dear Jens Axboe,
> 
> I will try debench on the fs with larger xfer size when I enter my Lab. 
> next time.
> In the previous testing I do iometer and bonnie++ bench with ext3 riserfs 
> file system.
> I have test the transfer size from 2K to 5M with random/sequence read/write 
> each term 2 hours.
> When those three testing platforms all have completion.
> There were not any one message appear as this.
> I have done same testing with ext2 512 sectors and all done well.
> I will find the difference of each LBA value , request length between 512 
> sectors and 4096 sectors.

Since you are a hardware vendor, you probably have access to various
hardware analyzers that you can hook up. It seems to be easily
reproducible for you with ext2, why don't you see if you bus traffic
corresponds to what you expect with 4096 xfer size?

Again, I don't think I can help you with this. We have larger
max_sectors drivers out there and experience no problems. I'm fairly
confident that this is a bug in your driver/hardware that you need to
work out.

-- 
Jens Axboe

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

[James Bottomley]

On Thu, 2006-04-20 at 10:23 +0200, Jens Axboe wrote:
> It was just a suggestion, the bug might very well be just the size of
> the transfer itself and nothing SG related. All I can say for sure is
> that I'd be very surprised if this fs corruption isn't due to the
> hardware mangling the data for large transfers.

It sounds like this to me as well.  The other problem might be some type
of segment boundary issue which are not uncommon on less capable DMA
engines.  Either way, there's no question that large transfers work on
other hardware (SGI and IBM have extensively tested raising the current
128SG entries limit just so they could squeeze megabytes of data per
single command), so as Jens says, this is some type of issue within the
Areca hardware which you need to understand before the driver can be
made safe.

James

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

[Randy.Dunlap]

On Thu, 20 Apr 2006 16:11:04 +0800 erich wrote:

> Dear Dear Jens Axboe,
> 
> Thanks for your notification and advice.
> Areca's firmware has max sg entries of 38 limit.
> In my debug driver I had add this condition check.
> But no one request more than 38 sg.

Yesterday I saw a request with 70 sg pieces.  It was while
running mkfs.ext3 .

> Both transfer length all have a lot of requests equal with 38 sg.
> But why it ocur only at 4096 sectors?
> If the /sys/block/sda/queue/max_sectors_kb equal 256 all operation running 
> well.
> But if I modify it more than 256, the bug appeared.
> I  will do more research about why there were a lot of requests equal with 
> 38 sg in all file system.
> And only it ocur at the volume that format with mkfs.ext2.
> Thanks again.
> 
> Best Regards
> Erich Chen
> 
> ----- Original Message ----- 
> From: "Jens Axboe" <axboe@suse.de>
> To: "erich" <erich@areca.com.tw>
> Cc: <dax@gurulabs.com>; <billion.wu@areca.com.tw>; "Al Viro" 
> <viro@ftp.linux.org.uk>; "Andrew Morton" <akpm@osdl.org>; "Randy.Dunlap" 
> <rdunlap@xenotime.net>; "Matti Aarnio" <matti.aarnio@zmailer.org>; 
> <linux-kernel@vger.kernel.org>; "James Bottomley" 
> <James.Bottomley@steeleye.com>; "Chris Caputo" <ccaputo@alt.net>
> Sent: Thursday, April 20, 2006 2:42 PM
> Subject: Re: new Areca driver in 2.6.16-rc6-mm2 appears to be broken
> 
> 
> > On Thu, Apr 20 2006, erich wrote:
> >> Dear Jens Axboe,
> >>
> >> I  do "fsck -fy /dev/sda1" on driver MAX_XFER_SECTORS 512.
> >> The file system was not clean.
> >> I attach mesg.txt for you refer to.
> >>
> >> =====================================
> >> == boot with driver MAX_XFER_SECTORS 4096
> >> =====================================
> >> #mkfs.ext2 /dev/sda1
> >> #reboot
> >> =====================================
> >> == boot with driver MAX_XFER_SECTORS 512
> >> =====================================
> >> #fsck -fy /dev/sda1
> >> /dev/sda1:clean,.............
> >> #reboot
> >> =====================================
> >> == boot with driver MAX_XFER_SECTORS 4096
> >> =====================================
> >> #mount /dev/sda1 /mnt/sda1
> >> #cp /root/aa /mnt/sda1
> >> #reboot
> >> =====================================
> >> == boot with driver MAX_XFER_SECTORS 512
> >> =====================================
> >> #fsck -fy /dev/sda1
> >> /dev/sda1: no clean,........and dump message such as the attach file
> >> mesg.txt.
> >
> > So the conclusion is that your driver and/or hardware corrupts data when
> > you set MAX_XFER_SECTORS too high. I can't help you anymore with this,
> > you should be in the best position to debug the driver and/or hardware
> > :-)
> >
> > It could be that the higher setting just exposes another transfer
> > setting bug, like maximum number of segments or segment size, etc.
> >
> > -- 
> > Jens Axboe
> > 
> 
> 


---
~Randy

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

[erich]

Dear Randy.Dunlap,

If it is true, I will add sg count check in arcmsr.
Driver report : host->sg_tablesize=ARCMSR_MAX_SG_ENTRIES to linux scsi host 
layer.
But got an incorrect request of sg list count from .queuecommand.
Could you tell me which value of ARCMSR_MAX_XFER_SECTORS (4096/512)?

Best Regards
Erich chen

----- Original Message ----- 
From: "Randy.Dunlap" <rdunlap@xenotime.net>
To: "erich" <erich@areca.com.tw>
Cc: <axboe@suse.de>; <dax@gurulabs.com>; <billion.wu@areca.com.tw>; 
<viro@ftp.linux.org.uk>; <akpm@osdl.org>; <matti.aarnio@zmailer.org>; 
<linux-kernel@vger.kernel.org>; <James.Bottomley@steeleye.com>; 
<ccaputo@alt.net>
Sent: Thursday, April 20, 2006 11:38 PM
Subject: Re: new Areca driver in 2.6.16-rc6-mm2 appears to be broken


> On Thu, 20 Apr 2006 16:11:04 +0800 erich wrote:
>
>> Dear Dear Jens Axboe,
>>
>> Thanks for your notification and advice.
>> Areca's firmware has max sg entries of 38 limit.
>> In my debug driver I had add this condition check.
>> But no one request more than 38 sg.
>
> Yesterday I saw a request with 70 sg pieces.  It was while
> running mkfs.ext3 .
>
>> Both transfer length all have a lot of requests equal with 38 sg.
>> But why it ocur only at 4096 sectors?
>> If the /sys/block/sda/queue/max_sectors_kb equal 256 all operation 
>> running
>> well.
>> But if I modify it more than 256, the bug appeared.
>> I  will do more research about why there were a lot of requests equal 
>> with
>> 38 sg in all file system.
>> And only it ocur at the volume that format with mkfs.ext2.
>> Thanks again.
>>
>> Best Regards
>> Erich Chen
>>
>> ----- Original Message ----- 
>> From: "Jens Axboe" <axboe@suse.de>
>> To: "erich" <erich@areca.com.tw>
>> Cc: <dax@gurulabs.com>; <billion.wu@areca.com.tw>; "Al Viro"
>> <viro@ftp.linux.org.uk>; "Andrew Morton" <akpm@osdl.org>; "Randy.Dunlap"
>> <rdunlap@xenotime.net>; "Matti Aarnio" <matti.aarnio@zmailer.org>;
>> <linux-kernel@vger.kernel.org>; "James Bottomley"
>> <James.Bottomley@steeleye.com>; "Chris Caputo" <ccaputo@alt.net>
>> Sent: Thursday, April 20, 2006 2:42 PM
>> Subject: Re: new Areca driver in 2.6.16-rc6-mm2 appears to be broken
>>
>>
>> > On Thu, Apr 20 2006, erich wrote:
>> >> Dear Jens Axboe,
>> >>
>> >> I  do "fsck -fy /dev/sda1" on driver MAX_XFER_SECTORS 512.
>> >> The file system was not clean.
>> >> I attach mesg.txt for you refer to.
>> >>
>> >> =====================================
>> >> == boot with driver MAX_XFER_SECTORS 4096
>> >> =====================================
>> >> #mkfs.ext2 /dev/sda1
>> >> #reboot
>> >> =====================================
>> >> == boot with driver MAX_XFER_SECTORS 512
>> >> =====================================
>> >> #fsck -fy /dev/sda1
>> >> /dev/sda1:clean,.............
>> >> #reboot
>> >> =====================================
>> >> == boot with driver MAX_XFER_SECTORS 4096
>> >> =====================================
>> >> #mount /dev/sda1 /mnt/sda1
>> >> #cp /root/aa /mnt/sda1
>> >> #reboot
>> >> =====================================
>> >> == boot with driver MAX_XFER_SECTORS 512
>> >> =====================================
>> >> #fsck -fy /dev/sda1
>> >> /dev/sda1: no clean,........and dump message such as the attach file
>> >> mesg.txt.
>> >
>> > So the conclusion is that your driver and/or hardware corrupts data 
>> > when
>> > you set MAX_XFER_SECTORS too high. I can't help you anymore with this,
>> > you should be in the best position to debug the driver and/or hardware
>> > :-)
>> >
>> > It could be that the higher setting just exposes another transfer
>> > setting bug, like maximum number of segments or segment size, etc.
>> >
>> > -- 
>> > Jens Axboe
>> >
>>
>>
>
>
> ---
> ~Randy 

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

[Randy.Dunlap]

On Tue, 25 Apr 2006 16:45:18 +0800 erich wrote:

> Dear Randy.Dunlap,
> 
> If it is true, I will add sg count check in arcmsr.
> Driver report : host->sg_tablesize=ARCMSR_MAX_SG_ENTRIES to linux scsi host 
> layer.
> But got an incorrect request of sg list count from .queuecommand.
> Could you tell me which value of ARCMSR_MAX_XFER_SECTORS (4096/512)?

Hi Erich,
I didn't see 70 sg pieces while using the arcmsr driver, it was
while testing another driver.  Sorry if that wasn't clear.

Driver setting host->sg_tablesize should be good enough according
to Documentation/scsi/scsi_mid_low_api.txt .  Are you seeing problems
with that?  and I don't understand your last question about
ARCMSR_MAX_XFER_SECTORS.


> Best Regards
> Erich chen
> 
> ----- Original Message ----- 
> From: "Randy.Dunlap" <rdunlap@xenotime.net>
> To: "erich" <erich@areca.com.tw>
> Cc: <axboe@suse.de>; <dax@gurulabs.com>; <billion.wu@areca.com.tw>; 
> <viro@ftp.linux.org.uk>; <akpm@osdl.org>; <matti.aarnio@zmailer.org>; 
> <linux-kernel@vger.kernel.org>; <James.Bottomley@steeleye.com>; 
> <ccaputo@alt.net>
> Sent: Thursday, April 20, 2006 11:38 PM
> Subject: Re: new Areca driver in 2.6.16-rc6-mm2 appears to be broken
> 
> 
> > On Thu, 20 Apr 2006 16:11:04 +0800 erich wrote:
> >
> >> Dear Dear Jens Axboe,
> >>
> >> Thanks for your notification and advice.
> >> Areca's firmware has max sg entries of 38 limit.
> >> In my debug driver I had add this condition check.
> >> But no one request more than 38 sg.
> >
> > Yesterday I saw a request with 70 sg pieces.  It was while
> > running mkfs.ext3 .
> >
> >> Both transfer length all have a lot of requests equal with 38 sg.
> >> But why it ocur only at 4096 sectors?
> >> If the /sys/block/sda/queue/max_sectors_kb equal 256 all operation 
> >> running
> >> well.
> >> But if I modify it more than 256, the bug appeared.
> >> I  will do more research about why there were a lot of requests equal 
> >> with
> >> 38 sg in all file system.
> >> And only it ocur at the volume that format with mkfs.ext2.
> >> Thanks again.
> >>
> >> Best Regards
> >> Erich Chen
> >>
> >> ----- Original Message ----- 
> >> From: "Jens Axboe" <axboe@suse.de>
> >> To: "erich" <erich@areca.com.tw>
> >> Cc: <dax@gurulabs.com>; <billion.wu@areca.com.tw>; "Al Viro"
> >> <viro@ftp.linux.org.uk>; "Andrew Morton" <akpm@osdl.org>; "Randy.Dunlap"
> >> <rdunlap@xenotime.net>; "Matti Aarnio" <matti.aarnio@zmailer.org>;
> >> <linux-kernel@vger.kernel.org>; "James Bottomley"
> >> <James.Bottomley@steeleye.com>; "Chris Caputo" <ccaputo@alt.net>
> >> Sent: Thursday, April 20, 2006 2:42 PM
> >> Subject: Re: new Areca driver in 2.6.16-rc6-mm2 appears to be broken
> >>
> >>
> >> > On Thu, Apr 20 2006, erich wrote:
> >> >> Dear Jens Axboe,
> >> >>
> >> >> I  do "fsck -fy /dev/sda1" on driver MAX_XFER_SECTORS 512.
> >> >> The file system was not clean.
> >> >> I attach mesg.txt for you refer to.
> >> >>
> >> >> =====================================
> >> >> == boot with driver MAX_XFER_SECTORS 4096
> >> >> =====================================
> >> >> #mkfs.ext2 /dev/sda1
> >> >> #reboot
> >> >> =====================================
> >> >> == boot with driver MAX_XFER_SECTORS 512
> >> >> =====================================
> >> >> #fsck -fy /dev/sda1
> >> >> /dev/sda1:clean,.............
> >> >> #reboot
> >> >> =====================================
> >> >> == boot with driver MAX_XFER_SECTORS 4096
> >> >> =====================================
> >> >> #mount /dev/sda1 /mnt/sda1
> >> >> #cp /root/aa /mnt/sda1
> >> >> #reboot
> >> >> =====================================
> >> >> == boot with driver MAX_XFER_SECTORS 512
> >> >> =====================================
> >> >> #fsck -fy /dev/sda1
> >> >> /dev/sda1: no clean,........and dump message such as the attach file
> >> >> mesg.txt.
> >> >
> >> > So the conclusion is that your driver and/or hardware corrupts data 
> >> > when
> >> > you set MAX_XFER_SECTORS too high. I can't help you anymore with this,
> >> > you should be in the best position to debug the driver and/or hardware
> >> > :-)
> >> >
> >> > It could be that the higher setting just exposes another transfer
> >> > setting bug, like maximum number of segments or segment size, etc.
> >> >
> >> > -- 
> >> > Jens Axboe
> >> >
> >>
> >>
> >
> >
> > ---
> > ~Randy 
> 
> 


---
~Randy

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

[erich]

Dear Randy.Dunlap,

Thanks for your new update information.
The ARCMSR_MAX_XFER_SECTORS has bug if its value equal to 4096.
I had change ARCMSR_MAX_XFER_SECTORS of arcmsr linux driver into 512 at last 
driver version.
I will find out the solution and implement it into 4096.

Best Regards
Erich Chen

----- Original Message ----- 
From: "Randy.Dunlap" <rdunlap@xenotime.net>
To: "erich" <erich@areca.com.tw>
Cc: <dax@gurulabs.com>; <billion.wu@areca.com.tw>; <viro@ftp.linux.org.uk>; 
<akpm@osdl.org>; <matti.aarnio@zmailer.org>; <linux-kernel@vger.kernel.org>; 
<James.Bottomley@steeleye.com>; <ccaputo@alt.net>
Sent: Wednesday, April 26, 2006 12:02 AM
Subject: Re: new Areca driver in 2.6.16-rc6-mm2 appears to be broken


> On Tue, 25 Apr 2006 16:45:18 +0800 erich wrote:
>
>> Dear Randy.Dunlap,
>>
>> If it is true, I will add sg count check in arcmsr.
>> Driver report : host->sg_tablesize=ARCMSR_MAX_SG_ENTRIES to linux scsi 
>> host
>> layer.
>> But got an incorrect request of sg list count from .queuecommand.
>> Could you tell me which value of ARCMSR_MAX_XFER_SECTORS (4096/512)?
>
> Hi Erich,
> I didn't see 70 sg pieces while using the arcmsr driver, it was
> while testing another driver.  Sorry if that wasn't clear.
>
> Driver setting host->sg_tablesize should be good enough according
> to Documentation/scsi/scsi_mid_low_api.txt .  Are you seeing problems
> with that?  and I don't understand your last question about
> ARCMSR_MAX_XFER_SECTORS.
>
>
>> Best Regards
>> Erich chen
>>
>> ----- Original Message ----- 
>> From: "Randy.Dunlap" <rdunlap@xenotime.net>
>> To: "erich" <erich@areca.com.tw>
>> Cc: <axboe@suse.de>; <dax@gurulabs.com>; <billion.wu@areca.com.tw>;
>> <viro@ftp.linux.org.uk>; <akpm@osdl.org>; <matti.aarnio@zmailer.org>;
>> <linux-kernel@vger.kernel.org>; <James.Bottomley@steeleye.com>;
>> <ccaputo@alt.net>
>> Sent: Thursday, April 20, 2006 11:38 PM
>> Subject: Re: new Areca driver in 2.6.16-rc6-mm2 appears to be broken
>>
>>
>> > On Thu, 20 Apr 2006 16:11:04 +0800 erich wrote:
>> >
>> >> Dear Dear Jens Axboe,
>> >>
>> >> Thanks for your notification and advice.
>> >> Areca's firmware has max sg entries of 38 limit.
>> >> In my debug driver I had add this condition check.
>> >> But no one request more than 38 sg.
>> >
>> > Yesterday I saw a request with 70 sg pieces.  It was while
>> > running mkfs.ext3 .
>> >
>> >> Both transfer length all have a lot of requests equal with 38 sg.
>> >> But why it ocur only at 4096 sectors?
>> >> If the /sys/block/sda/queue/max_sectors_kb equal 256 all operation
>> >> running
>> >> well.
>> >> But if I modify it more than 256, the bug appeared.
>> >> I  will do more research about why there were a lot of requests equal
>> >> with
>> >> 38 sg in all file system.
>> >> And only it ocur at the volume that format with mkfs.ext2.
>> >> Thanks again.
>> >>
>> >> Best Regards
>> >> Erich Chen
>> >>
>> >> ----- Original Message ----- 
>> >> From: "Jens Axboe" <axboe@suse.de>
>> >> To: "erich" <erich@areca.com.tw>
>> >> Cc: <dax@gurulabs.com>; <billion.wu@areca.com.tw>; "Al Viro"
>> >> <viro@ftp.linux.org.uk>; "Andrew Morton" <akpm@osdl.org>; 
>> >> "Randy.Dunlap"
>> >> <rdunlap@xenotime.net>; "Matti Aarnio" <matti.aarnio@zmailer.org>;
>> >> <linux-kernel@vger.kernel.org>; "James Bottomley"
>> >> <James.Bottomley@steeleye.com>; "Chris Caputo" <ccaputo@alt.net>
>> >> Sent: Thursday, April 20, 2006 2:42 PM
>> >> Subject: Re: new Areca driver in 2.6.16-rc6-mm2 appears to be broken
>> >>
>> >>
>> >> > On Thu, Apr 20 2006, erich wrote:
>> >> >> Dear Jens Axboe,
>> >> >>
>> >> >> I  do "fsck -fy /dev/sda1" on driver MAX_XFER_SECTORS 512.
>> >> >> The file system was not clean.
>> >> >> I attach mesg.txt for you refer to.
>> >> >>
>> >> >> =====================================
>> >> >> == boot with driver MAX_XFER_SECTORS 4096
>> >> >> =====================================
>> >> >> #mkfs.ext2 /dev/sda1
>> >> >> #reboot
>> >> >> =====================================
>> >> >> == boot with driver MAX_XFER_SECTORS 512
>> >> >> =====================================
>> >> >> #fsck -fy /dev/sda1
>> >> >> /dev/sda1:clean,.............
>> >> >> #reboot
>> >> >> =====================================
>> >> >> == boot with driver MAX_XFER_SECTORS 4096
>> >> >> =====================================
>> >> >> #mount /dev/sda1 /mnt/sda1
>> >> >> #cp /root/aa /mnt/sda1
>> >> >> #reboot
>> >> >> =====================================
>> >> >> == boot with driver MAX_XFER_SECTORS 512
>> >> >> =====================================
>> >> >> #fsck -fy /dev/sda1
>> >> >> /dev/sda1: no clean,........and dump message such as the attach 
>> >> >> file
>> >> >> mesg.txt.
>> >> >
>> >> > So the conclusion is that your driver and/or hardware corrupts data
>> >> > when
>> >> > you set MAX_XFER_SECTORS too high. I can't help you anymore with 
>> >> > this,
>> >> > you should be in the best position to debug the driver and/or 
>> >> > hardware
>> >> > :-)
>> >> >
>> >> > It could be that the higher setting just exposes another transfer
>> >> > setting bug, like maximum number of segments or segment size, etc.
>> >> >
>> >> > -- 
>> >> > Jens Axboe
>> >> >
>> >>
>> >>
>> >
>> >
>> > ---
>> > ~Randy
>>
>>
>
>
> ---
> ~Randy