|
[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
Am 13.01.2010 schrieb Pasi Kärkkäinen: > 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 As you can see in my first mail below this works in openSuse-11.2 with xen-4.3 and linux-2.6.31.5. Dietmar. > > > 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! > > > > > > > > > > > > > > > > > > -- Dietmar Hahn TSP ES&S SWE OS Telephone: +49 (0) 89 3222-2952 Fujitsu Technology Solutions Email: dietmar.hahn@xxxxxxxxxxxxxx Domagkstraße 28 Internet: http://ts.fujitsu.com D-80807 München Company details:ts.fujitsu.com/imprint.html _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |