[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: dom0 serial input overruns
Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> writes: > On Wed, Mar 23, 2011 at 07:57:08PM +0100, Ferenc Wagner wrote: > >> Ferenc Wagner <wferi@xxxxxxx> writes: >> >>> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> writes: >>> >>>> wferi writes: >>>> >>>>> the Xen (and Linux) serial console is also lossy as hell [...] >>>>> However, this lossage isn't accompanied by any warning. >>>> >>>> Oooh, strange. >>> >>> I have to take this back, partly. Although the bare linux serial console >>> is *much* more reliable (I couldn't trigger much visible corruption by a >>> simple 'while echo " X"; do :; done' loop, as under >>> Xen, even that heavily loses characters during the bootup message storm >>> when going through the Serial-over-LAN thingie. Now I took that out of >>> the picture entirely, using a physical serial connection instead. This >>> made a world of difference: bootup logs are pretty much perfect now, and >>> even the above while loop seldom produces a single wiggle (57600 baud). >>> See http://apt.niif.hu/xen_bootup.log for good example (the stray >>> character before "Allocated console ring" seems fully deterministic). >>> I'll test the same console setup under bare Linux tomorrow, maybe that >>> won't make a single error... >> >> Yes, testing confirms that bare Linux is even better, I couldn't notice >> a single missing character (vs. some glitch in every couple of seconds >> under Xen). >> >>> Still, these (infrequent) glitches over hvc0 go unnoticed by the system, >>> as far as I can tell. >> >> Who should notice this, after all? hvc0 itself probably not, being a >> virtual device. Does the Xen serial driver detect overruns? > > It is not a serial driver anymore. It uses some other type of API that > does not have all of the fancy serial support. No idea actually how it > does flow control. I guess you mean hvc. Yes, that surely shadows all the serial stuff which Xen does. But I'm afraid the Xen serial driver underneath has no flow control at all. At least I couldn't find it in the code last time I checked (maybe a year ago). >>>> Look for a thread from 'M A Young' about keyboard issues. >>> >>> Long thread, I'll read through it tomorrow. >> >> There's a good chance I'm running without the fix mentioned in the >> conclusion (I'm yet to check), and my serial interrupts really hit CPU0 >> alone. But my serial connection mostly works, not totally dead like in >> that thread. > > That is good. Happy to have been able to fix your problem by just > talking about it! Er, no, my serial overrun problem isn't fixed at all, it's still present. It just isn't a show stopper, the application copes with this amount of data loss. Still, the amount of generated kernel- and application logs (especially under load) is more than annoying. > BTW, haven't looked in details at the logs - little swamped right now. Sure, getting dom0 support into mainline comes first, definitely. :) Thanks for pushing that along so nicely. The boot logs aren't particularly interesting, maybe except for the one with Xen and Linux errors. It's possible that it should be reported separately... -- Thanks, Feri. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |