From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 16 22:52:14 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9E181065673 for ; Tue, 16 Mar 2010 22:52:14 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6B58FC08 for ; Tue, 16 Mar 2010 22:52:13 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 98BFD1E0012C; Tue, 16 Mar 2010 23:52:12 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id o2GMp9Gj040742; Tue, 16 Mar 2010 23:51:09 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id o2GMp9SY040741; Tue, 16 Mar 2010 23:51:09 +0100 (CET) (envelope-from nox) Date: Tue, 16 Mar 2010 23:51:09 +0100 (CET) From: Juergen Lock Message-Id: <201003162251.o2GMp9SY040741@triton8.kn-bremen.de> To: scdbackup@gmx.net X-Newsgroups: local.list.freebsd.hackers In-Reply-To: <10608773149940@192.168.2.69> References: <20100315201119.GA4860@triton8.kn-bremen.de> Organization: home X-Mailman-Approved-At: Tue, 16 Mar 2010 23:26:10 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: How to slow down SATA to 1.5 GBit/s ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 22:52:14 -0000 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