I've bug report from user with old notebook with ATI 320M (RS100). She installed openSUSE 11.3 which comes with 2.6.34 and can not get driver display anything. The important part is that notebook's PANEL is broken and she uses VGA for external monitor. There are two KMS cases I got tested by her: 1) "vga=0x31a" ─ black VGA screen right after booting start 2) "" (no vga) ─ black VGA screen right after booting start So I asked to experiment with UMS a little: 3) "vga=0x31a radeon.modeset=0 3" ─ radeonfb loads, VGA works! 4) "vga=0x31a radeon.modeset=0" ─ radeonfb works, black VGA screen on X start Without radeonfb: 5) "radeon.modeset=0 3" ─ pure console works on VGA, no radeonfb 6) "radeon.modeset=0" ─ pure console works on VGA, black VGA on X start My conclusions: 1) KMS can not initialize VGA 2) UMS can not initialize VGA 3) radeonfb *can* initialize VGA 4) There is no conflict with radeonfb, as dropping "vga=0x31a" does not help What else can I ask for to make it debuggable? I thought of Xorg.0.log but it may be hard to get for her as she had to mount some USB storage in console and copy file to it. Taking "dmesg | grep drm" could be easier. Would it be useful?
Can you attach the kms dmesg output and the Xorg log?
Also, please attach a copy of your video bios. To get a copy, do the following as root: cd /sys/bus/pci/devices/<pci bus id> echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom
Created attachment 39185 [details] dmesg for KMS I didn't want to explain how to blacklist module, test, then remove it so I proposed something different for Westa: 1) Booting with radeon.modeset=0 2) rmmod radeon && modprobe radeon modeset=1
Created attachment 39186 [details] [UMS] Xorg.0.log Xorg.0.log form *UMS* as problem seems to be shared between KMS and UMS. This may give some hint on fixing it.
Everything looks correct. Can you dump the regs using radeontool with kms and with radeonfb? As root: with radeonfb: radeontool regmatch '*' > working.regs with kms: radeontool regmatch '*' > broken.regs You can get radeontool here: http://cgit.freedesktop.org/~airlied/radeontool/
Created attachment 39189 [details] regs dump when using KMS
Created attachment 39190 [details] regs dump when using radeonfb
Created attachment 39192 [details] [review] diff -u broken.regs working.regs
Does the following fix kms/ums? radeontool regset 0x0284 0x00230000
Created attachment 39197 [details] [review] disable alt timing for CRT This kms patch should fix the issue I think.
(In reply to comment #9) > Does the following fix kms/ums? > radeontool regset 0x0284 0x00230000 I got false positive report about this :( What I asked for was executing: 1) Boot without vga=... and with radeon.modeset=0 3 2) Executing rmmod radeon 3) Executing: modprobe radeon modeset=1; sleep 5s; radeontool regset 0x0284 0x00230000 I got response monitor gone black and then came on again. But I now I know it has happened after 1s, not 5s! It seems loading radeon this one time didn't break VGA output. Maybe some register survived reboot? Maybe regs dumps are not clean actually, maybe I should ask to grab them from cold boot? :|
Created attachment 68470 [details] diff -u regs-fail regs-working I just tried installing openSUSE 12.1 on an old compaq presario 900 with a broken TFT panel and have exactly the same problem. Setting register 0x0284 does not work, and shortly after reloading radeon with modeset=1 the system hangs. Is there anything else to try? The attached diff compares the register values when modeset=0 (working) with them when modeset=1 (fail).
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/160.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.