RE: xHCI out of order events on BSD, was Re: xhci and other woes

2014-02-15 Thread Hans Petter Selasky 

Hi,

-Original message-
> From:Sarah Sharp  >

> Sent: Saturday 15th February 2014 0:02
> To: Hans Petter Selasky  >

> Cc: linux-usb@vger.kernel.org 
> Subject: xHCI out of order events on BSD, was Re: xhci and other woes
>
> On Thu, Feb 06, 2014 at 11:30:29AM +0100, Hans Petter Selasky wrote:
>> On 02/04/14 20:10, Sarah Sharp wrote:
>>> And there's code in the xHCI driver to ignore the second successful
>>> event.  See ep->last_td_was_short.  Yes, this is a slight race
>>> condition, and we should wait for the successful event.  However, we
>>> have not seen any issues with this race condition.
>>
>> Hi,
>>
>> Some comments from the side-line:
>>
>> I've observed some XHCI controllers sending special case events,
>> like IO-errors for ISOCHRONOUS endpoints, out of order. In not sure
>> if the XHCI specification is clear about this, or not, that when you
>> have bunch of TD's on an endpoint, you should not receive the
>> completion event for the next timeslot / TD, before receiving the
>> IO-error for the previous failed TRB/TD. I'm not sure what tests HW
>> guys are doing these days regarding XHCI. This has been observed
>> during driver development of FreeBSD's XHCI driver a long time ago,
>> and I though I'd mention it for you guys.

 > Do you mean you get a missed service event, and then an event for some
> later TD?  Or an event for that later TD, and then a missed service
> interval?  Or maybe that you queue TD 1 and TD 2, and then receive
> events for TD 2 and then TD 1?  What's the exact sequence of events
> here?

No, let me explain. I have a DVB USB adapter which would sometimes 
overflow the wMaxPacket data transfer length, due to a design flaw or 
so-called firmware/hardware bug. When that happened, I observed the 
completions for the faulty transfers would be received out of order, and 
would confuse the driver logic. This was not a missed service event 
error. So actually:


ISOC TD frame1: OK
ISOC TD frame2: too long (IO-ERROR)
ISOC TD frame3: OK
ISOC TD frame4: OK

Resulted in:

ISOC TD EVENT complete frame1
ISOC TD EVENT complete frame3
ISOC TD EVENT complete frame4

Some delay:

ISOC TD EVENT complete frame2 w/error in status code.

Hardware "ASM1042 SuperSpeed USB Host Controller".

>
> ISTR the xHCI spec does say you could get out-of-order TDs when the host
> is actually an SR-IOV virtualized host.  However, I had hoped that
> wouldn't happen when running on bare hardware.

No virtualization here.

>
>> FreeBSD's XHCI driver: 
http://svnweb.freebsd.org/base/head/sys/dev/usb/controller/xhci.c?view=markup 
 


>
> I can't look at that for licensing reasons, sorry.  However, we can have
> a conversation about observed hardware behavior.

That's fine. I don't read yours driver either  BTW: There is something 
called a dual BSD/GPL license


--HPS



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

Test email

2014-02-15 Thread Dr. P. Sekar 

Test email

--
Dr. P. Sekar
Chief Executive
AWATA Software Systems
Chennai, India
Mobile (91)98403 59234

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

Re: /dev entry of USB device not disappearing after detach

2014-02-15 Thread Valentina Manea 
On Fri, Feb 14, 2014 at 8:21 PM, Greg KH  wrote:
>
> Also, the kernel is the one now responsible for managing the /dev node
> creation/removal, through devtmpfs, there shouldn't be any "hotplug"
> scripts involved in this process, so I doubt it's a userspace issue.
>
> you do have CONFIG_DEVTMPFS enabled in your kernel, right?
>

Hi Greg,

It seems I did not have CONFIG_DEVTMPFS and, with this option, the bug
is no longer reproducible. Since, as I've read, devtmpfs has replaced
tmpfs, there's no point in further debugging.

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

Re: /dev entry of USB device not disappearing after detach

