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 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 3:30 PM, Albert Shih 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: vlan+iwn panic
On Mon, Jun 18, 2012 at 12:52 PM, David ROFFIAEN 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: panic with if_iwi(4) upon "netif restart"
On Mon, May 7, 2012 at 5:54 AM, Alexey Dokuchaev 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: at usbus3
>
> after kldload if_urtw.ko:
>
> urtw0:
> on usbus3
> urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
> device_attach: urtw0 attach returned 6
> urtw0:
> on usbus3
> urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
> device_attach: urtw0 attach returned 6
> urtw0:
> on usbus3
> urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
> device_attach: urtw0 attach returned 6
> urtw0:
> 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: 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
> iProduct = 0x0002
> iSerialNumber = 0x
> bNumConfigurations = 0x0001
>
> 3:28:48pm argus(49): usbconfig -u 3 -a 2 dump_curr_config_desc
> ugen3.2: 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
> bmAttributes = 0x0080
> bMaxPower = 0x00fa
>
> Interface 0
> bLength = 0x0009
> bDescriptorType = 0x0004
> bInterfaceNumber = 0x
> bAlternateSetting = 0x
> bNumEndpoints = 0x0009
> bInterfaceClass = 0x00ff
> bInterfaceSubClass = 0x00ff
> bInterfaceProtocol = 0x00ff
> iInterface = 0x0002
>
> Endpoint 0
> bLength = 0x0007
> bDescriptorType = 0x0005
> bEndpointAddress = 0x0083
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
> wMaxPacketSize = 0x0200
> bInterval = 0x
> bRefresh = 0x
> bSynchAddress = 0x
>
> Endpoint 1
> bLength = 0x0007
> bDescriptorType = 0x0005
> bEndpointAddress = 0x0004
> bmAttributes = 0x0002
> wMaxPacketSize = 0x0200
> bInterval = 0x
> bRefresh = 0x
> bSynchAddress = 0x
>
> Endpoint 2
> bLength = 0x0007
> bDescriptorType = 0x0005
> bEndpointAddress = 0x0005
> bmAttributes = 0x0002
> wMaxPacketSize = 0x0200
> bInterval = 0x
> bRefresh = 0x
> bS
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
> > > 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 15:15:45 Gardner Bell wrote: > On Tue, Apr 26, 2011 at 4:12 AM, Bernhard Schmidt > 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: 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: 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 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: > >>>> 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: 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: > >> 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 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:
> 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: 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 11:23:44 Olivier Cochard-Labbé wrote: > 2011/1/6 Bernhard Schmidt : > > 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: 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: 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: 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=8802 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: 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 > > >>>> > > > > > > wrote: > > >>>>> On 27/08/2010 09:28, Bernhard Schmidt wrote: > > >>>>>> On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey > > >>>>>> > > >>> > > >>> 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 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 > > > > wrote: > >>>>> On 27/08/2010 09:28, Bernhard Schmidt wrote: > >>>>>> On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey > >>>>>> > >>> > >>> 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 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 wrote: > >>> On 27/08/2010 09:28, Bernhard Schmidt wrote: > >>>> On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey > > > > 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 Friday, August 27, 2010 09:42:30 Bernhard Schmidt wrote: > On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey wrote: > > On 27/08/2010 09:28, Bernhard Schmidt wrote: > >> On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey 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 Sun, Aug 22, 2010 at 19:50, Dominic Fandrey 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: wpa_supplicant does not create pidfile
On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey wrote: > On 27/08/2010 09:28, Bernhard Schmidt wrote: >> On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey 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: 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
> 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
> >> 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 "type""ATTACH";
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 Sat, Apr 24, 2010 at 12:45:14AM -0700, Garrett Cooper wrote: > On Sat, Apr 24, 2010 at 12:34 AM, Bernhard Schmidt > 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 > >> wrote: > >> > On Sat, Apr 24, 2010 at 4:59 AM, Garrett Cooper > >> > wrote: > >> >> On Fri, Apr 23, 2010 at 9:42 PM, Garrett Cooper > >> >> wrote: > >> >>> On Fri, Apr 23, 2010 at 8:05 PM, Brandon Gooch > >> >>> wrote: > >> >>>> 2010/4/23 Garrett Cooper : > >> >>>>> 2010/4/23 Garrett Cooper : > >> >>>>>> 2010/4/18 Olivier Cochard-Labbé : > >> >>>>>>> 2010/4/18 Bernhard Schmidt : > >> >>>>>>>> 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
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 > wrote: > > On Sat, Apr 24, 2010 at 4:59 AM, Garrett Cooper wrote: > >> On Fri, Apr 23, 2010 at 9:42 PM, Garrett Cooper wrote: > >>> On Fri, Apr 23, 2010 at 8:05 PM, Brandon Gooch > >>> wrote: > >>>> 2010/4/23 Garrett Cooper : > >>>>> 2010/4/23 Garrett Cooper : > >>>>>> 2010/4/18 Olivier Cochard-Labbé : > >>>>>>> 2010/4/18 Bernhard Schmidt : > >>>>>>>> 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: > >>>>> > >
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=8843 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=3 > >> media: IEEE 802.11 Wireless Ethernet autoselect mode 11na > >> 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 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=patch&r1=202986&r2=203934&pathrev=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: 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: 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=revision&revision=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=47627&postcount=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: 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"
