Ati driver isues on Asus 1215b

[lxstoian]

I have tested hrev42942 on this machine. It has an AMD C-50 apu. It seems that the correct resolution is loaded but the image is highly disrupted. I will provide a screenshot. If any extra data is required I'll be glad to provide it.

[lxstoian]

screenshot

[kallisti5]

Definitely looks like a pixel clock issue.

Could we get the system logs from the boot attempt? You may be able to press and hold ctl+alt+delete for 4 seconds once the system loads to force a clean shutdown / reboot which will ensure the syslogs (/common/var/log/syslog) are written to your boot disk. (which I hope is a USB stick and not a CD)

[lxstoian]

I do use an usb stick to boot. But I have no other Haiku machine ( my main desktop simply wont boot Haiku no matter what I try , have reported a bug on it ) to open the BFS file system on and get the files.

[lxstoian]

Haiku is now booting every time on this machine but I get the same screen error even with all the improvements made to the ati driver. Could this have anything to do with the 1366x768 screen resolution ? I have another device with basically the same configuration ( c-60 instead of c-50 ) and on this devices everything runs great.

[kallisti5]

We still really need to get the system logs which would help greatly in this case... without system logs we're just guessing.

[lxstoian]

Any ideas how to get them. I seem to be unable to get to the desktop even in safe - video mode. Maybe if I do on screen debug during the boot process. Anything you can use from there ? I'll try again now to boot in vesa mode. Maybe some resolution will work. If I do get to the desktop what output would you need ?

[lxstoian]

Ok I got to the desktop after playing around with the safe mode settings. What output do you need?

[lxstoian]

This is the syslog from booting with the ati driver ( not safe mode )

[lxstoian]

If you need anything else let me know.

[kallisti5]

hmm.. the syslog provided only shows:

KERN: radeon_hd: init_hardware
KERN: radeon_hd: init_driver
KERN: radeon_hd: init_driver: GPU(0) Radeon HD 6250, revision = 0x0
KERN: radeon_hd: publish_devices
KERN: radeon_hd: find_device
KERN: loaded driver /boot/system/add-ons/kernel/drivers/dev/graphics/radeon_hd

I think that means we are catching the safemode boot there (as we load and use vesa right after that log message)

Can you find any more logs? The ones I am looking for will have *tons* of output containing radeon_hd.

I checked the driver and we are aware of your cards PCIID (and it is marker properly as an APU)

I don't have any direct access to any Radeon APU devices, so all I've had to go on is what the linux drm driver does.

Thanks!

[lxstoian]

I can only see syslog which is the current boot one and syslog.old. Where could I get more logs ?

[anevilyak]

It isn't the case that syslog is the current boot and syslog.old is the previous. The log is simply rotated once it grows beyond a certain size. It would probably be prudent to attach both, though in your case the log is also flooded with debug output from atheroswifi, so it'd probably be best to delete both of them, boot normally, reboot, then boot again in safe mode. Then attach what's present, be it one file or two.

[lxstoian]

Can I somehow increase the max size of the syslog? I'll do what you said now but I'll also try with disabling networking on boot as to stop the flood from the atheros card. Edit : Seems there is no option on boot to disable networking only.

[anevilyak]

Replying to lxstoian:

Can I somehow increase the max size of the syslog?

