On Tue, 03 Mar 2015 23:33:23 +0100 Jean-Sébastien Pédron <dumbbell_at_FreeBSD.org> wrote: > > 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: http://opal.com/jr/freebsd/panic/r279508M/dmesg.txt http://opal.com/jr/freebsd/panic/r279508M/core.txt.7 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. -jr
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:56 UTC