[REGRESSION][BISECTED] 5.9-rc4 disables console on radeon

Starting with linux-5.9-rc4, the Dell monitor on my desktop PC goes black during boot when the kernel activates the framebuffer console, except for this error message shown in the center of the screen: "Dell U2412M The current input timing is not supported by the monitor display. Please change

Re: [PATCH 09/16] sparc64: use the generic get_user_pages_fast code

For the record the futex test case OOPSes a 5.3-rc3 kernel running on a Sun Blade 2500 (2 x USIIIi). This system runs a custom distro with a custom toolchain (gcc-8.3 based), so I doubt it's a distro problem. On Sat, Aug 10, 2019 at 9:17 AM Christoph Hellwig wrote: > > There isn't really a way

Re: [5.0-rc5 regression] "scsi: kill off the legacy IO path" causes 5 minute delay during boot on Sun Blade 2500

On Sun, Feb 10, 2019 at 5:05 PM Jens Axboe wrote: > > On 2/10/19 8:44 AM, James Bottomley wrote: > > On Sun, 2019-02-10 at 10:17 +0100, Mikael Pettersson wrote: > >> On Sat, Feb 9, 2019 at 7:19 PM James Bottomley > >> wrote: > > [...] > >>> I thi

Re: [5.0-rc5 regression] "scsi: kill off the legacy IO path" causes 5 minute delay during boot on Sun Blade 2500

On Sat, Feb 9, 2019 at 7:19 PM James Bottomley wrote: > > On Sat, 2019-02-09 at 18:04 +0100, Mikael Pettersson wrote: > > 4.20 and earlier kernels boot fine on my Sun Blade 2500 (UltraSPARC > > IIIi), but the 5.0-rc kernels consistently experience a 5 minute > > delay >

[5.0-rc5 regression] "scsi: kill off the legacy IO path" causes 5 minute delay during boot on Sun Blade 2500

4.20 and earlier kernels boot fine on my Sun Blade 2500 (UltraSPARC IIIi), but the 5.0-rc kernels consistently experience a 5 minute delay late during boot, after enabling networking but before allowing user logins. E.g. 5.0-rc5 dmesg has: [Fri Feb 8 17:13:17 2019] random: dbus-daemon:

Re: [PATCH] mm: disable `vm.max_map_count' sysctl limit

On Mon, Nov 27, 2017 at 6:25 PM, Andi Kleen wrote: > It's an arbitrary scaling limit on the how many mappings the process > has. The more memory you have the bigger a problem it is. We've > ran into this problem too on larger systems. > > The reason the limit was there

Re: [PATCH] mm: disable `vm.max_map_count' sysctl limit

On Mon, Nov 27, 2017 at 6:25 PM, Andi Kleen wrote: > It's an arbitrary scaling limit on the how many mappings the process > has. The more memory you have the bigger a problem it is. We've > ran into this problem too on larger systems. > > The reason the limit was there originally because it

Re: [PATCH] mm: disable `vm.max_map_count' sysctl limit

On Mon, Nov 27, 2017 at 5:22 PM, Matthew Wilcox wrote: >> Could you be more explicit about _why_ we need to remove this tunable? >> I am not saying I disagree, the removal simplifies the code but I do not >> really see any justification here. > > I imagine he started seeing

Re: [PATCH] mm: disable `vm.max_map_count' sysctl limit

On Mon, Nov 27, 2017 at 5:22 PM, Matthew Wilcox wrote: >> Could you be more explicit about _why_ we need to remove this tunable? >> I am not saying I disagree, the removal simplifies the code but I do not >> really see any justification here. > > I imagine he started seeing random syscalls

Re: [PATCH] mm: disable `vm.max_map_count' sysctl limit

On Mon, Nov 27, 2017 at 11:12 AM, Michal Hocko wrote: > > I've kept the kernel tunable to not break the API towards user-space, > > but it's a no-op now. Also the distinction between split_vma() and > > __split_vma() disappears, so they are merged. > > Could you be more

Re: [PATCH] mm: disable `vm.max_map_count' sysctl limit

On Mon, Nov 27, 2017 at 11:12 AM, Michal Hocko wrote: > > I've kept the kernel tunable to not break the API towards user-space, > > but it's a no-op now. Also the distinction between split_vma() and > > __split_vma() disappears, so they are merged. > > Could you be more explicit about _why_ we

[PATCH] mm: disable `vm.max_map_count' sysctl limit

Also built an ARM NOMMU kernel to make sure NOMMU compiles and links cleanly. Signed-off-by: Mikael Pettersson <mikpeli...@gmail.com> --- Documentation/sysctl/vm.txt | 17 +- Documentation/vm/ksm.txt | 4 Documentation/vm/remap_file_pages.txt | 4

[PATCH] mm: disable `vm.max_map_count' sysctl limit

