(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.syrj...@linux.intel.com>
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.syrj...@linux.intel.com>
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.syrj...@linux.intel.com>
Cc: sta...@vger.kernel.org
[danvet: Add cc: stable since the offending commit has that, too.]
Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>
--
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
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
