Bug 205527 - radeonKMS silent reboot @r292637
Summary: radeonKMS silent reboot @r292637
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2015-12-23 01:31 UTC by Larry Rosenman
Modified: 2019-02-05 18:27 UTC (History)
1 user (show)

See Also:


Attachments
dmesg (16.08 KB, text/plain)
2015-12-23 01:31 UTC, Larry Rosenman
no flags Details
loader.conf (923 bytes, text/plain)
2015-12-23 01:31 UTC, Larry Rosenman
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Larry Rosenman freebsd_committer freebsd_triage 2015-12-23 01:31:05 UTC
Created attachment 164522 [details]
dmesg

when the kernel mode switches to radeonkms, I get a reboot.  If I comment out radeonkms, and the FW, we stay up.  If I kldload the fw and the radeonkms module, we get a failed to initialize cp(-22). message, but we switch. 

dmesg attached.

loader.conf attached (with the 2 radeon lines commented out. 

This had been working just fine....
Comment 1 Larry Rosenman freebsd_committer freebsd_triage 2015-12-23 01:31:33 UTC
Created attachment 164523 [details]
loader.conf
Comment 2 Larry Rosenman freebsd_committer freebsd_triage 2015-12-23 01:43:25 UTC
I had been running @r292000 before this.
Comment 3 Jean-Sébastien Pédron freebsd_committer freebsd_triage 2015-12-23 15:56:45 UTC
Hi Larry!

I'm running r292448 and don't see this behavior. Next week, I will update to a more recent kernel to try to reproduce the problem.

On your side, could you please try to isolte which commit causes the regression?
Comment 4 Larry Rosenman freebsd_committer freebsd_triage 2015-12-23 16:01:31 UTC
I'll try tonight when I am home again.
Comment 5 Jean-Sébastien Pédron freebsd_committer freebsd_triage 2015-12-23 23:47:30 UTC
I updated to r292665 tonight and everything is working fine.
Comment 6 Larry Rosenman freebsd_committer freebsd_triage 2015-12-23 23:58:44 UTC
Hrm.  Updated to latest (292675) and am compiling -- will check back.

Assuming it still fails, what can I get to help here?
Comment 7 Jean-Sébastien Pédron freebsd_committer freebsd_triage 2015-12-24 00:06:38 UTC
Can you lookup the first commit that fails?

You could use "git bisect" for that purpose, it helps a lot.
Comment 8 Larry Rosenman freebsd_committer freebsd_triage 2015-12-24 00:33:21 UTC
Still Failing for me.  I do NOT have a git checkout either.  

I also don't see anything in a quick search of this months commits for drm or kms. 

Ideas??
Comment 9 Jean-Sébastien Pédron freebsd_committer freebsd_triage 2015-12-24 08:06:47 UTC
You could lookup the failing commit by dichotomy with Subversion too; this is what "git bisect" does.

The problem is in the kernel, so you can prepare the initial list of commits to test using "svn log" in sys/ to get all the revisions between r292000 and r292637 (the commits known to be good and bad).

Now, test the commit in the middle of this list, let's say r292xxx. If it fails, test the next commit in the middle between r292000 and r292xxx, otherwise, test the commit in the middle between r292xxx and 292637, and so on.

Between those two revisions, there were two changes to TTM, the memory manager for Radeon (r292373 and r292469). I don't know if they could be the culprit. If you want to test them first, try those and the revisions before.

I'm not sure what to suggest otherwise.
Comment 10 Larry Rosenman freebsd_committer freebsd_triage 2015-12-24 15:23:50 UTC
we're heading out of town for Christmas, I'll try to do this when we get back on Saturday.
Comment 11 Jean-Sébastien Pédron freebsd_committer freebsd_triage 2015-12-24 15:27:14 UTC
Thank you very much! Merry Christmas!
Comment 12 Larry Rosenman freebsd_committer freebsd_triage 2019-02-05 18:27:13 UTC
the graphics stack has changed significantly, and this is 3 years old.  Closing as OBE.