Regression in panic
Mandeep Singh Baines
msb at chromium.org
Mon Jun 20 16:20:16 PDT 2011
On Mon, Jun 20, 2011 at 4:03 PM, David Rientjes <rientjes at google.com> wrote:
> On Mon, 20 Jun 2011, Mandeep Singh Baines wrote:
>> Hi Dave,
>> I think this change is causing a regression I'm seeing in panic.
>> Before this change, I'd get a
>> reboot on panic (we've configured as such).
>> With this change, my machine gets wedged if the machine is running in
>> X when the panic occurs.
>> I traced the code flow to this:
>> ->vc->vc_sw->con_blank(vc, 0, 0);
>> ->fbcon_blank(vc, 0, 0);
>> ->redraw_screen(vc, 0);
>> ->fb_pan_display(info, &ops->var);
>> ->info->fbops->fb_pan_display(var, info);
>> ->drm_fb_helper_pan_display(var, info);
>> ->mutex_lock(&dev->mode_config.mutex); *this blocks*
>> With this change, there is now a lot going on in the panic path. Stuff
>> that I'm not sure is safe when panicking. In addition to the
>> mutex_lock, there is also a del_timer_sync()
>> now happening in the context of panic().
>> I see this bug with a 2.6.38 kernel but did a quick scan of a newer
>> kernels and did not see anything that changed in this path so I
>> suspect its still there.
>> Reverting this change fixes the regression.
> Chris Fowler reports something similar when running 2.6.38 by inducing a
> kernel panic via the oom killer -- see
> http://marc.info/?l=linux-kernel&m=130805985022791. I've added him to the
> cc so he can participate in the thread and cherry-pick any fixes (last
> status update was that he was going to be trying 220.127.116.11).
One potential fix might be to convert the mutex_lock to a try if
I suspect oops_in_progress checks may be needed in a bunch of other places in
the screen_unblank code path.
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
More information about the dri-devel