| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] dom0 panic when using xm block-attach/block-detach -f
Hi list,
I tried to verify my problem with xen-4.0.0-rc1.
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!
>
>
--
Company details: http://ts.fujitsu.com/imprint.html
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home