Old ICH7 SATA-2 question

[Steven Hartland]

----- Original Message ----- 
From: "Jeremy Chadwick" <jdc at koitsu.org>
To: "Steven Hartland" <killing at multiplay.co.uk>
Cc: "Michael BlackHeart" <amdmiek at gmail.com>; "freebsd-stable" <freebsd-stable at freebsd.org>
Sent: Sunday, February 24, 2013 2:07 AM
Subject: Re: Old ICH7 SATA-2 question


> On Sun, Feb 24, 2013 at 01:56:46AM -0000, Steven Hartland wrote:
>> ----- Original Message ----- From: "Jeremy Chadwick"
>> <jdc at koitsu.org>
>> >On Sun, Feb 24, 2013 at 02:28:08AM +0400, Michael BlackHeart wrote:
>> >>2013/2/24 Jeremy Chadwick <jdc at koitsu.org>:
>> >>
>> >>{snipping irrelevant stuff and fixing formatting}
>> >>
>> >>atapci1 at 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.
>> 
>> pciconf:-
>> atapci1 at pci0:0:31:2: class=0x01018f card=0x26011043 chip=0x27c08086
>> rev=0x01 hdr=0x00
>> 
>> The PCI ID's listed aren't AHCI so are using legacy ata not ahci, the two
>> devices listed are:-
>> { ATA_I82801GB,     0,          0, 1, ATA_UDMA5, "ICH7" },
>> { ATA_I82801GB_S1,  0, INTEL_ICH7, 0, ATA_SA300, "ICH7" },
>> 
>> Boot details:-
>> atapci0: <Intel ICH7 UDMA100 controller> port..
>> ata0: <ATA channel> at channel 0 on atapci0
>> atapci1: <Intel ICH7 SATA300 controller> port...
>> ata2: <ATA channel> at channel 0 on atapci1
>> ata3: <ATA channel> at channel 1 on atapci1
>> 
>> Then your disks:-
>> ada3 at ata2 bus 0 scbus1 target 1 lun 0
>> ada3: <WDC WD20EARX-00PASB0 51.0AB51> ATA-8 SATA 3.x device
>> 
>> So your disks are in theory connected to a sata 2 compatible controller
>> which is being correctly identified.
>> 
>> You might want to try a verbose boot to see if that gives any information.
>> 
>> Also check your bios to see if it has an AHCI mode for the controller
>> and try that as its currently running in legacy.
> 
> Steve,
> 
> His controller model is ATA_I82801GB_S1, but does not support AHCI per
> Intel spec.  The "Desktop" revision of ICH7 (not ICH7R) does not support
> AHCI, but supports SATA300.  The "Mobile" revision of ICH7 does not
> support AHCI and also is limited to SATA150.  He has the "Desktop"
> revision.

I've seen bios in the past which have the option to toggle between these
hence worth checking.

> Your above dmesg/ada3 output shown does not indicate the negotiated PHY
> speed; it's showing the ATA IDENTIFY results, saying "this disk claims
> to support a SATA600 PHY".  That's not the same thing.

Never said it did, just that it indicated it was connected to a sata 2
compatible controller, which rules out PCI ID issues indicated in the
post you linked.

> What's missing from your dmesg/ada3 output is the "transfer rate" and
> the supposed PHY speed.  That is what's showing up wrong for Michael,
> and for another user too.
> 
> However, it's a **cosmetic problem**, because the true throughput I/O
> rate, despite what dmesg (xpt(4)) says, is actually higher.  Another
> user mailed me off-list and showed me this.

Interesting, the sata revision of the device determines its reported
speed. Looking the camcontrol output looks like the "default" case
is being triggered where it doesn't think the sata revision is valid
for some reason.

A verbose boot may provide some insite into why this is.

    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 at multiplay.co.uk.