kern/164369: [patch] two STP bridges have the same id
>Number: 164369
>Category: kern
>Synopsis: [patch] two STP bridges have the same id
>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: Sun Jan 22 11:30:11 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Nikos Vassiliadis
>Release:10.0-CURRENT
>Organization:
>Environment:
FreeBSD lab.local 10.0-CURRENT FreeBSD 10.0-CURRENT #110 r230309M: Wed Jan 18
21:07:24 EET 2012 root@lab.local:/usr/obj/usr/src/sys/LAB i386
>Description:
The current code in STP selects the id of a bridge from all available ethernet
ifnets regardless if they are part of the said bridge. This is problematic when
more than one STP bridges exist, that is, more than one bridges will have the
same bridge id.
>How-To-Repeat:
ifconfig bridge0 create
ifconfig bridge1 create
ifconfig bridge0 addm em0 addm em1 stp em0 stp em1
ifconfig bridge1 addm em2 addm em3 stp em2 stp em3
The resulting bridges are:
bridge0: flags=8802 metric 0 mtu 1500
ether 02:46:61:bb:95:00
nd6 options=29
id 08:00:27:0f:88:a5 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 08:00:27:0f:88:a5 priority 32768 ifcost 0 port 0
member: em1 flags=1c7
ifmaxaddr 0 port 3 priority 128 path cost 2 proto rstp
role designated state discarding
member: em0 flags=1c7
ifmaxaddr 0 port 1 priority 128 path cost 2 proto rstp
role designated state discarding
bridge1: flags=8802 metric 0 mtu 1500
ether 02:46:61:bb:95:01
nd6 options=29
id 08:00:27:0f:88:a5 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 08:00:27:0f:88:a5 priority 32768 ifcost 0 port 0
member: em3 flags=1c7
ifmaxaddr 0 port 5 priority 128 path cost 2 proto rstp
role designated state discarding
member: em2 flags=1c7
ifmaxaddr 0 port 4 priority 128 path cost 2 proto rstp
role designated state discarding
Both have the same id
>Fix:
The MAC address candidates for the bridge id should be only from the bridge's
members
Patch attached with submission follows:
Index: sys/net/bridgestp.c
===
--- sys/net/bridgestp.c (revision 230309)
+++ sys/net/bridgestp.c (working copy)
@@ -2017,20 +2017,27 @@
BSTP_LOCK_ASSERT(bs);
mif = NULL;
+ bp = LIST_FIRST(&bs->bs_bplist);
/*
* Search through the Ethernet adapters and find the one with the
-* lowest value. The adapter which we take the MAC address from does
-* not need to be part of the bridge, it just needs to be a unique
-* value.
+* lowest value. Make sure the adapter which we take the MAC address
+* from is part of this bridge, so we can have more than one independent
+* bridges in the same STP domain.
*/
IFNET_RLOCK_NOSLEEP();
TAILQ_FOREACH(ifp, &V_ifnet, if_link) {
if (ifp->if_type != IFT_ETHER)
continue;
+ if (ifp->if_bridge == NULL || bp == NULL)
+ continue;
+
if (bstp_addr_cmp(IF_LLADDR(ifp), llzero) == 0)
continue;
+ if (ifp->if_bridge != bp->bp_ifp->if_bridge)
+ continue;
+
if (mif == NULL) {
mif = ifp;
continue;
>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"
misc/164370: zfs destroy for snapshot fails on i386
>Number: 164370 >Category: misc >Synopsis: zfs destroy for snapshot fails on i386 >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Jan 22 11:30:12 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Dmitry Afanasiev >Release:FreeBSD 9.0-STABLE i386 >Organization: >Environment: FreeBSD kot 9.0-STABLE FreeBSD 9.0-STABLE #55: Fri Jan 6 16:07:09 MSK 2012 root@kot:/usr/obj/usr/src/sys/kot i386 >Description: zfs destroy without -R options fails for any snapshot on _i386_ systems. I have no this problem on my amd64 and sparc64 systems with same source code level. >How-To-Repeat: # zpool create tank `mdconfig -a -t swap -s 64m` # zfs snapshot tank@snap # zfs destroy -v tank@snap will destroy tank@snap will reclaim 0 # echo $? 1 # zfs destroy -rv tank@snap will destroy tank@snap will reclaim 0 # echo $? 1 # zfs destroy -Rv tank@snap will destroy tank@snap will reclaim 0 # echo $? 0 >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: misc/164370: zfs destroy for snapshot fails on i386
The following reply was made to PR misc/164370; it has been noted by GNATS. From: Dmitry Afanasiev To: bug-follo...@freebsd.org Cc: Subject: Re: misc/164370: zfs destroy for snapshot fails on i386 Date: Sun, 22 Jan 2012 17:30:20 +0400 Oops. I'm confused. Problem exists on sparc64 too. Only amd64 systems not affected by this issue. ___ 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/164361: make handles "+=" incorrectly when the variable has zero length
-- Forwarded message -- From: Jilles Tjoelker Date: Sun, Jan 22, 2012 at 8:24 AM Subject: Re: bin/164361 quick question about make To: Eitan Adler On Sun, Jan 22, 2012 at 12:48:49AM -0500, Eitan Adler wrote: > Is the behavior reported in bin/164361 actually a bug? > http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html > appears to have comment on += > The patch provided seems to fix the issue for me, but is it correct? I cannot find mention of += in the POSIX specification for make, but there is a proposal to add it at http://austingroupbugs.net/view.php?id=330 . This proposal appears to describe exactly what we do: if the variable already exists, a space is inserted between the old and the new value, even if the old value is null. The same happens in gmake and bmake (with the example). Because an extraneous space is unlikely to cause problems (sh treats two unquoted spaces the same as a single unquoted space), it seems unwise to change this. -- Eitan Adler Source & Ports committer X11, Bugbusting teams ___ 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/164375: Update our FreeBSD Listing
>Number: 164375 >Category: misc >Synopsis: Update our FreeBSD Listing >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Sun Jan 22 17:40:04 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Patrick Stump >Release:9.0 >Organization: Rokabear >Environment: >Description: Hello we havae moved from vmware to kvm based virtualization for FreeBSD. Can you update our listing to reflect: --- Rokabear.com offers KVM VPS and Dedicated servers that run FreeBSD 9.0. Rokabear has focused their services towards knowledgeable users who know what they want, and know how to run their systems their way. With a KVM VPS you are allowed to install FreeBSD as you want it. Right from the beginning your in control. Secure VNC based console allows you to have full access! Rokabear.com knows how to take your experience to the next level. Rokabear values its reputation for uptime, reliability and performance as much as you do. Check out a http://www.rokabear.com/kvmvps.html";>KVM VPS and see why people are flocking to KVM over XEN and VMWare. >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: www/164375: Update our FreeBSD Listing
Synopsis: Update our FreeBSD Listing Responsible-Changed-From-To: freebsd-bugs->freebsd-www Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 22 18:33:31 UTC 2012 Responsible-Changed-Why: Affects the website. http://www.freebsd.org/cgi/query-pr.cgi?pr=164375 ___ 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/164370: [zfs] zfs destroy for snapshot fails on i386 and sparc64
Old Synopsis: zfs destroy for snapshot fails on i386 New Synopsis: [zfs] zfs destroy for snapshot fails on i386 and sparc64 Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 22 18:34:49 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=164370 ___ 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/164369: [bridge] [patch] two STP bridges have the same id
Old Synopsis: [patch] two STP bridges have the same id New Synopsis: [bridge] [patch] two STP bridges have the same id Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 22 18:35:36 UTC 2012 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=164369 ___ 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/164378: [patch] improvement of pkg_info warning
>Number: 164378
>Category: misc
>Synopsis: [patch] improvement of pkg_info warning
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Sun Jan 22 19:00:19 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Yuri
>Release:9.0
>Organization:
n/a
>Environment:
>Description:
This patch adds package name to the pkg_info warning "corrupted record (pkgdep
line without argument)"
>How-To-Repeat:
>Fix:
Patch attached with submission follows:
--- usr.sbin/pkg_install/lib/plist.c.orig 2012-01-22 10:34:23.0
-0800
+++ usr.sbin/pkg_install/lib/plist.c2012-01-22 10:50:32.0 -0800
@@ -286,7 +286,8 @@
if (*cp == '\0') {
cp = NULL;
if (cmd == PLIST_PKGDEP) {
- warnx("corrupted record (pkgdep line without argument),
ignoring");
+ warnx("corrupted record for package %s (pkgdep line without
argument), ignoring",
+ pkg->name);
cmd = FAIL;
}
goto bottom;
>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"
misc/164382: [ath] crash when down/deleting a vap - inside ieee80211_input_mimo_all()
>Number: 164382 >Category: misc >Synopsis: [ath] crash when down/deleting a vap - inside >ieee80211_input_mimo_all() >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Jan 22 19:50:10 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:9.0-RC2, with -HEAD ath/net80211 >Organization: FreeBSD >Environment: FreeBSD marilyn 9.0-RC3-p1 FreeBSD 9.0-RC3-p1 #4: Sat Jan 21 20:56:40 PST 2012 root@marilyn:/usr/src/sys/i386/compile/MARILYN i386 >Description: I saw a crash inside the net80211 stack when either deleting or down'ing a vap. Unread portion of the kernel message buffer: KDB: stack backtrace: #0 0xc0727697 at kdb_backtrace+0x47 #1 0xc073b675 at _witness_debugger+0x25 #2 0xc073cb8e at witness_warn+0x1fe #3 0xc095e465 at trap+0x195 #4 0xc09478ac at calltrap+0x6 #5 0xc77e2bf1 at ieee80211_free_node_debug+0xb1 #6 0xc77ce017 at ieee80211_input_mimo_all+0xe7 #7 0xc77cdf22 at ieee80211_input_all+0x32 #8 0xc784dcc5 at ath_rx_proc+0xc45 #9 0xc784d071 at ath_rx_tasklet+0x101 #10 0xc073446b at taskqueue_run_locked+0xeb #11 0xc0734ec7 at taskqueue_thread_loop+0x67 #12 0xc06c76b8 at fork_exit+0xb8 #13 0xc0947924 at fork_trampoline+0x8 The debugging indicated something rather amusing at this point. ath0: ath_node_alloc: an 0xc7adf000 ieee80211_ref_node: 0xc7adf000: ieee80211_reset_bss /usr/home/adrian/work/freebsd/ath/head/src/sys/modules/wl an/../../net80211/ieee80211_node.c:434 wlan0: Ethernet address: 00:03:7f:11:a3:f3 ath0: ath_init: if_flags 0x8803 ath0: ath_stop_locked: invalid 0 if_flags 0x8803 ath0: ath_newstate: INIT -> INIT ath0: ath_newstate: RX filter 0x6497 bssid 00:00:00:00:00:00 aid 0x0 ath0: ath_newstate: INIT -> SCAN ath0: ath_newstate: RX filter 0x6497 bssid 00:00:00:00:00:00 aid 0x0 ath0: ath_node_alloc: an 0xc7aea000 . now at this point, there are two sets of messages which overlap, indicating that they ran concurrently: ieee80211_ref_node: 0xc7aea000: ieee80211_create_ibss /usr/home/adrian/work/freebsd/ath/head/src/sys/modules/ wlan/../../net802 ieee80211_ref_node: 0xc7adf000: ieee80211_input_mimo_all /usr/home/adrian/work/freebsd/ath/head/src/sys/modul es/wlan/../../net 11/ieee80211_node.c:412 80211/ieee80211_input.c:143 ath0: ath_node_free: ni 0xc7adf000 . and bang: Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex ath0_node_lock (ath0_node_lock) r = 0 (0xc79316c0) locked @ /usr/home/adrian/work/freeb sd/ath/head/src/sys/modules/wlan/../../net80211/ieee80211_node.c:1702 I'm gathering here that the delete was ongoing whilst traffic was being processed via ath_rx_tasklet() and the underlying vap was either deleted or the vap->iv_bss node was changed. There seems to be a larger class of bugs where the vap->iv_bss node is changed in parallel with some other process (eg beacon free/alloc) without suitable locking. >How-To-Repeat: It's difficult to reproduce. I reproduced it in a lab environment with lots of busy air. I guess anything that triggers constant incoming traffic and keeps the RX queue deep is going to make triggering this bug. What needs to happen: * ath_rx_tasklet() needs to take a while to run; * the ifconfig process (and net80211 taskqueue) needs to be scheduled on another CPU, so it can run _in parallel_ with the ath taskqueue (which ath_rx_tasklet() runs in) * somehow you have to get a vap down/delete in during this RX. >Fix: I think the RX path should be properly aborted during a a vap down/delete. This doesn't just mean stopping the hardware (which is what ath_stop_locked() currently does) but also waiting for the ath_rx_tasklet() and the TX completion tasklet to complete. >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"
misc/164383: new freebsd installer is pure CRAP!
>Number: 164383 >Category: misc >Synopsis: new freebsd installer is pure CRAP! >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sun Jan 22 19:50:10 UTC 2012 >Closed-Date: >Last-Modified: >Originator: James M. Pothering >Release:9.0 >Organization: aero-lab >Environment: FreeBSD wx.aero-lab.com 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 UTC 2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >Description: new freebsd bsd installer is confusing, lacks control, etc. it is inferior to old installer. i.e., it is pure CRAP! >How-To-Repeat: install freebsd 9.0 >Fix: convince freebsd team to go back to old installer >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/163567: make(1): add option to disable object directory
Old Synopsis: make(1) forgets to chdir back to the original directory after finding an object dir New Synopsis: make(1): add option to disable object directory Responsible-Changed-From-To: jilles->freebsd-bugs Responsible-Changed-By: jilles Responsible-Changed-When: Sun Jan 22 20:55:08 UTC 2012 Responsible-Changed-Why: There may be some use in adding an option to disable object directories, but I am not interested in doing it. http://www.freebsd.org/cgi/query-pr.cgi?pr=163567 ___ 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/164081: sockstat not reporting all open sockets
The following reply was made to PR bin/164081; it has been noted by GNATS.
From: Jilles Tjoelker
To: Jim Pirzyk , d...@freebsd.org
Cc: bug-follo...@freebsd.org
Subject: Re: bin/164081: sockstat not reporting all open sockets
Date: Sun, 22 Jan 2012 23:01:30 +0100
On Tue, Jan 17, 2012 at 08:13:59AM -0500, Jim Pirzyk wrote:
> On Jan 13, 2012, at 7:03 PM, Jilles Tjoelker wrote:
> >> [netstat reports sockets that sockstat does not]
> > The sockstat utility checks all file descriptors open by all processes
> > looking for sockets, while netstat shows all kernel-level sockets. This
> > may mismatch in many ways: a process may have closed its descriptor but
> > TCP still needs to maintain some state like TIME_WAIT (as mentioned in
> > the sockstat(1) man page), multiple descriptors may exist for a single
> > socket and kernel code (like nlockmgr) may use the socket(9) API
> > directly so there is no descriptor. However, any socket file descriptor
> > shown by sockstat must correspond to a kernel-level socket shown by
> > netstat.
> > This does appear to be intended, although it is surprising and not
> > documented very well.
> So maybe in light of that, we should change this ticket to update the
> man page to document this case too?
I looked in the code and tried to make sockstat show sockets that are
not associated with any open file. This turned out to be fairly easy.
I have tested this on 10-current and 8-stable. On 8-stable there will be
a conflict in sockstat.1 which can safely be ignored (it is because
r200779 was not MFCed).
On a machine that runs UDP nfsd it adds at least two lines to the
output:
?? ? ? udp6 *:2049*:*
?? ? ? udp4 *:2049*:*
DES, what do you think of this?
Index: usr.bin/sockstat/sockstat.1
===
--- usr.bin/sockstat/sockstat.1(revision 230388)
+++ usr.bin/sockstat/sockstat.1(working copy)
@@ -136,20 +136,6 @@
The address the foreign end of the socket is bound to (see
.Xr getpeername 2 ) .
.El
-.Pp
-Note that TCP sockets in the
-.Dv AF_INET
-or
-.Dv AF_INET6
-domains that are not in one of the
-.Dv LISTEN , SYN_SENT ,
-or
-.Dv ESTABLISHED
-states may not be shown by
-.Nm ;
-use
-.Xr netstat 1
-to examine them instead.
.Sh SEE ALSO
.Xr fstat 1 ,
.Xr netstat 1 ,
@@ -167,10 +153,3 @@
.Nm
command and this manual page were written by
.An Dag-Erling Sm\(/orgrav Aq d...@freebsd.org .
-.Sh BUGS
-Unlike
-.Xr netstat 1 ,
-.Nm
-lists sockets by walking file descriptor tables and will not output
-the ones owned by the kernel, e.g. NLM sockets created by
-.Xr rpc.lockd 8 .
Index: usr.bin/sockstat/sockstat.c
===
--- usr.bin/sockstat/sockstat.c(revision 230388)
+++ usr.bin/sockstat/sockstat.c(working copy)
@@ -86,6 +86,7 @@
struct sock {
void *socket;
void *pcb;
+ int shown;
int vflag;
int family;
int proto;
@@ -571,12 +572,67 @@
}
static void
+displaysock(struct sock *s, int pos)
+{
+ void *p;
+ int hash;
+
+ while (pos < 29)
+ pos += xprintf(" ");
+ pos += xprintf("%s", s->protoname);
+ if (s->vflag & INP_IPV4)
+ pos += xprintf("4 ");
+ if (s->vflag & INP_IPV6)
+ pos += xprintf("6 ");
+ while (pos < 36)
+ pos += xprintf(" ");
+ switch (s->family) {
+ case AF_INET:
+ case AF_INET6:
+ pos += printaddr(s->family, &s->laddr);
+ if (s->family == AF_INET6 && pos >= 58)
+ pos += xprintf(" ");
+ while (pos < 58)
+ pos += xprintf(" ");
+ pos += printaddr(s->family, &s->faddr);
+ break;
+ case AF_UNIX:
+ /* server */
+ if (s->laddr.ss_len > 0) {
+ pos += printaddr(s->family, &s->laddr);
+ break;
+ }
+ /* client */
+ p = *(void **)&s->faddr;
+ if (p == NULL) {
+ pos += xprintf("(not connected)");
+ break;
+ }
+ pos += xprintf("-> ");
+ for (hash = 0; hash < HASHSIZE; ++hash) {
+ for (s = sockhash[hash]; s != NULL; s = s->next)
+ if (s->pcb == p)
+ break;
+ if (s != NULL)
+ break;
+ }
+ if (s == NULL || s->laddr.ss_len == 0)
+ pos += xprintf("??");
+ else
+ pos += printaddr(s->family, &s->laddr);
+ break;
+ default:
+ abort();
+
Re: misc/164383: new freebsd installer is pure CRAP!
Synopsis: new freebsd installer is pure CRAP! State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Sun Jan 22 22:20:35 UTC 2012 State-Changed-Why: PR without substance. While you may feel better for having vented, all you've accomplished is to demotivate at least one person who could have fixed your problem. For an example of more substantial ways to submit PRs, see: http://www.freebsd.org/cgi/query-pr-summary.cgi?text=bsdinstall Responsible-Changed-From-To: freebsd-bugs->linimon Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 22 22:20:35 UTC 2012 Responsible-Changed-Why: Close with bugmeister hat. http://www.freebsd.org/cgi/query-pr.cgi?pr=164383 ___ 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/164382: [ath] crash when down/deleting a vap - inside ieee80211_input_mimo_all()
Synopsis: [ath] crash when down/deleting a vap - inside ieee80211_input_mimo_all() Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 22 22:26:05 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=164382 ___ 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/164220: sound preferences does not allow continuous adjustment of mic level
Synopsis: sound preferences does not allow continuous adjustment of mic level Responsible-Changed-From-To: freebsd-amd64->freebsd-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 22 23:30:02 UTC 2012 Responsible-Changed-Why: Please tell us what sound card and app you are using so that we may classify this PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=164220 ___ 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/163951: security] bundled openssl seems to miss fix for a CVE-2011-1945
Old Synopsis: bundled openssl seems to miss fix for a CVE-2011-1945 New Synopsis: security] bundled openssl seems to miss fix for a CVE-2011-1945 Responsible-Changed-From-To: freebsd-bugs->secteam Responsible-Changed-By: gavin Responsible-Changed-When: Mon Jan 23 00:34:06 UTC 2012 Responsible-Changed-Why: Pass this over to secteam for consideration http://www.freebsd.org/cgi/query-pr.cgi?pr=163951 ___ 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/164393: [rc.d] restarting netif with static addresses doesn't restart routing; makes machine unreachable
>Number: 164393 >Category: misc >Synopsis: [rc.d] restarting netif with static addresses doesn't restart >routing; makes machine unreachable >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: Mon Jan 23 05:30:09 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Garrett Cooper >Release:9.0-STABLE >Organization: n/a >Environment: FreeBSD bayonetta.local 9.0-STABLE FreeBSD 9.0-STABLE #4 r230371M: Thu Jan 19 23:55:38 PST 2012 gcooper@bayonetta.local:/usr/obj/store/freebsd/stable/9/sys/BAYONETTA amd64 >Description: If I set ifconfig_ to something other than "DHCP", then run 'service netif restart', it doesn't automatically restart the routing service, and thus redo the default route. So, the machine is now potentially unreachable from outside the subnet. This is a well-known caveat for seasoned FreeBSD users (it's been present ever since I started using it back in the 5.2 days), but it's an unexpected gotcha for FreeBSD newbies. (more info on this is described here: http://forums.freebsd.org/showthread.php?t=12132 , and several Google searches pull up the same usability nit). Example: # egrep '^(ifconfig_re0|defaultrouter)=' /etc/rc.conf ifconfig_re0="DHCP" # service netif restart Stopping Network: lo0 re0. .. # netstat -nr | grep ^default default192.168.20.1 UGS 00re0 # ping -c 1 google.com PING google.com (74.125.224.82): 56 data bytes 64 bytes from 74.125.224.82: icmp_seq=0 ttl=55 time=16.834 ms --- google.com ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 16.834/16.834/16.834/0.000 ms (Change the address to a static IP; specify the default gateway) # egrep '^(ifconfig_re0|defaultrouter)=' /etc/rc.conf defaultrouter="192.168.20.1" ifconfig_re0="inet 192.168.20.2/24" # service netif restart Stopping Network: lo0 re0. .. # netstat -nr | grep ^default # ping -c 1 google.com ping: cannot resolve google.com: Host name lookup failure # ping -c 1 192.168.20.1 PING 192.168.20.1 (192.168.20.1): 56 data bytes 64 bytes from 192.168.20.1: icmp_seq=0 ttl=64 time=0.662 ms --- 192.168.20.1 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.662/0.662/0.662/0.000 ms The desired behavior would be that the machine would be able to reach outside the network, even after I've restarted the interface. >How-To-Repeat: 1. Change an interface from DHCP to a defaultrouter/static IP configuration. 2. Restart the network interface via service netif restart >Fix: Please note that I'm not requesting that /etc/rc.d/routing be called from /etc/rc.d/netif . This is counterproductive to the way that things should be done. What I'm requesting is that an alternate mechanism for restarting network configuration be setup (sort of like /etc/netstart ) s.t. people who don't want to reinvent the wheel in terms of what /etc/rc.d/netif already does will have a mechanism that's easy to describe to non-FreeBSD savvy users, such that sysadmins won't need to have another machine on-hand to re-bootstrap the routing tables in the machine where the network was restarted. >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"
misc/164394: [GNATS] Change some fields to 'unset' to prevent miscategorization
>Number: 164394
>Category: misc
>Synopsis: [GNATS] Change some fields to 'unset' to prevent
>miscategorization
>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: Mon Jan 23 05:30:09 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Garrett Cooper
>Release:n/a
>Organization:
n/a
>Environment:
n/a
>Description:
Sometimes I file bugs with the wrong Category, Priority, or Class because I
focus on the details behind what I'm reporting and forget the other details in
qualifying the bug.
It might be a good idea if the dropdown boxes were unset ('') to force
individuals, like me, to punch in the right info instead of forcing the
bugbusters to correct the categorization for some of the things I submit.
>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"
misc/164395: [GNATs] add support for .patch attachments
>Number: 164395 >Category: misc >Synopsis: [GNATs] add support for .patch attachments >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: Mon Jan 23 05:40:07 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Garrett Cooper >Release:n/a >Organization: n/a >Environment: n/a >Description: Having a MIME-type for .patch in the web submission form would make life easier when submitting enhancements because then I could submit the same filename via email as well as via GNATs without mangling the filename. >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"
misc/164396: [GNATs] add 'enhancement' class
>Number: 164396 >Category: misc >Synopsis: [GNATs] add 'enhancement' class >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: Mon Jan 23 05:40:07 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Garrett Cooper >Release:n/a >Organization: n/a >Environment: n/a >Description: Many bug systems have a concept of 'enhancements', e.g. items that aren't defects and are meant to improve the status quo of the project that the enhancement was filed against. This would help improve the overall FreeBSD GNATs metrics and give folks a better idea of what's considered a software defect vs what's considered a software enhancement. >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: conf/164393: [rc.d] restarting netif with static addresses doesn't restart routing; makes machine unreachable
Synopsis: [rc.d] restarting netif with static addresses doesn't restart routing; makes machine unreachable Responsible-Changed-From-To: freebsd-bugs->freebsd-rc Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 23 05:44:41 UTC 2012 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=164393 ___ 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/164399: 9.0 installer failures
>Number: 164399 >Category: bin >Synopsis: 9.0 installer failures >Confidential: no >Severity: critical >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Jan 23 07:50:09 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Jin Guojun >Release:9.0-Release >Organization: >Environment: Cannot provide ENV because installation failure Hardware -- HP Pavilion dv5210us (dv5000 serial) laptop >Description: 1) installer configured internal IDE DVD driver as cd0 (not acd0) but trying to mount /dev/acd0, thus boot to root failed. Manually typing in "cd9660:/dev/cd0 ro" will boot. 2) DOS partition table has p1, 2, 3 used for Windows, and BSD is installed on partition 4. New installer does not ask for installing BSD boot menu, so FreeBSD 9.0 cannot boot after installtion. 3) After accidentlly did "bsdlabel -w -B ad0" (should be ad0s4), it screwed the boot sector to cause FreeBSD can NEVER be installed without ZERO out the first track of the hard drive. 3a) After "bsdlabel -w -B ad0", partition table got corrupted, and Windows has to be reinstalled. Windows installation went OK, and boots OK. 3b) New try to install FreBSD again, It see disk like: ada0 55GB BSD ada0a 55GB !0 fdisk sees partition OK (1, 2, 3 are used for Windows) and 25GB are available I have not tried on a different hardware, so no clue if this is for this laptop only. The hard drive on this laptop is 60GB capacity. >How-To-Repeat: See the Full Description section. >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"
