smartmontools panics 9.1-RELEASE on sunfire 240

[John-Mark Gurney]

Marius Strobl wrote this message on Sun, Jan 06, 2013 at 04:12 +0100:
> On Sat, Jan 05, 2013 at 06:19:23PM -0800, John-Mark Gurney wrote:
> > Marius Strobl wrote this message on Sat, Jan 05, 2013 at 02:52 +0100:
> > > On Fri, Jan 04, 2013 at 08:32:24PM -0500, Kurt Lidl wrote:
> > > > On Sat, Jan 05, 2013 at 12:53:36AM +0100, Marius Strobl wrote:
> > > > > Uhm, probably an userland buffer which isn't even 16-bit aligned.
> > > > > If that's the cause, the attached patch hopefully should at least
> > > > > prevent the panic. If it does, smartmontools still need to be fixed
> > > > > though.
> > > > 
> > > > You patch prevents the panic from happening.
> > > > When I try to start smartd now, it reports:
> > > > 
> > > > root at host-98: /usr/local/etc/rc.d/smartd onestart
> > > > Starting smartd.
> > > > smartd: cam_send_ccb: Invalid argument
> > > > /usr/local/etc/rc.d/smartd: WARNING: failed to start smartd
> > > > 
> > > > I had updated the kernel on the machine to 9-STABLE, and
> > > > verified that without this patch, the crash still happened with
> > > > a 9-STABLE kernel, in addition to 9.1-RELEASE kernel.
> > > > 
> > > > My kernel now identifies itself as:
> > > > FreeBSD 9.1-STABLE (GENERIC) #1 r245044:245048M: Fri Jan  4 20:19:50 EST 2013
> > > > 
> > > > -Kurt
> > > > 
> > > > > Index: cam_periph.c
> > > > > ===================================================================
> > > > > --- cam_periph.c	(revision 245046)
> > > > > +++ cam_periph.c	(working copy)
> > > > > @@ -744,6 +744,9 @@ cam_periph_mapmem(union ccb *ccb, struct cam_perip
> > > > >  		if ((ccb->ccb_h.flags & CAM_DIR_MASK) == CAM_DIR_NONE)
> > > > >  			return(0);
> > > > >  
> > > > > +		if ((uintptr_t)ccb->ataio.data_ptr % sizeof(uint16_t) != 0)
> > > > > +			return (EINVAL);
> > > > > +
> > > > >  		data_ptrs[0] = &ccb->ataio.data_ptr;
> > > > >  		lengths[0] = ccb->ataio.dxfer_len;
> > > > >  		dirs[0] = ccb->ccb_h.flags & CAM_DIR_MASK;
> > > > 
> > > 
> > > Alexander, are you okay with this approach or do you have a better
> > > idea how to handle this? In any case, it doesn't seem to make sense
> > > to teach the kernel how to cope with arbitrarily aligned buffers for
> > > ATA.
> > 
> > Shouldn't we make it dependant on the __NO_STRICT_ALIGNMENT define so
> > that it won't immediately break other arches?
> > 
> 
> No, not doing so tremendously helps ensuring that the software is
> properly written (apart from compact flash, ATA devices really
> only support 16-bit and 32-bit accesses) and judging the history
> of the patches in the smartmontools port it apparently already
> has to care about proper alignment for SCSI anyway. It would also
> not be the first time the smartmontools port is blown out of the
> water :)

Just wanted to make sure we understand the implications of this.

Please make sure that this requirement is properly documented on the
cam(3) man page then.

Thanks.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."