Re: svn commit: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/e
In message <201812090645.wb96jnso066...@repo.freebsd.org>, Cy Schubert writes: > Author: cy > Date: Sun Dec 9 06:45:49 2018 > New Revision: 341759 > URL: https://svnweb.freebsd.org/changeset/base/341759 > > Log: > MFV r341618: > > Update wpa 2.6 --> 2.7. In order to build this cleanly, artifacts from wpa 2.6 need to be removed first. Either build using a clean /usr/obj or if building using -DNO_CLEAN, rm -rf /usr/obj/opt/src/svn-current/*/usr.sbin/wpa first. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r341765 - head/sys/dev/md
Author: bde
Date: Sun Dec 9 15:34:20 2018
New Revision: 341765
URL: https://svnweb.freebsd.org/changeset/base/341765
Log:
Fix devstat on md devices.
devstat_end_transaction() was called before the i/o was actually ended
(by delivering it to GEOM), so at least the i/o length was messed up.
It was always recorded as 0, so the average transaction size and the
average transfer rate was always displayed as 0.
devstat_end_transaction() was not called at all for the error case, so
there were sometimes multiple starts per end. I didn't observe this in
practice and don't know if it did much damage. I think it extended the
length of the i/o to the next transaction.
Reviewed by: kib
Modified:
head/sys/dev/md/md.c
Modified: head/sys/dev/md/md.c
==
--- head/sys/dev/md/md.cSun Dec 9 11:39:45 2018(r341764)
+++ head/sys/dev/md/md.cSun Dec 9 15:34:20 2018(r341765)
@@ -1241,10 +1241,10 @@ md_kthread(void *arg)
if (error != -1) {
bp->bio_completed = bp->bio_length;
- if ((bp->bio_cmd == BIO_READ) || (bp->bio_cmd ==
BIO_WRITE))
- devstat_end_transaction_bio(sc->devstat, bp);
g_io_deliver(bp, error);
}
+ if (bp->bio_cmd == BIO_READ || bp->bio_cmd == BIO_WRITE)
+ devstat_end_transaction_bio(sc->devstat, bp);
}
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r341766 - head/sys/kern
Author: alc
Date: Sun Dec 9 17:55:10 2018
New Revision: 341766
URL: https://svnweb.freebsd.org/changeset/base/341766
Log:
blst_leaf_alloc updates bighint for a leaf when an allocation is successful
and includes the last block represented by the leaf. The reasoning is that,
if the last block is included, then there must be no solution before that
one in the leaf, so the leaf cannot provide an allocation that big again;
indeed, the leaf cannot provide a solution bigger than range1.
Which is all correct, except that if the value of blk passed in did not
represent the first block of the leaf, because the cursor was pointing to
the middle of the leaf, then a possible solution before the cursor may have
been ignored, and bighint cannot be updated.
Consider the sequence allocate 63 (returning address 0), free 0,63 (freeing
that same block, and allocate 1 (returning 63). The result is that one
block is allocated from the first leaf, and the value of bighint is 0, so
that nothing can be allocated from that leaf until the only block allocated
from that leaf is freed. This change detects that skipped-over solution,
and when there is one it makes sure that the value of bighint is not changed
when the last block is allocated.
Submitted by: Doug Moore
Tested by:pho
X-MFC with: r340402
Differential Revision:https://reviews.freebsd.org/D18474
Modified:
head/sys/kern/subr_blist.c
Modified: head/sys/kern/subr_blist.c
==
--- head/sys/kern/subr_blist.c Sun Dec 9 15:34:20 2018(r341765)
+++ head/sys/kern/subr_blist.c Sun Dec 9 17:55:10 2018(r341766)
@@ -644,14 +644,14 @@ blst_next_leaf_alloc(blmeta_t *scan, daddr_t blk, int
/*
* BLST_LEAF_ALLOC() - allocate at a leaf in the radix tree (a bitmap).
*
- * This is the core of the allocator and is optimized for the
- * BLIST_BMAP_RADIX block allocation case. Otherwise, execution
- * time is proportional to log2(count) + bitpos time.
+ * This function is the core of the allocator. Its execution time is
+ * proportional to log(count), plus height of the tree if the allocation
+ * crosses a leaf boundary.
*/
static daddr_t
blst_leaf_alloc(blmeta_t *scan, daddr_t blk, int count)
{
- u_daddr_t mask;
+ u_daddr_t cursor_mask, mask;
int count1, hi, lo, num_shifts, range1, range_ext;
range1 = 0;
@@ -661,14 +661,14 @@ blst_leaf_alloc(blmeta_t *scan, daddr_t blk, int count
while ((-mask & ~mask) != 0 && num_shifts > 0) {
/*
* If bit i is set in mask, then bits in [i, i+range1] are set
-* in scan->bm_bitmap. The value of range1 is equal to
-* count1 >> num_shifts. Grow range and reduce num_shifts to 0,
-* while preserving these invariants. The updates to mask leave
-* fewer bits set, but each bit that remains set represents a
-* longer string of consecutive bits set in scan->bm_bitmap.
-* If more updates to mask cannot clear more bits, because mask
-* is partitioned with all 0 bits preceding all 1 bits, the loop
-* terminates immediately.
+* in scan->bm_bitmap. The value of range1 is equal to count1
+* >> num_shifts. Grow range1 and reduce num_shifts to 0,
+* while preserving these invariants. The updates to mask
+* leave fewer bits set, but each bit that remains set
+* represents a longer string of consecutive bits set in
+* scan->bm_bitmap. If more updates to mask cannot clear more
+* bits, because mask is partitioned with all 0 bits preceding
+* all 1 bits, the loop terminates immediately.
*/
num_shifts--;
range_ext = range1 + ((count1 >> num_shifts) & 1);
@@ -691,10 +691,23 @@ blst_leaf_alloc(blmeta_t *scan, daddr_t blk, int count
}
/* Discard any candidates that appear before blk. */
- mask &= (u_daddr_t)-1 << (blk & BLIST_BMAP_MASK);
- if (mask == 0)
- return (SWAPBLK_NONE);
+ if ((blk & BLIST_BMAP_MASK) != 0) {
+ cursor_mask = mask & bitrange(0, blk & BLIST_BMAP_MASK);
+ if (cursor_mask != 0) {
+ mask ^= cursor_mask;
+ if (mask == 0)
+ return (SWAPBLK_NONE);
+ /*
+* Bighint change for last block allocation cannot
+* assume that any other blocks are allocated, so the
+* bighint cannot be reduced much.
+*/
+ range1 = BLIST_MAX_ALLOC - 1;
+ }
+ blk &= ~BLIST_BMAP_MASK;
+ }
+
/*
Re: svn commit: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/ea
> In message <201812090645.wb96jnso066...@repo.freebsd.org>, Cy Schubert > writes: > > Author: cy > > Date: Sun Dec 9 06:45:49 2018 > > New Revision: 341759 > > URL: https://svnweb.freebsd.org/changeset/base/341759 > > > > Log: > > MFV r341618: > > > > Update wpa 2.6 --> 2.7. > > Relnotes: yes As an FYI, or maybe a new procedure, doing a reply to a commit message adding relnotes: yes does very little to insure that this commit gets refered to in release notes. What about we add RELNOTES.missed to the tree next to UPDATING, and when someone forgets to tag the Relnotes:yes into a commit you just follow up with a commit to that file, stating the svn revision which was missing the note and then we have a nice documented and clean way to extract the missing release note items, rather than trying to cull it from a thread in a mail list archive. The file would get truncated to 0 at appropriate times on various branches. Thoughts? Rod https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/eap_
On Sun, Dec 9, 2018 at 1:09 PM Rodney W. Grimes < free...@pdx.rh.cn85.dnsmgr.net> wrote: > > In message <201812090645.wb96jnso066...@repo.freebsd.org>, Cy Schubert > > writes: > > > Author: cy > > > Date: Sun Dec 9 06:45:49 2018 > > > New Revision: 341759 > > > URL: https://svnweb.freebsd.org/changeset/base/341759 > > > > > > Log: > > > MFV r341618: > > > > > > Update wpa 2.6 --> 2.7. > > > > Relnotes: yes > > As an FYI, or maybe a new procedure, doing a reply to > a commit message adding relnotes: yes does very little > to insure that this commit gets refered to in release > notes. > > What about we add RELNOTES.missed to the tree > next to UPDATING, and when someone forgets to tag > the Relnotes:yes into a commit you just follow up > with a commit to that file, stating the svn revision > which was missing the note and then we have a nice > documented and clean way to extract the missing > release note items, rather than trying to cull it > from a thread in a mail list archive. > > The file would get truncated to 0 at appropriate > times on various branches. > How about just RELNOTES. You put the revision that is relevant and a quick blurb. That way we don't have to look in two places. All release notes go in here, no exceptions. You can retroactively tag them, or you can commit this as part of commit. Have a blurb at the top that tells people what order to add them in, and you'd be set. We'd then retire "relnotes: yes" in the commit message. This would also allow 'helpers' to format the RELNOTES file as we go rather than having to play 2 years of catch-up at major branch times. Having it in the commit message just doesn't work, and this is one of many reasons: Cy forgot. Other times I'll do something and it's only a month later I realize it needs to be in the release notes after some issue has come up Other times I put relnotes: yes in only to realize that's my vanity talking, and nobody else cares. Warner ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/eap_
On Sunday, December 9, 2018, Warner Losh wrote: > On Sun, Dec 9, 2018 at 1:09 PM Rodney W. Grimes < > free...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > In message <201812090645.wb96jnso066...@repo.freebsd.org>, Cy Schubert > > > writes: > > > > Author: cy > > > > Date: Sun Dec 9 06:45:49 2018 > > > > New Revision: 341759 > > > > URL: https://svnweb.freebsd.org/changeset/base/341759 > > > > > > > > Log: > > > > MFV r341618: > > > > > > > > Update wpa 2.6 --> 2.7. > > > > > > Relnotes: yes > > > > As an FYI, or maybe a new procedure, doing a reply to > > a commit message adding relnotes: yes does very little > > to insure that this commit gets refered to in release > > notes. > > > > What about we add RELNOTES.missed to the tree > > next to UPDATING, and when someone forgets to tag > > the Relnotes:yes into a commit you just follow up > > with a commit to that file, stating the svn revision > > which was missing the note and then we have a nice > > documented and clean way to extract the missing > > release note items, rather than trying to cull it > > from a thread in a mail list archive. > > > > The file would get truncated to 0 at appropriate > > times on various branches. > > > > How about just RELNOTES. You put the revision that is relevant and a quick > blurb. That way we don't have to look in two places. All release notes go > in here, no exceptions. You can retroactively tag them, or you can commit > this as part of commit. > I don't really know SVN, but there wouldn't be a chicken egg probem during commit time? I mean you would really know the SVN id. So you could only add a specific revision in a different commit to RELEASE file. > > Have a blurb at the top that tells people what > order to add them in, and you'd be set. We'd then retire "relnotes: yes" in > the commit message. This would also allow 'helpers' to format the RELNOTES > file as we go rather than having to play 2 years of catch-up at major > branch times. > > Having it in the commit message just doesn't work, and this is one of many > reasons: Cy forgot. Other times I'll do something and it's only a month > later I realize it needs to be in the release notes after some issue has > come up Other times I put relnotes: yes in only to realize that's my > vanity talking, and nobody else cares. > > Warner > ___ > svn-src-head@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r341768 - head/sbin/ping
Author: eugen Date: Sun Dec 9 21:11:15 2018 New Revision: 341768 URL: https://svnweb.freebsd.org/changeset/base/341768 Log: ping(8): remove needless comparision with LONG_MAX after unsigned long ultmp changed to long ltmp in r340245. MFC after:1 week Modified: head/sbin/ping/ping.c Modified: head/sbin/ping/ping.c == --- head/sbin/ping/ping.c Sun Dec 9 19:14:21 2018(r341767) +++ head/sbin/ping/ping.c Sun Dec 9 21:11:15 2018(r341768) @@ -313,7 +313,7 @@ main(int argc, char *const *argv) break; case 'c': ltmp = strtol(optarg, &ep, 0); - if (*ep || ep == optarg || ltmp > LONG_MAX || ltmp <=0) + if (*ep || ep == optarg || ltmp <=0) errx(EX_USAGE, "invalid count of packets to transmit: `%s'", optarg); ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/eap_
On Sun, Dec 9, 2018 at 2:03 PM Oliver Pinter wrote: > > > On Sunday, December 9, 2018, Warner Losh wrote: > >> On Sun, Dec 9, 2018 at 1:09 PM Rodney W. Grimes < >> free...@pdx.rh.cn85.dnsmgr.net> wrote: >> >> > > In message <201812090645.wb96jnso066...@repo.freebsd.org>, Cy >> Schubert >> > > writes: >> > > > Author: cy >> > > > Date: Sun Dec 9 06:45:49 2018 >> > > > New Revision: 341759 >> > > > URL: https://svnweb.freebsd.org/changeset/base/341759 >> > > > >> > > > Log: >> > > > MFV r341618: >> > > > >> > > > Update wpa 2.6 --> 2.7. >> > > >> > > Relnotes: yes >> > >> > As an FYI, or maybe a new procedure, doing a reply to >> > a commit message adding relnotes: yes does very little >> > to insure that this commit gets refered to in release >> > notes. >> > >> > What about we add RELNOTES.missed to the tree >> > next to UPDATING, and when someone forgets to tag >> > the Relnotes:yes into a commit you just follow up >> > with a commit to that file, stating the svn revision >> > which was missing the note and then we have a nice >> > documented and clean way to extract the missing >> > release note items, rather than trying to cull it >> > from a thread in a mail list archive. >> > >> > The file would get truncated to 0 at appropriate >> > times on various branches. >> > >> >> How about just RELNOTES. You put the revision that is relevant and a quick >> blurb. That way we don't have to look in two places. All release notes go >> in here, no exceptions. You can retroactively tag them, or you can commit >> this as part of commit. > > >> > I don't really know SVN, but there wouldn't be a chicken egg probem during > commit time? I mean you would really know the SVN id. So you could only add > a specific revision in a different commit to RELEASE file. > Generally, you can guess really well, and fix it in the case of a lost race easily. You'd add the release notes text in full to the file, with a pointer to the revision(s) for the feature. Warner > >> Have a blurb at the top that tells people what >> order to add them in, and you'd be set. We'd then retire "relnotes: yes" >> in >> the commit message. This would also allow 'helpers' to format the RELNOTES >> file as we go rather than having to play 2 years of catch-up at major >> branch times. >> >> Having it in the commit message just doesn't work, and this is one of many >> reasons: Cy forgot. Other times I'll do something and it's only a month >> later I realize it needs to be in the release notes after some issue has >> come up Other times I put relnotes: yes in only to realize that's my >> vanity talking, and nobody else cares. >> >> Warner >> ___ >> svn-src-head@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/svn-src-head >> To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" >> > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r341769 - head/sys/cam/scsi
Author: imp
Date: Sun Dec 9 21:37:34 2018
New Revision: 341769
URL: https://svnweb.freebsd.org/changeset/base/341769
Log:
Send a START UNIT command when a disk responds with an ASC of 04/1C.
This will hopefully spin up a disk that's in low-power mode.
Sponsored by: Netflix
Submitted by: scottl@
Modified:
head/sys/cam/scsi/scsi_all.c
Modified: head/sys/cam/scsi/scsi_all.c
==
--- head/sys/cam/scsi/scsi_all.cSun Dec 9 21:11:15 2018
(r341768)
+++ head/sys/cam/scsi/scsi_all.cSun Dec 9 21:37:34 2018
(r341769)
@@ -1165,7 +1165,7 @@ static struct asc_table_entry asc_table[] = {
{ SST(0x04, 0x1B, SS_RDEF, /* XXX TBD */
"Logical unit not ready, sanitize in progress") },
/* DT MAEB*/
- { SST(0x04, 0x1C, SS_RDEF, /* XXX TBD */
+ { SST(0x04, 0x1C, SS_START | SSQ_DECREMENT_COUNT | ENXIO,
"Logical unit not ready, additional power use not yet granted") },
/* D */
{ SST(0x04, 0x1D, SS_RDEF, /* XXX TBD */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r341770 - head/sys/modules
Author: imp
Date: Sun Dec 9 21:53:45 2018
New Revision: 341770
URL: https://svnweb.freebsd.org/changeset/base/341770
Log:
Fix typo in powerpcspe name.
Modified:
head/sys/modules/Makefile
Modified: head/sys/modules/Makefile
==
--- head/sys/modules/Makefile Sun Dec 9 21:37:34 2018(r341769)
+++ head/sys/modules/Makefile Sun Dec 9 21:53:45 2018(r341770)
@@ -524,7 +524,7 @@ _cxgbe= cxgbe
.endif
# These rely on 64bit atomics
-.if ${MACHINE_ARCH} != "powerpc" && ${MACHINE_ARCH} != "powerpcspc" && \
+.if ${MACHINE_ARCH} != "powerpc" && ${MACHINE_ARCH} != "powerpcspe" && \
${MACHINE_CPUARCH} != "mips"
_mps= mps
_mpr= mpr
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r341780 - head/stand/powerpc/uboot
Author: jhibbits
Date: Mon Dec 10 01:52:39 2018
New Revision: 341780
URL: https://svnweb.freebsd.org/changeset/base/341780
Log:
powerpc/ubldr: Teach powerpc's ubldr to boot 64-bit kernels
This is just a copy of powerpc/ofw's ppc64_elf_freebsd.c modified to fit
ubldr's boot format.
MFC after:1 week
Added:
head/stand/powerpc/uboot/ppc64_elf_freebsd.c (contents, props changed)
Modified:
head/stand/powerpc/uboot/Makefile
head/stand/powerpc/uboot/conf.c
Modified: head/stand/powerpc/uboot/Makefile
==
--- head/stand/powerpc/uboot/Makefile Mon Dec 10 01:39:40 2018
(r341779)
+++ head/stand/powerpc/uboot/Makefile Mon Dec 10 01:52:39 2018
(r341780)
@@ -16,7 +16,7 @@ NEWVERSWHAT= "U-Boot loader" ${MACHINE_ARCH}
INSTALLFLAGS= -b
# Architecture-specific loader code
-SRCS= start.S conf.c vers.c
+SRCS= start.S conf.c vers.c ppc64_elf_freebsd.c
SRCS+= ucmpdi2.c
# Always add MI sources
Modified: head/stand/powerpc/uboot/conf.c
==
--- head/stand/powerpc/uboot/conf.c Mon Dec 10 01:39:40 2018
(r341779)
+++ head/stand/powerpc/uboot/conf.c Mon Dec 10 01:52:39 2018
(r341780)
@@ -95,9 +95,11 @@ struct netif_driver *netif_drivers[] = {
* Sort formats so that those that can detect based on arguments
* rather than reading the file go first.
*/
+extern struct file_format uboot_elf64;
struct file_format *file_formats[] = {
&uboot_elf,
+ &uboot_elf64,
NULL
};
Added: head/stand/powerpc/uboot/ppc64_elf_freebsd.c
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/stand/powerpc/uboot/ppc64_elf_freebsd.cMon Dec 10 01:52:39
2018(r341780)
@@ -0,0 +1,101 @@
+/*-
+ * Copyright (c) 2001 Benno Rice
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include
+__FBSDID("$FreeBSD$");
+
+#define __ELF_WORD_SIZE 64
+
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+
+#include "bootstrap.h"
+#include "libuboot.h"
+
+vm_offset_t md_load64(char *args, vm_offset_t *modulep, vm_offset_t *dtb);
+extern charend[];
+extern vm_offset_t reloc; /* From /conf.c */
+
+int
+ppc64_uboot_elf_loadfile(char *filename, uint64_t dest,
+struct preloaded_file **result)
+{
+ int r;
+
+ r = __elfN(loadfile)(filename, dest, result);
+ if (r != 0)
+ return (r);
+
+ /*
+* No need to sync the icache for modules: this will
+* be done by the kernel after relocation.
+*/
+ if (!strcmp((*result)->f_type, "elf kernel"))
+ __syncicache((void *) (*result)->f_addr, (*result)->f_size);
+ return (0);
+}
+
+int
+ppc64_uboot_elf_exec(struct preloaded_file *fp)
+{
+ struct file_metadata*fmp;
+ vm_offset_t mdp, dtbp;
+ Elf_Ehdr*e;
+ int error;
+ void(*entry)(void *);
+
+ if ((fmp = file_findmetadata(fp, MODINFOMD_ELFHDR)) == NULL) {
+ return(EFTYPE);
+ }
+ e = (Elf_Ehdr *)&fmp->md_data;
+
+ /* Handle function descriptor for ELFv1 kernels */
+ if ((e->e_flags & 3) == 2)
+ entry = (void (*)(void*))(intptr_t)e->e_entry;
+ else
+ entry = *(void (*)(void*))(uint64_t *)(intptr_t)e->e_entry;
+
+ if ((error = md_load64(fp->f_args, &mdp, &dtbp)) != 0)
+ return (error);
+
+ dev_clean
svn commit: r341781 - head/sys/powerpc/mpc85xx
Author: jhibbits
Date: Mon Dec 10 04:16:40 2018
New Revision: 341781
URL: https://svnweb.freebsd.org/changeset/base/341781
Log:
powerpc/booke: Replace a logical equivalent of pmap_kextract() with a real
call
No sense in reinventing the wheel here. AP bringup is not a time-critical
point.
Modified:
head/sys/powerpc/mpc85xx/platform_mpc85xx.c
Modified: head/sys/powerpc/mpc85xx/platform_mpc85xx.c
==
--- head/sys/powerpc/mpc85xx/platform_mpc85xx.c Mon Dec 10 01:52:39 2018
(r341780)
+++ head/sys/powerpc/mpc85xx/platform_mpc85xx.c Mon Dec 10 04:16:40 2018
(r341781)
@@ -347,7 +347,7 @@ mpc85xx_smp_start_cpu_epapr(platform_t plat, struct pc
rel_va = rel_page + (rel_pa & PAGE_MASK);
pmap_kenter(rel_page, rel_pa & ~PAGE_MASK);
rel = (struct cpu_release *)rel_va;
- bptr = ((vm_paddr_t)(uintptr_t)__boot_page - __startkernel) + kernload;
+ bptr = pmap_kextract((uintptr_t)__boot_page);
cpu_flush_dcache(__DEVOLATILE(struct cpu_release *,rel), sizeof(*rel));
rel->pir = pc->pc_cpuid; __asm __volatile("sync");
rel->entry_h = (bptr >> 32);
@@ -416,7 +416,7 @@ mpc85xx_smp_start_cpu(platform_t plat, struct pcpu *pc
/* Flush caches to have our changes hit DRAM. */
cpu_flush_dcache(__boot_page, 4096);
- bptr = ((vm_paddr_t)(uintptr_t)__boot_page - __startkernel) + kernload;
+ bptr = pmap_kextract((uintptr_t)__boot_page);
KASSERT((bptr & 0xfff) == 0,
("%s: boot page is not aligned (%#jx)", __func__, (uintmax_t)bptr));
if (mpc85xx_is_qoriq()) {
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/e
In message , Warner Losh writes: > --9ed486057c9d7878 > Content-Type: text/plain; charset="UTF-8" > > On Sun, Dec 9, 2018 at 2:03 PM Oliver Pinter > wrote: > > > > > > > On Sunday, December 9, 2018, Warner Losh wrote: > > > >> On Sun, Dec 9, 2018 at 1:09 PM Rodney W. Grimes < > >> free...@pdx.rh.cn85.dnsmgr.net> wrote: > >> > >> > > In message <201812090645.wb96jnso066...@repo.freebsd.org>, Cy > >> Schubert > >> > > writes: > >> > > > Author: cy > >> > > > Date: Sun Dec 9 06:45:49 2018 > >> > > > New Revision: 341759 > >> > > > URL: https://svnweb.freebsd.org/changeset/base/341759 > >> > > > > >> > > > Log: > >> > > > MFV r341618: > >> > > > > >> > > > Update wpa 2.6 --> 2.7. > >> > > > >> > > Relnotes: yes > >> > > >> > As an FYI, or maybe a new procedure, doing a reply to > >> > a commit message adding relnotes: yes does very little > >> > to insure that this commit gets refered to in release > >> > notes. > >> > > >> > What about we add RELNOTES.missed to the tree > >> > next to UPDATING, and when someone forgets to tag > >> > the Relnotes:yes into a commit you just follow up > >> > with a commit to that file, stating the svn revision > >> > which was missing the note and then we have a nice > >> > documented and clean way to extract the missing > >> > release note items, rather than trying to cull it > >> > from a thread in a mail list archive. > >> > > >> > The file would get truncated to 0 at appropriate > >> > times on various branches. > >> > > >> > >> How about just RELNOTES. You put the revision that is relevant and a quick > >> blurb. That way we don't have to look in two places. All release notes go > >> in here, no exceptions. You can retroactively tag them, or you can commit > >> this as part of commit. > > > > > >> > > I don't really know SVN, but there wouldn't be a chicken egg probem during > > commit time? I mean you would really know the SVN id. So you could only add > > a specific revision in a different commit to RELEASE file. > > > > Generally, you can guess really well, and fix it in the case of a lost race > easily. > > You'd add the release notes text in full to the file, with a pointer to the > revision(s) for the feature. How about a couple of other alternatives? Hmmm. Rather than bloat the repo, can we put this onto wiki.freebsd.org? Downside, people tend to forget or it's too much of a hassle. Upside, no repo bloat. OTOH, if it is to be a file, IMO it should live in the doc repo. If people write up good notes they can be included directly from doc/. Personally, I prefer "put it in the doc repo" better. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/eap_
> On Sun, Dec 9, 2018 at 2:03 PM Oliver Pinter > wrote: > > > > > > > On Sunday, December 9, 2018, Warner Losh wrote: > > > >> On Sun, Dec 9, 2018 at 1:09 PM Rodney W. Grimes < > >> free...@pdx.rh.cn85.dnsmgr.net> wrote: > >> > >> > > In message <201812090645.wb96jnso066...@repo.freebsd.org>, Cy > >> Schubert > >> > > writes: > >> > > > Author: cy > >> > > > Date: Sun Dec 9 06:45:49 2018 > >> > > > New Revision: 341759 > >> > > > URL: https://svnweb.freebsd.org/changeset/base/341759 > >> > > > > >> > > > Log: > >> > > > MFV r341618: > >> > > > > >> > > > Update wpa 2.6 --> 2.7. > >> > > > >> > > Relnotes: yes > >> > > >> > As an FYI, or maybe a new procedure, doing a reply to > >> > a commit message adding relnotes: yes does very little > >> > to insure that this commit gets refered to in release > >> > notes. > >> > > >> > What about we add RELNOTES.missed to the tree > >> > next to UPDATING, and when someone forgets to tag > >> > the Relnotes:yes into a commit you just follow up > >> > with a commit to that file, stating the svn revision > >> > which was missing the note and then we have a nice > >> > documented and clean way to extract the missing > >> > release note items, rather than trying to cull it > >> > from a thread in a mail list archive. > >> > > >> > The file would get truncated to 0 at appropriate > >> > times on various branches. > >> > > >> > >> How about just RELNOTES. You put the revision that is relevant and a quick > >> blurb. That way we don't have to look in two places. All release notes go > >> in here, no exceptions. You can retroactively tag them, or you can commit > >> this as part of commit. My one concern is that if we remove the Relnotes: yes line from the commits then we may end up totally ignoring the need to put entries in RELNOTES, which unlike UPDATING do not have consequences if ignored. > > > > > >> > > I don't really know SVN, but there wouldn't be a chicken egg probem during > > commit time? I mean you would really know the SVN id. So you could only add > > a specific revision in a different commit to RELEASE file. > > > > Generally, you can guess really well, and fix it in the case of a lost race > easily. No reason to guess, if you add the RELNOTES change with the commit then it is the revision that added the RELNOTES entry, so a log view of RELNOTES would show you the revision. If you do it after words or edit an existing entry in the RELNOTES file that is also fairly clear as that commit has no other files touched. > > You'd add the release notes text in full to the file, with a pointer to the > revision(s) for the feature. If you modify RELNOTES with the commit adding the feature we could easily use a pointer of "this commit", the svn version number of that added entry is self referencing to the actual change, which I actually rather like the idea of. > > Warner > > > > >> Have a blurb at the top that tells people what > >> order to add them in, and you'd be set. We'd then retire "relnotes: yes" > >> in > >> the commit message. This would also allow 'helpers' to format the RELNOTES > >> file as we go rather than having to play 2 years of catch-up at major > >> branch times. Yes. You could actually "delete" an entry from RELNOTES once a proper entry in the actual release notes had been created, such that RELNOTES is really a list of pending items. > >> > >> Having it in the commit message just doesn't work, and this is one of many > >> reasons: Cy forgot. Other times I'll do something and it's only a month > >> later I realize it needs to be in the release notes after some issue has > >> come up Other times I put relnotes: yes in only to realize that's my > >> vanity talking, and nobody else cares. I agree, what we have now works poorly. > >> Warner -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/ea
> In message il.com> > , Warner Losh writes: > > --9ed486057c9d7878 > > Content-Type: text/plain; charset="UTF-8" > > > > On Sun, Dec 9, 2018 at 2:03 PM Oliver Pinter > > wrote: > > > > > > > > > > > On Sunday, December 9, 2018, Warner Losh wrote: > > > > > >> On Sun, Dec 9, 2018 at 1:09 PM Rodney W. Grimes < > > >> free...@pdx.rh.cn85.dnsmgr.net> wrote: > > >> > > >> > > In message <201812090645.wb96jnso066...@repo.freebsd.org>, Cy > > >> Schubert > > >> > > writes: > > >> > > > Author: cy > > >> > > > Date: Sun Dec 9 06:45:49 2018 > > >> > > > New Revision: 341759 > > >> > > > URL: https://svnweb.freebsd.org/changeset/base/341759 > > >> > > > > > >> > > > Log: > > >> > > > MFV r341618: > > >> > > > > > >> > > > Update wpa 2.6 --> 2.7. > > >> > > > > >> > > Relnotes: yes > > >> > > > >> > As an FYI, or maybe a new procedure, doing a reply to > > >> > a commit message adding relnotes: yes does very little > > >> > to insure that this commit gets refered to in release > > >> > notes. > > >> > > > >> > What about we add RELNOTES.missed to the tree > > >> > next to UPDATING, and when someone forgets to tag > > >> > the Relnotes:yes into a commit you just follow up > > >> > with a commit to that file, stating the svn revision > > >> > which was missing the note and then we have a nice > > >> > documented and clean way to extract the missing > > >> > release note items, rather than trying to cull it > > >> > from a thread in a mail list archive. > > >> > > > >> > The file would get truncated to 0 at appropriate > > >> > times on various branches. > > >> > > > >> > > >> How about just RELNOTES. You put the revision that is relevant and a > > >> quick > > >> blurb. That way we don't have to look in two places. All release notes go > > >> in here, no exceptions. You can retroactively tag them, or you can commit > > >> this as part of commit. > > > > > > > > >> > > > I don't really know SVN, but there wouldn't be a chicken egg probem during > > > commit time? I mean you would really know the SVN id. So you could only > > > add > > > a specific revision in a different commit to RELEASE file. > > > > > > > Generally, you can guess really well, and fix it in the case of a lost race > > easily. > > > > You'd add the release notes text in full to the file, with a pointer to the > > revision(s) for the feature. > > How about a couple of other alternatives? > > Hmmm. Rather than bloat the repo, I do not think this is going to create any sizeable amount of repo bloat. > can we put this onto > wiki.freebsd.org? Downside, people tend to forget or it's too much of a > hassle. Upside, no repo bloat. wiki.freebsd.org is out of the question, to far away from the commit button to ever be used by most developers. > > otoh, is it is to be a file, IMO it should live in the doc repo. If > people write up good notes they can be included directly from doc/. Again, doc repo is too far away for most developers to ever both with a commit to the doc repository, however we have move the release notes to the doc repository, but that is mostly release engineering doing work on that. > > Personally, I prefer "put it in the doc repo" better. Release notes are already there, but putting this file there would ensure that no developer ever adds anything to it. That would also mean 2 commits for any relnotes type thing, one to the base repository and another to the docs repository, and that would lose the self referential svn version that I mentioned in my reply to imp@ -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/e
In message <201812100619.wba6jb0c064...@pdx.rh.cn85.dnsmgr.net>, "Rodney W. Gri mes" writes: > > On Sun, Dec 9, 2018 at 2:03 PM Oliver Pinter > > > wrote: > > > > > > > > > > > On Sunday, December 9, 2018, Warner Losh wrote: > > > > > >> On Sun, Dec 9, 2018 at 1:09 PM Rodney W. Grimes < > > >> free...@pdx.rh.cn85.dnsmgr.net> wrote: > > >> > > >> > > In message <201812090645.wb96jnso066...@repo.freebsd.org>, Cy > > >> Schubert > > >> > > writes: > > >> > > > Author: cy > > >> > > > Date: Sun Dec 9 06:45:49 2018 > > >> > > > New Revision: 341759 > > >> > > > URL: https://svnweb.freebsd.org/changeset/base/341759 > > >> > > > > > >> > > > Log: > > >> > > > MFV r341618: > > >> > > > > > >> > > > Update wpa 2.6 --> 2.7. > > >> > > > > >> > > Relnotes: yes > > >> > > > >> > As an FYI, or maybe a new procedure, doing a reply to > > >> > a commit message adding relnotes: yes does very little > > >> > to insure that this commit gets refered to in release > > >> > notes. > > >> > > > >> > What about we add RELNOTES.missed to the tree > > >> > next to UPDATING, and when someone forgets to tag > > >> > the Relnotes:yes into a commit you just follow up > > >> > with a commit to that file, stating the svn revision > > >> > which was missing the note and then we have a nice > > >> > documented and clean way to extract the missing > > >> > release note items, rather than trying to cull it > > >> > from a thread in a mail list archive. > > >> > > > >> > The file would get truncated to 0 at appropriate > > >> > times on various branches. > > >> > > > >> > > >> How about just RELNOTES. You put the revision that is relevant and a qui > ck > > >> blurb. That way we don't have to look in two places. All release notes g > o > > >> in here, no exceptions. You can retroactively tag them, or you can commi > t > > >> this as part of commit. > > My one concern is that if we remove the Relnotes: yes line > from the commits then we may end up totally ignoring the > need to put entries in RELNOTES, which unlike UPDATING > do not have consequences if ignored. > > > > > > > > > >> > > > I don't really know SVN, but there wouldn't be a chicken egg probem durin > g > > > commit time? I mean you would really know the SVN id. So you could only a > dd > > > a specific revision in a different commit to RELEASE file. > > > > > > > Generally, you can guess really well, and fix it in the case of a lost race > > easily. > > No reason to guess, if you add the RELNOTES change with the commit > then it is the revision that added the RELNOTES entry, so a log view > of RELNOTES would show you the revision. If you do it after words > or edit an existing entry in the RELNOTES file that is also fairly > clear as that commit has no other files touched. > > > > > You'd add the release notes text in full to the file, with a pointer to the > > revision(s) for the feature. > > If you modify RELNOTES with the commit adding the feature we > could easily use a pointer of "this commit", the svn version number > of that added entry is self referencing to the actual change, > which I actually rather like the idea of. > > > > > Warner > > > > > > > >> Have a blurb at the top that tells people what > > >> order to add them in, and you'd be set. We'd then retire "relnotes: yes" > > >> in > > >> the commit message. This would also allow 'helpers' to format the RELNOT > ES > > >> file as we go rather than having to play 2 years of catch-up at major > > >> branch times. > > Yes. You could actually "delete" an entry from RELNOTES once a > proper entry in the actual release notes had been created, such > that RELNOTES is really a list of pending items. > > > >> > > >> Having it in the commit message just doesn't work, and this is one of ma > ny > > >> reasons: Cy forgot. Other times I'll do something and it's only a month > > >> later I realize it needs to be in the release notes after some issue has > > >> come up Other times I put relnotes: yes in only to realize that's my > > >> vanity talking, and nobody else cares. > > I agree, what we have now works poorly. Forgetting, yes, but also a hmmm moment. Initially my thinking was a file in doc/. Or maybe something like the vuxml port where we fill in the blanks and make validate to make sure all the i's are dotted and t's crossed. It's a little extra work for committers but would help re@ immensely, and get the details in from the get-go. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/eap_
On Sun, Dec 9, 2018, 11:40 PM Cy Schubert In message <201812100619.wba6jb0c064...@pdx.rh.cn85.dnsmgr.net>, > "Rodney W. Gri > mes" writes: > > > On Sun, Dec 9, 2018 at 2:03 PM Oliver Pinter < > oliver.pin...@hardenedbsd.org > > > > > > wrote: > > > > > > > > > > > > > > > On Sunday, December 9, 2018, Warner Losh wrote: > > > > > > > >> On Sun, Dec 9, 2018 at 1:09 PM Rodney W. Grimes < > > > >> free...@pdx.rh.cn85.dnsmgr.net> wrote: > > > >> > > > >> > > In message <201812090645.wb96jnso066...@repo.freebsd.org>, Cy > > > >> Schubert > > > >> > > writes: > > > >> > > > Author: cy > > > >> > > > Date: Sun Dec 9 06:45:49 2018 > > > >> > > > New Revision: 341759 > > > >> > > > URL: https://svnweb.freebsd.org/changeset/base/341759 > > > >> > > > > > > >> > > > Log: > > > >> > > > MFV r341618: > > > >> > > > > > > >> > > > Update wpa 2.6 --> 2.7. > > > >> > > > > > >> > > Relnotes: yes > > > >> > > > > >> > As an FYI, or maybe a new procedure, doing a reply to > > > >> > a commit message adding relnotes: yes does very little > > > >> > to insure that this commit gets refered to in release > > > >> > notes. > > > >> > > > > >> > What about we add RELNOTES.missed to the tree > > > >> > next to UPDATING, and when someone forgets to tag > > > >> > the Relnotes:yes into a commit you just follow up > > > >> > with a commit to that file, stating the svn revision > > > >> > which was missing the note and then we have a nice > > > >> > documented and clean way to extract the missing > > > >> > release note items, rather than trying to cull it > > > >> > from a thread in a mail list archive. > > > >> > > > > >> > The file would get truncated to 0 at appropriate > > > >> > times on various branches. > > > >> > > > > >> > > > >> How about just RELNOTES. You put the revision that is relevant and > a qui > > ck > > > >> blurb. That way we don't have to look in two places. All release > notes g > > o > > > >> in here, no exceptions. You can retroactively tag them, or you can > commi > > t > > > >> this as part of commit. > > > > My one concern is that if we remove the Relnotes: yes line > > from the commits then we may end up totally ignoring the > > need to put entries in RELNOTES, which unlike UPDATING > > do not have consequences if ignored. > > > > > > > > > > > > > >> > > > > I don't really know SVN, but there wouldn't be a chicken egg probem > durin > > g > > > > commit time? I mean you would really know the SVN id. So you could > only a > > dd > > > > a specific revision in a different commit to RELEASE file. > > > > > > > > > > Generally, you can guess really well, and fix it in the case of a lost > race > > > easily. > > > > No reason to guess, if you add the RELNOTES change with the commit > > then it is the revision that added the RELNOTES entry, so a log view > > of RELNOTES would show you the revision. If you do it after words > > or edit an existing entry in the RELNOTES file that is also fairly > > clear as that commit has no other files touched. > > > > > > > > You'd add the release notes text in full to the file, with a pointer > to the > > > revision(s) for the feature. > > > > If you modify RELNOTES with the commit adding the feature we > > could easily use a pointer of "this commit", the svn version number > > of that added entry is self referencing to the actual change, > > which I actually rather like the idea of. > > > > > > > > Warner > > > > > > > > > > >> Have a blurb at the top that tells people what > > > >> order to add them in, and you'd be set. We'd then retire "relnotes: > yes" > > > >> in > > > >> the commit message. This would also allow 'helpers' to format the > RELNOT > > ES > > > >> file as we go rather than having to play 2 years of catch-up at > major > > > >> branch times. > > > > Yes. You could actually "delete" an entry from RELNOTES once a > > proper entry in the actual release notes had been created, such > > that RELNOTES is really a list of pending items. > > > > > >> > > > >> Having it in the commit message just doesn't work, and this is one > of ma > > ny > > > >> reasons: Cy forgot. Other times I'll do something and it's only a > month > > > >> later I realize it needs to be in the release notes after some > issue has > > > >> come up Other times I put relnotes: yes in only to realize > that's my > > > >> vanity talking, and nobody else cares. > > > > I agree, what we have now works poorly. > > Forgetting, yes, but also a hmmm moment. > > Initially my thinking was a file in doc/. Or maybe something like the > vuxml port where we fill in the blanks and make validate to make sure > all the i's are dotted and t's crossed. It's a little extra work for > committers but would help re@ immensely, and get the details in from > the get-go. > My thought was a low friction, proximate way to do a ticker of important changes. Doc repo is too hard. Too much friction. A simple extra file puts it all in one, easy to find and edit place... it can cause other things to happen, furt
