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

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

Dwarf problem with gcc and gdb

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

Re: [PATCH] XOR uses

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

Re: Dwarf problem with gcc and gdb

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

Re: [PATCH] XOR uses

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

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

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

Re: HEADS-UP: Userland debug files enabled by default

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

Re: Panic at shutdown

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. > > >

HEADS-UP: Userland debug files enabled by default

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.

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

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

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

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

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

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

Re: panic: sbuf_vprintf called with a NULL sbuf pointer

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

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

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()

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

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

Re: Dwarf problem with gcc and gdb

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

LOR On AMD64 hosted by KVM hypervisor

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) @

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

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. > >

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

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

Re: slow screen updates on laptop console (i386)

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

Re: panic: sbuf_vprintf called with a NULL sbuf pointer

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 >> >> >

Re: Dwarf problem with gcc and gdb

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

Re: Dwarf problem with gcc and gdb

> 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).

Re: slow screen updates on laptop console (i386)

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. > > > > > >

Re: slow screen updates on laptop console (i386)

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. > > > > > >

Re: slow screen updates on laptop console (i386)

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

> 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

Re: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix

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

Re: slow screen updates on laptop console (i386)

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

Re: slow screen updates on laptop console (i386)

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 >

Re: slow screen updates on laptop console (i386)

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