Thank you for all your help Jan && Roger.
I think we can settle on this thread now.
After disabling the debug build, the gfx-passthrough back to work now.
On Mon, Feb 20, 2017 at 12:38 PM, G.R. wrote:
>>Feb 10, 2017 02:00，"Roger Pau Monné" wrote:
>>
>>On Thu, Feb 09, 2017 at 07:58:56AM -0700, Ja
>Feb 10, 2017 02:00，"Roger Pau Monné" wrote:
>
>On Thu, Feb 09, 2017 at 07:58:56AM -0700, Jan Beulich wrote:
>> >>> On 09.02.17 at 15:46, wrote:
>> > BTW -- I think that fix should not be conflicting with your debug change,
>> > right?
>>
>> Yes - ideally you'd keep that one in place along with a
On Thu, Feb 09, 2017 at 07:58:56AM -0700, Jan Beulich wrote:
> >>> On 09.02.17 at 15:46, wrote:
> > BTW -- I think that fix should not be conflicting with your debug change,
> > right?
>
> Yes - ideally you'd keep that one in place along with adding Roger's
> patch.
Please use the patch below,
>>> On 09.02.17 at 15:46, wrote:
> BTW -- I think that fix should not be conflicting with your debug change,
> right?
Yes - ideally you'd keep that one in place along with adding Roger's
patch.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
On Wed, Feb 8, 2017 at 11:59 PM, Jan Beulich wrote:
On 08.02.17 at 15:56, wrote:
>> On Wed, Feb 8, 2017 at 10:29 PM, G.R.
>> wrote:
>>> On Wed, Feb 8, 2017 at 8:44 PM, Jan Beulich wrote:
>>> On 07.02.17 at 16:44, wrote:
> On Mon, Feb 6, 2017 at 8:40 PM, Jan Beulich wrote:
>>
>>> On 08.02.17 at 15:56, wrote:
> On Wed, Feb 8, 2017 at 10:29 PM, G.R.
> wrote:
>> On Wed, Feb 8, 2017 at 8:44 PM, Jan Beulich wrote:
>> On 07.02.17 at 16:44, wrote:
On Mon, Feb 6, 2017 at 8:40 PM, Jan Beulich wrote:
On 05.02.17 at 06:51, wrote:
>> I finally get some
On Wed, Feb 8, 2017 at 10:29 PM, G.R. wrote:
> On Wed, Feb 8, 2017 at 8:44 PM, Jan Beulich wrote:
> On 07.02.17 at 16:44, wrote:
>>> On Mon, Feb 6, 2017 at 8:40 PM, Jan Beulich wrote:
>>> On 05.02.17 at 06:51, wrote:
> I finally get some spare time to collect the debug info.
>
On Wed, Feb 8, 2017 at 8:44 PM, Jan Beulich wrote:
On 07.02.17 at 16:44, wrote:
>> On Mon, Feb 6, 2017 at 8:40 PM, Jan Beulich wrote:
>> On 05.02.17 at 06:51, wrote:
I finally get some spare time to collect the debug info.
>>>
>>> As I continue to be puzzled, best I could come up
>>> On 07.02.17 at 16:44, wrote:
> On Mon, Feb 6, 2017 at 8:40 PM, Jan Beulich wrote:
> On 05.02.17 at 06:51, wrote:
>>> I finally get some spare time to collect the debug info.
>>
>> As I continue to be puzzled, best I could come up with is an
>> extension to the debug patch. Please use the
>>> On 07.02.17 at 16:44, wrote:
> On Mon, Feb 6, 2017 at 8:40 PM, Jan Beulich wrote:
> On 05.02.17 at 06:51, wrote:
>>> I finally get some spare time to collect the debug info.
>>
>> As I continue to be puzzled, best I could come up with is an
>> extension to the debug patch. Please use the
>>> On 07.02.17 at 16:44, wrote:
> On Mon, Feb 6, 2017 at 8:40 PM, Jan Beulich wrote:
> On 05.02.17 at 06:51, wrote:
>>> I finally get some spare time to collect the debug info.
>>
>> As I continue to be puzzled, best I could come up with is an
>> extension to the debug patch. Please use the
On Mon, Feb 6, 2017 at 8:40 PM, Jan Beulich wrote:
On 05.02.17 at 06:51, wrote:
>> I finally get some spare time to collect the debug info.
>
> As I continue to be puzzled, best I could come up with is an
> extension to the debug patch. Please use the attached one
> in place of the earlier o
>>> On 07.02.17 at 03:12, wrote:
> On Mon, Feb 6, 2017 at 7:43 PM, Jan Beulich wrote:
> On 05.02.17 at 06:51, wrote:
>>> Please find the full log in the attachment.
>>
>> Sadly that one is only a partial log again. I'd really need to see the
>> boot messages too, in particular to (hopefully)
On Mon, Feb 6, 2017 at 7:43 PM, Jan Beulich wrote:
On 05.02.17 at 06:51, wrote:
>> Please find the full log in the attachment.
>
> Sadly that one is only a partial log again. I'd really need to see the
> boot messages too, in particular to (hopefully) be able to judge
> whether your system u
>>> On 05.02.17 at 06:51, wrote:
> I finally get some spare time to collect the debug info.
As I continue to be puzzled, best I could come up with is an
extension to the debug patch. Please use the attached one
in place of the earlier one, ideally on top of
https://lists.xenproject.org/archives/h
>>> On 05.02.17 at 06:51, wrote:
> Please find the full log in the attachment.
Sadly that one is only a partial log again. I'd really need to see the
boot messages too, in particular to (hopefully) be able to judge
whether your system uses shared or separate EPT and VT-d tables.
Jan
__
On Mon, Feb 6, 2017 at 3:40 PM, Jan Beulich wrote:
On 05.02.17 at 08:18, wrote:
>> But we didn't see a map error in debug log either.
>
> I'll have to look into this more closely.
Let me know when you need more info / debug log.:-)
BTW, if this helps my hardware setup is based on i7-3770 +
>>> On 05.02.17 at 08:18, wrote:
> On Sun, Feb 5, 2017 at 1:51 PM, G.R. wrote:
>> On Fri, Jan 20, 2017 at 12:30 AM, Jan Beulich wrote:
>> On 17.01.17 at 16:08, wrote:
But fortunately commenting out that line could still reproduce the IOMMU
fault.
I was lucky to capture the fu
On Sun, Feb 5, 2017 at 1:51 PM, G.R. wrote:
> On Fri, Jan 20, 2017 at 12:30 AM, Jan Beulich wrote:
> On 17.01.17 at 16:08, wrote:
>>> But fortunately commenting out that line could still reproduce the IOMMU
>>> fault.
>>> I was lucky to capture the full log before it fills up my 100MB ring b
On Fri, Jan 20, 2017 at 12:30 AM, Jan Beulich wrote:
On 17.01.17 at 16:08, wrote:
>> But fortunately commenting out that line could still reproduce the IOMMU
>> fault.
>> I was lucky to capture the full log before it fills up my 100MB ring buffer
>> (in less than 2 seconds).
>
> So here's a
>>> On 17.01.17 at 16:08, wrote:
> But fortunately commenting out that line could still reproduce the IOMMU
> fault.
> I was lucky to capture the full log before it fills up my 100MB ring buffer
> (in less than 2 seconds).
So here's a first take at a debugging patch. I've tried to limit existing
On Wed, Jan 18, 2017 at 12:34 AM, Jan Beulich wrote:
> >>> On 17.01.17 at 16:08, wrote:
> > I was lucky to capture the full log before it fills up my 100MB ring
> buffer
> > (in less than 2 seconds).
> > Please find the log in the attachment.
>
> Sadly nothing helpful in there; I'm a little puzz
>>> On 17.01.17 at 16:08, wrote:
> I was lucky to capture the full log before it fills up my 100MB ring buffer
> (in less than 2 seconds).
> Please find the log in the attachment.
Sadly nothing helpful in there; I'm a little puzzled though that the
first thing we see is
(XEN) [VT-D]iommu.c:909:
On Tue, Jan 17, 2017 at 8:54 PM, Jan Beulich wrote:
> >>> On 17.01.17 at 11:49, wrote:
> > I was trying to figure out if I followed your instruction properly.
> > My first attempt only resulted in a binary with similar size with my
> > previous one.
> > Probably something went wrong.
> > I put m
>>> On 17.01.17 at 11:49, wrote:
> On Tue, Jan 17, 2017 at 12:11 AM, Jan Beulich wrote:
>
>> >>> On 16.01.17 at 16:15, wrote:
>> > On Mon, Jan 16, 2017 at 9:56 PM, Jan Beulich wrote:
>> >
>> >> For building a debug hypervisor, all you need to do is set
>> >> CONFIG_DEBUG=y in xen/.config. I do
On Tue, Jan 17, 2017 at 12:11 AM, Jan Beulich wrote:
> >>> On 16.01.17 at 16:15, wrote:
> > On Mon, Jan 16, 2017 at 9:56 PM, Jan Beulich wrote:
> >
> >> For building a debug hypervisor, all you need to do is set
> >> CONFIG_DEBUG=y in xen/.config. I don't think there are any
> >> knobs to avoid
>>> On 16.01.17 at 16:21, wrote:
> BTW, before I generate more verbose && complete debug log, just want to
> update that I also see the following in dom0 (without attempting any
> pass-through to the IGD device)
> But this time the log is not flooding at all. Not sure if this is relevant
> to what
>>> On 16.01.17 at 16:15, wrote:
> On Mon, Jan 16, 2017 at 9:56 PM, Jan Beulich wrote:
>
>> >>> On 16.01.17 at 14:43, wrote:
>> > On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich wrote:
>> >> >>> On 16.01.17 at 10:25, wrote:
>> > The fault log itself is really flooding. With a small 4MB ring buff
BTW, before I generate more verbose && complete debug log, just want to
update that I also see the following in dom0 (without attempting any
pass-through to the IGD device)
But this time the log is not flooding at all. Not sure if this is relevant
to what I see from the domU with pci pass-through.
On Mon, Jan 16, 2017 at 9:56 PM, Jan Beulich wrote:
> >>> On 16.01.17 at 14:43, wrote:
> > On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich wrote:
> >> >>> On 16.01.17 at 10:25, wrote:
> > The fault log itself is really flooding. With a small 4MB ring buffer, I
> > wasn't able to capture how it be
On Mon, Jan 16, 2017 at 1:43 PM, G.R. wrote:
> On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich wrote:
>>
>> >>> On 16.01.17 at 10:25, wrote:
>> > Here are some relevant logs, please help comment what's going on here
>> > and
>> > what's the next step of diagnose.
>> > It appears that the fault addr
>>> On 16.01.17 at 14:43, wrote:
> On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich wrote:
>> >>> On 16.01.17 at 10:25, wrote:
>> > Here are some relevant logs, please help comment what's going on here and
>> > what's the next step of diagnose.
>> > It appears that the fault address 0xcfxx falls
On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich wrote:
> >>> On 16.01.17 at 10:25, wrote:
> > Here are some relevant logs, please help comment what's going on here and
> > what's the next step of diagnose.
> > It appears that the fault address 0xcfxx falls within the host RMRR
> > region.
>
> M
>>> On 16.01.17 at 10:25, wrote:
> Here are some relevant logs, please help comment what's going on here and
> what's the next step of diagnose.
> It appears that the fault address 0xcfxx falls within the host RMRR
> region.
Might be a problem in the RMRR setup itself, when the guest gets
the
Hi all,
I have a working IGD passthrough setup running for 4 years on XEN 4.3.2.
And it no longer works after I upgraded to XEN4.8.0 yesterday. Really need
suggestions this time.
My previous setup was built upon some local fixes in qemu-xen-traditional
(for vendor specific pci cap).
With the same
35 matches
Mail list logo
