[i945GM] No screen(s) found after updgrade to karmic alpha 5

get-edid and ddcprobe fails to tell anything. I added vesa to xorg.conf and just added something to horizsync and vertrefresh, finally got it boot to gnome.

After upgrade xorg.conf was completely empty? I copied old one that was working with jaunty but that did not help. X -configure created nice long config file, but is was not usable either. Only thing that helped was to change xorg to use vesa.

I think I may have a similar issue. Same hardware works fine on Ubuntu 9.04 but booting Karmic Alpha 5 from a USB stick gives the attached Xorg log.

Monitor is an AG Neovo F-419 LCD panel.
Graphics is an integrated G33 on an Intel DG31PR mainboard.

Just tried with a different monitor (Belinea 17" LCD Panel) and it worked fine first time. I guess it's something funky with the other LCD...

sniver, could you check if it works if you use UMS instead of KMS. You do this by pressing Esc on boot to get the boot menu, then 'e' to edit the command line and then add i915.modeset=0 on the command line (after the last option which I think is splash). If it doesn't work with UMS, then could you try with Jaunty (a LiveCD if you want), add
Option "ModeDebug" "true"
to the "Device" section of xorg.conf and upload the resulting Xorg.0.log here?

It is also normal that there is no xorg.conf in Karmic. Xorg uses a default xorg.conf if none exists, and it is listed in Xorg.0.log.

Alex, bugs like this one is often caused by the monitor being slightly wrong about something. We only treat one case per bug report, since what is wrong is different from monitor to monitor. You may report your AG Neovo F-419 case as another bug.

When I added i915.modeset=0 it returns in boot "Unknown option i915.modeset=0" but still it boots and now with intel graphics! How do I fix it to allways include that option in boot options?

On a Karmic installation, you can add the option to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub (after quiet and splash). If your system is upgraded from Jaunty, it still uses an older Grub version and you need to edit /boot/grub/menu.lst.

Note that this is a workaround and not a fix, and that the UMS option is likely to be removed in the future (hopefully only when bugs like this have been fixed). It would be nice if you could add the ModeDebug option described above and attach the resulting Xorg.0.log here, since that will tell us how the monitor detection works with UMS. The problem seems to be that with KMS the driver thinks that no monitors are attached. It would be nice if you could also attach the output of dmesg for when you boot with KMS (i.e. without the i915.modeset=0 option).

here is xorg.0.log when booted with i915.modeset=0.

Last thing that is showing on screen when trying to boot with KMS is: [drm:intelfb_restore]*ERROR* Failed to restore crtc configration: -22. This text is blinking in endless loop and it can not be stopped?

The UMS log shows that the driver is not able to get EDID information in that case either.
I think this is another example of KMS monitor detection not working very well when the monitor doesn't provide EDID information. See http://<email address hidden>/msg42679.html for a recent discussion on this.

With the latest updates from xorg-edgers or somewhere else the device seems to detect the monitor in someway, as it is creating some graphics to screen. There is just yellow vertical lines blinking at the top of the screen if I try to boot without i915.modeset=0 option. I don`t know if this helps in anyway, but just noticed it few minutes ago.

To make sure that this isn't some artifact of the upgrade process, could you verify that this is also a problem with a LiveCD?

It shouldn't make a difference if you are using xorg-edgers or not, since the monitor detection should happen in the kernel when KMS is used. Could you with an updated Karmic (i.e. 2.6.31-12 kernel) upload Xorg.0.log (again) and the output of `dmesg`, `lspci -vvnn`. I think you may use `apport-collect 429369` to upload these and more, even if Xorg isn't running (you need a launchpad-lib package, but the script will tell you).

Hmm.. I just booted with second monitor connected to device and now it does not complain anything. But still the inbuilt touchscreen is black.

I will add logs for both ways booting. Is it okay to boot in recovery mode and then run startx to create the log? If I try to boot without i915.modeset=0 and without external monitor then the device just blinks those yellow or green lines at the top of screen and I can not make any console commands.

Here is first the logs with external monitor connected and without i915.modeset=0

Here is the logs when rebooted in recovery mode and tried to start x and without i915.modeset=0 option. What I noticed that when I have secondary monitor connected xorg.0.log says there is two vga connectors and when I try without the secondary monitor then there is vga and TV?? I don`t have TV-out in this device..

> Hmm.. I just booted with second monitor connected to device and now it does not complain anything. But still the inbuilt touchscreen is black.

That is what I would expect. When the external monitor is not connected, the driver does not see any connected monitors and therefore exits (with No Screens). When there is an external monitor, it proceeds since it can find one, but it still does not see the internal monitor.

> If I try to boot without i915.modeset=0 and without external monitor then the device just blinks those yellow or green lines at the top of screen and I can not make any console commands.

You should still be able to ssh in from another computer (after installing openssh-server) and run the commands.

Tried to connect from Windows Mobile side of Shift with pocket putty to Ubuntu side and it works when booted with i915.modeset=0 option but when without it, ssh-connection cannot be created as Ubuntu is in some kind of endless loop. Maybe it responses too slowly or something but nothing really happens..

Ok, got it work with usb-ethernet adapter. Here is those logs..

Karmic LiveCD tested -> endless loop saying "failed to restore crtc configuration -22". LiveCD was daily-live build from cdimages.ubuntu.com 20091014/

Seems that i915.resolution=800x480 option works. I also tried to add:

insmod vbe
set gfxmode=800x480
terminal_output.gfxterm
set gfxpayload=keep

before linux command on grub but that did not help. I tought that it would pass correct resolution for booting kernel but I`m not really sure what I`m doing :D

I changed few lines from /etc/default/grub to look like:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.resolution=gfxmode"

and:

GRUB_GFXMODE=800x480

Now grub is configured to use correct resolution and also it goes to booting options. But in this case is KMS used or UMS?

When typing vbeinfo, vbe_mode seems to be 640x480 by default but there is also 800x480 available. Does this mean anything?

Now both i915.modeset=0 or i915.resolution=800x480 option does not work anymore. And if I have seen right the i915 mod has been removed and 915resolution have been added? sudo 915resolution -l command responses: "command not found"

Tried also todays daily cd-image and it does not work either, same problems as earlier.

I found a work-around for this bug, you can see bug #467841, at the end there is a patch (sortof) that enables normal boot with KMS and intel driver and X startx normally with no problem after that.

I did fresh install from usb-startup disk. After that i915.resolution=800x480 works on boot options. And it did not broke after updating.

I was just stupid that I did not know how to add boot options to LiveCD. I don`t know if this is correct way to do it but I just pressed F6 and esc to get boot-line visible and added there i915.resolution=800x480. Without it LiveCD won`t work, it just hangs on boot.

The only work around that has fixed this bug for me so far is adding i915.modeset=0 to my boot options. I don't have this bug in the lucid alpha which indicates it's been fixed in the kernel. Can it be backported to karmic?

Hmm.. I must use i915.resolution=800x480 to start up lucid. Just yesterday I did fresh install from daily livecd.

sniveri,
     We are only backporting major security fixes to Karmic at this point, so I doubt this would meet the definition set forth in the SRU policy. I am glad you were able to verify that this is resolved in Lucid. I'll go ahead and mark this Fix Released.

Please feel free to adjust the bug status and provide an update if you feel this is in error.

Thanks!

-JFo

closing the xorg task as invalid

JFo