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 T
>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 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:
&g
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:
>>>&
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 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 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 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 Mon, Feb 6, 2017 at 5:33 PM, Pasi Kärkkäinen wrote:
> Hi,
>
> On Sun, Feb 05, 2017 at 04:05:32PM +0800, G.R. wrote:
>> Hi all,
>> dom0pvh=1 is not working well for me with XEN 4.8.0 + linux kernel 4.9.2.
>>
>> The system boots with no obvious issue.
>
Hi all,
dom0pvh=1 is not working well for me with XEN 4.8.0 + linux kernel 4.9.2.
The system boots with no obvious issue.
But many user mode application are suffering from segfault, which
makes the dom0 not useable: The segfault always come from libc-2.24.so
while it works just fine in PV dom0.
I
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
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 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, debug version of hypervisor will cause domU hang if
gfx-passthrough=1 is present (traditional device model).
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 se
t if I should use /nas/src/xen/xen/.config (note the double
'xen').
> I couldn't find obvious debug knob in the gcc command-line, even though
> the
> > build is with -O1.
>
> Nor do I understand this remark.
>
I checked the GCC c
set
On Mon, Jan 16, 2017 at 11:15 PM, G.R.
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,
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 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
x falls within the host RMRR
region.
However, the hvmloader is setting up memory region starting from address
0xe000.
Is the hvmloader memory map relevant here?
Unfortunately the iommu.c does not provide detailed log on the mapping
except a simple 'd2:PCI: map :00:02.0'
Thanks,
G.R.
19 matches
Mail list logo
