AHCI/ATA_CAM for dummies?

[Doug Barton]

I'd like to test the new stuff, but my main concern at this point is
that I am not 100% sure how to change my fstab, what will happen if I
need to revert, etc. I'm sure I probably _could_ figure it out, but it
would save me a lot of time if someone could write down really
explicit step-by-step instructions ... put this in your kernel config,
do this to fstab, do this if it blows up, etc.

Any takers? :)

Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/

_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

[Vincent Hoffman]

Doug Barton wrote:
> I'd like to test the new stuff, but my main concern at this point is
> that I am not 100% sure how to change my fstab, what will happen if I
> need to revert, etc. I'm sure I probably _could_ figure it out, but it
> would save me a lot of time if someone could write down really
> explicit step-by-step instructions ... put this in your kernel config,
> do this to fstab, do this if it blows up, etc.
>
> Any takers? :)
>
>
> Doug
>
>

For me trying ahci was very easy.
boot using the usb image, use the fixit environment.
I use ufs so I used tunefs to label all my partitions.
tunefs -L ROOTFS /path/to/rootfs
and so on for all my ufs partitions.
and then for swap,
glabel label SWAP /dev/ad1p1 (or your path to swap partition)

next mount the root filesystem and edit the fstab.
mkdir -p /mnt/rootfs
mount /dev/ufs/ROOTFS /mnt/rootfs
vi /mnt/rootfs/etc/fstab

my fstab looks like

/dev/ufs/SSDROOT / ufs rw,noatime 1 1
/dev/ufs/SSDUSR /usr ufs rw,noatime 2 2
/dev/ufs/SSDVAR /var ufs rw,noatime 2 2
/dev/ufs/TMP /tmp ufs rw,noatime 2 2
/dev/label/SWAP none swap sw 0 0
/dev/ufs/SCRATCH /scratch ufs rw,noatime 2 2

but adapt to fit.

I then added
ahci_load="YES"
to /mnt/rootfs/boot/loader.conf
and rebooted.

as yet I havent tried the rest of the ATA_CAM stuff though.

using labels means switching back is easy too (I switched back for a bit
until i found the latest smartmon tools supports the ahci ada devices.)

Vince

(obviously now I've sent this I'm bound to have forgotten something but
it really was very simple.)

[Nenhum_de_Nos]

On Sat, December 12, 2009 20:46, Vincent Hoffman wrote:
> Doug Barton wrote:
>> I'd like to test the new stuff, but my main concern at this point is
>> that I am not 100% sure how to change my fstab, what will happen if I
>> need to revert, etc. I'm sure I probably _could_ figure it out, but it
>> would save me a lot of time if someone could write down really
>> explicit step-by-step instructions ... put this in your kernel config,
>> do this to fstab, do this if it blows up, etc.
>>
>> Any takers? :)
>>
>>
>> Doug
>>
>>
> For me trying ahci was very easy.
> boot using the usb image, use the fixit environment.
> I use ufs so I used tunefs to label all my partitions.
> tunefs -L ROOTFS /path/to/rootfs

I got curious about this. what I should choose, glabel or this ?
I did this using glabel and so far so good.

thanks,

matheus

--
We will call you cygnus,
The God of balance you shall be

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

http://en.wikipedia.org/wiki/Posting_style

[Ivan Voras]

Nenhum_de_Nos wrote:
> On Sat, December 12, 2009 20:46, Vincent Hoffman wrote:
>> Doug Barton wrote:
>>> I'd like to test the new stuff, but my main concern at this point is
>>> that I am not 100% sure how to change my fstab, what will happen if I
>>> need to revert, etc. I'm sure I probably _could_ figure it out, but it
>>> would save me a lot of time if someone could write down really
>>> explicit step-by-step instructions ... put this in your kernel config,
>>> do this to fstab, do this if it blows up, etc.
>>>
>>> Any takers? :)
>>>
>>>
>>> Doug
>>>
>>>
>> For me trying ahci was very easy.
>> boot using the usb image, use the fixit environment.
>> I use ufs so I used tunefs to label all my partitions.
>> tunefs -L ROOTFS /path/to/rootfs
>
> I got curious about this. what I should choose, glabel or this ?

