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

[Mark Millard]

[scsi_pass.c -r314624 is the problem file vintage of the two files.]

On 2017-Mar-6, at 10:36 AM, Mark Millard <markmi at dsl-only.net> wrote:

> On 2017-Mar-6, at 8:43 AM, Mark Johnston <markj at FreeBSD.org> wrote:
> 
>> 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.
> 
> 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.


[I omit the segment of the /var/log/messages file that I sent last
time.]

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