2014-02-15 Thread Greg KH 
On Sat, Feb 15, 2014 at 02:38:28PM +0200, Valentina Manea wrote:
> On Fri, Feb 14, 2014 at 8:21 PM, Greg KH  wrote:
> >
> > Also, the kernel is the one now responsible for managing the /dev node
> > creation/removal, through devtmpfs, there shouldn't be any "hotplug"
> > scripts involved in this process, so I doubt it's a userspace issue.
> >
> > you do have CONFIG_DEVTMPFS enabled in your kernel, right?
> >
> 
> Hi Greg,
> 
> It seems I did not have CONFIG_DEVTMPFS and, with this option, the bug
> is no longer reproducible. Since, as I've read, devtmpfs has replaced
> tmpfs, there's no point in further debugging.

Ok, that makes sense, it wasn't a "bug", it was just that nothing was
around to delete the device node at all (udev no longer does this, it
relies on devtmpfs to be present).  So all was working just fine.

thanks,

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

Re: [OPW] USB subsystem questions

2014-02-15 Thread Valentina Manea 
On Sat, Feb 1, 2014 at 12:00 AM, Alan Stern  wrote:
> On Fri, 31 Jan 2014, Sarah Sharp wrote:
>
>> Why exactly do you want the device to not show up in /dev?  I would
>> think what you really want is for the device drivers on the server side
>> to not bind to the device, since the client side drivers should be bound
>> to them instead.
>>
>> I believe there is a mechanism for usbfs drivers to mark a port as
>> "claimed".  Perhaps the stub driver could do the same?  Alan Stern would
>> have deals on that.
>
> That might be good enough.  The stub driver could claim the port that
> the device is plugged into by calling usb_hub_claim_port (you would
> have to EXPORT this function first).  This would prevent the server
> system from automatically binding drivers to the device's interfaces
> whenever the client system changed the device's configuration.
>

Hi,

Thank you both for your replies, I managed to solve the /dev issues,
it seems it was related to tmpfs.

Related to the port claim mechanism, as far as I can see,
usb_hub_claim_port is called from a ioctl and, thus, needs a file to
be called for.
As I read, usbfs has been deprecated and /sys and /dev/bus/usb are
used instead. However, I can't figure out which file to use. I tried
claming a port from userspace using ioctl on /dev/bus/usb/001/001
(since it's the only file that looks like a device file corresponding
to hub usb1, to which the USB device to be shared is attached). I get
Operation not permitted when doing this.

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

Re: USB storage vanilla kernel 3.13 hang on DELL PRECISION M6400

2014-02-15 Thread Stefani Seibold 
Am Samstag, den 15.02.2014, 02:33 +0100 schrieb Thomas Gleixner:
> On Fri, 14 Feb 2014, Stefani Seibold wrote:
> > Am Freitag, den 14.02.2014, 10:32 -0500 schrieb Alan Stern:
> > > On Fri, 14 Feb 2014, Stefani Seibold wrote:
> > > 
> > > > Hi Alan;
> > > > 
> > > > Am Donnerstag, den 13.02.2014, 15:55 -0500 schrieb Alan Stern:
> > > > 
> > > > > Stefani, please try the patch below, with "threadirq" and the plain
> > > > > vanilla kernel.  It ought to fix your problem, but let's make certain.
> > > > 
> > > > I tried the patch on 3.13.2 together with the commit 88ed9fd50e57 and it
> > > > seems that it solves the problem.
> > > > 
> > > > I also tried the current 3.14.0-rc2-00271-g4675348 without any
> > > > modifications and without our patch... and it also works.
> > > 
> > > 3.14-rc2 works with no modifications at all?  Then it looks like the 
> > > patch is unnecessary.
> > > 
> > > But I'm surprised that it works.  As far as I know, there haven't been 
> > > any changes since 3.13 that would fix this problem.
> > > 
> > 
> > I surprised too. I think it is a kind of race condition and IMHO the
> > patch is necessary.
> 
> Lockdep does not care about race conditions and humble opinions at
> all. It observes that one place takes the lock with interrupts enabled
> and the other takes it in hardirq context. It's that simple.
> 
> So now the question is why one kernel triggers the lockdep warning and
> a later version does not while all involved parties claim that nothing
> has changed.
> 
> Before we jump into detailed analysis, let's make sure that this
> happens
> 
>   - with the same .config (i.e. lockdep and the device driver in
> question enabled)
> 
>   - the same system (i.e. the same drivers loaded and handling the same
> devices)
> 
>   - the device driver actually doing something which might cause
> lockdep to yell.
> 
> When this is the case, then the claim that nothing has changed is
> simply wrong and we need to figure out which allegedly unrelated
> change has caused this change in behaviour.
> 
> The patch is needed from a code analysis POV. I've been wrong before,
> but you really need to provide evidence why 3.14-rc2 does not show the
> behaviour and which change has caused that before I'm going to back
> off. IMHO is not a convincing argument!
> 

