Created attachment 355601 [details]
/tmp/anaconda.log

Created attachment 355603 [details]
/tmp/syslog (with drm.debug=1)

Created attachment 355704 [details]
lspci -nn

Andy is also seeing this on a:

VGA compatible controller [0300]: Intel Corporation 82865G Integrated Graphics Controller [8086:2572] (rev 02)

If we're yet at a point where you can get a Rawhide install done, does X behave the same in the installed system? Can we get /var/log/Xorg.0.log from the failure and success cases, if so?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Created attachment 356494 [details]
/tmp/X.log

Attempting to retest by installing rawhide-20090806 which contains:

 * xorg-x11-drv-intel-2.8.0-3.fc12
 * kernel-2.6.31-0.125.rc5.git2.fc12
 * xorg-x11-server-Xorg-1.6.99-25.20090804.fc12

Yields the following Backtrace while starting X:

0: Xorg(xorg_backtrace+0x28) [0x45f3b8]
1: Xorg [0x462d39]
2: /lib64/libpthread.so.0 [0x7ff07095e4c0]
3: /lib64/libc.so.6 [0x7ff06f198b26]
4: /lib64/libc.so.6 [0x7ff06f188150]
5: /lib64/libc.so.6(__isoc99_vsscanf+0x65) [0x7ff06f1778f5]
6: /lib64/libc.so.6(__isoc99_sscanf+0x88) [0x7ff06f177888]
7: Xorg [0x474e8d]
8: Xorg(InitOutput+0x52f) [0x470c0f]
9: Xorg [0x4227aa]
10: /lib64/libc.so.6(__libc_start_main+0xfd) [0x7ff06f131b8d]
11: Xorg [0x4224f9]

I can log this is a separate issue if desired.  I'm installing text-mode now so I can gather more details from a running system.

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

Reopening ... the reported issue needs testing and can now be tested that bug#515587 is resolved.

Created attachment 356524 [details]
/var/log/Xorg.0.log (using xorg-x11-server-1.6.99-27.20090804.fc12)

I can retest install media, but with the updated xorg.x11-server package noted in bug#515587, I now have working X on this system.

Retested with a CD install of F-12-Alpha-TC (includes xorg-x11-server-Xorg-1.6.99-22.20090724.fc12 and xorg-x11-drv-intel-2.8.0-2.fc12)  ... Booting with "nomodeset" is no longer required to get a working X.

This appears to have magically fixed itself.  Hooray for magic.

This problem has resurfaced on the reported system using rawhide-20091007.

* xorg-x11-drv-intel-2.9.0-2.fc12
* kernel-2.6.31.1-56.fc12

Still there post-beta?

(In reply to comment #12)
> Still there post-beta?  

Yes ... the reported problem remains.  Booting with 'nomodeset' is the only workaround to getting output on the attached LCD monitor.

James, can you please post updated Xorg.0.log files, from both failure and success cases, so we can make sure we have the info for the current situation and take a stab at figuring out what's wrong? Thanks.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Sorry ... haven't been in the office this week.  I'll queue this up for Monday morning.

Retested using rawhide-20091102/x86_64 and this has toggled back to working fine.

 * kernel-2.6.31.5-96.fc12.x86_64
 * xorg-x11-drv-intel-2.9.1-1.fc12.x86_64

Retested using rawhide-20091102/i386 and the problem remains.  Seems this is specific to i386. 

Attaching /tmp/X.log for both install cases.

Created attachment 367136 [details]
rawhide-20091102 - /tmp/X.log (x86_64) - with nomodeset

Created attachment 367137 [details]
rawhide-20091102 - /tmp/X.log (i386) - with nomodeset

James, I'm confused.  This bug appears to say "nomodeset doesn't work on x86".  While that is certainly a bug, it's not the default configuration for intel chips, so I'm not sure it's a blocker.  Does _not_ saying "nomodeset" work on this machine now?

I have a 82G965 that works without nomodeset, FWIW.

adam: what the summary means is that James has to use nomodeset to make it work. i.e., it fails with KMS enabled, our default case. he's now specified that it fails only in the 32-bit case, it works with the 64-bit tree.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(In reply to comment #22)
> adam: what the summary means is that James has to use nomodeset to make it
> work. i.e., it fails with KMS enabled, our default case. he's now specified
> that it fails only in the 32-bit case, it works with the 64-bit tree.

But, he hasn't.

The log from the 32-bit case in attachment #367137 [details] has 'nomodeset' in the dump of /proc/cmdline.  That's the "DOESN'T WORK" case.  So, nomodeset doesn't work there; okay, but not default, so probably not a blocker, particularly if _not_ saying nomodeset works.

The 64-bit log in attachment #367136 [details] _also_ has 'nomodeset' in the dump of /proc/cmdline.  That's the "WORKS" case.  So, nomodeset works there; great, but not a bug.

Huh. I didn't catch that. James, can you clarify?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(In reply to comment #24)
> Huh. I didn't catch that. James, can you clarify?

Sure, works fine with rawhide/x86_64.

The failure seems to only present with rawhide/i386

(In reply to comment #23)
> (In reply to comment #22)
> > adam: what the summary means is that James has to use nomodeset to make it
> > work. i.e., it fails with KMS enabled, our default case. he's now specified
> > that it fails only in the 32-bit case, it works with the 64-bit tree.
> 
> But, he hasn't.
> 
> The log from the 32-bit case in attachment #367137 [details] has 'nomodeset' in the dump
> of /proc/cmdline.  That's the "DOESN'T WORK" case.  So, nomodeset doesn't work
> there; okay, but not default, so probably not a blocker, particularly if _not_
> saying nomodeset works.
> 
> The 64-bit log in attachment #367136 [details] _also_ has 'nomodeset' in the dump of
> /proc/cmdline.  That's the "WORKS" case.  So, nomodeset works there; great, but
> not a bug.  

Aha, Sorry Adam, this is a left-over from using snake to boot the installer on an already installed system which was using "nomodeset".

I'll update my results immediately

So, it turns out that when I *properly* retest this issue, "nomodeset" is still required for both i386 and x86_64 installs to get any output from this adapter.

= Booting with *out* "nomodeset" =
 * rawhide/i386 - text loader does not display, monitor shows "Input not supported"
 * rawhide/x86_64 - text loader does not display, monitor shows "Input not supported"

= Booting with "nomodeset" =
 * rawhide/i386 - text loader and graphical stage#2 anaconda display properly
 * rawhide/x86_64 - text loader and graphical stage#2 anaconda display properly

I'll attempt to extract Xorg logs from the KMS failure case...

(In reply to comment #27)

> = Booting with *out* "nomodeset" =
>  * rawhide/i386 - text loader does not display, monitor shows "Input not
> supported"
>  * rawhide/x86_64 - text loader does not display, monitor shows "Input not
> supported"

If stage1 doesn't display, we're failing long before X is involved, so please catch dmesg from these cases as well as attempting to run X.

Created attachment 367204 [details]
dmesg

Created attachment 367205 [details]
/var/log/messages

Created attachment 367219 [details]
/var/log/Xorg.0.log

Okay, this is awesome.  KMS is failing because your EDID is flaky.  Note the different contents for the checksum failures in attachment #367204 [details].  UMS is polite enough to figure out load detection for you anyway, and come up at a semi-reasonable resolution, but KMS is just falling over.

Can you attach "DISPLAY=:0 xrandr -q" output from an X run configured like comment #31?  I'd like to see what the connection sense status is on the VGA output.

(In reply to comment #32)
> Can you attach "DISPLAY=:0 xrandr -q" output from an X run configured like
> comment #31?  I'd like to see what the connection sense status is on the VGA
> output.  

I've manually run 'startx -- -loglevel 9' as a non-root user.  While the startx command makes it seem like X has started, I still see a window on the LCD displaying "Input not supported".

[guest@brutus ~]$ DISPLAY=:0 xrandr -q
Screen 0: minimum 320 x 200, current 800 x 600, maximum 8192 x 8192
VGA1 connected 800x600+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   800x600        85.1*    72.2     75.0     60.3     56.2  
   640x480        85.0     75.0     72.8     59.9  
   720x400        85.0  
   640x400        85.1  
   640x350        85.1  
DVI1 disconnected (normal left inverted right x axis y axis)

Okay, so connection sense is working, but (from statistical analysis of your monitor's garbagey EDID) it really isn't capable of handling 85Hz modes.  THat we're advertising them at all is just silly, that bit of fallback logic should be aiming for 60Hz.

I'll build a scratch kernel.  If you could test it that'd be great, I'll post the link when it's built.

Nuts to that scratch build idea, I'll just build it for F12.  Please test 2.6.31.5-113.fc12.

Kernel installed, I'll be able to visually inspect the results in the morning.

Created attachment 367459 [details]
/var/log/{Xorg.0.log,messages,dmesg) using 2.6.31.5-113.fc12.x86_64

Using 2.6.31.5-113.fc12.x86_64 the system boots with KMS and I'm able to login to the desktop as expected.  The only issue seems to be the resolution.  But I believe that's the point of this defect right?  That the monitor isn't properly reporting this information?

Note, /var/log/messages now contains an error message reporting the EDID failure.  Which I gather is expected also.

Nov  4 07:18:13 brutus kernel: [drm:edid_is_valid] *ERROR* Raw EDID:
Nov  4 07:18:13 brutus kernel: i915 0000:00:02.0: VGA-1: EDID invalid.

AIUI, yeah, you're hitting the fallback-to-probably-safe-resolutions path and you were hitting a bug in that (it tried to use 85Hz refresh rates, which most LCDs can't cope with). As far as I can see from the logs, UMS doesn't actually detect the correct resolution either, it never gets a usable EDID and hits its fallback path too, it just happens to fall back to 1024x768 rather than 800x600 (which KMS falls back to). I dunno why KMS is more conservative than UMS, but...I think it's all behaving as expected now. Closing this, otheradam can re-open if I'm wrong :)

(there's a patch in 117 which tries the EDID four times in KMS rather than just once, but I don't think that'll help you; UMS already tries multiple times, and from your logs, it never hits)

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(In reply to comment #38)
>  I dunno why KMS is more conservative than UMS,
> but...I think it's all behaving as expected now. Closing this, otheradam can
> re-open if I'm wrong :)

We are not, a box I should have access to tonight apparently fails to display anything with that fix (it had EDID failures as well) - kernels before the fix are fine except that the resolution is 800x600 instead of 1600x1200 (high-end CRT). Logs coming in a few hours.
We may have hit an EDID detection regression, if I remember correctly this box was able to detect EDID correctly at F11 GA. I'll investigate and report.

(In reply to comment #37)
> Created an attachment (id=367459) [details]
> /var/log/{Xorg.0.log,messages,dmesg) using 2.6.31.5-113.fc12.x86_64
> 
> Using 2.6.31.5-113.fc12.x86_64 the system boots with KMS and I'm able to login
> to the desktop as expected.  The only issue seems to be the resolution.  But I
> believe that's the point of this defect right?  That the monitor isn't properly
> reporting this information?

James,

You could use xrandr to add the correct mode and switch to it, AFAIK.

F

fcami: please make sure it's isolated to this specific change (we tagged rather a lot of kernels lately) - try all the builds in koji sequentially if possible. and bring logs =) thanks!

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

It appears a different changeset is involved in what I was saying.
Opened bug 533632 with logs.