turned out to be interesting. The Plan 9 kernel is pre-emptible (and has been for a while). The only kind of interrupt that won''t get preempted is the clock or timer. The key is that you need to make sure that the VIRQ_TIMER gets mapped to the plan 9 timer irq. Once I realized that, I''m getting much further with things working right. In fact the boot process is working until it times out on no enet packets, which is actually fine -- lots of kprocs and procs running and doing the right thing now. ron -- LANL CCS-1 email flavor: ***** Correspondence [] ***** DUSA LACSI-HW [ ] ***** DUSA LACSI-OS [x ] ***** DUSA LACSI-CS [ ] ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Wed, 11 Aug 2004, ron minnich wrote:> > turned out to be interesting. The Plan 9 kernel is pre-emptible (and has > been for a while). The only kind of interrupt that won''t get preempted is > the clock or timer. The key is that you need to make sure that the > VIRQ_TIMER gets mapped to the plan 9 timer irq. Once I realized that, I''m > getting much further with things working right. > > In fact the boot process is working until it times out on no enet packets, > which is actually fine -- lots of kprocs and procs running and doing the > right thing now.Actually, I''d like to chime in here. I''ve been reading your threads with great interest. Not because I am porting an OS, but because we are seeing odd issues with time in our instances. We have a xen 1.2 system. Very often, several instances stop receiving timer interrupts. I assume this is what is happening, because time gets frozen, and no longer advances on them. Maybe this really is a valid bug, and has existed for awhile. Actually, catting /proc/interrupts *does* show the interrupt occuring. However, time is *not* advancing. doogie@xen-1-13:~$ time sleep 1 real 0m0.000s I waited 3 seconds, then hit ctrl-c ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Fri, 13 Aug 2004, Adam Heath wrote:> We have a xen 1.2 system. Very often, several instances stop receiving timer > interrupts. I assume this is what is happening, because time gets frozen, and > no longer advances on them.I saw something like this when I was blocking clock interrputs by mistake in Plan 9 dom1. Lots of stuff worked well -- up to a point, which is why I found the problem. It''s amazing how long an OS will run with clock interrupts completely off -- I''ve tried this in linux, disabling clocks with my DKM tool, and things work well for a long time (X will die at some point however). sounds like a lingering bug, but you should move forward to 2.0 anyway ... We need to start working out the vga issues. ron ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel