> 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 invest
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
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
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
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/freebs
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"
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.
> > >
> > > Pleas
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.
> > >
> > > Pleas
> 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 port
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
>> >> > i
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:2
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?)
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
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
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 syscal
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, co
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
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
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 sysc
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
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
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() r
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
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:
> >
> >
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 syscall
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
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 -
> s
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
___
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
we
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
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 no
31 matches
Mail list logo