| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: domU console buffer behaviour
Keir Fraser <keir.fraser@xxxxxxxxxxxxx> writes:
> On 29/12/2008 20:14, "Ferenc Wagner" <wferi@xxxxxxx> wrote:
>
>> That is, the first 158 lines were dropped and the last 128 lines were
>> overwritten. As formatting is such that each line is 16 bytes, it
>> means that the last 2 kiB was sort of following the guest console
>> output, but in a broken way: lines between 72285--72302 were lost.
>> Only the last 16 lines (256 bytes) are really fresh.
>>
>> All of this feels rather fishy. Can anybody provide some insight,
>> please? Is this expected? Is my config broken? Or is this a bug?
>
> I think the console daemon tries to discard contiguous chunks of
> data, rather than odd characters here and there. How effective it
> really is I'm not sure, but certainly you can expect the discards to
> be in reasonable-sized chunks and also to be pretty random.
Huh, now I'm no closer to have an idea about the expected behaviour.
What does the console daemon try to achieve? Does the randomness stem
from the scheduling irregularity? On which side of the daemon is the
1 MB buffer?
> Why do you think this has something to do with pv_ops lockups?
That's just the only trace I can start with. On kernel lockups, I
usually look for clues in the console output. Now I found it garbled.
Either it is normal and I should look elsewhere, or it is a buffer
handling bug, possibly overwriting some memory and causing havoc
later. I know that's a long shot... But even SysRq didn't work, so I
have nothing more to work with. I'm looking at tools/console/daemon/io.c
now.
--
Thanks,
Feri.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home