Date: Tue, 20 Jan 2004 08:15:22 +0200 From: Matti Saarinen <mjs@cc.tut.fi> To: Don Lewis <truckman@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: 5.2R: panic (syncer) on IBM x345 (SMP and Vinum) Message-ID: <qzu7jznp2md.fsf@butler.cc.tut.fi> In-Reply-To: <200401191329.i0JDTI7E055867@gw.catspoiler.org> (Don Lewis's message of "Mon, 19 Jan 2004 05:29:18 -0800 (PST)") References: <200401191329.i0JDTI7E055867@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-=-= Don Lewis <truckman@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. --=-=-= Content-Disposition: attachment; filename=news-crash-2004-01-20-08.00 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 --- --=-=-= Should I start to think that it's vinum that's causing the crash? Cheers, -- - Matti - --=-=-=--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?qzu7jznp2md.fsf>