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." From owner-freebsd-sparc64@FreeBSD.ORG Sun Jan 6 03:12:54 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 B0DE7345; Sun, 6 Jan 2013 03:12:54 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id C091CFD8; Sun, 6 Jan 2013 03:12:53 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.5/8.14.5/ALCHEMY.FRANKEN.DE) with ESMTP id r063CjlY045735; Sun, 6 Jan 2013 04:12:45 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r063Cjlo045734; Sun, 6 Jan 2013 04:12:45 +0100 (CET) (envelope-from marius) Date: Sun, 6 Jan 2013 04:12:45 +0100 From: Marius Strobl To: Kurt Lidl , mav@freebsd.org, freebsd-sparc64@freebsd.org Subject: Re: smartmontools panics 9.1-RELEASE on sunfire 240 Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130106021923.GE1410@funkthat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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 03:12:54 -0000 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 :) Marius From owner-freebsd-sparc64@FreeBSD.ORG Sun Jan 6 04:17:40 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 66C12985; Sun, 6 Jan 2013 04:17:40 +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 C76C5166; Sun, 6 Jan 2013 04:17:39 +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 r064HVrD047673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jan 2013 20:17:31 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r064HVq3047672; Sat, 5 Jan 2013 20:17:31 -0800 (PST) (envelope-from jmg) Date: Sat, 5 Jan 2013 20:17:31 -0800 From: John-Mark Gurney To: Marius Strobl Subject: Re: smartmontools panics 9.1-RELEASE on sunfire 240 Message-ID: <20130106041731.GF1410@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> <20130106021923.GE1410@funkthat.com> <20130106031245.GC26039@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130106031245.GC26039@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 20:17:31 -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 04:17:40 -0000 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." From owner-freebsd-sparc64@FreeBSD.ORG Mon Jan 7 09:02:05 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2012B93B; Mon, 7 Jan 2013 09:02:05 +0000 (UTC) (envelope-from lidl@hydra.pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id D699A309; Mon, 7 Jan 2013 09:02:04 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id r07921UM053529; Mon, 7 Jan 2013 04:02:01 -0500 (EST) (envelope-from lidl@hydra.pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at mail.pix.net Received: (from lidl@localhost) by hydra.pix.net (8.14.5/8.14.5/Submit) id r07921T4053528; Mon, 7 Jan 2013 04:02:01 -0500 (EST) (envelope-from lidl) Date: Mon, 7 Jan 2013 04:02:01 -0500 From: Kurt Lidl To: Marius Strobl Subject: Re: smartmontools panics 9.1-RELEASE on sunfire 240 Message-ID: <20130107090200.GA53424@pix.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130106031245.GC26039@alchemy.franken.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mav@freebsd.org, 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: Mon, 07 Jan 2013 09:02:05 -0000 On Sun, Jan 06, 2013 at 04:12:45AM +0100, Marius Strobl wrote: > 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 :) The following one-line change to smartd.cpp allows it at least start on my sparc64 machine. (Tested on a machine with a completely stock 9.1-RELEASE kernel.) --- smartd.cpp.orig 2012-09-15 11:50:29.000000000 -0400 +++ smartd.cpp 2013-01-07 02:15:22.828853514 -0500 @@ -1910,7 +1910,7 @@ static int ATADeviceScan(dev_config & cfg, dev_state & state, ata_device * atadev) { int supported=0; - struct ata_identify_device drive; + struct ata_identify_device drive __attribute__ ((aligned (4))); const char *name = cfg.name.c_str(); int retid; -Kurt From owner-freebsd-sparc64@FreeBSD.ORG Mon Jan 7 09:23:50 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 D5BE1CC1; Mon, 7 Jan 2013 09:23:50 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 9EAD93F5; Mon, 7 Jan 2013 09:23:50 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Ts8vn-0007Mz-04; Mon, 07 Jan 2013 09:23:43 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Ts8vm-0004UQ-BD; Mon, 07 Jan 2013 09:23:42 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6) with ESMTP id r079NfNH035002; Mon, 7 Jan 2013 09:23:41 GMT (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6/Submit) id r079NfRm035001; Mon, 7 Jan 2013 09:23:41 GMT (envelope-from mexas) Date: Mon, 7 Jan 2013 09:23:41 GMT From: Anton Shterenlikht Message-Id: <201301070923.r079NfRm035001@mech-cluster241.men.bris.ac.uk> To: freebsd-questions@freebsd.org, freebsd-sparc64@freebsd.org Subject: powerd(8), cpufreq(4) only available on amd64/i386? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 09:23:50 -0000 I recently installed 9.1-release on a sparc64 box. One of the options in bsdinstall was to use the cpu power control. I chose to use it. So I've got # grep power /etc/rc.conf powerd_enable="YES" # which doesn't seem to work: root: /etc/rc: WARNING: failed to start powerd Is the following dmesg line relevant? # dmesg|grep "power management" jbusppm0: mem 0x4000f000000-0x4000f000007,0x4000f410050-0x4000f41005f on nexus0 # Anyway, I wonder if powerd is only for amd64/i386 and is not supposed to work on sparc64. cpufreq(4) is not listed in sparc64 GENERIC kernel. If that's the case, then maybe it's best to remove powerd option from bsdinstall? Anton From owner-freebsd-sparc64@FreeBSD.ORG Mon Jan 7 11:06:53 2013 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 85296C7 for ; Mon, 7 Jan 2013 11:06:53 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 7744FFA0 for ; Mon, 7 Jan 2013 11:06:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r07B6rZk088021 for ; Mon, 7 Jan 2013 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r07B6rkq088019 for freebsd-sparc64@FreeBSD.org; Mon, 7 Jan 2013 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Jan 2013 11:06:53 GMT Message-Id: <201301071106.r07B6rkq088019@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Subject: Current problem reports assigned to 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: Mon, 07 Jan 2013 11:06:53 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/170663 sparc64 panics with VIA 6421 SATA150 controller on Blade 1500 o sparc/169669 sparc64 Something seems broken in sparc64 TLS or lang/lua o sparc/164227 sparc64 [boot] Can't boot 9.0-RELEASE/sparc64 on Blade 1500 s sparc/164226 sparc64 [cd] Data corruption on 9.0-RELEASE when reading from o sparc/162513 sparc64 mpt(4), mptutil(8) reports variable, erroneous drive i o sparc/141918 sparc64 [ehci] ehci_interrupt: unrecoverable error, controller s sparc/139134 sparc64 kernel output corruption s sparc/107087 sparc64 [hang] system is hung during boot from CD o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC 11 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Mon Jan 7 15:50:39 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D9A9915E; Mon, 7 Jan 2013 15:50:39 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id B589C22D; Mon, 7 Jan 2013 15:50:39 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0MG90031SIOEMT00@smtpauth1.wiscmail.wisc.edu>; Mon, 07 Jan 2013 09:50:38 -0600 (CST) Received: from wanderer.tachypleus.net (216-75-226-134.static.wiline.com [216.75.226.134]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0MG900GGNIOBCG50@smtpauth1.wiscmail.wisc.edu>; Mon, 07 Jan 2013 09:50:36 -0600 (CST) Date: Mon, 07 Jan 2013 07:50:34 -0800 From: Nathan Whitehorn Subject: Re: powerd(8), cpufreq(4) only available on amd64/i386? In-reply-to: <201301070923.r079NfRm035001@mech-cluster241.men.bris.ac.uk> Sender: whitehorn@wisc.edu To: mexas@bristol.ac.uk Message-id: <50EAEECA.9050508@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=216.75.226.134 X-Spam-PmxInfo: Server=avs-15, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.1.7.154215, SenderIP=216.75.226.134 References: <201301070923.r079NfRm035001@mech-cluster241.men.bris.ac.uk> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 Cc: freebsd-questions@freebsd.org, 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: Mon, 07 Jan 2013 15:50:39 -0000 On 01/07/13 01:23, Anton Shterenlikht wrote: > I recently installed 9.1-release on a sparc64 box. > One of the options in bsdinstall was to use the > cpu power control. I chose to use it. So I've got > > # grep power /etc/rc.conf > powerd_enable="YES" > # > > which doesn't seem to work: > > root: /etc/rc: WARNING: failed to start powerd > > Is the following dmesg line relevant? > > # dmesg|grep "power management" > jbusppm0: mem 0x4000f000000-0x4000f000007,0x4000f410050-0x4000f41005f on nexus0 > # > > Anyway, I wonder if powerd is only for amd64/i386 > and is not supposed to work on sparc64. > cpufreq(4) is not listed in sparc64 GENERIC kernel. > > If that's the case, then maybe it's best to > remove powerd option from bsdinstall? > It does work at least on powerpc[64], but I don't think we have any sparc systems with dynamic frequency control. It's very hard for bsdinstall to know whether it will work or not in advance, since it supports installing to disk images, but I can add a note (if supported by hardware) or something. -Nathan From owner-freebsd-sparc64@FreeBSD.ORG Mon Jan 7 22:42:28 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 23FB64CC; Mon, 7 Jan 2013 22:42:28 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200::ae25]) by mx1.freebsd.org (Postfix) with ESMTP id 2223EA84; Mon, 7 Jan 2013 22:42:10 +0000 (UTC) Received: from magrathea.distal.com (magrathea.distal.com [IPv6:2001:470:e24c:200:ea06:88ff:feca:960e]) (authenticated bits=0) by mail.distal.com (8.14.3/8.14.3) with ESMTP id r07MfwVr008100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Jan 2013 17:41:59 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Changes to kern.geom.debugflags? From: Chris Ross In-Reply-To: <20130104234616.GA37999@alchemy.franken.de> Date: Mon, 7 Jan 2013 17:41:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7AA0B5D0-D49C-4D5A-8FA0-AA57C091C040@distal.com> <6A0C1005-F328-4C4C-BB83-CA463BD85127@distal.com> <20121225232507.GA47735@alchemy.franken.de> <8D01A854-97D9-4F1F-906A-7AB59BF8850B@distal.com> <6FC4189B-85FA-466F-AA00-C660E9C16367@distal.com> <20121230032403.GA29164@pix.net> <56B28B8A-2284-421D-A666-A21F995C7640@distal.com> <20130104234616.GA37999@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.distal.com [IPv6:2001:470:e24c:200::ae25]); Mon, 07 Jan 2013 17:41:59 -0500 (EST) Cc: freebsd-sparc64@freebsd.org, avg@freebsd.org, Kurt Lidl 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: Mon, 07 Jan 2013 22:42:28 -0000 On Jan 4, 2013, at 18:46 , Marius Strobl = wrote: >> So, now that we're past the holiday madness, and I haven't heard = anything back >> on this is there some other group or list I should ask the questions = of ZFS internals >> to figure out why the sparc64 MD boot loader code is seeing a = dn_datablkszsec >> of 0, and what it should be set to? >>=20 >> Thanks. I'm happy to compose another message to include people who = might >> be able to help. I'm out of my "comfort zone" in ZFS. >=20 > The most straightforward way is to identify the commit that broke > it via a binary search and email the corresponding commit. Okay. I've completed this search. SVN rev 242228 works, boots up, = the first call to dnode_read() (in sys/boot/zfs/zfsimpl.c) (well, "first" call after = the console is initialized) shows (due to a printf I added) : dnode_read(): offset 512, bsize 16384, dn_datablkszsec 32 I notice in all of the many following calls that bsize is always 512 = or 16384, and dn_datablkszsec is sometimes as small as 1, or as large as 68, but = always non-zero. SVN revision 242230 fails in the same way the head of stable/9 does. = The first output I see from my printf in dnode_read() is (and the following trap): dnode_read(): offset 512, bsize 0, dn_datablkszsec 0 ERROR: Last Trap: Division by Zero I didn't test 242229,. but could if needed, because both 242229 and = 242230 were ZFS changes in the boot code, and by the same person. ------------------------------------------------------------------------ r242229 | avg | 2012-10-28 11:45:18 -0400 (Sun, 28 Oct 2012) | 3 lines MFC r241283: zfs boot: add code for listing child datasets of a given dataset ------------------------------------------------------------------------ ------------------------------------------------------------------------ r242230 | avg | 2012-10-28 11:47:56 -0400 (Sun, 28 Oct 2012) | 2 lines MFC r241289: boot/zfs: call zfs_spa_init for all found pools ------------------------------------------------------------------------ Should this go to Andriy, or is someone else more familiar with spar64 issues? These seem to come from a range of ZFS changes by Andriy (r241282 - r241294) on October 6. Something got messed up for the sparc64 code, though. Thanks. - Chris From owner-freebsd-sparc64@FreeBSD.ORG Tue Jan 8 01:53:55 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 C3D16D69; Tue, 8 Jan 2013 01:53:55 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200::ae25]) by mx1.freebsd.org (Postfix) with ESMTP id 81E66217; Tue, 8 Jan 2013 01:53:55 +0000 (UTC) Received: from magrathea.distal.com (magrathea.distal.com [206.138.151.12]) (authenticated bits=0) by mail.distal.com (8.14.3/8.14.3) with ESMTP id r081rpDd003675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Jan 2013 20:53:52 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Changes to kern.geom.debugflags? From: Chris Ross In-Reply-To: Date: Mon, 7 Jan 2013 20:53:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7AA0B5D0-D49C-4D5A-8FA0-AA57C091C040@distal.com> <6A0C1005-F328-4C4C-BB83-CA463BD85127@distal.com> <20121225232507.GA47735@alchemy.franken.de> <8D01A854-97D9-4F1F-906A-7AB59BF8850B@distal.com> <6FC4189B-85FA-466F-AA00-C660E9C16367@distal.com> <20121230032403.GA29164@pix.net> <56B28B8A-2284-421D-A666-A21F995C7640@distal.com> <20130104234616.GA37999@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.distal.com [206.138.151.250]); Mon, 07 Jan 2013 20:53:52 -0500 (EST) Cc: freebsd-sparc64@freebsd.org, avg@freebsd.org, Kurt Lidl 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: Tue, 08 Jan 2013 01:53:55 -0000 On Jan 7, 2013, at 17:41 , Chris Ross wrote: > Okay. I've completed this search. SVN rev 242228 works, boots up, = the first call > to dnode_read() (in sys/boot/zfs/zfsimpl.c) (well, "first" call after = the console is initialized) > shows (due to a printf I added) : >=20 > dnode_read(): offset 512, bsize 16384, dn_datablkszsec 32 >=20 > I notice in all of the many following calls that bsize is always 512 = or 16384, and > dn_datablkszsec is sometimes as small as 1, or as large as 68, but = always non-zero. >=20 > SVN revision 242230 fails in the same way the head of stable/9 does. = The first output > I see from my printf in dnode_read() is (and the following trap): >=20 > dnode_read(): offset 512, bsize 0, dn_datablkszsec 0 > ERROR: Last Trap: Division by Zero >=20 > I didn't test 242229,. but could if needed, because both 242229 and = 242230 were > ZFS changes in the boot code, and by the same person. Out of curiosity, I did try 242229. It boots. So. the problem = occurred with 242230, which=20 came from 241289. FYI. - Chris From owner-freebsd-sparc64@FreeBSD.ORG Tue Jan 8 09:39:08 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 31FD0BC0 for ; Tue, 8 Jan 2013 09:39:08 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f42.google.com (mail-bk0-f42.google.com [209.85.214.42]) by mx1.freebsd.org (Postfix) with ESMTP id BC3ED6B4 for ; Tue, 8 Jan 2013 09:39:07 +0000 (UTC) Received: by mail-bk0-f42.google.com with SMTP id ji2so102590bkc.15 for ; Tue, 08 Jan 2013 01:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0YNpxZi+ugNA3YfreSguBCWfIx9twO/aHEzi3cysSX0=; b=vgO1rJ+ZDLO80Yv8ZHY5lN1/f+5pk9JW6o+R2PvBVNfkv6u6t2wG7cXYdVg3MRxg1x ZGbQPkO3sHB/bUYbGWhxXONMMGmkHHqMiCeL8XhjQbmvd2/HaJuDc6erpDxzC4znFa9+ d2Z/qF3N0RIdkJY0i3WToJACdCuIjHfnR5u9nexVpD59qlerhk0hcUdXSB7WpUCuAoXe 7qB2e3muIfmuidQcgIIUXhtOY4K26t69Qal2rNmxTUH/XlN7RWN515O8I+rpjrsG3yGK ZtbbqfG9D9SzF8KRpRRMgpArMp+fVH1tl844tgfxWSKnICZPXqb2Dy65BJrXQ3zKupRz ZRNQ== X-Received: by 10.204.9.22 with SMTP id j22mr31216446bkj.114.1357637946295; Tue, 08 Jan 2013 01:39:06 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id 18sm44592209bkv.0.2013.01.08.01.39.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Jan 2013 01:39:05 -0800 (PST) Sender: Alexander Motin Message-ID: <50EBE936.4000806@FreeBSD.org> Date: Tue, 08 Jan 2013 11:39:02 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Marius Strobl Subject: Re: smartmontools panics 9.1-RELEASE on sunfire 240 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> In-Reply-To: <20130106031245.GC26039@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 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: Tue, 08 Jan 2013 09:39:08 -0000 On 06.01.2013 05:12, Marius Strobl wrote: > 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 :) That patch would do the trick, but I can't say that I like it. Yes, there are many things tied to 16-bit in ATA world: both legacy ATA DMA and AHCI require 16-bit aligned data, legacy ATA DMA also require even transfer size. On the other side, Silicon Image siis(4) chips have no such limitations, that makes it chip-specific, not system-specific problem. Also for other DMA cases alignment is handled by busdma code via bounce buffers -- not free, but transparent for user. For PIO transfers data alignment is just outside of the ATA specification and depends on implementation. I think better solution would be to implement support for misaligned PIO in ata(4) driver. It would cost just about dozen or two lines and should be quite trivial. Probably I should do it last time this alignment problem appeared. smartmontools is a good testing tool for ATA stack, as it uses so many kinds of ATA commands, that many of them are never used by kernel. -- Alexander Motin From owner-freebsd-sparc64@FreeBSD.ORG Sat Jan 12 22:37:25 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 7F5A6BCE for ; Sat, 12 Jan 2013 22:37:25 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by mx1.freebsd.org (Postfix) with ESMTP id 3FCDFB63 for ; Sat, 12 Jan 2013 22:37:25 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id p16so2471020vcq.25 for ; Sat, 12 Jan 2013 14:37:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding; bh=KkHdI+28pjGDr9iZv729WjeVVCQ6sCXgTvq4cjzC2gU=; b=fi9NZH2vlyQXwEHFgMRGnyMXqxbVTqWnq5JICc3tOonSrTJ4Gx2p3FLG3MkNB/wimc uuSa3Mn5btXlOQfE5cEPDw4kAqAXWZxoZjTFJNE5+3yRPUqlcojsrtVv6oW7mAv1nuxg OWh0xvD0mUpLfmFfbM4qjR5UhZWQtb+3V7HKJwZ6fkfAxyR6X+kLaXekGQzWitv+j/bH NS2CP4U1QZ2FHpb/OItdwEg++AQTdVnNYs7eUTSgvOKZJ6PAg7AylNQrIT7/eZ0Lo70y KwLhj1eye/Dwf5r9+EfwkVUTkz7KOq06yJDYHHVFedvj00MYZQw8Oqp4eyqd2EYSZmTw apSA== Received: by 10.220.241.80 with SMTP id ld16mr8365009vcb.5.1358030238599; Sat, 12 Jan 2013 14:37:18 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.164.100 with HTTP; Sat, 12 Jan 2013 14:36:58 -0800 (PST) From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Sat, 12 Jan 2013 23:36:58 +0100 X-Google-Sender-Auth: moIZ6xMvtuMuwY2kMVEeyp96UZ0 Message-ID: Subject: How to retrieve the "bootpath" variable in a running FreeBSD ? To: freebsd-sparc64@freebsd.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: Sat, 12 Jan 2013 22:37:25 -0000 Hi all, I've almost finish my nanobsd-sparc64 script but I meet a problem for the upgrade script. The last step of the upgrade process is to modify the OPB for booting on the new-system-partition "d" of my drive in place of the old-system-partition "a". I can use a simple command like this: eeprom boot-device=3Ddisk:d But this method is too stupid because it didn't works if my nanobsd is installed on another disk than the disk corresponding to the nvram alias "disk". This is why I want to use the more precise variable "bootpath" that is display during the FreeBSD bootstrap loader like on this capture: FreeBSD/sparc64 bootstrap loader, Revision 1.0 (root@sparc.orange.bsdrp.net, Sat Jan 12 10:12:01 UTC 2013) bootpath=3D"/pci@1f,0/ide@d/disk@1,0:a" But, I've checked in "sysctl -a" and in "eeprom -a"=85 I didn't found it. Do you know where I can found it from my running FreeBSD ? Thanks, Olivier From owner-freebsd-sparc64@FreeBSD.ORG Sat Jan 12 22:51:30 2013 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 43987FD0 for ; Sat, 12 Jan 2013 22:51:30 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 1E215C29 for ; Sat, 12 Jan 2013 22:51:25 +0000 (UTC) Received: from alph.allbsd.org (p1137-ipbf1505funabasi.chiba.ocn.ne.jp [118.7.212.137]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r0CMp7Mi067912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Jan 2013 07:51:17 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id r0CMp69E026513; Sun, 13 Jan 2013 07:51:07 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 13 Jan 2013 07:50:38 +0900 (JST) Message-Id: <20130113.075038.471841385206679419.hrs@allbsd.org> To: olivier@cochard.me Subject: Re: How to retrieve the "bootpath" variable in a running FreeBSD ? From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sun_Jan_13_07_50_38_2013_966)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Sun, 13 Jan 2013 07:51:17 +0900 (JST) X-Spam-Status: No, score=-97.9 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT,QENCPTR2,SAMEHELOBY2HOP,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: 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: Sat, 12 Jan 2013 22:51:30 -0000 ----Security_Multipart(Sun_Jan_13_07_50_38_2013_966)-- Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 T2xpdmllciBDb2NoYXJkLUxhYmLDqSA8b2xpdmllckBjb2NoYXJkLm1lPiB3cm90ZQ0KICBpbiA8 Q0ErcStUY3JMcTJ0SmQwZmZMR2dpc3dCa296czRUPXBQd2pieTU1QjFGYkQ9cEJFMjZBQG1haWwu Z21haWwuY29tPjoNCg0Kb2w+IEhpIGFsbCwNCm9sPiANCm9sPiBJJ3ZlIGFsbW9zdCBmaW5pc2gg bXkgbmFub2JzZC1zcGFyYzY0IHNjcmlwdCBidXQgSSBtZWV0IGEgcHJvYmxlbSBmb3INCm9sPiB0 aGUgdXBncmFkZSBzY3JpcHQuDQpvbD4gVGhlIGxhc3Qgc3RlcCBvZiB0aGUgdXBncmFkZSBwcm9j ZXNzIGlzIHRvIG1vZGlmeSB0aGUgT1BCIGZvciBib290aW5nDQpvbD4gb24gdGhlIG5ldy1zeXN0 ZW0tcGFydGl0aW9uICJkIiBvZiBteSBkcml2ZSBpbiBwbGFjZSBvZiB0aGUNCm9sPiBvbGQtc3lz dGVtLXBhcnRpdGlvbiAiYSIuDQpvbD4gSSBjYW4gdXNlIGEgc2ltcGxlIGNvbW1hbmQgbGlrZSB0 aGlzOg0Kb2w+IGVlcHJvbSBib290LWRldmljZT1kaXNrOmQNCm9sPiBCdXQgdGhpcyBtZXRob2Qg aXMgdG9vIHN0dXBpZCBiZWNhdXNlIGl0IGRpZG4ndCB3b3JrcyBpZiBteSBuYW5vYnNkIGlzDQpv bD4gaW5zdGFsbGVkIG9uIGFub3RoZXIgZGlzayB0aGFuIHRoZSBkaXNrIGNvcnJlc3BvbmRpbmcg dG8gdGhlIG52cmFtDQpvbD4gYWxpYXMgImRpc2siLg0Kb2w+IFRoaXMgaXMgd2h5IEkgd2FudCB0 byB1c2UgdGhlIG1vcmUgcHJlY2lzZSB2YXJpYWJsZSAiYm9vdHBhdGgiIHRoYXQgaXMNCm9sPiBk aXNwbGF5IGR1cmluZyB0aGUgRnJlZUJTRCBib290c3RyYXAgbG9hZGVyIGxpa2Ugb24gdGhpcyBj YXB0dXJlOg0Kb2w+IA0Kb2w+IEZyZWVCU0Qvc3BhcmM2NCBib290c3RyYXAgbG9hZGVyLCBSZXZp c2lvbiAxLjANCm9sPiAocm9vdEBzcGFyYy5vcmFuZ2UuYnNkcnAubmV0LCBTYXQgSmFuIDEyIDEw OjEyOjAxIFVUQyAyMDEzKQ0Kb2w+IGJvb3RwYXRoPSIvcGNpQDFmLDAvaWRlQGQvZGlza0AxLDA6 YSINCm9sPiANCm9sPiBCdXQsIEkndmUgY2hlY2tlZCBpbiAic3lzY3RsIC1hIiBhbmQgaW4gImVl cHJvbSAtYSLigKYgSSBkaWRuJ3QgZm91bmQgaXQuDQpvbD4gRG8geW91IGtub3cgd2hlcmUgSSBj YW4gZm91bmQgaXQgZnJvbSBteSBydW5uaW5nIEZyZWVCU0QgPw0KDQogVHJ5Og0KDQogJSBrZW52 IGN1cnJkZXYNCg0KLS0gSGlyb2tpDQo= ----Security_Multipart(Sun_Jan_13_07_50_38_2013_966)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAlDx6L4ACgkQTyzT2CeTzy1kewCdEHat+BfLf6AkvcBl/91KhFSr agkAn1zWRvzVBN0wpa0NJuUn/Nn4Tb+Q =stWm -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Jan_13_07_50_38_2013_966)----