5.2R: panic (syncer) on IBM x345 (SMP and Vinum)

[Matti Saarinen]

Don Lewis <truckman at FreeBSD.org> writes:

> You might try setting "camcontrol tags" down to 64 for each drive,
> since that is what it seems to be falling back to. I haven't used
> the IBM disks, only Seagate, and the one's that I've used seem to
> only support 64.

These IBM labelled disks are manufactured by Seagate and Fujitsu. The
tags parameters were different: 64 for Seagate disks and 128 for
Fujitsu disks. When I set the both values to 64 the error (or
informational?) messages from the ahd driver disappeared. 

The sad thing is that the system still crashes. The attached file
contains the logs from the latest crash and the trace from the kernel
debugger.

-------------- next part --------------
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 06
fault virtual address	= 0x0
fault code		= supervisor write, page not present
instruction pointer	= 0x8:0xc07bcafe
stack pointer	        = 0x10:0xe7b96784
frame pointer	        = 0x10:0xe7b967c0
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, def32 1, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 79 (syncer)
kernel: type 12 trap, code=0
Stopped at      generic_bcopy+0x1a:     repe movsl      (%esi),%es:(%edi)
db> trace
generic_bcopy(d7a09f58,0,d7a09f58,e7b967e4,c06590e1) at generic_bcopy+0x1a
vinumstrategy(d7a09f58,cafe9500,e7b9680c,c05da937,d7a09f58) at vinumstrategy+0xa6
dev_strategy(d7a09f58,0,360,1,c077dc95) at dev_strategy+0x41
spec_xstrategy(cb6dd924,d7a09f58,e7b96828,c05d9c38,e7b96854) at spec_xstrategy+0x1d7
spec_specstrategy(e7b96854,e7b96870,c07690bc,e7b96854,36c) at spec_specstrategy+0x1b
spec_vnoperate(e7b96854,36c,0,e7b9684c,d7a09f58) at spec_vnoperate+0x18
ufs_strategy(e7b96898,e7b968c8,c065502d,e7b96898,1) at ufs_strategy+0x10c
ufs_vnoperate(e7b96898,1,c082291c,360,246) at ufs_vnoperate+0x18
bwrite(d7a09f58,e7b9696c,c075c668,d7a09f58,0) at bwrite+0x44d
bawrite(d7a09f58,0,e7b969b8,2000,c70d6200) at bawrite+0x1c
ffs_write(e7b96998,d54000,0,dac000,0) at ffs_write+0x5f8
vnode_pager_generic_putpages(cd29c514,e7b96ad0,1000,c,e7b96a80) at vnode_pager_generic_putpages+0x223
vop_stdputpages(e7b96a38,e7b96a18,c0769e08,e7b96a38,e7b96a64) at vop_stdputpages+0x30
vop_defaultop(e7b96a38,e7b96a64,c0786bf9,e7b96a38,e7b96a34) at vop_defaultop+0x18
ufs_vnoperate(e7b96a38,e7b96a34,1,3c0,1000) at ufs_vnoperate+0x18
vnode_pager_putpages(cbaf08c4,e7b96ad0,1,c,e7b96a80) at vnode_pager_putpages+0xb9
vm_pageout_flush(e7b96ad0,1,c,246,e7b96ae0) at vm_pageout_flush+0xe1
vm_object_page_collect_flush(cbaf08c4,c3fecc80,394b,c,729) at vm_object_page_collect_flush+0x2a6
vm_object_page_clean(cbaf08c4,0,0,0,0) at vm_object_page_clean+0x17a
vfs_msync(cb588000,2,2,cafe9500,cb588000) at vfs_msync+0x1dc
sync_fsync(e7b96cd4,30002,cafe9500,6cd,0) at sync_fsync+0x14b
sched_sync(0,e7b96d48,c081d19a,311,0) at sched_sync+0x286
fork_exit(c0666480,0,e7b96d48) at fork_exit+0x7e
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xe7b96d7c, ebp = 0 ---
-------------- next part --------------

Should I start to think that it's vinum that's causing the crash?


Cheers,


-- 
- Matti -