Re: Programmatically cache line
On 30 December 2017 at 00:28, Konstantin Belousov wrote: > On Sat, Dec 30, 2017 at 07:50:19AM +, blubee blubeeme wrote: >> Is there some way to programmatically get the CPU cache line sizes on >> FreeBSD? > > There are, all of them are MD. > > On x86, the CPUID instruction leaf 0x1 returns the information in > %ebx register. Hm, weird. Why don't we extend sysctl to include this info? -adrian > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN r327444 breaks current build
On Sun, 2017-12-31 at 15:53 -0800, Oleksandr Tymoshenko wrote:
> Nathan Whitehorn (nwhiteh...@freebsd.org) wrote:
> >
> >
> >
> > On 12/31/17 14:22, Oleksandr Tymoshenko wrote:
> > >
> > > Michael Butler (i...@protected-networks.net) wrote:
> > > >
> > > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vt_font_default.o
> > > > --- vt_termcolors.o ---
> > > > /usr/src/sys/dev/vt/colors/vt_termcolors.c:158:55: error: too many
> > > > arguments to function call, expected 4, have 5
> > > > if (vt_parse_rgb_triplet(rgb, strlen(rgb), &r,
> > > > &g, &b) == 0) {
> > > >
> > > > ^~
> > > > /usr/src/sys/dev/vt/colors/vt_termcolors.c:77:1: note:
> > > > 'vt_parse_rgb_triplet' declared here
> > > > static int
> > > > ^
> > > > 1 error generated.
> > > > *** [vt_termcolors.o] Error code 1
> > > >
> > > > .. second time today a commit wasn't tested before commit :-(
> > > >
> > > > imb
> > > Should be fixed in r327449. It was a sloppy job, I was making iterative
> > > improvements to the original patch following review feedback and used
> > > out-of-tree testcases for actual testing. I appologize for the breakage.
> > >
> > Still broken with GCC.
> >
> > /usr/src/sys/dev/vt/colors/vt_termcolors.c:148: warning: function
> > declaration isn't a prototype [-Wstrict-prototypes]
> > *** [vt_termcolors.o] Error code 1
> *sigh* Should be fixed in r327454. Thanks for reporting
>
> I wonder if we can get clang to be more strict about
> declarations/prototypes/etc to match gcc's expectations. I understand
> that it's developers' responsibility to make sure that kernel
> is GCC-buildable but if raising red flag for some of the cases
> when compiling with clang reduced number of these breakages
> that it'd be an improvement.
>
I think we can get clang to do that with -Wstrict-prototypes, but I'm
not sure when that option appeared in terms of clang version, and the
clang site doesn't seem to provide documentation for anything other
than the current in-development version.
-- Ian
___
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: SVN r327444 breaks current build
Nathan Whitehorn (nwhiteh...@freebsd.org) wrote:
>
>
> On 12/31/17 14:22, Oleksandr Tymoshenko wrote:
> > Michael Butler (i...@protected-networks.net) wrote:
> >> Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vt_font_default.o
> >> --- vt_termcolors.o ---
> >> /usr/src/sys/dev/vt/colors/vt_termcolors.c:158:55: error: too many
> >> arguments to function call, expected 4, have 5
> >> if (vt_parse_rgb_triplet(rgb, strlen(rgb), &r,
> >> &g, &b) == 0) {
> >>
> >>^~
> >> /usr/src/sys/dev/vt/colors/vt_termcolors.c:77:1: note:
> >> 'vt_parse_rgb_triplet' declared here
> >> static int
> >> ^
> >> 1 error generated.
> >> *** [vt_termcolors.o] Error code 1
> >>
> >> .. second time today a commit wasn't tested before commit :-(
> >>
> >>imb
> > Should be fixed in r327449. It was a sloppy job, I was making iterative
> > improvements to the original patch following review feedback and used
> > out-of-tree testcases for actual testing. I appologize for the breakage.
> >
> Still broken with GCC.
>
> /usr/src/sys/dev/vt/colors/vt_termcolors.c:148: warning: function
> declaration isn't a prototype [-Wstrict-prototypes]
> *** [vt_termcolors.o] Error code 1
*sigh* Should be fixed in r327454. Thanks for reporting
I wonder if we can get clang to be more strict about
declarations/prototypes/etc to match gcc's expectations. I understand
that it's developers' responsibility to make sure that kernel
is GCC-buildable but if raising red flag for some of the cases
when compiling with clang reduced number of these breakages
that it'd be an improvement.
--
gonzo
___
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: SVN r327444 breaks current build
On 12/31/17 14:22, Oleksandr Tymoshenko wrote:
Michael Butler (i...@protected-networks.net) wrote:
Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vt_font_default.o
--- vt_termcolors.o ---
/usr/src/sys/dev/vt/colors/vt_termcolors.c:158:55: error: too many
arguments to function call, expected 4, have 5
if (vt_parse_rgb_triplet(rgb, strlen(rgb), &r,
&g, &b) == 0) {
^~
/usr/src/sys/dev/vt/colors/vt_termcolors.c:77:1: note:
'vt_parse_rgb_triplet' declared here
static int
^
1 error generated.
*** [vt_termcolors.o] Error code 1
.. second time today a commit wasn't tested before commit :-(
imb
Should be fixed in r327449. It was a sloppy job, I was making iterative
improvements to the original patch following review feedback and used
out-of-tree testcases for actual testing. I appologize for the breakage.
Still broken with GCC.
/usr/src/sys/dev/vt/colors/vt_termcolors.c:148: warning: function
declaration isn't a prototype [-Wstrict-prototypes]
*** [vt_termcolors.o] Error code 1
-Nathan
___
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: SVN r327444 breaks current build
Michael Butler (i...@protected-networks.net) wrote:
> Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vt_font_default.o
> --- vt_termcolors.o ---
> /usr/src/sys/dev/vt/colors/vt_termcolors.c:158:55: error: too many
> arguments to function call, expected 4, have 5
> if (vt_parse_rgb_triplet(rgb, strlen(rgb), &r,
> &g, &b) == 0) {
>
> ^~
> /usr/src/sys/dev/vt/colors/vt_termcolors.c:77:1: note:
> 'vt_parse_rgb_triplet' declared here
> static int
> ^
> 1 error generated.
> *** [vt_termcolors.o] Error code 1
>
> .. second time today a commit wasn't tested before commit :-(
>
> imb
Should be fixed in r327449. It was a sloppy job, I was making iterative
improvements to the original patch following review feedback and used
out-of-tree testcases for actual testing. I appologize for the breakage.
--
gonzo
___
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: SVN r327444 breaks current build
On Sun, 2017-12-31 at 16:32 -0500, Michael Butler wrote:
> Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vt_font_default.o
> --- vt_termcolors.o ---
> /usr/src/sys/dev/vt/colors/vt_termcolors.c:158:55: error: too many
> arguments to function call, expected 4, have 5
> if (vt_parse_rgb_triplet(rgb, strlen(rgb), &r,
> &g, &b) == 0) {
>
> ^~
> /usr/src/sys/dev/vt/colors/vt_termcolors.c:77:1: note:
> 'vt_parse_rgb_triplet' declared here
> static int
> ^
> 1 error generated.
> *** [vt_termcolors.o] Error code 1
>
> .. second time today a commit wasn't tested before commit :-(
>
> imb
Fixed in r327449.
-- Ian
___
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"
SVN r327444 breaks current build
Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vt_font_default.o
--- vt_termcolors.o ---
/usr/src/sys/dev/vt/colors/vt_termcolors.c:158:55: error: too many
arguments to function call, expected 4, have 5
if (vt_parse_rgb_triplet(rgb, strlen(rgb), &r,
&g, &b) == 0) {
^~
/usr/src/sys/dev/vt/colors/vt_termcolors.c:77:1: note:
'vt_parse_rgb_triplet' declared here
static int
^
1 error generated.
*** [vt_termcolors.o] Error code 1
.. second time today a commit wasn't tested before commit :-(
imb
___
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: SVN r327433 fails to build
On 12/31/17 12:17, Colin Percival wrote: > Oops! It never occurred to me that I had to worry about userland programs > defining _KERNEL and then including kernel headers... I think I know how to > fix this, just testing now. Should be fixed now. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ 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: SVN r327433 fails to build
On 12/31/17 09:35, Herbert J. Skuhra wrote: > On Sun, 31 Dec 2017 15:19:21 +0100, > Michael Butler wrote: >> >> ===> lib/libprocstat (obj,all,install) >> Building /usr/obj/usr/src/amd64.amd64/lib/libprocstat/zfs/zfs.o >> In file included from /usr/src/lib/libprocstat/zfs.c:41: >> /usr/src/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:217:9: >> error: 'curthread' macro redefined [-Werror,-Wmacro-redefined] > > This is caused by > > > r327429 | cperciva | 2017-12-31 10:23:35 +0100 (Sun, 31 Dec 2017) | 2 lines > > Use the TSLOG framework to record entry/exit timestamps for VFS_MOUNT calls. > > Oops! It never occurred to me that I had to worry about userland programs defining _KERNEL and then including kernel headers... I think I know how to fix this, just testing now. Thanks, -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ 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: evdev broken
Shawn Webb writes: > > > > It looks like evdev support in the kernel is broken. > > > > sys/dev/kbdmux/kbdmux.c contains various unresolved symbols to > > > > different evdev-related symbols. > > > > > > > > I have the following options in my kernel config: > > > > > > > > options EVDEV_SUPPORT > > > > options EVDEV_DEBUG > > > > options UINPUT_DEBUG > > > > > > Did you add "device evdev"? > > > > Good catch! I did not. Adding now and I'll report back when > > buildkernel finishes. > > That did the trick. Thanks! > > Seems like evdev doesn't have a manpage, which is why I didn't > know to include it in my kernel config. On a system running: FreeBSD 12.0-CURRENT #0 r326723: Sat Dec 9 12:30:04 EST 2017 amd64 there is a man page, in section 4x. That's the good news. The bad news is I see no mention of needing to add anything to the kernel; it's presented as a Xorg input device. Reported as "https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224793";. Respectfully, Robert Huff ___ 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: SVN r327433 fails to build
On Sun, 31 Dec 2017 15:19:21 +0100, Michael Butler wrote: > > An include file change? I couldn't see the cause :-( > > The last successful build I have is at SVN r327392. > > ===> lib/libprocstat (obj,all,install) > Building /usr/obj/usr/src/amd64.amd64/lib/libprocstat/zfs/zfs.o > In file included from /usr/src/lib/libprocstat/zfs.c:41: > /usr/src/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:217:9: > error: 'curthread' macro redefined [-Werror,-Wmacro-redefined] > #define curthread ((void *)(uintptr_t)thr_self()) > ^ > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/machine/pcpu.h:230:9: note: > previous definition is here > #define curthread (__curthread()) > ^ > In file included from /usr/src/lib/libprocstat/zfs.c:41: > /usr/src/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:236:9: > error: 'curproc' macro redefined [-Werror,-Wmacro-redefined] > #define curproc (&p0) > ^ > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/sys/pcpu.h:200:9: note: > previous definition is here > #define curproc (curthread->td_proc) > ^ > 2 errors generated. This is caused by r327429 | cperciva | 2017-12-31 10:23:35 +0100 (Sun, 31 Dec 2017) | 2 lines Use the TSLOG framework to record entry/exit timestamps for VFS_MOUNT calls. -- Herbert ___ 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: invalid bcd 194
On Sun, 2017-12-31 at 09:36 +0100, Matthias Apitz wrote:
> El día sábado, diciembre 30, 2017 a las 10:48:19p. m. +0100, Matthias Apitz
> escribió:
>
> >
> > El día sábado, diciembre 30, 2017 a las 11:11:54p. m. +0200, Konstantin
> > Belousov escribió:
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > static inline u_char
> > > > > > bcd2bin(int bcd)
> > > > > > {
> > > > > >
> > > > > > KASSERT(bcd >= 0 && bcd < LIBKERN_LEN_BCD2BIN,
> > > > > > ("invalid bcd %d", bcd));
> > > > > > return (bcd2bin_data[bcd]);
> > > > > > }
> > > > > >
> >
> > >
> > > For an immediate relief, enter the BIOS setup and set up the date. Try to
> > > change it even if the BIOS date looks fine.
> > >
> > > artc(4) should do more validation of the date read from CMOS, but this is
> > > a known issue.
> > The problem with this hardware (Acer C720 Chromebook) is, there is no
> > BIOS setup, only somekind of SeaBIOS w/o any setup. Btw: An older
> > CURRENT from an USB key r285885 boots fine.
>
> I have got a hint about that the problem showed up already in March this
> year, even with some comment of mine in this thread:
>
> http://freebsd.1045724.x6.nabble.com/panic-invalid-bcd-xxx-td6170480.html
>
> In this tread is mentioned a patch as:
>
> >
> > cem@ posted this patch:
> >
> > http://dpaste.com/1K2W05E
> >
> > If someone can test it, I'll gladly commit it. The real-time clock will
> > likely be wrong, but it won't panic with INVARIANTS.
> but the link is expired. Has got someone this patch? I checked the SVN
> for the file sys/sys/libkern.h there is no relevant change since March
> 2017. (cc'ed cem@)
>
> I will let the C720 over night under power while sitting in the boot menu,
> maybe this will fix the RTC battery issue.
>
Last time I worked on RTC stuff, cleaning this up got put on my "to-do
some day" list. I think maybe that day has arrived.
-- Ian
___
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"
SVN r327433 fails to build
An include file change? I couldn't see the cause :-( The last successful build I have is at SVN r327392. ===> lib/libprocstat (obj,all,install) Building /usr/obj/usr/src/amd64.amd64/lib/libprocstat/zfs/zfs.o In file included from /usr/src/lib/libprocstat/zfs.c:41: /usr/src/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:217:9: error: 'curthread' macro redefined [-Werror,-Wmacro-redefined] #define curthread ((void *)(uintptr_t)thr_self()) ^ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/machine/pcpu.h:230:9: note: previous definition is here #define curthread (__curthread()) ^ In file included from /usr/src/lib/libprocstat/zfs.c:41: /usr/src/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:236:9: error: 'curproc' macro redefined [-Werror,-Wmacro-redefined] #define curproc (&p0) ^ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/sys/pcpu.h:200:9: note: previous definition is here #define curproc (curthread->td_proc) ^ 2 errors generated. ___ 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: invalid bcd 194
El día sábado, diciembre 30, 2017 a las 10:48:19p. m. +0100, Matthias Apitz
escribió:
> El día sábado, diciembre 30, 2017 a las 11:11:54p. m. +0200, Konstantin
> Belousov escribió:
>
> > > > > static inline u_char
> > > > > bcd2bin(int bcd)
> > > > > {
> > > > >
> > > > > KASSERT(bcd >= 0 && bcd < LIBKERN_LEN_BCD2BIN,
> > > > > ("invalid bcd %d", bcd));
> > > > > return (bcd2bin_data[bcd]);
> > > > > }
> > > > >
> > For an immediate relief, enter the BIOS setup and set up the date. Try to
> > change it even if the BIOS date looks fine.
> >
> > artc(4) should do more validation of the date read from CMOS, but this is
> > a known issue.
>
> The problem with this hardware (Acer C720 Chromebook) is, there is no
> BIOS setup, only somekind of SeaBIOS w/o any setup. Btw: An older
> CURRENT from an USB key r285885 boots fine.
I have got a hint about that the problem showed up already in March this
year, even with some comment of mine in this thread:
http://freebsd.1045724.x6.nabble.com/panic-invalid-bcd-xxx-td6170480.html
In this tread is mentioned a patch as:
> cem@ posted this patch:
>
> http://dpaste.com/1K2W05E
>
> If someone can test it, I'll gladly commit it. The real-time clock will
> likely be wrong, but it won't panic with INVARIANTS.
but the link is expired. Has got someone this patch? I checked the SVN
for the file sys/sys/libkern.h there is no relevant change since March
2017. (cc'ed cem@)
I will let the C720 over night under power while sitting in the boot menu,
maybe this will fix the RTC battery issue.
Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ 📱
+49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
signature.asc
Description: PGP signature
