Re: SiI 3112A + Seagate HDs = still no go? [SOLVED]
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 [EMAIL PROTECTED] http://www.bootc.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SiI 3112A + Seagate HDs = still no go? [SOLVED]
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 [EMAIL PROTECTED] http://www.bootc.net/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SiI 3112A + Seagate HDs = still no go?
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SiI 3112A + Seagate HDs = still no go?
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.010. 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
[EMAIL PROTECTED]
http://www.bootc.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SiI 3112A + Seagate HDs = still no go?
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.010. 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
[EMAIL PROTECTED]
http://www.bootc.net/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SiI 3112A + Seagate HDs = still no go?
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SiI 3112A + Seagate HDs = still no go?
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.010. 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SiI 3112A + Seagate HDs = still no go?
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 = 0x8002
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 ([EMAIL PROTECTED]) (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 :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 )
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 :00:0f.0[B] -> Link [ALKA] -> GSI 20
(level, low) -> IRQ 169
PCI: Via IRQ fixup for :00:0f.0, from 11 to 9
sata_via(: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 )
scsi2 : sata_via
ata4: no device found (phy stat )
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
Re: SiI 3112A + Seagate HDs = still no go?
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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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 = 0x8002
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
([EMAIL PROTECTED]) (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 :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:
:00:00.0 Host bridge: VIA Technologies, Inc. VT8377
[KT400/KT600 AGP] Host Bridge :00:01.0 PCI bridge: VIA
Technologies, Inc. VT8235 PCI Bridge :00:0a.0 Unknown
mass storage controller: Silicon Image, Inc. SiI
3112 [SATALink/SATARaid] Serial ATA Controller (rev 02)
:00:0c.0 FireWire (IEEE 1394):
RE: SiI 3112A + Seagate HDs = still no go?
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: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] 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 = 0x8002
> 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
> ([EMAIL PROTECTED]) (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 :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:
>
> :00:00.0 Host bridge: VIA Technologies, Inc. VT8377
> [KT400/KT600 AGP] Host Bridge :00:01.0 PCI bridge: VIA
> Technologies, Inc. VT8235 PCI Bridge :00:0a.0 Unknown
> mass storage controller: Silicon Image, Inc. SiI
> 3112 [SATALink/SATARaid] Serial ATA Controller (rev 02)
> :00:0c.0 FireWire (IEEE 1394): Agere Systems (former Lucent
> Microelectronics) FW323 (rev 61)
> :00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA
> VT6420 SATA RAID Controller (rev 80)
> :00:0f.1 IDE interface: VIA Technologies, Inc.
>
Re: SiI 3112A + Seagate HDs = still no go?
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 = 0x8002
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 ([EMAIL PROTECTED]) (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 :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 )
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 :00:0f.0[B] -> Link [ALKA] -> GSI 20
(level, low) -> IRQ 169
PCI: Via IRQ fixup for :00:0f.0, from 11 to 9
sata_via(: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 )
scsi2 : sata_via
ata4: no device found (phy stat )
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
Re: SiI 3112A + Seagate HDs = still no go?
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 = 0x8002
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 ([EMAIL PROTECTED]) (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 :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 )
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 :00:0f.0[B] -> Link [ALKA] -> GSI 20
(level, low) -> IRQ 169
PCI: Via IRQ fixup for :00:0f.0, from 11 to 9
sata_via(: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 )
scsi2 : sata_via
ata4: no device found (phy stat )
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
Re: SiI 3112A + Seagate HDs = still no go?
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 = 0x8002
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 ([EMAIL PROTECTED]) (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 :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 )
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 :00:0f.0[B] -> Link [ALKA] -> GSI 20
(level, low) -> IRQ 169
PCI: Via IRQ fixup for :00:0f.0, from 11 to 9
sata_via(: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 )
scsi2 : sata_via
ata4: no device found (phy stat )
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
[EMAIL PROTECTED]
http://www.bootc.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Re: SiI 3112A + Seagate HDs = still no go?
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 = 0x8002
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 ([EMAIL PROTECTED]) (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 :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 )
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 :00:0f.0[B] -> Link [ALKA] -> GSI 20 (level,
low) -> IRQ 169
PCI: Via IRQ fixup for :00:0f.0, from 11 to 9
sata_via(: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 )
scsi2 : sata_via
ata4: no device found (phy stat )
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SiI 3112A + Seagate HDs = still no go?
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 = 0x8002
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 ([EMAIL PROTECTED]) (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 :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 )
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 :00:0f.0[B] -> Link [ALKA] -> GSI 20 (level,
low) -> IRQ 169
PCI: Via IRQ fixup for :00:0f.0, from 11 to 9
sata_via(: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 )
scsi2 : sata_via
ata4: no device found (phy stat )
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
[EMAIL PROTECTED]
http://www.bootc.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SiI 3112A + Seagate HDs = still no go?
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 = 0x8002
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 ([EMAIL PROTECTED]) (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 :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 )
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 :00:0f.0[B] - Link [ALKA] - GSI 20 (level,
low) - IRQ 169
PCI: Via IRQ fixup for :00:0f.0, from 11 to 9
sata_via(: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 )
scsi2 : sata_via
ata4: no device found (phy stat )
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
[EMAIL PROTECTED]
http://www.bootc.net/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SiI 3112A + Seagate HDs = still no go?
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 = 0x8002
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 ([EMAIL PROTECTED]) (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 :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 )
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 :00:0f.0[B] - Link [ALKA] - GSI 20 (level,
low) - IRQ 169
PCI: Via IRQ fixup for :00:0f.0, from 11 to 9
sata_via(: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 )
scsi2 : sata_via
ata4: no device found (phy stat )
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SiI 3112A + Seagate HDs = still no go?
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 = 0x8002
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 ([EMAIL PROTECTED]) (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 :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 )
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 :00:0f.0[B] - Link [ALKA] - GSI 20
(level, low) - IRQ 169
PCI: Via IRQ fixup for :00:0f.0, from 11 to 9
sata_via(: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 )
scsi2 : sata_via
ata4: no device found (phy stat )
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
[EMAIL PROTECTED]
http://www.bootc.net/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Re: SiI 3112A + Seagate HDs = still no go?
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 = 0x8002
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 ([EMAIL PROTECTED]) (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 :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 )
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 :00:0f.0[B] - Link [ALKA] - GSI 20
(level, low) - IRQ 169
PCI: Via IRQ fixup for :00:0f.0, from 11 to 9
sata_via(: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 )
scsi2 : sata_via
ata4: no device found (phy stat )
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
Re: SiI 3112A + Seagate HDs = still no go?
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 = 0x8002
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 ([EMAIL PROTECTED]) (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 :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 )
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 :00:0f.0[B] - Link [ALKA] - GSI 20
(level, low) - IRQ 169
PCI: Via IRQ fixup for :00:0f.0, from 11 to 9
sata_via(: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 )
scsi2 : sata_via
ata4: no device found (phy stat )
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
RE: SiI 3112A + Seagate HDs = still no go?
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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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 = 0x8002
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
([EMAIL PROTECTED]) (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 :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:
:00:00.0 Host bridge: VIA Technologies, Inc. VT8377
[KT400/KT600 AGP] Host Bridge :00:01.0 PCI bridge: VIA
Technologies, Inc. VT8235 PCI Bridge :00:0a.0 Unknown
mass storage controller: Silicon Image, Inc. SiI
3112 [SATALink/SATARaid] Serial ATA Controller (rev 02)
:00:0c.0 FireWire (IEEE 1394): Agere Systems (former Lucent
Microelectronics) FW323 (rev 61)
:00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA
VT6420 SATA RAID Controller (rev 80)
:00:0f.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/ VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev
06) :00:10.0 USB Controller: VIA
Re: SiI 3112A + Seagate HDs = still no go?
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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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 = 0x8002
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
([EMAIL PROTECTED]) (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 :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:
:00:00.0 Host bridge: VIA Technologies, Inc. VT8377
[KT400/KT600 AGP] Host Bridge :00:01.0 PCI bridge: VIA
Technologies, Inc. VT8235 PCI Bridge :00:0a.0 Unknown
mass storage controller: Silicon Image, Inc. SiI
3112 [SATALink/SATARaid] Serial ATA Controller (rev 02)
:00:0c.0 FireWire (IEEE 1394):
Re: SiI 3112A + Seagate HDs = still no go?
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 = 0x8002
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 ([EMAIL PROTECTED]) (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 :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 )
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 :00:0f.0[B] - Link [ALKA] - GSI 20
(level, low) - IRQ 169
PCI: Via IRQ fixup for :00:0f.0, from 11 to 9
sata_via(: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 )
scsi2 : sata_via
ata4: no device found (phy stat )
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
Re: SiI 3112A + Seagate HDs = still no go?
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.010. 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SiI 3112A + Seagate HDs = still no go?
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SiI 3112A + Seagate HDs = still no go?
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
