Re: ports/148272: polkit-gnome-authen core dumps when starting gnome
Synopsis: polkit-gnome-authen core dumps when starting gnome Responsible-Changed-From-To: freebsd-bugs->freebsd-ports-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jul 1 07:45:48 UTC 2010 Responsible-Changed-Why: ports PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=148272 ___ 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"
kern/148290: "sticky-address" option of Packet Filter (PF) blocks connection
>Number: 148290
>Category: kern
>Synopsis: "sticky-address" option of Packet Filter (PF) blocks connection
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Jul 01 12:50:03 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Simon "Saimoun" Lasnier
>Release:8.0-RELEASE
>Organization:
C2B
>Environment:
FreeBSD lb-Stemp.c2bsa.local 8.0-RELEASE FreeBSD 8.0-RELEASE #1: Wed Jun 30
14:39:04 UTC 2010
r...@lb-stemp.c2bsa.local:/usr/obj/usr/src/sys/SOEKRIS i386
>Description:
When using Packet Filter (PF) for load-balancing outgoing connections with 2
addresses in the pool, the connection take randomly one of the two connections.
If we want that each source address takes always the same way, we need to put
the keyword "sticky-address" in the pass rule in pf.conf.
In a computer where the LAN is "vr1" and two WAN are "vr2" and "vr3", this rule
is used :
pass in log on vr1 route-to {(vr2 $vr2_gw),(vr3 $vr3_gw)} \
sticky-address from to !
But this option seems to allow only one computer for each connection.
When one computer is already connected with one of the two WAN, if another
computer want to access the same WAN, it cannot. But in the pflog0, pf says
that it has passed the connection, on the right rule (the one which has a
route-to).
>How-To-Repeat:
Install FreeBSD on a computer (called "FreeBSD-PC") which has at least 3
interfaces (called vr1 vr2 vr3).
We supposed that there are one LAN on 192.168.0.0/24 connected to vr1 and two
WANs which gateways are 81.42.133.1 and 146.43.222.34 connected respectively to
vr2 and vr3.
Create /etc/pf.conf and put that lines in :
pass in log on vr1 route-to { (vr2 81.42.133.1), (vr3 146.43.222.34) } \
sticky-address from 192.168.0.0/24 to !192.168.0.0/24
Launch PF :
prompt# pfctl -e
prompt# pfctl -F all -f /etc/pf.conf
Now connect two other computers to FreeBSD-PC, configure their Ethernet
interface with the network 192.168.0.0/24, and add in their route table a
default route to the FreeBSD-PC (for example "route add default 192.168.0.1" if
192.168.0.1 is the address of the FreeBSD-PC in the vr1 interface).
Then, if you tried to access to the Internet (through one of the two WAN) with
the two computers, sometimes it will work (with a good "sticky", that is to say
one computer takes always the same WAN), but sometimes one of the two computers
is blocked, packets never reach the gateway, whereas we can see "pass" in the
pflog0 interface.
>Fix:
Don't know.
>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/144441: sed(1): Confusing error message from sed with 's/.*/d' ": unescaped newline inside substitute pattern
Synopsis: sed(1): Confusing error message from sed with 's/.*/d' ": unescaped newline inside substitute pattern State-Changed-From-To: open->closed State-Changed-By: jh State-Changed-When: Thu Jul 1 15:46:46 UTC 2010 State-Changed-Why: Closed at submitter's request. http://www.freebsd.org/cgi/query-pr.cgi?pr=11 ___ 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/148296: [zfs] [loader] Very slow probe in /usr/src/sys/boot/zfs/zfs.c
>Number: 148296
>Category: bin
>Synopsis: [zfs] [loader] Very slow probe in /usr/src/sys/boot/zfs/zfs.c
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Jul 01 16:10:06 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Jimmy Olgeni
>Release:FreeBSD 8.1-RC1 i386
>Organization:
>Environment:
System: FreeBSD backoffice 8.1-RC1 FreeBSD 8.1-RC1 #0: Fri Jun 25 21:42:58 CEST
2010 r...@backoffice:/usr/obj/usr/src/sys/RELENG_8.i386 i386
>Description:
Code in /usr/src/sys/boot/zfs/zfs.c (zfs_dev_init) probes all
possible disks/partitions to reconstruct ZFS pools.
Until rev 198420 it used to probe 4 partitions, which caused no
harm. However, with rev 198420 it started to probe all 128 possible
GPT partitions, causing very long boot times.
The problem is that for each possible GPT partition (diskNpM) the
code tries to fall back to a MBR slice (diskNsM).
When the code falls back to probing slices it actually ignores the
fact that the diskNpM partition could not be opened, and keeps
probing missing partitions up to index 128 (which takes a while).
If the partition index is > 4, the code tries to probe slices that
cannot possibly exist (diskNs5, ...), thus doubling the already
long processing time.
>How-To-Repeat:
>Fix:
Since we are looking for boot partitions, I think it should be safe
to assume that there are no empty partitions before them.
I moved slice probing into a separate loop to avoid any issues with
fallback code.
With the attached patch my 8.1-RC1 zfs-only server got back its old
boot time.
*** zfs.c.orig Thu Jul 1 17:14:42 2010
--- zfs.c Thu Jul 1 17:40:03 2010
***
*** 413,427
if (vdev_probe(vdev_read, (void*) (uintptr_t) fd, 0))
close(fd);
for (slice = 1; slice <= 128; slice++) {
sprintf(devname, "disk%dp%d:", unit, slice);
fd = open(devname, O_RDONLY);
! if (fd == -1) {
! sprintf(devname, "disk%ds%d:", unit, slice);
! fd = open(devname, O_RDONLY);
! if (fd == -1)
! continue;
! }
if (vdev_probe(vdev_read, (void*) (uintptr_t) fd, 0))
close(fd);
}
--- 413,432
if (vdev_probe(vdev_read, (void*) (uintptr_t) fd, 0))
close(fd);
+ for (slice = 1; slice <= 4; slice++) {
+ sprintf(devname, "disk%ds%d:", unit, slice);
+ fd = open(devname, O_RDONLY);
+ if (fd == -1)
+ continue;
+ if (vdev_probe(vdev_read, (void*) (uintptr_t) fd, 0))
+ close(fd);
+ }
+
for (slice = 1; slice <= 128; slice++) {
sprintf(devname, "disk%dp%d:", unit, slice);
fd = open(devname, O_RDONLY);
! if (fd == -1)
! break;
if (vdev_probe(vdev_read, (void*) (uintptr_t) fd, 0))
close(fd);
}
>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/58390: bsdlabel(8) fails to display an error message if the label could not be written
Synopsis: bsdlabel(8) fails to display an error message if the label could not
be written
State-Changed-From-To: open->feedback
State-Changed-By: jh
State-Changed-When: Thu Jul 1 15:55:12 UTC 2010
State-Changed-Why:
Is this still a problem for you?
On 8.0:
/dev/md1 on /mnt (ufs, local)
# bsdlabel -w /dev/md1
bsdlabel: Class not found
But this is because GEOM_BSD has been changed to GEOM_PART_BSD.
The error message is not very informative.
On 7.3 (uses GEOM_BSD):
# bsdlabel -w /dev/md1
bsdlabel: Geom not found: "md0"
Not very informative either.
This change makes the error message more understandable for me:
%%%
Index: sbin/bsdlabel/bsdlabel.c
===
--- sbin/bsdlabel/bsdlabel.c(revision 209622)
+++ sbin/bsdlabel/bsdlabel.c(working copy)
@@ -382,7 +382,7 @@ static int
writelabel(void)
{
uint64_t *p, sum;
- int i, fd;
+ int i, fd, serrno;
struct gctl_req *grq;
char const *errstr;
struct disklabel *lp = &lab;
@@ -413,6 +413,7 @@ writelabel(void)
fd = open(specname, O_RDWR);
if (fd < 0) {
+ serrno = errno;
if (is_file) {
warn("cannot open file %s for writing label", specname);
return(1);
@@ -426,7 +427,7 @@ writelabel(void)
bootarea + labeloffset + labelsoffset * secsize);
errstr = gctl_issue(grq);
if (errstr != NULL) {
- warnx("%s", errstr);
+ warnc(serrno, "%s", specname);
gctl_free(grq);
return(1);
}
%%%
With the patch applied:
# bsdlabel -w /dev/md1
bsdlabel: /dev/md1: Operation not permitted
Responsible-Changed-From-To: freebsd-bugs->jh
Responsible-Changed-By: jh
Responsible-Changed-When: Thu Jul 1 15:55:12 UTC 2010
Responsible-Changed-Why:
Track.
http://www.freebsd.org/cgi/query-pr.cgi?pr=58390
___
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/148087: commit references a PR
The following reply was made to PR kern/148087; it has been noted by GNATS. From: dfil...@freebsd.org (dfilter service) To: bug-follo...@freebsd.org Cc: Subject: Re: kern/148087: commit references a PR Date: Thu, 1 Jul 2010 17:46:25 + (UTC) Author: des Date: Thu Jul 1 17:44:33 2010 New Revision: 209632 URL: http://svn.freebsd.org/changeset/base/209632 Log: If the A flag is supplied, http_request() will attempt the request only once, even if authentication is required, instead of retrying with the proper credentials. Fix this by bumping the countdown if the origin or proxy server requests authentication so that the initial unauthenticated request does not count as an attempt. PR: 148087 Submitted by:Tom Evans MFC after: 2 weeks Modified: head/lib/libfetch/http.c Modified: head/lib/libfetch/http.c == --- head/lib/libfetch/http.c Thu Jul 1 15:23:29 2010(r209631) +++ head/lib/libfetch/http.c Thu Jul 1 17:44:33 2010(r209632) @@ -1786,12 +1786,14 @@ http_request(struct url *URL, const char case hdr_www_authenticate: if (conn->err != HTTP_NEED_AUTH) break; - http_parse_authenticate(p, &server_challenges); + if (http_parse_authenticate(p, &server_challenges)) + ++n; break; case hdr_proxy_authenticate: if (conn->err != HTTP_NEED_PROXY_AUTH) break; - http_parse_authenticate(p, &proxy_challenges); + if (http_parse_authenticate(p, &proxy_challenges) == 0); + ++n; break; case hdr_end: /* fall through */ ___ svn-src-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org" ___ 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"
kern/148302: Firewire-attached "My Book" drive gets no device node at boot time, but does after
>Number: 148302 >Category: kern >Synopsis: Firewire-attached "My Book" drive gets no device node at boot >time, but does after >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jul 01 23:50:01 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Andrew Reilly >Release:FreeBSD 9.0-CURRENT amd64 >Organization: >Environment: System: FreeBSD duncan.reilly.home 9.0-CURRENT FreeBSD 9.0-CURRENT #4: Sat Jun 26 00:24:47 EST 2010 r...@duncan.reilly.home:/nb/obj/nb/src/sys/DUNCAN amd64 Machine is an AthlonX2-4200 on a Gigabyte motherboard with NVidia chipset. >Description: This isn't really a new problem, but I noticed that the original report that I made (kern/136652) has been closed. Apparently I reported that the problem had gone away. I can't remember when it re-appeared, but it's back. Perhaps it came back after I upgraded to current from stable? Anyway, the problem is that the firewire stack seems to "see" the drive at boot (mentions it in the dmesg lines, eg:) fwohci0: mem 0xf2004000-0xf20047ff,0xf200-0xf2003fff irq 18 at device 10.0 on pci1 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:14:85:56:00:e6:80:b0 fwohci0: invalid speed 7 (fixed to 3). fwohci0: Phy 1394a available S800, 3 ports. fwohci0: Link S800, max_rec 4096 bytes. firewire0: on fwohci0fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:14:85:e6:80:b0 fwe0: Ethernet address: 02:14:85:e6:80:b0 fwip0: on firewire0 fwip0: Firewire address: 00:14:85:56:00:e6:80:b0 @ 0xfffe, S800, maxrec 4096 sbp0: on firewire0 dcons_crom0: on firewire0dcons_crom0: bus_addr 0x11c4000 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x0001, SelfID Count=1, CYCLEMASTER mode : : firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1) (me) firewire0: bus manager 1 fwohci0: phy int : : firewire0: New S800 device ID:0090a97488ce53aa sbp0: sbp_show_sdev_info: sbp0:0:0: ordered:1 type:0 EUI:0090a97488ce53aa node:0 speed:3 maxrec:8 sbp0: sbp_show_sdev_info: sbp0:0:0 'WD' 'My Book' '001028' sbp0: sbp_show_sdev_info: sbp0:0:1: ordered:1 type:13 EUI:0090a97488ce53aa node:0 speed:3 maxrec:8 sbp0: sbp_show_sdev_info: sbp0:0:1 'WD' 'My Book' '001028' : : but /dev/da0 does not show up until after boot, after I've manually run "fwcontrol -r". This This doesn't seem to be critical, because if I'm careful I know how to work around the problem, but it does mean that I have to remember to comment that drive out of /etc/fstab before I reboot remotely, or the box will wind up sitting in single-user mode after failing the fsck -p pass... >How-To-Repeat: Works (or fails to) every time, on my hardware. Not sure how to replicate it elsewhere. >Fix: No fix, but my work-around is to have an rc script that tweaks that drive out of fstab on shutdown, and tweaks it back in on boot, then fwcontrol -r/sleep/fsck -p manually. >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"
kern/148307: Incorrect alignment checks in sys/mips/atheros/if_arge.c
>Number: 148307 >Category: kern >Synopsis: Incorrect alignment checks in sys/mips/atheros/if_arge.c >Confidential: no >Severity: non-critical >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jul 02 06:50:01 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:FreeBSD 9.0-CURRENT mips >Organization: >Environment: FreeBSD 9.0-CURRENT, from ~ january (verified the arge driver hasn't changed since.) Hardware: Ubiquiti Routerstation Pro, AR71XX series SoC. Atheros wireless NIC(s)in HostAP mode. (AR5212/AR9160.) >Description: 2 bytes would appear in between the ethernet header and the ethernet payload in some circumstances. In this particular circumstance, it's when bridging over GRE tunnels. Traffic from an ethernet connected host worked, but traffic from a wireless connected host didn't. The if_arge() TX code would check the first fragment to see whether it's aligned and if not, a call to m_defrag() would align and pack the fragments. The hardware requires all fragments to be 4 bytes aligned - and that all fragments save the last be a size that's a multiple of 4 bytes. In the case I was seeing, an encapsulated packet would be an mbuf chain consisting of two parts. The first mbuf would have a 14 byte ethernet header (6 byte src, 6 byte dst, 2 byte ethertype) and then the original payload in the second mbuf. This didn't trigger the call to m_defrag() and thus the packet was passed along, untouched. "Normal" traffic almost exclusively was misaligned and called m_defrag(). >How-To-Repeat: Implement a pair of units which are bridging over GRE/IP: * create bridge0 * create gre0, mtu 1500, setup IPs as needed * throw arge1, wlan0, etc into bridge0 * throw gre0 into bridge0 * send traffic from wlan0 to a host on the other side of the bridge - this fails >Fix: The fix would be to check each mbuf in the TX chain for size and alignment then call m_defrag() if the constraints are missed. My local fix was just to always call m_defrag() for now. It is inefficient but it resolves the issue. >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"
