Re: SiI 3112A + Seagate HDs = still no go?

Re: SiI 3112A + Seagate HDs = still no go?

[Tejun Heo]

Chris Boot wrote:
> Hi all,
> 
> I just recently took the plunge and bought 4 250 GB Seagate drives  and 
> a 2 port Silicon Image 3112A controller card for the 2 drives my  
> motherboard doesn't handle. No matter how hard I try, I can't get the  
> hard drives to work: they are detected correctly and work reasonably  
> well under _very_ light load, but anything like building a RAID array  
> is a bit much and the whole controller seems to lock up.
> 
> I've tried adding the drive to the blacklist in the sata_sil.c driver  
> and I still have the same trouble: as you can see the messages below  
> relate to my patched kernel with the blacklist fix. I've seen that  this 
> was discussed just yesterday, but that seemed to give nothing:  
> http://www.ussg.iu.edu/hypermail/linux/kernel/0508.1/0310.html
> 
> Ready and willing to hack my kernel to pieces; this machine is no use  
> until I get all the drives working! Needless to say the drives  
> connected to the on-board VIA controller work fine, as do the drives  
> currently on the SiI controller if I swap them around.
> 
> Any ideas?
> 
> TIA
> Chris
> 

[added linux-ide to cc list]

  Can you please try w/ vanilla kernel (2.6.12 or 2.6.13-rc)?  And w/ 
one drive only?

-- 
tejun

Re: SiI 3112A + Seagate HDs = still no go?

[Chris Boot]

On 12 Aug 2005, at 4:24, Tejun Heo wrote:

> Chris Boot wrote:
>
>> Hi all,
>> I just recently took the plunge and bought 4 250 GB Seagate  
>> drives  and a 2 port Silicon Image 3112A controller card for the 2  
>> drives my  motherboard doesn't handle. No matter how hard I try, I  
>> can't get the  hard drives to work: they are detected correctly  
>> and work reasonably  well under _very_ light load, but anything  
>> like building a RAID array  is a bit much and the whole controller  
>> seems to lock up.
>> I've tried adding the drive to the blacklist in the sata_sil.c  
>> driver  and I still have the same trouble: as you can see the  
>> messages below  relate to my patched kernel with the blacklist  
>> fix. I've seen that  this was discussed just yesterday, but that  
>> seemed to give nothing:  http://www.ussg.iu.edu/hypermail/linux/ 
>> kernel/0508.1/0310.html
>> Ready and willing to hack my kernel to pieces; this machine is no  
>> use  until I get all the drives working! Needless to say the  
>> drives  connected to the on-board VIA controller work fine, as do  
>> the drives  currently on the SiI controller if I swap them around.
>> Any ideas?
>> TIA
>> Chris
>>
>
> [added linux-ide to cc list]
>
>  Can you please try w/ vanilla kernel (2.6.12 or 2.6.13-rc)?  And  
> w/ one drive only?

I unplugged both drives from my on-board SATA controller and left  
just one connected to the 3112A controller. Rebooted with a fresh,  
vanilla 2.6.13-rc6 and ran:

dd if=/dev/zero of=test.img bs=1M count=16384

After about 30 seconds I got the crash and the kernel started  
repeating every 30 seconds (with different sector numbers):

ata1: command 0x35 timeout, stat 0xd9 host_stat 0x1
ata1: status=0xd9 { Busy }
SCSI error : <0 0 0 0> return code = 0x80000002
sda: Current: sense key=0xb
ASC=0x47 ASCQ=0x0
end_request: I/O error, dev sda, sector 14937602
ATA: abnormal status 0xD9 on port E0802087
ATA: abnormal status 0xD9 on port E0802087
ATA: abnormal status 0xD9 on port E0802087

dmesg:
Linux version 2.6.13-rc6 (bootc@arcadia.bootc.net) (gcc version  
3.3.5-20050130 (Gentoo 3.3.5.20050130-r1, ssp-3.3.5.20050130-1,  
pie-8.7.7.1)) #1 Fri Aug 12 12:31:25 BST 2005
...
libata version 1.11 loaded.
sata_sil version 0.9
ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 18 (level, low) -> IRQ 177
ata1: SATA max UDMA/100 cmd 0xE0802080 ctl 0xE080208A bmdma  
0xE0802000 irq 177
ata2: SATA max UDMA/100 cmd 0xE08020C0 ctl 0xE08020CA bmdma  
0xE0802008 irq 177
ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4023 85:3469 86:3c01  
87:4023 88:207f
ata1: dev 0 ATA, max UDMA/133, 488397168 sectors: lba48
ata1: dev 0 configured for UDMA/100
scsi0 : sata_sil
ata2: no device found (phy stat 00000000)
scsi1 : sata_sil
   Vendor: ATA       Model: ST3250823AS       Rev: 3.03
   Type:   Direct-Access                      ANSI SCSI revision: 05
sata_via version 1.1
ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [ALKA] -> GSI 20 (level,  
low) -> IRQ 169
PCI: Via IRQ fixup for 0000:00:0f.0, from 11 to 9
sata_via(0000:00:0f.0): routed to hard irq line 9
ata3: SATA max UDMA/133 cmd 0xB400 ctl 0xB802 bmdma 0xC400 irq 169
ata4: SATA max UDMA/133 cmd 0xBC00 ctl 0xC002 bmdma 0xC408 irq 169
ata3: no device found (phy stat 00000000)
scsi2 : sata_via
ata4: no device found (phy stat 00000000)
scsi3 : sata_via
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
SCSI device sda: drive cache: write back
sda: sda1 sda2 sda3
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,  type 0

I forgot to mention previously but I even tried with "noapic nolapic  
acpi=off pci=routeirq" and got the same trouble.

Thanks,
Chris

-- 
Chris Boot
bootc@bootc.net
http://www.bootc.net/

Re: SiI 3112A + Seagate HDs = still no go?

[Tejun Heo]

  Hello, Chris.

Chris Boot wrote:
> 
> On 12 Aug 2005, at 4:24, Tejun Heo wrote:
> 
>> Chris Boot wrote:
>>
>>> Hi all,
>>> I just recently took the plunge and bought 4 250 GB Seagate  drives  
>>> and a 2 port Silicon Image 3112A controller card for the 2  drives 
>>> my  motherboard doesn't handle. No matter how hard I try, I  can't 
>>> get the  hard drives to work: they are detected correctly  and work 
>>> reasonably  well under _very_ light load, but anything  like building 
>>> a RAID array  is a bit much and the whole controller  seems to lock up.
>>> I've tried adding the drive to the blacklist in the sata_sil.c  
>>> driver  and I still have the same trouble: as you can see the  
>>> messages below  relate to my patched kernel with the blacklist  fix. 
>>> I've seen that  this was discussed just yesterday, but that  seemed 
>>> to give nothing:  http://www.ussg.iu.edu/hypermail/linux/ 
>>> kernel/0508.1/0310.html
>>> Ready and willing to hack my kernel to pieces; this machine is no  
>>> use  until I get all the drives working! Needless to say the  drives  
>>> connected to the on-board VIA controller work fine, as do  the 
>>> drives  currently on the SiI controller if I swap them around.
>>> Any ideas?
>>> TIA
>>> Chris
>>>
>>
>> [added linux-ide to cc list]
>>
>>  Can you please try w/ vanilla kernel (2.6.12 or 2.6.13-rc)?  And  w/ 
>> one drive only?
> 
> 
> I unplugged both drives from my on-board SATA controller and left  just 
> one connected to the 3112A controller. Rebooted with a fresh,  vanilla 
> 2.6.13-rc6 and ran:

  You can leave drives on on-board SATA controller.  It wouldn't make 
any difference.

