Bug 163877

Summary: i915 chipset not supported, SUSE cannot be installed
Product: [openSUSE] SUSE Linux 10.1 Reporter: Josh More <morej>
Component: X.OrgAssignee: Stefan Dirsch <sndirsch>
Status: RESOLVED DUPLICATE QA Contact: Stefan Dirsch <sndirsch>
Severity: Normal    
Priority: P2 - High CC: suse-beta, webb
Version: RC 1   
Target Milestone: ---   
Hardware: i686   
OS: SuSE Linux 10.1   
Whiteboard:
Found By: Third Party Developer/Partner Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: X Configs
Xorg log file
Output of lspci
Output of hwinfo --gfxcard

Description Josh More 2006-04-05 19:13:16 UTC 
When installing either OpenSUSE 10.1 beta 9 or SUSE Linux Enterprise Desktop 10 beta 8, Yast detects the i915 graphics chipset.

However, on running X as test or live, the best it works results in backgrounds of dialogs not appearing, no mouse cursor present, and the system quickly hangs.  CTRL+ALT+Backspace does not work, nor do the CTRL+ALT+F* keys.

Upon a reboot into init leve 1, Sax2 creates a black screen with a dialog box on it.  The dialog has viewable border and titlebar, but the background is black.  The buttons are visible "Change Configuration", "OK", and "Cancel".  The text on the dialog is not, as it is black on black.  There is also no mouse cursor.

When "OK" is selected, the entire system hangs.  After a reboot back into init 1, it appears that SAX did write a new xorg.conf.  I was also able to check the log file, and it seems to indicate that the problem is "ADVANCE_LP_RING: outring (0x27) isn't on a QWord boundary(WW) I810(0): Fixing display offsets."  The "0x27" portion changes.

This is on a Nobilis M31E10.  Our company uses Nobilis laptops everywhere, and we wish to sell Enterprise Desktop 10, once it is released.  However, until we can demo XGL on these laptops, we will not be able to do this.  We are partner #23611.

I have X configs, X logs, and an lspci dump available.
Comment 1 Josh More 2006-04-05 19:16:17 UTC 
Created attachment 76742 [details]
X Configs

X Configs from system, immediately after install and after a manual run of SaX2.
Comment 2 Josh More 2006-04-05 19:16:46 UTC 
Created attachment 76743 [details]
Xorg log file

Log file for failed run of X
Comment 3 Josh More 2006-04-05 19:17:08 UTC 
Created attachment 76745 [details]
Output of lspci
Comment 4 Stefan Dirsch 2006-04-05 20:30:42 UTC 
Could you attach the output of "hwinfo --gfxcard"? Please also try

  Option "noaccel"

in Section "Device" of your /etc/X11/xorg.conf and let me know whether it helps. Maybe we can find a workaround for 10.1/SLED10 with disabling one of
the Acceleration functions ...
Comment 5 Josh More 2006-04-05 20:47:08 UTC 
Created attachment 76763 [details]
Output of hwinfo --gfxcard
Comment 6 Josh More 2006-04-05 20:59:08 UTC 
Using 

Option "noaccel"

Allows X to start, obviously without hardware acceleration.
What is confusing here is that on OpenSUSE 10.0, hardware acceleration worked fine on this laptop with the i810 driver.  OpenSUSE 10.1 is still using that driver, and it does not work with acceleration.

We would like to demo SUSE Desktop 10 with XGL on these laptops.  Are there any other options?
Comment 7 Stefan Dirsch 2006-04-05 21:26:58 UTC 
> Are there any other options?
Yes, of course. I wanted to make sure that disabling hardware acceleration helps at all. Remove the "noaccel" option and try some of these.

"XaaNoCPUToScreenColorExpandFill"
"XaaNoColor8x8PatternFillRect"
"XaaNoColor8x8PatternFillTrap"
"XaaNoDashedBresenhamLine"
"XaaNoDashedTwoPointLine"
"XaaNoImageWriteRect"
"XaaNoMono8x8PatternFillRect"
"XaaNoMono8x8PatternFillTrap"
"XaaNoOffscreenPixmaps"
"XaaNoPixmapCache"
"XaaNoScanlineImageWriteRect"
"XaaNoScreenToScreenColorExpandFill"
"XaaNoScreenToScreenCopy"
"XaaNoSolidBresenhamLine"
"XaaNoSolidFillRect"
"XaaNoSolidFillTrap"
"XaaNoSolidHorVertLine"
"XaaNoSolidTwoPointLine"
"XaaNoWriteBitmap"
"XaaNoWritePixmap"

My favorites are "XaaNoScreenToScreenCopy", "XaaNoSolidFillRect", "XaaNoOffscreenPixmaps" and "XaaNoPixmapCache". Try one by one and if this doesn't help a bunch of them. Sorry, this kind of testing is not fun, I know. :-(
Comment 8 Josh More 2006-04-06 01:57:11 UTC 
Correction, the "noaccel" option gives me working backgrounds, but no mouse cursor.

The option "XaaNoSolidFillRect" gave me the same, with the exception that when I exited X, I got a black screen and did not regain control of my keyboard.  The "noaccel" option gave me back control after I left X.

All of the options had no effect, and the display was frozen even though X exited properly.


 When exiting X, the log reports the following, but the screen never clears:
   waiting for X server to shut down Synaptics DeviceOff called
   ADVANCE_LP_RING: outring (0x7) isn't on a QWord boundary..........
   /usr/X11R6/bin/xinit:  X server slow to shut down, sending KILL signal.
   waiting for server to die

When I run all of the Xaa* options together I still get no mouse, but cannot exit cleanly.  It freezes on a black screen, just like with the "XaaNoSolidFillRect" option.
Comment 9 Stefan Dirsch 2006-04-06 16:43:08 UTC 
> Correction, the "noaccel" option gives me working backgrounds, but no mouse
> cursor.
Add ' Option "SWCursor" '

> When exiting X, the log reports the following, but the screen never clears:
>   waiting for X server to shut down Synaptics DeviceOff called
>   ADVANCE_LP_RING: outring (0x7) isn't on a QWord boundary..........
>   /usr/X11R6/bin/xinit:  X server slow to shut down, sending KILL signal.
>   waiting for server to die
I hope that this does *not* happen when you use "noaccel" ?!?

Since this all looks horribly broken I suggest you try also the failsafe boot option to check whether it's kernel/hardware related.
Comment 10 Stefan Dirsch 2006-04-07 19:20:28 UTC 
JFYI, we urgently need your feedback ...
Comment 12 Josh More 2006-04-09 17:13:24 UTC 
The ' Option "SWCursor" ' gives me a cursor with "noaccel" and with "XaaNoSolidFillRect".

When running in "noaccel" mode with SWCursor, everything looks right, and exits OK.

When running in accelerated mode with "XaaNoSolidFillRect" and "SWCursor", everything looks right, but does not release the display as expected.

Here are log snippets of the difference:

1) Without acceleration:
 Shutting down...
klauncher: Exiting on signal 1
KWrited - Listening on Device /dev/pts/1
unix_connect: can't connect to server (unix:/tmp/ksocket-root/jaguarundi.alliancetechnologies.net-4c19-44330be8)
startkde: Running shutdown scripts...
startkde: Done.
waiting for X server to shut down Synaptics DeviceOff called


2) With acceleration:
Shutting down...
klauncher: Exiting on signal 1
KWrited - Listening on Device /dev/pts/1
unix_connect: can't connect to server (unix:/tmp/ksocket-root/jaguarundi.alliancetechnologies.net-4c19-44330be8)
startkde: Running shutdown scripts...
startkde: Done.
waiting for X server to shut down Synaptics DeviceOff called
ADVANCE_LP_RING: outring (0x7) isn't on a QWord boundary..........
/usr/X11R6/bin/xinit:  X server slow to shut down, sending KILL signal.
waiting for server to die



I did do some more extensive testing, and these problems occur in kde, gnome, windowmaker, fvwm2, mwm, and twm -- along with the error string: "ADVANCE_LP_RING: outring (0x437) isn't on a QWord boundary" (for different memory locations).  Though, in the windowmanagers other than KDE and Gnome, there are other issues with being able to read fonts on dialogs.


In failsafe boot mode, I still get the QWord error message, and exiting X still makes the display hang.
Comment 13 Stefan Dirsch 2006-04-10 10:34:18 UTC 
Thanks for investigation! Probably I need to disable acceleration and enable
software cursor for your notebook for now. 

 Vendor: pci 0x8086 "Intel Corporation"
  Device: pci 0x2592 "915 GM"
  SubVendor: pci 0x1584 "Uniwill Computer Corp"
  SubDevice: pci 0x9800 

I'll try to reproduce on another 915GM based notebook, since we don't have
any Nobilis notebooks for testing available, but it's unlikely that I can. :-(
I'll lower severity afterwards and resolve it as LATER, since it might get
fixed (by accident) with a newer driver release we expect to see for SLES10/SLED10 rather soon.
Comment 14 Stefan Dirsch 2006-04-10 13:14:22 UTC 
According to previous comment. Done for 10.1 > RC1.
Comment 15 Josh More 2006-04-19 17:01:09 UTC 
This bug is still present in 10.1 RC1.  I will try again once RC2 is available.
Comment 16 Stefan Dirsch 2006-04-19 17:08:55 UTC 
RC2 will not be released. You need to test again with the 10.1 final version. I'm sorry. And yes, it's fixed in RC2.
Comment 17 Josh More 2006-05-28 17:14:45 UTC 
I have just tested with 10.1-final (DVD .iso).

The bug is not fixed, and the accelleration was not disabled by the installer.
After the initial boot, there was no cursor and no menus.

I rebooted to init 3, edited xorg.conf and added:

Option "SWCursor"
Option "noaccel"

I can now use my system, but obviously cannot use any accelleration
functionality, such as XGL.

Please let me know if there is anything else you would like me to try.
Comment 18 Stefan Dirsch 2006-05-28 18:20:27 UTC 
Hmm ...

# Uniwill Computer Corp:915 GM
8086 2592 1584 9800
        x       4|i810||||Noaccel,SWcursor||||

Sure, you did an installation and not just an update?
Comment 19 Josh More 2006-05-28 21:57:06 UTC 
Yep, I did a straight install.  I even re-formatted the previous partition to ensure that I didn't run into any upgrade-related issues.
Comment 20 Stefan Dirsch 2006-05-29 01:22:26 UTC 
Marcus, can you help investigate?

Identity.map:
[...]
NAME=Uniwill Computer Corp§DEVICE=915GM§
VID=0x8086§DID=0x2592§SERVER=i810§EXT=§OPT=Noaccel,SWcursor§RAW=§PROFILE=§SCRIPT3D=§PACKAGE3D=§FLAG=DEFAULT§SUBVENDOR=0x1584§SUBDEVICE=0x9800
[...]

For unknown reasons the options are not added to the xorg.conf, although they are specifified in the Identity.map of SaX2 on SUSE 10.1 final.

Jost, please add at least your /var/log/SaX.log.
Comment 21 Stefan Dirsch 2006-05-30 20:46:11 UTC 
This is another similar issue, which might already be fixed by the X.Org 7.1 Intel driver. Closing as duplicate.

*** This bug has been marked as a duplicate of 179773 ***
Comment 22 Stefan Dirsch 2006-07-12 20:32:36 UTC 
reopen
Comment 23 Stefan Dirsch 2006-07-12 20:34:31 UTC 

*** This bug has been marked as a duplicate of 191987 ***