From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: My /dev contains parport0, parport1, parport2, and parport3. I have no parallel ports enabled on the system. Why are these entries there? Also why do I have 76 serial ports listed? I have ttyS0 - ttyS75. My modem is at ttyS14 (which is strange in itself because it has always been ttyS4, but that is another bug). Shouldn't there only be a /dev/ttyS14? Version-Release number of selected component (if applicable): udev-039-10.FC3.6 How reproducible: Always Steps to Reproduce: 1. look at dev entries 2. 3. Actual Results: I see the extra entries Expected Results: Since I don't have any parallel ports enabled and only 1 serial port (ttyS14) there should not be any parport or extra ttyS entries Additional info:
The ttyS* are provided by the kernel and the parport devices are required, because the module is not loaded at boot time. Edit /sbin/start_udev to get rid of parport. Reassign the bug to component kernel, if you feel disturbed by the many serial device nodes.
Ok, let me try to understand this. Udev has to create the parport stuff because the parport module is not loaded at boot time? May I ask why it is not? Please correct me if I am wrong, but isn't the serial module loaded at boot time? I will reassign this to the kernel once I modify the start_udev file. I will open a second ticket for the extra serial devices.
Per the comment from Harald Hoyer I am reassigning this to the kernel group. Please load the parport module at boot time. Also why is there 76 serial devices in dev?
Can parport be loaded at boot time so udev can dynamically create the lp devices for FC4? Also why does the kernel have so many serial devices? At most I have 1 serial port and a modem. Granted other people have more serial devices, but still why can't the kernel give the correct number of serial devices to udev? Thanks,
Udev still creates unnecessary serial, lp, and parport entries in dev. I am now running FC4, udev-058-1, and kernel-2.6.12-1.1390. Udev creates 4 lp and parport entries in /dev when there is only 1 parallel port. Udev creates 76 ttyS* entries in dev when there is only 1 serial port. I looked in the /sbin/start_udev file to get rid of the parport entires, but I can't find the line that creates those entries. This is strage sense I was able to edit the file to remove the extra entries back in FC3.
Edit /etc/udev/makedev.d/50-udev.nodes to remove the manually created udev nodes.
[This comment has been added as a mass update for all FC4 kernel bugs. If you have migrated this bug from an FC3 bug today, ignore this comment.] Please retest your problem with todays 2.6.12-1.1398_FC4 update. If your problem involved being unable to boot, or some hardware not being detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE* installing any kernel updates. If in doubt, you can recreate this file using.. mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak mv /etc/modprobe.conf /etc/modprobe.conf.bak kudzu Thank you.
Udev still creates unnecessary serial, lp, and parport entries in dev. I am now running FC4, udev-058-1, and kernel-2.6.12-1.1398. Udev creates 4 lp and parport entries in /dev when there is only 1 parallel port. Udev creates 76 ttyS* entries in dev when there is only 1 serial port. Why are there 65 tty devices in /dev? Jason
Mass update to all FC4 bugs: An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream kernel (2.6.13.2). As there were ~3500 changes upstream between this and the previous kernel, it's possible your bug has been fixed already. Please retest with this update, and update this bug if necessary. Thanks.
I have emailed with Greg KH the creater of udev and says this is a redhat (fedora) problem. Greg says that udev can dynamically create the lp0 and parport0 nodes.
As for the terminal devices, these are provided by the kernel. To test if s.th. is created by udev because the kernel is offering the device: # udevinfo -q all -n /dev/<device node>
ok, not true for names which are not changed by udev. # ls /sys/class/tty/*/dev e.g. these terminals are all provided by the kernel and thus created by udev.
I current edit the /etc/udev/makedev.d/50-udev.nodes to remove the manually created udev nodes. I would like to know redhat still creates them manually when udev has to ability to do this. Isn't it redundant? I will post the results of the udevinfo command shortly. Why are there 65 terminals in the kernel? Please correct me if I am wrong but I thought there were only 7 terminals? 6 text and X?? Thanks, Jason
When I run udevinfo -q all -n /dev/ttyS0 I get "no record for 'ttyS0' in database". This happens for all 32 ttySX nodes. This is a little strange because I do have 1 serial port enabled on the system. Here is what dmesg says about the serial port: Serial: 8250/16550 driver $Revision: 1.90 $ 32 ports, IRQ sharing enabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Jason, as I said, there is only a record in the database, if the name has changes from the kernel one. The parport devices are created, because the parport module is not loaded by kudzu/rc.sysinit, so no devices will be created by udev, though the HW is present. If the parport module would be compiled in the kernel it would be no problem either. Reassign to kudzu/initscripts.
This should already be fixed in rawhide.
I am running udev-069-10 and kernel-2.6.13-1.1600_FC5. I have the parallel port enabled in the bios and udev does not create /dev/lp0 or /dev/parport0.
What's the output of 'kudzu -p -b isapnp'?
- class: OTHER bus: ISAPNP detached: 0 desc: "PNP0200" deviceId: PNP0200 - class: OTHER bus: ISAPNP detached: 0 desc: "PNP0303" deviceId: PNP0303 compat: PNP030b - class: OTHER bus: ISAPNP detached: 0 driver: parport_pc desc: "PNP0401" deviceId: PNP0401 - class: OTHER bus: ISAPNP detached: 0 desc: "PNP0700" deviceId: PNP0700 - class: OTHER bus: ISAPNP detached: 0 desc: "PNP0800" deviceId: PNP0800 - class: OTHER bus: ISAPNP detached: 0 desc: "PNP0b00" deviceId: PNP0b00 - class: OTHER bus: ISAPNP detached: 0 desc: "PNP0c01" deviceId: PNP0c01 - class: OTHER bus: ISAPNP detached: 0 desc: "PNP0c04" deviceId: PNP0c04
Given the: class: OTHER bus: ISAPNP detached: 0 driver: parport_pc desc: "PNP0401" deviceId: PNP0401 - entry, I'm somewhat confused as to why it *wouldn't* be loaded on startup. Is parport_pc loaded for you?
Ok here is the story so far. I opened a ticket awhile ago because udev was creating too many nodes in /dev (and it still does). That orignial ticket has sense been closed. Harald Hoyer told where to edit a udev file so udev would not create the un-necessary nodes. I asked why udev was not dynamically creating the nodes like it does for most of the other nodes. Harald Hoyer told me that the reason for udev not creating the nodes dynamically was that the parallel port module was not loading at boot time so I opened this ticket. This ticket has been bouncing from udev, kernel, and kuduz for sometime now. I talked with Greg KH, the creater of udev, and Greg says that udev can dynamically create the lp0 and parport0 nodes. I don't know why this ticket is being bounced all over the place. Here is the output from dmesg: parport: PnPBIOS parport detected. parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE] I am guessing that this means the kernel sees the parallel port, but somewhere somehow the /dev nodes for lp0 and parport0 are not be created dynamically. I don't know if this is a function for udev or kudzu. Does it make sense now? It feels like I have been rambeling on for awhile. If you have any other questions, please feel free to ask. Thanks, Jason
Does parport_pc show as loaded if you run 'lsmod'?
parport_pc 27909 0 parport 35465 1 parport_pc Yes. I guess it might be time to change the summary to something like udev does not dynamically create parport0 and lp0 nodes. What do you think? Thanks,
ok, sorry, then in case of the parport module, it was a missing "dev" file in /sys, which the kernel should provide. Oct 19 09:11:52 jever udevd[18982]: get_udevd_msg: udevd event message received Oct 19 09:11:52 jever udevd[18982]: main: skip uevent_helper message with SEQNUM, netlink is active Oct 19 09:11:52 jever udevd[18982]: msg_queue_insert: seq 699 queued, 'add' '/module/parport' Oct 19 09:11:52 jever udevd[18982]: udev_event_run: seq 699 forked, pid [19000], 'add' 'module', 0 seconds old Oct 19 09:11:52 jever udevd[18982]: msg_queue_insert: seq 700 queued, 'add' '/module/parport_pc' Oct 19 09:11:52 jever udevd[18982]: udev_event_run: seq 700 forked, pid [19002], 'add' 'module', 0 seconds old Oct 19 09:11:52 jever udevd[18982]: get_udevd_msg: udevd event message received Oct 19 09:11:52 jever udevd[18982]: main: skip uevent_helper message with SEQNUM, netlink is active Oct 19 09:11:52 jever udevd[18982]: udev_done: seq 700, pid [19002] exit, 0 seconds old Oct 19 09:11:52 jever udevd[18982]: msg_queue_insert: seq 701 queued, 'add' '/bus/pnp/drivers/parport_pc' Oct 19 09:11:52 jever udevd[18982]: udev_event_run: seq 701 forked, pid [19006], 'add' 'drivers', 0 seconds old Oct 19 09:11:52 jever udevd[18982]: get_udevd_msg: udevd event message received Oct 19 09:11:52 jever udevd[18982]: main: skip uevent_helper message with SEQNUM, netlink is active Oct 19 09:11:52 jever kernel: pnp: Device 00:08 activated. Oct 19 09:11:52 jever udevd[18982]: udev_done: seq 699, pid [19000] exit, 0 seconds old Oct 19 09:11:52 jever kernel: parport: PnPBIOS parport detected. Oct 19 09:11:52 jever udevd[18982]: udev_done: seq 701, pid [19006] exit, 0 seconds old Oct 19 09:11:52 jever kernel: parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE] Oct 19 09:11:52 jever udevd[18982]: msg_queue_insert: seq 702 queued, 'add' '/bus/pci/drivers/parport_pc' Oct 19 09:11:52 jever udevd[18982]: udev_event_run: seq 702 forked, pid [19008], 'add' 'drivers', 0 seconds old Oct 19 09:11:52 jever udevd[18982]: get_udevd_msg: udevd event message received Oct 19 09:11:52 jever udevd[18982]: main: skip uevent_helper message with SEQNUM, netlink is active Oct 19 09:11:52 jever udevd[18982]: udev_done: seq 702, pid [19008] exit, 0 seconds old No hotplug message from the kernel appears and no /sys "dev" file is offered.
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
I am running rawhide now and the problem still remains in 2.6.14-1.1657_FC5.
Created attachment 122689 [details] patch to add sysfs and udev to parport
can you send this upstream to linux-kernel.org please ? Fedora will pick it up in rawhide the day its merged there.
I have already sent the patch to linux-kernel.org. Andrew Morton has already asked me to send him my patch as the first one was wordwrapped. As soon as this patch is in the kernel, fedora's rawhide udev will have to modified to remove the lp0, lp1, lp2, lp3, parport0, parport1, parport2, and parport3 from /etc/udev/makedev.d/50-udev.nodes. 50-udev-rules will have to remove the lp and parport symbolic link stuff. Should I open another bugzilla for this? Should I wait until the patch is merged?
once it's merged, and there's a rawhide kernel based on it, just reassign this bug back to a udev bug. It's all the same issue, and it can't be done in parallel (no pun intended), so we may as well keep it one place.
After some feedback from the linux-kernel mailing list the problem might not be the kernel after all. As it was explained to me the lp module is what should create the lp node in /dev. So there appears to be two problems 1)Fedora udev creates the lp and parport nodes from /etc/udev/makedev.d/50-udev.nodes. I am told this needs to be stopped and let udev do it the right way. 2)The lp module needs to be loaded so the lp node gets created and /usr/bin/printconf-gui can then successfully probe the port to create the queue. What do you think?
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
(this is a mass-close to kernel bugs in NEEDINFO state) As indicated previously there has been no update on the progress of this bug therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue still occurs for you and I will try to assist in its resolution. Thank you for taking the time to report the initial bug. If you believe that this bug was closed in error, please feel free to reopen this bug.