linux-kernel - Re: [PATCH 2.6.32.3] ahci: AHCI and RAID mode SATA patch for Intel Cougar Point DeviceIDs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 16 Jan 2010 19:02:31 +0100
From:	Krzysztof Halasa <khc@...waw.pl>
To:	Robert Hancock <hancockrwd@...il.com>
Cc:	Jeff Garzik <jgarzik@...ox.com>,
	Seth Heasley <seth.heasley@...el.com>,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.32.3] ahci: AHCI and RAID mode SATA patch for Intel  Cougar Point DeviceIDs

Robert Hancock <hancockrwd@...il.com> writes:

> Hmm.. From those test results I really suspect some kind of hardware
> fault. Could be a defective motherboard - I don't know if that chip
> needs any terminating resistors on the motherboard for the SATA signal
> lines or something, if so, could be they weren't installed properly..

Unfortunately I can't find a JMB363 datasheet on the net, but there is
a certain mb (p965t-a) schematic available.
It seems JMB363 doesn't need terminators on SATA RX/TX lines, there is
capacitative coupling only (10 nF in each line).

The port in question (SATA#2) on my mb (P45 Neo2) uses pins 56 (RXP)
57 (RXN) and 60 (TXN) 61 (TXP). No visible irregularity, the traces look
like they should, go straigt to the capacitors, and then to 0R R-packs
and to the connector. It looks exactly the same for both ports. There is
no short circuit past the capacitors (from the connector side). I'd say
quite low probability that there is something wrong with these signals.

It seems the chip uses extra 12k resistors for SATA (p965t-a calls the
pins SJ_REXT[12]), pin 44 for port#1 and 55 for port#2. Both look sane.
I will check the suspected connections with the machine powered off
later.

The RX and TX trace pairs go next to each other for up to 10 mm, could
that be a problem at these frequencies? If so it would show up on
all/many such boards certainly? Can't find any report.

OTOH other people have similar problems with other boards: e.g.
ASUS P5KC: http://ubuntuforums.org/showthread.php?t=766217
           https://bugs.launchpad.net/ubuntu/+source/linux/+bug/377633

(unknown boards)
https://archlinux-fr.org/doku.php?id=securisation:logcheck
http://forum.ubuntu-fr.org/viewtopic.php?pid=2739616
http://ubuntu-ky.ubuntuforums.org/showthread.php?p=7243061
The last one claims:
this started after an upgrade to ubuntu 9.04 and is stll here after re-installing
ubuntu 8.10.
this was fixed by re-installing ubuntu 8.10 only using the kernal,
2.6.27-7-generic.
I don't know if JMB36x is involved in this case, and how reliable the
info is.

Investigating as time permits.
-- 
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/