posix_fallocate(2) && posix_fadvise(2) are somewhat broken

[Maxim Sobolev]

Hi, while working on some unrelated feature I've noticed that at least
those two system calls are not returning proper value (-1) on error.
Instead actual errno value is returned from the syscall verbatim,
i.e. posix_fadvise() returns 22 on EINVAL. Attached patch fixes that
problem, however I am not sure if I need to assign td->td_retval[0] at all,
those two operations by design never return anything but -1 on error and 0
on success. Can someone comment on this? Thanks!
diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c
index e675b09..bdb1639 100644
--- a/sys/kern/vfs_syscalls.c
+++ b/sys/kern/vfs_syscalls.c
@@ -4528,7 +4528,7 @@ sys_posix_fallocate(struct thread *td, struct 
posix_fallocate_args *uap)
 
td->td_retval[0] = kern_posix_fallocate(td, uap->fd, uap->offset,
uap->len);
-   return (0);
+   return (td->td_retval[0]);
 }
 
 /*
@@ -4665,5 +4665,5 @@ sys_posix_fadvise(struct thread *td, struct 
posix_fadvise_args *uap)
 
td->td_retval[0] = kern_posix_fadvise(td, uap->fd, uap->offset,
uap->len, uap->advice);
-   return (0);
+   return (td->td_retval[0]);
 }
___
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"

Dwarf problem with gcc and gdb

[Ray Newman]

Hi,

Compiled using gcc (FreeBSD Ports Collection) 4.8.5 on arm (Raspberry Pi - 
several versions); BSDmakefile attached (make test used).
gdb gives:
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 "armv6-marcel-freebsd"...Dwarf Error: wrong version 
in compilation unit header (is 4, should be 2) [in module /home/ray/mumps/mumps]

I need to fix this to find the *real* problem.

Thanks,  Ray


# Makefile for MUMPS BSD
# Copyright (c) Raymond Douglas Newman, 1999 - 2014
# with help from Sam Habiel

CC  =   gcc
LIBS  = -lm -lcrypt
EXTRA = -O -Wall -Iinclude

.ifmake test
EXTRA = -O0 -g  -gdwarf-2 -gstrict-dwarf -ggdb -Wall -Iinclude
.endif

SUBDIRS=compile database init runtime seqio symbol util xcall

RM=rm -f

PROG  = mumps

OBJS=   compile/dollar.o \
compile/eval.o \
compile/localvar.o \
compile/parse.o \
compile/routine.o \
database/db_buffer.o \
database/db_daemon.o \
database/db_get.o \
database/db_ic.o \
database/db_kill.o \
database/db_locate.o \
database/db_main.o \
database/db_rekey.o \
database/db_set.o \
database/db_uci.o \
database/db_util.o \
database/db_view.o \
init/init_create.o \
init/init_run.o \
init/init_start.o \
init/mumps.o \
runtime/runtime_attn.o \
runtime/runtime_buildmvar.o \
runtime/runtime_debug.o \
runtime/runtime_func.o \
runtime/runtime_math.o \
runtime/runtime_pattern.o \
runtime/runtime_run.o \
runtime/runtime_ssvn.o \
runtime/runtime_util.o \
runtime/runtime_vars.o \
seqio/SQ_Util.o \
seqio/SQ_Signal.o \
seqio/SQ_Device.o \
seqio/SQ_File.o \
seqio/SQ_Pipe.o \
seqio/SQ_Seqio.o \
seqio/SQ_Socket.o \
seqio/SQ_Tcpip.o \
symbol/symbol_new.o \
symbol/symbol_util.o \
util/util_key.o \
util/util_lock.o \
util/util_memory.o \
util/util_routine.o \
util/util_share.o \
util/util_strerror.o \
xcall/xcall.o

.c.o:
${CC} ${EXTRA} -c $< -o $@

all: ${OBJS}
${CC} ${EXTRA} -o ${PROG} ${OBJS} ${LIBS}

test: ${OBJS}
${CC} ${EXTRA} -o ${PROG} ${OBJS} ${LIBS}

clean:
rm -f ${OBJS} ${PROG} ${PROG}.core



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PATCH] XOR uses

[Michael McConville]

Marcelo Araujo wrote:
> What would be the advantage of it?

Just clarity and readability.

> I still prefer explicit than implicit. The current code is much more
> readable.

I very much disagree. XOR is a basic binary operation, like AND and OR.
I don't understand what's more explicit about using 4x the code to
reimplement it every time. I don't feel strongly about the patches fate,
though.

> 2015-12-08 11:13 GMT+08:00 Michael McConville :
> 
> > A minor simplification patch:
> >
> >
> > Index: sys/arm/allwinner/a10_gpio.c
> > ===
> > --- sys/arm/allwinner/a10_gpio.c(revision 291978)
> > +++ sys/arm/allwinner/a10_gpio.c(working copy)
> > @@ -356,10 +356,7 @@
> > sc = device_get_softc(dev);
> > A10_GPIO_LOCK(sc);
> > data = A10_GPIO_READ(sc, A10_GPIO_GP_DAT(bank));
> > -   if (data & (1 << pin))
> > -   data &= ~(1 << pin);
> > -   else
> > -   data |= (1 << pin);
> > +   data ^= (1 << pin);
> > A10_GPIO_WRITE(sc, A10_GPIO_GP_DAT(bank), data);
> > A10_GPIO_UNLOCK(sc);
> >
> > Index: sys/arm/altera/socfpga/socfpga_gpio.c
> > ===
> > --- sys/arm/altera/socfpga/socfpga_gpio.c   (revision 291978)
> > +++ sys/arm/altera/socfpga/socfpga_gpio.c   (working copy)
> > @@ -336,10 +336,7 @@
> >
> > GPIO_LOCK(sc);
> > reg = READ4(sc, GPIO_SWPORTA_DR);
> > -   if (reg & (1 << i))
> > -   reg &= ~(1 << i);
> > -   else
> > -   reg |= (1 << i);
> > +   reg ^= (1 << i);
> > WRITE4(sc, GPIO_SWPORTA_DR, reg);
> > GPIO_UNLOCK(sc);
> >
> > Index: sys/arm/rockchip/rk30xx_gpio.c
> > ===
> > --- sys/arm/rockchip/rk30xx_gpio.c  (revision 291978)
> > +++ sys/arm/rockchip/rk30xx_gpio.c  (working copy)
> > @@ -375,10 +375,7 @@
> > return (EINVAL);
> > RK30_GPIO_LOCK(sc);
> > data = RK30_GPIO_READ(sc, RK30_GPIO_SWPORT_DR);
> > -   if (data & (1U << pin))
> > -   data &= ~(1U << pin);
> > -   else
> > -   data |= (1U << pin);
> > +   data ^= (1U << pin);
> > RK30_GPIO_WRITE(sc, RK30_GPIO_SWPORT_DR, data);
> > RK30_GPIO_UNLOCK(sc);
> >
> > Index: sys/arm/samsung/exynos/exynos5_pad.c
> > ===
> > --- sys/arm/samsung/exynos/exynos5_pad.c(revision 291978)
> > +++ sys/arm/samsung/exynos/exynos5_pad.c(working copy)
> > @@ -722,10 +722,7 @@
> >
> > GPIO_LOCK(sc);
> > reg = READ4(sc, bank.port, bank.con + 0x4);
> > -   if (reg & (1 << pin_shift))
> > -   reg &= ~(1 << pin_shift);
> > -   else
> > -   reg |= (1 << pin_shift);
> > +   reg ^= (1 << pin_shift);
> > WRITE4(sc, bank.port, bank.con + 0x4, reg);
> > GPIO_UNLOCK(sc);
> >
> > Index: sys/dev/nand/nandsim_ctrl.c
> > ===
> > --- sys/dev/nand/nandsim_ctrl.c (revision 291978)
> > +++ sys/dev/nand/nandsim_ctrl.c (working copy)
> > @@ -388,9 +388,6 @@
> > rand = random();
> > if ((rand % 100) < chip->error_ratio) {
> > bit = rand % 8;
> > -   if (*byte & (1 << bit))
> > -   *byte &= ~(1 << bit);
> > -   else
> > -   *byte |= (1 << bit);
> > +   *byte ^= (1 << bit);
> > }
> >  }
___
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: Dwarf problem with gcc and gdb

[David Chisnall]

The gdb in the base system doesn’t support DWARF4.  Use gdb791 or lldb-devel 
from ports (I believe gdb791 is probably a better bet on ARM, currently).

David

> On 8 Dec 2015, at 09:02, Ray Newman  wrote:
> 
> Hi,
> 
> Compiled using gcc (FreeBSD Ports Collection) 4.8.5 on arm (Raspberry Pi - 
> several versions); BSDmakefile attached (make test used).
> gdb gives:
> 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 "armv6-marcel-freebsd"...Dwarf Error: wrong 
> version in compilation unit header (is 4, should be 2) [in module 
> /home/ray/mumps/mumps]
> 
> I need to fix this to find the *real* problem.
> 
> Thanks,  Ray
> 
> 
> # Makefile for MUMPS BSD
> # Copyright (c) Raymond Douglas Newman, 1999 - 2014
> # with help from Sam Habiel
> 
> CC  =   gcc
> LIBS  = -lm -lcrypt
> EXTRA = -O -Wall -Iinclude
> 
> .ifmake test
> EXTRA = -O0 -g  -gdwarf-2 -gstrict-dwarf -ggdb -Wall -Iinclude
> .endif
> 
> SUBDIRS=compile database init runtime seqio symbol util xcall
> 
> RM=rm -f
> 
> PROG  = mumps
> 
> OBJS=   compile/dollar.o \
>compile/eval.o \
>compile/localvar.o \
>compile/parse.o \
>compile/routine.o \
>database/db_buffer.o \
>database/db_daemon.o \
>database/db_get.o \
>database/db_ic.o \
>database/db_kill.o \
>database/db_locate.o \
>database/db_main.o \
>database/db_rekey.o \
>database/db_set.o \
>database/db_uci.o \
>database/db_util.o \
>database/db_view.o \
>init/init_create.o \
>init/init_run.o \
>init/init_start.o \
>init/mumps.o \
>runtime/runtime_attn.o \
>runtime/runtime_buildmvar.o \
>runtime/runtime_debug.o \
>runtime/runtime_func.o \
>runtime/runtime_math.o \
>runtime/runtime_pattern.o \
>runtime/runtime_run.o \
>runtime/runtime_ssvn.o \
>runtime/runtime_util.o \
>runtime/runtime_vars.o \
>seqio/SQ_Util.o \
>seqio/SQ_Signal.o \
>seqio/SQ_Device.o \
>seqio/SQ_File.o \
>seqio/SQ_Pipe.o \
>seqio/SQ_Seqio.o \
>seqio/SQ_Socket.o \
>seqio/SQ_Tcpip.o \
>symbol/symbol_new.o \
>symbol/symbol_util.o \
>util/util_key.o \
>util/util_lock.o \
>util/util_memory.o \
>util/util_routine.o \
>util/util_share.o \
>util/util_strerror.o \
>xcall/xcall.o
> 
> .c.o:
>${CC} ${EXTRA} -c $< -o $@
> 
> all: ${OBJS}
>${CC} ${EXTRA} -o ${PROG} ${OBJS} ${LIBS}
> 
> test: ${OBJS}
>${CC} ${EXTRA} -o ${PROG} ${OBJS} ${LIBS}
> 
> clean:
>rm -f ${OBJS} ${PROG} ${PROG}.core
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [PATCH] XOR uses

[Hans Petter Selasky]

On 12/08/15 08:57, Ranjan1018 . wrote:

Hi,

I prefer the syntax in the patch:
- the semantic is more clear for me: if you want to flip a bit you should
use xor
- it saves, probably, some bytes of assembly code

Regards
Maurizio


+1

And it is unconditional.

--HPS
___
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: posix_fallocate(2) && posix_fadvise(2) are somewhat broken

[Dag-Erling Smørgrav]

Maxim Sobolev  writes:
> Hi, while working on some unrelated feature I've noticed that at least
> those two system calls are not returning proper value (-1) on error.
> Instead actual errno value is returned from the syscall verbatim,
> i.e. posix_fadvise() returns 22 on EINVAL.

That's how syscalls work.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
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: HEADS-UP: Userland debug files enabled by default

[Andriy Gapon]

On 08/12/2015 17:27, Ed Maste wrote:
> As of r291955 userland debug files are built and installed by default,
> in order to facilitate debugging. They will be built as part of the
> release process (in FreeBSD 11) so that they can be made available for
> download either at install time, or later on to debug a core file
> after a crash. (Release builds currently require the use of all
> default options.)
> 
> The debug files will be located automatically by gdb or lldb, by
> following the ".gnu_debuglink" section in the binary or library.
> 
> These files occupy additional disk space in the build object directory
> (e.g. /usr/obj) and in the install target filesystem (in
> /usr/lib/debug/...). If you do not want to build and install the debug
> files for any reason, add the following to /etc/src.conf:
> WITHOUT_DEBUG_FILES=YES
> 
> I hope to refine the option further to provide separate control over
> building debug files for binaries and for libraries/rltd.

Thank you very much!  This is a good improvement.

Now I only wish that we could do the same for packages (where possible) :-)

-- 
Andriy Gapon
___
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 at shutdown

[Ranjan1018 .]

2015-11-29 0:10 GMT+01:00 Garrett Cooper :

>
> > On Nov 28, 2015, at 12:32, Ranjan1018 . <21474...@gmail.com> wrote:
> >
> > Hi,
> >
> > sometimes I have the panic in the photo at shutdown:
> >
> > http://imgur.com/mXrgFLp
> >
> > Unfortunately this happens randomly.
> >
> > I am running:
> >
> > $ uname -a
> >
> > FreeBSD ativ 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r291160M: Sun Nov 22
> > 17:10:38 CET 2015 root@ativ:/usr/obj/usr/src/sys/GENERIC  amd64
>
> The panic is in the ZFS code.
>
> Have you run memtest on the machine recently?
>

Good suggestion I have run memtest successfully for few hours on my laptop.

I have understood the panic cause: is an invalid offset.

The original function in
/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c is:

boolean_t
txg_list_member(txg_list_t *tl, void *p, uint64_t txg)
{
int t = txg & TXG_MASK;
txg_node_t *tn = (txg_node_t *)((char *)p + tl->tl_offset);

return (tn->tn_member[t] != 0);
}

I have modified the function to print an uncommon or invalid tl->tl_offset :

boolean_t
txg_list_member(txg_list_t *tl, void *p, uint64_t txg)
{
size_t ofs = tl->tl_offset;
{
static int cnt=0;
if ( (cnt++ % 1000) == 0
|| (ofs != 88 && ofs != 984) )
printf(" %d) tl->tl_offset %zu\n", cnt, ofs);
}

txg_node_t *tn = (txg_node_t *)((char *)p + ofs);

return (tn->tn_member[txg & TXG_MASK] != 0);
}

I have received the panic again with an invalid  tl->tl_offset of
16045693110842147038.
In /val/log/messages I have:

Dec  8 10:32:42 ativ kernel: Waiting (max 60 seconds) for system process
`vnlru' to stop...done
Dec  8 10:32:42 ativ kernel: Waiting (max 60 seconds) for system process
`bufdaemon' to stop...done
Dec  8 10:32:42 ativ kernel: Waiting (max 60 seconds) for system process
`syncer' to stop...
Dec  8 10:32:42 ativ kernel: Syncing disks, vnodes remaining...0 0 0 done
Dec  8 10:32:42 ativ kernel: All buffers synced.
Dec  8 10:32:42 ativ kernel:  9692) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9693) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9694) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9695) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9708) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9709) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9710) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9711) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9720) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9721) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9722) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9723) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel: Uptime: 1h57m42s
Dec  8 10:32:42 ativ kernel:  9736) tl->tl_offset 16045693110842147038
Dec  8 10:32:42 ativ kernel:
Dec  8 10:32:42 ativ kernel:
Dec  8 10:32:42 ativ kernel: Fatal trap 9: general protection fault while
in kernel mode
Dec  8 10:32:42 ativ kernel: cpuid = 2; apic id = 02
Dec  8 10:32:42 ativ kernel: instruction pointer=
0x20:0x8211b1cb
Dec  8 10:32:42 ativ kernel: stack pointer=
0x28:0xfe0119525990
Dec  8 10:32:42 ativ kernel: frame pointer=
0x28:0xfe01195259c0
Dec  8 10:32:42 ativ kernel: code segment= base 0x0, limit 0xf,
type 0x1b
Dec  8 10:32:42 ativ kernel: = DPL 0, pres 1, long 1, def32 0, gran 1
Dec  8 10:32:42 ativ kernel: processor eflags= interrupt enabled,
resume, IOPL = 0
Dec  8 10:32:42 ativ kernel: current process= 0 (dbu_evict)

Probably the panic is caused by some memory already freed, the hex  value
of 16045693110842147038 is 0xdeadc0dedeadc0de.
To solve the panic I need some tips form someone more expert than me in ZFS
code.

Thanks.

-- Maurizio
___
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"

HEADS-UP: Userland debug files enabled by default

[Ed Maste]

As of r291955 userland debug files are built and installed by default,
in order to facilitate debugging. They will be built as part of the
release process (in FreeBSD 11) so that they can be made available for
download either at install time, or later on to debug a core file
after a crash. (Release builds currently require the use of all
default options.)

The debug files will be located automatically by gdb or lldb, by
following the ".gnu_debuglink" section in the binary or library.

These files occupy additional disk space in the build object directory
(e.g. /usr/obj) and in the install target filesystem (in
/usr/lib/debug/...). If you do not want to build and install the debug
files for any reason, add the following to /etc/src.conf:
WITHOUT_DEBUG_FILES=YES

I hope to refine the option further to provide separate control over
building debug files for binaries and for libraries/rltd.
___
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: posix_fallocate(2) && posix_fadvise(2) are somewhat broken

[Maxim Sobolev]

Ah, ok, I see now. It's been broken and still broken in 9.x/10.x, already
fixed in trunk and I been just reading wrong manpage. Thanks for the
pointer, on a related note those fixes should probably be MFCed into 10.3
if it has not been already.

On Tue, Dec 8, 2015 at 9:42 AM, Konstantin Belousov 
wrote:

> On Tue, Dec 08, 2015 at 04:52:05PM +0100, Dag-Erling Sm??rgrav wrote:
> > Maxim Sobolev  writes:
> > > Hi, while working on some unrelated feature I've noticed that at least
> > > those two system calls are not returning proper value (-1) on error.
> > > Instead actual errno value is returned from the syscall verbatim,
> > > i.e. posix_fadvise() returns 22 on EINVAL.
> >
> > That's how syscalls work.
>
> No, this is not how typical syscalls work, but is how the posix_fallocate()
> and posix_fadvise() are specified by Posix.  The patch is wrong, see also
> r261080 and r288640.
>
>
___
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: posix_fallocate(2) && posix_fadvise(2) are somewhat broken

[Garrett Wollman]

In article 
sobo...@freebsd.org writes:

>Hi, while working on some unrelated feature I've noticed that at least
>those two system calls are not returning proper value (-1) on error.
>Instead actual errno value is returned from the syscall verbatim,

That is what the specification requires.

RETURN VALUE
Upon successful completion, posix_fadvise( ) shall return
zero; otherwise, an error number shall be returned to
indicate the error.

(Quote from SUSv7 p. 1410, lines 46221-46223.)

-GAWollman

___
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: posix_fallocate(2) && posix_fadvise(2) are somewhat broken

[Maxim Sobolev]

Then it's documentation bug or maybe some discrepancy between SUS and
POSIX.

$ man posix_fadvise
RETURN VALUES
 The posix_fadvise() function returns the value 0 if successful;
otherwise
 the value -1 is returned and the global variable errno is set to
indicate
 the error.
STANDARDS
 The posix_fadvise() interface conforms to IEEE Std 1003.1-2001
 (``POSIX.1'').

HISTORY
 The posix_fadvise() system call first appeared in FreeBSD 9.1.


On Tue, Dec 8, 2015 at 9:01 AM, Garrett Wollman <
woll...@hergotha.csail.mit.edu> wrote:

> In article  nfgc...@mail.gmail.com>
> sobo...@freebsd.org writes:
>
> >Hi, while working on some unrelated feature I've noticed that at least
> >those two system calls are not returning proper value (-1) on error.
> >Instead actual errno value is returned from the syscall verbatim,
>
> That is what the specification requires.
>
> RETURN VALUE
> Upon successful completion, posix_fadvise( ) shall return
> zero; otherwise, an error number shall be returned to
> indicate the error.
>
> (Quote from SUSv7 p. 1410, lines 46221-46223.)
>
> -GAWollman
>
>
___
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: sbuf_vprintf called with a NULL sbuf pointer

[John Baldwin]

On Monday, December 07, 2015 10:10:51 PM Don Lewis wrote:
> On  2 Dec, John Baldwin wrote:
> > On Wednesday, December 02, 2015 01:25:56 PM Don Lewis wrote:
> >> > If you want to look at this further, try going to frame 16 and 
> >> > dissassembling the
> >> > instructions before the call to see if you can spot which register the 
> >> > first
> >> > parameter (saved in %rdi IIRC) comes from.
> >> 
> >> Dump of assembler code for function sbuf_printf:
> >>0x80a673e0 <+0>:push   %rbp
> >>0x80a673e1 <+1>:mov%rsp,%rbp
> >>0x80a673e4 <+4>:push   %r14
> >>0x80a673e6 <+6>:push   %rbx
> >>0x80a673e7 <+7>:sub$0x50,%rsp
> >>0x80a673eb <+11>:   mov%rsi,%r14
> >>0x80a673ee <+14>:   mov%rdi,%rbx
> >>0x80a673f1 <+17>:   mov%r9,-0x38(%rbp)
> >>0x80a673f5 <+21>:   mov%r8,-0x40(%rbp)
> >>0x80a673f9 <+25>:   mov%rcx,-0x48(%rbp)
> >>0x80a673fd <+29>:   mov%rdx,-0x50(%rbp)
> >>0x80a67401 <+33>:   lea-0x60(%rbp),%rax
> >>0x80a67405 <+37>:   mov%rax,-0x20(%rbp)
> >>0x80a67409 <+41>:   lea0x10(%rbp),%rax
> >>0x80a6740d <+45>:   mov%rax,-0x28(%rbp)
> >>0x80a67411 <+49>:   movl   $0x30,-0x2c(%rbp)
> >>0x80a67418 <+56>:   movl   $0x10,-0x30(%rbp)
> >>0x80a6741f <+63>:   mov$0x8137bdf8,%rdi
> >>0x80a67426 <+70>:   mov%rbx,%rsi
> >>0x80a67429 <+73>:   callq  0x80a66c00 
> >> <_assert_sbuf_integrity>
> >> 
> >> 
> >>0x80a237b9 <+825>:  jmpq   0x80a236fd 
> >>0x80a237be <+830>:  mov$0x80fd8ad3,%rsi
> >>0x80a237c5 <+837>:  xor%eax,%eax
> >>0x80a237c7 <+839>:  mov%r12,%rdi
> >>0x80a237ca <+842>:  mov-0x228(%rbp),%rdx
> >>0x80a237d1 <+849>:  callq  0x80a673e0 
> >> => 0x80a237d6 <+854>:  inc%r14d
> >>0x80a237d9 <+857>:  jmpq   0x80a236fd 
> > 
> > So maybe try 'p $r12' in the corefile_open() frame.
> 
> #17 0x80a237d6 in corefile_open (compress=0, comm=, 
> uid=, pid=, td=, 
> vpp=, namep=)
> at /usr/src/sys/kern/kern_sig.c:3188
> 3188  sbuf_printf(, "%s", comm);
> (kgdb) p $r12
> $1 = 0

So it's definitely zero. :(  The next step is probably to disassemble the
corefile_open function (ugh) and walk backwards to find where %r12 is read
from.  It might be from a local variable on the stack, so then you would
want to examine that memory in the stack and the surrounding memory to see
if there is memory corruption and perhaps if there is anything recognizable
about it (e.g. if the corruption contains some sort of data you recognize,
or if the corruption is bounded by a certain length, etc.).  It's a bit of
a shot in the dark though.

Is this reproducible?

-- 
John Baldwin
___
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: posix_fallocate(2) && posix_fadvise(2) are somewhat broken

[Mark Johnston]

On Tue, Dec 08, 2015 at 01:35:31AM -0800, Maxim Sobolev wrote:
> Hi, while working on some unrelated feature I've noticed that at least
> those two system calls are not returning proper value (-1) on error.
> Instead actual errno value is returned from the syscall verbatim,
> i.e. posix_fadvise() returns 22 on EINVAL. Attached patch fixes that
> problem, however I am not sure if I need to assign td->td_retval[0] at all,
> those two operations by design never return anything but -1 on error and 0
> on success. Can someone comment on this? Thanks!

This behaviour is documented and specified by POSIX. I'm not sure why
these syscalls are inconsistent with everything else, but the current
implementation is correct.
___
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: posix_fallocate(2) && posix_fadvise(2) are somewhat broken

[Konstantin Belousov]

On Tue, Dec 08, 2015 at 04:52:05PM +0100, Dag-Erling Sm??rgrav wrote:
> Maxim Sobolev  writes:
> > Hi, while working on some unrelated feature I've noticed that at least
> > those two system calls are not returning proper value (-1) on error.
> > Instead actual errno value is returned from the syscall verbatim,
> > i.e. posix_fadvise() returns 22 on EINVAL.
> 
> That's how syscalls work.

No, this is not how typical syscalls work, but is how the posix_fallocate()
and posix_fadvise() are specified by Posix.  The patch is wrong, see also
r261080 and r288640.
___
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: Dwarf problem with gcc and gdb

[Dimitry Andric]

On 08 Dec 2015, at 10:02, Ray Newman  wrote:
> 
> Compiled using gcc (FreeBSD Ports Collection) 4.8.5 on arm (Raspberry Pi - 
> several versions); BSDmakefile attached (make test used).
> gdb gives:
> 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 "armv6-marcel-freebsd"...Dwarf Error: wrong 
> version in compilation unit header (is 4, should be 2) [in module 
> /home/ray/mumps/mumps]
> 
> I need to fix this to find the *real* problem.

Since gcc 4.8.0, it defaults to -gdwarf-4.  You must explicitly use
-gdwarf-2, if you want to debug with the version of gdb in base.

Alternatively, use the gdb port, or lldb.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

LOR On AMD64 hosted by KVM hypervisor

[Pete Wright]

Hey All,
I am seeing a repeated LOR on r291495 that is pretty reproducible.  This
happens right after the system boots:

lock order reversal:
 1st 0xfe03e37fa920 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3476
 2nd 0xf80024c72200 dirhash (dirhash) @
/usr/src/sys/ufs/ufs/ufs_dirhash.c:281
stack backtrace:
#0 0x80a7b2e0 at witness_debugger+0x70
#1 0x80a7b1e1 at witness_checkorder+0xe71
#2 0x80a28ab2 at _sx_xlock+0x72
#3 0x80cc0a5d at ufsdirhash_add+0x3d
#4 0x80cc390f at ufs_direnter+0x62f
#5 0x80d3 at ufs_makeinode+0x5f3
#6 0x80cc881d at ufs_create+0x2d
#7 0x80fb2ed1 at VOP_CREATE_APV+0xf1
#8 0x80ae3568 at vn_open_cred+0x2f8
#9 0x80adc8ec at kern_openat+0x25c
#10 0x80e6a4fe at amd64_syscall+0x2de
#11 0x80e4972b at Xfast_syscall+0xfb

Here is the system info:
% uname -ar
FreeBSD bsd-current.trp-srd.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0
r291495: Mon Nov 30 23:14:34 UTC 2015
r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

The server itself is a VM running under the KVM hypervisor.  I am
currently rebuilding world+kernel now.  The base OS image is from the
latest 11-CURRENT snapshot, and I have been able to reproduce this on
several hypervisors.

Has anyone else seen this?

Cheers,
-pete




-- 
Pete Wright
p...@nomadlogic.org
twitter => @nomadlogicLA

___
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: posix_fallocate(2) && posix_fadvise(2) are somewhat broken

[Dag-Erling Smørgrav]

Konstantin Belousov  writes:
> Dag-Erling Smørgrav  writes:
> > Maxim Sobolev  writes:
> > > Hi, while working on some unrelated feature I've noticed that at least
> > > those two system calls are not returning proper value (-1) on error.
> > > Instead actual errno value is returned from the syscall verbatim,
> > > i.e. posix_fadvise() returns 22 on EINVAL.
> > That's how syscalls work.
> No, this is not how typical syscalls work, but is how the posix_fallocate()
> and posix_fadvise() are specified by Posix.  The patch is wrong, see also
> r261080 and r288640.

Umm, I can't find the code ATM but syscalls store the actual return
value in td_retval and return 0 or EWHATEVER and the syscall wrapper
handles the translation.  If that's not what Maxim was talking about,
then please ignore me.

Anyway, happy to hear that the X/Open group have found a new way to
screw people over.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
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: posix_fallocate(2) && posix_fadvise(2) are somewhat broken

[Konstantin Belousov]

On Tue, Dec 08, 2015 at 07:54:06PM +0100, Dag-Erling Sm??rgrav wrote:
> Konstantin Belousov  writes:
> > Dag-Erling Sm??rgrav  writes:
> > > Maxim Sobolev  writes:
> > > > Hi, while working on some unrelated feature I've noticed that at least
> > > > those two system calls are not returning proper value (-1) on error.
> > > > Instead actual errno value is returned from the syscall verbatim,
> > > > i.e. posix_fadvise() returns 22 on EINVAL.
> > > That's how syscalls work.
> > No, this is not how typical syscalls work, but is how the posix_fallocate()
> > and posix_fadvise() are specified by Posix.  The patch is wrong, see also
> > r261080 and r288640.
> 
> Umm, I can't find the code ATM but syscalls store the actual return
> value in td_retval and return 0 or EWHATEVER and the syscall wrapper
> handles the translation.  If that's not what Maxim was talking about,
> then please ignore me.
I mean that typical syscall does not return error to usermode, it
returns -1 and sets errno. But usermode conventions for the posix_f*e()
are different, and I believe this is what tripped over Maxim and I
reacted upon.

Indeed kernel expects the syscall function from the sysentvec table
to return error or zero. If zero is returned, then td_retval array is
translated into return value for usermode by cpu_set_syscall_retval().
If non-zero is returned, typical kernel/libc interface returns the
syscall function return value to usermode and additionally set flag
(like PSL_C in the processor status word). Of course, there is an
additional translation layer in usermode syscall trampolines.


> 
> Anyway, happy to hear that the X/Open group have found a new way to
> screw people over.
It is the same as the pthread_* conventions.  They are somewhat consistent.
___
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: slow screen updates on laptop console (i386)

[John Baldwin]

On Monday, December 07, 2015 06:01:08 PM Rick Macklem wrote:
> Adrian Chadd wrote:
> > Hi,
> > 
> > ok. please file a bug for that. It may be something to do with the
> > hardware and sleep states and skipping wakeups/interrupts or
> > something.
> > 
> > Please try using the default again (LAPIC?) and set
> > kern.eventtimer.periodic=1. See if that fixes it.
> > 
> Actually made it worse. Instead of being intermittently slow, it was
> almost constantly slow.

Try disabling C-states if they are enabled.  If you have a BIOS option
for C1E you might need to disable that as well.  If this fixes it, then
there isn't a really viable solution in software, and you might prefer
to use the RTC to get the power savings from C-states.

-- 
John Baldwin
___
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: sbuf_vprintf called with a NULL sbuf pointer

[Don Lewis]

On  8 Dec, John Baldwin wrote:
> On Monday, December 07, 2015 10:10:51 PM Don Lewis wrote:
>> On  2 Dec, John Baldwin wrote:
>> > On Wednesday, December 02, 2015 01:25:56 PM Don Lewis wrote:
>> >> > If you want to look at this further, try going to frame 16 and 
>> >> > dissassembling the
>> >> > instructions before the call to see if you can spot which register the 
>> >> > first
>> >> > parameter (saved in %rdi IIRC) comes from.
>> >> 
>> >> Dump of assembler code for function sbuf_printf:
>> >>0x80a673e0 <+0>:   push   %rbp
>> >>0x80a673e1 <+1>:   mov%rsp,%rbp
>> >>0x80a673e4 <+4>:   push   %r14
>> >>0x80a673e6 <+6>:   push   %rbx
>> >>0x80a673e7 <+7>:   sub$0x50,%rsp
>> >>0x80a673eb <+11>:  mov%rsi,%r14
>> >>0x80a673ee <+14>:  mov%rdi,%rbx
>> >>0x80a673f1 <+17>:  mov%r9,-0x38(%rbp)
>> >>0x80a673f5 <+21>:  mov%r8,-0x40(%rbp)
>> >>0x80a673f9 <+25>:  mov%rcx,-0x48(%rbp)
>> >>0x80a673fd <+29>:  mov%rdx,-0x50(%rbp)
>> >>0x80a67401 <+33>:  lea-0x60(%rbp),%rax
>> >>0x80a67405 <+37>:  mov%rax,-0x20(%rbp)
>> >>0x80a67409 <+41>:  lea0x10(%rbp),%rax
>> >>0x80a6740d <+45>:  mov%rax,-0x28(%rbp)
>> >>0x80a67411 <+49>:  movl   $0x30,-0x2c(%rbp)
>> >>0x80a67418 <+56>:  movl   $0x10,-0x30(%rbp)
>> >>0x80a6741f <+63>:  mov$0x8137bdf8,%rdi
>> >>0x80a67426 <+70>:  mov%rbx,%rsi
>> >>0x80a67429 <+73>:  callq  0x80a66c00 
>> >> <_assert_sbuf_integrity>
>> >> 
>> >> 
>> >>0x80a237b9 <+825>: jmpq   0x80a236fd 
>> >>0x80a237be <+830>: mov$0x80fd8ad3,%rsi
>> >>0x80a237c5 <+837>: xor%eax,%eax
>> >>0x80a237c7 <+839>: mov%r12,%rdi
>> >>0x80a237ca <+842>: mov-0x228(%rbp),%rdx
>> >>0x80a237d1 <+849>: callq  0x80a673e0 
>> >> => 0x80a237d6 <+854>: inc%r14d
>> >>0x80a237d9 <+857>: jmpq   0x80a236fd 
>> > 
>> > So maybe try 'p $r12' in the corefile_open() frame.
>> 
>> #17 0x80a237d6 in corefile_open (compress=0, comm=, 
>> uid=, pid=, td=, 
>> vpp=, namep=)
>> at /usr/src/sys/kern/kern_sig.c:3188
>> 3188 sbuf_printf(, "%s", comm);
>> (kgdb) p $r12
>> $1 = 0
> 
> So it's definitely zero. :(  The next step is probably to disassemble the
> corefile_open function (ugh) and walk backwards to find where %r12 is read
> from.  It might be from a local variable on the stack, so then you would
> want to examine that memory in the stack and the surrounding memory to see
> if there is memory corruption and perhaps if there is anything recognizable
> about it (e.g. if the corruption contains some sort of data you recognize,
> or if the corruption is bounded by a certain length, etc.).  It's a bit of
> a shot in the dark though.
> 
> Is this reproducible?

No it's not.  The only time it happened was when there was a swap
timeout, probably because of a lengthy deep recovery on one of the
mirrored swap devices.

The code in question is:
struct sbuf sb;
[snip]
(void)sbuf_new(, name, MAXPATHLEN, SBUF_FIXEDLEN);
[snip]
for (i = 0; format[i] != '\0'; i++) {
switch (format[i]) {
case '%':   /* Format character */
i++;
switch (format[i]) {
[snip]
case 'N':   /* process name */
sbuf_printf(, "%s", comm);
break;


 is used in a bunch of places, so the compiler probably computes its
value once by adding the proper offset to the stack pointer and stashing
the result in a register.  Since kern.corefile is "%N.core", the failure
is happening on the first interation of the loop, so there isn't much
opportunity for things to get corrupted.  Also, the control flow in this
function only depends on the format, so there shouldn't be anything
special about a swap timeout vs. a segfault generated core.

How is gdb able to print the register contents for an arbitrary stack
frame?  It's not like this is a SPARC with register windows.  Aren't
only the final register values when the core dump was generated saved
along with the memory contents?  Unless a register contents are pushed
onto the stack, I would think that if a callee overwrites a register,
its contents are gone.

___
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: Dwarf problem with gcc and gdb

[John Baldwin]

On Tuesday, December 08, 2015 12:31:11 PM David Chisnall wrote:
> The gdb in the base system doesn’t support DWARF4.  Use gdb791 or lldb-devel 
> from ports (I believe gdb791 is probably a better bet on ARM, currently).

gdb710 in ports does not support arm (yet).

-- 
John Baldwin
___
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: Dwarf problem with gcc and gdb

[Oleksandr Tymoshenko]

> On Dec 8, 2015, at 10:42 AM, John Baldwin  wrote:
> 
> On Tuesday, December 08, 2015 12:31:11 PM David Chisnall wrote:
>> The gdb in the base system doesn’t support DWARF4.  Use gdb791 or lldb-devel 
>> from ports (I believe gdb791 is probably a better bet on ARM, currently).
> 
> gdb710 in ports does not support arm (yet).

I have half-baked solution for gdb7/arm:

https://people.freebsd.org/~gonzo/arm/gdb7-arm.diff

And cognet@ worked on cross-debugging part, not sure how far he got. 
___
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: slow screen updates on laptop console (i386)

[Rick Macklem]

John Baldwin wrote:
> On Monday, December 07, 2015 06:01:08 PM Rick Macklem wrote:
> > Adrian Chadd wrote:
> > > Hi,
> > > 
> > > ok. please file a bug for that. It may be something to do with the
> > > hardware and sleep states and skipping wakeups/interrupts or
> > > something.
> > > 
> > > Please try using the default again (LAPIC?) and set
> > > kern.eventtimer.periodic=1. See if that fixes it.
> > > 
> > Actually made it worse. Instead of being intermittently slow, it was
> > almost constantly slow.
> 
> Try disabling C-states if they are enabled.  If you have a BIOS option
> for C1E you might need to disable that as well.  If this fixes it, then
> there isn't a really viable solution in software, and you might prefer
> to use the RTC to get the power savings from C-states.
> 
Oh, I do see stuff like:
hw.acpi.cpu.cx_lowest: C2
and
dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/85

Is there a sysctl to disable "C states"?

Thanks, rick
ps: Like I said, I don't care, but maybe Adrian would like me to try settings?

> --
> John Baldwin
> ___
> 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: slow screen updates on laptop console (i386)

[Rick Macklem]

John Baldwin wrote:
> On Monday, December 07, 2015 06:01:08 PM Rick Macklem wrote:
> > Adrian Chadd wrote:
> > > Hi,
> > > 
> > > ok. please file a bug for that. It may be something to do with the
> > > hardware and sleep states and skipping wakeups/interrupts or
> > > something.
> > > 
> > > Please try using the default again (LAPIC?) and set
> > > kern.eventtimer.periodic=1. See if that fixes it.
> > > 
> > Actually made it worse. Instead of being intermittently slow, it was
> > almost constantly slow.
> 
> Try disabling C-states if they are enabled.  If you have a BIOS option
> for C1E you might need to disable that as well.  If this fixes it, then
> there isn't a really viable solution in software, and you might prefer
> to use the RTC to get the power savings from C-states.
> 
Well, if the above refers to stuff that would be in the BIOS setup, there
isn't anything. Nothing setable w.r.t. the processor and there isn't much
of anything under power savings either (a couple of auto-boot options).
- It's a single core i386 Celeron about 8 years old.
(On the other hand, if these C states are something the FreeBSD kernel sets,
 then I don't know how it's done;-)

Btw, I'm perfectly happy running it with RTC. It was Adrian that was interested
in investigating it more.

Thanks, rick

> --
> John Baldwin
> 
___
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: slow screen updates on laptop console (i386)

[Adrian Chadd]

Hi,

Yea - try setting hw.acpi.cpu.cx_lowest=C1 and re-test.


-a
___
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 at shutdown

[NGie Cooper]

> On Dec 8, 2015, at 08:09, Ranjan1018 . <21474...@gmail.com> wrote:

…

> Probably the panic is caused by some memory already freed, the hex  value of 
> 16045693110842147038 is 0xdeadc0dedeadc0de.
> To solve the panic I need some tips form someone more expert than me in ZFS 
> code.

Good investigative work! There was something reported recently about unaligned 
accesses when dealing with msdosfs+zfs+etc, but it was an odd edgecase.

Definitely file a bug and assign it to freebsd-fs@ with the findings you have 
made here.

Thanks :)!
-NGie
___
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: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix

