Support for cheap Ralink 3070 WiFi plug #321

martinlbb · 2013-07-02T14:34:03Z

Support for Ralink Media Tek cheap Ralink 3070 WiFi Plug.

Incorrect detection of 3070 chipset.

See http://www.geekamole.com/2013/rt2800usb-fix-for-ralinkmediatek-3070-gentoo-linux/

Support for alink Media Tek cheap Ralink 3070 WiFi Plug. See http://www.geekamole.com/2013/rt2800usb-fix-for-ralinkmediatek-3070-gentoo-linux/

popcornmix · 2013-07-02T18:50:54Z

Please close #322 and on branch patch-2 do:
git add drivers/net/wireless/rt2x00/rt2800.h git commit --amend git push -f
This PR will update with other file.

Support for Ralink Media Tek cheap Ralink 3070 WiFi Plug. Incorrect detection of 3070 chipset. See http://www.geekamole.com/2013/rt2800usb-fix-for-ralinkmediatek-3070-gentoo-linux/

martinlbb · 2013-07-02T20:57:49Z

Ok, I did it. I close #322 and group needed files in the same commit.

Thanks for your help :)

popcornmix · 2013-07-02T21:00:35Z

I suggest "git commit --amend" which would squash the commits together.
Do a
git rebase -i HEAD~2
and squaash the second commit into first, then "git push -f"

shalecraig · 2013-09-04T14:36:39Z

Can someone figure out if this should be merged?

I'd love to use my 3070 without having to compile the kernel myself.

I'd be happy to rebase this myself if you want.

popcornmix · 2013-09-04T16:44:33Z

I'm waiting for @martinlbb to squash the commits together.
The first commit doesn't build without the second, so breaks git bisect, for example.

shalecraig · 2013-09-06T02:45:33Z

Understood/agreed.

I'd love to use my 3070 with raspberry pi (without needing to compile it myself). If it isn't updated by the end of Sunday, would you accept a new pull request that does this?

I haven't built it locally, and I trust @martinlbb's change works. I'd just rather that it's in Raspbian.

martinlbb · 2013-09-06T08:34:32Z

Dear all,

I was stuck on commit/mixing process. Using both git and web service
conducted changes to be a big mess :(

My goal was to share an easy and proved fix, using web site.

Feel free to launch a new pull request (and delete mine), if it can help.

Sorry for all,

Martinlbb

Le 06/09/13 04:45, shalecraig a écrit :

Understood/agreed.

I'd love to use my 3070 with raspberry pi (without needing to compile
it myself). If it isn't updated by the end of Sunday, would you accept
a new pull request that does this?

I haven't built it locally, and I /trust/ @martinlbb
https://github.com/martinlbb's change works. I'd just rather that
it's in Raspbian.

—
Reply to this email directly or view it on GitHub
#321 (comment).

popcornmix · 2013-09-08T16:58:38Z

Added here:
876ddb4
Please try rpi-update and test it works.

shalecraig · 2013-09-09T14:21:45Z

I've run rpi-update with no arguments, but I'm not sure how to verify that I have your change.

Based on ifconfig not showing any new interfaces, and iw list returning nothing at all, I don't think I have it.

For what it's worth, uname -r returns 3.6.11+.

martinlbb · 2013-09-09T17:26:21Z

I all,

I've done a rpi-update.
uname -a:
pi 3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 armv61

After reboot, I recheck (rpi-update told me firmware is up to date).

But, it's the same error (Invalid chipset 0x3070).

dmesg output following:
bcm2708_spi bcm2708_spi.0: master is unqueued, this is deprecated.
bcm2708_spi bcm2708_spi:0: SPI Controller at 0x20204000 (irq 80)
cfg80211: Calling CRDA to update world regulatory domain
phy0 -> rt2800_init_eeprom: Error - Invalid chipset 0x3070 detected.
phy0 -> rt2x00lib_prove_dev: Error - Failed to allocate device.

All the best,

Martinlbb

Le 09/09/13 16:22, shalecraig a écrit :

I've run |rpi-update| with no arguments, but I'm not sure how to
verify that I have your change.

Based on |ifconfig| not showing any new interfaces, and |iw list|
returning nothing at all, I don't think I have it.

For what it's worth, |uname -r| returns |3.6.11+|.

—
Reply to this email directly or view it on GitHub
#321 (comment).

popcornmix · 2013-09-09T18:33:37Z

The latest firmware contains this patch:
876ddb4

which looks like this PR to me. Perhaps this PR isn't sufficient?