> 
> dd if=/dev/zero of=test.img bs=1M count=16384
> 
> After about 30 seconds I got the crash and the kernel started  repeating 
> every 30 seconds (with different sector numbers):
> 
> ata1: command 0x35 timeout, stat 0xd9 host_stat 0x1
> ata1: status=0xd9 { Busy }
> SCSI error : <0 0 0 0> return code = 0x80000002
> sda: Current: sense key=0xb
> ASC=0x47 ASCQ=0x0
> end_request: I/O error, dev sda, sector 14937602
> ATA: abnormal status 0xD9 on port E0802087
> ATA: abnormal status 0xD9 on port E0802087
> ATA: abnormal status 0xD9 on port E0802087
> 
> dmesg:
> Linux version 2.6.13-rc6 (bootc@arcadia.bootc.net) (gcc version  
> 3.3.5-20050130 (Gentoo 3.3.5.20050130-r1, ssp-3.3.5.20050130-1,  
> pie-8.7.7.1)) #1 Fri Aug 12 12:31:25 BST 2005
> ...
> libata version 1.11 loaded.
> sata_sil version 0.9
> ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 18 (level, low) -> IRQ 177
> ata1: SATA max UDMA/100 cmd 0xE0802080 ctl 0xE080208A bmdma  0xE0802000 
> irq 177
> ata2: SATA max UDMA/100 cmd 0xE08020C0 ctl 0xE08020CA bmdma  0xE0802008 
> irq 177
> ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4023 85:3469 86:3c01  87:4023 
> 88:207f
> ata1: dev 0 ATA, max UDMA/133, 488397168 sectors: lba48
> ata1: dev 0 configured for UDMA/100
> scsi0 : sata_sil
> ata2: no device found (phy stat 00000000)
> scsi1 : sata_sil
>   Vendor: ATA       Model: ST3250823AS       Rev: 3.03
>   Type:   Direct-Access                      ANSI SCSI revision: 05
> sata_via version 1.1
> ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [ALKA] -> GSI 20 (level,  
> low) -> IRQ 169
> PCI: Via IRQ fixup for 0000:00:0f.0, from 11 to 9
> sata_via(0000:00:0f.0): routed to hard irq line 9
> ata3: SATA max UDMA/133 cmd 0xB400 ctl 0xB802 bmdma 0xC400 irq 169
> ata4: SATA max UDMA/133 cmd 0xBC00 ctl 0xC002 bmdma 0xC408 irq 169
> ata3: no device found (phy stat 00000000)
> scsi2 : sata_via
> ata4: no device found (phy stat 00000000)
> scsi3 : sata_via
> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
> SCSI device sda: drive cache: write back
> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
> SCSI device sda: drive cache: write back
> sda: sda1 sda2 sda3
> Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
> Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,  type 0
> 
> I forgot to mention previously but I even tried with "noapic nolapic  
> acpi=off pci=routeirq" and got the same trouble.

  This is weird as ST3250823AS (and all Seagate .8 drives) are known to 
work without any problem with sii 3112/3114.  I currently don't own such 
a drive but someone confirmed me that ST3250823AS works w/ sii 3114 
without any problem (including bonnie++ results and all).  So, I don't 
think it's the good old mod15write problem.

  I hope it's just a bad hardware, cable or something like that; 
otherwise, you're hitting a new bug.  Can you verify if the drive works 
under windows?

-- 
tejun

Re: SiI 3112A + Seagate HDs = still no go?

[Chris Boot]

Hi Tejun,

On 12 Aug 2005, at 12:28, Tejun Heo wrote:

>
>  Hello, Chris.
>
> Chris Boot wrote:
>
>> On 12 Aug 2005, at 4:24, Tejun Heo wrote:
>>
>>> Chris Boot wrote:
>>>
>>>
>>>> Hi all,
>>>> I just recently took the plunge and bought 4 250 GB Seagate   
>>>> drives  and a 2 port Silicon Image 3112A controller card for the  
>>>> 2  drives my  motherboard doesn't handle. No matter how hard I  
>>>> try, I  can't get the  hard drives to work: they are detected  
>>>> correctly  and work reasonably  well under _very_ light load,  
>>>> but anything  like building a RAID array  is a bit much and the  
>>>> whole controller  seems to lock up.
>>>> I've tried adding the drive to the blacklist in the sata_sil.c   
>>>> driver  and I still have the same trouble: as you can see the   
>>>> messages below  relate to my patched kernel with the blacklist   
>>>> fix. I've seen that  this was discussed just yesterday, but  
>>>> that  seemed to give nothing:  http://www.ussg.iu.edu/hypermail/ 
>>>> linux/ kernel/0508.1/0310.html
>>>> Ready and willing to hack my kernel to pieces; this machine is  
>>>> no  use  until I get all the drives working! Needless to say  
>>>> the  drives  connected to the on-board VIA controller work fine,  
>>>> as do  the drives  currently on the SiI controller if I swap  
>>>> them around.
>>>> Any ideas?
>>>> TIA
>>>> Chris
>>>>
>>>>
>>>
>>> [added linux-ide to cc list]
>>>
>>>  Can you please try w/ vanilla kernel (2.6.12 or 2.6.13-rc)?   
>>> And  w/ one drive only?
>>>
>> I unplugged both drives from my on-board SATA controller and left   
>> just one connected to the 3112A controller. Rebooted with a  
>> fresh,  vanilla 2.6.13-rc6 and ran:
>>
>
>  You can leave drives on on-board SATA controller.  It wouldn't  
> make any difference.
>
>
>> dd if=/dev/zero of=test.img bs=1M count=16384
>> After about 30 seconds I got the crash and the kernel started   
>> repeating every 30 seconds (with different sector numbers):
>> ata1: command 0x35 timeout, stat 0xd9 host_stat 0x1
>> ata1: status=0xd9 { Busy }
>> SCSI error : <0 0 0 0> return code = 0x80000002
>> sda: Current: sense key=0xb
>> ASC=0x47 ASCQ=0x0
>> end_request: I/O error, dev sda, sector 14937602
>> ATA: abnormal status 0xD9 on port E0802087
>> ATA: abnormal status 0xD9 on port E0802087
>> ATA: abnormal status 0xD9 on port E0802087
>> dmesg:
>> Linux version 2.6.13-rc6 (bootc@arcadia.bootc.net) (gcc version   
>> 3.3.5-20050130 (Gentoo 3.3.5.20050130-r1, ssp-3.3.5.20050130-1,   
>> pie-8.7.7.1)) #1 Fri Aug 12 12:31:25 BST 2005
>> ...
>> libata version 1.11 loaded.
>> sata_sil version 0.9
>> ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 18 (level, low) -> IRQ 177
>> ata1: SATA max UDMA/100 cmd 0xE0802080 ctl 0xE080208A bmdma   
>> 0xE0802000 irq 177
>> ata2: SATA max UDMA/100 cmd 0xE08020C0 ctl 0xE08020CA bmdma   
>> 0xE0802008 irq 177
>> ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4023 85:3469 86:3c01   
>> 87:4023 88:207f
>> ata1: dev 0 ATA, max UDMA/133, 488397168 sectors: lba48
>> ata1: dev 0 configured for UDMA/100
>> scsi0 : sata_sil
>> ata2: no device found (phy stat 00000000)
>> scsi1 : sata_sil
>>   Vendor: ATA       Model: ST3250823AS       Rev: 3.03
>>   Type:   Direct-Access                      ANSI SCSI revision: 05
>> sata_via version 1.1
>> ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [ALKA] -> GSI 20  
>> (level,  low) -> IRQ 169
>> PCI: Via IRQ fixup for 0000:00:0f.0, from 11 to 9
>> sata_via(0000:00:0f.0): routed to hard irq line 9
>> ata3: SATA max UDMA/133 cmd 0xB400 ctl 0xB802 bmdma 0xC400 irq 169
>> ata4: SATA max UDMA/133 cmd 0xBC00 ctl 0xC002 bmdma 0xC408 irq 169
>> ata3: no device found (phy stat 00000000)
>> scsi2 : sata_via
>> ata4: no device found (phy stat 00000000)
>> scsi3 : sata_via
>> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
>> SCSI device sda: drive cache: write back
>> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
>> SCSI device sda: drive cache: write back
>> sda: sda1 sda2 sda3
>> Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
>> Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,  type 0
>> I forgot to mention previously but I even tried with "noapic  
>> nolapic  acpi=off pci=routeirq" and got the same trouble.
>>
>
>  This is weird as ST3250823AS (and all Seagate .8 drives) are known  
> to work without any problem with sii 3112/3114.  I currently don't  
> own such a drive but someone confirmed me that ST3250823AS works w/  
> sii 3114 without any problem (including bonnie++ results and all).   
> So, I don't think it's the good old mod15write problem.
>
>  I hope it's just a bad hardware, cable or something like that;  
> otherwise, you're hitting a new bug.  Can you verify if the drive  
> works under windows?

Well, what piqued my interest is that the same drives work fine on my  
on-board sata_via controller. All 4 drives were bought at the same  
time and *seem* to be from the same batch, and all work fine on the  
VIA controller and none work on the 3112A. I've also tried different  
cables, all of which are Belkin which I thought were decent quality.

I'll just try installing Winblows and let you know.

Many thanks,
Chris

-- 
Chris Boot
bootc@bootc.net
http://www.bootc.net/

Re: SiI 3112A + Seagate HDs = still no go?

[Chris Boot]

Hi Tejun,

On 12 Aug 2005, at 12:33, Chris Boot wrote:

> Hi Tejun,
>
> On 12 Aug 2005, at 12:28, Tejun Heo wrote:
>
>
>>
>>  Hello, Chris.
>>
>> Chris Boot wrote:
>>
>>
>>> On 12 Aug 2005, at 4:24, Tejun Heo wrote:
>>>
>>>
>>>> Chris Boot wrote:
>>>>
>>>>
>>>>
>>>>> Hi all,
>>>>> I just recently took the plunge and bought 4 250 GB Seagate   
>>>>> drives  and a 2 port Silicon Image 3112A controller card for  
>>>>> the 2  drives my  motherboard doesn't handle. No matter how  
>>>>> hard I try, I  can't get the  hard drives to work: they are  
>>>>> detected correctly  and work reasonably  well under _very_  
>>>>> light load, but anything  like building a RAID array  is a bit  
>>>>> much and the whole controller  seems to lock up.
>>>>> I've tried adding the drive to the blacklist in the sata_sil.c   
>>>>> driver  and I still have the same trouble: as you can see the   
>>>>> messages below  relate to my patched kernel with the blacklist   
>>>>> fix. I've seen that  this was discussed just yesterday, but  
>>>>> that  seemed to give nothing:  http://www.ussg.iu.edu/hypermail/ 
>>>>> linux/ kernel/0508.1/0310.html
>>>>> Ready and willing to hack my kernel to pieces; this machine is  
>>>>> no  use  until I get all the drives working! Needless to say  
>>>>> the  drives  connected to the on-board VIA controller work  
>>>>> fine, as do  the drives  currently on the SiI controller if I  
>>>>> swap them around.
>>>>> Any ideas?
>>>>> TIA
>>>>> Chris
>>>>>
>>>>>
>>>>>
>>>>
>>>> [added linux-ide to cc list]
>>>>
>>>>  Can you please try w/ vanilla kernel (2.6.12 or 2.6.13-rc)?   
>>>> And  w/ one drive only?
>>>>
>>>>
>>> I unplugged both drives from my on-board SATA controller and  
>>> left  just one connected to the 3112A controller. Rebooted with a  
>>> fresh,  vanilla 2.6.13-rc6 and ran:
>>>
>>>
>>
>>  You can leave drives on on-board SATA controller.  It wouldn't  
>> make any difference.
>>
>>
>>
>>> dd if=/dev/zero of=test.img bs=1M count=16384
>>> After about 30 seconds I got the crash and the kernel started   
>>> repeating every 30 seconds (with different sector numbers):
>>> ata1: command 0x35 timeout, stat 0xd9 host_stat 0x1
>>> ata1: status=0xd9 { Busy }
>>> SCSI error : <0 0 0 0> return code = 0x80000002
>>> sda: Current: sense key=0xb
>>> ASC=0x47 ASCQ=0x0
>>> end_request: I/O error, dev sda, sector 14937602
>>> ATA: abnormal status 0xD9 on port E0802087
>>> ATA: abnormal status 0xD9 on port E0802087
>>> ATA: abnormal status 0xD9 on port E0802087
>>> dmesg:
>>> Linux version 2.6.13-rc6 (bootc@arcadia.bootc.net) (gcc version   
>>> 3.3.5-20050130 (Gentoo 3.3.5.20050130-r1, ssp-3.3.5.20050130-1,   
>>> pie-8.7.7.1)) #1 Fri Aug 12 12:31:25 BST 2005
>>> ...
>>> libata version 1.11 loaded.
>>> sata_sil version 0.9
>>> ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 18 (level, low) -> IRQ  
>>> 177
>>> ata1: SATA max UDMA/100 cmd 0xE0802080 ctl 0xE080208A bmdma   
>>> 0xE0802000 irq 177
>>> ata2: SATA max UDMA/100 cmd 0xE08020C0 ctl 0xE08020CA bmdma   
>>> 0xE0802008 irq 177
>>> ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4023 85:3469 86:3c01   
>>> 87:4023 88:207f
>>> ata1: dev 0 ATA, max UDMA/133, 488397168 sectors: lba48
>>> ata1: dev 0 configured for UDMA/100
>>> scsi0 : sata_sil
>>> ata2: no device found (phy stat 00000000)
>>> scsi1 : sata_sil
>>>   Vendor: ATA       Model: ST3250823AS       Rev: 3.03
>>>   Type:   Direct-Access                      ANSI SCSI revision: 05
>>> sata_via version 1.1
>>> ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [ALKA] -> GSI 20  
>>> (level,  low) -> IRQ 169
>>> PCI: Via IRQ fixup for 0000:00:0f.0, from 11 to 9
>>> sata_via(0000:00:0f.0): routed to hard irq line 9
>>> ata3: SATA max UDMA/133 cmd 0xB400 ctl 0xB802 bmdma 0xC400 irq 169
>>> ata4: SATA max UDMA/133 cmd 0xBC00 ctl 0xC002 bmdma 0xC408 irq 169
>>> ata3: no device found (phy stat 00000000)
>>> scsi2 : sata_via
>>> ata4: no device found (phy stat 00000000)
>>> scsi3 : sata_via
>>> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
>>> SCSI device sda: drive cache: write back
>>> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
>>> SCSI device sda: drive cache: write back
>>> sda: sda1 sda2 sda3
>>> Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
>>> Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,  type 0
>>> I forgot to mention previously but I even tried with "noapic  
>>> nolapic  acpi=off pci=routeirq" and got the same trouble.
>>>
>>>
>>
>>  This is weird as ST3250823AS (and all Seagate .8 drives) are  
>> known to work without any problem with sii 3112/3114.  I currently  
>> don't own such a drive but someone confirmed me that ST3250823AS  
>> works w/ sii 3114 without any problem (including bonnie++ results  
>> and all).  So, I don't think it's the good old mod15write problem.
>>
>>  I hope it's just a bad hardware, cable or something like that;  
>> otherwise, you're hitting a new bug.  Can you verify if the drive  
>> works under windows?
>>
>
> Well, what piqued my interest is that the same drives work fine on  
> my on-board sata_via controller. All 4 drives were bought at the  
> same time and *seem* to be from the same batch, and all work fine  
> on the VIA controller and none work on the 3112A. I've also tried  
> different cables, all of which are Belkin which I thought were  
> decent quality.
>
> I'll just try installing Winblows and let you know.

I just installed Windows XP SP2 and Cygwin:

$ dd if=/dev/zero of=test.img bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes (4.3GB) copied, 166.27 seconds, 25.8 MB/s

So it works a treat, although it's slower than maybe it should be:  
under linux and the VIA controller I get about 50 MB/sec, but that  
may just be down to the OS.

Where do I start to debug the problem?

Many thanks,
Chris

-- 
Chris Boot
bootc@bootc.net
http://www.bootc.net/

Re: SiI 3112A + Seagate HDs = still no go?

[Tejun Heo]

Chris Boot wrote:
> Hi Tejun,
> 
> On 12 Aug 2005, at 12:33, Chris Boot wrote:
> 
>> Hi Tejun,
>>
>> On 12 Aug 2005, at 12:28, Tejun Heo wrote:
>>
>>
>>>
>>>  Hello, Chris.
>>>
>>> Chris Boot wrote:
>>>
>>>
>>>> On 12 Aug 2005, at 4:24, Tejun Heo wrote:
>>>>
>>>>
>>>>> Chris Boot wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi all,
>>>>>> I just recently took the plunge and bought 4 250 GB Seagate   
>>>>>> drives  and a 2 port Silicon Image 3112A controller card for  the 
>>>>>> 2  drives my  motherboard doesn't handle. No matter how  hard I 
>>>>>> try, I  can't get the  hard drives to work: they are  detected 
>>>>>> correctly  and work reasonably  well under _very_  light load, but 
>>>>>> anything  like building a RAID array  is a bit  much and the whole 
>>>>>> controller  seems to lock up.
>>>>>> I've tried adding the drive to the blacklist in the sata_sil.c   
>>>>>> driver  and I still have the same trouble: as you can see the   
>>>>>> messages below  relate to my patched kernel with the blacklist   
>>>>>> fix. I've seen that  this was discussed just yesterday, but  that  
>>>>>> seemed to give nothing:  http://www.ussg.iu.edu/hypermail/ linux/ 
>>>>>> kernel/0508.1/0310.html
>>>>>> Ready and willing to hack my kernel to pieces; this machine is  
>>>>>> no  use  until I get all the drives working! Needless to say  the  
>>>>>> drives  connected to the on-board VIA controller work  fine, as 
>>>>>> do  the drives  currently on the SiI controller if I  swap them 
>>>>>> around.
>>>>>> Any ideas?
>>>>>> TIA
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> [added linux-ide to cc list]
>>>>>
>>>>>  Can you please try w/ vanilla kernel (2.6.12 or 2.6.13-rc)?   And  
>>>>> w/ one drive only?
>>>>>
>>>>>
>>>> I unplugged both drives from my on-board SATA controller and  left  
>>>> just one connected to the 3112A controller. Rebooted with a  fresh,  
>>>> vanilla 2.6.13-rc6 and ran:
>>>>
>>>>
>>>
>>>  You can leave drives on on-board SATA controller.  It wouldn't  make 
>>> any difference.
>>>
>>>
>>>
>>>> dd if=/dev/zero of=test.img bs=1M count=16384
>>>> After about 30 seconds I got the crash and the kernel started   
>>>> repeating every 30 seconds (with different sector numbers):
>>>> ata1: command 0x35 timeout, stat 0xd9 host_stat 0x1
>>>> ata1: status=0xd9 { Busy }
>>>> SCSI error : <0 0 0 0> return code = 0x80000002
>>>> sda: Current: sense key=0xb
>>>> ASC=0x47 ASCQ=0x0
>>>> end_request: I/O error, dev sda, sector 14937602
>>>> ATA: abnormal status 0xD9 on port E0802087
>>>> ATA: abnormal status 0xD9 on port E0802087
>>>> ATA: abnormal status 0xD9 on port E0802087
>>>> dmesg:
>>>> Linux version 2.6.13-rc6 (bootc@arcadia.bootc.net) (gcc version   
>>>> 3.3.5-20050130 (Gentoo 3.3.5.20050130-r1, ssp-3.3.5.20050130-1,   
>>>> pie-8.7.7.1)) #1 Fri Aug 12 12:31:25 BST 2005
>>>> ...
>>>> libata version 1.11 loaded.
>>>> sata_sil version 0.9
>>>> ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 18 (level, low) -> IRQ  177
>>>> ata1: SATA max UDMA/100 cmd 0xE0802080 ctl 0xE080208A bmdma   
>>>> 0xE0802000 irq 177
>>>> ata2: SATA max UDMA/100 cmd 0xE08020C0 ctl 0xE08020CA bmdma   
>>>> 0xE0802008 irq 177
>>>> ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4023 85:3469 86:3c01   
>>>> 87:4023 88:207f
>>>> ata1: dev 0 ATA, max UDMA/133, 488397168 sectors: lba48
>>>> ata1: dev 0 configured for UDMA/100
>>>> scsi0 : sata_sil
>>>> ata2: no device found (phy stat 00000000)
>>>> scsi1 : sata_sil
>>>>   Vendor: ATA       Model: ST3250823AS       Rev: 3.03
>>>>   Type:   Direct-Access                      ANSI SCSI revision: 05
>>>> sata_via version 1.1
>>>> ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [ALKA] -> GSI 20  
>>>> (level,  low) -> IRQ 169
>>>> PCI: Via IRQ fixup for 0000:00:0f.0, from 11 to 9
>>>> sata_via(0000:00:0f.0): routed to hard irq line 9
>>>> ata3: SATA max UDMA/133 cmd 0xB400 ctl 0xB802 bmdma 0xC400 irq 169
>>>> ata4: SATA max UDMA/133 cmd 0xBC00 ctl 0xC002 bmdma 0xC408 irq 169
>>>> ata3: no device found (phy stat 00000000)
>>>> scsi2 : sata_via
>>>> ata4: no device found (phy stat 00000000)
>>>> scsi3 : sata_via
>>>> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
>>>> SCSI device sda: drive cache: write back
>>>> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
>>>> SCSI device sda: drive cache: write back
>>>> sda: sda1 sda2 sda3
>>>> Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
>>>> Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,  type 0
>>>> I forgot to mention previously but I even tried with "noapic  
>>>> nolapic  acpi=off pci=routeirq" and got the same trouble.
>>>>
>>>>
>>>
>>>  This is weird as ST3250823AS (and all Seagate .8 drives) are  known 
>>> to work without any problem with sii 3112/3114.  I currently  don't 
>>> own such a drive but someone confirmed me that ST3250823AS  works w/ 
>>> sii 3114 without any problem (including bonnie++ results  and all).  
>>> So, I don't think it's the good old mod15write problem.
>>>
>>>  I hope it's just a bad hardware, cable or something like that;  
>>> otherwise, you're hitting a new bug.  Can you verify if the drive  
>>> works under windows?
>>>
>>
>> Well, what piqued my interest is that the same drives work fine on  my 
>> on-board sata_via controller. All 4 drives were bought at the  same 
>> time and *seem* to be from the same batch, and all work fine  on the 
>> VIA controller and none work on the 3112A. I've also tried  different 
>> cables, all of which are Belkin which I thought were  decent quality.
>>
>> I'll just try installing Winblows and let you know.
> 
> 
> I just installed Windows XP SP2 and Cygwin:
> 
> $ dd if=/dev/zero of=test.img bs=1M count=4096
> 4096+0 records in
> 4096+0 records out
> 4294967296 bytes (4.3GB) copied, 166.27 seconds, 25.8 MB/s
> 
> So it works a treat, although it's slower than maybe it should be:  
> under linux and the VIA controller I get about 50 MB/sec, but that  may 
> just be down to the OS.
> 
> Where do I start to debug the problem?
> 
> Many thanks,
> Chris
> 

[adding cc to Jeff Garzik. (Hi!)]

  Hi again, Chris.

  Unfortunately, I'm as lost as you are.  Can you please do the followings?

  * Verify if read is free from the problem.  ie. does "dd if=/dev/sd? 
of=/dev/null" work?
  * Turn on ATA_DEBUG and ATA_VERBOSE_DEBUG in include/linux/libata.h 