I have cross tested Alan's patch again with kernel 3.13.2 and the
current 3.14-rc2.

I have now exactly the same .config, the same system and the same kernel
cmdline.

A kernel 3.13.2 without Alan's patch freeze when accessing a USB flash
memory connect to the EHCI. With this patch everything is fine.

The current 3.14-rc2 freeze also when the patch is not applied. With
this patch it works.

The reason that my first test show a different behaviour on the 3.14
kernel was that the cmdline was missing the threadirq, because the boot
loader was missconfigured.  

So i will give an ACK for the patch.

- Stefani


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

Re: [PATCH][usbutils] lsusb: decode CDC MBIM extended functional descriptor

2014-02-15 Thread Greg Kroah-Hartman 
On Fri, Feb 14, 2014 at 11:47:03PM -0800, Ben Chan wrote:
> Signed-off-by: Ben Chan 
> ---
> Example output:
> 
>   Before:
> 
>   UNRECOGNIZED CDC:  08 24 1c 00 01 0f dc 05
> 
>   After:
> 
>   CDC MBIM Extended:
> bcdMBIMExtendedVersion   1.00
> bMaxOutstandingCommandMessages 15
> wMTU 1500
> 
>  lsusb.c | 13 +
>  1 file changed, 13 insertions(+)

Applied, thanks.

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

Did USB slowly kill/hang my kernel? (3.12.7)

2014-02-15 Thread Marc MERLIN 
I found that my server at home, after months of runtime, hung and found
the following on the serial console. Interestingly, the software watchdog wasn't
even able to reboot the system it seems, it needed a power cycle.

Is there other info I can provide/different kernel options I should use?

Thanks,
Marc

[1836102.933294] CPU: 1 PID: 426 Comm: khubd Tainted: GW
3.12.7-amd64-i915-preempt-20131107 #1
[1836102.963481] Hardware name: System manufacturer System Product Name/P8H67-M 
PRO, BIOS 3806 08/20/2012
[1836102.993665]  00f5 88021f287bd8 815e1e2e 
0006
[1836103.018828]  88021f287c28 88021f287c18 8104cf14 

