From owner-freebsd-gnome@FreeBSD.ORG Sun Feb 17 15:05:12 2008 Return-Path: Delivered-To: freebsd-gnome@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A76F16A418 for ; Sun, 17 Feb 2008 15:05:12 +0000 (UTC) (envelope-from thomas@FreeBSD.ORG) Received: from melamine.cuivre.fr.eu.org (melusine.cuivre.fr.eu.org [82.225.155.84]) by mx1.freebsd.org (Postfix) with ESMTP id 3D6D213C459 for ; Sun, 17 Feb 2008 15:05:12 +0000 (UTC) (envelope-from thomas@FreeBSD.ORG) Received: by melamine.cuivre.fr.eu.org (Postfix, from userid 1000) id 165E35C1F7; Sun, 17 Feb 2008 15:47:05 +0100 (CET) Date: Sun, 17 Feb 2008 15:47:04 +0100 From: Thomas Quinot To: Andriy Gapon Message-ID: <20080217144704.GA38221@melamine.cuivre.fr.eu.org> References: <47B81244.9090802@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47B81244.9090802@icyb.net.ua> X-message-flag: WARNING! Using Outlook can damage your computer. User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-gnome@freebsd.org Subject: Re: hal and "criss-crossed" atapicam X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2008 15:05:12 -0000 * Andriy Gapon, 2008-02-17 : > [Disclaimer: yes, I've read BUGS section of atapicam(4) (should probably > be named "CAVEATS"), but this is life.] Ah, well. The whole point of software development is to do things that are impossible. Or inadvisable. (Occasionally, both.) > I have a system with two IDE CD/DVD drives. atapicam and atapicd are > enabled and for some reason cd(4) unit numbers are criss-crossed > compared to the acd(4) numbers: > acd0 -> cd1 > acd1 -> cd0 > > acd0: CDRW at ata0-master UDMA33 > acd1: DVDR at ata1-master UDMA33 > cd0: Removable CD-ROM SCSI-0 device > cd1: Removable CD-ROM SCSI-0 device That would be an issue of CAM and ATA scanning controllers in a different order. Hard to say without at least complete "boot -v" and "camcontrol devlist -v" output. > These devices are both masters on different IDE channels. Right, otherwise the numbering would be consistent, since within a single controller both subsystems scan first the master then the slave. > Maybe this or maybe something else seems to confuse HAL a little bit. > Relevant snippets from lshal are pasted at the end. > As you can see, the net result is that HAL sees 3 non-ignored devices: > cd1 ("light-on"), cd0 ("dvdram"), acd1 ("dvdram" again). > For some reason, acd1 was not recognized as having a paired atapicam > device and situation is quite messy in general. I am not familiar with HAL's handling of ATAPI devices, but if what you are trying to do is to determine when two device nodes (say, an acd and a cd one) really are two interfaces to the same underlying device, I would not advise relying on unit numbers. The correct way to do that is to first identify the correspondance between ATA buses and CAM buses (as shown e.g. by "camcontrol devlist -v | grep '^scbus.*on ata'" and then note that on the CAM side, the master is always target 0 on its bugs and the slave, target 1. But then again, you should really ask yourself whether you really need to do that in the first place. What requirement are you trying to implement? From the point of view of HAL there are four device nodes on your system, why do you care whether these really are just two actual devices seen through different interfaces? In other words, you see three devices in HAL, and your question seems to imply that you expect to see only two, but why wouldn't you see *four* devices in HAL? > I would appreciate any advice on how to resolve this, either in atapicam > or in hald, either via configuration or via code. You can override cam's choice of unit numbers by wiring these down using kernel hints, see scsi(4) man page. Thomas.