Re: [git patch] 2.6.x libata fix

[Matt Darcy <kernel-lists@projecthugo.co.uk>]

Matt Darcy wrote:

> Jeff Garzik wrote:
>
>> Please pull from 'upstream-linus' branch of
>> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>>
>> to receive the following updates:
>>
>> drivers/scsi/sata_nv.c |   30 ++++++++++++++++++++++++------
>> 1 files changed, 24 insertions(+), 6 deletions(-)
>>
>> Andrew Chew:
>>      sata_nv, spurious interrupts at system startup with MAXTOR 
>> 6H500F0 drive
>>
>> diff --git a/drivers/scsi/sata_nv.c b/drivers/scsi/sata_nv.c
>> index c0cf52c..bbbb55e 100644
>> --- a/drivers/scsi/sata_nv.c
>> +++ b/drivers/scsi/sata_nv.c
>>
>> <snip reset of patch>
>>  
>>
> Hi Jeff, et all
>
> I pulled this down last night from 
> git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
> as I don't have an account on master.kernel.org, I assume these are 
> the same physical tree.
>
> This built fine and seemed aware of all the SATA disks on my 
> controller (as did previous git branches).
>
> Again using my raid5 (7 disks 1.4tb) example, I am unable to build an 
> array without the machine hanging.
>
> I am able to access the individual disks for a short period of time 
> before the box hangs totally which I assume is why the raid array will 
> not build as the access for the disks hangs, not the actual building 
> of the array.
>
> I havn't got any output yet on the errors (if there are any) as I left 
> the array building overnight (300+ minutes) and when I woke up this 
> morning the box had hung, but power saver had come on the screen so I 
> couldn't see the messages.
>
> I'll do another test this afternoon and try to get some output for 
> you, but I just thought I'd let you know this was coming.
>
> Aslo FYI: I'm using maxtor SATA disks, so your patch was of particular 
> interesting to me.
>
> Many thanks,
>
> Matt


I can now provide further updates for this, although this are not really 
super useful.

I've copied the linux-raid list in as well, as after a little more 
testing on my part I'd appriciate some input from the raid guys also.

First of all, please ignore the comments above, there was a problem with 
grub and it actually "failed back" and booted into the older git 
release, so my initial test was actually done running the wrong kenel 
which I didn't notice. Appologies to all for this.

Last nights tests where done using the correct kernel (I fixed the grub 
typo) 2.6.15-g5367f2d6

The details I have are as follows.

I can run the machine accessing the 7 maxtor SATA disks as individual 
disks for around 12 hours now, without any hangs or errors or any real 
problems. I've not hit them very hard, but initial performance seems 
fine and more than usable.

The actual problems occurr when including these disks in a raid group.

root@berger:~# fdisk -l /dev/sdc

Disk /dev/sdc: 251.0 GB, 251000193024 bytes
255 heads, 63 sectors/track, 30515 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1       30515   245111706   fd  Linux raid 
autodetect

root@berger:~# fdisk -l /dev/sde

Disk /dev/sde: 251.0 GB, 251000193024 bytes
255 heads, 63 sectors/track, 30515 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sde1               1       30515   245111706   fd  Linux raid 
autodetect


As you can see from my two random disks examples, they are partitioned 
and makred as raid auto detect.

I issue the mdadm command to build the raid 5 array

 mdadm -C /dev/md6 -l5 -n6 -x1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 
/dev/sdg1 /dev/sdh1 /dev/sdi1

and the array starts to build.......

md6 : active raid5 sdh1[7] sdi1[6](S) sdg1[4] sdf1[3] sde1[2] sdd1[1] 
sdc1[0]
      1225558080 blocks level 5, 64k chunk, algorithm 2 [6/5] [UUUUU_]
      [>....................]  recovery =  0.1% (374272/245111616) 
finish=337.8min speed=12073K/sec


however at around %25 - %40 completion the box will simpley just hang - 
I'm getting no on screen messages and the sylog is not reporting anything.

SysRQ is unusable.

I'm open to options on how to resolve this and move the driver forward 
(assuming it is the drivers interfaction with the raid sub system)
or
how to get some meaningful debug out to report back to the appropriate 
development groups.

thanks.

Matt.