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 ?
On Thu, Aug 25, 2016 at 2:22 PM, Mathias Nyman
> On 29.07.2016 17:41, Alex Damian wrote:
>> On Fri, Jul 29, 2016 at 2:53 PM, Greg KH <g...@kroah.com> 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
>> 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
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