IRC channel logs

<fowler>OK, som my quest to simple log in to the Hurd continues.

<fowler>I've booted with init=/bin/bash and done a few things to try and sole the issue

<fowler>I've done a chown -Rv root. / as all files seemed to be owned by 1000:1000

<fowler>I've corrected the entry in /etc/passwd from /tools/bin/bash to /tools-i686/bin/bash

<fowler>I've run passwd from within the shell

<fowler>After all of this I run "login root" from the bash shell and again I get "Authentication failure: Operation not permitted"

<fowler>I'm then dumped back to bash

<fowler>One weird thing I see is that in ps aux everything is running as uid root except /hur/password which is running as uid 1000

<gnucode>Are you running the hurd in a vm?

<fowler>Yes

<fowler>I'm building an image with cross-hurd and booting it with qemu

<fowler> https://github.com/flavioc/cross-hurd

<gnu_srs1>fowler: login root <return>; the password for root is empty!

<fowler>It's not I'm afraid. I've tried that. On the first boot you're asked to set a password

<fowler>Entering the wrong password or just hitting enter yields "login: Invalid password"

<gnu_srs1>Don't care about setting a password. It does not work.

<fowler>Entering the correct password gets you "Authemtication Failure: Operation not permitted"

<gnu_srs1>Don't give any password!

<fowler>OK, I'll build a new image and when it asks for a root password on first boot, I'll just hit enter

<gnu_srs1>Yes

<gnu_srs1>And when you get to the login prompt: login root; <return>

<fowler>Thanks, I'm in the middle of a rebuild so I'll try agian in about 1/2 an hour :)

<gnu_srs1>It's simpler than that: login> login root <return>

<fowler>Thanks gnu_srs1, entering no password in the setup means that after a reboot, a simple pressing of enter gets me in when asked for a password :D

<fowler>Wait, something is odd here

<fowler>I did the build as root this time, instead of my user

<fowler>when I login with no password and then enter "passwd root", I can then reboot and login using the password. /hurd/password is now running with uid 0... I wonder

<fowler>I'm going to rebuild the image and actually enter a password this time

<fowler>and NOW it workd.

<fowler>Building as root instead of my user made the difference. /hurd/password spawns with uid 0 instead of my host system uid of 1000

<fowler>Somehow the uid gets baked in somewhere during the build. I did chown -Rv root. / so it's not something as simple as a file user/group from what I can see

<fowler>OK, I have a booting hurd I can login to correctly :D :D

<fowler>I guess I can update my bug report.

<damo22>Pellescours: i think its trying to lock a bogus address

<damo22>which happens to be already set to 1

<damo22>and so deadlocks, not because there are more lock calls but because its already "locked"

<damo22>unless gdb is lying

<damo22>Pellescours: see my latest commit, it converts the simple_lock into a function so you can step into it with gdb

<fowler>Sweet, my bug was verified and fixed by the repo owner :)

<damo22>how do i make gdb insert a breakpoint when it can access the memory?

<damo22>so far i cant set a breakpoint in gnumach because initially the start symbol cannot be resolved

<damo22>its like the compiler is miscompiling this logic

<damo22>it gets confused with the function preamble and it messes with the function

<damo22>do i need to preserve old values of edi, esi, edx, ecx, eax when i use them in spl.S ?

<damo22>hmm maybe the pmap->lock is not initialised

<luckyluke>damo22: if you need a breakpoint before paging is enabled, I could make it work by setting the breakpoint at the address - 0xC0000000. I think gdb is confused by segmentation.

<damo22>youpi:

<damo22>+ while(__sync_val_compare_and_swap ((volatile int *)&(l->lock_data), 0, 1) != 0)

<damo22>+ __asm ("pause");

<damo22>is this another way to define the simple lock?

<youpi>damo22: yes, but less efficient since you don't have the relaxed loop

<youpi>damo22: you need to preserve all the callee-saved registers

<youpi>so ebx, edi, esi, ebp

<damo22>are there any i can use without preserving them?

<damo22>eax, ecx, edx ?

<youpi>all the caller-saved registers, so eax, ecx, edx

<youpi>it's all documented in the ABI documentations etc.

<damo22>int _simple_lock_xchg_(struct slock *l, int new_val)

