4 messages, 4 authors, 2004-01-21 · open the first message on its own page
From: Andrew Hogue <hidden>
Date: 2004-01-20 17:11:45
Hi, I just noticed that there is a patch that supposedly enables the S-ATA support with this chipset for the latest kernels. Has anyone tried this patch? How stable is libata for the VIA chipset...? I'm currently using a Silicon Image chipset with no trouble, and we just got a PC in with the VT on it... Please let me know if anyone has any experience with this chipset under linux? Thanks -- Andrew
From: Ming Zhang <hidden>
Date: 2004-01-20 18:06:58
Hi, can u provide more information on your current sata configuration? we have a discussion on what controller to choose right now. thanks a lot. ming On Tue, 2004-01-20 at 12:11, Andrew Hogue wrote:
Hi, I just noticed that there is a patch that supposedly enables the S-ATA support with this chipset for the latest kernels. Has anyone tried this patch? How stable is libata for the VIA chipset...? I'm currently using a Silicon Image chipset with no trouble, and we just got a PC in with the VT on it... Please let me know if anyone has any experience with this chipset under linux? Thanks -- Andrew - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Hendrik Visage <hidden>
Date: 2004-01-21 08:24:04
On Tue, Jan 20, 2004 at 12:11:45PM -0500, Andrew Hogue wrote:
Hi, I just noticed that there is a patch that supposedly enables the S-ATA support with this chipset for the latest kernels.
"stock standard" in 2.6.0
Using my MSI Neo K8T:
hvisage@swartes hvisage $ dmesg -s 128000|grep 8237
VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1
sata_via version 0.11
ata1: SATA max UDMA/133 cmd 0xD800 ctl 0xD402 bmdma 0xC800 irq 10
ata2: SATA max UDMA/133 cmd 0xD000 ctl 0xCC02 bmdma 0xC808 irq 10
ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:407f
ata1: dev 0 ATA, max UDMA/133, 234441648 sectors (lba48)
ata1: dev 0 configured for UDMA/133
scsi0 : sata_via
ata2: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:407f
ata2: dev 0 ATA, max UDMA/133, 234441648 sectors (lba48)
ata2: dev 0 configured for UDMA/133
scsi1 : sata_via
Vendor: ATA Model: ST3120026AS Rev: 0.81
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: ST3120026AS Rev: 0.81
Type: Direct-Access ANSI SCSI revision: 05
<etc.>
Has anyone tried this patch? How stable is libata for the VIA chipset...?
On 2.6.0 & 2.6.1 with the gentoo patches, I only have a single drive that appears to be "problematic", but I suspect either heat or cabling troubles, as it does the same on the Promise 20378 onboard controller. Otherwise I can't complain yet. HEndrik
From: Mark Hahn <hidden>
Date: 2004-01-21 19:02:16
"stock standard" in 2.6.0
with 2.6, it's wise to track patches more aggresively. in particular, I'd go with AKPM's latest mm prepatch and possibly jgarzik's libata update.
Vendor: ATA Model: ST3120026AS Rev: 0.81
Type: Direct-Access ANSI SCSI revision: 05...
quoted
Has anyone tried this patch? How stable is libata for the VIA chipset...?On 2.6.0 & 2.6.1 with the gentoo patches, I only have a single drive that appears to be "problematic", but I suspect either heat or cabling troubles, as it does the same on the Promise 20378 onboard controller.
some Seagate SATA disks have a bug that makes them unable to handle requests that don't contain a multiple of 16 sectors (or something similar). the latest libata patch has a quirk list to pick out those specific drives, and handle them. previously, iirc, all ST's were worked around, with serious performance implications. the model above is not in the quirk list. the quirk isn't controller-specific.