[Bryan Drewery]

On 12/7/15 1:33 PM, Mark Millard wrote:
> 
>> On 2015-Dec-7, at 12:48 PM, Simon J. Gerraty  wrote:
>>
>> Mark Millard  wrote:
>>> My guess is that it is picking up the
>>>
>>> MAKEOBJDIRPREFIX=/usr/obj/xtoolchain
>>
>> You should use ?= if you want this to work.
>> There are many places in Makefile.inc1 where MAKEOBJDIRPREFIX is tweaked
>> in the environment of a sub-make.
>>
>> By using = above, you break that.
> 
> That presumes that MAKEOBJDIRPREFIX has not been assigned a default value 
> before the SRC_ENV_CONF file has been included the first time. If 
> MAKEOBJDIRPREFIX had been defined already then the ?= would do nothing and 
> the wrong value would be used.
> 
> I believe that the following trace shows that such an assignment of a default 
> value does happen first, making ?= not work either.
> 
> 
> 
> /usr/src/Makefile (head/Makefile 29160) has
> 
>> MAKEOBJDIRPREFIX?=  /usr/obj
> 
> at line 145 (used when it is not using targets/Makefile from the relevant 
> .if/.else/.endif).
> 
> Line 105 has .include  and there no others before the above 
> assignment. bsd.compiler.mk in turn includes bsd.opt.mk (only), which in 
> turns includes bsd.mkopt.mk (only). That in turn includes nothing else. So 
> these files and only these files are the involved files before that 
> assignment as far as I can tell.
> 
> None of these get to src.sys.env.mk and so SRC_ENV_CONF use has not happened 
> yet when 
> 
>> MAKEOBJDIRPREFIX?=  /usr/obj
> 
> is executed.
> 
> So, if I understand right, MAKEOBJDIRPREFIX is already defined before the code
> 
>> SRC_ENV_CONF?= /etc/src-env.conf
>> .if !empty(SRC_ENV_CONF) && !target(_src_env_conf_included_)
>> .-include "${SRC_ENV_CONF}"
>> _src_env_conf_included_:.NOTMAIN
>> .endif
> 
> is executed and so using ?= would not be effective in the included file.
> 
> Did I miss something?