Technically, both are handled by glabel.

> I did this using glabel and so far so good.

All variants: ufs, ufsid, glabel are handled the same - the differences
are cosmetic and a matter of user's preferences.

Personally, I mostly use ufsid because it is always there and doesn't
require special configuration.

[Doug Barton]

Ivan Voras wrote:

> Doug Barton wrote:
>> I'd like to test the new stuff, but my main concern at this point is
>> that I am not 100% sure how to change my fstab, what will happen if I
>> need to revert, etc. I'm sure I probably _could_ figure it out, but it
>> would save me a lot of time if someone could write down really
>> explicit step-by-step instructions ... put this in your kernel config,
>> do this to fstab, do this if it blows up, etc.
>>
>> Any takers? :)
>

> Maybe
>
> http://ivoras.sharanet.org/blog/tree/2009-11-17.trying-ahci-in-8.0.html

That has a lot of good information, but most of it is irrelevant to me
(you seriously missed the "for dummies" issue). :) Also, thanks to
everyone who gave suggestions related to glabel, but I don't want to
use it.

What I've done that's worked is:

1. Add "options ATA_CAM" to my kernel config. AFAICS it's not
necessary to do anything special with ahci, that's included in ata_cam.

2. I already had atapicam in my kernel (which I commented out since
it's included in ata_cam as well), but I'm assuming that at least the
following are needed:
device scbus # SCSI bus (required for SCSI)
device da # Direct Access (disks)
device cd # CD
device pass # Passthrough device (direct SCSI access)

3. Comment out everything ata-related EXCEPT "device ata". Without
that one the kernel boots but stops cold when it tries to mount the
root file system.

4. Edit fstab. I actually copied all the ad0 entries, commented out
the old ones, and in the new ones I changed "ad0" to "ada0".

5. Update dumpdev in /etc/rc.conf

So far so good. :) I am actually kind of curious as to why "device
ata" is needed, but it doesn't seem to be hurting anything.

Regarding what's on your web page Ivan, I'm confused about NCQ. I did
what you suggested:
camcontrol tags ada0
(pass0:ata0:0:0:0): device openings: 1

Which is different from what you got. The relevant lines from
'camcontrol identify' are:
pass0: <Hitachi HTS721010G9SA00 MCZOC10H> ATA-7 SATA 1.x device
pass0: 100.000MB/s transfers (UDMA5, PIO size 8192bytes)
protocol ATA/ATAPI-7 SATA 1.x
Native Command Queuing (NCQ) yes 31/0x1F

Is there something I need to change to make this work, or is NCQ not
available for SATA 1.x devices? Are there any other parameters worth
tweaking?

Thanks,

[b. f.]

>1. Add "options ATA_CAM" to my kernel config. AFAICS it's not
>necessary to do anything special with ahci, that's included in ata_cam.

If you have AHCI-capable hardware and compatible BIOS, then there are
now *two* AHCI drivers:

[1] ataahci, together with the other ata(4) code, and
[2] ahci(4), which doesn't need ata(4).

ahci(4) is better, so you should use that if you can. You only need
ata(4) if you want to use non-AHCI hardware, or, rarely, AHCI hardware
in legacy mode. If you place both in your kernel, ahci(4) should take
priority over ata(4) and attach to devices where possible.

See the ahci(4) manpage and

http://lists.freebsd.org/pipermail/svn-src-all/2009-December/016791.html

