Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Mar 2010 23:51:09 +0100 (CET)
From:      Juergen Lock <nox@jelal.kn-bremen.de>
To:        scdbackup@gmx.net
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: How to slow down SATA to 1.5 GBit/s ?
Message-ID:  <201003162251.o2GMp9SY040741@triton8.kn-bremen.de>
In-Reply-To: <10608773149940@192.168.2.69>
References:  <20100315201119.GA4860@triton8.kn-bremen.de>

next in thread | previous in thread | raw e-mail | index | archive | help
In article <10608773149940@192.168.2.69> you write:
>Hi,
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

 Hm thats my post, wrong link? :)

>and bothered mav for instructions how to upgrade
>to a system that would suffice for diagnosing.
>
 That's also documented in the handbook, starting with `24.5.2 Staying
Stable with FreeBSD' here:
	http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html

>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.
>
 Or maybe burning apps should just invoke hal-disable-polling(1), I
suspect that's intended for these kind of things...
>
>> > 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.)
>
 Yep.
>
>Have a nice day :)
>
>Thomas

 Ditto!
	Juergen



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201003162251.o2GMp9SY040741>