* [PATCH 18/23] wireless-regdb: update PR's regulatory rules
From: Luis R. Rodriguez @ 2013-11-01 14:03 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, wireless-regdb, Luis R. Rodriguez
In-Reply-To: <1383314598-21240-1-git-send-email-mcgrof@do-not-panic.com>
This:
o Increases max EIRP from 27 dBm to 30 dBm on the
2.4 GHz frequency range
o Extends the 5 GHz DFS frequency range by 20 MHz
Source is QCA's regulatory team's efforts.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/db.txt b/db.txt
index e9d1540..b54ebd8 100644
--- a/db.txt
+++ b/db.txt
@@ -654,10 +654,10 @@ country PT: DFS-ETSI
(57240 - 65880 @ 2160), (40), NO-OUTDOOR
country PR: DFS-FCC
- (2402 - 2472 @ 40), (27)
+ (2402 - 2472 @ 40), (30)
(5170 - 5250 @ 80), (17)
(5250 - 5330 @ 80), (24), DFS
- (5490 - 5710 @ 80), (24), DFS
+ (5490 - 5730 @ 80), (24), DFS
(5735 - 5835 @ 80), (30)
country QA: DFS-JP
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH 19/23] wireless-regdb: update KR's regulatory rules
From: Luis R. Rodriguez @ 2013-11-01 14:03 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, wireless-regdb, Luis R. Rodriguez
In-Reply-To: <1383314598-21240-1-git-send-email-mcgrof@do-not-panic.com>
This:
o enables HT40 for the 2.4 GHz frequency range
o extends the 5 GHz DFS frequency range
Source is QCA's regulatory team's efforts.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/db.txt b/db.txt
index b54ebd8..9158448 100644
--- a/db.txt
+++ b/db.txt
@@ -469,9 +469,10 @@ country KP: DFS-JP
country KR: DFS-JP
(2402 - 2482 @ 20), (20)
+ (2402 - 2482 @ 40), (20)
(5170 - 5250 @ 80), (20)
(5250 - 5330 @ 80), (20), DFS
- (5490 - 5630 @ 80), (30), DFS
+ (5490 - 5710 @ 80), (30), DFS
(5735 - 5815 @ 80), (30)
country KW: DFS-ETSI
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH 20/23] wireless-regdb: update MX's regulatory rules
From: Luis R. Rodriguez @ 2013-11-01 14:03 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, wireless-regdb, Luis R. Rodriguez
In-Reply-To: <1383314598-21240-1-git-send-email-mcgrof@do-not-panic.com>
This:
o increases the 2.4 GHz frequency range but with the
compromise of reducing the max EIRP from 27 dBm to
20 dBm
o extends the second 5 GHz DFS frequency range
Source is QCA's regulatory team's efforts.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/db.txt b/db.txt
index 9158448..40a64d7 100644
--- a/db.txt
+++ b/db.txt
@@ -567,10 +567,10 @@ country MY: DFS-FCC
(5735 - 5835 @ 80), (30)
country MX: DFS-FCC
- (2402 - 2472 @ 40), (27)
+ (2402 - 2482 @ 40), (20)
(5170 - 5250 @ 80), (17)
(5250 - 5330 @ 80), (24), DFS
- (5490 - 5710 @ 80), (24), DFS
+ (5490 - 5730 @ 80), (24), DFS
(5735 - 5835 @ 80), (30)
country NL: DFS-ETSI
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH 21/23] wireless-regdb: update PA's regulatory rules
From: Luis R. Rodriguez @ 2013-11-01 14:03 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, wireless-regdb, Luis R. Rodriguez
In-Reply-To: <1383314598-21240-1-git-send-email-mcgrof@do-not-panic.com>
This:
o increases the max EIRP on the 2.4 GHz frequency
range from 27 dBm to 30 dBm
o enables VHT80 on all the 5 GHz frequency ranges
Source is QCA's regulatory team's efforts.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/db.txt b/db.txt
index 40a64d7..97165ed 100644
--- a/db.txt
+++ b/db.txt
@@ -608,10 +608,10 @@ country OM: DFS-ETSI
(5490 - 5710 @ 80), (27), DFS
country PA: DFS-FCC
- (2402 - 2472 @ 40), (27)
- (5170 - 5250 @ 40), (17)
- (5250 - 5330 @ 40), (23), DFS
- (5735 - 5835 @ 40), (30)
+ (2402 - 2472 @ 40), (30)
+ (5170 - 5250 @ 80), (17)
+ (5250 - 5330 @ 80), (23), DFS
+ (5735 - 5835 @ 80), (30)
country PE: DFS-FCC
(2402 - 2482 @ 40), (20)
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH 22/23] wireless-regdb: update TW's regulatory rules
From: Luis R. Rodriguez @ 2013-11-01 14:03 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, wireless-regdb, Luis R. Rodriguez
In-Reply-To: <1383314598-21240-1-git-send-email-mcgrof@do-not-panic.com>
This:
o Increases the max EIRP for the 2.4 GHz band from
27 dBm to 30 dBm
o Splits up the 5 GHz DFS band into two DFS bands,
one with VHT80 support, another only with HT40
support
o Extends the last 5 GHz frequency range by 20 MHz
Source is QCA's regulatory team's efforts.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/db.txt b/db.txt
index 97165ed..e45991f 100644
--- a/db.txt
+++ b/db.txt
@@ -744,10 +744,11 @@ country SY:
(2402 - 2482 @ 40), (20)
country TW: DFS-JP
- (2402 - 2472 @ 40), (27)
+ (2402 - 2472 @ 40), (30)
(5270 - 5330 @ 40), (17), DFS
- (5490 - 5710 @ 80), (30), DFS
- (5735 - 5815 @ 80), (30)
+ (5490 - 5590 @ 80), (30), DFS
+ (5650 - 5710 @ 40), (30), DFS
+ (5735 - 5835 @ 80), (30)
country TH: DFS-FCC
(2402 - 2482 @ 40), (20)
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH 23/23] wireless-regdb: update US' regulatory rules
From: Luis R. Rodriguez @ 2013-11-01 14:03 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, wireless-regdb, Luis R. Rodriguez
In-Reply-To: <1383314598-21240-1-git-send-email-mcgrof@do-not-panic.com>
This:
o Increases the max EIRP on the 2.4 GHz band from
27 dBm to 30 dBm
o Decreases the max EIRP for the first DFS frequency
range by 1 dBm
o Removes the two lower 5 GHz DFS frequency ranges
Source is QCA's regulatory team's efforts.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/db.txt b/db.txt
index e45991f..752dfc9 100644
--- a/db.txt
+++ b/db.txt
@@ -793,11 +793,9 @@ country UA: DFS-ETSI
(57240 - 65880 @ 2160), (40), NO-OUTDOOR
country US: DFS-FCC
- (2402 - 2472 @ 40), (27)
+ (2402 - 2472 @ 40), (30)
(5170 - 5250 @ 80), (17)
- (5250 - 5330 @ 80), (24), DFS
- (5490 - 5600 @ 80), (24), DFS
- (5650 - 5710 @ 40), (24), DFS
+ (5250 - 5330 @ 80), (23), DFS
(5735 - 5835 @ 80), (30)
# 60g band
# reference: http://cfr.regstoday.com/47cfr15.aspx#47_CFR_15p255
--
1.8.4.rc3
^ permalink raw reply related
* Re: BUG in rfcomm_sock_getsockopt+0x128/0x200
From: Fabio Rossi @ 2013-11-01 15:22 UTC (permalink / raw)
To: marcel
Cc: linux-wireless@vger.kernel.org Wireless,
linux-bluetooth@vger.kernel.org development
>what socket option is your client program setting? Do you happen to know that.
Would make it a lot easier to track this down.
Hi Marcel,
I'm using the bluetoothd daemon at startup and it crashes as soon as the
dongle is inserted. To test the behaviour I removed the dongle and restart the
daemon with
# bluetoothd -n -d
bluetoothd[4450]: Bluetooth daemon 4.101
bluetoothd[4450]: src/main.c:parse_config() parsing main.conf
bluetoothd[4450]: src/main.c:parse_config() discovto=0
bluetoothd[4450]: src/main.c:parse_config() pairto=0
bluetoothd[4450]: src/main.c:parse_config() pageto=8192
bluetoothd[4450]: src/main.c:parse_config() auto_to=60
bluetoothd[4450]: src/main.c:parse_config() name=%h-%d
bluetoothd[4450]: src/main.c:parse_config() class=0x000100
bluetoothd[4450]: src/main.c:parse_config() Key file does not have key
'DeviceID'
bluetoothd[4450]: Starting SDP server
bluetoothd[4450]: src/plugin.c:plugin_init() Loading builtin plugins
bluetoothd[4450]: src/plugin.c:add_plugin() Loading pnat plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading audio plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading input plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading serial plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading network plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading service plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading health plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading hciops plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading mgmtops plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading formfactor plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading storage plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading adaptername plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading wiimote plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading maemo6 plugin
bluetoothd[4450]: src/plugin.c:plugin_init() Loading plugins
/usr/lib64/bluetooth/plugins
bluetoothd[4450]: plugins/service.c:register_interface() path
/org/bluez/4450/any
bluetoothd[4450]: plugins/service.c:register_interface() Registered interface
org.bluez.Service on path /org/bluez/4450/any
bluetoothd[4450]: plugins/maemo6.c:maemo6_init() init maemo6 plugin
bluetoothd[4450]: health/hdp.c:hdp_manager_start() Starting Health manager
bluetoothd[4450]: network/manager.c:read_config() /etc/bluetooth/network.conf:
Key file does not have key 'DisableSecurity'
bluetoothd[4450]: network/manager.c:read_config() Config options:
Security=true
bluetoothd[4450]: input/manager.c:input_manager_init() input.conf: Key file
does not have key 'IdleTimeout'
bluetoothd[4450]: audio/manager.c:audio_manager_init() audio.conf: Key file
does not have key 'AutoConnect'
bluetoothd[4450]: plugins/pnat.c:pnat_init() Setup Phonet AT (DUN) plugin
bluetoothd[4450]: plugins/hciops.c:hciops_init()
bluetoothd[4450]: Bluetooth Management interface initialized
bluetoothd[4450]: Failed to open RFKILL control device
bluetoothd[4450]: src/main.c:main() Entering main loop
bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 12 bytes from
management socket
bluetoothd[4450]: plugins/mgmtops.c:mgmt_cmd_complete()
bluetoothd[4450]: plugins/mgmtops.c:read_version_complete() version 1 revision
4
bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 11 bytes from
management socket
bluetoothd[4450]: plugins/mgmtops.c:mgmt_cmd_complete()
then I insert the dongle
bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 6 bytes from
management socket
bluetoothd[4450]: plugins/mgmtops.c:add_controller() Added controller 0
bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 289 bytes from
management socket
bluetoothd[4450]: plugins/mgmtops.c:mgmt_cmd_complete()
bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 addr 00:09:DD:XX:
XX:XX version 3 manufacturer 10 class 0x000000
bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 settings
bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 name CSR - bc4
bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 short name
bluetoothd[4450]: plugins/mgmtops.c:mgmt_remove_uuid() index 0
bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=1
bluetoothd[4450]: plugins/mgmtops.c:mgmt_read_bdaddr() index 0 addr 00:09:DD:
XX:XX:XX
bluetoothd[4450]: src/sdpd-database.c:sdp_init_services_list()
bluetoothd[4450]: plugins/mgmtops.c:mgmt_add_uuid() index 0
bluetoothd[4450]: plugins/mgmtops.c:mgmt_add_uuid() index 0
bluetoothd[4450]: plugins/service.c:register_interface() path
/org/bluez/4450/hci0
bluetoothd[4450]: plugins/service.c:register_interface() Registered interface
org.bluez.Service on path /org/bluez/4450/hci0
bluetoothd[4450]: plugins/maemo6.c:mce_probe() path /org/bluez/4450/hci0
bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=2
bluetoothd[4450]: network/manager.c:network_server_probe() path
/org/bluez/4450/hci0
bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=3
bluetoothd[4450]: network/server.c:server_register() Registered interface org.
bluez.NetworkServer on path /org/bluez/4450/hci0
bluetoothd[4450]: serial/manager.c:proxy_probe() path /org/bluez/4450/hci0
bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=4
bluetoothd[4450]: serial/proxy.c:proxy_register() Registered interface org.
bluez.SerialProxyManager on path /org/bluez/4450/hci0
bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=5
bluetoothd[4450]: audio/manager.c:media_server_probe() path
/org/bluez/4450/hci0
bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=6
bluetoothd[4450]: audio/manager.c:audio_adapter_ref() 0x7f6c1794b2b0: ref=1
bluetoothd[4450]: audio/manager.c:headset_server_probe() path
/org/bluez/4450/hci0
bluetoothd[4450]: audio/manager.c:audio_adapter_ref() 0x7f6c1794b2b0: ref=2
bluetoothd[4450]: audio/manager.c:headset_server_init() audio.conf: Key file
does not have key 'Master'
Killed
and I get the crash previously reported. If I use a working kernel the
bluetooth daemon continues its startup and the next lines are
bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Adding record with
handle 0x10000
bluetoothd[2322]: plugins/mgmtops.c:mgmt_add_uuid() index
0
bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
UUID 00000003-0000-1000-8000-00805f9
bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
UUID 00000100-0000-1000-8000-00805f9
bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
UUID 00001002-0000-1000-8000-00805f9
bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
UUID 00001108-0000-1000-8000-00805f9
bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
UUID 00001112-0000-1000-8000-00805f9
bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
UUID 00001203-0000-1000-8000-00805f9
... [ omitted ] ...
Furthermore, comparing bluetoothd logs (working vs not working kernel) I have
noticed the following difference:
bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 addr 00:09:DD:XX:
XX:XX version 3 manufacturer 10 class 0x000000
bluetoothd[2322]: plugins/mgmtops.c:read_info_complete() hci0 addr 00:09:DD:XX:
XX:XX version 3 manufacturer 10 class 0x5a0100
so it seems the class is not properly initialized.
The kernel is configured with
CONFIG_BT=y
CONFIG_BT_RFCOMM=y
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=y
CONFIG_BT_HIDP=y
CONFIG_BT_HCIBTUSB=y
CONFIG_BT_HCIUART=y
Let me know if I can help providing more info.
Best regards,
Fabio
^ permalink raw reply
* Re: BCM43228
From: Larry Finger @ 2013-11-01 15:31 UTC (permalink / raw)
To: Ruben De Smet, b43-dev, linux-wireless
In-Reply-To: <52737A9C.3020404@telenet.be>
On 11/01/2013 04:55 AM, Ruben De Smet wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi folks,
>
> I'm currently running Broamcoms prorietary wl drivers, which were
> running fine until I found a bug in the bluetooth part of it, which
> panics the kernel at a certain position.
> I don't know if it's a part in the GPL part of the kernel which
> panics, or if it's in the Broadcom part, as the kernel is tainted by
> the wireless driver and cannot be debugged that way.
>
> lspci shows me this:
> 03:00.0 Network controller: Broadcom Corporation BCM43228 802.11a/b/g/n
>
> My question: will b43 ever support this chip? If so, I'd be able to
> give someone access to this computer for debugging purposes.
> I'd give any help possible, though kernels and modules aren't my
> domain yet.
The short answer is "probably not". The reverse engineering process is very time
consuming and boring. What seems to work best is to find a MIPS driver and
disassemble it to form the kind of "specs" that are seen at
http://bcm-v4.sipsolutions.net/. Next a different person needs to take that
prescription and turn it into code. To preserve the clean-room setting, those
two parts must be done by separate people. The process worked reasonably well
for 802.11g devices, but the code gets very complicated for 802.11n. Further
complicating the issue is that at least one of two BCM43228 units has an LCNXN
PHY, and we have done little with that although the web site shows WIP for that
PHY with a BCM43227. The 2.4 GHz part of the 227 probably matches that of the
228. Note that b43 has never worked well with the 5 GHz radio in any of the chips.
Of course, if the RE is done perfectly, then you end up with all the bugs of wl. :)
One other possibility is that the device might eventually be supported by
brcmsmac. That set of authors has the advantage of having access to the Broadcom
documentation and the wl sources. In case that is a possibility, I added the
linux-wireless mailing list to this reply.
As shown at http://wireless.kernel.org/en/users/Drivers/b43#Supported_devices,
there are two different PCI IDs that are called BCM43228. When you ask this kind
of question, you should include the output of 'lspci -nn' so that the ID is listed.
Larry
^ permalink raw reply
* [PATCH v2 15/23] wireless-regdb: update BG's regulatory rules
From: Luis R. Rodriguez @ 2013-11-01 15:59 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, wireless-regdb, Luis R. Rodriguez
This reduces the 5 GHz max EIRP to 20, enables VHT80
and removes the last 5 GHz DFS frequency range.
Source is QCA's regulatory team's efforts.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
I had forgotten to remove the 5 GHz frequency range.
db.txt | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/db.txt b/db.txt
index de2e94e..09a0164 100644
--- a/db.txt
+++ b/db.txt
@@ -103,9 +103,8 @@ country BE: DFS-ETSI
country BG: DFS-ETSI
(2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 40), (23)
- (5250 - 5290 @ 40), (23), DFS
- (5490 - 5710 @ 40), (30), DFS
+ (5170 - 5250 @ 80), (20)
+ (5250 - 5330 @ 80), (20), DFS
# 60 gHz band channels 1-4, ref: Etsi En 302 567
(57240 - 65880 @ 2160), (40), NO-OUTDOOR
--
1.8.4.rc3
^ permalink raw reply related
* Re: [PATCH 0/8] wireless-regdb: General updates
From: Luis R. Rodriguez @ 2013-11-01 16:04 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless, wireless-regdb@lists.infradead.org,
Luis R. Rodriguez
In-Reply-To: <1383314131-20774-1-git-send-email-mcgrof@do-not-panic.com>
On Fri, Nov 1, 2013 at 2:55 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> The entire delta can be obtained via either a single patch [0]
> or my git tree [1].
Since I provided a patch update fix I pushed the changes to the git
tree and provided a new v2 all-in-one patch [2] as well.
[2] http://drvbp1.linux-foundation.org/~mcgrof/patches/2013/11/01/pending-wireless-regdb-2013-11-01-v2.patch
Luis
^ permalink raw reply
* Re: BCM43228
From: Ruben De Smet @ 2013-11-01 16:00 UTC (permalink / raw)
To: Larry Finger, b43-dev, linux-wireless, brcm80211-dev-list
In-Reply-To: <5273C948.9060409@lwfinger.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/01/2013 04:31 PM, Larry Finger wrote:
>> Hi folks,
>>
>> I'm currently running Broamcoms prorietary wl drivers, which
>> were running fine until I found a bug in the bluetooth part of
>> it, which panics the kernel at a certain position. I don't know
>> if it's a part in the GPL part of the kernel which panics, or if
>> it's in the Broadcom part, as the kernel is tainted by the
>> wireless driver and cannot be debugged that way.
>>
>> lspci shows me this: 03:00.0 Network controller: Broadcom
>> Corporation BCM43228 802.11a/b/g/n
>>
>> My question: will b43 ever support this chip? If so, I'd be able
>> to give someone access to this computer for debugging purposes.
>> I'd give any help possible, though kernels and modules aren't my
>> domain yet.
>
> The short answer is "probably not". The reverse engineering process
> is very time consuming and boring. What seems to work best is to
> find a MIPS driver and disassemble it to form the kind of "specs"
> that are seen at http://bcm-v4.sipsolutions.net/. Next a different
> person needs to take that prescription and turn it into code. To
> preserve the clean-room setting, those two parts must be done by
> separate people. The process worked reasonably well for 802.11g
> devices, but the code gets very complicated for 802.11n. Further
> complicating the issue is that at least one of two BCM43228 units
> has an LCNXN PHY, and we have done little with that although the
> web site shows WIP for that PHY with a BCM43227. The 2.4 GHz part
> of the 227 probably matches that of the 228. Note that b43 has
> never worked well with the 5 GHz radio in any of the chips.
>
> Of course, if the RE is done perfectly, then you end up with all
> the bugs of wl. :)
>
> One other possibility is that the device might eventually be
> supported by brcmsmac. That set of authors has the advantage of
> having access to the Broadcom documentation and the wl sources. In
> case that is a possibility, I added the linux-wireless mailing list
> to this reply.
>
> As shown at
> http://wireless.kernel.org/en/users/Drivers/b43#Supported_devices,
> there are two different PCI IDs that are called BCM43228. When you
> ask this kind of question, you should include the output of 'lspci
> -nn' so that the ID is listed.
>
> Larry
>
AFAIK, broadcom only offers it's drivers for intel x86 and x64_86; I
guess by MIPS, you mean the architecture? (why wouldn't the intel
driver work? Pretty unknown on the subject ;) )
I read the WIP mail about the 227 chip, I could possibly wait for that
one to be released and test it out on mine?
For the record: the issue I'm having is as follows: when connecting
via the bluetooth part of the chip to my phone and using DUN to
connect to the internet, everything works fine until I shut down the
connection. Then my kernel panics. (Another issue of course is the
fact that wl is the only closed source thing in my kernel running atm
on my notebook...)
On brcmsmac: is linux-wireless the right mailinglist to post to then?
I see that the range of supported devices is more close to my chip
than b43 is ;)
I added brcm80211-dev-list@broadcom.com to this mail too, which looks
like the more appropriate mailinglist to post the issue to.
R
PS. snippet of the output of 'lspci -nn':
03:00.0 Network controller [0280]: Broadcom Corporation BCM43228
802.11a/b/g/n [14e4:4359]
Other information on request, will try to answer asap.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSc9AYAAoJEPgmWogSE9wQIGYIAM34w5YzEW3njtkOX0STZf/m
2nDYgORLDgksjQGf7XbSLIn+M7W0u9HMVQXT/aBBxejnSidD/WYIfNLuJddjrGZm
pCl3vO/Z7Px/PI/TBa58MIlV9zZOR/T2dLJmijm7u466AFE23PXT1mJemYzlDNdE
LLykV+Gp6of8uYLzj2GdqVwHEOztdO9x2q5PGVlDiBfIMkqnt1xn6VqFDZdp75Di
viC03tE4HPkN4IIxJbPmZUzBo4L47eRLLJxXAHsVst/sD+YnHkhvEk0yIvSvF3b4
0kZ1jSsDGjryquZ2f4Bvkw8prKS/LyNmPIn8+SaCZ516+C8uUX1e2Z1em2v5DiI=
=Z3eG
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: BCM43228
From: Larry Finger @ 2013-11-01 17:07 UTC (permalink / raw)
To: Ruben De Smet, b43-dev, linux-wireless, brcm80211-dev-list
In-Reply-To: <5273D018.7080607@telenet.be>
On 11/01/2013 11:00 AM, Ruben De Smet wrote:
> AFAIK, broadcom only offers it's drivers for intel x86 and x64_86; I
> guess by MIPS, you mean the architecture? (why wouldn't the intel
> driver work? Pretty unknown on the subject ;) )
>
> I read the WIP mail about the 227 chip, I could possibly wait for that
> one to be released and test it out on mine?
>
> For the record: the issue I'm having is as follows: when connecting
> via the bluetooth part of the chip to my phone and using DUN to
> connect to the internet, everything works fine until I shut down the
> connection. Then my kernel panics. (Another issue of course is the
> fact that wl is the only closed source thing in my kernel running atm
> on my notebook...)
>
> On brcmsmac: is linux-wireless the right mailinglist to post to then?
> I see that the range of supported devices is more close to my chip
> than b43 is ;)
> I added brcm80211-dev-list@broadcom.com to this mail too, which looks
> like the more appropriate mailinglist to post the issue to.
>
> R
>
> PS. snippet of the output of 'lspci -nn':
>
> 03:00.0 Network controller [0280]: Broadcom Corporation BCM43228
> 802.11a/b/g/n [14e4:4359]
>
> Other information on request, will try to answer asap.
The MIPS drivers are part of the codes used in various SoC implementations used
in wireless routers. Disassembling an x86 code stream is much harder than for a
machine like MIPS where all instructions are the same size.
Larry
^ permalink raw reply
* Re: BCM43228
From: Arend van Spriel @ 2013-11-01 17:53 UTC (permalink / raw)
To: Ruben De Smet, Larry Finger, b43-dev, linux-wireless,
brcm80211-dev-list
In-Reply-To: <5273D018.7080607@telenet.be>
On 11/01/2013 05:00 PM, Ruben De Smet wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On 11/01/2013 04:31 PM, Larry Finger wrote:
>>> Hi folks,
>>>
>>> I'm currently running Broamcoms prorietary wl drivers, which
>>> were running fine until I found a bug in the bluetooth part of
>>> it, which panics the kernel at a certain position. I don't know
>>> if it's a part in the GPL part of the kernel which panics, or if
>>> it's in the Broadcom part, as the kernel is tainted by the
>>> wireless driver and cannot be debugged that way.
>>>
>>> lspci shows me this: 03:00.0 Network controller: Broadcom
>>> Corporation BCM43228 802.11a/b/g/n
>>>
>>> My question: will b43 ever support this chip? If so, I'd be able
>>> to give someone access to this computer for debugging purposes.
>>> I'd give any help possible, though kernels and modules aren't my
>>> domain yet.
>>
>> The short answer is "probably not". The reverse engineering process
>> is very time consuming and boring. What seems to work best is to
>> find a MIPS driver and disassemble it to form the kind of "specs"
>> that are seen at http://bcm-v4.sipsolutions.net/. Next a different
>> person needs to take that prescription and turn it into code. To
>> preserve the clean-room setting, those two parts must be done by
>> separate people. The process worked reasonably well for 802.11g
>> devices, but the code gets very complicated for 802.11n. Further
>> complicating the issue is that at least one of two BCM43228 units
>> has an LCNXN PHY, and we have done little with that although the
>> web site shows WIP for that PHY with a BCM43227. The 2.4 GHz part
>> of the 227 probably matches that of the 228. Note that b43 has
>> never worked well with the 5 GHz radio in any of the chips.
>>
>> Of course, if the RE is done perfectly, then you end up with all
>> the bugs of wl. :)
>>
>> One other possibility is that the device might eventually be
>> supported by brcmsmac. That set of authors has the advantage of
>> having access to the Broadcom documentation and the wl sources. In
>> case that is a possibility, I added the linux-wireless mailing list
>> to this reply.
>>
>> As shown at
>> http://wireless.kernel.org/en/users/Drivers/b43#Supported_devices,
>> there are two different PCI IDs that are called BCM43228. When you
>> ask this kind of question, you should include the output of 'lspci
>> -nn' so that the ID is listed.
>>
>> Larry
>>
>
> AFAIK, broadcom only offers it's drivers for intel x86 and x64_86; I
> guess by MIPS, you mean the architecture? (why wouldn't the intel
> driver work? Pretty unknown on the subject ;) )
>
> I read the WIP mail about the 227 chip, I could possibly wait for that
> one to be released and test it out on mine?
>
> For the record: the issue I'm having is as follows: when connecting
> via the bluetooth part of the chip to my phone and using DUN to
> connect to the internet, everything works fine until I shut down the
> connection. Then my kernel panics. (Another issue of course is the
> fact that wl is the only closed source thing in my kernel running atm
> on my notebook...)
>
> On brcmsmac: is linux-wireless the right mailinglist to post to then?
> I see that the range of supported devices is more close to my chip
> than b43 is ;)
> I added brcm80211-dev-list@broadcom.com to this mail too, which looks
> like the more appropriate mailinglist to post the issue to.
Let me chime in on this. We always keep taps on linux-wireless so you
are always right to post there. I created the brcm80211-dev-list so
people can post their issues there regardless changes in the dev team.
So address brcm80211 issues to brcm80211-dev-list and Cc the
linux-wireless list. As a bonus that assures they are publicly archived.
Regards,
Arend
> R
>
> PS. snippet of the output of 'lspci -nn':
>
> 03:00.0 Network controller [0280]: Broadcom Corporation BCM43228
> 802.11a/b/g/n [14e4:4359]
>
> Other information on request, will try to answer asap.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJSc9AYAAoJEPgmWogSE9wQIGYIAM34w5YzEW3njtkOX0STZf/m
> 2nDYgORLDgksjQGf7XbSLIn+M7W0u9HMVQXT/aBBxejnSidD/WYIfNLuJddjrGZm
> pCl3vO/Z7Px/PI/TBa58MIlV9zZOR/T2dLJmijm7u466AFE23PXT1mJemYzlDNdE
> LLykV+Gp6of8uYLzj2GdqVwHEOztdO9x2q5PGVlDiBfIMkqnt1xn6VqFDZdp75Di
> viC03tE4HPkN4IIxJbPmZUzBo4L47eRLLJxXAHsVst/sD+YnHkhvEk0yIvSvF3b4
> 0kZ1jSsDGjryquZ2f4Bvkw8prKS/LyNmPIn8+SaCZ516+C8uUX1e2Z1em2v5DiI=
> =Z3eG
> -----END PGP SIGNATURE-----
>
^ permalink raw reply
* Re: BCM43228
From: Ruben De Smet @ 2013-11-01 18:09 UTC (permalink / raw)
To: Larry Finger, b43-dev, linux-wireless, brcm80211-dev-list
In-Reply-To: <5273DFC6.8000305@lwfinger.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/01/2013 06:07 PM, Larry Finger wrote:
> On 11/01/2013 11:00 AM, Ruben De Smet wrote:
>> AFAIK, broadcom only offers it's drivers for intel x86 and
>> x64_86; I guess by MIPS, you mean the architecture? (why wouldn't
>> the intel driver work? Pretty unknown on the subject ;) )
>>
>> I read the WIP mail about the 227 chip, I could possibly wait for
>> that one to be released and test it out on mine?
>>
>> For the record: the issue I'm having is as follows: when
>> connecting via the bluetooth part of the chip to my phone and
>> using DUN to connect to the internet, everything works fine until
>> I shut down the connection. Then my kernel panics. (Another issue
>> of course is the fact that wl is the only closed source thing in
>> my kernel running atm on my notebook...)
>>
>> On brcmsmac: is linux-wireless the right mailinglist to post to
>> then? I see that the range of supported devices is more close to
>> my chip than b43 is ;) I added brcm80211-dev-list@broadcom.com to
>> this mail too, which looks like the more appropriate mailinglist
>> to post the issue to.
>>
>> R
>>
>> PS. snippet of the output of 'lspci -nn':
>>
>> 03:00.0 Network controller [0280]: Broadcom Corporation BCM43228
>> 802.11a/b/g/n [14e4:4359]
>>
>> Other information on request, will try to answer asap.
>
> The MIPS drivers are part of the codes used in various SoC
> implementations used in wireless routers. Disassembling an x86
> code stream is much harder than for a machine like MIPS where all
> instructions are the same size.
>
> Larry
>
>
AFAIK this chip won't be incorporated in routers nor access points.
As Arend van Spriel stated in a followup mail, I'll keep
brcm80211-dev-list@broadcom.com in the To field.
Any chance that the brcm80211 team knows something on this topic? For
what I feel here, they are the people who will be closest to the issue.
Thank you for your time.
R
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSc+5SAAoJEPgmWogSE9wQau4IALRlKUQ3VpSjaX6/wgr2pY7X
d0pyHGCXVQAdKsvJoyIXqGAfpqRNM7jMsaZlP0ZEAwy0klq4Muh288UrF4SJGeHo
ZJx4j3AZhvu4bZrlWUc0tede0V1pe2Cughy6QIpgUwZdNli+FHpYsLXl+ktk2wR4
KQvUYzhB+09/YRSUgaGhbF+uR0XfW6uqK32NE8+hWjZF1VgGj7mZJd7ApYjbGTq/
91sOUM92F6JSFRGx9skCUwf0M/XhzCG+1w/vcw8eN7rbLqIh+GNYFhzhMC35xfjW
cENvCZ9hi0UyQQ+scPwbmQRHhwqsavN6Wk0irJdst6JxMML2jDjHsVAJR/vGTFk=
=drMC
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH v2 1/3] mac80211_hwsim: use debugfs_remove_recursive
From: Janusz Dziedzic @ 2013-11-01 19:35 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Janusz Dziedzic
Use debugfs_remove_recursive. That avoids the need
for the new dentry pointers and extra debugfs_remove
calls.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
---
drivers/net/wireless/mac80211_hwsim.c | 16 +++++-----------
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 1f49330..cb6b98e 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -352,7 +352,6 @@ struct mac80211_hwsim_data {
} ps;
bool ps_poll_pending;
struct dentry *debugfs;
- struct dentry *debugfs_ps;
struct sk_buff_head pending; /* packets pending */
/*
@@ -361,7 +360,6 @@ struct mac80211_hwsim_data {
* radio can be in more then one group.
*/
u64 group;
- struct dentry *debugfs_group;
int power_level;
@@ -1713,9 +1711,7 @@ static void mac80211_hwsim_free(void)
spin_unlock_bh(&hwsim_radio_lock);
list_for_each_entry_safe(data, tmpdata, &tmplist, list) {
- debugfs_remove(data->debugfs_group);
- debugfs_remove(data->debugfs_ps);
- debugfs_remove(data->debugfs);
+ debugfs_remove_recursive(data->debugfs);
ieee80211_unregister_hw(data->hw);
device_release_driver(data->dev);
device_unregister(data->dev);
@@ -2511,12 +2507,10 @@ static int __init init_mac80211_hwsim(void)
data->debugfs = debugfs_create_dir("hwsim",
hw->wiphy->debugfsdir);
- data->debugfs_ps = debugfs_create_file("ps", 0666,
- data->debugfs, data,
- &hwsim_fops_ps);
- data->debugfs_group = debugfs_create_file("group", 0666,
- data->debugfs, data,
- &hwsim_fops_group);
+ debugfs_create_file("ps", 0666, data->debugfs, data,
+ &hwsim_fops_ps);
+ debugfs_create_file("group", 0666, data->debugfs, data,
+ &hwsim_fops_group);
tasklet_hrtimer_init(&data->beacon_timer,
mac80211_hwsim_beacon,
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/3] mac80211_hwsim: Add iface comb for DFS
From: Janusz Dziedzic @ 2013-11-01 19:35 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Janusz Dziedzic
In-Reply-To: <1383334560-10672-1-git-send-email-janusz.dziedzic@tieto.com>
Add iface combination that will allow DFS
support. Add also debugfs dfs_simulate_radar
file that can be used to simulate radar event.
This could be useful for mac80211/cfg80211/
regulatory/hostap code testing without real HW.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
---
drivers/net/wireless/mac80211_hwsim.c | 46 +++++++++++++++++++++++++++------
1 file changed, 38 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index cb6b98e..085d165 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -1868,6 +1868,17 @@ static int hwsim_fops_ps_write(void *dat, u64 val)
DEFINE_SIMPLE_ATTRIBUTE(hwsim_fops_ps, hwsim_fops_ps_read, hwsim_fops_ps_write,
"%llu\n");
+static int hwsim_write_simulate_radar(void *dat, u64 val)
+{
+ struct mac80211_hwsim_data *data = dat;
+
+ ieee80211_radar_detected(data->hw);
+
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(hwsim_simulate_radar, NULL,
+ hwsim_write_simulate_radar, "%llu\n");
static int hwsim_fops_group_read(void *dat, u64 *val)
{
@@ -2169,11 +2180,28 @@ static const struct ieee80211_iface_limit hwsim_if_limits[] = {
{ .max = 1, .types = BIT(NL80211_IFTYPE_P2P_DEVICE) },
};
-static struct ieee80211_iface_combination hwsim_if_comb = {
- .limits = hwsim_if_limits,
- .n_limits = ARRAY_SIZE(hwsim_if_limits),
- .max_interfaces = 2048,
- .num_different_channels = 1,
+static const struct ieee80211_iface_limit hwsim_if_dfs_limits[] = {
+ { .max = 8, .types = BIT(NL80211_IFTYPE_AP) },
+};
+
+static struct ieee80211_iface_combination hwsim_if_comb[] = {
+ {
+ .limits = hwsim_if_limits,
+ .n_limits = ARRAY_SIZE(hwsim_if_limits),
+ .max_interfaces = 2048,
+ .num_different_channels = 1,
+ },
+ {
+ .limits = hwsim_if_dfs_limits,
+ .n_limits = ARRAY_SIZE(hwsim_if_dfs_limits),
+ .max_interfaces = 8,
+ .num_different_channels = 1,
+ .radar_detect_widths = BIT(NL80211_CHAN_WIDTH_20_NOHT) |
+ BIT(NL80211_CHAN_WIDTH_20) |
+ BIT(NL80211_CHAN_WIDTH_40) |
+ BIT(NL80211_CHAN_WIDTH_80) |
+ BIT(NL80211_CHAN_WIDTH_160),
+ }
};
static int __init init_mac80211_hwsim(void)
@@ -2191,7 +2219,7 @@ static int __init init_mac80211_hwsim(void)
return -EINVAL;
if (channels > 1) {
- hwsim_if_comb.num_different_channels = channels;
+ hwsim_if_comb[0].num_different_channels = channels;
mac80211_hwsim_ops.hw_scan = mac80211_hwsim_hw_scan;
mac80211_hwsim_ops.cancel_hw_scan =
mac80211_hwsim_cancel_hw_scan;
@@ -2271,8 +2299,8 @@ static int __init init_mac80211_hwsim(void)
hw->wiphy->n_addresses = 2;
hw->wiphy->addresses = data->addresses;
- hw->wiphy->iface_combinations = &hwsim_if_comb;
- hw->wiphy->n_iface_combinations = 1;
+ hw->wiphy->iface_combinations = hwsim_if_comb;
+ hw->wiphy->n_iface_combinations = ARRAY_SIZE(hwsim_if_comb);
if (channels > 1) {
hw->wiphy->max_scan_ssids = 255;
@@ -2511,6 +2539,8 @@ static int __init init_mac80211_hwsim(void)
&hwsim_fops_ps);
debugfs_create_file("group", 0666, data->debugfs, data,
&hwsim_fops_group);
+ debugfs_create_file("dfs_simulate_radar", 0222, data->debugfs,
+ data, &hwsim_simulate_radar);
tasklet_hrtimer_init(&data->beacon_timer,
mac80211_hwsim_beacon,
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 3/3] mac80211_hwsim: VHT add 160MHz width support
From: Janusz Dziedzic @ 2013-11-01 19:36 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Janusz Dziedzic
In-Reply-To: <1383334560-10672-1-git-send-email-janusz.dziedzic@tieto.com>
Add 160MHz width support. This could be
usefull for testing VHT160 and DFS functionality.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
---
drivers/net/wireless/mac80211_hwsim.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 085d165..1d4e3e3 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -2387,6 +2387,7 @@ static int __init init_mac80211_hwsim(void)
sband->vht_cap.cap =
IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454 |
IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ |
+ IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ |
IEEE80211_VHT_CAP_RXLDPC |
IEEE80211_VHT_CAP_SHORT_GI_80 |
IEEE80211_VHT_CAP_SHORT_GI_160 |
--
1.7.9.5
^ permalink raw reply related
* [PATCH] ath9k: DFS radar use correct width enum
From: Janusz Dziedzic @ 2013-11-01 19:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Janusz Dziedzic
Use correct width enums when setup
radar_detect_widths for DFS.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
---
drivers/net/wireless/ath/ath9k/init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index eac8f6d..beeb8d4 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -776,8 +776,8 @@ static const struct ieee80211_iface_combination if_comb[] = {
.max_interfaces = 1,
.num_different_channels = 1,
.beacon_int_infra_match = true,
- .radar_detect_widths = BIT(NL80211_CHAN_NO_HT) |
- BIT(NL80211_CHAN_HT20),
+ .radar_detect_widths = BIT(NL80211_CHAN_WIDTH_20_NOHT) |
+ BIT(NL80211_CHAN_WIDTH_20),
}
};
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 6/8] wireless-regdb: optimize two of DE's rules
From: Johannes Berg @ 2013-11-01 19:41 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless, wireless-regdb
In-Reply-To: <1383314131-20774-7-git-send-email-mcgrof@do-not-panic.com>
On Fri, 2013-11-01 at 14:55 +0100, Luis R. Rodriguez wrote:
> - # entry 303005
> - (5150 - 5250 @ 80), (100 mW), NO-OUTDOOR
> - # entries 304002 and 305002
> - (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR
> + # entry 303005, 304002 and 305002
should probably say entries :)
Btw, according to the formal definition that the kernel uses, having two
versus one rule actually *is* different. Having two stops you from using
a channel that crosses the boundary. In practice, this kind of
interpretation is actually cumbersome and error-prone, which I've
pointed out long ago together with my suggestion to actually change it,
but I wanted to point it out anyway.
johannes
^ permalink raw reply
* [PATCH] ath9k: dfs_debug fix possible NULL dereference
From: Janusz Dziedzic @ 2013-11-01 20:05 UTC (permalink / raw)
To: linux-wireless; +Cc: Janusz Dziedzic
Fix possible NULL (sc->dfs_detector) pointer dereference.
Detected by Smatch:
drivers/net/wireless/ath/ath9k/dfs_debug.c:67 read_file_dfs()
error: we previously assumed 'sc->dfs_detector' could be null (see line 47)
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
---
drivers/net/wireless/ath/ath9k/dfs_debug.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/dfs_debug.c b/drivers/net/wireless/ath/ath9k/dfs_debug.c
index 36cd82f..df00061 100644
--- a/drivers/net/wireless/ath/ath9k/dfs_debug.c
+++ b/drivers/net/wireless/ath/ath9k/dfs_debug.c
@@ -44,14 +44,20 @@ static ssize_t read_file_dfs(struct file *file, char __user *user_buf,
if (buf == NULL)
return -ENOMEM;
- if (sc->dfs_detector)
- dfs_pool_stats = sc->dfs_detector->get_stats(sc->dfs_detector);
-
len += snprintf(buf + len, size - len, "DFS support for "
"macVersion = 0x%x, macRev = 0x%x: %s\n",
hw_ver->macVersion, hw_ver->macRev,
(sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_DFS) ?
"enabled" : "disabled");
+
+ if (!sc->dfs_detector) {
+ len += snprintf(buf + len, size - len,
+ "DFS detector not enabled\n");
+ goto exit;
+ }
+
+ dfs_pool_stats = sc->dfs_detector->get_stats(sc->dfs_detector);
+
len += snprintf(buf + len, size - len, "Pulse detector statistics:\n");
ATH9K_DFS_STAT("pulse events reported ", pulses_total);
ATH9K_DFS_STAT("invalid pulse events ", pulses_no_dfs);
@@ -75,6 +81,7 @@ static ssize_t read_file_dfs(struct file *file, char __user *user_buf,
ATH9K_DFS_POOL_STAT("Seqs. alloc error ", pseq_alloc_error);
ATH9K_DFS_POOL_STAT("Seqs. in use ", pseq_used);
+exit:
if (len > size)
len = size;
--
1.7.9.5
^ permalink raw reply related
* Re: BUG in rfcomm_sock_getsockopt+0x128/0x200
From: Janusz Dziedzic @ 2013-11-01 20:27 UTC (permalink / raw)
To: Fabio Rossi
Cc: marcel, linux-wireless@vger.kernel.org Wireless,
linux-bluetooth@vger.kernel.org development
In-Reply-To: <607082335.2055771383319324985.JavaMail.defaultUser@defaultHost>
2013/11/1 Fabio Rossi <rossi.f@inwind.it>:
>>what socket option is your client program setting? Do you happen to know that.
> Would make it a lot easier to track this down.
>
> Hi Marcel,
> I'm using the bluetoothd daemon at startup and it crashes as soon as the
> dongle is inserted. To test the behaviour I removed the dongle and restart the
> daemon with
>
> # bluetoothd -n -d
>
> bluetoothd[4450]: Bluetooth daemon 4.101
> bluetoothd[4450]: src/main.c:parse_config() parsing main.conf
> bluetoothd[4450]: src/main.c:parse_config() discovto=0
> bluetoothd[4450]: src/main.c:parse_config() pairto=0
> bluetoothd[4450]: src/main.c:parse_config() pageto=8192
> bluetoothd[4450]: src/main.c:parse_config() auto_to=60
> bluetoothd[4450]: src/main.c:parse_config() name=%h-%d
> bluetoothd[4450]: src/main.c:parse_config() class=0x000100
> bluetoothd[4450]: src/main.c:parse_config() Key file does not have key
> 'DeviceID'
> bluetoothd[4450]: Starting SDP server
> bluetoothd[4450]: src/plugin.c:plugin_init() Loading builtin plugins
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading pnat plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading audio plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading input plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading serial plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading network plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading service plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading health plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading hciops plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading mgmtops plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading formfactor plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading storage plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading adaptername plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading wiimote plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading maemo6 plugin
> bluetoothd[4450]: src/plugin.c:plugin_init() Loading plugins
> /usr/lib64/bluetooth/plugins
> bluetoothd[4450]: plugins/service.c:register_interface() path
> /org/bluez/4450/any
> bluetoothd[4450]: plugins/service.c:register_interface() Registered interface
> org.bluez.Service on path /org/bluez/4450/any
> bluetoothd[4450]: plugins/maemo6.c:maemo6_init() init maemo6 plugin
> bluetoothd[4450]: health/hdp.c:hdp_manager_start() Starting Health manager
> bluetoothd[4450]: network/manager.c:read_config() /etc/bluetooth/network.conf:
> Key file does not have key 'DisableSecurity'
> bluetoothd[4450]: network/manager.c:read_config() Config options:
> Security=true
> bluetoothd[4450]: input/manager.c:input_manager_init() input.conf: Key file
> does not have key 'IdleTimeout'
> bluetoothd[4450]: audio/manager.c:audio_manager_init() audio.conf: Key file
> does not have key 'AutoConnect'
> bluetoothd[4450]: plugins/pnat.c:pnat_init() Setup Phonet AT (DUN) plugin
> bluetoothd[4450]: plugins/hciops.c:hciops_init()
> bluetoothd[4450]: Bluetooth Management interface initialized
> bluetoothd[4450]: Failed to open RFKILL control device
> bluetoothd[4450]: src/main.c:main() Entering main loop
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 12 bytes from
> management socket
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_cmd_complete()
> bluetoothd[4450]: plugins/mgmtops.c:read_version_complete() version 1 revision
> 4
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 11 bytes from
> management socket
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_cmd_complete()
>
> then I insert the dongle
>
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 6 bytes from
> management socket
> bluetoothd[4450]: plugins/mgmtops.c:add_controller() Added controller 0
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 289 bytes from
> management socket
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_cmd_complete()
> bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 addr 00:09:DD:XX:
> XX:XX version 3 manufacturer 10 class 0x000000
> bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 settings
> bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 name CSR - bc4
> bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 short name
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_remove_uuid() index 0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=1
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_read_bdaddr() index 0 addr 00:09:DD:
> XX:XX:XX
> bluetoothd[4450]: src/sdpd-database.c:sdp_init_services_list()
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_add_uuid() index 0
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_add_uuid() index 0
> bluetoothd[4450]: plugins/service.c:register_interface() path
> /org/bluez/4450/hci0
> bluetoothd[4450]: plugins/service.c:register_interface() Registered interface
> org.bluez.Service on path /org/bluez/4450/hci0
> bluetoothd[4450]: plugins/maemo6.c:mce_probe() path /org/bluez/4450/hci0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=2
> bluetoothd[4450]: network/manager.c:network_server_probe() path
> /org/bluez/4450/hci0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=3
> bluetoothd[4450]: network/server.c:server_register() Registered interface org.
> bluez.NetworkServer on path /org/bluez/4450/hci0
> bluetoothd[4450]: serial/manager.c:proxy_probe() path /org/bluez/4450/hci0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=4
> bluetoothd[4450]: serial/proxy.c:proxy_register() Registered interface org.
> bluez.SerialProxyManager on path /org/bluez/4450/hci0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=5
> bluetoothd[4450]: audio/manager.c:media_server_probe() path
> /org/bluez/4450/hci0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=6
> bluetoothd[4450]: audio/manager.c:audio_adapter_ref() 0x7f6c1794b2b0: ref=1
> bluetoothd[4450]: audio/manager.c:headset_server_probe() path
> /org/bluez/4450/hci0
> bluetoothd[4450]: audio/manager.c:audio_adapter_ref() 0x7f6c1794b2b0: ref=2
> bluetoothd[4450]: audio/manager.c:headset_server_init() audio.conf: Key file
> does not have key 'Master'
> Killed
>
> and I get the crash previously reported. If I use a working kernel the
> bluetooth daemon continues its startup and the next lines are
>
> bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Adding record with
> handle 0x10000
> bluetoothd[2322]: plugins/mgmtops.c:mgmt_add_uuid() index
> 0
> bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
> UUID 00000003-0000-1000-8000-00805f9
> bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
> UUID 00000100-0000-1000-8000-00805f9
> bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
> UUID 00001002-0000-1000-8000-00805f9
> bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
> UUID 00001108-0000-1000-8000-00805f9
> bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
> UUID 00001112-0000-1000-8000-00805f9
> bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
> UUID 00001203-0000-1000-8000-00805f9
> ... [ omitted ] ...
>
> Furthermore, comparing bluetoothd logs (working vs not working kernel) I have
> noticed the following difference:
>
> bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 addr 00:09:DD:XX:
> XX:XX version 3 manufacturer 10 class 0x000000
> bluetoothd[2322]: plugins/mgmtops.c:read_info_complete() hci0 addr 00:09:DD:XX:
> XX:XX version 3 manufacturer 10 class 0x5a0100
>
> so it seems the class is not properly initialized.
>
> The kernel is configured with
>
> CONFIG_BT=y
> CONFIG_BT_RFCOMM=y
> CONFIG_BT_RFCOMM_TTY=y
> CONFIG_BT_BNEP=y
> CONFIG_BT_HIDP=y
> CONFIG_BT_HCIBTUSB=y
> CONFIG_BT_HCIUART=y
>
> Let me know if I can help providing more info.
>
I see the same problem and same dump during laptop startup (Ubuntu 12.04 LTS).
As a workaround I had to disable BT in bios (Dell E4300) and remove
ar3k firmware (have two BT devices).
BR
Janusz
^ permalink raw reply
* Re: [PATCH 54/65] wireless-regdb: extend 5 GHz range for AR
From: Paul Stewart @ 2013-11-01 21:06 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: John Linville, linux-wireless, wireless-regdb
In-Reply-To: <1383314275-20960-55-git-send-email-mcgrof@do-not-panic.com>
I'd caution you to take a look at
http://www.productcompliancespecialists.eu/wp-content/uploads/2013/10/Regulatory_Update_Argentina_01-Oct-2013_Rev1.pdf
On Fri, Nov 1, 2013 at 6:57 AM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> Source is QCA's regulatory team's efforts.
>
> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
> ---
> db.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/db.txt b/db.txt
> index 10a7194..70b0b9d 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -46,7 +46,7 @@ country AR: DFS-FCC
> (2402 - 2482 @ 40), (20)
> (5170 - 5250 @ 80), (17)
> (5250 - 5330 @ 80), (24), DFS
> - (5490 - 5710 @ 80), (24), DFS
> + (5490 - 5730 @ 80), (24), DFS
> (5735 - 5835 @ 80), (30)
>
> country AT: DFS-ETSI
> --
> 1.8.4.rc3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: BUG in rfcomm_sock_getsockopt+0x128/0x200
From: Marcel Holtmann @ 2013-11-01 21:39 UTC (permalink / raw)
To: Fabio Rossi
Cc: linux-wireless@vger.kernel.org Wireless,
linux-bluetooth@vger.kernel.org development
In-Reply-To: <607082335.2055771383319324985.JavaMail.defaultUser@defaultHost>
Hi Fabio,
>> what socket option is your client program setting? Do you happen to know that.
> Would make it a lot easier to track this down.
>
> Hi Marcel,
> I'm using the bluetoothd daemon at startup and it crashes as soon as the
> dongle is inserted. To test the behaviour I removed the dongle and restart the
> daemon with
>
> # bluetoothd -n -d
>
> bluetoothd[4450]: Bluetooth daemon 4.101
> bluetoothd[4450]: src/main.c:parse_config() parsing main.conf
> bluetoothd[4450]: src/main.c:parse_config() discovto=0
> bluetoothd[4450]: src/main.c:parse_config() pairto=0
> bluetoothd[4450]: src/main.c:parse_config() pageto=8192
> bluetoothd[4450]: src/main.c:parse_config() auto_to=60
> bluetoothd[4450]: src/main.c:parse_config() name=%h-%d
> bluetoothd[4450]: src/main.c:parse_config() class=0x000100
> bluetoothd[4450]: src/main.c:parse_config() Key file does not have key
> 'DeviceID'
> bluetoothd[4450]: Starting SDP server
> bluetoothd[4450]: src/plugin.c:plugin_init() Loading builtin plugins
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading pnat plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading audio plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading input plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading serial plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading network plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading service plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading health plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading hciops plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading mgmtops plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading formfactor plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading storage plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading adaptername plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading wiimote plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading maemo6 plugin
> bluetoothd[4450]: src/plugin.c:plugin_init() Loading plugins
> /usr/lib64/bluetooth/plugins
> bluetoothd[4450]: plugins/service.c:register_interface() path
> /org/bluez/4450/any
> bluetoothd[4450]: plugins/service.c:register_interface() Registered interface
> org.bluez.Service on path /org/bluez/4450/any
> bluetoothd[4450]: plugins/maemo6.c:maemo6_init() init maemo6 plugin
> bluetoothd[4450]: health/hdp.c:hdp_manager_start() Starting Health manager
> bluetoothd[4450]: network/manager.c:read_config() /etc/bluetooth/network.conf:
> Key file does not have key 'DisableSecurity'
> bluetoothd[4450]: network/manager.c:read_config() Config options:
> Security=true
> bluetoothd[4450]: input/manager.c:input_manager_init() input.conf: Key file
> does not have key 'IdleTimeout'
> bluetoothd[4450]: audio/manager.c:audio_manager_init() audio.conf: Key file
> does not have key 'AutoConnect'
> bluetoothd[4450]: plugins/pnat.c:pnat_init() Setup Phonet AT (DUN) plugin
> bluetoothd[4450]: plugins/hciops.c:hciops_init()
> bluetoothd[4450]: Bluetooth Management interface initialized
> bluetoothd[4450]: Failed to open RFKILL control device
> bluetoothd[4450]: src/main.c:main() Entering main loop
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 12 bytes from
> management socket
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_cmd_complete()
> bluetoothd[4450]: plugins/mgmtops.c:read_version_complete() version 1 revision
> 4
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 11 bytes from
> management socket
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_cmd_complete()
>
> then I insert the dongle
>
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 6 bytes from
> management socket
> bluetoothd[4450]: plugins/mgmtops.c:add_controller() Added controller 0
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 289 bytes from
> management socket
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_cmd_complete()
> bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 addr 00:09:DD:XX:
> XX:XX version 3 manufacturer 10 class 0x000000
> bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 settings
> bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 name CSR - bc4
> bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 short name
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_remove_uuid() index 0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=1
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_read_bdaddr() index 0 addr 00:09:DD:
> XX:XX:XX
> bluetoothd[4450]: src/sdpd-database.c:sdp_init_services_list()
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_add_uuid() index 0
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_add_uuid() index 0
> bluetoothd[4450]: plugins/service.c:register_interface() path
> /org/bluez/4450/hci0
> bluetoothd[4450]: plugins/service.c:register_interface() Registered interface
> org.bluez.Service on path /org/bluez/4450/hci0
> bluetoothd[4450]: plugins/maemo6.c:mce_probe() path /org/bluez/4450/hci0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=2
> bluetoothd[4450]: network/manager.c:network_server_probe() path
> /org/bluez/4450/hci0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=3
> bluetoothd[4450]: network/server.c:server_register() Registered interface org.
> bluez.NetworkServer on path /org/bluez/4450/hci0
> bluetoothd[4450]: serial/manager.c:proxy_probe() path /org/bluez/4450/hci0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=4
> bluetoothd[4450]: serial/proxy.c:proxy_register() Registered interface org.
> bluez.SerialProxyManager on path /org/bluez/4450/hci0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=5
> bluetoothd[4450]: audio/manager.c:media_server_probe() path
> /org/bluez/4450/hci0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=6
> bluetoothd[4450]: audio/manager.c:audio_adapter_ref() 0x7f6c1794b2b0: ref=1
> bluetoothd[4450]: audio/manager.c:headset_server_probe() path
> /org/bluez/4450/hci0
> bluetoothd[4450]: audio/manager.c:audio_adapter_ref() 0x7f6c1794b2b0: ref=2
> bluetoothd[4450]: audio/manager.c:headset_server_init() audio.conf: Key file
> does not have key 'Master'
> Killed
>
> and I get the crash previously reported. If I use a working kernel the
> bluetooth daemon continues its startup and the next lines are
can you quickly test a kernel build from bluetooth-next tree. I would like to see if that crashes as well. Since I have been running that one for weeks and never saw this bug.
Regards
Marcel
^ permalink raw reply
* Interaction with new naming scheme for wireless devices
From: Larry Finger @ 2013-11-02 0:04 UTC (permalink / raw)
To: linux-wireless
When I allow the system to name wifi devices using the new-style names like
wlp0s2f1u, it is not possible to make a connection after unloading and reloading
the driver. A reboot is necessary. If I modify
/etc/udev/rules.d/70-persistent-net.rules to force the name to be wlanX, I can
reconnect again after a unload/reload cycle.
Has anyone seen this behavior? Any suggestions?
Larry
^ permalink raw reply
* Re: BUG in rfcomm_sock_getsockopt+0x128/0x200
From: Fabio Rossi @ 2013-11-02 1:12 UTC (permalink / raw)
To: marcel
Cc: linux-wireless@vger.kernel.org Wireless,
linux-bluetooth@vger.kernel.org development
>can you quickly test a kernel build from bluetooth-next tree. I would like to
see if that crashes as well. Since I have been running that one for weeks and
never saw this bug.
>
>Regards
>
>Marcel
Hi Marcel,
here is the same problem with bluetooth-next.git
BUG: unable to handle kernel paging request at 00000009dd503502
IP: [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
PGD 0
Oops: 0000 [#1] SMP
Modules linked in: ath5k ath mac80211 cfg80211
CPU: 2 PID: 1459 Comm: bluetoothd Not tainted 3.11.0-133163-gcebd830 #2
Hardware name: System manufacturer System Product Name/P6T DELUXE V2, BIOS
1202 12/22/2010
task: ffff8803304106a0 ti: ffff88033046a000 task.ti: ffff88033046a000
RIP: 0010:[<ffffffff815b1868>] [<ffffffff815b1868>]
rfcomm_sock_getsockopt+0x128/0x200
RSP: 0018:ffff88033046bed8 EFLAGS: 00010246
RAX: 00000009dd503502 RBX: 0000000000000003 RCX: 00007fffa2ed5548
RDX: 0000000000000003 RSI: 0000000000000012 RDI: ffff88032fd37480
RBP: ffff88033046bf28 R08: 00007fffa2ed554c R09: ffff88032f5707d8
R10: 00007fffa2ed5548 R11: 0000000000000202 R12: ffff880330bbd000
R13: 00007fffa2ed5548 R14: 0000000000000003 R15: 00007fffa2ed554c
FS: 00007fc44cfac700(0000) GS:ffff88033fc80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000009dd503502 CR3: 00000003304c2000 CR4: 00000000000007e0
Stack:
ffff88033046bf28 ffffffff815b0f2f ffff88033046bf18 0002ffff81105ef6
0000000600000000 ffff88032fd37480 0000000000000012 00007fffa2ed5548
0000000000000003 00007fffa2ed554c ffff88033046bf78 ffffffff814c0380
Call Trace:
[<ffffffff815b0f2f>] ? rfcomm_sock_setsockopt+0x5f/0x190
[<ffffffff814c0380>] SyS_getsockopt+0x60/0xb0
[<ffffffff815e0852>] system_call_fastpath+0x16/0x1b
Code: 02 00 00 00 0f 47 d0 4c 89 ef e8 74 13 cd ff 83 f8 01 19 c9 f7 d1 83 e1
f2 e9 4b ff ff ff 0f 1f 44 00 00 49 8b 84 24 70 02 00 00 <4c> 8b 30 4c 89 c0 e8
2d 19 cd ff 85 c0 49 89 d7 b9 f2 ff ff ff
RIP [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
RSP <ffff88033046bed8>
CR2: 00000009dd503502
---[ end trace 719ace9ee57b7a58 ]---
Regards,
Fabio
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox