34d2964554
Fixes issues with RTL8156 2.5G USB adapters
- # ethtool eth1
Settings for eth1:
Supported ports: [ ]
Supported link modes: Not reported
Supported pause frame use: No
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes: Not reported
Advertised pause frame use: No
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 2500Mb/s
Duplex: Half
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
MDI-X: Unknown
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
- #
- r8152: break the loop when the budget is exhausted
- r8152: Block future register access if register access fails
- r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLE
- r8152: add vendor/device ID pair for D-Link DUB-E250
- r8152: try to use a normal budget
- r8152: set bp in bulk
- r8152: adjust generic_ocp_write function
- r8152: fix the autosuspend doesn't work
- r8152: Add __GFP_NOWARN to big allocations
- r8152: reduce the control transfer of rtl8152_get_version()
- r8152: remove rtl_vendor_mode function
- r8152: avoid to change cfg for all devices
- r8152: add USB device driver for config selection
- r8152: use napi_gro_frags
- cdc_ether: no need to blacklist any r8152 devices
- cdc_ether: add u-blox 0x1313 composition
Build system: x86_64
Build-tested: bcm2711, rockchip, x86/64
Run-tested: bcm2711/RPi4B, rockchip/nanopi r2s, x86/64
Signed-off-by: Marty Jones <mj8263788@gmail.com>
56 lines
1.9 KiB
Diff
56 lines
1.9 KiB
Diff
From 5cc33f139e11b893ff6dc60d8a0ae865a65521ac Mon Sep 17 00:00:00 2001
|
|
From: Douglas Anderson <dianders@chromium.org>
|
|
Date: Thu, 6 Apr 2023 17:14:26 -0700
|
|
Subject: [PATCH] r8152: Add __GFP_NOWARN to big allocations
|
|
|
|
When memory is a little tight on my system, it's pretty easy to see
|
|
warnings that look like this.
|
|
|
|
ksoftirqd/0: page allocation failure: order:3, mode:0x40a20(GFP_ATOMIC|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0
|
|
...
|
|
Call trace:
|
|
dump_backtrace+0x0/0x1e8
|
|
show_stack+0x20/0x2c
|
|
dump_stack_lvl+0x60/0x78
|
|
dump_stack+0x18/0x38
|
|
warn_alloc+0x104/0x174
|
|
__alloc_pages+0x588/0x67c
|
|
alloc_rx_agg+0xa0/0x190 [r8152 ...]
|
|
r8152_poll+0x270/0x760 [r8152 ...]
|
|
__napi_poll+0x44/0x1ec
|
|
net_rx_action+0x100/0x300
|
|
__do_softirq+0xec/0x38c
|
|
run_ksoftirqd+0x38/0xec
|
|
smpboot_thread_fn+0xb8/0x248
|
|
kthread+0x134/0x154
|
|
ret_from_fork+0x10/0x20
|
|
|
|
On a fragmented system it's normal that order 3 allocations will
|
|
sometimes fail, especially atomic ones. The driver handles these
|
|
failures fine and the WARN just creates spam in the logs for this
|
|
case. The __GFP_NOWARN flag is exactly for this situation, so add it
|
|
to the allocation.
|
|
|
|
NOTE: my testing is on a 5.15 system, but there should be no reason
|
|
that this would be fundamentally different on a mainline kernel.
|
|
|
|
Signed-off-by: Douglas Anderson <dianders@chromium.org>
|
|
Acked-by: Hayes Wang <hayeswang@realtek.com>
|
|
Link: https://lore.kernel.org/r/20230406171411.1.I84dbef45786af440fd269b71e9436a96a8e7a152@changeid
|
|
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
---
|
|
drivers/net/usb/r8152.c | 2 +-
|
|
1 file changed, 1 insertion(+), 1 deletion(-)
|
|
|
|
--- a/drivers/net/usb/r8152.c
|
|
+++ b/drivers/net/usb/r8152.c
|
|
@@ -1947,7 +1947,7 @@ static struct rx_agg *alloc_rx_agg(struc
|
|
if (!rx_agg)
|
|
return NULL;
|
|
|
|
- rx_agg->page = alloc_pages(mflags | __GFP_COMP, order);
|
|
+ rx_agg->page = alloc_pages(mflags | __GFP_COMP | __GFP_NOWARN, order);
|
|
if (!rx_agg->page)
|
|
goto free_rx;
|
|
|