*** Bug 10472 has been marked as a duplicate of this bug. ***

Please refer to the previously mentioned link (http://launchpadlibrarian.net/12000527/logs.tgz) for LOG FILES and TRACES, because the attachment is too big for this bugzilla.

(In reply to comment #0)
> Logs and whole story (short - i830M):
> 
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/192088

From this link, It seems you can kill the Xserver via "Ctrl+Alt+Backspace", So X server is not crashed/frozen, it is just blank screen. Can you ssh to this machine? If can, would you please turn on ModeDebug in your xorg.conf and provide two xorg log (warm boot and cold boot)?

Did you use the intelfb module in kernel (grep intelfb in your dmesg log will give you the answer)? If so, please remove it before starting X.

Thanks,
Hong

(In reply to comment #2)
> Please refer to the previously mentioned link
> (http://launchpadlibrarian.net/12000527/logs.tgz) for LOG FILES and TRACES,
> because the attachment is too big for this bugzilla.
> 

Alex, would you please attach them as seperate files here? Also please refer to http://www.intellinuxgraphics.org/how_to_report_bug.html for what we needed.

Thanks Hong and Micheal for your replies and tips.
I am new to X debugging, so it took me a little while ...

Hong, unfortunatly X freezes the whole system, it is NOT possible to kill the server with Crtl-Alt-Backspace. I did this when testing X on the warm booted machine with ltrace/strace.

- linux-image-generic       Version: 2.6.24.8.8
- xserver-xorg-core         Version: 2:1.4.1~git20080131-1ubuntu2
- xserver-xorg-video-intel  Version: 2:2.2.0.90-2ubuntu2
- NO framebuffer is loaded, no vga=... boot options
- system boots without (!) bootsplash
- Option "ModeDebug" "yes" in the Device section of xorg.conf


-------------------------------------
Here's what I did on the hardware and software mentioned above:

1. Removed power plug and battery out of the machine for a few seconds (or leaving the machine for half an hour powered off). The notebook has a relatively new mainboard battery.
Booted into runlevel 5 (gdm disabled).
Ssh'd into the machine as root.

2. Via remote: # strace Xorg > strace_cold.log

RESULT:
X freezes. The resulting trace file is EMPTY. So I attached what I could catch from the remote shell in strace_cold-remoteshell.log.
Rebooted (!) the machine. Saved /var/log/... files as attachments.

------------------------------------
Now I tried something else according to https://wiki.ubuntu.com/DebuggingXorg.

# apt-get install xserver-xorg-core-dbg xserver-xorg-video-intel-dbg

Added the following to xorg.conf
Section "ServerFlags"
        Option "NoTrapSignals" "true"
EndSection

# sudo modprobe drm
# sudo echo 1 | sudo tee /sys/module/drm/parameters/debug
# ulimit -c unlimited
# sudo gdb /usr/bin/Xorg
# (gdb) run -keeptty -dumbSched

kern.log only shows one new line before freeze:
  Feb 19 14:11:18 ibmr31 kernel: [   61.457528] [drm] Initialized drm 1.1.0 20060810

RESULT:
X tries to start but freezes the machine.
No core dump in /etc/X11. I attach the catched gdb remote session.
Rebooted the machine and attached /var/log/Xorg.0.log,messages,kern.log

------------------------------------
For today my time exeeded - sorry.

Could you tell me how to enable coredumps in Xorg in this case? Or probably how to define a breakpoint?

Greets
Axel

Created attachment 14410 [details]
Logs and configuration files for first attempt on X debugging

Created attachment 14411 [details]
Logs and configuration files for SECOND attempt on X debugging

Started new attempts using the above configuration and coming nearer ...
Followed advices in https://wiki.ubuntu.com/Strace 

a. Preparation
# sudo su
# ulimit -c unlimited
# modprobe drm
# echo 1 | tee /sys/module/drm/parameters/debug

b. Run
# strace -Ff -tt /usr/bin/Xorg  2>&1 | tee strace-Xorg.log

RESULT:
With this command, the system does NOT freeze anymore, but X is NOT starting through - it stops, when the error occurs. I didn't go deep into strace, but I hope this is correct - please tell me if I am wrong. I attach the logs.

Thanks for your patience with my efforts in learning debugging ;)
Axel

Created attachment 14423 [details]
THIRD successful attempt debugging with strace after COLD BOOT

Directly (!) after the last post I booted into SuSE 10.3 (3D/DRI enabled) on the same machine and ran glxgears. If I don't do this the "trick" would not work!
I "WARM" (re)booted imediately into ubuntu 8.04. 

I used the same commands as for the COLD boot (the last post) to start Xorg.

RESULT:
X did not came up like expected using strace with "-Ff -tt". It stopped at right the same loacation in strace. So I left them away and just did a plain "strac /usr/bin/Xorg" which leaded into a running X.

Sorry, but my attachments are too big for this bugzilla and I don NOT upload them seperatly (this tests are scripted and it really took to much time and is error prone).

So the logs are here: System always starts into runlevel 5, but without X.
X is started via ssh - see above.

1. First boot (COLD):
http://launchpadlibrarian.net/12091276/Xorg-crash_on_COLD_boot-logs.tar.bz2
RESULT: X does not start and system freeezs completely.
Logs are from the NEXT boot.

2. Second boot (COLD):
http://launchpadlibrarian.net/12091373/Xorg-SECOND%20BOOT%20-%20crash_on_COLD_boot-logs.tar.bz2
RESULT: X does not start, but system keeps usable (only black screen).
Logs are from the same boot.

3. Third boot (WARM and pre initialized via SuSE 10.3):
http://launchpadlibrarian.net/12091181/Xorg-on_warm_boot-logs.tar.bz2
RESULT: X comes up without problem.

Created attachment 14427 [details]
my scripts used for testing

What is the driver version used in your SUSE system? So booting to Suse is always OK wether cold / warm boot?

Would you please try several things:
1. for 1st cold boot, 2nd cold boot and warm boot before starting X, could you try to lspci -xxx and dump the register using intel_reg_dump (in xf86-video-intel/src/reg_dump), and compare the logs to see if there is any difference?

2. for the 1st code boot, from the log
(II) intel(0): I2C bus "DVOI2C_E" removed.                                                            
(II) intel(0): I2C bus "DVOI2C_B" initialized.
1st cold boot stops here, while 2nd cold boot continues...
(II) intel(0): I2C device "DVOI2C_B:i82807aa "ivch" LVDS/CMOS panel controller" registered at address 0

The code is in i830_dvo_init (xf86-video-intel/src/i830_dvo.c),

448         if (gpio_inited != gpio) {
449             if (pI2CBus != NULL)
450                 xf86DestroyI2CBusRec(pI2CBus, TRUE, TRUE);
451             if (!I830I2CInit(pScrn, &pI2CBus, gpio,
452                              gpio == GPIOB ? "DVOI2C_B" : "DVOI2C_E")) {
          ***this create DVOI2C_B bus and both boot reached here***
453                 continue;
454             }
455         }
456 
457         if (drv->vid_rec != NULL)
458             ret_ptr = drv->vid_rec->init(pI2CBus, drv->address);
             ***this will call ivch_init(), it seems the 1st boot froze the sytem in this function.

Would you please try to start Xserver within GDB and set a break point in ivch_init, and then single-step in this function to see which line causes the system freeze.

Thanks,
Hong 

ping update from bug reporter...

Hello again, hello Hong,
first thank you very much for your answer and regard me being so late. I was very busy ... so back to work on open source now ;)

SUSE 10.3:
==========
Your question about the version of xorg in suse 10.3 (rpm -qa --info xorg-x11-server):
Name        : xorg-x11-server 
Version     : 7.2 
Release     : 143.6 - Build Date: Mi 24 Okt 2007 16:24:12 

New is: after doing the tests the driver behaves erratic. Sometimes it takes me three times after a cold boot to get the server running. First time system freezes right upon X startup showing crizzeling cube (the cursor) in the middle of the screen. Second time system freezes with vertical colored lines spread above the whole screen. Third time the boot process run's through and everything is O.K. Then (and only then !!!) it is possible to boot another Linux (e.g. ubuntu) without hazzle using DRI.

Ubuntu Hardy 8.04 LTS:
======================
By the way: another guy had detzected the same problems on a X3100 intel chipset (see: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/192088/comments/8) .

On my ubuntu things changed and a I recognized a new version of the "xserver-video-intel" driver arrived on alpha6 these days. I updated the system again today.
 -> xserver-xorg-video-intel  2:2.2.1-1ubuntu4

And suprise, surprise: The X server system boots now into the graphical desktop after a COLD boot. Using the system in a normal way is no probelem.

BUT - starting an applications that uses DRI (e.g. glxgears or compiz) makes the system freeze again.

DEBUGGING
=========
I booted Ubuntu 8.04, logged remotly via ssh into the machine and started the debugger via ssh:

 # pgrep Xorg
 5413
 # gdb /usr/bin/Xorg
 # (gdb) attach 5413
 [...]
 Loaded symbols for /usr/lib/xorg/modules//libexa.so
 Reading symbols from /usr/lib/dri/i915_dri.so...done.
 Loaded symbols for /usr/lib/dri/i915_dri.so
 Reading symbols from /usr/lib/libexpat.so.1...done.
 Loaded symbols for /usr/lib/libexpat.so.1
 0xb7fe1410 in __kernel_vsyscall ()
As you can see, the i915 drive is loaded, xorg.conf is showing the "intel" Driver. Could that be the problem?

I added the breakpoint
 # (gdb) break i830_dvo.c:438
 Breakpoint 1 at 0xb7b94016: file ../../src/i830_dvo.c, line 438.
 # (gdb) cont

Now I start glxgears, but the system does freeze when starting it. So I cannot get a backtrace again ;( You see I am completely new to X debugging.

Do I have to run glxgears also with the debugger?

Probably it will take a little time for my reply. Thanks for your patience.
Axel

Created attachment 15383 [details]
GLXgears freezes the system

Because the original problem is gone - the system boots into the graphical system  - should I close this thread? Consider, that DRI is not usable anyhow, problem seems so be deallocated into the running X process.

Hi there, since the easter egg search is not possible due to snow in germany/wiesbaden (my car was white this morning) I had some time reading some logs ;)

So the fact, that the graphical system is usable now make testing a lot more comfortable and less time consuming. I first disabled DRI with:
 - Option          "DRI"   "false"
and started testing.

PARTIAL SOLUTION
================
Carefully watching the Xorg.0.log's now, I remembered having some trouble back in time with an option in xorg.conf and the 830M chipset:
 - DefaultDepth    16 (in 'Screen' Section)

After adding the line to the xorg.conf and restarting gdm, the colors of the desktop are much more smooth (concerns depth 16bit).

TEST
====
1. Shutting the notebook down, get the power cord out, get the battery back out. Wait 5 Minutes ... starting into ubuntu 8.04/gnome.
RESULT: Graphical desktop appears like expected.

2. But when I start glxgears, the system freezes completely. Disabling DRI with 
 - Option          "DRI"   "false"
makes the system usable again - naturally. 
I don't no exactly how, but playing arround with playing videos, the following xorg.conf settings 
 - VideoRam        65536          # depreciated!
 - Option         "BackingStore"  "true"
 - Option         "AccelMethod"   "XAA"
together with restarting X several times, got me a running glxgears once, but never again. Unfortunately I could not reproduce this behaviour.

CONCLUSION (for now)
==========
1. This chipset is NOT good for use with 24bit color depth at all - or, in other words: this causes a lot of trouble. Probably the intel driver should respect/take care of this circumstance.

2. Problem with DRI is still the case, but the X boots up for now.

---------------------
I will try a little more. But for now it's enough and I am happy, that I have at least a usable system  - despite without DRI ;(
Adding logs now ...

Created attachment 15391 [details]
Xorg.conf and system logs after a freeze with glxgears.

For your DRI issue, I'd like to suggest you to update your mesa i915 dri driver and kernel drm module, and have a try.

If the problem still exists, please open a new bug about your DRI issue.

I will close this one since the 2D issue seems gone now.

Thanks,
Hong

Thanks too for your guidance.
Axel

After upate of today on the - not yet official - ubuntu hardy / 8.04 with
 - linux-image-generic      Version: 2.6.24.14.16
 - xserver-xorg-core        Version: 2:1.4.1~git20080131-1ubuntu6
 - xserver-xorg-video-intel Version: 2:2.2.1-1ubuntu6

my problems are completely gone ;) ;) ;)
So there is 3D from COLD boot straight after starting X and I could remove my "Option  "DRI" false" line out of xorg.conf.

