Date: Mon, 6 Mar 2017 08:43:41 -0800 From: Mark Johnston <markj@FreeBSD.org> To: Mark Millard <markmi@dsl-only.net> 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: <20170306164341.GA83069@wkstn-mjohnston.west.isilon.com> In-Reply-To: <4C78F6AA-5ABD-4445-B5EF-4E6778CE36FE@dsl-only.net> References: <98A62E0D-C2A0-40B1-AE6D-5810906208AE@dsl-only.net> <4C78F6AA-5ABD-4445-B5EF-4E6778CE36FE@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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: > > > When I tried to jump from head -r314479 to -r314687 the -r314687 kernel > > the result failed by always(?) getting: > > > > CAM status: Command timeout > > > > for: > > > > ATAPI_IDENTIFY > > INQUIRY > > DSM TRIM > > READ_DMA48 > > SETFEATURES ENABLE RCACHE > > WRITE_DMA48 > > etc. > > > > at: > > > > ada0:ata2:0:0:0 > > aprobe0:ata0:0:0:0 > > > > Booting with the older -r314479 works fine (same -r314687 world). > > > > [FYI: It is a ufs context.] > > > > > > The only thing that looks likely to me for > > the change in behavior is. . . > > > > Author: markj > > Date: Fri Mar 3 20:51:57 2017 > > New Revision: 314624 > > URL: > > https://svnweb.freebsd.org/changeset/base/314624 > > > > > > Log: > > Reject userland CCBs that have CAM_UNLOCKED set. > > > > CAM_UNLOCKED is internal flag and cannot correctly be set by userland. > > Return EINVAL from CAMIOCOMMAND and CAMIOQUEUE if it is set. > > > > Also fix leaks in some of the error paths for CAMIOQUEUE. > > > > PR: 215356 > > Reviewed by: ken, mav > > MFC after: 1 week > > Differential Revision: > > https://reviews.freebsd.org/D9869 > > > > > > Modified: > > head/sys/cam/cam_xpt.c > > head/sys/cam/scsi/scsi_pass.c > > > > > > > > [This may just mean that it exposes other problems.] > > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170306164341.GA83069>