search for: reprogrammed

On Fri, Sep 07, 2018 at 01:36:14PM +0800, Daniel Drake wrote: <..> > Thomas Martitz reports that this workaround also solves an issue where > the AMD Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive > after S3 suspend/resume. Where was this claimed? It is not stated in the linked bug: (https://bugs.freedesktop.org/show_bug.cgi?id=105760 > On resume, reprogram the

On Fri, Sep 7, 2018 at 2:40 PM, Sinan Kaya <okaya at kernel.org> wrote: > On 9/6/2018 10:36 PM, Daniel Drake wrote: >> >> + if (pci_dev->class == PCI_CLASS_BRIDGE_PCI << 8) >> + pci_setup_bridge_mmio_pref(pci_dev); > > > This should probably some kind of a quirk rather than default > for the listed card as it sounds like you are

Am 01.10.18 um 06:57 schrieb Daniel Drake: > On Sun, Sep 30, 2018 at 5:07 AM Thomas Martitz <kugel at rockbox.org> wrote: >> The latest iteration does not work on my HP system. The GPU fails to >> power up just like the unpatched kernel. > > That's weird, I would not expect a behaviour change in the latest > patch. pci_restore_config_dword() has some debug

Am 02.10.18 um 22:03 schrieb Bjorn Helgaas: > Hi Thomas, > > On Mon, Oct 01, 2018 at 04:25:06PM +0200, Thomas Martitz wrote: >> Am 01.10.18 um 06:57 schrieb Daniel Drake: >>> On Sun, Sep 30, 2018 at 5:07 AM Thomas Martitz <kugel at rockbox.org> wrote: >>>> The latest iteration does not work on my HP system. The GPU fails to >>>> power up just

On 9/6/2018 10:36 PM, Daniel Drake wrote: > + if (pci_dev->class == PCI_CLASS_BRIDGE_PCI << 8) > + pci_setup_bridge_mmio_pref(pci_dev); This should probably some kind of a quirk rather than default for the listed card as it sounds like you are dealing with broken hardware.

On Sun, Sep 30, 2018 at 5:07 AM Thomas Martitz <kugel at rockbox.org> wrote: > The latest iteration does not work on my HP system. The GPU fails to > power up just like the unpatched kernel. That's weird, I would not expect a behaviour change in the latest patch. pci_restore_config_dword() has some debug messages, could you please make them visible and show logs again? Also remind

[+cc LKML, Dave, Luming] On Fri, Sep 07, 2018 at 05:05:15PM +0200, Peter Wu wrote: > On Fri, Sep 07, 2018 at 01:36:14PM +0800, Daniel Drake wrote: > <..> > > Thomas Martitz reports that this workaround also solves an issue where > > the AMD Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive > > after S3 suspend/resume. > > Where was this claimed? It

On Thu, Sep 13, 2018 at 5:37 AM Daniel Drake <drake at endlessm.com> wrote: > > On 38+ Intel-based Asus products, the nvidia GPU becomes unusable > after S3 suspend/resume. The affected products include multiple > generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs > many errors such as: > > fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR]

On Thu, Sep 13, 2018 at 11:37:45AM +0800, Daniel Drake wrote: > On 38+ Intel-based Asus products, the nvidia GPU becomes unusable > after S3 suspend/resume. The affected products include multiple > generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs > many errors such as: > > fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04 >

CPUIDLE: Avoid remnant LAPIC timer intr while force hpetbroadcast LAPIC will stop during C3, and resume to work after exit from C3. Considering below case: The LAPIC timer was programmed to expire after 1000us, but CPU enter C3 after 100us and exit C3 at 9xxus. 0us: reprogram_timer(1000us) 100us: entry C3, LAPIC timer stop 9xxus: exit C3 due to unexpected event, LAPIC timer continue running

Hi Thomas, On Mon, Oct 01, 2018 at 04:25:06PM +0200, Thomas Martitz wrote: > Am 01.10.18 um 06:57 schrieb Daniel Drake: > > On Sun, Sep 30, 2018 at 5:07 AM Thomas Martitz <kugel at rockbox.org> wrote: > > > The latest iteration does not work on my HP system. The GPU fails to > > > power up just like the unpatched kernel. > > > > That's weird, I

Hi, Has anyone here reprogrammed their Polycom features keys using sip/ipmid.cfg? If so I would be really grateful if someone could send me an example as I have tried various entries for hours now and don't seem to be getting anywhere. Any help appreciated. Kind regards Jamie Heckford Technical Consultant

On Wed, Sep 12, 2018 at 8:45 AM Daniel Drake <drake at endlessm.com> wrote: > > On 38+ Intel-based Asus products, the nvidia GPU becomes unusable > after S3 suspend/resume. The affected products include multiple > generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs > many errors such as: > > fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR]

While I had thought I'd tested this before, it looks like this one issue slipped by my original CRC patches. Basically, there seem to be a few rules we need to follow when sending CRC commands to the display controller: * CRCs cannot be both disabled and enabled for a single head in the same flush * If a head with CRC reporting enabled switches from one OR to another, there must be a

From e2d47e2f75bac6876b7c2eaecfe946966bf27516 Mon Sep 17 00:00:00 2001 From: Liu Jinsong <jinsong.liu@intel.com> Date: Tue, 26 Nov 2013 04:53:17 +0800 Subject: [PATCH] VMX: wbinvd when vmentry under UC This patch flush cache when vmentry back to UC guest, to prevent cache polluted by hypervisor access guest memory during UC mode. However, wbinvd is a _very_ time consuming operation, so 1.

Am 27.09.18 um 22:52 schrieb Bjorn Helgaas: > [+cc LKML] > > On Tue, Sep 18, 2018 at 04:32:44PM -0500, Bjorn Helgaas wrote: >> On Thu, Sep 13, 2018 at 11:37:45AM +0800, Daniel Drake wrote: >>> On 38+ Intel-based Asus products, the nvidia GPU becomes unusable >>> after S3 suspend/resume. The affected products include multiple >>> generations of nvidia GPUs

cpuidle: Fix for timer_deadline==0 case After the scheduler timer became suspended before entering cpu idle state, the percpu timer_deadline is possible to be 0, i.e. no soft timer in the queue. This case will cause unexpected large residency percentage in C1 for the purely idle cpu. The fix is if timer_deadline == 0, skip most hpet broadcast enter logic because no broadcast is needed for this

I have created https://bugzilla.kernel.org/show_bug.cgi?id=201069 to archive the research done so far. On Fri, Sep 7, 2018 at 11:05 PM, Peter Wu <peter at lekensteyn.nl> wrote: > Windows 10 unconditionally rewrites these registers (BAR, I/O Base + > Limit, Memory Base + Limit, etc. from top to bottom), see annotations: > https://www.spinics.net/lists/linux-pci/msg75856.html >

[+cc LKML] On Tue, Sep 18, 2018 at 04:32:44PM -0500, Bjorn Helgaas wrote: > On Thu, Sep 13, 2018 at 11:37:45AM +0800, Daniel Drake wrote: > > On 38+ Intel-based Asus products, the nvidia GPU becomes unusable > > after S3 suspend/resume. The affected products include multiple > > generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs > > many errors such

Hi, I was wondering whether it is technically possible to go back from eg. DOS or Linux directly to the bootloader (instead of rebooting the hardware). We currently have 2 images (one DOS and one Linux) that need to be started before loading a system. They do things like disable PXE on NICs (using an Intel DOS tool), verify the correctness of the network patchings and validate if the