Also built an ARM NOMMU kernel to make sure NOMMU compiles and links cleanly. Signed-off-by: Mikael Pettersson --- Documentation/sysctl/vm.txt | 17 +- Documentation/vm/ksm.txt | 4 Documentation/vm/remap_file_pages.txt | 4 fs/bi

Re: Possible gcc 4.8.5 bug about RELOC_HIDE marcro

Jia He writes: > I tried to build kernel 4.14-rc1 on a arm64 server in distro centos 7.3. > The gcc version is 4.8.5 I have no input on the specifics of the issue, but please note that gcc-4.8 is no longer supported or maintained by upstream. Even gcc-4.9 is EOL, and gcc-5 will be EOL:d inn a

Re: Possible gcc 4.8.5 bug about RELOC_HIDE marcro

Jia He writes: > I tried to build kernel 4.14-rc1 on a arm64 server in distro centos 7.3. > The gcc version is 4.8.5 I have no input on the specifics of the issue, but please note that gcc-4.8 is no longer supported or maintained by upstream. Even gcc-4.9 is EOL, and gcc-5 will be EOL:d inn a

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

David Miller writes: > From: Mikael Pettersson <mikpeli...@gmail.com> > Date: Thu, 3 Aug 2017 22:02:57 +0200 > > > With that in place the kernel booted fine. > > When I then ran the `poll' strace test binary, the OOPS was replaced by: > > &

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

David Miller writes: > From: Mikael Pettersson > Date: Thu, 3 Aug 2017 22:02:57 +0200 > > > With that in place the kernel booted fine. > > When I then ran the `poll' strace test binary, the OOPS was replaced by: > > > > [ 140.589913] _copy_from_user(

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

Sam Ravnborg writes: > On Tue, Aug 01, 2017 at 10:58:29PM +0200, Sam Ravnborg wrote: > > Hi Mikael. > > > > I think this translates to the following code > > from linux/uaccess.h > > > > first part is the inlined _copy_from_user() > > > > > > > > (gdb) x/10i do_sys_poll+0x80-16 > >

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

Sam Ravnborg writes: > On Tue, Aug 01, 2017 at 10:58:29PM +0200, Sam Ravnborg wrote: > > Hi Mikael. > > > > I think this translates to the following code > > from linux/uaccess.h > > > > first part is the inlined _copy_from_user() > > > > > > > > (gdb) x/10i do_sys_poll+0x80-16 > >

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

David Miller writes: > From: Anatoly Pugachev > Date: Tue, 1 Aug 2017 01:01:47 +0300 > > > I don't know how to run on a running kernel , but as I understood: > > > > root@v215:strace# gzip -dc /boot/vmlinuz-4.12.0 > vmlinux > > root@v215:strace# gdb -q vmlinux > >

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

David Miller writes: > From: Anatoly Pugachev > Date: Tue, 1 Aug 2017 01:01:47 +0300 > > > I don't know how to run on a running kernel , but as I understood: > > > > root@v215:strace# gzip -dc /boot/vmlinuz-4.12.0 > vmlinux > > root@v215:strace# gdb -q vmlinux > > Reading symbols from

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

Mikael Pettersson writes: > Anatoly Pugachev writes: > > On Fri, Jul 28, 2017 at 11:45 AM, Mikael Pettersson > > <mikpeli...@gmail.com> wrote: > > > It's an rpmbuild --rebuild of Fedora's strace-4.18-1.fc24.src.rpm, but > according to the > &

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

Mikael Pettersson writes: > Anatoly Pugachev writes: > > On Fri, Jul 28, 2017 at 11:45 AM, Mikael Pettersson > > wrote: > > > It's an rpmbuild --rebuild of Fedora's strace-4.18-1.fc24.src.rpm, but > according to the > > > build log the following

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

Anatoly Pugachev writes: > On Fri, Jul 28, 2017 at 11:45 AM, Mikael Pettersson > <mikpeli...@gmail.com> wrote: > > It's an rpmbuild --rebuild of Fedora's strace-4.18-1.fc24.src.rpm, but > > according to the > > build log the following should do it: > > &

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

Anatoly Pugachev writes: > On Fri, Jul 28, 2017 at 11:45 AM, Mikael Pettersson > wrote: > > It's an rpmbuild --rebuild of Fedora's strace-4.18-1.fc24.src.rpm, but > > according to the > > build log the following should do it: > > > > export CFLAG

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