(change #undef's to #define's) and make the drive hang.  The log should 
show what was going on.

-- 
tejun

RE: SiI 3112A + Seagate HDs = still no go?

[Roger Heflin]

With the Segate sata's I worked with before, I had to
actually remove them from the blacklist, this was a couple
of months ago with the native sata seagate disks.

With the drive in the blacklist the drive worked right
under light conditions, but under a dd read from the boot
seagate the entire machine appeared to block on any io
going to that disk, it did not stop (verified by vmstat),
but I could never get the 55-60MiB/second expected, and
was getting around 15MiB/second, with enormous amounts
of interrupts, after removing it from the blacklist,
I got the 55-60MiB/second rate, and the interrupts were
much more reasonable, and the response of the system
was actually useable.    When the lockup occurred, stopping
the dd resulting in all things unlocking and continuing
on, I duplicated this several times with the latest kernel
at the time.

                   Roger 

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org 
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Chris Boot
> Sent: Thursday, August 11, 2005 4:55 PM
> To: linux-kernel@vger.kernel.org
> Subject: SiI 3112A + Seagate HDs = still no go?
> 
> Hi all,
> 
> I just recently took the plunge and bought 4 250 GB Seagate 
> drives and a 2 port Silicon Image 3112A controller card for 
> the 2 drives my motherboard doesn't handle. No matter how 
> hard I try, I can't get the hard drives to work: they are 
> detected correctly and work reasonably well under _very_ 
> light load, but anything like building a RAID array is a bit 
> much and the whole controller seems to lock up.
> 
> I've tried adding the drive to the blacklist in the 
> sata_sil.c driver and I still have the same trouble: as you 
> can see the messages below relate to my patched kernel with 
> the blacklist fix. I've seen that this was discussed just 
> yesterday, but that seemed to give nothing:  
> http://www.ussg.iu.edu/hypermail/linux/kernel/0508.1/0310.html
> 
> Ready and willing to hack my kernel to pieces; this machine 
> is no use until I get all the drives working! Needless to say 
> the drives connected to the on-board VIA controller work 
> fine, as do the drives currently on the SiI controller if I 
> swap them around.
> 
> Any ideas?
> 
> TIA
> Chris
> 
> The following messages are sent to the log when everything goes mad:
> 
> ata1: command 0x35 timeout, stat 0xd8 host_stat 0x0
> ata1: status=0xd8 { Busy }
> SCSI error : <0 0 0 0> return code = 0x80000002
> sda: Current: sense key=0xb
> ASC=0x47 ASCQ=0x0
> end_request: I/O error, dev sda, sector 2990370
> ATA: abnormal status 0xD8 on port E0802087
> ATA: abnormal status 0xD8 on port E0802087
> ATA: abnormal status 0xD8 on port E0802087 [ the above is 
> transcribed so may not be 100% accurate ]
> 
> Dmesg log during boot (and detection):
> 
> Aug 11 21:47:05 arcadia Linux version 2.6.12-gentoo-r6
> (root@arcadia.bootc.net) (gcc version 3.3.5-20050130 (Gentoo 
> 3.3.5.20050130-r1, ssp-3.3.5.20050130-1, pie-8.7.7.1)) #2 Thu 
> Aug 11 20:19:00 BST 2005 ...
> Aug 11 17:30:12 arcadia sata_sil version 0.9 Aug 11 17:30:12 
> arcadia ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 18 (level, 
> low) -> IRQ 177 Aug 11 17:30:12 arcadia ata1: SATA max 
> UDMA/100 cmd 0xE0802080 ctl 0xE080208A bmdma 0xE0802000 irq 
> 177 Aug 11 17:30:12 arcadia ata2: SATA max UDMA/100 cmd 
> 0xE08020C0 ctl 0xE08020CA bmdma 0xE0802008 irq 177 Aug 11 
> 17:30:12 arcadia ata1: dev 0 cfg 49:2f00 82:346b 83:7d01
> 84:4023 85:3469 86:3c01 87:4023 88:207f
> Aug 11 17:30:12 arcadia ata1: dev 0 ATA, max UDMA/133, 488397168
> sectors: lba48
> Aug 11 17:30:12 arcadia ata1(0): applying Seagate errata fix 
> Aug 11 17:30:12 arcadia ata1: dev 0 configured for UDMA/100 
> Aug 11 17:30:12 arcadia scsi0 : sata_sil Aug 11 17:30:12 
> arcadia ata2: dev 0 cfg 49:2f00 82:346b 83:7d01
> 84:4023 85:3469 86:3c01 87:4023 88:207f
> Aug 11 17:30:12 arcadia ata2: dev 0 ATA, max UDMA/133, 488397168
> sectors: lba48
> Aug 11 17:30:12 arcadia ata2(0): applying Seagate errata fix 
> Aug 11 17:30:12 arcadia ata2: dev 0 configured for UDMA/100 
> Aug 11 17:30:12 arcadia scsi1 : sata_sil
> Aug 11 17:30:12 arcadia Vendor: ATA       Model: ST3250823AS        
> Rev: 3.03
> Aug 11 17:30:12 arcadia Type:   Direct-Access                       
> ANSI SCSI revision: 05
> Aug 11 17:30:12 arcadia Vendor: ATA       Model: ST3250823AS        
> Rev: 3.03
> Aug 11 17:30:12 arcadia Type:   Direct-Access                       
> ANSI SCSI revision: 05
> 
> lspci:
> 
> 0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8377 
> [KT400/KT600 AGP] Host Bridge 0000:00:01.0 PCI bridge: VIA 
> Technologies, Inc. VT8235 PCI Bridge 0000:00:0a.0 Unknown 
> mass storage controller: Silicon Image, Inc. SiI
> 3112 [SATALink/SATARaid] Serial ATA Controller (rev 02) 
> 0000:00:0c.0 FireWire (IEEE 1394): Agere Systems (former Lucent
> Microelectronics) FW323 (rev 61)
> 0000:00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA 
> VT6420 SATA RAID Controller (rev 80)
> 0000:00:0f.1 IDE interface: VIA Technologies, Inc. 
> VT82C586A/B/ VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 
> 06) 0000:00:10.0 USB Controller: VIA Technologies, Inc. 
> VT82xxxxx UHCI USB 1.1 Controller (rev 81)
> 0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx 
> UHCI USB 1.1 Controller (rev 81)
> 0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx 
> UHCI USB 1.1 Controller (rev 81)
> 0000:00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx 
> UHCI USB 1.1 Controller (rev 81)
> 0000:00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 
> (rev 86) 0000:00:11.0 ISA bridge: VIA Technologies, Inc. 
> VT8237 ISA bridge [KT600/K8T800/K8T890 South]
> 0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc.  
> VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 
> 0000:00:12.0 Ethernet controller: VIA Technologies, Inc. 
> VT6102 [Rhine-II] (rev 78) 0000:01:00.0 VGA compatible 
> controller: nVidia Corporation NV11
> [GeForce2 MX/MX 400] (rev b2)
> 
> Many thanks,
> Chris
> 
> --
> Chris Boot
> bootc@bootc.net
> http://www.bootc.net/
> 
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: SiI 3112A + Seagate HDs = still no go?

[Chris Boot]

Hi there,

I get very different symptoms indeed. My drive isn't in the  
blacklist, and adding it has little effect (status 0xd9 to 0xd8, no  
other differences). Once the controller hangs, I can't even kill dd  
or login at a different terminal, just a complete lockup. If I have 2  
drives plugged in, running the dd on one of them also hangs the  
other, thus I suspect the controller. Also, reading via dd is fine,  
only writing has trouble.

Chris

On 12 Aug 2005, at 16:19, Roger Heflin wrote:

>
> With the Segate sata's I worked with before, I had to
> actually remove them from the blacklist, this was a couple
> of months ago with the native sata seagate disks.
>
> With the drive in the blacklist the drive worked right
> under light conditions, but under a dd read from the boot
> seagate the entire machine appeared to block on any io
> going to that disk, it did not stop (verified by vmstat),
> but I could never get the 55-60MiB/second expected, and
> was getting around 15MiB/second, with enormous amounts
> of interrupts, after removing it from the blacklist,
> I got the 55-60MiB/second rate, and the interrupts were
> much more reasonable, and the response of the system
> was actually useable.    When the lockup occurred, stopping
> the dd resulting in all things unlocking and continuing
> on, I duplicated this several times with the latest kernel
> at the time.
>
>                    Roger
>
>
>> -----Original Message-----
>> From: linux-kernel-owner@vger.kernel.org
>> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Chris Boot
>> Sent: Thursday, August 11, 2005 4:55 PM
>> To: linux-kernel@vger.kernel.org
>> Subject: SiI 3112A + Seagate HDs = still no go?
>>
>> Hi all,
>>
>> I just recently took the plunge and bought 4 250 GB Seagate
>> drives and a 2 port Silicon Image 3112A controller card for
>> the 2 drives my motherboard doesn't handle. No matter how
>> hard I try, I can't get the hard drives to work: they are
>> detected correctly and work reasonably well under _very_
>> light load, but anything like building a RAID array is a bit
>> much and the whole controller seems to lock up.
>>
>> I've tried adding the drive to the blacklist in the
>> sata_sil.c driver and I still have the same trouble: as you
>> can see the messages below relate to my patched kernel with
>> the blacklist fix. I've seen that this was discussed just
>> yesterday, but that seemed to give nothing:
>> http://www.ussg.iu.edu/hypermail/linux/kernel/0508.1/0310.html
>>
>> Ready and willing to hack my kernel to pieces; this machine
>> is no use until I get all the drives working! Needless to say
>> the drives connected to the on-board VIA controller work
>> fine, as do the drives currently on the SiI controller if I
>> swap them around.
>>
>> Any ideas?
>>
>> TIA
>> Chris
>>
>> The following messages are sent to the log when everything goes mad:
>>
>> ata1: command 0x35 timeout, stat 0xd8 host_stat 0x0
>> ata1: status=0xd8 { Busy }
>> SCSI error : <0 0 0 0> return code = 0x80000002
>> sda: Current: sense key=0xb
>> ASC=0x47 ASCQ=0x0
>> end_request: I/O error, dev sda, sector 2990370
>> ATA: abnormal status 0xD8 on port E0802087
>> ATA: abnormal status 0xD8 on port E0802087
>> ATA: abnormal status 0xD8 on port E0802087 [ the above is
>> transcribed so may not be 100% accurate ]
>>
>> Dmesg log during boot (and detection):
>>
>> Aug 11 21:47:05 arcadia Linux version 2.6.12-gentoo-r6
>> (root@arcadia.bootc.net) (gcc version 3.3.5-20050130 (Gentoo
>> 3.3.5.20050130-r1, ssp-3.3.5.20050130-1, pie-8.7.7.1)) #2 Thu
>> Aug 11 20:19:00 BST 2005 ...
>> Aug 11 17:30:12 arcadia sata_sil version 0.9 Aug 11 17:30:12
>> arcadia ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 18 (level,
>> low) -> IRQ 177 Aug 11 17:30:12 arcadia ata1: SATA max
>> UDMA/100 cmd 0xE0802080 ctl 0xE080208A bmdma 0xE0802000 irq
>> 177 Aug 11 17:30:12 arcadia ata2: SATA max UDMA/100 cmd
>> 0xE08020C0 ctl 0xE08020CA bmdma 0xE0802008 irq 177 Aug 11
>> 17:30:12 arcadia ata1: dev 0 cfg 49:2f00 82:346b 83:7d01
>> 84:4023 85:3469 86:3c01 87:4023 88:207f
>> Aug 11 17:30:12 arcadia ata1: dev 0 ATA, max UDMA/133, 488397168
>> sectors: lba48
>> Aug 11 17:30:12 arcadia ata1(0): applying Seagate errata fix
>> Aug 11 17:30:12 arcadia ata1: dev 0 configured for UDMA/100
>> Aug 11 17:30:12 arcadia scsi0 : sata_sil Aug 11 17:30:12
>> arcadia ata2: dev 0 cfg 49:2f00 82:346b 83:7d01
>> 84:4023 85:3469 86:3c01 87:4023 88:207f
>> Aug 11 17:30:12 arcadia ata2: dev 0 ATA, max UDMA/133, 488397168
>> sectors: lba48
>> Aug 11 17:30:12 arcadia ata2(0): applying Seagate errata fix
>> Aug 11 17:30:12 arcadia ata2: dev 0 configured for UDMA/100
>> Aug 11 17:30:12 arcadia scsi1 : sata_sil
>> Aug 11 17:30:12 arcadia Vendor: ATA       Model: ST3250823AS
>> Rev: 3.03
>> Aug 11 17:30:12 arcadia Type:   Direct-Access
>> ANSI SCSI revision: 05
>> Aug 11 17:30:12 arcadia Vendor: ATA       Model: ST3250823AS
>> Rev: 3.03
>> Aug 11 17:30:12 arcadia Type:   Direct-Access
>> ANSI SCSI revision: 05
>>
>> lspci:
>>
>> 0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8377
>> [KT400/KT600 AGP] Host Bridge 0000:00:01.0 PCI bridge: VIA
>> Technologies, Inc. VT8235 PCI Bridge 0000:00:0a.0 Unknown
>> mass storage controller: Silicon Image, Inc. SiI
>> 3112 [SATALink/SATARaid] Serial ATA Controller (rev 02)
>> 0000:00:0c.0 FireWire (IEEE 1394): Agere Systems (former Lucent
>> Microelectronics) FW323 (rev 61)
>> 0000:00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA
>> VT6420 SATA RAID Controller (rev 80)
>> 0000:00:0f.1 IDE interface: VIA Technologies, Inc.
>> VT82C586A/B/ VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev
>> 06) 0000:00:10.0 USB Controller: VIA Technologies, Inc.
>> VT82xxxxx UHCI USB 1.1 Controller (rev 81)
>> 0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx
>> UHCI USB 1.1 Controller (rev 81)
>> 0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx
>> UHCI USB 1.1 Controller (rev 81)
>> 0000:00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx
>> UHCI USB 1.1 Controller (rev 81)
>> 0000:00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0
>> (rev 86) 0000:00:11.0 ISA bridge: VIA Technologies, Inc.
>> VT8237 ISA bridge [KT600/K8T800/K8T890 South]
>> 0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc.
>> VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
>> 0000:00:12.0 Ethernet controller: VIA Technologies, Inc.
>> VT6102 [Rhine-II] (rev 78) 0000:01:00.0 VGA compatible
>> controller: nVidia Corporation NV11
>> [GeForce2 MX/MX 400] (rev b2)
>>
>> Many thanks,
>> Chris
>>
>> --
>> Chris Boot
>> bootc@bootc.net
>> http://www.bootc.net/
>>
>>
>>
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>>
>
>

