----- Original Message -----
From: "Jeremy Chadwick" <j...@koitsu.org>
To: "Steven Hartland" <kill...@multiplay.co.uk>
Cc: "Michael BlackHeart" <amdm...@gmail.com>; "freebsd-stable"
<freebsd-stable@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"
<j...@koitsu.org>
>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.
pciconf:-
atapci1@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 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"
