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

Mark Johnston markj at FreeBSD.org
Tue Mar 7 01:02:33 UTC 2017


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 <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:
> >>> [...]
> >>> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Check-for-CAM_UNLOCKED-in-CAMIOCOMMAND.patch
Type: text/x-diff
Size: 799 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ppc/attachments/20170306/05fbf72f/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Check-for-CAM_UNLOCKED-in-CAMIOQUEUE.patch
Type: text/x-diff
Size: 862 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ppc/attachments/20170306/05fbf72f/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Fix-error-handling-for-CAMIOQUEUE.patch
Type: text/x-diff
Size: 2732 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ppc/attachments/20170306/05fbf72f/attachment-0002.patch>


More information about the freebsd-ppc mailing list