Okay we will try and do other's test! thank you!
在 2018/12/6 下午3:26, Jan Kiszka 写道:
On 06.12.18 08:24, duanwujie wrote:
We use the xenomai 3.0.7 stable version. Is okay for this ?
No, as I said. You need the latest stable/3.0.x branch because you
need adjustments to the FPU changes.
On 06.12.18 08:24, duanwujie wrote:
We use the xenomai 3.0.7 stable version. Is okay for this ?
No, as I said. You need the latest stable/3.0.x branch because you need
adjustments to the FPU changes.
Jan
在 2018/12/6 下午3:21, Jan Kiszka 写道:
On 06.12.18 08:18, duanwujie wrote:
I am not so
We use the xenomai 3.0.7 stable version. Is okay for this ?
在 2018/12/6 下午3:21, Jan Kiszka 写道:
On 06.12.18 08:18, duanwujie wrote:
I am not so sure, bellow code exist in ipipe-core-4.9.51-x86-2.patch
but ipipe-core-4.9.135-x86-7.patch didn't。
arch/x86/include/asm/fpu/internal.h:
#ifdef
On 06.12.18 08:18, duanwujie wrote:
I am not so sure, bellow code exist in ipipe-core-4.9.51-x86-2.patch but
ipipe-core-4.9.135-x86-7.patch didn't。
arch/x86/include/asm/fpu/internal.h:
#ifdef CONFIG_IPIPE
static inline union fpregs_state *active_fpstate(struct fpu *fpu)
{
return
I am not so sure, bellow code exist in ipipe-core-4.9.51-x86-2.patch but
ipipe-core-4.9.135-x86-7.patch didn't。
arch/x86/include/asm/fpu/internal.h:
#ifdef CONFIG_IPIPE
static inline union fpregs_state *active_fpstate(struct fpu *fpu)
{
return fpu->active_state;
}
#else
static inline union
On 06.12.18 08:04, duanwujie wrote:
It seem to forget port the arch/x86/include/asm/fpu/internal.h in the
ipipe-core-4.9.135-x86-7.patch
You mean that file is missing in the generated patch?
Jan
在 2018/12/6 下午3:00, Jan Kiszka via Xenomai 写道:
On 06.12.18 06:45, limingyu via Xenomai
It seem to forget port the arch/x86/include/asm/fpu/internal.h in the
ipipe-core-4.9.135-x86-7.patch
在 2018/12/6 下午3:00, Jan Kiszka via Xenomai 写道:
On 06.12.18 06:45, limingyu via Xenomai wrote:
I have used this patch(ipipe-core-4.9.135-x86-7.patch) for a test
usage and I got a machine halt
On 05.12.18 16:29, Philippe Gerum wrote:
In order to prevent unexpected truncation of pointer args in userland
with the LP64 data model, libcobalt's fcntl() wrapper should accept a
long (3rd) argument.
Anticipate this change in the corresponding syscall implementation in
the Cobalt core. The
On 05.12.18 16:25, Philippe Gerum wrote:
Signed-off-by: Philippe Gerum
---
drivers/scsi/scsi_devinfo_tbl.c | 25 -
1 file changed, 25 deletions(-)
delete mode 100644 drivers/scsi/scsi_devinfo_tbl.c
diff --git a/drivers/scsi/scsi_devinfo_tbl.c
On 06.12.18 06:45, limingyu via Xenomai wrote:
I have used this patch(ipipe-core-4.9.135-x86-7.patch) for a test usage and I
got a machine halt after I run the latency test program of Xenomai.The problem
seems caused by the fpu_restore function. Could you please fix it in the next
patch
On 05.12.18 16:24, Philippe Gerum wrote:
On 11/4/18 11:52 AM, Philippe Gerum via Xenomai wrote:
On 11/2/18 9:22 AM, Jan Kiszka wrote:
On 02.11.18 04:34, Alec Ari wrote:
This isn't just for x86, this patch includes ppc and arm64 as well. I
was wondering why it was so big! Same story on the
I have used this patch(ipipe-core-4.9.135-x86-7.patch) for a test usage
and I got a machine halt after I run the latency test program of
Xenomai.The problem seems caused by the fpu_restore function. Could you
please fix it in the next patch release?
And here is the result of the panic
Hey Philippe, thank you!
Alec
On 12/5/18 5:17 PM, Jan Kiszka wrote:
> On 05.12.18 16:29, Philippe Gerum wrote:
>> In order to prevent unexpected truncation of pointer args in userland
>> with the LP64 data model, libcobalt's fcntl() wrapper should accept a
>> long (3rd) argument.
>>
>> Anticipate this change in the
On 05.12.18 16:29, Philippe Gerum wrote:
In order to prevent unexpected truncation of pointer args in userland
with the LP64 data model, libcobalt's fcntl() wrapper should accept a
long (3rd) argument.
Anticipate this change in the corresponding syscall implementation in
the Cobalt core. The
On 12/4/18 4:51 PM, Lange Norbert wrote:
> To close this up,
>
> is there anything expected from my side? I am not able to fix up the kernel
> side, esp. with the x32 API,
> and my disagreement with long vs void*/uintptr_t likely won't end up getting
> us anywhere.
>
The kernel patch is on
In order to prevent unexpected truncation of pointer args in userland
with the LP64 data model, libcobalt's fcntl() wrapper should accept a
long (3rd) argument.
Anticipate this change in the corresponding syscall implementation in
the Cobalt core. The updated ABI remains backward-compatible for
Signed-off-by: Philippe Gerum
---
scripts/ipipe/genpatches.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/ipipe/genpatches.sh b/scripts/ipipe/genpatches.sh
index cb83b6aed8fb..cd62d1bf258e 100755
--- a/scripts/ipipe/genpatches.sh
+++ b/scripts/ipipe/genpatches.sh
@@ -61,6 +61,7
Signed-off-by: Philippe Gerum
---
drivers/scsi/scsi_devinfo_tbl.c | 25 -
1 file changed, 25 deletions(-)
delete mode 100644 drivers/scsi/scsi_devinfo_tbl.c
diff --git a/drivers/scsi/scsi_devinfo_tbl.c b/drivers/scsi/scsi_devinfo_tbl.c
deleted file mode 100644
index
On 11/4/18 11:52 AM, Philippe Gerum via Xenomai wrote:
> On 11/2/18 9:22 AM, Jan Kiszka wrote:
>> On 02.11.18 04:34, Alec Ari wrote:
>>> This isn't just for x86, this patch includes ppc and arm64 as well. I
>>> was wondering why it was so big! Same story on the latest 4.4 patch.
>>
>> Huh!
> -Original Message-
> From: Jan Kiszka
> Sent: Dienstag, 4. Dezember 2018 18:59
> To: Lange Norbert
> Cc: Xenomai ; Philippe Gerum
>
> Subject: Re: improve and provide a header for bootstrapping
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION
On 05.12.18 10:32, Johannes Holtz wrote:
Am 04.12.18 um 14:46 schrieb Jan Kiszka:
On 04.12.18 12:04, Johannes Holtz via Xenomai wrote:
Hello,
When I request a socket with AF_RTIPC I get an EAFNOSUPPORT in return.
int sock = socket(AF_RTIPC, SOCK_DGRAM, IPCPROTO_IDDP);
You likely didn't
Am 04.12.18 um 14:46 schrieb Jan Kiszka:
On 04.12.18 12:04, Johannes Holtz via Xenomai wrote:
Hello,
When I request a socket with AF_RTIPC I get an EAFNOSUPPORT in return.
int sock = socket(AF_RTIPC, SOCK_DGRAM, IPCPROTO_IDDP);
You likely didn't wrap this posix application to link against
23 matches
Mail list logo
