<youpi>I guess your thread_info.h file doesn't have the field <AlmuHS>I have a default gnumach installation <AlmuHS>wait, I go to execute "make install" in my SMP gnumach <AlmuHS>but I notice that gnumach install headers in /include/mach , meanwhile hurd search It in /usr/include/mach <AlmuHS>I had to copy the first to the second plce <youpi>the default prefix on GNU is / indeed, you need to pass --prefix=/usr to configure to get the debian default <youpi>you also need to put the proper ifdefs in the code <youpi>so that both cases work as appropriate <youpi>just try to think about compatibility in both case <youpi>imagine what happens in both case <youpi>no need to initialize it to 0 before the ifdef <youpi>you can also test with a #error that what you want to be compiled really is compiled <youpi>sicne your last_processor is already a long unsigned, there is no need to cast it <youpi>apart from that it looks good <AlmuHS>I prefered to use an auxiliary variable to clean a bit the code <youpi>I just mean you don't need to initialize it to zero <AlmuHS>I prefered this than add the #ifdef in the same sprintf <youpi>since you set it right after it <youpi>no need for casting last_processor <youpi>also, we usually do not indent just because of #ifdef <youpi>so the two "last_processor =" lines would be indented just like above <youpi>that looks good except the indentation in the "last_processor = " lines <youpi>also, take care how braces are to be written for the if <youpi>see just above, you have an example <AlmuHS>anyways, I could pass an e-style to process.c. It has some irregular indentation <youpi>the GNU Coding Style provides the correct /usr/bin/indent call to make <youpi>your if braces need to be on separate lines, with some indentation <youpi>and put a space after the if <youpi>really, look around in the file to see the coding style <youpi>about irregular indentation, are you sure it's not just that your editor makes tabs 4-chars for instance? <AlmuHS>e-style is a plugin which applies the coding style what you want, to the entire file <youpi>you don't generally want to blindly apply a coding style <youpi>because that introduces a lot of spurious changes <youpi>which make reviewing way harder <AlmuHS>it's irregular because, It depends of tabs <youpi>you can make an indent run, but only to find incoherency and fix what you want <youpi>then tell your editor that tabs are 8 spaces <AlmuHS>but the indentation are depending of the size of this tabs <youpi>yes, and I tell you that tabs are 8 chars <AlmuHS>when I set 8 tabs, same codeblocks are bad indented. but, when I set 4 tabs, some blocks previosly well indented, feels wrong <youpi>provide examples, what I'm reading doesn't have such issue <youpi>all I'm reading is indented fine <youpi>since I guess you have a modified file <AlmuHS> start_code = end_code = 0; /* To make killall5.c consider it a <AlmuHS>also, It seems that some blocks mix spaces and tabs <youpi>the blue does are just here to tell that they are tabs <youpi>8 spaces are just replaced by tabs <AlmuHS>when I change the tabs size, some pieces move, but some not <youpi>really, the only thing you need is to tell your editor that tabs are 8 chars <youpi>most source code on the net assume that, if they assume something about tabs <AlmuHS>yes, but I have to add some spaces in some lines to fix well the line <youpi>and if source code is so indented that 8-char tabs make them not fit on the screen, the code is too complex and should be rewritten <AlmuHS>in these files, in some lines, I had to add 2 spaces, followed with an 8 space tab <youpi>really, for me everything is just as expected <youpi>that's not supposed to be needed <AlmuHS>how can I send screenshots by IRC? <youpi>didn't you look at my blip.png? <AlmuHS>yes, but I don't have any similar web <youpi>(random pickup from googling "paste image" ***Server sets mode: +nt
<youpi>if you have fixed the braces for the if yes <youpi>and the content of the braces is indented <youpi>(I'm really pissed that all these new fancy editors are just not respecting decades-old convention that a tab is 8 chars) <youpi>(that keeps posing problems to newcomers) <youpi>now the brace is correct, but the content is not, it's too indented <AlmuHS>CodeBlocks has a plugin to indent file in GNU mode, but this plugin reindent ALL file, so I prefered not to use <youpi>yes, better not use a systematic reindenter <youpi>there are always cases when manual indentation looks better <youpi>now, all that being said, here there is no need for braces since there's only one line <youpi>it's just that it's better you learn these parts of the coding style as early as possible <youpi>ah, again you need space between if and ( <jrtc27>eh, I deliberately default to 4 spaces per tab because I find it more readable/looks nicer (even for low depth), but will quickly recognise files for which I should change to 8 :P <AlmuHS>I usually use 4 space per tab in my personal code <AlmuHS>but, if GNU standard is 8 tabs, I'll have to follow It <jrtc27>yeah (and beware of the extra indentation when {} is involved) <jrtc27>(and the spaces before ('s in function calls) <jrtc27>which perhaps comes from certain early developers' use of lisp, where it's `(f (a b))`, so translates more to `f (a, b)` in C <AlmuHS>youpi: I've just sent the patch to maillist <AlmuHS>I don't tested It with hurd, I advice <youpi>(also note that comments contain sentences, and should thus start with a capital, and finish with a dot and two spaces) <jrtc27>I'd also suggest you use git-format-patch so you can bundle the changelog in with the diff rather than them being 2 separate files <youpi>I didn't notice in your previous change log: what is in parenthesis is the name of the function being modified, not the exactly code location <AlmuHS>in the parenthesis I said not the modified function, instead I said that I modified the callers of this function <AlmuHS>I might had been more clear, It's true <youpi>it's not a question of being clear, it's a question that it is the convention <youpi>all other changelog entries are made this way <AlmuHS>ok, I didn't know the convention either <youpi>see how it is done in git log <youpi>general rule: look around how it is done, mimic it <youpi>that'll save you a lot of GNU Coding Style reading <AlmuHS>+ [#include <mach/thread_info.h]) must be + [#include <mach/thread_info.h>]) <AlmuHS>youpi: can you fix It or I resend the patch? <youpi> sending a modified patch is useless once the previous is commited <AlmuHS>youpi: I sent a new patch. I found a new error (I'm embarrased, sorry) <damo22>youpi: how do you install an interrupt handler from userspace? <damo22>i found a bunch of symbols in gnumach that are pointers to functions *ivect[NINTR] <damo22>im a bit confused how that can translate to something a userspace driver can implement <youpi>damo22: you just forward the event through a notification <youpi>see the 70_dde.patch in the debian package that forwards interrupts to netdde <youpi>it's possibly full of issues, but at least the principle is correct <damo22>so every interrupt is going to be implemented as a separate rpc message <damo22>ok thats kind of easier to handle <damo22>i could have a single function that takes a parameter of the IRQ number <damo22>but i think i need to extend *ivect to 48 interrupts <damo22>i probably dont even need all that <damo22>but i want to allow scheduling of irqs <damo22>it seems like we are inventing a new interrupt mechanism <youpi>that's useful for giving a PCI device to a subhurd, yes <damo22>do i just set them all as intnull? <damo22>the problem is, this is all very hardware dependent <youpi>waiting for anything to register a handler <youpi>be it the user-land forwarding handler <damo22>how does it decide which interrupt to register <youpi>pic_isa.c is in i386/i386at/pic_isa.c, so it's fine to depend on x86 :) <youpi>see the patch, the register function says which interrupt should be used <youpi>netdde determines that from reading the PCI config space <youpi>a proper sub-hurd forwarded would make sure the subhurd only requests interrupts for the PCI device it's given <youpi>though getting more interrupts than needed is not really that much a problem <youpi>of course this model doesn't support the driver doing cli/sti <youpi>but nowadays nobody does this any more <youpi>it's too dangerous to be doing this in userland anyway, you could get stuck in a blocking system call <youpi>and then never have the chance of calling sti <damo22>is that why interrupts.S has cli in the middle? <damo22>to stop interrupts from interrupting interrupt handlers? <youpi>otherwise you may have unbound stacking <youpi>that does happen with very busy systems <damo22>im learning a lot from reading this code <youpi>it's much simpler to read than linux' :) <damo22>interesting that irq2 is intnull, its not even connected to a line <damo22>youd never receive an interrupt on irq2 <damo22>because the pics are plugged together on that line <youpi>better have a null handler than a hang if for whatever reason the hardware invented an interrupt on irq2 <mabox>Did you saw ideologing at Cristosan.com <mabox>Did ya ideology like at Cristosan.com <AlmuHS>are there any secure way to test and upstream hurd compilation? Sometimes, after do "make install", hurd hang at boot. And I have to reinstall entire system <youpi>note that you usually don't need to reinstall the entier system <youpi>either by booting from the debain installer, chrooting into your system and running dpkg -i <youpi>or by mounting the disk, and unpacking by hand with ar p hurd_foo.deb | tar x <AlmuHS>yes, but in this time, the filesystem crashed <AlmuHS>the translator which crashed was procfs <youpi>I have never had to reinstalled the buildd boxes for a decade <AlmuHS>btw, can anyone test the latest gnumach with the latest hurd? from upstream repositories. Yesterday hurd crashed after do It, but may I did any step wrong <youpi>I uploaded them in debian yesterday <AlmuHS>gnumach seems runs well, the problem seems to be in hurd <youpi>ah, the hurd binaries may have come this morning only <AlmuHS>I'm repeating the test now, as I said <youpi>1140 oct. 30 08:17 hurd_0.9.git20191029-1_hurd-i386.upload <AlmuHS>but, has you test It this configuration? <AlmuHS>first test: upstream gnumach with default debian hurd. OK <AlmuHS>now I have to test this with upstream Hurd <AlmuHS>my debian gnu/hurd is fully updated, btw <youpi>note that upstream hurd doesn't have the debianish startup changes <youpi>it'll expect scripts from /libexec etc. <youpi>that might work by luck, but there is really no guarantee <youpi>GNU and Debian just disagree on where files should be put <youpi>if you want to test something in particular, just copy over that part in your system <AlmuHS>upstream gnumach boot well, but without network <youpi>upstream gnumach doesn't have the dde changes <AlmuHS>compiling hurd. It takes a while <AlmuHS>same problem with default Debian gnumach <youpi>as I said, upstream's init system is very different from debian's init system, so it's not surprising that it fails <youpi>just copy over what you actually need <youpi>similarly, installing an upstream glibc over debian's glibc would be deemed to fail <youpi>nothing that would be necessary <AlmuHS>and, where is proc and procfs? To copy manually <youpi>from proc/ and procfs/ to /hurd/ <AlmuHS>ok, now Debian's gnumach with upstream proc and procfs (over Debian's Hurd) runs well <AlmuHS>but, in my SMP gnumach, something goes wrong <AlmuHS>ok, with Debian's gnumach, the top command shows this crash <youpi>you can attach gdb to the running procfs before triggering the crash <jrtc27>not that I would expect that to be a segfault <youpi>ergl, sure, the added code should be protected by an if (!err) <jrtc27>not going to help, err gets cleared <youpi>note that that's the proc source code <youpi>he has procfs dying, not proc <jrtc27>also the format string for last_process is %d yet the local is declared as long unsigned <jrtc27>which is fine on i386, and probably harmless on x86_64 <jrtc27>(I'm assuming varargs stack slots on x86_64 are 64-bit) *jrtc27 wonders whether libps needs to be in sync with procfs <youpi>you also need to install libps <youpi>it's in the hurd-libs0.3 package <youpi>same source package (hurd), but different binary package (hurd vs hurd-lib0.3) <AlmuHS>hurd-libs0.3/unstable,now 1:0.9.git20191029-1 hurd-i386 [instalado] <youpi>by "you also need to install libps", I mean like proc and procfs <AlmuHS>but, Is It generated in "make", in hurd sources? <youpi>yes, copy that into your lib/i386-gnu/libps.so.0.3 <AlmuHS>in Debian's gnumach, continues same problem <youpi>getting a backtrace with gdb would be really insightful <AlmuHS>gdt must be executed inside the machine? or out <youpi>(fun typo, looks like your head is full of x86 :) ) <youpi>gdb /hurd/procfs the_pid_of_procfs <AlmuHS>oh, It's strange. "ps -e | grep procfs" don't shows anything <AlmuHS>only the same grep: pruebas 728 p0 S 0:00.03 grep procfs <youpi>to be sure that it's still recorded <youpi>possibly it just fails to start early <AlmuHS>showtrans /proc don't shows anything <youpi>ah wait that's perhaps mounted by init scripts nowadays <youpi>but you can as well make it passive as well <AlmuHS>but, If this, ps might show It, is not? <AlmuHS>and "showtrans /hurd/procfs" shows /hurd/procfs <AlmuHS>nope, "ps -e" don't show procfs anyway <youpi>if it crashed you need to let it restart by looking in /proc <AlmuHS>warning: Can't wait for pid 783: No child processes <youpi>it's letting the program continue <youpi>like I said: trigger the crash <youpi>I don't really understand what you expected, actually <youpi>to get the backtrace of a crash, you need to trigger the crash <youpi>wasn't ps triggering the crash? <youpi>or top, or whatever you did that triggered the crash <AlmuHS>0x08033676 in process_file_gc_stat (ps=0x803f870, contents=0x1fffaa8) <AlmuHS>237 last_processor = thsi->last_processor; <youpi>oh, you need to add PSTAT_THREAD_SCHED in the entries array <youpi>otherwise libps will not have filledit <AlmuHS>in process.c ? (in stat writting) <AlmuHS>or in info.c? calling thread_info() <youpi>see where process_file_gc_stat is referenced <AlmuHS>but, what is "entries array"? stat array? <youpi>or, like I said, look where process_file_gc_stat is referenced <AlmuHS>hurd hasn't any caller for "process_file_gc_stat" <youpi>no, but it's referenced in the file <AlmuHS>procfs/process.c:497: .get_contents = process_file_gc_stat, <AlmuHS>procfs/process.c:219:process_file_gc_stat (struct proc_stat *ps, char **contents) <youpi>.get_contents, that's it, it's a reference to the function <youpi>you need to add PSTAT_THREAD_SCHED, to express that it needs that information <AlmuHS>although top only shows 3 process <AlmuHS>but all process are in cpu 0, anyway <AlmuHS>youpi: fixed. But bad news for my smp work <youpi>AlmuHS: could you post the output of ps -feM <youpi>I'm wondering if an idle thread shows up for the second processor <youpi>rootdir_gc_stat would need to be fixed to include all processors information <youpi>yay, there are two gnumach thread with "N" <youpi>so there is an idle thread for the second processor indeed <AlmuHS>maybe I can know the cause. wait <youpi>I wonder how get_idletime can determine which one is for which processor, though <youpi>it's expected to have these two idle threads <youpi>it's however surprising that one of them has no time <AlmuHS>I added this hack to avoid that, when the processor is not added to the system, It returns to the snippet and finish <AlmuHS>ideally, after "slave_main()" the processor never regret to cpuboot.S <AlmuHS>because slave_main() generate a new thread over this <AlmuHS>but maybe It regret anyways and does "hlt" <youpi>you should put printfs to make sure what happens <youpi>normally slave_main doesn't return, so put printf there <AlmuHS>I added this hack because, when I disable pagging and slave_main(), and the processor don't enter to the system, this regret to cpuboot.S, finish the thread and dead <youpi>you'll need to release ap_config_lock before calling it <youpi>otherwise that lock will never be released <youpi>cpu_launch_first_thread() doesn't return <youpi>(at least it's not supposed to) <youpi>but in the long run it won't <youpi>so releasing a mutex after it doesn't make sense <AlmuHS>the mutex in cpu_setup() is useless, I think <youpi>does the second CPU have its own PIT? <youpi> cpu_launch_first_thread calls startrtclock <youpi>you wouldn't want to do that again for the second processor, if you have only one PIT <youpi>the programmable interrupt timer <AlmuHS>in APIC, the Local APIC has Its own timer, but Mach don't use It <youpi>I'd say in cpu_launch_first_thread put an if (th != THREAD_NULL) before calling startrtclock <youpi>so only the boot cpu does it <youpi>in idle_thread, put a printf <youpi>to make sure that it's getting started <youpi>also put prints before thread_block, and between thread_block and idle_thread_continue <youpi>to be sure what happens there <AlmuHS> printf("cpu %d entering in idle_thread", cpu_number()); <youpi>and also at the begining of idle_thread_continue <youpi>concerning get_idletime in procfs, the answer is: idle threads are created in the cpu number order <youpi>so get_idletime can assume that <youpi>that'll be needed to get proper cpu stats in top <AlmuHS>I added this printf in the own idle_thread() function, not in the callet <AlmuHS> printf("cpu %d continue in idle thread", mycpu); <youpi>the message doesn't really matter as long as it's different for each print, and contains the cpu number <AlmuHS>what do you say about get_idletime ? <youpi>for when you get to that function to get proper cpu stats in top <youpi>so, about that idle thread not getting time in ps, that might be "normal": clock_interrupt() is supposed to be called in order to update that <youpi>but since there's only the pit, for which cpu0 catches the interrupt, cpu1 never gets such interrupt and never calls clock_interrupt <youpi>so you need to program the local apic insteda of the pit, to get these interrupts <AlmuHS>damo22 said that he could help me with local apic configuration <youpi>yes, that's it: in the ivect array, irq0 is hardwired on the hardclock() function, which calls clock_interrupt <youpi>you want to make the local apic call that as interupt handler <youpi>that might also actually help to make thread go to cpu1 <youpi>without it, only scheduling IPIs would get that <youpi>I guess you haven't implemented IPIs for scheduling yet? <AlmuHS>I've implemented a generic function to write ICR <youpi>but that's only used at startup, not by the scheduler, right? <AlmuHS>the sequence is start_other_cpus() -> intel_startCPU() -> startup_cpu() <AlmuHS>---> (from interrupt) cpuboot.S -> cpu_ap_main() -> cpu_setup() - ... -> slave_main() <youpi>so apparently what you need to do is to define an aston() function and define MACHINE_AST, so that in kern/sched_prim.c's thread_setrun(), the ast_on call does something <youpi>aston would have to send the ipi <youpi>basically, your IPI interrupt handler wouldn't have to do anything <youpi>ast_on only has to record the ast reason in the need_ast array, and send the IPI <AlmuHS>I haven't an IPI interrupt handler by own <youpi>the interrupt handler does nothing, but on return it will call all_intrs, which checks need_ast, and if so calls take_ast <youpi>just telling you what needs t obe done for this to work <AlmuHS>but this ast is not a architecture-defined IPI, is a fixed-type IPI , is not? <AlmuHS>It's not like INIT IPI or StartUP IPI <youpi>ast is just a software layer <youpi>which only requires from the hardware to manage to raise an IPI <AlmuHS>but I haven't clear what is the purpose of a AST. Or, even, what is exactly an AST <youpi>it's just a software layer for various stuff in the kernel to notify another cpu to do something <youpi>since that's all software, you don't need to implement anything but the IPI <AlmuHS>only send an IPI with the content indicated in the call ? <youpi>really, as I said, all it takes to implement it is to write an aston function which records the reason in the need_ast array and sends an IPI <youpi>and add an IPI handler which does nothing <youpi>no even need for passing the content in the IPI, just record it in need_ast <youpi>ah, ast_on() already does the recording <youpi>so aston() only has to trigger the IPI <AlmuHS>my send_ipi() function only fills IDT (to send the IPI) <AlmuHS>but this need the IDT content to write <AlmuHS>you can see an example of use just below send_ipi(), in startup_cpu() <AlmuHS>but then, we need to define some IPI types (to each reason) <AlmuHS>where I said "IDT content", I wanted to say "ICR content" <youpi>put whatever you like, it doesn't matter <youpi>the ast layer already manages the reasons <youpi>so you don't need to manage them at the IPI level <youpi>i.e. you'd have only one reason at the IPI level: ast <youpi>note that it's when you'll start executing processes on cpu1 that mayhem may happen <youpi>for now you do not have concurrency in drivers etc. <youpi>once executing on cpu1 you will <youpi>notably, the disk driver wil lbe called there <AlmuHS>yes. I'm not an SMP expert, I'm programming a bit blindy (I only knowed until slave_main() ) <AlmuHS>I'm embarrased to say that, but It's the true :-( <youpi>just a longer time ago than you did <AlmuHS>then, I need a new step sequence, with the next steps to solve <youpi>yeah, the ahci/ide disk driver will not be smp safe <youpi>it'd probably be safer to use a rumpdisk driver ***Emulatorman__ is now known as Emulatorman
<youpi>what i said for now: local apic, IPI <AlmuHS>damien said ioapic (to share IRQ) <youpi>then you'll want to implement cpu stats in proc for top to show them <youpi>but in terms of implementation that should be about it <youpi>what is next is to debug issues that will come out <youpi>or ioapic, I don't remember the details. BAscially, something that interrupts cpus periodically <AlmuHS>at moment, keyboard IRQ (the tty don't reply keyboard) <AlmuHS>Mach currently use PIC8259 controller <AlmuHS>but damo22 said that, to share I/O IRQ between processors, could be needed to configure IOAPIC <youpi>we don't really need to share IRQs between processors for now <youpi>it's fine to let cpu0 handle them all <AlmuHS>then, why tty don't reply keyboard? <youpi>possibly due to the pit thing, iirc they are related <youpi>ok, put an if to avoid these :) <AlmuHS> if(self != THREAD_NULL) printf("cpu %d entering in idle_thread\n", cpu_number()); ? <youpi>you can as well just test cpu_number() <AlmuHS> printf("cpu %d entering in idle_thread\n", cpu_number()); <youpi>thinking about it on my way back home: in idle_thread_continue() you could replace machine_idle() with machine_relax(), to avoid making the cpu enter sleep mode and need an irq to be awakened <youpi>that'll suck power, but it should allow for proper cpu scheduling <youpi>? no, that one doesn't call machine_idle ? <youpi>well, yes, there is no other call to machine_idle in idle_thread_continue <youpi>ok. To avoid issues I was thinking that you could, in thread_init(), set bound_processor to cpu_to_processor(0) instead of PROCESSOR_NULL <youpi>normally that'd make all tasks remain on cpu0 <youpi>so you can choose what you want to possibly put on cpu1 <youpi>that'd be notably useful to make ext2fs remain on cpu0 and avoid smp issues in the ide/ahci driver <AlmuHS>do you say thread_init() function, or the call to this? <AlmuHS>there are a special SMP usecase, disabled <AlmuHS> /* thread_template.last_processor (later) */ <youpi>when I say "in thread_init", I mean inside it <youpi>otherwise I would say "in callers of thread_init" <youpi>how are you emulating the system? <youpi>do you have several CPUs on your host? <youpi>does top on your host report 200% cpu usage? <youpi>ok, you could perhaps try to put a for loop around calling machine_relax() <youpi>to call it like a thousand times <youpi>if that's not enough, try a million times :) <AlmuHS>latest commit don't solve problem <AlmuHS>oh, wait. I had a fail in my latest commit. I forgot i++ <youpi>that said, it still means that calling machine_relax in a loop makes gnumach slow <youpi>with i++ that'll be the same <AlmuHS>really, what makes slow is Hurd servers boot <AlmuHS>the boot start freezing in ext2fs and finally freeze in Hurd server bootstrap, after load exec <youpi>did you add the bound_processor thing? <youpi>did you try with the bound_processor thing but keep machine_idle()? <youpi>in case it's actually the bound_processor thing which poses problem <youpi>oh, wait, I didn't realize: you want to replace machine_idle with machine_relax only on cpu1 <youpi>cpu0 should continue using machine_idle <youpi>and the infinite while loop for sure made cpu0 somehow hang :) <youpi>I was thinking: to make sure to know what is happening, put a print there when cpu is not 0 <youpi>to make sure whether cpu1 is just stuck in machine_idle, or something else <AlmuHS>after or before than machine_relax() ? <youpi>ah, I meant to use the machine_idle version <youpi>it's not surprising that it gets out of machine_relax <youpi>I was rather wondering whether the machine_idle version does return or not <youpi>did you look what machine_idle/relax do? <youpi>you'll better understand what I'm after <youpi>do you use tags in your editor? <youpi>to be able to quickly jump to the definition of a function? <youpi>you won't have to care about where is what any more <youpi>that's a so huge time saving <AlmuHS>I usually use CodeBlocks when I want to find any symbol <AlmuHS>to quick changes, It's more simple than a fully IDE <AlmuHS>but the slower task is transfer the changes to the VM. I have to commit and push to my repo, then fetch and merge in my VM, checkout to the Damien's branch (with Debian patches), and remerge It <youpi>if the IDE makes it slow to make small changes, change IDE :) <AlmuHS>no, simply I'm so lazy to open the IDE, unless It's really necessary <AlmuHS>ok, the new print don't shows any result <youpi>I'm not saying to look at what is happening on cpu0 <youpi>that one is fine since your system can usually boot with it <youpi>I'm saying to use machine_idle on cpu1 too, and observe there whether it does return <youpi>(note that sometimes boot gets stuck at exec startup, and it takes a couple reboots to get it past that) <youpi>just to make sure: apart from the prints, there is no difference with the version that was booting fine? <youpi>so I believe it's just the boot that gets stuck, try to reboot it <AlmuHS>the problem starts when ext2fs (and hurd after this) trying to boot <youpi>ah yes there is a difference: the bound_processor thing <youpi>did you try to reboot several times? <youpi>try to revert the bound_processor thing then <youpi>to get back to something that was working before <youpi>otherwise one can't make sure what is due to what <AlmuHS>ok, reverted bound_processor, It seems works <youpi>ok, so let's keep that for now, does it print cpu 1 out of idle? <youpi>if you don't see it, it means it doesn't happen, normally you would see loads of it :) <youpi>you could try to replace machine_idle(mycpu) with the infinite loop while(1) ; <youpi>just to make it hang in a cpu-busy with that should get emulated fine <youpi>perhaps machine_relax() actually bothers virtualization <AlmuHS>currently, both processors has machine_idle() <youpi>if the while(1); loop boots fine as well, you can try to make int i a volatile int i, and use for (i = 0; i < 10000000; i++) ; to make it a small delay loop without using machine_relax() <youpi>cpu0 works just fine since it has its irqs <youpi>I said first try with the while(1); loop <youpi>if you don't try each step, you don't understand what is happening <youpi>so many the cpu spin is not a problem <AlmuHS>while(1) is like stop the processor <AlmuHS>with for-loop, It seems to freeze <youpi>ok, so it's really letting cpu1 run other threads which poses problem <youpi>which is only to be expected, actually :) <youpi>I'm thinking that you should first set back the bound_processor thing <youpi>and make that work, before going further <AlmuHS>do I keep cpu0's machine_idle() ? <youpi>the idea is to keep almost similar to what was working <youpi>and only change the bound_processor thing <youpi>which is not supposed to b reak anything (but apparently does) <youpi>and once working, should allow to let cpu1 use machine_relax(), for it only to find that it has nothing to execute <youpi>and then enable running some tasks on cpu1 one by one <AlmuHS>maybe hlt is shutdown entirely the cpu1 <youpi>cpu0 shoul dbe able to continue working without problem <youpi>I'm checking what setting bound_processor would change <youpi>I don't see anything obvious <youpi>I'd say put prints in thread_setrun and in thread_select to make sure that evertything happens as appropriate <youpi>i.e. thread_setrun puts it on cpu0's runq <youpi>and thread_select finds it there <AlmuHS>here? if (myprocessor->runq.count > 0) { <youpi>anywhere where it makes sense <AlmuHS>if ((thread->state == TH_RUN) && <AlmuHS> (thread->processor_set == pset) && <AlmuHS> ((thread->bound_processor == PROCESSOR_NULL) || <AlmuHS> (thread->bound_processor == myprocessor))) { <AlmuHS> simple_unlock(&pset->runq.lock); <AlmuHS> if (thread->sched_stamp != sched_tick) 
