search

raspberrypi / linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/
Other
11.03k stars 4.95k forks source link

6.0 locks up on RPi2/3 if FIQ is enabled in dwc_otg and kernel is built with STACKPROTECTOR_PER_TASK #5189

Closed HiassofT closed 1 year ago

HiassofT commented 1 year ago

Describe the bug

Trying to boot 32bit rpi-6.0.y kernel on RPi3B+ results in a hard lockup, usually during USB enumeration.

This seems to be FIQ related, adding dwc_otg.fiq_enable=0 dwc_otg.fiq_fsm_enable=0 to cmdline.txt allows the kernel to boot.

Very likeley it's a crash somewhere in dwc_otg, but unfortunately serial logs stop after 8<--- cut here --- so the details what exactly went wrong are missing - not much more on HDMI screein either in a couple of tries.

Steps to reproduce the behaviour

Device (s)

Raspberry Pi 3 Mod. B+

System

I first noticed the lockup on LibreELEC, running 6.0-rc1 a while ago and now tested LE and RPiOS with current 6.0-rc7 kernel as well (all with the same results)

root@raspberrypi:~# cat /etc/rpi-issue
Raspberry Pi reference 2022-01-28
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, f01430c9d8f67a4b9719cc00e74a2079d3834d5d, stage2
root@raspberrypi:~# vcgencmd version
Aug 26 2022 14:04:36 
Copyright (c) 2012 Broadcom
version 102f1e848393c2112206fadffaaf86db04e98326 (clean) (release) (start)
root@raspberrypi:~# uname -a
Linux raspberrypi 6.0.0-rc7-v7+ #1 SMP Thu Sep 29 16:33:35 CEST 2022 armv7l GNU/Linux

Kernel built from commit 3fb5ca89c844eb9fda924a5e76ffab9e8c068675

Logs

rpi3b+.log.txt

Additional context

Most likely RPi0-3 are affected as well, haven't tested those though

lategoodbye commented 1 year ago

@HiassofT Your error description doesn't fit exactly to this, but could you give it a try? https://lore.kernel.org/lkml/20220929-rpi-pi3-unplugged-fixes-v1-0-cd22e962296c@cerno.tech/

pelwell commented 1 year ago

@popcornmix did notice FIQ not working when first trying 6.0, and as far as I know nothing has changed in that area.

HiassofT commented 1 year ago

@lategoodbye this time vc4 is not the culprit, the lockup also occurs with vc4 driver disabled (overlay removed)

disabling FIQ or using dwc2 let the system boot fine and so far 6.0 is looking quite good on RPi3 and 4

I did a few additional tests, hoping that ramoops plus watchdog (and gpio-conditional dwc2 driver) would give some more info about the oops but no luck so far - nothing in pstore

pelwell commented 1 year ago

It looks OK to me so far. Building from 3fb5ca89c844:

pi@raspberrypi:~$ uname -a
Linux philippi 6.0.0-rc7-v7+ #1102 SMP Fri Sep 30 15:56:21 BST 2022 armv7l GNU/Linux
pi@raspberrypi:~$ tail -4 /proc/cpuinfo
Hardware        : BCM2835
Revision        : a020d3
Serial          : 00000000ee2d4d87
Model           : Raspberry Pi 3 Model B Plus Rev 1.3
pi@raspberrypi:~$ dmesg | grep dwc
[    2.069763] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
[    3.021520] WARN::dwc_otg_hcd_init:1072: FIQ DMA bounce buffers: virt = 9e104000 dma = 0xde104000 len=9024
[    3.039113] dwc_otg: Microframe scheduler enabled
[    3.051070] dwc_otg 3f980000.usb: DWC OTG Controller
[    3.053197] dwc_otg 3f980000.usb: new USB bus registered, assigned bus number 1
[    3.055330] dwc_otg 3f980000.usb: irq 89, io mem 0x00000000
[    3.070305] usb usb1: Manufacturer: Linux 6.0.0-rc7-v7+ dwc_otg_hcd
[    3.080373] dwc_otg: FIQ enabled
[    3.080383] dwc_otg: NAK holdoff enabled
[    3.080391] dwc_otg: FIQ split-transaction FSM enabled
[    3.080405] Module dwc_common_port init
[    3.422948] usb 1-1: new high-speed USB device number 2 using dwc_otg
[    4.773100] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
[    5.328283] dwc_otg_handle_wakeup_detected_intr lxstate = 2
[    5.882991] usb 1-1.1.1: new high-speed USB device number 4 using dwc_otg
pelwell commented 1 year ago

