From: Robby Workman <rw@rlworkman.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: SOLVED (mostly) - Two issues - cdrom_id and duplicate /sys entries
Date: Mon, 30 Apr 2007 20:52:41 +0000 [thread overview]
Message-ID: <46365719.3020207@rlworkman.net> (raw)
Replying to myself, some inlined and some not...
Robby Workman wrote:
> This is on Slackware -current, but with 2.6.21 kernel and
> udev-109. Sorry for omitting that the first time... :/
I think this was related to the libata stuff in the kernel.
According to CONFIG_ATA help, ATA optical devices should also
be supported, but...
I was trying to keep the config for 2.6.21 as close to the stock
Slackware generic kernel as possible, but I somehow managed to
mark CONFIG_BLK_DEV_IDECD as "m" instead of "y" -- changing it
back to "y" results in the the optical devices being assigned
/dev/hd* nodes, which makes cdrom_id return correct values and
all is well. However, that raises additional questions:
> Robby Workman wrote:
>> First, it seems that /lib/udev/cdrom_id is not exporting correct
>> information about the capabilities of optical media drives.
>> This system contains a Lite-On combo cd writer / dvd reader and
>> an NEC dvd writer drive, but the cdrom_id binary returns this for
>> each of them:
>>
>> root@isotope:/lib/udev# ./cdrom_id --export /dev/sr{0,1,2,3}
>> ID_CDROM=1
>>
>> See http://rlworkman.net/attr-walk/ for the udevinfo attribute
>> walks on each of the devices.
>>
>> Of course, this brings up the second issue: there are only two
>> optical drives in this box, and there are four devices created.
>> 0 and 2 are essentially "mirrors" of one another, as are 1 and 3.
>> Interestingly enough, after dumping the udevinfo output to the
>> files linked above, sr1 and sr3 show different sizes, even though
>> they are the same drive. A diff of the respective files shows a
>> few more things that are different, but none as strange as the
>> size difference... :/
>>
>> bash-3.2$ grep size sr?-attributes
>> sr0-attributes: ATTR{size}="2097151"
>> sr1-attributes: ATTR{size}="4"
>> sr2-attributes: ATTR{size}="2097151"
>> sr3-attributes: ATTR{size}="9143552"
If the new libata stuff is supposed to support these (if I'm reading
that incorrectly, please liberally apply cluebat), then why is the
cdrom_id binary unable to get the proper attributes?
Along the same lines, why were there two "mirror" device nodes?
In essence, is this problem entirely PEBKAC (as it's easy enough to
build the kernel in such a way that it works correctly), or is it
something that should be reported to LKML?
--
http://rlworkman.net
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
reply other threads:[~2007-04-30 20:52 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46365719.3020207@rlworkman.net \
--to=rw@rlworkman.net \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).