On Feb 10, 2009, at 9:59 PM, Larry Finger wrote:
> Francesco and Lorenzo,
>
> I now know a little more about my firmware crash. This time I
> captured the
> tx_status from each call just before the callback into mac80211.
> When the
> routine was called with the deleted/poisoned skb, I dumped
Francesco and Lorenzo,
I now know a little more about my firmware crash. This time I captured the
tx_status from each call just before the callback into mac80211. When the
routine was called with the deleted/poisoned skb, I dumped the current status
and the saved one. The results were:
b43_dma_ha
On Wednesday 04 February 2009 10:22:53 Lorenzo Nava wrote:
>
> On Feb 4, 2009, at 4:12 AM, Larry Finger wrote:
>
> > Francesco,
> >
> > I have coded b43 to dump the microcode PSM when
> > b43_dma_handle_txstatus is called for an skb that has already been
> > processed and deleted. This dump is fo
On Wednesday 04 February 2009 04:12:46 Larry Finger wrote:
> Francesco,
>
> I have coded b43 to dump the microcode PSM when
> b43_dma_handle_txstatus is called for an skb that has already been
> processed and deleted. This dump is for V5.0 of the open firmware and
> includes everything but the PC
Lorenzo Nava wrote:
> All the registers values look correct: rate tables seems ok, general
> purpose registers ok, rx and tx headers are fine too. The only thing
> that I noticed is that SHM reports a TX header which cookie value is
> 0x200C (at 0x08A0). So this means that the dump of the SHM is re
On Feb 4, 2009, at 4:12 AM, Larry Finger wrote:
> Francesco,
>
> I have coded b43 to dump the microcode PSM when
> b43_dma_handle_txstatus is called for an skb that has already been
> processed and deleted. This dump is for V5.0 of the open firmware and
> includes everything but the PC and condit
Francesco,
I have coded b43 to dump the microcode PSM when
b43_dma_handle_txstatus is called for an skb that has already been
processed and deleted. This dump is for V5.0 of the open firmware and
includes everything but the PC and condition codes.
I think these data are correct; however, the dump
Francesco Gringoli wrote:
> Has anyone knowledge about incompatibility between b43/bcm adapters and
> this kind of CardBus bridge (as reported by lspci)
>
> CardBus bridge: ENE Technology Inc CB-720/2/4 Cardbus Controller (rev 01)
Does that bridge use Yenta as its driver? From lspci, my bridges a
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 di
I was able to crash the 5.0 firmware again today after a 7 hour run
This time I had the following patch applied:
Index: wireless-testing/drivers/net/wireless/b43/dma.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/dma.c
+++
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 cooki
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 without crashing the system?
I don't mind. Just
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
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 0x
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
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 l
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
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.
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 at the time the crash would trigger? Are
> there holes
> in
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 th
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 th
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 m
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 m
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
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
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:
>
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 DM
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 especiall
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 m
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
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 the first error. I have no idea how many
> errors occurred before I
On Jan 31, 2009, at 12:23 PM, Michael Buesch wrote:
> 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 wh
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'r
>>
> 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 tried with my 4318 and openfwwf-5.1 and
cookie value goes fr
On Saturday 31 January 2009 07:54:20 Larry Finger wrote:
> I changed the dma.c code to WARN_ON rather than BUG_ON
Can you send this patch upstream?
> b43 TX status reports:
>
> index | cookie | seq | phy_stat | frame_count | rts_count |
> supp_reason | pm_indicated | intermediate | for_ampdu | a
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
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 the first error. I have no idea how many
errors occurred before I got it stopped, but the cookies for the first
few offending f
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 code has some bug. Let's say, for
> example, that
> 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 code has some bug. Let's say, for
example, that all the DMA slots were filled; when the firmware will
try to repor
On Friday 30 January 2009 09:06:34 Lorenzo Nava wrote:
> I was wonder if the problem can be in any way related to DMA slots. Is
> it possible that, with the heavy load test, you filled all DMA rx ring
> slots?
I think that's rather unlikely, however. The DMA code is basically unchanged
for months
Hi Larry,
I was wonder if the problem can be in any way related to DMA slots. Is
it possible that, with the heavy load test, you filled all DMA rx ring
slots?
Can you repeat the test and check if DMA rx ring will be filled?
A last question: is it possible that some RTS or CTS frame was send
duri
Francesco Gringoli wrote:
> just one more question: if you have time to test again r5.1, not a
> stress test, a wget is enough, could you please report info about rx and
> tx_ring usages? Those lines like the following:
>
> [219861.208427] b43-phy222 debug: DMA-32 rx_ring: Used slots 8/64,
> Fail
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 re
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
>
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 to the kernel (we too are using
> 2.6.29-rc2-wl), so
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 dri
On Thursday 29 January 2009 18:48:15 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 BU
Lorenzo Nava wrote:
>
> I had similar problem while I was updating from version 351 to 410: the
> problem was related to some tx_header fields that had different offsets.
> Once shared memory definitions were updated I had no problem. I did a
> lot of tests and everything seems to be ok.
> Did you
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 drivers/.../b43/dma.c:1386, which is in routine
b43_dma_handle_txstatu
Stefan Lippers-Hollmann wrote:
>
> Sorry about the noise, loading b43 with qos=0 allows it wo work flawlessly,
> I wrongly expected "b43: Automatically probe for opensource firmware" [1]
> to disable qos along with RTS/CTS, is there perhaps a way to detect/ set
> that properly during the firmware
Francesco Gringoli wrote:
>
> many thanks, I will investigate: probably we missed something when
> switching from 5.0 to 5.1, sorry.
>
> By the way, have you ever tried a similar test with firmware 5.0? Hope
> yes and everything went fine :-)
Yes, 5.0 passed the test. When I shut down those test
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 dri
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 drivers/.../b43/dma.c:1386, which is in routine
b43_dma_handle_t
Hi
On Donnerstag, 29. Januar 2009, Stefan Lippers-Hollmann wrote:
> Hi
>
> On Donnerstag, 29. Januar 2009, Francesco Gringoli wrote:
> > Hello,
> >
> > we made a few modifications to the opensource firmware code and now it
> > accepts frame encoded as version 410 layout.
>
> Thank you a lot f
Hi
On Donnerstag, 29. Januar 2009, Francesco Gringoli wrote:
> Hello,
>
> we made a few modifications to the opensource firmware code and now it
> accepts frame encoded as version 410 layout.
Thank you a lot for your efforts, but so far I haven't been successful in
getting my two 32 bit cardbu
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
55 matches
Mail list logo
