On Sat, Nov 14, 2009 at 9:46 PM, Dave Witbrodt
Matthias Hopf wrote:
On Nov 11, 09 13:59:40 -0500, Dave Witbrodt wrote:
Uh-oh. The voltage levels look really broken. Can you post a BIOS here (you can get it with rhd_conntest -d [PCI-Id]) so I can verify what's happening here? Maybe also retry with git master, Egbert fixed an out-of-bounds access.
I've attached the requested BIOS. If, for some reason, the attachment doesn't work or gets blocked somewhere just let me know, and we can arrange another transfer method.
Worked out fine. The known good configurations table has a number of strange voltage entries (0xff01). I didn't validate the table entries yet, because I never saw wrong entries. Egbert fixed the possibility of broken table offsets (which he encountered), I just added the entry validation code to latest git, so please retest.
newly freed up hard drives. Just in time for me to become another statistic in the H1N1 pandemic!
:-] Take care, take your time. This is nothing pressing.
OK, I had to work on Thursday, but had Friday and Saturday off. Feeling much better now after the illness, I worked pretty hard on updating Mesa. I made it very hard on myself by requiring that I install everything using Debian's APT instead of raw 'make; make install' invocations, but it pays off when updates appear (or when a package begins behaving badly).
The Debian build scripts for Mesa-7.6 produce about 5 packages I need, and 14 that I don't. I studied what Debian was doing to build all of that stuff for a long time, hoping to only enable building the few packages I needed. I finally figured out how it works, only to realize that it would have been WAY easier from the beginning just to let all 19 build in the first place, instead of blowing a whole Friday reinventing the wheel. (It wasn't a total waste, though: I now know a hell of a lot more about building DEBs than before!)
In the end, I downloaded Mesa-7.7-devel-20091105, copied the 'debian' directory from Debian Mesa-7.6 sources, removed some of the patches that would not apply (and are not relevant to my hardware), and tweaked the 'debian/rules' script so that r600 support was added (and lots of other stuff was dropped). Had a few glitches forcing me to restart the build (luckily not from the beginning), and some new files from 7.7 ended up left out because I used package information from 7.6 to do the building... but I ended up with my DEBs!
BTW, I was forced to build DEBs of 'libdrm' after all: the Mesa-7.7 'configure' script reported a dependency on a newer 'libdrm' (2.4.15) than Debian has right now.
Also, as requested, I rebuilt 'radeonhd' using the git HEAD (and building DEBs, naturally), so we could see if the voltage tables looked better after Egbert's recent changes. But, most of all, I just wanted to see some working 2D/3D acceleration for a change!
Results? Everything looks good! I'm attaching a full Xorg.0.log, but here are some highlights:
[...] (==) RADEONHD(0): Depth 24, (--) framebuffer bpp 32 (**) RADEONHD(0): Selected EXA 2D acceleration. (II) RADEONHD(0): Card not in database: 0x9442:0x1458:0x21C7; using generic modesetting. [...] (II) RADEONHD(0): The detected amount of videoram exceeds the PCI BAR aperture. (II) RADEONHD(0): Mapping only 262144kB of the total 1048576kB, remaining memory is reserved for GPU. (--) RADEONHD(0): VideoRAM: 262144 kByte [...] (WW) RADEONHD(0): rhdAtomAllocateFbScratch: FW FB scratch area not located at the end of VRAM. Scratch End: 0x104fec VRAM End: 0x10000000 (II) RADEONHD(0): Cannot get VRAM scratch space. Allocating in main memory instead [...] (II) RADEONHD(0): Found libdri 5.4.0. drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (II) RADEONHD(0): Found libdrm 1.3.0. (II) RADEONHD(0): Found radeon drm 1.31.0. [...] (II) RADEONHD(0): Current Chip Voltage: 1123 (II) RADEONHD(0): Power Management: used engine clock / memory clock / core (VDDC) voltage (0: ignore) (II) RADEONHD(0): Power Management: Raw Ranges (II) RADEONHD(0): Minimum 250000 kHz / 250000 kHz / 0.892 V (II) RADEONHD(0): Maximum 768000 kHz / 1152000 kHz / 1.158 V (II) RADEONHD(0): Default 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): PowerPlayInfo Revision 0401 (II) RADEONHD(0): Power Management: Validated Ranges (II) RADEONHD(0): Minimum 250000 kHz / 250000 kHz / 0.892 V (II) RADEONHD(0): Maximum 768000 kHz / 1152000 kHz / 1.158 V (II) RADEONHD(0): Default 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): Power Management: Known Good Configurations (II) RADEONHD(0): 1 625000 kHz / 993000 kHz / 0.000 V (II) RADEONHD(0): 2 500000 kHz / 960000 kHz / 1.046 V (II) RADEONHD(0): 3 500000 kHz / 960000 kHz / 1.046 V (II) RADEONHD(0): 4 640000 kHz / 960000 kHz / 0.000 V (II) RADEONHD(0): 5 640000 kHz / 960000 kHz / 0.000 V (II) RADEONHD(0): 6 640000 kHz / 960000 kHz / 0.000 V (II) RADEONHD(0): 7 640000 kHz / 960000 kHz / 0.000 V (II) RADEONHD(0): 8 500000 kHz / 960000 kHz / 1.084 V (II) RADEONHD(0): 9 500000 kHz / 960000 kHz / 1.084 V (II) RADEONHD(0): Power Management: Final Levels (II) RADEONHD(0): Off 250000 kHz / 250000 kHz / 0.892 V (II) RADEONHD(0): Idle 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): Slow2D 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): Fast2D 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): Slow3D 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): Fast3D 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): Max3D 768000 kHz / 1152000 kHz / 1.158 V (II) RADEONHD(0): User 640000 kHz / 960000 kHz / 1.123 V [...] (II) RADEONHD(0): Using 3840x1920 Framebuffer with 3840 pitch (II) RADEONHD(0): FB: Allocated ScanoutBuffer at offset 0x00008000 (size = 0x01C20000) (**) RADEONHD(0): Display dimensions: (518, 324) mm (**) RADEONHD(0): DPI set to (188, 150) [...] (II) [drm] DRM interface version 1.3 (II) [drm] DRM open master succeeded. (II) RADEONHD(0): [drm] Using the DRM lock SAREA also for drawables. (II) RADEONHD(0): [drm] framebuffer handle = 0xd0000000 (II) RADEONHD(0): [drm] added 1 reserved context for kernel (II) RADEONHD(0): X context handle = 0x1 (II) RADEONHD(0): [drm] installed DRM signal handler (II) RADEONHD(0): [pci] 16384 kB allocated with handle 0x1142e900 [...] (II) RADEONHD(0): Direct rendering enabled (II) RADEONHD(0): Using DRM Command Processor (indirect) for acceleration. (II) EXA(0): Offscreen pixmap area of 26836992 bytes (II) EXA(0): Driver registered support for the following operations: (II) Solid (II) Copy (II) Composite (RENDER acceleration) (II) UploadToScreen (II) DownloadFromScreen [...] (II) AIGLX: Screen 0 is not DRI2 capable drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: drmOpenMinor returns 9 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (II) AIGLX: enabled GLX_MESA_copy_sub_buffer (II) AIGLX: enabled GLX_SGI_make_current_read (II) AIGLX: enabled GLX_texture_from_pixmap with driver support (II) AIGLX: Loaded and initialized /usr/lib/dri/r600_dri.so (II) GLX: Initialized DRI GL provider for screen 0 [...]
I see where the bogus DPI calculation is coming from: radeonhd is using the virtual buffer size (3840x1920) instead of the screen size (1920x1200).
Apart from corruption on the XDM login window (which occurs with and without acceleration), I have had no bugs or negative issues yet. I haven't tested it much -- windows can be slid with the mouse very rapidly without leaving long trails; DOSBox plays my favorite old game without sound glitches (graphics seem quicker, but haven't played with settings yet); prboom doesn't bog down so much -- but I'm already liking it. The visual aspects of my desktop machine haven't been this responsive since the proprietary NVidia driver went away (with the dead card this past summer).
Just now, I tried 'glxgears'. Hmm... won't run:
$ glxgears IRQ's not enabled, falling back to busy waits: 2 0 drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info.
$ dmesg [...] [ 8128.797480] [drm:r600_cs_packet_next_reloc_nomm] *ERROR* No packet3 for relocation for packet at 45. [ 8128.797490] [drm:r600_packet3_check] *ERROR* bad SET_CONTEXT_REG 0x28014 [ 8128.797496] [drm:r600_cs_legacy] *ERROR* Invalid command stream !
Update mesa. The proper fix is in the 7.6 branch and master. That register isn't used yet in mesa and requires a reloc when it eventually will be used. Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org