On Monday 29 September 2008 20:31:58 Larry Finger wrote:
Michael,
I have started modifying my copy of b43 to see if I can locate any
coding problems that might be causing the PHY transmission errors. To
start with, I am checking all the sections that use udelay. The main
reason is that when
.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John,
This is 2.6.28 material.
Larry
---
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index 7205a93..af60122 100644
--- a/drivers/net/wireless/b43
On Monday 29 September 2008 23:16:20 Peter Stuge wrote:
Michael Buesch wrote:
Actually, I do know since the very first days of bcm43xx that the
loop counts are not big enough in some of these loops.
Would it make sense to double check the conditions after the loop?
No it wouldn't
On Tuesday 30 September 2008 04:52:08 Peter Stuge wrote:
Celejar wrote:
simultaneously associate with two different APs
They would at least have to be on the same channel - or I think you
would need double radios and hardware tricks?
Well, you can use PS tricks (put STA into PS mode while
On Tuesday 30 September 2008 07:50:34 Peter Stuge wrote:
Larry Finger wrote:
Which specs?
The ones generated by the reverse engineers. See
http://bcm-v4.sipsolutions.net/.
Nice work, but as it's a spec of another driver implementation rather
than hardware (or even the firmware API)
On Tuesday 30 September 2008 15:46:04 [EMAIL PROTECTED] wrote:
If I understand him correctly he's suggesting that there could be BETTER
values than those used by the reference driver. In other words, yes,
B43/B43-Legacy are based on the RE of the Windows driver but perhaps
there are better
On Tuesday 30 September 2008 16:13:53 Peter Stuge wrote:
At this point, if there are only/mostly benefits, I don't see why
deviating from the specs is bad - after all they only document
another driver, right?
The past taught us that deviations from the specs are almost certainly
hidden bugs
On Tuesday 30 September 2008 16:11:18 Holger Schurig wrote:
The b43 and b43-legacy driver are _based_ on these
specifications. There are no other specs available.
Can it be the case that the binary windows driver the spec
They didn't use a windows driver.
producer analyzed used a
On Thursday 02 October 2008 16:51:42 Rafał Miłecki wrote:
2008/10/1 Vaidas Mikalauskas [EMAIL PROTECTED]:
b43-phy0 ERROR: PHY transmission error
wlan0: No ProbeResp from current AP 00:18:e7:32:a0:a4 - assume out of range
I guess it was Larry who was talking about PHY transmission error few
On Friday 03 October 2008 00:31:42 Larry Finger wrote:
On occasion, the PHY errors get much more serious. In dmesg, you get
the notation that 600 or 700 have been skipped. In addition, the
interface will reset.
That happens for one out of a thousand people.
--
Greetings Michael.
On Friday 03 October 2008 17:36:38 Mike VanRoy wrote:
This was happening to me but only a few errors (10), on 2.6.26.1.
After updating to 2.6.26.5, wpa_supplicant will not authenticate at all.
(BCM4318)
See, this is what I'm talking about. There's a lot of placebo involved.
There was no
On Sunday 19 October 2008 06:04:52 Brian J. Murrell wrote:
On Sat, 2008-10-18 at 19:24 -0700, [EMAIL PROTECTED] wrote:
Since you're running a custom distro for a particular branch of
hardware, have you communicated on their lists about this issue?
Not yet. I thought I would come to the
On Wednesday 22 October 2008 14:51:43 John W. Linville wrote:
I've seen this message a couple of times -- I'm a bit surprised that
you haven't been getting a response. I am Cc'ing Michael and the
bcm43xx mailing list just in case they haven't noticed this message.
I know about this issue.
But
On Thursday 23 October 2008 15:57:47 [EMAIL PROTECTED] wrote:
KURT PETERS wrote:
I still have the same problem here as well... except that I just went to
2.6.27.2 and still get the same problem. Last night, it seemed like my
laptop (with 4306 using the b43legacy driver) actually took
On Thursday 23 October 2008 17:13:44 KURT PETERS wrote:
Answers, as best I can, below:
KURT PETERS wrote:
I still have the same problem here as well... except that I just went to
2.6.27.2 and still get the same problem. Last night, it seemed like my
laptop (with 4306 using the b43legacy
On Thursday 23 October 2008 19:36:32 KURT PETERS wrote:
If you wanted to go over the specific suggested setup for wireshark, I'd be
happy to implement it. I don't know wireshark, so if you could eliminate
the learning curve, I'd be happy to take the data.
Just setup your testbed like the
On Thursday 23 October 2008 19:32:45 KURT PETERS wrote:
I'm using Cisco/Linksys.
I have a spare Netgear one I could try.
Please try this.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
Everybody with PHY TX error, please try updated firmware from
ftp://ftp.linksys.com/opensourcecode/wrt610n/1.00.00.018/wrt610n_v1.00.00.018_us.tgz
(Yeah, big tarball. It's 87MB)
Extract the file wrt610n_v1.00.00.018_us/release/src/wl/linux/wl.o out of the
archive.
Get latest b43-tools:
git clone
On Thursday 13 November 2008 20:10:01 Tex wrote:
I am getting stack traces (see below) on my broadcom 4318 card, they are
always started off at b43/xmit.c:76 (function
b43_plcp_get_bitrate_idx_ofdm) and mac80211/rx.c:2183 (function
__ieee80211_rx) both are hitting the WARN_ON macro
On Friday 21 November 2008 17:25:22 Larry Finger wrote:
A problem was recently posted to the bcm43xx mailing list that I am unable to
solve. The machine in question is an HP Mini 2133 (HP product number FU346EA)
with a BCM4312 PCIe wireless card. This card is known to work with the b43
driver
On Saturday 22 November 2008 07:39:24 Yuval Hager wrote:
On Friday 21 November 2008, Larry Finger wrote:
Yuval,
Michael Buesch wrote:
Can you dump PCI config space and SSB registers (TMSLOW, maybe others,
too). It looks like a random bus write disabled the device.
Please
On Saturday 22 November 2008 12:59:27 Yuval Hager wrote:
On Saturday 22 November 2008, Peter Stuge wrote:
Yuval Hager wrote:
When the wireless is working:
00: e4 14 12 43 06 01 10 00 02 00 80 02 08 00 00 00
10: 04 c0 ff fd 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00
On Saturday 22 November 2008 16:32:08 Larry Finger wrote:
Michael Buesch wrote:
Somebody disabled MMIO and busmastering.
And somebody cleared the CACHE_LINE_SIZE register.
Are these all the read/write bits in the configuration area? Should I conclude
that someone zeroed this area?
Yeah
On Sunday 23 November 2008 12:49:55 Yuval Hager wrote:
[ 182.891400] ** b43: B43_MMIO_MACCTL 0x840A0503
[ 182.891409] ** b43: SSB_TMSLOW 0x2015
[ 258.299027] irq 10: nobody cared (try booting with the irqpoll option)
Does the kernel disable the PCI device, if it ignores the
On Sunday 23 November 2008 16:42:28 Larry Finger wrote:
Michael Buesch wrote:
On Sunday 23 November 2008 12:49:55 Yuval Hager wrote:
[ 182.891400] ** b43: B43_MMIO_MACCTL 0x840A0503
[ 182.891409] ** b43: SSB_TMSLOW 0x2015
[ 258.299027] irq 10: nobody cared (try booting
On Sunday 23 November 2008 18:55:36 Yuval Hager wrote:
On Sunday 23 November 2008, you wrote:
On Sunday 23 November 2008 16:42:28 Larry Finger wrote:
Michael Buesch wrote:
On Sunday 23 November 2008 12:49:55 Yuval Hager wrote:
[ 182.891400] ** b43: B43_MMIO_MACCTL 0x840A0503
On Monday 24 November 2008 09:49:38 Yuval Hager wrote:
On Sunday 23 November 2008, Larry Finger wrote:
From a config file posted earlier, the OP is using SLAB. Is there any point
in trying SLUB?
Another try, not sure what it means:
* Added CONFIG_SLUB and CONFIG_SLUB_DEBUG
* boot
On Tuesday 25 November 2008 06:43:22 Yuval Hager wrote:
However, I have some few interesting findings.
First, this is totally unrelated to b43, but to the PCI. I get the flawed 1's
read from lspci even without loading b43.
I played around with different video drivers and the results are:
On Tuesday 02 December 2008 10:15:17 Mark Ryden wrote:
As far as I know, this driver
does support power saving mode.
No
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
On Wednesday 10 December 2008 06:35:41 Larry Finger wrote:
CHECK drivers/net/wireless/b43legacy/debugfs.c
drivers/net/wireless/b43legacy/debugfs.c:243:9: warning: memset with byte
count of 131072
I know about this error and I think it's a damn stupid error.
There is a reason why the value
On Wednesday 10 December 2008 16:09:35 Matthew Garrett wrote:
I've reworked the rfkill code in b43. This ought to be more consistent
...
I'm fine with this, as long as you take over the responsibility for the whole
b43-rfkill code.
I'm not going to touch it anymore. I'm only going to fix it by
On Wednesday 10 December 2008 18:23:40 Johannes Berg wrote:
Then there's user_claim_unsupported which is set by all drivers but
rt2x00, probably because they have hardware kill switches and thus they
have to set it even if it's not strictly true, because of the lacking
separation between these
On Wednesday 10 December 2008 18:51:02 Matthew Garrett wrote:
On Wed, Dec 10, 2008 at 06:37:23PM +0100, Johannes Berg wrote:
Ok. I think the fundamental flaw here is assuming that there's just a
single state. There isn't. The device can be turned off in hardware (in
which case sw won't be
On Wednesday 10 December 2008 19:29:50 Dan Williams wrote:
On Wed, 2008-12-10 at 19:05 +0100, Johannes Berg wrote:
On Wed, 2008-12-10 at 17:51 +, Matthew Garrett wrote:
They may not be physical buttons, but we can often control this anyway.
For instance, my HP has a button that
On Wednesday 10 December 2008 22:33:34 Henrique de Moraes Holschuh wrote:
On Wed, 10 Dec 2008, Johannes Berg wrote:
On Wed, 2008-12-10 at 18:23 +0100, Johannes Berg wrote:
Then there's user_claim_unsupported which is set by all drivers but
rt2x00, probably because they have hardware kill
On Thursday 11 December 2008 01:32:37 Julian Calaby wrote:
On Thu, Dec 11, 2008 at 02:29, Johannes Berg [EMAIL PROTECTED] wrote:
On Wed, 2008-12-10 at 15:09 +, Matthew Garrett wrote:
The final change is that I removed the code for changing the wireless
state in response to the txpower
On Thursday 18 December 2008 16:11:46 Mark Ryden wrote:
Hello,
Regarding on b43 drive:
As I understand, the b43 does not support power saving mode because of
some hw limitation.
It's not implemented in the driver.
Does anybody know: is there any attention to add
such a feature in hw in
On Thursday 18 December 2008 17:55:40 Mark Ryden wrote:
It's not implemented in the driver.
You mean It's not implemented in the driver firmware , as I understand
It means what I wrote.
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
This fixes some locking w.r.t. the lower MAC (firmware).
It also removes a lot of ancient IRQ-locking that's not needed anymore.
We simply suspend the MAC. That's easier and causes less trouble.
Signed-off-by: Michael Buesch m...@bu3sch.de
--
Stuff for the next feature release.
Index
On Friday 19 December 2008 16:39:23 Larry Finger wrote:
Michael Buesch wrote:
This fixes some locking w.r.t. the lower MAC (firmware).
It also removes a lot of ancient IRQ-locking that's not needed anymore.
We simply suspend the MAC. That's easier and causes less trouble.
When booting
We should suspend the MAC, before we kill the radio. This gives
the MAC a chance to leave any TX/RX state and it avoids races on
the PHY/RADIO registers.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
For 2.6.29
Index: wireless-testing/drivers/net/wireless/b43/phy_common.c
This adds an option to dump all crypto related memory to
the kernel log.
Obviously, it should not be enabled on productive systems. ;)
Signed-off-by: Michael Buesch m...@bu3sch.de
---
For 2.6.29
Index: wireless-testing/drivers/net/wireless/b43/debugfs.c
This fixes the key handling for mac80211's new key-flags.
It also adds TX locking to the set_key handler and adds a comment why this is
required.
This doesn't fix any known bugs.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
For 2.6.29
Index: wireless-testing/drivers/net/wireless/b43
On modern b43 devices with core rev =3, the hardware guarantees us an
atomic 64bit read/write of the TSF, if we access the lower 32bits first.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
For 2.6.29
Index: wireless-testing/drivers/net/wireless/b43/main.c
On Wednesday 24 December 2008 11:16:36 Ulf Dambacher wrote:
Matthew Garrett schrieb:
On Sat, Dec 20, 2008 at 06:08:17PM +0100, Ulf Dambacher wrote:
Hi
I hav a dell inspiron 5100 and it has no hardware button device to
toggle rfkill.
The broadcom bcm4301 card has this feature and the
On Wednesday 24 December 2008 16:58:14 Gene Heskett wrote:
With all due respect Michael, if it has been disabled by the panel switch
such
as the one on my lappy, can it not be made to emit such an error message so
that we know we have to toggle that pushbutton?
We emit a message that the
This adds detection code for the LP-PHY and SPROM
extraction code for version 8, which is needed by the LP-PHY and
newer N-PHY.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Please queue for 2.6.29
Index: wireless-testing/drivers/ssb/b43_pci_bridge.c
On Wednesday 24 December 2008 18:16:20 Ulf Dambacher wrote:
And both drivers use exactly the same code to test for the rfkill button. one
sais on the other sees off.
You must also honor the fact that you are running a completely different kernel.
It's _not_ that just one driver works, but the
On Thursday 25 December 2008 00:52:04 Johannes Berg wrote:
On Thu, 2008-12-25 at 00:39 +0100, Michael Buesch wrote:
This adds detection code for the LP-PHY and SPROM
extraction code for version 8, which is needed by the LP-PHY and
newer N-PHY.
I still get mac address ff:ff:ff:ff:ff:ff
On Thursday 25 December 2008 01:05:30 Johannes Berg wrote:
Hey,
I hope those of you who got their presents today enjoyed that. Here's
one from me for the poor souls like myself who have a Broadcom 11n chip:
I've been publishing specifications for things we have reverse
engineered, is
On Saturday 27 December 2008 00:28:01 Ulf Dambacher wrote:
Hi Michael
I did like you wanted and wrote the following output from screen (no
digicam at hand .-(
kernel 2.6.27.9 init=/bin/bash, no modules loaded so far
modprobe b43legacy:
ssb: Core 0 found: IEEE 802.11 (cc 0x812 rev
On Saturday 27 December 2008 00:48:20 Michael Buesch wrote:
On Saturday 27 December 2008 00:28:01 Ulf Dambacher wrote:
Hi Michael
I did like you wanted and wrote the following output from screen (no
digicam at hand .-(
kernel 2.6.27.9 init=/bin/bash, no modules loaded so far
The scheduled date for the removal of old fw support was in July 2008.
However, we're not going to remove the support unless it causes a major
headache. So change the schedule from July 2008 to when it causes headaches.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Please queue for 2.6.29
On Monday 29 December 2008 17:23:56 Larry Finger wrote:
Michael Buesch wrote:
Thanks, I applied this.
Is it possible, however, to have ssb_sprom --help not ask for the version?
Simply print out _all_ options that apply to all versions.
It's kind of confusing to see a question about a file
On Monday 29 December 2008 18:11:10 Larry Finger wrote:
Revise ssb-sprom to generate the help data for all versions of the device.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
Thanks.
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
I was doing some random tests on the b43 hardware RNG.
These are the results.
I patched the firmware to not access the RNG register anymore.
The unpatched firmware does two things. It reads the RNG register to get random
values
and it writes 0 to the register every now and then for whatever
On Friday 09 January 2009 02:30:56 Harvey Harrison wrote:
On Thu, 2009-01-08 at 17:28 -0800, Harvey Harrison wrote:
On Fri, 2009-01-09 at 02:11 +0100, Michael Buesch wrote:
I was doing some random tests on the b43 hardware RNG.
These are the results.
I patched the firmware
test firmware written by Michael Buesch and
useful talks with those guys (b43 developers), which we deeply
acknowledge. As we used several definition files written by Michael
for its firmware and we have prepared a source tar file that includes
them, we kindly ask Michael if this could
On Monday 12 January 2009 16:39:49 John W. Linville wrote:
On Sat, Jan 10, 2009 at 06:37:43PM +0100, Lorenzo Nava wrote:
Hello everybody,
today I tried OpenFWWF with kernel 2.6.28 on a Siemens wifi device with
Broadcom 4306 chipset:
BCM94306 802.11g (rev 03)
PHY: Analog 2, Type 2,
On Wednesday 14 January 2009 08:15:37 YanBo wrote:
[snip]
You can add
Acked-by: Michael Buesch m...@bu3sch.de
to all of these patches, after fixing the issues Johannes reported.
Please send them directly to John afterwards and CC me.
--
Greetings, Michael
On Wednesday 14 January 2009 02:19:05 David Ellingsworth wrote:
On Tue, Jan 13, 2009 at 6:09 PM, Paul Harris p...@whotookspaz.org wrote:
Hello there,
I was wondering if it would be at all possible for the developers of b43 to
consider dual licensing the drivers, so
that users of other
On Wednesday 14 January 2009 18:43:27 Larry Finger wrote:
Lorenzo Nava wrote:
Today we have also tested a new firmware version that works with
WPA2-personal (both TKIP and CCMP) and WPA2-enterprise (EAP-TTLS)
(tested on 4306 and 4318 PCI device). If anybody was interested please
try new
On Wednesday 14 January 2009 21:45:22 Johannes Berg wrote:
Initvals and new firmware version can be found at
http://www.ing.unibs.it/openfwwf
I suggest that before this is packaged, we change it so b43 can
recognise it and automatically disable qos and hwcrypto.
Yes, please introduce a
On Thursday 15 January 2009 00:22:33 Stefan Lippers-Hollmann wrote:
Is there a chance to add support for this kind of device?
I think you're on your own. Nobody else does have such a device
and remote-debugging is basically impossible for this.
--
Greetings, Michael.
On Thursday 15 January 2009 16:37:57 Michael Buesch wrote:
On Wednesday 14 January 2009 21:45:22 Johannes Berg wrote:
Initvals and new firmware version can be found at
http://www.ing.unibs.it/openfwwf
I suggest that before this is packaged, we change it so b43 can
recognise
On Thursday 15 January 2009 16:59:11 Larry Finger wrote:
Michael Buesch wrote:
Yes, please introduce a feature-bitfield at some location in SHM that's
unused
by the proprietary firmware. This bitfields would contain a bit for QoS and
a bit for hwcrypto.
Also change your firmware so
On Thursday 15 January 2009 18:59:46 Stefan Lippers-Hollmann wrote:
Hi
On Donnerstag, 15. Januar 2009, Michael Buesch wrote:
On Thursday 15 January 2009 00:22:33 Stefan Lippers-Hollmann wrote:
Is there a chance to add support for this kind of device?
I think you're on your own
On Friday 16 January 2009 00:01:41 Francesco Gringoli wrote:
On Jan 15, 2009, at 4:59 PM, Larry Finger wrote:
Michael Buesch wrote:
Yes, please introduce a feature-bitfield at some location in SHM
that's unused
by the proprietary firmware. This bitfields would contain a bit
On Friday 16 January 2009 00:17:43 Kyle McMartin wrote:
On Thu, Jan 15, 2009 at 05:09:49PM +0100, Michael Buesch wrote:
Already implemented here:
http://bu3sch.de/patches/wireless-testing/20081227-1821/patches/008-b43-probe-open-fw.patch
I just need to fix a leak in an error path before
On Wednesday 21 January 2009 18:29:40 Francesco Gringoli wrote:
Hello everyone,
we just made available a new opensource firmware version, download at
http://www.ing.unibs.it/openfwwf
New features:
- initvals source code added, initvals files are encoded by make process
- firmware is now
On Friday 23 January 2009 18:36:37 Francesco Gringoli wrote:
Hello,
we have been testing the firmware for a week now and it seems stable.
I personally tested it also on a Linksys WRT54GL and it works both in
station and in AP modes. I collected the feedbacks that some of you
sent and
On Friday 23 January 2009 19:01:00 Larry Finger wrote:
The driver can certainly be coded to look for the open-source firmware
names before trying to load vendor firmware. That way there will not
be any confusion.
I already posted that, but in case you missed it:
On Friday 23 January 2009 19:50:37 Dan Williams wrote:
On Fri, 2009-01-23 at 19:08 +0100, Michael Buesch wrote:
On Friday 23 January 2009 19:01:00 Larry Finger wrote:
The driver can certainly be coded to look for the open-source firmware
names before trying to load vendor firmware
On Friday 23 January 2009 20:18:52 Francesco Gringoli wrote:
Nothing. Why do we need to have different names?
Well, I was only considering a question raised by John, we can surely
maintain these names.
I guess I missed that. What was the question?
Note that proprietary and open firmwares
On Friday 23 January 2009 20:24:47 Francesco Gringoli wrote:
On Jan 23, 2009, at 7:01 PM, Larry Finger wrote:
Francesco Gringoli wrote:
Hello,
we have been testing the firmware for a week now and it seems
stable. I
personally tested it also on a Linksys WRT54GL and it works both
On Friday 23 January 2009 20:46:45 Francesco Gringoli wrote:
-- Is using the Broadcom names for the firmware the best course of
-- action? What if the opensource firmware files were named something
-- like os-ucode5.fw, etc. and b43 were coded to check for those files
-- first? It would then
on
multiband
devices, which are not implemented yet anyway.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
John, please queue for the next feature round.
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless
On Saturday 24 January 2009 06:04:47 Larry Finger wrote:
Michael Buesch wrote:
First probe for proprietary firmware and then probe for opensource firmware.
This way around it's a win-win situation.
1) If proprietary fw is available, it will work.
2) If opensource firmware is available
Fix compile warning for non-debug builds:
drivers/net/wireless/b43/phy_g.c: In function ‘b43_gphy_op_recalc_txpower’:
drivers/net/wireless/b43/phy_g.c:3195: warning: unused variable ‘dbm’
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Index: wireless-testing/drivers/net/wireless/b43/phy_g.c
a net reduction in size by about 12k.
This patch also adds a printk of the wireless core revision, so people
don't have to enable SSB debugging to get the wireless core revision.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
John, please queue for the next feature push.
Index: wireless
On Sunday 25 January 2009 13:19:45 Michael Buesch wrote:
On Sunday 25 January 2009 04:45:20 Larry Finger wrote:
Francesco Gringoli wrote:
could you please be so kind to try the opensource firmware on that
4311/2 card by renaming it ucode13 and report what happens? I suggest to
try
Hi,
What's the LP-PHY progress? I'd like to get some implementation going. :)
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
On Monday 26 January 2009 16:39:53 Larry Finger wrote:
Michael Buesch wrote:
Hi,
What's the LP-PHY progress? I'd like to get some implementation going. :)
As you likely noted, I've been busy with non-BCM43xx tasks.
The decompilation of the LP routines is essentially complete
On Monday 26 January 2009 16:34:49 Larry Finger wrote:
Do you know of any reason why version 410 firmware fails on this device?
No, it works on all of my 4318 devices.
Can you suggest to try without btcoex (module parameter)?
--
Greetings, Michael.
On Monday 26 January 2009 22:53:56 Larry Finger wrote:
Michael Buesch wrote:
Thanks a lot. That's very nice. I'm interested in implementing the stuff
and I already started to implement the existing specs stuff.
I'm interested to get the Asus WL500Gv2 working, which has an LP-PHY
On Tuesday 27 January 2009 22:51:50 Adam Goode wrote:
Hi,
I have a new laptop with a bcm4315, pci id 14e4:4515. Any update on
support? Can I be of any assistance?
I'm working on it, however, I just bricked my device. Let's hope I can
fix it via JTAG. :)
--
Greetings, Michael.
On Saturday 31 January 2009 12:20:18 Lorenzo Nava wrote:
Hmmm, I think the cookies should actually be more or less
sequential, if
QoS and PIO are not used. That's rather strange. Can you try with
original fw and
see what the cookies look like?
Yes Michael, you're right... I
This adds register definitions for the LP-PHY.
This also adds a few minor empty function bodies for the LP-init.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
I'll let you decide whether you queue this for the next feature release
or the next -rc. I lost track of what the rules
This adds code for the baseband init of LP-PHY =2.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Index: wireless-testing/drivers/net/wireless/b43/Makefile
===
--- wireless-testing.orig/drivers/net/wireless/b43/Makefile 2009
This adds initialization code for the 2062 radio.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Index: wireless-testing/drivers/net/wireless/b43/phy_lp.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/phy_lp.c 2009
On Saturday 31 January 2009 20:15:22 Francesco Gringoli wrote:
On Jan 31, 2009, at 7:54 AM, Larry Finger wrote:
Francesco,
I changed the dma.c code to WARN_ON rather than BUG_ON and also dump
the cookie for the erring case. Of course, the system no longer
crashes, nor even stops on
On Sunday 01 February 2009 00:35:01 Francesco Gringoli wrote:
On Jan 30, 2009, at 10:59 PM, Michael Buesch wrote:
On Friday 30 January 2009 14:22:35 Lorenzo Nava wrote:
I think that's rather unlikely, however. The DMA code is basically
unchanged
for months and especially the slot
On Sunday 01 February 2009 00:47:35 Michael Buesch wrote:
On Sunday 01 February 2009 00:35:01 Francesco Gringoli wrote:
On Jan 30, 2009, at 10:59 PM, Michael Buesch wrote:
On Friday 30 January 2009 14:22:35 Lorenzo Nava wrote:
I think that's rather unlikely, however. The DMA code
On Sunday 01 February 2009 11:16:29 Michael Buesch wrote:
On Sunday 01 February 2009 02:01:24 Francesco Gringoli wrote:
Ok, this could be a problem. Will check next days how to solve. I
suppose now that the length of that report_tx_status queue is very
device dependent as mine can
On Sunday 01 February 2009 02:01:24 Francesco Gringoli wrote:
Ok, this could be a problem. Will check next days how to solve. I
suppose now that the length of that report_tx_status queue is very
device dependent as mine can grow it more than one hundred elements
and status continues to
On Sunday 01 February 2009 12:24:23 Francesco Gringoli wrote:
On Feb 1, 2009, at 11:25 AM, Michael Buesch wrote:
On Sunday 01 February 2009 11:16:29 Michael Buesch wrote:
If it's not an external condition, it could possibly also be a bit
in the TXE or something
like that. I'm
On Sunday 01 February 2009 12:25:20 Francesco Gringoli wrote:
On Feb 1, 2009, at 11:25 AM, Michael Buesch wrote:
On Sunday 01 February 2009 11:16:29 Michael Buesch wrote:
If it's not an external condition, it could possibly also be a bit
in the TXE or something
like that. I'm
On Sunday 01 February 2009 16:58:33 Larry Finger wrote:
Michael Buesch wrote:
But, why do we talk about this, actually? Do we actually know what went
wrong, yet?
Larry, did you dump a cookie of a frame that would trigger the crash? What
does the
ring memory allocation look like
On Sunday 01 February 2009 17:26:26 Francesco Gringoli wrote:
On Feb 1, 2009, at 5:19 PM, Larry Finger wrote:
The problem also exists in the 5.0 firmware. My test this morning died
within 10 minutes. This time, there were only two transmits queued.
The cookies were 0x2048 and 0x204A.
This fixes the crystal frequency calculations in the b2062 init code.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
This patch depends on the SSB PMU code.
Index: wireless-testing/drivers/net/wireless/b43/phy_lp.c
1301 - 1400 of 1753 matches
Mail list logo
