Re: [PATCH] b43: Fix QoS defaults
Lorenzo Nava wrote: >> I'm not a reverse engineer, so I have no chance to check the original >> code to agree (or not) with you. >> > Ok, the mail has Johannes in Cc. I hope that he can tell me if me and > Francesco are right or not. > Johannes please check it (I mean specs at > http://bcm-v4.sipsolutions.net/802.11/QoS) > , thank you. It took me a while to find it, but the definitive statement is in the structure that defines the EDCF Q info array. It contains 16 2-byte words. The first 8 match the variables in the page mentioned above, and the last 8 are padding. Lorenzo and Francesco are right. I have modified the specs to conform to this finding. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4322 Info
Tyler Aviss wrote: > According to the specs on the actual laptop, it's a "Draft N" router. > I had thought that the b/g part would be pretty much the same as other > adaptors (and work) with the "N" part being added functionality (that > I can't use regardless, since my router is only B/G). However I > haven't had much luck getting the sucker to work under linux just yet, > except for the works-but-disconnects-regularly driver supplied by > Broadcomm. > > I was hoping to at least have some luck with ndiswrapper but even that > one hasn't been giving me much love with this card. Luckily I've got > an old USB-G adaptor kicking around that I can use in the meantime. > > Let me know if there's any other information you need... For the moment, what you sent is sufficient. Thanks. Unfortunately, the programming of the b/g part is different for the N PHY devices than it is for the G PHY units. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4322 Info
According to the specs on the actual laptop, it's a "Draft N" router. I had thought that the b/g part would be pretty much the same as other adaptors (and work) with the "N" part being added functionality (that I can't use regardless, since my router is only B/G). However I haven't had much luck getting the sucker to work under linux just yet, except for the works-but-disconnects-regularly driver supplied by Broadcomm. I was hoping to at least have some luck with ndiswrapper but even that one hasn't been giving me much love with this card. Luckily I've got an old USB-G adaptor kicking around that I can use in the meantime. Let me know if there's any other information you need... Here's the dump from "lspci -vv" 08:00.0 Network controller: Broadcom Corporation BCM4322 802.11a/b/g/n Wireless LAN Controller (rev 01) Subsystem: Hewlett-Packard Company Unknown device 137f Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- wrote: > Tyler Aviss wrote: >> >> Hey All, >> >> >> First of all, a quick introduction of myself. In general, I'm more of >> a sysadmin than a kernel developer, though in the odd case I've >> tracked down a few driver or FOSS-project bugs here and there (webcams >> and gatekeeper proejcts, small bugs usually caused by simple >> mistakes). So while I've never really delved heavily into writing >> drivers, I can at least do a step-by-step testing in many cases. >> >> I'm joining the list because: >> >> a) I have a bunch of laptops with Broadcomm cards, which - thanks to >> you developers - now happily work without me needing to use >> NDISwrapper >> b) I have a newer laptop with a Broadcomm card which seems to be >> something of an enigma at the moment. >> >> Now onward to (b), and what is currently one of the driving causes >> behind my joining this list. I notice that on the "LinuxWireless" >> page, the origins/status of the BCM4322 chipset seems to be somewhat >> unknown. The current comment in the unsupported section is: >> >> * BCM 4322 - We are working on support for this device (FIXME: what >> the hell is a BCM4322? –mb) >> >> I'd be happy to lend and support I can in supplying info/dumps/etc and >> testing the driver on this chipset as needed. Broadcomm actually has >> their own Linux/closed-source driver that somewhat works for this >> chipset (wl), but at the moment it's buggy as heck and tends to >> regularly disconnect and reconnect. I'd love to see the B43 driver get >> this chipset working, both so that I can have a working card and so >> that users can use a "true" FOSS driver rather than a buggy >> closed-source one. > > When you issue an 'lspci -nnv' for one of these devices, what is the PCI ID > for the BCM4322? > > I suspect that this is an 802.11n device. If so, the reverse engineering for > this device is going slowly. We had one person working on decompiling a MIPS > Broadcom driver, but he has been busy with other things lately. I have been > busy with working on the LP PHY (an 802.11g variant) for a couple of reasons > - it is a lot more like the other G PHYs, and I personally have one of the > devices. Once the LP PHY is working, then I will start on the N PHY code. > > Larry > -- Tyler Aviss Systems Support LPIC/LPIC-2 (647) 302-0942 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
The A in 4311AG
Hello list. I'm looking at buying an HP laptop which HP claims has "4311AG" wifi. I like to use .11a whenever possible and was a little sad to see that b43 doesn't support it. I am curious about why. "Just" lack of resources, or something more technical? Maybe I'll be able to help, in any case. Really lovely work on getting an open firmware going, Michael. //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix QoS defaults
> > I'm not a reverse engineer, so I have no chance to check the original > code to agree (or not) with you. > Ok, the mail has Johannes in Cc. I hope that he can tell me if me and Francesco are right or not. Johannes please check it (I mean specs at http://bcm-v4.sipsolutions.net/802.11/QoS) , thank you. regards Lorenzo > -- > Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [update] Asus 138G v2
On Wed, Sep 10, 2008 at 7:27 PM, Alexei Sergeev <[EMAIL PROTECTED]> wrote: > I sent another mail day ago, and while I was waiting and get no > support on irc I tried different drivers and firmwares. > > So far I tried bcm43xx and ndiswrapper (both gives me no success) > and I revert to b43. But now wireless card can't either connect to > network, it can see network but stop at "Configure device" state. > (Before it was able to connect but was very slow) > > So here is debug output again (now can't connect to AP, but see it): > uname -a > Linux server 2.6.24-19-generic #1 SMP Fri Jul 11 21:01:46 UTC 2008 > x86_64 GNU/Linux > > lspci -vvn|grep 43 -A7: > 05:00.0 0280: 14e4:4318 (rev 02) >Subsystem: 1043:100f >Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- >Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 32 >Interrupt: pin A routed to IRQ 20 >Region 0: Memory at e810 (32-bit, non-prefetchable) > [size=8K] > > 05:01.0 0480: 1131:7133 (rev d1) > > dmesg > [0.00] Initializing cgroup subsys cpuset > [0.00] Initializing cgroup subsys cpu > [0.00] Linux version 2.6.24-19-generic ([EMAIL PROTECTED]) (gcc > version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP Fri Jul 11 21:01:46 UTC > 2008 (Ubuntu 2.6.24-19.36-generic) > [0.00] Command line: root=UUID=05c8eb05-27d3-48a0- > be4f-75b22f6ece9b ro quiet splash > [0.00] BIOS-provided physical RAM map: > [0.00] BIOS-e820: - 0009e800 > (usable) > [0.00] BIOS-e820: 0009f800 - 000a > (reserved) > [0.00] BIOS-e820: 000f - 0010 > (reserved) > [0.00] BIOS-e820: 0010 - 7fee > (usable) > [0.00] BIOS-e820: 7fee - 7fee3000 > (ACPI NVS) > [0.00] BIOS-e820: 7fee3000 - 7fef > (ACPI data) > [0.00] BIOS-e820: 7fef - 7ff0 > (reserved) > [0.00] BIOS-e820: e000 - e400 > (reserved) > [0.00] BIOS-e820: fec0 - 0001 > (reserved) > [0.00] Entering add_active_range(0, 0, 158) 0 entries of 3200 > used > [0.00] Entering add_active_range(0, 256, 524000) 1 entries of > 3200 used > [0.00] end_pfn_map = 1048576 > [0.00] DMI 2.4 present. > [0.00] ACPI: RSDP signature @ 0x810F6F00 > checksum 0 > [0.00] ACPI: RSDP 000F6F00, 0014 (r0 GBT ) > [0.00] ACPI: RSDT 7FEE3040, 0038 (r1 GBTGBTUACPI > 42302E31 GBTU 1010101) > [0.00] ACPI: FACP 7FEE30C0, 0074 (r1 GBTGBTUACPI > 42302E31 GBTU 1010101) > [0.00] ACPI: DSDT 7FEE3180, 4B82 (r1 GBTGBTUACPI 1000 > MSFT 10C) > [0.00] ACPI: FACS 7FEE, 0040 > [0.00] ACPI: HPET 7FEE7E80, 0038 (r1 GBTGBTUACPI > 42302E31 GBTU 98) > [0.00] ACPI: MCFG 7FEE7F00, 003C (r1 GBTGBTUACPI > 42302E31 GBTU 1010101) > [0.00] ACPI: APIC 7FEE7D80, 0084 (r1 GBTGBTUACPI > 42302E31 GBTU 1010101) > [0.00] ACPI: SSDT 7FEE8860, 03AB (r1 PmRefCpuPm 3000 > INTL 20040311) > [0.00] No NUMA configuration found > [0.00] Faking a node at > -7fee > [0.00] Entering add_active_range(0, 0, 158) 0 entries of 3200 > used > [0.00] Entering add_active_range(0, 256, 524000) 1 entries of > 3200 used > [0.00] Bootmem setup node 0 > -7fee > [0.00] Zone PFN ranges: > [0.00] DMA 0 -> 4096 > [0.00] DMA324096 -> 1048576 > [0.00] Normal1048576 -> 1048576 > [0.00] Movable zone start PFN for each node > [0.00] early_node_map[2] active PFN ranges > [0.00] 0:0 -> 158 > [0.00] 0: 256 -> 524000 > [0.00] On node 0 totalpages: 523902 > [0.00] DMA zone: 56 pages used for memmap > [0.00] DMA zone: 1221 pages reserved > [0.00] DMA zone: 2721 pages, LIFO batch:0 > [0.00] DMA32 zone: 7108 pages used for memmap > [0.00] DMA32 zone: 512796 pages, LIFO batch:31 > [0.00] Normal zone: 0 pages used for memmap > [0.00] Movable zone: 0 pages used for memmap > [0.00] ACPI: PM-Timer IO Port: 0x408 > [0.00] ACPI: Local APIC address 0xfee0 > [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) > [0.00] Processor #0 (Bootup-CPU) > [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x03] enabled) > [0.00] Processor #3 > [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) > [0.00] Processor #2 > [0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled) > [0.00] Processor #1 > [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1]) > [0.0
Re: [PATCH] b43: Fix QoS defaults
On Wednesday 10 September 2008 22:11:53 Lorenzo Nava wrote: > >> > > The code is correct wrt specs. It says there are 0x16 words. > > First fix specs, then fix code, please. > > > Yes you're right, but just above the table of the parameters reported > at http://bcm-v4.sipsolutions.net/802.11/QoS it says: > > The EDCF Q Info array in SHM contains four structs of 16 16-bit words > > So there is something that is not correct: as I said before I think > that the error is in the table, and I checked it within the firmware, > so I am quite sure of that. > > Do you agree with me that there is an error in the specs? I'm not a reverse engineer, so I have no chance to check the original code to agree (or not) with you. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43: out-of-standard behavior
On Wednesday 10 September 2008 21:42:57 Francesco Gringoli wrote:
> Hello everybody,
>
> we found a strange behavior problem with the b43 driver. We begin
> investigating this when doing some access tests with several boards:
> we discovered that the Broadcom boards usually acquire the channel
> usage with higher priority when the b43 driver is used as respect to
> other vendor boards.
>
> After investigating we saw that the intra-queue contention procedure
> is carried out by the firmware which stores information, such as AIFS
> and current backoffs for each queue, inside the shared memory. The
> AIFS for each queue is used to compute the initial backoff so that
> internal contention usually gives more priority to VO queue (smallest
> AIFS) and less to background (biggest AIFS). AIFS parameters are
> initialized by the driver which is told to use a 22 words long
> structures. The firmware instead use 16 words structures: this means
> that AIFS parameters initialized by the driver do not match the
> corresponding values read by the firmware. We saw that the firmware
> reads (2,0,0,0) instead of (2,2,3,7) which results in very short
> backoff procedures.
>
> Has anyone noticed similar behavior? For the sake of clarity, I'm
> referring to latest (30 minutes ago) version of wireless-git and
> broadcom-wl-4.150.10.5 driver version. I verified that all ucode5.s,
> ucode9.s, ucode11.s, ucode13.s and ucode14.s firmwares use 16 words
> structures, and the driver instead still uses 22 words long
> structures. Probably the attached patch sorts out the problem.
>
> I also noticed that the specs say that these structures are 16 words:
> could not someone read 16 as 0x16 that finally became 0x16 = 22?
The specs are ambiguous here.
The specs table for QoS clearly has 0x16 fields. So I implemented it
this way and read the "foobar has 16 words" text in hex.
"How many people can read hex, if only you and dead people can read hex?" ;)
> --- b43.h.old 2008-09-10 21:12:59.0 +0200
> +++ b43.h 2008-09-10 21:13:09.0 +0200
> @@ -569,7 +569,7 @@
> #define B43_QOS_VOICE B43_QOS_PARAMS(3)
>
> /* QOS parameter hardware data structure offsets. */
> -#define B43_NR_QOSPARAMS 22
> +#define B43_NR_QOSPARAMS 16
> enum {
> B43_QOSPARAM_TXOP = 0,
> B43_QOSPARAM_CWMIN,
PS: Can you please avoid starting yet another thread for the topic?
We already have one.
Please, guys, keep _threads_. It's important to _not_ start new threads
all the time, so email archive searching is made possible. This is _also_
the case for private mail from you.
You're not the only one in my inbox, but every time I have to search for
your old mail it's a headache.
So good subjects (this one is _not_ a good one) and not breaking threads
is very important.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix QoS defaults
>> > The code is correct wrt specs. It says there are 0x16 words. > First fix specs, then fix code, please. > Yes you're right, but just above the table of the parameters reported at http://bcm-v4.sipsolutions.net/802.11/QoS it says: The EDCF Q Info array in SHM contains four structs of 16 16-bit words So there is something that is not correct: as I said before I think that the error is in the table, and I checked it within the firmware, so I am quite sure of that. Do you agree with me that there is an error in the specs? regards Lorenzo > -- > Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
b43: out-of-standard behavior
Hello everybody,
we found a strange behavior problem with the b43 driver. We begin
investigating this when doing some access tests with several boards:
we discovered that the Broadcom boards usually acquire the channel
usage with higher priority when the b43 driver is used as respect to
other vendor boards.
After investigating we saw that the intra-queue contention procedure
is carried out by the firmware which stores information, such as AIFS
and current backoffs for each queue, inside the shared memory. The
AIFS for each queue is used to compute the initial backoff so that
internal contention usually gives more priority to VO queue (smallest
AIFS) and less to background (biggest AIFS). AIFS parameters are
initialized by the driver which is told to use a 22 words long
structures. The firmware instead use 16 words structures: this means
that AIFS parameters initialized by the driver do not match the
corresponding values read by the firmware. We saw that the firmware
reads (2,0,0,0) instead of (2,2,3,7) which results in very short
backoff procedures.
Has anyone noticed similar behavior? For the sake of clarity, I'm
referring to latest (30 minutes ago) version of wireless-git and
broadcom-wl-4.150.10.5 driver version. I verified that all ucode5.s,
ucode9.s, ucode11.s, ucode13.s and ucode14.s firmwares use 16 words
structures, and the driver instead still uses 22 words long
structures. Probably the attached patch sorts out the problem.
I also noticed that the specs say that these structures are 16 words:
could not someone read 16 as 0x16 that finally became 0x16 = 22?
Cheers,
FG
--- b43.h.old 2008-09-10 21:12:59.0 +0200
+++ b43.h 2008-09-10 21:13:09.0 +0200
@@ -569,7 +569,7 @@
#define B43_QOS_VOICE B43_QOS_PARAMS(3)
/* QOS parameter hardware data structure offsets. */
-#define B43_NR_QOSPARAMS 22
+#define B43_NR_QOSPARAMS 16
enum {
B43_QOSPARAM_TXOP = 0,
B43_QOSPARAM_CWMIN,
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix QoS defaults
Stay on list. I'm not going to start another private thread for this. In general, I avoid private threads most of the time and barely answer them. There are so many people on the list that can answer your questions. On Wednesday 10 September 2008 17:50:33 Francesco Gringoli wrote: > > The code is correct wrt specs. It says there are 0x16 words. > > First fix specs, then fix code, please. > I do not understand: those specs say that there are 16 words. The table has 0x16 entries. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4322 Info
Tyler Aviss wrote: > Hey All, > > > First of all, a quick introduction of myself. In general, I'm more of > a sysadmin than a kernel developer, though in the odd case I've > tracked down a few driver or FOSS-project bugs here and there (webcams > and gatekeeper proejcts, small bugs usually caused by simple > mistakes). So while I've never really delved heavily into writing > drivers, I can at least do a step-by-step testing in many cases. > > I'm joining the list because: > > a) I have a bunch of laptops with Broadcomm cards, which - thanks to > you developers - now happily work without me needing to use > NDISwrapper > b) I have a newer laptop with a Broadcomm card which seems to be > something of an enigma at the moment. > > Now onward to (b), and what is currently one of the driving causes > behind my joining this list. I notice that on the "LinuxWireless" > page, the origins/status of the BCM4322 chipset seems to be somewhat > unknown. The current comment in the unsupported section is: > > * BCM 4322 - We are working on support for this device (FIXME: what > the hell is a BCM4322? –mb) > > I'd be happy to lend and support I can in supplying info/dumps/etc and > testing the driver on this chipset as needed. Broadcomm actually has > their own Linux/closed-source driver that somewhat works for this > chipset (wl), but at the moment it's buggy as heck and tends to > regularly disconnect and reconnect. I'd love to see the B43 driver get > this chipset working, both so that I can have a working card and so > that users can use a "true" FOSS driver rather than a buggy > closed-source one. When you issue an 'lspci -nnv' for one of these devices, what is the PCI ID for the BCM4322? I suspect that this is an 802.11n device. If so, the reverse engineering for this device is going slowly. We had one person working on decompiling a MIPS Broadcom driver, but he has been busy with other things lately. I have been busy with working on the LP PHY (an 802.11g variant) for a couple of reasons - it is a lot more like the other G PHYs, and I personally have one of the devices. Once the LP PHY is working, then I will start on the N PHY code. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
BCM4322 Info
Hey All, First of all, a quick introduction of myself. In general, I'm more of a sysadmin than a kernel developer, though in the odd case I've tracked down a few driver or FOSS-project bugs here and there (webcams and gatekeeper proejcts, small bugs usually caused by simple mistakes). So while I've never really delved heavily into writing drivers, I can at least do a step-by-step testing in many cases. I'm joining the list because: a) I have a bunch of laptops with Broadcomm cards, which - thanks to you developers - now happily work without me needing to use NDISwrapper b) I have a newer laptop with a Broadcomm card which seems to be something of an enigma at the moment. Now onward to (b), and what is currently one of the driving causes behind my joining this list. I notice that on the "LinuxWireless" page, the origins/status of the BCM4322 chipset seems to be somewhat unknown. The current comment in the unsupported section is: * BCM 4322 - We are working on support for this device (FIXME: what the hell is a BCM4322? –mb) If you haven't sighted this card in the wild, I currently have one in my newer HP laptop: A tx5254ca (Canadian TX2500 series, one of the reversible-screen tablet jobs). These went up for sale in a bunch of places at Future Shop and Best Buy, etc, so we may be seeing more Linux users with this chipset in the future. I'd be happy to lend and support I can in supplying info/dumps/etc and testing the driver on this chipset as needed. Broadcomm actually has their own Linux/closed-source driver that somewhat works for this chipset (wl), but at the moment it's buggy as heck and tends to regularly disconnect and reconnect. I'd love to see the B43 driver get this chipset working, both so that I can have a working card and so that users can use a "true" FOSS driver rather than a buggy closed-source one. Regards, Tyler Aviss ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix QoS defaults
On Wednesday 10 September 2008 15:18:07 Francesco Gringoli wrote: > Hi Michael, > > we are collecting every kind of material about Broadcom board, too. > Could you please point out the document with such specifications? http://bcm-v4.sipsolutions.net/802.11/QoS > I confirm what Lorenzo wrote: there are 32 bytes for queue. If you > leave 22 then all the Qos mechanisms go wrong. Indeed, the bcm board > takes (quite) exclusive control of the channel as gap is always set to > zero. The code is correct wrt specs. It says there are 0x16 words. First fix specs, then fix code, please. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix QoS defaults
Hi Michael, we are collecting every kind of material about Broadcom board, too. Could you please point out the document with such specifications? I confirm what Lorenzo wrote: there are 32 bytes for queue. If you leave 22 then all the Qos mechanisms go wrong. Indeed, the bcm board takes (quite) exclusive control of the channel as gap is always set to zero. Cheers, -FG On Sep 10, 2008, at 2:58 PM, Michael Buesch wrote: > On Wednesday 10 September 2008 00:15:14 Lorenzo Nava wrote: >> Hi everybody, >> >> I worked with the QoS parameters trying to understand why, checking >> them within the firmware, they don't seems to have the correct values >> even if they were set correctly by the driver. >> I think that there could be an error in the b43.h file: >> >> /* SHM offsets to the QOS data structures for the 4 different >> queues. */ >> #define B43_QOS_PARAMS(queue) (B43_SHM_SH_EDCFQ + \ >> (B43_NR_QOSPARAMS * sizeof(u16) * >> (queue))) >> #define B43_QOS_BACKGROUND B43_QOS_PARAMS(0) >> #define B43_QOS_BESTEFFORT B43_QOS_PARAMS(1) >> #define B43_QOS_VIDEO B43_QOS_PARAMS(2) >> #define B43_QOS_VOICE B43_QOS_PARAMS(3) >> >> /* QOS parameter hardware data structure offsets. */ >> #define B43_NR_QOSPARAMS22 >> >> Each EDCF parameters set take up 32 byte (in the firmware the offset >> between 2 EDCFQ is 0x010 that is equivalent to 0x020 if the offset >> was >> expressed in byte). This means that the B43_NR_QOSPARAMS must be set >> to 16. >> With the value equal to 16 I can access correctly the aifs, cwcur, >> cwmax, etc within the firmware. >> >> What do you think about that? > > The specifications says there are 22 (decimal) entries. > > > > -- > Greetings Michael. > ___ > Bcm43xx-dev mailing list > Bcm43xx-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism
On Wed, Sep 10, 2008 at 12:40:44AM -0600, Otto Solares wrote: > On Mon, Sep 08, 2008 at 04:54:59PM -0400, John W. Linville wrote: > > On Mon, Sep 08, 2008 at 11:22:43AM -0500, Larry Finger wrote: > > > Greg KH wrote: > > >> > > >> Bug fixes, not new features, it's pretty simple :) > > > > > > Just bug fixes, or does it have to be a regression? > > > > As I understand it, the rule is more like "bug fixes that are committed > > in the linux-2.6 tree". Since Linus has become more strict about > > requiring "regressions only" after the merge window, that effectively > > enforces the "regressions only" rule on the -stable trees as well. > > In this case that rule is harming, is not idiotic to not accept bug > fixes early or later? I'm just the messenger...FWIW the argument is that even a "fix" can introduce a new "bug" somewhere else, often quite unexpectedly. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix QoS defaults
On Wednesday 10 September 2008 00:15:14 Lorenzo Nava wrote: > Hi everybody, > > I worked with the QoS parameters trying to understand why, checking > them within the firmware, they don't seems to have the correct values > even if they were set correctly by the driver. > I think that there could be an error in the b43.h file: > > /* SHM offsets to the QOS data structures for the 4 different queues. */ > #define B43_QOS_PARAMS(queue) (B43_SHM_SH_EDCFQ + \ > (B43_NR_QOSPARAMS * sizeof(u16) * > (queue))) > #define B43_QOS_BACKGROUND B43_QOS_PARAMS(0) > #define B43_QOS_BESTEFFORT B43_QOS_PARAMS(1) > #define B43_QOS_VIDEO B43_QOS_PARAMS(2) > #define B43_QOS_VOICE B43_QOS_PARAMS(3) > > /* QOS parameter hardware data structure offsets. */ > #define B43_NR_QOSPARAMS22 > > Each EDCF parameters set take up 32 byte (in the firmware the offset > between 2 EDCFQ is 0x010 that is equivalent to 0x020 if the offset was > expressed in byte). This means that the B43_NR_QOSPARAMS must be set > to 16. > With the value equal to 16 I can access correctly the aifs, cwcur, > cwmax, etc within the firmware. > > What do you think about that? The specifications says there are 22 (decimal) entries. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
