Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 Mar 2015 17:28:02 +0100
From:      "J.R. Oldroyd" <fbsd@opal.com>
To:        =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= <dumbbell@FreeBSD.org>
Cc:        Hans Petter Selasky <hps@selasky.org>, freebsd-x11@FreeBSD.org, freebsd-current@FreeBSD.org, Ed Maste <emaste@freebsd.org>
Subject:   Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)
Message-ID:  <20150304172802.0b285585@shibato>
In-Reply-To: <54F636B3.90701@FreeBSD.org>
References:  <54F636B3.90701@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/gieHqjGF_8F4qJdiTq5hhuf
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, 03 Mar 2015 23:33:23 +0100 Jean-S=C3=A9bastien P=C3=A9dron <dumbbel=
l@FreeBSD.org> wrote:
>
> Hi!
>=20
> Here is a new patch to based on HEAD r279508:
>     https://people.freebsd.org/~dumbbell/graphics/drm-update-38.i.patch
>=20
> You can apply it to a Subversion checkout using the following command:
>     svn patch drm-update-38.i.patch
>=20
> 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
>=20

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

--Sig_/gieHqjGF_8F4qJdiTq5hhuf
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlT3MpoACgkQls33urr0k4m5/wCfQyQVzh4EDNupOpX1D5/CRWtN
DnwAnR72NiQ2VMElT6LQhHUtAOMW1S2N
=MWKE
-----END PGP SIGNATURE-----

--Sig_/gieHqjGF_8F4qJdiTq5hhuf--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150304172802.0b285585>