From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark van Dijk Subject: Re: Possible bug with huge unflushed console buffer Date: Fri, 10 Aug 2012 11:29:12 +0200 Message-ID: <20120810112912.6df40924@internecto.net> References: <20120808174355.470746e0@internecto.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Keir Fraser Cc: Konrad Rzeszutek Wilk , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org Greetings, > > The behaviour I encountered i.e. a system lock seems to suggest that > > there was some kind of buffer overflow. And this can be achieved by > > something as simple as 'iptables -I INPUT -j LOG'. Perhaps it is a > > wise idea to consider xl console -c to clear the console's history, > > then at least I could exit the console and clear unsent messages... > > Is your VM logging to its virtual serial line? You could just not do > that... Correct, it is logging to the virtual serial line and you're right, I could just not do that. But isn't that just a workaround? I just think that if you emulate something like a serial line, it should be emulated properly. Why don't we just discard the data that is sent to a detached serial line? That's what bare metal servers do too, right? > I think this is due to the guest's qemu-dm process stuffing its > transmitted serial data into a pty, to be consumed by 'xl console', > and if that doesn't happen the buffers fill up, serial processing > stops, and we back up all the way to the guest. Right. So the issue is only with the guest, not with the hypervisor. That's a relief. :) -- Stay in touch, Mark van Dijk. ,-------------------------------- ----------------------------' Fri Aug 10 09:11 UTC 2012 Today is Boomtime, the 3rd day of Bureaucracy in the YOLD 3178