Re: Improved opensource firmware
On Sunday 26 July 2009 17:37:10 Larry Finger wrote:
> Michael Buesch wrote:
> >
> > Just to explain my idea:
> > I think there are two ways for this warning to trigger.
> > The first being mac80211 being broken and not stopping the queue on request.
> > That's probably not very likely.
> > The second could possibly be the firmware reporting status for one frame
> > multiple times. I did not check the whole code, but this could possibly
> > lead to an integer under/overflow in the free_slots() calculation. A signed
> > integer
> > is used, so I think it can go negative, which would trigger the warning.
> >
> > I don't see another way to trigger the message.
> > And as it only seems to happen with open firmware, it seems likely be caused
> > by TX status reporting in the firmware.
>
> The message also triggers with proprietary firmware. My debugging hunk is
>
> @@ -1340,7 +1350,8 @@ int b43_dma_tx(struct b43_wldev *dev, st
> B43_WARN_ON(ring->stopped);
>
> if (unlikely(free_slots(ring) < TX_SLOTS_PER_FRAME)) {
> - b43warn(dev->wl, "DMA queue overflow\n");
> + b43warn(dev->wl, "DMA queue overflow with free_slots =
> %d\n",
> + free_slots(ring));
> err = -ENOSPC;
> goto out_unlock;
> }
>
> The revised printk shows
>
> b43-phy0 warning: DMA queue overflow with free_slots = 0
Ok, it's a mac80211 bug then.
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
Michael Buesch wrote:
>
> Just to explain my idea:
> I think there are two ways for this warning to trigger.
> The first being mac80211 being broken and not stopping the queue on request.
> That's probably not very likely.
> The second could possibly be the firmware reporting status for one frame
> multiple times. I did not check the whole code, but this could possibly
> lead to an integer under/overflow in the free_slots() calculation. A signed
> integer
> is used, so I think it can go negative, which would trigger the warning.
>
> I don't see another way to trigger the message.
> And as it only seems to happen with open firmware, it seems likely be caused
> by TX status reporting in the firmware.
The message also triggers with proprietary firmware. My debugging hunk is
@@ -1340,7 +1350,8 @@ int b43_dma_tx(struct b43_wldev *dev, st
B43_WARN_ON(ring->stopped);
if (unlikely(free_slots(ring) < TX_SLOTS_PER_FRAME)) {
- b43warn(dev->wl, "DMA queue overflow\n");
+ b43warn(dev->wl, "DMA queue overflow with free_slots =
%d\n",
+ free_slots(ring));
err = -ENOSPC;
goto out_unlock;
}
The revised printk shows
b43-phy0 warning: DMA queue overflow with free_slots = 0
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
On Sunday 26 July 2009 05:16:53 Larry Finger wrote: > Michael Buesch wrote: > > On Friday 24 July 2009 16:48:49 Larry Finger wrote: > >> Francesco, > >> > >> Sorry, but I missed a warning about DMA queue overflow that was being > >> logged as follows: > > > > Can you printk the value of free_slots(), when this happens? > > I have a printk in place, but that warning has not happened again. Just to explain my idea: I think there are two ways for this warning to trigger. The first being mac80211 being broken and not stopping the queue on request. That's probably not very likely. The second could possibly be the firmware reporting status for one frame multiple times. I did not check the whole code, but this could possibly lead to an integer under/overflow in the free_slots() calculation. A signed integer is used, so I think it can go negative, which would trigger the warning. I don't see another way to trigger the message. And as it only seems to happen with open firmware, it seems likely be caused by TX status reporting in the firmware. > I made the following changes: > > (1) I put guard words around meta in struct b43_dma_ring, and around > the skb in struct b43_dmadesc_meta. These were checked in > b43_dma_handle_txstatus() and were OK. Whatever is setting meta->skb > to NULL is specific in writing that location. > > (2) I replaced the BUG_ON when meta->skb is NULL with printk > statements that dump elements of the ring and meta structs. At least I > get a chance to interrogate the internal data. Furthermore, I can get > the wireless back by unloading and reloading b43 without rebooting. > The dumped values are as follows: > > b43: meta data: skb (null) > dmaaddr 986d50bc > is_last_fragment 1 > b43: ring data: nr_slots 256 > used_slots 45 > current_slot 65 > index 1 > tx 1 > max_used_slots 256 > > Unfortunately, all of these look reasonable - no smoking guns. > > Any suggestions on other values to dump? > > Larry > > -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
Michael Buesch wrote: > On Friday 24 July 2009 16:48:49 Larry Finger wrote: >> Francesco, >> >> Sorry, but I missed a warning about DMA queue overflow that was being >> logged as follows: > > Can you printk the value of free_slots(), when this happens? I have a printk in place, but that warning has not happened again. I made the following changes: (1) I put guard words around meta in struct b43_dma_ring, and around the skb in struct b43_dmadesc_meta. These were checked in b43_dma_handle_txstatus() and were OK. Whatever is setting meta->skb to NULL is specific in writing that location. (2) I replaced the BUG_ON when meta->skb is NULL with printk statements that dump elements of the ring and meta structs. At least I get a chance to interrogate the internal data. Furthermore, I can get the wireless back by unloading and reloading b43 without rebooting. The dumped values are as follows: b43: meta data: skb (null) dmaaddr 986d50bc is_last_fragment 1 b43: ring data: nr_slots 256 used_slots 45 current_slot 65 index 1 tx 1 max_used_slots 256 Unfortunately, all of these look reasonable - no smoking guns. Any suggestions on other values to dump? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
On Friday 24 July 2009 16:48:49 Larry Finger wrote: > Francesco, > > Sorry, but I missed a warning about DMA queue overflow that was being > logged as follows: Can you printk the value of free_slots(), when this happens? > > [ cut here ] > WARNING: at drivers/net/wireless/b43/dma.c:1342 > b43_dma_tx+0x115/0x9b2 [b43]() > Hardware name: HP Pavilion dv2700 Notebook PC > Modules linked in: b43 ssb rng_core mac80211 cfg80211 rfkill > led_class aes_x86_64 aes_gene > ric af_packet snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device nfs > lockd nfs_acl auth_rpcgss vboxnetadp sunrpc vboxnetflt v > boxdrv cpufreq_conservative cpufreq_userspace cpufreq_powersave > powernow_k8 fuse ext4 jbd2 crc16 loop dm_mod ide_cd_mod cdr > om snd_hda_codec_conexant arc4 ecb ide_pci_generic snd_hda_intel > snd_hda_codec snd_pcm snd_timer ac k8temp amd74xx i2c_nfor > ce2 battery snd sg serio_raw button forcedeth hwmon soundcore > snd_page_alloc ide_core joydev i2c_core sd_mod ohci_hcd ehci_ > hcd usbcore edd ahci libata scsi_mod ext3 mbcache jbd fan thermal > processor [last unloaded: led_class] > Pid: 10623, comm: tcpperf Tainted: GW 2.6.31-rc3-wl #183 > Call Trace: > [] ? b43_dma_tx+0x115/0x9b2 [b43] > [] warn_slowpath_common+0x77/0xa4 > [] warn_slowpath_null+0xf/0x11 > [] b43_dma_tx+0x115/0x9b2 [b43] > [] ? b43_op_tx+0x60/0x9e [b43] > [] b43_op_tx+0x76/0x9e [b43] > [] __ieee80211_tx+0xa3/0x104 [mac80211] > [] ieee80211_tx+0x124/0x272 [mac80211] > [] ? ieee80211_tx+0x41/0x272 [mac80211] > [] ieee80211_xmit+0x26a/0x28e [mac80211] > [] ieee80211_subif_start_xmit+0x516/0x538 [mac80211] > [] ? ieee80211_subif_start_xmit+0x20e/0x538 [mac80211] > [] ? trace_hardirqs_on_caller+0xf1/0x12f > [] ? trace_hardirqs_on+0xd/0xf > [] ? __kfree_skb+0x82/0x86 > [] dev_hard_start_xmit+0x254/0x302 > [] ? dev_hard_start_xmit+0x5e/0x302 > [] __qdisc_run+0xf5/0x208 > [] dev_queue_xmit+0x24b/0x390 > [] ? dev_queue_xmit+0x175/0x390 > [] ip_finish_output+0x239/0x27f > [] ? do_select+0x5b7/0x5d6 > [] ip_output+0xa9/0xad > [] ip_local_out+0x20/0x24 > [] ip_queue_xmit+0x2e0/0x337 > [] tcp_transmit_skb+0x600/0x643 > [] tcp_write_xmit+0x83f/0x924 > [] ? local_bh_enable+0xc9/0xce > [] tcp_push_one+0x2f/0x31 > [] tcp_sendmsg+0x7d1/0xa2e > [] sock_sendmsg+0xdf/0xf8 > [] ? might_fault+0xaf/0xb1 > [] ? autoremove_wake_function+0x0/0x38 > [] ? core_sys_select+0x3d/0x2b4 > [] ? trace_hardirqs_on_caller+0x10b/0x12f > [] ? trace_hardirqs_on+0xd/0xf > [] ? sockfd_lookup_light+0x1b/0x54 > [] sys_sendto+0xdf/0x107 > [] ? ktime_get_ts+0x49/0x4e > [] ? poll_select_copy_remaining+0xc5/0xea > [] system_call_fastpath+0x16/0x1b > ---[ end trace 3cd1097c91b647a6 ]--- > b43-phy0 warning: DMA queue overflow > > Larry > > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev > > -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
Francesco, Sorry, but I missed a warning about DMA queue overflow that was being logged as follows: [ cut here ] WARNING: at drivers/net/wireless/b43/dma.c:1342 b43_dma_tx+0x115/0x9b2 [b43]() Hardware name: HP Pavilion dv2700 Notebook PC Modules linked in: b43 ssb rng_core mac80211 cfg80211 rfkill led_class aes_x86_64 aes_gene ric af_packet snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device nfs lockd nfs_acl auth_rpcgss vboxnetadp sunrpc vboxnetflt v boxdrv cpufreq_conservative cpufreq_userspace cpufreq_powersave powernow_k8 fuse ext4 jbd2 crc16 loop dm_mod ide_cd_mod cdr om snd_hda_codec_conexant arc4 ecb ide_pci_generic snd_hda_intel snd_hda_codec snd_pcm snd_timer ac k8temp amd74xx i2c_nfor ce2 battery snd sg serio_raw button forcedeth hwmon soundcore snd_page_alloc ide_core joydev i2c_core sd_mod ohci_hcd ehci_ hcd usbcore edd ahci libata scsi_mod ext3 mbcache jbd fan thermal processor [last unloaded: led_class] Pid: 10623, comm: tcpperf Tainted: GW 2.6.31-rc3-wl #183 Call Trace: [] ? b43_dma_tx+0x115/0x9b2 [b43] [] warn_slowpath_common+0x77/0xa4 [] warn_slowpath_null+0xf/0x11 [] b43_dma_tx+0x115/0x9b2 [b43] [] ? b43_op_tx+0x60/0x9e [b43] [] b43_op_tx+0x76/0x9e [b43] [] __ieee80211_tx+0xa3/0x104 [mac80211] [] ieee80211_tx+0x124/0x272 [mac80211] [] ? ieee80211_tx+0x41/0x272 [mac80211] [] ieee80211_xmit+0x26a/0x28e [mac80211] [] ieee80211_subif_start_xmit+0x516/0x538 [mac80211] [] ? ieee80211_subif_start_xmit+0x20e/0x538 [mac80211] [] ? trace_hardirqs_on_caller+0xf1/0x12f [] ? trace_hardirqs_on+0xd/0xf [] ? __kfree_skb+0x82/0x86 [] dev_hard_start_xmit+0x254/0x302 [] ? dev_hard_start_xmit+0x5e/0x302 [] __qdisc_run+0xf5/0x208 [] dev_queue_xmit+0x24b/0x390 [] ? dev_queue_xmit+0x175/0x390 [] ip_finish_output+0x239/0x27f [] ? do_select+0x5b7/0x5d6 [] ip_output+0xa9/0xad [] ip_local_out+0x20/0x24 [] ip_queue_xmit+0x2e0/0x337 [] tcp_transmit_skb+0x600/0x643 [] tcp_write_xmit+0x83f/0x924 [] ? local_bh_enable+0xc9/0xce [] tcp_push_one+0x2f/0x31 [] tcp_sendmsg+0x7d1/0xa2e [] sock_sendmsg+0xdf/0xf8 [] ? might_fault+0xaf/0xb1 [] ? autoremove_wake_function+0x0/0x38 [] ? core_sys_select+0x3d/0x2b4 [] ? trace_hardirqs_on_caller+0x10b/0x12f [] ? trace_hardirqs_on+0xd/0xf [] ? sockfd_lookup_light+0x1b/0x54 [] sys_sendto+0xdf/0x107 [] ? ktime_get_ts+0x49/0x4e [] ? poll_select_copy_remaining+0xc5/0xea [] system_call_fastpath+0x16/0x1b ---[ end trace 3cd1097c91b647a6 ]--- b43-phy0 warning: DMA queue overflow Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
Francesco Gringoli wrote: > > Ok. I'd like to see some oopses with proprietary firmware. > > I will have to send you the laptop and the cards (happens with both > cards I have of that kind) because there is nothing written on > display, it simply gets freeze. Does the laptop have a serial port? In that case you could enable serial console and maybe get some debugging information out. Alternatively netconsole. Possibly even USB debug console, but for that you need a debug class device: http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=12083 //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
On Friday 24 July 2009 11:57:02 Francesco Gringoli wrote: > > Ok. I'd like to see some oopses with proprietary firmware. > I will have to send you the laptop and the cards (happens with both > cards I have of that kind) because there is nothing written on > display, it simply gets freeze. I also tried to enable the debug > features such as magic system request keys to print something but they > do not work. However the board is different than the one Larry > reported the problem and in my case it can be something due to some > hardware incompatibility. Did you try things like the hangcheck timer? Just enable all kernel hacking options. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
On Jul 24, 2009, at 11:43 AM, Michael Buesch wrote: > On Friday 24 July 2009 02:13:38 Francesco Gringoli wrote: >> >> Hello Michael, >> >> yes, you are right. I was referring to something like mov 0x, >> HOST_MEM[random]. >> >> Jokes apart, I really didn't think about this possibility but I >> believe your idea is correct. I originally thought, reading the >> specs, >> that the dma controller can be configured not only with the base >> address but also with a "Descriptor Stop Index", and I thought this >> was an upper limit to the memory it can use, beyond that the >> controller would have turned down to the beginning of the ring. >> Instead I see from the kernel code that there is not such kind of >> limit, is it right? Is it the kernel responsible of taking down the >> controller to the first slot when the dma reserved memory is >> exhausted >> (by writing zero in B43_DMA64_RXINDEX)? Sorry for these questions but >> I'm missing some details. > > Well it depends on the architecture to which places the DMA > controller can write. > On i386 it can write pretty much anywhere. On x86_64 it can probably > only write to mapped areas due to the IOMMU. > > The engine is supposed to wrap reading/writing at the descriptor > table end marker > and should stop at the index marker. As I wrote to Larry I decided to buy that kind of card. When I get it I will try to reproduce that problem and catch the bug. Thanks for clarifying the DMA. >>>> I suppose that the issue on pccard32 >>>> hardware is not yet solved. >>> >>> Which issue? >> The one we are talking about, reported by Larry for some pccard32 >> boards where the opensource firmware crashes. We did several testing >> with a few 4306 pccard32s the first time Larry reported the problem >> but unfortunately that hardware has different problems and crashes >> also with the original firmware. > > Ok. I'd like to see some oopses with proprietary firmware. I will have to send you the laptop and the cards (happens with both cards I have of that kind) because there is nothing written on display, it simply gets freeze. I also tried to enable the debug features such as magic system request keys to print something but they do not work. However the board is different than the one Larry reported the problem and in my case it can be something due to some hardware incompatibility. >>> This crash does _not_ happen with proprietary firmware. >>> The only way dev->fw.rev could crash is by dev being NULL. >> Got it! > > Ok, NULL was a typo. I meant "invalid" instead. > > -- Cheers, -Francesco "INFORMATIVA SUL TRATTAMENTO DEI DATI PERSONALI" I dati utilizzati per l'invio del presente messaggio sono trattati dall' Universita' degli studi di Brescia esclusivamente per finalita' istituzionali. Informazioni piu' dettagliate anche in ordine ai diritti dell'interessato sono riposte nell'informativa generale e nelle notizie pubblicate sul sito web dell'Ateneo nella sezione "privacy". Il contenuto di questo messaggio e' rivolto unicamente alle persone cui e' indirizzato e puo' contenere informazioni la cui riservatezza e' tutelata legalmente. Ne sono vietati la riproduzione, la diffusione e l'uso in mancanza di autorizzazione del destinatario. Qualora il messaggio fosse pervenuto per errore, preghiamo di eliminarlo. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
On Friday 24 July 2009 02:13:38 Francesco Gringoli wrote: > > On Jul 23, 2009, at 11:29 PM, Michael Buesch wrote: > > > On Thursday 23 July 2009 17:18:24 Francesco Gringoli wrote: > >> On Jul 23, 2009, at 11:18 AM, Michael Buesch wrote: > >> > >>> On Thursday 23 July 2009 04:05:17 Larry Finger wrote: > >>>> Francesco Gringoli wrote: > >>>>> Larry, I think this could be one of the causes of the > >>>>> malfunctioning you > >>>>> reported before. If you have some time (and indeed if you feel > >>>>> like > >>>>> doing it :-) ) please test this firmware, it will be great. > >>>> > >>>> Francesco, > >>>> > >>>> The system ran about 30 minutes, then crashed. I missed the first > >>>> oops, but caught a kernel panic with formal traceback on my i386 > >>>> system: > >>>> > >>>> b43_dma_handle_txstatus + 0x1ee/0x2fa > >>>> b43_handle_txstatus + 0x45/0x52 > >>>> > >>>> The call in b43_dma_handle_status is at line 1405: > >>>> > >>>> unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len, > >>>>1); > >>>> > >>>> The oops was in drivers/net/wireless/b43/xmit.h:171 in the call to > >>>> b43_is_old_txhdr_format(). It appears that dev->fw.rev causes the > >>>> oops. > >>> > >>> How is that possible? Is the firmware clobbering random memory? > >> > >> I don't think that the value was modified by the firmware. It cannot > >> poke values into host memory ;-) > > > > Oh yes it can. It has a DMA engine. > Hello Michael, > > yes, you are right. I was referring to something like mov 0x, > HOST_MEM[random]. > > Jokes apart, I really didn't think about this possibility but I > believe your idea is correct. I originally thought, reading the specs, > that the dma controller can be configured not only with the base > address but also with a "Descriptor Stop Index", and I thought this > was an upper limit to the memory it can use, beyond that the > controller would have turned down to the beginning of the ring. > Instead I see from the kernel code that there is not such kind of > limit, is it right? Is it the kernel responsible of taking down the > controller to the first slot when the dma reserved memory is exhausted > (by writing zero in B43_DMA64_RXINDEX)? Sorry for these questions but > I'm missing some details. Well it depends on the architecture to which places the DMA controller can write. On i386 it can write pretty much anywhere. On x86_64 it can probably only write to mapped areas due to the IOMMU. The engine is supposed to wrap reading/writing at the descriptor table end marker and should stop at the index marker. > >> I suppose that the issue on pccard32 > >> hardware is not yet solved. > > > > Which issue? > The one we are talking about, reported by Larry for some pccard32 > boards where the opensource firmware crashes. We did several testing > with a few 4306 pccard32s the first time Larry reported the problem > but unfortunately that hardware has different problems and crashes > also with the original firmware. Ok. I'd like to see some oopses with proprietary firmware. > > This crash does _not_ happen with proprietary firmware. > > The only way dev->fw.rev could crash is by dev being NULL. > Got it! Ok, NULL was a typo. I meant "invalid" instead. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
On Jul 24, 2009, at 3:44 AM, Larry Finger wrote: > Francesco Gringoli wrote: >>> >>> >> Hi Larry, >> >> Last time (it was February I believe) I didn't buy anything because I >> was involved in other projects. So again I ask you if I can place an >> order for this item >> >> http://cgi.ebay.com/HP-PCI-E-Broadcom-4312-wifi-card-generation-of-4311_W0QQitemZ320388697319QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item4a98a78ce7&_trksid=p3286.c0.m14&_trkparms=65%3A12%7C66%3A2%7C39%3A1%7C72%3A1234%7C293%3A1%7C294%3A50#ht_2507wt_1012 > > You must be careful with BCM4312 units as some of them have rev 5 > cores, but some have LP PHYs. The correct HP Part Number is > 459263-001. The one you looked at is 459263-002, which has the LP PHY. > One other criterion is the -001 is an 802.11abg unit, whereas the -002 > is 802.11bg. > > The one in the listing below is the correct model. Unfortunately, it > is in Malaysia and the shipping will be high. > http://cgi.ebay.com.my/ws/eBayISAPI.dll?ViewItem&item=150358107902 > > If there is a problem finding one at a reasonable price, I would be > willing to ship mine to you. Hi Larry, Don't matter, I just bought a couple of 4312 rev1 from the sellers you pointed out (just in case one adapter was broken...) I will start testing as soon as I get them. > > > I got the dump from a second error from my PCIe card. It hit the > BUG_ON(!meta->skb) in b43_dma_handle_txstatus() (Line 1414 of > drivers/net/wireless/b43/dma.c). In the first one I reported, > meta->skb was not NULL, and it crashed during the > unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len, 1). I think having the hardware is mandatory because we are now doing stress testing using a number of 4318s and also several linksys WRT54GL and we can never observe a crash. After the last improvement the boards get never halted. So there should be something that must be handled differently on 4312/001. We will discover... Many thanks for your help, Cheers, -Francesco > > > Larry > > "INFORMATIVA SUL TRATTAMENTO DEI DATI PERSONALI" I dati utilizzati per l'invio del presente messaggio sono trattati dall' Universita' degli studi di Brescia esclusivamente per finalita' istituzionali. Informazioni piu' dettagliate anche in ordine ai diritti dell'interessato sono riposte nell'informativa generale e nelle notizie pubblicate sul sito web dell'Ateneo nella sezione "privacy". Il contenuto di questo messaggio e' rivolto unicamente alle persone cui e' indirizzato e puo' contenere informazioni la cui riservatezza e' tutelata legalmente. Ne sono vietati la riproduzione, la diffusione e l'uso in mancanza di autorizzazione del destinatario. Qualora il messaggio fosse pervenuto per errore, preghiamo di eliminarlo. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
Francesco Gringoli wrote: > > On Jul 24, 2009, at 1:24 AM, Larry Finger wrote: > >> Francesco Gringoli wrote: >>> On Jul 23, 2009, at 4:05 AM, Larry Finger wrote: >>> Francesco Gringoli wrote: > Larry, I think this could be one of the causes of the > malfunctioning you > reported before. If you have some time (and indeed if you feel like > doing it :-) ) please test this firmware, it will be great. Francesco, The system ran about 30 minutes, then crashed. I missed the first oops, but caught a kernel panic with formal traceback on my i386 system: >> >> I had a kernel panic while testing the open firmware on a BCM4312 >> 802.11abg model (rev 01). The b/g section is just like a BCM4311/1. I >> was not watching the error console, so I have no dump information, but >> will do that next. >> >> Larry > Hi Larry, > > Last time (it was February I believe) I didn't buy anything because I > was involved in other projects. So again I ask you if I can place an > order for this item > > http://cgi.ebay.com/HP-PCI-E-Broadcom-4312-wifi-card-generation-of-4311_W0QQitemZ320388697319QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item4a98a78ce7&_trksid=p3286.c0.m14&_trkparms=65%3A12%7C66%3A2%7C39%3A1%7C72%3A1234%7C293%3A1%7C294%3A50#ht_2507wt_1012 You must be careful with BCM4312 units as some of them have rev 5 cores, but some have LP PHYs. The correct HP Part Number is 459263-001. The one you looked at is 459263-002, which has the LP PHY. One other criterion is the -001 is an 802.11abg unit, whereas the -002 is 802.11bg. The one in the listing below is the correct model. Unfortunately, it is in Malaysia and the shipping will be high. http://cgi.ebay.com.my/ws/eBayISAPI.dll?ViewItem&item=150358107902 If there is a problem finding one at a reasonable price, I would be willing to ship mine to you. I got the dump from a second error from my PCIe card. It hit the BUG_ON(!meta->skb) in b43_dma_handle_txstatus() (Line 1414 of drivers/net/wireless/b43/dma.c). In the first one I reported, meta->skb was not NULL, and it crashed during the unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len, 1). Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
On Jul 23, 2009, at 11:29 PM, Michael Buesch wrote: > On Thursday 23 July 2009 17:18:24 Francesco Gringoli wrote: >> On Jul 23, 2009, at 11:18 AM, Michael Buesch wrote: >> >>> On Thursday 23 July 2009 04:05:17 Larry Finger wrote: >>>> Francesco Gringoli wrote: >>>>> Larry, I think this could be one of the causes of the >>>>> malfunctioning you >>>>> reported before. If you have some time (and indeed if you feel >>>>> like >>>>> doing it :-) ) please test this firmware, it will be great. >>>> >>>> Francesco, >>>> >>>> The system ran about 30 minutes, then crashed. I missed the first >>>> oops, but caught a kernel panic with formal traceback on my i386 >>>> system: >>>> >>>> b43_dma_handle_txstatus + 0x1ee/0x2fa >>>> b43_handle_txstatus + 0x45/0x52 >>>> >>>> The call in b43_dma_handle_status is at line 1405: >>>> >>>> unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len, >>>>1); >>>> >>>> The oops was in drivers/net/wireless/b43/xmit.h:171 in the call to >>>> b43_is_old_txhdr_format(). It appears that dev->fw.rev causes the >>>> oops. >>> >>> How is that possible? Is the firmware clobbering random memory? >> >> I don't think that the value was modified by the firmware. It cannot >> poke values into host memory ;-) > > Oh yes it can. It has a DMA engine. Hello Michael, yes, you are right. I was referring to something like mov 0x, HOST_MEM[random]. Jokes apart, I really didn't think about this possibility but I believe your idea is correct. I originally thought, reading the specs, that the dma controller can be configured not only with the base address but also with a "Descriptor Stop Index", and I thought this was an upper limit to the memory it can use, beyond that the controller would have turned down to the beginning of the ring. Instead I see from the kernel code that there is not such kind of limit, is it right? Is it the kernel responsible of taking down the controller to the first slot when the dma reserved memory is exhausted (by writing zero in B43_DMA64_RXINDEX)? Sorry for these questions but I'm missing some details. >> I suppose that the issue on pccard32 >> hardware is not yet solved. > > Which issue? The one we are talking about, reported by Larry for some pccard32 boards where the opensource firmware crashes. We did several testing with a few 4306 pccard32s the first time Larry reported the problem but unfortunately that hardware has different problems and crashes also with the original firmware. > This crash does _not_ happen with proprietary firmware. > The only way dev->fw.rev could crash is by dev being NULL. Got it! Many thanks, -Francesco "INFORMATIVA SUL TRATTAMENTO DEI DATI PERSONALI" I dati utilizzati per l'invio del presente messaggio sono trattati dall' Universita' degli studi di Brescia esclusivamente per finalita' istituzionali. Informazioni piu' dettagliate anche in ordine ai diritti dell'interessato sono riposte nell'informativa generale e nelle notizie pubblicate sul sito web dell'Ateneo nella sezione "privacy". Il contenuto di questo messaggio e' rivolto unicamente alle persone cui e' indirizzato e puo' contenere informazioni la cui riservatezza e' tutelata legalmente. Ne sono vietati la riproduzione, la diffusione e l'uso in mancanza di autorizzazione del destinatario. Qualora il messaggio fosse pervenuto per errore, preghiamo di eliminarlo. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
On Jul 24, 2009, at 1:24 AM, Larry Finger wrote: > Francesco Gringoli wrote: >> On Jul 23, 2009, at 4:05 AM, Larry Finger wrote: >> >>> Francesco Gringoli wrote: Larry, I think this could be one of the causes of the malfunctioning you reported before. If you have some time (and indeed if you feel like doing it :-) ) please test this firmware, it will be great. >>> >>> Francesco, >>> >>> The system ran about 30 minutes, then crashed. I missed the first >>> oops, but caught a kernel panic with formal traceback on my i386 >>> system: > > I had a kernel panic while testing the open firmware on a BCM4312 > 802.11abg model (rev 01). The b/g section is just like a BCM4311/1. I > was not watching the error console, so I have no dump information, but > will do that next. > > Larry Hi Larry, Last time (it was February I believe) I didn't buy anything because I was involved in other projects. So again I ask you if I can place an order for this item http://cgi.ebay.com/HP-PCI-E-Broadcom-4312-wifi-card-generation-of-4311_W0QQitemZ320388697319QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item4a98a78ce7&_trksid=p3286.c0.m14&_trkparms=65%3A12%7C66%3A2%7C39%3A1%7C72%3A1234%7C293%3A1%7C294%3A50#ht_2507wt_1012 I hope the link is ok, otherwise you can get the picture from here http://www.ing.unibs.it/~gringoli/4312.png Tell me it's ok, I will order immediately, without the board I can't debug. Many thanks, -Francesco "INFORMATIVA SUL TRATTAMENTO DEI DATI PERSONALI" I dati utilizzati per l'invio del presente messaggio sono trattati dall' Universita' degli studi di Brescia esclusivamente per finalita' istituzionali. Informazioni piu' dettagliate anche in ordine ai diritti dell'interessato sono riposte nell'informativa generale e nelle notizie pubblicate sul sito web dell'Ateneo nella sezione "privacy". Il contenuto di questo messaggio e' rivolto unicamente alle persone cui e' indirizzato e puo' contenere informazioni la cui riservatezza e' tutelata legalmente. Ne sono vietati la riproduzione, la diffusione e l'uso in mancanza di autorizzazione del destinatario. Qualora il messaggio fosse pervenuto per errore, preghiamo di eliminarlo. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
Francesco Gringoli wrote: > On Jul 23, 2009, at 4:05 AM, Larry Finger wrote: > >> Francesco Gringoli wrote: >>> Larry, I think this could be one of the causes of the malfunctioning you >>> reported before. If you have some time (and indeed if you feel like >>> doing it :-) ) please test this firmware, it will be great. >> >> Francesco, >> >> The system ran about 30 minutes, then crashed. I missed the first >> oops, but caught a kernel panic with formal traceback on my i386 system: I had a kernel panic while testing the open firmware on a BCM4312 802.11abg model (rev 01). The b/g section is just like a BCM4311/1. I was not watching the error console, so I have no dump information, but will do that next. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
On Thursday 23 July 2009 17:18:24 Francesco Gringoli wrote: > On Jul 23, 2009, at 11:18 AM, Michael Buesch wrote: > > > On Thursday 23 July 2009 04:05:17 Larry Finger wrote: > >> Francesco Gringoli wrote: > >>> Larry, I think this could be one of the causes of the > >>> malfunctioning you > >>> reported before. If you have some time (and indeed if you feel like > >>> doing it :-) ) please test this firmware, it will be great. > >> > >> Francesco, > >> > >> The system ran about 30 minutes, then crashed. I missed the first > >> oops, but caught a kernel panic with formal traceback on my i386 > >> system: > >> > >> b43_dma_handle_txstatus + 0x1ee/0x2fa > >> b43_handle_txstatus + 0x45/0x52 > >> > >> The call in b43_dma_handle_status is at line 1405: > >> > >> unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len, > >> 1); > >> > >> The oops was in drivers/net/wireless/b43/xmit.h:171 in the call to > >> b43_is_old_txhdr_format(). It appears that dev->fw.rev causes the > >> oops. > > > > How is that possible? Is the firmware clobbering random memory? > > I don't think that the value was modified by the firmware. It cannot > poke values into host memory ;-) Oh yes it can. It has a DMA engine. > I suppose that the issue on pccard32 > hardware is not yet solved. Which issue? This crash does _not_ happen with proprietary firmware. The only way dev->fw.rev could crash is by dev being NULL. > I will get a closer look at how the > overflow condition should be handled correctly when reporting txstatus > to host. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
On Jul 23, 2009, at 11:18 AM, Michael Buesch wrote: > On Thursday 23 July 2009 04:05:17 Larry Finger wrote: >> Francesco Gringoli wrote: >>> Larry, I think this could be one of the causes of the >>> malfunctioning you >>> reported before. If you have some time (and indeed if you feel like >>> doing it :-) ) please test this firmware, it will be great. >> >> Francesco, >> >> The system ran about 30 minutes, then crashed. I missed the first >> oops, but caught a kernel panic with formal traceback on my i386 >> system: >> >> b43_dma_handle_txstatus + 0x1ee/0x2fa >> b43_handle_txstatus + 0x45/0x52 >> >> The call in b43_dma_handle_status is at line 1405: >> >> unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len, >> 1); >> >> The oops was in drivers/net/wireless/b43/xmit.h:171 in the call to >> b43_is_old_txhdr_format(). It appears that dev->fw.rev causes the >> oops. > > How is that possible? Is the firmware clobbering random memory? I don't think that the value was modified by the firmware. It cannot poke values into host memory ;-) I suppose that the issue on pccard32 hardware is not yet solved. I will get a closer look at how the overflow condition should be handled correctly when reporting txstatus to host. Cheers, -Francesco "INFORMATIVA SUL TRATTAMENTO DEI DATI PERSONALI" I dati utilizzati per l'invio del presente messaggio sono trattati dall' Universita' degli studi di Brescia esclusivamente per finalita' istituzionali. Informazioni piu' dettagliate anche in ordine ai diritti dell'interessato sono riposte nell'informativa generale e nelle notizie pubblicate sul sito web dell'Ateneo nella sezione "privacy". Il contenuto di questo messaggio e' rivolto unicamente alle persone cui e' indirizzato e puo' contenere informazioni la cui riservatezza e' tutelata legalmente. Ne sono vietati la riproduzione, la diffusione e l'uso in mancanza di autorizzazione del destinatario. Qualora il messaggio fosse pervenuto per errore, preghiamo di eliminarlo. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
Francesco Gringoli wrote: > On Jul 23, 2009, at 4:05 AM, Larry Finger wrote: > >> Francesco Gringoli wrote: >>> Larry, I think this could be one of the causes of the malfunctioning you >>> reported before. If you have some time (and indeed if you feel like >>> doing it :-) ) please test this firmware, it will be great. >> >> Francesco, >> >> The system ran about 30 minutes, then crashed. I missed the first >> oops, but caught a kernel panic with formal traceback on my i386 system: >> >> b43_dma_handle_txstatus + 0x1ee/0x2fa >> b43_handle_txstatus + 0x45/0x52 >> >> The call in b43_dma_handle_status is at line 1405: >> >> unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len, >> 1); >> >> The oops was in drivers/net/wireless/b43/xmit.h:171 in the call to >> b43_is_old_txhdr_format(). It appears that dev->fw.rev causes the oops. >> >> As usual, I was running an infinite loop of tcpperf in one console and >> a flood ping in a second. >> >> Larry > Hi Larry, > > Many many thanks. > > As I focussed almost only on the firmware side during these last months, > I forgot to upgrade the kernel :-) . Which version have you used to do > the test? Are you still using the PCcard32 (rev11/a)? I will try this > summer to replicate precisely your setup. I also think it is time to use > the support provided by Michael for telling the kernel which features > are present. The dump traceback was for 2.6.31-rc1-wl. The card is a Cardbus version of the BCM4318 on i386 architecture. I have now upgraded the kernel for that machine to 2.6.31-rc3-wl, but as there have been no recent changes in b43, I expect the same result. I will be adding some diagnostics to the interrupt routine to detect bad values and get better information for your debugging. Just knowint that there was a "fatal exception in interrupt" crash isn't very helpful. I will also test with my PCIe version of a BCM4311, which also uses rev 5 firmware. That will be on x86_64 architecture. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
On Thursday 23 July 2009 04:05:17 Larry Finger wrote: > Francesco Gringoli wrote: > > Larry, I think this could be one of the causes of the malfunctioning you > > reported before. If you have some time (and indeed if you feel like > > doing it :-) ) please test this firmware, it will be great. > > Francesco, > > The system ran about 30 minutes, then crashed. I missed the first > oops, but caught a kernel panic with formal traceback on my i386 system: > > b43_dma_handle_txstatus + 0x1ee/0x2fa > b43_handle_txstatus + 0x45/0x52 > > The call in b43_dma_handle_status is at line 1405: > > unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len, > 1); > > The oops was in drivers/net/wireless/b43/xmit.h:171 in the call to > b43_is_old_txhdr_format(). It appears that dev->fw.rev causes the oops. How is that possible? Is the firmware clobbering random memory? -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
On Jul 23, 2009, at 4:05 AM, Larry Finger wrote: > Francesco Gringoli wrote: >> Larry, I think this could be one of the causes of the >> malfunctioning you >> reported before. If you have some time (and indeed if you feel like >> doing it :-) ) please test this firmware, it will be great. > > Francesco, > > The system ran about 30 minutes, then crashed. I missed the first > oops, but caught a kernel panic with formal traceback on my i386 > system: > > b43_dma_handle_txstatus + 0x1ee/0x2fa > b43_handle_txstatus + 0x45/0x52 > > The call in b43_dma_handle_status is at line 1405: > > unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len, > 1); > > The oops was in drivers/net/wireless/b43/xmit.h:171 in the call to > b43_is_old_txhdr_format(). It appears that dev->fw.rev causes the > oops. > > As usual, I was running an infinite loop of tcpperf in one console and > a flood ping in a second. > > Larry Hi Larry, Many many thanks. As I focussed almost only on the firmware side during these last months, I forgot to upgrade the kernel :-) . Which version have you used to do the test? Are you still using the PCcard32 (rev11/a)? I will try this summer to replicate precisely your setup. I also think it is time to use the support provided by Michael for telling the kernel which features are present. Cheers, -Francesco "INFORMATIVA SUL TRATTAMENTO DEI DATI PERSONALI" I dati utilizzati per l'invio del presente messaggio sono trattati dall' Universita' degli studi di Brescia esclusivamente per finalita' istituzionali. Informazioni piu' dettagliate anche in ordine ai diritti dell'interessato sono riposte nell'informativa generale e nelle notizie pubblicate sul sito web dell'Ateneo nella sezione "privacy". Il contenuto di questo messaggio e' rivolto unicamente alle persone cui e' indirizzato e puo' contenere informazioni la cui riservatezza e' tutelata legalmente. Ne sono vietati la riproduzione, la diffusione e l'uso in mancanza di autorizzazione del destinatario. Qualora il messaggio fosse pervenuto per errore, preghiamo di eliminarlo. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
Francesco Gringoli wrote: > Larry, I think this could be one of the causes of the malfunctioning you > reported before. If you have some time (and indeed if you feel like > doing it :-) ) please test this firmware, it will be great. Francesco, The system ran about 30 minutes, then crashed. I missed the first oops, but caught a kernel panic with formal traceback on my i386 system: b43_dma_handle_txstatus + 0x1ee/0x2fa b43_handle_txstatus + 0x45/0x52 The call in b43_dma_handle_status is at line 1405: unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len, 1); The oops was in drivers/net/wireless/b43/xmit.h:171 in the call to b43_is_old_txhdr_format(). It appears that dev->fw.rev causes the oops. As usual, I was running an infinite loop of tcpperf in one console and a flood ping in a second. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
oh i forgot to ask: any plan to implement QoS and/or hw crypto? On Tue, 21 Jul 2009 18:41:22 +0200 Francesco Gringoli wrote: > 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 error and the mac suspended, interface was no more > usable. This bug appears usually when the signal received from the > peer is very low, and was reported by several users. Now we can > still have phy errors in the system.log but the interface remains > fully functional (as it happens with the official firmware). > > There are also more comments in the source code with some registers > explained. > > Larry, I think this could be one of the causes of the malfunctioning > you reported before. If you have some time (and indeed if you feel > like doing it :-) ) please test this firmware, it will be great. > > Cheers, > -Francesco ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Improved opensource firmware
wow! although b43 & openfwwf already worked fine for me, i'm glad to see openfwwf is still improving after a 100 day hiatus. i'm unable to test it ATM, but anyway, thanks for your efforts! On Tue, 21 Jul 2009 18:41:22 +0200 Francesco Gringoli wrote: > 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 error and the mac suspended, interface was no more > usable. This bug appears usually when the signal received from the > peer is very low, and was reported by several users. Now we can > still have phy errors in the system.log but the interface remains > fully functional (as it happens with the official firmware). > > There are also more comments in the source code with some registers > explained. > > Larry, I think this could be one of the causes of the malfunctioning > you reported before. If you have some time (and indeed if you feel > like doing it :-) ) please test this firmware, it will be great. > > Cheers, > -Francesco ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Improved opensource firmware
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 error and the mac suspended, interface was no more usable. This bug appears usually when the signal received from the peer is very low, and was reported by several users. Now we can still have phy errors in the system.log but the interface remains fully functional (as it happens with the official firmware). There are also more comments in the source code with some registers explained. Larry, I think this could be one of the causes of the malfunctioning you reported before. If you have some time (and indeed if you feel like doing it :-) ) please test this firmware, it will be great. Cheers, -Francesco "INFORMATIVA SUL TRATTAMENTO DEI DATI PERSONALI" I dati utilizzati per l'invio del presente messaggio sono trattati dall' Universita' degli studi di Brescia esclusivamente per finalita' istituzionali. Informazioni piu' dettagliate anche in ordine ai diritti dell'interessato sono riposte nell'informativa generale e nelle notizie pubblicate sul sito web dell'Ateneo nella sezione "privacy". Il contenuto di questo messaggio e' rivolto unicamente alle persone cui e' indirizzato e puo' contenere informazioni la cui riservatezza e' tutelata legalmente. Ne sono vietati la riproduzione, la diffusione e l'uso in mancanza di autorizzazione del destinatario. Qualora il messaggio fosse pervenuto per errore, preghiamo di eliminarlo. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 the > current status > and the saved one. The results were: > > b43_dma_handle_txstatus called for deleted cookie 0x2004 > > Parameter saved_status status > cookie 0x2022 0x2004 > seq 0x1510x142 > phy_stat0x0 0x0 > frame_count 0x1 0x1 > rts_count 0x0 0x0 > supp_reason 0x0 0x0 > pm_indicat 0x0 0x0 > for_ampdu 0x0 0x0 > acked 0x1 0x1 > > Clearly quite a few transaction took place between the time that the > skb with > cookie 0x2004 was deleted and the erroring callback. The cookie > count increased > by 30 and the sequence by 15. I'm pretty sure that this means 15 > total packets > were handled in the interim. Yes it is correct. > > > Unless this report results in an immediate "light bulb" moment, I > plan to buffer > at least 32 status values so that we can see the details of all > transactions > between the first and second calls with the cookie associated with > the deleted > skb. Are there any other parameters I should also buffer? > Let's start with these parameters and see what happen. Thank you cheers Lorenzo > Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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_handle_txstatus called for deleted cookie 0x2004 Parameter saved_status status cookie 0x2022 0x2004 seq 0x1510x142 phy_stat0x0 0x0 frame_count 0x1 0x1 rts_count 0x0 0x0 supp_reason 0x0 0x0 pm_indicat 0x0 0x0 for_ampdu 0x0 0x0 acked 0x1 0x1 Clearly quite a few transaction took place between the time that the skb with cookie 0x2004 was deleted and the erroring callback. The cookie count increased by 30 and the sequence by 15. I'm pretty sure that this means 15 total packets were handled in the interim. Unless this report results in an immediate "light bulb" moment, I plan to buffer at least 32 status values so that we can see the details of all transactions between the first and second calls with the cookie associated with the deleted skb. Are there any other parameters I should also buffer? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 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 code has not been > > debugged. Please let me know if any of these data are not correct. > > > > Hi Larry, > > 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 relative > to a frame that is different with respect to the one that causes the > warning. > > Where are 0x206C-0x200A frames? Note that the dump is asynchronous wrt to the bug. The firmware will have advanced to the next frame(s) when the interrupt reaches the CPU. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 and condition codes. You can get the PC from the debug register. However, this stuff is asynchronous wrt to the firmware. So the PC would have absolutely no meaning. The interrupt takes a few microseconds to trigger and the bottom half probably takes up to a few milliseconds. So the firmware will have advanced a lot until you dump the state. For this reason I introduced the synchronous debug-irq. With this IRQ it's possible to synchronously send events to the driver and dump some state in a consistent way. However, it requires firmware support, of course. We cannot read the conditions without help of the firmware. Or at least, we don't know how to, if it's possible somehow. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 relative > to a frame that is different with respect to the one that causes the > warning. > > Where are 0x206C-0x200A frames? > > Larry, this problem is presenting only when you stress the device, or it > always causes crashes the card? In previous crashes, there has always been a number of queued tx_status responses. Perhaps the missing cookies were there. This time I stopped the microcode CPU and never restarted it, but now that it looks as if the dump is OK, I will start it again right after the dump. So far, I have only seen these crashes when I stress the device using two transmit streams - one with small packets (a flood ping) and one with large packets (the tcpperf test). Even then, it has taken as long as 7 hours to cause the crash. On other occasions, it takes just minutes. The bug must have only a narrow window to trigger. In addition, these tests were the first ones I tried. FWIW, the proprietary firmware ran my test for 12 hours without failing. Do you suggest any additional checks in the tx_status routine? Could I compare the received cookie with some part of SHM? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 condition codes. > > I think these data are correct; however, the dump code has not been > debugged. Please let me know if any of these data are not correct. > Hi Larry, 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 relative to a frame that is different with respect to the one that causes the warning. Where are 0x206C-0x200A frames? Larry, this problem is presenting only when you stress the device, or it always causes crashes the card? Thank you. Lorenzo. > Larry > > == > > b43: b43_dma_handle_txstatus called for deleted skb caused by a double > call for cookie 0x206C > > b43: Link Registers: lr0 0x03E5 lr1 0x0436 lr2 0x0049 lr3 0x0467 > > b43: Offset Registers: off0 0x042C off1 0x0508 off2 0x0374 >off3 0x0374 off4 0x00EC off5 0x00EC >off6 0xEF9F > > b43: General Registers: > > r00 0x0001 r01 0x r02 0x0004 r03 0x0002 r04 0x0002 r05 0x0002 > r06 0x001F r07 0x03FF r08 0x001F r09 0x r10 0x007E r11 0xE7B4 > r12 0x5C36 r13 0x0001 r14 0x0007 r15 0x r16 0x r17 0xAAC2 > r18 0x r19 0x r20 0x r21 0x r22 0x r23 0x > r24 0x0035 r25 0x4C1D r26 0x r27 0x000C r28 0x0001 r29 0x0003 > r30 0x0001 r31 0x5714 r32 0x0006 r33 0x013F r34 0x13C6 r35 0x042C > r36 0x0008 r37 0x r38 0x0002 r39 0x r40 0x r41 0x > r42 0x r43 0x r44 0x r45 0x r46 0x r47 0x > r48 0x r49 0x r50 0x r51 0x r52 0x r53 0x > r54 0x r55 0x r56 0x r57 0x r58 0x r59 0x > r60 0x r61 0x r62 0x r63 0x > > b43: Shared Memory: > > 0x: 0x015F 0x007E 0x 0x2EC2 0x 0x 0x0014 0x000A > 0x0010: 0x0009 0x 0x0080 0x0009 0x0047 0x0047 0x0183 0x0064 > 0x0020: 0x0930 0xFCC0 0x 0x 0x 0x 0x 0x > 0x0030: 0x0100 0x 0x0002 0x0002 0x0001 0x0004 0x001E 0x > 0x0040: 0x0002 0x 0x0003 0x0002 0x000E 0x0047 0x2800 0x > 0x0050: 0x0007 0x0002 0xFCC0 0x0582 0x110D 0x7F7F 0x000A 0x0103 > 0x0060: 0x 0x 0x0003 0x 0x 0x 0x 0x0011 > 0x0070: 0xF1F1 0xF1F1 0x0001 0x 0x 0x007E 0xE7B3 0x944F > 0x0080: 0x0006 0x2710 0x 0x 0x1012 0x0F10 0x000C 0x0207 > 0x0090: 0x 0x 0x0960 0x00FA 0x0D09 0x080A 0x010D 0x > 0x00A0: 0x0001 0x 0x 0x013F 0x 0x 0x 0x > 0x00B0: 0x 0x 0x 0x 0x 0x 0x 0x > 0x00C0: 0x 0x 0x 0x 0x 0x 0x 0x > 0x00D0: 0x 0x 0x 0x 0x 0x 0x 0x > 0x00E0: 0x 0x 0x 0x 0x 0x 0x 0x > 0x00F0: 0x 0x 0x 0x 0x 0x 0x 0x > 0x0100: 0x 0x 0x 0x 0x 0x 0x 0x > 0x0110: 0x 0x 0x 0x 0x 0x 0x 0x > 0x0120: 0x 0x 0x 0x 0x 0x 0x 0x > 0x0130: 0x 0x 0x 0x 0x 0x 0x 0x > 0x0140: 0x 0x 0x 0x 0x 0x 0x 0x > 0x0150: 0x 0x 0x 0x 0x 0x 0x 0x > 0x0160: 0x5242 0x4D43 0x545F 0x5345 0x5F54 0x5353 0x4449 0x > 0x0170: 0x 0x 0x 0x 0x 0x 0x 0x > 0x0180: 0x 0x 0x 0x 0xFCC0 0x 0x 0x > 0x0190: 0x 0x 0x 0x 0x 0x 0x 0x > 0x01A0: 0x 0x 0x 0x 0x 0x 0x 0x > 0x01B0: 0x 0x 0x 0x 0x 0x 0x 0x > 0x01C0: 0x032E 0x032E 0x032E 0x032E 0x032E 0x032E 0x032E 0x032E > 0x01D0: 0x036A 0x0356 0x0342 0x032E 0x0374 0x0360 0x034C 0x0338 > 0x01E0: 0x 0x 0x 0x 0x 0x 0x 0x > 0x01F0: 0x036A 0x0356 0x0342 0x032E 0x036A 0x0356 0x0342 0x0338 > 0x0200: 0x037E 0x037E 0x037E 0x037E 0x0389 0x037E 0x037E 0x0394 > 0x0210: 0x037E 0x037E 0x037E 0x037E 0x037E 0x037E 0x039F 0x037E > 0x0220: 0x 0x 0x 0x 0x0389 0x 0x 0x0394 > 0x0230: 0x 0x 0x037E 0x 0x 0x 0x037E 0x > 0x0240: 0x 0x0001 0x03FF 0x0001 0x0007 0x0001 0x0008 0x0100 > 0x0250: 0x 0x 0x 0x 0x 0x 0x 0x > 0x0260: 0x 0x001F 0x03FF 0x001F 0x0003 0x0013 0x0016 0x0300 > 0x0270: 0x 0x 0x 0x 0x 0x 0x 0x > 0x0280: 0x 0x0001 0x0001 0x0001 0x
Re: opensource firmware now accept version 410 frames
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 code has not been debugged. Please let me know if any of these data are not correct. Larry == b43: b43_dma_handle_txstatus called for deleted skb caused by a double call for cookie 0x206C b43: Link Registers: lr0 0x03E5 lr1 0x0436 lr2 0x0049 lr3 0x0467 b43: Offset Registers: off0 0x042C off1 0x0508 off2 0x0374 off3 0x0374 off4 0x00EC off5 0x00EC off6 0xEF9F b43: General Registers: r00 0x0001 r01 0x r02 0x0004 r03 0x0002 r04 0x0002 r05 0x0002 r06 0x001F r07 0x03FF r08 0x001F r09 0x r10 0x007E r11 0xE7B4 r12 0x5C36 r13 0x0001 r14 0x0007 r15 0x r16 0x r17 0xAAC2 r18 0x r19 0x r20 0x r21 0x r22 0x r23 0x r24 0x0035 r25 0x4C1D r26 0x r27 0x000C r28 0x0001 r29 0x0003 r30 0x0001 r31 0x5714 r32 0x0006 r33 0x013F r34 0x13C6 r35 0x042C r36 0x0008 r37 0x r38 0x0002 r39 0x r40 0x r41 0x r42 0x r43 0x r44 0x r45 0x r46 0x r47 0x r48 0x r49 0x r50 0x r51 0x r52 0x r53 0x r54 0x r55 0x r56 0x r57 0x r58 0x r59 0x r60 0x r61 0x r62 0x r63 0x b43: Shared Memory: 0x: 0x015F 0x007E 0x 0x2EC2 0x 0x 0x0014 0x000A 0x0010: 0x0009 0x 0x0080 0x0009 0x0047 0x0047 0x0183 0x0064 0x0020: 0x0930 0xFCC0 0x 0x 0x 0x 0x 0x 0x0030: 0x0100 0x 0x0002 0x0002 0x0001 0x0004 0x001E 0x 0x0040: 0x0002 0x 0x0003 0x0002 0x000E 0x0047 0x2800 0x 0x0050: 0x0007 0x0002 0xFCC0 0x0582 0x110D 0x7F7F 0x000A 0x0103 0x0060: 0x 0x 0x0003 0x 0x 0x 0x 0x0011 0x0070: 0xF1F1 0xF1F1 0x0001 0x 0x 0x007E 0xE7B3 0x944F 0x0080: 0x0006 0x2710 0x 0x 0x1012 0x0F10 0x000C 0x0207 0x0090: 0x 0x 0x0960 0x00FA 0x0D09 0x080A 0x010D 0x 0x00A0: 0x0001 0x 0x 0x013F 0x 0x 0x 0x 0x00B0: 0x 0x 0x 0x 0x 0x 0x 0x 0x00C0: 0x 0x 0x 0x 0x 0x 0x 0x 0x00D0: 0x 0x 0x 0x 0x 0x 0x 0x 0x00E0: 0x 0x 0x 0x 0x 0x 0x 0x 0x00F0: 0x 0x 0x 0x 0x 0x 0x 0x 0x0100: 0x 0x 0x 0x 0x 0x 0x 0x 0x0110: 0x 0x 0x 0x 0x 0x 0x 0x 0x0120: 0x 0x 0x 0x 0x 0x 0x 0x 0x0130: 0x 0x 0x 0x 0x 0x 0x 0x 0x0140: 0x 0x 0x 0x 0x 0x 0x 0x 0x0150: 0x 0x 0x 0x 0x 0x 0x 0x 0x0160: 0x5242 0x4D43 0x545F 0x5345 0x5F54 0x5353 0x4449 0x 0x0170: 0x 0x 0x 0x 0x 0x 0x 0x 0x0180: 0x 0x 0x 0x 0xFCC0 0x 0x 0x 0x0190: 0x 0x 0x 0x 0x 0x 0x 0x 0x01A0: 0x 0x 0x 0x 0x 0x 0x 0x 0x01B0: 0x 0x 0x 0x 0x 0x 0x 0x 0x01C0: 0x032E 0x032E 0x032E 0x032E 0x032E 0x032E 0x032E 0x032E 0x01D0: 0x036A 0x0356 0x0342 0x032E 0x0374 0x0360 0x034C 0x0338 0x01E0: 0x 0x 0x 0x 0x 0x 0x 0x 0x01F0: 0x036A 0x0356 0x0342 0x032E 0x036A 0x0356 0x0342 0x0338 0x0200: 0x037E 0x037E 0x037E 0x037E 0x0389 0x037E 0x037E 0x0394 0x0210: 0x037E 0x037E 0x037E 0x037E 0x037E 0x037E 0x039F 0x037E 0x0220: 0x 0x 0x 0x 0x0389 0x 0x 0x0394 0x0230: 0x 0x 0x037E 0x 0x 0x 0x037E 0x 0x0240: 0x 0x0001 0x03FF 0x0001 0x0007 0x0001 0x0008 0x0100 0x0250: 0x 0x 0x 0x 0x 0x 0x 0x 0x0260: 0x 0x001F 0x03FF 0x001F 0x0003 0x0013 0x0016 0x0300 0x0270: 0x 0x 0x 0x 0x 0x 0x 0x 0x0280: 0x 0x0001 0x0001 0x0001 0x0002 0x 0x0002 0x0100 0x0290: 0x 0x 0x 0x 0x 0x 0x 0x 0x02A0: 0x 0x000F 0x03FF 0x000F 0x0002 0x000E 0x0010 0x0100 0x02B0: 0x 0x 0x 0x 0x 0x 0x 0x 0x02C0: 0x 0x 0x 0x 0x 0x 0x 0x 0x02D0: 0x 0x 0x 0x 0x 0x 0x0002 0x 0x02E0: 0x 0x 0x 0x 0x 0x 0x 0x 0x02F0: 0x 0x 0x 0x 0x 0x 0x 0x 0x0300: 0x 0x 0x 0x 0x 0x 0x 0x 0x0310: 0x 0x 0x 0x 0x 0x 0x 0x 0x0320: 0x 0x 0x 0x 0x 0x 0x 0x 0x0330: 0x 0x 0x 0x 0x 0x 0
Re: opensource firmware now accept version 410 frames
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 are O2 Micro, Inc. OZ6832/6833 Cardbus Controller (rev 34) Yenta_socket is definitely the module used by this device. > > I always believed it was 32-bit (isn't it?) and I used it without > problems for a long time with an Atheros controller so I believe it is > not broken. If lspci sees the card as well as the bridge, it is 32 bit. I'm about to start my test using my BCM4318 and the proprietary firmware. I don't expect any failure, but I'll let it run for at least 14 hours, which is twice as long as the longest successful run with the open firmware. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 several tests and everything was fine. Today, instead, I brought both laptop and cardbus adapter into the lab and each time I begin to download even very small files, it crashes. This happens with both openfwwf and original Broadcom firmware. I tested another cardbus adapter (though I believe they are the same, both Belkin) and it crashes too. Switching back to internal mini-pci, instead, I have no problems. Unfortunately I do not observe any message from console, I set /proc/ sys/kernel/printk to log everything but the system simply hangs and I have to switch it off. The only difference between the lab and my home networks is that here (lab) we have several SSIDs broadcasted, I can clearly observe tens of APs on the same channel and a lot of background traffic. Note that the PC is rock solid, it never crashes in other conditions. The same situation appears with two cardbus adapters so I can't believe they are both broken and independently of the cardbus slot I plug the network adapter into. 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) I always believed it was 32-bit (isn't it?) and I used it without problems for a long time with an Atheros controller so I believe it is not broken. Cheers -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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
+++ wireless-testing/drivers/net/wireless/b43/dma.c
@@ -40,6 +40,7 @@
#include
#include
+static int b43_freeze = 0;
/* 32bit DMA ops. */
static
@@ -1292,6 +1293,8 @@ int b43_dma_tx(struct b43_wldev *dev, st
unsigned long flags;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ if (b43_freeze)
+ return -ENOMEM;
hdr = (struct ieee80211_hdr *)skb->data;
if (info->flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM) {
/* The multicast ring will be sent after the DTIM */
@@ -1372,7 +1375,11 @@ void b43_dma_handle_txstatus(struct b43_
while (1) {
B43_WARN_ON(!(slot >= 0 && slot < ring->nr_slots));
desc = ops->idx2desc(ring, slot, &meta);
-
+ if (meta->skb == 0x6b6b6b6b) {
+ printk(KERN_INFO "b43: Double call of b43_dma_handle_"
+ "txstatus for cookie 0x%X\n", status->cookie);
+ meta->skb = NULL;
+ }
if (meta->skb)
unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len,
1);
@@ -1383,7 +1390,13 @@ void b43_dma_handle_txstatus(struct b43_
if (meta->is_last_fragment) {
struct ieee80211_tx_info *info;
- BUG_ON(!meta->skb);
+ if (!meta->skb) {
+ printk(KERN_INFO "b43: Cookie is 0x%X for bad
skb\n",
status->cookie);
+ printk(KERN_INFO "b43: DMA Output is frozen\n");
+ b43_freeze = 1;
+ B43_WARN_ON(1);
+ return;
+ }
info = IEEE80211_SKB_CB(meta->skb);
@@ -1402,7 +1415,7 @@ void b43_dma_handle_txstatus(struct b43_
ieee80211_tx_status_irqsafe(dev->wl->hw, meta->skb);
/* skb is freed by ieee80211_tx_status_irqsafe() */
- meta->skb = NULL;
+ meta->skb = 0x6b6b6b6b;
} else {
/* No need to call free_descriptor_buffer here, as
* this is only the txhdr, which is not allocated.
Besides freezing TX when an error occurs, I also "poisoned" meta->skb rather
than making
it NULL after the call to ieee80211_tx_status_irqsafe(). I could then detect a
double call
with the same cookie, which is exactly what happened.
I will now have time to code a dump of shared memory when the error occurs, but
we do know
what the mistake is.
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 without crashing the system? > > I don't mind. Just to clarify your question. Will you be sending me > both new firmware and a kernel patch? Many thanks. I'm preparing them, I will send them ASAP. > BTW, I realized I missed an earlier question of yours. My BCM4318 is > CardBus, i.e. 32 bit. > > Larry > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 to clarify your question. Will you be sending me both new firmware and a kernel patch? BTW, I realized I missed an earlier question of yours. My BCM4318 is CardBus, i.e. 32 bit. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 transmits queued. >>> The cookies were 0x2048 and 0x204A. >>> >>> Larry >>> >> I'm happier now... though this means very hard debugging. It would be >> great if you can crash the original firmware too ;-) If it happens >> tell us... > > Don't you think this is a bit unlikely? We're using the proprietary > firmware > since, well,... ever? This particular version is in use since about > a year. > We didn't have a single report of this. > 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? Cheers, -FG > > -- > 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/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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. > > > > Larry > > > I'm happier now... though this means very hard debugging. It would be > great if you can crash the original firmware too ;-) If it happens > tell us... Don't you think this is a bit unlikely? We're using the proprietary firmware since, well,... ever? This particular version is in use since about a year. We didn't have a single report of this. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 would be great if you can crash the original firmware too ;-) If it happens tell us... Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 at the time the crash would trigger? Are > > there holes > > in the ring memory? What does the crashing cookie point to? The end of the > > ring (aprox) > > or somewhere completely different. > > printk printk printk printk... :) > > > > Now that I'm not crashing Linux when it happens, I know a little more > about what happens. My last test with 5.1 firmware ran nearly 7 hours > before it died. At that point, ifconfig reported 25,407,000 packets > received for a total of 1,944 MB, and 36,843,000 packets transmitted > for a total of 596 MB. Those numbers for the MB transferred are not > what I expected - the flood ping should TX and RX equal numbers of > small packets, and the tcpperf run should TX large packets and RX only > ACKs. > > In my latest run, I froze the TX queue when the first error occurred. > When that happened, there were still 6 more entries in the TX queue. > The cookies were all in the same sequence: 0x204A, 0x204E, 0x2050, > 0x2052, 0x2054, 0x2056, and 0x205A. What happened to 0x2058? And 4C The DMA implementation requires slots on one DMA queue to be reported in the correct sequencial order. And it also requires them all to be reported. Otherwise the slot counts (used_slots, current_slot) go wrong. If you don't keep the strict order it will result in memory leaks and/or double-frees. The double-free is detected by the BUG_ON in question. There's no leak detection, so it will silently leak. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 the ring memory? What does the crashing cookie point to? The end of the > ring (aprox) > or somewhere completely different. > printk printk printk printk... :) > Now that I'm not crashing Linux when it happens, I know a little more about what happens. My last test with 5.1 firmware ran nearly 7 hours before it died. At that point, ifconfig reported 25,407,000 packets received for a total of 1,944 MB, and 36,843,000 packets transmitted for a total of 596 MB. Those numbers for the MB transferred are not what I expected - the flood ping should TX and RX equal numbers of small packets, and the tcpperf run should TX large packets and RX only ACKs. In my latest run, I froze the TX queue when the first error occurred. When that happened, there were still 6 more entries in the TX queue. The cookies were all in the same sequence: 0x204A, 0x204E, 0x2050, 0x2052, 0x2054, 0x2056, and 0x205A. What happened to 0x2058? I'm pretty busy today with the "Super Bowl", but I'm going to start a long run with 5.0 firmware. My last run showed that the failure can take a long time and that my previous tests may have missed an error. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 not completely sure on that one. But external > > condition would be my > > first bet, as we have lots of other external conditions for other > > overflow conditions. > Well, the handler that reports status to host waits for a couple of > external conditions, looping until they are satisfied: we left that > about crypto because all times we removed something about crypto > everything went bad, even if it seemed useless, do not consider it > now. The other condition, instead, is the same that is checked before > sending a received frame to host through _dma_, isn't it strange? > There is no conditioning instead that prevents the IRQ about tx status > reporting to be raised once we entered the reporting handler, and we > jump into it after each sending. So each time we enter the report > status handler, the IRQ is raised. So I think that the conditions you > are talking can only be those two I said here above, no other bit is > checked, and your bet was right :) I think you're looking at the wrong place. The check for the tx status queue must be a _lot_ earlier. It must be even before we route the frame from the DMA engine to the TXE. I bet it's one of the very first conditions that start the TX operation. The basic idea is that we must check all buffers, including the tx status report buffer, before we start the TX operation. Because if we started it and we notice right in the middle of the operation that we lack bufferspace somewhere, we're screwed. That's my theory. I cannot back it up with facts, but it sounds sane to me. 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 the ring memory? What does the crashing cookie point to? The end of the ring (aprox) or somewhere completely different. printk printk printk printk... :) -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 not completely sure on that one. But external > > condition would be my > > first bet, as we have lots of other external conditions for other > > overflow conditions. > > For my understanding of what's going on with Larry's adapter, may I > kindly ask you if the following picture is correct? > > I simply put a printk just at the top of op32_poke_tx and another in > handle_irq_transmit_status. I injected as mush traffic as I can by > sending UDP style frames through a raw socket to the wireless > interface, I send ten thousands packets so to enter a "regime" > condition: after the first hundreds packets are sent, I see from > dmesg a op32_poke_tx line followed by a handle_irq_transmit_status > line, these two couple of lines repeated thousands times. More > interesting is what happens at the end when I stop sending packets on > the raw socket: the kernel stops filling the queue, and in dmesg we > can see only handle_irq_transmit_status lines corresponding to frames > still in the tx fifo. The firmware is removing these last packets and > for each of them it will send a IRQ after sending. It always turn out > that the queue had 64 packets inside, I always see 64 consecutive > lines about handle_irq_transmit_stats. Is this number (64) due to the > definition Yes it is. You need two slots per data packet. > If this is correct, the condition observed by Larry could be due to > some packets being lost during their travel in the fifo run by the dma > system? Well I'm not completely sure what's going on exactly. I only know that we get bad cookies that the driver doesn't expect. > It seems that the firmware is reporting status for not all > packets that have been sent through the dma, Whoopsy, it is _required_ to report status for every single packet. That's a basic assumption that must not be violated, as it's used for freeing the DMA memory in the driver. However, it should not corrupt anything. It will just grind the DMA to a halt 64 packets after a status report was missed. I never tried this, however. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 > first bet, as we have lots of other external conditions for other > overflow conditions. For my understanding of what's going on with Larry's adapter, may I kindly ask you if the following picture is correct? I simply put a printk just at the top of op32_poke_tx and another in handle_irq_transmit_status. I injected as mush traffic as I can by sending UDP style frames through a raw socket to the wireless interface, I send ten thousands packets so to enter a "regime" condition: after the first hundreds packets are sent, I see from dmesg a op32_poke_tx line followed by a handle_irq_transmit_status line, these two couple of lines repeated thousands times. More interesting is what happens at the end when I stop sending packets on the raw socket: the kernel stops filling the queue, and in dmesg we can see only handle_irq_transmit_status lines corresponding to frames still in the tx fifo. The firmware is removing these last packets and for each of them it will send a IRQ after sending. It always turn out that the queue had 64 packets inside, I always see 64 consecutive lines about handle_irq_transmit_stats. Is this number (64) due to the definition #define B43_TXRING_SLOTS128 in dma.h? For what I understand a slot is used for tx header, the other for the actual packet, isn'it? So we have half of 128 slots for 64 packets. If this is correct, the condition observed by Larry could be due to some packets being lost during their travel in the fifo run by the dma system? It seems that the firmware is reporting status for not all packets that have been sent through the dma, but we know that the firmware always reports status _unless_ the mac ctl register is set to skip status reporting. Could we investigate on this or I'm completely wrong? Cheers, -Francesco ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 > first bet, as we have lots of other external conditions for other > overflow conditions. Well, the handler that reports status to host waits for a couple of external conditions, looping until they are satisfied: we left that about crypto because all times we removed something about crypto everything went bad, even if it seemed useless, do not consider it now. The other condition, instead, is the same that is checked before sending a received frame to host through _dma_, isn't it strange? There is no conditioning instead that prevents the IRQ about tx status reporting to be raised once we entered the reporting handler, and we jump into it after each sending. So each time we enter the report status handler, the IRQ is raised. So I think that the conditions you are talking can only be those two I said here above, no other bit is checked, and your bet was right :) Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 grow it more than one hundred elements > > and status continues to be correctly reported. > > I think you still probably didn't get it. > The TX status queue has _nothing_ to do with the DMA queues/rings/slots > or the PIO queues. These are _completely_ independent queues. > Just _completely_ forget about DMA and PIO when dealing with TX status. > > The TX status queue is only about 16 elements (give or take a couple) on all > devices. I'm not sure if it's possible to read the queue size from somewhere. > It probably isn't. I think the overflow protection works through external > conditions > in the firmware. So there is some external condition that flags "tx status > queue is full" > and the firmware will neither try to queue the status report, nor try to > transmit yet > another frame. It will simply wait for the driver to fetch at least one entry > from > the queue. The external condition will flip and the firmware goes on. > (However, I think the firmware probably can receive new frames while waiting > for > the tx status queue to get one free entry.) 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 first bet, as we have lots of other external conditions for other overflow conditions. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 be correctly reported. I think you still probably didn't get it. The TX status queue has _nothing_ to do with the DMA queues/rings/slots or the PIO queues. These are _completely_ independent queues. Just _completely_ forget about DMA and PIO when dealing with TX status. The TX status queue is only about 16 elements (give or take a couple) on all devices. I'm not sure if it's possible to read the queue size from somewhere. It probably isn't. I think the overflow protection works through external conditions in the firmware. So there is some external condition that flags "tx status queue is full" and the firmware will neither try to queue the status report, nor try to transmit yet another frame. It will simply wait for the driver to fetch at least one entry from the queue. The external condition will flip and the firmware goes on. (However, I think the firmware probably can receive new frames while waiting for the tx status queue to get one free entry.) -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 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 report a tx status it will send the informations to the > DMA. > The DMA won't have enough space to store it and so it will drop > the > message. In your opinion is it possible that something like that > happened? No. TX status isn't passed through DMA in >=rev5 cores. It's passed through MMIO registers which access an internal hardware queue. >>> Michael, >>> >>> sorry, I have a question, there is a piece of code I do not >>> understand. I see from specs that this queue (that is filled by the >>> firmware to report status to host) _seems_ to be 16 positions >>> long. I >>> would say that this value should be taken as an upper limit in the >>> number of frames sent on the dma and still not acked (positively or >>> not, depending on tx success) by the firmware. Is this correct? I >>> did >>> some tests and I saw that the number of frames sent through >>> op32_poke_tx before corresponding status being reported greatly >>> exceeds 16. >> >> The driver just puts the stuff into the DMA ring. It can put as >> much stuff >> into the ring as it wants, as it allocated the ring. >> >> The _firmware_ must make sure to accept new packets from dma _only_ >> if >> its buffers are not filled. That includes the tx status report >> buffer. > > The tx-status-queue-full condition most likely is an external > condition > in the firmware. Don't ask me which one, however. 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 be correctly reported. Cheers, -FG > > > -- > 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/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 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 report a tx status it will send the informations to the DMA. > > >> The DMA won't have enough space to store it and so it will drop the > > >> message. In your opinion is it possible that something like that > > >> happened? > > > > > > No. TX status isn't passed through DMA in >=rev5 cores. > > > It's passed through MMIO registers which access an internal hardware > > > queue. > > Michael, > > > > sorry, I have a question, there is a piece of code I do not > > understand. I see from specs that this queue (that is filled by the > > firmware to report status to host) _seems_ to be 16 positions long. I > > would say that this value should be taken as an upper limit in the > > number of frames sent on the dma and still not acked (positively or > > not, depending on tx success) by the firmware. Is this correct? I did > > some tests and I saw that the number of frames sent through > > op32_poke_tx before corresponding status being reported greatly > > exceeds 16. > > The driver just puts the stuff into the DMA ring. It can put as much stuff > into the ring as it wants, as it allocated the ring. > > The _firmware_ must make sure to accept new packets from dma _only_ if > its buffers are not filled. That includes the tx status report buffer. The tx-status-queue-full condition most likely is an external condition in the firmware. Don't ask me which one, however. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 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 report a tx status it will send the informations to the DMA. > >> The DMA won't have enough space to store it and so it will drop the > >> message. In your opinion is it possible that something like that > >> happened? > > > > No. TX status isn't passed through DMA in >=rev5 cores. > > It's passed through MMIO registers which access an internal hardware > > queue. > Michael, > > sorry, I have a question, there is a piece of code I do not > understand. I see from specs that this queue (that is filled by the > firmware to report status to host) _seems_ to be 16 positions long. I > would say that this value should be taken as an upper limit in the > number of frames sent on the dma and still not acked (positively or > not, depending on tx success) by the firmware. Is this correct? I did > some tests and I saw that the number of frames sent through > op32_poke_tx before corresponding status being reported greatly > exceeds 16. The driver just puts the stuff into the DMA ring. It can put as much stuff into the ring as it wants, as it allocated the ring. The _firmware_ must make sure to accept new packets from dma _only_ if its buffers are not filled. That includes the tx status report buffer. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 code has some bug. Let's say, for >> example, that all the DMA slots were filled; when the firmware will >> try to report a tx status it will send the informations to the DMA. >> The DMA won't have enough space to store it and so it will drop the >> message. In your opinion is it possible that something like that >> happened? > > No. TX status isn't passed through DMA in >=rev5 cores. > It's passed through MMIO registers which access an internal hardware > queue. Michael, sorry, I have a question, there is a piece of code I do not understand. I see from specs that this queue (that is filled by the firmware to report status to host) _seems_ to be 16 positions long. I would say that this value should be taken as an upper limit in the number of frames sent on the dma and still not acked (positively or not, depending on tx success) by the firmware. Is this correct? I did some tests and I saw that the number of frames sent through op32_poke_tx before corresponding status being reported greatly exceeds 16. What am I missing? Many thanks, Cheers, -FG > > >> What looks strange to me is that, if the error is somewhere in the >> tx_header definition, every transmission will result in an error from >> the b43_dma_handle_txstatus. If a field is not in the correct >> position, it is always wrong: it can't be sometimes right and >> sometimes wrong, don't you agree? >> I had similar problem beacause of the wrong header offsets >> definitions, but that made every transmission generate a BUG >> report... >> I don't understand how it is possible that almost always things went >> fine and sometimes report status was not correct... > > Well, you should probably patch the driver to print the cookie when > the WARN_ON happens > and reproduce. > >> Please Michael, if you can, can you please check shm.inc header >> definition? > > Not yet. Maybe later. > > > -- > Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 the first error. I have no idea how many > > errors occurred before I got it stopped, but the cookies for the first > > few offending frames were 0x2030, 0x2032, 0x2048, 0x204c, 0x204e, > > 0x2050, and 0x2052. > > > > When I got it stopped, I dumped /sys/kernel/debug/b43/phy0/txstat and > > obtained: > > > > [cut] > Larry, > > many thanks for your help in debugging. However I can't reproduce that > error. I tried all this afternoon with a 4306rev3 on a CardBus board > but all efforts to freeze the PC were useless. I checked again the > difference between r5.0 and r5.1 but it is only 10 lines... so easy to > debug that I'm pretty sure that error is not due to changes into > header offsets. > > > Is there any way for me to me to freeze the interface when the first > > error occurs without inducing a kernel panic? > I don't understand completely your question: if you need to stop the > firmware without having its memory corrupted we can add a semaphore > just after the WARN_ON into shm so that next loop after > state_machine_start we enter an infinite loop. However this would > happen after hundreds cycles. Tell me if we can helping adding debug > blocks into the firmware. You can stop the PSM immediately, if you need to, with the MAC_CONTROL. See b43-fwdump, it uses it to get a consistent dump. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 got it stopped, but the cookies for the first > few offending frames were 0x2030, 0x2032, 0x2048, 0x204c, 0x204e, > 0x2050, and 0x2052. > > When I got it stopped, I dumped /sys/kernel/debug/b43/phy0/txstat and > obtained: > > [cut] Larry, many thanks for your help in debugging. However I can't reproduce that error. I tried all this afternoon with a 4306rev3 on a CardBus board but all efforts to freeze the PC were useless. I checked again the difference between r5.0 and r5.1 but it is only 10 lines... so easy to debug that I'm pretty sure that error is not due to changes into header offsets. > Is there any way for me to me to freeze the interface when the first > error occurs without inducing a kernel panic? I don't understand completely your question: if you need to stop the firmware without having its memory corrupted we can add a semaphore just after the WARN_ON into shm so that next loop after state_machine_start we enter an infinite loop. However this would happen after hundreds cycles. Tell me if we can helping adding debug blocks into the firmware. What kind of PC are you testing your CardBus adapter? Is that a 32bit or 16bit? Cheers, -FG > > > Larry > --- 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 list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 what the cookies look like? >> >> >> Yes Michael, you're right... I tried with my 4318 and openfwwf-5.1 >> and >> cookie value goes from 00 to 7E and then restarts from 00. >> Here is a portion of what cookie header field looks like during a 1 >> ping/s transmission... >> >> ... >> |6420| >> |6620| >> |6820| >> |6A20| >> |6C20| >> |6E20| >> |7020| >> |7220| >> |7420| >> |7620| >> |7820| >> |7A20| >> |7C20| >> |7E20| >> |0020| >> |0220| >> |0420| >> |0620| >> |0820| >> |0C20| >> |0E20| >> |1020| >> ... >> >> Any idea on the reason why Larry has 2 cookie sequences mixed >> togheter? > > Why are your cookies endianness swapped? I forgot to say that these numbers are related to tx header, so I now need to check what report_tx_status send back... > > > -- > Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 tried with my 4318 and openfwwf-5.1 and > cookie value goes from 00 to 7E and then restarts from 00. > Here is a portion of what cookie header field looks like during a 1 > ping/s transmission... > > ... > |6420| > |6620| > |6820| > |6A20| > |6C20| > |6E20| > |7020| > |7220| > |7420| > |7620| > |7820| > |7A20| > |7C20| > |7E20| > |0020| > |0220| > |0420| > |0620| > |0820| > |0C20| > |0E20| > |1020| > ... > > Any idea on the reason why Larry has 2 cookie sequences mixed togheter? Why are your cookies endianness swapped? -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
>> > 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 from 00 to 7E and then restarts from 00. Here is a portion of what cookie header field looks like during a 1 ping/s transmission... ... |6420| |6620| |6820| |6A20| |6C20| |6E20| |7020| |7220| |7420| |7620| |7820| |7A20| |7C20| |7E20| |0020| |0220| |0420| |0620| |0820| |0C20| |0E20| |1020| ... Any idea on the reason why Larry has 2 cookie sequences mixed togheter? cheers Lorenzo ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 | acked > --- > 000 | 0x207E | 0x067E | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 001 | 0x2060 | 0x066E | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 002 | 0x2062 | 0x0670 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 003 | 0x2002 | 0x0680 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 004 | 0x2064 | 0x0670 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 005 | 0x2004 | 0x0681 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 006 | 0x2066 | 0x0672 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 007 | 0x2006 | 0x0682 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 008 | 0x2068 | 0x0672 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 009 | 0x2008 | 0x0683 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 010 | 0x206A | 0x0674 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 011 | 0x200A | 0x0684 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 012 | 0x206C | 0x0674 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 013 | 0x206E | 0x0676 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 014 | 0x200E | 0x0686 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 015 | 0x2070 | 0x0676 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 016 | 0x2072 | 0x0678 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 017 | 0x2012 | 0x0688 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 018 | 0x2074 | 0x0678 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 019 | 0x2076 | 0x067A | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 020 | 0x2016 | 0x068A | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 021 | 0x2078 | 0x067A | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 022 | 0x207A | 0x067C | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 023 | 0x201A | 0x068C | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 024 | 0x207C | 0x067C | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 025 | 0x201E | 0x068E | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 026 | 0x2000 | 0x067E | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 027 | 0x2020 | 0x068F | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 028 | 0x2002 | 0x0680 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 029 | 0x2022 | 0x0690 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 030 | 0x2004 | 0x0680 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 031 | 0x2006 | 0x0682 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 032 | 0x2026 | 0x0692 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 033 | 0x2008 | 0x0682 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 034 | 0x2028 | 0x0693 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 035 | 0x200A | 0x0684 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 036 | 0x202A | 0x0694 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 037 | 0x200C | 0x0684 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 038 | 0x202C | 0x0695 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 039 | 0x200E | 0x0686 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 040 | 0x202E | 0x0696 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 041 | 0x2010 | 0x0686 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 042 | 0x2030 | 0x0697 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 043 | 0x2012 | 0x0688 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 044 | 0x2034 | 0x0699 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 045 | 0x2016 | 0x068A | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 046 | 0x2036 | 0x069A | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 047 | 0x2018 | 0x068A | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 048 | 0x2038 | 0x069B | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 049 | 0x201A | 0x068C | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 050 | 0x201C | 0x068C | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 051 | 0x203C | 0x069D | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 052 | 0x201E | 0x068E | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 053 | 0x2020 | 0x068E | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 054 | 0x2040 | 0x069F | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 055 | 0x2022 | 0x0690 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 056 | 0x2042 | 0x06A0 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 057 | 0x2024 | 0x0690 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 058 | 0x2044 | 0x06A1 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 059 | 0x2026 | 0x0692 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 060 | 0x2046 | 0x06A2 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 061 | 0x2028 | 0x0692 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 062 | 0x2048 | 0x06A3 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 063 | 0x202A | 0x0694 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 064 | 0x204A | 0x06A4 | 0x00 | 0x5 | 0x0 | 0 | 0 | 0 | 0 | 1 > 065 | 0x202C | 0x0694 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 066 | 0x204C | 0x06A5 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 067 | 0x202E | 0x0696 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 068 | 0x204E | 0x06A6 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 069 | 0x2030 | 0x0696 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 070 | 0x2050 | 0x06A7 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 071 | 0x2032 | 0x0698 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 072 | 0x2052 | 0x06A8 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 073 | 0x2034 | 0x0698 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 > 074 | 0x2054 | 0x06A9 | 0
Re: opensource firmware now accept version 410 frames
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 code has some bug. Let's say, for >> example, that all the DMA slots were filled; when the firmware will >> try to report a tx status it will send the informations to the DMA. >> The DMA won't have enough space to store it and so it will drop the >> message. In your opinion is it possible that something like that >> happened? > > No. TX status isn't passed through DMA in >=rev5 cores. > It's passed through MMIO registers which access an internal hardware > queue. Ok, perfect, thanks. > > >> Please Michael, if you can, can you please check shm.inc header >> definition? > > Not yet. Maybe later. > Ok, tahnks. Cheers Lorenzo ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 frames were 0x2030, 0x2032, 0x2048, 0x204c, 0x204e, 0x2050, and 0x2052. When I got it stopped, I dumped /sys/kernel/debug/b43/phy0/txstat and obtained: b43 TX status reports: index | cookie | seq | phy_stat | frame_count | rts_count | supp_reason | pm_indicated | intermediate | for_ampdu | acked --- 000 | 0x207E | 0x067E | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 001 | 0x2060 | 0x066E | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 002 | 0x2062 | 0x0670 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 003 | 0x2002 | 0x0680 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 004 | 0x2064 | 0x0670 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 005 | 0x2004 | 0x0681 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 006 | 0x2066 | 0x0672 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 007 | 0x2006 | 0x0682 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 008 | 0x2068 | 0x0672 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 009 | 0x2008 | 0x0683 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 010 | 0x206A | 0x0674 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 011 | 0x200A | 0x0684 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 012 | 0x206C | 0x0674 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 013 | 0x206E | 0x0676 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 014 | 0x200E | 0x0686 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 015 | 0x2070 | 0x0676 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 016 | 0x2072 | 0x0678 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 017 | 0x2012 | 0x0688 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 018 | 0x2074 | 0x0678 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 019 | 0x2076 | 0x067A | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 020 | 0x2016 | 0x068A | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 021 | 0x2078 | 0x067A | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 022 | 0x207A | 0x067C | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 023 | 0x201A | 0x068C | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 024 | 0x207C | 0x067C | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 025 | 0x201E | 0x068E | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 026 | 0x2000 | 0x067E | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 027 | 0x2020 | 0x068F | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 028 | 0x2002 | 0x0680 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 029 | 0x2022 | 0x0690 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 030 | 0x2004 | 0x0680 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 031 | 0x2006 | 0x0682 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 032 | 0x2026 | 0x0692 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 033 | 0x2008 | 0x0682 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 034 | 0x2028 | 0x0693 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 035 | 0x200A | 0x0684 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 036 | 0x202A | 0x0694 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 037 | 0x200C | 0x0684 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 038 | 0x202C | 0x0695 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 039 | 0x200E | 0x0686 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 040 | 0x202E | 0x0696 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 041 | 0x2010 | 0x0686 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 042 | 0x2030 | 0x0697 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 043 | 0x2012 | 0x0688 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 044 | 0x2034 | 0x0699 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 045 | 0x2016 | 0x068A | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 046 | 0x2036 | 0x069A | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 047 | 0x2018 | 0x068A | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 048 | 0x2038 | 0x069B | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 049 | 0x201A | 0x068C | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 050 | 0x201C | 0x068C | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 051 | 0x203C | 0x069D | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 052 | 0x201E | 0x068E | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 053 | 0x2020 | 0x068E | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 054 | 0x2040 | 0x069F | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 055 | 0x2022 | 0x0690 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 056 | 0x2042 | 0x06A0 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 057 | 0x2024 | 0x0690 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 058 | 0x2044 | 0x06A1 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 059 | 0x2026 | 0x0692 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 060 | 0x2046 | 0x06A2 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 061 | 0x2028 | 0x0692 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 062 | 0x2048 | 0x06A3 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 063 | 0x202A | 0x0694 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 064 | 0x204A | 0x06A4 | 0x00 | 0x5 | 0x0 | 0 | 0 | 0 | 0 | 1 065 | 0x202C | 0x0694 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 066 | 0x204C | 0x06A5 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 067 | 0x202E | 0x0696 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 068 | 0x204E | 0x06A6 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 069 | 0x2030 | 0x0696 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 070 | 0x2050 | 0x06A7 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 071 | 0x2032 | 0x0698 | 0x00 | 0x1 | 0x0 | 0 | 0 | 0 | 0 | 1 072
Re: opensource firmware now accept version 410 frames
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 all the DMA slots were filled; when the firmware will > try to report a tx status it will send the informations to the DMA. > The DMA won't have enough space to store it and so it will drop the > message. In your opinion is it possible that something like that > happened? No. TX status isn't passed through DMA in >=rev5 cores. It's passed through MMIO registers which access an internal hardware queue. > What looks strange to me is that, if the error is somewhere in the > tx_header definition, every transmission will result in an error from > the b43_dma_handle_txstatus. If a field is not in the correct > position, it is always wrong: it can't be sometimes right and > sometimes wrong, don't you agree? > I had similar problem beacause of the wrong header offsets > definitions, but that made every transmission generate a BUG report... > I don't understand how it is possible that almost always things went > fine and sometimes report status was not correct... Well, you should probably patch the driver to print the cookie when the WARN_ON happens and reproduce. > Please Michael, if you can, can you please check shm.inc header definition? Not yet. Maybe later. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
> 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 report a tx status it will send the informations to the DMA. The DMA won't have enough space to store it and so it will drop the message. In your opinion is it possible that something like that happened? What looks strange to me is that, if the error is somewhere in the tx_header definition, every transmission will result in an error from the b43_dma_handle_txstatus. If a field is not in the correct position, it is always wrong: it can't be sometimes right and sometimes wrong, don't you agree? I had similar problem beacause of the wrong header offsets definitions, but that made every transmission generate a BUG report... I don't understand how it is possible that almost always things went fine and sometimes report status was not correct... Please Michael, if you can, can you please check shm.inc header definition? Thanks Lorenzo. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 and especially the slot handling hasn't changed in years. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 during the test? Sometimes CTS frames produce strange behavior with the device. Thank you again Cheers Lorenzo ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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, > Failed frames 0/0 = 0.0%, Average tries 0.00 > [219861.216070] b43-phy222 debug: DMA-32 tx_ring_AC_BE: Used slots > 128/128, Failed frames 1600/3398448 = 0.0%, Average tries 1.19 I downloaded the 2.6.28.tar.gz file ffrom kernel.org - about 64 MiB. The logged data are ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243) ssb: SPROM revision 2 detected. b43-phy1: Broadcom 4318 WLAN found (core revision 9) b43-phy1 debug: Found PHY: Analog 3, Type 2, Revision 7 b43-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8 wmaster0 (b43): not using net_device_ops yet phy1: Selected rate control algorithm 'minstrel' ssb: Sonics Silicon Backplane found on PCI device :06:00.0 udev: renamed network interface wlan0 to eth1 input: b43-phy1 as /class/input/input5 b43 ssb1:0: firmware: requesting b43-open/ucode5.fw b43 ssb1:0: firmware: requesting b43-open/pcm5.fw b43 ssb1:0: firmware: requesting b43-open/b0g0initvals5.fw b43 ssb1:0: firmware: requesting b43-open/b0g0bsinitvals5.fw b43-phy1: Loading OpenSource firmware version 410.31754 (Hardware crypto not supported) 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 b43-phy1: Radio turned on by software eth1: authenticate with AP 00:1a:70:46:ba:b1 eth1: authenticated eth1: associate with AP 00:1a:70:46:ba:b1 eth1: RX AssocResp from 00:1a:70:46:ba:b1 (capab=0x431 status=0 aid=2) eth1: associated eth1: deauthenticating by local choice (reason=3) b43-phy1 debug: Removing Interface type 2 b43-phy1 debug: Wireless interface stopped b43-phy1 debug: DMA-32 rx_ring: Used slots 4/64, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-32 tx_ring_AC_BK: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-32 tx_ring_AC_BE: Used slots 24/128, Failed frames 0/24835 = 0.0%, Average tries 1.02 b43-phy1 debug: DMA-32 tx_ring_AC_VI: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-32 tx_ring_AC_VO: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-phy1 debug: DMA-32 tx_ring_mcast: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 b43-pci-bridge :06:00.0: PCI INT A disabled Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 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 the website? >> - have you replaced _all_ the files, including shm.inc etc? Here we >> redefined the txheader layout and moved the cookie address >> - are you modprobing by setting qos=0? >> - is your card a PCCARD or PCI? > > The only patch I had applied to 2.6.29-rc2-wl was to have b43 look for > opensource firmware before the proprietary version. The complete set > of files from the openfwwf-5.1.tar.gz were applied and the firmware > built from them. I am modprobing with qos=0 and nohwcrypto=1. I have a > PCCARD format. It is labeled as a Linksys WPC54G, ver. 3. Larry, 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, Failed frames 0/0 = 0.0%, Average tries 0.00 [219861.216070] b43-phy222 debug: DMA-32 tx_ring_AC_BE: Used slots 128/128, Failed frames 1600/3398448 = 0.0%, Average tries 1.19 Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 the website? >> - have you replaced _all_ the files, including shm.inc etc? Here we >> redefined the txheader layout and moved the cookie address >> - are you modprobing by setting qos=0? >> - is your card a PCCARD or PCI? > > The only patch I had applied to 2.6.29-rc2-wl was to have b43 look for > opensource firmware before the proprietary version. The complete set I still did not have time to integrate this patch, I will try it tomorrow. > of files from the openfwwf-5.1.tar.gz were applied and the firmware > built from them. I am modprobing with qos=0 and nohwcrypto=1. I have a Perfect. > PCCARD format. It is labeled as a Linksys WPC54G, ver. 3. Ah... well, although Lorenzo did lot of this work using his 4318 PCCARD branded Belkin, I observed very bizarre behavior when using PCCARD in the past, independently of the firmware type (also with the original Broadcom one), to such point that I gave up and switched to PCI and PCI-express only testbeds. However I will give a try tomorrow, I'm curious now to see what happens with new kernel + r5.1 + PCCARD. >> [cut] >> when you want, in this case just after the SIFS and only for frames >> sent >> to one not existing MAC addresses, so that no ack is sent by no one). >> Actual packets transmission verified by sniffing the channel by using >> another Broadcom card > > Your tests are a lot more rigorous than mine. > > I'll repeat my tests. > > Larry Many thanks, Cheers -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 that your kernel can behave differently than ours? > - are you sure you are using the correct initvals files? Those we put > today on the website? > - have you replaced _all_ the files, including shm.inc etc? Here we > redefined the txheader layout and moved the cookie address > - are you modprobing by setting qos=0? > - is your card a PCCARD or PCI? The only patch I had applied to 2.6.29-rc2-wl was to have b43 look for opensource firmware before the proprietary version. The complete set of files from the openfwwf-5.1.tar.gz were applied and the firmware built from them. I am modprobing with qos=0 and nohwcrypto=1. I have a PCCARD format. It is labeled as a Linksys WPC54G, ver. 3. > The strange thing is that the way b43 is interfaced to the firmware, > when hw encryption is not activated, does not change switching from 351 > to 410 version apart for the txheader layout: however we modified that > layout according to definitions in xmit.h. Is this correct? If this hold > I really can not understand why r5.1 had problems and r5.0 not in your > setup. I would have supposed that given r5.1 has problems, the same can > arise also on r5.0. > > Thanks, > -FG > > Tests description: we did the following couple of tests > > - downloaded 1GB through TCP while sending 1.6GB of UDP like traffic > through a raw socket, 10 ping/s > > - sent 10GBYTE by injecting packets composed in userspace through a > ioctl we attached to mac80211 stack: packets are sent one after another > without ACKs, separated by just a SIFS and encoded at 54Mb/s (this is a > very small firmware hack that reprograms next transmission opportunity > when you want, in this case just after the SIFS and only for frames sent > to one not existing MAC addresses, so that no ack is sent by no one). > Actual packets transmission verified by sniffing the channel by using > another Broadcom card Your tests are a lot more rigorous than mine. I'll repeat my tests. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 drivers/.../b43/dma.c:1386, which is in routine > b43_dma_handle_txstatus. The specific condition is !meta->skb. > > No other messages made it to the log. I will investigate the kind of > debugging aids that Michael mentioned and send more info when > available. > > Larry Larry, 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 that your kernel can behave differently than ours? - are you sure you are using the correct initvals files? Those we put today on the website? - have you replaced _all_ the files, including shm.inc etc? Here we redefined the txheader layout and moved the cookie address - are you modprobing by setting qos=0? - is your card a PCCARD or PCI? The strange thing is that the way b43 is interfaced to the firmware, when hw encryption is not activated, does not change switching from 351 to 410 version apart for the txheader layout: however we modified that layout according to definitions in xmit.h. Is this correct? If this hold I really can not understand why r5.1 had problems and r5.0 not in your setup. I would have supposed that given r5.1 has problems, the same can arise also on r5.0. Thanks, -FG Tests description: we did the following couple of tests - downloaded 1GB through TCP while sending 1.6GB of UDP like traffic through a raw socket, 10 ping/s - sent 10GBYTE by injecting packets composed in userspace through a ioctl we attached to mac80211 stack: packets are sent one after another without ACKs, separated by just a SIFS and encoded at 54Mb/s (this is a very small firmware hack that reprograms next transmission opportunity when you want, in this case just after the SIFS and only for frames sent to one not existing MAC addresses, so that no ack is sent by no one). Actual packets transmission verified by sniffing the channel by using another Broadcom card ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 BUG at drivers/.../b43/dma.c:1386, which is in routine > b43_dma_handle_txstatus. The specific condition is !meta->skb. > > No other messages made it to the log. I will investigate the kind of > debugging aids that Michael mentioned and send more info when available. Most likely it got a wrong cookie. So either the cookie passing in the txheader is broken in fw or the txstatus. I'd probably say txheader, because that changed between revs and the txstatus didn't. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 use encryption while doing your tests? Yes, my network is WPA2 personal encrypted. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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_txstatus. The specific condition is !meta->skb. 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 use encryption while doing your tests? cheers Lorenzo Nava ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 loading? Once the dust settles, the plan is to have the os firmware write its capabilities into some place in shared memory. Then b43 will interpret the data and set the capabilities automagically. Not yet implemented on either end. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 tests, b43 with 5.0 firmware had transmitted and received over 800 MiB of data with no messages in the logs. I shut down testing at that point because they were hogging too much of my wireless bandwidth. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 drivers/.../b43/dma.c:1386, which is in routine > b43_dma_handle_txstatus. The specific condition is !meta->skb. > > No other messages made it to the log. I will investigate the kind of > debugging aids that Michael mentioned and send more info when > available. > > Larry Larry, 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 :-) Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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_txstatus. The specific condition is !meta->skb. No other messages made it to the log. I will investigate the kind of debugging aids that Michael mentioned and send more info when available. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 for your efforts, but so far I haven't been successful in > getting my two 32 bit cardbus BCM4306 (rev. 5) based cards to work. [...] 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 loading? Thank you a lot Stefan Lippers-Hollmann [1] http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commitdiff;h=0faa1094b4f6bae7705d845fee87a1b4a3501178 signature.asc Description: This is a digitally signed message part. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: opensource firmware now accept version 410 frames
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 cardbus BCM4306 (rev. 5) based cards to work.
b43-asm[1] and openfwwf 5.1[3] seem to build fine, but tests with kernel
2.6.28.2, patched with "b43: Automatically probe for opensource
firmware"[5] and "b43: Dynamically control log verbosity"[6] from Michael
Buesch, seem to result in lots of firmware restarts
b43-phy0 ERROR: Firmware watchdog: The firmware died
b43-phy0 ERROR: MAC suspend failed
while scanning for wireless networks works half the time, associating with
a WPA2PSK (CCMP) access point (Linksys WRT-54GL 1.1/ BCM4320, OpenWRT
8.09_RC2, brcm-2.4[7] (proprietary wl 4.150.10.5 on kernel 2.4.35.4 - and
Asus WL-500gP v1/ BCM4318, OpenWRT 8.09_RC2, brcm47xx[8] (opensource b43
(compat-wireless[9]) with proprietary firmware 410.2160 on kernel
2.6.25.17) hasn't succeeded yet.
This behaviour is identical with openfwwf 5.0 and 5.1 for me.
While I'll try a current wireless-testing snapshot with more debugging
options set tonight, I don't see any relevant changes (except [5], [6],
which are applied to my 2.6.28.2 kernel) staging, do I miss anything
obvious? Are there eventually ways to debug this further?
Next to the preliminary Debian package sources at [1], [3], I also
unpacked the resulting binary packages below [10] (b43-asm for i386).
By the way, the install target of the current openfwwf 5.1 tarball installs
ucode5.fw as /lib/firmware/b43-open/open_ucode5.fw, while current b43 [13]
looks for /lib/firmware/b43-open/ucode5.fw; furthermore b0g0initvals5.fw
and b0g0bsinitvals5.fw aren't installed to ${PREFIX}/ at all. Also b43
seems to probe for pcm5.fw, which doesn't get built by openfwwf 5.0/ 5.1?
Thanks a lot
Stefan Lippers-Hollmann
=== dmesg excerpt, full dmesg at [11] ===
b43-pci-bridge :03:00.0: enabling device ( -> 0002)
pcmcia_socket pcmcia_socket0: cs: IO port probe 0x100-0x3af: excluding
0x230-0x237
pcmcia_socket pcmcia_socket0: cs: IO port probe 0x3e0-0x4ff: clean.
b43-pci-bridge :03:00.0: PCI INT A -> Link[LNKC] -> GSI 10 (level, low) ->
IRQ 10
pcmcia_socket pcmcia_socket0: cs: IO port probe 0x820-0x8ff: clean.
b43-pci-bridge :03:00.0: setting latency timer to 64
ssb: Sonics Silicon Backplane found on PCI device :03:00.0
pcmcia_socket pcmcia_socket0: cs: IO port probe 0xc00-0xcf7: clean.
pcmcia_socket pcmcia_socket0: cs: IO port probe 0xa00-0xaff: clean.
b43-phy0: Broadcom 4306 WLAN found (core revision 5)
phy0: Selected rate control algorithm 'minstrel'
Broadcom 43xx driver loaded [ Features: PMLR, Firmware-ID: FW13 ]
input: b43-phy0 as /devices/virtual/input/input8
b43 ssb0:0: firmware: requesting b43/ucode5.fw
b43 ssb0:0: firmware: requesting b43-open/ucode5.fw
b43 ssb0:0: firmware: requesting b43-open/pcm5.fw
b43 ssb0:0: firmware: requesting b43-open/b0g0initvals5.fw
b43 ssb0:0: firmware: requesting b43-open/b0g0bsinitvals5.fw
b43-phy0: Loading OpenSource firmware version 410.31754 (Hardware crypto not
supported)
Registered led device: b43-phy0::tx
Registered led device: b43-phy0::rx
Registered led device: b43-phy0::radio
b43-phy0: Radio turned on by software
b43-phy0 ERROR: Firmware watchdog: The firmware died!
b43-phy0: Controller RESET (Firmware watchdog) ...
b43-phy0 ERROR: MAC suspend failed
b43 ssb0:0: firmware: requesting b43/ucode5.fw
b43 ssb0:0: firmware: requesting b43-open/ucode5.fw
b43 ssb0:0: firmware: requesting b43-open/pcm5.fw
b43 ssb0:0: firmware: requesting b43-open/b0g0initvals5.fw
b43 ssb0:0: firmware: requesting b43-open/b0g0bsinitvals5.fw
b43-phy0: Loading OpenSource firmware version 410.31754 (Hardware crypto not
supported)
Registered led device: b43-phy0::tx
Registered led device: b43-phy0::rx
Registered led device: b43-phy0::radio
b43-phy0: Controller restarted
wlan1: direct probe to AP 00:18:39:6b:da:23 try 1
wlan1: direct probe to AP 00:18:39:6b:da:23 try 2
wlan1: direct probe to AP 00:18:39:6b:da:23 try 3
wlan1: direct probe to AP 00:18:39:6b:da:23 timed out
wlan1: direct probe to AP 00:18:39:6b:da:23 try 1
[...]
=== lspci -nnvvv ===
03:00.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g
Wireless LAN Controller [14e4:4320] (rev 03)
Subsystem: Belkin Belkin F5D7010 54g Wireless Network card [1799:7010]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-
}
=== dmesg excerpt, working Broadcom firmware ===
b43-pci-bridge :03:00.0: enabling device ( -> 0002)
b43-pci-bridge :03:00.0: PCI INT A -> Link[LNKC] -> GSI 10 (level, low) ->
IRQ
opensource firmware now accept version 410 frames
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
Re: [b43] opensource firmware
2009/1/14 Lorenzo Nava : > we completed the 1st version of initvals. They are available at > http://www.ing.unibs.it/openfwwf > . Currently only binary version is available: don't worry, we will > publish source code as soon as possible!! This first version is a > "test version": please try it and let us know if everythink is ok... > > 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 > firmware with encryption and let us know if it works correctly, thanks! > > Initvals and new firmware version can be found at > http://www.ing.unibs.it/openfwwf I belive you still need testing? I used openfwwf-5.0.tar.gz and initvals.tar.gz for my bcm4318 card in Acer Aspire 5024 (qos=0). Scanning works fine, connecting to WPA Personal network also. I can't check speed performance as I don't have antenna connected to my card (notebook lid just gone... I belive "Acer" explains that situation to you?). As for stability it's great. I downloaded 100MB, left notebook for 24h and then downloaded another 50MB. So to sum up: I don't feel any difference between opensource and broardcom's firmware. -- Rafał Miłecki ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
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 monitor mode without associating first. > > > > I had already tried it in managed mode. The logged data are > > > > Jan 23 13:37:09 larrylap kernel: b43-phy0: Loading OpenSource firmware > > version 351.11970 > > Jan 23 13:37:09 larrylap kernel: b43-phy0 warning: You are using an > > old firmware image. Support for old firmware will be removed soon > > (official deadline was July 2008). > > Jan 23 13:37:09 larrylap kernel: b43-phy0 warning: You must go to > > http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware and > > download the correct firmware for this driver version. Please > > carefully read all instructions on this website. > > Jan 23 13:37:09 larrylap kernel: b43-phy0 debug: Chip initialized > > Jan 23 13:37:09 larrylap kernel: b43-phy0 debug: 64-bit DMA initialized > > Jan 23 13:37:09 larrylap kernel: Registered led device: b43-phy0::tx > > Jan 23 13:37:09 larrylap kernel: Registered led device: b43-phy0::rx > > Jan 23 13:37:09 larrylap kernel: Registered led device: b43-phy0::radio > > Jan 23 13:37:09 larrylap kernel: b43-phy0 debug: Wireless interface > > started > > Jan 23 13:37:09 larrylap kernel: b43-phy0: Controller restarted > > Jan 23 13:37:25 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:29 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:30 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:30 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:30 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:31 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:31 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:31 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:32 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:32 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:40 larrylap kernel: b43-phy0 ERROR: Firmware watchdog: > > The firmware died! > > Jan 23 13:37:40 larrylap kernel: b43-phy0: Controller RESET (Firmware > > watchdog) ... > > Jan 23 13:37:41 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: Wireless interface > > stopped > > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 rx_ring: Used > > slots 0/64, Failed frames 0/0 = 0.0%, Average tries 0.00 > > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_BK: > > Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 > > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_BE: > > Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 > > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_VI: > > Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 > > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_VO: > > Used slots 22/128, Failed frames 0/0 = 0.0%, Average tries 0.00 > > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_mcast: > > Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 > > > > I haven't gotten to monitor mode yet, but if the firmware cannot > > suspend the MAC, I'm not optimistic. > > Well, there's a reason broadcom does different firmwares for different cores. > ;) > It turns out even rev9 runs with its own firmware now. I think that used to > run rev5 > firmware in the past. Btw, I guess you know you guys know about the b43-fwdump utility found in b43-tools/debug. It provides a kernel-oops-like firmware register (and SHM) dump and a (pseudo-)backtrace for the current program counter of the firmware. It requires the b43 debugfs interface to be available. Very nice to debug this kind of "what the hell is happening" errors, as you can see what code the firmware does currently execute. For the pseudo-backtrace you must provide the .fw file to the b43-fwdump tool. (see b43-fwdump --help) -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
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 monitor mode without associating first. > > I had already tried it in managed mode. The logged data are > > Jan 23 13:37:09 larrylap kernel: b43-phy0: Loading OpenSource firmware > version 351.11970 > Jan 23 13:37:09 larrylap kernel: b43-phy0 warning: You are using an > old firmware image. Support for old firmware will be removed soon > (official deadline was July 2008). > Jan 23 13:37:09 larrylap kernel: b43-phy0 warning: You must go to > http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware and > download the correct firmware for this driver version. Please > carefully read all instructions on this website. > Jan 23 13:37:09 larrylap kernel: b43-phy0 debug: Chip initialized > Jan 23 13:37:09 larrylap kernel: b43-phy0 debug: 64-bit DMA initialized > Jan 23 13:37:09 larrylap kernel: Registered led device: b43-phy0::tx > Jan 23 13:37:09 larrylap kernel: Registered led device: b43-phy0::rx > Jan 23 13:37:09 larrylap kernel: Registered led device: b43-phy0::radio > Jan 23 13:37:09 larrylap kernel: b43-phy0 debug: Wireless interface > started > Jan 23 13:37:09 larrylap kernel: b43-phy0: Controller restarted > Jan 23 13:37:25 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:29 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:30 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:30 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:30 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:31 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:31 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:31 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:32 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:32 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:40 larrylap kernel: b43-phy0 ERROR: Firmware watchdog: > The firmware died! > Jan 23 13:37:40 larrylap kernel: b43-phy0: Controller RESET (Firmware > watchdog) ... > Jan 23 13:37:41 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: Wireless interface > stopped > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 rx_ring: Used > slots 0/64, Failed frames 0/0 = 0.0%, Average tries 0.00 > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_BK: > Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_BE: > Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_VI: > Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_VO: > Used slots 22/128, Failed frames 0/0 = 0.0%, Average tries 0.00 > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_mcast: > Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 > > I haven't gotten to monitor mode yet, but if the firmware cannot > suspend the MAC, I'm not optimistic. Well, there's a reason broadcom does different firmwares for different cores. ;) It turns out even rev9 runs with its own firmware now. I think that used to run rev5 firmware in the past. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
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 monitor mode without associating first. I had already tried it in managed mode. The logged data are Jan 23 13:37:09 larrylap kernel: b43-phy0: Loading OpenSource firmware version 351.11970 Jan 23 13:37:09 larrylap kernel: b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed soon (official deadline was July 2008). Jan 23 13:37:09 larrylap kernel: b43-phy0 warning: You must go to http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware and download the correct firmware for this driver version. Please carefully read all instructions on this website. Jan 23 13:37:09 larrylap kernel: b43-phy0 debug: Chip initialized Jan 23 13:37:09 larrylap kernel: b43-phy0 debug: 64-bit DMA initialized Jan 23 13:37:09 larrylap kernel: Registered led device: b43-phy0::tx Jan 23 13:37:09 larrylap kernel: Registered led device: b43-phy0::rx Jan 23 13:37:09 larrylap kernel: Registered led device: b43-phy0::radio Jan 23 13:37:09 larrylap kernel: b43-phy0 debug: Wireless interface started Jan 23 13:37:09 larrylap kernel: b43-phy0: Controller restarted Jan 23 13:37:25 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:29 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:30 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:30 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:30 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:31 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:31 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:31 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:32 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:32 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:40 larrylap kernel: b43-phy0 ERROR: Firmware watchdog: The firmware died! Jan 23 13:37:40 larrylap kernel: b43-phy0: Controller RESET (Firmware watchdog) ... Jan 23 13:37:41 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: Wireless interface stopped Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 rx_ring: Used slots 0/64, Failed frames 0/0 = 0.0%, Average tries 0.00 Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_BK: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_BE: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_VI: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_VO: Used slots 22/128, Failed frames 0/0 = 0.0%, Average tries 0.00 Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_mcast: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 I haven't gotten to monitor mode yet, but if the firmware cannot suspend the MAC, I'm not optimistic. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
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 for >> the >> feedback. >> >> By the way: is that device inside an AP? If yes what? if not which >> brand >> has the board on? I can look around. > > Mine is on a mini-PCIe card in a laptop. The part has an HP Part > #441090-001, but I expect there are Dell equivalents that are cheaper. > I don't know about an AP. > > Larry Larry, 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 monitor mode without associating first. Thanks a lot. -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Automatically probe for opensource firmware
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, but no proprietary (Distros can > > only ship open fw) > >it might work. > > 3) If both open and proprietary are available, it will work, because it > > selects > >the proprietary. We currently don't prefer the open fw in this case, > > because it doesn't > >work on all devices. It would introduce a regression otherwise. > > > > The remaining FIXMEs in this patch are harmless, because they only matter > > on multiband > > devices, which are not implemented yet anyway. > > > > Signed-off-by: Michael Buesch > > > > --- > > > > John, please queue for the next feature round. > > Acked-by: Larry Finger > > I made one temporary change to search for open-source firmware before > the proprietary version because I boot kernels that are not changed to > handle the o-s version, but still want to test when I can. > > I understand and approve of your logic - it just doesn't fit my > current agenda. You can still use the fwpostfix module parameter, of course. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Automatically probe for opensource firmware
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, but no proprietary (Distros can only > ship open fw) >it might work. > 3) If both open and proprietary are available, it will work, because it > selects >the proprietary. We currently don't prefer the open fw in this case, > because it doesn't >work on all devices. It would introduce a regression otherwise. > > The remaining FIXMEs in this patch are harmless, because they only matter on > multiband > devices, which are not implemented yet anyway. > > Signed-off-by: Michael Buesch > > --- > > John, please queue for the next feature round. Acked-by: Larry Finger I made one temporary change to search for open-source firmware before the proprietary version because I boot kernels that are not changed to handle the o-s version, but still want to test when I can. I understand and approve of your logic - it just doesn't fit my current agenda. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Automatically probe for opensource firmware
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, but no proprietary (Distros can only
ship open fw)
it might work.
3) If both open and proprietary are available, it will work, because it selects
the proprietary. We currently don't prefer the open fw in this case, because
it doesn't
work on all devices. It would introduce a regression otherwise.
The remaining FIXMEs in this patch are harmless, because they only matter on
multiband
devices, which are not implemented yet anyway.
Signed-off-by: Michael Buesch
---
John, please queue for the next feature round.
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c 2009-01-23
19:19:20.0 +0100
+++ wireless-testing/drivers/net/wireless/b43/main.c2009-01-23
19:23:18.0 +0100
@@ -1931,25 +1931,25 @@ static irqreturn_t b43_interrupt_handler
mmiowb();
spin_unlock(&dev->wl->irq_lock);
return ret;
}
-static void do_release_fw(struct b43_firmware_file *fw)
+void b43_do_release_fw(struct b43_firmware_file *fw)
{
release_firmware(fw->data);
fw->data = NULL;
fw->filename = NULL;
}
static void b43_release_firmware(struct b43_wldev *dev)
{
- do_release_fw(&dev->fw.ucode);
- do_release_fw(&dev->fw.pcm);
- do_release_fw(&dev->fw.initvals);
- do_release_fw(&dev->fw.initvals_band);
+ b43_do_release_fw(&dev->fw.ucode);
+ b43_do_release_fw(&dev->fw.pcm);
+ b43_do_release_fw(&dev->fw.initvals);
+ b43_do_release_fw(&dev->fw.initvals_band);
}
static void b43_print_fw_helptext(struct b43_wl *wl, bool error)
{
const char *text;
@@ -1960,48 +1960,66 @@ static void b43_print_fw_helptext(struct
if (error)
b43err(wl, text);
else
b43warn(wl, text);
}
-static int do_request_fw(struct b43_wldev *dev,
-const char *name,
-struct b43_firmware_file *fw,
-bool silent)
+int b43_do_request_fw(struct b43_request_fw_context *ctx,
+ const char *name,
+ struct b43_firmware_file *fw)
{
- char path[sizeof(modparam_fwpostfix) + 32];
const struct firmware *blob;
struct b43_fw_header *hdr;
u32 size;
int err;
if (!name) {
/* Don't fetch anything. Free possibly cached firmware. */
- do_release_fw(fw);
+ /* FIXME: We should probably keep it anyway, to save some
headache
+* on suspend/resume with multiband devices. */
+ b43_do_release_fw(fw);
return 0;
}
if (fw->filename) {
- if (strcmp(fw->filename, name) == 0)
+ if ((fw->type == ctx->req_type) &&
+ (strcmp(fw->filename, name) == 0))
return 0; /* Already have this fw. */
/* Free the cached firmware first. */
- do_release_fw(fw);
+ /* FIXME: We should probably do this later after we successfully
+* got the new fw. This could reduce headache with multiband
devices.
+* We could also redesign this to cache the firmware for all
possible
+* bands all the time. */
+ b43_do_release_fw(fw);
+ }
+
+ switch (ctx->req_type) {
+ case B43_FWTYPE_PROPRIETARY:
+ snprintf(ctx->fwname, sizeof(ctx->fwname),
+"b43%s/%s.fw",
+modparam_fwpostfix, name);
+ break;
+ case B43_FWTYPE_OPENSOURCE:
+ snprintf(ctx->fwname, sizeof(ctx->fwname),
+"b43-open%s/%s.fw",
+modparam_fwpostfix, name);
+ break;
+ default:
+ B43_WARN_ON(1);
+ return -ENOSYS;
}
-
- snprintf(path, ARRAY_SIZE(path),
-"b43%s/%s.fw",
-modparam_fwpostfix, name);
- err = request_firmware(&blob, path, dev->dev->dev);
+ err = request_firmware(&blob, ctx->fwname, ctx->dev->dev->dev);
if (err == -ENOENT) {
- if (!silent) {
- b43err(dev->wl, "Firmware file \"%s\" not found\n",
- path);
- }
+ snprintf(ctx->errors[ctx->req_type],
+sizeof(ctx->errors[ctx->req_type]),
+
Re: integration of opensource firmware with b43 kernel driver
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 you try pushing it hard? i.e. doing a nice big bulk transfer > through it? Did it reach decent speeds without pegging the CPU with > softirqs? > > Can you give details on which kernel(s) and how you built/configured > the > router firmware(s)? Well, I just tested a 500Mbytes bulk transfer and I got a mean throughput of about 5.5Mbit/s, it was a simple infinite wget loop so we can have some slowness due to TCP. However no errors were logged to syslog and the AP is still there, it didn't complain about anything. I built kamikaze yesterday image (r14144), kernel 2.6.25.17, I used the AP as a station joined to another AP without encryption. By the way, we did thousands of tests with x86 and we came to the conclusion that there is no performance (throughput) difference if compared to the standard proprietary firmware. Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
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 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, 4318, 4320 >>> >>> As a point of clarification, I think this is restricted to the >>> 4311/1 >>> as the 4311/2 uses ucode13, not ucode5. If you need a tester for an >>> open-source version of the 13 firmware, I'm available. >> 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 for the feedback. > > Well, if you didn't notice it already, there are a zillion different > flavors > of the broadcom wireless chip out there. So if you buy a random > device, you're almost > guaranteed that you don't have that flavor already. ;) Ehm... I begin to notice now... we were so engaged in understanding the tx state machine that we lost this _huge_ detail(!). They (Broadcom) should have plenty of engineers to design so many different chipsets. Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
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 fall back to the standard firmware if the > -- opensource version is not found. I answered to this question with this patch: http://bu3sch.de/patches/wireless-testing/20081227-1821/patches/008-b43-probe-open-fw.patch I am currently testing an updated version of the patch and I'll push it upstream tomorrow. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
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 was the question? > Note that proprietary and open firmwares are in separate > directories, so > I don't see why we should rename them. > Renaming firmware is a huge pain. We did it several times in the > past and > I really want to avoid it. It creates a major confusion for users > for some months. Sorry sorry sorry and sorry again... it was a Larry question, not John's... pardon me -- 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 fall back to the standard firmware if the -- opensource version is not found. However, it's not a problem maintaining these names. >>>> - detection of the opensource firmware capabilities: are you really >>>> sure we cannot use a shm location that the bcm proprietary firmware >>>> uses for some other purpose? >>> >>> Yes, well. You're not intermixing an earlier discussion into this, >>> where >>> you didn't indicate opensource capabilities to the kernel. >>> If you indicate OS capabilities, you can use whatever offset you >>> want, of course. >> Excellent. We will modify the firmware accordingly and encode the >> options. > > Thanks. Would be nice if you could also do the corresponding driver > patch. Ok, it should be simple. >>>> - tx header layout: the opensource firmware is now using the old >>>> memory layout in the tx header (<351). Do you think switching to >>>> 410 >>>> format is mandatory now or we can concentrate on the other tasks? >>> >>> Yes, the old format is deprecated and will be removed soon. >> Ok, first task in the todo list! > > Well, doesn't need to the the first one. Just note that support for > this is > scheduled to be removed in summer 2008. So if any problems show up > (broadcom > releases yet another API, for example), I will immediately remove it. Well, it's the first because it's the easiest :-) >> Ok, thanks for the hint. I will check, > > There are a few things we're not yet sure about. > For example the operand for the GPR number got an additional bit. > But we're not sure if the real number of GPRs also was doubled in > the hardware. > There are a few FIXMEs in the code for this... > I think this simply has to be tested by trial and error. Thanks, I will surely check this. Cheers, -FG > > > -- > 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/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
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 for the > feedback. > > By the way: is that device inside an AP? If yes what? if not which brand > has the board on? I can look around. Mine is on a mini-PCIe card in a laptop. The part has an HP Part #441090-001, but I expect there are Dell equivalents that are cheaper. I don't know about an AP. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
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 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, 4318, 4320 > > > > As a point of clarification, I think this is restricted to the 4311/1 > > as the 4311/2 uses ucode13, not ucode5. If you need a tester for an > > open-source version of the 13 firmware, I'm available. > 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 for the feedback. Well, if you didn't notice it already, there are a zillion different flavors of the broadcom wireless chip out there. So if you buy a random device, you're almost guaranteed that you don't have that flavor already. ;) Another thing is: You simply can _not_ distinguish the devices by the 43xx number in practice. There are too many devices with the same 43xx number, but different internal designs. The safest solution for the firmware is to tell by the wireless core revision whether it works or not. (However, that still leaves a few traps for different PHY and radio revisions, as the firmware also accesses PHY and radio). -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
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 are in separate directories, so I don't see why we should rename them. Renaming firmware is a huge pain. We did it several times in the past and I really want to avoid it. It creates a major confusion for users for some months. > >> - detection of the opensource firmware capabilities: are you really > >> sure we cannot use a shm location that the bcm proprietary firmware > >> uses for some other purpose? > > > > Yes, well. You're not intermixing an earlier discussion into this, > > where > > you didn't indicate opensource capabilities to the kernel. > > If you indicate OS capabilities, you can use whatever offset you > > want, of course. > Excellent. We will modify the firmware accordingly and encode the > options. Thanks. Would be nice if you could also do the corresponding driver patch. > >> - what to do with rts procedure: we can implement this feature easily > >> but I'm not sure about the value it can add to people (the majority > >> of > >> users?) that use the bcm board in station mode. This is different for > >> those who run a bcm card in AP mode, but we can clearly discourage > >> them to run this firmware in AP mode if not sure about rts usage by > >> stations. However, we put this task in the todo list. > > > > RTS/CTS is not specific to AP mode. It's used on any station in the > > BSS. > > See IEEE 802.11 specs. > Yes, in fact we put this task in the todo list. Thanks. > >> - tx header layout: the opensource firmware is now using the old > >> memory layout in the tx header (<351). Do you think switching to 410 > >> format is mandatory now or we can concentrate on the other tasks? > > > > Yes, the old format is deprecated and will be removed soon. > Ok, first task in the todo list! Well, doesn't need to the the first one. Just note that support for this is scheduled to be removed in summer 2008. So if any problems show up (broadcom releases yet another API, for example), I will immediately remove it. > Ok, thanks for the hint. I will check, There are a few things we're not yet sure about. For example the operand for the GPR number got an additional bit. But we're not sure if the real number of GPRs also was doubled in the hardware. There are a few FIXMEs in the code for this... I think this simply has to be tested by trial and error. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
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 of you >> sent >> and it seems that the firmware now runs on these board: >> >> - 4306, 4311, 4318, 4320 > > As a point of clarification, I think this is restricted to the 4311/1 > as the 4311/2 uses ucode13, not ucode5. If you need a tester for an > open-source version of the 13 firmware, I'm available. 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 for the feedback. By the way: is that device inside an AP? If yes what? if not which brand has the board on? I can look around. Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
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 collected the feedbacks that some of you >> sent and it seems that the firmware now runs on these board: >> >> - 4306, 4311, 4318, 4320 > > I don't think it has enough testing, yet. Sure, it seems to be stable on _our_ boards but I can't tell if it shows the same behavior on other hardware revisions. > > >> I was considering the suggestions you all gave me a few days ago and >> other questions related to the possible integration of this firmware >> into the kernel, and I came to these conclusions/questions (please >> forgive me for this long message :-) ) > > I don't think we want to have the firmware in the kernel. > Instead distributions should simply ship the firmware in a package. > That's not our business. I agree with you, distributions could easily package the firmware and distribute it to users when it will be stable, I was just wondering about. >> - change the name of the initvals for the opensource firmware: this > > Why? > >> [cut] >> initvals have already been uploaded. What can we do? > > 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. >> - detection of the opensource firmware capabilities: are you really >> sure we cannot use a shm location that the bcm proprietary firmware >> uses for some other purpose? > > Yes, well. You're not intermixing an earlier discussion into this, > where > you didn't indicate opensource capabilities to the kernel. > If you indicate OS capabilities, you can use whatever offset you > want, of course. Excellent. We will modify the firmware accordingly and encode the options. >> - what to do with rts procedure: we can implement this feature easily >> but I'm not sure about the value it can add to people (the majority >> of >> users?) that use the bcm board in station mode. This is different for >> those who run a bcm card in AP mode, but we can clearly discourage >> them to run this firmware in AP mode if not sure about rts usage by >> stations. However, we put this task in the todo list. > > RTS/CTS is not specific to AP mode. It's used on any station in the > BSS. > See IEEE 802.11 specs. Yes, in fact we put this task in the todo list. >> - tx header layout: the opensource firmware is now using the old >> memory layout in the tx header (<351). Do you think switching to 410 >> format is mandatory now or we can concentrate on the other tasks? > > Yes, the old format is deprecated and will be removed soon. Ok, first task in the todo list! >> - I would like to start considering N-phy on the firmware side. I >> have >> a late 2008 MacBook Pro and I'm not sure if beginning this work on >> this platform is a waste of time or not as Apple could have asked >> Broadcom a customized chipset. Should I start or is it better if I >> buy >> a N-phy pci board for my x86 box? > > A little bit of b43-asm work is still needed for this core. > There are a few FIXMEs in the code. Not sure, maybe there's more to > do. > I didn't try that, yet. > Before you start, you'll have to verify whether the assembler works > correctly. > Same for the disassembler. Ok, thanks for the hint. I will check, Cheers, -FG > > > -- > 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/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
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. That way there will not > > > be any confusion. > > > > I already posted that, but in case you missed it: > > http://bu3sch.de/patches/wireless-testing/20081227-1821/patches/008-b43-probe-open-fw.patch > > Preferring the proprietary firmware over the open firmware (for now) > seems like the best approach at this time. Many people will be quite > happy with the open firmware that we can actually ship in distros, and > those that aren't can do the fwcutter stuff and get their own > proprietary firmware. If for some reason the open firmware isn't > working, use fwcutter and get the proprietary firmware, which you would > have had to do before anyway. And those people with chips that aren't > supported by the proprietary firmware yet still have to use the > fwcutter, which they would have had to do anyway. Win all around. Exactly. This is why I implemented it that way. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
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: http://bu3sch.de/patches/wireless-testing/20081227-1821/patches/008-b43-probe-open-fw.patch -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
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 it seems that the firmware now runs on these board: > > - 4306, 4311, 4318, 4320 I don't think it has enough testing, yet. > I was considering the suggestions you all gave me a few days ago and > other questions related to the possible integration of this firmware > into the kernel, and I came to these conclusions/questions (please > forgive me for this long message :-) ) I don't think we want to have the firmware in the kernel. Instead distributions should simply ship the firmware in a package. That's not our business. > - change the name of the initvals for the opensource firmware: this Why? > seems a little bit complicated as now the decision about the initval- > files' names and the detection of the firmware type are respectively > based on the phy type and on the firmware date. This means that > initval-files' names can be determine as soon as the hardware type has > been probed, while the firmware needs to be started before the kernel > can determine if it is opensource or not: at this time, however, the > initvals have already been uploaded. What can we do? Nothing. Why do we need to have different names? > - detection of the opensource firmware capabilities: are you really > sure we cannot use a shm location that the bcm proprietary firmware > uses for some other purpose? Yes, well. You're not intermixing an earlier discussion into this, where you didn't indicate opensource capabilities to the kernel. If you indicate OS capabilities, you can use whatever offset you want, of course. > - what to do with rts procedure: we can implement this feature easily > but I'm not sure about the value it can add to people (the majority of > users?) that use the bcm board in station mode. This is different for > those who run a bcm card in AP mode, but we can clearly discourage > them to run this firmware in AP mode if not sure about rts usage by > stations. However, we put this task in the todo list. RTS/CTS is not specific to AP mode. It's used on any station in the BSS. See IEEE 802.11 specs. > - tx header layout: the opensource firmware is now using the old > memory layout in the tx header (<351). Do you think switching to 410 > format is mandatory now or we can concentrate on the other tasks? Yes, the old format is deprecated and will be removed soon. > - I would like to start considering N-phy on the firmware side. I have > a late 2008 MacBook Pro and I'm not sure if beginning this work on > this platform is a waste of time or not as Apple could have asked > Broadcom a customized chipset. Should I start or is it better if I buy > a N-phy pci board for my x86 box? A little bit of b43-asm work is still needed for this core. There are a few FIXMEs in the code. Not sure, maybe there's more to do. I didn't try that, yet. Before you start, you'll have to verify whether the assembler works correctly. Same for the disassembler. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
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 it seems that the firmware now runs on these board: > > - 4306, 4311, 4318, 4320 As a point of clarification, I think this is restricted to the 4311/1 as the 4311/2 uses ucode13, not ucode5. If you need a tester for an open-source version of the 13 firmware, I'm available. > I was considering the suggestions you all gave me a few days ago and > other questions related to the possible integration of this firmware > into the kernel, and I came to these conclusions/questions (please > forgive me for this long message :-) ) > > - change the name of the initvals for the opensource firmware: this > seems a little bit complicated as now the decision about the > initval-files' names and the detection of the firmware type are > respectively based on the phy type and on the firmware date. This means > that initval-files' names can be determine as soon as the hardware type > has been probed, while the firmware needs to be started before the > kernel can determine if it is opensource or not: at this time, however, > the initvals have already been uploaded. What can we do? 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. > - detection of the opensource firmware capabilities: are you really sure > we cannot use a shm location that the bcm proprietary firmware uses for > some other purpose? Once, in fact, the kernel has determined that the > firmware is opensource it can also use a given location in a different > manner than it would do for a proprietary firmware. However this is not > a problem at all :-) as we can use one location in the "high" shm-memory > area, let's say > 0xb00, just choose one. I think it best to choose an unused location. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