David Miller writes: > From: Mikael Pettersson <mikpeli...@gmail.com> > Date: Thu, 27 Jul 2017 21:45:25 +0200 > > > Attempting to build strace-4.18 as sparcv9 code and run its test suite > > on a sparc64 machine (Sun Blade 2500 w/ 2 x USIIIi in my case) fails

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

David Miller writes: > From: Mikael Pettersson > Date: Thu, 27 Jul 2017 21:45:25 +0200 > > > Attempting to build strace-4.18 as sparcv9 code and run its test suite > > on a sparc64 machine (Sun Blade 2500 w/ 2 x USIIIi in my case) fails > > reliably in

strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

Attempting to build strace-4.18 as sparcv9 code and run its test suite on a sparc64 machine (Sun Blade 2500 w/ 2 x USIIIi in my case) fails reliably in three test cases (sched.gen, sched_xetattr.gen, and poll) because two test binaries (sched_xetattr and poll) OOPS the kernel and get killed.

strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

Attempting to build strace-4.18 as sparcv9 code and run its test suite on a sparc64 machine (Sun Blade 2500 w/ 2 x USIIIi in my case) fails reliably in three test cases (sched.gen, sched_xetattr.gen, and poll) because two test binaries (sched_xetattr and poll) OOPS the kernel and get killed.

Re: v4.13-rc2: usb mouse stopped working?

Jiri Kosina writes: > On Mon, 24 Jul 2017, Pavel Machek wrote: > > > On thinkpad x220, USB mouse stopped working in v4.13-rc2. v4.12 was > > ok, iirc. > > > > Now, USB mouse is so common hw that I may have something wrong in my > > config...? But I did not change anything there. > >

Re: v4.13-rc2: usb mouse stopped working?

Jiri Kosina writes: > On Mon, 24 Jul 2017, Pavel Machek wrote: > > > On thinkpad x220, USB mouse stopped working in v4.13-rc2. v4.12 was > > ok, iirc. > > > > Now, USB mouse is so common hw that I may have something wrong in my > > config...? But I did not change anything there. > >

Re: 4.7-rc6, ext4, sparc64: Unable to handle kernel paging request at ...

Meelis Roos writes: > > > Just got this on bootup of my Sun T2000: > > >... > > > I have not seen it before, this includes 4.6.0 4.6.0-08907-g7639dad > > > 4.7.0-rc1-00094-g6b15d66 4.7.0-rc4-00014-g67016f6. > > > > > > It is not reproducible, did not appear on next reboot of the same > > >

Re: 4.7-rc6, ext4, sparc64: Unable to handle kernel paging request at ...

Meelis Roos writes: > > > Just got this on bootup of my Sun T2000: > > >... > > > I have not seen it before, this includes 4.6.0 4.6.0-08907-g7639dad > > > 4.7.0-rc1-00094-g6b15d66 4.7.0-rc4-00014-g67016f6. > > > > > > It is not reproducible, did not appear on next reboot of the same > > >

Re: SIGSYS annoyance

Andy Lutomirski writes: > On Mon, Jun 6, 2016 at 9:03 AM, Kees Cook wrote: > > On Fri, Jun 3, 2016 at 10:16 PM, Andy Lutomirski > > wrote: > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1176099 > >> > >> Should SIGSYS be delivered to the

Re: SIGSYS annoyance

Andy Lutomirski writes: > On Mon, Jun 6, 2016 at 9:03 AM, Kees Cook wrote: > > On Fri, Jun 3, 2016 at 10:16 PM, Andy Lutomirski > > wrote: > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1176099 > >> > >> Should SIGSYS be delivered to the handler even if blocked? What, if > >>

Re: fork on processes with lots of memory

Felix von Leitner writes: > > Dear Linux kernel devs, > > > I talked to someone who uses large Linux based hardware to run a > > process with huge memory requirements (think 4 GB), and he told me that > > if they do a fork() syscall on that process, the whole system comes to > > standstill.

Re: fork on processes with lots of memory

Felix von Leitner writes: > > Dear Linux kernel devs, > > > I talked to someone who uses large Linux based hardware to run a > > process with huge memory requirements (think 4 GB), and he told me that > > if they do a fork() syscall on that process, the whole system comes to > > standstill.

Re: [4.3-rc1 regression] modular 8250 doesn't load

Greg Kroah-Hartman writes: > On Mon, Sep 14, 2015 at 02:12:43PM -0700, Greg Kroah-Hartman wrote: > > On Mon, Sep 14, 2015 at 10:42:24PM +0200, Mikael Pettersson wrote: > > > Greg Kroah-Hartman writes: > > > > On Mon, Sep 14, 2015 at 08:06:21PM +0200, Mikael Pett

