2008-06-24 17:08:19 kernel oops when calling release on device
Kyle Schlansker (UNITED STATES)
Message: 57819
I'm developing a driver to read data over the SPORT0 interface and am running into a problem closing the character device.
Once my userspace app has finished reading the data it needs, and it calls 'close(fd)' which in turn invokes my driver's "i2s_release" function, I run into a kernel oops and can't for the life of me figure out what's going on.
I've completlely stripped out the body of my i2s_release function so that it only consists of a printk and return 0, yet I still run into the oops.
Below is the trace I get from the blackfin (BF537 stamp board). I'd appreciate any insight into possible causes. Thanks!
CPLB miss
- Used by the MMU to signal a CPLB miss on a data access.
Kernel OOPS in progress
Defered Exception context
CURRENT PROCESS:
COMM=datalogger_t PID=105
invalid mm
return address: [0x00025434]; contents of:
0x00025410: 1406 3006 6009 e302 b4e9 2fcf 3045 e3ff
0x00025420: b441 2fe3 63a7 2fe5 3208 0c41 1815 0000
0x00025430: 0000 0031 [e408] 0048 67f8 e608 0048 60f8
0x00025440: 0801 1807 e14a 0014 e10a 2578 9110 0040
SEQUENCER STATUS: Not tainted
SEQSTAT: 00000026 IPEND: 8030 SYSCFG: 0006
HWERRCAUSE: 0x0
EXCAUSE : 0x26
physical IVG15 asserted : <0xffa00ea8> { _evt_system_call + 0x0 }
logical irq 6 mapped : <0xffa00250> { _timer_interrupt + 0x0 }
logical irq 12 mapped : <0x03270550> { :ad1871_i2s:_i2s_open + 0x248 }
logical irq 18 mapped : <0x0008d758> { _bfin_serial_dma_rx_int + 0x0 }
logical irq 19 mapped : <0x0008d308> { _bfin_serial_dma_tx_int + 0x0 }
logical irq 24 mapped : <0x00096cc8> { _bf537mac_interrupt + 0x0 }
RETE: <0x00000000> /* Maybe null pointer? */
RETN: <0x03791e48> /* unknown address */
RETX: <0x00025434> { _module_put + 0xc }
RETS: <0x0003844c> { ___fput + 0x144 }
PC : <0x00025434> { _module_put + 0xc }
DCPLB_FAULT_ADDR: <0x0761b8a0> /* unknown address */
ICPLB_FAULT_ADDR: <0x00025434> { _module_put + 0xc }
PROCESSOR STATE:
R0 : 0761b780 R1 : 0000ffff R2 : 0000001f R3 : 2f71ff00
R4 : 00000000 R5 : 0000000c R6 : 00494590 R7 : 00000010
P0 : 001435d0 P1 : 0761b780 P2 : 00142578 P3 : 004915e0
P4 : 03531360 P5 : 004915e0 FP : 037f37a0 SP : 03791d6c
LB0: 032a157f LT0: 032a157e LC0: 00000000
LB1: 0007eaf0 LT1: 0007eae6 LC1: 00000000
B0 : 00000000 L0 : 00000000 M0 : 00000000 I0 : 00000010
B1 : 00000000 L1 : 00000000 M1 : 00000000 I1 : 00000000
B2 : 00000000 L2 : 00000000 M2 : 00000000 I2 : ffff078c
B3 : 00000000 L3 : 00000000 M3 : 00000000 I3 : 00000000
A0.w: 0000007f A0.x: 00000000 A1.w: 0000007f A1.x: 00000000
USP : 032a7ec8 ASTAT: 02003004
Hardware Trace:
0 Target : <0x0000483c> { _trap_c + 0x0 }
Source : <0xffa007ac> { _exception_to_level5 + 0xb4 }
1 Target : <0xffa006f8> { _exception_to_level5 + 0x0 }
Source : <0xffa00650> { _ex_trap_c + 0x68 }
2 Target : <0xffa00824> { _trap + 0x0 }
Source : <0xffa0057e> { _bfin_return_from_exception + 0x1a }
3 Target : <0xffa00824> { _trap + 0x0 }
Source : <0x00025432> { _module_put + 0xa }
4 Target : <0x00025428> { _module_put + 0x0 }
Source : <0x00039790> { _cdev_put + 0x1c }
5 Target : <0x00039788> { _cdev_put + 0x14 }
Source : <0x0007be3e> { _kref_put + 0x42 }
6 Target : <0x0007bdfc> { _kref_put + 0x0 }
Source : <0x0007b2a6> { _kobject_put + 0xe }
7 Target : <0x0007b298> { _kobject_put + 0x0 }
Source : <0x00039784> { _cdev_put + 0x10 }
8 Target : <0x00039774> { _cdev_put + 0x0 }
Source : <0x00038448> { ___fput + 0x140 }
9 Target : <0x00038440> { ___fput + 0x138 }
Source : <0x000383b0> { ___fput + 0xa8 }
10 Target : <0x000383a0> { ___fput + 0x98 }
Source : <0x0006dce0> { _dummy_file_free_security + 0x8 }
11 Target : <0x0006dcd8> { _dummy_file_free_security + 0x0 }
Source : <0x0003839e> { ___fput + 0x96 }
12 Target : <0x0003838e> { ___fput + 0x86 }
Source : <0x03270074> { :ad1871_i2s:_i2s_release + 0x24 }
13 Target : <0x0327006e> { :ad1871_i2s:_i2s_release + 0x1e }
Source : <0x0000d65e> { _printk + 0x16 }
14 Target : <0x0000d65a> { _printk + 0x12 }
Source : <0x0000d510> { _vprintk + 0x1b8 }
15 Target : <0x0000d504> { _vprintk + 0x1ac }
Source : <0xffa00d48> { __common_int_entry + 0xd8 }
Stack from 03791d4c:
00000000 ffa007b0 0014256c 0014256c 00142568 03531360 004d8cc9 00142578
00025434 00008030 00000026 00000000 03791e48 00025434 00025434 0003844c
0761b780 02003004 0007eaf0 032a157f 0007eae6 032a157e 00000000 00000000
0000007f 00000000 0000007f 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ffff078c 00000000 00000010 032a7ec8 037f37a0 004915e0 03531360
Call Trace:
[<0000ffff>] _do_exit+0x61f/0x760
[<00035e58>] _filp_close+0x38/0x60
[<00032ee8>] _exit_mmap+0x30/0x48
[<0000eb82>] _put_files_struct+0xce/0xd4
[<0000e7b6>] _exit_mm+0x5a/0xdc
[<0000fae6>] _do_exit+0x106/0x760
[<000101cc>] _sys_exit+0x0/0xc
[<00035e58>] _filp_close+0x38/0x60
[<0003805e>] _sys_write+0x32/0x64
[<000101d8>] _complete_and_exit+0x0/0x18
[<000101cc>] _sys_exit+0x0/0xc
[<0003802c>] _sys_write+0x0/0x64
[<00008000>] _l1sram_alloc+0x30/0x34
Modules linked in: ad1871_i2s
QuoteReplyEditDelete
2008-06-24 18:01:10 Re: kernel oops when calling release on device
Mike Frysinger (UNITED STATES)
Message: 57820
if things are crashing in kobject/cdev code like that, it usually means you didnt initialize the structures properly during module init
i would get rid of any i2s pieces completely and focus on the cdev parts
there is a kernel hacking option "kobject debugging", but i'm not sure it'll help you here
QuoteReplyEditDelete
2008-06-25 14:51:04 Re: kernel oops when calling release on device
Kyle Schlansker (UNITED STATES)
Message: 57872
Thanks for pointing me in the right direction. I rewrote my init function and it appeared to solve the issue.