hwpmc / amd panic when stopping pmcstat
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
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 = 0x00
Re: DeLock 10x SATA AHCI controller not working properly
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
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
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 adju
Re: http://pkg.freebsd.org only has freebsd:11:aarch64:64 for aaarch64? How to boostrap aarch64 pkg for head (12-CURRENT)?
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
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
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
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)?
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)?
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)?
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"