Re: libata pm
Hi everybody,
it looks like this will be a never ending story...
>>> After I got the new PSU and the raid was in full sync without any
>>> error for 48h, I thought all problems were gone. Today the sata errors
>>> reappeared and whenever the load is high enough I get the following:
>>>
I exchanged two (probably failing) of the eight harddrives with new ones.
All remaining disks have a good smart state and are fully readable when
the raid is not active. As long as I mount the filesystem on the raid
readonly there wont happen any error, but the moment I mount it rw and try
to copy something to the fs on the raid I get the already known timeout.
At least I get a little bit desperate now...
ata10.00: failed to read SCR 1 (Emask=0x40)
ata10.01: failed to read SCR 1 (Emask=0x40)
ata10.02: failed to read SCR 1 (Emask=0x40)
ata10.03: failed to read SCR 1 (Emask=0x40)
ata10.04: failed to read SCR 1 (Emask=0x40)
ata10.05: failed to read SCR 1 (Emask=0x40)
ata10.00: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.01: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.01: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 1 cdb 0x0 data 0
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata10.01: status: { DRDY }
ata10.02: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.03: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.04: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.05: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.15: hard resetting link
ata10.15: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
ata10.00: hard resetting link
ata10.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata10.01: hard resetting link
ata10.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata10.02: hard resetting link
ata10.02: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata10.03: hard resetting link
ata10.03: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata10.04: hard resetting link
ata10.04: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata10.05: hard resetting link
ata10.05: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata10.00: configured for UDMA/100
ata10.01: configured for UDMA/100
ata10.03: configured for UDMA/100
ata10.04: configured for UDMA/100
ata10: EH complete
sd 9:0:0:0: [sdl] 976773168 512-byte hardware sectors (500108 MB)
sd 9:0:0:0: [sdl] Write Protect is off
sd 9:0:0:0: [sdl] Mode Sense: 00 3a 00 00
sd 9:0:0:0: [sdl] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 9:1:0:0: [sdm] 976773168 512-byte hardware sectors (500108 MB)
sd 9:1:0:0: [sdm] Write Protect is off
sd 9:1:0:0: [sdm] Mode Sense: 00 3a 00 00
sd 9:1:0:0: [sdm] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 9:2:0:0: [sdn] 976773168 512-byte hardware sectors (500108 MB)
sd 9:2:0:0: [sdn] Write Protect is off
sd 9:2:0:0: [sdn] Mode Sense: 00 3a 00 00
sd 9:2:0:0: [sdn] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 9:3:0:0: [sdo] 976773168 512-byte hardware sectors (500108 MB)
sd 9:3:0:0: [sdo] Write Protect is off
sd 9:3:0:0: [sdo] Mode Sense: 00 3a 00 00
sd 9:3:0:0: [sdo] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 9:4:0:0: [sdp] 976773168 512-byte hardware sectors (500108 MB)
sd 9:4:0:0: [sdp] Write Protect is off
sd 9:4:0:0: [sdp] Mode Sense: 00 3a 00 00
sd 9:4:0:0: [sdp] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata pm
Am Fr, 1.02.2008, 14:06, schrieb Mark Lord:
> [EMAIL PROTECTED] wrote:
>>>> Sorry for my late answer, but i had to sort this out first.
>>>> After replacing the first PSU with a new Corsair 650W the power no
>>>> longer fluctuated more than 0,01 V (and this only when booting up
>>>> the drives...) I did a full resync on both raid arrays and got no
>>>> more errors or resets, but there were some inconsitencies during
>>>> sync and the xfs filesystem on both arrays had to be repaired. Are
>>>> these problems caused by the pm resets ?
>>>>
>>> libata EH won't lose any data as long as the hardware doesn't. If
>>> power fluctuates causing your drive to briefly power down - this does
>>> happen and you can hear the drive doing emergency unload when it
>>> happens, the data in write buffer can be lost. On coming back, all
>>> that libata can know is that the PHY suffered brief connection loss,
>>> so it resets the device and goes on, so the data in the cache is lost
>>> now. It's basically pulling the power plug from the harddrive while
>>> write is going on and connecting it back quickly. You're bound to
>>> lose data.
>>>
>> After I got the new PSU and the raid was in full sync without any error
>> for 48h, I thought all problems were gone. Today the sata errors
>> reappeared and whenever the load is high enough I get the following:
> ..
>
>
> What exact brand/model drives are those again (hdparm --Istdout, please)
> ?
>
>
> If I have a similar unit here, I may try to reproduce this.
>
>
Yes, of course. This is the failing drive:
hdparm --Istdout /dev/sdn
/dev/sdn:
0040 3fff c837 0010 8856 022a 003f
5330 4d55 4a31 4650 3930 3136
3432 2020 2020 2020 0003 8000 0004 4352
3130 302d 3131 5341 4d53 554e 4720 4844
3530 314c 4a20 2020 2020 2020 2020 2020
2020 2020 2020 2020 2020 2020 2020 8010
2f00 4000 0200 0200 0007 3fff 0010
003f fc10 00fb 0fff 0007
0003 0078 0078 0078 0078
001f 0706 004c 0040
01f8 0052 746b 7f01 4123 7469 bc01 4123
20ff 0054 0054 fffe fe00
6030 3a38
5000 0f00 1b90 1642
4014
4014
0021
0400 0e00 0003
9a00 0300 2400 6a20 3231
003f
100f
0001 0400
9ca5
And now all others: (All the same model Samsung HD501LJ)
hdparm --Istdout /dev/sdo
/dev/sdo:
0040 3fff c837 0010 8856 022a 003f
5330 4d55 4a31 4450 3932 3433
3833 2020 2020 2020 0003 8000 0004 4352
3130 302d 3131 5341 4d53 554e 4720 4844
3530 314c 4a20 2020 2020 2020 2020 2020
2020 2020 2020 2020 2020 2020 2020 8010
2f00 4000 0200 0200 0007 3fff 0010
003f fc10 00fb 0fff 0007
0003 0078 0078 0078 0078
001f 0706 004c 0040
01f8 0052 746b 7f01 4123 7469 bc01 4123
20ff 0054 0054 fffe fe00
6030 3a38
5000 0f00 1b92 4383
4014
4014
0021
0400 0e00 0003
9a00 0300 2400 6a20 3231
003f
100f
0001 0400
27a5
hdparm --Istdout /dev/sdp
/dev/sdp:
0040 3fff c837 0010 8856 022a 003f
2020 2020 2020 5330 5a46 4a31
4d50 3930 3538 3734 0003 8000 0004 4352
3130 302d 3131 5341 4d53 554e 4720 4844
3530 314c 4a20 2020 2020 2020 2020 2020
2020 2020 2020 2020 2020 2020 2020 8010
2f00 4000 0200 0200 0007 3fff 0010
003f fc10 00fb 0fff 0007
0003 0078 0078 0078 0078
001f 0706 004c 0040
01f8 0052 746b 7f01 4123 7469 be01 4123
20ff 0054 00
Re: libata pm
otect is off
sd 9:3:0:0: [sdo] Mode Sense: 00 3a 00 00
sd 9:3:0:0: [sdo] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 9:4:0:0: [sdp] 976773168 512-byte hardware sectors (500108 MB)
sd 9:4:0:0: [sdp] Write Protect is off
sd 9:4:0:0: [sdp] Mode Sense: 00 3a 00 00
sd 9:4:0:0: [sdp] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
ata10.00: failed to read SCR 1 (Emask=0x40)
ata10.01: failed to read SCR 1 (Emask=0x40)
ata10.02: failed to read SCR 1 (Emask=0x40)
ata10.03: failed to read SCR 1 (Emask=0x40)
ata10.04: failed to read SCR 1 (Emask=0x40)
ata10.05: failed to read SCR 1 (Emask=0x40)
ata10.00: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.01: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.02: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.02: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 2 cdb 0x0 data 0
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata10.02: status: { DRDY }
ata10.03: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.04: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.05: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.15: hard resetting link
ata10.15: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
ata10.00: hard resetting link
ata10.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata10.01: hard resetting link
ata10.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata10.02: hard resetting link
ata10.02: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata10.03: hard resetting link
ata10.03: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata10.04: hard resetting link
ata10.04: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata10.05: hard resetting link
ata10.05: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata10.00: configured for UDMA/100
ata10.01: configured for UDMA/100
ata10.02: configured for UDMA/100
ata10.03: configured for UDMA/100
ata10.04: configured for UDMA/100
ata10: EH complete
sd 9:0:0:0: [sdl] 976773168 512-byte hardware sectors (500108 MB)
sd 9:0:0:0: [sdl] Write Protect is off
sd 9:0:0:0: [sdl] Mode Sense: 00 3a 00 00
sd 9:0:0:0: [sdl] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 9:1:0:0: [sdm] 976773168 512-byte hardware sectors (500108 MB)
sd 9:1:0:0: [sdm] Write Protect is off
sd 9:1:0:0: [sdm] Mode Sense: 00 3a 00 00
sd 9:1:0:0: [sdm] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 9:2:0:0: [sdn] 976773168 512-byte hardware sectors (500108 MB)
sd 9:2:0:0: [sdn] Write Protect is off
sd 9:2:0:0: [sdn] Mode Sense: 00 3a 00 00
sd 9:2:0:0: [sdn] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 9:3:0:0: [sdo] 976773168 512-byte hardware sectors (500108 MB)
sd 9:3:0:0: [sdo] Write Protect is off
sd 9:3:0:0: [sdo] Mode Sense: 00 3a 00 00
sd 9:3:0:0: [sdo] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 9:4:0:0: [sdp] 976773168 512-byte hardware sectors (500108 MB)
sd 9:4:0:0: [sdp] Write Protect is off
sd 9:4:0:0: [sdp] Mode Sense: 00 3a 00 00
sd 9:4:0:0: [sdp] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 9:0:0:0: [sdl] 976773168 512-byte hardware sectors (500108 MB)
sd 9:0:0:0: [sdl] Write Protect is off
sd 9:0:0:0: [sdl] Mode Sense: 00 3a 00 00
sd 9:0:0:0: [sdl] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 9:1:0:0: [sdm] 976773168 512-byte hardware sectors (500108 MB)
sd 9:1:0:0: [sdm] Write Protect is off
sd 9:1:0:0: [sdm] Mode Sense: 00 3a 00 00
sd 9:1:0:0: [sdm] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 9:2:0:0: [sdn] 976773168 512-byte hardware sectors (500108 MB)
sd 9:2:0:0: [sdn] Write Protect is off
sd 9:2:0:0: [sdn] Mode Sense: 00 3a 00 00
sd 9:2:0:0: [sdn] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 9:3:0:0: [sdo] 976773168 512-byte hardware sectors (500108 MB)
sd 9:3:0:0: [sdo] Write Protect is off
sd 9:3:0:0: [sdo] Mode Sense: 00 3a 00 00
sd 9:3:0:0: [sdo] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 9:4:0:0: [sdp] 976773168 512-byte hardware sectors (500108 MB)
sd 9:4:0:0: [sdp] Write Protect is off
sd 9:4:0:0: [sdp] Mode Sense: 00 3a 00 00
sd 9:4:0:0: [sdp] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata pm
>> Shuffling the drives did not change anything to the linkspeed of the 3 >> ports running with 1.5 Gbps. Looks like the problem is port-related. > > Hmm... Okay. Maybe the signal traces or connectors have some problems. > But 3.0Gbps on downstream port doesn't make any difference anyway so > unless it leads to errors, it should be fine. > >> The first PSU (Multilane) offers (measured) 12,20 V on both lanes. This >> falls during read/write access on all drives attached down to 12,10 V. >> > > That explains the PHY dropouts. I've even seen drives to do hard reset > accompanying emergency head unload due to voltage dropping when high IO > load hits. Of course, data in cache is lost. > >> The second PSU (Singlelane) offers (measured) 11,75 V. This doesn't >> change during read/write access on all drives attached. I tested the >> second PSU without anything attached and it still offered 11,75 V. > > 11.75 is still in spec and it doesn't fluctuate. I like this power much > better. > >> I will try to add another PSU this evening and remeasure. >> Currently the whole machine needs about 350W. >> The PSUs are Targan 500W (Multilane - 2x12V 10A) >> > > Maybe one of the lane is only connected to video power connectors? > IIRC, that was the idea of multilane power anyway. > > > Please lemme know your test result. > Sorry for my late answer, but i had to sort this out first. After replacing the first PSU with a new Corsair 650W the power no longer fluctuated more than 0,01 V (and this only when booting up the drives...) I did a full resync on both raid arrays and got no more errors or resets, but there were some inconsitencies during sync and the xfs filesystem on both arrays had to be repaired. Are these problems caused by the pm resets ? Thanks for your patience. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata pm
Hello,
Am Mo, 28.01.2008, 01:17, schrieb Tejun Heo:
> Hello,
>
>
> [EMAIL PROTECTED] wrote:
>> With one, two and three drives on the pm I got no errors, so I tried to
>> change the power supply. I got two power supplies for the 16
>> harddrives and the second one (with all Maxtor drives and the first pm)
>> was failing. After changing the power supply all problems where gone.
>> Sorry for the
>> confusion.
>
> It's amazing that, in SATA, PSU-problem-verified / PSU-problem-suggested
> ratio is significant. I don't think this ever was the case with PATA. SATA
> link seems much more susceptible to power quality and allows hooking up
> whole lot of drives.
>
>
>> The only remaining issue is that some sata links are only working with
>> 1.5
>> gbps and I can't figure out why. (ata3,4,5,6.x are the Maxtor drives and
>> ata7,8,9,10.x are the Samsung ones)
>>
>
> Hmm... That's how the hardware negotiated transfer rate w/ each other.
> SControl is telling the hardware that there's no speed limit and to go
> as high as it can but somehow 3.0Gbps negotiation failed and the link speed
> is limited to 1.5Gbps for some of the ports. Is the result always the
> same? What happens if you swap drives between ports? Also, if you have
> an extra PSU lying around, can you hook it up with some of the drives such
> that the load is more distributed.
>
> Oh.. Another note on PSU. I don't know whether this still holds for
> more recent ones but mid-to-high range multi-lane PSUs sometimes have
> lesser juice on 12v rail available for disks than low cost single lane
> PSUs. This is because high power 12v lanes are allocated to power video
> cards and disks can only pull power from (usually) single weak 12v lane.
>
> Thanks.
>
>
> --
> tejun
>
>
Shuffling the drives did not change anything to the linkspeed of the 3
ports running with 1.5 Gbps. Looks like the problem is port-related.
The first PSU (Multilane) offers (measured) 12,20 V on both lanes. This
falls during read/write access on all drives attached down to 12,10 V.
The second PSU (Singlelane) offers (measured) 11,75 V. This doesn't change
during read/write access on all drives attached. I tested the second PSU
without anything attached and it still offered 11,75 V.
I will try to add another PSU this evening and remeasure.
Currently the whole machine needs about 350W.
The PSUs are Targan 500W (Multilane - 2x12V 10A) and Noname 350W
(Singlelane - 1x12V 10A) so this 'should' be enough...
This night i copied the backup back to the first raid (the Maxtor drives)
without any error but during the transfer i got this on the second
(mounted but unused) raid:
ata10.00: failed to read SCR 1 (Emask=0x40)
ata10.01: failed to read SCR 1 (Emask=0x40)
ata10.02: failed to read SCR 1 (Emask=0x40)
ata10.03: failed to read SCR 1 (Emask=0x40)
ata10.04: failed to read SCR 1 (Emask=0x40)
ata10.05: failed to read SCR 1 (Emask=0x40)
ata10.00: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.01: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.02: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.02: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 1 cdb 0x0 data 0
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata10.02: status: { DRDY }
ata10.03: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.04: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.05: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata10.15: hard resetting link
ata10.15: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
ata10.00: hard resetting link
ata10.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata10.01: hard resetting link
ata10.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata10.02: hard resetting link
ata10.02: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata10.03: hard resetting link
ata10.03: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata10.04: hard resetting link
ata10.04: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata10.05: hard resetting link
ata10.05: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata10.00: configured for UDMA/100
ata10.01: configured for UDMA/100
ata10.02: configured for UDMA/100
ata10.03: configured for UDMA/100
ata10.04: configured for UDMA/100
ata10: EH complete
sd 9:0:0:0: [sdp] 976773168 512-byte hardware sectors (500108 MB)
sd 9:0:0:0: [sdp] Write Protect is off
sd 9:0:0:0: [sdp] Mode Sense: 00 3a 00 00
sd 9:0:0:0: [sdp] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 9:1:0:0: [sdq] 976773168 512-byte hardware sectors (500108 MB)
sd 9:1:0:0: [sdq] Write Protect is off
sd 9:1:0:0: [sdq] Mode Sense: 00 3a 00 00
sd 9:1:0:0: [sdq] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 9:2:0:0: [sdr] 9
Re: libata pm
Am So, 27.01.2008, 01:38, schrieb [EMAIL PROTECTED]: > Am Sa, 26.01.2008, 23:33, schrieb Tejun Heo: > >> [EMAIL PROTECTED] wrote: >>> I could solve the problem by ncq blacklisting the "Maxtor 6V300F0" >>> devices in libata-core.c >> >> That's a strange story. The reported error was PHY readiness changed >> and Device exchanged, both of which point to hotplug event. Maybe >> something causes the firmware to reset? What happen if you only leave >> two drives on the port multiplier and remove the NCQ blacklist? Also, >> does the error ever occur on the drives which are connected directly to >> the controller? >> >> >> -- >> tejun >> >> > > No the error only occures on the drives on the pm. I can test the pm with > two Maxtor drives tomorrow (currently backing up the raid). > > With one, two and three drives on the pm I got no errors, so I tried to change the power supply. I got two power supplies for the 16 harddrives and the second one (with all Maxtor drives and the first pm) was failing. After changing the power supply all problems where gone. Sorry for the confusion. The only remaining issue is that some sata links are only working with 1.5 gbps and I can't figure out why. (ata3,4,5,6.x are the Maxtor drives and ata7,8,9,10.x are the Samsung ones) jasmin ~ # dmesg | grep Gbps ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata6.00: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata6.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata6.02: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata6.03: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata6.04: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata6.05: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata8: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata9: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata10: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata10.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata10.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata10.02: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata10.03: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata10.04: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata10.05: SATA link up 1.5 Gbps (SStatus 113 SControl 300) - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata pm
Am Sa, 26.01.2008, 23:33, schrieb Tejun Heo: > [EMAIL PROTECTED] wrote: >> I could solve the problem by ncq blacklisting the "Maxtor 6V300F0" >> devices in libata-core.c > > That's a strange story. The reported error was PHY readiness changed > and Device exchanged, both of which point to hotplug event. Maybe > something causes the firmware to reset? What happen if you only leave two > drives on the port multiplier and remove the NCQ blacklist? Also, does > the error ever occur on the drives which are connected directly to the > controller? > > > -- > tejun > > No the error only occures on the drives on the pm. I can test the pm with two Maxtor drives tomorrow (currently backing up the raid). - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata pm
I could solve the problem by ncq blacklisting the "Maxtor 6V300F0" devices
in libata-core.c
Am Sa, 26.01.2008, 18:03, schrieb [EMAIL PROTECTED]:
> I'm currently running
>
>
> Linux *** 2.6.23 #1 SMP PREEMPT Sat Jan 26 17:59:58 CET 2008 x86_64
> Intel(R) Pentium(R) D CPU 3.20GHz GenuineIntel GNU/Linux
> with the libata-tj-2.6.23-20071011 path for 2.6.23
>
> and for testing purposes
>
> linux-2.6.24-rc6-mm1
>
>
> on a Asus P5WDG2-WS with two PCI-X Dawicontrol DC 4300 Controllers and
> two Dawicontrol DC 6510 PM port multipliers to get 16 sata ports. (the
> linux partition is on a ide drive)
>
> the second raid array with 8 Samsung HD-LJ 501 works great without any
> errors. but the first raid with 8 Maxtor 6V300F0 produces one error after
> another after mounting the filesystem:
>
> Filesystem "dm-0": Disabling barriers, not supported by the underlying
> device XFS mounting filesystem dm-0
> Ending clean XFS mount for filesystem: dm-0
> Filesystem "dm-1": Disabling barriers, not supported by the underlying
> device XFS mounting filesystem dm-1
> Ending clean XFS mount for filesystem: dm-1
> ata6.04: exception Emask 0x10 SAct 0x0 SErr 0x401 action 0xb
> ata6: SError: { PHYRdyChg DevExch }
> ata6.04: hard resetting link
> ata6.04: SATA link down (SStatus 0 SControl 300)
> ata6: failed to recover some devices, retrying in 5 secs
> ata6.04: hard resetting link
> ata6.04: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata6.04: configured for UDMA/100
> ata6: EH complete
> sd 5:0:0:0: [sdh] 586114704 512-byte hardware sectors (300091 MB) sd
> 5:0:0:0: [sdh] Write Protect is off
> sd 5:0:0:0: [sdh] Mode Sense: 00 3a 00 00 sd 5:0:0:0: [sdh] Write cache:
> enabled, read cache: enabled, doesn't support DPO or FUA sd 5:1:0:0: [sdi]
> 586114704 512-byte hardware sectors (300091 MB)
> sd 5:1:0:0: [sdi] Write Protect is off sd 5:1:0:0: [sdi] Mode Sense: 00 3a
> 00 00
> sd 5:1:0:0: [sdi] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA sd 5:2:0:0: [sdj] 586114704 512-byte hardware sectors
> (300091 MB)
> sd 5:2:0:0: [sdj] Write Protect is off sd 5:2:0:0: [sdj] Mode Sense: 00 3a
> 00 00
> sd 5:2:0:0: [sdj] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA sd 5:3:0:0: [sdk] 586114704 512-byte hardware sectors
> (300091 MB)
> sd 5:3:0:0: [sdk] Write Protect is off sd 5:3:0:0: [sdk] Mode Sense: 00 3a
> 00 00
> sd 5:3:0:0: [sdk] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA sd 5:4:0:0: [sdl] 586114704 512-byte hardware sectors
> (300091 MB)
> sd 5:4:0:0: [sdl] Write Protect is off sd 5:4:0:0: [sdl] Mode Sense: 00 3a
> 00 00
> sd 5:4:0:0: [sdl] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA ata6.00: failed to read SCR 1 (Emask=0x40)
> ata6.01: failed to read SCR 1 (Emask=0x40)
> ata6.02: failed to read SCR 1 (Emask=0x40)
> ata6.03: failed to read SCR 1 (Emask=0x40)
> ata6.04: failed to read SCR 1 (Emask=0x40)
> ata6.05: failed to read SCR 1 (Emask=0x40)
> ata6.00: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata6.01: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata6.01: cmd c8/00:10:97:26:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192
> in res 50/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata6.01:
> status: { DRDY }
> ata6.02: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata6.03: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata6.04: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata6.05: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata6.15: hard resetting link
> ata6.15: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
> ata6.00: hard resetting link
> ata6.00: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata6.01: hard resetting link
> ata6.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> ata6.02: hard resetting link
> ata6.02: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> ata6.03: hard resetting link
> ata6.03: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> ata6.04: hard resetting link
> ata6.04: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> ata6.05: hard resetting link
> ata6.05: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata6.00: configured for UDMA/100
> ata6.01: configured for UDMA/100
> ata6.02: configured for UDMA/100
> ata6.03: configured for UDMA/100
> ata6.04: configured for UDMA/100
> ata6: EH complete
> sd 5:0:0:0: [sdh] 586114704 512-byte hardware sectors (300091 MB) sd
> 5:0:0:0: [sdh] Write Protect is off
> sd 5:0:0:0: [sdh] Mode Sense: 00 3a 00 00 sd 5:0:0:0: [sdh] Write cache:
> enabled, read cache: enabled, doesn't support DPO or F
libata pm
00 00 sd 5:3:0:0: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 5:4:0:0: [sdl] 586114704 512-byte hardware sectors (300091 MB) sd 5:4:0:0: [sdl] Write Protect is off sd 5:4:0:0: [sdl] Mode Sense: 00 3a 00 00 sd 5:4:0:0: [sdl] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 5:0:0:0: [sdh] 586114704 512-byte hardware sectors (300091 MB) sd 5:0:0:0: [sdh] Write Protect is off sd 5:0:0:0: [sdh] Mode Sense: 00 3a 00 00 sd 5:0:0:0: [sdh] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 5:1:0:0: [sdi] 586114704 512-byte hardware sectors (300091 MB) sd 5:1:0:0: [sdi] Write Protect is off sd 5:1:0:0: [sdi] Mode Sense: 00 3a 00 00 sd 5:1:0:0: [sdi] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 5:2:0:0: [sdj] 586114704 512-byte hardware sectors (300091 MB) sd 5:2:0:0: [sdj] Write Protect is off sd 5:2:0:0: [sdj] Mode Sense: 00 3a 00 00 sd 5:2:0:0: [sdj] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 5:3:0:0: [sdk] 586114704 512-byte hardware sectors (300091 MB) sd 5:3:0:0: [sdk] Write Protect is off sd 5:3:0:0: [sdk] Mode Sense: 00 3a 00 00 sd 5:3:0:0: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 5:4:0:0: [sdl] 586114704 512-byte hardware sectors (300091 MB) sd 5:4:0:0: [sdl] Write Protect is off sd 5:4:0:0: [sdl] Mode Sense: 00 3a 00 00 sd 5:4:0:0: [sdl] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA these messages repeat themself for hours... attached to this message is th dmesg output and hdparam -i for all devicessata_sil24 :05:01.0: version 1.1 ACPI: PCI Interrupt :05:01.0[A] -> GSI 24 (level, low) -> IRQ 24 sata_sil24 :05:01.0: Applying completion IRQ loss on PCI-X errata fix scsi2 : sata_sil24 scsi3 : sata_sil24 scsi4 : sata_sil24 scsi5 : sata_sil24 ata3: SATA max UDMA/100 host [EMAIL PROTECTED] port 0xfeaf irq 24 ata4: SATA max UDMA/100 host [EMAIL PROTECTED] port 0xfeaf2000 irq 24 ata5: SATA max UDMA/100 host [EMAIL PROTECTED] port 0xfeaf4000 irq 24 ata6: SATA max UDMA/100 host [EMAIL PROTECTED] port 0xfeaf6000 irq 24 ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata3.00: ATA-7: Maxtor 6V300F0, VA111630, max UDMA/133 ata3.00: 586114704 sectors, multi 16: LBA48 NCQ (not used) ata3.00: configured for UDMA/100 ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata4.00: ATA-7: Maxtor 6V300F0, VA111630, max UDMA/133 ata4.00: 586114704 sectors, multi 16: LBA48 NCQ (not used) ata4.00: configured for UDMA/100 ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata5.00: ATA-7: Maxtor 6V300F0, VA111630, max UDMA/133 ata5.00: 586114704 sectors, multi 16: LBA48 NCQ (not used) ata5.00: configured for UDMA/100 ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata6.15: Port Multiplier 1.1, 0x1095:0x3726 r23, 6 ports, feat 0x1/0x9 ata6.00: hard resetting link ata6.00: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata6.01: hard resetting link ata6.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata6.02: hard resetting link ata6.02: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata6.03: hard resetting link ata6.03: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata6.04: hard resetting link ata6.04: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata6.05: hard resetting link ata6.05: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata6.00: ATA-7: Maxtor 6V300F0, VA111630, max UDMA/133 ata6.00: 586114704 sectors, multi 16: LBA48 NCQ (not used) ata6.00: configured for UDMA/100 ata6.01: ATA-7: Maxtor 6V300F0, VA111630, max UDMA/133 ata6.01: 586114704 sectors, multi 0: LBA48 NCQ (not used) ata6.01: configured for UDMA/100 ata6.02: ATA-7: Maxtor 6V300F0, VA111630, max UDMA/133 ata6.02: 586114704 sectors, multi 0: LBA48 NCQ (not used) ata6.02: configured for UDMA/100 ata6.03: ATA-7: Maxtor 6V300F0, VA111630, max UDMA/133 ata6.03: 586114704 sectors, multi 0: LBA48 NCQ (not used) ata6.03: configured for UDMA/100 ata6.04: ATA-7: Maxtor 6V300F0, VA111630, max UDMA/133 ata6.04: 586114704 sectors, multi 0: LBA48 NCQ (not used) ata6.04: configured for UDMA/100 ata6: EH complete scsi 2:0:0:0: Direct-Access ATA Maxtor 6V300F0 VA11 PQ: 0 ANSI: 5 sd 2:0:0:0: [sde] 586114704 512-byte hardware sectors (300091 MB) sd 2:0:0:0: [sde] Write Protect is off sd 2:0:0:0: [sde] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 2:0:0:0: [sde] 586114704 512-byte hardware sectors (300091 MB) sd 2:0:0:0: [sde] Write Protect is off sd 2:0:0:0: [sde] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sde: sde1 sd 2:0:0:0: [sde] Attached SCSI disk sd 2:0:0:0: Attached scsi generic sg4 type 0 scsi 3:0:0:0: Direct-Access ATA Maxtor 6V300F0 VA11 PQ: 0 ANSI: 5 sd 3:0:0:0: [sdf] 586114704 512-byte hardware sectors (300091 MB) sd 3:0:0:
Re: libata-dev.git rebased
Jeff, Here's my rebased patch. Let me know if there's a problem with it. Thanks, Dan >On 12/1/06, Jeff Garzik <[EMAIL PROTECTED]> wrote: >> I just rebased all branches of libata-dev.git, and there was a bit of >> fallout: >> >> 1) Dan, I'll have to ask you to resend your sata_vsc MSI patch yet >> again, this time against 2.6.19. Since it was against >> drivers/scsi/sata_vsc.c, that caused some cross-directory-move related >> problems. >I've copied Dan Wolstenholme. > >Regards, >Dan Williams patch.sata_vsc.2.6.19 Description: Binary data
[PATCH libata-dev-2.6] sata_via: VT6420 PATA support - please help, correct this driver's alfa source code
I traid to write VT6420 PATA support into the libata: sata_via.c,
because the way through via82cxxx.c doesn't work.
Please help me with this and correct this driver's alfa source code.
/* */ ... this sign in source code means, that this part i added into
current libata-dev-2.6: sata_via.c
Petr Novák
[EMAIL PROTECTED]
/*
sata_via.c - VIA Serial ATA controllers
Maintained by: Jeff Garzik <[EMAIL PROTECTED]>
Please ALWAYS copy linux-ide@vger.kernel.org
on emails.
Copyright 2003-2004 Red Hat, Inc. All rights reserved.
Copyright 2003-2004 Jeff Garzik
The contents of this file are subject to the Open
Software License version 1.1 that can be found at
http://www.opensource.org/licenses/osl-1.1.txt and is included herein
by reference.
Alternatively, the contents of this file may be used under the terms
of the GNU General Public License version 2 (the "GPL") as distributed
in the kernel source COPYING file, in which case the provisions of
the GPL are applicable instead of the above. If you wish to allow
the use of your version of this file only under the terms of the
GPL and not to allow others to use your version of this file under
the OSL, indicate your decision by deleting the provisions above and
replace them with the notice and other provisions required by the GPL.
If you do not delete the provisions above, a recipient may use your
version of this file under either the OSL or the GPL.
--
To-do list:
* VT6420 PATA support
* VT6421 PATA support
*/
#include
#include
#include
#include
#include
#include
#include "scsi.h"
#include
#include
#include
#define DRV_NAME"sata_via"
#define DRV_VERSION "1.2" /* */
enum board_ids_enum {
vt6420,
vt6420pata, /* */
vt6421,
};
enum {
SATA_CHAN_ENAB = 0x40, /* SATA channel enable */
SATA_INT_GATE = 0x41, /* SATA interrupt gating */
SATA_NATIVE_MODE= 0x42, /* Native mode enable */
SATA_PATA_SHARING = 0x49, /* PATA/SATA sharing func ctrl */
VT_CTLSTAT = 0x60, /* IDE control and status (per
port) */ /* */
PORT0 = (1 << 1),
PORT1 = (1 << 0),
ALL_PORTS = PORT0 | PORT1,
N_PORTS = 2,
NATIVE_MODE_ALL = (1 << 7) | (1 << 6) | (1 << 5) | (1 << 4),
SATA_EXT_PHY= (1 << 6), /* 0==use PATA, 1==ext phy */
SATA_2DEV = (1 << 5), /* SATA is master/slave */
};
static int svia_init_one (struct pci_dev *pdev, const struct pci_device_id
*ent);
static u32 svia_scr_read (struct ata_port *ap, unsigned int sc_reg);
static void svia_scr_write (struct ata_port *ap, unsigned int sc_reg, u32 val);
/* */
static void vt6420pata_phy_reset(struct ata_port *ap);
static void vt6420pata_cbl_detect(struct ata_port *ap);
static struct pci_device_id svia_pci_tbl[] = {
{ 0x1106, 0x3149, PCI_ANY_ID, PCI_ANY_ID, 0, 0, vt6420 },
{ 0x1106, 0x4149, PCI_ANY_ID, PCI_ANY_ID, 0, 0, vt6420pata }, /* */
{ 0x1106, 0x3249, PCI_ANY_ID, PCI_ANY_ID, 0, 0, vt6421 },
{ } /* terminate list */
};
static struct pci_driver svia_pci_driver = {
.name = DRV_NAME,
.id_table = svia_pci_tbl,
.probe = svia_init_one,
.remove = ata_pci_remove_one,
};
static Scsi_Host_Template svia_sht = {
.module = THIS_MODULE,
.name = DRV_NAME,
.ioctl = ata_scsi_ioctl,
.queuecommand = ata_scsi_queuecmd,
.eh_strategy_handler= ata_scsi_error,
.can_queue = ATA_DEF_QUEUE,
.this_id= ATA_SHT_THIS_ID,
.sg_tablesize = LIBATA_MAX_PRD,
.max_sectors= ATA_MAX_SECTORS,
.cmd_per_lun= ATA_SHT_CMD_PER_LUN,
.emulated = ATA_SHT_EMULATED,
.use_clustering = ATA_SHT_USE_CLUSTERING,
.proc_name = DRV_NAME,
.dma_boundary = ATA_DMA_BOUNDARY,
.slave_configure= ata_scsi_slave_config,
.bios_param = ata_std_bios_param,
};
static struct ata_port_operations svia_sata_ops = {
.port_disable = ata_port_disable,
.tf_load= ata_tf_load,
.tf_read= ata_tf_read,
.check_status = ata_check_status,
.exec_command
Re: kernel history of ide performance
kiu wrote: Hi ide team, i often heard "uh, since kernel 2.6.bla the ide perfomance is soo bad". Because of that (and the joy of writing bash scripts noone else will understand *g*) i wrote an automated test script to get comparable measurements. The script compiles 2.6.0-2.6.11.6 (yes "" | make oldconfig), boots each kernel, runs hdparm/bonnie++ and create some pngs with gnuplot. I ran the script on a Intel 82371AB/EB/MB PIIX4/PIICeleron 333/IC35L040AVER07 machine and you can find the results here: http://www.kiu.weite-welt.com/misc/idetest I am quite busy at the moment and hopefully have time next month to clean up the scripts for a release (are you interested?) and do further testing... This looks like a mixed bag: some regression, some clear improvements, mostly the same. Nice work! Does this portray the IDE situation or more the situation of the PIIX chipset - I guess the code isn't changed as much since it should be rather mature? With kind regards, Oliver Korpilla - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SATA] libata-dev queue updated
Jeff Garzik napsal(a): Merged recent upstream changes into libata-dev queue. No new patches have found their way into libata-dev since last email. BK URL, Patch URL, and changelog attached. Note that the patch is diff'd against 2.6.11-bk6, which won't exist until four hours after this email is sent. Jeff It is hard to add support for VIA VT6420 PATA channel (SATA works fine)? Does anybody working on it? I can help with beta testing this driver. (The way through via82cxxx.c don't working.) Is it possible add to To-do list to sata_via.c or add this support to driver? sata_via.c: ---cut here--- To-do list: * VT6420 PATA support <= new line * VT6421 PATA support */ ---cut here--- Petr Novák, [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SATA] SATA_SIL and ATI SB400 chipset
Mark Hahn wrote: Problem is, I want to do an install from the Sarge netinstall media to get a full AMD64-compatible install. If I load the SATA_SIL module there, no so you should get the debian people to fix their bug - amd64 doesn't use a different sata_sil driver than ia32, of course! I wasn't implying that - I thought there could be the possibility to override the module probe parameters. being loaded correctly, with the same parameters it recognizes the hardware when booted with kernel 2.6.11. to me it sounds like your random debian kernel is just broken. in general, no module parameters should ever be needed. That seems to be correct - I did help me out with an PATA drive, made an install, fixed a vanilla 2.6.11 onto it, and all runs perfectly well, except it only seems to scans two of my four SATA ports. But it boots and runs smoothly, so that's nice enough. So if needed I will produce my own boot disk, that's fine enough! :) Do you think my controller is limited to doing a mode of UDMA/100 when the drive reports as UDMA/133 capable, but then is reported with less. Or is this inherent to the SATA_SIL driver? I guess it's not a bad thing to archive into a Linux list that the RS480M2-IL motherboard's SATA controller works with SATA_SIL driver, as it uses the ATI SB400 Chipset. ;) :) Thanks and with kind regards, Oliver Korpilla - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: via 6420 pata/sata controller
I downloaded new kernel 2.6.11, applied your's via82cxxx.c patch and
compiled it (.config was derived "make oldconfig" from 2.6.8 kernel from
Debian Sarge 3.1).
I created initrd.img with this settings:
/etc/mkinitrd/mkinitrd.conf
--- cut here ---
MODULES=dep
--- cut here ---
/etc/mkinitrd/modules
###
jbd
ext3
ide-core
via82cxxx
I boot PC with this settings:
/etc/modules
###
ide-cd
via82cxxx
Results:
Everything is the same, dmesg, lspci, lspci -n, cat /proc/ioports, lsmod
as the last email.
Controller still don't working :'(.
PS: I don't add anything into pci_ids.h, I only applied your's
via82cxxx.c patch:
#define PCI_DEVICE_ID_VIA_6420 0x4149
Your's Sincerely
Petr Novák
[EMAIL PROTECTED]
Jeff Garzik napsal(a):
If I had to guess, I would try the attached patch. The via82cxxx.c
driver is a bit annoying in that, here we do not talk to the ISA
bridge but to the PCI device 0x4149 itself.
If this doesn't work, I could probably whip together a quick PATA
driver for libata that works on this hardware.
Jeff
= drivers/ide/pci/via82cxxx.c 1.27 vs edited =
--- 1.27/drivers/ide/pci/via82cxxx.c2005-02-03 02:24:29 -05:00
+++ edited/drivers/ide/pci/via82cxxx.c 2005-03-02 01:28:26 -05:00
@@ -79,6 +79,7 @@
u8 rev_max;
u16 flags;
} via_isa_bridges[] = {
+ { "vt6420", 0x4149, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
{ "vt8237", PCI_DEVICE_ID_VIA_8237, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
{ "vt8235", PCI_DEVICE_ID_VIA_8235, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
{ "vt8233a", PCI_DEVICE_ID_VIA_8233A,0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
@@ -635,9 +636,10 @@
}
static struct pci_device_id via_pci_tbl[] = {
- { PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C576_1, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
- { PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
- { 0, },
+ { PCI_DEVICE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C576_1) },
+ { PCI_DEVICE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1) },
+ { PCI_DEVICE(PCI_VENDOR_ID_VIA, 0x4149) },
+ { },/* terminate list */
};
MODULE_DEVICE_TABLE(pci, via_pci_tbl);
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: via 6420 pata/sata controller
>>Bartlomiej Zolnierkiewicz wrote:
>>> On Tuesday 30 of March 2004 15:24, Zdenek Tlusty wrote:
>>>
>>>>Hello,
>>>>
>>>>I have problem with via 6420 controller under linux (I have
mandrake 9.1
>>>>with kernel 2.4.25 with libata patch version 16).
>>>>This controller has two sata and one pata channels. Sata channel
works fine
>>>>with libata. My problem is with pata channel. I have pata hard disk
on this
>>>>controller. Bios of the controller detected this disk but linux did
not.
>>>>What is the current status of the driver for this controller?
>>>>Thank you for your time.
>>>
>>>
>>> There are some patches floating around adding support for VT6410
>>> (not VT6420) to generic IDE PCI driver. This controller may also work
>>> with generic IDE PCI driver (PCI VendorID/ProductID needs to be added
>>> to drivers/ide/pci/generic.h and drivers/ide/pci/generic.c).
>>
>>VT 6420 should be added to via82cxxx.c, since it does the necessary bus
>>setup and such. AFAICS it is programmed just like all the other VIA
>>PATA controllers.
>>
>> BTW Does anybody has contacts in VIA?
>>
>>Sure... I'll check my VT 6420 cards as well. It should just be another
>>PCI id added to via82cxxx.c.
>>
>> Jeff
>>
>
>Hello,
>
>I tried to modify via82cxxx.c and .h, but was unsuccessful. Has anyone
got it to work properly?
>
>Kamil Okac
* Per my message (last quoted line), the user should add the PCI ID to *
drivers/ide/via82cxxx.[ch] and see what happens.
*
* Jeff
Hello,
i trying resurrect this discussion again for solve this problem
successfuly.
My experiments:
I changed two files:
usr/src/linux-2.6.11-rc5/include/linux/pci_ids.h
--- cut here ---
#define PCI_DEVICE_ID_VIA_8703_51_0 0x3148
#define PCI_DEVICE_ID_VIA_8237_SATA 0x3149
#define PCI_DEVICE_ID_VIA_6420 0x4149; <= this i was
add
#define PCI_DEVICE_ID_VIA_XN266 0x3156
#define PCI_DEVICE_ID_VIA_8754C_0 0x3168
--- cut here ---
/use/src/linux-2.6.11-rc5/drivers/ide/pci/via82cxxx.c
--- cut here ---
{ "vt8233c", PCI_DEVICE_ID_VIA_8233C_0, 0x00, 0x2f, VIA_UDMA_100 },
{ "vt8233", PCI_DEVICE_ID_VIA_8233_0, 0x00, 0x2f, VIA_UDMA_100 },
{ "vt8231", PCI_DEVICE_ID_VIA_8231, 0x00, 0x2f, VIA_UDMA_100 },
{ "vt6420", PCI_DEVICE_ID_VIA_6420, 0x00, 0x2f, VIA_UDMA_100 },
; <= this i was add
{ "vt82c686b", PCI_DEVICE_ID_VIA_82C686, 0x40, 0x4f, VIA_UDMA_100 },
{ "vt82c686a", PCI_DEVICE_ID_VIA_82C686, 0x10, 0x2f, VIA_UDMA_66 },
--- cut here ---
But i was not successful :'-(
Informations from my computer:
dmesg
--- cut here ---
Linux version 2.6.11-rc5 ([EMAIL PROTECTED]) (gcc version 2.95.4 20011002
(Debian prerelease)) #1 Sat Feb 26 02:18:02 CET 2005
.
.
.
SCSI subsystem initialized
libata version 1.10 loaded.
sata_via version 1.1
sata_via(:00:0f.0): routed to hard irq line 10
ata1: SATA max UDMA/133 cmd 0x6200 ctl 0x6302 bmdma 0x6600 irq 10
ata2: SATA max UDMA/133 cmd 0x6400 ctl 0x6502 bmdma 0x6608 irq 10
ata1: no device found (phy stat )
scsi0 : sata_via
ata2: no device found (phy stat )
scsi1 : sata_via
--- cut here ---
lspci
--- cut here ---
:00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA
RAID Controller (rev 50)
:00:0f.1 RAID bus controller: VIA Technologies, Inc.: Unknown device
4149 (rev 80)
--- cut here ---
lspci -n
--- cut here ---
:00:0f.0 0104: 1106:3149 (rev 50)
:00:0f.1 0104: 1106:4149 (rev 80)
--- cut here ---
cat /proc/ioports
--- cut here ---
6200-6207 : :00:0f.0
6200-6207 : sata_via
6300-6303 : :00:0f.0
6300-6303 : sata_via
6400-6407 : :00:0f.0
6400-6407 : sata_via
6500-6503 : :00:0f.0
6500-6503 : sata_via
6600-660f : :00:0f.0
6600-660f : sata_via
6700-67ff : :00:0f.0
6700-67ff : sata_via
6800-6807 : :00:0f.1
6900-6903 : :00:0f.1
6a00-6a07 : :00:0f.1
6b00-6b03 : :00:0f.1
6c00-6c0f : :00:0f.1
--- cut here ---
lsmod
--- cut here ---
Module Size Used by
ipv6 245568 10
uhci_hcd 30216 0
ohci_hcd 20736 0
ehci_hcd 32128 0
usbcore 113096 3 uhci_hcd,ohci_hcd,ehci_hcd
i2c_sis630 7688 0
i2c_sis5595 7424 0
i2c_core 22144 2 i2c_sis630,i2c_sis5595
sis_agp 8576 0
agpgart33612 1 sis_agp
parport_pc 34724 0
parport35264 1 parport_pc
floppy 58096 0
pcspkr 3912 0
evdev 9344 0
sata_via8708 0
libata 44804 1 sata_via
scsi_mod 129572 1 libata
via_rhine 22148 0
mii
