* u-boot crashes if mass-storage devices are connected via USB-C
@ 2023-03-01 13:38 bluetail
2023-03-01 20:34 ` Simon Glass
0 siblings, 1 reply; 9+ messages in thread
From: bluetail @ 2023-03-01 13:38 UTC (permalink / raw)
To: u-boot
[-- Attachment #1: Type: text/plain, Size: 1418 bytes --]
Hello. user kettenis aka "Mark Kettenis" guided me write my bug report
to this email. "bluetail: please report these usb bugs upstream; they're
almost certainly not hardware-specific"
But before, jannau aka Janne Grunau asked me to give the version output
of `pacman -Qi uboot-asahi` to which I replied 2022.10.asahi1-1.
Because I had the feeling that sometimes the reboot with a USB-C
connected device succeeds, depending how many bays are populated. But I
have no evidence for that.
I did try other USB Type C Cables, but without success of fixing the
underlying issue. The device works fine via USB Type A or C fine if
plugged in AFTER u-boot.
But, u-boot does not support USB Type A yet, which is why it wont break
my boot sequence with USB Type A.
Essentially, I connect a mass-storage device to the USB-C port of a Mac
Mini 2020 (M1), and it leads to the issue in the attachment.
I was able to reproduce it with Icy Box IB-3810 and ICY BOX IB-3805.
Initially I thought this issue was only for some devices (also attached
here) https://github.com/AsahiLinux/u-boot/issues/4 but it appears this
might be a issue that is with many devices.
If you need any more information, please feel free to ask. I am very
eager to have this issue fixed because it seems to be a very broad issue
with mass media storage in general.
uname-r returns 6.1.0-asahi-2-2-edge-ARCH
Best regards,
bluetail
--
aka zDEFz
[-- Attachment #2: reproduction usb-c-reencoded.mp4 --]
[-- Type: video/mp4, Size: 9308096 bytes --]
[-- Attachment #3: 1.png --]
[-- Type: image/png, Size: 966076 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: u-boot crashes if mass-storage devices are connected via USB-C
2023-03-01 13:38 u-boot crashes if mass-storage devices are connected via USB-C bluetail
@ 2023-03-01 20:34 ` Simon Glass
2023-03-01 22:51 ` Marek Vasut
0 siblings, 1 reply; 9+ messages in thread
From: Simon Glass @ 2023-03-01 20:34 UTC (permalink / raw)
To: bluetail, Marek Vasut, Bin Meng, Mark Kettenis, Tom Rini; +Cc: u-boot
+Marek Vasut +Bin Meng +Mark Kettenis +Tom Rini
On Wed, 1 Mar 2023 at 08:12, bluetail <a-development+asahi@posteo.de> wrote:
>
> Hello. user kettenis aka "Mark Kettenis" guided me write my bug report
> to this email. "bluetail: please report these usb bugs upstream; they're
> almost certainly not hardware-specific"
>
> But before, jannau aka Janne Grunau asked me to give the version output
> of `pacman -Qi uboot-asahi` to which I replied 2022.10.asahi1-1.
> Because I had the feeling that sometimes the reboot with a USB-C
> connected device succeeds, depending how many bays are populated. But I
> have no evidence for that.
> I did try other USB Type C Cables, but without success of fixing the
> underlying issue. The device works fine via USB Type A or C fine if
> plugged in AFTER u-boot.
> But, u-boot does not support USB Type A yet, which is why it wont break
> my boot sequence with USB Type A.
>
> Essentially, I connect a mass-storage device to the USB-C port of a Mac
> Mini 2020 (M1), and it leads to the issue in the attachment.
> I was able to reproduce it with Icy Box IB-3810 and ICY BOX IB-3805.
> Initially I thought this issue was only for some devices (also attached
> here) https://github.com/AsahiLinux/u-boot/issues/4 but it appears this
> might be a issue that is with many devices.
>
> If you need any more information, please feel free to ask. I am very
> eager to have this issue fixed because it seems to be a very broad issue
> with mass media storage in general.
> uname-r returns 6.1.0-asahi-2-2-edge-ARCH
>
> Best regards,
> bluetail
> --
> aka zDEFz
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: u-boot crashes if mass-storage devices are connected via USB-C
2023-03-01 20:34 ` Simon Glass
@ 2023-03-01 22:51 ` Marek Vasut
2023-03-01 23:30 ` bluetail
2023-03-02 9:14 ` Janne Grunau
0 siblings, 2 replies; 9+ messages in thread
From: Marek Vasut @ 2023-03-01 22:51 UTC (permalink / raw)
To: Simon Glass, bluetail, Bin Meng, Mark Kettenis, Tom Rini
Cc: u-boot, Janne Grunau
On 3/1/23 21:34, Simon Glass wrote:
> +Marek Vasut +Bin Meng +Mark Kettenis +Tom Rini
>
> On Wed, 1 Mar 2023 at 08:12, bluetail <a-development+asahi@posteo.de> wrote:
>>
>> Hello. user kettenis aka "Mark Kettenis" guided me write my bug report
>> to this email. "bluetail: please report these usb bugs upstream; they're
>> almost certainly not hardware-specific"
>>
>> But before, jannau aka Janne Grunau asked me to give the version output
>> of `pacman -Qi uboot-asahi` to which I replied 2022.10.asahi1-1.
>> Because I had the feeling that sometimes the reboot with a USB-C
>> connected device succeeds, depending how many bays are populated. But I
>> have no evidence for that.
>> I did try other USB Type C Cables, but without success of fixing the
>> underlying issue. The device works fine via USB Type A or C fine if
>> plugged in AFTER u-boot.
>> But, u-boot does not support USB Type A yet, which is why it wont break
>> my boot sequence with USB Type A.
>>
>> Essentially, I connect a mass-storage device to the USB-C port of a Mac
>> Mini 2020 (M1), and it leads to the issue in the attachment.
>> I was able to reproduce it with Icy Box IB-3810 and ICY BOX IB-3805.
>> Initially I thought this issue was only for some devices (also attached
>> here) https://github.com/AsahiLinux/u-boot/issues/4 but it appears this
>> might be a issue that is with many devices.
>>
>> If you need any more information, please feel free to ask. I am very
>> eager to have this issue fixed because it seems to be a very broad issue
>> with mass media storage in general.
>> uname-r returns 6.1.0-asahi-2-2-edge-ARCH
Would it be possible to check whether current u-boot/master works any
better ?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: u-boot crashes if mass-storage devices are connected via USB-C
2023-03-01 22:51 ` Marek Vasut
@ 2023-03-01 23:30 ` bluetail
2023-03-02 9:14 ` Janne Grunau
1 sibling, 0 replies; 9+ messages in thread
From: bluetail @ 2023-03-01 23:30 UTC (permalink / raw)
To: Marek Vasut
Cc: Simon Glass, Bin Meng, Mark Kettenis, Tom Rini, u-boot, Janne Grunau
Sure. Please send some instructions my way on how to proceed. I know
there is a u-boot manual, but I don't wanna mess up my mac mini m1
system. So I'd stick with instructions on your end. Ideally, the action
is reversible. I always keep complete system backups, though. My current
version is asahi-v2022.10-1 as far as I can tell. I'm used to git, so
pulling and making would be the slightest issue.
All the best and thanks,
---
aka zDEFz
On 01.03.2023 23:51, Marek Vasut wrote:
> On 3/1/23 21:34, Simon Glass wrote:
>> +Marek Vasut +Bin Meng +Mark Kettenis +Tom Rini
>>
>> On Wed, 1 Mar 2023 at 08:12, bluetail <a-development+asahi@posteo.de>
>> wrote:
>>>
>>> Hello. user kettenis aka "Mark Kettenis" guided me write my bug
>>> report
>>> to this email. "bluetail: please report these usb bugs upstream;
>>> they're
>>> almost certainly not hardware-specific"
>>>
>>> But before, jannau aka Janne Grunau asked me to give the version
>>> output
>>> of `pacman -Qi uboot-asahi` to which I replied 2022.10.asahi1-1.
>>> Because I had the feeling that sometimes the reboot with a USB-C
>>> connected device succeeds, depending how many bays are populated. But
>>> I
>>> have no evidence for that.
>>> I did try other USB Type C Cables, but without success of fixing the
>>> underlying issue. The device works fine via USB Type A or C fine if
>>> plugged in AFTER u-boot.
>>> But, u-boot does not support USB Type A yet, which is why it wont
>>> break
>>> my boot sequence with USB Type A.
>>>
>>> Essentially, I connect a mass-storage device to the USB-C port of a
>>> Mac
>>> Mini 2020 (M1), and it leads to the issue in the attachment.
>>> I was able to reproduce it with Icy Box IB-3810 and ICY BOX IB-3805.
>>> Initially I thought this issue was only for some devices (also
>>> attached
>>> here) https://github.com/AsahiLinux/u-boot/issues/4 but it appears
>>> this
>>> might be a issue that is with many devices.
>>>
>>> If you need any more information, please feel free to ask. I am very
>>> eager to have this issue fixed because it seems to be a very broad
>>> issue
>>> with mass media storage in general.
>>> uname-r returns 6.1.0-asahi-2-2-edge-ARCH
> Would it be possible to check whether current u-boot/master works any
> better ?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: u-boot crashes if mass-storage devices are connected via USB-C
2023-03-01 22:51 ` Marek Vasut
2023-03-01 23:30 ` bluetail
@ 2023-03-02 9:14 ` Janne Grunau
2023-03-02 17:33 ` Marek Vasut
1 sibling, 1 reply; 9+ messages in thread
From: Janne Grunau @ 2023-03-02 9:14 UTC (permalink / raw)
To: Marek Vasut
Cc: Simon Glass, bluetail, Bin Meng, Mark Kettenis, Tom Rini, u-boot
On 2023-03-01 23:51:14 +0100, Marek Vasut wrote:
> On 3/1/23 21:34, Simon Glass wrote:
> > +Marek Vasut +Bin Meng +Mark Kettenis +Tom Rini
> >
> > On Wed, 1 Mar 2023 at 08:12, bluetail <a-development+asahi@posteo.de> wrote:
> > >
> > > Hello. user kettenis aka "Mark Kettenis" guided me write my bug report
> > > to this email. "bluetail: please report these usb bugs upstream; they're
> > > almost certainly not hardware-specific"
> > >
> > > But before, jannau aka Janne Grunau asked me to give the version output
> > > of `pacman -Qi uboot-asahi` to which I replied 2022.10.asahi1-1.
> > > Because I had the feeling that sometimes the reboot with a USB-C
> > > connected device succeeds, depending how many bays are populated. But I
> > > have no evidence for that.
> > > I did try other USB Type C Cables, but without success of fixing the
> > > underlying issue. The device works fine via USB Type A or C fine if
> > > plugged in AFTER u-boot.
> > > But, u-boot does not support USB Type A yet, which is why it wont break
> > > my boot sequence with USB Type A.
> > >
> > > Essentially, I connect a mass-storage device to the USB-C port of a Mac
> > > Mini 2020 (M1), and it leads to the issue in the attachment.
> > > I was able to reproduce it with Icy Box IB-3810 and ICY BOX IB-3805.
> > > Initially I thought this issue was only for some devices (also attached
> > > here) https://github.com/AsahiLinux/u-boot/issues/4 but it appears this
> > > might be a issue that is with many devices.
> > >
> > > If you need any more information, please feel free to ask. I am very
> > > eager to have this issue fixed because it seems to be a very broad issue
> > > with mass media storage in general.
> > > uname-r returns 6.1.0-asahi-2-2-edge-ARCH
> Would it be possible to check whether current u-boot/master works any better
Reproduced with b0eda49bc9b0 ("Merge tag 'u-boot-at91-fixes-2023.04-a'
of https://source.denx.de/u-boot/custodians/u-boot-at91") and Icy Box
IB-3804-C31 (same design as IB-3805/IB-3810 but just a single 4 port
USB3 hub + 4 independent asmedia usb3 to sata converters).
| scanning bus usb@b02280000 for devices... Device NOT ready
| Request Sense returned 02 3A 00
| Device NOT ready
| Request Sense returned 02 3A 00
| Resetting EP 0...
| WARN halted endpoint, queueing URB anyway.
| Unexpected XHCI event TRB, skipping... (c9208350 0000010f 13000000 04008401)
| "Synchronous Abort" handler, esr 0x96000005
| elr: 000000000003934c lr : 000000000003934c (reloc)
| elr: 0000010fcd24034c lr : 0000010fcd24034c
| x0 : 0000000000000000 x1 : 00000000000003e8
| x2 : 0000000000000040 x3 : 000000000000003f
| x4 : 0000010fc92065c0 x5 : 0000010fc9208210
| x6 : 0000000000001800 x7 : 00000000300c0300
| x8 : 0000000000000424 x9 : 0000000000000004
| x10: 00000000ffffffe8 x11: 0000000000000010
| x12: 0000000000010000 x13: 0000000000000001
| x14: 0000010fc91c6720 x15: 0000000000000021
| x16: 0000010fcd23a414 x17: 0000000000000040
| x18: 0000010fc91e7d70 x19: 0000010fc92065c0
| x20: 0000010fc9443630 x21: 0000000000000002
| x22: 0000010fc94406f0 x23: 0000000000000080
| x24: 0000000000000000 x25: 0000010fc91c6100
| x26: 0000010fc91c6100 x27: 0000010fc94406f0
| x28: 0000000000000000 x29: 0000010fc91c5db0
|
| Code: 97ffff3c 52800401 aa1303e0 97ffffa2 (b9400c00) Resetting CPU ...
The usb2sata bridges can powered off individually. u-boot crashes with
just a single bridge with HDD powered on. Works if all bridges are off
or don't have a HDD connected.
The bridge reports under linux as
Bus 005 Device 003: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
best regards
Janne
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: u-boot crashes if mass-storage devices are connected via USB-C
2023-03-02 9:14 ` Janne Grunau
@ 2023-03-02 17:33 ` Marek Vasut
2023-03-02 18:51 ` Janne Grunau
0 siblings, 1 reply; 9+ messages in thread
From: Marek Vasut @ 2023-03-02 17:33 UTC (permalink / raw)
To: Janne Grunau
Cc: Simon Glass, bluetail, Bin Meng, Mark Kettenis, Tom Rini, u-boot
On 3/2/23 10:14, Janne Grunau wrote:
> On 2023-03-01 23:51:14 +0100, Marek Vasut wrote:
>> On 3/1/23 21:34, Simon Glass wrote:
>>> +Marek Vasut +Bin Meng +Mark Kettenis +Tom Rini
>>>
>>> On Wed, 1 Mar 2023 at 08:12, bluetail <a-development+asahi@posteo.de> wrote:
>>>>
>>>> Hello. user kettenis aka "Mark Kettenis" guided me write my bug report
>>>> to this email. "bluetail: please report these usb bugs upstream; they're
>>>> almost certainly not hardware-specific"
>>>>
>>>> But before, jannau aka Janne Grunau asked me to give the version output
>>>> of `pacman -Qi uboot-asahi` to which I replied 2022.10.asahi1-1.
>>>> Because I had the feeling that sometimes the reboot with a USB-C
>>>> connected device succeeds, depending how many bays are populated. But I
>>>> have no evidence for that.
>>>> I did try other USB Type C Cables, but without success of fixing the
>>>> underlying issue. The device works fine via USB Type A or C fine if
>>>> plugged in AFTER u-boot.
>>>> But, u-boot does not support USB Type A yet, which is why it wont break
>>>> my boot sequence with USB Type A.
>>>>
>>>> Essentially, I connect a mass-storage device to the USB-C port of a Mac
>>>> Mini 2020 (M1), and it leads to the issue in the attachment.
>>>> I was able to reproduce it with Icy Box IB-3810 and ICY BOX IB-3805.
>>>> Initially I thought this issue was only for some devices (also attached
>>>> here) https://github.com/AsahiLinux/u-boot/issues/4 but it appears this
>>>> might be a issue that is with many devices.
>>>>
>>>> If you need any more information, please feel free to ask. I am very
>>>> eager to have this issue fixed because it seems to be a very broad issue
>>>> with mass media storage in general.
>>>> uname-r returns 6.1.0-asahi-2-2-edge-ARCH
>> Would it be possible to check whether current u-boot/master works any better
>
> Reproduced with b0eda49bc9b0 ("Merge tag 'u-boot-at91-fixes-2023.04-a'
> of https://source.denx.de/u-boot/custodians/u-boot-at91") and Icy Box
> IB-3804-C31 (same design as IB-3805/IB-3810 but just a single 4 port
> USB3 hub + 4 independent asmedia usb3 to sata converters).
>
> | scanning bus usb@b02280000 for devices... Device NOT ready
> | Request Sense returned 02 3A 00
> | Device NOT ready
> | Request Sense returned 02 3A 00
> | Resetting EP 0...
> | WARN halted endpoint, queueing URB anyway.
> | Unexpected XHCI event TRB, skipping... (c9208350 0000010f 13000000 04008401)
> | "Synchronous Abort" handler, esr 0x96000005
> | elr: 000000000003934c lr : 000000000003934c (reloc)
> | elr: 0000010fcd24034c lr : 0000010fcd24034c
Could you decode the trace and check where exactly this exception occurred ?
It should be enough to run "aarch64-...-objdump -lSD u-boot | less" on
the U-Boot which matches the one which generated the trace, and then
look up the lr/elr address in that trace. That should point you to the
exact place in code where the exception occurred .
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: u-boot crashes if mass-storage devices are connected via USB-C
2023-03-02 17:33 ` Marek Vasut
@ 2023-03-02 18:51 ` Janne Grunau
2023-03-02 21:05 ` Marek Vasut
0 siblings, 1 reply; 9+ messages in thread
From: Janne Grunau @ 2023-03-02 18:51 UTC (permalink / raw)
To: Marek Vasut
Cc: Simon Glass, bluetail, Bin Meng, Mark Kettenis, Tom Rini, u-boot
On 2023-03-02 18:33:15 +0100, Marek Vasut wrote:
> On 3/2/23 10:14, Janne Grunau wrote:
> > On 2023-03-01 23:51:14 +0100, Marek Vasut wrote:
> > > On 3/1/23 21:34, Simon Glass wrote:
> > > > +Marek Vasut +Bin Meng +Mark Kettenis +Tom Rini
> > > >
> > > > On Wed, 1 Mar 2023 at 08:12, bluetail <a-development+asahi@posteo.de> wrote:
> > > > >
> > > > > Essentially, I connect a mass-storage device to the USB-C port of a Mac
> > > > > Mini 2020 (M1), and it leads to the issue in the attachment.
> > > > > I was able to reproduce it with Icy Box IB-3810 and ICY BOX IB-3805.
> > > > > Initially I thought this issue was only for some devices (also attached
> > > > > here) https://github.com/AsahiLinux/u-boot/issues/4 but it appears this
> > > > > might be a issue that is with many devices.
> > > > >
> > > > > If you need any more information, please feel free to ask. I am very
> > > > > eager to have this issue fixed because it seems to be a very broad issue
> > > > > with mass media storage in general.
> > > > > uname-r returns 6.1.0-asahi-2-2-edge-ARCH
> > > Would it be possible to check whether current u-boot/master works any better
> >
> > Reproduced with b0eda49bc9b0 ("Merge tag 'u-boot-at91-fixes-2023.04-a'
> > of https://source.denx.de/u-boot/custodians/u-boot-at91") and Icy Box
> > IB-3804-C31 (same design as IB-3805/IB-3810 but just a single 4 port
> > USB3 hub + 4 independent asmedia usb3 to sata converters).
> >
> > | scanning bus usb@b02280000 for devices... Device NOT ready
> > | Request Sense returned 02 3A 00
> > | Device NOT ready
> > | Request Sense returned 02 3A 00
> > | Resetting EP 0...
> > | WARN halted endpoint, queueing URB anyway.
> > | Unexpected XHCI event TRB, skipping... (c9208350 0000010f 13000000 04008401)
> > | "Synchronous Abort" handler, esr 0x96000005
> > | elr: 000000000003934c lr : 000000000003934c (reloc)
> > | elr: 0000010fcd24034c lr : 0000010fcd24034c
>
> Could you decode the trace and check where exactly this exception occurred ?
>
> It should be enough to run "aarch64-...-objdump -lSD u-boot | less" on the
> U-Boot which matches the one which generated the trace, and then look up the
> lr/elr address in that trace. That should point you to the exact place in
> code where the exception occurred .
Slightly different binary due to unrelated chnages:
| scanning bus usb@702280000 for devices... 1 USB Device(s) found
| scanning bus usb@b02280000 for devices... 1 USB Device(s) found
| scanning bus usb@f02280000 for devices... 1 USB Device(s) found
| scanning bus usb@1302280000 for devices... 2 USB Device(s) found
| scanning bus usb@702280000 for devices... 1 USB Device(s) found
| scanning bus usb@b02280000 for devices... Resetting EP 0...
| WARN halted endpoint, queueing URB anyway.
| Unexpected XHCI event TRB, skipping... (c92247b0 0000010f 13000000 02008400)
| "Synchronous Abort" handler, esr 0x96000005
| elr: 0000000000039d9c lr : 0000000000039d9c (reloc)
| elr: 0000010fcd240d9c lr : 0000010fcd240d9c
| x0 : 0000000000000000 x1 : 00000000000003e8
| x2 : 0000000000000040 x3 : 000000000000003f
| x4 : 0000010fc9223040 x5 : 0000010fc921ef90
| x6 : 0000000000001800 x7 : 00000000300c0300
| x8 : 0000000000000424 x9 : 0000000000000008
| x10: 00000000ffffffe8 x11: 0000000000000010
| x12: 0000000000010000 x13: 0000000000000001
| x14: 0000010fc91ba320 x15: 0000000000000021
| x16: 0000010fcd23addc x17: 0000000000000040
| x18: 0000010fc91e7d70 x19: 0000010fc9223040
| x20: 0000010fc9234b20 x21: 0000000000000002
| x22: 0000010fc9233790 x23: 0000000000000080
| x24: 0000000000000000 x25: 0000010fc91b9d00
| x26: 0000010fc91b9d00 x27: 0000010fc9233790
| x28: 0000000000000000 x29: 0000010fc91b99b0
|
| Code: 97ffff3c 52800401 aa1303e0 97ffffa2 (b9400c00)
objdump -lSD u-boot | grep -C 12 ' 39d9c'
| Disassembly of section .text_rest:
| ...
| 39d84: f9400c36 ldr x22, [x1, #24]
| /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:544
| xhci_queue_command(ctrl, 0, udev->slot_id, ep_index, TRB_STOP_RING);
| 39d88: d2800001 mov x1, #0x0 // #0
| 39d8c: 97ffff3c bl 39a7c <xhci_queue_command>
| /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:546
| event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
| 39d90: 52800401 mov w1, #0x20 // #32
| 39d94: aa1303e0 mov x0, x19
| 39d98: 97ffffa2 bl 39c20 <xhci_wait_for_event>
| /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:547
| field = le32_to_cpu(event->trans_event.flags);
| 39d9c: b9400c00 ldr w0, [x0, #12]
| /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:548
| BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
| 39da0: b9494681 ldr w1, [x20, #2372]
| 39da4: 6b40603f cmp w1, w0, lsr #24
| 39da8: 54000180 b.eq 39dd8 <abort_td+0x8c> // b.none
| /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:548 (discriminator 1)
| 39dac: 90000143 adrp x3, 61000 <crc16_tab+0x170>
| 39db0: 913d0863 add x3, x3, #0xf42
| 39db4: 52804482 mov w2, #0x224 // #548
| /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:549 (discriminator 1)
| BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
| 39db8: b0000181 adrp x1, 6a000 <names.0+0x11cb>
not immediately obvious to me what's the problem. x0 looks valid before the ldr.
best regards
Janne
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: u-boot crashes if mass-storage devices are connected via USB-C
2023-03-02 18:51 ` Janne Grunau
@ 2023-03-02 21:05 ` Marek Vasut
2023-03-02 23:47 ` Janne Grunau
0 siblings, 1 reply; 9+ messages in thread
From: Marek Vasut @ 2023-03-02 21:05 UTC (permalink / raw)
To: Janne Grunau
Cc: Simon Glass, bluetail, Bin Meng, Mark Kettenis, Tom Rini, u-boot
On 3/2/23 19:51, Janne Grunau wrote:
> On 2023-03-02 18:33:15 +0100, Marek Vasut wrote:
>> On 3/2/23 10:14, Janne Grunau wrote:
>>> On 2023-03-01 23:51:14 +0100, Marek Vasut wrote:
>>>> On 3/1/23 21:34, Simon Glass wrote:
>>>>> +Marek Vasut +Bin Meng +Mark Kettenis +Tom Rini
>>>>>
>>>>> On Wed, 1 Mar 2023 at 08:12, bluetail <a-development+asahi@posteo.de> wrote:
>>>>>>
>>>>>> Essentially, I connect a mass-storage device to the USB-C port of a Mac
>>>>>> Mini 2020 (M1), and it leads to the issue in the attachment.
>>>>>> I was able to reproduce it with Icy Box IB-3810 and ICY BOX IB-3805.
>>>>>> Initially I thought this issue was only for some devices (also attached
>>>>>> here) https://github.com/AsahiLinux/u-boot/issues/4 but it appears this
>>>>>> might be a issue that is with many devices.
>>>>>>
>>>>>> If you need any more information, please feel free to ask. I am very
>>>>>> eager to have this issue fixed because it seems to be a very broad issue
>>>>>> with mass media storage in general.
>>>>>> uname-r returns 6.1.0-asahi-2-2-edge-ARCH
>>>> Would it be possible to check whether current u-boot/master works any better
>>>
>>> Reproduced with b0eda49bc9b0 ("Merge tag 'u-boot-at91-fixes-2023.04-a'
>>> of https://source.denx.de/u-boot/custodians/u-boot-at91") and Icy Box
>>> IB-3804-C31 (same design as IB-3805/IB-3810 but just a single 4 port
>>> USB3 hub + 4 independent asmedia usb3 to sata converters).
>>>
>>> | scanning bus usb@b02280000 for devices... Device NOT ready
>>> | Request Sense returned 02 3A 00
>>> | Device NOT ready
>>> | Request Sense returned 02 3A 00
>>> | Resetting EP 0...
>>> | WARN halted endpoint, queueing URB anyway.
>>> | Unexpected XHCI event TRB, skipping... (c9208350 0000010f 13000000 04008401)
>>> | "Synchronous Abort" handler, esr 0x96000005
>>> | elr: 000000000003934c lr : 000000000003934c (reloc)
>>> | elr: 0000010fcd24034c lr : 0000010fcd24034c
>>
>> Could you decode the trace and check where exactly this exception occurred ?
>>
>> It should be enough to run "aarch64-...-objdump -lSD u-boot | less" on the
>> U-Boot which matches the one which generated the trace, and then look up the
>> lr/elr address in that trace. That should point you to the exact place in
>> code where the exception occurred .
>
> Slightly different binary due to unrelated chnages:
>
> | scanning bus usb@702280000 for devices... 1 USB Device(s) found
> | scanning bus usb@b02280000 for devices... 1 USB Device(s) found
> | scanning bus usb@f02280000 for devices... 1 USB Device(s) found
> | scanning bus usb@1302280000 for devices... 2 USB Device(s) found
> | scanning bus usb@702280000 for devices... 1 USB Device(s) found
> | scanning bus usb@b02280000 for devices... Resetting EP 0...
> | WARN halted endpoint, queueing URB anyway.
> | Unexpected XHCI event TRB, skipping... (c92247b0 0000010f 13000000 02008400)
> | "Synchronous Abort" handler, esr 0x96000005
> | elr: 0000000000039d9c lr : 0000000000039d9c (reloc)
> | elr: 0000010fcd240d9c lr : 0000010fcd240d9c
> | x0 : 0000000000000000 x1 : 00000000000003e8
> | x2 : 0000000000000040 x3 : 000000000000003f
> | x4 : 0000010fc9223040 x5 : 0000010fc921ef90
> | x6 : 0000000000001800 x7 : 00000000300c0300
> | x8 : 0000000000000424 x9 : 0000000000000008
> | x10: 00000000ffffffe8 x11: 0000000000000010
> | x12: 0000000000010000 x13: 0000000000000001
> | x14: 0000010fc91ba320 x15: 0000000000000021
> | x16: 0000010fcd23addc x17: 0000000000000040
> | x18: 0000010fc91e7d70 x19: 0000010fc9223040
> | x20: 0000010fc9234b20 x21: 0000000000000002
> | x22: 0000010fc9233790 x23: 0000000000000080
> | x24: 0000000000000000 x25: 0000010fc91b9d00
> | x26: 0000010fc91b9d00 x27: 0000010fc9233790
> | x28: 0000000000000000 x29: 0000010fc91b99b0
> |
> | Code: 97ffff3c 52800401 aa1303e0 97ffffa2 (b9400c00)
>
> objdump -lSD u-boot | grep -C 12 ' 39d9c'
>
> | Disassembly of section .text_rest:
> | ...
> | 39d84: f9400c36 ldr x22, [x1, #24]
> | /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:544
> | xhci_queue_command(ctrl, 0, udev->slot_id, ep_index, TRB_STOP_RING);
> | 39d88: d2800001 mov x1, #0x0 // #0
> | 39d8c: 97ffff3c bl 39a7c <xhci_queue_command>
> | /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:546
> | event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
> | 39d90: 52800401 mov w1, #0x20 // #32
> | 39d94: aa1303e0 mov x0, x19
> | 39d98: 97ffffa2 bl 39c20 <xhci_wait_for_event>
> | /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:547
> | field = le32_to_cpu(event->trans_event.flags);
> | 39d9c: b9400c00 ldr w0, [x0, #12]
> | /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:548
> | BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
> | 39da0: b9494681 ldr w1, [x20, #2372]
> | 39da4: 6b40603f cmp w1, w0, lsr #24
> | 39da8: 54000180 b.eq 39dd8 <abort_td+0x8c> // b.none
> | /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:548 (discriminator 1)
> | 39dac: 90000143 adrp x3, 61000 <crc16_tab+0x170>
> | 39db0: 913d0863 add x3, x3, #0xf42
> | 39db4: 52804482 mov w2, #0x224 // #548
> | /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:549 (discriminator 1)
> | BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
> | 39db8: b0000181 adrp x1, 6a000 <names.0+0x11cb>
>
> not immediately obvious to me what's the problem. x0 looks valid before the ldr.
x0 in the splat is
| x0 : 0000000000000000 x1 : 00000000000003e8
so, I think xhci_wait_for_event() returns NULL .
I found this device locally:
New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
Product: ICY BOX IB-366StU3+B
I will see if I can reproduce the problem on iMX8MP DWC3 too, unless
someone wants to dig into it first, which might expedite the fix.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: u-boot crashes if mass-storage devices are connected via USB-C
2023-03-02 21:05 ` Marek Vasut
@ 2023-03-02 23:47 ` Janne Grunau
0 siblings, 0 replies; 9+ messages in thread
From: Janne Grunau @ 2023-03-02 23:47 UTC (permalink / raw)
To: Marek Vasut
Cc: Simon Glass, bluetail, Bin Meng, Mark Kettenis, Tom Rini, u-boot
On 2023-03-02 22:05:43 +0100, Marek Vasut wrote:
> On 3/2/23 19:51, Janne Grunau wrote:
> > On 2023-03-02 18:33:15 +0100, Marek Vasut wrote:
> > > On 3/2/23 10:14, Janne Grunau wrote:
> > > > On 2023-03-01 23:51:14 +0100, Marek Vasut wrote:
> > > > > On 3/1/23 21:34, Simon Glass wrote:
> > > > > > +Marek Vasut +Bin Meng +Mark Kettenis +Tom Rini
> > > > > >
> > > > > > On Wed, 1 Mar 2023 at 08:12, bluetail <a-development+asahi@posteo.de> wrote:
> > > > > > >
> > > > > > > Essentially, I connect a mass-storage device to the USB-C port of a Mac
> > > > > > > Mini 2020 (M1), and it leads to the issue in the attachment.
> > > > > > > I was able to reproduce it with Icy Box IB-3810 and ICY BOX IB-3805.
> > > > > > > Initially I thought this issue was only for some devices (also attached
> > > > > > > here) https://github.com/AsahiLinux/u-boot/issues/4 but it appears this
> > > > > > > might be a issue that is with many devices.
> > > > > > >
> > > > > > > If you need any more information, please feel free to ask. I am very
> > > > > > > eager to have this issue fixed because it seems to be a very broad issue
> > > > > > > with mass media storage in general.
> > > > > > > uname-r returns 6.1.0-asahi-2-2-edge-ARCH
> > > > > Would it be possible to check whether current u-boot/master works any better
> > > >
> > > > Reproduced with b0eda49bc9b0 ("Merge tag 'u-boot-at91-fixes-2023.04-a'
> > > > of https://source.denx.de/u-boot/custodians/u-boot-at91") and Icy Box
> > > > IB-3804-C31 (same design as IB-3805/IB-3810 but just a single 4 port
> > > > USB3 hub + 4 independent asmedia usb3 to sata converters).
> > > >
> > > > | scanning bus usb@b02280000 for devices... Device NOT ready
> > > > | Request Sense returned 02 3A 00
> > > > | Device NOT ready
> > > > | Request Sense returned 02 3A 00
> > > > | Resetting EP 0...
> > > > | WARN halted endpoint, queueing URB anyway.
> > > > | Unexpected XHCI event TRB, skipping... (c9208350 0000010f 13000000 04008401)
> > > > | "Synchronous Abort" handler, esr 0x96000005
> > > > | elr: 000000000003934c lr : 000000000003934c (reloc)
> > > > | elr: 0000010fcd24034c lr : 0000010fcd24034c
> > >
> > > Could you decode the trace and check where exactly this exception occurred ?
> > >
> > > It should be enough to run "aarch64-...-objdump -lSD u-boot | less" on the
> > > U-Boot which matches the one which generated the trace, and then look up the
> > > lr/elr address in that trace. That should point you to the exact place in
> > > code where the exception occurred .
> >
> > Slightly different binary due to unrelated chnages:
> >
> > | scanning bus usb@702280000 for devices... 1 USB Device(s) found
> > | scanning bus usb@b02280000 for devices... 1 USB Device(s) found
> > | scanning bus usb@f02280000 for devices... 1 USB Device(s) found
> > | scanning bus usb@1302280000 for devices... 2 USB Device(s) found
> > | scanning bus usb@702280000 for devices... 1 USB Device(s) found
> > | scanning bus usb@b02280000 for devices... Resetting EP 0...
> > | WARN halted endpoint, queueing URB anyway.
> > | Unexpected XHCI event TRB, skipping... (c92247b0 0000010f 13000000 02008400)
> > | "Synchronous Abort" handler, esr 0x96000005
> > | elr: 0000000000039d9c lr : 0000000000039d9c (reloc)
> > | elr: 0000010fcd240d9c lr : 0000010fcd240d9c
> > | x0 : 0000000000000000 x1 : 00000000000003e8
> > | x2 : 0000000000000040 x3 : 000000000000003f
> > | x4 : 0000010fc9223040 x5 : 0000010fc921ef90
> > | x6 : 0000000000001800 x7 : 00000000300c0300
> > | x8 : 0000000000000424 x9 : 0000000000000008
> > | x10: 00000000ffffffe8 x11: 0000000000000010
> > | x12: 0000000000010000 x13: 0000000000000001
> > | x14: 0000010fc91ba320 x15: 0000000000000021
> > | x16: 0000010fcd23addc x17: 0000000000000040
> > | x18: 0000010fc91e7d70 x19: 0000010fc9223040
> > | x20: 0000010fc9234b20 x21: 0000000000000002
> > | x22: 0000010fc9233790 x23: 0000000000000080
> > | x24: 0000000000000000 x25: 0000010fc91b9d00
> > | x26: 0000010fc91b9d00 x27: 0000010fc9233790
> > | x28: 0000000000000000 x29: 0000010fc91b99b0
> > |
> > | Code: 97ffff3c 52800401 aa1303e0 97ffffa2 (b9400c00)
> >
> > objdump -lSD u-boot | grep -C 12 ' 39d9c'
> >
> > | Disassembly of section .text_rest:
> > | ...
> > | 39d84: f9400c36 ldr x22, [x1, #24]
> > | /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:544
> > | xhci_queue_command(ctrl, 0, udev->slot_id, ep_index, TRB_STOP_RING);
> > | 39d88: d2800001 mov x1, #0x0 // #0
> > | 39d8c: 97ffff3c bl 39a7c <xhci_queue_command>
> > | /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:546
> > | event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
> > | 39d90: 52800401 mov w1, #0x20 // #32
> > | 39d94: aa1303e0 mov x0, x19
> > | 39d98: 97ffffa2 bl 39c20 <xhci_wait_for_event>
> > | /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:547
> > | field = le32_to_cpu(event->trans_event.flags);
> > | 39d9c: b9400c00 ldr w0, [x0, #12]
> > | /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:548
> > | BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
> > | 39da0: b9494681 ldr w1, [x20, #2372]
> > | 39da4: 6b40603f cmp w1, w0, lsr #24
> > | 39da8: 54000180 b.eq 39dd8 <abort_td+0x8c> // b.none
> > | /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:548 (discriminator 1)
> > | 39dac: 90000143 adrp x3, 61000 <crc16_tab+0x170>
> > | 39db0: 913d0863 add x3, x3, #0xf42
> > | 39db4: 52804482 mov w2, #0x224 // #548
> > | /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:549 (discriminator 1)
> > | BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
> > | 39db8: b0000181 adrp x1, 6a000 <names.0+0x11cb>
> >
> > not immediately obvious to me what's the problem. x0 looks valid before the ldr.
>
> x0 in the splat is
> | x0 : 0000000000000000 x1 : 00000000000003e8
> so, I think xhci_wait_for_event() returns NULL .
Indeed, I confused myself earlier since I saw abort_td() finish once.
This is clearly buggy code. 'xhci_wait_for_event(ctrl, TRB_TRANSFER);'
returns NULL on timeouts so the event dereferencing after that needs to
be inside an 'if (event) {}'.
This fixes not the problem as we hit now the 'BUG()' at the end of
xhci_wait_for_event() for TRB_COMPLETION:
| scanning bus usb@b02280000 for devices... Resetting EP 0...
| WARN halted endpoint, queueing URB anyway.
| Unexpected XHCI event TRB, skipping... (c92247b0 0000010f 13000000 02008400)
| XHCI timeout on event type 33... cannot recover.
| BUG at drivers/usb/host/xhci-ring.c:496/xhci_wait_for_event()!
| BUG!
| resetting ..
At least an improvement in the error reporting.
> I found this device locally:
> New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
> Product: ICY BOX IB-366StU3+B
>
> I will see if I can reproduce the problem on iMX8MP DWC3 too, unless someone
> wants to dig into it first, which might expedite the fix.
That seems to be a different asmedia usb to sata bridge as it is only 5
gbps instead of 10 gbps. Still worth trying.
Janne
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2023-03-02 23:47 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-01 13:38 u-boot crashes if mass-storage devices are connected via USB-C bluetail
2023-03-01 20:34 ` Simon Glass
2023-03-01 22:51 ` Marek Vasut
2023-03-01 23:30 ` bluetail
2023-03-02 9:14 ` Janne Grunau
2023-03-02 17:33 ` Marek Vasut
2023-03-02 18:51 ` Janne Grunau
2023-03-02 21:05 ` Marek Vasut
2023-03-02 23:47 ` Janne Grunau
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.