[Call for testers] DRM device-independent code update to Linux 3.8 (take #2)
fbsd at opal.com
Wed Mar 4 16:28:33 UTC 2015
On Tue, 03 Mar 2015 23:33:23 +0100 Jean-Sébastien Pédron <dumbbell at FreeBSD.org> wrote:
> Here is a new patch to based on HEAD r279508:
> 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
> o A lock assert was added, suggested by Konstantin Belousov
Tested as requested: svn update to r279508 and applied the 38i patch.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 181 bytes
Desc: OpenPGP digital signature
More information about the freebsd-current