Re: Problem building kernel

[Justin Hibbits]

Hi Michael,

The GENERIC config is for 32-bit powerpc, GENERIC64 is what you want
for 64-bit config.

- Justin

On Sun, 24 Dec 2023 12:18:55 +0100
tue...@freebsd.org wrote:

> Dear all,
> 
> I just tried to build world and kernel on a 64-bit PPC system.
> 
> make -j 32 buildworld
> 
> ran without problems.
> However
> 
> make kernel KERNCONF=GENERIC
> 
> breaks with
> ..
> --- all_subdir_accf_data ---
> --- accf_data.kld ---
> ld -m elf32ppc_fbsd -warn-common --build-id=sha1 --no-toc-optimize
> -r  -o accf_data.kld accf_data.o --- all_subdir_acl_nfs4 ---
> --- offset.inc ---
> sh /usr/home/tuexen/freebsd-src/sys/kern/genoffset.sh genoffset.o >
> offset.inc --- all_subdir_accf_data ---
> ld: error: accf_data.o is incompatible with elf32ppc_fbsd
> *** [accf_data.kld] Error code 1
> 
> make[4]: stopped in /usr/home/tuexen/freebsd-src/sys/modules/accf_data
>5.79 real22.37 user15.35 sys
> 
> make[1]: stopped in /usr/home/tuexen/freebsd-src
> 
> make: stopped in /usr/home/tuexen/freebsd-src
> tuexen@blackbird:
> 
> Any idea what is going wrong?
> 
> Best regards
> Michael

Re: Considering stepping down from all of my FreeBSD responsibilities

[Justin Hibbits]

On Fri, 01 Apr 2022 09:38:07 -0700
Cy Schubert  wrote:

> In message <20220401064816.gs60...@eureka.lemis.com>, Greg 'groggy'
> Lehey write
> s:
> > 
> > --TSQPSNmi3T91JED+
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> >
> > On Friday,  1 April 2022 at  5:58:39 +, Alexey Dokuchaev wrote:
> >  
> > > On Fri, Apr 01, 2022 at 02:20:31PM +0900, Yasuhiro Kimura wrote:  
> > >> Hi Glen,
> > >>
> > >> From: Glen Barber 
> > >> Subject: Considering stepping down from all of my FreeBSD
> > >> responsibilities Date: Fri, 1 Apr 2022 00:15:02 +
> > >>  
> > >>> Dear community,
> > >>>
> > >>> Given the mental toll the past two years or so have taken on
> > >>> me, I have decided to step down from all of my "hats" within
> > >>> the Project, and take some time to sort out what my future
> > >>> looks like going forward.
> > >>>
> > >>> Happy April 1st.  I'm not going anywhere.  :-)  
> > >>
> > >> We are waiting for the announce of FreeBSD 2.2.10-RELEASE. :-)
> > >>
> > >> Cf.
> > >> https://lists.freebsd.org/pipermail/freebsd-announce/2006-April/001055
> > >>  
> > .html  
> > >
> > > I don't think 2.2.10 is warranted.  
> >
> > Agreed.  The upgrade isn't sufficiently important.
> >
> > How about 2.2.9.1?  
> 
> I had a different more sinister thought: Announcing that we've moved
> from BSDL to GPLv3 to be more like Linux.
> 
> 

Take it to the next level.  Since we're using git you can make the
license change, do the commit, then send the commit email out, and it
would have the valid hash and all.

- Justin

Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311

[Justin Hibbits]

On Thu, 11 Jun 2020 17:30:24 -0700
Mark Millard  wrote:

> On 2020-Jun-11, at 16:49, Mark Millard  wrote:
> 
> > On 2020-Jun-11, at 14:42, Justin Hibbits 
> > wrote:
> > 
> > On Thu, 11 Jun 2020 14:36:37 -0700
> > Mark Millard  wrote:
> >   
> >> On 2020-Jun-11, at 13:55, Justin Hibbits 
> >> wrote:
> >>   
> >>> On Wed, 10 Jun 2020 18:56:57 -0700
> >>> Mark Millard  wrote:  
> > . . .  
> >> 
> >>   
> >>> That said, the attached patch effectively copies
> >>> what's done in OEA6464 into OEA pmap.  Can you test it?
> >> 
> >> I'll try it once I get a chance, probably later
> >> today.
> >> . . .  
> > 
> > No luck at the change being a fix, I'm afraid.
> > 
> > I verified that the build ended up with
> > 
> > 00926cb0  bl  008e8dc8 
> > 00926cb4  mr  r27,r3
> > 00926cb8  addir3,r3,36
> > 00926cbc  hwsync
> > 00926cc0  lwarx   r25,0,r3
> > 00926cc4  li  r4,0
> > 00926cc8  stwcx.  r4,0,r3
> > 00926ccc  bne-00926cc0 
> > 00926cd0  andi.   r3,r25,128
> > 00926cd4  beq 00926ce0 
> > 00926cd8  mr  r3,r27
> > 00926cdc  bl  008e9874 
> > 
> > in the installed kernel. So I doubt a
> > mis-build would be involved. It is a
> > head -r360311 based context still. World is
> > without MALLOC_PRODUCTION so that jemalloc
> > code executes its asserts, catching more
> > and earlier than otherwise.
> > 
> > First test . . .
> > 
> > The only thing that the witness kernel reported was:
> > 
> > Jun 11 15:58:16 FBSDG4S2 kernel: lock order reversal:
> > Jun 11 15:58:16 FBSDG4S2 kernel:  1st 0x216fb00 Mountpoints (UMA
> > zone) @ /usr/src/sys/vm/uma_core.c:4387 Jun 11 15:58:16 FBSDG4S2
> > kernel:  2nd 0x1192d2c kernelpmap (kernelpmap) @
> > /usr/src/sys/powerpc/aim/mmu_oea.c:1524 Jun 11 15:58:16 FBSDG4S2
> > kernel: stack backtrace: Jun 11 15:58:16 FBSDG4S2 kernel: #0
> > 0x5ec164 at witness_debugger+0x94 Jun 11 15:58:16 FBSDG4S2 kernel:
> > #1 0x5ebe3c at witness_checkorder+0xb50 Jun 11 15:58:16 FBSDG4S2
> > kernel: #2 0x536d5c at __mtx_lock_flags+0xcc Jun 11 15:58:16
> > FBSDG4S2 kernel: #3 0x92636c at moea_kextract+0x5c Jun 11 15:58:16
> > FBSDG4S2 kernel: #4 0x965d30 at pmap_kextract+0x98 Jun 11 15:58:16
> > FBSDG4S2 kernel: #5 0x8bfdbc at zone_release+0xf0 Jun 11 15:58:16
> > FBSDG4S2 kernel: #6 0x8c7854 at bucket_drain+0x2f0 Jun 11 15:58:16
> > FBSDG4S2 kernel: #7 0x8c728c at bucket_free+0x54 Jun 11 15:58:16
> > FBSDG4S2 kernel: #8 0x8c74fc at bucket_cache_reclaim+0x1bc Jun 11
> > 15:58:16 FBSDG4S2 kernel: #9 0x8c7004 at zone_reclaim+0x128 Jun 11
> > 15:58:16 FBSDG4S2 kernel: #10 0x8c3a40 at uma_reclaim+0x170 Jun 11
> > 15:58:16 FBSDG4S2 kernel: #11 0x8c3f70 at uma_reclaim_worker+0x68
> > Jun 11 15:58:16 FBSDG4S2 kernel: #12 0x50fbac at fork_exit+0xb0 Jun
> > 11 15:58:16 FBSDG4S2 kernel: #13 0x9684ac at fork_trampoline+0xc
> > 
> > The processes that were hit were listed as:
> > 
> > Jun 11 15:59:11 FBSDG4S2 kernel: pid 971 (cron), jid 0, uid 0:
> > exited on signal 11 (core dumped) Jun 11 16:02:59 FBSDG4S2 kernel:
> > pid  (stress), jid 0, uid 0: exited on signal 6 (core dumped)
> > Jun 11 16:03:27 FBSDG4S2 kernel: pid 871 (mountd), jid 0, uid 0:
> > exited on signal 6 (core dumped) Jun 11 16:03:40 FBSDG4S2 kernel:
> > pid 1065 (su), jid 0, uid 0: exited on signal 6 Jun 11 16:04:13
> > FBSDG4S2 kernel: pid 1088 (su), jid 0, uid 0: exited on signal 6
> > Jun 11 16:04:28 FBSDG4S2 kernel: pid 968 (sshd), jid 0, uid 0:
> > exited on signal 6
> > 
> > Jun 11 16:05:42 FBSDG4S2 kernel: pid 1028 (login), jid 0, uid 0:
> > exited on signal 6
> > 
> > Jun 11 16:05:46 FBSDG4S2 kernel: pid 873 (nfsd), jid 0, uid 0:
> > exited on signal 6 (core dumped)
> > 
> > 
> > Rebooting and rerunning and showing the stress output and such
> > (I did not capture copies during the first test, but the first
> > test had similar messages at the same sort of points):
> > 
> > Second test . . .
> > 
> > # stress -m 2 --vm-bytes 1700M
> > stress: info: [1166] dispatching hogs: 0 cpu, 0 io, 2 vm, 0 hdd
> > :
> > /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:258:
> > Failed assertion: "slab == extent_slab_get(extent)" :
> > /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:258:
> > Failed assertion: "slab == extent_slab_get(extent)" ^C
> > 
> > # exit
> > :
> > /usr/s

Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311

[Justin Hibbits]

On Thu, 11 Jun 2020 14:36:37 -0700
Mark Millard  wrote:

> On 2020-Jun-11, at 13:55, Justin Hibbits 
> wrote:
> 
> > On Wed, 10 Jun 2020 18:56:57 -0700
> > Mark Millard  wrote:
> >   
> >> On 2020-May-13, at 08:56, Justin Hibbits 
> >> wrote: 
> >>> Hi Mark,
> >> 
> >> Hello Justin.  
> > 
> > Hi Mark,  
> 
> Hello again, Justin.
> 
> >> 
> >> I've been avoiding the old PowerMacs and leaving
> >> them at head -r360311 , pending an update that
> >> would avoid the kernel zeroing pages that it
> >> should not zero. But I've seen that you were busy
> >> with more modern contexts this last about a month.
> >> 
> >> And, clearly, my own context has left pending
> >> (for much longer) other more involved activities
> >> (compared to just periodically updating to
> >> more recent FreeBSD vintages).
> >> 
> >> . . .
> >>   
> > 
> > Sorry for the delay, I got sidetracked with a bunch of other
> > development.  
> 
> > I did install a newer FreeBSD on my dual G4 and couldn't
> > see the problem.  
> 
> How did you test?
> 
> In my context it was far easier to see the problem
> with builds that did not use MALLOC_PRODUCTION. In
> other words: jemalloc having its asserts tested.
> 
> The easiest way I found to get the asserts to fail
> was to do (multiple processes (-m) and totaling to
> more than enough to force paging/swapping):
> 
> stress -m 2 --vm-bytes 1700M &
> 
> (Possibly setting up some shells first
> to potentially later exit.)
> 
> Normally stress itself would hit jemalloc
> asserts. Apparently the asserts did not
> stop the code and it ran until a failure
> occurred (via dtv=0x0). I never had to
> manually stop the stress processes.
> 
> If no failures during, then exit shells
> that likely were swapped out or partially
> paged out during the stress run. They
> hit jemalloc asserts during their cleanup
> activity in my testing.

My testing was only with a WITNESS kernel, and wasn't an exhaustive
test, so obviously is not a straight apples-to-apples comparison.
Unfortunately, my backlog of other work got in the way of doing a
meaningful extensive test.

> 
> 
> > That said, the attached patch effectively copies
> > what's done in OEA6464 into OEA pmap.  Can you test it?  
> 
> I'll try it once I get a chance, probably later
> today.
> 
> I gather from what I see that moea64_protect did not
> need the changes that you originally thought might
> be required? I only see moea_protect changes in the
> patch.

The wording was a little ambiguous.  I had meant to convey that I was
looking at mmu_oea64.c for inspiration for what's missing in mmu_oea.c.

> 
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
> 

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311

[Justin Hibbits]

On Wed, 10 Jun 2020 18:56:57 -0700
Mark Millard  wrote:

> On 2020-May-13, at 08:56, Justin Hibbits  wrote:
> 
> > Hi Mark,  
> 
> Hello Justin.

Hi Mark,


