From owner-freebsd-ppc@freebsd.org Tue Mar 7 17:16:00 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A481AD01388 for ; Tue, 7 Mar 2017 17:16:00 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 59D8D1BB1; Tue, 7 Mar 2017 17:16:00 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk0-x22b.google.com with SMTP id y76so14696702qkb.0; Tue, 07 Mar 2017 09:16:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=I0EC3UVk7p9ID6qC5OANlRJuMZdMpJRx64jDbQCIv4Y=; b=tHkHJPCcgtGeL4sxBXaWCKqVHHOAW1XR993k77+R57/GOUbqU5I1M3xGAefv0pQ90X LQS1XUHkvCWNx95f1Vsa5PSPTbysXzhv/d3HjMkhnVxsNtPZewvuzzd8L5ke9WsjYr4w FTTtjq9MYXJEP31LiH6nOO7qk/KigeVDN7TGiUTPTqkkQKHTNDNafHQAkLa3y+fhTjLo MXn8HD6Hr0Ucxf/fNof2oiKk/kTLjn/HkjdPcXQ7NB1qlDtbQ0vxWMDm123TXSP10wJZ OBBd1yv8q/zVjdQ3RKB5KIP4zA7+x1IzvpjkZgcKVjAfbNbH1x25WsBxli15QPmKD9Gh VZLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=I0EC3UVk7p9ID6qC5OANlRJuMZdMpJRx64jDbQCIv4Y=; b=Q0tFpPYwCE+49od83j6U5a+iLDadK2fYEntmrTu9fWaVcmTCnuadDKcZdi4jETEk7D cF3OYMOtRSxi5Y9kF3kd/69OD/8qbCtguN3Olg02G+OPbvswosNLcL1+jF+VjTCjZi/H 9tTBLwskgPIJBxszJadR08DwFToO+f2nkpT2PvExiBdsKNGBUZfzdTF1XvXULHot2Wxk iM3csAI/AN+8BceSa5JWOuT1MLyp5WJxtq+0HGnCZ7xey6zNiLqRA+2+rcI+XTV9AzEl TAGkSkKFsn+xl7qH2uXeAxb7pPMk7ug3wzkhflt4M0PB2mx88FSqOH4pzfSXyhAjj1WW eoFw== X-Gm-Message-State: AMke39kRiX4iJIXd6SLNp9aBv1uR/3sWCPynoNAnesvYZtI9ctLGaMUzbpJbmRirSrqAMA== X-Received: by 10.200.49.66 with SMTP id h2mr1794825qtb.252.1488906959270; Tue, 07 Mar 2017 09:15:59 -0800 (PST) Received: from wkstn-mjohnston.west.isilon.com (c-76-104-201-218.hsd1.wa.comcast.net. [76.104.201.218]) by smtp.gmail.com with ESMTPSA id s71sm373283qkl.60.2017.03.07.09.15.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 09:15:58 -0800 (PST) Sender: Mark Johnston Date: Tue, 7 Mar 2017 09:15:26 -0800 From: Mark Johnston To: Mark Millard Cc: FreeBSD PowerPC ML , Justin Hibbits , Nathan Whitehorn Subject: Re: powerpc64 head -r314687 (PowerMac G5 so-called "Quad Core", clang based): CAM status: Command timeout (always?) Message-ID: <20170307171526.GA42761@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> <20170307010204.GA3611@wkstn-mjohnston.west.isilon.com> <2FA8AC16-8108-4FC7-B1E6-788CBD32F372@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2FA8AC16-8108-4FC7-B1E6-788CBD32F372@dsl-only.net> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 17:16:00 -0000 On Mon, Mar 06, 2017 at 08:03:08PM -0800, Mark Millard wrote: > On 2017-Mar-6, at 5:02 PM, Mark Johnston 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.] > >> > >> On 2017-Mar-6, at 10:36 AM, Mark Millard wrote: > >> > >>> On 2017-Mar-6, at 8:43 AM, Mark Johnston wrote: > >>> > >>>> On Mon, Mar 06, 2017 at 02:05:39AM -0800, Mark Millard wrote: > >>>>> On 2017-Mar-6, at 1:37 AM, Mark Millard wrote: > >>>>> [...] > >>>>> Yep: reverting the two files allowed the PowerMac G5 so-called > >>>>> "Quad Core" to boot fully and I could log in. > >>>> > >>>> 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? > >>> > >>> . . . > >>>> If so I'm rather > >>>> puzzled, as the change should only affect userland applications. > >>>> Specifically, it modified a couple of ioctl handlers. > >>>> > >>>>> > >>>>> 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. > >>>>> > >>>>> Should the 2 files be reverted until other things are cleaned up? > >>>> > >>>> 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. > >>> > >>> In a while I'll try each of the files individually, one old, one modern > >>> each time. > >> > >> scsi_pass.c -r314624 (new) and cam_xpt.c -r314283 (old): fails. > >> > >> cam_xpt.c -r314624 (new) and scsi_pass.c -r308451 (old) : works fine so far. > >> > >> Prior results: > >> > >> cam_xpt.c and scsi_pass.c both being -r314624 (both new): fails > >> > >> cam_xpt.c -r314283 and scsi_pass.c -r308451 (both old): works fine. > > > > 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? > > > > 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: Indeed, this kind of problem is tricky to track down. A couple of thoughts: - Were you using the same compiler for all of your tests? I noticed your post yesterday about clang 3.9 vs. 4.0 for powerpc and powerpc64. - Was the rest of the source tree (i.e., everything but cam_xpt.c and scsi_pass.c) the same in all of your testing? I've noticed in the past that unrelated changes to the source tree can result in various kernel linker sets having a different order than they would have otherwise, and that can expose or hide bugs. See this recent post for an example: https://lists.freebsd.org/pipermail/freebsd-current/2016-December/064122.html