On Friday 26 March 2010, Larry Finger wrote:
Some recent BCM43XX devices lack an on-board SPROM. The pertinent data
from the SPROM could be included in the kernel; however, this presents
a problem in the generation of a unique, reproducible MAC address. The
solution is to initialize the address to
On 03/26/2010 06:18 AM, Gene Heskett wrote:
On Friday 26 March 2010, Larry Finger wrote:
Some recent BCM43XX devices lack an on-board SPROM. The pertinent data
from the SPROM could be included in the kernel; however, this presents
a problem in the generation of a unique, reproducible MAC
On 03/23/2010 03:58 PM, Calvin Walton wrote:
I will warn you that the following is rather untested, as I don't have
any of the affected hardware (or any b43 devices at all, actually), but
something along these lines should work. There's no syntax errors, at
least :)
---
On Wednesday 24 March 2010 15:16:03 Larry Finger wrote:
I have modified ssb to supply a MAC address of 80:80:80:80:80:80, rather than
What about also setting the local-assignment bit for this temporary address?
The one remaining problem is that the interface has already been renamed
before
On Tuesday 23 March 2010 00:45:28 Larry Finger wrote:
(2) In drivers/ssb/pci.c, the firmware loading process reads the file, then
modifies it using the bus address.
No. You don't need firmware loading at all.
udev can just set the mac address through the standard ioctl calls.
Just like how
On Tuesday 23 March 2010 09:55:39 Florian Fainelli wrote:
Why not use random_ether_addr and only use the digits that you are interested
in?
Because it's not constant across reboots.
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
On 03/23/2010 03:52 AM, Michael Buesch wrote:
On Tuesday 23 March 2010 00:45:28 Larry Finger wrote:
(2) In drivers/ssb/pci.c, the firmware loading process reads the file, then
modifies it using the bus address.
No. You don't need firmware loading at all.
udev can just set the mac address
On 03/22/2010 09:57 PM, Frank Middleton wrote:
Had some really great experiences with your software recently, especially
using a public Wifi system with really weak/out of range signals. I could
still get emails even when Windows couldn't find any unencrypted APs,
and it worked like a champ
On 03/23/2010 02:30 PM, Chris Lopes wrote:
Hi,
I had a perfectly working Dell system running Windows Vista and using
version 5.60.188.1 of the Broadcom windows driver (distributed by
Dell) for what Windows calls the Dell Wireless 1397 WLAN Mini-Card,
which is actually 14e4:4315.
I booted
On 03/23/2010 02:53 PM, Chris Lopes wrote:
Thanks for the quick reply. So are you saying that it is impossible
that the b43 driver could have somehow made my wireless card unable to
detect any networks after a reboot (in either Windows or Linux)?
I don't know of any way that b43 could have
Ok. I got my wireless card to detect networks again. I also had a
theory and tried to reproduce the problem, and was successful in doing
so. Here are my steps to reproduce:
1) Have Vista running and connected to a wireless network
2) Hibernate Vista
3) Boot Parted Magic from a USB drive
4)
On 03/23/2010 03:31 PM, Chris Lopes wrote:
Ok. I got my wireless card to detect networks again. I also had a
theory and tried to reproduce the problem, and was successful in doing
so. Here are my steps to reproduce:
1) Have Vista running and connected to a wireless network
2) Hibernate
What does (or might) Wake On LAN have to do with this problem, exactly?
2010/3/24 Larry Finger larry.fin...@lwfinger.net:
On 03/23/2010 03:31 PM, Chris Lopes wrote:
Ok. I got my wireless card to detect networks again. I also had a
theory and tried to reproduce the problem, and was successful
: bcm43xx-dev@lists.berlios.de
Subject: Re: 14e4:4315 (Dell Wireless 1397) cannot find networks after use of
b43 driver
Ok. I got my wireless card to detect networks again. I also had a
theory and tried to reproduce the problem, and was successful in doing
so. Here are my steps to reproduce:
1) Have
On Tuesday 23 March 2010 21:58:22 Calvin Walton wrote:
On Tue, 2010-03-23 at 09:25 -0500, Larry Finger wrote:
Will someone please write me udev rule(s) that do the following:
1. Detect a MAC address of FF:FF:FF:FF:FF:FF
2. If this is the first time for this bus address, then generate a
On Wed, 24 Mar 2010 03:31:42 +0700
Chris Lopes clo...@gmail.com wrote:
Ok. I got my wireless card to detect networks again. I also had a
theory and tried to reproduce the problem, and was successful in doing
so. Here are my steps to reproduce:
1) Have Vista running and connected to a
I didn't try a cold reboot that did not involve the removal of
battery and power supply, so maybe it would work.
Honestly I am still perplexed (given modern hardware and software), as
to why/how:
1) Hibernate and un-hibernate, regardless of what happens in between
with the wireless card, could
On Tue, Mar 23, 2010 at 11:23 PM, Chris Lopes clo...@gmail.com wrote:
I didn't try a cold reboot that did not involve the removal of
battery and power supply, so maybe it would work.
Honestly I am still perplexed (given modern hardware and software), as
to why/how:
1) Hibernate and
On Tue, 23 Mar 2010 23:37:45 +0100
Gábor Stefanik netrolller...@gmail.com wrote:
(On 2.6.33, b43 works around this by falling back to PIO.)
I think it requires 2.6.34 for this (currently 2.6.34-rc2).
Chris
___
Bcm43xx-dev mailing list
On Mon, 22 Mar 2010 20:54:14 -0400
Celejar cele...@gmail.com wrote:
Hi,
I have been using my 4318 successfully with b43 (thanks, Michael and
all devs / reverse engineers!) for many kernel revisions now, both as a
client, as well as in monitor mode (kismet, airodump). With
2.6.34-rc1, I
Michael Buesch wrote:
On Monday 22 March 2010 22:56:44 Larry Finger wrote:
Does anyone have any suggestions on what characteristic could be used to
generate a unique MAC address for a box in a udev rule?
/dev/urandom
Yeah, there's the chance of clashes. In practice there won't be
On Monday 22 March 2010 07:28:23 Calvin Walton wrote:
Hi,
On Sat, 2010-03-20 at 19:14 -0500, Larry Finger wrote:
Some recent BCM43XX devices lack an on-board SPROM. The pertinent data
from the SPROM could be included in the kernel; however, this presents
a problem in the generation of a
On 03/22/2010 03:37 AM, Michael Buesch wrote:
On Monday 22 March 2010 07:28:23 Calvin Walton wrote:
Hi,
On Sat, 2010-03-20 at 19:14 -0500, Larry Finger wrote:
Some recent BCM43XX devices lack an on-board SPROM. The pertinent data
from the SPROM could be included in the kernel; however, this
On 03/22/2010 04:55 PM, Michael Buesch wrote:
I don't see a problem for udev to distinguish the cards. It can do it merely
on
the bus-ID. That's unique. Yeah, it might change if you change the hardware.
But do we care? I say no, because you cannot actually change the hardware in
real life
On Monday 22 March 2010 22:56:44 Larry Finger wrote:
Does anyone have any suggestions on what characteristic could be used to
generate a unique MAC address for a box in a udev rule?
/dev/urandom
Yeah, there's the chance of clashes. In practice there won't be any clashes,
however. If you think
On Monday 22 March 2010 23:19:54 Larry Finger wrote:
On 03/22/2010 04:55 PM, Michael Buesch wrote:
I don't see a problem for udev to distinguish the cards. It can do it
merely on
the bus-ID. That's unique. Yeah, it might change if you change the hardware.
But do we care? I say no,
Michael,
Would the following be sufficient?
(1) The utility /bin/dbus-uuidgen is used to create a file
/lib/firmware/ssb/mac_address. The command to create this file if it does not
exist could be added to the scripts that use fwcutter.
(2) In drivers/ssb/pci.c, the firmware loading process
On Sunday 21 March 2010 01:14:51 Larry Finger wrote:
Some recent BCM43XX devices lack an on-board SPROM. The pertinent data
from the SPROM could be included in the kernel; however, this presents
a problem in the generation of a unique, reproducible MAC address. The
solution has been to create
On Thursday 18 March 2010 22:38:17 Larry Finger wrote:
On 03/18/2010 02:31 PM, Michael Buesch wrote:
On Thursday 18 March 2010 18:46:35 Larry Finger wrote:
(1) Modify b43-fwcutter to take data from an existing SPROM,
Why not extend the ssb-sprom tool? I don't think this has anything to
On Thu, 2010-03-18 at 16:10 -0500, Larry Finger wrote:
On 03/18/2010 03:53 PM, Johannes Berg wrote:
On Thu, 2010-03-18 at 12:46 -0500, Larry Finger wrote:
Michael,
I'm switching this discussion from the kernel Bugzilla to the lists.
As you know, but I'm restating for anyone that has
On Thu, Mar 18, 2010 at 08:31:24PM +0100, Michael Buesch wrote:
On Thursday 18 March 2010 18:46:35 Larry Finger wrote:
It it reasonable to keep the vendor portion of the MAC and only replace the
serial number, or would it be better to randomize all 6 octants?
I think it doesn't really
On Thu, 2010-03-18 at 12:46 -0500, Larry Finger wrote:
Michael,
I'm switching this discussion from the kernel Bugzilla to the lists.
As you know, but I'm restating for anyone that has not read our previous
discussions, the b43 driver needs to be changed to handle some of the newer
devices
On Thu, Mar 18, 2010 at 12:26:32AM +, Chris Vine
ch...@cvine.freeserve.co.uk wrote:
I suggest you add to this thread in linux-acpi (and lkml), that you can
reproduce the problem, and it might then get some attention:
http://marc.info/?l=linux-kernelm=126879129905898w=2 .
Done.
Out of
On Wed, 17 Mar 2010 20:09:41 +0100
Miklos Vajna vmik...@frugalware.org wrote:
Hi,
I recently upgraded to 2.6.33, then 2.6.34-rc1, but both have the same
bugs:
1) The earlier mentioned problem is still there, the b43 driver
disconnects if no WPA is used by the AP.
(This is not an issue
On Thursday 18 March 2010 18:46:35 Larry Finger wrote:
(1) Modify b43-fwcutter to take data from an existing SPROM,
Why not extend the ssb-sprom tool? I don't think this has anything to do with
firmware, except that we (ab)use the firmware loading mechanism of the kernel
for loading the blob
Larry Finger wrote :
Michael,
I'm switching this discussion from the kernel Bugzilla to the lists.
As you know, but I'm restating for anyone that has not read our previous
discussions, the b43 driver needs to be changed to handle some of the newer
devices do not have an on-board SPROM. It
On 03/18/2010 03:53 PM, Johannes Berg wrote:
On Thu, 2010-03-18 at 12:46 -0500, Larry Finger wrote:
Michael,
I'm switching this discussion from the kernel Bugzilla to the lists.
As you know, but I'm restating for anyone that has not read our previous
discussions, the b43 driver needs to be
On 03/18/2010 02:31 PM, Michael Buesch wrote:
On Thursday 18 March 2010 18:46:35 Larry Finger wrote:
(1) Modify b43-fwcutter to take data from an existing SPROM,
Why not extend the ssb-sprom tool? I don't think this has anything to do with
firmware, except that we (ab)use the firmware
then?
In the Linux driver and likely in the Windows driver, the SPROM data is read
from the SPROM and encoded into a set of tagged strings. After that, the actual
SPROM is ignored. I have not completed the RE on this area, but it looks as if
they have a set of canned data that is copied into the area
On Thu, 2010-03-18 at 16:20 -0400, John W. Linville wrote:
On Thu, Mar 18, 2010 at 08:31:24PM +0100, Michael Buesch wrote:
On Thursday 18 March 2010 18:46:35 Larry Finger wrote:
It it reasonable to keep the vendor portion of the MAC and only replace
the
serial number, or would it be
Hi,
I recently upgraded to 2.6.33, then 2.6.34-rc1, but both have the same
bugs:
1) The earlier mentioned problem is still there, the b43 driver
disconnects if no WPA is used by the AP.
(This is not an issue with the binary broadcom 'wl' driver.)
2) The wireless card seems not to be functional
On Tuesday 16 March 2010, Chris Vine wrote:
On Mon, 8 Mar 2010 17:22:26 +
Chris Vine ch...@cvine.freeserve.co.uk wrote:
I have noticed that although my BCM4312 802.11b/g [14e4:4315] wireless
device works using the PIO option in 2.6.33, it breaks after a suspend
or hibernate. Attempts
On Thu, 18 Mar 2010 00:26:32 +
Chris Vine ch...@cvine.freeserve.co.uk wrote:
[snip]
I suggest you add to this thread in linux-acpi (and lkml), that you
can reproduce the problem, and it might then get some attention:
http://marc.info/?l=linux-kernelm=126879129905898w=2 .
Ah, I see you
Hi,
On Mon, Mar 15, 2010 at 07:41:02PM -0500, Larry Finger wrote:
On 03/15/2010 06:20 PM, Marc Haber wrote:
On Thu, Mar 04, 2010 at 06:54:23PM +0100, Marc Haber wrote:
when the broadcom-sta driver didn't compile with 2.6.33 I decided to
give b43 a new try. I have a Lenovo Ideapad S12,
On Mon, 8 Mar 2010 17:22:26 +
Chris Vine ch...@cvine.freeserve.co.uk wrote:
I have noticed that although my BCM4312 802.11b/g [14e4:4315] wireless
device works using the PIO option in 2.6.33, it breaks after a suspend
or hibernate. Attempts to bring up the wlan0 interface with
'ifconfig
Hi,
On Thu, Mar 04, 2010 at 06:54:23PM +0100, Marc Haber wrote:
when the broadcom-sta driver didn't compile with 2.6.33 I decided to
give b43 a new try. I have a Lenovo Ideapad S12, which has a BCM4312
with LP Phy (14e4:4315). I am using Debian unstable.
When I load the module, a new
On 03/15/2010 06:20 PM, Marc Haber wrote:
Hi,
On Thu, Mar 04, 2010 at 06:54:23PM +0100, Marc Haber wrote:
when the broadcom-sta driver didn't compile with 2.6.33 I decided to
give b43 a new try. I have a Lenovo Ideapad S12, which has a BCM4312
with LP Phy (14e4:4315). I am using Debian
On Sat, Mar 13, 2010 at 7:48 PM, Michael Buesch m...@bu3sch.de wrote:
On Saturday 13 March 2010 19:38:01 Gábor Stefanik wrote:
I know this one it is compatible with aircrack supporting injection
Thank you for your invaluable help ..
thank
As a general rule, do not bug Michael with
On Saturday 13 March 2010 19:38:01 Gábor Stefanik wrote:
I know this one it is compatible with aircrack supporting injection
Thank you for your invaluable help ..
thank
As a general rule, do not bug Michael with injection-related
questions; the only one in the team who cares about
On Sat, Mar 13, 2010 at 7:05 PM, mic cat micac...@gmail.com wrote:
Hi all
i have 2 Broadcom network controller :
BCM4312 802.11 B/G 14E4:4315
This is supported in 2.6.32 and newer; though you may need to compile
with CONFIG_B43_FORCE_PIO if you have a netbook and/or a machine with
Hi Larry,
On Sat, Mar 06, 2010 at 07:57:57AM -0600, Larry Finger wrote:
On 03/06/2010 04:07 AM, Marc Haber wrote:
On Fri, Mar 05, 2010 at 05:54:24PM +, Chris Vine wrote:
You can get the Ideapad to work by forcing use of the PIO however.
How exactly do I do this? I remember trying by
On Mon, Mar 8, 2010 at 11:28 AM, Marc Haber mh+bcm43xx-...@zugschlus.de wrote:
Hi Larry,
On Sat, Mar 06, 2010 at 07:57:57AM -0600, Larry Finger wrote:
On 03/06/2010 04:07 AM, Marc Haber wrote:
On Fri, Mar 05, 2010 at 05:54:24PM +, Chris Vine wrote:
You can get the Ideapad to work by
2010/3/8 Marc Haber mh+bcm43xx-d...@zugschlus.de:
Hi,
On Mon, Mar 08, 2010 at 12:54:44PM +0100, Gábor Stefanik wrote:
That message sounds like you are using iwlist to scan - try iw instead.
Yes, I am using iwlist. Has this changed? Have the tools like wicd
and/or network-manager already
On Thu, Mar 4, 2010 at 1:30 AM, Larry Finger larry.fin...@lwfinger.net wrote:
On 03/02/2010 03:57 PM, Michael Buesch wrote:
A bug in the PCI-E core code is able to show such behavior, because all
memory
transfers (MMIO and DMA) from the PCI device to the wireless core are
translated
by
On 03/03/2010 06:47 PM, Gábor Stefanik wrote:
On Thu, Mar 4, 2010 at 1:30 AM, Larry Finger larry.fin...@lwfinger.net
wrote:
On 03/02/2010 03:57 PM, Michael Buesch wrote:
A bug in the PCI-E core code is able to show such behavior, because all
memory
transfers (MMIO and DMA) from the PCI
On 03/02/2010 03:57 PM, Michael Buesch wrote:
A bug in the PCI-E core code is able to show such behavior, because all memory
transfers (MMIO and DMA) from the PCI device to the wireless core are
translated
by the PCI-E core.
I think the whole PCI-E core code has to be audited (also the
Hello
Marc Haber wrote:
Hi,
when the broadcom-sta driver didn't compile with 2.6.33 I decided to
give b43 a new try. I have a Lenovo Ideapad S12, which has a BCM4312
with LP Phy (14e4:4315). I am using Debian unstable.
When I load the module, a new interface wlan0 appears, but iwlist
On 03/04/2010 12:49 PM, William Bourque wrote:
Hello
Marc Haber wrote:
Hi,
when the broadcom-sta driver didn't compile with 2.6.33 I decided to
give b43 a new try. I have a Lenovo Ideapad S12, which has a BCM4312
with LP Phy (14e4:4315). I am using Debian unstable.
When I load the
On Thu, Mar 04, 2010 at 01:16:26PM -0600, Larry Finger wrote:
CRDA is the user-space implementation of the regulatory database.
What will the b43 driver do without a CRDA user-space daemon? It's not
yet in Debian (see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536502).
Greetings
Marc
--
On Thu, Mar 04, 2010 at 01:49:14PM -0500, William Bourque wrote:
Silly question, but did you try to up (ifconfig wlan0 up) the
interface before scanning?
I tried ip link set dev wlan0 up, which gave me a few more dmesg lines:
b43 ssb0:0: firmware: requesting b43/ucode15.fw
b43 ssb0:0: firmware:
On 03/04/2010 03:46 PM, Marc Haber wrote:
On Thu, Mar 04, 2010 at 01:16:26PM -0600, Larry Finger wrote:
CRDA is the user-space implementation of the regulatory database.
What will the b43 driver do without a CRDA user-space daemon? It's not
yet in Debian (see
On Thu, 4 Mar 2010 22:46:10 +0100
Marc Haber mh+bcm43xx-...@zugschlus.de wrote:
On Thu, Mar 04, 2010 at 01:16:26PM -0600, Larry Finger wrote:
CRDA is the user-space implementation of the regulatory database.
What will the b43 driver do without a CRDA user-space daemon? It's not
yet in
On 03/04/2010 04:53 PM, Celejar wrote:
b43 works perfectly fine with my 4318 on my Debian Sid system, without
CRDA installed.
What kernel version is in Sid?
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
On Thu, 04 Mar 2010 17:11:06 -0600
Larry Finger larry.fin...@lwfinger.net wrote:
On 03/04/2010 04:53 PM, Celejar wrote:
b43 works perfectly fine with my 4318 on my Debian Sid system, without
CRDA installed.
What kernel version is in Sid?
Currently some version of 2.6.32. I should
On Thu, Mar 4, 2010 at 11:36 PM, Marc Haber mh+bcm43xx-...@zugschlus.de wrote:
On Thu, Mar 04, 2010 at 01:49:14PM -0500, William Bourque wrote:
Silly question, but did you try to up (ifconfig wlan0 up) the
interface before scanning?
I tried ip link set dev wlan0 up, which gave me a few more
On 03/04/2010 05:33 PM, Celejar wrote:
Currently some version of 2.6.32. I should have noted that I actually
usually run self-built vanilla ones (from upstream mainline), but I'm
pretty sure that b43 works even when I use the Debian packaged ones
from the repos.
It may fail with 2.6.33.
On Thu, 04 Mar 2010 17:52:15 -0600
Larry Finger larry.fin...@lwfinger.net wrote:
On 03/04/2010 05:33 PM, Celejar wrote:
Currently some version of 2.6.32. I should have noted that I actually
usually run self-built vanilla ones (from upstream mainline), but I'm
pretty sure that b43 works
On Tuesday 02 March 2010 23:25:48 William Bourque wrote:
So if I get this right, this code is responsible of handling the b43
devices, as well as several other PCI-E devices, correct?
Nah, this is a broadcom specific thing of the on-chip SSB bus.
Because now that you mention this, the wired
Michael Buesch wrote:
On Tuesday 02 March 2010 23:25:48 William Bourque wrote:
So if I get this right, this code is responsible of handling the b43
devices, as well as several other PCI-E devices, correct?
Nah, this is a broadcom specific thing of the on-chip SSB bus.
Ok, sorry then :)
On Monday 01 March 2010 01:22:50 Michael Buesch wrote:
Well, you are confusing address spaces here.
On a PCI based SSB device all host-side MMIO transfers go into
the PCI device's address space first. The core-switching moves the window of
the SSB address space that is mapped into 0-0xFFF of
On Sunday 28 February 2010 02:37:21 Rafał Miłecki wrote:
W dniu 27 lutego 2010 15:51 użytkownik Michael Buesch m...@bu3sch.de
napisał:
On Saturday 27 February 2010 12:12:23 Rafał Miłecki wrote:
2010/2/10 Michael Buesch m...@bu3sch.de:
On Tuesday 09 February 2010 21:04:33 Rafał Miłecki
2010/2/28 Nathan Schulte rekl...@gmail.com:
On Sat, Feb 27, 2010 at 7:03 PM, Nathan Schulte rekl...@gmail.com wrote:
2010/2/27 Larry Finger larry.fin...@lwfinger.net:
The printk's I sent yesterday can have timing info, but the timestamps
would not
be exactly coordinated - printk values seem
Chris Vine wrote:
On Sun, 28 Feb 2010 00:44:58 +0100
Gábor Stefanik netrolller...@gmail.com wrote:
2010/2/28 Nathan Schulte rekl...@gmail.com:
2010/2/27 Gábor Stefanik netrolller...@gmail.com:
OK, I whipped up a quick test patch with changes found so far
implemented. Please test if this
On Sun, Feb 28, 2010 at 7:00 PM, William Bourque
william.bour...@polymtl.ca wrote:
Chris Vine wrote:
This doesn't help on my netbook, I am afraid.
I confirm, it still crashes on my notebook as well. However the new
fallback to PIO behavior introduced earlier do a fine job getting it back
on
On Sun, Feb 28, 2010 at 7:00 PM, William Bourque
william.bour...@polymtl.ca wrote:
I confirm, it still crashes on my notebook as well. However the new
fallback to PIO behavior introduced earlier do a fine job getting it back
on track.
Btw, you are often refering to some documentation that
2010/2/28 Gábor Stefanik netrolller...@gmail.com:
On Sun, Feb 28, 2010 at 7:00 PM, William Bourque
william.bour...@polymtl.ca wrote:
I confirm, it still crashes on my notebook as well. However the new
fallback to PIO behavior introduced earlier do a fine job getting it back
on track.
Btw,
On Sunday 28 February 2010 19:52:53 Gábor Stefanik wrote:
2010/2/28 Rafał Miłecki zaj...@gmail.com:
2010/2/28 Gábor Stefanik netrolller...@gmail.com:
On Sun, Feb 28, 2010 at 7:00 PM, William Bourque
william.bour...@polymtl.ca wrote:
I confirm, it still crashes on my notebook as well.
New test patch attached.
Please CC linux-wirel...@vger.kernel.org on further e-mails,
bcm43xx-dev appears to be having problems.
Hmm... I don't know if it is only coincidence, but this one seems to
help somehow.
The driver raised the DMA error again, but instead of being as soon as I
On Sun, 28 Feb 2010 14:44:12 -0500
William Bourque william.bour...@polymtl.ca wrote:
New test patch attached.
Please CC linux-wirel...@vger.kernel.org on further e-mails,
bcm43xx-dev appears to be having problems.
Hmm... I don't know if it is only coincidence, but this one seems to
On Sunday 28 February 2010 21:30:38 Chris Vine wrote:
On Sun, 28 Feb 2010 19:58:11 +0100
Michael Buesch m...@bu3sch.de wrote:
It says 8k for all of my devices there. So an MMIO write to 0x2000
and above writes to completely random memory.
My BCM4312 device is 16K:
Region 0: Memory
Chris Vine wrote:
On Sun, 28 Feb 2010 19:58:11 +0100
Michael Buesch m...@bu3sch.de wrote:
It says 8k for all of my devices there. So an MMIO write to 0x2000
and above writes to completely random memory.
My BCM4312 device is 16K:
Region 0: Memory at f800 (64-bit, non-prefetchable)
On Sun, 28 Feb 2010 15:51:14 -0500
William Bourque william.bour...@polymtl.ca wrote:
Chris Vine wrote:
On Sun, 28 Feb 2010 19:58:11 +0100
Michael Buesch m...@bu3sch.de wrote:
It says 8k for all of my devices there. So an MMIO write to 0x2000
and above writes to completely random memory.
2010/2/28 Nathan Schulte rekl...@gmail.com:
2010/2/28 Gábor Stefanik netrolller...@gmail.com:
OK, this dump shows the 0x280a write happening with core 3, i.e. PCIE,
active. So, it is indeed probably the PCIE misc configuration
routine. Why it's 0x280a is still a mystery to me, it should be
On Monday 01 March 2010 00:38:16 Nathan Schulte wrote:
2010/2/28 Gábor Stefanik netrolller...@gmail.com:
The latest patch, which is a partial success according to some
testers, writes to core 1 (PCI-E) instead of core 0 (ChipCommon).
Then either I am misinterpreting the logs, or the last
On Sat, 27 Feb 2010 02:41:48 +0100
Gábor Stefanik netrolller...@gmail.com wrote:
Someone should test the following:
-Open drivers/ssb/driver_chipcommon_pmu.c
-In ssb_pmu_init, replace 0x4325 with 0x4312. (This is not the correct
way to fix this, but should be enough for a test. The correct fix
2010/2/9 Michael Buesch m...@bu3sch.de:
On Tuesday 09 February 2010 21:04:40 Rafał Miłecki wrote:
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/net/wireless/b43/phy_common.c | 11 +++
drivers/net/wireless/b43/phy_common.h | 2 ++
2 files changed, 13 insertions(+), 0
2010/2/10 Michael Buesch m...@bu3sch.de:
On Tuesday 09 February 2010 21:04:33 Rafał Miłecki wrote:
+#define B43_MMIO_PSM_PHY_HDR 0x492 /* programmable state machine
*/
The comment doesn't make a lot of sense.
In case you don't know, the PSM is the part of the hardware
that
On Friday 26 February 2010 23:03:28 Gábor Stefanik wrote:
BTW there is an interesting difference in the early init between wl
and b43: b43 sets bit 0x200 in core register 0x600, while wl sets
0x8000 in register 0x280a - an undocumented register.
Well, it is not only undocumented, it's also far
On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote:
Someone should test the following:
-Open drivers/ssb/driver_chipcommon_pmu.c
-In ssb_pmu_init, replace 0x4325 with 0x4312.
Uh, wait a second. Do _all_ cards that show the behavior have a PMU on the SSB?
If so, you should really make
On Saturday 27 February 2010 12:12:23 Rafał Miłecki wrote:
2010/2/10 Michael Buesch m...@bu3sch.de:
On Tuesday 09 February 2010 21:04:33 Rafał Miłecki wrote:
+#define B43_MMIO_PSM_PHY_HDR 0x492 /* programmable state
machine */
The comment doesn't make a lot of sense.
In
On Saturday 27 February 2010 12:09:30 Rafał Miłecki wrote:
2010/2/9 Michael Buesch m...@bu3sch.de:
On Tuesday 09 February 2010 21:04:40 Rafał Miłecki wrote:
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/net/wireless/b43/phy_common.c | 11 +++
On 02/27/2010 09:16 AM, Michael Buesch wrote:
On Friday 26 February 2010 23:03:28 Gábor Stefanik wrote:
BTW there is an interesting difference in the early init between wl
and b43: b43 sets bit 0x200 in core register 0x600, while wl sets
0x8000 in register 0x280a - an undocumented register.
On 02/27/2010 09:20 AM, Michael Buesch wrote:
On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote:
Someone should test the following:
-Open drivers/ssb/driver_chipcommon_pmu.c
-In ssb_pmu_init, replace 0x4325 with 0x4312.
Uh, wait a second. Do _all_ cards that show the behavior have
On Saturday 27 February 2010 16:55:09 Larry Finger wrote:
On 02/27/2010 09:16 AM, Michael Buesch wrote:
On Friday 26 February 2010 23:03:28 Gábor Stefanik wrote:
BTW there is an interesting difference in the early init between wl
and b43: b43 sets bit 0x200 in core register 0x600, while wl
On Saturday 27 February 2010 17:05:41 Larry Finger wrote:
On 02/27/2010 09:20 AM, Michael Buesch wrote:
On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote:
Someone should test the following:
-Open drivers/ssb/driver_chipcommon_pmu.c
-In ssb_pmu_init, replace 0x4325 with 0x4312.
On 02/27/2010 10:08 AM, Michael Buesch wrote:
On Saturday 27 February 2010 17:05:41 Larry Finger wrote:
On 02/27/2010 09:20 AM, Michael Buesch wrote:
On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote:
Someone should test the following:
-Open drivers/ssb/driver_chipcommon_pmu.c
-In
On Sat, Feb 27, 2010 at 5:37 PM, Larry Finger larry.fin...@lwfinger.net wrote:
On 02/27/2010 10:08 AM, Michael Buesch wrote:
On Saturday 27 February 2010 17:05:41 Larry Finger wrote:
On 02/27/2010 09:20 AM, Michael Buesch wrote:
On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote:
2010/2/27 Nathan Schulte rekl...@gmail.com:
I've been following along with the linux-wireless thread, and wanted
to bring up a few points.
1) If the report in reference by Gábor: Well, we have a report from
someone with an Intel T7250, ... is mine, note that my processor is
actually a T5670
On Saturday 27 February 2010 20:45:50 Gábor Stefanik wrote:
2. Just before the SPROM readout, we are missing a Set 0x8000 in
MMIO offset 0x280a. This looks curiously like PCI-E Miscellaneous
Configuration, from http://bcm-v4.sipsolutions.net/PCI-E - and
indeed, the value read out from
On 02/27/2010 01:45 PM, Gábor Stefanik wrote:
So, a quick status update, from what I've found yesterday:
1. We get the PMU setup wrong. Bit 0x200 is being set, despite the
PMU being rev1. Also, PMU setup is done too early - at least wl reads
the SPROM before setting up the PMU. A write
1 - 100 of 5577 matches
Mail list logo
