lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <201105091504.54868.thomas@fjellstrom.ca>
Date:	Mon, 9 May 2011 15:04:54 -0600
From:	Thomas Fjellstrom <thomas@...llstrom.ca>
To:	Jerome Glisse <j.glisse@...il.com>
Cc:	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: long delay when using HMDI output on RS780

On May 9, 2011, Thomas Fjellstrom wrote:
> On May 9, 2011, Jerome Glisse wrote:
> > On Mon, May 9, 2011 at 3:50 PM, Thomas Fjellstrom <thomas@...llstrom.ca>
> 
> wrote:
> > > On May 7, 2011, Thomas Fjellstrom wrote:
> > >> I just switched to using HDMI with my media center, and its causing a
> > >> 30+ second delay in the screen turning on, as well as a 7 second delay
> > >> in the X startup when it tries to fetch the EDID information.
> > >> Basically I don't get any picture at all once KMS initializes until
> > >> after X has been up a few seconds.
> > >> 
> > >> The odd thing is the monitor seems to think something is going on,
> > >> since it doesn't go to sleep or display its "No Signal" OSD, but just
> > >> after X starts up, it pops up the "Input detected/switched" OSD, and
> > >> the picture appears.
> > >> 
> > >> The bios, grub2 (in both text mode and graphics mode), and the initial
> > >> linux kernel messages all display fine and immediately. Its only once
> > >> KMS and radeondrmfb initializes that there's a problem (at least till
> > >> X starts up).
> > >> 
> > >> I've just built with a vanila 2.6.38.4 kernel from the stable git
> > >> repo, and have played with some EDID settings, trying to disable edid
> > >> where I could thinking thats what caused the problem. That doesn't
> > >> seem to be the case though. I also tried playing with the video=
> > >> kernel option, trying to force disable VGA-1, and set a static mode
> > >> for HDMI-A-1, but if I try, it seems to force disable HDMI-A-1
> > >> instead of force the mode.
> > >> 
> > >> With a DVI-D cable instead, the problem goes away.
> > >> 
> > >> Attached are the dmesg and xorg.log files for the latest boot with
> > >> HDMI (no video= parameter, and EDID enabled, most settings at
> > >> defaults).
> > >> 
> > >> What exactly would cause this, and is there a way I can fix it?
> > > 
> > > I've been playing around with it more, and got it to not blank the
> > > screen after KMS init, /once/. So far no luck repeating that success.
> > > 
> > > I've tried late, and early kms init, and currently have the radeon
> > > module and firmware compiled into the kernel. Boot times at least are
> > > fairly decent, about 8-10s till X starts, but about 25-35s till
> > > anything shows up.
> > > 
> > > Some strangeness, I have the kernel set to force the hdmi output to on,
> > > with a very specific mode, that X tends to like, the vga port is forced
> > > disabled. X is set to ignore EDID, and also set to that specific mode
> > > that it tends to auto set itself. Regardless X still wants to pause for
> > > 7s 2-3 times while processing EDID info.
> > > 
> > > I've attached the new dmesg and xorg logs from the latest attempts.
> > > 
> > > Note, this only happens with KMS, with HDMI. disabling KMS, or using
> > > DVI makes the problem go away. Even grub's own graphical mode works
> > > fine, its only once KMS inits that things go bad, and its not till
> > > after X is up for a few seconds that something displays on my screen.
> > > 
> > > --
> > > Thomas Fjellstrom
> > > thomas@...llstrom.ca
> > 
> > Please boot with drm.debug=4 and attach dmesg it should be more
> > verbose. You might also want to try booting with radeon.audio=0
> 
> Hi, attached both one with just drm.debug=4, and one with that and
> radeon.audio=0.
> 
> Now, I'm guessing its a bug in my monitor claiming it can do HDMI audio? As
> setting radeon.audio=0 seems to have fixed the blanking problem. And the
> dmesg logs seem to claim that radeon thinks it can do HDMI audio.
> 
> It also seems to be ignoring the mode I've requested via the video= param.
> It at least sees that I want it forced enabled, but claims its 0x0? Or at
> least it seems its picking the preferred mode.
> 
> Still have X blocking for up to 14s though.
> 
> Theres also a bunch of repeated log messages from drm now, every second
> about it seems to spam the following lines: (the last one is repeated a
> bunch of times, with FB:44 or FB:42)
> 
> [   31.330033] [drm:output_poll_execute], [CONNECTOR:13:VGA-1] status
> updated from 2 to 2
> [   31.435455] [drm:radeon_atombios_connected_scratch_regs], DFP1 connected
> [   31.435463] [drm:output_poll_execute], [CONNECTOR:15:HDMI-A-1] status
> updated from 1 to 1
> [   31.437391] [drm:drm_mode_addfb], [FB:42]
> 
> > Cheers,
> > Jerome

Ok, a bit more news. My monitor does indeed support audio, at least it has 
volume buttons, so I assume it has speakers, and should support HDMI audio (I 
have never used it though).

-- 
Thomas Fjellstrom
thomas@...llstrom.ca
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