[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Fix device removal on net and block frontend drivers
On Mon, 21 Nov 2005, Ewan Mellor wrote: > On Mon, Nov 21, 2005 at 11:48:10AM -0600, Adam Heath wrote: > > > On Mon, 21 Nov 2005, Murillo Fernandes Bernardes wrote: > > > > > > > > Frontend devices are not being unregistered when in closed state. The > > > following patch fix that. > > > > > > Fix bug #420. > > > > > > Makes "05_attach_and_dettach_device_repeatedly_pos" and > > > "09_attach_and_dettach_device_check_data_pos" tests pass. > > > > > > > > > Signed-off-by: Murillo Fernandes Bernardes <mfb@xxxxxxxxxx> > > > > Hmm. I have a way to make dom0 in unstable kernel-oops. If I attempt to > > setup a virtual block device to a /dev/nbN(enbd), but never actually > > configure > > the /dev/nbN, I get a kernel oops in dom0 when the domU shutdowns down. I > > can > > then no longer reboot or shutdown the dom0. > > > > Would this be related? > > This doesn't seem very related, no. What does your oops look like? >From the config file: == disk = [ 'phy:/dev/space/xen-0-16-swap-0,hda,w', 'phy:/dev/space/xen-0-16-tmp,hdb,w', 'phy:/dev/nda,hdc,w', 'phy:/dev/ndb,hdd,w' ] == /dev/nda and /dev/ndb have not been configured yet. >From the domU: == [61776.756910] Registering block device major 3 [61776.756999] hda: unknown partition table [61776.782867] hdb: unknown partition table [61776.805007] Registering block device major 22 [61776.805096] hdc:end_request: I/O error, dev hdc, sector 0 [61776.805225] Buffer I/O error on device hdc, logical block 0 [61776.805372] end_request: I/O error, dev hdc, sector 0 [61776.805379] Buffer I/O error on device hdc, logical block 0 [61776.805392] unable to read partition table == And from dom0, the oops(plus leading lines from syslog): Nov 21 14:21:38 xen-3 logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/1/768 Nov 21 14:21:39 xen-3 logger: /etc/xen/scripts/block: Writing backend/vbd/1/768/physical-device 0xfe01 backend/vbd/1/768/node /dev/space/xen-0-16-swap-0 to xenstore. Nov 21 14:21:39 xen-3 logger: /etc/xen/scripts/block: Writing backend/vbd/1/768/hotplug-status connected to xenstore. Nov 21 14:21:39 xen-3 logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/1/832 Nov 21 14:21:40 xen-3 logger: /etc/xen/scripts/block: Writing backend/vbd/1/832/physical-device 0xfe02 backend/vbd/1/832/node /dev/space/xen-0-16-tmp to xenstore. Nov 21 14:21:40 xen-3 logger: /etc/xen/scripts/block: Writing backend/vbd/1/832/hotplug-status connected to xenstore. Nov 21 14:21:40 xen-3 logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/1/5632 Nov 21 14:21:40 xen-3 logger: /etc/xen/scripts/block: Writing backend/vbd/1/5632/physical-device 0x2b00 backend/vbd/1/5632/node /dev/nda to xenstore. Nov 21 14:21:40 xen-3 logger: /etc/xen/scripts/block: Writing backend/vbd/1/5632/hotplug-status connected to xenstore. Nov 21 14:21:41 xen-3 logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/1/5696 Nov 21 14:21:41 xen-3 logger: /etc/xen/scripts/block: Writing backend/vbd/1/5696/physical-device 0x2b10 backend/vbd/1/5696/node /dev/ndb to xenstore. Nov 21 14:21:41 xen-3 logger: /etc/xen/scripts/block: Writing backend/vbd/1/5696/hotplug-status connected to xenstore. Nov 21 14:21:42 xen-3 logger: /etc/xen/scripts/vif-route: online XENBUS_PATH=backend/vif/1/0 Nov 21 14:21:43 xen-3 kernel: [61773.038490] ip_tables: (C) 2000-2002 Netfilter core team Nov 21 14:21:43 xen-3 logger: /etc/xen/scripts/vif-route: Writing backend/vif/1/0/hotplug-status connected to xenstore. Nov 21 14:21:46 xen-3 kernel: [61776.805155] nbd0: Request when not-ready Nov 21 14:21:46 xen-3 kernel: [61776.805187] end_request: I/O error, dev nbd0, sector 0 Nov 21 14:21:46 xen-3 kernel: [61776.805323] nbd0: Request when not-ready Nov 21 14:21:46 xen-3 kernel: [61776.805343] end_request: I/O error, dev nbd0, sector 0 Nov 21 14:21:46 xen-3 kernel: [61776.820855] general protection fault: 0000 [#1] Nov 21 14:21:46 xen-3 kernel: [61776.820879] SMP Nov 21 14:21:46 xen-3 kernel: [61776.820898] Modules linked in: ipt_physdev iptable_filter ip_tables i2c_i801 i2c_core dm_mod nbd sd_mod ata_ piix libata scsi_mod Nov 21 14:21:46 xen-3 kernel: [61776.820979] CPU: 0 Nov 21 14:21:46 xen-3 kernel: [61776.820980] EIP: 0061:[<c0160b60>] Not tainted VLI Nov 21 14:21:46 xen-3 kernel: [61776.820982] EFLAGS: 00010282 (2.6.12.6-xen) Nov 21 14:21:46 xen-3 kernel: [61776.821039] EIP is at blkdev_put+0x9/0x13c Nov 21 14:21:46 xen-3 kernel: [61776.821059] eax: fffffffa ebx: fffffffa ecx: 00000000 edx: 00000106 Nov 21 14:21:46 xen-3 kernel: [61776.821083] esi: c59c46a0 edi: c005a800 ebp: c59c4658 esp: c0427f40 Nov 21 14:21:46 xen-3 kernel: [61776.821107] ds: 007b es: 007b ss: 0069 Nov 21 14:21:46 xen-3 kernel: [61776.821126] Process events/0 (pid: 4, threadinfo=c0426000 task=c0057a20) Nov 21 14:21:46 xen-3 kernel: [61776.821137] Stack: 00000000 c59c467c c59c46a0 c005a800 c59c4658 c025e0bb c59c4658 c025df6c Nov 21 14:21:46 xen-3 kernel: [61776.821207] 00000000 c012c343 00000000 00000002 c1114c60 000de3dd c005a80c c005a814 Nov 21 14:21:46 xen-3 kernel: [61776.821272] c0426000 c59c469c c025df4a 00000001 00000000 c1114c60 00010000 00000000 Nov 21 14:21:46 xen-3 kernel: [61776.821337] Call Trace: Nov 21 14:21:46 xen-3 kernel: [61776.821366] [<c025e0bb>] vbd_free+0xf/0x18 Nov 21 14:21:46 xen-3 kernel: [61776.821394] [<c025df6c>] free_blkif+0x22/0x4c Nov 21 14:21:46 xen-3 kernel: [61776.821421] [<c012c343>] worker_thread+0x175/0x242 Nov 21 14:21:46 xen-3 kernel: [61776.821450] [<c025df4a>] free_blkif+0x0/0x4c Nov 21 14:21:46 xen-3 kernel: [61776.822757] [<c0118fd3>] default_wake_function+0x0/0xc Nov 21 14:21:46 xen-3 kernel: [61776.822786] [<c012c1ce>] worker_thread+0x0/0x242 Nov 21 14:21:46 xen-3 kernel: [61776.822814] [<c012ff99>] kthread+0x93/0x97 Nov 21 14:21:46 xen-3 kernel: [61776.822840] [<c012ff06>] kthread+0x0/0x97 Nov 21 14:21:46 xen-3 kernel: [61776.822867] [<c01070b5>] kernel_thread_helper+0x5/0xb Nov 21 14:21:46 xen-3 kernel: [61776.822894] Code: 89 d8 5b 5e 5f c3 89 f2 89 f8 e8 b6 fa ff ff 89 c3 85 c0 74 e9 89 f8 e8 06 00 00 00 89 d8 5b 5e 5f c3 55 57 56 53 83 ec 04 89 c3 <8b> 70 04 8b 78 58 8d 40 0c 89 04 24 f0 ff 4b 0c 0f 88 3d 03 00 == Doing an objdump of fs/block_dev.c(where blkdev_put exists), I get this: == 00000ca7 <blkdev_put>: ca7: 55 push %ebp ca8: 57 push %edi ca9: 56 push %esi caa: 53 push %ebx cab: 83 ec 04 sub $0x4,%esp cae: 89 c3 mov %eax,%ebx cb0: 8b 70 04 mov 0x4(%eax),%esi cb3: 8b 78 58 mov 0x58(%eax),%edi cb6: 8d 40 0c lea 0xc(%eax),%eax cb9: 89 04 24 mov %eax,(%esp) cbc: f0 ff 4b 0c lock decl 0xc(%ebx) cc0: 0f 88 3d 03 00 00 js 1003 <.text.lock.block_dev+0x7e> cc6: e8 fc ff ff ff call cc7 <lock_kernel+0xcc7> ccb: 8b 43 08 mov 0x8(%ebx),%eax == So, address cb0 is at fault. The snippet from block_dev.c has this: == int blkdev_put(struct block_device *bdev) { int ret = 0; struct inode *bd_inode = bdev->bd_inode; struct gendisk *disk = bdev->bd_disk; == bdev->bd_inode is at offset 4. Combined with eax being fffffffa, we get either a wrap-around, or overflow, on the addressing. This all points, however, to vbd->bdev not being initialized properly. In fact, with eax being what it is(-5 is signed int land), makes me believe some error condition isn't being checked. However, after I read the log again, it looks like an error occurs once, something is freed, and error occurs again, then the oops occurs. However, that may just be coincidence. Anyways, that should be enough info for someone a bit more knowledgable to debug this. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |