Dietmar Hahn
2010-Jan-08 11:09 UTC
[Xen-devel] dom0 panic when using xm block-attach/block-detach -f
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@lists.xensource.com http://lists.xensource.com/xen-devel
Dietmar Hahn
2010-Jan-13 09:23 UTC
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@lists.xensource.com
http://lists.xensource.com/xen-devel
Pasi Kärkkäinen
2010-Jan-13 10:05 UTC
Re: [Xen-devel] dom0 panic when using xm block-attach/block-detach -f
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? -- 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! > > > > > -- > Company details: http://ts.fujitsu.com/imprint.html > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Dietmar Hahn
2010-Jan-13 10:13 UTC
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 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 ;-) 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@lists.xensource.com http://lists.xensource.com/xen-devel
Pasi Kärkkäinen
2010-Jan-13 10:32 UTC
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@lists.xensource.com http://lists.xensource.com/xen-devel
Dietmar Hahn
2010-Jan-13 10:54 UTC
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? > > -- PasiAs 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@ts.fujitsu.com 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@lists.xensource.com http://lists.xensource.com/xen-devel
Pasi Kärkkäinen
2010-Jan-13 11:13 UTC
Re: [Xen-devel] dom0 panic when using xm block-attach/block-detach -f
On Wed, Jan 13, 2010 at 11:54:27AM +0100, Dietmar Hahn wrote:> 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. >Ok.. It shouldn''t crash though, even if it doesn''t work. Someone should investigate this more in depth.. Out of curiosity, why do you want to do that? :) kpartx is much more simple, and doesn''t need Xen at all to do the same.. -- Pasi> 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@ts.fujitsu.com > 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@lists.xensource.com http://lists.xensource.com/xen-devel
Dietmar Hahn
2010-Jan-13 12:27 UTC
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:54:27AM +0100, Dietmar Hahn wrote: > > 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. > > > > Ok.. It shouldn''t crash, even if it doesn''t work. > Someone should investigate this more in depth.. > > Out of curiosity, why do you want to do that? :) kpartx is much more > simple, and doesn''t need Xen at all to do the same..It was not my idea. A vm-install tool used these commands to extract the kernel and the initrd from the image. I only analyzed the dom0 panics and could reproduce the panic with these commands. I will talk to the tool writer. 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! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel