| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] 2 questions
>
> 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home