Real happy now - good work.

I am adding my xorg.conf for the Thinkpad R31.

Created attachment 15728 [details]
Xorg.conf Ubuntu Hardy 8.04 for 1024x768 LCD on TP R31

glad to hear it's working now :)

Hello guys,

sorry to mention, that problems are back again (for a while). I did not have the time to report - sorry.

System:
-------
- Ubuntu hardy heron - 8.04 LTS

Problem description:
--------------------
1.When DRI is enabled and an opengl application starts (e.g. glxgears, stellarium, compiz, ...) system freezes completely. 
2. DRI __is_not__ working any more after rebooting from another linux, where DRI was working (e.g. suse 10.1).

Partial fix:
------------
I had to add "Option  "DRI" false" line in xorg.conf.
So the computer is usable for now with 2D.


I am filing a new bug to i830M and DRI problems within the next days with the according logs.

Hi there after a while,

System: 
-------------------
Thinkpad R31 (specs see above)
Ubuntu 8.10 with
- xserver-xorg       1:7.4~5ubuntu3     the X.Org X server
- xserver-xorg-video-intel  2:2.4.1-1ubuntu10  X.Org X server -- Intel i8xx, - i9xx display driver
- linux-image-generic 2.6.27.7.11        Generic Linux kernel image


Updated Informations
--------------------

I am very pleased to announce, that with upgrade to ubuntu 8.10, several problems are gone under __ONE_ circumstance:
I deleted the xorg.conf completely and let the system decide to configure a new one! Using the old xorg.conf is possible but leads into the described problems above.

FIRST: DRI now works. It is incredibly slow, but no freezes any more ;) No more hangs during boot or starting GL applications (including e.g. metacity compositing manager).

SECOND: The first time ever for the last years, I am able to use the dual screen option to use a second monitor expanding my display - not only the "clone" function.

One glitch: I had to manually add the parts from the keyboard and mouse device section from my old to the new xorg.conf.

A big "thank you" to all intel developers working on these threads!

Greets Axel

Created attachment 20040 [details]
Xorg.conf with auto configuration (except mouse and keyboard) and randr

This make the former solution for xorg.conf obsolete (but only tested for Ubuntu 8.10).

ADDENDUM
--------

Due to some artifacts on the screen I had to add

Section "Screen"
...
   DefaultDepth     16
...

to  the xorg.conf. I suppose this is the same problem with this chipset as mentioned in another post above.