* MSI causing softpanics in guest
@ 2008-09-19 19:53 Anish Bhatt
2008-09-20 8:15 ` Keir Fraser
0 siblings, 1 reply; 20+ messages in thread
From: Anish Bhatt @ 2008-09-19 19:53 UTC (permalink / raw)
To: xen-devel; +Cc: haitao.shan
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: MSI causing softpanics in guest 2008-09-19 19:53 MSI causing softpanics in guest Anish Bhatt @ 2008-09-20 8:15 ` Keir Fraser [not found] ` <48D52FE7.7050207@gatech.edu> 2008-09-22 8:12 ` Jan Beulich 0 siblings, 2 replies; 20+ messages in thread From: Keir Fraser @ 2008-09-20 8:15 UTC (permalink / raw) To: Anish Bhatt, xen-devel; +Cc: haitao.shan 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. :-) -- Keir On 19/9/08 20:53, "Anish Bhatt" <anish@cc.gatech.edu> 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <48D52FE7.7050207@gatech.edu>]
* RE: MSI causing softpanics in guest [not found] ` <48D52FE7.7050207@gatech.edu> @ 2008-09-21 14:23 ` Shan, Haitao [not found] ` <48D6968A.4050502@gatech.edu> 0 siblings, 1 reply; 20+ messages in thread From: Shan, Haitao @ 2008-09-21 14:23 UTC (permalink / raw) To: Anish Bhatt, Keir Fraser; +Cc: Jan, xen-devel@lists.xensource.com Are you using MSI or MSI-X? I remember there are some bugfixes related to MSI-X recently. What are the changsets you are using for xen and PV kernel? Shan Haitao -----Original Message----- From: Anish Bhatt [mailto:anish@gatech.edu] Sent: 2008年9月21日 1:16 To: Keir Fraser Cc: xen-devel@lists.xensource.com; Shan, Haitao; Jan Beulich Subject: Re: [Xen-devel] MSI causing softpanics in guest I have put msi=1 in grub in 3.3 & unstable, don't know why its still not working though.. -anish Keir Fraser wrote: > 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. :-) > > -- Keir > > On 19/9/08 20:53, "Anish Bhatt" <anish@cc.gatech.edu> 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <48D6968A.4050502@gatech.edu>]
* RE: MSI causing softpanics in guest [not found] ` <48D6968A.4050502@gatech.edu> @ 2008-09-22 1:41 ` Shan, Haitao 0 siblings, 0 replies; 20+ messages in thread From: Shan, Haitao @ 2008-09-22 1:41 UTC (permalink / raw) To: Anish Bhatt; +Cc: xen-devel@lists.xensource.com, Keir Fraser Seems it is not possible to trigger this bug_on, although I do not quite understand this part of code. I think you have invoked pci_enable_msi before request_irq, right? Does pci_enable_msi return correctly? Shan Haitao -----Original Message----- From: Anish Bhatt [mailto:anish@gatech.edu] Sent: 2008年9月22日 2:47 To: Shan, Haitao Cc: Keir Fraser; xen-devel@lists.xensource.com; Jan Beulich Subject: Re: [Xen-devel] MSI causing softpanics in guest I'm using MSI. I'm using the same 2.6.18 kernel for xen & PV, changeset is as follows : (XEN) Latest ChangeSet: Wed Sep 17 14:16:02 2008 +0100 18510:694b7daa353c -Anish Shan, Haitao wrote: > Are you using MSI or MSI-X? > I remember there are some bugfixes related to MSI-X recently. What are the changsets you are using for xen and PV kernel? > > Shan Haitao > > -----Original Message----- > From: Anish Bhatt [mailto:anish@gatech.edu] > Sent: 2008年9月21日 1:16 > To: Keir Fraser > Cc: xen-devel@lists.xensource.com; Shan, Haitao; Jan Beulich > Subject: Re: [Xen-devel] MSI causing softpanics in guest > > I have put msi=1 in grub in 3.3 & unstable, don't know why its still not > working though.. > -anish > > Keir Fraser wrote: >> 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. :-) >> >> -- Keir >> >> On 19/9/08 20:53, "Anish Bhatt" <anish@cc.gatech.edu> 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. > -- As long as the music's loud enough, we won't hear the world falling apart. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MSI causing softpanics in guest 2008-09-20 8:15 ` Keir Fraser [not found] ` <48D52FE7.7050207@gatech.edu> @ 2008-09-22 8:12 ` Jan Beulich [not found] ` <48D878CB.6060404@gatech.edu> 1 sibling, 1 reply; 20+ messages in thread From: Jan Beulich @ 2008-09-22 8:12 UTC (permalink / raw) To: Anish Bhatt, Keir Fraser; +Cc: xen-devel, haitao.shan >>> Keir Fraser <keir.fraser@eu.citrix.com> 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@cc.gatech.edu> 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <48D878CB.6060404@gatech.edu>]
* Re: MSI causing softpanics in guest [not found] ` <48D878CB.6060404@gatech.edu> @ 2008-09-23 7:23 ` Jan Beulich 2008-09-23 7:50 ` Shan, Haitao 0 siblings, 1 reply; 20+ messages in thread From: Jan Beulich @ 2008-09-23 7:23 UTC (permalink / raw) To: Anish Bhatt; +Cc: xen-devel, haitao.shan, Keir Fraser So the question is what irq you pass in to request_irq() and where you got it from. Jan >>> Anish Bhatt <anish@gatech.edu> 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@eu.citrix.com> 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@cc.gatech.edu> 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: MSI causing softpanics in guest 2008-09-23 7:23 ` Jan Beulich @ 2008-09-23 7:50 ` Shan, Haitao 2008-09-23 8:14 ` Keir Fraser 2008-09-24 0:07 ` Anish Bhatt 0 siblings, 2 replies; 20+ messages in thread From: Shan, Haitao @ 2008-09-23 7:50 UTC (permalink / raw) To: Jan Beulich, Anish Bhatt; +Cc: xen-devel@lists.xensource.com, Keir Fraser 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@novell.com] Sent: 2008年9月23日 15:24 To: Anish Bhatt Cc: Keir Fraser; Shan, Haitao; xen-devel@lists.xensource.com 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@gatech.edu> 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@eu.citrix.com> 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@cc.gatech.edu> 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MSI causing softpanics in guest 2008-09-23 7:50 ` Shan, Haitao @ 2008-09-23 8:14 ` Keir Fraser 2008-09-23 8:26 ` Shan, Haitao 2008-09-24 0:07 ` Anish Bhatt 1 sibling, 1 reply; 20+ messages in thread From: Keir Fraser @ 2008-09-23 8:14 UTC (permalink / raw) To: Shan, Haitao, Jan Beulich, Anish Bhatt; +Cc: xen-devel@lists.xensource.com On 23/9/08 08:50, "Shan, Haitao" <haitao.shan@intel.com> 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? Yes, actually I remember thinking there should be a hook for Jan's patch into pcifront, but then forgot about it. When pcifront gets back a pirq from pciback, it should evtchn_map_pirq(), right? -- Keir ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: MSI causing softpanics in guest 2008-09-23 8:14 ` Keir Fraser @ 2008-09-23 8:26 ` Shan, Haitao 2008-09-23 8:30 ` Keir Fraser 0 siblings, 1 reply; 20+ messages in thread From: Shan, Haitao @ 2008-09-23 8:26 UTC (permalink / raw) To: Keir Fraser, Jan Beulich, Anish Bhatt; +Cc: xen-devel@lists.xensource.com Yes. I think so. But here is another problem, current code in dom0 returns irq number (irq number has meaning only in its domain, am I right?) not pirq number to PV domU guest. I am not sure whether this number can be used in evtchn_map_pirq in PV domU. Seems some modification is needed, I believe. Shan Haitao -----Original Message----- From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Sent: 2008年9月23日 16:15 To: Shan, Haitao; Jan Beulich; Anish Bhatt Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] MSI causing softpanics in guest On 23/9/08 08:50, "Shan, Haitao" <haitao.shan@intel.com> 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? Yes, actually I remember thinking there should be a hook for Jan's patch into pcifront, but then forgot about it. When pcifront gets back a pirq from pciback, it should evtchn_map_pirq(), right? -- Keir ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MSI causing softpanics in guest 2008-09-23 8:26 ` Shan, Haitao @ 2008-09-23 8:30 ` Keir Fraser 2008-09-23 8:33 ` Shan, Haitao 0 siblings, 1 reply; 20+ messages in thread From: Keir Fraser @ 2008-09-23 8:30 UTC (permalink / raw) To: Shan, Haitao, Jan Beulich, Anish Bhatt; +Cc: xen-devel@lists.xensource.com pciback should be returning the number which the domU should present to Xen via EVTCHNOP_bind_pirq. Anything else would be meaningless. DomU then gets itself a Linux irq by 'irq = evtchn_map_pirq(-1, pirq_from_pciback)'. -- Keir On 23/9/08 09:26, "Shan, Haitao" <haitao.shan@intel.com> wrote: > Yes. I think so. > But here is another problem, current code in dom0 returns irq number (irq > number has meaning only in its domain, am I right?) not pirq number to PV domU > guest. I am not sure whether this number can be used in evtchn_map_pirq in PV > domU. Seems some modification is needed, I believe. ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: MSI causing softpanics in guest 2008-09-23 8:30 ` Keir Fraser @ 2008-09-23 8:33 ` Shan, Haitao 0 siblings, 0 replies; 20+ messages in thread From: Shan, Haitao @ 2008-09-23 8:33 UTC (permalink / raw) To: Keir Fraser, Jan Beulich, Anish Bhatt; +Cc: xen-devel@lists.xensource.com Yes, exactly the same as what I am thinking. Shan Haitao -----Original Message----- From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Sent: 2008年9月23日 16:30 To: Shan, Haitao; Jan Beulich; Anish Bhatt Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] MSI causing softpanics in guest pciback should be returning the number which the domU should present to Xen via EVTCHNOP_bind_pirq. Anything else would be meaningless. DomU then gets itself a Linux irq by 'irq = evtchn_map_pirq(-1, pirq_from_pciback)'. -- Keir On 23/9/08 09:26, "Shan, Haitao" <haitao.shan@intel.com> wrote: > Yes. I think so. > But here is another problem, current code in dom0 returns irq number (irq > number has meaning only in its domain, am I right?) not pirq number to PV domU > guest. I am not sure whether this number can be used in evtchn_map_pirq in PV > domU. Seems some modification is needed, I believe. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MSI causing softpanics in guest 2008-09-23 7:50 ` Shan, Haitao 2008-09-23 8:14 ` Keir Fraser @ 2008-09-24 0:07 ` Anish Bhatt 2008-09-24 1:24 ` Shan, Haitao 1 sibling, 1 reply; 20+ messages in thread From: Anish Bhatt @ 2008-09-24 0:07 UTC (permalink / raw) To: Shan, Haitao; +Cc: xen-devel@lists.xensource.com, Keir Fraser 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@novell.com] > Sent: 2008年9月23日 15:24 > To: Anish Bhatt > Cc: Keir Fraser; Shan, Haitao; xen-devel@lists.xensource.com > 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@gatech.edu> 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@eu.citrix.com> 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@cc.gatech.edu> 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@lists.xensource.com > http://lists.xensource.com/xen-devel > -- As long as the music's loud enough, we won't hear the world falling apart. ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: MSI causing softpanics in guest 2008-09-24 0:07 ` Anish Bhatt @ 2008-09-24 1:24 ` Shan, Haitao 2008-09-24 6:04 ` Keir Fraser 2008-09-27 2:41 ` Anish Bhatt 0 siblings, 2 replies; 20+ messages in thread From: Shan, Haitao @ 2008-09-24 1:24 UTC (permalink / raw) To: Anish Bhatt; +Cc: xen-devel@lists.xensource.com, Keir Fraser 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@cc.gatech.edu] Sent: 2008年9月24日 8:08 To: Shan, Haitao Cc: Jan Beulich; xen-devel@lists.xensource.com; 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@novell.com] > Sent: 2008年9月23日 15:24 > To: Anish Bhatt > Cc: Keir Fraser; Shan, Haitao; xen-devel@lists.xensource.com > 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@gatech.edu> 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@eu.citrix.com> 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@cc.gatech.edu> 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@lists.xensource.com > http://lists.xensource.com/xen-devel > -- As long as the music's loud enough, we won't hear the world falling apart. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MSI causing softpanics in guest 2008-09-24 1:24 ` Shan, Haitao @ 2008-09-24 6:04 ` Keir Fraser 2008-09-24 6:28 ` Shan, Haitao 2008-09-24 9:38 ` Shan, Haitao 2008-09-27 2:41 ` Anish Bhatt 1 sibling, 2 replies; 20+ messages in thread From: Keir Fraser @ 2008-09-24 6:04 UTC (permalink / raw) To: Shan, Haitao, Anish Bhatt; +Cc: xen-devel@lists.xensource.com So, which of us is going to patch pcifront? :-) -- Keir On 24/9/08 02:24, "Shan, Haitao" <haitao.shan@intel.com> 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@cc.gatech.edu] > Sent: 2008年9月24日 8:08 > To: Shan, Haitao > Cc: Jan Beulich; xen-devel@lists.xensource.com; 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@novell.com] >> Sent: 2008年9月23日 15:24 >> To: Anish Bhatt >> Cc: Keir Fraser; Shan, Haitao; xen-devel@lists.xensource.com >> 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@gatech.edu> 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@eu.citrix.com> 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@cc.gatech.edu> 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:8 >>> 09> >>> ! >>> >>> >>>> 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:8 >>> 09> >>> ! >>> >>> >>>> 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@lists.xensource.com >> http://lists.xensource.com/xen-devel >> > > > -- > As long as the music's loud enough, we won't hear the world falling apart. > ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: MSI causing softpanics in guest 2008-09-24 6:04 ` Keir Fraser @ 2008-09-24 6:28 ` Shan, Haitao 2008-09-24 9:38 ` Shan, Haitao 1 sibling, 0 replies; 20+ messages in thread From: Shan, Haitao @ 2008-09-24 6:28 UTC (permalink / raw) To: Keir Fraser, Anish Bhatt; +Cc: xen-devel@lists.xensource.com OK. Let me take this AR. :) I will cook a patch for that. Shan Haitao -----Original Message----- From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Sent: 2008年9月24日 14:05 To: Shan, Haitao; Anish Bhatt Cc: Jan Beulich; xen-devel@lists.xensource.com Subject: Re: [Xen-devel] MSI causing softpanics in guest So, which of us is going to patch pcifront? :-) -- Keir On 24/9/08 02:24, "Shan, Haitao" <haitao.shan@intel.com> 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@cc.gatech.edu] > Sent: 2008年9月24日 8:08 > To: Shan, Haitao > Cc: Jan Beulich; xen-devel@lists.xensource.com; 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@novell.com] >> Sent: 2008年9月23日 15:24 >> To: Anish Bhatt >> Cc: Keir Fraser; Shan, Haitao; xen-devel@lists.xensource.com >> 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@gatech.edu> 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@eu.citrix.com> 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@cc.gatech.edu> 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:8 >>> 09> >>> ! >>> >>> >>>> 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:8 >>> 09> >>> ! >>> >>> >>>> 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@lists.xensource.com >> http://lists.xensource.com/xen-devel >> > > > -- > As long as the music's loud enough, we won't hear the world falling apart. > ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: MSI causing softpanics in guest 2008-09-24 6:04 ` Keir Fraser 2008-09-24 6:28 ` Shan, Haitao @ 2008-09-24 9:38 ` Shan, Haitao 2008-09-24 10:30 ` Keir Fraser 2008-09-24 10:59 ` Jan Beulich 1 sibling, 2 replies; 20+ messages in thread From: Shan, Haitao @ 2008-09-24 9:38 UTC (permalink / raw) To: Keir Fraser, Anish Bhatt; +Cc: xen-devel@lists.xensource.com [-- Attachment #1: Type: text/plain, Size: 8960 bytes --] Hi, Keir, This is an RFC patch, which is not tested now (It will cost some time to setup my test environments). I want to ensure I am on the same page with you. So could you pleas have a look and point to me which part I may be missing? Thanks! Shan Haitao -----Original Message----- From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Sent: 2008年9月24日 14:05 To: Shan, Haitao; Anish Bhatt Cc: Jan Beulich; xen-devel@lists.xensource.com Subject: Re: [Xen-devel] MSI causing softpanics in guest So, which of us is going to patch pcifront? :-) -- Keir On 24/9/08 02:24, "Shan, Haitao" <haitao.shan@intel.com> 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@cc.gatech.edu] > Sent: 2008年9月24日 8:08 > To: Shan, Haitao > Cc: Jan Beulich; xen-devel@lists.xensource.com; 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@novell.com] >> Sent: 2008年9月23日 15:24 >> To: Anish Bhatt >> Cc: Keir Fraser; Shan, Haitao; xen-devel@lists.xensource.com >> 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@gatech.edu> 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@eu.citrix.com> 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@cc.gatech.edu> 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:8 >>> 09> >>> ! >>> >>> >>>> 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:8 >>> 09> >>> ! >>> >>> >>>> 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@lists.xensource.com >> http://lists.xensource.com/xen-devel >> > > > -- > As long as the music's loud enough, we won't hear the world falling apart. > [-- Attachment #2: fixup_translate_xen_pirqs.patch --] [-- Type: application/octet-stream, Size: 3462 bytes --] diff -r 916aae9cc11a drivers/pci/msi-xen.c --- a/drivers/pci/msi-xen.c Mon Sep 22 16:08:10 2008 +0100 +++ b/drivers/pci/msi-xen.c Wed Sep 24 01:45:16 2008 +0800 @@ -158,7 +158,11 @@ static int msi_unmap_pirq(struct pci_dev int rc; unmap.domid = msi_get_dev_owner(dev); - unmap.pirq = evtchn_get_xen_pirq(pirq); + /* See comments in msi_map_pirq_to_vector, input parameter pirq + * mean irq number only if the device belongs to dom0 itself. + */ + if (unmap.domid == DOMID_SELF) + unmap.pirq = evtchn_get_xen_pirq(pirq); if ((rc = HYPERVISOR_physdev_op(PHYSDEVOP_unmap_pirq, &unmap))) printk(KERN_WARNING "unmap irq %x failed\n", pirq); @@ -166,7 +170,9 @@ static int msi_unmap_pirq(struct pci_dev if (rc < 0) return rc; - evtchn_map_pirq(pirq, 0); + if (unmap.domid == DOMID_SELF) + evtchn_map_pirq(pirq, 0); + return 0; } @@ -217,7 +223,15 @@ static int msi_map_pirq_to_vector(struct return -ENOSYS; BUG_ON(map_irq.pirq <= 0); - return evtchn_map_pirq(pirq, map_irq.pirq); + + /* If mapping of this perticuliar MSI is on behalf of another domain, + We do not need to get an irq in dom0. This also implies: + dev->irq in dom0 will be recording pirq number if this device belongs + to another domain, or will be irq number if this device belongs to + dom0. + */ + return (domid == DOMID_SELF)? + map_irq.pirq : evtchn_map_pirq(pirq, map_irq.pirq); } static int msi_map_vector(struct pci_dev *dev, int entry_nr, u64 table_base) @@ -520,6 +534,7 @@ int pci_enable_msi(struct pci_dev* dev) if (ret) return ret; + dev->irq = evtchn_map_pirq(-1, dev->irq); dev->irq_old = temp; return ret; @@ -563,6 +578,7 @@ void pci_disable_msi(struct pci_dev* dev #ifdef CONFIG_XEN_PCIDEV_FRONTEND if (!is_initial_xendomain()) { + evtchn_map_pirq(dev->irq, 0); pci_frontend_disable_msi(dev); dev->irq = dev->irq_old; return; @@ -618,7 +634,9 @@ int pci_enable_msix(struct pci_dev* dev, #ifdef CONFIG_XEN_PCIDEV_FRONTEND if (!is_initial_xendomain()) { - int ret; + struct msi_dev_list *msi_dev_entry; + struct msi_pirq_entry *pirq_entry; + int ret, irq; ret = pci_frontend_enable_msix(dev, entries, nvec); if (ret) { @@ -626,6 +644,26 @@ int pci_enable_msix(struct pci_dev* dev, return ret; } + msi_dev_entry = get_msi_dev_pirq_list(dev); + for (i = 0; i < nvec; i++) { + int mapped = 0; + + list_for_each_entry(pirq_entry, + &msi_dev_entry->pirq_list_head, list) { + if (pirq_entry->entry_nr == entries[i].entry) { + irq = pirq_entry->pirq; + BUG_ON(entries[i].vector != evtchn_get_xen_pirq(irq)); + entries[i].vector = irq; + mapped = 1; + break; + } + } + if (mapped) + continue; + irq = evtchn_map_pirq(-1, entries[i].vector); + attach_pirq_entry(irq, entries[i].entry, msi_dev_entry); + entries[i].vector = irq; + } return 0; } #endif @@ -687,7 +725,19 @@ void pci_disable_msix(struct pci_dev* de #ifdef CONFIG_XEN_PCIDEV_FRONTEND if (!is_initial_xendomain()) { + struct msi_dev_list *msi_dev_entry; + struct msi_pirq_entry *pirq_entry, *tmp; + pci_frontend_disable_msix(dev); + + msi_dev_entry = get_msi_dev_pirq_list(dev); + list_for_each_entry_safe(pirq_entry, tmp, + &msi_dev_entry->pirq_list_head, list) { + evtchn_map_pirq(pirq_entry->pirq, 0); + list_del(&pirq_entry->list); + kfree(pirq_entry); + } + dev->irq = dev->irq_old; return; } [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MSI causing softpanics in guest 2008-09-24 9:38 ` Shan, Haitao @ 2008-09-24 10:30 ` Keir Fraser 2008-09-24 10:59 ` Jan Beulich 1 sibling, 0 replies; 20+ messages in thread From: Keir Fraser @ 2008-09-24 10:30 UTC (permalink / raw) To: Shan, Haitao, Anish Bhatt; +Cc: xen-devel@lists.xensource.com Yes, it's a better job than I could have managed. -- Keir On 24/9/08 10:38, "Shan, Haitao" <haitao.shan@intel.com> wrote: > Hi, Keir, > > This is an RFC patch, which is not tested now (It will cost some time to setup > my test environments). I want to ensure I am on the same page with you. So > could you pleas have a look and point to me which part I may be missing? > Thanks! > > Shan Haitao > > -----Original Message----- > From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] > Sent: 2008年9月24日 14:05 > To: Shan, Haitao; Anish Bhatt > Cc: Jan Beulich; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] MSI causing softpanics in guest > > So, which of us is going to patch pcifront? :-) > > -- Keir > > On 24/9/08 02:24, "Shan, Haitao" <haitao.shan@intel.com> 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@cc.gatech.edu] >> Sent: 2008年9月24日 8:08 >> To: Shan, Haitao >> Cc: Jan Beulich; xen-devel@lists.xensource.com; 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@novell.com] >>> Sent: 2008年9月23日 15:24 >>> To: Anish Bhatt >>> Cc: Keir Fraser; Shan, Haitao; xen-devel@lists.xensource.com >>> 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@gatech.edu> 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@eu.citrix.com> 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@cc.gatech.edu> 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:>>>> 8 >>>> 09> >>>> ! >>>> >>>> >>>>> 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:>>>> 8 >>>> 09> >>>> ! >>>> >>>> >>>>> 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@lists.xensource.com >>> http://lists.xensource.com/xen-devel >>> >> >> >> -- >> As long as the music's loud enough, we won't hear the world falling apart. >> > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: MSI causing softpanics in guest 2008-09-24 9:38 ` Shan, Haitao 2008-09-24 10:30 ` Keir Fraser @ 2008-09-24 10:59 ` Jan Beulich 1 sibling, 0 replies; 20+ messages in thread From: Jan Beulich @ 2008-09-24 10:59 UTC (permalink / raw) To: Haitao Shan; +Cc: Anish Bhatt, xen-devel@lists.xensource.com, Keir Fraser >--- a/drivers/pci/msi-xen.c Mon Sep 22 16:08:10 2008 +0100 >+++ b/drivers/pci/msi-xen.c Wed Sep 24 01:45:16 2008 +0800 >@@ -158,7 +158,11 @@ static int msi_unmap_pirq(struct pci_dev > int rc; > > unmap.domid = msi_get_dev_owner(dev); >- unmap.pirq = evtchn_get_xen_pirq(pirq); >+ /* See comments in msi_map_pirq_to_vector, input parameter pirq >+ * mean irq number only if the device belongs to dom0 itself. >+ */ >+ if (unmap.domid == DOMID_SELF) >+ unmap.pirq = evtchn_get_xen_pirq(pirq); This seems to leave unmap.pirq uninitialized in the !DOMID_SELF case. Otherwise, seems a reasonable alternative to doing it in pcifront/pciback. Jan ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MSI causing softpanics in guest 2008-09-24 1:24 ` Shan, Haitao 2008-09-24 6:04 ` Keir Fraser @ 2008-09-27 2:41 ` Anish Bhatt 2008-09-27 3:33 ` Keir Fraser 1 sibling, 1 reply; 20+ messages in thread From: Anish Bhatt @ 2008-09-27 2:41 UTC (permalink / raw) To: Shan, Haitao; +Cc: xen-devel@lists.xensource.com, Keir Fraser 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@cc.gatech.edu] > Sent: 2008年9月24日 8:08 > To: Shan, Haitao > Cc: Jan Beulich; xen-devel@lists.xensource.com; 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@novell.com] >> Sent: 2008年9月23日 15:24 >> To: Anish Bhatt >> Cc: Keir Fraser; Shan, Haitao; xen-devel@lists.xensource.com >> 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@gatech.edu> 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@eu.citrix.com> 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@cc.gatech.edu> 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@lists.xensource.com >> http://lists.xensource.com/xen-devel >> >> > > > -- > As long as the music's loud enough, we won't hear the world falling apart. > > -- As long as the music's loud enough, we won't hear the world falling apart. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: MSI causing softpanics in guest 2008-09-27 2:41 ` Anish Bhatt @ 2008-09-27 3:33 ` Keir Fraser 0 siblings, 0 replies; 20+ messages in thread From: Keir Fraser @ 2008-09-27 3:33 UTC (permalink / raw) To: Anish Bhatt, Shan, Haitao; +Cc: xen-devel@lists.xensource.com 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@cc.gatech.edu> 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@cc.gatech.edu] >> Sent: 2008年9月24日 8:08 >> To: Shan, Haitao >> Cc: Jan Beulich; xen-devel@lists.xensource.com; 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@novell.com] >>> Sent: 2008年9月23日 15:24 >>> To: Anish Bhatt >>> Cc: Keir Fraser; Shan, Haitao; xen-devel@lists.xensource.com >>> 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@gatech.edu> 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@eu.citrix.com> 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@cc.gatech.edu> 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@lists.xensource.com >>> http://lists.xensource.com/xen-devel >>> >>> >> >> >> -- >> As long as the music's loud enough, we won't hear the world falling apart. >> >> > ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2008-09-27 3:33 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-09-19 19:53 MSI causing softpanics in guest Anish Bhatt
2008-09-20 8:15 ` Keir Fraser
[not found] ` <48D52FE7.7050207@gatech.edu>
2008-09-21 14:23 ` Shan, Haitao
[not found] ` <48D6968A.4050502@gatech.edu>
2008-09-22 1:41 ` Shan, Haitao
2008-09-22 8:12 ` Jan Beulich
[not found] ` <48D878CB.6060404@gatech.edu>
2008-09-23 7:23 ` Jan Beulich
2008-09-23 7:50 ` Shan, Haitao
2008-09-23 8:14 ` Keir Fraser
2008-09-23 8:26 ` Shan, Haitao
2008-09-23 8:30 ` Keir Fraser
2008-09-23 8:33 ` Shan, Haitao
2008-09-24 0:07 ` Anish Bhatt
2008-09-24 1:24 ` Shan, Haitao
2008-09-24 6:04 ` Keir Fraser
2008-09-24 6:28 ` Shan, Haitao
2008-09-24 9:38 ` Shan, Haitao
2008-09-24 10:30 ` Keir Fraser
2008-09-24 10:59 ` Jan Beulich
2008-09-27 2:41 ` Anish Bhatt
2008-09-27 3:33 ` Keir Fraser
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.