similar to: Log/dump/trace HW access using PCI passthrough

Hello, I have problems running Xen (from Debian 7, i386 userspace) on Asus P3-AE5 system (M2V-TVM board) with Athlon 64 3000+ CPU (AM2, 1.8GHz). In short, Xen is not accessible from amd64 Linux kernels but works fine with 686 kernels. Long version: xen-system-i386 (4.1.4-3+deb7u1) works fine with linux-image-3.2.0-4-686-pae xen-system-amd64 (4.1.4-3+deb7u1) works fine with

On Saturday 10 October 2020 02:02:42 Karol Herbst wrote: > On Sat, Oct 10, 2020 at 12:23 AM Ilia Mirkin <imirkin at alum.mit.edu> wrote: > > > > On Fri, Oct 9, 2020 at 5:54 PM Karol Herbst <kherbst at redhat.com> wrote: > > > > > > On Fri, Oct 9, 2020 at 11:35 PM Ondrej Zary <linux at zary.sk> wrote: > > > > > > > > Hello,

On Fri, Oct 9, 2020 at 11:35 PM Ondrej Zary <linux at zary.sk> wrote: > > Hello, > I'm testing 5.9.0-rc8 and found that Riva TNT2 stopped working: > [ 0.000000] Linux version 5.9.0-rc8+ (zary at gsql) (gcc (Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #326 SMP Fri Oct 9 22:31:40 CEST 2020 > ... > [ 14.771464] nouveau 0000:01:00.0: GPU not

SiS 761 chipset does not support AGP cards but has AGP capability (for the onboard video). At least PC Chips A31G board using this chipset has an AGP-like AGPro slot that's wired to the PCI bus. Enabling AGP will fail (GPU lockup and software fbcon, X11 hangs). Add support for matching just the host bridge in nvkm_device_agp_quirks and add entry for SiS 761 with mode 0 (AGP disabled).

On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <linux at rainbow-software.org> wrote: >> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote: >>> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary >>> >>> <linux at rainbow-software.org> wrote: >>> > @@ -483,8

On Sunday 13 September 2015 21:12:25 Ilia Mirkin wrote: > On Sun, Sep 13, 2015 at 2:57 PM, Ondrej Zary <linux at rainbow-software.org> wrote: > > Hello, > > I have a PC Chips A31G board with AGPro slot and found that nouveau does > > not work properly with it. Console works but reverts to software mode, > > X11 hangs with mouse cursor only. > > > > The

With a new kernel, mind grabbing a dmesg with drm.debug=0x1e nouveau.debug=debug (or maybe even =trace)? Maybe also see if fbcon/fbdev have any debug things that can be turned on? Sounds like things are generally working, just the fbcon -> nouveaufb path seems somehow buggered. Another thing to try would be nouveau.atomic=1 On Fri, Nov 17, 2017 at 9:26 AM, Ondrej Zary <linux at

On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <linux at rainbow-software.org> wrote: > On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote: >> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary >> >> <linux at rainbow-software.org> wrote: >> > @@ -483,8 +483,8 @@ >> > nouveau 0000:02:00.0: disp: 0860: 00000000 -> 00000500 >> > nouveau

On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <linux at rainbow-software.org> wrote: >> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote: >>> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary >>> >>> <linux at rainbow-software.org> wrote: >>> > @@ -483,8

On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote: > On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary > > <linux at rainbow-software.org> wrote: > > @@ -483,8 +483,8 @@ > > nouveau 0000:02:00.0: disp: 0860: 00000000 -> 00000500 > > nouveau 0000:02:00.0: disp: 0864: 00000000 > > nouveau 0000:02:00.0: disp: 0868: 00000000 -> 04000500 >

On Fri, Oct 9, 2020 at 5:54 PM Karol Herbst <kherbst at redhat.com> wrote: > > On Fri, Oct 9, 2020 at 11:35 PM Ondrej Zary <linux at zary.sk> wrote: > > > > Hello, > > I'm testing 5.9.0-rc8 and found that Riva TNT2 stopped working: > > [ 0.000000] Linux version 5.9.0-rc8+ (zary at gsql) (gcc (Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian)

