Re: kern/185395: IPv4 Multicast broken in 10.x
Synopsis: IPv4 Multicast broken in 10.x State-Changed-From-To: open->patched State-Changed-By: glebius State-Changed-When: Thu Jan 2 10:18:56 UTC 2014 State-Changed-Why: Fixed in head. Responsible-Changed-From-To: freebsd-bugs->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Thu Jan 2 10:18:56 UTC 2014 Responsible-Changed-Why: Fixed in head. http://www.freebsd.org/cgi/query-pr.cgi?pr=185395 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: ports/185406: update www/py-django-simple-captcha from 0.4.0 to 0.4.1
Old Synopsis: update py-django-simple-captcha from 0.4.0 to 0.4.1 New Synopsis: update www/py-django-simple-captcha from 0.4.0 to 0.4.1 Responsible-Changed-From-To: freebsd-bugs->freebsd-ports-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jan 2 11:20:22 UTC 2014 Responsible-Changed-Why: make this a ports PR and fix Synopsis. http://www.freebsd.org/cgi/query-pr.cgi?pr=185406 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/185092: panic: rtfree 2 (using RADIX_MPATH in a VNET jail)
Synopsis: panic: rtfree 2 (using RADIX_MPATH in a VNET jail) Responsible-Changed-From-To: freebsd-bugs->melifaro Responsible-Changed-By: melifaro Responsible-Changed-When: Thu Jan 2 13:34:35 UTC 2014 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=185092 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/185092: panic: rtfree 2 (using RADIX_MPATH in a VNET jail)
On Wed, Jan 1, 2014 at 5:39 PM, Nikolay Denev wrote:
> Ok, killing openvpn with -9 leaves the routes around, and particularly
> interesting are the following routes :
>
> 78.90.222.xx 10.255.255.0 UGHS0 5841 epair0 =>
> 78.90.222.xx/3210.255.255.0 UGS 00 epair0
>
> Now, if I do :
>
> route delete 78.90.222.xx 10.255.255.0
>
> The route, with the H flag is deleted. If I repeat the command the
> second route is deleted as well, even if the second command specifies
> a netmask no panic.
>
> However the first delete command specifies the /32 mask like this :
>
> route delete 78.90.222.xx 10.255.255.0 255.255.255.255
>
> Then I get "rtfree 2" kernel panic immediately.
>
> This seems to be happening as I'm manually installing static routes in
> the vnet jail for the VPN remote endpoints , however OpenVPN adds such
> routes too however differently, which results in two routing entries.
>
> For example :
>
> route add $IP $GW
> and
> route add $IP $GW 255.255.255.255
>
> add to different route entries, one is /32 network, the other is a host route.
>
>
>
> --Nikolay
>
> On Wed, Jan 1, 2014 at 1:21 PM, Nikolay Denev wrote:
>> On Wed, Jan 1, 2014 at 1:10 PM, Nikolay Denev wrote:
>>>
>>> On Sun, Dec 22, 2013 at 1:10 PM, wrote:
Thank you very much for your problem report.
It has the internal identification `misc/185092'.
The individual assigned to look at your
report is: freebsd-bugs.
You can access the state of your problem report at any time
via this link:
http://www.freebsd.org/cgi/query-pr.cgi?pr=185092
>Category: misc
>Responsible:freebsd-bugs
>Synopsis: panic: rtfree 2 (using RADIX_MPATH in a VNET jail)
>Arrival-Date: Sun Dec 22 13:10:00 UTC 2013
>>>
>>>
>>> I'm trying to understand exactly what is happening here, and examining a
>>> core dump with kgdb I'm getting some output that confuses me :
>>>
>>> (kgdb) bt
>>> #0 doadump (textdump=-1011569920) at pcpu.h:233
>>> #1 0xc06069b2 in kern_reboot (howto=260) at
>>> /usr/src/sys/kern/kern_shutdown.c:447
>>> #2 0xc0606d0e in panic (fmt=) at
>>> /usr/src/sys/kern/kern_shutdown.c:754
>>> #3 0xc06de639 in rtfree (rt=) at
>>> /usr/src/sys/net/route.c:464
>>> #4 0xc06e188d in route_output (m=) at
>>> /usr/src/sys/net/rtsock.c:951
>>> #5 0xc06de18f in raw_usend (so=, flags=0, m=>> optimized out>, nam=0x0, control=,
>>> td=0xc3bd2000) at /usr/src/sys/net/raw_usrreq.c:238
>>> #6 0xc066eca9 in sosend_generic (so=0xc3e9c1a8, uio=>> out>, top=, control=0x0,
>>> flags=, td=) at
>>> /usr/src/sys/kern/uipc_socket.c:1271
>>> #7 0xc066efc7 in sosend (so=0xc3e9c1a8, addr=0x0, uio=0xd9b9cc10,
>>> top=0x0, control=0x0, flags=0, td=0xc3bd2000)
>>> at /usr/src/sys/kern/uipc_socket.c:1315
>>> #8 0xc0654af4 in soo_write (fp=0xc3c0c818, uio=0xd9b9cc10,
>>> active_cred=0xc3f1dd00, flags=0, td=0xc3bd2000)
>>> at /usr/src/sys/kern/sys_socket.c:103
>>> #9 0xc064c866 in dofilewrite (td=0xc3bd2000, fd=3, fp=0xc3c0c818,
>>> auio=0xd9b9cc10, offset=-1, flags=0) at file.h:303
>>> #10 0xc064c566 in kern_writev (td=0xc3bd2000, fd=3, auio=>> out>) at /usr/src/sys/kern/sys_generic.c:467
>>> #11 0xc064c4bc in sys_write (td=, uap=>> optimized out>) at /usr/src/sys/kern/sys_generic.c:382
>>> #12 0xc08614d3 in syscall (frame=) at
>>> subr_syscall.c:134
>>> #13 0xc084cca1 in Xint0x80_syscall () at
>>> /usr/src/sys/i386/i386/exception.s:270
>>> #14 0x281975b7 in ?? ()
>>> Previous frame inner to this frame (corrupt stack?)
>>> Current language: auto; currently minimal
>>> (kgdb) fr 3
>>> #3 0xc06de639 in rtfree (rt=) at
>>> /usr/src/sys/net/route.c:464
>>> 464 panic("rtfree 2");
>>> (kgdb) print *rt
>>> $1 = {rt_nodes = {{rn_mklist = 0xc3b4ab30, rn_parent = 0x1, rn_bit = 0,
>>> rn_bmask = 0 '\0', rn_flags = 0 '\0', rn_u = {rn_leaf = {
>>> rn_Key = 0xc0882687 "shutdown_post_sync", rn_Mask = 0x103
>>> , rn_Dupedkey = 0x0}, rn_node = {
>>> rn_Off = -1064819065, rn_L = 0x103, rn_R = 0x0}}},
>>> {rn_mklist = 0x0, rn_parent = 0x4, rn_bit = -18048, rn_bmask = -94 '?',
>>> rn_flags = 195 '?', rn_u = {rn_leaf = {rn_Key = 0xc3a545e0 "",
>>> rn_Mask = 0xc3a4e440 " ??(???\020'", rn_Dupedkey = 0xc3a4e880},
>>> rn_node = {rn_Off = -1012578848, rn_L = 0xc3a4e440, rn_R =
>>> 0xc3a4e880, rt_gateway = 0x74756873, rt_flags = 1853321060,
>>> rt_refcnt = 1936683103, rt_ifp = 0x79735f74, rt_ifa = 0x636e, rt_rmx =
>>> {rmx_mtu = 0, rmx_expire = 0, rmx_pksent = 0, rmx_weight = 0},
>>> rt_fibnum = 0, rt_mtx = {lock_object = {lo_name = 0x0, lo_flags = 0,
>>> lo_data = 0, lo_witness = 0x0}, mtx_lock = 0}}
>>>
>>>
>>>
>>> rn_Key with value of “shutdown_post_sync” ?
>>>
>>> It’s visible also in the raw_usend() frame:
>>>
>>> (kgdb) fr 5
>>> #5 0xc06de18f in raw_usend (so=, flags=0, m=>> optimized out>, nam=0x0, control=,
>>> td=0xc3bd2000) at /usr/src/sys/net/raw_usrreq.c:238
>>> 238 return (
kern/185425: iwn difficulties in busy radio environments
>Number: 185425 >Category: kern >Synopsis: iwn difficulties in busy radio environments >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jan 02 21:00:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Nathan Whitehorn >Release:11-CURRENT >Organization: >Environment: FreeBSD wanderer.tachypleus.net 11.0-CURRENT FreeBSD 11.0-CURRENT #41 r260039M: Sun Dec 29 13:22:33 EST 2013 r...@wanderer.tachypleus.net:/usr/obj/usr/src/sys/WANDERER amd64 >Description: In busy radio environments (i.e. not at home), using wpa_supplicant reliably causes NIC crashes involving printing errors about "NMI_FIRMWARE_WATCHDOG" to the console. Resetting the interface (an up/down cycle) restores its operation for a time. This problem seems specific to wpa_supplicant. If I am connected to an open network and wpa_supplicant is running, the NIC will crash. If I turn wpa_supplicant off and just connect with ifconfig ssid foo, it will not crash. I suspect it is a scanning-related race. The card in question is: iwn0@pci0:3:0:0:class=0x028000 card=0x11108086 chip=0x42308086 rev=0x61 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/Wireless 4965 AG or AGN [Kedron] Network Connection' >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/185393: find(1): -lname buffer read overflow bug
Old Synopsis: find -lname buffer read overflow bug New Synopsis: find(1): -lname buffer read overflow bug Responsible-Changed-From-To: freebsd-bugs->jilles Responsible-Changed-By: jilles Responsible-Changed-When: Thu Jan 2 21:41:09 UTC 2014 Responsible-Changed-Why: I'm working on this. http://www.freebsd.org/cgi/query-pr.cgi?pr=185393 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/185054: Cannot mount_udf dvd Invalid argument
The following reply was made to PR misc/185054; it has been noted by GNATS. From: Takashi Matsubara To: freebsd-gnats-sub...@freebsd.org Cc: Subject: Re: misc/185054: Cannot mount_udf dvd Invalid argument Date: Thu, 2 Jan 2014 23:29:37 GMT >Submitter-Id: current-users >Originator: Takashi Matsubara >Organization: >Confidential: no >Synopsis: Re: misc/185054: Cannot mount_udf dvd Invalid argument >Severity: non-critical >Priority: low >Category: misc >Class:sw-bug >Release: 10-RC4 >Environment: FreeBSD tamago-two.tamago.local 10.0-PRERELEASE FreeBSD >10.0-PRERELEASE #0 r260180: Thu Jan 2 13:22:02 JST 2014 >matubara@tamago-two.tamago.local:/usr/obj/usr/src/sys/TAMAGO-TWO amd64 >Description: Information is added. [camcontrol devlist] at scbus0 target 0 lun 0 (ada0,pass0) at scbus1 target 0 lun 0 (cd0,pass1) at scbus4 target 0 lun 0 (ses0,pass2) [file -s /dev/cd0] /dev/cd0: # UDF filesystem data (version 1.5) 'SAMPLE ' mount_-t udf:NG mount -t cd9660:OK Why can't it mount by mount_udf? >How-To-Repeat: >Fix: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/185429: rc.subr: ${name}_chroot does not work when there's a custom rc "start_cmd"
>Number: 185429
>Category: misc
>Synopsis: rc.subr: ${name}_chroot does not work when there's a custom rc
>"start_cmd"
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Jan 02 23:30:01 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: Dreamcat4
>Release:9.1-RELEASE-p5 and higher
>Organization:
-
>Environment:
This bug occurs for any / all recent FreeBSD versions since 9.1-RELEASE-p5
>Description:
There is a bug in /etc/rc.subr
the bug is:
if [ there's a custom ${XXX_cmd}, ]
E.g. an rc "start_cmd", "stop_cmd".
then
"${name}_chroot" does not work.
Documentation:
man -Pcat rc.subr | grep -5 -i chroot
${name}_chroot
Directory to chroot(8) to before running command.
Only supported after /usr is mounted.
It happens at these begin/end points:
https://gitorious.org/freebsd/freebsd/source/1e0e806b8822c4570e09508df054f82f9a47ce0e:etc/rc.subr#L684-739
If you look in rc.subr at those lines ^^ control is obviously never getting to
the part where it kicks of the chroot case... which only happens in case start).
There may be more bugs nearby, and for the same reason.
Will fix / wont fix ?
Many thanks.
>How-To-Repeat:
for any rc.d service that sets "start_cmd" at the top of its rc.d script
1) set "${name}_chroot=/path/to/chroot" in rc.conf
2) set "name_enable=YES" in rc.conf
3) start that rc.d service
>Fix:
need to edit the file "/etc/rc.subr" around these lines:
https://gitorious.org/freebsd/freebsd/source/1e0e806b8822c4570e09508df054f82f9a47ce0e:etc/rc.subr#L684-739
So that ${name}_chroot is checked for, even at the top where it says:
"# if there's a custom ${XXX_cmd},"
...
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
bin/185431: gcc bug with short int promotion
>Number: 185431
>Category: bin
>Synopsis: gcc bug with short int promotion
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Jan 03 01:50:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: Stephen Hurd
>Release:9.1-RELEASE-p6
>Organization:
>Environment:
FreeBSD cracked.hurd.local 9.1-RELEASE-p6 FreeBSD 9.1-RELEASE-p6 #0: Wed Aug 21
20:30:17 UTC 2013
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386
>Description:
Integer promotion of a short int and an unsigned short in the same expression
seems broken in the system compiler.
>How-To-Repeat:
#include
int main(int argc, char **argv)
{
short k = 251;
unsigned short l = 65535;
printf("%hd > %hu = %d\n", k, l, (k > l));
return 0;
}
> gcc test.c
> ./a.out
251 > 65535 = 1
>Fix:
Use a different compiler.
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/185427: [igb] freebsd 8.4, 9.1 and 9.2 panic Double-Fault with intel 82576 igb driver
Old Synopsis: freebsd 8.4, 9.1 and 9.2 panic Double-Fault with intel 82576 igb driver New Synopsis: [igb] freebsd 8.4, 9.1 and 9.2 panic Double-Fault with intel 82576 igb driver Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jan 3 02:06:34 UTC 2014 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=185427 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