>2. I already had atapicam in my kernel (which I commented out since
>it's included in ata_cam as well), but I'm assuming that at least the
>following are needed:
>device scbus # SCSI bus (required for SCSI)
>device da # Direct Access (disks)
>device cd # CD
>device pass # Passthrough device (direct SCSI access)

Yes. But see above -- you may want to add:

device ahci

>3. Comment out everything ata-related EXCEPT "device ata". Without
>that one the kernel boots but stops cold when it tries to mount the
>root file system.

Again, see above. You may not actually need ata(4). Even if you do
want it, you don't actually need all of ata(4); you can just add the
portion you need:

device atacore

and the chipset-specific parts that correspond to your hardware.
Usually, something like:

atapci
ataahci
atanvidia

for example. See src/sys/conf/NOTES. You can also have ataisa,
atabus, and atacard if you need them; but you should remove device
atadisk, ataraid, atapicd, atapifd, atapist, and atapicam if you have
ATA_CAM, which uses other means to give equivalent functionality,
except in the case of ataraid. For that, ATA_CAM has no replacement;
see

http://lists.freebsd.org/pipermail/freebsd-current/2009-December/013956.html

where mav@ states:

"The main regression of the new mode is a lack of ataraid alternative, to
support cheap BIOS-based ATA RAIDs. If somebody has time and wish to
port that code from inside ata(4) into GEOM module, to make it work over
CAM also, I would appreciate that and propose a help, if needed."

and

http://lists.freebsd.org/pipermail/freebsd-arch/2009-December/009742.html

..

>So far so good. :) I am actually kind of curious as to why "device
>ata" is needed, but it doesn't seem to be hurting anything.

It is needed if you have AHCI hardware, and are operating in AHCI
mode, but don't have ahci(4) in your kernel; or if you don't have AHCI
hardware, or have AHCI hardware operating in legacy mode, and still
want to use ATA devices.

..

>Is there something I need to change to make this work, or is NCQ not
>available for SATA 1.x devices? Are there any other parameters worth
>tweaking?

It may be available, but you need to look at the messages regarding
your other hardware, not just your disk drive. Do you have an
AHCI-capable motherboard and chipset? Are you in AHCI mode? The
following kinds of considerations may be relevant as well, for others,
if not for your specific case (although these messages were written
before the last round of revisions, and mav@ may have made some
changes):

http://lists.freebsd.org/pipermail/freebsd-stable/2009-December/053381.html
http://lists.freebsd.org/pipermail/freebsd-current/2009-November/013477.html
http://lists.freebsd.org/pipermail/freebsd-current/2009-November/013639.html

Some non-AHCI hardware can do NCQ, but needs drivers that mav@ has not
written, and probably won't write. Someone willing to take the time
to do so could port some of these drivers from Linux.

b.

[b. f.]

On 12/14/09, b. f. <bf1...@googlemail.com> wrote:
..
>>So far so good. :) I am actually kind of curious as to why "device
>>ata" is needed, but it doesn't seem to be hurting anything.
>
> It is needed if you have AHCI hardware, and are operating in AHCI
> mode, but don't have ahci(4) in your kernel; or if you don't have AHCI
> hardware, or have AHCI hardware operating in legacy mode, and still
> want to use ATA devices.
>

I forgot to mention that ata(4) is also superfluous if you have
hardware that can use the siis(4) driver, and that driver is in your
kernel.

[Doug Barton]

Thank you for your very informative reply. :) I left a few things out
of my first post to try and keep it brief, so I'll add some more
details below.

You might seriously consider working something at this level up for
the wiki, perhaps working with mav as well. IMO this stuff is never
going to get wide testing if we don't make it a whole lot easier for
people to do so.

b. f. wrote:
>> 1. Add "options ATA_CAM" to my kernel config. AFAICS it's not
>> necessary to do anything special with ahci, that's included in ata_cam.
>
> If you have AHCI-capable hardware and compatible BIOS,

One thing I did not include in my previous post was that I actually
did try adding the ahci device to my kernel config, and didn't get any
hits. Per your other message tonight I tried again adding ahci and
siis and booting verbose, no joy. This is on a laptop so I'm not
really surprised, just disappointed. :)