On Sat, Oct 10, 2020 at 12:23 AM Ilia Mirkin <imirkin at alum.mit.edu> wrote: > > On Fri, Oct 9, 2020 at 5:54 PM Karol Herbst <kherbst at redhat.com> wrote: > > > > On Fri, Oct 9, 2020 at 11:35 PM Ondrej Zary <linux at zary.sk> wrote: > > > > > > Hello, > > > I'm testing 5.9.0-rc8 and found that Riva TNT2 stopped working: > >

On Friday 17 November 2017 15:43:33 Ilia Mirkin wrote: > With a new kernel, mind grabbing a dmesg with drm.debug=0x1e > nouveau.debug=debug (or maybe even =trace)? Maybe also see if > fbcon/fbdev have any debug things that can be turned on? Here's diff of the 32MB and 64MB debug logs: --- nouveau-debug-32mb.txt- 2017-11-17 18:12:06.290108330 +0100 +++ nouveau-debug-64mb.txt-

Hello, I'm testing 5.9.0-rc8 and found that Riva TNT2 stopped working: [ 0.000000] Linux version 5.9.0-rc8+ (zary at gsql) (gcc (Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #326 SMP Fri Oct 9 22:31:40 CEST 2020 ... [ 14.771464] nouveau 0000:01:00.0: GPU not supported on big-endian [ 14.771782] nouveau: probe of 0000:01:00.0 failed with error -38 big-endian? WTF? The

Package: xcp-xapi Version: 1.3.2-15 Severity: normal I am trying to pass an SRIOV virtual function in a virtual machine but the attempt fails with the following errors shown in the xcp-xapi.log [20130829T19:29:17.909Z|debug|sriov1|314 UNIX /var/lib/xcp/xapi|VM.start R:9e8e10bd31bb|pciops] PCI devices from other-config:pci to attach: 0/0000:04:00.1 [20130829T19:29:18.012Z|debug|sriov1|314 UNIX

Hello, I've just been hit by this old bug which is still present in 4.14: https://bugs.freedesktop.org/show_bug.cgi?id=80675 On MCP79 (ION), when stolen memory is set to 32MB in BIOS, console is blank but X11 works. When the stolen memory is increased to 64MB, console works fine. Bisected it to this: 4f6029da58ba9204c98e33f4f3737fe085c87a6f is the first bad commit commit

On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary <linux at rainbow-software.org> wrote: > @@ -483,8 +483,8 @@ > nouveau 0000:02:00.0: disp: 0860: 00000000 -> 00000500 > nouveau 0000:02:00.0: disp: 0864: 00000000 > nouveau 0000:02:00.0: disp: 0868: 00000000 -> 04000500 > -nouveau 0000:02:00.0: disp: 086c: 00000000 -> 00100500 > -nouveau 0000:02:00.0:

On 2019-08-18 11:27 a.m., Ondrej Zary wrote: > On Saturday 17 August 2019 14:50:33 Alex Dewar wrote: >> Hi all, >> >> I'm getting frequent system crashes (every few hours or so) and it seems >> that the nouveau driver is causing the issue (dmesg output below). I see it >> with both v5.2.8 and the v4.19 LTS kernel. Sometimes the system >> completely

On Saturday 17 August 2019 14:50:33 Alex Dewar wrote: > Hi all, > > I'm getting frequent system crashes (every few hours or so) and it seems > that the nouveau driver is causing the issue (dmesg output below). I see it > with both v5.2.8 and the v4.19 LTS kernel. Sometimes the system > completely freezes and sometimes seemingly just the nouveau driver goes > down. The

After a few days, one of my DomU becomes unresponsive. Here''s the output of my DomU''s. root@xenII:/var/log/xen# xl list Name ID Mem VCPUs State Time(s) Domain-0 0 7126 2 r----- 723932.0 redhat-sdsweb 11 4091 2 -b---- 92633.1 w2k8-AD