Re: panic: double fault with 11.0-CURRENT r258504
On 25 Nov, Konstantin Belousov wrote:
On Sat, Nov 23, 2013 at 11:43:30PM -0800, Don Lewis wrote:
I upgraded my 11.0-CURRENT machine to r258504 to get past the uma panic
that I stumbled across earlier. Now I got this when I started upgrading
ports:
Unread portion of the kernel message buffer:
Fatal double fault:
eip = 0xc0b158e0
esp = 0xe4f62000
ebp = 0xe4f62010
cpuid = 0; apic id = 00
panic: double fault
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper(c113340c,2,1000,c15a0cf0,c15a0ce8,...) at
db_trace_self_wrapper+0x2d/frame 0xc15a0cb0
kdb_backtrace(c12f143f,0,c12f2aea,c15a0d6c,0,...) at
kdb_backtrace+0x30/frame 0xc15a0d18
vpanic(c15a0d6c,c15a0d84,c0fc14fb,c12f2aea,0,...) at vpanic+0x11f/frame
0xc15a0d54
panic(c12f2aea,0,0,0,e4f62010,...) at panic+0x12/frame 0xc15a0d60
dblfault_handler() at dblfault_handler+0xab/frame 0xc15a0d60
--- trap 0x17, eip = 0xc0b158e0, esp = 0xe4f62000, ebp = 0xe4f62010 ---
vprintf(c12f2900,c,fe7f,feff,bfff75ed,...) at vprintf/frame
0xe4f62010
trap(e4f62164) at trap+0x18a/frame 0xe4f62158
calltrap() at calltrap+0x6/frame 0xe4f62158
--- trap 0xc, eip = 0xc0b145dd, esp = 0xe4f621a4, ebp = 0xe4f62270 ---
kvprintf(c12f2900,c0b15210,e4f62290,a,e4f6235c,...) at kvprintf+0x1cd/frame
0xe4f62270
vprintf(c12f2900,e4f6235c,e4f6235c) at vprintf+0x7f/frame 0xe4f6233c
printf(c12f2900,c,ffefdfff,ebefefff,dfdffedf,...) at printf+0x1b/frame
0xe4f62350
trap(e4f624a4) at trap+0x18a/frame 0xe4f62498
calltrap() at calltrap+0x6/frame 0xe4f62498
--- trap 0xc, eip = 0xc0b145dd, esp = 0xe4f624e4, ebp = 0xe4f625b0 ---
kvprintf(c12f2900,c0b15210,e4f625d0,a,e4f6269c,...) at kvprintf+0x1cd/frame
0xe4f625b0
vprintf(c12f2900,e4f6269c,e4f6269c) at vprintf+0x7f/frame 0xe4f6267c
printf(c12f2900,c,5fd7ff5f,ba77f7fb,bfffb7ff,...) at printf+0x1b/frame
0xe4f62690
trap(e4f627e4) at trap+0x18a/frame 0xe4f627d8
calltrap() at calltrap+0x6/frame 0xe4f627d8
--- trap 0xc, eip = 0xc0b145dd, esp = 0xe4f62824, ebp = 0xe4f628f0 ---
kvprintf(c12f2900,c0b15210,e4f62910,a,e4f629dc,...) at kvprintf+0x1cd/frame
0xe4f628f0
vprintf(c12f2900,e4f629dc,e4f629dc) at vprintf+0x7f/frame 0xe4f629bc
printf(c12f2900,c,0,8000,c0,...) at printf+0x1b/frame 0xe4f629d0
trap(e4f62b20) at trap+0x18a/frame 0xe4f62b14
calltrap() at calltrap+0x6/frame 0xe4f62b14
--- trap 0xc, eip = 0xc0afe270, esp = 0xe4f62b60, ebp = 0xe4f62b78 ---
tdq_choose(c141e090,4,c113144d,917,c2425c80,...) at tdq_choose+0x60/frame
0xe4f62b78
sched_choose(e4f62c00,c0afc511,c141e090,14,c113144d,...) at
sched_choose+0x4c/frame 0xe4f62ba4
choosethread(c141e090,14,c113144d,78b,c141e116,...) at
choosethread+0x1f/frame 0xe4f62bac
sched_switch(c8f04000,0,608,1b7,ef2,...) at sched_switch+0x361/frame
0xe4f62c00
mi_switch(608,0,c112f4e4,d3,c,...) at mi_switch+0x1c9/frame 0xe4f62c34
critical_exit(0,2,c113144d,411,c141e108,...) at critical_exit+0xa4/frame
0xe4f62c50
sched_idletd(0,e4f62d08,c1128634,3db,0,...) at sched_idletd+0x1d6/frame
0xe4f62ccc
fork_exit(c0afeb00,0,e4f62d08) at fork_exit+0x7f/frame 0xe4f62cf4
fork_trampoline() at fork_trampoline+0x8/frame 0xe4f62cf4
--- trap 0, eip = 0, esp = 0xe4f62d40, ebp = 0 ---
KDB: enter: panic
(kgdb) list *tdq_choose+0x60
0xc0afe270 is in tdq_choose (/usr/src/sys/kern/sched_ule.c:1334).
1329 td = runq_choose(tdq-tdq_realtime);
1330 if (td != NULL)
1331 return (td);
1332 td = runq_choose_from(tdq-tdq_timeshare, tdq-tdq_ridx);
1333 if (td != NULL) {
1334 KASSERT(td-td_priority = PRI_MIN_BATCH,
1335 (tdq_choose: Invalid priority on timeshare queue
%d,
1336 td-td_priority));
1337 return (td);
1338 }
(kgdb) bt
#0 doadump (textdump=-1051128300) at pcpu.h:233
#1 0xc052766d in db_fncall (dummy1=-1051051648, dummy2=0,
dummy3=-1051063684,
dummy4=0xc15a0a54 ) at /usr/src/sys/ddb/db_command.c:578
#2 0xc0527357 in db_command (cmd_table=value optimized out)
at /usr/src/sys/ddb/db_command.c:449
#3 0xc0527090 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502
#4 0xc0529922 in db_trap (type=value optimized out, code=0)
at /usr/src/sys/ddb/db_main.c:231
#5 0xc0b0ff38 in kdb_trap (type=value optimized out,
code=value optimized out, tf=value optimized out)
at /usr/src/sys/kern/subr_kdb.c:656
#6 0xc0fc0c07 in trap (frame=value optimized out)
at /usr/src/sys/i386/i386/trap.c:712
#7 0xc0faa0ec in calltrap () at /usr/src/sys/i386/i386/exception.s:170
#8 0xc0b0f7bd in kdb_enter (why=0xc112ee39 panic, msg=value optimized
out)
at cpufunc.h:71
#9 0xc0ad6a93 in vpanic (fmt=value optimized out, ap=value optimized
out)
at /usr/src/sys/kern/kern_shutdown.c:747
#10 0xc0ad6ad2 in panic (fmt=0xc12f2aea double fault)
at /usr/src/sys/kern/kern_shutdown.c:683
#11 0xc0fc14fb in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:1072
#12 0x in
Re: panic: double fault with 11.0-CURRENT r258504
On Wed, Nov 27, 2013 at 12:22:27AM -0800, Don Lewis wrote: It took a while, but I just got another double fault, though this one is somewhat different. This time it trapped in cpu_switch(), which resulted in calls to trap()-printf()-...-putchar()-msgbuf_addstr()-_mtx_lock_spin_flags() where it trapped again. Sitting at DDB prompt ... Does 'show allpcpu' work ? pgpCwbNGR0JYY.pgp Description: PGP signature
Re: panic: double fault with 11.0-CURRENT r258504
On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 12:22:27AM -0800, Don Lewis wrote: It took a while, but I just got another double fault, though this one is somewhat different. This time it trapped in cpu_switch(), which resulted in calls to trap()-printf()-...-putchar()-msgbuf_addstr()-_mtx_lock_spin_flags() where it trapped again. Sitting at DDB prompt ... Does 'show allpcpu' work ? Yup. For both CPUs, curthread == idlethread, both CPUs have the same curpcb. What is dynamic pcpu? The values differ considerably between the two CPUs. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
(bsd)patch vs ports
When building ports on head I sometimes see messages like the following during a patch phase: === Applying FreeBSD patches for firefox-25.0_1,1 No such line 262 in input file, ignoring === Applying NSS patches No such line 194 in input file, ignoring No such line 658 in input file, ignoring No such line 52 in input file, ignoring No such line 45 in input file, ignoring Is this a cause for concern? Do those messages mean that potentially important patches are not actually applied? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
FreeBSD 10.0-BETA3 snapshots (pre -BETA4) now available
FreeBSD 10.0-BETA3 snapshots are now available. These images are generated from r258657 of stable/10, and are intended as pre -BETA4 snapshots for public testing, until 10.0-BETA4 is rolled (which should be within the next few days). Please note, freebsd-update(8) upgrades are not available for this set of builds. As these builds are considered snapshot-only, the change list is not included, in case something needs to be reverted for the 10.0-BETA4 builds. If you notice problems you can report them through the normal GNATS PR system or here on the -current mailing list. The images may be downloaded from the 'snapshots' directory on FTP: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ In addition, pre-built virtual machine images are also available: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/ Checksums for the installation ISOs and the VM disk images follow at the end of this email. == ISO CHECKSUMS == - 10.0-BETA3 amd64: SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-bootonly.iso) = bbaf40b51278e7f0f31ca056459539acd4eeca07eb3db77468e70f68dadfbc93 SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-disc1.iso) = e3f35a786af16bf8ea7f8ba8a1ce1a4ca0aaeb4388bd1af0f5d948072768472a SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-dvd1.iso) = 61c8031ad3c7daafe619e686485d04ee219dc6cdec5636ac171f3e6317c37004 SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-memstick.img) = 7f8bb8e0815772a9277d8465f7b43c22b07b7dd6251ddc0809ae9309c379d743 MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-bootonly.iso) = 573f679c2eacfbf46dd8452975c5a807 MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-disc1.iso) = 6ca7358887c622b7d9290da0acc4373c MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-dvd1.iso) = 833e47010f72aaed8e4ef5df8ef2f65d MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-memstick.img) = 576c2fc5c63aa3b3e46da38f7c40dec4 - 10.0-BETA3 i386: SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657-bootonly.iso) = d08bf30619af86c5c8013a64be3fe3496c6b45b522a431660617011039a966a5 SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657-disc1.iso) = 59e98e4f91bee70d9101b04f315ea2b5e2d3650f1f203ed9bba0a9e3bea09159 SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657-dvd1.iso) = 0680818b9bf51513a5fbf311720873207f528c6201f9b05dbe322843a83ca9de SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657-memstick.img) = 7c333fd25bb9e16c9b52027b3991e96b89f5cf44bb9e6d4e5ffb2162cb5f8654 MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657-bootonly.iso) = 3e950d40c7f807d0a4b8eef2d85da4c5 MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657-disc1.iso) = 95c5deb510b2d7d89d39435210c93e90 MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657-dvd1.iso) = 961394ea39d97ed706b8f840566aa7cd MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657-memstick.img) = 12366e49affc33a9104861172adab6f4 - 10.0-BETA3 ia64: SHA256 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-bootonly.iso) = 843d2f6c7c2c57063e0de773f98c3d6327deded9fbe7488fdd90f5d3b091399d SHA256 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-disc1.iso) = 2f2b51ec6f9a32cd12db58bcb9e577f39689c250da666e7d3ceecbc54883377c SHA256 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-memstick.img) = 08902cfd3447df4edac150ff96bbf1235bab4ac461e4238c1125eea83cba15b1 MD5 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-bootonly.iso) = 876d0a31510cf6a1251324738be82177 MD5 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-disc1.iso) = 0acf4517db5df9407e97857d7811277b MD5 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-memstick.img) = 55025d6ac489769ebb251ac137fe89e7 - 10.0-BETA3 powerpc: SHA256 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-bootonly.iso) = fff26c419a1a7380af4fdf8cee86aabd97584d03c6da71b2dff7e3f277f17711 SHA256 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-disc1.iso) = 2cdad79753ca5dc45907f14587fcfd06eed1b8449ed367f225045372762119b9 SHA256 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-memstick.img) = 16f2f54a9b7943b4eff89a8d52e96724caefecb39683125543a507a20df49953 MD5 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-bootonly.iso) = 9fb3857c394473d1e6fa7bd0753a6201 MD5 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-disc1.iso) = 4e9304f55d8a63310e4eda6c5bd8e4c7 MD5 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-memstick.img) = 11fc39cb92d9ef2d643c56368221443e - 10.0-BETA3 powerpc64: SHA256 (FreeBSD-10.0-BETA3-powerpc-powerpc64-20131126-r258657-bootonly.iso) = 7eb672f81d4c3cb32399f4285bb049e8576d1fabe46350210ca37bb01ea2e523 SHA256 (FreeBSD-10.0-BETA3-powerpc-powerpc64-20131126-r258657-disc1.iso) = 3ee0949bcab657b461fa5ca9eeef82ec8cd561750e098fbfd899330178bf2337 SHA256 (FreeBSD-10.0-BETA3-powerpc-powerpc64-20131126-r258657-memstick.img) = df21073b158b9be8bedd8d7ed55bd385a02844234c0ecb61701a3b42b6e035bb MD5 (FreeBSD-10.0-BETA3-powerpc-powerpc64-20131126-r258657-bootonly.iso) =
Re: panic: double fault with 11.0-CURRENT r258504
On Wed, Nov 27, 2013 at 01:13:41AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 12:22:27AM -0800, Don Lewis wrote: It took a while, but I just got another double fault, though this one is somewhat different. This time it trapped in cpu_switch(), which resulted in calls to trap()-printf()-...-putchar()-msgbuf_addstr()-_mtx_lock_spin_flags() where it trapped again. Sitting at DDB prompt ... Does 'show allpcpu' work ? Yup. For both CPUs, curthread == idlethread, both CPUs have the same curpcb. What is dynamic pcpu? The values differ considerably between the two CPUs. Are you sure about curpcb being the same for two CPUs ? This is rather broken. The best would be to show the actual ddb output. Dynamic pcpu is in fact 'static' pcpu which is allocated for modules. It must be per-cpu, so different values are correct. pgpnkUm4PkCO1.pgp Description: PGP signature
Re: panic: double fault with 11.0-CURRENT r258504
On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 01:13:41AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 12:22:27AM -0800, Don Lewis wrote: It took a while, but I just got another double fault, though this one is somewhat different. This time it trapped in cpu_switch(), which resulted in calls to trap()-printf()-...-putchar()-msgbuf_addstr()-_mtx_lock_spin_flags() where it trapped again. Sitting at DDB prompt ... Does 'show allpcpu' work ? Yup. For both CPUs, curthread == idlethread, both CPUs have the same curpcb. What is dynamic pcpu? The values differ considerably between the two CPUs. Are you sure about curpcb being the same for two CPUs ? This is rather broken. The best would be to show the actual ddb output. It turns out that they are different: 0xe4f62d60 0xe4f65d60 Screenshot here: http://people.freebsd.org/~truckman/doublefault1.JPG Dynamic pcpu is in fact 'static' pcpu which is allocated for modules. It must be per-cpu, so different values are correct. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: double fault with 11.0-CURRENT r258504
On 27 Nov, I wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 01:13:41AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 12:22:27AM -0800, Don Lewis wrote: It took a while, but I just got another double fault, though this one is somewhat different. This time it trapped in cpu_switch(), which resulted in calls to trap()-printf()-...-putchar()-msgbuf_addstr()-_mtx_lock_spin_flags() where it trapped again. Sitting at DDB prompt ... Does 'show allpcpu' work ? Yup. For both CPUs, curthread == idlethread, both CPUs have the same curpcb. What is dynamic pcpu? The values differ considerably between the two CPUs. Are you sure about curpcb being the same for two CPUs ? This is rather broken. The best would be to show the actual ddb output. It turns out that they are different: 0xe4f62d60 0xe4f65d60 Screenshot here: http://people.freebsd.org/~truckman/doublefault1.JPG And screenshot of the stack trace here: http://people.freebsd.org/~truckman/doublefault2.JPG ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Feature request: sticky bit inheritance
Hello, ever since I took a FreeBSD machine into production, acting as any kind of file server, I have to work arround the problem, that write access to a directory implies unlinking (deleting) directory contents. Never heard any sensible explanation why anybody would ever want that behaviour, but it's been like that for decades and everybody seems to be fine with that!?! Maybe because there's the stick bit, which is a usable workarround. Unfortunately, there's no “sticky” equivalent in nfs4acls. More unfortunate, newly created directories don't inherit the sticky bit – unlike the group settings. And most unfortunate, I'm not able to implement sticky bit inheritance myself :-( Since there's already a kind of inheritance when calling mkdir(1), I guess extendig the inheritance to respect the sticky bit shouldn't be too complex, is it? I'd love to see a sysctl which controls the behaviour, so there's no unexpected behaviour, but the possibillity to make FreeBSDs filsystem-permission-control more real-world-usable. But if a sysctl is noticable more effort than just a kern-conf (compile time) option, I'd also highly appreciate that option! Is there anybody who might want to look into that? Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: (bsd)patch vs ports
On Wednesday, November 27, 2013 11:21:58 AM Andriy Gapon wrote: When building ports on head I sometimes see messages like the following during a patch phase: === Applying FreeBSD patches for firefox-25.0_1,1 No such line 262 in input file, ignoring === Applying NSS patches No such line 194 in input file, ignoring No such line 658 in input file, ignoring No such line 52 in input file, ignoring No such line 45 in input file, ignoring Is this a cause for concern? Do those messages mean that potentially important patches are not actually applied? Well.. If it compiles, then no, those patches were probably not important. Security fixes are usually done upstream by the vendor. Honestly, it appears that someone left old patch files, and those patches may no longer be needed for firefox to compile on FreeBSD. break19 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on amd64/amd64
TB --- 2013-11-27 07:20:17 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-27 07:20:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-27 07:20:17 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-11-27 07:20:17 - cleaning the object tree TB --- 2013-11-27 07:28:48 - /usr/local/bin/svn stat /src TB --- 2013-11-27 07:28:52 - At svn revision 258674 TB --- 2013-11-27 07:28:53 - building world TB --- 2013-11-27 07:28:53 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 07:28:53 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 07:28:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 07:28:53 - SRCCONF=/dev/null TB --- 2013-11-27 07:28:53 - TARGET=amd64 TB --- 2013-11-27 07:28:53 - TARGET_ARCH=amd64 TB --- 2013-11-27 07:28:53 - TZ=UTC TB --- 2013-11-27 07:28:53 - __MAKE_CONF=/dev/null TB --- 2013-11-27 07:28:53 - cd /src TB --- 2013-11-27 07:28:53 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Nov 27 07:28:59 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Nov 27 10:41:58 UTC 2013 TB --- 2013-11-27 10:41:58 - generating LINT kernel config TB --- 2013-11-27 10:41:58 - cd /src/sys/amd64/conf TB --- 2013-11-27 10:41:58 - /usr/bin/make -B LINT TB --- 2013-11-27 10:41:58 - cd /src/sys/amd64/conf TB --- 2013-11-27 10:41:58 - /usr/sbin/config -m LINT TB --- 2013-11-27 10:41:58 - building LINT kernel TB --- 2013-11-27 10:41:58 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 10:41:58 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 10:41:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 10:41:58 - SRCCONF=/dev/null TB --- 2013-11-27 10:41:58 - TARGET=amd64 TB --- 2013-11-27 10:41:58 - TARGET_ARCH=amd64 TB --- 2013-11-27 10:41:58 - TZ=UTC TB --- 2013-11-27 10:41:58 - __MAKE_CONF=/dev/null TB --- 2013-11-27 10:41:58 - cd /src TB --- 2013-11-27 10:41:58 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Nov 27 10:41:58 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Wed Nov 27 11:18:27 UTC 2013 TB --- 2013-11-27 11:18:27 - cd /src/sys/amd64/conf TB --- 2013-11-27 11:18:27 - /usr/sbin/config -m LINT-NOINET TB --- 2013-11-27 11:18:27 - building LINT-NOINET kernel TB --- 2013-11-27 11:18:27 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 11:18:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 11:18:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 11:18:27 - SRCCONF=/dev/null TB --- 2013-11-27 11:18:27 - TARGET=amd64 TB --- 2013-11-27 11:18:27 - TARGET_ARCH=amd64 TB --- 2013-11-27 11:18:27 - TZ=UTC TB --- 2013-11-27 11:18:27 - __MAKE_CONF=/dev/null TB --- 2013-11-27 11:18:27 - cd /src TB --- 2013-11-27 11:18:27 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Wed Nov 27 11:18:27 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Wed Nov 27 11:50:46 UTC 2013 TB --- 2013-11-27 11:50:46 - cd /src/sys/amd64/conf TB --- 2013-11-27 11:50:46 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-11-27 11:50:46 - building LINT-NOINET6 kernel TB --- 2013-11-27 11:50:46 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 11:50:46 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 11:50:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 11:50:46 - SRCCONF=/dev/null TB --- 2013-11-27 11:50:46 - TARGET=amd64 TB --- 2013-11-27 11:50:46 - TARGET_ARCH=amd64 TB --- 2013-11-27 11:50:46 - TZ=UTC TB --- 2013-11-27 11:50:46 - __MAKE_CONF=/dev/null TB --- 2013-11-27 11:50:46 - cd /src TB --- 2013-11-27 11:50:46 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Wed Nov 27 11:50:46 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Wed Nov 27 12:23:15 UTC 2013 TB --- 2013-11-27 12:23:15 - cd /src/sys/amd64/conf TB --- 2013-11-27 12:23:15 - /usr/sbin/config -m LINT-NOIP TB --- 2013-11-27 12:23:15 - building LINT-NOIP kernel TB --- 2013-11-27 12:23:15 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 12:23:15 -
[head tinderbox] failure on i386/i386
TB --- 2013-11-27 07:20:17 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-27 07:20:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-27 07:20:17 - starting HEAD tinderbox run for i386/i386 TB --- 2013-11-27 07:20:17 - cleaning the object tree TB --- 2013-11-27 07:28:28 - /usr/local/bin/svn stat /src TB --- 2013-11-27 07:28:32 - At svn revision 258674 TB --- 2013-11-27 07:28:33 - building world TB --- 2013-11-27 07:28:33 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 07:28:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 07:28:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 07:28:33 - SRCCONF=/dev/null TB --- 2013-11-27 07:28:33 - TARGET=i386 TB --- 2013-11-27 07:28:33 - TARGET_ARCH=i386 TB --- 2013-11-27 07:28:33 - TZ=UTC TB --- 2013-11-27 07:28:33 - __MAKE_CONF=/dev/null TB --- 2013-11-27 07:28:33 - cd /src TB --- 2013-11-27 07:28:33 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Nov 27 07:28:40 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Nov 27 10:41:58 UTC 2013 TB --- 2013-11-27 10:41:58 - generating LINT kernel config TB --- 2013-11-27 10:41:58 - cd /src/sys/i386/conf TB --- 2013-11-27 10:41:58 - /usr/bin/make -B LINT TB --- 2013-11-27 10:41:58 - cd /src/sys/i386/conf TB --- 2013-11-27 10:41:58 - /usr/sbin/config -m LINT TB --- 2013-11-27 10:41:58 - building LINT kernel TB --- 2013-11-27 10:41:58 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 10:41:58 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 10:41:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 10:41:58 - SRCCONF=/dev/null TB --- 2013-11-27 10:41:58 - TARGET=i386 TB --- 2013-11-27 10:41:58 - TARGET_ARCH=i386 TB --- 2013-11-27 10:41:58 - TZ=UTC TB --- 2013-11-27 10:41:58 - __MAKE_CONF=/dev/null TB --- 2013-11-27 10:41:58 - cd /src TB --- 2013-11-27 10:41:58 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Nov 27 10:41:58 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Wed Nov 27 11:18:44 UTC 2013 TB --- 2013-11-27 11:18:44 - cd /src/sys/i386/conf TB --- 2013-11-27 11:18:44 - /usr/sbin/config -m LINT-NOINET TB --- 2013-11-27 11:18:44 - building LINT-NOINET kernel TB --- 2013-11-27 11:18:44 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 11:18:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 11:18:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 11:18:44 - SRCCONF=/dev/null TB --- 2013-11-27 11:18:44 - TARGET=i386 TB --- 2013-11-27 11:18:44 - TARGET_ARCH=i386 TB --- 2013-11-27 11:18:44 - TZ=UTC TB --- 2013-11-27 11:18:44 - __MAKE_CONF=/dev/null TB --- 2013-11-27 11:18:44 - cd /src TB --- 2013-11-27 11:18:44 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Wed Nov 27 11:18:44 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Wed Nov 27 11:51:46 UTC 2013 TB --- 2013-11-27 11:51:46 - cd /src/sys/i386/conf TB --- 2013-11-27 11:51:46 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-11-27 11:51:46 - building LINT-NOINET6 kernel TB --- 2013-11-27 11:51:46 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 11:51:46 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-27 11:51:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-27 11:51:46 - SRCCONF=/dev/null TB --- 2013-11-27 11:51:46 - TARGET=i386 TB --- 2013-11-27 11:51:46 - TARGET_ARCH=i386 TB --- 2013-11-27 11:51:46 - TZ=UTC TB --- 2013-11-27 11:51:46 - __MAKE_CONF=/dev/null TB --- 2013-11-27 11:51:46 - cd /src TB --- 2013-11-27 11:51:46 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Wed Nov 27 11:51:46 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Wed Nov 27 12:24:28 UTC 2013 TB --- 2013-11-27 12:24:28 - cd /src/sys/i386/conf TB --- 2013-11-27 12:24:28 - /usr/sbin/config -m LINT-NOIP TB --- 2013-11-27 12:24:28 - building LINT-NOIP kernel TB --- 2013-11-27 12:24:28 - CROSS_BUILD_TESTING=YES TB --- 2013-11-27 12:24:28 - MAKEOBJDIRPREFIX=/obj
Re: [head tinderbox] failure on amd64/amd64
On Wed, Nov 27, 2013 at 8:07 AM, FreeBSD Tinderbox tinder...@freebsd.orgwrote:
stage 3.2: building everything
[...]
^
/src/sys/sys/sdt.h:153:19: note: expanded from macro 'SDT_PROBE_DEFINE'
struct sdt_probe sdt_##prov##_##mod##_##func##_##name[1] = {
\
^
scratch space:51:1: note: expanded from here
sdt_vnet_functions_vnet_destroy_entry
^
4 errors generated.
*** Error code 1
Stop.
bmake[1]: stopped in /obj/amd64.amd64/src/sys/LINT-VIMAGE
*** Error code 1
Stop.
bmake: stopped in /src
*** Error code 1
Stop in /src.
TB --- 2013-11-27 13:07:05 - WARNING: /usr/bin/make returned exit code 1
TB --- 2013-11-27 13:07:05 - ERROR: failed to build LINT-VIMAGE kernel
TB --- 2013-11-27 13:07:05 - 15909.88 user 3061.45 system 20807.46 real
http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full
Seems like this was a typo or copy/paste error. This patch fixes it:
diff --git a/sys/net/vnet.c b/sys/net/vnet.c
index 977bf59..bceb2ef 100644
--- a/sys/net/vnet.c
+++ b/sys/net/vnet.c
@@ -216,7 +216,7 @@ SDT_PROBE_DEFINE2(vnet, functions, vnet_alloc, return,
int, struct vnet *);
SDT_PROBE_DEFINE2(vnet, functions, vnet_destroy, entry,
int, struct vnet *);
-SDT_PROBE_DEFINE1(vnet, functions, vnet_destroy, entry,
+SDT_PROBE_DEFINE1(vnet, functions, vnet_destroy, return,
int);
#ifdef DDB
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on amd64/amd64
On 27 November 2013 17:59, Shawn Webb latt...@gmail.com wrote:
On Wed, Nov 27, 2013 at 8:07 AM, FreeBSD Tinderbox
tinder...@freebsd.orgwrote:
stage 3.2: building everything
[...]
^
/src/sys/sys/sdt.h:153:19: note: expanded from macro 'SDT_PROBE_DEFINE'
struct sdt_probe sdt_##prov##_##mod##_##func##_##name[1] = {
\
^
scratch space:51:1: note: expanded from here
sdt_vnet_functions_vnet_destroy_entry
^
4 errors generated.
*** Error code 1
Stop.
bmake[1]: stopped in /obj/amd64.amd64/src/sys/LINT-VIMAGE
*** Error code 1
Stop.
bmake: stopped in /src
*** Error code 1
Stop in /src.
TB --- 2013-11-27 13:07:05 - WARNING: /usr/bin/make returned exit code 1
TB --- 2013-11-27 13:07:05 - ERROR: failed to build LINT-VIMAGE kernel
TB --- 2013-11-27 13:07:05 - 15909.88 user 3061.45 system 20807.46 real
http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full
Seems like this was a typo or copy/paste error. This patch fixes it:
This should be fixed in r258675. Tinderbox is lagging behind.
--
wbr,
pluknet
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Feature request: sticky bit inheritance
On 11/27/13, 8:03 PM, Harald Schmalzbauer wrote: Hello, ever since I took a FreeBSD machine into production, acting as any kind of file server, I have to work arround the problem, that write access to a directory implies unlinking (deleting) directory contents. not sure I fully understand what you mean by that.. Do you mean write access implies delete access? yes.. This can be modified with the nounlink flag. (man 2 chflags) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[request] ntp upgrade
Hi, is it possible to include in base system of the upcoming 10.0 the new version of ntp (4.2.7 instead of 4.2.4)? There is a bug in older versions ( 4.2.7) who allows attacker use an ntp server to DDoS. This has been corrected in new version: https://cert.litnet.lt/en/docs/ntp-distributed-reflection-dos-attacks This attack seems to be increasing in the last few weeks. net/ntp-devel is Ok. Thank you, sorry for my basic english. -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [request] ntp upgrade
On Wed, Nov 27, 2013 at 3:29 PM, Cristiano Deana cristiano.de...@gmail.com wrote: Hi, is it possible to include in base system of the upcoming 10.0 the new version of ntp (4.2.7 instead of 4.2.4)? There is a bug in older versions ( 4.2.7) who allows attacker use an ntp server to DDoS. This has been corrected in new version: https://cert.litnet.lt/en/docs/ntp-distributed-reflection-dos-attacks This attack seems to be increasing in the last few weeks. net/ntp-devel is Ok. Thank you, sorry for my basic english. ntp 4.2.4p8 isn't vulnerable. http://www.cvedetails.com/vulnerability-list/vendor_id-2153/NTP.html The reflection attack is the first in the list, 4.2.4p7 and below are affected. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [request] ntp upgrade
On Wed, Nov 27, 2013 at 5:06 PM, Tom Evans tevans...@googlemail.com wrote: There is a bug in older versions ( 4.2.7) who allows attacker use an ntp server to DDoS. This has been corrected in new version: https://cert.litnet.lt/en/docs/ntp-distributed-reflection-dos-attacks This attack seems to be increasing in the last few weeks. net/ntp-devel is Ok. ntp 4.2.4p8 isn't vulnerable. http://www.cvedetails.com/vulnerability-list/vendor_id-2153/NTP.html The reflection attack is the first in the list, 4.2.4p7 and below are affected. Thank you, Tom for your quick reply. That is not the same bug. I had two ntpd with 4.2.4p8 used the last days to DDoS. I found the link below, used net/ntp-devel and the abuse was gone. -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Feature request: sticky bit inheritance
Bezüglich Julian Elischer's Nachricht vom 27.11.2013 16:20 (localtime): On 11/27/13, 8:03 PM, Harald Schmalzbauer wrote: Hello, ever since I took a FreeBSD machine into production, acting as any kind of file server, I have to work arround the problem, that write access to a directory implies unlinking (deleting) directory contents. not sure I fully understand what you mean by that.. Do you mean write access implies delete access? yes.. This can be modified with the nounlink flag. The uunlink flags also prohibits the owner to delete his files as far as I know. I want to prohibt users from deleting “foreign” files, even if the user has write access to the parent directory (and I wanted to explain that I don't understand why anybody would want that a user with write access to a directory can delete files on which the user doesn't have write access). The sticky bit exactly does what I need (and should be the default behaviour in my opinion). But my problem is that the stick bit must be added to each single directory after creation, it's not inherited. I'd need every child directory of directories, who have the sticky bit set, also to have the sticky bit. The same behaviour as with the gid – it's the same as the parent has for new directories. Thanks, -Harry signature.asc Description: OpenPGP digital signature
[HEADSUP!!!] do not upgrade to or past r258632 if you use ZFS + TRIM
on 26/11/2013 11:57 Andriy Gapon said the following: Author: avg Date: Tue Nov 26 09:57:14 2013 New Revision: 258632 URL: http://svnweb.freebsd.org/changeset/base/258632 Log: MFV r255255: 4045 zfs write throttle i/o scheduler performance work illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e Please note the following changes: - zio_ioctl has lost its priority parameter and now TRIM is executed with 'now' priority - some knobs are gone and some new knobs are added; not all of them are exposed as tunables / sysctls yet MFC after: 10 days Sponsored by: HybridCluster [merge] I think that I've introduced a very serious bug when merging this change. Please do not upgrade to this revision if you use ZFS with SSDs and have TRIM support enabled. If you have already upgraded, please disable TRIM support ASAP and roll back to a previous version of kernel and then check integrity of your pools. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
warning
OS: FreeBSD 10.0-BETA3 #0 r257580: Sun Nov 3 19:43:01 UTC 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 When I boot a computer I got one warning: /etc/rc: WARNING: $tcsd_enable is not set properly I don't now on which setting is this warning related. My rc.conf looks like: hostname=blabla ifconfig_bge0=DHCP ntpd_enable=YES powerd_enable=YES dumpdev=NO pf_enable=YES pflog_enable=YES update_motd=NO dbus_enable=YES hald_enable=YES saver=green blanktime=600 webcamd_enable=YES linux_enable=YES cupsd_enable=YES Thanks in advance. -- Mitja --- http://www.redbubble.com/people.lumiwa ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
python 2.7
OS: FreeBSD 10.0-BETA3 #0 r257580: Sun Nov 3 19:43:01 UTC 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 I have all the time python related warnings: WARNING pid 1615 (python2.7): ioctl sign-extension ioctl 80087467 WARNING pid 1617 (python2.7): ioctl sign-extension ioctl 80087467 Thank you. -- Mitja --- http://www.redbubble.com/people.lumiwa ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: double fault with 11.0-CURRENT r258504
On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: http://people.freebsd.org/~truckman/doublefault2.JPG What is the instruction at cpu_switch+0x9b ? pgpkUYYh0Npao.pgp Description: PGP signature
Re: [request] ntp upgrade
On Wed, Nov 27, 2013 at 4:10 PM, Cristiano Deana cristiano.de...@gmail.com wrote: On Wed, Nov 27, 2013 at 5:06 PM, Tom Evans tevans...@googlemail.com wrote: There is a bug in older versions ( 4.2.7) who allows attacker use an ntp server to DDoS. This has been corrected in new version: https://cert.litnet.lt/en/docs/ntp-distributed-reflection-dos-attacks This attack seems to be increasing in the last few weeks. net/ntp-devel is Ok. ntp 4.2.4p8 isn't vulnerable. http://www.cvedetails.com/vulnerability-list/vendor_id-2153/NTP.html The reflection attack is the first in the list, 4.2.4p7 and below are affected. Thank you, Tom for your quick reply. That is not the same bug. I had two ntpd with 4.2.4p8 used the last days to DDoS. I found the link below, used net/ntp-devel and the abuse was gone. Does it have a CVE? The article is low on content :( Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: double fault with 11.0-CURRENT r258504
On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: http://people.freebsd.org/~truckman/doublefault2.JPG What is the instruction at cpu_switch+0x9b ? movl 0x8(%edx),%eax This machine is running in i386 mode. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: double fault with 11.0-CURRENT r258504
On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: http://people.freebsd.org/~truckman/doublefault2.JPG What is the instruction at cpu_switch+0x9b ? movl 0x8(%edx),%eax So it is line 176 in swtch.s. Is machine still in ddb, or did you obtained the core ? If yes, please print out the content of words at 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the word at address (*) + 8. This machine is running in i386 mode. Yes, this is clear from the backtraces. pgpiwfdg_cp0M.pgp Description: PGP signature
Re: panic: double fault with 11.0-CURRENT r258504
On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: http://people.freebsd.org/~truckman/doublefault2.JPG What is the instruction at cpu_switch+0x9b ? movl 0x8(%edx),%eax So it is line 176 in swtch.s. Is machine still in ddb, or did you obtained the core ? If yes, please print out the content of words at 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the word at address (*) + 8. It is still in ddb. http://people.freebsd.org/~truckman/doublefault3.JPG, though not in the above order. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Re: libc++ vs. libstdc++ usage in the ports tree
On Wed, Nov 27, 2013 at 07:31:44PM +0100, Jan Henrik Sylvester wrote: On 11/14/2013 15:45, Steve Kargl wrote: And in practice, it is broken. http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046565.html QED Trying to migrate to 10, I would like to keep octave. Have you found anything new? Having build the port and all dependencies with standard options, octave is segfaulting for me, too. Anyhow, I can run octave with: env LD_PRELOAD=/usr/lib/libc++.so.1 octave Unfortunately, you need to add USE_GCC=any to math/octave/Makefile, and rebuild it. You theni need to run ldd -a | more and search for shared libraries that are linked against both libc++ and libstdc++. Then, add USE_GCC=any to those ports' Makefile and recompile. I recall at least 4 that needed to be rebuilt, but only remember fltk and libgraphite2. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Re: libc++ vs. libstdc++ usage in the ports tree
On 11/14/2013 15:45, Steve Kargl wrote: On Thu, Nov 14, 2013 at 09:54:52AM +, David Chisnall wrote: On 13 Nov 2013, at 19:40, Dimitry Andric d...@freebsd.org wrote: On the other hand, different C++ standard libraries simply cannot be mixed. The internal implementations are usually completely different. This is not really news at all, certainly not to the ports people. :-) That said, it should still be possible to mix them in different libraries. The constraint from the wiki still applies: if you don't use STL types at library boundaries, then it should still work. If you do, then the libc++ and libstdc++ symbols will be mangled differently and so you will get link-time errors. In theory, if it links it should run... And in practice, it is broken. http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046565.html QED Trying to migrate to 10, I would like to keep octave. Have you found anything new? Having build the port and all dependencies with standard options, octave is segfaulting for me, too. Anyhow, I can run octave with: env LD_PRELOAD=/usr/lib/libc++.so.1 octave Some very light testing indicates that it is working. Of course, this is not ideal. Maybe this gives a clue how to fix the octave port properly. Cheers, Jan Henrik ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: double fault with 11.0-CURRENT r258504
On Wed, Nov 27, 2013 at 10:33:30AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: http://people.freebsd.org/~truckman/doublefault2.JPG What is the instruction at cpu_switch+0x9b ? movl 0x8(%edx),%eax So it is line 176 in swtch.s. Is machine still in ddb, or did you obtained the core ? If yes, please print out the content of words at 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the word at address (*) + 8. It is still in ddb. http://people.freebsd.org/~truckman/doublefault3.JPG, though not in the above order. Uhm, sorry, I mistyped the last part of the instructions. The new thread pointer is 0xd2f4e000, there is nothing incriminating. Please print the word at 0xd2f4e000+0x254 == 0xd2f4e254, which would be the address of the new thread pcb. It is load from the pcb + 8 which faults. pgpzr6WYU0flP.pgp Description: PGP signature
Re: panic: double fault with 11.0-CURRENT r258504
On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 10:33:30AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: http://people.freebsd.org/~truckman/doublefault2.JPG What is the instruction at cpu_switch+0x9b ? movl 0x8(%edx),%eax So it is line 176 in swtch.s. Is machine still in ddb, or did you obtained the core ? If yes, please print out the content of words at 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the word at address (*) + 8. It is still in ddb. http://people.freebsd.org/~truckman/doublefault3.JPG, though not in the above order. Uhm, sorry, I mistyped the last part of the instructions. The new thread pointer is 0xd2f4e000, there is nothing incriminating. Please print the word at 0xd2f4e000+0x254 == 0xd2f4e254, which would be the address of the new thread pcb. It is load from the pcb + 8 which faults. 0xf3d44d60 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: warning
On Wednesday 27 November 2013 12:59:10 Ajtim wrote: On Wednesday 27 November 2013 17:07:40 you wrote: On Wed, Nov 27, 2013 at 4:55 PM, Ajtim lum...@gmail.com wrote: OS: FreeBSD 10.0-BETA3 #0 r257580: Sun Nov 3 19:43:01 UTC 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 When I boot a computer I got one warning: /etc/rc: WARNING: $tcsd_enable is not set properly This is part of a port, security/trousers. Reinstall it? Cheers Tom Thank you. I didn't reinstall yet. I did and warning exist. If I put tcsd_enable=YES in /etc/rc.conf than I gor that cannot start tcsd. Thank you. -- Mitja --- http://www.redbubble.com/people.lumiwa ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: double fault with 11.0-CURRENT r258504
On Wed, Nov 27, 2013 at 11:02:57AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 10:33:30AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: http://people.freebsd.org/~truckman/doublefault2.JPG What is the instruction at cpu_switch+0x9b ? movl 0x8(%edx),%eax So it is line 176 in swtch.s. Is machine still in ddb, or did you obtained the core ? If yes, please print out the content of words at 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the word at address (*) + 8. It is still in ddb. http://people.freebsd.org/~truckman/doublefault3.JPG, though not in the above order. Uhm, sorry, I mistyped the last part of the instructions. The new thread pointer is 0xd2f4e000, there is nothing incriminating. Please print the word at 0xd2f4e000+0x254 == 0xd2f4e254, which would be the address of the new thread pcb. It is load from the pcb + 8 which faults. 0xf3d44d60 Again, the pointer looks fine, and its tail is 0xd60, which is correct for the pcb offset in the last page of the thread stack. Please do 'show thread 0xd2f4e000' before trying below instructions. What happens if you try to read word at 0xf3d44d68 ? pgpnctCgGCVZ9.pgp Description: PGP signature
[review] sendfile / sendfile_sync refactoring
Hi, Here's part #2 in my sendfile refactoring. This is a little more intrusive than the first patch. http://people.freebsd.org/~adrian/netflix/20131126-sendfile-sync-refactor-2.diff My aim here is to move the sendfile_sync stuff out of uipc_syscalls.c and out of sendfile-only code and into something that can be reused elsewhere or replaced later on. I've created methods for all the sendfile_sync stuff, I've moved it out of the do_sendfile() loop so do_sendfile() doesn't specifically implement the completion behaviour. Initially, I'm going to implement a sendfile knote representing the completion of this particular mbuf transaction. I also have a vague, handwav-y idea to use this kind of mbuf transaction representation for later work with aio_write() (and maybe an aio_writev()) when writing to a socket - wire in the userland memory, create a chain of mbufs to represent those, wrap them up in a sendfile_sync (or whatever it mutates into) and then use that for the kqueue completion notification. It needs the same kind of mbuf transaction and kqueue notification mechanism so I'd like to eventually make the sendfile_sync stuff generic, or use the memory buffer representation from jhb, to implement this in a variety of places. I'm not entirely happy where the sendfile_sync stuff is living but this is all meant to be transition-y and enable further hacking on sendfile / variations thereof without having to duplicate too much code. Thanks, -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree
On Wed, 27 Nov 2013 19:31:44 +0100 Jan Henrik Sylvester wrote:
Trying to migrate to 10, I would like to keep octave. Have you found
anything new? Having build the port and all dependencies with standard
options, octave is segfaulting for me, too. Anyhow, I can run octave with:
env LD_PRELOAD=/usr/lib/libc++.so.1 octave
Some very light testing indicates that it is working. Of course, this is
not ideal.
Maybe this gives a clue how to fix the octave port properly.
I have a preliminary patch for math/octave that I wanted to test on
redports first, but it is down at the moment so here it is.Index: math/octave/Makefile
===
--- math/octave/Makefile (revision 335025)
+++ math/octave/Makefile (working copy)
@@ -32,7 +32,7 @@ LIB_DEPENDS= GraphicsMagick:${PORTSDIR}/
umfpack.1:${PORTSDIR}/math/suitesparse \
glpk:${PORTSDIR}/math/glpk
-USES= charsetfix gmake perl5 pkgconfig
+USES= charsetfix fortran gmake perl5 pkgconfig
USE_BZIP2= yes
USE_PERL5= build
USE_TEX= dvipsk:build
@@ -74,8 +74,6 @@ BLAS= -lptf77blas
LAPACK= -lalapack -lptcblas
.endif
-USE_FORTRAN= yes
-
OCTAVE_VERSION= ${PORTVERSION}
GNU_HOST= ${ARCH}-portbld-freebsd${OSREL}
PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION} GNU_HOST=${GNU_HOST}
@@ -140,7 +138,8 @@ post-install:
${ECHO_CMD} @dirrm share/octave ${WRKDIR}/PLIST
cd ${WRKDIR} ; ${SED} -i -e /PLIST/ r PLIST ${TMPPLIST}
-check:
+check: regression-test
+regression-test: build
(cd ${WRKSRC}; ${SETENV} ${MAKE_ENV} ${GMAKE} ${MAKE_ARGS} check)
.include bsd.port.post.mk
Index: math/octave/files/patch-configure
===
--- math/octave/files/patch-configure (revision 0)
+++ math/octave/files/patch-configure (working copy)
@@ -0,0 +1,11 @@
+--- configure.orig 2013-02-21 21:21:49.0 +0100
configure 2013-11-22 20:34:49.0 +0100
+@@ -58248,7 +58248,7 @@
+ main ()
+ {
+
+- std::unordered_map m;
++ std::unordered_mapint, int m;
+
+ ;
+ return 0;
Property changes on: math/octave/files/patch-configure
___
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Index: math/octave/files/patch-libgnu-math.in.h
===
--- math/octave/files/patch-libgnu-math.in.h (revision 0)
+++ math/octave/files/patch-libgnu-math.in.h (working copy)
@@ -0,0 +1,11 @@
+--- libgnu/math.in.h.orig 2013-02-21 21:21:17.0 +0100
libgnu/math.in.h 2013-11-22 12:35:47.0 +0100
+@@ -17,7 +17,7 @@
+You should have received a copy of the GNU General Public License
+along with this program. If not, see http://www.gnu.org/licenses/. */
+
+-#ifndef _@GUARD_PREFIX@_MATH_H
++#if 1
+
+ #if __GNUC__ = 3
+ @PRAGMA_SYSTEM_HEADER@
Property changes on: math/octave/files/patch-libgnu-math.in.h
___
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Index: math/octave/files/patch-liboctave-eigs-base.cc
===
--- math/octave/files/patch-liboctave-eigs-base.cc (revision 0)
+++ math/octave/files/patch-liboctave-eigs-base.cc (working copy)
@@ -0,0 +1,11 @@
+--- liboctave/eigs-base.cc.orig 2013-02-21 21:19:24.0 +0100
liboctave/eigs-base.cc 2013-11-22 20:19:19.0 +0100
+@@ -3832,7 +3832,7 @@
+ bool cholB = 0, int disp = 0, int maxit = 300);
+ #endif
+
+-#ifndef _MSC_VER
++#if !defined(_MSC_VER) !defined(__clang__)
+ template static octave_idx_type
+ lusolve (const SparseMatrix, const SparseMatrix, Matrix);
+
Property changes on: math/octave/files/patch-liboctave-eigs-base.cc
___
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Index: Mk/Uses/fortran.mk
===
--- Mk/Uses/fortran.mk (revision 0)
+++ Mk/Uses/fortran.mk (working copy)
@@ -0,0 +1,32 @@
+# $FreeBSD$
+#
+# Establish Fortran-capable compiler as a build dependency
+#
+# MAINTAINER: po...@freebsd.org
+#
+# Feature: fortran
+# Usage: USES=fortran
+# Valid ARGS: does not require args
+
+.if !defined(_INCLUDE_USES_FORTRAN_MK)
+_INCLUDE_USES_FORTRAN_MK= yes
+
+.if defined(fortran_ARGS)
+IGNORE= USES=fortran does not require args
+.endif
+
Re: panic: double fault with 11.0-CURRENT r258504
On Wed, Nov 27, 2013 at 11:35:19AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 11:02:57AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 10:33:30AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: http://people.freebsd.org/~truckman/doublefault2.JPG What is the instruction at cpu_switch+0x9b ? movl 0x8(%edx),%eax So it is line 176 in swtch.s. Is machine still in ddb, or did you obtained the core ? If yes, please print out the content of words at 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the word at address (*) + 8. It is still in ddb. http://people.freebsd.org/~truckman/doublefault3.JPG, though not in the above order. Uhm, sorry, I mistyped the last part of the instructions. The new thread pointer is 0xd2f4e000, there is nothing incriminating. Please print the word at 0xd2f4e000+0x254 == 0xd2f4e254, which would be the address of the new thread pcb. It is load from the pcb + 8 which faults. 0xf3d44d60 Again, the pointer looks fine, and its tail is 0xd60, which is correct for the pcb offset in the last page of the thread stack. Please do 'show thread 0xd2f4e000' before trying below instructions. Ok, see below: What happens if you try to read word at 0xf3d44d68 ? Nothing bad ... http://people.freebsd.org/~truckman/doublefault4.JPG So the thread structure looks sane, the stack region is in place where it is supposed to be, all the gathered data looks self-consistent. And, the access to the faulted address from ddb does not fault. Thread stacks can only be invalidated when the process is swapped out and kernel stack is written to swap. Your thread flags indicate that it is in memory, and TDF_CANSWAP is not set. I do not believe that our swapout code would invalidate stack mapping in such situation, otherwise we would have too many complaints already. Just in case, do you use swap on this box ? And, as the last resort, I do understand that this sounds as giving up, do you monitor the temperature of the CPUs ? BTW, which CPUs are that, please show the cpu identification lines from the boot dmesg. pgp8CtXBo4KXZ.pgp Description: PGP signature
Re: [request] ntp upgrade
On Wed, Nov 27, 2013 at 4:29 PM, Cristiano Deana cristiano.de...@gmail.com wrote: Hi, is it possible to include in base system of the upcoming 10.0 the new version of ntp (4.2.7 instead of 4.2.4)? There is a bug in older versions ( 4.2.7) who allows attacker use an ntp server to DDoS. This has been corrected in new version: https://cert.litnet.lt/en/docs/ntp-distributed-reflection-dos-attacks Thanks for this URL, I've meet this problem on my FreeBSD 9.2 few weeks ago (public NTP registered in the pool.ntp.org). There is a thread on the ntp.org ML about this too: http://lists.ntp.org/pipermail/pool/2013-November/thread.html Regards, Olivier ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: double fault with 11.0-CURRENT r258504
On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 11:02:57AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 10:33:30AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: http://people.freebsd.org/~truckman/doublefault2.JPG What is the instruction at cpu_switch+0x9b ? movl 0x8(%edx),%eax So it is line 176 in swtch.s. Is machine still in ddb, or did you obtained the core ? If yes, please print out the content of words at 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the word at address (*) + 8. It is still in ddb. http://people.freebsd.org/~truckman/doublefault3.JPG, though not in the above order. Uhm, sorry, I mistyped the last part of the instructions. The new thread pointer is 0xd2f4e000, there is nothing incriminating. Please print the word at 0xd2f4e000+0x254 == 0xd2f4e254, which would be the address of the new thread pcb. It is load from the pcb + 8 which faults. 0xf3d44d60 Again, the pointer looks fine, and its tail is 0xd60, which is correct for the pcb offset in the last page of the thread stack. Please do 'show thread 0xd2f4e000' before trying below instructions. Ok, see below: What happens if you try to read word at 0xf3d44d68 ? Nothing bad ... http://people.freebsd.org/~truckman/doublefault4.JPG ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: double fault with 11.0-CURRENT r258504
On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 11:35:19AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 11:02:57AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 10:33:30AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: http://people.freebsd.org/~truckman/doublefault2.JPG What is the instruction at cpu_switch+0x9b ? movl 0x8(%edx),%eax So it is line 176 in swtch.s. Is machine still in ddb, or did you obtained the core ? If yes, please print out the content of words at 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the word at address (*) + 8. It is still in ddb. http://people.freebsd.org/~truckman/doublefault3.JPG, though not in the above order. Uhm, sorry, I mistyped the last part of the instructions. The new thread pointer is 0xd2f4e000, there is nothing incriminating. Please print the word at 0xd2f4e000+0x254 == 0xd2f4e254, which would be the address of the new thread pcb. It is load from the pcb + 8 which faults. 0xf3d44d60 Again, the pointer looks fine, and its tail is 0xd60, which is correct for the pcb offset in the last page of the thread stack. Please do 'show thread 0xd2f4e000' before trying below instructions. Ok, see below: What happens if you try to read word at 0xf3d44d68 ? Nothing bad ... http://people.freebsd.org/~truckman/doublefault4.JPG So the thread structure looks sane, the stack region is in place where it is supposed to be, all the gathered data looks self-consistent. And, the access to the faulted address from ddb does not fault. Thread stacks can only be invalidated when the process is swapped out and kernel stack is written to swap. Your thread flags indicate that it is in memory, and TDF_CANSWAP is not set. I do not believe that our swapout code would invalidate stack mapping in such situation, otherwise we would have too many complaints already. Just in case, do you use swap on this box ? I do. And, as the last resort, I do understand that this sounds as giving up, do you monitor the temperature of the CPUs ? BTW, which CPUs are that, please show the cpu identification lines from the boot dmesg. I don't monitor the temperature, but I do hear the CPU fan speed ramping up and down when I'm building ports like this. Even though I'm pretty much keeping one core busy the whole time, the temperature must drop enough at times to let the fan speed drop. I can run math/mprime on this machine for a while to see if anything shows up. I also have a very similar machine (same motherboard but different CPU) that I can move the drive over to and test. Here's the full dmesg.boot: Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #63 r258614M: Tue Nov 26 00:29:01 PST 2013 d...@scratch.catspoiler.org:/usr/obj/usr/src/sys/GENERICSMB i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ (2500.06-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x60fb1 Family = 0xf Model = 0x6b Stepping = 1 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x2001SSE3,CX16 AMD Features=0xea500800SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x11fLAHF,CMP,SVM,ExtAPIC,CR8,Prefetch real memory = 4294967296 (4096 MB) avail memory = 3589320704 (3423 MB) Event timer LAPIC quality 400 ACPI APIC Table: Nvidia AWRDACPI FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has zero address or length: 0x/0x1 (20130823/tbfadt-630) ioapic0: Changing APIC ID to 2 ioapic0 Version 1.1 irqs 0-23 on motherboard random: Software, Yarrow initialized kbd1 at kbdmux0 acpi0: Nvidia AWRDACPI on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, dbdf (3) failed cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 attimer0: AT timer port 0x40-0x43 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 hpet0: High Precision Event Timer iomem 0xfeff-0xfeff03ff irq 0,8 on acpi0 device_attach: hpet0 attach returned 12 atrtc0: AT realtime clock port 0x70-0x73 on acpi0 Event timer RTC
Re: [request] ntp upgrade
On Wed, Nov 27, 2013 at 6:21 PM, Tom Evans tevans...@googlemail.com wrote: Does it have a CVE? The article is low on content I don't think so. I think there were lot of ideas about the DDoS, that's the only article suggesting a right solution (in my experience). I think they are still investigating. Italian FreeBSD User Group http://www.gufi.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [request] ntp upgrade
On Wed, Nov 27, 2013 at 9:03 PM, Olivier Cochard-Labbé oliv...@cochard.mewrote: Hi Thanks for this URL, I've meet this problem on my FreeBSD 9.2 few weeks ago (public NTP registered in the pool.ntp.org). Same for me. There is a thread on the ntp.org ML about this too: http://lists.ntp.org/pipermail/pool/2013-November/thread.html i tried those suggestion too (with discard parameter) but it didn't work. When I switched to ntp-devel everything went fine. Just: # service ntpd stop # cd /usr/ports/net/ntp-devel make -DBATCH install # echo 'ntpd_program=/usr/local/sbin/ntpd' /etc/rc.conf # service ntpd start it will use same /etc/ntp.conf conf file. -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: double fault with 11.0-CURRENT r258504
On 27 Nov, Konstantin Belousov wrote: And, as the last resort, I do understand that this sounds as giving up, do you monitor the temperature of the CPUs ? BTW, which CPUs are that, please show the cpu identification lines from the boot dmesg. Idle temps: hw.acpi.thermal.tz0.temperature: 38.0C dev.cpu.0.temperature: 40.2C dev.cpu.1.temperature: 44.2C dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%parent: hostb3 dev.amdtemp.0.sensor_offset: 0 dev.amdtemp.0.core0.sensor0: 40.5C dev.amdtemp.0.core0.sensor1: 36.2C dev.amdtemp.0.core1.sensor0: 44.5C dev.amdtemp.0.core1.sensor1: 28.7C Running two copies of mprime: hw.acpi.thermal.tz0.temperature: 60.0C dev.cpu.0.temperature: 52.5C dev.cpu.1.temperature: 55.0C dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%parent: hostb3 dev.amdtemp.0.sensor_offset: 0 dev.amdtemp.0.core0.sensor0: 51.7C dev.amdtemp.0.core0.sensor1: 52.2C dev.amdtemp.0.core1.sensor0: 55.0C dev.amdtemp.0.core1.sensor1: 44.0C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Feature request: sticky bit inheritance
On 11/28/13, 12:17 AM, Harald Schmalzbauer wrote: Bezüglich Julian Elischer's Nachricht vom 27.11.2013 16:20 (localtime): On 11/27/13, 8:03 PM, Harald Schmalzbauer wrote: Hello, ever since I took a FreeBSD machine into production, acting as any kind of file server, I have to work arround the problem, that write access to a directory implies unlinking (deleting) directory contents. not sure I fully understand what you mean by that.. Do you mean write access implies delete access? yes.. This can be modified with the nounlink flag. The uunlink flags also prohibits the owner to delete his files as far as I know. I want to prohibt users from deleting “foreign” files, even if the user has write access to the parent directory (and I wanted to explain that I don't understand why anybody would want that a user with write access to a directory can delete files on which the user doesn't have write access). You can always unlink a file that is not yours if you own the directory. because the ability to unlink is purely dependent on the directory. You don't change the file, and it may in fact have other links The 'nounlink' flags change this. The sticky bit exactly does what I need (and should be the default behaviour in my opinion). But my problem is that the stick bit must be added to each single directory after creation, it's not inherited. correct. I'd need every child directory of directories, who have the sticky bit set, also to have the sticky bit. The same behaviour as with the gid – it's the same as the parent has for new directories. patches accepted :-) I don't think that you are going to have much chance in changing default unix behaviour, but a patch (that can be disabled) would have a chance if there was a really good reason for it. Thanks, -Harry ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree
Hmm thanks for discussion. I'll install and test FBSD 10 in this weekend. thanks Nakata Maho From: Steve Kargl s...@troutmask.apl.washington.edu Subject: Re: Re: libc++ vs. libstdc++ usage in the ports tree Date: Wed, 27 Nov 2013 10:43:02 -0800 On Wed, Nov 27, 2013 at 07:31:44PM +0100, Jan Henrik Sylvester wrote: On 11/14/2013 15:45, Steve Kargl wrote: And in practice, it is broken. http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046565.html QED Trying to migrate to 10, I would like to keep octave. Have you found anything new? Having build the port and all dependencies with standard options, octave is segfaulting for me, too. Anyhow, I can run octave with: env LD_PRELOAD=/usr/lib/libc++.so.1 octave Unfortunately, you need to add USE_GCC=any to math/octave/Makefile, and rebuild it. You theni need to run ldd -a | more and search for shared libraries that are linked against both libc++ and libstdc++. Then, add USE_GCC=any to those ports' Makefile and recompile. I recall at least 4 that needed to be rebuilt, but only remember fltk and libgraphite2. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: double fault with 11.0-CURRENT r258504
On Wed, Nov 27, 2013 at 01:11:35PM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 11:35:19AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 11:02:57AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 10:33:30AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 09:41:36AM -0800, Don Lewis wrote: On 27 Nov, Konstantin Belousov wrote: On Wed, Nov 27, 2013 at 02:49:12AM -0800, Don Lewis wrote: http://people.freebsd.org/~truckman/doublefault2.JPG What is the instruction at cpu_switch+0x9b ? movl 0x8(%edx),%eax So it is line 176 in swtch.s. Is machine still in ddb, or did you obtained the core ? If yes, please print out the content of words at 0xe4f62bb0 + 4, +8 (*), +16. Please print the content of the word at address (*) + 8. It is still in ddb. http://people.freebsd.org/~truckman/doublefault3.JPG, though not in the above order. Uhm, sorry, I mistyped the last part of the instructions. The new thread pointer is 0xd2f4e000, there is nothing incriminating. Please print the word at 0xd2f4e000+0x254 == 0xd2f4e254, which would be the address of the new thread pcb. It is load from the pcb + 8 which faults. 0xf3d44d60 Again, the pointer looks fine, and its tail is 0xd60, which is correct for the pcb offset in the last page of the thread stack. Please do 'show thread 0xd2f4e000' before trying below instructions. Ok, see below: What happens if you try to read word at 0xf3d44d68 ? Nothing bad ... http://people.freebsd.org/~truckman/doublefault4.JPG So the thread structure looks sane, the stack region is in place where it is supposed to be, all the gathered data looks self-consistent. And, the access to the faulted address from ddb does not fault. Thread stacks can only be invalidated when the process is swapped out and kernel stack is written to swap. Your thread flags indicate that it is in memory, and TDF_CANSWAP is not set. I do not believe that our swapout code would invalidate stack mapping in such situation, otherwise we would have too many complaints already. Just in case, do you use swap on this box ? I do. And, as the last resort, I do understand that this sounds as giving up, do you monitor the temperature of the CPUs ? BTW, which CPUs are that, please show the cpu identification lines from the boot dmesg. I don't monitor the temperature, but I do hear the CPU fan speed ramping up and down when I'm building ports like this. Even though I'm pretty much keeping one core busy the whole time, the temperature must drop enough at times to let the fan speed drop. I can run math/mprime on this machine for a while to see if anything shows up. I also have a very similar machine (same motherboard but different CPU) that I can move the drive over to and test. Here's the full dmesg.boot: Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #63 r258614M: Tue Nov 26 00:29:01 PST 2013 d...@scratch.catspoiler.org:/usr/obj/usr/src/sys/GENERICSMB i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ (2500.06-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x60fb1 Family = 0xf Model = 0x6b Stepping = 1 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x2001SSE3,CX16 AMD Features=0xea500800SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x11fLAHF,CMP,SVM,ExtAPIC,CR8,Prefetch The errata list for the Athlon 64 X2 is quite long. Do you have latest BIOS ? I am not sure if AMD provides standalone firmware update blocks for their CPUs. If any Linux distribution ships updates for AMD CPUs, it might be useful to load the update with cpucontrol(8). Even if we do not hit a CPU bug, it would provide me with more certainity that we are not chasing ghost. Another things to try, in vain, is to compile kernel with gcc or disable SMP. Peter, could you, please, try to reproduce the issue ? It does not look like a random hardware failure, since in all cases, it is curthread access which is faulting. The issue is only reported by Don, and so far only for i386 SMP. pgp2Xr0ZdiSmh.pgp Description: PGP signature