> Again, see above. You may not actually need ata(4). Even if you do
> want it, you don't actually need all of ata(4); you can just add the
> portion you need:
>
> device atacore
>
> and the chipset-specific parts that correspond to your hardware.
> Usually, something like:
>
> atapci
> ataahci
> atanvidia

The only nvidia thing I have is my graphics card, so I'm assuming I
could get away with just the first two? Also, how much of an advantage
does stripping down the ata stuff give? Is it just a bit of kernel
memory? It's working atm so I'm sort of inclined to leave it alone. :)

Thanks again,

Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/

_______________________________________________

[K.R.]

On 14.12.2009 5:27, Doug Barton wrote:
> Is there something I need to change to make this work, or is NCQ not
> available for SATA 1.x devices? Are there any other parameters worth
> tweaking?
>

From what I know, SATA 1 does not support NCQ. It's a feature of SATA 2.

--
Kamigishi Rei
KREI-RIPE

[b. f.]

On 12/14/09, Doug Barton <do...@freebsd.org> wrote:

>
> One thing I did not include in my previous post was that I actually
> did try adding the ahci device to my kernel config, and didn't get any
> hits. Per your other message tonight I tried again adding ahci and
> siis and booting verbose, no joy. This is on a laptop so I'm not
> really surprised, just disappointed. :)

If you use 'pciconf -lv', is the subclass for your SATA controller
listed as either RAID or AHCI? If not, either your hardware doesn't
support AHCI, or it is switched into legacy mode (or there is a
problem that mav@ would probably like to know about). Try looking in
the BIOS setup for a place where you can change the mode.

>
>> Again, see above. You may not actually need ata(4). Even if you do
>> want it, you don't actually need all of ata(4); you can just add the
>> portion you need:
>>
>> device atacore
>>
>> and the chipset-specific parts that correspond to your hardware.
>> Usually, something like:
>>
>> atapci
>> ataahci
>> atanvidia
>
> The only nvidia thing I have is my graphics card, so I'm assuming I
> could get away with just the first two? Also, how much of an advantage
> does stripping down the ata stuff give? Is it just a bit of kernel
> memory? It's working atm so I'm sort of inclined to leave it alone. :)
>

I was only offering these three as an example -- the modules that you
should choose depend on your IDE and ATA controller(s). atapci is the
generic default module, ataahci is required for ahci without ahci(4),
and then there may be a vendor-specific module as well. Yes, you save
a bit of memory, compile time, and space -- but if you don't want to
use the modular setup, just use the

device ata

catchall.

b.

[Doug Barton]

b. f. wrote:
> On 12/14/09, Doug Barton <do...@freebsd.org> wrote:
>
>> One thing I did not include in my previous post was that I actually
>> did try adding the ahci device to my kernel config, and didn't get any
>> hits. Per your other message tonight I tried again adding ahci and
>> siis and booting verbose, no joy. This is on a laptop so I'm not
>> really surprised, just disappointed. :)
>
> If you use 'pciconf -lv', is the subclass for your SATA controller
> listed as either RAID or AHCI?

I should also have mentioned that I looked in my BIOS and didn't see
anything relevant. Here is the pciconf output:

atapci0@pci0:0:31:2: class=0x010180 card=0x01c21028 chip=0x27c48086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage
Controller'
class = mass storage
subclass = ATA

Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/

_______________________________________________

[b. f.]

