Re: FreeBSD HVM+PV domU hangs on boot -- but not if using file-backed storage

[Adam Hamsik <haaaad%gmail.com@localhost>]

On May,Thursday 27 2010, at 10:20 PM, Hugo Silva wrote:

> Adam Hamsik wrote:
>> On May,Thursday 27 2010, at 11:25 AM, Hugo Silva wrote:
>> 
>>  
>>> It doesn't mean much but I was able to run HVM+PV FreeBSD many months ago 
>>> on a Debian dom0, also with lvm-backed storage. I can't test that now 
>>> either, as the machine happily runs NetBSD -current these days.
>>> 
>>> 
>>> The only remotely suspect message I was able to find while booting the 
>>> domUis:
>>> xbdback backend/vbd/3/768: unknown device 0xc207 (major=194)
>>>    
>> 
>> 194 is major number of device-mapper (aka lvm) devices. Can you debug this 
>> issue more ? But I'm really not sure where to start. Is this message from 
>> xen tools or from kernel ?   
> 
> It is from the kernel.
>> It looks like that it can be from xbdback_xenbus.c#691
>> 
>>      if (mode[0] == 'w')
>>                xbdi->xbdi_ro = 0;
>>        else
>>                xbdi->xbdi_ro = 1;
>>        major = major(xbdi->xbdi_dev);
>>        devname = devsw_blk2name(major);
>>        if (devname == NULL) {
>>                printf("xbdback %s: unknown device 0x%"PRIx64"\n",
>>                    xbusd->xbusd_path, xbdi->xbdi_dev);
>>                return;
>>        }
>> 
>> But my sources are different I can't find '(major=194)' there. Can you post 
>> your part of these sources or add printfs there to confirm this theory ?
>>  
> 
> You are correct, it comes from xbdback_xenbus.c.
> 
> # mv xbdback_xenbus.c xbdback_xenbus.c.orig
> # cvs update -P -d
> cvs update: Updating .
> cvs update: warning: xbdback_xenbus.c was lost
> U xbdback_xenbus.c
> # diff xbdback_xenbus.c xbdback_xenbus.c.orig
> 693,694c693,694
> < printf("xbdback %s: unknown device 0x%"PRIx64"\n",
> < xbusd->xbusd_path, xbdi->xbdi_dev);
> ---
> > printf("xbdback %s: unknown device 0x%"PRIx64" (major=%d)\n",
> > xbusd->xbusd_path, xbdi->xbdi_dev, major);
> 
> 
> I must have added the major=%d myself during one of our previous debug 
> sessions. Oops :-)
>> How many lvm devices do you use ? Because I can't really see how this can 
>> fail for some domU and work for other.
>> 
>> 
>> Regards
>> 
>> Adam.
>> 
>>  
> # lvm lvs
> File descriptor 3 () leaked on lvm invocation. Parent PID 71:
> Found duplicate PV Vl95SzA75G4TqDSLC2F3vOvrkd1wGiFC: using /dev/rraid1d not 
> /dev/rraid1a
> Found duplicate PV 2phD1fxXEmHvIbXxMeaClrVNe8BknhDM: using /dev/rraid2d not 
> /dev/rraid2a
> LV VG Attr LSize Origin Snap% Move Log Copy% Convert
> fileserver vg1 -wi-a- 24.00g
> ftest vg1 -wi-a- 4.00g
> obsdtest vg1 -wi-a- 4.00g
> pythondev vg1 -wi-a- 24.00g
> pythondev2 vg1 -wi-a- 16.00g
> wiki vg1 -wi-a- 8.00g
> wiki-data0 vg1 -wi-a- 4.00g
> 
> 
> This is on NetBSD 5.99.29 amd64, by the way.
> 
> I don't rule out the possibility that this could be some file I edited or 
> some patch I forgot to reapply. Could someone confirm FreeBSD's XENHVM with 
> lvm also hangs? Instructions are on my previous email -- shouldn't take more 
> than 20 minutes.


> 
> Adam, if there are no volunteers I will update my -current and give it 
> another go with fresh sources. This reminds me - the block-raw.diff patch, 
> was it integrated in pkgsrc?
> 

I will sent you some debug patch later on, so we can find what is going on. 
Nope I was overloaded and I not know how to do it properly.

> p.s: I've always wondered what the above "File descriptor 3 () leaked on lvm 
> invocation" means. Is it harmless? I see some of them during dom0 boot.
I stared to see them after latest upgrade but I haven't had time to debug them. 
Maybe -ddddd run can help to find from where we are getting this error.

> p.p.s: Same for "Found duplicate PV". It seems to be harmless as lvm works, 
> but as far as I remember I've always seen these messages. Now I'm wondering. 
> Is it normal?

It's normal on NetBSD because a and d partitions points to same device if you 
create PV on d partition(there is no disklabel on disk).

Regards

Adam.