crash: umount_nfs: Current

[Larry Rosenman]

Recent current, playing with new FreeNAS Corral, client is FreeBSD -CURRENT.

Lovely crash:

borg.lerctr.org dumped core - see /var/crash/vmcore.1

Wed Mar 15 21:38:53 CDT 2017

FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r315289: Tue Mar 
14 20:55:36 CDT 2017 r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER  amd64

panic: general protection fault

GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from 
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.

Unread portion of the kernel message buffer:


Fatal trap 9: general protection fault while in kernel mode
cpuid = 1; apic id = 21
instruction pointer = 0x20:0x80a327ae
stack pointer   = 0x28:0xfe535ebb2800
frame pointer   = 0x28:0xfe535ebb2830
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 = 3172 (umount)
trap number = 9
panic: general protection fault
cpuid = 1
time = 1489631515
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe535ebb2440
vpanic() at vpanic+0x19c/frame 0xfe535ebb24c0
panic() at panic+0x43/frame 0xfe535ebb2520
trap_fatal() at trap_fatal+0x322/frame 0xfe535ebb2570
trap() at trap+0x5e/frame 0xfe535ebb2730
calltrap() at calltrap+0x8/frame 0xfe535ebb2730
--- trap 0x9, rip = 0x80a327ae, rsp = 0xfe535ebb2800, rbp = 
0xfe535ebb2830 ---
__mtx_lock_flags() at __mtx_lock_flags+0x3e/frame 0xfe535ebb2830
xprt_unregister() at xprt_unregister+0x28/frame 0xfe535ebb2850
clnt_reconnect_destroy() at clnt_reconnect_destroy+0x38/frame 0xfe535ebb2880
nfs_unmount() at nfs_unmount+0x182/frame 0xfe535ebb28d0
dounmount() at dounmount+0x5c1/frame 0xfe535ebb2950
sys_unmount() at sys_unmount+0x30f/frame 0xfe535ebb2a70
amd64_syscall() at amd64_syscall+0x55a/frame 0xfe535ebb2bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe535ebb2bf0
--- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x800872b9a, rsp = 
0x7fffde88, rbp = 0x7fffe3c0 ---
Uptime: 2h43m8s
Dumping 5744 out of 131005 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

Reading symbols from /boot/kernel/zfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linux.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.
done.
Reading symbols from /boot/kernel/if_lagg.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/if_lagg.ko.debug...done.
done.
Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/coretemp.ko.debug...done.
done.
Reading symbols from /boot/kernel/aesni.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/aesni.ko.debug...done.
done.
Reading symbols from /boot/kernel/filemon.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/filemon.ko.debug...done.
done.
Reading symbols from /boot/kernel/fuse.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/fuse.ko.debug...done.
done.
Reading symbols from /boot/kernel/ichsmb.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/ichsmb.ko.debug...done.
done.
Reading symbols from /boot/kernel/smbus.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/smbus.ko.debug...done.
done.
Reading symbols from /boot/kernel/ichwd.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/ichwd.ko.debug...done.
done.
Reading symbols from /boot/kernel/cpuctl.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/cpuctl.ko.debug...done.
done.
Reading symbols from /boot/kernel/cryptodev.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/cryptodev.ko.debug...done.
done.
Reading symbols from /boot/kernel/dtraceall.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/dtraceall.ko.debug...done.
done.
Reading symbols from /boot/kernel/profile.ko...Reading symbols from 

Re: ntpd dies nightly on a server with jails

[Cy Schubert]

Hi O.Hartmann,

I'll try to answer as much as I can in the noon hour I have left.

In message <20170315071724.78bb0...@freyja.zeit4.iv.bundesimmobilien.de>, 
"O. H
artmann" writes:
> Running a host with several jails on recent CURRENT (12.0-CURRENT #8 r315187:
> Sun Mar 12 11:22:38 CET 2017 amd64) makes me trouble on a daily basis.
> 
> The box is an older two-socket Fujitsu server equipted with two four-core
> Intel(R) Xeon(R) CPU L5420  @ 2.50GHz.
> 
> The box has several jails, each jail does NOT run service ntpd. Each jail has
> its dedicated loopback, lo1 throughout lo5 (for the moment) with dedicated IP
> :
> 127.0.1.1 - 127.0.5.1 (if this matter, I believe not).
> 
> The host itself has two main NICs, broadcom based. bcm0 is dedicated to the
> host, bcm1 is shared amongst the jails: each jail has an IP bound to bcm1 via
> whihc the jails communicate with the network.
> 
> I try to capture log informations via syslog, but FreeBSD's ntpd seems to be
> very, very sparse with such informations, coverging to null - I can't see
> anything suiatble in the logs why NTPD dies almost every night leaving the
> system with a wild reset of time. Sometimes it is a gain of 6 hours, sometime
> s
> it is only half an hour. I leave the box at 16:00 local time usually and take
> care again at ~ 7 o'clock in the morning local time.

