no. youre giving me random conflicts. unless you have a reason beyond
turdshining now is not good time to do that
On Thursday, 10 March 2016, Martin Pieuchot wrote:
> ok?
>
> Index: vfs_bio.c
> ===
> RCS file: /cvs/src/sys/kern/vfs_
ok?
Index: vfs_bio.c
===
RCS file: /cvs/src/sys/kern/vfs_bio.c,v
retrieving revision 1.173
diff -u -p -r1.173 vfs_bio.c
--- vfs_bio.c 10 Mar 2016 03:09:45 - 1.173
+++ vfs_bio.c 10 Mar 2016 07:15:57 -
@@ -1292,14 +1292
On 10/03/16(Thu) 01:04, Mark Kettenis wrote:
> > Date: Wed, 9 Mar 2016 17:09:13 -0600
> > From: joshua stein
> >
> > Is anyone seriously finding video/Xorg bugs through the default X
> > stipple pattern anymore? Xorg changed the default to draw a black
> > background a while ago (with stipple en
On 09/03/16(Wed) 17:09, joshua stein wrote:
> Is anyone seriously finding video/Xorg bugs through the default X
> stipple pattern anymore? Xorg changed the default to draw a black
> background a while ago (with stipple enabled using the -retro flag),
> but we have this local change that reverted i
Daniel Dickman writes:
> On Wed, Mar 9, 2016 at 9:35 PM, Michael McConville wrote:
>> Jeremie Courreges-Anglas wrote:
>>> >> @@ -66,13 +66,18 @@ main(int argc, char *argv[])
>>> >>argv++;
>>> >>}
>>> >>
>>> >> - while ((ch = getopt(argc, argv, "n:")) != -1) {
>>> >> + while ((c
Stuart Henderson wrote:
> On 2016/03/09 20:49, Stefan Kempf wrote:
> > Here's a diff that allocates the most commonly used amap slot sizes
> > (between 1 and 16) using pool_get(9) instead of malloc(9). That should
> > reduce the pressure on kernel virtual address space somewhat (on amd64
> > at lea
On Wed, Mar 9, 2016 at 9:35 PM, Michael McConville wrote:
> Jeremie Courreges-Anglas wrote:
>> >> @@ -66,13 +66,18 @@ main(int argc, char *argv[])
>> >>argv++;
>> >>}
>> >>
>> >> - while ((ch = getopt(argc, argv, "n:")) != -1) {
>> >> + while ((ch = getopt(argc, argv, "c:n:")) !=
Theo de Raadt writes:
>> >> I don't see any value in being different. Plus, tail(1) already has
>> >> support for -c.
>> >>
>> >> Comments/ok?
>> >
>> > Makes sense and works for me. I'll leave a few comments inline. Also:
>> >
>> >> PS: the next diff will remove documentation for the obsolete
> >> I don't see any value in being different. Plus, tail(1) already has
> >> support for -c.
> >>
> >> Comments/ok?
> >
> > Makes sense and works for me. I'll leave a few comments inline. Also:
> >
> >> PS: the next diff will remove documentation for the obsolete "-count"
> >> syntax.
> >
> > In
Jeremie Courreges-Anglas wrote:
> >> @@ -66,13 +66,18 @@ main(int argc, char *argv[])
> >>argv++;
> >>}
> >>
> >> - while ((ch = getopt(argc, argv, "n:")) != -1) {
> >> + while ((ch = getopt(argc, argv, "c:n:")) != -1) {
> >>switch (ch) {
> >> + case 'c':
>
Michael McConville writes:
> Jeremie Courreges-Anglas wrote:
>> Today someone bumped into a port that contained head -c calls. While
>> upstream could be prodded to care a bit more about portability, support
>> for head -c is widespread (GNU coreutils, busybox, FreeBSD, NetBSD) so
>> I don't see
On Wed, Mar 09, 2016 at 05:09:13PM -0600, joshua stein wrote:
> Is anyone seriously finding video/Xorg bugs through the default X
> stipple pattern anymore? Xorg changed the default to draw a black
> background a while ago (with stipple enabled using the -retro flag),
> but we have this local chan
On 2016/03/09 20:49, Stefan Kempf wrote:
> Here's a diff that allocates the most commonly used amap slot sizes
> (between 1 and 16) using pool_get(9) instead of malloc(9). That should
> reduce the pressure on kernel virtual address space somewhat (on amd64
> at least),
Thanks for the useful inform
Theo de Raadt wrote:
> > > Is anyone seriously finding video/Xorg bugs through the default X
> > > stipple pattern anymore? Xorg changed the default to draw a black
> > > background a while ago (with stipple enabled using the -retro flag),
> > > but we have this local change that reverted it while
Jeremie Courreges-Anglas wrote:
> Today someone bumped into a port that contained head -c calls. While
> upstream could be prodded to care a bit more about portability, support
> for head -c is widespread (GNU coreutils, busybox, FreeBSD, NetBSD) so
> I don't see any value in being different. Plu
> > Is anyone seriously finding video/Xorg bugs through the default X
> > stipple pattern anymore? Xorg changed the default to draw a black
> > background a while ago (with stipple enabled using the -retro flag),
> > but we have this local change that reverted it while adding a silly
> > -retard f
> Date: Wed, 9 Mar 2016 17:09:13 -0600
> From: joshua stein
>
> Is anyone seriously finding video/Xorg bugs through the default X
> stipple pattern anymore? Xorg changed the default to draw a black
> background a while ago (with stipple enabled using the -retro flag),
> but we have this local ch
On Wed, 9 Mar 2016, joshua stein wrote:
> Is anyone seriously finding video/Xorg bugs through the default X
> stipple pattern anymore? Xorg changed the default to draw a black
> background a while ago (with stipple enabled using the -retro flag),
> but we have this local change that reverted it w
These function pointers don't provide any benefit.
They will just get in the way when we merge this driver with rtwn(4).
Tested with:
MAC/BB RTL8188CUS, RF 6052 1T1R
MAC/BB RTL8188EU, RF 6052 1T1R (URTWN_CHIP_88E)
MAC/BB RTL8192CU, RF 6052 2T2R
Index: if_urtwn.c
=
Today someone bumped into a port that contained head -c calls. While
upstream could be prodded to care a bit more about portability, support
for head -c is widespread (GNU coreutils, busybox, FreeBSD, NetBSD) so
I don't see any value in being different. Plus, tail(1) already has
support for -c.
Stuart Henderson wrote:
> While running some fairly memory-hungry jobs I hit a state where wchan
> in top was showing "fltamap" and the machine locked up (couldn't enter
> DDB).
>
> Which must be this:
>
> /* didn't work? must be out of RAM. sleep. */
> if (UVM_ET_IS
rtwn(4) may end up in tsleep(9) while suspending, as shown in dmesg:
Starting stack trace...
tsleep() at tsleep+0x117
rtwn_fw_reset() at rtwn_fw_reset+0x71
rtwn_stop() at rtwn_stop+0x198
rtwn_activate() at rtwn_activate+0x32
config_suspend() at config_suspend+0x37
config_activate_children() at con
rtwn_attach() may fail due to "unsupported test chip".
Unlikely to occur in practice, but still...
Index: ic/rtwn.c
===
RCS file: /cvs/src/sys/dev/ic/rtwn.c,v
retrieving revision 1.1
diff -u -p -r1.1 rtwn.c
--- ic/rtwn.c 9 Mar 2016
On Fri, Feb 12, 2016 at 06:59:02PM +, Edd Barrett wrote:
> Updated diff:
I've now tested the updated diff on sparc64 and amd64 with S malloc
flags for a while. No issues.
Would anyone go as far as "OK"?
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
On 09:42:32, 9.03.16, Michal Mazurek wrote:
> On 22:47:08, 8.03.16, Martin Pieuchot wrote:
> > On 08/03/16(Tue) 10:01, Michal Mazurek wrote:
> > > p_cpu exists, but p_usrpri isn't based on it.
> >
> > Michal I lost track of all your comment fixes. One of the accepted
> > rules when we read code
While running some fairly memory-hungry jobs I hit a state where wchan
in top was showing "fltamap" and the machine locked up (couldn't enter
DDB).
Which must be this:
/* didn't work? must be out of RAM. sleep. */
if (UVM_ET_ISNEEDSCOPY(ufi->entry)) {
On 08/03/16(Tue) 14:05, Michael McConville wrote:
> Martin Pieuchot wrote:
> > On 06/03/16(Sun) 19:20, Michael McConville wrote:
> > > We check static arrays against NULL pretty often in the kernel. I
> > > suspect most of these are due to recent kernel API changes. Should they
> > > be removed, or
On 09/03/16(Wed) 16:26, David Gwynne wrote:
> this is an unfortunately large reworking of vlan(4) to make tx mpsafe
This is great but unfortunately hard to review.
> it also includes the following:
>
> - moving away from the vlan specific SIOC[SG]ETVLAN ioctls to the
> SIOC[SGD]{VNETID,IFPARENT}
Hi,
a future goal for malloc is to use multiple pools in threaded environments,
to reduce lock contention.
This is a small first step towards that goal: move two globals to the
pool-specific struct dir_info. Currently there's only a single pool,
but that will change one day.
Lightly tested by m
> On 6 Mar 2016, at 9:53 PM, Tobias Ulmer wrote:
>
> map is passed straight into free where it gets overwritten with junk.
> No other arch makes map invalid before free, and my N2100 didn't
> suddenly misbehave either.
>
> ok?
ok
>
> Index: arch/arm/arm/bus_dma.c
> ==
On 22:47:08, 8.03.16, Martin Pieuchot wrote:
> On 08/03/16(Tue) 10:01, Michal Mazurek wrote:
> > p_cpu exists, but p_usrpri isn't based on it.
>
> Michal I lost track of all your comment fixes. One of the accepted
> rules when we read code is that comments are always lying. So I doubt
> anyone
On Wed, Mar 09, 2016 at 01:28:55PM +1100, Jonathan Gray wrote:
> On Tue, Mar 08, 2016 at 10:59:42PM +0100, Patrick Wildt wrote:
> > Hi,
> >
> > I'd like to get some opinions on this. ARM8 has probably never ever
> > been used with OpenBSD, and I doubt it will ever be. I think it also
> > makes s
I think we can assume that people have abs(3) these days...
This macro only had one usage, which is visible in the diff. It doesn't
look like replacing it should cause any functional changes to the
arithmetic.
ok?
Index: print-icmp6.c
33 matches
Mail list logo
