IRC channel logs


back to list of 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>I'm building an image with cross-hurd and booting it with qemu
<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>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>+ 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> 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
<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>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:
<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>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>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