> 
> > On Wed, 13 May 2020 01:43:23 -0700
> > Mark Millard  wrote:
> >   
> >> [I'm adding a reference to an old arm64/aarch64 bug that had
> >> pages turning to zero, in case this 32-bit powerpc issue is
> >> somewhat analogous.]
> >>   
> >>> . . .  
> > ...  
> >> . . .
> >> 
> >> (Note: dsl-only.net closed down, so the E-mail
> >> address reference is no longer valid.)
> >> 
> >> Author: kib
> >> Date: Mon Apr 10 15:32:26 2017
> >> New Revision: 316679
> >> URL: 
> >> https://svnweb.freebsd.org/changeset/base/316679
> >> 
> >> 
> >> Log:
> >> Do not lose dirty bits for removing PROT_WRITE on arm64.
> >> 
> >> Arm64 pmap interprets accessed writable ptes as modified, since
> >> ARMv8.0 does not track Dirty Bit Modifier in hardware. If writable
> >> bit is removed, page must be marked as dirty for MI VM.
> >> 
> >> This change is most important for COW, where fork caused losing
> >> content of the dirty pages which were not yet scanned by
> >> pagedaemon.
> >> 
> >> Reviewed by:   alc, andrew
> >> Reported and tested by:Mark Millard  >> dsl-only.net> PR:  217138, 217239
> >> Sponsored by:  The FreeBSD Foundation
> >> MFC after: 2 weeks
> >> 
> >> Modified:
> >> head/sys/arm64/arm64/pmap.c
> >> 
> >> Modified: head/sys/arm64/arm64/pmap.c
> >> ==
> >> --- head/sys/arm64/arm64/pmap.cMon Apr 10 12:35:58
> >> 2017   (r316678) +++ head/sys/arm64/arm64/pmap.c   Mon
> >> Apr 10 15:32:26 2017   (r316679) @@ -2481,6 +2481,11 @@
> >> pmap_protect(pmap_t pmap, vm_offset_t sv sva += L3_SIZE) {
> >>l3 = pmap_load(l3p);
> >>if (pmap_l3_valid(l3)) {
> >> +  if ((l3 & ATTR_SW_MANAGED) &&
> >> +  pmap_page_dirty(l3)) {
> >> +
> >> vm_page_dirty(PHYS_TO_VM_PAGE(l3 &
> >> +  ~ATTR_MASK));
> >> +  }
> >>pmap_set(l3p, ATTR_AP(ATTR_AP_RO));
> >>PTE_SYNC(l3p);
> >>/* XXX: Use pmap_invalidate_range
> >> */
> >> 
> >> . . .
> >>   
> > 
> > Thanks for this reference.  I took a quick look at the 3 pmap
> > implementations we have (haven't check the new radix pmap yet), and
> > it looks like only mmu_oea.c (32-bit AIM pmap, for G3 and G4) is
> > missing vm_page_dirty() calls in its pmap_protect() implementation,
> > analogous to the change you posted right above. Given this, I think
> > it's safe to say that this missing piece is necessary.  We'll work
> > on a fix for this; looking at moea64_protect(), there may be
> > additional work needed to support this as well, so it may take a
> > few days.  
> 
> Ping? Any clue when the above might happen?
> 
> I've been avoiding the old PowerMacs and leaving
> them at head -r360311 , pending an update that
> would avoid the kernel zeroing pages that it
> should not zero. But I've seen that you were busy
> with more modern contexts this last about a month.
> 
> And, clearly, my own context has left pending
> (for much longer) other more involved activities
> (compared to just periodically updating to
> more recent FreeBSD vintages).
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
> 

Sorry for the delay, I got sidetracked with a bunch of other
development.  I did install a newer FreeBSD on my dual G4 and couldn't
see the problem.  That said, the attached patch effectively copies
what's done in OEA6464 into OEA pmap.  Can you test it?

- Justin
diff --git a/sys/powerpc/aim/mmu_oea.c b/sys/powerpc/aim/mmu_oea.c
index c5b0b048a41..2f1422b36c4 100644
--- a/sys/powerpc/aim/mmu_oea.c
+++ b/sys/powerpc/aim/mmu_oea.c
@@ -1776,6 +1776,9 @@ moea_protect(pmap_t pm, vm_offset_t sva, vm_offset_t eva,
 {
 	struct	pvo_entry *pvo, *tpvo, key;
 	struct	pte *pt;
+	struct	pte old_pte;
+	vm_page_t	m;
+	int32_t	refchg;
 
 	KASSERT(pm == >p_vmspace->vm_pmap || pm == kernel_pmap,
 	("moea_protect: non current pmap"));
@@ -1803,12 +1806,31 @@ moea_protect(pma

Re: acpi timer reads all ones [Was: efirtc + atrtc at the same time]

[Justin Hibbits]

On Wed, 27 May 2020 06:27:16 -0700
John Baldwin  wrote:

> On 5/27/20 2:39 AM, Andriy Gapon wrote:
> > On 27/05/2020 11:13, Andriy Gapon wrote:  
> >> I added more diagnostics and it seems to support the idea that the
> >> problem is related to I/O cycles and bridges.
> >>
> >> ACPI timer suddenly starts returning 0x and that lasts for
> >> tens of microseconds before the timer goes back to returning
> >> normal values with an expected increase.
> >> AMD provides a proprietary way to access ACPI registers via MMIO
> >> (0xfed808xx). That mechanism is unaffected, ACPI timer register
> >> always returns good values.
> >>
> >> The problem seems to happen when restoring configuration of a
> >> particular PCI bridge.  What's interesting is that the bridge
> >> decodes one memory range and one I/O range.
> >>
> >> Looking at pci_cfg_restore() I wonder if it is wise to restore
> >> PCIR_COMMAND so early.  Could it be that after the resume the
> >> bridge is configured with a wrong I/O range (e.g., too wide) and
> >> by writing PCIR_COMMAND we enable that decoding. So, the bridge
> >> steals I/O cycles destined for ACPI support hardware.  If there is
> >> nothing behind the bridge to handle those ports, then we get those
> >> bad readings. Once the bridge configuration is fully restored, the
> >> I/O handling goes back to normal.  
> > 
> > From what I see, this looks like a BIOS bug.
> > Upon resume, it swaps window configurations of pcib1 and pcib2
> > (until FreeBSD restores them).  pcib1 originally does not have an
> > I/O window.  So, BIOS programs both base and limit of pcib2 I/O
> > window to zero.   When FreeBSD writes its command register to
> > enable I/O decoding it starts claiming 0x0 - 0xFFF I/O port range.
> > That covers the ACPI ports at 0x8xx.
> > 
> > Some printf-s.
> > From (verbose) boot time:
> > pcib1:   domain0
> > pcib1:   secondary bus 1
> > pcib1:   subordinate bus   1
> > pcib1:   memory decode 0xfea0-0xfeaf
> > pcib2:   domain0
> > pcib2:   secondary bus 2
> > pcib2:   subordinate bus   2
> > pcib2:   I/O decode0xf000-0x
> > pcib2:   memory decode 0xfe90-0xfe9f
> > 
> > My printf-s from resume time:
> > pcib1: old I/O base (low): 0xf1
> > pcib1: old I/O base (high): 0x0
> > pcib1: old I/O limit (low): 0x1
> > pcib1: old I/O limit (high): 0x0
> > pcib2: old I/O base (low): 0x1
> > pcib2: old I/O base (high): 0x0
> > pcib2: old I/O limit (low): 0x1
> > pcib2: old I/O limit (high): 0x0  
> 
> The "solution" I think is to have resume be multi-pass and to resume
> all the bridges first before trying to resume leaf devices (including
> timers), but that's a fair bit of work.  It might be that we just
> need to resume timer interrupts later after the new-bus resume (I
> think we currently do it before?), though the reason for that was to
> allow resume methods in devices to sleep (I'm not sure if any do).
> 

That sounds like a good fit for https://reviews.freebsd.org/D203 .
Someone (TM) just needs to take it over the finish line... 6 years
later.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311

[Justin Hibbits]

Hi Mark,

On Wed, 13 May 2020 01:43:23 -0700
Mark Millard  wrote:

> [I'm adding a reference to an old arm64/aarch64 bug that had
> pages turning to zero, in case this 32-bit powerpc issue is
> somewhat analogous.]
> 
> On 2020-May-13, at 00:29, Mark Millard  wrote:
> 
> > [stress alone is sufficient to have jemalloc asserts fail
> > in stress, no need for a multi-socket G4 either. No need
> > to involve nfsd, mountd, rpcbind or the like. This is not
> > a claim that I know all the problems to be the same, just
> > that a jemalloc reported failure in this simpler context
> > happens and zeroed pages are involved.]
> > 
> > Reminder: head -r360311 based context.
> > 
> > 
> > First I show a single CPU/core PowerMac G4 context failing
> > in stress. (I actually did this later, but it is the
> > simpler context.) I simply moved the media from the
> > 2-socket G4 to this slower, single-cpu/core one.
> > 
> > cpu0: Motorola PowerPC 7400 revision 2.9, 466.42 MHz
> > cpu0: Features 9c00
> > cpu0: HID0 8094c0a4
> > real memory  = 1577857024 (1504 MB)
> > avail memory = 1527508992 (1456 MB)
> > 
> > # stress -m 1 --vm-bytes 1792M
> > stress: info: [1024] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
> > :
> > /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:258:
> > Failed assertion: "slab == extent_slab_get(extent)" stress: FAIL:
> > [1024] (415) <-- worker 1025 got signal 6 stress: WARN: [1024]
> > (417) now reaping child worker processes stress: FAIL: [1024] (451)
> > failed run completed in 243s
> > 
> > (Note: 1792 is the biggest it allowed with M.)
> > 
> > The following still pages in and out and fails:
> > 
> > # stress -m 1 --vm-bytes 1290M
> > stress: info: [1163] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
> > :
> > /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:258:
> > Failed assertion: "slab == extent_slab_get(extent)" . . .
> > 
> > By contrast, the following had no problem for as
> > long as I let it run --and did not page in or out:
> > 
> > # stress -m 1 --vm-bytes 1280M
> > stress: info: [1181] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
> > 
...
> The following is was a fix for a "pages magically
> turn into zeros" problem on amd64/aarch64. The
> original 32-bit powerpc context did not seem a
> match to me --but the stress test behavior that
> I've just observed seems closer from an
> external-test point of view: swapping is involved.
> 
> My be this will suggest something to someone that
> knows what they are doing.
> 
> (Note: dsl-only.net closed down, so the E-mail
> address reference is no longer valid.)
> 
> Author: kib
> Date: Mon Apr 10 15:32:26 2017
> New Revision: 316679
> URL: 
> https://svnweb.freebsd.org/changeset/base/316679
> 
> 
> Log:
>  Do not lose dirty bits for removing PROT_WRITE on arm64.
> 
>  Arm64 pmap interprets accessed writable ptes as modified, since
>  ARMv8.0 does not track Dirty Bit Modifier in hardware. If writable
> bit is removed, page must be marked as dirty for MI VM.
> 
>  This change is most important for COW, where fork caused losing
>  content of the dirty pages which were not yet scanned by pagedaemon.
> 
>  Reviewed by: alc, andrew
>  Reported and tested by:  Mark Millard 
>  PR:  217138, 217239
>  Sponsored by:The FreeBSD Foundation
>  MFC after:   2 weeks
> 
> Modified:
>  head/sys/arm64/arm64/pmap.c
> 
> Modified: head/sys/arm64/arm64/pmap.c
> ==
> --- head/sys/arm64/arm64/pmap.c   Mon Apr 10 12:35:58
> 2017  (r316678) +++ head/sys/arm64/arm64/pmap.c   Mon Apr
> 10 15:32:26 2017  (r316679) @@ -2481,6 +2481,11 @@
> pmap_protect(pmap_t pmap, vm_offset_t sv sva += L3_SIZE) {
>   l3 = pmap_load(l3p);
>   if (pmap_l3_valid(l3)) {
> + if ((l3 & ATTR_SW_MANAGED) &&
> + pmap_page_dirty(l3)) {
> +
> vm_page_dirty(PHYS_TO_VM_PAGE(l3 &
> + ~ATTR_MASK));
> + }
>   pmap_set(l3p, ATTR_AP(ATTR_AP_RO));
>   PTE_SYNC(l3p);
>   /* XXX: Use pmap_invalidate_range */
> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
> 

Thanks for this reference.  I took a quick look at the 3 pmap
implementations we have (haven

Re: ZFS with 32-bit, non-x86 kernel

[Justin Hibbits]

On Fri, 4 Oct 2019 15:06:52 -0400
Dennis Clarke  wrote:

> On 10/4/19 10:05 AM, Andriy Gapon wrote:
> > 
> > Does anyone use ZFS with a 32-bit kernel, that is also not i386 ?
> > If you do, could you please let me know?  Along with uname -rmp
> > output. Thank you!
> >   
> 
> I don't know if that has even been attempted by anyone. The ZIL and
> ZFS log comonents require substantial amounts of memory and I am not
> aware of anyone with arm devices that have 8GB+ of memory. I have had
> FreeBSD current on RISC-V running fairly well with ZFS however that
> was a purely rv64imafdc architecture.
> 
> I will watch this thread with curiosity.
> 
> 

I did try using ZFS on 32-bit powerpc (8GB RAM), and even got a bugfix
pushed into the ZFS/Illumos repo for it, but it was too unstable to be
usable.  I'd love to try again later though.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: hdac0: Unexpected unsolicited response from address 0: 00000000

[Justin Hibbits]

On Wed, 21 Aug 2019 13:23:05 +0200
"Hartmann, O."  wrote:

> Hello list,
> 
> on a Lenovo E540 I get this weird error since I used 12-STABLE/CURRENT
> on this specific notebook. I guess it has a Optimus Intel iGPU/nVidia
> NV940 GPU system and usable is only the iGPU with port
> graphics/drm-fbsd12.0-kmod.
> 
> The notebook doesn't have audio anymore, nor can I use vlc, mplayer or
> smplayer anymore, the applications are stuck as they are waiting for
> the audio which never comes up. The same in Firefox (recent versions),
> videos, i.e. via youtube, never played since a while now.
> 
> I can't say when this problem first occured, it is now for a while,
> say 6 or 8 months so. I receive massive kernel messages on the
> console like
> 
> [...]
> hdac0: Unexpected unsolicited response from address 0: 
> hdac0: Unexpected unsolicited response from address 0: 
> hdac0: Unexpected unsolicited response from address 0: 
> [...]
> 
> What is wrong here?
> 
> Thanks,
> 
> oh
> 
> The dmesg shows:
> 
> ---<>---
> Copyright (c) 1992-2019 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
> 1994 The Regents of the University of California. All rights
> reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 12.0-STABLE #61 r351164: Sat Aug 17 08:37:38 CEST 2019
> root@toedd:/usr/obj/usr/src/amd64.amd64/sys/TOEDD amd64
> FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on
> LLVM 8.0.1)
> VT(efifb): resolution 1920x1080
> module zfsctrl already present!
> module_register: cannot register tmpfs from kernel; already loaded
> from tmpfs.ko
> Module tmpfs failed to register: 17
> CPU: Intel(R) Core(TM) i5-4200M CPU @ 2.50GHz (2494.28-MHz K8-class
> CPU) Origin="GenuineIntel"  Id=0x306c3  Family=0x6  Model=0x3c
> Stepping=3
> Features=0xbfebfbff
> Features2=0x7fdafbbf
> AMD Features=0x2c100800 AMD
> Features2=0x21 Structured Extended
> Features=0x27ab
>   Structured Extended Features3=0x9c00
>   XSAVE Features=0x1
>   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>   TSC: P-state invariant, performance statistics
> real memory  = 17179869184 (16384 MB)
> avail memory = 16439214080 (15677 MB)
> Event timer "LAPIC" quality 600
> ACPI APIC Table: 
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads
> random: unblocking device.
> Security policy loaded: MAC/ntpd (mac_ntpd)
> ioapic0  irqs 0-23 on motherboard
> Launching APs: 1 3 2
> Timecounter "TSC-low" frequency 1247140210 Hz quality 1000
> random: entropy device external interface
> kbd1 at kbdmux0
> module_register_init: MOD_LOAD (vesa, 0x80d41390, 0) error 19
> [...]
> 
> 
> [...]
> dmesg|grep hda
> hdac0:  mem 0xf161-0xf1613fff at
> device 3.0 on pci0 hdac1:  mem
> 0xf1614000-0xf1617fff at device 27.0 on pci0 hdacc0:  HDA
> CODEC> at cad 0 on hdac0 hdaa0: 
> CODEC> at nid 1 on hdacc0  
> pcm0:  at nid 3 on hdaa0
> hdacc1:  at cad 0 on hdac1
> hdaa1:  at nid 1 on hdacc1
> pcm1:  at nid 23 on
> hdaa1 pcm2:  at nid 22
> on hdaa1 hdac0: Unexpected unsolicited response from address 0:
>  hdac0: Unexpected unsolicited response from address 0:
>  hdac0: Unexpected unsolicited response from address 0:
>  hdac0: Unexpected unsolicited response from address 0:
> 

I see that on my Talos, with my Radeon card, when the PCI bus is reset.
 In my case, it causes a panic, too.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [package - head-i386-default][sysutils/lsof] Failed for lsof-4.93.2_2,8 in build

[Justin Hibbits]

On Thu, 25 Jul 2019 12:35:32 -0600
Alan Somers  wrote:

> On Thu, Jul 25, 2019 at 12:13 PM Larry Rosenman 
> wrote:
> >
> > On 07/25/2019 1:10 pm, Alan Somers wrote:  
> > > On Thu, Jul 25, 2019 at 12:05 PM Larry Rosenman 
> > > wrote:  
> > >>
> > >> Um  Who broke this?
...
> > > "svn blame" suggests r350199 by kib.  However, refcount.h should
> > > only be included if lsof defines _KERNEL, which normal programs
> > > shouldn't. So I think this should be considered a bug in lsof.
> > > -Alan  
> >
> >
> > we *HAVE* to define _KERNEL, to get at the kernel structures.  
> 
> Then I think you have to live with this amount of instability.
> refcount(9) says that you should include .  Did you do
> that?  If so, then this is a man page bug and refcount(9) should also
> specify stdbool.h.
> -Alan

 includes  already, which typedefs bool.  So
 should suffice to include in lsof.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ci.freebsd.org: powerpcspe build failing due to linker error in assembly code

[Justin Hibbits]

On Mon, 20 May 2019 17:54:12 -0700
Enji Cooper  wrote:

> Hi,
>   The following build issue has been cropping up over the past
> 6 hours. From
> https://ci.freebsd.org/job/FreeBSD-head-powerpcspe-build/11154/console :
> 
> 12:49:01 /usr/src/stand/powerpc/kboot/kerneltramp.S: Assembler
> messages: 12:49:01 /usr/src/stand/powerpc/kboot/kerneltramp.S:88:
> Error: Unrecognized opcode: `rldicr'
> 12:49:01 /usr/src/stand/powerpc/kboot/kerneltramp.S:96: Error:
> Unrecognized opcode: `rfid'
> 
>   This code hasn’t changed for some time. I’m not sure what
> triggered the issue, but I suspect it has to deal with an external
> [toolchain] change. Cheers! -Enji

It's probably r348005's fault.  It removes the ppc64bridge option.
kboot should only be built for powerpc64 anyway.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Ports build fails on 13-CURRENT r341690

[Justin Hibbits]

On Mon, 10 Dec 2018 17:34:03 +0900 (JST)
Yasuhiro KIMURA  wrote:

> Hello,
> 
> yasu@rolling-vm-freebsd1[2018]% uname -a
> FreeBSD rolling-vm-freebsd1.home.utahime.org 13.0-CURRENT FreeBSD
> 13.0-CURRENT r341690 GENERIC  amd64 yasu@rolling-vm-freebsd1[2019]%
> LANG=C svn info /usr/src Path: /usr/src
> Working Copy Root Path: /usr/src
> URL: https://svn.freebsd.org/base/head
> Relative URL: ^/head
> Repository Root: https://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 341690
> Node Kind: directory
> Schedule: normal
> Last Changed Author: kib
> Last Changed Rev: 341690
> Last Changed Date: 2018-12-08 00:19:00 +0900 (Sat, 08 Dec 2018)
> 
> yasu@rolling-vm-freebsd1[2020]% LANG=C svn info /usr/ports
> Path: /usr/ports
> Working Copy Root Path: /usr/ports
> URL: https://svn.freebsd.org/ports/head
> Relative URL: ^/head
> Repository Root: https://svn.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 487116
> Node Kind: directory
> Schedule: normal
> Last Changed Author: yuri
> Last Changed Rev: 487116
> Last Changed Date: 2018-12-10 10:06:34 +0900 (Mon, 10 Dec 2018)
> 
> 
> Build of ports-mgmt/pkg fails as following.
> 
> --
> > Compressing man pages (compress-man)  
> ===   
>   
> === > ===>  Building package for
> >pkg-1.10.5_5  
> install -l
> rs /.npkg/All/pkg-1.10.5_5.txz /.npkg/Latest/pkg.txz
> install: /.npkg/All/pkg-1.10.5_5.txz: realpath: No such file or
> directory *** Error code 71
> 
> Stop.
> make[1]: stopped in /usr/ports/ports-mgmt/pkg
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/ports-mgmt/pkg
> =>> Cleaning up wrkdir  
> ===>  Cleaning for pkg-1.10.5_5  
> build of ports-mgmt/pkg | pkg-1.10.5_5 ended at Mon Dec 10 16:49:35
> JST 2018 build time: 00:03:50
> !!! build failure encountered !!!
> --
> 
> Full build log:
> https://www.utahime.org/FreeBSD/poudriere/data/logs/bulk/curamd64-local/2018-12-10_16h45m20s/logs/errors/pkg-1.10.5_5.log
> 
> And this prevent any other ports from building.
> 
> Does anyone else experience it?
> 
> Best Regards.
> 
> ---
> Yasuhiro KIMURA

Hi,

I see the exact same problem on one of my powerpc64 machines (a
P5020-based machine). I see it intermittently on my POWER9, so thought
it was a race condition, but it's 100% reproducible on my P5020 machine.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto

[Justin Hibbits]

On Thu, Oct 11, 2018 at 7:57 PM Glen Barber  wrote:
>
> On Thu, Oct 11, 2018 at 10:55:46PM +, Glen Barber wrote:
> > On Thu, Oct 11, 2018 at 10:32:34PM +, Glen Barber wrote:
> > > I still see a failure with this applied.
> > >
> > >  ===> lib/libldns (obj,all,install)
> > >  /usr/obj/usr/src/powerpc.powerpc/tmp/usr/bin/ld: cannot find -lssl
> > >  --- libprivateldns.so.5.full ---
> > >  *** [libprivateldns.so.5.full] Error code 1
> > >
> > > I'll prune .OBJDIR and re-run without -jN to eliminate the possibility
> > > of a build race.
> > >
> >
> > It does not appear to be a build race.
> >
> >  ===> secure/lib/libcrypto (obj,all,install)
> >  /usr/src/crypto/openssl/crypto/err/err.c: In function 'err_load_strings':
> >  /usr/src/crypto/openssl/crypto/err/err.c:311: warning: passing argument 2 
> > of 'lh_ERR_STRING_DATA_insert' discards qualifiers from pointer target type
> >  /usr/src/crypto/openssl/crypto/err/err.c: In function 'err_load_strings':
> >  /usr/src/crypto/openssl/crypto/err/err.c:311: warning: passing argument 2 
> > of 'lh_ERR_STRING_DATA_insert' discards qualifiers from pointer target type
> >  /usr/obj/usr/src/powerpc.powerpc/tmp/usr/bin/ld: cannot find -lpthread
> >  *** Error code 1
> >
> >  Stop.
> >  make[4]: stopped in /usr/src/secure/lib/libcrypto
> >  *** Error code 1
> >
>
> In fact, on closer inspection, this patch breaks every architecture.
>
> Glen
>

Yes it does.  Can r339303 be reverted until DES can look at it closer?

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto

[Justin Hibbits]

On Thu, 11 Oct 2018 17:32:21 -0400
Jung-uk Kim  wrote:

> On 18. 10. 11., Justin Hibbits wrote:
> > On Thu, 11 Oct 2018 19:07:45 +
> > Glen Barber  wrote:
> >   
> >> On Thu, Oct 11, 2018 at 09:05:52AM +0200, Raúl wrote:  
> >>> Maybe related to recent Glen's Heads-UP?
> >>>
> >>> https://lists.freebsd.org/pipermail/freebsd-current/2018-October/071581.html
> >>> 
> >>
> >> No, this is different, and more recent than the heads-up.  I now
> >> see failures on powerpc, powerpc64, powerpcspe, sparc64, and arm.
> >>
> >> I'm trying to track down what commit introduced this, but it was
> >> not the final merge from the projects/openssl111 branch.
> >>
> >> Glen
> >>  
> > 
> > Seems r339303 is the cuplrit.  Reverting this gets my build
> > completing.  
> 
> It seems ldns now requires libssl.so to support DANE-TA.  Please try
> the attached patch.
> 
> Jung-uk Kim

Just patching lib/libldns is insufficient.  share/mk/src.libnames.mk
needs updated as well.  Here's a patch I tested, attached.

- Justin
Index: lib/libldns/Makefile
===
--- lib/libldns/Makefile	(revision 339318)
+++ lib/libldns/Makefile	(working copy)
@@ -19,7 +19,7 @@
 
 SRCS+=	b64_ntop.c b64_pton.c
 
-LIBADD=	crypto
+LIBADD=	ssl crypto
 
 WARNS ?= 3
 
Index: share/mk/src.libnames.mk
===
--- share/mk/src.libnames.mk	(revision 339318)
+++ share/mk/src.libnames.mk	(working copy)
@@ -273,7 +273,7 @@
 _DP_memstat=	kvm
 _DP_magic=	z
 _DP_mt=		sbuf bsdxml
-_DP_ldns=	crypto
+_DP_ldns=	ssl crypto
 .if ${MK_OPENSSL} != "no"
 _DP_fetch=	ssl crypto
 .else


pgpUyM6srNt8R.pgp
Description: OpenPGP digital signature

Re: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto

[Justin Hibbits]

On Thu, 11 Oct 2018 19:07:45 +
Glen Barber  wrote:

> On Thu, Oct 11, 2018 at 09:05:52AM +0200, Raúl wrote:
> > Maybe related to recent Glen's Heads-UP?
> > 
> > https://lists.freebsd.org/pipermail/freebsd-current/2018-October/071581.html
> >   
> 
> No, this is different, and more recent than the heads-up.  I now see
> failures on powerpc, powerpc64, powerpcspe, sparc64, and arm.
> 
> I'm trying to track down what commit introduced this, but it was not
> the final merge from the projects/openssl111 branch.
> 
> Glen
> 

Seems r339303 is the cuplrit.  Reverting this gets my build completing.

- Justin


pgpOqoFg6PKcb.pgp
Description: OpenPGP digital signature

Re: nvme0: Missing interrupt on powerpc64

[Justin Hibbits]

Hi Piotr,
On Fri, Sep 14, 2018 at 3:23 AM Piotr Kubaj via freebsd-ppc
 wrote:
>
> Hello,
>
> I'm running FreeBSD 12.0-ALPHA5 on Talos Lite (Power9). I have / on NVME 
> drive.
>
> During boot, I'm getting:
> nvme0: Missing interrupt
>
> It happens when /etc/rc.d/kldxref runs. If I press ^C, booting goes on.

This is a relatively known issue.  I see it on my Talos II (regular,
currently single-CPU).  It only affects performance, it doesn't affect
system stability, in my case anyway.  Some others have reported NVMe
crashes, but I haven't reproduced on my hardware.  We haven't yet
determined the cause of the missing interrupt, but it happens often,
and causes things to hang for a bit before continuing.

We still have a bit of work to do on the stability and performance
sides on POWER, particularly with the interrupt controller (XIVE) and
the PCIe controller.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Strange ARC/Swap/CPU on yesterday's -CURRENT

[Justin Hibbits]

Hi Mark,

On Sat, Apr 7, 2018 at 2:49 PM, Mark Johnston <ma...@freebsd.org> wrote:
> On Sat, Apr 07, 2018 at 02:34:54PM -0500, Justin Hibbits wrote:
>>
>> I reverted back to r329881, and successfully built world.  Updated to
>> r329882 and it got stuck with processes in btalloc.
>>
>> I've seen other reports of r329882 causing problems on powerpc64 as
>> well, with other bizarre behaviors.
>
> Did you try the patch that I had posted? If not, could you? Please also
> update zfs_arc_free_target or just apply D14994.

I just applied both patches, and head still locks up, but no threads
are stuck in btalloc.  The thread running when I break into ddb is
still vmdaemon.

Running 'show all vmem' on ddb shows it pretty low on kernel arena:

vmem 0xe1202900 'buffer arena'
quantum:4096
size:   775913472
inuse:  152928256
free:   622985216
busy tags:  4668
free tags:  4
inuse   sizefreesize
16384   2   32768   0   0
32768   4666152895488   1   32768
536870912   0   0   1   622952448
vmem 0xe5017000 'kernel arena dom'
quantum:4096
size:   775946240
inuse:  772923392
free:   3022848
busy tags:  144749
free tags:  3
inuse   sizefreesize
4096141305  578785280   0   0
8192243 1990656 0   0
16384   2081340951040   0
20480   290 5939200 0   0
32768   113 3702784 0   0
36864   61  2248704 0   0
65536   80  5242880 0   0
69632   2   139264  1   69632
77824   1   77824   0   0
81920   1   81920   0   0
86016   1   86016   0   0
90112   2   180224  0   0
94208   2   188416  0   0
98304   1   98304   0   0
102400  1   102400  0   0
110592  1   110592  0   0
118784  1   118784  0   0
122880  1   122880  0   0
131072  545 714342400   0
262144  2   524288  9   2428928
524288  4   2154496 1   524288
1048576 6   6995968 0   0
2097152 1   2097152 0   0
4194304 1   4194304 0   0
8388608 1   8388608 0   0
167772162   438231040   0
vmem 0xe1202180 'kernel arena'
quantum:4096
size:   2353004544
inuse:  2351603712
free:   1400832
busy tags:  600
free tags:  4
inuse   sizefreesize
40963   12288   1   4096
24576   0   0   2   49152
28672   0   0   1   28672
36864   415 152985601   36864
65536   1   65536   0   0
131072  1   131072  0   0
1048576 0   0   1   1282048
4194304 172 721420288   0   0
8388608 1   8388608 0   0
167772162   461373440   0
134217728   3   453386240   0   0
268435456   1   297295872   0   0
536870912   1   809467904   0   0

Any other numbers I can gather to debug this?

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Strange ARC/Swap/CPU on yesterday's -CURRENT

[Justin Hibbits]

Hi Don,

> I initially missed that this was on powerpc.  I believe that arch is a
> bit odd with characters unsigned by default and arithmentic shifts
> always being unsigned.  Things like that could mess up the algorithm,
> but I didn't see anything suspicious in the r329882 diff.

I think the biggest difference for powerpc64 vs amd64 in this case is
the (currently) relatively small KVA (7.5GB vs 2(?) TB).  That might
make a difference regarding VM pageout calculations.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Strange ARC/Swap/CPU on yesterday's -CURRENT

[Justin Hibbits]

On Fri, Apr 6, 2018 at 10:25 AM, Justin Hibbits <chmeeed...@gmail.com> wrote:
> On Fri, Apr 6, 2018 at 10:08 AM, Mark Johnston <ma...@freebsd.org> wrote:
>> On Fri, Apr 06, 2018 at 12:47:14AM +, Justin Hibbits wrote:
>>> My powerpc64 embedded machine is virtually unusable since these vm changes.
>>> I tried setting vfs.zfs.arc_free_target as suggested, and that didn't help
>>> at all. Eventually the machine hangs and just gets stuck in vmdaemon, with
>>> many processes in wait channel btalloc.
>>
>> You don't really have the same symptoms that Don is reporting.
>
> Okay.  I latched onto the thread because it seemed similar.
>
>> Threads being stuck in btalloc implies a KVA shortage. So:
>> - What do you mean by "stuck in vmdaemon"?
>
> The machine hangs, and my ssh sessions get killed.  I can't do
> anything at the console except break into kdb.  When I do, the running
> thread is always vmdaemon.
>
>> - Which commits specifically cause problems? Does reverting r329882 fix the
>>   hang?
>
> I'll try reverting it and report back.  Thankfully I can buildkernel
> successfully on the machine before it hangs.  Can't do more than that,
> though.

I reverted back to r329881, and successfully built world.  Updated to
r329882 and it got stuck with processes in btalloc.

I've seen other reports of r329882 causing problems on powerpc64 as
well, with other bizarre behaviors.


- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Strange ARC/Swap/CPU on yesterday's -CURRENT

[Justin Hibbits]

On Fri, Apr 6, 2018 at 10:08 AM, Mark Johnston <ma...@freebsd.org> wrote:
> On Fri, Apr 06, 2018 at 12:47:14AM +0000, Justin Hibbits wrote:
>> My powerpc64 embedded machine is virtually unusable since these vm changes.
>> I tried setting vfs.zfs.arc_free_target as suggested, and that didn't help
>> at all. Eventually the machine hangs and just gets stuck in vmdaemon, with
>> many processes in wait channel btalloc.
>
> You don't really have the same symptoms that Don is reporting.

Okay.  I latched onto the thread because it seemed similar.

> Threads being stuck in btalloc implies a KVA shortage. So:
> - What do you mean by "stuck in vmdaemon"?

The machine hangs, and my ssh sessions get killed.  I can't do
anything at the console except break into kdb.  When I do, the running
thread is always vmdaemon.

> - Which commits specifically cause problems? Does reverting r329882 fix the
>   hang?

I'll try reverting it and report back.  Thankfully I can buildkernel
successfully on the machine before it hangs.  Can't do more than that,
though.

> - Can you break to DDB and get "show page" output when the hang occurs?

I'll reproduce and get numbers today, but I do know the free_count was
high (6 digits), much higher than the free_min. when I checked
yesterday.  I'm surprised it's running out of KVA, I've never had the
problem before with the same workloads, and has ~7.5GB KVA (almost the
same size as the total RAM in the machine).

> - What is the system doing to cause the hang to occur?

Just a simple buildworld with 2 or 3 jobs (tried both).  It's 100% reproducible.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Strange ARC/Swap/CPU on yesterday's -CURRENT

[Justin Hibbits]

=
> > --- sys/vm/vm_pageout.c   (revision 331933)
> > +++ sys/vm/vm_pageout.c   (working copy)
> > @@ -1114,25 +1114,6 @@
> >   boolean_t queue_locked;
> >
> >   /*
> > -  * If we need to reclaim memory ask kernel caches to return
> > -  * some.  We rate limit to avoid thrashing.
> > -  */
> > - if (vmd == VM_DOMAIN(0) && pass > 0 &&
> > - (time_uptime - lowmem_uptime) >= lowmem_period) {
> > - /*
> > -  * Decrease registered cache sizes.
> > -  */
> > - SDT_PROBE0(vm, , , vm__lowmem_scan);
> > - EVENTHANDLER_INVOKE(vm_lowmem, VM_LOW_PAGES);
> > - /*
> > -  * We do this explicitly after the caches have been
> > -  * drained above.
> > -  */
> > - uma_reclaim();
> > - lowmem_uptime = time_uptime;
> > - }
> > -
> > - /*
> >* The addl_page_shortage is the number of temporarily
> >* stuck pages in the inactive queue.  In other words, the
> >* number of pages from the inactive count that should be
> > @@ -1824,6 +1805,26 @@
> >   atomic_store_int(>vmd_pageout_wanted, 1);
> >
> >   /*
> > +  * If we need to reclaim memory ask kernel caches to return
> > +  * some.  We rate limit to avoid thrashing.
> > +  */
> > + if (vmd == VM_DOMAIN(0) &&
> > + vmd->vmd_free_count < vmd->vmd_free_target &&
> > + (time_uptime - lowmem_uptime) >= lowmem_period) {
> > + /*
> > +      * Decrease registered cache sizes.
> > +  */
> > + SDT_PROBE0(vm, , , vm__lowmem_scan);
> > + EVENTHANDLER_INVOKE(vm_lowmem, VM_LOW_PAGES);
> > + /*
> > +  * We do this explicitly after the caches have been
> > +  * drained above.
> > +  */
> > + uma_reclaim();
> > + lowmem_uptime = time_uptime;
> > + }
> > +
> > + /*
> >* Use the controller to calculate how many pages to free
> in
> >* this interval.
> >*/
>

My powerpc64 embedded machine is virtually unusable since these vm changes.
I tried setting vfs.zfs.arc_free_target as suggested, and that didn't help
at all. Eventually the machine hangs and just gets stuck in vmdaemon, with
many processes in wait channel btalloc.

- Justin

>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: From LLVM: I got a note that LLVM plans to remove PPC64's V1 abi support; I'm asked about what support there is for the PPC64 little-endian/V2 abi (see forwarded message)

[Justin Hibbits]

On Wed, Mar 28, 2018 at 3:17 PM, A. Wilcox <awil...@wilcox-tech.com> wrote:
> On 03/28/18 13:38, Nathan Whitehorn wrote:
>> Is this big-endian support or V1 support being removed? We support
>> the V2 ABI fully on FreeBSD, but not (yet) little-endian. Like on
>> Linux, the default ABI on big-endian will likely remain V1 for the
>> indefinite future,
>
> This is an important distinction to make (big-endian != ELFv1, and ELFv1
> != big-endian).
>
> But do note that on Linux, the musl libc (in use by distros like Alpine,
> Adélie, postmarketOS) only supports ELFv2, even in big-endian mode.  And
> as the maintainer of Adélie using it as a daily-driver on an iMac G5,
> it's definitely something you can use (the only breakage I've seen so
> far on Linux is the PCRE JIT ignoring __CALL_ELF and inserting function
> descriptors anyway).
>
> So I wouldn't discount moving to ELFv2 ABI on BE if that is necessary to
> keep LLVM happy.  It'd be some effort but it should work.
>
> If this is really something FreeBSD is interested in, you might even
> manage to convince me to put on my ports hat again, to help get the JIT
> patches in that are needed for upstreams that went comatose.
>
>
> Best,
> --arw
>
>
>> however, and it would be good if it were at least simple to re-add
>> support at some later date. -Nathan
>>
>
> --
> A. Wilcox (awilfox)
> Open-source programmer (C, C++, Python)
> https://code.foxkit.us/u/awilfox/
>

Moving to ELFv2 is predicated on having a complete toolchain
supporting it.  Right now, base gcc+binutils only supports ELFv1, and
we cannot upgrade to newer toolchain yet.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Crash during boot [g_part_wither()?] @r329259

[Justin Hibbits]

On Wed, Feb 14, 2018 at 8:49 AM, David Wolfskill <da...@catwhisker.org> wrote:
> On Wed, Feb 14, 2018 at 06:09:51AM -0800, Cy Schubert wrote:
>> Try reverting this https://svnweb.freebsd.org/changeset/base/329225 for now.
>> 
>
> Aye; thanks:  after 'svn merge -c -329225 ^/head /usr/src' & a
> rebuild/install, the boot completes:
>
> FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #104  
> r329259M/329260:1200058: Wed Feb 14 06:40:10 PST 2018 
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC  
> amd64
>
> Thanks!
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> The circus around that memo helps confirm that Mr. Trump is unfit for office.
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.

Hi David,

Sorry, this was my fault.  I didn't think the partition table could
ever have NULL(incomplete?) entries, but I was wrong.  Fixed with
r329262.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: openssl in base should install c_rehash

[Justin Hibbits]

On Feb 8, 2018, at 2:15 PM, Ulrich Spörlein wrote:


2018-02-08 21:00 GMT+01:00 Jung-uk Kim <j...@freebsd.org>:


On 02/08/2018 08:52, Jan Bramkamp wrote:

On 08.02.18 14:24, Ulrich Spörlein wrote:

Hey,

c_rehash has somehow disappeared from the base system. We still
install the
manpage it seems, but the tool itself is missing. Can we have  
that back?



root@acme:/etc/ssl# locate c_rehash
...
/usr/share/openssl/man/man1/c_rehash.1.gz
/usr/src/crypto/openssl/doc/apps/c_rehash.pod
/usr/src/secure/usr.bin/openssl/man/c_rehash.1


The port seems to install it just fine:

root@acme:/etc/ssl# grep -r c_rehash /usr/ports/
/usr/ports/security/openssl/pkg-plist:bin/c_rehash
/usr/ports/security/openssl/pkg-plist:man/man1/c_rehash.1.gz

It looks like the merge of OpenSSL 1.0.1c got rid of it (if I'm
reading the
history with git pickaxe right).


The LibreSSL port lacks a c_rehash script as well. Putting  
c_rehash back

into base wouldn't solve the problem because it requires Perl 5.


Correct.  I just removed the manual page to not confuse users.

https://svnweb.freebsd.org/changeset/base/329024

Thanks for letting me know!

Jung-uk Kim


I would rather that c_rehash is brought back. I can install perl  
just fine
(or have it anyway installed), that's not the case with openssl from  
ports,

as that will mess up many things.

Guess I'll download my own version ... :(

Uli


Would this be something useful to add to src/tools?  Or create an  
explicit port for it?  Or just keep it handy yourself?


- Justin

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: C++ in jemalloc

[Justin Hibbits]

Hi Mark,

On Thu, Oct 5, 2017 at 11:58 PM, Mark Millard <mar...@dsl-only.net> wrote:
> Warner Losh imp at bsdimp.com wrote on
> Thu Oct 5 21:01:26 UTC 2017 :
>
>> Starting in FreeBSD 11, arm and powerpc are supported by clang,
>> but not super well. For FreeBSD 12, we're getting close for everything
>> except sparc64 (whose fate has not yet been finally decided).
>
> My understanding of the powerpc and powerpc64 status
> follows. This is based on my use of head via clang
> as much as I can for them.
>
> For TARGET_ARCH=powerpc64 and TARGET_ARCH=powerpc :
>
> lld is far from working last I knew. (I've focused
> more on the compilers for testing, using other
> linkers and such.) [lldb may be in a similar state
> for powerpc64. It does not build for powerpc.]
>
> clang 5 (and 4) generated code crashes on any thrown
> C++ exception. For example:
>
> #include 
>
> int main(void)
> {
> try { throw std::exception(); }
> catch (std::exception& e) {}
> return 0;
> }
>
> crashes.
>
> Luckily most kernel and world code that I actively use
> does not throw C++ exceptions in my use.

Do you see this problem using libstdc++, et al, from base gcc 4.2.1?
Or using libc++?

I don't have the time right now to look into it, but if no one else is
able to in the next couple months I'll try to make the time when
higher priorities are done.

>
> But devel/kyua is majorly broken by the C++ exception
> issue: It makes extensive use of C++ exceptions. In my
> view that disqualifies clang as being "close": I view
> my activity as a hack until devel/kyua is generally
> operable and so available for use in testing.
>
> clang 5 currently can not build the TARGET_ARCH=powerpc
> kernel. (I was able to back in clang 4 days --but the
> resultant build failed to execute init fully after
> finishing the prior boot activity.) For the 32-bit
> context I use gcc 4.2.1 for building the kernel and
> clang 5 for building the world, system binutils
> in use in both cases.

What problem(s) do you see with this?  If they're just compile time
failures they can be fixed pretty readily.

>
> I do build the kernel and world for
> TARGET_ARCH=powerpc64 via system clang 5. But I
> use ports binutils as well in order for this to
> finish and work overall.
>
>
> As for more modern devel/powerpc64-xtoolchain-gcc
> (so devel/powerpc64-gcc) versions being used to
> build the world and kernel for powerpc64 I've never
> been able to get lib32 on powerpc64 to work via
> such a build: it builds but fails to execute from
> dereferencing via an R30 that has an inappropriate
> value for the attempt ( lib32/crtbeginS.o code in
> _init in /usr/lib32/libc.so.* ). (The clang-based
> builds do not have this problem.) It has been a
> while since I've done devel/powerpc64-gcc
> experiments.
>
> I'm not aware of a devel/powerpc-xtoolchain-gcc
> as an alternative for 32-bit powerpc targeting.

There's documentation floating around (on the wiki maybe?) for doing
this.  I won't check now, but it's not difficult (not trivial, but not
difficult).  With the proposal to eliminate gcc 4.2.1 from our tree by
the end of the year, we need to get everything in place to make a
seamless transition, whether it be to external toolchain or to finish
up clang for powerpc.  I really hope we can finish up clang.  Please
continue to file bugs with as much detail as necessary to track down
and fix the problems--both in FreeBSD and upstream LLVM.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: hang in dlclose() on rtld lock (powerpc64)

[Justin Hibbits]

On Thursday, March 9, 2017, Konstantin Belousov <kostik...@gmail.com> wrote:

> On Thu, Mar 09, 2017 at 09:59:00AM -0600, Justin Hibbits wrote:
> > When building ports in poudriere, I see gdk-pixbuf-query-modules and
> > gio-querymodules hanging on r314676, but working in r305820.  I took a
> > backtrace on both in gdb, and see the following (identical between both):
> >
> > Program received signal SIGINT, Interrupt.
> > 0x506831d8 in .__sys.umtx_op () from /lib/libc.so.7
> > (gdb) bt
> > #0  0x506831d8 in .__sys.umtx_op () from /lib/libc.so.7
> > #1  0x50588010 in _umtx_op_err (obj=0x4, op=13, val=0, uaddr=0x0,
> > uaddr2=0x0)
> > at /home/chmeee/freebsd/pristine/lib/libthr/thread/thr_umtx.c:37
> > #2  0x505881b8 in __thr_rwlock_wrlock (rwlock=,
> > tsp=)
> > at /home/chmeee/freebsd/pristine/lib/libthr/thread/thr_umtx.c:325
> > #3  0x505965f0 in _thr_rwlock_wrlock (tsp=,
> > rwlock=)
> > at /home/chmeee/freebsd/pristine/lib/libthr/thread/thr_umtx.h:239
> > #4  _thr_rtld_wlock_acquire (lock=0x505bdd00)
> > at /home/chmeee/freebsd/pristine/lib/libthr/thread/thr_rtld.c:141
> > #5  0x50026bf4 in wlock_acquire (lock=0x5004cf20 ,
> > lockstate=0xcab0)
> > at /home/chmeee/freebsd/pristine/libexec/rtld-elf/rtld_lock.c:222
> > #6  0x50022b1c in dlclose (handle=0x51d62000)
> > at /home/chmeee/freebsd/pristine/libexec/rtld-elf/rtld.c:3021
> > #7  0x50022c90 in free_needed_filtees (n=0x509f7420)
> > at /home/chmeee/freebsd/pristine/libexec/rtld-elf/rtld.c:2113
> > #8  0x50022d18 in unload_filtees (obj=0x509fa800)
> > at /home/chmeee/freebsd/pristine/libexec/rtld-elf/rtld.c:2129
> > #9  0x50022e54 in unload_object (root=)
> > at /home/chmeee/freebsd/pristine/libexec/rtld-elf/rtld.c:4464
> > #10 0x50022c20 in dlclose (handle=0x50054000)
> > at /home/chmeee/freebsd/pristine/libexec/rtld-elf/rtld.c:3044
> > ---Type  to continue, or q  to quit---q
> >
> >
> > This happens on powerpc64.  I haven't tested on powerpc or any other
> arch.
>
> Please test the following patch.  It avoids recursing on the bind lock.
>
> diff --git a/libexec/rtld-elf/rtld.c b/libexec/rtld-elf/rtld.c
> index a7c61b2d13f..880cf100c45 100644
> --- a/libexec/rtld-elf/rtld.c
> +++ b/libexec/rtld-elf/rtld.c
> @@ -77,6 +77,7 @@ static void digest_dynamic2(Obj_Entry *, const Elf_Dyn
> *, const Elf_Dyn *,
>  static void digest_dynamic(Obj_Entry *, int);
>  static Obj_Entry *digest_phdr(const Elf_Phdr *, int, caddr_t, const char
> *);
>  static Obj_Entry *dlcheck(void *);
> +static int dlclose_locked(void *, RtldLockState *);
>  static Obj_Entry *dlopen_object(const char *name, int fd, Obj_Entry
> *refobj,
>  int lo_flags, int mode, RtldLockState *lockstate);
>  static Obj_Entry *do_load_object(int, const char *, char *, struct stat
> *, int);
> @@ -98,7 +99,7 @@ static void initlist_add_objects(Obj_Entry *, Obj_Entry
> *, Objlist *);
>  static void linkmap_add(Obj_Entry *);
>  static void linkmap_delete(Obj_Entry *);
>  static void load_filtees(Obj_Entry *, int flags, RtldLockState *);
> -static void unload_filtees(Obj_Entry *);
> +static void unload_filtees(Obj_Entry *, RtldLockState *);
>  static int load_needed_objects(Obj_Entry *, int);
>  static int load_preload_objects(void);
>  static Obj_Entry *load_object(const char *, int fd, const Obj_Entry *,
> int);
> @@ -142,7 +143,7 @@ static int symlook_obj1_sysv(SymLook *, const
> Obj_Entry *);
>  static int symlook_obj1_gnu(SymLook *, const Obj_Entry *);
>  static void trace_loaded_objects(Obj_Entry *);
>  static void unlink_object(Obj_Entry *);
> -static void unload_object(Obj_Entry *);
> +static void unload_object(Obj_Entry *, RtldLockState *lockstate);
>  static void unref_dag(Obj_Entry *);
>  static void ref_dag(Obj_Entry *);
>  static char *origin_subst_one(Obj_Entry *, char *, const char *,
> @@ -2104,13 +2105,13 @@ initlist_add_objects(Obj_Entry *obj, Obj_Entry
> *tail, Objlist *list)
>  #endif
>
>  static void
> -free_needed_filtees(Needed_Entry *n)
> +free_needed_filtees(Needed_Entry *n, RtldLockState *lockstate)
>  {
>  Needed_Entry *needed, *needed1;
>
>  for (needed = n; needed != NULL; needed = needed->next) {
> if (needed->obj != NULL) {
> -   dlclose(needed->obj);
> +   dlclose_locked(needed->obj, lockstate);
> needed->obj = NULL;
> }
>  }
> @@ -2121,14 +2122,14 @@ free_needed_filtees(Needed_Entry *n)
>  }
>
>  static void
> -unload_filtees(

hang in dlclose() on rtld lock (powerpc64)

[Justin Hibbits]

When building ports in poudriere, I see gdk-pixbuf-query-modules and
gio-querymodules hanging on r314676, but working in r305820.  I took a
backtrace on both in gdb, and see the following (identical between both):

Program received signal SIGINT, Interrupt.
0x506831d8 in .__sys.umtx_op () from /lib/libc.so.7
(gdb) bt
#0  0x506831d8 in .__sys.umtx_op () from /lib/libc.so.7
#1  0x50588010 in _umtx_op_err (obj=0x4, op=13, val=0, uaddr=0x0,
uaddr2=0x0)
at /home/chmeee/freebsd/pristine/lib/libthr/thread/thr_umtx.c:37
#2  0x505881b8 in __thr_rwlock_wrlock (rwlock=,
tsp=)
at /home/chmeee/freebsd/pristine/lib/libthr/thread/thr_umtx.c:325
#3  0x505965f0 in _thr_rwlock_wrlock (tsp=,
rwlock=)
at /home/chmeee/freebsd/pristine/lib/libthr/thread/thr_umtx.h:239
#4  _thr_rtld_wlock_acquire (lock=0x505bdd00)
at /home/chmeee/freebsd/pristine/lib/libthr/thread/thr_rtld.c:141
#5  0x50026bf4 in wlock_acquire (lock=0x5004cf20 ,
lockstate=0xcab0)
at /home/chmeee/freebsd/pristine/libexec/rtld-elf/rtld_lock.c:222
#6  0x50022b1c in dlclose (handle=0x51d62000)
at /home/chmeee/freebsd/pristine/libexec/rtld-elf/rtld.c:3021
#7  0x50022c90 in free_needed_filtees (n=0x509f7420)
at /home/chmeee/freebsd/pristine/libexec/rtld-elf/rtld.c:2113
#8  0x50022d18 in unload_filtees (obj=0x509fa800)
at /home/chmeee/freebsd/pristine/libexec/rtld-elf/rtld.c:2129
#9  0x50022e54 in unload_object (root=)
at /home/chmeee/freebsd/pristine/libexec/rtld-elf/rtld.c:4464
#10 0x50022c20 in dlclose (handle=0x50054000)
at /home/chmeee/freebsd/pristine/libexec/rtld-elf/rtld.c:3044
---Type  to continue, or q  to quit---q


This happens on powerpc64.  I haven't tested on powerpc or any other arch.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: PowerMac G5 and KMS

[Justin Hibbits]

On Thu, Mar 2, 2017 at 5:42 AM, Hiroo Ono (小野寛生)
<hiroo.ono+free...@gmail.com> wrote:
> I recently installed 12-current powerpc64 r313561 to a PowerMac G5
>  (it is dual processor, but I do not know its detail).
>
> When I try to load drm2.ko and radeonkms.ko,
> the screen turns into black and recovers, then the system locks.
> kldload command does not return, no response to keyboard input, etc.
>
> Is it possible to use KMS on FreeBSD/powerpc64?
>
> The log in /var/log/messages is
>
> after "kldload drm2",
>
> kernel: info: [drm] Initialized drm 1.1.0 20060810
>
> and then, after "kldload radeonkms",
>
> kernel: iic0:  on iicbus0
> kernel: iic1:  on iicbus1
> kernel: drmn0:  on vgapci0
> kernel: info: [drm] RADEON_IS_AGP
> kernel: info: [drm] initializing kernel modesetting (RV350 0x1002:0x4150
> 0x1002:0x4150).
> kernel: info: [drm] register mmio base: 0x9000
> kernel: info: [drm] register mmio size: 65536
> kernel: info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM...
> kernel: info: [drm] igp_read_bios_from_vram: VRAM base address: 0x9800
> kernel: info: [drm] igp_read_bios_from_vram: Map address:
> 0xc00061412000 (262144 bytes)
> kernel: info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature:
> 0x
> kernel: info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM...
> kernel: info: [drm] radeon_read_bios: Map address: 0xc00061412000
> (131072 bytes)
> kernel: info: [drm] radeon_read_bios: Incorrect BIOS signature: 0x2AFF
> kernel: info: [drm] legacy_read_disabled_bios: ===> Try disabled BIOS
> (legacy)...
> kernel: info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM...
> kernel: info: [drm] radeon_read_bios: Map address: 0xc00061412000
> (131072 bytes)
>
> As the system locks up here, I have to power it off forcibly.

Congratulations (?) you are quite possibly the first person to report
even attempting to use radeonkms on powerpc64.  Frankly, I'm not
surprised that it doesn't work for you.  Unfortunately, I don't have a
solution, or even a means to track it down.  Looking at the log
snippet, my first guess is there may need to be a provision added to
the driver for non-x86.  Do you know what card this is?

Adding a couple other lists with people who might have more insight.

If it can be made to work, I'd definitely want to get a Radeon card for my G5(s)

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860]

[Justin Hibbits]

My buildworld completed successfully, so it's been fixed in r308873/ 
r308874.


Thanks for your testing.  I often build just kernel, so wouldn't have  
seen the fallout until it was far too late.


- Justin

On Nov 19, 2016, at 10:22 PM, Mark Millard wrote:

On 2016-Nov-16, at 8:33 PM, Justin Hibbits <jhibb...@freebsd.org>  
wrote:


*sigh* okay, thanks.  I just tested, and vm/vm_page.h, and vm/vm.h  
can both be removed from memstat_uma.c for it to compile.  I'm  
kicking off a buildworld myself now, too, and hope to have it ready  
to commit tomorrow (takes a couple hours to buildworld on my G5).


- Justin


That will not be the only potential place: umastat.c in tools/tools/ 
umastat/

also has a include of vm/vm_page.h:

# find /usr/src/ -name .svn -prune -o -name sys -prune -o -name man  
-prune -o -exec grep "vm_page[.]h" {} \; -print | more

#include 
/usr/src/lib/libmemstat/memstat_uma.c
#define LIBMEMSTAT  /* Cause vm_page.h not to include  
opt_vmpage.h */

#include 
/usr/src/tools/tools/umastat/umastat.c



===
Mark Millard
markmi at dsl-only.net

On Nov 19, 2016, at 9:47 PM, Mark Millard wrote:


[Top post of bad news.]

With the patch I get a different incomplete type used in libmemstat:

struct md_page

--- all_subdir_lib/libmemstat ---
In file included from /usr/src/lib/libmemstat/memstat_uma.c:34:0:
/usr/src/sys/vm/vm_page.h:144:17: error: field 'md' has incomplete  
type

struct md_page md;  /* machine dependent stuff */
  ^
*** [memstat_uma.o] Error code 1

make[5]: stopped in /usr/src/lib/libmemstat


===
Mark Millard
markmi at dsl-only.net

On 2016-Nov-19, at 7:42 PM, Mark Millard   
wrote:


On 2016-Nov-19, at 7:36 PM, Mark Millard   
wrote:


On 2016-Nov-19, at 7:32 PM, Justin Hibbits freebsd.org> wrote:


Sorry, I generated the diff from a different tree that wasn't  
synced to head (had the same change in both trees originally).  
If that is the only problem, you can ignore it and try the rest.  
I can generate another diff later too.

- Justin


Yep: I manually did the move of the pm_stats line and am building.


If it builds and I install it on a PowerMac G5 and it boots, what  
do I

do to test if pm_stats and pm_mtx seems to be working well/right for
the out of kernel code? Do you know of a reasonable test?

===
Mark Millard
markmi at  dsl-only.net


On Nov 19, 2016 21:27, "Mark Millard"  wrote:

[Top post about patch issues.]

Looking at the patch it seems to be designed for when #else was in  
use:



-#else
+#elif defined(BOOKE)


but -r308817 already has the 2nd line (BOOKE). Your patch shows:


Index: sys/powerpc/include/pmap.h
===
--- sys/powerpc/include/pmap.h  (revision 308718)
+++ sys/powerpc/include/pmap.h  (working copy)


So it looks like you started from before -r308817 .

Trying it (I'm at -r308860):


Patching file sys/powerpc/include/pmap.h using Plan A...
Hunk #1 succeeded at 74.
Hunk #2 succeeded at 84.
Hunk #3 succeeded at 132.
Hunk #4 succeeded at 145.
Hunk #5 failed at 180.
Hunk #6 succeeded at 194.
Hunk #7 succeeded at 210.
1 out of 7 hunks failed--saving rejects to sys/powerpc/include/ 
pmap.h.rej



# more sys/powerpc/include/pmap.h.rej
@@ -179,13 +180,13 @@
struct slb **slb_alloc_user_cache(void);
void   slb_free_user_cache(struct slb **);

-#else
+#elif defined(BOOKE)

struct pmap {
+   struct pmap_statistics  pm_stats;   /* pmap  
statistics */

   struct mtx  pm_mtx; /* pmap mutex */
   tlbtid_tpm_tid[MAXCPU]; /* TID to identify  
this pmap entries in TLB */

   cpuset_tpm_active;  /* active on cpus */
-   struct pmap_statistics  pm_stats;   /* pmap  
statistics */


   /* Page table directory, array of pointers to page tables. */
   pte_t   *pm_pdir[PDIR_NENTRIES];



===
Mark Millard
markmi at dsl-only.net

On 2016-Nov-19, at 7:00 PM, Mark Millard   
wrote:


It may take a little bit but I'll try the patch.

It looks like sys/powerpc/include/pmap.h from -r176700 from 2088- 
Mar-3
is when the BOOKE/E500 split started with the preprocessor use of  
AIM

and #else . This predates PowerMac G5 support.

This is definitely not new for the general structure on the powerpc
side of things. Any place that did not have the AIM vs. not status
available was subject to problems of possibly mismatched  
definitions.


===
Mark Millard
markmi at dsl-only.net

On 2016-Nov-19, at 6:47 PM, Justin Hibbits freebsd.org> wrote:


On Sat, 19 Nov 2016 18:36:39 -0800
Mark Millard  wrote:


[Quick top post I'm afraid.]

I think that I figured out why there is a problem even earlier
--that just did not stop the compiles.

lib/libutil/kinfo_getallproc.c is built here as part of buildworld
(stage 4.2 "building libraries" instead of buildkernel. It does not
have the KERNCONF's AIM vs. BOOKE vs. . . . definitions vs. lack of
them).

So if it includes machine/pmap.h that

Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860]

[Justin Hibbits]

umastat doesn't even build right now anyway.  I just tried:

[chmeee@zhabar:pts/29]:~...tools/umastat> make
echo umastat.full: /usr/lib/libc.a /usr/lib/libkvm.a >> .depend
Warning: Object directory not changed from original /home/chmeee/ 
freebsd/head/tools/tools/umastat
cc  -O2 -pipe   -g -MD  -MF.depend.umastat.o -MTumastat.o -std=gnu99 - 
fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k  
-W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes - 
Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c umastat.c - 
o umastat.o
umastat.c:136: error: 'UMA_ZONE_REFCNT' undeclared here (not in a  
function)

*** Error code 1


- Justin

On Nov 19, 2016, at 10:22 PM, Mark Millard wrote:

On 2016-Nov-16, at 8:33 PM, Justin Hibbits <jhibb...@freebsd.org>  
wrote:


*sigh* okay, thanks.  I just tested, and vm/vm_page.h, and vm/vm.h  
can both be removed from memstat_uma.c for it to compile.  I'm  
kicking off a buildworld myself now, too, and hope to have it ready  
to commit tomorrow (takes a couple hours to buildworld on my G5).


- Justin


That will not be the only potential place: umastat.c in tools/tools/ 
umastat/

also has a include of vm/vm_page.h:

# find /usr/src/ -name .svn -prune -o -name sys -prune -o -name man  
-prune -o -exec grep "vm_page[.]h" {} \; -print | more

#include 
/usr/src/lib/libmemstat/memstat_uma.c
#define LIBMEMSTAT  /* Cause vm_page.h not to include  
opt_vmpage.h */

#include 
/usr/src/tools/tools/umastat/umastat.c



===
Mark Millard
markmi at dsl-only.net

On Nov 19, 2016, at 9:47 PM, Mark Millard wrote:


[Top post of bad news.]

With the patch I get a different incomplete type used in libmemstat:

struct md_page

--- all_subdir_lib/libmemstat ---
In file included from /usr/src/lib/libmemstat/memstat_uma.c:34:0:
/usr/src/sys/vm/vm_page.h:144:17: error: field 'md' has incomplete  
type

struct md_page md;  /* machine dependent stuff */
  ^
*** [memstat_uma.o] Error code 1

make[5]: stopped in /usr/src/lib/libmemstat


===
Mark Millard
markmi at dsl-only.net

On 2016-Nov-19, at 7:42 PM, Mark Millard   
wrote:


On 2016-Nov-19, at 7:36 PM, Mark Millard   
wrote:


On 2016-Nov-19, at 7:32 PM, Justin Hibbits freebsd.org> wrote:


Sorry, I generated the diff from a different tree that wasn't  
synced to head (had the same change in both trees originally).  
If that is the only problem, you can ignore it and try the rest.  
I can generate another diff later too.

- Justin


Yep: I manually did the move of the pm_stats line and am building.


If it builds and I install it on a PowerMac G5 and it boots, what  
do I

do to test if pm_stats and pm_mtx seems to be working well/right for
the out of kernel code? Do you know of a reasonable test?

===
Mark Millard
markmi at  dsl-only.net


On Nov 19, 2016 21:27, "Mark Millard"  wrote:

[Top post about patch issues.]

Looking at the patch it seems to be designed for when #else was in  
use:



-#else
+#elif defined(BOOKE)


but -r308817 already has the 2nd line (BOOKE). Your patch shows:


Index: sys/powerpc/include/pmap.h
===
--- sys/powerpc/include/pmap.h  (revision 308718)
+++ sys/powerpc/include/pmap.h  (working copy)


So it looks like you started from before -r308817 .

Trying it (I'm at -r308860):


Patching file sys/powerpc/include/pmap.h using Plan A...
Hunk #1 succeeded at 74.
Hunk #2 succeeded at 84.
Hunk #3 succeeded at 132.
Hunk #4 succeeded at 145.
Hunk #5 failed at 180.
Hunk #6 succeeded at 194.
Hunk #7 succeeded at 210.
1 out of 7 hunks failed--saving rejects to sys/powerpc/include/ 
pmap.h.rej



# more sys/powerpc/include/pmap.h.rej
@@ -179,13 +180,13 @@
struct slb **slb_alloc_user_cache(void);
void   slb_free_user_cache(struct slb **);

-#else
+#elif defined(BOOKE)

struct pmap {
+   struct pmap_statistics  pm_stats;   /* pmap  
statistics */

   struct mtx  pm_mtx; /* pmap mutex */
   tlbtid_tpm_tid[MAXCPU]; /* TID to identify  
this pmap entries in TLB */

   cpuset_tpm_active;  /* active on cpus */
-   struct pmap_statistics  pm_stats;   /* pmap  
statistics */


   /* Page table directory, array of pointers to page tables. */
   pte_t   *pm_pdir[PDIR_NENTRIES];



===
Mark Millard
markmi at dsl-only.net

On 2016-Nov-19, at 7:00 PM, Mark Millard   
wrote:


It may take a little bit but I'll try the patch.

It looks like sys/powerpc/include/pmap.h from -r176700 from 2088- 
Mar-3
is when the BOOKE/E500 split started with the preprocessor use of  
AIM

and #else . This predates PowerMac G5 support.

This is definitely not new for the general structure on the powerpc
side of things. Any place that did not have the AIM vs. not status
available was subject to problems of possibly mismatched  
definitions.


===
Mark Millard
markmi at dsl-only.net

On 2016-Nov-19, at 6:47 PM, Justin Hi

Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860]

[Justin Hibbits]

*sigh* okay, thanks.  I just tested, and vm/vm_page.h, and vm/vm.h can  
both be removed from memstat_uma.c for it to compile.  I'm kicking off  
a buildworld myself now, too, and hope to have it ready to commit  
tomorrow (takes a couple hours to buildworld on my G5).


- Justin

On Nov 19, 2016, at 9:47 PM, Mark Millard wrote:


[Top post of bad news.]

With the patch I get a different incomplete type used in libmemstat:

struct md_page

--- all_subdir_lib/libmemstat ---
In file included from /usr/src/lib/libmemstat/memstat_uma.c:34:0:
/usr/src/sys/vm/vm_page.h:144:17: error: field 'md' has incomplete  
type

 struct md_page md;  /* machine dependent stuff */
^
*** [memstat_uma.o] Error code 1

make[5]: stopped in /usr/src/lib/libmemstat


===
Mark Millard
markmi at dsl-only.net

On 2016-Nov-19, at 7:42 PM, Mark Millard   
wrote:


On 2016-Nov-19, at 7:36 PM, Mark Millard   
wrote:


On 2016-Nov-19, at 7:32 PM, Justin Hibbits freebsd.org> wrote:


Sorry, I generated the diff from a different tree that wasn't  
synced to head (had the same change in both trees originally). If  
that is the only problem, you can ignore it and try the rest. I  
can generate another diff later too.

- Justin


Yep: I manually did the move of the pm_stats line and am building.


If it builds and I install it on a PowerMac G5 and it boots, what  
do I

do to test if pm_stats and pm_mtx seems to be working well/right for
the out of kernel code? Do you know of a reasonable test?

===
Mark Millard
markmi at  dsl-only.net


On Nov 19, 2016 21:27, "Mark Millard"  wrote:

[Top post about patch issues.]

Looking at the patch it seems to be designed for when #else was in  
use:



-#else
+#elif defined(BOOKE)


but -r308817 already has the 2nd line (BOOKE). Your patch shows:


Index: sys/powerpc/include/pmap.h
===
--- sys/powerpc/include/pmap.h  (revision 308718)
+++ sys/powerpc/include/pmap.h  (working copy)


So it looks like you started from before -r308817 .

Trying it (I'm at -r308860):


Patching file sys/powerpc/include/pmap.h using Plan A...
Hunk #1 succeeded at 74.
Hunk #2 succeeded at 84.
Hunk #3 succeeded at 132.
Hunk #4 succeeded at 145.
Hunk #5 failed at 180.
Hunk #6 succeeded at 194.
Hunk #7 succeeded at 210.
1 out of 7 hunks failed--saving rejects to sys/powerpc/include/ 
pmap.h.rej



# more sys/powerpc/include/pmap.h.rej
@@ -179,13 +180,13 @@
struct slb **slb_alloc_user_cache(void);
void   slb_free_user_cache(struct slb **);

-#else
+#elif defined(BOOKE)

struct pmap {
+   struct pmap_statistics  pm_stats;   /* pmap statistics  
*/

 struct mtx  pm_mtx; /* pmap mutex */
 tlbtid_tpm_tid[MAXCPU]; /* TID to identify  
this pmap entries in TLB */

 cpuset_tpm_active;  /* active on cpus */
-   struct pmap_statistics  pm_stats;   /* pmap statistics  
*/


 /* Page table directory, array of pointers to page tables. */
 pte_t   *pm_pdir[PDIR_NENTRIES];



===
Mark Millard
markmi at dsl-only.net

On 2016-Nov-19, at 7:00 PM, Mark Millard   
wrote:


It may take a little bit but I'll try the patch.

It looks like sys/powerpc/include/pmap.h from -r176700 from 2088- 
Mar-3

is when the BOOKE/E500 split started with the preprocessor use of AIM
and #else . This predates PowerMac G5 support.

This is definitely not new for the general structure on the powerpc
side of things. Any place that did not have the AIM vs. not status
available was subject to problems of possibly mismatched definitions.

===
Mark Millard
markmi at dsl-only.net

On 2016-Nov-19, at 6:47 PM, Justin Hibbits freebsd.org> wrote:


On Sat, 19 Nov 2016 18:36:39 -0800
Mark Millard  wrote:


[Quick top post I'm afraid.]

I think that I figured out why there is a problem even earlier
--that just did not stop the compiles.

lib/libutil/kinfo_getallproc.c is built here as part of buildworld
(stage 4.2 "building libraries" instead of buildkernel. It does not
have the KERNCONF's AIM vs. BOOKE vs. . . . definitions vs. lack of
them).

So if it includes machine/pmap.h that binds to
sys/powerpc/include/pmap.h which has the structure. . .

. . .
#if defined(AIM)
. . . (definitions here)
#elif defined(BOOKE)
. . . (definitions here)
#endif
. . .

it gets no definition now.

With the older:

. . .
#if defined(AIM)
. . . (definitions here)
#else
. . . (definitions here)
#endif
. . .

It got a definition, just not necessarily the right one.


===
Mark Millard
markmi at dsl-only.net


Can you try the attached patch?  There was a subtle ABI issue that
r308817 exposed, which is that the pmap structs aren't identical such
that the pm_stats are at different locations, and libkvm ends up
reading with the Book-E pmap, getting different stats than expected  
for

AIM.  This patch fixes that, bumping version to account for 

Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860]

[Justin Hibbits]

On Nov 19, 2016 21:42, "Mark Millard" <mar...@dsl-only.net> wrote:
>
> On 2016-Nov-19, at 7:36 PM, Mark Millard  wrote:
>
> > On 2016-Nov-19, at 7:32 PM, Justin Hibbits 
wrote:
> >
> >> Sorry, I generated the diff from a different tree that wasn't synced
to head (had the same change in both trees originally). If that is the only
problem, you can ignore it and try the rest. I can generate another diff
later too.
> >> - Justin
> >
> > Yep: I manually did the move of the pm_stats line and am building.
>
> If it builds and I install it on a PowerMac G5 and it boots, what do I
> do to test if pm_stats and pm_mtx seems to be working well/right for
> the out of kernel code? Do you know of a reasonable test?
>
> ===
> Mark Millard
> markmi at  dsl-only.net

I think using procstat should work. Not at my machine right now so can't
really check the man page, but libprocstat and libkvm both read vmspace, so
that's a likely candidate.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860]

[Justin Hibbits]

Sorry, I generated the diff from a different tree that wasn't synced to
head (had the same change in both trees originally). If that is the only
problem, you can ignore it and try the rest. I can generate another diff
later too.

- Justin

On Nov 19, 2016 21:27, "Mark Millard" <mar...@dsl-only.net> wrote:

> [Top post about patch issues.]
>
> Looking at the patch it seems to be designed for when #else was in use:
>
> > -#else
> > +#elif defined(BOOKE)
>
> but -r308817 already has the 2nd line (BOOKE). Your patch shows:
>
> > Index: sys/powerpc/include/pmap.h
> > ===
> > --- sys/powerpc/include/pmap.h  (revision 308718)
> > +++ sys/powerpc/include/pmap.h  (working copy)
>
> So it looks like you started from before -r308817 .
>
> Trying it (I'm at -r308860):
>
> > Patching file sys/powerpc/include/pmap.h using Plan A...
> > Hunk #1 succeeded at 74.
> > Hunk #2 succeeded at 84.
> > Hunk #3 succeeded at 132.
> > Hunk #4 succeeded at 145.
> > Hunk #5 failed at 180.
> > Hunk #6 succeeded at 194.
> > Hunk #7 succeeded at 210.
> > 1 out of 7 hunks failed--saving rejects to sys/powerpc/include/pmap.h.rej
>
> > # more sys/powerpc/include/pmap.h.rej
> > @@ -179,13 +180,13 @@
> >  struct slb **slb_alloc_user_cache(void);
> >  void   slb_free_user_cache(struct slb **);
> >
> > -#else
> > +#elif defined(BOOKE)
> >
> >  struct pmap {
> > +   struct pmap_statistics  pm_stats;   /* pmap statistics */
> > struct mtx  pm_mtx; /* pmap mutex */
> > tlbtid_tpm_tid[MAXCPU]; /* TID to identify this
> pmap entries in TLB */
> > cpuset_tpm_active;  /* active on cpus */
> > -   struct pmap_statistics  pm_stats;   /* pmap statistics */
> >
> > /* Page table directory, array of pointers to page tables. */
> > pte_t   *pm_pdir[PDIR_NENTRIES];
>
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> On 2016-Nov-19, at 7:00 PM, Mark Millard <mar...@dsl-only.net> wrote:
>
> It may take a little bit but I'll try the patch.
>
> It looks like sys/powerpc/include/pmap.h from -r176700 from 2088-Mar-3
> is when the BOOKE/E500 split started with the preprocessor use of AIM
> and #else . This predates PowerMac G5 support.
>
> This is definitely not new for the general structure on the powerpc
> side of things. Any place that did not have the AIM vs. not status
> available was subject to problems of possibly mismatched definitions.
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> On 2016-Nov-19, at 6:47 PM, Justin Hibbits 
> wrote:
>
> On Sat, 19 Nov 2016 18:36:39 -0800
> Mark Millard  wrote:
>
> > [Quick top post I'm afraid.]
> >
> > I think that I figured out why there is a problem even earlier
> > --that just did not stop the compiles.
> >
> > lib/libutil/kinfo_getallproc.c is built here as part of buildworld
> > (stage 4.2 "building libraries" instead of buildkernel. It does not
> > have the KERNCONF's AIM vs. BOOKE vs. . . . definitions vs. lack of
> > them).
> >
> > So if it includes machine/pmap.h that binds to
> > sys/powerpc/include/pmap.h which has the structure. . .
> >
> > . . .
> > #if defined(AIM)
> > . . . (definitions here)
> > #elif defined(BOOKE)
> > . . . (definitions here)
> > #endif
> > . . .
> >
> > it gets no definition now.
> >
> > With the older:
> >
> > . . .
> > #if defined(AIM)
> > . . . (definitions here)
> > #else
> > . . . (definitions here)
> > #endif
> > . . .
> >
> > It got a definition, just not necessarily the right one.
> >
> >
> > ===
> > Mark Millard
> > markmi at dsl-only.net
>
> Can you try the attached patch?  There was a subtle ABI issue that
> r308817 exposed, which is that the pmap structs aren't identical such
> that the pm_stats are at different locations, and libkvm ends up
> reading with the Book-E pmap, getting different stats than expected for
> AIM.  This patch fixes that, bumping version to account for this ABI
> change.
>
> - Justin
>
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860]

[Justin Hibbits]

On Sat, 19 Nov 2016 18:36:39 -0800
Mark Millard  wrote:

> [Quick top post I'm afraid.]
> 
> I think that I figured out why there is a problem even earlier
> --that just did not stop the compiles.
> 
> lib/libutil/kinfo_getallproc.c is built here as part of buildworld
> (stage 4.2 "building libraries" instead of buildkernel. It does not
> have the KERNCONF's AIM vs. BOOKE vs. . . . definitions vs. lack of
> them).
> 
> So if it includes machine/pmap.h that binds to
> sys/powerpc/include/pmap.h which has the structure. . .
> 
> . . .
> #if defined(AIM)
> . . . (definitions here)
> #elif defined(BOOKE)
> . . . (definitions here)
> #endif
> . . .
> 
> it gets no definition now.
> 
> With the older:
> 
> . . .
> #if defined(AIM)
> . . . (definitions here)
> #else
> . . . (definitions here)
> #endif
> . . .
> 
> It got a definition, just not necessarily the right one.
> 
> 
> ===
> Mark Millard
> markmi at dsl-only.net

Can you try the attached patch?  There was a subtle ABI issue that
r308817 exposed, which is that the pmap structs aren't identical such
that the pm_stats are at different locations, and libkvm ends up
reading with the Book-E pmap, getting different stats than expected for
AIM.  This patch fixes that, bumping version to account for this ABI
change.

- JustinIndex: sys/sys/param.h
===
--- sys/sys/param.h	(revision 308708)
+++ sys/sys/param.h	(working copy)
@@ -58,7 +58,7 @@
  *		in the range 5 to 9.
  */
 #undef __FreeBSD_version
-#define __FreeBSD_version 1200014	/* Master, propagated to newvers */
+#define __FreeBSD_version 1200015	/* Master, propagated to newvers */
 
 /*
  * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD,
Index: sys/powerpc/include/pmap.h
===
--- sys/powerpc/include/pmap.h	(revision 308718)
+++ sys/powerpc/include/pmap.h	(working copy)
@@ -74,6 +74,9 @@
 #include 
 #include 
 
+struct pmap;
+typedef struct pmap *pmap_t;
+
 #if defined(AIM)
 
 #if !defined(NPMAPS)
@@ -81,8 +84,6 @@
 #endif /* !defined(NPMAPS) */
 
 struct	slbtnode;
-struct	pmap;
-typedef	struct pmap *pmap_t;
 
 struct pvo_entry {
 	LIST_ENTRY(pvo_entry) pvo_vlink;	/* Link to common virt page */
@@ -131,6 +132,7 @@
 #define	PVO_VSID(pvo)		((pvo)->pvo_vpn >> 16)
 
 struct	pmap {
+	struct		pmap_statistics	pm_stats;
 	struct	mtx	pm_mtx;
 	
 #ifdef __powerpc64__
@@ -143,7 +145,6 @@
 	cpuset_t	pm_active;
 
 	struct pmap	*pmap_phys;
-	struct		pmap_statistics	pm_stats;
 	struct pvo_tree pmap_pvo;
 };
 
@@ -179,13 +180,13 @@
 struct slb **slb_alloc_user_cache(void);
 void	slb_free_user_cache(struct slb **);
 
-#else
+#elif defined(BOOKE)
 
 struct pmap {
+	struct pmap_statistics	pm_stats;	/* pmap statistics */
 	struct mtx		pm_mtx;		/* pmap mutex */
 	tlbtid_t		pm_tid[MAXCPU];	/* TID to identify this pmap entries in TLB */
 	cpuset_t		pm_active;	/* active on cpus */
-	struct pmap_statistics	pm_stats;	/* pmap statistics */
 
 	/* Page table directory, array of pointers to page tables. */
 	pte_t			*pm_pdir[PDIR_NENTRIES];
@@ -193,7 +194,6 @@
 	/* List of allocated ptbl bufs (ptbl kva regions). */
 	TAILQ_HEAD(, ptbl_buf)	pm_ptbl_list;
 };
-typedef	struct pmap *pmap_t;
 
 struct pv_entry {
 	pmap_t pv_pmap;
@@ -210,6 +210,16 @@
 #define	pmap_page_get_memattr(m)	VM_MEMATTR_DEFAULT
 #define	pmap_page_is_mapped(m)	(!TAILQ_EMPTY(&(m)->md.pv_list))
 
+#else
+/*
+ * Common pmap members between AIM and BOOKE.
+ * libkvm needs pm_stats at the same location between both, as it doesn't define
+ * AIM nor BOOKE, and is expected to work across all.
+ */
+struct pmap {
+	struct pmap_statistics	pm_stats;	/* pmap statistics */
+	struct mtx		pm_mtx;		/* pmap mutex */
+};
 #endif /* AIM */
 
 extern	struct pmap kernel_pmap_store;
Index: UPDATING
===
--- UPDATING	(revision 308708)
+++ UPDATING	(working copy)
@@ -51,6 +51,11 @@
 
 ** SPECIAL WARNING: **
 
+20161119:
+	The layout of the pmap structure has changed for powerpc to put the pmap
+	statistics at the front for all CPU variations.  libkvm(3) and all tools
+	that link against it need to be recompiled.
+
 20161030:
 	isl(4) and cyapa(4) drivers now require a new driver,
 	chromebook_platform(4), to work properly on Chromebook-class hardware.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860]

[Justin Hibbits]

On Sat, 19 Nov 2016 18:19:37 -0800
Mark Millard <mar...@dsl-only.net> wrote:

> > Author: jhibbits
> > Date: Fri Nov 18 22:59:33 2016
> > New Revision: 308817
> > URL: https://svnweb.freebsd.org/changeset/base/308817
> > 
> > Log:
> >   Fix buildworld
> >   
> >   Change the pv_tracked flag to an int, just in case userspace
> > decides to include this file and defines BOOKE.
> >   
> >   Guard this block from unintentional inclusion with ifdef BOOKE.
> >   
> >   Reported by:  emaste  
> . . .
> 
> (Later quotes are not from the list or from E-mail but from files.)
> 
> I'm not targeting BOOKE but GENERIC64 (via include, with AIM but not
> ps3). I'm at head -r308860 yet for TARGET_ARCH=powerpc64 I get the
> following that did not happen with my older -r308247 builds:
> 
> > --- kinfo_getallproc.o ---  
> . . .
> > In file included from /usr/src/sys/sys/user.h:53:0,
> >  from q:34:
> > /usr/src/sys/vm/vm_map.h:190:2: error: unknown type name 'pmap_t'
> >   pmap_t pmap;   /* (c) Physical map */
> >   ^
> > /usr/src/sys/vm/vm_map.h:250:14: error: field 'vm_pmap' has
> > incomplete type struct pmap vm_pmap; /* private physical map */
> >   ^
> > --- kinfo_getfile.o ---
> > In file included from /usr/src/sys/sys/user.h:53:0,
> >  from /usr/src/lib/libutil/kinfo_getfile.c:5:
> > /usr/src/sys/vm/vm_map.h:190:2: error: unknown type name 'pmap_t'
> >   pmap_t pmap;   /* (c) Physical map */
> >   ^
> > /usr/src/sys/vm/vm_map.h:250:14: error: field 'vm_pmap' has
> > incomplete type struct pmap vm_pmap; /* private physical map */  
> 
> 
> It is almost like a machine/pmap.h include is missing now so that the
> types are not defined. But I've not yet found where the relevant
> difference(s) are from -r308247.
> 
> Showing a compile command (with -v) with its failure. . .
> 

The change is the "#elif defined(BOOKE)".  Since userspace doesn't
define either AIM nor BOOKE, struct pmap no longer exists.

Alan, do you know if vmspace *needs* struct pmap to exist when read
from userspace (in libprocstat and libkvm, from what I grepped)?  If
not, I can add a simple '#else struct pmap {};' to quiet the build.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Buildworld error with read-only source tree

[Justin Hibbits]

On Mon, 7 Nov 2016 20:53:46 -0500
Ryan Stone <ryst...@gmail.com> wrote:

> I just got the following error attempting to build r308430 with my
> source tree on a read-only NFS mount.  I can work around it for now,
> but shouldn't the source tree be untouched during a buildworld?
> 
> $ make -j4 buildworld buildkernel
> --- buildworld ---
> make[1]: "/repos/users/rstone/freebsd/Makefile.inc1" line 146:
> SYSTEM_COMPILER: Determined that CC=cc matches the source tree.  Not
> bootstrapping a cross-compiler.
> --- buildworld_prologue ---
> --
> >>> World build started on Tue Nov  8 01:50:50 EST 2016  
> --
> --- _worldtmp ---
> --
> >>> Rebuilding the temporary build tree  
> --
> rm -rf /repos/users/rstone/freebsd/tmp
> rm -rf /repos/users/rstone/freebsd/lib32
> mkdir -p /repos/users/rstone/freebsd/tmp/lib
> mkdir: /repos/users/rstone/freebsd/tmp: Read-only file system

Do you have a MAKEOBJDIRPREFIX set (locally, or through a script or
Makefile hack)? My build log doesn't show it touching the source tree,
it shows it only touching the object tree.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

hang during kldload if_bwn

[Justin Hibbits]

Hi folks,

I have a PowerBook G4 with an Airport Extreme card (bwi/bwn, can use
either one), and found if I don't have the exact correct firmware it
hangs.  Here's a snippet of WITNESS before it hangs:

siba_bwn0:  mem
0xa0004000-0xa0005fff irq 52 at device 17.0 on pci1 bwn0 on siba_bwn0
bwn0: bwn_attach_core: forcing 2GHz only; no dual-band support for PHY
bwn0: WLAN (chipid 0x4318 rev 9) PHY (analog 3 type 2 rev 7) RADIO
(manuf 0x17f ver 0x2050 rev 8) bwn0: DMA (32 bits)
wlan0: Ethernet address: 00:14:51:7d:60:39
bwn0: ucode fw: ucode5
Sleeping on "fwload" with the following non-sleepable locks held:
exclusive sleep mutex bwn0 (network driver) r = 0 (0xd2e57004) locked
@ /usr/src/sys/modules/bwn/../../dev/bwn/if_bwn.c:814 stack backtrace:
#0 0x50fd64 at witness_warn+0x2c0
#1 0x49ef0c at _sleep+0xc8
#2 0x4e2e10 at firmware_get+0x120
#3 0xd2d0a6e4 at bwn_fw_get+0xe4
#4 0xd2d1057c at bwn_fw_gets+0x1ac
#5 0xd2d13130 at bwn_core_init+0x28c
#6 0xd2d151f0 at bwn_init+0x310
#7 0xd2d15408 at bwn_parent+0x80
#8 0xd2da794c at parent_updown+0x1c
#9 0x4fe6dc at taskqueue_run_locked+0x178
#10 0x4ff468 at taskqueue_thread_loop+0xa8
#11 0x44c99c at fork_exit+0xc0
#12 0x8229dc at fork_trampoline+0xc
bwn_v4_ucode5: could not load firmware image, error 2
bwn0: the fw file(bwn_v4_ucode5) not found
bwn0: ucode fw: ucode5
Sleeping on "fwload" with the following non-sleepable locks held:
exclusive sleep mutex bwn0 (network driver) r = 0 (0xd2e57004) locked
@ /usr/src/sys/modules/bwn/../../dev/bwn/if_bwn.c:814 stack backtrace:
#0 0x50fd64 at witness_warn+0x2c0
#1 0x49ef0c at _sleep+0xc8
#2 0x4e2e10 at firmware_get+0x120
#3 0xd2d0a6e4 at bwn_fw_get+0xe4
#4 0xd2d1057c at bwn_fw_gets+0x1ac
#5 0xd2d13130 at bwn_core_init+0x28c
#6 0xd2d151f0 at bwn_init+0x310
#7 0xd2d15408 at bwn_parent+0x80
#8 0xd2da794c at parent_updown+0x1c
#9 0x4fe6dc at taskqueue_run_locked+0x178
#10 0x4ff468 at taskqueue_thread_loop+0xa8
#11 0x44c99c at fork_exit+0xc0
#12 0x8229dc at fork_trampoline+0xc
bwn-open_v4_ucode5: could not load firmware image, error 2
bwn0: the fw file(bwn-open_v4_ucode5) not found


Creating a symlink in /boot/modules of bwn_v4_ucode5.ko ->
bwn_v4_ucode.ko makes it not hang, but it still triggers WITNESS.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64] [filemon fails to load on powerpc64]

[Justin Hibbits]

On Wed, Jun 1, 2016 at 8:59 PM, Bryan Drewery <bdrew...@freebsd.org> wrote:
> On 6/1/2016 6:39 PM, Mark Millard wrote:
>> while filemon.ko now exists:
>>> # ls -l /boot/*/filemon*
>>> -r-xr-xr-x  1 root  wheel  32064 Jun  1 17:59 /boot/kernel/filemon.ko
>> it does not load:
>>> # kldload -n filemon
>>> kldload: can't load filemon: No such file or directory
>>> # dmesg | grep link_elf
>>> link_elf: symbol elf64_freebsd_sysvec undefined
>
> There's 2 different ABI formats for powerpc64?
>
>> sys/powerpc/powerpc/elf64_machdep.c:INIT_SYSENTVEC(elf64_sysvec_v1, 
>> _freebsd_sysvec_v1);
>> sys/powerpc/powerpc/elf64_machdep.c:INIT_SYSENTVEC(elf64_sysvec_v2, 
>> _freebsd_sysvec_v2);
>
> What's up with that?
>
> --
> Regards,
> Bryan Drewery
>

Yes, powerpc64 has two ABIs now.  ELFv1 is traditional ABI.  ELFv2 was
created IBM for their little-endian (POWER8 ppc64le) target.  Nathan
added support to use it in FreeBSD.  It cleans up some of the
silliness that's in ELFv1, such as function descriptors.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Justin Hibbits]

On Tue, Apr 19, 2016 at 3:36 PM, Nathan Whitehorn
<nwhiteh...@freebsd.org> wrote:
>
>
> On 04/19/16 13:26, Poul-Henning Kamp wrote:
>>
>> 
>> In message <1461096962.1232.32.ca...@freebsd.org>, Ian Lepore writes:
>>
>>> Oh yeah, now I remember:  Because in freebsd, design is decided by a
>>> race to commit rather than by discussion.
>>
>> No, that's not it.
>>
>> It is because code talks much louder than words.

> If it would help, I am happy to generate a patch to make the discussion
> concrete.
> -Nathan

Please do.  Practical is always better than theory, in practice.  It's
easier to debate on practical grounds.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: SVN r296987 -> r297000 breaks Sil 3124 channel attach

[Justin Hibbits]

You're right.  On line 323 of sys/dev/siis/siis.c, try replacing
'long' with 'rman_res_t', as I did for ahci.c.  If this works, tonight
I'll commit the fix.  I envision there may be others using 'long'
instead of 'u_long' for rman (u_long was the correct form until
rman_res_t, so signed long was already a bug).

- Justin

On Mon, Mar 21, 2016 at 11:11 AM, Michael Butler
<i...@protected-networks.net> wrote:
> Something between SVN r296987 and r297000 causes the following errors in
> dmesg .. and the loss of the attached disks:
>
> siisch0:  at channel 0 on siis0
> device attach: siisch0 attach returned 6
> siisch1:  at channel 1 on siis0
> device attach: siisch0 attach returned 6
> siisch2:  at channel 2 on siis0
> device attach: siisch0 attach returned 6
> siisch3:  at channel 3 on siis0
> device attach: siisch0 attach returned 6
>
> I can't see anything but r297000 causing this :-(
>
> Michael
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB disks attach after rootfs prompt

[Justin Hibbits]

On Sat, 19 Mar 2016 15:09:35 +
"Poul-Henning Kamp" <p...@phk.freebsd.dk> wrote:

> 
> In message <1458397972.68920.69.ca...@freebsd.org>, Ian Lepore writes:
> >On Sat, 2016-03-19 at 13:04 +, Poul-Henning Kamp wrote:  
> >> Running:
> >> 
> >>FreeBSD 11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC
> >> 2016
> >> 
> >> I tried "boot -a" and found that USB disks only attach *after* you
> >> enter some root filesystem.
> >> 
> >> That's not terribly useful.  
> >
> >iirc, interrupts are disabled while you're at the mountroot prompt,
> >which freezes usb enumeration.  
> 
> I am somewhat certain that this used to work...
> 
> 

Tunable vfs.mountroot.timeout may be what you're looking for.  By
default it waits for 3 seconds, but for USB it's suggested 10s or more,
from what I recall.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

CFT: powerpcspe arch port

[Justin Hibbits]

To anyone using the PowerPC e500v2 core, I have created a new
architecture port, powerpc.powerpcspe, which supports the use of the
Signal Processing Engine found in these SoCs.  It does not support
e500v1, which only has single-precision floating point capabilities.

It can be found at svn.freebsd.org/base/projects/powerpcspe .  It has
been tested on a RouterBoard RB800, where it boots to multiuser, and
some basic utilities have been run (ls, sh).

Please report any problems with it to me and ppc@.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD_HEAD_i386 - Build #2215 - Failure

[Justin Hibbits]

Sorry, didn't fully tinderbox after a minor change before checking in  
r294883.  Should be fixed by r294885.


- Justin

On Jan 26, 2016, at 9:39 PM, jenkins-ad...@freebsd.org wrote:


FreeBSD_HEAD_i386 - Build #2215 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2215/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2215/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2215/console

Change summaries:

294884 by cy:
Allow specification of fetch options for ntp leap-seconds fetch.

MFC after:  1 week
X-MFC with: r289421, r293037, r294773

294883 by jhibbits:
Convert rman to use rman_res_t instead of u_long

Summary:
Migrate to using the semi-opaque type rman_res_t to specify rman  
resources.  For

now, this is still compatible with u_long.

This is step one in migrating rman to use uintmax_t for resources  
instead of

u_long.

Going forward, this could feasibly be used to specify architecture- 
specific
definitions of resource ranges, rather than baking a specific  
integer type into

the API.

This change has been broken out to facilitate MFC'ing drivers back  
to 10 without

breaking ABI.

Reviewed By: jhb
Sponsored by:   Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D5075

294882 by luigi:
cleanup and document in some detail the internals of the testing code
for dummynet schedulers

294881 by luigi:
the _Static_assert was not supposed to be in the commit.

294880 by dteske:
Replace awk with more efficient builtins-only algo

294879 by luigi:
bugfix: the scheduler template (dn_schk) for the round robin scheduler
is followed by another structure (rr_schk) whose size must be set
in the schk_datalen field of the descriptor.
Not allocating the memory may cause other memory to be overwritten
(though dn_schk is 192 bytes and rr_schk only 12 so we may be lucky
and end up in the padding after the dn_schk).

This is a merge candidate for stable and 10.3

MFC after:  3 days

294878 by bdrewery:
Revert yacc dependency back to pre-r241298.

Several attempts to fix this logic was done after r241298, which were
all reverted, yet this change was not.

The .h file does not depend on the .c file, so do not impose such a
dependency on it.  They are generated by the same command but do not
depend on each other.  Restore the .ORDER which should handle  
parallel build

issues.  This fixes an actual bug where the .h file is not recreated
when missing [1].  For example:
 cd lib/libc
 make cleanobj
 make nsparser.h
 rm nsparser.h
 make nsparser.h # will not rebuild nsparser.h

I have been trying to track down a build problem where nsparser.h is
missing when nslexer.o is built.  It is possible this is related.

Reported by:bde [1]

https://lists.freebsd.org/pipermail/svn-src-all/2012-October/059481.html

https://lists.freebsd.org/pipermail/svn-src-all/2012-October/060038.html
MFC after:  3 weeks
Sponsored by:   EMC / Isilon Storage Division

294877 by bdrewery:
Replace nslexer.l->nslexer.c custom rule with a -D CFLAG.

This avoids reproducing the lex logic which had dependencies set wrong
and used an intermediate file for modifying the YY_BUF_SIZE.

This has only been possible since flex 2.5.37 was imported in r250873,
which uses #ifndef YY_BUF_SIZE.

MFC after:  2 weeks
Sponsored by:   EMC / Isilon Storage Division

294876 by bdrewery:
nslexer.c does not depend on nsparser.h.

nslexer.o depends on nsparser.h, which is already added by bsd.lib.mk
and .depend.

This reverts r237402.

MFC after:  2 weeks
Sponsored by:   EMC / Isilon Storage Division

294875 by bdrewery:
FAST_DEPEND: Mark some unneeded code for later removal.

Sponsored by:   EMC / Isilon Storage Division

294874 by bdrewery:
FAST_DEPEND: Apply missed nofilemon fix from r294351.

Sponsored by:   EMC / Isilon Storage Division

294873 by bdrewery:
Set a value for _RECURSING_PROGS for debugging.

MFC after:  3 days
Sponsored by:   EMC / Isilon Storage Division

294872 by bdrewery:
Fix DIRDEPS_BUILD after r294752.

DIRDEPS_BUILD does not yet support PROGS having their own dependency
file.

Overriding .MAKE.DEPENDFILE here causes major problems with the meta
mode logic since it creates the Makefile.depend as '.depend' resulting
in infinite loops in make due to dirdeps.mk including .depend  
endlessly.


X-MFC-With: r294752
MFC after:  1 week
Sponsored by:   EMC / Isilon Storage Division



The end of the build log:

[...truncated 59511 lines...]
===> lib/libcom_err (all)
--- all_subdir_libbsm ---
--- bsm_mask.So ---
cc  -fpic -DPIC -g -O2 -pipe -I/usr/src/lib/libbsm/../../contrib/ 
openbsm -I/usr/src/lib/libbsm/../../contrib/openbsm/libbsm   - 
std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wno- 
pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const- 
variable -Wno-tautological-compare -Wno-unused-value -Wno- 
parentheses-equality -Wno-unused-functio

Re: DDB patches

[Justin Hibbits]

On Thu, Nov 19, 2015 at 8:29 AM, Dan Partelly <dan_parte...@rdsor.ro> wrote:
>> Unlike what you suggest here, I see lots of issues in Bugzilla which
>> exactly what you describe: enhancements on already available tools.
>> I've even submitted a few myself.
>
> Thats great Willem.
>
> But no matter what you find odd or not, I am simply following what Ive read 
> on some
> page on freebsd.org that one of the ways of contributing is by submitting code
> on the mailing-lists , where “somebody will happily pick up changes”.
>
> So, if you continue to find this odd, please take it up with the web-masters 
> on
> freebsd.org to update the resources regarding contributing to the project.

Dan,

I think a lot of people tend to use the 'one-two punch' of both PR and
mailing list.  Mailing list to flesh it out and discuss the idea, and
the PR when it's ready to go in.  I've done a very cursory review of
your patch, and it looks pretty good.  Unfortunately, my time is
booked for more projects than I really have time for, so I'd be unable
to test it.  If you submit it as a PR in bugzilla, at the very least
the patch won't get lost when someone else comes looking for the
feature, and more likely it'll get picked up by someone rather quickly
or in the next triage phase (some people like to do bug triaging
periodically, where things like this get their basic testing and
commit).

When you said it's not a patch for an issue/bug/etc, one could say the
bug is that the patch isn't already in the tree :) .

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT: uintmax_t rman

[Justin Hibbits]

On Mon, Nov 16, 2015 at 6:25 PM, Benjamin Kaduk <ka...@mit.edu> wrote:
> On Mon, 16 Nov 2015, Warner Losh wrote:
>
>> >
>> > On Nov 15, 2015, at 9:13 PM, Justin Hibbits <chmeeed...@gmail.com> wrote:
>> >
>> > (Attempted to send this yesterday, but appears it didn't go through.  
>> > Apologies if it really did go through).
>> >
>> > As part of a project getting FreeBSD on the Freescale P5020 SoC, I 
>> > increased the width of resources, from u_long(32 bits on 32-bit archs, 64 
>> > bits on 64-bit archs) to uintmax_t (currently 64 bits on all archs).  I 
>> > have it working on PowerPC, but have not tested it on any other 
>> > architecture, I have no other systems to test it with, so I need help.  
>> > This passes a tinderbox build.  I need this tested on other archs, the 
>> > more the better, especially i386, including PAE.
>> >
>> > It should be effectively a no-op on most architectures, especially 64-bit 
>> > archs, though there were some checks I found in x86 code clamping address 
>> > checks to under 4GB, commented as necessary purely for rman.  If this 
>> > isn't the case, and we can't yet handle the checks being removed, they can 
>> > go in, but that needs testing.  It should apply cleanly to recent head.
>>
>> I like the idea. There’s nothing offensive enough in the diffs to comment 
>> upon here (though I suppose I could see a few spots one could quibble over 
>> if one were so inclined).
>>
>> I wonder, though, why not make its own typedef, even if it is just
>> ‘typedef man_res_t uintmax_t;’ in the rman headers?
>
> Channeling my inner bde (maybe?), the typedef is probably helpful, but
> uintmax_t seems less so.  uintmax_t has no guaranteed ABI, so a
> fixed-width type like uint64_t seems beter, assuming that uintmax_t is
> currently uint64_t everywhere (which I think is the case but did not
> verify).
>
> -Ben

I'm not opposed to a typedef for this, bde suggested I just use
straight uintmax_t, so it's a good starting point for wider testing.
I'm fine with anything as long as it's guaranteed to be the largest
integer size (uintmax_t guarantees that, so any typedef of that is
sufficient for me).

Any name suggestions are appreciated, but what I want more than that
right now is testing.  Hammer the hell out of this on as wide a
variety of platforms as anyone can, to make sure it doesn't break in
odd cases.

If typedefs are desired, it's no more work than a simple sed plus a
single added line.  If this breaks anything, that's the bigger
problem.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT: uintmax_t rman

[Justin Hibbits]

On Tue, Nov 17, 2015 at 10:41 AM, Adrian Chadd <adrian.ch...@gmail.com> wrote:
> [snip]
>
> emulators! emulators emulators emulators emulators emulators!
>
> You can emulate x86 (32, 64 bit) on your ppc via qemu-devel.
> I know that mips, mipsel, mips64, mips64el all work via qemu-system-*.
> sparc64 is .. coming.
> I'm not sure about arm, but I know arm64 can run in the emulator fine.
>
> So hm, can you automate firing things up in emulators?
>
>
>
> -adrian

Can I build a full bootable image for every arch without root
privileges?  There's no way that I'm going to build every architecture
on my 10 year old dual core machine (where I have root), it'll take
forever, so my only other option is to use the cluster, where I of
course don't have root privileges.

If I can type 'make universeimages' as non-root, then, sure, I'll take
the time to boot test every target that'll boot in qemu.  Otherwise, I
don't have the time to do it, and that's where crowdtesting is
advantageous.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r287797 breaks build WITHOUT_NIS

[Justin Hibbits]

Thanks!
On Oct 25, 2015 02:44, "NGie Cooper" <yaneurab...@gmail.com> wrote:

>
> > On Oct 10, 2015, at 16:18, Justin Hibbits <jr...@alumni.cwru.edu> wrote:
> >
> > When building WITHOUT_NIS, the following errors show up (base gcc, for
> > building powerpc):
> >
> > cc1: warnings being treated as errors
> > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c: In function
> > 'compat_setgrent':
> > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1258: warning:
> > comparison is always false due to limited range of data type
> > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1267: warning:
> > comparison is always false due to limited range of data type
> > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c: In function
> 'compat_group':
> > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1355: warning:
> > comparison is always false due to limited range of data type
> > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1378: warning:
> > comparison is always false due to limited range of data type
> >
> > Converting the local variable in the macros back to int fixes it.
>
> Fixed in r289925.
> Thanks!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r288669 breaks ports building with USE_GCC=yes

[Justin Hibbits]

Hi Pedro,

On Tue, Oct 13, 2015 at 9:18 AM, Pedro Giffuni <p...@freebsd.org> wrote:
> Hi;
>
> On 10/12/2015 8:28 PM, Justin Hibbits wrote:
>>
>> Hi Pedro,
>>
>> ...
>> This is on powerpc64.  I see the patch has been there for 16 months, but
>> for some reason, the /usr/local/bin/gcc48 doesn't contain the patch.  I ran
>> `strings` on the binary, and it has the following string:
>>
>> %{fstack-protector|fstack-protector-all:-lssp_nonshared}
>>
>> Which, if you examine files/patch-stackprotector-gcc, is the unpatched
>> string.
>>
>> I have no idea why this is the case.
>>
>
> I think it is important to determine if this is a problem from upstream or
> a problem in the gcc48 backported patches. Please test building with gcc49
> or gcc5.
>
> This is just for curiosity ... I am keeping my fingers away from GCC ;).
>
> Pedro.
>

As Antoine mentioned, the problem is that lang/gcc does not have this
patch.  USE_GCC uses lang/gcc, not lang/gcc48.  So lang/gcc needs to
be updated.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

r288669 breaks ports building with USE_GCC=yes

[Justin Hibbits]

The default ports gcc for USE_GCC is still 4.8, which does not support
-fstack-protector-strong.  This breaks several ports including (from
my poudriere run): libfpx and qt4-sqlite3-plugin.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r288669 breaks ports building with USE_GCC=yes

[Justin Hibbits]

Hi Pedro,

On Mon, Oct 12, 2015 at 3:28 PM, Pedro Giffuni <p...@freebsd.org> wrote:
> Hi again;
>
> On 12/10/2015 03:16 p.m., Pedro Giffuni wrote:
>>
>> Hello;
>>
>> On 12/10/2015 02:56 p.m., Justin Hibbits wrote:
>>>
>>> The default ports gcc for USE_GCC is still 4.8, which does not support
>>> -fstack-protector-strong.  This breaks several ports including (from
>>> my poudriere run): libfpx and qt4-sqlite3-plugin.
>>>
>>> - Justin
>>
>>
>> r288669 only applies to base. It was tested with an exp-run and there were
>> no
>> failures so this is something wrong in your setup.
>>
>
> Ugh ... now that I remember, we actually used -stack-protector-all for the
> exp-run
> (which is supported in pretty much every gcc).
>
> Still, the change should only apply to the base system and not ports, and
> -stack-protector-strong appears to have been backported to gcc48
> last year (see PR 186852).
>
> cheers,
>
> Pedro.
>

All I can say is building with USE_GCC=yes, I see the following error:

g++48: error: unrecognized command line option '-fstack-protector-strong'

This is using the latest gcc48 in ports (full tree updated yesterday).

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r288669 breaks ports building with USE_GCC=yes

[Justin Hibbits]

Hi Pedro,

On Oct 12, 2015, at 7:23 PM, Pedro Giffuni wrote:




On 10/12/2015 3:33 PM, Justin Hibbits wrote:

Hi Pedro,

On Mon, Oct 12, 2015 at 3:28 PM, Pedro Giffuni <p...@freebsd.org>  
wrote:

Hi again;

On 12/10/2015 03:16 p.m., Pedro Giffuni wrote:

Hello;

On 12/10/2015 02:56 p.m., Justin Hibbits wrote:
The default ports gcc for USE_GCC is still 4.8, which does not  
support
-fstack-protector-strong.  This breaks several ports including  
(from

my poudriere run): libfpx and qt4-sqlite3-plugin.

- Justin


r288669 only applies to base. It was tested with an exp-run and  
there were

no
failures so this is something wrong in your setup.

Ugh ... now that I remember, we actually used -stack-protector-all  
for the

exp-run
(which is supported in pretty much every gcc).

Still, the change should only apply to the base system and not  
ports, and

-stack-protector-strong appears to have been backported to gcc48
last year (see PR 186852).

cheers,

Pedro.

All I can say is building with USE_GCC=yes, I see the following  
error:


g++48: error: unrecognized command line option '-fstack-protector- 
strong'


This is using the latest gcc48 in ports (full tree updated  
yesterday).


OK, I tested graphics/libfpx on i386-current:

-stack-protector-strong indeed gets pulled in due to some non-orthodox
workarounds in files/Makefile.bsd.

g++48 accepts it just fine and the port compiles.

Is this a platform that has GCC issues, perhaps? It looks like one  
of those

"unfortunately series of events" that may have to be fixed in the port
and/or gcc48.

Pedro.



This is on powerpc64.  I see the patch has been there for 16 months,  
but for some reason, the /usr/local/bin/gcc48 doesn't contain the  
patch.  I ran `strings` on the binary, and it has the following string:


%{fstack-protector|fstack-protector-all:-lssp_nonshared}

Which, if you examine files/patch-stackprotector-gcc, is the unpatched  
string.


I have no idea why this is the case.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

r287797 breaks build WITHOUT_NIS

[Justin Hibbits]

When building WITHOUT_NIS, the following errors show up (base gcc, for
building powerpc):

cc1: warnings being treated as errors
/home/chmeee/freebsd/head/lib/libc/gen/getgrent.c: In function
'compat_setgrent':
/home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1258: warning:
comparison is always false due to limited range of data type
/home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1267: warning:
comparison is always false due to limited range of data type
/home/chmeee/freebsd/head/lib/libc/gen/getgrent.c: In function 'compat_group':
/home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1355: warning:
comparison is always false due to limited range of data type
/home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1378: warning:
comparison is always false due to limited range of data type

Converting the local variable in the macros back to int fixes it.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CPU Perf Power Mgt

[Justin Hibbits]

On Thu, Aug 20, 2015 at 5:44 AM, Will Green w...@sundivenetworks.com wrote:
 Hello,

 I’ve been thinking about CPU performance and power management on FreeBSD 
 recently. As a user it seems like there has been little activity in this area 
 and I wanted to try and understand what the situation was.

 From the publicly available information on powerd [1], the wiki [2] and my 
 attempts to optimize hardware power/performance; it seems the current 
 approach is quite old and laptop-focused. Recent CPU designs can control the 
 state and frequency of individual cores very quickly. In the case of a single 
 heavy thread, a multicore CPU might power-gate all but one core so the active 
 core can be pushed to a higher frequency. This doesn’t seem to be possible on 
 FreeBSD at the moment: powerd is userland (~250 ms poll) and can only control 
 the frequency of all cores together.

 I understand this opens a can of worms as the CPU core states, frequency and 
 scheduler would all need to co-operate. However, I think it’s important that 
 this does happen. Without this functionality FreeBSD is leaving performance 
 on the table and consuming more power than other operating systems. At BSDCan 
 I heard that there was work going on for arm systems, but didn’t manage to 
 get any details and whether it was relevant to amd64 too.

 TIA,
 Will

 PS. I was interested to see Intel announce at IDF that they'll be working 
 with open source projects to implement Speed Shift Technology”, which leaves 
 responsibility for p-state management on the CPU.

 [1] https://www.freebsd.org/cgi/man.cgi?query=powerd
 [2] https://wiki.freebsd.org/TuningPowerConsumption

Hi Will,

There was a working group at BSDCan this year on power management, and
what we need to / can do to bring it up to par with the modern world.
Unfortunately, I haven't had any time lately to work on it, but you
can read the notes at
https://wiki.freebsd.org/201506DevSummit/ClockDomains

In short, the goal is to add infrastructure to the kernel to support
overall power management of the system, scaling beyond cpufreq/powerd.
Looking for volunteers who could do some of this, due to my lack of
time to work on it.

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: powerpc and powerpc64 builds broken

[Justin Hibbits]

On Jun 30, 2015 1:11 AM, Perry Hutchison per...@pluto.rain.com wrote:

 Konstantin Belousov kostik...@gmail.com wrote:

  I think trying to understand why the hack was added is not
  possible.

 In an ideal world, svn blame would identify the commit in which
 it was added, and that commit's log entry would explain why :)

The line existed from the beginning. My guess is to bootstrap on non-iconv
freebsd. As Konstantin said, though, it's very fragile.

-Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: powerpc and powerpc64 builds broken

[Justin Hibbits]

On Tue, Jun 30, 2015 at 8:48 AM, Simon J. Gerraty s...@juniper.net wrote:
 Justin Hibbits jhibb...@freebsd.org wrote:
  Yeah, crossbuilds work fine. It's the actual run-on-real-hardware bit
  that doesn't.
 
  (powerpc64 runs fine in qemu-devel; people should try it!)

 r284345 (introduction of metamode) is the problem.  I bisected it on
 the power8 and it reliably fails this way.  Andreas tested it on his
 G4 (32-bit hardware) and it worked fine, so there's something
 introduced that just doesn't like powerpc64.

 Hmm, didn't touch usr.bin/mkesdb so must be something indirect.
 Is this with[out] NO_CLEAN ?

Tried it both ways, with the same result.  I don't think metamode
necessarily is the cause of the problem, merely unmasking the latent
problem.  Though I've committed a fix for this, it would still be nice
to understand what in r284345 exposed this.

- Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: powerpc and powerpc64 builds broken

[Justin Hibbits]

On Sun, Jun 28, 2015 at 10:32 PM, Konstantin Belousov
kostik...@gmail.com wrote:
 On Sun, Jun 28, 2015 at 10:32:45PM +0200, Andreas Tobler wrote:
 On 28.06.15 21:32, Konstantin Belousov wrote:
  On Sun, Jun 28, 2015 at 12:09:25PM -0700, Justin Hibbits wrote:
  On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper yaneurab...@gmail.com 
  wrote:
 
  On Jun 28, 2015, at 10:48, Justin Hibbits jhibb...@freebsd.org wrote:
 
  Both powerpc and powerpc64 builds are broken in the same way, in
  usr.bin/mkesdb.  It was working correctly as of just before BSDCan, I
  successfully built world and kernel on June 6.
 
  The error seen at this point is:
 
  cc  -O2 -pipe   -I/home/chmeee/freebsd/head/usr.bin/mkesdb
  -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb
  -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv
  -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
  -L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc
  -o mkesdb lex.o yacc.o
  /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld:
  undefined reference to symbol `_end' (try adding -lc)
  /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7:
  could not read symbols: Bad value
 
  I've seen this both locally on my G5, and on the Power8 in the FreeBSD 
  cluster.
 
  - What does file say when you run it on libc.so.7?
 
  /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object,
  64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked,
  not stripped
  I think a libc linker could try for that command line lives in
  /home/chmeee/world/zhabar/home/chmeee/freebsd/head/lib/libc/libc.so
  or in
  /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so
 
  But, the reason for your troubles seems to come from the
  usr.bin/mkesdb/Makefile.  Why does it explicitely adds LDFLAGS to point
  to objdir/.../libc, I have no idea.


 Neither me.

 Here with this mods it compiles:

 Either:

 --- Makefile  (revision 284911)
 +++ Makefile  (working copy)
 @@ -3,7 +3,7 @@
   .PATH: ${.CURDIR}/../../lib/libc/iconv

   PROG=   mkesdb
 -LDFLAGS+= -L${.OBJDIR}/../../lib/libc
 +LDFLAGS+= -L${.OBJDIR}/../../lib/libc/libc

   NO_WMISSING_VARIABLE_DECLARATIONS=


 Or:

 Index: Makefile
 ===
 --- Makefile  (revision 284911)
 +++ Makefile  (working copy)
 @@ -3,7 +3,7 @@
   .PATH: ${.CURDIR}/../../lib/libc/iconv

   PROG=   mkesdb
 -LDFLAGS+= -L${.OBJDIR}/../../lib/libc
 +LDFLAGS+= -L${.CURDIR}/../../lib/libc

   NO_WMISSING_VARIABLE_DECLARATIONS=

 No, I mean that LDFLAGS explicitely listing supposed location for libc
 is wrong, too much wrong.  If mkesd is special, it might need to become
 a bootstrap tool.  But the hackery above is too fragile and it is surprising
 that it went unnoticed for such long time (after the citrus enablement).

Would anyone object to me simply removing that line?  This fixes the
build on powerpc64, and I highly doubt it would impact any other
build.

- Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: powerpc and powerpc64 builds broken

[Justin Hibbits]

On Mon, Jun 29, 2015 at 4:58 PM, Justin Hibbits jhibb...@freebsd.org wrote:
 On Sun, Jun 28, 2015 at 10:32 PM, Konstantin Belousov
 kostik...@gmail.com wrote:
 On Sun, Jun 28, 2015 at 10:32:45PM +0200, Andreas Tobler wrote:
 On 28.06.15 21:32, Konstantin Belousov wrote:
  On Sun, Jun 28, 2015 at 12:09:25PM -0700, Justin Hibbits wrote:
  On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper yaneurab...@gmail.com 
  wrote:
 
  On Jun 28, 2015, at 10:48, Justin Hibbits jhibb...@freebsd.org wrote:
 
  Both powerpc and powerpc64 builds are broken in the same way, in
  usr.bin/mkesdb.  It was working correctly as of just before BSDCan, I
  successfully built world and kernel on June 6.
 
  The error seen at this point is:
 
  cc  -O2 -pipe   -I/home/chmeee/freebsd/head/usr.bin/mkesdb
  -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb
  -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv
  -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
  -L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc
  -o mkesdb lex.o yacc.o
  /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld:
  undefined reference to symbol `_end' (try adding -lc)
  /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7:
  could not read symbols: Bad value
 
  I've seen this both locally on my G5, and on the Power8 in the FreeBSD 
  cluster.
 
  - What does file say when you run it on libc.so.7?
 
  /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object,
  64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked,
  not stripped
  I think a libc linker could try for that command line lives in
  /home/chmeee/world/zhabar/home/chmeee/freebsd/head/lib/libc/libc.so
  or in
  /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so
 
  But, the reason for your troubles seems to come from the
  usr.bin/mkesdb/Makefile.  Why does it explicitely adds LDFLAGS to point
  to objdir/.../libc, I have no idea.


 Neither me.

 Here with this mods it compiles:

 Either:

 --- Makefile  (revision 284911)
 +++ Makefile  (working copy)
 @@ -3,7 +3,7 @@
   .PATH: ${.CURDIR}/../../lib/libc/iconv

   PROG=   mkesdb
 -LDFLAGS+= -L${.OBJDIR}/../../lib/libc
 +LDFLAGS+= -L${.OBJDIR}/../../lib/libc/libc

   NO_WMISSING_VARIABLE_DECLARATIONS=


 Or:

 Index: Makefile
 ===
 --- Makefile  (revision 284911)
 +++ Makefile  (working copy)
 @@ -3,7 +3,7 @@
   .PATH: ${.CURDIR}/../../lib/libc/iconv

   PROG=   mkesdb
 -LDFLAGS+= -L${.OBJDIR}/../../lib/libc
 +LDFLAGS+= -L${.CURDIR}/../../lib/libc

   NO_WMISSING_VARIABLE_DECLARATIONS=

 No, I mean that LDFLAGS explicitely listing supposed location for libc
 is wrong, too much wrong.  If mkesd is special, it might need to become
 a bootstrap tool.  But the hackery above is too fragile and it is surprising
 that it went unnoticed for such long time (after the citrus enablement).

 Would anyone object to me simply removing that line?  This fixes the
 build on powerpc64, and I highly doubt it would impact any other
 build.

 - Justin

A universe build on the cluster passed, I'm nuking it.

- Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

powerpc and powerpc64 builds broken

[Justin Hibbits]

Both powerpc and powerpc64 builds are broken in the same way, in
usr.bin/mkesdb.  It was working correctly as of just before BSDCan, I
successfully built world and kernel on June 6.

The error seen at this point is:

cc  -O2 -pipe   -I/home/chmeee/freebsd/head/usr.bin/mkesdb
-I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb
-I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv
-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
-L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc
-o mkesdb lex.o yacc.o
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld:
undefined reference to symbol `_end' (try adding -lc)
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7:
could not read symbols: Bad value

I've seen this both locally on my G5, and on the Power8 in the FreeBSD cluster.

- Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: powerpc and powerpc64 builds broken

[Justin Hibbits]

On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper yaneurab...@gmail.com wrote:

 On Jun 28, 2015, at 10:48, Justin Hibbits jhibb...@freebsd.org wrote:

 Both powerpc and powerpc64 builds are broken in the same way, in
 usr.bin/mkesdb.  It was working correctly as of just before BSDCan, I
 successfully built world and kernel on June 6.

 The error seen at this point is:

 cc  -O2 -pipe   -I/home/chmeee/freebsd/head/usr.bin/mkesdb
 -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb
 -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv
 -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
 -L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc
 -o mkesdb lex.o yacc.o
 /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld:
 undefined reference to symbol `_end' (try adding -lc)
 /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7:
 could not read symbols: Bad value

 I've seen this both locally on my G5, and on the Power8 in the FreeBSD 
 cluster.

 - What does file say when you run it on libc.so.7?

/usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object,
64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked,
not stripped

 - What's your current revision?

r284893

 - Does it work when SRCCONF/__MAKECONF are set to /dev/null?

No, the problem remains.


 Thanks!

- Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: powerpc and powerpc64 builds broken

[Justin Hibbits]

On Sun, Jun 28, 2015 at 3:59 PM, Adrian Chadd adrian.ch...@gmail.com wrote:
 On 28 June 2015 at 15:52, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net 
 wrote:

 On 28 Jun 2015, at 19:09 , Justin Hibbits jhibb...@freebsd.org wrote:

 On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper yaneurab...@gmail.com 
 wrote:

 On Jun 28, 2015, at 10:48, Justin Hibbits jhibb...@freebsd.org wrote:

 Both powerpc and powerpc64 builds are broken in the same way, in
 usr.bin/mkesdb.  It was working correctly as of just before BSDCan, I
 successfully built world and kernel on June 6.

 The error seen at this point is:

 - What does file say when you run it on libc.so.7?

 /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object,
 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked,
 not stripped

 - What's your current revision?

 r284893

 - Does it work when SRCCONF/__MAKECONF are set to /dev/null?

 No, the problem remains.

 I have not see this problem in my endless tinderbox run;
 I know the crossbuilds succeeded with r284913.

 Yeah, crossbuilds work fine. It's the actual run-on-real-hardware bit
 that doesn't.

 (powerpc64 runs fine in qemu-devel; people should try it!)

r284345 (introduction of metamode) is the problem.  I bisected it on
the power8 and it reliably fails this way.  Andreas tested it on his
G4 (32-bit hardware) and it worked fine, so there's something
introduced that just doesn't like powerpc64.

- Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Build failed in Jenkins: FreeBSD_HEAD #2663

[Justin Hibbits]

Crap, sorry. I wonder how that compiled fine for me. I'll fix it in a
couple hours when I get home.

-Justin
On Apr 18, 2015 4:49 PM, Garrett Cooper yaneurab...@gmail.com wrote:


  On Apr 18, 2015, at 15:56, jenkins-ad...@freebsd.org wrote:


  === lib/libpmc (all)
  --- libpmc.So ---
  cc  -fpic -DPIC  -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 -Wmissing-variable-declarations
 -Wthread-safety -Wno-empty-body -Wno-string-plus-int
 -Wno-unused-const-variable -Qunused-arguments -c 
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/libpmc.c -o
 libpmc.So
  --- pmclog.So ---
  cc  -fpic -DPIC  -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 -Wmissing-variable-declarations
 -Wthread-safety -Wno-empty-body -Wno-string-plus-int
 -Wno-unused-const-variable -Qunused-arguments -c 
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/pmclog.c -o
 pmclog.So
  --- libpmc.So ---
  https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/libpmc.c:302:1:
 error: use of undeclared identifier 'PMC_CLASS_E500'; did you mean
 'PMC_CLASS_P5'?
  PMC_MDEP_TABLE(e500, E500, PMC_CLASS_SOFT, PMC_CLASS_E500,
 PMC_CLASS_TSC);
  ^
  https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/libpmc.c:273:3:
 note: expanded from macro 'PMC_MDEP_TABLE'
 PMC_CLASS_##C, __VA_ARGS__  \
 ^
  scratch space:64:1: note: expanded from here
  PMC_CLASS_E500
  ^
  
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:144:2:
 note: 'PMC_CLASS_P5' declared here
 __PMC_CLASSES()
 ^
  
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:125:2:
 note: expanded from macro '__PMC_CLASSES'
 __PMC_CLASS(P5) /* Intel Pentium counters */\
 ^
  
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:143:24:
 note: expanded from macro '__PMC_CLASS'
  #define __PMC_CLASS(N)  PMC_CLASS_##N ,
 ^
  scratch space:46:1: note: expanded from here
  PMC_CLASS_P5
  ^
  https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/libpmc.c:302:44:
 error: use of undeclared identifier 'PMC_CLASS_E500'; did you mean
 'PMC_CLASS_P5'?
  PMC_MDEP_TABLE(e500, E500, PMC_CLASS_SOFT, PMC_CLASS_E500,
 PMC_CLASS_TSC);
^~
PMC_CLASS_P5
  https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/libpmc.c:273:18:
 note: expanded from macro 'PMC_MDEP_TABLE'
 PMC_CLASS_##C, __VA_ARGS__  \
^
  
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:144:2:
 note: 'PMC_CLASS_P5' declared here
 __PMC_CLASSES()
 ^
  
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:125:2:
 note: expanded from macro '__PMC_CLASSES'
 __PMC_CLASS(P5) /* Intel Pentium counters */\
 ^
  
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:143:24:
 note: expanded from macro '__PMC_CLASS'
  #define __PMC_CLASS(N)  PMC_CLASS_##N ,
 ^
  scratch space:46:1: note: expanded from here
  PMC_CLASS_P5
  ^
  https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/libpmc.c:2961:7:
 error: use of undeclared identifier 'PMC_CLASS_E500'; did you mean
 'PMC_CLASS_P5'?
 case PMC_CLASS_E500:
  ^~
  PMC_CLASS_P5
  
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:144:2:
 note: 'PMC_CLASS_P5' declared here
 __PMC_CLASSES()
 ^
  
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:125:2:
 note: expanded from macro '__PMC_CLASSES'
 __PMC_CLASS(P5) /* Intel Pentium counters */\
 ^
  
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:143:24:
 note: expanded from macro '__PMC_CLASS'
  #define __PMC_CLASS(N)  PMC_CLASS_##N ,
 ^
  scratch space:46:1: note: expanded from here

Re: Build failed in Jenkins: FreeBSD_HEAD #2663

[Justin Hibbits]

Sorry about that. Forgot the pmc.h changes.

-Justin
On Apr 18, 2015 4:53 PM, Justin Hibbits jhibb...@freebsd.org wrote:

 Crap, sorry. I wonder how that compiled fine for me. I'll fix it in a
 couple hours when I get home.

 -Justin
 On Apr 18, 2015 4:49 PM, Garrett Cooper yaneurab...@gmail.com wrote:


  On Apr 18, 2015, at 15:56, jenkins-ad...@freebsd.org wrote:


  === lib/libpmc (all)
  --- libpmc.So ---
  cc  -fpic -DPIC  -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 -Wmissing-variable-declarations
 -Wthread-safety -Wno-empty-body -Wno-string-plus-int
 -Wno-unused-const-variable -Qunused-arguments -c 
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/libpmc.c -o
 libpmc.So
  --- pmclog.So ---
  cc  -fpic -DPIC  -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 -Wmissing-variable-declarations
 -Wthread-safety -Wno-empty-body -Wno-string-plus-int
 -Wno-unused-const-variable -Qunused-arguments -c 
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/pmclog.c -o
 pmclog.So
  --- libpmc.So ---
  https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/libpmc.c:302:1:
 error: use of undeclared identifier 'PMC_CLASS_E500'; did you mean
 'PMC_CLASS_P5'?
  PMC_MDEP_TABLE(e500, E500, PMC_CLASS_SOFT, PMC_CLASS_E500,
 PMC_CLASS_TSC);
  ^
  https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/libpmc.c:273:3:
 note: expanded from macro 'PMC_MDEP_TABLE'
 PMC_CLASS_##C, __VA_ARGS__  \
 ^
  scratch space:64:1: note: expanded from here
  PMC_CLASS_E500
  ^
  
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:144:2:
 note: 'PMC_CLASS_P5' declared here
 __PMC_CLASSES()
 ^
  
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:125:2:
 note: expanded from macro '__PMC_CLASSES'
 __PMC_CLASS(P5) /* Intel Pentium counters */\
 ^
  
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:143:24:
 note: expanded from macro '__PMC_CLASS'
  #define __PMC_CLASS(N)  PMC_CLASS_##N ,
 ^
  scratch space:46:1: note: expanded from here
  PMC_CLASS_P5
  ^
  https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/libpmc.c:302:44:
 error: use of undeclared identifier 'PMC_CLASS_E500'; did you mean
 'PMC_CLASS_P5'?
  PMC_MDEP_TABLE(e500, E500, PMC_CLASS_SOFT, PMC_CLASS_E500,
 PMC_CLASS_TSC);
^~
PMC_CLASS_P5
  https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/libpmc.c:273:18:
 note: expanded from macro 'PMC_MDEP_TABLE'
 PMC_CLASS_##C, __VA_ARGS__  \
^
  
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:144:2:
 note: 'PMC_CLASS_P5' declared here
 __PMC_CLASSES()
 ^
  
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:125:2:
 note: expanded from macro '__PMC_CLASSES'
 __PMC_CLASS(P5) /* Intel Pentium counters */\
 ^
  
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:143:24:
 note: expanded from macro '__PMC_CLASS'
  #define __PMC_CLASS(N)  PMC_CLASS_##N ,
 ^
  scratch space:46:1: note: expanded from here
  PMC_CLASS_P5
  ^
  https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/libpmc.c:2961:7:
 error: use of undeclared identifier 'PMC_CLASS_E500'; did you mean
 'PMC_CLASS_P5'?
 case PMC_CLASS_E500:
  ^~
  PMC_CLASS_P5
  
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:144:2:
 note: 'PMC_CLASS_P5' declared here
 __PMC_CLASSES()
 ^
  
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:125:2:
 note: expanded from macro '__PMC_CLASSES'
 __PMC_CLASS(P5) /* Intel Pentium counters */\
 ^
  
 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h:143:24:
 note: expanded from macro '__PMC_CLASS

Re: Request for testing an alternate branch

[Justin Hibbits]

On Wed, Mar 18, 2015 at 12:12 AM,  lausg...@gmail.com wrote:

 6 дек. 2013 г., в 23:40, Justin Hibbits jhibb...@freebsd.org написал(а):

 On Wed, Dec 4, 2013 at 10:19 PM, Justin Hibbits jhibb...@freebsd.org wrote:
 I've been working on the projects/pmac_pmu branch for some time now to
 add suspend/resume as well as CPU speed change for certain PowerPC
 machines, about a year since I created the branch, and now it's stable
 enough that I want to merge it into HEAD, hence this request.

 Thanks for your work! What is the estimated time when it will go HEAD?
 May I expect that my powerbook4,1 machine will get ability to sleep under the 
 FreeBSD now?

 However,
 it does touch several drivers, turning them into early drivers, such
 that they can be initialized, and suspended and resumed at a different
 time.  Saying that, I do need testing from other architectures, to make
 sure I haven't broken anything.

 The technical details:

 To get proper ordering, I've extended the bus_generic_suspend() and
 bus_generic_resume() to do multiple passes.  Devices which cannot be
 enabled or disabled at the current pass level would return an EAGAIN.
 This could possibly cause problems, since it's an addition to an
 existing API rather than a new API to run along side it, so it needs a
 great deal of testing.  It works fine on PowerPC, but I don't have any
 i386/amd64 or sparc64 hardware to test it on, so would like others who
 do to test it.  I don't thin

 Also, any comments are of course welcome.  Technical concerns are
 obviously welcome, and I will try to address everything.

 Thanks,

 Justin

 Thanks to hrs@, images are now available for the pmac_pmu project on
 allbsd for i386, amd64, sparc64, and ia64:
 https://pub.allbsd.org/FreeBSD-snapshots/ .

 I understand that you provided these so people with another archs could test 
 whether it doesn't break anything, but what about actual PPC users? ;)
 Considering that powerpc is a Tier 2 these days, it's not that easy even to 
 get svn quickly for it to grab your tree, so I would ask adding 
 projects_pmac_pmu to the powerpc building. Thanks.

There were some design decisions that people took issue with, so I've
been working on that.  I plan to merge the bulk of the work into HEAD
soon, but only the driver suspend/resume routines.  The additional
updates for suspending the system as a whole won't be made for some
time, due to the intrusiveness of the change.  I'm still planning for
this to be completed for the 11.0 release, and with the bulk of the
work completed, that should be feasible.

I don't have a PowerBook4,1 to test with, but I think it should work,
but some drivers may not resume properly.

- Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Massive libxo-zation that breaks everything

[Justin Hibbits]

On Tue, Mar 3, 2015 at 11:14 AM, Alfred Perlstein bri...@mu.org wrote:


 On Mar 3, 2015, at 11:07 AM, Justin Hibbits jr...@alumni.cwru.edu wrote:

 On Tue, Mar 3, 2015 at 10:39 AM, Alfred Perlstein bri...@mu.org wrote:


 Sent from my iPhone

 On Mar 3, 2015, at 9:32 AM, hiren panchasara hi...@strugglingcoder.info 
 wrote:

 On 03/02/15 at 07:33P, Alfred Perlstein wrote:


 Actually I want to shame third party ports into adopting libxo (or at 
 least providing machine readable output).

 I know it's scary to try to lead the pack, after all we could be wrong, 
 but maybe it's time to try something new and see what happens.

 And no, your idea doesn't make sense it just will lead to those files bit 
 rotting.

 Bedsides that you don't even have a real spec other than it should be 
 done differently.

 Again, show the code.

 Wow. He told you want he didn't like and he moved on. I hope/wish we as
 a project can take criticism more positively than this.

 Answer to every criticism should not be show me your code. We (should)
 know better than that.

 Maybe I am too old school but the motd on freefall is still now shut up 
 and code. I still believe that's right.

 We ALL need to know when to step back from an issue we really do not have 
 the bandwidth to constructively contribute to.

 This doesn't mean ideas or concerns aren't valid, but that unless you truly 
 have the bandwidth to contribute, taking a step back is a good idea.

 -Alfred.

 You're both right.  Maybe we need a hackathon on this.  Is BSDCan too late?

 Hackathon on what exactly?

 -Alfred

libifying base.  And, if there's still stuff that needs libxo'd, do
that, too.  Looking at both could help to derive a clean library API
that libxo'd interfaces can use.

libifying base has been on my interesting TODO list for the last 10
years or so, I just haven't had the inclination.  Now that there's
been a swell of support for it, getting people together to actually
make it happen seems like a good idea.

- Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Massive libxo-zation that breaks everything

[Justin Hibbits]

On Tue, Mar 3, 2015 at 10:39 AM, Alfred Perlstein bri...@mu.org wrote:


 Sent from my iPhone

 On Mar 3, 2015, at 9:32 AM, hiren panchasara hi...@strugglingcoder.info 
 wrote:

 On 03/02/15 at 07:33P, Alfred Perlstein wrote:



 Actually I want to shame third party ports into adopting libxo (or at least 
 providing machine readable output).

 I know it's scary to try to lead the pack, after all we could be wrong, but 
 maybe it's time to try something new and see what happens.

 And no, your idea doesn't make sense it just will lead to those files bit 
 rotting.

 Bedsides that you don't even have a real spec other than it should be done 
 differently.

 Again, show the code.

 Wow. He told you want he didn't like and he moved on. I hope/wish we as
 a project can take criticism more positively than this.

 Answer to every criticism should not be show me your code. We (should)
 know better than that.

 Maybe I am too old school but the motd on freefall is still now shut up and 
 code. I still believe that's right.

 We ALL need to know when to step back from an issue we really do not have the 
 bandwidth to constructively contribute to.

 This doesn't mean ideas or concerns aren't valid, but that unless you truly 
 have the bandwidth to contribute, taking a step back is a good idea.

 -Alfred.

You're both right.  Maybe we need a hackathon on this.  Is BSDCan too late?

- Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Questions on adding backlight support for the i915 driver

[Justin Hibbits]

Would it make sense to have a generic 'backlight' driver framework
that we plug into?  I wrote a backlight driver (well, 2, but both show
up as dev.backlight in sysctl) for powerpc, but if we want to have
even more individual backlight drivers, I think it makes sense to make
them all look the same, with similar configuration properties.

- Justin

On Fri, Jan 30, 2015 at 3:16 PM, Adrian Chadd adr...@freebsd.org wrote:
 Hi,

 Which chipset is it?

 Loading acpi_video causes a handful of interconnected pieces to shift
 (as IIRC at that point acpi_video also states that it wishes to take
 control of video setting, not just leave it all up to ACPI to drive
 itself.)

 There's a bunch of discussion / code churn in the linux dri2/i915 code
 (/past/ the point in 2012 that our code is currently synced to) about
 how to manage backlights. A lot of it seems due to ridiculously large
 variations in how backlights are actually managed.

 So, if we're going to do this, I think we should actually have a
 generic backlight thing that figures out if the right thing to do is
 talk to the underlying device/panel, rather than hang backlight
 controls off of each driver. It may not always be off of drm. :(
 There's also stuff surrounding locking and state changes, as well as
 restoring backlight values after a suspend/resume cycle. That kind of
 weird crap.

 But I'd start with which chipset it is, which version of FreeBSD it
 is, and whether the ACPI stuff would work for you with a code update.
 But for a more general future thing, I'd rather we had a sysctl tree
 of actual display devices, each one mapping to the underlying thing
 it's controlling, so it's a generic API for both getting and setting
 values for the various displays that are hooked into things.



 -adrian

 On 27 January 2015 at 22:38, Elizabeth Myers elizab...@interlinked.me wrote:
 Hello,

 I want to add backlight support to the i915 driver in FreeBSD. It seems
 that two magic addresses are read and wrote from to change the backlight
 itself. It supports rather fine-level granularity all the way down to
 zero. Right now I use a hacked-up userland program that reads
 from/writes to these addresses, which is far from an ideal solution.

 I am interested in this because the acpi_video(4) driver does not
 support my backlight on my Dell Inspiron 15 3521 (not terribly
 suprising, on Linux I needed a special Dell-specific driver, and I'm not
 sure even that really used ACPI, I never really checked).

 My questions are really twofold:

 1) How can this be exposed appropriately? I would prefer this be exposed
 generally so upower could grok it. As far as I can tell upower uses
 hw.acpi.video.lcd0 to control backlight. I am not sure that upower is
 doing the right thing here, though.
 2) Where would the code go for this? The dri2 driver seems the most
 logical place, but maybe it belongs in X and exposed via a program? Or
 something else entirely that I'm not thinking of?

 I have experience developing PCI drivers and doing other PCI related
 doodads, and some kernel development experience, as well as general C
 experience, but I'm not by any means an expert on the matter.

 Cheers,
 Elizabeth Myers

 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

OOM killer and kernel cache reclamation rate limit in vm_pageout_scan()

[Justin T. Gibbs]

avg pointed out the rate limiting code in vm_pageout_scan() during discussion 
about PR 187594.  While it certainly can contribute to the problems discussed 
in that PR, a bigger problem is that it can allow the OOM killer to be 
triggered even though there is plenty of reclaimable memory available in the 
system.  Any load that can consume enough pages within the polling interval to 
hit the v_free_min threshold (e.g. multiple 'dd if=/dev/zero of=/file/on/zfs') 
can make this happen.

The product I’m working on does not have swap configured and treats any OOM 
trigger as fatal, so it is very obvious when this happens. :-)

I’ve tried several things to mitigate the problem.  The first was to ignore 
rate limiting for pass 2.  However, even though ZFS is guaranteed to receive 
some feedback prior to OOM being declared, my testing showed that a trivial 
load (a couple dd operations) could still consume enough of the reclaimed space 
to leave the system below its target at the end of pass 2.  After removing the 
rate limiting entirely, I’ve so far been unable to kill the system via a ZFS 
induced load.

I understand the motivation behind the rate limiting, but the current 
implementation seems too simplistic to be safe.  The documentation for the 
Solaris slab allocator provides good motivation for their approach of using a 
“sliding average” to reign in temporary bursts of usage without unduly harming 
efficient service for the recorded steady-state memory demand.  Regardless of 
the approach taken, I believe that the OOM killer must be a last resort and 
shouldn’t be called when there are caches that can be culled.

One other thing I’ve noticed in my testing with ZFS is that it needs feedback 
and a little time to react to memory pressure.  Calling it’s lowmem handler 
just once isn’t enough for it to limit in-flight writes so it can avoid reuse 
of pages that it just freed up.  But, it doesn’t take too long to react ( 1sec 
in the profiling I’ve done).  Is there a way in vm_pageout_scan() that we can 
better record that progress is being made (pages were freed in the pass, even 
if some/all of them were consumed again) and allow more passes before the OOM 
killer is invoked in this case?

—
Justin

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

bwn(4) testing

[Justin Hibbits]

Since I don't have a machine that successfully suspends/resumes, can
someone test the patch at https://reviews.freebsd.org/D802 ?  It
shouldn't be any functional change, just removing code duplicated by
bus_generic_* functions.

Thanks,
Justin


signature.asc
Description: PGP signature

Re: What do you use for kernel debugging?

[Justin Hibbits]

On Mon, 29 Sep 2014 02:31:25 +0200
José Pérez Arauzo f...@aoek.com wrote:

 I hope Dcons + 1394 works where it's applicable.
 
 BR,
 
 --
 José Pérez Arauzo

As a constant user of DCons+firewire, I can say it certainly works, and
quite well at that.  At least on PowerPC where firewire is everywhere.
I only wish it were possible to use dcons+firewire even earlier in the
boot (before the firewire device is probed), maybe initialize something
in the loader.

- Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Boot failure with r272146

[Justin Hibbits]

That fixed it, thanks!

-Justin
On Sep 26, 2014 6:59 AM, Ian Lepore i...@freebsd.org wrote:

 On Thu, 2014-09-25 at 20:40 -0700, Justin Hibbits wrote:
  With r272146 my SATA controller fails to attach, preventing the kernel
  from mounting root.  I've attached a log of as much as dconschat would
  allow.  The relevant portion is pcib10:
 
  atapci0: ServerWorks K2 SATA150 controller mem 0xfa402000-0xfa403fff
  at device 12.0 on pci10 pcib1: failed to reserve resource for pcib10
  pcib10: failed to allocate initial I/O port window (0-0x,0x10)
  atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, 0x).
  atapci0: unable to map interrupt
  device_attach: atapci0 attach returned 6
 
  pcib10: allocated memory range (0xfa40-0xfa400fff) for rid 10 of
  pci1:3:14:0 atapci0: ServerWorks K2 SATA150 controller mem
  0xfa402000-0xfa403fff at device 12.0 on pci10 pcib1: failed to reserve
  resource for pcib10 pcib10: failed to allocate initial I/O port window
  (0-0x,0x10) atapci0: 0x10 bytes of rid 0x20 res 4 failed (0,
  0x). atapci0: unable to map interrupt
  device_attach: atapci0 attach returned 6
  ata0: Shasta Kauai ATA Controller mem 0xfa404000-0xfa407fff at device
  13.0 on pci10 ofw_pci mapdev: start fa404000, len 16384
  ata0: unable to allocate interrupt
  device_attach: ata0 attach returned 6
 
 
  It works fine with r271697 kernel (latest I have booting).  I haven't
  yet tried bisecting.
 
  Hardware is a PowerMac G5 (last generation).
 
  - Justin

 Ooops, I think a paste-o in my r272109 caused it.  See if this fixes it.

 -- Ian




 Index: sys/powerpc/ofw/ofw_pcibus.c
 ===
 --- sys/powerpc/ofw/ofw_pcibus.c(revision 272109)
 +++ sys/powerpc/ofw/ofw_pcibus.c(working copy)
 @@ -201,7 +201,7 @@ ofw_pcibus_enum_devtree(device_t dev, u_int domain
  * resource list.
  */
 if (dinfo-opd_dinfo.cfg.intpin == 0)
 -   ofw_bus_intr_to_rl(dev, node,
 dinfo-opd_dinfo.resources);
 +   ofw_bus_intr_to_rl(dev, child,
 dinfo-opd_dinfo.resources);
 }
  }



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Boot failure with r272146

[Justin Hibbits]

With r272146 my SATA controller fails to attach, preventing the kernel
from mounting root.  I've attached a log of as much as dconschat would
allow.  The relevant portion is pcib10:

atapci0: ServerWorks K2 SATA150 controller mem 0xfa402000-0xfa403fff
at device 12.0 on pci10 pcib1: failed to reserve resource for pcib10
pcib10: failed to allocate initial I/O port window (0-0x,0x10)
atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, 0x).
atapci0: unable to map interrupt
device_attach: atapci0 attach returned 6

pcib10: allocated memory range (0xfa40-0xfa400fff) for rid 10 of
pci1:3:14:0 atapci0: ServerWorks K2 SATA150 controller mem
0xfa402000-0xfa403fff at device 12.0 on pci10 pcib1: failed to reserve
resource for pcib10 pcib10: failed to allocate initial I/O port window
(0-0x,0x10) atapci0: 0x10 bytes of rid 0x20 res 4 failed (0,
0x). atapci0: unable to map interrupt
device_attach: atapci0 attach returned 6
ata0: Shasta Kauai ATA Controller mem 0xfa404000-0xfa407fff at device
13.0 on pci10 ofw_pci mapdev: start fa404000, len 16384
ata0: unable to allocate interrupt
device_attach: ata0 attach returned 6


It works fine with r271697 kernel (latest I have booting).  I haven't
yet tried bisecting.

Hardware is a PowerMac G5 (last generation).

- Justin

kernel_boot.fail
Description: Binary data
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Poor state of the build infrastructure.

[Justin Hibbits]

On Wed, 24 Sep 2014 16:33:46 -0700
Marcel Moolenaar mar...@xcllnt.net wrote:

 
 On Sep 24, 2014, at 12:54 PM, John Baldwin j...@freebsd.org wrote:
 
  On Tuesday, September 23, 2014 09:29:48 AM Marcel Moolenaar wrote:
  What is going on here?
  Are we still in some kind of flux and people aren't done yet or is
  this the intended state by virtue of noone having anything left on
  there TODO list?
  
  Sorry to ask a dumb question, but are you sure you did the make
  buildworld first?  Shouldn't that have errored if it couldn't build
  crt1?
 
 The root cause problem was that MAKEOBJDIRPREFIX was not set
 to whatever it was set to during buildworld. That was easy
 enough to figure out when a bunch of things don't add up.

That's a very annoying problem, and even more annoying to track down.


 But neither problem mentioned in the email had anything to
 do with MAKEOBJDIRPREFIX. Having to set the COMPILER_TYPE
 as part of an install is a bug. Entering a powerpc buildenv
 and having a compiler that builds for the host (or maybe
 just some default) is a regression.

When MAKEOBJDIRPREFIX isn't set, it takes whatever compiler it can
find.  It should probably error out instead, since the build
environment isn't sane at this point.  I ran into this probably a few
weeks back.

 The only thing the FreeBSD build is good at, really, is
 building in /usr/src for the host. The rest is just not
 up to par and I think it harms FreeBSD beyond belief.

I have no problems building outside of /usr/src.

- Justin


signature.asc
Description: PGP signature

Re: libthr and main thread stack size

[Justin T. Gibbs]

On Sep 20, 2014, at 11:06 AM, Konstantin Belousov kostik...@gmail.com wrote:

 On Fri, Sep 19, 2014 at 03:27:25PM -0400, John Baldwin wrote:
 I suspect it was done out of reasons of being overly conservative in
 interpreting RLIMIT_STACK. I think it is quite surprising behavior
 though and would rather we make your option the default and implement
 what the Open Group says above.
 
 Ok, below is the patch.  I felt bad about adding yet another magic and
 undocumented tunable to our libthr.  Since there seems to be no
 alternative than a tunable to enforce old behaviour, I documented
 the quirks I am aware of.

Why do we need to support the old behavior?  Any program that ran in the old 
model will run in the new.  In the unlikely event that someone was using the 
old scheme for administrative control, there are other mechanisms for this 
already available that we can point them to instead.

—
Justin


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: libthr and main thread stack size

[Justin T. Gibbs]

On Aug 8, 2014, at 5:22 AM, Konstantin Belousov kostik...@gmail.com wrote:

…

 Below is the patch which adds environment variable LIBPTHREAD_BIGSTACK_MAIN.
 Setting it to any value results in the main thread stack left as is, and
 other threads allocate stack below the area of RLIMIT_STACK.  Try it.
 I do not want to set this behaviour as default.

Is there a reason this should not be the default?  Looking at the getrlimit() 
page on the OpenGroup’s site they say:

RLIMIT_STACK
This is the maximum size of the initial thread's stack, in bytes. The 
implementation does not automatically grow the stack beyond this limit. If this 
limit is exceeded, SIGSEGV shall be generated for the thread. If the thread is 
blocking SIGSEGV, or the process is ignoring or catching SIGSEGV and has not 
made arrangements to use an alternate stack, the disposition of SIGSEGV shall 
be set to SIG_DFL before it is generated.

Does posix say something different?

I ran into this issue when debugging a segfault on Postgres when running an 
(arguably quite bogus) query that should have fit within both the configured 
stack rlimit and Postgres’ configured stack limit.  The Postgres backend is 
really just single threaded, but happens to pull in libpthread due to the 
threading support in some of the libraries it uses.  The segfault definitely 
violates POLA.

—
Justin


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Child suspend/resume

[Justin Hibbits]

Thanks Alexandr!

- Justin

On Wed, Aug 13, 2014 at 11:33 PM, Alexandr Krivulya
shur...@shurik.kiev.ua wrote:
 I've done three suspend/resume cycle during last workday and all works
 fine. Sorry for misled.

 13.08.2014 18:35, Justin Hibbits пишет:
 That's odd, because another tester reported everything worked correctly
 for him.  Could you send me the output of a verbose boot dmesg (boot
 -v), devinfo -rv, and pciconf -lv?

 Thanks,
 Justin

 On Wed, 13 Aug 2014 09:17:24 +0300
 Alexandr Krivulya shur...@shurik.kiev.ua wrote:

 Now laptop resumes, screen turned on and I see in dmesg acpi: resumed
 at ..., but neither keyboard nor mouse don't work and host is not
 accessible from network.

 12.08.2014 17:06, Justin Hibbits пишет:
 Hi Alexandr,

 Thanks.  I got another confirmation that it didn't work, and may
 have found the cause.  I have another patch that you can find at
 https://phabric.freebsd.org/D590 which fixes a typo that I had made.
 Could you try that?

 (Added current@ so everyone else sees this as well).

 Thanks!

 - Justin

 On Tue, 12 Aug 2014 11:18:29 +0300
 Alexandr Krivulya shur...@shurik.kiev.ua wrote:

 Hi, Justin
 After applying your patch my thinkpad e530 (FreeBSD 11.0-CURRENT,
 amd64) doesn't resume any more - screen remains black.

 11.08.2014 08:30, Justin Hibbits (by way of Justin Hibbits
 chmeeed...@gmail.com) пишет:
 Hi all,

 The attached patch is completely untested, due to lack of existing
 suspendable hardware (no x86 machines).  It does compile cleanly
 against head, though. I don't think it should change any behavior,
 I tried to keep the essence of the code path the same.

 It was suggested that I break up my multipass suspend/resume code
 into incremental parts, so this is part one.  It adds a
 BUS_SUSPEND_CHILD/BUS_RESUME_CHILD, as well as helper functions,
 bus_generic_suspend_child()/bus_generic_resume_child(), and
 modifies the PCI driver to use this new facility.

 I'd like some feedback, and testing of this, to make sure I didn't
 break anything.

 Thanks,
 Justin


 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to
 freebsd-current-unsubscr...@freebsd.org
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to
 freebsd-current-unsubscr...@freebsd.org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Child suspend/resume

[Justin Hibbits]

That's odd, because another tester reported everything worked correctly
for him.  Could you send me the output of a verbose boot dmesg (boot
-v), devinfo -rv, and pciconf -lv?

Thanks,
Justin

On Wed, 13 Aug 2014 09:17:24 +0300
Alexandr Krivulya shur...@shurik.kiev.ua wrote:

 Now laptop resumes, screen turned on and I see in dmesg acpi: resumed
 at ..., but neither keyboard nor mouse don't work and host is not
 accessible from network.
 
 12.08.2014 17:06, Justin Hibbits пишет:
  Hi Alexandr,
 
  Thanks.  I got another confirmation that it didn't work, and may
  have found the cause.  I have another patch that you can find at
  https://phabric.freebsd.org/D590 which fixes a typo that I had made.
  Could you try that?
 
  (Added current@ so everyone else sees this as well).
 
  Thanks!
 
  - Justin
 
  On Tue, 12 Aug 2014 11:18:29 +0300
  Alexandr Krivulya shur...@shurik.kiev.ua wrote:
 
  Hi, Justin
  After applying your patch my thinkpad e530 (FreeBSD 11.0-CURRENT,
  amd64) doesn't resume any more - screen remains black.
 
  11.08.2014 08:30, Justin Hibbits (by way of Justin Hibbits
  chmeeed...@gmail.com) пишет:
  Hi all,
 
  The attached patch is completely untested, due to lack of existing
  suspendable hardware (no x86 machines).  It does compile cleanly
  against head, though. I don't think it should change any behavior,
  I tried to keep the essence of the code path the same.
 
  It was suggested that I break up my multipass suspend/resume code
  into incremental parts, so this is part one.  It adds a
  BUS_SUSPEND_CHILD/BUS_RESUME_CHILD, as well as helper functions,
  bus_generic_suspend_child()/bus_generic_resume_child(), and
  modifies the PCI driver to use this new facility.
 
  I'd like some feedback, and testing of this, to make sure I didn't
  break anything.
 
  Thanks,
  Justin
 
 
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to
  freebsd-current-unsubscr...@freebsd.org
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to
  freebsd-current-unsubscr...@freebsd.org
 

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Child suspend/resume

[Justin Hibbits]

Hi Alexandr,

Thanks.  I got another confirmation that it didn't work, and may have
found the cause.  I have another patch that you can find at
https://phabric.freebsd.org/D590 which fixes a typo that I had made.
Could you try that?

(Added current@ so everyone else sees this as well).

Thanks!

- Justin

On Tue, 12 Aug 2014 11:18:29 +0300
Alexandr Krivulya shur...@shurik.kiev.ua wrote:

 Hi, Justin
 After applying your patch my thinkpad e530 (FreeBSD 11.0-CURRENT,
 amd64) doesn't resume any more - screen remains black.
 
 11.08.2014 08:30, Justin Hibbits (by way of Justin Hibbits
 chmeeed...@gmail.com) пишет:
  Hi all,
 
  The attached patch is completely untested, due to lack of existing
  suspendable hardware (no x86 machines).  It does compile cleanly
  against head, though. I don't think it should change any behavior,
  I tried to keep the essence of the code path the same.
 
  It was suggested that I break up my multipass suspend/resume code
  into incremental parts, so this is part one.  It adds a
  BUS_SUSPEND_CHILD/BUS_RESUME_CHILD, as well as helper functions,
  bus_generic_suspend_child()/bus_generic_resume_child(), and modifies
  the PCI driver to use this new facility.
 
  I'd like some feedback, and testing of this, to make sure I didn't
  break anything.
 
  Thanks,
  Justin
 
 
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to
  freebsd-current-unsubscr...@freebsd.org
 

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Child suspend/resume

[Justin Hibbits]

Hi all,

The attached patch is completely untested, due to lack of existing
suspendable hardware (no x86 machines).  It does compile cleanly against
head, though. I don't think it should change any behavior, I tried to
keep the essence of the code path the same.

It was suggested that I break up my multipass suspend/resume code into
incremental parts, so this is part one.  It adds a
BUS_SUSPEND_CHILD/BUS_RESUME_CHILD, as well as helper functions,
bus_generic_suspend_child()/bus_generic_resume_child(), and modifies
the PCI driver to use this new facility.

I'd like some feedback, and testing of this, to make sure I didn't
break anything.

Thanks,
JustinIndex: sys/kern/bus_if.m
===
--- sys/kern/bus_if.m	(revision 269798)
+++ sys/kern/bus_if.m	(working copy)
@@ -670,3 +670,25 @@
 	device_t	_child;
 	u_int		_irq;
 } DEFAULT null_remap_intr;
+
+/**
+ * @brief Suspend a given child
+ *
+ * @param _dev		the parent device of @p _child
+ * @param _child	the device to suspend
+ */
+METHOD int suspend_child {
+	device_t	_dev;
+	device_t	_child;
+} DEFAULT bus_generic_suspend_child;
+
+/**
+ * @brief Resume a given child
+ *
+ * @param _dev		the parent device of @p _child
+ * @param _child	the device to resume
+ */
+METHOD int resume_child {
+	device_t	_dev;
+	device_t	_child;
+} DEFAULT bus_generic_suspend_child;
Index: sys/kern/subr_bus.c
===
--- sys/kern/subr_bus.c	(revision 269798)
+++ sys/kern/subr_bus.c	(working copy)
@@ -135,6 +135,7 @@
 #define	DF_DONENOMATCH	0x20		/* don't execute DEVICE_NOMATCH again */
 #define	DF_EXTERNALSOFTC 0x40		/* softc not allocated by us */
 #define	DF_REBID	0x80		/* Can rebid after attach */
+#define	DF_SUSPENDED	0x100		/* Device is suspended. */
 	u_int	order;			/** order from device_add_child_ordered() */
 	void	*ivars;			/** instance variables  */
 	void	*softc;			/** current driver's variables  */
@@ -3631,6 +3632,37 @@
 }
 
 /**
+ * @brief Default function for suspending a child device.
+ *
+ * This function is to be used by a bus's DEVICE_SUSPEND_CHILD().
+ */
+int
+bus_generic_suspend_child(device_t dev, device_t child)
+{
+	int	error;
+
+	error = DEVICE_SUSPEND(child);
+
+	if (error == 0)
+		dev-flags |= DF_SUSPENDED;
+	return (error);
+}
+
+/**
+ * @brief Default function for resuming a child device.
+ *
+ * This function is to be used by a bus's DEVICE_RESUME_CHILD().
+ */
+int
+bus_generic_resume_child(device_t dev, device_t child)
+{
+	DEVICE_RESUME(child);
+
+	dev-flags = ~DF_SUSPENDED;
+	return (0);
+}
+
+/**
  * @brief Helper function for implementing DEVICE_SUSPEND()
  *
  * This function can be used to help implement the DEVICE_SUSPEND()
@@ -3646,12 +3678,12 @@
 	device_t	child, child2;
 
 	TAILQ_FOREACH(child, dev-children, link) {
-		error = DEVICE_SUSPEND(child);
+		error = BUS_SUSPEND_CHILD(dev, child);
 		if (error) {
 			for (child2 = TAILQ_FIRST(dev-children);
 			 child2  child2 != child;
 			 child2 = TAILQ_NEXT(child2, link))
-DEVICE_RESUME(child2);
+BUS_RESUME_CHILD(dev, child2);
 			return (error);
 		}
 	}
@@ -3670,7 +3702,7 @@
 	device_t	child;
 
 	TAILQ_FOREACH(child, dev-children, link) {
-		DEVICE_RESUME(child);
+		BUS_RESUME_CHILD(dev, child);
 		/* if resume fails, there's nothing we can usefully do... */
 	}
 	return (0);
Index: sys/dev/pci/pci.c
===
--- sys/dev/pci/pci.c	(revision 269798)
+++ sys/dev/pci/pci.c	(working copy)
@@ -162,6 +162,8 @@
 	DEVMETHOD(bus_child_pnpinfo_str, pci_child_pnpinfo_str_method),
 	DEVMETHOD(bus_child_location_str, pci_child_location_str_method),
 	DEVMETHOD(bus_remap_intr,	pci_remap_intr_method),
+	DEVMETHOD(bus_suspend_child,	pci_suspend_child),
+	DEVMETHOD(bus_resume_child,	pci_resume_child),
 
 	/* PCI interface */
 	DEVMETHOD(pci_read_config,	pci_read_config_method),
@@ -3614,12 +3616,11 @@
 #endif
 
 static void
-pci_set_power_children(device_t dev, device_t *devlist, int numdevs,
-int state)
+pci_set_power_child(device_t dev, device_t child, int state)
 {
-	device_t child, pcib;
 	struct pci_devinfo *dinfo;
-	int dstate, i;
+	device_t pcib;
+	int dstate;
 
 	/*
 	 * Set the device to the given state.  If the firmware suggests
@@ -3629,74 +3630,74 @@
 	 * are handled separately.
 	 */
 	pcib = device_get_parent(dev);
-	for (i = 0; i  numdevs; i++) {
-		child = devlist[i];
-		dinfo = device_get_ivars(child);
-		dstate = state;
-		if (device_is_attached(child) 
-		PCIB_POWER_FOR_SLEEP(pcib, dev, dstate) == 0)
-			pci_set_powerstate(child, dstate);
-	}
+	dinfo = device_get_ivars(child);
+	dstate = state;
+	if (device_is_attached(child) 
+	PCIB_POWER_FOR_SLEEP(pcib, dev, dstate) == 0)
+		pci_set_powerstate(child, dstate);
 }
 
 int