It also boots with earlycon, and with an HDMI display, and keyboard and mouse.

If you are network booting, have you tried with an SD card?

HiassofT commented 1 year ago

Weird. I'm booting from sdcard here, cpuinfo looks identical to yours and my config.txt is pretty stock (disabled vc4 and added dtdebug, uart_2ndstage, ramoops, watchdog and conditional dwc2 overlay today - after initial report) - see below.

I also unplugged all USB devices so it's just lan on USB here now.

dmesg from successful boot with dwc2: http://ix.io/4bUU

I'm currently testing with dwc_otg, FIQ and watchdog and the farthest I got was a single ping answer before it locked up and watchdog kicked in.

cpuinfo:

Hardware    : BCM2835
Revision    : a020d3
Serial      : 00000000e22fae42
Model       : Raspberry Pi 3 Model B Plus Rev 1.3

config.txt:

# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
# dtparam=audio=on

# Automatically load overlays for detected cameras
camera_auto_detect=1

# Automatically load overlays for detected DSI displays
display_auto_detect=1

# Enable DRM VC4 V3D driver
#dtoverlay=vc4-kms-v3d
max_framebuffers=2

# Disable compensation for displays with overscan
disable_overscan=1

[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1

[all]

[pi4]
# Run as fast as firmware / board allows
arm_boost=1

[all]
dtdebug=1
uart_2ndstage=1
dtoverlay=disable-bt
#dtoverlay=ramoops,console-size=16384
dtoverlay=ramoops,console-size=16384

dtparam=
dtparam=watchdog=on

[pi3]
[gpio6=1]
dtoverlay=dwc2,dr_mode=host
[all]
HiassofT commented 1 year ago

forgot to add: HDMI (1920x1200 monitor) is connected, otherwise just LAN (and serial on AMA)

HiassofT commented 1 year ago

Ah, after about 10 minutes in watchdog reboot loop I just got one boot that didn't lock up

dmesg: http://ix.io/4bUY

popcornmix commented 1 year ago

I've just tried a few boots on a Pi3 with:

pi@pi3:~ $ uname -a
Linux pi3 6.0.0-v7+ #906 SMP Mon Oct 3 16:28:12 BST 2022 armv7l GNU/Linux

and nfs boot (so dwc/fiq should be active). Comes up okay and dmesg is clean.

@popcornmix did notice FIQ not working when first trying 6.0, and as far as I know nothing has changed in that area.

Just checked the email and it was actually a report of @HiassofT had seen an issue with FIQ on 6.0.0-rc1, rather that me seeing it directly.

I guess there is something broken that needs certain conditions (presumably timing) to succeed or fail and @HiassofT is triggering it more easily. Perhaps .config options chosen changes the order kernel components are initialised in?

HiassofT commented 1 year ago

Just re-did the test, started with a plain install of Sep 22 RPiOS lite image, only enabled ssh, installed apt updates and latest rpi-update kernel/firmware, then built rpi-6.0.y final kernel 896b8da17ad15 with bcm2709_defconfig using arm gcc from Debian Bullseye

hias@delle:~/private/rpi/linux-rpi-6.0$ export CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf-
hias@delle:~/private/rpi/linux-rpi-6.0$ /usr/bin/arm-linux-gnueabihf-gcc --version
arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I then tested that on an RPi2, an RPi3 and another virgin RPi3B+ I pulled from the shelve - and all of these were locking up.

RPi2 locked up immediately during boot - no matter if LAN and USB keyboard were connected or not.

RPi3 seemed more robust, it booted up fine with LAN connected, even survived ssh-ing in and ping -f but then locked up during reboot - or on subsequent boots even once during boot.

RPi3B+ either locked up during boot (with LAN or nothing connected) or then later when booting without LAN/keyboard connected and then plugging in LAN cable.

In one of the RPi3B+ lockups during boot it got as far as showing a kernel NULL pointer at address 0000000f - not really helpful info though :-(

My bet would be on a race somewhere...

pelwell commented 1 year ago

I find it strange that you are the only person so far to report this problem. I could try leaving a 3B+ in a reboot loop to see if I hit it eventually.

HiassofT commented 1 year ago

It's indeed very strange.

@pelwell could you share your kernel build somewhere? I'll then give that a try and check for possible differences (that should quickly rule out build issues).

I've uploaded mine here, together with .config generated by bcm2709_defconfig (kconfig-bcm2709 in root) https://www.horus.com/~hias/tmp/rpi-kernel7-6.0.tar

pelwell commented 1 year ago

This is my build of 6.0.0 (80aaa961c308a680f34157f1397c13b7cee45e04): https://drive.google.com/file/d/1ItRLCyvgba8cQeU6qgtloxu_xgDsG-df/view?usp=sharing I'll try your build in a moment.

pelwell commented 1 year ago

N.B. Be careful how you extract that archive - it puts modules at /lib, which can be fatal unless you include --keep-directory-symlink. I use the following command to do the extraction:

$ sudo tar --no-same-owner --keep-directory-symlink -zxf <path-to-archive> -C /
pelwell commented 1 year ago

Your kernel build also crashes for me...

pelwell commented 1 year ago

The archive behind the download link above has been updated to include the dtb and overlay files.

pelwell commented 1 year ago

FYI these are the config diffs:

diff .config kconfig-bcm2709
5c5
< CONFIG_CC_VERSION_TEXT="arm-linux-gnueabihf-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0"
---
> CONFIG_CC_VERSION_TEXT="arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110"
7c7
< CONFIG_GCC_VERSION=90400
---
> CONFIG_GCC_VERSION=100201
10c10
< CONFIG_AS_VERSION=23400
---
> CONFIG_AS_VERSION=23502
12c12
< CONFIG_LD_VERSION=23400
---
> CONFIG_LD_VERSION=23502
488a489
> CONFIG_STACKPROTECTOR_PER_TASK=y
673a675,677
> CONFIG_GCC_PLUGINS=y
> # CONFIG_GCC_PLUGIN_LATENT_ENTROPY is not set
> CONFIG_GCC_PLUGIN_ARM_SSP_PER_TASK=y
7268a7273,7275
> # CONFIG_GCC_PLUGIN_STRUCTLEAK_USER is not set
> # CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF is not set
> # CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL is not set
7273a7281,7282
> # CONFIG_RANDSTRUCT_FULL is not set
> # CONFIG_RANDSTRUCT_PERFORMANCE is not set
HiassofT commented 1 year ago

Just tested your build and it's working fine here, too.

I'll try a build with CONFIG_STACKPROTECTOR_PER_TASK set to off and see if that changes anything

HiassofT commented 1 year ago

Some more datapoints:

32bit bcm2709_defconfig with CONFIG_STACKPROTECTOR_PER_TASK disabled didn't lock up here on RPi3B+

As disabling the (default y) option doesn't make me feel to comfortable I build a 64bit bcmrpi3_defconfig kernel with KASAN enabled - CONFIG_STACKPROTECTOR_PER_TASK can't be disabled here in Kconfig, only CONFIG_STACKPROTECTOR is changeable.

That resulted in a out-of-bounds read error in dwc_otg:

[   17.922535] ==================================================================
[   17.947229] BUG: KASAN: slab-out-of-bounds in dwc_otg_hcd_is_bandwidth_allocated+0x2c/0x50
[   17.972466] Read of size 8 at addr ffffff80045d4c68 by task kworker/1:1/36

[   18.022333] CPU: 1 PID: 36 Comm: kworker/1:1 Not tainted 6.0.0-v8+ #1
[   18.047963] Hardware name: Raspberry Pi 3 Model B Plus Rev 1.3 (DT)
[   18.073628] Workqueue: events_power_efficient hub_init_func3
[   18.099286] Call trace:
[   18.124536]  dump_backtrace.part.0+0xe0/0xf0
[   18.149947]  show_stack+0x20/0x60
[   18.175107]  dump_stack_lvl+0x8c/0xb8
[   18.200105]  print_report+0x14c/0x5bc
[   18.224932]  kasan_report+0xb0/0x110
[   18.249520]  __asan_load8+0x80/0xac
[   18.273974]  dwc_otg_hcd_is_bandwidth_allocated+0x2c/0x50
[   18.298844]  dwc_otg_urb_enqueue+0x48c/0x590
[   18.323054]  usb_hcd_submit_urb+0x1a8/0xec0
[   18.346686]  usb_submit_urb+0x2f0/0x9dc
[   18.370268]  hub_activate+0x3c4/0xd40
[   18.393811]  hub_init_func3+0x20/0x30
[   18.417305]  process_one_work+0x4f4/0xb3c
[   18.440767]  worker_thread+0xac/0x6b0
[   18.464035]  kthread+0x168/0x170
[   18.487008]  ret_from_fork+0x10/0x20

[   18.532093] Allocated by task 36:
[   18.554481]  kasan_save_stack+0x2c/0x54
[   18.576827]  __kasan_kmalloc+0x90/0xbc
[   18.599210]  __kmalloc+0x214/0x370
[   18.621130]  usb_get_configuration+0x8a8/0x1d60
[   18.643074]  usb_new_device+0x324/0x690
[   18.664728]  hub_event+0xea0/0x1d40
[   18.686217]  process_one_work+0x4f4/0xb3c
[   18.707711]  worker_thread+0xac/0x6b0
[   18.729104]  kthread+0x168/0x170
[   18.750491]  ret_from_fork+0x10/0x20

[   18.792371] The buggy address belongs to the object at ffffff80045d4c00
                which belongs to the cache kmalloc-128 of size 128
[   18.835059] The buggy address is located 104 bytes inside of
                128-byte region [ffffff80045d4c00, ffffff80045d4c80)

[   18.898583] The buggy address belongs to the physical page:
[   18.919967] page:00000000e5a3fefc refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x45d4
[   18.942237] flags: 0x200(slab|zone=0)
[   18.963980] raw: 0000000000000200 0000000000000000 dead000000000122 ffffff8003802300
[   18.986313] raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
[   19.008577] page dumped because: kasan: bad access detected

[   19.052549] Memory state around the buggy address:
[   19.072928] ------------[ cut here ]------------
[   19.074747]  ffffff80045d4b00: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
[   19.074793]  ffffff80045d4b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   19.074837] >ffffff80045d4c00: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
[   19.074869]                                                           ^
[   19.074907]  ffffff80045d4c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   19.074950]  ffffff80045d4d00: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   19.074984] ==================================================================

To check if that could be related to the stackprotector I built another kernel with CONFIG_STACKPROTECTOR disabled and KASAN enabled (full config is here: http://ix.io/4chU) and got pretty much the same KASAN bug reported:

[   17.617847] ==================================================================
[   17.641995] BUG: KASAN: slab-out-of-bounds in dwc_otg_hcd_is_bandwidth_allocated+0x2c/0x50
[   17.666650] Read of size 8 at addr ffffff80062d6068 by task kworker/0:1/14

[   17.715497] CPU: 0 PID: 14 Comm: kworker/0:1 Not tainted 6.0.0-v8+ #1
[   17.740622] Hardware name: Raspberry Pi 3 Model B Plus Rev 1.3 (DT)
[   17.765806] Workqueue: events_power_efficient hub_init_func3
[   17.790989] Call trace:
[   17.815759]  dump_backtrace.part.0+0xe0/0xf0
[   17.840696]  show_stack+0x20/0x60
[   17.865369]  dump_stack_lvl+0x8c/0xb8
[   17.889888]  print_report+0x14c/0x5bc
[   17.914229]  kasan_report+0xb0/0x110
[   17.938357]  __asan_load8+0x80/0xac
[   17.962329]  dwc_otg_hcd_is_bandwidth_allocated+0x2c/0x50
[   17.986714]  dwc_otg_urb_enqueue+0x468/0x560
[   18.010448]  usb_hcd_submit_urb+0x198/0xe90
[   18.033659]  usb_submit_urb+0x2f0/0x9dc
[   18.056802]  hub_activate+0x3b4/0xd10
[   18.079898]  hub_init_func3+0x20/0x30
[   18.102942]  process_one_work+0x4ec/0xb0c
[   18.125943]  worker_thread+0xac/0x6b0
[   18.148745]  kthread+0x168/0x170
[   18.171235]  ret_from_fork+0x10/0x20

[   18.215361] Allocated by task 14:
[   18.217078] uart-pl011 3f201000.serial: cts_event_workaround enabled
[   18.237257]  kasan_save_stack+0x2c/0x54
[   18.237340]  __kasan_kmalloc+0x90/0xbc
[   18.237404]  __kmalloc+0x204/0x344
[   18.237461]  usb_get_configuration+0x8a4/0x1d0c
[   18.237537]  usb_new_device+0x324/0x690
[   18.265206] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 99, base_baud = 0) is a PL011 rev2
[   18.282762]  hub_event+0xe74/0x1d04
[   18.282820]  process_one_work+0x4ec/0xb0c
[   18.282889]  worker_thread+0xac/0x6b0
[   18.282950]  kthread+0x168/0x170
[   18.283004]  ret_from_fork+0x10/0x20

[   18.522005] The buggy address belongs to the object at ffffff80062d6000
                which belongs to the cache kmalloc-128 of size 128
[   18.565293] The buggy address is located 104 bytes inside of
                128-byte region [ffffff80062d6000, ffffff80062d6080)

[   18.629643] The buggy address belongs to the physical page:
[   18.651254] page:000000000c3046b9 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x62d6
[   18.673647] flags: 0x200(slab|zone=0)
[   18.695644] raw: 0000000000000200 0000000000000000 dead000000000122 ffffff8003402300
[   18.718310] raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
[   18.740902] page dumped because: kasan: bad access detected

[   18.785398] Memory state around the buggy address:
[   18.807587]  ffffff80062d5f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[   18.830076]  ffffff80062d5f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[   18.852285] >ffffff80062d6000: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
[   18.874677]                                                           ^
[   18.897255]  ffffff80062d6080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   18.920209]  ffffff80062d6100: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   18.942982] ==================================================================

Full dmesg is here: http://ix.io/4chV

So I suspect there may be a bug lingering somewhere in dwc_otg

ping @P33M - any ideas?

mi-hol commented 1 year ago

@HiassofT maybe the issue title should be changed to reflect your latest finding?

HiassofT commented 1 year ago

I've added the title to reflect the conditions under which the lockup occurs.

On RPiOS/Debian bullseye, with gcc 10, you need to install the gcc-10-plugin-dev package (or gcc-10-plugin-dev-arm-linux-gnueabihf if cross-compiling).

When compiling with gcc 12 the plugin is not required as the compiler can generate the necessary code on it's own.

Under both conditions kbuild will automatically enable CONFIG_STACKPROTECTOR_PER_TASK

For the kicks I built current 6.0.1 (commit f9d15714a2e2bb8ee18cd426fc82a5010e7c240b) on an RPi3B+ running RPiOS bullseye with gcc-10-plugin-dev installed and about 2 hours later I had a kernel that locked up as well

P33M commented 1 year ago

I strongly suspect that qh->qh_list_entry is uninitialised (or dangling) when touched by dwc_otg_hcd_is_bandwidth_allocated().

P33M commented 1 year ago

This is why you don't pass around void * everywhere - the driver incorrectly passes a pointer to ep->hcpriv in to dwc_otg_hcd_is_bandwidth_allocated, not ep->hcpriv (which should point to the queue head struct, once the first transfer has been queued).

P33M commented 1 year ago

I'm building with the per-task stack protector enabled to see what the FIQ code looks like. From my understanding, the stack canary value will randomly change and if GCC is being clever and adding a stack check in FIQ functions then this will explode.

HiassofT commented 1 year ago

Thanks a lot for looking into this!

I did some more tests with fcc5c1493398705066a9fa5e7145d6514eb4c919 but didn't get very far yet.

Results so far:

on 64bit (bcmrpi3_defconfig plus stackprotector per task plus KASAN) KASAN is happy now, kernel boots.

64bit kernel with stackprotector plus SOFTLOCKUP_DETECTOR plus PROVE_LOCKING hasn't flagged anything either yet

32bit kernel (bcm2709_defconfig without stackprotector per task) seems to boot fine

32bit kernel with stackprotector and fiq_enable=1 fiq_fsm_enable=1 always locks up during boot on RPi3B+ (let it run for about half an hour with watchdog) - nothing at all in serial console log

32bit kernel with stackprotector and fiq_enable=1 fiq_fsm_enable=0 seems to boot fine - I tried a couple of reboots but take it with a grain of salt as in previous testing sometimes fiq+fiq_fsm enabled booted, too

P33M commented 1 year ago

Crashes for me on bcm2709_defconfig and STACKPROTECTOR_PER_TASK=y. It still crashes with maxcpus=1.

P33M commented 1 year ago

Can you try the top of https://github.com/P33M/linux/tree/dwc_otg_fix ? Seems to work for me.

HiassofT commented 1 year ago

@P33M thanks a lot, your dwc_otg commit applied on top of latest 6.0 branch (692039799e7857ae0f7e72125b5f73dc965a7b9a) works fine here, too!

Tested both with gcc 10 on Debian Bullseye and gcc 12 in LE buildsystem

HiassofT commented 1 year ago

again, thanks a lot, 6.0 branch is fine now