On 12/19/18 12:36 PM, Joseph Myers wrote:
> On Wed, 19 Dec 2018, Vineet Gupta wrote:
>
>> So perhaps we keep the ARC header above, with matching layout, while
>> switching to generic sigaction() still. OK ?
>
> If the different userspace layout is better, it should be better for all
> future
> "Nikita" == Nikita Sobolev writes:
> From: NikitaSobolev
> Bump azure-iot-sdk-c to 2018-12-13 release.
> Add patch, that removes Windows specified variables from
> azure-iot-sdk-c-2018-12-13 release. That variables cause
> build errors.
> Signed-off-by: Nikita Sobolev
> ---
>
Seen on ARC when it passed in 1 setup, but segv on other
| Path:
/sd/arc_initramfs_hs_1812-gnu-2018.09-BIG/uClibc-ng-testsuite-Os/rt/tst-posix_spawn
| CPU: 1 PID: 3313 Comm: tst-posix_spawn Not tainted
| 4.19.0-3-ga4e0cf751ad3 #108
|
| [ECR ]: 0x00050100 => Invalid Read @ 0x by
On 12/21/18 10:46 AM, Joseph Myers wrote:
> On Tue, 18 Dec 2018, Vineet Gupta wrote:
>
>> This corresponds to the version
>>
>> Author: law
>> Date: Tue Jun 27 16:10:15 2017 +
>>
>> * longlong.h: Remove ns32k support.
> It seems odd to update from an out-of-date version of
On Tue, 18 Dec 2018, Vineet Gupta wrote:
> This corresponds to the version
>
> Author: law
> Date: Tue Jun 27 16:10:15 2017 +
>
> * longlong.h: Remove ns32k support.
It seems odd to update from an out-of-date version of longlong.h, missing
the subsequent RISC-V changes. So
On 12/21/18 5:04 AM, Michal Hocko wrote:
>> I presume you are referring to original commit, not my anti-change in ARC
>> code,
>> which is actually re-enabling it.
>
> Yes, but you are building on a broken concept I believe.
Not sure where this is heading. Broken concept was introduced by
From: NikitaSobolev
Bump azure-iot-sdk-c to 2018-12-13 release.
Add patch, that removes Windows specified variables from
azure-iot-sdk-c-2018-12-13 release. That variables cause
build errors.
Signed-off-by: Nikita Sobolev
---
...-azure-iot-sdk-c-Delete-windows-variables.patch | 34
On 12/21/18 6:32 AM, Joseph Myers wrote:
> On Fri, 21 Dec 2018, Vineet Gupta wrote:
>
>> is due to linkage of a generic libgcc routine fp-bit.c
>
> I'd suggest moving from fp-bit to soft-fp in libgcc (soft-fp is a lot
> faster, see the 2006 GCC Summit proceedings, though of course you may wish
On Fri, 21 Dec 2018, Vineet Gupta wrote:
> is due to linkage of a generic libgcc routine fp-bit.c
I'd suggest moving from fp-bit to soft-fp in libgcc (soft-fp is a lot
faster, see the 2006 GCC Summit proceedings, though of course you may wish
to do your own benchmarking on ARC), which would
On Fri 21-12-18 14:04:04, Michal Hocko wrote:
[...]
> Yes, but you are building on a broken concept I believe. What
> implications does re-enabling really have? Now you could reschedule and
> you can move to another CPU. Is this really safe? I believe that yes
> because the preemption disabling is
On Thu 20-12-18 18:45:48, Vineet Gupta wrote:
> On 12/20/18 5:04 AM, Michal Hocko wrote:
> > On Tue 18-12-18 10:53:59, Vineet Gupta wrote:
> >> signal handling core calls ARCH show_regs() with preemption disabled
> >> which causes __might_sleep functions such as mmput leading to lockdep
> >>
On 20/12/2018 18:46, Vineet Gupta wrote:
> On 12/20/18 12:06 PM, Adhemerval Zanella wrote:
>>
>>
>> On 20/12/2018 17:23, Vineet Gupta wrote:
>>> On 12/20/18 3:19 AM, Adhemerval Zanella wrote:
>> #define SET_SA_RESTORER(kact, act) \
>> (kact)->sa_flags =
12 matches
Mail list logo
