BUG: unable to handle kernel NULL pointer dereference at (null); RIP: 0010:[<ffffffff8167f93a>] [<ffffffff8167f93a>] __mutex_lock_slowpath+0xaa/0x150

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1070690

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Do you happen to know if this issue also happens on prior releases?

Markus Schade, as this report is apport-collect'ed against your ivy bridge computer, please file a new report against your sandy bridge computer by executing the following in a terminal, and please feel free to subscribe me to it:
ubuntu-bug linux

Thank you for your understanding.

Status Incomplete pending response from https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1070690/comments/23 .

Hi Joseph,

Am 24.10.2012 16:30, schrieb Joseph Salisbury:
> Do you happen to know if this issue also happens on prior releases?

No, this is new in quantal. We have been running precise before without
any issues on both platforms.

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report[0]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

Please follow the instructions on the wiki page[0]. The first step is to email the appropriate mailing list. If no response is received, then a bug may be opened on bugzilla.kernel.org.

[0] https://wiki.ubuntu.com/Bugs/Upstream/kernel

In addition to opening an upstream bug, I'd like to perform a bisect to figure out what commit caused this regression. It would be very helpful to know the earliest kernel where the issue started happening as well as the latest kernel that did not have this issue.

Can you test the following kernels and report back? We are looking for the first kernel version that doesn't have this bug:

v3.3 final: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3-precise/
v3.4 final: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-quantal/
v3.5-rc4: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5-rc4-quantal/

You don't have to test every kernel, just up until the kernel that first has this bug.

Thanks in advance!

I am a bit puzzled. I have tested up to 3.5.7 including the mainline 3.5.5, on which the quantal kernel is based, without encountering this error. But looking at the changelog I can't see anything related to drm or i915.
Kernel 3.6.0 had the "light" version of the bug.

[ 9.001003] [drm:drm_pci_agp_init] *ERROR* Cannot initialize the agpgart module.
[ 9.001046] DRM: Fill_in_dev failed.

However X still works despite this error, while it does not in 3.5.0-17-generic. So I'm currently testing the 3.6-rc series to find the first ocurrence.

the "light" bug is already present in 3.6-rc1

I've seen the same problem on my Dell M4700. However, it appears to fail intermittently. The last time I booted, the driver loaded without error, but the time before that it failed with the message below.

00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])
        Subsystem: Dell Device 053e
        Flags: bus master, fast devsel, latency 0, IRQ 46
        Memory at f6400000 (64-bit, non-prefetchable) [size=4M]
        Memory at d0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at f000 [size=64]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
        Capabilities: [d0] Power Management version 2
        Capabilities: [a4] PCI Advanced Features
        Kernel driver in use: i915
        Kernel modules: i915

Here's what the error looked like when it failed:
[ 6.035344] Oops: 0002 [#1] SMP
[ 6.035410] CPU 5
[ 6.035429] Modules linked in: aesni_intel cryptd aes_x86_64 firewire_ohci(+) i915(+) firewire_core crc_itu_t sdhci_pci(+) sdhci drm_kms_helper drm mxm_wmi i2c_algo_bit wmi video
[ 6.035782]
[ 6.035811] Pid: 243, comm: modprobe Not tainted 3.5.0-17-generic #28-Ubuntu Dell Inc. Precision M4700/082H3V
[ 6.035914] RIP: 0010:[<ffffffff8167f93a>] [<ffffffff8167f93a>] __mutex_lock_slowpath+0xaa/0x150
[ 6.035984] RSP: 0018:ffff880411e3dd38 EFLAGS: 00010246
[ 6.036020] RAX: 0000000000000000 RBX: ffff8804126c9ba0 RCX: 0000000000000000
[ 6.036058] RDX: ffff880411e3dd50 RSI: ffffffffa0041a1a RDI: ffff8804126c9ba4
[ 6.036096] RBP: ffff880411e3dd98 R08: 00000000000003ea R09: 0000000000000000
[ 6.036134] R10: ffffffff8184b320 R11: 0000000000000000 R12: ffff880411e31700
[ 6.036172] R13: ffff8804126c9ba4 R14: 00000000ffffffff R15: ffff8804126c9ba8
[ 6.036210] FS: 00007fbd4717d700(0000) GS:ffff88042e340000(0000) knlGS:0000000000000000
[ 6.036259] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6.036294] CR2: 0000000000000000 CR3: 00000004127bd000 CR4: 00000000001407e0
[ 6.036332] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 6.036370] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 6.036408] Process modprobe (pid: 243, threadinfo ffff880411e3c000, task ffff880411e31700)
[ 6.036456] Stack:
[ 6.036484] 0000000000000000 ffff880417a1a090 ffff880411e3dda8 ffff8804126c9ba8
[ 6.036596] 0000000000000000 0000000000000018 ffff880411e3ddb8 ffff8804126c9ba0
[ 6.036710] ffff8804126c9800 ffff8804126c9ba0 0000000000000000 ffff880417a1a090
[ 6.036826] Call Trace:
[ 6.036861] [<ffffffff8167f43a>] mutex_lock+0x2a/0x50
[ 6.036911] [<ffffffffa012dd4b>] intel_fb_restore_mode+0x2b/0xb0 [i915]
[ 6.036961] [<ffffffffa00f1120>] i915_driver_lastclose+0x30/0x60 [i915]
[ 6.037009] [<ffffffffa001b79a>] drm_lastclose+0x4a/0x320 [drm]
[ 6.037051] [<ffffffffa0021919>] drm_fill_in_dev+0x139/0x1c0 [drm]
[ 6.037095] [<ffffffffa0024243>] drm_get_pci_dev+0xd3/0x310 [drm]
[ 6.037135] [<ffffffff8135ab52>] ? pci_get_subsys+0x92/0xd0
[ 6.037178] [<ffffffffa002454e>] drm_pci_init+0xce...

Simon Jones, if you have a bug in Ubuntu, could you please file a new report by executing the following in a terminal:
ubuntu-bug linux

For more on this, please see the Ubuntu Bug Control and Ubuntu Bug Squad article:
https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue

and Ubuntu Community article:
https://help.ubuntu.com/community/ReportingBugs

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report may cause your problem to not be addressed as quickly as possible.

Thank you for your understanding.

I also encounter this issue on my dell xps 15.
This bug happens for me with kernel 3.5.0-18-generic, but not with 3.5.0-17-generic.

When booting with 3.5.0-18-generic, driver initialization fail, and X fallback to using the vesa driver.

Florent Mertens, if you have a bug in Ubuntu, could you please file a new report by executing the following in a terminal:
ubuntu-bug linux

For more on this, please see the Ubuntu Bug Control and Ubuntu Bug Squad article:
https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue

and Ubuntu Community article:
https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report may delay your problem being addressed as quickly as possible.

Thank you for your understanding.

Christpher, I don't see any reason to open a new bug, this is the exact same issue.

PLease Christopher, could you tell us what is missing to this bug ?
For what I can see this bug was introduced between 3.5.0-18-generic and 3.5.0-17-generic, and looking at the changelog, there is a bunch of i915 changes there.

Upstream is already aware of the issue, see

http://www.spinics.net/lists/kernel/msg1418335.html

So the only thing that needs to be determined, is which quantal patch to the 3.5 mainline has introduced the bug.

As outlined in the message the bug is triggered by adding the "nomodeset" option to the kernel command line which seems to enable a different code path. So booting without nomodeset is fine, but I don't need KMS on a server.

@Markus,

Comment #27 lists some kernel version prior to The final 12.10 kernel. Did you not see this bug in any of those listed kernels? If that is the case, I will post some additional kernels to test.

@Joseph

I tested together with Markus 3.5.0-16.25 and several older ones, all are working.

In 3.5.0-17.26 were some drm/i915 related things added.

Booting the 17.26 prints the following at boot:
 * Starting load fallback graphics devices [fail]

the curious thing is that I can't find anything realted in dmesg/syslog. I attach the dmesg output, maybe I have something overlooked.

Any hints on how I can test the different (44 :( ) commits to drivers/gpu/drm/i915 between 3.5.0-16.25 and 3.5.0-17.26? I'm kinda new to git repositorys.

I've just reported bug 1077658 which looks like it might be the same as this.
This only happens for me if I plug in via a KVM switch, not direclty in via a monitor.

3.7.0-030700rc5 #201211110835 from the nightlies works for me (http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-rc5-raring/ although I'm on a quantal userspace)
  So I say that makes it a fixed upstream

3.6.3-030603 #201210211349 boots but won't start X (but ctrl-alt-f1 gets me a console)

Dave

I tested the 3.7.0-030700rc5 #201211110835 too,
looks like it works without the kernelparameter nomodeset:
[ 9.374325] [drm] Initialized drm 1.1.0 20060810
[ 9.429448] pci 0000:00:00.0: Intel Ivybridge Chipset
[ 9.429524] pci 0000:00:00.0: detected gtt size: 2097152K total, 262144K mappable
[ 9.431003] pci 0000:00:00.0: detected 262144K stolen memory
[ 9.431044] i915 0000:00:02.0: setting latency timer to 64
[ 9.455005] i915 0000:00:02.0: irq 47 for MSI/MSI-X
[ 9.455010] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 9.455011] [drm] Driver supports precise vblank timestamp query.
[ 9.455067] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 9.493056] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off
[ 9.904155] fbcon: inteldrmfb (fb0) is primary device
[ 10.121160] Console: switching to colour frame buffer device 240x67
[ 10.123510] fb0: inteldrmfb frame buffer device
[ 10.123511] drm: registered panic notifier
[ 10.151005] acpi device:43: registered as cooling_device13
[ 10.151117] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
[ 10.151143] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input4
[ 10.151243] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

but with nomodeset:
[ 8.969763] [drm] Initialized drm 1.1.0 20060810
[ 9.019220] wmi: Mapper loaded
[ 9.042668] asus_wmi: ASUS WMI generic driver loaded
[ 9.054022] asus_wmi: Initialization: 0x0asus_wmi: BIOS WMI version: 0.9
[ 9.054063] asus_wmi: SFUN value: 0x0<6>[ 9.054241] input: Eee PC WMI hotkeys as /devices/platform/eeepc-wmi/input/input3
[ 9.054738] asus_wmi: Backlight controlled by ACPI video driver
[ 9.147639] [drm:drm_pci_agp_init] *ERROR* Cannot initialize the agpgart module.
[ 9.147682] DRM: Fill_in_dev failed.
[ 9.452735] r8169 0000:03:00.0 eth0: link down
[ 9.452759] r8169 0000:03:00.0 eth0: link down
[ 9.452790] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 9.756940] init: udev-fallback-graphics main process (830) terminated with status 1

I am facing the same issue on 3.5.0-18 on Ubuntu 12.10 (64-bit)

as Tim wrote, the upstream bug is fixed as of 3.7-rc5. So the only thing that needs to be resolved is the actual quantal bug. As we have tested the mainstream kernels up to 3.5.7, could you please post the pre-release quantal kernels that we should test?

Fazlur, if you have a bug in Ubuntu, could you please file a new report by executing the following in a terminal:
ubuntu-bug linux

For more on this, please see the Ubuntu Kernel team article:
https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports

the Ubuntu Bug Control and Ubuntu Bug Squad article:
https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue

and Ubuntu Community article:
https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report may delay your problem being addressed as quickly as possible.

Thank you for your understanding.

