From: Lionel Bouton <Lionel.Bouton@inet6.fr>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>, Andre Hedrick <andre@linux-ide.org>
Cc: Teodor Iacob <Teodor.Iacob@astral.kappa.ro>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: UDMA 133 on a 40 pin cable
Date: Thu, 02 Jan 2003 23:00:56 +0100 [thread overview]
Message-ID: <3E14B698.8030107@inet6.fr> (raw)
In-Reply-To: <1041536269.24901.47.camel@irongate.swansea.linux.org.uk>
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.
next prev parent reply other threads:[~2003-01-02 21:54 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-02 18:29 UDMA 133 on a 40 pin cable Teodor Iacob
2003-01-02 19:37 ` Alan Cox
2003-01-02 18:59 ` Teodor Iacob
2003-01-02 19:21 ` Samuel Flory
2003-01-02 19:23 ` Teodor Iacob
2003-01-02 19:47 ` Samuel Flory
2003-01-02 20:37 ` Teodor Iacob
2003-01-03 2:26 ` Joshua Stewart
2003-01-02 22:00 ` Lionel Bouton [this message]
2003-01-02 22:40 ` Ross Biro
2003-01-02 22:42 ` Teodor Iacob
2003-01-03 1:04 ` Lionel Bouton
2003-01-03 1:57 ` Alan Cox
2003-01-03 10:20 ` IDE termination (was Re: UDMA 133 on a 40 pin cable) John Bradford
2003-01-03 10:29 ` Andre Hedrick
2003-01-02 23:24 ` UDMA 133 on a 40 pin cable Alan Cox
2003-01-02 22:45 ` Ross Biro
2003-01-03 1:15 ` Lionel Bouton
2003-01-03 16:14 ` Vojtech Pavlik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E14B698.8030107@inet6.fr \
--to=lionel.bouton@inet6.fr \
--cc=Teodor.Iacob@astral.kappa.ro \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andre@linux-ide.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.