----- Original Message -----
From: "Jeremy Chadwick"
On Sat, Feb 23, 2013 at 04:13:07PM -0800, Jeremy Chadwick wrote:
On Sun, Feb 24, 2013 at 02:28:08AM +0400, Michael BlackHeart wrote:
> 2013/2/24 Jeremy Chadwick <j...@koitsu.org>:
>
> {snipping irrelevant stuff and fixing formatting}
>
> atapci1@pci0:0:31:2: class=0x01018f card=0x26011043 chip=0x27c08086
rev=0x01 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'N10/ICH7 Family SATA IDE Controller'
>
> {snip}
I had written up a significantly longer reply to this Email, but once I
finished and went back reviewing the information provided, my memory
recalled having this exact conversation some time ago. After some
extensive digging, I found it -- circa late 2008:
http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046306.html
The result of this conversation was that FreeBSD at the time -- this
would have been probably FreeBSD 8.0 or 8.1 -- contained a bug:
ata_chipset.c (part of the classic ata(4) driver) was misidentifying the
different revisions of ICH7 and therefore limiting controller capacities
incorrectly.
Possibly a regression has been introduced as a result of the ATA-via-CAM
migration (now the default), which uses a completely different set of
code.
CC'ing mav@ because I need some help/clarification on this one.
I received an off-list mail from another ICH7 user, particularly one who
is using an SSD. Their controller is identical (same vendor/device ID),
and all their devices also claim "SATA" as well as "150MBytes/sec".
However, "diskinfo -t" on the individuals' SSD shows quite clearly rates
of up to 200MBytes/second.
So the issue appears to be cosmetic. The question is why.
Let me clarify because some list members have already gotten confused
about some of the information output by the kernel and utilities. I'm
going to use my own system (different controller, etc.) to educate list
members. The fact I'm using AHCI has no bearing on this educational
section, let me make that clear!
* The following output during boot reflects the results of the ATA
IDENTIFY command, and indicates what the **disk itself** (or more
specifically, the controller on the disk itself) claims it is capable
of:
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <INTEL SSDSA2CW080G3 4PC10302> ATA-8 SATA 2.x device
The "at ahcichX" indicates your using AHCI as you stated, if however
you see "at ataX" then your using the legacy ata driver still.
This indicates the ada0 disk supports up to the SATA 2.x revision (i.e.
SATA300). This DOES NOT indicate what the motherboard (or HBA) SATA
controllers' PHY/port is operating at; it only indicates what the disk
supports "up to".
* The subsequent output during boot reflects the actual motherboard (or
HBA) SATA controllers' PHY/port speed, including what has been
negotiated:
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
There's a 1:1 mapping between SATA revision and PHY speed, effectively,
unless otherwise throttled down or forced in some manner. I'm reminded
of the non-ATA_CAM function ata_satarev2str() where the revision map is
like this:
value 0 = "" (default speed value is used?? unsure)
value 1 = "SATA150" (150MB/sec)
value 2 = "SATA300" (300MB/sec)
value 3 = "SATA600" (600MB/sec)
value 0xff = "SATA" (default speed value is used)
else = "???" (default speed value is used?? unsure)
Now for the rest...
I've taken a look at the code and it's very difficult for me to follow;
I'm not entirely sure, but it does look like pieces of
sys/dev/ata/chipsets are still used today. I need mav@ to verify that
fact however, because if ata_intel_probe() isn't used any more, then
that might explain what's going on here (possibly).
When not using ahci this code is still used like in this case seen
in boot via:-
ada2 at ata2 bus 0 scbus1 target 0 lun 0
ada2: <ST3500320AS SD1A> ATA-8 SATA 2.x device
ada2: 150.000MB/s transfers (SATA, UDMA5, PIO 8192bytes)
"at ata2" shows its using the old ata driver, which is expected
if the controller doesn't have an ahci mode.
The "negotiated speed" printing comes from sys/cam/ata/ata_xpt.c, in
ata_announce_periph(). The code logic here is simple, while the complex
bits (e.g. what sets CTS_SATA_VALID_REVISION) are elsewhere.
Yes as I said looks like its using the default case for speed, so
for some reason the sata revision isn't being flagged as valid.
Having a quick look I'd suspect ata_sata_getrev or ata_intel_sata_getrev
is going to be where this info is coming from
Some blocks that stood out as something to check are:-
This on interacts with how reg = ATA_SSTATUS could be retrieve:-
if ((ctlr->chip->cfg1 & INTEL_ICH7)) {
ch->hw.pm_read = ata_intel_sata_ahci_read;
ch->hw.pm_write = ata_intel_sata_ahci_write;
} else {
ch->hw.pm_read = ata_intel_sata_sidpr_read;
ch->hw.pm_write = ata_intel_sata_sidpr_write;
}
This one sets up a custom handler for getrev, possibly needs another
special case for INTEL_ICH7?
if (ctlr->r_res2 != NULL ||
(ctlr->chip->cfg1 & INTEL_ICH5))
ctlr->getrev = ata_intel_sata_getrev;
As you've said its quite deep in the HW specific code so mav@ is
likely you're man. However if someone has the specs for the HW and
access to HW to test on it shouldn't be too hard to track down tbh.
Regards
Steve
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