We will need to turn on debugging. Unfortunately debug code is not compiled 
into the binary. We have two options. You can either update 
src/usr.sbin/ntp/config.h to enable DEBUG or build the port (it's the exact 
same ntp) with the DEBUG option -- this is probably simpler. Then enable 
debug with -d and -D. -D increases verbosity. I just committed a debug 
option to both ntp ports to assist here.

Next question: Do you see any indication of a core dump? I'd be interested 
in looking at it if possible.

> 
> When the clock is floating that wild, in all cases ntpd isn't running any mor
> e.
> I try to restart with options -g and -G to adjust the time quickly at the
> beginning, which works fine.

This is disconcerting. If your clock is floating wildly without ntpd 
running there are other issues that might be at play here. At most the 
clock might drift a little, maybe a minute or two a day but not by a lot. 
Does the drift cause your clocks to run fast or slow?

> 
> Apart from possible misconfigurations of the jails (I'm quite new to jails an
> d
> their pitfalls), I was wondering what causes ntpd to die. i can't determine
> exactly the time of its death, so it might be related to diurnal/periodic
> processes (I use only the most vanilla configurations on periodic, except for
> checking ZFS's scrubbing enabled).

As I'm a little rushed for time, I didn't catch whether the jails 
themselves were also running ntpd... just thought I'd ask. I don't see how 
zfs scrubbing or any other periodic scripts could cause this.

> 
> I'ven't had the chance to check whether the hardware is completely all right,
> but from a superficial point of view there is no issue with high gain of the
> internal clock or other hardware issues.

It's probably a good idea to check. I don't think that would cause ntpd any 
gas. I've seen RTC battery messages on my gear which haven't caused ntpd 
any problem. I have two machines which complain about RTC battery being 
dead, where in fact I have replaced the batteries and the messages still 
are displayed at boot. I'm not sure if it's possible for a kernel to damage 
the RTC. In my case that doesn't cause ntpd any problems. It's probably 
good to check anyway.

> 
> If there are known issues with jails (the problem occurs since I use those),
> advice is appreciated.

Not that I know of.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
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: fail world build

[Roberto Rodriguez Jr]

Hi,
world is amd64-20170309-r314972
# ls /usr/include/pci
ls: /usr/include/pci: No such file or directory

Havent been able to buildworld since r314495

Thanks
-R

On Wed, Mar 15, 2017 at 11:57 PM, Manfred Antar  wrote:

>
> > On Mar 15, 2017, at 4:44 PM, Roberto Rodriguez Jr <
> rob.rodz@gmail.com> wrote:
> >
> > Hey,
> >
> > r315336
> >
> > --- pciconf.o ---
> > /usr/src/head/usr.sbin/pciconf/pciconf.c:703:3: error: use of
> > undeclared identifier 'PCIC_ACCEL'
> >{PCIC_ACCEL,-1, "processing
> > accelerators"},
> > ^
> > /usr/src/head/usr.sbin/pciconf/pciconf.c:704:3: error: use of
> > undeclared identifier 'PCIC_ACCEL'
> >{PCIC_ACCEL,PCIS_ACCEL_PROCESSING,  "processing
> > accelerators"},
> > ^
> > /usr/src/head/usr.sbin/pciconf/pciconf.c:704:16: error: use of
> > undeclared identifier 'PCIS_ACCEL_PROCESSING'
> >{PCIC_ACCEL,PCIS_ACCEL_PROCESSING,  "processing
> > accelerators"},
> >^
> > /usr/src/head/usr.sbin/pciconf/pciconf.c:705:3: error: use of
> > undeclared identifier 'PCIC_INSTRUMENT'
> >{PCIC_INSTRUMENT,   -1, "non-essential
> > instrumentation"},
> > ^
> > 4 errors generated.
> >
>
> What revision of /usr/include/pci/pcireg.h do you have ?
> I have r315190
>
> Current r315337:
>
> (include)5028}cd /usr/src/usr.sbin/pciconf/
> (pciconf)5029}make obj
> /usr/obj/usr/src/usr.sbin/pciconf created for /usr/src/usr.sbin/pciconf
> (pciconf)5030}make
> echo pciconf: /usr/lib/libc.a  >> .depend
> /usr/local/bin/ccache cc  -O2 -pipe   -MD  -MF.depend.pciconf.o
> -MTpciconf.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall
> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
> -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations
> -Wthread-safety -Wno-empty-body -Wno-string-plus-int
> -Wno-unused-const-variable  -Qunused-arguments  -c
> /usr/src/usr.sbin/pciconf/pciconf.c -o pciconf.o
> /usr/local/bin/ccache cc  -O2 -pipe   -MD  -MF.depend.cap.o -MTcap.o
> -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k
> -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow
> -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs
> -Wredundant-decls -Wold-style-definition -Wno-pointer-sign
> -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body
> -Wno-string-plus-int -Wno-unused-const-variable  -Qunused-arguments  -c
> /usr/src/usr.sbin/pciconf/cap.c -o cap.o
> /usr/local/bin/ccache cc  -O2 -pipe   -MD  -MF.depend.err.o -MTerr.o
> -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k
> -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow
> -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs
> -Wredundant-decls -Wold-style-definition -Wno-pointer-sign
> -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body
> -Wno-string-plus-int -Wno-unused-const-variable  -Qunused-arguments  -c
> /usr/src/usr.sbin/pciconf/err.c -o err.o
> cc -O2 -pipe -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall
> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
> -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations
> -Wthread-safety -Wno-empty-body -Wno-string-plus-int
> -Wno-unused-const-variable -Qunused-arguments  -o pciconf pciconf.o cap.o
> err.o
> gzip -cn /usr/src/usr.sbin/pciconf/pciconf.8 > pciconf.8.gz
> (pciconf)5031}
>
> This is on amd64 current r315337
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
___
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: fail world build

[Manfred Antar]

> On Mar 15, 2017, at 4:44 PM, Roberto Rodriguez Jr  
> wrote:
> 
> Hey,
> 
> r315336
> 
> --- pciconf.o ---
> /usr/src/head/usr.sbin/pciconf/pciconf.c:703:3: error: use of
> undeclared identifier 'PCIC_ACCEL'
>{PCIC_ACCEL,-1, "processing
> accelerators"},
> ^
> /usr/src/head/usr.sbin/pciconf/pciconf.c:704:3: error: use of
> undeclared identifier 'PCIC_ACCEL'
>{PCIC_ACCEL,PCIS_ACCEL_PROCESSING,  "processing
> accelerators"},
> ^
> /usr/src/head/usr.sbin/pciconf/pciconf.c:704:16: error: use of
> undeclared identifier 'PCIS_ACCEL_PROCESSING'
>{PCIC_ACCEL,PCIS_ACCEL_PROCESSING,  "processing
> accelerators"},
>^
> /usr/src/head/usr.sbin/pciconf/pciconf.c:705:3: error: use of
> undeclared identifier 'PCIC_INSTRUMENT'
>{PCIC_INSTRUMENT,   -1, "non-essential
> instrumentation"},
> ^
> 4 errors generated.
> 

What revision of /usr/include/pci/pcireg.h do you have ?
I have r315190

Current r315337:

(include)5028}cd /usr/src/usr.sbin/pciconf/
(pciconf)5029}make obj
/usr/obj/usr/src/usr.sbin/pciconf created for /usr/src/usr.sbin/pciconf
(pciconf)5030}make
echo pciconf: /usr/lib/libc.a  >> .depend
/usr/local/bin/ccache cc  -O2 -pipe   -MD  -MF.depend.pciconf.o -MTpciconf.o 
-std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
-Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations 
-Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
 -Qunused-arguments  -c /usr/src/usr.sbin/pciconf/pciconf.c -o pciconf.o
/usr/local/bin/ccache cc  -O2 -pipe   -MD  -MF.depend.cap.o -MTcap.o -std=gnu99 
-fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
-Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations 
-Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
 -Qunused-arguments  -c /usr/src/usr.sbin/pciconf/cap.c -o cap.o
/usr/local/bin/ccache cc  -O2 -pipe   -MD  -MF.depend.err.o -MTerr.o -std=gnu99 
-fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
-Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations 
-Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
 -Qunused-arguments  -c /usr/src/usr.sbin/pciconf/err.c -o err.o
cc -O2 -pipe -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall 
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings 
-Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline 
-Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign 
-Wmissing-variable-declarations -Wthread-safety -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments  -o pciconf 
pciconf.o cap.o err.o  
gzip -cn /usr/src/usr.sbin/pciconf/pciconf.8 > pciconf.8.gz
(pciconf)5031}

This is on amd64 current r315337


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
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: fail world build

[Roberto Rodriguez Jr]

Hey,

r315336

--- pciconf.o ---
/usr/src/head/usr.sbin/pciconf/pciconf.c:703:3: error: use of
undeclared identifier 'PCIC_ACCEL'
{PCIC_ACCEL,-1, "processing
accelerators"},
 ^
/usr/src/head/usr.sbin/pciconf/pciconf.c:704:3: error: use of
undeclared identifier 'PCIC_ACCEL'
{PCIC_ACCEL,PCIS_ACCEL_PROCESSING,  "processing
accelerators"},
 ^
/usr/src/head/usr.sbin/pciconf/pciconf.c:704:16: error: use of
undeclared identifier 'PCIS_ACCEL_PROCESSING'
{PCIC_ACCEL,PCIS_ACCEL_PROCESSING,  "processing
accelerators"},
^
/usr/src/head/usr.sbin/pciconf/pciconf.c:705:3: error: use of
undeclared identifier 'PCIC_INSTRUMENT'
{PCIC_INSTRUMENT,   -1, "non-essential
instrumentation"},
 ^
4 errors generated.

Repository Root: https://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 315336
Node Kind: directory
Schedule: normal
Last Changed Author: jhb
Last Changed Rev: 315336
Last Changed Date: 2017-03-15 23:08:11 + (Wed, 15 Mar 2017)
___
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"

fail world build

[Roberto Rodriguez Jr]

Hello,

buildkernel as of r315323
GOOD

buildworld FAILS:

/usr/src/head/usr.sbin/pciconf/pciconf.c:703:3: error: use of undeclared
identifier 'PCIC_ACCEL'
{PCIC_ACCEL,-1, "processing
accelerators"},
 ^
/usr/src/head/usr.sbin/pciconf/pciconf.c:704:3: error: use of undeclared
identifier 'PCIC_ACCEL'
{PCIC_ACCEL,PCIS_ACCEL_PROCESSING,  "processing
accelerators"},
 ^
/usr/src/head/usr.sbin/pciconf/pciconf.c:704:16: error: use of undeclared
identifier 'PCIS_ACCEL_PROCESSING'
{PCIC_ACCEL,PCIS_ACCEL_PROCESSING,  "processing
accelerators"},
^
/usr/src/head/usr.sbin/pciconf/pciconf.c:705:3: error: use of undeclared
identifier 'PCIC_INSTRUMENT'
{PCIC_INSTRUMENT,   -1, "non-essential
instrumentation"},
 ^
4 errors generated.

URL: https://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: https://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 315328
Node Kind: directory
Schedule: normal
Last Changed Author: mav
Last Changed Rev: 315327
Last Changed Date: 2017-03-15 19:49:45 + (Wed, 15 Mar 2017)

Reporting live, :)
-R
___
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: Apparent build race(s), r315238 -> r315298

[David Wolfskill]

On Wed, Mar 15, 2017 at 03:40:42PM -0700, Ngie Cooper (yaneurabeya) wrote:
> ... 
> > This should fix it: https://svnweb.freebsd.org/changeset/base/315332 
> > 
> 
> Yeah, that would do it >_>…
> Thanks,
> -Ngie

After hand-applying r315332 to a head@r315298 set of sources, a "normal"
(well, in my environment) build completed without incident.

Thanks! :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Claims that lack evidence are not a basis for rational decision-making.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Apparent build race(s), r315238 -> r315298

[Ngie Cooper (yaneurabeya)]

> On Mar 15, 2017, at 2:19 PM, Bryan Drewery  wrote:
> 
> On 3/15/2017 2:10 PM, Bryan Drewery wrote:
>> On 3/15/2017 11:23 AM, David Wolfskill wrote:
>>> On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote:
 ...
 So where is /common/S4/obj coming from?
 
 Is there a symlink involved here for /usr/obj?
 
>>> 
>>> Yes; I've had /usr/obj as a symlink (to a different file system) for ...
>>> a couple of decades, now
>> 
>> Ok, I don't think the symlink is the problem.  It's just the meta mode
>> handling forcing a realpath(3) on some of the output which causes the
>> confusion.
>> 
>> Still looking...
>> 
>> 
> 
> This should fix it: https://svnweb.freebsd.org/changeset/base/315332 
> 

Yeah, that would do it >_>…
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP

Re: r314708: panic: Assertion err == 0 failed at /usr/src/sys/net/iflib.c:2241

[Bryan Drewery]

On 3/9/2017 1:31 PM, Bryan Drewery wrote:
> This came up at shutdown in r314708. I don't yet know if I will have a
> core to diagnose.
> 
>> panic: Assertion err == 0 failed at /usr/src/sys/net/iflib.c:2241
>> cpuid = 0
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
>> 0xfe349a7f9940
>> vpanic() at vpanic+0x186/frame 0xfe349a7f99c0
>> _kassert_panic() at _kassert_panic+0x12f/frame 0xfe349a7f9a40
>> _task_fn_rx() at _task_fn_rx+0x19d/frame 0xfe349a7f9b20
>> gtaskqueue_run_locked() at gtaskqueue_run_locked+0x139/frame 
>> 0xfe349a7f9b80
>> gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0x88/frame 
>> 0xfe349a7f9bb0
>> fork_exit() at fork_exit+0x84/frame 0xfe349a7f9bf0
>> fork_trampoline() at fork_trampoline+0xe/frame 0xfe349a7f9bf0
>> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
>> KDB: enter: panic
>> [ thread pid 0 tid 100038 ]
>> Stopped at  kdb_enter+0x3b: movq$0,kdb_why
> 

FYI this assertion was removed in r315217 so it's effectively fixed.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: Apparent build race(s), r315238 -> r315298

[Simon J. Gerraty]

Ngie Cooper (yaneurabeya)  wrote:
> Alternatively, could you please revert just r313650 in another 
> branch/workspace (I wonder if changing from .OBJDIR to OBJTOP had some 
> unintended consequences that unrooted issues with how bmake evaluates paths)?

The only change to dir handling in recent bmake is handling of -C where
arg involves symlinks - provided that refers to same dir as getcwd, the
logical value is used.



___
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: Apparent build race(s), r315238 -> r315298

[Bryan Drewery]

On 3/15/2017 2:10 PM, Bryan Drewery wrote:
> On 3/15/2017 11:23 AM, David Wolfskill wrote:
>> On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote:
>>> ...
>>> So where is /common/S4/obj coming from?
>>>
>>> Is there a symlink involved here for /usr/obj?
>>> 
>>
>> Yes; I've had /usr/obj as a symlink (to a different file system) for ...
>> a couple of decades, now
> 
> Ok, I don't think the symlink is the problem.  It's just the meta mode
> handling forcing a realpath(3) on some of the output which causes the
> confusion.
> 
> Still looking...
> 
> 

This should fix it: https://svnweb.freebsd.org/changeset/base/315332

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: Apparent build race(s), r315238 -> r315298

[Bryan Drewery]

On 3/15/2017 11:23 AM, David Wolfskill wrote:
> On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote:
>> ...
>> So where is /common/S4/obj coming from?
>>
>> Is there a symlink involved here for /usr/obj?
>> 
> 
> Yes; I've had /usr/obj as a symlink (to a different file system) for ...
> a couple of decades, now

Ok, I don't think the symlink is the problem.  It's just the meta mode
handling forcing a realpath(3) on some of the output which causes the
confusion.

Still looking...


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]

[Mark Millard]

[Something strange happened to the automatic CC: fill-in for my original
reply. Also I should have mentioned that for my test program if a
variant is made that does not fork the swapping works fine.]

On 2017-Mar-15, at 9:37 AM, Mark Millard  wrote:

> On 2017-Mar-15, at 6:15 AM, Scott Bennett  wrote:
> 
>>On Tue, 14 Mar 2017 18:18:56 -0700 Mark Millard
>>  wrote:
>>> On 2017-Mar-14, at 4:44 PM, Bernd Walter  wrote:
>>> 
 On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote:
> [test_check() between the fork and the wait/sleep prevents the
> failure from occurring. Even a small access to the memory at
> that stage prevents the failure. Details follow.]
 
 Maybe a stupid question, since you might have written it somewhere.
 What medium do you swap to?
 I've seen broken firmware on microSD cards doing silent data
 corruption for some access patterns.
>>> 
>>> The root filesystem is on a USB SSD on a powered hub.
>>> 
>>> Only the kernel is from the microSD card.
>>> 
>>> I have several examples of the USB SSD model and have
>>> never observed such problems in any other context.
>>> 
>>> [remainder of irrelevant material deleted  --SB]
>> 
>>You gave a very long-winded non-answer to Bernd's question, so I'll
>> repeat it here.  What medium do you swap to?
> 
> My wording of:
> 
> The root filesystem is on a USB SSD on a powered hub.
> 
> was definitely poor. It should have explicitly mentioned the
> swap partition too:
> 
> The root filesystem and swap partition are both on the same
> USB SSD on a powered hub.
> 
> More detail from dmesg -a for usb:
> 
> usbus0: 12Mbps Full Speed USB v1.0
> usbus1: 480Mbps High Speed USB v2.0
> usbus2: 12Mbps Full Speed USB v1.0
> usbus3: 480Mbps High Speed USB v2.0
> ugen0.1:  at usbus0
> uhub0:  on usbus0
> ugen1.1:  at usbus1
> uhub1:  on usbus1
> ugen2.1:  at usbus2
> uhub2:  on usbus2
> ugen3.1:  at usbus3
> uhub3:  on usbus3
> . . .
> uhub0: 1 port with 1 removable, self powered
> uhub2: 1 port with 1 removable, self powered
> uhub1: 1 port with 1 removable, self powered
> uhub3: 1 port with 1 removable, self powered
> ugen3.2:  at usbus3
> uhub4 on uhub3
> uhub4:  on usbus3
> uhub4: MTT enabled
> uhub4: 4 ports with 4 removable, self powered
> ugen3.3:  at usbus3
> umass0 on uhub4
> umass0:  on usbus3
> umass0:  SCSI over Bulk-Only; quirks = 0x0100
> umass0:0:0: Attached to scbus0
> . . .
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number 
> da0: 40.000MB/s transfers
> 
> (Edited a bit because there is other material interlaced, even
> internal to some lines. Also: I removed the serial number of the
> specific example device.)
> 
>>I will further note that any kind of USB device cannot automatically
>> be trusted to behave properly.  USB devices are notorious, for example,
>> for momentarily dropping off-line and then immediately reconnecting.  (ZFS
>> reacts very poorly to such events, BTW.)  This misbehavior can be caused
>> by either processor involved, i.e., the one controlling either the
>> upstream or the downstream device.  Hubs are really bad about this, but
>> any USB device can be guilty.  You may have a defective storage device,
>> its controller may be defective, or any controller in the chain all the
>> way back to the motherboard may be defective or, not defective, but
>> corrupted by having been connected to another device with corrupted
>> (infected) firmware that tries to flash itself into the firmware flash
>> chips in its potential victim.
>>Flash memory chips, spinning disks, or {S,}{D,}RAM chips can be
>> defective.  Without parity bits, the devices may return bad data and lie
>> about the presence of corrupted data.  That, for example, is where ZFS
>> is better than any kind of classical RAID because ZFS keeps checksums on
>> everything, so it has a reasonable chance of detecting corruption even
>> without parity support and, if there is any redundancy in the pool or the
>> data set, fixing the bad data machine.  Even having parity generally
>> allows only the detection of single-bit errors, but not of repairing them.
>>You should identify where you page/swap to and then try substituting
>> a different device for that function as a test to eliminate the possibility
>> of a bad storage device/controller.  If the problem still occurs, that
>> means there still remains the possibility that another controller or its
>> firmware is defective instead.  It could be a kernel bug, it is true, but
>> making sure there is no hardware or firmware error occurring is important,
>> and as I say, USB devices should always be considered suspect unless and
>> until proven innocent.
> 
> [FYI: This is a ufs context, not a zfs one.]
> 
> I'm aware of such  things. There is no evidence that has resulted in
> suggesting the USB devices that I can replace are a problem. Otherwise
> I'd not be going down this path. I only have access to the one a

Re: Apparent build race(s), r315238 -> r315298

[Ngie Cooper (yaneurabeya)]

> On Mar 15, 2017, at 11:24, Ngie Cooper (yaneurabeya)  
> wrote:
> 
> 
>> On Mar 15, 2017, at 11:23, David Wolfskill  wrote:
>> 
>> On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote:
>>> ...
>>> So where is /common/S4/obj coming from?
>>> 
>>> Is there a symlink involved here for /usr/obj?
>>> 
>> 
>> Yes; I've had /usr/obj as a symlink (to a different file system) for ...
>> a couple of decades, now
> 
> What happens if you revert r314808 and r315088 (the bmake-20170301 upgrade 
> and supporting commit)?

Alternatively, could you please revert just r313650 in another branch/workspace 
(I wonder if changing from .OBJDIR to OBJTOP had some unintended consequences 
that unrooted issues with how bmake evaluates paths)?
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Apparent build race(s), r315238 -> r315298

[Ngie Cooper (yaneurabeya)]

> On Mar 15, 2017, at 11:23, David Wolfskill  wrote:
> 
> On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote:
>> ...
>> So where is /common/S4/obj coming from?
>> 
>> Is there a symlink involved here for /usr/obj?
>> 
> 
> Yes; I've had /usr/obj as a symlink (to a different file system) for ...
> a couple of decades, now

What happens if you revert r314808 and r315088 (the bmake-20170301 upgrade and 
supporting commit)?
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Apparent build race(s), r315238 -> r315298

[David Wolfskill]

On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote:
> ...
> So where is /common/S4/obj coming from?
> 
> Is there a symlink involved here for /usr/obj?
> 

Yes; I've had /usr/obj as a symlink (to a different file system) for ...
a couple of decades, now

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Claims that lack evidence are not a basis for rational decision-making.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Apparent build race(s), r315238 -> r315298

[Ngie Cooper (yaneurabeya)]

> On Mar 15, 2017, at 11:09, Bryan Drewery  wrote:
> 
> On 3/15/2017 10:04 AM, David Wolfskill wrote:
> 
>> --
> stage 1.1: legacy release compatibility shims
>> --
>> cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/tmp
> 
> Ok it is trying to use MAKEOBJDIRPREFIX=/usr/obj
> 
>> Building /common/S4/obj/usr/src/gnu/usr.bin/gdb/gdbtui/gdbtui
> 
> But all of the 'Building' lines are tryign to use
> MAKEOBJDIRPREFIX=/common/S4/obj/ ...
> 
>> --- all_subdir_cddl ---
>> --- all_subdir_cddl/usr.bin ---
>> --- all_subdir_cddl/usr.bin/zinject ---
>> ===> cddl/usr.bin/zinject (all)
>> --- all_subdir_gnu ---
>> --- gdbtui ---
>> cc: error: no such file or directory: 
>> '/usr/obj/usr/src/gnu/usr.bin/binutils/libbfd/libbfd.a'
> 
> But then complains about a missing file in MAKEOBJDIRPREFIX=/usr/obj
> 
>> *** [gdbtui] Error code 1
>> 
>> bmake[6]: stopped in /usr/src/gnu/usr.bin/gdb/gdbtui
>> .ERROR_TARGET='gdbtui'
>> .ERROR_META_FILE='/common/S4/obj/usr/src/gnu/usr.bin/gdb/gdbtui/gdbtui.meta'
>> .MAKE.LEVEL='6'
>> MAKEFILE=''
>> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
>> .CURDIR='/usr/src/gnu/usr.bin/gdb/gdbtui'
>> .MAKE='/usr/obj/usr/src/make.amd64/bmake'
> ...
>> .OBJDIR='/usr/obj/usr/src/gnu/usr.bin/gdb/gdbtui'
> 
> And says here that there is an existing directory for
> MAKEOBJDIRPREFIX=/usr/obj for /usr/src/gnu/usr.bin/gdb/gdbtui, which is
> throwing off its paths for libbfd.a.
> 
> ...
>> MAKEOBJDIRPREFIX='/usr/obj'
> 
> And the meta error agrees it wants MAKEOBJDIRPREFIX=/usr/obj
> 
> 
> So where is /common/S4/obj coming from?
> 
> Is there a symlink involved here for /usr/obj?

^/head@r315175 doesn’t look like it’s causing a problem here. I don’t 
think my commit here recently (^/head@r313650) was a problem, but I wonder if 
it exposed a race or incomplete dependency logic…
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Apparent build race(s), r315238 -> r315298

[Bryan Drewery]

On 3/15/2017 10:04 AM, David Wolfskill wrote:

> --
 stage 1.1: legacy release compatibility shims
> --
> cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/tmp 

Ok it is trying to use MAKEOBJDIRPREFIX=/usr/obj

> Building /common/S4/obj/usr/src/gnu/usr.bin/gdb/gdbtui/gdbtui

But all of the 'Building' lines are tryign to use
MAKEOBJDIRPREFIX=/common/S4/obj/ ...

> --- all_subdir_cddl ---
> --- all_subdir_cddl/usr.bin ---
> --- all_subdir_cddl/usr.bin/zinject ---
> ===> cddl/usr.bin/zinject (all)
> --- all_subdir_gnu ---
> --- gdbtui ---
> cc: error: no such file or directory: 
> '/usr/obj/usr/src/gnu/usr.bin/binutils/libbfd/libbfd.a'

But then complains about a missing file in MAKEOBJDIRPREFIX=/usr/obj

> *** [gdbtui] Error code 1
> 
> bmake[6]: stopped in /usr/src/gnu/usr.bin/gdb/gdbtui
> .ERROR_TARGET='gdbtui'
> .ERROR_META_FILE='/common/S4/obj/usr/src/gnu/usr.bin/gdb/gdbtui/gdbtui.meta'
> .MAKE.LEVEL='6'
> MAKEFILE=''
> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
> .CURDIR='/usr/src/gnu/usr.bin/gdb/gdbtui'
> .MAKE='/usr/obj/usr/src/make.amd64/bmake'
...
> .OBJDIR='/usr/obj/usr/src/gnu/usr.bin/gdb/gdbtui'

And says here that there is an existing directory for
MAKEOBJDIRPREFIX=/usr/obj for /usr/src/gnu/usr.bin/gdb/gdbtui, which is
throwing off its paths for libbfd.a.

...
 > MAKEOBJDIRPREFIX='/usr/obj'

And the meta error agrees it wants MAKEOBJDIRPREFIX=/usr/obj


So where is /common/S4/obj coming from?

Is there a symlink involved here for /usr/obj?

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Apparent build race(s), r315238 -> r315298

[David Wolfskill]

Both the biuld machine ("freebeast") and my laptop encountered errors
during the "make -jN buildworld" -- each completed on restart, and the
(initially-detected) errors were different:

Build machine:
...
===> usr.bin/mkimg/tests (all)
--- all_subdir_gnu ---
Building /common/S4/obj/usr/src/gnu/usr.bin/gdb/gdbtui/gdbtui
--- all_subdir_cddl ---
--- all_subdir_cddl/usr.bin ---
--- all_subdir_cddl/usr.bin/zinject ---
===> cddl/usr.bin/zinject (all)
--- all_subdir_gnu ---
--- gdbtui ---
cc: error: no such file or directory: 
'/usr/obj/usr/src/gnu/usr.bin/binutils/libbfd/libbfd.a'
*** [gdbtui] Error code 1

bmake[6]: stopped in /usr/src/gnu/usr.bin/gdb/gdbtui
.ERROR_TARGET='gdbtui'
.ERROR_META_FILE='/common/S4/obj/usr/src/gnu/usr.bin/gdb/gdbtui/gdbtui.meta'
.MAKE.LEVEL='6'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
.CURDIR='/usr/src/gnu/usr.bin/gdb/gdbtui'
.MAKE='/usr/obj/usr/src/make.amd64/bmake'
.OBJDIR='/usr/obj/usr/src/gnu/usr.bin/gdb/gdbtui'
.TARGETS='all'
DESTDIR='/usr/obj/usr/src/tmp'
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20160604'
PATH='/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/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'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
/usr/src/share/mk/src.sys.env.mk /etc/src-env.conf 
/usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.conf 
/usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf 
/usr/src/gnu/usr.bin/gdb/gdbtui/Makefile /usr/src/share/mk/bsd.prog.mk 
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk 
/usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk 
/usr/src/share/mk/src.init.mk /usr/src/gnu/usr.bin/gdb/gdbtui/../Makefile.inc 
/usr/src/gnu/usr.bin/gdb/arch/amd64/Makefile 
/usr/src/gnu/usr.bin/gdb/gdbtui/../../Makefile.inc 
/usr/src/gnu/usr.bin/gdb/gdbtui/../../../Makefile.inc 
/usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk 
/usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.libnames.mk 
/usr/src/share/mk/src.libnames.mk /usr/src/share/mk/src.opts.mk 
/usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.confs.mk 
/usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk 
/usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.mk 
/usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk 
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk 
/usr/src/share/mk/bsd.sys.mk'
.PATH='. /usr/src/gnu/usr.bin/gdb/gdbtui /usr/src/contrib/gdb/gdb 
/usr/src/contrib/gdb/gdb/cli /usr/src/contrib/gdb/gdb/mi 
/usr/src/contrib/gdb/gdb/signals /usr/src/contrib/gdb/gdb/tui 
/usr/src/gnu/usr.bin/gdb/arch/amd64'
1 error

bmake[6]: stopped in /usr/src/gnu/usr.bin/gdb/gdbtui
.ERROR_TARGET='gdbtui'



Laptop:
...
===> usr.bin/mkcsmapper_static (obj,build-tools)
--- build-tools_share/syscons/scrnmaps ---
--- obj ---
...
--- obj_crunchdir_rcp ---
--- obj_crunchdir_sync ---
--- obj ---
--- obj_crunchdir_csh ---
--- obj_crunchdir_badsect ---
--- build-tools_usr.bin/mkcsmapper_static ---
--- lex.o ---
/usr/src/usr.bin/mkcsmapper/lex.l:56:25: error: use of undeclared identifier 
'R_LN'
{ linenumber++; return (R_LN); }
^
/usr/src/usr.bin/mkcsmapper/lex.l:70:3: error: use of undeclared identifier 
'yylval'
yylval.i_value = strtoul(yytext, NULL, 0);
^
/usr/src/usr.bin/mkcsmapper/lex.l:71:11: error: use of undeclared identifier 
'L_IMM'
return (L_IMM);
^
/usr/src/usr.bin/mkcsmapper/lex.l:74:11: error: use of undeclared identifier 
'R_TYPE'
{ return (R_TYPE); }
  ^
/usr/src/usr.bin/mkcsmapper/lex.l:75:11: error: use of undeclared identifier 
'R_NAME'
{ return (R_NAME); }
  ^
/usr/src/usr.bin/mkcsmapper/lex.l:76:11: error: use of undeclared identifier 
'R_SRC_ZONE'
{ return (R_SRC_ZONE); }
  ^
/usr/src/usr.bin/mkcsmapper/lex.l:77:11: error: use of undeclared identifier 
'R_DST_INVALID'
{ return (R_DST_INVALID); }
  ^
/usr/src/usr.bin/mkcsmapper/lex.l:78:11: error: use of undeclared identifier 
'R_DST_ILSEQ'
{ return (R_DST_ILSEQ); }
  ^
/usr/src/usr.bin/mkcsmapper/lex.l:79:11: error: use of undeclared identifier 
'R_DST_UNIT_BITS'
{ return (R_DST_UNIT_BITS); }
  ^
/usr/src/usr.bin/mkcsmapper/lex.l:80:11: error: use of undeclared identifier 
'R_BEGIN_MAP'
{ return (R_BEGIN_MAP); }
  ^
/usr/src/usr.bin/mkcsmapper/lex.l:81:11: error: use of undeclared identifier 
'R_END_MAP'
{ return (R_END_MAP); }
  ^
/usr/src/usr.bin/mkcsmapper/lex.l:82:11: error: use of undeclared identifier 
'R_INVALID'
{ return (R_INVALID); }
  ^
/usr/src/usr.bin/mkcsmapper/lex.l:83:11: error: use of undeclared identifier 
'R_ILSEQ'
{ ret