Bug 15521

(II) RADEONHD(0): Getting BIOS copy from legacy VBIOS location
(EE) RADEONHD(0): Invalid BIOS length field
(II) RADEONHD(0): Query for AtomBIOS Init: failed

Appearantly X cannot read the VBIOS image of the the card. This is not a driver issue but an issue of the Xserver.
The real underlying problem is that the driver is unable to obtain information on the connector table. This information could also be hard coded in the driver itself but to do this you'd either have to run the card in a system that can access the VBIOS and either run X on it or dump me a copy of the BIOS or you will have to run rhd_conntest to obtain connector information.
The latter would have to be done for each connector separately. Please consult 
http://wiki.x.org/wiki/radeonhd for more information.
You can also use 'rhd_conntest -d' to try and dump the BIOS. I doubt that this will work on a later Alpha with multiple PCI hoses.
 
It's quite likely that the support for Alphas is broken in the current Xserver.
It used to work well and I myself stuck a lot of effort into making it work.
Unfortunately the Linux systems on all my Alphas are so stale that it's not possible to build a later version of X. Also I can't find the time to reinstall one of the systems with a later X even on the fastest of my Alphas.

Matt, I'm assigning this to you to provide the information requested (due to a lack of a NEEDINFO state). Please assign this back when you have provided this.

Matt, I've just pushed a change which may already fix your problem. Please get the latest driver bits from GIT and test.
If this doesn't help please provide the information requested in comment #1.

Created attachment 15958 [details]
X log with new driver

X suffers from some of the same problems, but it looks like the additions to the driver were a step in the right direction.

Created attachment 15959 [details]
X1550 BIOS

The BIOS support of X for this Alpha model seems to be suboptimal. Now we get:

(EE) Cannot find empty range to map base to
(WW) RADEONHD(0): Read only 0 of 131072 bytes of BIOS image
(II) RADEONHD(0): Query for AtomBIOS Init: failed
(--) RADEONHD(0): VideoRAM: 262144 kByte

So we have to try to live without the BIOS. I will look at your BIOS and get the connector table.

Created attachment 15963 [details] [review]
Add hard coded connector table for the card in question.

This patch adds the connector table for this card. You also need to add a line:
#define USE_ID_CONNECTORS
to src/rhd_id.c
Matt, please test :)

Created attachment 15988 [details]
X log with proposed patches

X now starts cleanly!

There are still some (unfixable?) errors in the log. I don't know if there's anything that can be done about them.

One other note, X hangs a long time (10 seconds, maybe) after this line is printed to the log.

(II) RADEONHD(0): I2C device "RHD I2C line 0:ddc2" registered at address 0xA0.

The line directly after is

(II) RADEONHD(0): I2C device "RHD I2C line 0:ddc2" removed.

I don't know if this means the card doesn't actually have this, or what.

Please mark fixed if you think this is satisfactory. Thank you very much :)

We can probably reduce the loop value in the driver to fix the long wait.
For some reason there is not DDC data dumped for this driver.
You could to a -logverbose 8 to get a very verbose log that may help to shed some light on this.

The other issues are due to not being able to find AtomBIOS. For this the result is already pretty good.
If you can put the card into a x86 or x86-46 PC you could run rhd_conntest <pci_id> with the VGA connected to see if we are probing the right DDC port.

Relevant information from this X1550 in my AMD64 box.

# lspci | grep ATI
02:00.0 VGA compatible controller: ATI Technologies Inc RV516 [Radeon X1300/X1550 Series]
02:00.1 Display controller: ATI Technologies Inc RV516 [Radeon X1300 Pro] (Secondary)

# ./rhd_conntest -s 2:00:00
rhd_conntest: v1.2.1, git branch master, commit 0dd39c82
Checking connectors on 0x7183, 0x1092, 0x3000  (@02:00:00):
  Load Detection: RHD_OUTPUT_DACA
  HotPlug: RHD_HPD_NONE 
  DDC: RHD_DDC_0
  DDC Line[0]: Slaves: a0 a2 a4 a6 a8 aa ac ae

