Distribution: Debian 3.1 Sarge Hardware Environment: Dell Power Edge 1800, Single Xeon 2.8 Ghz, AVM B1 PCI 4.0 Software Environment: Mail and Fax Gateway (or at least it should have been) Problem Description: Oops when using c2faxsend -d "faxnumber" -v -f TIFF /path/to/tiffile.tif Steps to reproduce: Always reproducible (but getting different stacks depending on kernel configuration) when doing c2faxsend -d "numbertodial" -v -f TIFF Enabling Preemption and SMP I get the following stack trace on 2.6.12.3 capi: appl 3 ncci 0x10101 forced down kcapi: appl 3 ncci 0x10101 down Unable to handle kernel paging request at virtual address 00100104 printing eip: e09b4e12 *pde = 00000000 Oops: 0002 [#1] PREEMPT SMP Modules linked in: ipv6 b1pci b1dma b1 n_hdlc tun capi capifs kernelcapi evdev pcspkr parport_pc parport psmouse genrtc e1000 ide_cd cdrom ide_disk ide_generic pdc202xx_new aec62xx alim15x3 amd74xx atiixp cmd64x cs5520 cs5530 cy82c693 generic hpt34x ns87415 opti621 pdc202xx_old rz1000 sc1200 serverworks siimage sis5513 slc90e66 triflex trm290 via82cxxx floppy usb_storage piix ide_core fbcon font bitblit vga16fb usbhid usbkbd ehci_hcd uhci_hcd thermal processor fan unix CPU: 1 EIP: 0060:[<e09b4e12>] Not tainted VLI EFLAGS: 00010292 (2.6.12.3) EIP is at capilib_release_appl+0x52/0x70 [kernelcapi] eax: 00100100 ebx: d914c080 ecx: c03c5a94 edx: 00200200 esi: dec8ee4c edi: dec8ee4c ebp: 00000003 esp: d4ddbdb4 ds: 007b es: 007b ss: 0068 Process c2faxsend (pid: 5499, threadinfo=d4dda000 task=d4871a60) Stack: e09b7960 00000003 00010101 dec8ecc8 00000003 decc6000 de8f2968 e0c6bb29 dec8ee4c 00000003 000000e2 dec8ecc8 d6c03288 dff85300 e09b20ba dec8ecc8 00000003 00000000 e09b2d00 dec8ecc8 00000003 d6c03280 00000000 e0949653 Call Trace: [<e0c6bb29>] b1dma_release_appl+0x29/0xe0 [b1dma] [<e09b20ba>] release_appl+0x1a/0x70 [kernelcapi] [<e09b2d00>] capi20_release+0xc0/0xd0 [kernelcapi] [<e0949653>] capidev_free+0x93/0xa0 [capi] [<e094a739>] capi_release+0x19/0x30 [capi] [<c015fbaa>] __fput+0x12a/0x140 [<c015e109>] filp_close+0x59/0x90 [<c011fcf4>] put_files_struct+0x64/0xd0 [<c0120a2e>] do_exit+0xee/0x380 [<c0120d40>] do_group_exit+0x40/0xb0 [<c012a7f3>] get_signal_to_deliver+0x233/0x340 [<c01031ab>] do_signal+0x9b/0x130 [<c0117ba8>] wake_up_state+0x18/0x20 [<c0128b9e>] signal_wake_up+0x2e/0x50 [<c0129201>] force_sig_info+0x71/0xb0 [<c0129b40>] force_sig+0x20/0x30 [<c0105000>] do_general_protection+0x90/0x1c0 [<c023d182>] copy_to_user+0x42/0x60 [<c012294c>] sys_gettimeofday+0x3c/0x90 [<c0104f70>] do_general_protection+0x0/0x1c0 [<c0103277>] do_notify_resume+0x37/0x3c [<c0103436>] work_notifysig+0x13/0x15 Code: f3 39 fb 8b 36 75 f2 83 c4 0c 5b 5e 5f 5d c3 8b 43 0c 89 6c 24 04 c7 04 24 60 79 9b e0 89 44 24 08 e8 63 95 76 df 8b 53 04 8b 03 <89> 50 04 89 02 c7 43 04 00 02 20 00 c7 03 00 01 10 00 89 1c 24
Created attachment 5633 [details] .config 2.6.12.3 This is the intial config where I noticed the problem
Created attachment 5634 [details] Oops 2.6.12.4-SMP,disabled Preemption This is the stack trace using 2.6.12.4 with Preemption disabled, this results in a lot of lines and a got a final panic when I tried to make menuconfig to compile a new kernel
Created attachment 5635 [details] Oops with 2.6.13-rc6-SMP and Preemption
Please post the output of ./scripts/ver_linux
Output of ./scripts/ver_linux Gnu C 3.3.5 Gnu make 3.80 binutils 2.15 util-linux 2.12p mount 2.12p module-init-tools 3.2-pre1 e2fsprogs 1.37 reiserfsprogs line reiser4progs line xfsprogs 2.6.20 PPP 2.4.3 isdn4k-utils 3.6 nfs-utils 1.0.6 Linux C Library 2.3.2 Dynamic linker (ldd) 2.3.2 Procps 3.2.1 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.2.1
Created attachment 5938 [details] Working Configuration It seems that with this configuration I don't get Ooopses, just segmentation faults in the program
I forward here a comment from Sven Schmidt, the product manager at AVM in charge of Linux related things. He says: this problem has another origin. While reconstructing kernel 2.6. the call of "capilib_release_appl()" was build into the "...._release_appl" function of the active controllers (b1dma_release_appl(), b1_release_appl() and c4_release_appl()). The function "capilib_release_appl()" is executed in the response function of the controller. At this point the call is not only unnecessary, moreover it is dangerous since the calls of capilib.c are not secured against interrupt breaks. In short: Delete Calls to capilib_release_appl() in: drivers/isdn/harware/avm/b1.c:b1_release_appl() drivers/isdn/harware/avm/b1dma.c:b1dma_release_appl() drivers/isdn/harware/avm/c4.c:c4_release_appl()
Any updates on this? I still see the calls mentioned in #7 present in the code. Is suggestion in #7 reasonable? Thanks.
This is what I really love, rejecting a bug report after 3 years being open with the reason insufficient data and not telling what data is needed.