***Server sets mode: +nt
<damo22>youpi: maybe there is a missing dependency <youpi>I mean I was running both in parallel <damo22>could it be losing an interrupt? <damo22>or too much delay in delivering the interrupt and it times out <damo22>i believe the clock is set to 100Hz timer, and rump also uses 100Hz iirc <damo22>maybe we need mach to have higher resolution timer? <youpi>I wouldn't think about an interrupt loss because it happened twice in the same place <damo22>i dont mean a timeout in the mach message, i mean the driver sets a timer to wait for interrupt and the delay causes the driver to give up <youpi>yes, still that'd be seconds <youpi>(and I would probably get a message) <damo22>we should try reverting my ahci core changes <damo22>maybe they are not needed anymore <damo22>because if the command just times out before it is actually complete, it may not be ready <damo22>hmm but its in a while loop that checks for ready <damo22>i dont know what tsleep is supposed to do, maybe it is waking up a thread that actually performs the io <damo22>it could be cutting it short if the timeout is reached <damo22>the ahci driver has changed a lot in master netbsd <damo22>this is probably a good reason to help them integrate rump into their build system so we can get more up to date drivers <damo22>youpi: i saw in linux kernel code they have a workaround for override irq choosing the wrong trigger mode and they force it to edge or something, but thats only for APIC <damo22>it causes timer to trigger wayy too many times <damo22>but this is not occurring for pic <Pellescours>damo22: I would like to help you but I don’t know where to start nor how to help <damo22>i am trying to build ACPICA as a library and make it initialise the acpi <damo22>the whole thing boils down to one function, acpi_init() <damo22>if you write a simple program that has int main() { acpi_init(); return 0; } you can test it <damo22>and compile the libacpica library <damo22>something is wrong with the glue code i wrote <damo22>the last commit removes semaphores that break it <damo22>you can run the test program in gdb and try to figure out where it is failing and maybe you can fix it <damo22>my theory is that there are some acpi globals that need to be defined and we need to use #define DEFINE_ACPI_GLOBALS somewhere in the code, but i cant quite figure it out <damo22>if you get it to print "PASS" at the end and it waits there, youve succeeded <Pellescours>ok I have to go to bed but as soon I can I’ll try it <damo22>thats why i got it built so quick <damo22>(12:59:37) ryoshu: i want to see buildrump.sh integrated into mainline src tree <--- netbsd dev is suggesting we try to integrate buildrump.sh into build.sh <AliciaC>as I understand it DEFINE_ACPI_GLOBALS needs to be defined once before libacpica/acpi/acpixf.h and libacpica/acglobal.h global are included, but only once (maybe in one .c file). because defining DEFINE_ACPI_GLOBALS makes the ACPI_GLOBAL and a few other macros generate definitions instead of declarations <damo22>it seems that semaphores in ACPICA are not supposed to be separate to the locks <damo22>because they don't call acpi_os_create_semaphore before using them <damo22>i think they are reusing the handles <damo22>is it possible to implement semaphores with mutex locks? <damo22>or can i use a sem_t as a mutex lock? <youpi>sem_t and mutex_lock are completely different things <youpi>but you can use a sem_t to implement a mutex <youpi>simply initialize it with 1 token <youpi>"because they don't call acpi_os_create_semaphore before using them" so they just call wait on them without creating them? <youpi>that'd be very very surprising <damo22>they create locks instead but use the semaphore calls on the locks <youpi>ok, so yes make creating a lock actually create a semaphore with one token <damo22>so is acquire lock the same as sem_wait, or sem_post? <youpi>since you wait for a token to be available <youpi>please read the tanenbaum books ;) ***alessandro_ is now known as adamantinum
<damo22>ive pushed something that works slightly better to my branch, maybe Pellescours can work more on it while i sleep <damo22>you were right about the globals, AliciaC <damo22>more drama in libreboot world, the lead person kicked out one of the developers because they refused to denounce the work of another developer <damo22>they were offered money to leave the project, then the board and the voting scheme was dismantled and push access is now only by the project owner again... its a shambles, im so glad i left that project a long time ago <alessandro_>Hi, I don't know if it's the right channel or it's a debian releated issue. I'm trying Hurd after some years, I see the improvement (before I was never able to start X server correctly) and so I'm going to interesting in it. The major issue regards I can't start virtual terminals, e.g. xterm returns "xterm: Error 32, errno 1073741826: No such file or directory Reason: get_pty: not enough ptys". Is it a known issue or I'm do <damo22>alessandro_: im not sure if there are many hurd users yet, let alone ones that use X on hurd. We are still writing drivers for the hardware, but its progressing and once the main hardware drivers are working, we can focus on things that are important for the experience on things like GUIs <alessandro_>Sorry the message started. I suppose that very few people use Hurd with X. I asked just to know if is a known issue. I'm happy the work is going on, because it would be sad if this project was stopped. <damo22>its great to hear bug reports though, if you can post it somewhere on the mailing list it will be looked into <gnu_srs>Looks like the whole acpi_gbl_mutex_info() array is not initialized. <Pellescours>I have a strange behavior, my VM has internet, I forward ssh port to my host, my ssh server is running in my VM, but i can’t connect <Pellescours>ssh: connect to host 127.0.0.1 port 22: Connection refused <youpi>use tcpdump to check exactly where the refuse comes from <Pellescours>my bad it’s because it’s `p` for port forwarding and not `P` ***Emulatorman_ is now known as Emulatorman
***Emulatorman_ is now known as Emulatorman
<Pellescours>I try to build acpia and against the small main with acpia_init but i fail :/ <Pellescours>I built libacpia.a but when I try to link my main against it, gcc says their is undefined reference ***Thunderbi is now known as nckx
<Pellescours>damo22: in acpi_init I can see you alocate a semaphore using ac_allocate… but you free it by calling free directly <damo22>Pellescours: please check the hash you are on <Pellescours>now I have to learn how to use gdb because I know the very basics <damo22>yeah it seems the acpica code tries to use a semaphore that is uninited <AliciaC>yeah, I wanted to have a look with some more context but grep is giving me nothing. I now realize it's probably gdb output