bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

64bit startup


From: Samuel Thibault
Subject: 64bit startup
Date: Fri, 26 May 2023 03:31:46 +0200
User-agent: NeoMutt/20170609 (1.8.3)

Hello,

I'm trying to start a 64bit Debian/Hurd but this fails very early. To
build gnumach I'm using:

$ ../configure --host=x86_64-gnu LD=x86_64-linux-gnu-ld CC=x86_64-linux-gnu-gcc 
--disable-user32 --disable-linux-groups

which I have put on 

https://dept-info.labri.fr/~thibault/tmp/gnumach

and I'm loading the ext2fs.static module, as obtained from
https://people.debian.org/~sthibault/tmp/hurd-amd64/pool-hurd-amd64/h/hurd/hurd_0.9.git20230520-1_hurd-amd64.deb

which I have put on 
https://dept-info.labri.fr/~thibault/tmp/ext2fs.static

and what I obtain is:

GNU Mach 1.8
ELF section header table at ffffffff80010290
biosmem: physical memory map:
biosmem: 000000000000000000:00000000000009f000, available
biosmem: 00000000000009fc00:0000000000000a0000, reserved
biosmem: 0000000000000f0000:000000000000100000, reserved
biosmem: 000000000000100000:0000000000dddde000, available
biosmem: 0000000000dddde000:0000000000dde00000, reserved
biosmem: 0000000000feffc000:0000000000ff000000, reserved
biosmem: 0000000000fffc0000:000000000100000000, reserved
vm_page: page table size: 908750 entries (85196k)
vm_page: DMA: pages: 4080 (15M), free: 0 (0M)
vm_page: DMA: min:500 low:600 high:1000
vm_page: DMA32: pages: 61440 (240M), free: 61207 (239M)
vm_page: DMA32: min:3072 low:3686 high:6144
vm_page: DIRECTMAP: pages: 327680 (1280M), free: 297135 (1160M)
vm_page: DIRECTMAP: min:16384 low:19660 high:32768
vm_page: HIGHMEM: pages: 515550 (2013M), free: 0 (0M)
vm_page: HIGHMEM: min:25777 low:30933 high:51555
com 2 out of range
RTC time is 2023-05-26 01:25:34
module 0: ext2fs --readonly --host-priv-port=${host-port} 
--device-master-port=${device-port} 
--multiboot-command-line=${kernel-command-line} --exec-server-task=${exec-task} 
-T typed ${root} $(fs-task=task-create) $(task-resume)
module 1: exec /hurd/exec $(exec-task=task-create)
2 multiboot modules
Kernel Double fault trap, eip 0x0
kernel: Double fault (8), code=0
Stopped at  0:
no memory is assigned to address 00000000

no memory is assigned to address 00000001
addb    %al,0(%eax)
0x0(
no memory is assigned to address 00000000
...)
0xffffffff8107a712(0,8101d463,400ee0,ffffffff8101d49c,0)
0xffffffff8106ff27(ffffffffde739868,ffffffff8101d463,ffffffffde736fb8,0,ffffffff
8104ceec)
>>>>> user space <<<<<

where 0xffffffff8107a712 is the *read_exec call in exec_load, which does
happen fine, until read_exec calls copyout, which thus apparently fails
somehow.

Does that ring a bell?

Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]