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
|
Home