On 12/14/09, Doug Barton <do...@freebsd.org> wrote:
> b. f. wrote:
>> On 12/14/09, Doug Barton <do...@freebsd.org> wrote:
>>
>>> One thing I did not include in my previous post was that I actually
>>> did try adding the ahci device to my kernel config, and didn't get any
>>> hits. Per your other message tonight I tried again adding ahci and
>>> siis and booting verbose, no joy. This is on a laptop so I'm not
>>> really surprised, just disappointed. :)
>>
>> If you use 'pciconf -lv', is the subclass for your SATA controller
>> listed as either RAID or AHCI?
>
> I should also have mentioned that I looked in my BIOS and didn't see
> anything relevant. Here is the pciconf output:
>
> atapci0@pci0:0:31:2: class=0x010180 card=0x01c21028 chip=0x27c48086
> rev=0x01 hdr=0x00
> vendor = 'Intel Corporation'
> device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage
> Controller'
> class = mass storage
> subclass = ATA
>

Hmm. From what little I know, your chipset should support AHCI, so
perhaps your motherboard or bios isn't set up right?:

p. 39, 44 of the pdf at:

http://www.intel.com/design/chipsets/datashts/307013.htm

b.

[Doug Barton]

b. f. wrote:
> Hmm. From what little I know, your chipset should support AHCI, so
> perhaps your motherboard or bios isn't set up right?:
>
> p. 39, 44 of the pdf at:
>
> http://www.intel.com/design/chipsets/datashts/307013.htm

On page 44 it says, "for some features, hardware support in the SATA
device ..."

Full output of 'camcontrol identify':

pass0: <Hitachi HTS721010G9SA00 MCZOC10H> ATA-7 SATA 1.x device
pass0: 100.000MB/s transfers (UDMA5, PIO size 8192bytes)

protocol ATA/ATAPI-7 SATA 1.x
device model Hitachi HTS721010G9SA00
firmware revision MCZOC10H
serial number MPCZN7Y0GZSYAL
cylinders 16383
heads 16
sectors/track 63
sector size logical 512, physical 512, offset 0
LBA supported 195371568 sectors
LBA48 supported 195371568 sectors
PIO supported PIO4
DMA supported WDMA2 UDMA5
overlap not supported

Feature Support Enable Value Vendor
read ahead yes yes
write cache yes yes
flush cache yes yes

Native Command Queuing (NCQ) yes 31/0x1F

Tagged Command Queuing (TCQ) no no 31/0x1F
SMART yes yes
microcode download yes yes
security yes no
power management yes yes
advanced power management yes yes 16512/0x4080
automatic acoustic management yes yes 254/0xFE 128/0x80
media status notification no no
power-up in Standby yes no
write-read-verify no no 0/0x0
unload no no
free-fall no no

Perhaps it does not have the requisite "hardware support" for ahci?

--

Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/

_______________________________________________

[Daniel Braniss]

probably, but have you checked the BIOS setup?

my 5c.
danny

[b. f.]

On 12/14/09, Doug Barton <do...@freebsd.org> wrote:

> b. f. wrote:
>> Hmm. From what little I know, your chipset should support AHCI, so
>> perhaps your motherboard or bios isn't set up right?:
>>
>> p. 39, 44 of the pdf at:
>>
>> http://www.intel.com/design/chipsets/datashts/307013.htm
>
> On page 44 it says, "for some features, hardware support in the SATA
> device ..."
>

I believe what they meant in the Intel document was that in order to
use certain features supported by AHCI, such as NCQ, the disk drive
must also support them. Your disk drive seems to support NCQ.

> pass0: <Hitachi HTS721010G9SA00 MCZOC10H> ATA-7 SATA 1.x device
> pass0: 100.000MB/s transfers (UDMA5, PIO size 8192bytes)

..

> Perhaps it does not have the requisite "hardware support" for ahci?

This is the disk drive. AHCI is for host controllers:

http://www.intel.com/technology/serialata/ahci.htm

So this does not seem to explain why ahci(4) fails to attach to your
SATA controller. I suspect that your bios or motherboard fails to use
AHCI mode. Maybe there is a later bios revision, or some jumper
settings on the board that will allow it to be enabled. You may have
to talk to the manufacturer. Of course, there is a small chance that
there is a problem with our drivers. Have you tried a live CD of a
Linux distro, to see AHCI works with another OS?

