Re: b43/b43legacy driver
Daniel Kuehn wrote: There is an option in gmail to tell it to send the mails as plain-text too. That is what I use, Good point - important to post plain text. I think another point which is also really important is to EXTENSIVELY TRIM messages that you reply to. It is quite common that Gmail users include the full previous history of a thread in every reply they create and this is absolute madness! Please be more aware of how you post, and make sure to trim when sending replies. Some particular behavior of Gmail (maybe it hides old parts of the thread?) is not an excuse for you to waste everyone else's time! //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy-phy3: Radio hardware status changed to XXX
Larry Finger wrote: There could be a bug in the software that processes whatever WMI info that your system generates. WMI (Windows Management Interface) code handles the functions of the top row of your keyboard that are generated by a fn+FX key. The BIOS is rarely if ever involved in any of this. As was already explained, the rfkill signal is an electrical input to the wifi hardware, and the b43 driver can only ever read the state of this input. Who drives the signal depends on the unique system design. (Think mainboard.) In laptops there is always at least one embedded controller AKA EC which handles some or all of keyboard, GPIO signals, LEDs, Fn keys, lid switch, power switch, special function keys, fan control, battery charging and various other bits and pieces of the system. Bytecode within the ACPI tables in the BIOS may be executed by the kernel in order to discover e.g. Fn+key combination presses or lid switch, but the BIOS does not have anything to do with changing the electrical signal going out from the EC - that is done either by the EC firmware (in response to some keypress, which will also be reported via ACPI so the OS can update some status display) or as ordered by the operating system (in response to some keypress reported by the EC via ACPI). There is no standardization at all for these signals and this behavior. If you can find the schematics for your laptop that would help. //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: No probe response from AP address after 500ms, disconnecting.
Miklos Vajna wrote: reboot pending to try the latest wireless-testing, Please let me know if that helped (which git repo, which branch?). It did not help. I merged git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git master into my kernel, and have posted a message about it to the ath9k list. Miklos Vajna wrote: So it's like: it's avilable for about 5 secs, then it goes down for 2, and this loops forever. :/ My disconnects are nowhere nearly as frequent. I can provoke them with power management on but with it off my card is very usable. I suspect there may be a similar problem in the reception path of both ath9k and b43, leading to the same error in mac80211. Again, this is with 2.6.33-rc4. Now my hope is that wireless-testing has some changes which are not in 2.6.33-rc4 and that solves this issue, but I'll wait for your experience first. :) Not for me, but I'm also not exercising the b43 code at all, so maybe there is something for you.. Dunno. $ git log --oneline dec18..master drivers/net/wireless/b43|grep b43: 81f14df b43: LP-PHY: note and explain specs inconsistency 55afc80 Revert b43: Enforce DMA descriptor memory constraints b02914a b43: Allow PIO mode to be selected at module load 214ac9a b43: Remove reset after fatal DMA error df98a49 b43: fix two warnings c2ff581 b43: avoid PPC fault during resume 07681e2 b43: Rewrite DMA Tx status handling sanity checks 9bd568a b43: Enforce DMA descriptor memory constraints f54a520 b43: Rewrite TX bounce buffer handling c1b84ab b43: Remove deprecated 'qual' from returned RX status 2c0d610 b43: LP-PHY: Begin implementing calibration software RFKILL support 72f5f45 b43: use ieee80211_rx_ni() 88499ab b43: Optimize PIO scratchbuffer usage bdcf8ff b43: Comment unused functions lpphy_restore_dig_flt_state and lpphy_disable_rx_gain_override //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: No probe response from AP address after 500ms, disconnecting.
Interesting! Miklos Vajna wrote: Hi, I tried asking on #bcm-users, then found the wiki where it's suggested to report to this list, so I'm doing so. Sorry for the noise on IRC. A description of the problem at hand: My card works fine when I use it with WPA, however when I try to use it without any encryption Do you have wpa_supplicant running also when not using encryption? (actually the provider uses MAC-based filtering, but that's not important), then after the iwconfig eth0 essid essid, iwconfig shows the MAC of the AP, and after about 5 secs iwconfig says it's Not-Associated. If I run iwconfig eth0 essid again, then it's usable again for ~5 secs and so on. When the AP goes unassociated, I see this in dmesg: No probe response from AP 00:12:17:d3:87:f5 after 500ms, disconnecting. I also get this issue, but with ath9k. I have made some noise on the ath9k list about it, and currently have a reboot pending to try the latest wireless-testing, which has gotten some more fixes. When it happens: It happens only in case not using encryption. An other laptop with ipw2200 driver works fine, so I guess this will be a b43 or firmware problem. The same card works under Windows XP as well, so I guess it's not a hardware problem. I upgraded from ipw2200 to ath9k in my laptop and the old card never had trouble. Both ath9k and b43 use mac80211 but ipw2200 does not. With mac80211 you're apparently supposed to always have wpa_supplicant running - even if not using encryption. The supplicant is responsible for reconnecting if the interface is disconnected for any reason. I'm not satisfied with this as the final answer yet. I find it suspicious that my card disconnects in the first place. I am normally in a moderately silent RF environment, with not many APs. With power management enabled (iwconfig eth1 power on) I experience this issue within minutes. With PM disabled, it happens only every couple of days. This is on wireless-testing as of Dec 14. In a very tough RF environment such as a hacker conference the problem is much more pronounced and disconnects happen many times per day also with PM off. Any ideas? Does iwconfig power off make a difference for you? //Peter pgpWZFKIquKbK.pgp Description: PGP signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: No probe response from AP address after 500ms, disconnecting.
Miklos Vajna wrote:
I have made some noise on the ath9k list about it, and currently have
a reboot pending to try the latest wireless-testing, which has gotten
some more fixes.
Please let me know if that helped (which git repo, which branch?).
Will do.
Should I include a section for the linksys (which has no encryption)
AP as well? if yes, what should it look like?
Yes, otherwise I don't think wpa_supplicant will do anything.
network={
ssid=linksys
key_mgmt=NONE
}
It could help to run it in foreground - you should see disconnect and
reauth then.
Does iwconfig power off make a difference for you?
It seems to be already off,
Ok.
//Peter
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Efficient emails [was: The newest Macbook 13.3 wireless]
Hi Daniel, Daniel Kuehn wrote: Just reply under (below) quoted text (as I did in this mail). I see, I am used to the opposite way in a normal email conversation on gmail :P Will have to re think when posting to MLs then ^^ Thanks for keeping a good attitude! :) Although Gmail has a huge number of users, there are thousands of other email programs and frequently when using mailing lists you are likely to be communicating with people who are using different email workflows. Besides bottom-posting I think it helps a great deal to make email discussions more readable to drastically trim the amount of quoted text from previous messages in the conversation (AKA thread) _and_ to break up the quoted text and interleave replies with relevant quotes. (Always reply below quote though.) As I see it, the only reason to include any previous text at all is to provide context for the parts that are being replied to. An email could easily cover several related things at once, and in a reply it can be difficult to know what new points related to what parts of the original message. Interleaving reply text with minimal quoting helps make this a great deal clearer IMO. New readers in the thread can benefit greatly from quoted context, but on the other hand they can never get the full story at once unless every email includes every previous email. (But that's not a good idea.) Old readers are likely to remember much of the context from previous messages. This means that anything but the absolute bare minimum of context provided to them is redundant, a waste of time, a waste of screen real estate (need to scroll past stuff they already know) and (maybe less important) a waste of bandwidth. Risk is higher that readers will not bother at all if they need to work more to find out if your message is useful. So - please make sure to remove as much as possible from the message(s) that you are replying to. Sometimes quotes need to be long to be useful, but most of the time I find that it's easy to remove 95% of previous messages when I reply. Yes - it's more work, but it saves a lot of time for everyone who is reading your message. Thanks! //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Notebooks compatibility with Broadcom cards
Rafał Miłecki wrote: I know there were some series of notebooks accepting only one kind of wireless cards. Not sure what vendor was that... Dell or HP maybe? HP and IBM/Lenovo both have BIOS checks for particular PCI IDs and only allow cards with certain IDs to be plugged in. Do you have any idea if I should be somehow careful when changing wireless card in my Acer? Sorry, no idea. Also is this possible my notebook is just too old to handle new wireless 802.11n card? Maybe too old mini pcie, or something like that? Check that the expansion socket is compatible. The 4318 is probably a mini-PCI card and .11n cards are usually mini-PCIe which is very different and not at all compatible. The card you buy must fit your socket. I've bought an Atheros miniPCI .11n card off eBay for my X40: http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItemitem=400078624952 But I haven't received it yet so I can't review. It's supposed to be supported by ath9k. I expect that I have to fiddle with the EEPROM on this card to get my ThinkPad to boot with it. Also check the antenna situation. .11n often uses MIMO so it might need an extra antenna to be installed in your laptop. Note how the above card has three connectors, and comes shipped with one antenna. Also note the MIMO arrangement so that it fits your needs. (In simplified terms it can be optimized for receive or transmit.) //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
Michael Buesch wrote: Hmm, surprise surprise. The slot is empty. They seem to have moved it onto the motherborad. Whoa, sick man. :) So I think there's a fair chance that there's no sprom at all, if the device is on-board. One idea is to look up the FCC ID of the laptop in the FCC database. Since the radio is onboard, there should be photos of the internals in the application, which is usually available as PDF online. //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43-phy0 ERROR: Fatal DMA error: 0x00000400
Larry Finger wrote: merely triggered by some interaction with ACPI and/or the BIOS. From what I found in looking back through the DMA error reports, most (if not all) people with the problem have netbook computers with Intel ATOM processors. Gábor Stefanik wrote: Linus has also reported this issue on a Core 2 ULV. I suspect that the key part is deep-sleep support in the CPU. Atom has new (lower) power states, with wakeup sequences that are very different from previous PC platforms. I don't know exact details, unfortunately. :\ Also, PhoenixBIOS seems to play part in the problem. I do know that the power sequencing is not really part of the Intel reference platform, but rather it will be solved in a microcontroller or embedded controller by the systems designer. The BIOS needs to support this properly. This is all new stuff on PCs. It is very possible that there are BIOS bugs. If you send an email to the coreboot mailing list, it is possible that someone there has an Atom system running coreboot and would be willing to help test if given a card. If so, they are also very knowledgeable about the lowlevel details. //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 kills my kernel
Oncaphillis wrote:
I poked around in the sbb code and found that ssb_do_read never
returns:
snip
static int sprom_do_read(struct ssb_bus *bus, u16 *sprom)
You wrote ssb_do_read above, this is sprom_do_read. Maybe they call
each other?
So I guess the mmio address is wrong. It is set to decimal
-133791744 when it freezes. I don't know if that's a valid mmio
address but it seems fishy.
$ printf %x\\n -133791744 | sed 'sx.*\(.\{8\}\)x\1x'
f8068000
Basically looks ok, but..
01:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g
[14e4:4315] (rev 01)
..
Region 0: Memory at 5710 (64-bit, non-prefetchable) [size=16K]
It should be closer to this region.
//Peter
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43/BCM4312 fails with DMA errors
Chris Vine wrote: The problem is not with b43, but with ACPI. The debugging will need to be done by that set of devs. OK. I may try blacklisting different ACPI modules and see if I can identify which one is causing the problem. I'd suggest to go directly to the ACPI mailing list, do not pass go. :) They will want you to do more, and other, testing in order to track down the problem. //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: ssb problem on ar71xx ubiquiti routerstation
Daniel Schmitt wrote: Is it right, that the only way to get 4 minipci cards working is a x86 PC with a big huge ATX power supply and a big case? I know of ALIX but I want something small and cheap for driving bcm4306 cards ... :( The ALIX is a pretty nice deal, some models run under 70 EUR. It doesn't support 4 cards however.. //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: LP-PHY status?
Rafał Miłecki wrote: Stefanik is there change you find some time to finish calibration part before .32 merge window? Don't want to rush you, you already have done great work, just would like to know. Developers can (and they should) react very badly to questions like this. Many times I do, I have no idea about Stefanik. Asking for progress like this is, in fact, precisely trying to rush development. You would like this work to be finished already, and if you have to wait, ok, but you want it as soon as possible, because you want to use it. At the very least you want to know when it will be finished. Remember that there is NO WARRANTY, no guarantees for delivery dates, no nothing. The code is not even guaranteed to work! If it does work, it's really a success. I think you know this. In the open source world, when someone needs something, they help create it, and it is done when it is done. Not everyone can help with programming, but there are other tasks as well. And donations always help of course! I think you know this too. Just a friendly reminder. Kind regards //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC PATCH] b43: Implement LP-PHY baseband table initialization
Gábor Stefanik wrote:
+ 0x0128,
+ 0x0128,
+ 0x0009,
+ 0x0009,
+ 0x0028,
+ 0x0028,
Is it possible to use more than one value per line for all these
tables?
if you know a good regex to convert the tables to use multiple
values on each line, please post it.
Try this:
tr -d ' \n'|sed 's-\(\([^,]*,\)\{9\}\)-\1\n-g'|sed 's,^, ,'
9 is the number of values you want on each line.
//Peter
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Ask for help about openChrome killing Broadcom
Hi, Rafał Miłecki wrote: Problem is that 0x2A doesn't seem to be anything outside our pci region. No, but it has reserved bits. I know it's not really your business, Correct. This issue has nothing to do with b43, and everything to do with PCIe in general in the chipset. Classic mixup of symptom and cause. That said, .. but any help/tips would be appreciated. ..I didn't know there was a ticket. There was a thread about this issue on openchrome-devel back in November, but the ticket was never mentioned in that thread. At any rate I've tried to clarify a bit in http://www.openchrome.org/trac/ticket/288#comment:24 and I believe r746 of OpenChrome should have fixed the issue. Further discussion via Trac or openchrome-devel, please. //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 4311 not detected at all
Fabio A. Correa wrote: The bottom line is that a BIOS error is likely the problem with BAR allocation on your machine. Have you checked to see if an updated one is available? Hey, I found an updated BIOS available in the HP site, obviously requiring Windows. I had deleted those partitions, so I will get a Windows hard disk/CD and try to flash it. You may be able to use flashrom as developed by the coreboot project to flash your BIOS. Maybe. If not, come on IRC or the mailing list and we can try to help you get it to work on your laptop. http://coreboot.org/Flashrom http://coreboot.org/IRC http://coreboot.org/Mailinglist By the way, what is BAR? The boot firmware (usually BIOS) assigns PCI devices an address range through which software can exchange data with the device. Each device specifies the size for it's address ranges, the firmware calculates how all ranges fit together, and then writes the start, or base, address to the respective BAR in each device. The addresses are the same as RAM addresses, which is why 32-bit systems can not use full 4GB of RAM. The PCI device address ranges will occupy the last part of memory space. Better BAR allocation algorithms could allow more usable RAM, but it also depends on chipset limitations. //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4312 (B/G) (low power)
Pascal de Bruijn wrote: The card does not seems easily replaceable, since the BIOS actually checks which WiFi card is installed during boot. And it won't boot with a non HP branded Intel card. I would try to patch the BIOS, but that's not a good solution for everyone. :\ //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy: My laptop has no button for rfkill but the driver sais it has...
Larry Finger wrote: If your laptop does not have an RFKILL button, I have no idea where the signal to kill the radio is coming from. It can be connected to just about any GPIO pin on any chip in the system. The super IO, embedded controller and chipset all have IOs to spare, some chips have a lot of them too. Two designers at the Taiwanese ODM may know which pin controls it. Reverse engineer it. //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4312 Fails when xdm is started
Yuval Hager wrote: I played around with different video drivers and the results are: * If using the 'via' driver, I lose the PCIe card immediately upon initialization * Using the 'openchrome' (trunk version), It works well in the beginning. After first blanking the register reads are all 1's, and then when the screen is blank I get a different read (some registers are correct, some are wrong), and when the screen is unblanked, I get 0xff's again. Very consistent and predictabe (same read every time). * Using the 'vesa' driver I could not recreate the problem. I could not get the screen to blank for some reason, but closing the lid, going on standby/hibernate, restarting X - all didn't matter much to the PCI and the wireless card kept on working. Good work! You have beyond any doubt established that the X graphics driver can cause this problem. Were you using a kernel framebuffer driver when you saw the problem also without running X at all? If not, the cause of trouble then is still unidentified. //Peter pgpARW21DAltA.pgp Description: PGP signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4312 Fails when xdm is started
Michael Buesch wrote:
On Sunday 23 November 2008 12:49:55 Yuval Hager wrote:
[ 182.891400] ** b43: B43_MMIO_MACCTL 0x840A0503
[ 182.891409] ** b43: SSB_TMSLOW 0x2015
[ 258.299027] irq 10: nobody cared (try booting with the irqpoll option)
Does the kernel disable the PCI device, if it ignores the IRQ?
The kernel disables the IRQ at least internally, maybe also by
deconfiguring the interrupt register in any devices using it, which
would explain the change in config register 0x3c (but not the changes
in all the other bytes, could that be a freak chain reaction inside
the hardware?) but I haven't heard/seen the kernel disable the PCI
device itself. I don't know if it can.
Why doesn't b43 care about this interrupt? Without APIC interrupt 10
is what both device and driver should be using (according to earlier
lspci -x output).
[ 258.299173] handlers:
[ 258.299176] [f7906455] (b43_interrupt_handler+0x0/0x1b7 [b43])
[ 258.299212] Disabling IRQ #10
[ 258.315148] b43-phy0: Radio hardware status changed to DISABLED
[ 258.315160] b43-phy0: B43_B43_MMIO_RADIO_HWENABLED_HI 0x
[ 258.342341] kobject: 'rfkill0' (f43b7d78): kobject_uevent_env
[ 258.342367] kobject: 'rfkill0' (f43b7d78): fill_kobj_path: path =
'/class/rfkill/rfkill0'
[ 258.342418] kobject: 'ssb0:0' (f40dfcd8): fill_kobj_path: path =
'/devices/pci:00/:00:02.0/:02:00.0/ssb0:0'
Why does the radio hw status changes here?
How is the change notified to the driver?
[ 258.391951]
[ 258.391956] =
[ 258.391964] [ INFO: inconsistent lock state ]
[ 258.391971] 2.6.28-rc5 #15
[ 258.391975] -
[ 258.391980] inconsistent {in-hardirq-W} - {hardirq-on-W} usage.
[ 258.391987] X/3965 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 258.391993] (irq_desc_lock_class){++..}, at: [c0148c60]
try_one_irq+0x15/0xe8
[ 258.392016] {in-hardirq-W} state was registered at:
[ 258.392021] [c013bc07] __lock_acquire+0x490/0x6bc
[ 258.392034] [c013be8d] lock_acquire+0x5a/0x74
[ 258.392043] [c01496f8] handle_level_irq+0x12/0xba
[ 258.392053] [c03c4842] _spin_lock+0x1c/0x45
[ 258.392066] [c01496f8] handle_level_irq+0x12/0xba
[ 258.392076] [c01496f8] handle_level_irq+0x12/0xba
[ 258.392085] [c010564e] do_IRQ+0x89/0x9f
[ 258.392096] [c0103ea8] common_interrupt+0x28/0x30
[ 258.392105] [c03c4cc2] _spin_unlock_irqrestore+0x37/0x39
[ 258.392115] [c01487e6] __setup_irq+0x17a/0x1f3
[ 258.392124] [c05ce79d] start_kernel+0x285/0x2f1
[ 258.392140] [] 0x
[ 258.392159] irq event stamp: 1844456
[ 258.392164] hardirqs last enabled at (1844456): [c03c4b6f]
_spin_unlock_irq+0x20/0x23
[ 258.392175] hardirqs last disabled at (1844455): [c03c4ac3]
_spin_lock_irq+0xa/0x4b
[ 258.392186] softirqs last enabled at (1844310): [c0125406]
do_softirq+0x37/0x4d
[ 258.392198] softirqs last disabled at (187): [c0125406]
do_softirq+0x37/0x4d
That's a bit weird. Looks like another bug in the IRQ layer.
Something happens with the hardware that confuses the kernel. It's
triggered by software but I don't know where.. Like Michael, I'm
not too convinced that it is in b43. :\
//Peter
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4312 Fails when xdm is started
Yuval Hager wrote: When the wireless is working: 00: e4 14 12 43 06 01 10 00 02 00 80 02 08 00 00 00 10: 04 c0 ff fd 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 0a 01 00 00 After it fails: 00: e4 14 12 43 00 00 10 00 02 00 80 02 00 00 00 00 10: 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 01 00 00 Differences: 04h bit 1: A value of 1 allows the device to respond to Memory Space addresses. 04h bit 2: A value of 1 allows the device to behave as a bus master. 04h bit 8: A value of 1 enables the SERR# driver. 0ch bit 3: System cacheline size in units of DWORDs. 10h: BAR0 (memory mapped address for device) 3ch bits 7:0: Interrupt Line Basically the card has been deconfigured. This should never happen. Try the following (somewhat naive) command to see if it starts working again: setpci -d 14e4:4312 c.l=8 10.l=fdffc004 4.w=0106 //Peter pgpFVIyLNz5Et.pgp Description: PGP signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4312 Fails when xdm is started
Michael Buesch wrote: Are these all the read/write bits in the configuration area? No, there are more of them. Most bytes in config space are rw, except the first four. Should I conclude that someone zeroed this area? No, because there are still valid bytes. Especially the first byte in the BAR being non-zero (maybe even unchanged) is peculiar. Yeah well. I'm not sure. It _looks_ like someone completely cut the physical power line to the card and it reset its complete PCI config. PCIe maps config space into MMIO IIRC. It might be clobbered that way. So well, X does poke with the PCI devices. But as you said it also happens if X doesn't run, I'd rule that out. Agree. But I would not rule out a fucked BIOS, yet. Possibly. Does the BIOS have any powersave options and/or spread-spectrum options for the PCI-bus? Can you try to turn them all off? Being a HP I don't expect there are many options in the BIOS. :\ In case the kernel memory diagnostics don't help, is there any way to trap writes to the configuration registers? Well, if we have random memory corruption, that can hit memory and MMIO. It doesn't hurt to turn on all debugging options. Often you get some hint by doing so. I hope this will give some more info. I think it will. //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [BCM4312][kernel 2.6.27] - wireless fails after X starts
Yuval Hager wrote: HP Mini 2133 I posted about the wifi in this guy a while back. It has ABG b43 which isn't really properly supported, at least not the A part but the reaction I got from mentioning the chipset made me not expect too much. I don't know if the ABG can be expected to behave exactly like the BG when not using .11a. I doubt it. (HP product number FU346EA). I just now noticed that the wifi seems to be a miniPCI card. If I was you I would just replace it. :) this problem is recreated exactly the same every time. wireless works correctly as long as I don't start X (or maybe it's KDE trying to reset something when it loads?) You can test this by starting only the X server and nothing else, simply run the command X (one capital X) instead of startx or an init script for kdm or anything else. You will get only the X server running (black/white dots background) and you have to kill it with Ctrl-Alt-Backspace. It would be interesting to know the results. I booted Vista once (that came with the machine) and everything was working fine, so I assume the hardware is ok (but I don't have vista anymore). Yes. I expect it's the ABG causing problems because it isn't so well known. I'm looking to get one of those machines too. RSN.. :) //Peter pgpgwthlfigzv.pgp Description: PGP signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC/T] b43: to few loop tries in do_dummy_tx
Michael Buesch wrote: Nice work, but as it's a spec of another driver implementation rather than hardware (or even the firmware API) I don't think it should be so authoritative. If other values are clearly better why not use them? What crap are you smoking? Maybe we just miscommunicated, or maybe I misunderstood something about the reverse engineering process. I am very new to this project. The b43 and b43-legacy driver are _based_ on these specifications. There are no other specs available. I know. Allow me to clarify my train of thought: * Specs are created by reverse engineering of a binary blob. * After development of b43*, many can happily use the drivers. \o/ * As it turns out, b43* can be made even more reliable by doing things slightly different than what the specs say. Case in point looping a little longer. At this point, if there are only/mostly benefits, I don't see why deviating from the specs is bad - after all they only document another driver, right? //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC/T] b43: to few loop tries in do_dummy_tx
Michael Buesch wrote: Actually, I do know since the very first days of bcm43xx that the loop counts are not big enough in some of these loops. Would it make sense to double check the conditions after the loop? But I didn't change it, as it was said the current counts match the specs. Which specs? //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Multiple station interfaces
Celejar wrote: simultaneously associate with two different APs They would at least have to be on the same channel - or I think you would need double radios and hardware tricks? //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC/T] b43: to few loop tries in do_dummy_tx
Larry Finger wrote: Which specs? The ones generated by the reverse engineers. See http://bcm-v4.sipsolutions.net/. Nice work, but as it's a spec of another driver implementation rather than hardware (or even the firmware API) I don't think it should be so authoritative. If other values are clearly better why not use them? //Peter ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] b43: A patch for control of the radio LED using rfkill
Johannes Berg wrote: .. (b) take rfkill state and transform it into conf.radio_enabled along with the internal conf.radio_enabled state that mac80211 may decide on based on iwconfig txpower off. assume that users know what they're doing if they iwconfig txpower off, I think it's pretty pointless to have in light of rfkill and for all I care we can remove it From a usability perspective anything but a single control at the core is utterly confusing and must IMO be avoided at all cost. Driver only has to follow conf.radio_enabled and inform mac80211 of the hard state. Where's the flaw? Seems complete. I like it. b43 radio state in hardware is a simple logic nor; when both bits are 0 the radio is on. There are many different ways for the user to signal radio enable or disable; radio control is not symmetric. I think the confusion may come from the two separate methods of disabling radio in b43 hardware. There can be both a button suitable for rfkill integration, and a button that overrides whatever software tries to do. The latter is notification only (but pressing it does generate a notification, right? Or is it polled?) and should maybe not be handled by rfkill (I too am not very familiar with the rfkill design :\) but must certainly be reflected in LEDs. Again, LEDs _must_ follow hardware state. Usability. I think the simplest way to accomplish that is logic that funnels into one single radio setting and the LED following that setting. The twist is that radio state is not only controlled by the kernel, but also by hardware. //Peter pgpcyYXN4IcY4.pgp Description: PGP signature ___ 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
