Created attachment 21151 [details]
Xorg.0.log and xorg.conf

We have a bug reported to Novell Bugzilla#442416 that points  to this intel bug#18270 as resolution Upstream .


We have tried comment#33in Intelbug18270. It does not resolve our problem. attached is the log collected from trying comment#33.

Since the terminal name in Bug#18270 is for others, had open this bug separately per intel request to deal with IBM terminals.

Michael

This bug is created per yr advise. Any update from intel?

Created attachment 21197 [details]
xorg.log with EXANoComposition

Created attachment 21198 [details]
xorg.conf with EXANoComposite

Let's try turns off 2D acceleration completely.. add  Option "NoAccel" "Yes" to device section. 

Please turn on "ModeDebug" "True" , too, then attach the xorg.log ( no gzip ). 

thanks!

Created attachment 21200 [details]
Xorg.log

Hi Michael, here is the Xorg.log with NoAccel option and ModeDebug turned on. I see a blanked out white screen when X is loaded. But I can still go into the tty consoles which means the system didn't hang.

I've finished current testing on 845GV here. It looks interrupt is broken on it, so I have to disable DRI. After that, everything works fine even with exa composite on. I'm on all git masters, kernel 2.6.28-rc8, xf86-video-intel 2.6-rc1 should be the same, etc.

Zhenyu,

do you need out to test out any option?

yeah, please try Option "DRI" "off".

Created attachment 21228 [details]
Xorg.0.log

added the Option "DRI" "off". Display still does not turn out ok.
Is there any other package that we need to add in?

Guek, do you use the same hardware like Vance's? As your log showed failure with no output detected, which is different with this problem. 

we are using the same physical terminal to test out and report the problem.

(In reply to comment #12)
> we are using the same physical terminal to test out and report the problem.
> 

Do you mean you are using exact same HW environment to do testing as with Vance? But the test result diff is big. Vance at least can still detect the connected monitor. Would you please test it more times to see if you always get the same log? Or double check with Vance how he did the test?

No difference in  hardware that we are using. The terminal comes with an integrated Monitor. 

Tested again. Get the same result. 
No able to get o X window. See this error message " WARNING: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors"

Created attachment 21377 [details]
this the xorg.conf used.

Created attachment 21378 [details]
this is Xorg.0.log

Guek, you're testing this board with only VGA connected or no output connected? Could you paste X log with ModeDebug on?

The board is tested with touchscreen monitor attached phyiscally.
The Xorg.0.log in previous attached already with 'Option "ModeDebug" "true"'.

This is the 'hwinfo --monitor' information.

27: None 00.0: 10002 LCD Monitor
  [Created at monitor.140]
  Unique ID: rdCR.lhai6zl_YJ6
  Hardware Class: monitor
  Model: "IBM Notebook LCD"
  Vendor: "IBM CORPORATION"
  Device: "Notebook LCD"
  Resolution: 1024x768@60Hz
  Size: 305x229 mm
  Driver Info #0:
    Max. Resolution: 1024x768
    Vert. Sync Range: 50-75 Hz
    Hor. Sync Range: 31-69 kHz
  Config Status: cfg=new, avail=yes, need=no, active=unknown

Are you using any kernel vesa driver? like vesafb, etc. maybe you can attach your dmesg. thanks.

Created attachment 21388 [details]
dmesg per request

Is using "intel" video driver. comment#15 xorg.conf is the setup that is used, the xorg.0.log is in comment#16.


Attached is the dmesg.

Guek Wu Neo, 

- Does this machine also comes with two display like other POS machine you are making?

- If you change the driver to vesa, can you get any display work?

thanks.

This POS machine has 2 graphics cards.

Primary is Intel, Secondary is nVidia

Primary video card:
VGA compatible controller [0300]: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device [8086:2562] (rev 03)

Secondary video card:
VGA compatible controller [0300]: nVidia Corporation NV11 [GeForce2 MX/MX 400] [10de:0110] (rev b2)


Yes switching to vesa or fbdev will be able to get to see Xdeskstop for the Primary display( that is connected to the integrated LCD monitor(in comment#18). 

However when vesa is used, once exit to terminal console from Xdesktop, when return to Xdesktop again, will see black screen.

(In reply to comment #22)
> This POS machine has 2 graphics cards.
> 
> Primary is Intel, Secondary is nVidia
> 
> Primary video card:
> VGA compatible controller [0300]: Intel Corporation 82845G/GL[Brookdale-G]/GE
> Chipset Integrated Graphics Device [8086:2562] (rev 03)
> 
> Secondary video card:
> VGA compatible controller [0300]: nVidia Corporation NV11 [GeForce2 MX/MX 400]
> [10de:0110] (rev b2)
> 
> 
> Yes switching to vesa or fbdev will be able to get to see Xdeskstop for the
> Primary display( that is connected to the integrated LCD monitor(in
> comment#18). 
> 
> However when vesa is used, once exit to terminal console from Xdesktop, when
> return to Xdesktop again, will see black screen.
> 

could you please double check if monitor is really connected to the integrated intel graphics? e.g. by connecting two monitors to both VGA ports... thanks.

there will only be display on one monitor even when there are total 2 monitors connected to the 2 vga ports.
Per the xorg.conf, is configured to use port 0:02:0 which is the intel card.

here is the sax2 -p output:
Chip: 0  is -> IBM i845                         00:02:0 0x8086 0x2562 PCI vesa
Chip: 1  is -> NVidia GeForce2 MX/MX 400        01:10:0 0x10de 0x0110 AGP nv

continue on comment#24, the display on the one monitor is as mentioned in comment#14 when intel driver is used.

If vesa or fbdev is used, the display on the one monitor is as mentioned in comment#22

Just reminder one point,  This release of beta6 graphics doesn't have all packages of Intel Q3 release. I am not sure if you have packages the latest driver from SLE11-RC1 factory. RC1 should have Q3 release at all. 

If possible, please have a try. Of course, if you packages intel Q3 release seperately, that is fine.

Thanks

openSUSE 11.1/Novell SLE11 specific
-----------------------------------

  * The issue is that sax2, which runs during installation (and also on 
    LiveCD), does not use Xserver's "-br" option yet and the problem only 
    occurs when this option is not being set. This is the reasons why 
    xdm/gdm/kdm, which now use "-br" option by default, work after 
    installation (after being forced to reboot). Still it's a driver bug.

Hi qwang13, testing has been done on SLED 11 RC1 version already, so from what you mentioned, the graphics packages should be included. We still see the gdm display error when intel driver is used.

Hi Stefan, just to understand your comment a little better, do you mean that during installation we will encounter the error when sax2 attempts to configure the graphics hardware but not post installation? On our machine(563), sax uses VESA for the graphics driver by default so we have to manually change to intel when testing and it is during this process where we will see the display failure. 

Vance, whenever you run 'sax2 -r' or start it from Linux console and use intel driver for 845G you'll run into this situation, since sax2 doesn't use always Xserver's '-br' option. This will be 'fixed' in SaX2 (I consider this a driver bug) in SLE11 RC2.

Hi Michael, based on the Stefan's comments, do you have anything to comment on what needs to be done on the video driver on your side? 

Hi Stefan, about the option -br you mentioned, am I right to say that it is an internal parameter of the sax2 program and not part of the command e.g. sax2 -br? 

-br is an Xserver option.

# Xorg --help
-br                    create root window with black background

Thanks for clarifying. So this means if I start the machine in init3 mode, then manually run Xorg -br, I should be able to replicate the effect of the fix?

Somewhat. There's no fix for Xorg/intel driver. With -br Xserver starts fine, withou this option it hangs.

(In reply to comment #30)
> Hi Michael, based on the Stefan's comments, do you have anything to comment on
> what needs to be done on the video driver on your side? 
> 

Hi Michael, can you provide feedback based on my previous question?

Hi Stefan, since RC2 was delayed slightly, I decided to try running Xorg -br in init3 to try the fix but recieved an error saying no screens found. Would it be helpful to you if I provide the Xorg.log?

Vance, RC2 should be available *very* soon.

Created attachment 22143 [details]
Xorg log in debug mode

I tried using intel driver after installing SLES11 RC2 on the machine and I am still getting this error message:

gdm[2949]: WARNING: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors

Created attachment 22144 [details]
Xorg configuration used

Using 'intel' driver on this 845GV seems not work, as it uses DVO LVDS, our driver has no support. But we also can't make VGA output to work on it, does anyone know why? (BIOS and vesa both can't light it up too)

Hi Zhenyu,

        Here's another update on the testing we have done. We have altogether 4 machines that uses the i845G chipset, 3 of them connects to external displays and one has an integrated display. We tested SLES 11 RC2 on all four machines. On the machines that uses external displays, we could get all of them to function properly in X only when the "noaccel" option is set to true. Without this option, X would hang after logging in. Is it possible to make the display work without disabling acceleration? 

The machine with the integrated display is the one I have been using to provide the logs and is the one with the DVO LVDS issue you mentioned. The dislay works fine when using vesafb or fbdev. I wonder if Novell has any input on this? 

(In reply to comment #41)
> Hi Zhenyu,
> 
>         Here's another update on the testing we have done. We have altogether 4
> machines that uses the i845G chipset, 3 of them connects to external displays
> and one has an integrated display. We tested SLES 11 RC2 on all four machines.
> On the machines that uses external displays, we could get all of them to
> function properly in X only when the "noaccel" option is set to true. Without
> this option, X would hang after logging in. Is it possible to make the display
> work without disabling acceleration? 

this matches the behavior of our machine here.

> 
> The machine with the integrated display is the one I have been using to provide
> the logs and is the one with the DVO LVDS issue you mentioned. The dislay works
> fine when using vesafb or fbdev. I wonder if Novell has any input on this? 
> 

Have you tried the VGA on this kind of 845G machine? I have a sample from you, it never works ever since press the power button. That's why we think this is a HW/FW issue.

(In reply to comment #42)
> > The machine with the integrated display is the one I have been using to provide
> > the logs and is the one with the DVO LVDS issue you mentioned. The dislay works
> > fine when using vesafb or fbdev. I wonder if Novell has any input on this? 
> > 
> 
> Have you tried the VGA on this kind of 845G machine? I have a sample from you,
> it never works ever since press the power button. That's why we think this is a
> HW/FW issue.
> 

Hi, Micheal. Happy New Year to you. So you mean the redwood machine we shipped to you doesn't even boot up? Can you elaborate on what you mean by trying vga on this machine?

it can boot, but only show things on the LVDS panel. There is a VGA D-sub connector on the back. After connect a VGA monitor to it, it's always black ever since power the machine on ( No bios info, no Linux messages, nothing ... )

michael i think your talking about the secondary vga. but why are you doing that, does it because the lcd panel does not work? i cant remember if i send it to you disconnected but it should be easier for you to identify how to connect it  back.  

i got 3 more machines with the same chipsets working, so I cant understand why it shouldnt for Redwood. 

ok. so it's a known issue? I'm not bothering to play with it. I thought you are going to use a dual play on it...

if only LVDS panel is used, why not just use VESA driver, if you only need basic display function? support to 845G is becoming legacy in our driver.

we need dual video support for this machine, thats why we need the 845 driver to work with the primary chipset then we can test the dual video. Right now we are using vesa and we are unable to detect the secondary video.

could you please help us to work on this? as i stated earlier 3 more machines are found working and we dont know why it is not for redwood, the main difference is redwood offers dual video but using a different video card. 

sorry, even bios can't light it up... I'm afraid we can't help. That's why I'm wonderring if it's a HW or FW issue.. Are you using a NV or ATI card in the as the secondary display? that will make things even worse.

(In reply to comment #41)
> Hi Zhenyu,
> 
> Here's another update on the testing we have done. We have altogether 4
> machines that uses the i845G chipset, 3 of them connects to external displays
> and one has an integrated display. We tested SLES 11 RC2 on all four machines.
> On the machines that uses external displays, we could get all of them to
> function properly in X only when the "noaccel" option is set to true. Without
> this option, X would hang after logging in. Is it possible to make the display
> work without disabling acceleration? 

I don't need this option on our 845G machines (FSC + Dell Optiplex GX260)

> The machine with the integrated display is the one I have been using to provide
> the logs and is the one with the DVO LVDS issue you mentioned. The dislay works
> fine when using vesafb or fbdev. I wonder if Novell has any input on this? 

We don't have such a machine at Novell.

Hi Michael, I probably should elaborate our test situation with the Redwood. This machine is the only one that uses an integrated intel i845 chipset with an add-on nvidia Geforce2 MX 400 graphics adapter. For single display(integrated), using intel drivers will give a gdm display error as I have mentioned before. Using vesa/fbdev works perfectly fine. However, when we use vesa in dual display(attaching an external display to nvidia card) mode, there would be no display on the secondary display while the primary display works. 

On a similar machine but using an intel i915 chipset and Ati graphics card, we could get the dual display to work when using intel/radeon driver where using vesa/radeon will give a blank screen on the secondary display(similar to above situation). I hope this clears up the reason why we need to try a working intel driver on this platform.

I also have a test update on SLED 11 RC3:

I reported on RC2 that the three machines that does not use an LVDS output worked with the "NoAccel" "yes" option. In RC3, even with this option, I get a white screen after logging in. I will attaching the screen shot and the Xorg.log with debug on. Any idea what might have changed in RC3 to effect this, Stefan?

Created attachment 22568 [details]
Screen capture of hanged screen

Created attachment 22569 [details]
Xorg.log

> I also have a test update on SLED 11 RC3:
>
> I reported on RC2 that the three machines that does not use an LVDS output
> worked with the "NoAccel" "yes" option. In RC3, even with this option, I get a
> white screen after logging in. I will attaching the screen shot and the
> Xorg.log with debug on. Any idea what might have changed in RC3 to effect this,
> Stefan?

No idea, there weren't any changes for intel driver between RC2 and RC3. No changes for xorg-server, Mesa, libdrm either.

(In reply to comment #50)
> Hi Michael, I probably should elaborate our test situation with the Redwood.
> This machine is the only one that uses an integrated intel i845 chipset with an
> add-on nvidia Geforce2 MX 400 graphics adapter. For single display(integrated),
> using intel drivers will give a gdm display error as I have mentioned before.
> Using vesa/fbdev works perfectly fine. However, when we use vesa in dual
> display(attaching an external display to nvidia card) mode, there would be no
> display on the secondary display while the primary display works. 
> 
> On a similar machine but using an intel i915 chipset and Ati graphics card, we
> could get the dual display to work when using intel/radeon driver where using
> vesa/radeon will give a blank screen on the secondary display(similar to above
> situation). I hope this clears up the reason why we need to try a working intel
> driver on this platform.

we didn't test that, so I don't know how to help you here...

> 
> I also have a test update on SLED 11 RC3:
> 
> I reported on RC2 that the three machines that does not use an LVDS output
> worked with the "NoAccel" "yes" option. In RC3, even with this option, I get a
> white screen after logging in. 
>

I'm confused... Have you ever opened about about this? I mean is there a bug in which we tell you to use "NoAccel" "Yes" to work around? If yes, pls comment on that bug, rather than this bug... thanks.

Michael, this bug was opened for for machines with i845 chipsets having issues with the intel driver included in SLES/D 11. This includes the four machines I mentioned in Comment#41. They were grouped together into this bug because all four uses the same chipset and had the same error when using intel drivers. The NoAccel option was suggested by yourself in Comment#5. We try to use the device options you have mentioned in this thread when we test.

A further update on the three machines I mentioned that requires the NoAccel option, I have verified that in SLES11 RC3 I was able to login and see the desktop with this option(with intel driver). In SLED11 RC3, X would freeze up with a white screen after I logged in. 

Stefan, could it be any application in SLED that is causing this? If so, how I can help to determine which is it?

Maybe Gnome tries to start compiz or KDE its KDE desktop effects. I suggest to try a failsafe Xsession instead to verify this.

(In reply to comment #56)
> Maybe Gnome tries to start compiz or KDE its KDE desktop effects. I suggest to
> try a failsafe Xsession instead to verify this.
> 

You are right Stefan. After uninstalling Compiz from SLED it works just the same as in SLES.

I think finally, this eventually can be concluded as a DVO-LVDS support request. Unfortunately, this is unlikely happen given this DVO support is really becoming legacy

The other lesson we learned is,  we finally know that this platform use a NV card to provide VGA output.. it sounds like there are other "Redwood" system that doesn't use Nv card, while Intel chip provide the VGA output. This is really confusing .. Maybe from your side, they are all Redwood, but for us it's totally different thing and shouldn't be put together in one bug report.

We really should make sure we are talking about just _one_ platform in one bug...

Hi Michael,

The reason we used this bug report for four platforms was because they were using the same chipset and experiencing the same issues in the beginning. But I see you point and agree too that for future bug threads, we will use a separate bug to track each platform, and let them be marked duplicates if found to be as such.

So just to confirm with you that DVO-LVDS support will not be provided for the intel drivers? If so it means we can only use vesa driver and not have dual display support for this machine.

(In reply to comment #59)
> Hi Michael,
> 
> So just to confirm with you that DVO-LVDS support will not be provided for the
> intel drivers? If so it means we can only use vesa driver and not have dual
> display support for this machine.
> 

yes.