# ./rhd_conntest 2:00:00
rhd_conntest: v1.2.1, git branch master, commit 0dd39c82
Checking connectors on 0x7183, 0x1092, 0x3000  (@02:00:00):
  Load Detection: RHD_OUTPUT_DACA
  HotPlug: RHD_HPD_NONE 
  DDC: RHD_DDC_0

Created attachment 16034 [details]
X log from X1550 installed in AMD64 system with logverbose 8

Matt, in the log in comment #10 DDC reading worked flawlessly:

(II) RADEONHD(0): I2C device "RHD I2C line 0:ddc2" registered at address 0xA0.
(II) RADEONHD(0): FUNCTION: rhd5xxWriteRead
(II) RADEONHD(0): FUNCTION: rhd5xxI2CSetupStatus
(II) RADEONHD(0): FUNCTION: rhd5xxWriteReadChunk
(II) RADEONHD(0): FUNCTION: rhd5xxI2CStatus
(II) RADEONHD(0): SW_STATUS: 0x1 4938
(II) RADEONHD(0): FUNCTION: rhd5xxI2CStatus
(II) RADEONHD(0): SW_STATUS: 0x1 4532
(II) RADEONHD(0): FUNCTION: rhd5xxWriteReadChunk
...
II) RADEONHD(0): FUNCTION: rhd5xxI2CStatus
(II) RADEONHD(0): SW_STATUS: 0x1 4743
(II) RADEONHD(0): EDID data for CMC 17" AD
(II) RADEONHD(0): Manufacturer: CMO  Model: 7801  Serial#: 0
(II) RADEONHD(0): Year: 2003  Week: 22
...

So I assume that you didn't see the 10 second delay either. 
Now, why did it work this time:
- Was it just a bad contact?
- Was it because you ran rhd_conntest (or even rhd_conntest -s) before?Could you Matt, if you don't mind, please try again on a freshly booted system, start X normally and see if you get DDC output. If you don't, please run rhd_conntest and see if X shows DDC when started afterwards.
Thanks!

> So I assume that you didn't see the 10 second delay either. 
> Now, why did it work this time:
> - Was it just a bad contact?
> - Was it because you ran rhd_conntest (or even rhd_conntest -s) before?Could
> you Matt, if you don't mind, please try again on a freshly booted system, start
> X normally and see if you get DDC output. If you don't, please run rhd_conntest
> and see if X shows DDC when started afterwards.
> Thanks!

I did not experience the delay on my AMD64 system. I also did not have to do anything special. I just booted with the Radeon X1550 instead of my standard X800 (after switching xorg.conf to use radeonhd) and it X starts perfectly. Running rhd_conntest beforehand is not necessary.

The information posted in comment #9 was retrieved after X had started on the AMD64 box.

Would posting an X log from the Alpha with -logverbose 8 be of any use?

