[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a9fcc952-a55f-1eae-c584-d58644bae00d@gmail.com>
Date: Mon, 2 May 2022 22:33:06 +0200
From: Ferry Toth <fntoth@...il.com>
To: Lukas Wunner <lukas@...ner.de>,
Steve Glendinning <steve.glendinning@...well.net>,
UNGLinuxDriver@...rochip.com, Oliver Neukum <oneukum@...e.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org, linux-usb@...r.kernel.org,
Andre Edich <andre.edich@...rochip.com>,
Oleksij Rempel <o.rempel@...gutronix.de>,
Martyn Welch <martyn.welch@...labora.com>,
Gabriel Hojda <ghojda@...urs.ro>,
Christoph Fritz <chf.fritz@...glemail.com>,
Lino Sanfilippo <LinoSanfilippo@....de>,
Philipp Rosenberger <p.rosenberger@...bus.com>,
Heiner Kallweit <hkallweit1@...il.com>,
Andrew Lunn <andrew@...n.ch>,
Russell King <linux@...linux.org.uk>
Subject: Re: [PATCH net-next 0/7] Polling be gone on LAN95xx
Hi,
Op 27-04-2022 om 07:48 schreef Lukas Wunner:
> Do away with link status polling on LAN95XX USB Ethernet
> and rely on interrupts instead, thereby reducing bus traffic,
> CPU overhead and improving interface bringup latency.
>
> The meat of the series is in patch [5/7]. The preceding and
> following patches are various cleanups to prepare for and
> adjust to interrupt-driven link state detection.
>
> Please review and test. Thanks!
>
> Lukas Wunner (7):
> usbnet: Run unregister_netdev() before unbind() again
> usbnet: smsc95xx: Don't clear read-only PHY interrupt
> usbnet: smsc95xx: Don't reset PHY behind PHY driver's back
> usbnet: smsc95xx: Avoid link settings race on interrupt reception
> usbnet: smsc95xx: Forward PHY interrupts to PHY driver to avoid
> polling
> net: phy: smsc: Cache interrupt mask
> net: phy: smsc: Cope with hot-removal in interrupt handler
>
> drivers/net/phy/smsc.c | 28 +++---
> drivers/net/usb/asix_devices.c | 6 +-
> drivers/net/usb/smsc95xx.c | 155 ++++++++++++++++-----------------
> drivers/net/usb/usbnet.c | 6 +-
> 4 files changed, 91 insertions(+), 104 deletions(-)
>
Tested-by: Ferry Toth <fntoth@...il.com> (Intel Edison-Arduino)
(linux v5.17 + the series + usbnet: smsc95xx: Fix deadlock on runtime
resume)
While testing I noted another problem. I have "DMA-API: debugging
enabled by kernel config" and this (I guess) shows me before and after
the patches:
------------[ cut here ]------------
DMA-API: xhci-hcd xhci-hcd.1.auto: cacheline tracking EEXIST,
overlapping mappings aren't supported
WARNING: CPU: 0 PID: 24 at kernel/dma/debug.c:570 add_dma_entry+0x1d9/0x270
Modules linked in: mmc_block extcon_intel_mrfld sdhci_pci cqhci sdhci
led_class mmc_core intel_soc_pmic_mrfld btrfs libcrc32c xor zlib_deflate
raid6_pq zstd_c>
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 5.17.0-edison-acpi-standard #1
Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542
2015.01.21:18.19.48
Workqueue: usb_hub_wq hub_event
RIP: 0010:add_dma_entry+0x1d9/0x270
Code: ff 0f 84 97 00 00 00 4c 8b 67 50 4d 85 e4 75 03 4c 8b 27 e8 29 a4
52 00 48 89 c6 4c 89 e2 48 c7 c7 78 9d 7e 98 e8 b3 f7 b6 00 <0f> 0b 48
85 ed 0f 85 d3 >
RSP: 0018:ffffb2ce000d7ad0 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 0000000000000000
RDX: 0000000000000001 RSI: 00000000ffffffea RDI: 00000000ffffffff
RBP: ffff9dea81239a00 R08: ffffffff98b356c8 R09: 00000000ffffdfff
R10: ffffffff98a556e0 R11: ffffffff98a556e0 R12: ffff9dea87397180
R13: 0000000000000001 R14: 0000000000000206 R15: 0000000000046c59
FS: 0000000000000000(0000) GS:ffff9deabe200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005595807522e0 CR3: 0000000006be2000 CR4: 00000000001006f0
Call Trace:
<TASK>
dma_map_page_attrs+0xfc/0x240
? usb_hcd_link_urb_to_ep+0x6e/0xa0
? preempt_count_add+0x63/0x90
usb_hcd_map_urb_for_dma+0x3f3/0x580
usb_hcd_submit_urb+0x93/0xb90
? _raw_spin_lock+0xe/0x30
? _raw_spin_unlock+0xd/0x20
? usb_hcd_link_urb_to_ep+0x6e/0xa0
? prepare_transfer+0xff/0x140
usb_start_wait_urb+0x60/0x160
usb_control_msg+0xdc/0x140
hub_ext_port_status+0x82/0x100
hub_event+0x1b2/0x1880
? hub_activate+0x59c/0x880
process_one_work+0x1d3/0x3a0
worker_thread+0x48/0x3c0
? rescuer_thread+0x380/0x380
kthread+0xe2/0x110
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x22/0x30
</TASK>
---[ end trace 0000000000000000 ]---
DMA-API: Mapped at:
debug_dma_map_page+0x60/0xf0
dma_map_page_attrs+0xfc/0x240
usb_hcd_map_urb_for_dma+0x3f3/0x580
usb_hcd_submit_urb+0x93/0xb90
usb_start_wait_urb+0x60/0x160
usb 1-1.1: new high-speed USB device number 3 using xhci-hcd
usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00,
bcdDevice= 2.00
usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.1: Product: LAN9514
usb 1-1.1: Manufacturer: SMSC
usb 1-1.1: SerialNumber: 00951d0d
Any ideas on this?
Powered by blists - more mailing lists