Re: AMD graphics performance regression in 4.15 and later

On 04/11/2018 05:37 AM, Christian König wrote: >> With your patches my EPYC box is unusable with  4.15++ kernels. >> The whole Desktop is acting weird.  This one is using >> an Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] GPU. >> >> Box is  2 * EPYC 7281 with 128 GB ECC RAM >> >> Also a 14C Xeon

Re: AMD graphics performance regression in 4.15 and later

On 04/09/2018 05:42 AM, Christian König wrote: > Backporting all the detection logic is to invasive, but you could just > go into drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c and forcefull use the > other code path. > > Just look out for "#ifdef CONFIG_SWIOTLB" checks and disable those. Do you mean ju

Re: AMD graphics performance regression in 4.15 and later

uot;offending" patch reverted. Is that safe to run or are there possible bad interactions with other changes. Cheers, Jean-Marc On 04/06/2018 01:20 PM, Christian König wrote: > Am 06.04.2018 um 18:42 schrieb Jean-Marc Valin: >> Hi Christian, >> >> On 04/09/2018 07:48 A

Re: AMD graphics performance regression in 4.15 and later

Hi Christian, On 04/09/2018 07:48 AM, Christian König wrote: > Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin: >> Hi Christian, >> >> Is there a way to turn off these huge pages at boot-time/run-time? > > Only at compile time by not setting CONFIG_TRANSPARENT_HUGEPAGE.

Re: AMD graphics performance regression in 4.15 and later

tially somebody needs to > figure out why firefox and/or the user space stack is doing this > constant allocation/freeing of memory. > > There is also a bug tracker on bugs.kernel.org about this, but I can't > find it any more of hand. > > Regards, > Christian. > >

AMD graphics performance regression in 4.15 and later

Hi, I noticed a serious graphics performance regression between 4.14 and 4.15. It is most noticeable with Firefox (tried FF57 through FF60) and causes scrolling to be really choppy/sluggish. I've confirmed that the problem is also there on 4.16, while 4.13 works fine. After a bisection, I've narr

Re: Suspend to RAM generates oops and general protection fault

Hi, Sorry I haven't replied recently about that bug, but I have to admit I have no idea where to start. There actually seems to be much more fundamental problems with the kernel on my machines. I initially realised that even without using suspend to RAM, I was still getting crashes when docking. S

Re: Suspend to RAM generates oops and general protection fault

Luming Yu a écrit : > what about removing psmouse module? Trying that now. Any particular reason you suspect that one? Jean-Marc > On 1/23/07, Jean-Marc Valin <[EMAIL PROTECTED]> wrote: >> >>> will be a device driver. Common causes of suspend/resume problems

Re: Suspend to RAM generates oops and general protection fault

>>> will be a device driver. Common causes of suspend/resume problems from >>> the list you give below are acpi modules, bluetooth and usb. I'd also be >>> consider pcmcia, drm and fuse possibilities. But again, go for unloading >>> everything possible in the first instance. >> Actually, the reason

Re: Suspend to RAM generates oops and general protection fault

>> I just encountered the following oops and general protection fault >> trying to suspend/resume my laptop. I've got a Dell D820 laptop with a 2 >> GHz Core 2 Duo CPU. It usually suspends/resumes fine but not always. The >> relevant errors are below but the full dmesg log is at >> http://people.xi

Re: Suspend to RAM generates oops and general protection fault

>> I just encountered the following oops and general protection fault >> trying to suspend/resume my laptop. I've got a Dell D820 laptop with a 2 >> GHz Core 2 Duo CPU. It usually suspends/resumes fine but not always. The >> relevant errors are below but the full dmesg log is at >> http://people.xi

Suspend to RAM generates oops and general protection fault

Hi, I just encountered the following oops and general protection fault trying to suspend/resume my laptop. I've got a Dell D820 laptop with a 2 GHz Core 2 Duo CPU. It usually suspends/resumes fine but not always. The relevant errors are below but the full dmesg log is at http://people.xiph.org/~jm

Low latency patches

audio (or other real-time stuff) on Linux. Jean-Marc P.S. Please include me in CC, I'm not subscribed. -- Jean-Marc Valin <[EMAIL PROTECTED]> Université de Sherbrooke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a m

Re: ext3 bug

f it at that time (2GB free on the swap), so I doubt that's the problem in my case. Jean-Marc -- Jean-Marc Valin <[EMAIL PROTECTED]> Université de Sherbrooke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL P

Re: ext3 bug

-rcX? Jean-Marc -- Jean-Marc Valin <[EMAIL PROTECTED]> Université de Sherbrooke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please

Re: ext3 bug

ter a reboot, I was able to run fsck on the disk (many, many errors) and it went fine after. Jean-Marc -- Jean-Marc Valin <[EMAIL PROTECTED]> Université de Sherbrooke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAI

ext3 bug

nothing. The filesystem is on a USB hard disk. The actual dump is in attachment. I'm running Debian unstable with a custom 2.6.10 kernel on a 1.6 GHz Pentium-M. Jean-Marc -- Jean-Marc Valin <[EMAIL PROTECTED]> Université de Sherbrooke Feb 27 01:15:48 idefix kernel: [