2.4.26-xenU boots fine on my T41 laptop, with the exception that it glitches numlock at some point so you have to hit numlock a few times unless you have a login for r66t :-) Is there any way other than com1 to get xen debug output at this point? Also my xen is still at 1.3 -- should I just bite the bullet and get -unstable again (which I assume is sort of 2.0)? Which tree do you recommend I pull for the ''latest bug fix'' :-) I got more time to work on the Plan 9 port, and yikes! it is close to mounting its root file system. This is the lashup: 1. vmware session with Plan 9 auth/file server 2. vmware session with xen 1.3, 2.4.26-xen0, and plan 9 in domN The current hangup is literally that. Plan 9 front end network gets packets fine -- to a point. Then it starts getting network frontend interrupts but the producer/consumer numbers are the same -- i.e. it gets into the netif_poll from the interrupt handler and the indication is that there are no new packets to consume, going by the numbers. This can happen at packet 18, or packet 30, or packet 138 -- it''s not deterministic. I just did a bk get last night and rebuilt, and it gets farther, but still gets stuck at some point. I get several interrupts but no indication from the shared memory counters that there are packets there. Will Xen ever send me an interrupt if there are no packets to receive? What''s a good thing to look for here? This packet lockup is the only thing between me and a multi-user plan 9 cpu server working :-) I am going to try running straight on the laptop without vmware to make sure it''s not that, but I''m doubtful that will do it. ron ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > 2.4.26-xenU boots fine on my T41 laptop, with the exception that it > glitches numlock at some point so you have to hit numlock a few times > unless you have a login for r66t :-)I gave my "6 concurrent versions of Linux" demo at OLS2004 on a T41, and I can''t recall any issues with numlock. odd.> Is there any way other than com1 to get xen debug output at this point?com2 ;-) There''s also ''xm dmesg'' if you''ve got a running system.> Also my xen is still at 1.3 -- should I just bite the bullet and get > -unstable again (which I assume is sort of 2.0)? Which tree do you > recommend I pull for the ''latest bug fix'' :-)Right now, it shouldn''t matter : unstable and 2.0 are very close as the latter is just a time-delayed version of the former where bug fixes get road tested.> The current hangup is literally that. Plan 9 front end network gets > packets fine -- to a point. Then it starts getting network frontend > interrupts but the producer/consumer numbers are the same -- i.e. it gets > into the netif_poll from the interrupt handler and the indication is that > there are no new packets to consume, going by the numbers. This can happen > at packet 18, or packet 30, or packet 138 -- it''s not deterministic. I > just did a bk get last night and rebuilt, and it gets farther, but still > gets stuck at some point. I get several interrupts but no indication from > the shared memory counters that there are packets there. Will Xen ever > send me an interrupt if there are no packets to receive?You shouldn''t get virtual interrupts unless the producer has been advanced past the event threshold. Sounds like you have a bug ;-)> What''s a good thing to look for here? This packet lockup is the only thing > between me and a multi-user plan 9 cpu server working :-)You could add printk''s to the netback driver in dom0 so that you can see what''s happening on the other side and compare it with your view of the world. One thing to watch out for is that the compiler is not caching the producer value in a register. The Linux driver doesn''t have this problem because of calls to non-static functions that ensure the value can not be cached in a register across (as per the C spec). Ian ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel