Bug 514600 - Intel 82G965 requires 'nomodeset' workaround to get working text-mode
Intel 82G965 requires 'nomodeset' workaround to get working text-mode
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel (Show other bugs)
rawhide
All Linux
low Severity high
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
card_965G
: Reopened
Depends On:
Blocks: fedora-x-blocker
  Show dependency treegraph
 
Reported: 2009-07-29 15:44 EDT by James Laska
Modified: 2013-09-02 02:37 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-04 11:38:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/tmp/syslog (48.16 KB, text/plain)
2009-07-29 15:44 EDT, James Laska
no flags Details
/tmp/anaconda.log (2.12 KB, text/plain)
2009-07-29 15:44 EDT, James Laska
no flags Details
/tmp/syslog (with drm.debug=1) (48.78 KB, text/plain)
2009-07-29 15:59 EDT, James Laska
no flags Details
lspci -nn (2.69 KB, text/plain)
2009-07-30 12:54 EDT, James Laska
no flags Details
/tmp/X.log (9.96 KB, text/plain)
2009-08-06 08:23 EDT, James Laska
no flags Details
/var/log/Xorg.0.log (using xorg-x11-server-1.6.99-27.20090804.fc12) (39.33 KB, text/plain)
2009-08-06 10:35 EDT, James Laska
no flags Details
rawhide-20091102 - /tmp/X.log (x86_64) - with nomodeset (24.30 KB, text/plain)
2009-11-02 08:47 EST, James Laska
no flags Details
rawhide-20091102 - /tmp/X.log (i386) - with nomodeset (40.82 KB, text/plain)
2009-11-02 08:51 EST, James Laska
no flags Details
dmesg (41.08 KB, text/plain)
2009-11-02 15:50 EST, James Laska
no flags Details
/var/log/messages (57.63 KB, text/plain)
2009-11-02 15:51 EST, James Laska
no flags Details
/var/log/Xorg.0.log (21.03 KB, text/plain)
2009-11-02 16:43 EST, James Laska
no flags Details
/var/log/{Xorg.0.log,messages,dmesg) using 2.6.31.5-113.fc12.x86_64 (166.88 KB, text/plain)
2009-11-04 07:24 EST, James Laska
no flags Details

  None (edit)
Description James Laska 2009-07-29 15:44:03 EDT
Created attachment 355600 [details]
/tmp/syslog

Description of problem:

Attempting to install rawhide, when loader starts, the monitor displays a message 'Input not supported'.  I have to boot with 'nomodeset' in order to see the loader prompts for keyboard and language.

Version-Release number of selected component (if applicable):

 * kernel-2.6.31-0.103.rc4.git2.fc12

How reproducible:
100%

Steps to Reproduce:
1. Boot rawhide installer using pxeboot images (vmlinuz+initrd.img)
  
Actual results:

 * Monitor flashes with "Input not supported"

Expected results:

 * See text-mode installer

Additional info:

# Works in Fedora 11 (with updates)
# This seems to have failed today ... but worked in previous days ... investigating
# lspci | grep VGA

00:02.0 VGA compatible controller: Intel Corporation 82G965 Integrated Graphics Controller (rev 02)
Comment 1 James Laska 2009-07-29 15:44:31 EDT
Created attachment 355601 [details]
/tmp/anaconda.log
Comment 2 James Laska 2009-07-29 15:59:04 EDT
Created attachment 355603 [details]
/tmp/syslog (with drm.debug=1)
Comment 3 James Laska 2009-07-30 12:54:05 EDT
Created attachment 355704 [details]
lspci -nn
Comment 4 James Laska 2009-08-03 10:48:29 EDT
Andy is also seeing this on a:

VGA compatible controller [0300]: Intel Corporation 82865G Integrated Graphics Controller [8086:2572] (rev 02)
Comment 5 Adam Williamson 2009-08-04 19:24:24 EDT
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
Comment 6 James Laska 2009-08-06 08:23:05 EDT
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.
Comment 7 Bill Nottingham 2009-08-06 09:46:00 EDT

*** This bug has been marked as a duplicate of bug 515587 ***
Comment 8 James Laska 2009-08-06 10:30:55 EDT
Reopening ... the reported issue needs testing and can now be tested that bug#515587 is resolved.
Comment 9 James Laska 2009-08-06 10:35:31 EDT
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.
Comment 10 James Laska 2009-08-06 10:50:21 EDT
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.
Comment 11 James Laska 2009-10-08 09:06:18 EDT
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
Comment 12 Jesse Keating 2009-10-21 18:18:15 EDT
Still there post-beta?
Comment 13 James Laska 2009-10-22 15:24:27 EDT
(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.
Comment 14 Adam Williamson 2009-10-23 16:36:50 EDT
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
Comment 15 James Laska 2009-10-30 16:40:09 EDT
Sorry ... haven't been in the office this week.  I'll queue this up for Monday morning.
Comment 17 James Laska 2009-11-02 08:46:35 EST
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.
Comment 18 James Laska 2009-11-02 08:47:29 EST
Created attachment 367136 [details]
rawhide-20091102 - /tmp/X.log (x86_64) - with nomodeset
Comment 19 James Laska 2009-11-02 08:51:47 EST
Created attachment 367137 [details]
rawhide-20091102 - /tmp/X.log (i386) - with nomodeset
Comment 20 Adam Jackson 2009-11-02 10:39:43 EST
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?
Comment 21 Bill Nottingham 2009-11-02 11:18:50 EST
I have a 82G965 that works without nomodeset, FWIW.
Comment 22 Adam Williamson 2009-11-02 12:41:36 EST
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
Comment 23 Adam Jackson 2009-11-02 13:32:59 EST
(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.
Comment 24 Adam Williamson 2009-11-02 13:39:09 EST
Huh. I didn't catch that. James, can you clarify?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 25 James Laska 2009-11-02 15:17:01 EST
(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
Comment 26 James Laska 2009-11-02 15:20:38 EST
(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
Comment 27 James Laska 2009-11-02 15:38:43 EST
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...
Comment 28 Adam Jackson 2009-11-02 15:45:24 EST
(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.
Comment 29 James Laska 2009-11-02 15:50:57 EST
Created attachment 367204 [details]
dmesg
Comment 30 James Laska 2009-11-02 15:51:19 EST
Created attachment 367205 [details]
/var/log/messages
Comment 31 James Laska 2009-11-02 16:43:17 EST
Created attachment 367219 [details]
/var/log/Xorg.0.log
Comment 32 Adam Jackson 2009-11-02 16:57:33 EST
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.
Comment 33 James Laska 2009-11-02 19:01:28 EST
(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)
Comment 34 Adam Jackson 2009-11-03 16:51:39 EST
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.
Comment 35 Adam Jackson 2009-11-03 17:03:01 EST
Nuts to that scratch build idea, I'll just build it for F12.  Please test 2.6.31.5-113.fc12.
Comment 36 James Laska 2009-11-03 19:11:48 EST
Kernel installed, I'll be able to visually inspect the results in the morning.
Comment 37 James Laska 2009-11-04 07:24:02 EST
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.
Comment 38 Adam Williamson 2009-11-04 11:38:29 EST
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
Comment 39 François Cami 2009-11-05 02:17:07 EST
(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
Comment 40 Adam Williamson 2009-11-05 02:52:31 EST
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
Comment 41 François Cami 2009-11-07 20:56:59 EST
It appears a different changeset is involved in what I was saying.
Opened bug 533632 with logs.

Note You need to log in before you can comment on or make changes to this bug.