Not sure if this is a bug in anaconda, or Xconfigurator.... I just did a fresh install of RC1 on a machine with a Matrox G400 and an AOC Spectrum 7Glr hooked to the primary output of the Matrox (no secondary head hooked up) The ddc probe reported unknown monitor, so I had to manually select the correct one. This is a regression from 7.1, where this combination was correctly detected. Here's the output from running it command-line [kaboom@verdande tmp]$ sudo /usr/sbin/ddcprobe VESA 2.0 detected. OEM Name: Matrox Graphics Inc. Memory installed = 512 * 64k blocks = 32768kb Supported standard modes: 640x400x256 640x480x256 800x600x16 800x600x256 640x480x32k 640x480x64k 640x480x16m 800x600x32k 800x600x64k 800x600x16m 132x43 (text) EDID read failed. (No DDC-capable monitor attached?) [kaboom@verdande tmp]$
Could you please try running the ddcprobe binary from 7.1? We have heard of this problem - it is not clear if it is a toolchain or kernel related.
Sure [kaboom@verdande sbin]$ sudo ./ddcprobe VESA 2.0 detected. OEM Name: Matrox Graphics Inc. Memory installed = 512 * 64k blocks = 32768kb Supported standard modes: 640x400x256 640x480x256 800x600x16 800x600x256 640x480x32k 640x480x64k 640x480x16m 800x600x32k 800x600x64k 800x600x16m 132x43 (text) EDID ver. 1 rev. 1. Manufacturer: AOC ID: a785 EISA ID: AOCa785 Serial number: 0508b716. Manufactured in week 44 of 1998. Input signal type: analog signal. Screen size max 32 cm horizontal, 24 cm vertical. Gamma: 1.500000. DPMS flags: RGB, active off, suspend, standby. Established timings: 640x480 @ 60 Hz (VGA) 640x480 @ 75 Hz (VESA) 800x600 @ 60 Hz (VESA) 800x600 @ 72 Hz (VESA) 800x600 @ 75 Hz (VESA) 1024x768 @ 75 Hz (VESA) Standard timing 0: 85 Hz, 640x480 Standard timing 1: 85 Hz, 800x600 Standard timing 2: 85 Hz, 1024x768 Standard timing 3: 60 Hz, 1600x1200 Detailed timing 0: Pixel clock: 36000000 Horizontal active time (pixel width): 128 Horizontal blank time (pixel width): 704 Vertical active time (pixel height): 224 Vertical blank time (pixel height): 285 Horizontal sync offset: 56 Horizontal sync pulse width: 56 Vertical sync offset: 3 Vertical sync pulse width: 1 Dimensions: 54x496Detailed timing 1: Pixel clock: 56250000 Horizontal active time (pixel width): 32 Horizontal blank time (pixel width): 1016 Vertical active time (pixel height): 88 Vertical blank time (pixel height): 543 Horizontal sync offset: 32 Horizontal sync pulse width: 64 Vertical sync offset: 3 Vertical sync pulse width: 1 Dimensions: 54x496 Detailed timing 2: Pixel clock: 56250000 Horizontal active time (pixel width): 32 Horizontal blank time (pixel width): 1016 Vertical active time (pixel height): 88 Vertical blank time (pixel height): 543 Horizontal sync offset: 32 Horizontal sync pulse width: 64 Vertical sync offset: 3 Vertical sync pulse width: 1 Dimensions: 54x496 Detailed timing 3: Pixel clock: 78750000 Horizontal active time (pixel width): 256 Horizontal blank time (pixel width): 1056 Vertical active time (pixel height): 0 Vertical blank time (pixel height): 800 Horizontal sync offset: 16 Horizontal sync pulse width: 96 Vertical sync offset: 3 Vertical sync pulse width: 1 Dimensions: 54x496 [kaboom@verdande sbin]$
So were you using the 7.1 ddcprobe binary inside a 7.1 system? Another thing to try is to put the 7.1 ddcprobe binary on a floppy, go to VC2 during the install, mount the floppy and then run the 7.1 ddcprobe inside the 7.2 install environment.
The first one (sudo /usr/sbin/ddcprobe) is 7.2rc1 ddcprobe on 7.2rc1 The second one (sudo ./ddcprobe) is 7.1 ddcprobe on 7.2rc1
This would certainly seem to indicate its a tool chain issue, since the only difference in the two cases is the generated code. I wonder if there is a timing issue involved. Could you possibly rebuild the ddcprobe binary under 7.2RC1 with all optimizations disabled and see if its better?
Hmm, I know I've submitted additional comments (results of the compile w/o optimization, etc.) on this bug that seem to have disappeared from the database. At any rate, I just did a clean install of rc2, and the AOC 7GLR still wasn't detected by anaconda.
What was the basic gist of the compiler optimization stuff? We haven't changed anything in RC2 so unless the toolchain fixed itself, it would still be broken there :)
I searched through all my mails from bugzilla, and I figured out what happened. All my comments about compilation got put on bug #52157. I'll assume I was just a moron, got in a hurry, and put them in the wrong place. At any rate, on stock rc1, I compiled ddcprobe w/o optimization and it detected the monitor. Then I compiled with -O and it detected. Then I compiled with -O2 and it still detected. Ditto for -O3. So, it looked like it was fixed, but then RC2 is broken all over again.
How about with both -O2 and -g since that's how it's compiled in anaconda.
More info: on a stock RC2 system, I run ddcprobe and it fails (as expected, since it fails during install). [kaboom@verdande tmp]$ sudo /usr/sbin/ddcprobe VESA 2.0 detected. OEM Name: Matrox Graphics Inc. Memory installed = 512 * 64k blocks = 32768kb Supported standard modes: 640x400x256 640x480x256 800x600x16 800x600x256 640x480x32k 640x480x64k 640x480x16m 800x600x32k 800x600x64k 800x600x16m 132x43 (text) EDID read failed. (No DDC-capable monitor attached?) [kaboom@verdande tmp]$ So then I compile ddcprobe from the anaconda src rpm (7.1.95). It fails with -O2, -O, and no optimization. It looks like there was a brief window when it magically started working on rc1, and now it's borked again. Here's the strace: [kaboom@verdande ddcprobe]$ sudo strace ./ddcprobe execve("./ddcprobe", ["./ddcprobe"], [/* 36 vars */]) = 0 uname({sys="Linux", node="verdande.oobleck.net", ...}) = 0 brk(0) = 0x804f210 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=83538, ...}) = 0 old_mmap(NULL, 83538, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40000000 close(3) = 0 open("/lib/i686/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20T\304"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=5782000, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 old_mmap(0x4fc27000, 1297576, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4fc27000 mprotect(0x4fd5b000, 36008, PROT_NONE) = 0 old_mmap(0x4fd5b000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x133000) = 0x4fd5b000 old_mmap(0x4fd60000, 15528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4fd60000 close(3) = 0 munmap(0x40000000, 83538) = 0 open("/dev/zero", O_RDONLY) = 3 mmap2(0x10000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x10000 open("/dev/mem", O_RDWR) = 4 mmap2(NULL, 1282, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0 mmap2(0xa0000, 393216, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 4, 0xa0) = 0xa0000 iopl(0x3) = 0 ioperm(0, 0x400, 0x1) = 0 vm86old(0x804e70c) = -1 ENOSYS (Function not implemented) brk(0x804f428) = 0x804f428 brk(0x8050000) = 0x8050000 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40000000 write(1, "VESA 2.0 detected.\n", 19VESA 2.0 detected. ) = 19 write(1, "OEM Name: Matrox Graphics Inc.\n", 31OEM Name: Matrox Graphics Inc. ) = 31 write(1, "Memory installed = 512 * 64k blo"..., 46Memory installed = 512 * 64k blocks = 32768kb ) = 46 write(1, "Supported standard modes:\n", 26Supported standard modes: ) = 26 write(1, "\t640x400x256\n", 13 640x400x256) = 13 write(1, "\t640x480x256\n", 13 640x480x256 ) = 13 write(1, "\t800x600x16\n", 12 800x600x16 ) = 12 write(1, "\t800x600x256\n", 13 800x600x256 ) = 13 write(1, "\t640x480x32k\n", 13 640x480x32k ) = 13 write(1, "\t640x480x64k\n", 13 640x480x64k ) = 13 write(1, "\t640x480x16m\n", 13 640x480x16m ) = 13 write(1, "\t800x600x32k\n", 13 800x600x32k ) = 13 write(1, "\t800x600x64k\n", 13 800x600x64k ) = 13 write(1, "\t800x600x16m\n", 13 800x600x16m ) = 13 write(1, "\t132x43 (text)\n", 15 132x43 (text) ) = 15 iopl(0x3) = 0 ioperm(0, 0x400, 0x1) = 0 vm86old(0x804e70c) = -1 ENOSYS (Function not implemented) vm86old(0x804e70c) = -1 ENOSYS (Function not implemented) vm86old(0x804e70c) = -1 ENOSYS (Function not implemented) vm86old(0x804e70c) = -1 ENOSYS (Function not implemented) vm86old(0x804e70c) = -1 ENOSYS (Function not implemented) vm86old(0x804e70c) = -1 ENOSYS (Function not implemented) vm86old(0x804e70c) = -1 ENOSYS (Function not implemented) <snip lots of these> vm86old(0x804e70c) = -1 ENOSYS (Function not implemented) EDID read failed. (No DDC-capable monitor attached?) munmap(0x40000000, 4096) = 0 _exit(0) = ? [kaboom@verdande ddcprobe]$
-g doesn't seem to make a difference
Since there is a workaround by manually selecting the monitor, I'm going to close this as 'wontfix'. We haven't heard any other reports of this, and it only seems to affect this monitor. Changing things at this point is pretty much reserved to absolutely critical bugs.