Possibly, but the code generating that message has changed in current
xen-unstable.hg, so you might have more luck with that.
-- Keir
On 27/9/08 03:41, "Anish Bhatt" <anish@xxxxxxxxxxxxx> wrote:
>
> Works fine now with your patch, but I still see the '
>
> physdev.c:90:d0 remap pirq fa vector 49 while not unmap' message in dom0 xm
> dmesg. Is that something to be bothered about ?
> -Anish
>
> Shan, Haitao wrote:
>> It is supposed to work on dom0. This is a bug.
>> Please refer to Keir's reply in this mail thread.
>>
>> Shan Haitao
>>
>> -----Original Message-----
>> From: Anish Bhatt [mailto:anish@xxxxxxxxxxxxx]
>> Sent: 2008年9月24日 8:08
>> To: Shan, Haitao
>> Cc: Jan Beulich; xen-devel@xxxxxxxxxxxxxxxxxxx; Keir Fraser
>> Subject: Re: [Xen-devel] MSI causing softpanics in guest
>>
>> No, the bug_on is not triggered in dom0. I also saw the following error
>> message in xm dmesg, :
>> /physdev.c:90:d0 remap pirq fa vector 49 while not unmap/
>> Its part of the code added for MSI, I wonder if its of any significance.
>>
>> -Anish
>>
>> Shan, Haitao wrote:
>>
>>> Just some thoughts on Anish's problem. It seems he reveals a bug in current
>>> code, I think.
>>>
>>> Currently, evnchn_map_pirq is hooked on msi_map_vector
>>> (pci_enable_msi->msi_capability_init->msi_map_vector). Here the pirq type is
>>> set to IRQT_PIRQ. Then request_irq should succeed since pirq type is already
>>> set.
>>>
>>> However, this path only works on the assumption that msi_map_vector and
>>> request_irq are executed in the same domain, to be more specific, dom0.
>>> For PV domU guest, there is no msi_map_vector in its pci_enable_msi ( PV
>>> domU actually asks dom0 to do the msi map, instead. This is a decision made
>>> by Keir and Yunhong long ago. I think it is base on security
>>> considerations). So its irq type is not set correctly (What's more, it
>>> incorrectly sets the dom0's irq type). Then request_irq can trigger this
>>> bug_on().
>>>
>>> Anish, if you use the device in dom0 itself, does it also have this bug_on?
>>>
>>> Keir and Jan,
>>> Do you think this explanation is reasonable for issues Anish met?
>>>
>>> Best Regards
>>> Shan Haitao
>>>
>>> -----Original Message-----
>>> From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx]
>>> Sent: 2008年9月23日 15:24
>>> To: Anish Bhatt
>>> Cc: Keir Fraser; Shan, Haitao; xen-devel@xxxxxxxxxxxxxxxxxxx
>>> Subject: Re: [Xen-devel] MSI causing softpanics in guest
>>>
>>> So the question is what irq you pass in to request_irq() and where you got
>>> it from. Jan
>>>
>>>
>>>
>>>>>> Anish Bhatt <anish@xxxxxxxxxx> 23.09.08 07:04 >>>
>>>>>>
>>>>>>
>>> I put a printk before BUG_ON, Its expecting IRQT_PIRQ, but getting
>>> IRQT_UNBOUND instead.
>>> -Anish
>>>
>>> Jan Beulich wrote:
>>>
>>>
>>>>>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 20.09.08 10:15 >>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> On 3.3.0 you need to specify msi=1 on Xen's command line to enable MSI. In
>>>>> xen-unstable, MSI support is always enabled.
>>>>>
>>>>> I changed a check in evtchn_get_xen_pirq() into a BUG_ON() as it looks to
>>>>> me
>>>>> like it should never trigger. Jan Beulich was the original authour of that
>>>>> function -- cc'ed in case he can indicate whether I've actually broken the
>>>>> function. :-)
>>>>>
>>>>>
>>>>>
>>>> No, I think that BUG_ON() you added is valid. It definitely is in the
>>>> context
>>>> of startup_pirq(). I'd be curious to know what the type of that irq really
>>>> is,
>>>> but that cannot be determined from the backtrace alone. Anish, could you
>>>> perhaps add a simple printk() before the BUG_ON()? Unfortunately the
>>>> driver in question does not appear to be part of the tree, so we can't even
>>>> check what it does prior to calling request_irq()...
>>>>
>>>> -- Keir
>>>>
>>>> On 19/9/08 20:53, "Anish Bhatt" <anish@xxxxxxxxxxxxx> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> lspci shows MSI enabled for PCI device. PCI passthrough works fine.
>>>>> However, as soon as the MSI driver for card is insmodded, kernel panics.
>>>>> This is on xen-unstable. Tried the same with xen-3.3.0 which is
>>>>> supposed to have MSI passthrough, but the same guest shows MSI as
>>>>> disabled.
>>>>> Any else seen this bug, or know of a workaround ?
>>>>>
>>>>> Trace is as follows :
>>>>>
>>>>> ------------[ cut here ]------------
>>>>> kernel BUG at
>>>>>
>>>>>
>>>>>
>>>>>
>>>> /usr/src/xen/xen-unstable.hg/linux-2.6.18-xen.hg/drivers/xen/core/evtchn.c:
>>>> 809>
>>>> !
>>>>
>>>>
>>>>
>>>>> invalid opcode: 0000 [#1]
>>>>> SMP
>>>>> Modules linked in: nfemsg nfdvnet ipv6 binfmt_misc dm_mod nfe usbcore
>>>>> ext3 jbd processor fuse
>>>>> CPU: 0
>>>>> EIP: 0061:[<c02487f5>] Tainted: GF VLI
>>>>> EFLAGS: 00210097 (2.6.18.8-xen #2)
>>>>> EIP is at evtchn_get_xen_pirq+0x35/0x40
>>>>> eax: ffffffff ebx: 00000002 ecx: c0372e60 edx: 00000000
>>>>> esi: c2103560 edi: c03d3080 ebp: 000004f9 esp: ed385dac
>>>>> ds: 007b es: 007b ss: 0069
>>>>> Process modprobe (pid: 2590, ti=ed384000 task=ed7b1100 task.ti=ed384000)
>>>>> Stack: c0248aef 00000000 00000000 00000000 00000000 00000000 00000000
>>>>> 00000000
>>>>> 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>>>>> 00000000
>>>>> 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>>>>> 00000000
>>>>> Call Trace:
>>>>> [<c0248aef>] startup_pirq+0x3f/0x250
>>>>> [<c0150b50>] setup_irq+0x160/0x1b0
>>>>> [<ee0dd270>] nfe_interrupt_handler+0x0/0x30 [nfemsg]
>>>>> [<c0150c43>] request_irq+0xa3/0xc0
>>>>> [<ee02c8ad>] nfemsg_module_init+0x8ad/0x133e [nfemsg]
>>>>> [<c030531b>] cond_resched+0x2b/0x40
>>>>> [<c0305369>] wait_for_completion+0x19/0xf0
>>>>> [<c0142818>] sys_init_module+0x148/0x1b50
>>>>> [<c010595f>] syscall_call+0x7/0xb
>>>>> Code: 00 00 89 d1 d3 e0 85 05 c4 2c 42 c0 74 1a 8b 14 95 c0 c0 44 c0 89
>>>>> d0 c1 e8 1c 83 e8 01 75 0c c1 ea 0c 81 e2 ff ff 00 00 89 d0 c3 <0f> 0b
>>>>> 29 03 a4 f1 32 c0 eb ea 90 83 ec 08 89 74 24 04 89 c6 a1
>>>>> EIP: [<c02487f5>] evtchn_get_xen_pirq+0x35/0x40 SS:ESP 0069:ed385dac
>>>>> ### card [0] start: host progs ###
>>>>> -bash-3.2#
>>>>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>>>> kernel: ------------[ cut here ]------------
>>>>>
>>>>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>>>> kernel: kernel BUG at
>>>>>
>>>>>
>>>>>
>>>>>
>>>> /usr/src/xen/xen-unstable.hg/linux-2.6.18-xen.hg/drivers/xen/core/evtchn.c:
>>>> 809>
>>>> !
>>>>
>>>>
>>>>
>>>>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>>>> kernel: invalid opcode: 0000 [#1]
>>>>>
>>>>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>>>> kernel: SMP
>>>>>
>>>>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>>>> kernel: CPU: 0
>>>>>
>>>>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>>>> kernel: EIP is at evtchn_get_xen_pirq+0x35/0x40
>>>>>
>>>>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>>>> kernel: eax: ffffffff ebx: 00000002 ecx: c0372e60 edx: 00000000
>>>>>
>>>>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>>>> kernel: esi: c2103560 edi: c03d3080 ebp: 000004f9 esp: ed385dac
>>>>>
>>>>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>>>> kernel: ds: 007b es: 007b ss: 0069
>>>>>
>>>>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>>>> kernel: Process modprobe (pid: 2590, ti=ed384000 task=ed7b1100
>>>>> task.ti=ed384000)
>>>>>
>>>>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>>>> kernel: Stack: c0248aef 00000000 00000000 00000000 00000000 00000000
>>>>> 00000000 00000000
>>>>>
>>>>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>>>> kernel: 00000000 00000000 00000000 00000000 00000000 00000000
>>>>> 00000000 00000000
>>>>>
>>>>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>>>> kernel: 00000000 00000000 00000000 00000000 00000000 00000000
>>>>> 00000000 00000000
>>>>>
>>>>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>>>> kernel: Call Trace:
>>>>>
>>>>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>>>> kernel: Code: 00 00 89 d1 d3 e0 85 05 c4 2c 42 c0 74 1a 8b 14 95 c0 c0
>>>>> 44 c0 89 d0 c1 e8 1c 83 e8 01 75 0c c1 ea 0c 81 e2 ff ff 00 00 89 d0 c3
>>>>> <0f> 0b 29 03 a4 f1 32 c0 eb ea 90 83 ec 08 89 74 24 04 89 c6 a1
>>>>>
>>>>> Message from syslogd@drake at Sep 19 15:36:44 ...
>>>>> kernel: EIP: [<c02487f5>] evtchn_get_xen_pirq+0x35/0x40 SS:ESP
>>>>> 0069:ed385dac
>>>>>
>>>>>
>>>>>
>>>>
>>> --
>>> As long as the music's loud enough, we won't hear the world falling apart.
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>> http://lists.xensource.com/xen-devel
>>>
>>>
>>
>>
>> --
>> As long as the music's loud enough, we won't hear the world falling apart.
>>
>>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home