Re: panic with if_iwi(4) upon netif restart
On Tuesday 19 June 2012 07:28:11 Alexey Dokuchaev wrote: On Mon, May 07, 2012 at 08:28:50PM +0200, Bernhard Schmidt wrote: On Mon, May 7, 2012 at 5:54 AM, Alexey Dokuchaev da...@nsu.ru wrote: Weird panic occurs to me here with iwi(4) based laptop when trying to hook up to WPA-protected network with service netif restart. Kernel and userland are not strictly in sync, with the latter lagging behind couple of months, but presumably this fact should not matter on stable branch. does ps in kgdb reveal multiple instances of wpa_supplicant running? If so, this seems to be the well known devd+netif+supplicant+newstate race/missing refcount. Wanna try attached patch? Bernhard, Sorry it took so long to get back. With your patch applied, I haven't seen this panic for a while, however, double instances of wpa_supplicant still persist. So I think you can commit it, but underlying race remains to be fixed. Ok, thanks. The patch is indeed supposed to only fix the panics. The underlying problem is that a netif restart results in 2 calls to netif wlan0 start, one through the call itself the other due an event sent to devd. wpa_supplicant itself has a small window were it is possible that 2 instances are attached to one resource. I have yet to find a solution for this without adding any regressions. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: vlan+iwn panic
On Mon, Jun 18, 2012 at 12:52 PM, David ROFFIAEN d...@roffiaen.com wrote: Hi list, I encoutered a panic with FreeBSD 9 Stable creating vlan with wlan0 (iwn0) parent. Panic occur when upping the vlan : Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xff800024b3f0 frame pointer = 0x28:0xff800024b4b0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi4: clock) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0x80625896 at kdb_backtrace+0x66 #1 0x805ed71e at panic+0x1ce #2 0x80887690 at trap_fatal+0x290 #3 0x808879fc at trap_pfault+0x21c #4 0x80887ff5 at trap+0x365 #5 0x80872713 at calltrap+0x8 #6 0x807b9968 at nd6_output+0x18 #7 0x807b41ed at ip6_output+0x11dd #8 0x807b4c8c at mld_dispatch_packet+0xdc #9 0x807b5121 at mld_dispatch_queue+0x21 #10 0x807b7ac0 at mld_fasttimo+0x640 #11 0x8064fdbb at pffasttimo+0x2b #12 0x80603540 at softclock+0x3c0 #13 0x805bf3e4 at intr_event_execute_handlers+0x104 #14 0x805c0b64 at ithread_loop+0xa4 #15 0x805bc04f at fork_exit+0x11f #16 0x80872c3e at fork_trampoline+0xe I don't see this on HEAD, so some commit might have fixed it, not certain which one though. I'm running into another panic though. This problem doesn't occur with atheros card on SOEKRIS (i386). Just the up works or can you even do traffic? I'm not so sure about the later, I'm not aware that wlan+vlan has ever be tested. If it works for ath though, I'll look into the iwn part. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: vlan+iwn panic
On Mon, Jun 18, 2012 at 3:30 PM, Albert Shih albert.s...@obspm.fr wrote: Le 18/06/2012 ? 12:52:19+0200, David ROFFIAEN a écrit Hi list, I encoutered a panic with FreeBSD 9 Stable creating vlan with wlan0 (iwn0) parent. Panic occur when upping the vlan : I've same problem whitout vlan. Just sometime (rarely) when the signal of the wifi is very weak the system crash with something very close. Very close? Do you mean same backtrace? Write a report next time you run into it please, preferably with a way to reproduce. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: panic with if_iwi(4) upon netif restart
On Mon, May 7, 2012 at 5:54 AM, Alexey Dokuchaev da...@nsu.ru wrote: Folks, Weird panic occurs to me here with iwi(4) based laptop when trying to hook up to WPA-protected network with service netif restart. Kernel and userland are not strictly in sync, with the latter lagging behind couple of months, but presumably this fact should not matter on stable branch. I was only able to get online by manually running wpa_supplicant(8) and dhclient(8). if_iwi(4) loaded after system fully boots (i.e. manually after login). [snip] Feel free to ask for more information. does ps in kgdb reveal multiple instances of wpa_supplicant running? If so, this seems to be the well known devd+netif+supplicant+newstate race/missing refcount. Wanna try attached patch? -- Bernhard iwi_vs_sta1.diff Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: problem with urtw
On Thursday, June 09, 2011 22:34:18 Jim Bryant wrote:
I just bought one of those chinese (apparently the same unit relabeled
and being sold by multiple companies) realtek RTL8187B wifi units. The
price is right.
The label name on this one is WiFySky 1500mW.
other than the fact that the case it is enclosed in is really cheesy,
there is a more immediate problem with this.
the current urtw driver returns a 6.
here we go:
on insert:
ugen3.2: vendor 0x0bda at usbus3
after kldload if_urtw.ko:
urtw0: vendor 0x0bda product 0x8187, class 0/0, rev 2.00/2.00, addr 2
on usbus3
urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
device_attach: urtw0 attach returned 6
urtw0: vendor 0x0bda product 0x8187, class 0/0, rev 2.00/2.00, addr 2
on usbus3
urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
device_attach: urtw0 attach returned 6
urtw0: vendor 0x0bda product 0x8187, class 0/0, rev 2.00/2.00, addr 2
on usbus3
urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
device_attach: urtw0 attach returned 6
urtw0: vendor 0x0bda product 0x8187, class 0/0, rev 2.00/2.00, addr 2
on usbus3
urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
device_attach: urtw0 attach returned 6
3:28:35pm argus(48): usbconfig -u 3 -a 2 dump_device_desc
ugen3.2: product 0x8187 vendor 0x0bda at usbus3, cfg=0 md=HOST
spd=HIGH (480Mbps) pwr=ON
bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x
bDeviceSubClass = 0x
bDeviceProtocol = 0x
bMaxPacketSize0 = 0x0040
idVendor = 0x0bda
idProduct = 0x8187
bcdDevice = 0x0200
iManufacturer = 0x0001 Wireless Manufacturer
iProduct = 0x0002 USB2.0 WLAN Adapter
iSerialNumber = 0x no string
bNumConfigurations = 0x0001
3:28:48pm argus(49): usbconfig -u 3 -a 2 dump_curr_config_desc
ugen3.2: product 0x8187 vendor 0x0bda at usbus3, cfg=0 md=HOST
spd=HIGH (480Mbps) pwr=ON
Configuration index 0
bLength = 0x0009
bDescriptorType = 0x0002
wTotalLength = 0x0051
bNumInterfaces = 0x0001
bConfigurationValue = 0x0001
iConfiguration = 0x0004 Wireless Network Card
bmAttributes = 0x0080
bMaxPower = 0x00fa
Interface 0
bLength = 0x0009
bDescriptorType = 0x0004
bInterfaceNumber = 0x
bAlternateSetting = 0x
bNumEndpoints = 0x0009
bInterfaceClass = 0x00ff
bInterfaceSubClass = 0x00ff
bInterfaceProtocol = 0x00ff
iInterface = 0x0002 USB2.0 WLAN Adapter
Endpoint 0
bLength = 0x0007
bDescriptorType = 0x0005
bEndpointAddress = 0x0083 IN
I have no clue what I'm talking about, so, this might be wrong..
Anyways.. the urtw(4) driver supports two different chips the
8187B and 8187L. One difference between those is the number of
endpoints and its addresses. The 8187L uses 3 endpoints with
0x81 as the RX endpoint, the 8187B uses 7 endpoints with 0x83 as
RX.
% vendor REALTEK0x0bda Realtek
% product REALTEK RTL8187 0x8187 RTL8187 Wireless Adapter
Quoting from the driver:
% #define URTW_DEV_B(v,p) \
% { USB_VPI(USB_VENDOR_##v, USB_PRODUCT_##v##_##p, URTW_REV_RTL8187B) }
% #define URTW_DEV_L(v,p) \
% { USB_VPI(USB_VENDOR_##v, USB_PRODUCT_##v##_##p, URTW_REV_RTL8187L) }
% ..
% static const struct usb_device_id urtw_devs[] = {
% URTW_DEV_L(REALTEK, RTL8187),
% ..
% static const struct usb_config urtw_8187b_usbconfig[URTW_8187B_N_XFERS] = {
% [URTW_8187B_BULK_RX] = {
% .type = UE_BULK,
% .endpoint = 0x83,
% ..
% static const struct usb_config urtw_8187l_usbconfig[URTW_8187L_N_XFERS] = {
% [URTW_8187L_BULK_RX] = {
% .type = UE_BULK,
% .endpoint = 0x81,
It occurs to me that yours might actually be a B chip not a L,
because there is a 0x83 endpoint but none for 0x81.
Wanna give that a shot?
Index: if_urtw.c
===
--- if_urtw.c (revision 222807)
+++ if_urtw.c (working copy)
@@ -112,7 +112,7 @@ static const struct usb_device_id urtw_devs[] = {
URTW_DEV_L(BELKIN, F5D7050E),
URTW_DEV_L(LINKSYS4, WUSB54GCV2),
URTW_DEV_L(NETGEAR, WG111V2),
- URTW_DEV_L(REALTEK, RTL8187),
+ URTW_DEV_B(REALTEK, RTL8187),
URTW_DEV_L(SITECOMEU, WL168V1),
URTW_DEV_L(SURECOM, EP9001G2A),
{ USB_VPI(0x1b75, 0x8187, URTW_REV_RTL8187L) },
bmAttributes = 0x0002 BULK
wMaxPacketSize = 0x0200
bInterval = 0x
bRefresh = 0x
bSynchAddress = 0x
Endpoint 1
bLength = 0x0007
bDescriptorType = 0x0005
bEndpointAddress = 0x0004 OUT
bmAttributes = 0x0002 BULK
wMaxPacketSize = 0x0200
bInterval =
Re: Fatal trap 12: page fault while in kernel mode
On Tuesday, April 26, 2011 17:35:32 Gardner Bell wrote:
On Tue, Apr 26, 2011 at 04:25:26PM +0200, Bernhard Schmidt wrote:
On Tuesday, April 26, 2011 15:15:45 Gardner Bell wrote:
On Tue, Apr 26, 2011 at 4:12 AM, Bernhard Schmidt bschm...@freebsd.org
wrote:
On Tuesday, April 26, 2011 01:09:42 Gardner Bell wrote:
Downloading a torrent with many peers on a toshiba satellite notebook
using an Atheros AR5006 wireless nic caused the following panic. This
is an i386 system running 8.2-STABLE from around April 06.
Can you reproduce that?
So far I've not been able to reproduce this.
Ok. I assume this only happens when loosing the connection and trying
to re-associate. At least that is the only possible scenario I can
think of where a timeout for mgmt frames is involved. Probably we
aren't bumping a refcount correctly or something. Actually that sounds
rather plausible as it panics exactly when trying to access ni which
should, for a station, always point to iv_bss, which can in turn be
free'd almost unconditionally if someone's telling net80211 to
associate to another (or even the same) network. Hmm.. tracing refcount
it is.
Were you running wpa_supplicant at that point? Any messages before
the panic happened?
Yes, I'm running wpa_supplicant with the following settings:
network={
ssid=x
psk=x
}
Other settings for the wireless card I have in rc.conf:
wlans_ath0=wlan0
ifconfig_wlan0=WPA DHCP
ifconfig_wlan0_alias0=inet 192.168.0.12 netmask 0x
The last messages seen on the console before the panic are wlan0:
ieee80211_new_state_locked: pending SCAN - AUTH transition lost
and several UP/DOWN events.
That's what I expected, thanks. I'll try to come up with something.
--
Bernhard
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Fatal trap 12: page fault while in kernel mode
On Tuesday, April 26, 2011 01:09:42 Gardner Bell wrote: Downloading a torrent with many peers on a toshiba satellite notebook using an Atheros AR5006 wireless nic caused the following panic. This is an i386 system running 8.2-STABLE from around April 06. Can you reproduce that? A comment about the relevant code says: /* * XXX what happens if !acked but response shows up before callback? */ Guess we now know.. ;) -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Fatal trap 12: page fault while in kernel mode
On Tuesday, April 26, 2011 15:15:45 Gardner Bell wrote: On Tue, Apr 26, 2011 at 4:12 AM, Bernhard Schmidt bschm...@freebsd.org wrote: On Tuesday, April 26, 2011 01:09:42 Gardner Bell wrote: Downloading a torrent with many peers on a toshiba satellite notebook using an Atheros AR5006 wireless nic caused the following panic. This is an i386 system running 8.2-STABLE from around April 06. Can you reproduce that? So far I've not been able to reproduce this. Ok. I assume this only happens when loosing the connection and trying to re-associate. At least that is the only possible scenario I can think of where a timeout for mgmt frames is involved. Probably we aren't bumping a refcount correctly or something. Actually that sounds rather plausible as it panics exactly when trying to access ni which should, for a station, always point to iv_bss, which can in turn be free'd almost unconditionally if someone's telling net80211 to associate to another (or even the same) network. Hmm.. tracing refcount it is. Were you running wpa_supplicant at that point? Any messages before the panic happened? -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: urtw0: could not allocate USB transfers
On Friday 25 February 2011 21:53:54 joseph wrote: Thanks for your fast answers! I tryed your suggestions but only the urtw driver shows interrest in my usb wlan device. The patched urtw still gives the same error massage. Could a update to 8.2 fix this issue? Possibly, worth a try. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: urtw0: could not allocate USB transfers
On Thursday, February 24, 2011 21:51:23 joseph wrote:
Hello,
i decided to get my laptop wlan via usb because my internal device isn't
supported yet.
The usb device is a logilink WL0006 unit its vendorid is 0x0bda and the
productid says 0x8187.
My search results say that this device depends on a RTL8187 chipset.
I tried both, load the kernel module at boot time and compile kernel
withe urtw, but i get the same output at dmesg
device_attach: urtw0 attach returned 6
urtw0: vendor 0x0bda product 0x8187, class 0/0, rev 2.00/2.00, addr 2
on usbus3
urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
device_attach: urtw0 attach returned 6
im running FreeBSD 8.1-RELEASE-p2 amd64.
What might be the reason for this error?
Thanks for all hints.
Well, I have no clue about USB.. but this smells like one of the
endpoints is 'not there'. At least I can't find any reference to
it in the Linux driver. Wanna give attached patch a shot?
--
Bernhard
Index: if_urtw.c
===
--- if_urtw.c (revision 218938)
+++ if_urtw.c (working copy)
@@ -633,19 +635,6 @@ static const struct usb_config urtw_8187l_usbconfi
.callback = urtw_bulk_tx_callback,
.timeout = URTW_DATA_TIMEOUT
},
- [URTW_8187L_BULK_TX_NORMAL] = {
- .type = UE_BULK,
- .endpoint = 0x3,
- .direction = UE_DIR_OUT,
- .bufsize = URTW_TX_MAXSIZE,
- .flags = {
- .ext_buffer = 1,
- .force_short_xfer = 1,
- .pipe_bof = 1,
- },
- .callback = urtw_bulk_tx_callback,
- .timeout = URTW_DATA_TIMEOUT
- },
};
static struct ieee80211vap *urtw_vap_create(struct ieee80211com *,
@@ -1813,9 +1802,7 @@ urtw_tx_start(struct urtw_softc *sc, struct ieee80
break;
}
} else
- xfer = (prior == URTW_PRIORITY_LOW) ?
- sc-sc_xfer[URTW_8187L_BULK_TX_LOW] :
- sc-sc_xfer[URTW_8187L_BULK_TX_NORMAL];
+ xfer = sc-sc_xfer[URTW_8187L_BULK_TX_LOW];
STAILQ_INSERT_TAIL(sc-sc_tx_pending, data, next);
usbd_transfer_start(xfer);
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: urtw0: could not allocate USB transfers
On Friday, February 25, 2011 11:03:04 Etienne Robillard wrote: On 25/02/11 04:11 AM, Bernhard Schmidt wrote: On Thursday, February 24, 2011 21:51:23 joseph wrote: Hello, i decided to get my laptop wlan via usb because my internal device isn't supported yet. The usb device is a logilink WL0006 unit its vendorid is 0x0bda and the productid says 0x8187. My search results say that this device depends on a RTL8187 chipset. I tried both, load the kernel module at boot time and compile kernel withe urtw, but i get the same output at dmesg device_attach: urtw0 attach returned 6 urtw0: vendor 0x0bda product 0x8187, class 0/0, rev 2.00/2.00, addr 2 on usbus3 urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE device_attach: urtw0 attach returned 6 im running FreeBSD 8.1-RELEASE-p2 amd64. What might be the reason for this error? Thanks for all hints. Well, I have no clue about USB.. but this smells like one of the endpoints is 'not there'. At least I can't find any reference to it in the Linux driver. Wanna give attached patch a shot? Hi Bernard, For rt287x based cards, you can try using rt28700 chipset instead of urtw0 on FreeBSD 8. The former is not in the stable src tree, but could be retrieved from here: https://gthc.org/distfiles/freebsd/rt2870_fbsd8.tar.gz Any takers to make module rt28700 (if_rt2870) officially part of the FreeBSD src tree? I'm a bit confused now, shouldn't the rt2870 be supported by run(4)? On a site-note, this is Ralink chipset not a Realtek one. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: urtw0: could not allocate USB transfers
On Friday, February 25, 2011 12:47:12 Etienne Robillard wrote: On 25/02/11 06:18 AM, Bernhard Schmidt wrote: On Friday, February 25, 2011 11:03:04 Etienne Robillard wrote: On 25/02/11 04:11 AM, Bernhard Schmidt wrote: On Thursday, February 24, 2011 21:51:23 joseph wrote: Hello, i decided to get my laptop wlan via usb because my internal device isn't supported yet. The usb device is a logilink WL0006 unit its vendorid is 0x0bda and the productid says 0x8187. My search results say that this device depends on a RTL8187 chipset. I tried both, load the kernel module at boot time and compile kernel withe urtw, but i get the same output at dmesg device_attach: urtw0 attach returned 6 urtw0: vendor 0x0bda product 0x8187, class 0/0, rev 2.00/2.00, addr 2 on usbus3 urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE device_attach: urtw0 attach returned 6 im running FreeBSD 8.1-RELEASE-p2 amd64. What might be the reason for this error? Thanks for all hints. Well, I have no clue about USB.. but this smells like one of the endpoints is 'not there'. At least I can't find any reference to it in the Linux driver. Wanna give attached patch a shot? Hi Bernard, For rt287x based cards, you can try using rt28700 chipset instead of urtw0 on FreeBSD 8. The former is not in the stable src tree, but could be retrieved from here: https://gthc.org/distfiles/freebsd/rt2870_fbsd8.tar.gz Any takers to make module rt28700 (if_rt2870) officially part of the FreeBSD src tree? I'm a bit confused now, shouldn't the rt2870 be supported by run(4)? On a site-note, this is Ralink chipset not a Realtek one. I believe this is a different implementation for RT8187 usb network adapters than run(4). However in my view I found urtw0 buggy, but would certainly take a look at run(4) to compare the results with wireless networking agaisnt the other driver (rt28700). Yeah, urtw(4) has a few flaws.. - urtw(4): Realtek RTL8187B/RTL8187L - rum(4): Ralink RT2501/RT2601 - run(4): Ralink RT2700/RT2800/RT3000 So it seems the driver you've posted conflicts with run(4). From a quick glance at it, it seems to support 11n? If so, can I talk you into working on getting those bits merged? Thanks! -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: link aggregation - bundling 2 lagg interfaces together
On Friday 04 February 2011 13:13:52 Damien Fleuriot wrote: Hello list, I have a firewall with 2x Intel pro dual port cards. On Intel A , port 1 goes to switch 1, port 2 goes to switch 2 On Intel B , port 1 goes to switch 1, port 2 goes to switch 2 I have created the following 2 lagg devices using LACP: lagg0 = A1 + B1 lagg1 = A2 + B2 This works fine. Now, what I had in mind was creating a lagg2 device using lagg0 and lagg1 with failover. That would provide redundancy in case of a switch failure. ifconfig won't let me though: # ifconfig lagg2 laggproto failover laggport lagg0 laggport lagg1 ifconfig: SIOCSLAGGPORT: Invalid argument I suppose it's not possible to aggregate lagg interfaces ? That would shatter my dreams :( I have no clue if that is at all possible, or makes any sense at all, but can't you just add all 4 ports one lagg interface? -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Error produced by static ip setting: ifconfig: inet: bad value
On Monday, January 31, 2011 13:57:29 Yue Wu wrote: List, Hi. I use following setting for my wireless networking enviroment: ifconfig_wlan0=mode 11g bssid my:bssid wepmode on weptxkey 1 wepkey 1:0x11 DHCP But I don't like DHCP and want to use static ip, so I tried: ifconfig_wlan0=mode 11g bssid my:bssid wepmode on weptxkey 1 wepkey 1:0x11 inet 192.168.1.144 netmask 255.255.255.0 But the setting makes BSD networking not working anymore, and when the system starts up, there's an error message: ifconfig: inet: bad value What's wrong? How to use static ip in my wireless networking? Remove the 'inet', it isn't required. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Regression with iwn drivers (4965BGN) in 8.2-PRERELEASE ?
On Thursday, January 06, 2011 10:02:54 Olivier Cochard-Labbé wrote: Hi all, Since I've upgraded from 8.1 to 8.2RC, my wireless negotiated speed is very very slow (more exactly it start at normal speed, but decrease each second still stopping a 1Mbps and became unusuable). I'm using iwn drivers: iwn0: Intel(R) PRO/Wireless 4965BGN mem 0xf6cfe000-0xf6cf irq 17 at device 0.0 on pci12 iwn0: MIMO 2T3R, MoW2, address 00:1d:e0:72:10:01 iwn0: [ITHREAD] iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps [r...@d630]~#uname -a FreeBSD d630.bsdrp.net 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #1: Sun Jan 2 01:32:14 CET 2011 r...@d630.bsdrp.net:/usr/obj/usr/src/sys/GENERIC amd64 Does anybody else meet the same problem ? Haven't seen this yet. What do you mean with 'unusable' exactly? Lots of packet loss, or just slow transfer rates? 'wlandebug +rate' might shed some light on this one. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Regression with iwn drivers (4965BGN) in 8.2-PRERELEASE ?
On Thursday, January 06, 2011 11:23:44 Olivier Cochard-Labbé wrote: 2011/1/6 Bernhard Schmidt bschm...@freebsd.org: What do you mean with 'unusable' exactly? Lots of packet loss, or just slow transfer rates? 'wlandebug +rate' might shed some light on this one. Hi, it's just very slow transfer rates. I didn't know wlandebug, thanks for the tips. Here are the result just after a boot, during pinging my gateway (few traffic): Jan 6 11:02:25 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR increasing rate 48 (txcnt=11 retrycnt=0) Jan 6 11:02:36 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR increasing rate 72 (txcnt=11 retrycnt=0) Jan 6 11:03:02 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR increasing rate 96 (txcnt=11 retrycnt=0) Now, I start xorg and a start a browser: Jan 6 11:04:04 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR decreasing rate 72 (txcnt=11 retrycnt=10) [..] Jan 6 11:11:09 d630 kernel: wlan0: [3a:41:c4:e3:1e:18] AMRR decreasing rate 4 (txcnt=11 retrycnt=4) The rate decrease too much for using a browser (but I can still ping my gateway)… That looks indeed quite weird. I'll have a look into that. Can you post 'ifconfig wlan0 list scan' output, just to see how staffed the band is? -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: if_wpi crashes when renewing in FreeBSD 8 all versions
On Tuesday 23 November 2010 22:03:22 Zhihao Yuan wrote: My laptop is a HP Compaq nc8430, and the wireless card is Intel 3945ABG, with if_wpi driver. wpi0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 00:1b:77:31:1d:74 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier I can use the wireless correctly when I start the system. But after some time (depends on your wireless router renewing settings), it can not renew the DHCP settings. And, if you try to renew it with sudo /etc/rc.d/netif restart for like more than 2 times, the whole system will crash. The interesting thing is, the renewing problem only occurs on the wireless network with a WPA2 protocol. For the WEP or None-keys network, there is no problem. For the WPA-EAP network, you can redo the DHCP but not /etc/rc.d/netif restart. That is a known issue, there is race in our devd/rc-subsystems and especially the way wpa_supplicant get exclusive access to the interface. This leads to all kind of funny results, panics being one of it. I have patches to address the panics but this does not fix the initial issue which is that wpa_supplicant gets started twice. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Can't use wireless networking after upgrade the world recently
On Saturday 13 November 2010 08:32:05 Yue Wu wrote: Hi list, As the title, my settings for wireless networking worked fine before upgrade to the yesterday stable src, don't know why now it doesn't work anymore. I've attached the startup's log, loader.conf, rc.conf, and output of ifconfig(trancated useless parts of them as needed). any info is needed? plz let me know. Sorry for my poor English, plz let me know if I didn't describe clearly. Can you try that with the wlan_amrr module loaded? Adding it to loader.conf should be sufficient. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Intel PRO/Wireless 6050 in 8.1-RELEASE Problems
On Friday, October 29, 2010 10:32:52 m...@kmwhite.net wrote: I've installed FreeBSD 8.1-RELEASE on a Dell Latitude E6410. Most hardware works just fine, but I'm having a hell of a time with the wifi. Everytime I try to associate with an access point, my terminal replies with: [..] iwn6050fw_load=YES [..] iwn0: Intel(R) PRO/Wireless 6050 mem 0xe6e0-0xe6e01fff irq 17 at [..] iwn0: iwn_hw_init: timeout waiting for adapter to initialize, error 35 iwn0: iwn_init_locked: could not initialize hardware, error 35 iwn0: iwn_hw_init: timeout waiting for adapter to initialize, error 35 iwn0: iwn_init_locked: could not initialize hardware, error 35 I know that that error has to be part of the problem. I just don't know what to do next, and haven't been able to find any help further. Any ideas? Additionally, any thing I forgot to add, please let me know. The messages indicate that you are using 8.1-RELEASE, but afaik 8.1 does not have the 6050 firmware module, did you get that from stable? If you're able to try stable/8, please do so, there have been a few additions/fixes regarding 6000 series chips which are not in 8.1-RELEASE. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: wpa_supplicant does not create pidfile
On Tuesday, September 07, 2010 09:18:42 Bernhard Schmidt wrote: On Tuesday, September 07, 2010 09:14:00 Dominic Fandrey wrote: On 07/09/2010 09:09, Bernhard Schmidt wrote: On Tuesday, September 07, 2010 09:01:18 Dominic Fandrey wrote: On 07/09/2010 08:50, Bernhard Schmidt wrote: On Friday, August 27, 2010 09:42:30 Bernhard Schmidt wrote: On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey kamik...@bsdforen.de wrote: On 27/08/2010 09:28, Bernhard Schmidt wrote: On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey kamik...@bsdforen.de wrote: wpa_supplicant doesn't create the pidfile if the target directory does not exist. Because /var/run is wiped with every boot I added the following line to my rc.local to workaround this issue: /bin/mkdir -p /var/run/wpa_supplicant I'm running RELENG_8. How about this? Index: etc/mtree/BSD.var.dist == = --- etc/mtree/BSD.var.dist.(revision 211568) +++ etc/mtree/BSD.var.dist.(working copy) @@ -64,6 +64,8 @@ .. ppp gname=network mode=0770 .. +wpa_supplicant +.. .. rwhogname=daemon mode=0775 .. I committed this change, as it seems to the correct solution. Is the mtree built every time the system boots? Because my /var/run is a tmpfs. And even if it wasn't, I think it's wiped every boot any way. Not build but, according to /etc/rc.d/var mtree is run on every boot. I actually tried that and it works just fine. Did you have a chance to try this? Given positive feedback I'd like to commit it. No, doesn't work. The named and ppp directories also don't exist. Sorry about the delay. Ok, thanks. Is it only /var/run/* that is wiped for you, or /var/* itself? I just checked rc.d/var and it looks like this: if [ -d /var/run -a -d /var/db -a -d /var/empty ] ; then true elif [ -x /usr/sbin/mtree ] ; then populate_var So.. if var/run does exist, populate_var isn't run. Only /var/run and /var/log are tmpfs (notebook, reduce HD access to allow HD spindown). I wouldn't wipe my /var/db every boot. Ah, ok, that explains it. Try with populate_var=YES in rc.conf and it should create all directories under var/run. Were you able to give this a shot? -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: wpa_supplicant does not create pidfile
On Friday, August 27, 2010 09:42:30 Bernhard Schmidt wrote: On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey kamik...@bsdforen.de wrote: On 27/08/2010 09:28, Bernhard Schmidt wrote: On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey kamik...@bsdforen.de wrote: wpa_supplicant doesn't create the pidfile if the target directory does not exist. Because /var/run is wiped with every boot I added the following line to my rc.local to workaround this issue: /bin/mkdir -p /var/run/wpa_supplicant I'm running RELENG_8. How about this? Index: etc/mtree/BSD.var.dist === --- etc/mtree/BSD.var.dist.(revision 211568) +++ etc/mtree/BSD.var.dist.(working copy) @@ -64,6 +64,8 @@ .. ppp gname=network mode=0770 .. +wpa_supplicant +.. .. rwhogname=daemon mode=0775 .. Is the mtree built every time the system boots? Because my /var/run is a tmpfs. And even if it wasn't, I think it's wiped every boot any way. Not build but, according to /etc/rc.d/var mtree is run on every boot. I actually tried that and it works just fine. Did you have a chance to try this? Given positive feedback I'd like to commit it. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: wpa_supplicant does not create pidfile
On Tuesday, September 07, 2010 09:01:18 Dominic Fandrey wrote: On 07/09/2010 08:50, Bernhard Schmidt wrote: On Friday, August 27, 2010 09:42:30 Bernhard Schmidt wrote: On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey kamik...@bsdforen.de wrote: On 27/08/2010 09:28, Bernhard Schmidt wrote: On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey kamik...@bsdforen.de wrote: wpa_supplicant doesn't create the pidfile if the target directory does not exist. Because /var/run is wiped with every boot I added the following line to my rc.local to workaround this issue: /bin/mkdir -p /var/run/wpa_supplicant I'm running RELENG_8. How about this? Index: etc/mtree/BSD.var.dist === --- etc/mtree/BSD.var.dist.(revision 211568) +++ etc/mtree/BSD.var.dist.(working copy) @@ -64,6 +64,8 @@ .. ppp gname=network mode=0770 .. +wpa_supplicant +.. .. rwhogname=daemon mode=0775 .. Is the mtree built every time the system boots? Because my /var/run is a tmpfs. And even if it wasn't, I think it's wiped every boot any way. Not build but, according to /etc/rc.d/var mtree is run on every boot. I actually tried that and it works just fine. Did you have a chance to try this? Given positive feedback I'd like to commit it. No, doesn't work. The named and ppp directories also don't exist. Sorry about the delay. Ok, thanks. Is it only /var/run/* that is wiped for you, or /var/* itself? I just checked rc.d/var and it looks like this: if [ -d /var/run -a -d /var/db -a -d /var/empty ] ; then true elif [ -x /usr/sbin/mtree ] ; then populate_var So.. if var/run does exist, populate_var isn't run. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: wpa_supplicant does not create pidfile
On Tuesday, September 07, 2010 09:14:00 Dominic Fandrey wrote: On 07/09/2010 09:09, Bernhard Schmidt wrote: On Tuesday, September 07, 2010 09:01:18 Dominic Fandrey wrote: On 07/09/2010 08:50, Bernhard Schmidt wrote: On Friday, August 27, 2010 09:42:30 Bernhard Schmidt wrote: On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey kamik...@bsdforen.de wrote: On 27/08/2010 09:28, Bernhard Schmidt wrote: On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey kamik...@bsdforen.de wrote: wpa_supplicant doesn't create the pidfile if the target directory does not exist. Because /var/run is wiped with every boot I added the following line to my rc.local to workaround this issue: /bin/mkdir -p /var/run/wpa_supplicant I'm running RELENG_8. How about this? Index: etc/mtree/BSD.var.dist === --- etc/mtree/BSD.var.dist.(revision 211568) +++ etc/mtree/BSD.var.dist.(working copy) @@ -64,6 +64,8 @@ .. ppp gname=network mode=0770 .. +wpa_supplicant +.. .. rwhogname=daemon mode=0775 .. Is the mtree built every time the system boots? Because my /var/run is a tmpfs. And even if it wasn't, I think it's wiped every boot any way. Not build but, according to /etc/rc.d/var mtree is run on every boot. I actually tried that and it works just fine. Did you have a chance to try this? Given positive feedback I'd like to commit it. No, doesn't work. The named and ppp directories also don't exist. Sorry about the delay. Ok, thanks. Is it only /var/run/* that is wiped for you, or /var/* itself? I just checked rc.d/var and it looks like this: if [ -d /var/run -a -d /var/db -a -d /var/empty ] ; then true elif [ -x /usr/sbin/mtree ] ; then populate_var So.. if var/run does exist, populate_var isn't run. Only /var/run and /var/log are tmpfs (notebook, reduce HD access to allow HD spindown). I wouldn't wipe my /var/db every boot. Ah, ok, that explains it. Try with populate_var=YES in rc.conf and it should create all directories under var/run. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: wpa_supplicant does not create pidfile
On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey kamik...@bsdforen.de wrote: On 27/08/2010 09:28, Bernhard Schmidt wrote: On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey kamik...@bsdforen.de wrote: wpa_supplicant doesn't create the pidfile if the target directory does not exist. Because /var/run is wiped with every boot I added the following line to my rc.local to workaround this issue: /bin/mkdir -p /var/run/wpa_supplicant I'm running RELENG_8. How about this? Index: etc/mtree/BSD.var.dist === --- etc/mtree/BSD.var.dist.(revision 211568) +++ etc/mtree/BSD.var.dist.(working copy) @@ -64,6 +64,8 @@ .. ppp gname=network mode=0770 .. + wpa_supplicant + .. .. rwho gname=daemon mode=0775 .. Is the mtree built every time the system boots? Because my /var/run is a tmpfs. And even if it wasn't, I think it's wiped every boot any way. Not build but, according to /etc/rc.d/var mtree is run on every boot. I actually tried that and it works just fine. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: wpa_supplicant does not create pidfile
On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey kamik...@bsdforen.de wrote: wpa_supplicant doesn't create the pidfile if the target directory does not exist. Because /var/run is wiped with every boot I added the following line to my rc.local to workaround this issue: /bin/mkdir -p /var/run/wpa_supplicant I'm running RELENG_8. How about this? Index: etc/mtree/BSD.var.dist === --- etc/mtree/BSD.var.dist.(revision 211568) +++ etc/mtree/BSD.var.dist.(working copy) @@ -64,6 +64,8 @@ .. ppp gname=network mode=0770 .. +wpa_supplicant +.. .. rwhogname=daemon mode=0775 .. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: iwn firmware instability with an up-to-date stable kernel
On Sat, Apr 24, 2010 at 06:24:42PM -0700, Garrett Cooper wrote:
On Sat, Apr 24, 2010 at 12:50 AM, Bernhard Schmidt
bschm...@techwires.net wrote:
On Sat, Apr 24, 2010 at 12:45:14AM -0700, Garrett Cooper wrote:
On Sat, Apr 24, 2010 at 12:34 AM, Bernhard Schmidt
bschm...@techwires.net wrote:
How did you do that? Reloading the module, or with ifconfig?
/etc/rc.d/netif restart , which does the ifconfig operations (no
module change occurred AFAIK, but wlan0 did of course do some
device_printf's when it was associating itself with iwn(4)).
Can you do ps xa | grep wpa? Just wondering if wpa_supplicant gets
started twice.
Some more interesting data.
Open authentication at home works out of the box via wpa_supplicant
with ifconfig_wlan0=WPA DHCP whereas it flaked out and died at work.
There are two instances of wpa_supplicant started up on the laptop.
Here's a snippet from pstree that shows that both processes are
standalone:
-+= 1 root /sbin/init --
|--= 00121 root adjkerntz -i
|--= 00559 root /sbin/devd
|--= 00711 root /usr/sbin/syslogd -s
|--= 00735 root /usr/sbin/rpcbind
|--= 00879 root /usr/sbin/moused -p /dev/psm0 -t auto
|--= 00903 messagebus /usr/local/bin/dbus-daemon --system
|--= 01073 root /usr/sbin/sshd
|--= 01081 root sendmail: accepting connections (sendmail)
|--= 01085 smmsp sendmail: Queue run...@00:30:00 for
/var/spool/clientmqueue (sendmail)
|--= 01093 root /usr/sbin/cron -s
|-+= 01176 haldaemon /usr/local/sbin/hald
| \-+- 01180 root hald-runner
| |--- 01185 root hald-addon-mouse-sysmouse: /dev/psm0
(hald-addon-mouse-sy)
| \--- 01205 root hald-addon-storage: /dev/acd0 (hald-addon-storage)
|--= 01179 root /usr/local/sbin/console-kit-daemon
|--= 01727 root /usr/sbin/wpa_supplicant -s -B -i wlan0 -c
/etc/wpa_supplicant.conf -D bsd -P /var/run/wpa_supplicant/wlan0.pid
|--= 01783 root /usr/sbin/wpa_supplicant -s -B -i wlan0 -c
/etc/wpa_supplicant.conf -D bsd -P /var/run/wpa_supplicant/wlan0.pid
|--= 01866 root dhclient: wlan0 [priv] (dhclient)
|--= 01902 _dhcp dhclient: wlan0 (dhclient)
Indeed, devd is responsible for that, removing
notify 0 {
match system IFNET;
match typeATTACH;
action /etc/pccard_ether $subsystem start;
};
from devd.conf prevents a seconds call to rc.d/netif and therefore
rc.d/wpa_supplicant. This breaks the intended purpose though.
Can we somehow prevent this by checking the pidfile in
rc.d/wpa_supplicant?
--
Bernhard
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: iwn firmware instability with an up-to-date stable kernel
On Fri, Apr 23, 2010 at 11:27:32PM -0700, Garrett Cooper wrote: On Fri, Apr 23, 2010 at 10:08 PM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Sat, Apr 24, 2010 at 4:59 AM, Garrett Cooper yanef...@gmail.com wrote: On Fri, Apr 23, 2010 at 9:42 PM, Garrett Cooper yanef...@gmail.com wrote: On Fri, Apr 23, 2010 at 8:05 PM, Brandon Gooch jamesbrandongo...@gmail.com wrote: 2010/4/23 Garrett Cooper yanef...@gmail.com: 2010/4/23 Garrett Cooper yanef...@gmail.com: 2010/4/18 Olivier Cochard-Labbé oliv...@cochard.me: 2010/4/18 Bernhard Schmidt bschm...@techwires.net: Are you able to reproduce this on demand? As in type a few commands and the firmware error occurs? No, I'm not able to reproduce on demand this problem. I'm seeing similar issues on occasion with my Lenovo as well: Apr 23 19:25:24 garrcoop-fbsd kernel: firmware error log: Apr 23 19:25:24 garrcoop-fbsd kernel: error type = NMI_INTERRUPT_WDG (0x0004) Apr 23 19:25:24 garrcoop-fbsd kernel: program counter = 0x046C Apr 23 19:25:24 garrcoop-fbsd kernel: source line = 0x00D0 Apr 23 19:25:24 garrcoop-fbsd kernel: error data = 0x00020703 Apr 23 19:25:24 garrcoop-fbsd kernel: branch link = 0x837004C2 Apr 23 19:25:24 garrcoop-fbsd kernel: interrupt link = 0x06DA18B8 Apr 23 19:25:24 garrcoop-fbsd kernel: time = 4287402440 Apr 23 19:25:24 garrcoop-fbsd kernel: driver status: Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 0: qid=0 cur=1 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 1: qid=1 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 2: qid=2 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 3: qid=3 cur=36 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 4: qid=4 cur=123 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 5: qid=5 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 6: qid=6 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 7: qid=7 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 8: qid=8 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 9: qid=9 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 10: qid=10 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 11: qid=11 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 12: qid=12 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 13: qid=13 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 14: qid=14 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 15: qid=15 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: rx ring: cur=8 This may be because the system was under load (I was installing a port shortly before the connection dropped). I'll try poking at this further because it's going to be an annoying productivity loss :/. Sorry... should have included more helpful details. Thanks, -Garrett dmesg: iwn0: Intel(R) PRO/Wireless 4965BGN mem 0xdf2fe000-0xdf2f irq 17 at device 0.0 on pci3 iwn0: MIMO 2T3R, MoW1, address 00:1d:e0:7d:9f:c7 iwn0: [ITHREAD] iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps pciconf -lv snippet: i...@pci0:3:0:0: class=0x028000 card=0x11108086 chip=0x42308086 rev=0x61 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Wireless WiFi Link 4965AGN (Intel 4965AGN)' class = network c...@pci0:21:0:0: class=0x060700 card=0x20c617aa chip=0x04761180 rev=0xba hdr=0x02 uname -a: $ uname -a FreeBSD garrcoop-fbsd.cisco.com 8.0-STABLE FreeBSD 8.0-STABLE #0 r207006: Wed Apr 21 13:18:44 PDT 2010 r...@garrcoop-fbsd.cisco.com:/usr/obj/usr/src/sys/LAPPY_X86 i386 I'm actually looking at this right now. For me, it's actually happening when my machine stays on overnight (or for long periods of time, idle). Also, it seems to be causing the kernel to panic, although I'm now wondering if the Machine Check Architecture is somehow catching this device error and causing an exception (hw.mca.enabled=1)(?) -- not possible, right ??? Whatever the case, I can't seem to get the firmware error to occur with iwn(4) debugging or wlandebug options enabled, so who knows exactly what leads to this. I know Bernhard has worked hard on this driver, it's a shame that this freaky bug has bit us all now, without leaving many clues :( I've attached a textdump for posterity if nothing else :) Connectivity appears to be shoddy in my neck of the woods (kind of ironic... but meh). Just running buildworld, buildkernel, then doing a tcpdump in parallel causes the pseudo device to go up and down
Re: iwn firmware instability with an up-to-date stable kernel
On Sat, Apr 24, 2010 at 12:45:14AM -0700, Garrett Cooper wrote: On Sat, Apr 24, 2010 at 12:34 AM, Bernhard Schmidt bschm...@techwires.net wrote: On Fri, Apr 23, 2010 at 11:27:32PM -0700, Garrett Cooper wrote: On Fri, Apr 23, 2010 at 10:08 PM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Sat, Apr 24, 2010 at 4:59 AM, Garrett Cooper yanef...@gmail.com wrote: On Fri, Apr 23, 2010 at 9:42 PM, Garrett Cooper yanef...@gmail.com wrote: On Fri, Apr 23, 2010 at 8:05 PM, Brandon Gooch jamesbrandongo...@gmail.com wrote: 2010/4/23 Garrett Cooper yanef...@gmail.com: 2010/4/23 Garrett Cooper yanef...@gmail.com: 2010/4/18 Olivier Cochard-Labbé oliv...@cochard.me: 2010/4/18 Bernhard Schmidt bschm...@techwires.net: Are you able to reproduce this on demand? As in type a few commands and the firmware error occurs? No, I'm not able to reproduce on demand this problem. I'm seeing similar issues on occasion with my Lenovo as well: Apr 23 19:25:24 garrcoop-fbsd kernel: firmware error log: Apr 23 19:25:24 garrcoop-fbsd kernel: error type = NMI_INTERRUPT_WDG (0x0004) Apr 23 19:25:24 garrcoop-fbsd kernel: program counter = 0x046C Apr 23 19:25:24 garrcoop-fbsd kernel: source line = 0x00D0 Apr 23 19:25:24 garrcoop-fbsd kernel: error data = 0x00020703 Apr 23 19:25:24 garrcoop-fbsd kernel: branch link = 0x837004C2 Apr 23 19:25:24 garrcoop-fbsd kernel: interrupt link = 0x06DA18B8 Apr 23 19:25:24 garrcoop-fbsd kernel: time = 4287402440 Apr 23 19:25:24 garrcoop-fbsd kernel: driver status: Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 0: qid=0 cur=1 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 1: qid=1 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 2: qid=2 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 3: qid=3 cur=36 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 4: qid=4 cur=123 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 5: qid=5 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 6: qid=6 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 7: qid=7 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 8: qid=8 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 9: qid=9 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 10: qid=10 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 11: qid=11 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 12: qid=12 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 13: qid=13 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 14: qid=14 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 15: qid=15 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: rx ring: cur=8 This may be because the system was under load (I was installing a port shortly before the connection dropped). I'll try poking at this further because it's going to be an annoying productivity loss :/. Sorry... should have included more helpful details. Thanks, -Garrett dmesg: iwn0: Intel(R) PRO/Wireless 4965BGN mem 0xdf2fe000-0xdf2f irq 17 at device 0.0 on pci3 iwn0: MIMO 2T3R, MoW1, address 00:1d:e0:7d:9f:c7 iwn0: [ITHREAD] iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps pciconf -lv snippet: i...@pci0:3:0:0: class=0x028000 card=0x11108086 chip=0x42308086 rev=0x61 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Wireless WiFi Link 4965AGN (Intel 4965AGN)' class = network c...@pci0:21:0:0: class=0x060700 card=0x20c617aa chip=0x04761180 rev=0xba hdr=0x02 uname -a: $ uname -a FreeBSD garrcoop-fbsd.cisco.com 8.0-STABLE FreeBSD 8.0-STABLE #0 r207006: Wed Apr 21 13:18:44 PDT 2010 r...@garrcoop-fbsd.cisco.com:/usr/obj/usr/src/sys/LAPPY_X86 i386 I'm actually looking at this right now. For me, it's actually happening when my machine stays on overnight (or for long periods of time, idle). Also, it seems to be causing the kernel to panic, although I'm now wondering if the Machine Check Architecture is somehow catching this device error and causing an exception (hw.mca.enabled=1)(?) -- not possible, right ??? Whatever the case, I can't seem to get the firmware error to occur with iwn(4) debugging or wlandebug options enabled, so who knows exactly what leads to this. I know Bernhard has worked hard on this driver, it's a shame that this freaky bug has bit us all now, without
Re: iwn firmware instability with an up-to-date stable kernel
On Sun, Apr 18, 2010 at 03:49:14AM +0200, Olivier Cochard-Labbé wrote: Hi, I meet instability with an up-to-date stable 8 kernel and iwn drivers: About twice a day, my wireless connection hang and I've this error message in dmesg: firmware error log: error type = NMI_INTERRUPT_WDG (0x0004) program counter = 0x046C source line = 0x00D0 [..] Does anyone meet the same problem ? I've seen this error a few times, even Intel knows about it: http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1965 Issue is that there is no known workaround. Are you able to reproduce this on demand? As in type a few commands and the firmware error occurs? -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD-8.0 802.11n support with ath/mwl
On Sun, Feb 28, 2010 at 12:38:19PM -0500, Jim Pingle wrote: On 2/28/2010 7:54 AM, Rui Paulo wrote: On 28 Feb 2010, at 03:22, Jim Pingle wrote: Are you aware if similar work ongoing for the mwl(4) based 802.11n cards? I picked up a couple cheap this past week and have them working with hostapd but, as with the OP in the thread, only with G rates. The ifconfig[1] output suggests that it is using 40MHz wide ht channels but devices only associate at 54Mbps[2]. Jim [1] ifconfig mwl0_wlan1 mwl0_wlan1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:01:36:17:96:0e inet6 fe80::201:36ff:fe17:960e%mwl0_wlan1 prefixlen 64 scopeid 0x9 inet 192.168.15.1 netmask 0xff00 broadcast 192.168.15.255 nd6 options=3PERFORMNUD,ACCEPT_RTADV media: IEEE 802.11 Wireless Ethernet autoselect mode 11na hostap status: running ssid WatchTower channel 100 (5500 MHz 11a ht/40+) bssid 00:01:36:17:96:0e regdomain DEBUG indoor authmode WPA2/802.11i privacy MIXED deftxkey 3 AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 14 scanvalid 60 ampdulimit 64k ampdudensity 4 shortgi smps burst dtimperiod 1 [2] ifconfig mwl0_wlan1 list sta (w/addr removed) AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 1 120 54M 33.00 1537 25952 EP A RSN (rssi 68:20:20 nf 0:0:0) mwl supports HT rates, but it looks like your AP is not sending HT rates to you. Thanks for the quick clarification, that's very encouraging to find out! In this case, the mwl card is the AP. The client line is from an associated Windows 7 laptop with an Intel 5100abgn card which does show the AP as 802.11n in the AP list. I'm connected and sending this message through it right now, actually. Are there some other bits that need set in order to have clients associate with HT rates? Or some other prerequisite conditions such as number of attached antennae? I do only have one antenna attached as I didn't have a second pigtail for this test unit's case. The card actually has three connectors. I didn't see hints in the mwl(4), wlan(4), hostapd(8), hostapd.conf(5), or ifconfig(8) man pages about troubleshooting rates. I see plenty of talk in ifconfig(8) about use and control of HT rates, but given what I'm seeing in ifconfig, it should be set to use them. I've tried several combinations of channels and standards (e.g. 11ng, 11na) but always end up with a 54Mbps link. I'd appreciate any more pointers that you (or anyone else reading) may have. I'd like to write up something on the topic once I get it fully operational. Did you measure the actual bandwidth you get? Changes are high that you are actually using HT rates, the rate information is just no accurate. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD-8.0 802.11n support with ath
On Sat, Feb 27, 2010 at 01:27:09PM +0100, Spil Oss wrote: Hi All, Got myself an Atheros AR5416 card to upgrade my HostAP to Wireless-N speed. Somehow I can't find a way to convince the driver to go into 11n mode # ifconfig wlan0 mode 11b # ifconfig wlan0 mode 11g # ifconfig wlan0 mode 11n ifconfig: SIOCSIFMEDIA (media): Device not configured It's either mode 11na or mode 11ng. The man-page for ifconfig specifies only 11a, 11b and 11g as modes. The part is functioning fine in 11g mode. Am I missing something obvious or is Wireless-N support not fully implemented yet? There is no rate control algo fuer 11n, afaik, you will only be able to use legacy rates. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: stable/8: iwn5100 , unable to get scan results
On Thu, Feb 25, 2010 at 03:10:21PM +0200, Nezmer wrote: Hi, I'm new to FreeBSD so don't shoot me If I'm missing something obvious. I built and installed stable/8 yesterday to try out the updated iwn driver. But every time I run: ifconfig iwn0 up scan I get: ifconfig: unable to get scan results How can I go about investigating this further? The needed module and firmware are loaded of course. 8.0 and newer use VAPs, you have to do: # kldload if_iwn # ifconfig wlan0 create wlandev iwn0 # ifconfig wlan0 up # ifconfig wlan0 list scan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Intel Wifi Link 1000 - panic
On Sunday 21 February 2010 10:42:41 tech...@callooh.com wrote: today i upgraded to the latest stable from source, and tried to use the iwn driver, but when i `kldload if_iwn`: iwn0 Intel(R) PRO/Wireless 1000 mem 0xfeafe000-0xfeaf irq 17 at device 0.0 on pci2 iwn: MIMO 1T2R, , address 00:00:00:00:00:00 panic: ieee80211_get_ratetable: not rate table for channel; freq 0 flag 0x0 cpuid = 1 ... no matter if i kldload iwn1000fw in advance or not .. is there something i could tweak to get the driver working, or is it just broken ? thanks for any response, reinhard There is a fix for that in head, r203934. I will MFC that in a couple of days. http://svn.freebsd.org/viewvc/base/head/sys/dev/iwn/if_iwn.c?view=patchr1=202986r2=203934pathrev=203934 -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: iwn(4) 5100 - Estimation for MFC of r198429?
On Wednesday 02 December 2009 18:24:58 Roland Smith wrote: On Tue, Dec 01, 2009 at 07:39:37PM -0500, Glen Barber wrote: Hi, I've been using the iwn(4) driver contributed by Bernhard Schmidt with my Intel 5100 AGN card on 8-STABLE since he announced the availability. It was committed to -CURRENT as of r198429. There is no mention of MFC in the commit log. Are there plans to MFC this driver to 8-STABLE for a wider testing base? Hear, hear. I've got a 5100 AGN in a laptop. I'd like to test it as well, without switching to -CURRENT. If I just got the files mentioned in the commit* and add/replace them in my source tree, it looks like it should work. Or am I missing something? Roland * http://svn.freebsd.org/viewvc/base?view=revisionrevision=198429 Yep, that should work, though it is probably better and easier if you use the svn version. It also contains several fixes. Installation instructions: http://forums.freebsd.org/showpost.php?p=47627postcount=16 -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Freebsd 8.0 system freeze
On Wednesday 02 December 2009 17:22:13 Peter Pieczora wrote: Hi, I recently upgraded from 7.2-STABLE to 8.0-RELEASE, and I'm encountering frequent system freezes (hang ups), which end in a reboot. There is no indication of any panic, no messages are generated and no core dump files (sysctl kern.coredump=1). System runs on IBM T43 with intel wireless chipset, iwi modules are loaded during boot via /boot/loader.conf. legal.intel_iwi.license_ack=1 if_iwi_load=YES wlan_load=YES firmware_load=YES iwi_bss_load=YES iwi_ibss_load=YES iwi_monitor_load=YES Typically msg. look something like that or similar (iwi0 line gets repeated twice or 3 times): Dec 1 22:02:12 local kernel: wlan0: link state changed to DOWN Dec 1 22:02:19 local kernel: wlan0: link state changed to UP Dec 1 22:02:19 local kernel: iwi0: need multicast update callback Dec 1 22:02:30 local kernel: wlan0: link state changed to DOWN Dec 1 22:04:14 local syslogd: kernel boot file is /boot/kernel/kernel Is anyone else seeing this? ATM I am at work using bge0 interface and system runs without freezing so far. Could this situation be attributed to iwi driver or maybe wlandev? I've seen something which might be related. Using a iwn(4) device for some time my -CURRENT box locks up completely, no reboot, no panic, no ctrl+alt+esc.. The last message I see is from net80211 sending a power notification wakeup message after returning form a background scan. Still digging around, trying to find the cause. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: samba - SIGABRT
On Wednesday 07 October 2009 20:09:59 Oliver Lehmann wrote: Hi, I wonder what may have caused this and how should I debug it to find the source? I Installed samba 3.3.7 on a clean 8.0-RC1 and I upgraded then my system to the latest RELENG_8. Since I've not the time searching much longer for the error I'll just go to upgrade to 3.3.8 (recompile it...) tomorrow but I'm curious what it may have caused and how I would have been able to find the cause Is by any chance security.bsd.map_at_zero set to 0? If it is http://lists.freebsd.org/pipermail/freebsd-stable/2009-October/052235.html has a solution. r...@nudel samba33 /usr/local/sbin/smbd Abort Exit 134 r...@nudel samba33 gdb 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 i386-marcel-freebsd. (gdb) exec /usr/local/sbin/smbd (gdb) run Starting program: /usr/local/sbin/smbd Program terminated with signal SIGABRT, Aborted. The program no longer exists. You can't do that without a process to debug. (gdb) q r...@nudel samba33 ktrace /usr/local/sbin/smbd Abort Exit 134 r...@nudel samba33 kdump 2605 ktrace RET ktrace 0 2605 ktrace CALL execve(0xbfbfed83,0xbfbfec50,0xbfbfec58) 2605 ktrace NAMI /usr/local/sbin/smbd r...@nudel samba33 mount -t procfs /dev/null /proc r...@nudel samba33 truss -fad /usr/local/sbin/smbd truss: can not get etype: No such process Exit 2 r...@nudel samba33 dmesg | tail -1 fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6 r...@nudel samba33 ldd /usr/local/sbin/smbd /usr/local/sbin/smbd: libcrypt.so.5 = /lib/libcrypt.so.5 (0x281aa000) libpam.so.5 = /usr/lib/libpam.so.5 (0x281c3000) libexecinfo.so.1 = /usr/local/lib/libexecinfo.so.1 (0x281cb000) libiconv.so.3 = /usr/local/lib/libiconv.so.3 (0x288d2000) libpopt.so.0 = /usr/local/lib/libpopt.so.0 (0x281d6000) libc.so.7 = /lib/libc.so.7 (0x28091000) libm.so.5 = /lib/libm.so.5 (0x281df000) libintl.so.8 = /usr/local/lib/libintl.so.8 (0x289d1000) r...@nudel samba33 ls -l /lib/libcrypt.so.5 /usr/lib/libpam.so.5 /usr/local/lib/libexecinfo.so.1 /usr/local/lib/libiconv.so.3 /usr/local/lib/libpopt.so.0 /lib/libc.so.7 /lib/libm.so.5 /usr/local/lib/libintl.so.8 -r--r--r-- 1 root wheel 1144500 Oct 5 16:40 /lib/libc.so.7 -r--r--r-- 1 root wheel32060 Oct 5 16:41 /lib/libcrypt.so.5 -r--r--r-- 1 root wheel 119372 Oct 5 16:41 /lib/libm.so.5 -r--r--r-- 1 root wheel28424 Oct 5 16:42 /usr/lib/libpam.so.5 -r--r--r-- 1 root wheel40636 Oct 4 19:59 /usr/local/lib/libexecinfo.so.1 -r--r--r-- 1 root wheel 1050349 Oct 4 19:41 /usr/local/lib/libiconv.so.3 -r--r--r-- 1 root wheel39876 Oct 4 19:52 /usr/local/lib/libintl.so.8 -rwxr-xr-x 1 root wheel39623 Oct 4 20:00 /usr/local/lib/libpopt.so.0* r...@nudel samba33 ls -l /usr/local/sbin/smbd -rwxr-xr-x 1 root wheel 6698391 Oct 4 20:30 /usr/local/sbin/smbd* r...@nudel samba33 file /usr/local/sbin/smbd /usr/local/sbin/smbd: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.0 (800107), not stripped r...@nudel samba33 -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-BETA3: make WITHOUT_INSTALLLIB=yes buildworld broken
Am 29.08.2009 um 18:22 schrieb Eugene Grosbein: Hi! WITHOUT_INSTALLLIB= knob is documented in src.conf(5) as feature useful for nanobsb build to skip *.a libraries. In 8.0-BETA3, make buildworld breaks in 3 seconds after start when this knob is used: As far as I know, this an option for installworld NOT buildworld. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Compiling world+kernel in RELENG_7 right now | releng_7 tinderbox
Hi, /obj/amd64/src/sys/boot/i386/zfsboot/../btx/lib/crt0.o zfsboot.o sio.o \ /obj/amd64/src/tmp/usr/lib/libstand.a objcopy -S -O binary zfsboot.out zfsboot.bin btxld -v -E 0x2000 -f bin -b /obj/amd64/src/ sys/boot/i386/zfsboot/../btx/btx/btx -l zfsboot.ldr \ -o zfsboot.ld -P 1 zfsboot.bin btxld: zfsboot.ldr: Invalid argument *** Error code 2 Attached diff fixes that issue for me. -- Regards, Bernhard Schmidt btxld.diff Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
