hal and "criss-crossed" atapicam

[Andriy Gapon]

> * 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 <LITE-ON LTR-40125W/WS03> at ata0-master UDMA33
>> acd1: DVDR <HL-DT-ST DVDRAM GSA-4163B/A105> at ata1-master UDMA33
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
look at these lines, and read at the end
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
>> cd0: <HL-DT-ST DVDRAM GSA-4163B A105> Removable CD-ROM SCSI-0 device
>> cd1: <LITE-ON LTR-40125W WS03> 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.

Actually, after your email I tried reboot several times and it happens
both ways - sometimes the mapping is 0->0, 1->1, sometimes
criss-crossed. So this seems like some sort of a timing issue.
I guess this is normal and happens from time to time.
On the other hand, is it possible for atapicam to somehow query
underlying ATA channel numbers and hard-derive unit numbers from that ?
Something like ATA layer does when ATA_STATIC_ID kernel option is given.
Well, maybe this is not applicable to atapi, so I might be just mumbling
nonsense here.

>> 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?

No, no :-) HAL actually sees 4 devices, but its default behavior is to
be smart and protective and to mark atapi devices as "ignored" if they
have atapicam partners.
As the manual page warns, it is indeed a bad thing to access the same
device via two interface simultaneously. And hald is very active at
tasting devices, so people experienced crashes and other weird things.


>> 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.

Thank you very much! It's almost obvious that that manual is "it", but I
 didn't even consider it.

Returning to HAL. A wild guess: maybe a space in device inquiry info
confuses hald - I haven't look into the code, but something in lshal
output looked strange for the dvd-ram device when seen via atapicam.

-- 
Andriy Gapon