The link for a BSD book points to a C# book.
Here is the patch:
Index: books.html
===
RCS file: /cvs/www/books.html,v
retrieving revision 1.110
diff -r1.110 books.html
101c101
< At 549 pages plus an index,
On Tue, 31 Jan 2017, Sebastien Marie wrote:
> On Tue, Jan 31, 2017 at 12:07:48AM -0800, Philip Guenther wrote:
> > Sun, 29 Jan 2017, Philip Guenther wrote:
> > ...
> >
> > semarie@, you can consistently trigger that kernel log message, perhaps
> > you can try reproducing it with this patch and
Don't know if related. After upgrading to 30 Jan snapshot (amd64)
my console shows lots of:
splassert: yield: want 0 have 1
dmesg:
OpenBSD 6.0-current (GENERIC.MP) #158: Mon Jan 30 19:30:12 MST 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem =
On 01/31/17 15:34, Stefan Sperling wrote:
> On Tue, Jan 31, 2017 at 03:36:21PM +0300, Soner Tari wrote:
>>> Synopsis: With large line numbers, tail(1) makes the system unusable.
>>> Category: system
>>> Environment:
>> System : OpenBSD 6.0
>> Details : OpenBSD 6.0 (GENERIC)
On Tue, Jan 31, 2017 at 03:36:21PM +0300, Soner Tari wrote:
> >Synopsis: With large line numbers, tail(1) makes the system unusable.
> >Category: system
> >Environment:
> System : OpenBSD 6.0
> Details : OpenBSD 6.0 (GENERIC) #2148: Tue Jul 26 12:55:20
> MDT 2016
>
>Synopsis: With large line numbers, tail(1) makes the system unusable.
>Category: system
>Environment:
System : OpenBSD 6.0
Details : OpenBSD 6.0 (GENERIC) #2148: Tue Jul 26 12:55:20
MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/am
On 30/01/17(Mon) 22:02, Pedro Caetano wrote:
> Hi,
>
> On three of six VMs the following stack trace has been shown on logs.
> All the systems are amd64 running the same snapshot, sources fecthed from
> cvs january 28th, the only that crashed were running ospfd.
>
> stacks and dmesg below.
On Tue, Jan 31, 2017 at 12:07:48AM -0800, Philip Guenther wrote:
> Sun, 29 Jan 2017, Philip Guenther wrote:
> ...
>
> semarie@, you can consistently trigger that kernel log message, perhaps
> you can try reproducing it with this patch and see if it goes away?
it is a bit better now: I have only
Sun, 29 Jan 2017, Philip Guenther wrote:
...
> Indeed, the exec_elf.c side of that is already there, though currently
> it's only in play for the stack on hppa: check out the
> MACHINE_STACK_GROWS_UP section of uvm_coredump_walkmap() in
> uvm/uvm_unix.c.Actually, that code looks broken, as
