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: Call Trace: [<c012924d>] run_timer_softirq+0xcd/0x170 [<>] __do_softirq+oxab/0xb0 [<>] do_softirq+0x2d/0x30 [<>] smp_apic_timer_interrupt+0xe5/0x150 [<>] apic_timer_interrupt+0x1a/0xd0 [<>] default_idle+0x2a/0x40 [<>] cpu_idle+ox2d/0x40 [<>] start_kernel+0x199/0x1e0 Code: Bad EIP value. <0>Kernel panick: Fatal exception in interrupr In interrupt handler - not syncing Version-Release number of selected component (if applicable): kudzu-1.1.62-1 How reproducible: 100% 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 Actual results: Expected results: Additional info:
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 verbose option.
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 informative approach