Markus Schade, thank you for your comments. Regarding them https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1070690/comments/45 :
>"as Tim wrote, the upstream bug is fixed as of 3.7-rc5.
Changed in linux (Ubuntu Raring):
status: Incomplete → Fix Released"

The fact Tim said his issue is resolved for him in 3.7-rc5 does not make the linux (Ubuntu Raring) task Fix Released. For more on this, please see https://wiki.ubuntu.com/Bugs/Status .

Thank you for your understanding.

Christopher, please read Tim's post #39. He is testing the platform with me. We are working on the issue together. So the bug is indeed fixed for Raring.

I justed tested several other raring Kernel:
3.6.4-030604-generic
3.6.6-030606-generic
3.7.0-030700rc1-generic
3.7.0-030700rc2-generic
3.7.0-030700rc3-generic
3.7.0-030700rc4-generic

they are all working, dmesg output looks like the one posted in #42

https://github.com/Bumblebee-Project/Bumblebee/issues/277

This change was made by a bot.

Markus Meusel, thank you for your comments. Regarding them https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1070690/comments/48 :
>"Christopher, please read Tim's post #39."

I re-reviewed comment #39 and saw no mention of how either of you tested this issue in a Raring environment, whose Ubuntu kernel is linux 3.7.0-0.5 as per https://launchpad.net/ubuntu/raring/+source/linux . As per #39 Tim tested mainline http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-rc5-raring/ . Correct?

As is known, the Ubuntu kernel and mainline upstream kernel are not the same. Hence, a bug expressed in a Ubuntu kernel, may not necessarily exist in a mainline kernel of a similar looking, but distinctly different version scheme, and vice versa.

"He is testing the platform with me. We are working on the issue together."

I'll keep this in mind.

"So the bug is indeed fixed for Raring."

Did either Tim or you test for this problem in a Raring environment and was unable to reproduce the problem?

Thank you for your understanding.

Karma Dorje, to maintain a respectful atmosphere, please follow the code of conduct - http://www.ubuntu.com/project/about-ubuntu/conduct . Bug reports are handled by humans, the majority of whom are volunteers, so please bear this in mind.

As well, please do not add bumblebee (Ubuntu) tasks as bumblebee has no install candidate from an official Ubuntu repository. Hence, this would not be supported by the Ubuntu project. If you are interested in learning more about software repositories and Ubuntu the following pages should be informative:
1. http://www.ubuntu.com/project/about-ubuntu/components - information about Ubuntu repositories
2. https://help.ubuntu.com/community/Repositories - information regarding managing repositories

As you are a member of Ubuntu Bug Squad, and signer of the Ubuntu Code of Conduct, you should already be familiar with this.

Thank you for your understanding.

Hi,
my previous posts were not accurate enough, sorry for that. To clarify some facts:

The Raring Kernel 3.7.0-0.5 and the newer one from last night 3.7.0-1.7 are as buggy as the real quantal kernel. Their dmesg output is the same as mentioned in my comment #42. Also as written in post #49, the dmesg log from
3.6.4-030604-generic
3.6.6-030606-generic
3.7.0-030700rc1-generic
3.7.0-030700rc2-generic
3.7.0-030700rc3-generic
3.7.0-030700rc4-generic

is the same as mentioned in post #42.

conclusion: none of the listed kernels in this post is working with the bootparameter nomodeset

FYI: the error is still present in the newest 3.7-rc6 mainline release

I talked to Daniel Vetter, he is responsible for the i915 driver and works for Intel. He told me that this chipset series doesn't support the parameter nomodeset. So this bug report can be closed now.

My and Daniels email about this problem: http://lists.freedesktop.org/archives/intel-gfx/2012-November/022707.html

Tim Meusel, thank you for investigating this further. Regarding your comments https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1070690/comments/57 :
>"He told me that this chipset series doesn't support the parameter nomodeset."

He did not say it's not supported. What he said was:
>"Well, you're booting with nomodeset, which then kills the driver because we seem to not properly handle a cleanup cornercase."

