search for: acpidumps

Hi, we have some problems with acpidump running on Xen Dom0. On 64 bit Dom0 it will trigger the OOM killer, on 32 bit Dom0s it will cause a kernel crash. The hypervisor does not matter, I tried 4.1.3-rc2 as well as various unstable versions including 25467, also 32-bit versions of 4.1. The Dom0 kernels were always PVOPS versions, the problems starts with 3.2-rc1~194 and is still in 3.5.0-rc3.

https://bugs.freedesktop.org/show_bug.cgi?id=55948 Priority: medium Bug ID: 55948 Assignee: nouveau at lists.freedesktop.org Summary: [nvd9 optimus] drm/nouveau/bios: attempt to fetch entire acpi rom image in one shot breaks module load QA Contact: xorg-team at lists.x.org Severity: major Classification:

On Wed, Nov 28, 2018 at 01:08:57PM +0200, Mika Westerberg wrote: > On Tue, Nov 27, 2018 at 09:49:44PM -0500, Michael S. Tsirkin wrote: > > On Tue, Nov 27, 2018 at 11:36:50AM +0200, Mika Westerberg wrote: > > > +linux-acpi > > > > > > Hi Michael, > > > > > > On Mon, Nov 26, 2018 at 10:53:26PM -0500, Michael S. Tsirkin wrote: > > >

On Mon, Oct 21, 2019 at 04:49:09PM +0200, Karol Herbst wrote: > On Mon, Oct 21, 2019 at 4:09 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Mon, Oct 21, 2019 at 03:54:09PM +0200, Karol Herbst wrote: > > > > I really would like to provide you more information about such > > > > workaround but I'm not aware of any ;-) I have

I have an Athlon system which isn't co-operating with the ACPI in -stable (I haven't tried -current yet). I notice that the general recommendation in -current is to provide the output of acpidump but none of the ACPI userland has been MFC'd. I just had a quick try and building the -current userland on -stable and found this is non-trivial because it appears that the APIs are

https://bugs.freedesktop.org/show_bug.cgi?id=90626 Bug ID: 90626 Summary: HP ZBook 15 nouveau driver hangup for kernel >= 3.19 Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: critical Priority: medium Component: Driver/nouveau Assignee:

On Wed, Nov 28, 2018 at 10:09:22AM -0500, Michael S. Tsirkin wrote: > Yea all this is weird, in particular I wonder why does everyone > using dsm insists on saying Arg4 > when they actually mean Arg3. ACPI numbers arguments from 0. > > So it's a bit ugly, and maybe worth fixing but unlikely to be > an actual issue simply because we end up not using DSM in the end. I agree.

On Wed, Nov 28, 2018 at 05:55:44PM +0200, Mika Westerberg wrote: > On Wed, Nov 28, 2018 at 10:09:22AM -0500, Michael S. Tsirkin wrote: > > Yea all this is weird, in particular I wonder why does everyone > > using dsm insists on saying Arg4 > > when they actually mean Arg3. ACPI numbers arguments from 0. > > > > So it's a bit ugly, and maybe worth fixing but

https://bugs.freedesktop.org/show_bug.cgi?id=99385 Bug ID: 99385 Summary: Nouveau produces soft lockups Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at lists.freedesktop.org

On Mon, Oct 21, 2019 at 5:46 PM Mika Westerberg <mika.westerberg at intel.com> wrote: > > On Mon, Oct 21, 2019 at 04:49:09PM +0200, Karol Herbst wrote: > > On Mon, Oct 21, 2019 at 4:09 PM Mika Westerberg > > <mika.westerberg at intel.com> wrote: > > > > > > On Mon, Oct 21, 2019 at 03:54:09PM +0200, Karol Herbst wrote: > > > > > I

I sent the file to you and the list but it appears to have bounced off the list server. Did you get the direct copy? On Thu, Mar 12, 2015 at 6:46 PM, Evan Foss <evanfoss at gmail.com> wrote: > Hi Pierre, > > Yes well acpidump is free software island wildlife. As yet it has not > predators so the only thing keeping it in check is forkers loosing > interest in maintaining their

On Tue, Aug 28, 2018 at 5:57 PM, Peter Wu <peter at lekensteyn.nl> wrote: > Just to be sure, after "sleep", do both devices report "suspended" in > /sys/bus/pci/devices/0000:00:1c.0/power/runtime_status > /sys/bus/pci/devices/0000:01:00.0/power/runtime_status > > and was this reproduced with a recent mainline kernel with no special > cmdline options? The

On Tue, Oct 22, 2019 at 11:16:14AM +0200, Karol Herbst wrote: > I think there is something I totally forgot about: > > When there was never a driver bound to the GPU, and if runtime power > management gets enabled on that device, runtime suspend/resume works > as expected (I am not 100% sure on if that always works, but I will > recheck that). AFAIK, if there is no driver bound

On Tue, Nov 26, 2019 at 06:10:36PM -0500, Lyude Paul wrote: > Hey-this is almost certainly not the right place in this thread to respond, > but this thread has gotten so deep evolution can't push the subject further to > the right, heh. So I'll just respond here. :) > I've been following this and helping out Karol with testing here and there. > They had me test

Hi Pierre, No worries about the response time. I remember when the features matrix was mostly todo's. Clearly you folks have put in a ton of work. I would feel bad about trying to shove a developer into my problem and I do not have the time right now to join the development team. Besides my day job I am currently writing a library to interpret BSDL files (JTAG). I am having a bit of trouble

this was already debugged and there is no point in searching inside the Firmware. It's not a firmware bug or anything. The proper fix is to do something inside Nouveau so that we don't upset the device and being able to runtime resume it again. The initial thing we do inside Nouveau to cause those issues is to run that so called "DEVINIT" script inside the vbios to initialize

http://bugs.freedesktop.org/show_bug.cgi?id=26349 Summary: nouveau_hybrid_setup: disables a discrete NVS 3100m on ThinkPad T410 Product: xorg Version: git Platform: All OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo:

On Wed, 2019-11-27 at 12:51 +0100, Karol Herbst wrote: > On Wed, Nov 27, 2019 at 12:49 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > On Tue, Nov 26, 2019 at 06:10:36PM -0500, Lyude Paul wrote: > > > Hey-this is almost certainly not the right place in this thread to > > > respond, > > > but this thread has gotten so deep evolution

I think there is something I totally forgot about: When there was never a driver bound to the GPU, and if runtime power management gets enabled on that device, runtime suspend/resume works as expected (I am not 100% sure on if that always works, but I will recheck that). In the past I know that at some point I "bisected" the nouveau driver to figure out what actually breaks it and found

Hi, I''m not able to activate VT-d on my PC due to a buggy BIOS. Xen fails to parse ACPI DMAR table. There is a problem with RMRR address range. My configuration is : - Debian Weezy - Xen version 4.1.2 (Debian 4.1.2-2) - Sabertooth X58 with last bios (1304) - i7 - 960 I have the following message : (XEN) [VT-D]dmar.c:704: Host address width 39 (XEN) [VT-D]dmar.c:719: found