IRC channel logs


back to list of logs

<AlmuHS>It's possible
<damo22>now i dont know which interrupt AHCI is using on the APIC
<AlmuHS>I don't know neither
<damo22>it says 0x0b in the interrupt line field of pci
<damo22>does that mean its PIRQB = 16+1?
<AlmuHS>i don't know, sorry :(
***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>i386 is hard
<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>you have to clean up
<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>probably that is why
<damo22>hmm why would masking interrupts cause a kernel thread to write to userspace?
<damo22>started cpu 1 ... page fault
***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>then i can include it in both
<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>you can put it in pic.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
<damo22>so i will create pic_disable.c
<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>make apic a superset of pic
<damo22>that would make it easier
<damo22>and then i would only need one ifdef to not include pic.c
<damo22>for the apic case
<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>i always forget this
<damo22>hmm its booting... very slowly
<damo22>creating device nodes.....
<damo22>it found 2 cpus
<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>what does this instruction do?
<damo22>movl EXT(pic_mask)(,%edx,4),%eax
<damo22>what does the (,reg,imm) do?
<damo22>is it like eax = pic_mask[edx]
<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
<AlmuHS>tonight I was sleeping ;)
<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
<AlmuHS>how can I close kdb?
<youpi>then run gdb
<youpi>well, yes, didn't you read kdb's documetnation inthe gnumach manual ? :)
<AlmuHS>no really
<AlmuHS>when I try to open gdb over kdb, gdb tries to debug kdb
<AlmuHS>instead debug the kernel
<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>kdb output:
<AlmuHS>gdb output:
<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
<AlmuHS>oh, ok
<youpi>and default_pset.runq
<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
<AlmuHS>youpi: I don't know how to search ext2fs threads. In kbd, these hasn't any address
<youpi>AlmuHS: I said the threads in the running state
<youpi>there are three of them in the latest log you sent
<AlmuHS> 1 (f5c00000) R.....
<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>I did a print in gdb
<AlmuHS> next = 0xc1220128 <processor_array+328>, prev = 0xc1220128 <processor_array+328>}, {next = 0xc1220130 <processor_array+336>,
<AlmuHS>and more like this
<youpi>what did you type to get this?
<AlmuHS>p p processor_ptr[0].runq
<AlmuHS>p processor_ptr[0].runq
<AlmuHS>and p processor_ptr[0].runq->runq
<youpi>also look at the count value
<youpi>and the low value
<youpi>do you know about linked lists?
<youpi>so follow the list
<AlmuHS>(gdb) p processor_ptr[0].runq->count
<AlmuHS>$5 = 0
<AlmuHS>(gdb) p processor_ptr[0].runq->low
<AlmuHS>$6 = 30
<youpi>count == 0 is very surprising
<youpi>are all linked lists of the runq indeed empty?
<AlmuHS>It's a very long list, in fact
<youpi>are you really talking about the linked list, or the runq[] array?
<youpi>don't confuse them
<youpi>you have an array of linked lists
<youpi>most of which are empty
<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
<youpi>oops, vim-ism :)
<AlmuHS>(gdb) p processor_ptr[0].runq.count
<AlmuHS>$13 = 0
<AlmuHS>It's so strange
<AlmuHS>(gdb) p processor_ptr[0]
<AlmuHS>$23 = (struct queue_entry *) 0xc121ffe0 <processor_array>
<AlmuHS>(gdb) p processor_ptr[0]
<AlmuHS>$24 = (struct queue_entry *) 0xc121ffe0 <processor_array>
<AlmuHS>(gdb) p processor_ptr[0]
<AlmuHS>$25 = (struct queue_entry *) 0xc121ffe0 <processor_array>
<AlmuHS>always the same thread
<youpi>no, it's just the head of the list
<youpi>it's an empty 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>bt show this
<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
<AlmuHS>$26 = 260
<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>$27 = 4
<AlmuHS>1 ext2fs (f5c01dd0): 7 threads:
<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> 3 (f5e1ad28) R.....
<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>$28 = 0
<AlmuHS>what means this?
<AlmuHS>(gdb) p (((struct thread*) 0xf5e1ad28) ->state) & 4
<AlmuHS>$28 = 0
<AlmuHS>(gdb) p (((struct thread*) 0xf5c002a0) ->state) & 4
<AlmuHS>$29 = 0
<AlmuHS>(gdb) p (((struct thread*) 0xf5c00000) ->state) & 4
<AlmuHS>$30 = 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>$31 = 0
<AlmuHS>(gdb) p (((struct thread*) 0xf5e1ad28) ->state) & 4
<AlmuHS>$32 = 0
<AlmuHS>(gdb) p (((struct thread*) 0xf5e1abd8) ->state) & 4
<AlmuHS>$33 = 0
<AlmuHS>(gdb) p (((struct thread*) 0xf5e1aa88) ->state) & 4
<AlmuHS>$34 = 4
<AlmuHS>(gdb) p (((struct thread*) 0xf5e1a938) ->state) & 4
<AlmuHS>$35 = 0
<AlmuHS>0xf5c00000 and 0xf5e1aa88 are running, I think