Xen devel - Mar 2010 - Bug xen/next.. WARNING: at /home/konrad/git/nex-VI-PVOPS/linux/kernel/irq/manage.c:274 __enable_irq+0x5c/0xaf(

Jeremy,

This one looks quite familiar. I think I pointed this one out to you the
first time I started working on pv-ops (so, June/July?) and you had a
fix for it, but I can''t remember the details (except that you did ask
me
to review it, and I did, but I didn''t send any details back).

Any ideas?

This is against xen/next as of today with this commit being at the top:

commit cdab7a09b1bd682c5b14effd98a6312c8b798297
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Wed Mar 3 18:05:56 2010 -0500

    xen: Make sure to use the physical IRQ (GSI) instead of the irq.
    
    The IRQ chip startup handler was using the wrong IRQ number. This
    fixes it to use the GSI provided.

Here is the bug that openned against 2.6.30:
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1512

This is the serial output of xen/next:

[  289.059686] ------------[ cut here ]------------
[  289.059703] WARNING: at
/home/konrad/git/nex-VI-PVOPS/linux/kernel/irq/manage.c:274
__enable_irq+0x5c/0xaf()
[  289.059710] Hardware name: To Be Filled By O.E.M.
[  289.059715] Unbalanced enable for IRQ 989
[  289.059719] Modules linked in: event_log iscsi_tcp libiscsi_tcp
libiscsi scsi_transport_iscsi nbd tun dm_round_robin dm_multipath
qla2xxx r8169 tg3
[  289.059786] Pid: 11011, comm: console Tainted: G        W
2.6.32-xen0-00437-gcdab7a0 #30
[  289.059792] Call Trace:
[  289.059800]  [<ffffffff810f050a>] ? __enable_irq+0x5c/0xaf
[  289.059808]  [<ffffffff8107c2d8>] warn_slowpath_common+0xb8/0xe5
[  289.059816]  [<ffffffff8107c3a4>] warn_slowpath_fmt+0x79/0x89
[  289.059824]  [<ffffffff81049d30>] ?
pvclock_clocksource_read+0x81/0xef
[  289.059832]  [<ffffffff810129ee>] ? __spin_time_accum+0x3d/0x79
[  289.059840]  [<ffffffff81012e8a>] ? __xen_spin_lock+0x12f/0x150
[  289.059848]  [<ffffffff81012ed7>] ? xen_spin_lock_flags+0x2c/0x35
[  289.059856]  [<ffffffff8173205e>] ? _spin_lock_irqsave+0x52/0x6e
[  289.059864]  [<ffffffff810f050a>] __enable_irq+0x5c/0xaf
[  289.059872]  [<ffffffff810f0a91>] enable_irq+0x67/0x9b
[  289.059879]  [<ffffffff813b4fd8>] evtchn_write+0xfe/0x14f
[  289.059887]  [<ffffffff8116cfde>] vfs_write+0xf4/0x172
[  289.059894]  [<ffffffff8116d16f>] sys_write+0x6a/0xab
[  289.059902]  [<ffffffff81016d02>] system_call_fastpath+0x16/0x1b
[  289.059908] ---[ end trace a7919e7f17c0a79b ]---


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 03/09/2010 07:52 AM, Konrad Rzeszutek Wilk wrote:
> Jeremy,
>
> This one looks quite familiar. I think I pointed this one out to you the
> first time I started working on pv-ops (so, June/July?) and you had a
> fix for it, but I can''t remember the details (except that you did
ask me
> to review it, and I did, but I didn''t send any details back).
>    
Ah, yeah, something wrong with the /dev/evtchn driver.  Ah, I forgot to 
merge in xen/dev-evtchn into xen/next; try that and see what happens.  
(I''ll test it too, but it may have to wait for tomorrow.)

     J


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel