Forgot to mention, I just reproduced it on the mainline 4.8.1 kernel.

On Wed, Oct 12, 2016 at 5:13 PM, Alex Damian <> wrote:
> Hello,
> To follow up on the original bug report. I am still experiencing
> memory corruption problems in the xhci stack.
> One thing I noticed is that the corruption always occur on a secondary
> CPU (ie. the stack trace starts on cpu_startup_entry) and it is always
> going on when trying to handle an intrerrupt.
> Seems to me that a mutex or something similar is not correctly locked,
> but I don't have any experience with the code around this part, so I
> have no idea where to look.
> Pointers, ideas, suggestions ?
> Cheers,
> Alex
> On Thu, Aug 25, 2016 at 2:22 PM, Mathias Nyman
> <> wrote:
>> On 29.07.2016 17:41, Alex Damian wrote:
>>> On Fri, Jul 29, 2016 at 2:53 PM, Greg KH <> wrote:
>>>> On Fri, Jul 29, 2016 at 10:58:03AM +0100, Alex Damian wrote:
>>>>> Hi Greg,
>>>>> I managed to reproduce with a untainted kernel, see dmesg paste below.
>>>>> The stack seemed corrupted as well ?
>>>>> I refered to it as a crash since after a couple of these issues, the
>>>>> machine hard freezes - I set up a serial console via a USB cable, but
>>>>> I don't get the kernel oops out of the machine. The network is also
>>>>> dead before getting any data. I could not think of any other way to
>>>>> get a console out of a Macbook - any ideas ?
>>>>> There is a progressive level of deterioration going on below, this is
>>>>> why I'm adding multiple pastes. See the obviously invalid pointer
>>>>> 0000000000000001 in 3rd paste below. Also, see the protection fault in
>>>>> the last paste. To me, something is trampling all over memory, and it
>>>>> is usb-related.
>>>> Not good, thanks for reproducing it without the closed kernel drivers.
>>>> If you disable the list debug kernel option, do you have any problems
>>>> with the machine?  We aren't having any other reports of issues like
>>>> this at the moment, which makes me worry that it's something unique to
>>>> your situation/hardware.
>>> I strongly suspect it's related to the macbook 12,1 hardware. I
>>> haven't been able
>>> to reproduce this with other machines, including other macbook
>>> versions with the same peripherals.
>>> This machine has never been stable in this particular peripheral
>>> configuration.
>>> I had Apple run all HW diagnostics on the machine, I ran the memcheck
>>> to verify that
>>> the RAM is ok - all results are clean. The machine is very stable under
>>> Mac OSX.
>>>> And you don't know that it's a USB problem, only that USB is the one
>>>> that is showing the issue.  Anyone could be writing over memory.
>>> True. However it seems particularly related to the USB mouse - that's
>>> how I manage
>>> to reproduce the error.
>>>> Also, any chance you can use 'git bisect' to track down an offending
>>>> commit?  I'm assuming that this used to work properly and something
>>>> recently caused the issue, correct?
>>> The earliest kernels I've tested are in the 3.3 range. All kernels
>>> before 4.7 just lock up.
>>> 4.7 is the first kernel where I have meaningful dmesg errors before
>>> locking up. As such,
>>> there is very little that I can do to bisect :(.
>> Going through xhci related issues that occurred during my vacation.
>> There is one command list related issue fixed in 4.8-rc3, any chance you
>> could try it?
>> Alternatively just add the following patch added to 4.7:
>> 33be126 xhci: always handle "Command Ring Stopped" events
>> Enabling xhci debug could reveal something.
>> echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control
>> -Mathias
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to
More majordomo info at

Reply via email to