From owner-freebsd-sparc64@FreeBSD.ORG Sun Dec 9 18:50:22 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E13B3350 for ; Sun, 9 Dec 2012 18:50:22 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A27E48FC1A for ; Sun, 9 Dec 2012 18:50:22 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so1412105pbc.13 for ; Sun, 09 Dec 2012 10:50:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type:x-gm-message-state; bh=5fWgylGiq8F/xIkEEo08py/KPhxFu2c4EOHYYrQz/mc=; b=nHSnrHfRepo1zGAYTWC0vkxQfFbvn8VBz6ytvHDoX1dJEpLj8mpaq+L8cDHkG4RFus t75eZCA6vQAY+HG7Lss+sQjBWwhoCDq5ItU4c03vqi4SnY2QEGRcOSWGcSAAXOddsXAU S6AeE5gMPk4daUxqq8QR+qbYIl0h828bjFVeoofdKj4+A/u+cKoUsXm3eWbqZPWhE+dW 6onSOSJaHe7yYDds4o0wCxruq8v0qdambELX1GL/sEf/ZZ76wBxzebexGuS33gXizJT6 gWeStohACfdyXQBTE4+bA4HIA9sXzjQpbvdr81ICfE5XEU6oxFAtGlmkUl2zxw8eeM7m nvLQ== Received: by 10.66.84.10 with SMTP id u10mr30029217pay.24.1355079021836; Sun, 09 Dec 2012 10:50:21 -0800 (PST) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by mx.google.com with ESMTPS id m4sm10436372pav.17.2012.12.09.10.50.19 (version=SSLv3 cipher=OTHER); Sun, 09 Dec 2012 10:50:21 -0800 (PST) Date: Sun, 9 Dec 2012 08:48:51 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Ian Lepore Subject: Re: Call for testing and review, busdma changes In-Reply-To: <1355077061.87661.320.camel@revolution.hippie.lan> Message-ID: References: <1355077061.87661.320.camel@revolution.hippie.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQn0bXTG6a9s759roJTRuxZV2aVxAjviWIQWGf5tyB6ICNOQjxVnwDht7iXfLB56PFtDKkRS X-Mailman-Approved-At: Mon, 10 Dec 2012 00:22:09 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, kib@freebsd.org, sparc64@freebsd.org, arm@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, 09 Dec 2012 18:50:22 -0000 On Sun, 9 Dec 2012, Ian Lepore wrote: > On Sat, 2012-12-08 at 08:51 -1000, Jeff Roberson wrote: >> Hello, >> >> http://people.freebsd.org/~jeff/physbio.diff >> >> I have a relative large patch that reforms the busdma API so that new >> types may be added without modifying every architecture's >> busdma_machdep.c. It does this by unifying the bus_dmamap_load_buffer() >> routines so that they may be called from MI code. The MD busdma is then >> given a chance to do any final processing in the complete() callback. >> This patch also contains cam changes to unify the bus_dmamap_load* >> handling in cam drivers. >> >> The arm and mips implementations saw the largest changes since they have >> to track virtual addresses for sync(). Previously this was done in a type >> specific way. Now it is done in a generic way by recording the list of >> virtuals in the map. >> >> I have verified that this patch passes make universe which includes >> several kernel builds from each architecture. I suspect that if I broke >> anything your machine simply won't boot or will throw I/O errors. There >> is little subtlety, it is mostly refactoring. >> > > Testing on armv4/v5 platforms, the patches applied and compiled cleanly, > but fault-abort with a NULL deref on what appears to be the first call > to bus_dmamap_load(). I'll dig deeper into debugging that after > browsing the new code so I can figure out where to start debugging. Can you give me the file and line of the fault? > > Just from an initial quick browsing of the new code for armv4, I notice > these things... > > The new routine __bus_dmamap_mayblock() does (*flags) |= BUS_DMA_WAITOK; > which is a no-op because BUS_DMA_WAITOK is zero. I'm not sure what the > intent was, but I think any modification of the WAIT-related flags would > be conceptually wrong because it overrides the caller's instructions on > whether or not to do a deferred load when resources aren't available. The intent of the original load function seems to be that it is always blocking. Most architectures force the flag. The mbuf and uio load routines don't support blocking at all because the callback lacks the information needed to restart the operation. > > The way you've refactored the mbuf-related load routines, the MD code is > no longer able to tell that it's an mbuf operation. This comes back to > what I said a few days ago... when you look at the current code on > various platforms you see a lot of false similarities. The code isn't > nearly identical because it really all needs to be the same, it's > because it was all copied from the same source, and it doesn't currently > work correctly on arm and mips. With your changes, the ability to > correct the implementation on those platforms is now gone. Perhaps this > can be fixed easily by defining some new flags that the MI routines can > OR-in to give the MD routines more info on what's happening. (Correcting > the mbuf sync handling on arm and mips requires that we know at sync > time that the buffers involved are mbufs, which means we need to know at > map-load time so we can set a flag or a type code or something in the > map that we can examine at sync time.) Why do you need to know it is an mbuf if you have a record of the virtual addresses? The only type specific information was used to find the addresses. See how arm's busdma_machdep-v6 ws implemented. > >> The next step is to allow for dma loading of physical addresses. This >> will permit unmapped I/O. Which is a significant performance optimization >> targeted for 10.0. > > This sounds scary for arm and mips, or more specifically for VIVT cache > platforms that can only do a sync based on virtual addresses. Can you > talk some more about the plans for this? It will be for addresses which were never mapped into kva. To support unmaapped io. There will only be a need for bounce pages, no syncing. Jeff > > -- Ian > > From owner-freebsd-sparc64@FreeBSD.ORG Sun Dec 9 20:34:55 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1EEC849E; Sun, 9 Dec 2012 20:34:55 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id B46EA8FC13; Sun, 9 Dec 2012 20:34:42 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qB9KYZtS016544; Sun, 9 Dec 2012 13:34:41 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qB9KYAou053413; Sun, 9 Dec 2012 13:34:10 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Call for testing and review, busdma changes From: Ian Lepore To: Jeff Roberson In-Reply-To: References: <1355077061.87661.320.camel@revolution.hippie.lan> Content-Type: multipart/mixed; boundary="=-jWdke4I5Nd/QjDc9IHG8" Date: Sun, 09 Dec 2012 13:34:10 -0700 Message-ID: <1355085250.87661.345.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-Mailman-Approved-At: Mon, 10 Dec 2012 00:22:09 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, kib@freebsd.org, sparc64@freebsd.org, arm@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, 09 Dec 2012 20:34:55 -0000 --=-jWdke4I5Nd/QjDc9IHG8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sun, 2012-12-09 at 08:48 -1000, Jeff Roberson wrote: > > On Sun, 9 Dec 2012, Ian Lepore wrote: > > > On Sat, 2012-12-08 at 08:51 -1000, Jeff Roberson wrote: > >> Hello, > >> > >> http://people.freebsd.org/~jeff/physbio.diff > >> > >> I have a relative large patch that reforms the busdma API so that new > >> types may be added without modifying every architecture's > >> busdma_machdep.c. It does this by unifying the bus_dmamap_load_buffer() > >> routines so that they may be called from MI code. The MD busdma is then > >> given a chance to do any final processing in the complete() callback. > >> This patch also contains cam changes to unify the bus_dmamap_load* > >> handling in cam drivers. > >> > >> The arm and mips implementations saw the largest changes since they have > >> to track virtual addresses for sync(). Previously this was done in a type > >> specific way. Now it is done in a generic way by recording the list of > >> virtuals in the map. > >> > >> I have verified that this patch passes make universe which includes > >> several kernel builds from each architecture. I suspect that if I broke > >> anything your machine simply won't boot or will throw I/O errors. There > >> is little subtlety, it is mostly refactoring. > >> First an FYI, my replies to this thread aren't making it to the mailing lists, except when quoted by someone replying to them. They're being held for moderator approval because they're going to too many addresses. > > > > Testing on armv4/v5 platforms, the patches applied and compiled cleanly, > > but fault-abort with a NULL deref on what appears to be the first call > > to bus_dmamap_load(). I'll dig deeper into debugging that after > > browsing the new code so I can figure out where to start debugging. > > Can you give me the file and line of the fault? > Better than that, I can give you patches (attached). There were two little glitches... the allocated slist wasn't getting attached to the map, and when building the slist in _bus_dmamap_load_buffer() the slist needs to participate in the coalescing logic near the end of the loop. I'm not positive the attached quick-fix is perfect, but it allows one of my arm units here to boot and run and pass some basic IO smoke tests. I'll be trying it on other arm platforms later today. > > > > Just from an initial quick browsing of the new code for armv4, I notice > > these things... > > > > The new routine __bus_dmamap_mayblock() does (*flags) |= BUS_DMA_WAITOK; > > which is a no-op because BUS_DMA_WAITOK is zero. I'm not sure what the > > intent was, but I think any modification of the WAIT-related flags would > > be conceptually wrong because it overrides the caller's instructions on > > whether or not to do a deferred load when resources aren't available. > > The intent of the original load function seems to be that it is always > blocking. Most architectures force the flag. The mbuf and uio load > routines don't support blocking at all because the callback lacks the > information needed to restart the operation. > The manpage states that bus_dmamap_load() never blocks for any reason. The mbuf and uio flavors say they are variations of bus_dmapmap_load(); I take the implication of that to mean that they also are defined as never blocking. The docs then say that WAITOK vs. NOWAIT control the scheduling of a deferred load, and that NOWAIT is forced in the mbuf and uio cases. Your refactored code already handles that by adding NOWAIT to the caller-specified flags for mbufs and uio. So the code will do the right thing now (with your patches), but only because (*flags) |= BUS_DMA_WAITOK is a no-op. > > > > The way you've refactored the mbuf-related load routines, the MD code is > > no longer able to tell that it's an mbuf operation. This comes back to > > what I said a few days ago... when you look at the current code on > > various platforms you see a lot of false similarities. The code isn't > > nearly identical because it really all needs to be the same, it's > > because it was all copied from the same source, and it doesn't currently > > work correctly on arm and mips. With your changes, the ability to > > correct the implementation on those platforms is now gone. Perhaps this > > can be fixed easily by defining some new flags that the MI routines can > > OR-in to give the MD routines more info on what's happening. (Correcting > > the mbuf sync handling on arm and mips requires that we know at sync > > time that the buffers involved are mbufs, which means we need to know at > > map-load time so we can set a flag or a type code or something in the > > map that we can examine at sync time.) > > Why do you need to know it is an mbuf if you have a record of the virtual > addresses? The only type specific information was used to find the > addresses. See how arm's busdma_machdep-v6 ws implemented. > Because there is a special rule for mbufs on VIVT-cache architectures: the address of the data buffer is not aligned to a cacheline boundary, but the sync code is allowed to treat the buffer as if it is aligned and thus avoid invoking the partial cacheline flush algorithm. That algorithm was shown a few months ago to be fatally flawed, and we're on a path (albeit in super-slow-motion) to eliminate it. I have patches to fix the mbuf partial sync and other things related to partial sync problems, and my next step will be to try to rework them to fit in with what you've done. Based on what I've seen so far in your refactoring, I think just passing a flag to say it's an mbuf, from the MI to the MD mapping routine, will provide enough info. > > > >> The next step is to allow for dma loading of physical addresses. This > >> will permit unmapped I/O. Which is a significant performance optimization > >> targeted for 10.0. > > > > This sounds scary for arm and mips, or more specifically for VIVT cache > > platforms that can only do a sync based on virtual addresses. Can you > > talk some more about the plans for this? > > It will be for addresses which were never mapped into kva. To support > unmaapped io. There will only be a need for bounce pages, no syncing. > Can the pages be mapped into any non-kernel vmspaces? If they aren't mapped into any vmspace at all, then I think there'll be no implications for VIVT cache architectures. If they appear in any pmap at all then there may be problems. -- Ian --=-jWdke4I5Nd/QjDc9IHG8 Content-Disposition: inline; filename="physbio_armv4fix.diff" Content-Type: text/x-patch; name="physbio_armv4fix.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit diff -r bee560bf0159 sys/arm/arm/busdma_machdep.c --- a/sys/arm/arm/busdma_machdep.c Sun Dec 09 12:12:11 2012 -0700 +++ b/sys/arm/arm/busdma_machdep.c Sun Dec 09 13:01:12 2012 -0700 @@ -310,9 +310,10 @@ static __inline bus_dmamap_t map->flags = DMAMAP_ALLOCATED; } else map->flags = 0; - if (map != NULL) + if (map != NULL) { STAILQ_INIT(&map->bpages); - else + map->slist = slist; + } else free(slist, M_DEVBUF); return (map); } @@ -764,7 +765,6 @@ int { bus_size_t sgsize; bus_addr_t curaddr, baddr, bmask; - struct sync_list *sl; vm_offset_t vaddr = (vm_offset_t)buf; int seg; int error = 0; @@ -855,14 +855,6 @@ int if (((dmat->flags & BUS_DMA_COULD_BOUNCE) != 0) && map->pagesneeded != 0 && run_filter(dmat, curaddr)) { curaddr = add_bounce_page(dmat, map, vaddr, sgsize); - } else { - sl = &map->slist[map->sync_count]; - if (++map->sync_count > dmat->nsegments) - goto cleanup; - printf("sl %p count %d nseg %d\n", sl, map->sync_count, dmat->nsegments); - sl->vaddr = vaddr; - sl->datacount = sgsize; - sl->busaddr = curaddr; } if (dmat->ranges) { @@ -891,10 +883,15 @@ int (segs[seg].ds_addr & bmask) == (curaddr & bmask))) { segs[seg].ds_len += sgsize; + map->slist[seg].datacount += sgsize; goto segdone; } else { if (++seg >= dmat->nsegments) break; + ++map->sync_count; + map->slist[seg].vaddr = vaddr; + map->slist[seg].busaddr = curaddr; + map->slist[seg].datacount = sgsize; segs[seg].ds_addr = curaddr; segs[seg].ds_len = sgsize; } @@ -906,7 +903,6 @@ segdone: } *segp = seg; -cleanup: /* * Did we fit? */ --=-jWdke4I5Nd/QjDc9IHG8-- From owner-freebsd-sparc64@FreeBSD.ORG Sun Dec 9 18:18:31 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7377D882; Sun, 9 Dec 2012 18:18:31 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id E5AC38FC12; Sun, 9 Dec 2012 18:18:18 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qB9II553012970; Sun, 9 Dec 2012 11:18:11 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qB9IHfHu053325; Sun, 9 Dec 2012 11:17:41 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Call for testing and review, busdma changes From: Ian Lepore To: Jeff Roberson In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Sun, 09 Dec 2012 11:17:41 -0700 Message-ID: <1355077061.87661.320.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 10 Dec 2012 00:29:15 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, kib@freebsd.org, sparc64@freebsd.org, arm@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, 09 Dec 2012 18:18:31 -0000 On Sat, 2012-12-08 at 08:51 -1000, Jeff Roberson wrote: > Hello, > > http://people.freebsd.org/~jeff/physbio.diff > > I have a relative large patch that reforms the busdma API so that new > types may be added without modifying every architecture's > busdma_machdep.c. It does this by unifying the bus_dmamap_load_buffer() > routines so that they may be called from MI code. The MD busdma is then > given a chance to do any final processing in the complete() callback. > This patch also contains cam changes to unify the bus_dmamap_load* > handling in cam drivers. > > The arm and mips implementations saw the largest changes since they have > to track virtual addresses for sync(). Previously this was done in a type > specific way. Now it is done in a generic way by recording the list of > virtuals in the map. > > I have verified that this patch passes make universe which includes > several kernel builds from each architecture. I suspect that if I broke > anything your machine simply won't boot or will throw I/O errors. There > is little subtlety, it is mostly refactoring. > Testing on armv4/v5 platforms, the patches applied and compiled cleanly, but fault-abort with a NULL deref on what appears to be the first call to bus_dmamap_load(). I'll dig deeper into debugging that after browsing the new code so I can figure out where to start debugging. Just from an initial quick browsing of the new code for armv4, I notice these things... The new routine __bus_dmamap_mayblock() does (*flags) |= BUS_DMA_WAITOK; which is a no-op because BUS_DMA_WAITOK is zero. I'm not sure what the intent was, but I think any modification of the WAIT-related flags would be conceptually wrong because it overrides the caller's instructions on whether or not to do a deferred load when resources aren't available. The way you've refactored the mbuf-related load routines, the MD code is no longer able to tell that it's an mbuf operation. This comes back to what I said a few days ago... when you look at the current code on various platforms you see a lot of false similarities. The code isn't nearly identical because it really all needs to be the same, it's because it was all copied from the same source, and it doesn't currently work correctly on arm and mips. With your changes, the ability to correct the implementation on those platforms is now gone. Perhaps this can be fixed easily by defining some new flags that the MI routines can OR-in to give the MD routines more info on what's happening. (Correcting the mbuf sync handling on arm and mips requires that we know at sync time that the buffers involved are mbufs, which means we need to know at map-load time so we can set a flag or a type code or something in the map that we can examine at sync time.) > The next step is to allow for dma loading of physical addresses. This > will permit unmapped I/O. Which is a significant performance optimization > targeted for 10.0. This sounds scary for arm and mips, or more specifically for VIVT cache platforms that can only do a sync based on virtual addresses. Can you talk some more about the plans for this? -- Ian From owner-freebsd-sparc64@FreeBSD.ORG Mon Dec 10 00:54:18 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2BA632D4 for ; Mon, 10 Dec 2012 00:54:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by mx1.freebsd.org (Postfix) with ESMTP id CF9558FC15 for ; Mon, 10 Dec 2012 00:54:17 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id c10so6671540ieb.25 for ; Sun, 09 Dec 2012 16:54:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=NQ/SFUzHRS12x8NX6tNgjKotHD2QRO5QpoGfvtwLETk=; b=I3SdWPQ9R4fmC24MHXPi6ZPJmhwiXpOXmWj3Ytx4dwEmjc5bRkGUI4YkeUOF2J0ZeK H2d2aIAJzogiKr+BsFTTpcvaKDWZpE9+ilRlRVulLqhAz+Ofdq2WR4zT+Cp4HtQm99pe LMQxcdRCRp09r+TnjqfAQZ/o4krtVy+AUqH57BgBMvdjMm379h383/KOkVQeRahh4z4S 3LYij0PNzlSMxivEz0htf9/rbqFfjFtrIWkdGelEulqB/dHtH5E8Fwg3V+fVzsHXOm8K UJ+xY2IAVZByMoR3ZRTEGVqm6gXBsxmffCaas8cclqNPD02IpcELBrR5HM5Lpz4ZUqgx 5sZg== Received: by 10.50.157.130 with SMTP id wm2mr7911478igb.0.1355100851225; Sun, 09 Dec 2012 16:54:11 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id l8sm5263808igo.13.2012.12.09.16.54.08 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 09 Dec 2012 16:54:10 -0800 (PST) Sender: Warner Losh Subject: Re: Call for testing and review, busdma changes Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 9 Dec 2012 17:54:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1355077061.87661.320.camel@revolution.hippie.lan> To: Jeff Roberson X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmNXpDhqBYlIimCcNdY+8rv8WudwDbyvrzo6FGW0rnZLODzgA/BUbNAdeZYNz3JpPXF2qUV X-Mailman-Approved-At: Mon, 10 Dec 2012 01:02:09 +0000 Cc: Ian Lepore , powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, kib@freebsd.org, sparc64@freebsd.org, arm@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, 10 Dec 2012 00:54:18 -0000 [[ looks like Ian answered the other questions ]] On Dec 9, 2012, at 11:48 AM, Jeff Roberson wrote: >>> The next step is to allow for dma loading of physical addresses. = This >>> will permit unmapped I/O. Which is a significant performance = optimization >>> targeted for 10.0. >>=20 >> This sounds scary for arm and mips, or more specifically for VIVT = cache >> platforms that can only do a sync based on virtual addresses. Can = you >> talk some more about the plans for this? >=20 > It will be for addresses which were never mapped into kva. To support = unmaapped io. There will only be a need for bounce pages, no syncing. If there's a virtual mapping at all for the page (not just a kva), then = we need to flush/invalidate cache for those pages for safety unless we = know for sure there's nothing in the cache. It these are pages that = have never been mapped (say for zero copy between storage and network = controllers), then there won't be a problem. The whole reason for cache = jockeying is to make sure that any pending writes to the data are = flushed, and that any cached notion of the pages are invalidated once = the read is done. This is more important for mbuf operations, = operations with the USB stack or anything else that marshals data it = generates to be consumed by the stack/hardware. Warner From owner-freebsd-sparc64@FreeBSD.ORG Mon Dec 10 11:06:51 2012 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3AE53F97 for ; Mon, 10 Dec 2012 11:06:51 +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 1EE898FC15 for ; Mon, 10 Dec 2012 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qBAB6poS064382 for ; Mon, 10 Dec 2012 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBAB6o3v064380 for freebsd-sparc64@FreeBSD.org; Mon, 10 Dec 2012 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Dec 2012 11:06:50 GMT Message-Id: <201212101106.qBAB6o3v064380@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, 10 Dec 2012 11:06:51 -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 Dec 11 05:24:14 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF9B5F6B; Tue, 11 Dec 2012 05:24:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id AA0CD8FC0C; Tue, 11 Dec 2012 05:24:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qBB5ODq0017512; Tue, 11 Dec 2012 00:24:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBB5ODLh017507; Tue, 11 Dec 2012 05:24:13 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 11 Dec 2012 05:24:13 GMT Message-Id: <201212110524.qBB5ODLh017507@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head 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, 11 Dec 2012 05:24:15 -0000 TB --- 2012-12-11 04:09:25 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-11 04:09:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-11 04:09:25 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-12-11 04:09:25 - cleaning the object tree TB --- 2012-12-11 04:09:25 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-11 04:09:25 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2012-12-11 04:09:25 - /usr/local/bin/svn cleanup /src TB --- 2012-12-11 04:11:32 - /usr/local/bin/svn update /src TB --- 2012-12-11 04:11:39 - At svn revision 244108 TB --- 2012-12-11 04:11:40 - building world TB --- 2012-12-11 04:11:40 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 04:11:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 04:11:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 04:11:40 - SRCCONF=/dev/null TB --- 2012-12-11 04:11:40 - TARGET=sparc64 TB --- 2012-12-11 04:11:40 - TARGET_ARCH=sparc64 TB --- 2012-12-11 04:11:40 - TZ=UTC TB --- 2012-12-11 04:11:40 - __MAKE_CONF=/dev/null TB --- 2012-12-11 04:11:40 - cd /src TB --- 2012-12-11 04:11:40 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Dec 11 04:11:46 UTC 2012 >>> 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 Dec 11 05:13:53 UTC 2012 TB --- 2012-12-11 05:13:53 - generating LINT kernel config TB --- 2012-12-11 05:13:53 - cd /src/sys/sparc64/conf TB --- 2012-12-11 05:13:53 - /usr/bin/make -B LINT TB --- 2012-12-11 05:13:53 - cd /src/sys/sparc64/conf TB --- 2012-12-11 05:13:53 - /usr/sbin/config -m LINT TB --- 2012-12-11 05:13:53 - building LINT kernel TB --- 2012-12-11 05:13:53 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 05:13:53 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 05:13:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 05:13:53 - SRCCONF=/dev/null TB --- 2012-12-11 05:13:53 - TARGET=sparc64 TB --- 2012-12-11 05:13:53 - TARGET_ARCH=sparc64 TB --- 2012-12-11 05:13:53 - TZ=UTC TB --- 2012-12-11 05:13:53 - __MAKE_CONF=/dev/null TB --- 2012-12-11 05:13:53 - cd /src TB --- 2012-12-11 05:13:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 11 05:13:53 UTC 2012 >>> 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/kern/subr_trap.c 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/kern/subr_turnstile.c 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/kern/subr_uio.c 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/kern/subr_unit.c 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/kern/subr_witness.c cc1: warnings being treated as errors /src/sys/kern/subr_witness.c: In function 'witness_assert': /src/sys/kern/subr_witness.c:2253: warning: 'instance' may be used uninitialized in this function *** [subr_witness.o] Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-11 05:24:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-11 05:24:13 - ERROR: failed to build LINT kernel TB --- 2012-12-11 05:24:13 - 3586.73 user 597.80 system 4488.23 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Tue Dec 11 06:39:34 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B262681A; Tue, 11 Dec 2012 06:39:34 +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 7209D8FC08; Tue, 11 Dec 2012 06:39:34 +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 qBB6dX2k020755; Tue, 11 Dec 2012 06:39:33 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id qBB6dX8C020754; Tue, 11 Dec 2012 06:39:33 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 11 Dec 2012 06:39:33 GMT Message-Id: <201212110639.qBB6dX8C020754@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, 11 Dec 2012 06:39:34 -0000 TB --- 2012-12-11 06:00:45 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-12-11 06:00:45 - 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 --- 2012-12-11 06:00:45 - starting RELENG_9 tinderbox run for sparc64/sparc64 TB --- 2012-12-11 06:00:45 - cleaning the object tree TB --- 2012-12-11 06:00:45 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2012-12-11 06:00:45 - cd /tinderbox/RELENG_9/sparc64/sparc64 TB --- 2012-12-11 06:00:45 - /usr/local/bin/svn cleanup /src TB --- 2012-12-11 06:01:26 - /usr/local/bin/svn update /src TB --- 2012-12-11 06:01:34 - At svn revision 244111 TB --- 2012-12-11 06:01:35 - building world TB --- 2012-12-11 06:01:35 - CROSS_BUILD_TESTING=YES TB --- 2012-12-11 06:01:35 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-11 06:01:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-11 06:01:35 - SRCCONF=/dev/null TB --- 2012-12-11 06:01:35 - TARGET=sparc64 TB --- 2012-12-11 06:01:35 - TARGET_ARCH=sparc64 TB --- 2012-12-11 06:01:35 - TZ=UTC TB --- 2012-12-11 06:01:35 - __MAKE_CONF=/dev/null TB --- 2012-12-11 06:01:35 - cd /src TB --- 2012-12-11 06:01:35 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 11 06:01:36 UTC 2012 >>> 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 [...] ===> bin/expr (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c expr.c cc1: warnings being treated as errors /src/bin/expr/expr.y: In function 'main': /src/bin/expr/expr.y:291: warning: implicit declaration of function 'yyparse' /src/bin/expr/expr.y:291: warning: nested extern declaration of 'yyparse' expr.c: At top level: expr.c:813: warning: no previous prototype for 'yyparse' *** Error code 1 Stop in /src/bin/expr. *** Error code 1 Stop in /src/bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-11 06:39:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-11 06:39:33 - ERROR: failed to build world TB --- 2012-12-11 06:39:33 - 1743.67 user 335.81 system 2328.51 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Thu Dec 13 10:05:18 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4517B435 for ; Thu, 13 Dec 2012 10:05:18 +0000 (UTC) (envelope-from matpockuh@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id BA4788FC15 for ; Thu, 13 Dec 2012 10:05:17 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id je9so882897bkc.13 for ; Thu, 13 Dec 2012 02:05:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CBKEgX6cTyuTg8h2jU0jwfq7ntRDXlesb6nFcbHePNI=; b=wk7hONrZlcT11h8YtJr5l+RATeQ9VntbANo/K+eK2pG2iOlEVRzGbXwzSu7MExpEBz 9QyBUZgsNgGY9+402/JMnjYf8lOlFIX44MQa/gavaqfjLxn3oArDHFzuPKKZqHLs6lkB y+4wT2HDrI3RoDZRh3owkOjot9/RoM+vy4gTEkvaCqLS28Qhre2j+tBMNQr9xf7VDmLa WDG4QfteFo+67GFTpC+AvOc9f1/Z9jj5JuzXJxEPSVc/wHr5kknEbKP9LN/Oo6zg1pDh gi7a4pfc1HjR9DjMCME+j/EMWs7ae0FJXhJpQ66xb6F8bzhgLTUWIutBtVxSG9CW7yJT Me1w== MIME-Version: 1.0 Received: by 10.204.5.205 with SMTP id 13mr679842bkw.111.1355393116577; Thu, 13 Dec 2012 02:05:16 -0800 (PST) Received: by 10.205.107.69 with HTTP; Thu, 13 Dec 2012 02:05:16 -0800 (PST) In-Reply-To: <20120730113015.GA14735@alchemy.franken.de> References: <20120708025435.GA12487@pix.net> <20120709140019.GA67276@alchemy.franken.de> <20120710165433.GA98707@pix.net> <20120712172208.GA47484@pix.net> <20120713195807.GU63893@alchemy.franken.de> <20120714004335.GD92944@pix.net> <20120727182558.GH58433@alchemy.franken.de> <20120730113015.GA14735@alchemy.franken.de> Date: Thu, 13 Dec 2012 13:05:16 +0300 Message-ID: Subject: Re: zfs booting feedback From: KOT MATPOCKuH To: Marius Strobl 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: Thu, 13 Dec 2012 10:05:18 -0000 Good morning! I builded world/kernel from stable/9 r244121, installed zfsboot and zfsloader to disk on Sun Fire V240 with OpenBoot 4.30.4.a. But boot fails with: Rebooting with command: boot disk Boot device: /pci@1c,600000/scsi@2/disk@0,0 File and args: >> FreeBSD/sparc64 ZFS boot block Boot path: /pci@1c,600000/scsi@2/disk@0,0:a Consoles: Open Firmware console ERROR: Last Trap: Division by Zero Also I tried zfsloader builded from sources @ may 2012: (same zfsboot, but used zfsloader.old) Boot device: disk File and args: >> FreeBSD/sparc64 ZFS boot block Boot path: /pci@1c,600000/scsi@2/disk@0,0:a Consoles: Open Firmware console ofwd_open: Could not open disk1: ofwd_open: Could not open disk2: ofwd_open: Could not open disk3: FreeBSD/sparc64 ZFS enabled bootstrap loader, Revision 1.0 (root@sunspot, Fri Nov 2 08:59:22 MSK 2012) bootpath="/pci@1c,600000/scsi@2/disk@0,0:a" ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable can't load 'kernel' What's wrong? Could it a result of crosscompiling? PS. When writing both zfsloader I got "Invalid argument" message: # dd if=/boot/zfsloader.old of=/dev/da0a bs=512 oseek=1024 dd: /dev/da0a: Invalid argument 470+1 records in 470+0 records out 240640 bytes transferred in 1.915555 secs (125624 bytes/sec) Is it okey? -- MATPOCKuH