Date: Mon, 6 Mar 2017 20:03:08 -0800 From: Mark Millard <markmi@dsl-only.net> To: Mark Johnston <markj@FreeBSD.org> Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, Justin Hibbits <chmeeedalf@gmail.com>, Nathan Whitehorn <nwhitehorn@freebsd.org> Subject: Re: powerpc64 head -r314687 (PowerMac G5 so-called "Quad Core", clang based): CAM status: Command timeout (always?) Message-ID: <2FA8AC16-8108-4FC7-B1E6-788CBD32F372@dsl-only.net> In-Reply-To: <20170307010204.GA3611@wkstn-mjohnston.west.isilon.com> References: <98A62E0D-C2A0-40B1-AE6D-5810906208AE@dsl-only.net> <4C78F6AA-5ABD-4445-B5EF-4E6778CE36FE@dsl-only.net> <20170306164341.GA83069@wkstn-mjohnston.west.isilon.com> <466C25ED-0A70-4988-9BB1-3B43BD031E5E@dsl-only.net> <E67A6606-941D-4F00-993D-4347C2A1D332@dsl-only.net> <20170307010204.GA3611@wkstn-mjohnston.west.isilon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Mar-6, at 5:02 PM, Mark Johnston <markj at FreeBSD.org> wrote: > On Mon, Mar 06, 2017 at 02:01:06PM -0800, Mark Millard wrote: >> [scsi_pass.c -r314624 is the problem file vintage of the two files.] >>=20 >> On 2017-Mar-6, at 10:36 AM, Mark Millard <markmi at dsl-only.net> = wrote: >>=20 >>> On 2017-Mar-6, at 8:43 AM, Mark Johnston <markj at FreeBSD.org> = wrote: >>>=20 >>>> On Mon, Mar 06, 2017 at 02:05:39AM -0800, Mark Millard wrote: >>>>> On 2017-Mar-6, at 1:37 AM, Mark Millard <markmi at dsl-only.net> = wrote: >>>>> [...] >>>>> Yep: reverting the two files allowed the PowerMac G5 so-called >>>>> "Quad Core" to boot fully and I could log in. >>>>=20 >>>> Do you have a full dmesg of the failed boot? Am I correct in = thinking >>>> that the boot failed before making it to user mode? >>>=20 >>> . . . >>>> If so I'm rather >>>> puzzled, as the change should only affect userland applications. >>>> Specifically, it modified a couple of ioctl handlers. >>>>=20 >>>>>=20 >>>>> It appears that if such powerpc64 machines are to stay bootable >>>>> then other things need to be cleaned up before the two updated >>>>> files from -r314624 should be used. >>>>>=20 >>>>> Should the 2 files be reverted until other things are cleaned up? >>>>=20 >>>> I don't mind reverting the change, but my suspicion is that it = uncovered >>>> a problem rather than introducing it. If you're willing to narrow = things >>>> down a bit, could you try booting with one of the file = modifications and >>>> not the other? They are independent. >>>=20 >>> In a while I'll try each of the files individually, one old, one = modern >>> each time. >>=20 >> scsi_pass.c -r314624 (new) and cam_xpt.c -r314283 (old): fails. >>=20 >> cam_xpt.c -r314624 (new) and scsi_pass.c -r308451 (old) : works fine = so far. >>=20 >> Prior results: >>=20 >> cam_xpt.c and scsi_pass.c both being -r314624 (both new): fails >>=20 >> cam_xpt.c -r314283 and scsi_pass.c -r308451 (both old): works fine. >=20 > Thank you. I'm still failing to see how the change is connected with = the > symptoms you're seeing. Are you testing with a kernel that has > INVARIANTS and WITNESS configured? >=20 > I've broken up the scsi_pass.c change into several patches. They are > sequential; can you try testing the result of each patch in the = series? I'm no longer able to reproduce the problem, not even with an "svnlite update -r314687" based build where "svnlite status /usr/src/" does not list ether of the files. This was after trying the patch sequence, which had no failures at any stage. This suggests some sort of intermittent problem someplace. At least it fits with your not finding a way for your code update to cause the results that I got. But finding such an intermittent problem is a pain. I've no clue if/when I'll even see an example again, much less find a way to investigate it if I do. (PowerMac's do not take ddb input early.) There is the possibility that the recent atomic_fcmpset based locking changes still has some sort of problem, just not seen often. Not easy to find if true. Anyway I'm now running -r314687 with: # svnlite status /usr/src/ | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/BPIM3-DBG ? /usr/src/sys/arm/conf/BPIM3-NODBG ? /usr/src/sys/arm/conf/RPI2-DBG ? /usr/src/sys/arm/conf/RPI2-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/bin/sh/jobs.c M /usr/src/bin/sh/miscbltin.c M /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp M /usr/src/crypto/openssl/crypto/armcap.c M /usr/src/lib/csu/powerpc64/Makefile M /usr/src/libexec/rtld-elf/Makefile M /usr/src/sys/arm/arm/gic.c M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/kmod.mk M /usr/src/sys/ddb/db_main.c M /usr/src/sys/ddb/db_script.c M /usr/src/sys/powerpc/ofw/ofw_machdep.c (which are long standing in my environment). I'll build and try a debug kernel but I'm not hopeful for it finding anything. =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2FA8AC16-8108-4FC7-B1E6-788CBD32F372>