-pci_suspend(device_t dev)
+pci_suspend_child(device_t dev, device_t child)
 {
-	device_t child, *devlist;
 	struct pci_devinfo *dinfo;
-	int error, i, numdevs;
+	int 

Re: OpenSSL vs. LibreSSL (OpenBSD)

[Justin Hibbits]

On Thu, Apr 24, 2014 at 2:41 PM, Alfred Perlstein bri...@mu.org wrote:

 On 4/24/14, 1:35 PM, O. Hartmann wrote:

 It seems that OpenBSD is now forking their own SSL implementation, called
 LibreSSL. As
 OpenBSD speaks for many similar opinion regarding the state of the code of
 OpenSSL, I'd
 like to hear what the plans are in FreeBSD for this critical portion of
 software.

 Is FreeBSD going to support the effords taken by OpenBSD and participating
 in the
 LibreSSL development (http://www.libressl.org/)?

 oh

 We need to discuss the use of comic sans font across our web properties
 first.

 -Alfred

You, sir, win 2 internets.

- Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Build failure on PowerPC in pf

[Justin Hibbits]

Building on PowerPC I see the following failure:

cc1: warnings being treated as errors

/home/chmeee/freebsd/head/sys/modules/pf/../../netpfil/pf/pf_ioctl.c:
In function 'pfioctl':
/home/chmeee/freebsd/head/sys/modules/pf/../../netpfil/pf/pf_ioctl.c:1357:warning:
cast to pointer from integer of different size [-Wint-to-pointer-cast]
/home/chmeee/freebsd/head/sys/modules/pf/../../netpfil/pf/pf_ioctl.c:1359:warning:
cast to pointer from integer of different size [-Wint-to-pointer-cast]
/home/chmeee/freebsd/head/sys/modules/pf/../../netpfil/pf/pf_ioctl.c:1361:warning:
cast to pointer from integer of different size [-Wint-to-pointer-cast]

struct pf_rule has counter_u64_t entries, which are actually pointers
to uint64_t's.  These pointers get assigned from the result of
counter_u64_fetch(), which returns a uint64_t.  Looks to me like
there's a bug in here, but I have no idea what to do to fix it.  And
I'm surprised this hasn't been reported against other 32-bit
architectures.

- Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Build failure on PowerPC in pf

[Justin Hibbits]

On Wed, Feb 26, 2014 at 10:32 AM, Justin Hibbits jr...@alumni.cwru.edu wrote:
 Building on PowerPC I see the following failure:

 cc1: warnings being treated as errors

 /home/chmeee/freebsd/head/sys/modules/pf/../../netpfil/pf/pf_ioctl.c:
 In function 'pfioctl':
 /home/chmeee/freebsd/head/sys/modules/pf/../../netpfil/pf/pf_ioctl.c:1357:warning:
 cast to pointer from integer of different size [-Wint-to-pointer-cast]
 /home/chmeee/freebsd/head/sys/modules/pf/../../netpfil/pf/pf_ioctl.c:1359:warning:
 cast to pointer from integer of different size [-Wint-to-pointer-cast]
 /home/chmeee/freebsd/head/sys/modules/pf/../../netpfil/pf/pf_ioctl.c:1361:warning:
 cast to pointer from integer of different size [-Wint-to-pointer-cast]

 struct pf_rule has counter_u64_t entries, which are actually pointers
 to uint64_t's.  These pointers get assigned from the result of
 counter_u64_fetch(), which returns a uint64_t.  Looks to me like
 there's a bug in here, but I have no idea what to do to fix it.  And
 I'm surprised this hasn't been reported against other 32-bit
 architectures.

 - Justin

Replying to myself, it looks like this was broken by r261882.

- Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Build failure on PowerPC in pf

[Justin Hibbits]

On Wed, Feb 26, 2014 at 1:20 PM, John-Mark Gurney j...@funkthat.com wrote:
 Justin Hibbits wrote this message on Wed, Feb 26, 2014 at 11:12 -0800:
 On Wed, Feb 26, 2014 at 10:32 AM, Justin Hibbits jr...@alumni.cwru.edu 
 wrote:
  Building on PowerPC I see the following failure:
 
  cc1: warnings being treated as errors
 
  /home/chmeee/freebsd/head/sys/modules/pf/../../netpfil/pf/pf_ioctl.c:
  In function 'pfioctl':
  /home/chmeee/freebsd/head/sys/modules/pf/../../netpfil/pf/pf_ioctl.c:1357:warning:
  cast to pointer from integer of different size [-Wint-to-pointer-cast]
  /home/chmeee/freebsd/head/sys/modules/pf/../../netpfil/pf/pf_ioctl.c:1359:warning:
  cast to pointer from integer of different size [-Wint-to-pointer-cast]
  /home/chmeee/freebsd/head/sys/modules/pf/../../netpfil/pf/pf_ioctl.c:1361:warning:
  cast to pointer from integer of different size [-Wint-to-pointer-cast]
 
  struct pf_rule has counter_u64_t entries, which are actually pointers
  to uint64_t's.  These pointers get assigned from the result of
  counter_u64_fetch(), which returns a uint64_t.  Looks to me like
  there's a bug in here, but I have no idea what to do to fix it.  And
  I'm surprised this hasn't been reported against other 32-bit
  architectures.

 Replying to myself, it looks like this was broken by r261882.

 This comment says it all:
 1352glebius 261882  /*
 1353* XXXGL: this is what happens when internal kernel
 1354* structures are used as ioctl API structures.
 1355*/

 So, one way could be to use a union for the states:
 union {
 struct {
 counter_u64_t states_cur;
 counter_u64_t states_tot;
 counter_u64_t src_nodes;
 } k;
 struct {
 uint64_t states_cur;
 uint64_t states_tot;
 uint64_t src_nodes;
 } u;
 } u;

 The other option is to cast through uintptr_t...

 Even though it'd make the code a bit more ugly, I'd vote for the union,
 since it's designed for what the code is trying to do...

 --
   John-Mark Gurney  Voice: +1 415 225 5579

  All that I will do, has been done, All that I have, has not.

Casting through uintptr_t eliminated the warning.  But, like you said,
the union is the better way to go.

- Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for testing an alternate branch

[Justin Hibbits]

On Thu, 12 Dec 2013 14:15:47 -0500
John Baldwin j...@freebsd.org wrote:

 On Wednesday, December 11, 2013 5:40:30 pm Justin Hibbits wrote:
  On Wed, Dec 11, 2013 at 1:26 PM, John Baldwin j...@freebsd.org
  wrote:
   On Thursday, December 05, 2013 1:21:13 am Justin Hibbits wrote:
   I've been working on the projects/pmac_pmu branch for some time
   now to add suspend/resume as well as CPU speed change for
   certain PowerPC machines, about a year since I created the
   branch, and now it's stable enough that I want to merge it into
   HEAD, hence this request. However, it does touch several
   drivers, turning them into early drivers, such that they can
   be initialized, and suspended and resumed at a different time.
   Saying that, I do need testing from other architectures, to make
   sure I haven't broken anything.
  
   The technical details:
  
   To get proper ordering, I've extended the bus_generic_suspend()
   and bus_generic_resume() to do multiple passes.  Devices which
   cannot be enabled or disabled at the current pass level would
   return an EAGAIN. This could possibly cause problems, since it's
   an addition to an existing API rather than a new API to run
   along side it, so it needs a great deal of testing.  It works
   fine on PowerPC, but I don't have any i386/amd64 or sparc64
   hardware to test it on, so would like others who do to test it.
   I don't think that it would impact x86 at all (testing is
   obviously required), because the nexus is not an
   EARLY_DRIVER_MODULE, so all devices would be handled at the same
   pass.  But, I do know the sparc64 has an EARLY_DRIVER_MODULE()
   nexus, so that will likely be impacted.
  
   I have patches to change many x86 drivers to use
   EARLY_DRIVER_MODULE() FWIW.
  
   Also, I'm still not a fan of the EAGAIN approach.  I'd rather
   have a method in bus_if.m to suspend or resume a single device
   and to track that a device is suspended or resumed via a device_t
   flag or some such. (I think I had suggested this previously as it
   would also allow us to have a tool to suspend/resume individual
   drivers at runtime apart from a full suspend/resume request).
  
   --
   John Baldwin
  
  Understood.  You had mentioned something along those lines before.
  Is it safe/sane to partially merge a branch into HEAD?  If so, I can
  merge only the changes necessary for PMU cpufreq, and work on the
  suspend/resume separately.  I put them together because most of the
  low level code involved is the same between them.
 
 Yes, you can split them up.  However, the way to do that is to
 generate a diff and patch that into a head checkout and commit.
 There's not a good way to have 'svn merge' do it AFAIK.
 
  I do like your idea of a device_t flag, but I'm not sure what the
  best way to go with that would be.  I do already use a device_t
  flag to determine if the device is suspended, but only
  bus_generic_* access that in this patch.
  
  Would a better way be:
  * root_suspend instead of suspending its children, instead traverses
  and suspends each descendent in reverse order.
   * While doing this, insert each device upon successful suspend
  into a list.
  * For root_resume(), traverse the list back, and suspend each device
  in the reverse order.
 
 I would rather do it more the way that multipass attach now works
 where you do scans of the entire device tree as you walk the pass
 number down (during suspend) suspending any devices that are not yet
 suspended if their pass number is = current pass number, then on
 resume you do scans of the entire tree raising the pass number back
 up using similar logic to attach where you resume any suspended
 devices if the driver's pass number is = current pass number.
 
  With this, add a new method, called device_suspend_child() to
  suspend a specific child if it hasn't already been suspended.
 
 Well, I would call it 'bus_suspend_child' and 'bus_resume_child' as
 these would be bus methods in bus_if.m.
 
   * This could require modifying the PCI driver to move the device
  child suspend/resume into those functions, instead of doing that
  logic in the device_suspend/device_resume itself.
 
 Correct.  bus_generic_suspend() and bus_suspend_resume() would turn
 into loops that look a lot like bus_generic_new_pass() (so the logic
 for honoring pass numbers would happen in these routines and they
 would invoke bus_suspend_child() and bus_resume_child() to change the
 state of individual drivers).
 
 device_suspend() and device_resume() for the root device would look
 like bus_set_pass() with a similar loop that walked through the pass
 levels and invoked bus_generic_suspend/resume after each pass change
 to start the pass across the device tree.
  
  I guess, in short, I'm asking:  Is it fine if I merge only the code
  necessary for this cpufreq?  That would require making other changes
  to this before merging in, to isolate that code, but it's very
  doable.
  
  - Justin
  
 

John,

Would it make

Re: Request for testing an alternate branch

[Justin Hibbits]

On Wed, Dec 11, 2013 at 1:26 PM, John Baldwin j...@freebsd.org wrote:
 On Thursday, December 05, 2013 1:21:13 am Justin Hibbits wrote:
 I've been working on the projects/pmac_pmu branch for some time now to
 add suspend/resume as well as CPU speed change for certain PowerPC
 machines, about a year since I created the branch, and now it's stable
 enough that I want to merge it into HEAD, hence this request. However,
 it does touch several drivers, turning them into early drivers, such
 that they can be initialized, and suspended and resumed at a different
 time.  Saying that, I do need testing from other architectures, to make
 sure I haven't broken anything.

 The technical details:

 To get proper ordering, I've extended the bus_generic_suspend() and
 bus_generic_resume() to do multiple passes.  Devices which cannot be
 enabled or disabled at the current pass level would return an EAGAIN.
 This could possibly cause problems, since it's an addition to an
 existing API rather than a new API to run along side it, so it needs a
 great deal of testing.  It works fine on PowerPC, but I don't have any
 i386/amd64 or sparc64 hardware to test it on, so would like others who
 do to test it.  I don't think that it would impact x86 at all (testing
 is obviously required), because the nexus is not an EARLY_DRIVER_MODULE,
 so all devices would be handled at the same pass.  But, I do know the
 sparc64 has an EARLY_DRIVER_MODULE() nexus, so that will likely be
 impacted.

 I have patches to change many x86 drivers to use EARLY_DRIVER_MODULE()
 FWIW.

 Also, I'm still not a fan of the EAGAIN approach.  I'd rather have a method
 in bus_if.m to suspend or resume a single device and to track that a device
 is suspended or resumed via a device_t flag or some such. (I think I had
 suggested this previously as it would also allow us to have a tool to
 suspend/resume individual drivers at runtime apart from a full suspend/resume
 request).

 --
 John Baldwin