-- 
Chris Boot
bootc@bootc.net
http://www.bootc.net/

Re: SiI 3112A + Seagate HDs = still no go?

[Chris Boot]

On 12 Aug 2005, at 15:08, Tejun Heo wrote:

> Chris Boot wrote:
>
>> Hi Tejun,
>> On 12 Aug 2005, at 12:33, Chris Boot wrote:
>>
>>> Hi Tejun,
>>>
>>> On 12 Aug 2005, at 12:28, Tejun Heo wrote:
>>>
>>>
>>>
>>>>
>>>>  Hello, Chris.
>>>>
>>>> Chris Boot wrote:
>>>>
>>>>
>>>>
>>>>> On 12 Aug 2005, at 4:24, Tejun Heo wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Chris Boot wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi all,
>>>>>>> I just recently took the plunge and bought 4 250 GB Seagate    
>>>>>>> drives  and a 2 port Silicon Image 3112A controller card for   
>>>>>>> the 2  drives my  motherboard doesn't handle. No matter how   
>>>>>>> hard I try, I  can't get the  hard drives to work: they are   
>>>>>>> detected correctly  and work reasonably  well under _very_   
>>>>>>> light load, but anything  like building a RAID array  is a  
>>>>>>> bit  much and the whole controller  seems to lock up.
>>>>>>> I've tried adding the drive to the blacklist in the  
>>>>>>> sata_sil.c   driver  and I still have the same trouble: as  
>>>>>>> you can see the   messages below  relate to my patched kernel  
>>>>>>> with the blacklist   fix. I've seen that  this was discussed  
>>>>>>> just yesterday, but  that  seemed to give nothing:  http:// 
>>>>>>> www.ussg.iu.edu/hypermail/ linux/ kernel/0508.1/0310.html
>>>>>>> Ready and willing to hack my kernel to pieces; this machine  
>>>>>>> is  no  use  until I get all the drives working! Needless to  
>>>>>>> say  the  drives  connected to the on-board VIA controller  
>>>>>>> work  fine, as do  the drives  currently on the SiI  
>>>>>>> controller if I  swap them around.
>>>>>>> Any ideas?
>>>>>>> TIA
>>>>>>> Chris
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> [added linux-ide to cc list]
>>>>>>
>>>>>>  Can you please try w/ vanilla kernel (2.6.12 or 2.6.13-rc)?    
>>>>>> And  w/ one drive only?
>>>>>>
>>>>>>
>>>>>>
>>>>> I unplugged both drives from my on-board SATA controller and   
>>>>> left  just one connected to the 3112A controller. Rebooted with  
>>>>> a  fresh,  vanilla 2.6.13-rc6 and ran:
>>>>>
>>>>>
>>>>>
>>>>
>>>>  You can leave drives on on-board SATA controller.  It wouldn't   
>>>> make any difference.
>>>>
>>>>
>>>>
>>>>
>>>>> dd if=/dev/zero of=test.img bs=1M count=16384
>>>>> After about 30 seconds I got the crash and the kernel started    
>>>>> repeating every 30 seconds (with different sector numbers):
>>>>> ata1: command 0x35 timeout, stat 0xd9 host_stat 0x1
>>>>> ata1: status=0xd9 { Busy }
>>>>> SCSI error : <0 0 0 0> return code = 0x80000002
>>>>> sda: Current: sense key=0xb
>>>>> ASC=0x47 ASCQ=0x0
>>>>> end_request: I/O error, dev sda, sector 14937602
>>>>> ATA: abnormal status 0xD9 on port E0802087
>>>>> ATA: abnormal status 0xD9 on port E0802087
>>>>> ATA: abnormal status 0xD9 on port E0802087
>>>>> dmesg:
>>>>> Linux version 2.6.13-rc6 (bootc@arcadia.bootc.net) (gcc  
>>>>> version   3.3.5-20050130 (Gentoo 3.3.5.20050130-r1,  
>>>>> ssp-3.3.5.20050130-1,   pie-8.7.7.1)) #1 Fri Aug 12 12:31:25  
>>>>> BST 2005
>>>>> ...
>>>>> libata version 1.11 loaded.
>>>>> sata_sil version 0.9
>>>>> ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 18 (level, low) ->  
>>>>> IRQ  177
>>>>> ata1: SATA max UDMA/100 cmd 0xE0802080 ctl 0xE080208A bmdma    
>>>>> 0xE0802000 irq 177
>>>>> ata2: SATA max UDMA/100 cmd 0xE08020C0 ctl 0xE08020CA bmdma    
>>>>> 0xE0802008 irq 177
>>>>> ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4023 85:3469  
>>>>> 86:3c01   87:4023 88:207f
>>>>> ata1: dev 0 ATA, max UDMA/133, 488397168 sectors: lba48
>>>>> ata1: dev 0 configured for UDMA/100
>>>>> scsi0 : sata_sil
>>>>> ata2: no device found (phy stat 00000000)
>>>>> scsi1 : sata_sil
>>>>>   Vendor: ATA       Model: ST3250823AS       Rev: 3.03
>>>>>   Type:   Direct-Access                      ANSI SCSI  
>>>>> revision: 05
>>>>> sata_via version 1.1
>>>>> ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [ALKA] -> GSI 20   
>>>>> (level,  low) -> IRQ 169
>>>>> PCI: Via IRQ fixup for 0000:00:0f.0, from 11 to 9
>>>>> sata_via(0000:00:0f.0): routed to hard irq line 9
>>>>> ata3: SATA max UDMA/133 cmd 0xB400 ctl 0xB802 bmdma 0xC400 irq 169
>>>>> ata4: SATA max UDMA/133 cmd 0xBC00 ctl 0xC002 bmdma 0xC408 irq 169
>>>>> ata3: no device found (phy stat 00000000)
>>>>> scsi2 : sata_via
>>>>> ata4: no device found (phy stat 00000000)
>>>>> scsi3 : sata_via
>>>>> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
>>>>> SCSI device sda: drive cache: write back
>>>>> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
>>>>> SCSI device sda: drive cache: write back
>>>>> sda: sda1 sda2 sda3
>>>>> Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
>>>>> Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,   
>>>>> type 0
>>>>> I forgot to mention previously but I even tried with "noapic   
>>>>> nolapic  acpi=off pci=routeirq" and got the same trouble.
>>>>>
>>>>>
>>>>>
>>>>
>>>>  This is weird as ST3250823AS (and all Seagate .8 drives) are   
>>>> known to work without any problem with sii 3112/3114.  I  
>>>> currently  don't own such a drive but someone confirmed me that  
>>>> ST3250823AS  works w/ sii 3114 without any problem (including  
>>>> bonnie++ results  and all).  So, I don't think it's the good old  
>>>> mod15write problem.
>>>>
>>>>  I hope it's just a bad hardware, cable or something like that;   
>>>> otherwise, you're hitting a new bug.  Can you verify if the  
>>>> drive  works under windows?
>>>>
>>>>
>>>
>>> Well, what piqued my interest is that the same drives work fine  
>>> on  my on-board sata_via controller. All 4 drives were bought at  
>>> the  same time and *seem* to be from the same batch, and all work  
>>> fine  on the VIA controller and none work on the 3112A. I've also  
>>> tried  different cables, all of which are Belkin which I thought  
>>> were  decent quality.
>>>
>>> I'll just try installing Winblows and let you know.
>>>
>> I just installed Windows XP SP2 and Cygwin:
>> $ dd if=/dev/zero of=test.img bs=1M count=4096
>> 4096+0 records in
>> 4096+0 records out
>> 4294967296 bytes (4.3GB) copied, 166.27 seconds, 25.8 MB/s
>> So it works a treat, although it's slower than maybe it should  
>> be:  under linux and the VIA controller I get about 50 MB/sec, but  
>> that  may just be down to the OS.
>> Where do I start to debug the problem?
>> Many thanks,
>> Chris
>>
>
> [adding cc to Jeff Garzik. (Hi!)]
>
>  Hi again, Chris.
>
>  Unfortunately, I'm as lost as you are.  Can you please do the  
> followings?
>
>  * Verify if read is free from the problem.  ie. does "dd if=/dev/ 
> sd? of=/dev/null" work?

