hwpmc / amd panic when stopping pmcstat

2016-11-07 Thread Andriy Gapon 

panic: [pmc,1473] pp_pmcval outside of expected range cpu=2 ri=17
pp_pmcval=fa529f5b pm_reloadcount=1

(kgdb) p pp->pp_pmcs[17].pp_pmc->pm_state
$2 = PMC_STATE_DELETED

Those are interesting bits.  The counter is logically stopped and the value read
from the hardware is small (become huge after "munging").  My theory is that, at
least for AMD processors, a counter keeps running after overflowing.
At the same time, amd_intr() takes an early way out if pm_state !=
PMC_STATE_RUNNING.  So, the counter is allowed to overflow if it's logically
stopped.  But that makes the assertion in pmc_process_csw_out() invalid.

It seems that the following patch fixes the problem.
But I wonder if there is a better, perhaps hardware specific, fix.

Also, maybe the condition should be pm_state == PMC_STATE_RUNNING instead of
pm_state != PMC_STATE_DELETED.

diff --git a/sys/dev/hwpmc/hwpmc_mod.c b/sys/dev/hwpmc/hwpmc_mod.c
index 55dc499b1c40e..36bcccb8c27ac 100644
--- a/sys/dev/hwpmc/hwpmc_mod.c
+++ b/sys/dev/hwpmc/hwpmc_mod.c
@@ -1431,8 +1431,8 @@ pmc_process_csw_out(struct thread *td)
 * save the reading.
 */

-   if (pp != NULL && pp->pp_pmcs[ri].pp_pmc != NULL) {
-
+   if (pm->pm_state != PMC_STATE_DELETED && pp != NULL &&
+   pp->pp_pmcs[ri].pp_pmc != NULL) {
KASSERT(pm == pp->pp_pmcs[ri].pp_pmc,
("[pmc,%d] pm %p != pp_pmcs[%d] %p", __LINE__,
pm, ri, pp->pp_pmcs[ri].pp_pmc));

-- 
Andriy Gapon
___
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: FYI: a Pine64+ 2G aarch64 head -r308247 crash and some information about it

2016-11-07 Thread Mark Millard 
On 2016-Nov-7, at 8:54 PM, Mark Millard  wrote:

> This is just in case any of the information happens to prove 
> useful/interesting.
> I'm not expecting any assistance.
> 
> Note: After the crash ddb was not responding to input so this is all that I 
> have.
> 
> Note: This was an experiment with head -r308247 but was built like stable for
>  performance issues (GENERIC included and then overridden, not GENERIC-UP
>  based).
> 
> The below was found via dmesg and/or /var/log/messages content while the 
> Pine64
> was busy building lang/gcc6 and its prerequisites (as a stability test).
> 
> It got lots of spurious interrupt notices per second, such as:
> 
>> gic0: Spurious interrupt detected: last irq: 27 on CPU0
>> gic0: Spurious interrupt detected: last irq: 27 on CPU2
>> gic0: Spurious interrupt detected: last irq: 106 on CPU3
>> gic0: Spurious interrupt detected: last irq: 27 on CPU1
>> gic0: Spurious interrupt detected: last irq: 27 on CPU1
>> gic0: gic0: Spurious interrupt detected: last irq: 27 on CPU1
>> Spurious interrupt detected: last irq: 27 on CPU3
>> gic0: gic0: Spurious interrupt detected: last irq: 27 on CPU0
>> Spurious interrupt detected: last irq: 27 on CPU1
>> gic0: Spurious interrupt detected: last irq: 27 on CPU1
>> gic0: Spurious interrupt detected: last irq: 27 on CPU2
>> gic0: Spurious interrupt detected: last irq: 27 on CPU3
> 
> 27 happened the most by far. 106 was fairly rare. I'd not noticed any other
> figures. From what I saw all were "gic0".
> 
> sh had a few signal 11's and one signal 4 as of when I had last checked:
> 
>> pid 13900 (sh), uid 0: exited on signal 11 (core dumped)
>> pid 19325 (sh), uid 0: exited on signal 11 (core dumped)
>> pid 49697 (sh), uid 0: exited on signal 11 (core dumped)
>> pid 68390 (sh), uid 0: exited on signal 4 (core dumped)
>> pid 81149 (sh), uid 0: exited on signal 11 (core dumped)
> 
> I did not notice any other core dumps.
> 
> And the following happened once that I noticed:
> 
>> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 16 a3 a4 80 00 00 40 00 
>> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
>> (da0:umass-sim0:0:0:0): Retrying command
> 
> The root filesystem was on a USB SSD.
> 
> The above was all from a ssh session history. The below is from the serial
> console. . .
> 
> Later it got the crash:
> 
>> panic: ARM64TODO: reclaim_pv_chunk
>> cpuid = 2
>> KDB: stack backtrace:
>> db_trace_self() at db_trace_self_wrapper+0x28
>>pc = 0x0068b430  lr = 0x000631dc
>>sp = 0x83758080  fp = 0x83758290
>> 
>> db_trace_self_wrapper() at vpanic+0x170
>>pc = 0x000631dc  lr = 0x00335f10
>>sp = 0x837582a0  fp = 0x83758320
>> 
>> vpanic() at panic+0x4c
>>pc = 0x00335f10  lr = 0x00335d9c
>>sp = 0x83758330  fp = 0x837583b0
>> 
>> panic() at reclaim_pv_chunk+0x10
>>pc = 0x00335d9c  lr = 0x006a13d4
>>sp = 0x837583c0  fp = 0x837583c0
>> 
>> reclaim_pv_chunk() at get_pv_entry+0x2bc
>>pc = 0x006a13d4  lr = 0x0069c270
>>sp = 0x837583d0  fp = 0x83758400
>> 
>> get_pv_entry() at pmap_enter+0x68c
>>pc = 0x0069c270  lr = 0x0069b41c
>>sp = 0x83758410  fp = 0x837584b0
>> 
>> pmap_enter() at vm_fault_hold+0x2f0
>>pc = 0x0069b41c  lr = 0x00641eb8
>>sp = 0x837584c0  fp = 0x83758600
>> 
>> vm_fault_hold() at vm_fault_quick_hold_pages+0x120
>>pc = 0x00641eb8  lr = 0x00645004
>>sp = 0x83758610  fp = 0x83758670
>> 
>> vm_fault_quick_hold_pages() at vn_io_fault1+0x250
>>pc = 0x00645004  lr = 0x0042b788
>>sp = 0x83758680  fp = 0x837587c0
>> 
>> vn_io_fault1() at vn_io_fault+0x170
>>pc = 0x0042b788  lr = 0x004297a4
>>sp = 0x837587d0  fp = 0x83758840
>> 
>> vn_io_fault() at dofilewrite+0xbc
>>pc = 0x004297a4  lr = 0x003a35e4
>>sp = 0x83758850  fp = 0x83758890
>> 
>> dofilewrite() at kern_writev+0x6c
>>pc = 0x003a35e4  lr = 0x003a32d4
>>sp = 0x837588a0  fp = 0x837588e0
>> 
>> kern_writev() at sys_write+0x7c
>>pc = 0x003a32d4  lr = 0x003a3258
>>sp = 0x837588f0  fp = 0x83758930
>> 
>> sys_write() at do_el0_sync+0x6fc
>>pc = 0x003a3258  lr = 0x006a2778
>>sp = 0x83758940  fp = 0x83758a70
>> 
>> do_el0_sync() at handle_el0_sync+0x64
>>pc = 0x006a2778  lr = 0x0068d1d0
>>sp = 0x83758a80  fp = 0x83758b90
>> 
>> handle_el0_sync() at 0x696ff0
>>pc = 0x0068d1d0  lr = 0x00696ff0
>>sp = 0x83758ba0  fp =

Re: DeLock 10x SATA AHCI controller not working properly

2016-11-07 Thread Alexander Motin 
As I have told before, this card is from completely different price
segment then proper SAS/SATA HBAs.  For its $80 it is not promised to be
reliable.  But in case anything can be done, I'll try to take a look on
it in couple weeks when I get one and return home.

On 07.11.2016 16:19, Daniel Engberg wrote:
> I discussed this card briefly with Alexander Motin (@mav) back in 2015,
> https://forums.freebsd.org/threads/50411/page-2#post-282648 .
> I've CCed him for suggestions.
> 
> https://lists.freebsd.org/pipermail/freebsd-current/2016-October/063668.html

-- 
Alexander Motin
___
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"

Failure during buildworld of FreeBSD 9 on FreeBSD 12.0-CURRENT

2016-11-07 Thread Dave Dodd 
Gentlefolk,

I have run into a problem building a FreeBSD 9 world & kernel on a
FreeBSD 12.0-CURRENT host.

I have my FreeBSD 9 tree located in /usr/src-9 which was refreshed via svn
yesterday.

The build is being executed on a host running FreeBSD 12.0-CURRENT #3 r308389 .

The steps that were followed were:

cd /usr/src-10
svn update
make buildworld -j8

This starts and emits the following:

root@fmaster:/usr/src-9 # make buildworld -j8
--- upgrade_checks ---
--- make ---
--
>>> Building an up-to-date make(1)
--
--- obj ---
--- _proginstall ---
sh /usr/src-9/tools/install.sh -s -o root -g wheel -m 555   make 
/usr/obj/usr/src-9/make.amd64/make
--- buildworld ---
Unknown modifier 'U'

"/usr/share/mk/bsd.compiler.mk", line 38: Malformed conditional 
(${MK_CCACHE_BUILD:Uno} == "yes" &&  !make(showconfig) &&  
(${CC:M*ccache/world/*} == "" || ${CXX:M*ccache/world/*} == ""))
"/usr/share/mk/bsd.compiler.mk", line 107: missing `in' in for
X_ in CC $${_empty_var_} XCC X_
"/usr/share/mk/bsd.compiler.mk", line 108: Malformed conditional (${cc} == "CC" 
|| !empty(XCC))
Unknown modifier 'h'

Error expanding embedded variable.
"/usr/src-9/Makefile.inc1", line 134: warning: 
"/usr/obj/usr/src-9/make.amd64/make -C /usr/src-9/release -V REVISION" returned 
non-zero status
Unknown modifier 'U'

"/usr/share/mk/bsd.compiler.mk", line 38: Malformed conditional 
(${MK_CCACHE_BUILD:Uno} == "yes" &&  !make(showconfig) &&  
(${CC:M*ccache/world/*} == "" || ${CXX:M*ccache/world/*} == ""))
"/usr/share/mk/bsd.compiler.mk", line 107: missing `in' in for
X_ in CC $${_empty_var_} XCC X_
"/usr/share/mk/bsd.compiler.mk", line 108: Malformed conditional (${cc} == "CC" 
|| !empty(XCC))
Unknown modifier 'h'

Error expanding embedded variable.
"/usr/src-9/Makefile.inc1", line 135: warning: 
"/usr/obj/usr/src-9/make.amd64/make -C /usr/src-9/release -V BRANCH" returned 
non-zero status

---

I realized that the build was using /usr/share/mk/bsd.compiler.mk

I then set the environment variable MAKESYSPATH to /usr/src-9/share/mk and
retried.

The inital errors/warning about Malformed conditionals dissapear, however
the buildworld then fails at the same point as before.

Note that a build using a FreeBSD 9 jail hosted on the same
FreeBSD 12.0-CURRENT server works correctly without problems.

I do not have any problem doing a buildworld of FreeBSD 10 world done on the sam
e FreeBSD 12.0 host.

The FreeBSD 12.0-CURRENT host does not have an /etc/make.conf or /etc/src.conf

My understanding is that building like this should work seamlessly.

I have transcripts of both builds available if required but I cannot attach
them to this email becuse of mailing list posting size limitations.

-- 
David Dodd
Bing Technologies Pty Ltd
Suite 54, Jones Bay Wharf
26-32 Pirrama Road
Pyrmont NSW 2009 Australia
Telephone +612 9552 5500 Fax +612 9552 5549
___
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"

FYI: a Pine64+ 2G aarch64 head -r308247 crash and some information about it

2016-11-07 Thread Mark Millard 
This is just in case any of the information happens to prove useful/interesting.
I'm not expecting any assistance.

Note: After the crash ddb was not responding to input so this is all that I 
have.

Note: This was an experiment with head -r308247 but was built like stable for
  performance issues (GENERIC included and then overridden, not GENERIC-UP
  based).

The below was found via dmesg and/or /var/log/messages content while the Pine64
was busy building lang/gcc6 and its prerequisites (as a stability test).

It got lots of spurious interrupt notices per second, such as:

> gic0: Spurious interrupt detected: last irq: 27 on CPU0
> gic0: Spurious interrupt detected: last irq: 27 on CPU2
> gic0: Spurious interrupt detected: last irq: 106 on CPU3
> gic0: Spurious interrupt detected: last irq: 27 on CPU1
> gic0: Spurious interrupt detected: last irq: 27 on CPU1
> gic0: gic0: Spurious interrupt detected: last irq: 27 on CPU1
> Spurious interrupt detected: last irq: 27 on CPU3
> gic0: gic0: Spurious interrupt detected: last irq: 27 on CPU0
> Spurious interrupt detected: last irq: 27 on CPU1
> gic0: Spurious interrupt detected: last irq: 27 on CPU1
> gic0: Spurious interrupt detected: last irq: 27 on CPU2
> gic0: Spurious interrupt detected: last irq: 27 on CPU3

27 happened the most by far. 106 was fairly rare. I'd not noticed any other
figures. From what I saw all were "gic0".

sh had a few signal 11's and one signal 4 as of when I had last checked:

> pid 13900 (sh), uid 0: exited on signal 11 (core dumped)
> pid 19325 (sh), uid 0: exited on signal 11 (core dumped)
> pid 49697 (sh), uid 0: exited on signal 11 (core dumped)
> pid 68390 (sh), uid 0: exited on signal 4 (core dumped)
> pid 81149 (sh), uid 0: exited on signal 11 (core dumped)

I did not notice any other core dumps.

And the following happened once that I noticed:

> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 16 a3 a4 80 00 00 40 00 
> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
> (da0:umass-sim0:0:0:0): Retrying command

The root filesystem was on a USB SSD.

The above was all from a ssh session history. The below is from the serial
console. . .

Later it got the crash:

> panic: ARM64TODO: reclaim_pv_chunk
> cpuid = 2
> KDB: stack backtrace:
> db_trace_self() at db_trace_self_wrapper+0x28
> pc = 0x0068b430  lr = 0x000631dc
> sp = 0x83758080  fp = 0x83758290
> 
> db_trace_self_wrapper() at vpanic+0x170
> pc = 0x000631dc  lr = 0x00335f10
> sp = 0x837582a0  fp = 0x83758320
> 
> vpanic() at panic+0x4c
> pc = 0x00335f10  lr = 0x00335d9c
> sp = 0x83758330  fp = 0x837583b0
> 
> panic() at reclaim_pv_chunk+0x10
> pc = 0x00335d9c  lr = 0x006a13d4
> sp = 0x837583c0  fp = 0x837583c0
> 
> reclaim_pv_chunk() at get_pv_entry+0x2bc
> pc = 0x006a13d4  lr = 0x0069c270
> sp = 0x837583d0  fp = 0x83758400
> 
> get_pv_entry() at pmap_enter+0x68c
> pc = 0x0069c270  lr = 0x0069b41c
> sp = 0x83758410  fp = 0x837584b0
> 
> pmap_enter() at vm_fault_hold+0x2f0
> pc = 0x0069b41c  lr = 0x00641eb8
> sp = 0x837584c0  fp = 0x83758600
> 
> vm_fault_hold() at vm_fault_quick_hold_pages+0x120
> pc = 0x00641eb8  lr = 0x00645004
> sp = 0x83758610  fp = 0x83758670
> 
> vm_fault_quick_hold_pages() at vn_io_fault1+0x250
> pc = 0x00645004  lr = 0x0042b788
> sp = 0x83758680  fp = 0x837587c0
> 
> vn_io_fault1() at vn_io_fault+0x170
> pc = 0x0042b788  lr = 0x004297a4
> sp = 0x837587d0  fp = 0x83758840
> 
> vn_io_fault() at dofilewrite+0xbc
> pc = 0x004297a4  lr = 0x003a35e4
> sp = 0x83758850  fp = 0x83758890
> 
> dofilewrite() at kern_writev+0x6c
> pc = 0x003a35e4  lr = 0x003a32d4
> sp = 0x837588a0  fp = 0x837588e0
> 
> kern_writev() at sys_write+0x7c
> pc = 0x003a32d4  lr = 0x003a3258
> sp = 0x837588f0  fp = 0x83758930
> 
> sys_write() at do_el0_sync+0x6fc
> pc = 0x003a3258  lr = 0x006a2778
> sp = 0x83758940  fp = 0x83758a70
> 
> do_el0_sync() at handle_el0_sync+0x64
> pc = 0x006a2778  lr = 0x0068d1d0
> sp = 0x83758a80  fp = 0x83758b90
> 
> handle_el0_sync() at 0x696ff0
> pc = 0x0068d1d0  lr = 0x00696ff0
> sp = 0x83758ba0  fp = 0xc610
> 
> KDB: enter: panic
> [ thread pid 850 tid 100149 ]
> Stopped at  kdb_enter+0x40: undefined   d420


Side notes:

To do the lang/gcc6 test I

Re: http://pkg.freebsd.org only has freebsd:11:aarch64:64 for aaarch64? How to boostrap aarch64 pkg for head (12-CURRENT)?

2016-11-07 Thread Mark Millard 
On 2016-Nov-7, at 1:16 PM, Brad Davis  wrote:

> On Mon, Nov 07, 2016 at 12:19:24PM -0800, Mark Millard wrote:
>> It looks like http://pkg.freebsd.org is still back as of head being 
>> 11-CURRENT: http://pkg.freebsd.org shows only
> 
> Correct.  I wrote up some details on how to use the 11 packages here:
> 
> http://www.raspbsd.org/raspberrypi.html
> 
> 
> Regards,
> Brad Davis

Thanks. That helped me get to the next issue to figure out.

I eventually found that https://wiki.freebsd.org/arm64/rpi3 has a "Package 
Repo" section with the alternate ABI information for pkg and also how to get 
port builds going (putting an ld in place) --as if the material was RPI3 
specific. https://wiki.freebsd.org/arm64/rpi3 says:

> There is no package repo for 12-CURRENT, but the package repo for 11 can be 
> used on 12-CURRENT by telling pkg to use the FreeBSD 11 aarch64 ABI: 
> 
> env ABI=FreeBSD:11:aarch64 pkg bootstrap
> 
> Once pkg is bootstrapped, you can add this to /usr/local/etc/pkg.conf: 
> 
> ABI = "FreeBSD:11:aarch64";
> 
> If you want to build your own ports or packages, you'll need to install the 
> aarch64-binutils package and link /usr/bin/ld to 
> /usr/local/bin/aarch64-freebsd-ld: 
> 
> # pkg install aarch64-binutils
> # ln /usr/local/bin/aarch64-freebsd-ld /usr/bin/ld
> 
> Note that if you're building directly on the RPI3, you will definitely want 
> to use either USB storage or NFS. Building on the sdcard will likely wear the 
> sdcard out. 

(I have the root filesystem on a USB SSD.)

My context is a Pine64+ 2GB --which https://wiki.freebsd.org/arm64 does not 
even mention as covered by TARGET_ARCH=aarch64 . But crochet is set up for 
pine64's and uses TARGET_ARCH=aarch64 style builds.


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

___
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

2016-11-07 Thread Justin Hibbits 
On Mon, 7 Nov 2016 20:53:46 -0500
Ryan Stone  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"

Buildworld error with read-only source tree

2016-11-07 Thread Ryan Stone 
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
___
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: DeLock 10x SATA AHCI controller not working properly

2016-11-07 Thread Daniel Engberg 

Hi,

I discussed this card briefly with Alexander Motin (@mav) back in 2015, 
https://forums.freebsd.org/threads/50411/page-2#post-282648 .

I've CCed him for suggestions.

https://lists.freebsd.org/pipermail/freebsd-current/2016-October/063668.html

Best regards,
Daniel
___
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: http://pkg.freebsd.org only has freebsd:11:aarch64:64 for aaarch64? How to boostrap aarch64 pkg for head (12-CURRENT)?

2016-11-07 Thread Brad Davis 
On Mon, Nov 07, 2016 at 12:19:24PM -0800, Mark Millard wrote:
> It looks like http://pkg.freebsd.org is still back as of head being 
> 11-CURRENT: http://pkg.freebsd.org shows only

Correct.  I wrote up some details on how to use the 11 packages here:

http://www.raspbsd.org/raspberrypi.html


Regards,
Brad Davis

___
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: http://pkg.freebsd.org only has freebsd:11:aarch64:64 for aaarch64? How to boostrap aarch64 pkg for head (12-CURRENT)?

2016-11-07 Thread Allan Jude 
On 2016-11-07 15:19, Mark Millard wrote:
> It looks like http://pkg.freebsd.org is still back as of head being 
> 11-CURRENT: http://pkg.freebsd.org shows only
> 
>   • freebsd:11:aarch64:64
> 
> (as http://pkg.freebsd.org/freebsd%3A11%3Aaarch64%3A64 ).
> 
> So on 12-CURRENT pkg bootstrapping gets:
> 
>> # pkg
>> The package management tool is not yet installed on your system.
>> Do you want to fetch and install it now? [y/N]: y
>> Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:12:aarch64/latest, 
>> please wait...
>> pkg: Error fetching 
>> http://pkg.FreeBSD.org/FreeBSD:12:aarch64/latest/Latest/pkg.txz: Not Found
>> A pre-built version of pkg could not be found for your system.
>> Consider changing PACKAGESITE or installing it from ports: 'ports-mgmt/pkg'.
> 
> but ld is also missing at this stage so one cannot link anything --and pkg is 
> not a route to make an ld available.
> 
> So how does one currently bootstrap a 12-CURRENT pkg for aarch64 (context: 
> pine64+ 2GB)?
> 
> Create a /usr/local/etc/pkg/repos/FreeBSD.conf to reference 
> FreeBSD:11:aarch64 ? That just reports the wrong architecture is being 
> attempted:
> 
>> # pkg
>> The package management tool is not yet installed on your system.
>> Do you want to fetch and install it now? [y/N]: y
>> Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:11:aarch64/latest, 
>> please wait...
>> Verifying signature with trusted certificate pkg.freebsd.org.2013102301... 
>> done
>> pkg-static: Warning: Major OS version upgrade detected.  Running "pkg-static 
>> install -f pkg" recommended
>> Installing pkg-1.9.2...
>> pkg-static: wrong architecture: FreeBSD:11:aarch64 instead of 
>> FreeBSD:12:aarch64
>>
>> Failed to install the following 1 package(s): /tmp//pkg.txz.zkdHp2
> 
> 
> pkg-static install -f pkg fetches meta.txz and packagesite.txz first but then 
> also reports "wrong architecture":
> 
>> # pkg-static install -f pkg
>> pkg-static: Warning: Major OS version upgrade detected.  Running "pkg-static 
>> install -f pkg" recommended
>> Updating FreeBSD repository catalogue...
>> Fetching meta.txz: 100%944 B   0.9kB/s00:01
>> Fetching packagesite.txz: 100%4 MiB   4.3MB/s00:01
>> Processing entries:   0%
>> pkg-static: wrong architecture: freebsd:11:aarch64:64 instead of 
>> FreeBSD:12:aarch64
>> pkg-static: repository FreeBSD contains packages with wrong ABI: 
>> freebsd:11:aarch64:64
>> Processing entries: 100%
>> Unable to update repository FreeBSD
>> All repositories are up-to-date.
>> pkg-static: Repository FreeBSD cannot be opened. 'pkg update' required
>> pkg-static: No packages available to install matching 'pkg' have been found 
>> in the repositories
> 
> 
> 
> 
> Context details (was cross built from amd64 head -r308247):
> 
>> # uname -apKU
>> FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r308247M: Thu Nov  3 
>> 07:10:44 PDT 2016 
>> markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm64.aarch64/usr/src/sys/GENERIC-NODBG
>>   arm64 aarch64 1200014 1200014
> 
> 
>> # svnlite info /usr/ports | grep "Re[lv]"
>> Relative URL: ^/head
>> Revision: 424540
>> Last Changed Rev: 424540
> 
> 
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
> ___
> 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"
> 

Until the 12 packages are built, you can cheat:

env ABI=freebsd:11:aarch64:64 pkg bootstrap


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

http://pkg.freebsd.org only has freebsd:11:aarch64:64 for aaarch64? How to boostrap aarch64 pkg for head (12-CURRENT)?

2016-11-07 Thread Mark Millard 
It looks like http://pkg.freebsd.org is still back as of head being 11-CURRENT: 
http://pkg.freebsd.org shows only

• freebsd:11:aarch64:64

(as http://pkg.freebsd.org/freebsd%3A11%3Aaarch64%3A64 ).

So on 12-CURRENT pkg bootstrapping gets:

> # pkg
> The package management tool is not yet installed on your system.
> Do you want to fetch and install it now? [y/N]: y
> Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:12:aarch64/latest, 
> please wait...
> pkg: Error fetching 
> http://pkg.FreeBSD.org/FreeBSD:12:aarch64/latest/Latest/pkg.txz: Not Found
> A pre-built version of pkg could not be found for your system.
> Consider changing PACKAGESITE or installing it from ports: 'ports-mgmt/pkg'.

but ld is also missing at this stage so one cannot link anything --and pkg is 
not a route to make an ld available.

So how does one currently bootstrap a 12-CURRENT pkg for aarch64 (context: 
pine64+ 2GB)?

Create a /usr/local/etc/pkg/repos/FreeBSD.conf to reference FreeBSD:11:aarch64 
? That just reports the wrong architecture is being attempted:

> # pkg
> The package management tool is not yet installed on your system.
> Do you want to fetch and install it now? [y/N]: y
> Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:11:aarch64/latest, 
> please wait...
> Verifying signature with trusted certificate pkg.freebsd.org.2013102301... 
> done
> pkg-static: Warning: Major OS version upgrade detected.  Running "pkg-static 
> install -f pkg" recommended
> Installing pkg-1.9.2...
> pkg-static: wrong architecture: FreeBSD:11:aarch64 instead of 
> FreeBSD:12:aarch64
> 
> Failed to install the following 1 package(s): /tmp//pkg.txz.zkdHp2


pkg-static install -f pkg fetches meta.txz and packagesite.txz first but then 
also reports "wrong architecture":

> # pkg-static install -f pkg
> pkg-static: Warning: Major OS version upgrade detected.  Running "pkg-static 
> install -f pkg" recommended
> Updating FreeBSD repository catalogue...
> Fetching meta.txz: 100%944 B   0.9kB/s00:01
> Fetching packagesite.txz: 100%4 MiB   4.3MB/s00:01
> Processing entries:   0%
> pkg-static: wrong architecture: freebsd:11:aarch64:64 instead of 
> FreeBSD:12:aarch64
> pkg-static: repository FreeBSD contains packages with wrong ABI: 
> freebsd:11:aarch64:64
> Processing entries: 100%
> Unable to update repository FreeBSD
> All repositories are up-to-date.
> pkg-static: Repository FreeBSD cannot be opened. 'pkg update' required
> pkg-static: No packages available to install matching 'pkg' have been found 
> in the repositories




Context details (was cross built from amd64 head -r308247):

> # uname -apKU
> FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r308247M: Thu Nov  3 
> 07:10:44 PDT 2016 
> markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm64.aarch64/usr/src/sys/GENERIC-NODBG
>   arm64 aarch64 1200014 1200014


> # svnlite info /usr/ports | grep "Re[lv]"
> Relative URL: ^/head
> Revision: 424540
> Last Changed Rev: 424540



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

___
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"