Hello,
Today i mounted a HDD on my secondary IDE on a 40 pin cable and surprise
the kernel set it up on UDMA 133:
hdd: 120103200 sectors (61493 MB) w/2048KiB Cache, CHS=119150/16/63, UDMA(133)
I wouldn't have notice this unless I got some errors:
Jan 2 20:20:40 theo kernel: hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Jan 2 20:20:40 theo kernel: hdd: dma_intr: error=0x84 { DriveStatusError BadCRC }
Jan 2 20:20:40 theo kernel: hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Jan 2 20:20:40 theo kernel: hdd: dma_intr: error=0x84 { DriveStatusError BadCRC }
Jan 2 20:20:40 theo kernel: hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Jan 2 20:20:40 theo kernel: hdd: dma_intr: error=0x84 { DriveStatusError BadCRC }
Jan 2 20:20:40 theo kernel: hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Jan 2 20:20:40 theo kernel: hdd: dma_intr: error=0x84 { DriveStatusError BadCRC }
Jan 2 20:20:40 theo kernel: ide1: reset: success
This box is running kernel: 2.4.18-18.8.0 ( redhat 8.0 )
Teo
On Thu, 2003-01-02 at 18:29, Teodor Iacob wrote:
> Hello,
>
> Today i mounted a HDD on my secondary IDE on a 40 pin cable and surprise
> the kernel set it up on UDMA 133:
>
> hdd: 120103200 sectors (61493 MB) w/2048KiB Cache, CHS=119150/16/63, UDMA(133)
What controller and disks ?
> I wouldn't have notice this unless I got some errors:
It got CRC errors, not suprisingly and will drop back. Nevertheless it
shouldnt have gotten this wrong, so more info would be good.
On Thu, Jan 02, 2003 at 07:37:49PM +0000, Alan Cox wrote:
> On Thu, 2003-01-02 at 18:29, Teodor Iacob wrote:
> > Hello,
> >
> > Today i mounted a HDD on my secondary IDE on a 40 pin cable and surprise
> > the kernel set it up on UDMA 133:
> >
> > hdd: 120103200 sectors (61493 MB) w/2048KiB Cache, CHS=119150/16/63, UDMA(133)
>
> What controller and disks ?
Sorry I didn't append this info from the first time.. there it goes:
00:11.1 IDE interface: VIA Technologies, Inc. VT82C586B PIPC Bus Master IDE (rev 06)
hdd: Maxtor 6Y060L0, ATA DISK drive
the harddisk is DiamondPlus9 60GB 7200 rpm UDMA133 .. and the mainbboard is Soltek 75-FRV
with KT400 chipset
>
> > I wouldn't have notice this unless I got some errors:
>
> It got CRC errors, not suprisingly and will drop back. Nevertheless it
> shouldnt have gotten this wrong, so more info would be good.
>
> -
> 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/
--
Teodor Iacob,
Network Administrator
Astral TELECOM Internet
Teodor Iacob wrote:
>On Thu, Jan 02, 2003 at 07:37:49PM +0000, Alan Cox wrote:
>
>
>>On Thu, 2003-01-02 at 18:29, Teodor Iacob wrote:
>>
>>
>>>Hello,
>>>
>>>Today i mounted a HDD on my secondary IDE on a 40 pin cable and surprise
>>>the kernel set it up on UDMA 133:
>>>
>>>hdd: 120103200 sectors (61493 MB) w/2048KiB Cache, CHS=119150/16/63, UDMA(133)
>>>
>>>
>>What controller and disks ?
>>
>>
>
>Sorry I didn't append this info from the first time.. there it goes:
>
>00:11.1 IDE interface: VIA Technologies, Inc. VT82C586B PIPC Bus Master IDE (rev 06)
>
>hdd: Maxtor 6Y060L0, ATA DISK drive
>
>the harddisk is DiamondPlus9 60GB 7200 rpm UDMA133 .. and the mainbboard is Soltek 75-FRV
>with KT400 chipset
>
>
What's hdc? Hdd is the secondary slave. If it's the only device on
the chain you should make sure you jumper the drive as a master.
--
There is no such thing as obsolete hardware.
Merely hardware that other people don't want.
(The Second Rule of Hardware Acquisition)
Sam Flory <[email protected]>
> >00:11.1 IDE interface: VIA Technologies, Inc. VT82C586B PIPC Bus Master
> >IDE (rev 06)
> >
> >hdd: Maxtor 6Y060L0, ATA DISK drive
> >
> >the harddisk is DiamondPlus9 60GB 7200 rpm UDMA133 .. and the mainbboard
> >is Soltek 75-FRV
> >with KT400 chipset
> >
> >
>
> What's hdc? Hdd is the secondary slave. If it's the only device on
> the chain you should make sure you jumper the drive as a master.
HDC it's a CD-RW .. it was not used at the time of the error ( i was doing
mke2fs on hdd1 when I got those errors in dmesg ).
>
>
> --
> There is no such thing as obsolete hardware.
> Merely hardware that other people don't want.
> (The Second Rule of Hardware Acquisition)
> Sam Flory <[email protected]>
>
>
--
Teodor Iacob,
Network Administrator
Astral TELECOM Internet
Teodor Iacob wrote:
>>>00:11.1 IDE interface: VIA Technologies, Inc. VT82C586B PIPC Bus Master
>>>IDE (rev 06)
>>>
>>>hdd: Maxtor 6Y060L0, ATA DISK drive
>>>
>>>the harddisk is DiamondPlus9 60GB 7200 rpm UDMA133 .. and the mainbboard
>>>is Soltek 75-FRV
>>>with KT400 chipset
>>>
>>>
>>>
>>>
>> What's hdc? Hdd is the secondary slave. If it's the only device on
>>the chain you should make sure you jumper the drive as a master.
>>
>>
>
>HDC it's a CD-RW .. it was not used at the time of the error ( i was doing
>mke2fs on hdd1 when I got those errors in dmesg ).
>
>
>
Try setting the cd-rw as a slave, and the hard drive as a master.
--
There is no such thing as obsolete hardware.
Merely hardware that other people don't want.
(The Second Rule of Hardware Acquisition)
Sam Flory <[email protected]>
On Thu, Jan 02, 2003 at 11:47:56AM -0800, Samuel Flory wrote:
>
> Try setting the cd-rw as a slave, and the hard drive as a master.
My problem was that it was recognised as UDMA 133 on a 40 pin cable...
actually after those errors ( which repeats 4 times in the log ) the hard-drive
works fine.. I just thought of it as a bug.. I shall not use the hard-drive
in this configuration anyway...
>
> --
> There is no such thing as obsolete hardware.
> Merely hardware that other people don't want.
> (The Second Rule of Hardware Acquisition)
> Sam Flory <[email protected]>
>
>
>
> -
> 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/
--
Teodor Iacob,
Network Administrator
Astral TELECOM Internet
Happy new year everybody
Alan Cox wrote:
>It got CRC errors, not suprisingly and will drop back. Nevertheless it
>shouldnt have gotten this wrong, so more info would be good.
>
>
I'm wondering some things about IDE 40/80 pin cables since some time ago :
- somehow the circuitry can make the difference between 40 and 80 pin
(probably some pins are shorted or not by the cables or some
cable-type-dependent impedance between wires is mesured) and set a bit
for us to use.
- most probably the same circuitry can't verify the length of the cables
or their overall quality but I'm unsure.
#1 How is the 40/80 pin detection done at the hardware level ?
#2 Are there any other cable-quality hardware tests done by the chipsets
? How ?
I've encountered a barebone design (Mocha P4, uses 2.5" drives) where
the IDE cable was 40-pin but :
- has a single drive connector instead of the common two,
- its length is only around 10 or 15 cm.
A buyer contacted me for SiS IDE driver directions on this platform and
confirmed this at least for his purchase.
#3 Is the above cable electrically able to sustain 66+ UDMA transfers
(could I hack a driver in order to bypass the 80pin cable detection and
make it work properly) ?
#4 Are the electrical specs for 66+ UDMA transfers public (couldn't find
by googling) ? Where can we find them ?
Here I mean some really basic specs (max Resistance/Capacity/Inductance
between wires, max signal propagation delays and so on) and not general
high level specs (material, connector design, length ranges allowed in
the general 80-pin, 2 drives case).
Any hints on these Andre ?
LB.
>
>
>>#3 Is the above cable electrically able to sustain 66+ UDMA transfers
>>(could I hack a driver in order to bypass the 80pin cable detection and
>>make it work properly) ?
>>
>>
>
>It is possible to do this yes. Other vendors do it as well. Careful
>cable choice lets you meet the electrical requirements other ways in
>certain situations.
>
>
>
>
on the kernel command line ide0=ATA66 bypasses the check for ide channel 0.
Ross
On Thu, 2003-01-02 at 22:00, Lionel Bouton wrote:
> I'm wondering some things about IDE 40/80 pin cables since some time ago :
> - somehow the circuitry can make the difference between 40 and 80 pin
> (probably some pins are shorted or not by the cables or some
> cable-type-dependent impedance between wires is mesured) and set a bit
> for us to use.
> - most probably the same circuitry can't verify the length of the cables
> or their overall quality but I'm unsure.
>
> #1 How is the 40/80 pin detection done at the hardware level ?
> #2 Are there any other cable-quality hardware tests done by the chipsets
> ? How ?
Oh god. Andre described this one as needing a "two beer" explanation.
I'd recommend stronger drinks however.
> I've encountered a barebone design (Mocha P4, uses 2.5" drives) where
> the IDE cable was 40-pin but :
> - has a single drive connector instead of the common two,
> - its length is only around 10 or 15 cm.
> A buyer contacted me for SiS IDE driver directions on this platform and
> confirmed this at least for his purchase.
>
> #3 Is the above cable electrically able to sustain 66+ UDMA transfers
> (could I hack a driver in order to bypass the 80pin cable detection and
> make it work properly) ?
It is possible to do this yes. Other vendors do it as well. Careful
cable choice lets you meet the electrical requirements other ways in
certain situations.
>
> #1 How is the 40/80 pin detection done at the hardware level ?
On the motherboard end of the 80 conductor cable, the connector shorts
one of the pins to ground (maybe pin 38). The ide controller just
checks to see if the pin is pulled low or not. Pulled low = 80 pin.
That's one of the reasons it's important to plug IDE cables in the
correct way.
Ross
Ok then after all .. what I see on my box could be a stupid IDE controller?
On Thu, Jan 02, 2003 at 02:40:20PM -0800, Ross Biro wrote:
> >
> >#1 How is the 40/80 pin detection done at the hardware level ?
>
>
> On the motherboard end of the 80 conductor cable, the connector shorts
> one of the pins to ground (maybe pin 38). The ide controller just
> checks to see if the pin is pulled low or not. Pulled low = 80 pin.
> That's one of the reasons it's important to plug IDE cables in the
> correct way.
>
> Ross
>
--
Teodor Iacob,
Network Administrator
Astral TELECOM Internet
Teodor Iacob wrote:
>Ok then after all .. what I see on my box could be a stupid IDE controller?
>
>
Chip bug, unknown chip revision with different register layout needing
reverse engineering (or did VIA learn that providing specs enlarge their
market share ?) or plain driver bug.
I don't think ATA66+ controllers can be within spec if they don't detect
40 vs 80 pin cables.
LB.
On Fri, 2003-01-03 at 01:04, Lionel Bouton wrote:
> I don't think ATA66+ controllers can be within spec if they don't detect
> 40 vs 80 pin cables.
I wish. Alas not in the real world.
Alan
Alan Cox wrote:
>On Thu, 2003-01-02 at 22:00, Lionel Bouton wrote:
>
>
>>#2 Are there any other cable-quality hardware tests done by the chipsets
>>? How ?
>>
>>
>
>Oh god. Andre described this one as needing a "two beer" explanation.
>I'd recommend stronger drinks however.
>
>
In that case the thing should be within my body specifications :-)
>>#3 Is the above cable electrically able to sustain 66+ UDMA transfers
>>(could I hack a driver in order to bypass the 80pin cable detection and
>>make it work properly) ?
>>
>>
>
>It is possible to do this yes. Other vendors do it as well. Careful
>cable choice lets you meet the electrical requirements other ways in
>certain situations.
>
>
Given what I see on sales (various out of spec drives/cables and maybe
even controllers) I'm suspecting that some of these vendors might use
plain trial and error cable testing...
This is why I'd prefer to have real electrical specs at hand to make my
own checks.
LB.
On Thu, 2003-01-02 at 14:47, Samuel Flory wrote:
> Try setting the cd-rw as a slave, and the hard drive as a master.
I tried setting up my CDRW as a slave and couldn't get it to work.
Later I found documentation stating that my Memorex 48-24-48 CDRW was
unable to function as a slave device.
Let me know if you can get it to work.
Josh
> > I don't think ATA66+ controllers can be within spec if they don't detect
> > 40 vs 80 pin cables.
>
> I wish. Alas not in the real world.
Something that occurs to me, which is somewhat related to this:
My understanding, (which might be wrong) is that termination of the
IDE bus is partly handled by each connected devicem rather like modern
floppy drives, (in contrast to SCSI, 10-base-2, old floppy drives etc,
where the termination is handled by devices at the physical ends of
the cable).
So if you connnect a really old IDE disk, say a 20 Mb one, and an
ATA-100 one to the same bus, is the termination then out of spec,
(analogous to using passive terminators on anything other than a SCSI-1
bus), because presumably the termination requirements are stricter for
the higher bus speed and signaling on both edges?
Just wondered.
John.
On Fri, 3 Jan 2003, John Bradford wrote:
> > > I don't think ATA66+ controllers can be within spec if they don't detect
> > > 40 vs 80 pin cables.
> >
> > I wish. Alas not in the real world.
>
> Something that occurs to me, which is somewhat related to this:
>
> My understanding, (which might be wrong) is that termination of the
> IDE bus is partly handled by each connected devicem rather like modern
> floppy drives, (in contrast to SCSI, 10-base-2, old floppy drives etc,
> where the termination is handled by devices at the physical ends of
> the cable).
>
> So if you connnect a really old IDE disk, say a 20 Mb one, and an
> ATA-100 one to the same bus, is the termination then out of spec,
> (analogous to using passive terminators on anything other than a SCSI-1
> bus), because presumably the termination requirements are stricter for
> the higher bus speed and signaling on both edges?
All are self terminating, and are effected by the M:S:C jumpers for
their responses. Things like leak current times and other events that are
based on various decay rates against an assumed Z value for a given
ribbon+devices+host combination will change things rudely.
There are issues of shadow registers and pattern responses.
But you got the swing of it!
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Thu, Jan 02, 2003 at 11:00:56PM +0100, Lionel Bouton wrote:
> Happy new year everybody
>
>
> Alan Cox wrote:
>
> >It got CRC errors, not suprisingly and will drop back. Nevertheless it
> >shouldnt have gotten this wrong, so more info would be good.
> >
> >
>
> I'm wondering some things about IDE 40/80 pin cables since some time ago :
> - somehow the circuitry can make the difference between 40 and 80 pin
> (probably some pins are shorted or not by the cables or some
> cable-type-dependent impedance between wires is mesured) and set a bit
> for us to use.
Yes. There are two types of this circuitry:
1) Just-a-capacitor-on-mainboard. When the pin in question (CBLID) is
connected to ground via a capacitor on the mainboard, the attached
devices can detect the cable and the IDE driver can ask them.
2) GPIO pin on mainboard. One of the chipset's GPIO pins gets wired to
CBLID and then the chipset can see what cable is installed.
Unfortunately, the wiring is mainboard (not chipset) dependent, and thus
only the BIOS can know.
Anyway, mixing various types of devices and mainboards there are always
cases where you get incorrect results. For some reason the ATA people
couldn't get this ever right.
The second method is safer, and mostly works for chipsets where there is
a 'cable detect scratch register', where the BIOS writes the 80/40 pin
cable information. Modern chipsets (Intel, AMD) implement this. VIA
doesn't. There is no way for a driver to read the cable type on a VIA
mainboard - it can ask the drives (but they can lie if they're mixed
with older devices, and if there is no cap on the mainboard), and it can
guess from the settings the BIOS used to program the UDMA speeds.
Currently it does the later, because it works in 99% of cases - the BIOS
will only set the chipset to UDMA66+ if it sees the cable on the right
GPIO pins.
> - most probably the same circuitry can't verify the length of the cables
> or their overall quality but I'm unsure.
It can not. Very modern drives and chipsets can adapt the termination
and various aspects of signalling, but cannot measure whether the cable
is suitable for a certain speed or not. The only way to really know is
to try to do a transfer. Or two. Or a thousand.
> #1 How is the 40/80 pin detection done at the hardware level ?
See above. Also see the ATA specs, it's there.
> #2 Are there any other cable-quality hardware tests done by the chipsets
> ? How ?
Not really.
> I've encountered a barebone design (Mocha P4, uses 2.5" drives) where
> the IDE cable was 40-pin but :
> - has a single drive connector instead of the common two,
> - its length is only around 10 or 15 cm.
> A buyer contacted me for SiS IDE driver directions on this platform and
> confirmed this at least for his purchase.
>
> #3 Is the above cable electrically able to sustain 66+ UDMA transfers
> (could I hack a driver in order to bypass the 80pin cable detection and
> make it work properly) ?
If you use ide0=ata66, the cable should be forced to 80pin. Also, it can
work if the cable is short and there is only one drive. Make sure it's
not bent too much, too.
> #4 Are the electrical specs for 66+ UDMA transfers public (couldn't find
> by googling) ? Where can we find them ?
> Here I mean some really basic specs (max Resistance/Capacity/Inductance
> between wires, max signal propagation delays and so on) and not general
> high level specs (material, connector design, length ranges allowed in
> the general 80-pin, 2 drives case).
Mostly. See the ATA spec.
> Any hints on these Andre ?
--
Vojtech Pavlik
SuSE Labs