Works like a treat at 30 MB/s. I do get a few errors in the log  
(repeated a couple of times), but they seem mostly harmless:

ata1: status=0x51 { DriveReady SeekComplete Error }
ata1: error=0x04 { DriveStatusError }

>  * Turn on ATA_DEBUG and ATA_VERBOSE_DEBUG in include/linux/ 
> libata.h (change #undef's to #define's) and make the drive hang.   
> The log should show what was going on.

While untarring and compiling the new kernel I got lots of:

ata1: status=0x51 { DriveReady SeekComplete Error }
ata1: error=0x84 { DriveStatusError BadCRC }

Syslog seems to die log before I get anything useful, and setting  
loglevel 9 with SysRq gives:

ata_fill_sg: PRD[126]: 0x1206A000, 0x1000)
ata_fill_sg: PRD[127]: 0x1206B000, 0x1000)
ata_dev_select: ENTER, ata1: device 0, wait 1
ATA: abnormal status 0xD9 on port 0xE0804087
ATA: abnormal status 0xD9 on port 0xE0804087
ata_tf_load_mmio: hob: feat 0x0 nsect 0x3, lba 0x1 0x0 0x0
ata_tf_load_mmio: feat 0x0 nsect 0xF8 lba 0x1A 0xEF 0x33
ata_tf_load_mmio: device 0xE0
ATA: abnormal statux 0xD9 on port 0xE0804087
ata_exec_command_mmio: ata: cmd 0x35
ata_scsi_translate: EXIT

It then hangs for exactly 30 seconds, and more stuff flies by  
followed by much the same messages EXCEPT:

1. There seems to be one less ata_fill_sg line every time, since PRD 
[XXX] decrements by one every time.
2. The ata_tf_load_mmio lines give different nsect and lba, the  
device stays the same.

Many thanks,
Chris

-- 
Chris Boot
bootc@bootc.net
http://www.bootc.net/

Re: SiI 3112A + Seagate HDs = still no go?

[Tejun Heo]

  Hello, Chris.

Chris Boot wrote:
> On 12 Aug 2005, at 15:08, Tejun Heo wrote:
> 
>>
>> [adding cc to Jeff Garzik. (Hi!)]
>>
>>  Hi again, Chris.
>>
>>  Unfortunately, I'm as lost as you are.  Can you please do the  
>> followings?
>>
>>  * Verify if read is free from the problem.  ie. does "dd if=/dev/ sd? 
>> of=/dev/null" work?
> 
> 
> Works like a treat at 30 MB/s. I do get a few errors in the log  
> (repeated a couple of times), but they seem mostly harmless:
> 
> ata1: status=0x51 { DriveReady SeekComplete Error }
> ata1: error=0x04 { DriveStatusError }

  This is IDE ABRT error and it indicates that something strange is 
going on.  You're not getting this kind of error on VIA controller, right?

>>  * Turn on ATA_DEBUG and ATA_VERBOSE_DEBUG in include/linux/ libata.h 
>> (change #undef's to #define's) and make the drive hang.   The log 
>> should show what was going on.
> 
> 
> While untarring and compiling the new kernel I got lots of:
> 
> ata1: status=0x51 { DriveReady SeekComplete Error }
> ata1: error=0x84 { DriveStatusError BadCRC }

  Wow, this is CRC error.  Something is wrong w/ your controller.

> Syslog seems to die log before I get anything useful, and setting  
> loglevel 9 with SysRq gives:
> 
> ata_fill_sg: PRD[126]: 0x1206A000, 0x1000)
> ata_fill_sg: PRD[127]: 0x1206B000, 0x1000)
> ata_dev_select: ENTER, ata1: device 0, wait 1
> ATA: abnormal status 0xD9 on port 0xE0804087
> ATA: abnormal status 0xD9 on port 0xE0804087
> ata_tf_load_mmio: hob: feat 0x0 nsect 0x3, lba 0x1 0x0 0x0
> ata_tf_load_mmio: feat 0x0 nsect 0xF8 lba 0x1A 0xEF 0x33
> ata_tf_load_mmio: device 0xE0
> ATA: abnormal statux 0xD9 on port 0xE0804087
> ata_exec_command_mmio: ata: cmd 0x35
> ata_scsi_translate: EXIT
> 
> It then hangs for exactly 30 seconds, and more stuff flies by  followed 
> by much the same messages EXCEPT:
> 
> 1. There seems to be one less ata_fill_sg line every time, since PRD 
> [XXX] decrements by one every time.
> 2. The ata_tf_load_mmio lines give different nsect and lba, the  device 
> stays the same.

  30 secs is SCSI command timeout and retrying w/ one less chunk is sd 
driver's error recovery behavior.

  It seems that a lot of errors occur while bits are going through your 
SATA connection.  I don't know about Seagate drives, but my Samsung 
drive sometimes locks up if it gets weird packets/commands.  This might 
be also your case.  PHY-resetting usually gets the drive back online but 
currently libata doesn't do any such error recovery actions.  To make 
sure that it's because of faulty controller, can you please try the 
following?

  * Monitor how IO goes on the drive in Windows.  You can do this by
      - Start->Run and enter perfmon.
      - After perfmon starts, right click on (heh heh, I guess this is
        one of those few times you read this on linux kernel mailing
        list) counter list and select add. Add DiskBytes/sec counter of
        PhysicalDisk object.
      - Adjust scale to 0.0000010.  Also, change color to black to make
        it stand out.
      - start dd.

  I think, if the errors are due to hardware error, the perfmon graph 
will show some stuttering when it hits command timeout.  So, write to 
disk, as writing seems to cause timeouts.  If the problem also happens 
on Windows, it's highly likely that you have a faulty controller.

