* 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).