kernel-packages team mailing list archive

[Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>]

(In reply to comment #20)
> Today's mainline kernel (top commit 85ce70fdf48aa290b4845311c2dd815d7f8d1fa5)
> 
> [  241.352344] INFO: task systemd-udevd:381 blocked for more than 120
> seconds.
> [  241.352420]       Tainted: PF          O 3.13.0-3-generic #18-Ubuntu
> [  241.352474] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> this message.
> [  241.352532] systemd-udevd   D f4fd7a24     0   381    270 0x00000004
> [  241.352552]  f4fd7a4c 00000086 c12f0573 f4fd7a24 c18294f8 c1a7c780
> 00000001 00000001
> [  241.352582]  c1a7c780 f5858000 f68a0d00 0003d1d6 00000000 f4fd7a1c
> f86e97df 1b762573
> [  241.352608]  f86e97e1 f86e97e1 f86ee998 f4fd7a60 c12f29dc 00000001
> 00000000 0000ff02
> [  241.352635] Call Trace:
> [  241.352663]  [<c12f0573>] ? format_decode+0x323/0x390
> [  241.352708]  [<c12f29dc>] ? vsnprintf+0x2cc/0x3d0
> [  241.352728]  [<c12f0001>] ? put_dec_trunc8+0x61/0xa0
> [  241.352750]  [<c16415a3>] schedule_preempt_disabled+0x23/0x60
> [  241.352766]  [<c1642eed>] __mutex_lock_slowpath+0x10d/0x171
> [  241.352782]  [<c164241c>] mutex_lock+0x1c/0x28
> [  241.352910]  [<f8d93aa2>] intel_get_load_detect_pipe+0x152/0x3a0 [i915]
> [  241.353059]  [<f8dc3142>] ? gen4_read32+0x32/0xb0 [i915]
> [  241.353075]  [<c12f2b6a>] ? snprintf+0x1a/0x20
> [  241.353195]  [<f8d9516d>] intel_modeset_setup_hw_state+0xa7d/0xae0 [i915]
> [  241.353273]  [<f86cffd8>] ? drm_mode_config_reset+0x98/0xb0 [drm]
> [  241.353392]  [<f8d951fe>] intel_modeset_gem_init+0x2e/0x40 [i915]
> [  241.353490]  [<f8d5abfb>] i915_driver_load+0xb3b/0xdc0 [i915]
> [  241.353586]  [<f8d57e10>] ? i915_switcheroo_set_state+0xa0/0xa0 [i915]
> [  241.353706]  [<f86cbcab>] drm_dev_register+0x8b/0x1a0 [drm]
> [  241.353768]  [<f86cd78e>] drm_get_pci_dev+0x7e/0x120 [drm]
> [  241.353797]  [<c11d8e37>] ? sysfs_do_create_link_sd.isra.2+0xa7/0x1c0
> [  241.353897]  [<f8d575ea>] i915_pci_probe+0x3a/0x80 [i915]
> [  241.353918]  [<c132870f>] pci_device_probe+0x6f/0xc0
> [  241.353934]  [<c11d8f75>] ? sysfs_create_link+0x25/0x40
> [  241.353956]  [<c13faf65>] driver_probe_device+0x105/0x380
> [  241.353972]  [<c1328662>] ? pci_match_device+0xb2/0xc0
> [  241.353992]  [<c13fb291>] __driver_attach+0x71/0x80
> [  241.354008]  [<c13fb220>] ? __device_attach+0x40/0x40
> [  241.354026]  [<c13f93c7>] bus_for_each_dev+0x47/0x80
> [  241.354043]  [<c13fa9ce>] driver_attach+0x1e/0x20
> [  241.354057]  [<c13fb220>] ? __device_attach+0x40/0x40
> [  241.354072]  [<c13fa627>] bus_add_driver+0x157/0x230
> [  241.354093]  [<c13fb859>] driver_register+0x59/0xe0
> [  241.354111]  [<c10487a0>] ? __set_pmd_pte+0xa0/0xa0
> [  241.354130]  [<c1327142>] __pci_register_driver+0x32/0x40
> [  241.354191]  [<f86cd925>] drm_pci_init+0xf5/0x100 [drm]
> [  241.354223]  [<f8655000>] ? 0xf8654fff
> [  241.354316]  [<f865505e>] i915_init+0x5e/0x60 [i915]
> [  241.354333]  [<c1002122>] do_one_initcall+0xd2/0x190
> [  241.354352]  [<c10e94f8>] ? tracepoint_module_notify+0x118/0x180
> [  241.354372]  [<f8655000>] ? 0xf8654fff
> [  241.354389]  [<c1049daf>] ? set_memory_nx+0x5f/0x70
> [  241.354411]  [<c16393ee>] ? set_section_ro_nx+0x54/0x59
> [  241.354432]  [<c10c210a>] load_module+0x111a/0x18e0
> [  241.354464]  [<c10c2a35>] SyS_finit_module+0x75/0xc0
> [  241.354481]  [<c11374cb>] ? vm_mmap_pgoff+0x7b/0xa0
> [  241.354513]  [<c164b90d>] sysenter_do_call+0x12/0x28
> 
> I'll test the drm-intel-nightly next

For reference that looks to be fixed with

commit 7ad228b11ec26a820291c9f5a1168d6176580dc1
Author: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
Date:   Tue Jan 7 16:15:36 2014 +0200

    drm/i915: Don't grab crtc mutexes in intel_modeset_gem_init()
    
    When the pipe A force quirk is applied the code will attempt to grab
    a crtc mutex during intel_modeset_setup_hw_state(). If we're already
    holding all crtc mutexes this will obviously deadlock every time.
    
    So instead of using drm_modeset_lock_all() just grab the
    mode_config.mutex. This is enough to avoid the unlocked mutex warnings
    from certain lower level functions.
    
    The regression was introduced in:
    
     commit 027476642811f8559cbe00ef6cc54db230e48a20
     Author: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
     Date:   Mon Dec 2 11:08:06 2013 +0200
    
        drm/i915: Take modeset locks around intel_modeset_setup_hw_state()
    
    Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
    Cc: stable@xxxxxxxxxxxxxxx
    [danvet: Add cc: stable since the offending commit has that, too.]
    Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx>

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1251065

Title:
  HP Mini 1000 fails to resume from suspend

Status in The Linux Kernel:
  Incomplete
Status in “linux” package in Ubuntu:
  In Progress

Bug description:
  Booting various kernels including the mainline 3.12 kernel, HP Mini
  1000 does not resume from suspend. Problem seems to have begun
  following update to 13.10, including kernels 3.9, 3.10, 3.11.

  Ran steps on DebuggingKernelSuspend wiki page at
  https://wiki.ubuntu.com/DebugginKernelSuspend#A.22resume-
  trace.22_debugging_procedure_for_finding_buggy_drivers.

  Attached: dmesg.txt
  --- 
  ApportVersion: 2.12.5-0ubuntu2.1
  Architecture: i386
  DistroRelease: Ubuntu 13.10
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2013-11-12 (1 days ago)
  InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release i386 (20131016.1)
  MarkForUpload: True
  NonfreeKernelModules: wl
  Package: linux (not installed)
  Tags:  saucy
  Uname: Linux 3.12.0-031200-generic i686
  UnreportableReason: The running kernel is not an Ubuntu kernel
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1251065/+subscriptions