Re: usb sound issue - any ideas?

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

 



On Mon, Jul 09, 2012 at 02:07:42PM +0800, Andiry Xu wrote:
> On 07/08/2012 08:50 PM, Dr. Ing. Dieter Jurzitza wrote:
> >Dear listmembers,
> >recently I switched to a new pc, making use of an external USB sound device.
> >The problem: when I log off a kde-session and log in again, the sound device
> >vanishes. Issuing dmesg, I see:
> >
> >****************************************************************************************************
> >[747766.894681] systemd-logind[22155]: New session 1337 of user hoss.
> >[747767.130779] checkproc[31777]: checkproc: can not get session id for
> >process 30437!
> >[747767.172502] nas[31781]: Network Audio System Release 1.9.2
> >[747768.192940] dbus-daemon[22185]: no kernel backlight interface found
> >[747768.967589] dbus-daemon[22185]: dbus[22185]: [system] Activating via
> >systemd: service name='org.freedesktop.NetworkManager' unit='dbus-
> >org.freedesktop.NetworkManager.service'
> >[747768.967791] dbus[22185]: [system] Activation via systemd failed for unit
> >'dbus-org.freedesktop.NetworkManager.service': Unit dbus-
> >org.freedesktop.NetworkManager.service failed to load: No such file or
> >directory. See system logs and 'systemctl status dbus-
> >org.freedesktop.NetworkManager.service' for details.
> >[747768.967812] dbus-daemon[22185]: dbus[22185]: [system] Activation via
> >systemd failed for unit 'dbus-org.freedesktop.NetworkManager.service': Unit
> >dbus-org.freedesktop.NetworkManager.service failed to load: No such file or
> >directory. See system logs and 'systemctl status dbus-
> >org.freedesktop.NetworkManager.service' for details.
> >[747773.392964] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with
> >disabled ep ffff8803cf791240
> >[747773.392966] xhci_hcd 0000:00:14.0: Trying to add endpoint 0x3 without
> >dropping it.
> >[747773.392969] usb 3-4: Not enough bandwidth for altsetting 1
> >[747773.392971] ALSA pcm.c:250 9:3:1: usb_set_interface failed
> >[747773.394882] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with
> >disabled ep ffff8803cf791240
> >[747773.394885] xhci_hcd 0000:00:14.0: Trying to add endpoint 0x3 without
> >dropping it.
> >[747773.394887] usb 3-4: Not enough bandwidth for altsetting 1
> >[747773.394889] ALSA pcm.c:250 9:3:1: usb_set_interface failed
> >[747773.419558] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with
> >disabled ep ffff8803cf791240
> >[747773.419561] xhci_hcd 0000:00:14.0: Trying to add endpoint 0x3 without
> >dropping it.
> >[747773.419563] usb 3-4: Not enough bandwidth for altsetting 1
> >[747773.419565] ALSA pcm.c:250 9:3:1: usb_set_interface failed
> >[747773.449987] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with
> >disabled ep ffff8803cf791240
> >[747773.449989] xhci_hcd 0000:00:14.0: Trying to add endpoint 0x3 without
> >dropping it.
> >[747773.449992] usb 3-4: Not enough bandwidth for altsetting 2
> >[747773.449995] ALSA pcm.c:250 9:3:2: usb_set_interface failed
> >****************************************************************************************************
> >
> >I think the dbus-manager messages can savely be ignored, they are not related
> >to this problem IMHO. In contrast, xhci_hcd seems to be the culprit but I
> >cannot tell anything more about it.
> >
> >After this, I have to plug-unplug the device, then I can use it again - until
> >the next logout, what is very anoying. By the way, I am using kernel 3.4.4.
> >
> >Thank you very much for looking into this,
> >take care
> >
> 
> I have got a basic idea about what's going on...
> 
> When you logoff, the driver will change interface. xHCI driver will
> drop the endpoints of the old interface and add the endpoints of new
> interface. However the drop endpoint is disabled and xHCI driver
> ignores the drop request, while in add endpoint request driver finds
> out the endpoint is not dropped and hence the add request fails.

But why is the endpoint disabled in the first place?  That's what we
need to know, since this isn't a valid fix.  Perhaps a WARN_ON() around
the error path for the disabled endpoint would help us with a stack
trace?

Sarah Sharp

> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 73e8817..220671a 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -1448,7 +1448,7 @@ int xhci_drop_endpoint(struct usb_hcd *hcd, struct usb_device *udev,
>  	    xhci_get_endpoint_flag(&ep->desc)) {
>  		xhci_warn(xhci, "xHCI %s called with disabled ep %p\n",
>  				__func__, ep);
> -		return 0;
> +//		return 0;
>  	}
>  
>  	ctrl_ctx->drop_flags |= cpu_to_le32(drop_flag);

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

  Powered by Linux