shalecraig · 2013-09-11T06:44:50Z

Good News Everyone!

I just ran rpi-update, and iw list returns a ton of stuff.

Based on a quick look, I think that rpi-update pulls from compiled (weekly?) builds on another repo.

dennisjanssen · 2013-09-11T08:44:06Z

Any way to test this on Raspbmc as well? I can't seem to run rpi-update.

martinlbb · 2013-09-11T09:37:55Z

Confirmed :)

I did a rpi-update, and it work oob :)

Adapter is recognize, and fully working (tested with WPA PSK network).

Perfect :)

Shalecraig: you are right, it seems that there is some delay between git
commit and rpi-update availability.

If you're okay, I'll update RPi_USB_Wi-Fi_Adapters wiki page on elinux.

Martinlbb
PS: thanks popcornmix to handle this :)

Le 11/09/2013 08:45, shalecraig a écrit :

Good News Everyone!

I just ran |rpi-update|, and |iw list| returns a ton of stuff.

Based on a quick look, I think that |rpi-update| pulls from compiled
(weekly?) builds on another repo.

—
Reply to this email directly or view it on GitHub
#321 (comment).

See: raspberrypi#321

See: #321

See: raspberrypi#321

See: #321

…offline_kmem() memcg_offline_kmem() may be called from memcg_free_kmem() after a css init failure. memcg_free_kmem() is a ->css_free callback which is called without cgroup_mutex and memcg_offline_kmem() ends up using css_for_each_descendant_pre() without any locking. Fix it by adding rcu read locking around it. mkdir: cannot create directory `65530': No space left on device [ 527.241361] =============================== [ 527.241845] [ INFO: suspicious RCU usage. ] [ 527.242367] 4.6.0-work+ raspberrypi#321 Not tainted [ 527.242730] ------------------------------- [ 527.243220] kernel/cgroup.c:4008 cgroup_mutex or RCU read lock required! [ 527.243970] [ 527.243970] other info that might help us debug this: [ 527.243970] [ 527.244715] [ 527.244715] rcu_scheduler_active = 1, debug_locks = 0 [ 527.245463] 2 locks held by kworker/0:5/1664: [ 527.245939] #0: ("cgroup_destroy"){.+.+..}, at: [<ffffffff81060ab5>] process_one_work+0x165/0x4a0 [ 527.246958] #1: ((&css->destroy_work)#3){+.+...}, at: [<ffffffff81060ab5>] process_one_work+0x165/0x4a0 [ 527.248098] [ 527.248098] stack backtrace: [ 527.249565] CPU: 0 PID: 1664 Comm: kworker/0:5 Not tainted 4.6.0-work+ raspberrypi#321 [ 527.250429] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014 [ 527.250555] Workqueue: cgroup_destroy css_free_work_fn [ 527.250555] 0000000000000000 ffff880178747c68 ffffffff8128bfc7 ffff880178b8ac40 [ 527.250555] 0000000000000001 ffff880178747c98 ffffffff8108c297 0000000000000000 [ 527.250555] ffff88010de54138 000000000000fffb ffff88010de537e8 ffff880178747cc0 [ 527.250555] Call Trace: [ 527.250555] [<ffffffff8128bfc7>] dump_stack+0x68/0xa1 [ 527.250555] [<ffffffff8108c297>] lockdep_rcu_suspicious+0xd7/0x110 [ 527.250555] [<ffffffff810ca03d>] css_next_descendant_pre+0x7d/0xb0 [ 527.250555] [<ffffffff8114d14a>] memcg_offline_kmem.part.44+0x4a/0xc0 [ 527.250555] [<ffffffff8114d3ac>] mem_cgroup_css_free+0x1ec/0x200 [ 527.250555] [<ffffffff810ccdc9>] css_free_work_fn+0x49/0x5e0 [ 527.250555] [<ffffffff81060b15>] process_one_work+0x1c5/0x4a0 [ 527.250555] [<ffffffff81060ab5>] ? process_one_work+0x165/0x4a0 [ 527.250555] [<ffffffff81060e39>] worker_thread+0x49/0x490 [ 527.250555] [<ffffffff81060df0>] ? process_one_work+0x4a0/0x4a0 [ 527.250555] [<ffffffff81060df0>] ? process_one_work+0x4a0/0x4a0 [ 527.250555] [<ffffffff810672ba>] kthread+0xea/0x100 [ 527.250555] [<ffffffff814cbcff>] ret_from_fork+0x1f/0x40 [ 527.250555] [<ffffffff810671d0>] ? kthread_create_on_node+0x200/0x200 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Tejun Heo <[email protected]> Acked-by: Vladimir Davydov <[email protected]> Acked-by: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]>

…offline_kmem() memcg_offline_kmem() may be called from memcg_free_kmem() after a css init failure. memcg_free_kmem() is a ->css_free callback which is called without cgroup_mutex and memcg_offline_kmem() ends up using css_for_each_descendant_pre() without any locking. Fix it by adding rcu read locking around it. mkdir: cannot create directory `65530': No space left on device =============================== [ INFO: suspicious RCU usage. ] 4.6.0-work+ #321 Not tainted ------------------------------- kernel/cgroup.c:4008 cgroup_mutex or RCU read lock required! [ 527.243970] other info that might help us debug this: [ 527.244715] rcu_scheduler_active = 1, debug_locks = 0 2 locks held by kworker/0:5/1664: #0: ("cgroup_destroy"){.+.+..}, at: [<ffffffff81060ab5>] process_one_work+0x165/0x4a0 #1: ((&css->destroy_work)#3){+.+...}, at: [<ffffffff81060ab5>] process_one_work+0x165/0x4a0 [ 527.248098] stack backtrace: CPU: 0 PID: 1664 Comm: kworker/0:5 Not tainted 4.6.0-work+ #321 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014 Workqueue: cgroup_destroy css_free_work_fn Call Trace: dump_stack+0x68/0xa1 lockdep_rcu_suspicious+0xd7/0x110 css_next_descendant_pre+0x7d/0xb0 memcg_offline_kmem.part.44+0x4a/0xc0 mem_cgroup_css_free+0x1ec/0x200 css_free_work_fn+0x49/0x5e0 process_one_work+0x1c5/0x4a0 worker_thread+0x49/0x490 kthread+0xea/0x100 ret_from_fork+0x1f/0x40 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Tejun Heo <[email protected]> Acked-by: Vladimir Davydov <[email protected]> Acked-by: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Cc: <[email protected]> [4.5+] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>

…offline_kmem() commit 3a06bb7 upstream. memcg_offline_kmem() may be called from memcg_free_kmem() after a css init failure. memcg_free_kmem() is a ->css_free callback which is called without cgroup_mutex and memcg_offline_kmem() ends up using css_for_each_descendant_pre() without any locking. Fix it by adding rcu read locking around it. mkdir: cannot create directory `65530': No space left on device =============================== [ INFO: suspicious RCU usage. ] 4.6.0-work+ #321 Not tainted ------------------------------- kernel/cgroup.c:4008 cgroup_mutex or RCU read lock required! [ 527.243970] other info that might help us debug this: [ 527.244715] rcu_scheduler_active = 1, debug_locks = 0 2 locks held by kworker/0:5/1664: #0: ("cgroup_destroy"){.+.+..}, at: [<ffffffff81060ab5>] process_one_work+0x165/0x4a0 #1: ((&css->destroy_work)#3){+.+...}, at: [<ffffffff81060ab5>] process_one_work+0x165/0x4a0 [ 527.248098] stack backtrace: CPU: 0 PID: 1664 Comm: kworker/0:5 Not tainted 4.6.0-work+ #321 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014 Workqueue: cgroup_destroy css_free_work_fn Call Trace: dump_stack+0x68/0xa1 lockdep_rcu_suspicious+0xd7/0x110 css_next_descendant_pre+0x7d/0xb0 memcg_offline_kmem.part.44+0x4a/0xc0 mem_cgroup_css_free+0x1ec/0x200 css_free_work_fn+0x49/0x5e0 process_one_work+0x1c5/0x4a0 worker_thread+0x49/0x490 kthread+0xea/0x100 ret_from_fork+0x1f/0x40 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Tejun Heo <[email protected]> Acked-by: Vladimir Davydov <[email protected]> Acked-by: Johannes Weiner <[email protected]> Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e8c220f upstream. Since commit e1ab9a4 ("i2c: imx: improve the error handling in i2c_imx_dma_request()") when booting with the DMA driver as module (such as CONFIG_FSL_EDMA=m) the following endless clk warnings are seen: [ 153.077831] ------------[ cut here ]------------ [ 153.082528] WARNING: CPU: 0 PID: 15 at drivers/clk/clk.c:924 clk_core_disable_lock+0x18/0x24 [ 153.093077] i2c0 already disabled [ 153.096416] Modules linked in: [ 153.099521] CPU: 0 PID: 15 Comm: kworker/0:1 Tainted: G W 5.2.0+ #321 [ 153.107290] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree) [ 153.113772] Workqueue: events deferred_probe_work_func [ 153.118979] [<c0019560>] (unwind_backtrace) from [<c0014734>] (show_stack+0x10/0x14) [ 153.126778] [<c0014734>] (show_stack) from [<c083f8dc>] (dump_stack+0x9c/0xd4) [ 153.134051] [<c083f8dc>] (dump_stack) from [<c0031154>] (__warn+0xf8/0x124) [ 153.141056] [<c0031154>] (__warn) from [<c0031248>] (warn_slowpath_fmt+0x38/0x48) [ 153.148580] [<c0031248>] (warn_slowpath_fmt) from [<c040fde0>] (clk_core_disable_lock+0x18/0x24) [ 153.157413] [<c040fde0>] (clk_core_disable_lock) from [<c058f520>] (i2c_imx_probe+0x554/0x6ec) [ 153.166076] [<c058f520>] (i2c_imx_probe) from [<c04b9178>] (platform_drv_probe+0x48/0x98) [ 153.174297] [<c04b9178>] (platform_drv_probe) from [<c04b7298>] (really_probe+0x1d8/0x2c0) [ 153.182605] [<c04b7298>] (really_probe) from [<c04b7554>] (driver_probe_device+0x5c/0x174) [ 153.190909] [<c04b7554>] (driver_probe_device) from [<c04b58c8>] (bus_for_each_drv+0x44/0x8c) [ 153.199480] [<c04b58c8>] (bus_for_each_drv) from [<c04b746c>] (__device_attach+0xa0/0x108) [ 153.207782] [<c04b746c>] (__device_attach) from [<c04b65a4>] (bus_probe_device+0x88/0x90) [ 153.215999] [<c04b65a4>] (bus_probe_device) from [<c04b6a04>] (deferred_probe_work_func+0x60/0x90) [ 153.225003] [<c04b6a04>] (deferred_probe_work_func) from [<c004f190>] (process_one_work+0x204/0x634) [ 153.234178] [<c004f190>] (process_one_work) from [<c004f618>] (worker_thread+0x20/0x484) [ 153.242315] [<c004f618>] (worker_thread) from [<c0055c2c>] (kthread+0x118/0x150) [ 153.249758] [<c0055c2c>] (kthread) from [<c00090b4>] (ret_from_fork+0x14/0x20) [ 153.257006] Exception stack(0xdde43fb0 to 0xdde43ff8) [ 153.262095] 3fa0: 00000000 00000000 00000000 00000000 [ 153.270306] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 153.278520] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 153.285159] irq event stamp: 3323022 [ 153.288787] hardirqs last enabled at (3323021): [<c0861c4c>] _raw_spin_unlock_irq+0x24/0x2c [ 153.297261] hardirqs last disabled at (3323022): [<c040d7a0>] clk_enable_lock+0x10/0x124 [ 153.305392] softirqs last enabled at (3322092): [<c000a504>] __do_softirq+0x344/0x540 [ 153.313352] softirqs last disabled at (3322081): [<c00385c0>] irq_exit+0x10c/0x128 [ 153.320946] ---[ end trace a506731ccd9bd703 ]--- This endless clk warnings behaviour is well explained by Andrey Smirnov: "Allocating DMA after registering I2C adapter can lead to infinite probing loop, for example, consider the following scenario: 1. i2c_imx_probe() is called and successfully registers an I2C adapter via i2c_add_numbered_adapter() 2. As a part of i2c_add_numbered_adapter() new I2C slave devices are added from DT which results in a call to driver_deferred_probe_trigger() 3. i2c_imx_probe() continues and calls i2c_imx_dma_request() which due to lack of proper DMA driver returns -EPROBE_DEFER 4. i2c_imx_probe() fails, removes I2C adapter and returns -EPROBE_DEFER, which places it into deferred probe list 5. Deferred probe work triggered in #2 above kicks in and calls i2c_imx_probe() again thus bringing us to step #1" So revert commit e1ab9a4 ("i2c: imx: improve the error handling in i2c_imx_dma_request()") and restore the old behaviour, in order to avoid regressions on existing setups. Cc: <[email protected]> Reported-by: Andrey Smirnov <[email protected]> Reported-by: Russell King <[email protected]> Fixes: e1ab9a4 ("i2c: imx: improve the error handling in i2c_imx_dma_request()") Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

Since commit e1ab9a4 ("i2c: imx: improve the error handling in i2c_imx_dma_request()") when booting with the DMA driver as module (such as CONFIG_FSL_EDMA=m) the following endless clk warnings are seen: [ 153.077831] ------------[ cut here ]------------ [ 153.082528] WARNING: CPU: 0 PID: 15 at drivers/clk/clk.c:924 clk_core_disable_lock+0x18/0x24 [ 153.093077] i2c0 already disabled [ 153.096416] Modules linked in: [ 153.099521] CPU: 0 PID: 15 Comm: kworker/0:1 Tainted: G W 5.2.0+ #321 [ 153.107290] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree) [ 153.113772] Workqueue: events deferred_probe_work_func [ 153.118979] [<c0019560>] (unwind_backtrace) from [<c0014734>] (show_stack+0x10/0x14) [ 153.126778] [<c0014734>] (show_stack) from [<c083f8dc>] (dump_stack+0x9c/0xd4) [ 153.134051] [<c083f8dc>] (dump_stack) from [<c0031154>] (__warn+0xf8/0x124) [ 153.141056] [<c0031154>] (__warn) from [<c0031248>] (warn_slowpath_fmt+0x38/0x48) [ 153.148580] [<c0031248>] (warn_slowpath_fmt) from [<c040fde0>] (clk_core_disable_lock+0x18/0x24) [ 153.157413] [<c040fde0>] (clk_core_disable_lock) from [<c058f520>] (i2c_imx_probe+0x554/0x6ec) [ 153.166076] [<c058f520>] (i2c_imx_probe) from [<c04b9178>] (platform_drv_probe+0x48/0x98) [ 153.174297] [<c04b9178>] (platform_drv_probe) from [<c04b7298>] (really_probe+0x1d8/0x2c0) [ 153.182605] [<c04b7298>] (really_probe) from [<c04b7554>] (driver_probe_device+0x5c/0x174) [ 153.190909] [<c04b7554>] (driver_probe_device) from [<c04b58c8>] (bus_for_each_drv+0x44/0x8c) [ 153.199480] [<c04b58c8>] (bus_for_each_drv) from [<c04b746c>] (__device_attach+0xa0/0x108) [ 153.207782] [<c04b746c>] (__device_attach) from [<c04b65a4>] (bus_probe_device+0x88/0x90) [ 153.215999] [<c04b65a4>] (bus_probe_device) from [<c04b6a04>] (deferred_probe_work_func+0x60/0x90) [ 153.225003] [<c04b6a04>] (deferred_probe_work_func) from [<c004f190>] (process_one_work+0x204/0x634) [ 153.234178] [<c004f190>] (process_one_work) from [<c004f618>] (worker_thread+0x20/0x484) [ 153.242315] [<c004f618>] (worker_thread) from [<c0055c2c>] (kthread+0x118/0x150) [ 153.249758] [<c0055c2c>] (kthread) from [<c00090b4>] (ret_from_fork+0x14/0x20) [ 153.257006] Exception stack(0xdde43fb0 to 0xdde43ff8) [ 153.262095] 3fa0: 00000000 00000000 00000000 00000000 [ 153.270306] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 153.278520] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 153.285159] irq event stamp: 3323022 [ 153.288787] hardirqs last enabled at (3323021): [<c0861c4c>] _raw_spin_unlock_irq+0x24/0x2c [ 153.297261] hardirqs last disabled at (3323022): [<c040d7a0>] clk_enable_lock+0x10/0x124 [ 153.305392] softirqs last enabled at (3322092): [<c000a504>] __do_softirq+0x344/0x540 [ 153.313352] softirqs last disabled at (3322081): [<c00385c0>] irq_exit+0x10c/0x128 [ 153.320946] ---[ end trace a506731ccd9bd703 ]--- This endless clk warnings behaviour is well explained by Andrey Smirnov: "Allocating DMA after registering I2C adapter can lead to infinite probing loop, for example, consider the following scenario: 1. i2c_imx_probe() is called and successfully registers an I2C adapter via i2c_add_numbered_adapter() 2. As a part of i2c_add_numbered_adapter() new I2C slave devices are added from DT which results in a call to driver_deferred_probe_trigger() 3. i2c_imx_probe() continues and calls i2c_imx_dma_request() which due to lack of proper DMA driver returns -EPROBE_DEFER 4. i2c_imx_probe() fails, removes I2C adapter and returns -EPROBE_DEFER, which places it into deferred probe list 5. Deferred probe work triggered in #2 above kicks in and calls i2c_imx_probe() again thus bringing us to step #1" So revert commit e1ab9a4 ("i2c: imx: improve the error handling in i2c_imx_dma_request()") and restore the old behaviour, in order to avoid regressions on existing setups. Cc: <[email protected]> Reported-by: Andrey Smirnov <[email protected]> Reported-by: Russell King <[email protected]> Fixes: e1ab9a4 ("i2c: imx: improve the error handling in i2c_imx_dma_request()") Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>

[ Upstream commit bd5cd35 ] gtp hashtable size is received by user-space. So, this hashtable size could be too large. If so, kmalloc will internally print a warning message. This warning message is actually not necessary for the gtp module. So, this patch adds __GFP_NOWARN to avoid this message. Splat looks like: [ 2171.200049][ T1860] WARNING: CPU: 1 PID: 1860 at mm/page_alloc.c:4713 __alloc_pages_nodemask+0x2f3/0x740 [ 2171.238885][ T1860] Modules linked in: gtp veth openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv] [ 2171.262680][ T1860] CPU: 1 PID: 1860 Comm: gtp-link Not tainted 5.5.0+ #321 [ 2171.263567][ T1860] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 2171.264681][ T1860] RIP: 0010:__alloc_pages_nodemask+0x2f3/0x740 [ 2171.265332][ T1860] Code: 64 fe ff ff 65 48 8b 04 25 c0 0f 02 00 48 05 f0 12 00 00 41 be 01 00 00 00 49 89 47 0 [ 2171.267301][ T1860] RSP: 0018:ffff8880b51af1f0 EFLAGS: 00010246 [ 2171.268320][ T1860] RAX: ffffed1016a35e43 RBX: 0000000000000000 RCX: 0000000000000000 [ 2171.269517][ T1860] RDX: 0000000000000000 RSI: 000000000000000b RDI: 0000000000000000 [ 2171.270305][ T1860] RBP: 0000000000040cc0 R08: ffffed1018893109 R09: dffffc0000000000 [ 2171.275973][ T1860] R10: 0000000000000001 R11: ffffed1018893108 R12: 1ffff11016a35e43 [ 2171.291039][ T1860] R13: 000000000000000b R14: 000000000000000b R15: 00000000000f4240 [ 2171.292328][ T1860] FS: 00007f53cbc83740(0000) GS:ffff8880da000000(0000) knlGS:0000000000000000 [ 2171.293409][ T1860] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2171.294586][ T1860] CR2: 000055f540014508 CR3: 00000000b49f2004 CR4: 00000000000606e0 [ 2171.295424][ T1860] Call Trace: [ 2171.295756][ T1860] ? mark_held_locks+0xa5/0xe0 [ 2171.296659][ T1860] ? __alloc_pages_slowpath+0x21b0/0x21b0 [ 2171.298283][ T1860] ? gtp_encap_enable_socket+0x13e/0x400 [gtp] [ 2171.298962][ T1860] ? alloc_pages_current+0xc1/0x1a0 [ 2171.299475][ T1860] kmalloc_order+0x22/0x80 [ 2171.299936][ T1860] kmalloc_order_trace+0x1d/0x140 [ 2171.300437][ T1860] __kmalloc+0x302/0x3a0 [ 2171.300896][ T1860] gtp_newlink+0x293/0xba0 [gtp] [ ... ] Fixes: 459aa66 ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Taehee Yoo <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit bd5cd35 ] gtp hashtable size is received by user-space. So, this hashtable size could be too large. If so, kmalloc will internally print a warning message. This warning message is actually not necessary for the gtp module. So, this patch adds __GFP_NOWARN to avoid this message. Splat looks like: [ 2171.200049][ T1860] WARNING: CPU: 1 PID: 1860 at mm/page_alloc.c:4713 __alloc_pages_nodemask+0x2f3/0x740 [ 2171.238885][ T1860] Modules linked in: gtp veth openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv] [ 2171.262680][ T1860] CPU: 1 PID: 1860 Comm: gtp-link Not tainted 5.5.0+ raspberrypi#321 [ 2171.263567][ T1860] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 2171.264681][ T1860] RIP: 0010:__alloc_pages_nodemask+0x2f3/0x740 [ 2171.265332][ T1860] Code: 64 fe ff ff 65 48 8b 04 25 c0 0f 02 00 48 05 f0 12 00 00 41 be 01 00 00 00 49 89 47 0 [ 2171.267301][ T1860] RSP: 0018:ffff8880b51af1f0 EFLAGS: 00010246 [ 2171.268320][ T1860] RAX: ffffed1016a35e43 RBX: 0000000000000000 RCX: 0000000000000000 [ 2171.269517][ T1860] RDX: 0000000000000000 RSI: 000000000000000b RDI: 0000000000000000 [ 2171.270305][ T1860] RBP: 0000000000040cc0 R08: ffffed1018893109 R09: dffffc0000000000 [ 2171.275973][ T1860] R10: 0000000000000001 R11: ffffed1018893108 R12: 1ffff11016a35e43 [ 2171.291039][ T1860] R13: 000000000000000b R14: 000000000000000b R15: 00000000000f4240 [ 2171.292328][ T1860] FS: 00007f53cbc83740(0000) GS:ffff8880da000000(0000) knlGS:0000000000000000 [ 2171.293409][ T1860] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2171.294586][ T1860] CR2: 000055f540014508 CR3: 00000000b49f2004 CR4: 00000000000606e0 [ 2171.295424][ T1860] Call Trace: [ 2171.295756][ T1860] ? mark_held_locks+0xa5/0xe0 [ 2171.296659][ T1860] ? __alloc_pages_slowpath+0x21b0/0x21b0 [ 2171.298283][ T1860] ? gtp_encap_enable_socket+0x13e/0x400 [gtp] [ 2171.298962][ T1860] ? alloc_pages_current+0xc1/0x1a0 [ 2171.299475][ T1860] kmalloc_order+0x22/0x80 [ 2171.299936][ T1860] kmalloc_order_trace+0x1d/0x140 [ 2171.300437][ T1860] __kmalloc+0x302/0x3a0 [ 2171.300896][ T1860] gtp_newlink+0x293/0xba0 [gtp] [ ... ] Fixes: 459aa66 ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Taehee Yoo <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

…format [ Upstream commit 06d213d ] For incoming SCO connection with transparent coding format, alt setting of CVSD is getting applied instead of Transparent. Before fix: < HCI Command: Accept Synchron.. (0x01|0x0029) plen 21 #2196 [hci0] 321.342548 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 #2197 [hci0] 321.343585 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Comp.. (0x2c) plen 17 #2198 [hci0] 321.351666 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) ........ > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2336 [hci0] 321.383655 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2337 [hci0] 321.389558 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2338 [hci0] 321.393615 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2339 [hci0] 321.393618 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2340 [hci0] 321.393618 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2341 [hci0] 321.397070 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2342 [hci0] 321.403622 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2343 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2344 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2345 [hci0] 321.403625 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2346 [hci0] 321.404569 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2347 [hci0] 321.412091 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2348 [hci0] 321.413626 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2349 [hci0] 321.413630 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2350 [hci0] 321.413630 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2351 [hci0] 321.419674 After fix: < HCI Command: Accept Synchronou.. (0x01|0x0029) plen 21 #309 [hci0] 49.439693 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 #310 [hci0] 49.440308 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Complete (0x2c) plen 17 #311 [hci0] 49.449308 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) < SCO Data TX: Handle 257 flags 0x00 dlen 60 #312 [hci0] 49.450421 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #313 [hci0] 49.457927 > HCI Event: Max Slots Change (0x1b) plen 3 #314 [hci0] 49.460345 Handle: 256 Max slots: 5 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #315 [hci0] 49.465453 > SCO Data RX: Handle 257 flags 0x00 dlen 60 #316 [hci0] 49.470502 > SCO Data RX: Handle 257 flags 0x00 dlen 60 #317 [hci0] 49.470519 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #318 [hci0] 49.472996 > SCO Data RX: Handle 257 flags 0x00 dlen 60 #319 [hci0] 49.480412 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #320 [hci0] 49.480492 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #321 [hci0] 49.487989 > SCO Data RX: Handle 257 flags 0x00 dlen 60 #322 [hci0] 49.490303 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #323 [hci0] 49.495496 > SCO Data RX: Handle 257 flags 0x00 dlen 60 #324 [hci0] 49.500304 > SCO Data RX: Handle 257 flags 0x00 dlen 60 #325 [hci0] 49.500311 Signed-off-by: Kiran K <[email protected]> Signed-off-by: Lokendra Singh <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

See: raspberrypi/linux#321

Support for cheap Ralink 3070 WiFi plug

015e91f

Support for alink Media Tek cheap Ralink 3070 WiFi Plug. See http://www.geekamole.com/2013/rt2800usb-fix-for-ralinkmediatek-3070-gentoo-linux/

Support for cheap Ralink 3070 WiFi plug

9f56dad

Support for Ralink Media Tek cheap Ralink 3070 WiFi Plug. Incorrect detection of 3070 chipset. See http://www.geekamole.com/2013/rt2800usb-fix-for-ralinkmediatek-3070-gentoo-linux/

gazsiazasz mentioned this pull request Jul 3, 2013

Support for cheap Ralink 3070 WiFi plug OpenELEC/OpenELEC.tv#2435

Closed

popcornmix closed this Sep 11, 2013

andyduller pushed a commit to afterthoughtsoftware/linux that referenced this pull request Oct 30, 2013

Support for cheap Ralink 3070 WiFi plug

876ddb4

See: raspberrypi#321

popcornmix added a commit that referenced this pull request Nov 4, 2013

Support for cheap Ralink 3070 WiFi plug

8263a4a

See: #321

popcornmix added a commit that referenced this pull request Nov 4, 2013

Support for cheap Ralink 3070 WiFi plug

0991667

See: #321

popcornmix added a commit that referenced this pull request Nov 4, 2013

Support for cheap Ralink 3070 WiFi plug

362a3bd

See: #321

popcornmix added a commit that referenced this pull request Nov 9, 2013

Support for cheap Ralink 3070 WiFi plug

2c40281

See: #321

popcornmix added a commit that referenced this pull request Nov 16, 2013

Support for cheap Ralink 3070 WiFi plug

6d3fe89

See: #321

popcornmix added a commit that referenced this pull request Nov 17, 2013

Support for cheap Ralink 3070 WiFi plug

9c4cb5e

See: #321

popcornmix added a commit that referenced this pull request Nov 17, 2013

Support for cheap Ralink 3070 WiFi plug

60f4a4a

See: #321

davet321 pushed a commit to davet321/rpi-linux that referenced this pull request Nov 18, 2013

Support for cheap Ralink 3070 WiFi plug

1996471

See: raspberrypi#321

davet321 pushed a commit to davet321/rpi-linux that referenced this pull request Nov 18, 2013

Support for cheap Ralink 3070 WiFi plug

d1c1984

See: raspberrypi#321

popcornmix added a commit that referenced this pull request Nov 22, 2013

Support for cheap Ralink 3070 WiFi plug

d241d63

See: #321

popcornmix added a commit that referenced this pull request Nov 22, 2013

Support for cheap Ralink 3070 WiFi plug

fc5621c

See: #321

popcornmix added a commit that referenced this pull request Nov 30, 2013

Support for cheap Ralink 3070 WiFi plug

6463ad9

See: #321

popcornmix added a commit that referenced this pull request Nov 30, 2013

Support for cheap Ralink 3070 WiFi plug

55c5079

See: #321

popcornmix added a commit that referenced this pull request Dec 5, 2013

Support for cheap Ralink 3070 WiFi plug

d5801df

See: #321

popcornmix added a commit that referenced this pull request Dec 9, 2013

Support for cheap Ralink 3070 WiFi plug

ac438ad

See: #321

jai-raptee pushed a commit to jai-raptee/iliteck1 that referenced this pull request Apr 30, 2024

Support for cheap Ralink 3070 WiFi plug

7b19842

See: raspberrypi/linux#321

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support for cheap Ralink 3070 WiFi plug #321

Support for cheap Ralink 3070 WiFi plug #321

martinlbb commented Jul 2, 2013

popcornmix commented Jul 2, 2013

martinlbb commented Jul 2, 2013

popcornmix commented Jul 2, 2013

shalecraig commented Sep 4, 2013

popcornmix commented Sep 4, 2013

shalecraig commented Sep 6, 2013

martinlbb commented Sep 6, 2013

popcornmix commented Sep 8, 2013

shalecraig commented Sep 9, 2013

martinlbb commented Sep 9, 2013

popcornmix commented Sep 9, 2013

shalecraig commented Sep 11, 2013

dennisjanssen commented Sep 11, 2013

martinlbb commented Sep 11, 2013

Support for cheap Ralink 3070 WiFi plug #321

Support for cheap Ralink 3070 WiFi plug #321

Conversation

martinlbb commented Jul 2, 2013

popcornmix commented Jul 2, 2013

martinlbb commented Jul 2, 2013

popcornmix commented Jul 2, 2013

shalecraig commented Sep 4, 2013

popcornmix commented Sep 4, 2013

shalecraig commented Sep 6, 2013

martinlbb commented Sep 6, 2013

popcornmix commented Sep 8, 2013

shalecraig commented Sep 9, 2013

martinlbb commented Sep 9, 2013

popcornmix commented Sep 9, 2013

shalecraig commented Sep 11, 2013

dennisjanssen commented Sep 11, 2013

martinlbb commented Sep 11, 2013