Understood.  You had mentioned something along those lines before.  Is
it safe/sane to partially merge a branch into HEAD?  If so, I can
merge only the changes necessary for PMU cpufreq, and work on the
suspend/resume separately.  I put them together because most of the
low level code involved is the same between them.

I do like your idea of a device_t flag, but I'm not sure what the best
way to go with that would be.  I do already use a device_t flag to
determine if the device is suspended, but only bus_generic_* access
that in this patch.

Would a better way be:
* root_suspend instead of suspending its children, instead traverses
and suspends each descendent in reverse order.
 * While doing this, insert each device upon successful suspend into a list.
* For root_resume(), traverse the list back, and suspend each device
in the reverse order.

With this, add a new method, called device_suspend_child() to suspend
a specific child if it hasn't already been suspended.
 * This could require modifying the PCI driver to move the device
child suspend/resume into those functions, instead of doing that logic
in the device_suspend/device_resume itself.

I guess, in short, I'm asking:  Is it fine if I merge only the code
necessary for this cpufreq?  That would require making other changes
to this before merging in, to isolate that code, but it's very doable.

- Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for testing an alternate branch

[Justin Hibbits]

On Dec 8, 2013 5:39 AM, Marius Strobl mar...@alchemy.franken.de wrote:

 On Wed, Dec 04, 2013 at 10:21:13PM -0800, Justin Hibbits wrote:
  I've been working on the projects/pmac_pmu branch for some time now to
  add suspend/resume as well as CPU speed change for certain PowerPC
  machines, about a year since I created the branch, and now it's stable
  enough that I want to merge it into HEAD, hence this request. However,
  it does touch several drivers, turning them into early drivers, such
  that they can be initialized, and suspended and resumed at a different
  time.  Saying that, I do need testing from other architectures, to make
  sure I haven't broken anything.
 
  The technical details:
 
  To get proper ordering, I've extended the bus_generic_suspend() and
  bus_generic_resume() to do multiple passes.  Devices which cannot be
  enabled or disabled at the current pass level would return an EAGAIN.
  This could possibly cause problems, since it's an addition to an
  existing API rather than a new API to run along side it, so it needs a
  great deal of testing.  It works fine on PowerPC, but I don't have any
  i386/amd64 or sparc64 hardware to test it on, so would like others who
  do to test it.  I don't think that it would impact x86 at all (testing
  is obviously required), because the nexus is not an EARLY_DRIVER_MODULE,
  so all devices would be handled at the same pass.  But, I do know the
  sparc64 has an EARLY_DRIVER_MODULE() nexus, so that will likely be
  impacted.
 
  Also, any comments are of course welcome.  Technical concerns are
  obviously welcome, and I will try to address everything.

 Do you have a patch against head?

 Marius