<damo22>{

<damo22> return (__sync_lock_test_and_set ((volatile int *)&(l->lock_data), new_val));

<damo22>is that ok?

<youpi>depends what you want to do

<youpi>but I really wonder why you are trying to rewrite this

<youpi>AFAIK, the existing code is already correct

<youpi>no need to patch it over

<damo22>i need to make it a function though so i can debug it

<damo22>its currently a macro

<youpi>then just paste the existing code into the function

<damo22>ok

<youpi>(I mean the whole simple_lock code, not just simple_lock_xchg_)

<damo22>the reason i rewrote it is because i thought the compiler was breaking the code

<damo22>with inline asm

<youpi>how could it?

<youpi>the inline stanzas exactly explain what it's about

<damo22>ok

<damo22>i think the brokenness is from spl.S

<youpi>but for sure, as long as your spl code overwrites %ebx, everything can happen

<youpi>yes, that's I wrote here the other day

<youpi>cf the log

<youpi>(00:38:39) Pellescours: they are identical: https://pastebin.com/BLQQiAuC

<youpi>(00:39:11) youpi: and what I meant above is that they are bogus

<youpi>(00:39:20) youpi: they modify ebx, which is a callee-saved register

<damo22>smp 1 booted, smp 2,4,6,8 all hung

<damo22>start acpi: <nothing>

<damo22>the first task is dying, regardless of the task

<damo22>which stops the boot process

<damo22> while (! info.done)

<damo22> {

<damo22> thread_sleep ((event_t) &info, simple_lock_addr(info.lock), FALSE);

<damo22> simple_lock (&info.lock);

<damo22> }

<damo22> simple_unlock (&info.lock);

<damo22>is it okay to simple_lock in a loop??

<youpi>no

<youpi>but see the content of thread_sleep

<damo22>i tried with "prompt-task-resume" in the bootstrap

<damo22>it reaches the debugger

<damo22> 0 gnumach (f59a8ea0): 10 threads:

<damo22> 0 (f59a6e70) R.....

<damo22> 1 (f59a6d20) R..O..(idle_thread_continue)

<damo22> 2 (f59a6bd0) R.....

<damo22> 3 (f59a6a80) .W.ON.(reaper_thread_continue) 0xc10b1430

<damo22> 4 (f59a6930) .W.ON.(swapin_thread_continue) 0xc10b158c

<damo22> 5 (f59a67e0) .W.ON.(sched_thread_continue) 0

<damo22> 6 (f59a6690) .W..N. intr_thread

<damo22> 7 (f59a6540) .W.ON.(action_thread_continue) 0xc10ac2a4

<damo22> 8 (f59a63f0) .W.ON.(io_done_thread_continue) 0xc10b2c00

<damo22> 9 (f59a62a0) .W.ON.(net_thread_continue) 0xc10b4414

<damo22> 1 acpi (f59a8dd0): (f59a6150) ..SO..(thread_bootstrap_return)

<damo22> 2 pci-arbiter (f59a8d00): (f59a6000) ..SO..(thread_bootstrap_return)

<damo22> 3 rumpdisk (f59a8c30): (f598fe78) ..SO..(thread_bootstrap_return)

<damo22> 4 ext2fs (f59a8b60): (f598fd28) ..SO..(thread_bootstrap_return)

<damo22> 5 exec (f59a8a90): (f598fbd8) ..SO..(thread_bootstrap_return)

<damo22>thats with -smp 2

<luckyluke>It seems like it's time for a 64 bit userapace :)

<flavioc>luckyluke: yep. could be a good idea to split efforts, otherwise we risk stepping on each other's efforts

<youpi>yes, I was wondering whether to raise the issue on the list :)

<youpi>it seems we mostly managed to avoid re-doing some work several times, but that was mostly luck

<flavioc>youpi: what do you think about having a new data layout in Mig stubs for 64 bits? I think we should use this opportunity when moving to a 64 bit userland, probably by adopting untyped messages which can help us avoid excessive padding but also avoiding extra copies on the stack for alignment

<youpi>not sure: untyped messages = not using C structures, and just let mig decide its own alignment & padding ?

<youpi>I'd say yes, we can use memcpy etc., the compiler will understand everything and turn that to an optimized result anyway

<flavioc>by untyped messages, I mean just putting all the non-complex data together after header and ports. mig can either group the messages in an optimal way to avoid padding or rely on a single memcpy to map that into a structure that respects alignment and is sent to the routines

<luckyluke>isn't alignment an issue also for complex data, i.e. if we have an array of ports? Or are these magically aligned somehow?

<luckyluke>I'm still processing Sergey's mail...

<flavioc>for untyped mig, array of ports are converted in the kernel so that you end up with an aligned array of pointers. with my patch given that we pad a port name with another 4 bytes, so when the kernel converts the port name to port pointer, the pointer will always be 8-byte aligned

<luckyluke>ok, I think I have the general idea, and messages could also be smaller because non-complex data don't need a descriptor anymore

<flavioc>yeah, the problem is mostly because the mach_msg_type_t are inbetween the data and the data sometimes needs to be 8-byte aligned. packing everything together makes it much easier to perform optimal alignment without having to ensure each data item to be 8-byte aligned separately

<luckyluke>once this is solved, would it be safe to remove also the -no-sse and similar flags?

<youpi>no, those ar eto avoid the kernel using floating-ponit operations

<luckyluke>ok

<luckyluke>but apart from rpc, I think the kernel need also work in other places, e.g. the 64-bit syscall interface, and probably some other things...

<luckyluke>otherwise we can't test rpc :)

<youpi>well, sure, but we'll have to fix rpc too anyway

<youpi>doesn't really matter who does what in which order

<luckyluke>sure, I was just thinking about the missing things

<luckyluke>it would be good to also improve the kernel memory map, but that's probably lower priority now

IRC channel logs

2023-02-12.log