Date: Sat, 5 Jan 2013 18:19:23 -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: <20130106021923.GE1410@funkthat.com> In-Reply-To: <20130105015242.GB26039@alchemy.franken.de> References: <20130104051914.GA22613@pix.net> <20130104235336.GB37999@alchemy.franken.de> <20130105013224.GA31361@pix.net> <20130105015242.GB26039@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
--
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?20130106021923.GE1410>