On Tue, 03 Mar 2015 23:33:23 +0100 Jean-Sébastien Pédron <dumbb...@freebsd.org> 
> Hi!
> Here is a new patch to based on HEAD r279508:
>     https://people.freebsd.org/~dumbbell/graphics/drm-update-38.i.patch
> You can apply it to a Subversion checkout using the following command:
>     svn patch drm-update-38.i.patch
> There are few changes:
>     o  The panic reported by J.R. Oldroyd is fixed, but not the CP init
>        problem.
>     o  A lock assert was added, suggested by Konstantin Belousov

Tested as requested: svn update to r279508 and applied the 38i patch.
Mixed results.

The first boot, done as a warm "reboot" command while running 10-stable
shows that the CP init failed again and I am back to the mtx_lock panic.

I then let it auto-reboot back into 10-stable (this is an old
10-stable at the time of r271969 10.1-BETA2 but it is one in which the
ring CP init still works).  That shows it boots fine and ring CP inits
OK - even as a warm reboot after the previous failure.

I then thought to try a power-off cold reboot into r279508.  This works,
both ring CP inits OK and no mtx_lock panic.  In fact, I am using it
now to send this report.

So, perhaps the previous fix for the mtx_lock panic wasn't right, but
just seemed to work because I happened to cold-boot those times.

The pattern that's emerging here is that older (mid-2014) kernels
boot and init fine, warm or cold.  The CP init problem started
somewhere mid-2014.  The mtx_lock panic is new, so I am guessing
related to the drm2-38 update.  BOTH CP init and mtx_lock problems
go away when cold booting.

I've uploaded info here:


The dmesg shows the three boot sequences with annotations to make it
clear which is which.

Above is system with ATI Radeon RS690 X1270 IGP, RS690.

BTW, I now also have the ring CP init failure on a second system
that was just updated to 10.1-RELEASE-p6.  It has ATI Radeon HD 4200
which is RS780 and it also shows the ring init failure at CAFEDEAD
but in r600_ting_test().  Unfortunately, this system is a production
one so I can't easily play with it.  Note, no mtx_lock panic here.
Fortunately, the graphics not working isn't a problem on this system.


Attachment: pgpZ9qNOg7N2y.pgp
Description: OpenPGP digital signature

Reply via email to