Distribution: SuSE 9.0 64-bit (x86_64) Hardware Environment: 2 x AMD Opteron 240, Tyan Thunder K8W, 1 GB RAM (4 x 256, two nodes, dual-channel), LSI 53C1010 64-bit SCSI + 2 x HDD (IBM), NEC-based USB 2.0 adapter (Manhattan), GeForce FX5200 (LeadTek), 2 x SATA HDD (Seagate, Samsung), IDE DVD (Liteon), IDE DVDR (Liteon) Software Environment: SuSE 9.0 (downloadable version) + KDE 3.2 (from kde.org) + kernel 2.6.4-rc1-bk3 (2.6.3-rc1-mm1) Problem Description: There are some unknown symbols in the ohci1394 and ieee1394 modules which prevents the kernel from loading them. Here's the dmesg output: ieee1394: Unknown symbol kernel_locked ohci1394: Unknown symbol hpsb_iso_wake ohci1394: Unknown symbol hpsb_packet_received ohci1394: Unknown symbol dma_prog_region_free ohci1394: Unknown symbol hpsb_add_host ohci1394: Unknown symbol dma_prog_region_init ohci1394: Unknown symbol dma_prog_region_alloc ohci1394: Unknown symbol dma_region_offset_to_bus ohci1394: Unknown symbol hpsb_alloc_host ohci1394: Unknown symbol hpsb_selfid_complete ohci1394: Unknown symbol hpsb_remove_host ohci1394: Unknown symbol hpsb_iso_packet_received ohci1394: Unknown symbol hpsb_iso_packet_sent ohci1394: Unknown symbol hpsb_packet_sent ohci1394: Unknown symbol dma_region_sync ohci1394: Unknown symbol hpsb_selfid_received ohci1394: Unknown symbol hpsb_bus_reset Steps to reproduce: Try "modprobe ohci1394"
I meant the kernel 2.6.4-rc1-mm1 (not the 2.6.3-rc1-mm1) in the software environment part. BTW, the problem apeared there for the first time, AFAIR.
Could you provide your .config?
Created attachment 2304 [details] Kernel config for Linux-2.6.4-rc2-bk3 The .config is attached. Seemingly, the problem is that one of the macros in the line 126 of drivers/ieee1394/ieee1394_core.c (GFP_ATOMIC or GFP_KERNEL) produces a call to kernel_locked() which apparently is not defined. This is what the gcc says when I compile the whole thing in (ie. CONFIG_IEEE1394=y): CC drivers/ieee1394/ieee1394_core.o drivers/ieee1394/ieee1394_core.c: In function `hpsb_alloc_packet': drivers/ieee1394/ieee1394_core.c:126: warning: implicit declaration of function `kernel_locked' It seems to me that this may be architecture-related (ie. x86-64 may be to blame).
Sorry, GFP_ATOMIC and GFP_KERNEL are ok, but in_atomic() is defined like that: # define in_atomic() ((preempt_count() & ~PREEMPT_ACTIVE) != kernel_locked()) in include/asm-x86_64/hardirq.h if CONFIG_PREEMPT is set
I can confirm that the problem is architecture-related, because it does not occur on i386 (x86_64 is to blame, apparently). FYI, the kernel-2.6.4 is also affected.
Created attachment 2316 [details] A patch to fix the problem I was wrong before: it seems that the problem is not related to the architecture, but to SMP (or a lack thereof). Attached is a patch that fixes this on my system(s).
It's the fault of the driver if it doesn't include the right includes.
Actually, shouldn't include/asm-x86_64/hardirq.h include smp_lock.h, since it is the actual user of the problem bit of code?
No, IEEE1394 is using in_atomic(), which is it includes properly. However x86_64's definition of the macro uses another macro that is defined elsewhere. That header should be the one bringing in the includes it needs to complete the definition. This is a bug in include/asm-x86_64/hardirq.h, IMO.
I just tried and I cannot reproduce any compile errors on 2.6.4 with modular ieee1394
Regarding Comment #10: There are not any, AFAIR. Please try to compile the driver into the kernel. And i think you have to enable SMP to see any problems. Regarding Comment #9: IMO this is a matter of what drivers generally do with the smp_lock.h, and as far as I can see, they include it wherever necessary. Of course, you can require that some other header should include it, but this is not what is generally done. That's why I proposed the above patch.
Of course it's appropriate for a header to include what it needs to completely define the values it is exporting. If I include stdio.h in userspace, there's nothing else I need to include so long as I only use things that stdio.h exports. Most other architectures already include smp_lock.h in hardirq.h; sparc, sparc64, i386, mips, ppc and ia64. The use of kernel_locked() in hardirq.h is specifically why they do it. This bug really needs to be fixed where it should be.
I would change it, but I cannot reproduce the failure. Even with SMP on and IEEE all compiled in things compile just fine here.
Created attachment 2318 [details] Kernel config for Linux-2.6.4 Regarding Comment #13: Here's what I do: (1) get linux-2.6.4.tar.bz2 from kernel.org, (2) untar it, (3) copy the kernel config that is attached to "linux-2.6.4/.config", (4) "make xconfig" (no changes, Save, Quit), (6) make Here's what I get: CC drivers/ieee1394/ieee1394_core.o drivers/ieee1394/ieee1394_core.c: In function `hpsb_alloc_packet': drivers/ieee1394/ieee1394_core.c:126: warning: implicit declaration of function `kernel_locked' CC drivers/ieee1394/ieee1394_transactions.o and finally: LD .tmp_vmlinux1 drivers/built-in.o(.text+0x891f8): In function `hpsb_alloc_packet': : undefined reference to `kernel_locked' make: *** [.tmp_vmlinux1] Error 1 When I compile the ieee1394 as a module, I get the following after "make modules_install": if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.6.4; fi WARNING: /lib/modules/2.6.4/kernel/drivers/ieee1394/ieee1394.ko needs unknown symbol kernel_locked Sorry, but I can't help it unless I patch the kernel. My gcc is 3.3.1 out of SuSE 9.0 (gcc-3.3.1-23)
Created attachment 2352 [details] Another patch (may be better :-)) Well, I think I have a more acceptable patch (attached). It makes asm-x86_64/hardirq.h include linux/smp_lock.h. Unfortunately it requires a patch to drivers/char/rtc.c, but this is analogous to what is done for i386. The patch is against linux-2.6.5-rc1 but it applies cleanly to linux-2.6.5-rc1-mm1 as well.
Can you test compile it with the various possibilities? (make allyesconfig with PREEMPT+UP, PREEMPT+SMP, SMP, UP each) If it passes I will apply it.
Regarding Comment #16: It looks like it does. I've done all of them and it compiles each time (I've only had to unset CONFIG_PM_DISK and CONFIG_WANXL_BUILD_FIRMWARE, because the first one does not compile without the patch either and the second requires as68k which I have no idea where to get from).