On Fri, Jul 29, 2016 at 2:53 PM, Greg KH <greg@xxxxxxxxx> 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 :(. > > thanks, > > greg k-h -- 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
