Bug 430942 - [RHEL5 U2] Kernel-xen reports "Unknown symbols" during boot
[RHEL5 U2] Kernel-xen reports "Unknown symbols" during boot
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: module-init-tools (Show other bugs)
5.2
All Linux
medium Severity medium
: rc
: 5.5
Assigned To: Jon Masters
BaseOS QE
http://rhts.lab.boston.redhat.com/tes...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-30 13:52 EST by Jeff Burke
Modified: 2010-03-30 04:24 EDT (History)
9 users (show)

See Also:
Fixed In Version: module-init-tools-3.3-0.pre3.1.58.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-30 04:24:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
module-init fix to propagate the dependency errors up (1.69 KB, patch)
2008-10-01 16:51 EDT, Don Zickus
no flags Details | Diff
A sysV based file locking scheme for read-only filesystems (2.06 KB, text/plain)
2009-12-13 20:57 EST, Jon Masters
no flags Details
add sysv locking (4.27 KB, patch)
2009-12-14 02:44 EST, Jon Masters
no flags Details | Diff
add sysv locking (4.46 KB, application/octet-stream)
2009-12-15 01:45 EST, Jon Masters
no flags Details

  None (edit)
Description Jeff Burke 2008-01-30 13:52:55 EST
Description of problem:
 While booting the xen kernel it reports unknown sysmbols

Version-Release number of selected component (if applicable):
 2.6.18-76

How reproducible:
 Always
 
Actual results:
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
8250_pnp: Unknown symbol serial8250_unregister_port
8250_pnp: Unknown symbol serial8250_register_port
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
8250_pnp: Unknown symbol serial8250_unregister_port
8250_pnp: Unknown symbol serial8250_register_port

Expected results:
 We should not report unknown symbols during normal boot operations.

Additional info:
 I believe that this issue has been around for a while.
Comment 1 RHEL Product and Program Management 2008-02-01 17:37:57 EST
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 2 Bill Burns 2008-03-03 11:49:03 EST
This issue also exists on RHEL 5 GA as well as RHEL 5.1.
Comment 3 Don Dutile 2008-03-03 12:43:24 EST
The xen kernels have CONFIG_SERIAL_8250=m , while all the other kernels have
CONFIG_SERIAL_8250=y.
CONFIG_SERIAL_8250_PNP=m everywhere.

So, when 8250-PNP driver is loaded on non-xen kernels, the export exists in the
kernel already. and no complaints.
but, in xen kernels, 8250-PNP is not automagically loaded, so when 8250-pnp is
loaded, there's a symbol missing in the kernel.

Comment 4 Don Zickus 2008-03-19 17:08:15 EDT
So why isn't the 8250 driver automagically loaded?  Or on the flip side why is
the 8250-pnp loaded but not the 8250 (ie what is the magic udev event that
thinks the pnp driver should be loaded)?

This problem may have existed in RHEL-5 GA but it is still a potential support
issue that needs to be resolved, if not for 5.2 then 5.3.
Comment 5 Don Zickus 2008-03-20 16:10:40 EDT
Assigning this to Jon, as this seems like modprobe should behave differently.  

What is happening is the 8250 driver is being loaded as a dependency from the
8250_pnp/pci driver.  Because the HV is controlling the hardware, the 8250
driver fails to load.  This should immediately cause the 8250_pnp/pci drivers to
fail to install.  Instead it seems that modprobe continues to try and resolve
the 8250_pnp/pci symbols (which are not all there obviously) and we end up with
unknown symbols in dmesg.

Jon is going to talk to Rusty about the current modprobe behaviour and perhaps
add a flag to modprobe that we could stick in /etc/modprobe.conf to get the
behaviour we want.
Comment 6 RHEL Product and Program Management 2008-06-09 17:59:01 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 10 Don Zickus 2008-10-01 16:51:28 EDT
Created attachment 319164 [details]
module-init fix to propagate the dependency errors up

This is a silly and pathetic patch that demonstrates one way to fix the problem.  I only tested this on one box, so I have no idea what is the correct way to handle the failure cases, but it does work for this issue.

The gist of the patch is that once a dependency has failed, propagate the error up and stop loading all the modules that are dependent on the failed one.  This allows us to bail out quicker and not run into issues like 'Unknown symbols' because the parent modules are never asked to load.
Comment 13 Jon Masters 2009-04-28 14:03:50 EDT
module-init-tools-3_3-0_pre3_1_45_el5
Comment 15 Don Zickus 2009-07-13 14:20:04 EDT
These symbols still exist on a variety of platforms, possibly AMD only.
Comment 31 Don Zickus 2009-10-02 14:09:18 EDT
Jon,

Any chance we can get this fixed for 5.5 now?  I mean how many times do we have to delay this.
Comment 38 Jon Masters 2009-12-13 20:57:13 EST
Created attachment 378133 [details]
A sysV based file locking scheme for read-only filesystems
Comment 41 Jon Masters 2009-12-14 02:44:29 EST
Created attachment 378163 [details]
add sysv locking
Comment 44 Jon Masters 2009-12-15 01:45:17 EST
Created attachment 378438 [details]
add sysv locking
Comment 45 Jon Masters 2009-12-15 01:47:06 EST
With this updated patch, a new locking mechanism is introduced that is used on read-only filesystems in order to ensure that there is not a race between modprobe and another instance of the same. With this updated patch (updated to handle the unlikely case of also exceeding max open files), I can no longer reproduce this issue. Please test the latest build.

Jon.
Comment 53 errata-xmlrpc 2010-03-30 04:24:59 EDT
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 therefore 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-2010-0242.html

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