Re: port-xen/47057: Xen NetBSD DomU file system trash under Linux Dom0

[Roger Pau Monné <roger.pau%citrix.com@localhost>]

On 20/10/12 17:38, Manuel Bouyer wrote:
> On Sat, Oct 20, 2012 at 05:31:11PM +0200, Roger Pau Monné wrote:
>>> You can also try to type 'continue' and enter ddb again to see
>>> if things changes (especially where in xenbus_thread it is
>>> interrupted).
>>
>> Nope, the system is completely frozen, tried several times and the trace
>> is exactly the same.
> 
> You mean, it's always at xenbus_thread+0xf5 ? You never see other offsets ?

No, no other offsets.

> 
>> Will compile a new kernel with -g and let's see
>> what I can get, but I bet xenbus_thread is blocked at:
>>
>> 831: printk("XENBUS error %d while reading message\n", err);
>>
>> In fact I'm going to replace that with a panic.
> 
> Maybe just a printf instead of a printk at first.

Tried that in the past (replacing the printk with a printf), and then I
just get in an infite printf loop, intf->rsp_cons and intf->rsp_prod are
corrupted, check_indexes in xb_read always returns false and this leads
to a infinite loop in xenbus_thread because process_msg always return error.

I've now compiled a kernel that has the panic and prints the ring
indexes. What's the best way to check who modifies intf->rsp_cons and
intf->rsp_prod? Will ddb watch work on this kind of memory region?

> If the offset never changes, I wonder if it could be stuck in
>       (void)HYPERVISOR_console_io(CONSOLEIO_write, ret, buf);
>