https://bugzilla.novell.com/show_bug.cgi?id=653547
https://bugzilla.novell.com/show_bug.cgi?id=653547#c38
Jan Kara changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |ASSIGNED
InfoProvider|eich@novell.com |
--- Comment #38 from Jan Kara 2011-01-12 17:49:41 UTC ---
Thanks for testing. Geez, this is driving me crazy. So it's not nouveau
driver... The corruption always overwrites memory from offset 0x28 in the slab
object by a pointer somewhere. So far we've observed corruptions in size-256
cache (the first run of the debug kernel) and size-512 cache (all the other
reports). So it might be use-after-free of some variable sized object with a
fixed header. But that's just a guess.
So I see two possible ways how to debug this:
a) try to boot with a minimal configuration (no graphics, no network, no sound,
no usb, ...) and see whether the corruption still occurs. If not (and I hope
not because if it was a problem in the core kernel I'd expect to see more
reports of the corruption), then add subsystems one by one and see when the
corruption starts happening.
b) configure kdump on the system and trigger the dump (via sysrq) as soon as
the slab corruption is reported. Then I can inspect the dump and hopefully the
pointer with which the memory is overwritten will point to some place which
will give us more clue.
Personally, I'd suggest starting with a) as I think it has higher chances of
success and only if even the minimal configuration still has problems, resort
to b).
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.