Bug 145148 - kernel creates no /sys entries for parports and lps
kernel creates no /sys entries for parports and lps
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
MassClosed
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-14 15:18 EST by Jason
Modified: 2015-01-04 17:15 EST (History)
4 users (show)

See Also:
Fixed In Version: 1.2.9-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-19 23:40:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to add sysfs and udev to parport (1.96 KB, patch)
2006-01-02 10:17 EST, Jason
no flags Details | Diff

  None (edit)
Description Jason 2005-01-14 15:18:25 EST
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:
Comment 1 Harald Hoyer 2005-01-17 04:44:43 EST
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.
Comment 2 Jason 2005-01-17 14:35:06 EST
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.
Comment 3 Jason 2005-01-19 15:08:58 EST
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?  
Comment 4 Jason 2005-03-10 15:50:15 EST
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,
Comment 5 Jason 2005-07-12 17:08:36 EDT
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.
Comment 6 Harald Hoyer 2005-07-13 04:12:21 EDT
Edit /etc/udev/makedev.d/50-udev.nodes to remove the manually created udev nodes.
Comment 7 Dave Jones 2005-07-15 17:38:18 EDT
[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.
Comment 8 Jason 2005-07-18 10:23:35 EDT
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
Comment 9 Dave Jones 2005-09-30 03:00:29 EDT
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.
Comment 10 Jason 2005-10-05 10:06:47 EDT
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.
Comment 11 Harald Hoyer 2005-10-06 10:50:03 EDT
Edit /etc/udev/makedev.d/50-udev.nodes to remove the manually created udev nodes.
Comment 12 Harald Hoyer 2005-10-06 10:56:22 EDT
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>
Comment 13 Harald Hoyer 2005-10-06 11:09:42 EDT
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.
Comment 14 Jason 2005-10-06 11:41:00 EDT
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
Comment 15 Jason 2005-10-06 11:59:11 EDT
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
Comment 16 Harald Hoyer 2005-10-07 05:05:10 EDT
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.
Comment 17 Bill Nottingham 2005-10-07 12:32:34 EDT
This should already be fixed in rawhide.
Comment 18 Jason 2005-10-11 16:24:21 EDT
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.
Comment 19 Bill Nottingham 2005-10-17 16:08:54 EDT
What's the output of 'kudzu -p -b isapnp'?
Comment 20 Jason 2005-10-18 11:29:18 EDT
-
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
Comment 21 Bill Nottingham 2005-10-18 13:53:11 EDT
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?
Comment 22 Jason 2005-10-18 16:42:32 EDT
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
Comment 23 Bill Nottingham 2005-10-18 17:29:21 EDT
Does parport_pc show as loaded if you run 'lsmod'?
Comment 24 Jason 2005-10-18 19:36:42 EDT
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,
Comment 25 Harald Hoyer 2005-10-19 03:12:24 EDT
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.
Comment 26 Dave Jones 2005-11-10 15:05:32 EST
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.
Comment 27 Jason 2005-11-11 10:05:51 EST
I am running rawhide now and the problem still remains in 2.6.14-1.1657_FC5.
Comment 28 Jason 2006-01-02 10:17:32 EST
Created attachment 122689 [details]
patch to add sysfs and udev to parport
Comment 29 Dave Jones 2006-01-03 00:31:15 EST
can you send this upstream to linux-kernel@vger.kernel.org please ?
Fedora will pick it up in rawhide the day its merged there.
Comment 30 Jason 2006-01-03 10:23:27 EST
I have already sent the patch to linux-kernel@vger.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?
Comment 31 Dave Jones 2006-01-03 16:30:55 EST
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.
Comment 32 Jason 2006-01-04 21:27:52 EST
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?
Comment 33 Dave Jones 2006-10-16 15:08:56 EDT
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.
Comment 34 Jon Stanley 2008-01-19 23:40:48 EST
(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.

Note You need to log in before you can comment on or make changes to this bug.