I can generate one today.

- Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for testing an alternate branch

[Justin Hibbits]

On Dec 8, 2013 3:48 PM, Justin Hibbits chmeeed...@gmail.com wrote:

 On Sun, 8 Dec 2013 14:38:53 +0100
 Marius Strobl mar...@alchemy.franken.de wrote:

  On Wed, Dec 04, 2013 at 10:21:13PM -0800, Justin Hibbits wrote:
   I've been working on the projects/pmac_pmu branch for some time now
   to add suspend/resume as well as CPU speed change for certain
   PowerPC machines, about a year since I created the branch, and now
   it's stable enough that I want to merge it into HEAD, hence this
   request. However, it does touch several drivers, turning them into
   early drivers, such that they can be initialized, and suspended
   and resumed at a different time.  Saying that, I do need testing
   from other architectures, to make sure I haven't broken anything.
  
   The technical details:
  
   To get proper ordering, I've extended the bus_generic_suspend() and
   bus_generic_resume() to do multiple passes.  Devices which cannot be
   enabled or disabled at the current pass level would return an
   EAGAIN. This could possibly cause problems, since it's an addition
   to an existing API rather than a new API to run along side it, so
   it needs a great deal of testing.  It works fine on PowerPC, but I
   don't have any i386/amd64 or sparc64 hardware to test it on, so
   would like others who do to test it.  I don't think that it would
   impact x86 at all (testing is obviously required), because the
   nexus is not an EARLY_DRIVER_MODULE, so all devices would be
   handled at the same pass.  But, I do know the sparc64 has an
   EARLY_DRIVER_MODULE() nexus, so that will likely be impacted.
  
   Also, any comments are of course welcome.  Technical concerns are
   obviously welcome, and I will try to address everything.
 
  Do you have a patch against head?
 
  Marius
 

 Here you go.

 - Justin