[1836103.043960]  810c244f 8802148e3c00  
88021f287d40
[1836103.069099] Call Trace:
[1836103.079178][] dump_stack+0x4f/0x84
[1836103.099185]  [] warn_slowpath_common+0x81/0x9b
[1836103.119948]  [] ? watchdog_overflow_callback+0x9c/0xa7
[1836103.142762]  [] warn_slowpath_fmt+0x46/0x48
[1836103.162706]  [] watchdog_overflow_callback+0x9c/0xa7
[1836103.184957]  [] __perf_event_overflow+0x134/0x1bd
[1836103.206470]  [] ? x86_perf_event_set_period+0x103/0x10f
[1836103.229493]  [] perf_event_overflow+0x14/0x16
[1836103.249897]  [] intel_pmu_handle_irq+0x28c/0x311
[1836103.271063]  [] perf_event_nmi_handler+0x2b/0x48
[1836103.292198]  [] nmi_handle.isra.3+0x6f/0x16e
[1836103.312281]  [] ? perf_ibs_nmi_handler+0x3d/0x3d
[1836103.80]  [] do_nmi+0xa2/0x2ce
[1836103.350571]  [] end_repeat_nmi+0x1e/0x2e
[1836103.369600]  [] ? usb_hcd_flush_endpoint+0x38/0xf0 
[usbcore]
[1836103.393814]  [] ? usb_hcd_flush_endpoint+0x38/0xf0 
[usbcore]
[1836103.417981]  [] ? usb_hcd_flush_endpoint+0x38/0xf0 
[usbcore]
[1836103.442121]  <>  [] usb_disable_endpoint+0x5c/0x74 
[usbcore]
[1836103.467677]  [] usb_disable_interface+0x3c/0x4f [usbcore]
[1836103.491039]  [] usb_unbind_interface+0x62/0x144 [usbcore]
[1836103.514383]  [] __device_release_driver+0x89/0xdf
[1836103.535621]  [] device_release_driver+0x23/0x30
[1836103.556322]  [] bus_remove_device+0xfc/0x111
[1836103.576219]  [] device_del+0x130/0x18a
[1836103.594558]  [] usb_disable_device+0x77/0x197 [usbcore]
[1836103.617304]  [] usb_disconnect+0x91/0x162 [usbcore]
[1836103.639001]  [] hub_thread+0x6ad/0xf8f [usbcore]
[1836103.659886]  [] ? need_resched+0x1e/0x28
[1836103.678664]  [] ? add_wait_queue+0x49/0x49
[1836103.697970]  [] ? usb_port_resume+0x35c/0x35c [usbcore]
[1836103.720632]  [] kthread+0x8d/0x95
[1836103.737553]  [] ? kthread_freezable_should_stop+0x3e/0x3e
[1836103.760707]  [] ret_from_fork+0x7c/0xb0
[1836103.779168]  [] ? kthread_freezable_should_stop+0x3e/0x3e
[1836103.802287] ---[ end trace 073a1f1790f2d963 ]---
[1836103.818383] perf samples too long (11276019 > 5000), lowering 
kernel.perf_event_max_sample_rate to 25000
[1836103.849033] INFO: NMI handler (perf_event_nmi_handler) took too long to 
run: 1473.504 msecs
[1836113.826714] perf samples too long (11187945 > 1), lowering 
kernel.perf_event_max_sample_rate to 12500
[1836123.835043] perf samples too long (11100557 > 2), lowering 
kernel.perf_event_max_sample_rate to 6250
[1836133.843375] perf samples too long (11013858 > 4), lowering 
kernel.perf_event_max_sample_rate to 3250
[1836143.851705] perf samples too long (10927832 > 76923), lowering 
kernel.perf_event_max_sample_rate to 1750
[1836153.860035] perf samples too long (10842479 > 142857), lowering 
kernel.perf_event_max_sample_rate to 1000
[1836163.868365] perf samples too long (10757790 > 25), lowering 
kernel.perf_event_max_sample_rate to 500
[1836173.876695] perf samples too long (10673763 > 50), lowering 
kernel.perf_event_max_sample_rate to 250
(last line visible on the console, software watchdog didn't reboot the
machine)

I do have lots of devices:
gargamel:~# lsusb
Bus 004 Device 025: ID 0830:0080 Palm, Inc. Serial Adapter [for Palm III]
Bus 004 Device 024: ID 0403:6001 Future Technology Devices International, Ltd 
FT232 USB-Serial (UART) IC
Bus 004 Device 023: ID 0403:6001 Future Technology Devices International, Ltd 
FT232 USB-Serial (UART) IC
Bus 004 Device 022: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 004 Device 021: ID 0403:6001 Future Technology Devices International, Ltd 
FT232 USB-Serial (UART) IC
Bus 004 Device 020: ID 0403:6001 Future Technology Devices International, Ltd 
FT232 USB-Serial (UART) IC
Bus 004 Device 019: ID 0403:6001 Future Technology Devices International, Ltd 
FT232 USB-Serial (UART) IC
Bus 004 Device 018: ID 1a40:0101 TERMINUS TECHNOLOGY INC. 
Bus 004 Device 017: ID 0b95:1780 ASIX Electronics Corp. AX88178
Bus 004 Device 016: ID 06cd:0121 Keyspan USA-19hs serial adapter
Bus 004 Device 015: ID 0409:005a NEC Corp. HighSpeed Hub
Bus 004 Device 014: ID 0403:6001 Future Technology Devices International, Ltd 
FT232 USB-Serial (UART) IC
Bus 004 Device 013: ID 0403:6001 Future Technology Devices International, Ltd 
FT232 USB-Serial (UART) IC
Bus 004 Device 012:

Re: [PATCH v4 12/14] usb: guarantee child device resume on port poweron

2014-02-15 Thread Alan Stern 
On Fri, 14 Feb 2014, Dan Williams wrote:

