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>