* Trouble using bcm4318 compact flash with b43 driver
@ 2011-01-14 17:21 dylan cristiani
2011-01-14 18:52 ` Larry Finger
0 siblings, 1 reply; 24+ messages in thread
From: dylan cristiani @ 2011-01-14 17:21 UTC (permalink / raw)
To: b43-dev
Hi folks, i'm using a compact flash module, based on broadcom bcm4318
chipset, together with b43 driver from kernel mainline, and i get 'some'
troubles trying to associate with APs; here follows 'uname' and
'dmesg' logs:
>uname -a
Linux nylux 2.6.36 #167 Thu Jan 06 00:37:29 CET 2011 armv5tel GNU/Linux
>dmesg
......
bus: 'ssb': registered
bus: 'pcmcia': add driver b43-pcmcia
bus: 'pcmcia': driver_probe_device: matched device 0.0 with driver
b43-pcmcia bus: 'pcmcia': really_probe: probing driver b43-pcmcia with
device 0.0
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243)
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor 0x4243)
ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243)
ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243)
ssb: chipcommon status is 0x0
device: 'ssb0:0': device_add
bus: 'ssb': add device ssb0:0
ssb: Sonics Silicon Backplane found on PCMCIA device pcmcia0.0
driver: '0.0': driver_bound: bound to device 'b43-pcmcia'
bus: 'pcmcia': really_probe: bound device 0.0 to driver b43-pcmcia
bus: 'ssb': add driver b43
bus: 'ssb': driver_probe_device: matched device ssb0:0 with driver b43
bus: 'ssb': really_probe: probing driver b43 with device ssb0:0
b43-phy0: Broadcom 4318 WLAN found (core revision 9)
b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8
device: 'phy0': device_add
ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
device: 'wlan0': device_add
driver: 'ssb0:0': driver_bound: bound to device 'b43'
bus: 'ssb': really_probe: bound device ssb0:0 to driver b43
Broadcom 43xx driver loaded [ Features: M, Firmware-ID: FW13 ]
rev= 9
b43 ssb0:0: firmware: requesting b43/ucode5.fw
device: 'ssb0:0': device_add
device: 'ssb0:0': device_unregister
b43 ssb0:0: firmware: requesting b43/pcm5.fw
device: 'ssb0:0': device_add
device: 'ssb0:0': device_unregister
b43 ssb0:0: firmware: requesting b43/b0g0initvals5.fw
device: 'ssb0:0': device_add
device: 'ssb0:0': device_unregister
b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
device: 'ssb0:0': device_add
device: 'ssb0:0': device_unregister
b43-phy0: Loading firmware version 4
b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
b43-phy0 debug: Chip initialized
b43-phy0 debug: PIO initialized
b43-phy0 debug: QoS enabled
device: 'hw_random': device_add
b43-phy0 debug: Wireless interface started
b43-phy0 debug: Adding Interface type 2
ieee80211 phy0: device no longer idle - scanning
ieee80211 phy0: device now idle
b43-phy0 debug: Removing Interface type 2
b43-phy0 debug: Wireless interface stopped
device: 'hw_random': device_unregister
device: 'hw_random': device_create_release
b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
b43-phy0 debug: Chip initialized
b43-phy0 debug: PIO initialized
b43-phy0 debug: QoS enabled
device: 'hw_random': device_add
b43-phy0 debug: Wireless interface started
b43-phy0 debug: Adding Interface type 2
ieee80211 phy0: device no longer idle - scanning
ieee80211 phy0: device now idle
ieee80211 phy0: device no longer idle - working
wlan0: authenticate with 00:15:70:e2:3c:a1 (try 1)
wlan0: authenticated
ieee80211 phy0: device now idle
ieee80211 phy0: device no longer idle - working
wlan0: associate with 00:15:70:e2:3c:a1 (try 1)
wlan0: RX AssocResp from 00:15:70:e2:3c:a1 (capab=0x411 status=0 aid=3)
wlan0: associated
ieee80211 phy0: Allocated STA 00:15:70:e2:3c:a1
ieee80211 phy0: Inserted STA 00:15:70:e2:3c:a1
cfg80211: Calling CRDA for country: IT
b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac:
00:15:70:e2:3c:a1 b43-phy0 debug: Using hardware based encryption for
keyidx: 1, mac: ff:ff:ff:ff:ff:ff
wlan0: detected beacon loss from AP - sending probe request
ieee80211 phy0: wlan0: No probe response from AP 00:15:70:e2:3c:a1
after 500ms, try 1 ieee80211 phy0: wlan0: No probe response from AP
00:15:70:e2:3c:a1 after 500ms, try 2
ieee80211 phy0: wlan0: No probe response from AP 00:15:70:e2:3c:a1
after 500ms, try 3 ieee80211 phy0: wlan0: No probe response from AP
00:15:70:e2:3c:a1 after 500ms, try 4
ieee80211 phy0: wlan0: No probe response from AP 00:15:70:e2:3c:a1
after 500ms, disconnecting. b43-phy0 debug: Disabling hardware based
encryption for keyidx: 0, mac: 00:15:70:e2:3c:a1
ieee80211 phy0: Removed STA 00:15:70:e2:3c:a1
ieee80211 phy0: Destroyed STA 00:15:70:e2:3c:a1
ieee80211 phy0: device now idle
b43-phy0 debug: Disabling hardware based encryption for keyidx: 1,
mac: ff:ff:ff:ff:ff:ff cfg80211: All devices are disconnected, going
to restore regulatory settings
cfg80211: Restoring regulatory settings
cfg80211: Calling CRDA to update world regulatory domain
ieee80211 phy0: device no longer idle - scanning
ieee80211 phy0: device now idle
Note that same stuff happens also with kernel 2.6.37, and same with old
firmware version 410.2160 (2007-05-26 15:32:10) cutted from
http://mirror2.openwrt.org/sources/broadcom-wl-4.150.10.5.tar.bz2
while other firmware (version 478.104 (2008-07-01 00:50:23)) was from
http://downloads.openwrt.org/sources/broadcom-wl-4.178.10.4.tar.bz2
Any help will be very very very appreciated
tks
dylan
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-01-14 17:21 Trouble using bcm4318 compact flash with b43 driver dylan cristiani
@ 2011-01-14 18:52 ` Larry Finger
2011-01-15 7:05 ` Dylan Cristiani
0 siblings, 1 reply; 24+ messages in thread
From: Larry Finger @ 2011-01-14 18:52 UTC (permalink / raw)
To: b43-dev
On 01/14/2011 11:21 AM, dylan cristiani wrote:
> Hi folks, i'm using a compact flash module, based on broadcom bcm4318
> chipset, together with b43 driver from kernel mainline, and i get 'some'
> troubles trying to associate with APs; here follows 'uname' and
> 'dmesg' logs:
>
>> uname -a
> Linux nylux 2.6.36 #167 Thu Jan 06 00:37:29 CET 2011 armv5tel GNU/Linux
>
>> dmesg
> ......
> bus: 'ssb': registered
> bus: 'pcmcia': add driver b43-pcmcia
> bus: 'pcmcia': driver_probe_device: matched device 0.0 with driver
> b43-pcmcia bus: 'pcmcia': really_probe: probing driver b43-pcmcia with
> device 0.0
> ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243)
> ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor 0x4243)
> ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243)
> ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243)
> ssb: chipcommon status is 0x0
> device: 'ssb0:0': device_add
> bus: 'ssb': add device ssb0:0
> ssb: Sonics Silicon Backplane found on PCMCIA device pcmcia0.0
> driver: '0.0': driver_bound: bound to device 'b43-pcmcia'
> bus: 'pcmcia': really_probe: bound device 0.0 to driver b43-pcmcia
> bus: 'ssb': add driver b43
> bus: 'ssb': driver_probe_device: matched device ssb0:0 with driver b43
> bus: 'ssb': really_probe: probing driver b43 with device ssb0:0
> b43-phy0: Broadcom 4318 WLAN found (core revision 9)
> b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7
> b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8
> device: 'phy0': device_add
> ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> device: 'wlan0': device_add
> driver: 'ssb0:0': driver_bound: bound to device 'b43'
> bus: 'ssb': really_probe: bound device ssb0:0 to driver b43
> Broadcom 43xx driver loaded [ Features: M, Firmware-ID: FW13 ]
> rev= 9
> b43 ssb0:0: firmware: requesting b43/ucode5.fw
> device: 'ssb0:0': device_add
> device: 'ssb0:0': device_unregister
> b43 ssb0:0: firmware: requesting b43/pcm5.fw
> device: 'ssb0:0': device_add
> device: 'ssb0:0': device_unregister
> b43 ssb0:0: firmware: requesting b43/b0g0initvals5.fw
> device: 'ssb0:0': device_add
> device: 'ssb0:0': device_unregister
> b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
> device: 'ssb0:0': device_add
> device: 'ssb0:0': device_unregister
> b43-phy0: Loading firmware version 4
> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
> b43-phy0 debug: Chip initialized
> b43-phy0 debug: PIO initialized
> b43-phy0 debug: QoS enabled
> device: 'hw_random': device_add
> b43-phy0 debug: Wireless interface started
> b43-phy0 debug: Adding Interface type 2
> ieee80211 phy0: device no longer idle - scanning
> ieee80211 phy0: device now idle
> b43-phy0 debug: Removing Interface type 2
> b43-phy0 debug: Wireless interface stopped
> device: 'hw_random': device_unregister
> device: 'hw_random': device_create_release
> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
> b43-phy0 debug: Chip initialized
> b43-phy0 debug: PIO initialized
> b43-phy0 debug: QoS enabled
> device: 'hw_random': device_add
> b43-phy0 debug: Wireless interface started
> b43-phy0 debug: Adding Interface type 2
> ieee80211 phy0: device no longer idle - scanning
> ieee80211 phy0: device now idle
> ieee80211 phy0: device no longer idle - working
> wlan0: authenticate with 00:15:70:e2:3c:a1 (try 1)
> wlan0: authenticated
> ieee80211 phy0: device now idle
> ieee80211 phy0: device no longer idle - working
> wlan0: associate with 00:15:70:e2:3c:a1 (try 1)
> wlan0: RX AssocResp from 00:15:70:e2:3c:a1 (capab=0x411 status=0 aid=3)
> wlan0: associated
> ieee80211 phy0: Allocated STA 00:15:70:e2:3c:a1
> ieee80211 phy0: Inserted STA 00:15:70:e2:3c:a1
> cfg80211: Calling CRDA for country: IT
> b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac:
> 00:15:70:e2:3c:a1 b43-phy0 debug: Using hardware based encryption for
> keyidx: 1, mac: ff:ff:ff:ff:ff:ff
Does /var/log/messages indicate how long a time elapsed between the keyidx
message above, and the beacon loss below? \
> wlan0: detected beacon loss from AP - sending probe request
> ieee80211 phy0: wlan0: No probe response from AP 00:15:70:e2:3c:a1
> after 500ms, try 1 ieee80211 phy0: wlan0: No probe response from AP
> 00:15:70:e2:3c:a1 after 500ms, try 2
> ieee80211 phy0: wlan0: No probe response from AP 00:15:70:e2:3c:a1
> after 500ms, try 3 ieee80211 phy0: wlan0: No probe response from AP
> 00:15:70:e2:3c:a1 after 500ms, try 4
> ieee80211 phy0: wlan0: No probe response from AP 00:15:70:e2:3c:a1
> after 500ms, disconnecting. b43-phy0 debug: Disabling hardware based
> encryption for keyidx: 0, mac: 00:15:70:e2:3c:a1
> ieee80211 phy0: Removed STA 00:15:70:e2:3c:a1
> ieee80211 phy0: Destroyed STA 00:15:70:e2:3c:a1
> ieee80211 phy0: device now idle
> b43-phy0 debug: Disabling hardware based encryption for keyidx: 1,
> mac: ff:ff:ff:ff:ff:ff cfg80211: All devices are disconnected, going
> to restore regulatory settings
> cfg80211: Restoring regulatory settings
> cfg80211: Calling CRDA to update world regulatory domain
> ieee80211 phy0: device no longer idle - scanning
> ieee80211 phy0: device now idle
>
> Note that same stuff happens also with kernel 2.6.37, and same with old
> firmware version 410.2160 (2007-05-26 15:32:10) cutted from
> http://mirror2.openwrt.org/sources/broadcom-wl-4.150.10.5.tar.bz2
>
> while other firmware (version 478.104 (2008-07-01 00:50:23)) was from
> http://downloads.openwrt.org/sources/broadcom-wl-4.178.10.4.tar.bz2
>
> Any help will be very very very appreciated
At this point, I have no idea why the interface authenticated and associated,
then suddenly stopped receiving beacons. If necessary, could you set up another
box with wireshark to capture the traffic to/from the 4318?
Larry
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-01-14 18:52 ` Larry Finger
@ 2011-01-15 7:05 ` Dylan Cristiani
2011-01-15 16:38 ` Larry Finger
0 siblings, 1 reply; 24+ messages in thread
From: Dylan Cristiani @ 2011-01-15 7:05 UTC (permalink / raw)
To: b43-dev
On Fri, 14 Jan 2011 12:52:35 -0600
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 01/14/2011 11:21 AM, dylan cristiani wrote:
> > Hi folks, i'm using a compact flash module, based on broadcom
> > bcm4318 chipset, together with b43 driver from kernel mainline, and
> > i get 'some' troubles trying to associate with APs; here follows
> > 'uname' and 'dmesg' logs:
> >
> >> uname -a
> > Linux nylux 2.6.36 #167 Thu Jan 06 00:37:29 CET 2011 armv5tel
> > GNU/Linux
> >
> >> dmesg
> > ......
> > bus: 'ssb': registered
> > bus: 'pcmcia': add driver b43-pcmcia
> > bus: 'pcmcia': driver_probe_device: matched device 0.0 with driver
> > b43-pcmcia bus: 'pcmcia': really_probe: probing driver b43-pcmcia
> > with device 0.0
> > ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243)
> > ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor 0x4243)
> > ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243)
> > ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243)
> > ssb: chipcommon status is 0x0
> > device: 'ssb0:0': device_add
> > bus: 'ssb': add device ssb0:0
> > ssb: Sonics Silicon Backplane found on PCMCIA device pcmcia0.0
> > driver: '0.0': driver_bound: bound to device 'b43-pcmcia'
> > bus: 'pcmcia': really_probe: bound device 0.0 to driver b43-pcmcia
> > bus: 'ssb': add driver b43
> > bus: 'ssb': driver_probe_device: matched device ssb0:0 with driver
> > b43 bus: 'ssb': really_probe: probing driver b43 with device ssb0:0
> > b43-phy0: Broadcom 4318 WLAN found (core revision 9)
> > b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7
> > b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision
> > 8 device: 'phy0': device_add
> > ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> > device: 'wlan0': device_add
> > driver: 'ssb0:0': driver_bound: bound to device 'b43'
> > bus: 'ssb': really_probe: bound device ssb0:0 to driver b43
> > Broadcom 43xx driver loaded [ Features: M, Firmware-ID: FW13 ]
> > rev= 9
> > b43 ssb0:0: firmware: requesting b43/ucode5.fw
> > device: 'ssb0:0': device_add
> > device: 'ssb0:0': device_unregister
> > b43 ssb0:0: firmware: requesting b43/pcm5.fw
> > device: 'ssb0:0': device_add
> > device: 'ssb0:0': device_unregister
> > b43 ssb0:0: firmware: requesting b43/b0g0initvals5.fw
> > device: 'ssb0:0': device_add
> > device: 'ssb0:0': device_unregister
> > b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
> > device: 'ssb0:0': device_add
> > device: 'ssb0:0': device_unregister
> > b43-phy0: Loading firmware version 4
> > b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
> > b43-phy0 debug: Chip initialized
> > b43-phy0 debug: PIO initialized
> > b43-phy0 debug: QoS enabled
> > device: 'hw_random': device_add
> > b43-phy0 debug: Wireless interface started
> > b43-phy0 debug: Adding Interface type 2
> > ieee80211 phy0: device no longer idle - scanning
> > ieee80211 phy0: device now idle
> > b43-phy0 debug: Removing Interface type 2
> > b43-phy0 debug: Wireless interface stopped
> > device: 'hw_random': device_unregister
> > device: 'hw_random': device_create_release
> > b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
> > b43-phy0 debug: Chip initialized
> > b43-phy0 debug: PIO initialized
> > b43-phy0 debug: QoS enabled
> > device: 'hw_random': device_add
> > b43-phy0 debug: Wireless interface started
> > b43-phy0 debug: Adding Interface type 2
> > ieee80211 phy0: device no longer idle - scanning
> > ieee80211 phy0: device now idle
> > ieee80211 phy0: device no longer idle - working
> > wlan0: authenticate with 00:15:70:e2:3c:a1 (try 1)
> > wlan0: authenticated
> > ieee80211 phy0: device now idle
> > ieee80211 phy0: device no longer idle - working
> > wlan0: associate with 00:15:70:e2:3c:a1 (try 1)
> > wlan0: RX AssocResp from 00:15:70:e2:3c:a1 (capab=0x411 status=0
> > aid=3) wlan0: associated
> > ieee80211 phy0: Allocated STA 00:15:70:e2:3c:a1
> > ieee80211 phy0: Inserted STA 00:15:70:e2:3c:a1
> > cfg80211: Calling CRDA for country: IT
> > b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac:
> > 00:15:70:e2:3c:a1 b43-phy0 debug: Using hardware based encryption
> > for keyidx: 1, mac: ff:ff:ff:ff:ff:ff
>
> Does /var/log/messages indicate how long a time elapsed between the
> keyidx message above, and the beacon loss below? \
i'll try to set the kernel option timestamp to se elapsed time but
as far as i can 'count' by my self it's very short time!
>
> > wlan0: detected beacon loss from AP - sending probe request
> > ieee80211 phy0: wlan0: No probe response from AP 00:15:70:e2:3c:a1
> > after 500ms, try 1 ieee80211 phy0: wlan0: No probe response from AP
> > 00:15:70:e2:3c:a1 after 500ms, try 2
> > ieee80211 phy0: wlan0: No probe response from AP 00:15:70:e2:3c:a1
> > after 500ms, try 3 ieee80211 phy0: wlan0: No probe response from AP
> > 00:15:70:e2:3c:a1 after 500ms, try 4
> > ieee80211 phy0: wlan0: No probe response from AP 00:15:70:e2:3c:a1
> > after 500ms, disconnecting. b43-phy0 debug: Disabling hardware
> > based encryption for keyidx: 0, mac: 00:15:70:e2:3c:a1
> > ieee80211 phy0: Removed STA 00:15:70:e2:3c:a1
> > ieee80211 phy0: Destroyed STA 00:15:70:e2:3c:a1
> > ieee80211 phy0: device now idle
> > b43-phy0 debug: Disabling hardware based encryption for keyidx: 1,
> > mac: ff:ff:ff:ff:ff:ff cfg80211: All devices are disconnected,
> > going to restore regulatory settings
> > cfg80211: Restoring regulatory settings
> > cfg80211: Calling CRDA to update world regulatory domain
> > ieee80211 phy0: device no longer idle - scanning
> > ieee80211 phy0: device now idle
> >
> > Note that same stuff happens also with kernel 2.6.37, and same with
> > old firmware version 410.2160 (2007-05-26 15:32:10) cutted from
> > http://mirror2.openwrt.org/sources/broadcom-wl-4.150.10.5.tar.bz2
> >
> > while other firmware (version 478.104 (2008-07-01 00:50:23)) was
> > from
> > http://downloads.openwrt.org/sources/broadcom-wl-4.178.10.4.tar.bz2
> >
> > Any help will be very very very appreciated
>
> At this point, I have no idea why the interface authenticated and
> associated, then suddenly stopped receiving beacons. If necessary,
> could you set up another box with wireshark to capture the traffic
> to/from the 4318?
it will be hard i must try to find some sniffer somewhere
>
> Larry
for now tks larry!
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-01-15 7:05 ` Dylan Cristiani
@ 2011-01-15 16:38 ` Larry Finger
2011-01-17 10:06 ` dylan cristiani
0 siblings, 1 reply; 24+ messages in thread
From: Larry Finger @ 2011-01-15 16:38 UTC (permalink / raw)
To: b43-dev
On 01/15/2011 01:05 AM, Dylan Cristiani wrote:
> it will be hard i must try to find some sniffer somewhere
>>
>> Larry
> for now tks larry!
One other thing. Before you try to make the connection, start the command 'iw
event -t -f' in another terminal to see what events are happening.
Larry
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-01-15 16:38 ` Larry Finger
@ 2011-01-17 10:06 ` dylan cristiani
2011-01-17 13:51 ` dylan cristiani
0 siblings, 1 reply; 24+ messages in thread
From: dylan cristiani @ 2011-01-17 10:06 UTC (permalink / raw)
To: b43-dev
On Sat, 15 Jan 2011 10:38:59 -0600
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 01/15/2011 01:05 AM, Dylan Cristiani wrote:
> > it will be hard i must try to find some sniffer somewhere
> >>
> >> Larry
> > for now tks larry!
>
> One other thing. Before you try to make the connection, start the
> command 'iw event -t -f' in another terminal to see what events are
> happening.
>
> Larry
here comes the 'iw event -t -f' log:
nylux:~ #iw event -t -f
1229947332.952454: wlan0 (phy #0): scan started
1229947334.360008: wlan0 (phy #0): scan finished: 2412 2417 2422 2427
2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, "bancoliniaes"
1229947334.406591: wlan0 (phy #0): auth 00:15:70:e2:3c:a1 ->
14:0b:6b:1e:3e:86 status: 0: Successful [frame: b0 08 40 01 14 0b 6b 1e
3e 86 00 15 70 e2 3c a1 00 15 70 e2 3c a1 80 7d 00 00 02 00 00 00]
1229947334.417716: wlan0: new station 00:15:70:e2:3c:a1
1229947334.430558: wlan0 (phy #0): assoc 00:15:70:e2:3c:a1 ->
14:0b:6b:1e:3e:86 status: 0: Successful [frame: 10 00 40 01 14 0b 6b 1e
3e 86 00 15 70 e2 3c a1 00 15 70 e2 3c a1 90 7d 11 04 00 00 01 c0 01 08
82 84 8b 0c 12 96 18 24 32 05 24 30 48 60 6c]
1229947334.431352: wlan0 (phy #0): connected to 00:15:70:e2:3c:a1
1229947340.620737: wlan0 (phy #0): deauth 14:0b:6b:1e:3e:86 ->
00:15:70:e2:3c:a1 reason 4: Disassociated due to inactivity [frame: c0
00 00 00 00 15 70 e2 3c a1 14 0b 6b 1e 3e 86 00 15 70 e2 3c a1 00 00 04
00]
1229947340.621700: wlan0 (phy #0): disconnected (local request)
1229947340.740407: wlan0 (phy #0): scan started
1229947342.169816: wlan0 (phy #0): scan finished: 2412 2417 2422 2427
2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1229947342.791016: wlan0 (phy #0): auth: timed out
1229947342.791700: wlan0 (phy #0): failed to connect to
00:15:70:e2:3c:a1, status: 1: Unspecified failure
1229947352.221068: wlan0 (phy #0): scan started
1229947353.654043: wlan0 (phy #0): scan finished: 2412 2417 2422 2427
2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, "bancoliniaes"
1229947358.680398: wlan0 (phy #0): scan started
1229947360.110101: wlan0 (phy #0): scan finished: 2412 2417 2422 2427
2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1229947365.130440: wlan0 (phy #0): scan started
1229947366.559799: wlan0 (phy #0): scan finished: 2412 2417 2422 2427
2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, "bancoliniaes"
As you can see the module get associated to AP whose ssid is
"bancoliniaes", get connected but few time after it disassociates:
'reason 4: Disassociated due to inactivity' i dunno why is this
happening...
after this i cutted the log because it loops forever between 'scan
started' and 'scan finished' without any more association between the
module and the AP! i hope this logs can tell you something to help me.
for now tks
dylan
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-01-17 10:06 ` dylan cristiani
@ 2011-01-17 13:51 ` dylan cristiani
2011-01-18 10:58 ` dylan cristiani
0 siblings, 1 reply; 24+ messages in thread
From: dylan cristiani @ 2011-01-17 13:51 UTC (permalink / raw)
To: b43-dev
On Mon, 17 Jan 2011 11:06:18 +0100
dylan cristiani <d.cristiani@idem-tech.it> wrote:
> On Sat, 15 Jan 2011 10:38:59 -0600
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
> > On 01/15/2011 01:05 AM, Dylan Cristiani wrote:
> > > it will be hard i must try to find some sniffer somewhere
> > >>
> > >> Larry
> > > for now tks larry!
> >
> > One other thing. Before you try to make the connection, start the
> > command 'iw event -t -f' in another terminal to see what events are
> > happening.
> >
> > Larry
> here comes the 'iw event -t -f' log:
>
> nylux:~ #iw event -t -f
> 1229947332.952454: wlan0 (phy #0): scan started
> 1229947334.360008: wlan0 (phy #0): scan finished: 2412 2417 2422 2427
> 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, "bancoliniaes"
> 1229947334.406591: wlan0 (phy #0): auth 00:15:70:e2:3c:a1 ->
> 14:0b:6b:1e:3e:86 status: 0: Successful [frame: b0 08 40 01 14 0b 6b
> 1e 3e 86 00 15 70 e2 3c a1 00 15 70 e2 3c a1 80 7d 00 00 02 00 00 00]
> 1229947334.417716: wlan0: new station 00:15:70:e2:3c:a1
> 1229947334.430558: wlan0 (phy #0): assoc 00:15:70:e2:3c:a1 ->
> 14:0b:6b:1e:3e:86 status: 0: Successful [frame: 10 00 40 01 14 0b 6b
> 1e 3e 86 00 15 70 e2 3c a1 00 15 70 e2 3c a1 90 7d 11 04 00 00 01 c0
> 01 08 82 84 8b 0c 12 96 18 24 32 05 24 30 48 60 6c]
> 1229947334.431352: wlan0 (phy #0): connected to 00:15:70:e2:3c:a1
> 1229947340.620737: wlan0 (phy #0): deauth 14:0b:6b:1e:3e:86 ->
> 00:15:70:e2:3c:a1 reason 4: Disassociated due to inactivity [frame: c0
> 00 00 00 00 15 70 e2 3c a1 14 0b 6b 1e 3e 86 00 15 70 e2 3c a1 00 00
> 04 00]
> 1229947340.621700: wlan0 (phy #0): disconnected (local request)
> 1229947340.740407: wlan0 (phy #0): scan started
> 1229947342.169816: wlan0 (phy #0): scan finished: 2412 2417 2422 2427
> 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
> 1229947342.791016: wlan0 (phy #0): auth: timed out
> 1229947342.791700: wlan0 (phy #0): failed to connect to
> 00:15:70:e2:3c:a1, status: 1: Unspecified failure
> 1229947352.221068: wlan0 (phy #0): scan started
> 1229947353.654043: wlan0 (phy #0): scan finished: 2412 2417 2422 2427
> 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, "bancoliniaes"
> 1229947358.680398: wlan0 (phy #0): scan started
> 1229947360.110101: wlan0 (phy #0): scan finished: 2412 2417 2422 2427
> 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
> 1229947365.130440: wlan0 (phy #0): scan started
> 1229947366.559799: wlan0 (phy #0): scan finished: 2412 2417 2422 2427
> 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, "bancoliniaes"
>
>
> As you can see the module get associated to AP whose ssid is
> "bancoliniaes", get connected but few time after it disassociates:
> 'reason 4: Disassociated due to inactivity' i dunno why is this
> happening...
> after this i cutted the log because it loops forever between 'scan
> started' and 'scan finished' without any more association between the
> module and the AP! i hope this logs can tell you something to help me.
> for now tks
PS for sure, AP side, there are no rules, nor blacklists, nor filters
nor timer to disconnect anyone from the net!
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-01-17 13:51 ` dylan cristiani
@ 2011-01-18 10:58 ` dylan cristiani
2011-01-18 14:34 ` Larry Finger
0 siblings, 1 reply; 24+ messages in thread
From: dylan cristiani @ 2011-01-18 10:58 UTC (permalink / raw)
To: b43-dev
On Mon, 17 Jan 2011 14:51:06 +0100
dylan cristiani <d.cristiani@idem-tech.it> wrote:
...snipped
> here comes the 'iw event -t -f' log:
>
> nylux:~ #iw event -t -f
> 1229947332.952454: wlan0 (phy #0): scan started
> 1229947334.360008: wlan0 (phy #0): scan finished: 2412 2417 2422 2427
> 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, "bancoliniaes"
> 1229947334.406591: wlan0 (phy #0): auth 00:15:70:e2:3c:a1 ->
> 14:0b:6b:1e:3e:86 status: 0: Successful [frame: b0 08 40 01 14 0b 6b
> 1e 3e 86 00 15 70 e2 3c a1 00 15 70 e2 3c a1 80 7d 00 00 02 00 00 00]
> 1229947334.417716: wlan0: new station 00:15:70:e2:3c:a1
> 1229947334.430558: wlan0 (phy #0): assoc 00:15:70:e2:3c:a1 ->
> 14:0b:6b:1e:3e:86 status: 0: Successful [frame: 10 00 40 01 14 0b 6b
> 1e 3e 86 00 15 70 e2 3c a1 00 15 70 e2 3c a1 90 7d 11 04 00 00 01 c0
> 01 08 82 84 8b 0c 12 96 18 24 32 05 24 30 48 60 6c]
> 1229947334.431352: wlan0 (phy #0): connected to 00:15:70:e2:3c:a1
> 1229947340.620737: wlan0 (phy #0): deauth 14:0b:6b:1e:3e:86 ->
> 00:15:70:e2:3c:a1 reason 4: Disassociated due to inactivity [frame: c0
> 00 00 00 00 15 70 e2 3c a1 14 0b 6b 1e 3e 86 00 15 70 e2 3c a1 00 00
> 04 00]
> 1229947340.621700: wlan0 (phy #0): disconnected (local request)
> 1229947340.740407: wlan0 (phy #0): scan started
> 1229947342.169816: wlan0 (phy #0): scan finished: 2412 2417 2422 2427
> 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
> 1229947342.791016: wlan0 (phy #0): auth: timed out
> 1229947342.791700: wlan0 (phy #0): failed to connect to
> 00:15:70:e2:3c:a1, status: 1: Unspecified failure
> 1229947352.221068: wlan0 (phy #0): scan started
> 1229947353.654043: wlan0 (phy #0): scan finished: 2412 2417 2422 2427
> 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, "bancoliniaes"
> 1229947358.680398: wlan0 (phy #0): scan started
> 1229947360.110101: wlan0 (phy #0): scan finished: 2412 2417 2422 2427
> 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
> 1229947365.130440: wlan0 (phy #0): scan started
> 1229947366.559799: wlan0 (phy #0): scan finished: 2412 2417 2422 2427
> 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, "bancoliniaes"
>
>
> As you can see the module get associated to AP whose ssid is
> "bancoliniaes", get connected but few time after it disassociates:
> 'reason 4: Disassociated due to inactivity' i dunno why is this
> happening...
> after this i cutted the log because it loops forever between 'scan
> started' and 'scan finished' without any more association between the
> module and the AP! i hope this logs can tell you something to help me.
> for now tks
Hi Larry i've some news: i tryied with kernel 2.6.35 and it works!
the module associates to AP and i can browse the net, ping external
addresses and so on...; it seems that some drivers' changes made things
go worste for my 'platform': do you have any suggestions?
Note that all kernel settings are the same in 2.6.35, 2.6.36 and 2.6.37
except, obviously, for the new kernel's parameters of the latter two.
dylan
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-01-18 10:58 ` dylan cristiani
@ 2011-01-18 14:34 ` Larry Finger
2011-01-19 13:03 ` dylan cristiani
0 siblings, 1 reply; 24+ messages in thread
From: Larry Finger @ 2011-01-18 14:34 UTC (permalink / raw)
To: b43-dev
On 01/18/2011 04:58 AM, dylan cristiani wrote:
> On Mon, 17 Jan 2011 14:51:06 +0100
> dylan cristiani <d.cristiani@idem-tech.it> wrote:
>
> ...snipped
>> here comes the 'iw event -t -f' log:
>>
>> nylux:~ #iw event -t -f
>> 1229947332.952454: wlan0 (phy #0): scan started
>> 1229947334.360008: wlan0 (phy #0): scan finished: 2412 2417 2422 2427
>> 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, "bancoliniaes"
>> 1229947334.406591: wlan0 (phy #0): auth 00:15:70:e2:3c:a1 ->
>> 14:0b:6b:1e:3e:86 status: 0: Successful [frame: b0 08 40 01 14 0b 6b
>> 1e 3e 86 00 15 70 e2 3c a1 00 15 70 e2 3c a1 80 7d 00 00 02 00 00 00]
>> 1229947334.417716: wlan0: new station 00:15:70:e2:3c:a1
>> 1229947334.430558: wlan0 (phy #0): assoc 00:15:70:e2:3c:a1 ->
>> 14:0b:6b:1e:3e:86 status: 0: Successful [frame: 10 00 40 01 14 0b 6b
>> 1e 3e 86 00 15 70 e2 3c a1 00 15 70 e2 3c a1 90 7d 11 04 00 00 01 c0
>> 01 08 82 84 8b 0c 12 96 18 24 32 05 24 30 48 60 6c]
>> 1229947334.431352: wlan0 (phy #0): connected to 00:15:70:e2:3c:a1
>> 1229947340.620737: wlan0 (phy #0): deauth 14:0b:6b:1e:3e:86 ->
>> 00:15:70:e2:3c:a1 reason 4: Disassociated due to inactivity [frame: c0
>> 00 00 00 00 15 70 e2 3c a1 14 0b 6b 1e 3e 86 00 15 70 e2 3c a1 00 00
>> 04 00]
>> 1229947340.621700: wlan0 (phy #0): disconnected (local request)
>> 1229947340.740407: wlan0 (phy #0): scan started
>> 1229947342.169816: wlan0 (phy #0): scan finished: 2412 2417 2422 2427
>> 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
>> 1229947342.791016: wlan0 (phy #0): auth: timed out
>> 1229947342.791700: wlan0 (phy #0): failed to connect to
>> 00:15:70:e2:3c:a1, status: 1: Unspecified failure
>> 1229947352.221068: wlan0 (phy #0): scan started
>> 1229947353.654043: wlan0 (phy #0): scan finished: 2412 2417 2422 2427
>> 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, "bancoliniaes"
>> 1229947358.680398: wlan0 (phy #0): scan started
>> 1229947360.110101: wlan0 (phy #0): scan finished: 2412 2417 2422 2427
>> 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
>> 1229947365.130440: wlan0 (phy #0): scan started
>> 1229947366.559799: wlan0 (phy #0): scan finished: 2412 2417 2422 2427
>> 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, "bancoliniaes"
>>
>>
>> As you can see the module get associated to AP whose ssid is
>> "bancoliniaes", get connected but few time after it disassociates:
>> 'reason 4: Disassociated due to inactivity' i dunno why is this
>> happening...
>> after this i cutted the log because it loops forever between 'scan
>> started' and 'scan finished' without any more association between the
>> module and the AP! i hope this logs can tell you something to help me.
>> for now tks
> Hi Larry i've some news: i tryied with kernel 2.6.35 and it works!
> the module associates to AP and i can browse the net, ping external
> addresses and so on...; it seems that some drivers' changes made things
> go worste for my 'platform': do you have any suggestions?
> Note that all kernel settings are the same in 2.6.35, 2.6.36 and 2.6.37
> except, obviously, for the new kernel's parameters of the latter two.
The usual advice offered in cases like yours is to install a git tree and bisect
the issue. As you have a problem with mainline kernels, I definitely recommend
the linux-2.6.git tree as it bisects better than development trees like
wireless-testing.git. Your number of trials should not be too bad as you know it
broke between 2.6.35 and 2.6.36.
Larry
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-01-18 14:34 ` Larry Finger
@ 2011-01-19 13:03 ` dylan cristiani
2011-01-21 15:51 ` Dylan Cristiani
0 siblings, 1 reply; 24+ messages in thread
From: dylan cristiani @ 2011-01-19 13:03 UTC (permalink / raw)
To: b43-dev
On Tue, 18 Jan 2011 08:34:46 -0600
Larry Finger <Larry.Finger@lwfinger.net> wrote:
.....
> > Hi Larry i've some news: i tryied with kernel 2.6.35 and it works!
> > the module associates to AP and i can browse the net, ping external
> > addresses and so on...; it seems that some drivers' changes made
> > things go worste for my 'platform': do you have any suggestions?
> > Note that all kernel settings are the same in 2.6.35, 2.6.36 and
> > 2.6.37 except, obviously, for the new kernel's parameters of the
> > latter two.
>
> The usual advice offered in cases like yours is to install a git tree
> and bisect the issue. As you have a problem with mainline kernels, I
> definitely recommend the linux-2.6.git tree as it bisects better than
> development trees like wireless-testing.git. Your number of trials
> should not be too bad as you know it broke between 2.6.35 and 2.6.36.
>
> Larry
Tks for hint, but today i had a brand new behaviour: before diving into
git, i tryed to add som debug printk into ssb backplane to see if there
were some difference between 2.6.35 and 2.6.36, and the magic is that
the module worked also with 2.6.36 kernel; for sure i don't really think
that my few printk made the miracle; the only difference was that i
manually made 'insmod' of ssb.ko and b43.ko, then i 'ifdown wlan0' then
'ifup wlan0' and it worked...; as it seems to me there must be some alea
somewhere, that in certain conditions makes the module to misbehave
and the AP forbids to associate to it; but i cannot get the point also
for the fact that if a restore the starting buggy situation ('insmod' is
performed by a script launched by inittat just after init), the 'race'
situation doesn't happen anymore (for now), and the wlan0 still keep
working: don't know where to hit my head......(desk already hitten!)
dylan (swimming in deep dark....)
--
eng. dylan cristiani
idem srl
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-01-19 13:03 ` dylan cristiani
@ 2011-01-21 15:51 ` Dylan Cristiani
2011-01-21 17:22 ` Larry Finger
0 siblings, 1 reply; 24+ messages in thread
From: Dylan Cristiani @ 2011-01-21 15:51 UTC (permalink / raw)
To: b43-dev
On Wed, 19 Jan 2011 14:03:28 +0100
dylan cristiani <d.cristiani@idem-tech.it> wrote:
> On Tue, 18 Jan 2011 08:34:46 -0600
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
> .....
> > > Hi Larry i've some news: i tryied with kernel 2.6.35 and it works!
> > > the module associates to AP and i can browse the net, ping
> > > external addresses and so on...; it seems that some drivers'
> > > changes made things go worste for my 'platform': do you have any
> > > suggestions? Note that all kernel settings are the same in
> > > 2.6.35, 2.6.36 and 2.6.37 except, obviously, for the new kernel's
> > > parameters of the latter two.
> >
> > The usual advice offered in cases like yours is to install a git
> > tree and bisect the issue. As you have a problem with mainline
> > kernels, I definitely recommend the linux-2.6.git tree as it
> > bisects better than development trees like wireless-testing.git.
> > Your number of trials should not be too bad as you know it broke
> > between 2.6.35 and 2.6.36.
> >
> > Larry
> Tks for hint, but today i had a brand new behaviour: before diving
> into git, i tryed to add som debug printk into ssb backplane to see
> if there were some difference between 2.6.35 and 2.6.36, and the
> magic is that the module worked also with 2.6.36 kernel; for sure i
> don't really think that my few printk made the miracle; the only
> difference was that i manually made 'insmod' of ssb.ko and b43.ko,
> then i 'ifdown wlan0' then 'ifup wlan0' and it worked...; as it seems
> to me there must be some alea somewhere, that in certain conditions
> makes the module to misbehave and the AP forbids to associate to it;
> but i cannot get the point also for the fact that if a restore the
> starting buggy situation ('insmod' is performed by a script launched
> by inittat just after init), the 'race' situation doesn't happen
> anymore (for now), and the wlan0 still keep working: don't know where
> to hit my head......(desk already hitten!)
>
> dylan (swimming in deep dark....)
>
probably i found a clue (maybe the point): when the b43 wlan interface
comes up its rate is, at the beginning, setted to the lowest possible:
1Mbit, as i can see with iwconfig, and it seems that, at this low rates,
some access points doesn't work, becuase of some handshake timeout
failure happening or other different timeouts issue, like they can't
'deal' with such communication being too slow; if i set higher rates
(i.e. 'iw set rate 24M') it associates to access point (WPA2
encryption), it gets dhcp address and it is possible to ping other net's
nodes, also if there are still some issue, like high percentage of
packet lost and so on; furthermore, trying to force setting of the rate
to highest possible 'iw set rate 54M', doesn't improve the performances
but, at the opposite, it leads again to association failures; is this a
normal behaviour? do you think that i'm doing something wrong? why is
the starting rate setted to 1M (it's a wlan module policy or a driver
choice?); which is the best way to solve this issue if any?
as usual thanks for you support and patience!!
dylan
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-01-21 15:51 ` Dylan Cristiani
@ 2011-01-21 17:22 ` Larry Finger
2011-01-21 21:54 ` Dylan Cristiani
0 siblings, 1 reply; 24+ messages in thread
From: Larry Finger @ 2011-01-21 17:22 UTC (permalink / raw)
To: b43-dev
On 01/21/2011 09:51 AM, Dylan Cristiani wrote:
> probably i found a clue (maybe the point): when the b43 wlan interface
> comes up its rate is, at the beginning, setted to the lowest possible:
> 1Mbit, as i can see with iwconfig, and it seems that, at this low rates,
> some access points doesn't work, becuase of some handshake timeout
> failure happening or other different timeouts issue, like they can't
> 'deal' with such communication being too slow; if i set higher rates
> (i.e. 'iw set rate 24M') it associates to access point (WPA2
> encryption), it gets dhcp address and it is possible to ping other net's
> nodes, also if there are still some issue, like high percentage of
> packet lost and so on; furthermore, trying to force setting of the rate
> to highest possible 'iw set rate 54M', doesn't improve the performances
> but, at the opposite, it leads again to association failures; is this a
> normal behaviour? do you think that i'm doing something wrong? why is
> the starting rate setted to 1M (it's a wlan module policy or a driver
> choice?); which is the best way to solve this issue if any?
>
> as usual thanks for you support and patience!!
Your finding may be a good clue, but I'm not sure how to interpret it. Any AP
must be able to handle traffic at 1 Mbps. Consider a station at an extreme
distance where rates no higher that 1M can be supported. In addition, all
management frames are sent at 1M to minimize the chances of packet loss.
You may have found a bug in the firmware of the AP, although that is not too
likely. What make and model is the AP and what firmware version is it using?
Fixing the transmission rate at too high a value will reduce throughput, just as
you see because of transmission errors. Any new connection always starts at 1M.
The rate-control algorithm will then increase the rate until the error rate
increases.
I think you must do the git bisection to find the kernel change that caused the
problem. I know that it is a lot of work, but at least you already know how to
compile a kernel.
Larry
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-01-21 17:22 ` Larry Finger
@ 2011-01-21 21:54 ` Dylan Cristiani
2011-01-21 22:13 ` Larry Finger
0 siblings, 1 reply; 24+ messages in thread
From: Dylan Cristiani @ 2011-01-21 21:54 UTC (permalink / raw)
To: b43-dev
On Fri, 21 Jan 2011 11:22:01 -0600
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 01/21/2011 09:51 AM, Dylan Cristiani wrote:
> > probably i found a clue (maybe the point): when the b43 wlan
> > interface comes up its rate is, at the beginning, setted to the
> > lowest possible: 1Mbit, as i can see with iwconfig, and it seems
> > that, at this low rates, some access points doesn't work, becuase
> > of some handshake timeout failure happening or other different
> > timeouts issue, like they can't 'deal' with such communication
> > being too slow; if i set higher rates (i.e. 'iw set rate 24M') it
> > associates to access point (WPA2 encryption), it gets dhcp address
> > and it is possible to ping other net's nodes, also if there are
> > still some issue, like high percentage of packet lost and so on;
> > furthermore, trying to force setting of the rate to highest
> > possible 'iw set rate 54M', doesn't improve the performances but,
> > at the opposite, it leads again to association failures; is this a
> > normal behaviour? do you think that i'm doing something wrong? why
> > is the starting rate setted to 1M (it's a wlan module policy or a
> > driver choice?); which is the best way to solve this issue if any?
> >
> > as usual thanks for you support and patience!!
>
> Your finding may be a good clue, but I'm not sure how to interpret
> it. Any AP must be able to handle traffic at 1 Mbps. Consider a
> station at an extreme distance where rates no higher that 1M can be
> supported. In addition, all management frames are sent at 1M to
> minimize the chances of packet loss.
ok so that's normal and sensible policy and for sure very reasonable in
fact maybe my question was little blind (near to stupid!)
>
> You may have found a bug in the firmware of the AP, although that is
> not too likely. What make and model is the AP and what firmware
> version is it using?
problems came up with motorola wireless switch RFS6000 and access
port650; but same problems with motorola ap7131 and less with ap5131
>
> Fixing the transmission rate at too high a value will reduce
> throughput, just as you see because of transmission errors. Any new
> connection always starts at 1M. The rate-control algorithm will then
> increase the rate until the error rate increases.
same as first point i was blind and hasty but you know when something
is not working, you change something and it works, then you revert it
but it still works it's not a good feeling, because you cannot target
the problem...
>
> I think you must do the git bisection to find the kernel change that
> caused the problem. I know that it is a lot of work, but at least you
> already know how to compile a kernel.
yes at least, other than bother community ;-), i know how to compile the
kernel i think i'm over thousand, only with 2.6.36 i reached more than
200 :-(; btw tks for you time, i'll bisect kernel but i'm not really
sure that it's a question of driver's problem, because as i told you
same kernel version sometimes works sometimes not.
dyl
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-01-21 21:54 ` Dylan Cristiani
@ 2011-01-21 22:13 ` Larry Finger
2011-01-22 10:48 ` Dylan Cristiani
0 siblings, 1 reply; 24+ messages in thread
From: Larry Finger @ 2011-01-21 22:13 UTC (permalink / raw)
To: b43-dev
On 01/21/2011 03:54 PM, Dylan Cristiani wrote:
> yes at least, other than bother community ;-), i know how to compile the
> kernel i think i'm over thousand, only with 2.6.36 i reached more than
> 200 :-(; btw tks for you time, i'll bisect kernel but i'm not really
> sure that it's a question of driver's problem, because as i told you
> same kernel version sometimes works sometimes not.
An intermittent problem makes bisection difficult. How many times to try before
calling a particular sample good? 10, 20??
As I understood the situation, 2.6.35 works all the time. Is that not so?
If you don't have any version that always works, then bisection is likely not
the answer. You will need to investigate what is on the air by using kismet or
wireshark on a separate computer.
Larry
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-01-21 22:13 ` Larry Finger
@ 2011-01-22 10:48 ` Dylan Cristiani
2011-02-01 14:41 ` dylan cristiani
0 siblings, 1 reply; 24+ messages in thread
From: Dylan Cristiani @ 2011-01-22 10:48 UTC (permalink / raw)
To: b43-dev
On Fri, 21 Jan 2011 16:13:33 -0600
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 01/21/2011 03:54 PM, Dylan Cristiani wrote:
> > yes at least, other than bother community ;-), i know how to
> > compile the kernel i think i'm over thousand, only with 2.6.36 i
> > reached more than 200 :-(; btw tks for you time, i'll bisect kernel
> > but i'm not really sure that it's a question of driver's problem,
> > because as i told you same kernel version sometimes works sometimes
> > not.
>
> An intermittent problem makes bisection difficult. How many times to
> try before calling a particular sample good? 10, 20??
>
> As I understood the situation, 2.6.35 works all the time. Is that not
> so?
with accesspoint i have (ap5131) 2.6.36 worked (seemed to) at the
beginning; other test by other people with different AP (wireless
switch RFS6000 + access port AP650) showed up the problem i initially
posted here: "not associating to access point or better associating then
de-associating for 'reason 4: Disassociated due to inactivity'"; then i
looked at Changelogs for 2.6.37 and i noticed that there were many
changes into cfg/mac80211 then i migrated to kernel 2.6.37; same as
before with my access point it worked while with wireless switch not;
(to be honest sometimes also to me happened associations problems but in
manner not 'deterministic' i.e. coming back to 2.6.36 (same situation
that worked early) it stopped work with same deassociation issue; so i
try to go back to 2.6.35 and it started to work again to me, so i gave
this version to people with wireless switch, but there it still not
worked, the module doesn't associate for some different inctivity
reasons like 'reason 2: Previous authentication no longer valid', if the
wireless switch's profile is open or 'Reason 15: is "4-Way Handshake
timeout"' if wpa2 is active; so i can really 'state' that (unlickly) i
saw one kernel working all the time neither by my side (with people
with wireless switch at the opposite no one kernel ever worked!)
>
> If you don't have any version that always works, then bisection is
> likely not the answer. You will need to investigate what is on the
> air by using kismet or wireshark on a separate computer.
i'll try with kismet or wireshark (keeping my finger crossed....,but
the fact that problems are intermittent make me feel bad....)
>
> Larry
tks again Larry!!
dylan
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-01-22 10:48 ` Dylan Cristiani
@ 2011-02-01 14:41 ` dylan cristiani
2011-02-01 20:40 ` Larry Finger
0 siblings, 1 reply; 24+ messages in thread
From: dylan cristiani @ 2011-02-01 14:41 UTC (permalink / raw)
To: b43-dev
On Sat, 22 Jan 2011 11:48:34 +0100
Dylan Cristiani <d.cristiani@idem-tech.it> wrote:
[snip]
> >
> > If you don't have any version that always works, then bisection is
> > likely not the answer. You will need to investigate what is on the
> > air by using kismet or wireshark on a separate computer.
> i'll try with kismet or wireshark (keeping my finger crossed....,but
> the fact that problems are intermittent make me feel bad....)
> >
> > Larry
> tks again Larry!!
>
i have some news: i went back to kernel version 2.6.26 and it worked
so i moved forward kernel by kernel and it works till kernel 2.6.32;
first kernel that shows up the problem is 2.6.33 and, at module loading
time i can see for the first time, after loading firmware, the following
debug info (don't know if it's helpful but same message happears in
every non-working kernel from 2.6.33 to 2.6.37):
"b43-phy0 warning: Invalid max-TX-power value in SPROM"
dylan
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-02-01 14:41 ` dylan cristiani
@ 2011-02-01 20:40 ` Larry Finger
2011-02-02 9:11 ` dylan cristiani
0 siblings, 1 reply; 24+ messages in thread
From: Larry Finger @ 2011-02-01 20:40 UTC (permalink / raw)
To: b43-dev
On 02/01/2011 08:41 AM, dylan cristiani wrote:
> i have some news: i went back to kernel version 2.6.26 and it worked
> so i moved forward kernel by kernel and it works till kernel 2.6.32;
> first kernel that shows up the problem is 2.6.33 and, at module loading
> time i can see for the first time, after loading firmware, the following
> debug info (don't know if it's helpful but same message happears in
> every non-working kernel from 2.6.33 to 2.6.37):
>
> "b43-phy0 warning: Invalid max-TX-power value in SPROM"
Between 2.6.32 and 2.6.33, there were only 6 patches that touched SSB. Two of
them (e33761e and 3ba6018) affected SPROM writing, one (37ace3d) was only for
PCMCIA, and one (ac2752c) only affected logging of a core scan. The two
remaining are 391ae22 that fixed an SDIO typo and 8b45499 that put host pointers
in a union should be the only ones that needed testing.
Those patches are attached. Try each of them in turn to 2.6.33 with a
'patch -p1 -R < patch_name' If it doesn't help, use the same command without the
"-R" to reapply. I'm guessing that 8b45499 is more likely to be the problem, and
I would try it first.
Larry
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch_391ae22
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110201/340c8ec1/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch_8b45499
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110201/340c8ec1/attachment-0001.ksh>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-02-01 20:40 ` Larry Finger
@ 2011-02-02 9:11 ` dylan cristiani
2011-02-02 11:55 ` dylan cristiani
0 siblings, 1 reply; 24+ messages in thread
From: dylan cristiani @ 2011-02-02 9:11 UTC (permalink / raw)
To: b43-dev
On Tue, 01 Feb 2011 14:40:32 -0600
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 02/01/2011 08:41 AM, dylan cristiani wrote:
> > i have some news: i went back to kernel version 2.6.26 and it worked
> > so i moved forward kernel by kernel and it works till kernel 2.6.32;
> > first kernel that shows up the problem is 2.6.33 and, at module
> > loading time i can see for the first time, after loading firmware,
> > the following debug info (don't know if it's helpful but same
> > message happears in every non-working kernel from 2.6.33 to 2.6.37):
> >
> > "b43-phy0 warning: Invalid max-TX-power value in SPROM"
>
> Between 2.6.32 and 2.6.33, there were only 6 patches that touched
> SSB. Two of them (e33761e and 3ba6018) affected SPROM writing, one
> (37ace3d) was only for PCMCIA, and one (ac2752c) only affected
> logging of a core scan. The two remaining are 391ae22 that fixed an
> SDIO typo and 8b45499 that put host pointers in a union should be the
> only ones that needed testing.
>
> Those patches are attached. Try each of them in turn to 2.6.33 with a
> 'patch -p1 -R < patch_name' If it doesn't help, use the same command
> without the "-R" to reapply. I'm guessing that 8b45499 is more likely
> to be the problem, and I would try it first.
>
> Larry
Hi Larry i tryied to reverte two patches you sent me but nothing
happens; but i discovered interesting behaviour: the mac address of the
module is:
00:0B:B6....
but starting from 2.6.33 the chip is read as:
14:0B:B6....
(maybe the '0x14' value could be '20dBm' related to the max-TX-power
value.....); so it seems that the driver is faulty reading the chip
properties from sprom (in fact till the 2.6.32 the mac address was
correct and the max-TX-power warning wasn't issued); i noticed that
into drivers/ssb/pcmcia.c tha way to read properties from the chip is
changed also; hope this helps
thanks
dylan
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-02-02 9:11 ` dylan cristiani
@ 2011-02-02 11:55 ` dylan cristiani
2011-02-02 15:30 ` dylan cristiani
0 siblings, 1 reply; 24+ messages in thread
From: dylan cristiani @ 2011-02-02 11:55 UTC (permalink / raw)
To: b43-dev
On Wed, 2 Feb 2011 10:11:51 +0100
dylan cristiani <d.cristiani@idem-tech.it> wrote:
> On Tue, 01 Feb 2011 14:40:32 -0600
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
> > On 02/01/2011 08:41 AM, dylan cristiani wrote:
> > > i have some news: i went back to kernel version 2.6.26 and it
> > > worked so i moved forward kernel by kernel and it works till
> > > kernel 2.6.32; first kernel that shows up the problem is 2.6.33
> > > and, at module loading time i can see for the first time, after
> > > loading firmware, the following debug info (don't know if it's
> > > helpful but same message happears in every non-working kernel
> > > from 2.6.33 to 2.6.37):
> > >
> > > "b43-phy0 warning: Invalid max-TX-power value in SPROM"
> >
> > Between 2.6.32 and 2.6.33, there were only 6 patches that touched
> > SSB. Two of them (e33761e and 3ba6018) affected SPROM writing, one
> > (37ace3d) was only for PCMCIA, and one (ac2752c) only affected
> > logging of a core scan. The two remaining are 391ae22 that fixed an
> > SDIO typo and 8b45499 that put host pointers in a union should be
> > the only ones that needed testing.
> >
> > Those patches are attached. Try each of them in turn to 2.6.33 with
> > a 'patch -p1 -R < patch_name' If it doesn't help, use the same
> > command without the "-R" to reapply. I'm guessing that 8b45499 is
> > more likely to be the problem, and I would try it first.
> >
> > Larry
> Hi Larry i tryied to reverte two patches you sent me but nothing
> happens; but i discovered interesting behaviour: the mac address of
> the module is:
> 00:0B:B6....
> but starting from 2.6.33 the chip is read as:
> 14:0B:B6....
> (maybe the '0x14' value could be '20dBm' related to the max-TX-power
> value.....); so it seems that the driver is faulty reading the chip
> properties from sprom (in fact till the 2.6.32 the mac address was
> correct and the max-TX-power warning wasn't issued); i noticed that
> into drivers/ssb/pcmcia.c tha way to read properties from the chip is
> changed also; hope this helps
Hi larry i located the problem: at ssb level the info (MAC,
max-TX-power and friends) are ok, while when at b43 driver level there
are some data corruption; here comes the log of some debug i put into
drivers followed by the code slices where i put the debug; i'm sure
i'll find the trouble:
boot log
...
MMMMAC0 = 0
MMMMAC1 = b
MMMMAC1 = 6b
MMMMAC1 = 1e
MMMMAC1 = 3e
MMMMAC1 = 86
sprom->maxpwr_bg = 76
ssb: Sonics Silicon Backplane found on PCMCIA device pcmcia0.0
IEEEMMMMAC0 = 14
IEEEMMMMAC1 = b
IEEEMMMMAC1 = 6b
IEEEMMMMAC1 = 1e
IEEEMMMMAC1 = 3e
IEEEMMMMAC1 = 86
b43-phy0: Broadcom 4318 WLAN found (core revision 9)
Broadcom 43xx driver loaded [ Features: M, Firmware-ID: FW13 ]
Reconfiguring network interfaces...
ip: RTNETLINK answers: File exists
b43 ssb0:0: firmware: requesting b43/ucode5.fw
buf=31 a 0loading=1buf=30 a 0loading=0
b43 ssb0:0: firmware: requesting b43/pcm5.fw
buf=31 a 0loading=1buf=30 a 0loading=0
b43 ssb0:0: firmware: requesting b43/b0g0initvals5.fw
buf=31 a 0loading=1buf=30 a 0loading=0
b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
buf=31 a 0loading=1buf=30 a 0loading=0
b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
phy_g max_pwr_bg = 65535
b43-phy0 warning: Invalid max-TX-power value in SPROM.
udhcpc (v1.17.4) started
Sending discover...
phy_g max_pwr_bg = 80
Sending discover...
Sending discover...
No lease, failing
.....
and here the sources:
drivers/ssb/pcmcia.c
static int ssb_pcmcia_get_mac(struct pcmcia_device *p_dev,
tuple_t *tuple,
void *priv)
{
struct ssb_sprom *sprom = priv;
if (tuple->TupleData[0] != CISTPL_FUNCE_LAN_NODE_ID)
return -EINVAL;
if (tuple->TupleDataLen != ETH_ALEN + 2)
return -EINVAL;
if (tuple->TupleData[1] != ETH_ALEN)
return -EINVAL;
memcpy(sprom->il0mac, &tuple->TupleData[2], ETH_ALEN);
//ssb_log
printk(KERN_INFO "MMMMAC0 = %x", sprom->il0mac[0]);
printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[1]);
printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[2]);
printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[3]);
printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[4]);
printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[5]);
//ssb_log
return 0;
};
.....
static int ssb_pcmcia_do_get_invariants(struct pcmcia_device *p_dev,
tuple_t *tuple,
void *priv)
{
.....
sprom->maxpwr_bg = tuple->TupleData[8];
//ssb_log
printk(KERN_INFO "sprom->maxpwr_bg = %d",
sprom->maxpwr_bg);
//ssb_log
......
drivers/net/wireless/b43/main.c
static int b43_wireless_init(struct ssb_device *dev)
{
....
if (is_valid_ether_addr(sprom->et1mac))
SET_IEEE80211_PERM_ADDR(hw, sprom->et1mac);
else
SET_IEEE80211_PERM_ADDR(hw, sprom->il0mac);
//b43_main_log
printk(KERN_INFO "IEEEMMMMAC0 = %x", sprom->il0mac[0]);
printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[1]);
printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[2]);
printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[3]);
printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[4]);
printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[5]);
//b43_main_log
....
drivers/net/wireless/b43/phy_g.c
/* Estimate the TX power emission based on the TSSI */
estimated_pwr = b43_gphy_estimate_power_out(dev, average_tssi);
B43_WARN_ON(phy->type != B43_PHYTYPE_G);
max_pwr = dev->dev->bus->sprom.maxpwr_bg;
//b43_phyg_log
printk(KERN_INFO "phy_g max_pwr_bg = %d\n", max_pwr);
//b43_phyg_log
if (dev->dev->bus->sprom.boardflags_lo & B43_BFL_PACTRL)
max_pwr -= 3; /* minus 0.75 */
if (unlikely(max_pwr >= INT_TO_Q52(30/*dBm*/))) {
b43warn(dev->wl,
"Invalid max-TX-power value in SPROM.\n");
max_pwr = INT_TO_Q52(20); /* fake it */
dev->dev->bus->sprom.maxpwr_bg = max_pwr;
}
....
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-02-02 11:55 ` dylan cristiani
@ 2011-02-02 15:30 ` dylan cristiani
2011-02-02 21:58 ` Larry Finger
2011-02-02 22:40 ` Michael Büsch
0 siblings, 2 replies; 24+ messages in thread
From: dylan cristiani @ 2011-02-02 15:30 UTC (permalink / raw)
To: b43-dev
On Wed, 2 Feb 2011 12:55:29 +0100
dylan cristiani <d.cristiani@idem-tech.it> wrote:
> On Wed, 2 Feb 2011 10:11:51 +0100
> dylan cristiani <d.cristiani@idem-tech.it> wrote:
>
> > On Tue, 01 Feb 2011 14:40:32 -0600
> > Larry Finger <Larry.Finger@lwfinger.net> wrote:
> >
> > > On 02/01/2011 08:41 AM, dylan cristiani wrote:
> > > > i have some news: i went back to kernel version 2.6.26 and it
> > > > worked so i moved forward kernel by kernel and it works till
> > > > kernel 2.6.32; first kernel that shows up the problem is 2.6.33
> > > > and, at module loading time i can see for the first time, after
> > > > loading firmware, the following debug info (don't know if it's
> > > > helpful but same message happears in every non-working kernel
> > > > from 2.6.33 to 2.6.37):
> > > >
> > > > "b43-phy0 warning: Invalid max-TX-power value in SPROM"
> > >
> > > Between 2.6.32 and 2.6.33, there were only 6 patches that touched
> > > SSB. Two of them (e33761e and 3ba6018) affected SPROM writing, one
> > > (37ace3d) was only for PCMCIA, and one (ac2752c) only affected
> > > logging of a core scan. The two remaining are 391ae22 that fixed
> > > an SDIO typo and 8b45499 that put host pointers in a union should
> > > be the only ones that needed testing.
> > >
> > > Those patches are attached. Try each of them in turn to 2.6.33
> > > with a 'patch -p1 -R < patch_name' If it doesn't help, use the
> > > same command without the "-R" to reapply. I'm guessing that
> > > 8b45499 is more likely to be the problem, and I would try it
> > > first.
> > >
> > > Larry
> > Hi Larry i tryied to reverte two patches you sent me but nothing
> > happens; but i discovered interesting behaviour: the mac address of
> > the module is:
> > 00:0B:B6....
> > but starting from 2.6.33 the chip is read as:
> > 14:0B:B6....
> > (maybe the '0x14' value could be '20dBm' related to the max-TX-power
> > value.....); so it seems that the driver is faulty reading the chip
> > properties from sprom (in fact till the 2.6.32 the mac address was
> > correct and the max-TX-power warning wasn't issued); i noticed that
> > into drivers/ssb/pcmcia.c tha way to read properties from the chip
> > is changed also; hope this helps
> Hi larry i located the problem: at ssb level the info (MAC,
> max-TX-power and friends) are ok, while when at b43 driver level there
> are some data corruption; here comes the log of some debug i put into
> drivers followed by the code slices where i put the debug; i'm sure
> i'll find the trouble:
>
> boot log
> ...
> MMMMAC0 = 0
> MMMMAC1 = b
> MMMMAC1 = 6b
> MMMMAC1 = 1e
> MMMMAC1 = 3e
> MMMMAC1 = 86
>
> sprom->maxpwr_bg = 76
>
> ssb: Sonics Silicon Backplane found on PCMCIA device pcmcia0.0
>
> IEEEMMMMAC0 = 14
> IEEEMMMMAC1 = b
> IEEEMMMMAC1 = 6b
> IEEEMMMMAC1 = 1e
> IEEEMMMMAC1 = 3e
> IEEEMMMMAC1 = 86
>
> b43-phy0: Broadcom 4318 WLAN found (core revision 9)
> Broadcom 43xx driver loaded [ Features: M, Firmware-ID: FW13 ]
> Reconfiguring network interfaces...
> ip: RTNETLINK answers: File exists
> b43 ssb0:0: firmware: requesting b43/ucode5.fw
> buf=31 a 0loading=1buf=30 a 0loading=0
> b43 ssb0:0: firmware: requesting b43/pcm5.fw
> buf=31 a 0loading=1buf=30 a 0loading=0
> b43 ssb0:0: firmware: requesting b43/b0g0initvals5.fw
> buf=31 a 0loading=1buf=30 a 0loading=0
> b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
> buf=31 a 0loading=1buf=30 a 0loading=0
> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
>
> phy_g max_pwr_bg = 65535
>
> b43-phy0 warning: Invalid max-TX-power value in SPROM.
> udhcpc (v1.17.4) started
> Sending discover...
> phy_g max_pwr_bg = 80
> Sending discover...
> Sending discover...
> No lease, failing
> .....
>
> and here the sources:
>
> drivers/ssb/pcmcia.c
>
> static int ssb_pcmcia_get_mac(struct pcmcia_device *p_dev,
> tuple_t *tuple,
> void *priv)
> {
> struct ssb_sprom *sprom = priv;
>
> if (tuple->TupleData[0] != CISTPL_FUNCE_LAN_NODE_ID)
> return -EINVAL;
> if (tuple->TupleDataLen != ETH_ALEN + 2)
> return -EINVAL;
> if (tuple->TupleData[1] != ETH_ALEN)
> return -EINVAL;
> memcpy(sprom->il0mac, &tuple->TupleData[2], ETH_ALEN);
>
> //ssb_log
> printk(KERN_INFO "MMMMAC0 = %x", sprom->il0mac[0]);
> printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[1]);
> printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[2]);
> printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[3]);
> printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[4]);
> printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[5]);
> //ssb_log
>
> return 0;
> };
> .....
>
> static int ssb_pcmcia_do_get_invariants(struct pcmcia_device *p_dev,
> tuple_t *tuple,
> void *priv)
> {
> .....
>
> sprom->maxpwr_bg = tuple->TupleData[8];
> //ssb_log
> printk(KERN_INFO "sprom->maxpwr_bg = %d",
> sprom->maxpwr_bg);
> //ssb_log
>
> ......
>
>
> drivers/net/wireless/b43/main.c
>
> static int b43_wireless_init(struct ssb_device *dev)
> {
> ....
>
> if (is_valid_ether_addr(sprom->et1mac))
> SET_IEEE80211_PERM_ADDR(hw, sprom->et1mac);
> else
> SET_IEEE80211_PERM_ADDR(hw, sprom->il0mac);
>
> //b43_main_log
> printk(KERN_INFO "IEEEMMMMAC0 = %x", sprom->il0mac[0]);
> printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[1]);
> printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[2]);
> printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[3]);
> printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[4]);
> printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[5]);
> //b43_main_log
>
> ....
>
> drivers/net/wireless/b43/phy_g.c
>
>
> /* Estimate the TX power emission based on the TSSI */
> estimated_pwr = b43_gphy_estimate_power_out(dev,
> average_tssi);
>
> B43_WARN_ON(phy->type != B43_PHYTYPE_G);
> max_pwr = dev->dev->bus->sprom.maxpwr_bg;
>
> //b43_phyg_log
> printk(KERN_INFO "phy_g max_pwr_bg = %d\n", max_pwr);
> //b43_phyg_log
>
> if (dev->dev->bus->sprom.boardflags_lo & B43_BFL_PACTRL)
> max_pwr -= 3; /* minus 0.75 */
>
> if (unlikely(max_pwr >= INT_TO_Q52(30/*dBm*/))) {
> b43warn(dev->wl,
> "Invalid max-TX-power value in SPROM.\n");
> max_pwr = INT_TO_Q52(20); /* fake it */
> dev->dev->bus->sprom.maxpwr_bg = max_pwr;
> }
> ....
I try to send you a 'maybe regular' patch: this solves the issue; before
the patch, the MSB of the MAC address were overridden by one assignement
inside function ssb_pcmcia_get_invariants(...); here the patch
--- a/drivers/ssb/pcmcia.c
+++ b/drivers/ssb/pcmcia.c
@@ -735,5 +735,5 @@ int ssb_pcmcia_get_invariants(struct ssb_bus *bus,
/* Fetch the vendor specific tuples. */
res = pcmcia_loop_tuple(bus->host_pcmcia, SSB_PCMCIA_CIS,
- ssb_pcmcia_do_get_invariants, sprom);
+ ssb_pcmcia_do_get_invariants, iv);
if ((res == 0) || (res == -ENOSPC))
return 0;
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-02-02 15:30 ` dylan cristiani
@ 2011-02-02 21:58 ` Larry Finger
2011-02-03 8:28 ` dylan cristiani
2011-02-02 22:40 ` Michael Büsch
1 sibling, 1 reply; 24+ messages in thread
From: Larry Finger @ 2011-02-02 21:58 UTC (permalink / raw)
To: b43-dev
On 02/02/2011 09:30 AM, dylan cristiani wrote:
> On Wed, 2 Feb 2011 12:55:29 +0100
> dylan cristiani <d.cristiani@idem-tech.it> wrote:
>
>> On Wed, 2 Feb 2011 10:11:51 +0100
>> dylan cristiani <d.cristiani@idem-tech.it> wrote:
>>
>>> On Tue, 01 Feb 2011 14:40:32 -0600
>>> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>>
>>>> On 02/01/2011 08:41 AM, dylan cristiani wrote:
>>>>> i have some news: i went back to kernel version 2.6.26 and it
>>>>> worked so i moved forward kernel by kernel and it works till
>>>>> kernel 2.6.32; first kernel that shows up the problem is 2.6.33
>>>>> and, at module loading time i can see for the first time, after
>>>>> loading firmware, the following debug info (don't know if it's
>>>>> helpful but same message happears in every non-working kernel
>>>>> from 2.6.33 to 2.6.37):
>>>>>
>>>>> "b43-phy0 warning: Invalid max-TX-power value in SPROM"
>>>>
>>>> Between 2.6.32 and 2.6.33, there were only 6 patches that touched
>>>> SSB. Two of them (e33761e and 3ba6018) affected SPROM writing, one
>>>> (37ace3d) was only for PCMCIA, and one (ac2752c) only affected
>>>> logging of a core scan. The two remaining are 391ae22 that fixed
>>>> an SDIO typo and 8b45499 that put host pointers in a union should
>>>> be the only ones that needed testing.
>>>>
>>>> Those patches are attached. Try each of them in turn to 2.6.33
>>>> with a 'patch -p1 -R < patch_name' If it doesn't help, use the
>>>> same command without the "-R" to reapply. I'm guessing that
>>>> 8b45499 is more likely to be the problem, and I would try it
>>>> first.
>>>>
>>>> Larry
>>> Hi Larry i tryied to reverte two patches you sent me but nothing
>>> happens; but i discovered interesting behaviour: the mac address of
>>> the module is:
>>> 00:0B:B6....
>>> but starting from 2.6.33 the chip is read as:
>>> 14:0B:B6....
>>> (maybe the '0x14' value could be '20dBm' related to the max-TX-power
>>> value.....); so it seems that the driver is faulty reading the chip
>>> properties from sprom (in fact till the 2.6.32 the mac address was
>>> correct and the max-TX-power warning wasn't issued); i noticed that
>>> into drivers/ssb/pcmcia.c tha way to read properties from the chip
>>> is changed also; hope this helps
>> Hi larry i located the problem: at ssb level the info (MAC,
>> max-TX-power and friends) are ok, while when at b43 driver level there
>> are some data corruption; here comes the log of some debug i put into
>> drivers followed by the code slices where i put the debug; i'm sure
>> i'll find the trouble:
>>
>> boot log
>> ...
>> MMMMAC0 = 0
>> MMMMAC1 = b
>> MMMMAC1 = 6b
>> MMMMAC1 = 1e
>> MMMMAC1 = 3e
>> MMMMAC1 = 86
>>
>> sprom->maxpwr_bg = 76
>>
>> ssb: Sonics Silicon Backplane found on PCMCIA device pcmcia0.0
>>
>> IEEEMMMMAC0 = 14
>> IEEEMMMMAC1 = b
>> IEEEMMMMAC1 = 6b
>> IEEEMMMMAC1 = 1e
>> IEEEMMMMAC1 = 3e
>> IEEEMMMMAC1 = 86
>>
>> b43-phy0: Broadcom 4318 WLAN found (core revision 9)
>> Broadcom 43xx driver loaded [ Features: M, Firmware-ID: FW13 ]
>> Reconfiguring network interfaces...
>> ip: RTNETLINK answers: File exists
>> b43 ssb0:0: firmware: requesting b43/ucode5.fw
>> buf=31 a 0loading=1buf=30 a 0loading=0
>> b43 ssb0:0: firmware: requesting b43/pcm5.fw
>> buf=31 a 0loading=1buf=30 a 0loading=0
>> b43 ssb0:0: firmware: requesting b43/b0g0initvals5.fw
>> buf=31 a 0loading=1buf=30 a 0loading=0
>> b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
>> buf=31 a 0loading=1buf=30 a 0loading=0
>> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
>>
>> phy_g max_pwr_bg = 65535
>>
>> b43-phy0 warning: Invalid max-TX-power value in SPROM.
>> udhcpc (v1.17.4) started
>> Sending discover...
>> phy_g max_pwr_bg = 80
>> Sending discover...
>> Sending discover...
>> No lease, failing
>> .....
>>
>> and here the sources:
>>
>> drivers/ssb/pcmcia.c
>>
>> static int ssb_pcmcia_get_mac(struct pcmcia_device *p_dev,
>> tuple_t *tuple,
>> void *priv)
>> {
>> struct ssb_sprom *sprom = priv;
>>
>> if (tuple->TupleData[0] != CISTPL_FUNCE_LAN_NODE_ID)
>> return -EINVAL;
>> if (tuple->TupleDataLen != ETH_ALEN + 2)
>> return -EINVAL;
>> if (tuple->TupleData[1] != ETH_ALEN)
>> return -EINVAL;
>> memcpy(sprom->il0mac, &tuple->TupleData[2], ETH_ALEN);
>>
>> //ssb_log
>> printk(KERN_INFO "MMMMAC0 = %x", sprom->il0mac[0]);
>> printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[1]);
>> printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[2]);
>> printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[3]);
>> printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[4]);
>> printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[5]);
>> //ssb_log
>>
>> return 0;
>> };
>> .....
>>
>> static int ssb_pcmcia_do_get_invariants(struct pcmcia_device *p_dev,
>> tuple_t *tuple,
>> void *priv)
>> {
>> .....
>>
>> sprom->maxpwr_bg = tuple->TupleData[8];
>> //ssb_log
>> printk(KERN_INFO "sprom->maxpwr_bg = %d",
>> sprom->maxpwr_bg);
>> //ssb_log
>>
>> ......
>>
>>
>> drivers/net/wireless/b43/main.c
>>
>> static int b43_wireless_init(struct ssb_device *dev)
>> {
>> ....
>>
>> if (is_valid_ether_addr(sprom->et1mac))
>> SET_IEEE80211_PERM_ADDR(hw, sprom->et1mac);
>> else
>> SET_IEEE80211_PERM_ADDR(hw, sprom->il0mac);
>>
>> //b43_main_log
>> printk(KERN_INFO "IEEEMMMMAC0 = %x", sprom->il0mac[0]);
>> printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[1]);
>> printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[2]);
>> printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[3]);
>> printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[4]);
>> printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[5]);
>> //b43_main_log
>>
>> ....
>>
>> drivers/net/wireless/b43/phy_g.c
>>
>>
>> /* Estimate the TX power emission based on the TSSI */
>> estimated_pwr = b43_gphy_estimate_power_out(dev,
>> average_tssi);
>>
>> B43_WARN_ON(phy->type != B43_PHYTYPE_G);
>> max_pwr = dev->dev->bus->sprom.maxpwr_bg;
>>
>> //b43_phyg_log
>> printk(KERN_INFO "phy_g max_pwr_bg = %d\n", max_pwr);
>> //b43_phyg_log
>>
>> if (dev->dev->bus->sprom.boardflags_lo & B43_BFL_PACTRL)
>> max_pwr -= 3; /* minus 0.75 */
>>
>> if (unlikely(max_pwr >= INT_TO_Q52(30/*dBm*/))) {
>> b43warn(dev->wl,
>> "Invalid max-TX-power value in SPROM.\n");
>> max_pwr = INT_TO_Q52(20); /* fake it */
>> dev->dev->bus->sprom.maxpwr_bg = max_pwr;
>> }
>> ....
> I try to send you a 'maybe regular' patch: this solves the issue; before
> the patch, the MSB of the MAC address were overridden by one assignement
> inside function ssb_pcmcia_get_invariants(...); here the patch
>
>
> --- a/drivers/ssb/pcmcia.c
> +++ b/drivers/ssb/pcmcia.c
> @@ -735,5 +735,5 @@ int ssb_pcmcia_get_invariants(struct ssb_bus *bus,
> /* Fetch the vendor specific tuples. */
> res = pcmcia_loop_tuple(bus->host_pcmcia, SSB_PCMCIA_CIS,
> - ssb_pcmcia_do_get_invariants, sprom);
> + ssb_pcmcia_do_get_invariants, iv);
> if ((res == 0) || (res == -ENOSPC))
> return 0;
Does this one-liner solve all the problems, or just the MAC address?
Larry
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-02-02 15:30 ` dylan cristiani
2011-02-02 21:58 ` Larry Finger
@ 2011-02-02 22:40 ` Michael Büsch
2011-02-03 8:45 ` dylan cristiani
1 sibling, 1 reply; 24+ messages in thread
From: Michael Büsch @ 2011-02-02 22:40 UTC (permalink / raw)
To: b43-dev
On Wed, 2011-02-02 at 16:30 +0100, dylan cristiani wrote:
> --- a/drivers/ssb/pcmcia.c
> +++ b/drivers/ssb/pcmcia.c
> @@ -735,5 +735,5 @@ int ssb_pcmcia_get_invariants(struct ssb_bus *bus,
> /* Fetch the vendor specific tuples. */
> res = pcmcia_loop_tuple(bus->host_pcmcia, SSB_PCMCIA_CIS,
> - ssb_pcmcia_do_get_invariants, sprom);
> + ssb_pcmcia_do_get_invariants, iv);
> if ((res == 0) || (res == -ENOSPC))
> return 0;
That patch seems right.
I guess that the regression was introduced with the general PCMCIA
changes by Dominik Brodowski back in October.
However...
I do actually have serious trouble to figure out what you're doing.
I'm not saying that there is no bug, but I don't understand what you're
doing to trigger and/or track down the bug.
Let's look at two facts you gave us in previous email:
1) You want to change the PCI IDs. That implies you have a PCI card.
2) You are patching stuff in the PCMCIA code.
These two things are mutually exclusive.
You card is either PCI xor PCMCIA. So only one of these facts can
be true.
If it really is PCMCIA, I'll have to say that the SSB-PCMCIA
SPROM writing code is basically untested. That means I would be
surprised if it worked at all.
PS:
I also want to note that it is wrong to override the SPROM with
an image acquired elsewhere. The SPROM contains important calibration
data that is card-specific. So you cannot take the SPROM from one
card and put it into another. Even if it's exactly the same card type.
You must read SPROM -> modify that image -> write SPROM back.
--
Greetings Michael.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-02-02 21:58 ` Larry Finger
@ 2011-02-03 8:28 ` dylan cristiani
0 siblings, 0 replies; 24+ messages in thread
From: dylan cristiani @ 2011-02-03 8:28 UTC (permalink / raw)
To: b43-dev
On Wed, 02 Feb 2011 15:58:55 -0600
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 02/02/2011 09:30 AM, dylan cristiani wrote:
> > On Wed, 2 Feb 2011 12:55:29 +0100
> > dylan cristiani <d.cristiani@idem-tech.it> wrote:
> >
> >> On Wed, 2 Feb 2011 10:11:51 +0100
> >> dylan cristiani <d.cristiani@idem-tech.it> wrote:
> >>
> >>> On Tue, 01 Feb 2011 14:40:32 -0600
> >>> Larry Finger <Larry.Finger@lwfinger.net> wrote:
> >>>
> >>>> On 02/01/2011 08:41 AM, dylan cristiani wrote:
> >>>>> i have some news: i went back to kernel version 2.6.26 and it
> >>>>> worked so i moved forward kernel by kernel and it works till
> >>>>> kernel 2.6.32; first kernel that shows up the problem is 2.6.33
> >>>>> and, at module loading time i can see for the first time, after
> >>>>> loading firmware, the following debug info (don't know if it's
> >>>>> helpful but same message happears in every non-working kernel
> >>>>> from 2.6.33 to 2.6.37):
> >>>>>
> >>>>> "b43-phy0 warning: Invalid max-TX-power value in SPROM"
> >>>>
> >>>> Between 2.6.32 and 2.6.33, there were only 6 patches that touched
> >>>> SSB. Two of them (e33761e and 3ba6018) affected SPROM writing,
> >>>> one (37ace3d) was only for PCMCIA, and one (ac2752c) only
> >>>> affected logging of a core scan. The two remaining are 391ae22
> >>>> that fixed an SDIO typo and 8b45499 that put host pointers in a
> >>>> union should be the only ones that needed testing.
> >>>>
> >>>> Those patches are attached. Try each of them in turn to 2.6.33
> >>>> with a 'patch -p1 -R < patch_name' If it doesn't help, use the
> >>>> same command without the "-R" to reapply. I'm guessing that
> >>>> 8b45499 is more likely to be the problem, and I would try it
> >>>> first.
> >>>>
> >>>> Larry
> >>> Hi Larry i tryied to reverte two patches you sent me but nothing
> >>> happens; but i discovered interesting behaviour: the mac address
> >>> of the module is:
> >>> 00:0B:B6....
> >>> but starting from 2.6.33 the chip is read as:
> >>> 14:0B:B6....
> >>> (maybe the '0x14' value could be '20dBm' related to the
> >>> max-TX-power value.....); so it seems that the driver is faulty
> >>> reading the chip properties from sprom (in fact till the 2.6.32
> >>> the mac address was correct and the max-TX-power warning wasn't
> >>> issued); i noticed that into drivers/ssb/pcmcia.c tha way to read
> >>> properties from the chip is changed also; hope this helps
> >> Hi larry i located the problem: at ssb level the info (MAC,
> >> max-TX-power and friends) are ok, while when at b43 driver level
> >> there are some data corruption; here comes the log of some debug i
> >> put into drivers followed by the code slices where i put the
> >> debug; i'm sure i'll find the trouble:
> >>
> >> boot log
> >> ...
> >> MMMMAC0 = 0
> >> MMMMAC1 = b
> >> MMMMAC1 = 6b
> >> MMMMAC1 = 1e
> >> MMMMAC1 = 3e
> >> MMMMAC1 = 86
> >>
> >> sprom->maxpwr_bg = 76
> >>
> >> ssb: Sonics Silicon Backplane found on PCMCIA device pcmcia0.0
> >>
> >> IEEEMMMMAC0 = 14
> >> IEEEMMMMAC1 = b
> >> IEEEMMMMAC1 = 6b
> >> IEEEMMMMAC1 = 1e
> >> IEEEMMMMAC1 = 3e
> >> IEEEMMMMAC1 = 86
> >>
> >> b43-phy0: Broadcom 4318 WLAN found (core revision 9)
> >> Broadcom 43xx driver loaded [ Features: M, Firmware-ID: FW13 ]
> >> Reconfiguring network interfaces...
> >> ip: RTNETLINK answers: File exists
> >> b43 ssb0:0: firmware: requesting b43/ucode5.fw
> >> buf=31 a 0loading=1buf=30 a 0loading=0
> >> b43 ssb0:0: firmware: requesting b43/pcm5.fw
> >> buf=31 a 0loading=1buf=30 a 0loading=0
> >> b43 ssb0:0: firmware: requesting b43/b0g0initvals5.fw
> >> buf=31 a 0loading=1buf=30 a 0loading=0
> >> b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
> >> buf=31 a 0loading=1buf=30 a 0loading=0
> >> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
> >>
> >> phy_g max_pwr_bg = 65535
> >>
> >> b43-phy0 warning: Invalid max-TX-power value in SPROM.
> >> udhcpc (v1.17.4) started
> >> Sending discover...
> >> phy_g max_pwr_bg = 80
> >> Sending discover...
> >> Sending discover...
> >> No lease, failing
> >> .....
> >>
> >> and here the sources:
> >>
> >> drivers/ssb/pcmcia.c
> >>
> >> static int ssb_pcmcia_get_mac(struct pcmcia_device *p_dev,
> >> tuple_t *tuple,
> >> void *priv)
> >> {
> >> struct ssb_sprom *sprom = priv;
> >>
> >> if (tuple->TupleData[0] != CISTPL_FUNCE_LAN_NODE_ID)
> >> return -EINVAL;
> >> if (tuple->TupleDataLen != ETH_ALEN + 2)
> >> return -EINVAL;
> >> if (tuple->TupleData[1] != ETH_ALEN)
> >> return -EINVAL;
> >> memcpy(sprom->il0mac, &tuple->TupleData[2], ETH_ALEN);
> >>
> >> //ssb_log
> >> printk(KERN_INFO "MMMMAC0 = %x", sprom->il0mac[0]);
> >> printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[1]);
> >> printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[2]);
> >> printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[3]);
> >> printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[4]);
> >> printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[5]);
> >> //ssb_log
> >>
> >> return 0;
> >> };
> >> .....
> >>
> >> static int ssb_pcmcia_do_get_invariants(struct pcmcia_device
> >> *p_dev, tuple_t *tuple,
> >> void *priv)
> >> {
> >> .....
> >>
> >> sprom->maxpwr_bg = tuple->TupleData[8];
> >> //ssb_log
> >> printk(KERN_INFO "sprom->maxpwr_bg = %d",
> >> sprom->maxpwr_bg);
> >> //ssb_log
> >>
> >> ......
> >>
> >>
> >> drivers/net/wireless/b43/main.c
> >>
> >> static int b43_wireless_init(struct ssb_device *dev)
> >> {
> >> ....
> >>
> >> if (is_valid_ether_addr(sprom->et1mac))
> >> SET_IEEE80211_PERM_ADDR(hw, sprom->et1mac);
> >> else
> >> SET_IEEE80211_PERM_ADDR(hw, sprom->il0mac);
> >>
> >> //b43_main_log
> >> printk(KERN_INFO "IEEEMMMMAC0 = %x", sprom->il0mac[0]);
> >> printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[1]);
> >> printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[2]);
> >> printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[3]);
> >> printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[4]);
> >> printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[5]);
> >> //b43_main_log
> >>
> >> ....
> >>
> >> drivers/net/wireless/b43/phy_g.c
> >>
> >>
> >> /* Estimate the TX power emission based on the TSSI */
> >> estimated_pwr = b43_gphy_estimate_power_out(dev,
> >> average_tssi);
> >>
> >> B43_WARN_ON(phy->type != B43_PHYTYPE_G);
> >> max_pwr = dev->dev->bus->sprom.maxpwr_bg;
> >>
> >> //b43_phyg_log
> >> printk(KERN_INFO "phy_g max_pwr_bg = %d\n", max_pwr);
> >> //b43_phyg_log
> >>
> >> if (dev->dev->bus->sprom.boardflags_lo & B43_BFL_PACTRL)
> >> max_pwr -= 3; /* minus 0.75 */
> >>
> >> if (unlikely(max_pwr >= INT_TO_Q52(30/*dBm*/))) {
> >> b43warn(dev->wl,
> >> "Invalid max-TX-power value in SPROM.\n");
> >> max_pwr = INT_TO_Q52(20); /* fake it */
> >> dev->dev->bus->sprom.maxpwr_bg = max_pwr;
> >> }
> >> ....
> > I try to send you a 'maybe regular' patch: this solves the issue;
> > before the patch, the MSB of the MAC address were overridden by one
> > assignement inside function ssb_pcmcia_get_invariants(...); here
> > the patch
> >
> >
> > --- a/drivers/ssb/pcmcia.c
> > +++ b/drivers/ssb/pcmcia.c
> > @@ -735,5 +735,5 @@ int ssb_pcmcia_get_invariants(struct ssb_bus
> > *bus, /* Fetch the vendor specific tuples. */
> > res = pcmcia_loop_tuple(bus->host_pcmcia, SSB_PCMCIA_CIS,
> > - ssb_pcmcia_do_get_invariants,
> > sprom);
> > + ssb_pcmcia_do_get_invariants, iv);
> > if ((res == 0) || (res == -ENOSPC))
> > return 0;
>
> Does this one-liner solve all the problems, or just the MAC address?
>
> Larry
as i can see all the problem becuase also the max-TX-power keep the
righ value; the fact is that now the structure of
ssb_pcmcia_do_get_invariants doesn't waste the one of
ssb_pcmcia_get_mac and viceversa so all fields seems to be right; in
fact i can just see that MAC and max-TX-power are correct and the
wireless module is working very well, but if you want to suggest me
some values to be checked feel free!
Do you think that we must cc also the linux-arm-kernel list?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-02-02 22:40 ` Michael Büsch
@ 2011-02-03 8:45 ` dylan cristiani
2011-02-03 10:29 ` Michael Büsch
0 siblings, 1 reply; 24+ messages in thread
From: dylan cristiani @ 2011-02-03 8:45 UTC (permalink / raw)
To: b43-dev
On Wed, 02 Feb 2011 23:40:08 +0100
Michael B?sch <mb@bu3sch.de> wrote:
> On Wed, 2011-02-02 at 16:30 +0100, dylan cristiani wrote:
> > --- a/drivers/ssb/pcmcia.c
> > +++ b/drivers/ssb/pcmcia.c
> > @@ -735,5 +735,5 @@ int ssb_pcmcia_get_invariants(struct ssb_bus
> > *bus, /* Fetch the vendor specific tuples. */
> > res = pcmcia_loop_tuple(bus->host_pcmcia, SSB_PCMCIA_CIS,
> > - ssb_pcmcia_do_get_invariants,
> > sprom);
> > + ssb_pcmcia_do_get_invariants, iv);
> > if ((res == 0) || (res == -ENOSPC))
> > return 0;
>
> That patch seems right.
> I guess that the regression was introduced with the general PCMCIA
> changes by Dominik Brodowski back in October.
>
>
>
> However...
>
> I do actually have serious trouble to figure out what you're doing.
> I'm not saying that there is no bug, but I don't understand what
> you're doing to trigger and/or track down the bug.
>
> Let's look at two facts you gave us in previous email:
>
> 1) You want to change the PCI IDs. That implies you have a PCI card.
> 2) You are patching stuff in the PCMCIA code.
i'm using PCMCIA module with BCM4318 so the 2 one is the right statement
>
> These two things are mutually exclusive.
> You card is either PCI xor PCMCIA. So only one of these facts can
> be true.
yes as i told using b43 driver for PCMCIA ans SSB backplane
>
> If it really is PCMCIA, I'll have to say that the SSB-PCMCIA
> SPROM writing code is basically untested. That means I would be
> surprised if it worked at all.
>
> PS:
> I also want to note that it is wrong to override the SPROM with
> an image acquired elsewhere. The SPROM contains important calibration
> data that is card-specific. So you cannot take the SPROM from one
> card and put it into another. Even if it's exactly the same card type.
> You must read SPROM -> modify that image -> write SPROM back.
>
i'm not trying to write to SPROM i noticed that using kernel 2.6.36 i
was seeing the warning message:
"b43-phy0 warning: Invalid max-TX-power value in SPROM"
, then the wlan card didn't associate to AP.
Then i decided to try to migrate forth to 2.6.37 then back to
2.6.34 but problem was still present; then i changed strategy and i went
very very back to 2.6.26 and i noticed that the warning message wasn't
issued and the wlan module associates to AP and worked; so i decided to
migrate, kernel by kernel, to the first one that showed up the
original problem, that was the 2.6.33; so i guessed that there were
somewhere some changes in SPROM reading methods, that were 'wasting'
some structure where those SPROM values were stored; with a big amount
of printk i located the problem then i (hope to have) fixed it; so
resuming it wasn't problem in ovverriding SPROM values but just the way
the driver was reading and storing these values; hope i explained the
issue
--
eng. dylan cristiani
idem srl
^ permalink raw reply [flat|nested] 24+ messages in thread
* Trouble using bcm4318 compact flash with b43 driver
2011-02-03 8:45 ` dylan cristiani
@ 2011-02-03 10:29 ` Michael Büsch
0 siblings, 0 replies; 24+ messages in thread
From: Michael Büsch @ 2011-02-03 10:29 UTC (permalink / raw)
To: b43-dev
On Thu, 2011-02-03 at 09:45 +0100, dylan cristiani wrote:
> i'm not trying to write to SPROM i noticed that using kernel 2.6.36 i
> was seeing the warning message:
> "b43-phy0 warning: Invalid max-TX-power value in SPROM"
> , then the wlan card didn't associate to AP.
Oh I think I mixed up two threads on the list then. I should pay more
attention before replying. :D
Anyway, I think your patch is right.
--
Greetings Michael.
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2011-02-03 10:29 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-14 17:21 Trouble using bcm4318 compact flash with b43 driver dylan cristiani
2011-01-14 18:52 ` Larry Finger
2011-01-15 7:05 ` Dylan Cristiani
2011-01-15 16:38 ` Larry Finger
2011-01-17 10:06 ` dylan cristiani
2011-01-17 13:51 ` dylan cristiani
2011-01-18 10:58 ` dylan cristiani
2011-01-18 14:34 ` Larry Finger
2011-01-19 13:03 ` dylan cristiani
2011-01-21 15:51 ` Dylan Cristiani
2011-01-21 17:22 ` Larry Finger
2011-01-21 21:54 ` Dylan Cristiani
2011-01-21 22:13 ` Larry Finger
2011-01-22 10:48 ` Dylan Cristiani
2011-02-01 14:41 ` dylan cristiani
2011-02-01 20:40 ` Larry Finger
2011-02-02 9:11 ` dylan cristiani
2011-02-02 11:55 ` dylan cristiani
2011-02-02 15:30 ` dylan cristiani
2011-02-02 21:58 ` Larry Finger
2011-02-03 8:28 ` dylan cristiani
2011-02-02 22:40 ` Michael Büsch
2011-02-03 8:45 ` dylan cristiani
2011-02-03 10:29 ` Michael Büsch
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.