Date: Sat, 5 Jan 2013 20:17:31 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Marius Strobl <marius@alchemy.franken.de> Cc: mav@freebsd.org, Kurt Lidl <lidl@pix.net>, freebsd-sparc64@freebsd.org Subject: Re: smartmontools panics 9.1-RELEASE on sunfire 240 Message-ID: <20130106041731.GF1410@funkthat.com> In-Reply-To: <20130106031245.GC26039@alchemy.franken.de> References: <20130104051914.GA22613@pix.net> <20130104235336.GB37999@alchemy.franken.de> <20130105013224.GA31361@pix.net> <20130105015242.GB26039@alchemy.franken.de> <20130106021923.GE1410@funkthat.com> <20130106031245.GC26039@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130106041731.GF1410>