From owner-freebsd-sparc64@FreeBSD.ORG Sun Jan 13 00:28: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 17B1C930; Sun, 13 Jan 2013 00:28:05 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 973F9F40; Sun, 13 Jan 2013 00:28:04 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so2566841vba.27 for ; Sat, 12 Jan 2013 16:27:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=QAcAuooPmYhwnNZjzlyS/JB4OF+bX2VbTJZ8VH+pgHY=; b=LlLF4IU6bO6K4FrhBRk8kLDi5/gJCQcqHB/O35tH8gw9FGLu7uhsGFaRxezjh0tt0c PnnkLaUl0Z1aJdfzlsz4P4kL1DqUkoDatIelPMtOofDDFPgnea5kCubnjM8NDAD43Pfq hCZACMaiIaTJ0RShFN/025i681mHmgBfdxt5bsBO9cdfTVv5ZqC/A8tzBj57ei/cYdxL tlpyr0N0Yy64YAStXBvDC+NGNC6SSBnzarh/wQDynzY9QznbH0QFFWiDIg+7MBbbnPBB DKMnvS/74e+CNxHy64N+sLSWTfjvXSbAypc2fI1rfTb2RRbVAc+6+Uj7Wgyl4aTVLNGI 7hBA== Received: by 10.58.44.74 with SMTP id c10mr101654214vem.10.1358036877817; Sat, 12 Jan 2013 16:27:57 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.164.100 with HTTP; Sat, 12 Jan 2013 16:27:36 -0800 (PST) In-Reply-To: <20130113.075038.471841385206679419.hrs@allbsd.org> References: <20130113.075038.471841385206679419.hrs@allbsd.org> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Sun, 13 Jan 2013 01:27:36 +0100 X-Google-Sender-Auth: RNTn1KSXrwWN23d3wAyEcvskC9s Message-ID: Subject: Re: How to retrieve the "bootpath" variable in a running FreeBSD ? To: Hiroki Sato Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 13 Jan 2013 00:28:05 -0000 On Sat, Jan 12, 2013 at 11:50 PM, Hiroki Sato wrote: > > Try: > > % kenv currdev > Thanks a lot's ! Now my eeprom is correctly updated, just a last bug to fix. After updating the eeprom from FreeBSD I need to issue a cold-reboot for eeprom changes being applied (poweroff+poweron or "boot" command in OBP): A simple "reboot" from SSH console is not enough. I don't know if it's my old Sun Blade 150 that have this problem or if it's a normal sparc behavior. Regards, Olivier From owner-freebsd-sparc64@FreeBSD.ORG Sun Jan 13 15:55:19 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 5B8F71F7; Sun, 13 Jan 2013 15:55:19 +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 D7383B14; Sun, 13 Jan 2013 15:55:18 +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 r0DFtHtb010910; Sun, 13 Jan 2013 16:55:17 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r0DFtGma010909; Sun, 13 Jan 2013 16:55:16 +0100 (CET) (envelope-from marius) Date: Sun, 13 Jan 2013 16:55:16 +0100 From: Marius Strobl To: Alexander Motin Subject: Re: smartmontools panics 9.1-RELEASE on sunfire 240 Message-ID: <20130113155516.GK26039@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> <50EBE936.4000806@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50EBE936.4000806@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Sun, 13 Jan 2013 15:55:19 -0000 On Tue, Jan 08, 2013 at 11:39:02AM +0200, Alexander Motin wrote: > 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. My reading of 3.2.9 of the ATA-7 specification actually is different as it says that apart from CFA devices, both DMA and PIO transfers are 16-bit and generally there's no guarantee that there's anything like a DMA engine or busdma code that can handle unaligned transfers in between, especially for PIO. > Also for other DMA cases alignment is handled by busdma code > via bounce buffers -- not free, but transparent for user. The main purpose of DMA bounce buffers is address range translation in case a device can't access the whole system memory, thus the sparc64 busdma code doesn't use bounce buffers as that job is done by the IOMMU. AFAICT, no MD bus_dmamap_load_uio() implementation currently handles unaligned transfers as this is not just about unaligned buffers in RAM but also the appropriate cache flushing necessary for these and just happens to work on x86. > For PIO > transfers data alignment is just outside of the ATA specification and > depends on implementation. I don't agree here as it is hard to imagine how an ATA controller should be able to handle unaligned PIO (assuming your statement regarding siis(4) driven chips refers to DMA only and unaligned PIO hasn't actually been implemented in some ATA controllers). > > 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. In the end I don't really care as long as it works but from a sheer performance point of view it seems wrong to bounce PIO in the kernel if it is trivial for applications to care about the alignment required by the protocol they want to talk in the first place. Marius From owner-freebsd-sparc64@FreeBSD.ORG Sun Jan 13 16:49:10 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 7695AAE0 for ; Sun, 13 Jan 2013 16:49:10 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by mx1.freebsd.org (Postfix) with ESMTP id 0872AEA9 for ; Sun, 13 Jan 2013 16:49:09 +0000 (UTC) Received: by mail-bk0-f52.google.com with SMTP id w5so1557381bku.25 for ; Sun, 13 Jan 2013 08:49:03 -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=MWR4j8Mv32M4DiNzvSiVgrcMFvioBxAHtBctGu6HBog=; b=PLAjahaabCWY4KuFZBf15vDrH+11vR6lzXS+b+SZRHkM6mytkvN/bEuYZ9BtEte86e dYovt9VjfgKsrOFYNmGa1ZZedD/CvYTpTS9b6dWYyoYJQjXIk+Eq2RRMgfQyi219zP2B 7peClBFBL1T1OoGImIm+uNv4fr8Nf1gy9yWMYlU/PDWKjQqPr9IK3pB1z96xMn5pP3ZA XzC823wpXYNJqEg9MEUU3JE72aOnpF9pnzeH08MAJ6Xe0Y0tAoh5iokuCWfuAT8FT5cc hUc3eu7tB6ul4cYKVMnyVsBUEZ97S9zLZuCiLbMrANb5aSC2zC+olyRAsKa1/KLoWLM0 pEZw== X-Received: by 10.204.157.26 with SMTP id z26mr38551383bkw.101.1358095743510; Sun, 13 Jan 2013 08:49:03 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id r16sm7808185bkv.3.2013.01.13.08.49.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Jan 2013 08:49:02 -0800 (PST) Sender: Alexander Motin Message-ID: <50F2E57C.1090305@FreeBSD.org> Date: Sun, 13 Jan 2013 18:49:00 +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> <50EBE936.4000806@FreeBSD.org> <20130113155516.GK26039@alchemy.franken.de> In-Reply-To: <20130113155516.GK26039@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: Sun, 13 Jan 2013 16:49:10 -0000 On 13.01.2013 17:55, Marius Strobl wrote: > On Tue, Jan 08, 2013 at 11:39:02AM +0200, Alexander Motin wrote: >> 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. > > My reading of 3.2.9 of the ATA-7 specification actually is different > as it says that apart from CFA devices, both DMA and PIO transfers > are 16-bit and generally there's no guarantee that there's anything > like a DMA engine or busdma code that can handle unaligned transfers > in between, especially for PIO. Yes, transfers are 16-bit, but odd-sized transfers are zero-padded by transmitter. PIO may drop extra byte, but with DMA that extra received byte of padding may overwrite something important. >> Also for other DMA cases alignment is handled by busdma code >> via bounce buffers -- not free, but transparent for user. > > The main purpose of DMA bounce buffers is address range translation > in case a device can't access the whole system memory, thus the > sparc64 busdma code doesn't use bounce buffers as that job is done > by the IOMMU. AFAICT, no MD bus_dmamap_load_uio() implementation > currently handles unaligned transfers as this is not just about > unaligned buffers in RAM but also the appropriate cache flushing > necessary for these and just happens to work on x86. Hmm. Pity. >> For PIO >> transfers data alignment is just outside of the ATA specification and >> depends on implementation. > > I don't agree here as it is hard to imagine how an ATA controller > should be able to handle unaligned PIO (assuming your statement > regarding siis(4) driven chips refers to DMA only and unaligned PIO > hasn't actually been implemented in some ATA controllers). siis(4) uses DMA for all data transfers, including PIO emulation. And it has no address restrictions. Speaking about legacy ATA controller PIO, what it the problem to read 16-bit value from aligned controller port and then write it to RAM on odd address in two halves? With PIO performance is out of question any way. >> 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. > > In the end I don't really care as long as it works but from a sheer > performance point of view it seems wrong to bounce PIO in the kernel > if it is trivial for applications to care about the alignment required > by the protocol they want to talk in the first place. I don't mind if application will manage some alignment, but so far it doesn't. -- Alexander Motin From owner-freebsd-sparc64@FreeBSD.ORG Sun Jan 13 17:14:00 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 89F7C585; Sun, 13 Jan 2013 17:14:00 +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 0C76CFC0; Sun, 13 Jan 2013 17:13:59 +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 r0DHDwuS013593; Sun, 13 Jan 2013 18:13:58 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r0DHDwf4013592; Sun, 13 Jan 2013 18:13:58 +0100 (CET) (envelope-from marius) Date: Sun, 13 Jan 2013 18:13:58 +0100 From: Marius Strobl To: Alexander Motin Subject: Re: smartmontools panics 9.1-RELEASE on sunfire 240 Message-ID: <20130113171358.GL26039@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> <50EBE936.4000806@FreeBSD.org> <20130113155516.GK26039@alchemy.franken.de> <50F2E57C.1090305@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50F2E57C.1090305@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Sun, 13 Jan 2013 17:14:00 -0000 On Sun, Jan 13, 2013 at 06:49:00PM +0200, Alexander Motin wrote: > On 13.01.2013 17:55, Marius Strobl wrote: > > On Tue, Jan 08, 2013 at 11:39:02AM +0200, Alexander Motin wrote: > >> 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. > > > > My reading of 3.2.9 of the ATA-7 specification actually is different > > as it says that apart from CFA devices, both DMA and PIO transfers > > are 16-bit and generally there's no guarantee that there's anything > > like a DMA engine or busdma code that can handle unaligned transfers > > in between, especially for PIO. > > Yes, transfers are 16-bit, but odd-sized transfers are zero-padded by > transmitter. PIO may drop extra byte, but with DMA that extra received > byte of padding may overwrite something important. > > >> Also for other DMA cases alignment is handled by busdma code > >> via bounce buffers -- not free, but transparent for user. > > > > The main purpose of DMA bounce buffers is address range translation > > in case a device can't access the whole system memory, thus the > > sparc64 busdma code doesn't use bounce buffers as that job is done > > by the IOMMU. AFAICT, no MD bus_dmamap_load_uio() implementation > > currently handles unaligned transfers as this is not just about > > unaligned buffers in RAM but also the appropriate cache flushing > > necessary for these and just happens to work on x86. > > Hmm. Pity. > > >> For PIO > >> transfers data alignment is just outside of the ATA specification and > >> depends on implementation. > > > > I don't agree here as it is hard to imagine how an ATA controller > > should be able to handle unaligned PIO (assuming your statement > > regarding siis(4) driven chips refers to DMA only and unaligned PIO > > hasn't actually been implemented in some ATA controllers). > > siis(4) uses DMA for all data transfers, including PIO emulation. Ah, PIO emulation is something I had not thought of. > And it > has no address restrictions. Speaking about legacy ATA controller PIO, > what it the problem to read 16-bit value from aligned controller port > and then write it to RAM on odd address in two halves? With PIO > performance is out of question any way. I see no real technical problem in doing so, it's just unpleasant. > > >> 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. > > > > In the end I don't really care as long as it works but from a sheer > > performance point of view it seems wrong to bounce PIO in the kernel > > if it is trivial for applications to care about the alignment required > > by the protocol they want to talk in the first place. > > I don't mind if application will manage some alignment, but so far it > doesn't. > That's hardly an excuse, it seems the majority of applications today aren't written with support for architectures with strict alignment requirements in mind and only tested on x86 :) AFAICT cdrtools in contrast are written with that in mind. Marius From owner-freebsd-sparc64@FreeBSD.ORG Sun Jan 13 20:39:20 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 C3B8A25C; Sun, 13 Jan 2013 20:39:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by mx1.freebsd.org (Postfix) with ESMTP id 13D98A71; Sun, 13 Jan 2013 20:39:19 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id e12so1656753wge.34 for ; Sun, 13 Jan 2013 12:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=oV1vzTqA60KKNQmbpwtTCtJLzD0+LB55Vl83up8pA60=; b=OlRoOik/JUxtxYPCoIEtn9HSholo3C4HWmZRNwBcICRNKG5cL3OwQyeoNjlPqzL33F 3LGhqKgDraUKt5XEwWBscdC8qhe5QbJtjRXbdbLBy+40GlB8RkjqKr+tFKBlzW3Sl4La Wo3FsMZLetqE6prtTi2YxUXzE12f6qrynCQryFWWw0ppAG2SySmK4X176cc6p8yyjGXt jlY2bNWxCW6hcwzHqDgJSd3vDG4tR6mLnvrmiLQHf+hbNgLkbAJ6XqWPL2jQMCWkDIcL 9VeJpEEmfwLhuCcaV0ble77c5uIr4ToKd3F3JMFIneWMrY5xyPEXDu6jUB4zhcGVxyuo 8lyA== MIME-Version: 1.0 Received: by 10.195.13.67 with SMTP id ew3mr44127859wjd.59.1358109559155; Sun, 13 Jan 2013 12:39:19 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sun, 13 Jan 2013 12:39:19 -0800 (PST) In-Reply-To: <20130113171358.GL26039@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> <50EBE936.4000806@FreeBSD.org> <20130113155516.GK26039@alchemy.franken.de> <50F2E57C.1090305@FreeBSD.org> <20130113171358.GL26039@alchemy.franken.de> Date: Sun, 13 Jan 2013 12:39:19 -0800 X-Google-Sender-Auth: F6RBJj2lVJs5eVZLndJQJnaegtU Message-ID: Subject: Re: smartmontools panics 9.1-RELEASE on sunfire 240 From: Adrian Chadd To: Marius Strobl Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Motin , 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, 13 Jan 2013 20:39:20 -0000 whoa, whoa. The kernel panics because you pass in an unaligned buffer, right? :) adrian From owner-freebsd-sparc64@FreeBSD.ORG Sun Jan 13 21:28:46 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 D45116C7; Sun, 13 Jan 2013 21:28:46 +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 A8EBFDB2; Sun, 13 Jan 2013 21:28:46 +0000 (UTC) Received: from [192.168.1.151] (static-71-163-17-12.washdc.fios.verizon.net [71.163.17.12]) (authenticated bits=0) by mail.distal.com (8.14.3/8.14.3) with ESMTP id r0DLSicA026417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 Jan 2013 16:28:45 -0500 (EST) From: Chris Ross Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: ZFS loader crash on sparc64 (since Oct 2012) Date: Sun, 13 Jan 2013 16:28:43 -0500 Message-Id: <4031F492-C30C-4F5D-BF8E-B2D61FFD0EAD@distal.com> To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) 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]); Sun, 13 Jan 2013 16:28:45 -0500 (EST) 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: Sun, 13 Jan 2013 21:28:46 -0000 Since this is a loader crash related to ZFS, someone wisely pointed = out that posting to freebsd-fs might be a good idea. There's a long = thread on the freebsd-sparc64 list about this issue, you can find at: = http://list-archives.org/2012/12/23/freebsd-sparc64-freebsd-org/changes-to= -kern-geom-debugflags/f/4758203564 But, the relevant details are that I determined that stable/9 changed = for sparc64 on October 28, with revision 242230. This was noted as a = merge by avg for revision 241289, and appears to be part of a bunch of = changes he made on October 6 (revs 241282-241294, plus some others = nearby). I'm interested in getting this fixed, so I can build a bootloader that = doesn't cause my sparc64 to hit a divide by zero trap. Please feel free to contact me with any questions about what I found. = (most of it is in the freebsd-sparc64 thread linked to above, but I'm = happy to describe anything unclear or recount from memory.) Thanks! - Chris From owner-freebsd-sparc64@FreeBSD.ORG Sun Jan 13 21:55:35 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 138D03EC; Sun, 13 Jan 2013 21:55:35 +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 9CEB5F11; Sun, 13 Jan 2013 21:55:34 +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 r0DLtWte014615; Sun, 13 Jan 2013 22:55:32 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r0DLtWqL014614; Sun, 13 Jan 2013 22:55:32 +0100 (CET) (envelope-from marius) Date: Sun, 13 Jan 2013 22:55:32 +0100 From: Marius Strobl To: Adrian Chadd Subject: Re: smartmontools panics 9.1-RELEASE on sunfire 240 Message-ID: <20130113215532.GO26039@alchemy.franken.de> References: <20130104235336.GB37999@alchemy.franken.de> <20130105013224.GA31361@pix.net> <20130105015242.GB26039@alchemy.franken.de> <20130106021923.GE1410@funkthat.com> <20130106031245.GC26039@alchemy.franken.de> <50EBE936.4000806@FreeBSD.org> <20130113155516.GK26039@alchemy.franken.de> <50F2E57C.1090305@FreeBSD.org> <20130113171358.GL26039@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexander Motin , 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, 13 Jan 2013 21:55:35 -0000 On Sun, Jan 13, 2013 at 12:39:19PM -0800, Adrian Chadd wrote: > whoa, whoa. > > The kernel panics because you pass in an unaligned buffer, right? :) > Yes. What are you trying to say? Marius From owner-freebsd-sparc64@FreeBSD.ORG Mon Jan 14 11:06:54 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 5B7C64FA for ; Mon, 14 Jan 2013 11:06:54 +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 4A62765A for ; Mon, 14 Jan 2013 11:06:54 +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 r0EB6sxZ086533 for ; Mon, 14 Jan 2013 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0EB6rT6086531 for freebsd-sparc64@FreeBSD.org; Mon, 14 Jan 2013 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Jan 2013 11:06:53 GMT Message-Id: <201301141106.r0EB6rT6086531@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, 14 Jan 2013 11:06:54 -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 Tue Jan 15 02:55:46 2013 Return-Path: Delivered-To: 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 1CBBFBB8; Tue, 15 Jan 2013 02:55:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id BDF51E0D; Tue, 15 Jan 2013 02:55:45 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r0F2tjVd089923; Tue, 15 Jan 2013 02:55:45 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r0F2tj3T089918; Tue, 15 Jan 2013 02:55:45 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 15 Jan 2013 02:55:45 GMT Message-Id: <201301150255.r0F2tj3T089918@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 02:55:46 -0000 TB --- 2013-01-15 01:14:40 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-01-15 01:14:40 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-01-15 01:14:40 - starting RELENG_9 tinderbox run for sparc64/sparc64 TB --- 2013-01-15 01:14:40 - cleaning the object tree TB --- 2013-01-15 01:14:40 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-01-15 01:14:40 - cd /tinderbox/RELENG_9/sparc64/sparc64 TB --- 2013-01-15 01:14:40 - /usr/local/bin/svn cleanup /src TB --- 2013-01-15 01:15:21 - /usr/local/bin/svn update /src TB --- 2013-01-15 01:17:00 - building world TB --- 2013-01-15 01:17:00 - CROSS_BUILD_TESTING=YES TB --- 2013-01-15 01:17:00 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-15 01:17:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-15 01:17:00 - SRCCONF=/dev/null TB --- 2013-01-15 01:17:00 - TARGET=sparc64 TB --- 2013-01-15 01:17:00 - TARGET_ARCH=sparc64 TB --- 2013-01-15 01:17:00 - TZ=UTC TB --- 2013-01-15 01:17:00 - __MAKE_CONF=/dev/null TB --- 2013-01-15 01:17:00 - cd /src TB --- 2013-01-15 01:17:00 - /usr/bin/make -B buildworld >>> World build started on Tue Jan 15 01:17:01 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jan 15 02:48:21 UTC 2013 TB --- 2013-01-15 02:48:21 - generating LINT kernel config TB --- 2013-01-15 02:48:21 - cd /src/sys/sparc64/conf TB --- 2013-01-15 02:48:21 - /usr/bin/make -B LINT TB --- 2013-01-15 02:48:22 - cd /src/sys/sparc64/conf TB --- 2013-01-15 02:48:22 - /usr/sbin/config -m LINT TB --- 2013-01-15 02:48:22 - building LINT kernel TB --- 2013-01-15 02:48:22 - CROSS_BUILD_TESTING=YES TB --- 2013-01-15 02:48:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-15 02:48:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-15 02:48:22 - SRCCONF=/dev/null TB --- 2013-01-15 02:48:22 - TARGET=sparc64 TB --- 2013-01-15 02:48:22 - TARGET_ARCH=sparc64 TB --- 2013-01-15 02:48:22 - TZ=UTC TB --- 2013-01-15 02:48:22 - __MAKE_CONF=/dev/null TB --- 2013-01-15 02:48:22 - cd /src TB --- 2013-01-15 02:48:22 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jan 15 02:48:22 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar9001/ar9160_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar9002/ar9280_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar9002/ar9280_olc.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c: In function 'ar9285Attach': /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: 'ath_hal_EepromDataRead' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ar9002/ar9285_attach.c:144: error: for each function it appears in.) *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-15 02:55:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-15 02:55:44 - ERROR: failed to build LINT kernel TB --- 2013-01-15 02:55:44 - 3851.46 user 610.80 system 6064.34 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Wed Jan 16 01:49:31 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 361CF5A2; Wed, 16 Jan 2013 01:49:31 +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 C7001D58; Wed, 16 Jan 2013 01:49:30 +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 r0G1YTxg030144; Wed, 16 Jan 2013 02:34:29 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r0G1YTge030143; Wed, 16 Jan 2013 02:34:29 +0100 (CET) (envelope-from marius) Date: Wed, 16 Jan 2013 02:34:29 +0100 From: Marius Strobl To: Olivier =?iso-8859-1?Q?Cochard-Labb=E9?= Subject: Re: How to retrieve the "bootpath" variable in a running FreeBSD ? Message-ID: <20130116013429.GA28437@alchemy.franken.de> References: <20130113.075038.471841385206679419.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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: Wed, 16 Jan 2013 01:49:31 -0000 On Sun, Jan 13, 2013 at 01:27:36AM +0100, Olivier Cochard-Labbé wrote: > On Sat, Jan 12, 2013 at 11:50 PM, Hiroki Sato wrote: > > > > Try: > > > > % kenv currdev > > > > Thanks a lot's ! > > Now my eeprom is correctly updated, just a last bug to fix. > After updating the eeprom from FreeBSD I need to issue a cold-reboot > for eeprom changes being applied (poweroff+poweron or "boot" command > in OBP): A simple "reboot" from SSH console is not enough. > I don't know if it's my old Sun Blade 150 that have this problem or if > it's a normal sparc behavior. > Uhm, that's tricky. I haven't implemented that part but AFAICT, the current behavior of rebooting from the previously used bootpath rather than from what is specified via boot-device (now) is on purpose and actually I make heavy use of it. Normally, I boot my machines from disk set via boot-device, except for kernel development which I typically use netbooting for. In order to do so, I interrupt the boot process and boot via `boot net`. It's very convenient that this sticks across reboots until one power cycles the machine or explicitly boots from disk again without having to fiddle with boot-device. The behavior you are asking for can also be implemented but I can't think of a proper logic for determining what to do when boot-device and bootpath disagree and I don't want to get rid of the current one :) If you need that alternate behavior the best way forward seems to be to add a switch for it to reboot(8). Marius From owner-freebsd-sparc64@FreeBSD.ORG Thu Jan 17 16:35:26 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 ACC41AB8 for ; Thu, 17 Jan 2013 16:35:26 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D689BDA5 for ; Thu, 17 Jan 2013 16:35:25 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA14368; Thu, 17 Jan 2013 18:35:19 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TvsQx-0000GS-F2; Thu, 17 Jan 2013 18:35:19 +0200 Message-ID: <50F82846.6030104@FreeBSD.org> Date: Thu, 17 Jan 2013 18:35:18 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Chris Ross Subject: Re: Changes to kern.geom.debugflags? 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> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kurt Lidl , freebsd-sparc64@FreeBSD.org, Marius Strobl 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: Thu, 17 Jan 2013 16:35:26 -0000 on 08/01/2013 03:53 Chris Ross said the following: > > 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) : >> >> 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. > > Out of curiosity, I did try 242229. It boots. So. the problem occurred with 242230, which > came from 241289. FYI. Chris, thank you for triaging and analyzing this problem. And sorry for the long delay (caused by the New Year craziness you mentioned earlier). The problem is that arch_zfs_probe methods are expected only to probe for ZFS disks/partitions, but they are not allowed to execute any other ZFS operations. I assumed this to be true and forgot to check sparc64_zfs_probe. Mea culpa. Could you please test the following patch? Thank you! diff --git a/sys/boot/sparc64/loader/main.c b/sys/boot/sparc64/loader/main.c index fa9d068..06a9f70 100644 --- a/sys/boot/sparc64/loader/main.c +++ b/sys/boot/sparc64/loader/main.c @@ -142,6 +142,10 @@ static vm_offset_t heapva; static char bootpath[64]; static phandle_t root; +#ifdef LOADER_ZFS_SUPPORT +static struct zfs_devdesc zfs_currdev; +#endif + /* * Machine dependent structures that the machine independent * loader part uses. @@ -732,7 +736,6 @@ static void sparc64_zfs_probe(void) { struct vtoc8 vtoc; - struct zfs_devdesc zfs_currdev; char alias[64], devname[sizeof(alias) + sizeof(":x") - 1]; char type[sizeof("device_type")]; char *bdev, *dev, *odev; @@ -805,9 +808,6 @@ sparc64_zfs_probe(void) zfs_currdev.root_guid = 0; zfs_currdev.d_dev = &zfs_dev; zfs_currdev.d_type = zfs_currdev.d_dev->dv_type; - (void)strncpy(bootpath, zfs_fmtdev(&zfs_currdev), - sizeof(bootpath) - 1); - bootpath[sizeof(bootpath) - 1] = '\0'; } } #endif /* LOADER_ZFS_SUPPORT */ @@ -878,6 +878,14 @@ main(int (*openfirm)(void *)) if ((*dp)->dv_init != 0) (*dp)->dv_init(); +#ifdef LOADER_ZFS_SUPPORT + if (zfs_currdev.pool_guid != 0) { + (void)strncpy(bootpath, zfs_fmtdev(&zfs_currdev), + sizeof(bootpath) - 1); + bootpath[sizeof(bootpath) - 1] = '\0'; + } +#endif + /* * Now that sparc64_zfs_probe() might have altered bootpath, * export it. -- Andriy Gapon From owner-freebsd-sparc64@FreeBSD.ORG Fri Jan 18 00:49:29 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 5149F779; Fri, 18 Jan 2013 00:49:29 +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 E2D8A8C; Fri, 18 Jan 2013 00:49:28 +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 r0I0nPuC014155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Jan 2013 19:49:25 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Changes to kern.geom.debugflags? From: Chris Ross In-Reply-To: <50F82846.6030104@FreeBSD.org> Date: Thu, 17 Jan 2013 19:49:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <315EDE17-4995-4819-BC82-E9B7D942E82A@distal.com> 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> <50F82846.6030104@FreeBSD.org> To: Andriy Gapon 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]); Thu, 17 Jan 2013 19:49:26 -0500 (EST) Cc: "freebsd-fs@freebsd.org" , Kurt Lidl , "freebsd-sparc64@freebsd.org" , Marius Strobl 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: Fri, 18 Jan 2013 00:49:29 -0000 On Jan 17, 2013, at 11:35 , Andriy Gapon wrote: > on 08/01/2013 03:53 Chris Ross said the following: >>=20 >> Out of curiosity, I did try 242229. It boots. So. the problem = occurred with 242230, which=20 >> came from 241289. FYI. >=20 > Chris, >=20 > thank you for triaging and analyzing this problem. And sorry for the = long delay > (caused by the New Year craziness you mentioned earlier). >=20 > The problem is that arch_zfs_probe methods are expected only to probe = for ZFS > disks/partitions, but they are not allowed to execute any other ZFS = operations. > I assumed this to be true and forgot to check sparc64_zfs_probe. Mea = culpa. >=20 > Could you please test the following patch? Thank you, Andriy. Much as you'd expect, that patch solves the = problem. I get some of the printf()s that I'd put into zfs_fmtdev(), and the system loads = successfully. Please commit that patch, and if you could, change the comment just = below the last portion of it that is now not quite accurate (since you moved mentioned = code). Thanks again! How long will this take to get to stable/9? Being new = to FreeBSD, I'm not too familiar with the process of HEAD/stable/etc. (In NetBSD, = it would be a commit followed by a pull request.) - Chris