From owner-freebsd-sparc64@FreeBSD.ORG Sun Jan 6 02:40:27 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C62EFA6D; Sun, 6 Jan 2013 02:40:27 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7CF3BEA8; Sun, 6 Jan 2013 02:40:27 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r062JOLg046123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jan 2013 18:19:24 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r062JNEX046122; Sat, 5 Jan 2013 18:19:23 -0800 (PST) (envelope-from jmg) Date: Sat, 5 Jan 2013 18:19:23 -0800 From: John-Mark Gurney To: Marius Strobl Subject: Re: smartmontools panics 9.1-RELEASE on sunfire 240 Message-ID: <20130106021923.GE1410@funkthat.com> Mail-Followup-To: Marius Strobl , Kurt Lidl , mav@freebsd.org, freebsd-sparc64@freebsd.org References: <20130104051914.GA22613@pix.net> <20130104235336.GB37999@alchemy.franken.de> <20130105013224.GA31361@pix.net> <20130105015242.GB26039@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130105015242.GB26039@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 05 Jan 2013 18:19:24 -0800 (PST) Cc: mav@freebsd.org, Kurt Lidl , freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 02:40:27 -0000 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."