-- 
tejun

Re: SiI 3112A + Seagate HDs = still no go?

[Chris Boot]

On 13 Aug 2005, at 2:13, Tejun Heo wrote:

>
>  Hello, Chris.
>
> Chris Boot wrote:
>
>> On 12 Aug 2005, at 15:08, Tejun Heo wrote:
>>
>>>
>>> [adding cc to Jeff Garzik. (Hi!)]
>>>
>>>  Hi again, Chris.
>>>
>>>  Unfortunately, I'm as lost as you are.  Can you please do the   
>>> followings?
>>>
>>>  * Verify if read is free from the problem.  ie. does "dd if=/ 
>>> dev/ sd? of=/dev/null" work?
>>>
>> Works like a treat at 30 MB/s. I do get a few errors in the log   
>> (repeated a couple of times), but they seem mostly harmless:
>> ata1: status=0x51 { DriveReady SeekComplete Error }
>> ata1: error=0x04 { DriveStatusError }
>>
>
>  This is IDE ABRT error and it indicates that something strange is  
> going on.  You're not getting this kind of error on VIA controller,  
> right?

I most certainly am not.

>
>>>  * Turn on ATA_DEBUG and ATA_VERBOSE_DEBUG in include/linux/  
>>> libata.h (change #undef's to #define's) and make the drive  
>>> hang.   The log should show what was going on.
>>>
>> While untarring and compiling the new kernel I got lots of:
>> ata1: status=0x51 { DriveReady SeekComplete Error }
>> ata1: error=0x84 { DriveStatusError BadCRC }
>>
>
>  Wow, this is CRC error.  Something is wrong w/ your controller.

Great...

>> Syslog seems to die log before I get anything useful, and setting   
>> loglevel 9 with SysRq gives:
>> ata_fill_sg: PRD[126]: 0x1206A000, 0x1000)
>> ata_fill_sg: PRD[127]: 0x1206B000, 0x1000)
>> ata_dev_select: ENTER, ata1: device 0, wait 1
>> ATA: abnormal status 0xD9 on port 0xE0804087
>> ATA: abnormal status 0xD9 on port 0xE0804087
>> ata_tf_load_mmio: hob: feat 0x0 nsect 0x3, lba 0x1 0x0 0x0
>> ata_tf_load_mmio: feat 0x0 nsect 0xF8 lba 0x1A 0xEF 0x33
>> ata_tf_load_mmio: device 0xE0
>> ATA: abnormal statux 0xD9 on port 0xE0804087
>> ata_exec_command_mmio: ata: cmd 0x35
>> ata_scsi_translate: EXIT
>> It then hangs for exactly 30 seconds, and more stuff flies by   
>> followed by much the same messages EXCEPT:
>> 1. There seems to be one less ata_fill_sg line every time, since  
>> PRD [XXX] decrements by one every time.
>> 2. The ata_tf_load_mmio lines give different nsect and lba, the   
>> device stays the same.
>>
>
>  30 secs is SCSI command timeout and retrying w/ one less chunk is  
> sd driver's error recovery behavior.
>
>  It seems that a lot of errors occur while bits are going through  
> your SATA connection.  I don't know about Seagate drives, but my  
> Samsung drive sometimes locks up if it gets weird packets/ 
> commands.  This might be also your case.  PHY-resetting usually  
> gets the drive back online but currently libata doesn't do any such  
> error recovery actions.  To make sure that it's because of faulty  
> controller, can you please try the following?
>
>  * Monitor how IO goes on the drive in Windows.  You can do this by
>      - Start->Run and enter perfmon.
>      - After perfmon starts, right click on (heh heh, I guess this is
>        one of those few times you read this on linux kernel mailing
>        list) counter list and select add. Add DiskBytes/sec counter of
>        PhysicalDisk object.
>      - Adjust scale to 0.0000010.  Also, change color to black to make
>        it stand out.
>      - start dd.
>
>  I think, if the errors are due to hardware error, the perfmon  
> graph will show some stuttering when it hits command timeout.  So,  
> write to disk, as writing seems to cause timeouts.  If the problem  
> also happens on Windows, it's highly likely that you have a faulty  
> controller.

Some interesting developments!

I installed a fresh copy of Windows, and all the VIA and nVidia and  
so on drivers. At some point during all this (a period of relatively  
heavy disk IO), the computer seemed to crash and I rebooted it. It  
then worked fine for a while, but during my perfmon testing it seemed  
to do the same thing. This time I left it for a while and it did  
eventually wake up again, so I'm guessing the controller is a bit  
fubared. Perfmon did indeed show several dips down to or very close  
to 0 during the write operation, with peaks up to 48 MB/sec, which is  
pretty respectable. So, time to replace the brand-new controller I  
guess.

Now, do you think this is just my one particular controller card and  
a simple return would fix the problem, or is it more likely a problem  
with the whole range? It's an Innovision EIO SATA controller: http:// 
www.ivmm.com/eio/products/index.htm

Would it be a safer bet to go for the Adaptec controller of the same  
variety? How reliable are they?

Many thanks,
Chris

-- 
Chris Boot
bootc@bootc.net
http://www.bootc.net/

Re: SiI 3112A + Seagate HDs = still no go?

[Tejun Heo]

Chris Boot wrote:
> Some interesting developments!
> 
> I installed a fresh copy of Windows, and all the VIA and nVidia and  so 
> on drivers. At some point during all this (a period of relatively  heavy 
> disk IO), the computer seemed to crash and I rebooted it. It  then 
> worked fine for a while, but during my perfmon testing it seemed  to do 
> the same thing. This time I left it for a while and it did  eventually 
> wake up again, so I'm guessing the controller is a bit  fubared. Perfmon 
> did indeed show several dips down to or very close  to 0 during the 
> write operation, with peaks up to 48 MB/sec, which is  pretty 
> respectable. So, time to replace the brand-new controller I  guess.
> 
> Now, do you think this is just my one particular controller card and  a 
> simple return would fix the problem, or is it more likely a problem  
> with the whole range? It's an Innovision EIO SATA controller: http:// 
> www.ivmm.com/eio/products/index.htm
> 
> Would it be a safer bet to go for the Adaptec controller of the same  
> variety? How reliable are they?

  I frankly don't know.  Maybe it's just one faulty controller, 
connector or whatever.  Maybe the card manufacturer screwed up 
somewhere.  I mean, the only course I took in electronics is 
introductory digital circuits which used 74xx chips and push triggered 
clock on a breadboard.  What would I know about gigahertz signaling 
error.  :-p

  Though, one thing I can say is majority of 311x controllers don't seem 
to suffer from this problem.  So, take your pick.

-- 
tejun

Re: SiI 3112A + Seagate HDs = still no go? [SOLVED]

[Chris Boot]

Tejun Heo wrote:

> Chris Boot wrote:
>
>> Some interesting developments!
>>
>> I installed a fresh copy of Windows, and all the VIA and nVidia and  
>> so on drivers. At some point during all this (a period of relatively  
>> heavy disk IO), the computer seemed to crash and I rebooted it. It  
>> then worked fine for a while, but during my perfmon testing it 
>> seemed  to do the same thing. This time I left it for a while and it 
>> did  eventually wake up again, so I'm guessing the controller is a 
>> bit  fubared. Perfmon did indeed show several dips down to or very 
>> close  to 0 during the write operation, with peaks up to 48 MB/sec, 
>> which is  pretty respectable. So, time to replace the brand-new 
>> controller I  guess.
>>
>> Now, do you think this is just my one particular controller card and  
>> a simple return would fix the problem, or is it more likely a 
>> problem  with the whole range? It's an Innovision EIO SATA 
>> controller: http:// www.ivmm.com/eio/products/index.htm
>>
>> Would it be a safer bet to go for the Adaptec controller of the same  
>> variety? How reliable are they?
>
>
>  I frankly don't know.  Maybe it's just one faulty controller, 
> connector or whatever.  Maybe the card manufacturer screwed up 
> somewhere.  I mean, the only course I took in electronics is 
> introductory digital circuits which used 74xx chips and push triggered 
> clock on a breadboard.  What would I know about gigahertz signaling 
> error.  :-p
>
>  Though, one thing I can say is majority of 311x controllers don't 
> seem to suffer from this problem.  So, take your pick.
>
Right, I've replaced my previous controller with an Adaptec AHA-1205SA, 
and I'm rebulding 2 RAID-1 arrays at 50MB/sec without a hitch.

Thanks for your help diagnosing my problem, it was much appreciated!

Many thanks,
Chris

-- 
Chris Boot
bootc@bootc.net
http://www.bootc.net/