[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] dom0 panic when using xm block-attach/block-detach -f



On Wed, Jan 13, 2010 at 11:13:50AM +0100, Dietmar Hahn wrote:
> Am 13.01.2010 schrieb Pasi Kärkkäinen:
> > On Wed, Jan 13, 2010 at 10:23:17AM +0100, Dietmar Hahn wrote:
> > > Hi list,
> > > 
> > > I tried to verify my problem with xen-4.0.0-rc1.
> > >
> > 
> > What dom0 kernel did you use? What kernel did you use in the guest?
> 
> The pv_ops kernel downloaded during make world:
> # uname -a
> Linux chiana 2.6.31.6-xen-400rc1 #6 SMP Wed Jan 13 10:43:49 CET 2010 x86_64 
> x86_64 x86_64 GNU/Linux
> 
> I only added ext4 to the config because the Linux-partition is ext4 ;-)
>

Ok. 

I'm not sure if block-attach to dom0 has ever been supported? 
Did it work at some point for you? 

-- Pasi

> Dietmar.
> 
> > 
> > -- Pasi
> > 
> > 
> > > I did again the block-attach:
> > > 
> > > # xm block-attach 0 tap:aio:my-image.iso xvda r
> > > 
> > > But now I don't get any devices /dev/xvda?
> > > Now I'am a little bit confused!
> > > 
> > > # fdisk -l my-image.iso
> > > You must set cylinders.
> > > You can do this from the extra functions menu.
> > > 
> > > Disk my-image.iso: 0 MB, 0 bytes
> > > 255 heads, 63 sectors/track, 0 cylinders
> > > Units = cylinders of 16065 * 512 = 8225280 bytes
> > > Disk identifier: 0x00044fcc
> > > 
> > >        Device Boot      Start         End      Blocks   Id  System
> > > my-image.iso1               1          17      136521   82  Linux swap / 
> > > Solaris
> > > my-image.iso2   *          18         522     4056412+  83  Linux
> > > 
> > > Any help would be appreciated.
> > > Thanks.
> > > 
> > > Dietmar.
> > > 
> > > Am 08.01.2010 schrieb Dietmar Hahn:
> > > > Hi list,
> > > > 
> > > > I have an image with a bootable system and do the following steps:
> > > > # xm block-attach 0 tap:aio:my-image.iso xvda r
> > > > mount the root partition:
> > > > # mount /dev/xvda2 /mnt
> > > > Now forcing block-detach:
> > > > # xm block-detach 0 51712 -f
> > > > 
> > > > This leads to an inconsistent sysfs in dom0.
> > > > The xen device /sys/devices/xen/vbd-51712 gets removed but lots of 
> > > > links remain.
> > > > 
> > > > In the log I can see the message:
> > > > [  349.928350] vbd vbd-51712: 16 Device in use; refusing to close
> > > > 
> > > > The next call of
> > > > # xm block-attach 0 tap:aio:my-image.iso xvda r
> > > > leads to the panic, because creating of a sysfs entry failed
> > > > (it's already there) and a not existing failure handling (return of
> > > > register_disk() in add_disk()) leads to the panic later.
> > > > 
> > > > [  210.184660] WARNING: at 
> > > > /usr/src/linux-2.6.31.5-0.1/fs/sysfs/dir.c:489 
> > > > sysfs_add_one+0xde/0x150()
> > > > [  210.184662] Hardware name: CELSIUS H270
> > > > [  210.184663] sysfs: cannot create duplicate filename 
> > > > '/dev/block/202:0'
> > > > [  210.184664] Modules linked in: ext4 jbd2 crc16 netbk blkbk 
> > > > blkback_pagemap snd_pcm_oss snd_mixer_oss blktap snd_seq snd_seq_device 
> > > > edd ipv6 af_packet bridge stp llc fuse loop dm_mod arc4 ecb cryptomgr 
> > > > aead pcompress snd_hda_codec_realtek crypto_blkcipher crypto_hash 
> > > > crypto_algapi snd_hda_intel iwlagn snd_hda_codec iwlcore pcmcia 
> > > > snd_hwdep led_class snd_pcm ppdev mac80211 snd_timer 8250_pci 
> > > > yenta_socket parport_pc 8250_pnp snd tpm_infineon rsrc_nonstatic 
> > > > i2c_i801 parport iTCO_wdt 8250 soundcore cfg80211 intel_agp tpm e1000e 
> > > > video pcmcia_core i2c_core heci(C) iTCO_vendor_support sr_mod sg pcspkr 
> > > > serio_raw joydev serial_core snd_page_alloc rfkill agpgart tpm_bios 
> > > > output container battery button ac usbhid hid uhci_hcd ehci_hcd xenblk 
> > > > cdrom xennet fan thermal processor thermal_sys hwmon ide_pci_generic 
> > > > ide_core sata_sil24 ata_generic
> > > > [  210.184697] Pid: 15, comm: xenwatch Tainted: G         C 
> > > > 2.6.31.5-0.1-xen-hahn #9
> > > > [  210.184698] Call Trace:
> > > > [  210.184701]  [<ffffffff800117e9>] try_stack_unwind+0x189/0x1b0
> > > > [  210.184704]  [<ffffffff8000f2c6>] dump_trace+0xa6/0x1e0
> > > > [  210.184707]  [<ffffffff800112f4>] show_trace_log_lvl+0x64/0x90
> > > > [  210.184710]  [<ffffffff80011343>] show_trace+0x23/0x40
> > > > [  210.184712]  [<ffffffff80460e6e>] dump_stack+0x81/0x9e
> > > > [  210.184717]  [<ffffffff8004cf50>] warn_slowpath_common+0x80/0xd0
> > > > [  210.184720]  [<ffffffff8004d02b>] warn_slowpath_fmt+0x4b/0x70
> > > > [  210.184723]  [<ffffffff8018f48e>] sysfs_add_one+0xde/0x150
> > > > [  210.184726]  [<ffffffff8018fb3b>] sysfs_do_create_link+0x17b/0x200
> > > > [  210.184729]  [<ffffffff8018fc21>] sysfs_create_link+0x21/0x40
> > > > [  210.184732]  [<ffffffff802e0375>] device_add+0x1d5/0x620
> > > > [  210.184734]  [<ffffffff80185e76>] register_disk+0x66/0x1c0
> > > > [  210.184737]  [<ffffffff8022212b>] add_disk+0xcb/0x1b0
> > > > [  210.184742]  [<ffffffffa0098cb4>] backend_changed+0x354/0x3a0 
> > > > [xenblk]
> > > > [  210.184746]  [<ffffffff802fb952>] otherend_changed+0xf2/0x1c0
> > > > [  210.184749]  [<ffffffff802f931c>] xenwatch_handle_callback+0x2c/0x80
> > > > [  210.184752]  [<ffffffff802f9538>] xenwatch_thread+0x1c8/0x200
> > > > [  210.184755]  [<ffffffff8006cf96>] kthread+0xb6/0xc0
> > > > [  210.184758]  [<ffffffff8000d25a>] child_rip+0xa/0x20
> > > > [  210.184760] ---[ end trace 2db54c629bf6d53c ]---
> > > > ...
> > > > 
> > > > The problem seems to be that in backend_changed() the device is seen as 
> > > > in use
> > > > and so blkfront_closing() -> xlvbd_del() -> del_gendisk()
> > > > isn't called to remove the links but later the xen device gets removed.
> > > > 
> > > > What to do here?
> > > > If a user of the -f flag "SHOULD know what he is doing" than the manual 
> > > > page
> > > > of the xm command has to be changed.
> > > > Ohterwise how can this be solved?
> > > > 
> > > > Thanks.
> > > > Dietmar.
> > > > 
> > > > This was testet on OpenSuSE-11.2 with xen-3.4 and linux-2.6.31.5,
> > > > don't know about xen-unstable!
> > > > 
> > > > 
> > 
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.