Date: Sun, 24 Feb 2013 05:48:46 -0000 From: "Steven Hartland" <killing@multiplay.co.uk> To: "Jeremy Chadwick" <jdc@koitsu.org>, "Michael BlackHeart" <amdmiek@gmail.com> Cc: mav@freebsd.org, freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: Old ICH7 SATA-2 question Message-ID: <0568D24FDB4B4057B59AC1433E75B1BE@multiplay.co.uk> References: <CA%2BAz77OiEauxDK_73NgZgbJCk0HHfmALywS4ZQ3KwQiiuyGDiQ@mail.gmail.com> <20130223211932.GA41809@icarus.home.lan> <CA%2BAz77NHoPc2DoyQDUQQRtbLWrDndmRp91BfjTz7Gfk35r4d5g@mail.gmail.com> <20130224001307.GA43436@icarus.home.lan> <20130224030927.GA46638@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
----- 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 <jdc@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 postmaster@multiplay.co.uk.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0568D24FDB4B4057B59AC1433E75B1BE>