search for: reprogram

...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 PCI bridge prefetch registers, including the > magic register mentioned above. > > This matches Win10 behaviour, which also rewrites these registers > during S3 resume (checked with qemu tracing). Windows 10 unconditionally rewrites these registers (BAR, I/O Base + Limit, Memory B...

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

...nd 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 PCI bridge prefetch registers, including the > > magic register mentioned above. > > > > This matches Win10 behaviour, which also rewrites these registers > > during S3 resume (checked with qemu tracing). > > Windows 10 unconditionally rewrites these registers (B...

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 10xxus: reprogram_timer(1000us), fail due to the past expiring time. ......: no timer softirq raised, no change to LAPIC timer. ......: if entry C3 again, HPET will be forced repro...

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]

...ad_atom *asyh = nv50_head_atom(new_crtc_state); + struct nv50_outp_atom *outp_atom; + struct nouveau_encoder *outp = + nv50_real_outp(nv50_head_atom_get_encoder(armh)); + struct drm_encoder *encoder = &outp->base.base; + + if (!asyh->clr.crc) + continue; + /* - * If we're reprogramming our OR, we need to flush the CRC - * disable first + * Re-programming ORs can't be done in the same flush as + * disabling CRCs */ - if (asyh->clr.crc) { - encoder = nv50_head_atom_get_encoder(armh); - - list_for_each_entry(outp_atom, &atom->outp, head) { - if (o...

...q enalbed), timer interrupt then occurs and drops guest at once; 3. drop to hypervisor ... then vmentry and wbinvd again; This loop will run again and again, until lucky enough wbinvd happens not to expire timer and then loop break, usually it would occur 10K~60K times, blocking guest 10s~60s. reprogram timer to avoid dead_like_loop. Signed-off-by: Liu Jinsong <jinsong.liu@intel.com> --- xen/arch/x86/hvm/vmx/vmx.c | 32 ++++++++++++++++++++++++++++---- 1 files changed, 28 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 75be62e..47...

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

...ine 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 cpu. Meanwhile strengthen the check in reprogram_hpet_evt_channel, treating (expire <= 0) as a hint for no need to reprogram hpet. Signed-off-by: Wei Gang <gang.wei@intel.com> diff -r f734a724902b xen/arch/x86/hpet.c --- a/xen/arch/x86/hpet.c Mon Apr 27 18:59:56 2009 +0100 +++ b/xen/arch/x86/hpet.c Thu Apr 30 14:45:01 2009 +0800 @@ -12...

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