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

[Mark Millard]

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.

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?

===
Mark Millard
markmi at dsl-only.net