The "scheduling while atomic" should be happening in this case because a panic happens in atomic context, and the panic calls its notifier list which contains drm_fb_helper_panic (the switch to console on modesetting framebuffer).
drm_fb_helper_panic calls drm_fb_helper_force_kernel_mode->drm_crtc_helper_set_config drm_crtc_helper_set_config has kzalloc calls with GFP_KERNEL, which means it has __GFP_WAIT set. This makes it the allocation routines call might_sleep, which calls _cond_resched and may be schedule()... in this case schedule was called so you get this trace. One fix to this would be turning the kzalloc calls to use GFP_ATOMIC instead, so we avoid kzalloc calling schedule. Anyway, this is not the regression reported here, just this scheduling while atomic makes it harder to see the real problem (the panic that should scrolled up on the screen). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/793796 Title: 2.6.38-10 panic after ejecting drive To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/793796/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
