Bug 442682

Summary: F-9 pv_ops xen: Warnings and I/O errors during 32 bit install
Product: [Fedora] Fedora Reporter: Mark McLoughlin <markmc>
Component: kernel-xen-2.6Assignee: Xen Maintainance List <xen-maint>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: berrange, ehabkost, ondrejj
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-07-01 07:33:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 434756    
Attachments:
Description Flags
syslog none

Description Mark McLoughlin 2008-04-16 09:13:37 UTC 
On 32 bit, with the 2008-04-13 install tree and kernel-xen-2.6.25-0.24.rc9.i686,
I'm seeing:

<4>------------[ cut here ]------------
<4>WARNING: at block/blk-core.c:334 blk_start_queue+0x25/0x6d() (Not tainted)
<4>Modules linked in: sha256_generic aes_generic cbc dm_crypt crypto_blkcipher
dm_emc dm_round_robin dm_multipath dm_snapshot
 dm_mirror dm_zero dm_mod xfs jfs reiserfs lock_nolock gfs2 msdos linear raid10
raid456 async_xor async_memcpy async_tx xor r
aid1 raid0 xen_netfront xen_blkfront ipv6 iscsi_tcp libiscsi
scsi_transport_iscsi scsi_mod ext2 ext3 jbd ext4dev jbd2 mbcache
 crc16 squashfs pcspkr edd loop nfs lockd nfs_acl sunrpc vfat fat cramfs
<4>Pid: 0, comm: swapper Not tainted 2.6.25-0.24.rc9.fc9.i686.xen #1
<4> [<c042b0a1>] warn_on_slowpath+0x47/0x73
<4> [<c0405fcf>] ? xen_restore_fl_direct_end+0x0/0x1
<4> [<c0404df9>] ? force_evtchn_callback+0xd/0x10
<4> [<c040604a>] ? check_events+0x8/0xe
<4> [<c0405fcf>] ? xen_restore_fl_direct_end+0x0/0x1
<4> [<c048451b>] ? kmem_cache_free+0x89/0x93
<4> [<c0404df9>] ? force_evtchn_callback+0xd/0x10
<4> [<c040604a>] ? check_events+0x8/0xe
<4> [<c0405fcf>] ? xen_restore_fl_direct_end+0x0/0x1
<4> [<c048451b>] ? kmem_cache_free+0x89/0x93
<4> [<c04ea3b0>] ? __freed_request+0x20/0x77
<4> [<c04ea424>] ? freed_request+0x1d/0x34
<4> [<c04ea4ad>] ? __blk_put_request+0x72/0x77
<4> [<c04ea6d9>] ? end_that_request_last+0x227/0x22f
<4> [<c04eb558>] blk_start_queue+0x25/0x6d
<4> [<e0a05739>] kick_pending_request_queues+0x19/0x24 [xen_blkfront]
<4> [<e0a058cb>] blkif_interrupt+0x187/0x1a1 [xen_blkfront]
<4> [<c045fce8>] handle_IRQ_event+0x2a/0x5a
<4> [<c0460c9c>] handle_level_irq+0x7a/0xbe
<4> [<c0460c22>] ? handle_level_irq+0x0/0xbe
<4> [<c040aee8>] do_IRQ+0x98/0xc4
<4> [<c0404f9a>] xen_evtchn_do_upcall+0x75/0xac
<4> [<c0409830>] xen_hypervisor_callback+0x3c/0x44
<4> [<c0403111>] ? xen_safe_halt+0x10/0x1b
<4> [<c0403e5c>] ? xen_idle+0x0/0x40
<4> [<c0403e8b>] xen_idle+0x2f/0x40
<4> [<c0407b44>] cpu_idle+0xa1/0xc1
<4> [<c06256e5>] rest_init+0x49/0x4b
<4> =======================
<4>---[ end trace 5e0ebc484baf5166 ]---
...
<3>end_request: I/O error, dev xvda, sector 17296121
<3>Buffer I/O error on device dm-0, logical block 2111764
<4>lost page write due to I/O error on dm-0
...

Full log attached

(Dom0 is a fairly up to date rawhide running a 2.6.21.7 kernel-xen)
Comment 1 Mark McLoughlin 2008-04-16 09:14:14 UTC 
Created attachment 302565 [details]
syslog
Comment 2 Mark McLoughlin 2008-04-16 09:15:10 UTC 
Oh, and I'm *not* seeing this during 64 bit installs
Comment 3 Mark McLoughlin 2008-04-18 08:01:25 UTC 
Also, installs do seem to complete just fine in spit of the I/O errors
Comment 4 Bug Zapper 2008-05-14 09:31:16 UTC 
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Jan ONDREJ 2008-05-19 09:43:04 UTC 
This happens when trying to install i386 domU F9 on x86_64 Dom0 F8.
Installing x86_64 domU F9 on x86_64 dom0 F8 works, but can't boot properly
(after testing I will create a new bug).
Comment 6 Mark McLoughlin 2008-07-01 07:33:56 UTC 
Not sure whether we still get these warnings, but they don't seem to be causing
problems in practice, so closing for now ...