Yes. sys.mk and src-env.conf are included *before* Makefile. Think of it
as being in line 0.

Technically you should be able to use MAKEOBJDIRPREFIX in make.conf or
src.conf if you are not using any of the meta mode features (all off by
default).

-- 
Regards,
Bryan Drewery
___
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: slow screen updates on laptop console (i386)

[Adrian Chadd]

ok, can you post the full dmesg? I'd like to know which CPU this is.

Thanks,

-a


On 8 December 2015 at 13:19, Rick Macklem  wrote:
> Adrian Chadd wrote:
>> Hi,
>>
>> Yea - try setting hw.acpi.cpu.cx_lowest=C1 and re-test.
>>
> Yep, with this setting, LAPIC seems to work fine.
>
> rick
>
>>
>> -a
>> ___
>> 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: slow screen updates on laptop console (i386)

[Rick Macklem]

Adrian Chadd wrote:
> Hi,
> 
> Yea - try setting hw.acpi.cpu.cx_lowest=C1 and re-test.
> 
Yep, with this setting, LAPIC seems to work fine.

rick

> 
> -a
> ___
> 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: slow screen updates on laptop console (i386)

[Rick Macklem]

Adrian Chadd wrote:
> ok, can you post the full dmesg? I'd like to know which CPU this is.
> 
Ok, here it is (Kostik already asked, so I have it right here;-):

