Re: Has gdb been disconnected from make installworld?
On Sun, 25 Jun 2017 14:07-0500, Benjamin Kaduk wrote: > On Sun, Jun 25, 2017 at 09:03:58PM +0200, Trond Endrestøl wrote: > > > Ah, they wound up in /usr/libexec. Still, that's an odd place for user > > software. > > --- > r317416 | jhb | 2017-04-25 13:08:56 -0500 (Tue, 25 Apr 2017) | 16 lines > > Add a new GDB_LIBEXEC option to install gdb and kgdb to /usr/libexec. > > When this option is enabled, only gdb and kgdb are installed to > /usr/libexec for use by crashinfo(8). Other bits of GDB such as > gdbserver and gdbtui are not installed. For this option to be > effective, GDB must be enabled. > > Rework r317094 to re-enable GDB on all platforms but enable > GDB_LIBEXEC on platforms for which the GDB in ports is a superset of > functionality. > > Reviewed by:emaste, kib > Suggested by: kib > Relnotes: yes > Differential Revision: https://reviews.freebsd.org/D10449 > --- > > > Note specifically that the GDB in ports is a substantial improvement in > functionality on amd64. > > -Ben Good to know. Thanks. -- +---++ | 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: ZFS ABD Panic
On Monday, June 26, 2017, Shawn Webb wrote: > This is on the latest HardenedBSD 12-CURRENT on one of my servers: > > [141] panic: sleepq_add: td 0xf80008d20560 to sleep on wchan > 0xf803b7d4e810 with sleeping prohibited > [141] cpuid = 5 > [141] time = 1498436043 > [141] KDB: stack backtrace: > [141] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfe2fc8b0 > [141] vpanic() at vpanic+0x19c/frame 0xfe2fc930 > [141] kassert_panic() at kassert_panic+0x126/frame 0xfe2fc9a0 > [141] sleepq_add() at sleepq_add+0x34f/frame 0xfe2fc9f0 > [141] _sx_xlock_hard() at _sx_xlock_hard+0x2a4/frame 0xfe2fcaa0 > [141] _sx_xlock() at _sx_xlock+0x98/frame 0xfe2fcae0 > [141] refcount_remove_many() at refcount_remove_many+0x2a/frame > 0xfe2fcb20 > [141] abd_return_buf() at abd_return_buf+0xe3/frame 0xfe2fcb50 > [141] vdev_geom_io_intr() at vdev_geom_io_intr+0x114/frame > 0xfe2fcb70 > [141] g_io_schedule_up() at g_io_schedule_up+0x42/frame 0xfe2fcba0 > [141] g_up_procbody() at g_up_procbody+0x6d/frame 0xfe2fcbb0 > [141] fork_exit() at fork_exit+0x84/frame 0xfe2fcbf0 > [141] fork_trampoline() at fork_trampoline+0xe/frame 0xfe2fcbf0 > > pool: rpool > state: ONLINE > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > rpoolONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > mfid0p3 ONLINE 0 0 0 > mfid1p3 ONLINE 0 0 0 > mirror-1 ONLINE 0 0 0 > mfid2ONLINE 0 0 0 > mfid3ONLINE 0 0 0 > > errors: No known data errors What's the corresponding git note? > > Thanks, > > -- > Shawn Webb > Cofounder and Security Engineer > HardenedBSD > > GPG Key ID: 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE > ___ 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"
r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'
Over the past week we did not update several 12-CURRENT running development hosts, so today is the first day of performing this task. First I hit the very same problem David Wolfskill reported earlier, a fatal trap 12, but fowllowing the thread, I did as advised: removing /usr/obj completely (we use filemon/WITH_META_MODE=YES all over the place) and recompiling world and kernel. Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and the INO64 update hasn't performed so far starting from r319971, I installed the kernel, rebooted the box in single user mode (this time smoothly), did a mergemaster and tried to do "make installworld" - but the box instantanously bails out: [...] Fatal error 'Cannot allocate red zone for initial thread' at line 392 in file /usr/src/lib/libthread/thr_init.c pid 60 (cc) uid0: exited on signal 6 ... [...] That way, I obviously can not install a world :-( What is wrong here? Is the problem resovable? Kind regards, Oliver ___ 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: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'
Is this related to kib's additional fix over the weekend? https://svnweb.freebsd.org/changeset/base/320344 Regards Steve On 26/06/2017 09:29, O. Hartmann wrote: Over the past week we did not update several 12-CURRENT running development hosts, so today is the first day of performing this task. First I hit the very same problem David Wolfskill reported earlier, a fatal trap 12, but fowllowing the thread, I did as advised: removing /usr/obj completely (we use filemon/WITH_META_MODE=YES all over the place) and recompiling world and kernel. Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and the INO64 update hasn't performed so far starting from r319971, I installed the kernel, rebooted the box in single user mode (this time smoothly), did a mergemaster and tried to do "make installworld" - but the box instantanously bails out: [...] Fatal error 'Cannot allocate red zone for initial thread' at line 392 in file /usr/src/lib/libthread/thr_init.c pid 60 (cc) uid0: exited on signal 6 ... [...] That way, I obviously can not install a world :-( What is wrong here? Is the problem resovable? Kind regards, Oliver ___ 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: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'
On Mon, 26 Jun 2017 10:29:47 +0200 "O. Hartmann" wrote: > Over the past week we did not update several 12-CURRENT running development > hosts, so today is the first day of performing this task. > > First I hit the very same problem David Wolfskill reported earlier, a fatal > trap 12, but fowllowing the thread, I did as advised: removing /usr/obj > completely (we use filemon/WITH_META_MODE=YES all over the place) and > recompiling world and kernel. > > Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and the > INO64 update hasn't performed so far starting from r319971, I installed the > kernel, rebooted the box in single user mode (this time smoothly), did a > mergemaster and tried to do "make installworld" - but the box instantanously > bails out: > > [...] > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in > file /usr/src/lib/libthread/thr_init.c > pid 60 (cc) uid0: exited on signal 6 ... > > [...] > > That way, I obviously can not install a world :-( > > What is wrong here? Is the problem resovable? > How recent was your last update? Some changes were made just a few hours ago to fix a stack growth problem in threads. Either your source is not up to date, or a new bug was introduced by the intended fix. -- Gary Jennejohn ___ 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: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'
On Mon, 26 Jun 2017 12:22+0100, Steven Hartland wrote: > Is this related to kib's additional fix over the weekend? > > https://svnweb.freebsd.org/changeset/base/320344 Attempting to run r320348 with no patches applied proved unfruitful earlier today. I had partial success the weekend building r320328 with the vm2.2.patch applied while running r320293. https://people.freebsd.org/~kib/misc/vm2.2.patch You might want to stay at pre-r320316 until the matter is resolved. > Regards > Steve > > On 26/06/2017 09:29, O. Hartmann wrote: > > Over the past week we did not update several 12-CURRENT running development > > hosts, so today is the first day of performing this task. > > > > First I hit the very same problem David Wolfskill reported earlier, a fatal > > trap 12, but fowllowing the thread, I did as advised: removing /usr/obj > > completely (we use filemon/WITH_META_MODE=YES all over the place) and > > recompiling world and kernel. > > > > Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and the > > INO64 update hasn't performed so far starting from r319971, I installed the > > kernel, rebooted the box in single user mode (this time smoothly), did a > > mergemaster and tried to do "make installworld" - but the box instantanously > > bails out: > > > > [...] > > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in > > file /usr/src/lib/libthread/thr_init.c > > pid 60 (cc) uid0: exited on signal 6 ... > > > > [...] > > > > That way, I obviously can not install a world :-( > > > > What is wrong here? Is the problem resovable? > > > > Kind regards, > > > > Oliver -- Trond. ___ 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: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'
On Mon, Jun 26, 2017 at 10:29:47AM +0200, O. Hartmann wrote: > ... > Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and the > INO64 update hasn't performed so far starting from r319971, I installed the > kernel, rebooted the box in single user mode (this time smoothly), did a > mergemaster and tried to do "make installworld" - but the box instantanously > bails out: > > [...] > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in > file /usr/src/lib/libthread/thr_init.c > pid 60 (cc) uid0: exited on signal 6 ... My head update this morning was from r320324 to r320353; I did not encounter the above. (I did, however, encounter an inability to load tmpfs.ko; I will describe that issue in a separate thread.) > ... Peace, david -- David H. Wolfskill da...@catwhisker.org Trump (et al.): Hiding information doesn't prove its falsity. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: [RESOLVED] Failover Mode Between Ethernet and Wireless Interfaces broken on >= 11
On 26/06/17 00:59, Benjamin Kaduk wrote: > On Fri, Jun 23, 2017 at 11:22:46PM -0500, Benjamin Kaduk wrote: >> I fixed the rc.conf snippet in the handbook in r50399. >> I lost track of the rest of the thread as to what needs to be >> changed in the actual command examples in lagg.4 and/or the >> handbook, though. > > To be clear, that is: one of you please supply the correct commands > to execute this configuration manually (i.e., not via rc.conf), or the > rest of the documentation is unlikely to get updated. On lagg(4): # ifconfig em0 up # ifconfig create wlan0 wlandev ath0 ssid my_net \ wlanaddr 00:11:22:33:44:55 up # ifconfig lagg0 create # ifconfig lagg0 laggproto failover laggport em0 laggport wlan0 \ 192.168.1.1 netmask 255.255.255.0 On Handbook [1]: Following line should be removed: # ifconfig iwn0 ether 00:21:70:da:ae:37 And the next example command should be changed to: # ifconfig wlan0 create wlandev iwn0 ssid my_router \ wlanaddr 00:21:70:da:ae:37 up The rc.conf block looks fine. Thank you for taking care of it. [1] https://www.freebsd.org/doc/handbook/network-aggregation.html#networking-lagg-wired-and-wireless -- Renato Botelho ___ 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: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'
On Mon, Jun 26, 2017 at 10:29:47AM +0200, O. Hartmann wrote: > Over the past week we did not update several 12-CURRENT running development > hosts, so today is the first day of performing this task. > > First I hit the very same problem David Wolfskill reported earlier, a fatal > trap 12, but fowllowing the thread, I did as advised: removing /usr/obj > completely (we use filemon/WITH_META_MODE=YES all over the place) and > recompiling world and kernel. > > Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and the > INO64 update hasn't performed so far starting from r319971, I installed the > kernel, rebooted the box in single user mode (this time smoothly), did a > mergemaster and tried to do "make installworld" - but the box instantanously > bails out: > > [...] > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in > file /usr/src/lib/libthread/thr_init.c > pid 60 (cc) uid0: exited on signal 6 ... It is strange that cc is executed during installworld. Anyway, show ktrace of the failure. ___ 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"
Unable to load kernel modules after r320324 -> r320353: "depends on kernel - not available or version mismatch"
This is amd64: FreeBSD 12.0-CURRENT #386 r320324M/320326:1200035: Sun Jun 25 06:36:19 PDT 2017 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 After a src update to r320353, the last several lines on the serial console from the initial (verbose) reboot are: ... random: harvesting attach, 8 bytes (4 bits) from ukbd0 KLD geom_eli.ko: depends on kernel - not available0010-89d5-003048 or version mismatch linker_load_file: /boot/kernel/geom_eli.ko - unsupported file type 2d326a. SettingGEOM_PART: partition 1 on (diskid/DISK-1350095E5057, MBR) is not aligned on 4096 bytes GEOM_PART: partition 2 on (diskid/DISK-1350095E5057, MBR) is not aligned on 4096 bytes uhub3: 6 ports with 6 removable, self powered GEOM_PART: partition 3 on (diskid/DISK-1350095E5057, MBR) is not aligned on 4096 bytes random: harvesting attach, 8 bytes (4 bits) from uhub3 hostid: 0xc7455GEOM_PART: partition 1 on (diskid/DISK-1350095E5057, MBR) is not aligned on 4096 bytes 1dd. No suitablGEOM_PART: partition 2 on (diskid/DISK-1350095E5057, MBR) is not aligned on 4096 bytes uhub4: 8 ports with 8 removable, self powered GEOM_PART: partition 3 on (diskid/DISK-1350095E5057, MBR) is not aligned on 4096 bytes random: harvesting attach, 8 bytes (4 bits) from uhub4 e dump device waGEOM_PART: partition 1 on (diskid/DISK-1350095E5057, MBR) is not aligned on 4096 bytes GEOM_PART: partition 2 on (diskid/DISK-1350095E5057, MBR) is not aligned on 4096 bytes GEOM_PART: partition 3 on (diskid/DISK-1350095E5057, MBR) is not aligned on 4096 bytes ugen0.3: at usbus0 umass0 on uhub2 s found. Startiumass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4000 ng file system cumass0:6:0: Attached to scbus6 (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? random: harvesting attach, 8 bytes (4 bits) from umass0 pass6 at umass-sim0 bus 0 scbus6 target 0 lun 0 hecks: /dev/adapass6: 0s4a: FILE SYSTE Removable Direct AM CLEAN; SKIPPINcG CHECKS /dev/acess SCSI device pass6: Serial Number 2010081884130 pass6: 40.000MB/s transfers GEOM_PART: partition 1 on (diskid/DISK-1350095E5057, MBR) is not aligned on 4096 bytes da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 da0: Removable Direct Access SCSI device da0: Serial Number 2010081884130 da0: 40.000MB/s transfers da0: Attempt to qda0s4a: clean, 6uery device size failed: NOT READY, Medium not present da0: quirks=0x2 (probe0:umass-sim0:0:0:1): Down reving Protocol Version from 2 to 0? da016774 free (3814: Delete methods: GEOM_PART: partition 2 on (diskid/DISK-1350095E5057, MBR) is not aligned on 4096 bytes pass7 at umass-sim0 bus 0 scbus6 target 0 lun 1 GEOM_PART: partition 3 on (diskid/DISK-1350095E5057, MBR) is not aligned on 4096 bytes ugen0.4: at usbus0 pass7: Removable Direct Access frags, 76620 bl SCSI docks, 0.5% fragmevice pass7: Serial Number 2010081884130 pass7: 40.000MB/s transfers entation) /dev/GEOM: new disk da0 (probe0:umass-sim0:0:0:2): Down reving Protocol Version from 2 to 0? da1 at umass-sim0 bus 0 scbus6 target 0 lun 1 da1: Removable Direct Access SCSI device da1: Serial Number 2010081ada0s1a: FILE SY88413000STEM CLEAN; SKIP00PING CHECKS /de da1: 40.000MB/s transfers da1: Attempt to query device v/ada0s1a: cleansize failed: NOT RE, 607665 free (1ADY, Medium not present da1: quirks=0x2 GEOM: new disk da1 da1: Delete825 frags, 75730 methods: p blocks, 0.2% frass8 at umass-sim0 bus 0 scbus6 target 0 lun 2 pass8: Removable Direct Access SCSI device pass8: Serial Number 2010081884130 pass8: agmentation) /d40.000MB/s transfers da2 at umass-sim0 bus 0 scbus6 target 0 lun 2 da2: Removable Direct Access SCSI device da2: Serial Number 2010081884130 da2: 40.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not presev/ada0s1d: FILEent da2: quirks=0x2 da2: Delete methods: (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL not supported. (probe0:umass-sim0:0:0:3): Down reving Protocol Version from 2 to 0? KIPPING CHECKS pass9 at umass-sim0 bus 0 scbus6 target 0 lun 3 pass9: Removable Direct Access SCSI device pass9: Serial Number 2010081884130 pass9: 40.000MB/s transfers da3 at umass-sim0 bus 0 scbus6 target 0 lun 3 da3: Removable Direct Access SCSI device da3: Serial Numb/dev/ada0s1d: cler 2010081884130 da3: 40.000MB/s transfers da3: Attempt toean, 594513 free (56257 frags, 6query device size failed: NOT READY, Medium not present da3: quirks=0x2 da3: Dele7282 blocks, 2.5te methods: (da1:uma% fragmentation)ss-sim0:0:0:1): PREVENT ALLOW MEDIUM REMOVAL no /dev/ada0s2a: t supported. FILE SYSTEM CLEAGEOM: new disk da2 GEOM: new disk da3 (da2:umass-sim0:0:0:2): PREVENT ALLOW MEDIUM REMOVAL not supported. N; SKIPPING CHEC(da3:umass-sim0:0:0:3): PREVENT ALLOW MEDIUMKS /dev/ada0s2a REMOVAL not supported. : clean, 607665 GEOM_PART: partition 1 on (diskid/DISK-1350095E5057, MBR) is not aligned on 4096 bytes GEOM_PART: partitfree (233 frags,ion 2 on (diskid/DISK-1350095E5057, MBR) is not
Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'
On Mon, 26 Jun 2017 13:26:08 +0200 Gary Jennejohn wrote: > On Mon, 26 Jun 2017 10:29:47 +0200 > "O. Hartmann" wrote: > > > Over the past week we did not update several 12-CURRENT running development > > hosts, so today is the first day of performing this task. > > > > First I hit the very same problem David Wolfskill reported earlier, a fatal > > trap 12, but fowllowing the thread, I did as advised: removing /usr/obj > > completely (we use filemon/WITH_META_MODE=YES all over the place) and > > recompiling world and kernel. > > > > Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and the > > INO64 update hasn't performed so far starting from r319971, I installed the > > kernel, rebooted the box in single user mode (this time smoothly), did a > > mergemaster and tried to do "make installworld" - but the box instantanously > > bails out: > > > > [...] > > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in > > file /usr/src/lib/libthread/thr_init.c > > pid 60 (cc) uid0: exited on signal 6 ... > > > > [...] > > > > That way, I obviously can not install a world :-( > > > > What is wrong here? Is the problem resovable? > > > > How recent was your last update? Some changes were made just a few > hours ago to fix a stack growth problem in threads. Well, what do you mean by "... source is not up to date ..."? Performing an svn update of /usr/src should suffice, shouldn't it? If not, then ... please correct me. I think the sources are up to date as of the moment the bug occured. I consider the sources up to date, it is on the latest updated box r320355. There are so far two variations: one is r319971 -> 320351 as the subject indicates, the second box is r320144 -> 320355. > > Either your source is not up to date, or a new bug was introduced by > the intended fix. > As described earlier, I ran into a coredump by not having built world and kernel from scratch but with filemon. That was r320251. Cleaning (deleting) /usr/obj/* and rebuilding world and kernel and performing the update of the system as required (install the new kernel, boot the new kernel in single user mode) succeeded, but installworld then failed. ___ 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: Unable to load kernel modules after r320324 -> r320353: "depends on kernel - not available or version mismatch"
On Mon, Jun 26, 2017 at 04:54:36AM -0700, David Wolfskill wrote: > KLD geom_eli.ko: depends on kernel - not available or version mismatch > linker_load_file: /boot/kernel/geom_eli.ko - unsupported file type > swapon: /dev/ada0s4b.eli: Invalid parameters Again remove all kernel build files and try fresh build. ___ 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: Unable to load kernel modules after r320324 -> r320353: "depends on kernel - not available or version mismatch"
On Mon, Jun 26, 2017 at 03:05:58PM +0300, Konstantin Belousov wrote:
> On Mon, Jun 26, 2017 at 04:54:36AM -0700, David Wolfskill wrote:
> > KLD geom_eli.ko: depends on kernel - not available or version mismatch
> > linker_load_file: /boot/kernel/geom_eli.ko - unsupported file type
> > swapon: /dev/ada0s4b.eli: Invalid parameters
>
> Again remove all kernel build files and try fresh build.
OK; after clearing /usr/obj/usr/src/sys/GENERIC, then rebuilding the
kernel ("make -j16 buildkernel && ... && make installkernel") &
rebooting no longer whines about the kmods, and kldstat says:
freebeast(12.0-C)[2] kldstat
Id Refs AddressSize Name
1 25 0x8020 2081550 kernel
21 0x82283000 a128 filemon.ko
31 0x82421000 11376geom_eli.ko
41 0x82433000 fde7 tmpfs.ko
51 0x82443000 4fd4 ng_ubt.ko
65 0x82448000 d0fe netgraph.ko
71 0x82456000 a9f4 ng_hci.ko
83 0x82461000 10e3 ng_bluetooth.ko
91 0x82463000 e41e ng_l2cap.ko
101 0x82472000 1e413ng_btsocket.ko
111 0x82491000 3d37 ng_socket.ko
121 0x82495000 8884 autofs.ko
freebeast(12.0-C)[3]
uname output is:
FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #388
r320353M/320355:1200036: Mon Jun 26 05:18:40 PDT 2017
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64
Hmmm.
Thanks!
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Trump (et al.): Hiding information doesn't prove its falsity.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
Re: Unable to load kernel modules after r320324 -> r320353: "depends on kernel - not available or version mismatch"
On Mon, Jun 26, 2017 at 05:28:24AM -0700, David Wolfskill wrote:
> On Mon, Jun 26, 2017 at 03:05:58PM +0300, Konstantin Belousov wrote:
> > On Mon, Jun 26, 2017 at 04:54:36AM -0700, David Wolfskill wrote:
> > > KLD geom_eli.ko: depends on kernel - not available or version mismatch
> > > linker_load_file: /boot/kernel/geom_eli.ko - unsupported file type
> > > swapon: /dev/ada0s4b.eli: Invalid parameters
> >
> > Again remove all kernel build files and try fresh build.
>
> OK; after clearing /usr/obj/usr/src/sys/GENERIC, then rebuilding the
> kernel ("make -j16 buildkernel && ... && make installkernel") &
> rebooting no longer whines about the kmods, and kldstat says:
>
> freebeast(12.0-C)[2] kldstat
> Id Refs AddressSize Name
> 1 25 0x8020 2081550 kernel
> 21 0x82283000 a128 filemon.ko
> 31 0x82421000 11376geom_eli.ko
> 41 0x82433000 fde7 tmpfs.ko
> 51 0x82443000 4fd4 ng_ubt.ko
> 65 0x82448000 d0fe netgraph.ko
> 71 0x82456000 a9f4 ng_hci.ko
> 83 0x82461000 10e3 ng_bluetooth.ko
> 91 0x82463000 e41e ng_l2cap.ko
> 101 0x82472000 1e413ng_btsocket.ko
> 111 0x82491000 3d37 ng_socket.ko
> 121 0x82495000 8884 autofs.ko
> freebeast(12.0-C)[3]
>
> uname output is:
> FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #388
> r320353M/320355:1200036: Mon Jun 26 05:18:40 PDT 2017
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64
>
> Hmmm.
As if computer tries to say you, do not use meta mode.
___
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: Unable to load kernel modules after r320324 -> r320353: "depends on kernel - not available or version mismatch"
On Mon, Jun 26, 2017 at 03:29:59PM +0300, Konstantin Belousov wrote: > ... > > Hmmm. > > As if computer tries to say you, do not use meta mode. For building the kernel, on head as of some commit after r320307 (but by r320324). Peace, david -- David H. Wolfskill da...@catwhisker.org Trump (et al.): Hiding information doesn't prove its falsity. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'
On Mon, 26 Jun 2017 14:00:48 +0200 "O. Hartmann" wrote: > On Mon, 26 Jun 2017 13:26:08 +0200 > Gary Jennejohn wrote: > > > On Mon, 26 Jun 2017 10:29:47 +0200 > > "O. Hartmann" wrote: > > > > > Over the past week we did not update several 12-CURRENT running > > > development > > > hosts, so today is the first day of performing this task. > > > > > > First I hit the very same problem David Wolfskill reported earlier, a > > > fatal > > > trap 12, but fowllowing the thread, I did as advised: removing /usr/obj > > > completely (we use filemon/WITH_META_MODE=YES all over the place) and > > > recompiling world and kernel. > > > > > > Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and > > > the > > > INO64 update hasn't performed so far starting from r319971, I installed > > > the > > > kernel, rebooted the box in single user mode (this time smoothly), did a > > > mergemaster and tried to do "make installworld" - but the box > > > instantanously > > > bails out: > > > > > > [...] > > > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in > > > file /usr/src/lib/libthread/thr_init.c > > > pid 60 (cc) uid0: exited on signal 6 ... > > > > > > [...] > > > > > > That way, I obviously can not install a world :-( > > > > > > What is wrong here? Is the problem resovable? > > > > > > > How recent was your last update? Some changes were made just a few > > hours ago to fix a stack growth problem in threads. > > Well, what do you mean by "... source is not up to date ..."? > Performing an svn update of /usr/src should suffice, shouldn't > it? If not, then ... please correct me. I think the sources > are up to date as of the moment the bug occured. > > I consider the sources up to date, it is on the latest updated > box r320355. > You did not explicitly state in the orignal post at which SVN revison your code was. Seems to me that my question was reasonable. Now it's clear that your source should have been up to date. Just for the record, I just booted a kernel from SVN r320357 which immediately resulted in a kernel panic. I had to delete everything under /usr/obj/usr/src/sys to get a working kernel. -- Gary Jennejohn ___ 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: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'
On Mon, 26 Jun 2017 14:48:58 +0200 Gary Jennejohn wrote: > On Mon, 26 Jun 2017 14:00:48 +0200 > "O. Hartmann" wrote: > > > On Mon, 26 Jun 2017 13:26:08 +0200 > > Gary Jennejohn wrote: > > > > > On Mon, 26 Jun 2017 10:29:47 +0200 > > > "O. Hartmann" wrote: > > > > > > > Over the past week we did not update several 12-CURRENT running > > > > development hosts, so today is the first day of performing this task. > > > > > > > > First I hit the very same problem David Wolfskill reported earlier, a > > > > fatal trap 12, but fowllowing the thread, I did as advised: > > > > removing /usr/obj completely (we use filemon/WITH_META_MODE=YES all > > > > over the place) and recompiling world and kernel. > > > > > > > > Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update > > > > and the INO64 update hasn't performed so far starting from r319971, I > > > > installed the kernel, rebooted the box in single user mode (this time > > > > smoothly), did a mergemaster and tried to do "make installworld" - but > > > > the box instantanously bails out: > > > > > > > > [...] > > > > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in > > > > file /usr/src/lib/libthread/thr_init.c > > > > pid 60 (cc) uid0: exited on signal 6 ... > > > > > > > > [...] > > > > > > > > That way, I obviously can not install a world :-( > > > > > > > > What is wrong here? Is the problem resovable? > > > > > > > > > > How recent was your last update? Some changes were made just a few > > > hours ago to fix a stack growth problem in threads. > > > > Well, what do you mean by "... source is not up to date ..."? > > Performing an svn update of /usr/src should suffice, shouldn't > > it? If not, then ... please correct me. I think the sources > > are up to date as of the moment the bug occured. > > > > I consider the sources up to date, it is on the latest updated > > box r320355. > > > > You did not explicitly state in the orignal post at which SVN > revison your code was. Seems to me that my question was > reasonable. > > Now it's clear that your source should have been up to date. > > Just for the record, I just booted a kernel from SVN r320357 which > immediately resulted in a kernel panic. I had to delete everything > under /usr/obj/usr/src/sys to get a working kernel. That has been made clear earlier in the thread, telling us that NO_CLEAN and/or META_MODE leaves the object tree in a somehow unusable state. Id did so twice this morning. I have to build a kernel with KTRACE capabilities as requested herein, but can perform this not before tomorrow morning. Some people seem to report positive updates, but starting from a later svn revision. So the problem seems to be transitional ... ___ 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: status of and/or url to check base packages repo somewhere?
On Sun, Jun 25, 2017 at 10:30:53PM -0700, Jeffrey Bouquet wrote: > As the Subject: is there a canonical url to check, and a procedure in place > yet, to, > for instance, if one cannot buildworld on 12.0-CURRENT, to access the package > .txz or > whatever and 'pkg fetch ... pkg add ...' which would substitute for the > buildworld > cycle? Also, one would be rebooted into a GENERIC kernel, ... and other > details ? > There is no public repository for base packages as of yet. It is still highly considered a 'beta' feature at this point. A public repository for base packages is one of the requirements to get it out of 'beta', but there are a few outstanding issues elsewhere. Glen signature.asc Description: PGP signature
Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'
On Mon, 26 Jun 2017 12:22:50 +0100 Steven Hartland wrote: > Is this related to kib's additional fix over the weekend? > > https://svnweb.freebsd.org/changeset/base/320344 > > Regards > Steve > > On 26/06/2017 09:29, O. Hartmann wrote: > > Over the past week we did not update several 12-CURRENT running development > > hosts, so today is the first day of performing this task. > > > > First I hit the very same problem David Wolfskill reported earlier, a fatal > > trap 12, but fowllowing the thread, I did as advised: removing /usr/obj > > completely (we use filemon/WITH_META_MODE=YES all over the place) and > > recompiling world and kernel. > > > > Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and the > > INO64 update hasn't performed so far starting from r319971, I installed the > > kernel, rebooted the box in single user mode (this time smoothly), did a > > mergemaster and tried to do "make installworld" - but the box instantanously > > bails out: > > > > [...] > > Fatal error 'Cannot allocate red zone for initial thread' at line 392 in > > file /usr/src/lib/libthread/thr_init.c > > pid 60 (cc) uid0: exited on signal 6 ... > > > > [...] > > > > That way, I obviously can not install a world :-( > > > > What is wrong here? Is the problem resovable? > > > > Kind regards, > > > > Oliver [...] The very same happens from updating r320144 -> r320355 ___ 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: Current amd64 new error or warning from today's current with ruby r320323
On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov wrote: > No need, I understood why MAP_STACK failed in this case, thanks to the > ktrace log. This is indeed something ruby-specific, or rather, triggered > by ruby special use of libthr. It is not related to the main stack > split. > > It seems that ruby requested very small stack for a new thread, only 5 > pages in size. This size caused the stack gap to be correctly calculated > as having zero size, because the whole stack is allocated by initial grow. > But then there is no space for the guard page, which caused mapping failure > for it, and overall stack mapping failure. > > Try this. > https://people.freebsd.org/~kib/misc/vm2.2.patch > > I managed to get the "Cannot allocate red zone for initial thread" at the start of installworld (doing CC feature detection, IIRC) going from r306247 to r320328. Is it worth trying that patch out? -Ben ___ 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: Current amd64 new error or warning from today's current with ruby r320323
On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote: > On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov > wrote: > > > No need, I understood why MAP_STACK failed in this case, thanks to the > > ktrace log. This is indeed something ruby-specific, or rather, triggered > > by ruby special use of libthr. It is not related to the main stack > > split. > > > > It seems that ruby requested very small stack for a new thread, only 5 > > pages in size. This size caused the stack gap to be correctly calculated > > as having zero size, because the whole stack is allocated by initial grow. > > But then there is no space for the guard page, which caused mapping failure > > for it, and overall stack mapping failure. > > > > Try this. > > https://people.freebsd.org/~kib/misc/vm2.2.patch > > > > > I managed to get the "Cannot allocate red zone for initial thread" at the > start of installworld (doing CC feature detection, IIRC) going from r306247 > to r320328. > > Is it worth trying that patch out? Ensure that you run a kernel past r320344 and then show me ktrace of the failing process. ___ 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: Current amd64 new error or warning from today's current with ruby r320323
> On Jun 26, 2017, at 13:25, Konstantin Belousov wrote: > > On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote: >> On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov >> wrote: >> >>> No need, I understood why MAP_STACK failed in this case, thanks to the >>> ktrace log. This is indeed something ruby-specific, or rather, triggered >>> by ruby special use of libthr. It is not related to the main stack >>> split. >>> >>> It seems that ruby requested very small stack for a new thread, only 5 >>> pages in size. This size caused the stack gap to be correctly calculated >>> as having zero size, because the whole stack is allocated by initial grow. >>> But then there is no space for the guard page, which caused mapping failure >>> for it, and overall stack mapping failure. >>> >>> Try this. >>> https://people.freebsd.org/~kib/misc/vm2.2.patch >>> >>> >> I managed to get the "Cannot allocate red zone for initial thread" at the >> start of installworld (doing CC feature detection, IIRC) going from r306247 >> to r320328. >> >> Is it worth trying that patch out? > > Ensure that you run a kernel past r320344 and then show me ktrace of > the failing process. So I’m running r320364 with a ZFS root: > uname -a FreeBSD bjrbsd 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320364: Mon Jun 26 12:35:03 PDT 2017 benno@bjrbsd:/src/obj/src/freebsd/sys/GENERIC-NODEBUG amd64 While upgrading I discovered that the zfs command works fine in multiuser but fails in single-user in the way described above: # zfs mount -a Fatal error 'Cannot allocate red zone for initial thread' at line 393 in file /src/freebsd/lib(something)/thread/thr_init.c (errno = 12) Abort trap (core dumped) I booted into single-user and ran zfs under ktrace and I’ve put the results up for you: https://people.freebsd.org/~benno/ktrace.out.txt https://people.freebsd.org/~benno/ktrace.out https://people.freebsd.org/~benno/zfs.core ___ 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: Current amd64 new error or warning from today's current with ruby r320323
On Mon, Jun 26, 2017 at 01:34:35PM -0700, Benno Rice wrote:
>
> > On Jun 26, 2017, at 13:25, Konstantin Belousov wrote:
> >
> > On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote:
> >> On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov
> >> wrote:
> >>
> >>> No need, I understood why MAP_STACK failed in this case, thanks to the
> >>> ktrace log. This is indeed something ruby-specific, or rather, triggered
> >>> by ruby special use of libthr. It is not related to the main stack
> >>> split.
> >>>
> >>> It seems that ruby requested very small stack for a new thread, only 5
> >>> pages in size. This size caused the stack gap to be correctly calculated
> >>> as having zero size, because the whole stack is allocated by initial grow.
> >>> But then there is no space for the guard page, which caused mapping
> >>> failure
> >>> for it, and overall stack mapping failure.
> >>>
> >>> Try this.
> >>> https://people.freebsd.org/~kib/misc/vm2.2.patch
> >>>
> >>>
> >> I managed to get the "Cannot allocate red zone for initial thread" at the
> >> start of installworld (doing CC feature detection, IIRC) going from r306247
> >> to r320328.
> >>
> >> Is it worth trying that patch out?
> >
> > Ensure that you run a kernel past r320344 and then show me ktrace of
> > the failing process.
>
> So I???m running r320364 with a ZFS root:
>
> > uname -a
> FreeBSD bjrbsd 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320364: Mon Jun 26
> 12:35:03 PDT 2017 benno@bjrbsd:/src/obj/src/freebsd/sys/GENERIC-NODEBUG
> amd64
>
> While upgrading I discovered that the zfs command works fine in multiuser but
> fails in single-user in the way described above:
>
> # zfs mount -a
> Fatal error 'Cannot allocate red zone for initial thread' at line 393 in file
> /src/freebsd/lib(something)/thread/thr_init.c (errno = 12)
> Abort trap (core dumped)
>
> I booted into single-user and ran zfs under ktrace and I???ve put the results
> up for you:
>
> https://people.freebsd.org/~benno/ktrace.out.txt
> https://people.freebsd.org/~benno/ktrace.out
> https://people.freebsd.org/~benno/zfs.core
Try this. Even if it helps, the patch is being actively discussed and
may be not in its final form.
diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c
index 7b4a86dffd8..2766454d825 100644
--- a/sys/vm/vm_map.c
+++ b/sys/vm/vm_map.c
@@ -1556,6 +1556,25 @@ again:
return (result);
}
+int
+vm_map_find_min(vm_map_t map, vm_object_t object, vm_ooffset_t offset,
+vm_offset_t *addr, vm_size_t length, vm_offset_t min_addr,
+vm_offset_t max_addr, int find_space, vm_prot_t prot, vm_prot_t max,
+int cow)
+{
+ vm_offset_t hint;
+ int rv;
+
+ hint = *addr;
+ for (;;) {
+ rv = vm_map_find(map, object, offset, addr, length, max_addr,
+ find_space, prot, max, cow);
+ if (rv == KERN_SUCCESS || hint == 0 || min_addr >= hint)
+ return (rv);
+ *addr = min_addr;
+ }
+}
+
/*
* vm_map_simplify_entry:
*
diff --git a/sys/vm/vm_map.h b/sys/vm/vm_map.h
index 2c89e1d73d4..78f3f31c226 100644
--- a/sys/vm/vm_map.h
+++ b/sys/vm/vm_map.h
@@ -372,6 +372,8 @@ vm_map_t vm_map_create(pmap_t, vm_offset_t, vm_offset_t);
int vm_map_delete(vm_map_t, vm_offset_t, vm_offset_t);
int vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *, vm_size_t,
vm_offset_t, int, vm_prot_t, vm_prot_t, int);
+int vm_map_find_min(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *,
+vm_size_t, vm_offset_t, vm_offset_t, int, vm_prot_t, vm_prot_t, int);
int vm_map_fixed(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t, vm_size_t,
vm_prot_t, vm_prot_t, int);
int vm_map_findspace (vm_map_t, vm_offset_t, vm_size_t, vm_offset_t *);
diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c
index 4d8f6ad9ed7..24360d422e3 100644
--- a/sys/vm/vm_mmap.c
+++ b/sys/vm/vm_mmap.c
@@ -1438,10 +1439,12 @@ vm_mmap_object(vm_map_t map, vm_offset_t *addr,
vm_size_t size, vm_prot_t prot,
vm_prot_t maxprot, int flags, vm_object_t object, vm_ooffset_t foff,
boolean_t writecounted, struct thread *td)
{
- boolean_t fitit;
+ boolean_t curmap, fitit;
+ vm_offset_t max_addr;
int docow, error, findspace, rv;
- if (map == &td->td_proc->p_vmspace->vm_map) {
+ curmap = map == &td->td_proc->p_vmspace->vm_map;
+ if (curmap) {
PROC_LOCK(td->td_proc);
if (map->size + size > lim_cur_proc(td->td_proc, RLIMIT_VMEM)) {
PROC_UNLOCK(td->td_proc);
@@ -1529,11 +1532,20 @@ vm_mmap_object(vm_map_t map, vm_offset_t *addr,
vm_size_t size, vm_prot_t prot,
MAP_ALIGNMENT_SHIFT);
else
findspace = VMFS_OPTIMAL_SPACE;
- rv = vm_map_find(map, object, foff, addr, size,
+ max_addr = 0;
#ifdef MAP_32BIT
- flags & MAP_32BIT ? MAP_32BIT_MAX_ADDR :
+ if ((flag
Re: Ports still broken by ino64?
I'm sure stas can figure it out! -a On 25 June 2017 at 22:44, Thomas Mueller wrote: > from Adrian Chadd: > >> valgrind broke as part of the ino64 work :( > > Valgrind was not on my mind! Your post sent me to > > ls -d /usr/ports/*/val* > > to find valgrind, and then read the pkg-descr. > > One less tool for getting debugging information when something crashes? > > Tom > > ___ > 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"
head -r320192 -> -r320387 kernel build and install to a DESTDIR: if_igb.ko vs. DESTDIR use for installkernel has symbolic link that seems inapproriate
installkernel DESTDIR=/usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387 produced a if_igb.ko (this used: ls -lD %C ): lrwxr-xr-x 1 root wheel80 20 if_igb.ko -> /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if_em.ko This does not allow simple copies of such directory trees that have if_igb.ko pointing to the right if_em.ko. Looking in my -r320192 based /boot/kernel/ that had been filled in via a default DESTDIR for installkernel (this used: ls -lD %C ): lrwxr-xr-x 1 root wheel21 20 if_igb.ko -> /boot/kernel/if_em.ko So something like: cp -aRx /boot/kernel/ /boot/kercgd ends up with /boot/kercgd/if_igb.ko pointing into /boot/kernel/ instead of into /boot/kercgd/ . === 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"
Recent reports of needing to avoid META_MODE for head kernel builds for updates: a preliminary investigation
For an example of the recent reports:
David Wolfskill david at catwhisker.org wrote on
Mon Jun 26 12:44:20 UTC 2017 :
> On Mon, Jun 26, 2017 at 03:29:59PM +0300, Konstantin Belousov wrote:
> > ...
> >
> > Hmmm.
> >
> > As if computer tries to say you, do not use meta mode.
>
>
> For building the kernel, on head as of some commit after r320307 (but
> by r320324).
While there are other kernel issues going on I decided to try to
investigate the difference in meta mode incremental build results
vs. full rebuild.
I started with head -r320192. This sequence avoids updating
the live kernel (since other problems are being looked into).
Local DESTDIR's are used for installkernel.
# more ~/src.configs/src.conf.amd64-clang.amd64-host
TO_TYPE=amd64
#
KERNCONF=GENERIC-NODBG
TARGET=${TO_TYPE}
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
#WITH_CROSS_COMPILER=
WITH_SYSTEM_COMPILER=
#
WITH_LIBCPLUSPLUS=
WITH_BINUTILS_BOOTSTRAP=
WITH_ELFTOOLCHAIN_BOOTSTRAP=
#WITH_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLD=
WITHOUT_LLD_IS_LD=
WITH_LLVM_LIBUNWIND=
WITH_LLDB=
#PORTS_MODULES=emulators/virtualbox-ose-additions
#
WITH_BOOT=
WITH_LIB32=
#
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#WERROR=
MALLOC_PRODUCTION=
#
WITH_REPRODUCIBLE_BUILD=
WITH_DEBUG_FILES=
Note the "WITH_REPRODUCIBLE_BUILD=".
>From a -r320192 context I did:
svnlite update -r320387 /usr/src
I then used my usual script to do buildworld buildkernel. It updated things
in the pre-existing /usr/obj/amd64_clang/amd64.amd64/ . (I cause the
explicit amd64.amd64 deliberately. This is not a cross build.)
I'll note that I've been using /usr/obj/amd64_clang/amd64.amd64/ for
incremental builds for a long time. (This will show up later.)
I then used the script to:
installkernel
DESTDIR=/usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387
I then moved /usr/obj/amd64_clang/ to be /usr/obj/amd64_clang_192_387/ for
later potential detailed comparisons. I then redid the buildworld buildkernel
which produced another /usr/obj/amd64_clang/ but from scratch this time.
I then used the script to:
installkernel
DESTDIR=/usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387
I then did (the D %C avoids date/time text being different):
# ls -lD %C
/usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/ >
~/ls_192_387_kernel.txt
# ls -lD %C
/usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/ >
~/ls_noth_387_kernel.txt
allowing me to compare sizes and permissions:
# diff -u ~/ls_192_387_kernel.txt ~/ls_noth_387_kernel.txt | more
--- /root/ls_192_387_kernel.txt 2017-06-26 16:13:25.734588000 -0700
+++ /root/ls_noth_387_kernel.txt2017-06-26 18:22:34.001866000 -0700
@@ -1,4 +1,4 @@
-total 69163
+total 68995
-r-xr-xr-x 1 root wheel107664 20 aac.ko
-r-xr-xr-x 1 root wheel105232 20 aacraid.ko
-r-xr-xr-x 1 root wheel 6296 20 accf_data.ko
@@ -270,7 +270,7 @@
-r-xr-xr-x 1 root wheel 41968 20 if_gre.ko
-r-xr-xr-x 1 root wheel 41664 20 if_hme.ko
-r-xr-xr-x 1 root wheel 18192 20 if_ic.ko
-lrwxr-xr-x 1 root wheel80 20 if_igb.ko ->
/usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if_em.ko
+lrwxr-xr-x 1 root wheel80 20 if_igb.ko ->
/usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/if_em.ko
-r-xr-xr-x 1 root wheel 24000 20 if_ipheth.ko
-r-xr-xr-x 1 root wheel 78344 20 if_ipw.ko
-r-xr-xr-x 1 root wheel113544 20 if_iwi.ko
@@ -419,7 +419,7 @@
-r-xr-xr-x 1 root wheel 12160 20 joy.ko
-r-xr-xr-x 1 root wheel 46984 20 kbdmux.ko
-r-xr-xr-x 1 root wheel 14168 20 kern_testfrwk.ko
--r-xr-xr-x 1 root wheel 27479832 20 kernel
+-r-xr-xr-x 1 root wheel 27307184 20 kernel
-r-xr-xr-x 1 root wheel105216 20 kgssapi.ko
-r-xr-xr-x 1 root wheel 53840 20 kgssapi_krb5.ko
-r-xr-xr-x 1 root wheel163976 20 krpc.ko
[Note: there is still a problem of if_igb.ko being handled as
a full-pathj symbolic link such that copying kernels around
need not end up with a working if_igb.ko . I doubt that this
is the problem that the reports are about.]
The kernel from the incremental build is larger
(includes more?).
Of this the kernel being a different size would
seem to be a problem. But going in a different
direction that is more detailed (content comparison
spanning all of boot, not just boot/kernel/ ):
# diff -r /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/
/usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/ | more
Binary files
/usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/aesni.ko
and
/usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/aesni.ko
differ
Binary files
/usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/ath_hal_ar5416.ko
and
/usr/obj/DESTDIRs/cla
Compiler more strict on 12 with r320337 ?
Hi!
Compiling devel/lfcbase, it fails while including sys/socketvar.h with
this error:
In file included from Net.cc:36:
/usr/include/sys/socketvar.h:117:4: error: types cannot be declared in an
anonymous struct
enum {
^
1 error generated.
Should sys/socketvar.h be included at all ?
--
p...@freebsd.org +49 171 31013723 years to go !
___
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"
