Red Hat Bugzilla – Bug 125760
kudzu causes kernel panic with kernel 2.6.6
Last modified: 2014-03-16 22:46:07 EDT
Description of problem:
I need to run with the NVIDIA accelerated video driver and I
needed IEEE1694 support for external drives, so I installed a stock
2.6.6 kernel on my system. Everything appears to run fine except for
kudzu. I can boot the system if I disable kudzu with "chkconfig kudzu off"
Then if I run kudzu manually with "service kudzu start" I get a kernel
panic. On the console the last few lines are:
Code: Bad EIP value.
<0>Kernel panick: Fatal exception in interrupr
In interrupt handler - not syncing
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot under 2.6.6 kernel with kudzu disabled
2. In virtual console start up kudzu with "service kudzu start"
3. machine hangs with EIP error message
I have since solved my problem by importing the configuration file from
one of the kernel configuration file from one of the Fedora kernels. I am
not sure which build options are necessary for kudzu to operate correctly, but
they appear to be set in the new version of the kernel that I created.
My new version of the kernel works with the NVIDIA driver, and my firewire
drive. I saw some mention that the ieee1394 support was not entirely stable,
and that was why it was not included in the stock kernel. Do you know
whether the problem has been fixed in the 2.6.6 version of the kernel?
I had this problem on my machine as well -- same scenario, same
kernel, same oops, same work around. I needed 2.6.6 for a fix to the
b44 network driver which doesn't work in the stock FC2 kernel.
I am able to confirm, also, that removing the OHCI-1394 driver from my
kernel config/build prevents the kernel panic generated by running kudzu.
When kudzu was causing the panics, I had OHCI-1394 compiled as a
module (I do have an OHCI-1394 supported device which worked correctly
in FC1). Full config available upon request.
Is there any way to coerce kudzu into giving more output as to what it
is doing? I suspect this is a kernel issue and want to get the steps
to reproduce using modutils. The man page doesn't indicate a debug or
1394 should be fairly stable as of the -435 kernel in the errata. The
original kernel had 1394 disabled because it crashed the machine if
you loaded it (as you now know in detail).
You can strace kudzu if you want to see what its up to. Since module
loads are often triggered indirectly via hotplug its actually the most