Reinoud Koornstra gmail.com> writes:
>
> Hi Everyone,
>
> Did anybody enounter the following compiler problem with linux 3.10.81?
> gcc version is 4.9.3 for mips.
>
> arch/mips/kernel/r4k_fpu.S: Assembler messages:
> arch/mips/kernel/r4k_fpu.S:59: Error: opcode not supported on this
> processo
Hi Everyone,
Did anybody enounter the following compiler problem with linux 3.10.81?
gcc version is 4.9.3 for mips.
arch/mips/kernel/r4k_fpu.S: Assembler messages:
arch/mips/kernel/r4k_fpu.S:59: Error: opcode not supported on this
processor: mips3 (mips3) `sdc1 $f0,272+0($4)'
arch/mips/kernel/r4k
On Sun, Apr 27, 2014 at 07:13:12PM +0200, Florian Kaiser wrote:
> Hello,
>
> Not sure if you did not include this for a reason in the latest 3.10.y
> (3.10.38, released 16 hours ago) or if you just missed it. In the latter case,
> please backport it.
>
> Patch from commit b04c46190219a4f845e46a45
Hello,
Not sure if you did not include this for a reason in the latest 3.10.y
(3.10.38, released 16 hours ago) or if you just missed it. In the latter case,
please backport it.
Patch from commit b04c46190219a4f845e46a459e3102137b7f6cac should apply with
some offsets but otherwise work as expected
Just FYI.
Our full tier tests have completed with no issues due to the sit or
ip6_tunnel modules. These patches appear to have solved our problems.
Nicolas, Thanks again for posting these!
-- Steve
On Fri, 31 Jan 2014 09:24:04 +0100
Nicolas Dichtel wrote:
> This problem was fixed upstream by
This reverts commit 22c3ec552c29cf4bd4a75566088950fe57d860c4.
This patch is not the right fix, it introduces a memory leak when a netns is
destroyed (the FB device is never deleted).
Signed-off-by: Nicolas Dichtel
Reported-by: Steven Rostedt
Tested-by: Steven Rostedt (and our entire MRG team)
This problem was fixed upstream by commit 1e9f3d6f1c40 ("ip6tnl: fix use after
free of fb_tnl_dev").
The upstream patch depends on upstream commit 0bd8762824e7 ("ip6tnl: add x-netns
support"), which was not backported into 3.10 branch.
First, explain the problem: when the ip6_tunnel module is unlo
This problem was fixed upstream by commit 9434266f2c64 ("sit: fix use after free
of fb_tunnel_dev").
The upstream patch depends on upstream commit 5e6700b3bf98 ("sit: add support of
x-netns"), which was not backported into 3.10 branch.
First, explain the problem: when the sit module is unloaded, s
This problem was fixed upstream by commit 1e9f3d6f1c40 ("ip6tnl: fix use after
free of fb_tnl_dev").
The upstream patch depends on upstream commit 0bd8762824e7 ("ip6tnl: add x-netns
support"), which was not backported into 3.10 branch.
First, explain the problem: when the ip6_tunnel module is unlo
This reverts commit 22c3ec552c29cf4bd4a75566088950fe57d860c4.
This patch is not the right fix, it introduces a memory leak when a netns is
destroyed (the FB device is never deleted).
Signed-off-by: Nicolas Dichtel
---
net/ipv6/ip6_tunnel.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/n
This problem was fixed upstream by commit 9434266f2c64 ("sit: fix use after free
of fb_tunnel_dev").
The upstream patch depends on upstream commit 5e6700b3bf98 ("sit: add support of
x-netns"), which was not backported into 3.10 branch.
First, explain the problem: when the sit module is unloaded, s
Le 19/12/2013 11:07, Luis Henriques a écrit :
On Tue, Dec 17, 2013 at 02:40:02PM -0500, David Miller wrote:
From: Nicolas Dichtel
Date: Fri, 13 Dec 2013 10:06:35 +0100
The upstream commit bb8140947a24 ("ip6tnl: allow to use rtnl ops on fb tunnel")
(backported into linux-3.10.y)
On Tue, Dec 17, 2013 at 02:40:02PM -0500, David Miller wrote:
> From: Nicolas Dichtel
> Date: Fri, 13 Dec 2013 10:06:35 +0100
>
> > The upstream commit bb8140947a24 ("ip6tnl: allow to use rtnl ops on fb
> > tunnel")
> > (backported into linux-3.10.y) l
3.10-stable review patch. If anyone has any objections, please let me know.
--
The upstream commit bb8140947a24 ("ip6tnl: allow to use rtnl ops on fb tunnel")
(backported into linux-3.10.y) left a bug which was fixed upstream by commit
1e9f3d6f1c40 ("ip6tnl: fix
On Tue, Dec 17, 2013 at 02:40:02PM -0500, David Miller wrote:
> From: Nicolas Dichtel
> Date: Fri, 13 Dec 2013 10:06:35 +0100
>
> > The upstream commit bb8140947a24 ("ip6tnl: allow to use rtnl ops on fb
> > tunnel")
> > (backported into linux-3.10.y) l
From: Nicolas Dichtel
Date: Fri, 13 Dec 2013 10:06:35 +0100
> The upstream commit bb8140947a24 ("ip6tnl: allow to use rtnl ops on fb
> tunnel")
> (backported into linux-3.10.y) left a bug which was fixed upstream by commit
> 1e9f3d6f1c40 ("ip6tnl: fix use after fre
The upstream commit bb8140947a24 ("ip6tnl: allow to use rtnl ops on fb tunnel")
(backported into linux-3.10.y) left a bug which was fixed upstream by commit
1e9f3d6f1c40 ("ip6tnl: fix use after free of fb_tnl_dev").
The problem is a bit different in linux-3.10.y, because
On Thu, Dec 12, 2013 at 07:06:57AM -0800, H. Peter Anvin wrote:
> On 12/12/2013 05:28 AM, Ingo Molnar wrote:
> >>
> >> The reason we use thread_info::flags is because we need to write
> >> TIF_NEED_RESCHED into it to wake up anyhow.
> >>
> >> Using another cacheline would mean the wakeup path would
On 12/12/2013 05:28 AM, Ingo Molnar wrote:
>>
>> The reason we use thread_info::flags is because we need to write
>> TIF_NEED_RESCHED into it to wake up anyhow.
>>
>> Using another cacheline would mean the wakeup path would need to write a
>> second cross cpu cacheline -- that is badness too.
>>
>>
* Peter Zijlstra wrote:
> On Wed, Dec 11, 2013 at 03:08:35PM -0800, H. Peter Anvin wrote:
> > On 12/11/2013 09:50 AM, Ingo Molnar wrote:
> > >
> > > Well, availability could be a problem too, if some CPU (real or
> > > virtual) implements MWAIT but not CLFLUSH.
> > >
> > > In theory we could
On Wed, Dec 11, 2013 at 03:08:35PM -0800, H. Peter Anvin wrote:
> On 12/11/2013 09:50 AM, Ingo Molnar wrote:
> >
> > Well, availability could be a problem too, if some CPU (real or
> > virtual) implements MWAIT but not CLFLUSH.
> >
> > In theory we could make mwait an alternatives variant and pa
I'm guessing there is an implicit or explicit wake-up somewhere that I managed
to miss. If it is implicit it could be hard to catch.
Mike Galbraith wrote:
>On Thu, 2013-12-12 at 06:57 +0100, Mike Galbraith wrote:
>> On Wed, 2013-12-11 at 21:45 -0800, H. Peter Anvin wrote:
>> > As in it hangs
On Thu, 2013-12-12 at 06:57 +0100, Mike Galbraith wrote:
> On Wed, 2013-12-11 at 21:45 -0800, H. Peter Anvin wrote:
> > As in it hangs at that point?
>
> Nope, it's still going.
>
> [1567.578340] pcc-cpufreq: (v1.10.00) driver loaded with frequency limits:
> 1064 MHz, 2266 MHz
>
> Funny, cont
On Wed, 2013-12-11 at 21:45 -0800, H. Peter Anvin wrote:
> As in it hangs at that point?
Nope, it's still going.
[1567.578340] pcc-cpufreq: (v1.10.00) driver loaded with frequency limits: 1064
MHz, 2266 MHz
Funny, continents move faster :) Maybe missing a write or two.
-Mike
--
To unsubscri
As in it hangs at that point?
Mike Galbraith wrote:
>On Wed, 2013-12-11 at 20:49 -0800, H. Peter Anvin wrote:
>> On 12/11/2013 08:25 PM, Mike Galbraith wrote:
>> > arch/x86/include/asm/mwait.h |4 ++--
>> > arch/x86/kernel/cpu/common.c |7 ---
>> > arch/x86/kernel/setup_percpu.c
On Wed, 2013-12-11 at 20:49 -0800, H. Peter Anvin wrote:
> On 12/11/2013 08:25 PM, Mike Galbraith wrote:
> > arch/x86/include/asm/mwait.h |4 ++--
> > arch/x86/kernel/cpu/common.c |7 ---
> > arch/x86/kernel/setup_percpu.c |1 +
> > 3 files changed, 7 insertions(+), 5 deletion
On Wed, 2013-12-11 at 20:49 -0800, H. Peter Anvin wrote:
> On 12/11/2013 08:25 PM, Mike Galbraith wrote:
> > arch/x86/include/asm/mwait.h |4 ++--
> > arch/x86/kernel/cpu/common.c |7 ---
> > arch/x86/kernel/setup_percpu.c |1 +
> > 3 files changed, 7 insertions(+), 5 deletion
On 12/11/2013 08:25 PM, Mike Galbraith wrote:
> arch/x86/include/asm/mwait.h |4 ++--
> arch/x86/kernel/cpu/common.c |7 ---
> arch/x86/kernel/setup_percpu.c |1 +
> 3 files changed, 7 insertions(+), 5 deletions(-)
>
> Index: linux-2.6/arch/x86/kernel/cpu/common.c
> ==
On Wed, 2013-12-11 at 16:52 -0800, H. Peter Anvin wrote:
> On 12/11/2013 03:14 PM, Borislav Petkov wrote:
> > On Wed, Dec 11, 2013 at 03:08:35PM -0800, H. Peter Anvin wrote:
> >> So I would like to propose that we switch to using a percpu variable
> >> which is a single cache line of nothing at al
On 12/11/2013 03:14 PM, Borislav Petkov wrote:
> On Wed, Dec 11, 2013 at 03:08:35PM -0800, H. Peter Anvin wrote:
>> So I would like to propose that we switch to using a percpu variable
>> which is a single cache line of nothing at all. It would only ever
>> be touched by MONITOR and for explicit wa
On Wed, Dec 11, 2013 at 03:08:35PM -0800, H. Peter Anvin wrote:
> So I would like to propose that we switch to using a percpu variable
> which is a single cache line of nothing at all. It would only ever
> be touched by MONITOR and for explicit wakeup. Hopefully that will
> resolve this problem wit
On 12/11/2013 09:50 AM, Ingo Molnar wrote:
>
> Well, availability could be a problem too, if some CPU (real or
> virtual) implements MWAIT but not CLFLUSH.
>
> In theory we could make mwait an alternatives variant and patch in the
> right combination of instructions? The CLFLUSH goes to the sam
On Wed, 11 Dec 2013, Len Brown wrote:
> For the record...
>
> intel_idle doesn't check that bit because it doesn't run on model 29 --
> the Xeon 7400 was the "Dunnington" 4-socket generation based on Core2.
Right, we wondered about the restricted model check
already. Interesting that this is a 4
For the record...
intel_idle doesn't check that bit because it doesn't run on model 29 --
the Xeon 7400 was the "Dunnington" 4-socket generation based on Core2.
Until now, i was not aware that this issue might apply to models other
than that one.
Checking w/ the HW guys...
thanks,
Len Brown, Int
* Peter Zijlstra wrote:
> On Wed, Dec 11, 2013 at 03:56:55PM +0100, Ingo Molnar wrote:
> >
> > * Borislav Petkov wrote:
> >
> > > On Wed, Dec 11, 2013 at 01:43:52PM +0100, Peter Zijlstra wrote:
> > > > Something like the below.. someone needs to double check and possibly
> > > > add SNB/IVB E
* Peter Zijlstra wrote:
> On Wed, Dec 11, 2013 at 04:09:11PM +0100, Ingo Molnar wrote:
> >
> > * Thomas Gleixner wrote:
> >
> > > On Wed, 11 Dec 2013, Ingo Molnar wrote:
> > > >
> > > > Another thing that is required I think is to issue a write barrier
> > > > before CLFLUSH instruction. By
* Peter Zijlstra wrote:
> On Wed, Dec 11, 2013 at 03:42:38PM +0100, Ingo Molnar wrote:
> > Another thing that is required I think is to issue a write barrier
> > before CLFLUSH instruction. By my (possibly incorrect ...) reading of
> > the documentation CLFLUSH does not appear to be ordered (a
On Wed, Dec 11, 2013 at 04:09:11PM +0100, Ingo Molnar wrote:
>
> * Thomas Gleixner wrote:
>
> > On Wed, 11 Dec 2013, Ingo Molnar wrote:
> > >
> > > Another thing that is required I think is to issue a write barrier
> > > before CLFLUSH instruction. By my (possibly incorrect ...) reading of
>
On Wed, Dec 11, 2013 at 03:42:38PM +0100, Ingo Molnar wrote:
> Another thing that is required I think is to issue a write barrier
> before CLFLUSH instruction. By my (possibly incorrect ...) reading of
> the documentation CLFLUSH does not appear to be ordered (at all), so
> it might execute befo
On Wed, Dec 11, 2013 at 03:56:55PM +0100, Ingo Molnar wrote:
>
> * Borislav Petkov wrote:
>
> > On Wed, Dec 11, 2013 at 01:43:52PM +0100, Peter Zijlstra wrote:
> > > Something like the below.. someone needs to double check and possibly
> > > add SNB/IVB EX parts if they're already available.
> >
On Wed, Dec 11, 2013 at 03:56:55PM +0100, Ingo Molnar wrote:
> I think CLFLUSH should be pretty universally available, IIRC
> graphics drivers were using it rather heavily in combination with
> write-combining MTRRs, both on Linux and on Windows.
... and it is also very expensive. So I don't think
* Thomas Gleixner wrote:
> On Wed, 11 Dec 2013, Ingo Molnar wrote:
> >
> > Another thing that is required I think is to issue a write barrier
> > before CLFLUSH instruction. By my (possibly incorrect ...) reading of
> > the documentation CLFLUSH does not appear to be ordered (at all), so
> >
On Wed, 11 Dec 2013, Ingo Molnar wrote:
>
> Another thing that is required I think is to issue a write barrier
> before CLFLUSH instruction. By my (possibly incorrect ...) reading of
> the documentation CLFLUSH does not appear to be ordered (at all), so
> it might execute before the modificatio
* Borislav Petkov wrote:
> On Wed, Dec 11, 2013 at 01:43:52PM +0100, Peter Zijlstra wrote:
> > Something like the below.. someone needs to double check and possibly
> > add SNB/IVB EX parts if they're already available.
>
> Right, our friends at Intel would need to tell us which families/models
* Peter Zijlstra wrote:
> On Wed, Dec 11, 2013 at 01:29:15PM +0100, Mike Galbraith wrote:
> > On Wed, 2013-12-11 at 12:52 +0100, Peter Zijlstra wrote:
> > > On Wed, Dec 11, 2013 at 12:38:39PM +0100, Borislav Petkov wrote:
> > > > Right, if it turns out that this is really the case and that this
On Wed, Dec 11, 2013 at 01:43:52PM +0100, Peter Zijlstra wrote:
> Something like the below.. someone needs to double check and possibly
> add SNB/IVB EX parts if they're already available.
Right, our friends at Intel would need to tell us which families/models
does AAI65 span... if, this is actual
On Wed, 2013-12-11 at 13:43 +0100, Peter Zijlstra wrote:
> On Wed, Dec 11, 2013 at 01:29:15PM +0100, Mike Galbraith wrote:
> > On Wed, 2013-12-11 at 12:52 +0100, Peter Zijlstra wrote:
> > > On Wed, Dec 11, 2013 at 12:38:39PM +0100, Borislav Petkov wrote:
> > > > Right, if it turns out that this i
On Wed, Dec 11, 2013 at 01:29:15PM +0100, Mike Galbraith wrote:
> On Wed, 2013-12-11 at 12:52 +0100, Peter Zijlstra wrote:
> > On Wed, Dec 11, 2013 at 12:38:39PM +0100, Borislav Petkov wrote:
> > > Right, if it turns out that this is really the case and that this
> > > erratum hasn't been fixed fo
On Wed, 2013-12-11 at 12:52 +0100, Peter Zijlstra wrote:
> On Wed, Dec 11, 2013 at 12:38:39PM +0100, Borislav Petkov wrote:
> > Right, if it turns out that this is really the case and that this
> > erratum hasn't been fixed for models later than 29 - we'd need the
> > additional model numbers to s
On Wed, Dec 11, 2013 at 12:38:39PM +0100, Borislav Petkov wrote:
> Right, if it turns out that this is really the case and that this
> erratum hasn't been fixed for models later than 29 - we'd need the
> additional model numbers to set X86_FEATURE_CLFLUSH_MONITOR correctly.
You also need: https://
On Wed, Dec 11, 2013 at 12:28:36PM +0100, Thomas Gleixner wrote:
> On Wed, 11 Dec 2013, Mike Galbraith wrote:
> > Alakazam..
> > Yup, magical gremlin repellent works on 8 socket DL980 too.
>
> Now here is a less magical version of the gremlin repellent.
>
> And just for the amusement value: The e
On Wed, 11 Dec 2013, Mike Galbraith wrote:
> Alakazam..
> Yup, magical gremlin repellent works on 8 socket DL980 too.
Now here is a less magical version of the gremlin repellent.
And just for the amusement value: The erratum for the series 7400
says:
AAI65. MONITOR/MWAIT May Have Excessive False
Alakazam..
pk cor CPU%c0 GHz TSC SMI%c1%c3%c6 CTMP %pc3 %pc6
0.17 2.01 2.26 0 0.02 99.82 0.00 49 99.55 0.00
0 0 0 0.95 1.45 2.26 2 0.43 98.62 0.00 48 98.48 0.00
1 0 8 0.24 1.99 2.26 2 0.02 99.75 0.00 38 99.68 0.00
On Tue, 10 Dec 2013, Thomas Gleixner wrote:
> On Tue, 10 Dec 2013, Mike Galbraith wrote:
> > vogelweide:~/:[130]# turbostat -P -i 60
> > pk cor CPU%c0 GHz TSC SMI%c1%c3%c6 CTMP %pc3 %pc6
> > 0.02 2.12 2.26 0 43.40 56.57 0.00 53 33.81 0.00
> > 0 0 0
* Thomas Gleixner wrote:
> On Tue, 10 Dec 2013, Mike Galbraith wrote:
> > vogelweide:~/:[130]# turbostat -P -i 60
> > pk cor CPU%c0 GHz TSC SMI%c1%c3%c6 CTMP %pc3 %pc6
> > 0.02 2.12 2.26 0 43.40 56.57 0.00 53 33.81 0.00
> > 0 0 0 0.23 2.10 2.2
On Tue, 10 Dec 2013, Mike Galbraith wrote:
> vogelweide:~/:[130]# turbostat -P -i 60
> pk cor CPU%c0 GHz TSC SMI%c1%c3%c6 CTMP %pc3 %pc6
> 0.02 2.12 2.26 0 43.40 56.57 0.00 53 33.81 0.00
> 0 0 0 0.23 2.10 2.26 5 65.47 34.30 0.00 52 10.69
* Mike Galbraith wrote:
> Hi Len,
>
> I'm unable to reproduce those DL980 results. I updated the kernel and
> config yesterday, and happened to run turbostat again.. and the box was
> nowhere near as quiet. I ended up spending all day futzing with the
> darn thing, checking various config/ker
* Mike Galbraith wrote:
> On Sat, 2013-12-07 at 11:45 -0500, Len Brown wrote:
> > >> It fixes that, except for my Q6600 box. Too bad mwait_idle() went away,
> > >> beloved old box doesn't play hints game, so it continues to flog itself.
> >
> >
> > Thanks for pointing this out, Mike!
> >
>
Hi Len,
I'm unable to reproduce those DL980 results. I updated the kernel and
config yesterday, and happened to run turbostat again.. and the box was
nowhere near as quiet. I ended up spending all day futzing with the
darn thing, checking various config/kernel combos, and none produced the
previ
On Sun, 2013-12-08 at 15:40 -0500, Len Brown wrote:
> > FWIW, my little x3550 (E5620) box is spending ~99% of its time in C3 per
> > powertop, deepest state it has.
>
> Please run turbostat, which always describes what the hardware does.
> Depending on the version of powertop and the hardware inv
> FWIW, my little x3550 (E5620) box is spending ~99% of its time in C3 per
> powertop, deepest state it has.
Please run turbostat, which always describes what the hardware does.
Depending on the version of powertop and the hardware involved,
it may be describing that the OS requested -- which is n
On Sat, 2013-12-07 at 03:00 -0500, Len Brown wrote:
> Hello Thomas,
>
> An idle WSM-EX box (40 Xeon cores) runs 50 Watts hotter after this patch:
>
> commit 7d1a941731fabf27e5fb6edbebb79fe856edb4e5
> Author: Thomas Gleixner
> Date: Thu Mar 21 22:50:03 2013 +0100
>
> x86: Use generic idle
On Sat, 2013-12-07 at 11:45 -0500, Len Brown wrote:
> >> It fixes that, except for my Q6600 box. Too bad mwait_idle() went away,
> >> beloved old box doesn't play hints game, so it continues to flog itself.
>
>
> Thanks for pointing this out, Mike!
>
> A Q6600 is a Kentsfield. I dug one of th
>> It fixes that, except for my Q6600 box. Too bad mwait_idle() went away,
>> beloved old box doesn't play hints game, so it continues to flog itself.
Thanks for pointing this out, Mike!
A Q6600 is a Kentsfield. I dug one of those up.
Indeed, the only idle capabilities it has are HALT
and old
On Sat, Dec 7, 2013 at 3:39 AM, Mike Galbraith wrote:
> On Sat, 2013-12-07 at 03:00 -0500, Len Brown wrote:
>
>> No, Linux-3.13-rc3 does not fix this issue, even though it contains
>> the following patch, claiming to address an issue with the commit above:
>>
>> commit ea8117478918a4734586d35ff530
Len,
On Sat, 7 Dec 2013, Len Brown wrote:
>
> How shall we proceed?
Can you please gather a function trace so I can see what the system is
doing? Preferrably with 3.13-rc3 so we have Peters fix included.
Please send it offlist or put it somehwere for download.
Thanks,
tglx
--
To unsubs
On Sat, 2013-12-07 at 03:00 -0500, Len Brown wrote:
> No, Linux-3.13-rc3 does not fix this issue, even though it contains
> the following patch, claiming to address an issue with the commit above:
>
> commit ea8117478918a4734586d35ff530721b682425be
> Author: Peter Zijlstra
> Date: Wed Sep 11 1
Hello Thomas,
An idle WSM-EX box (40 Xeon cores) runs 50 Watts hotter after this patch:
commit 7d1a941731fabf27e5fb6edbebb79fe856edb4e5
Author: Thomas Gleixner
Date: Thu Mar 21 22:50:03 2013 +0100
x86: Use generic idle loop
ie. the commit before this patch (aba92c9e2cf3042bf6efc68fa2e423
On Tue, 2013-07-30 at 13:13 -0400, Josef Bacik wrote:
> I've looked at all the places we do divides in this function and it
> doesn't look like we're doing this anywhere but I could be blind,
do_div seems a likely suspect...
/*
* stripe_nr counts the total number of stripes we ha
On Tue, Jul 30, 2013 at 11:07:30AM +0200, Geert Uytterhoeven wrote:
> On Tue, 30 Jul 2013, Thorsten Glaser wrote:
> > NEW problem: btrfs doesn’t work at all. I had to reboot my
> > buildd into 3.2 using echo s/u/s/o >/proc/sysrq-trigger as
> > the attempt to mount it left the system hanging there.
On Tue, 30 Jul 2013, Thorsten Glaser wrote:
> NEW problem: btrfs doesn’t work at all. I had to reboot my
> buildd into 3.2 using echo s/u/s/o >/proc/sysrq-trigger as
> the attempt to mount it left the system hanging there.
> [0.00] Linux version 3.10-1-m68k (debian-ker...@lists.debian.org)
> I don't see mei_me_pci_suspend() calling mei_disable_interrupts() and
> pci_disable_msi().
Suspend calls mei_reset with request for disabling interrupts
I'm pretty sure I do free_irq and I do disable_msi in the suspend (Hope we are
looking at the same code)
I don't see a call to mei_enable
On 07/10/2013 09:18 AM, Winkler, Tomas wrote:
>>> suspend complete.
>>>
>>> I can start bi-sect of this problem on intel-display scope if you
>>> would like me to. Please let me know if the bisect scope should be larger.
>>>
>>> -- Shuah
>>
>> I got finally an older system where this reproduces con
> > suspend complete.
> >
> > I can start bi-sect of this problem on intel-display scope if you
> > would like me to. Please let me know if the bisect scope should be larger.
> >
> > -- Shuah
>
> I got finally an older system where this reproduces consistently, I'm trying
> to
> root cause that n
On Sun, Jul 7, 2013 at 8:31 PM, Sören Brinkmann
wrote:
> Hi,
>
> since I updated to 3.10 my system freezes occasionally. Googling the
> messages in my kernel log (attached) make me suspect, that my problem
> might be related to the issue Shuah reported.
>
> So, I just wanted to check in, what the
On Mon, Jul 1, 2013 at 5:54 PM, Shuah Khan wrote:
> On 06/26/2013 04:24 PM, Shuah Khan wrote:
>> On 06/26/2013 04:12 PM, Winkler, Tomas wrote:
>>>
>>>
>
>>> 42f132f mei: me: clear interrupts on the resume path
>>> 2753ff5 mei: nfc: fix nfc device freeing
>>> 5e85b36 mei: init: Flush scheduled work
Hi All,
on my Core2 (x64) system with linux 3.9 i could suspend to disk (and
resume) correctly from my kde 4.10 environment.
Just upgrading to linux 3.10 resume got broken due to GPU driver.
more infos:
1) suspend to ram works perfectly (resume too of course)
2) suspend to disk works, resume
On 06/26/2013 04:24 PM, Shuah Khan wrote:
> On 06/26/2013 04:12 PM, Winkler, Tomas wrote:
>>
>>
>> 42f132f mei: me: clear interrupts on the resume path
>> 2753ff5 mei: nfc: fix nfc device freeing
>> 5e85b36 mei: init: Flush scheduled work before resetting the device
>>
>> Are you sure you have the
Hi all,
On Sun, 30 Jun 2013 16:09:59 -0700 Linus Torvalds
wrote:
>
> ...
So, lets all take a deep breath, go test what's in linux-next, resist the
urge to rebase/rewrite all those trees and then bury Linus under pull
requests.
--
Cheers,
Stephen Rothwells...@canb.auug.org.
nrad Rzeszutek Wilk (1):
drm/i915: make compact dma scatter lists creation work with
SWIOTLB backend.
Krishna Mohan (1):
libfcoe: Fix Conflicting FCFs issue in the fabric
Linus Lüssing (1):
bridge: fix switched interval for MLD Query types
Linus Torvalds (1):
Linux 3.10
Lo
On Sat, Jun 29, 2013 at 4:52 PM, Sergey Meirovich wrote:
>
> There was overheating issue, that caused forced power off in the
> middle of the first compile.
Ok, then the thing is easily explained by simply the filesystem being
shut down in an incomplete state. Sounds like the mkregtable binary
ha
On 30 June 2013 01:13, Linus Torvalds wrote:
> On Sat, Jun 29, 2013 at 2:07 PM, Sergey Meirovich
> wrote:
>>> (and possibly the
>>> mkregtable binary) and trying again might fix it.
>>
>> Removing mkregtable has indeed the compile issue for me. Thanks!
>
> Ok, so something failed at an earlier
On Sun, Jun 30, 2013 at 8:13 AM, Linus Torvalds
wrote:
> On Sat, Jun 29, 2013 at 2:07 PM, Sergey Meirovich
> wrote:
>>> (and possibly the
>>> mkregtable binary) and trying again might fix it.
>>
>> Removing mkregtable has indeed the compile issue for me. Thanks!
>
> Ok, so something failed at a
On Sat, Jun 29, 2013 at 2:07 PM, Sergey Meirovich wrote:
>> (and possibly the
>> mkregtable binary) and trying again might fix it.
>
> Removing mkregtable has indeed the compile issue for me. Thanks!
Ok, so something failed at an earlier build. That error is probably
long gone, though, since the
Hi Linus,
On 29 June 2013 21:11, Linus Torvalds wrote:
> On Sat, Jun 29, 2013 at 8:05 AM, Sergey Meirovich
> wrote:
>>
>> 3.10-rc7 doesn't compile for me
>>
>> rathamahata@piledriver /usr/local/src/linux-3.10-rc7 $ make -j1 bzImage
>> modules
>>
On Sat, Jun 29, 2013 at 8:05 AM, Sergey Meirovich wrote:
>
> 3.10-rc7 doesn't compile for me
>
> rathamahata@piledriver /usr/local/src/linux-3.10-rc7 $ make -j1 bzImage
> modules
> make[1]: Nothing to be done for `all'.
> make[1]: Nothing to be done for `relocs&
On 06/26/2013 04:12 PM, Winkler, Tomas wrote:
>
>
>>> Can you please send me the log part when this starts?
>>>
>>> Thanks
>>>
>>
>> It rolled over and I don't have prior messages. I tried reproducing twice and
>> didn't see it again. I will try a few more times and see if I can get it to
>> happe
> > Can you please send me the log part when this starts?
> >
> > Thanks
> >
>
> It rolled over and I don't have prior messages. I tried reproducing twice and
> didn't see it again. I will try a few more times and see if I can get it to
> happen
> again.
>
> This is what I could save before dm
On Tue, 25 Jun 2013 20:51:27 +
Shuah Khan wrote:
> On 06/25/2013 02:06 PM, Jesse Barnes wrote:
> > On Tue, 25 Jun 2013 19:59:28 +
> > Shuah Khan wrote:
> >
> >> On 06/25/2013 01:52 PM, Jesse Barnes wrote:
> >>> On Tue, 25 Jun 2013 21:37:37 +0200
> >>> Daniel Vetter wrote:
> >>>
> >>
> >
On 06/25/2013 02:57 PM, Tomas Winkler wrote:
> On Tue, Jun 25, 2013 at 11:51 PM, Shuah Khan wrote:
>>
>> With this patch warn_on went away. Resume worked. I started seeing:
>>
>> [ 78.733062] mei_me :00:16.0: unexpected reset: dev_state =
>> RESETTING
>> [ 78.733079] mei_me :00:16.0:
On Tue, Jun 25, 2013 at 11:51 PM, Shuah Khan wrote:
>
> On 06/25/2013 02:06 PM, Jesse Barnes wrote:
> > On Tue, 25 Jun 2013 19:59:28 +
> > Shuah Khan wrote:
> >
> >> On 06/25/2013 01:52 PM, Jesse Barnes wrote:
> >>> On Tue, 25 Jun 2013 21:37:37 +0200
> >>> Daniel Vetter wrote:
> >>>
> >>
> >
On 06/25/2013 02:06 PM, Jesse Barnes wrote:
> On Tue, 25 Jun 2013 19:59:28 +
> Shuah Khan wrote:
>
>> On 06/25/2013 01:52 PM, Jesse Barnes wrote:
>>> On Tue, 25 Jun 2013 21:37:37 +0200
>>> Daniel Vetter wrote:
>>>
>>
Adding more lists to cc + Jesse since he's the guilty one for the
On Tue, 25 Jun 2013 19:59:28 +
Shuah Khan wrote:
> On 06/25/2013 01:52 PM, Jesse Barnes wrote:
> > On Tue, 25 Jun 2013 21:37:37 +0200
> > Daniel Vetter wrote:
> >
>
> >>
> >> Adding more lists to cc + Jesse since he's the guilty one for the
> >> vt-switchless state restore stuff.
> >
> > Ye
On 06/25/2013 01:52 PM, Jesse Barnes wrote:
> On Tue, 25 Jun 2013 21:37:37 +0200
> Daniel Vetter wrote:
>
>>
>> Adding more lists to cc + Jesse since he's the guilty one for the
>> vt-switchless state restore stuff.
>
> Yeah, looks like we don't fetch the PLL state on resume from hibernate,
> lea
On Tue, 25 Jun 2013 21:37:37 +0200
Daniel Vetter wrote:
> On Tue, Jun 25, 2013 at 9:05 PM, Linus Torvalds
> wrote:
> > Adding the appropriate cc'd.. I'm not seeing why this would start
> > happening now, but there's been a number of commits that touch the
> > intel crtc 'active' state and hotplu
On Tue, Jun 25, 2013 at 9:05 PM, Linus Torvalds
wrote:
> Adding the appropriate cc'd.. I'm not seeing why this would start
> happening now, but there's been a number of commits that touch the
> intel crtc 'active' state and hotplug logic, so I'm assuming one of
> them is to blame.. Lots of small c
Adding the appropriate cc'd.. I'm not seeing why this would start
happening now, but there's been a number of commits that touch the
intel crtc 'active' state and hotplug logic, so I'm assuming one of
them is to blame.. Lots of small changes around
ironlake_crtc_mode_set() etc.
This warning seems
On 06/24/2013 09:27 AM, Linus Torvalds wrote:
> So this is hopefully the last -rc in the series, and things have
> indeed be calming down finally, so assuming that trend continues,
> we're all good.
>
> Which means that we still want more testing and people hollering if
> there are any regressions
On Sat, 22 Jun 2013 11:04:27 -1000 Linus Torvalds
wrote:
>
> So this is hopefully the last -rc in the series, and things have
> indeed be calming down finally, so assuming that trend continues,
> we're all good.
And you are all going to resist rebasing your trees (for no apparent
reason) this cl
move notifier from list before freeing it
Laurent Pinchart (1):
drm/prime: Honor requested file flags when exporting a buffer
Li Zhong (1):
nohz: Fix notifier return val that enforce timekeeping
Linus Torvalds (1):
Linux 3.10-rc7
Magnus Damm (1):
ARM: 7756/1: zImage/vi
1 - 100 of 145 matches
Mail list logo
