Hi,
Just encountered a case where wait(4) + WNOHANG do not fail with
expected ECHILD when there is no process to wait.
The attached testcase illustrate this :
pid = wait4(-1, NULL, 0, NULL);
assert(pid == -1 && errno == ECHILD);
pid = wait4(-1, NULL, WNOHANG, NULL);
assert(pid == -1 &&
Date:Sun, 6 Nov 2016 09:34:17 +0100
From:Nicolas Joly
Message-ID: <20161106083417.ga6...@issan.sis.pasteur.fr>
| Just encountered a case where wait(4) + WNOHANG do not fail with
| expected ECHILD when there is no process to wait.
See man 2 wait ...
When the
On Sun, Nov 06, 2016 at 09:34:17AM +0100, Nicolas Joly wrote:
>
> Hi,
>
> Just encountered a case where wait(4) + WNOHANG do not fail with
> expected ECHILD when there is no process to wait.
>
> The attached testcase illustrate this :
>
> pid = wait4(-1, NULL, 0, NULL);
> assert(pid == -1 &
On Sun, Nov 06, 2016 at 04:39:00PM +0700, Robert Elz wrote:
> Date:Sun, 6 Nov 2016 09:34:17 +0100
> From:Nicolas Joly
> Message-ID: <20161106083417.ga6...@issan.sis.pasteur.fr>
>
> | Just encountered a case where wait(4) + WNOHANG do not fail with
> | expected ECH
Hmmm...
I see that POSIX says ... *about waitpid() - there is no POSIX wait4()
but waitpid() is just wait4() without the rusage arg, which is irrelevant
here)
If waitpid() was invoked with WNOHANG set in options, it has at least
one child process specified by pid for which status is not
JaromÃr,
Earlier, I wrote:
> I can't do automated installs of sparc under qemu>0 because of
> https://bugs.launchpad.net/qemu/+bug/1399943,
After some discussion with the qemu maintainers, it looks like bug
1399943 has been fixed, so I should be able to test your patch after
all, as soon as the b
Hi,
on my Lenovo Thinkpad T410 (i5 M520) the fan was constantly spinning at
3800 rpms
despite core temperatures below 40 degrees celsius. The fan was silent
running under
OpenBSD which uses C3 power states. After enabling C3 with a NetBSD
custom kernel
the fan control works perfect, with tempe
Date:Sun, 6 Nov 2016 10:39:22 +0100
From:Nicolas Joly
Message-ID: <20161106093922.ga10...@issan.sis.pasteur.fr>
| Just tested it on 7.0.2 NetBSD/amd64 under qemu, and it works as
| expected. Looks like a -current regression.
In -current, the primary wait*() inter
On 06.11.2016 11:42, Robert Elz wrote:
> Date:Sun, 6 Nov 2016 10:39:22 +0100
> From:Nicolas Joly
> Message-ID: <20161106093922.ga10...@issan.sis.pasteur.fr>
>
> | Just tested it on 7.0.2 NetBSD/amd64 under qemu, and it works as
> | expected. Looks like a -curren
On 06.11.2016 11:53, Kamil Rytarowski wrote:
>
>
> On 06.11.2016 11:42, Robert Elz wrote:
>> Date:Sun, 6 Nov 2016 10:39:22 +0100
>> From:Nicolas Joly
>> Message-ID: <20161106093922.ga10...@issan.sis.pasteur.fr>
>>
>> | Just tested it on 7.0.2 NetBSD/amd64 under q
This is an automatically generated notice of a new failure of the
NetBSD test suite.
The newly failing test case is:
net/if/t_compat:OOSIOCGIFBRDADDR
The above test failed in each of the last 3 test runs, and passed in
at least 27 consecutive runs before that.
The following commits were mad
Date:Sun, 6 Nov 2016 11:53:06 +0100
From:Kamil Rytarowski
Message-ID:
| I will extend our ATF tests to validate it.
That's good. But test for getting ECHILD from waitpid() - it is fairly
clear that is what should happen.
I am currently testing a fix, but I won'
On 06.11.2016 12:54, Robert Elz wrote:
> Date:Sun, 6 Nov 2016 11:53:06 +0100
> From:Kamil Rytarowski
> Message-ID:
>
> | I will extend our ATF tests to validate it.
>
> That's good. But test for getting ECHILD from waitpid() - it is fairly
> clear that is what
On Sun, Nov 06, 2016 at 05:42:48PM +0700, Robert Elz wrote:
> Date:Sun, 6 Nov 2016 10:39:22 +0100
> From:Nicolas Joly
> Message-ID: <20161106093922.ga10...@issan.sis.pasteur.fr>
>
> | Just tested it on 7.0.2 NetBSD/amd64 under qemu, and it works as
> | expected. L
Hi!
SolidRun Cubox (SoC is Marvell Dove 88AP510. a.k.a. Armada 510) boots!
However, this support has a problem now.
The cpu type of 88AP510 is PJ4. Not CPU_PJ4B. But core is Sheeva 88SV581x.
This mean is confusing in set_cpufuncs().
Also sdhc@mvsoc supports PIO-read only now.
ToDo:
sdhc@mvsoc
On Sun, Nov 06, 2016 at 11:32:21AM +0100, kue...@posteo.de wrote:
> 40 while idle, with fan spinning down. Suspend and resume works fine, I only
> have to switch
> manually to X by using Strg+Alt+F5 after resume, but this was the case with
> the standard
Out of curiosity, does your touchpad show u
Date:Sun, 6 Nov 2016 13:07:45 +0100
From:Kamil Rytarowski
Message-ID:
| Please file a PR for it.
Will do.
| I will reference it in ATF tests - I'm
| preparing a combination of all possible cases.
Sounds good.
| Please make sure that all t_ptrace tests st
On 06.11.2016 15:13, Robert Elz wrote:
> Date:Sun, 6 Nov 2016 13:07:45 +0100
> From:Kamil Rytarowski
> Message-ID:
>
>
> | Please file a PR for it.
>
> Will do.
>
> | I will reference it in ATF tests - I'm
> | preparing a combination of all possible cases.
Date:Sun, 6 Nov 2016 12:30:04 +0100
From:Nicolas Joly
Message-ID: <20161106113004.ga7...@issan.sis.pasteur.fr>
| Don't we need to report an error because of the "shall" wording in the
| ERRORS section.
Possibly. But read the similar text in the error list for w
Date:Sun, 6 Nov 2016 12:30:04 +0100
From:Nicolas Joly
Message-ID: <20161106113004.ga7...@issan.sis.pasteur.fr>
| Don't we need to report an error because of the "shall" wording in the
| ERRORS section.
|
| [...]
| The waitid() function shall fail if:
|
Out of curiosity, does your touchpad show up as pms or ums? I've had
some issues related to that on resume.
It's detected as pms. Full dmesg:
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016
Th
It would seem that the OOSIOCGIFBRDADDR ioctl is part of COMPAT_43. Yet
the test runs in a rump environment, and rump only has COMPAT_50 and
newer. So I would expect this test to fail.
It didn't fail previously because we included sys/compat/common/if_43.c
code all the time, rather than only
On Sun, 30 Oct 2016, John D. Baker wrote:
> Booting GENERIC with "-2c" to disable ACPI and drop into userconf
> permits disabling the "nouveau*" driver after which the process continues
> as above (hangs probing cd0 and wd0 until power button is pressed).
Booting with -12c to disable SMP and ACPI
Updating src tree:
P src/distrib/sets/lists/debug/mi
P src/distrib/sets/lists/tests/mi
P src/external/gpl3/binutils.old/dist/bfd/elf32-ppc.c
P src/external/gpl3/binutils.old/dist/bfd/elf64-ppc.c
P src/share/man/man4/inphy.4
P src/sys/dev/pci/if_msk.c
P src/sys/netinet6/ip6_output.c
P src/tests/dev
24 matches
Mail list logo
