https://bugzilla.kernel.org/show_bug.cgi?id=25832 --- Comment #48 from rocko <rockorequin@xxxxxxxxxxx> 2011-03-14 04:10:06 --- Unfortunately there are a couple of problems with bisecting this, quite apart from the time it takes to build and test each kernel... The first is that it is unsurprisingly easy to crash an rc1 kernel, which makes it even harder to reliably detect the bug. For instance, I managed to crash the first bisect of 35-36.rc1 with the suspend/resume test eventually (it seems much more robust than 2.6.38 with respect to this bug) but it isn't clear that the problem occurred as a result of the USB removal - the stack trace looks like it includes memory allocations and socket receives. Why, the first time I booted the 36rc1 kernel, it hung completely at the login screen with no human input whatsoever, clearly as a result of a different bug. I'm not even positive that the log I posted from the 36rc1 kernel crash above is related to this bug, as it looks different from the 2.6.37/38 logs. The second problem is that I can't necessarily compile all the bisects! For instance commit f6cec0ae58c17522a7bc4e2f39dae19f199ab534 (the second bisect I tried) fails with this error: drivers/staging/comedi/drivers/das08_cs.c: In function âdas08_pcmcia_config_loopâ: drivers/staging/comedi/drivers/das08_cs.c:225:8: error: âstruct pcmcia_deviceâ has no member named âio Is there a way to make the kernel handle a bug like this more gracefully? It seems that there are many great debug tools for extracting information about process states, but they are all useless here because the crash is so catastrophic. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.-- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
