Results of various tests with MVME167
On Mon, 2004-09-06 at 20:06, Kars de Jong wrote:
> I hope to be able to test the SCSI driver and this driver tomorrow.
And I did, with mixed results.
First, I built a kernel (CVS-current with my patches) based on the a
config from the kernel-image-2.6.8-mvme16x_2.6.8-1_m68k.deb from
Christian.
Serial console worked OK, the SCSI driver dumped an error and then
caused a kernel panic (looks like it was treating something as a pointer
which it really wasn't):
------------------------------------------------------------------------
scsi-ncr53c7xx : NCR53c710 at memory 0xfff47000, io 0x0, irq 85
scsi0: Revision 0x1
scsi0 : NCR code relocated to 0xf1e5cc (virt 0x00f1e5cc)
scsi0 : test 1 started
scsi0 : MVME16x NCR53c710 SCSI
Using anticipatory io scheduler
scsi0 : invalid instruction
scsi0 : DCMD|DBC=0xc0000004, DNAD=0xf1f184 (virt 0x00f1f184)
DSA=0x0 (virt 0x00000000)
DSPS=0xf1f184, TEMP=0x33 (virt 0x00000033), DMODE=0xe0
SXFER=0x0, SCNTL3=0x0
phase=DATAOUT, 0 bytes in SCSI FIFO
SCRATCH=0x0, saved2_dsa=0x0
scsi0 : DSP 0xf1f188 (virt 0x00f1f188) ->
0xf1f188 (+2ef) : 0xc0000004 0x00f1f184 0x00000033
0xf1f194 (+2f2) : 0xc0000004 0x00000033 0x00f1e5b0
0xf1f1a0 (+2f5) : 0xc0000004 0x00f1e13c 0x00000033
0xf1f1ac (+2f8) : 0x72370000 0x00000000
0xf1f1b4 (+2fa) : 0x6a0b0000 0x00000000
0xf1f1bc (+2fc) : 0xc0000004 0x00f1e5b0 0x0000000f
scsi0 : issue queue
scsi0 : schedule dsa array :
scsi0 : dsa at phys 0xf1f188 (virt 0x00f1f188)
+ 64 : dsa_msgout length = 2282225664, data = 0xf1e7c4 (virt 0x00f1e7c4)
^^^^^^^^^^
that's a really big SCSI message!
+ 60 : select_indirect = 0xf
+ 56 : dsa_cmnd = 0xf1e5b0 <1>Unable to handle kernel NULL pointer dereference at virtual address 0000003c
Oops: 00000000
Modules linked in:
PC: [<000dfbb0>] print_dsa+0x112/0x26c
SR: 2700 SP: 00fd3bdc a2: 00fcf860
d0: 00000023 d1: 00000971 d2: 0000000a d3: 00000018
d4: 00f00a84 d5: 00000033 a0: 00000000 a1: 00174450
Process swapper (pid: 1, stackpage=00fd0860)
Stack from 00fd3bdc:
00000971 0000000a 00000018 00f00a84 00000033 00000000 00174450 00fcf860
00000023 ffffffff 00000000 2700000d fbb07008 00fd3c20 05050005 00050005
0000003c 00174450 00000001 00026328 00f1e5b0 00f1f188 000dfba2 0015f9af
00000038 00f1e5b0 00000000 00000018 00f1e000 00f1fb80 00f00a84 00f1e000
00f00a84 000dfde4 00f00a84 00f1f188 0015dfde 00000000 28010c00 00f1e000
00000033 00f1f184 00026328 fff47000 00f1f1c8 000e01b8 00f00a84 00f1f188
Call Trace: [<00026328>] printk+0x0/0xfa
[<0015f2d9>] syncs+0xa3f/0x288f
[<000df126>] intr_dma+0x11a/0x35c
[<0015f49e>] syncs+0xc04/0x288f
[<000dea2a>] NCR53c7x0_intr+0x12c/0x27c
[<00002010>] rest_init+0x8/0x1c
[<00002404>] huft_build+0x284/0x3da
[<00002700>] inflate_codes+0x180/0x402
[<00009efe>] mvme16x_process_int+0x44/0x4e
[<000066ba>] process_int+0x4e/0x62
[<000052e4>] inthandler+0x2a/0x2c
[<00002010>] rest_init+0x8/0x1c
[<000d5b92>] scsi_request_fn+0x170/0x3a6
[<00002000>] _start+0x0/0x8
[<000c7f98>] blk_insert_request+0x4a/0x9e
[<000d4c70>] scsi_insert_special_req+0x28/0x30
[<000d4d70>] scsi_do_req+0x64/0x6c
[<000d4e28>] scsi_wait_req+0x62/0x9e
[<000d4d78>] scsi_wait_done+0x0/0x4e
[<000d6964>] scsi_probe_lun+0xce/0x3a6
[<000d7014>] scsi_probe_and_add_lun+0xe0/0x1d2
[<000d7028>] scsi_probe_and_add_lun+0xf4/0x1d2
[<000d766c>] scsi_scan_target+0x58/0xbc
[<000d7726>] scsi_scan_channel+0x56/0x70
[<000d77ce>] scsi_scan_host_selected+0x8e/0xca
[<000d7822>] scsi_scan_host+0x18/0x1e
[<001d220a>] init_this_scsi_driver+0x60/0xaa
[<00026328>] printk+0x0/0xfa
[<001ca040>] do_initcalls+0x62/0xc8
[<00026328>] printk+0x0/0xfa
[<001ca0c2>] do_basic_setup+0x1c/0x1e
[<00002078>] init+0x1c/0xd2
[<00026328>] printk+0x0/0xfa
[<000055ae>] kernel_thread+0x3e/0x54
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
------------------------------------------------------------------------
So, I decided to take a kernel from daily d-i builds,
vmlinuz-2.4.27-mvme16x. Oddly enough, this kernel crashed with the same
error message...
But I did have a working 2.4.26 kernel which I built myself.
Then I tried vmlinuz-2.2.25-mvme16x. This did work fine.
So I built the 2.6.8.1 kernel based on my old config, and voila, it
worked fine...
Now it was time to find out which config option caused the problem...
Took me quite some recompile/reboot cycles, but it turned out to be
CONFIG_SINGLE_MEMORY_CHUNK. If this is NOT defined as "Y", the kernel
crashes. And this is apparently also true for 2.4.x (x > ??) kernels.
Seeing that the NCR53C710 bugs out with "illegal instruction" it would
almost have to be a virt <-> phys conversion issue.
Anyone else having problems with this?
Kind regards,
Kars.
Reply to: