* seagate disks on sil3114 - slow?
@ 2007-10-18 4:54 Soeren Sonnenburg
2007-10-18 5:07 ` Jeff Garzik
0 siblings, 1 reply; 7+ messages in thread
From: Soeren Sonnenburg @ 2007-10-18 4:54 UTC (permalink / raw)
To: linux-ide
Dear all,
I just now realize that all disk i.o. on my machine is quite slow
compared with the pata disks I had before. Furthermore I recognized that
I only have seagates (ST3400832AS,ST3400620AS,ST3750640AS,ST3750640AS)
connected to a sil3114 controller.
Being on kernel 2.6.23.1 and stumbling across
http://home-tj.org/wiki/index.php/Sil_m15w I am now wondering if this
patch made it already in kernel (or when it will make it if it is not
yet in/why never).
Best,
Soeren
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: seagate disks on sil3114 - slow?
2007-10-18 4:54 seagate disks on sil3114 - slow? Soeren Sonnenburg
@ 2007-10-18 5:07 ` Jeff Garzik
2007-10-18 8:52 ` Soeren Sonnenburg
0 siblings, 1 reply; 7+ messages in thread
From: Jeff Garzik @ 2007-10-18 5:07 UTC (permalink / raw)
To: Soeren Sonnenburg; +Cc: linux-ide
Soeren Sonnenburg wrote:
> Dear all,
>
> I just now realize that all disk i.o. on my machine is quite slow
> compared with the pata disks I had before. Furthermore I recognized that
> I only have seagates (ST3400832AS,ST3400620AS,ST3750640AS,ST3750640AS)
> connected to a sil3114 controller.
>
> Being on kernel 2.6.23.1 and stumbling across
> http://home-tj.org/wiki/index.php/Sil_m15w I am now wondering if this
> patch made it already in kernel (or when it will make it if it is not
> yet in/why never).
Are you sure you have a 3114? the mod15write isn't applied to that chip.
Does your dmesg say "applying Seagate errata fix (mod15write workaround)" ?
Jeff
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: seagate disks on sil3114 - slow?
2007-10-18 5:07 ` Jeff Garzik
@ 2007-10-18 8:52 ` Soeren Sonnenburg
2007-10-26 2:32 ` Tejun Heo
0 siblings, 1 reply; 7+ messages in thread
From: Soeren Sonnenburg @ 2007-10-18 8:52 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide
On Thu, 2007-10-18 at 01:07 -0400, Jeff Garzik wrote:
> Soeren Sonnenburg wrote:
> > Dear all,
> >
> > I just now realize that all disk i.o. on my machine is quite slow
> > compared with the pata disks I had before. Furthermore I recognized that
> > I only have seagates (ST3400832AS,ST3400620AS,ST3750640AS,ST3750640AS)
> > connected to a sil3114 controller.
> >
> > Being on kernel 2.6.23.1 and stumbling across
> > http://home-tj.org/wiki/index.php/Sil_m15w I am now wondering if this
> > patch made it already in kernel (or when it will make it if it is not
> > yet in/why never).
>
> Are you sure you have a 3114? the mod15write isn't applied to that chip.
> Does your dmesg say "applying Seagate errata fix (mod15write workaround)" ?
At least lspci / dmesg indicates I have a 3114 ... but maybe the problem
is something else. Is there a raw device speed, readonly benchmark to
check whether things are as expected?
Soeren
- lspci
00:0e.0 RAID bus controller: Silicon Image, Inc. SiI 3114
[SATALink/SATARaid] Serial ATA Controller (rev 02)
00:0e.0 0104: 1095:3114 (rev 02)
- dmesg
sata_sil 0000:00:0e.0: version 2.3
ACPI: PCI Interrupt 0000:00:0e.0[A] -> GSI 17 (level, low) -> IRQ 17
sata_sil 0000:00:0e.0: Applying R_ERR on DMA activate FIS errata fix
scsi3 : sata_sil
scsi4 : sata_sil
scsi5 : sata_sil
scsi6 : sata_sil
ata4: SATA max UDMA/100 cmd 0xf882e080 ctl 0xf882e08a bmdma 0xf882e000 irq 17
ata5: SATA max UDMA/100 cmd 0xf882e0c0 ctl 0xf882e0ca bmdma 0xf882e008 irq 17
ata6: SATA max UDMA/100 cmd 0xf882e280 ctl 0xf882e28a bmdma 0xf882e200 irq 17
ata7: SATA max UDMA/100 cmd 0xf882e2c0 ctl 0xf882e2ca bmdma 0xf882e208 irq 17
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata4.00: ATA-7: ST3400832AS, 3.01, max UDMA/133
ata4.00: 781422768 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata4.00: configured for UDMA/100
ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata5.00: ATA-7: ST3400620AS, 3.AAE, max UDMA/133
ata5.00: 781422768 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata5.00: configured for UDMA/100
ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata6.00: ATA-7: ST3750640AS, 3.AAE, max UDMA/133
ata6.00: 1465149168 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata6.00: configured for UDMA/100
ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata7.00: ATA-7: ST3750640AS, 3.AAC, max UDMA/133
ata7.00: 1465149168 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata7.00: configured for UDMA/100
scsi 3:0:0:0: Direct-Access ATA ST3400832AS 3.01 PQ: 0 ANSI: 5
sd 3:0:0:0: [sda] 781422768 512-byte hardware sectors (400088 MB)
sd 3:0:0:0: [sda] Write Protect is off
sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 3:0:0:0: [sda] 781422768 512-byte hardware sectors (400088 MB)
sd 3:0:0:0: [sda] Write Protect is off
sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: unknown partition table
sd 3:0:0:0: [sda] Attached SCSI disk
sd 3:0:0:0: Attached scsi generic sg0 type 0
scsi 4:0:0:0: Direct-Access ATA ST3400620AS 3.AA PQ: 0 ANSI: 5
sd 4:0:0:0: [sdb] 781422768 512-byte hardware sectors (400088 MB)
sd 4:0:0:0: [sdb] Write Protect is off
sd 4:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 4:0:0:0: [sdb] 781422768 512-byte hardware sectors (400088 MB)
sd 4:0:0:0: [sdb] Write Protect is off
sd 4:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sdb: unknown partition table
sd 4:0:0:0: [sdb] Attached SCSI disk
sd 4:0:0:0: Attached scsi generic sg1 type 0
scsi 5:0:0:0: Direct-Access ATA ST3750640AS 3.AA PQ: 0 ANSI: 5
sd 5:0:0:0: [sdc] 1465149168 512-byte hardware sectors (750156 MB)
sd 5:0:0:0: [sdc] Write Protect is off
sd 5:0:0:0: [sdc] Mode Sense: 00 3a 00 00
sd 5:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 5:0:0:0: [sdc] 1465149168 512-byte hardware sectors (750156 MB)
sd 5:0:0:0: [sdc] Write Protect is off
sd 5:0:0:0: [sdc] Mode Sense: 00 3a 00 00
sd 5:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sdc: unknown partition table
sd 5:0:0:0: [sdc] Attached SCSI disk
sd 5:0:0:0: Attached scsi generic sg2 type 0
scsi 6:0:0:0: Direct-Access ATA ST3750640AS 3.AA PQ: 0 ANSI: 5
sd 6:0:0:0: [sdd] 1465149168 512-byte hardware sectors (750156 MB)
sd 6:0:0:0: [sdd] Write Protect is off
sd 6:0:0:0: [sdd] Mode Sense: 00 3a 00 00
sd 6:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 6:0:0:0: [sdd] 1465149168 512-byte hardware sectors (750156 MB)
sd 6:0:0:0: [sdd] Write Protect is off
sd 6:0:0:0: [sdd] Mode Sense: 00 3a 00 00
sd 6:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sdd: unknown partition table
sd 6:0:0:0: [sdd] Attached SCSI disk
sd 6:0:0:0: Attached scsi generic sg3 type 0
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: seagate disks on sil3114 - slow?
2007-10-18 8:52 ` Soeren Sonnenburg
@ 2007-10-26 2:32 ` Tejun Heo
2007-10-26 5:49 ` Soeren Sonnenburg
0 siblings, 1 reply; 7+ messages in thread
From: Tejun Heo @ 2007-10-26 2:32 UTC (permalink / raw)
To: Soeren Sonnenburg; +Cc: Jeff Garzik, linux-ide
Soeren Sonnenburg wrote:
> On Thu, 2007-10-18 at 01:07 -0400, Jeff Garzik wrote:
>> Soeren Sonnenburg wrote:
>>> Dear all,
>>>
>>> I just now realize that all disk i.o. on my machine is quite slow
>>> compared with the pata disks I had before. Furthermore I recognized that
>>> I only have seagates (ST3400832AS,ST3400620AS,ST3750640AS,ST3750640AS)
>>> connected to a sil3114 controller.
>>>
>>> Being on kernel 2.6.23.1 and stumbling across
>>> http://home-tj.org/wiki/index.php/Sil_m15w I am now wondering if this
>>> patch made it already in kernel (or when it will make it if it is not
>>> yet in/why never).
>> Are you sure you have a 3114? the mod15write isn't applied to that chip.
>> Does your dmesg say "applying Seagate errata fix (mod15write workaround)" ?
>
> At least lspci / dmesg indicates I have a 3114 ... but maybe the problem
> is something else. Is there a raw device speed, readonly benchmark to
> check whether things are as expected?
"dd if=/dev/sdX of=/dev/null bs=1M"? Also, does changing IO scheduler
to deadline make any difference?
--
tejun
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: seagate disks on sil3114 - slow?
2007-10-26 2:32 ` Tejun Heo
@ 2007-10-26 5:49 ` Soeren Sonnenburg
2007-10-26 6:08 ` Tejun Heo
0 siblings, 1 reply; 7+ messages in thread
From: Soeren Sonnenburg @ 2007-10-26 5:49 UTC (permalink / raw)
To: Tejun Heo; +Cc: Jeff Garzik, linux-ide
On Fri, 2007-10-26 at 11:32 +0900, Tejun Heo wrote:
> Soeren Sonnenburg wrote:
> > On Thu, 2007-10-18 at 01:07 -0400, Jeff Garzik wrote:
> >> Soeren Sonnenburg wrote:
> >>> Dear all,
> >>>
> >>> I just now realize that all disk i.o. on my machine is quite slow
> >>> compared with the pata disks I had before. Furthermore I recognized that
> >>> I only have seagates (ST3400832AS,ST3400620AS,ST3750640AS,ST3750640AS)
> >>> connected to a sil3114 controller.
> >>>
> >>> Being on kernel 2.6.23.1 and stumbling across
> >>> http://home-tj.org/wiki/index.php/Sil_m15w I am now wondering if this
> >>> patch made it already in kernel (or when it will make it if it is not
> >>> yet in/why never).
> >> Are you sure you have a 3114? the mod15write isn't applied to that chip.
> >> Does your dmesg say "applying Seagate errata fix (mod15write workaround)" ?
> >
> > At least lspci / dmesg indicates I have a 3114 ... but maybe the problem
> > is something else. Is there a raw device speed, readonly benchmark to
> > check whether things are as expected?
looks like I did not fully reply to this one: yes I have a 3114 and
based on Bernds patch to enable m15w support for sil3114 I added the
first two drives to the blacklist and yes I saw the applying mod15write
workaround messages for these disks afterwards. These disks attached to
the internal promise seems to work stably now (uptime is a week now),
with the occasional error that thanks to the new EH is successfully
recovered from - good job!!
> "dd if=/dev/sdX of=/dev/null bs=1M"? Also, does changing IO scheduler
> to deadline make any difference?
OK I knew that one... about 50-60M/s - sounds reasonable, but if I
understand the m15w problem correctly it can only be triggered on
writes...
Soeren
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: seagate disks on sil3114 - slow?
2007-10-26 5:49 ` Soeren Sonnenburg
@ 2007-10-26 6:08 ` Tejun Heo
2007-10-27 5:21 ` Soeren Sonnenburg
0 siblings, 1 reply; 7+ messages in thread
From: Tejun Heo @ 2007-10-26 6:08 UTC (permalink / raw)
To: Soeren Sonnenburg; +Cc: Jeff Garzik, linux-ide
Soeren Sonnenburg wrote:
> On Fri, 2007-10-26 at 11:32 +0900, Tejun Heo wrote:
>> Soeren Sonnenburg wrote:
>>> On Thu, 2007-10-18 at 01:07 -0400, Jeff Garzik wrote:
>>>> Soeren Sonnenburg wrote:
>>>>> Dear all,
>>>>>
>>>>> I just now realize that all disk i.o. on my machine is quite slow
>>>>> compared with the pata disks I had before. Furthermore I recognized that
>>>>> I only have seagates (ST3400832AS,ST3400620AS,ST3750640AS,ST3750640AS)
>>>>> connected to a sil3114 controller.
>>>>>
>>>>> Being on kernel 2.6.23.1 and stumbling across
>>>>> http://home-tj.org/wiki/index.php/Sil_m15w I am now wondering if this
>>>>> patch made it already in kernel (or when it will make it if it is not
>>>>> yet in/why never).
>>>> Are you sure you have a 3114? the mod15write isn't applied to that chip.
>>>> Does your dmesg say "applying Seagate errata fix (mod15write workaround)" ?
>>> At least lspci / dmesg indicates I have a 3114 ... but maybe the problem
>>> is something else. Is there a raw device speed, readonly benchmark to
>>> check whether things are as expected?
>
> looks like I did not fully reply to this one: yes I have a 3114 and
> based on Bernds patch to enable m15w support for sil3114 I added the
> first two drives to the blacklist and yes I saw the applying mod15write
> workaround messages for these disks afterwards. These disks attached to
> the internal promise seems to work stably now (uptime is a week now),
> with the occasional error that thanks to the new EH is successfully
> recovered from - good job!!
>
>> "dd if=/dev/sdX of=/dev/null bs=1M"? Also, does changing IO scheduler
>> to deadline make any difference?
>
> OK I knew that one... about 50-60M/s - sounds reasonable, but if I
> understand the m15w problem correctly it can only be triggered on
> writes...
3114 -> no m15w problem and m15w doesn't slow down transfers. It locks
up certain drives. What slows down transfers is workaround for m15w.
--
tejun
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: seagate disks on sil3114 - slow?
2007-10-26 6:08 ` Tejun Heo
@ 2007-10-27 5:21 ` Soeren Sonnenburg
0 siblings, 0 replies; 7+ messages in thread
From: Soeren Sonnenburg @ 2007-10-27 5:21 UTC (permalink / raw)
To: Tejun Heo; +Cc: Jeff Garzik, linux-ide
On Fri, 2007-10-26 at 15:08 +0900, Tejun Heo wrote:
> Soeren Sonnenburg wrote:
> > On Fri, 2007-10-26 at 11:32 +0900, Tejun Heo wrote:
> [...]
> > OK I knew that one... about 50-60M/s - sounds reasonable, but if I
> > understand the m15w problem correctly it can only be triggered on
> > writes...
>
> 3114 -> no m15w problem and m15w doesn't slow down transfers. It locks
> up certain drives. What slows down transfers is workaround for m15w.
Which means Bernd's sil3114 m15w patch does not fix anything but maybe
just lowered pci-bus load. Well....
Soeren
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2007-10-27 5:21 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-10-18 4:54 seagate disks on sil3114 - slow? Soeren Sonnenburg
2007-10-18 5:07 ` Jeff Garzik
2007-10-18 8:52 ` Soeren Sonnenburg
2007-10-26 2:32 ` Tejun Heo
2007-10-26 5:49 ` Soeren Sonnenburg
2007-10-26 6:08 ` Tejun Heo
2007-10-27 5:21 ` Soeren Sonnenburg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).