Copyright (c) 1992-2015 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #4: Sat Dec  5 17:56:08 EST 2015
r...@nfsv4-laptop.rick.home:/usr/src/sys.nov30-2015/i386/compile/GENERIC 
i386
FreeBSD clang version 3.6.1 (tags/RELEASE_361/final 237755) 20150525
WARNING: WITNESS option enabled, expect reduced performance.
VT(vga): resolution 640x480
CPU: Intel(R) Celeron(R) M processor 1.40GHz (1396.57-MHz 686-class CPU)
  Origin="GenuineIntel"  Id=0x6d8  Family=0x6  Model=0xd  Stepping=8
  
Features=0xafe9fbff
  AMD Features=0x10
real memory  = 268435456 (256 MB)
avail memory = 219033600 (208 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
random: unblocking device.
ioapic0: Changing APIC ID to 1
ioapic0  irqs 0-23 on motherboard
random: entropy device external interface
kbd1 at kbdmux0
module_register_init: MOD_LOAD (vesa, 0xc10daf40, 0) error 19
vtvga0:  on motherboard
cryptosoft0:  on motherboard
acpi0:  on motherboard
cpu0:  on acpi0
atrtc0:  port 0x70-0x71,0x72-0x77 irq 8 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x43,0x50-0x53 irq 2 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
acpi_acad0:  on acpi0
battery0:  on acpi0
acpi_lid0:  on acpi0
acpi_button0:  on acpi0
acpi_button1:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
vgapci0:  port 0xeff8-0xefff mem 
0xdff0-0xdff7,0xc000-0xcfff,0xdfec-0xdfef irq 16 at 
device 2.0 on pci0
agp0:  on vgapci0
agp0: aperture size is 256M, detected 7932k stolen memory
vgapci0: Boot video device
vgapci1:  mem 0xdff8-0xdfff at device 2.1 on 
pci0
hdac0:  mem 0xdfebc000-0xdfeb irq 16 at device 
27.0 on pci0
pcib1:  at device 28.0 on pci0
pci1:  on pcib1
pcib2:  at device 28.3 on pci0
pci2:  on pcib2
uhci0:  port 0xbf80-0xbf9f 
irq 16 at device 29.0 on pci0
usbus0 on uhci0
uhci1:  port 0xbf60-0xbf7f 
irq 17 at device 29.1 on pci0
usbus1 on uhci1
uhci2:  port 0xbf40-0xbf5f 
irq 18 at device 29.2 on pci0
usbus2 on uhci2
uhci3:  port 0xbf20-0xbf3f 
irq 19 at device 29.3 on pci0
usbus3 on uhci3
ehci0:  mem 0xb000-0xb3ff irq 
16 at device 29.7 on pci0
usbus4: EHCI version 1.0
usbus4 on ehci0
pcib3:  at device 30.0 on pci0
pci3:  on pcib3
bfe0:  mem 0xdfbfe000-0xdfbf irq 18 at 
device 0.0 on pci3
miibus0:  on bfe0
bmtphy0:  PHY 1 on miibus0
bmtphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
bfe0: Ethernet address: 00:14:22:93:66:a0
isab0:  at device 31.0 on pci0
isa0:  on isab0
atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xbfa0-0xbfaf irq 16 at device 31.1 on pci0
ata0:  at channel 0 on atapci0
ata1:  at channel 1 on atapci0
acpi_tz0:  on acpi0
atkbdc0:  port 0x60,0x64,0x62,0x66 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
psm0:  irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: model Generic PS/2 mouse, device ID 0
pmtimer0 on isa0
orm0:  at iomem 0xc-0xcf7ff,0xcf800-0xc pnpid ORM 
on isa0
ppc0: parallel port not found.
Timecounters tick every 0.976 msec
IPsec: Initialized Security Association Processing.
hdacc0:  at cad 0 on hdac0
hdaa0:  at nid 1 on hdacc0
pcm0:  at nid 14,13 on hdaa0
hdacc1:  at cad 1 on hdac0
unknown:  at nid 2 on hdacc1 
(no driver attached)
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 12Mbps Full Speed USB v1.0
ugen0.1:  at usbus0
uhub0:  on usbus0
ugen1.1:  at usbus1
uhub1:  on usbus1
usbus2: 12Mbps Full Speed USB v1.0
usbus3: 12Mbps Full Speed USB v1.0
ugen2.1:  at usbus2
uhub2:  on usbus2
ugen3.1:  at usbus3
uhub3:  on usbus3
usbus4: 480Mbps High Speed USB v2.0
ugen4.1:  at usbus4
uhub4:  on usbus4
ada0 at ata0 bus 0 scbus0 target 0 lun 0
cd0 at ata0 bus 0 scbus0 target 1 lun 0
cd0:  Removable CD-ROM SCSI device
cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
cd0: Attempt to query device size failed: NOT READY, Medium not present
ada0:  ATA-7 device
ada0: Serial Number S03WJ40YA03331
ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes)
ada0: 38154MB (78140160 512 byte sectors)
Timecounter "TSC" frequency 1396569526 Hz quality 800
WARNING: WITNESS option enabled, expect reduced performance.
Trying to mount root from ufs:/dev/ada0s1a [rw]...
uhub0: 2 ports with 2 removable, self powered
uhub1: 2 ports with 2 removable, self powered
uhub2: 2 ports with 2 removable, self powered
uhub3: 2 ports with 2 removable,