In /boot/home/config/settings/kernel/drivers/kernel (create this file if it doesn't already exist, you can add: syslog_max_size 5MB or some other size to adjust that.

Edit : Seems there is no option on boot to disable networking only.

You could simply move the atheroswifi binary out of /system/add-ons/kernel/drivers/bin.

[lxstoian]

Syslog from a first boot normal then second boot safe mode. Wifi still on.

[lxstoian]

I believe this is what you need. It contains a lot of radeon output.

[kallisti5]

Ok, I'm pretty clear on the issue now. This issue is mostly due to me not having hardware to test on.

Some implementations require a special AtomBIOS call to pull LVDS panel information (limits, modelines, etc)

It was a todo, so I just sent back the VESA modeline..

connector_read_edid: LCD panel detected (LVDS), sending VESA EDID!

​http://cgit.haiku-os.org/haiku/tree/src/add-ons/accelerants/radeon_hd/connector.cpp#n127

Interesting bits: (notice the 0 limits)

1633	KERN: radeon_hd: Currently detected connectors=============
1634	KERN: radeon_hd: Connector #0)
1635	KERN: radeon_hd:  + connector:      LVDS Panel
1636	KERN: radeon_hd:  + gpio table id:  0
1637	KERN: radeon_hd:  + gpio hw pin:    0x90
1638	KERN: radeon_hd:  + gpio valid:     true
1639	KERN: radeon_hd:  + encoder:        LVDS
1640	KERN: radeon_hd:    - id:           30
1641	KERN: radeon_hd:    - type:         Internal Kaleidoscope UNIPHY
1642	KERN: radeon_hd:    - enumeration:  1
1643	KERN: radeon_hd:    - attributes:
1644	KERN: radeon_hd:      * no extra attributes
1645	KERN: radeon_hd: Connector #1)
1646	KERN: radeon_hd:  + connector:      HDMI A
1647	KERN: radeon_hd:  + gpio table id:  1
1648	KERN: radeon_hd:  + gpio hw pin:    0x91
1649	KERN: radeon_hd:  + gpio valid:     true
1650	KERN: radeon_hd:  + encoder:        TMDS
1651	KERN: radeon_hd:    - id:           30
1652	KERN: radeon_hd:    - type:         Internal Kaleidoscope UNIPHY
1653	KERN: radeon_hd:    - enumeration:  2
1654	KERN: radeon_hd:    - attributes:
1655	KERN: radeon_hd:      * is HDMI
1656	KERN: radeon_hd: Connector #2)
1657	KERN: radeon_hd:  + connector:      VGA
1658	KERN: radeon_hd:  + gpio table id:  7
1659	KERN: radeon_hd:  + gpio hw pin:    0x97
1660	KERN: radeon_hd:  + gpio valid:     true
1661	KERN: radeon_hd:  + encoder:        TV DAC
1662	KERN: radeon_hd:    - id:           21
1663	KERN: radeon_hd:    - type:         Internal Kaleidoscope DAC1
1664	KERN: radeon_hd:    - enumeration:  1
1665	KERN: radeon_hd:    - attributes:
1666	KERN: radeon_hd:      * no extra attributes
1667	KERN: radeon_hd: ==========================================
1668	KERN: radeon_hd: dp_setup_connectors
1669	KERN: radeon_hd: connector_read_edid: LCD panel detected (LVDS), sending VESA EDID!
1670	KERN: radeon_hd: init_registers, registers for ATI chipset Palm crt #0 loaded
1671	KERN: DDC: ddc2_read: DDC information read failure
1672	KERN: Last message repeated 7 times.
1673	KERN: radeon_hd: Currently detected monitors===============
1674	KERN: radeon_hd: Display #0 active = true
1675	KERN: radeon_hd:  + connector ID:   0
1676	KERN: radeon_hd:  + connector type: LVDS Panel
1677	KERN: radeon_hd:  + encoder type:   LVDS
1678	KERN: radeon_hd:  + limits: Vert Min/Max: 0/0
1679	KERN: radeon_hd:  + limits: Horz Min/Max: 0/0
1680	KERN: radeon_hd: Display #1 active = false
1681	KERN: radeon_hd: ==========================================

[kallisti5]

#8329 opened for more general issue with EDID lvds

[lxstoian]

If you need more testing let me know.

[kallisti5]

hrev43767 should resolve this issue so the native resolution should be set properly.

Can you test as soon as you have access to a hrev43767 or higher build?

[lxstoian]

Tested hrev43768 and there has been no change to the behaviour.

[lxstoian]

Latest syslog. Bug still present.

[kallisti5]

try post hrev43810. hrev43810 fixes a *big* oops.

[lxstoian]

Bug is still present as of hrev43824. Nothing in the behaviour has changed.

[kallisti5]

Could you recollect logs? The previous syslog provided didn't show any radeon_hd info.

[lxstoian]

Sorry for the last syslog. I checked this one and it does contain all the radeon output.

[kallisti5]

Hmm... you're showing the exact same issue as #8331

Could you collect the syslog again post hrev43827? sorry, I know it's a pain :)

[lxstoian]

Will do as soon as it shows up on Haiku Files.

[lxstoian]

Here it is as requested.

[lxstoian]

Bug still alive and well as of hrev43840. Will provide syslog.

[kallisti5]

hrev43900 should solve this.

Please test and confirm.

(yay!)

[lxstoian]

Thanks Kallisti this bug has been crushed.

[kallisti5]

Glad to hear it :)

Closing.