Re: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto
On Fri, 12 Oct 2018 09:59+0200, Raúl wrote: > (also deleted obj) I do that whenever sys/sys/param.h changes. My builder wipes obj unconditionally every Monday in addition to the above. -- 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: r343111 breaks build
On Thu, 17 Jan 2019 04:49-0800, David Wolfskill wrote: > On Thu, Jan 17, 2019 at 03:37:16PM +0300, Lev Serebryakov wrote: > > > > I can not build CURRENT r343111 on r343022 world. Looks like r343111 > > itself cause problems (r343110 builds): > > > > In file included from /data/src/contrib/libc++/src/algorithm.cpp:11: > > In file included from /data/src/contrib/libc++/include/random:1646: > > In file included from /data/src/contrib/libc++/include/istream:163: > > In file included from /data/src/contrib/libc++/include/ostream:138: > > In file included from /data/src/contrib/libc++/include/ios:216: > > In file included from /data/src/contrib/libc++/include/__locale:18: > > In file included from /data/src/contrib/libc++/include/mutex:191: > > In file included from /data/src/contrib/libc++/include/__mutex_base:16: > > In file included from /data/src/contrib/libc++/include/system_error:146: > > In file included from /data/src/contrib/libc++/include/__errc:106: > > In file included from /data/src/contrib/libc++/include/cerrno:27: > > /data/src/contrib/libc++/include/errno.h:70:2: error: unterminated > > conditional directive > > #ifdef ELAST > > ^ > > /data/src/contrib/libc++/include/errno.h:63:2: error: unterminated > > conditional directive > > #ifdef ELAST > > ^ > > ... > > Confirmed (though in my case, I'm building on r343088, and I did not try > building r343110). I did see the above failure on both my build machine > and my laptop. Try the attached patch, repeated here in case it gets munched by mailman: Index: contrib/libc++/include/errno.h === --- contrib/libc++/include/errno.h (revision 343111) +++ contrib/libc++/include/errno.h (working copy) @@ -56,6 +56,7 @@ #ifdef ELAST #undef ELAST #define ELAST EINTEGRITY +#endif #elif !defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 @@ -63,6 +64,7 @@ #ifdef ELAST #undef ELAST #define ELAST EOWNERDEAD +#endif #elif !defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define EOWNERDEAD __elast1 @@ -70,6 +72,7 @@ #ifdef ELAST #undef ELAST #define ELAST EINTEGRITY +#endif #elif !defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define EOWNERDEAD __elast1 @@ -76,6 +79,7 @@ #ifdef ELAST #undef ELAST #define ELAST EOWNERDEAD +#endif #elif defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 @@ -83,6 +87,7 @@ #ifdef ELAST #undef ELAST #define ELAST EINTEGRITY +#endif #elif defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 @@ -89,6 +94,7 @@ #ifdef ELAST #undef ELAST #define ELAST ENOTRECOVERABLE +#endif #elif defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define EINTEGRITY __elast1 @@ -95,6 +101,7 @@ #ifdef ELAST #undef ELAST #define ELAST EINTEGRITY +#endif #endif // !defined(OWNERDEAD) && !defined(NOTRECOVERABLE) && !defined(INTEGRITY) -- Trond.Index: contrib/libc++/include/errno.h === --- contrib/libc++/include/errno.h (revision 343111) +++ contrib/libc++/include/errno.h (working copy) @@ -56,6 +56,7 @@ #ifdef ELAST #undef ELAST #define ELAST EINTEGRITY +#endif #elif !defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 @@ -63,6 +64,7 @@ #ifdef ELAST #undef ELAST #define ELAST EOWNERDEAD +#endif #elif !defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define EOWNERDEAD __elast1 @@ -70,6 +72,7 @@ #ifdef ELAST #undef ELAST #define ELAST EINTEGRITY +#endif #elif !defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define EOWNERDEAD __elast1 @@ -76,6 +79,7 @@ #ifdef ELAST #undef ELAST #define ELAST EOWNERDEAD +#endif #elif defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 @@ -83,6 +87,7 @@ #ifdef ELAST #undef ELAST #define ELAST EINTEGRITY +#endif #elif defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 @@ -89,6 +94,7 @@ #ifdef ELAST #undef ELAST #define ELAST ENOTRECOVERABLE +#endif #elif defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define EINTEGRITY __elast1 @@ -95,6 +101,7 @@ #ifdef ELAST #undef ELAST #define ELAST EINTEGRITY +#endif #endif // !defined(OWNERDEAD) && !defined(NOTRECOVERABLE) && !defined(INTEGRITY) ___ 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: r343111 breaks build
On Thu, 17 Jan 2019 15:53+0100, Trond Endrestøl wrote: > Try the attached patch, [...] I fail to see how r343113 actually fixes r343111. Attached patch augments and corrects the changes done in r343113. -- Trond.Index: contrib/libc++/include/errno.h === --- contrib/libc++/include/errno.h (revision 343114) +++ contrib/libc++/include/errno.h (working copy) @@ -56,6 +56,7 @@ #if defined(ELAST) #undef ELAST #define ELAST EINTEGRITY +#endif #elif !defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 @@ -63,6 +64,7 @@ #if defined(ELAST) #undef ELAST #define ELAST EOWNERDEAD +#endif #elif !defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define EOWNERDEAD __elast1 @@ -70,6 +72,7 @@ #if defined(ELAST) #undef ELAST #define ELAST EINTEGRITY +#endif #elif !defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define EOWNERDEAD __elast1 @@ -76,6 +79,7 @@ #if defined(ELAST) #undef ELAST #define ELAST EOWNERDEAD +#endif #elif defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 @@ -83,6 +87,7 @@ #if defined(ELAST) #undef ELAST #define ELAST EINTEGRITY +#endif #elif defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 @@ -89,6 +94,7 @@ #if defined(ELAST) #undef ELAST #define ELAST ENOTRECOVERABLE +#endif #elif defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define EINTEGRITY __elast1 @@ -95,6 +101,7 @@ #if defined(ELAST) #undef ELAST #define ELAST EINTEGRITY +#endif #endif // !defined(OWNERDEAD) && !defined(NOTRECOVERABLE) && !defined(INTEGRITY) ___ 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: 13.0-CURRENT drops to debugger on shutdown with IPNAT enabled
On Sun, 20 Jan 2019 13:09-0500, David Boyd wrote: > 13.0-CURRENT drops to debugger on shutdown with IPNAT enabled. > > Running in VirtualBox 6.0.2. > > The identical configuration running 12.0-RELEASE-p2, 12.0-STABLE, 11.2- > RELEASE-p8 and 11.2-STABLE do not exhibit this behavior. > > This (VM) is a test machine and I can do anything that will help > identify the root of this problem. Is the VM configured to use UEFI as the boot firmware? I've noticed 13.0-CURRENT fails to poweroff, be it by way of shutdown -p now or halt -p, when using UEFI on VBox 5.2.x and 6.0.y. shutdown -h and plain halt works as intended. Maybe this is completely unrelated to your issue. > I have included screenshots of the debug output and a backtrace. The screenshots got stripped off by the mailman list software. Can you reupload them somewhere else, or transcribe the relevant details? -- 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"
ZFS no longer mounted in alphanumerical order
Has anyone else noticed ZFS datasets are no longer mounted in alphanumerical order in CURRENT? It looks more like they are mounted in the order in which they are encountered. Are there any chance of reverting to the old behaviour? Here's an example: Filesystem SizeUsed Avail Capacity Mounted on zroot/ROOT/20190311-r3450136.8G1.7G5.1G25%/ devfs 1.0K1.0K 0B 100%/dev zroot/usr/obj 5.1G 30K5.1G 0%/usr/obj zroot/usr/src 5.1G 30K5.1G 0%/usr/src zroot/home 5.1G 30K5.1G 0%/home zroot/usr/ports5.1G 30K5.1G 0%/usr/ports zroot/tmp 5.1G 51K5.1G 0%/tmp zroot/usr/ports/packages 5.1G 30K5.1G 0% /usr/ports/packages zroot/usr/ports/workdirs 5.1G 30K5.1G 0% /usr/ports/workdirs zroot/usr/ports/local 5.1G 30K5.1G 0%/usr/ports/local zroot/usr/compat 5.1G 30K5.1G 0%/usr/compat zroot/usr/ports/distfiles 5.1G 30K5.1G 0% /usr/ports/distfiles zroot/var 5.1G 22M5.1G 0%/var zroot/nfs 5.1G 30K5.1G 0%/nfs zroot/media5.1G 31K5.1G 0%/media zroot/usr/local5.9G804M5.1G13%/usr/local zroot/usr/compat/linux 5.1G 31K5.1G 0%/usr/compat/linux zroot/var/db/ports 5.1G 30K5.1G 0%/var/db/ports zroot/var/lib 5.1G 30K5.1G 0%/var/lib zroot/usr/local/etc5.1G924K5.1G 0%/usr/local/etc zroot/var/empty5.1G 30K5.1G 0%/var/empty zroot/usr/local/pgsql 5.1G 30K5.1G 0%/usr/local/pgsql zroot/var/audit5.1G 30K5.1G 0%/var/audit zroot/var/backups 5.1G3.2M5.1G 0%/var/backups zroot/var/mail 5.1G 30K5.1G 0%/var/mail zroot/usr/local/certs 5.1G 30K5.1G 0%/usr/local/certs zroot/var/unbound 5.1G 30K5.1G 0%/var/unbound zroot/var/db/mysql 5.1G 30K5.1G 0%/var/db/mysql zroot/usr/local/www5.1G 30K5.1G 0%/usr/local/www zroot/usr/local/tests 5.1G 30K5.1G 0%/usr/local/tests zroot/var/db/boinc 5.1G 30K5.1G 0%/var/db/boinc zroot/var/Named5.1G 30K5.1G 0%/var/Named zroot/var/db/etcupdate 5.1G993K5.1G 0%/var/db/etcupdate zroot/var/db/hyperv5.1G 30K5.1G 0%/var/db/hyperv zroot/usr/local/var5.1G 30K5.1G 0%/usr/local/var zroot/var/crash5.1G 30K5.1G 0%/var/crash zroot/usr/local/info 5.1G 32K5.1G 0%/usr/local/info zroot/var/tmp 5.1G 30K5.1G 0%/var/tmp zroot/var/spool5.1G 81K5.1G 0%/var/spool zroot/var/log 5.1G8.7M5.1G 0%/var/log zroot/var/db/bacula5.1G 30K5.1G 0%/var/db/bacula zroot/var/run 5.1G 53K5.1G 0%/var/run zroot/var/cache/synth 5.1G801K5.1G 0%/var/cache/synth zroot/var/db/pkg 5.1G7.1M5.1G 0%/var/db/pkg zroot/var/synth5.1G 34K5.1G 0%/var/synth zroot/var/spool/ftp5.1G 30K5.1G 0%/var/spool/ftp zroot/var/synth/builders 5.1G 30K5.1G 0% /var/synth/builders fdescfs1.0K1.0K 0B 100%/dev/fd procfs 4.0K4.0K 0B 100%/proc devfs 1.0K1.0K 0B 100% /usr/compat/linux/dev fdescfs1.0K1.0K 0B 100% /usr/compat/linux/dev/fd linprocfs 4.0K4.0K 0B 100% /usr/compat/linux/proc linsysfs 4.0K4.0K 0B 100% /usr/compat/linux/sys -- 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: ZFS no longer mounted in alphanumerical order
On Mon, 11 Mar 2019 13:47-0700, Matthew Ahrens wrote: > On Mon, Mar 11, 2019 at 11:33 AM Trond Endrestøl < > trond.endres...@fagskolen.gjovik.no> wrote: > > > Has anyone else noticed ZFS datasets are no longer mounted in > > alphanumerical order in CURRENT? It looks more like they are mounted > > in the order in which they are encountered. > > Wouldn't surprise me if this was caused by the parallel mount changes. The > filesystems should still be mounted in hierarchical order (parents before > children), so everything should still work. What problem are you seeing as > a result of the changed mount order? Actually no problems other than it's rather unintuitive when looking at the output of "df -ah". Could we have a command line option for disabling the parallel mount? -- 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: ZFS no longer mounted in alphanumerical order
On Mon, 11 Mar 2019 14:03-0700, Freddie Cash wrote: > On Mon, Mar 11, 2019 at 1:59 PM Trond Endrestøl < > trond.endres...@fagskolen.gjovik.no> wrote: > > > On Mon, 11 Mar 2019 13:47-0700, Matthew Ahrens wrote: > > > > > On Mon, Mar 11, 2019 at 11:33 AM Trond Endrestøl < > > > trond.endres...@fagskolen.gjovik.no> wrote: > > > > > > > Has anyone else noticed ZFS datasets are no longer mounted in > > > > alphanumerical order in CURRENT? It looks more like they are mounted > > > > in the order in which they are encountered. > > > > > > Wouldn't surprise me if this was caused by the parallel mount changes. > > The > > > filesystems should still be mounted in hierarchical order (parents before > > > children), so everything should still work. What problem are you seeing > > as > > > a result of the changed mount order? > > > > Actually no problems other than it's rather unintuitive when looking > > at the output of "df -ah". Could we have a command line option for > > disabling the parallel mount? > > Wouldn't it make more sense to teach df, du, "zfs list", and other things > that list the mounted filesystems to use sorted output? That's a better alternative. > IOW, is it the mount process itself that's an issue, or just the output of > mounted filesystems list? The latter in my case. -- 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: ZFS no longer mounted in alphanumerical order
On Tue, 12 Mar 2019 08:54+0200, Andriy Gapon wrote:
> On 12/03/2019 02:12, Rodney W. Grimes wrote:
> >> On 11/03/2019 23:03, Freddie Cash wrote:
> >>> Wouldn't it make more sense to teach df, du, "zfs list", and other things
> >>> that list the mounted filesystems to use sorted output?
> >>
> >> | sort [desired options]
> >
> > Except that df and zfs list have a header that you have to deal with,
> > which is not so easy to get sort to do the right things with out
> > some hoop jumping.
>
> Like "| tail +2" ?
> Or if it's just for visual inspection (as seems to be the case for the
> original
> poster) just mentally filter out that line.
>
> >> P.S.
> >> zfs list already supports sorting by a specific property.
> >
> > Perhaps make zfs list -s mountpoint a default?
>
> Why?
I concocted a shell script, it looks promising:
#!/bin/sh
#-
# Parallel mounting of ZFS filesystems leaves a chaotic listing of
# mounted filesystems when viewed by df(1).
# Separating the header from the remaining lines and sorting the
# latter before recombining is a viable solution.
#-
DF=/bin/df
${DF} ${@} | grep^Filesystem
${DF} ${@} | grep -v ^Filesystem | sort -k 6
# new-df.sh
--
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: ZFS no longer mounted in alphanumerical order
On Tue, 12 Mar 2019 11:37+0100, Jan Martin Mikkelsen wrote:
> > On 12 Mar 2019, at 10:37, Trond Endrestøl
> > wrote:
> > I concocted a shell script, it looks promising:
> >
> > #!/bin/sh
> > #-
> > # Parallel mounting of ZFS filesystems leaves a chaotic listing of
> > # mounted filesystems when viewed by df(1).
> > # Separating the header from the remaining lines and sorting the
> > # latter before recombining is a viable solution.
> > #-
> >
> > DF=/bin/df
> >
> > ${DF} ${@} | grep^Filesystem
> > ${DF} ${@} | grep -v ^Filesystem | sort -k 6
> >
> > # new-df.sh
>
> An alternative sort approach, which handles df arguments which change the
> number of columns, and only invokes df once:
>
> ${DF} "$@" | awk '/^Filesystem/ { print; sort = "sort -k " NF } !
> /^Filesystem/ { print | sort }’
Well, yes and no, mostly no.
Why are we feeding each line from df(1) separately to sort(1)?
It defeats the entire purpose. No sorting takes place.
We might be better off accumulating the majority of the lines and
sorting them in an END block.
--
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: ZFS no longer mounted in alphanumerical order
On Tue, 12 Mar 2019 12:14+0100, Trond Endrestøl wrote:
> On Tue, 12 Mar 2019 11:37+0100, Jan Martin Mikkelsen wrote:
>
> > > On 12 Mar 2019, at 10:37, Trond Endrestøl
> > > wrote:
> > > I concocted a shell script, it looks promising:
> > >
> > > #!/bin/sh
> > > #-
> > > # Parallel mounting of ZFS filesystems leaves a chaotic listing of
> > > # mounted filesystems when viewed by df(1).
> > > # Separating the header from the remaining lines and sorting the
> > > # latter before recombining is a viable solution.
> > > #-
> > >
> > > DF=/bin/df
> > >
> > > ${DF} ${@} | grep^Filesystem
> > > ${DF} ${@} | grep -v ^Filesystem | sort -k 6
> > >
> > > # new-df.sh
> >
> > An alternative sort approach, which handles df arguments which change the
> > number of columns, and only invokes df once:
> >
> > ${DF} "$@" | awk '/^Filesystem/ { print; sort = "sort -k " NF } !
> > /^Filesystem/ { print | sort }’
>
> Well, yes and no, mostly no.
>
> Why are we feeding each line from df(1) separately to sort(1)?
> It defeats the entire purpose. No sorting takes place.
>
> We might be better off accumulating the majority of the lines and
> sorting them in an END block.
How about this?
/bin/df ${@} | /usr/bin/awk '/^Filesystem/ { print; sort = "/usr/bin/sort -sk "
NF-1 } ! /^Filesystem/ { if (length(acc) > 0) acc = acc "\n" $0; else acc = $0;
} END { print acc | sort }'
--
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: ZFS no longer mounted in alphanumerical order
On Tue, 12 Mar 2019 13:27+0200, Andriy Gapon wrote: > On 12/03/2019 11:37, Trond Endrestøl wrote: > > # Parallel mounting of ZFS filesystems leaves a chaotic listing of > > # mounted filesystems when viewed by df(1). > > df reports filesystems in the order they were mounted. > If you unmount and remount a filesystem or mount a new filesystem, you can see > it for yourself. Also, if you ever used fstab then you could see that too. > Just because previously the output happened to look like it was sorted does > not > mean that it was or that there was such an intention. I am aware of all of this. I was caught by surprise when my ZFS filesystems appeared partially ordered. I know that / and /dev are mounted by the kernel, and sometime later the remaining UFS/ZFS filesystems, and I also have a few synthetic filesystems mounted late in the boot process, and the latter ones (still) appear at the end of df(1)'s output. Order has somewhat been restored. Maybe it's no biggie. -- 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: leaked swap?
On Tue, 19 Mar 2019 16:02+0300, Slawa Olhovchenkov wrote: > On Mon, Mar 18, 2019 at 11:00:10PM +0200, Andriy Gapon wrote: > > > On 18/03/2019 20:01, Andrey Fesenko wrote: > > > Not this? ZFS use wired and not clean only reboot? > > > https://reviews.freebsd.org/D7538?id=25108 > > > > Wired memory surely has nothing to do with swap. > > Wired memory can pressure to swapable memory I've noticed setting vm.pageout_update_period=0 in /etc/sysctl.conf eliminated excessive swapping, effectively disabling r334154. Maybe this is irrelevant. I waited a while before mentioning this. Response times of idle services skyrocketed in my case. -- 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: r346025: ZFS filesystems do not mount anymore
On Mon, 8 Apr 2019 19:58+0200, O. Hartmann wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hello, > > after a bunch of updates this weekend, mounting ZFS filesystems on CURRENT > r346025 doesn't > work anymore at boot time when ZFS is built-in-kernel. zfs_enable="YES" is > set in /etc/rc.conf. > > After the system has booted, mounting all ZFS filesystems via "zfs mount -a" > operates as > expected and all filesystems are available as usual. I blame r346017: Trying to mount root from zfs:zroot/ROOT/20190409-r346017 [] Setting hostuuid: 7b624d1c-4bc3-e2cb-4ac2-6487a4b4774c. Setting hostid: 0xf9071336. interface zfsctrl.1 already present in the KLD 'kernel'! linker_load_file: /boot/kernel/zfs.ko - unsupported file type kldload: an error occurred while loading module zfs. Please check dmesg(8) for more details. /etc/rc: WARNING: Unable to load kernel module zfs Starting file system checks: Mounting local filesystems:. interface zfsctrl.1 already present in the KLD 'kernel'! linker_load_file: /boot/kernel/zfs.ko - unsupported file type kldload: an error occurred while loading module zfs. Please check dmesg(8) for more details. /etc/rc: WARNING: Unable to load kernel module zfs interface zfsctrl.1 already present in the KLD 'kernel'! linker_load_file: /boot/kernel/zfs.ko - unsupported file type kldload: an error occurred while loading module zfs. Please check dmesg(8) for more details. /etc/rc: WARNING: Unable to load kernel module zfs ELF ldconfig path: /lib /usr/lib /usr/lib/compat 32-bit compatibility ldconfig path: /usr/lib32 [...] Creating and/or trimming log files. Starting syslogd. Apr 9 09:48:32 freebsd-head-zfs syslogd: /var/log/security: No such file or directory Setting date via ntp. 9 Apr 09:48:38 ntpdate[1073]: step time server 2001:W:X:Y::Z offset -0.992370 sec No core dumps found. Clearing /tmp (X related). Updating motd:. Mounting late filesystems:mount: /usr/compat/linux: No such file or directory mount: /usr/compat/linux: No such file or directory mount: /usr/compat/linux: No such file or directory mount: /usr/compat/linux: No such file or directory . Mounting /etc/fstab filesystems failed, startup aborted ERROR: ABORTING BOOT (sending SIGTERM to parent)! Enter full pathname of shell or RETURN for /bin/sh: root@freebsd-head-zfs:/ # zfs mount -av root@freebsd-head-zfs:/ # mount -al root@freebsd-head-zfs:/ # exit Setting hostuuid: 7b624d1c-4bc3-e2cb-4ac2-6487a4b4774c. Setting hostid: 0xf9071336. interface zfsctrl.1 already present in the KLD 'kernel'! linker_load_file: /boot/kernel/zfs.ko - unsupported file type kldload: an error occurred while loading module zfs. Please check dmesg(8) for more details. /etc/rc: WARNING: Unable to load kernel module zfs Fast boot: skipping disk checks. Mounting local filesystems:. interface zfsctrl.1 already present in the KLD 'kernel'! linker_load_file: /boot/kernel/zfs.ko - unsupported file type kldload: an error occurred while loading module zfs. Please check dmesg(8) for more details. /etc/rc: WARNING: Unable to load kernel module zfs interface zfsctrl.1 already present in the KLD 'kernel'! linker_load_file: /boot/kernel/zfs.ko - unsupported file type kldload: an error occurred while loading module zfs. Please check dmesg(8) for more details. /etc/rc: WARNING: Unable to load kernel module zfs ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/perl5/5.28/mach/CORE 32-bit compatibility ldconfig path: /usr/lib32 [...] Once I manually mount the remaining filesystems, multiuser boot proceeds as expected. My kernel has options ZFS, and the boot scripts doesn't account for this scenario. -- 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: r346025: ZFS filesystems do not mount anymore
On Tue, 9 Apr 2019 10:06+0200, Trond Endrestøl wrote: > On Mon, 8 Apr 2019 19:58+0200, O. Hartmann wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Hello, > > > > after a bunch of updates this weekend, mounting ZFS filesystems on CURRENT > > r346025 doesn't > > work anymore at boot time when ZFS is built-in-kernel. zfs_enable="YES" is > > set in /etc/rc.conf. > > > > After the system has booted, mounting all ZFS filesystems via "zfs mount > > -a" operates as > > expected and all filesystems are available as usual. > > I blame r346017: > > Trying to mount root from zfs:zroot/ROOT/20190409-r346017 [] > Setting hostuuid: 7b624d1c-4bc3-e2cb-4ac2-6487a4b4774c. > Setting hostid: 0xf9071336. > interface zfsctrl.1 already present in the KLD 'kernel'! > linker_load_file: /boot/kernel/zfs.ko - unsupported file type > kldload: an error occurred while loading module zfs. Please check dmesg(8) > for more details. > /etc/rc: WARNING: Unable to load kernel module zfs > Starting file system checks: > Mounting local filesystems:. > interface zfsctrl.1 already present in the KLD 'kernel'! > linker_load_file: /boot/kernel/zfs.ko - unsupported file type > kldload: an error occurred while loading module zfs. Please check dmesg(8) > for more details. > /etc/rc: WARNING: Unable to load kernel module zfs > interface zfsctrl.1 already present in the KLD 'kernel'! > linker_load_file: /boot/kernel/zfs.ko - unsupported file type > kldload: an error occurred while loading module zfs. Please check dmesg(8) > for more details. > /etc/rc: WARNING: Unable to load kernel module zfs > ELF ldconfig path: /lib /usr/lib /usr/lib/compat > 32-bit compatibility ldconfig path: /usr/lib32 > > [...] > > Creating and/or trimming log files. > Starting syslogd. > Apr 9 09:48:32 freebsd-head-zfs syslogd: /var/log/security: No > such file or directory > Setting date via ntp. > 9 Apr 09:48:38 ntpdate[1073]: step time server 2001:W:X:Y::Z offset > -0.992370 sec > No core dumps found. > Clearing /tmp (X related). > Updating motd:. > Mounting late filesystems:mount: /usr/compat/linux: No such file or directory > mount: /usr/compat/linux: No such file or directory > mount: /usr/compat/linux: No such file or directory > mount: /usr/compat/linux: No such file or directory > . > Mounting /etc/fstab filesystems failed, startup aborted > ERROR: ABORTING BOOT (sending SIGTERM to parent)! > Enter full pathname of shell or RETURN for /bin/sh: > root@freebsd-head-zfs:/ # zfs mount -av > root@freebsd-head-zfs:/ # mount -al > root@freebsd-head-zfs:/ # exit > Setting hostuuid: 7b624d1c-4bc3-e2cb-4ac2-6487a4b4774c. > Setting hostid: 0xf9071336. > interface zfsctrl.1 already present in the KLD 'kernel'! > linker_load_file: /boot/kernel/zfs.ko - unsupported file type > kldload: an error occurred while loading module zfs. Please check dmesg(8) > for more details. > /etc/rc: WARNING: Unable to load kernel module zfs > Fast boot: skipping disk checks. > Mounting local filesystems:. > interface zfsctrl.1 already present in the KLD 'kernel'! > linker_load_file: /boot/kernel/zfs.ko - unsupported file type > kldload: an error occurred while loading module zfs. Please check dmesg(8) > for more details. > /etc/rc: WARNING: Unable to load kernel module zfs > interface zfsctrl.1 already present in the KLD 'kernel'! > linker_load_file: /boot/kernel/zfs.ko - unsupported file type > kldload: an error occurred while loading module zfs. Please check dmesg(8) > for more details. > /etc/rc: WARNING: Unable to load kernel module zfs > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib > /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg > /usr/local/lib/perl5/5.28/mach/CORE > 32-bit compatibility ldconfig path: /usr/lib32 > > [...] At a later point, this happens: Starting syslogd. usage: protect [-i] command protect [-cdi] -g pgrp | -p pid Setting date via ntp. It looks like syslogd is no longer protected against the OOM killer. > Once I manually mount the remaining filesystems, multiuser boot > proceeds as expected. My kernel has options ZFS, and the boot scripts > doesn't account for this scenario. -- 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"
Panic in fbt_provide_module_function() on head amd64 r347403
Host is Windows 7 x64 SP1. CPU is Core i7 960. Hypervisor is VirtualBox 6.0.6. VM is using UEFI. Kernel config is https://ximalas.info/~trond/create-zfs/canmount/VBOXGUEST-amd64-head Crash happens early during boot, right after launching the APs. fault virtual address = 0x0 [...] KDB backtrace: db_trace_self_wrapper() at vpanic() at panic() at trap_fatal() at trap_pfault() at trap() at calltrap() at -- trap 0xc, rip = 0x8196d63a, rsp = 0x8198d730, rbp = 0x8198d790 --- fbt_provide_module_function() at 0x8196d63a = fbt_provide_module_function+0x7a/frame 0x8198d790 link_elf_each_function_nameval() at 0x80822ae5 = link_elf_each_function_nameval+0x115/frame 0x8198d7e0 fbt_provide_module() at 0x8196c33e = fbt_provide_module+0xde/frame 0x8198dc10 fbt_linker_file_cb() at 0x8196c242 = fbt_linker_file_cb+0x12/frame 0x8198dc20 linker_file_foreach() at 0x807c47b7 = linker_file_foreach+0x67/frame 0x8198dc60 mi_startup() at 0x80786de6 = mi_startup+0x216/frame 0x8198dcb0 btext() at 0x8030da2c = btext+0x2c Uptime: 1s Previous BE is r346969 and works flawlessly. No dumpdev is enabled to capture the details this early during boot. Suggestions are welcome. -- 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: Panic in fbt_provide_module_function() on head amd64 r347403
On Thu, 9 May 2019 17:23-0500, Larry Rosenman wrote:
> On 05/09/2019 5:19 pm, Trond Endrestøl wrote:
> > Host is Windows 7 x64 SP1.
> > CPU is Core i7 960.
> > Hypervisor is VirtualBox 6.0.6.
> > VM is using UEFI.
> > Kernel config is
> > https://ximalas.info/~trond/create-zfs/canmount/VBOXGUEST-amd64-head
> >
> > Crash happens early during boot, right after launching the APs.
> >
> > fault virtual address = 0x0
> > [...]
> > KDB backtrace:
> > db_trace_self_wrapper() at
> > vpanic() at
> > panic() at
> > trap_fatal() at
> > trap_pfault() at
> > trap() at
> > calltrap() at
> > -- trap 0xc, rip = 0x8196d63a, rsp = 0x8198d730, rbp =
> > 0x8198d790 ---
> > fbt_provide_module_function() at 0x8196d63a =
> > fbt_provide_module_function+0x7a/frame 0x8198d790
> > link_elf_each_function_nameval() at 0x80822ae5 =
> > link_elf_each_function_nameval+0x115/frame 0x8198d7e0
> > fbt_provide_module() at 0x8196c33e =
> > fbt_provide_module+0xde/frame 0x8198dc10
> > fbt_linker_file_cb() at 0x8196c242 =
> > fbt_linker_file_cb+0x12/frame 0x8198dc20
> > linker_file_foreach() at 0x807c47b7 =
> > linker_file_foreach+0x67/frame 0x8198dc60
> > mi_startup() at 0x80786de6 = mi_startup+0x216/frame
> > 0x8198dcb0
> > btext() at 0x8030da2c = btext+0x2c
> > Uptime: 1s
> >
> > Previous BE is r346969 and works flawlessly.
> > No dumpdev is enabled to capture the details this early during boot.
> > Suggestions are welcome.
>
> There is a patch:
> From: ma...@freebsd.org (on my Crash loading dtraceall thread):
>
>
> I see, my theory above is not the real problem here. The resolver for
> x86_rng_store() may return NULL, which we do not expect. Can you show
> the CPU info and features lines from the dmesg to confirm?
CPU: Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz (3207.36-MHz K8-class CPU)
Origin="GenuineIntel" Id=0x196a5 Family=0x6 Model=0x1a Stepping=5
Features=0x1783fbff
Features=0x180201
AMD Features=0x28100800
AMD Features2=0x1
TSC: P-state invariant
I'll try the patch below when I get home.
Thanks.
> Also see if this patch helps:
>
> diff --git a/sys/dev/random/ivy.c b/sys/dev/random/ivy.c
> index 57f3d0a1d80b..71065d788cf9 100644
> --- a/sys/dev/random/ivy.c
> +++ b/sys/dev/random/ivy.c
> @@ -97,6 +97,13 @@ x86_rdseed_store(u_long *buf)
> return (retry);
> }
>
> +static int
> +x86_dead_store(u_long *buf __unused)
> +{
> +
> +panic("missing hardware PRNG support");
> +}
> +
> DEFINE_IFUNC(static, int, x86_rng_store, (u_long *buf), static)
> {
> has_rdrand = (cpu_feature2 & CPUID2_RDRAND);
> @@ -107,7 +114,7 @@ DEFINE_IFUNC(static, int, x86_rng_store, (u_long *buf),
> static)
> else if (has_rdrand)
> return (x86_rdrand_store);
> else
> -return (NULL);
> +return (x86_dead_store);
> }
>
> /* It is required that buf length is a multiple of sizeof(u_long). */
--
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: r349100: buildworld does not compile (ld: error: duplicate symbol: sse42_crc32c)
On Sun, 16 Jun 2019 17:49+0200, Rainer Hurling wrote: > This happens with two older cpus, Intel (Core 17-4770) and AMD (Phenom > II X6 1090T). > > Am I the only one, who observes this breakage? Thanks for any hint. No. This also happens on Intel Core i7 960. I will retry buildworld using -D WITHOUT_TESTS. -- 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: filesystem mount problem
On Sun, 21 Jul 2019 15:07-0400, AN wrote: > I don't understand why the /tmp is being mounted. It is causing problems > because when I try to run portupgrade it fails for lack of space. If I > forcibly unmount it everything breaks. tmpmfs is set to "AUTO" in /etc/defaults/rc.conf. Try setting tmpmfs="NO" in /etc/rc.conf, reboot, and see if this prohibits the creation of /tmp as a tmpfs. You can also set PKG_TMPDIR or TMPDIR to point to, say, /var/tmp. E.g.: export PKG_TMPDIR=/var/tmp or setenv PKG_TMPDIR /var/tmp > # umount -v /tmp > umount: unmount of /tmp failed: Device busy > [root@FreeBSD_13 ~]# umount -vf /tmp > tmpfs: unmount from /tmp > [root@FreeBSD_13 ~]# df -h > Filesystem SizeUsed Avail Capacity Mounted on > /dev/ada0p3428G245G149G62%/ > devfs 1.0K1.0K 0B 100%/dev > linprocfs 4.0K4.0K 0B 100%/compat/linux/proc > tmpfs 47G4.0K 47G 0%/compat/linux/dev/shm > [root@FreeBSD_13 ~]# vinagre > Unable to init server: Could not connect to 127.0.0.1: Connection refused > > (vinagre:27111): Gtk-WARNING **: 15:04:21.599: cannot open display: :0 This is expected when /tmp/.X11-unix/X0 ceases to exist, among other files within /tmp. -- 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"
r350583 - init died (signal 6, exit 0)
Hi, Has anyone else noticed the kernel being unable to spawn init lately? All I get is: init died (signal 6, exit 0) panic: Going nowhere without my init! /sbin/init hasn't had any changes in 4 months, and is present in /sbin in the new BE. I've tried and failed in VBox at home this weekend, and in Citrix Hypervisor 8 at $WORK today. I think we can rule out the hypervisors. Last known working revision is r350400. There are numerous kernel changes between r350400 and r350583. I'll try each revision in succession and see if I can identify any culprits. -- 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: r350484 and ASLR enabled - init died (signal 6, exit 0)
On Mon, 5 Aug 2019 06:02-0700, David Wolfskill wrote:
> On Mon, Aug 05, 2019 at 02:53:04PM +0200, Trond Endrestøl wrote:
> > Hi,
> >
> > Has anyone else noticed the kernel being unable to spawn init lately?
> >
> > All I get is:
> >
> > init died (signal 6, exit 0)
> > panic: Going nowhere without my init!
> >
> > /sbin/init hasn't had any changes in 4 months, and is present in /sbin
> > in the new BE.
> >
> > I've tried and failed in VBox at home this weekend, and in Citrix
> > Hypervisor 8 at $WORK today. I think we can rule out the hypervisors.
> >
> > Last known working revision is r350400.
> >
> > There are numerous kernel changes between r350400 and r350583. I'll
> > try each revision in succession and see if I can identify any
> > culprits.
> > ...
>
> I have not seen the behavior in question; my last update was from
> r350566 to r350584 (and was quite uneventful).
>
> In each case, a "real machine" was used (laptop & a build machine).
After more trial and error, r350484 is the culprit for Citrix
Hypervisor 8.
I have these lines in /boot/loader.conf:
kern.elf32.aslr.enable="1"
kern.elf32.aslr.pie_enable="1"
kern.elf64.aslr.enable="1"
kern.elf64.aslr.pie_enable="1"
r350483 works like a charm, and so does r350484 iff I disable ASLR.
Reenabling ASLR and setting kern.elf{64,32}.aslr.stack_gap to zero has
no effect.
I've cc'd kib@ on this one.
I'm going home and see if VBox 6.0.10 exhibits the same behaviour.
--
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: r350484 and ASLR enabled - init died (signal 6, exit 0)
On Mon, 5 Aug 2019 22:23+0300, Konstantin Belousov wrote: > On Mon, Aug 05, 2019 at 08:10:43PM +0200, Trond Endrestøl wrote: > > > I'm going home and see if VBox 6.0.10 exhibits the same behaviour. > > Try r350608. There was a mis-merge in the committed patch (more serious > part), and some limits were not applied, which I did not see in my > testing due to the mismatch between stock FreeBSD and my testing > environment. I'm now at r350609, and booting with ASLR enabled works in VBox. I'll try the Citrix Hypervisor VM tomorrow Thank you, Konstantin. -- 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: r350484 and ASLR enabled - init died (signal 6, exit 0)
On Mon, 5 Aug 2019 22:32+0200, Trond Endrestøl wrote: > On Mon, 5 Aug 2019 22:23+0300, Konstantin Belousov wrote: > > > On Mon, Aug 05, 2019 at 08:10:43PM +0200, Trond Endrestøl wrote: > > > > > I'm going home and see if VBox 6.0.10 exhibits the same behaviour. > > > > Try r350608. There was a mis-merge in the committed patch (more serious > > part), and some limits were not applied, which I did not see in my > > testing due to the mismatch between stock FreeBSD and my testing > > environment. > > I'm now at r350609, and booting with ASLR enabled works in VBox. > I'll try the Citrix Hypervisor VM tomorrow Back at $WORK, I noticed a repeat of the initial issue which persisted until I forcefully shutdown this longrunning VM, now running r350624. Upon cold start, the VM behaved as expected, making me think there might be one or more uninitialised variables at play or some odd behaviour by the hypervisors I use. -- 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: hang up with r352239 and r352386 with i5-7500
On Mon, 16 Sep 2019 20:09+0900, Masachika ISHIZUKA wrote: > My machine (with core i5-7500) is hangup when loading i915kms.ko > on r352239 and r352386 (1300047). > This machine was working good with r351728 (1300044). > > /etc/rc.conf has the following line. > kld_list="i915kms.ko" Pardon the intrusion. What happens if you add drm2.ko and/or switch to absolute paths? This is what I had to put in my /etc/rc.conf for a Dell Latitude E5530 to get rid of the message of drm2 being deprecated: kld_list="/boot/modules/drm2.ko /boot/modules/i915kms.ko" -- 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: pkg/ports system terribly messed up?
On Tue, 30 Sep 2014 08:13+0200, O. Hartmann wrote: > > Hello. > > I just made the last update of the ports yesterday (I use portmaster -da > performing this > task) and obviously or superficially everything went all right. > > I'm running on the boxes in question most recent CURRENT. > > On one system, a subsequent start of updating ports starts to freak out when > updateing > lang/gcc: it loops over and over on some ports already updated, especially > devel/binutils, but the port looping on isn't specific and varies. > > On every CURRENT box I tried this morning to update the ports again, I find > this > frsutrating message (depends on installation, but it seems in principal the > same, only > the affected ports in dependency chain varies): > > ===>>> Gathering distinfo list for installed ports > > ===>>> Starting check of installed ports for available updates > ===>>> Launching child to update openldap-sasl-client-2.4.39_2 to > openldap-sasl-client-2.4.40 > > ===>>> All >> openldap-sasl-client-2.4.39_2 (1/1) > > ===>>> Currently installed version: openldap-sasl-client-2.4.39_2 > ===>>> Port directory: /usr/ports/net/openldap24-sasl-client > > ===>>> Launching 'make checksum' for net/openldap24-sasl-client in background > ===>>> Gathering dependency list for net/openldap24-sasl-client from ports > ===>>> Launching child to install > net/openldap24-sasl-client/../../ports-mgmt/pkg > > ===>>> All >> openldap-sasl-client-2.4.39_2 >> > net/openldap24-sasl-client/../../ports-mgmt/pkg (2/2) > > ===>>> Port directory: > /usr/ports/net/openldap24-sasl-client/../../ports-mgmt/pkg > > > ===>>> Update for net/openldap24-sasl-client/../../ports-mgmt/pkg failed > ===>>> Aborting update > > ===>>> Update for openldap-sasl-client-2.4.39_2 failed > ===>>> Aborting update > > You have new mail. > > > This isn't, so far, OpenLDAP specific, on other systems without LDAP the > update fails on > another port. > > Oliver What happens if you manually upgrade ports-mgmt/pkg, assuming it's out of date? I've noticed running make missing from /usr/ports/ports-mgmt/pkg produces some interesting results _only_ when pkg is up-to-date: trond@enterprise:/usr/ports/ports-mgmt/pkg>make missing /usr/ports/workdirs/usr/ports/ports-mgmt/pkg/work/pkg-1.3.8/src/pkg-static: not found *** [missing] Error code 127 Stop in /usr/ports/ports-mgmt/pkg. Using portupgrade, I finally created a script to help me get past some of the deficiency of the duo pkg and portupgrade. The script checks to see if ports-mgmt/pkg needs an upgrade and upgrades pkg before proceeding with the remaining outdated ports. As portupgrade doesn't always properly install _new_ dependencies, my script also checks for any missing ports and installs them prior to upgrading the outdated ports. If anyone's interested, here's my script: http://ximalas.info/~trond/create-zfs/canmount/upgrade-outdated-ports.sh -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pkg/ports system terribly messed up?
On Tue, 30 Sep 2014 08:40+0200, Trond Endrestøl wrote: > On Tue, 30 Sep 2014 08:13+0200, O. Hartmann wrote: > > > > > Hello. > > > > I just made the last update of the ports yesterday (I use portmaster -da > > performing this > > task) and obviously or superficially everything went all right. > > > > I'm running on the boxes in question most recent CURRENT. > > > > On one system, a subsequent start of updating ports starts to freak out > > when updateing > > lang/gcc: it loops over and over on some ports already updated, especially > > devel/binutils, but the port looping on isn't specific and varies. > > > > On every CURRENT box I tried this morning to update the ports again, I find > > this > > frsutrating message (depends on installation, but it seems in principal the > > same, only > > the affected ports in dependency chain varies): > > > > ===>>> Gathering distinfo list for installed ports > > > > ===>>> Starting check of installed ports for available updates > > ===>>> Launching child to update openldap-sasl-client-2.4.39_2 to > > openldap-sasl-client-2.4.40 > > > > ===>>> All >> openldap-sasl-client-2.4.39_2 (1/1) > > > > ===>>> Currently installed version: openldap-sasl-client-2.4.39_2 > > ===>>> Port directory: /usr/ports/net/openldap24-sasl-client > > > > ===>>> Launching 'make checksum' for net/openldap24-sasl-client in > > background > > ===>>> Gathering dependency list for net/openldap24-sasl-client from ports > > ===>>> Launching child to install > > net/openldap24-sasl-client/../../ports-mgmt/pkg > > > > ===>>> All >> openldap-sasl-client-2.4.39_2 >> > > net/openldap24-sasl-client/../../ports-mgmt/pkg (2/2) > > > > ===>>> Port directory: > > /usr/ports/net/openldap24-sasl-client/../../ports-mgmt/pkg > > > > > > ===>>> Update for net/openldap24-sasl-client/../../ports-mgmt/pkg failed > > ===>>> Aborting update > > > > ===>>> Update for openldap-sasl-client-2.4.39_2 failed > > ===>>> Aborting update > > > > You have new mail. > > > > > > This isn't, so far, OpenLDAP specific, on other systems without LDAP the > > update fails on > > another port. > > > > Oliver > > What happens if you manually upgrade ports-mgmt/pkg, assuming it's out > of date? > > I've noticed running make missing from /usr/ports/ports-mgmt/pkg > produces some interesting results _only_ when pkg is up-to-date: > > trond@enterprise:/usr/ports/ports-mgmt/pkg>make missing > /usr/ports/workdirs/usr/ports/ports-mgmt/pkg/work/pkg-1.3.8/src/pkg-static: > not found > *** [missing] Error code 127 > > Stop in /usr/ports/ports-mgmt/pkg. > > Using portupgrade, I finally created a script to help me get past some Oh, that's bad wording on my part, it should read: I'm only using portupgrade, so I finally created a script to help me get past some > of the deficiency of the duo pkg and portupgrade. The script checks to > see if ports-mgmt/pkg needs an upgrade and upgrades pkg before > proceeding with the remaining outdated ports. As portupgrade doesn't > always properly install _new_ dependencies, my script also checks for > any missing ports and installs them prior to upgrading the outdated > ports. If anyone's interested, here's my script: > http://ximalas.info/~trond/create-zfs/canmount/upgrade-outdated-ports.sh -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!
On Sat, 1 Nov 2014 18:03+0100, Dag-Erling Smørgrav wrote: > Ian Lepore writes: > > Dag-Erling Smørgrav writes: > > > I think you misremember. It is impossible to guarantee that the > > > system will always have enough entropy right from the start. > > > Servers, desktops and laptops will be fine, but embedded systems and > > > VMs might not be able to unblock until they've seen some network > > > traffic or loaded a chunk of pre-generated entropy (which is what > > > /etc/rc.d/random does). This is especially true for embedded > > > systems that don't have enumerable buses and rely on fdt(4) to > > > create the device tree at boot time. > > And what about devices that are not connected to a network? > > They still get entropy from interrupts and disk I/O. > > > Oh well, I'm sure I'll be able to find some hacks to undo whatever > > y'all have done now, and we'll just have to carry them as local diffs > > forever. > > How about you take a ing chill pill and read what I wrote earlier: > this is a regression which we will try to fix. But the bottom line is > that the entropy has to come from *somewhere* and if whatever dinky > device you're playing with doesn't provide any, that's not our fault. > Buy http://www.amazon.com/dp/0833030477 and type it in, or something. > We're engineers, not magicians. Sirs, please control your temper, at least while on a public mailing list. What good does the file /entropy do if boot up is delayed everytime during "Writing entropy file:"? > (or maybe you can do something constructive, like write code to harvest > entropy from background noise in ADCs, unused WiFi / 4G / BT radios or > whatever else is available and submit a patch) -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
/usr/sbin/cron and /usr/sbin/fifolog_{create,reader,writer} winds up in ${DESTDIR}/ during installworld, as of r275212
Something's wrong in base/head when /usr/sbin/cron and
/usr/sbin/fifolog_{create,reader,writer} winds up in ${DESTDIR}/
during installworld.
Seen on amd64 as of r275212, both with and without DESTDIR set.
Is it a pilot error on my part?
--
+---++
| 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
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r282420 omits /usr/lib/private/libssh_p.a
make delete-old can't finish off the /usr/lib/private directory due to the presence of libssh_p.a. Manual intervention is required UFN. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Build world problem r284331 > r284377
On Sun, 14 Jun 2015 11:48+0300, Ivan Klymenko wrote: > [snip] Try to revert to r284342, e.g. svn up -r284342 /usr/src. That should get you going until things are sorted out with r284345 being the problematic commit. BTW, the commit log for r284345 states: Off by default [...] It doesn't seem to be the case. Correct me if I'm wrong. -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Obsolete files in base/head
e's dated Mar 8 2014. /usr/share/man/man8/mount_fusefs.8.gz is installed and is current. Also, I believe these directories should be removed during delete-old: /usr/local/debug/usr/lib/clang/3.5.1 /usr/local/debug/usr/lib/clang/3.6.0 -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
Hi, Am I the only one who fails to build recent base/head (r284673) on pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs. Under the above circumstances, I got: --- rescue.all__D --- rescue sh: rescue: not found *** [rescue] Error code 127 make[5]: stopped in /usr/obj/usr/src/rescue/rescue 1 error Yes, a ran a four-way build, -j 4. Maybe I should switch to single job builds. Also, I see at lot of: --- gnu/lib/libssp/libssp_nonshared__PL --- ERROR: ctfconvert: rc = -1 No entry found [dwarf_next_cu_header_c(61)] The one above happened very early in "stage 4.2: building libraries". Complete build log (23 MiB) is available at http://ximalas.info/~trond/base-head-201506/make-buildworld-buildkernel-20150621-r284673.txt. Using a one month old base/head (r284273) appears to get the job done, and I'm using that BE to build r284675 ATM, using serial jobs. I haven't ruled out any pilot error on my behalf, or maybe my working copy of base/head is on the fritz. My /etc/make.conf looks like this: KERNCONF=VBOX # DTrace for both base and ports. See https://wiki.freebsd.org/DTrace/KernelSupport. STRIP= CFLAGS+=-fno-omit-frame-pointer WITH_CTF=1 WITH_PKGNG=yes WITH_BDB6_PERMITTED=yes WITH_SSP_PORTS=yes WRKDIRPREFIX=/usr/ports/workdirs TEX_DEFAULT=texlive DEFAULT_VERSIONS=apache=2.4 bdb=5 firebird=2.5 gcc=4.8 lua=5.2 mysql=5.6 perl5=5.20 pgsql=9.4 php=5.6 python=2.7 python2=2.7 python3=3.4 ruby=2.2 tcltk=8.6 My /etc/src.conf looks like this: CC=clang CXX=clang++ CPP=clang-cpp NO_WERROR= WERROR= WITH_CLANG_EXTRAS=yes WITH_CLANG_FULL=yes WITH_CTF=yes WITH_GCC=yes WITH_GNUCXX=yes WITH_LIBCPLUSPLUS=yes WITH_LLDB=yes WITH_NAND=yes My /etc/src-env.conf exists, but empty. -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
On Sun, 21 Jun 2015 13:05-0700, Garrett Cooper wrote: > > CC=clang > > CXX=clang++ > > CPP=clang-cpp > > Hi Trond, > You need to remove these lines. They shouldn?t have been set before or > after the commits from projects/bmake . > Thanks, Ah. That's good to know. Pilot error, indeed. They were probably leftovers from when we could choose between gcc and clang. I'll remove those lines and see what happens. 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
On Mon, 22 Jun 2015 09:41-0700, Jason Evans wrote: > On Jun 21, 2015, at 1:05 PM, Garrett Cooper wrote: > > On Jun 21, 2015, at 3:16, Trond Endrestøl > > wrote: > >> Am I the only one who fails to build recent base/head (r284673) on > >> pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs. > > > > ... > > > >> CC=clang > >> CXX=clang++ > >> CPP=clang-cpp > > > > You need to remove these lines. They shouldn?t have been set before or > > after the commits from projects/bmake . > > I hit the same build failure, and I don't have any of those lines in my > /etc/make.conf. Mine is: > > STRIP= > > # added by use.perl 2013-01-21 16:11:13 > PERL_VERSION=5.12.4 > WITH_PKGNG=yes > > The STRIP= definition appears to have no impact with regard to the build > failure. > > I routinely do multiple buildworld/installworld cycles when updating, so I am > pretty sure that this is a self bootstrap failure; buildworld/installworld > succeeds the first time, but not the second time. r283923 does not have the > problem, so this was introduced sometime in the past three weeks. I concur. DTrace support is b0rken. I installed a fresh VM at work using Glen's recent base/head snapshot, 20150618 r284544. I created an /etc/src.conf file with only WITH_CTF=yes. I got hold of base/head r284678, started a -j4 buildworld + buildkernel, and immediately ctfconvert started complaining about nothing to do, i.e.: ERROR: ctfconvert: rc = -1 No entry found [dwarf_next_cu_header_c(61)] Same result with -j1. I probably forgot to mention earlier, after my problems began last week, I always wiped /usr/obj clean before building again. I haven't activated dtraceall.ko using /boot/loader.conf, but I guess those that dare, end up with a kernel panic. I certainly did that last week. -- +-------++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
On Mon, 22 Jun 2015 18:14-, Mark Johnston wrote: > On Mon, Jun 22, 2015 at 08:00:13PM +0200, Trond Endrestøl wrote: > > > > I concur. DTrace support is b0rken. > > > > I installed a fresh VM at work using Glen's recent base/head snapshot, > > 20150618 r284544. I created an /etc/src.conf file with only > > WITH_CTF=yes. I got hold of base/head r284678, started a -j4 > > buildworld + buildkernel, and immediately ctfconvert started > > complaining about nothing to do, i.e.: > > > > ERROR: ctfconvert: rc = -1 No entry found [dwarf_next_cu_header_c(61)] > > > > Same result with -j1. > > These warnings are benign and are the result of compiling with WITH_CTF > and without debug info. Compiling with WITH_DEBUG_FILES or > DEBUG_FLAGS=-g will allow CTF to be generated, but its absence shouldn't > cause any problems (aside from these annoying warnings). Thanks for clarifying. > > I probably forgot to mention earlier, after my problems began last > > week, I always wiped /usr/obj clean before building again. > > > > I haven't activated dtraceall.ko using /boot/loader.conf, but I guess > > those that dare, end up with a kernel panic. I certainly did that last > > week. > > Can you elaborate on this? There don't seem to be any reports of such a > panic, and I certainly dare to load dtraceall.ko on head. :) It was sometime last week. I probably got a bad build due to the use of my highly customised bash environment. The resulting world would take 5.51 times longer to build another clean world and kernel, and fail, with the norm being about one and a half hour on this hardware, i7-960 @ 3.2 GHz. Thus, I reverted to a BE running r284273 from earlier this month, and got away with that. I have now switched to standard FreeBSD csh enviroment, and r284703 doesn't not have a problem loading dtraceall.ko. Sorry for all the noise. -- +-------++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Problems with building rescue are solved
Hi, I guess both the instructions for enabling DTrace, https://wiki.freebsd.org/DTrace/KernelSupport and r284356 are to blame. I suggest the wiki be amended with: STRIP=: or some other innocuous command like 'echo --'. Otherwise, "$(STRIP) rescue" in /usr/obj/usr/src/rescue/rescue/rescue.mk will expand to simply " rescue", and thus halting make buildworld by trying to run a command not normally found in $(PATH). "make -C /usr/src/rescue/rescue -d e" came to the rescue, hah! -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Problems with building rescue are solved
On Tue, 7 Jul 2015 19:37+0200, Trond Endrestøl wrote: > Hi, > > I guess both the instructions for enabling DTrace, > https://wiki.freebsd.org/DTrace/KernelSupport and r284356 are to > blame. > > I suggest the wiki be amended with: > > STRIP=: > > or some other innocuous command like 'echo --'. On second thoughts, maybe not. It causes new problems elsewhere in the source tree. Maybe /etc/make.conf should state: STRIP= as suggested by the wiki, but /etc/src.conf or even /etc/src-env.conf should state: STRIP=strip > Otherwise, "$(STRIP) rescue" in > /usr/obj/usr/src/rescue/rescue/rescue.mk will expand to simply > " rescue", and thus halting make buildworld by trying to run a command > not normally found in $(PATH). > > "make -C /usr/src/rescue/rescue -d e" came to the rescue, hah! -- +---+----+ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: keymap set after file system decryption
On Wed, 16 Dec 2015 11:04+0100, Carsten Kunze wrote:
> Hello,
>
> according to the boot messages the keymap is set after decryption of
> file systems. I consider this as a bug. The geli decryption script
> asks for the passphrase which can't of course be input if the kaymap
> is not set.
>
> Handbook §17.12 does not mention the keymap setup. What can I do to
> make this work? (Of course I can call e.g. kbdmap in
> /etc/rc.d/geli, but this is kind of tinkering.)
I guess we who live outside the US should take into account that PCs
are initialised by firmware to the US keyboard layout and the 437 code
page, courtesy of IBM, 1981.
I'm not sure if the creators of (U)EFI has considered other keyboard
layouts and/or code pages at boot time.
A bad workaround is to copy the suitable keymap from /usr/share... to
/etc, along with /usr/sbin/kbdcontrol, and add a suitable line to one
or either of /etc/rc.d/geli{,2}, e.g.:
/etc/kbdcontrol -l /etc/german.iso.kbd
kbdcontrol is linked only to libc:
$ ldd `which kbdcontrol`
/usr/sbin/kbdcontrol:
libc.so.7 => /lib/libc.so.7 (0x800827000)
--
+---++
| 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: Re: keymap set after file system decryption
On Wed, 16 Dec 2015 16:34-0800, Kevin Oberman wrote:
> On Wed, Dec 16, 2015 at 7:34 AM, Carsten Kunze
> wrote:
>
> > Trond Endrestøl wrote:
> >
> > > I guess we who live outside the US should take into account that PCs
> > > are initialised by firmware to the US keyboard layout and the 437 code
> > > page, courtesy of IBM, 1981.
> >
> > In 1981 I had accepted this. Now it's simply a bug and I wonder it has
> > not been fixed in 22 years. I'll file a bug report.
> >
> > > I'm not sure if the creators of (U)EFI has considered other keyboard
> > > layouts and/or code pages at boot time.
> >
> > I don't care for the BIOS here, the OS has to take care of it. It may be
> > ok that at the boot prompt only US keymap is set. But when the rc scripts
> > are running the keymap must be set correctly (as one of the first actions).
> >
> > > A bad workaround is to copy the suitable keymap from /usr/share... to
> > > /etc, along with /usr/sbin/kbdcontrol, and add a suitable line to one
> > > or either of /etc/rc.d/geli{,2}, e.g.:
> > >
> > > /etc/kbdcontrol -l /etc/german.iso.kbd
> > >
> > > kbdcontrol is linked only to libc:
> > >
> > > $ ldd `which kbdcontrol`
> > > /usr/sbin/kbdcontrol:
> > > libc.so.7 => /lib/libc.so.7 (0x800827000)
> >
> > In my case it's simpler since I have /usr in /, but as you descripted
> > kbdcontrol must be in /sbin and the maps in /etc in the future.
> >
> > Carsten
> >
>
> You can specify your default keymap in your kernel config file.
> ATKBD_DFLT_KEYBD. It's possible that you might be able to set it in
> /boot/loader.conf, as well, but I'm not too sure of this. See atkbd(4).
I can confirm that neither ATKBD_DFLT_KEYMAP nor UKBD_DFLT_KEYMAP, nor
SC_DFLT_FONT for that matter, works as intended.
I have never had any success with:
options SC_DFLT_FONT
makeoptions SC_DFLT_FONT=iso
options UKBD_DFLT_KEYMAP
makeoptions UKBD_DFLT_KEYMAP=norwegian.iso
options ATKBD_DFLT_KEYMAP
makeoptions ATKBD_DFLT_KEYMAP=norwegian.iso
Please prove me wrong.
--
+---++
| 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: Re: keymap set after file system decryption
On Thu, 17 Dec 2015 11:56+0100, Trond Endrestøl wrote:
> On Wed, 16 Dec 2015 16:34-0800, Kevin Oberman wrote:
>
> > On Wed, Dec 16, 2015 at 7:34 AM, Carsten Kunze
> > wrote:
> >
> > > Trond Endrestøl wrote:
> > >
> > > > I guess we who live outside the US should take into account that PCs
> > > > are initialised by firmware to the US keyboard layout and the 437 code
> > > > page, courtesy of IBM, 1981.
> > >
> > > In 1981 I had accepted this. Now it's simply a bug and I wonder it has
> > > not been fixed in 22 years. I'll file a bug report.
> > >
> > > > I'm not sure if the creators of (U)EFI has considered other keyboard
> > > > layouts and/or code pages at boot time.
> > >
> > > I don't care for the BIOS here, the OS has to take care of it. It may be
> > > ok that at the boot prompt only US keymap is set. But when the rc scripts
> > > are running the keymap must be set correctly (as one of the first
> > > actions).
> > >
> > > > A bad workaround is to copy the suitable keymap from /usr/share... to
> > > > /etc, along with /usr/sbin/kbdcontrol, and add a suitable line to one
> > > > or either of /etc/rc.d/geli{,2}, e.g.:
> > > >
> > > > /etc/kbdcontrol -l /etc/german.iso.kbd
> > > >
> > > > kbdcontrol is linked only to libc:
> > > >
> > > > $ ldd `which kbdcontrol`
> > > > /usr/sbin/kbdcontrol:
> > > > libc.so.7 => /lib/libc.so.7 (0x800827000)
> > >
> > > In my case it's simpler since I have /usr in /, but as you descripted
> > > kbdcontrol must be in /sbin and the maps in /etc in the future.
> > >
> > > Carsten
> > >
> >
> > You can specify your default keymap in your kernel config file.
> > ATKBD_DFLT_KEYBD. It's possible that you might be able to set it in
> > /boot/loader.conf, as well, but I'm not too sure of this. See atkbd(4).
>
> I can confirm that neither ATKBD_DFLT_KEYMAP nor UKBD_DFLT_KEYMAP, nor
> SC_DFLT_FONT for that matter, works as intended.
>
> I have never had any success with:
>
> options SC_DFLT_FONT
> makeoptions SC_DFLT_FONT=iso
>
> options UKBD_DFLT_KEYMAP
> makeoptions UKBD_DFLT_KEYMAP=norwegian.iso
>
> options ATKBD_DFLT_KEYMAP
> makeoptions ATKBD_DFLT_KEYMAP=norwegian.iso
>
> Please prove me wrong.
A recent run in stable/10 using r292334, resulted in:
--- ukbd.o ---
cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
-Wmissing-include-dirs -fdiagnostics-show-option
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I.
-I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2
/usr/src/sys/dev/usb/input/ukbd.c
/usr/src/sys/dev/usb/input/ukbd.c:1216:18: error: use of undeclared identifier
'key_map'
sc->sc_keymap = key_map;
^
/usr/src/sys/dev/usb/input/ukbd.c:1217:18: error: use of undeclared identifier
'accent_map'
sc->sc_accmap = accent_map;
^
--
+---++
| 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: Re: keymap set after file system decryption
On Thu, 17 Dec 2015 12:21+0100, Trond Endrestøl wrote:
> On Thu, 17 Dec 2015 11:56+0100, Trond Endrestøl wrote:
>
> > On Wed, 16 Dec 2015 16:34-0800, Kevin Oberman wrote:
> >
> > > On Wed, Dec 16, 2015 at 7:34 AM, Carsten Kunze
> > > wrote:
> > >
> > > > Trond Endrestøl wrote:
> > > >
> > > > > I guess we who live outside the US should take into account that PCs
> > > > > are initialised by firmware to the US keyboard layout and the 437 code
> > > > > page, courtesy of IBM, 1981.
> > > >
> > > > In 1981 I had accepted this. Now it's simply a bug and I wonder it has
> > > > not been fixed in 22 years. I'll file a bug report.
> > > >
> > > > > I'm not sure if the creators of (U)EFI has considered other keyboard
> > > > > layouts and/or code pages at boot time.
> > > >
> > > > I don't care for the BIOS here, the OS has to take care of it. It may
> > > > be
> > > > ok that at the boot prompt only US keymap is set. But when the rc
> > > > scripts
> > > > are running the keymap must be set correctly (as one of the first
> > > > actions).
> > > >
> > > > > A bad workaround is to copy the suitable keymap from /usr/share... to
> > > > > /etc, along with /usr/sbin/kbdcontrol, and add a suitable line to one
> > > > > or either of /etc/rc.d/geli{,2}, e.g.:
> > > > >
> > > > > /etc/kbdcontrol -l /etc/german.iso.kbd
> > > > >
> > > > > kbdcontrol is linked only to libc:
> > > > >
> > > > > $ ldd `which kbdcontrol`
> > > > > /usr/sbin/kbdcontrol:
> > > > > libc.so.7 => /lib/libc.so.7 (0x800827000)
> > > >
> > > > In my case it's simpler since I have /usr in /, but as you descripted
> > > > kbdcontrol must be in /sbin and the maps in /etc in the future.
> > > >
> > > > Carsten
> > > >
> > >
> > > You can specify your default keymap in your kernel config file.
> > > ATKBD_DFLT_KEYBD. It's possible that you might be able to set it in
> > > /boot/loader.conf, as well, but I'm not too sure of this. See atkbd(4).
> >
> > I can confirm that neither ATKBD_DFLT_KEYMAP nor UKBD_DFLT_KEYMAP, nor
> > SC_DFLT_FONT for that matter, works as intended.
> >
> > I have never had any success with:
> >
> > options SC_DFLT_FONT
> > makeoptions SC_DFLT_FONT=iso
> >
> > options UKBD_DFLT_KEYMAP
> > makeoptions UKBD_DFLT_KEYMAP=norwegian.iso
> >
> > options ATKBD_DFLT_KEYMAP
> > makeoptions ATKBD_DFLT_KEYMAP=norwegian.iso
> >
> > Please prove me wrong.
>
> A recent run in stable/10 using r292334, resulted in:
>
> --- ukbd.o ---
> cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls
> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
> -Wmissing-include-dirs -fdiagnostics-show-option
> -Wno-error-tautological-compare -Wno-error-empty-body
> -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I.
> -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt
> -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx
> -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
> -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2
> /usr/src/sys/dev/usb/input/ukbd.c
> /usr/src/sys/dev/usb/input/ukbd.c:1216:18: error: use of undeclared
> identifier 'key_map'
> sc->sc_keymap = key_map;
> ^
> /usr/src/sys/dev/usb/input/ukbd.c:1217:18: error: use of undeclared
> identifier 'accent_map'
> sc->sc_accmap = accent_map;
> ^
/usr/obj/usr/src/sys/KERNEL/{at,u}kbdmap.h er both empty.
The problem seems to be related to kbdcontrol.
kbdcontrol(8) is run as /usr/sbin/kbdcontrol -L ${ATKBD_DFLT_KEYMAP}
and as /usr/sbin/kbdcontrol -L ${UKBD_DFLT_KEYMAP}, during
buildkernel.
The option -L, unlike option -l (lowercase ell), does not search the
normal directories, e.g. /usr/share/syscons/keymaps.
By removing {at,u}kbdmap.h from /usr/obj/usr/src/sys/KERNEL and
changing to
options ATKBD_DFLT_KEYMAP
makeoptions ATKBD_DFLT_KEYMAP=/usr/share/syscons/keymaps/norwegian.iso.kbd
opt
Re: keymap set after file system decryption
On Thu, 17 Dec 2015 12:51+0100, Claude Buisson wrote:
> On 12/17/2015 12:21, Trond Endrestøl wrote:
> > On Thu, 17 Dec 2015 11:56+0100, Trond Endrestøl wrote:
> >
> > > On Wed, 16 Dec 2015 16:34-0800, Kevin Oberman wrote:
> > >
> > > > On Wed, Dec 16, 2015 at 7:34 AM, Carsten Kunze
> > > > wrote:
> > > >
> > > > > Trond Endrestøl wrote:
> > > > >
> > > > > > I guess we who live outside the US should take into account that PCs
> > > > > > are initialised by firmware to the US keyboard layout and the 437
> > > > > > code
> > > > > > page, courtesy of IBM, 1981.
> > > > >
> > > > > In 1981 I had accepted this. Now it's simply a bug and I wonder it
> > > > > has
> > > > > not been fixed in 22 years. I'll file a bug report.
> > > > >
> > > > > > I'm not sure if the creators of (U)EFI has considered other keyboard
> > > > > > layouts and/or code pages at boot time.
> > > > >
> > > > > I don't care for the BIOS here, the OS has to take care of it. It may
> > > > > be
> > > > > ok that at the boot prompt only US keymap is set. But when the rc
> > > > > scripts
> > > > > are running the keymap must be set correctly (as one of the first
> > > > > actions).
> > > > >
> > > > > > A bad workaround is to copy the suitable keymap from /usr/share...
> > > > > > to
> > > > > > /etc, along with /usr/sbin/kbdcontrol, and add a suitable line to
> > > > > > one
> > > > > > or either of /etc/rc.d/geli{,2}, e.g.:
> > > > > >
> > > > > > /etc/kbdcontrol -l /etc/german.iso.kbd
> > > > > >
> > > > > > kbdcontrol is linked only to libc:
> > > > > >
> > > > > > $ ldd `which kbdcontrol`
> > > > > > /usr/sbin/kbdcontrol:
> > > > > > libc.so.7 => /lib/libc.so.7 (0x800827000)
> > > > >
> > > > > In my case it's simpler since I have /usr in /, but as you descripted
> > > > > kbdcontrol must be in /sbin and the maps in /etc in the future.
> > > > >
> > > > > Carsten
> > > > >
> > > >
> > > > You can specify your default keymap in your kernel config file.
> > > > ATKBD_DFLT_KEYBD. It's possible that you might be able to set it in
> > > > /boot/loader.conf, as well, but I'm not too sure of this. See atkbd(4).
> > >
> > > I can confirm that neither ATKBD_DFLT_KEYMAP nor UKBD_DFLT_KEYMAP, nor
> > > SC_DFLT_FONT for that matter, works as intended.
> > >
> > > I have never had any success with:
> > >
> > > options SC_DFLT_FONT
> > > makeoptions SC_DFLT_FONT=iso
> > >
> > > options UKBD_DFLT_KEYMAP
> > > makeoptions UKBD_DFLT_KEYMAP=norwegian.iso
> > >
> > > options ATKBD_DFLT_KEYMAP
> > > makeoptions ATKBD_DFLT_KEYMAP=norwegian.iso
> > >
> > > Please prove me wrong.
> >
> > A recent run in stable/10 using r292334, resulted in:
> >
> > --- ukbd.o ---
> > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls
> > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
> > -Wmissing-include-dirs -fdiagnostics-show-option
> > -Wno-error-tautological-compare -Wno-error-empty-body
> > -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I.
> > -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt
> > -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h
> > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx
> > -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
> > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2
> > /usr/src/sys/dev/usb/input/ukbd.c
> > /usr/src/sys/dev/usb/input/ukbd.c:1216:18: error: use of undeclared
> > identifier 'key_map'
> > sc->sc_keymap = key_map;
> > ^
> > /usr/src/sys/dev/usb/input/ukbd.c:1217:18: error: use of undeclared
> > identifier 'accent_map'
> > sc->sc_accmap = acce
Re: keymap set after file system decryption
On Thu, 17 Dec 2015 13:56+0100, Trond Endrestøl wrote:
> On Thu, 17 Dec 2015 12:51+0100, Claude Buisson wrote:
>
> > On 12/17/2015 12:21, Trond Endrestøl wrote:
> > > On Thu, 17 Dec 2015 11:56+0100, Trond Endrestøl wrote:
> > >
> > > > On Wed, 16 Dec 2015 16:34-0800, Kevin Oberman wrote:
> > > >
> > > > > On Wed, Dec 16, 2015 at 7:34 AM, Carsten Kunze
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Trond Endrestøl wrote:
> > > > > >
> > > > > > > I guess we who live outside the US should take into account that
> > > > > > > PCs
> > > > > > > are initialised by firmware to the US keyboard layout and the 437
> > > > > > > code
> > > > > > > page, courtesy of IBM, 1981.
> > > > > >
> > > > > > In 1981 I had accepted this. Now it's simply a bug and I wonder it
> > > > > > has
> > > > > > not been fixed in 22 years. I'll file a bug report.
> > > > > >
> > > > > > > I'm not sure if the creators of (U)EFI has considered other
> > > > > > > keyboard
> > > > > > > layouts and/or code pages at boot time.
> > > > > >
> > > > > > I don't care for the BIOS here, the OS has to take care of it. It
> > > > > > may
> > > > > > be
> > > > > > ok that at the boot prompt only US keymap is set. But when the rc
> > > > > > scripts
> > > > > > are running the keymap must be set correctly (as one of the first
> > > > > > actions).
> > > > > >
> > > > > > > A bad workaround is to copy the suitable keymap from /usr/share...
> > > > > > > to
> > > > > > > /etc, along with /usr/sbin/kbdcontrol, and add a suitable line to
> > > > > > > one
> > > > > > > or either of /etc/rc.d/geli{,2}, e.g.:
> > > > > > >
> > > > > > > /etc/kbdcontrol -l /etc/german.iso.kbd
> > > > > > >
> > > > > > > kbdcontrol is linked only to libc:
> > > > > > >
> > > > > > > $ ldd `which kbdcontrol`
> > > > > > > /usr/sbin/kbdcontrol:
> > > > > > > libc.so.7 => /lib/libc.so.7 (0x800827000)
> > > > > >
> > > > > > In my case it's simpler since I have /usr in /, but as you
> > > > > > descripted
> > > > > > kbdcontrol must be in /sbin and the maps in /etc in the future.
> > > > > >
> > > > > > Carsten
> > > > > >
> > > > >
> > > > > You can specify your default keymap in your kernel config file.
> > > > > ATKBD_DFLT_KEYBD. It's possible that you might be able to set it in
> > > > > /boot/loader.conf, as well, but I'm not too sure of this. See
> > > > > atkbd(4).
> > > >
> > > > I can confirm that neither ATKBD_DFLT_KEYMAP nor UKBD_DFLT_KEYMAP, nor
> > > > SC_DFLT_FONT for that matter, works as intended.
> > > >
> > > > I have never had any success with:
> > > >
> > > > options SC_DFLT_FONT
> > > > makeoptions SC_DFLT_FONT=iso
> > > >
> > > > options UKBD_DFLT_KEYMAP
> > > > makeoptions UKBD_DFLT_KEYMAP=norwegian.iso
> > > >
> > > > options ATKBD_DFLT_KEYMAP
> > > > makeoptions ATKBD_DFLT_KEYMAP=norwegian.iso
> > > >
> > > > Please prove me wrong.
> > >
> > > A recent run in stable/10 using r292334, resulted in:
> > >
> > > --- ukbd.o ---
> > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls
> > > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> > > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
> > > -Wmissing-include-dirs -fdiagnostics-show-option
> > > -Wno-error-tautological-compare -Wno-error-empty-body
> > > -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc
> > > -I.
> > > -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt
> > > -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h
>
Re: keymap set after file system decryption
On Thu, 17 Dec 2015 17:08+0100, Claude Buisson wrote: > As I said above, if you use vt, and kbdmux (which is standard and even > mandatory to be able to use Xorg), specifying the keymap for atkbd and > usbkbd is useless.. > > Have a look at PR 194744 by Oliver Pinter > > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194744) > > This PR is now more than 1 year old, and nothing has been done: people > using non-US keyboard are not popular here.. > > Claude Buisson Finally, I got it. That patch is quite trivial. Anyone with commit privs willing to commit it? Ed Maste is assigned, so unless you're too busy, Ed, would you commit this patch to CURRENT and MFC/MFH as appropriate? -- +---++ | 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: EFI zfs loader and beadm?
On Thu, 10 Mar 2016 18:38+0300, Andrey Fesenko wrote: > On Thu, Mar 10, 2016 at 6:11 PM, krad wrote: > > As Eric said you cant have /boot on a separate dataset as the whole loader > > bootstrap isnt designed too look for it on the dataset defined by bootfs. > > Remember no other datasets are mounted at that stage of the bootstrap. > > > > You could maybe bodge something by manually playing around with the bootfs > > property, symlinks and rootfs variables in the loader.conf. But why would > > you want to do this? It's more work and non standard, and will break a lot? > > > > > > > > On 10 March 2016 at 12:11, Andrey Fesenko wrote: > >> > >> On Thu, Mar 10, 2016 at 2:55 PM, krad wrote: > >> > presumably it boots now? > >> > > >> > On 10 March 2016 at 11:01, Andrey Fesenko wrote: > >> >> > >> >> On Thu, Mar 10, 2016 at 1:49 PM, krad wrote: > >> >> > Make sure you are running the latest snapshot of current or 10.3 as > >> >> > well, as > >> >> > the MFC commits were in early February for 10-stable > >> >> > > >> >> >> > >> >> >> If remove efiwpool/ROOT/init/boot and copy his content on > >> >> >> efiwpool/ROOT/init my scheme work fine too. > >> >> >> /usr /var /home and other included in BE for consistent boot system > >> >> >> (CURRENT world may not boot with kernel other rev), and old home > >> >> >> snapshot sometimes useful for backup/restore > >> >> >> ___ > >> >> > >> >> % uname -a > >> >> FreeBSD x220.efi.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r296548: > >> >> Wed Mar 9 01:16:17 MSK 2016 > >> >> root@des.local:/usr/obj/usr/src/sys/X220 amd64 > >> > > >> > > >> > >> My current working config > >> % mount > >> > >> > >> This work fine, booted, beadm create new env, activate them, see boot > >> menu and select BE. > >> > >> % beadm list > >> BEActive Mountpoint Space Created > >> init - - 420.7M 2016-03-09 02:57 > >> init0 NR / 35.9G 2016-03-10 05:00 > >> > >> If i'm add separate dataset for /boot (efiwpool/ROOT/init0/boot) > >> system not booted, efi loader (first stage) see only my pool, not > >> found /boot/loader.efi > > > > > > It probably does not matter, as bootfs have snapshots (BE), just > wanted to make it more clear (having taken significant mountpoint > /boot, /usr, /var... in zfs dataset) and was surprised why the system > does not boot > > It is clear that as long as the functionality is experimental and > under development, but would like to see where the full instructions > on its implementation / restrictions, at least as early as has been > described https://wiki.freebsd.org/RootOnZFS If you keep /boot as a separate dataset/filesystem, with efiwpool/ROOT/init0/boot as the given bootfs, then boot1.efi will not see a /boot directory inside that dataset. The files and directories from /boot will be presented as living in /, the local root directory of that dataset. You could create a /boot/boot symlink pointing to . (dot), but it's better to let /boot be part of the regular boot environment, pretty similar to what you would find on a UFS system using a separate root filesystem. -- +---++ | 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: wired memory leak at r298785
On Tue, 3 May 2016 08:27-0600, Scott Long wrote: > > > On May 3, 2016, at 12:20 AM, Mark Johnston wrote: > > > > On Mon, May 02, 2016 at 08:55:58PM -0400, Steve Wills wrote: > >> Hi, > >> > >> On 05/ 2/16 09:32 AM, Steve Wills wrote: > >>> Hi, > >>> > >>> Just did my monthly update and r298785 seems to be leaking wired memory > >>> rather rapidly. My system has 8gb of RAM and the amount of wired memory > >>> just goes up and up continuously. It takes about 12 hours before it > >>> exhausts all the RAM and sort of locks up (though shutdown still works). > >>> > >>> I also made one other change to the system at the same time as updating, > >>> which was to add another disk and configure it using ZFS. Perhaps this > >>> is a ZFS on PowerPC64 issue? My amd64 box running the same rev of > >>> CURRENT doesn't have the issue. > >>> > >> > >> I've rebooted the box and started repeatedly logging the output of > >> vmstat -m. It seems to show CAM CCB using a lot of memory and growing > >> rather rapidly. For example, here's a few lines of diff output: > >> > >> - CAM CCB 91418 182836K - 187149 2048 > >> + CAM CCB 447070 894140K - 900292 2048 > >> > >> from two samples that are 60 minutes apart. > >> > >> The box is isn't terribly busy, it's just running the monitoring daemons > >> running (snmpd, collectd), whatever web requests are hitting it (very > >> few if any), this logging process, and my shell, etc. > > > > This was causing problems on one of my amd64 systems, so it's not > > specific to powerpc64. It turns out to be due to r298004: the CCB > > allocated in cam_periph_devctl_notify() never gets freed. The patch > > below seems to fix it. > > Thanks Mark, that looks like the right fix. I’ll put it in today. > > Scott A few of my stable/10 systems simple froze due to this bug. Would it be possible for the kernel to detect when it's running low on (kernel) memory, or when it's completely out of (kernel) memory, and call on panic() only to limp away for a day or so before rebooting again? -- +---++ | 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: console in 11.0-ALPHA4
On Mon, 20 Jun 2016 11:36-0400, Ernie Luzar wrote: > I have installed 11.0-ALPHA4-i386-20160617-r301975. > > The console looks very different from all previous releases. > I find it to be harder to read. This manifests it self with the boot log > messages and the normal behavior of the virtual consoles. > > But the real problem is in the notable hesitation when switching between > virtual consoles. > > From the boot log (ie: dmesg) I see this > VT(vga): resolution 640x480 > > This must be what is making the console display so different from > previous releases. Can VT be configured to default to present the same > console behavior as previous releases before this version of 11.0 gets > published as RELEASE? If you want textmode like in the old days, add this line to /boot/loader.conf: hw.vga.textmode="1" You can also interrupt the final boot loader, and type: set hw.vga.textmode="1" Then type: menu or: boot > About the "hesitation when switching between virtual consoles" I am > thinking that this reduced performance may be caused by WITNESS being > enabled in the ALPHA series of releases. Can anyone verify that this > hesitation will not exist in the published RELEASE? The "hesitation" is sometimes hardware dependent. A GPU with a KMS driver makes it better. It's even worse in some virtualization environments, e.g. Microsoft Hyper-V. > In the boot log I get this message 16 times. > "vicontrol: setting cursor type: Inappropriate ioctl for device" > They don't seem to cause any problems that I have stumbled across. > Is anyone else getting these "NOTICE" type messages? If you decide to continue with the vt console, you should consider the following: With the new VT console in graphics mode, you don't need to load any fonts. Disable or remove any font lines from /etc/rc.conf. I haven't tried the vt console in text mode lately, so maybe you need the fonts in that case. Look for the appropriate keymap file in /usr/share/vt/keymaps/ and update the keymap line in /etc/rc.conf. Here's the Norwegian keyboard layout as an example: keymap="norwegian.iso" # Old Norwegian keymap for the sc console keymap="no"# New Norwegian keymap for the vt console -- +-------++ | 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: Weekday missing in date(1) output
On Mon, 4 Jul 2016 08:34+0200, Baptiste Daroussin wrote: > On Sun, Jul 03, 2016 at 10:17:54PM +0200, Thomas Eberhardt wrote: > > % uname -a > > FreeBSD clarence.ocp.lan 11.0-ALPHA6 FreeBSD 11.0-ALPHA6 #0 r302324: Sun > > Jul 3 21:27:41 CEST 2016 > > tho...@clarence.ocp.lan:/usr/obj/usr/src/sys/GENERIC-NODEBUG amd64 > > % env LANG=en_US.UTF-8 date > > Sunday, July 3, 2016 at 10:14:21 PM CEST > > % env LANG=de_DE.UTF-8 date > > 3. Juli 2016 um 22:14:22 CEST > > > > stable10 gives: > > % env LANG=de_DE.UTF-8 date > > So 3 Jul 2016 19:34:18 CEST > > > > Is this intentional? > > > I have readded the weekday in most locales, I will recheck all of them to > ensure > the weekday is readded everywhere it was expected nb_NO.UTF-8 and nb_NO.ISO8859-1 are also affected. -- +---+----+ | 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: CURRENT: "service netif restart" looses default route
On Wed, 5 Oct 2016 18:47+0200, O. Hartmann wrote: > > Today, I checked on two servers of ours running both a recent CURRENT (i.e. > FreeBSD > 12.0-CURRENT #43 r306701: Wed Oct 5 06:40:40 CEST 2016) via "service netif > restart" the > upcoming network and realised that the default route is lost then! > > I'm able to config the route via "service routing restart" - or manually as I > did > otherwise. But I recall that I did a simple "service netif restart" in > 11-CURRENT > recently and that worked. > > Has there been a change? What is now the official way to restart network? I see something similar on stable/11, r306639. During boot this system can't add its IPv6 default route. I need to add it manually afterwards. Note, this is on XenServer 7.0.0, so maybe the hypervisor play a certain role. Oct 4 13:23:24 [WITHHELD] kernel: add host 127.0.0.1: gateway lo0 fib 0: route already in table Oct 4 13:23:24 [WITHHELD] kernel: add net default: gateway 128.x.y.z Oct 4 13:23:24 [WITHHELD] kernel: Additional inet routing options: gateway=YES. Oct 4 13:23:24 [WITHHELD] kernel: add host ::1: gateway lo0 fib 0: route already in table Oct 4 13:23:24 [WITHHELD] kernel: add net fe80::: gateway ::1 Oct 4 13:23:24 [WITHHELD] kernel: add net ff02::: gateway ::1 Oct 4 13:23:24 [WITHHELD] kernel: add net :::0.0.0.0: gateway ::1 Oct 4 13:23:24 [WITHHELD] kernel: add net ::0.0.0.0: gateway ::1 Oct 4 13:23:24 [WITHHELD] kernel: route: writing to routing socket: Network is unreachable Oct 4 13:23:24 [WITHHELD] kernel: add net default: gateway 2001:x:y:z::1 fib 0: Network is unreachable Also, why do the startup scripts attempt to add additional routes for 127.0.0.1 and ::1? I see that behaviour on both head and stable/11. -- +---+----+ | 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: CURRENT: "service netif restart" looses default route
On Wed, 5 Oct 2016 19:50+0200, Trond Endrestøl wrote: > Oct 4 13:23:24 [WITHHELD] kernel: add net default: gateway > 2001:x:y:z::1 fib 0: Network is unreachable This problem was due to a typo, sorry for the noise. > Also, why do the startup scripts attempt to add additional routes for > 127.0.0.1 and ::1? I see that behaviour on both head and stable/11. It might be worth investigating this issue further, since this behaviour is absent on stable/10. -- +---++ | 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 crash on FreeBSD 10.3
On Fri, 14 Oct 2016 00:19-0700, Julian Elischer wrote: > I attempted to add a second partition to an existing FS pool in FreeBSD 10.3 > and the result was a crash.. > > is there anyone out there with a scratch system (10.3) (or two spare drives) > who can show me this working? > > Does it look familiar to anyone? > > The drive 'boot0' is being used as the root drive, but we are in single user > mode, so its' read-only at this stage. > > === cut-n-paste = > > [boot -s] > > [...] > > Trying to mount root from zfs:p8/image1 []... > Enter full pathname of shell or RETURN for /bin/sh: > PS1="# " > # > # > # ls /dev/gpt > boot0boot1 > # zpool attach -f p8 gpt/boot0 gpt/boot1 Do you really need to force zpool to attach the second partition? What happens if you omit the -f flag? > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address= 0x50 > fault code= supervisor read data, page not present > instruction pointer= 0x20:0x81717063 > stack pointer= 0x28:0xfe0169bfc640 > frame pointer= 0x28:0xfe0169bfc9a0 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process= 3 (txg_thread_enter) > trap number= 12 > Panic:Thought about setting the watchdog to 10 Minutes > panic: page fault > cpuid = 1 > > KDB: stack backtrace: > stack1 db_trace_self_wrapper+0x2a > kdb_backtrace+0x37 vpanic+0xf7 > panic+0x67 trap_fatal+0x264 > trap_pfault+0x1c2 > trap+0x38c > calltrap+0x8 > dsl_scan_sync+0x2f3 > spa_sync+0x328 > txg_sync_thread+0x140 > fork_exit+0x135 > fork_trampoline+0xe > > KDB: enter: panic > [ thread pid 3 tid 100328 ] > Stopped at kdb_enter+0x50: movq$0,0x6bd5cd(%rip) > db> reboot > > I will add that after this, every boot hits this problem. (same stack trace). > the box is effectively bricked > (or would be if it weren't just a bhyve image) -- +---++ | 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"
/usr/share/man/man4/cc.4.gz obsolete?
/usr/share/man/man4/cc.4.gz shows up as obsolete whenever I run make -C /usr/src check-old. make -C /usr/src delete-old removes the file, but make -C /usr/src installworld adds it. System is base/head r309889. Please make up your mind. -- +---++ | 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: Problem compiling akonadi
On Tue, 21 Feb 2017 09:00-, Filippo Moretti wrote: > While trying to compile akonadi I get the following error: > ===> Installing for qtchooser-39===> Checking if qtchooser already > installed===> Registering installation for qtchooser-39 as > automaticInstalling qtchooser-39...pkg-static: qtchooser-39 conflicts with > qt4-dbus-4.8.7 (installs files into the same place). Problematic file: > /usr/local/bin/qdbus*** Error code 70 > Stop.make[5]: stopped in /usr/ports/misc/qtchooser*** Error code > 1Stop.make[4]: stopped in /usr/ports/devel/qt4-qmake*** Error code > 1Stop.make[3]: stopped in /usr/ports/devel/qt4-moc*** Error code > 1Stop.make[2]: stopped in /usr/ports/devel/automoc4*** Error code > 1Stop.make[1]: stopped in /usr/ports/databases/akonadi*** Error code > 1Stop.make: stopped in /usr/ports/databases/akonadi > sincerelyFilippo I had to: pkg delete qt4-linguisttools pkg delete qt4-rcc pkg delete qt4-moc Then I installed qtchooser, and next, I upgraded qt5-core only. Now, you should be able to upgrade the remaining ports. Note, I use ports which I build on my own, not pre-compiled packages. -- +---++ | 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: update an older i386 CURRENT system to amd64 CURRENT
r/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin > /usr/obj/usr/src/make.i386/bmake KERNEL=kernel install > cc: Exec format error > bmake[1]: "/usr/src/share/mk/bsd.compiler.mk" line 145: Unable to > determine compiler type for CC=cc -isystem > /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib > -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin. Consider setting COMPILER_TYPE. > *** Error code 1 > > > Is there a way to use this /usr/src and pre-compiled /usr/obj on an i386 > host for update? Or do I have to use a complete recompile or even > reinstall, based on a 64-bit memstick system? I have in the past successfully migrated i386 to amd64 by cheating a bit: overwriting select parts of the base system with their amd64 counterparts from a snapshot (CD or memorystick) while exempting a few vital directories, /boot (not when replacing the kernel), /etc, /root, and /var. Since you're running the GENERIC kernel, all you need is the latest -current snapshot. Here are my notes from when I was "researching (and perfecting?)" the methodology: http://ximalas.info/2015/01/17/migrating-freebsd-from-i386-to-amd64/ YMMV, but this was less of a hassle than following https://wiki.freebsd.org/amd64/i386Migration. Last Easter I transformed four systems from 9-stable i386 UFS to 10-stable amd64 ZFS, using hardware I had selected for replacing the old hardware. The old systems were transferred to the new systems using tar and nc. That way the old systems kept humming while I recompiled base, ports, etc, on their replacements. Here are three things I didn't do/tried before "going live" last year: recursively copying /usr/local/lib to /usr/local/lib/compat/lib32, creating /usr/local/libdata/ldconfig/lib32 containing the line "/usr/local/lib/compat/lib32", and running ldconfig -R. When all parts of the new systems was in amd64 shape, I removed /usr/local/lib/compat/lib32 and /usr/local/libdata/ldconfig/lib32. -- +---++ | 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"
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"
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 Wed, 21 Jun 2017 11:18+0300, Andriy Gapon wrote: > On 21/06/2017 00: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 > >>>
Re: Current amd64 new error or warning from today's current with ruby r320323
; }
>
> /*
> @@ -2003,6 +2024,8 @@ vm_map_protect(vm_map_t map, vm_offset_t start,
> vm_offset_t end,
>*/
> for (current = entry; current != &map->header && current->start < end;
> current = current->next) {
> + if ((current->eflags & MAP_ENTRY_GUARD) != 0)
> + continue;
> if (current->eflags & MAP_ENTRY_IS_SUB_MAP) {
> vm_map_unlock(map);
> return (KERN_INVALID_ARGUMENT);
> @@ -2011,6 +2034,11 @@ vm_map_protect(vm_map_t map, vm_offset_t start,
> vm_offset_t end,
> vm_map_unlock(map);
> return (KERN_PROTECTION_FAILURE);
> }
> + if (current->end < end && (current->next == &map->header ||
> + current->next->start > current->end)) {
> + vm_map_unlock(map);
> + return (KERN_INVALID_ADDRESS);
> + }
> }
>
> /*
> @@ -2712,9 +2740,9 @@ vm_map_wire(vm_map_t map, vm_offset_t start,
> vm_offset_t end,
>* If VM_MAP_WIRE_HOLESOK was specified, skip this check.
>*/
> next_entry:
> - if (((flags & VM_MAP_WIRE_HOLESOK) == 0) &&
> - (entry->end < end && (entry->next == &map->header ||
> - entry->next->start > entry->end))) {
> + if ((flags & VM_MAP_WIRE_HOLESOK) == 0 &&
> + entry->end < end && (entry->next == &map->header ||
> + entry->next->start > entry->end)) {
> end = entry->end;
> rv = KERN_INVALID_ADDRESS;
> goto done;
> diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c
> index 4d8f6ad9ed7..09912250d52 100644
> --- a/sys/vm/vm_mmap.c
> +++ b/sys/vm/vm_mmap.c
> @@ -607,6 +607,7 @@ kern_mprotect(struct thread *td, uintptr_t addr0, size_t
> size, int prot)
> case KERN_PROTECTION_FAILURE:
> return (EACCES);
> case KERN_RESOURCE_SHORTAGE:
> + case KERN_INVALID_ADDRESS:
> return (ENOMEM);
> }
> return (EINVAL);
I'm seeing similar fallout on r320327, built from scratch while
running r320293:
Script started on Sun Jun 25 17:03:41 2017
# uname -aKU
FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320327: Sun Jun 25 16:35:02 CEST
2017 r...@freebsd-head-uefi-zfs.bsd.net:/usr/obj/usr/src/sys/VBOX amd64
1200035 1200035
# /sbin/zfs mount -va
Fatal error 'Cannot allocate red zone for initial thread' at line 392 in file
/usr/src/lib/libthr/thread/thr_init.c (errno = 12)
Abort trap (core dumped)
# ls -l /lib/libthr*
-r--r--r-- 1 root wheel 153336 Jun 25 16:39 /lib/libthr.so.3
# ls -l /usr/lib/libthr*
-r--r--r-- 1 root wheel 256064 May 28 21:41 /usr/lib/libthr.a
lrwxr-xr-x 1 root wheel 21 Jun 25 16:39 /usr/lib/libthr.so ->
../../lib/libthr.so.3
-r--r--r-- 1 root wheel 270362 May 28 21:41 /usr/lib/libthr_p.a
-r--r--r-- 1 root wheel 45376 Apr 22 10:39 /usr/lib/libthread_db.a
lrwxr-xr-x 1 root wheel 17 Jun 25 16:39 /usr/lib/libthread_db.so ->
libthread_db.so.3
-r--r--r-- 1 root wheel 38776 Jun 25 16:39 /usr/lib/libthread_db.so.3
-r--r--r-- 1 root wheel 49496 Apr 22 10:39 /usr/lib/libthread_db_p.a
# ldd /sbin/zfs
/sbin/zfs:
libjail.so.1 => /lib/libjail.so.1 (0x800247000)
libnvpair.so.2 => /lib/libnvpair.so.2 (0x80024f000)
libuutil.so.2 => /lib/libuutil.so.2 (0x800269000)
libzfs_core.so.2 => /lib/libzfs_core.so.2 (0x800276000)
libzfs.so.3 => /lib/libzfs.so.3 (0x800281000)
libc.so.7 => /lib/libc.so.7 (0x8002cd000)
libmd.so.6 => /lib/libmd.so.6 (0x8006d1000)
libumem.so.2 => /lib/libumem.so.2 (0x8006eb000)
libutil.so.9 => /lib/libutil.so.9 (0x8006f)
libm.so.5 => /lib/libm.so.5 (0x800706000)
libavl.so.2 => /lib/libavl.so.2 (0x800736000)
libbsdxml.so.4 => /lib/libbsdxml.so.4 (0x80073a000)
libgeom.so.5 => /lib/libgeom.so.5 (0x80077)
libz.so.6 => /lib/libz.so.6 (0x800779000)
libthr.so.3 => /lib/libthr.so.3 (0x800793000)
libsbuf.so.6 => /lib/libsbuf.so.6 (0x8007bd000)
# ls -l /sbin/zfs
-r-xr-xr-x 1 root wheel 124296 Jun 25 16:39 /sbin/zfs
# exit
Script done on Sun Jun 25 17:04:32 2017
Although not relevant for this case, neither /usr/lib/libthr.a, nor
/usr/lib/libthr_p.a, nor /usr/lib/libthread_db.a, nor
/usr/lib/libthread_db_p.a has been updated by installworld, nor
removed by delete-old-libs, in a very long time.
Anything else I can contribute? I'll try your patch and see if I can
get any further.
--
+---++
| 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: Current amd64 new error or warning from today's current with ruby r320323
On Sun, 25 Jun 2017 17:18+0200, Trond Endrestøl wrote: > On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote: > > > On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote: > > > > > > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov > > > > wrote: > > > > > > > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote: > > > >> > > > >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov > > > >>> wrote: > > > >>> > > > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > > > >>>> New world and kernel r320323 > > > >>>> I get a new error or message when using ruby: > > > >>>> > > > >>>> > > > >>>> /usr/local/sbin/portupgrade -av > > > >>>> : warning: pthread_create failed for timer: Resource > > > >>>> temporarily unavailable, scheduling broken > > > >>>> > > > >>>> everything works just this message when using ruby. I recompiled > > > >>>> ruby , still same message > > > >>>> > > > >>>> /usr/local/bin/ruby -v > > > >>>> : warning: pthread_create failed for timer: Resource > > > >>>> temporarily unavailable, scheduling broken > > > >>>> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > > >>>> > > > >>>> Not sure what???s changed, I noticed some commits to vm stuff, maybe > > > >>>> thats it. > > > >>> > > > >>> ktrace your failing ruby invocation, then post output of kdump -H > > > >>> somewhere. > > > >>> > > > >> > > > >> Ok not sure if this is right , but this is what i did: > > > >> > > > >> (tmp)4637}ktrace /usr/local/bin/ruby -v > > > >> : warning: pthread_create failed for timer: Resource temporarily > > > >> unavailable, scheduling broken > > > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > > >> > > > >> (tmp)4638}kdump -H -f ./ktrace.out > kdump.txt > > > >> > > > >> you can get kdump.txt at: > > > >> > > > >> http://www.pozo.com/kernel/kdump <http://www.pozo.com/kernel/kdump>.txt > > > >> > > > >> It???s not failing, I don???t think , I can do portupgrade and it > > > >> works fine. > > > >> I just get this new message > > > > > > > > I see what is going on, but it is somewhat strange that it happens. > > > > > > > > Do you run ruby in a jail with old (say, stable/10) libthr ? > > > > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in > > > > your environment ? > > > > > > > > Anyway, the rework of the stack grow indeed have incompatibility with > > > > the > > > > old (pre-11) libthr, which tries to split main thread stack into smaller > > > > stacks for the new threads. New stack grow code was specifically > > > > designed > > > > to prevent this. Some hack would be needed there, to allow reuse of > > > > the main stack gap. > > > > > > > > > > Not running any jails > > > all libraries are current as of today > > > locate libthr. |xargs ls -l > > > -r--r--r-- 1 root wheel 120240 Jun 24 12:50 /lib/libthr.so.3 > > > -r--r--r-- 1 root wheel 256072 Jun 24 12:50 /usr/lib/libthr.a > > > lrwxr-xr-x 1 root wheel 21 Jun 24 12:50 /usr/lib/libthr.so -> > > > ../../lib/libthr.so.3 > > > > > > ldd /usr/local/bin/ruby > > > -rwxr-xr-x 1 root wheel 2677552 Jun 24 18:22 > > > /usr/local/lib/libruby23.so.2 > > > -rwxr-xr-x 1 root wheel 43832 Jun 24 19:10 > > > /usr/local/lib/libunwind.so.8.0.1 > > > > > > /usr/local/bin/ruby: > > > libruby23.so.23 => /usr/local/lib/libruby23.so.23 (0x800a0) > > > libelf.so.2 => /lib/libelf.so.2 (0x800e9d000) > > > libunwind.so.8 => /usr/local/lib/libunwind.so.8 (0x8010b5000) > > > libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x8012ce000) > > > libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x8014d1000) > > > libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016db000) >
Re: Current amd64 new error or warning from today's current with ruby r320323
On Sun, 25 Jun 2017 17:56+0200, Trond Endrestøl wrote: > On Sun, 25 Jun 2017 17:18+0200, Trond Endrestøl wrote: > > > On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote: > > > > > On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote: > > > > > > > > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov > > > > > wrote: > > > > > > > > > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote: > > > > >> > > > > >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov > > > > >>> wrote: > > > > >>> > > > > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > > > > >>>> New world and kernel r320323 > > > > >>>> I get a new error or message when using ruby: > > > > >>>> > > > > >>>> > > > > >>>> /usr/local/sbin/portupgrade -av > > > > >>>> : warning: pthread_create failed for timer: Resource > > > > >>>> temporarily unavailable, scheduling broken > > > > >>>> > > > > >>>> everything works just this message when using ruby. I recompiled > > > > >>>> ruby , still same message > > > > >>>> > > > > >>>> /usr/local/bin/ruby -v > > > > >>>> : warning: pthread_create failed for timer: Resource > > > > >>>> temporarily unavailable, scheduling broken > > > > >>>> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > > > >>>> > > > > >>>> Not sure what???s changed, I noticed some commits to vm stuff, > > > > >>>> maybe thats it. > > > > >>> > > > > >>> ktrace your failing ruby invocation, then post output of kdump -H > > > > >>> somewhere. > > > > >>> > > > > >> > > > > >> Ok not sure if this is right , but this is what i did: > > > > >> > > > > >> (tmp)4637}ktrace /usr/local/bin/ruby -v > > > > >> : warning: pthread_create failed for timer: Resource > > > > >> temporarily unavailable, scheduling broken > > > > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > > > >> > > > > >> (tmp)4638}kdump -H -f ./ktrace.out > kdump.txt > > > > >> > > > > >> you can get kdump.txt at: > > > > >> > > > > >> http://www.pozo.com/kernel/kdump > > > > >> <http://www.pozo.com/kernel/kdump>.txt > > > > >> > > > > >> It???s not failing, I don???t think , I can do portupgrade and it > > > > >> works fine. > > > > >> I just get this new message > > > > > > > > > > I see what is going on, but it is somewhat strange that it happens. > > > > > > > > > > Do you run ruby in a jail with old (say, stable/10) libthr ? > > > > > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in > > > > > your environment ? > > > > > > > > > > Anyway, the rework of the stack grow indeed have incompatibility with > > > > > the > > > > > old (pre-11) libthr, which tries to split main thread stack into > > > > > smaller > > > > > stacks for the new threads. New stack grow code was specifically > > > > > designed > > > > > to prevent this. Some hack would be needed there, to allow reuse of > > > > > the main stack gap. > > > > > > > > > > > > > Not running any jails > > > > all libraries are current as of today > > > > locate libthr. |xargs ls -l > > > > -r--r--r-- 1 root wheel 120240 Jun 24 12:50 /lib/libthr.so.3 > > > > -r--r--r-- 1 root wheel 256072 Jun 24 12:50 /usr/lib/libthr.a > > > > lrwxr-xr-x 1 root wheel 21 Jun 24 12:50 /usr/lib/libthr.so -> > > > > ../../lib/libthr.so.3 > > > > > > > > ldd /usr/local/bin/ruby > > > > -rwxr-xr-x 1 root wheel 2677552 Jun 24 18:22 > > > > /usr/local/lib/libruby23.so.2 > > > > -rwxr-xr-x 1 root wheel 43832 Jun 24 19:10 > > > > /usr/local/lib/libun
Re: Current amd64 new error or warning from today's current with ruby r320323
On Sun, 25 Jun 2017 18:08+0200, Trond Endrestøl wrote: > On Sun, 25 Jun 2017 17:56+0200, Trond Endrestøl wrote: > > > On Sun, 25 Jun 2017 17:18+0200, Trond Endrestøl wrote: > > > > > On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote: > > > > > > > On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote: > > > > > > > > > > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov > > > > > > wrote: > > > > > > > > > > > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote: > > > > > >> > > > > > >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov > > > > > >>> wrote: > > > > > >>> > > > > > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > > > > > >>>> New world and kernel r320323 > > > > > >>>> I get a new error or message when using ruby: > > > > > >>>> > > > > > >>>> > > > > > >>>> /usr/local/sbin/portupgrade -av > > > > > >>>> : warning: pthread_create failed for timer: Resource > > > > > >>>> temporarily unavailable, scheduling broken > > > > > >>>> > > > > > >>>> everything works just this message when using ruby. I recompiled > > > > > >>>> ruby , still same message > > > > > >>>> > > > > > >>>> /usr/local/bin/ruby -v > > > > > >>>> : warning: pthread_create failed for timer: Resource > > > > > >>>> temporarily unavailable, scheduling broken > > > > > >>>> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > > > > >>>> > > > > > >>>> Not sure what???s changed, I noticed some commits to vm stuff, > > > > > >>>> maybe thats it. > > > > > >>> > > > > > >>> ktrace your failing ruby invocation, then post output of kdump -H > > > > > >>> somewhere. > > > > > >>> > > > > > >> > > > > > >> Ok not sure if this is right , but this is what i did: > > > > > >> > > > > > >> (tmp)4637}ktrace /usr/local/bin/ruby -v > > > > > >> : warning: pthread_create failed for timer: Resource > > > > > >> temporarily unavailable, scheduling broken > > > > > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12] > > > > > >> > > > > > >> (tmp)4638}kdump -H -f ./ktrace.out > kdump.txt > > > > > >> > > > > > >> you can get kdump.txt at: > > > > > >> > > > > > >> http://www.pozo.com/kernel/kdump > > > > > >> <http://www.pozo.com/kernel/kdump>.txt > > > > > >> > > > > > >> It???s not failing, I don???t think , I can do portupgrade and it > > > > > >> works fine. > > > > > >> I just get this new message > > > > > > > > > > > > I see what is going on, but it is somewhat strange that it happens. > > > > > > > > > > > > Do you run ruby in a jail with old (say, stable/10) libthr ? > > > > > > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set > > > > > > in > > > > > > your environment ? > > > > > > > > > > > > Anyway, the rework of the stack grow indeed have incompatibility > > > > > > with the > > > > > > old (pre-11) libthr, which tries to split main thread stack into > > > > > > smaller > > > > > > stacks for the new threads. New stack grow code was specifically > > > > > > designed > > > > > > to prevent this. Some hack would be needed there, to allow reuse of > > > > > > the main stack gap. > > > > > > > > > > > > > > > > Not running any jails > > > > > all libraries are current as of today > > > > > locate libthr. |xargs ls -l > > > > > -r--r--r-- 1 root wheel 120240 Jun 24 12:50 /lib/libthr.so.3 > > > > > -r--r--r-- 1
Re: Current amd64 new error or warning from today's current with ruby r320323
On Sun, 25 Jun 2017 19:41+0300, Konstantin Belousov wrote: > On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote: > > > > > On Jun 25, 2017, at 7:50 AM, Konstantin Belousov > > > wrote: > > > > > > On Sun, Jun 25, 2017 at 07:43:25AM -0700, Manfred Antar wrote: > > >> maybe message got reformatted in mail program (mac mail). > > >> could you send me a tar file of the patch? > > >> also not sure if ???patch -p1 > >> patch > > >> > > >> you could cc r...@pozo.com <mailto:r...@pozo.com> , that way i have copy > > >> on freebsd box and on mac. > > > > > > https://people.freebsd.org/~kib/misc/vm2.1.patch > > > <https://people.freebsd.org/~kib/misc/vm2.1.patch> > > > > OK patched and built new kernel \ > > rebooted, > > same ruby message. So it must be a ruby thing. > > new kdump.txt at http://www.pozo.com/kernel/kdump.txt > > <http://www.pozo.com/kernel/kdump.txt> > > > > also i???ll put a copy of my kernel config in same directory: > > > > http://www.pozo.com/kernel/pozo <http://www.pozo.com/kernel/pozo> > > > > only one module is being loaded at boot: > > (kernel)4908}kldstat > > Id Refs AddressSize Name > > 15 0x8020 10380a8 kernel > > 21 0x8123a000 e13f50 nvidia.ko > > > > I can disable nvidia if it helps as I really only access this machine over > > the net or serial console. > > > 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 This patch made ruby23 happy on my end. Can't say the same for emacs-nox11 or temacs while building the former. -- +---++ | 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"
Has gdb been disconnected from make installworld?
I was at bit surprised to see gdb missing from /usr/bin this evening. The executables are still being built in /usr/obj/usr/src/gnu/usr.bin/gdb. This is on base/head r320329. Do we need to add WITH_GDB=yes to our src.conf files? -- +---++ | 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: Has gdb been disconnected from make installworld?
On Sun, 25 Jun 2017 20:55+0200, Trond Endrestøl wrote: > I was at bit surprised to see gdb missing from /usr/bin this evening. > The executables are still being built in /usr/obj/usr/src/gnu/usr.bin/gdb. > > This is on base/head r320329. > > Do we need to add WITH_GDB=yes to our src.conf files? Ah, they wound up in /usr/libexec. Still, that's an odd place for user software. -- +---++ | 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: 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: 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: [base package build] [fail] r320347 -> r320392: install: builddir/Africa/Abidjan: No such file or directory
Try running make installworld without -j N. Serial installworld was successful at my end. -- +---++ | 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: Current amd64 new error or warning from today's current with ruby r320323
On Sun, 25 Jun 2017 22:05+0300, Konstantin Belousov wrote: > On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote: > > > https://people.freebsd.org/~kib/misc/vm2.2.patch > > > > This patch made ruby23 happy on my end. Can't say the same for > > emacs-nox11 or temacs while building the former. > > What exactly do you mean ? Explain the behaviour and show the ktrace log. It builds now. I'm running unpatched r320406, and I'll attempt building and running r320420 with your patch from yesterday. I too suffer from /sbin/zfs's inability to run in singleuser mode, yet somehow it does its job while in multiuser mode. -- 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: Current amd64 new error or warning from today's current with ruby r320323
On Tue, 27 Jun 2017 20:28+0200, Trond Endrestøl wrote: > On Sun, 25 Jun 2017 22:05+0300, Konstantin Belousov wrote: > > > On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote: > > > > https://people.freebsd.org/~kib/misc/vm2.2.patch > > > > > > This patch made ruby23 happy on my end. Can't say the same for > > > emacs-nox11 or temacs while building the former. > > > > What exactly do you mean ? Explain the behaviour and show the ktrace log. > > It builds now. > > I'm running unpatched r320406, and I'll attempt building and running > r320420 with your patch from yesterday. > > I too suffer from /sbin/zfs' inability to run in singleuser mode, yet > somehow it does its job while in multiuser mode. That patch enables /sbin/zfs to run in singleuser mode. Next, there seems to be a race condition while running installworld in parallel, but that's a story for another time. -- 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"
ipfw_netflow in base/head r320944 & r321008
At boot time /etc/rc display this message: /etc/rc: WARNING: $ipfw_netflow_enable is not set properly - see rc.conf(5). This was introduced in r320944 and corrected to some extent in r321008. Nevertheless, a default value for ipfw_netflow_enable should be provided: Index: etc/defaults/rc.conf === --- etc/defaults/rc.conf(revision 321041) +++ etc/defaults/rc.conf(working copy) @@ -195,6 +195,7 @@ # of state tables at shutdown and boot ipfs_program="/sbin/ipfs" # where the ipfs program lives ipfs_flags="" # additional flags for ipfs +ipfw_netflow_enable="NO" # Set yo YES to enable ipfw netflow. pf_enable="NO" # Set to YES to enable packet filter (pf) pf_rules="/etc/pf.conf"# rules definition file for pf pf_program="/sbin/pfctl" # where the pfctl program lives -- +---++ | 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: ipfw_netflow in base/head r320944 & r321008
On Sun, 16 Jul 2017 10:43+0200, Trond Endrestøl wrote: > At boot time /etc/rc display this message: > > /etc/rc: WARNING: $ipfw_netflow_enable is not set properly - see rc.conf(5). > > This was introduced in r320944 and corrected to some extent in > r321008. > > Nevertheless, a default value for ipfw_netflow_enable should be > provided: > > Index: etc/defaults/rc.conf > === > --- etc/defaults/rc.conf (revision 321041) > +++ etc/defaults/rc.conf (working copy) > @@ -195,6 +195,7 @@ > # of state tables at shutdown and boot > ipfs_program="/sbin/ipfs"# where the ipfs program lives > ipfs_flags=""# additional flags for ipfs > +ipfw_netflow_enable="NO" # Set yo YES to enable ipfw netflow. Typo fixed: +ipfw_netflow_enable="NO" # Set to YES to enable ipfw netflow. > pf_enable="NO" # Set to YES to enable packet filter > (pf) > pf_rules="/etc/pf.conf" # rules definition file for pf > pf_program="/sbin/pfctl" # where the pfctl program lives -- +---+----+ | 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: [tzsetup] can't set up local timezone if CMOS is set to UTC
On Mon, 7 Aug 2017 09:51+0300, Boris Samorodov wrote: > So my question is: how to set up local time zone if CMOS is set to UTC? My timezone is Europe/Oslo, adjust to fit your timezone: rm -f /etc/wall_cmos_clock cp -p /usr/share/zoneinfo/Europe/Oslo /etc/localtime echo Europe/Oslo > /var/db/zoneinfo -- 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: make delete-old broken
On Tue, 29 Oct 2013 13:26+0200, Alexander Panyushkin wrote:
> Hello
>
> FreeBSD 10.0-BETA2 #0 r257316: Tue Oct 29 12:46:22 EET 2013
> root:/usr/obj/usr/src/sys/Kernel amd64
>
> Build without error.
>
> root> make delete-old delete-old-libs
> >>> Removing old files (only deletes safe to delete libs)
> make[3]: chdir /usr/obj/usr/src/release: No such file or directory
> make[2]: "/usr/src/Makefile.inc1" line 132: warning: "make -C
> /usr/obj/usr/src/release -V REVISION" returned non-zero status
> make[3]: chdir /usr/obj/usr/src/release: No such file or directory
> make[2]: "/usr/src/Makefile.inc1" line 133: warning: "make -C
> /usr/obj/usr/src/release -V BRANCH" returned non-zero status
> awk: can't open file /usr/obj/usr/src/sys/sys/param.h
> source line number 1
> make[2]: "/usr/src/Makefile.inc1" line 135: warning: "awk
> '/^#define[[:space:]]*__FreeBSD_version/ { print $3 }'
> /usr/obj/usr/src/sys/sys/param.h" returned non-zero status
> >>> Old files removed
> >>> Removing old directories
> make[3]: chdir /usr/obj/usr/src/release: No such file or directory
> make[2]: "/usr/src/Makefile.inc1" line 132: warning: "make -C
> /usr/obj/usr/src/release -V REVISION" returned non-zero status
> make[3]: chdir /usr/obj/usr/src/release: No such file or directory
> make[2]: "/usr/src/Makefile.inc1" line 133: warning: "make -C
> /usr/obj/usr/src/release -V BRANCH" returned non-zero status
> awk: can't open file /usr/obj/usr/src/sys/sys/param.h
> source line number 1
> make[2]: "/usr/src/Makefile.inc1" line 135: warning: "awk
> '/^#define[[:space:]]*__FreeBSD_version/ { print $3 }'
> /usr/obj/usr/src/sys/sys/param.h" returned non-zero status
> rmdir: /usr/share/doc/psd/28.cvs: Directory not empty
> >>> Old directories removed
> To remove old libraries run 'make delete-old-libs'.
> >>> Removing old libraries
> Please be sure no application still uses those libraries, else you
> can not start such an application. Consult UPDATING for more
> information regarding how to cope with the removal/revision bump
> of a specific library.
> make[3]: chdir /usr/obj/usr/src/release: No such file or directory
> make[2]: "/usr/src/Makefile.inc1" line 132: warning: "make -C
> /usr/obj/usr/src/release -V REVISION" returned non-zero status
> make[3]: chdir /usr/obj/usr/src/release: No such file or directory
> make[2]: "/usr/src/Makefile.inc1" line 133: warning: "make -C
> /usr/obj/usr/src/release -V BRANCH" returned non-zero status
> awk: can't open file /usr/obj/usr/src/sys/sys/param.h
> source line number 1
> make[2]: "/usr/src/Makefile.inc1" line 135: warning: "awk
> '/^#define[[:space:]]*__FreeBSD_version/ { print $3 }'
> /usr/obj/usr/src/sys/sys/param.h" returned non-zero status
> >>> Old libraries removed
+1
Running make delete-old delete-old-libs rips away libc++, libcxxrt,
and important header files on head with nothing in make.conf nor
src.conf. Do we need to explicitly specify WITH_LIBCPLUSPLUS=yes &
friends in src.conf? If head is migrating away from g++ and libstdc++,
then why remove libc++ during make delete-old{,-libs}?
> On 29.08.2013 12:48, Ivan Klymenko wrote:
> > Hello.
> > In the interval between revisions >= r254887 to r255016
> > make delete-old broken
> >
> > root@nonamehost:/ # cd /usr/src/
> > root@nonamehost:/usr/src # yes|make delete-old
> > make[1]: "tools/build/mk/tools/build/mk/OptionalObsoleteFiles.inc" line
> > 1603: Malformed conditional (${MK_GNU_PATCH} == no) make[1]: Fatal
> > errors encountered -- cannot continue make[1]: stopped in /usr/src
> > *** Error code 1
> >
> > Stop.
> > make: stopped in /usr/src
> >
> > I can not say exactly at what revision it happened - but it was noticed
> > in revision r255016
--
+---++
| 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
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r265279 causes gpf at sys/net/route.c:930
Hi, I updated one of my amd64 base/head VMs this afternoon. It crashes in rt_expunge(), and I think r265279 is to blame. If someone's interested, here's the crash report: http://ximalas.info/~trond/amd64-head-VBOX-crash/r265283/core.txt.0 Another amd64 base/head VM I updated earlier this afternoon, runs smoothly at r265275. -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT: jemalloc_jemalloc.c:(.text+0xcb7): relocation truncated to fit: R_X86_64_PC32 against symbol `__je_ctl_boot'
On Mon, 5 May 2014 23:34+0200, O. Hartmann wrote: > > It seems that I can not build anymore a kernel or world. > > I had an accident in a truncated /usr/libc while installing the last > buildworld/kernel > with mixed up sources. > > Is there a way to revert this mess? > > I think I installed lib/libc with more recent sources than the last installed > system > ( FreeBSD 11.0-CURRENT #7 r265358: Mon May 5 14:12:21 CEST 2014 amd64). > > Any help welcome. Maybe you could resurrect the corrupted library/ies from a recent snapshot. Try downloading base.txz from ftp://ftp1.de.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/11.0-CURRENT/, and then extract the contents into a safe (sub)directory, and carefully copy the files you need into place. > [...] > c++ -O2 -pipe -O3 -pipe -O3 > -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/include > -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/include > -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I. > -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/../../lib/clang/include > -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS > -D__STDC_CONSTANT_MACROS > -fno-strict-aliasing > -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" > -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" > -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-exceptions > -fno-rtti -static > -L/usr/obj/usr/src/tmp/legacy/usr/lib -o tblgen AsmMatcherEmitter.o > AsmWriterEmitter.o > AsmWriterInst.o CTagsEmitter.o CallingConvEmitter.o CodeEmitterGen.o > CodeGenDAGPatterns.o > CodeGenInstruction.o CodeGenMapTable.o CodeGenRegisters.o CodeGenSchedule.o > CodeGenTarget.o DAGISelEmitter.o DAGISelMatcher.o DAGISelMatcherEmitter.o > DAGISelMatcherGen.o DAGISelMatcherOpt.o DFAPacketizerEmitter.o > DisassemblerEmitter.o > FastISelEmitter.o FixedLenDecoderEmitter.o InstrInfoEmitter.o > IntrinsicEmitter.o > OptParserEmitter.o PseudoLoweringEmitter.o RegisterInfoEmitter.o SetTheory.o > SubtargetEmitter.o TGValueTypes.o TableGen.o X86DisassemblerTables.o > X86ModRMFilters.o > X86RecognizableInstr.o > /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/tblgen/../../../lib/clang/libllvmtablegen/libllvmtablegen.a > > /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/tblgen/../../../lib/clang/libllvmsupport/libllvmsupport.a > -lncurses -legacy /usr/lib/libc.a(jemalloc_jemalloc.o): In function `malloc': > jemalloc_jemalloc.c:(.text+0xcb7): relocation truncated to fit: R_X86_64_PC32 > against > symbol `__je_ctl_boot' defined in .text section in > /usr/lib/libc.a(jemalloc_ctl.o) c++: > error: linker command failed with exit code 1 (use -v to see invocation) *** > Error code 1 > > Stop. > make[3]: stopped in /usr/src/usr.bin/clang/tblgen > -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld fails (missing /usr/share/mk/src.opts.mk)
On Tue, 6 May 2014 13:24+0200, Stefan Esser wrote: > Am 06.05.2014 11:52, schrieb Stefan Esser: > > Hi Warner, > > > > as already reported by Jenkins, HEAD does not build. > > > > Seems that this is caused by src.opts.mk missing in /usr/share/mk > > during the cleandir phase. I guess this is kind of a bootstrap > > issue - the definitions are looked up in the installed base, not > > in the src tree - but did not verify this assumption. > > > > A work-around is to manually install src.opts.mk: > > > > # make -C /usr/src/share/mk install > > > > (which might deserve an UPDATING entry). Falling back on the file > > in the src directory might be a better solution ... > > > > Regards, STefan > > Following up to my earlier mail: > > The diagnosis was wrong - the main Makefiles include src.opts.mk from > the source directory. But two sub-ordinate Makefiles missed to include > the new options file (sys/conf/kmod.mk and sys/modules/drm2/Makefile). > > I committed a fix/work-around to stop the flood of tinderbox messages > (r265433). tinderbox still complains about usr.bin/bmake/Makefile.inc. -- +-------+--------+ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ports broken in current
On Thu, 8 May 2014 09:04-0700, Warner Losh wrote: > On May 7, 2014, at 5:41 PM, Shane Ambler wrote: > > > I have just updated my 11-CURRENT tinderbox machine and found an issue > > that breaks ports building. > > > > make: "/usr/share/mk/bsd.port.mk" line 15: Could not find bsd.own.mk > > Install again. This was fixed last night. You can fix it just by > updating and running make install in share/mk. > > > This is highlighted as tinderbox creates a clean build environment while > > the base system kept working with the old file being left behind - make > > delete-old doesn't remove bsd.own.mk from base but a clean system > > doesn't get it installed. > > > > In r265420 /head/share/mk/Makefile removed reference to bsd.own.mk and > > replaced it with src.opts.mk > > Yea that?s totally bogus. Which is why I fixed it. One too many > automatic replacements that slipped through the cracks. > > > bsd.port.mk was left unaltered still including bsd.own.mk which now > > doesn't get installed but is still in svn, breaking ports building. > > Yea, bsd.port.mk is good. The above breakage was bad... > > > Should bsd.port.mk include src.opts.mk instead of bsd.own.mk or should > > bsd.own.mk be re-added to the install list? > > The proper fix is in the tree: re-add bsd.own.mk. > > > This appears to carry on from the yesterdays build fails with > > src.opts.mk not being found. > > Please update. If the problems persist, please let me know. Also, be > sure to remove /usr/share/mk/src.opts.mk, since if will cause you > head-aches in the future if you don?t. If we're supposed to remove /usr/share/mk/src.opts.mk until futher notice, why is it being reinstalled by make installworld? make installworld sure did this at r265705 yesterday. Maybe I'm missing something. > Sorry for the bumps? The beumps? ;-) -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r266298: make buildworld fail: fatal error: 'llvm/ADT/APFloat.h' file not found #include "llvm/ADT/APFloat.h"
On Sat, 17 May 2014 10:11+0200, O. Hartmann wrote: > With 11.0-CURRENT's sources (r266298) buildworld fails: > > [...] > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp:15:10: > fatal error: 'llvm/ADT/APFloat.h' file not found #include "llvm/ADT/APFloat.h" > ^ > 1 error generated. > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APInt.cpp:16:10: > fatal error: 'llvm/ADT/APInt.h' file not found #include "llvm/ADT/APInt.h" When I upgraded from r265775 to r266393 earlier today, I had to empty /usr/obj and recompile world+kernel on my three base/head VMs. It's worth a try, although it robs you of precious time. I believe the introduction of clang 3.4.1 is the culprit. -- +---+----+ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: jail sockstat shows gdnc, gdomap, casperd as enabled
On Tue, 3 Jun 2014 00:02-0700, Beeblebrox wrote: > Some (not all) of my jails show gdnc, gdomap & casperd services with sockstat > listing. The jails that show these services have /usr/local mounted as ro to > jailname/usr/local. > > root gdnc 1433 5 stream > /tmp/GNUstepSecure0/NSMessagePort/ports/1433.0 > nobody gdomap 1378 3 udp4 192.168.2.50:538 *:* > nobody gdomap 1378 4 tcp4 192.168.2.50:538 *:* These two are related to GNUstep. If your jails don't run GNUstep, why is GNUstep installed in the first place? http://www.gnustep.org/resources/documentation/Developer/Tools/Reference/gdnc.html http://www.gnustep.org/resources/documentation/Developer/Tools/Reference/gdomap.html > root casperd1149 3 dgram -> /var/run/logpriv > root casperd1149 4 stream -> ?? > root casperd1149 6 stream /var/run/casper > root casperd1148 5 stream -> ?? casperd is part of capsicum. You should probably keep this one. http://www.cl.cam.ac.uk/research/security/capsicum/freebsd.html -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: jail sockstat shows gdnc, gdomap, casperd as enabled
On Tue, 3 Jun 2014 01:00-0700, Beeblebrox wrote: > Hi Trond, > > > These two are related to GNUstep. If your jails don't run GNUstep, > > why is GNUstep installed in the first place? > > I know that they are related to GNUstep (although I have no idea what > GNUstep actually does other than act as a messaging system probably like > dbus). Anyway, I don't understand how & why they start up and that's > exactly my question. The only insight I can provide, is that /usr/local is > null_mounted on to jail/usr/local, but that should not really have this > effect. I have no experience with GNUstep, but I recall X applications depending on dbus will start an user instance if there's no system instance running. I guess the same applies to GNUstep's services. > > casperd is part of capsicum. You should probably keep this one. > > I figured as much re capsicum. So the question becomes "should all jails be > running capsicum in this case"? casperd uses local sockets and are thus confined to its jail. Do the sandboxes in each jail need the casperd services, e.g. the DNS service? Well, yes, if the sandboxes i.e. can't send UDP datagrams. -- +---+----+ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: do we have a generic string-number sysctl mapping library ?
On Fri, 27 Jun 2014 11:14+0200, Luigi Rizzo wrote: > Hi, > I have frequently found myself using sysctls to control some kernel > feature where a string would be a better (and sometimes the only) > option than using a numeric value, yet the internal representation > should be numeric for speed and robustness. > Examples are the kern.timecounter, the default scheduler in dummynet, > and now in netmap the selection between native and emulated mode. > I am sure many of you can come up with other cases. > > I wonder if we have some support for that already in the sysctl code, > or i should build a generic one next time i need to do that. In C, according to sysctl(3) you could use sysctlnametomib(). I might have misinterpreted the problem domain. > Feel free to criticise the approach and suggest better ones. > Right now i am using sysctls because i have a set of macros > and wrapper functions that let me convert them to sysfs > entries when building kernel code on linux, so I have a > portable solutions. > > For the details, I'd like to have a mechanism that requires the > kernel programmer supply a (possibly extensible) table of > supported values, and matching constants to be used within > the kernel. A single declaration should generate entries > to get/set the current value as well as list options. > We can discuss frills (such as wildcards, multiple values,etc). > > cheers > luigi -- +---+----+ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
vidcontrol(1) complains about Bad magic, in base/head, amd64, sc console, r268165
Hi, Is it just me or is there something wrong with vidcontrol(1) in base/head, amd64, sc console, r268165? First, I had to specify absolute pathnames for the font8x16, font8x14, and font8x8 variables in /etc/rc.conf before vidcontrol(1) would load anything, and next, vidcontrol(1), when run by /etc/rc.d/syscons, complains about: Bad magic vidcontrol: failed to load font "/usr/share/syscons/fonts/iso-8x16.fnt": No error: 0 Bad magic vidcontrol: failed to load font "/usr/share/syscons/fonts/iso-8x14.fnt": No error: 0 Bad magic vidcontrol: failed to load font "/usr/share/syscons/fonts/iso-8x8.fnt": No error: 0 I wouldn't rule out pilot error on my part, but r267957 worked flawlessly in this regard. -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vidcontrol(1) complains about Bad magic, in base/head, amd64, sc console, r268165
On Wed, 2 Jul 2014 20:51+0200, Trond Endrestøl wrote: > Hi, > > Is it just me or is there something wrong with vidcontrol(1) in > base/head, amd64, sc console, r268165? > > First, I had to specify absolute pathnames for the font8x16, font8x14, > and font8x8 variables in /etc/rc.conf before vidcontrol(1) would load > anything, and next, vidcontrol(1), when run by /etc/rc.d/syscons, > complains about: > > Bad magic > vidcontrol: failed to load font "/usr/share/syscons/fonts/iso-8x16.fnt": No > error: 0 > Bad magic > vidcontrol: failed to load font "/usr/share/syscons/fonts/iso-8x14.fnt": No > error: 0 > Bad magic > vidcontrol: failed to load font "/usr/share/syscons/fonts/iso-8x8.fnt": No > error: 0 > > I wouldn't rule out pilot error on my part, but r267957 worked > flawlessly in this regard. I guess with both sc and vt in the kernel, line 220 of usr.sbin/vidcontrol/vidcontrol.c needs a slight adjustment. -- +---+--------+ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vidcontrol(1) complains about Bad magic, in base/head, amd64, sc console, r268165
On Wed, 2 Jul 2014 21:05+0200, Trond Endrestøl wrote: > On Wed, 2 Jul 2014 20:51+0200, Trond Endrestøl wrote: > > > Hi, > > > > Is it just me or is there something wrong with vidcontrol(1) in > > base/head, amd64, sc console, r268165? > > > > First, I had to specify absolute pathnames for the font8x16, font8x14, > > and font8x8 variables in /etc/rc.conf before vidcontrol(1) would load > > anything, and next, vidcontrol(1), when run by /etc/rc.d/syscons, > > complains about: > > > > Bad magic > > vidcontrol: failed to load font "/usr/share/syscons/fonts/iso-8x16.fnt": No > > error: 0 > > Bad magic > > vidcontrol: failed to load font "/usr/share/syscons/fonts/iso-8x14.fnt": No > > error: 0 > > Bad magic > > vidcontrol: failed to load font "/usr/share/syscons/fonts/iso-8x8.fnt": No > > error: 0 > > > > I wouldn't rule out pilot error on my part, but r267957 worked > > flawlessly in this regard. > > I guess with both sc and vt in the kernel, line 220 of > usr.sbin/vidcontrol/vidcontrol.c needs a slight adjustment. The same adjustment will be needed at line 150 of usr.sbin/kbdcontrol/kbdcontrol.c. -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vidcontrol(1) complains about Bad magic, in base/head, amd64, sc console, r268165
On Wed, 2 Jul 2014 12:57-0700, Kevin Oberman wrote: > On Wed, Jul 2, 2014 at 12:19 PM, Trond Endrestøl < > trond.endres...@fagskolen.gjovik.no> wrote: > > > On Wed, 2 Jul 2014 21:05+0200, Trond Endrestøl wrote: > > > > > On Wed, 2 Jul 2014 20:51+0200, Trond Endrestøl wrote: > > > > > > > Hi, > > > > > > > > Is it just me or is there something wrong with vidcontrol(1) in > > > > base/head, amd64, sc console, r268165? > > > > > > > > First, I had to specify absolute pathnames for the font8x16, font8x14, > > > > and font8x8 variables in /etc/rc.conf before vidcontrol(1) would load > > > > anything, and next, vidcontrol(1), when run by /etc/rc.d/syscons, > > > > complains about: > > > > > > > > Bad magic > > > > vidcontrol: failed to load font > > "/usr/share/syscons/fonts/iso-8x16.fnt": No error: 0 > > > > Bad magic > > > > vidcontrol: failed to load font > > "/usr/share/syscons/fonts/iso-8x14.fnt": No error: 0 > > > > Bad magic > > > > vidcontrol: failed to load font > > "/usr/share/syscons/fonts/iso-8x8.fnt": No error: 0 > > > > > > > > I wouldn't rule out pilot error on my part, but r267957 worked > > > > flawlessly in this regard. > > > > > > I guess with both sc and vt in the kernel, line 220 of > > > usr.sbin/vidcontrol/vidcontrol.c needs a slight adjustment. > > > > The same adjustment will be needed at line 150 of > > usr.sbin/kbdcontrol/kbdcontrol.c. > > > > I don't believe that building a kernel for both vt and sc is supported, so > I'm not surprised that it does not work. Maybe you should examine r268045 and reconsider your position. > I would like to know how you intend to use such a kernel. I'm not sure I > see a case where having both would be useful and it looks like keeping them > straight would be rather a problem. -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vidcontrol(1) complains about Bad magic, in base/head, amd64, sc console, r268165
On Wed, 2 Jul 2014 16:43-0400, Ed Maste wrote: > On 2 July 2014 14:51, Trond Endrestøl > wrote: > > Hi, > > > > Is it just me or is there something wrong with vidcontrol(1) in > > base/head, amd64, sc console, r268165? > > Should be fixed in r268175. Looks good, 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vidcontrol(1) complains about Bad magic, in base/head, amd64, sc console, r268165
On Wed, 2 Jul 2014 17:37-0400, Ed Maste wrote:
> On 2 July 2014 17:09, Trond Endrestøl
> wrote:
> > On Wed, 2 Jul 2014 16:43-0400, Ed Maste wrote:
> >
> >> On 2 July 2014 14:51, Trond Endrestøl
> >> wrote:
> >> > Hi,
> >> >
> >> > Is it just me or is there something wrong with vidcontrol(1) in
> >> > base/head, amd64, sc console, r268165?
> >>
> >> Should be fixed in r268175.
> >
> > Looks good, thanks.
>
> Thanks for the report, and sorry for the trouble.
No trouble at all, I follow base/head (and stable/{8,9,10}) on various
VMs at home only to know what's ahead. ;-)
Since neither kbdcontrol(1) nor I mind using the old syscons keymap
file norwegian.iso.kbd, wouldn't it be nice if kbdcontrol(1), while in
vt(4) mode, would search for keymaps in /usr/share/syscons/keymaps
after searching for them in /usr/share/vt/keymaps?
E.g.:
Index: usr.sbin/kbdcontrol/kbdcontrol.c
===
--- usr.sbin/kbdcontrol/kbdcontrol.c(revision 268203)
+++ usr.sbin/kbdcontrol/kbdcontrol.c(working copy)
@@ -804,7 +804,7 @@
char*postfix[] = {blank, dotkbd, NULL};
if (is_vt4())
- prefix[2] = vt_keymap_path;
+ prefix[1] = vt_keymap_path;
cp = getenv("KEYMAP_PATH");
if (cp != NULL)
asprintf(&(prefix[0]), "%s/", cp);
--
+---++
| 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
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vidcontrol(1) complains about Bad magic, in base/head, amd64, sc console, r268165
On Thu, 3 Jul 2014 08:21+0200, Trond Endrestøl wrote:
> On Wed, 2 Jul 2014 17:37-0400, Ed Maste wrote:
>
> > On 2 July 2014 17:09, Trond Endrestøl
> > wrote:
> > > On Wed, 2 Jul 2014 16:43-0400, Ed Maste wrote:
> > >
> > >> On 2 July 2014 14:51, Trond Endrestøl
> > >> wrote:
> > >> > Hi,
> > >> >
> > >> > Is it just me or is there something wrong with vidcontrol(1) in
> > >> > base/head, amd64, sc console, r268165?
> > >>
> > >> Should be fixed in r268175.
> > >
> > > Looks good, thanks.
> >
> > Thanks for the report, and sorry for the trouble.
>
> No trouble at all, I follow base/head (and stable/{8,9,10}) on various
> VMs at home only to know what's ahead. ;-)
>
> Since neither kbdcontrol(1) nor I mind using the old syscons keymap
> file norwegian.iso.kbd, wouldn't it be nice if kbdcontrol(1), while in
> vt(4) mode, would search for keymaps in /usr/share/syscons/keymaps
> after searching for them in /usr/share/vt/keymaps?
>
> E.g.:
>
> Index: usr.sbin/kbdcontrol/kbdcontrol.c
> ===
> --- usr.sbin/kbdcontrol/kbdcontrol.c(revision 268203)
> +++ usr.sbin/kbdcontrol/kbdcontrol.c(working copy)
> @@ -804,7 +804,7 @@
> char*postfix[] = {blank, dotkbd, NULL};
>
> if (is_vt4())
> - prefix[2] = vt_keymap_path;
> + prefix[1] = vt_keymap_path;
> cp = getenv("KEYMAP_PATH");
> if (cp != NULL)
> asprintf(&(prefix[0]), "%s/", cp);
Or maybe this patch is even better, as it leaves one instance of blank
in the array when KEYMAP_PATH is set in the environment, at prefix[1],
and sadly add a redundant blank at prefix[2] when KEYMAP_PATH is not
set in the environment.
Index: usr.sbin/kbdcontrol/kbdcontrol.c
===
--- usr.sbin/kbdcontrol/kbdcontrol.c(revision 268203)
+++ usr.sbin/kbdcontrol/kbdcontrol.c(working copy)
@@ -800,7 +800,7 @@
char*name, *cp;
charblank[] = "", keymap_path[] = KEYMAP_PATH;
charvt_keymap_path[] = VT_KEYMAP_PATH, dotkbd[] = ".kbd";
- char*prefix[] = {blank, blank, keymap_path, NULL};
+ char*prefix[] = {blank, blank, blank, keymap_path, NULL};
char*postfix[] = {blank, dotkbd, NULL};
if (is_vt4())
For now I could just stick to using an absolute pathname for keymap=
in /etc/rc.conf.
--
+---++
| 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
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: getenv("TZ") crashes triggered by tzset_basic()
e (localtime.c:1467) > ==6563==by 0x40D38C: http_dirlisting (http.c:214) > ==6563==by 0x40FF9C: http_openfile (http.c:1485) > ==6563==by 0x413921: httpresponse (http.c:1940) > ==6563==by 0x40657C: handle_read_misc (gatling.c:1051) > ==6563==by 0x404D53: main (gatling.c:2247) > ==6563== If you believe this happened as a result of a stack > ==6563== overflow in your program's main thread (unlikely but > ==6563== possible), you can try to increase the size of the > ==6563== main thread stack using the --main-stacksize= flag. > ==6563== The main thread stack size used in this run was 16777216. > ==6563== > ==6563== HEAP SUMMARY: > ==6563== in use at exit: 18,848 bytes in 6 blocks > ==6563== total heap usage: 25 allocs, 19 frees, 47,144 bytes allocated > ==6563== > ==6563== LEAK SUMMARY: > ==6563==definitely lost: 0 bytes in 0 blocks > ==6563==indirectly lost: 0 bytes in 0 blocks > ==6563== possibly lost: 0 bytes in 0 blocks > ==6563==still reachable: 18,848 bytes in 6 blocks > ==6563== suppressed: 0 bytes in 0 blocks > ==6563== Rerun with --leak-check=full to see details of leaked memory > ==6563== > ==6563== For counts of detected and suppressed errors, rerun with: -v > ==6563== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) > Segmentation fault > > I can't reproduce the problem with a test program that merely calls > localtime(), so I assume some environment changes are required. > > Has anyone seens this or is able to reproduce the gatling crashes? > > Fabian > -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vidcontrol(1) complains about Bad magic, in base/head, amd64, sc console, r268165
On Thu, 3 Jul 2014 12:48+0300, Aleksandr Rybalko wrote:
> On Thu, 3 Jul 2014 08:31:45 +0200 (CEST)
> Trond Endrestøl wrote:
>
> > On Thu, 3 Jul 2014 08:21+0200, Trond Endrestøl wrote:
> >
> > > On Wed, 2 Jul 2014 17:37-0400, Ed Maste wrote:
> > >
> > > > On 2 July 2014 17:09, Trond Endrestøl
> > > > wrote:
> > > > > On Wed, 2 Jul 2014 16:43-0400, Ed Maste wrote:
> > > > >
> > > > >> On 2 July 2014 14:51, Trond Endrestøl
> > > > >> wrote:
> > > > >> > Hi,
> > > > >> >
> > > > >> > Is it just me or is there something wrong with vidcontrol(1) in
> > > > >> > base/head, amd64, sc console, r268165?
> > > > >>
> > > > >> Should be fixed in r268175.
> > > > >
> > > > > Looks good, thanks.
> > > >
> > > > Thanks for the report, and sorry for the trouble.
> > >
> > > No trouble at all, I follow base/head (and stable/{8,9,10}) on various
> > > VMs at home only to know what's ahead. ;-)
> > >
> > > Since neither kbdcontrol(1) nor I mind using the old syscons keymap
> > > file norwegian.iso.kbd, wouldn't it be nice if kbdcontrol(1), while in
> > > vt(4) mode, would search for keymaps in /usr/share/syscons/keymaps
> > > after searching for them in /usr/share/vt/keymaps?
> > >
> > > E.g.:
> > >
> > > Index: usr.sbin/kbdcontrol/kbdcontrol.c
> > > ===
> > > --- usr.sbin/kbdcontrol/kbdcontrol.c(revision 268203)
> > > +++ usr.sbin/kbdcontrol/kbdcontrol.c(working copy)
> > > @@ -804,7 +804,7 @@
> > > char*postfix[] = {blank, dotkbd, NULL};
> > >
> > > if (is_vt4())
> > > - prefix[2] = vt_keymap_path;
> > > + prefix[1] = vt_keymap_path;
> > > cp = getenv("KEYMAP_PATH");
> > > if (cp != NULL)
> > > asprintf(&(prefix[0]), "%s/", cp);
> >
> > Or maybe this patch is even better, as it leaves one instance of blank
> > in the array when KEYMAP_PATH is set in the environment, at prefix[1],
> > and sadly add a redundant blank at prefix[2] when KEYMAP_PATH is not
> > set in the environment.
> >
> > Index: usr.sbin/kbdcontrol/kbdcontrol.c
> > ===
> > --- usr.sbin/kbdcontrol/kbdcontrol.c(revision 268203)
> > +++ usr.sbin/kbdcontrol/kbdcontrol.c(working copy)
> > @@ -800,7 +800,7 @@
> > char*name, *cp;
> > charblank[] = "", keymap_path[] = KEYMAP_PATH;
> > charvt_keymap_path[] = VT_KEYMAP_PATH, dotkbd[] = ".kbd";
> > - char*prefix[] = {blank, blank, keymap_path, NULL};
> > + char*prefix[] = {blank, blank, blank, keymap_path, NULL};
> > char*postfix[] = {blank, dotkbd, NULL};
> >
> > if (is_vt4())
> >
> > For now I could just stick to using an absolute pathname for keymap=
> > in /etc/rc.conf.
>
> Hi Trond,
>
> It is not so good idea to fallback to syscons keymaps, because vt(4)
> works with Unicode only char codes. So fallback will make input with
> non-English characters - unreadable.
>
> Instead of that fallback you can convert keymaps you can verify by
> follow instructions in [1], then please check it and send it to list,
> so me or someone else will commit it.
>
> Thank you for reports!
>
> 1.
> http://raybsd.blogspot.com/2013/10/newcons-international-keyboard-input.html
I tried to follow the instructions, but I honestly don't see any
difference.
I downloaded uakbd2ukbd.pl.gz, decompressed the file, installed
converters/p5-Text-Iconv, copied /usr/share/syscons/norwegian.iso.kbd
to cwd, and ran:
./uakbd2ukbd.pl norwegian.iso.kbd ISO-8859-1 > norwegian.utf8.kbd
Running diff -u norwegian.* shows absolutely no difference.
Is it pilot error on my part?
I have attached both files.
--
+---++
| 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
Re: vidcontrol(1) complains about Bad magic, in base/head, amd64, sc console, r268165
On Thu, 3 Jul 2014 17:50+0200, Trond Endrestøl wrote:
> On Thu, 3 Jul 2014 12:48+0300, Aleksandr Rybalko wrote:
>
> > On Thu, 3 Jul 2014 08:31:45 +0200 (CEST)
> > Trond Endrestøl wrote:
> >
> > > On Thu, 3 Jul 2014 08:21+0200, Trond Endrestøl wrote:
> > >
> > > > On Wed, 2 Jul 2014 17:37-0400, Ed Maste wrote:
> > > >
> > > > > On 2 July 2014 17:09, Trond Endrestøl
> > > > > wrote:
> > > > > > On Wed, 2 Jul 2014 16:43-0400, Ed Maste wrote:
> > > > > >
> > > > > >> On 2 July 2014 14:51, Trond Endrestøl
> > > > > >> wrote:
> > > > > >> > Hi,
> > > > > >> >
> > > > > >> > Is it just me or is there something wrong with vidcontrol(1) in
> > > > > >> > base/head, amd64, sc console, r268165?
> > > > > >>
> > > > > >> Should be fixed in r268175.
> > > > > >
> > > > > > Looks good, thanks.
> > > > >
> > > > > Thanks for the report, and sorry for the trouble.
> > > >
> > > > No trouble at all, I follow base/head (and stable/{8,9,10}) on various
> > > > VMs at home only to know what's ahead. ;-)
> > > >
> > > > Since neither kbdcontrol(1) nor I mind using the old syscons keymap
> > > > file norwegian.iso.kbd, wouldn't it be nice if kbdcontrol(1), while in
> > > > vt(4) mode, would search for keymaps in /usr/share/syscons/keymaps
> > > > after searching for them in /usr/share/vt/keymaps?
> > > >
> > > > E.g.:
> > > >
> > > > Index: usr.sbin/kbdcontrol/kbdcontrol.c
> > > > ===
> > > > --- usr.sbin/kbdcontrol/kbdcontrol.c(revision 268203)
> > > > +++ usr.sbin/kbdcontrol/kbdcontrol.c(working copy)
> > > > @@ -804,7 +804,7 @@
> > > > char*postfix[] = {blank, dotkbd, NULL};
> > > >
> > > > if (is_vt4())
> > > > - prefix[2] = vt_keymap_path;
> > > > + prefix[1] = vt_keymap_path;
> > > > cp = getenv("KEYMAP_PATH");
> > > > if (cp != NULL)
> > > > asprintf(&(prefix[0]), "%s/", cp);
> > >
> > > Or maybe this patch is even better, as it leaves one instance of blank
> > > in the array when KEYMAP_PATH is set in the environment, at prefix[1],
> > > and sadly add a redundant blank at prefix[2] when KEYMAP_PATH is not
> > > set in the environment.
> > >
> > > Index: usr.sbin/kbdcontrol/kbdcontrol.c
> > > ===
> > > --- usr.sbin/kbdcontrol/kbdcontrol.c(revision 268203)
> > > +++ usr.sbin/kbdcontrol/kbdcontrol.c(working copy)
> > > @@ -800,7 +800,7 @@
> > > char*name, *cp;
> > > charblank[] = "", keymap_path[] = KEYMAP_PATH;
> > > charvt_keymap_path[] = VT_KEYMAP_PATH, dotkbd[] = ".kbd";
> > > - char*prefix[] = {blank, blank, keymap_path, NULL};
> > > + char*prefix[] = {blank, blank, blank, keymap_path, NULL};
> > > char*postfix[] = {blank, dotkbd, NULL};
> > >
> > > if (is_vt4())
> > >
> > > For now I could just stick to using an absolute pathname for keymap=
> > > in /etc/rc.conf.
> >
> > Hi Trond,
> >
> > It is not so good idea to fallback to syscons keymaps, because vt(4)
> > works with Unicode only char codes. So fallback will make input with
> > non-English characters - unreadable.
> >
> > Instead of that fallback you can convert keymaps you can verify by
> > follow instructions in [1], then please check it and send it to list,
> > so me or someone else will commit it.
> >
> > Thank you for reports!
> >
> > 1.
> > http://raybsd.blogspot.com/2013/10/newcons-international-keyboard-input.html
>
> I tried to follow the instructions, but I honestly don't see any
> difference.
>
> I downloaded uakbd2ukbd.pl.gz, decompressed the file, installed
> converters/p5-Text-Iconv, copied /usr/share/syscons/norwegian.iso.kbd
> to cwd, and ran:
>
> ./uakbd2ukbd.pl norwegian.iso.kbd ISO-8859-1 > norwegian.utf8.kbd
>
> Running diff -u norwegian.* shows a
Re: keyboard break to debugger broken?
On Fri, 4 Jul 2014 02:28-0700, John-Mark Gurney wrote: > So, I recently tried to break into the debugger w/ the various key > sequences that I know about, and none of them worked... I've tried > CTRL-ESC, ALT-ESC, CTRL-ALT-ESC, CTRL-PRTSCR, ALT-PRTSCR and > CTRL-ALT-PRTSCR, and many other different ones... I've verified that > I can sysctl debug.kdb.enter=1 to enter the debugger, and the > CTRL-ALT-PAUSE works to suspend the machine, and CTRL-ALT-DEL works > to reboot... > > Does anyone know if this works? > > Thanks for the pointers... > > btw, I'm having trouble on 9stable too. You might need to modify and load a keymap, specifying debug as the action for the appropriate combination of keys. Have a look at the files in /usr/share/syscons/keymaps/. -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vidcontrol(1) complains about Bad magic, in base/head, amd64, sc console, r268165
On Sun, 6 Jul 2014 16:33+0300, Aleksandr Rybalko wrote:
> Hi,
>
> so if i get it right, you get expected results, right?
>
> If so, please check key combinations which is different, to get correct
> results.
> And if all is ok, send me new maps please.
> If it is not correct, let as know what is wrong.
>
> Thanks a lot!
Sorry for the delay.
I followed my heart and looked carefully at the Norwegian layout of my
keyboard. The layout is fairly updated, although it has the wavey
Windows symbol and not the trapeze shaped Windows symbol you'll find
nowadays. ;-)
I decided it would be nice to have access to the euro symbol not on
its current location as the letter é has historically been reached by
holding AltGr and hitting the lowercase e key.
Instead, I figured it made some sense to have the euro symbol
available on AltGr+Shift+4. That's where you'll find the 8364 value,
line 11.
The remainder is virtually unchanged, except for a correction of
whitespace on line 109. A tab was changed into three spaces.
Feel free to use a better, suitable name for the attached keymap.
I know there are some Norwegian speaking individuals on this list, and
I welcome their input.
--
+---++
| 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: head/share/syscons/keymaps/norwegian.iso.kbd 117271 2003-07-06
03:09:40Z ache $
# alt
# scan cntrl altalt cntrl lock
# code base shift cntrl shift altshift cntrl shift state
# --
000 nopnopnopnopnopnopnopnop O
001 escescescescescescdebug esc O
002 '1''!'nopnop'1''!'nopnop O
003 '2''"'nulnul'@''@'nulnul O
004 '3''#'nopnop163'#'nopnop O
005 '4'164nopnop'$'8364 nopnop O
006 '5''%'nopnop'5''%'nopnop O
007 '6''&'nopnop'6''&'nopnop O
008 '7''/'nopnop'{''/'nopnop O
009 '8''('escesc'[''('escesc O
010 '9'')'gs gs ']'')'gs gs O
011 '0''='nopnop'}''='nopnop O
012 '+''?'nopnop'+''?'nopnop O
013 '\''`'fs fs '''nopnopnop O
014 bs bs deldelbs bs deldel O
015 ht btab nopnopht btab nopnop O
016 'q''Q'dc1dc1'q''Q'dc1dc1 C
017 'w''W'etbetb'w''W'etbetb C
018 'e''E'enqenq233201enqenq C
019 'r''R'dc2dc2174174dc2dc2 C
020 't''T'dc4dc4254222dc4dc4 C
021 'y''Y'em em 255165em em C
022 'u''U'naknak252220naknak C
023 'i''I'ht ht 239207ht ht C
024 'o''O'si si 242210si si C
025 'p''P'dledle182182dledle C
026 229197nopnop'}'']'nopnop C
027 168'^'rs rs '~''^'rs rs O
028 cr cr nl nl cr cr nl nl O
029 lctrl lctrl lctrl lctrl lctrl lctrl lctrl lctrl O
030 'a''A'sohsoh225193
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
On Tue, 5 Aug 2014 20:49-0700, John Baldwin wrote: > > On Aug 5, 2014, at 2:29 PM, Michael Butler > wrote: > > > On 08/05/14 16:56, Michael Butler wrote: > >> On 08/05/14 16:02, John Baldwin wrote: > >> > >>> My guess is that the recent Xen changes tickled something. > >> > >> I can confirm this on a kernel which is otherwise up to date .. > >> > >> FreeBSD toshi.auburn.protected-networks.net 11.0-CURRENT FreeBSD > >> 11.0-CURRENT #2 r269608M: Tue Aug 5 16:48:12 EDT 2014 > >> > >> I backed out all of SVN r269507 through r269515. > >> > >> Now working .. > > > > [ .. snip .. ] > > > >> Now to see if it's related to the other machine's disk woes (it's a > >> single-core device), > > > > And it fixes the inability to probe disks on my single-core machine :-) > > It looks like the MADT code to probe the I/O APICs isn't working so > it's trying to fall back to using the ATPIC while using SMP (which > doesn't work). I know it's a pain on a laptop, but if it is at all > possible to capture either a verbose or non-verbose dmesg that would > really help narrow it down. > > Also, if anyone can try reverting just the MADT-related changes in > the recent Xen changes to see if you can narrow down which exact one > triggers the panic that would be really helpful. I noticed this panic on i386 head r269607 yesterday, running in VBox on Windows 7 SP1 x64, on an Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz (3175.67-MHz 686-class CPU). Go to http://ximalas.info/~trond/atpic_assign_cpu/ where you'll find a verbose dmesg from i386 head r268838 from the same VM and a couple of screenshots of the crash while booting r269607 with the verbose flag on. I'm rewinding /usr/src to r269507, and I'll take it from there, one commit at the time. I'll also try to investigate this panic using my amd64 head VM. -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
On Wed, 6 Aug 2014 19:21+0200, Trond Endrestøl wrote: > On Tue, 5 Aug 2014 20:49-0700, John Baldwin wrote: > > > > > On Aug 5, 2014, at 2:29 PM, Michael Butler > > wrote: > > > > > On 08/05/14 16:56, Michael Butler wrote: > > >> On 08/05/14 16:02, John Baldwin wrote: > > >> > > >>> My guess is that the recent Xen changes tickled something. > > >> > > >> I can confirm this on a kernel which is otherwise up to date .. > > >> > > >> FreeBSD toshi.auburn.protected-networks.net 11.0-CURRENT FreeBSD > > >> 11.0-CURRENT #2 r269608M: Tue Aug 5 16:48:12 EDT 2014 > > >> > > >> I backed out all of SVN r269507 through r269515. > > >> > > >> Now working .. > > > > > > [ .. snip .. ] > > > > > >> Now to see if it's related to the other machine's disk woes (it's a > > >> single-core device), > > > > > > And it fixes the inability to probe disks on my single-core machine :-) > > > > It looks like the MADT code to probe the I/O APICs isn't working so > > it's trying to fall back to using the ATPIC while using SMP (which > > doesn't work). I know it's a pain on a laptop, but if it is at all > > possible to capture either a verbose or non-verbose dmesg that would > > really help narrow it down. > > > > Also, if anyone can try reverting just the MADT-related changes in > > the recent Xen changes to see if you can narrow down which exact one > > triggers the panic that would be really helpful. > > I noticed this panic on i386 head r269607 yesterday, running in VBox > on Windows 7 SP1 x64, on an Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz > (3175.67-MHz 686-class CPU). > > Go to http://ximalas.info/~trond/atpic_assign_cpu/ where you'll find a > verbose dmesg from i386 head r268838 from the same VM and a couple of > screenshots of the crash while booting r269607 with the verbose flag > on. > > I'm rewinding /usr/src to r269507, and I'll take it from there, one > commit at the time. Reverting r269510 did the trick, i.e.: cd /usr/src && svn up && svn diff -r 269510:269509 | patch My i386 head VM is running smoothly with r269641M, with M meaning only the above reversal. > I'll also try to investigate this panic using my amd64 head VM. Work in progress. -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
On Wed, 6 Aug 2014 22:48+0200, Trond Endrestøl wrote: > On Wed, 6 Aug 2014 19:21+0200, Trond Endrestøl wrote: > > > On Tue, 5 Aug 2014 20:49-0700, John Baldwin wrote: > > > > > > > > On Aug 5, 2014, at 2:29 PM, Michael Butler > > > wrote: > > > > > > > On 08/05/14 16:56, Michael Butler wrote: > > > >> On 08/05/14 16:02, John Baldwin wrote: > > > >> > > > >>> My guess is that the recent Xen changes tickled something. > > > >> > > > >> I can confirm this on a kernel which is otherwise up to date .. > > > >> > > > >> FreeBSD toshi.auburn.protected-networks.net 11.0-CURRENT FreeBSD > > > >> 11.0-CURRENT #2 r269608M: Tue Aug 5 16:48:12 EDT 2014 > > > >> > > > >> I backed out all of SVN r269507 through r269515. > > > >> > > > >> Now working .. > > > > > > > > [ .. snip .. ] > > > > > > > >> Now to see if it's related to the other machine's disk woes (it's a > > > >> single-core device), > > > > > > > > And it fixes the inability to probe disks on my single-core machine :-) > > > > > > It looks like the MADT code to probe the I/O APICs isn't working so > > > it's trying to fall back to using the ATPIC while using SMP (which > > > doesn't work). I know it's a pain on a laptop, but if it is at all > > > possible to capture either a verbose or non-verbose dmesg that would > > > really help narrow it down. > > > > > > Also, if anyone can try reverting just the MADT-related changes in > > > the recent Xen changes to see if you can narrow down which exact one > > > triggers the panic that would be really helpful. > > > > I noticed this panic on i386 head r269607 yesterday, running in VBox > > on Windows 7 SP1 x64, on an Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz > > (3175.67-MHz 686-class CPU). > > > > Go to http://ximalas.info/~trond/atpic_assign_cpu/ where you'll find a > > verbose dmesg from i386 head r268838 from the same VM and a couple of > > screenshots of the crash while booting r269607 with the verbose flag > > on. > > > > I'm rewinding /usr/src to r269507, and I'll take it from there, one > > commit at the time. > > Reverting r269510 did the trick, i.e.: > > cd /usr/src && svn up && svn diff -r 269510:269509 | patch > > My i386 head VM is running smoothly with r269641M, with M meaning only > the above reversal. > > > I'll also try to investigate this panic using my amd64 head VM. > > Work in progress. amd64 is unaffected, as r269644 worked without any modifications. I'm guessing the changes to sys/x86/x86/local_apic.c and sys/x86/xen/xen_intr.c come as a pair. If not, then the changes done to sys/x86/x86/local_apic.c is the culprit somehow. Trond, going to bed. -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
On Thu, 7 Aug 2014 13:32+0200, Roger Pau Monné wrote: > On 06/08/14 23:07, David Wolfskill wrote: > > On Wed, Aug 06, 2014 at 10:48:32PM +0200, Trond Endrestøl wrote: > >> ... > >> Reverting r269510 did the trick, i.e.: > >> > >> cd /usr/src && svn up && svn diff -r 269510:269509 | patch > >> > >> My i386 head VM is running smoothly with r269641M, with M meaning only > >> the above reversal. > >> ... > > > > Works for me, as well -- thanks! > > > > FreeBSD 11.0-CURRENT #1333 r269622M/269622:1100028: Wed Aug 6 14:01:30 > > PDT 2014 > > > > (I'll be providing more details to royger@ et al. in a moment.) > > I think I've found the issue, but since I'm not able to reproduce it, > could someone try the following patch? (without r269510 reverted). I'll try it once I'm back home, in about 3 hours. > Thanks, Roger. NP. -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
On Thu, 7 Aug 2014 07:49-0700, David Wolfskill wrote: > On Thu, Aug 07, 2014 at 01:32:45PM +0200, Roger Pau Monné wrote: > > ... > > I think I've found the issue, but since I'm not able to reproduce it, > > could someone try the following patch? (without r269510 reverted). > > ... > > That worked for me; thanks! +1 Verbose dmesg for i386 head r269666M with http://ximalas.info/~trond/atpic_assign_cpu/sys-x86-isa-atpic.c.patch as the sole modification is available at http://ximalas.info/~trond/atpic_assign_cpu/dmesg-verbose-head-i386-r269666M.txt -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: loader lszfs command
On Thu, 7 Aug 2014 14:17-0700, dte...@freebsd.org wrote: > Hi, > > People have been pestering me to update the Forth code to present > a menu of ZFS datasets (*cough* boot environments *cough*). > > Would love to, but existing code seems broken. > > Can *anybody* produce meaningful output from the following? > > http://svnweb.freebsd.org/base?view=revision&revision=241284 > > All I get on every system I've tried (multiple versions, including HEAD) > produce the following: > > OK lszfs zroot > ZFS: i/o error - all block copies unavailable > operation not permitted > > It's really hard for me to start with something that's broken. Can > I get confirmation that this doesn't appear to be working as intended? > If so, I'll go ahead and try to fix it, but need to confirm that I'm ( a ) > not > crazy and ( b ) seeing the same thing everybody else is seeing. A bit on the side, but more user friendly: You should change the error message on line 335 to explain how to use lszfs, or add a "help lszfs" command. Instead of merely complaining about "wrong number of arguments", how about stating something like "wrong number of arguments, need at least pool name"? -- +-------+--------+ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Oversized kernel.txz in FreeBSD-10.0-CURRENT-i386-20130525-r250975-release.iso
Hi, I just tried to install FreeBSD/i386 from the FreeBSD-10.0-CURRENT-i386-20130525-r250975-release.iso snapshot. The installer fails while extracting kernel.txz. kernel.txz file is larger than usual. The file contains virtually everything from /usr/obj/usr/src and not just boot/kernel/* rooted at /usr/obj/usr/src/release/dist/base. Maybe someone would look at the scripts involved when creating kernel.txz. Such a change will certainly make the snapshots more useful. -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Unable to set root's password during install of FreeBSD-10.0-CURRENT-i386-20130601-r251213-release.iso
Hi, I'm unable to get past the rootpass step using the FreeBSD-10.0-CURRENT-i386-20130601-r251213-release.iso snapshot. The error message: passwd: pam_chauthtok(): error in service module is briefly shown, leaving behind a core file named /pwd_mkdb.core. pwd_mkdb does not contain any debugging symbols and this makes it a bit hard to guess what went wrong. Anyway, here's the backtrace as provided by gdb: Script started on Mon Jun 3 06:50:44 2013 command: gdb /usr/sbin/pwd_mkdb /pwd_mkdb.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `pwd_mkdb'. Program terminated with signal 11, Segmentation fault. #0 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x0804acf2 in __pw_scan () #2 0x0804976a in __pw_scan () #3 0x08048e6a in ?? () #4 0x0007 in ?? () #5 0xbfbfdd18 in ?? () #6 0xbfbfdd38 in ?? () #7 0xbfbfdd38 in ?? () #8 0xbfbfdd14 in ?? () #9 0x in ?? () (gdb) q Script done on Mon Jun 3 06:50:49 2013 Has anyone else tried recently to change user passwords on -CURRENT? -- +---++ | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
