On Thu, May 14, 2020 at 11:48:31AM +0200, John Paul Adrian Glaubitz wrote:
>
>
> On 5/14/20 9:53 AM, John Paul Adrian Glaubitz wrote:
> > The kernel is currently building, you should get it by the evening (CEST).
> >
> > The machine also serves as a Debian buildd which is why it's a bit more
>
On Thu, May 14, 2020 at 12:45:41PM +0200, Andreas Schwab wrote:
> On Mai 14 2020, Christian Brauner wrote:
>
> > pid = syscall(189 /* __NR_clone2 */, SIGCHLD, stack, STACK_SIZE,
> > NULL, NULL);
>
> Syscall 189 doesn't exist on ia64, they start with 1024 (and __NR_clone2
> is 1213).
On Mai 14 2020, Christian Brauner wrote:
> pid = syscall(189 /* __NR_clone2 */, SIGCHLD, stack, STACK_SIZE,
> NULL, NULL);
Syscall 189 doesn't exist on ia64, they start with 1024 (and __NR_clone2
is 1213).
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578
On Thu, May 14, 2020 at 12:35:49PM +0200, John Paul Adrian Glaubitz wrote:
> On 5/14/20 12:32 PM, Christian Brauner wrote:
> > Do you have a very minimalistic ia64 userspace preferably without systemd
> > where
> > you could simply test. That should give us an idea whether things work:
> >
> >
On Thu, May 14, 2020 at 12:33:00PM +0200, Christian Brauner wrote:
> On Thu, May 14, 2020 at 12:21:13PM +0200, John Paul Adrian Glaubitz wrote:
> > On 5/14/20 12:19 PM, Christian Brauner wrote:
> > > Scratch that. It's even worse. On ia64 it is _invalid_ to pass a NULL
> > > stack. That's at least
On Mai 14 2020, Christian Brauner wrote:
>> static inline pid_t raw_clone(unsigned long flags) {
>> pid_t ret;
>>
>> assert((flags & (CLONE_VM|CLONE_PARENT_SETTID|CLONE_CHILD_SETTID|
>> CLONE_CHILD_CLEARTID|CLONE_SETTLS)) == 0);
>> #if defined(__s390x__)
On 5/14/20 12:32 PM, Christian Brauner wrote:
> Do you have a very minimalistic ia64 userspace preferably without systemd
> where
> you could simply test. That should give us an idea whether things work:
>
> #define _GNU_SOURCE
> #include
> #include
> #include
> #include
> #include
>
On Thu, May 14, 2020 at 12:21:13PM +0200, John Paul Adrian Glaubitz wrote:
> On 5/14/20 12:19 PM, Christian Brauner wrote:
> > Scratch that. It's even worse. On ia64 it is _invalid_ to pass a NULL
> > stack. That's at least what the glibc assembly assumes:
> >
> > cmp.eq p6,p0=0,in0
> >
On 5/14/20 12:19 PM, Christian Brauner wrote:
> Scratch that. It's even worse. On ia64 it is _invalid_ to pass a NULL
> stack. That's at least what the glibc assembly assumes:
>
> cmp.eq p6,p0=0,in0
> cmp.eq p7,p0=0,in1
> mov r8=EINVAL
> mov out0=in3/* Flags
On Thu, May 14, 2020 at 12:15:42PM +0200, Christian Brauner wrote:
> On Thu, May 14, 2020 at 12:08:27PM +0200, John Paul Adrian Glaubitz wrote:
> > On 5/14/20 12:04 PM, Christian Brauner wrote:
> > > So that's interesting because systemd doesn't support itanium correctly
> > > afaict.
> > > They
On Thu, May 14, 2020 at 12:08:27PM +0200, John Paul Adrian Glaubitz wrote:
> On 5/14/20 12:04 PM, Christian Brauner wrote:
> > So that's interesting because systemd doesn't support itanium correctly
> > afaict.
> > They have a raw_clone() function that they use which is not tailored to
> > ia64.
On 5/14/20 12:04 PM, Christian Brauner wrote:
> So that's interesting because systemd doesn't support itanium correctly
> afaict.
> They have a raw_clone() function that they use which is not tailored to
> ia64. __NR_clone should be defined as so to hit clone2() but they don't
> pass a stack size
On Thu, May 14, 2020 at 11:48:31AM +0200, John Paul Adrian Glaubitz wrote:
>
>
> On 5/14/20 9:53 AM, John Paul Adrian Glaubitz wrote:
> > The kernel is currently building, you should get it by the evening (CEST).
> >
> > The machine also serves as a Debian buildd which is why it's a bit more
>
On Thu, May 14, 2020 at 10:58:01AM +0200, Sebastian Andrzej Siewior wrote:
> On 2020-05-14 09:46:06 [+0200], Christian Brauner wrote:
> > > As for getting a working cross-compiler for ia64 in Debian, this has
> > > been on my TODO list for a while now. Building a cross-compiler for
> > > ia64 is a
On 5/14/20 9:53 AM, John Paul Adrian Glaubitz wrote:
> The kernel is currently building, you should get it by the evening (CEST).
>
> The machine also serves as a Debian buildd which is why it's a bit more
> busy than other servers.
I applied the patch against 5.7-rc5, it applied fine and
On 2020-05-14 09:46:06 [+0200], Christian Brauner wrote:
> > As for getting a working cross-compiler for ia64 in Debian, this has
> > been on my TODO list for a while now. Building a cross-compiler for
> > ia64 is a bit more tricky due to it's dependency on the external
> > libunwind.
>
> I hit
On 5/14/20 10:37 AM, Christian Brauner wrote:
>>> Oh? Does it also produce Debian images for ia64 similar to what is done
>>> for sparc64?
>>
>> Yes, it's actually the same person who does this - me ;).
>
> Well thank you very much. Thanks to this I was able to test my sparc
> patches in qemu. :)
On Thu, May 14, 2020 at 10:24:25AM +0200, John Paul Adrian Glaubitz wrote:
> Hi!
>
> On 5/14/20 9:58 AM, Christian Brauner wrote:
> >> The machine also serves as a Debian buildd which is why it's a bit more
> >> busy than other servers.
> >
> > Oh? Does it also produce Debian images for ia64
Hi!
On 5/14/20 9:58 AM, Christian Brauner wrote:
>> The machine also serves as a Debian buildd which is why it's a bit more
>> busy than other servers.
>
> Oh? Does it also produce Debian images for ia64 similar to what is done
> for sparc64?
Yes, it's actually the same person who does this -
On Thu, May 14, 2020 at 09:53:49AM +0200, John Paul Adrian Glaubitz wrote:
> Hi Christian!
>
> On 5/14/20 9:46 AM, Christian Brauner wrote:
> >>> My last functional ia64 machine no longer powers on. Unclear if it's just
> >>> a broken power supply or something more serious. With almost nobody
>
Hi Christian!
On 5/14/20 9:46 AM, Christian Brauner wrote:
>>> My last functional ia64 machine no longer powers on. Unclear if it's just
>>> a broken power supply or something more serious. With almost nobody
>>> in offices/labs anymore my search for another machine is proceeding
>>> slowly.
>>
On Wed, May 13, 2020 at 09:19:41PM +, Luck, Tony wrote:
> > I tried my very best to test this patch including installing Debian 3
> > and 4 to try and get my hands on a gcc version that would allow
> > cross-compiling for ia64. But no, even that wasn't possible let alone a
> > working qemu for
On Wed, May 13, 2020 at 11:26:35PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Tony!
>
> On 5/13/20 11:19 PM, Luck, Tony wrote:
> >> I tried my very best to test this patch including installing Debian 3
> >> and 4 to try and get my hands on a gcc version that would allow
> >> cross-compiling for
Hi Tony!
On 5/13/20 11:19 PM, Luck, Tony wrote:
>> I tried my very best to test this patch including installing Debian 3
>> and 4 to try and get my hands on a gcc version that would allow
>> cross-compiling for ia64. But no, even that wasn't possible let alone a
>> working qemu for ia64. So this
> I tried my very best to test this patch including installing Debian 3
> and 4 to try and get my hands on a gcc version that would allow
> cross-compiling for ia64. But no, even that wasn't possible let alone a
> working qemu for ia64. So this is largely untested but hopefully a
> straightforward
This is part of a larger series that aims at getting rid of the
copy_thread()/copy_thread_tls() split that makes the process creation
codepaths in the kernel more convoluted and error-prone than they need
to be.
I'm converting all the remaining arches that haven't yet switched and
am collecting
26 matches
Mail list logo
