Bug 30620

Summary:

[RADEON:KMS:RS100:MODESET] no display on VGA

Product:

DRI

Reporter:

Rafał Miłecki <zajec5>

Component:

DRM/Radeon

Assignee:

Default DRI bug account <dri-devel>

Status:

RESOLVED MOVED

QA Contact:

Severity:

normal

Priority:

medium

CC:

auxsvr

Version:

unspecified

Hardware:

Other

OS:

All

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
dmesg for KMS	none
[UMS] Xorg.0.log	none
regs dump when using KMS	none
regs dump when using radeonfb	none
diff -u broken.regs working.regs	none
disable alt timing for CRT	none
diff -u regs-fail regs-working	none

Description Rafał Miłecki 2010-10-05 04:41:29 UTC

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?

Comment 1 Alex Deucher 2010-10-05 08:12:07 UTC

Can you attach the kms dmesg output and the Xorg log?

Comment 2 Alex Deucher 2010-10-05 09:15:37 UTC

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

Comment 3 Rafał Miłecki 2010-10-05 10:24:22 UTC

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

Comment 4 Rafał Miłecki 2010-10-05 10:25:18 UTC

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.

Comment 5 Alex Deucher 2010-10-05 10:42:02 UTC

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/

Comment 6 Rafał Miłecki 2010-10-05 12:29:10 UTC

Created attachment 39189 [details]
regs dump when using KMS

Comment 7 Rafał Miłecki 2010-10-05 12:29:37 UTC

Created attachment 39190 [details]
regs dump when using radeonfb

Comment 8 Rafał Miłecki 2010-10-05 12:31:36 UTC

Created attachment 39192 [details] [review]
diff -u broken.regs working.regs

Comment 9 Alex Deucher 2010-10-05 14:43:25 UTC

Does the following fix kms/ums?
radeontool regset 0x0284 0x00230000

Comment 10 Alex Deucher 2010-10-05 15:10:25 UTC

Created attachment 39197 [details] [review]
disable alt timing for CRT

This kms patch should fix the issue I think.

Comment 11 Rafał Miłecki 2010-10-16 00:58:35 UTC

(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? :|

Comment 12 auxsvr 2012-10-12 06:20:23 UTC

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).

Comment 13 Martin Peres 2019-11-19 08:15:56 UTC

-- 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.