On Friday 20 November 2009 02:41:58 Oncaphillis wrote:
On 11/20/2009 12:46 AM, Oncaphillis wrote:
On 11/19/2009 06:44 PM, Michael Buesch wrote:
On Thursday 19 November 2009 16:41:12 Michael Buesch wrote:
Wait, that still can't work. I'll fix it soon...
Ok, here's the updated version.
On Friday 20 November 2009 00:55:07 Larry Finger wrote:
On 11/18/2009 11:21 PM, William Bourque wrote:
Also, just saying, but it seems Larry's pm_qos_update_requirement
patch had some good effects; I can hardly get any connectivity without
it. With the patch, the wireless seems to be
On 11/20/2009 10:27 AM, Michael Buesch wrote:
On Friday 20 November 2009 02:41:58 Oncaphillis wrote:
On 11/20/2009 12:46 AM, Oncaphillis wrote:
On 11/19/2009 06:44 PM, Michael Buesch wrote:
On Thursday 19 November 2009 16:41:12 Michael Buesch wrote:
Wait, that still can't work. I'll fix it
On Friday 20 November 2009 11:29:20 Oncaphillis wrote:
Ok -- Some more details about my experience that it appears to be slow.
Note that there are several issues. First one being the sprom calibration
values being _wrong_ for your card. Second one is LP-PHY performance being
crappy in
general
This patch adds a generic mechanism for overriding the SPROM mechanism
on devices without SPROM hardware.
There currently is a major problem with this:
It tries to deduce a MAC address from various hardware parameters. But
currently it will result in the same MAC address for machines of the same
On Friday 20 November 2009 12:38:07 Florian Fainelli wrote:
Why not call once random_ether_addr instead of using some kind of hash? Is it
because you
want the same MAC from a reboot to another?
yes.
Ok, so for BCM63xx I would no longer have to declare my SPROM, fine.
No you still need to
On 11/20/2009 04:54 AM, Michael Buesch wrote:
On Friday 20 November 2009 11:29:20 Oncaphillis wrote:
Ok -- Some more details about my experience that it appears to be slow.
Note that there are several issues. First one being the sprom calibration
values being _wrong_ for your card. Second
On 11/20/2009 03:29 AM, Michael Buesch wrote:
On Friday 20 November 2009 00:55:07 Larry Finger wrote:
If the pm_qos patch has some positive benefits, I'll push it; however, I
think
this is just a band aid, not a real fix. It also has the bad side effect of
keeping the CPU from going into
One last check. I would appreciate receiving answers to the following questions.
These questions apply to anyone else with this problem.
Does the pm_qos patch help your fatal DMA error problem, particularly when
booted from power-off?
If you warm-boot after loading the wl driver, does the patch
On Thu, Nov 19, 2009 at 05:55:07PM -0600, Larry Finger wrote:
On 11/18/2009 11:21 PM, William Bourque wrote:
Also, just saying, but it seems Larry's pm_qos_update_requirement
patch had some good effects; I can hardly get any connectivity without
it. With the patch, the wireless seems to
Larry Finger wrote:
One last check. I would appreciate receiving answers to the following
questions.
These questions apply to anyone else with this problem.
Does the pm_qos patch help your fatal DMA error problem, particularly when
booted from power-off?
If you warm-boot after loading
On 11/20/2009 05:12 AM, Michael Buesch wrote:
This patch adds a generic mechanism for overriding the SPROM mechanism
on devices without SPROM hardware.
There currently is a major problem with this:
It tries to deduce a MAC address from various hardware parameters. But
currently it will
Hi
On Friday 20 November 2009, Larry Finger wrote:
On 11/20/2009 05:12 AM, Michael Buesch wrote:
[...]
You might look at the root= part of /proc/cmdline. Mine says
root=/dev/disk/by-id/ata-TOSHIBA_MK2546GSX_18C2P0KCT-part1. That disk serial
number would certainly be unique. Even if it just
You might look at the root= part of /proc/cmdline. Mine says
root=/dev/disk/by-id/ata-TOSHIBA_MK2546GSX_18C2P0KCT-part1. That disk
serial
number would certainly be unique. Even if it just said root=/dev/sda1, it
would be repeatable.
Ok, I think this is getting ugly :)
The problem with all
On 11/20/2009 08:11 AM, Michael Buesch wrote:
Ok, I think this is getting ugly :)
The problem with all this is that if you change the harddisk, or change the
partitioning,
the wireless mac address would change. That would surely lead to confusion.
I think we probably have to drop this
On 11/20/2009 08:50 AM, Ehud Gavron wrote:
How does WL do it? Broadcom *has* to generate a MAC address that is
both unique and in its assigned range. If we can do the same thing in
B43 that would be ideal.
They are memory mapping a file in /etc/wlan. How this file is generated is not
known.
Larry Finger wrote:
On 11/20/2009 05:12 AM, Michael Buesch wrote:
This patch adds a generic mechanism for overriding the SPROM mechanism
on devices without SPROM hardware.
There currently is a major problem with this:
It tries to deduce a MAC address from various hardware parameters.
On 11/20/2009 04:36 PM, Bartłomiej Ochman wrote:
Oncaphillis wrote:
At least on my Acer One D250 dmidecode provides a mainboard
UUID.
Who's the vendor of ethernet chip in this acer? Broadcom too?
lspci tells me its broadcom
See the lspci under
http://oncaphillis.net/lspci-aspire-d250.txt
unsubscribe me please
From: Michael Buesch m...@bu3sch.de
To: Larry Finger larry.fin...@lwfinger.net
Cc: linux-wirel...@vger.kernel.org; bcm43xx-dev@lists.berlios.de
Sent: Thu, November 19, 2009 3:13:33 PM
Subject: Re: [PATCH] ssb: Unconditionally log results
On Fri, 20 Nov 2009 06:43:05 -0600
Larry Finger larry.fin...@lwfinger.net wrote:
One last check. I would appreciate receiving answers to the following
questions. These questions apply to anyone else with this problem.
Does the pm_qos patch help your fatal DMA error problem,
particularly when
On 20/11/09 10:54, Michael Buesch wrote:
Can somebody give me a genuine SPROM image for an LP-PHY card, please?
Just do this:
sudo cat $(find /sys/devices -name ssb_sprom) ssb_sprom_copy
Does this help?
Andy
ssb_sprom_copy
Description: Binary data
21 matches
Mail list logo