> On Mon, Feb 10, 2014 at 1:01 PM, Alan Stern  wrote:
> > The patch description here could be improved substantially.  It should
> > start out with an explanation of the basic reason for the patch and a
> > clear indication of what the patch does.
> >
> > On Fri, 31 Jan 2014, Dan Williams wrote:
> >
> >> Make port power recovery behave similarly to the power session recovery
> >> that occurs after a system / hub suspend event.  Arrange for a
> >
> > That is not clear to me, mostly because of its lack of specificity.  I
> > would phrase it more like this:
> >
> > Whenever a USB port is powered back on (runtime resumed),
> > ask khubd to do an autoresume of the attached child device as
> > soon as possible.
> 
> Yes, that's clearer.
> 
> >
> >> usb_device to always complete a usb_port_resume() run prior to the next
> >> khubd run.  This serves several purposes:
> >
> > "Prior to the next khubd run" is misleading.  khubd may run several
> > times, for other purposes, before it gets around to handling this
> > particular port.  "As soon as possible" is better.
> 
> *nod*
> 
> >
> >> 1/ The device may need a reset on power-session loss, without this
> >>change port power-on recovery exposes khubd to scenarios that
> >>usb_port_resume() is set to handle.
> >
> > What scenarios?
> 
> Prior to port power control the only time a power session would be
> lost is during dpm_suspend of the hub.  In that scenario
> usb_port_resume() is guaranteed to be called prior to khubd running
> for that port.  With this change we wakeup the child device prior to
> khubd running again for this port.
> 
> > Wouldn't khubd handle them by doing a runtime resume
> > anyway?
> 
> khubd will only do a runtime resume if the portstatus / portchange
> indicates a suspend state.  In the case of port power control we are
> not coming from a hub-port-suspend state.
> 
> >>  Also, testing showed that USB3
> >>devices that are not reset on power-session loss may eventually
> >>downgrade their connection to the USB2 pins.
> >
> > What do you mean by "eventually"?  The delay before the reset is too
> > long?  Or the port power-cycles too many times?
> 
> Empirically port power cycles too many times seems to be trigger.
> 
> >> 2/ This mechanism rate limits port power toggling.  The minimum port
> >>power on/off period is now gated by the child device suspend/resume
> >>latency.  This mitigates devices downgrading their connection on
> >>perceived instability of the host connection.  This ratelimiting is
> >>really only relevant to port power control testing, but it is a nice
> >>side effect of closing the above race.
> >
> > What race?
> 
> The race of khubd for the given port running while a usb_port_resume()
> event is pending.
> 
> > This reminds me...  In the case of a tier mismatch, is it possible that
> > the USB-3 root hub will be capable of switching off power to its ports
> > but the integrated USB-2 hub won't?  In that situation, the device is
> > virtually certain to change over to high speed.
> 
> Good point I should be gating USB3 port power off on the merged
> wHubCharacteristics of the peered ports.
> 
> >> 3/ Going forward if we find that power-session recovery requires
> >>warm-resets (http://marc.info/?t=13865923293&r=1&w=2) that is
> >>something usb_port_resume() can drive and handle before khubd's next
> >>evaluation of the portstatus.
> >
> > Isn't this more or less the case right now?  In the current code, the
> > only reason the hub driver would look at a port that had recently been
> > powered back on is if the attached device was undergoing a runtime
> > resume.
> 
> This is more or less the case right now, yes.
> 
> >> 4/ If the device *was* disconnected the only time we'll know for sure is
> >>after a failed resume, so it's necessary for
> >>usb_port_runtime_resume() to expedite a usb_port_resume() to clean up
> >>the removed device.
> >
> > I don't follow the reasoning.  Even granting that we want to find out
> > about the disconnection, we have already waited an indefinitely long
> > time for the port to be powered back on.  What harm is there in waiting
> > another indefinitely long time for the device to be runtime-resumed?
> 
> Least surprise for the user.  Turning on a port means that hotplug
> detection is again enabled for the port, it is surprising that devices
> that were removed while the port was off are not disconnected until
> they are attempted to be used.  As a user "why would I try to use a
> device I removed from the system?"
> 
> > Also, usb_port_runtime_resume _already_ includes code to check for a
> > disconnection.  Currently all it does is log a debugging message if the
> > device is gone, but it could easily do more.
> 
> That detection is buggy and we can't rely on it until
> usb_port_resume() determines the disconnection.  It's buggy because
> the port may require a

Re: Any change on REAPURB ioctl since 3.11.0?

2014-02-15 Thread Alan Stern 
On Sat, 15 Feb 2014, Steven Xiao wrote:

> Hi Alan,
> 
> Can you please elaborate why this change about handling NRDY was
> introduced into Linux 3.11?

As far as I know, there have been no changes introduced into 3.11 that
affect the way NRDY is handled.  But I'm not an expert on the xhci-hcd
driver.  You should ask the driver's maintainer.

>  Or is there a bug number tracking this
> change?

Not that I know of.

>  In my understanding, NRDYs are sent by the device to indicate
> that the endpoint is not ready to send or receive packets.  When the
> host receives an NRDY, the attempt of reaping URB should be blocked,
> because no URBs are completed at that point, until it receives ERDY.

That's right.  Are you sure your device didn't send an ERDY after it 
sent NRDY?

Alan Stern

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

Re: [OPW] USB subsystem questions

2014-02-15 Thread Alan Stern 
On Sat, 15 Feb 2014, Valentina Manea wrote:

> Hi,
> 
> Thank you both for your replies, I managed to solve the /dev issues,
> it seems it was related to tmpfs.
> 
> Related to the port claim mechanism, as far as I can see,
> usb_hub_claim_port is called from a ioctl and, thus, needs a file to
> be called for.

That's true when it is invoked from userspace.  It can also be invoked 
directly by a kernel driver; in that case no file is needed.

> As I read, usbfs has been deprecated and /sys and /dev/bus/usb are
> used instead. However, I can't figure out which file to use. I tried
> claming a port from userspace using ioctl on /dev/bus/usb/001/001
> (since it's the only file that looks like a device file corresponding
> to hub usb1, to which the USB device to be shared is attached). I get
> Operation not permitted when doing this.

That's the right file.  Did you open the file for writing?  Did you run 
the program as root?

For an example of how to use this ioctl, see

http://marc.info/?l=linux-usb&m=124345857431452&w=2

Alan Stern

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

Re: Did USB slowly kill/hang my kernel? (3.12.7)

2014-02-15 Thread Alan Stern 
On Sat, 15 Feb 2014, Marc MERLIN wrote:

> I found that my server at home, after months of runtime, hung and found
> the following on the serial console. Interestingly, the software watchdog 
> wasn't
> even able to reboot the system it seems, it needed a power cycle.
> 
> Is there other info I can provide/different kernel options I should use?

You can try turning on CONFIG_USB_DEBUG.  It may not help much, though.

How reproducible is this failure?

> [1836102.933294] CPU: 1 PID: 426 Comm: khubd Tainted: GW
> 3.12.7-amd64-i915-preempt-20131107 #1
> [1836102.963481] Hardware name: System manufacturer System Product 
> Name/P8H67-M PRO, BIOS 3806 08/20/2012
> [1836102.993665]  00f5 88021f287bd8 815e1e2e 
> 0006
> [1836103.018828]  88021f287c28 88021f287c18 8104cf14 
> 
> [1836103.043960]  810c244f 8802148e3c00  
> 88021f287d40
> [1836103.069099] Call Trace:
> [1836103.079178][] dump_stack+0x4f/0x84
> [1836103.099185]  [] warn_slowpath_common+0x81/0x9b
> [1836103.119948]  [] ? watchdog_overflow_callback+0x9c/0xa7
> [1836103.142762]  [] warn_slowpath_fmt+0x46/0x48
> [1836103.162706]  [] watchdog_overflow_callback+0x9c/0xa7
> [1836103.184957]  [] __perf_event_overflow+0x134/0x1bd
> [1836103.206470]  [] ? x86_perf_event_set_period+0x103/0x10f
> [1836103.229493]  [] perf_event_overflow+0x14/0x16
> [1836103.249897]  [] intel_pmu_handle_irq+0x28c/0x311
> [1836103.271063]  [] perf_event_nmi_handler+0x2b/0x48
> [1836103.292198]  [] nmi_handle.isra.3+0x6f/0x16e
> [1836103.312281]  [] ? perf_ibs_nmi_handler+0x3d/0x3d
> [1836103.80]  [] do_nmi+0xa2/0x2ce
> [1836103.350571]  [] end_repeat_nmi+0x1e/0x2e
> [1836103.369600]  [] ? usb_hcd_flush_endpoint+0x38/0xf0 
> [usbcore]
> [1836103.393814]  [] ? usb_hcd_flush_endpoint+0x38/0xf0 
> [usbcore]
> [1836103.417981]  [] ? usb_hcd_flush_endpoint+0x38/0xf0 
> [usbcore]
> [1836103.442121]  <>  [] 
> usb_disable_endpoint+0x5c/0x74 [usbcore]

Something is stuck in usb_disable_endpoint.  But from the information 
shown, we have no way of knowing which driver is involved.

Alan Stern

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

Re: USB storage vanilla kernel 3.13 hang on DELL PRECISION M6400

2014-02-15 Thread Alan Stern 
On Sat, 15 Feb 2014, Stefani Seibold wrote:

> I have cross tested Alan's patch again with kernel 3.13.2 and the
> current 3.14-rc2.
> 
> I have now exactly the same .config, the same system and the same kernel
> cmdline.
> 
> A kernel 3.13.2 without Alan's patch freeze when accessing a USB flash
> memory connect to the EHCI. With this patch everything is fine.
> 
> The current 3.14-rc2 freeze also when the patch is not applied. With
> this patch it works.
> 
> The reason that my first test show a different behaviour on the 3.14
> kernel was that the cmdline was missing the threadirq, because the boot
> loader was missconfigured.  
> 
> So i will give an ACK for the patch.

Okay, that makes a lot more sense.  I will submit the patch next week.

Alan Stern

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

Re: Did USB slowly kill/hang my kernel? (3.12.7)

2014-02-15 Thread Marc MERLIN 
On Sat, Feb 15, 2014 at 05:45:54PM -0500, Alan Stern wrote:
> On Sat, 15 Feb 2014, Marc MERLIN wrote:
> 
> > I found that my server at home, after months of runtime, hung and found
> > the following on the serial console. Interestingly, the software watchdog 
> > wasn't
> > even able to reboot the system it seems, it needed a power cycle.
> > 
> > Is there other info I can provide/different kernel options I should use?
> 
> You can try turning on CONFIG_USB_DEBUG.  It may not help much, though.

Will do.

> How reproducible is this failure?

Only happened once so far.

The only thing I can think of is that I recently added a USB to ethernet
cable to USB expander, and it worked about about a week before I got
this crash.
Not sure if it's related yet, or not, but now that I think about it,
it's the last thing I changed, so it's very possible.
 
> > [1836102.933294] CPU: 1 PID: 426 Comm: khubd Tainted: GW
> > 3.12.7-amd64-i915-preempt-20131107 #1
> > [1836102.963481] Hardware name: System manufacturer System Product 
> > Name/P8H67-M PRO, BIOS 3806 08/20/2012
> > [1836102.993665]  00f5 88021f287bd8 815e1e2e 
> > 0006
> > [1836103.018828]  88021f287c28 88021f287c18 8104cf14 
> > 
> > [1836103.043960]  810c244f 8802148e3c00  
> > 88021f287d40
> > [1836103.069099] Call Trace:
> > [1836103.079178][] dump_stack+0x4f/0x84
> > [1836103.099185]  [] warn_slowpath_common+0x81/0x9b
> > [1836103.119948]  [] ? 
> > watchdog_overflow_callback+0x9c/0xa7
> > [1836103.142762]  [] warn_slowpath_fmt+0x46/0x48
> > [1836103.162706]  [] watchdog_overflow_callback+0x9c/0xa7
> > [1836103.184957]  [] __perf_event_overflow+0x134/0x1bd
> > [1836103.206470]  [] ? 
> > x86_perf_event_set_period+0x103/0x10f
> > [1836103.229493]  [] perf_event_overflow+0x14/0x16
> > [1836103.249897]  [] intel_pmu_handle_irq+0x28c/0x311
> > [1836103.271063]  [] perf_event_nmi_handler+0x2b/0x48
> > [1836103.292198]  [] nmi_handle.isra.3+0x6f/0x16e
> > [1836103.312281]  [] ? perf_ibs_nmi_handler+0x3d/0x3d
> > [1836103.80]  [] do_nmi+0xa2/0x2ce
> > [1836103.350571]  [] end_repeat_nmi+0x1e/0x2e
> > [1836103.369600]  [] ? usb_hcd_flush_endpoint+0x38/0xf0 
> > [usbcore]
> > [1836103.393814]  [] ? usb_hcd_flush_endpoint+0x38/0xf0 
> > [usbcore]
> > [1836103.417981]  [] ? usb_hcd_flush_endpoint+0x38/0xf0 
> > [usbcore]
> > [1836103.442121]  <>  [] 
> > usb_disable_endpoint+0x5c/0x74 [usbcore]
> 
> Something is stuck in usb_disable_endpoint.  But from the information 
> shown, we have no way of knowing which driver is involved.

I'll try to get you that next time with CONFIG_USB_DEBUG hopefully.

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html