kern/145826: Unable to configure adhoc mode on ath0/wlan0
>Number: 145826 >Category: kern >Synopsis: Unable to configure adhoc mode on ath0/wlan0 >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Apr 19 07:40:01 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Lystopad Olexandr >Release:FreeBSD 8.0-STABLE i386 >Organization: >Environment: System: FreeBSD 8.0-STABLE #0: Wed Apr 14 07:45:45 MSD 2010 r...@serv01:/usr/obj/usr/src/sys/serv01 i386 Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-STABLE #0: Wed Apr 14 07:45:45 MSD 2010 r...@serv01:/usr/obj/usr/src/sys/serv01 i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2194.76-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x40fb2 Family = f Model = 4b Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f real memory = 536870912 (512 MB) avail memory = 449187840 (428 MB) ACPI APIC Table: <050407 APIC1334> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <050407 RSDT1334> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fee0, 1000 (3) failed acpi0: reservation of ffb8, 8 (3) failed acpi0: reservation of fff8, 8 (3) failed acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 1bf0 (3) failed ACPI HPET table warning: Sequence is non-zero (2) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xc000-0xc0ff mem 0xf800-0xfbff,0xfe7f-0xfe7f,0xfe60-0xfe6f irq 18 at device 5.0 on pci1 pcib2: at device 7.0 on pci0 pci2: on pcib2 re0: port 0xd800-0xd8ff mem 0xfe8ff000-0xfe8f irq 19 at device 0.0 on pci2 re0: Using 1 MSI messages re0: Chip rev. 0x3400 re0: MAC rev. 0x miibus0: on re0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re0: Ethernet address: 00:19:db:65:31:df re0: [FILTER] atapci0: port 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem 0xfe5ff800-0xfe5ffbff irq 22 at device 1 8.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI v1.10 controller with 4 3Gbps ports, PM supported ata2: on atapci0 ata2: port is not ready (timeout 0ms) tfd = 01d0 ata2: software reset clear timeout ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ohci0: mem 0xfe5fe000-0xfe5fefff irq 16 at device 19.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xfe5fd000-0xfe5fdfff irq 17 at device 19.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ohci2: mem 0xfe5fc000-0xfe5fcfff irq 18 at device 19.2 on pci0 ohci2: [ITHREAD] usbus2: on ohci2 ohci3: mem 0xfe5fb000-0xfe5fbfff irq 17 at device 19.3 on pci0 ohci3: [ITHREAD] usbus3: on ohci3 ohci4: mem 0xfe5fa000-0xfe5fafff irq 18 at device 19.4 on pci0 ohci4: [ITHREAD] usbus4: on ohci4 ehci0: mem 0xfe5ff000-0xfe5ff0ff irq 19 at device 19.5 on pci0 ehci0: [ITHREAD] ehci0: AMD SB600/700 quirk applied usbus5: EHCI version 1.0 usbus5: on ehci0 pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] pci0: at device 20.2 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pci3: on pcib3 fxp0: port 0xe800-0xe81f mem 0xfdfff000-0xfdff,0xfeb0-0xfebf irq 22 at device 2.0 on pci3 fxp0: Enabling Rx lock-up workaround miibus1: on fxp0 inphy0: PHY 1 on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:08:c7:c9:55:38 fxp0: [ITHREAD] ath0: mem 0xfe9f-0xfe9f irq 21 at device 3.0 on pci3 ath0: [ITHREAD] ath0: AR5212 mac 5.9 RF5112 phy 4.3 acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] pmtimer0 on isa0 orm0: at iomem 0xcd800-0xce7ff,0xce800-0xcefff pnpid ORM on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3d
Re: kern/59739: [patch] [libc] rmdir(2) and mkdir(2) both return EISDIR for argument "/"
The following reply was made to PR kern/59739; it has been noted by GNATS. From: Alexander Best To: Cc: Subject: Re: kern/59739: [patch] [libc] rmdir(2) and mkdir(2) both return EISDIR for argument "/" Date: Mon, 19 Apr 2010 12:46:02 +0200 (CEST) i think this issue got fixed in r205682. please mark patched and assign to jh@ as MFC reminder. -- Alexander Best ___ 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/145825: [panic] panic: soabort: so_count
Synopsis: [panic] panic: soabort: so_count Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 19 14:35:30 UTC 2010 Responsible-Changed-Why: apparently involves the network stack. http://www.freebsd.org/cgi/query-pr.cgi?pr=145825 ___ 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/145826: [ath] Unable to configure adhoc mode on ath0/wlan0
Old Synopsis: Unable to configure adhoc mode on ath0/wlan0 New Synopsis: [ath] Unable to configure adhoc mode on ath0/wlan0 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 19 14:36:30 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=145826 ___ 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/59739: [patch] [libc] rmdir(2) and mkdir(2) both return EISDIR for argument "/"
Synopsis: [patch] [libc] rmdir(2) and mkdir(2) both return EISDIR for argument "/" State-Changed-From-To: analyzed->patched State-Changed-By: linimon State-Changed-When: Mon Apr 19 14:37:29 UTC 2010 State-Changed-Why: Apparently jh committed a patch. Assign and set to patched as MFC reminder. Responsible-Changed-From-To: freebsd-bugs->jh Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 19 14:37:29 UTC 2010 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=59739 ___ 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/59739: [patch] [libc] rmdir(2) and mkdir(2) both return EISDIR for argument "/"
Synopsis: [patch] [libc] rmdir(2) and mkdir(2) both return EISDIR for argument "/" State-Changed-From-To: patched->analyzed State-Changed-By: linimon State-Changed-When: Mon Apr 19 19:04:33 UTC 2010 State-Changed-Why: false alarm, it seems. Responsible-Changed-From-To: jh->freebsd-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 19 19:04:33 UTC 2010 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=59739 ___ 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/145212: [build] Feature Request: Be able to build FreeBSD with man utilities but not with man pages
Synopsis: [build] Feature Request: Be able to build FreeBSD with man utilities but not with man pages Responsible-Changed-From-To: freebsd-bugs->jkim Responsible-Changed-By: jkim Responsible-Changed-When: Mon Apr 19 19:30:13 UTC 2010 Responsible-Changed-Why: I'll take a look at it. http://www.freebsd.org/cgi/query-pr.cgi?pr=145212 ___ 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/143972: mptutil(8) segfault
The following reply was made to PR bin/143972; it has been noted by GNATS. From: Charles Owens To: bug-follo...@freebsd.org, cow...@greatbaysoftware.com Cc: Subject: Re: bin/143972: mptutil(8) segfault Date: Mon, 19 Apr 2010 19:41:34 -0400 Issue resolved via patch from John Baldwin (thanks much!). For discussion thread see: http://docs.freebsd.org/cgi/mid.cgi?201002181023.08131.jhb Patch committed to -CURRENT: 204086 and 204090... already MFC'd. -- Charles Owens Great Bay Software, Inc. ___ 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/145748: hexdump(1) %s format qualifier broken
The following reply was made to PR bin/145748; it has been noted by GNATS. From: Wayne Sierke To: Garrett Cooper Cc: bug-follo...@freebsd.org Subject: Re: bin/145748: hexdump(1) %s format qualifier broken Date: Tue, 20 Apr 2010 12:33:14 +0930 > > "4" in %4s" is the field width. "%.4s" has precision 4 and is = > accepted, > > but I don't know what most of this is supposed to do so I don't know = > if > > this actually works. As noted by Bruce, the provided test-case was setting field width instead of field precision. This seems to be a case of "works as advertised". # jot -b a 1024 | hexdump -e '"%.4s\n"' a a * # jot -b a 1024 | hexdump -e ' /4 "%s\n"' a a * # I did stumble upon the following, however, which looks like a bug (if I haven't missed something): # jot -w "%07d" 32 0 | tr '\012' '\040' | hexdump -e '"%.32s\n"' 000 001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031 # jot -w "%07d" 32 0 | tr '\012' '\040' | hexdump -e '/32 "%s\n"' 000 001 002 003 004 005 006 007 008 009 010 011 004 005 006 007 012 013 014 015 016 017 018 019 012 013 014 015 020 021 022 023 024 025 026 027 020 021 022 023 028 029 030 031 # Seems to be reproducible for "byte count" = 2^n (n=1,2,3,...). Should probably go in a new PR (although I haven't checked for an existing one). ___ 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/145865: kernel memory leak with disabled devd and hw.bus.devctl_disable=1
>Number: 145865
>Category: kern
>Synopsis: kernel memory leak with disabled devd and
>hw.bus.devctl_disable=1
>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: Tue Apr 20 04:30:05 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Alexey Illarionov
>Release:7.3-STABLE
>Organization:
>Environment:
7.3-STABLE FreeBSD 7.3-STABLE #1: Mon Apr 19 05:25:53 MSD 2010 i386
>Description:
The 7.3-STABLE kernel leaks memory when devd is disabled even when
hw.bus.devctl_disable=1.
The same problem exists on recent 8 stable with hw.bus.devctl_queue=0 and
hw.bus.devctl_disable=1
I have mpd5 server with about 400 online users. After about month of uptime
there was a kernel panic:
panic: kmem_malloc(16384): kmem_map too small: 335544320 total allocated
vmstat points to high bus memory usage:
bus 4891890 191093K - 4907302 16,32,64,128,1024
>How-To-Repeat:
1. Turn off devd:
# /etc/rc.d/devd stop
# sysctl hw.bus.devctl_disable=1
2. Create some kernel events and watch for memory:
# vmstat -m | awk '$1=="bus"{print $1,$2,$3}'
bus 1053 50K
# for i in `jot - 1 50` ; do ifconfig gre$i create ; ifconfig gre$i destroy ;
done
# vmstat -m | awk '$1=="bus"{print $1,$2,$3}'
bus 1153 57K
# for i in `jot - 1 50` ; do ifconfig gre$i create ; ifconfig gre$i destroy ;
done
# vmstat -m | awk '$1=="bus"{print $1,$2,$3}'
bus 1254 63K
>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/145759: [patch] Add do-not-fragment option support to ping6(8)
Synopsis: [patch] Add do-not-fragment option support to ping6(8) State-Changed-From-To: open->patched State-Changed-By: maxim State-Changed-When: Tue Apr 20 06:17:32 UTC 2010 State-Changed-Why: Committed to HEAD. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=145759 ___ 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/145759: commit references a PR
The following reply was made to PR bin/145759; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: bin/145759: commit references a PR
Date: Tue, 20 Apr 2010 06:10:14 + (UTC)
Author: maxim
Date: Tue Apr 20 06:10:05 2010
New Revision: 206889
URL: http://svn.freebsd.org/changeset/base/206889
Log:
o Add do-not-fragment option support to ping6(8).
PR: bin/145759
Submitted by:pluknet
MFC after: 1 month
Modified:
head/sbin/ping6/ping6.8
head/sbin/ping6/ping6.c
Modified: head/sbin/ping6/ping6.8
==
--- head/sbin/ping6/ping6.8Tue Apr 20 06:08:34 2010(r206888)
+++ head/sbin/ping6/ping6.8Tue Apr 20 06:10:05 2010(r206889)
@@ -29,7 +29,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd August 27, 2008
+.Dd April 20, 2010
.Dt PING6 8
.Os
.Sh NAME
@@ -40,9 +40,9 @@ packets to network hosts
.Sh SYNOPSIS
.Nm
.\" without ipsec, or new ipsec
-.Op Fl dfHmnNoqrRtvwW
+.Op Fl DdfHmnNoqrRtvwW
.\" old ipsec
-.\" .Op Fl AdEfmnNqRtvwW
+.\" .Op Fl ADdEfmnNqRtvwW
.Bk -words
.Op Fl a Ar addrtype
.Ek
@@ -141,6 +141,8 @@ Stop after sending
.Ar count
.Tn ECHO_RESPONSE
packets.
+.It Fl D
+Disable IPv6 fragmentation.
.It Fl d
Set the
.Dv SO_DEBUG
Modified: head/sbin/ping6/ping6.c
==
--- head/sbin/ping6/ping6.cTue Apr 20 06:08:34 2010(r206888)
+++ head/sbin/ping6/ping6.cTue Apr 20 06:10:05 2010(r206889)
@@ -191,6 +191,7 @@ struct tv32 {
#define F_ONCE0x20
#define F_AUDIBLE 0x40
#define F_MISSED 0x80
+#define F_DONTFRAG0x100
#define F_NOUSERDATA (F_NODEADDR | F_FQDN | F_FQDNOLD | F_SUPTYPES)
u_int options;
@@ -349,7 +350,7 @@ main(argc, argv)
#endif /*IPSEC_POLICY_IPSEC*/
#endif
while ((ch = getopt(argc, argv,
- "a:b:c:dfHg:h:I:i:l:mnNop:qrRS:s:tvwW" ADDOPTS)) != -1) {
+ "a:b:c:DdfHg:h:I:i:l:mnNop:qrRS:s:tvwW" ADDOPTS)) != -1) {
#undef ADDOPTS
switch (ch) {
case 'a':
@@ -415,6 +416,9 @@ main(argc, argv)
errx(1,
"illegal number of packets -- %s", optarg);
break;
+ case 'D':
+ options |= F_DONTFRAG;
+ break;
case 'd':
options |= F_SO_DEBUG;
break;
@@ -742,7 +746,11 @@ main(argc, argv)
for (i = 0; i < sizeof(nonce); i += sizeof(u_int32_t))
*((u_int32_t *)&nonce[i]) = arc4random();
#endif
-
+ optval = 1;
+ if (options & F_DONTFRAG)
+ if (setsockopt(s, IPPROTO_IPV6, IPV6_DONTFRAG,
+ &optval, sizeof(optval)) == -1)
+ err(1, "IPV6_DONTFRAG");
hold = 1;
if (options & F_SO_DEBUG)
@@ -2780,7 +2788,7 @@ usage()
"A"
#endif
"usage: ping6 [-"
- "d"
+ "Dd"
#if defined(IPSEC) && !defined(IPSEC_POLICY_IPSEC)
"E"
#endif
___
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"
Re: bin/145748: hexdump(1) %s format qualifier broken
The following reply was made to PR bin/145748; it has been noted by GNATS. From: Garrett Cooper To: Wayne Sierke Cc: bug-follo...@freebsd.org Subject: Re: bin/145748: hexdump(1) %s format qualifier broken Date: Mon, 19 Apr 2010 23:31:41 -0700 On Mon, Apr 19, 2010 at 8:03 PM, Wayne Sierke wrote: >> =A0> "4" in %4s" is the field width. =A0"%.4s" has precision 4 and is = =3D >> =A0accepted, >> =A0> but I don't know what most of this is supposed to do so I don't kno= w =3D >> =A0if >> =A0> this actually works. > > As noted by Bruce, the provided test-case was setting field width > instead of field precision. This seems to be a case of "works as > advertised". Except from a programming perspective it really doesn't make sense to support a field width from a strict standpoint, whereas the relaxed version, like so works and is standard in multiple programming languages out there: "%4s" The fact that "%4s" fails and isn't noted in the addendum is a failure according to the specifications of hexdump as per the manpage; "%.4s" passing is a reasonable workaround for broken "%[:digit:]s" functionality. I have a patch for this, but it's a part of a much bigger change that I'm working on for hexdump, and I'd rather this be documented so we can move on to the point where all of the items need to be committed all at once and all of these PRs can be fixed. > # jot -b a 1024 | hexdump -e '"%.4s\n"' > a > a > > * > # jot -b a 1024 | hexdump -e ' /4 "%s\n"' > a > a > > * > # > > I did stumble upon the following, however, which looks like a bug (if I > haven't missed something): > > # jot -w "%07d" 32 0 | tr '\012' '\040' | hexdump -e '"%.32s\n"' > 000 001 002 003 > 004 005 006 007 > 008 009 010 011 > 012 013 014 015 > 016 017 018 019 > 020 021 022 023 > 024 025 026 027 > 028 029 030 031 > # jot -w "%07d" 32 0 | tr '\012' '\040' | hexdump -e '/32 "%s\n"' > 000 001 002 003 > 004 005 006 007 > 008 009 010 011 004 005 006 007 > 012 013 014 015 > 016 017 018 019 012 013 014 015 > 020 021 022 023 > 024 025 026 027 020 021 022 023 > 028 029 030 031 > # > > Seems to be reproducible for "byte count" =3D 2^n (n=3D1,2,3,...). I think this is a bug in display.c in terms of how it's consuming bytes. I'll analyze it tonight and figure out whether or not the issue is valid (looks like it but I want to be sure), and figure out where the problem needs to be fixed (it's present in my modified version and the original). > Should probably go in a new PR (although I haven't checked for an > existing one). Cheers :), -Garrett ___ 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"
