The symptom is an oops very early on boot, with do_cpu and resume_userspace_check as the only two functions in the stack trace. Bisecting led to your commit 4227a2d4efc9c84f35826dc4d1e6dc183f6c1c05, though with linus' tree (rather than loongson-community, where I first observed the problem) I can't really tell whether the stack trace is the same, as there is no sm712 support there any more, and even if I patch it in, the screen is severely garbled with the minimized config I use for the bisection. I need a handful of other patches to bring even 3.18 to a bootable state on yeeloongs, too, and I've applied the small patchset throughout the bisection. Are you by any chance already aware of this regression? Could it be that thte problem is elsewhere, and bisection just happened to find a spot in the middle of a larger changeset whose intermediate steps wouldn't work? Thanks in advance for any advice you might be able to provide on how to debug or work around this problem. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
