Bug#453937: hangs when probing (with x86emu on amd64) a radeonhd card

[Robert Millan <rmh@aybabtu.com>]

On Mon, Dec 03, 2007 at 08:53:11AM +0100, Michel Dänzer wrote:
> 
> On Sun, 2007-12-02 at 19:41 +0100, Robert Millan wrote:
> > 
> > I did a bit more testing.  The result is that on either i386 or amd64,
> > ddcprobe hangs if run whenever X is running (but not otherwise).
> > 
> > Sounds like a firmware thread-safety bug.  If you ask me, not sure what was
> > all that big fuss about AMD allowing free drivers if these have to rely on
> > propietary firmware.  oh well...
> 
> The drivers don't have to rely on the firmware, thanks to the non-NDA
> specs.
> 
> Also, I'm not sure this really means it's a firmware issue - maybe the X
> server just holds some resource (e.g. the card ROM, as a guess) that
> ddcprobe needs to run?

At least the ddcprobe part seems to be in firmware.  This is where I caught it
while hang:

(gdb) bt
#0  0x0804a394 in emulate () at lrmi.c:419
#1  0x0804a7ad in run_vm86 () at lrmi.c:621
#2  0x0804aa0f in LRMI_int (i=16, r=0xbf91c9ec) at lrmi.c:844
#3  0x0804b1a4 in get_edid_info () at vbe.c:250
#4  0x0804bb98 in main () at ddcprobe.c:123

after single-stepping to determine which code is running in a loop, much
to my surprise, it eventually reached this:

  fprintf(stderr, "VESA BIOS Extensions not detected.\n");

and aborted.  I'm pretty confused.  Could this hang depend on a timing issue?

Note: this test is on i386, since I assumed running x86 code natively would
      make debugging easier.  I'm not sure why this emulate() is still there
      though.

Again, if the xresprobe migration is going to render this obsolete, please let
me know so I don't waste my time ;-)

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)