On 12/06/06 14:37, Max Laier wrote: > On Wednesday 06 December 2006 14:20, Volker wrote: >> The following reply was made to PR kern/106400; it has been noted by >> GNATS. >> >> From: Volker <[EMAIL PROTECTED]> >> To: [EMAIL PROTECTED], [EMAIL PROTECTED] >> Cc: >> Subject: Re: kern/106400: fatal trap 12 at restart of PF with ALTQ if >> ng0 device has detached >> Date: Wed, 06 Dec 2006 14:16:42 +0100 >> >> First I would suggest to use ALTQ w/ mpd not on ng0 but on the real >> physical interface (for example fxp0, xl0) which is being used by >> netgraph/mpd. >> >> On the other side I also do have trouble using ALTQ with mpd but I'm >> using mpd for a 3G connection (based on a tty device, not a NIC). >> >> Avoiding ALTQ rules in pf.conf for the ng0 interface (not using ALTQ >> on ng0) doesn't produce a fatal trap 12. So disabling ALTQ in your >> kernel is not the only workaround. You may still use ALTQ on your >> internal NIC without a trap. >> >> Unlike your experience, I always do experience a kernel trap when >> reloading pf rules w/ ALTQ on ng0 (whether or not pf rules are >> reloaded by a script or manually). >> >> This also occours while the ng0 interface is still there and from my >> experience it's not related to a reload of mpd. > > Can you provide a trace for this panic? I have a good understanding of > the issue in the PR, but your problem seems to be quite different if the > ng0 device really doesn't go away meanwhile. More details would be > required. >
Max, sure, I can do that but please stay patient for some days. I need to setup debugging env, serial cable and get the right time to be willing to crash my server machine... ;) Just as a pre-information, here's the dmesg output of a crash occured at 2006-11-07 (taken from periodic security message): kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x2c352f30 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc057ae05 > stack pointer = 0x28:0xdaaa595c > frame pointer = 0x28:0xdaaa5968 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 24730 (pfctl) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > kdb_backtrace(100,c3995c00,28,daaa591c,c,...) at kdb_backtrace+0x29 > panic(c07573b4,c0788e59,0,fffff,c09b,...) at panic+0x113 > trap_fatal(daaa591c,2c352f30) at trap_fatal+0x2d7 > trap(8,28,28,c3995c00,2c352e30,...) at trap+0x10e > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc057ae05, esp = 0xdaaa595c, ebp = 0xdaaa5968 --- > _mtx_lock_sleep(c346850c,c3995c00,0,0,0) at _mtx_lock_sleep+0xa5 > rmc_delete_class(c3c2cc04,c3723c00,c3723c00,a,daaa59c8,...) at rmc_delete_class+0x5a > cbq_class_destroy(c3c2c800,c3723c00,1,c3c2c800,0,...) at cbq_class_destroy+0x18 > cbq_clear_interface(c3c2c800) at cbq_clear_interface+0x37 > cbq_remove_altq(c3729600) at cbq_remove_altq+0x20 > altq_remove(c3729600) at altq_remove+0x3d > pf_commit_altq(4,cd858940,cd858940,c35a9c70,daaa5a30,...) at pf_commit_altq+0x10a > pfioctl(c3455300,c00c4452,c358b770,3,c3995c00,...) at pfioctl+0x3698 > devfs_ioctl_f(c35b65a0,c00c4452,c358b770,c3bd8e80,c3995c00) at devfs_ioctl_f+0xb3 > ioctl(c3995c00,daaa5d04) at ioctl+0x449 > syscall(3b,3b,3b,bfbfdd6c,0,...) at syscall+0x2cd > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28193b0f, esp = 0xbfbfdd4c, ebp = 0xbfbfdd78 --- I'll provide you complete details and probably more debugging infos next week. Greetings, Volker _______________________________________________ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
