On Dec 24, 2008, at 2:55 AM, Gabe Black wrote: > It looks like the version in the tree is actually already fixed. > Execution is now getting to the point where the wbinvd instruction is > being executed. This instruction is supposed to write back the > contents > of the cache and mark everything invalid, and from previous > conversations I know there isn't any way to make the caches do that > right now. If someone that knows more about the cache could comment, > or > even better if someone with shiny new microcode knowledge and existing > cache knowledge could implement that instruction, that would be great. At this point I would just print a warning and continue execution. Without caches it won't matter, and our l1s are coherent wrt each other so that should be ok too.
> While I'm writing, here's a brief status update. I fixed a few more > things, mostly unrelated to IDE, and I discovered that I was actually > successfully accessing the disk since I wrote last. There's a DMA time > out from the controller, but then the interrupt it was waiting for > comes > in shortly after that. I'm not entirely sure why that's happening, but > it might be because I handle all interrupts like they were edge > triggered instead of level triggered like I think they're intended to > be. It could also be that the DMA timing out is confusing the > kernel, or > that the pciToDma function (what exactly is that for anyway?) isn't > implemented right for x86, or something else. The simulation killing > problem I'm running into after that is that there's a page fault when > execing the initial process. I think that might be because of some > sort > of COW and pagefaults not being implemented at all, or it could be > something completely unrelated. In any case, it's getting really close > to the point where I'll need to be able to handle both a TLB miss and > some sort of architectural fault as a result of the same translation. I would guess that the interrupt comes in after the DMA times out and the device driver pokes the device again. I've seen this occur before and it normally had something to do with DMA not completely successfully. This could be because the caches were broken (which they aren't now) or more likely as you mentioned the pciToDma() function not being implemented correctly. Here too it might be because the IDE controller just DMAed over the page table. pciToDma() is supposed to turn a DMA address into a physical address. The function in src/dev/ alpha/tsunami_pchip.cc:translatePciToDma() handles this for Alpha. In the Alpha case it can be just a simple masking/replacing of some address bits or a one level translation. My guess is (as always) that x86 is going to be more complicated. For example if you have an I/O MMU this would be be the place to do that translation. Ultimately, you can get an idea about what linux is doing there by looking at the pci_map_page() and pci_map_single() functions for x86. Ali > > Gabe > > [email protected] wrote: >> Yes. I'm having network issues so it might not make it into the >> tree quickly. >> >> Gabe >> >> Quoting nathan binkert <[email protected]>: >> >> >>> I recently put the mkblankimage.sh script in m5/util. My guess is >>> that we should remove the one from the website (with maybe a pointer >>> to the repository) and fix the one in the tree. Can you take care >>> of >>> it gabe? >>> >>> >>>> I have the M5 ops working, but the slow IDE controller turned out >>>> to be >>>> a bug in the rdtsc (read time stamp counter) instruction and a >>>> coincidence of timing. When making a blank image using the script >>>> on the >>>> website, there was a bug which was fairly easy to fix. There was >>>> one >>>> place where sudo was used directly instead of using the run_priv >>>> (right >>>> name?) function, so if you try to run as root without using sudo it >>>> won't work. I think it was on line 154, but I haven't looked at >>>> that for >>>> a day or two so that may be completely wrong. I still haven't >>>> actually >>>> ran anything off the image I made, but I've fixed a few problems >>>> and I'm >>>> getting closer. Happy holidays everybody! >>>> >>> _______________________________________________ >>> m5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/listinfo/m5-dev >>> >>> >> >> >> >> >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
