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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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.
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
66 matches
Mail list logo