Oh I must add that this was just a merge, I didn't try compiling this
merge, but there were no conflicts so it should build. But images are up on
allbsd.org for people to test.

-Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for testing an alternate branch

[Justin Hibbits]

On Wed, Dec 4, 2013 at 10:19 PM, Justin Hibbits jhibb...@freebsd.org wrote:
 I've been working on the projects/pmac_pmu branch for some time now to
 add suspend/resume as well as CPU speed change for certain PowerPC
 machines, about a year since I created the branch, and now it's stable
 enough that I want to merge it into HEAD, hence this request. However,
 it does touch several drivers, turning them into early drivers, such
 that they can be initialized, and suspended and resumed at a different
 time.  Saying that, I do need testing from other architectures, to make
 sure I haven't broken anything.

 The technical details:

 To get proper ordering, I've extended the bus_generic_suspend() and
 bus_generic_resume() to do multiple passes.  Devices which cannot be
 enabled or disabled at the current pass level would return an EAGAIN.
 This could possibly cause problems, since it's an addition to an
 existing API rather than a new API to run along side it, so it needs a
 great deal of testing.  It works fine on PowerPC, but I don't have any
 i386/amd64 or sparc64 hardware to test it on, so would like others who
 do to test it.  I don't thin

 Also, any comments are of course welcome.  Technical concerns are
 obviously welcome, and I will try to address everything.

 Thanks,

 Justin

Thanks to hrs@, images are now available for the pmac_pmu project on
allbsd for i386, amd64, sparc64, and ia64:
https://pub.allbsd.org/FreeBSD-snapshots/ .

- Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Request for testing an alternate branch

[Justin Hibbits]

I've been working on the projects/pmac_pmu branch for some time now to
add suspend/resume as well as CPU speed change for certain PowerPC
machines, about a year since I created the branch, and now it's stable
enough that I want to merge it into HEAD, hence this request. However,
it does touch several drivers, turning them into early drivers, such
that they can be initialized, and suspended and resumed at a different
time.  Saying that, I do need testing from other architectures, to make
sure I haven't broken anything.

The technical details:

To get proper ordering, I've extended the bus_generic_suspend() and
bus_generic_resume() to do multiple passes.  Devices which cannot be
enabled or disabled at the current pass level would return an EAGAIN.
This could possibly cause problems, since it's an addition to an
existing API rather than a new API to run along side it, so it needs a
great deal of testing.  It works fine on PowerPC, but I don't have any
i386/amd64 or sparc64 hardware to test it on, so would like others who
do to test it.  I don't think that it would impact x86 at all (testing
is obviously required), because the nexus is not an EARLY_DRIVER_MODULE,
so all devices would be handled at the same pass.  But, I do know the
sparc64 has an EARLY_DRIVER_MODULE() nexus, so that will likely be
impacted.

Also, any comments are of course welcome.  Technical concerns are
obviously welcome, and I will try to address everything.

Thanks,

Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Internal compiler error on gcc with latest updates

[Justin Hibbits]

Yesterday I started a full world update for my machine (powerpc64), but
the new gcc import ICEs at emit-rtl.c:1784, when compiling zdb.  I
haven't tried reverting contrib/gcc yet, but is there a good way to
debug this?

- Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Internal compiler error on gcc with latest updates

[Justin Hibbits]

On Dec 2, 2013 10:26 AM, Craig Rodrigues rodr...@freebsd.org wrote:

 On Mon, Dec 2, 2013 at 6:40 AM, Justin Hibbits chmeeed...@gmail.com
wrote:

 Yesterday I started a full world update for my machine (powerpc64), but
 the new gcc import ICEs at emit-rtl.c:1784, when compiling zdb.  I
 haven't tried reverting contrib/gcc yet, but is there a good way to
 debug this?


 If you are getting the same Internal Compiler Error,
 it may be worth doing a web search on the GCC web site to see if it is a
known issue:

 https://www.google.com/#q=site:gcc.gnu.org

 --
 Craig

Good idea. It looks like it is related to GCC bug 48561/21307.

-Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Zpool not recognized after disk moved to different name

[Justin Hibbits]

Hi, I'm migrating a system exhibiting the click of death to a new hard
drive, on PowerPC, and in the process migrating to zfs.  I set up the
system, then pulled the old drive out. Now, the spool that was on ada1s5 is
now on ada0s5, and zfs won't recognize this pool. I can't recreate the
pool, it says it is too dangerous.  Is there any way to reactivate this
pool after the disk name change?

Thanks,
Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Zpool not recognized after disk moved to different name

[Justin Hibbits]

On Oct 20, 2013 10:12 AM, Allan Jude free...@allanjude.com wrote:

 On 2013-10-20 13:07, Justin Hibbits wrote:
  Hi, I'm migrating a system exhibiting the click of death to a new hard
  drive, on PowerPC, and in the process migrating to zfs.  I set up the
  system, then pulled the old drive out. Now, the spool that was on
ada1s5 is
  now on ada0s5, and zfs won't recognize this pool. I can't recreate the
  pool, it says it is too dangerous.  Is there any way to reactivate this
  pool after the disk name change?
 
  Thanks,
  Justin
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to 
freebsd-current-unsubscr...@freebsd.org

 Please provide the output of the following commands:

 gpart show
 zpool import
 zdb -l /dev/each device/slice you think might be the ZFS


 --
 Allan Jude

Hi Allan,

I was missing the zpool import' command, hadn't seen it before, but a forum
search found its usage for me. Had to do a 'zpool import -f' on the pool,
but now it is up and fully functional.  Seems obvious now :-)

Thanks,
Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ZFS secondarycache on SSD problem on r255173

[Justin T. Gibbs]

You'll have to be more specific.  I don't have that email or know what list on 
which to search.

Thanks,
Justin

On Oct 16, 2013, at 2:01 AM, Vitalij Satanivskij sa...@ukr.net wrote:

 Hello.
 
 Patch brocke cache functionality.
 
 Look at's Dmitriy's mail from  Mon, 07 Oct 2013 21:09:06 +0300
 
 With subject ZFS L2ARC - incorrect size and abnormal system load on r255173
 
 As patch alredy in head and BETA it's not good.
 
 Yesterday we update one machine up to beta1 and forgot about patch. So 12 
 Hours and cache broken... :((
 
 
 
 Dmitriy Makarov wrote:
 DM The attached patch by Steven Hartland fixes issue for me too. Thank you! 
 DM 
 DM 
 DM --- Исходное сообщение --- 
 DM От кого: Steven Hartland  kill...@multiplay.co.uk  
 DM Дата: 18 сентября 2013, 01:53:10 
 DM 
 DM - Original Message - 
 DM From: Justin T. Gibbs  
 DM 
 DM --- 
 DM Дмитрий Макаров 
 DM ___
 DM freebsd-current@freebsd.org mailing list
 DM http://lists.freebsd.org/mailman/listinfo/freebsd-current
 DM To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ZFS secondarycache on SSD problem on r255173

[Justin T. Gibbs]

I took a quick look at arc.c and see that the trim_map_free() calls don't take 
into account ashift.  I don't know if that has anything to do with your problem 
though.  I would expect this would just make the trim less efficient, but I 
need to dig further.

--
Justin

On Oct 16, 2013, at 4:42 PM, Justin T. Gibbs gi...@freebsd.org wrote:

 You'll have to be more specific.  I don't have that email or know what list 
 on which to search.
 
 Thanks,
 Justin
 
 On Oct 16, 2013, at 2:01 AM, Vitalij Satanivskij sa...@ukr.net wrote:
 
 Hello.
 
 Patch brocke cache functionality.
 
 Look at's Dmitriy's mail from  Mon, 07 Oct 2013 21:09:06 +0300
 
 With subject ZFS L2ARC - incorrect size and abnormal system load on r255173
 
 As patch alredy in head and BETA it's not good.
 
 Yesterday we update one machine up to beta1 and forgot about patch. So 12 
 Hours and cache broken... :((
 
 
 
 Dmitriy Makarov wrote:
 DM The attached patch by Steven Hartland fixes issue for me too. Thank you! 
 DM 
 DM 
 DM --- Исходное сообщение --- 
 DM От кого: Steven Hartland  kill...@multiplay.co.uk  
 DM Дата: 18 сентября 2013, 01:53:10 
 DM 
 DM - Original Message - 
 DM From: Justin T. Gibbs  
 DM 
 DM --- 
 DM Дмитрий Макаров 
 DM ___
 DM freebsd-current@freebsd.org mailing list
 DM http://lists.freebsd.org/mailman/listinfo/freebsd-current
 DM To unsubscribe, send any mail to 
 freebsd-current-unsubscr...@freebsd.org
 
 
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: undefined reference to xenpci_alloc_space

[Justin T. Gibbs]

On Oct 10, 2013, at 12:40 PM, Michael Schmiedgen schmied...@gmx.net wrote:

 Hi List,
 
 is it intended that kernel does not build if
 
 device xenpci
 
 is omitted in the kernel config? I get the following error:
 
 linking kernel
 gnttab.o: In function `gnttab_resume':
 /usr/src/sys/xen/gnttab.c:(.text+0xe47): undefined reference to 
 `xenpci_alloc_space'
 
 Thanks,
  Michael
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 

XENHVM depends on xenpci, so you must remove XENHVM if you remove
xenpci.  Perhaps we should make a change similar to the attached
patch in order to make this clear?

--
Justin



GENERIC.diff
Description: Binary data
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ZFS secondarycache on SSD problem on r255173

[Justin T. Gibbs]

On Sep 17, 2013, at 4:53 PM, Steven Hartland kill...@multiplay.co.uk wrote:

 - Original Message - From: Justin T. Gibbs gi...@freebsd.org
 
 
 Sorry for being slow to chime in on this thread.  I live in Boulder, CO and 
 we've had a bit of rain. :-)
 
 Hope all is well your side, everyone safe and sound if may be little wetter 
 than usual.

I have been very fortunate.

 As Steven pointed out, the warning is benign, but does show that the code I 
 committed to
 -current is not optimizing the allocation size for L2ARC devices.  The fix 
 for this is to find
 the best place during pool creation/load/import to call 
 vdev_ashift_optimize() on L2ARC
 devices.  I will look into this tomorrow, but feel free to suggest a good 
 spot if you look at it
 before I can.
 
 The attached patch fixes this for me, not sure if its ideal place for it and 
 consideration may be
 needed in combination with persistent l2arc.

Persistent l2arc will require storing and checking the ashift recorded in the 
label so bugs and
or quirk table changes don't confuse the system.  But for now, with no 
persistent l2arc support
in the tree, I think your placement is fine.  I've submitted a request to RE so 
I can put your fix into head.

--
Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: -ffunction-sections, -fdata-sections and -Wl,--gc-sections

[Justin Hibbits]

On Sep 17, 2013 4:31 PM, Adrian Chadd adr...@freebsd.org wrote:

 On 17 September 2013 16:22, Ian Lepore i...@freebsd.org wrote:

  On Tue, 2013-09-17 at 14:56 -0700, Adrian Chadd wrote:
   ... I'd rather see if we can actually separate out things some more so
   these builds can shrink.
  
   Eg, if there's malloc related functions that aren't used, maybe we
should
   break malloc down into a directory full of functions.
  
 
  Why is that better than using this automated solution?
 

 Not everyone is going to run clang on their target development platform?
:-)

 Personally I'd rather structure my work to behave better instead of doing
 something that relies on a specific tool/suite to be able to optimise.


Gcc also supports this. I used it when generating builds with newlib for
microcontrollers at a previous job.

-Justin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ZFS secondarycache on SSD problem on r255173

[Justin T. Gibbs]

Sorry for being slow to chime in on this thread.  I live in Boulder, CO and 
we've had a bit of rain. :-)

As Steven pointed out, the warning is benign, but does show that the code I 
committed to -current is not optimizing the allocation size for L2ARC devices.  
The fix for this is to find the best place during pool creation/load/import to 
call vdev_ashift_optimize() on L2ARC devices.  I will look into this tomorrow, 
but feel free to suggest a good spot if you look at it before I can.

--
Justin

On Sep 16, 2013, at 6:43 AM, Steven Hartland kill...@multiplay.co.uk wrote:

 Thats correct the new code knows the what the ashift of the underlying disk 
 should
 be so if it detects a vdev with a lower ashift you get this warning.
 
 I suspect the issue is that cache devices don't have an ashift, so when the 
 check
 is done it gets a default value and hence the warning.
 
 I'd have to did some more to see how ashift in cache devices is or isn't 
 implemented.
 
   Regards
   Steve
 
 - Original Message - From: Dmitriy Makarov suppor...@ukr.net
 To: Steven Hartland kill...@multiplay.co.uk
 Cc: Borja Marcos bor...@sarenet.es; freebsd-current@freebsd.org; 
 Justin T. Gibbs gi...@freebsd.org
 Sent: Monday, September 16, 2013 1:29 PM
 Subject: Re[3]: ZFS secondarycache on SSD problem on r255173
 
 
 And have to say that ashift of a main pool doesn't matter.
 I've tried to create pool with ashift 9 (default value) and with ashift 12 
 with creating gnops over gpart devices, export pool, destroy gnops, import 
 pool. There is the same problem with cache device.
 
 There is no problem with ZIL devices, they reports ashift: 12
 
 children[1]:
 type: 'disk'
 id: 1
 guid: 6986664094649753344
 path: '/dev/gpt/zil1'
 phys_path: '/dev/gpt/zil1'
 whole_disk: 1
 metaslab_array: 67
 metaslab_shift: 25
 ashift: 12
 asize: 4290248704
 is_log: 1
 create_txg: 22517
 
 Problem with cache devices only, but in zdb output tere is nothing at all 
 about them.
 
 --- Исходное сообщение --- От кого: Steven Hartland  
 kill...@multiplay.co.uk 
 Дата: 16 сентября 2013, 14:18:31
 
 Cant say I've ever had a issue with gnop, but I haven't used it for
 some time.
 
 I did have a quick look over the weekend at your issue and it looks
 to me like warning for the cache is a false positive, as the vdev
 for cache doesn't report an ashift in zdb so could well be falling
 back to a default value.
 
 I couldn't reproduce the issue for log here, it just seems to work
 for me, can you confirm what ashift is reported for your devices
 using: zdb pool
 
   Regards
   Steve
 - Original Message - From: Borja Marcos 
 
 --- Дмитрий Макаров
 
 
 --- Дмитрий Макаров
 
 
 
 This e.mail is private and confidential between Multiplay (UK) Ltd. and the 
 person or entity to whom it is addressed. In the event of misdirection, the 
 recipient is prohibited from using, copying, printing or otherwise 
 disseminating it or any information contained in it. 
 In the event of misdirection, illegible or incomplete transmission please 
 telephone +44 845 868 1337
 or return the E.mail to postmas...@multiplay.co.uk.
 
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: dirmngr won't link with liblber.so?

[Justin Hibbits]

I filled a PR on this: Ports/181230.

- Justin
On Sep 6, 2013 12:23 PM, Michael Butler i...@protected-networks.net
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 09/06/13 15:17, Baptiste Daroussin wrote:
  On Fri, Sep 06, 2013 at 03:14:05PM -0400, Michael Butler wrote:
  What's up with this? I recompiled openldap-client; I can do a 'nm
  liblber-2.4.so.8' without error but .. dirmngr won't link it?

  [ .. snip .. ]

 
  That mean the port is missing a LDFLAG: -llber-2.4

 Thanks! That fixed it :-)

 imb
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.14 (FreeBSD)

 iEYEARECAAYFAlIqK6QACgkQQv9rrgRC1JKGsgCgypNCgSYnaALv56XhKuLqvXth
 6NEAoMj5uNCkboSr7zDVddr3V/QfEbpn
 =FVbW
 -END PGP SIGNATURE-
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [head tinderbox] failure on powerpc/powerpc

[Justin Hibbits]

Wow, not sure how this skipped by me.  Will fix this evening.

-Justin
On Sep 4, 2013 1:33 PM, FreeBSD Tinderbox tinder...@freebsd.org wrote:

 TB --- 2013-09-04 17:40:07 - tinderbox 2.10 running on
 freebsd-current.sentex.ca
 TB --- 2013-09-04 17:40:07 - FreeBSD freebsd-current.sentex.ca8.3-PRERELEASE 
 FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
 TB --- 2013-09-04 17:40:07 - starting HEAD tinderbox run for
 powerpc/powerpc
 TB --- 2013-09-04 17:40:07 - cleaning the object tree
 TB --- 2013-09-04 17:41:20 - /usr/local/bin/svn stat /src
 TB --- 2013-09-04 17:41:23 - At svn revision 255201
 TB --- 2013-09-04 17:41:24 - building world
 TB --- 2013-09-04 17:41:24 - CROSS_BUILD_TESTING=YES
 TB --- 2013-09-04 17:41:24 - MAKEOBJDIRPREFIX=/obj
 TB --- 2013-09-04 17:41:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
 TB --- 2013-09-04 17:41:24 - SRCCONF=/dev/null
 TB --- 2013-09-04 17:41:24 - TARGET=powerpc
 TB --- 2013-09-04 17:41:24 - TARGET_ARCH=powerpc
 TB --- 2013-09-04 17:41:24 - TZ=UTC
 TB --- 2013-09-04 17:41:24 - __MAKE_CONF=/dev/null
 TB --- 2013-09-04 17:41:24 - cd /src
 TB --- 2013-09-04 17:41:24 - /usr/bin/make -B buildworld
  Building an up-to-date make(1)
  World build started on Wed Sep  4 17:41:31 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 Wed Sep  4 20:22:29 UTC 2013
 TB --- 2013-09-04 20:22:29 - generating LINT kernel config
 TB --- 2013-09-04 20:22:29 - cd /src/sys/powerpc/conf
 TB --- 2013-09-04 20:22:29 - /usr/bin/make -B LINT
 TB --- 2013-09-04 20:22:29 - cd /src/sys/powerpc/conf
 TB --- 2013-09-04 20:22:29 - /usr/sbin/config -m LINT
 TB --- 2013-09-04 20:22:29 - building LINT kernel
 TB --- 2013-09-04 20:22:29 - CROSS_BUILD_TESTING=YES
 TB --- 2013-09-04 20:22:29 - MAKEOBJDIRPREFIX=/obj
 TB --- 2013-09-04 20:22:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
 TB --- 2013-09-04 20:22:29 - SRCCONF=/dev/null
 TB --- 2013-09-04 20:22:29 - TARGET=powerpc
 TB --- 2013-09-04 20:22:29 - TARGET_ARCH=powerpc
 TB --- 2013-09-04 20:22:29 - TZ=UTC
 TB --- 2013-09-04 20:22:29 - __MAKE_CONF=/dev/null
 TB --- 2013-09-04 20:22:29 - cd /src
 TB --- 2013-09-04 20:22:29 - /usr/bin/make -B buildkernel KERNCONF=LINT
  Kernel build for LINT started on Wed Sep  4 20:22:30 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
 [...]
 hwpmc_powerpc.c:(.text+0xd6): undefined reference to `powerpc_pcpu'
 hwpmc_powerpc.o: In function `pmc_md_initialize':
 hwpmc_powerpc.c:(.text+0x192): undefined reference to `powerpc_pcpu'
 hwpmc_powerpc.c:(.text+0x196): undefined reference to `powerpc_pcpu'
 hwpmc_powerpc.c:(.text+0x1d8): undefined reference to
 `pmc_mpc7xxx_initialize'
 hwpmc_powerpc.o: In function `powerpc_describe':
 hwpmc_powerpc.c:(.text+0x272): undefined reference to `powerpc_pcpu'
 hwpmc_powerpc.c:(.text+0x276): undefined reference to `powerpc_pcpu'
 *** Error code 1

 Stop.
 bmake[1]: stopped in /obj/powerpc.powerpc/src/sys/LINT
 *** Error code 1

 Stop.
 bmake: stopped in /src
 *** Error code 1

 Stop in /src.
 TB --- 2013-09-04 20:33:01 - WARNING: /usr/bin/make returned exit code  1
 TB --- 2013-09-04 20:33:01 - ERROR: failed to build LINT kernel
 TB --- 2013-09-04 20:33:01 - 8673.46 user 1121.14 system 10374.41 real


 http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org