oopses with sr0 in armel versatile image

[Oliver Grawert]

after a while of operation the versatile armel kernel spills out the following messages:

end_request: I/O error, dev sr0, sector 64
Buffer I/O error on device sr0, logical block 16
Buffer I/O error on device sr0, logical block 17
end_request: I/O error, dev sr0, sector 64
Buffer I/O error on device sr0, logical block 16
Buffer I/O error on device sr0, logical block 17
end_request: I/O error, dev sr0, sector 0
Buffer I/O error on device sr0, logical block 0
Buffer I/O error on device sr0, logical block 1
Buffer I/O error on device sr0, logical block 2
Buffer I/O error on device sr0, logical block 3
end_request: I/O error, dev sr0, sector 0
Buffer I/O error on device sr0, logical block 0
Buffer I/O error on device sr0, logical block 1
end_request: I/O error, dev sr0, sector 0
end_request: I/O error, dev sr0, sector 0

shortly after that i see a kernel oops like below:

lsi_scsi: error: Reselect with pending DMA
Unable to handle kernel NULL pointer dereference at virtual address 00000358

pgd = c0004000
[00000358] *pgd=00000000
Internal error: Oops: 17 [#1]
Modules linked in:
CPU: 0 Not tainted (2.6.28 #1)
PC is at sym_interrupt+0x97c/0x18ec
LR is at sym53c8xx_intr+0x48/0x78
pc : [<c01b7534>] lr : [<c01b2278>] psr: 80000113
sp : c0337db8 ip : d08da000 fp : c0337e24
r10: cf930c00 r9 : 0000ffff r8 : 00000001
r7 : ffd00084 r6 : 00000000 r5 : ffd00000 r4 : 0000000b
r3 : 0000000a r2 : ffd00000 r1 : 00000000 r0 : d08da00c
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 00093177 Table: 0c328000 DAC: 00000017
Process swapper (pid: 0, stack limit = 0xc0336268)
Stack: (0xc0337db8 to 0xc0338000)
7da0: c0337ddc c0337dc8
7dc0: c006a75c c0033854 00000004 c0337f38 c0337df4 c0337de0 cf80e800 c004b238
7de0: ffffffff f1140000 00000000 c0337df8 c0029a74 c002900c ffd00000 cf930c00
7e00: 00000000 00000000 0000001b c0352768 00000000 0000000a c0337e3c c0337e28
7e20: c01b2278 c01b6bc4 50001238 cf9bde40 c0337e5c c0337e40 c00690e0 c01b223c
7e40: c033f3b0 0000001b 00000001 00000012 c0337e74 c0337e60 c006a710 c00690a8
7e60: 0000001b c0337f38 c0337e8c c0337e78 c0029064 c006a688 ffffffff f1140000
7e80: c0337f0c c0337e90 c0029a74 c002900c 0000001b c0336000 c0357800 20000113
7ea0: 0000001b 00000000 c0336000 00000012 c0352768 00000000 0000000a c0337f0c
7ec0: c0337f10 c0337ed8 c004b270 c004b164 20000113 ffffffff c0337f04 c033f3b0
7ee0: 0000001b 0000001b 00000000 00000001 c002b41c c0352768 41069265 00022820
7f00: c0337f1c c0337f10 c004b270 c004b128 c0337f34 c0337f20 c0029068 c004b238
7f20: ffffffff f1140000 c0337f8c c0337f38 c0029a74 c002900c 00000000 00093177
7f40: 00092177 60000013 c002b41c c0336000 c0339f34 c002b41c c0352768 41069265
7f60: 00022820 c0337f8c 600000d3 c0337f80 c002b460 c002b46c 60000013 ffffffff
7f80: c0337fb4 c0337f90 c002b3f0 c002b428 c0352308 c035a2cc c0352308 c0025320
7fa0: c0339dc8 00022854 c0337fc4 c0337fb8 c028bf8c c002b3ac c0337ff4 c0337fc8
7fc0: c0008b30 c028bf44 c0008604 00000000 00000000 c0025320 00000000 00093175
7fe0: c03527cc c0025724 00000000 c0337ff8 00008034 c00088b8 00000000 00000000
Backtrace:
[<c01b6bb8>] (sym_interrupt+0x0/0x18ec) from [<c01b2278>]
(sym53c8xx_intr+0x48/0x78)
[<c01b2230>] (sym53c8xx_intr+0x0/0x78) from [<c00690e0>]
(handle_IRQ_event+0x44/0x84)
r4:cf9bde40
[<c006909c>] (handle_IRQ_event+0x0/0x84) from [<c006a710>]
(handle_level_irq+0x94/0xec)
r7:00000012 r6:00000001 r5:0000001b r4:c033f3b0
[<c006a67c>] (handle_level_irq+0x0/0xec) from [<c0029064>]
(__exception_text_start+0x64/0x84)
r5:c0337f38 r4:0000001b
[<c0029000>] (__exception_text_start+0x0/0x84) from [<c0029a74>]
(__irq_svc+0x34/0xa0)
Exception stack(0xc0337e90 to 0xc0337ed8)
7e80: 0000001b c0336000 c0357800 20000113
7ea0: 0000001b 00000000 c0336000 00000012 c0352768 00000000 0000000a c0337f0c
7ec0: c0337f10 c0337ed8 c004b270 c004b164 20000113 ffffffff
r5:f1140000 r4:ffffffff
[<c004b11c>] (__do_softirq+0x0/0x110) from [<c004b270>] (irq_exit+0x44/0x4c)
[<c004b22c>] (irq_exit+0x0/0x4c) from [<c0029068>]
(__exception_text_start+0x68/0x84)
[<c0029000>] (__exception_text_start+0x0/0x84) from [<c0029a74>]
(__irq_svc+0x34/0xa0)
Exception stack(0xc0337f38 to 0xc0337f80)
7f20: 00000000 00093177
7f40: 00092177 60000013 c002b41c c0336000 c0339f34 c002b41c c0352768 41069265
7f60: 00022820 c0337f8c 600000d3 c0337f80 c002b460 c002b46c 60000013 ffffffff
r5:f1140000 r4:ffffffff
[<c002b41c>] (default_idle+0x0/0x58) from [<c002b3f0>] (cpu_idle+0x50/0x7c)
[<c002b3a0>] (cpu_idle+0x0/0x7c) from [<c028bf8c>] (rest_init+0x54/0x68)
r8:00022854 r7:c0339dc8 r6:c0025320 r5:c0352308 r4:c035a2cc
[<c028bf38>] (rest_init+0x0/0x68) from [<c0008b30>] (start_kernel+0x284/0x2ec)
[<c00088ac>] (start_kernel+0x0/0x2ec) from [<00008034>] (0x8034)
r6:c0025724 r5:c03527cc r4:00093175
Code: e1a01000 e5932000 e59f056c ea000017 (e5963358)

disabling the CONFIG_BLK_DEV_SR option in the kernel config and recompiling the kernel seems to make this oops go away.

[Oliver Grawert (ogra)]

this was partially fixed since the -7 upload of the linux package by making CONFIG_BLK_DEV_SR a module, though now loading the module produces the oops, i think we should disable it completely for that flavour

[Amit Kucheria (amitk)]

CONFIG_BLK_DEV_SR is now a module. So the 'problem' is bypassed.

Loading the module causes the oops though. So the real fix would be to track the source of the oops instead of completely disabling SR.