agpgart-intel not loaded before drm sometimes, causes KMS to fail
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| linux (Ubuntu) |
Fix Released
|
Medium
|
Tim Gardner | ||
| Karmic |
Fix Released
|
Medium
|
Tim Gardner | ||
Bug Description
On some boots drm gets loaded before agpgart-intel, which causes drm to fail. KMS then is not available.
[ 3.151433] [drm] Initialized drm 1.1.0 20060810
[ 3.159541] i915 .&checktime(0000,00,02,':').0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 3.159546] i915 .&checktime(0000,00,02,':').0: setting latency timer to 64
[ 3.159563] [drm:drm_
[ 3.159608] [drm:intelfb_
[ 3.159651] DRM: Fill_in_dev failed.
[ 3.159689] i915 .&checktime(0000,00,02,':').0: PCI INT A disabled
[ 3.159708] i915: probe of .&checktime(0000,00,02,':').0 failed with error -22
[ 3.162053] agpgart-intel .&checktime(0000,00,00,':').0: Intel Mobile Intel® GM45 Express Chipset
[ 3.162861] agpgart-intel .&checktime(0000,00,00,':').0: detected 32764K stolen memory
[ 3.167540] agpgart-intel .&checktime(0000,00,00,':').0: AGP aperture is 256M @ 0xe0000000
ProblemType: Bug
Architecture: amd64
ArecordDevices:
**** List of CAPTURE Hardware Devices ****
card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
Subdevices: 2/2
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/
/dev/snd/pcmC0D0p: kai 3178 F...m pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
Card hw:0 'Intel'/'HDA Intel at 0xf6adc000 irq 21'
Mixer name : 'Intel G45 DEVCTG'
Components : 'HDA:111d76b2,
Controls : 33
Simple ctrls : 20
Date: Wed Sep 16 14:17:04 2009
DistroRelease: Ubuntu 9.10
HibernationDevice: RESUME=
MachineType: Dell Inc. Latitude E6400
Package: linux-image-
ProcCmdLine: BOOT_IMAGE=
ProcEnviron:
PATH=(custom, user)
LANG=de_DE.UTF-8
SHELL=/bin/bash
ProcVersionSign
RelatedPackageV
linux-
linux-firmware 1.18
SourcePackage: linux
Uname: Linux 2.6.31-10-generic x86_64
WpaSupplicantLog:
dmi.bios.date: 05/11/2009
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A14
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.
dmi.product.name: Latitude E6400
dmi.sys.vendor: Dell Inc.
- kern_drmfail.log Edit (76.2 KiB, text/plain)
- AlsaDevices.txt Edit (405 bytes, text/plain; charset="utf-8")
- AplayDevices.txt Edit (269 bytes, text/plain; charset="utf-8")
- BootDmesg.txt Edit (52.4 KiB, text/plain; charset="utf-8")
- Card0.Amixer.values.txt Edit (3.6 KiB, text/plain; charset="utf-8")
- Card0.Codecs.codec.0.txt Edit (7.5 KiB, text/plain; charset="utf-8")
- Card0.Codecs.codec.2.txt Edit (991 bytes, text/plain; charset="utf-8")
- CurrentDmesg.txt Edit (7.3 KiB, text/plain; charset="utf-8")
- Dependencies.txt Edit (1.4 KiB, text/plain; charset="utf-8")
- IwConfig.txt Edit (643 bytes, text/plain; charset="utf-8")
- Lspci.txt Edit (14.4 KiB, text/plain; charset="utf-8")
- Lsusb.txt Edit (806 bytes, text/plain; charset="utf-8")
- PciMultimedia.txt Edit (586 bytes, text/plain; charset="utf-8")
- ProcCpuinfo.txt Edit (1.5 KiB, text/plain; charset="utf-8")
- ProcInterrupts.txt Edit (1.3 KiB, text/plain; charset="utf-8")
- ProcModules.txt Edit (3.8 KiB, text/plain; charset="utf-8")
- RfKill.txt Edit (112 bytes, text/plain; charset="utf-8")
- UdevDb.txt Edit (118.2 KiB, text/plain; charset="utf-8")
- UdevLog.txt Edit (243.2 KiB, text/plain; charset="utf-8")
- WifiSyslog.txt Edit (567.6 KiB, text/plain; charset="utf-8")
Here, my work around for the issue has been to set the following in /etc/initramfs-
# List of modules that you want to include in your initramfs.
#
# Syntax: module_name [args ...]
#
# You must run update-initramfs(8) to effect this change.
#
# Examples:
#
# raid1
# sd_mod
intel_agp
i915 modeset=1
Once this has been configured, you need to run:
sudo dpkg-reconfigure linux-image-
writing in with similar messages in dmesg, Karmic alpha 6 amd64
[ 4.084484] [drm] Initialized drm 1.1.0 20060810
[ 4.118414] i915 .&checktime(0000,00,02,':').0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 4.118421] i915 .&checktime(0000,00,02,':').0: setting latency timer to 64
[ 4.118453] [drm:drm_
[ 4.118521] [drm:intelfb_
[ 4.118579] DRM: Fill_in_dev failed.
[ 4.118619] i915 .&checktime(0000,00,02,':').0: PCI INT A disabled
[ 4.118652] i915: probe of .&checktime(0000,00,02,':').0 failed with error -22
[ 4.210075] agpgart-intel .&checktime(0000,00,00,':').0: Intel 945G Chipset
[ 4.210434] agpgart-intel .&checktime(0000,00,00,':').0: detected 7932K stolen memory
[ 4.213411] agpgart-intel .&checktime(0000,00,00,':').0: AGP aperture is 256M @ 0xe0000000
compiz then refuses to load
The workaround from comment #2 worked here, thanks :)
hi,
today i upgraded karmic. a new kernel came with that, linux-image-
the woraround from #2 helped me, but with changes:
...
intel_agp
i915 modeset=0
Once this has been configured, you need to run:
sudo dpkg-reconfigure linux-image-
some more infos, without workaround, xorg takes 100% cpu, so it it not easy to use the system anymore ;-)
kde,i386, Intel 82852/855GM
has anyone got a clue why this only affects every Xth boot?
with the workaround, it also worked for me with i915.modeset=1 set to grub. But with the last kernel-update i run again in the error. workaround wasn't working for me. at the end, this helped me in /etc/initramfs-
...
fbcon
intel_agp
agpgart
i think fbcon is not needed anymore, was another workaround for black screen
>has anyone got a clue why this only affects every Xth boot?
i think the problem is, when initrd gets updated. maybe dependencies of the modules were not set correctly and drm is complied (and loaded) into kernel before agpgart-intel
Actually, as of linux-image-
Without having read the relevant kernel source, I'd still venture that one of the following causes might be our culprit:
1) the kernel doesn't offer management of module loading order dependencies (unlikely, but you never know).
2) the kernel offers management of module loading order dependencies, but KMS-related modules don't use it (unlikely, but you never know).
3) the kernel offers management of module loading order dependencies, KMS-related modules use it, but in an incorrect way.
4) the kernel offers management of module loading order dependencies, but it is broken, so all attempts by KMS-related modules to use it fail miserably.
Basically, we need a systematic method for loading modules and their dependencies in a predictable order, always. Right now, either we're lacking this or what we have doesn't work as intended.
I have applied the #2 and I don't see again error :
[ 2.919077] [drm:drm_
[ 2.919146] [drm:intelfb_
[ 2.919415] i915: probe of .&checktime(0000,00,02,':').0 failed with error -22
But the issue is not solved, sometimes when I boot, my cpu still @ 100% on Xorg process :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1396 root 20 0 451m 35m 7320 S 100 1.8 0:15.78 Xorg
I end my session and open again and my Xorg seem's to be OK
I also applied the work around in #2 and the problem appears to be resolved. I should mention that I have Intel 8x on-board graphics and not the Intel 915 graphics outlined in the work around but the solution worked perfectly fine on my system.
Please fix this bug for Intel graphics, this is such a good release and I do not want to see anyone miss out on this one like the last release. Thank you Martin-Éric Racine for discovering the solution to this problem and sharing it here. Also, thank you to the community members that pointed me to this bug report.
After a couple of re-boots it seems the problem has returned...
AplayDevices:
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
Subdevices: 0/1
Subdevice #0: subdevice #0
Architecture: i386
ArecordDevices:
**** List of CAPTURE Hardware Devices ****
card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
Subdevices: 1/2
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/
/dev/snd/pcmC0D0c: eligos 2340 F...m pulseaudio
/dev/snd/pcmC0D0p: eligos 2340 F...m pulseaudio
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
Card0.Amixer.info:
Card hw:0 'Intel'/'HDA Intel at 0xf4800000 irq 22'
Mixer name : 'IDT 92HD81B1C5'
Components : 'HDA:111d76d5,
Controls : 26
Simple ctrls : 16
DistroRelease: Ubuntu 9.10
HibernationDevice: RESUME=
MachineType: Dell Inc. Vostro 1320
NonfreeKernelMo
Package: linux (not installed)
ProcCmdLine: BOOT_IMAGE=
ProcEnviron:
SHELL=/bin/bash
PATH=(custom, no user)
LANG=es_CL.UTF-8
ProcVersionSign
RelatedPackageV
linux-
linux-firmware 1.20
RfKill:
Uname: Linux 2.6.31-
UserGroups: adm admin cdrom dialout lpadmin netdev plugdev sambashare vboxusers
WpaSupplicantLog:
dmi.bios.date: 04/08/2009
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A02
dmi.board.name: 0T052J
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.
dmi.modalias: dmi:bvnDellInc.
dmi.product.name: Vostro 1320
dmi.product.
dmi.sys.vendor: Dell Inc.
a temporary solution which have worked for me its too add x-swat ppa and update the system installing the new 2.9 intel driver :
sudo add-apt-repository ppa:ubuntu-
Worked fine for me.... im not sure its the best to do because ppa are no supported by x-ubuntu team....if developpers thinks, its not the good way you can remove my comment.
Have fun guys
I would like to note that twice, this bug surfaced after installing the file syncing application dropbox, which modifies nautilus and might be related somehow.
Fix #2 solved the issue.
Happens to me on the HP Mini.
I have this problem on my Acer Aspire One A110L (Intel Atom processor with 945GME chipset) with Ubuntu 9.10-beta (Linux netbook 2.6.31-11-generic #38-Ubuntu) i386 desktop version. .
[ 2.342900] Linux agpgart interface v0.103
[ 2.509235] [drm] Initialized drm 1.1.0 20060810
[ 2.570171] i915 .&checktime(0000,00,02,':').0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 2.570187] i915 .&checktime(0000,00,02,':').0: setting latency timer to 64
[ 2.570228] [drm:drm_
[ 2.570295] [drm:intelfb_
[ 2.570357] DRM: Fill_in_dev failed.
[ 2.570409] i915 .&checktime(0000,00,02,':').0: PCI INT A disabled
[ 2.570428] i915: probe of .&checktime(0000,00,02,':').0 failed with error -22
glxinfo| grep render
direct rendering: Yes
OpenGL renderer string: Software Rasterizer
My Asus 1005HA netbook (running under UNR 9.10 Beta+) is exhibiting what I believe is the same problem where about 3 boots out of 4 the video driver fails to initialize properly and then performs very slowly.
Linux agpgart interface v0.103
Oct 4 13:58:54 asmodeus kernel: [ 2.038380] [drm] Initialized drm 1.1.0 20060810
Oct 4 13:58:54 asmodeus kernel: [ 2.083409] i915 .&checktime(0000,00,02,':').0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Oct 4 13:58:54 asmodeus kernel: [ 2.083757] i915 .&checktime(0000,00,02,':').0: PCI INT A disabled
Oct 4 13:58:54 asmodeus kernel: [ 2.083826] i915: probe of .&checktime(0000,00,02,':').0 failed with error -22
Except I don't get the "*ERROR* Cannot initialize the agpgart module." message the other users have.
I'm wondering if there's not some sort of race condition where sometimes the video hardware has settled down and is ready to be detected correctly and sometimes it has not.
I modified my /etc/default/grub file by commenting out "GRUB_HIDDEN_
So far, this seems to be working.
The AGP driver and DRM driver are loaded for entirely different devices, so there's no ordering requirement to enforce here. A simple fix would be for i915 to grow a depends on intel-agp.
I take back what I said about the workaround. It stills happens randomly here.
Try running the following:
echo 'install i915 /sbin/modprobe -qb intel-agp ; /sbin/modprobe --ignore-install i915 $CMDLINE_OPTS' > /etc/modprobe.
update-initramfs -u
Should this be bug renamed "i915 missing an explicit dependency on intel_agp" and filed upstream at kernel.org then?
On Mon, 2009年10月05日 at 15:56 +0000, Martin-Éric Racine wrote:
> Should this be bug renamed "i915 missing an explicit dependency on
> intel_agp" and filed upstream at kernel.org then?
>
Exactly.
Scott
--
Scott James Remnant
<email address hidden>
@Scott ... comment #32 fixed it on my system.
@Pete yeah that means we understand this bug, I should stress that if we roll with that fix for 9.10 then we should make sure we come up with a proper solution for 10.04
Proper solutions include soft dependencies between modules, or switching the AGP drivers to an agp subsystem
#32 don't fix the problem (for me). At the first reboot I hope, but after few reboot the problem appear sometimes.
I am also suffering from this bug. I'd like to help fixing it. But it is not possible for me to do a complete install.
If there is any way that I can help by using a Live CD, let me know.
Latest Grub update changed GRUB_TIMEOUT=10 in /etc/default/grub to GRUB_TIMEOUT="10". Removing double quotes and rebuilding grub solved problem for me.
As others have commented earlier, this bug appears to be somewhat random (a race condition?) and so a few successful boots don't mean the bug is fixed. If #32 doesn't do essentially more than #2, it fails every now and then at least here and as such I'm not surprised of comments #12, #31, #37.
I'm with #29 in this and would like to know if it's possible that the module load order doesn't matter as much as whether intel_agp has settled before i915 needs it. If so, could a work-around be udevadm settle or sleep 1 between the module loads? (Specifically, I'm now testing 'install i915 /sbin/modprobe -qb intel-agp ; sleep 1 ; /sbin/modprobe --ignore-install i915 $CMDLINE_OPTS' in /etc/modprobe.
This bug was fixed in the package linux - 2.6.31-12.40
---------------
linux (2.6.31-12.40) karmic; urgency=low
[ Tim Gardner ]
* SAUCE: Created MODULE_
- LP: #430694
* SAUCE: Use MODULE_IMPORT macro to tie intel_agp to i915
- LP: #430694
[ Upstream Kernel Changes ]
* V4L/DVB (12352): gspca - vc032x: Fix mi1310_soc preview and LED
- LP: #310760
-- Tim Gardner <email address hidden> 2009年10月06日 20:25:36 -0600
I can reproduce this pretty reliably on my Latitude D430 when booting with the internal screen and undocked. Curiously I (almost) never get this effect when booting docked and with the external screen; I guess some slight timing difference just wins/loses the race there.
I tried both of Tim's test kernels, and I still get the issue. The final -12.40 upload isn't built yet, so I could not test this one yet.
- dmesg when it fails Edit (41.2 KiB, text/plain)
dmesg when it fails:
[drm] Initialized drm 1.1.0 20060810
i915 .&checktime(0000,00,02,':').0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
i915 .&checktime(0000,00,02,':').0: setting latency timer to 64
[drm:drm_
[drm:intelfb_
DRM: Fill_in_dev failed.
i915 .&checktime(0000,00,02,':').0: PCI INT A disabled
tg3.c:v3.99 (April 20, 2009)
i915: probe of .&checktime(0000,00,02,':').0 failed with error -22
tg3 .&checktime(0000,09,00,':').0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
tg3 .&checktime(0000,09,00,':').0: setting latency timer to 64
agpgart-intel .&checktime(0000,00,00,':').0: Intel 945GM Chipset
agpgart-intel .&checktime(0000,00,00,':').0: detected 7932K stolen memory
agpgart-intel .&checktime(0000,00,00,':').0: AGP aperture is 256M @ 0xd0000000
So it still loads drm first, then i915, then agpgart.
When it works, I get the correct ordering:
agpgart-intel .&checktime(0000,00,00,':').0: Intel 945GM Chipset
agpgart-intel .&checktime(0000,00,00,':').0: detected 7932K stolen memory
agpgart-intel .&checktime(0000,00,00,':').0: AGP aperture is 256M @ 0xd0000000
input: Video Bus as /devices/
ACPI: Video Device [VID] (multi-head: yes rom: no post: no)
ACPI Warning: \_SB_.PCI0.
[drm] Initialized drm 1.1.0 20060810
i915 .&checktime(0000,00,02,':').0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
i915 .&checktime(0000,00,02,':').0: setting latency timer to 64
- modules.dep Edit (232.4 KiB, text/plain)
Seems no dependency is actually generated?
$ grep agp /lib/modules/
kernel/
kernel/
kernel/
Have got 2.6.31-12.40 just now - the issue still exists, while with 2.6.31-11.38 all is OK for me.
@Martin: It should be the other way around, i.e., i915 is dependent on agp
grep i915 /lib/modules/
Tim Gardner [2009年10月07日 13:22 -0000]:
> @Martin: It should be the other way around, i.e., i915 is dependent on
> agp
Hmm. Isn't the actual problem that agp is loaded before drm? Adding a
dependency to i915 wouldn't fix that?
> grep i915 /lib/modules/
$ grep i915 /lib/modules/
kernel/
"grep agp" still yields no dependencies.
This is with -12.40 now.
--
Martin Pitt | http://
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
@Martin: Actually, I was proceeding on the assumption that intel-agp needed to be loaded before i915. Still, its curious that you don't have the i915 dependent on intel-agp. I'll do some more digging.
Sometimes I got:
[ 4.118453] [drm:drm_
[ 4.118521] [drm:intelfb_
I'm on eeepc 1000ha with Ubuntu 9.10 Beta @ 2.6.31-11.
It's pretty random, and no fix till now.
Tim Gardner [2009年10月07日 13:54 -0000]:
> @Martin: Actually, I was proceeding on the assumption that intel-agp
> needed to be loaded before i915.
This is probably also required, but not sufficient (it _also_ needs to
come before drm).
Thanks a lot for your efforts!
Martin
--
Martin Pitt | http://
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
The fix from #2 worked for me. About 10 restarts/boots without incident. Yet to try the 2.6.31-12 update
GM965, x3100 graphics, x-swat drivers (~2.9.0)
Sorry, that's xorg-edgers.
2.6.31-12 is just fine. (With fix from #2)
Have an Inspiron 15n that has a:
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
Trying the fix in comment #71 DOES NOT fix the issue. It will still fail at times.
This is what I did to produce the problem.
Running on Battery power:
1) Boot from cold boot (works)
2) Restart ... KMS fails on boot .. you notice the Ubuntu logo is fuzzy (meanig not at LCD native res) .. also X is slow
3) Restart .... KMS fails .. blah blah
4) Restart ... KMS fails .. blah blah
Looks like if you run off battery you can get one good boot then restart and fails every time. This is how I can accurately reproduce the issue.
I see this from the kernel messages when it fails:
[ 3.093703] i915 .&checktime(0000,00,02,':').0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 3.093710] i915 .&checktime(0000,00,02,':').0: setting latency timer to 64
[ 3.093725] [drm:drm_
[ 3.093771] [drm:intelfb_
[ 3.093815] DRM: Fill_in_dev failed.
[ 3.093854] i915 .&checktime(0000,00,02,':').0: PCI INT A disabled
[ 3.093860] i915: probe of .&checktime(0000,00,02,':').0 failed with error -22
[ 3.096854] agpgart-intel .&checktime(0000,00,00,':').0: Intel Mobile Intel® GM45 Express Chipset
[ 3.097455] agpgart-intel .&checktime(0000,00,00,':').0: detected 32764K stolen memory
[ 3.100916] agpgart-intel .&checktime(0000,00,00,':').0: AGP aperture is 256M @ 0xe0000000
@Martin - I think I've figured it out. The MODULE_
As for drm dependencies, i915 is already dependent on the main drm module.
Tim Gardner [2009年10月07日 15:21 -0000]:
> @Martin - I think I've figured it out. The MODULE_
> macros didn't work for amd64.
Ah! Indeed I am using amd64 here.
> I've applied a big hammer to the problem, so it should be fixed in
> the next upload.
Awesome, thanks!
> As for drm dependencies, i915 is already dependent on the main drm
> module.
So your current upload introduces the drm -> intel_agpgart dependency?
Out of curiosity, what happens on platforms where intel_agpgart
isn't needed, but drm is?
Thanks, Martin
@Martin - this is a generic problem with a number of the drm/agp hardware pairs as long as the AGP hardware code is built as a module. Its also worth noting that this load race issue affects network drivers that are consumers of libphy, e.g., if the associated MII driver has not already registered with libphy, then the NIC driver can't do much. I solved that issue awhile ago by building into the kernel all of the phylib HW modules, not the most elegant solution. I'm going to talk to upstream to see if there is a better solution.
- /var/log/dmesg when agpgart fails to load properly Edit (50.6 KiB, text/plain)
Not sure if the Fix Committed above makes this irrelevant but...
I installed http://
Cold rebooted 3 times, warm reboot 2 times. 4 out of 5 times, the problem recurred.
Info from problem session:
cian@eireog:~$ glxinfo | grep render
direct rendering: Yes
OpenGL renderer string: Software Rasterizer
root@eireog:~# uname -a
Linux eireog 2.6.31-12-generic #39 SMP Tue Oct 6 23:37:52 UTC 2009 i686 GNU/Linux
dmesg and modules.dep attached
This bug was fixed in the package linux - 2.6.31-12.41
---------------
linux (2.6.31-12.41) karmic; urgency=low
[ Tim Gardner ]
* [Config] CONFIG_
- LP: #416325
* SAUCE: Fix MODULE_
The original patch failed to work for amd64.
- LP: #430694
[ Upstream Kernel Changes ]
* ALSA: hda - Add a white-list for MSI option
Upstream cherry-pick: Infrastructure support for #445580
* ALSA: hda - Add HP Pavilion dv4t-1300 to MSI whitelist
- LP: #445580
* ALSA: intel8x0 - Mute External Amplifier by default for Sony VAIO
VGN-T350P
- LP: #410933
* ALSA: intel8x0 - Mute External Amplifier by default for Sony VAIO
VGN-B1VP
- LP: #410933
-- Tim Gardner <email address hidden> 2009年10月07日 11:59:35 -0600
Definitely not fixed for me, my bug is this bug #430876 . Since updating yesterday I have completely lost access to /dev/dri devices. This bug used to appear but I could still access /dev/dri/card0 as /dev/card0. Now it is gone completely.
What is "yesterday"? :-) linux-image-
It's not fixed for me, too.
The "error -22" is fixed, but now with 12.41 I get this (dmesg relevant parts):
...
[ 1.288303] ACPI: Video Device [GFX0] (multi-head: yes rom: yes post: no)
[ 1.341223] Linux agpgart interface v0.103
[ 1.346363] agpgart-intel .&checktime(0000,00,00,':').0: Intel 855GM Chipset
[ 1.347559] agpgart-intel .&checktime(0000,00,00,':').0: detected 8060K stolen memory
[ 1.349446] agpgart-intel .&checktime(0000,00,00,':').0: AGP aperture is 128M @ 0xe8000000
[ 1.515062] [drm] Initialized drm 1.1.0 20060810
[ 1.535304] i915 .&checktime(0000,00,02,':').0: PCI INT A -> Link[LNKA] -> GSI 10 (level, low) -> IRQ 10
[ 1.535324] i915 .&checktime(0000,00,02,':').0: setting latency timer to 64
[ 1.541531] vesafb: framebuffer at 0xe8000000, mapped to 0xf8480000, using 6144k, total 8000k
[ 1.541549] vesafb: mode is 1024x768x32, linelength=4096, pages=1
[ 1.541555] vesafb: scrolling: redraw
[ 1.541562] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[ 1.541649] fb0: VESA VGA frame buffer device
[ 1.551481] Console: switching to colour frame buffer device 128x48
[ 1.722351] ohci1394 .&checktime(0000,02,03,':').2: PCI INT C -> Link[LNKC] -> GSI 11 (level, low) -> IRQ 11
[ 2.074869] [drm] DAC-6: set mode 640x480 0
...
[ 2.660127] i915 .&checktime(0000,00,02,':').0: LVDS-1: no EDID data
[ 2.674940] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
[ 2.675082] Console: switching to colour dummy device 80x25
[ 2.677636] Console: switching to colour frame buffer device 128x48
...
[ 2.751480] render error detected, EIR: 0x00000010
[ 2.751485] [drm:i915_
[ 2.751502] render error detected, EIR: 0x00000010
[ 2.760716] [drm] LVDS-8: set mode 1024x768 c
[ 2.807061] [drm] fb0: inteldrmfb frame buffer device
[ 2.807518] [drm] Initialized i915 1.6.0 20080730 for .&checktime(0000,00,02,':').0 on minor 0
drm is loaded, but xorg won't start. All seems ok in xorg.log, but now it dies. the end of xorg.log:
(II) intel(0): [DRI2] Setup complete
(**) intel(0): Kernel mode setting active, disabling FBC.
(**) intel(0): Framebuffer compression disabled
(**) intel(0): Tiling enabled
(**) intel(0): SwapBuffers wait enabled
(==) intel(0): VideoRam: 131072 KB
(II) intel(0): Attempting memory allocation with tiled buffers.
my vga:
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
Subsystem: Dell Device 014f
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
Latency: 0
Interrupt: pin A routed to IRQ 10
Region 0: Memory at e8000000 (32-bit, prefetchable) [size=128M]
Region 1: Memory at e0000000 (32-bit, non-prefetchable) [size=512K]
Region 2: I/O ports at 1800 [size=8]
Kernel driver in use: i915
Kernel modules: i915
any ideas?
@Daniel - you appear to have a different problem, i.e., its no longer module load order. Start a new bug using the information at https:/
The updates fix this bug on my system. However, when I log in now, compiz is
not running. I have to run compiz --replace to get it running, but it works
just fine once I do that. Would this be related to this bug, or should I
file a new one?
@crashsystems - yes, you have a different bug.
@crashsystems most likey its not a bug. gconf remembers your last setting with was without compiz.
Go to System-
and select either Normal or Extra and compiz should come up and stay.
2.6.31-12.41 made things worse here: whenever rebooting the computer, instead of getting the BIOS prompt, I get a lot of video garbage, immediately followed by the most recent kernel booting.
Verified fixed the Inspiron 15n. Now KMS comes up every time.
With the new kernel 2.6.31-13.43 the problem is come back, my first CPU still at 100% with Xorg
YannTech, can you please confirm that you have lines like
>[ 3.159563] [drm:drm_
>[ 3.159608] [drm:intelfb_
in your log. Otherwise you have another bug, maybe Bug #439138.
No this line in my dmesg, sorry for the bad report.
I'm affected by the bug you mentionned #439138
thanks
Latest kernel fixes the issue for me, without the tweak from #32.
cian@eireog:~$ glxinfo | grep -i "renderer string"
OpenGL renderer string: Mesa DRI Intel(R) 915GM GEM 20090712 2009Q2 RC3 x86/MMX/SSE2
cian@eireog:~$ uname -a
Linux eireog 2.6.31-13-generic #44-Ubuntu SMP Sat Oct 10 15:27:55 UTC 2009 i686 GNU/Linux
Seemingly the problem continues in 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686 GNU/Linux
on Thinkpad X61
I was still experiencing this today despite having the later kernel installed, because for some reason grub2's menu was not showing all of the installed kernels but rather was stuck on -11. When I manually change the grub commands to boot -15, the problem seems to be fixed.
OK, my comment in #112 was a local problem because I hadn't completed the grub2 upgrade - but if others are still seeing this bug they might want to check grub's actually booting what they think it should be.