(In reply to comment #12)
 
> The information posted in comment #9 was retrieved after X had started on the
> AMD64 box.

That's expected. If this would have caused any hang we would probably have seen it here, too.

> 
> Would posting an X log from the Alpha with -logverbose 8 be of any use?
> 

Matt, yes, please provide this when running on the Alpha!
Also please try rhd_conntest on the Alpha - like you did in comment #9 for the AMD64 system. Thanks!

Created attachment 16138 [details]
X log with X1550 installed in Alpha system with logverbose 8

# lspci | grep ATI
0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV516 [Radeon  1300/X1550 Series]
0000:01:00.1 Display controller: ATI Technologies Inc RV516 [Radeon X1300 Pro] (Secondary)

# ./rhd_conntest -s 01:00.0
rhd_conntest: v1.2.1, git branch master, commit 0dd39c82
No BIOS Signature found!
No AtomBios signature found
Cannot analyze AtomBIOS

# ./rhd_conntest -s 01:00.1
rhd_conntest: v1.2.1, git branch master, commit 0dd39c82
Unknown device: 0x1002:0x71A3 (01:00.01).

This information was collected after X had been started, while X was still running.

Ok, rhd_conntest didn't return any reasonable response because AtomBIOS is not available. I will check the code so that it just disable functions that require BIOS access.

Matt, I've pushed a change to rhd_conntest which should make it work regardless if AtomBIOS is available or not. Please retest.
Also I've pushed your connector table. You still need to compile with 
#define USE_ID_CONNECTORS
Please test on your Alpha! We may have to readjust the fallback timing parameters used when AtomBIOS isn't available.

Created attachment 16229 [details]
X log in Alpha after echo 1 > enable

Dave Airlie suggested I attempt the following commands before starting X.

/sys/bus/pci/devices/0000:01:00.0 # echo 1 > enable
/sys/bus/pci/devices/0000:01:00.0 # echo 1 > rom

After these commands, cat rom > /tmp/rom still turns up a blank file, but X starts properly with an unpatched radeonhd driver. The X log appears to show it successfully read the BIOS. There is no 10 second delay, but there are still a few (EE) in the log.

I don't think manually executing these commands constitutes a fix.

OK, this sounds good. Still I would like to make sure that DDC also works without AtomBIOS. I've pushed a fix that should do this. Matt, would you mind to test this  for me? 
You'd either have to boot afresh or do a:

/sys/bus/pci/devices/0000:01:00.0 # echo 0 > rom
Thanks a lot!

Created attachment 16249 [details]
X log before 'cat rom > /tmp/rom'

With the latest commit (45fdec79)

Attempted to start X (no echo 1 to either 'enable' or 'rom) -- X fails to start
Attempted to start X (echo 1 > enable; nothing to rom) -- X fails to start
Attempted to start X (echo 1 > enable; echo 1 > rom) -- X fails to start

These three cases produce X logs identical to the one attached with this comment.

Only after executing 'echo 1 > enable; echo 1 > rom; cat rom > /tmp/rom' would X start. The log produced from this procedure is identical to attachment #16229 [details] (X log in Alpha after echo 1 > enable). I guess I didn't realize cat rom > /tmp/rom changed the behavior or else I would have named the log differently.

Created attachment 16910 [details]
X log from HD2400 black screen case

Created attachment 16911 [details]
X log from HD2400 working case

I am also seeing this bug.

Machine specs:
Compaq Alpha XP1000 (667MHz EV67 cpu)
Powercolor HD 2400 Pro PCI (RV610)

I have patched rhd_id.c to contain a line specifying the monitor connection details for the powercolor graphics card onto the git commit just before the DRI stuff was checked in (possibly at commit 4f3d627795ab).  

Starting X leads to a black screen.  The monitor reports that is receiving a signal of the expected resolution and sync frequencies.  This occurs for both the vga and dvi outputs.

Shutting down X leads to a complete system lockup.  No response with ping.

Applying the following before starting X (as suggested in comment 17):

/sys/bus/pci/devices/0000:01:00.0 # echo 1 > enable
/sys/bus/pci/devices/0000:01:00.0 # echo 1 > rom
/sys/bus/pci/devices/0000:01:00.0 # cat rom

works!  X starts up with proper screen output.  When I close down X (or attempt to shift to one of the text consoles with ctrl-alt-<num> the system locks up.  Again no reponse with ping.

I attach two log files.  One from the example of the black screen and one when X starts up with output.

(Attachments appear to have gone through as previous messages - it is not obvious from bug logging system that this would occur.)

I've got plenty of Alphas around (latest one EV6) and I would be tempted to reproduce this bug myself alone I don't have a single RadeonHD PCI card.
To debug the hang I need to rely on the help of a user with such a system. The best bet would be to look where RHDSaveScreen (last function listed the log file) gets called (inside the server) (look for pScreen->SaveScreen()) and set gdb breakpoints following this instruction until the source of the lockup is hit.

Actually there was a hang fix relating to MC reprogramming, recently. This however didn't involve server shutdown.
Also some asserts have been added to 'blow the whistle' if certain conditions aren't met.
@Michael: would you please give the latest driver from GIT a try to see if it makes a difference?

I was holding off doing anymore testing until Linux kernel bug 10893 (http://bugzilla.kernel.org/show_bug.cgi?id=10893) is resolved.  It has been suggested that the resolution of that kernel bug will resolve the Alpha PLL access problem.

But as you suggest otherwise, I'll try to compile the new driver.  It'll take a bit more work to do since I now have to get all the DRI/Mesa dependencies compiled first, which I didn't have to do with the older version I previously tested. Quite likely will be a few days before I can report back as I don't have any free evenings this week.

I may also have to learn how to attach gdb to the Xserver to do the other testing you suggest.  I'll wait to see if the newest git version resolves the crash issue before attempting that though.

Michael: I've just submitted a patch which fixes the --disable-dri option.
Now you should be able to do: configure --disable-dri and build without DRI bits installed.

Created attachment 17991 [details]
X log exhibiting failed assertion at RHDMCIdle

Compiling the radeonhd driver proved relatively easy once I realised that I
didn't need to recompile the whole X server. I used the mesa packages from
Debian experimental since they seemed to be relatively recent.  Running this on
the Compaq XP1000 (ev67 CPU) the X server refuses to complete startup with a
failed assertion that RHDMCIdle ultimately failed.  X log attached.

I also have an ev56 miata Alpha so I also tried the Radeon HD2400 in that with
the radeonhd driver.  The SRM couldn't initialise the card, so I had to drive it
through the serial console, and eventually managed to get the kernel to boot.  X
came up fine, and I had gdm running, but with the colours all mucked up.  For
example, the Debian login splash screen consists of varying intensity (and
saturation) blues, but these appeared in psychedelic rainbow colours.  Shutting
down X didn't cause any problems on this computer.  I didn't think to get an X log at the time.

Michael, thanks for the test!
Cool, so it seems to be running. Since the SRM console didn't get the card POSTed it had to be POSTed by InitAsic. This doesn't set a mode so it's possible that the LUT (for gamma) is not set correctly. This this problem could be similar to the one in bug #16280.
I've looked for an occurrence of rhdRRCrtcGammaSet() in the log file. I didn't find any.
Please try running 'xgamma -gamma 1.0' and see if this will set sane colors.

To clarify:  I tested the HD2400 card on two different Alpha systems on which it ran on only one (though with a bad colour problem).

On the ev56 system, where the SRM console couldn't POST the card, X comes up but the colours are all mucked up.  I've tried running 'xgamma -gamma 1.0' as you suggest but it doesn't fix the problem.

On the ev67 system, where the SRM console does POST the card, X bombs out on startup due to a failed assertion in the radeonhd driver.  The log file for this case is in comment 27.  It is particularly this system that I would really like to run the card, but currently can't because of the failed assertion.

This bug is now filed in the correct place. :)

It looks to me like this bug is yet another symptom of kernel bug 10893 (http://bugzilla.kernel.org/show_bug.cgi?id=10893)

I feel like if that damn kernel bug was ever fixed, this bug along with bug 16549 and bug 17801 would be instantly fixed. (It looks like bug 4508 is probably already fixed, just hasn't been marked.)

Egbert, and other developers, could any of you spare a bit of time and see if it's possible to fix kernel bug 10893? It would certainly clear out the alpha bugs in this bugzilla + allow people to do useful things with their alphas.

Matt,

I see you have changed this bug to Resolved Wontfix.  Actually I think it is fixed and working since about March or April - I just got it fixed but about the same time got my system disc into a mucked up state, had to reinstall, and I meant to give it one final test, but because the Xserver got broken on Alpha I haven't been able to do the test.  Now that the Xserver is working on Alpha I meant to give this one a final test before closing it.  I'll perform the test in the next couple or so days and change the bug to Fixed if indeed it is.  Presumably it is not working for you if you changed it to Wontfix?

Michael.

I closed it for a couple reasons:

1. I stopped getting feedback
2. I really don't see any reason to use RadeonHD

If you want to test with radeonhd, cool. I'll change the status if you want.

Confirmed working with an HD2400 on a DEC PWS600au.  PLL and reference clock is read and other issues mentioned (such as mixed up colours) are fixed on Alpha architecture.  Changing status to fixed.