On Nov 23, 2009, at 11:49 AM, Michael Buesch wrote:
On Monday 23 November 2009 05:45:47 Larry Finger wrote:
On 11/19/2009 03:24 PM, Michael Buesch wrote:
This rewrites the error handling policies in the TX status handler.
It tries to be error-tolerant as in try hard to not crash the
/bcm43xx-dev
---
Francesco Gringoli, PhD - Assistant Professor
Dept. of Electrical Engineering for Automation
University of Brescia
via Branze, 38
25123 Brescia
ITALY
Ph: ++39.030.3715843
FAX: ++39.030.380014
WWW: http://www.ing.unibs.it/~gringoli
INFORMATIVA SUL TRATTAMENTO DEI DATI
On Aug 5, 2009, at 4:41 PM, Larry Finger wrote:
Francesco Gringoli wrote:
On Aug 5, 2009, at 1:07 PM, Peter Lemenkov wrote:
Hello,All!
Here is a bug report regarding DMA issues with openfwwf ver. 5.2 . I
suspect, that this is a known issue, but anyway, maybe this bugzilla
ticket will add
On Jul 30, 2009, at 9:02 PM, Larry Finger wrote:
Francesco,
skb=NULL somehow smells like a double-free caused by a double-report
or something like that.
Based on what Michael said about a double-free, I changed from
meta-skb = NULL to meta-skb = 0x0606060606060606, and changed to
testing
On Jul 30, 2009, at 11:55 PM, Michael Buesch wrote:
On Thursday 30 July 2009 23:54:17 Francesco Gringoli wrote:
many thanks. I will surely look into that direction as soon as I get
the boards. By the way: I never worked with mini-pci-e and I don't
even have a desktop PC with that bus, so I
On Jul 26, 2009, at 7:01 PM, Larry Finger wrote:
Michael Buesch wrote:
On Sunday 26 July 2009 17:37:10 Larry Finger wrote:
The revised printk shows
b43-phy0 warning: DMA queue overflow with free_slots = 0
Ok, it's a mac80211 bug then.
Perhaps not. I also got the ring-stopped WARN_ON. Is
Hello there,
after a long time we just made available a new version of the
opensource firmware at http://www.ing.unibs.it/openfwwf (release 5.2).
We discovered a bug that was causing the firmware to go into
suspension after a phy error due to external conditions: syslog
reported a phy
:
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
---
Francesco Gringoli, PhD - Assistant Professor
Dept. of Electrical Engineering for Automation
University
on trying
to get this to work.
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
---
Francesco Gringoli, PhD - Assistant Professor
Dept. of Electrical
Michael,
I was wondering about the beacon IRQ and those functions inside b43
that handle such interrupt. In which situations apart the first
installation of the beacon in template ram, is handle_irq_beacon
called inside the b43 driver? E.g., openfirmware does not raise the
beacon irq but
On Apr 10, 2009, at 12:42 AM, Michael Buesch wrote:
On Friday 10 April 2009 00:28:48 Francesco Gringoli wrote:
You mean that it misses to transmit some frames? Do you have
hypotheses on why AP mode should complete change the behavior of the
board from good enough to not working correctly
On Apr 10, 2009, at 12:44 AM, Michael Buesch wrote:
On Friday 10 April 2009 00:34:32 Francesco Gringoli wrote:
I was wondering about the beacon IRQ and those functions inside b43
that handle such interrupt. In which situations apart the first
installation of the beacon in template ram
On Mar 30, 2009, at 11:35 PM, Francesco Gringoli wrote:
On Mar 28, 2009, at 12:41 AM, Michael Buesch wrote:
The RX buffer poison needs to be refreshed, if we recycle an RX
buffer,
because it might be (partially) overwritten by some DMA operations.
Cc: sta...@kernel.org
Cc: Francesco
On Mar 28, 2009, at 12:41 AM, Michael Buesch wrote:
The RX buffer poison needs to be refreshed, if we recycle an RX
buffer,
because it might be (partially) overwritten by some DMA operations.
Cc: sta...@kernel.org
Cc: Francesco Gringoli francesco.gring...@ing.unibs.it
Signed-off
On Mar 28, 2009, at 12:53 AM, Michael Buesch wrote:
On Saturday 28 March 2009 00:49:12 Francesco Gringoli wrote:
On Mar 27, 2009, at 10:51 PM, Michael Buesch wrote:
This patch adds poisoning and sanity checking to the RX DMA buffers.
This is used for protection against buggy hardware
* and is split over multiple buffers.
--
Greetings, Michael.
---
Francesco Gringoli, PhD - Assistant Professor
Dept. of Electrical Engineering for Automation
University of Brescia
via Branze, 38
25123 Brescia
ITALY
Ph: ++39.030.3715843
FAX: ++39.030.380014
WWW: http://www.ing.unibs.it
/bcm43xx-dev
---
Francesco Gringoli, PhD - Assistant Professor
Dept. of Electrical Engineering for Automation
University of Brescia
via Branze, 38
25123 Brescia
ITALY
Ph: ++39.030.3715843
FAX: ++39.030.380014
WWW: http://www.ing.unibs.it/~gringoli
On Mar 19, 2009, at 8:13 PM, Michael Buesch wrote:
On Thursday 19 March 2009 20:00:45 Francesco Gringoli wrote:
Yeah well. This confirms my thoughts.
There are other ways to voluntarily trigger the errors. For example
try covering the antennae with your bare hands. Try to move the
device
On Mar 19, 2009, at 9:10 PM, Michael Buesch wrote:
On Thursday 19 March 2009 20:56:52 Francesco Gringoli wrote:
I would agree with you, but there is this bizarre issue with PHY
errors in monitoring mode that makes me thinking about what we call
PHY errors. I would say they are not only due
Hello everyone,
I tried without success to run b43 on a via (cpu) pc and I got a very
strange behavior. Everything seems to work fine for a random time
going from 60s to a multiple of 60s. Then dmesg reports that a direct
probe failed and that b43 lost the connection to the AP.
I tried
---
Francesco Gringoli, PhD - Assistant Professor
Dept. of Electrical Engineering for Automation
University of Brescia
via Branze, 38
25123 Brescia
ITALY
Ph: ++39.030.3715843
FAX: ++39.030.380014
WWW: http://www.ing.unibs.it/~gringoli
___
Bcm43xx
On Feb 22, 2009, at 8:10 PM, Larry Finger wrote:
Francesco and Lorenzo,
I modified my driver source to dump the firmware machine state
whenever the
b43_dma_handle_txstatus routine was called with an out-of-order
cookie. With
proprietary firmware, the test of a flood ping in one job
On Feb 18, 2009, at 11:15 AM, Michael Buesch wrote:
On Wednesday 18 February 2009 03:33:01 Francesco Gringoli wrote:
On Feb 18, 2009, at 12:23 AM, Michael Buesch wrote:
On Wednesday 18 February 2009 00:07:56 Bo Han wrote:
I think I am working on the first sanity check in the driver
filled by first the driver then
mac80211?
Cheers,
-FG
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
---
Francesco Gringoli, PhD - Assistant
On Feb 2, 2009, at 4:23 AM, Larry Finger wrote:
I was able to crash the 5.0 firmware again today after a 7 hour run
This time I had the following patch applied:
Finally I got my equipment, a rev 3 4306 Broadcom cardbus adapter, to
crash too. What is strange is that during the weekend I did
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 not completely sure on that one. But external
condition would be my
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 not completely sure on that one. But external
condition would be my
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.
Larry
I'm happier now... though this means very hard debugging. It
On Feb 1, 2009, at 5:32 PM, Michael Buesch wrote:
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
On Feb 1, 2009, at 6:10 PM, Larry Finger wrote:
Francesco Gringoli wrote:
In fact, I was joking! However if it happens...
Jokes apart, I must reproduce this condition to debug it. Larry,
would
you mind loading up a modified firmware with a small kernel patch to
report a cookie miss
---
Francesco Gringoli, PhD - Assistant Professor
Dept. of Electrical Engineering for Automation
University of Brescia
via Branze, 38
25123 Brescia
ITALY
Ph: ++39.030.3715843
FAX: ++39.030.380014
WWW: http://www.ing.unibs.it/~gringoli
___
Bcm43xx-dev mailing
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 handling hasn't changed in years.
Yes, but I didn't mean that the
On Feb 1, 2009, at 12:49 AM, Michael Buesch wrote:
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
Hello,
we made a few modifications to the opensource firmware code and now it
accepts frame encoded as version 410 layout.
Cheers,
-FG
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Larry,
could you please be so kind and check if this is the 4311 board you
have? I found it on ebay and I would like to buy the correct one
(hoping that the seller put the correct photo... :-) )
http://www.ing.unibs.it/openfwwf/private/hp-4311.jpg
Cheers,
-FG
On Jan 29, 2009, at 6:48 PM, Larry Finger wrote:
Francesco,
Opensource firmware 5.1 works with my BCM4318; however, under heavy
load with a ping running in one window and 10 second bursts of tcpperf
transmissions in another, the kernel (2.6.29-rc2-wl) panicked by
hitting the BUG at
On Jan 30, 2009, at 12:09 AM, Larry Finger wrote:
Francesco Gringoli wrote:
- have you applied any recent patch to the kernel (we too are using
2.6.29-rc2-wl), so that your kernel can behave differently than ours?
- are you sure you are using the correct initvals files? Those we put
today
On Jan 30, 2009, at 12:09 AM, Larry Finger wrote:
Francesco Gringoli wrote:
we just finished a couple of stressing tests and everything went
fine,
kernel did not complain about anything, below is attached the tests
description. Just a few questions
- have you applied any recent patch
On Jan 23, 2009, at 8:45 PM, Larry Finger wrote:
Francesco Gringoli wrote:
Damn... that would be a very hard writing We do not have any
4311/2
board: at first glance there are more condition registers whose
meaning
we do not know. Very different hardware, didn't know. Thank you
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 it seems that the firmware now runs on these board:
- 4306, 4311,
On Jan 23, 2009, at 7:02 PM, Michael Buesch wrote:
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
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 in
station and in AP modes. I collected the feedbacks that some
On Jan 23, 2009, at 8:33 PM, Michael Buesch wrote:
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
On Jan 23, 2009, at 8:37 PM, Michael Buesch wrote:
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
On Jan 23, 2009, at 6:44 PM, Brian J. Murrell wrote:
On Fri, 2009-01-23 at 18:36 +0100, 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.
Did
On Jan 22, 2009, at 10:51 AM, Thomas Ilnseher wrote:
Am Donnerstag, den 22.01.2009, 10:26 +0100 schrieb Holger Schurig:
Just found this in the Android's repository and think maybe
this info can be useful for someone in this list:
http://android.git.kernel.org/?p=platform/system/wlan/broadcom
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 recognized as opensource, though still as version
351 (old format).
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 for
QoS and
a bit for hwcrypto.
Also change your firmware so the driver
On Jan 15, 2009, at 4:35 AM, _...@list.ru wrote:
(Previous message failed)
The Wi-Fi status LED on Acer Extensa 5220 works incorrectly.
When using b43, it is turned on only if radio is disabled.
When using ndiswrapper, it is blinking when disconnected, on when
connected and rapidly flashes
On Jan 12, 2009, at 4:39 PM, 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, Revision 2
to implement other MAC algorithms for research purposes: if
someone is interested in this kind of work and would like to share
ideas also on research topics, please let us know.
Cheers,
Francesco Gringoli
Lorenzo Nava
___
Bcm43xx-dev mailing list
Hi Michael,
we are collecting every kind of material about Broadcom board, too.
Could you please point out the document with such specifications?
I confirm what Lorenzo wrote: there are 32 bytes for queue. If you
leave 22 then all the Qos mechanisms go wrong. Indeed, the bcm board
takes
Hello everybody,
we found a strange behavior problem with the b43 driver. We begin
investigating this when doing some access tests with several boards:
we discovered that the Broadcom boards usually acquire the channel
usage with higher priority when the b43 driver is used as respect to
Just a question (for Francis): how does the AP work? Have you tried
very stressing tests with traffic crossing the AP? We do have problems
when the channel is saturated, it seems that the BCM device acting as
AP stops sending beacons and the BSS goes down, we need to reconfigure
everything
for future drivers.
And I would very be pleased to know how did you pointed out the
meaning of the opcode in the website.
Thank you very much for your time,
cheers,
FG
%
Francesco Gringoli, PhD - Assistant Professor
Dept. of Electrical Engineering for Automation
University
Hi Michael,
It could also be the case that the opcodes on the website aren't
opcodes to a real CPU,
Broadcom calls this a Programmable State Machine.
But what is this all about? Why do you care what type of CPU this is?
Does this matter _at_ _all_? I mean, we know all opcodes of the
revision
4 and lower. Is that r3 and r4? Are they the same?
Have you tried to write your own mac to see if it works?
Thank you very much,
FG
On Dec 3, 2007, at 11:38, Johannes Berg wrote:
On Sun, 2007-12-02 at 15:55 +0100, Francesco Gringoli wrote:
Hi Johannes,
I read the interesting note you
Hi Johannes,
I read the interesting note you wrote on September about r4 ucode
reverse engineering. Have you new results since then? Did you
understand what kind of core is bcm4318 based on? From broadcom
website it should be a MIPS32 core (check http://www.broadcom.com/
58 matches
Mail list logo
