Re: chroot in its own ext2fs?

2014-05-02 Thread Justus Winter
Hi :) Quoting Samuel Thibault (2014-05-02 02:22:01) Does anybody remember precisely why chroots should have their own ext2fs? I can build packages fine from inside a chroot which doesn't have its own ext2fs, for instance. I thought only subhurds need their own translator? Justus

Re: chroot in its own ext2fs?

2014-05-02 Thread Samuel Thibault
Justus Winter, le Fri 02 May 2014 09:15:44 +0200, a écrit : Quoting Samuel Thibault (2014-05-02 02:22:01) Does anybody remember precisely why chroots should have their own ext2fs? I can build packages fine from inside a chroot which doesn't have its own ext2fs, for instance. I thought

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

2014-05-02 Thread Svante Signell
On Fri, 2014-05-02 at 00:45 +0200, Samuel Thibault wrote: Hello, Svante Signell, le Thu 24 Apr 2014 10:39:10 +0200, a écrit : - Without split stack enabled around 70 libgo tests pass and 50 fails, most of them with a segfault. - Enabling split stack and using the libc Samuel built all

Re: chroot in its own ext2fs?

2014-05-02 Thread Michael Banck
Hi, On Fri, May 02, 2014 at 02:22:01AM +0200, Samuel Thibault wrote: Does anybody remember precisely why chroots should have their own ext2fs? I can build packages fine from inside a chroot which doesn't have its own ext2fs, for instance. I don't recall why we did that, maybe it was purely

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

2014-05-02 Thread Samuel Thibault
Svante Signell, le Fri 02 May 2014 10:18:12 +0200, a écrit : Thread 4 (Thread 1205.4): #0 0x019977b7 in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:132 err = optimized out err = optimized out user_option = 3 user_timeout = 48 m = 0x532370

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

2014-05-02 Thread Samuel Thibault
Svante Signell, le Fri 02 May 2014 10:03:23 +0200, a écrit : On Fri, 2014-05-02 at 00:45 +0200, Samuel Thibault wrote: Hello, Svante Signell, le Thu 24 Apr 2014 10:39:10 +0200, a écrit : - Without split stack enabled around 70 libgo tests pass and 50 fails, most of them with a

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

2014-05-02 Thread Samuel Thibault
Svante Signell, le Fri 02 May 2014 10:18:12 +0200, a écrit : task130(pid1182)-vm_allocate (33562796 8364 0) = 0x3 ((os/kern) no space available) task130(pid1182)-vm_allocate (33571160 8364 0) = 0 33570816 While inspecting this, I realized this is from __pthread_stack_alloc, the only caller

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

2014-05-02 Thread Samuel Thibault
Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit : So we just need to fix guardsize in our libpthread. It was not so difficult actually. Svante, could you try this libpthread: http://people.debian.org/~sthibault/tmp/libpthread.so.0.3 Thanks, Samuel

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

2014-05-02 Thread Svante Signell
On Fri, 2014-05-02 at 12:00 +0200, Samuel Thibault wrote: Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit : So we just need to fix guardsize in our libpthread. (And I'll have a look at it). Maybe this can fix the around 40 segfaults (of 50 failures) when split stack is disabled

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

2014-05-02 Thread Samuel Thibault
Svante Signell, le Fri 02 May 2014 12:45:56 +0200, a écrit : On Fri, 2014-05-02 at 12:00 +0200, Samuel Thibault wrote: Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit : So we just need to fix guardsize in our libpthread. (And I'll have a look at it). Maybe this can fix

[PATCH 2/3] i386: add io_map_cached

2014-05-02 Thread Justus Winter
io_map_cached is like io_map, but reuses the old mapping if it is applicable. * i386/i386/io_map.c: Add io_map_cached. --- i386/i386/io_map.c | 29 + 1 file changed, 29 insertions(+) diff --git a/i386/i386/io_map.c b/i386/i386/io_map.c index 74e0b47..03d7152 100644

[PATCH 1/3] ddb: add halt command

2014-05-02 Thread Justus Winter
* ddb/db_command.c (db_command_table): Add halt command. * i386/i386/db_interface.h (db_halt_cpu): New declaration. * i386/i386at/model_dep.c (db_halt_cpu): New function. --- ddb/db_command.c | 1 + i386/i386/db_interface.h | 2 ++ i386/i386at/model_dep.c | 5 + 3 files changed, 8

Re: [PATCH 1/3] ddb: add halt command

2014-05-02 Thread Samuel Thibault
Justus Winter, le Fri 02 May 2014 21:33:00 +0200, a écrit : * ddb/db_command.c (db_command_table): Add halt command. * i386/i386/db_interface.h (db_halt_cpu): New declaration. * i386/i386at/model_dep.c (db_halt_cpu): New function. Ack. --- ddb/db_command.c | 1 +

forgot i386/i386at/acpihalt.h

2014-05-02 Thread Justus Winter
I forgot to add i386/i386at/acpihalt.h.