Re: [4.3-rc1 regression] modular 8250 doesn't load

Greg Kroah-Hartman writes: > On Mon, Sep 14, 2015 at 08:06:21PM +0200, Mikael Pettersson wrote: > > Greg Kroah-Hartman writes: > > > On Mon, Sep 14, 2015 at 07:08:10PM +0200, Mikael Pettersson wrote: > > > > I have CONFIG_SERIAL_8250=m. With 4.

Re: [4.3-rc1 regression] modular 8250 doesn't load

Greg Kroah-Hartman writes: > On Mon, Sep 14, 2015 at 07:08:10PM +0200, Mikael Pettersson wrote: > > I have CONFIG_SERIAL_8250=m. With 4.2 '/sbin/modprobe 8250' worked > > and resulted in: > > > > [ 41.354550] Serial: 8250/16550 driver, 4 ports, IRQ sharing

[4.3-rc1 regression] modular 8250 doesn't load

I have CONFIG_SERIAL_8250=m. With 4.2 '/sbin/modprobe 8250' worked and resulted in: [ 41.354550] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 41.375156] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A With 4.3-rc1 however the command fails and logs

[4.3-rc1 regression] modular 8250 doesn't load

I have CONFIG_SERIAL_8250=m. With 4.2 '/sbin/modprobe 8250' worked and resulted in: [ 41.354550] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 41.375156] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A With 4.3-rc1 however the command fails and logs

Re: [4.3-rc1 regression] modular 8250 doesn't load

Greg Kroah-Hartman writes: > On Mon, Sep 14, 2015 at 08:06:21PM +0200, Mikael Pettersson wrote: > > Greg Kroah-Hartman writes: > > > On Mon, Sep 14, 2015 at 07:08:10PM +0200, Mikael Pettersson wrote: > > > > I have CONFIG_SERIAL_8250=m. With 4.

Re: [4.3-rc1 regression] modular 8250 doesn't load

Greg Kroah-Hartman writes: > On Mon, Sep 14, 2015 at 02:12:43PM -0700, Greg Kroah-Hartman wrote: > > On Mon, Sep 14, 2015 at 10:42:24PM +0200, Mikael Pettersson wrote: > > > Greg Kroah-Hartman writes: > > > > On Mon, Sep 14, 2015 at 08:06:21PM +0200, Mikael Pett

Re: [4.3-rc1 regression] modular 8250 doesn't load

Greg Kroah-Hartman writes: > On Mon, Sep 14, 2015 at 07:08:10PM +0200, Mikael Pettersson wrote: > > I have CONFIG_SERIAL_8250=m. With 4.2 '/sbin/modprobe 8250' worked > > and resulted in: > > > > [ 41.354550] Serial: 8250/16550 driver, 4 ports, IRQ sharing

RE: [REGRESSION,BISECTED] 4.1-rc2 radeon audio changes oops the kernel hard

