mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chris Boot <bootc@bootc.net>
To: Tejun Heo <htejun@gmail.com>
Cc: Jeff Garzik <jgarzik@pobox.com>,
	Linux-ide <linux-ide@vger.kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: SiI 3112A + Seagate HDs = still no go?
Date: Fri, 12 Aug 2005 17:27:39 +0100	[thread overview]
Message-ID: <74C9A166-2FDC-45F8-BEB1-A574FD9602D4@bootc.net> (raw)
In-Reply-To: <42FCAD4D.7080707@gmail.com>

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/



  reply	other threads:[~2005-08-12 16:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-11 21:55 Chris Boot
2005-08-12  3:24 ` Tejun Heo
2005-08-12 10:57   ` Chris Boot
2005-08-12 11:28     ` Tejun Heo
2005-08-12 11:33       ` Chris Boot
2005-08-12 13:23         ` Chris Boot
2005-08-12 14:08           ` Tejun Heo
2005-08-12 16:27             ` Chris Boot [this message]
2005-08-13  1:13               ` Tejun Heo
2005-08-13 12:14                 ` Chris Boot
2005-08-13 14:59                   ` Tejun Heo
2005-08-17 10:32                     ` SiI 3112A + Seagate HDs = still no go? [SOLVED] Chris Boot
2005-08-12 15:19 ` SiI 3112A + Seagate HDs = still no go? Roger Heflin
2005-08-12 15:20   ` Chris Boot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=74C9A166-2FDC-45F8-BEB1-A574FD9602D4@bootc.net \
    --to=bootc@bootc.net \
    --cc=htejun@gmail.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®