>"So, this bug report can be closed now."

Your prior justification does not indicate this bug should be closed. As well, this report being closed is up to Markus Schade, as he is the original reporter.

One thing I am curious about, is their a reason why you/Markus Schade are/is using the nomodeset kernel parameter? If this parameter is removed, do problems occur?

Thank you for your understanding.

Dear Christopher,
Daniel wrote to me in a personal email "usermodesetting was _never_ supported on these machines. " (talking about Ivy Bridge chipsets).

As written by Markus in the initial post, we had an OOPS/Kernel Panic with the i915 driver and the first official Ubuntu 12.10 driver (3.5.17?). As also written before, there are no longer kernel Panics with the new 3.5.18 kernel.

In the past, we had some very hard problems with broken gpu drivers for our servers. The easiest way to fix that was adding the nomodeset parameter to the kernel command line on every server (we are freaks, we have many many servers). Looks like we now have to blacklist every gpu driver on every maschine running kernels newer than 3.6

I think there are really two separate bugs going on here;

  1) For some reason the Intel chipset doesn't like something and gives up
  2) When it cleans up from (1) it panics

It looks to me like 3.5.0-19-generic has fixed the panic on my box; although I still get a black screen - but that looks like a separate
monitor-presence detection problem:
[ 23.572] (II) intel(0): Output VGA1 disconnected
[ 23.572] (II) intel(0): Output HDMI1 disconnected
[ 23.572] (II) intel(0): Output DP1 disconnected
[ 23.572] (WW) intel(0): No outputs definitely connected, trying again...
[ 23.572] (II) intel(0): Output VGA1 disconnected
[ 23.572] (II) intel(0): Output HDMI1 disconnected
[ 23.572] (II) intel(0): Output DP1 disconnected
[ 23.572] (WW) intel(0): Unable to find connected outputs - setting 1024x768 initial framebuffer
[ 23.572] (II) intel(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated.
[ 23.572] (II) intel(0): Kernel page flipping support detected, enabling
[ 23.572] (EE) intel(0): No modes.
[ 23.572] (II) UnloadModule: "intel"
[ 23.572] (EE) Screen(s) found, but none have a usable configuration.

So, I'd say the oops itself is fixed; Markus - is the same true for you?

Dave

Dear Dave,

for Markus and me the oops was fixed in 3.5.0-18. I haven't seen your "intel(0)..." messages on my test systems, where did you get them? dmesg?

Well, the small error message ( *ERROR* Cannot initialize the agpgart module. DRM: Fill_in_dev failed.) when booting without 'nomodeset' is gone. But the oops is still present when booting with nomodeset. But since upstream says that nomodeset is not really supported, I can only assume that only way to avoid modesetting is to to blacklist the i915 module.

Tim, did you file the bug upstream as Daniel requested?

Marking Invalid for Quantal as per https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1070690/comments/62 .

Tim: Apologies, I didn't notice your comment #62
  The oops was in dmesg, as reported in bug 1077658 and as I said in #61 the was fixed in -19 for me.

assuming this is fixed in raring as well.

This depends on the definition of fixed. Booting with "nomodeset" still leads to the originally reported call trace, even in 3.5.0-26-generic #42. So, the workaround is either to blacklist i915 or to add something like "video=1024x768" to the kernel options in order to get a resolution that is not completely insane on a server console.

Confirmed on Raring.
additional information as per Markus Schade above.

xcasex, if you have a bug in Ubuntu, the Ubuntu Kernel team, Ubuntu Bug Control team, and Ubuntu Bug Squad would like you to please file a new report by executing the following in a terminal:
ubuntu-bug linux

For more on this, please see the Ubuntu Kernel team article:
https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports

the Ubuntu Bug Control team and Ubuntu Bug Squad team article:
https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue

and Ubuntu Community article:
https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report would delay your problem being addressed as quickly as possible.

Thank you for your understanding.