Deucher, Alexander writes: > > -Original Message- > > From: Mikael Pettersson [mailto:mikpeli...@gmail.com] > > Sent: Monday, May 04, 2015 11:53 AM > > To: linux-kernel@vger.kernel.org > > Cc: Deucher, Alexander > > Subject: [REGRESSION,BISECTE

[REGRESSION,BISECTED] 4.1-rc2 radeon audio changes oops the kernel hard

On my Ivy Bridge i7 mobo w/ Radeon graphics, the 4.1-rc2 kernel oopses hard, requiring a hard reset: BUG: unable to handle kernel NULL pointer dereference at 0010 IP: [] radeon_audio_detect+0x5b/0x150 [radeon] PGD 0 Oops: [#1] SMP Modules linked in: af_packet

[REGRESSION,BISECTED] 4.1-rc2 radeon audio changes oops the kernel hard

On my Ivy Bridge i7 mobo w/ Radeon graphics, the 4.1-rc2 kernel oopses hard, requiring a hard reset: BUG: unable to handle kernel NULL pointer dereference at 0010 IP: [a03d0e1b] radeon_audio_detect+0x5b/0x150 [radeon] PGD 0 Oops: [#1] SMP Modules linked in: af_packet

RE: [REGRESSION,BISECTED] 4.1-rc2 radeon audio changes oops the kernel hard

Deucher, Alexander writes: -Original Message- From: Mikael Pettersson [mailto:mikpeli...@gmail.com] Sent: Monday, May 04, 2015 11:53 AM To: linux-kernel@vger.kernel.org Cc: Deucher, Alexander Subject: [REGRESSION,BISECTED] 4.1-rc2 radeon audio changes oops the kernel

Re: [PATCH] seccomp.2: Add note about alarm(2) not being sufficient to limit runtime

Jann Horn writes: > On Wed, Mar 11, 2015 at 10:43:50PM +0100, Mikael Pettersson wrote: > > Jann Horn writes: > > > Or should I throw this patch away and write a patch > > > for the prctl() manpage instead that documents that > > > being able to

Re: [PATCH] Don't allow blocking of signals using sigreturn.

Andy Lutomirski writes: > On Wed, Mar 11, 2015 at 2:43 PM, Mikael Pettersson > wrote: > > Jann Horn writes: > > > Or should I throw this patch away and write a patch > > > for the prctl() manpage instead that documents that > > > being able

Re: [PATCH] seccomp.2: Add note about alarm(2) not being sufficient to limit runtime

Jann Horn writes: On Wed, Mar 11, 2015 at 10:43:50PM +0100, Mikael Pettersson wrote: Jann Horn writes: Or should I throw this patch away and write a patch for the prctl() manpage instead that documents that being able to call sigreturn() implies being able to effectively

Re: [PATCH] Don't allow blocking of signals using sigreturn.

Andy Lutomirski writes: On Wed, Mar 11, 2015 at 2:43 PM, Mikael Pettersson mikpeli...@gmail.com wrote: Jann Horn writes: Or should I throw this patch away and write a patch for the prctl() manpage instead that documents that being able to call sigreturn() implies being able

Re: [PATCH] Don't allow blocking of signals using sigreturn.

Jann Horn writes: > Or should I throw this patch away and write a patch > for the prctl() manpage instead that documents that > being able to call sigreturn() implies being able to > effectively call sigprocmask(), at least on some > architectures like X86? Well, that is the semantics of

Re: [PATCH] Don't allow blocking of signals using sigreturn.

Jann Horn writes: Or should I throw this patch away and write a patch for the prctl() manpage instead that documents that being able to call sigreturn() implies being able to effectively call sigprocmask(), at least on some architectures like X86? Well, that is the semantics of

Re: status of ia64 / hpsim

Tony Luck writes: > On Tue, Dec 30, 2014 at 7:50 AM, Christoph Hellwig > wrote: > > IS the ia64 hpsim architecture still in use? I noticed it because it > > has a fairly rudimentary SCSI driver under arch/ia64, which doesn't > > look very maintained. > > Mikael was doing something with

Re: status of ia64 / hpsim

Tony Luck writes: On Tue, Dec 30, 2014 at 7:50 AM, Christoph Hellwig h...@infradead.org wrote: IS the ia64 hpsim architecture still in use? I noticed it because it has a fairly rudimentary SCSI driver under arch/ia64, which doesn't look very maintained. Mikael was doing

Re: [PATCH] arm: Blacklist gcc 4.8.[012] and 4.9.0 with CONFIG_FRAME_POINTER

Peter Hurley writes: > On 10/11/2014 12:33 PM, Mikael Pettersson wrote: > > Peter Hurley writes: > > > On 10/10/2014 12:36 PM, Russell King - ARM Linux wrote: > > > > On Fri, Oct 10, 2014 at 12:26:14PM -0400, Peter Hurley wrote: > > > >> gc

Re: [PATCH] arm: Blacklist gcc 4.8.[012] and 4.9.0 with CONFIG_FRAME_POINTER

Peter Hurley writes: On 10/11/2014 12:33 PM, Mikael Pettersson wrote: Peter Hurley writes: On 10/10/2014 12:36 PM, Russell King - ARM Linux wrote: On Fri, Oct 10, 2014 at 12:26:14PM -0400, Peter Hurley wrote: gcc versions 4.8.[012] and 4.9.0 generates code that prematurely

Re: [PATCH] arm: Blacklist gcc 4.8.[012] and 4.9.0 with CONFIG_FRAME_POINTER

Peter Hurley writes: > On 10/10/2014 12:36 PM, Russell King - ARM Linux wrote: > > On Fri, Oct 10, 2014 at 12:26:14PM -0400, Peter Hurley wrote: > >> gcc versions 4.8.[012] and 4.9.0 generates code that prematurely > >> adjusts the stack pointer such that still-to-be-referenced locals > >>

Re: [PATCH] arm: Blacklist gcc 4.8.[012] and 4.9.0 with CONFIG_FRAME_POINTER

Peter Hurley writes: On 10/10/2014 12:36 PM, Russell King - ARM Linux wrote: On Fri, Oct 10, 2014 at 12:26:14PM -0400, Peter Hurley wrote: gcc versions 4.8.[012] and 4.9.0 generates code that prematurely adjusts the stack pointer such that still-to-be-referenced locals are below the

Re: [BISECTED] 3.17-rc1 radeon screen corruption due to "Always flush the HDP cache before submitting a CS to the GPU"

Michel Dänzer writes: > On 06.09.2014 01:49, Mikael Pettersson wrote: > > Michel Dänzer writes: > > > On 30.08.2014 22:59, Mikael Pettersson wrote: > > > > Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen > > corruption > > >

Re: [BISECTED] 3.17-rc1 radeon screen corruption due to Always flush the HDP cache before submitting a CS to the GPU

Michel Dänzer writes: On 06.09.2014 01:49, Mikael Pettersson wrote: Michel Dänzer writes: On 30.08.2014 22:59, Mikael Pettersson wrote: Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption after a while in X + firefox. This still occurs

Re: [BISECTED] 3.17-rc1 radeon screen corruption due to "Always flush the HDP cache before submitting a CS to the GPU"

Michel Dänzer writes: > On 06.09.2014 01:49, Mikael Pettersson wrote: > > Michel Dänzer writes: > > > On 30.08.2014 22:59, Mikael Pettersson wrote: > > > > Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen > > corruption > > >

Re: [BISECTED] 3.17-rc1 radeon screen corruption due to Always flush the HDP cache before submitting a CS to the GPU

Michel Dänzer writes: On 06.09.2014 01:49, Mikael Pettersson wrote: Michel Dänzer writes: On 30.08.2014 22:59, Mikael Pettersson wrote: Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption after a while in X + firefox. This still occurs

Re: [BISECTED] 3.17-rc1 radeon screen corruption due to "Always flush the HDP cache before submitting a CS to the GPU"

Michel Dänzer writes: > On 30.08.2014 22:59, Mikael Pettersson wrote: > > Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption > > after a while in X + firefox. This still occurs with yesterday's HEAD > > of Linus' repo. 3.16 and ealier kernels a

Re: [BISECTED] 3.17-rc1 radeon screen corruption due to Always flush the HDP cache before submitting a CS to the GPU

Michel Dänzer writes: On 30.08.2014 22:59, Mikael Pettersson wrote: Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption after a while in X + firefox. This still occurs with yesterday's HEAD of Linus' repo. 3.16 and ealier kernels are fine. I ran a bisect

Re: bit fields && data tearing

Benjamin Herrenschmidt writes: > On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote: > > > Apologies for hijacking this thread but I need to extend this discussion > > somewhat regarding what a compiler might do with adjacent fields in a > > structure. > > > > The tty subsystem

Re: bit fields data tearing

Benjamin Herrenschmidt writes: On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote: Apologies for hijacking this thread but I need to extend this discussion somewhat regarding what a compiler might do with adjacent fields in a structure. The tty subsystem defines a large

Re: [BISECTED] 3.17-rc1 radeon screen corruption due to "Always flush the HDP cache before submitting a CS to the GPU"

Michel Dänzer writes: > On 30.08.2014 22:59, Mikael Pettersson wrote: > > Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption > > after a while in X + firefox. This still occurs with yesterday's HEAD > > of Linus' repo. 3.16 and ealier kernels a

Re: [BISECTED] 3.17-rc1 radeon screen corruption due to Always flush the HDP cache before submitting a CS to the GPU

Michel Dänzer writes: On 30.08.2014 22:59, Mikael Pettersson wrote: Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption after a while in X + firefox. This still occurs with yesterday's HEAD of Linus' repo. 3.16 and ealier kernels are fine. I ran a bisect

[BISECTED] 3.17-rc1 radeon screen corruption due to "Always flush the HDP cache before submitting a CS to the GPU"

Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption after a while in X + firefox. This still occurs with yesterday's HEAD of Linus' repo. 3.16 and ealier kernels are fine. I ran a bisect, which identified: commit 72a9987edcedb89db988079a03c9b9c65b6ec9ac Author: Michel

[BISECTED] 3.17-rc1 radeon screen corruption due to Always flush the HDP cache before submitting a CS to the GPU

Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption after a while in X + firefox. This still occurs with yesterday's HEAD of Linus' repo. 3.16 and ealier kernels are fine. I ran a bisect, which identified: commit 72a9987edcedb89db988079a03c9b9c65b6ec9ac Author: Michel

Re: rt_sigreturn rejects a substitute stack frame as invalid.

Steven Stewart-Gallus writes: > Hello, > > I'm not totally sure that GLibc's setcontext is safe to use in a > signal handler. So, I decided I was going to play things safe and let > rt_sigreturn switch stacks for me instead. However, rt_sigreturn seems > to reject my substitute stack frame

Re: rt_sigreturn rejects a substitute stack frame as invalid.

Steven Stewart-Gallus writes: Hello, I'm not totally sure that GLibc's setcontext is safe to use in a signal handler. So, I decided I was going to play things safe and let rt_sigreturn switch stacks for me instead. However, rt_sigreturn seems to reject my substitute stack frame as

[BUG] 3.17-rc1 radeon screen corruption and hang

On one of my machines, an Ivy Bridge desktop with a Radeon X550 (RV370) graphics card, 3.17-rc1 causes random screen corruption with X running. Eventually X stopped honoring mouse or keyboard clicks, and when I tried to reboot it via an ssh login from another machine, it hanged hard. 3.16 and

[BUG] 3.17-rc1 radeon screen corruption and hang

On one of my machines, an Ivy Bridge desktop with a Radeon X550 (RV370) graphics card, 3.17-rc1 causes random screen corruption with X running. Eventually X stopped honoring mouse or keyboard clicks, and when I tried to reboot it via an ssh login from another machine, it hanged hard. 3.16 and

Re: [RFC 0/2] __vdso_findsym

Andy Lutomirski writes: > The idea is to add AT_VDSO_FINDSYM pointing at __vdso_findsym. This > implements __vdso_findsym. > > This would make it easier for runtimes that don't otherwise implement > ELF loaders to use the vdso. > > Thoughts? I'm opposed to this based on the principle

Re: [RFC 0/2] __vdso_findsym

Andy Lutomirski writes: The idea is to add AT_VDSO_FINDSYM pointing at __vdso_findsym. This implements __vdso_findsym. This would make it easier for runtimes that don't otherwise implement ELF loaders to use the vdso. Thoughts? I'm opposed to this based on the principle that the

Re: rcu alignment warning tripping on m68k

Paul E. McKenney writes: > On Fri, May 30, 2014 at 11:29:41AM +1000, Greg Ungerer wrote: > > On 29/05/14 23:11, One Thousand Gnomes wrote: > > > On Thu, 29 May 2014 12:08:32 +1000 > > > Greg Ungerer wrote: > > > > > >> Hi All, > > >> > > >> Inside kernel/rcy/tree.c in __call_rcu() it

Re: rcu alignment warning tripping on m68k

Paul E. McKenney writes: On Fri, May 30, 2014 at 11:29:41AM +1000, Greg Ungerer wrote: On 29/05/14 23:11, One Thousand Gnomes wrote: On Thu, 29 May 2014 12:08:32 +1000 Greg Ungerer g...@uclinux.org wrote: Hi All, Inside kernel/rcy/tree.c in __call_rcu() it does an

Re: Q: uniqueness of pthread_t

Ulrich Windl writes: > Hi! > > I'm programming a little bit with pthreads in Linux. As I understand > pthread_t is an opaque type (a pointer address?) that cannot be mapped to > the kernel's TID easily. Anyway: Is it expected that when one thread > terminates and another thread is

Re: Q: uniqueness of pthread_t

Ulrich Windl writes: Hi! I'm programming a little bit with pthreads in Linux. As I understand pthread_t is an opaque type (a pointer address?) that cannot be mapped to the kernel's TID easily. Anyway: Is it expected that when one thread terminates and another thread is created (in

keyboard problems on Dell Latitude E6230

I'm having problems with the built-in keyboard on Dell Latitude E6230 laptops and Linux 3.12/3.13 kernels: - sometimes the keyboard just keeps sending the same key code, as if the key was held down permanently; sometimes that can be cured by pressing ^C or something, but often only a reboot

keyboard problems on Dell Latitude E6230

I'm having problems with the built-in keyboard on Dell Latitude E6230 laptops and Linux 3.12/3.13 kernels: - sometimes the keyboard just keeps sending the same key code, as if the key was held down permanently; sometimes that can be cured by pressing ^C or something, but often only a reboot

Re: [PATCH 0/5] ia64 ski emulator patches

Mikael Pettersson writes: > Mikulas Patocka writes: > > > > > > On Sat, 25 Jan 2014, Mikael Pettersson wrote: > > > > > My ski patches are in > <http://user.it.uu.se/~mikpe/linux/patches/ia64/ski-1.3.2/> > > > for now. I'll

Re: [PATCH 0/5] ia64 ski emulator patches

Mikael Pettersson writes: Mikulas Patocka writes: On Sat, 25 Jan 2014, Mikael Pettersson wrote: My ski patches are in http://user.it.uu.se/~mikpe/linux/patches/ia64/ski-1.3.2/ for now. I'll post the kernel patches to linux-ia64 @ vger in a few minutes

Re: [PATCH 0/5] ia64 ski emulator patches

Mikulas Patocka writes: > > > On Sat, 25 Jan 2014, Mikael Pettersson wrote: > > > My ski patches are in > > <http://user.it.uu.se/~mikpe/linux/patches/ia64/ski-1.3.2/> > > for now. I'll post the kernel patches to linux-ia64 @ vger in a f

RE: [PATCH 0/5] ia64 ski emulator patches

Luck, Tony writes: > Mikulas: > >> Here I'm sending some ia64 patches to make it work in the ski emulator. > >> This has been broken for a long time. > > Thanks - There are questions from time to time on how to test ia64 > for those people who do not have hardware. > > Mikael: > >

Re: [PATCH 0/5] ia64 ski emulator patches

Mikulas Patocka writes: > > > On Fri, 24 Jan 2014, Mikael Pettersson wrote: > > > Mikulas Patocka writes: > > > Hi > > > > > > Here I'm sending some ia64 patches to make it work in the ski emulator. > > > This has been bro

Re: [PATCH 0/5] ia64 ski emulator patches

Mikulas Patocka writes: > > > On Fri, 24 Jan 2014, Mikael Pettersson wrote: > > > Mikulas Patocka writes: > > > Hi > > > > > > Here I'm sending some ia64 patches to make it work in the ski emulator. > > > This has been bro

Re: [PATCH 0/5] ia64 ski emulator patches

Mikulas Patocka writes: On Fri, 24 Jan 2014, Mikael Pettersson wrote: Mikulas Patocka writes: Hi Here I'm sending some ia64 patches to make it work in the ski emulator. This has been broken for a long time. Thanks. I've recently started running 3.x

Re: [PATCH 0/5] ia64 ski emulator patches

Mikulas Patocka writes: On Fri, 24 Jan 2014, Mikael Pettersson wrote: Mikulas Patocka writes: Hi Here I'm sending some ia64 patches to make it work in the ski emulator. This has been broken for a long time. Thanks. I've recently started running 3.x

RE: [PATCH 0/5] ia64 ski emulator patches

Luck, Tony writes: Mikulas: Here I'm sending some ia64 patches to make it work in the ski emulator. This has been broken for a long time. Thanks - There are questions from time to time on how to test ia64 for those people who do not have hardware. Mikael: Thanks. I've

Re: [PATCH 0/5] ia64 ski emulator patches

Mikulas Patocka writes: On Sat, 25 Jan 2014, Mikael Pettersson wrote: My ski patches are in http://user.it.uu.se/~mikpe/linux/patches/ia64/ski-1.3.2/ for now. I'll post the kernel patches to linux-ia64 @ vger in a few minutes. /Mikael Thanks for the patches

Re: [PATCH 0/5] ia64 ski emulator patches

Mikulas Patocka writes: > Hi > > Here I'm sending some ia64 patches to make it work in the ski emulator. > This has been broken for a long time. Thanks. I've recently started running 3.x kernels on ia64 via ski, but I'm getting random kernel crashes with 3.13. I'll give your patches a try

Re: [PATCH 0/5] ia64 ski emulator patches

Mikulas Patocka writes: Hi Here I'm sending some ia64 patches to make it work in the ski emulator. This has been broken for a long time. Thanks. I've recently started running 3.x kernels on ia64 via ski, but I'm getting random kernel crashes with 3.13. I'll give your patches a try

Re: [BUG?] mtrr sanitizer fails on Latitude E6230

Yinghai Lu writes: > On Thu, Nov 7, 2013 at 12:25 AM, Mikael Pettersson > wrote: > > Yinghai Lu writes: > > > On Wed, Nov 6, 2013 at 1:16 AM, Mikael Pettersson > > wrote: > > > > I recently got a Dell Latitude E6230 (Ivy Bridge i7-3540M) an

Re: [BUG?] mtrr sanitizer fails on Latitude E6230

Yinghai Lu writes: On Thu, Nov 7, 2013 at 12:25 AM, Mikael Pettersson mikpeli...@gmail.com wrote: Yinghai Lu writes: On Wed, Nov 6, 2013 at 1:16 AM, Mikael Pettersson mikpeli...@gmail.com wrote: I recently got a Dell Latitude E6230 (Ivy Bridge i7-3540M) and noticed

Re: [BUG?] mtrr sanitizer fails on Latitude E6230

Yinghai Lu writes: > On Wed, Nov 6, 2013 at 1:16 AM, Mikael Pettersson > wrote: > > I recently got a Dell Latitude E6230 (Ivy Bridge i7-3540M) and noticed that > > the mtrr sanitizer failed on it: > > > > === snip === > > Linux version 3.12.0 (mikpe

  1   2   3   4   5   6   7   8   9   >