RE: usb_alloc_device: Failure selecting configuration index 0:USB_ERR_TIMEOUT, port 1, addr 2 (ignored)
Hi HPS, Thanks for replying. We never saw this issue with previous versions of Freebsd (FreeBSD 6.x & FreeBSD 7.x) booted on the same hardware system. But with FreeBSD 8 we can reproduce it in 3-4 hours. Does this make case 1 more likely? Should below quirks resolve the issue in either case? I will give it a try anyway :) Thanks, Vishal -Original Message- From: Hans Petter Selasky [mailto:hsela...@c2i.net] Sent: Thursday, November 10, 2011 12:29 AM To: freebsd-usb@freebsd.org Cc: Shah, Vishal; Ranaweera, Samantha Subject: Re: usb_alloc_device: Failure selecting configuration index 0:USB_ERR_TIMEOUT, port 1, addr 2 (ignored) On Thursday 10 November 2011 05:08:30 Shah, Vishal wrote: > usb_alloc_device: Failure selecting configuration index > 0:USB_ERR_TIMEOUT, port 1, addr 2 (ignored)\r\r\n Hi, The set config message is sent on the control endpoint. The set config message doesn't have any data stage, so the USB stack is waiting for the status stage callback. Either that is caused by: 1) Lost interrupt on EHCI or 2) Device never sends the status stage (needs a bus analyzer for this). Quirks you can set in /boot/loader.conf: hw.usb.ehci.lostintrbug: 0 hw.usb.ehci.iaadbug: 0 --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
usb_alloc_device: Failure selecting configuration index 0:USB_ERR_TIMEOUT, port 1, addr 2 (ignored)
Hi All, This is regarding the issue we are seeing in the FreeBSD 8 USB driver. I have a USB flash device from which the system is booted. Occasionally USB device fails to get initialized in the system. So I enabled USB_DEBUG option and added few more printfs for debugging purpose. After multiple iterations of rebooting I am able to reproduce the issue and I see following messages on console while booting the system. Have any similar issue been reported previously? parent_dev=0xff0004208300, bus=0xff8001053c90, parent_hub=0, depth=0, port_index=0, port_no=1, speed=3, usb_mode=0\r\r\n parent_dev=0xff0004233400, bus=0xff800105cc90, parent_hub=0, depth=0, port_index=0, port_no=1, speed=3, usb_mode=0\r\r\n adding unit addr=1, rev=200, class=9, subclass=0, protocol=1, maxpacket=64, len=8, speed=3\r\r\n setting config 0\r\r\n new dev (addr 1), udev=0xff00041b1000, parent_hub=0\r\r\n ugen0.1: at usbus0\r\r\n usb_probe_and_attach: enter\r\r\n iclass=9/0/0 iindex=0/0\r\r\n adding unit addr=1, rev=200, class=9, subclass=0, protocol=1, maxpacket=64, len=8, speed=3\r\r\n setting config 0\r\r\n new dev (addr 1), udev=0xff00020f9800, parent_hub=0\r\r\n ugen1.1: at usbus1\r\r\n usb_probe_and_attach: enter\r\r\n iclass=9/0/0 iindex=0/0\r\r\n parent_dev=0xff0004332100, bus=0xff800105cc90, parent_hub=0xff00020f9800, depth=1, port_index=0, port_no=1, speed=3, usb_mode=0\r\r\n adding unit addr=2, rev=200, class=0, subclass=0, protocol=0, maxpacket=64, len=8, speed=3\r\r\n setting config 0\r\r\n Root mount waiting for: usbus1\r\r\n Root mount waiting for: usbus1\r\r\n setting config 0\r\r\n Root mount waiting for: usbus1\r\r\n usb_alloc_device: Failure selecting configuration index 0:USB_ERR_TIMEOUT, port 1, addr 2 (ignored)\r\r\n new dev (addr 2), udev=0xff0004357800, parent_hub=0xff00020f9800\r\r\n ugen1.2: at usbus1\r\r\n usb_probe_and_attach: enter\r\r\n /dev/da0s1: No such file or directory\r\n Can you please guide me in resolving this issue? Thanks in advance. Thanks, Vishal ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
RE: System hang in USB umass module while processing panic
Hi Hans Petter, Thanks for looking into this. The command is not hanging on a USB device. The issue is, command never reaches the USB device. As I understand it, after receiving the command from the upper layers, umass layer will just enqueue the xfer at the USBD layer. And then usb_proc process is supposed to take the xfer from the queue and give it to the EHCI layer. When the system panics and gets into the uni-processor environment, the current process issues a SYNCHRONIZE_CACHE command keeps polling the umass layer for the completion of that xfer, and won't leave the single running CPU. For this reason, the usb_proc is never scheduled after that and the xfer never reaches the USB device. Thanks, Vishal -Original Message- From: Hans Petter Selasky [mailto:hsela...@freebsd.org] Sent: Wednesday, May 25, 2011 8:11 AM To: Andriy Gapon Cc: Shah, Vishal; freebsd-usb@FreeBSD.org; Ranaweera, Samantha; Faylor, Christopher Subject: Re: System hang in USB umass module while processing panic On Wednesday 25 May 2011 17:01:24 Andriy Gapon wrote: > on 19/05/2011 22:27 Shah, Vishal said the following: > > In FreeBSD 8 USB driver, commands are asynchronously sent from umass > > layer onto the wire, in other words, multiple threads are involved > > before the command is sent from the umass layer all the way to the wire. > > Since the usb_proc is not scheduled current process keeps waiting for > > the command to complete, hence the hang. Is this a known issue? If yes, > > is there a fix available? Are there any plans of adding a synchronous > > path to send the command to the device? Any information regarding this > > issue is much appreciated. > > From your description this sounds like a problem in USB driver. > I am not an expert in USB code, looks like some polling prodding would have > to be added there (if it's not there yet). Hans Petter may be a better > contact for this issue. > I am not sure if I can help you more. Hi, The umass driver is being polled during panic. If some command is hanging on a USB device then USB cannot do anything about it. Only the CAM layer can abort the SCSI command, because the USB layer doesn't know if it is the dump device or not? Sometimes the command timeouts are rather longs so waiting until the command times out might work to get a core dump. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
System hang in USB umass module while processing panic
Hi Folks,
This is regarding the issue we saw in the USB driver of FreeBSD 8,
particularly umass driver. We have a USB flash device in our system.
The issue is, when the system panics, it gets into the uni-processor
mode, and while processing that panic, scsi layer shutdown handler
(dashutdown())is called to issue the SYNCHRONIZE_CACHE command to the
device. This command is never completed and the system hangs.
Details:
When the system panics, it gets into the uniprocessor mode and the
usb_proc is never scheduled to complete the transfer which was enqueued
while executing the SYNCHRONIZE_CACHE command sent by xpt_action() in
the below loop. After sending(enqueuing xfer) the command, current
process waits in a loop for the command to complete with a very large
timeout value.
Loop in xpt_polled_action() called by dashutdown():
if (timeout != 0) {
xpt_action(start_ccb);
while(--timeout > 0) {
(*(sim->sim_poll))(sim);
camisr_runqueue(&sim->sim_doneq);
if ((start_ccb->ccb_h.status & CAM_STATUS_MASK)
!= CAM_REQ_INPROG)
break;
DELAY(1000);
}
In FreeBSD 8 USB driver, commands are asynchronously sent from umass
layer onto the wire, in other words, multiple threads are involved
before the command is sent from the umass layer all the way to the wire.
Since the usb_proc is not scheduled current process keeps waiting for
the command to complete, hence the hang.
Is this a known issue? If yes, is there a fix available? Are there any
plans of adding a synchronous path to send the command to the device?
Any information regarding this issue is much appreciated.
Thanks in advance,
Vishal
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
