Bug 167291
| Summary: | CAPI subsystem not working with udev | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Peter Bieringer <pb> |
| Component: | udev | Assignee: | Harald Hoyer <harald> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | CC: | axel.thimm, jlayton, laroche, ubeck |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | NdRvw | ||
| Fixed In Version: | RHBA-2006-0382 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-08-10 21:16:58 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 181409 | ||
|
Description
Peter Bieringer
2005-09-01 12:10:28 UTC
With AVM PCI (Fritz!PCI v2) isdn card /dev/capi20 also missing. I tried the udev fix as proposed in the FC4 bug report ([url=https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139321#c5]), but 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. D. 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. please test: ftp://people.redhat.com/harald/udev/039-10.14.EL4/ 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. http://rhn.redhat.com/errata/RHBA-2006-0382.html 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 P: /class/capi/capi N: capi20 T: c M: 020660 S: O: root G: root F: /etc/udev/rules.d/10-capi.rules L: 1 U: 38 R: 0 # udevinfo -q all -n /dev/capi/0 P: /class/tty/capi0 N: capi/0 T: c M: 020660 S: O: root G: root F: /etc/udev/rules.d/10-capi.rules L: 2 U: 38 R: 0 |