***Server sets mode: +nt
<damo22>i wonder if i can replace sti/cli in linux drivers to use spl0() and splhi() <youpi>note that it's __sti() that you want to replace <damo22>+-#define __sti() __asm__ __volatile__ ("sti": : :"memory") <damo22>+-#define __cli() __asm__ __volatile__ ("cli": : :"memory") <damo22>and removed all references to pic mask <damo22>oh but spl0() has some stuff for linux handling <damo22>maybe the interrupt handler is calling itself <youpi>if I manage to find the time <damo22>that skips all the linux handling when in a linux driver because its already handling the interrupt <damo22>so the only way to get to the linux handler is via mach spl0 <damo22>what if i make sti/cli = no operation <damo22>i found only one cli() in ahci.c, it seems to time out with no port->status, but if interrupts are disabled, how can the interrupt happen? <damo22>it doesnt make sense why the call to cli() is there <damo22>oh its polling the port with sleep_on() ? <youpi>damo22: note that restore_flags() is supposed to restore the interrupt flag <damo22>its using some kind of internal linux timer scheduling to wait for the port->status but its broken when i get rid of pic mask <youpi>sleep_on probably also restores the interrupt flag <youpi>yes, __sleep_on does sti before schedul( <damo22>i dont understand what i should do <damo22>do i need a third state where timers work but nothing else? <youpi>timers will work in the ahci case because sleep_on does sti <damo22>why cant i just modify the ahci driver to poll for the interrupt status without a timer <youpi>because we need to be able to time out <damo22>which is a timer based thing and doesnt need to call cli <youpi>jiffies don't avance if the clock interrupt does not work <damo22>im suggesting to remove the cli call <youpi>you don't want to do that, that would make it unsafe <youpi>I mean, cli was most probably there for a reason <damo22>most of the other calls just poll, just not this one <youpi>that being said it's just at probing time <youpi>so you may not care if it's unsafe <youpi>you'll still be able to work <damo22> while (!readl(&ahci_port->is)) { <youpi>that's not polling for the status field <youpi>in ahci_identify it's polling for something that is set by the interrupt handler <youpi>that's why it makes sense to disable the interrupt before trying to synchronize that way with it <damo22>it issues a command writel(1 << slot, &ahci_port->ci) <damo22>is that handled by the interrupt handler? <youpi>only the interrupt handler writes to the status variable <damo22>so you want to disable interrupts before calling that, and somehow process it slowly <youpi>more precisely, you do not want the interrupt to happen between the !potr->status test and the sleep_on() call <youpi>if that happened, the probing thread would be stuck forever <damo22>it times out on the second timeout twice <youpi>did you fix save_flags / restore_flags to use spl? <youpi>restore_flags is supposed to restore the interrupt flag <youpi>so that has to interact with spl <damo22>so it needs to save it to curr_ipl <youpi>err, rather to return the value of curr_ipl <youpi>and restore_flags would basically be an splx call <youpi>ideally it'd only store the info in the appropriate interrupt bit of the flags <youpi>probably no driver uses other flags than the interrupt flag, but possibly some do <youpi>so probably you can leave that aside <damo22>__asm__ __volatile__("pushf ; pop %0" : "=r" (x): /* no input */ :"memory") <damo22>doesnt that save the current flags to x <youpi>you want to replace that with copying curr_ipl to x <damo22>#define restore_flags(x) splx(x) <damo22>#define __save_flags(x) (x = curr_ipl > 0 ? 0x400 : 0) <youpi>isn't the interrupt flag 0x200 ? <youpi>(better use (1 << EFLAGS_IF_SHIFT) ) ***Glider_IRC_ is now known as Glider_IRC
<AlmuHS>I got outstanding for my final degree thesis about Hurd SMP!! :-) <AlmuHS>youpi: I got a outstanding with honours for my Hurd SMP final degree project <AlmuHS>ty. It was a big effort (and continues) <AlmuHS>jrtc27: thanks. It seems this index is bad <jrtc27>oh it's all written in spanish :( <AlmuHS>yes. Maybe I will write a paper about this, but the final degree thesis is in spanish <jrtc27>yeah sure it makes sense for internal things (although papers are generally english so an argument could be made there) but unfortunate for those who don't speak it :) <AlmuHS>btw, jrtc27 , youpi and damo22 are quoted in the document <jrtc27>if I applied my brain enough I could *probably* get by with my basic french/italian knowledge <AlmuHS>in a few months I will write a paper <jrtc27>(and domain-specific knowledge... technical writings in non-english language tend to be amusingly high in words that look a lot like the english tech terms) <AlmuHS>yes, but some of my selection board are not familiarized with english terms, and I had to translate these to spanish <AlmuHS>even I had to explain terms as "BSP", "AP"... <youpi>AlmuHS: impressive technical writing :) <youpi>did you get some teacher to actually understand it ? :) <AlmuHS>my tutor is a operating systems teacher <AlmuHS>the notes about scheduling and MMU in the operating system subject of my degree has been written by him <AlmuHS>but these notes are so generic, don't explain about how x86 apply this concepts <gnu_srs2>youpi: How important are libblkid-dev, libparted-dev, libpciaccess-dev, uuid-dev? <gnu_srs2>Can lwip be built with GNU tools: Cross-building cmake is just too much... <youpi>gnu_srs2: libpciaccess is needed for netdde <youpi>I don't know about lwip with GNU tools <youpi>(blkid/parted/uuid are needed only for userland partition support)