USB 2.0 driver fails with kernel update from 6.1.27 to 6.1.28-3-rpi-ARCH #5470
Comments
|
Strange - it's working for me, built from 1229967:
|
|
tail -1 /proc/cpuinfo config.txt No custom .dtb files as far as I know The fdt |
|
Your dtb may not be custom, but it also isn't the dtb that goes with that kernel version. |
|
Sorry my dtb is the one downloaded ruunning 6.1.27, since I backed it off. Would they be the same? |
|
No - the set of patches leading up to 1229967 requires that the drivers and dtb be updated together (something we usually try to avoid, but in general the dtbs should be treated as if they were part of the kernel). |
|
I assumed so. I pushed it back to 2.1.28 and yours and mine do match |
|
And yet it doesn't work? Please link to the new fdt file for comparison. |
|
After reboot same problem kernel trace: |
|
Ah - it looks like you have an 8GB CM4 (I would keep your location secret!), whereas mine is a 4GB. As a diagnostic tool, does adding |
|
Well that partially fixes it. The bus is unstable with I/O errors and then failure lsusb looks happy but a stream of errors: |
|
I'm seeing something strange, which I'm investigating. In the meantime, does replacing: with (which is our default configuration on CM4) help? You can remove the |
|
Yes Could that be documented in BTW using Thanks |
|
It's not an overlay thing - it's one of the other config.txt settings, and documented here: https://www.raspberrypi.com/documentation/computers/config_txt.html#otg_mode-raspberry-pi-4-only |
|
I hope to find and fix the DMA problem tomorrow. |
pelwell
added a commit
that referenced
this issue
May 17, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
|
The recent addition of a |
pelwell
added a commit
that referenced
this issue
May 17, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
pelwell
added a commit
that referenced
this issue
May 17, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
added a commit
to raspberrypi/firmware
that referenced
this issue
May 17, 2023
popcornmix
added a commit
to raspberrypi/rpi-firmware
that referenced
this issue
May 17, 2023
pelwell
added a commit
that referenced
this issue
May 17, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
|
@pelwell -
This is also the ArchARM default, see: https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-rpi/config.txt#L27-L31 @baslking - did you forget to diff I just pushed 6.1.28-5 which incorporates this upstream change. Once it hits the mirror, can you try it? |
|
Yes, that [cm4] section looks very much like (if not the same as) ours. |
|
My install is over 2 years old, and none of the config.txt.* files have otg_mode in them. I have tested @gradsky2 build |
|
WARNING : I have backed off to |
|
Unrelated to the initial issue, but I recall that, at least at some point in time, the use of ECC memory was highly encouraged for ZFS devices? |
|
ECC would be nice, and there is some legends around this, the idea being that a scrub operation to check parity with a stuck bit in ram would corrupt the disk, but it's a poor man's NAS based on a CM4 :-) |
|
That is because you have not modified |
|
I have modified |
popcornmix
pushed a commit
that referenced
this issue
Jun 6, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Jun 7, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Noltari
pushed a commit
to Noltari/rpi-linux
that referenced
this issue
Jun 8, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: raspberrypi#5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Jun 12, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Jun 12, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Jun 16, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Jun 20, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Jun 22, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Jun 26, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Jun 30, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Jul 3, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Jul 3, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Jul 10, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Jul 10, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Jul 14, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Jul 14, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Jul 20, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Jul 24, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Jul 27, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Aug 3, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Aug 9, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Aug 17, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Sep 5, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Sep 8, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix
pushed a commit
that referenced
this issue
Sep 13, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2711 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so to act as the limiting factor in the calculation. See: #5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
pelwell
added a commit
to pelwell/linux
that referenced
this issue
Oct 17, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2712 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so as to act as the limiting factor in the calculation. See: raspberrypi#5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
pelwell
added a commit
to pelwell/linux
that referenced
this issue
Oct 19, 2023
The arm64 initialisation uses the physical address reachable by all DMA controllers to set the size of ZONE_DMA. This fails on BCM2712 with the current dts files because the declaration of the I/O space fools it into thinking the legacy 30-bit DMA channels can see most of the 32-bit space. Take advantage of the simple nature of the implementation by adding a node with a restricted dma-ranges property solely so as to act as the limiting factor in the calculation. See: raspberrypi#5470 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
USB 2.0 generates kernel trace at boot and then does not correctly detect or use USB connected devices.
expected behavior of
~lsusb
Bus 001 Device 003: ID 0463:ffff MGE UPS Systems UPS
Bus 001 Device 002: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Kernel 28 behavior:
~lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Steps to reproduce the behaviour
Updated kernel no longer detects USB devices boot trace shown below.
Reverting to 6.1.27 kernel resolves the issue
Device (s)
Raspberry Pi CM4 8GB
System
NAME="Arch Linux ARM"
PRETTY_NAME="Arch Linux ARM"
ID=archarm
ID_LIKE=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinuxarm.org/"
DOCUMENTATION_URL="https://archlinuxarm.org/wiki"
SUPPORT_URL="https://archlinuxarm.org/forum"
BUG_REPORT_URL="https://github.com/archlinuxarm/PKGBUILDs/issues"
pacman -Qs raspberry
local/firmware-raspberrypi 20230125-1
Additional firmware for Raspberry Pi
local/raspberrypi-bootloader 20230512-1
Bootloader files for Raspberry Pi
This kernel works:
Linux pi-nas 6.1.27-1-rpi-ARCH #1 SMP PREEMPT Tue May 2 18:32:20 MDT 2023 aarch64 GNU/Linux
This kernel does not:
Linux pi-nas 6.1.28-3-rpi-ARCH #1 SMP PREEMPT Mon May 15 12:00:19 MDT 2023 aarch64 GNU/Linux
Logs
journalctl -b snippet:
------------[ cut here ]------------
May 16 11:09:01 pi-nas kernel: bcm2835-isp bcm2835-isp: Register capture node 1 with media controller
May 16 11:09:01 pi-nas kernel: dwc2 fe980000.usb: swiotlb addr 0xffffffffffffffff+8 overflow (mask ffffffff, bus limit ffffffff).
May 16 11:09:01 pi-nas kernel: bcm2835-isp bcm2835-isp: Register capture node 2 with media controller
May 16 11:09:01 pi-nas kernel: WARNING: CPU: 1 PID: 155 at kernel/dma/swiotlb.c:885 swiotlb_map+0x2b4/0x2c4
May 16 11:09:01 pi-nas kernel: bcm2835-isp bcm2835-isp: Register capture node 3 with media controller
May 16 11:09:01 pi-nas kernel: Modules linked in: bcm2835_codec(C) bcm2835_v4l2(C) bcm2835_isp(C+) rpivid_hevc(C) rtc_pcf85063 bcm2835_mmal_vchiq(C)
May 16 11:09:01 pi-nas kernel: bcm2835-isp bcm2835-isp: Loaded V4L2 bcm2835-isp
May 16 11:09:01 pi-nas kernel: v4l2_mem2mem videobuf2_vmalloc videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 snd_bcm2835(C) videobuf2_common snd_pcm vc_sm>
May 16 11:09:01 pi-nas kernel: CPU: 1 PID: 155 Comm: kworker/1:2 Tainted: P C O 6.1.28-3-rpi-ARCH #1
May 16 11:09:01 pi-nas kernel: Hardware name: Raspberry Pi Compute Module 4 Rev 1.0 (DT)
May 16 11:09:01 pi-nas kernel: Workqueue: usb_hub_wq hub_event
May 16 11:09:01 pi-nas kernel: pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
May 16 11:09:01 pi-nas kernel: pc : swiotlb_map+0x2b4/0x2c4
May 16 11:09:01 pi-nas kernel: lr : swiotlb_map+0x2b4/0x2c4
May 16 11:09:01 pi-nas kernel: sp : ffffffc0086bb880
May 16 11:09:01 pi-nas kernel: x29: ffffffc0086bb880 x28: ffffffd7660a53a0 x27: ffffff8101111800
May 16 11:09:01 pi-nas kernel: x26: ffffffd7657e2a38 x25: ffffffffffffffff x24: 0000000000000000
May 16 11:09:01 pi-nas kernel: x23: ffffff810020e410 x22: 0000000000000001 x21: 0000000000000000
May 16 11:09:01 pi-nas kernel: x20: 0000000000000008 x19: 000000010924f380 x18: 0000000000000006
May 16 11:09:01 pi-nas kernel: x17: 6d2820776f6c6672 x16: 65766f20382b6666 x15: 6666666666666666
May 16 11:09:01 pi-nas kernel: x14: 0050a68d1f24b046 x13: ffffffd76572b6a0 x12: ffffffd765f28910
May 16 11:09:01 pi-nas kernel: x11: 0000000000000001 x10: 0000000000001a80 x9 : ffffffd7656eee38
May 16 11:09:01 pi-nas kernel: x8 : ffffffc0086bb5f8 x7 : 0000000000000000 x6 : 00000000000000d0
May 16 11:09:01 pi-nas kernel: x5 : ffffffd765f29000 x4 : ffffffd765f29070 x3 : 0000000000000000
May 16 11:09:01 pi-nas kernel: x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff810322be00
May 16 11:09:01 pi-nas kernel: Call trace:
May 16 11:09:01 pi-nas kernel: swiotlb_map+0x2b4/0x2c4
May 16 11:09:01 pi-nas kernel: dma_map_page_attrs+0xa0/0x200
May 16 11:09:01 pi-nas kernel: usb_hcd_map_urb_for_dma+0x170/0x470
May 16 11:09:01 pi-nas kernel: dwc2_map_urb_for_dma+0x58/0x130 [dwc2]
May 16 11:09:01 pi-nas kernel: usb_hcd_submit_urb+0xb0/0x950
May 16 11:09:01 pi-nas kernel: usb_submit_urb+0x29c/0x5c0
May 16 11:09:01 pi-nas kernel: usb_start_wait_urb+0x78/0x11c
May 16 11:09:01 pi-nas kernel: usb_control_msg+0xc8/0x140
May 16 11:09:01 pi-nas kernel: hub_port_init+0x3dc/0xc80
May 16 11:09:01 pi-nas kernel: hub_event+0x968/0x159c
May 16 11:09:01 pi-nas kernel: process_one_work+0x200/0x474
May 16 11:09:01 pi-nas kernel: worker_thread+0x74/0x43c
May 16 11:09:01 pi-nas kernel: kthread+0xfc/0x110
May 16 11:09:01 pi-nas kernel: ret_from_fork+0x10/0x20
May 16 11:09:01 pi-nas kernel: ---[ end trace 0000000000000000 ]---
Additional context
No response
The text was updated successfully, but these errors were encountered: