> From: Amit Kulkarni
> Date: Sun, 20 Mar 2016 17:57:49 -0500
>
> On Sat, Mar 19, 2016 at 4:35 PM, Bob wrote:
>
> >
> > I'm also interested in hearing from more people using multi-threaded
> >> applications.
> >>
> >
> > I applied the patch to my old core duo p7570 running CURRENT/amd64.
> > Fi
On Sat, Mar 19, 2016 at 4:35 PM, Bob wrote:
>
> I'm also interested in hearing from more people using multi-threaded
>> applications.
>>
>
> I applied the patch to my old core duo p7570 running CURRENT/amd64.
> Firefox is more responsive and youtube videos, previously impossible to
> watch, run s
On 18.3.2016. 20:00, Mark Kettenis wrote:
> One other important case to test is network packet forwarding. Some
> of our network stack is now running inside a kernel thread. And any
> changes in the scheduling behaviour have the potential of having a
> significant impact there.
I've done some ba
On Sun, Mar 20, 2016 at 09:04:22PM +0100, Norman Golisz wrote:
> Hi Martin,
>
> On Sat Mar 19 2016 13:53, Martin Pieuchot wrote:
> > I'm also interested in hearing from more people using multi-threaded
> > applications.
>
> your patch - just like Michal's - improves the situation a lot.
For now
Hi Martin,
On Sat Mar 19 2016 13:53, Martin Pieuchot wrote:
> I'm also interested in hearing from more people using multi-threaded
> applications.
your patch - just like Michal's - improves the situation a lot.
Watching videos (HD) fullscreen in a browser without stuttering - the
GUI stays respo
> Date: Sat, 19 Mar 2016 14:15:47 +0100
> From: Stefan Sperling
>
> A sparc64 machine of mine crashes every few weeks because the kernel
> runs out of memory.
>
> The crash usually happens in a malloc call in the vnet(4) ioctl code path.
> I have a cronjob which downs/up vnet interfaces in case
> Date: Sat, 19 Mar 2016 09:06:26 +0100
> From: Alexandre Ratchov
>
> On Fri, Mar 18, 2016 at 08:00:35PM +0100, Mark Kettenis wrote:
> > > From: Bob Beck
> > > Date: Fri, 18 Mar 2016 09:20:35 -0600
> > >
> > > this is cool .. but
> > >
> > > I would be interested in someone comparing server wo
On Sat, Mar 19, 2016 at 10:41:06PM +0100, Alexander Bluhm wrote:
> Perhaps the tcps_sc_seedrandom counter with a netstat -s line should
> be commited anyway to show the problem.
ok?
bluhm
Index: sys/netinet/tcp_input.c
===
RCS file:
On Sat, Mar 19, 2016 at 10:41:06PM +0100, Alexander Bluhm wrote:
> The drawback is that the the cache lookup has to be done in two syn
> caches when an ACK arrives.
This can be prevented most of the time. Switch the cache only after
10 uses. So most of the time the passive cache is empty and
I have been asked to prepare a less invasive version of
the MT diffs I posted a week ago. Here it is. It doesn't
delete wsmouse_input(). The old and the new infrastructure
coexist in wsmouse, and only the touchpad drivers have been
changed to use the new one. Except for a stylistic detail
(s/times
Stefan Sperling writes:
> On Fri, Mar 18, 2016 at 01:49:05AM +0100, Jeremie Courreges-Anglas wrote:
>>
>> What's the plan regarding this? libc and locale(1) don't use
>> LOCALE_CHARSETS anymore, we only support UTF-8 and I doubt that we'll
>> change our mind about that.
>>
>> The diff below re
On Mon, Mar 21, 2016 at 12:52:17AM +1100, Jonathan Gray wrote:
> Remove defines for unsupported chips, add V5TEJ and remove incorrect
> ARCH_V7 define. The number ARM Ltd armv7 chips set here is 0xf,
> documented as 'Defined by CPUID scheme'.
>
> Index: armreg.h
>
On Mon, Mar 21, 2016 at 12:52:17AM +1100, Jonathan Gray wrote:
> Remove defines for unsupported chips, add V5TEJ and remove incorrect
> ARCH_V7 define. The number ARM Ltd armv7 chips set here is 0xf,
> documented as 'Defined by CPUID scheme'.
Looks OK to me. Compile tested only.
On Fri, Mar 18, 2016 at 01:49:05AM +0100, Jeremie Courreges-Anglas wrote:
>
> What's the plan regarding this? libc and locale(1) don't use
> LOCALE_CHARSETS anymore, we only support UTF-8 and I doubt that we'll
> change our mind about that.
>
> The diff below removes support for non-UTF-8 LC_CTY
Remove defines for unsupported chips, add V5TEJ and remove incorrect
ARCH_V7 define. The number ARM Ltd armv7 chips set here is 0xf,
documented as 'Defined by CPUID scheme'.
Index: armreg.h
===
RCS file: /cvs/src/sys/arch/arm/include
Unused.
Index: locale/Makefile.inc
===
RCS file: /cvs/src/lib/libc/locale/Makefile.inc,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile.inc
--- locale/Makefile.inc 3 Jul 2015 11:15:19 - 1.20
+++ locale/Makefile.inc 20 M
LOCALE_CHARSETS is unused in locale.c.
Index: Makefile
===
RCS file: /cvs/src/usr.bin/locale/Makefile,v
retrieving revision 1.1
diff -u -p -r1.1 Makefile
--- Makefile3 Jun 2013 14:27:50 - 1.1
+++ Makefile20 Mar 2016
On Sat, Mar 19, 2016 at 05:09:34PM -0400, Brandon Mercer wrote:
> I've recently acquired a usb3.0->gigabit ethernet adapter. It did not
> attach reliably, pass traffic reliably, and it made my machine panic
> when I unplugged it. Takahiro HAYASHI suggested that the reset
> code doesn't do anything
On Sun, Mar 20, 2016 at 11:55:23AM +0100, Stefan Sperling wrote:
> On Sun, Mar 20, 2016 at 10:43:43AM +, Stuart Henderson wrote:
> > While I do see use for this, can people also apply pressure to said
> > ISP to fix their setup as well please? This is basic routing and really
> > shouldn't need
On Sun, Mar 20, 2016 at 10:43:43AM +, Stuart Henderson wrote:
> While I do see use for this, can people also apply pressure to said
> ISP to fix their setup as well please? This is basic routing and really
> shouldn't need bridge hacks. People will need better than a single
> /64 in order to se
On Sat, Mar 19, 2016 at 05:09:34PM -0400, Brandon Mercer wrote:
> I've recently acquired a usb3.0->gigabit ethernet adapter. It did not
> attach reliably, pass traffic reliably, and it made my machine panic
> when I unplugged it. Takahiro HAYASHI suggested that the reset
> code doesn't do anything
While I do see use for this, can people also apply pressure to said
ISP to fix their setup as well please? This is basic routing and really
shouldn't need bridge hacks. People will need better than a single
/64 in order to segregate their IOT crap onto a network that doesn't
have access to their co
On Wed, Mar 16, 2016 at 08:54:22PM +0100, Momtchil Momtchev wrote:
>
> Hello there,
>
> Here is my patch that adds support for creating IPv6-only or IPv4-only
> bridges. This is different from simply blocking one of the protocols via PF
> - it allows you to create a setup where IPv4 is ro
23 matches
Mail list logo