b.

[Olivier Certner]

> All variants: ufs, ufsid, glabel are handled the same - the differences
> are cosmetic and a matter of user's preferences.

All the variants may be handled the same, but I found that I can put a '_' in
a pure glabel name (using glabel on-storage format, one sector at the
provider's end, I guess) whereas I can't in a ufs-provided label (using
7.2R).

Olivier

[Dag-Erling Smørgrav]

"K.R." <spa...@haruhiism.net> writes:
> From what I know, SATA 1 does not support NCQ. It's a feature of SATA
> 2.

a) There is no such thing as SATA 1 or 2; there is only SATA, although
marketroids sometimes incorrectly refer to drives that support 3 Gbps
transfer speed as SATA II drives.

b) SATA has supported NCQ from the very beginning. In fact, command
queueing already existed in PATA at the time SATA was finalized.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Doug Barton]

b. f. wrote:
> On 12/14/09, Doug Barton <do...@freebsd.org> wrote:
> I believe what they meant in the Intel document was that in order to
> use certain features supported by AHCI, such as NCQ, the disk drive
> must also support them. Your disk drive seems to support NCQ.

Ok, I believe you. :) This is clearly not my area.

> So this does not seem to explain why ahci(4) fails to attach to your
> SATA controller. I suspect that your bios or motherboard fails to use
> AHCI mode. Maybe there is a later bios revision,

There is no later BIOS available, at least not from Dell. This is a
Latitude D620 laptop. And as I said previously, there are no BIOS
options that mention anything even remotely similar. There are two
hard drive related options. One is related to making it "slower and
quieter" vs. "faster and noisier." Guess which one I picked. :) The
other is related to power management (DPMI).

I did look up the spec sheet on the hard drive last night, and
although it does mention SATA and NCQ it does not explicitly mention
AHCI.
http://www.hitachigst.com/tech/techlib.nsf/techdocs/50C8DBC2A315A4C786256F400065B756/$file/7K100_SATA_FINAL_DS.pdf
and
http://www.hitachigst.com/tech/techlib.nsf/products/Travelstar_7K100
if you're interested.

I also didn't see any mentions of jumpers on the drive to enable AHCI,
which I was kind of hoping for since that's pretty easy to remove.

> or some jumper
> settings on the board that will allow it to be enabled. You may have
> to talk to the manufacturer.

I would be willing to dive into that if someone could give me clear
guidance that one exists. I'm not really eager to open the
case otherwise.

> Of course, there is a small chance that
> there is a problem with our drivers. Have you tried a live CD of a
> Linux distro, to see AHCI works with another OS?

No, but I'm happy to do so. Any suggestions on what distro is most
likely to succeed, and what to look for? I have used Ubuntu for a
project in the past with good success but I'd be willing to try
anything that folks think will work.

In any case I do appreciate your time on this. I run -current on
purpose to try out new features, help get them fleshed out from a
"regular user" perspective, and to expose bugs (often my own of
course). Better performance and cool new toys don't hurt either ...

Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/

[Adam Vande More]

A bit of research leads to believe you are SOL on ahci/NCQ for this system
unless you're able to hack a BIOS. I believe both drive and controller are
capable of running it, but Dell has disabled it as an option for some
reason.

--
Adam Vande More

[b. f.]

On 12/14/09, Adam Vande More <amvan...@gmail.com> wrote:
> On Mon, Dec 14, 2009 at 2:47 PM, Doug Barton <do...@freebsd.org> wrote:
>
>> b. f. wrote:
>> > On 12/14/09, Doug Barton <do...@freebsd.org> wrote:

>>
>> I did look up the spec sheet on the hard drive last night, and
>> although it does mention SATA and NCQ it does not explicitly mention
>> AHCI.

This isn't surprising, because, as mentioned before, AHCI is largely
concerned with the workings of host controllers, and not with most
storage devices. It is reassuring to see that the specs agree with
our drivers with respect to the NCQ.

