* [PATCH v1] usb: xhci: Check return value of wait for TRB_TRANSFER event @ 2023-10-17 6:20 Minda Chen 2023-10-17 11:20 ` Marek Vasut 0 siblings, 1 reply; 10+ messages in thread From: Minda Chen @ 2023-10-17 6:20 UTC (permalink / raw) To: Bin Meng, Marek Vasut; +Cc: u-boot, Minda Chen xhci_wait_for_event() waiting TRB_TRANSFER event may return NULL. Checking the return value to avoid crash. Signed-off-by: Minda Chen <minda.chen@starfivetech.com> --- drivers/usb/host/xhci-ring.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index c8260cbdf9..5f02ff0769 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -544,6 +544,8 @@ static void abort_td(struct usb_device *udev, int ep_index) xhci_queue_command(ctrl, 0, udev->slot_id, ep_index, TRB_STOP_RING); event = xhci_wait_for_event(ctrl, TRB_TRANSFER); + if (!event) + return; field = le32_to_cpu(event->trans_event.flags); BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id); BUG_ON(TRB_TO_EP_INDEX(field) != ep_index); -- 2.17.1 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v1] usb: xhci: Check return value of wait for TRB_TRANSFER event 2023-10-17 6:20 [PATCH v1] usb: xhci: Check return value of wait for TRB_TRANSFER event Minda Chen @ 2023-10-17 11:20 ` Marek Vasut 2023-10-18 1:22 ` Minda Chen 0 siblings, 1 reply; 10+ messages in thread From: Marek Vasut @ 2023-10-17 11:20 UTC (permalink / raw) To: Minda Chen, Bin Meng; +Cc: u-boot On 10/17/23 08:20, Minda Chen wrote: > xhci_wait_for_event() waiting TRB_TRANSFER event may return > NULL. Checking the return value to avoid crash. > > Signed-off-by: Minda Chen <minda.chen@starfivetech.com> How did you trigger this error ? Is there a reproducer ? Details please ... ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1] usb: xhci: Check return value of wait for TRB_TRANSFER event 2023-10-17 11:20 ` Marek Vasut @ 2023-10-18 1:22 ` Minda Chen 2023-10-18 2:35 ` Marek Vasut 0 siblings, 1 reply; 10+ messages in thread From: Minda Chen @ 2023-10-18 1:22 UTC (permalink / raw) To: Marek Vasut, Bin Meng; +Cc: u-boot On 2023/10/17 19:20, Marek Vasut wrote: > On 10/17/23 08:20, Minda Chen wrote: >> xhci_wait_for_event() waiting TRB_TRANSFER event may return >> NULL. Checking the return value to avoid crash. >> >> Signed-off-by: Minda Chen <minda.chen@starfivetech.com> > > How did you trigger this error ? Is there a reproducer ? Details please ... While Scanning a lenovo usb2.0 udisk， not 100 % reproduce This is log. StarFive # usb reset resetting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... WARN halted endpoint, queueing URB anyway. Unexpected XHCI event TRB, skipping... (f77141f0 00000000 13000000 02008401) Unhandled exception: Load access fault EPC: 00000000f7f563c6 RA: 00000000f7f563c6 TVAL: 000000000000000c EPC: 000000004024a3c6 RA: 000000004024a3c6 reloc adjusted SP: 00000000f76f9a60 GP: 00000000f76fbdd0 TP: 0000000000000001 T0: 00000000f76fa168 T1: 00000000000000ff T2: 0000000000000016 S0: 00000000f7712fc0 S1: 00000000f76fb100 A0: 0000000000000000 A1: 0000000000000000 A2: 00000000f77145d0 A3: 00000000f7714590 A4: 0000000000000000 A5: 0000000000000020 A6: 000000000000000f A7: 0000000000000100 S2: 0000000000000000 S3: 0000000000000000 S4: 00000000f7717050 S5: 00000000f7717050 S6: 0000000080000383 S7: 00000000f76f9dc0 S8: 00000000000000ff S9: 0000000000000001 S10: 00000000f76f9ba0 S11: 0000000000010c04 T3: 0000000000000010 T4: 0000000000000006 T5: 0000000000000080 T6: 00000000f76fa231 Code: 842a f0ef d75f 0593 0200 8522 f0ef ebdf (455c) This is USB info and storage info StarFive # 1: Hub, USB Revision 3.0 - U-Boot XHCI Host Controller - Class: Hub - PacketSize: 512 Configurations: 1 - Vendor: 0x0000 Product 0x0000 Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms 2: Hub, USB Revision 2.10 - USB2.0 Hub - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x2109 Product 0x3431 Version 4.32 Configuration: 1 - Interfaces: 1 Self Powered Remote Wakeup 100mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms 3: Mass Storage, USB Revision 2.0 - Generic Mass Storage 31097778XB15113405 - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x17ef Product 0x38ac Version 1.0 Configuration: 1 - Interfaces: 1 Bus Powered 200mA Interface: 0 - Alternate Setting 0, Endpoints: 2 - Class Mass Storage, Transp. SCSI, Bulk only - Endpoint 1 Out Bulk MaxPacket 512 - Endpoint 2 In Bulk MaxPacket 512 StarFive # usb storage Device 0: Vendor: Rev: 8.07 Prod: Lenovo SX1 64G Type: Removable Hard Disk Capacity: 60000.0 MB = 58.5 GB (122880000 x 512) StarFive # ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1] usb: xhci: Check return value of wait for TRB_TRANSFER event 2023-10-18 1:22 ` Minda Chen @ 2023-10-18 2:35 ` Marek Vasut 2023-10-18 3:46 ` Minda Chen 0 siblings, 1 reply; 10+ messages in thread From: Marek Vasut @ 2023-10-18 2:35 UTC (permalink / raw) To: Minda Chen, Bin Meng; +Cc: u-boot On 10/18/23 03:22, Minda Chen wrote: > > > On 2023/10/17 19:20, Marek Vasut wrote: >> On 10/17/23 08:20, Minda Chen wrote: >>> xhci_wait_for_event() waiting TRB_TRANSFER event may return >>> NULL. Checking the return value to avoid crash. >>> >>> Signed-off-by: Minda Chen <minda.chen@starfivetech.com> >> >> How did you trigger this error ? Is there a reproducer ? Details please ... > > While Scanning a lenovo usb2.0 udisk， not 100 % reproduce Can you include Linux lsusb -vvv output for this device and include that information in the commit message ? (or the U-Boot info below, that works too, just please add it into the commit message, it is important for future reference). > This is log. > > StarFive # usb reset > resetting USB... > Bus xhci_pci: Register 5000420 NbrPorts 5 > Starting the controller > USB XHCI 1.00 > scanning bus xhci_pci for devices... WARN halted endpoint, queueing URB anyway. > Unexpected XHCI event TRB, skipping... (f77141f0 00000000 13000000 02008401) > Unhandled exception: Load access fault > EPC: 00000000f7f563c6 RA: 00000000f7f563c6 TVAL: 000000000000000c > EPC: 000000004024a3c6 RA: 000000004024a3c6 reloc adjusted Where does the crash point to in code, can you disassemble the PC pointer ? (or maybe you can use scripts/decodecode I think) > SP: 00000000f76f9a60 GP: 00000000f76fbdd0 TP: 0000000000000001 > T0: 00000000f76fa168 T1: 00000000000000ff T2: 0000000000000016 > S0: 00000000f7712fc0 S1: 00000000f76fb100 A0: 0000000000000000 > A1: 0000000000000000 A2: 00000000f77145d0 A3: 00000000f7714590 > A4: 0000000000000000 A5: 0000000000000020 A6: 000000000000000f > A7: 0000000000000100 S2: 0000000000000000 S3: 0000000000000000 > S4: 00000000f7717050 S5: 00000000f7717050 S6: 0000000080000383 > S7: 00000000f76f9dc0 S8: 00000000000000ff S9: 0000000000000001 > S10: 00000000f76f9ba0 S11: 0000000000010c04 T3: 0000000000000010 > T4: 0000000000000006 T5: 0000000000000080 T6: 00000000f76fa231 [...] > 3: Mass Storage, USB Revision 2.0 > - Generic Mass Storage 31097778XB15113405 > - Class: (from Interface) Mass Storage > - PacketSize: 64 Configurations: 1 > - Vendor: 0x17ef Product 0x38ac Version 1.0 > Configuration: 1 > - Interfaces: 1 Bus Powered 200mA > Interface: 0 > - Alternate Setting 0, Endpoints: 2 > - Class Mass Storage, Transp. SCSI, Bulk only > - Endpoint 1 Out Bulk MaxPacket 512 > - Endpoint 2 In Bulk MaxPacket 512 > > StarFive # usb storage > Device 0: Vendor: Rev: 8.07 Prod: Lenovo SX1 64G > Type: Removable Hard Disk > Capacity: 60000.0 MB = 58.5 GB (122880000 x 512) [...] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1] usb: xhci: Check return value of wait for TRB_TRANSFER event 2023-10-18 2:35 ` Marek Vasut @ 2023-10-18 3:46 ` Minda Chen 2023-10-18 10:11 ` Marek Vasut 0 siblings, 1 reply; 10+ messages in thread From: Minda Chen @ 2023-10-18 3:46 UTC (permalink / raw) To: Marek Vasut, Bin Meng; +Cc: u-boot On 2023/10/18 10:35, Marek Vasut wrote: > On 10/18/23 03:22, Minda Chen wrote: >> >> >> On 2023/10/17 19:20, Marek Vasut wrote: >>> On 10/17/23 08:20, Minda Chen wrote: >>>> xhci_wait_for_event() waiting TRB_TRANSFER event may return >>>> NULL. Checking the return value to avoid crash. >>>> >>>> Signed-off-by: Minda Chen <minda.chen@starfivetech.com> >>> >>> How did you trigger this error ? Is there a reproducer ? Details please ... >> >> While Scanning a lenovo usb2.0 udisk， not 100 % reproduce > > Can you include Linux > > lsusb -vvv > > output for this device and include that information in the commit message ? (or the U-Boot info below, that works too, just please add it into the commit message, it is important for future reference). > OK， I will add lsusb -vvv Linux udisk message and crash dump info to commit message >> This is log. >> >> StarFive # usb reset >> resetting USB... >> Bus xhci_pci: Register 5000420 NbrPorts 5 >> Starting the controller >> USB XHCI 1.00 >> scanning bus xhci_pci for devices... WARN halted endpoint, queueing URB anyway. >> Unexpected XHCI event TRB, skipping... (f77141f0 00000000 13000000 02008401) >> Unhandled exception: Load access fault >> EPC: 00000000f7f563c6 RA: 00000000f7f563c6 TVAL: 000000000000000c >> EPC: 000000004024a3c6 RA: 000000004024a3c6 reloc adjusted > > Where does the crash point to in code, can you disassemble the PC pointer ? (or maybe you can use scripts/decodecode I think) > OK， I will add EPC pointer disassemble to commit message >> SP: 00000000f76f9a60 GP: 00000000f76fbdd0 TP: 0000000000000001 >> T0: 00000000f76fa168 T1: 00000000000000ff T2: 0000000000000016 >> S0: 00000000f7712fc0 S1: 00000000f76fb100 A0: 0000000000000000 >> A1: 0000000000000000 A2: 00000000f77145d0 A3: 00000000f7714590 >> A4: 0000000000000000 A5: 0000000000000020 A6: 000000000000000f >> A7: 0000000000000100 S2: 0000000000000000 S3: 0000000000000000 >> S4: 00000000f7717050 S5: 00000000f7717050 S6: 0000000080000383 >> S7: 00000000f76f9dc0 S8: 00000000000000ff S9: 0000000000000001 >> S10: 00000000f76f9ba0 S11: 0000000000010c04 T3: 0000000000000010 >> T4: 0000000000000006 T5: 0000000000000080 T6: 00000000f76fa231 > > [...] > >> 3: Mass Storage, USB Revision 2.0 >> - Generic Mass Storage 31097778XB15113405 >> - Class: (from Interface) Mass Storage >> - PacketSize: 64 Configurations: 1 >> - Vendor: 0x17ef Product 0x38ac Version 1.0 >> Configuration: 1 >> - Interfaces: 1 Bus Powered 200mA >> Interface: 0 >> - Alternate Setting 0, Endpoints: 2 >> - Class Mass Storage, Transp. SCSI, Bulk only >> - Endpoint 1 Out Bulk MaxPacket 512 >> - Endpoint 2 In Bulk MaxPacket 512 >> >> StarFive # usb storage >> Device 0: Vendor: Rev: 8.07 Prod: Lenovo SX1 64G >> Type: Removable Hard Disk >> Capacity: 60000.0 MB = 58.5 GB (122880000 x 512) > > [...] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1] usb: xhci: Check return value of wait for TRB_TRANSFER event 2023-10-18 3:46 ` Minda Chen @ 2023-10-18 10:11 ` Marek Vasut 2023-10-18 10:16 ` Minda Chen 0 siblings, 1 reply; 10+ messages in thread From: Marek Vasut @ 2023-10-18 10:11 UTC (permalink / raw) To: Minda Chen, Bin Meng; +Cc: u-boot On 10/18/23 05:46, Minda Chen wrote: > > > On 2023/10/18 10:35, Marek Vasut wrote: >> On 10/18/23 03:22, Minda Chen wrote: >>> >>> >>> On 2023/10/17 19:20, Marek Vasut wrote: >>>> On 10/17/23 08:20, Minda Chen wrote: >>>>> xhci_wait_for_event() waiting TRB_TRANSFER event may return >>>>> NULL. Checking the return value to avoid crash. >>>>> >>>>> Signed-off-by: Minda Chen <minda.chen@starfivetech.com> >>>> >>>> How did you trigger this error ? Is there a reproducer ? Details please ... >>> >>> While Scanning a lenovo usb2.0 udisk， not 100 % reproduce >> >> Can you include Linux >> >> lsusb -vvv >> >> output for this device and include that information in the commit message ? (or the U-Boot info below, that works too, just please add it into the commit message, it is important for future reference). >> > OK， I will add lsusb -vvv Linux udisk message and crash dump info to commit message Thank you >>> This is log. >>> >>> StarFive # usb reset >>> resetting USB... >>> Bus xhci_pci: Register 5000420 NbrPorts 5 >>> Starting the controller >>> USB XHCI 1.00 >>> scanning bus xhci_pci for devices... WARN halted endpoint, queueing URB anyway. >>> Unexpected XHCI event TRB, skipping... (f77141f0 00000000 13000000 02008401) >>> Unhandled exception: Load access fault >>> EPC: 00000000f7f563c6 RA: 00000000f7f563c6 TVAL: 000000000000000c >>> EPC: 000000004024a3c6 RA: 000000004024a3c6 reloc adjusted >> >> Where does the crash point to in code, can you disassemble the PC pointer ? (or maybe you can use scripts/decodecode I think) >> > OK， I will add EPC pointer disassemble to commit message This part probably doesn't need to be in the commit message. I'd like to know where the crash occurred in the code. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1] usb: xhci: Check return value of wait for TRB_TRANSFER event 2023-10-18 10:11 ` Marek Vasut @ 2023-10-18 10:16 ` Minda Chen 2023-10-18 10:55 ` Marek Vasut 0 siblings, 1 reply; 10+ messages in thread From: Minda Chen @ 2023-10-18 10:16 UTC (permalink / raw) To: Marek Vasut, Bin Meng; +Cc: u-boot On 2023/10/18 18:11, Marek Vasut wrote: > On 10/18/23 05:46, Minda Chen wrote: >> >> >> On 2023/10/18 10:35, Marek Vasut wrote: >>> On 10/18/23 03:22, Minda Chen wrote: >>>> >>>> >>>> On 2023/10/17 19:20, Marek Vasut wrote: >>>>> On 10/17/23 08:20, Minda Chen wrote: >>>>>> xhci_wait_for_event() waiting TRB_TRANSFER event may return >>>>>> NULL. Checking the return value to avoid crash. >>>>>> >>>>>> Signed-off-by: Minda Chen <minda.chen@starfivetech.com> >>>>> >>>>> How did you trigger this error ? Is there a reproducer ? Details please ... >>>> >>>> While Scanning a lenovo usb2.0 udisk， not 100 % reproduce >>> >>> Can you include Linux >>> >>> lsusb -vvv >>> >>> output for this device and include that information in the commit message ? (or the U-Boot info below, that works too, just please add it into the commit message, it is important for future reference). >>> >> OK， I will add lsusb -vvv Linux udisk message and crash dump info to commit message > > Thank you > >>>> This is log. >>>> >>>> StarFive # usb reset >>>> resetting USB... >>>> Bus xhci_pci: Register 5000420 NbrPorts 5 >>>> Starting the controller >>>> USB XHCI 1.00 >>>> scanning bus xhci_pci for devices... WARN halted endpoint, queueing URB anyway. >>>> Unexpected XHCI event TRB, skipping... (f77141f0 00000000 13000000 02008401) >>>> Unhandled exception: Load access fault >>>> EPC: 00000000f7f563c6 RA: 00000000f7f563c6 TVAL: 000000000000000c >>>> EPC: 000000004024a3c6 RA: 000000004024a3c6 reloc adjusted >>> >>> Where does the crash point to in code, can you disassemble the PC pointer ? (or maybe you can use scripts/decodecode I think) >>> >> OK， I will add EPC pointer disassemble to commit message > > This part probably doesn't need to be in the commit message. I'd like to know where the crash occurred in the code. 000000004024a376 <abort_td>: { 4024a376: 7179 addi sp,sp,-48 4024a378: f406 sd ra,40(sp) 4024a37a: f022 sd s0,32(sp) 4024a37c: ec26 sd s1,24(sp) 4024a37e: e84a sd s2,16(sp) 4024a380: e44e sd s3,8(sp) 4024a382: e052 sd s4,0(sp) 4024a384: 89ae mv s3,a1 4024a386: 84aa mv s1,a0 struct xhci_ctrl *ctrl = xhci_get_ctrl(udev); 4024a388: 8c4fe0ef jal ra,4024844c <xhci_get_ctrl> struct xhci_ring *ring = ctrl->devs[udev->slot_id]->eps[ep_index].ring; 4024a38c: 6785 lui a5,0x1 4024a38e: 94be add s1,s1,a5 4024a390: 9444a603 lw a2,-1724(s1) 4024a394: 00198713 addi a4,s3,1 4024a398: 0712 slli a4,a4,0x4 4024a39a: 02061793 slli a5,a2,0x20 4024a39e: 9381 srli a5,a5,0x20 4024a3a0: 07c9 addi a5,a5,18 4024a3a2: 078e slli a5,a5,0x3 4024a3a4: 97aa add a5,a5,a0 4024a3a6: 679c ld a5,8(a5) xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING); 4024a3a8: 2981 sext.w s3,s3 4024a3aa: 86ce mv a3,s3 struct xhci_ring *ring = ctrl->devs[udev->slot_id]->eps[ep_index].ring; 4024a3ac: 97ba add a5,a5,a4 xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING); 4024a3ae: 4581 li a1,0 4024a3b0: 473d li a4,15 struct xhci_ring *ring = ctrl->devs[udev->slot_id]->eps[ep_index].ring; 4024a3b2: 0087ba03 ld s4,8(a5) # 1008 <_start-0x401feff8> struct xhci_ctrl *ctrl = xhci_get_ctrl(udev); 4024a3b6: 842a mv s0,a0 xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING); 4024a3b8: d75ff0ef jal ra,4024a12c <xhci_queue_command> event = xhci_wait_for_event(ctrl, TRB_TRANSFER); 4024a3bc: 02000593 li a1,32 4024a3c0: 8522 mv a0,s0 4024a3c2: ebdff0ef jal ra,4024a27e <xhci_wait_for_event> field = le32_to_cpu(event->trans_event.flags); epc-> 4024a3c6: 455c lw a5,12(a0) BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id); 4024a3c8: 9444a703 lw a4,-1724(s1) field = le32_to_cpu(event->trans_event.flags); 4024a3cc: 0007891b sext.w s2,a5 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1] usb: xhci: Check return value of wait for TRB_TRANSFER event 2023-10-18 10:16 ` Minda Chen @ 2023-10-18 10:55 ` Marek Vasut 2023-10-19 2:46 ` Minda Chen 0 siblings, 1 reply; 10+ messages in thread From: Marek Vasut @ 2023-10-18 10:55 UTC (permalink / raw) To: Minda Chen, Bin Meng; +Cc: u-boot On 10/18/23 12:16, Minda Chen wrote: > > > On 2023/10/18 18:11, Marek Vasut wrote: >> On 10/18/23 05:46, Minda Chen wrote: >>> >>> >>> On 2023/10/18 10:35, Marek Vasut wrote: >>>> On 10/18/23 03:22, Minda Chen wrote: >>>>> >>>>> >>>>> On 2023/10/17 19:20, Marek Vasut wrote: >>>>>> On 10/17/23 08:20, Minda Chen wrote: >>>>>>> xhci_wait_for_event() waiting TRB_TRANSFER event may return >>>>>>> NULL. Checking the return value to avoid crash. >>>>>>> >>>>>>> Signed-off-by: Minda Chen <minda.chen@starfivetech.com> >>>>>> >>>>>> How did you trigger this error ? Is there a reproducer ? Details please ... >>>>> >>>>> While Scanning a lenovo usb2.0 udisk， not 100 % reproduce >>>> >>>> Can you include Linux >>>> >>>> lsusb -vvv >>>> >>>> output for this device and include that information in the commit message ? (or the U-Boot info below, that works too, just please add it into the commit message, it is important for future reference). >>>> >>> OK， I will add lsusb -vvv Linux udisk message and crash dump info to commit message >> >> Thank you >> >>>>> This is log. >>>>> >>>>> StarFive # usb reset >>>>> resetting USB... >>>>> Bus xhci_pci: Register 5000420 NbrPorts 5 >>>>> Starting the controller >>>>> USB XHCI 1.00 >>>>> scanning bus xhci_pci for devices... WARN halted endpoint, queueing URB anyway. >>>>> Unexpected XHCI event TRB, skipping... (f77141f0 00000000 13000000 02008401) >>>>> Unhandled exception: Load access fault >>>>> EPC: 00000000f7f563c6 RA: 00000000f7f563c6 TVAL: 000000000000000c >>>>> EPC: 000000004024a3c6 RA: 000000004024a3c6 reloc adjusted >>>> >>>> Where does the crash point to in code, can you disassemble the PC pointer ? (or maybe you can use scripts/decodecode I think) >>>> >>> OK， I will add EPC pointer disassemble to commit message >> >> This part probably doesn't need to be in the commit message. I'd like to know where the crash occurred in the code. > > > 000000004024a376 <abort_td>: > { > 4024a376: 7179 addi sp,sp,-48 > 4024a378: f406 sd ra,40(sp) > 4024a37a: f022 sd s0,32(sp) > 4024a37c: ec26 sd s1,24(sp) > 4024a37e: e84a sd s2,16(sp) > 4024a380: e44e sd s3,8(sp) > 4024a382: e052 sd s4,0(sp) > 4024a384: 89ae mv s3,a1 > 4024a386: 84aa mv s1,a0 > struct xhci_ctrl *ctrl = xhci_get_ctrl(udev); > 4024a388: 8c4fe0ef jal ra,4024844c <xhci_get_ctrl> > struct xhci_ring *ring = ctrl->devs[udev->slot_id]->eps[ep_index].ring; > 4024a38c: 6785 lui a5,0x1 > 4024a38e: 94be add s1,s1,a5 > 4024a390: 9444a603 lw a2,-1724(s1) > 4024a394: 00198713 addi a4,s3,1 > 4024a398: 0712 slli a4,a4,0x4 > 4024a39a: 02061793 slli a5,a2,0x20 > 4024a39e: 9381 srli a5,a5,0x20 > 4024a3a0: 07c9 addi a5,a5,18 > 4024a3a2: 078e slli a5,a5,0x3 > 4024a3a4: 97aa add a5,a5,a0 > 4024a3a6: 679c ld a5,8(a5) > xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING); > 4024a3a8: 2981 sext.w s3,s3 > 4024a3aa: 86ce mv a3,s3 > struct xhci_ring *ring = ctrl->devs[udev->slot_id]->eps[ep_index].ring; > 4024a3ac: 97ba add a5,a5,a4 > xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING); > 4024a3ae: 4581 li a1,0 > 4024a3b0: 473d li a4,15 > struct xhci_ring *ring = ctrl->devs[udev->slot_id]->eps[ep_index].ring; > 4024a3b2: 0087ba03 ld s4,8(a5) # 1008 <_start-0x401feff8> > struct xhci_ctrl *ctrl = xhci_get_ctrl(udev); > 4024a3b6: 842a mv s0,a0 > xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING); > 4024a3b8: d75ff0ef jal ra,4024a12c <xhci_queue_command> > event = xhci_wait_for_event(ctrl, TRB_TRANSFER); > 4024a3bc: 02000593 li a1,32 > 4024a3c0: 8522 mv a0,s0 > 4024a3c2: ebdff0ef jal ra,4024a27e <xhci_wait_for_event> > field = le32_to_cpu(event->trans_event.flags); > epc-> 4024a3c6: 455c lw a5,12(a0) So the fault occurs when reading the controller register(s), do I understand it right ? Could it be the problem is rather some clock, which are turned off after a fault ? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1] usb: xhci: Check return value of wait for TRB_TRANSFER event 2023-10-18 10:55 ` Marek Vasut @ 2023-10-19 2:46 ` Minda Chen 2023-10-19 3:22 ` Marek Vasut 0 siblings, 1 reply; 10+ messages in thread From: Minda Chen @ 2023-10-19 2:46 UTC (permalink / raw) To: Marek Vasut, Bin Meng; +Cc: u-boot On 2023/10/18 18:55, Marek Vasut wrote: > On 10/18/23 12:16, Minda Chen wrote: >> >> >> On 2023/10/18 18:11, Marek Vasut wrote: >>> On 10/18/23 05:46, Minda Chen wrote: >>>> >>>> >>>> On 2023/10/18 10:35, Marek Vasut wrote: >>>>> On 10/18/23 03:22, Minda Chen wrote: >>>>>> >>>>>> >>>>>> On 2023/10/17 19:20, Marek Vasut wrote: >>>>>>> On 10/17/23 08:20, Minda Chen wrote: >>>>>>>> xhci_wait_for_event() waiting TRB_TRANSFER event may return >>>>>>>> NULL. Checking the return value to avoid crash. >>>>>>>> >>>>>>>> Signed-off-by: Minda Chen <minda.chen@starfivetech.com> >>>>>>> >>>>>>> How did you trigger this error ? Is there a reproducer ? Details please ... >>>>>> >>>>>> While Scanning a lenovo usb2.0 udisk， not 100 % reproduce >>>>> >>>>> Can you include Linux >>>>> >>>>> lsusb -vvv >>>>> >>>>> output for this device and include that information in the commit message ? (or the U-Boot info below, that works too, just please add it into the commit message, it is important for future reference). >>>>> >>>> OK， I will add lsusb -vvv Linux udisk message and crash dump info to commit message >>> >>> Thank you >>> >>>>>> This is log. >>>>>> >>>>>> StarFive # usb reset >>>>>> resetting USB... >>>>>> Bus xhci_pci: Register 5000420 NbrPorts 5 >>>>>> Starting the controller >>>>>> USB XHCI 1.00 >>>>>> scanning bus xhci_pci for devices... WARN halted endpoint, queueing URB anyway. >>>>>> Unexpected XHCI event TRB, skipping... (f77141f0 00000000 13000000 02008401) >>>>>> Unhandled exception: Load access fault >>>>>> EPC: 00000000f7f563c6 RA: 00000000f7f563c6 TVAL: 000000000000000c >>>>>> EPC: 000000004024a3c6 RA: 000000004024a3c6 reloc adjusted >>>>> >>>>> Where does the crash point to in code, can you disassemble the PC pointer ? (or maybe you can use scripts/decodecode I think) >>>>> >>>> OK， I will add EPC pointer disassemble to commit message >>> >>> This part probably doesn't need to be in the commit message. I'd like to know where the crash occurred in the code. >> >> >> 000000004024a376 <abort_td>: >> { >> 4024a376: 7179 addi sp,sp,-48 >> 4024a378: f406 sd ra,40(sp) >> 4024a37a: f022 sd s0,32(sp) >> 4024a37c: ec26 sd s1,24(sp) >> 4024a37e: e84a sd s2,16(sp) >> 4024a380: e44e sd s3,8(sp) >> 4024a382: e052 sd s4,0(sp) >> 4024a384: 89ae mv s3,a1 >> 4024a386: 84aa mv s1,a0 >> struct xhci_ctrl *ctrl = xhci_get_ctrl(udev); >> 4024a388: 8c4fe0ef jal ra,4024844c <xhci_get_ctrl> >> struct xhci_ring *ring = ctrl->devs[udev->slot_id]->eps[ep_index].ring; >> 4024a38c: 6785 lui a5,0x1 >> 4024a38e: 94be add s1,s1,a5 >> 4024a390: 9444a603 lw a2,-1724(s1) >> 4024a394: 00198713 addi a4,s3,1 >> 4024a398: 0712 slli a4,a4,0x4 >> 4024a39a: 02061793 slli a5,a2,0x20 >> 4024a39e: 9381 srli a5,a5,0x20 >> 4024a3a0: 07c9 addi a5,a5,18 >> 4024a3a2: 078e slli a5,a5,0x3 >> 4024a3a4: 97aa add a5,a5,a0 >> 4024a3a6: 679c ld a5,8(a5) >> xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING); >> 4024a3a8: 2981 sext.w s3,s3 >> 4024a3aa: 86ce mv a3,s3 >> struct xhci_ring *ring = ctrl->devs[udev->slot_id]->eps[ep_index].ring; >> 4024a3ac: 97ba add a5,a5,a4 >> xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING); >> 4024a3ae: 4581 li a1,0 >> 4024a3b0: 473d li a4,15 >> struct xhci_ring *ring = ctrl->devs[udev->slot_id]->eps[ep_index].ring; >> 4024a3b2: 0087ba03 ld s4,8(a5) # 1008 <_start-0x401feff8> >> struct xhci_ctrl *ctrl = xhci_get_ctrl(udev); >> 4024a3b6: 842a mv s0,a0 >> xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING); >> 4024a3b8: d75ff0ef jal ra,4024a12c <xhci_queue_command> >> event = xhci_wait_for_event(ctrl, TRB_TRANSFER); >> 4024a3bc: 02000593 li a1,32 >> 4024a3c0: 8522 mv a0,s0 >> 4024a3c2: ebdff0ef jal ra,4024a27e <xhci_wait_for_event> >> field = le32_to_cpu(event->trans_event.flags); >> epc-> 4024a3c6: 455c lw a5,12(a0) > > So the fault occurs when reading the controller register(s), do I understand it right ? > I think it is right. Actually this error occur in error path, control tx transfer TRB_TRANSFER error occur and jump to error path. sending TRB_TRANSFER again. > Could it be the problem is rather some clock, which are turned off after a fault ? I think not. Just this udisk can reproduce this issue. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1] usb: xhci: Check return value of wait for TRB_TRANSFER event 2023-10-19 2:46 ` Minda Chen @ 2023-10-19 3:22 ` Marek Vasut 0 siblings, 0 replies; 10+ messages in thread From: Marek Vasut @ 2023-10-19 3:22 UTC (permalink / raw) To: Minda Chen, Bin Meng; +Cc: u-boot On 10/19/23 04:46, Minda Chen wrote: [...] >>> 000000004024a376 <abort_td>: >>> { >>> 4024a376: 7179 addi sp,sp,-48 >>> 4024a378: f406 sd ra,40(sp) >>> 4024a37a: f022 sd s0,32(sp) >>> 4024a37c: ec26 sd s1,24(sp) >>> 4024a37e: e84a sd s2,16(sp) >>> 4024a380: e44e sd s3,8(sp) >>> 4024a382: e052 sd s4,0(sp) >>> 4024a384: 89ae mv s3,a1 >>> 4024a386: 84aa mv s1,a0 >>> struct xhci_ctrl *ctrl = xhci_get_ctrl(udev); >>> 4024a388: 8c4fe0ef jal ra,4024844c <xhci_get_ctrl> >>> struct xhci_ring *ring = ctrl->devs[udev->slot_id]->eps[ep_index].ring; >>> 4024a38c: 6785 lui a5,0x1 >>> 4024a38e: 94be add s1,s1,a5 >>> 4024a390: 9444a603 lw a2,-1724(s1) >>> 4024a394: 00198713 addi a4,s3,1 >>> 4024a398: 0712 slli a4,a4,0x4 >>> 4024a39a: 02061793 slli a5,a2,0x20 >>> 4024a39e: 9381 srli a5,a5,0x20 >>> 4024a3a0: 07c9 addi a5,a5,18 >>> 4024a3a2: 078e slli a5,a5,0x3 >>> 4024a3a4: 97aa add a5,a5,a0 >>> 4024a3a6: 679c ld a5,8(a5) >>> xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING); >>> 4024a3a8: 2981 sext.w s3,s3 >>> 4024a3aa: 86ce mv a3,s3 >>> struct xhci_ring *ring = ctrl->devs[udev->slot_id]->eps[ep_index].ring; >>> 4024a3ac: 97ba add a5,a5,a4 >>> xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING); >>> 4024a3ae: 4581 li a1,0 >>> 4024a3b0: 473d li a4,15 >>> struct xhci_ring *ring = ctrl->devs[udev->slot_id]->eps[ep_index].ring; >>> 4024a3b2: 0087ba03 ld s4,8(a5) # 1008 <_start-0x401feff8> >>> struct xhci_ctrl *ctrl = xhci_get_ctrl(udev); >>> 4024a3b6: 842a mv s0,a0 >>> xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING); >>> 4024a3b8: d75ff0ef jal ra,4024a12c <xhci_queue_command> >>> event = xhci_wait_for_event(ctrl, TRB_TRANSFER); >>> 4024a3bc: 02000593 li a1,32 >>> 4024a3c0: 8522 mv a0,s0 >>> 4024a3c2: ebdff0ef jal ra,4024a27e <xhci_wait_for_event> >>> field = le32_to_cpu(event->trans_event.flags); >>> epc-> 4024a3c6: 455c lw a5,12(a0) >> >> So the fault occurs when reading the controller register(s), do I understand it right ? >> > I think it is right. Actually this error occur in error path, control tx transfer TRB_TRANSFER error occur and jump to error path. > sending TRB_TRANSFER again. >> Could it be the problem is rather some clock, which are turned off after a fault ? > I think not. Just this udisk can reproduce this issue. Can you take a closer look into this ? Is there maybe some hardware debug tool which can clarify what is going on better ? It seems weird that controller register access would trigger this kind of bus fault (it is a bus fault, right ?) ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2023-10-19 3:22 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-10-17 6:20 [PATCH v1] usb: xhci: Check return value of wait for TRB_TRANSFER event Minda Chen 2023-10-17 11:20 ` Marek Vasut 2023-10-18 1:22 ` Minda Chen 2023-10-18 2:35 ` Marek Vasut 2023-10-18 3:46 ` Minda Chen 2023-10-18 10:11 ` Marek Vasut 2023-10-18 10:16 ` Minda Chen 2023-10-18 10:55 ` Marek Vasut 2023-10-19 2:46 ` Minda Chen 2023-10-19 3:22 ` Marek Vasut
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox