Bug 261501 - [rhts] k8_edac fails to load
[rhts] k8_edac fails to load
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
x86_64 All
medium Severity low
: ---
: ---
Assigned To: Aristeu Rozanski
Red Hat Kernel QE team
Depends On:
Blocks: 533192
  Show dependency treegraph
Reported: 2007-08-28 15:16 EDT by Don Zickus
Modified: 2013-04-17 14:23 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-04-17 14:23:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
reproducer (771 bytes, text/x-sh)
2008-04-17 16:57 EDT, Aristeu Rozanski
no flags Details

  None (edit)
Description Don Zickus 2007-08-28 15:16:44 EDT
Description of problem:
While diff'ing the boot logs of a -43.el5 and a -44.el5, the following diff
showed up on v40z-01.rhts.boston.redhat.com

+k8_edac: Unknown symbol edac_mc_del_mc
+k8_edac: Unknown symbol edac_mc_find
+k8_edac: Unknown symbol edac_mc_add_mc
+k8_edac: Unknown symbol edac_mc_alloc
+k8_edac: Unknown symbol edac_mc_handle_ue_no_info
+k8_edac: Unknown symbol edac_mc_free
+k8_edac: Unknown symbol edac_mc_handle_ce
+k8_edac: Unknown symbol edac_mc_handle_ue
+k8_edac: Unknown symbol edac_mc_handle_ce_no_info

edac_mc seems to be loaded, so these warnings are unusual.

further info 
(click on tmp.uz3842 for boot log)

Version-Release number of selected component (if applicable):
using distro RHEL5.1-Server-20070822.1

How reproducible:
not sure

Steps to Reproduce:
1.boot -44.el5
Comment 1 Don Zickus 2007-08-28 15:26:06 EDT
adding Aris as he already started to look at it
Comment 2 Aristeu Rozanski 2007-08-28 15:29:53 EDT
EDAC MC: Ver: 2.0.1 Aug 27 2007
/* edac_mc gets loaded */

FDC 0 is a post-1991 82077
hdc: ATAPI 24X DVD-ROM drive, 256kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20

k8_edac: Unknown symbol edac_mc_del_mc
k8_edac: Unknown symbol edac_mc_find
k8_edac: Unknown symbol edac_mc_add_mc
k8_edac: Unknown symbol edac_mc_alloc
k8_edac: Unknown symbol edac_mc_handle_ue_no_info
k8_edac: Unknown symbol edac_mc_free
k8_edac: Unknown symbol edac_mc_handle_ce
k8_edac: Unknown symbol edac_mc_handle_ue
k8_edac: Unknown symbol edac_mc_handle_ce_no_info
/* k8_edac fails to load missing symbols present in edac_mc !? */

EDAC MC0: Giving out device to k8_edac Athlon64/Opteron: DEV 0000:00:18.2
EDAC MC1: Giving out device to k8_edac Athlon64/Opteron: DEV 0000:00:19.2
EDAC MC2: Giving out device to k8_edac Athlon64/Opteron: DEV 0000:00:1a.2
EDAC MC3: Giving out device to k8_edac Athlon64/Opteron: DEV 0000:00:1b.2
/* k8_edac loads, edac_mc is responsible by those messages */
Comment 3 Aristeu Rozanski 2007-09-10 15:43:35 EDT
Just to make an update on this bug:

Still no clue. Checked the module loading process and the module init function
(the one that will print "EDAC MC: Ver: 2.0.1 Aug 27 2007") only will be called
after making all the symbols available. I also ran a test (in the same machine and
the same version used by jburke) by 72h (by changing /etc/rc.local to keep
rebooting until find the messages or mail me if the problem is detected), couldn't
reproduce the problem. Will try to reproduce again.
Comment 4 Aristeu Rozanski 2007-11-12 15:51:43 EST
Oct 29 10:13:21 manus kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 4
ports, IRQ sharing enabled
Oct 29 10:13:21 manus kernel: 8250_pnp: Unknown symbol serial8250_unregister_port
Oct 29 10:13:21 manus kernel: 8250_pnp: Unknown symbol serial8250_register_port
Oct 29 10:13:21 manus kernel: 8250_pnp: Unknown symbol serial8250_unregister_port
Oct 29 10:13:21 manus kernel: 8250_pnp: Unknown symbol serial8250_register_port
Oct 29 10:13:21 manus kernel: ACPI: PCI Interrupt 0000:00:1f.5[B] -> GSI 17
(level, low) -> IRQ 17

it appears to be the same bug, only different modules
Comment 5 Jeff Burke 2007-11-12 16:20:55 EST
Adding Jon to the BZ. Perhaps he may have some ideas.

Comment 6 Jon Masters 2007-11-12 16:32:20 EST
There was a change upstream to the module loading code such that we might end up
calling modprobe before the required symbols have been made available - it's
being discussed on LKML at the moment, and Jan Glauber is debating this with
other folks. He's seeing funky stuff on s390x. I am going to look into this and
try to give an informed opinion - how urgent is it this week? Is this for 5.2 now?

Comment 7 Jon Masters 2007-11-15 03:12:15 EST

Jeff B. suggested that you might want to look into this. There's an upstream
patch from Rusty, which will dtrt., but it's currently broken (Jan has
confirmed), and Rusty is away for the next week. I am planning to look at this
at the weekend if there is some time to do so, but let me know if you want to
own this issue.

Comment 8 Jon Masters 2007-11-15 03:13:19 EST
Upstream thread has the subject:

"[PATCH] module loader should not complain about unknown symbol"

Comment 9 Aristeu Rozanski 2007-11-15 09:44:40 EST
Jon, I don't think I'll have time to work on this issue until next week, so feel
free to work on it on weekend. If you don't I'll resume the work next week. Anyway
I'll follow this thread.
Comment 13 Aristeu Rozanski 2008-04-17 16:56:15 EDT
Still triggers on 2.6.18-90.el5.
Attaching reproducer.
Comment 14 Aristeu Rozanski 2008-04-17 16:57:57 EDT
Created attachment 302808 [details]

edit the script replacing the edac module used on the current machine
Comment 15 Aristeu Rozanski 2008-05-12 10:23:31 EDT
the reproducer doesn't work. working on a new one.
Comment 16 RHEL Product and Program Management 2009-02-16 10:38:38 EST
Updating PM score.
Comment 24 Aristeu Rozanski 2013-02-05 14:15:28 EST
I'm pretty sure we fixed this a long time ago. Not sure why this bug is still
open. Don, you still see this happening?
Comment 25 Don Zickus 2013-02-05 14:57:09 EST
I haven't really looked, but feel free to close as someone else should have noticed it by now if it was still a problem.


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