>
> A bit of research leads to believe you are SOL on ahci/NCQ for this system
> unless you're able to hack a BIOS. I believe both drive and controller are
> capable of running it, but Dell has disabled it as an option for some
> reason.
>

As Adam says, a brief look at the web shows that people have long been
complaining about the fact that the BIOS of these machines does not
allow users to employ AHCI. If, as you say, Dell hasn't been willing
to fix this, then you are left with only a few options:

1) try to find a replacement BIOS ( maybe someone is working on
coreboot support for this model? :
http://www.coreboot.org/Welcome_to_coreboot )

2) employ a driver that circumvents the crippled BIOS, and enables AHCI.

With regard to 2), there have been a number of hacks for Linux that
enable AHCI on these and related machines, with varying degrees of
success. See, for example:

http://www.mail-archive.com/linu...@vger.kernel.org/msg09698.html
(and follow-ups!)
http://tartarus.org/ds/quirk-ich-force-ahci.patch
http://www.codon.org.uk/~mjg59/tmp/hack_ahci
http://mjg59.livejournal.com/85504.html

Maybe a knowledgeable person, like mav@ or jhb@, could exploit some of
these ideas in FreeBSD to allow you and others in similar predicaments
to use AHCI on your machines?

Regards,
b.

[Doug Barton]

b. f. wrote:
> Maybe a knowledgeable person, like mav@ or jhb@, could exploit some of
> these ideas in FreeBSD to allow you and others in similar predicaments
> to use AHCI on your machines?

Sounds good to me. :) There wasn't anything that looked promising at
coreboot, and a cursory search for other BIOS sources didn't turn up
anything either.

Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/

_______________________________________________

[Boris Samorodov]

"b. f." <bf1...@googlemail.com> writes:

> If you use 'pciconf -lv', is the subclass for your SATA controller
> listed as either RAID or AHCI?

If I'm not mistaken that should be "RAID or SATA".

--
WBR, bsam

[Andriy Gapon]

on 14/12/2009 22:47 Doug Barton said the following:

> I did look up the spec sheet on the hard drive last night, and
> although it does mention SATA and NCQ it does not explicitly mention
> AHCI.
> http://www.hitachigst.com/tech/techlib.nsf/techdocs/50C8DBC2A315A4C786256F400065B756/$file/7K100_SATA_FINAL_DS.pdf
> and
> http://www.hitachigst.com/tech/techlib.nsf/products/Travelstar_7K100
> if you're interested.
>
> I also didn't see any mentions of jumpers on the drive to enable AHCI,
> which I was kind of hoping for since that's pretty easy to remove.
>

AHCI stands for Advanced Host Controller Interface, which means that it has to do
with an interface that a controller presents to a host OS, not with an interface
between the controller and a drive. OTOH, AHCI is applicable only to SATA
controllers. The opposite is not true, though, not all SATA controllers are AHCI.

--
Andriy Gapon

[Daniel O'Connor]

On Tue, 15 Dec 2009, Bruce Simpson wrote:
> b. f. wrote:
> > "The main regression of the new mode is a lack of ataraid
> > alternative, to support cheap BIOS-based ATA RAIDs. If somebody has
> > time and wish to port that code from inside ata(4) into GEOM
> > module, to make it work over CAM also, I would appreciate that and
> > propose a help, if needed."
>

> Please search stable@ archives for my bad experiences with ataraid.
>
> IMHO, this stuff needs serious attention before it could be
> considered useful, so the lack of ataraid in the new world order is
> not that much of a loss, to my mind anyway.

It worked well in 4.x in my experience, but I had issues with 6.x and
switched to "real" (3ware) RAID cards after that.

That said even in 4.x you could get spontaneous splits which was quite
annoying.

6.x would do things like pick the "wrong" side of the mirror (ie one
that is out of date) which causes hilarity to ensue when you find data
for the last week has gone away..

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C