Re: [AirForce One 54g] working
Gavin McCullagh wrote: > Hi, > > a few more details. > > On Sun, 16 Sep 2007, Gavin McCullagh wrote: > >> I have a linksys WPC54GS pcmcia wifi card. lspci details below. I tried >> it with the latest firmware and Ubuntu gutsy's 2.6.22-10-generic and >> 2.6.22-11-generic kernels. > >> I went onto the IRC channel and noted the suggestion that I try the >> wireless-dev tree (2.6.23-rc4). So I did and I'm glad to say successfully. >> I'm using it now and have been for the past 6-8 hours on and off without >> any reboot or problems. > > A little more feedback on my experiences with this driver. > > The first time I booted up, logged in (to gnome) and then popped in the > pcmcia card. The key manager prompted for password to unlock it and I got > straight onto the WPA wifi network (192.168.10.0/24). This worked fine and > continues to. > > Later I tried to boot up with the card in. I logged in and network-manager > connected to an unencrypted network (192.168.182.0/24). Not wanting that, > I clicked on the network manager and selected the WPA network. Nothing > much happened, according to the applet and the ip address and essid didn't > change according to iwconfig/ifconfig. Eventually the applet disappeared > and restarting it didn't work. In syslog, it showed that NetworkManager > had crashed. A full log is below. > > It seems there is a problem switching network but as long as I start it on > the WPA one, all is fine. I realise this driver is still experimental so > perhaps this behaviour is normal and as I know how to make it work reliably > it's okay. However, if you need more information let me know. It seems > pretty reproducible. As far as I can tell, this is a NetworkManager problem. I have two APs, one with WPA and one with WEP encryption so that I can test in either mode without affecting my wife's connection. With NetworkManager 0.6.4, I found that if I wanted to switch networks, I had to "try" to connect to a third network, which could be another encrypted wireless or my wired interface. Once that was done, then I could connect to the other wireless network. Now I have upgraded to NM 0.6.5 and I can switch wireless connections directly. I don't know which version of NM is in Gutsy, but I'm willing to bet that it is 0.6.4. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Machine Check on Fedora rawhide kernel.
On Mon, Sep 17, 2007 at 09:18:57PM +0100, David Woodhouse wrote: > On Fri, 2007-09-14 at 23:33 +0200, Michael Buesch wrote: > > These are all false positives, except this one, where the wrong > > converter function was used. > > > > @@ -442,7 +444,7 @@ void b43legacy_rx(struct b43legacy_wldev > > phystat0 = le16_to_cpu(rxhdr->phy_status0); > > phystat3 = le16_to_cpu(rxhdr->phy_status3); > > jssi = rxhdr->jssi; > > - macstat = le32_to_cpu(rxhdr->mac_status); > > + macstat = le16_to_cpu(rxhdr->mac_status); > > mactime = le16_to_cpu(rxhdr->mac_time); > > chanstat = le16_to_cpu(rxhdr->channel); > > Did this one get committed yet? Working on it now... -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [AirForce One 54g] working
Hi, a few more details. On Sun, 16 Sep 2007, Gavin McCullagh wrote: > I have a linksys WPC54GS pcmcia wifi card. lspci details below. I tried > it with the latest firmware and Ubuntu gutsy's 2.6.22-10-generic and > 2.6.22-11-generic kernels. > I went onto the IRC channel and noted the suggestion that I try the > wireless-dev tree (2.6.23-rc4). So I did and I'm glad to say successfully. > I'm using it now and have been for the past 6-8 hours on and off without > any reboot or problems. A little more feedback on my experiences with this driver. The first time I booted up, logged in (to gnome) and then popped in the pcmcia card. The key manager prompted for password to unlock it and I got straight onto the WPA wifi network (192.168.10.0/24). This worked fine and continues to. Later I tried to boot up with the card in. I logged in and network-manager connected to an unencrypted network (192.168.182.0/24). Not wanting that, I clicked on the network manager and selected the WPA network. Nothing much happened, according to the applet and the ip address and essid didn't change according to iwconfig/ifconfig. Eventually the applet disappeared and restarting it didn't work. In syslog, it showed that NetworkManager had crashed. A full log is below. It seems there is a problem switching network but as long as I start it on the WPA one, all is fine. I realise this driver is still experimental so perhaps this behaviour is normal and as I know how to make it work reliably it's okay. However, if you need more information let me know. It seems pretty reproducible. Gavin > [EMAIL PROTECTED]:~$ lspci -v -s 02:00.0 > 02:00.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] > 802.11g Wireless LAN Controller (rev 02) > Subsystem: Linksys Unknown device 0049 > Flags: bus master, fast devsel, latency 64, IRQ 10 > Memory at 2400 (32-bit, non-prefetchable) [size=8K] > > [EMAIL PROTECTED]:~$ lspci -vn -s 02:00.0 > 02:00.0 0280: 14e4:4318 (rev 02) > Subsystem: 1737:0049 > Flags: bus master, fast devsel, latency 64, IRQ 10 > Memory at 2400 (32-bit, non-prefetchable) [size=8K] Sep 17 20:17:28 tilly kernel: [ 106.569612] lo: Disabled Privacy Extensions Sep 17 20:17:28 tilly kernel: [ 106.570443] ADDRCONF(NETDEV_UP): eth0: link is not ready Sep 17 20:17:28 tilly kernel: [ 106.570500] ADDRCONF(NETDEV_UP): eth1: link is not ready Sep 17 20:17:33 tilly hcid[4838]: Default passkey agent (:1.14, /org/bluez/passkey) registered Sep 17 20:17:33 tilly hcid[4838]: Default authorization agent (:1.14, /org/bluez/auth) registered Sep 17 20:17:48 tilly NetworkManager: Updating allowed wireless network lists. Sep 17 20:17:48 tilly NetworkManager: SWITCH: no current connection, found better connection 'eth1'. Sep 17 20:17:48 tilly dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth1 for sub-path eth1.dbus.get.reason Sep 17 20:17:48 tilly NetworkManager: Will activate connection 'eth1/FON_TEST'. Sep 17 20:17:48 tilly NetworkManager: Device eth1 activation scheduled... Sep 17 20:17:48 tilly NetworkManager: Activation (eth1) started... Sep 17 20:17:48 tilly NetworkManager: Activation (eth1) Stage 1 of 5 (Device Prepare) scheduled... Sep 17 20:17:48 tilly NetworkManager: Activation (eth1) Stage 1 of 5 (Device Prepare) started... Sep 17 20:17:48 tilly NetworkManager: Activation (eth1) Stage 2 of 5 (Device Configure) scheduled... Sep 17 20:17:48 tilly NetworkManager: Activation (eth1) Stage 1 of 5 (Device Prepare) complete. Sep 17 20:17:48 tilly NetworkManager: Activation (eth1) Stage 2 of 5 (Device Configure) starting... Sep 17 20:17:48 tilly NetworkManager: Activation (eth1/wireless): access point 'FON_TEST' is unencrypted, no key needed. Sep 17 20:17:48 tilly NetworkManager: Old device 'eth1' activating, won't change. Sep 17 20:17:49 tilly NetworkManager: supplicant_interface_init() - connect to global ctrl socket (0/10). Sep 17 20:17:49 tilly NetworkManager: supplicant_interface_init() - connect to global ctrl socket (1/10). Sep 17 20:17:50 tilly NetworkManager: supplicant_interface_init() - connect to global ctrl socket (2/10). Sep 17 20:17:50 tilly NetworkManager: supplicant_interface_init() - connect to global ctrl socket (3/10). Sep 17 20:17:50 tilly NetworkManager: supplicant_interface_init() - connect to global ctrl socket (4/10). Sep 17 20:17:50 tilly NetworkManager: SUP: sending command 'INTERFACE_ADD eth1^I^Iwext^I/var/run/wpa_supplicant2^I' Sep 17 20:17:50 tilly kernel: [ 122.379900] NET: Registered protocol family 17 Sep 17 20:17:50 tilly NetworkManager: SUP: response was 'OK' Sep 17 20:17:50 tilly NetworkManager: supplicant_init() - connect to device ctrl socket (6/10). Sep 17 20:17:50 tilly NetworkManager: SUP: sending command 'AP_SCAN 1' Sep 17 20:17:50 tilly NetworkManager: SUP: response was 'OK' Sep 17 20:17:50 t
Re: Machine Check on Fedora rawhide kernel.
On Fri, 2007-09-14 at 23:33 +0200, Michael Buesch wrote: > These are all false positives, except this one, where the wrong > converter function was used. > > @@ -442,7 +444,7 @@ void b43legacy_rx(struct b43legacy_wldev > phystat0 = le16_to_cpu(rxhdr->phy_status0); > phystat3 = le16_to_cpu(rxhdr->phy_status3); > jssi = rxhdr->jssi; > - macstat = le32_to_cpu(rxhdr->mac_status); > + macstat = le16_to_cpu(rxhdr->mac_status); > mactime = le16_to_cpu(rxhdr->mac_time); > chanstat = le16_to_cpu(rxhdr->channel); Did this one get committed yet? -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43legacy: Don't cancel the restart workqueue in wireless_core_exit
John W. Linville wrote:
> On Mon, Sep 17, 2007 at 12:05:36PM -0500, Larry Finger wrote:
>> John W. Linville wrote:
>>> Is this the correct patch? The first hunk conflicts with an earlier
>>> patch ("b43legacy: Fix cancellation of work queues").
>>>
>>> John
>> Yes, this one is correct. The first one was without a commit message, and
>> had an error.
>
> H, not that one. There was another patch that (looking closer)
> you sent me and cc'ed bcm43xx-dev on or about 30 August. I guess
> I'll drop that one and use this one instead.
No, the Aug 30 one is needed. Somehow my patch sets got confused. Please apply
the August 30 patch
and drop the Sept. 10 one. I'll fix it after your tree gets updated. I don't
think it will cause any
problems. As you said, the first hunk is already in the Aug. 30 patch.
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43legacy: Don't cancel the restart workqueue in wireless_core_exit
On Mon, Sep 17, 2007 at 12:05:36PM -0500, Larry Finger wrote:
> John W. Linville wrote:
> > Is this the correct patch? The first hunk conflicts with an earlier
> > patch ("b43legacy: Fix cancellation of work queues").
> >
> > John
>
> Yes, this one is correct. The first one was without a commit message, and had
> an error.
H, not that one. There was another patch that (looking closer)
you sent me and cc'ed bcm43xx-dev on or about 30 August. I guess
I'll drop that one and use this one instead.
Thanks,
John
--
John W. Linville
[EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc regression: bcm43xx does not work after commit 4cf92a3c
Jean Tourrilhes wrote: > On Mon, Sep 17, 2007 at 04:24:18AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ > wrote: >> Hello. >> >> With latest git tree, bcm43xx driver does not work. >> By bisect, I've found the commit 4cf92a3c is the first "bad" commit. >> >> [PATCH] softmac: Fix ESSID problem >> >> Victor Porton reported that the SoftMAC layer had random problem when >> setting the ESSID : >> http://bugzilla.kernel.org/show_bug.cgi?id=8686 After investigation, it >> turned out to be >> worse, the SoftMAC layer is left in an inconsistent state. The fix is >> pretty trivial. >> >> Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]> >> Acked-by: Michael Buesch <[EMAIL PROTECTED]> >> Acked-by: Larry Finger <[EMAIL PROTECTED]> >> Signed-off-by: John W. Linville <[EMAIL PROTECTED]> >> >> After reverting this commit, the driver starts working again. Thank you for this thorough, if surprising, bug report. I would like a few more details about your configuration so that I might be able to reproduce the problem. When you say "the latest git tree", do you mean Linus's mainstream tree? Is your wireless device being controlled by NetworkManager, or by ifconfig up/down? Which distro do you use? Which BCM43xx device do you have? Thanks, Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43legacy: Don't cancel the restart workqueue in wireless_core_exit
John W. Linville wrote:
> Is this the correct patch? The first hunk conflicts with an earlier
> patch ("b43legacy: Fix cancellation of work queues").
>
> John
Yes, this one is correct. The first one was without a commit message, and had
an error.
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43legacy: Don't cancel the restart workqueue in wireless_core_exit
Is this the correct patch? The first hunk conflicts with an earlier
patch ("b43legacy: Fix cancellation of work queues").
John
On Mon, Sep 10, 2007 at 11:59:20AM -0500, Larry Finger wrote:
> From: Michael Buesch <[EMAIL PROTECTED]>
>
> The wq must be canceled later on rmmod. It's nonfatal, if
> the wq runs on a device that's not started or down. It will
> handle these cases.
> But syncing in wireless_core_exit() will cause a deadlock with
> the restart_work. (restart work cancels itself)
>
> Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
>
> John,
>
> Sorry, but I sent the bare patch in the first version.
>
> Larry
>
> drivers/net/wireless/b43legacy/main.c |2 ++
> 1 file changed, 2 insertions(+)
>
> Index: wireless-dev/drivers/net/wireless/b43legacy/main.c
> ===
> --- wireless-dev.orig/drivers/net/wireless/b43legacy/main.c
> +++ wireless-dev/drivers/net/wireless/b43legacy/main.c
> @@ -3021,6 +3021,7 @@ static void b43legacy_wireless_core_exit
> B43legacy_WARN_ON(b43legacy_status(dev) > B43legacy_STAT_INITIALIZED);
> if (b43legacy_status(dev) != B43legacy_STAT_INITIALIZED)
> return;
> + b43legacy_set_status(dev, B43legacy_STAT_UNINIT);
>
> b43legacy_rng_exit(dev->wl);
> b43legacy_pio_free(dev);
> @@ -3520,6 +3521,7 @@ static void b43legacy_one_core_detach(st
>
> wldev = ssb_get_drvdata(dev);
> wl = wldev->wl;
> + cancel_work_sync(&wldev->restart_work);
> b43legacy_debugfs_remove_device(wldev);
> b43legacy_wireless_core_detach(wldev);
> list_del(&wldev->list);
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
John W. Linville
[EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
