powerpc64 head -r314687 (PowerMac G5 so-called "Quad Core", clang based): CAM status: Command timeout (always?)

Mark Johnston markj at FreeBSD.org
Mon Mar 6 16:44:21 UTC 2017


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.


More information about the freebsd-ppc mailing list