Re: ipv6_addrs_IF aliases in rc.conf(5)
Michael Grimm wrote in <4c07217dc9200841dfd065a6d5284...@mx1.enfer-du-nord.net>: tr> On 2013-07-12 6:56, Hiroki Sato wrote: tr> > Kevin Oberman wrote tr> > in : tr> > rk> On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder 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 wrote in <201306200229.r5k2tnfr085...@svn.freebsd.org>: hr> A summary of the supported ifconfig_* variables is as follows: hr> hr># IPv4 configuration. hr>ifconfig_em0="inet 192.168.0.1" hr># IPv6 configuration. hr>ifconfig_em0_ipv6="inet6 2001:db8::1/64" hr># IPv4 address range spec. Now deprecated. hr>ipv4_addr_em0="10.2.1.1-10" hr># IPv6 alias. hr>ifconfig_em0_alias0="inet6 2001:db8:5::1 prefixlen 70" hr># IPv4 alias. hr>ifconfig_em0_alias1="inet 10.2.2.1/24" hr># IPv4 alias with range spec w/o AF keyword (backward compat). hr>ifconfig_em0_alias2="10.3.1.1-10/32" hr># IPv6 alias with range spec. hr>ifconfig_em0_alias3="inet6 2001:db8:20-2f::1/64" hr># ifconfig_IF_aliases is just like ifconfig_IF_aliasN. hr>ifconfig_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) hr>ipv6_ifconfig_em0_alias0="inet6 2001:db8:f::1/64" hr># IPv6 alias w/o AF keyword (backward compat) hr>ipv6_ifconfig_em0_alias1="2001:db8:f:1::1/64" hr># IPv6 prefix. hr>ipv6_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=) 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-
Re: What are the ideal ranges for kern.ipc.shm*?
On Fri, 12 Jul 2013 05:24:55 +0200, Chris H 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 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
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 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 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 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 > 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"
