Bug 5064 - Oops Unable to handle NULL pointer dereference/paging request in b1dma_release_appl
Oops Unable to handle NULL pointer dereference/paging request in b1dma_releas...
Status: REJECTED INSUFFICIENT_DATA
Product: Drivers
Classification: Unclassified
Component: ISDN
i386 Linux
: P2 normal
Assigned To: Karsten Keil
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-14 08:33 UTC by Carsten Menke
Modified: 2008-09-28 10:38 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.12.3,2.6.13-rc6
Tree: Mainline
Regression: ---


Attachments
.config 2.6.12.3 (41.59 KB, text/plain)
2005-08-14 08:34 UTC, Carsten Menke
Details
Oops 2.6.12.4-SMP,disabled Preemption (9.84 KB, text/plain)
2005-08-14 08:37 UTC, Carsten Menke
Details
Oops with 2.6.13-rc6-SMP and Preemption (2.26 KB, text/plain)
2005-08-14 08:39 UTC, Carsten Menke
Details
Working Configuration (36.74 KB, text/plain)
2005-09-08 15:24 UTC, Carsten Menke
Details

Description Carsten Menke 2005-08-14 08:33:27 UTC
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
Comment 1 Carsten Menke 2005-08-14 08:34:34 UTC
Created attachment 5633 [details]
.config 2.6.12.3

This is the intial config where I noticed the problem
Comment 2 Carsten Menke 2005-08-14 08:37:22 UTC
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
Comment 3 Carsten Menke 2005-08-14 08:39:37 UTC
Created attachment 5635 [details]
Oops with 2.6.13-rc6-SMP and Preemption
Comment 4 Adrian Bunk 2005-08-14 11:56:58 UTC
Please post the output of
  ./scripts/ver_linux
Comment 5 Carsten Menke 2005-08-14 12:27:26 UTC
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
Comment 6 Carsten Menke 2005-09-08 15:24:18 UTC
Created attachment 5938 [details]
Working Configuration

It seems that with this configuration I don't get Ooopses, just segmentation
faults in the program
Comment 7 Lionel Elie Mamane 2005-09-12 07:21:33 UTC
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()
Comment 8 Natalie Protasevich 2007-10-11 00:03:30 UTC
Any updates on this?
I still see the calls mentioned in #7 present in the code. Is suggestion in #7 reasonable?
Thanks.
Comment 9 Carsten Menke 2008-09-28 10:38:49 UTC
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.

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