Bug 430942

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 "?".

This issue also exists on RHEL 5 GA as well as RHEL 5.1.

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.

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.

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.

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.

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.

module-init-tools-3_3-0_pre3_1_45_el5

These symbols still exist on a variety of platforms, possibly AMD only.

Jon,

Any chance we can get this fixed for 5.5 now?  I mean how many times do we have to delay this.

Created attachment 378133 [details]
A sysV based file locking scheme for read-only filesystems

Created attachment 378163 [details]
add sysv locking

Created attachment 378438 [details]
add sysv locking

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.

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