Opened 10 years ago

Closed 5 years ago

Last modified 4 years ago

#10167 closed bug (invalid)

Radeon HD 6950 crashes on booting

Reported by: Guest One Owned by: kallisti5
Priority: normal Milestone:
Component: Drivers/Graphics/radeon_hd Version: R1/Development
Keywords: boot-failure Cc: stippi
Blocked By: Blocking:
Platform: All

Description

device Display controller (VGA compatible controller, VGA controller) [3|0|0]

vendor 1002: Advanced Micro Devices, Inc. [AMD/ATI] device 6719: Cayman PRO [Radeon HD 6950]

hrev46308

All icons on bootscreen lights up, and KDL appears on next second. With "safe vido mode" system boots fine. Problem in video driver probably.

Attachments (6)

syslog (351.4 KB ) - added by Guest One 10 years ago.
syslog
IMG_3141.JPG (1.6 MB ) - added by Guest One 10 years ago.
KDL bt
hrev47486-kdl-1-vert.jpg (826.0 KB ) - added by Guest One 10 years ago.
rev47486
hrev47486-syslog (77.7 KB ) - added by Guest One 10 years ago.
hrev47629-syslog (304.1 KB ) - added by Guest One 10 years ago.
app_server-444-debug-06-08-2014-17-24-18.report (11.5 KB ) - added by Guest One 10 years ago.

Change History (28)

by Guest One, 10 years ago

Attachment: syslog added

syslog

by Guest One, 10 years ago

Attachment: IMG_3141.JPG added

KDL bt

comment:1 by kallisti5, 10 years ago

odd, it looks like the driver is loaded before the base haiku package is loaded. I know if the video driver attempts to load and the accelerant fails to load for some reason, an app server crash may occur.

This may be PM related... not sure.

2614	KERN: radeon_hd: init_hardware
2615	KERN: package_daemon [14608192:   449] active package: "mesa-9.1.1-1-x86.hpkg"
2616	KERN: radeon_hd: init_driver
2617	KERN: package_daemon [14616853:   449] active package: "webpositive-r1~alpha4_pm_hrev46308-1-x86.hpkg"
2618	KERN: package_daemon [14627433:   449] radeon_hd: init_driver: GPU(0) Radeon HD 6950, revision = 0x0
2619	KERN: active package: "zlib_devel-1.2.8-4-x86.hpkg"
2620	KERN: ahci: ahci_supports_device
2621	KERN: package_daemon [14639820:   449] radeon_hd: publish_devices
2622	KERN: active package: "perl-5.10.1-6-x86.hpkg"
2623	KERN: radeon_hd: find_device
2624	KERN: package_daemon [14651174:   449] loaded driver /boot/system/add-ons/kernel/drivers/dev/graphics/radeon_hd
2625	KERN: active package: "sqlite-3.7.13-4-x86.hpkg"
2626	KERN: package_daemon [14666347:   449] active package: "haiku-r1~alpha4_pm_hrev46308-1-x86.hpkg"
2627	KERN: package_daemon [14674320:   449] active package: "glu_x86_gcc2_devel-9.0.0-2-x86.hpkg"
2628	KERN: package_daemon [14681940:   449] active package: "libogg-1.3.0-2-x86.hpkg"
2629	KERN: package_daemon [14688532:   449] active package: "libpng_x86_gcc2_devel-1.5.12-3-x86.hpkg"
2630	KERN: package_daemon [14696505:   449] active package: "libvpx-1.0.0-2-x86.hpkg"
2631	KERN: package_daemon [14703091:   449] active package: "curl_x86_gcc2_devel-7.26.0-5-x86.hpkg"
2632	KERN: package_daemon [14710895:   449] active package: "libtool-2.4-8-x86.hpkg"
2633	KERN: package_daemon [14717507:   449] Volume::InitialVerify((nil), (nil))
2634	KERN: Radeon - init_hardware: Version: 5.1.6.0

comment:2 by bonefish, 10 years ago

When the package daemon is started (from the Bootscript), it asks packagefs what packages are active and prints respective debug output. The order is of no significance (it's some hash table's iteration order). The packagefs volumes are mounted long before that point (directly after the boot volume is mounted). The timing of the radeon_hd output is mere coincidence, since the app server is started immediately after the package daemon.

comment:3 by Guest One, 10 years ago

The issue is not related to package management. I have the same bug in pre-PM nightly builds.

comment:4 by kallisti5, 10 years ago

odd, the last line from the radeon drivers is...

KERN: radeon_hd: find_device

It looks like it can't jump into the accelerant. As soon as the accelerant is loaded, we should see a trace message (thats missing from your logs http://cgit.haiku-os.org/haiku/tree/src/add-ons/accelerants/radeon_hd/accelerant.cpp#n242)

