Displaying 20 results from an estimated 110 matches similar to: "Resource map sanity check fails after GRUB "keeps" the gfx mode"
2013 Sep 27
2
Resource map sanity check fails after GRUB "keeps" the gfx mode
On 26/09/13 23:37, Pavel Roskin wrote:
> Hello!
>
> I have spent some time on the issue. I'm not sure it's a nouveau bug.
> I have a fix that changes arch/x86/kernel/sysfb_simplefb.c only.
>
> GRUB actually uses graphic mode on my card. That mode is supported by
> simplefb. However, the resource conflict happens regardless of whether
> simplefb is enabled.
2013 Sep 26
0
Resource map sanity check fails after GRUB "keeps" the gfx mode
Hello!
I have spent some time on the issue. I'm not sure it's a nouveau bug.
I have a fix that changes arch/x86/kernel/sysfb_simplefb.c only.
GRUB actually uses graphic mode on my card. That mode is supported by
simplefb. However, the resource conflict happens regardless of whether
simplefb is enabled. It's sysfb_simplefb that causes it, a completely
different driver.
If GRUB
2013 Sep 17
33
[Bug 69488] New: GF108 (NVC1) GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=69488
Priority: medium
Bug ID: 69488
Assignee: nouveau at lists.freedesktop.org
Summary: GF108 (NVC1) GPU lockup
QA Contact: xorg-team at lists.x.org
Severity: normal
Classification: Unclassified
OS: All
Reporter: vekinn at gmail.com
Hardware: Other
2013 Oct 03
2
Resource map sanity check fails after GRUB "keeps" the gfx mode
Hi Pavel
On Fri, Oct 4, 2013 at 12:10 AM, Pavel Roskin <proski at gnu.org> wrote:
> Hi David,
>
> On Thu, 3 Oct 2013 00:19:56 +0200
> David Herrmann <dh.herrmann at gmail.com> wrote:
>
>> >> And your PCI-BAR adjustment doesn't change
>> >> anything either, sorry.
>> >
>> > I simply tried another approach to pacify the
2013 Oct 02
2
Resource map sanity check fails after GRUB "keeps" the gfx mode
Hi Pavel
On Wed, Oct 2, 2013 at 11:46 PM, Pavel Roskin <proski at gnu.org> wrote:
> On Wed, 2 Oct 2013 16:47:29 +0200
> David Herrmann <dh.herrmann at gmail.com> wrote:
>
>> Thanks for your investigations. I finally sent my patch and put you on
>> CC. Sorry for the delay, but I have mostly catched up with all emails
>> now.
>>
>> This really just
2013 Oct 04
0
Resource map sanity check fails after GRUB "keeps" the gfx mode
On Fri, 4 Oct 2013 01:08:34 +0200
David Herrmann <dh.herrmann at gmail.com> wrote:
> > CONFIG_X86_SYSFB is always defined. I doubt an x86 kernel would
> > compile without it. create_simplefb() is used in
> > arch/x86/kernel/sysfb.c that is compiled unconditionally and that
> > function is defined in arch/x86/kernel/sysfb_simplefb.c that is only
> > compiled
2013 Sep 27
0
Resource map sanity check fails after GRUB "keeps" the gfx mode
On Fri, 27 Sep 2013 10:33:26 +0100
Emil Velikov <emil.l.velikov at gmail.com> wrote:
> FWIW another nvc0 user is experiencing the same/similar issue and the
> patch seems to resolve the problem in his case.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=69488
Good to hear that my patch actually makes more than cosmetic difference
for somebody. My system doesn't hang
2013 Sep 27
2
Resource map sanity check fails after GRUB "keeps" the gfx mode
Hi
On Fri, Sep 27, 2013 at 5:37 PM, Pavel Roskin <proski at gnu.org> wrote:
> On Fri, 27 Sep 2013 10:33:26 +0100
> Emil Velikov <emil.l.velikov at gmail.com> wrote:
>
>> FWIW another nvc0 user is experiencing the same/similar issue and the
>> patch seems to resolve the problem in his case.
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=69488
>
2013 Oct 03
0
Resource map sanity check fails after GRUB "keeps" the gfx mode
Hi David,
On Thu, 3 Oct 2013 00:19:56 +0200
David Herrmann <dh.herrmann at gmail.com> wrote:
> >> And your PCI-BAR adjustment doesn't change
> >> anything either, sorry.
> >
> > I simply tried another approach to pacify the resource checker.
> >
> > However, there is some difference. nvidiafb cannot access the
> > resources if
2008 Feb 29
1
FreeBSD 7.0 + Xen 3.1 + HVM: Success!
Just thought I'd pass along that I have successfully installed FreeBSD 7.0
into a Xen 3.1 HVM. ?This one went as smooth as I expected, considering my
experience with 6.3. ?Haven't done any benchmarking or stress testing or
port installs or anything. ?But so far it's working nicely.
Here's all the info. ?If you'd like to see anything else, let me know.
Host hardware:
?
2019 Feb 19
2
[Bug 109681] New: Nvidia GT710 => nouveau + wayland + swayWM => crash when use acceleration (open Firefox)
https://bugs.freedesktop.org/show_bug.cgi?id=109681
Bug ID: 109681
Summary: Nvidia GT710 => nouveau + wayland + swayWM => crash
when use acceleration (open Firefox)
Product: Mesa
Version: 18.3
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: critical
2014 Mar 31
11
[Bug 76818] New: Xorg EQ overflowing lock up
https://bugs.freedesktop.org/show_bug.cgi?id=76818
Priority: medium
Bug ID: 76818
Assignee: nouveau at lists.freedesktop.org
Summary: Xorg EQ overflowing lock up
QA Contact: xorg-team at lists.x.org
Severity: normal
Classification: Unclassified
OS: All
Reporter: max.snow at 4mation.com.au
2017 Dec 05
0
Libvirt checkout graphics card
Hello, everybody!My guest has two graphics card when it is running, one is GTX960, and other is video card that is created by qemu.But my guest use video card default, and my screen is not light. I try checkout graphics card with vnc or spice, But it is suspend.Could you help me? And may i checkout card in my host system with command? Because my connection with vnc or spice is not stable.This is
2016 Mar 01
3
[REGRESSION] nouveau: 30 second boot hang after commit 2b700825e
Hello,
I am encountering a 30 second hang during boot, in the Xorg process just before
the display manager comes up. I have bisected the problem to the following
commit:
commit 2b700825e7a7702fb862edba1262c98040dc1bf6
Author: Ben Skeggs <bskeggs at redhat.com>
Date: Thu Aug 20 14:54:22 2015 +1000
drm/nouveau/mc: move device irq handling to platform-specific code
The hang only
2011 Nov 05
88
OpenSuse 11 hvm domU: screen resolution up to 640x480
Hello,
I''ve recently installed a hvm domU opensuse 11 guest and I cannot set the screen
resolution higher then 640x480. This seems very strange to me, because
I don''t have
any problem to set higher resolution on a windows 7 domU, using the
following parameters
in the configuration file:
stdvga=1
videoram=16
What could the problem be? Is some video driver missing?
--
Flavio
2011 Nov 05
88
OpenSuse 11 hvm domU: screen resolution up to 640x480
Hello,
I''ve recently installed a hvm domU opensuse 11 guest and I cannot set the screen
resolution higher then 640x480. This seems very strange to me, because
I don''t have
any problem to set higher resolution on a windows 7 domU, using the
following parameters
in the configuration file:
stdvga=1
videoram=16
What could the problem be? Is some video driver missing?
--
Flavio
2012 Sep 12
2
[Bug 54830] New: Display is shifted to right (ASUS VS197)
https://bugs.freedesktop.org/show_bug.cgi?id=54830
Bug #: 54830
Summary: Display is shifted to right (ASUS VS197)
Classification: Unclassified
Product: xorg
Version: 7.7 (2011)
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: minor
Priority: medium
Component:
2008 Jun 30
0
FreeBSD 7.0 + Xen 3.1 + HVM: Success!
Kip,
Does the problem with Xen 3.1 in HVM/Intel manifest as those BTX halted
errors (e.g.
http://lists.xensource.com/archives/html/xen-users/2006-10/msg00014.html) ?
If so, do you happen to know whether this problem has been solved in Xen
3.2 or 3.2.1? This message of yours was written this March, so I'm
assuming that 3.2.1 will contain this fix?
Can anybody confirm this? I'm having
2013 Jun 19
0
Re: FreeBSD PVHVM call for testing
On 19 Jun 2013, at 13:34, Roger Pau Monné <roger.pau@citrix.com> wrote:
>
> Could you provide the boot log of the DomU, backtrace, Xen version and
> Dom0 kernel version?
I did not have a console attached when it rebooted, so I did not have a log of the initial boot. Now that I did, I see that it fails to mount its root volume.
It had been running previously on pvhvm_v10 for about
2012 Oct 30
8
[PATCH] xen PVonHVM: require at least Xen 3.4 as dom0
The XenPVHVM extensions have not been tested much on very old
hypervisors. At least Xen 3.4 gets some testing with the pvops kernel.
Require at least Xen 3.4 for the PVonHVM extensions. If an older
hypervisor is detected the extensions will be disabled and the guest
will only see emulated hardware.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
arch/x86/xen/enlighten.c | 27