Red Hat Bugzilla – Bug 167291
CAPI subsystem not working with udev
Last modified: 2007-11-30 17:07:20 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.7.10) Gecko/20050717 Firefox/1.0.6
Description of problem:
Same as happen in FC4:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. put AVM B1 ISDN card into system
2. try to load firmware
Actual Results: # /sbin/avmcapictrl load /etc/firmware/isdn/b1.t4 1
Device file /dev/capi20 and /dev/isdn/capi20 missing, use instdev: No such file or directory
Expected Results: # /sbin/avmcapictrl load /etc/firmware/isdn/b1.t4 1
Loading Bootcode /etc/firmware/isdn/b1.t4 ... done
With AVM PCI (Fritz!PCI v2) isdn card /dev/capi20 also missing.
I tried the udev fix as proposed in the FC4 bug report
still have issues:
1. using the 'standard' capiinit (from isdn4k-utils package) doesn't work even
with the fix - no /dev/capi20 and /dev/capi/* device nodes are created.
2. I compiled capi4k-utils-2005.07.18 which provides a newer capiinit (and some
other utilities). With it the first time I run 'capiinit' it fails, but a couple
of seconds later the /dev/capi20 and /dev/capi/* device nodes are created. If I
run 'capiinit' once more, it starts fine.
Your second point looks like to me as the usual udev problem after loading a
module (e.g. by a trigger). udev need some time to create the device node
(sometimes up to 20 seconds). So one have to debug which code in capiinit
triggers loading of module. Here it has to wait some time until the device node
is created successfully by udev.
This issue is on Red Hat Engineering's list of planned work items
for the upcoming Red Hat Enterprise Linux 4.4 release. Engineering
resources have been assigned and barring unforeseen circumstances, Red
Hat intends to include this item in the 4.4 release.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
It turns out that the rules that were added to fix this are not restrictive
enough. They make no distinction between block and character devices.
Unfortunately, I don't have one of these devices, so it's tough for me to
suggest a new rule to fix it.
Would someone with one of these cards be kind enough to run:
udevinfo -q all -n /dev/capi20
udevinfo -q all -n /dev/capi/0
and post the output here?
I have still not updated the selinux policy, but here the output as requested:
# udevinfo -q all -n /dev/capi20
# udevinfo -q all -n /dev/capi/0