So the issue you're seeing exists somewhere between the driver publishing the graphic devices and the accelerant taking over... Can't say this is a common issue as no-other cards see it... it must be device dependent somehow.

Last edited 10 years ago by kallisti5 (previous) (diff)

in reply to:  4 ; comment:5 by Guest One, 10 years ago

Replying to kallisti5:

It looks like it can't jump into the accelerant. As soon as the accelerant is loaded, we should see a trace message (thats missing from your logs http://cgit.haiku-os.org/haiku/tree/src/add-ons/accelerants/radeon_hd/accelerant.cpp#n242)

How exactly can I get this message?

in reply to:  5 comment:6 by kallisti5, 10 years ago

Replying to Guest One:

How exactly can I get this message?

Thats not the point, the message should already be showing up. Not sure of the cause at this time.

comment:7 by luroh, 10 years ago

Blocking: 7665 added

comment:8 by kallisti5, 10 years ago

Stuff has changed since this was reported. Is this still an issue for you?

comment:9 by Guest One, 10 years ago

Yes, I still can't boot and I'm using safe video mode. Give me a day and I'll provide new logs from latest nightly.

by Guest One, 10 years ago

Attachment: hrev47486-kdl-1-vert.jpg added

rev47486

by Guest One, 10 years ago

Attachment: hrev47486-syslog added

by Guest One, 10 years ago

Attachment: hrev47629-syslog added

comment:10 by Guest One, 10 years ago

No canges for me at hrev47486 and hrev47629. I've got the same symptoms in KDL.

comment:11 by anevilyak, 10 years ago

That's actually an app_server crash rather than a KDL. If this is repeatable, would you be able to type save-report at the prompt? That will save a crash report to your hard disk which could be attached to this ticket, and might yield some more interesting information.

in reply to:  11 comment:12 by Guest One, 10 years ago

Replying to anevilyak:

That's actually an app_server crash rather than a KDL. If this is repeatable, would you be able to type save-report at the prompt? That will save a crash report to your hard disk which could be attached to this ticket, and might yield some more interesting information.

Report uploaded. This is repeatable. I always have this issue if I do not use failsafe video mode.

comment:13 by anevilyak, 10 years ago

Interestingly, it does appear that the app_server at least partly attempted to load the radeon_hd accelerant, since some of its areas/semaphores are present, though it was also unloaded again since it's no longer in the app_server's image list. Not sure what to make of it beyond that though, will have to leave further diagnosis to kallisti5.

comment:14 by pulkomandy, 10 years ago

It looks like the screen->Initialize() call in _AddHWInterface returned an error, and the screen is deleted because of that. Could this lead to the accelerant being unloaded while it's still somewhat in use?

in reply to:  14 comment:15 by anevilyak, 10 years ago

Cc: stippi added
Summary: Radeon HD 6950 carshes on bootingRadeon HD 6950 crashes on booting

Replying to pulkomandy:

It looks like the screen->Initialize() call in _AddHWInterface returned an error, and the screen is deleted because of that. Could this lead to the accelerant being unloaded while it's still somewhat in use?

That would at least explain the backtrace. If the app_server still has an accelerant_hooks structure with function pointers into the accelerant, and attempts to call one after the latter has already been unloaded, that would certainly lead to a crash like we're seeing. That's a separate question from why the accelerant fails to initialize correctly though, and probably deserves its own ticket. In any case, CCing stippi in case he has any insight into the app_server part.

comment:16 by kallisti5, 10 years ago

We've always had issues if an accelerant tries to bail out. radeon_hd.accelerant should make all the needed deconstruction calls, however it's always crashed for me if I try to back it out at boot.

In theory, if radeon_hd decides it won't work with the card it should be able to unload and the app_serer fall back to VESA. I don't think i've ever seen that work correctly. It could be just the driver, but I don't think any other accelerants successfully fail either.

comment:17 by anevilyak, 10 years ago

It'd be interesting to know why it fails though, since I'm assuming it wouldn't have come far enough to try to map AtomBIOS and such if the kernel driver hadn't picked up what it thought was a supported device, no?

comment:18 by kallisti5, 8 years ago

I haven't seen radeon_hd crash for quite some time. Is this still an issue?

comment:19 by waddlesplash, 6 years ago

Keywords: boot-failure added; HD6950 removed

comment:20 by waddlesplash, 6 years ago

Blocking: 7665 removed

comment:21 by waddlesplash, 5 years ago

Resolution: invalid
Status: newclosed

No reply in 2 years.

comment:22 by nielx, 4 years ago

Milestone: R1

Remove milestone for tickets with status = closed and resolution != fixed

Note: See TracTickets for help on using tickets.