On Fri, 14 Oct 2016, Ilya Kaliman wrote:
> dmesg:
> OpenBSD 6.0 (GENERIC.MP) #1: Thu Sep 8 16:32:34 PDT 2016
> i...@puffy.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
..
> acpiec0 at acpi0: Failed to read resource settings
...
> acpidump:
I've taken a brief look at this. The
It used to be that access to a process's vmspace (and thus its pmap where
the ASID can be found) was only via a thread's p_vmspace member. Now that
the process itself has a copy of that, the loops in the sh code that
iterated across threads to find a valid pointer can be eliminated.
ok?
On Fri, Oct 14, 2016 at 09:24:03AM -0600, Todd C. Miller wrote:
> On Fri, 14 Oct 2016 16:17:45 +0200, Joris Vink wrote:
>
> > In certain cases update -r and update -A would not properly set or reset
> > the sticky tag for file(s). This patch fixes that problem.
>
> After reading through the
dmesg:
OpenBSD 6.0 (GENERIC.MP) #1: Thu Sep 8 16:32:34 PDT 2016
i...@puffy.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 80
real mem = 8468033536 (8075MB)
avail mem = 8206921728 (7826MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at
On Fri, Oct 14, 2016 at 04:49:31PM +0900, YASUOKA Masahiko wrote:
> Hi,
>
> I'm working on NEC Express5800/R110h-1 (dmesg is attached). On this
> machine, our kernel panics with following message.
>
> cpu0 at mainbus0panic: cpu at apic id 0 already attached?
>
> This seems to happen since
> Most of the word movement functions required complete rewrites,
> but the new versions aren't harder to read than the old ones.
>
> I have done some testing, but a bit more might be in order.
>
> OK?
The patch reads fine to me and behaves well in some testing.
It is ok tb@ as is.
I wonder if
Hi Dmitrij,
Dmitrij D. Czarkoff wrote on Fri, Oct 14, 2016 at 01:11:16PM +0200:
> I've noticed that in ksh's vi mode ranged operations are performed
> without respect to cursor's position within utf8 byte sequence. Eg.:
>
> 1. type "echo тест | hexdump -C"
> 2. leave inseart mode
> 3. "0",
On Mon, Sep 26, 2016 at 03:45:59PM +0200, Rafael Zalamena wrote:
> Lets teach snmpd(8) how to fork+exec using the proc.c file from the latest
> switchd(8) diff.
>
> Note 1: I just tested the basic operations: startup and teardown.
> Note 2: the kill with close will be implemented in another diff
Otto Moerbeek wrote:
> Hi,
>
> 0xdb is better dan 0xd0, since it is unaligned in more cases (think
> about the bytes being used as a pointer.
ok
forgot to look at bgpctl in my first reply, sry
Peter Hessler(phess...@openbsd.org) on 2016.10.13 17:34:28 +0200:
> On 2016 Oct 11 (Tue) at 00:00:53 +0200 (+0200), Peter Hessler wrote:
> :Here is an initial implementation of draft-ietf-idr-large-community for
> :OpenBGPD. I can connect and
On Tue, Oct 11, 2016 at 02:02:46AM +0200, Rafael Zalamena wrote:
> This diff brings the relayd(8) proc.c up-to-date and removes the file limit
> alteration in relayd.c. The file limit alteration is not needed anymore
> since now the number of descriptors pre-allocated is very small (only one
>
On Fri, 14 Oct 2016 16:17:45 +0200, Joris Vink wrote:
> In certain cases update -r and update -A would not properly set or reset
> the sticky tag for file(s). This patch fixes that problem.
After reading through the applicable parts of update.c I'm fairly
certain this is correct. OK millert@
Peter Hessler(phess...@openbsd.org) on 2016.10.13 17:34:28 +0200:
> On 2016 Oct 11 (Tue) at 00:00:53 +0200 (+0200), Peter Hessler wrote:
> :Here is an initial implementation of draft-ietf-idr-large-community for
> :OpenBGPD. I can connect and exchange routes with these attributes
> :against
The switch(4) device has a function called switch_forward_flooder()
which doesn't seem to be used anywhere.
In switchofp.c we have the swofp_action_output() which would be the place
where it would be likely called, however it already has the code that
does it.
Since it doesn't seem to fit
On Fri, 14 Oct 2016, YASUOKA Masahiko wrote:
> I'm working on NEC Express5800/R110h-1 (dmesg is attached). On this
> machine, our kernel panics with following message.
>
> cpu0 at mainbus0panic: cpu at apic id 0 already attached?
>
> This seems to happen since x2APIC on the machine is enabled
Hi,
In certain cases update -r and update -A would not properly set or reset
the sticky tag for file(s). This patch fixes that problem.
.joris
Index: update.c
===
RCS file: /cvs/src/usr.bin/cvs/update.c,v
retrieving revision 1.172
On Friday, 14 October 2016 15:48:47 CEST Mark Kettenis wrote:
> > Date: Fri, 14 Oct 2016 16:49:31 +0900 (JST)
> > From: YASUOKA Masahiko
> >
> > Hi,
> >
> > I'm working on NEC Express5800/R110h-1 (dmesg is attached). On this
> > machine, our kernel panics with following
> Date: Fri, 14 Oct 2016 16:49:31 +0900 (JST)
> From: YASUOKA Masahiko
>
> Hi,
>
> I'm working on NEC Express5800/R110h-1 (dmesg is attached). On this
> machine, our kernel panics with following message.
>
> cpu0 at mainbus0panic: cpu at apic id 0 already attached?
>
>
Hi,
when committing ksh(1) vi input mode UTF-8 support recently,
i added a setlocale(3) call to the shell. Now, when considering
how to document LC_CTYPE in the ksh(1) manual, i realized that
inspecting that variable is not really useful, so we can simplify
things, see the diff below.
First,
Hi,
0xdb is better dan 0xd0, since it is unaligned in more cases (think
about the bytes being used as a pointer.
ok?
-Otto
Index: lib/libc/stdlib/malloc.c
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
retrieving
Hi!
I've noticed that in ksh's vi mode ranged operations are performed
without respect to cursor's position within utf8 byte sequence. Eg.:
1. type "echo тест | hexdump -C"
2. leave inseart mode
3. "0", "2E", "dh", Enter
4. you end up with "те" and 0x82 (last byte of letter under cursor).
On 14 October 2016 at 12:40, Mike Belopuhov wrote:
> On Fri, Oct 14, 2016 at 07:58 +0200, Claudio Jeker wrote:
>> It is time to put the nasty comment from rl(4) into em(4) and ix(4).
>> Everybody knew how bad realtek was but thinks Intel nics are good. The
>> truth is that
On Fri, Oct 14, 2016 at 15:48 +1000, David Gwynne wrote:
> this adds a pool backend for MCLGETI thats 2k+2 bytes in size, which
> can be used on some very common nics that have annoying constraints
> on their rx descriptors.
>
> this in turn simplifies the code in those drivers and lets them
>
On Fri, Oct 14, 2016 at 07:58 +0200, Claudio Jeker wrote:
> It is time to put the nasty comment from rl(4) into em(4) and ix(4).
> Everybody knew how bad realtek was but thinks Intel nics are good. The
> truth is that modern Intel nic are as bad as the cheepest and crapiest
> 10/100 Mbps Ethernet
The switch(4) packet_out handler wasn't handling some cases, so here is
the missing code.
1) pout_buffer_id is a 4 bytes field and it was using the wrong define
to check for absence of buffers;
2) When a buffer_id was sent the code didn't handle this, now when this
happens we send an error
On Thu, Oct 13, 2016 at 02:48:07AM +0200, Theo Buehler wrote:
> On Wed, Oct 12, 2016 at 10:30:26PM +0200, Theo Buehler wrote:
> > Several people noticed that a few files from libstdc++-v3 in /usr/obj
> > end up being owned by root, namely:
> >
> > c++config.h gthr.h gthr-single.h gthr-posix.h
Hi,
On Fri, Oct 14, 2016 at 12:56:09AM +0200, Reyk Floeter wrote:
> Using vether in a bridge with the tap allows you to preconfigure a
> fixed interface on the host that doesn't depend on the vm state.
Ah. Yes, and this actually fixes the quirks I mentioned. Using tap
directly is actually *more*
On Fri, Oct 14, 2016 at 10:44:33AM +0200, Peter Hessler wrote:
> While working on Large Communities, I realized that I would really like
> to easily see and know when I am receiving "unknown" attributes.
>
> Patch for tcpdump is easy, if it doesn't have a decoder, just print the
> type and
On 2016/10/13 22:55, Ted Unangst wrote:
> 16 bit IDs don't offer much security. This is well known. A trick to encode
> more bits into the query is to vary the case of the query name. It's case
> insensitive, but all known servers echo it back exactly, case preserving.
Unfortunately not. Many do
While working on Large Communities, I realized that I would really like
to easily see and know when I am receiving "unknown" attributes.
Patch for tcpdump is easy, if it doesn't have a decoder, just print the
type and length. You can use -X to see the raw hex.
Path for bgpctl is a bit more
Hi,
i did some performace tests in current with and without your diff.
There is no difference in performance.
I will try to do performance tests with current on a regular base now.
2016-10-05 10:15 GMT+02:00, Martin Pieuchot :
> On 10/04/16 16:44, Martin Pieuchot wrote:
>> On
ping
On Oct 10 21:39:16, h...@stare.cz wrote:
> The embedded cpmain() will never have _any_ flags set,
> as mv.c calls it as
>
> argv[0] = from;
> argv[1] = to;
> argv[2] = NULL;
> cpmain(2, argv);
>
> There is probably more code that could be romoved
> form the embedded
Hi,
I'm working on NEC Express5800/R110h-1 (dmesg is attached). On this
machine, our kernel panics with following message.
cpu0 at mainbus0panic: cpu at apic id 0 already attached?
This seems to happen since x2APIC on the machine is enabled by BIOS
and the kernel doesn't assume that. The
Index: io.c
===
RCS file: /cvs/src/usr.bin/calendar/io.c,v
retrieving revision 1.44
diff -u -p -r1.44 io.c
--- io.c31 Aug 2016 09:38:47 - 1.44
+++ io.c14 Oct 2016 07:27:52 -
@@ -89,13 +89,9 @@ cal(void)
> On 14 Oct 2016, at 16:17, Ted Unangst wrote:
>
> David Gwynne wrote:
>> this adds a pool backend for MCLGETI thats 2k+2 bytes in size, which
>> can be used on some very common nics that have annoying constraints
>> on their rx descriptors.
>>
>> this in turn simplifies
> Which acpi table should I attach?
Use sendbug(1). See also
http://www.openbsd.org/report.html#bugtypes
David Gwynne wrote:
> this adds a pool backend for MCLGETI thats 2k+2 bytes in size, which
> can be used on some very common nics that have annoying constraints
> on their rx descriptors.
>
> this in turn simplifies the code in those drivers and lets them
> always operate on ETHER_ALIGN
37 matches
Mail list logo