Hello,
As you probably know, in the current Linux kernel there is a staging
driver for the RTL8187SE device (based on my older RTL8180/RTL8185
Linux driver), while there also a regular (not staging) driver
supporting older RTL8185 and RTL8180 devices
(net/wireless/rtl818x/rtl8180) .
As far as I can see, the RTL8187SE device seems not so much different
from an RTL8185 device.
I would like to try (in my spare time) to add support for RTL8187SE
device in the current RTL818x driver, in order to avoid code
duplication, remove a driver from staging, and make RTL8187SE using
mac80211.
Do any one of you have any comment/objection/suggestions about this ?
Is it possible to get the RTL8187SE documentation to make things easier?
For now I will probably keep different RF code for the two cards even
if the RTL8225 (zebra 2) radio is used by both RTL8187SE and some
RTL8185 devices, however if I could get enough documentation about it,
it would be great to try to merge also RF code..
Thank you,
Andrea
On Tue, Sep 10, 2013 at 05:59:54PM +0200, Andrea Merello wrote:
> Hello,
>
> As you probably know, in the current Linux kernel there is a staging
> driver for the RTL8187SE device (based on my older RTL8180/RTL8185
> Linux driver), while there also a regular (not staging) driver
> supporting older RTL8185 and RTL8180 devices
> (net/wireless/rtl818x/rtl8180) .
>
> As far as I can see, the RTL8187SE device seems not so much different
> from an RTL8185 device.
> I would like to try (in my spare time) to add support for RTL8187SE
> device in the current RTL818x driver, in order to avoid code
> duplication, remove a driver from staging, and make RTL8187SE using
> mac80211.
>
> Do any one of you have any comment/objection/suggestions about this ?
I would be extremely happy for you to tackle this.
> Is it possible to get the RTL8187SE documentation to make things easier?
This info used to be readily available. If you can't find a source, I
probably still have a (mildly useful) datasheet somewhere in my heap...
> For now I will probably keep different RF code for the two cards even
> if the RTL8225 (zebra 2) radio is used by both RTL8187SE and some
> RTL8185 devices, however if I could get enough documentation about it,
> it would be great to try to merge also RF code..
>
> Thank you,
> Andrea
Seems reasonable...
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
Thanks for your code and for documentation!
I see you did your work in a new net/wireless/rtl818x/rtl8187se
directory and you produced a new driver.
Now I have to evaluate whether to keep doing it in this way, trying to
continue your work, or to merge support in
net/wireless/rtl818x/rtl8180 code, that was my original idea..
Now that I have documentation I can better evaluate how much the two
boards are similar..
Andrea
On Tue, Sep 10, 2013 at 7:35 PM, Larry Finger <[email protected]> wrote:
> On 09/10/2013 10:59 AM, Andrea Merello wrote:
>>
>> Hello,
>>
>> As you probably know, in the current Linux kernel there is a staging
>> driver for the RTL8187SE device (based on my older RTL8180/RTL8185
>> Linux driver), while there also a regular (not staging) driver
>> supporting older RTL8185 and RTL8180 devices
>> (net/wireless/rtl818x/rtl8180) .
>>
>> As far as I can see, the RTL8187SE device seems not so much different
>> from an RTL8185 device.
>> I would like to try (in my spare time) to add support for RTL8187SE
>> device in the current RTL818x driver, in order to avoid code
>> duplication, remove a driver from staging, and make RTL8187SE using
>> mac80211.
>>
>> Do any one of you have any comment/objection/suggestions about this ?
>>
>> Is it possible to get the RTL8187SE documentation to make things easier?
>>
>> For now I will probably keep different RF code for the two cards even
>> if the RTL8225 (zebra 2) radio is used by both RTL8187SE and some
>> RTL8185 devices, however if I could get enough documentation about it,
>> it would be great to try to merge also RF code..
>
>
> I too would be very happy for you to do this. At one point, I was trying to
> do this and I had a version that very nearly worked. The driver was
> receiving data and transmitting short packets but failing on longer ones.
> Length 42 was OK, but 68 failed. At that point, the chip locked up and
> needed to be power cycled. It seems that I got the DMA wrong, but I could
> never find it, and eventually, I had to move on.
>
> At the moment, I am working at getting it to build on the current kernel.
> When I finish that, I will send the code to you. Even if you decide to scrap
> it, it may help you a little.
>
> Attached is the datasheet, which is the only documentation I have.
>
> Larry
>
>
On 09/10/2013 10:59 AM, Andrea Merello wrote:
> Hello,
>
> As you probably know, in the current Linux kernel there is a staging
> driver for the RTL8187SE device (based on my older RTL8180/RTL8185
> Linux driver), while there also a regular (not staging) driver
> supporting older RTL8185 and RTL8180 devices
> (net/wireless/rtl818x/rtl8180) .
>
> As far as I can see, the RTL8187SE device seems not so much different
> from an RTL8185 device.
> I would like to try (in my spare time) to add support for RTL8187SE
> device in the current RTL818x driver, in order to avoid code
> duplication, remove a driver from staging, and make RTL8187SE using
> mac80211.
>
> Do any one of you have any comment/objection/suggestions about this ?
>
> Is it possible to get the RTL8187SE documentation to make things easier?
>
> For now I will probably keep different RF code for the two cards even
> if the RTL8225 (zebra 2) radio is used by both RTL8187SE and some
> RTL8185 devices, however if I could get enough documentation about it,
> it would be great to try to merge also RF code..
I too would be very happy for you to do this. At one point, I was trying to do
this and I had a version that very nearly worked. The driver was receiving data
and transmitting short packets but failing on longer ones. Length 42 was OK, but
68 failed. At that point, the chip locked up and needed to be power cycled. It
seems that I got the DMA wrong, but I could never find it, and eventually, I had
to move on.
At the moment, I am working at getting it to build on the current kernel. When I
finish that, I will send the code to you. Even if you decide to scrap it, it may
help you a little.
Attached is the datasheet, which is the only documentation I have.
Larry
Hello Bernhard,
Are you still curious to test something ? :)
I attach a patch that should apply to wireless-testing..
I still have several items pending on my TODO list, including things
to tidy/fix, and things that are currently missing, however I'm
getting encouraging results on my setup..
If this works for you, and if other people in CC here agree, I may
starting split this mega-patch in something more suitable for kernel
maintainers to merge (currently it even changes few misleading names
in the common register struct, affecting also rtl8187 driver)..
Let me know if it works :)
Andrea
On 01/15/2014 11:22 AM, Andrea Merello wrote:
> Hello,
> Thank you for testing!
>
> This is interesting:
> I ever worked on this patch on an older wireless-testing tree, that
> gave me no oops after lot of time.
>
> Yesterday, before sending you my patch, I ported it to a newer
> wireless-testing, and I did just a quick compile/load test.
> But today I got panic me too with the new kernel...
>
> I have a serial console over I could capture the the oops..
> I will look at this issue in next days...
>
> 86509.384436] divide error: 0000 [#1] PREEMPT SMP
> [86509.387743] Modules linked in: rtl8180(O) mac80211 cfbfillrect
> cfbimgblt cfbcopyarea drm_kms_helper cfg80211 ttm [last unloaded:
> rtl8180]
> [86509.399253] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O
> 3.13.0-rc7-wl+ #16
> [86509.399253] Hardware name: System manufacturer System Product
> Name/M3N78 PRO, BIOS ASUS M3N78 PRO ACPI BIOS Revision 1402 12/04/2009
> [86509.399253] task: ffffffff81c10460 ti: ffffffff81c00000 task.ti:
> ffffffff81c00000
> [86509.428032] RIP: 0010:[<ffffffffa00fdac2>] [<ffffffffa00fdac2>]
> ieee80211_bss_info_update+0x1c2/0x350 [mac80211]
> [86509.433405] RSP: 0018:ffff88006fc03cb8 EFLAGS: 00010202
> [86509.441368] RAX: 00000000000003e8 RBX: ffff88006fc03d08 RCX: 0000000000000077
> [86509.451441] RDX: 0000000000000000 RSI: ffff880068aa97b0 RDI: 0000000000000000
> [86509.451441] RBP: ffff88006fc03cf8 R08: ffff88006fc03d08 R09: 000000000000000a
> [86509.464969] R10: ffff88006fc03d08 R11: 0000000000000000 R12: ffff880068a93300
> [86509.464969] R13: ffff88006c2db628 R14: ffff880068a93301 R15: ffff880068aa84c0
> [86509.478134] FS: 00007f413fab8800(0000) GS:ffff88006fc00000(0000)
> knlGS:0000000000000000
> [86509.488032] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [86509.489400] CR2: 00007f413eedbfc9 CR3: 0000000001c0b000 CR4: 00000000000007f0
> [86509.494704] Stack:
> [86509.494704] 0000000000000000 0000000000000000 0000000020000000
> ffff88006c2db600
> [86509.494704] ffff880068a93300 ffff880068aa84c0 ffff880068a93300
> ffff880068aa9ac0
> [86509.494704] ffff88006fc03e38 ffffffffa00fdd8e ffff880068a93324
> 0000000000000053
> [86509.494704] Call Trace:
> [86509.494704] <IRQ>
> [86509.494704] [<ffffffffa00fdd8e>] ieee80211_scan_rx+0x13e/0x1a0 [mac80211]
> [86509.494704] [<ffffffffa0114ff0>] ieee80211_rx+0x700/0x7c0 [mac80211]
> [86509.494704] [<ffffffffa00f6119>]
> ieee80211_tasklet_handler+0xb9/0xc0 [mac80211]
> [86509.494704] [<ffffffff8106b3c7>] tasklet_action+0xa7/0xb0
> [86509.494704] [<ffffffff8106b7fd>] __do_softirq+0xcd/0x1d0
> [86509.494704] [<ffffffff8106bba6>] irq_exit+0x76/0xa0
> [86509.494704] [<ffffffff81032dde>] do_IRQ+0x5e/0xd0
> [86509.494704] [<ffffffff817210ea>] common_interrupt+0x6a/0x6a
> [86509.494704] <EOI>
> [86509.494704] [<ffffffff81039198>] ? amd_e400_idle+0x68/0xe0
> [86509.494704] [<ffffffff810398c6>] arch_cpu_idle+0x16/0x20
> [86509.494704] [<ffffffff810a0d6d>] cpu_startup_entry+0x11d/0x170
> [86509.494704] [<ffffffff8171344f>] rest_init+0x7f/0x90
> [86509.494704] [<ffffffff81cb0d63>] start_kernel+0x307/0x313
> [86509.494704] [<ffffffff81cb0865>] ? repair_env_string+0x5c/0x5c
> [86509.494704] [<ffffffff81cb05a3>] x86_64_start_reservations+0x2a/0x2c
> [86509.494704] [<ffffffff81cb066c>] x86_64_start_kernel+0xc7/0xca
> [86509.494704] Code: 5e 41 5f 5d c3 0f 1f 40 00 45 31 c9 83 e7 20 0f
> 84 9f fe ff ff 45 0f be 4d 21 bf 64 00 00 00 44 89 c8 0f af c7 41 0f
> be 7f 74 99 <f7> ff 41 89 c1 e9 7f fe ff ff 0
> [86509.494704] RIP [<ffffffffa00fdac2>]
> ieee80211_bss_info_update+0x1c2/0x350 [mac80211]
> [86509.494704] RSP <ffff88006fc03cb8>
> [86509.654701] ---[ end trace 08e0a7abe35b1caf ]---
> [86509.661368] Kernel panic - not syncing: Fatal exception in interrupt
The divide fault occurs because hw.max_signal was not set in line 75 of
net/mac80211/scan.c. The failing line is
signal = (rx_status->signal * 100) / local->hw.max_signal;
I have not yet looked to see where that info comes from in the driver.
Larry
Hello,
Thank you for testing!
This is interesting:
I ever worked on this patch on an older wireless-testing tree, that
gave me no oops after lot of time.
Yesterday, before sending you my patch, I ported it to a newer
wireless-testing, and I did just a quick compile/load test.
But today I got panic me too with the new kernel...
I have a serial console over I could capture the the oops..
I will look at this issue in next days...
86509.384436] divide error: 0000 [#1] PREEMPT SMP
[86509.387743] Modules linked in: rtl8180(O) mac80211 cfbfillrect
cfbimgblt cfbcopyarea drm_kms_helper cfg80211 ttm [last unloaded:
rtl8180]
[86509.399253] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O
3.13.0-rc7-wl+ #16
[86509.399253] Hardware name: System manufacturer System Product
Name/M3N78 PRO, BIOS ASUS M3N78 PRO ACPI BIOS Revision 1402 12/04/2009
[86509.399253] task: ffffffff81c10460 ti: ffffffff81c00000 task.ti:
ffffffff81c00000
[86509.428032] RIP: 0010:[<ffffffffa00fdac2>] [<ffffffffa00fdac2>]
ieee80211_bss_info_update+0x1c2/0x350 [mac80211]
[86509.433405] RSP: 0018:ffff88006fc03cb8 EFLAGS: 00010202
[86509.441368] RAX: 00000000000003e8 RBX: ffff88006fc03d08 RCX: 0000000000000077
[86509.451441] RDX: 0000000000000000 RSI: ffff880068aa97b0 RDI: 0000000000000000
[86509.451441] RBP: ffff88006fc03cf8 R08: ffff88006fc03d08 R09: 000000000000000a
[86509.464969] R10: ffff88006fc03d08 R11: 0000000000000000 R12: ffff880068a93300
[86509.464969] R13: ffff88006c2db628 R14: ffff880068a93301 R15: ffff880068aa84c0
[86509.478134] FS: 00007f413fab8800(0000) GS:ffff88006fc00000(0000)
knlGS:0000000000000000
[86509.488032] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[86509.489400] CR2: 00007f413eedbfc9 CR3: 0000000001c0b000 CR4: 00000000000007f0
[86509.494704] Stack:
[86509.494704] 0000000000000000 0000000000000000 0000000020000000
ffff88006c2db600
[86509.494704] ffff880068a93300 ffff880068aa84c0 ffff880068a93300
ffff880068aa9ac0
[86509.494704] ffff88006fc03e38 ffffffffa00fdd8e ffff880068a93324
0000000000000053
[86509.494704] Call Trace:
[86509.494704] <IRQ>
[86509.494704] [<ffffffffa00fdd8e>] ieee80211_scan_rx+0x13e/0x1a0 [mac80211]
[86509.494704] [<ffffffffa0114ff0>] ieee80211_rx+0x700/0x7c0 [mac80211]
[86509.494704] [<ffffffffa00f6119>]
ieee80211_tasklet_handler+0xb9/0xc0 [mac80211]
[86509.494704] [<ffffffff8106b3c7>] tasklet_action+0xa7/0xb0
[86509.494704] [<ffffffff8106b7fd>] __do_softirq+0xcd/0x1d0
[86509.494704] [<ffffffff8106bba6>] irq_exit+0x76/0xa0
[86509.494704] [<ffffffff81032dde>] do_IRQ+0x5e/0xd0
[86509.494704] [<ffffffff817210ea>] common_interrupt+0x6a/0x6a
[86509.494704] <EOI>
[86509.494704] [<ffffffff81039198>] ? amd_e400_idle+0x68/0xe0
[86509.494704] [<ffffffff810398c6>] arch_cpu_idle+0x16/0x20
[86509.494704] [<ffffffff810a0d6d>] cpu_startup_entry+0x11d/0x170
[86509.494704] [<ffffffff8171344f>] rest_init+0x7f/0x90
[86509.494704] [<ffffffff81cb0d63>] start_kernel+0x307/0x313
[86509.494704] [<ffffffff81cb0865>] ? repair_env_string+0x5c/0x5c
[86509.494704] [<ffffffff81cb05a3>] x86_64_start_reservations+0x2a/0x2c
[86509.494704] [<ffffffff81cb066c>] x86_64_start_kernel+0xc7/0xca
[86509.494704] Code: 5e 41 5f 5d c3 0f 1f 40 00 45 31 c9 83 e7 20 0f
84 9f fe ff ff 45 0f be 4d 21 bf 64 00 00 00 44 89 c8 0f af c7 41 0f
be 7f 74 99 <f7> ff 41 89 c1 e9 7f fe ff ff 0
[86509.494704] RIP [<ffffffffa00fdac2>]
ieee80211_bss_info_update+0x1c2/0x350 [mac80211]
[86509.494704] RSP <ffff88006fc03cb8>
[86509.654701] ---[ end trace 08e0a7abe35b1caf ]---
[86509.661368] Kernel panic - not syncing: Fatal exception in interrupt
On Wed, Jan 15, 2014 at 5:11 PM, Larry Finger <[email protected]> wrote:
> Andrea,
>
> Just a head's up, but I had a kernel panic overnight. This kernel (3.13-rc7
> from wireless testing) has been stable - the only thing new is the
> RTL8187SE. I have no diagnostic information other than the blinking console
> lights. If/when I get more info, I'll let you know.
>
> Larry
>
should be
+ (hw->max_signal < 0),
I'm sorry, I did something wrong in my git commit
On Wed, Jan 15, 2014 at 7:41 PM, Andrea Merello
<[email protected]> wrote:
> Thank you.
>
> The driver tries to set this in rtl8180_probe, line 2140
> dev->max_signal = 65;
>
> I have no idea yet if this will be overwritten somewhere other or
> whatever else..
>
> In this case maybe the value become corrupted later on, after mac80211
> initialization, BTW, what about making mac80211 robust to at least
> wrong initialization?
> Simulating a initialization to zero, the following patch will triggers
> also lot of other WARN_ON because of broken signal information, but
> should avoid the panic..
>
> BTW Currently i'm not able to reproduce the rtl8187se bug anymore :(
>
> From cdc000007a1226b9daaab2d8354aab55127c1fb4 Mon Sep 17 00:00:00 2001
> From: andrea merello <[email protected]>
> Date: Wed, 15 Jan 2014 19:17:25 +0100
> Subject: [PATCH] MAC80211: Issue a WARN and prevent divide by zero when
> max_signal is not set
>
> if the driver sets IEEE80211_HW_SIGNAL_UNSPEC, then mac80211 tries to
> perform a division by max_signal while scanning.
>
> Print a warn and set a dummy value.
> This should result is wrong signal information but avoid a crash.
> ---
> net/mac80211/main.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/net/mac80211/main.c b/net/mac80211/main.c
> index d767cfb..449c417 100644
> --- a/net/mac80211/main.c
> +++ b/net/mac80211/main.c
> @@ -753,6 +753,11 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
> netdev_features_t feature_whitelist;
> struct cfg80211_chan_def dflt_chandef = {};
>
> + if (WARN((hw->flags & IEEE80211_HW_SIGNAL_UNSPEC) &&
> + (hw->max_signal < 0),
> + "max_signal not set while set IEEE80211_HW_SIGNAL_UNSPEC\n"))
> + hw->max_signal = 1;
> +
> if (hw->flags & IEEE80211_HW_QUEUE_CONTROL &&
> (local->hw.offchannel_tx_hw_queue == IEEE80211_INVAL_HW_QUEUE ||
> local->hw.offchannel_tx_hw_queue >= local->hw.queues))
> --
> 1.8.3.2
>
>
>
>
>
> On Wed, Jan 15, 2014 at 6:42 PM, Larry Finger <[email protected]> wrote:
>> On 01/15/2014 11:22 AM, Andrea Merello wrote:
>>>
>>> Hello,
>>> Thank you for testing!
>>>
>>> This is interesting:
>>> I ever worked on this patch on an older wireless-testing tree, that
>>> gave me no oops after lot of time.
>>>
>>> Yesterday, before sending you my patch, I ported it to a newer
>>> wireless-testing, and I did just a quick compile/load test.
>>> But today I got panic me too with the new kernel...
>>>
>>> I have a serial console over I could capture the the oops..
>>> I will look at this issue in next days...
>>>
>>> 86509.384436] divide error: 0000 [#1] PREEMPT SMP
>>> [86509.387743] Modules linked in: rtl8180(O) mac80211 cfbfillrect
>>> cfbimgblt cfbcopyarea drm_kms_helper cfg80211 ttm [last unloaded:
>>> rtl8180]
>>> [86509.399253] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O
>>> 3.13.0-rc7-wl+ #16
>>> [86509.399253] Hardware name: System manufacturer System Product
>>> Name/M3N78 PRO, BIOS ASUS M3N78 PRO ACPI BIOS Revision 1402 12/04/2009
>>> [86509.399253] task: ffffffff81c10460 ti: ffffffff81c00000 task.ti:
>>> ffffffff81c00000
>>> [86509.428032] RIP: 0010:[<ffffffffa00fdac2>] [<ffffffffa00fdac2>]
>>> ieee80211_bss_info_update+0x1c2/0x350 [mac80211]
>>> [86509.433405] RSP: 0018:ffff88006fc03cb8 EFLAGS: 00010202
>>> [86509.441368] RAX: 00000000000003e8 RBX: ffff88006fc03d08 RCX:
>>> 0000000000000077
>>> [86509.451441] RDX: 0000000000000000 RSI: ffff880068aa97b0 RDI:
>>> 0000000000000000
>>> [86509.451441] RBP: ffff88006fc03cf8 R08: ffff88006fc03d08 R09:
>>> 000000000000000a
>>> [86509.464969] R10: ffff88006fc03d08 R11: 0000000000000000 R12:
>>> ffff880068a93300
>>> [86509.464969] R13: ffff88006c2db628 R14: ffff880068a93301 R15:
>>> ffff880068aa84c0
>>> [86509.478134] FS: 00007f413fab8800(0000) GS:ffff88006fc00000(0000)
>>> knlGS:0000000000000000
>>> [86509.488032] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>> [86509.489400] CR2: 00007f413eedbfc9 CR3: 0000000001c0b000 CR4:
>>> 00000000000007f0
>>> [86509.494704] Stack:
>>> [86509.494704] 0000000000000000 0000000000000000 0000000020000000
>>> ffff88006c2db600
>>> [86509.494704] ffff880068a93300 ffff880068aa84c0 ffff880068a93300
>>> ffff880068aa9ac0
>>> [86509.494704] ffff88006fc03e38 ffffffffa00fdd8e ffff880068a93324
>>> 0000000000000053
>>> [86509.494704] Call Trace:
>>> [86509.494704] <IRQ>
>>> [86509.494704] [<ffffffffa00fdd8e>] ieee80211_scan_rx+0x13e/0x1a0
>>> [mac80211]
>>> [86509.494704] [<ffffffffa0114ff0>] ieee80211_rx+0x700/0x7c0 [mac80211]
>>> [86509.494704] [<ffffffffa00f6119>]
>>> ieee80211_tasklet_handler+0xb9/0xc0 [mac80211]
>>> [86509.494704] [<ffffffff8106b3c7>] tasklet_action+0xa7/0xb0
>>> [86509.494704] [<ffffffff8106b7fd>] __do_softirq+0xcd/0x1d0
>>> [86509.494704] [<ffffffff8106bba6>] irq_exit+0x76/0xa0
>>> [86509.494704] [<ffffffff81032dde>] do_IRQ+0x5e/0xd0
>>> [86509.494704] [<ffffffff817210ea>] common_interrupt+0x6a/0x6a
>>> [86509.494704] <EOI>
>>> [86509.494704] [<ffffffff81039198>] ? amd_e400_idle+0x68/0xe0
>>> [86509.494704] [<ffffffff810398c6>] arch_cpu_idle+0x16/0x20
>>> [86509.494704] [<ffffffff810a0d6d>] cpu_startup_entry+0x11d/0x170
>>> [86509.494704] [<ffffffff8171344f>] rest_init+0x7f/0x90
>>> [86509.494704] [<ffffffff81cb0d63>] start_kernel+0x307/0x313
>>> [86509.494704] [<ffffffff81cb0865>] ? repair_env_string+0x5c/0x5c
>>> [86509.494704] [<ffffffff81cb05a3>] x86_64_start_reservations+0x2a/0x2c
>>> [86509.494704] [<ffffffff81cb066c>] x86_64_start_kernel+0xc7/0xca
>>> [86509.494704] Code: 5e 41 5f 5d c3 0f 1f 40 00 45 31 c9 83 e7 20 0f
>>> 84 9f fe ff ff 45 0f be 4d 21 bf 64 00 00 00 44 89 c8 0f af c7 41 0f
>>> be 7f 74 99 <f7> ff 41 89 c1 e9 7f fe ff ff 0
>>> [86509.494704] RIP [<ffffffffa00fdac2>]
>>> ieee80211_bss_info_update+0x1c2/0x350 [mac80211]
>>> [86509.494704] RSP <ffff88006fc03cb8>
>>> [86509.654701] ---[ end trace 08e0a7abe35b1caf ]---
>>> [86509.661368] Kernel panic - not syncing: Fatal exception in interrupt
>>
>>
>> The divide fault occurs because hw.max_signal was not set in line 75 of
>> net/mac80211/scan.c. The failing line is
>>
>> signal = (rx_status->signal * 100) / local->hw.max_signal;
>>
>> I have not yet looked to see where that info comes from in the driver.
>>
>> Larry
>>
>>
>>
Larry,
Currently I'm struggling trying to reproduce the panic again..
Unfortunately it is working without problems now..
When it happened to you, was the RTL8187SE associated to any AP ? was
there network traffic flowing ?
Do you have done some other test ? do you have had more panics ?
Any more information about that panic is really welcome..
Jumping back to your older mail, about your note on compile warning of
rtl8187 driver, I have verified that In rtl8187 reference sources I
have, the register is really accessed as 8 bit wide, while in the
rtl8187se reference code (staging linux driver indeed) it is accessed
in 16 bit way.
I don't have a big endian system me too to test if uniforming to 16bit
brokes thing, but:
Despite I suspect the two ASIC have the same MAC and the same AFE, and
that one of the two reference code is wrong, I can't know which one,
so I'm thinking about keeping the common register struct as it is, and
avoiding modify the rtl8187 driver about this, while eventually I will
stick to the 16 bit access on the rtl8187se using a raw cast..
Better ideas are welcome :)
Thanks
Andrea
Thank you
Andrea
On Wed, Jan 15, 2014 at 5:11 PM, Larry Finger <[email protected]> wrote:
> Andrea,
>
> Just a head's up, but I had a kernel panic overnight. This kernel (3.13-rc7
> from wireless testing) has been stable - the only thing new is the
> RTL8187SE. I have no diagnostic information other than the blinking console
> lights. If/when I get more info, I'll let you know.
>
> Larry
>
On 01/15/2014 12:43 PM, Andrea Merello wrote:
> should be
> + (hw->max_signal < 0),
>
> I'm sorry, I did something wrong in my git commit
I would have expected <= 0. It is the zero value that causes the divide fault.
Larry
On 01/14/2014 11:40 AM, Andrea Merello wrote:
> Hello Bernhard,
>
> Are you still curious to test something ? :)
> I attach a patch that should apply to wireless-testing..
>
> I still have several items pending on my TODO list, including things
> to tidy/fix, and things that are currently missing, however I'm
> getting encouraging results on my setup..
>
> If this works for you, and if other people in CC here agree, I may
> starting split this mega-patch in something more suitable for kernel
> maintainers to merge (currently it even changes few misleading names
> in the common register struct, affecting also rtl8187 driver)..
>
> Let me know if it works :)
Andrea,
Building your version gets the following warning:
CC [M] drivers/net/wireless/rtl818x/rtl8187/rfkill.o
drivers/net/wireless/rtl818x/rtl8187/dev.c: In function ?rtl8187_set_anaparam?:
drivers/net/wireless/rtl818x/rtl8187/dev.c:596:3: warning: passing argument 2 of
?rtl818x_iowrite8? from incompatible pointer type [enabled by default]
In file included from drivers/net/wireless/rtl818x/rtl8187/dev.c:32:0:
drivers/net/wireless/rtl818x/rtl8187/rtl8187.h:237:20: note: expected ?u8 *? but
argument is of type ?__le16 *?
The easy fix is to change that to an ...iowrite16() call. So far, my testing to
see if writing that extra byte messes up the RTL8187B has not shown any
problems; however, I have not yet tested on a big-endian machine.
Have you given any thought to renaming the driver? It seems to me that rtl8180
was probably not right when it drove both RTL8180 and RTL8185, and it is even
less appropriate today.
The driver connects to the following APs:
802.11n running WPA2
802.11g running WPA1
802.11g running WEP
Looks good.
Larry
Andrea,
Just a head's up, but I had a kernel panic overnight. This kernel (3.13-rc7 from
wireless testing) has been stable - the only thing new is the RTL8187SE. I have
no diagnostic information other than the blinking console lights. If/when I get
more info, I'll let you know.
Larry
Thank you.
The driver tries to set this in rtl8180_probe, line 2140
dev->max_signal = 65;
I have no idea yet if this will be overwritten somewhere other or
whatever else..
In this case maybe the value become corrupted later on, after mac80211
initialization, BTW, what about making mac80211 robust to at least
wrong initialization?
Simulating a initialization to zero, the following patch will triggers
also lot of other WARN_ON because of broken signal information, but
should avoid the panic..
BTW Currently i'm not able to reproduce the rtl8187se bug anymore :(
>From cdc000007a1226b9daaab2d8354aab55127c1fb4 Mon Sep 17 00:00:00 2001
From: andrea merello <[email protected]>
Date: Wed, 15 Jan 2014 19:17:25 +0100
Subject: [PATCH] MAC80211: Issue a WARN and prevent divide by zero when
max_signal is not set
if the driver sets IEEE80211_HW_SIGNAL_UNSPEC, then mac80211 tries to
perform a division by max_signal while scanning.
Print a warn and set a dummy value.
This should result is wrong signal information but avoid a crash.
---
net/mac80211/main.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index d767cfb..449c417 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -753,6 +753,11 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
netdev_features_t feature_whitelist;
struct cfg80211_chan_def dflt_chandef = {};
+ if (WARN((hw->flags & IEEE80211_HW_SIGNAL_UNSPEC) &&
+ (hw->max_signal < 0),
+ "max_signal not set while set IEEE80211_HW_SIGNAL_UNSPEC\n"))
+ hw->max_signal = 1;
+
if (hw->flags & IEEE80211_HW_QUEUE_CONTROL &&
(local->hw.offchannel_tx_hw_queue == IEEE80211_INVAL_HW_QUEUE ||
local->hw.offchannel_tx_hw_queue >= local->hw.queues))
--
1.8.3.2
On Wed, Jan 15, 2014 at 6:42 PM, Larry Finger <[email protected]> wrote:
> On 01/15/2014 11:22 AM, Andrea Merello wrote:
>>
>> Hello,
>> Thank you for testing!
>>
>> This is interesting:
>> I ever worked on this patch on an older wireless-testing tree, that
>> gave me no oops after lot of time.
>>
>> Yesterday, before sending you my patch, I ported it to a newer
>> wireless-testing, and I did just a quick compile/load test.
>> But today I got panic me too with the new kernel...
>>
>> I have a serial console over I could capture the the oops..
>> I will look at this issue in next days...
>>
>> 86509.384436] divide error: 0000 [#1] PREEMPT SMP
>> [86509.387743] Modules linked in: rtl8180(O) mac80211 cfbfillrect
>> cfbimgblt cfbcopyarea drm_kms_helper cfg80211 ttm [last unloaded:
>> rtl8180]
>> [86509.399253] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O
>> 3.13.0-rc7-wl+ #16
>> [86509.399253] Hardware name: System manufacturer System Product
>> Name/M3N78 PRO, BIOS ASUS M3N78 PRO ACPI BIOS Revision 1402 12/04/2009
>> [86509.399253] task: ffffffff81c10460 ti: ffffffff81c00000 task.ti:
>> ffffffff81c00000
>> [86509.428032] RIP: 0010:[<ffffffffa00fdac2>] [<ffffffffa00fdac2>]
>> ieee80211_bss_info_update+0x1c2/0x350 [mac80211]
>> [86509.433405] RSP: 0018:ffff88006fc03cb8 EFLAGS: 00010202
>> [86509.441368] RAX: 00000000000003e8 RBX: ffff88006fc03d08 RCX:
>> 0000000000000077
>> [86509.451441] RDX: 0000000000000000 RSI: ffff880068aa97b0 RDI:
>> 0000000000000000
>> [86509.451441] RBP: ffff88006fc03cf8 R08: ffff88006fc03d08 R09:
>> 000000000000000a
>> [86509.464969] R10: ffff88006fc03d08 R11: 0000000000000000 R12:
>> ffff880068a93300
>> [86509.464969] R13: ffff88006c2db628 R14: ffff880068a93301 R15:
>> ffff880068aa84c0
>> [86509.478134] FS: 00007f413fab8800(0000) GS:ffff88006fc00000(0000)
>> knlGS:0000000000000000
>> [86509.488032] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [86509.489400] CR2: 00007f413eedbfc9 CR3: 0000000001c0b000 CR4:
>> 00000000000007f0
>> [86509.494704] Stack:
>> [86509.494704] 0000000000000000 0000000000000000 0000000020000000
>> ffff88006c2db600
>> [86509.494704] ffff880068a93300 ffff880068aa84c0 ffff880068a93300
>> ffff880068aa9ac0
>> [86509.494704] ffff88006fc03e38 ffffffffa00fdd8e ffff880068a93324
>> 0000000000000053
>> [86509.494704] Call Trace:
>> [86509.494704] <IRQ>
>> [86509.494704] [<ffffffffa00fdd8e>] ieee80211_scan_rx+0x13e/0x1a0
>> [mac80211]
>> [86509.494704] [<ffffffffa0114ff0>] ieee80211_rx+0x700/0x7c0 [mac80211]
>> [86509.494704] [<ffffffffa00f6119>]
>> ieee80211_tasklet_handler+0xb9/0xc0 [mac80211]
>> [86509.494704] [<ffffffff8106b3c7>] tasklet_action+0xa7/0xb0
>> [86509.494704] [<ffffffff8106b7fd>] __do_softirq+0xcd/0x1d0
>> [86509.494704] [<ffffffff8106bba6>] irq_exit+0x76/0xa0
>> [86509.494704] [<ffffffff81032dde>] do_IRQ+0x5e/0xd0
>> [86509.494704] [<ffffffff817210ea>] common_interrupt+0x6a/0x6a
>> [86509.494704] <EOI>
>> [86509.494704] [<ffffffff81039198>] ? amd_e400_idle+0x68/0xe0
>> [86509.494704] [<ffffffff810398c6>] arch_cpu_idle+0x16/0x20
>> [86509.494704] [<ffffffff810a0d6d>] cpu_startup_entry+0x11d/0x170
>> [86509.494704] [<ffffffff8171344f>] rest_init+0x7f/0x90
>> [86509.494704] [<ffffffff81cb0d63>] start_kernel+0x307/0x313
>> [86509.494704] [<ffffffff81cb0865>] ? repair_env_string+0x5c/0x5c
>> [86509.494704] [<ffffffff81cb05a3>] x86_64_start_reservations+0x2a/0x2c
>> [86509.494704] [<ffffffff81cb066c>] x86_64_start_kernel+0xc7/0xca
>> [86509.494704] Code: 5e 41 5f 5d c3 0f 1f 40 00 45 31 c9 83 e7 20 0f
>> 84 9f fe ff ff 45 0f be 4d 21 bf 64 00 00 00 44 89 c8 0f af c7 41 0f
>> be 7f 74 99 <f7> ff 41 89 c1 e9 7f fe ff ff 0
>> [86509.494704] RIP [<ffffffffa00fdac2>]
>> ieee80211_bss_info_update+0x1c2/0x350 [mac80211]
>> [86509.494704] RSP <ffff88006fc03cb8>
>> [86509.654701] ---[ end trace 08e0a7abe35b1caf ]---
>> [86509.661368] Kernel panic - not syncing: Fatal exception in interrupt
>
>
> The divide fault occurs because hw.max_signal was not set in line 75 of
> net/mac80211/scan.c. The failing line is
>
> signal = (rx_status->signal * 100) / local->hw.max_signal;
>
> I have not yet looked to see where that info comes from in the driver.
>
> Larry
>
>
>