RE: RE: USB: add check to detect host controller hardware removal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
> Sent: Monday, November 6, 2023 4:28 PM
> To: Li, Meng <Meng.Li@xxxxxxxxxxxxx>
> Cc: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>; Steven Rostedt
> <rostedt@xxxxxxxxxxx>; Ingo Molnar <mingo@xxxxxxxxxx>; USB mailing list
> <linux-usb@xxxxxxxxxxxxxxx>; linux-rt-users <linux-rt-users@xxxxxxxxxxxxxxx>
> Subject: Re: RE: USB: add check to detect host controller hardware removal
> 
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and
> know the content is safe.
> 
> On 2023-11-06 03:02:42 [+0000], Li, Meng wrote:
> > > Good.  Meng Li, can you test a patch that replaces the
> > > local_irq_disable() - usb_hcd_irq() - local_irq_enable() lines with
> > > a single call to generic_handle_irq_safe()?
> >
> > It needs an irq number as parameter, what I should pass to this
> > function, 0 or dev->irq or other value?
> 
> dev->irq is what it asks for. I would really appreciate if you would
> instead use the sysfs interface to remove the device prior physically removing
> it. This should solve your trouble.
> 

This is not my original issue that I encountered.
I agree that we should remove the device from sys interface firstly, and then do hot-plug action.
My original issue was the calltrace on RT kernel if I remove the device from sys interface.
# echo 1 > /sys/bus/pci/devices/0001:01:00.0/remove
xhci_hcd 0001:01:00.0: remove, state 1
usb usb2: USB disconnect, device number 1
usb 2-4: USB disconnect, device number 2
xhci_hcd 0001:01:00.0: USB bus 2 deregistered
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46
in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 765, name: sh
root@nxp-ls1043:preempt_count: 0, expected: 0
RCU nest depth: 0, expected: 0
~# CPU: 0 PID: 765 Comm: sh Tainted: G        W          6.1.57-rt10-yocto-preempt-rt #1
Hardware name: LS1043A RDB Board (DT)
Call trace:
 dump_backtrace.part.0+0xc8/0xd4
 show_stack+0x20/0x30
 dump_stack_lvl+0x6c/0x88
 dump_stack+0x18/0x34
 __might_resched+0x160/0x1c0
 rt_spin_lock+0x38/0xb0
 xhci_irq+0x44/0x16d0
 usb_hcd_irq+0x38/0x5c
 usb_hcd_pci_remove+0x84/0x14c
 xhci_pci_remove+0x78/0xc0
 pci_device_remove+0x44/0xcc
 device_remove+0x54/0x8c
 device_release_driver_internal+0x1ec/0x260
 device_release_driver+0x20/0x30
 pci_stop_bus_device+0x8c/0xcc
 pci_stop_and_remove_bus_device_locked+0x28/0x44
 remove_store+0xa0/0xb0
 dev_attr_store+0x20/0x34
 sysfs_kf_write+0x4c/0x5c
 kernfs_fop_write_iter+0x128/0x1f0
 vfs_write+0x1c0/0x2f0
 ksys_write+0x78/0x110
 __arm64_sys_write+0x24/0x30
 invoke_syscall+0x5c/0x130
 el0_svc_common.constprop.0+0x4c/0xf4
 do_el0_svc+0x34/0xc0
 el0_svc+0x2c/0x84
 el0t_64_sync_handler+0xf4/0x120
 el0t_64_sync+0x18c/0x190

and then I checked the commit log to get which commit introduced this issue.
I found out the commit is 
commit c548795abe0d3520b74e18f23ca0a0d72deddab9
Author: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
Date:   Wed Jun 9 17:34:27 2010 -0400

    USB: add check to detect host controller hardware removal

And then, Alan Stern told me the background of this issue. so, I started to do hotplug operation on my board to see what symptom on my nxp-ls1043/6 board.
And then there were lots of discussion followed.

Thanks,
Limeng

> > Thanks,
> > Limeng
> 
> Sebastian




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux