Blank (disconnected) screen during boot with latest 2.6.35-rcX kernels
in [Kernel]
|
Prev: [PATCH] math-emu: correct test for downshifting fraction in _FP_FROM_INT()
Next: timer: Added usleep[_range][_interruptible] timer
From: Alex Deucher on 20 Jul 2010 13:30 On Tue, Jul 20, 2010 at 12:47 PM, trapDoor <trapdoor6(a)gmail.com> wrote: > Hi Alex, > >> >> Probably the oem made two similar boards one with dual DVI and one >> with DVI + VGA + HDMI and used the same connector table since the >> encoder routing is still correct even if the connectors are named >> wrong. We can add a quirk to fix it. >> > > I plugged my monitor into the other (white) DVI port and now system > recognises it as DVI: > > [ 18.418] (II) RADEON(0): Output HDMI-0 disconnected > [ 18.418] (II) RADEON(0): Output VGA-0 disconnected > [ 18.418] (II) RADEON(0): Output DIN disconnected > [ 18.418] (II) RADEON(0): Output DVI-0 connected > > As I mentioned before, I guess that on my card HDMI signal is > supported only on the yellow DVI port (through DVI > HDMI adapter), > and even if a device is connected to it directly the system will still > recognise it as HDMI. > >> >> So the patch fixes the issue? I'll send it on then. Looks like your >> systems needs a connector table quirk. Can you send me the pci ids >> for your GPU (lspci -vnn) and a copy of your vbios? To dump your >> vbios (as root): >> cd /sys/bus/pci/devices/<pci bus id> >> echo 1 > rom >> cat rom > /tmp/vbios.rom >> echo 0 > rom >> > > Yes, I confirm it does fix it. Good. > Full lspci output attached and below pasting what's related to my graphics card: > -------------- > 04:00.0 VGA compatible controller [0300]: ATI Technologies Inc > Mobility Radeon HD 3600 Series [1002:9598] > Subsystem: ASUSTeK Computer Inc. Device [1043:01e4] > Flags: bus master, fast devsel, latency 0, IRQ 43 > Memory at d0000000 (64-bit, prefetchable) [size=256M] > Memory at fbfe0000 (64-bit, non-prefetchable) [size=64K] > I/O ports at e000 [size=256] > Expansion ROM at fbfc0000 [disabled] [size=128K] > Capabilities: <access denied> > Kernel driver in use: radeon > > 04:00.1 Audio device [0403]: ATI Technologies Inc RV635 Audio device > [Radeon HD 3600 Series] [1002:aa20] > Subsystem: ASUSTeK Computer Inc. Device [1043:aa20] > Flags: bus master, fast devsel, latency 0, IRQ 45 > Memory at fbffc000 (64-bit, non-prefetchable) [size=16K] > Capabilities: <access denied> > Kernel driver in use: HDA Intel > -------------- > > Vbios dump for bus ID 0000:04:00.0 attached. > The attached patch should fix the connectors to report properly. There are a number of similar ASUS cards with the same quirk. >> >> As to the performance regressions, 2.6.35 added proper support for the >> glx vblank stuff, so you are likely seeing apps synchronized to the >> vrefresh. >> > > I guess you were referring to the glxgears 'test tool' that used to > show (before 2.6.35-rc) much higher number of fps than it does now > when it corresponds to vertical-refresh like it's supposed to. I > noticed the change and assumed it is correct. And I never considered > glxgears as a proper performance test anyway so I wouldn't rely on the > results it gives. > > Where I see a real 3D performance drop now is for example Armagetron > Advanced - a game I use just for testing. I enabled certain features > using 3D in it. Without going into details I just say that with kernel > 2.6.34.1 the overall 3D performance in AA is about twice better. The > game runs quite smooth, number of fps doesn't go under 60. With kernel > 2.6.35-rc5-git3 on the same system, with the same drivers, mesa, drm > etc., the game runs slower and not so smooth, certain details look > slightly worse and I won't get more than 35 fps. > > Apart from that I don't notice any regressions on my desktop, with > compiz effects etc. I'd run some other tests if you could recommend > some tools, but not too complex and rather some specialised software > just for testing purposes, not games. If it's just the kernel that changed is there any chance you could bisect what caused the performance regression? Alex
From: Alex Deucher on 20 Jul 2010 18:10 On Tue, Jul 20, 2010 at 5:54 PM, trapDoor <trapdoor6(a)gmail.com> wrote: >> The attached patch should fix the connectors to report properly. >> There are a number of similar ASUS cards with the same quirk. >> > > Right. I have applied your second patch on top of 2.6.35-rc5-git4 + > 0001-drm-radeon-kms-fix-shared-ddc-harder.patch > > After successful boot from the new kernel, these lines in Xorg.0.log > corresponds now to the outputs I have on my card: > > ### for LCD connected to the first DVI port: > [ � �19.582] (II) RADEON(0): Output DVI-0 connected > [ � �19.582] (II) RADEON(0): Output DIN disconnected > [ � �19.582] (II) RADEON(0): Output DVI-1 disconnected > [ � �19.582] (II) RADEON(0): Using exact sizes for initial modes > [ � �19.582] (II) RADEON(0): Output DVI-0 using initial mode 1920x1080 > > ### LCD connected to the other DVI port: > [ � �18.068] (II) RADEON(0): Output DVI-0 disconnected > [ � �18.068] (II) RADEON(0): Output DIN disconnected > [ � �18.068] (II) RADEON(0): Output DVI-1 connected > [ � �18.068] (II) RADEON(0): Using exact sizes for initial modes > [ � �18.068] (II) RADEON(0): Output DVI-1 using initial mode 1920x1080 > > HDMI output isn't listed any more. So that's seems good. Thanks a lot > for fixing this. Thanks for testing. > > I'm just wondering now what will happen if I connect some HDMI device > via DVI > HDMI adaptor. Should it work? Is HDMI still supported on my > card after applying the last patch? Unfortunately I don't own any > device I could test it on. It will not affect your ability to use HDMI. It only affects the naming. > > Do you expect any problems with applying this patch onto 2.6.34.1? If > not, I could do it as on that kernel the first DVI port is still shown > as HDMI. If the patch works OK on 2.6.34.1, it could be submitted > upstream to the stable branch ? I'll CC stable. > >>> >>> Where I see a real 3D performance drop now is for example Armagetron >>> Advanced - a game I use just for testing. I enabled certain features >>> using 3D in it. Without going into details I just say that with kernel >>> 2.6.34.1 the overall 3D performance in AA is about twice better. The >>> game runs quite smooth, number of fps doesn't go under 60. With kernel >>> 2.6.35-rc5-git3 on the same system, with the same drivers, mesa, drm >>> etc., the game runs slower and not so smooth, certain details look >>> slightly worse and I won't get more than 35 fps. >>> >>> Apart from that I don't notice any regressions on my desktop, with >>> compiz effects etc. I'd run some other tests if you could recommend >>> some tools, but not too complex and rather some specialised software >>> just for testing purposes, not games. >> >> If it's just the kernel that changed is there any chance you could >> bisect what caused the performance regression? >> > > I could find some time for bisecting tomorrow around evening. Prior to > that I'd need a quick look into some manuals .. > Sounds good. Alex > > -- > Regards > trapDoor > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: trapDoor on 20 Jul 2010 18:10
> The attached patch should fix the connectors to report properly. > There are a number of similar ASUS cards with the same quirk. > Right. I have applied your second patch on top of 2.6.35-rc5-git4 + 0001-drm-radeon-kms-fix-shared-ddc-harder.patch After successful boot from the new kernel, these lines in Xorg.0.log corresponds now to the outputs I have on my card: ### for LCD connected to the first DVI port: [ 19.582] (II) RADEON(0): Output DVI-0 connected [ 19.582] (II) RADEON(0): Output DIN disconnected [ 19.582] (II) RADEON(0): Output DVI-1 disconnected [ 19.582] (II) RADEON(0): Using exact sizes for initial modes [ 19.582] (II) RADEON(0): Output DVI-0 using initial mode 1920x1080 ### LCD connected to the other DVI port: [ 18.068] (II) RADEON(0): Output DVI-0 disconnected [ 18.068] (II) RADEON(0): Output DIN disconnected [ 18.068] (II) RADEON(0): Output DVI-1 connected [ 18.068] (II) RADEON(0): Using exact sizes for initial modes [ 18.068] (II) RADEON(0): Output DVI-1 using initial mode 1920x1080 HDMI output isn't listed any more. So that's seems good. Thanks a lot for fixing this. I'm just wondering now what will happen if I connect some HDMI device via DVI > HDMI adaptor. Should it work? Is HDMI still supported on my card after applying the last patch? Unfortunately I don't own any device I could test it on. Do you expect any problems with applying this patch onto 2.6.34.1? If not, I could do it as on that kernel the first DVI port is still shown as HDMI. If the patch works OK on 2.6.34.1, it could be submitted upstream to the stable branch ? >> >> Where I see a real 3D performance drop now is for example Armagetron >> Advanced - a game I use just for testing. I enabled certain features >> using 3D in it. Without going into details I just say that with kernel >> 2.6.34.1 the overall 3D performance in AA is about twice better. The >> game runs quite smooth, number of fps doesn't go under 60. With kernel >> 2.6.35-rc5-git3 on the same system, with the same drivers, mesa, drm >> etc., the game runs slower and not so smooth, certain details look >> slightly worse and I won't get more than 35 fps. >> >> Apart from that I don't notice any regressions on my desktop, with >> compiz effects etc. I'd run some other tests if you could recommend >> some tools, but not too complex and rather some specialised software >> just for testing purposes, not games. > > If it's just the kernel that changed is there any chance you could > bisect what caused the performance regression? > I could find some time for bisecting tomorrow around evening. Prior to that I'd need a quick look into some manuals .. -- Regards trapDoor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |