From bugzilla-noreply at freebsd.org Wed Apr 1 05:56:30 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Apr 2015 05:56:30 +0000
Subject: [Bug 194654] 10.1-RC3 hangs with simultanious writes
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194654
FreeBSD at ShaneWare.Biz changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Closed |Open
Resolution|Unable to Reproduce |---
--- Comment #8 from FreeBSD at ShaneWare.Biz ---
While the wired accumulates slower the issue is still present.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 1 09:12:40 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Apr 2015 09:12:40 +0000
Subject: [Bug 198936] [drm] Xorg consume 100% with XFCE after latest DRM2
changes
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198936
Hans Petter Selasky changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|In Progress |Closed
Resolution|--- |FIXED
--- Comment #4 from Hans Petter Selasky ---
Hi,
r280814 seems to fix the issue. I'll reopen if not. Thank you!
--HPS
--
You are receiving this mail because:
You are the assignee for the bug.
From news at campsalesaustralia.com Wed Apr 1 11:27:20 2015
From: news at campsalesaustralia.com (Camp Sales Australia)
Date: Wed, 01 Apr 2015 21:27:12 +1000
Subject: Never To Be Repeated Price: 7kva
Message-ID: <1460605722551bd61012b2b.1427887632@www.vision6.com.au>
[1]campsalesau
[Display.png]
Silent 7kVA Pure Sine Wave Inverter Camping Generator Electric Start + Remote
generator
Only
$999.00
Was $2,799.00
Buy Now
This inverter generator unit is petrol powered and differs from cheaper
units, in that the engine (which is built to the same design as the
market leading Japanese brands) drives a DC alternator. [2][read more]
[3]www.campsalesaustralia.com | Australia
This email was sent by Camp Sales AU, Sydney NSW Australia to
freebsd-bugs at freebsd.org
[4]Unsubscribe
References
Visible links
1. http://www.vision6.com.au/ch/44773/k4xj2/1895903/5fd8etf5z.html
2. http://www.vision6.com.au/ch/44773/k4xj2/1903038/5fd8eh4gz-1.html
3. http://www.vision6.com.au/ch/44773/k4xj2/1895903/5fd8etf5z-1.html
4. http://www.vision6.com.au/forms/u/d789f58/44773/16324772.html
Hidden links:
6. http://www.vision6.com.au/ch/44773/k4xj2/1903038/5fd8eh4gz.html
From bugzilla-noreply at freebsd.org Wed Apr 1 16:07:51 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Apr 2015 16:07:51 +0000
Subject: [Bug 165602] [request] pkg_add(1) - extend PACKAGESITE lookup to
include rc.conf.local
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=165602
mike at bayphoto.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|In Progress |Closed
--- Comment #1 from mike at bayphoto.com ---
this bug is no longer relevant
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 1 17:13:33 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Apr 2015 17:13:33 +0000
Subject: [Bug 199095] man page for oce driver have wrong line for loader.conf
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199095
Bug ID: 199095
Summary: man page for oce driver have wrong line for
loader.conf
Product: Base System
Version: 10.1-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: jiri at navratil.cz
The oce driver need line
oce_load="YES"
in /boot/loader.conf
but man page
https://www.freebsd.org/cgi/man.cgi?query=oce&sektion=4&manpath=FreeBSD+10.1-RELEASE
have state
if_oce_load="YES"
which is not working.
Please change if_oce_load="YES" to oce_load="YES"
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 1 17:18:50 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Apr 2015 17:18:50 +0000
Subject: [Bug 199096] Kernel panic after some time using mpd (netgraph) and
ipfw
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199096
Bug ID: 199096
Summary: Kernel panic after some time using mpd (netgraph) and
ipfw
Product: Base System
Version: 9.2-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: dblais at interplex.ca
We're managing 8 different servers with a similar setup (FreeBSD 9.2 + MPD +
IPFW) that are crashing once in a while. The crash frequency depends on the
amount of customers behind the PPPoE Server (the purpose of the servers).
It's happening on HP DL360 G5 and HP Microserver G7.
Here's the kernel output:
FreeBSD hidden_host 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26
22:50:31 UTC 2013 root at bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC
amd64
panic: page fault
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 "amd64-marcel-freebsd"...
Unread portion of the kernel message buffer:
current process = 0 (dummynet)
trap number = 12
panic: page fault
cpuid = 7
KDB: stack backtrace:
#0 0xffffffff80947986 at kdb_backtrace+0x66
#1 0xffffffff8090d9ae at panic+0x1ce
#2 0xffffffff80cf20d0 at trap_fatal+0x290
#3 0xffffffff80cf2431 at trap_pfault+0x211
#4 0xffffffff80cf29e4 at trap+0x344
#5 0xffffffff80cdbd13 at calltrap+0x8
#6 0xffffffff809c5959 at bpf_mtap2+0x89
#7 0xffffffff8188e11a at ng_iface_bpftap+0x2a
#8 0xffffffff8188eb11 at ng_iface_output+0xf1
#9 0xffffffff80a3a104 at ip_output+0xd74
#10 0xffffffff81864edc at dummynet_send+0x13c
#11 0xffffffff81865467 at dummynet_task+0x1b7
#12 0xffffffff80954554 at taskqueue_run_locked+0x74
#13 0xffffffff80955506 at taskqueue_thread_loop+0x46
#14 0xffffffff808db67f at fork_exit+0x11f
#15 0xffffffff80cdc23e at fork_trampoline+0xe
Uptime: 21d19h53m27s
Dumping 1450 out of 16359 MB:..2%..12%..21%..31%..41%..51%..61%..71%..81%..91%
Reading symbols from /boot/kernel/if_carp.ko...Reading symbols from
/boot/kernel/if_carp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/if_carp.ko
Reading symbols from /boot/kernel/pf.ko...Reading symbols from
/boot/kernel/pf.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pf.ko
Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from
/boot/kernel/ipfw.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ipfw.ko
done.
Loaded symbols for /boot/kernel/ipfw.ko
Reading symbols from /boot/kernel/dummynet.ko...Reading symbols from
/boot/kernel/dummynet.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/dummynet.ko
Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from
/boot/kernel/ng_socket.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_socket.ko
Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from
/boot/kernel/netgraph.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/netgraph.ko
Reading symbols from /boot/kernel/ng_mppc.ko...Reading symbols from
/boot/kernel/ng_mppc.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_mppc.ko
Reading symbols from /boot/kernel/rc4.ko...Reading symbols from
/boot/kernel/rc4.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/rc4.ko
Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from
/boot/kernel/ng_ether.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_ether.ko
Reading symbols from /boot/kernel/ng_pppoe.ko...Reading symbols from
/boot/kernel/ng_pppoe.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_pppoe.ko
Reading symbols from /boot/kernel/ng_tee.ko...Reading symbols from
/boot/kernel/ng_tee.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_tee.ko
Reading symbols from /boot/kernel/ng_iface.ko...Reading symbols from
/boot/kernel/ng_iface.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_iface.ko
Reading symbols from /boot/kernel/ng_ppp.ko...Reading symbols from
/boot/kernel/ng_ppp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_ppp.ko
#0 doadump (textdump=) at pcpu.h:234
234 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0 doadump (textdump=) at pcpu.h:234
#1 0xffffffff8090d486 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:449
#2 0xffffffff8090d987 in panic (fmt=0x1 )
at /usr/src/sys/kern/kern_shutdown.c:637
#3 0xffffffff80cf20d0 in trap_fatal (frame=0xc, eva=)
at /usr/src/sys/amd64/amd64/trap.c:879
#4 0xffffffff80cf2431 in trap_pfault (frame=0xffffff8882642700, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:795
#5 0xffffffff80cf29e4 in trap (frame=0xffffff8882642700)
at /usr/src/sys/amd64/amd64/trap.c:463
#6 0xffffffff80cdbd13 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:232
#7 0xffffffff8090adb0 in _rw_rlock (rw=0xfffffe013aade5a8, file=0x0,
line=485069968) at /usr/src/sys/kern/kern_rwlock.c:382
#8 0xffffffff809c5959 in bpf_mtap2 (bp=0xfffffe013aade580,
data=0xffffff88826429bc, dlen=4, m=0xfffffe0300f46700)
at /usr/src/sys/net/bpf.c:2197
#9 0xffffffff8188e11a in ng_iface_bpftap (ifp=, m=0x0,
family=144 '\220')
at /usr/src/sys/modules/netgraph/iface/../../../netgraph/ng_iface.c:444
#10 0xffffffff8188eb11 in ng_iface_output (ifp=0xfffffe014566a000,
m=0xfffffe0300f46700, dst=0xffffff8882642aac, ro=)
at /usr/src/sys/modules/netgraph/iface/../../../netgraph/ng_iface.c:394
#11 0xffffffff80a3a104 in ip_output (m=0xfffffe0300f46700,
opt=, ro=0xffffff8882642a90,
flags=, imo=0x0, inp=0x0)
at /usr/src/sys/netinet/ip_output.c:631
#12 0xffffffff81864edc in dummynet_send (m=0xfffffe0300f46700)
at /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:655
#13 0xffffffff81865467 in dummynet_task (context=,
pending=)
at /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:618
#14 0xffffffff80954554 in taskqueue_run_locked (queue=0xfffffe000d2d1a80)
at /usr/src/sys/kern/subr_taskqueue.c:312
#15 0xffffffff80955506 in taskqueue_thread_loop (arg=)
at /usr/src/sys/kern/subr_taskqueue.c:501
#16 0xffffffff808db67f in fork_exit (
callout=0xffffffff809554c0 ,
arg=0xffffffff81869be0, frame=0xffffff8882642c40)
at /usr/src/sys/kern/kern_fork.c:992
#17 0xffffffff80cdc23e in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:606
#18 0x0000000000000000 in ?? ()
(kgdb)
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 1 18:21:30 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Apr 2015 18:21:30 +0000
Subject: [Bug 199096] Kernel panic after some time using mpd (netgraph) and
ipfw
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199096
--- Comment #1 from dblais at interplex.ca ---
I previously posted into bug # 171711 but my issue is different as pointed out
by
Andrey V. Elsukov : "This panic looks different. Probably an interface has
gone away and BPF's interface departure handler already destroyed bif_lock."
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 1 18:23:49 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Apr 2015 18:23:49 +0000
Subject: [Bug 199078] IPv6 on a bridge only works if an attached interface
has had a v6 address
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199078
n+freebsd at nirf.de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|New |Closed
Resolution|--- |Not A Bug
--- Comment #1 from n+freebsd at nirf.de ---
Adding ifconfig_re0_ipv6="up" to /etc/rc.conf fixed the problem.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 1 18:30:29 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Apr 2015 18:30:28 +0000
Subject: [Bug 191951] [build] stable/10 with WITHOUT_OPENSSL not compiling
multiple issues
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191951
Bernard Spil changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |spil.oss at gmail.com
--- Comment #3 from Bernard Spil ---
Looks like it's easy to link libfetch to port's OpenSSL.
NB. Have NOT tested if this is functional!
--- lib/libfetch/Makefile.orig 2015-04-01 20:26:51.215998490 +0200
+++ lib/libfetch/Makefile 2015-04-01 20:26:32.724999161 +0200
@@ -17,7 +17,7 @@
.if ${MK_OPENSSL} != "no"
CFLAGS+= -DWITH_SSL
DPADD= ${LIBSSL} ${LIBCRYPTO}
-LDADD= -lssl -lcrypto
+LDADD= -L/usr/local/lib -lssl -lcrypto
.else
DPADD= ${LIBMD}
LDADD= -lmd
Results in
# readelf -d /usr/obj/usr/src/lib/libfetch/libfetch.so.6
Dynamic section at offset 0x110b0 contains 24 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libssl.so.32]
0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.32]
0x0000000000000001 (NEEDED) Shared library: [libc.so.7]
0x000000000000000e (SONAME) Library soname: [libfetch.so.6]
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 1 21:20:10 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Apr 2015 21:20:09 +0000
Subject: [Bug 79274] Autoconfigure fails for O2Micro OZ6812/6872 PCI-CardBus
Bridge
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=79274
John Baldwin changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jhb at FreeBSD.org
Resolution|--- |Not Enough Information
Status|In Progress |Closed
--- Comment #7 from John Baldwin ---
There have been various changes in the PCI/cardbus layer since 2007. My
request for a complete verbose dmesg back in 2011 wasn't responded to. Without
that info this is not going to be fixed.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 1 21:59:25 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Apr 2015 21:59:25 +0000
Subject: [Bug 196724] fts(3) returns invalid fts_info for edge case
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196724
Jilles Tjoelker changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jilles at FreeBSD.org
Status|New |Open
--- Comment #1 from Jilles Tjoelker ---
When following symlinks, fts returns FTS_SLNONE when stat() fails, but a
subsequent lstat() succeeds (in recent versions fstatat() without and with
AT_SYMLINK_NOFOLLOW). This incorrectly triggers if a filename exists to be read
from the directory, is deleted before the stat and created again after the
stat.
Clearly, the code should only return FTS_SLNONE if S_ISLNK(sbp->st_mode). What
it should do otherwise is less clear. We could go back to stat() and try some
number of times for stat() and lstat() to become consistent, or we could return
FTS_NS immediately.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 1 23:02:49 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 01 Apr 2015 23:02:49 +0000
Subject: [Bug 199104] boot(8) build broken
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199104
Bug ID: 199104
Summary: boot(8) build broken
Product: Base System
Version: 10.1-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: heas at shrubbery.net
Building a custom boot(8) as in 26.6.3. Setting a Faster Serial Port Speed of
https://www.freebsd.org/doc/handbook/serialconsole-setup.html fails with
svn://svn0.us-west.freebsd.org/base/release/10.1.0 r280970:
# cd /sys/boot;make -j 8
Warning: Object directory not changed from original /src/10.1.0/sys/boot
....
building shared library userboot.so
cc: error: no such file or directory:
'/src/10.1.0/sys/boot/userboot/userboot/../zfs/libzfsboot.a'
*** [userboot.so] Error code 1
make[2]: stopped in /src/10.1.0/sys/boot/userboot/userboot
1 error
# make -C userboot/zfs libzfsboot.a
`libzfsboot.a' is up to date.
using symlink to libzfsboot:
===> userboot/userboot (all)
Warning: Object directory not changed from original
/src/10.1.0/sys/boot/userboot/userboot
building shared library userboot.so
/usr/bin/ld: i386 architecture of input file
`/src/10.1.0/sys/boot/userboot/userboot/../zfs/libzfsboot.a(zfs.o)' is
incompatible with i386:x86-64 output
/usr/bin/ld: warning: creating a DT_TEXTREL in a shared object.
cc: error: unable to execute command: Segmentation fault (core dumped)
cc: error: linker command failed due to signal (use -v to see invocation)
*** Error code 254
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 2 08:00:57 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Apr 2015 08:00:57 +0000
Subject: [Bug 199109] Regression seen with ncurses on 11-current
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199109
Bug ID: 199109
Summary: Regression seen with ncurses on 11-current
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: misc
Assignee: freebsd-bugs at FreeBSD.org
Reporter: marino at FreeBSD.org
I don't know if it was the last update to ncurses or an earlier one, but the
port devel/adacurses builds with base ncurses on FreeBSD 8,9,10 but not 11:
http://beefy2.isc.freebsd.org/bulk/head-amd64-default/2015-03-19_00h08m00s/logs/errors/adacurses-20110404_3.log
The port was previously using ncurses from ports, so the failures started after
switching to base ncurses.
Can somebody tell me if there is an unintended regression on base, or if
adacurses simply requires ncurses from ports now?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 2 08:01:34 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Apr 2015 08:01:34 +0000
Subject: [Bug 199109] Regression seen with ncurses on 11-current
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199109
John Marino changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bapt at FreeBSD.org,
| |delphij at FreeBSD.org
--- Comment #1 from John Marino ---
Adding the two developers involved with last update to ncurses in base.
--
You are receiving this mail because:
You are the assignee for the bug.
From new at campsalesaustralia.com Thu Apr 2 11:17:17 2015
From: new at campsalesaustralia.com (Camp Sales AU)
Date: Thu, 02 Apr 2015 21:17:07 +1000
Subject: CampSales eco Easter Sale:
Message-ID: <1168955403551d2533abfc4.1427973427@www.vision6.com.au>
[1]campsalesau
[solar.jpg]
250W Solar Panel
generator
Only
$220.00
Was $855.00
Buy Now
Our solar panels deliver outstanding performance even in challenging
environments, including low light conditions with the cells being
partly shaded. It also features a special... [2][read more]
Package Deal 4X
250W Solar Panels
generator
Only
$799.00
Was $3,420.00
Buy Now
Employed by cutting edge technology, the unique textured cell surface
reduces the reflection of sunlight and maximizes light absorption. The
advanced engineered cell structure further improves conversion...
[3][read more]
[4]www.campsalesau.com | Australia
This email was sent by Camp SalesAU, Sydney NSW Australia to
freebsd-bugs at freebsd.org
[5]Unsubscribe
References
Visible links
1. http://www.vision6.com.au/ch/44773/k7dh3/1895903/5fdb8tf5z.html
2. http://www.vision6.com.au/ch/44773/k7dh3/1909171/5fdb8p3s6-1.html
3. http://www.vision6.com.au/ch/44773/k7dh3/1909172/5fdb8mg6d-1.html
4. http://www.vision6.com.au/ch/44773/k7dh3/1895903/5fdb8tf5z-1.html
5. http://www.vision6.com.au/forms/u/f27839c/44773/16401213.html
Hidden links:
7. http://www.vision6.com.au/ch/44773/k7dh3/1909171/5fdb8p3s6.html
8. http://www.vision6.com.au/ch/44773/k7dh3/1909172/5fdb8mg6d.html
From bugzilla-noreply at freebsd.org Thu Apr 2 11:48:44 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Apr 2015 11:48:43 +0000
Subject: [Bug 199109] Regression seen with ncurses on 11-current
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199109
--- Comment #2 from John Marino ---
It turns out that I did have FreeBSD 11 (from October 2014), and the problem
was there then.
on FreeBSD 9:
> # grep is_keypad /usr/lib/libncurses.so
> binary file /usr/lib/libncurses.so matches
on FreeBSD 11:
nothing returns
on FreeBSD 9:
> # man curses | grep is_keypad
> is_keypad curs_opaque(3X)*
on FreeBSD 11:
> # man curses | grep is_keypad
> is_keypad curs_opaque(3X)*
(the same)
So it's in the man page, but not in the library
Chances are all 13 "curs_opaque(3X)" functions are missing.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 2 11:57:16 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Apr 2015 11:57:16 +0000
Subject: [Bug 199109] Regression seen with ncurses on 11-current
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199109
--- Comment #3 from John Marino ---
I suspect NCURSES_OPAQUE needs to be defined somewhere, and defined as "0".
On DragonFly it is handled here:
lib/libncurses/include/curses.head
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 2 15:48:08 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Apr 2015 15:48:07 +0000
Subject: [Bug 7802] [MFC] outbound, fragmented multicast packets are
mishandled at the data-link layer
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=7802
--- Comment #3 from commit-hook at freebsd.org ---
A commit references this bug:
Author: hselasky
Date: Thu Apr 2 15:47:38 UTC 2015
New revision: 280991
URL: https://svnweb.freebsd.org/changeset/base/280991
Log:
Extend fixes made in r278103 and r38754 by copying the complete packet
header and not only partial flags and fields. Firewalls can attach
classification tags to the outgoing mbufs which should be copied to
all the new fragments. Else only the first fragment will be let
through by the firewall. This can easily be tested by sending a large
ping packet through a firewall. It was also discovered that VLAN
related flags and fields should be copied for packets traversing
through VLANs. This is all handled by "m_dup_pkthdr()".
Regarding the MAC policy check in ip_fragment(), the tag provided by
the originating mbuf is copied instead of using the default one
provided by m_gethdr().
Tested by: Karim Fodil-Lemelin
MFC after: 2 weeks
Sponsored by: Mellanox Technologies
PR: 7802
Changes:
head/sys/netinet/ip_output.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 2 16:22:53 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Apr 2015 16:22:53 +0000
Subject: [Bug 199117] Kernel panic when iSCSI drops
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199117
Bug ID: 199117
Summary: Kernel panic when iSCSI drops
Product: Base System
Version: 10.1-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: rwestlun at gmail.com
I'm using iSCSI to connect to a remote drive over an SSH tunnel. When the
connection drops, I get a kernel panic and reboot. This has occurred three
times in the past three days.
dmesg:
WARNING: localhost (iqn.cryo): no ping reply (NOP-In) after 5 seconds;
reconnecting
WARNING: localhost (iqn.cryo): no ping reply (NOP-In) after 5 seconds;
reconnecting
Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0xffffffff802e1b6e
stack pointer = 0x28:0xfffffe0119c68ae0
frame pointer = 0x28:0xfffffe0119c68b10
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 0 (iscsimt)
trap number = 9
panic: general protection fault
cpuid = 0
KDB: stack backtrace:
#0 0xffffffff80963000 at kdb_backtrace+0x60
#1 0xffffffff80928125 at panic+0x155
#2 0xffffffff80d24f0f at trap_fatal+0x38f
#3 0xffffffff80d24b6c at trap+0x75c
#4 0xffffffff80d0a772 at calltrap+0x8
#5 0xffffffff81e43f47 at iscsi_session_terminate_task+0x57
#6 0xffffffff81e43ed0 at iscsi_session_cleanup+0x1c0
#7 0xffffffff81e43a78 at iscsi_maintenance_thread+0x58
#8 0xffffffff808f8b6a at fork_exit+0x9a
#9 0xffffffff80d0acae at fork_trampoline+0xe
Uptime: 15h46m39s
(da0:iscsi1:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00
(da0:iscsi1:0:0:0): CAM status: Command timeout
(da0:iscsi1:0:0:0): Error 5, Retries exhausted
(da0:iscsi1:0:0:0): Synchronize cache failed
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
Copyright (c) 1992-2014 The FreeBSD Project.
System info:
GENERIC kernel
uname -a
FreeBSD legion.textplain.net 10.1-RELEASE-p6 FreeBSD 10.1-RELEASE-p6 #0: Tue
Feb 24 19:00:21 UTC 2015
root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 2 17:00:39 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Apr 2015 17:00:39 +0000
Subject: [Bug 199075] mtree -F freebsd9 not consistent with fmtree
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199075
Thomas Quinot changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 2 17:08:33 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Apr 2015 17:08:33 +0000
Subject: [Bug 199119] libmd conflicts with libcrypto
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199119
Bug ID: 199119
Summary: libmd conflicts with libcrypto
Product: Base System
Version: 10.1-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: thomas at FreeBSD.org
libmd provides symbols that have the same name, but (presumably) are not
compatible, with libcrypto.
As a result, a program linked against libmd cannot connect to an LDAP server
using SSL, because libldap will resolve symbols in libmd, whereas it expects
those from libcrypto.
An annoying collateral is that crontab(1) will hang when using nss_ldap,
because it is linked against libmd to get MD5.
Various solutions are possible:
* link libmd statically in crontab(1)
* add -lcrypto before -lmd when linking crontab(1)
* make libmd symbols consistent (ABI-compatible) with those in libcrypto
* use different syumbol names in libmd to avoid the clash
* remove libmd symbols that duplicate functionality from libcrypto
* deprecate libmd altogether and use other hash functions from libcrypto.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 2 18:19:17 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Apr 2015 18:19:17 +0000
Subject: [Bug 183765] /boot/{menu,loader}.rc do not get updated by "make
installkernel"
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183765
Nikolai Lifanov changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |lifanov at mail.lifanov.com
--- Comment #5 from Nikolai Lifanov ---
Created attachment 155127
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155127&action=edit
remove menu.rc and loader.rc install guards
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 2 18:20:40 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Apr 2015 18:20:40 +0000
Subject: [Bug 183765] /boot/{menu,loader}.rc do not get updated by "make
installkernel"
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183765
--- Comment #6 from Nikolai Lifanov ---
Since r258270 try-include's menu.rc.local and loader.rc.local, the install
guards can go away. This will make installworld experience match that of
freebsd-update.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 2 19:11:31 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Apr 2015 19:11:31 +0000
Subject: [Bug 198163] Kernel panic in vm_reserv_populate()
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198163
--- Comment #9 from commit-hook at freebsd.org ---
A commit references this bug:
Author: alc
Date: Thu Apr 2 19:10:34 UTC 2015
New revision: 281001
URL: https://svnweb.freebsd.org/changeset/base/281001
Log:
MFC r280238
Fix the root cause of the "vm_reserv_populate: reserv is already
promoted" panics.
PR: 198163
Changes:
_U stable/10/
stable/10/sys/vm/vm_fault.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 2 21:36:28 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Apr 2015 21:36:28 +0000
Subject: [Bug 199127] rc.d/ntpd: user-set ntpd_flags stomps over rc-defined
ones (pidfile, driftfile)
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199127
Bug ID: 199127
Summary: rc.d/ntpd: user-set ntpd_flags stomps over rc-defined
ones (pidfile, driftfile)
Product: Base System
Version: 9.2-STABLE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: conf
Assignee: freebsd-bugs at FreeBSD.org
Reporter: jdc at koitsu.org
Issue:
Use of ntpd_flags in /etc/rc.conf results in completely broken behaviour when
ntpd starts. The most common issue is that there is no longer a pidfile
associated with ntpd, as well as other problems.
This is caused by a design/logic problem in etc/rc.d/ntpd which I have not yet
worked out. I am certain it must be easy/simple, and hoping someone in the
FreeBSD team can figure it out easier than I can.
Reproducing:
rc.conf contains following settings:
ntpd_enable="yes"
ntpd_config="/conf/ME/ntp.conf"
ntpd_sync_on_start="yes"
Process starts as:
/usr/sbin/ntpd -g -c /conf/ME/ntp.conf -p /var/run/ntpd.pid -f
/var/db/ntpd.drift
Add the following line to rc.conf:
ntpd_flags="-4"
Process starts as:
/usr/sbin/ntpd -g -c /conf/ME/ntp.conf -4
Note missing -p and -f. This causes lots of problems (like service/rc scripts
saying "ntpd: no such pid", etc.).
This is on a stable/9 system (9.3-STABLE, which is not a choice in the Bugzilla
pulldown for some reason). No idea if stable/10 has this fixed (haven't
looked, but if it has, it should be MFC'd).
Footnote: this may or may not somehow be related to Bug 106927.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 2 21:37:21 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Apr 2015 21:37:21 +0000
Subject: [Bug 199127] rc.d/ntpd: user-set ntpd_flags stomps over rc-defined
ones (pidfile, driftfile)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199127
Jeremy Chadwick changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|Affects Only Me |Affects Many People
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 2 21:37:36 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Apr 2015 21:37:36 +0000
Subject: [Bug 199127] rc.d/ntpd: user-set ntpd_flags stomps over rc-defined
ones (pidfile, driftfile)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199127
Jeremy Chadwick changed:
What |Removed |Added
----------------------------------------------------------------------------
Hardware|amd64 |Any
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 01:41:30 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 01:41:29 +0000
Subject: [Bug 199127] rc.d/ntpd: user-set ntpd_flags stomps over rc-defined
ones (pidfile, driftfile)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199127
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-rc at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 01:43:05 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 01:43:05 +0000
Subject: [Bug 199119] libmd conflicts with libcrypto
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199119
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|bin |kern
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 01:43:33 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 01:43:33 +0000
Subject: [Bug 199117] Kernel panic when iSCSI drops
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199117
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-scsi at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 01:44:21 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 01:44:21 +0000
Subject: [Bug 199109] Regression seen with ncurses on 11-current
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199109
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|misc |kern
Keywords| |regression
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 01:44:57 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 01:44:57 +0000
Subject: [Bug 199096] Kernel panic after some time using mpd (netgraph) and
ipfw
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199096
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-net at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 01:45:33 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 01:45:32 +0000
Subject: [Bug 199095] man page for oce driver have wrong line for loader.conf
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199095
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|kern |Documentation
Product|Base System |Documentation
Version|10.1-RELEASE |Latest
Assignee|freebsd-bugs at FreeBSD.org |freebsd-doc at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 06:52:03 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 06:52:03 +0000
Subject: [Bug 199136] [if_tap] Added down_on_close sysctl variable to tap(4)
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199136
Bug ID: 199136
Summary: [if_tap] Added down_on_close sysctl variable to tap(4)
Product: Base System
Version: 10.1-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: yuri at rawbw.com
Created attachment 155148
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155148&action=edit
patch
New variable down_on_close has two values:
* down_on_close=0: (default value) tap(4) will try to preserve the up state
when tap control device is closed, if it was up when in was opened. Both up
state and inet addresses are preserved.
* down_on_close=1: (previous behavior) always brings tap(4) interface down and
deletes all inet addresses.
The problem solved by this patch is that previously tap(4) interface was always
put into down state when control device was closed, and the user had to bring
it back up, and restore inet addresses again. This is particularly a problem
when VirtualBox VM connected to tap is restarted. The first time tapN could
have been configured by /etc/rc.conf, but subsequent runs required manual
reconfiguration of tap(0) interface. With the new default behavior tap(4) keeps
the state of the interface across open/close cycles.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 07:54:27 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 07:54:27 +0000
Subject: [Bug 199140] unlinking symlinks oddly slow on UFS
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199140
Bug ID: 199140
Summary: unlinking symlinks oddly slow on UFS
Product: Base System
Version: 9.3-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: sigsys at gmail.com
On a UFS2 filesystem with soft updates, deleting a directory of thousands of
symlinks is hundreds of times slower than deleting regular files.
It looks like the writes are synchronous.
$ mkdir test1 && for f in `seq 5000`; do touch "test1/$f"; done
$ mkdir test2 && for f in `seq 5000`; do echo test > "test2/$f"; done
$ mkdir test3 && for f in `seq 5000`; do ln -s test "test3/$f"; done
$ sync
$ time rm -r test1
0.20 real 0.01 user 0.17 sys
$ time rm -r test2
0.30 real 0.00 user 0.25 sys
$ time rm -r test3
94.73 real 0.02 user 0.72 sys
But if the symlinks are made large enough that their targets cannot be stored
in the inode directly, then unlinking them is fast!
$ test="$(perl -e 'print "x"x1023')"
$ mkdir test4 && for f in `seq 5000`; do ln -s "$test" "test4/$f"; done
$ time rm -r test4
0.17 real 0.00 user 0.17 sys
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 08:30:20 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 08:30:19 +0000
Subject: [Bug 199119] libmd conflicts with libcrypto
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199119
--- Comment #1 from Thomas Quinot ---
Created attachment 155151
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155151&action=edit
patch to avoid the symbol clash
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 08:51:17 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 08:51:17 +0000
Subject: [Bug 199119] libmd conflicts with libcrypto
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199119
--- Comment #2 from Thomas Quinot ---
Patch submitted for review:
https://reviews.freebsd.org/D2216
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 09:08:37 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 09:08:37 +0000
Subject: [Bug 199136] [if_tap] Added down_on_close sysctl variable to tap(4)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199136
yuri at rawbw.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #155148|0 |1
is obsolete| |
--- Comment #1 from yuri at rawbw.com ---
Created attachment 155152
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155152&action=edit
patch
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 09:47:10 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 09:47:10 +0000
Subject: [Bug 199136] [if_tap] Added down_on_close sysctl variable to tap(4)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199136
yuri at rawbw.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |mfc-stable10?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 10:19:34 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 10:19:33 +0000
Subject: [Bug 199144] [patch] ppp(8): spontaneous connectivity losses when
using MPPE in the stateless mode
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199144
Bug ID: 199144
Summary: [patch] ppp(8): spontaneous connectivity losses when
using MPPE in the stateless mode
Product: Base System
Version: 10.1-RELEASE
Hardware: Any
OS: Any
Status: New
Keywords: patch
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: alex at zagrebin.ru
Keywords: patch
Created attachment 155154
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155154&action=edit
patch
I'm using PPPoE connection to my ISP.
I've noticed, that there are spontaneous connectivity losses, when MPPE in
the stateless mode is used for data encryption. During such losses the ppp.log
contains a tons of messages like:
...
ppp[83292]: tun0: Phase: Unknown protocol 0xd198 (unrecognised protocol)
ppp[83292]: tun0: Phase: Unknown protocol 0xfbd7 (unrecognised protocol)
ppp[83292]: tun0: Phase: Unknown protocol 0x600e (unrecognised protocol)
ppp[83292]: tun0: Phase: Unknown protocol 0x4aef (unrecognised protocol)
ppp[83292]: tun0: Phase: Unknown protocol 0x2ed7 (unrecognised protocol)
ppp[83292]: tun0: Phase: Unknown protocol 0xc6a1 (unrecognised protocol)
ppp[83292]: tun0: Phase: Unknown protocol 0x4511 (unrecognised protocol)
ppp[83292]: tun0: Phase: Unknown protocol 0x0166 (unrecognised protocol)
ppp[83292]: tun0: Phase: Unknown protocol 0x36a2 (unrecognised protocol)
ppp[83292]: tun0: Phase: Unknown protocol 0xa294 (unrecognised protocol)
...
At the same time the ppp peers successfuly exchanges with a LCP keepalive
packets, so formally the link is alive and there is the one workaround only -
to restart ppp.
After doing some debugging I've found that this issue occurs because MPPE
keys, used for encryption/decryption, goes out of sync.
To ensure that a keys are synchronized, ppp tracks the coherency count,
which is a part of a MPPE-encrypted packet. When packet with an unexpected
coherency count is received, ppp assumes that some packets are lost and
performs a corresponding number of key changes to synchronize the key.
This approach works fine for serial link, but for PPPoE there is another
problem: packets reordering. For example: if packet with coherency count
N-1 is delayed and it was received after the packet with coherency count N,
then ppp will assume that 4094 packet are lost (a coherency count's size
is 12 bit) and will perform 4095 [unnecessary] key changes to synchronize key.
So the MPPE key goes out of sync.
To fix this issue I've written the patch (see attached file).
With this patch applied, ppp(8) distinguishes lost and delayed packets.
To have the chance to decrypt a delayed packets, it keeps small history
of MPPE keys (I think that 64 is a reasonable value).
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 10:26:11 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 10:26:11 +0000
Subject: [Bug 198772] Problem with pkg behind a chunking proxy
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198772
--- Comment #1 from sg-ball at laposte.net ---
The problem was discussed in mailing list at
https://lists.freebsd.org/pipermail/freebsd-pkg/2015-March/000979.html. It was
confirmed to be a bug and a patch
has been submitted.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 14:38:47 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 14:38:47 +0000
Subject: [Bug 197336] find command cannot see more than 32765 subdirectories
when using ZFS
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197336
--- Comment #5 from Jilles Tjoelker ---
Created attachment 155161
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155161&action=edit
fts(3) patch that disables the nlink optimization if st_nlink >= LINK_MAX
This patch disables the nlink optimization if st_nlink >= LINK_MAX (assuming
that the real link count may be higher than st_nlink in that case).
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 17:03:04 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 17:03:04 +0000
Subject: [Bug 199109] Regression seen with ncurses on 11-current
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199109
Xin LI changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|kern |bin
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 17:05:32 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 17:05:32 +0000
Subject: [Bug 199109] Regression seen with ncurses on 11-current
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199109
Xin LI changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rafan at FreeBSD.org
--- Comment #4 from Xin LI ---
(In reply to John Marino from comment #3)
These are in the header files.
I wonder if they should be defined as 1? Because the linker is complaining
about a missing symbol, it suggests the accessors are functions and not macros.
What's the side effect if we make the library NCURSES_OPAQUE? It sounds like
it doesn't change the ABI but will potentially break certain applications that
accesses the internals directly?
Adding rafan@ just in case.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 19:23:17 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 19:23:17 +0000
Subject: [Bug 199150] /etc/rc.d/pflog always emits "starting pflogd:"
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199150
Bug ID: 199150
Summary: /etc/rc.d/pflog always emits "starting pflogd:"
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: conf
Assignee: freebsd-bugs at FreeBSD.org
Reporter: lidl at pix.net
Whether or not pflogd is configured in the /etc/rc.conf
on a system, the /etc/rc.d/pflog script always emits
the line "starting pflogd: "
Really, this should only be output if $flog_instances is not empty.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 19:29:12 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 19:29:12 +0000
Subject: [Bug 196724] fts(3) returns invalid fts_info for edge case
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196724
Jilles Tjoelker changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |jilles at FreeBSD.org
--- Comment #2 from Jilles Tjoelker ---
Created attachment 155166
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155166&action=edit
don't return FTS_SLNONE if it's not a symlink (if race)
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 19:55:39 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 19:55:38 +0000
Subject: [Bug 199151] speed up pagezero assembly on Xeon
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199151
Bug ID: 199151
Summary: speed up pagezero assembly on Xeon
Product: Base System
Version: 11.0-CURRENT
Hardware: amd64
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: lidl at pix.net
Created attachment 155167
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155167&action=edit
diff to sys/amd64/amd64/support.S - pagezero function
The attached patch gives a consistant 1% decrease in system time when
doing something that forks a bunch of jobs, like buildworld or buildkernel,
when running with modestly high -j values (-j 24 or -j 32).
We have been running this in production for a couple of months.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 20:18:05 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 20:18:04 +0000
Subject: [Bug 196447] vi(1) misbehavior when encountered invalid Unicode
character
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196447
--- Comment #5 from lichray at gmail.com ---
Although not resolving this issue, FYI, the patch to prevent file truncation
upon writing is merged:
https://github.com/lichray/nvi2/commit/310d1e86c0b3db7f7e025e3092afc78e3d906fa2
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 3 21:49:25 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 03 Apr 2015 21:49:25 +0000
Subject: [Bug 199152] msdosfs writes on umount to readonly mounted fs
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199152
Bug ID: 199152
Summary: msdosfs writes on umount to readonly mounted fs
Product: Base System
Version: 10.1-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: longwitz at incore.de
Created attachment 155169
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155169&action=edit
Patch for msdosfs
In FreeBSD 10.1-STABLE #10 r279940 I see
mount -r /mydosfs
umount /mydosfs
umount: unmount of /mydosfs failed: Operation not permitted
On console: g_vfs_done():ada0p1[WRITE(offset=512, length=512)]error = 1
The next umount works.
This problem was introduced by rev 275638 to head, because in the case of a
readonly mounted msdosfs a call of msdosfs_sync() was introduced which failes
to write in msdos_fsiflush(). This happens because the flag MSDOSFS_FSIMOD is
set on the first call of msdosfs_sync().
The attached patch solves the problem for me and includes also some minor
changes necessary to build the kernel with MSDOS_DEBUG.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Apr 4 02:57:09 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 04 Apr 2015 02:57:09 +0000
Subject: [Bug 199136] [if_tap] Added down_on_close sysctl variable to tap(4)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199136
yuri at rawbw.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #155152|0 |1
is obsolete| |
--- Comment #2 from yuri at rawbw.com ---
Created attachment 155174
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155174&action=edit
patch
I went through several iterations, and updating the patch.
The meaning of IFF_DRV_RUNNING isn't clear in the tap driver, and its value is
currently inconsistent. If the interface goes down when device is open,
tapclose doesn't reset IFF_DRV_RUNNING. But I didn't touch it with this patch.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Apr 4 12:33:43 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 04 Apr 2015 12:33:42 +0000
Subject: [Bug 199151] speed up pagezero assembly on Xeon
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199151
Andriy Gapon changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #155167|0 |1
is patch| |
Attachment #155167|application/mbox |text/plain
mime type| |
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Apr 4 20:00:01 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 04 Apr 2015 20:00:01 +0000
Subject: [Bug 199165] UEFI issues
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199165
Bug ID: 199165
Summary: UEFI issues
Product: Base System
Version: 10.1-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: bstirling2307 at gmail.com
https://forums.freebsd.org/threads/uefi-boot-fail.51126/#post-286422
Howdy All,
I have been beating my head against the brick wall that is this issue for the
last few days. I have tried everything I can think of and everything I have
found on this forum and others. I will explain my goal and what I have
attempted.
Also this is the first time I am trying to install FreeBSD on an UEFI system
Goal:
Dual boot FreeBSD 10.1 and Windows 8.1 (required for work)
Boot manager: don't really care rEFInd, Grub2, ect
I am installing FreeBSD 10.1 using the
FreeBSD-10.1-RELEASE-amd64-uefi-memstick.img .
I am installing this on Asus X200MA-RCLT08
First installation attempt:
windows 8.1 working boots normally
Disabled secure boot
installed from usb and used UFS (GTP)
partition talble is:
100MB EFI -(windows UEFI)
900MB Recovery
128MB MS- Reserverd
186GB MS-basic-data
800KB EFI (FreeBSD)
144GB FreeBSD-UFS /
4GB FreeBSD-swap
Issue:
FreeBSD will not freaking boot!!!
UEFI dose not see the EFI partition created during installation.
It will boot if the install media is in the USB port it was in during
installation and that is selected from the UEFI boot menu. (note if it is not
in the USB port used during install, then the installation menu is booted)
Attempted resolutions:
I followed this guide
http://ximalas.info/2015/03/19/uefi-gpt-windows-10-freebsd-10-and-refind/
when I select freeBSD from the menu I get the attached error
Code:
Fatal trap 1 with interrupts dissabled
Fatal trap 1: privileged instruction fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0xffffff80400000
stack pointer = 0x28:0xffffff814b5a70
frame pointer = 0x28:0x0
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = resume, IOPL = 0
current process = 0 ()
trap number = 1
panic: privileged instruction fault
cpuid = 0
KDB: stack backtrace:
#0 0xffffffff80963000 at ??+0
#1 0xffffffff80928125 at ??+0
#2 0xffffffff80d24f1f at ??+0
#3 0xffffffff80d24b7c at ??+0
#4 0xffffffff80d0a782 at ??+0
Uptime: 1s
I then attempted to skip the 3rd party boot loader and mounted the windows ESP
again and copied the /boot/boot1.efi to /esp/efi/fbsd/bootx64.efi
I then in the system UEFI created boot entry pointing at /efi/fbsd/bootx64.efi
booted the system to the new entry and
Code:
Fatal trap 1 with interrupts dissabled
Fatal trap 1: privileged instruction fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0xffffff80400000
stack pointer = 0x28:0xffffff814b5a70
frame pointer = 0x28:0x0
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = resume, IOPL = 0
current process = 0 ()
trap number = 1
panic: privileged instruction fault
cpuid = 0
KDB: stack backtrace:
#0 0xffffffff80963000 at ??+0
#1 0xffffffff80928125 at ??+0
#2 0xffffffff80d24f1f at ??+0
#3 0xffffffff80d24b7c at ??+0
#4 0xffffffff80d0a782 at ??+0
Uptime: 1s
Again!!!
Second installation attempt:
Disabled secure boot
installed from usb and used UFS (GTP)
partition talble is:
800KB EFI (FreeBSD)
144GB FreeBSD-UFS /
4GB FreeBSD-swap
UEFI Sees the EFI Partition now: YAY (im hopeful; who needs wendooz anyway)
I boot the system and ... wait for it....
Code:
Fatal trap 1 with interrupts dissabled
Fatal trap 1: privileged instruction fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0xffffff80400000
stack pointer = 0x28:0xffffff814b5a70
frame pointer = 0x28:0x0
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = resume, IOPL = 0
current process = 0 ()
trap number = 1
panic: privileged instruction fault
cpuid = 0
KDB: stack backtrace:
#0 0xffffffff80963000 at ??+0
#1 0xffffffff80928125 at ??+0
#2 0xffffffff80d24f1f at ??+0
#3 0xffffffff80d24b7c at ??+0
#4 0xffffffff80d0a782 at ??+0
Uptime: 1s
FML
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 5 02:29:02 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Apr 2015 02:29:02 +0000
Subject: [Bug 199150] /etc/rc.d/pflog always emits "starting pflogd:"
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199150
jason.unovitch at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason.unovitch at gmail.com
--- Comment #1 from jason.unovitch at gmail.com ---
Created attachment 155192
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155192&action=edit
pflog patch
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 5 02:54:49 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Apr 2015 02:54:49 +0000
Subject: [Bug 199150] /etc/rc.d/pflog always emits "starting pflogd:"
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199150
--- Comment #2 from jason.unovitch at gmail.com ---
Thank for opening this. There is a bit more to the issue than just printing
the output you noted. For one, it breaks Puppet because Puppet is removing the
leading '#' markers and gets mixed up when it sees "Starting pflog" (ref [1]
lines 22-28).
I saw this a while ago and commented the 'echo' line out out but seeing the PR
on the mailing list reminded me I needed to to make a real patch. Sorry for
not opening this sooner, but it's still plenty early enough to get this in for
10.2-RELEASE and 11.0-RELEASE. The multiple instance support was implemented
in an earlier PR [2] and I just updated that PR with a request for the
submitter and committer to review this PR.
The fixed version is available with:
fetch -o /etc/rc.d/pflog
https://raw.githubusercontent.com/junovitch/my-freebsd-build/master/patches/PR199150.pflog
Test cases that show the expected output from the various `service pflog
` commands are below.
===== EXAMPLE OF PUPPET ISSUE =====
root at myrtr:/etc/rc.d # puppet agent --test
...
Error: /Stage[main]/Soekris::Service::Pf/Service[pflog]: Could not evaluate:
rcvar value is empty
===== POST-PATCH MULTIPLE PFLOG CONFIGURATION =====
/etc/rc.conf
pflog_enable="YES"
/etc/rc.conf.d/pflog
pflog_instances="pflog0 pflog1 pflog2"
pflog_pflog0_dev="pflog0"
pflog_pflog0_logfile="/var/log/pflog0"
pflog_pflog1_dev="pflog1"
pflog_pflog1_logfile="/var/log/pflog1"
pflog_pflog2_dev="pflog2"
pflog_pflog2_logfile="/var/log/pflog2"
===== POST-PATCH MULTIPLE PFLOG TEST CASES =====
root at myrtr:/etc/rc.d # service pflog start
Starting pflog0.
Starting pflog1.
Starting pflog2.
root at myrtr:/etc/rc.d # service pflog restart
Stopping pflog0.
Waiting for PIDS: 55175.
Starting pflog0.
Stopping pflog1.
Waiting for PIDS: 55826.
Starting pflog1.
Stopping pflog2.
Waiting for PIDS: 56253.
Starting pflog2.
root at myrtr:/etc/rc.d # service pflog rcvar
# pflog0
#
pflog_enable="YES"
# (default: "")
# pflog1
#
pflog_enable="YES"
# (default: "")
# pflog2
#
pflog_enable="YES"
# (default: "")
root at myrtr:/etc/rc.d # service pflog enabled
root at myrtr:/etc/rc.d # service pflog reload
root at myrtr:/etc/rc.d # service pflog resync
# (All display no output)
root at myrtr:/etc/rc.d # service pflog status
pflog0 is running as pid 57645.
pflog1 is running as pid 58831.
pflog2 is running as pid 60086.
root at myrtr:/etc/rc.d # service pflog poll
Waiting for PIDS: 57645
# ...
root at myrtr:/etc/rc.d # service pflog stop
Stopping pflog0.
Waiting for PIDS: 57645.
Stopping pflog1.
Waiting for PIDS: 58831.
Stopping pflog2.
Waiting for PIDS: 60086.
===== POST-PATCH SINGLE PFLOG CONFIGURATION =====
/etc/rc.conf
pflog_enable="YES"
===== POST-PATCH SINGLE PFLOG TEST CASES =====
root at myrtr:/etc/rc.d # service pflog start
Starting pflog.
root at myrtr:/etc/rc.d # service pflog restart
Stopping pflog.
Waiting for PIDS: 71252.
Starting pflog.
root at myrtr:/etc/rc.d # service pflog rcvar
# pflog
#
pflog_enable="YES"
# (default: "")
root at myrtr:/etc/rc.d # service pflog enabled
root at myrtr:/etc/rc.d # service pflog reload
root at myrtr:/etc/rc.d # service pflog resync
# (All display no output)
root at myrtr:/etc/rc.d # service pflog status
pflog is running as pid 72503.
root at myrtr:/etc/rc.d # service pflog poll
Waiting for PIDS: 72503
# ...
root at myrtr:/etc/rc.d # service pflog stop
Stopping pflog.
Waiting for PIDS: 72503.
===== REFERENCES =====
[1]
https://github.com/puppetlabs/puppet/blob/cb4ad1f19b043a70ba17e4103a25f5c97a76948b/lib/puppet/provider/service/freebsd.rb
[2] https://bugs.freebsd.org/158171
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 5 03:43:11 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Apr 2015 03:43:11 +0000
Subject: [Bug 199150] /etc/rc.d/pflog always emits "starting pflogd:"
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199150
Josh Paetzel changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jpaetzel at FreeBSD.org
Assignee|freebsd-bugs at FreeBSD.org |jpaetzel at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 5 04:13:18 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Apr 2015 04:13:18 +0000
Subject: [Bug 199151] speed up pagezero assembly on Xeon
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199151
Eitan Adler changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |eadler at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 5 10:05:35 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Apr 2015 10:05:34 +0000
Subject: [Bug 199169] [patch] zone "UMA Zone" has bigger size than need
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199169
Bug ID: 199169
Summary: [patch] zone "UMA Zone" has bigger size than need
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Keywords: patch
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: luke.tw at gmail.com
Keywords: patch
Created attachment 155194
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155194&action=edit
UMA Zones size patch
It calculates the size for per cpu cache with (mp_maxid + 1 ).
This allocates space with one extra struct uma_cache.
* before patch
% vmstat -z | grep Zone
UMA Zones: 1152, 0, 196, 2, 196, 0, 0
* after patch
% vmstat -z | grep Zone
UMA Zones: 1024, 0, 196, 2, 196, 0, 0
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 5 10:06:21 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Apr 2015 10:06:21 +0000
Subject: [Bug 199169] [patch] zone "UMA Zones" has bigger size than need
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199169
luke.tw at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[patch] zone "UMA Zone" has |[patch] zone "UMA Zones"
|bigger size than need |has bigger size than need
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 5 13:12:15 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Apr 2015 13:12:15 +0000
Subject: [Bug 199172] [patch] wrong KASSERT msg in uma_zone_set_fini/freef()
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199172
Bug ID: 199172
Summary: [patch] wrong KASSERT msg in uma_zone_set_fini/freef()
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Keywords: patch
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: luke.tw at gmail.com
Keywords: patch
Index: sys/vm/uma_core.c
===================================================================
--- sys/vm/uma_core.c (revision 281078)
+++ sys/vm/uma_core.c (working copy)
@@ -3060,7 +3060,7 @@ uma_zone_set_fini(uma_zone_t zone, uma_fini fini)
uma_keg_t keg;
keg = zone_first_keg(zone);
- KASSERT(keg != NULL, ("uma_zone_set_init: Invalid zone type"));
+ KASSERT(keg != NULL, ("uma_zone_set_fini: Invalid zone type"));
KEG_LOCK(keg);
KASSERT(keg->uk_pages == 0,
("uma_zone_set_fini on non-empty keg"));
@@ -3100,7 +3100,7 @@ uma_zone_set_freef(uma_zone_t zone, uma_free freef
uma_keg_t keg;
keg = zone_first_keg(zone);
- KASSERT(keg != NULL, ("uma_zone_set_init: Invalid zone type"));
+ KASSERT(keg != NULL, ("uma_zone_set_freef: Invalid zone type"));
KEG_LOCK(keg);
keg->uk_freef = freef;
KEG_UNLOCK(keg);
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 5 13:28:24 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Apr 2015 13:28:24 +0000
Subject: [Bug 199174] em tx and rx hang
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174
Bug ID: 199174
Summary: em tx and rx hang
Product: Base System
Version: 10.1-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: david.keller at litchis.fr
Hi,
While sending moderated nfs traffic < 2Mo/s, the interface suddenly stopped
transmitting/receiving.
However the interface seemed fine:
$ ifconfig
em0: flags=8843 metric 0 mtu 9000
options=4219b
ether 00:25:90:34:5d:44
inet YYYY netmask 0xffffff00 broadcast YYY.255
inet6 fe80::225:90ff:fe34:5d44%em0 prefixlen 64 scopeid 0x1
inet6 XXXX prefixlen 64 autoconf
nd6 options=23
media: Ethernet autoselect (1000baseT )
status: active
Pinging gateway didn't work:
$ ping ZZZZ
PING ZZZZ (ZZZZ): 56 data bytes
ping: sendto: Host is down
ping: sendto: Host is down
But driver seemed happy with the card as no particular message was printed.
# tcpdump -ni em0
-> No rx traffic, only tx.
Printing em driver internal variables was more interesting:
$ sysctl dev.em.0.debug=1
Interface is RUNNING and ACTIVE
em0: hw tdh = 325, hw tdt = 166
em0: hw rdh = 688, hw rdt = 687
em0: Tx Queue Status = 1
em0: TX descriptors avail = 150
em0: Tx Descriptors avail failure = 0
em0: RX discarded packets = 0
em0: RX Next to Check = 688
em0: RX Next to Refresh = 687
Sending PING request incremented hw tdt as expected. Wondering what would
happen when it would reach tdh value, I ping-flooded the gateway.
Driver figured out something was going bad and reset the card:
#ping -f ZZZZ
em0: Watchdog timeout -- resetting
em0: Queue(0) tdh = 325, hw tdt = 285
em0: TX(0) desc avail = 31,Next TX to Clean = 316
em0: link state changed to DOWN
em0: link state changed to UP
Interface is RUNNING and ACTIVE
em0: hw tdh = 113, hw tdt = 113
em0: hw rdh = 36, hw rdt = 35
em0: Tx Queue Status = 0
em0: TX descriptors avail = 1024
em0: Tx Descriptors avail failure = 0
em0: RX discarded packets = 0
em0: RX Next to Check = 36
em0: RX Next to Refresh = 35
>From here, the interface was working as usual.
$ ping ZZZZ
PING ZZZZ (ZZZZ): 56 data bytes
64 bytes from ZZZZ: icmp_seq=0 ttl=255 time=0.241 ms
$dmesg
FreeBSD 10.1-RELEASE-p6 #0: Tue Feb 24 19:00:21 UTC 2015
[...]
em0: port 0xdc00-0xdc1f mem
0xfe9e0000-0xfe9fffff,0xfe9dc000-0xfe9dffff irq 16 at device 0.0 on pci2
em0: Using MSIX interrupts with 3 vectors
em0: Ethernet address: 00:25:90:34:5d:44
pcib3: irq 16 at device 28.5 on pci0
pci3: on pcib3
em1: port 0xec00-0xec1f mem
0xfeae0000-0xfeafffff,0xfeadc000-0xfeadffff irq 17 at device 0.0 on pci3
em1: Using MSIX interrupts with 3 vectors
em1: Ethernet address: 00:25:90:34:5d:45
$pciconf -elv
[...]
em0 at pci0:2:0:0: class=0x020000 card=0x060a15d9 chip=0x10d38086 rev=0x00
hdr=0x00
vendor = 'Intel Corporation'
device = '82574L Gigabit Network Connection'
class = network
subclass = ethernet
PCI-e errors = Correctable Error Detected
Unsupported Request Detected
Corrected = Receiver Error
Bad TLP
Bad DLLP
REPLAY_NUM Rollover
Replay Timer Timeout
Advisory Non-Fatal Error
em1 at pci0:3:0:0: class=0x020000 card=0x060a15d9 chip=0x10d38086 rev=0x00
hdr=0x00
vendor = 'Intel Corporation'
device = '82574L Gigabit Network Connection'
class = network
subclass = ethernet
PCI-e errors = Correctable Error Detected
Unsupported Request Detected
Corrected = Receiver Error
Bad TLP
Bad DLLP
Replay Timer Timeout
Advisory Non-Fatal Error
The port is connected to a GS108 switch. Link was up the whole time and no
transmit error has been detected.
Motherboard is a Supermicro X7SPA-HF with latest bios.
On this board, there is a BMC sharing the em0 port. The BMC was not responding
either.
Hence my lucky guess would be that it may not be the driver fault as the BMC
has suffered too, but the card fault.
This is also happening on an OpenBSD em0 with the same motherboard (but not
connected to the same switch).
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 5 14:53:22 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Apr 2015 14:53:22 +0000
Subject: [Bug 199174] em tx and rx hang
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174
--- Comment #1 from david.keller at litchis.fr ---
The card is definitely not sending:
1) dev.em.0.queue0.tx_irq is *not* increasing, so no signal from the card that
data has been sent
2) hence sysctl dev.em.0.debug=1 shows that TX descriptors avail is decreasing
3) when it drops bellow EM_MAX_SCATTER, em_txeof() is finally called:
https://svnweb.freebsd.org/base/releng/10.1/sys/dev/e1000/if_em.c?view=markup#l962
4) em_txoef() examines descriptors and detects that the card has not processed
any of them and marks the queue as EM_QUEUE_HUNG:
https://svnweb.freebsd.org/base/releng/10.1/sys/dev/e1000/if_em.c?view=markup#l3925
5) The queue status is read and the card reset is performed:
https://svnweb.freebsd.org/base/releng/10.1/sys/dev/e1000/if_em.c?view=markup#l2297
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 5 14:59:31 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Apr 2015 14:59:31 +0000
Subject: [Bug 199174] em tx and rx hang
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174
--- Comment #2 from david.keller at litchis.fr ---
Created attachment 155199
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155199&action=edit
sysctl dev.em.0
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 5 16:50:53 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Apr 2015 16:50:53 +0000
Subject: [Bug 199169] [patch] zone "UMA Zones" has bigger size than need
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199169
Dmitry Chagin changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dchagin at FreeBSD.org
--- Comment #1 from Dmitry Chagin ---
hm, mp_maxid is a max cpu id. on my 8 threaded cpu mp_maxid is 7.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 5 18:26:06 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Apr 2015 18:26:06 +0000
Subject: [Bug 199172] [patch] wrong KASSERT msg in uma_zone_set_fini/freef()
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199172
--- Comment #1 from commit-hook at freebsd.org ---
A commit references this bug:
Author: dchagin
Date: Sun Apr 5 18:25:24 UTC 2015
New revision: 281113
URL: https://svnweb.freebsd.org/changeset/base/281113
Log:
Fix wrong kassert msg in uma.
PR: 199172
Submitted by: luke.tw gmail com
MFC after: 1 week
Changes:
head/sys/vm/uma_core.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at FreeBSD.org Sun Apr 5 21:00:18 2015
From: bugzilla-noreply at FreeBSD.org (bugzilla-noreply at FreeBSD.org)
Date: Sun, 05 Apr 2015 21:00:18 +0000
Subject: Problem reports for freebsd-bugs@FreeBSD.org that need special
attention
Message-ID: <201504052100.t35L0IiS073282@kenobi.freebsd.org>
To view an individual PR, use:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.
Status | Bug Id | Description
------------+-----------+---------------------------------------------------
In Progress | 196973 | sh(1) broken UTF-8 input
New | 198797 | [PATCH] Added an option to install BSDstats to bs
Open | 90114 | [patch] pw(8) takes strings after option -g for G
Open | 155028 | init(8): "init q" in single user causes segfault
Open | 156481 | [kernel] [patch] kernel incorrectly reports PPS j
Open | 165630 | [ndis][panic][patch] IRQL_NOT_GREATER_THAN
Open | 167133 | stale files in /usr/share/examples
Open | 169471 | [patch] pw(8) deletes group "username" on userdel
Open | 171779 | [patch] passwd(1): make option NO_FSCHG incomplet
Open | 184681 | A bug of bsdconfig(8) in 10.0 RC1
Open | 191511 | opiepasswd(1) segfaults with a seed length > 12
In Progress | 191348 | [mps] LSI2308 with WD3000FYYZ drives disappears a
12 problems total for which you should take action.
From bugzilla-noreply at freebsd.org Sun Apr 5 21:08:18 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Apr 2015 21:08:18 +0000
Subject: [Bug 199152] msdosfs writes on umount to readonly mounted fs
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199152
--- Comment #1 from commit-hook at freebsd.org ---
A commit references this bug:
Author: kib
Date: Sun Apr 5 21:08:05 UTC 2015
New revision: 281120
URL: https://svnweb.freebsd.org/changeset/base/281120
Log:
Assert that an msdosfs mount is not read-only when FAT modifications
are requested.
PR: 199152
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Changes:
head/sys/fs/msdosfs/msdosfs_fat.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 5 21:11:20 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Apr 2015 21:11:20 +0000
Subject: [Bug 199152] msdosfs writes on umount to readonly mounted fs
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199152
--- Comment #2 from commit-hook at freebsd.org ---
A commit references this bug:
Author: kib
Date: Sun Apr 5 21:10:39 UTC 2015
New revision: 281121
URL: https://svnweb.freebsd.org/changeset/base/281121
Log:
Do not call msdosfs_sync() on the read-only msdosfs mounts. In fact,
it should be a nop for ro.
PR: 199152
Reviewed by: bde (PR version of the patch)
Submitted by: longwitz at incore.de
MFC after: 1 week
Changes:
head/sys/fs/msdosfs/msdosfs_vfsops.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 5 21:14:20 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Apr 2015 21:14:19 +0000
Subject: [Bug 199152] msdosfs writes on umount to readonly mounted fs
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199152
--- Comment #3 from Konstantin Belousov ---
(In reply to longwitz from comment #0)
The msdosfs_unmount() chunk is committed, with minor editing around.
I also committed the assertions to verify your claim that MSDOSFS_FSIMOD flag
was set. Please re-test with only r281120 applied. I cannot reproduce the
issue locally, using ro file-backed md volume. I want to see the backtrace for
the moment where FSIMOD flag is set.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 5 22:32:38 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 05 Apr 2015 22:32:38 +0000
Subject: [Bug 199189] SWAP on ZFS can crash server
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199189
Bug ID: 199189
Summary: SWAP on ZFS can crash server
Product: Base System
Version: 10.1-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: vermaden at interia.pl
Running swap on zvol is a bad idea, because it will eventually crash the server
when trashing happens.
You can simulate the trashing by running the following Perl script, it will
eventually fill up all your available memory.
===============================================================================
#!/usr/bin/perl
my $count=0;
my @data;
my $temp_data;
for(my $i=0;$i<10000000;$i++) {
$temp_data.="1234567890abcdefghijklmnopqrstuvwxyz";
}
while(1) {
$data[$count++]=$temp_data;
}
===============================================================================
Tested on FreeBSD 10.1 stable
With zvol swap - 8 GB RAM FreeBSD server will stall within 1 minutes.
without swap or dedicated swap disk/partition - server will automatically kill
that Perl process.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 6 00:48:46 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Apr 2015 00:48:45 +0000
Subject: [Bug 199174] em tx and rx hang
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174
--- Comment #3 from david.keller at litchis.fr ---
Regarding RX:
sysctl dev.em.0.mac_stats.total_pkts_recvd *is* increasing
sysctl dev.em.0.mac_stats.good_pkts_recvd *isn't*
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 6 03:32:19 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Apr 2015 03:32:18 +0000
Subject: [Bug 199191] Allow _.disk.image name to be specified
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199191
Bug ID: 199191
Summary: Allow _.disk.image name to be specified
Product: Base System
Version: 10.1-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: misc
Assignee: freebsd-bugs at FreeBSD.org
Reporter: ask at develooper.com
I build several slightly different images from my nanobsd build; this small
patch makes it faster. The change makes a tiny bit more sense with an optional
option to create_image to specify a suffix for the log file. I'm not sure if
it's worth including though.
--- /usr/gsrc/freebsd/tools/tools/nanobsd/nanobsd.sh 2014-12-14
06:36:35.000000000 +0000
+++ /x/nanobsd/nanobsd.sh 2015-04-05 16:06:22.000000000 +0000
@@ -66,6 +66,7 @@
# The default name for any image we create.
NANO_IMGNAME="_.disk.full"
+NANO_IMG1NAME="_.disk.image"
# Options to put in make.conf during buildworld only
CONF_BUILD=' '
@@ -650,8 +654,8 @@
fi
if ${do_copyout_partition} ; then
- echo "Writing out _.disk.image..."
- dd conv=sparse if=/dev/${MD}s1 of=${NANO_DISKIMGDIR}/_.disk.image
bs=64k
+ echo "Writing out ${NANO_IMG1NAME}_..."
+ dd conv=sparse if=/dev/${MD}s1 of=${NANO_DISKIMGDIR}/${NANO_IMG1NAME}
bs=64k
fi
mdconfig -d -u $MD
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 6 03:35:08 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Apr 2015 03:35:07 +0000
Subject: [Bug 199169] [patch] zone "UMA Zones" has bigger size than need
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199169
--- Comment #2 from luke.tw at gmail.com ---
hi, Dmitry,
Thanks for your feedback.
That's right, but there is already one uma_cache in the struct uma_zone.
Let me do an experiment on sleepq_zone.
I have 4-core cpu and the mp_maxid is 3.
(kgdb) p mp_maxid
$1 = 3
The size of all per-cpu cache in sleepq_zone is 640 bytes.
(kgdb) p sleepq_zone
$2 = 0xfffff80002bb8000
(kgdb) p sleepq_zone->uz_cpu
$3 = 0xfffff80002bb8200
(kgdb) p masterzone_z->uz_size - (0xfffff80002bb8200 - 0xfffff80002bb8000)
$4 = 640
So, there are total 5 elements in the uz_cpu array
(kgdb) p 640 / sizeof(struct uma_cache)
$5 = 5
Only the first 4 elements are used.
(kgdb) p sleepq_zone->uz_cpu[0]
$6 = {uc_freebucket = 0x0, uc_allocbucket = 0xfffff80002bb1c00, uc_allocs = 73,
uc_frees = 0}
(kgdb) p sleepq_zone->uz_cpu[1]
$7 = {uc_freebucket = 0x0, uc_allocbucket = 0xfffff8000516a800, uc_allocs = 18,
uc_frees = 0}
(kgdb) p sleepq_zone->uz_cpu[2]
$8 = {uc_freebucket = 0x0, uc_allocbucket = 0xfffff80004747c00, uc_allocs = 18,
uc_frees = 0}
(kgdb) p sleepq_zone->uz_cpu[3]
$9 = {uc_freebucket = 0x0, uc_allocbucket = 0xfffff800047a1c00, uc_allocs = 36,
uc_frees = 0}
(kgdb) p sleepq_zone->uz_cpu[4]
$10 = {uc_freebucket = 0x0, uc_allocbucket = 0x0, uc_allocs = 0, uc_frees = 0}
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 6 15:28:40 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Apr 2015 15:28:40 +0000
Subject: [Bug 199197] FreeBSD should be able to PXE boot directly from ISO file
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199197
Bug ID: 199197
Summary: FreeBSD should be able to PXE boot directly from ISO
file
Product: Base System
Version: 9.1-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: will at FreeBSD.org
Since 9.0+, FreeBSD has not been able to PXE boot directly from an ISO file.
The kernel will start (having been set up by the loader), but multiuser will
fail because the ISO image was only accessible in protected memory, before the
kernel booted.
It should be copied as a linker file for the kernel to reference, and then geom
should be modified to try to attach to linker files (at least this particular
one), enabling iso9660 tasting to work and therefore mountroot.
I have done some work along these lines, but was not able to finish before
switching to other work. If anyone wants to try to fix it this way (there may
be other ways I'm not aware of), let me know and I will dig the patch out from
the sands of time.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 6 17:06:59 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Apr 2015 17:06:59 +0000
Subject: [Bug 199169] [patch] zone "UMA Zones" has bigger size than need
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199169
--- Comment #3 from Dmitry Chagin ---
(In reply to luke.tw from comment #2)
Yes, I see.
It would be nice to add db_show_zone DDB method and use a now unused
uma_print_zone with their counterparts.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 6 18:46:09 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Apr 2015 18:46:08 +0000
Subject: [Bug 199169] [patch] zone "UMA Zones" has bigger size than need
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199169
--- Comment #4 from commit-hook at freebsd.org ---
A commit references this bug:
Author: dchagin
Date: Mon Apr 6 18:45:42 UTC 2015
New revision: 281162
URL: https://svnweb.freebsd.org/changeset/base/281162
Log:
Properly calculate "UMA Zones" per cpu cache size. Avoid allocating
an extra struct uma_cache since the struct uma_zone already has one.
PR: 199169
Submitted by: luke.tw gmail com
MFC after: 1 week
Changes:
head/sys/vm/uma_core.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 6 19:09:22 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Apr 2015 19:09:22 +0000
Subject: [Bug 199252] Fatal trap 12: page fault while in kernel mode
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199252
Bug ID: 199252
Summary: Fatal trap 12: page fault while in kernel mode
Product: Base System
Version: 10.1-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: tio.madrid at hotmail.com
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xfffffffff5555570
fault code = supervisor write data, page not present
instruction pointer = 0x20:0xffffffff80d348e4
stack pointer = 0x28:0xfffffe004f71b5d0
frame pointer = 0x28:0xfffffe004f71b5e0
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 38133 (sh)
--
You are receiving this mail because:
You are the assignee for the bug.
From jhb at freebsd.org Mon Apr 6 19:19:26 2015
From: jhb at freebsd.org (John Baldwin)
Date: Mon, 06 Apr 2015 14:35:30 -0400
Subject: How to know the system state if the system is going for halt or
poweroff or reboot in FreeBSD
In-Reply-To:
References:
Message-ID: <3069256.iCnUzzNb56@ralph.baldwin.cx>
On Thursday, March 26, 2015 01:54:45 AM Sibananda Sahu wrote:
> My requirement is to know the exact reason of shutdown, whether is it a
> power-off or a reboot call.
>
> And I can get the information from the ?howto? variable that is passed to
> the kern_reboot() function call, but this variable is local to
> kern_reboot() only.
It is passed to the shutdown_* eventhandlers. So if you register an eventhandler
you can get the howto argument that way. ACPI uses this to power off the machine
for a power off request for example:
static void
acpi_shutdown_final(void *arg, int howto)
{
...
if ((howto & RB_POWEROFF) != 0) {
status = AcpiEnterSleepStatePrep(ACPI_STATE_S5);
}
--
John Baldwin
From bugzilla-noreply at freebsd.org Mon Apr 6 21:05:15 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Apr 2015 21:05:16 +0000
Subject: [Bug 199174] em tx and rx hang
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174
--- Comment #4 from david.keller at litchis.fr ---
While the interace is not responding, dev.em.0.link_irq is incremented every
second.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 7 08:03:58 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Apr 2015 08:03:58 +0000
Subject: [Bug 199169] [patch] zone "UMA Zones" has bigger size than need
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199169
Dmitry Chagin changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|New |In Progress
Assignee|freebsd-bugs at FreeBSD.org |dchagin at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 7 08:04:45 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Apr 2015 08:04:45 +0000
Subject: [Bug 199172] [patch] wrong KASSERT msg in uma_zone_set_fini/freef()
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199172
Dmitry Chagin changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|New |In Progress
CC| |dchagin at FreeBSD.org
Assignee|freebsd-bugs at FreeBSD.org |dchagin at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 7 12:50:57 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Apr 2015 12:50:56 +0000
Subject: [Bug 188833] [suspend/resume] Suspend/resume with Intel GMA HD 4000:
AIGLX fails to restart
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188833
--- Comment #3 from Bengt Ahlgren ---
Created attachment 155303
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155303&action=edit
xf86-video-intel batch buffer retry patch
It would be great if the simple patch by Jan Kokem?ller that Ivan points to
could be added to x11-drivers/xf86-video-intel/files! I'm attaching that patch
for easy access. I have been using this patch on a TP X201 for quite some time.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 7 13:02:24 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Apr 2015 13:02:23 +0000
Subject: [Bug 188833] [suspend/resume] Suspend/resume with Intel GMA HD 4000:
AIGLX fails to restart
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188833
Bengt Ahlgren changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |maintainer-feedback?(x11 at Fr
| |eeBSD.org)
CC| |x11 at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 7 14:50:45 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Apr 2015 14:50:45 +0000
Subject: [Bug 198062] FreeBSD 10.1-RELEASE kernel freezes on 'pci0: on pcib0'
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198062
--- Comment #6 from Joseph King ---
9.3-Release 64bit works fine.
10.0-Release 64bit fails at same place at 10.1-Release 64bit.
10.1-Release 64bit fails the same as noted by gmc at metro.cx
10.1-Release 32bit works however need 64 bit due to amount of memory installed
in system being greater than 3gb.
System that I am using is a Tyan Transport GT24 B3992 Model B3992G24V4H.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 7 22:17:54 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Apr 2015 22:17:54 +0000
Subject: [Bug 199152] msdosfs writes on umount to readonly mounted fs
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199152
longwitz at incore.de changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |longwitz at incore.de
--- Comment #4 from longwitz at incore.de ---
Your assertions from r281120 did not trigger. I found the flag FSIMOD is set in
usemap_free() called from fillinusemap(), which is called from mountmsdosfs()
but before the MSDOSFSMNT_RONLY flag is set. Thats the reason why your
assertion is missed. At the begin of the "for (cn = CLUST_FIRST .." loop in
fillinusemap() I see pm_flags=0x20000000 and pm_maxcluster=98305. After the
loop I have pm_flags=0x21000000 and usemap_free() was called 79356 times,
enough to set the FSIMOD bit.
The first install of my test maschine was Windows 7 mit UEFI, I boot FreeBSD 10
Stable with PXE, because my motherboard (Gigabyte hGA-A75M-UD2H) has the
problem described in PR/193646 and FreeBSD hangs on EFI boot. My test msdosfs
partition is the EFI partition installed by Windows 7 and is 100 MB in size.
For clarification the output of "gpart show":
=> 34 234441581 ada0 GPT (112G)
34 2014 - free - (1.0M)
2048 204800 1 efi (100M)
206848 262144 2 ms-reserved (128M)
468992 182771712 3 ms-basic-data (87G)
183240704 1024 4 freebsd-boot (512K)
183241728 2097152 5 freebsd-ufs (1.0G)
185338880 8388608 6 freebsd-swap (4.0G)
193727488 8388608 7 freebsd-ufs (4.0G)
202116096 16777216 8 freebsd-ufs (8.0G)
218893312 15548302 9 freebsd-ufs (7.4G)
234441614 1 - free - (512B)
If you need more information let me know.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 8 01:08:11 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Apr 2015 01:08:11 +0000
Subject: [Bug 199278] Process building disk1.iso fails when PORTS_MODULES is
set in /etc/make.conf
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199278
Bug ID: 199278
Summary: Process building disk1.iso fails when PORTS_MODULES is
set in /etc/make.conf
Product: Base System
Version: 10.1-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: misc
Assignee: freebsd-bugs at FreeBSD.org
Reporter: yuri at rawbw.com
Every time when I have PORTS_MODULES in /etc/make.conf, like this:
> PORTS_MODULES=emulators/virtualbox-ose-kmod multimedia/cuse4bsd-kmod x11/nvidia-driver
disk1.iso building process always fails:
> cd /usr/src/release
> make NODOC=YES disc1.iso
This is a problem for people who want to build iso on their local system, and
maybe not an important problem for the dedicated build server.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 8 07:01:39 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Apr 2015 07:01:39 +0000
Subject: [Bug 191348] [mps] LSI2308 with WD3000FYYZ drives disappears after
hotswapping
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191348
--- Comment #17 from Karli.Sjoberg at slu.se ---
Hi!
Any chance to see this MFC'd soon?
>From the svnweb link it says to MFC after two weeks and it?s been six weeks
(2015-04-08) already so...
Best Regards
Karli Sj?berg
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 8 08:17:17 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Apr 2015 08:17:17 +0000
Subject: [Bug 199287] Missing TCP retransmit timer reset
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199287
Bug ID: 199287
Summary: Missing TCP retransmit timer reset
Product: Base System
Version: 9.3-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: sebastian.huber at embedded-brains.de
There is a potential problem in the TCP implementation. I don't use FreeBSD
directly, instead I use a port of the FreeBSD 9.3 network stack to the RTEMS
real-time operating system. Nonetheless, this problem might exist in the real
FreeBSD system.
During tests under heavy load conditions the following situation occurred. I
transfer data from my development hosts /dev/zero to the targets (RTEMS running
the FreeBSD network stack) /dev/null via TCP. Thus the target sends only ACKs
after the TCP connection setup. The interface driver uses an equal count for
the rx and tx DMA descriptors. I use a small value to provoke packet loss at
the rx side. This packet loss is dealt via SACK, so the transfer rate is
nearly constant and at a high level for the target. In this setup the tx queue
overflows occasionally, thus in ip_output() we end up at
/*
* Verify that we have any chance at all of being able to queue the
* packet or packet fragments, unless ALTQ is enabled on the given
* interface in which case packetdrop should be done by queueing.
*/
n = ip->ip_len / mtu + 1; /* how many fragments ? */
if (
#ifdef ALTQ
(!ALTQ_IS_ENABLED(&ifp->if_snd)) &&
#endif /* ALTQ */
(ifp->if_snd.ifq_len + n) >= ifp->if_snd.ifq_maxlen ) {
error = ENOBUFS;
IPSTAT_INC(ips_odropped);
ifp->if_snd.ifq_drops += n;
goto bad;
}
and return ENOBUFS. This leads to tcp_ouput()
out:
SOCKBUF_UNLOCK_ASSERT(&so->so_snd); /* Check gotos. */
switch (error) {
case EPERM:
tp->t_softerror = error;
return (error);
case ENOBUFS:
if (!tcp_timer_active(tp, TT_REXMT) &&
!tcp_timer_active(tp, TT_PERSIST))
tcp_timer_activate(tp, TT_REXMT, tp->t_rxtcur);
tp->snd_cwnd = tp->t_maxseg;
return (0);
So here we start the retransmit timer. An occasional drop of ACK-only packets
doesn't hurt in this scenario so we don't observe any problems and on the rx
side we nearly always end up in tcp_do_segment() with tlen != 0
/*
* Header prediction: check for the two common cases
* of a uni-directional data xfer. If the packet has
* no control flags, is in-sequence, the window didn't
* change and we're not retransmitting, it's a
* candidate. If the length is zero and the ack moved
* forward, we're the sender side of the xfer. Just
* free the data acked & wake any higher level process
* that was blocked waiting for space. If the length
* is non-zero and the ack didn't move, we're the
* receiver side. If we're getting packets in-order
* (the reassembly queue is empty), add the data to
* the socket buffer and note that we need a delayed ack.
* Make sure that the hidden state-flags are also off.
* Since we check for TCPS_ESTABLISHED first, it can only
* be TH_NEEDSYN.
*/
if (tp->t_state == TCPS_ESTABLISHED &&
th->th_seq == tp->rcv_nxt &&
(thflags & (TH_SYN|TH_FIN|TH_RST|TH_URG|TH_ACK)) == TH_ACK &&
tp->snd_nxt == tp->snd_max &&
tiwin && tiwin == tp->snd_wnd &&
((tp->t_flags & (TF_NEEDSYN|TF_NEEDFIN)) == 0) &&
LIST_EMPTY(&tp->t_segq) &&
((to.to_flags & TOF_TS) == 0 ||
TSTMP_GEQ(to.to_tsval, tp->ts_recent)) ) {
In this path the retransmit timer is never reset, so in the end the connection
is dropped by tcp_timer_rexmt() even though there is no real connection
problem.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 8 22:31:21 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Apr 2015 22:31:21 +0000
Subject: [Bug 199109] Regression seen with ncurses on 11-current
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199109
--- Comment #5 from John Marino ---
I thought they were opaque, which is why the symbols were missing.
Setting it to "0" would make them not opaque.
However, bapt seemed to say that this was set to "0" already.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 9 00:12:36 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Apr 2015 00:12:36 +0000
Subject: [Bug 199174] em tx and rx hang
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174
--- Comment #5 from david.keller at litchis.fr ---
Let's keep up with the digging.
When hung, the 82574 generates link interrupts at a rate of ~1/s.
The first ICR read value by the link interrupt routine is 0x800000c5
.
Then *every* ICR read value is 0x40 .
TXDW:
Transmit Descriptor Written Back
Set when hardware processes a descriptor with RS set. If using
delayed interrupts (IDE set), the interrupt is delayed until after one of
the delayed-timers (TIDV or TADV) expires.
LSC:
Link Status Change
This bit is set whenever the link status changes (either from up to
down, or from down to up). This bit is affected by the link indication
from the PHY.
RXO:
Receiver Overrun
Set on receive data FIFO overrun. Could be caused either because
there are no available buffers or because PCIe receive bandwidth is
inadequate
RXT0:
Receiver Timer Interrupt
Set when the timer expires.
INT_ASSRTED:
Interrupt Asserted
This bit is set when the LAN port has a pending interrupt. If the
interrupt is enabled in the PCI configuration space, an interrupt is
asserted.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 9 00:24:59 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Apr 2015 00:24:59 +0000
Subject: [Bug 199304] minor bug in /usr/src/sys/netinet6/nd6_nbr.c
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199304
Bug ID: 199304
Summary: minor bug in /usr/src/sys/netinet6/nd6_nbr.c
Product: Base System
Version: 10.1-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: fbsd.bugzilla at fenyo.net
In /usr/src/sys/netinet6/nd6_nbr.c, there are 2 times the following code:
if (max_linkhdr + maxlen >= MCLBYTES) {
#ifdef DIAGNOSTIC
printf("nd6_ns_output: max_linkhdr + maxlen >= MCLBYTES "
"(%d + %d > %d)\n", max_linkhdr, maxlen, MCLBYTES);
#endif
return;
}
There is two times the same little mistake in this code: the ">=" should
changed to ">".
It is correctly written in the last part of the diag: "(%d + %d > %d)\n"
But it is incorrect in the test (">= MCLBYTES" instead of "> MCLBYTES") and in
the first part of the diag: "max_linkhdr + maxlen >= MCLBYTES" instead of
"max_linkhdr + maxlen > MCLBYTES".
This is a bug because if the packet need exactly MCLBYTES, it is possible to
process it, but the code would not process the packet.
Anyway, this case should never happen because the Neigbor Advertisement and
Neighbor Solicitation packets are always small enough to be contained in a
single MBUF cluster. But the code is wrong, it would be nicer if corrected.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 9 05:52:33 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Apr 2015 05:52:33 +0000
Subject: [Bug 193500] Interrupt storm after loading i915kms module on Gen4
Intel GPU
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
Adrian Chadd changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |adrian at freebsd.org
--- Comment #20 from Adrian Chadd ---
I'm also having this problem on:
vgapci0 at pci0:0:2:0: class=0x030000 card=0x20e417aa chip=0x2a428086 rev=0x07
hdr=0x00
vendor = 'Intel Corporation'
device = 'Mobile 4 Series Chipset Integrated Graphics Controller'
class = display
subclass = VGA
info: [drm] Initialized drm 1.1.0 20060810
drmn0: on vgapci0
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 9 06:15:23 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Apr 2015 06:15:23 +0000
Subject: [Bug 193500] Interrupt storm after loading i915kms module on Gen4
Intel GPU
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #21 from Adrian Chadd ---
(In reply to Jan Kokem?ller from comment #11)
This also works for me, on my GM45 mobile chipset.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 9 06:31:41 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Apr 2015 06:31:41 +0000
Subject: [Bug 193500] Interrupt storm after loading i915kms module on Gen4
Intel GPU
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193500
--- Comment #22 from Adrian Chadd ---
... just to be clear:
* kib's opregion + zero'ing GMBUS4 patch didn't work
* jan's patch in comment #11 works
--
You are receiving this mail because:
You are the assignee for the bug.
From sibananda.sahu at avagotech.com Thu Apr 9 10:10:59 2015
From: sibananda.sahu at avagotech.com (Sibananda Sahu)
Date: Thu, 9 Apr 2015 15:40:50 +0530
Subject: scsi_scan_bus in FreeBSD 10.1 has mutex unlock and lock swapped
Message-ID: <2fa5e95f922badfba3ccf4dfd96e524e@mail.gmail.com>
Hi,
Recently I was working with mpslsi3 driver and found that the system just
crashed at xpt_action() call.
The same driver code is working just fine with other versions of FreeBSD.
After digging a little into the CAM layer code I found that:
inside scsi_scan_bus()at line number: 1935 first mutex_unlock(mtx) is
called and then at line 1974 called mtx_lock(mtx) just before exiting the
XPT_SCAN_BUS case.
I just swapped the calls and called mutex_lock() first and then called
mutex_unlock() and found there is no kernel panic.
Driver was loaded just fine but after a while I was unable to operate the
system.
But pinging to the system was working and the system was up.
Is it OK or it looks to be a bug?
Thanks,
Sibananda Sahu
From bugzilla-noreply at freebsd.org Thu Apr 9 10:48:31 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Apr 2015 10:48:31 +0000
Subject: [Bug 199002] freebsd-upgrade fails to find
/usr/src/crypto/openssl/util/mkbuildinf.pl
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199002
--- Comment #2 from mikhail.rokhin at gmail.com ---
(In reply to jason.unovitch from comment #1)
root at router:/home/wella # freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 5 mirrors found.
Fetching metadata signature for 10.1-RELEASE from update5.freebsd.org... done.
Fetching metadata index... done.
Fetching 2 metadata patches.. done.
Applying metadata patches... done.
Inspecting system... done.
Preparing to download files... done.
Fetching 5 patches... done.
Applying patches... done.
The following files will be added as part of updating to 10.1-RELEASE-p9:
/usr/src/crypto/openssl/util/mkbuildinf.pl
The following files will be updated as part of updating to 10.1-RELEASE-p9:
/bin/freebsd-version
/boot/kernel/kernel
/boot/kernel/kernel.symbols
/usr/libexec/bsdinstall/zfsboot
/usr/sbin/ntpd
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 9 10:50:06 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Apr 2015 10:50:05 +0000
Subject: [Bug 199002] freebsd-upgrade fails to find
/usr/src/crypto/openssl/util/mkbuildinf.pl
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199002
--- Comment #3 from mikhail.rokhin at gmail.com ---
(In reply to jason.unovitch from comment #1)
The error still exists preventing from update SRC-LESS installations...
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 9 10:56:42 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Apr 2015 10:56:42 +0000
Subject: [Bug 199002] freebsd-upgrade fails to find
/usr/src/crypto/openssl/util/mkbuildinf.pl
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199002
--- Comment #4 from mikhail.rokhin at gmail.com ---
Temporary solution for SRC-LESS installs:
# mkdir -p /usr/src/crypto/openssl/util/
# touch /usr/src/crypto/openssl/util/mkbuildinf.pl
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 9 10:57:09 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Apr 2015 10:57:09 +0000
Subject: [Bug 199002] freebsd-upgrade fails to find
/usr/src/crypto/openssl/util/mkbuildinf.pl in SRC-LESS installations of
FreeBSD
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199002
mikhail.rokhin at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|freebsd-upgrade fails to |freebsd-upgrade fails to
|find |find
|/usr/src/crypto/openssl/uti |/usr/src/crypto/openssl/uti
|l/mkbuildinf.pl |l/mkbuildinf.pl in SRC-LESS
| |installations of FreeBSD
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 9 10:58:54 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Apr 2015 10:58:53 +0000
Subject: [Bug 199002] freebsd-upgrade fails to find
/usr/src/crypto/openssl/util/mkbuildinf.pl in SRC-LESS installations of
FreeBSD
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199002
--- Comment #5 from mikhail.rokhin at gmail.com ---
(In reply to jason.unovitch from comment #1)
I guess freebsd-update may be more intellectual, whilst inspecting the system,
it may find out SRC-LESS installation of FreeBSD...
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 9 11:16:50 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Apr 2015 11:16:50 +0000
Subject: [Bug 199304] minor bug in /usr/src/sys/netinet6/nd6_nbr.c
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199304
Andrey V. Elsukov changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ae at FreeBSD.org
Assignee|freebsd-bugs at FreeBSD.org |ae at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 9 13:00:26 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Apr 2015 13:00:25 +0000
Subject: [Bug 199309] Kernel panic "binsfree: free buffer onto another
queue???" extracting tar to ext2fs partition.
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199309
Bug ID: 199309
Summary: Kernel panic "binsfree: free buffer onto another
queue???" extracting tar to ext2fs partition.
Product: Base System
Version: 10.1-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: kpielorz at tdx.co.uk
When extracting a large .tar.gz file onto a mounted ext2fs filesystem - under
10.1-RELEASE you get a reproducible kernel panic (details below).
The same set of operations on a FreeBSD 9.1-RELEASE system work correctly.
To reproduce:
- Install FreeBSD
- Install 'e2fsutils'
'mke2fs' a new partition, and mount it (e.g. 'mount -t ext2fs /dev/ada1s4
/mnt') - extract a large tar file (20Gb) to this new partition.
Under 9.1-R it finishes extraction. Under 10.1-R it fails after about the same
amount of time, but in slightly different places with:
"
panic: binsfree: free buffer onto another queue???
cpuid =3
KDB: stack backtrace:
#0 0xffffffff80963000 at kb_backtrace+0x60
#1 0xffffffff80928125 at panic+0x155
#2 0xffffffff809b18f7 at binsfree+0x327
#3 0xffffffff809afca0 at brelse+0x5f0
#4 0xffffffff81a19c34 at ext2_htree_add_entry+0x714
#5 0xffffffff81a1c1d4 at ext2_direnter+0xc4
#6 0xffffffff81a21d7d at ext2_makeinode+0x12d
#7 0xffffffff80e41ca1 at VOP_CREATE_APV+0xa1
#8 0xffffffff809d66c8 at vn_open_cred+0x2a8
#9 0xffffffff809cfedf at kern_openat+0x26f
#10 0xffffffff80d25851 at amd64_syscall+0x351
"
I have a minidump (~470Mb) of this crash - so I can kgdb it to run off various
bits (I can't publish as it likely has confidential data in the dump).
Smaller tar files extract OK.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 9 13:24:15 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Apr 2015 13:24:15 +0000
Subject: [Bug 199310] Font rendering problem -STABLE
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199310
Bug ID: 199310
Summary: Font rendering problem -STABLE
Product: Base System
Version: 10.1-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: misc
Assignee: freebsd-bugs at FreeBSD.org
Reporter: sasamotikomi at gmail.com
Created attachment 155361
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155361&action=edit
font problem
Problem repeatable on FreeBSD 10.1 -STABLE (r281276) screenshot Firefox
rendering for example, problem affected not only Firefox but repeat when
Firefox is running.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 9 16:59:08 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Apr 2015 16:59:08 +0000
Subject: [Bug 199321] Total MSI-X vector allocation limited to 191 vectors
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199321
Bug ID: 199321
Summary: Total MSI-X vector allocation limited to 191 vectors
Product: Base System
Version: 11.0-CURRENT
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: jimharris at FreeBSD.org
System Configuration:
2x 18C E5-v3 CPU (SMT enabled)
2x X520 Intel Ethernet 10Gb Adapter (4 ports total)
11.0-CURRENT (r281283)
ixgbe driver tries to allocate full range of 64 MSI-X vectors per port - first
two ports succeed, but third and fourth ports fail and fall back to a single
MSI vector.
msix_alloc() tries to use intr_next_cpu() to round-robin MSI-X vectors across
all cores. But driver initialization happens before APs are started, so
intr_next_cpu() just returns the BSP's apic ID 0. Each local APIC is limited
to APIC_NUM_IOINTS==191 vectors, so a single local APIC cannot handle the 64
vectors for each of the 4 ports.
intr_shuffle_irqs runs in SI_SUB_SMP phase and is intended to shuffle iras off
of core 0 to APs, but at this point it is too late - pci_alloc_msix() already
reported to ixgbe(4) that it could not allocate all 64 vectors.
x86 defines NUM_MSI_INTS as 512, but this bug really restricts number of MSI-X
vectors to APIC_NUM_IOINTS (191). Impact is that some drivers/devices which
can take advantage of multiple queues and one interrupt per queue must fall
back to a single interrupt. There may also be inconsistency across platforms
based on device enumeration - whichever devices enumerate first will get its
allotment of MSI-X vectors.
This problem will become exacerbated as NVMe SSDs become more prevalent, which
also try to allocate 32-64 MSIx vectors each. There are systems available
already with 8 NVMe SSDs in a single system.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 9 21:53:41 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 09 Apr 2015 21:53:27 +0000
Subject: [Bug 195458] Hang on shutdown/root unmount after FreeBSD 10.1R upgrade
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
--- Comment #72 from ncrogers at gmail.com ---
(In reply to commit-hook from comment #71)
Great work tracking this one down. I am guessing this is a no, but are there
any plans for this to make it into the 10.1-RELEASE branch? Another one of my
systems was hit by this today going from 10.1-p8 to 10.1-p9. Or is patching a
custom kernel the recommended solution?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 10 01:27:07 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 10 Apr 2015 01:27:07 +0000
Subject: [Bug 199002] freebsd-upgrade fails to find
/usr/src/crypto/openssl/util/mkbuildinf.pl in SRC-LESS installations of
FreeBSD
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199002
--- Comment #6 from jason.unovitch at gmail.com ---
(In reply to mikhail.rokhin from comment #4)
I can replicate with freebsd-update fetch before changing
/etc/freebsd-update.conf.
I cannot replicate with freebsd-update fetch being run after changing
/etc/freebsd-update.conf.
Also, regarding the "prevent from update" comment, freebsd-update install
should still work. It just can't handle that file for the reason mentioned
before.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 10 05:50:38 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 10 Apr 2015 05:50:38 +0000
Subject: [Bug 199310] www/firefox: Font rendering problem on 10-STABLE
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199310
Kubilay Kocak changed:
What |Removed |Added
----------------------------------------------------------------------------
Product|Base System |Ports & Packages
Summary|Font rendering problem |www/firefox: Font rendering
|-STABLE |problem on 10-STABLE
Version|10.1-STABLE |Latest
Status|New |Open
CC|freebsd-stable at FreeBSD.org, |
|sasamotikomi at gmail.com |
Flags| |maintainer-feedback?(gecko@
| |FreeBSD.org)
Component|misc |Individual Port(s)
Assignee|freebsd-bugs at FreeBSD.org |freebsd-ports-bugs at FreeBSD.
| |org
Keywords| |needs-qa
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 10 13:05:45 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 10 Apr 2015 13:05:44 +0000
Subject: [Bug 199350] Lzma library error: Corrupted input data
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199350
Bug ID: 199350
Summary: Lzma library error: Corrupted input data
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: juraj at lutter.sk
After recent import of LZMA I'm getting:
Lzma library error: Corrupted input data
when running "tar xvjf filename.txz"
On ARM:
Tested on Raspberry PI and qemu-static-arm.
System:
FreeBSD rpitest 11.0-CURRENT FreeBSD 11.0-CURRENT #34 r281320M: Thu Apr 9
22:04:36 CEST 2015
root at rpibuild:/data/rpibuild/output/obj/arm.armv6hf/data/rpibuild/src/fbsd-11/sys/RPI-B-OTIS
arm
On AMD64:
root at rpibuild:/usr/ports/audio/xmms-flac # make
===> xmms-flac-1.3.1 depends on file: /usr/local/sbin/pkg - found
=> flac-1.3.1.tar.xz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch
http://downloads.xiph.org/releases/flac/flac-1.3.1.tar.xz
flac-1.3.1.tar.xz 100% of 919 kB 269 kBps 00m03s
===> Fetching all distfiles required by xmms-flac-1.3.1 for building
===> Extracting for xmms-flac-1.3.1
=> SHA256 Checksum OK for flac-1.3.1.tar.xz.
flac-1.3.1/src/libFLAC/lpc_intrin_sse.c: Lzma library error: Corrupted input
data
tar: Error exit delayed from previous errors.
*** Error code 1
Problem occurs in r281320.
Works OK on 10-STABLE/amd64.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 10 17:46:06 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 10 Apr 2015 17:46:06 +0000
Subject: [Bug 199356] [carp] [vlan] stuck in INIT state
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199356
Bug ID: 199356
Summary: [carp] [vlan] stuck in INIT state
Product: Base System
Version: 11.0-CURRENT
Hardware: mips
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: harm at weites.com
Trying to setup carp on a vlan interface on the tplink 1043nd (MIPS) fails:
ifconfig vlan1 alias vhid 8 pass none 1.1.1.1/24 up
vlan1: flags=8943 metric 0 mtu
1500
ether 90:f6:52:33:51:74
inet6 fe80::92f6:52ff:fe33:5174%vlan1 prefixlen 64 scopeid 0xb
inet 10.9.0.12 netmask 0xffffff00 broadcast 10.9.0.255
inet 1.1.1.1 netmask 0xffffff00 broadcast 1.1.1.255 vhid 8
nd6 options=21
media: Ethernet 1000baseT
status: active
vlan: 1 parent interface: arge0
carp: INIT vhid 8 advbase 1 advskew 0
groups: vlan
Stuck in INIT state and no mcast packages in tcpdump.
I observed the same on a Pi (ARM) and a virtualbox instance with e1000
interface (am64), though those could not be easily reproduced. Configuring
with/without specifically putting the interface in a up state, I've read about
this on the ML.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 10 17:53:34 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 10 Apr 2015 17:53:34 +0000
Subject: [Bug 199357] Make liblzma use libmd again
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199357
Bug ID: 199357
Summary: Make liblzma use libmd again
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: delphij at FreeBSD.org
The SHA256 portion was reverted in 281372. After bug 199119 have been
resolved, the revision should be reverted.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 10 17:53:42 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 10 Apr 2015 17:53:42 +0000
Subject: [Bug 199357] Make liblzma use libmd again
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199357
Xin LI changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends on| |199119
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 10 17:53:43 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 10 Apr 2015 17:53:42 +0000
Subject: [Bug 199119] libmd conflicts with libcrypto
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199119
Xin LI changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |199357
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 10 17:53:47 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 10 Apr 2015 17:53:47 +0000
Subject: [Bug 199357] Make liblzma use libmd again
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199357
Xin LI changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |delphij at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 10 18:40:17 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 10 Apr 2015 18:40:16 +0000
Subject: [Bug 196447] vi(1) misbehavior when encountered invalid Unicode
character
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196447
Xin LI changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|New |In Progress
Assignee|freebsd-bugs at FreeBSD.org |bapt at FreeBSD.org
--- Comment #6 from Xin LI ---
This should have been addressed in 281373. Over to bapt at .
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 10 19:00:01 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 10 Apr 2015 19:00:01 +0000
Subject: [Bug 199002] freebsd-upgrade fails to find
/usr/src/crypto/openssl/util/mkbuildinf.pl in SRC-LESS installations of
FreeBSD
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199002
Matthias Andree changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |DUPLICATE
Status|New |Closed
CC| |mandree at FreeBSD.org
--- Comment #7 from Matthias Andree ---
*** This bug has been marked as a duplicate of bug 198030 ***
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 10 19:00:05 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 10 Apr 2015 19:00:01 +0000
Subject: [Bug 198030] /usr/src/crypto/openssl/util/mkbuildinf.pl: No such
file or directory on freebsd-update install
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198030
Matthias Andree changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mikhail.rokhin at gmail.com
--- Comment #14 from Matthias Andree ---
*** Bug 199002 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Apr 11 04:18:52 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Apr 2015 04:18:52 +0000
Subject: [Bug 174441] [psm] [patch] Enable detection of Synaptics touchpad
for firmware >= 7.5
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=174441
Rui Paulo changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rpaulo at FreeBSD.org
Resolution|--- |Overcome By Events
Status|In Progress |Closed
--- Comment #1 from Rui Paulo ---
Patch already in FreeBSD.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Apr 11 04:20:17 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Apr 2015 04:20:17 +0000
Subject: [Bug 89258] [mouse] synaptic touchpad support "worse" with
hw.psm.synaptics_support="1" than without
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=89258
Rui Paulo changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |Overcome By Events
CC| |rpaulo at FreeBSD.org
Status|In Progress |Closed
--- Comment #1 from Rui Paulo ---
Please retest a newer FreeBSD and file a new bug report. Synaptics support has
improved quite a bit.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Apr 11 04:21:39 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Apr 2015 04:21:39 +0000
Subject: [Bug 182577] Newer ALPS Touchpad under hw.psm.synaptics_support seen
as glidepoint
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=182577
Rui Paulo changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rpaulo at FreeBSD.org
Resolution|--- |DUPLICATE
Status|In Progress |Closed
--- Comment #1 from Rui Paulo ---
*** This bug has been marked as a duplicate of bug 138938 ***
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Apr 11 04:21:39 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Apr 2015 04:21:39 +0000
Subject: [Bug 138938] [psm] Synaptics Support dosn't work on Dell Latitude
d600
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=138938
Rui Paulo changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |martin.hellwig at gmail.com
--- Comment #1 from Rui Paulo ---
*** Bug 182577 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Apr 11 04:22:21 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Apr 2015 04:22:20 +0000
Subject: [Bug 138870] [apm] 8.0beta4 PnP problem? lost synaptics trackpad in
r40, psm0 not detected [regression]
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=138870
Rui Paulo changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rpaulo at FreeBSD.org
Status|In Progress |Closed
Resolution|--- |Overcome By Events
--- Comment #3 from Rui Paulo ---
APM is no longer supported. Please test a recent FreeBSD and file a new bug.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Apr 11 04:23:11 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Apr 2015 04:23:11 +0000
Subject: [Bug 137228] [psm] synaptics support delays 'mouse up' events when
no motion
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=137228
Rui Paulo changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rpaulo at FreeBSD.org
Status|In Progress |Closed
Resolution|--- |Overcome By Events
--- Comment #1 from Rui Paulo ---
Please test a newer FreeBSD version (as the synaptics driver has improved) and
file a new bug report if the problem persists.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Apr 11 04:24:47 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Apr 2015 04:24:47 +0000
Subject: [Bug 138938] [psm] Synaptics Support dosn't work on Dell Latitude
d600
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=138938
Rui Paulo changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rpaulo at FreeBSD.org
Resolution|--- |Overcome By Events
Status|In Progress |Closed
--- Comment #2 from Rui Paulo ---
Please try a new FreeBSD version.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Apr 11 04:25:20 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Apr 2015 04:25:20 +0000
Subject: [Bug 108659] [psm] Mouse (Synaptics touchpad) cursor freezes for
some seconds (~5sec) in X
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=108659
Rui Paulo changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |Overcome By Events
Status|In Progress |Closed
CC| |rpaulo at FreeBSD.org
--- Comment #1 from Rui Paulo ---
Please try a new freebsd version since the driver has improved.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Apr 11 04:26:15 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Apr 2015 04:26:15 +0000
Subject: [Bug 122046] [psm] Synaptics touchpad freezes (psm0: lost
interrupt?) [regression]
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=122046
Rui Paulo changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rpaulo at FreeBSD.org
Status|In Progress |Closed
Resolution|--- |Overcome By Events
--- Comment #6 from Rui Paulo ---
Please try a more recent FreeBSD version and file a new bug if the problem
persists.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Apr 11 14:26:49 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 11 Apr 2015 14:26:49 +0000
Subject: [Bug 199378] [patch] dhclient violates RFC2131 when sending early
DHCPREQUEST message to re-obtain old IP
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199378
Bug ID: 199378
Summary: [patch] dhclient violates RFC2131 when sending early
DHCPREQUEST message to re-obtain old IP
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Keywords: patch
Severity: Affects Many People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: fbsd at opal.com
Keywords: patch
Created attachment 155476
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155476&action=edit
patch to cause early DHCPREQUEST broadcasts to be sent using source IP 0.0.0.0
When dhclient first starts, if an old IP address exists in the dhclient.leases
file, dhclient(8) sends early DHCPREQUEST message(s) in an attempt to re-obtain
the old IP address again. These messages contain the old IP as a
requested-IP-address option in the message body (correct) but the message also
uses the old IP address as the packet's source IP (incorrect).
RFC2131 sec 4.1 states:
DHCP messages broadcast by a client prior to that client obtaining
its IP address must have the source address field in the IP header
set to 0.
The use of the old IP as the packet's source address is incorrect if (a) the
computer is now on a different network or (b) it is on the same network, but
the old IP has been reallocated to another host.
The attached patch fixes things to use 0.0.0.0 as the source IP without
removing any existing functionality. Any previously-used old IP is still
requested in the body of an early DHCPREQUEST message.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 12 07:05:31 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 12 Apr 2015 07:05:31 +0000
Subject: [Bug 199152] msdosfs writes on umount to readonly mounted fs
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199152
--- Comment #5 from commit-hook at freebsd.org ---
A commit references this bug:
Author: kib
Date: Sun Apr 12 07:05:21 UTC 2015
New revision: 281457
URL: https://svnweb.freebsd.org/changeset/base/281457
Log:
MFC r281121:
Do not call msdosfs_sync() on the read-only msdosfs mounts.
PR: 199152
Changes:
_U stable/10/
stable/10/sys/fs/msdosfs/msdosfs_vfsops.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at FreeBSD.org Sun Apr 12 21:00:17 2015
From: bugzilla-noreply at FreeBSD.org (bugzilla-noreply at FreeBSD.org)
Date: Sun, 12 Apr 2015 21:00:17 +0000
Subject: Problem reports for freebsd-bugs@FreeBSD.org that need special
attention
Message-ID: <201504122100.t3CL0HIA029702@kenobi.freebsd.org>
To view an individual PR, use:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.
Status | Bug Id | Description
------------+-----------+---------------------------------------------------
In Progress | 196973 | sh(1) broken UTF-8 input
New | 198797 | [PATCH] Added an option to install BSDstats to bs
New | 199136 | [if_tap] Added down_on_close sysctl variable to t
Open | 90114 | [patch] pw(8) takes strings after option -g for G
Open | 155028 | init(8): "init q" in single user causes segfault
Open | 156481 | [kernel] [patch] kernel incorrectly reports PPS j
Open | 165630 | [ndis][panic][patch] IRQL_NOT_GREATER_THAN
Open | 167133 | stale files in /usr/share/examples
Open | 169471 | [patch] pw(8) deletes group "username" on userdel
Open | 171779 | [patch] passwd(1): make option NO_FSCHG incomplet
Open | 184681 | A bug of bsdconfig(8) in 10.0 RC1
Open | 191511 | opiepasswd(1) segfaults with a seed length > 12
12 problems total for which you should take action.
From bugzilla-noreply at freebsd.org Sun Apr 12 23:48:15 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 12 Apr 2015 23:48:14 +0000
Subject: [Bug 199405] Panic trying to mount ZFS pool after 10.1 update
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199405
Bug ID: 199405
Summary: Panic trying to mount ZFS pool after 10.1 update
Product: Base System
Version: 10.1-STABLE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: drsmithy at gmail.com
Created attachment 155528
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155528&action=edit
Core dump text file
My home FreeBSD servers is panicking trying to mount one of its ZFS pools. It
is a VM running on vSphere 5.5 with two LSI SAS9211-8i HBAs presented to it
using PCI passthrough and has been quite stable for a couple of years in this
configuration.
It was recently updated to 10.1 (from 10), but ran successfully for a week or
two before the current problem. It was also relatively recently (within the
last month or two) updated from 9.3-STABLE.
The ZFS pool was not upgraded to the latest features when the system was.
Trying to "zpool import -f" on freshly built 10.1 or 9.3 systems causes the
same panic. I have also tried importing with readonly=on. I haven't tried
systems earlier than 9.3.
A second zpool from the same server is working without problems (ie: I was able
to mount it on the freshly built 10.1 box with zpool import-f).
The text from the panic is:
FreeBSD freebsd 10.1-RELEASE-p9 FreeBSD 10.1-RELEASE-p9 #0: Tue Apr 7 01:09:46
UTC 2015 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
amd64
panic: solaris assert: range_tree_space(rt) == space (0x6b34cb000 ==
0x6b3525000), file:
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c,
line: 130
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 "amd64-marcel-freebsd"...
Unread portion of the kernel message buffer:
panic: solaris assert: range_tree_space(rt) == space (0x6b34cb000 ==
0x6b3525000), file:
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c,
line: 130
cpuid = 0
KDB: stack backtrace:
#0 0xffffffff80963000 at kdb_backtrace+0x60
#1 0xffffffff80928125 at panic+0x155
#2 0xffffffff81b7c22f at assfail3+0x2f
#3 0xffffffff81a836e5 at space_map_load+0x3d5
#4 0xffffffff81a69b0e at metaslab_load+0x2e
#5 0xffffffff81a6b609 at metaslab_alloc+0x6b9
#6 0xffffffff81aa9ca6 at zio_dva_allocate+0x76
#7 0xffffffff81aa7382 at zio_execute+0x162
#8 0xffffffff80971475 at taskqueue_run_locked+0xe5
#9 0xffffffff80971f08 at taskqueue_thread_loop+0xa8
#10 0xffffffff808f8b6a at fork_exit+0x9a
#11 0xffffffff80d0acfe at fork_trampoline+0xe
Uptime: 4m26s
Dumping 418 out of 8168 MB:..4%..12%..23%..31%..43%..54%..62%..73%..81%..92%
I have attached the core.txt file produced, I also have a core dump. This is
from trying to import on the fresh 10.1 system.
This may be related to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193875
?
It would be great if I could even get this pool mounted in a readonly state to
pull some of the data off it. Nothing is irreplaceable, but restoring ~9T over
the internet takes a long time.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 13 01:43:06 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Apr 2015 01:43:06 +0000
Subject: [Bug 199407] mkuzip(8) verbosity change request to help with
makefs(8) filesystems
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199407
Bug ID: 199407
Summary: mkuzip(8) verbosity change request to help with
makefs(8) filesystems
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: kwhite at site.uottawa.ca
Created attachment 155531
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155531&action=edit
requested enhancements to mkuzip and makefs
After an Easter weekend's head scratching over a frustratingly
intermittent problem...
mkuzip's default verbosity level hides a message that might help
end users (me) when disk /dev/ufs/... labels on mkuzip filesystems
"mysteriously" don't appear at boot. mkuzip provides useful messages
when "-v" is added, but they're lost amongst the noise. I propose
adding verbosity levels: "-v" "-vv"
Patch for mkuzip(8) attached. The mkulzma(8) derivative could be
modified similarly.
sys/geom/label/g_label_ufs.c expects well behaved filesystem sizes.
Unfortunately, mkuzip(8) may need to add some padding when compressing
a filesystem, and the provider size will then no longer match the
superblock. Particularly for a makefs(8) filesystem.
One workaround for "file size is not multiple of XXXX, padding data"
would be for the user to specify a bsize the same as the intended
mkuzip blocksize. e.g.:
$ ZBLOCKSIZE=32768
$ FSIZE=`expr $ZBLOCKSIZE / 8`
$ LABEL="ALabel"
$ makefs -o label="$LABEL" -o bsize=$ZBLOCKSIZE -o fsize=$FSIZE ...
$ mkuzip -v -s $ZBLOCKSIZE ...
A patch (attached) for makefs(8) that pads the resulting filesystem
to fit on a mkuzip cluster_size boundary, might be useful as well.
$ ZBLOCKSIZE=32768
$ LABEL="ALabel"
$ makefs -o label="$LABEL" -c $ZBLOCKSIZE ...
$ mkuzip -v -s $ZBLOCKSIZE
...keith
~
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 13 17:00:08 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Apr 2015 17:00:08 +0000
Subject: [Bug 199422] fmodl not fully defined on architectures where
LDBL_PREC == 53 (arm, mips, powerpc)
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199422
Bug ID: 199422
Summary: fmodl not fully defined on architectures where
LDBL_PREC == 53 (arm, mips, powerpc)
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: ngie at FreeBSD.org
I testing out a change to build lib/msun/tests on all architectures, and I
lib/msun/tests/fmod_test failed to compile on MACHINE == {arm,mips,powerpc}
with the following error:
t_fmod.o: In function `atfu_fmod_body':
t_fmod.c:(.text+0x200): undefined reference to `fmodl'
t_fmod.c:(.text+0x204): undefined reference to `fmodl'
t_fmod.c:(.text+0x2f0): undefined reference to `fmodl'
t_fmod.c:(.text+0x2f4): undefined reference to `fmodl'
t_fmod.c:(.text+0x434): undefined reference to `fmodl'
t_fmod.o:t_fmod.c:(.text+0x438): more undefined references to `fmodl' follow
--- fmod_test ---
*** [fmod_test] Error code 1
make[8]: stopped in /home/ngie/head/lib/msun/tests
Are these functions supposed to be fully defined?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 13 17:01:30 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Apr 2015 17:01:30 +0000
Subject: [Bug 199422] fmodl not fully defined on architectures where
LDBL_PREC == 53 (arm, mips, powerpc)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199422
Garrett Cooper,425-314-3911 changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |das at FreeBSD.org,
| |kargl at FreeBSD.org
Severity|Affects Only Me |Affects Some People
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 13 17:04:56 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Apr 2015 17:04:56 +0000
Subject: [Bug 199423] NTP stopped peering after FreeBSD-SA-15:07.ntp
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199423
Bug ID: 199423
Summary: NTP stopped peering after FreeBSD-SA-15:07.ntp
Product: Base System
Version: 10.1-STABLE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: freebsd at pki2.com
After I applied FreeBSD-SA-15:07.ntp the NTP daemon stopped peering. It still
successfully works as a client and server.
My peers are authenticated and I found under the following conditions I can
return peers to a working state:
1) I restore the unpatched ntp_proto.c file.
2) I applied the patch below, which undoes part of FreeBSD-SA-15:07.ntp.
Although I DID NOT step through the code (I looked through some of the code),
it isn't clear to me why this works. For a while I suspected an optimizer bug.
3) net/ntp (4.2.8p2) and net/ntp-devel (4.3.14) both work. (FreeBSD is
4.2.4p8.)
My systems are:
Marvin# uname -a
FreeBSD Marvin 10.1-STABLE FreeBSD 10.1-STABLE #0 r281238: Tue Apr 7 19:05:26
CDT 2015 root at Marvin:/usr/obj/usr/src/sys/PENFORD-FreeBSD10-amd64 amd64
My ntp.conf on the host Marvin is the following. My other systems are similar.
My keys are MD5, such as:
250 MD5 xxxxxxxx
Marvin# more /etc/ntp.conf
enable auth ntp monitor stats
keys /etc/ntp/keys
keysdir /etc/ntp
crypto randfile /dev/random
crypto leap /etc/ntp/leap-seconds.3629404800
trustedkey 67 68 69 70 71 72 73 74 101 102 104 250 251 252 253 254 255 260
261
requestkey 23
controlkey 27
server tock.usno.navy.mil prefer
server time-a.nist.gov prefer
server time-b.nist.gov prefer
server time.xmission.com prefer
server clock.fmt.he.net prefer
peer granny.bwa.penx.com key 250
peer tweety-ext.cria.penx.com key 251
peer daffy.penx.com key 252
peer elmer.dco.penx.com key 254
peer bugs.obil.penx.com key 255
#
# Back up clock source
server 127.127.1.0
fudge 127.127.1.0 stratum 5
Marvin# diff -c ntp_proto.c.orig ntp_proto.c
*** ntp_proto.c.orig Sat Apr 11 23:51:43 2015
--- ntp_proto.c Sat Apr 11 23:54:54 2015
***************
*** 948,957 ****
peer->flash |= TEST2; /* bogus packet */
}
! /*
! * If unsynchronized or bogus abandon ship. If the crypto machine
! * breaks, light the crypto bit and plaint the log.
! */
if (peer->flash & PKT_TEST_MASK) {
#ifdef OPENSSL
if (crypto_flags && (peer->flags & FLAG_SKEY)) {
--- 948,960 ----
peer->flash |= TEST2; /* bogus packet */
}
! /*
! * Update the origin and destination timestamps. If
! * unsynchronized or bogus abandon ship. If the crypto machine
! * breaks, light the crypto bit and plaint the log.
! */
! peer->org = p_xmt;
! peer->rec = rbufp->recv_time;
if (peer->flash & PKT_TEST_MASK) {
#ifdef OPENSSL
if (crypto_flags && (peer->flags & FLAG_SKEY)) {
***************
*** 994,1005 ****
/*
* That was hard and I am sweaty, but the packet is squeaky
* clean. Get on with real work.
- *
- * Update the origin and destination timestamps.
*/
- peer->org = p_xmt;
- peer->rec = rbufp->recv_time;
-
peer->received++;
peer->timereceived = current_time;
if (is_authentic == AUTH_OK)
--- 997,1003 ----
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 13 17:06:17 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Apr 2015 17:06:16 +0000
Subject: [Bug 198030] /usr/src/crypto/openssl/util/mkbuildinf.pl: No such
file or directory on freebsd-update install
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198030
jeff+freebsd at wagsky.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jeff+freebsd at wagsky.com
--- Comment #15 from jeff+freebsd at wagsky.com ---
Confirmed still an issue on:
$ uname -a
FreeBSD 10.1-RELEASE-p9 FreeBSD 10.1-RELEASE-p9 #0: Tue Apr 7
01:09:46 UTC 2015
root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
$ freebsd-version -uk
10.1-RELEASE-p9
10.1-RELEASE-p9
$ ls -l /usr/src/
total 0
(This machine intentionally does not have the src distribution installed)
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 13 17:08:39 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Apr 2015 17:08:39 +0000
Subject: [Bug 199422] fmodl not fully defined on architectures where
LDBL_PREC == 53 (arm, mips, powerpc)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199422
--- Comment #1 from Garrett Cooper,425-314-3911 ---
lib/msun/Makefile only defines fmodl on select architectures:
97 .if ${LDBL_PREC} != 53
98 # If long double != double use these; otherwise, we alias the double
versions.
99 COMMON_SRCS+= e_acoshl.c e_acosl.c e_asinl.c e_atan2l.c e_atanhl.c \
100 e_coshl.c e_fmodl.c e_hypotl.c \
This seems to support what I've seen.
Is there a list of functions that are only partially implemented on some
architectures, so I can modify the testcases accordingly to skip them?
--
You are receiving this mail because:
You are the assignee for the bug.
From brde at optusnet.com.au Mon Apr 13 17:29:40 2015
From: brde at optusnet.com.au (Bruce Evans)
Date: Tue, 14 Apr 2015 03:29:31 +1000 (EST)
Subject: [Bug 199422] fmodl not fully defined on architectures where
LDBL_PREC == 53 (arm, mips, powerpc)
In-Reply-To:
References:
Message-ID: <20150414032241.K6307@besplex.bde.org>
On Mon, 13 Apr 2015 bugzilla-noreply at freebsd.org wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199422
>
> I testing out a change to build lib/msun/tests on all architectures, and I
> lib/msun/tests/fmod_test failed to compile on MACHINE == {arm,mips,powerpc}
> with the following error:
>
> t_fmod.o: In function `atfu_fmod_body':
> t_fmod.c:(.text+0x200): undefined reference to `fmodl'
> t_fmod.c:(.text+0x204): undefined reference to `fmodl'
> t_fmod.c:(.text+0x2f0): undefined reference to `fmodl'
> t_fmod.c:(.text+0x2f4): undefined reference to `fmodl'
> t_fmod.c:(.text+0x434): undefined reference to `fmodl'
> t_fmod.o:t_fmod.c:(.text+0x438): more undefined references to `fmodl' follow
> --- fmod_test ---
> *** [fmod_test] Error code 1
>
> make[8]: stopped in /home/ngie/head/lib/msun/tests
>
> Are these functions supposed to be fully defined?
fmodl just seems to be missing a weak definition. Try this fix.
X diff -u2 e_fmod.c~ e_fmod.c
X --- e_fmod.c~ 2013-05-30 08:14:16.000000000 +0000
X +++ e_fmod.c 2015-04-13 17:18:19.493921000 +0000
X @@ -21,4 +21,6 @@
X */
X
X +#include
X +
X #include "math.h"
X #include "math_private.h"
X @@ -131,2 +133,6 @@
X return x; /* exact output */
X }
X +
X +#if (LDBL_MANT_DIG == 53)
X +__weak_reference(fmod, fmodl);
X +#endif
Testing weak aliases is mostly redundant, but it is
probably easier to not have special cases for them.
The special cases would still need existence tests.
Bruce
From bugzilla-noreply at freebsd.org Mon Apr 13 17:31:43 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Apr 2015 17:31:43 +0000
Subject: [Bug 199422] fmodl not fully defined on architectures where
LDBL_PREC == 53 (arm, mips, powerpc)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199422
Ed Maste changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |emaste at freebsd.org
--- Comment #2 from Ed Maste ---
I'm not aware of any overall list, you'll have to handle it on a case by case
basis.
That said, I think there's an actual error here -- fmodl should be an alias for
fmod when long double == double.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 13 17:41:57 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Apr 2015 17:41:57 +0000
Subject: [Bug 199422] fmodl not fully defined on architectures where
LDBL_PREC == 53 (arm, mips, powerpc)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199422
--- Comment #3 from Garrett Cooper,425-314-3911 ---
(In reply to Ed Maste from comment #2)
The NetBSD testcases poke directly at fmodl and friends in t_fmod.c, so it's a
problem with the testcases.
Thanks for the clarification :).
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 13 17:45:02 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Apr 2015 17:45:02 +0000
Subject: [Bug 199422] fmodl not fully defined on architectures where
LDBL_PREC == 53 (arm, mips, powerpc)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199422
--- Comment #4 from Ed Maste ---
(In reply to Garrett Cooper,425-314-3911 from comment #3)
> so it's a problem with the testcases
I don't follow; the tests in t_fmod.c should build and pass on all
architectures.
> ATF_CHECK(fmodl(2.0, 1.0) == 0);
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 13 17:45:56 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Apr 2015 17:45:56 +0000
Subject: [Bug 199422] fmodl not fully defined on architectures where
LDBL_PREC == 53 (arm, mips, powerpc)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199422
--- Comment #5 from Garrett Cooper,425-314-3911 ---
Nevermind. I just reread that. You're right -- it's an issue with libc.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 13 17:46:19 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Apr 2015 17:46:19 +0000
Subject: [Bug 199422] fmodl not fully defined on architectures where
LDBL_PREC == 53 (arm, mips, powerpc)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199422
--- Comment #6 from Garrett Cooper,425-314-3911 ---
(In reply to Garrett Cooper,425-314-3911 from comment #5)
msun, not libc.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 13 18:12:54 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Apr 2015 18:12:54 +0000
Subject: [Bug 199422] fmodl not fully defined on architectures where
LDBL_PREC == 53 (arm, mips, powerpc)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199422
--- Comment #7 from Ed Maste ---
As an aside, by the same logic it looks like r274601 should be reverted
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 13 18:47:57 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Apr 2015 18:47:57 +0000
Subject: [Bug 194416] Testing123
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194416
--- Comment #1 from commit-hook at freebsd.org ---
A commit references this bug:
Author: adamw
Date: Mon Apr 13 18:47:51 UTC 2015
New revision: 383947
URL: https://svnweb.freebsd.org/changeset/ports/383947
Log:
Update to 1.3.6.
PR: 194416
Submitted by: Ben Woods (maintainer)
Changes:
head/multimedia/plexhometheater/Makefile
head/multimedia/plexhometheater/distinfo
head/multimedia/plexhometheater/files/patch-CMakeLists.txt
head/multimedia/plexhometheater/files/patch-lib__CMakeLists.txt
head/multimedia/plexhometheater/files/patch-lib__cpluff__CMakeLists.txt
head/multimedia/plexhometheater/files/patch-lib__cximage-6.0__CMakeLists.txt
head/multimedia/plexhometheater/files/patch-lib__ffmpeg__CMakeLists.txt
head/multimedia/plexhometheater/files/patch-lib__libdvd__libdvdcss__CMakeLists.txt
head/multimedia/plexhometheater/files/patch-lib__libdvd__libdvdnav__CMakeLists.txt
head/multimedia/plexhometheater/files/patch-libcec22
head/multimedia/plexhometheater/files/patch-plex__CMakeLists.txt
head/multimedia/plexhometheater/files/patch-plex__CMakeModules__CMakeConfig.cmake
head/multimedia/plexhometheater/files/patch-plex__CMakeModules__CPackConfig.cmake
head/multimedia/plexhometheater/files/patch-plex__CMakeModules__FindExecinfo.cmake
head/multimedia/plexhometheater/files/patch-plex__CMakeModules__PlatformConfigFREEBSD.cmake
head/multimedia/plexhometheater/files/patch-plex__CMakeModules__PlatformConfigPOSIX.cmake
head/multimedia/plexhometheater/files/patch-plex__Network__CMakeLists.txt
head/multimedia/plexhometheater/files/patch-plex__Network__NetworkInterfaceBSD.cpp
head/multimedia/plexhometheater/files/patch-plex__config.h.in
head/multimedia/plexhometheater/files/patch-xbmc__CMakeLists.txt
head/multimedia/plexhometheater/files/patch-xbmc__cdrip__CMakeLists.txt
head/multimedia/plexhometheater/files/patch-xbmc__cores__AudioEngine__Sinks__CMakeLists.txt
head/multimedia/plexhometheater/files/patch-xbmc__cores__DllLoader__CMakeLists.txt
head/multimedia/plexhometheater/files/patch-xbmc__cores__dvdplayer__DVDCodecs__Video__CMakeLists.txt
head/multimedia/plexhometheater/files/patch-xbmc__input__CMakeLists.txt
head/multimedia/plexhometheater/files/patch-xbmc__linux__CMakeLists.txt
head/multimedia/plexhometheater/files/patch-xbmc__storage__CMakeLists.txt
head/multimedia/plexhometheater/files/patch-xbmc__visualizations__XBMCProjectM__CMakeLists.txt
head/multimedia/plexhometheater/files/patch-xbmc__windowing__CMakeLists.txt
head/multimedia/plexhometheater/pkg-plist
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 13 22:24:42 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Apr 2015 22:24:42 +0000
Subject: [Bug 198937] Xorg blank screen after r277486 on Asus Zenbook
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198937
--- Comment #1 from Stefan Parvu ---
Created attachment 155573
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155573&action=edit
hw.dri.0 dump
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 13 22:25:31 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Apr 2015 22:25:31 +0000
Subject: [Bug 198937] Xorg blank screen after r277486 on Asus Zenbook
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198937
--- Comment #2 from Stefan Parvu ---
Created attachment 155574
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155574&action=edit
dmesg information
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 13 22:26:08 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Apr 2015 22:26:08 +0000
Subject: [Bug 198937] Xorg blank screen after r277486 on Asus Zenbook
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198937
--- Comment #3 from Stefan Parvu ---
I have tried to adjust the brightness of the LCD by using:
hw.acpi.video.lcd0.brightness but did not work.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 14 02:25:02 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Apr 2015 02:25:02 +0000
Subject: [Bug 198148] [hwpmc] pmcstat -G doesn't resolve symbols from
userland processes
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198148
ganbold at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ganbold at gmail.com
--- Comment #3 from ganbold at gmail.com ---
I'm running some content filtering software written in Go and did some load on
it. I tried pmcstat.
As Hiren, I see userland symbols in callgraph like:
...
50.69% [359402] scanblock @ /usr/home/tsgan/go/bin/shuultuur
00.04% [140] net.(*netFD).decref
00.01% [23] os.Lstat
00.00% [13] runtime.netpollinit
00.00% [10] runtime.goexit
--
08.61% [61068] runtime.MSpan_Sweep @ /usr/home/tsgan/go/bin/shuultuur
02.33% [16554] hash/crc32.update @ /usr/home/tsgan/go/bin/shuultuur
00.03% [5] hash/crc32.Update
00.01% [1] reflect.cvtFloatInt
00.01% [1] net/textproto.(*dotReader).Read
00.01% [1] reflect.(*rtype).Implements
--
01.34% [9528] compress/flate.(*decompressor).huffSym @
/usr/home/tsgan/go/bin/shuultuur
01.20% [8515] runtime.readvarint @ /usr/home/tsgan/go/bin/shuultuur
01.43% [122] runtime.step
00.05% [4] runtime.goparkunlock
00.01% [1] net/http.(*persistConn).wroteRequest
00.01% [1] net/http.(*persistConn).markBroken
--
01.10% [7832] code.google.com/p/go.net/html.(*Tokenizer).readByte @
/usr/home/tsgan/go/bin/shuultuur
00.63% [49] code.google.com/p/go.net/html.(*Tokenizer).Next
00.31% [24] code.google.com/p/go.net/html.(*Tokenizer).readScript
00.27% [21] code.google.com/p/go.net/html.(*Tokenizer).readTagAttrVal
00.09% [7] code.google.com/p/go.net/html.(*Tokenizer).skipWhiteSpace
--
01.09% [7697] compress/flate.(*decompressor).huffmanBlock @
/usr/home/tsgan/go/bin/shuultuur
00.01% [1] compress/flate.(*decompressor).huffmanBlock
01.01% [7184] strings.Map @ /usr/home/tsgan/go/bin/shuultuur
00.93% [6613]
bitbucket.org/hooray-976/shuultuur/tools/search.(*stringFinder).next @
/usr/home/tsgan/go/bin/shuultuur
00.92% [6488] runtime.step @ /usr/home/tsgan/go/bin/shuultuur
00.62% [40] runtime.pcvalue
00.42% [27] runtime.goparkunlock
00.08% [5] github.com/elazarl/goproxy.func.018
00.03% [2] net/http.(*Server).ListenAndServeTLS
--
...
I run FreeBSD current in VMware Fusion:
root at bsd:/var/tmp # uname -an
FreeBSD bsd 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r269824: Mon Aug 11 20:18:52
UTC 2014 root at grind.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
Maybe it depends from your use case?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 14 02:34:09 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Apr 2015 02:34:09 +0000
Subject: [Bug 199356] [carp] [vlan] stuck in INIT state
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199356
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-net at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 14 02:36:59 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Apr 2015 02:36:58 +0000
Subject: [Bug 199405] Panic trying to mount ZFS pool after 10.1 update
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199405
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-fs at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 14 02:39:07 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Apr 2015 02:39:07 +0000
Subject: [Bug 199407] mkuzip(8) verbosity change request to help with
makefs(8) filesystems
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199407
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 14 03:15:49 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Apr 2015 03:15:49 +0000
Subject: [Bug 199438] vt(4) cannot load GNU Unifont
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199438
Bug ID: 199438
Summary: vt(4) cannot load GNU Unifont
Product: Base System
Version: 10.1-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: lantw44 at gmail.com
Created attachment 155584
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155584&action=edit
Increase VTFONT_MAXMAPPINGS and VTFONT_MAXGLYPHSIZE
I downloaded GNU Unifont from this website:
http://www.unifoundry.com/unifont.html
I tried to convert the BDF file to FNT file with vtfontcvt, but I got E2BIG
error when trying to load the converted file with vidcontrol -f.
It seems it was caused by the limits set in sys/dev/vt/vt_font.c.
#define VTFONT_MAXMAPPINGS 8192
#define VTFONT_MAXGLYPHSIZE 1048576
The values showed when loading the font.
f->map_count[0] = 12894
f->map_count[1] = 23362
f->map_count[2] = 0
f->map_count[3] = 0
glyphsize = 1133296
If I increase the limit with the attached patch, the font can be successfully
loaded.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 14 03:33:06 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Apr 2015 03:33:06 +0000
Subject: [Bug 198147] [hwpmc] running pmcstat -t (top mode) whilst a process
is running doesn't resolve the symbols correctly
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198147
ganbold at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ganbold at gmail.com
--- Comment #1 from ganbold at gmail.com ---
I tried to run pmcstat in top mode after starting specific program. pmcstat
seems show userland symbols like:
PMC: [INSTR_RETIRED_ANY] Samples: 17452 (100.0%) , 207 unresolved
%SAMP IMAGE FUNCTION CALLERS
42.4 shuultuur scanblock
7.3 shuultuur runtime.MSpan_Sweep
3.0 shuultuur code.google.com/p/go
2.8 shuultuur hash/crc32.update
2.6 shuultuur runtime.readvarint
2.0 shuultuur runtime.step
2.0 shuultuur strings.Map
1.4 shuultuur runtime.findfunc
1.4 shuultuur runtime.stringiter2
1.3 shuultuur compress/flate.(*dec
1.3 shuultuur unicode.ToLower
1.1 shuultuur compress/flate.(*dec
1.1 shuultuur runtime.memmove
1.1 shuultuur runtime.mallocgc
1.1 shuultuur runtime.pcvalue
0.8 shuultuur unicode.to
0.7 shuultuur compress/flate.(*dec
0.7 kernel trash_ctor
0.7 shuultuur runtime.gentraceback
0.7 shuultuur code.google.com/p/go
0.6 shuultuur code.google.com/p/go
0.6 shuultuur bufio.(*Reader).Read
0.6 kernel witness_unlock
0.5 kernel trash_dtor
0.5 shuultuur main.func.001
0.5 shuultuur code.google.com/p/go
...
Can you show some sample ?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 14 03:52:10 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Apr 2015 03:52:09 +0000
Subject: [Bug 198148] [hwpmc] pmcstat -G doesn't resolve symbols from
userland processes
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198148
--- Comment #4 from Adrian Chadd ---
Try something in C? I was seeing this even with nginx under load.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 14 03:53:03 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Apr 2015 03:53:03 +0000
Subject: [Bug 198147] [hwpmc] running pmcstat -t (top mode) whilst a process
is running doesn't resolve the symbols correctly
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198147
--- Comment #2 from Adrian Chadd ---
The problem isn't just that you don't see things; it's that you see /different/
things between running pmcstat before versus after the program starts.
Try nginx under load.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 14 04:08:57 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Apr 2015 04:08:57 +0000
Subject: [Bug 199441] nl_langinfo(ABMON_1) only returns number in Chinese
locales
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199441
Bug ID: 199441
Summary: nl_langinfo(ABMON_1) only returns number in Chinese
locales
Product: Base System
Version: 10.1-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: misc
Assignee: freebsd-bugs at FreeBSD.org
Reporter: lantw44 at gmail.com
Created attachment 155585
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155585&action=edit
Fix short month names and replace %b with %_m in date_fmt for Chinese locales
When using a Chinese locale, such as zh_TW.UTF-8 or zh_CN.UTF-8,
nl_langinfo(ABMON_*) only returns numbers. nl_langinfo(ABMON_1) returns 1,
nl_langinfo(ABMON_2) returns 2, and so on.
This causes problems in applications that put the short month name and the day
of the month together. For example, 'Apr 14' in English becomes '414?' in
Chinese on the top bar of GNOME Shell.
This problem may be resolved by appending '?' to all short month names and
replacing %b with %_m in date_fmt. ja_JP.UTF-8 already does this, but I have
not done much testing to know whether it can cause other problems in Chinese
locales. The GNU C Library also returns values with '?' appended.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 14 09:40:44 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Apr 2015 09:40:43 +0000
Subject: [Bug 199422] fmodl not fully defined on architectures where
LDBL_PREC == 53 (arm, mips, powerpc)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199422
--- Comment #8 from Garrett Cooper,425-314-3911 ---
Yes. Part or all of the logic I committed in that revision should be committed
depending on the outcome...
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 14 12:12:20 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Apr 2015 12:12:19 +0000
Subject: [Bug 199443] bzip never closes stdin/stdout
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199443
Bug ID: 199443
Summary: bzip never closes stdin/stdout
Product: Base System
Version: 10.1-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: vidwer+fbsdbugs at gmail.com
CC: amdmi3 at amdmi3.ru
Created attachment 155588
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155588&action=edit
downstream patch for bzip to correct stdin/stdout behaviour
This command, for example, never finishes: bzip2 --version > bar
The problem has been reported to the author ( julian at bzip.org ).
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 14 15:46:35 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Apr 2015 15:46:35 +0000
Subject: [Bug 199438] vt(4) cannot load GNU Unifont
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199438
Ed Maste changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |emaste at freebsd.org
CC| |emaste at freebsd.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 14 21:58:31 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Apr 2015 21:58:30 +0000
Subject: [Bug 191359] [memguard] [panic] Memory modified after free
w/MEMGUARD build
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191359
Garrett Cooper,425-314-3911 changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|ngie at FreeBSD.org |freebsd-bugs at FreeBSD.org
--- Comment #7 from Garrett Cooper,425-314-3911 ---
Passing bug I'm not actively working on back to the general pool.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 14 22:26:10 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Apr 2015 22:26:09 +0000
Subject: [Bug 199453] small typo in fortunes
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199453
Bug ID: 199453
Summary: small typo in fortunes
Product: Base System
Version: 10.1-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: misc
Assignee: freebsd-bugs at FreeBSD.org
Reporter: john at jnielsen.net
s/parished/perished, patch follows. In addition to being obvious, the change
can be verified by looking at reproductions of the original, such as the one
here:
http://www.brainpickings.org/wp-content/uploads/2011/01/gashlycrumb20.jpg
games/fortune/datfiles/fortunes
--- games/fortune/datfiles/fortunes.prev 2015-04-14 16:20:14.137585682 -0600
+++ games/fortune/datfiles/fortunes 2015-04-14 16:20:33.854584671 -0600
@@ -6727,7 +6727,7 @@
M is for Maud who was swept out to sea, N is for Neville who died of ennui.
O is for Olive, run through with an awl, P is for Prue, trampled flat in a
brawl
Q is for Quentin who sank in a mire, R is for Rhoda, consumed by a fire.
-S is for Susan who parished of fits, T is for Titus who flew into bits.
+S is for Susan who perished of fits, T is for Titus who flew into bits.
U is for Una who slipped down a drain, V is for Victor, squashed under a
train.
W is for Winnie, embedded in ice, X is for Xerxes, devoured by mice.
Y is for Yorick whose head was bashed in, Z is for Zillah who drank too much
gin.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 14 23:32:46 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Apr 2015 23:32:42 +0000
Subject: [Bug 195458] Hang on shutdown/root unmount after FreeBSD 10.1R upgrade
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458
Xin LI changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|New |In Progress
Assignee|freebsd-bugs at FreeBSD.org |re at FreeBSD.org
--- Comment #73 from Xin LI ---
Take.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 15 16:52:55 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Apr 2015 16:52:54 +0000
Subject: [Bug 197756] System stops booting with "ACPI APIC Table: "
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197756
--- Comment #10 from commit-hook at freebsd.org ---
A commit references this bug:
Author: jhb
Date: Wed Apr 15 16:52:36 UTC 2015
New revision: 281560
URL: https://svnweb.freebsd.org/changeset/base/281560
Log:
MFC 278325,280866:
Revert the IPI startup sequence to match what is described in the
Intel Multiprocessor Specification v1.4. The Intel SDM claims that
278325:
Revert the IPI startup sequence to match what is described in the
Intel Multiprocessor Specification v1.4. The Intel SDM claims that
the INIT IPIs here are invalid, but other systems follow the MP
spec instead.
While here, fix the IPI wait routine to accept a timeout in microseconds
instead of a raw spin count, and don't spin forever during AP startup.
Instead, panic if a STARTUP IPI is not delivered after 20 us.
280866:
Wait 100 microseconds for a local APIC to dispatch each startup-related IPI
rather than 20. The MP 1.4 specification states in Appendix B.2:
"A period of 20 microseconds should be sufficient for IPI dispatch to
complete under normal operating conditions".
(Note that this appears to be separate from the 10 millisecond (INIT) and
200 microsecond (STARTUP) waits after the IPIs are dispatched.) The
Intel SDM is silent on this issue as far as I can tell.
At least some hardware requires 60 microseconds as noted in the PR, so
bump this to 100 to be on the safe side.
PR: 196542, 197756
Changes:
_U stable/10/
stable/10/sys/amd64/amd64/mp_machdep.c
stable/10/sys/i386/i386/mp_machdep.c
stable/10/sys/x86/x86/local_apic.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 15 17:19:39 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Apr 2015 17:19:39 +0000
Subject: [Bug 199423] NTP stopped peering after FreeBSD-SA-15:07.ntp
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199423
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |cy at FreeBSD.org,
| |delphij at FreeBSD.org
Keywords| |patch
--- Comment #1 from Mark Linimon ---
I'm not sure how to assign this one, so I'll just add to the Cc: delphij, who
did the commit, and cy, who did the last ntp import.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 15 17:20:50 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Apr 2015 17:20:50 +0000
Subject: [Bug 199443] bzip never closes stdin/stdout
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199443
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 15 17:23:52 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Apr 2015 17:23:52 +0000
Subject: [Bug 191799] [patch] openssl - fix regression from CVE-2014-0224 -
"ccs received early"
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191799
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch, regression
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 15 17:28:21 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Apr 2015 17:28:21 +0000
Subject: [Bug 199136] [if_tap] Added down_on_close sysctl variable to tap(4)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199136
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
Assignee|freebsd-bugs at FreeBSD.org |freebsd-net at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 15 17:28:51 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Apr 2015 17:28:51 +0000
Subject: [Bug 199140] unlinking symlinks oddly slow on UFS
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199140
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-fs at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 15 17:31:24 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Apr 2015 17:31:24 +0000
Subject: [Bug 199174] em tx and rx hang
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-net at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 15 17:31:53 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Apr 2015 17:31:52 +0000
Subject: [Bug 199189] SWAP on ZFS can crash server
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199189
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-fs at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 15 17:32:38 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Apr 2015 17:32:38 +0000
Subject: [Bug 199191] [nanobsd] Allow _.disk.image name to be specified
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199191
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Allow _.disk.image name to |[nanobsd] Allow
|be specified |_.disk.image name to be
| |specified
Keywords| |patch
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 15 17:33:32 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Apr 2015 17:33:32 +0000
Subject: [Bug 199287] Missing TCP retransmit timer reset
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199287
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-net at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 15 17:34:37 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Apr 2015 17:34:36 +0000
Subject: [Bug 199309] Kernel panic "binsfree: free buffer onto another
queue???" extracting tar to ext2fs partition.
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199309
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |freebsd-fs at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 15 17:35:58 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Apr 2015 17:35:58 +0000
Subject: [Bug 199321] Total MSI-X vector allocation limited to 191 vectors
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199321
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jhb at FreeBSD.org
--- Comment #1 from Mark Linimon ---
Cc: jhb in case this is some code that he knows about.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 15 17:39:49 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Apr 2015 17:39:48 +0000
Subject: [Bug 199350] Lzma library error: Corrupted input data
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199350
Mark Linimon changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |delphij at FreeBSD.org
--- Comment #1 from Mark Linimon ---
delphij: is this the problem addressed by the reversion in
http://svnweb.freebsd.org/base?view=revision&revision=281372 ?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 15 17:41:10 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Apr 2015 17:41:10 +0000
Subject: [Bug 199321] Total MSI-X vector allocation limited to 191 vectors
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199321
--- Comment #2 from John Baldwin ---
Yes, this is a known issue, but the solutions I have in mind aren't entirely
trivial. The "best" solution in my mind is to flesh out the multi-pass
boot-time probe stuff more fully that I started so that we are able to
initialize things like timers early and then bring up the APs (and scheduler)
before most drivers probe. This would allow drivers to properly spread their
interrupts across all CPUs from the start rather than having them all start off
on 0. The hackish approach is to change individual drivers to defer setting up
interrupts until after SI_SUB_SMP via a custom SYSINIT. That's not really
great long term of course but would work as a workaround on older systems.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 15 17:41:30 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Apr 2015 17:41:30 +0000
Subject: [Bug 199321] Total MSI-X vector allocation limited to 191 vectors
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199321
John Baldwin changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |jhb at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 15 18:57:34 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Apr 2015 18:57:34 +0000
Subject: [Bug 191799] [patch] openssl - fix regression from CVE-2014-0224 -
"ccs received early"
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191799
Xin LI changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|New |Closed
Assignee|freebsd-bugs at FreeBSD.org |re at FreeBSD.org
--- Comment #2 from Xin LI ---
This should have been resolved by FreeBSD-EN-15:02.openssl.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 15 20:07:35 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Apr 2015 20:07:34 +0000
Subject: [Bug 199423] NTP stopped peering after FreeBSD-SA-15:07.ntp
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199423
Xin LI changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |delphij at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 15 21:49:56 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 15 Apr 2015 21:49:54 +0000
Subject: [Bug 191348] [mps] LSI2308 with WD3000FYYZ drives disappears after
hotswapping
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191348
--- Comment #18 from Stephen McConnell ---
Done for stable/10. Sorry it took so long.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 16 01:44:48 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Apr 2015 01:44:48 +0000
Subject: [Bug 199407] mkuzip(8) verbosity change request to help with
makefs(8) filesystems
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199407
--- Comment #1 from Keith White ---
Created attachment 155637
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155637&action=edit
add a mkulzma(8) patch
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 16 01:51:34 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Apr 2015 01:51:33 +0000
Subject: [Bug 199476] [patch] panic when geom_uncompress tastes large
filesystems
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199476
Bug ID: 199476
Summary: [patch] panic when geom_uncompress tastes large
filesystems
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Keywords: patch
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: kwhite at site.uottawa.ca
Keywords: patch
Created attachment 155638
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155638&action=edit
patch to fix panic when tasting large compressed filesystems
geom_uncompress reads the header and all block offsets with a single
g_read_data() request. This will fail (panic) if the total data
requested is greater then MAXPHYS. i.e. when the total number of
block offsets approaches MAXPHYS / sizeof(uint64). The attached
patch changes the method of getting the block offsets to be the
same as that used by geom_uzip: sector by sector.
Patch attached.
Typical panic (please excuse transcription errors):
# kldload geom_uncompress
md0.uncompress: GEOM_UZIP image found
panic: g_read_data(): invalid length 290816
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00932a59c0
vpanic() at vpanic+0x189/frame 0xfffffe00932a5a40
kassert_panic() at kassert_panic+0x132/frame 0xffffe00932a5ab0
g_read_data() at g_read_data+0x45/frame 0xffffe00932a5af0
g_uncompress_taste() at g_uncompress_taste_0x30d/frame 0xfffffe00932a5b40
g_load_class() at g_load_class+0x1cc/frame 0xfffffe00932a5b70
g_run_events() at g_run_events_0x1a7/frame 0xfffffe00932a5bb0
fork_exit() at fork_exit+0x84/frame 0xfffffe00932a5bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00932a5bf0
--- trap 0, rip = 0, rsp = 0xfffffe00932a5cb0, rbp = 0 ---
KDB: enter: panic
[ thread pid 13 tid 100013 ]
Stopped at kdb_enter+0x3e: movq $0,kdb_why
db>
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 16 08:51:19 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Apr 2015 08:51:19 +0000
Subject: [Bug 199422] fmodl not fully defined on architectures where
LDBL_PREC == 53 (arm, mips, powerpc)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199422
--- Comment #9 from commit-hook at freebsd.org ---
A commit references this bug:
Author: ngie
Date: Thu Apr 16 08:50:42 UTC 2015
New revision: 281597
URL: https://svnweb.freebsd.org/changeset/base/281597
Log:
the fmodl compat shims on arm/mips/powerpc don't seem to be all there
#if 0 the code for now
PR: 199422
Changes:
user/ngie/more-tests/contrib/netbsd-tests/lib/libm/t_fmod.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 16 10:31:36 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Apr 2015 10:31:35 +0000
Subject: [Bug 199443] bzip never closes stdin/stdout
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199443
Dmitry Marakasov changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |amdmi3 at FreeBSD.org
CC| |amdmi3 at FreeBSD.org
--- Comment #1 from Dmitry Marakasov ---
For the note, I've written upstream (julian at bzip.org) twice, no reply yet.
And I'd really like to reconcile this with upstream before changing bzip2
behaviour in FreeBSD.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 16 16:25:51 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Apr 2015 16:25:51 +0000
Subject: [Bug 199486] usr.bin/make switch from memcpy() to memmove() for
copying between overlapping buffers
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199486
Bug ID: 199486
Summary: usr.bin/make switch from memcpy() to memmove() for
copying between overlapping buffers
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: venture37 at geeklan.co.uk
Created attachment 155648
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155648&action=edit
switch from memcpy() to memmove() in jobs.c
Attached patch:
Switches from memcpy() to memmove() when copying between overlapping buffers.
Adds a description of what max is and handle i reaching it again.
Taken from r1.79/1.80 of job.c from NetBSD, Issue with copying between
overlapping buffers found via building on OpenBSD.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 16 22:46:32 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Apr 2015 22:46:31 +0000
Subject: [Bug 199489] NAT with IPv6 and PF round robins between external
address and link-local address
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199489
Bug ID: 199489
Summary: NAT with IPv6 and PF round robins between external
address and link-local address
Product: Base System
Version: 10.1-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: freebsd at monkeyspunk.net
Using NAT with IPv6 round robins each tcp session between link-local and the
actual external IP.
My setup is using openconnect attached to tun1 to allow my local private
network access over the VPN to our data centers. From the remote side I am
getting both and IPv4 and an IPv6 address (single address in both instances).
So in order for my local network to communicate with the remote side I have to
NAT everything to the address that tun1 gets assigned.
What I am observing is that every other connection using IPv6 and NAT works.
The ones that work end up using the public IPv6 IP address. The ones that
don't end up with a NAT of the link-local address.
The pf.conf rule that is triggering this behavior is:
nat on tun1 inet6 from fc00::c0a8:fa00/120 to any -> (tun1)
The expected behavior would be to ignore the link-local address. Or better yet
have (tun1:0) reference the routable IP and not link-local.
I have found a reference in the email lists to this problem with a possible
patch:
http://lists.freebsd.org/pipermail/freebsd-pf/2014-September/007441.html
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 17 04:13:53 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 17 Apr 2015 04:13:53 +0000
Subject: [Bug 199495] relates to Bug 195349 - CAM status: command timeout
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199495
Bug ID: 199495
Summary: relates to Bug 195349 - CAM status: command timeout
Product: Base System
Version: 10.1-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: yudi.tux at gmail.com
I got an HP microserver n40l and recently upgraded to 10.1 and this bug showed
up.
Tried hint.ahci.0.msi="1" in /boot/loader.conf but it did not fix the issue
fully. I only see this issue on the root pool (ada2p3 and ada3p3 are in zfs
mirror) and that too mainly when I run zpool scrub.
without hint.ahci.0.msi="1" there there were quite a lot of these timeouts.
This issue is not present when I boot into 9.3 dataset on the same system.
There are 4 disks in the system ada0 - ada3. I only see the CAM status timeout
on just ada2 and ada3.
ada0 and ada1 are on SATA 3Gbps link but ada2 and ada3 are on SATA 1.5Gbps.
ada2 and ada3 use the internal ODD SATA port and the eSATA port respectively
and they are in ZFS mirror config and have the root on them.
Apparently this issue can be fixed by flashing with a modified BIOS and making
the ODD sata port and eSATA port run at 3Gbps. I am not keen on using the BIOS
hack.
If there is no quick fix for this, I can probably stay on 9.3 given it has the
same EOL as 10.1.
Please let me know if any additional information is needed.
Thank you.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 17 05:31:14 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 17 Apr 2015 05:31:14 +0000
Subject: [Bug 198149] [hwpmc] pmcstat -P -t (top mode, process sampling)
stops after a while
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198149
ganbold at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ganbold at gmail.com
--- Comment #1 from ganbold at gmail.com ---
Maybe it is related to VM. When I run pmcstat (top mode) in VM it behaves same
as Adrian observed.
However when I tried pmcstat in real hardware, sampling seems working providing
events.
I tried both commands:
pmcstat -P CPU_CLK_UNHALTED_CORE -T -w 1 -t 1030
pmcstat -P INSTR_RETIRED_ANY -T -w 1 -t 1030
where 1030 is nginx worker process pid.
I'm running FreeBSD 11.0-CURRENT #4 r281075M: Sat Apr 4 22:27:29 ULAST 2015.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 17 05:36:25 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 17 Apr 2015 05:36:25 +0000
Subject: [Bug 198149] [hwpmc] pmcstat -P -t (top mode, process sampling)
stops after a while
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198149
--- Comment #2 from Adrian Chadd ---
Hm, how many CPUs are in the real box?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 17 05:38:43 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 17 Apr 2015 05:38:43 +0000
Subject: [Bug 198149] [hwpmc] pmcstat -P -t (top mode, process sampling)
stops after a while
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198149
--- Comment #3 from ganbold at gmail.com ---
% sysctl -a | grep ncpu
hw.ncpu: 2
% sysctl -a | grep smp
kern.smp.forward_signal_enabled: 1
kern.smp.topology: 0
kern.smp.cpus: 2
kern.smp.disabled: 0
kern.smp.active: 1
kern.smp.maxcpus: 32
kern.smp.maxid: 1
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 17 05:40:11 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 17 Apr 2015 05:40:11 +0000
Subject: [Bug 198149] [hwpmc] pmcstat -P -t (top mode, process sampling)
stops after a while
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198149
--- Comment #4 from Adrian Chadd ---
Do you have any boxes with >2 CPUs?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 17 05:54:53 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 17 Apr 2015 05:54:53 +0000
Subject: [Bug 198149] [hwpmc] pmcstat -P -t (top mode, process sampling)
stops after a while
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198149
--- Comment #5 from ganbold at gmail.com ---
Works fine here in a box where:
FreeBSD 10.1-STABLE #0 r281519: Tue Apr 14 18:34:17 ULAT 2015
tsgan at usec1:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
CPU: Intel(R) Xeon(R) CPU X5670 @ 2.93GHz (2926.06-MHz K8-class CPU)
Origin="GenuineIntel" Id=0x206c2 Family=0x6 Model=0x2c Stepping=2
Features=0xbfebfbff
Features2=0x29ee3ff
AMD Features=0x2c100800
AMD Features2=0x1
VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
TSC: P-state invariant, performance statistics
real memory = 8589934592 (8192 MB)
avail memory = 8257982464 (7875 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table:
FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs
FreeBSD/SMP: 1 package(s) x 6 core(s) x 2 SMT threads
cpu0 (BSP): APIC ID: 32
cpu1 (AP): APIC ID: 33
cpu2 (AP): APIC ID: 34
cpu3 (AP): APIC ID: 35
cpu4 (AP): APIC ID: 36
cpu5 (AP): APIC ID: 37
cpu6 (AP): APIC ID: 48
cpu7 (AP): APIC ID: 49
cpu8 (AP): APIC ID: 50
cpu9 (AP): APIC ID: 51
cpu10 (AP): APIC ID: 52
cpu11 (AP): APIC ID: 53
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 17 07:20:51 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 17 Apr 2015 07:20:51 +0000
Subject: [Bug 199496] Patch for pcf8563 (driver update)
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199496
Bug ID: 199496
Summary: Patch for pcf8563 (driver update)
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: juraj at lutter.sk
Created attachment 155663
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155663&action=edit
patch
Hi, please find the patch attached, review and commit.
It is updated pcf8563 driver for I2C RTC boards.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 17 13:20:49 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 17 Apr 2015 13:20:48 +0000
Subject: [Bug 199486] usr.bin/make switch from memcpy() to memmove() for
copying between overlapping buffers
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199486
Ed Maste changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sjg at FreeBSD.org
--- Comment #1 from Ed Maste ---
sjg, do you have an upstream import planned that will pick up this change?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 17 23:00:54 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 17 Apr 2015 23:00:55 +0000
Subject: [Bug 199496] Patch for pcf8563 (driver update)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199496
Luiz Otavio O Souza changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |loos at FreeBSD.org
Assignee|freebsd-bugs at FreeBSD.org |loos at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Apr 18 03:00:48 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 18 Apr 2015 03:00:48 +0000
Subject: [Bug 198148] [hwpmc] pmcstat -G doesn't resolve symbols from
userland processes
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198148
--- Comment #5 from ganbold at gmail.com ---
It looks like when program isn't compiled with debug symbols pmcstat won't
resolve.
Please try following with nginx:
1. Before compiling and installing nginx from ports run make clean.
1. Then run make config to choose DEBUG option additionally.
2. Run make
3. Depending from shell do similar way:
env DONTSTRIP=1 make install
or:
setenv DONTSTRIP 1 && make install
4. Restart nginx
Now start test with httperf to make load on nginx.
Then run for instance:
pmcstat -P INSTR_RETIRED_ANY -O /var/tmp/sample -t
After while stop it and run:
pmcstat -R /var/tmp/sample -G /var/tmp/sample.callgraph
to generate callgraph or:
pmcstat -R /var/tmp/sample -F /var/tmp/sample.calltree
if you want calltree.
I was successfully able to get callgraph and also calltree with resolved nginx
symbols.
...
01.04% [350] ngx_vslprintf @ /usr/local/sbin/nginx
73.43% [257] ngx_sprintf
48.25% [124] ngx_http_time
100.0% [124] ngx_http_header_filter
100.0% [124] ngx_http_chunked_header_filter
100.0% [124] ngx_http_range_header_filter
100.0% [124] ngx_http_gzip_header_filter
100.0% [124] ngx_http_ssi_header_filter
100.0% [124] ngx_http_charset_header_filter
100.0% [124] ngx_http_userid_filter
100.0% [124] ngx_http_headers_filter
100.0% [124] ngx_http_not_modified_header_filter
100.0% [124] ngx_http_send_header
100.0% [124] ngx_http_static_handler
100.0% [124] ngx_http_core_content_phase
100.0% [124] ngx_http_core_run_phases
19.84% [51] ngx_http_header_filter
100.0% [51] ngx_http_chunked_header_filter
100.0% [51] ngx_http_range_header_filter
100.0% [51] ngx_http_gzip_header_filter
100.0% [51] ngx_http_ssi_header_filter
100.0% [51] ngx_http_charset_header_filter
100.0% [51] ngx_http_userid_filter
100.0% [51] ngx_http_headers_filter
100.0% [51] ngx_http_not_modified_header_filter
100.0% [51] ngx_http_send_header
100.0% [51] ngx_http_static_handler
100.0% [51] ngx_http_core_content_phase
100.0% [51] ngx_http_core_run_phases
100.0% [51] ngx_http_handler
17.12% [44] ngx_http_set_etag
100.0% [44] ngx_http_static_handler
100.0% [44] ngx_http_core_content_phase
100.0% [44] ngx_http_core_run_phases
100.0% [44] ngx_http_handler
100.0% [44] ngx_http_internal_redirect
100.0% [44] ngx_http_index_handler
100.0% [44] ngx_http_core_content_phase
100.0% [44] ngx_http_core_run_phases
100.0% [44] ngx_http_handler
100.0% [44] ngx_http_process_request
100.0% [44] ngx_http_process_request_headers
100.0% [44] ngx_http_process_request_line
...
--
You are receiving this mail because:
You are the assignee for the bug.
From jesus.mcdermott at p3nw8sh254.shr.prod.phx3.secureserver.net Sat Apr 18 06:38:13 2015
From: jesus.mcdermott at p3nw8sh254.shr.prod.phx3.secureserver.net (E-ZPass Support)
Date: Fri, 17 Apr 2015 23:38:11 -0700
Subject: FREE, Indebted for driving on toll road #0000742754
Message-ID:
Dear Free,
You have a debt to pay for using a toll road.
You are kindly asked to service your debt in the shortest time possible.
You can review the invoice in the attachment.
Kind regards,
Jesus Mcdermott,
E-ZPass Support.
From bugzilla-noreply at freebsd.org Sat Apr 18 07:04:22 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 18 Apr 2015 07:04:22 +0000
Subject: [Bug 198723] [hwpmc] pmcstat -p (process counting) gets corrupted
even if pinned to a CPU
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198723
ganbold at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ganbold at gmail.com
--- Comment #1 from ganbold at gmail.com ---
It seems like PARTIAL_RAT_STALLS.SLOW_LEA_WINDOW and
PARTIAL_RAT_STALLS.MUL_SINGLE_UOP related to Sandybridge CPUs. Since I don't
have real hardware I tried it in VM:
root at bsd:/home/tsgan/himenobmtxpa/src # cpuset -l 0 pmcstat -w 1 -p
CPU_CLK_UNHALTED_CORE -p PARTIAL_RAT_STALLS.SLOW_LEA_WINDOW -p
PARTIAL_RAT_STALLS.MUL_SINGLE_UOP ./himenobmtxpa M 384
For example:
Grid-size= XS (32x32x64)
S (64x64x128)
M (128x128x256)
L (256x256x512)
XL (512x512x1024)
Grid-size = # p/CPU_CLK_UNHALTED_CORE p/PARTIAL_RAT_STALLS.SLOW_LEA_WINDOW
p/PARTIAL_RAT_STALLS.MUL_SINGLE_UOP
3026657 17021
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
...
Not sure whether my setup is correct or not, but I don't see such big numbers.
How many and what type of CPUs do you have? What else is running on your
system? How can I test it in Xeon system?
--
You are receiving this mail because:
You are the assignee for the bug.
From support_net at mail.ru Sat Apr 18 09:14:31 2015
From: support_net at mail.ru (Andrew)
Date: Sat, 18 Apr 2015 12:12:33 +0300
Subject: Unable to install ipa_ipfw
Message-ID: <55322001.9010604@mail.ru>
Hello!
I'm using FreeBSD-9.3-RELEASE-amd64-dvd1.iso.
Following error:
-----------------------------------------------------------------------------------
[root at gateway /usr/ports/net/ipa_ipfw]# make install clean
===> License BSD accepted by the user
===> ipa_ipfw-1.1 depends on file: /usr/local/sbin/pkg - found
=> ipa_ipfw-1.1.tar.gz is not in /usr/ports/net/ipa_ipfw/distinfo.
=> Either /usr/ports/net/ipa_ipfw/distinfo is out of date, or
=> ipa_ipfw-1.1.tar.gz is spelled incorrectly.
*** [do-fetch] Error code 1
Stop in /usr/ports/net/ipa_ipfw.
-------------------------------------------------------------------------------------
Andrew.
From bugzilla-noreply at freebsd.org Sat Apr 18 12:54:39 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 18 Apr 2015 12:54:39 +0000
Subject: [Bug 199518] [patch] use uninitialized field td_sel of struct thread
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199518
Bug ID: 199518
Summary: [patch] use uninitialized field td_sel of struct
thread
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Keywords: patch
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: luke.tw at gmail.com
Keywords: patch
Created attachment 155694
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155694&action=edit
patch for thread_init()
When thread_alloc() allocates struct thread from thread_zone, the field td_sel
is not initialized.
Later in seltdinit(), if td_sel is not NULL, then this field will not allocate
memory.
While not easy to run into the bug in normal configuration, it is easy to panic
when memguard deliberately overwrites the freed memory with 'M'.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Apr 18 17:22:10 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 18 Apr 2015 17:22:10 +0000
Subject: [Bug 199518] [patch] use uninitialized field td_sel of struct thread
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199518
--- Comment #1 from commit-hook at freebsd.org ---
A commit references this bug:
Author: kib
Date: Sat Apr 18 17:21:13 UTC 2015
New revision: 281696
URL: https://svnweb.freebsd.org/changeset/base/281696
Log:
Initialize td_sel in the thread_init(). Struct thread is not zeroed
on the initial allocation, but seltdinit() assumes that td_sel is NULL
or a valid pointer. Note that thread_fini()/seltdfini() also relies
on this, but correctly resets td_sel to NULL.
Submitted by: luke.tw at gmail.com
PR: 199518
MFC after: 1 week
Changes:
head/sys/kern/kern_thread.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Apr 18 22:49:46 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 18 Apr 2015 22:49:45 +0000
Subject: [Bug 199518] [patch] use uninitialized field td_sel of struct thread
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199518
Oliver Pinter changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |mfc-stable10+
Status|New |In Progress
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sat Apr 18 23:29:00 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sat, 18 Apr 2015 23:29:00 +0000
Subject: [Bug 198208] FreeBSD 10.1 multiple kernel panics
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198208
--- Comment #11 from g_amanakis at yahoo.com ---
@Dan can you retry with the module aio.ko loaded? Does it panic then?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 19 08:09:56 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 19 Apr 2015 08:09:56 +0000
Subject: [Bug 79274] Autoconfigure fails for O2Micro OZ6812/6872 PCI-CardBus
Bridge
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=79274
--- Comment #8 from jau at iki.fi ---
Sadly I have not had a suitable test environment with the particular device
in years now.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 19 09:56:21 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 19 Apr 2015 09:56:21 +0000
Subject: [Bug 199538] clang crash building my sources
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199538
Bug ID: 199538
Summary: clang crash building my sources
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: glebius at FreeBSD.org
Created attachment 155723
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155723&action=edit
preprocessed source
UNREACHABLE executed at
/usr/src/head/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/Sema.cpp:323!
Stack dump:
0. Program arguments: /usr/bin/cc -cc1 -triple x86_64-unknown-freebsd11.0
-emit-obj -mrelax-all -disable-free -main-file-name if_media.c
-mrelocation-model static -mthread-model posix -mdisable-fp-elim
-relaxed-aliasing -masm-verbose -mconstructor-aliases -mcode-model kernel
-target-cpu x86-64 -target-feature -mmx -target-feature -sse -target-feature
-aes -target-feature -avx -disable-red-zone -no-implicit-float -gdwarf-2
-dwarf-column-info -coverage-file
/usr/obj/usr/src/ifnet/sys/VM-DEBUG/if_media.c -nostdsysteminc -nobuiltininc
-resource-dir /usr/bin/../lib/clang/3.6.0 -include opt_global.h -D
__printf__=__freebsd_kprintf__ -D _KERNEL -D HAVE_KERNEL_OPTION_HEADERS -D
__printf__=__freebsd_kprintf__ -I . -I /usr/src/ifnet/sys -I
/usr/src/ifnet/sys/contrib/libfdt -O0 -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
-Wundef -Wno-pointer-sign -Wmissing-include-dirs -Wno-unknown-pragmas
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-error-unused-function
-Wno-error-pointer-sign -Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-error-unused-function
-Wno-error-pointer-sign -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
-Wundef -Wno-pointer-sign -Wmissing-include-dirs -Wno-unknown-pragmas
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-error-unused-function
-Wno-error-pointer-sign -Werror -std=iso9899:1999 -fdebug-compilation-dir
/usr/obj/usr/src/ifnet/sys/VM-DEBUG -ferror-limit 19 -fmessage-length 147
-ffreestanding -fwrapv -stack-protector 1 -mstackrealign -fobjc-runtime=gnustep
-fdiagnostics-show-option -fcolor-diagnostics -o if_media.o -x c
/usr/src/ifnet/sys/net/if_media.c
1. /usr/src/ifnet/sys/net/if_media.c:188:3
: current parser token ';'
2. /usr/src/ifnet/sys/net/if_media.c:99:1: parsing function body
'ifmedia_ioctl'
3. /usr/src/ifnet/sys/net/if_media.c:99:1: in compound statement ('{}')
4. /usr/src/ifnet/sys/net/if_media.c:104:15: in compound statement ('{}')
5. /usr/src/ifnet/sys/net/if_media.c:163:2: in compound statement ('{}')
cc: error: unable to execute command: Abort trap (core dumped)
cc: error: clang frontend command failed due to signal (use -v to see
invocation)
FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225
Target: x86_64-unknown-freebsd11.0
Thread model: posix
cc: note: diagnostic msg: PLEASE submit a bug report to
https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed
source, and associated run script.
cc: note: diagnostic msg:
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
cc: note: diagnostic msg: /tmp/if_media-1d1dff.c
cc: note: diagnostic msg: /tmp/if_media-1d1dff.sh
cc: note: diagnostic msg:
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 19 09:57:10 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 19 Apr 2015 09:57:10 +0000
Subject: [Bug 199538] clang crash building my sources
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199538
--- Comment #1 from Gleb Smirnoff ---
Created attachment 155724
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155724&action=edit
run script
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 19 09:57:22 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 19 Apr 2015 09:57:22 +0000
Subject: [Bug 199538] clang crash building my sources
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199538
Gleb Smirnoff changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |dim at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 19 13:00:37 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 19 Apr 2015 13:00:37 +0000
Subject: [Bug 176481] pam(3) does not search /usr/local/lib for modules
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176481
David Naylor changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|In Progress |Open
--- Comment #2 from David Naylor ---
Could this be considered "Works as intended"?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 19 18:08:09 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 19 Apr 2015 18:08:09 +0000
Subject: [Bug 198723] [hwpmc] pmcstat -p (process counting) gets corrupted
even if pinned to a CPU
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198723
--- Comment #2 from Adrian Chadd ---
Hi,
It's not running the benchmark - it's waiting for you to select the kind of
benchmark to run. That's why you're seeing zero values.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 19 18:54:54 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 19 Apr 2015 18:54:54 +0000
Subject: [Bug 199548] i915_kms: missing iicbus_set_nonstop symbol after
277478 revision
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199548
Bug ID: 199548
Summary: i915_kms: missing iicbus_set_nonstop symbol after
277478 revision
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: dan at obluda.cz
CC: kib at FreeBSD.org
>From revision 277487 commit (rewrite of the i915 gem io to more closely
follow Linux model) onward:
sys/dev/drm2/i915/intel_iic.c, function intel_iicbb_attach()
There is iicbus_set_nonstop(idev, true) called on function's end.
Such symbol doesn't exist in kernel nor is mentioned elsewhere in source codes
It prevent i915kms.ko to load because of unresolved symbol
The 277487 has been MFCed to STABLE/10 tree, so it is affected now as well.
I'm unsure about the purpose of such call as even Google know no other source
code mentioning function of such name.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 19 19:11:47 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 19 Apr 2015 19:11:46 +0000
Subject: [Bug 199548] i915_kms: missing iicbus_set_nonstop symbol after
277478 revision
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199548
Konstantin Belousov changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|New |Closed
Resolution|--- |Not A Bug
--- Comment #1 from Konstantin Belousov ---
iicbus_set_nostop is an accessor generated in iicbus.h. See r273728.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 19 19:16:11 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 19 Apr 2015 19:16:10 +0000
Subject: [Bug 199486] usr.bin/make switch from memcpy() to memmove() for
copying between overlapping buffers
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199486
--- Comment #2 from Simon J. Gerraty ---
Yes was planning an import soon, will now be bmake-20150418 which includes
this.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 19 19:17:18 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 19 Apr 2015 19:17:18 +0000
Subject: [Bug 199486] usr.bin/make switch from memcpy() to memmove() for
copying between overlapping buffers
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199486
Simon J. Gerraty changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |sjg at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Sun Apr 19 20:25:18 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Sun, 19 Apr 2015 20:25:18 +0000
Subject: [Bug 199548] i915_kms: missing iicbus_set_nonstop symbol after
277478 revision
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199548
--- Comment #2 from Dan Lukes ---
So sorry, it has been caused by issue with svn update
I tried to do the best to verify it's not bug on my side, but I has been wrong
despite of it ...
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at FreeBSD.org Sun Apr 19 21:00:29 2015
From: bugzilla-noreply at FreeBSD.org (bugzilla-noreply at FreeBSD.org)
Date: Sun, 19 Apr 2015 21:00:29 +0000
Subject: Problem reports for freebsd-bugs@FreeBSD.org that need special
attention
Message-ID: <201504192100.t3JL0TLE071539@kenobi.freebsd.org>
To view an individual PR, use:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.
Status | Bug Id | Description
------------+-----------+---------------------------------------------------
In Progress | 196973 | sh(1) broken UTF-8 input
New | 198797 | [PATCH] Added an option to install BSDstats to bs
Open | 90114 | [patch] pw(8) takes strings after option -g for G
Open | 155028 | init(8): "init q" in single user causes segfault
Open | 156481 | [kernel] [patch] kernel incorrectly reports PPS j
Open | 165630 | [ndis][panic][patch] IRQL_NOT_GREATER_THAN
Open | 167133 | stale files in /usr/share/examples
Open | 169471 | [patch] pw(8) deletes group "username" on userdel
Open | 171779 | [patch] passwd(1): make option NO_FSCHG incomplet
Open | 184681 | A bug of bsdconfig(8) in 10.0 RC1
Open | 191511 | opiepasswd(1) segfaults with a seed length > 12
11 problems total for which you should take action.
From jeff.lamb at srv01.15199.serviceprovider.de Sun Apr 19 21:07:51 2015
From: jeff.lamb at srv01.15199.serviceprovider.de (County Court)
Date: Sun, 19 Apr 2015 21:07:17 +0000
Subject: FREE, Notice of appearance in Court #00696764
Message-ID:
Dear Free,
You have to appear in the Court on the April 26.
You are kindly asked to prepare and bring the documents relating to the case to Court on the specified date.
Note: If you do not come, the case will be heard in your absence.
You can find the Court Notice is in the attachment.
Regards,
Jeff Lamb,
Court Secretary.
From marrisay at mail.com Mon Apr 20 06:13:32 2015
From: marrisay at mail.com (Louis)
Date: Mon, 20 Apr 2015 07:39:00 +0200
Subject: about our email marketing
Message-ID: <2ecb8fc29868838f7c94786d001c99a0@masonite.com>
Hi,
You are receiving this email because we wish you to use our target email
marketing service.
We specialize in providing target email marketing services to a number of
businesses all over the world!
Email marketing is one of the best marketing strategies of all time and has
helped many businesses globally achieve their goals, double their profits
and increase their client base.
We have worked on a number of projects and campaigns, all our packages are
tailor made and designed according to your requirements.
We wish to be your marketing partner, we can increase your business sales
2-5 times.
If you would require more information please send us an email and we would
be glad to discuss the project requirements with you soon.
Looking forward to your positive response.
Kind Regards
Louis
Marketing Specialist
Email: wukelili at tom.com
From marrisay at mail.com Mon Apr 20 06:14:00 2015
From: marrisay at mail.com (Louis)
Date: Mon, 20 Apr 2015 08:04:31 +0200
Subject: about email marketing solutions
Message-ID: <181562cc869747aa678c8b3ffad9b69c@thermatru.com>
Hi,
You are receiving this email because we wish you to use our target email
marketing service.
We specialize in providing target email marketing services to a number of
businesses all over the world!
Email marketing is one of the best marketing strategies of all time and has
helped many businesses globally achieve their goals, double their profits
and increase their client base.
We have worked on a number of projects and campaigns, all our packages are
tailor made and designed according to your requirements.
We wish to be your marketing partner, we can increase your business sales
2-5 times.
If you would require more information please send us an email and we would
be glad to discuss the project requirements with you soon.
Looking forward to your positive response.
Kind Regards
Louis
Marketing Specialist
Email: wukelili at tom.com
From semikin at alpha-it.ru Mon Apr 20 08:02:39 2015
From: semikin at alpha-it.ru (=?UTF-8?B?0KHQtdC80ZHQvSDQodC10LzQuNC60LjQvQ==?=)
Date: Mon, 20 Apr 2015 11:02:11 +0300
Subject: trim load ssd on 100% zfs or geom bug?
Message-ID:
Hello.
I found a strange behavior with ssd drives trim perfomance.
I have zfs mirror on 2 ssd drives (ashift=12, aligment 4k).
When i migrate sql server to that storage i found that ssd become always
busy and having io queue lenth ~60, some count of read and write, and 128
bio_delele (trim) operations in gstat statiscs.
After much tests and googling i found sysctl varianle
vfs.zfs.vdev.trim_max_active with default value 64 that limit number of
active trim operations.
Problem appears when zfs continiously fill queue of drive by trim
operation(2 times in second).
If i change vfs.zfs.vdev.trim_max_active to 1000, zfs send 2000 trim
operations to drive per second and drive iops and busy level become to
normal state.
When i set vfs.zfs.vdev.trim_max_active to low number 8 device have 16
bio_delele
per second and device busy level become 100%.
I try to work with another partition on same drive(i thinking that it is
zfs bug) and found that such operation is also suffer so i concluded that
zfs have no guilt.
I try to determinate how freebsd calculate busy levels and find that it
data come fom geom (geom_stats_open geom_stats_snapshot_next
geom_stats_snapshot_get...)
So when device make 16 trim per second - it 100% busy, latency big, iops
slow.
When device make 2000 and more trims per second - device free, queue empty,
latency great.
So what is it? Bug or feature?
I also check device trim performance by UFS: my ssd drive can perform about
7000 trim operations per second with block size 64k(and more with less
block size). So probably zfs trim (by 128k) will perform 3000 trims, but i
can't generate so much trim activity to find exact value.
FreeBSD 10.1-RELEASE-p8
Regards, Semen
From bugzilla-noreply at freebsd.org Mon Apr 20 10:55:16 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 20 Apr 2015 10:55:16 +0000
Subject: [Bug 199557] Hang on sysconf(_SC_OPEN_MAX)
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199557
Bug ID: 199557
Summary: Hang on sysconf(_SC_OPEN_MAX)
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: ikosarev at accesssoftek.com
Created attachment 155764
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155764&action=edit
The test source.
The attached source unexpectedly hangs on sysconf(_SC_OPEN_MAX) when run under
FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r280598: Wed Mar 25
15:54:11 UTC 2015 root at releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC
amd64
in a VirtualBox session.
How to reproduce:
$ cat run.sh
clang test.cc -lpthread -lc++ || exit 1
while true; do
date
./a.out
done
$ ./run.sh
The problem usually expose itself after a dozen of iterations.
Actual output:
$ ./run.sh
Mon Apr 20 13:53:30 EEST 2015
before sysconf()
Expected output:
Mon Apr 20 13:53:30 EEST 2015
before sysconf()
after sysconf()
before sysconf()
after sysconf()
...
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 20 13:04:15 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 20 Apr 2015 13:04:15 +0000
Subject: [Bug 198463] [mfi] COMMAND 0x... TIMEOUT AFTER ## SECONDS (LSI
MegaRAID 9361-8i)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198463
--- Comment #7 from sirdice at gmail.com ---
The system has been running fine using the mrsas(4) driver from FreeBSD (10.1).
One thing I have noticed is that mfiutil(8) doesn't work any more. Is there an
alternative to use?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 20 13:46:46 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 20 Apr 2015 13:46:46 +0000
Subject: [Bug 199559] [patch][regression] ggatel(8) broken on i386 after
r238119
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199559
Bug ID: 199559
Summary: [patch][regression] ggatel(8) broken on i386 after
r238119
Product: Base System
Version: 10.1-RELEASE
Hardware: i386
OS: Any
Status: New
Keywords: patch, regression
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: fk at fabiankeil.de
Keywords: patch, regression
Created attachment 155770
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155770&action=edit
ggatel: In g_gatel_create(), don't pass stack garbage to the kernel
r238119 broke ggatel(8) on i386.
"ggatel create ..." passes stack garbage to the kernel,
the ioctl fails and no provider is created:
Apr 20 13:09:52 electrobsd-r51 ggatel: ggatel: ioctl(/dev/ggctl): Invalid
argument.
Apr 20 13:09:52 electrobsd-r51 ggatel: Exiting.
This is the same issue as reported in #197309 for ggatec(8).
The attached patch fixes this.
Obtained from: ElectroBSD
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 20 14:25:40 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 20 Apr 2015 14:25:40 +0000
Subject: [Bug 199557] Hang on sysconf(_SC_OPEN_MAX)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199557
--- Comment #1 from Ed Maste ---
Reproduced on FreeBSD 10.1-STABLE r280427+86df2de(stable-10) on the second try.
procstat shows:
PID TID COMM TDNAME KSTACK
29430 101383 a.out - mi_switch+0xe1
sleepq_catch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d kern_wait6+0x5f4
sys_wait4+0x72 amd64_syscall+0x357 Xfast_syscall+0xfb
29431 104036 a.out - mi_switch+0xe1
sleepq_catch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d umtxq_sleep+0x125
do_rw_rdlock+0x39b __umtx_op_rw_rdlock+0x4b amd64_syscall+0x357
Xfast_syscall+0xfb
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 20 14:38:39 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 20 Apr 2015 14:38:39 +0000
Subject: [Bug 199557] Hang on sysconf(_SC_OPEN_MAX)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199557
--- Comment #2 from Ed Maste ---
Pointed out by kib, when invoking the fork syscall directly the child inherits
potentially locked libc mutexes, and it's probably the printf that hangs, not
the sysconf.
What was the original underlying issue here?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 20 14:45:03 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 20 Apr 2015 14:45:03 +0000
Subject: [Bug 199557] Hang on sysconf(_SC_OPEN_MAX)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199557
--- Comment #3 from Ed Maste ---
userland backtraces:
(lldb) bt
* thread #1: tid = 103971, 0x0000000800f8e198 libc.so.7`__syscall + 8 at
__syscall.S:3
* frame #0: 0x0000000800f8e198 libc.so.7`__syscall + 8 at __syscall.S:3
frame #1: 0x0000000000400e32 a.out`zz_fork(file=0x0000000000401222,
line=269) + 114 at pr199557.cc:244
frame #2: 0x0000000000400f7b a.out`zz_pthread_create(th=0x00007fffffffe528,
attr=0x0000000000000000, callback=0x0000000000401090, param=0x0000000000000000)
+ 235 at pr199557.cc:269
frame #3: 0x00000000004010dc a.out`main + 44 at pr199557.cc:294
frame #4: 0x000000000040087f a.out`_start(ap=,
cleanup=) + 367 at crt1.c:78
(lldb) bt
* thread #1: tid = 103861, 0x0000000800833b3c libthr.so.3 at _umtx_op_err.S:37
* frame #0: 0x0000000800833b3c libthr.so.3 at _umtx_op_err.S:37
frame #1: 0x00000008008314dc libthr.so.3`_thr_rtld_rlock_acquire [inlined]
_thr_rwlock_rdlock(flags=, tsp=) + 76 at
thr_umtx.h:196
frame #2: 0x0000000800831490
libthr.so.3`_thr_rtld_rlock_acquire(lock=0x0000000800a42680) + 64 at
thr_rtld.c:123
frame #3: 0x000000080060bf42
ld-elf.so.1`rlock_acquire(lock=0x000000080081f860,
lockstate=0x00007fffffffe358) + 50 at rtld_lock.c:197
frame #4: 0x0000000800605c5d ld-elf.so.1`_rtld_bind(obj=0x0000000800621000,
reloff=0) + 45 at rtld.c:679
frame #5: 0x00000008006034fd ld-elf.so.1`??? + 45 at rtld_start.S:121
frame #6: 0x0000000000400d9b a.out`zz_sysconf(file=0x0000000000401222,
line=269) + 43 at pr199557.cc:227
frame #7: 0x0000000000400e01 a.out`zz_fork(file=0x0000000000401222,
line=269) + 65 at pr199557.cc:240
frame #8: 0x0000000000400f7b a.out`zz_pthread_create(th=0x00007fffffffe528,
attr=0x0000000000000000, callback=0x0000000000401090, param=0x0000000000000000)
+ 235 at pr199557.cc:269
frame #9: 0x00000000004010dc a.out`main + 44 at pr199557.cc:294
frame #10: 0x000000000040087f a.out`_start(ap=,
cleanup=) + 367 at crt1.c:78
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 20 14:55:41 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 20 Apr 2015 14:55:41 +0000
Subject: [Bug 199557] Hang on sysconf(_SC_OPEN_MAX)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199557
--- Comment #4 from Ed Maste ---
See http://svnweb.freebsd.org/changeset/base/266609 for the fix for this issue
in the fork() case.
In any case calling the fork syscall directly is going to be error-prone, so it
would be useful to have a brief description of how tsan intends to interact
with a target process fork.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 20 21:33:14 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 20 Apr 2015 21:33:13 +0000
Subject: [Bug 198208] FreeBSD 10.1 multiple kernel panics
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198208
--- Comment #12 from Dan ---
It died many times in the ipf_frag_known function. I removed 'keep frags' from
my ipfilter rules and it has not crashed in 7 days, which is a record since
installing FreeBSD 10. I am going to let it run a few more days and then put
the 'keep frags' back to see if it crashes.
How does the aio.ko module fit in?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Mon Apr 20 23:29:52 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 20 Apr 2015 23:29:52 +0000
Subject: [Bug 198723] [hwpmc] pmcstat -p (process counting) gets corrupted
even if pinned to a CPU
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198723
--- Comment #3 from ganbold at gmail.com ---
Ok, my case is probably different, so I see different numbers, but not huge:
cpuset -l 0 pmcstat -w 1 -p CPU_CLK_UNHALTED_CORE -p
PARTIAL_RAT_STALLS.SLOW_LEA_WINDOW -p PARTIAL_RAT_STALLS.MUL_SINGLE_UOP
./himenobmtxpa XL
mimax = 512 mjmax = 512 mkmax = 1024
imax = 511 jmax = 511 kmax =1023
# p/CPU_CLK_UNHALTED_CORE p/PARTIAL_RAT_STALLS.SLOW_LEA_WINDOW
p/PARTIAL_RAT_STALLS.MUL_SINGLE_UOP
870033399 3725668
0
245841351 908762
0
149768752 495087
0
92044851 314835
0
172232985 555547
0
130470473 415529
0
97294500 324799
0
224264591 730483
0
323564237 1001842
0
274181332 793169
0
203753726 565633
0
65682400 185914
0
305112357 883635
0
58018371 175088
0
57542509 165927
0
56139142 164077
0
114569102 328945
0
49034541 139120
0
87673805 246503
0
78197785 216160
0
125396191 347830
0
60803608 169127
0
58624781 158633
0
158752072 431521
0
126637934 347436
0
75105123 200448
0
75871442 165376
0
121684025 326831
0
63415999 164887
0
65051834 165931
0
172723309 437796
0
55178114 134277
0
129564415 321174
0
67139171 161328
0
129583559 302727
0
65823717 159945
0
100021756 239138
0
248424650 604507
0
# p/CPU_CLK_UNHALTED_CORE p/PARTIAL_RAT_STALLS.SLOW_LEA_WINDOW
p/PARTIAL_RAT_STALLS.MUL_SINGLE_UOP
2157395 5581
0
266630444 648471
0
265551569 601376
0
350420437 805538
0
274975297 568795
0
204726842 445208
0
145150448 312924
0
263387441 546046
0
174172408 317262
0
170038378 331495
0
190559076 369572
0
0 0
0
0 0
0
65105706 137757
0
0 0
0
83246288 172311
0
0 0
0
83317266 171992
0
64043046 131977
0
73166853 148560
0
0 0
0
82940705 167883
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
359667865 717901
0
570575714 1085051
0
336720952 634324
0
357310518 663736
0
176594285 311291
0
113486543 211149
0
229862414 416510
0
185818110 320432
0
253051214 440886
0
167883757 285382
0
# p/CPU_CLK_UNHALTED_CORE p/PARTIAL_RAT_STALLS.SLOW_LEA_WINDOW
p/PARTIAL_RAT_STALLS.MUL_SINGLE_UOP
94516905 176444
0
0 0
0
98904136 171988
0
0 0
0
91853341 170419
0
0 0
0
72928488 127483
0
0 0
0
93832604 171930
0
95043153 171647
0
0 0
0
100036516 175539
0
81642449 146707
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
122492641 215274
0
432573271 723654
0
672475908 1137167
0
164955154 275113
0
75885192 127743
0
362878684 597953
0
106611797 165063
0
96271731 159800
0
160547540 238537
0
104997341 166820
0
99251489 158100
0
677889774 1069483
0
109420715 171744
0
92841357 147517
0
17494074 26594
0
0 0
0
109178407 173350
0
0 0
0
89909372 148525
0
14054265 22545
0
# p/CPU_CLK_UNHALTED_CORE p/PARTIAL_RAT_STALLS.SLOW_LEA_WINDOW
p/PARTIAL_RAT_STALLS.MUL_SINGLE_UOP
109666162 151431
0
19816973 29435
0
0 0
0
123641867 186868
0
74710420 117138
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
241415658 318707
0
413566724 628075
0
340955679 519405
0
289339024 438947
0
141001617 218872
0
141498097 213880
0
272845051 424913
0
16543212 23563
0
207416368 316845
0
118682821 166716
0
321315802 474006
0
106027959 159611
0
347174670 484656
0
0 0
0
154530996 170777
0
119466402 174679
0
266077428 326838
0
464666247 629234
0
508973836 728643
0
226376736 289833
0
240968127 325854
0
161590314 181870
0
152003550 172463
0
0 0
0
0 0
0
0 0
0
0 0
0
0 0
0
# p/CPU_CLK_UNHALTED_CORE p/PARTIAL_RAT_STALLS.SLOW_LEA_WINDOW
p/PARTIAL_RAT_STALLS.MUL_SINGLE_UOP
144675563 195757
0
0 0
0
35247263 46692
0
root at bsd:/home/tsgan/himenobmtxpa/src #
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 21 00:00:47 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 21 Apr 2015 00:00:47 +0000
Subject: [Bug 199568] tcpdump -C ignored
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199568
Bug ID: 199568
Summary: tcpdump -C ignored
Product: Base System
Version: 10.1-RELEASE
Hardware: i386
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: bugzilla at termi.dk
tcpdump -C 1 -W 3 -i em0 -w capture.pcap
Should produce 3 files of 1,000,000 bytes but it ignores -C 1 and capture.pcap0
just keeps growing in size
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 21 01:21:08 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 21 Apr 2015 01:21:08 +0000
Subject: [Bug 198723] [hwpmc] pmcstat -p (process counting) gets corrupted
even if pinned to a CPU
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198723
--- Comment #4 from ganbold at gmail.com ---
Some more outputs:
root at bsd:/home/tsgan/himenobmtxpa/src # cpuset -l 1 pmcstat -w 1 -p
CPU_CLK_UNHALTED_CORE -p PARTIAL_RAT_STALLS.SLOW_LEA_WINDOW -p
PARTIAL_RAT_STALLS.MUL_SINGLE_UOP ./himenobmtxpa M
mimax = 128 mjmax = 128 mkmax = 256
imax = 127 jmax = 127 kmax =255
# p/CPU_CLK_UNHALTED_CORE p/PARTIAL_RAT_STALLS.SLOW_LEA_WINDOW
p/PARTIAL_RAT_STALLS.MUL_SINGLE_UOP
496973198 1891482
0
0 0
0
0 0
0
6211441 6475
0
67851413 228420
0
167437929 578476
0
58202990 263315
0
159091555 615841
0
199474522 914360
0
435143068 2102652
0 Start rehearsal measurement process.
Measure the performance in 3 times.
1046313910 3638978
9088916
661072248 1262611
12287166
1181939944 2818232
22741743
571538306 1247954
8365446
1123442862 3240698
18681005
1356224563 3224598
22727923
1147070767 3143202
18853622
1291379900 3264098
22911348
640597242 1432676
10454925
469944137 1173440
8993387
388538712 875062
6810780 MFLOPS: 38.013623 time(s): 10.607217 1.733593e-03
Now, start the actual measurement process.
The loop will be excuted in 16 times
This will take about one minute.
Wait for a while
165134408 621783
851017
239418647 639771
3972871
1002366660 2269801
16204933
1125772300 2705173
20909153
1073364783 2946491
16979374
1199833427 2934209
20613526
1270493498 3131262
22138008
1108155249 3002679
17521465
1314310219 3156869
22821855
1140823030 2842658
20023985
1126332577 2883871
18672363
1162000580 2832338
21202038
1109106518 3066909
16946660
1296149672 3304390
21986759
1179265638 2807189
21081432
1068573361 2922111
16053932
1198262630 2887323
21327538
# p/CPU_CLK_UNHALTED_CORE p/PARTIAL_RAT_STALLS.SLOW_LEA_WINDOW
p/PARTIAL_RAT_STALLS.MUL_SINGLE_UOP
1175241231 2829240
20693991
1096268514 3018859
16739105
1185463271 2963422
21308158
1178471187 2863822
20017627
1148132142 3233218
17586444
1144689029 2976330
20739875
1094868768 2882188
17116037
1269267205 3162007
21789166
1145196524 2810384
19985030
1210390022 3289607
16888847
1201586511 2994667
21764537
1146922422 2767725
19709885
1170310109 3175550
16395202
1289971174 3180738
22527756
1057194734 2602396
19377512
1157004463 3193955
17467630
1235730044 3065464
21453972
1081579818 2756388
17322508
1196944986 3144452
20926928
1095767389 2631318
18833998
1056892461 2789426
16491839
1262274645 3215379
21593331
1193887452 3066186
21195414
1077392053 3120552
17142660
1199816969 2999705
21635489
1064253746 2552890
18452838
1103708407 2965405
16170094
1244782428 2882083
21250280
1199552244 2798772
19013893 Loop executed for 16 times
Gosa : 1.604793e-03
MFLOPS measured : 45.999056 cpu : 46.750959
Score based on Pentium III 600MHz using Fortran 77: 0.560964
558500599 2034859
3314459
root at bsd:/home/tsgan/himenobmtxpa/src #
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 21 01:52:06 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 21 Apr 2015 01:52:06 +0000
Subject: [Bug 198149] [hwpmc] pmcstat -P -t (top mode, process sampling)
stops after a while
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198149
--- Comment #6 from Adrian Chadd ---
ok, try something multi-threaded and doing system calls. I just tried with
nginx and it's okay - it's all one thread per process.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 21 03:05:08 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 21 Apr 2015 03:05:08 +0000
Subject: [Bug 198149] [hwpmc] pmcstat -P -t (top mode, process sampling)
stops after a while
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198149
--- Comment #7 from ganbold at gmail.com ---
I tried to reproduce it with asterisk in same multicore machine and put some
load on asterisk:
last pid: 1296; load averages: 7.44, 5.22, 3.17
up
0+00:28:00 12:01:12
51 processes: 2 running, 49 sleeping
CPU: 31.9% user, 0.0% nice, 21.8% system, 1.8% interrupt, 44.5% idle
Mem: 300M Active, 443M Inact, 252M Wired, 90M Buf, 6933M Free
Swap: 16G Total, 16G Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
1275 root 1059 20 0 1472M 584M select 3 14:30 217.48% asterisk
1280 root 1 24 0 33100K 12692K CPU3 3 0:06 1.27% pmcstat
721 tsgan 1 20 0 86488K 7060K select 7 0:03 0.00% sshd
And I still see pmcstat shows in top mode:
PMC: [CPU_CLK_UNHALTED_CORE] Samples: 24904 (100.0%) , 2906 unresolved
%SAMP IMAGE FUNCTION CALLERS
7.0 kernel _mtx_lock_spin_cooki pmclog_reserve:6.4 sched_add:0.6
3.4 kernel __mtx_lock_sleep umtxq_sleep:1.3
__umtx_op_wake2_umutex:1.2 do_lock_umutex:0.6
3.3 libgsm.so. 0xad72 Gsm_Short_Term_Synthesis_Filt
2.4 kernel cpu_search_lowest cpu_search_lowest
2.3 libgsm.so. 0xad37 Gsm_Short_Term_Synthesis_Filt
1.8 libgsm.so. 0xad19 Gsm_Short_Term_Synthesis_Filt
1.6 libgsm.so. 0xad30 Gsm_Short_Term_Synthesis_Filt
1.6 libgsm.so. 0xad69 Gsm_Short_Term_Synthesis_Filt
1.6 libgsm.so. 0xace7 Gsm_Short_Term_Synthesis_Filt
1.4 libgsm.so. Gsm_Decoder gsm_decode
1.3 libgsm.so. 0xad53 Gsm_Short_Term_Synthesis_Filt
1.3 libgsm.so. Gsm_Long_Term_Synthe Gsm_Decoder
1.2 hwpmc.ko pmc_hook_handler sched_switch
1.1 libgsm.so. 0xad4b Gsm_Short_Term_Synthesis_Filt
1.1 codec_ulaw lintoulaw_framein
1.0 libgsm.so. Gsm_Short_Term_Synth Gsm_Decoder
1.0 kernel Xrendezvous
1.0 libgsm.so. 0xad33 Gsm_Short_Term_Synthesis_Filt
1.0 libgsm.so. 0xad3f Gsm_Short_Term_Synthesis_Filt
1.0 libgsm.so. 0xace0 Gsm_Short_Term_Synthesis_Filt
1.0 libgsm.so. 0xacb0 Gsm_Short_Term_Synthesis_Filt
0.9 libgsm.so. 0xacca Gsm_Short_Term_Synthesis_Filt
0.9 kernel do_lock_umutex __umtx_op_wait_umutex
0.9 libgsm.so. 0xacef Gsm_Short_Term_Synthesis_Filt
0.9 libgsm.so. 0xad11 Gsm_Short_Term_Synthesis_Filt
0.8 libgsm.so. 0xad00 Gsm_Short_Term_Synthesis_Filt
0.8 kernel amd64_syscall
0.8 kernel in_pcbconnect_setup udp_send
0.8 libgsm.so. 0xacfa Gsm_Short_Term_Synthesis_Filt
0.8 libgsm.so. 0xad06 Gsm_Short_Term_Synthesis_Filt
0.7 libgsm.so. Gsm_RPE_Decoding Gsm_Decoder
0.7 kernel thread_lock_flags_
0.7 libc.so.7 memcpy
0.6 kernel __umtx_op_wake2_umut amd64_syscall
0.6 kernel __rw_rlock
0.6 libgsm.so. 0xad43 Gsm_Short_Term_Synthesis_Filt
...
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 21 06:32:35 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 21 Apr 2015 06:32:35 +0000
Subject: [Bug 198463] [mfi] COMMAND 0x... TIMEOUT AFTER ## SECONDS (LSI
MegaRAID 9361-8i)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198463
--- Comment #8 from Sibananda Sahu ---
(In reply to sirdice from comment #7)
mrsas(4) is not supporting the mfiutil(8) yet.
You can use the LSI application for the same purpose i.e StorCli, which is
available on www.lsi.com
Below is the download location:
http://www.lsi.com/downloads/Public/RAID%20Controllers/RAID%20Controllers%20Common%20Files/1.15.05_StorCLI.zip
Hope this helps.
- Sibananda Sahu
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 21 09:11:41 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 21 Apr 2015 09:11:41 +0000
Subject: [Bug 199574] trim load ssd on 100%
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199574
Bug ID: 199574
Summary: trim load ssd on 100%
Product: Base System
Version: 10.1-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: gs3men at gmail.com
FreeBSD 10.1-RELEASE-p8 amd64
Hello.
I found a strange behavior with ssd drives trim perfomance.
I have zfs mirror on 2 ssd drives (ashift=12, aligment 4k).
When i migrate sql server to that storage i found that ssd become always busy
and having io queue lenth ~60, some count of read and write, and 128 bio_delele
(trim) operations in gstat statiscs.
After much tests and googling i found sysctl varianle
vfs.zfs.vdev.trim_max_active with default value 64 that limit number of active
trim operations.
Problem appears when zfs continiously fill queue of drive by trim operation(2
times in second).
If i change vfs.zfs.vdev.trim_max_active to 1000, zfs send 2000 trim operations
to drive per second and drive iops and busy level become to normal state.
When i set vfs.zfs.vdev.trim_max_active to low number 8 device have 16
bio_delele per second and device busy level become 100%.
I try to work with another partition on same drive(i thinking that it is zfs
bug) and found that such operation is also suffer so i concluded that zfs have
no guilt.
I try to determinate how freebsd calculate busy levels and find that it come
fom geom (geom_stats_open geom_stats_snapshot_next geom_stats_snapshot_get...)
So when device make 16 trim per second - it 100% busy, latency big, iops slow.
When device make 2000 and more trims per second - device free, queue empty,
latency great.
So what is it? Bug or feature?
I also check device trim performance by UFS: my ssd drive can perform about
7000 trim operations per second with block size 64k(and more with less block
size). So probably zfs trim (by 128k) will perform 3000 trims, but i can't
generate so much trim activity to find exact value.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 21 09:33:09 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 21 Apr 2015 09:33:08 +0000
Subject: [Bug 198208] FreeBSD 10.1 multiple kernel panics
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198208
--- Comment #13 from g_amanakis at yahoo.com ---
I have observed a similar behaviour when running ctld, samba4, nfs along with
an ezjail running apache24, php5 and mariadb55-server. The filesystem is ZFS.
When I run a script which 1)stops all these services and the ezjail, 2)makes
ZFS snapshots and 3) restarts the services along with the ezjail, it throws a
kernel panic and reboots. Culprit seems to be __mtx_lock_sleep, but I cannot
find out the service calling it.
When the aio module is loaded the kernel never panics.
Hardware is an X9SCM/E3-1220Lv2, 8GB ECC-RAM and an IBM ServerRAID M1015.
Vanilla GENERIC kernel.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 21 09:53:04 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 21 Apr 2015 09:53:04 +0000
Subject: [Bug 199495] relates to Bug 195349 - CAM status: command timeout
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199495
stenio changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |stenio at csi-italia.eu
--- Comment #1 from stenio ---
Hi,
I think I have the same problem: for some reason my hardware (Fabiatech FX5621)
doesn't work with FreeBSD 10.1 while it works perfectly with version 8.3. I
tried to boot from a USB drive, disabling from BIOS all IDE drives and using
all hints commands I found with no luck! This is what I tried:
set hint.atapci.1.msi=0
set hint.atapci.0.msi=0
set hint.ata.1.mode="PIO4"
set hint.ata.0.mode="PIO4"
set hint.acpi.0.disabled=1
set kern.cam.ada.write_cache=0
boot
The boot loops with this error:
(aprobe0:ata1:0:1:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00
(aprobe0:ata1:0:1:0): CAM status: Command timeout
(aprobe0:ata1:0:1:0): Retrying command
run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config
(aprobe0:ata1:0:1:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00
(aprobe0:ata1:0:1:0): CAM status: Command timeout
(aprobe0:ata1:0:1:0): Error 5, Retries exhausted
(aprobe0:ata1:0:1:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00
(aprobe0:ata1:0:1:0): CAM status: Command timeout
(aprobe0:ata1:0:1:0): Retrying command
run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config
(aprobe0:ata1:0:1:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00
(aprobe0:ata1:0:1:0): CAM status: Command timeout
(aprobe0:ata1:0:1:0): Error 5, Retries exhausted
Please let me know if you have any suggestion.
Thanks,
Stenio
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Tue Apr 21 17:52:23 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 21 Apr 2015 17:52:23 +0000
Subject: [Bug 199587] libc strncmp() performance
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199587
Bug ID: 199587
Summary: libc strncmp() performance
Product: Base System
Version: 10.1-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: misc
Assignee: freebsd-bugs at FreeBSD.org
Reporter: blackngel1 at gmail.com
I've been tinkering with the code, out of curiosity, and I've reimplemented
strncmp() to check the performance. Here are my results and the benchmark code:
42359800221 cycles -- FreeBSD strncmp()
42113090043 cycles -- FreeBSD strncmp()
42145558182 cycles -- FreeBSD strncmp()
39479522958 cycles -- My Implementation
39447595998 cycles -- My Implementation
39445708599 cycles -- My Implementation
My implementation always runs a bit faster and seems more clean.
--------------
#include
unsigned long long
rdtsc(void)
{
unsigned int low, hi;
__asm__ volatile(
"rdtsc\n"
: "=a"(low), "=d"(hi)
:
: "memory");
return ((unsigned long long)hi << 32) | (unsigned long long) low;
}
int
strncmpnew(const char *p, const char *q, size_t n)
{
while (n > 0 && *p && (*p == *q))
n--, p++, q++;
return (n == 0) ? 0: ((const unsigned char)*p - (const unsigned
char)*q);
}
int
strncmpfbsd(const char *s1, const char *s2, size_t n)
{
if (n == 0)
return (0);
do {
if (*s1 != *s2++)
return (*(const unsigned char *)s1 -
*(const unsigned char *)(s2 - 1));
if (*s1++ == '\0')
break;
} while (--n != 0);
return (0);
}
void
test(int (*f)(const char *, const char *, unsigned int n), unsigned int iters,
char *msg)
{
char *str1 = "abcdefghijklmnopqrstuvwxyz0123456789A";
char *str2 = "abcdefghijklmnopqrstuvwxyz0123456789A";
unsigned long foo = 0;
unsigned long long int st = rdtsc();
unsigned int i;
for (i = 0; i < iters; i++)
foo += f(str1, str2, 37);
unsigned long long int tot = rdtsc() - st;
printf("%20llu cycles -- %s\n", tot, msg);
asm volatile( "" :: "g"(foo) : "memory");
}
int
main(void)
{
unsigned int iters = 100000000;
test(strncmpfbsd, iters, "FreeBSD strncmp()");
test(strncmpfbsd, iters, "FreeBSD strncmp()");
test(strncmpfbsd, iters, "FreeBSD strncmp()");
test(strncmpnew, iters, "My Implementation");
test(strncmpnew, iters, "My Implementation");
test(strncmpnew, iters, "My Implementation");
getchar();
return 0;
}
--------------
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 22 00:40:04 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 22 Apr 2015 00:40:04 +0000
Subject: [Bug 199596] 'service restart' command still runs 'start' when
'stop' failed
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199596
Bug ID: 199596
Summary: 'service restart' command still runs 'start' when
'stop' failed
Product: Base System
Version: 10.0-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: misc
Assignee: freebsd-bugs at FreeBSD.org
Reporter: yuri at rawbw.com
> service restart
Should be equivalent to
> service stop && service start
And it just runs them sequentially.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 22 09:27:37 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 22 Apr 2015 09:27:36 +0000
Subject: [Bug 199605] BTX halted
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199605
Bug ID: 199605
Summary: BTX halted
Product: Base System
Version: 10.1-STABLE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: Karli.Sjoberg at slu.se
I was just upgrading one of our storage's- an old Sun Fire X4140- to
10.1-STABLE as per Bug 191348[*] when something strange happened after writing
new boot code and rebooting:
BTX loader 1.00 BTX version is 1.02
Consoles: internal video/keyboard
BIOS drive C: is disk8
BIOS drive D: is disk9
int=00000000 err=00000000 efl=00010246 eip=00037d34
eax=00000001 ebx=00000000 ecx=00000000 edx=00000000
esi=00000000 edi=00000000 ebp=0008f600 esp=0008f598
cs=002b ds=0033 es=0033 fs=0033 gs=0033 ss=0033
cs:eip=f7 35 d0 f4 03 00 85 f6-74 05 89 3e 89 5e 04 89
c2 e9 cc 00 00 00 66 c7-45 ea 00 00 89 d8 c1 e8
ss:esp=00 00 20 00 00 00 00 00-00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
BTX halted
Never happened to me before. I then booted with a 10.1-RELEASE CD and wrote
bootcode from that, same problem. 9.3; same there...
Thanks in advance!
Karli Sj?berg
[*]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191348
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Wed Apr 22 16:13:52 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 22 Apr 2015 16:13:51 +0000
Subject: [Bug 102834] [patch] mail(1) hangs on the sigsuspend system call in
popen.c
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=102834
Eitan Adler changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|FIXED |---
Status|Closed |Open
Assignee|eadler at FreeBSD.org |freebsd-bugs at FreeBSD.org
--- Comment #13 from Eitan Adler ---
re-open.
--
You are receiving this mail because:
You are the assignee for the bug.
From interjulyyy at aliyun.com Thu Apr 23 05:06:43 2015
From: interjulyyy at aliyun.com (John)
Date: Thu, 23 Apr 2015 06:54:38 +0200
Subject: business leads
Message-ID: <6efbbbab9d463d28a06dd078bfb7865b@cakegroup.com>
Hey,
You are receiving this email because we wish you to use our email marketing
service.
We wish to be your email marketing partner, we can grow your business 2-5
times than now.
If you would require more information please send us an email and we would
be glad to discuss the project requirements with you soon.
Looking forward to your positive response.
Kind Regards
John
Email: pottleyo at aliyun.com
-------------------------------------------------
This e-mail message and its attachments (if any) are intended solely for
the use of the addressee(s) hereof. In addition, this message and the
attachments (if any) may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If you are not
the intended recipient of this message, you are prohibited from reading,
disclosing, reproducing, distributing, disseminating or otherwise using
this transmission. Delivery of this message to any person other than the
intended recipient is not intended to waive any right or privilege. If you
have received this message in error, please promptly notify the sender and
immediately delete this message from your system.
If you don't wish our future news letter, pls send address to
ttickmay at aliyun.com for removal.
From bugzilla-noreply at freebsd.org Thu Apr 23 08:29:55 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 23 Apr 2015 08:29:55 +0000
Subject: [Bug 199557] Hang on sysconf(_SC_OPEN_MAX)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199557
--- Comment #5 from ikosarev at accesssoftek.com ---
(In reply to Ed Maste from comment #2)
> Pointed out by kib, when invoking the fork syscall directly the child
> inherits potentially locked libc mutexes, and it's probably the printf
> that hangs, not the sysconf.
Note that the code doesn't leverage libc's printf(), but rather uses its own
version of it.
> What was the original underlying issue here?
The original problem is random Tsan tests hanging on high loaded machines like
the FreeBSD sanitizers buildbot:
http://lab.llvm.org:8011/builders/sanitizer_x86_64-freebsd/builds/4978/steps/make-check-tsan/logs/stdio
It mostly work fine when the tests run in about 4 threads, but tends to fail
constantly when run in about 64 threads--doesn't matter how much cores the
hardware has.
This is how it leads to the point of hang: during execution of a Tsan tests the
Tsan STL catches a data race or other condition triggering a run-time report.
That report contains references to related object files and associated
addresses. These file names together with the addresses are then translated
into source file name, line numbers and function names by calling the
llvm-symbolizer or, if the RTL is unable to locate it, the addr2line command.
To catch the output of the symbolizing tool the RTL fork() the process and
redirects the streams. This is where the whole thing hangs. Note is that if I
comment the sysconf(_SC_OPEN_MAX) call, then it hangs on one of the other
subsequent system calls, like read() so it appears to not to be a
sysconf()-specific issue.
Another note is that the RTL sources refer to a specific reason about why it
tries to use the syscall fork() in place of the libc's intercepted one:
// Real fork() may call user callbacks registered with pthread_atfork().
pid = internal_fork();
The internal_fork() function is just the syscall:
int internal_fork() {
#if SANITIZER_USES_CANONICAL_LINUX_SYSCALLS
return internal_syscall(SYSCALL(clone), SIGCHLD, 0);
#else
return internal_syscall(SYSCALL(fork));
#endif
}
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 23 11:12:42 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 23 Apr 2015 11:12:41 +0000
Subject: [Bug 199641] Growfs does not compile in debugmode (GFSDBG)
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199641
Bug ID: 199641
Summary: Growfs does not compile in debugmode (GFSDBG)
Product: Base System
Version: 10.1-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: wjw at digiware.nl
cd /usr/src/sbin/growfs
make -DGFSDBG
Returns errors while building.
Probably because the debug code is normally execluded.
2* int versus u_int_32
2* char-pointer cast to uint-pointer
First is fixed by changing type
Second is fixed by getting the compiler to ignore the warning.
Which IMHO is valid since compiling GFSDBG is only done if you sort of know
what is going on.....
Perhaps a suggestion on debugging on the manual page would be approriate as
well.
Tested on 10.1, but probably valid on others as well.
svn diff:
Index: sbin/growfs/Makefile
===================================================================
--- sbin/growfs/Makefile (revision 281869)
+++ sbin/growfs/Makefile (working copy)
@@ -17,6 +17,8 @@
.if defined(GFSDBG)
SRCS+= debug.c
+CFLAGS+=-DFS_DEBUG
+NO_WCAST_ALIGN= yes
.endif
DPADD= ${LIBUTIL}
Index: sbin/growfs/growfs.c
===================================================================
--- sbin/growfs/growfs.c (revision 281869)
+++ sbin/growfs/growfs.c (working copy)
@@ -161,7 +161,7 @@
#ifdef FS_DEBUG
{
struct csum *dbg_csp;
- int dbg_csc;
+ u_int32_t dbg_csc;
char dbg_line[80];
dbg_csp = fscs;
@@ -242,7 +242,7 @@
#ifdef FS_DEBUG
{
struct csum *dbg_csp;
- int dbg_csc;
+ u_int32_t dbg_csc;
char dbg_line[80];
dbg_csp = fscs;
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 23 12:06:52 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 23 Apr 2015 12:06:52 +0000
Subject: [Bug 199557] Hang on sysconf(_SC_OPEN_MAX)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199557
--- Comment #6 from Konstantin Belousov ---
(In reply to ikosarev from comment #5)
It is actually rtld' locks which are inherited blocked and thus symbol
resolution is non-functional. As a quick test, try your test with
LD_BIND_NOW=1 env var set.
Direct calls to the fork syscall from the threading process is not supposed to
work.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 23 16:12:10 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 23 Apr 2015 16:12:10 +0000
Subject: [Bug 196392] [cam] tape pwr-off then pwr-on: cam_periph_alloc:
attempt to re-allocate valid device
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196392
G. Paul Ziemba changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|New |Closed
Resolution|--- |FIXED
--- Comment #1 from G. Paul Ziemba ---
As of 10-Stable r280974, this problem seems to be fixed (probably due to the
sa(4) changes committed in the meantime).
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 23 17:07:12 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 23 Apr 2015 17:07:12 +0000
Subject: [Bug 199648] vt(4) mouse cursor becomes "stripey" in the rightmost
character column
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199648
Bug ID: 199648
Summary: vt(4) mouse cursor becomes "stripey" in the rightmost
character column
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: emaste at freebsd.org
Created attachment 155919
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155919&action=edit
Crop from QEMU screenshot of stripey mouse
See attached crop r281777, QEMU screengrab. Also reproduced on a Thinkpad X220
with i950kms and a little older kernel.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 23 20:16:07 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 23 Apr 2015 20:16:07 +0000
Subject: [Bug 199648] vt(4) mouse cursor becomes "stripey" in the rightmost
character column
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199648
Ed Maste changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |emaste at freebsd.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 23 21:30:31 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 23 Apr 2015 21:30:31 +0000
Subject: [Bug 194746] /etc/freebsd-update.conf shouldn't include src as an
Component on the Components line
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194746
Kamil Czekirda changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kczekirda at freebsd.org
--- Comment #1 from Kamil Czekirda ---
Created attachment 155928
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155928&action=edit
patch for bsdinstall
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 23 21:32:45 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 23 Apr 2015 21:32:44 +0000
Subject: [Bug 199557] Hang on sysconf(_SC_OPEN_MAX)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199557
Jilles Tjoelker changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jilles at FreeBSD.org
--- Comment #7 from Jilles Tjoelker ---
There is a proposal for an async-signal safe version of fork() called _Fork(),
which does not call atfork handlers, at
http://austingroupbugs.net/view.php?id=62 . This would help if the only problem
with calling fork() is that it executes atfork handlers. It still executes a
fair bit of code, but no user code.
To make _Fork() async-signal safe, the malloc handling would have to be
disabled as well, making malloc/free in the child more unsafe (but also
interfering less with other threads in the parent). The handling of the lock
for sem_open() and sem_close() uses pthread_atfork() and would be disabled as
well.
This may be useful for this and other situations that want to fork from signal
handlers or other strange thread states.
I have not found common implementations of _Fork(), though.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 23 22:37:24 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 23 Apr 2015 22:37:24 +0000
Subject: [Bug 194746] /etc/freebsd-update.conf shouldn't include src as an
Component on the Components line
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194746
--- Comment #2 from Kamil Czekirda ---
Comment on attachment 155928
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155928
patch for bsdinstall
>--- config.old 2015-02-08 11:00:26.000000000 +0100
>+++ config 2015-04-23 23:26:34.236700377 +0200
>@@ -40,6 +40,14 @@
>
> cp $BSDINSTALL_TMPBOOT/* $BSDINSTALL_CHROOT/boot
>
>+src=
>+for dist in $DISTRIBUTIONS; do
>+ [ "$dist" = "src.txz" ] && src=1
>+done
>+
>+[ ! "$src" ] && sed -i.bu 's/^Components src/Components/g' $BSDINSTALL_CHROOT/etc/freebsd-update.conf
>+
>+
> [ "${debugFile#+}" ] && cp "${debugFile#+}" $BSDINSTALL_CHROOT/var/log/
>
> # Set up other things from installed config
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 23 22:42:42 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 23 Apr 2015 22:42:42 +0000
Subject: [Bug 194746] /etc/freebsd-update.conf shouldn't include src as an
Component on the Components line
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194746
Kamil Czekirda changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #155928|0 |1
is obsolete| |
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 23 22:43:52 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 23 Apr 2015 22:43:52 +0000
Subject: [Bug 194746] /etc/freebsd-update.conf shouldn't include src as an
Component on the Components line
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194746
--- Comment #3 from Kamil Czekirda ---
Created attachment 155929
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155929&action=edit
patch for bsdinstall
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 23 22:45:30 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 23 Apr 2015 22:45:29 +0000
Subject: [Bug 194746] /etc/freebsd-update.conf shouldn't include src as an
Component on the Components line
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194746
Kamil Czekirda changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #155929|0 |1
is obsolete| |
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Thu Apr 23 22:46:45 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 23 Apr 2015 22:46:45 +0000
Subject: [Bug 194746] /etc/freebsd-update.conf shouldn't include src as an
Component on the Components line
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194746
--- Comment #4 from Kamil Czekirda ---
Created attachment 155930
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155930&action=edit
patch for bsdinstall config
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 00:45:09 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 00:45:08 +0000
Subject: [Bug 199654] [patch] Add additional hooks to MAC framework following
vnode lookup and create operations
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199654
Bug ID: 199654
Summary: [patch] Add additional hooks to MAC framework
following vnode lookup and create operations
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Keywords: patch
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: sdmoore at fas.harvard.edu
Keywords: patch
Created attachment 155932
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155932&action=edit
Patch adding hooks to the MAC framework and vnode operations
Add hooks in the MAC subsystem following vnode lookup and create operations
that allow MAC policies to update state in response to file system accesses and
modifications.
These hooks are used in the Shill research project
(http://shill.seas.harvard.edu) to implement a capability-based sandbox, but
could be used by any MAC policy that requires fine-grained tracking of
filesystem access patterns.
To evaluate the performance impact of this patch, I have run two benchmarks
that test the overhead on lookup and create operations. The first benchmark
"open-read-close" measures the time required to open the file "/tmp/file" (two
lookup operations), read 1 byte, and close the file. The second benchmark
"create-unlink" measures the time required to create a the file "/tmp/file" and
then unlink it. I ran each benchmark in a tight loop lasting for 10 seconds and
took 50 measurements. The measurements were taken on a ThinkPad x201 in single
user mode, pinned to a single core. The performance impact appears to be
negligible, within a few microseconds. A summary of the benchmarks is below
(time in microseconds).
Unpatched Patched
Benchmark Mean SD Mean SD
open-read-close 11.11 0.02 11.18 0.03
create-unlink 41.50 0.09 40.57 0.17
--
You are receiving this mail because:
You are the assignee for the bug.
From interjulyyy at aliyun.com Fri Apr 24 05:49:22 2015
From: interjulyyy at aliyun.com (John)
Date: Thu, 23 Apr 2015 18:23:41 +0200
Subject: leads for your business
Message-ID:
Hey,
We can help you to generate business from our email marketing.
I can help you accomplish that if you're not already.
I specialize in the following:
Email Marketing
Leads Generating.
Just reply back and I can go over options for you.
Thanks,
John
Email: pottleyo at aliyun.com
-------------------------------------------------
This e-mail message and its attachments (if any) are intended solely for
the use of the addressee(s) hereof. In addition, this message and the
attachments (if any) may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If you are not
the intended recipient of this message, you are prohibited from reading,
disclosing, reproducing, distributing, disseminating or otherwise using
this transmission. Delivery of this message to any person other than the
intended recipient is not intended to waive any right or privilege. If you
have received this message in error, please promptly notify the sender and
immediately delete this message from your system.
If you don't wish our future news letter, pls send address to
ttickmay at aliyun.com for removal.
From bugzilla-noreply at freebsd.org Fri Apr 24 08:41:08 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 08:41:08 +0000
Subject: [Bug 199574] trim load ssd on 100%
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199574
Robert Schulze changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rs at bytecamp.net
--- Comment #1 from Robert Schulze ---
This is a duplicate of
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197516.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 08:42:45 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 08:42:45 +0000
Subject: [Bug 199574] trim load ssd on 100%
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199574
--- Comment #2 from Robert Schulze ---
Ouch, sorry for my last comment. Its not a duplicate since this is on ZFS.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 09:15:15 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 09:15:15 +0000
Subject: [Bug 199574] trim load ssd on 100%
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199574
--- Comment #3 from Semen ---
And i havn't gmirror.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 11:04:02 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 11:04:02 +0000
Subject: [Bug 196694] libmd doesn't detect EOF properly; can get stuck in an
infinite loop in MDXFileChunk
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196694
--- Comment #2 from commit-hook at freebsd.org ---
A commit references this bug:
Author: ngie
Date: Fri Apr 24 11:03:48 UTC 2015
New revision: 281928
URL: https://svnweb.freebsd.org/changeset/base/281928
Log:
Avoid an infinite loop by ensuring that the amount of bytes read is greater
than 0 in MDXFileChunk when calculating the checksum
This edgecase can be triggered if the file is truncated while the checksum
is being calculated (i.e. the EOF is reached)
Differential Revision: https://reviews.freebsd.org/D2351 (patch by darius)
PR: 196694
Reviewed by: delphij, ngie
Submitted by: Daniel O'Connor
Sponsored by: EMC / Isilon Storage Division
Changes:
head/lib/libmd/mdXhl.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 11:04:55 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 11:04:54 +0000
Subject: [Bug 196694] libmd doesn't detect EOF properly; can get stuck in an
infinite loop in MDXFileChunk
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196694
Garrett Cooper,425-314-3911 changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |ngie at FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 11:51:40 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 11:51:40 +0000
Subject: [Bug 199641] Growfs does not compile in debugmode (GFSDBG)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199641
Edward Tomasz Napierala changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |trasz at FreeBSD.org
Assignee|freebsd-bugs at FreeBSD.org |trasz at FreeBSD.org
Status|New |Open
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 15:06:05 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 15:06:05 +0000
Subject: [Bug 188039] [i915] [panic] hw.vga.textmode=1 causes crash when
starting Xorg or loading i915kms module
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188039
Ed Maste changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|In Progress |Closed
Resolution|--- |Unable to Reproduce
--- Comment #2 from Ed Maste ---
Panic is still not reproducible at r281909 on my X220, hw.vga.textmode=1 with
i915kms.
Please reopen if you encounter this again.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 15:59:33 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 15:59:33 +0000
Subject: [Bug 196918] [PATCH] Add R_X86_64_PC64 to sys/sys/elf_common.h
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196918
--- Comment #12 from commit-hook at freebsd.org ---
A commit references this bug:
Author: emaste
Date: Fri Apr 24 15:58:42 UTC 2015
New revision: 281937
URL: https://svnweb.freebsd.org/changeset/base/281937
Log:
MFC r277464: Add missing R_X86_64_ constants to elf_common.h
PR: 196918
Sponsored by: The FreeBSD Foundation
Changes:
_U stable/10/
stable/10/sys/sys/elf_common.h
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 16:12:36 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 16:12:35 +0000
Subject: [Bug 196918] [PATCH] Add R_X86_64_PC64 to sys/sys/elf_common.h
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196918
--- Comment #13 from commit-hook at freebsd.org ---
A commit references this bug:
Author: emaste
Date: Fri Apr 24 16:12:31 UTC 2015
New revision: 281939
URL: https://svnweb.freebsd.org/changeset/base/281939
Log:
MFC r277464: Add missing R_X86_64_ constants to elf_common.h
PR: 196918
Sponsored by: The FreeBSD Foundation
Changes:
_U stable/9/sys/
_U stable/9/sys/sys/
stable/9/sys/sys/elf_common.h
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 16:14:01 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 16:14:01 +0000
Subject: [Bug 196918] [PATCH] Add R_X86_64_PC64 to sys/sys/elf_common.h
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196918
Ed Maste changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|New |Closed
Resolution|--- |FIXED
--- Comment #14 from Ed Maste ---
Merged to HEAD, stable/10 and stable/9.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 16:28:14 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 16:28:14 +0000
Subject: [Bug 197534] Repeatable segfault in unbound when re-reading config
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197534
--- Comment #3 from Poul-Henning Kamp ---
-current r281910 and unbound still dies when interfaces go up or down.
This makes -current pretty useless for pretty much anything but a laptop where
you can manually restart it whenever the network burps.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 16:38:33 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 16:38:33 +0000
Subject: [Bug 197534] Repeatable segfault in unbound when re-reading config
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197534
Baptiste Daroussin changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|freebsd-bugs at FreeBSD.org |des at FreeBSD.org
--- Comment #4 from Baptiste Daroussin ---
Assigned to des@ as he is the maintainer of unbound in base
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 17:03:27 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 17:03:27 +0000
Subject: [Bug 199669] freebsd-update break sshd
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199669
Bug ID: 199669
Summary: freebsd-update break sshd
Product: Base System
Version: 9.3-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: slw at zxy.spb.ru
On 9.2-RC3 do:
====
freebsd-update fetch
freebsd-update install
reboot
====
After this do:
====
freebsd-update upgrade -r 9.3
freebsd-update install
reboot
freebsd-update install
====
Got next error messages:
=====
Installing updates...ln: ///usr/lib/private/libssh.so: No such file or
directory
install: ///usr/lib/private/libssh.so.5: No such file or directory
ln: ///usr/lib/private/libucl.so: No such file or directory
install: ///usr/lib/private/libucl.so.1: No such file or directory
install: ///usr/src/contrib/bind9/libtool.m4 exists but is not a directory
install: ///usr/src/contrib/bind9/libtool.m4/libtool.m4: Not a directory
install: ///usr/src/contrib/bind9/libtool.m4/ltoptions.m4: Not a directory
install: ///usr/src/contrib/bind9/libtool.m4/ltsugar.m4: Not a directory
install: ///usr/src/contrib/bind9/libtool.m4/ltversion.m4: Not a directory
Completing this upgrade requires removing old shared object files.
Please rebuild all installed 3rd party software (e.g., programs
installed from the ports tree) and then run "/usr/sbin/freebsd-update install"
again to finish installing updates.
=====
After this sshd don't start:
=====
# /etc/rc.d/sshd start
Generating ED25519 host key.
key_generate: unknown type 9
/etc/ssh/ssh_host_ed25519_key.pub: No such file or directory
Performing sanity check on sshd configuration.
/usr/sbin/sshd: Undefined symbol "ssh_explicit_bzero"
/etc/rc.d/sshd: WARNING: failed precmd routine for sshd
=====
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 17:04:34 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 17:04:34 +0000
Subject: [Bug 194746] /etc/freebsd-update.conf shouldn't include src as an
Component on the Components line
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194746
Nathan Whitehorn changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|New |Open
CC| |nwhitehorn at FreeBSD.org
--- Comment #5 from Nathan Whitehorn ---
Thanks for this! It seems like a good idea, but I'm very hesitant to patch
files in the base system from the installer: it adds magic to something that is
supposed to only be tar. Do you know how hard it would be to patch
freebsd-update to be smarter instead?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 17:16:29 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 17:16:29 +0000
Subject: [Bug 199669] freebsd-update break sshd
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199669
--- Comment #1 from slw at zxy.spb.ru ---
`freebsd-update IDS` on this system don't find any relevan problems:
===
Looking up update.FreeBSD.org mirrors... none found.
Fetching metadata signature for 9.3-RELEASE from update.FreeBSD.org... done.
Fetching metadata index... done.
Inspecting system... done.
/etc/dhclient.conf has SHA256 hash
adf0f297109e16e742204def7397d7de7e7ad538485228b67d6325b28c18ae23, but should
have SHA256 hash
be06fcdc4b61f88c779c323e9fb7ab5aba9e972ebca033ecee0e81e51aec6b7f.
/etc/group has SHA256 hash
afc67a5abdfa1335e4e8a3ca0e53b05b45621f9eeca960303e1c149ec38710f5, but should
have SHA256 hash
f1a06b63561e4d644b82599a8f520f905c4024c16d4969c55c2b6af2189024e4.
/etc/hosts has SHA256 hash
c87d8ba343bc0203420056f939d02510984c732fd143a135f7f3e92386621ea2, but should
have SHA256 hash
c10aced14c4e17d1b84d76b4925605163a1cea8b8e90bdf6fbf5c001899203df.
/etc/hosts.lpd has SHA256 hash
30911e88673a0cab89e3a97e9b9266f2ad28fdb42971c1a4a77f1b56179ed9e8, but should
have SHA256 hash
0fc4c626b4354dc08418e10635ed6b375de1439a56183fa0855256456e5dba23.
/etc/inetd.conf has SHA256 hash
00818bc5366efe48768b80e04b016ec8e7283b24e9ba517e24eb0eee0b4bd9a6, but should
have SHA256 hash
503293a0270f9aa4efcb8a7285e233ad77715c7ad563426098872c1b23fc4e88.
/etc/login.conf has SHA256 hash
eb84a507c1fe740bdc7f316c0a5102fb8b8b01e617e9283dfd56ce72db5ff166, but should
have SHA256 hash
5fed38d2cfd32494b0aef1e2db8a26e9c0c1656ca5219ca313a8914a78e45b2b.
/etc/login.conf.db has SHA256 hash
a2cb5022aa91638a26c8cef0b03f8edd3e24e2ebab6d60a27f310ce81624f3dc, but should
have SHA256 hash
959cff1a36836894d2c7b7615d61f76bc5160065485924a72344e355bc52601c.
/etc/mail/aliases has SHA256 hash
af8c6d708a9f5da13b0a9f59e157a8e95b5230782c0f82bc6615448ee5ee1616, but should
have SHA256 hash
dd5f3be7f5dfe3cf8d937081763c9af85961aff9bf803edd698b5071f54495c1.
/etc/mail/sendmail.cf has 0444 permissions, but should have 0644 permissions.
/etc/mail/sendmail.cf has SHA256 hash
317659aa42390a51fc573d84dc84243f9088c84101ad8a42471ed1c51188d151, but should
have SHA256 hash
3034fff9293e5f50bc6ca1ef501bb837f381c2853433a120fd77639ce4f9a7dc.
/etc/mail/submit.cf has SHA256 hash
ffb14b0aadf3ed7bc955db1b6d474e4907d71a3841f759ed02a77ef10b1a4f9a, but should
have SHA256 hash
491ac81b60b0acbde396937817c131ed4c8d33e3307c317456d8a6ffbbc1dd55.
/etc/master.passwd has SHA256 hash
4cc1ad59a2ea539524e59b2eaab53d3c5f00742d5a5a0c09192a287393b35898, but should
have SHA256 hash
c6a2620559374a74d83897d333e1c02bbb2a02bae803c5f49986b98a016c15d6.
/etc/motd has SHA256 hash
e69f3e4fe140970a3166d957b94a2ef86a7ac729ea7c83d1635b593bf1c16fb4, but should
have SHA256 hash
98f082efc89da5e887e72bc4dcfa3e5fc8bada9d19db4bdbba9a32692a7c82a7.
/etc/namedb is a symlink to /var/named/etc/namedb, but should be a symlink to
../var/named/etc/namedb.
/etc/passwd has SHA256 hash
e2e86c6b8dd52ecaef2270b4a1f1fbd049f7e8b977f95185ae5f84861ee877ba, but should
have SHA256 hash
07a01ba0a6cc1953aedb2fa419a81e4467b7635aa2654c26833a172b96ad576b.
/etc/printcap has SHA256 hash
a1e0a2772a87454fcae9e7b766697d436e85697877a22f82d247ce9799216685, but should
have SHA256 hash
a88a827426da69334673b5e27d450b90ab79a946d019d0912fe189e7c34c2206.
/etc/pwd.db has SHA256 hash
9049af692aaf1743967ec6e1a357b327b29507c292d0956dde80691adc23416f, but should
have SHA256 hash
1b481658b7b6aa8126fef82f745a37e3b6e896d247364eb797e2cb434f370354.
/etc/spwd.db has SHA256 hash
81ba1ee50b1d30df755245cffb1f9ac0208c28b8cac7442becf2b53292e58f3a, but should
have SHA256 hash
5f4a19eafc5edd3a903a32c835cb3f71181f3e89c9bf2fbbf7ecc14fae69cf5b.
/etc/syslog.conf has SHA256 hash
36a04bf8ca0c3a5cbf20bd0d75493624d9d6527469f524cc648bdc42d0d0621b, but should
have SHA256 hash
4c7abd5b4e02ab29d5509738dcca80a11b9f7d3b782849696199d24446ccc53d.
/usr/src/contrib/bind9/libtool.m4 is a regular file, but should be a directory.
/var/named/etc/namedb/named.conf has SHA256 hash
c2723a39f159d8dbb8c95d61145c11fdc32aad0254f79c655f3c9bbc0567aacc, but should
have SHA256 hash
c9ef6bd870a873b778bb7e705830df405eae4b4f30594d33099335e9e3ac2117.
====
# freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 5 mirrors found.
Fetching metadata signature for 9.3-RELEASE from update6.freebsd.org... done.
Fetching metadata index... done.
Fetching 2 metadata patches.. done.
Applying metadata patches... done.
Fetching 2 metadata files... done.
Inspecting system... done.
Preparing to download files... done.
No updates needed to update system to 9.3-RELEASE-p13.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 17:42:57 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 17:42:57 +0000
Subject: [Bug 199670] memory leak in netpfil
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199670
Bug ID: 199670
Summary: memory leak in netpfil
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: pfg at FreeBSD.org
Created attachment 155950
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155950&action=edit
Fix
Found by clang static analyzer:
http://scan.freebsd.org/scan-build/WORLD/2015-04-20-amd64/report-ee9ce2.html#EndPath
And also Coverity (CID 1245771).
I cannot really check this so hopefully someone else can review.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 17:46:43 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 17:46:43 +0000
Subject: [Bug 199671] memory leak in cam scsi
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199671
Bug ID: 199671
Summary: memory leak in cam scsi
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: pfg at FreeBSD.org
Created attachment 155951
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155951&action=edit
Fix
Found by clang static analyzer:
http://scan.freebsd.org/scan-build/WORLD/2015-04-20-amd64/report-851c0f.html#EndPath
And also Coverity (CID 1007770)
I am not using this so hopefully someone else can review/test.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 17:49:04 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 17:49:04 +0000
Subject: [Bug 199670] [patch] memory leak in netpfil
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199670
Pedro F. Giffuni changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|memory leak in netpfil |[patch] memory leak in
| |netpfil
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 17:49:44 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 17:49:44 +0000
Subject: [Bug 199671] [patch] memory leak in cam scsi
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199671
Pedro F. Giffuni changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|memory leak in cam scsi |[patch] memory leak in cam
| |scsi
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 17:53:24 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 17:53:24 +0000
Subject: [Bug 199671] [patch] memory leak in cam scsi
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199671
--- Comment #1 from Pedro F. Giffuni ---
(In reply to Pedro F. Giffuni from comment #0)
Wrong link, see:
http://scan.freebsd.org/scan-build/WORLD/2015-04-20-amd64/report-16a93b.html#EndPath
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 18:04:57 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 18:04:57 +0000
Subject: [Bug 194746] /etc/freebsd-update.conf shouldn't include src as an
Component on the Components line
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194746
--- Comment #6 from Kamil Czekirda ---
Created attachment 155952
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155952&action=edit
patch for freebsd-update
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 18:06:16 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 18:06:16 +0000
Subject: [Bug 187114] rtld(1) does not expand $ORIGIN unless DF_ORIGIN flag
is set
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187114
--- Comment #1 from Ed Maste ---
When the dynamic linker loads an object that uses $ORIGIN, it must calculate
the pathname of the directory containing the object. Because this calculation
can be computationally expensive, implementations may want to avoid the
calculation for objects that do not use $ORIGIN. If an object calls dlopen()
with a string containing $ORIGIN and does not use $ORIGIN in one if its dynamic
array entries, the dynamic linker may not have calculated the pathname for the
object until the dlopen() actually occurs. Since the application may have
changed its current working directory before the dlopen() call, the calculation
may not yield the correct result. To avoid this possibility, an object may
signal its intention to reference $ORIGIN by setting the DF_ORIGIN flag. An
implementation may reject an attempt to use $ORIGIN within a dlopen() call from
an object that did not set the DF_ORIGIN flag and did not use $ORIGIN within
its dynamic array.
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 18:11:19 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 18:11:19 +0000
Subject: [Bug 187114] rtld(1) does not expand $ORIGIN unless DF_ORIGIN flag
is set
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187114
--- Comment #2 from Ed Maste ---
(In reply to Ed Maste from comment #1)
(text above from
http://www.sco.com/developers/gabi/2003-12-17/ch5.dynamic.html#substitution)
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 18:36:37 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 18:36:37 +0000
Subject: [Bug 194746] /etc/freebsd-update.conf shouldn't include src as an
Component on the Components line
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194746
--- Comment #7 from Nathan Whitehorn ---
That looks great to me, thanks. Anyone else have opinions?
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 18:46:51 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 18:46:51 +0000
Subject: [Bug 194746] /etc/freebsd-update.conf shouldn't include src as an
Component on the Components line
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194746
--- Comment #8 from Kamil Czekirda ---
Revision created:
https://reviews.freebsd.org/D2364
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 19:05:10 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 19:05:10 +0000
Subject: [Bug 199673] sysctl(8) suffers a multiplication overflow when
formatting vm.vmtotal
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199673
Bug ID: 199673
Summary: sysctl(8) suffers a multiplication overflow when
formatting vm.vmtotal
Product: Base System
Version: 10.0-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: vmagerya at gmail.com
Created attachment 155955
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155955&action=edit
sysctl-overflow.diff
Here's a part of 'sysctl vm.mvtotal' output on my 10.0/amd64
machine:
% sysctl vm.vmtotal
[...]
Virtual Memory: (Total: 1654588K Active: 1536668K)
[...]
If on the other hand, when I try to retrieve the same data via
sysctl(3), I get different total virtual memory:
% cat >test.c <<'EOF'
#include
#include
#include
#include
#include
int main() {
struct vmtotal vt = {0};
size_t vtlen = sizeof(vt);
if (sysctlbyname("vm.vmtotal", &vt, &vtlen, NULL, 0) != 0)
return -1;
ssize_t pagesize = getpagesize()/1024;
printf("vm.vmtotal.t_vm = %zd pages (%zd kB)\n",
(ssize_t)vt.t_vm,
pagesize*vt.t_vm);
return 0;
}
'EOF'
% c99 test.c && ./a.out
vm.vmtotal.t_vm = 1074154446 pages (4296617784 kB)
As you can see, the actual data coming out of sysctl(3) is
4296617784K, not 1654588K as sysctl(8) says. This is because
sysctl(8) has a multiplication overflow in the 'S_vmtotal'
function [1] when the number of pages ('t_vm') is multiplied by
the page size ('pageKilo').
I'm attaching a (completely untested) patch to fix this problem;
apply this patch to 'sbin/sysctl/sysctl.c'.
[1]
http://svnweb.freebsd.org/base/head/sbin/sysctl/sysctl.c?revision=278654&view=markup#l530
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 19:22:07 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 19:22:07 +0000
Subject: [Bug 196512] vt(4): Keyboard not working properly when not using
kbdmux(4)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196512
Ed Maste changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|New |Open
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 19:26:52 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 19:26:52 +0000
Subject: [Bug 196512] vt(4): Keyboard not working properly when not using
kbdmux(4)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196512
--- Comment #1 from commit-hook at freebsd.org ---
A commit references this bug:
Author: emaste
Date: Fri Apr 24 19:26:01 UTC 2015
New revision: 281947
URL: https://svnweb.freebsd.org/changeset/base/281947
Log:
MFC r273973: vt(4): Fix keyboard allocation when kbdmux(4) isn't used
The problem was that only the kbdmux keyboard index was saved in
vd->vd_keyboard. This index is -1 when kbdmux isn't used. In this
case, the keyboard was correctly allocated, but the returned index was
discarded.
PR: 196512
Changes:
_U stable/9/sys/
_U stable/9/sys/dev/
stable/9/sys/dev/vt/vt_core.c
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 19:27:53 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 19:27:53 +0000
Subject: [Bug 196512] vt(4): Keyboard not working properly when not using
kbdmux(4)
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196512
Ed Maste changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Open |Closed
Resolution|--- |FIXED
--
You are receiving this mail because:
You are the assignee for the bug.
From bugzilla-noreply at freebsd.org Fri Apr 24 20:18:00 2015
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 24 Apr 2015 20:18:00 +0000
Subject: [Bug 199670] [patch] memory leak in netpfil
In-Reply-To:
References:
Message-ID:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199670
Andrey V. Elsukov changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ae at FreeBSD.org
--- Comment #1 from Andrey V. Elsukov