Re: Suspend/hibernate broken in 2.6.33
On Tuesday 16 March 2010, Chris Vine wrote: On Mon, 8 Mar 2010 17:22:26 + Chris Vine ch...@cvine.freeserve.co.uk wrote: I have noticed that although my BCM4312 802.11b/g [14e4:4315] wireless device works using the PIO option in 2.6.33, it breaks after a suspend or hibernate. Attempts to bring up the wlan0 interface with 'ifconfig wlan0 up' after suspension or hibernation results in the following message (although nothing is revealed by dmesg): SIOCSIFFLAGS: Unknown error 132 If I unload all wireless and related modules before suspending or hibernating, and then reload them on resuming, I get more information from dmesg, namely that it thinks that the wireless has been turned off by the rfkill button, which it definitely has not: [snip] I am still getting this with kernel-2.6.33.1 and I have also managed to reproduce a suspension writing to CMOS in a way which permanently disables my wireless unless I reset the BIOS to its defaults. This may not be the write mailing list to report this true. If so, what would be the correct one - the acpi list? Please report it to linux-acpi/LKML. Thanks, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: suspend vs. b43
On Sunday, 1 of June 2008, Michael Buesch wrote: On Sunday 01 June 2008 02:40:33 Stefanik Gábor wrote: Looks like we are losing track of the microcode. The driver thinks it's loaded, but in fact it isn't. Maybe we should reupload the microcode on resume. We already do this, of course. Do we do it in .resume(), perchance? ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: suspend vs. b43
On Friday, 30 of May 2008, Johannes Berg wrote: Hi, Hi, Since a while ago I've had trouble resuming when b43 was connected to an AP while suspended. I did a test today where this was the only difference, but I failed to see whether ssb or b43 were causing the problem. Does anyone have a machine with b43 in it that can suspend and supports the RTC-trace feature so we can narrow it down? Even reproducing might help to make sure it's not just something weird with my powerbook. No, it's not. It just doesn't work, AFAICS. My box is only able to suspend (without hanging) if NetworkManager is switched off or b43 is unloaded before an attempt to. Unfortunately, I didn't have the time to fight with that. Thanks, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: suspend vs. b43
On Friday, 30 of May 2008, Johannes Berg wrote: On Fri, 2008-05-30 at 16:42 +0200, Michael Buesch wrote: On Friday 30 May 2008 16:37:18 Johannes Berg wrote: Odd. Resume itself works just fine here, except when b43 is up. But then again, you might not notice that this is the problem because by default, nothing gets printed on the resume console and then it will indeed hang with a black screen. How can I change the printing? Hmm. It seems I might have been wrong here. Rafael, do we still have console suspend stuff? Yes, we do. Use no_console_suspend in the kernel command line to change that, but note that it's not generally safe (eg. if you are using netconsole at the same time). Thanks, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: suspend vs. b43
On Friday, 30 of May 2008, Johannes Berg wrote: On Fri, 2008-05-30 at 16:06 +0200, Michael Buesch wrote: On Friday 30 May 2008 14:31:53 Johannes Berg wrote: Since a while ago I've had trouble resuming when b43 was connected to an AP while suspended. I did a test today where this was the only difference, but I failed to see whether ssb or b43 were causing the problem. Does anyone have a machine with b43 in it that can suspend and supports the RTC-trace feature so we can narrow it down? Even reproducing might help to make sure it's not just something weird with my powerbook. Resume is pretty broken since some time for me. It sometimes works fine and sometimes just hangs with a black screen. I have no idea what's going on. Odd. Resume itself works just fine here, except when b43 is up. I can confirm that. It looks like a deadlock with mac80211 or something similar to my untrained eye. But then again, you might not notice that this is the problem because by default, nothing gets printed on the resume console and then it will indeed hang with a black screen. Please use no_console_suspend, as I said in the other message. Thanks, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: suspend vs. b43
On Friday, 30 of May 2008, Johannes Berg wrote: On Fri, 2008-05-30 at 17:20 +0200, Rafael J. Wysocki wrote: On Friday, 30 of May 2008, Johannes Berg wrote: On Fri, 2008-05-30 at 16:42 +0200, Michael Buesch wrote: On Friday 30 May 2008 16:37:18 Johannes Berg wrote: Odd. Resume itself works just fine here, except when b43 is up. But then again, you might not notice that this is the problem because by default, nothing gets printed on the resume console and then it will indeed hang with a black screen. How can I change the printing? Hmm. It seems I might have been wrong here. Rafael, do we still have console suspend stuff? Yes, we do. Use no_console_suspend in the kernel command line to change that, but note that it's not generally safe (eg. if you are using netconsole at the same time). I see. System reset hard and clock set to 1904, PMU didn't like me :) Thing is, I do have no_console_suspend (hardcoded in my boot loader config so I forgot), but even with PM-debug I didn't see it hang at b43 and no useful messages. Not sure what to do, hence asking if anybody has the rtc-trace stuff. It hangs for me either at read_unlock_irqrestore() in b43_op_tx() or somewhere in ieee80211_tx() (at various places). Thanks, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: suspend vs. b43
On Saturday, 31 of May 2008, Johannes Berg wrote: It hangs for me either at read_unlock_irqrestore() in b43_op_tx() or somewhere in ieee80211_tx() (at various places). Huh. Why is it even getting into the tx path? And even then, why does it hang at an unlock? Well, I saw that during hibernation, so it probably happened after creating the image, when devices were being resumed for image saving. Thanks, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: suspend vs. b43
On Saturday, 31 of May 2008, Johannes Berg wrote: On Sat, 2008-05-31 at 00:49 +0200, Rafael J. Wysocki wrote: On Saturday, 31 of May 2008, Johannes Berg wrote: It hangs for me either at read_unlock_irqrestore() in b43_op_tx() or somewhere in ieee80211_tx() (at various places). Huh. Why is it even getting into the tx path? And even then, why does it hang at an unlock? Well, I saw that during hibernation, so it probably happened after creating the image, when devices were being resumed for image saving. Yeah, like I said earlier to somebody. Still doesn't make much sense here. I'll play with it next week, or you could try to put into suspend() a call to ieee80211_stop_queues() and in resume ieee80211_wake_queues(), maybe that fixes it? I probably won't have time over the weekend to look more into it, sorry. No big deal. :-) It's always been breaking for me like this ... Thanks, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH -mm 0/5] b43: Fix suspend/resume deadlock
Hi, The following series of patches is intended to fix the suspend/resume deadlock occuring as a result of unregistering device objects, locked by the PM core, during suspend/resume cycles by the b43 driver. In short, the b43 driver is modified to avoid unregistering device objects during suspend/resume cycles except for the resume code path, in which the devices are unregistered using the recently introduced suspend-safe method. For this purpose, it is necessary to introduce the possibility to safely remove misc devices, leds classdevs and hwrng devices during suspend/resume cycles (patches 2/5, 4/5, 3/5, respectively). Please consider for applying. Thanks, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH -mm 1/5] PM: Export device_pm_schedule_removal
From: Rafael J. Wysocki [EMAIL PROTECTED]
Move the declaration of device_pm_schedule_removal() to device.h
and make it exported, as it will be used directly by some drivers
for unregistering device objects during suspend/resume cycles in a
safe way.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
drivers/base/power/main.c |1 +
drivers/base/power/power.h |1 -
include/linux/device.h |6 ++
3 files changed, 7 insertions(+), 1 deletion(-)
Index: linux-2.6.24-rc8-mm1/drivers/base/power/main.c
===
--- linux-2.6.24-rc8-mm1.orig/drivers/base/power/main.c
+++ linux-2.6.24-rc8-mm1/drivers/base/power/main.c
@@ -129,6 +129,7 @@ void device_pm_schedule_removal(struct d
list_move_tail(dev-power.entry, dpm_destroy);
mutex_unlock(dpm_list_mtx);
}
+EXPORT_SYMBOL_GPL(device_pm_schedule_removal);
/**
* pm_sleep_lock - mutual exclusion for registration and suspend
Index: linux-2.6.24-rc8-mm1/include/linux/device.h
===
--- linux-2.6.24-rc8-mm1.orig/include/linux/device.h
+++ linux-2.6.24-rc8-mm1/include/linux/device.h
@@ -532,11 +532,17 @@ extern struct device *device_create(stru
extern void device_destroy(struct class *cls, dev_t devt);
#ifdef CONFIG_PM_SLEEP
extern void destroy_suspended_device(struct class *cls, dev_t devt);
+extern void device_pm_schedule_removal(struct device *);
#else /* !CONFIG_PM_SLEEP */
static inline void destroy_suspended_device(struct class *cls, dev_t devt)
{
device_destroy(cls, devt);
}
+
+static inline void device_pm_schedule_removal(struct device *dev)
+{
+ device_unregister(dev);
+}
#endif /* !CONFIG_PM_SLEEP */
/*
Index: linux-2.6.24-rc8-mm1/drivers/base/power/power.h
===
--- linux-2.6.24-rc8-mm1.orig/drivers/base/power/power.h
+++ linux-2.6.24-rc8-mm1/drivers/base/power/power.h
@@ -13,7 +13,6 @@ static inline struct device *to_device(s
extern void device_pm_add(struct device *);
extern void device_pm_remove(struct device *);
-extern void device_pm_schedule_removal(struct device *);
extern int pm_sleep_lock(void);
extern void pm_sleep_unlock(void);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH -mm 5/5] b43: Avoid unregistering device objects during suspend
From: Rafael J. Wysocki [EMAIL PROTECTED]
Modify the b43 driver to avoid deadlocking suspend and resume,
which happens as a result of attempting to unregister device objects
locked by the PM core during suspend/resume cycles. Also, make it
use a suspend-safe method of unregistering device object in the
resume error path.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Michael Buesch [EMAIL PROTECTED]
---
drivers/net/wireless/b43/b43.h |1 +
drivers/net/wireless/b43/leds.c |5 -
drivers/net/wireless/b43/main.c | 25 -
3 files changed, 21 insertions(+), 10 deletions(-)
Index: linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/b43.h
===
--- linux-2.6.24-rc8-mm1.orig/drivers/net/wireless/b43/b43.h
+++ linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/b43.h
@@ -706,6 +706,7 @@ struct b43_wldev {
bool short_preamble;/* TRUE, if short preamble is enabled. */
bool short_slot;/* TRUE, if short slot timing is enabled. */
bool radio_hw_enable; /* saved state of radio hardware enabled state
*/
+ bool suspend_in_progress; /* TRUE, if we are in a suspend/resume
cycle */
/* PHY/Radio device. */
struct b43_phy phy;
Index: linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/main.c
===
--- linux-2.6.24-rc8-mm1.orig/drivers/net/wireless/b43/main.c
+++ linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/main.c
@@ -2470,10 +2470,10 @@ static int b43_rng_read(struct hwrng *rn
return (sizeof(u16));
}
-static void b43_rng_exit(struct b43_wl *wl)
+static void b43_rng_exit(struct b43_wl *wl, bool suspended)
{
if (wl-rng_initialized)
- hwrng_unregister(wl-rng);
+ __hwrng_unregister(wl-rng, suspended);
}
static int b43_rng_init(struct b43_wl *wl)
@@ -3298,8 +3298,10 @@ static void b43_wireless_core_exit(struc
return;
b43_set_status(dev, B43_STAT_UNINIT);
- b43_leds_exit(dev);
- b43_rng_exit(dev-wl);
+ if (!dev-suspend_in_progress) {
+ b43_leds_exit(dev);
+ b43_rng_exit(dev-wl, false);
+ }
b43_pio_free(dev);
b43_dma_free(dev);
b43_chip_exit(dev);
@@ -3420,11 +3422,13 @@ static int b43_wireless_core_init(struct
memset(wl-mac_addr, 0, ETH_ALEN);
b43_upload_card_macaddress(dev);
b43_security_init(dev);
- b43_rng_init(wl);
+ if (!dev-suspend_in_progress)
+ b43_rng_init(wl);
b43_set_status(dev, B43_STAT_INITIALIZED);
- b43_leds_init(dev);
+ if (!dev-suspend_in_progress)
+ b43_leds_init(dev);
out:
return err;
@@ -4024,6 +4028,7 @@ static int b43_suspend(struct ssb_device
b43dbg(wl, Suspending...\n);
mutex_lock(wl-mutex);
+ wldev-suspend_in_progress = true;
wldev-suspend_init_status = b43_status(wldev);
if (wldev-suspend_init_status = B43_STAT_STARTED)
b43_wireless_core_stop(wldev);
@@ -4055,15 +4060,17 @@ static int b43_resume(struct ssb_device
if (wldev-suspend_init_status = B43_STAT_STARTED) {
err = b43_wireless_core_start(wldev);
if (err) {
+ b43_leds_exit(wldev);
+ b43_rng_exit(wldev-wl, true);
b43_wireless_core_exit(wldev);
b43err(wl, Resume failed at core start\n);
goto out;
}
}
- mutex_unlock(wl-mutex);
-
b43dbg(wl, Device resumed.\n);
- out:
+ out:
+ wldev-suspend_in_progress = false;
+ mutex_unlock(wl-mutex);
return err;
}
Index: linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/leds.c
===
--- linux-2.6.24-rc8-mm1.orig/drivers/net/wireless/b43/leds.c
+++ linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/leds.c
@@ -116,7 +116,10 @@ static void b43_unregister_led(struct b4
{
if (!led-dev)
return;
- led_classdev_unregister(led-led_dev);
+ if (led-dev-suspend_in_progress)
+ led_classdev_unregister_suspended(led-led_dev);
+ else
+ led_classdev_unregister(led-led_dev);
b43_led_turn_off(led-dev, led-index, led-activelow);
led-dev = NULL;
}
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH -mm 3/5] HWRNG: Add possibility to remove hwrng devices during suspend/resume
From: Rafael J. Wysocki [EMAIL PROTECTED]
Make it possible to unregister a Hardware Random Number Generator
device object in a safe way during a suspend/resume cycle.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Michael Buesch [EMAIL PROTECTED]
---
drivers/char/hw_random/core.c | 10 +-
include/linux/hw_random.h | 10 +-
2 files changed, 14 insertions(+), 6 deletions(-)
Index: linux-2.6.24-rc8-mm1/drivers/char/hw_random/core.c
===
--- linux-2.6.24-rc8-mm1.orig/drivers/char/hw_random/core.c
+++ linux-2.6.24-rc8-mm1/drivers/char/hw_random/core.c
@@ -234,11 +234,11 @@ static DEVICE_ATTR(rng_available, S_IRUG
NULL);
-static void unregister_miscdev(void)
+static void unregister_miscdev(bool suspended)
{
device_remove_file(rng_miscdev.this_device, dev_attr_rng_available);
device_remove_file(rng_miscdev.this_device, dev_attr_rng_current);
- misc_deregister(rng_miscdev);
+ __misc_deregister(rng_miscdev, suspended);
}
static int register_miscdev(void)
@@ -313,7 +313,7 @@ out:
}
EXPORT_SYMBOL_GPL(hwrng_register);
-void hwrng_unregister(struct hwrng *rng)
+void __hwrng_unregister(struct hwrng *rng, bool suspended)
{
int err;
@@ -332,11 +332,11 @@ void hwrng_unregister(struct hwrng *rng)
}
}
if (list_empty(rng_list))
- unregister_miscdev();
+ unregister_miscdev(suspended);
mutex_unlock(rng_mutex);
}
-EXPORT_SYMBOL_GPL(hwrng_unregister);
+EXPORT_SYMBOL_GPL(__hwrng_unregister);
MODULE_DESCRIPTION(H/W Random Number Generator (RNG) driver);
Index: linux-2.6.24-rc8-mm1/include/linux/hw_random.h
===
--- linux-2.6.24-rc8-mm1.orig/include/linux/hw_random.h
+++ linux-2.6.24-rc8-mm1/include/linux/hw_random.h
@@ -44,7 +44,15 @@ struct hwrng {
/** Register a new Hardware Random Number Generator driver. */
extern int hwrng_register(struct hwrng *rng);
/** Unregister a Hardware Random Number Generator driver. */
-extern void hwrng_unregister(struct hwrng *rng);
+extern void __hwrng_unregister(struct hwrng *rng, bool suspended);
+static inline void hwrng_unregister(struct hwrng *rng)
+{
+ __hwrng_unregister(rng, false);
+}
+static inline void hwrng_unregister_suspended(struct hwrng *rng)
+{
+ __hwrng_unregister(rng, true);
+}
#endif /* __KERNEL__ */
#endif /* LINUX_HWRANDOM_H_ */
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH -mm 4/5] Leds: Add possibility to remove leds classdevs during suspend/resume
From: Rafael J. Wysocki [EMAIL PROTECTED]
Make it possible to unregister a led classdev object in a safe way
during a suspend/resume cycle.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
drivers/leds/led-class.c | 13 +
include/linux/leds.h | 10 +-
2 files changed, 18 insertions(+), 5 deletions(-)
Index: linux-2.6.24-rc8-mm1/drivers/leds/led-class.c
===
--- linux-2.6.24-rc8-mm1.orig/drivers/leds/led-class.c
+++ linux-2.6.24-rc8-mm1/drivers/leds/led-class.c
@@ -137,12 +137,14 @@ err_out:
EXPORT_SYMBOL_GPL(led_classdev_register);
/**
- * led_classdev_unregister - unregisters a object of led_properties class.
+ * __led_classdev_unregister - unregisters a object of led_properties class.
* @led_cdev: the led device to unregister
+ * @suspended: indicates whether system-wide suspend or resume is in progress
*
* Unregisters a previously registered via led_classdev_register object.
*/
-void led_classdev_unregister(struct led_classdev *led_cdev)
+void __led_classdev_unregister(struct led_classdev *led_cdev,
+ bool suspended)
{
device_remove_file(led_cdev-dev, dev_attr_brightness);
#ifdef CONFIG_LEDS_TRIGGERS
@@ -153,13 +155,16 @@ void led_classdev_unregister(struct led_
up_write(led_cdev-trigger_lock);
#endif
- device_unregister(led_cdev-dev);
+ if (suspended)
+ device_pm_schedule_removal(led_cdev-dev);
+ else
+ device_unregister(led_cdev-dev);
down_write(leds_list_lock);
list_del(led_cdev-node);
up_write(leds_list_lock);
}
-EXPORT_SYMBOL_GPL(led_classdev_unregister);
+EXPORT_SYMBOL_GPL(__led_classdev_unregister);
static int __init leds_init(void)
{
Index: linux-2.6.24-rc8-mm1/include/linux/leds.h
===
--- linux-2.6.24-rc8-mm1.orig/include/linux/leds.h
+++ linux-2.6.24-rc8-mm1/include/linux/leds.h
@@ -59,7 +59,15 @@ struct led_classdev {
extern int led_classdev_register(struct device *parent,
struct led_classdev *led_cdev);
-extern void led_classdev_unregister(struct led_classdev *led_cdev);
+extern void __led_classdev_unregister(struct led_classdev *led_cdev, bool sus);
+static inline void led_classdev_unregister(struct led_classdev *lcd)
+{
+ __led_classdev_unregister(lcd, false);
+}
+static inline void led_classdev_unregister_suspended(struct led_classdev *lcd)
+{
+ __led_classdev_unregister(lcd, true);
+}
extern void led_classdev_suspend(struct led_classdev *led_cdev);
extern void led_classdev_resume(struct led_classdev *led_cdev);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH -mm 2/5] Misc: Add possibility to remove misc devices during suspend/resume
From: Rafael J. Wysocki [EMAIL PROTECTED]
Make it possible to unregister a misc device object in a safe way
during a suspend/resume cycle.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
drivers/char/misc.c| 13 +
include/linux/miscdevice.h | 10 +-
2 files changed, 18 insertions(+), 5 deletions(-)
Index: linux-2.6.24-rc8-mm1/include/linux/miscdevice.h
===
--- linux-2.6.24-rc8-mm1.orig/include/linux/miscdevice.h
+++ linux-2.6.24-rc8-mm1/include/linux/miscdevice.h
@@ -43,7 +43,15 @@ struct miscdevice {
};
extern int misc_register(struct miscdevice * misc);
-extern int misc_deregister(struct miscdevice * misc);
+extern int __misc_deregister(struct miscdevice *misc, bool suspended);
+static inline int misc_deregister(struct miscdevice *misc)
+{
+ return __misc_deregister(misc, false);
+}
+static inline int misc_deregister_suspended(struct miscdevice *misc)
+{
+ return __misc_deregister(misc, true);
+}
#define MODULE_ALIAS_MISCDEV(minor)\
MODULE_ALIAS(char-major- __stringify(MISC_MAJOR) \
Index: linux-2.6.24-rc8-mm1/drivers/char/misc.c
===
--- linux-2.6.24-rc8-mm1.orig/drivers/char/misc.c
+++ linux-2.6.24-rc8-mm1/drivers/char/misc.c
@@ -232,8 +232,9 @@ int misc_register(struct miscdevice * mi
}
/**
- * misc_deregister - unregister a miscellaneous device
+ * __misc_deregister - unregister a miscellaneous device
* @misc: device to unregister
+ * @suspended: to be set if the function is used during suspend/resume
*
* Unregister a miscellaneous device that was previously
* successfully registered with misc_register(). Success
@@ -241,7 +242,7 @@ int misc_register(struct miscdevice * mi
* indicates an error.
*/
-int misc_deregister(struct miscdevice * misc)
+int __misc_deregister(struct miscdevice *misc, bool suspended)
{
int i = misc-minor;
@@ -250,7 +251,11 @@ int misc_deregister(struct miscdevice *
mutex_lock(misc_mtx);
list_del(misc-list);
- device_destroy(misc_class, MKDEV(MISC_MAJOR, misc-minor));
+ if (suspended)
+ destroy_suspended_device(misc_class,
+ MKDEV(MISC_MAJOR, misc-minor));
+ else
+ device_destroy(misc_class, MKDEV(MISC_MAJOR, misc-minor));
if (i DYNAMIC_MINORS i0) {
misc_minors[i3] = ~(1 (misc-minor 7));
}
@@ -259,7 +264,7 @@ int misc_deregister(struct miscdevice *
}
EXPORT_SYMBOL(misc_register);
-EXPORT_SYMBOL(misc_deregister);
+EXPORT_SYMBOL(__misc_deregister);
static int __init misc_init(void)
{
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH -mm 5/5] b43: Avoid unregistering device objects during suspend
On Friday, 25 of January 2008, Michael Buesch wrote: On Friday 25 January 2008 08:47:46 Pavel Machek wrote: On Fri 2008-01-25 01:37:33, Rafael J. Wysocki wrote: From: Rafael J. Wysocki [EMAIL PROTECTED] Modify the b43 driver to avoid deadlocking suspend and resume, which happens as a result of attempting to unregister device objects locked by the PM core during suspend/resume cycles. Also, make it use a suspend-safe method of unregistering device object in the resume error path. Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Acked-by: Michael Buesch [EMAIL PROTECTED] Maybe we should have global suspend_in_progress (or maybe system_state == suspending?) and automatically switch to schedule_removal() while it is set? That would be great, from my perspective :) Let's see how many drivers are going to need that. If there's more than a couple, it will certainly make sense to have a global variable like this. Thanks, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: resuming from suspend to disk not working with b43
On Wednesday, 23 of January 2008, Celejar wrote:
Hi,
Hi,
I know there's an ongoing long thread about suspend in b43, but
the technical level has been above me, and I don't know if anything
there is relevant to me.
When I suspend to disk ('s2disk' from uswsusp), the resume fails if b43
is loaded. The screen stays blank, although I see a cursor flashing.
'modprobe -r b43' before suspending makes the resume work fine, but if I
subsequently load b43 after the resume the machine freezes.
Hm, I use b43 w/ s2disk on a regular basis and it works, but openSUSE has a
userland suspend hook that disables NetworkManager before a suspend.
I am using Debian Sid, b43 from vanilla kernels from kernel.org (2.6.24
isn't in Debian yet). I have had this problem with -rc4 and -rc8. the
only two I've tried. HW is a 4318 Air Force One, in an Acer Aspire
3690-2672. Is there any debugging info I can provide? Is this a known
problem? Is there anything I should try?
Please try to switch off the interface before suspend without unloading the
module.
Also, does s2ram work on your box?
Rafael
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: resuming from suspend to disk not working with b43
On Wednesday, 23 of January 2008, Celejar wrote:
On Wed, 23 Jan 2008 16:00:15 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Wednesday, 23 of January 2008, Celejar wrote:
Hi,
Hi,
I know there's an ongoing long thread about suspend in b43, but
the technical level has been above me, and I don't know if anything
there is relevant to me.
When I suspend to disk ('s2disk' from uswsusp), the resume fails if b43
is loaded. The screen stays blank, although I see a cursor flashing.
'modprobe -r b43' before suspending makes the resume work fine, but if I
subsequently load b43 after the resume the machine freezes.
Hm, I use b43 w/ s2disk on a regular basis and it works, but openSUSE has a
userland suspend hook that disables NetworkManager before a suspend.
I am using Debian Sid, b43 from vanilla kernels from kernel.org (2.6.24
isn't in Debian yet). I have had this problem with -rc4 and -rc8. the
only two I've tried. HW is a 4318 Air Force One, in an Acer Aspire
3690-2672. Is there any debugging info I can provide? Is this a known
problem? Is there anything I should try?
Please try to switch off the interface before suspend without unloading the
module.
I did 'ifdown eth0' followed by 'ifconfig eth0 down'; I assume that's
what you meant. I do have some sort of HW switch, but I never touch it.
The machine came up okay. 'ifconfig -a' shows eth0 (unconfigured), but
'ifup eth0' and even 'ifconfig eth0 up' returns 'SIOCSIFFLAGS: no such
device. lsmod shows that b43 is still there. When I then did
'modprobe -r b43' followed by 'modprobe b43', the machine froze - no
screen output after the module insertion.
When 2.6.24 is out, please test it, but make sure you don't set
USB_OHCI_HCD_SSB.
Also, does s2ram work on your box?
I've never gotten it to resume correctly. I tried at one time
many / most of the s2ram option suggestions from the
README.s2ram-whitelist, but nothing worked, and I eventually ran out of
patience for the sort of experimenting that required constant hard
power offs and reboots.
There are some suspend debug patches scheduled for 2.6.25 time frame. If they
get merged, we'll be able to check what's going wrong here.
Thanks,
Rafael
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43_suspend problem
On Monday, 21 of January 2008, Michael Buesch wrote:
On Monday 21 January 2008, Rafael J. Wysocki wrote:
[--snip--]
Index: linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/leds.h
===
--- linux-2.6.24-rc8-mm1.orig/drivers/net/wireless/b43/leds.h
+++ linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/leds.h
@@ -43,8 +43,15 @@ enum b43_led_behaviour {
};
void b43_leds_init(struct b43_wldev *dev);
-void b43_leds_exit(struct b43_wldev *dev);
-
+void __b43_leds_exit(struct b43_wldev *dev, bool suspended);
+static inline void b43_leds_exit(struct b43_wldev *dev)
+{
+ __b43_leds_exit(dev, false);
+}
+static inline void b43_leds_resume_exit(struct b43_wldev *dev)
+{
+ __b43_leds_exit(dev, true);
+}
I still don't like this function wrapping.
I'm pretty sure the additional parameter to the function is not
needed. We can check dev-suspend_in_progress to find out
if we are in a up/down or in a suspend/resume cycle.
You're right, I overlooked that.
-static void b43_unregister_led(struct b43_led *led)
+static void b43_unregister_led(struct b43_led *led, bool suspended)
{
if (!led-dev)
return;
- led_classdev_unregister(led-led_dev);
+ if (suspended)
You can check led-dev-suspend_in_progress here.
+ led_classdev_unregister_suspended(led-led_dev);
+ else
+ led_classdev_unregister(led-led_dev);
b43_led_turn_off(led-dev, led-index, led-activelow);
led-dev = NULL;
}
@@ -230,10 +233,10 @@ void b43_leds_init(struct b43_wldev *dev
}
}
-void b43_leds_exit(struct b43_wldev *dev)
+void __b43_leds_exit(struct b43_wldev *dev, bool suspended)
{
- b43_unregister_led(dev-led_tx);
- b43_unregister_led(dev-led_rx);
- b43_unregister_led(dev-led_assoc);
- b43_unregister_led(dev-led_radio);
+ b43_unregister_led(dev-led_tx, suspended);
+ b43_unregister_led(dev-led_rx, suspended);
+ b43_unregister_led(dev-led_assoc, suspended);
+ b43_unregister_led(dev-led_radio, suspended);
}
Don't need this hunk. Check led-dev-suspend_in_progress in
b43_unregister_led.
#endif /* __KERNEL__ */
#endif /* LINUX_HWRANDOM_H_ */
Index: linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/b43.h
===
--- linux-2.6.24-rc8-mm1.orig/drivers/net/wireless/b43/b43.h
+++ linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/b43.h
@@ -706,6 +706,7 @@ struct b43_wldev {
bool short_preamble;/* TRUE, if short preamble is enabled. */
bool short_slot;/* TRUE, if short slot timing is enabled. */
bool radio_hw_enable; /* saved state of radio hardware enabled state
*/
+ bool suspend_in_progress;
Please add a comment like: /* TRUE, if we are in a suspend/resume cycle */
Sure, I just didn't know what to write in the comment. :-)
Revised patch below, please have a look.
Thanks,
Rafael
---
drivers/base/power/main.c |1 +
drivers/base/power/power.h |1 -
drivers/char/hw_random/core.c | 10 +-
drivers/char/misc.c | 13 +
drivers/leds/led-class.c| 13 +
drivers/net/wireless/b43/b43.h |1 +
drivers/net/wireless/b43/leds.c |5 -
drivers/net/wireless/b43/main.c | 25 -
include/linux/device.h |6 ++
include/linux/hw_random.h | 10 +-
include/linux/leds.h| 10 +-
include/linux/miscdevice.h | 10 +-
12 files changed, 78 insertions(+), 27 deletions(-)
Index: linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/main.c
===
--- linux-2.6.24-rc8-mm1.orig/drivers/net/wireless/b43/main.c
+++ linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/main.c
@@ -2470,10 +2470,10 @@ static int b43_rng_read(struct hwrng *rn
return (sizeof(u16));
}
-static void b43_rng_exit(struct b43_wl *wl)
+static void b43_rng_exit(struct b43_wl *wl, bool suspended)
{
if (wl-rng_initialized)
- hwrng_unregister(wl-rng);
+ __hwrng_unregister(wl-rng, suspended);
}
static int b43_rng_init(struct b43_wl *wl)
@@ -3298,8 +3298,10 @@ static void b43_wireless_core_exit(struc
return;
b43_set_status(dev, B43_STAT_UNINIT);
- b43_leds_exit(dev);
- b43_rng_exit(dev-wl);
+ if (!dev-suspend_in_progress) {
+ b43_leds_exit(dev);
+ b43_rng_exit(dev-wl, false);
+ }
b43_pio_free(dev);
b43_dma_free(dev);
b43_chip_exit(dev);
@@ -3420,11 +3422,13 @@ static int b43_wireless_core_init(struct
memset(wl-mac_addr, 0, ETH_ALEN);
b43_upload_card_macaddress(dev);
b43_security_init(dev);
- b43_rng_init(wl);
+ if (!dev-suspend_in_progress)
+ b43_rng_init(wl
Re: b43_suspend problem
On Sunday, 20 of January 2008, Michael Buesch wrote:
On Sunday 20 January 2008, Rafael J. Wysocki wrote:
On Sunday, 13 of January 2008, Alan Stern wrote:
On Sun, 13 Jan 2008, Michael Buesch wrote:
Besides, if you're going to register the device right back again
during
the subsequent resume, then why go to the trouble of unregistering it
during suspend? Why not just leave it registered the whole time and
avoid all the complication (and excess meaningless uevents)?
Well, because not doing it complicates code :)
Currently suspend/resume calls the same code as init/exit.
The b43 init/exit code is really complicated, compared to other
drivers, due to dozens of hardware versions. So I just avoided
having yet other codepaths for suspend/resume. But I will add
a flag to the device structure that's used to avoid unregistering stuff.
Instead of adding an extra flag you should refactor the code. Have a
common enable subroutine that can be called for both init and resume,
and a common disable subroutine that can be called for both exit and
suspend. Then the method routines themselves will contain only the
portions unique to their particular functions, making them shorter and
simpler.
Well, it doesn't seem to be that easy.
I tried to fix the issue myself and finally obtained the appended,
apparently
working, patch (against 2.6.24-rc8-mm1). Well, it should have been a series
of patches against multiple subsystems, but I thought it would be
instructive
to put everything needed into one bigger patch for starters.
Greetings,
Rafael
---
drivers/base/power/main.c |1
drivers/base/power/power.h |1
drivers/char/hw_random/core.c | 10 -
drivers/char/misc.c | 13
drivers/leds/led-class.c| 13
drivers/net/wireless/b43/leds.c | 17 +--
drivers/net/wireless/b43/leds.h | 14 +++--
drivers/net/wireless/b43/main.c | 43
+---
include/linux/device.h |6 +
include/linux/hw_random.h | 10 -
include/linux/leds.h| 10 -
include/linux/miscdevice.h | 10 -
12 files changed, 111 insertions(+), 37 deletions(-)
Index: linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/main.c
===
--- linux-2.6.24-rc8-mm1.orig/drivers/net/wireless/b43/main.c
+++ linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/main.c
@@ -2470,10 +2470,15 @@ static int b43_rng_read(struct hwrng *rn
return (sizeof(u16));
}
-static void b43_rng_exit(struct b43_wl *wl)
+static void __b43_rng_exit(struct b43_wl *wl, bool suspended)
{
if (wl-rng_initialized)
- hwrng_unregister(wl-rng);
+ __hwrng_unregister(wl-rng, suspended);
+}
+
+static void b43_rng_exit(struct b43_wl *wl)
+{
+ __b43_rng_exit(wl, false);
}
static int b43_rng_init(struct b43_wl *wl)
@@ -3289,7 +3294,7 @@ static void b43_set_retry_limits(struct
/* Shutdown a wireless core */
/* Locking: wl-mutex */
-static void b43_wireless_core_exit(struct b43_wldev *dev)
+static void __b43_wireless_core_exit(struct b43_wldev *dev, bool
no_suspend)
{
struct b43_phy *phy = dev-phy;
@@ -3298,8 +3303,10 @@ static void b43_wireless_core_exit(struc
return;
b43_set_status(dev, B43_STAT_UNINIT);
- b43_leds_exit(dev);
- b43_rng_exit(dev-wl);
+ if (no_suspend) {
+ b43_leds_exit(dev);
+ b43_rng_exit(dev-wl);
+ }
b43_pio_free(dev);
b43_dma_free(dev);
b43_chip_exit(dev);
@@ -3313,8 +3320,13 @@ static void b43_wireless_core_exit(struc
ssb_bus_may_powerdown(dev-dev-bus);
}
+static void b43_wireless_core_exit(struct b43_wldev *dev)
+{
+ __b43_wireless_core_exit(dev, true);
+}
Nah, please don't obfuscate the code.
Better add a flag to struct b43_wldev and check that in the few places
that need different behaviour.
I can do that, if you prefer, but that will look worse, IMHO.
Thanks,
Rafael
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43_suspend problem
On Sunday, 20 of January 2008, Michael Buesch wrote:
On Sunday 20 January 2008, Rafael J. Wysocki wrote:
Nah, please don't obfuscate the code.
Better add a flag to struct b43_wldev and check that in the few places
that need different behaviour.
I can do that, if you prefer, but that will look worse, IMHO.
I'm pretty sure it won't. We had such a flag in the past for firmware.
(Fixed that differently now).
You simply have do do dev-suspending = 1; at the beginning of suspend/resume
and dev-suspending = 0; at the end. The if() checks in the code remain the
same.
The only thing that this approach won't do it clutter the (already hard
to understand) interface up/down API. And that is good. We already have
enough special cases for this stuff due to device weirdness. Let's not make
it worse.
I had a hard time to make a sane API for this (look at bcm43xx to compare to
the old crap that doesn't work on lots of devices. ;) )
I modified the patch to implement something like this. This still is one big
patch against everything what's necessary. [BTW, in the current version
of the code, b43_resume() may leave wl-mutex locked in the error paths,
which also is fixed by the patch.]
Please have a look.
Thanks for doing this patch.
You're welcome. :-)
Thanks,
Rafael
---
drivers/base/power/main.c |1 +
drivers/base/power/power.h |1 -
drivers/char/hw_random/core.c | 10 +-
drivers/char/misc.c | 13 +
drivers/leds/led-class.c| 13 +
drivers/net/wireless/b43/b43.h |1 +
drivers/net/wireless/b43/leds.c | 17 ++---
drivers/net/wireless/b43/leds.h | 14 --
drivers/net/wireless/b43/main.c | 25 -
include/linux/device.h |6 ++
include/linux/hw_random.h | 10 +-
include/linux/leds.h| 10 +-
include/linux/miscdevice.h | 10 +-
13 files changed, 96 insertions(+), 35 deletions(-)
Index: linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/main.c
===
--- linux-2.6.24-rc8-mm1.orig/drivers/net/wireless/b43/main.c
+++ linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/main.c
@@ -2470,10 +2470,10 @@ static int b43_rng_read(struct hwrng *rn
return (sizeof(u16));
}
-static void b43_rng_exit(struct b43_wl *wl)
+static void b43_rng_exit(struct b43_wl *wl, bool suspended)
{
if (wl-rng_initialized)
- hwrng_unregister(wl-rng);
+ __hwrng_unregister(wl-rng, suspended);
}
static int b43_rng_init(struct b43_wl *wl)
@@ -3298,8 +3298,10 @@ static void b43_wireless_core_exit(struc
return;
b43_set_status(dev, B43_STAT_UNINIT);
- b43_leds_exit(dev);
- b43_rng_exit(dev-wl);
+ if (!dev-suspend_in_progress) {
+ b43_leds_exit(dev);
+ b43_rng_exit(dev-wl, false);
+ }
b43_pio_free(dev);
b43_dma_free(dev);
b43_chip_exit(dev);
@@ -3420,11 +3422,13 @@ static int b43_wireless_core_init(struct
memset(wl-mac_addr, 0, ETH_ALEN);
b43_upload_card_macaddress(dev);
b43_security_init(dev);
- b43_rng_init(wl);
+ if (!dev-suspend_in_progress)
+ b43_rng_init(wl);
b43_set_status(dev, B43_STAT_INITIALIZED);
- b43_leds_init(dev);
+ if (!dev-suspend_in_progress)
+ b43_leds_init(dev);
out:
return err;
@@ -4024,6 +4028,7 @@ static int b43_suspend(struct ssb_device
b43dbg(wl, Suspending...\n);
mutex_lock(wl-mutex);
+ wldev-suspend_in_progress = true;
wldev-suspend_init_status = b43_status(wldev);
if (wldev-suspend_init_status = B43_STAT_STARTED)
b43_wireless_core_stop(wldev);
@@ -4055,15 +4060,17 @@ static int b43_resume(struct ssb_device
if (wldev-suspend_init_status = B43_STAT_STARTED) {
err = b43_wireless_core_start(wldev);
if (err) {
+ b43_leds_resume_exit(wldev);
+ b43_rng_exit(wldev-wl, true);
b43_wireless_core_exit(wldev);
b43err(wl, Resume failed at core start\n);
goto out;
}
}
- mutex_unlock(wl-mutex);
-
b43dbg(wl, Device resumed.\n);
- out:
+ out:
+ wldev-suspend_in_progress = false;
+ mutex_unlock(wl-mutex);
return err;
}
Index: linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/leds.h
===
--- linux-2.6.24-rc8-mm1.orig/drivers/net/wireless/b43/leds.h
+++ linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/leds.h
@@ -43,8 +43,15 @@ enum b43_led_behaviour {
};
void b43_leds_init(struct b43_wldev *dev);
-void b43_leds_exit(struct b43_wldev *dev);
-
+void __b43_leds_exit(struct b43_wldev *dev, bool
Re: b43_suspend problem
On Sunday, 13 of January 2008, Alan Stern wrote:
On Sun, 13 Jan 2008, Michael Buesch wrote:
Besides, if you're going to register the device right back again during
the subsequent resume, then why go to the trouble of unregistering it
during suspend? Why not just leave it registered the whole time and
avoid all the complication (and excess meaningless uevents)?
Well, because not doing it complicates code :)
Currently suspend/resume calls the same code as init/exit.
The b43 init/exit code is really complicated, compared to other
drivers, due to dozens of hardware versions. So I just avoided
having yet other codepaths for suspend/resume. But I will add
a flag to the device structure that's used to avoid unregistering stuff.
Instead of adding an extra flag you should refactor the code. Have a
common enable subroutine that can be called for both init and resume,
and a common disable subroutine that can be called for both exit and
suspend. Then the method routines themselves will contain only the
portions unique to their particular functions, making them shorter and
simpler.
Well, it doesn't seem to be that easy.
I tried to fix the issue myself and finally obtained the appended, apparently
working, patch (against 2.6.24-rc8-mm1). Well, it should have been a series
of patches against multiple subsystems, but I thought it would be instructive
to put everything needed into one bigger patch for starters.
Greetings,
Rafael
---
drivers/base/power/main.c |1
drivers/base/power/power.h |1
drivers/char/hw_random/core.c | 10 -
drivers/char/misc.c | 13
drivers/leds/led-class.c| 13
drivers/net/wireless/b43/leds.c | 17 +--
drivers/net/wireless/b43/leds.h | 14 +++--
drivers/net/wireless/b43/main.c | 43 +---
include/linux/device.h |6 +
include/linux/hw_random.h | 10 -
include/linux/leds.h| 10 -
include/linux/miscdevice.h | 10 -
12 files changed, 111 insertions(+), 37 deletions(-)
Index: linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/main.c
===
--- linux-2.6.24-rc8-mm1.orig/drivers/net/wireless/b43/main.c
+++ linux-2.6.24-rc8-mm1/drivers/net/wireless/b43/main.c
@@ -2470,10 +2470,15 @@ static int b43_rng_read(struct hwrng *rn
return (sizeof(u16));
}
-static void b43_rng_exit(struct b43_wl *wl)
+static void __b43_rng_exit(struct b43_wl *wl, bool suspended)
{
if (wl-rng_initialized)
- hwrng_unregister(wl-rng);
+ __hwrng_unregister(wl-rng, suspended);
+}
+
+static void b43_rng_exit(struct b43_wl *wl)
+{
+ __b43_rng_exit(wl, false);
}
static int b43_rng_init(struct b43_wl *wl)
@@ -3289,7 +3294,7 @@ static void b43_set_retry_limits(struct
/* Shutdown a wireless core */
/* Locking: wl-mutex */
-static void b43_wireless_core_exit(struct b43_wldev *dev)
+static void __b43_wireless_core_exit(struct b43_wldev *dev, bool no_suspend)
{
struct b43_phy *phy = dev-phy;
@@ -3298,8 +3303,10 @@ static void b43_wireless_core_exit(struc
return;
b43_set_status(dev, B43_STAT_UNINIT);
- b43_leds_exit(dev);
- b43_rng_exit(dev-wl);
+ if (no_suspend) {
+ b43_leds_exit(dev);
+ b43_rng_exit(dev-wl);
+ }
b43_pio_free(dev);
b43_dma_free(dev);
b43_chip_exit(dev);
@@ -3313,8 +3320,13 @@ static void b43_wireless_core_exit(struc
ssb_bus_may_powerdown(dev-dev-bus);
}
+static void b43_wireless_core_exit(struct b43_wldev *dev)
+{
+ __b43_wireless_core_exit(dev, true);
+}
+
/* Initialize a wireless core */
-static int b43_wireless_core_init(struct b43_wldev *dev)
+static int __b43_wireless_core_init(struct b43_wldev *dev, bool no_suspend)
{
struct b43_wl *wl = dev-wl;
struct ssb_bus *bus = dev-dev-bus;
@@ -3420,11 +3432,13 @@ static int b43_wireless_core_init(struct
memset(wl-mac_addr, 0, ETH_ALEN);
b43_upload_card_macaddress(dev);
b43_security_init(dev);
- b43_rng_init(wl);
+ if (no_suspend)
+ b43_rng_init(wl);
b43_set_status(dev, B43_STAT_INITIALIZED);
- b43_leds_init(dev);
+ if (no_suspend)
+ b43_leds_init(dev);
out:
return err;
@@ -3442,6 +3456,11 @@ out:
return err;
}
+static int b43_wireless_core_init(struct b43_wldev *dev)
+{
+ return __b43_wireless_core_init(dev, true);
+}
+
static int b43_op_add_interface(struct ieee80211_hw *hw,
struct ieee80211_if_init_conf *conf)
{
@@ -4028,7 +4047,7 @@ static int b43_suspend(struct ssb_device
if (wldev-suspend_init_status = B43_STAT_STARTED)
b43_wireless_core_stop(wldev);
if
Re: b43_suspend problem
On Sunday, 13 of January 2008, Michael Buesch wrote: On Sunday 13 January 2008 00:08:29 Rafael J. Wysocki wrote: There is a problem with b43_suspend() that it (indirectly) causes b43_leds_exit() to be called, which attempts to unregister the leds device objects, which is forbidden (ie. you can't unregister and/or register devices during a suspend or resume). Why? Well, the unregistering itself is not really harmful, provided that the device is not registered back during the subsequent resume. The PM core uses a list of active devices that are added to the list in device_add(). The ordering of this list is important, because it is expected to reflect the order in which the devices are to be suspended. This list is manipulated during suspend/resume and devices are moved from it and back to it, so unregistering devices during a suspend and registering them during the subsequent resume generally changes its ordering and may lead to problems during the next suspend/resume cycle. This is also undesirable if we're going to stop using the freezer for suspend/resume at one point in the future. I'm sure Alan can add some more details. Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 will need a firmware upgrade soon
On Monday, 7 of January 2008, Michael Buesch wrote: On Sunday 06 January 2008 23:01:00 John W. Linville wrote: On Sun, Jan 06, 2008 at 10:38:43PM +0100, Michael Buesch wrote: On Sunday 06 January 2008 22:35:51 Pavel Roskin wrote: Quoting Michael Buesch [EMAIL PROTECTED]: see fwpostfix module parameter Can we please avoid this annoyance this time? Go and complain at Broadcom please. Broadcom doesn't really have this problem, since they are free to include the binary firmware in their Windows/Mac/whatever drivers. If the driver needs different firmware, why not have it ask for different filenames? As I suggested elsewhere, this could be as simple as setting a default value for fwpostfix... I'm not sure why people are complaining about stuff that's not done, yet. I just said that we need an update to an incompatible firmware soon. HOW that happens is an entirely different question. It seems like we _might_ be able to support both fw versions for some limited time. If that is not possible for whatever reason, I will change the fw filenames, of course. (And people will complain about that, too. Because the rule for broadcom firmware is: Always complain about whatever you do. ;) ) The _just_ wanted to tell people about a serious change _before_ it happens. I'm not sure why this results in all kinds of complaints. Most probably, because the people don't want that to happen. ;-) Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Friday, 14 of December 2007, Michael Buesch wrote: On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote: This user did get the following messages in dmesg: b43err(dev-wl, Firmware file \%s\ not found or load failed.\n, path); So the question seems to be why b43 needs version 4, when b43legacy and bcm43x uses version 3? That's really a question, right? Well. linux-2.4 doesn't work with the linux-2.6 modutils. Windows Vista doesn't work with Windows 98 device drivers. That leads to this assumption: b43 doesn't work with version 3 firmware but needs version 4. Newer drivers supporting newer hardware need newer firmware. Actually, can you explain why, from the technical point of view, the version 4 firware is better than version 3, please? Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Friday, 14 of December 2007, Michael Buesch wrote: On Friday 14 December 2007 18:59:10 Ingo Molnar wrote: * Michael Buesch [EMAIL PROTECTED] wrote: In my opinion this all is the work of the distributions and not the work of the kernel developers. Distributions have to make sure that everything works after a kernel update. [...] actually, not. The the task of kernel developers is to KEEP OLD DISTRIBUTIONS WORKING WITH NEW DRIVERS. Or the old driver stays around until eternity, because the new one is just BROKEN. What exactly prevents an old distribution from using new b43 given that they fix their broken udev scripts first? (I cannot fix their broken scripts from within the kernel.) Well, we talked about that some time ago, didn't we? The rule is this: if one uses kernel 2.6.x from kernel.org _successfully_ with certain distribution (whatever it is), then one is supposed to be able to take the kernel 2.6.(x+1), install it on that distribution and use it without any major configuration changes. If this rule is not followed, people will stop testing kernel.org kernels and we'll all suffer from that. Now, in my not so humble opinion, switching from bcm43xx to b43 _is_ a major configuration change (I did it, so please don't try to discuss with my experience) and forcing users to do that breaks the rule above. Take a look at CONFIG_COMPAT_VDSO for example - one single version of glibc was released in a distro that depended on a kernel vDSO bug. So we'll keep that aspect of the vDSO perhaps forever. Simple as that. Stuff must just work. Whatever it takes. Best is if you add in new stuff without the user noticing _ANYTHING_ but that the kernel version bumped. If the maintainers of the other 7 million lines of kernel code can get this right then the wireless code should be able to do it too. Ok? all this distributors will have to sort out the mess talk is nonsense, and i really hope you do not truly believe in that crap. If your attitude is prevalent in the wireless development community then it's in worse shape than i thought :-( Sorry if I didn't chose my wording correctly. But I was only talking about the development of drivers. It is correct that userspace ABI has to be preserved, but that is not an issue at all to drivers. I was talking about things like installing the right firmware for the new driver. It is the job of the distributors to install the new firmware when they introduce a new driver. Yes, as far as new distributions are concerned. However, we _want_ kernel.org kernels to work with the old ones too. Yes, WE DO. It is the job of the distributors to test their userland scripts and configuration stuff with that driver and fix their stuff. It is _not_ my job to fix random distribution udev scripts or explaining over and over again to people how the firmware is installed. Given specific software environment (it may be a home-made system compiled from sources or whatever), if installing a new kernel forces me to reconfigure it in any significant way to obtain the functionality that I previously had, the problem is with the kernel. No less, no more. Either distributions have to install it automatically or people simply have to read one or two lines of documentation. That's just what I wanted to say. It's not that simple. For example, regression testing will be a major PITA if one needs to switch back and forth from the new driver to the old one in the process. Of course it is _my_ job to preserve ABI. I did never want to question that. Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: timeout problems with certain APs and b43
On Saturday, 24 of November 2007, Johannes Berg wrote: It seems that I can reproduce something similar on demand with an SMC wireless router by moving my box sufficiently far away from it. :-) Well, yeah, that's expected though, you lose signal at some point. Not expected is that it happens without moving anything. Unless the calibration code is wrong which wouldn't really surprise me either. In my case, everything works just fine when the box is 6 meters away from the AP (including a thick wall in between), but when I move it another 5-6 meters away from the AP, things break down ... I'd expect it to work at longer distances, but well. :-) Yeah, but keep in mind we reverse engineered all the calibration code. Sure. :-) For me it's not a problem (everywhere I use the wireless, there are APs close enough ;-)), but it seems related to what's been reported in this thread. Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: timeout problems with certain APs and b43
On Friday, 23 of November 2007, Johannes Berg wrote: on certain APs, the internet works for a long time then stops, and I get authentication time outs, why? It usually works again if I reset the AP itself, which i should not have to do and don't have to if in XP wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:0f:66:53:3e:24 wlan0: authenticate with AP 00:0f:66:53:3e:24 wlan0: authenticate with AP 00:0f:66:53:3e:24 wlan0: authentication with AP 00:0f:66:53:3e:24 timed out Does it help to reload the b43 module? I think I have seen this problem before but always associated it with suspend/resume rather than a long time elapsing, I also thought it was due to bad power recalibration. It seems that I can reproduce something similar on demand with an SMC wireless router by moving my box sufficiently far away from it. :-) Well, yeah, that's expected though, you lose signal at some point. Not expected is that it happens without moving anything. Unless the calibration code is wrong which wouldn't really surprise me either. In my case, everything works just fine when the box is 6 meters away from the AP (including a thick wall in between), but when I move it another 5-6 meters away from the AP, things break down ... I'd expect it to work at longer distances, but well. :-) Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: timeout problems with certain APs and b43
On Friday, 23 of November 2007, Johannes Berg wrote: on certain APs, the internet works for a long time then stops, and I get authentication time outs, why? It usually works again if I reset the AP itself, which i should not have to do and don't have to if in XP wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:0f:66:53:3e:24 wlan0: authenticate with AP 00:0f:66:53:3e:24 wlan0: authenticate with AP 00:0f:66:53:3e:24 wlan0: authentication with AP 00:0f:66:53:3e:24 timed out Does it help to reload the b43 module? I think I have seen this problem before but always associated it with suspend/resume rather than a long time elapsing, I also thought it was due to bad power recalibration. It seems that I can reproduce something similar on demand with an SMC wireless router by moving my box sufficiently far away from it. :-) Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: schedule bcm43xx removal for 2.6.26 -- Re: [PATCH v3] remove bcm43xx
On Wednesday, 21 of November 2007, John W. Linville wrote: On Wed, Nov 21, 2007 at 12:26:48AM +0100, Rafael J. Wysocki wrote: On Tuesday, 20 of November 2007, Michael Buesch wrote: It is known for over a year now that b43 (aka bcm43xx-mac80211) is going to replace bcm43xx. And we already do a parrallel release cycle with both drivers included so people can switch. What else do you want? _First_, mark bcm43xx as unmaintained. Then, it's not your problem any more. Perhaps there's someone who'd be willing to maintain it. Otherwise, it will be dropped anyway after some time - when no one uses it any more. Still, it need not be (and IMHO it shouldn't be) your decision to drop it. It is probably true that we haven't communicated this very well outside the wireless team. We probably should have added bcm43xx to the feature removal schedule before the 2.6.24 merge window closed. How about if we mark bcm43xx as Obsolete in MAINTAINERS and add an entry to Documentation/feature-removal-schedule.txt with a When of 2.6.26? This is a very good idea IMO. I think that should give everyone sufficient notice...? Please also state very clearly in the changelog that you'd like to drop the driver entirely before 2.6.26. Thanks, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH v3] remove bcm43xx
On Tuesday, 20 of November 2007, Michael Buesch wrote: On Monday 19 November 2007 23:57:43 Rafael J. Wysocki wrote: Having both drivers in 2.6.24 should help find out if there's anything which should be ironed out with b43/b43legacy, but right now they are already working a lot better than bcm43xx, and they are more stable. So I couldn't find a reason why we shouldn't remove bcm43xx in 2.6.25. Many people use the old driver and you are forcing them to switch in a rather unfriendly fashion. Moreover, the switch generally involves a configuration change (on my system eth1 became wlan0) and is not _that_ seamless. IMvHO, the schedule of the removal of this driver should be discussed on LKML. Ok, so we are going to add Rafael J. Wysocki as the bcm43xx maintainer and remove everyone else. I'm OK with that. [That wasn't nice.] I'm not qualified to maintain that code, sorry. Apart from this, I've switched to b43. :-) It is known for over a year now that b43 (aka bcm43xx-mac80211) is going to replace bcm43xx. And we already do a parrallel release cycle with both drivers included so people can switch. What else do you want? _First_, mark bcm43xx as unmaintained. Then, it's not your problem any more. Perhaps there's someone who'd be willing to maintain it. Otherwise, it will be dropped anyway after some time - when no one uses it any more. Still, it need not be (and IMHO it shouldn't be) your decision to drop it. Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH v3] remove bcm43xx
On Monday, 19 of November 2007, Stefano Brivio wrote: On Mon, 19 Nov 2007 23:00:11 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: Well, are you 100% sure that everyone interested knows that this drivers is going out in 2.6.25 and no one will object? The maintainers know. I mean the users. Having both drivers in 2.6.24 should help find out if there's anything which should be ironed out with b43/b43legacy, but right now they are already working a lot better than bcm43xx, and they are more stable. So I couldn't find a reason why we shouldn't remove bcm43xx in 2.6.25. Many people use the old driver and you are forcing them to switch in a rather unfriendly fashion. Moreover, the switch generally involves a configuration change (on my system eth1 became wlan0) and is not _that_ seamless. IMvHO, the schedule of the removal of this driver should be discussed on LKML. Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH v3] remove bcm43xx
On Monday, 19 of November 2007, Andreas Schwab wrote: Stefano Brivio [EMAIL PROTECTED] writes: On Mon, 19 Nov 2007 23:00:11 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: Well, are you 100% sure that everyone interested knows that this drivers is going out in 2.6.25 and no one will object? The maintainers know. Having both drivers in 2.6.24 should help find out if there's anything which should be ironed out with b43/b43legacy, but right now they are already working a lot better than bcm43xx, and they are more stable. So I couldn't find a reason why we shouldn't remove bcm43xx in 2.6.25. b43 still does not work at all on ppc. Well, in that case for ppc users the removal of bcm43xx will be a regression. Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 on HP nx6325 w/ openSUSE 10.3 (x86_64)
On Tuesday, 6 of November 2007, Larry Finger wrote: Rafael J. Wysocki wrote: On Monday, 5 of November 2007, Larry Finger wrote: Rafael J. Wysocki wrote: Hi, I'm trying to make the b43 driver work on an HP nx6325 with openSUSE 10.3 (64-bit). In short, it sort of works, but some things are a bit ugly. The kernel is the current -git (approx. 2.6.24-rc1-git13) with the following extra patches applied: b43: Fix rfkill callback deadlock b43: debugfs SHM read buffer overrun fix b43: Rewrite and fix rfkill init and I'm using the firmware from http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 Here's the debug info from dmesg: b43-phy1: Broadcom 4311 WLAN found b43-phy1 debug: Found PHY: Analog 4, Type 2, Revision 8 b43-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 b43-phy1 debug: Loading firmware version 351.126 (2006-07-29 05:54:02) Registered led device: b43-phy1:tx Registered led device: b43-phy1:rx b43-phy1 debug: Chip initialized b43-phy1 debug: 32-bit DMA initialized b43-phy1 debug: Wireless interface started b43-phy1 debug: Adding Interface type 2 Now, the first problem is that the card seems to lose frames from time to time. This is visible in the output of mtr and while trying to transfer large files using scp. With scp the transfer just stalls and stays this way although the other end is pingable etc. (eg. attempting to transfer more than 400 MB at once triggers this 100% of the time). If you can suggest some more specific tests to me, I'll run them and report back. The second problem is that YaST is apparently unable to detect the device, which sort of sucks, because it leads to configuration problems (basically, you need to set up everything manually). Evidently, udev manages to handle it, so this may be related to HAL. Anyway, it looks like the problem is related to the fact that the device is not present under /sys/bus/pci/devices/ directly, but you need to go through the ssb0:0 subdirectory to get to it. Do you have any ideas how to tell the user space stuff where the devices is in sysfs? Your configuration is exactly like mine - openSUSE 10.3, x86_64 with Linus's latest git, and a 4311. I have not used mtr or scp and cannot comment on your transfer problems. That may be AP-related, but I had no such problems with the bcm43xx used previously on the same hardware w/ the same AP. I have had 0 problems configuring the device with YaST. Hm, I wonder what I've done wrong, then. :-) Can you send me /etc/sysconfig/network/ifcfg-wlan0 (or whatever the card is visible as on your system) from the x86_64 laptop? This config file is for WPA-PSK TKIP BOOTPROTO='dhcp' BROADCAST='' ETHTOOL_OPTIONS='' IFPLUGD_PRIORITY='10' IPADDR='' MTU='' NAME='Hewlett-Packard Company WLAN controller' NETMASK='' NETWORK='' REMOTE_IPADDR='' STARTMODE='ifplugd' USERCONTROL='yes' WIRELESS_AP='' WIRELESS_AUTH_MODE='psk' WIRELESS_BITRATE='auto' WIRELESS_CA_CERT='' WIRELESS_CHANNEL='' WIRELESS_CLIENT_CERT='' WIRELESS_CLIENT_KEY='' WIRELESS_CLIENT_KEY_PASSWORD='' WIRELESS_DEFAULT_KEY='0' WIRELESS_EAP_AUTH='' WIRELESS_EAP_MODE='' WIRELESS_ESSID='lwfdjf' WIRELESS_FREQUENCY='' WIRELESS_KEY='' WIRELESS_KEY_0='' WIRELESS_KEY_1='' WIRELESS_KEY_2='' WIRELESS_KEY_3='' WIRELESS_KEY_LENGTH='128' WIRELESS_MODE='Managed' WIRELESS_NICK='' WIRELESS_NWID='' WIRELESS_PEAP_VERSION='' WIRELESS_POWER='yes' WIRELESS_WPA_ANONID='' WIRELESS_WPA_IDENTITY='' WIRELESS_WPA_PASSWORD='' WIRELESS_WPA_PSK='My secret' Thanks! Well, it's similar to mine ... Anyway, I'm now running NetworkManager with b43 and it seems fine so far (except for the transfer problems described in the $subject message). Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 on HP nx6325 w/ openSUSE 10.3 (x86_64)
On Monday, 5 of November 2007, Larry Finger wrote: Rafael J. Wysocki wrote: Hi, I'm trying to make the b43 driver work on an HP nx6325 with openSUSE 10.3 (64-bit). In short, it sort of works, but some things are a bit ugly. The kernel is the current -git (approx. 2.6.24-rc1-git13) with the following extra patches applied: b43: Fix rfkill callback deadlock b43: debugfs SHM read buffer overrun fix b43: Rewrite and fix rfkill init and I'm using the firmware from http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 Here's the debug info from dmesg: b43-phy1: Broadcom 4311 WLAN found b43-phy1 debug: Found PHY: Analog 4, Type 2, Revision 8 b43-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 b43-phy1 debug: Loading firmware version 351.126 (2006-07-29 05:54:02) Registered led device: b43-phy1:tx Registered led device: b43-phy1:rx b43-phy1 debug: Chip initialized b43-phy1 debug: 32-bit DMA initialized b43-phy1 debug: Wireless interface started b43-phy1 debug: Adding Interface type 2 Now, the first problem is that the card seems to lose frames from time to time. This is visible in the output of mtr and while trying to transfer large files using scp. With scp the transfer just stalls and stays this way although the other end is pingable etc. (eg. attempting to transfer more than 400 MB at once triggers this 100% of the time). If you can suggest some more specific tests to me, I'll run them and report back. The second problem is that YaST is apparently unable to detect the device, which sort of sucks, because it leads to configuration problems (basically, you need to set up everything manually). Evidently, udev manages to handle it, so this may be related to HAL. Anyway, it looks like the problem is related to the fact that the device is not present under /sys/bus/pci/devices/ directly, but you need to go through the ssb0:0 subdirectory to get to it. Do you have any ideas how to tell the user space stuff where the devices is in sysfs? Your configuration is exactly like mine - openSUSE 10.3, x86_64 with Linus's latest git, and a 4311. I have not used mtr or scp and cannot comment on your transfer problems. That may be AP-related, but I had no such problems with the bcm43xx used previously on the same hardware w/ the same AP. I have had 0 problems configuring the device with YaST. Hm, I wonder what I've done wrong, then. :-) Can you send me /etc/sysconfig/network/ifcfg-wlan0 (or whatever the card is visible as on your system) from the x86_64 laptop? On the x86_64 laptop, I let NetworkManager control the wireless connection, but I have also used the traditional ifup/ifdown method. On an i386 system, I use ifup/ifdown as I don't run X on that machine. Both make fast connections. Well, finally I did configure the card with YaST, but I had to manually add it to the list. ifup/ifdown works, but I haven't tried NetworkManager yet. Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
b43 on HP nx6325 w/ openSUSE 10.3 (x86_64)
Hi, I'm trying to make the b43 driver work on an HP nx6325 with openSUSE 10.3 (64-bit). In short, it sort of works, but some things are a bit ugly. The kernel is the current -git (approx. 2.6.24-rc1-git13) with the following extra patches applied: b43: Fix rfkill callback deadlock b43: debugfs SHM read buffer overrun fix b43: Rewrite and fix rfkill init and I'm using the firmware from http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 Here's the debug info from dmesg: b43-phy1: Broadcom 4311 WLAN found b43-phy1 debug: Found PHY: Analog 4, Type 2, Revision 8 b43-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 b43-phy1 debug: Loading firmware version 351.126 (2006-07-29 05:54:02) Registered led device: b43-phy1:tx Registered led device: b43-phy1:rx b43-phy1 debug: Chip initialized b43-phy1 debug: 32-bit DMA initialized b43-phy1 debug: Wireless interface started b43-phy1 debug: Adding Interface type 2 Now, the first problem is that the card seems to lose frames from time to time. This is visible in the output of mtr and while trying to transfer large files using scp. With scp the transfer just stalls and stays this way although the other end is pingable etc. (eg. attempting to transfer more than 400 MB at once triggers this 100% of the time). If you can suggest some more specific tests to me, I'll run them and report back. The second problem is that YaST is apparently unable to detect the device, which sort of sucks, because it leads to configuration problems (basically, you need to set up everything manually). Evidently, udev manages to handle it, so this may be related to HAL. Anyway, it looks like the problem is related to the fact that the device is not present under /sys/bus/pci/devices/ directly, but you need to go through the ssb0:0 subdirectory to get to it. Do you have any ideas how to tell the user space stuff where the devices is in sysfs? Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: How to prevent bcm43xx from switching bit rate
On Wednesday, 9 May 2007 07:35, Larry Finger wrote: Rafael J. Wysocki wrote: Hi, Is there any way to force bcm43xx to use specific bit rate (eg. 11 M)? On my box it tends to automatically switch to 24 M, even if I do # iwconfig eth1 rate 11M fixed If you use git, reverting commit bb52a653eaef4aee877b2fa36de8699926f788bd will make your interface always use 11 Mbs. In case you don't use git, this patch was the following: Thanks, but I generally use 24 M. It only doesn't work well with *some* access points in which cases I use the above command to set 11 M bit rate. Still, the card/driver switches back to 24 M after some time and I have to repeat it, which is sort of tedious. I thought it would be possible to get rid of this without patching the kernel. ;-) Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: How to prevent bcm43xx from switching bit rate
On Wednesday, 9 May 2007 16:24, Johannes Berg wrote: Hi Rafael, On my box it tends to automatically switch to 24 M, even if I do (*) # iwconfig eth1 rate 11M fixed That's strange. softmac ought to start at 24M now, and it ignores the fixed flag since it always uses a fixed bitrate. Did this change some time? Actually, it may automatically reset the bitrate when you associate to a new network, and I don't think you can stop it from doing that right now, precisely because it ignores the fixed flag. Well, it works like this: - I associate with an AP at 11 M - After some time, the bit rate changes to 24 M - So I use (*) to set it back to 11 M (and iwconfig prints 11 M pronto) - After some time, the bit rate changes to 24 M - etc. This is all the same AP all the time. Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
How to prevent bcm43xx from switching bit rate
Hi, Is there any way to force bcm43xx to use specific bit rate (eg. 11 M)? On my box it tends to automatically switch to 24 M, even if I do # iwconfig eth1 rate 11M fixed Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] bcm43xx-mac80211: Work around 30bit DMA limitation
On Thursday, 29 March 2007 00:16, Larry Finger wrote: Michael Buesch wrote: On Wednesday 28 March 2007 23:43, Larry Finger wrote: As a result, every driver for hardware with less than 32-bit DMA addressing has to address (pun intended) the problem. We will probably be fighting the problem again when 4 GB RAM computers become common and 32 bits are not enough to address all of memory. Nope, see Johannes' mail. Yes, if an IOMMU is included, but why don't we have them now on our 64-bit processors? Don't we? I thought all 64bit machines that support 4G Ram do have an IOMMU. My AMD Turion 64 X2 processor can address more than 4 GB RAM, but AMD's IOMMU has not yet been released. Er, are you sure? AFAIR all of the K8 CPUs have something called GART IOMMU, which is not a real IOMMU, but still it can do its job (to a limited extent, though). Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix loss of association after resume
On Wednesday, 14 February 2007 22:43, Michael Buesch wrote: On Wednesday 14 February 2007 17:29, Larry Finger wrote: And no, it is not correct to just call attach_board from resume. ;) Instead you must copy (or probably move) the HW init stuff that is in the attach step to the init step. I have done that in my tree in bcm43xx-d80211. Not easy to refactor without introducing bugs. Definately _not_ a patch for next -stable kernel. ;) After looking through your code, I agree that it is not -stable material. It would be drastic, but we could call remove_one on suspend and init_one on resume. Userland might get excited about the interface disappearing and reappearing, but it should work. Any thoughts? Yes, exactly. The problem would be that we redo all the data structures, too. If you want, create a patch to test if it works. But I really don't want to have something like that in the kernel tree, because it's worse behaviour in the common suspend-to-ram case. Userspace is confused by it. The supplicant for instance might, too, and might be unable to reassociate. But I don't know for sure. I think the current behavior is acceptable if the driver generally works with the STR. The STR is more important to us than the STD these days. :-) It may be possible to make it work after the resume from disk too if it's loaded before reading the image, for example. I have to carry out some more tests and debug it a bit more, but that will take some time (obviously). Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix loss of association after resume
On Thursday, 15 February 2007 00:01, Michael Buesch wrote: On Wednesday 14 February 2007 22:53, Rafael J. Wysocki wrote: I think the current behavior is acceptable if the driver generally works with the STR. The STR is more important to us than the STD these days. :-) It may be possible to make it work after the resume from disk too if it's loaded before reading the image, for example. I have to carry out some more tests and debug it a bit more, but that will Well, the easiest workaround is simply reloading bcm43xx by the hibernate scripts. I think people could live with that for now. Yes, I do exactly this. It's not really troublesome. I only sometimes need to switch NetworkManager to the offline and back to the online mode afterwards so that it shows the wireless networks. Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix loss of association after resume
On Tuesday, 13 February 2007 00:24, Michael Buesch wrote: On Tuesday 13 February 2007 00:08, Rafael J. Wysocki wrote: On Monday, 12 February 2007 23:20, Larry Finger wrote: Rafael J. Wysocki wrote: On Monday, 12 February 2007 02:18, Larry Finger wrote: Rafael J. Wysocki wrote: It doesn't help in my case. The behavior is similar to that without the patch, but also with the patch it loses the association entirely. Thanks for trying. Do you have this patch installed? If you do, please try increasing the 100 to 200. Hm, but it wouldn't help to get the microcode to respond after the resume ... Yes it would. That count is how long the system waits for the firmware to respond. I'm still thinking the problem is with the firmware. Where exactly is it stored? In the memory of the microprocessor on the card. Please do what I asked. With or without the previous patch? Both, please. It doesn't help in either case. I get albercik:~ # ifconfig eth1 down albercik:~ # ifconfig eth1 up SIOCSIFFLAGS: No such device in both cases. I think the problem is that the firmware is not present and requesting it doesn't work for some reason. Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix loss of association after resume
On Tuesday, 13 February 2007 18:02, Larry Finger wrote: Rafael J. Wysocki wrote: On Tuesday, 13 February 2007 00:24, Michael Buesch wrote: On Tuesday 13 February 2007 00:08, Rafael J. Wysocki wrote: On Monday, 12 February 2007 23:20, Larry Finger wrote: Rafael J. Wysocki wrote: On Monday, 12 February 2007 02:18, Larry Finger wrote: Rafael J. Wysocki wrote: It doesn't help in my case. The behavior is similar to that without the patch, but also with the patch it loses the association entirely. Thanks for trying. Do you have this patch installed? If you do, please try increasing the 100 to 200. Hm, but it wouldn't help to get the microcode to respond after the resume ... Yes it would. That count is how long the system waits for the firmware to respond. I'm still thinking the problem is with the firmware. Where exactly is it stored? In the memory of the microprocessor on the card. Please do what I asked. With or without the previous patch? Both, please. It doesn't help in either case. I get albercik:~ # ifconfig eth1 down albercik:~ # ifconfig eth1 up SIOCSIFFLAGS: No such device in both cases. I think the problem is that the firmware is not present and requesting it doesn't work for some reason. PLEASE SEND OUTPUT FROM dmesg! Okay, okay. The first one (dmesg.log.gz) is for the driver with bcm43xx_request_firmware(bcm) in bcm43xx_resume(). The other one is for the driver without it. BCM43xx_IRQWAIT_MAX_RETRIES was set to 100 in both cases. Greetings, Rafael dmesg.log.gz Description: GNU Zip compressed data dmesg-2.log.gz Description: GNU Zip compressed data ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix loss of association after resume
On Tuesday, 13 February 2007 22:54, Michael Buesch wrote: Did you already try my tree? I fixed resume there by completely reinitializing the device on resume. No, I didn't. So far I've had no time to set up a git tree on my box. I'll try when I finally do it (but probably not any time soon ;-)). Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix loss of association after resume
On Monday, 12 February 2007 23:20, Larry Finger wrote: Rafael J. Wysocki wrote: On Monday, 12 February 2007 02:18, Larry Finger wrote: Rafael J. Wysocki wrote: It doesn't help in my case. The behavior is similar to that without the patch, but also with the patch it loses the association entirely. Thanks for trying. Do you have this patch installed? If you do, please try increasing the 100 to 200. Hm, but it wouldn't help to get the microcode to respond after the resume ... Yes it would. That count is how long the system waits for the firmware to respond. I'm still thinking the problem is with the firmware. Where exactly is it stored? In the memory of the microprocessor on the card. Please do what I asked. With or without the previous patch? Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix loss of association after resume
On Saturday, 10 February 2007 21:33, Larry Finger wrote: Rafael, Rafael J. Wysocki wrote: I'm running with this patch applied right now, but the association is lost after the resume anyway. I have to reload bcm43xx to make it associate with the AP again (no big deal). Please send me the output of iwconfig and ifconfig after the resume, but before you reload bcm43xx. albercik:~ # iwconfig lono wireless extensions. eth0 no wireless extensions. eth1 IEEE 802.11b/g ESSID:DI524 Nickname:Broadcom 4311 Mode:Managed Frequency=2.484 GHz Access Point: Invalid Bit Rate=1 Mb/s Tx-Power=18 dBm RTS thr:off Fragment thr:off Encryption key:off Link Quality=0/100 Signal level=-256 dBm Noise level=-256 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 albercik:~ # ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:14:A5:BE:95:31 inet addr:192.168.100.101 Bcast:192.168.100.255 Mask:255.255.255.0 inet6 addr: fe80::214:a5ff:febe:9531/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:5137 errors:0 dropped:120 overruns:0 frame:0 TX packets:5703 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4569090 (4.3 Mb) TX bytes:156826797 (149.5 Mb) Interrupt:18 albercik:~ # ifconfig eth1 down albercik:~ # ifconfig eth1 up SIOCSIFFLAGS: No such device Reloading the driver helps. ;-) Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix loss of association after resume
On Sunday, 11 February 2007 14:07, Michael Buesch wrote: On Sunday 11 February 2007 13:56, Rafael J. Wysocki wrote: On Saturday, 10 February 2007 21:33, Larry Finger wrote: Rafael, Rafael J. Wysocki wrote: I'm running with this patch applied right now, but the association is lost after the resume anyway. I have to reload bcm43xx to make it associate with the AP again (no big deal). Please send me the output of iwconfig and ifconfig after the resume, but before you reload bcm43xx. albercik:~ # iwconfig lono wireless extensions. eth0 no wireless extensions. eth1 IEEE 802.11b/g ESSID:DI524 Nickname:Broadcom 4311 Mode:Managed Frequency=2.484 GHz Access Point: Invalid Bit Rate=1 Mb/s Tx-Power=18 dBm RTS thr:off Fragment thr:off Encryption key:off Link Quality=0/100 Signal level=-256 dBm Noise level=-256 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 albercik:~ # ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:14:A5:BE:95:31 inet addr:192.168.100.101 Bcast:192.168.100.255 Mask:255.255.255.0 inet6 addr: fe80::214:a5ff:febe:9531/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:5137 errors:0 dropped:120 overruns:0 frame:0 TX packets:5703 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4569090 (4.3 Mb) TX bytes:156826797 (149.5 Mb) Interrupt:18 albercik:~ # ifconfig eth1 down albercik:~ # ifconfig eth1 up SIOCSIFFLAGS: No such device ^ I'd like to see dmesg, please. Appended. It covers one suspend-resume cycle (suspend to disk). I have filtered HID-related messages out of it. Greetings, Rafael ton.000e = 0 usb 3-1: usb auto-resume ohci_hcd :00:13.1: GetStatus roothub.portstatus [0] = 0x00040103 PSSC PPS PES CCS usb 3-1: finish resume usb usb1: usb auto-resume usb usb1: finish resume hub 1-0:1.0: hub_resume ehci_hcd :00:13.2: resume root hub hub 1-0:1.0: state 7 ports 8 chg evt usb 3-1: usb auto-suspend hub 1-0:1.0: hub_suspend usb usb1: usb auto-suspend PM: Adding info for No Bus:vcs8 PM: Adding info for No Bus:vcsa8 SoftMAC: Scanning finished: scanned 14 channels starting with channel 1 Stopping tasks ... done. Shrinking memory... -\|/-\|/-\done (113015 pages freed) Freed 452060 kbytes in 1.44 seconds (313.93 MB/s) Suspending console(s) usbhid 3-4:1.0: freeze usb 3-4: freeze usbhid 3-4:1.0: suspend usb 3-4: usb suspend usbdev3.18: PM: suspend 0-1, parent 3-1 already 2 usbdev3.18_ep02: PM: suspend 0-1, parent 3-1:1.0 already 2 usbdev3.18_ep81: PM: suspend 0-1, parent 3-1:1.0 already 2 usb 3-1:1.0: PM: suspend 2--1 usb 3-1:1.0: PM: suspend 2-1, parent 3-1 already 2 usbdev3.18_ep00: PM: suspend 0-1, parent 3-1 already 2 usb 3-1: PM: suspend 2--1 usb 2-2:1.3: freeze usb 2-2:1.2: freeze hci_usb 2-2:1.1: freeze hci_usb 2-2:1.0: freeze usb 2-2: freeze usb 2-2: usb suspend serio serio6: freeze platform bluetooth: freeze hub 3-0:1.0: freeze usb usb3: freeze hub 3-0:1.0: hub_suspend ohci_hcd :00:13.1: suspend root hub usb usb3: usb suspend hub 2-0:1.0: freeze usb usb2: freeze hub 2-0:1.0: hub_suspend ohci_hcd :00:13.0: suspend root hub usb usb2: usb suspend usbdev1.1: PM: suspend 0-1, parent usb1 already 2 usbdev1.1_ep81: PM: suspend 0-1, parent 1-0:1.0 already 2 hub 1-0:1.0: PM: suspend 2--1 hub 1-0:1.0: PM: suspend 2-1, parent usb1 already 2 usbdev1.1_ep00: PM: suspend 0-1, parent usb1 already 2 usb usb1: PM: suspend 2--1 ide-cdrom 0.0: freeze psmouse serio4: freeze serio serio3: freeze serio serio2: freeze serio serio1: freeze atkbd serio0: freeze i8042 i8042: freeze sd 0:0:0:0: freeze serial8250 serial8250: freeze vesafb vesafb.0: freeze pci_express :00:06.0:pcie03: freeze pci_express :00:06.0:pcie01: freeze pci_express :00:06.0:pcie00: freeze pci_express :00:05.0:pcie03: freeze pci_express :00:05.0:pcie01: freeze pci_express :00:05.0:pcie00: freeze pci_express :00:04.0:pcie03: freeze pci_express :00:04.0:pcie01: freeze pci_express :00:04.0:pcie00: freeze pcspkr pcspkr: freeze sdhci :02:04.3: freeze ACPI: PCI interrupt for device :02:04.3 disabled tifm_7xx1 :02:04.2: freeze ACPI: PCI interrupt for device :02:04.2 disabled ohci1394 :02:04.1: freeze ohci1394 does not fully support suspend and resume yet ieee1394: hpsb_bus_reset called while bus reset already in progress yenta_cardbus :02:04.0: freeze tg3 :02:01.0: freeze PM: Writing back config space on device :02:01.0 at offset b (was 3ed173b, writing 30b0103c) PM: Writing back config space on device :02:01.0 at offset 3 (was 0, writing 4010) PM: Writing back config space on device :02:01.0 at offset
Re: [PATCH] bcm43xx: Fix loss of association after resume
On Sunday, 11 February 2007 16:59, Larry Finger wrote: Michael Buesch wrote: On Sunday 11 February 2007 15:02, Rafael J. Wysocki wrote: PM: Removing info for No Bus::30:00.0 bcm43xx: IRQ_READY timeout bcm43xx: core_up for active 802.11 core failed (-19) I never tried suspend to disk with the driver. This implies that suspend to RAM works. Is that true? Larry, an idea why the microcode doesn't respond? Is this code snippet supposed to keep the firmware loaded when the system is suspended? bcm-firmware_norelease = 1; bcm43xx_free_board(bcm); bcm-firmware_norelease = 0; If so, that may be the problem. What would force it to be reloaded when resuming after a suspend to disk and subsequent power off? That would certainly explain why a reload is successful. Is there a volatile location that would safely indicate that the firmware is not good? Perhaps, we need to bite the bullet and reload the firmware after every resume. The patch below should do that. I am also working on a case where the user has troubles with a suspend to disk from Windows followed by a reboot to Linux, and warm reboots from Windows to Linux. In these cases, he gets a firmware file-format error; however, his firmware is fine from a cold boot. Larry Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c === --- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c +++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c @@ -4296,6 +4297,7 @@ static int bcm43xx_resume(struct pci_dev printk(KERN_ERR PFX Resume failed!\n); return err; } + bcm43xx_request_firmware(bcm); netif_device_attach(net_dev); dprintk(KERN_INFO PFX Device resumed.\n); It doesn't help in my case. The behavior is similar to that without the patch, but also with the patch it loses the association entirely. Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix loss of association after resume
On Friday, 9 February 2007 17:53, Michael Buesch wrote: On Friday 09 February 2007 17:18, Larry Finger wrote: After a suspend/resume cycle, bcm43xx-softmac has lost its association with the AP and requires manual intervention. This situation is fixed by making one of softmac's internal routines public and calling it. Signed-off-by: Larry Finger [EMAIL PROTECTED] Ack, this is good as workaround. I'm running with this patch applied right now, but the association is lost after the resume anyway. I have to reload bcm43xx to make it associate with the AP again (no big deal). Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Change SoftMAC to initialize to high rates
On Thursday, 8 February 2007 18:31, Larry Finger wrote:
There is a bug in SoftMAC that initializes data rates for all devices to 11
Mbs. Now that many of
the devices will actually run at higher rates, this patch fixes that bug.
As not all chips will run at speeds above 11 Mbs, I will not be sending this
patch upstream to
Linville, but I wanted it available for the users. As you see, I'm setting a
rate of 24 Mbs. If your
card works at 36, please change that line.
Hm, may I suggest the appended patch instead? ;-)
Rafael
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
net/ieee80211/softmac/ieee80211softmac_module.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
Index: linux-2.6.20/net/ieee80211/softmac/ieee80211softmac_module.c
===
--- linux-2.6.20.orig/net/ieee80211/softmac/ieee80211softmac_module.c
+++ linux-2.6.20/net/ieee80211/softmac/ieee80211softmac_module.c
@@ -270,12 +270,13 @@ void ieee80211softmac_init_bss(struct ie
can manually change it if they really need to, but 11M is
more reliable. Note similar logic in
ieee80211softmac_wx_set_rate() */
- if (ieee-modulation IEEE80211_CCK_MODULATION) {
+ if (ieee-modulation IEEE80211_OFDM_MODULATION) {
+ txrates-user_rate = IEEE80211_OFDM_RATE_24MB;
+ } else if (ieee-modulation IEEE80211_CCK_MODULATION) {
txrates-user_rate = IEEE80211_CCK_RATE_11MB;
- } else if (ieee-modulation IEEE80211_OFDM_MODULATION) {
- txrates-user_rate = IEEE80211_OFDM_RATE_54MB;
- } else
+ } else {
assert(0);
+ }
txrates-default_rate = IEEE80211_CCK_RATE_1MB;
change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT;
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix for oops on resume
On Wednesday, 7 February 2007 14:23, Larry Finger wrote: Johannes Berg wrote: On Tue, 2007-02-06 at 11:39 -0600, Larry Finger wrote: There is a kernel oops on bcm43xx when resuming due to an overly tight timeout loop. Come to think of it... Is there any chance of fixing the actual oops that happens in this case? I can imagine broken hardware or firmware that causes this as well and we don't really want to oops in that case either... That's why we have the timeout in the first place, to not hang there forever. Nothing against this patch though. As you suggested earlier, a slow clock setting in the bcm43xx device may be the cause of this difficulty. If my laptop would suspend/resume correctly, then I could test various fixes based on that hypothesis. Since it does not, I think the band-aid approach is warranted. A proper fix is still on my agenda; however, getting full data rates still has priority. BTW, have you tried to suspend to disk or to RAM only? Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: RFT: The real fix for BCM4311 and BCM4312
On Thursday, 8 February 2007 02:17, Larry Finger wrote: Jochen Puchalla wrote: this sounds wonderful! However, I applied this patch and radio_enable_2.6.20 to my 2.6.20-rc7 on an HP nx6325 (I know you have one as well), but still I only get 100kB/s at 1M 2M 5.5M and 11M. Do I need the combined-patch for 2.6.20? I only have 1GB RAM and don't do suspends, so I don't think so. Jochen, My laptop is an HP dv2125nr, but it has a BCM4311 with the same revisions as yours. I don't understand why your system doesn't show the improvement. The combined patch also includes the code for handling the rf switch correctly. It shouldn't be needed, but please try a kernel with the combined patch for 2.6.20 and either one of the patches from yesterday - the _GOOD_ news faulty one or the one that followed. Well, my box is an nx6325 too and it _does_ show the improvement. The patches I use are available at http://www.sisk.pl/kernel/patches/2.6.20/ (of course only the bcm43xx-* are relevant). Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed measurement and stability issues
On Thursday, 8 February 2007 01:10, Larry Finger wrote: Fernando Toledo wrote: Pavel Roskin escribió: rate: iperf reports: 1 928 Kbits/sec 2 1.69 Mbits/sec 5.53.92 Mbits/sec 6 4.78 Mbits/sec 9 6.55 Mbits/sec 11 5.97 Mbits/sec 12 8.18 Mbits/sec 18 10.4 Mbits/sec 24 13.0 Mbits/sec 36 15.1 Mbits/sec 48 187 Kbits/sec 54 N/A testing at 11Mb i have same aprox. value that Pavel. it was a REally_GOOD_news for me :) My results are: rate 4311 rate 4318 rate = 11M 6.50 Mbs6.34 Mbs 18M 10.4 Mbs6.98 Mbs 24M 12.3 Mbs7.61 Mbs 36M 15.0 Mbs8.22 Mbs 48M 4.76 Mbs8.05 Mbs 54M Failed 7.82 Mbs I get the best results at 24M, 15 Mb/s according to gkrellm. 36M is much worse and when I switch directly from 11M to 36M the rate drops to 1-2 Mb/s. Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Success with 4311 on HPC nx6325
On Monday, 5 February 2007 04:20, Larry Finger wrote: Rafael J. Wysocki wrote: On Saturday, 3 February 2007 23:30, Rafael J. Wysocki wrote: On Saturday, 3 February 2007 02:03, Larry Finger wrote: Rafael J. Wysocki wrote: Hi, Some good news here. :-) I've finally managed to make the 4311 in my nx6325 work. Well, it turns out that new D-Link routers (at least DI-524 and DI-624) are recognized by it (still older ones are not). The transfer rates are rather low (20 - 25 KB/s downstream), but sufficient for reading e-mail and web browsing. ;-) Contrary to logic, if you set your rate to 1M, you will get better throughput. Copying a file across my internal network with the rate set at 1M, I get 81 KB/s upload and 66 on download. Both are close to the expected maximum rate ( 1M bits/sec / 8 bits/byte / 2 (approximate overhead). Ah, thanks for the hint. With the rate set to 1M I get similar results. BTW, is there any way to tell NetworkManager to use 1M by default? Not to my knowledge, but I cc'd Dan Williams. He'll know if anyone does. Okay, so perhaps I can hack the driver to use 1M by default? Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Success with 4311 on HPC nx6325
On Monday, 5 February 2007 16:32, Larry Finger wrote: Rafael J. Wysocki wrote: Okay, so perhaps I can hack the driver to use 1M by default? This patch will do it. Thanks a lot! In the meantime I wrote a small bash script that fixed the bit rate to 1M (attached) and put it in /etc/sysconfig/network/if-up.d/ (I use OpenSUSE 10.2). [The ping part is there because my bcm43xx doesn't come up immediately, but only after several packets have been sent through it.] Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King set-bit-rate-for-wireless Description: application/shellscript ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Success with 4311 on HPC nx6325
On Saturday, 3 February 2007 23:30, Rafael J. Wysocki wrote: On Saturday, 3 February 2007 02:03, Larry Finger wrote: Rafael J. Wysocki wrote: Hi, Some good news here. :-) I've finally managed to make the 4311 in my nx6325 work. Well, it turns out that new D-Link routers (at least DI-524 and DI-624) are recognized by it (still older ones are not). The transfer rates are rather low (20 - 25 KB/s downstream), but sufficient for reading e-mail and web browsing. ;-) Contrary to logic, if you set your rate to 1M, you will get better throughput. Copying a file across my internal network with the rate set at 1M, I get 81 KB/s upload and 66 on download. Both are close to the expected maximum rate ( 1M bits/sec / 8 bits/byte / 2 (approximate overhead). Ah, thanks for the hint. With the rate set to 1M I get similar results. BTW, is there any way to tell NetworkManager to use 1M by default? Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Bcm43xx oops after suspend to disk
On Sunday, 4 February 2007 18:42, Larry Finger wrote: roucaries bastien wrote: Sorry for the delay it works. This time I can use iwlist eth scan. I have some difficulties to associate and I need to rmmod/modprobe in order to associate but it is another problem linked to a really weak power. Bastien, Please try this patch instead. Hm, it doesn't seem to apply to the mainline version of the driver. Any chance for a fix against 2.6.20? Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Success with 4311 on HPC nx6325
On Saturday, 3 February 2007 02:03, Larry Finger wrote: Rafael J. Wysocki wrote: Hi, Some good news here. :-) I've finally managed to make the 4311 in my nx6325 work. Well, it turns out that new D-Link routers (at least DI-524 and DI-624) are recognized by it (still older ones are not). The transfer rates are rather low (20 - 25 KB/s downstream), but sufficient for reading e-mail and web browsing. ;-) Contrary to logic, if you set your rate to 1M, you will get better throughput. Copying a file across my internal network with the rate set at 1M, I get 81 KB/s upload and 66 on download. Both are close to the expected maximum rate ( 1M bits/sec / 8 bits/byte / 2 (approximate overhead). Ah, thanks for the hint. With the rate set to 1M I get similar results. Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Success with 4311 on HPC nx6325
On Saturday, 3 February 2007 01:03, Fernando Toledo wrote: Rafael J. Wysocki escribió: Hi, Some good news here. :-) I've finally managed to make the 4311 in my nx6325 work. Well, it turns out that new D-Link routers (at least DI-524 and DI-624) are recognized by it (still older ones are not). The transfer rates are rather low (20 - 25 KB/s downstream), but sufficient for reading e-mail and web browsing. ;-) Thanks, Rafael hi Rafael, can you tell me what versions of kernel and patches are using you? 2.6.20-rc7 with the radio_enable_2.6.20 patch from Larry plus some other patches that should not matter (full series at http://www.sisk.pl/kernel/patches/2.6.20-rc7/). i can use my 4311 to connect to several AP's, but i still can't connect to my dlink AP. There are some D-Link APs I can't connect to, but they are older ones (like DI-624+). Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Another strange thing with the driver
On Thursday, 1 February 2007 22:56, Larry Finger wrote:
Igor Korot wrote:
Hi, guys,
I just did a little test yesterday, and today.
The problem below occur when on the dual-boot laptop, you boot Windows
first, suspend it to disk, then boot Linux.
I have a Dell Inspiron E1505 with WinXP and Gentoo installed.
And this is exactly what happened.
If you then re-boot Linux (Gentoo, in my case), and will try to bring the
interface up, it will run without any problems.
I don't know what is happenning after hibernating the XP, and booting
Linux, and why the interface is up after re-booting Linux, but that the
story behind this problem.
Larry, will Kismet out help to track this one as well?
It might. I'm not sure what is happening. At least you will know if the
interface is broadcasting.
Thank you.
Hi, Larry,
I found another strange thing with the driver.
I was able to successfully establish the connection using wireless tools.
I just installed wpa_supplicant, and here is what happened:
IgorsGentooOnNetwork igor # ifconfig eth1 up
SIOCSIFFLAGS: Protocol error
Looking at dmesg, I found that the problem is in the firmware:
bcm43xx: PHY connected
bcm43xx: Microcode rev 0x127, pl 0xe (2005-04-18 02:36:27)
bcm43xx: InitVals (bcm43xx_initvalXX.fw) file-format error. Please fix your
bcm43xx firmware files.
bcm43xx: core_up for active 802.11 core failed (-71)
Here is my /etc/conf.d/net
# This blank configuration will automatically use DHCP for any net.*
# scripts in /etc/init.d. To create a more complete configuration,
# please review /etc/conf.d/net.example and save your configuration
# in /etc/conf.d/net (this file :]!).
#Wireless-tools
#nis_domain_lo=IgorsGentoo
#modules=(iwconfig)
#key_ESSID1=[1] s:IgorsNetwork key [1] enc open
#key_ESSID2=[1] ---dd key [1] enc estricted
#preferred_aps=(ESSID1 ESSID2)
#Wpa_supplicant
modules=( wpa_supplicant )
wpa_supplicant_eth1=-Dbcm43xx
Here is my /etc/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
ap_scan=1
network={
ssid=IgorsNetwork
psk=abcdef
priority=5
}
Do I need to re-install the firmware going from wireless tools to
wpa_supplicant?
Not usually. It looks as if your firmware got corrupted.
BTW, can anyone please point me to a file containing the firmware that's
known to work with the 4311 and can be extracted by fwcutter?
Greetings,
Rafael
--
If you don't have the time to read,
you don't have the time or the tools to write.
- Stephen King
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Need testing help
On Wednesday, 31 January 2007 17:04, Michael Buesch wrote: I need some real-life data to estimate what the ITSSI value usually is on different cards. (ITSSI is called savedpctlreg in softmac driver). Please run this patch on your machine, bring up the interface and send dmesg back to me. Thanks. This is from Linux-2.6.20-rc7 (x86_64) on HPC nx6325: bcm43xx driver ACPI: PCI Interrupt :30:00.0[A] - GSI 18 (level, low) - IRQ 18 PCI: Setting latency timer of device :30:00.0 to 64 bcm43xx: Chip ID 0x4311, rev 0x1 bcm43xx: Number of cores: 4 bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243 bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243 bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243 bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243 bcm43xx: PHY connected bcm43xx: Detected PHY: Version: 4, Type 2, Revision 8 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) bcm43xx: Radio turned off bcm43xx: Radio turned off printk: 3 messages suppressed. SoftMAC: ASSERTION FAILED (0) at: net/ieee80211/softmac/ieee80211softmac_wx.c:30 6:ieee80211softmac_wx_get_rate() SoftMAC: ASSERTION FAILED (0) at: net/ieee80211/softmac/ieee80211softmac_wx.c:306:ieee80211softmac_wx_get_rate() SoftMAC: ASSERTION FAILED (0) at: net/ieee80211/softmac/ieee80211softmac_wx.c:306:ieee80211softmac_wx_get_rate() bcm43xx: PHY connected PM: Adding info for No Bus::30:00.0 PM: Removing info for No Bus::30:00.0 PM: Adding info for No Bus::30:00.0 PM: Removing info for No Bus::30:00.0 PM: Adding info for No Bus::30:00.0 PM: Removing info for No Bus::30:00.0 PM: Adding info for No Bus::30:00.0 PM: Removing info for No Bus::30:00.0 bcm43xx: Microcode rev 0x127, pl 0xe (2005-04-18 02:36:27) bcm43xx: Radio turned on bcm43xx: Radio enabled by hardware savedpctlreg == 52 bcm43xx: Chip initialized bcm43xx: 32-bit DMA initialized bcm43xx: Keys cleared bcm43xx: Selected 802.11 core (phytype 2) lspci -v says: 30:00.0 Network controller: Broadcom Corporation BCM4310 UART (rev 01) Subsystem: Hewlett-Packard Company Unknown device 1361 Flags: bus master, fast devsel, latency 0, IRQ 18 Memory at c800 (32-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 2 Capabilities: [58] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- Capabilities: [d0] Express Legacy Endpoint IRQ 0 Capabilities: [100] Advanced Error Reporting Capabilities: [13c] Virtual Channel Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
bcm43xx on HPC nx6325 - partial success
Hi, First, thanks a lot for your work on the driver. Now, my observations: With the patch from https://lists.berlios.de/pipermail/bcm43xx-dev/2007-January/003484.html and the patch radio_enable_2.6.20 from ftp://lwfinger.dynalias.org/patches on top of 2.6.20-rc5 (x86_64), the bcm4311 card in my HPC nx6325 partially works (I use the ieee80211softmac version of the driver). Namely, everything seems to be going on well and and interrupts are coming, I can run iwlist eth2 scan and it reports something like the following: eth2 Scan completed : Cell 01 - Address: 00:13:46:85:46:F9 ESSID:[edited] Protocol:IEEE 802.11bg Mode:Master Channel:6 Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Quality=82/100 Signal level=-71 dBm Noise level=-68 dBm IE: WPA Version 1 Group Cipher : WEP-40 Pairwise Ciphers (2) : WEP-40 TKIP Authentication Suites (1) : PSK Extra: Last beacon: 280ms ago but strangely enough this is someone else's access point, not mine. My access point is a D-Link DI-624+ router, with different ESSID and different MAC. It stands just next to my machine and yet it is not detected (it is detected by my second maching with bcm4306, though, and works with it). Also, the interface is not automatically associated with the listed AP, but I can run iwconfig eth2 essid [edited] and it seems to work (although please note the link quality reported vs the one above): albercik:~/src/wireless/wireless_tools.29 # iwconfig eth2 eth2 IEEE 802.11b/g ESSID:[edited] Nickname:Broadcom 4311 Mode:Managed Frequency=2.437 GHz Access Point: 00:13:46:85:46:F9 Bit Rate=1 Mb/s Tx-Power=18 dBm RTS thr:off Fragment thr:off Encryption key:off Link Quality=0/100 Signal level=-256 dBm Noise level=-256 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 However, if I attempt to change the bit rate with iwconfig eth2 rate 11M it just doesn't work (iwconfig still reports Bit Rate=1 Mb/s), and then iwlist rate says: eth2 12 available bit-rates : 0.012 kb/s 0.018 kb/s 0.024 kb/s 0.036 kb/s 0.048 kb/s 0.072 kb/s 0.096 kb/s 0.108 kb/s 0.002 kb/s 0.004 kb/s 0.011 kb/s 0.022 kb/s Current Bit Rate:1 Mb/s The first problem is the D-Link router not being detected, but I think someone else has already reported similar problems with a D-Link access point, so it seems there's something wrong with the bcm4311 vs D-Link APs in general. Of course the second one is the bit rates, but I have no idea if they are related to each other. Please let me know what I can do to debug the problems further. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm43xx on HPC nx6325 - partial success
Hi, On Tuesday, 23 January 2007 20:59, Larry Finger wrote: Rafael J. Wysocki wrote: Hi, First, thanks a lot for your work on the driver. Now, my observations: With the patch from https://lists.berlios.de/pipermail/bcm43xx-dev/2007-January/003484.html and the patch radio_enable_2.6.20 from ftp://lwfinger.dynalias.org/patches on top of 2.6.20-rc5 (x86_64), the bcm4311 card in my HPC nx6325 partially works (I use the ieee80211softmac version of the driver). Namely, everything seems to be going on well and and interrupts are coming, I can run iwlist eth2 scan and it reports something like the following: eth2 Scan completed : Cell 01 - Address: 00:13:46:85:46:F9 ESSID:[edited] Protocol:IEEE 802.11bg Mode:Master Channel:6 Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Quality=82/100 Signal level=-71 dBm Noise level=-68 dBm IE: WPA Version 1 Group Cipher : WEP-40 Pairwise Ciphers (2) : WEP-40 TKIP Authentication Suites (1) : PSK Extra: Last beacon: 280ms ago but strangely enough this is someone else's access point, not mine. My access point is a D-Link DI-624+ router, with different ESSID and different MAC. It stands just next to my machine and yet it is not detected (it is detected by my second maching with bcm4306, though, and works with it). First of all, please don't bother editing out the ESSID's from your postings. That information can be deduced by anyone in your vicinity very quickly, even if your ESSID is hidden. This isn't mine, as I said, and that's why it's been edited. Well, I should have edited the MAC too, but that isn't so easy to google out. ;-) [--snip--] The first problem is the D-Link router not being detected, but I think someone else has already reported similar problems with a D-Link access point, so it seems there's something wrong with the bcm4311 vs D-Link APs in general. You might try using kismet or ethereal on another wireless device to capture the traffic from the 4311. Yes, that sounds promising. In the meantime I carried out another experiment. I found an unencrypted AP close to me and tried to associate with it. That seemed to work, so I configured the interface manually with ifconfig and ran tcpdump on it. Then I received some traffic from that network and figured out from it that there was the IP 192.168.1.101 in there, so I reconfigured my interface with the address 192.168.1.15 and tried to ping the other host. There was no reply (Destination Host Unreachable), so I started a network monitor (gkrellm) and ran a continuous ping from the wireless interface. Then, no transmits were reported by the monitor. So, it seems, the card is still unable to transmit, although it evidently receives packets. Of course the second one is the bit rates, but I have no idea if they are related to each other. The bit rate output is a bug. Mine does it too - I'll find the problem. Ah, I see there's a patch already. I'll try it and report back. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix scaling error for 'iwlist rate' information
On Tuesday, 23 January 2007 21:26, Larry Finger wrote: The bcm43xx scales the rate information supplied to a WE iwlist rate call incorrectly. Signed-off-by: Larry Finger [EMAIL PROTECTED] --- John, This fix should be applied to wireless-2.6. As it is a bug fix, it could also be sent to 2.6.20; however, it has no real effect on system operations, and it doesn't mtter. Fixes the output of 'iwlist rate' for me. Thanks, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
2.6.17-rc1: bcm43xx problems with BCM4306 on x86_64
Hi, I've just tried the version of the driver included in 2.6.17-rc1 on an x86_64 box (Asus L5D) with a built-in PCI BCM4306 adapter (Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)), and unfortunately it doesn't seem to work. The driver loads and seems to initialize the adapter, but that's all, apparently. First, I compiled the driver with DMA and PIO support, but it hanged my box solid when I tried iwconfig eth1 essid on on it. On the next boot I noticed it caused the following messages to appear in dmesg: nommu_map_single: overflow 58ee7010+2404 of device mask 3fff nommu_map_single: overflow 53669010+2404 of device mask 3fff nommu_map_single: overflow 50180010+2404 of device mask 3fff and so on, down to 455aa010. Then I thought the adapter might be unable to DMA for some reason and compiled it with PIO support only. It did not hang the box any more, but I couldn't make it work. It causes the following messages to appear in dmesg: bcm43xx: set security called bcm43xx:.level = 0 bcm43xx:.enabled = 0 bcm43xx:.encrypt = 0 bcm43xx: PHY connected bcm43xx: Radio turned on bcm43xx: Chip initialized bcm43xx: PIO initialized bcm43xx: 80211 cores initialized bcm43xx: Keys cleared ADDRCONF(NETDEV_UP): eth1: link is not ready bcm43xx: FATAL ERROR: BCM43xx_IRQ_XMIT_ERROR bcm43xx: FATAL ERROR: BCM43xx_IRQ_XMIT_ERROR bcm43xx: FATAL ERROR: BCM43xx_IRQ_XMIT_ERROR bcm43xx: ASSERTION FAILED (0) at: drivers/net/wireless/bcm43xx/bcm43xx_pio.c:167:parse_cookie() bcm43xx: ASSERTION FAILED (packetindex = 0 packetindex BCM43xx_PIO_MAXTXPACKETS) at: drivers/net/wireless/bcm43xx/bcm43xx_ pio.c:170:parse_cookie() bcm43xx: ASSERTION FAILED (queue) at: drivers/net/wireless/bcm43xx/bcm43xx_pio.c:482:bcm43xx_pio_handle_xmitstatus() bcm43xx: FATAL ERROR: BCM43xx_IRQ_XMIT_ERROR bcm43xx: FATAL ERROR: BCM43xx_IRQ_XMIT_ERROR bcm43xx: FATAL ERROR: BCM43xx_IRQ_XMIT_ERROR bcm43xx: ASSERTION FAILED (0) at: drivers/net/wireless/bcm43xx/bcm43xx_pio.c:167:parse_cookie() bcm43xx: ASSERTION FAILED (packetindex = 0 packetindex BCM43xx_PIO_MAXTXPACKETS) at: drivers/net/wireless/bcm43xx/bcm43xx_ pio.c:170:parse_cookie() bcm43xx: ASSERTION FAILED (queue) at: drivers/net/wireless/bcm43xx/bcm43xx_pio.c:482:bcm43xx_pio_handle_xmitstatus() and so on. I used fwcutter 004 to extract the firmvare from the Windows file delivered with the machine (BCMWL5.SYS). If you need/want any more information from me, please let me know. Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.17-rc1: bcm43xx problems with BCM4306 on x86_64
On Friday 07 April 2006 21:05, Michael Buesch wrote: On Friday 07 April 2006 18:59, Rafael J. Wysocki wrote: I've just tried the version of the driver included in 2.6.17-rc1 on an x86_64 box (Asus L5D) with a built-in PCI BCM4306 adapter (Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)), and unfortunately it doesn't seem to work. The driver loads and seems to initialize the adapter, but that's all, apparently. First, I compiled the driver with DMA and PIO support, but it hanged my box solid when I tried iwconfig eth1 essid on on it. On the next boot I noticed it caused the following messages to appear in dmesg: nommu_map_single: overflow 58ee7010+2404 of device mask 3fff nommu_map_single: overflow 53669010+2404 of device mask 3fff nommu_map_single: overflow 50180010+2404 of device mask 3fff You should probably report that to the x86_64 people. I'll try -mm first and report if this still happens there. and so on, down to 455aa010. Then I thought the adapter might be unable to DMA for some reason and compiled it with PIO support only. It did not hang the box any more, but I couldn't make it work. PIO does not work, yet. Give me some other few weeks, please. Oops. Sorry for the noice then. ;-) Greetings, Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
