Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found
On Fri, Jul 12, 2013 at 07:24:40AM +0200, Andre Albsmeier wrote: On Thu, 04-Jul-2013 at 19:25:28 +0200, Konstantin Belousov wrote: On Thu, Jul 04, 2013 at 04:29:19PM +0200, Andre Albsmeier wrote: OK, patch is applied. I will reboot the machine later and see what happens tomorrow in the morning. However, it might take a few days since the last 2 weeks all was fine. BTW, should this patch be used in general or is it just for debugging? My understanding is that it is something which could stay in the code... Patch is to improve debugging. I probably commit it after the issue is closed. Arguments against the commit is that the change imposes small performance penalty due to save and restore of the %ebp (I doubt that this is measureable by any means). Also, arguably, such change should be done for all functions in support.s, but bcopy() is the hot spot. Got a new one, 2 hours old ;-) GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xcd5ec000 fault code = supervisor write, page not present instruction pointer = 0x20:0xc07cb2fe stack pointer = 0x28:0xd82e45cc frame pointer = 0x28:0xd82e45d4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 18714 (mksnap_ffs) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c08207eb,d82e4418,c05fdfc9,c081df13,c08a82e0,...) at db_trace_self_wrapper+0x26/frame 0xd82e43e8 kdb_backtrace(c081df13,c08a82e0,c0801bfa,d82e4424,d82e4424,...) at kdb_backtrace+0x29/frame 0xd82e43f4 panic(c0801bfa,c0845a01,c2b067d4,1,1,...) at panic+0xc9/frame 0xd82e4418 trap_fatal(c0ff6000,cd5ec000,2,0,c08b6bf4,...) at trap_fatal+0x353/frame 0xd82e4458 trap_pfault(baa8454b,21510,0,c2b06620,c08b6bf0,...) at trap_pfault+0x2d7/frame 0xd82e44a0 trap(d82e458c) at trap+0x41a/frame 0xd82e4580 calltrap() at calltrap+0x6/frame 0xd82e4580 --- trap 0xc, eip = 0xc07cb2fe, esp = 0xd82e45cc, ebp = 0xd82e45d4 --- bcopy(c36ed000,cd5e6000,8000,8000,c281b980,...) at bcopy+0x1a/frame 0xd82e45d4 ffs_snapshot(c2b35a90,c2ed0400,0,0,0,...) at ffs_snapshot+0x2933/frame 0xd82e490c ffs_mount(c2b35a90,c322e200,ff,d82e4c08,c2ccbc8c,...) at ffs_mount+0x15ee/frame 0xd82e4a3c vfs_donmount(c2b06620,10313108,0,c2b74d80,c2b74d80,...) at vfs_donmount+0x196b/frame 0xd82e4c2c sys_nmount(c2b06620,d82e4ccc,c2b06908,d82e4c6c,c0605015,...) at sys_nmount+0x63/frame 0xd82e4c50 syscall(d82e4d08) at syscall+0x2ce/frame 0xd82e4cfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xd82e4cfc --- syscall (378, FreeBSD ELF32, sys_nmount), eip = 0x180bdf37, esp = 0xbfbfd65c, ebp = 0xbfbfddd8 --- Uptime: 4d20h0m44s Physical memory: 503 MB Dumping 104 MB: 89 73 57 41 25 9 No symbol stopped_cpus in current context. No symbol stoppcbs in current context. #0 doadump (textdump=1) at pcpu.h:249 249 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump (textdump=1) at pcpu.h:249 #1 0xc05f in kern_reboot (howto=260) at /src/src-9/sys/kern/kern_shutdown.c:449 #2 0xc05fe028 in panic (fmt=value optimized out) at /src/src-9/sys/kern/kern_shutdown.c:637 #3 0xc07cd1d3 in trap_fatal (frame=0xd82e458c, eva=3445538816) at /src/src-9/sys/i386/i386/trap.c:1044 #4 0xc07cd4b7 in trap_pfault (frame=0xd82e458c, usermode=0, eva=3445538816) at /src/src-9/sys/i386/i386/trap.c:957 #5 0xc07ce05a in trap (frame=0xd82e458c) at /src/src-9/sys/i386/i386/trap.c:555 #6 0xc07ba88c in calltrap () at /src/src-9/sys/i386/i386/exception.s:170 #7 0xc07cb2fe in bcopy () at /src/src-9/sys/i386/i386/support.s:198 #8 0xc072be13 in ffs_snapshot (mp=0xc2b35a90, snapfile=0xc2ed0400 s5-2013.07.12-03.15.01) at /src/src-9/sys/ufs/ffs/ffs_snapshot.c:793 #9 0xc0748e8e in ffs_mount (mp=0xc2b35a90) at /src/src-9/sys/ufs/ffs/ffs_vfsops.c:483 #10 0xc068a72b in vfs_donmount (td=0xc2b06620, fsflags=271659272, fsoptions=0xc2b74d80) at /src/src-9/sys/kern/vfs_mount.c:948 #11 0xc068a8e3 in sys_nmount (td=0xc2b06620, uap=0xd82e4ccc) at /src/src-9/sys/kern/vfs_mount.c:417 #12 0xc07cd7ae in syscall (frame=0xd82e4d08) at subr_syscall.c:135 #13 0xc07ba8f1 in Xint0x80_syscall () at /src/src-9/sys/i386/i386/exception.s:270 #14 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) Please show me the first 100
Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found
On Fri, 12-Jul-2013 at 08:01:12 +0200, Konstantin Belousov wrote: On Fri, Jul 12, 2013 at 07:24:40AM +0200, Andre Albsmeier wrote: On Thu, 04-Jul-2013 at 19:25:28 +0200, Konstantin Belousov wrote: On Thu, Jul 04, 2013 at 04:29:19PM +0200, Andre Albsmeier wrote: OK, patch is applied. I will reboot the machine later and see what happens tomorrow in the morning. However, it might take a few days since the last 2 weeks all was fine. BTW, should this patch be used in general or is it just for debugging? My understanding is that it is something which could stay in the code... Patch is to improve debugging. I probably commit it after the issue is closed. Arguments against the commit is that the change imposes small performance penalty due to save and restore of the %ebp (I doubt that this is measureable by any means). Also, arguably, such change should be done for all functions in support.s, but bcopy() is the hot spot. Got a new one, 2 hours old ;-) GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xcd5ec000 fault code = supervisor write, page not present instruction pointer = 0x20:0xc07cb2fe stack pointer = 0x28:0xd82e45cc frame pointer = 0x28:0xd82e45d4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 18714 (mksnap_ffs) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c08207eb,d82e4418,c05fdfc9,c081df13,c08a82e0,...) at db_trace_self_wrapper+0x26/frame 0xd82e43e8 kdb_backtrace(c081df13,c08a82e0,c0801bfa,d82e4424,d82e4424,...) at kdb_backtrace+0x29/frame 0xd82e43f4 panic(c0801bfa,c0845a01,c2b067d4,1,1,...) at panic+0xc9/frame 0xd82e4418 trap_fatal(c0ff6000,cd5ec000,2,0,c08b6bf4,...) at trap_fatal+0x353/frame 0xd82e4458 trap_pfault(baa8454b,21510,0,c2b06620,c08b6bf0,...) at trap_pfault+0x2d7/frame 0xd82e44a0 trap(d82e458c) at trap+0x41a/frame 0xd82e4580 calltrap() at calltrap+0x6/frame 0xd82e4580 --- trap 0xc, eip = 0xc07cb2fe, esp = 0xd82e45cc, ebp = 0xd82e45d4 --- bcopy(c36ed000,cd5e6000,8000,8000,c281b980,...) at bcopy+0x1a/frame 0xd82e45d4 ffs_snapshot(c2b35a90,c2ed0400,0,0,0,...) at ffs_snapshot+0x2933/frame 0xd82e490c ffs_mount(c2b35a90,c322e200,ff,d82e4c08,c2ccbc8c,...) at ffs_mount+0x15ee/frame 0xd82e4a3c vfs_donmount(c2b06620,10313108,0,c2b74d80,c2b74d80,...) at vfs_donmount+0x196b/frame 0xd82e4c2c sys_nmount(c2b06620,d82e4ccc,c2b06908,d82e4c6c,c0605015,...) at sys_nmount+0x63/frame 0xd82e4c50 syscall(d82e4d08) at syscall+0x2ce/frame 0xd82e4cfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xd82e4cfc --- syscall (378, FreeBSD ELF32, sys_nmount), eip = 0x180bdf37, esp = 0xbfbfd65c, ebp = 0xbfbfddd8 --- Uptime: 4d20h0m44s Physical memory: 503 MB Dumping 104 MB: 89 73 57 41 25 9 No symbol stopped_cpus in current context. No symbol stoppcbs in current context. #0 doadump (textdump=1) at pcpu.h:249 249 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump (textdump=1) at pcpu.h:249 #1 0xc05f in kern_reboot (howto=260) at /src/src-9/sys/kern/kern_shutdown.c:449 #2 0xc05fe028 in panic (fmt=value optimized out) at /src/src-9/sys/kern/kern_shutdown.c:637 #3 0xc07cd1d3 in trap_fatal (frame=0xd82e458c, eva=3445538816) at /src/src-9/sys/i386/i386/trap.c:1044 #4 0xc07cd4b7 in trap_pfault (frame=0xd82e458c, usermode=0, eva=3445538816) at /src/src-9/sys/i386/i386/trap.c:957 #5 0xc07ce05a in trap (frame=0xd82e458c) at /src/src-9/sys/i386/i386/trap.c:555 #6 0xc07ba88c in calltrap () at /src/src-9/sys/i386/i386/exception.s:170 #7 0xc07cb2fe in bcopy () at /src/src-9/sys/i386/i386/support.s:198 #8 0xc072be13 in ffs_snapshot (mp=0xc2b35a90, snapfile=0xc2ed0400 s5-2013.07.12-03.15.01) at /src/src-9/sys/ufs/ffs/ffs_snapshot.c:793 #9 0xc0748e8e in ffs_mount (mp=0xc2b35a90) at /src/src-9/sys/ufs/ffs/ffs_vfsops.c:483 #10 0xc068a72b in vfs_donmount (td=0xc2b06620, fsflags=271659272, fsoptions=0xc2b74d80) at /src/src-9/sys/kern/vfs_mount.c:948 #11 0xc068a8e3 in sys_nmount (td=0xc2b06620, uap=0xd82e4ccc) at /src/src-9/sys/kern/vfs_mount.c:417 #12 0xc07cd7ae in syscall (frame=0xd82e4d08) at subr_syscall.c:135 #13 0xc07ba8f1
Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found
On Fri, Jul 12, 2013 at 08:05:27AM +0200, Andre Albsmeier wrote: On Fri, 12-Jul-2013 at 08:01:12 +0200, Konstantin Belousov wrote: On Fri, Jul 12, 2013 at 07:24:40AM +0200, Andre Albsmeier wrote: On Thu, 04-Jul-2013 at 19:25:28 +0200, Konstantin Belousov wrote: On Thu, Jul 04, 2013 at 04:29:19PM +0200, Andre Albsmeier wrote: OK, patch is applied. I will reboot the machine later and see what happens tomorrow in the morning. However, it might take a few days since the last 2 weeks all was fine. BTW, should this patch be used in general or is it just for debugging? My understanding is that it is something which could stay in the code... Patch is to improve debugging. I probably commit it after the issue is closed. Arguments against the commit is that the change imposes small performance penalty due to save and restore of the %ebp (I doubt that this is measureable by any means). Also, arguably, such change should be done for all functions in support.s, but bcopy() is the hot spot. Got a new one, 2 hours old ;-) GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xcd5ec000 fault code = supervisor write, page not present instruction pointer = 0x20:0xc07cb2fe stack pointer = 0x28:0xd82e45cc frame pointer = 0x28:0xd82e45d4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 18714 (mksnap_ffs) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c08207eb,d82e4418,c05fdfc9,c081df13,c08a82e0,...) at db_trace_self_wrapper+0x26/frame 0xd82e43e8 kdb_backtrace(c081df13,c08a82e0,c0801bfa,d82e4424,d82e4424,...) at kdb_backtrace+0x29/frame 0xd82e43f4 panic(c0801bfa,c0845a01,c2b067d4,1,1,...) at panic+0xc9/frame 0xd82e4418 trap_fatal(c0ff6000,cd5ec000,2,0,c08b6bf4,...) at trap_fatal+0x353/frame 0xd82e4458 trap_pfault(baa8454b,21510,0,c2b06620,c08b6bf0,...) at trap_pfault+0x2d7/frame 0xd82e44a0 trap(d82e458c) at trap+0x41a/frame 0xd82e4580 calltrap() at calltrap+0x6/frame 0xd82e4580 --- trap 0xc, eip = 0xc07cb2fe, esp = 0xd82e45cc, ebp = 0xd82e45d4 --- bcopy(c36ed000,cd5e6000,8000,8000,c281b980,...) at bcopy+0x1a/frame 0xd82e45d4 ffs_snapshot(c2b35a90,c2ed0400,0,0,0,...) at ffs_snapshot+0x2933/frame 0xd82e490c ffs_mount(c2b35a90,c322e200,ff,d82e4c08,c2ccbc8c,...) at ffs_mount+0x15ee/frame 0xd82e4a3c vfs_donmount(c2b06620,10313108,0,c2b74d80,c2b74d80,...) at vfs_donmount+0x196b/frame 0xd82e4c2c sys_nmount(c2b06620,d82e4ccc,c2b06908,d82e4c6c,c0605015,...) at sys_nmount+0x63/frame 0xd82e4c50 syscall(d82e4d08) at syscall+0x2ce/frame 0xd82e4cfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xd82e4cfc --- syscall (378, FreeBSD ELF32, sys_nmount), eip = 0x180bdf37, esp = 0xbfbfd65c, ebp = 0xbfbfddd8 --- Uptime: 4d20h0m44s Physical memory: 503 MB Dumping 104 MB: 89 73 57 41 25 9 No symbol stopped_cpus in current context. No symbol stoppcbs in current context. #0 doadump (textdump=1) at pcpu.h:249 249 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump (textdump=1) at pcpu.h:249 #1 0xc05f in kern_reboot (howto=260) at /src/src-9/sys/kern/kern_shutdown.c:449 #2 0xc05fe028 in panic (fmt=value optimized out) at /src/src-9/sys/kern/kern_shutdown.c:637 #3 0xc07cd1d3 in trap_fatal (frame=0xd82e458c, eva=3445538816) at /src/src-9/sys/i386/i386/trap.c:1044 #4 0xc07cd4b7 in trap_pfault (frame=0xd82e458c, usermode=0, eva=3445538816) at /src/src-9/sys/i386/i386/trap.c:957 #5 0xc07ce05a in trap (frame=0xd82e458c) at /src/src-9/sys/i386/i386/trap.c:555 #6 0xc07ba88c in calltrap () at /src/src-9/sys/i386/i386/exception.s:170 #7 0xc07cb2fe in bcopy () at /src/src-9/sys/i386/i386/support.s:198 #8 0xc072be13 in ffs_snapshot (mp=0xc2b35a90, snapfile=0xc2ed0400 s5-2013.07.12-03.15.01) at /src/src-9/sys/ufs/ffs/ffs_snapshot.c:793 #9 0xc0748e8e in ffs_mount (mp=0xc2b35a90) at /src/src-9/sys/ufs/ffs/ffs_vfsops.c:483 #10 0xc068a72b in vfs_donmount (td=0xc2b06620, fsflags=271659272, fsoptions=0xc2b74d80) at /src/src-9/sys/kern/vfs_mount.c:948 #11
Re: ipv6_addrs_IF aliases in rc.conf(5)
On 2013-07-12 6:56, Hiroki Sato wrote: Kevin Oberman rkober...@gmail.com wrote in can6yy1srswemj2_bjx_drzmxgk4tf50_ode8o8i2d6wtrgw...@mail.gmail.com: rk On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder f...@feld.me wrote: rk rk On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm rk trash...@odo.in-berlin.de wrote: rk rk Will that patch make it into 9.2? If I am not mistaken, that patch isn't rk in stable yet. rk rk rk I would also like to see this patch hit 9.x sooner than later. It's so rk painful when someone forgets to fix the alias numbering on servers with rk many, many IPv4 and IPv6 addresses... rk rk rk Please, please, please, please, ...! rk rk Freeze is only two days away, so time for 9.2 is almost over and I can see rk no good reason NOT to get this done. r252015 was merged to stable/9 today. Thanks! This is highly appreciated. A first glance at network.subr tells me that much more has been modified/simplified regarding alias definitions, great. Regards, Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ipv6_addrs_IF aliases in rc.conf(5)
Michael Grimm trash...@odo.in-berlin.de wrote in 4c07217dc9200841dfd065a6d5284...@mx1.enfer-du-nord.net: tr On 2013-07-12 6:56, Hiroki Sato wrote: tr Kevin Oberman rkober...@gmail.com wrote trin can6yy1srswemj2_bjx_drzmxgk4tf50_ode8o8i2d6wtrgw...@mail.gmail.com: tr rk On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder f...@feld.me wrote: tr rk tr rk On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm tr rk trash...@odo.in-berlin.de wrote: tr rk tr rk Will that patch make it into 9.2? If I am not mistaken, that patch isn't tr rk in stable yet. tr rk tr rk tr rk I would also like to see this patch hit 9.x sooner than later. It's so tr rk painful when someone forgets to fix the alias numbering on servers with tr rk many, many IPv4 and IPv6 addresses... tr rk tr rk tr rk Please, please, please, please, ...! tr rk tr rk Freeze is only two days away, so time for 9.2 is almost over and I can see tr rk no good reason NOT to get this done. tr r252015 was merged to stable/9 today. tr tr Thanks! This is highly appreciated. A first glance at network.subr tells me that tr much more has been modified/simplified regarding alias definitions, great. Please let me know if the existing configurations and/or the new formats do not work. The following is a summary of the supported rc.conf variables, FYI: Hiroki Sato h...@freebsd.org wrote in 201306200229.r5k2tnfr085...@svn.freebsd.org: hr A summary of the supported ifconfig_* variables is as follows: hr hr# IPv4 configuration. hrifconfig_em0=inet 192.168.0.1 hr# IPv6 configuration. hrifconfig_em0_ipv6=inet6 2001:db8::1/64 hr# IPv4 address range spec. Now deprecated. hripv4_addr_em0=10.2.1.1-10 hr# IPv6 alias. hrifconfig_em0_alias0=inet6 2001:db8:5::1 prefixlen 70 hr# IPv4 alias. hrifconfig_em0_alias1=inet 10.2.2.1/24 hr# IPv4 alias with range spec w/o AF keyword (backward compat). hrifconfig_em0_alias2=10.3.1.1-10/32 hr# IPv6 alias with range spec. hrifconfig_em0_alias3=inet6 2001:db8:20-2f::1/64 hr# ifconfig_IF_aliases is just like ifconfig_IF_aliasN. hrifconfig_em0_aliases=inet 10.3.3.201-204/24 inet6 2001:db8:210-213::1/64 inet 10.1.1.1/24 hr# IPv6 alias (backward compat) hripv6_ifconfig_em0_alias0=inet6 2001:db8:f::1/64 hr# IPv6 alias w/o AF keyword (backward compat) hripv6_ifconfig_em0_alias1=2001:db8:f:1::1/64 hr# IPv6 prefix. hripv6_prefix_em0=2001:db8::/64 -- Hiroki pgp_2ncrav6RP.pgp Description: PGP signature
Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found
On Fri, 12-Jul-2013 at 08:35:33 +0200, Konstantin Belousov wrote: On Fri, Jul 12, 2013 at 08:05:27AM +0200, Andre Albsmeier wrote: On Fri, 12-Jul-2013 at 08:01:12 +0200, Konstantin Belousov wrote: On Fri, Jul 12, 2013 at 07:24:40AM +0200, Andre Albsmeier wrote: On Thu, 04-Jul-2013 at 19:25:28 +0200, Konstantin Belousov wrote: On Thu, Jul 04, 2013 at 04:29:19PM +0200, Andre Albsmeier wrote: OK, patch is applied. I will reboot the machine later and see what happens tomorrow in the morning. However, it might take a few days since the last 2 weeks all was fine. BTW, should this patch be used in general or is it just for debugging? My understanding is that it is something which could stay in the code... Patch is to improve debugging. I probably commit it after the issue is closed. Arguments against the commit is that the change imposes small performance penalty due to save and restore of the %ebp (I doubt that this is measureable by any means). Also, arguably, such change should be done for all functions in support.s, but bcopy() is the hot spot. Got a new one, 2 hours old ;-) GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xcd5ec000 fault code = supervisor write, page not present instruction pointer = 0x20:0xc07cb2fe stack pointer = 0x28:0xd82e45cc frame pointer = 0x28:0xd82e45d4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 18714 (mksnap_ffs) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c08207eb,d82e4418,c05fdfc9,c081df13,c08a82e0,...) at db_trace_self_wrapper+0x26/frame 0xd82e43e8 kdb_backtrace(c081df13,c08a82e0,c0801bfa,d82e4424,d82e4424,...) at kdb_backtrace+0x29/frame 0xd82e43f4 panic(c0801bfa,c0845a01,c2b067d4,1,1,...) at panic+0xc9/frame 0xd82e4418 trap_fatal(c0ff6000,cd5ec000,2,0,c08b6bf4,...) at trap_fatal+0x353/frame 0xd82e4458 trap_pfault(baa8454b,21510,0,c2b06620,c08b6bf0,...) at trap_pfault+0x2d7/frame 0xd82e44a0 trap(d82e458c) at trap+0x41a/frame 0xd82e4580 calltrap() at calltrap+0x6/frame 0xd82e4580 --- trap 0xc, eip = 0xc07cb2fe, esp = 0xd82e45cc, ebp = 0xd82e45d4 --- bcopy(c36ed000,cd5e6000,8000,8000,c281b980,...) at bcopy+0x1a/frame 0xd82e45d4 ffs_snapshot(c2b35a90,c2ed0400,0,0,0,...) at ffs_snapshot+0x2933/frame 0xd82e490c ffs_mount(c2b35a90,c322e200,ff,d82e4c08,c2ccbc8c,...) at ffs_mount+0x15ee/frame 0xd82e4a3c vfs_donmount(c2b06620,10313108,0,c2b74d80,c2b74d80,...) at vfs_donmount+0x196b/frame 0xd82e4c2c sys_nmount(c2b06620,d82e4ccc,c2b06908,d82e4c6c,c0605015,...) at sys_nmount+0x63/frame 0xd82e4c50 syscall(d82e4d08) at syscall+0x2ce/frame 0xd82e4cfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xd82e4cfc --- syscall (378, FreeBSD ELF32, sys_nmount), eip = 0x180bdf37, esp = 0xbfbfd65c, ebp = 0xbfbfddd8 --- Uptime: 4d20h0m44s Physical memory: 503 MB Dumping 104 MB: 89 73 57 41 25 9 No symbol stopped_cpus in current context. No symbol stoppcbs in current context. #0 doadump (textdump=1) at pcpu.h:249 249 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump (textdump=1) at pcpu.h:249 #1 0xc05f in kern_reboot (howto=260) at /src/src-9/sys/kern/kern_shutdown.c:449 #2 0xc05fe028 in panic (fmt=value optimized out) at /src/src-9/sys/kern/kern_shutdown.c:637 #3 0xc07cd1d3 in trap_fatal (frame=0xd82e458c, eva=3445538816) at /src/src-9/sys/i386/i386/trap.c:1044 #4 0xc07cd4b7 in trap_pfault (frame=0xd82e458c, usermode=0, eva=3445538816) at /src/src-9/sys/i386/i386/trap.c:957 #5 0xc07ce05a in trap (frame=0xd82e458c) at /src/src-9/sys/i386/i386/trap.c:555 #6 0xc07ba88c in calltrap () at /src/src-9/sys/i386/i386/exception.s:170 #7 0xc07cb2fe in bcopy () at /src/src-9/sys/i386/i386/support.s:198 #8 0xc072be13 in ffs_snapshot (mp=0xc2b35a90, snapfile=0xc2ed0400 s5-2013.07.12-03.15.01) at /src/src-9/sys/ufs/ffs/ffs_snapshot.c:793 #9 0xc0748e8e in ffs_mount (mp=0xc2b35a90) at
Re: What are the ideal ranges for kern.ipc.shm*?
On Fri, 12 Jul 2013 05:24:55 +0200, Chris H bsd-li...@1command.com wrote: Greetings, Over the years using the xfce4 desktop, I would occasionally receive SHM ERROR messages. As they never interfered (so's I could notice), I always put off attempting to track the cause down. However, now having performed a fairly major upgrade (~1yr since last), The error appears to greatly affect KDE4 (used to use kde3) applications I run within xfce4. The windows don't re-draw correctly, and I receive additional errors,as well: ... Resource id: 0x0 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x0 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x0 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x0 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x0 QCoreApplication::postEvent: Unexpected null receiver ... After much searching, it would appear to be related to the kern.ipc.shm* values. pertinent details follow: FreeBSD udns 8.4-STABLE FreeBSD 8.4-STABLE #3: Tue Jul 2 13:41:21 PDT 2013 root@udns:/usr/obj/usr/src/sys/AMD64 amd64 with 64Gb ram, and 3 cores, and nvidia-driver-308.88_1. # ipcs -M shminfo: shmmax: 33554432(max shared memory segment size) shmmin:1(min shared memory segment size) shmmni: 192(max number of shared memory identifiers) shmseg: 128(max shared memory segments per process) shmall: 8192(max amount of shared memory in pages) My 9.1-STABLE amd64 with 4GB RAM has these default settings: ipcs -M shminfo: shmmax:536870912(max shared memory segment size) shmmin:1(min shared memory segment size) shmmni: 1024(max number of shared memory identifiers) shmseg: 1024(max shared memory segments per process) shmall: 131072(max amount of shared memory in pages) Regards, Ronald. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: strange stable/9 buildworld failure
on 11/07/2013 23:07 Dimitry Andric said the following: On Jul 11, 2013, at 19:19, Andriy Gapon a...@freebsd.org wrote: on 11/07/2013 19:43 Andriy Gapon said the following: buildword was run as make -j8 buildworld and the it mysteriously failed like this: sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 liblwres.so.80 /usr/obj/usr/src/tmp/usr/lib sh /usr/src/tools/install.sh -l s liblwres.so.80 /usr/obj/usr/src/tmp/usr/lib/liblwres.so 1 error *** [libraries] Error code 2 I could not find any actual error message in the build log. /usr/obj was cleaned out before the build. I was able to reproduce this exact failure 3 times in a row. Running buildworld without -j allowed the build to proceed further. Please note that my current userland is at (quite old) r248369, also stable/9. Hi Andriy, Can you please post the complete build log somewhere? Maybe there is something unexpected going wrong which does not show a clear error message? Sorry for the noise, all, it was a pilot error indeed. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: locks under printf(9) and WITNESS = panic?
on 11/07/2013 23:21 John Baldwin said the following:
On Saturday, June 29, 2013 9:19:24 pm Steven Hartland wrote:
when booting stable/9 under a debug kernel with WITNESS
enabled and verbose I get the following panic..
It seems very much like the discussion from a year back on
current: http://lists.freebsd.org/pipermail/freebsd-current/2012-
January/031375.html
Any ideas?
Yeah, that lock needs to be MTX_RECURSE (the cnputs_mtx). However, it
only recurses under witness. *sigh*
In my tree I have this commit:
commit 9ef2a49ec43e6ebf429e4dae3bf230a09ae106f1
Author: Andriy Gapon a...@icyb.net.ua
Date: Fri May 18 12:58:13 2012 +0300
[test] mark all locks in printf(9) call tree as no-witness
... to avoid warnings because of complex interactions between printf(9)
being called from arbitrary contexts and syscons code making non-trivial
calls into other subsystems (e.g. callout) for terminal emulation
purposes.
And also secondary problems resulting from witness(9) using printf(9)
to warn about problem in the latter and thus causing its recursion.
diff --git a/sys/dev/syscons/syscons.c b/sys/dev/syscons/syscons.c
index bfbbff7..8539d27 100644
--- a/sys/dev/syscons/syscons.c
+++ b/sys/dev/syscons/syscons.c
@@ -3299,7 +3299,7 @@ init_scp(sc_softc_t *sc, int vty, scr_stat *scp)
scp-history_pos = 0;
scp-history_size = 0;
-mtx_init(scp-scr_lock, scrlock, NULL, MTX_SPIN);
+mtx_init(scp-scr_lock, scrlock, NULL, MTX_SPIN | MTX_NOWITNESS);
}
int
diff --git a/sys/dev/syscons/syscons.h b/sys/dev/syscons/syscons.h
index 353b67f..fbe20f0 100644
--- a/sys/dev/syscons/syscons.h
+++ b/sys/dev/syscons/syscons.h
@@ -537,7 +537,7 @@ typedef struct {
#define SC_VIDEO_LOCKINIT(sc) \
mtx_init((sc)-video_mtx, syscons video lock, NULL, \
- MTX_SPIN | MTX_RECURSE);
+ MTX_SPIN | MTX_RECURSE | MTX_NOWITNESS);
#define SC_VIDEO_LOCK(sc) \
do {\
if (!cold) \
diff --git a/sys/dev/uart/uart_core.c b/sys/dev/uart/uart_core.c
index b6bed03..8396f7a 100644
--- a/sys/dev/uart/uart_core.c
+++ b/sys/dev/uart/uart_core.c
@@ -413,7 +413,7 @@ uart_bus_attach(device_t dev)
*/
sc-sc_leaving = 1;
- mtx_init(sc-sc_hwmtx_s, uart_hwmtx, NULL, MTX_SPIN);
+ mtx_init(sc-sc_hwmtx_s, uart_hwmtx, NULL, MTX_SPIN | MTX_NOWITNESS);
if (sc-sc_hwmtx == NULL)
sc-sc_hwmtx = sc-sc_hwmtx_s;
diff --git a/sys/kern/subr_witness.c b/sys/kern/subr_witness.c
index 02ad77a..9ee7e1e 100644
--- a/sys/kern/subr_witness.c
+++ b/sys/kern/subr_witness.c
@@ -632,7 +632,6 @@ static struct witness_order_list_entry order_lists[] = {
#endif
{ rm.mutex_mtx, lock_class_mtx_spin },
{ sio, lock_class_mtx_spin },
- { scrlock, lock_class_mtx_spin },
#ifdef __i386__
{ cy, lock_class_mtx_spin },
#endif
@@ -641,7 +640,6 @@ static struct witness_order_list_entry order_lists[] = {
{ rtc_mtx, lock_class_mtx_spin },
#endif
{ scc_hwmtx, lock_class_mtx_spin },
- { uart_hwmtx, lock_class_mtx_spin },
{ fast_taskqueue, lock_class_mtx_spin },
{ intr table, lock_class_mtx_spin },
#ifdef HWPMC_HOOKS
@@ -657,7 +655,6 @@ static struct witness_order_list_entry order_lists[] = {
{ td_contested, lock_class_mtx_spin },
{ callout, lock_class_mtx_spin },
{ entropy harvest mutex, lock_class_mtx_spin },
- { syscons video lock, lock_class_mtx_spin },
#ifdef SMP
{ smp rendezvous, lock_class_mtx_spin },
#endif
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: What are the ideal ranges for kern.ipc.shm*?
On Fri, Jul 12, 2013 at 5:24 AM, Chris H bsd-li...@1command.com wrote: Greetings, Over the years using the xfce4 desktop, I would occasionally receive SHM ERROR messages. As they never interfered (so's I could notice), I always put off attempting to track the cause down. However, now having performed a fairly major upgrade (~1yr since last), The error appears to greatly affect KDE4 (used to use kde3) applications I run within xfce4. The windows don't re-draw correctly, and I receive additional errors,as well: ... Resource id: 0x0 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x0 ... After much searching, it would appear to be related to the kern.ipc.shm* values. $ cat /usr/ports/x11-toolkits/qt4-gui/pkg-message Qt paint engine makes common use of shared memory. To avoid MIT-SHM errors (i.e., blank windows), you probably need to raise shared memory limits in loader.conf(5). The following should be safe values for the KDE Plasma Desktop: kern.ipc.shmall=32768 kern.ipc.shmmni=1024 kern.ipc.shmseg=1024 -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [resolved] stable/9 fails to compile: kmem_alloc_contig bad definition - radeon kms patches
12.07.2013 08:51, Volodymyr Kostyrko wrote: vm_extern.h: vm_offset_t kmem_alloc_contig(vm_map_t map, vm_size_t size, int flags, vm_paddr_t low, vm_paddr_t high, unsigned long alignment, unsigned long boundary, vm_memattr_t memattr); Why boundary is unsigned long and not vm_paddr_t? vm_contig.c: vm_offset_t kmem_alloc_contig(vm_map_t map, vm_size_t size, int flags, vm_paddr_t low, vm_paddr_t high, u_long alignment, vm_paddr_t boundary, vm_memattr_t memattr) That was caused by radeon drm patches found at https://wiki.freebsd.org/AMD_GPU -- Sphinx of black quartz, judge my vow. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: What are the ideal ranges for kern.ipc.shm*?
Greetings Alberto, and thank you for the reply. On Fri, Jul 12, 2013 at 5:24 AM, Chris H bsd-li...@1command.com wrote: Greetings, Over the years using the xfce4 desktop, I would occasionally receive SHM ERROR messages. As they never interfered (so's I could notice), I always put off attempting to track the cause down. However, now having performed a fairly major upgrade (~1yr since last), The error appears to greatly affect KDE4 (used to use kde3) applications I run within xfce4. The windows don't re-draw correctly, and I receive additional errors,as well: ... Resource id: 0x0 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x0 ... After much searching, it would appear to be related to the kern.ipc.shm* values. $ cat /usr/ports/x11-toolkits/qt4-gui/pkg-message Qt paint engine makes common use of shared memory. To avoid MIT-SHM errors (i.e., blank windows), you probably need to raise shared memory limits in loader.conf(5). The following should be safe values for the KDE Plasma Desktop: kern.ipc.shmall=32768 kern.ipc.shmmni=1024 kern.ipc.shmseg=1024 Yes, I followed those instructions when I received the message after the upgrade from qt3 -- qt4. Entering those numbers in loader.conf(5) caused the server to freeze and re-boot ~20 seconds after starting X. --chris -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re:
Re: iclaims.docx Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[no subject]
___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
