Re: Unsure about buildworld
On Tue, Jun 20, 2017 at 01:58:58PM -0700, Jeffrey Bouquet wrote: > Used rsync to put /usr/src/.svn to > /usr2/src/.svn [another disk] > did an svn up of that ^^ Is there some reason (e.g., documentation) to believe that will result in a stable and self-consistent checkout? > # sh > export CC=/usr/local/bin/clang39# and the two others I don't think that's the correct variable(s) to set to use an external compiler. > cd /usr2/src > MAKEOBJDIRPREFIX=/usr2/obj -DNO_PROFILE ... buildworld. > > > which halts on some error > ranlib -d ... .a > exec(ranlib) no such file or directory > ... > Is there a more knowledgeable way of putting both src and obj on a seperate > disk > and having the build complete AND > be sure where it builds, [ obj ] and the precise way to test an install [ > pre-rsync to the > production system , so to speak ]or > some other *preferred* way, extract base.txz ... or even a clean > 12.0-CURRENT snapshot > system to rsync onto the present one... Building a release and extracting the tarballs is something that people do, though I don't have any personal experience to recommend it. -Ben > . > My motivation is I do not wish to attempt an svn upgrade of the desktop > without a > certainty that the installworld will complete so the nvidia-driver can more > likely > than not be restored to a working state. > > > ___ > 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" ___ 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 in base/head in abd_put() after r320156
On 2017-06-20 17:45, Trond Endrestøl wrote: > On Tue, 20 Jun 2017 17:31-0400, Allan Jude wrote: > >> On 2017-06-20 17:27, Trond Endrestøl wrote: >>> Has anyone else seen a crash in base/head in abd_put() after r320156? >>> >>> One of my experimental VMs at home crashed spectacularly after >>> upgrading to r320156. I even wiped my /usr/obj, recompiled everything >>> and got the same result. Everything's back to normal when I boot >>> r320146. >>> >>> Here's the backtrace: >>> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 3; apic id = 03 >>> >>> fault virtual address = 0x8 >>> >>> Fatal trap 12: page fault while in kernel mode >>> >>> cpuid = 2; >>> Fatal trap 12: page fault while in kernel mode >>> apic id = 02 >>> fault virtual address = 0x8 >>> cpuid = 0; apic id = 00 >>> fault virtual address = 0x8 >>> fault code = supervisor read data, page not present >>> fault code = supervisor read data, page not present >>> instruction pointer = 0x20:0x803260fa >>> stack pointer = 0x28:0xfe01b0231860 >>> frame pointer = 0x28:0xfe01b0231870 >>> code segment= base 0x0, limit 0xf, type 0x1b >>> >>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>> >>> Fatal trap 12: page fault while in kernel mode >>> fault code = supervisor read data, page not present >>> processor eflags= interrupt enabled, resume, IOPL = 0 >>> current process = 0 (zio_free_issue_5_2) >>> trap number = 12 >>> instruction pointer = 0x20:0x803260fa >>> stack pointer = 0x28:0xfe01b022c860 >>> frame pointer = 0x28:0xfe01b022c870 >>> panic: page fault >>> cpuid = 0 >>> time = 4 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at 0x8044f93b = >>> db_trace_self_wrapper+0x2b/frame 0xfe01b0231440 >>> vpanic() at 0x8067ec0c = vpanic+0x19c/frame 0xfe01b02314c0 >>> panic() at 0x8067ea63 = panic+0x43/frame 0xfe01b0231520 >>> trap_fatal() at 0x80983b32 = trap_fatal+0x322/frame >>> 0xfe01b0231570 >>> trap_pfault() at 0x80983b89 = trap_pfault+0x49/frame >>> 0xfe01b02315d0 >>> trap() at 0x809833c5 = trap+0x295/frame 0xfe01b0231790 >>> calltrap() at 0x80968c21 = calltrap+0x8/frame 0xfe01b0231790 >>> --- trap 0xc, rip = 0x803260fa, rsp = 0xfe01b0231860, rbp = >>> 0xfe01b0231870 --- >>> abd_put() at 0x803260fa = abd_put+0xa/frame 0xfe01b0231870 >>> vdev_raidz_map_free() at 0x803aa7c2 = >>> vdev_raidz_map_free+0x82/frame 0xfe01b02318a0 >>> zio_vdev_io_assess() at 0x803ecc04 = zio_vdev_io_assess+0x74/frame >>> 0xfe01b02318e0 >>> zio_execute() at 0x803e913c = zio_execute+0xac/frame >>> 0xfe01b0231930 >>> zio_vdev_io_start() at 0x803ec894 = zio_vdev_io_start+0x2b4/frame >>> 0xfe01b0231990 >>> zio_execute() at 0x803e913c = zio_execute+0xac/frame >>> 0xfe01b02319e0 >>> zio_nowait() at 0x803e8a8b = zio_nowait+0xcb/frame >>> 0xfe01b0231a20 >>> vdev_mirror_io_start() at 0x803a744c = >>> vdev_mirror_io_start+0x35c/frame 0xfe01b0231a70 >>> zio_vdev_io_start() at 0x803ec86c = zio_vdev_io_start+0x28c/frame >>> 0xfe01b0231ad0 >>> zio_execute() at 0x803e913c = zio_execute+0xac/frame >>> 0xfe01b0231b20 >>> taskqueue_run_locked() at 0x806d3d27 = >>> taskqueue_run_locked+0x127/frame 0xfe01b0231b80 >>> taskqueue_thread_loop() at 0x806d4ee8 = >>> taskqueue_thread_loop+0xc8/frame 0xfe01b0231bb0 >>> fork_exit() at 0x80640df5 = fork_exit+0x85/frame 0xfe01b0231bf0 >>> fork_trampoline() at 0x8096915e = fork_trampoline+0xe/frame >>> 0xfe01b0231bf0 >>> --- trap 0, rip = 0, rsp = 0, rbp = 0 --- >>> Uptime: 4s >>> >> >> This seems to be an unintended consequence of some code that was pulled >> in from upstream today. >> >> Try adding: vfs.zfs.trim.enabled=0 >> to /boot/loader.conf >> >> (you can set it manually from the boot loader menu with the set command >> to get the system to boot) > > That worked. Thanks. > > BTW, the call to abd_put() was given a NULL pointer. > Yeah, if you want more detail, there is a thread on svn-src-h...@freebsd.org that discusses it. Should be fixed tomorrow. -- Allan Jude ___ 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 in base/head in abd_put() after r320156
On Tue, 20 Jun 2017 17:31-0400, Allan Jude wrote: > On 2017-06-20 17:27, Trond Endrestøl wrote: > > Has anyone else seen a crash in base/head in abd_put() after r320156? > > > > One of my experimental VMs at home crashed spectacularly after > > upgrading to r320156. I even wiped my /usr/obj, recompiled everything > > and got the same result. Everything's back to normal when I boot > > r320146. > > > > Here's the backtrace: > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 3; apic id = 03 > > > > fault virtual address = 0x8 > > > > Fatal trap 12: page fault while in kernel mode > > > > cpuid = 2; > > Fatal trap 12: page fault while in kernel mode > > apic id = 02 > > fault virtual address = 0x8 > > cpuid = 0; apic id = 00 > > fault virtual address = 0x8 > > fault code = supervisor read data, page not present > > fault code = supervisor read data, page not present > > instruction pointer = 0x20:0x803260fa > > stack pointer = 0x28:0xfe01b0231860 > > frame pointer = 0x28:0xfe01b0231870 > > code segment= base 0x0, limit 0xf, type 0x1b > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > Fatal trap 12: page fault while in kernel mode > > fault code = supervisor read data, page not present > > processor eflags= interrupt enabled, resume, IOPL = 0 > > current process = 0 (zio_free_issue_5_2) > > trap number = 12 > > instruction pointer = 0x20:0x803260fa > > stack pointer = 0x28:0xfe01b022c860 > > frame pointer = 0x28:0xfe01b022c870 > > panic: page fault > > cpuid = 0 > > time = 4 > > KDB: stack backtrace: > > db_trace_self_wrapper() at 0x8044f93b = > > db_trace_self_wrapper+0x2b/frame 0xfe01b0231440 > > vpanic() at 0x8067ec0c = vpanic+0x19c/frame 0xfe01b02314c0 > > panic() at 0x8067ea63 = panic+0x43/frame 0xfe01b0231520 > > trap_fatal() at 0x80983b32 = trap_fatal+0x322/frame > > 0xfe01b0231570 > > trap_pfault() at 0x80983b89 = trap_pfault+0x49/frame > > 0xfe01b02315d0 > > trap() at 0x809833c5 = trap+0x295/frame 0xfe01b0231790 > > calltrap() at 0x80968c21 = calltrap+0x8/frame 0xfe01b0231790 > > --- trap 0xc, rip = 0x803260fa, rsp = 0xfe01b0231860, rbp = > > 0xfe01b0231870 --- > > abd_put() at 0x803260fa = abd_put+0xa/frame 0xfe01b0231870 > > vdev_raidz_map_free() at 0x803aa7c2 = > > vdev_raidz_map_free+0x82/frame 0xfe01b02318a0 > > zio_vdev_io_assess() at 0x803ecc04 = zio_vdev_io_assess+0x74/frame > > 0xfe01b02318e0 > > zio_execute() at 0x803e913c = zio_execute+0xac/frame > > 0xfe01b0231930 > > zio_vdev_io_start() at 0x803ec894 = zio_vdev_io_start+0x2b4/frame > > 0xfe01b0231990 > > zio_execute() at 0x803e913c = zio_execute+0xac/frame > > 0xfe01b02319e0 > > zio_nowait() at 0x803e8a8b = zio_nowait+0xcb/frame > > 0xfe01b0231a20 > > vdev_mirror_io_start() at 0x803a744c = > > vdev_mirror_io_start+0x35c/frame 0xfe01b0231a70 > > zio_vdev_io_start() at 0x803ec86c = zio_vdev_io_start+0x28c/frame > > 0xfe01b0231ad0 > > zio_execute() at 0x803e913c = zio_execute+0xac/frame > > 0xfe01b0231b20 > > taskqueue_run_locked() at 0x806d3d27 = > > taskqueue_run_locked+0x127/frame 0xfe01b0231b80 > > taskqueue_thread_loop() at 0x806d4ee8 = > > taskqueue_thread_loop+0xc8/frame 0xfe01b0231bb0 > > fork_exit() at 0x80640df5 = fork_exit+0x85/frame 0xfe01b0231bf0 > > fork_trampoline() at 0x8096915e = fork_trampoline+0xe/frame > > 0xfe01b0231bf0 > > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > > Uptime: 4s > > > > This seems to be an unintended consequence of some code that was pulled > in from upstream today. > > Try adding: vfs.zfs.trim.enabled=0 > to /boot/loader.conf > > (you can set it manually from the boot loader menu with the set command > to get the system to boot) That worked. Thanks. BTW, the call to abd_put() was given a NULL pointer. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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 in base/head in abd_put() after r320156
On 2017-06-20 17:27, Trond Endrestøl wrote: > Has anyone else seen a crash in base/head in abd_put() after r320156? > > One of my experimental VMs at home crashed spectacularly after > upgrading to r320156. I even wiped my /usr/obj, recompiled everything > and got the same result. Everything's back to normal when I boot > r320146. > > Here's the backtrace: > > Fatal trap 12: page fault while in kernel mode > cpuid = 3; apic id = 03 > > fault virtual address = 0x8 > > Fatal trap 12: page fault while in kernel mode > > cpuid = 2; > Fatal trap 12: page fault while in kernel mode > apic id = 02 > fault virtual address = 0x8 > cpuid = 0; apic id = 00 > fault virtual address = 0x8 > fault code= supervisor read data, page not present > fault code= supervisor read data, page not present > instruction pointer = 0x20:0x803260fa > stack pointer = 0x28:0xfe01b0231860 > frame pointer = 0x28:0xfe01b0231870 > code segment = base 0x0, limit 0xf, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > Fatal trap 12: page fault while in kernel mode > fault code= supervisor read data, page not present > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (zio_free_issue_5_2) > trap number = 12 > instruction pointer = 0x20:0x803260fa > stack pointer = 0x28:0xfe01b022c860 > frame pointer = 0x28:0xfe01b022c870 > panic: page fault > cpuid = 0 > time = 4 > KDB: stack backtrace: > db_trace_self_wrapper() at 0x8044f93b = > db_trace_self_wrapper+0x2b/frame 0xfe01b0231440 > vpanic() at 0x8067ec0c = vpanic+0x19c/frame 0xfe01b02314c0 > panic() at 0x8067ea63 = panic+0x43/frame 0xfe01b0231520 > trap_fatal() at 0x80983b32 = trap_fatal+0x322/frame 0xfe01b0231570 > trap_pfault() at 0x80983b89 = trap_pfault+0x49/frame > 0xfe01b02315d0 > trap() at 0x809833c5 = trap+0x295/frame 0xfe01b0231790 > calltrap() at 0x80968c21 = calltrap+0x8/frame 0xfe01b0231790 > --- trap 0xc, rip = 0x803260fa, rsp = 0xfe01b0231860, rbp = > 0xfe01b0231870 --- > abd_put() at 0x803260fa = abd_put+0xa/frame 0xfe01b0231870 > vdev_raidz_map_free() at 0x803aa7c2 = vdev_raidz_map_free+0x82/frame > 0xfe01b02318a0 > zio_vdev_io_assess() at 0x803ecc04 = zio_vdev_io_assess+0x74/frame > 0xfe01b02318e0 > zio_execute() at 0x803e913c = zio_execute+0xac/frame > 0xfe01b0231930 > zio_vdev_io_start() at 0x803ec894 = zio_vdev_io_start+0x2b4/frame > 0xfe01b0231990 > zio_execute() at 0x803e913c = zio_execute+0xac/frame > 0xfe01b02319e0 > zio_nowait() at 0x803e8a8b = zio_nowait+0xcb/frame 0xfe01b0231a20 > vdev_mirror_io_start() at 0x803a744c = > vdev_mirror_io_start+0x35c/frame 0xfe01b0231a70 > zio_vdev_io_start() at 0x803ec86c = zio_vdev_io_start+0x28c/frame > 0xfe01b0231ad0 > zio_execute() at 0x803e913c = zio_execute+0xac/frame > 0xfe01b0231b20 > taskqueue_run_locked() at 0x806d3d27 = > taskqueue_run_locked+0x127/frame 0xfe01b0231b80 > taskqueue_thread_loop() at 0x806d4ee8 = > taskqueue_thread_loop+0xc8/frame 0xfe01b0231bb0 > fork_exit() at 0x80640df5 = fork_exit+0x85/frame 0xfe01b0231bf0 > fork_trampoline() at 0x8096915e = fork_trampoline+0xe/frame > 0xfe01b0231bf0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > Uptime: 4s > This seems to be an unintended consequence of some code that was pulled in from upstream today. Try adding: vfs.zfs.trim.enabled=0 to /boot/loader.conf (you can set it manually from the boot loader menu with the set command to get the system to boot) -- Allan Jude signature.asc Description: OpenPGP digital signature
Crash in base/head in abd_put() after r320156
Has anyone else seen a crash in base/head in abd_put() after r320156? One of my experimental VMs at home crashed spectacularly after upgrading to r320156. I even wiped my /usr/obj, recompiled everything and got the same result. Everything's back to normal when I boot r320146. Here's the backtrace: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x8 Fatal trap 12: page fault while in kernel mode cpuid = 2; Fatal trap 12: page fault while in kernel mode apic id = 02 fault virtual address = 0x8 cpuid = 0; apic id = 00 fault virtual address = 0x8 fault code = supervisor read data, page not present fault code = supervisor read data, page not present instruction pointer = 0x20:0x803260fa stack pointer = 0x28:0xfe01b0231860 frame pointer = 0x28:0xfe01b0231870 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 Fatal trap 12: page fault while in kernel mode fault code = supervisor read data, page not present processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (zio_free_issue_5_2) trap number = 12 instruction pointer = 0x20:0x803260fa stack pointer = 0x28:0xfe01b022c860 frame pointer = 0x28:0xfe01b022c870 panic: page fault cpuid = 0 time = 4 KDB: stack backtrace: db_trace_self_wrapper() at 0x8044f93b = db_trace_self_wrapper+0x2b/frame 0xfe01b0231440 vpanic() at 0x8067ec0c = vpanic+0x19c/frame 0xfe01b02314c0 panic() at 0x8067ea63 = panic+0x43/frame 0xfe01b0231520 trap_fatal() at 0x80983b32 = trap_fatal+0x322/frame 0xfe01b0231570 trap_pfault() at 0x80983b89 = trap_pfault+0x49/frame 0xfe01b02315d0 trap() at 0x809833c5 = trap+0x295/frame 0xfe01b0231790 calltrap() at 0x80968c21 = calltrap+0x8/frame 0xfe01b0231790 --- trap 0xc, rip = 0x803260fa, rsp = 0xfe01b0231860, rbp = 0xfe01b0231870 --- abd_put() at 0x803260fa = abd_put+0xa/frame 0xfe01b0231870 vdev_raidz_map_free() at 0x803aa7c2 = vdev_raidz_map_free+0x82/frame 0xfe01b02318a0 zio_vdev_io_assess() at 0x803ecc04 = zio_vdev_io_assess+0x74/frame 0xfe01b02318e0 zio_execute() at 0x803e913c = zio_execute+0xac/frame 0xfe01b0231930 zio_vdev_io_start() at 0x803ec894 = zio_vdev_io_start+0x2b4/frame 0xfe01b0231990 zio_execute() at 0x803e913c = zio_execute+0xac/frame 0xfe01b02319e0 zio_nowait() at 0x803e8a8b = zio_nowait+0xcb/frame 0xfe01b0231a20 vdev_mirror_io_start() at 0x803a744c = vdev_mirror_io_start+0x35c/frame 0xfe01b0231a70 zio_vdev_io_start() at 0x803ec86c = zio_vdev_io_start+0x28c/frame 0xfe01b0231ad0 zio_execute() at 0x803e913c = zio_execute+0xac/frame 0xfe01b0231b20 taskqueue_run_locked() at 0x806d3d27 = taskqueue_run_locked+0x127/frame 0xfe01b0231b80 taskqueue_thread_loop() at 0x806d4ee8 = taskqueue_thread_loop+0xc8/frame 0xfe01b0231bb0 fork_exit() at 0x80640df5 = fork_exit+0x85/frame 0xfe01b0231bf0 fork_trampoline() at 0x8096915e = fork_trampoline+0xe/frame 0xfe01b0231bf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- Uptime: 4s -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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"
Unsure about buildworld
Used rsync to put /usr/src/.svn to /usr2/src/.svn [another disk] did an svn up of that ^^ # sh export CC=/usr/local/bin/clang39# and the two others cd /usr2/src MAKEOBJDIRPREFIX=/usr2/obj -DNO_PROFILE ... buildworld. which halts on some error ranlib -d ... .a exec(ranlib) no such file or directory ... Is there a more knowledgeable way of putting both src and obj on a seperate disk and having the build complete AND be sure where it builds, [ obj ] and the precise way to test an install [ pre-rsync to the production system , so to speak ]or some other *preferred* way, extract base.txz ... or even a clean 12.0-CURRENT snapshot system to rsync onto the present one... . My motivation is I do not wish to attempt an svn upgrade of the desktop without a certainty that the installworld will complete so the nvidia-driver can more likely than not be restored to a working state. ___ 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"
