<damo22>now i dont know which interrupt AHCI is using on the APIC <damo22>it says 0x0b in the interrupt line field of pci <damo22>does that mean its PIRQB = 16+1? ***Server sets mode: +nt
<damo22> i think i need to turn off the irq routing in the LPC bus for the PIC <AlmuHS>I don't get debugging with kdb and gdb at same tine <damo22>i keep finding more stuff to configure <damo22>how do i run hurd with init = /bin/bash <damo22>i want to bypass all the startup <damo22>since it tries to call a bunch of crap that hangs my console <jrtc27>youpi: FYI exodar seems to be down <jrtc27>damo22: same as usual, add init=/bin/bash to the kernel command line (the multiboot command) <jrtc27>though it's not as instant as other OSes <jrtc27>has to get all the way to /hurd/runsystem.sysv first <jrtc27>(or one of the other runsystem alternatives) <damo22>when i want to call a function with one arg from asm, i do pushl %eax ; call func; but do i need to popl %eax after? <damo22>or does the calling of the function absorb the arg on the stack? <jrtc27>also, the i386 SysV ABI requires that the arguments start at a 16-byte aligned address <damo22>thanks, but i seem to be getting a wierd error where the kernel accesses userspace and i get a page fault <jrtc27>ie that %esp+4 is 16-byte aligned on function entry (due to the implicit pushk from call) <damo22>hmm why would masking interrupts cause a kernel thread to write to userspace? ***AliciaC_ is now known as AliciaC
<youpi>damo22: (init=/bin/bash) iirc that's to be set on the gnumach command line <youpi>jrtc27: I know, I get an sms when that happens :) <damo22>if i have a single function from a C file i want to export only to another file, should i put the prototype in a separate file? <damo22>eg, the pic functions belong in pic.c <damo22>but i want to call picdisable from apic code <damo22>i think i should create pic_disable.h <youpi>why do you want to export it only to another file ? <damo22>no because i dont want the other parts of the pic code included <damo22>because i am replacing the pic with apic stubs <youpi>you mean other definitions of pic.c ? <youpi>pic.h is only about declarations <youpi>so that's not what will save you <youpi>you have to disable the code parts in pic.c <youpi>otherwise they'll get in anyway <youpi>.h declaration doesn't matter in terms of actual symbol exposition <youpi>they are only there to check that the prototypes are the same (and macro definitions) <damo22>i want to reuse macros from pic.h <youpi>if you only want to reuse macros, just include it <youpi>the fact that declarations are there won't magically create those functions <youpi>only promise that they exist <damo22>hmm yes i can put the code in ioapic.c <damo22>but i dont want all the prototypes from pic.h <damo22>well i guess it doesnt matter, i am defining them again, i dont need to <youpi>as long as the definitions have the same prototype as the declaration, it will be fine <youpi>if you are using different prototypes, then just comment out the old declarations. Callers will have to use the proper declaration anyway <damo22>but i put ifdefs all over the place to swap pic.h with apic.h <damo22>maybe i should have just nested them <damo22>and then i would only need one ifdef to not include pic.c <youpi>you don't have to remove declarations in order to drop pic.c from the link <youpi>a declaration is a "promise" that a function exists, but if nobody call it, then not actually defining it is not a problem <damo22>but when it hits starting hurd console, the screen goes black <youpi>damo22: you can disable the console in /etc/defaults/hurd <damo22>the ahci interrupt is not working not sure about the timer <damo22>but it seems to be booting slowly <damo22>movl EXT(pic_mask)(,%edx,4),%eax <jrtc27>damo22: foo(a, b, c) means (foo + a + b*c) <jrtc27>so if pic_mask is an array of 4-byte integers, then yes ***Glider_IRC__ is now known as Glider_IRC
<gnu_srs2>damo22: AlmuHS: No activity tonight? I've really enjonied <gnu_srs2>enjoyed your progress (even if not understanding too much) ;) Please keep up your good work! <AlmuHS>I was debugging gnumach using gdb, but I didn't get any clear results <AlmuHS>I can't open gdb after kdb, and kdb after gdb usually crash <youpi>did you try gdb after closing kdb ? <youpi>i.e. trigger kdb, type show all threads, then type continue <youpi>well, yes, didn't you read kdb's documetnation inthe gnumach manual ? :) <AlmuHS>when I try to open gdb over kdb, gdb tries to debug kdb <AlmuHS>i think that I tried to type continue, but then kdb crash <AlmuHS>i use gdb with remote debugging, through 1234 port <AlmuHS>ok. kdb, continue, and then gdb works <AlmuHS>* 1 Thread 1.1 (CPU#0 [running]) _return_from_trap () <youpi>you can inspect the processors' runqs like I mentioned <youpi>to check whether you find the 3 ext2fs threads there <youpi>(actually one of them is probably running, so that one wouldn't be on the runq, that'd be expected) <AlmuHS>when I type "next" in kdb, It crash <AlmuHS>Kernel Debug trap trap, eip 0xc1009150 <youpi>I'm not that much surprised, possibly some SMP support is needed there for such kdb command <AlmuHS>after type "continue" in gdb, after ext2fs freeze, gnumach never regret to choose_thread or thread_select <AlmuHS>I can't find the runq at this point <youpi>didn't you take notes when I explained how to access them? <youpi>processor_ptr[0].runq for cpu0 <youpi>for all cpus (but should be empty since we bind all threads) <AlmuHS>just before continue in kdb, ext2fs has 7 threads, not only 3 ***random-nickname is now known as random-nick
<youpi>AlmuHS: I said the threads in the running state <youpi>there are three of them in the latest log you sent <AlmuHS> 3 (f5e1ad28) R..O..(thread_bootstrap_return) <youpi>one of them is not blocked (no continuation function), so you wouldn't see it in a runq <AlmuHS> 4 (f5e1abd8) R..O..(thread_bootstrap_return) <youpi>yes, thread 1 is currently running, so you wouldn't see it in a runq <youpi>but threads 3 and 4 you should see them in runqs <AlmuHS>but I don't know how to find It in the runq <youpi>did you get to the runq structure? <youpi>did you read the runq structure fields? <AlmuHS> next = 0xc1220128 <processor_array+328>, prev = 0xc1220128 <processor_array+328>}, {next = 0xc1220130 <processor_array+336>, <youpi>what did you type to get this? <AlmuHS>and p processor_ptr[0].runq->runq <youpi>also look at the count value <youpi>do you know about linked lists? <AlmuHS>(gdb) p processor_ptr[0].runq->count <AlmuHS>(gdb) p processor_ptr[0].runq->low <youpi>count == 0 is very surprising <youpi>are all linked lists of the runq indeed empty? <youpi>are you really talking about the linked list, or the runq[] array? <youpi>you have an array of linked lists <youpi>I'm surprised that you wrote processor_ptr[0].runq->count, and not processor_ptr[0].runq.count <youpi>runq here is a struct, not a pointer <AlmuHS>(gdb) p processor_ptr[0].runq.count <AlmuHS>(gdb) p processor_ptr[0].runq.runq.next.next.next.next <AlmuHS>$23 = (struct queue_entry *) 0xc121ffe0 <processor_array> <AlmuHS>(gdb) p processor_ptr[0].runq.runq.next.next.next.next.next <AlmuHS>$24 = (struct queue_entry *) 0xc121ffe0 <processor_array> <AlmuHS>(gdb) p processor_ptr[0].runq.runq.next.next.next.next.next.next <AlmuHS>$25 = (struct queue_entry *) 0xc121ffe0 <processor_array> <youpi>no, it's just the head of the list <AlmuHS>then, cpu 0 hasn't any thread in its list? <youpi>apparently, and that's surprising <youpi>you can check the state of the threads with e.g. p ((struct thread*) 0xf5c00000) ->state <AlmuHS>#0 thread_invoke (old_thread=0xf5c00150, continuation=0xc1007120 <thread_exception_return>, new_thread=0xf5e1aa88) at ../kern/sched_prim.c:627 <AlmuHS>#1 0xc103003c in thread_block (continuation=0xc1007120 <thread_exception_return>) at ../kern/sched_prim.c:893 <AlmuHS>#2 0xc1023e81 in ast_taken () at ../kern/ast.c:111 <AlmuHS>#3 0xc1009553 in i386_astintr () at ../i386/i386/trap.c:582 <AlmuHS>#4 0xc10070c5 in _return_from_trap () at ../i386/i386/locore.S:513 <AlmuHS>(gdb) p ((struct thread*) 0xf5c00000) ->state <youpi>actually, what you're intereseted in is the run bit <youpi>so p (((struct thread*) 0xf5c00000) ->state) & 4 <youpi>(equivalent to knowing whether it has R state) <AlmuHS>(gdb) p (((struct thread*) 0xf5c00000) ->state) & 4 <AlmuHS> 0 (f5c002a0) .W.O.F(mach_msg_continue) 0 <AlmuHS> 1 (f5c00000) .W.O.F(mach_msg_receive_continue) 0 <AlmuHS> 2 (f5e1ae78) .W.O..(mach_msg_receive_continue) 0 <AlmuHS> 4 (f5e1abd8) .W.O..(mach_msg_receive_continue) 0 <AlmuHS> 5 (f5e1aa88) R..O..(thread_bootstrap_return) <AlmuHS> 6 (f5e1a938) .W.O..(mach_msg_receive_continue) 0 <AlmuHS>(gdb) p (((struct thread*) 0xf5e1ad28) ->state) & 4 <AlmuHS>(gdb) p (((struct thread*) 0xf5e1ad28) ->state) & 4 <AlmuHS>(gdb) p (((struct thread*) 0xf5c002a0) ->state) & 4 <AlmuHS>(gdb) p (((struct thread*) 0xf5c00000) ->state) & 4 <AlmuHS>(gdb) p (((struct thread*) 0xf5e1ae78 ->state) & 4 <AlmuHS>A syntax error in expression, near `'. <AlmuHS>(gdb) p (((struct thread*) 0xf5e1ae78) ->state) & 4 <AlmuHS>(gdb) p (((struct thread*) 0xf5e1ad28) ->state) & 4 <AlmuHS>(gdb) p (((struct thread*) 0xf5e1abd8) ->state) & 4 <AlmuHS>(gdb) p (((struct thread*) 0xf5e1aa88) ->state) & 4 <AlmuHS>(gdb) p (((struct thread*) 0xf5e1a938) ->state) & 4 <AlmuHS>0xf5c00000 and 0xf5e1aa88 are running, I think