How to slow down SATA to 1.5 GBit/s ?

[Thomas Schmitt]

Hi,

> I have Cc'd mav@ who afaik did most of the ahci(4) work,

I found a similar PR
  http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg70510.html
and bothered mav for instructions how to upgrade
to a system that would suffice for diagnosing.

Meanwhile i suspect that there is a general
problem with SCSI commands which report error
codes. I even found a little bug in cdrskin
by watching when it gets stuck.
(SCSI error or "sense" replies are not
 necessarily a sign of a program error. They
 are often just part of the dialog.)


> Well I guess drives simply don't like `random other' commands being
> sent to them while a burn is in progress...

It depends on the media type.
CD and DVD-R[W] are vulnerable. It's a classic
side effect of hald.
On Linux, the burn just ends with some more or
less plausible SCSI error.
FreeBSD 8.0 freshly from DVD was less graceful.
Now it seems to know when not to let me touch
the drive. ("Now" is already before ahci.)


> I don't know if hald also sends direct scsi
> commands via pass(4) devices, so that
> may even need to be blocked too

Making drive access exclusive is quite a tragic
drama on Linux. Most burn programs rely on an
undocumented meaning of open(O_EXCL). That would
work well ... if there wasn't an older slightly
incompatible undocumented meaning.
(Cough.)
O_EXCL works on inode level, whereas we actually
would need locking on SCSI generic level, where
all possible users of a drive come together.

FreeBSD offers at least as many bypasses to the
drive as Linux does. I imagine that it is not
easy to lock them all.
I'm not done with exploring yet.


> > The port of xfburn generously (or daringly)
> > writes into /etc/devfs.rules :
> Ouch! :)

Yeah. What happened to good old group "floppy" ?

camcontrol devlist tells the particular device
files. (I learned today on my way to ahci.)


Have a nice day :)

Thomas