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
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
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
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
>
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:
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
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
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
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
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
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
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
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
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
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
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:
> >
&
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(
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
> >
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
> >
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
> >
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
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
> &
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
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:
> >
&
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
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
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
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.
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.
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.
>
>
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.
>
>
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
> > >
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
> > >
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
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
> >>
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.
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.
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
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.
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> >>
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
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
> > >
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
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
> > >
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
> >
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
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
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
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
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
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
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
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
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
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
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 - 100 of 874 matches
Mail list logo