How to slow down SATA to 1.5 GBit/s ?

[Juergen Lock]

In article <10606352212539 at 192.168.2.69> you write:
>Hi,
Hi!
>
>> > A leadout track. Sounds very CD-ish.
>> > With DVD and BD one should rather go for READ
>> > DISC INFORMATION and READ TRACK INFORMATION.
>
>Juergen Lock wrote:
>> Hmm you might want to followup on the PR with that hint...
>
>First i should become a less clueless newbie
>and get all my own stuff sorted out. Then
>i will probably take over the plight of ports
>maintainership from J.R. Oldroyd.
>Then i might study the sources of FreeBSD to
>find out what can be improved about DVD or BD.
>Only then i plan to become perky and tell
>other people what they should do. :))
>
 Heh ok. :)
>
>> > (Switching off-and-on a stuck USB drive is
>> > obviously not a healthy thing to do.)
>> Hehe.
>
>It would be quite annoying if the machine had any
>other job than serving as OS example.
>
 Well I guess we can be lucky that we do have the new usb stack now,
of course there always is room for improvement...
>
>> > First drives got stuck when disturbed while
>> > burning CD. Now the offender gets blocked until
>> > the vulnerable drive state ends.
>> [...]
>> Oh I do remember one issue:  Burning usually doesn't work when hald
>> is running,
>
>I am not aware to have noticed it on FreeBSD.
>  # ps -ax | fgrep hald
>  974   1  R+     0:00.00 fgrep hald
>
>The machine runs headless resp. in console mode.
>No X, no desktop. So probably no hald.
>
 Yeah hald comes with things like gnome, kde and so on, and xorg itself
now also needs it although that at least can also be configured to run
without it.

>The current behavior is quite like Alexander
>predicted it for FreeBSD back in 2006. It
>resembles the one of older SuSE Linuxes.
>
>The initial behavior, before i installed ports,
>was rather frightening. The drives got stuck
>when i accessed them while a CD was burned.

 Well I guess drives simply don't like `random other' commands being
sent to them while a burn is in progress...  Of course the a?cd(4)
drivers _could_ try to catch that situation and return an error or
something like that - is that what Linux does?  (Actually I don't know
if hald also sends direct scsi commands via pass(4) devices, so that
may even need to be blocked too...)

>I had to shutdown -p and re-power in order to
>revive the SATA burner. USB power cycling did
>not cause a panic but the drive did not show up
>as /dev/cd* any more. A warm reboot helped.
>
>So this is on my long todo list for inspection.
>
>
>> Actually I do have siis(4) here too, will have to test that someday...
>
>With xorriso you would get a nice backup
>program. :))
>The port is a bit outdated. GNU xorriso-0.5.0
>should compile on FreeBSD out of the box.
>It is a standalone package with minimal external
>dependencies. Well suited for a test.
>
>With a SATA drive at ata i need rw-permissions
>for these device files: acd, pass, cd, xpt.
>The port of xfburn generously (or daringly)
>writes into /etc/devfs.rules :
>  # rules for grip and xfburn support
>  add path 'acd*' mode 0666
>  add path 'cd*' mode 0666
>  add path 'pass*' mode 0666
>  add path 'xpt*' mode 0666
>
 Ouch! :)  Anyway I might give that a try once ahci(4) is working...
>
>Have a nice day :)
>
>Thomas

 Ditto!
	Juergen