On Fri, 26 Jun 2015, Darren Hart wrote:
> On Thu, Nov 27, 2014 at 07:13:10PM +0100, Julia Lawall wrote:
> >
> >
> > On Mon, 24 Nov 2014, SF Markus Elfring wrote:
> >
> > > >> This issue was detected by using the Coccinelle software.
> > > >
> > > > What script was used ?
> > >
> > > A semanti
If the CONFIG_DEBUG_FS is not selected, compilation of the
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c provides two warnings that
amdgpu_debugfs_regs_init and amdgpu_debugfs_regs_cleanup are used but
never defined. And as result:
ERROR: "amdgpu_debugfs_regs_cleanup" [drivers/gpu/drm/amd/amdgpu/amdg
On 2015/06/25 19:37, Wang Nan wrote:
> Before this patch, add_perf_probe_events() init symbol maps only for
> uprobe if the first pev passed to it is a uprobe event. However, with
> the incoming BPF uprobe support, now it will be possible to pass an
> array with combined kprobe and uprobe events to
Make sure that return value of all SMBIOS calls are properly checked and
do not continue of processing (received) information if call failed.
Also do not chache hwswitch wireless state as it can be changed at runtime
(e.g from userspace smbios applications).
Signed-off-by: Pali Rohár
---
Changes
On 2015/6/27 15:29, Masami Hiramatsu wrote:
On 2015/06/25 19:37, Wang Nan wrote:
Before this patch, add_perf_probe_events() init symbol maps only for
uprobe if the first pev passed to it is a uprobe event. However, with
the incoming BPF uprobe support, now it will be possible to pass an
array
On 6/26/15 11:44 PM, He Kuang wrote:
@@ -1141,13 +1141,13 @@ kprobe_perf_func(struct trace_kprobe *tk, struct
pt_regs *regs)
int size, __size, dsize;
int rctx;
- if (prog && !trace_call_bpf(prog, regs))
- return;
-
head = this_cpu_ptr(call->perf_event
On Sat, Jun 27, 2015 at 4:39 AM, Guenter Roeck wrote:
> The code depends on CLKDEV_LOOKUP since commit 225d68d852f1 ("staging:
> board: Add support for devices with complex dependencies").
>
> Related build error (powerpc:allmodconfig):
>
> drivers/built-in.o: In function `.board_staging_register_
On Fri, Jun 26, 2015 at 04:15:24PM +0300, Dan Carpenter wrote:
> I've sent my review script out a few times before but we have some new
> reviewers in staging who maybe haven't tried them.
Thanks Dan. It will be of great help.
regards
sudip
--
To unsubscribe from this list: send the line "unsubscr
* Linus Torvalds wrote:
> On Fri, Jun 26, 2015 at 9:01 AM, Tejun Heo wrote:
> >
> > Ooh, it isn't in mainline yet but pulling rcu tree will cause a silent
> > conflict with this pull request which leads to build failure.
>
> I tend to try to do a full "make allmodconfig" build between all pull
On Sat, 2015-06-27 at 08:25 +0200, Mike Galbraith wrote:
> Hi Ingo,
>
> My i7-4790 box is having one hell of a time with this merge window, is
> dead in the water.
BIOS setting "Limit CPUID Maximum" upsets new fpu code mightily.
-Mike
--
To unsubscribe from this list: send the line "uns
* Mike Galbraith wrote:
> Hi Ingo,
>
> My i7-4790 box is having one hell of a time with this merge window, is
> dead in the water. The netconsole log below is v4.1-7254-gc13c81006314,
> but trouble begins at bisected point much earlier. If I turn off kvm,
> such that I can kinda sorta boot, s
On Fri, Jun 26, 2015 at 06:09:03PM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.1.1 release.
> There are 11 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
* Mike Galbraith wrote:
> On Sat, 2015-06-27 at 08:25 +0200, Mike Galbraith wrote:
> > Hi Ingo,
> >
> > My i7-4790 box is having one hell of a time with this merge window, is
> > dead in the water.
>
> BIOS setting "Limit CPUID Maximum" upsets new fpu code mightily.
Ok, that's interesting. Mi
Hi Wang,
On 2015/06/27 16:34, Wangnan (F) wrote:
>
>
> On 2015/6/27 15:29, Masami Hiramatsu wrote:
>> On 2015/06/25 19:37, Wang Nan wrote:
>>> Before this patch, add_perf_probe_events() init symbol maps only for
>>> uprobe if the first pev passed to it is a uprobe event. However, with
>>> the in
* Prarit Bhargava wrote:
> Customers write system monitoring software for single systems as well as
> clusters. In load-balancing software it is useful to know how "busy" a
> core is. Unfortunately the only way to get this data is to run as root,
> or use setcap to allow userspace access for p
* Ingo Molnar wrote:
> So what's wrong with exposing them as a simplified PMU driver?
>
> That way we only expose the ones we want to - plus tooling can use all the
> rich
> perf features that can be used around this. (sampling, counting, call chains,
> etc.)
See below code from Andy that e
Maps for JIT is helpful for symbols-parsing for anon-executable-memory.
What we need to do is to add (START, SIZE, symbolname) to /tmp/perf-%d.map
(%d = pid of process), and perf would parse symbol located in this area
according to /tmp/perf-%d.map. It works well for normal mmap.
However, when we
On 2015/06/27 15:44, He Kuang wrote:
> When we add a kprobe point and record events by perf, the execution path
> of all threads on each cpu will enter this point, but perf may only
> record events on a particular thread or cpu at this kprobe point, a
> check on call->perf_events list filters out t
On Sat, 2015-06-27 at 10:25 +0200, Ingo Molnar wrote:
> * Mike Galbraith wrote:
>
> > On Sat, 2015-06-27 at 08:25 +0200, Mike Galbraith wrote:
> > > Hi Ingo,
> > >
> > > My i7-4790 box is having one hell of a time with this merge window, is
> > > dead in the water.
> >
> > BIOS setting "Limit C
On Fri, Jun 26, 2015 at 05:33:22PM +0800, Zhu Guihua wrote:
> The following lockdep warning occurrs when running with latest kernel:
> [3.178000] [ cut here ]
> [3.183000] WARNING: CPU: 128 PID: 0 at kernel/locking/lockdep.c:2755
> lockdep_trace_alloc+0xdd/0xe0()
>
On Fri, Jun 26, 2015 at 06:38:20PM -0700, Michel Lespinasse wrote:
> Hi Peter,
>
> I am getting a minor issue trying to boot a lockdep enabled x86_64
> kernel with >64 CPUs.
>
> The kernel boots the first 64 CPUs without issues, but then complains
> that lockdep wants to allocate memory while sta
On Fri, Jun 26, 2015 at 04:44:14PM +0100, Andy Lutomirski wrote:
> On Fri, Jun 26, 2015 at 8:29 AM, Will Deacon wrote:
> > On Fri, Jun 26, 2015 at 04:18:59PM +0100, Andy Lutomirski wrote:
> >> On Fri, Jun 26, 2015 at 7:58 AM, Will Deacon wrote:
> >> > (CC'ing Andy, since the removal of VDSO_PRELI
On Fri, Jun 26, 2015 at 06:08:42PM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.0.7 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
On 2015/6/27 16:49, Hou Pengyang wrote:
Maps for JIT is helpful for symbols-parsing for anon-executable-memory.
What we need to do is to add (START, SIZE, symbolname) to /tmp/perf-%d.map
(%d = pid of process), and perf would parse symbol located in this area
according to /tmp/perf-%d.map. It work
Commit 922d0e4d9f04 ("perf tools: Adjust symbols in VDSO") changed the
ELF symbol parsing so that the vDSO is treated the same as ET_EXEC and
ET_REL binaries despite being an ET_DYN. This was a partial workaround
to deal with older x86 vDSOs being prelinked at a high address that
didn't correspond
On 06/26/2015 05:25 PM, Xi Wang wrote:
Currently "ALU_END_FROM_BE 32" and "ALU_END_FROM_LE 32" do not test if
the upper bits of the result are zeros (the arm64 JIT had such bugs).
Extend the two tests to catch this.
Cc: Alexei Starovoitov
Signed-off-by: Xi Wang
Thanks for extending the test
Greetings,
We are an Investment company that invites you to partner with us and benefit in
our new Loan and Project funding program. We offer flexible loans and funding
for
various projects by passing the usual rigorous procedures.This Funding program
allows a client to enjoy low interest p
On Sat, Jun 27, 2015 at 10:55:28AM +0200, Mike Galbraith wrote:
> Yup, that made it not care about the BIOS setting.. again.
Does it say
"x86/fpu: Legacy x87 FPU detected."
with Ingo's patch?
Or do you see that "x86/fpu: Enabled xstate features... " print out from
the end of fpu__init_s
On Fri, Jun 26, 2015 at 06:08:23PM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.82 release.
> There are 5 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
From: Jan Kiszka
migrate_timers is invoked with preemption enabled. Therefore we have to
get/put the cpu-local variable tvec_bases like before commit 0eeda71bc3.
This fixes
BUG: using smp_processor_id() in preemptible [] code: bash/4917
caller is debug_smp_processor_id+0x17/0x19
CPU: 0
> Julia, do you have any particular objection to this specific patch?
> I didn't see a reason to prevent it going in.
Thanks for your interest around this concrete update suggestion.
* Would you like to distinguish the consequences a bit more
for results from the application of the semantic pat
On Fri, Jun 26, 2015 at 06:08:22PM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.46 release.
> There are 17 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know
On Sat, Jun 27, 2015 at 03:32:40AM -0700, Michel Lespinasse wrote:
> Yes, tried this successfully both with <64 and >64 CPUs, this does get
> rid of the lockdep warning for me.
Thanks, I'll add your Tested-by to the patch.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you repl
On Sat, Jun 27, 2015 at 11:55:49AM +0200, Jan Kiszka wrote:
> From: Jan Kiszka
>
> migrate_timers is invoked with preemption enabled. Therefore we have to
> get/put the cpu-local variable tvec_bases like before commit 0eeda71bc3.
>
> This fixes
>
> BUG: using smp_processor_id() in preemptible [
On Sat, 2015-06-27 at 11:37 +0200, Borislav Petkov wrote:
> On Sat, Jun 27, 2015 at 10:55:28AM +0200, Mike Galbraith wrote:
> > Yup, that made it not care about the BIOS setting.. again.
>
> Does it say
>
> "x86/fpu: Legacy x87 FPU detected."
>
> with Ingo's patch?
Nope.
> Or do you see
--
I am very sorry If I interfere into your privacy,i will like to get
acquainted with you. I will appreciate if granted this Privilege to know
you more. Get back to me for formal introduction ,waiting earnestly to
read from you. ( ezzahzuw...@hotmail.com )
Ezzah
--
To unsubscribe from this
On 2015/6/27 16:30, Masami Hiramatsu wrote:
Hi Wang,
On 2015/06/27 16:34, Wangnan (F) wrote:
On 2015/6/27 15:29, Masami Hiramatsu wrote:
On 2015/06/25 19:37, Wang Nan wrote:
Before this patch, add_perf_probe_events() init symbol maps only for
uprobe if the first pev passed to it is a uprob
On 2015-06-27 13:00, Borislav Petkov wrote:
> On Sat, Jun 27, 2015 at 11:55:49AM +0200, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> migrate_timers is invoked with preemption enabled. Therefore we have to
>> get/put the cpu-local variable tvec_bases like before commit 0eeda71bc3.
>>
>> This fixes
>
On Sat, Jun 27, 2015 at 01:19:24PM +0200, Jan Kiszka wrote:
> Oh, there is a fix already. It's just the same: both implicitly
> disable preemption via get_cpu_ptr/var, look at the macros.
Ah, yes.
/me goes to the coffee machine to make eyes open.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim
Hi Lina,
On Sat, Jun 27, 2015 at 6:05 AM, Lina Iyer wrote:
> Hi Ohad,
>
> Any comments?
Sorry, I was under the impression the discussion with Bjorn is still open.
Like Bjorn, I'm not so sure too we want to bind a specific lock to the
RAW capability since this is not a lock-specific hardware det
Hi Pali,
I've just noticed an issue with this patch. See the comment here below.
Gabriele
On Wednesday 29 April 2015 13:41:26 Pali Rohár wrote:
> This patch splits CONFIG_I8K compile option to SENSORS_DELL_SMM and
> CONFIG_I8K.
> Option SENSORS_DELL_SMM is now used to enable compilation of dell
Commit e1abf2cc8d5d80b41c4419368ec743ccadbb131e ("bpf: Fix the build on
BPF_SYSCALL=y && !CONFIG_TRACING kernels, make it more configurable")
updated the building condition of bpf_trace.o from CONFIG_BPF_SYSCALL
to CONFIG_BPF_EVENT, but the corresponding #ifdef controller in
ftrace_event.h for trac
From: Markus Elfring
Date: Sat, 27 Jun 2015 13:50:43 +0200
The pci_dev_put() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drive
By copying BPF related operation to uprobe processing path, this patch
allow users attach BPF programs to uprobes like what they are already
doing on kprobes.
After this patch, users are allowed to use PERF_EVENT_IOC_SET_BPF on a
uprobe perf event. Which make it possible to profile user space prog
Before this patch, add_perf_probe_events() init symbol maps only for
uprobe if the first 'struct perf_probe_event' passed to it is a uprobe
event. This is a trick because 'perf probe''s command line syntax
constrains the first elements of the probe_event arrays must be kprobes
if there is one.
How
Commit e1abf2cc8d5d80b41c4419368ec743ccadbb131e ("bpf: Fix the build on
BPF_SYSCALL=y && !CONFIG_TRACING kernels, make it more configurable")
updated the building condition of bpf_trace.o from CONFIG_BPF_SYSCALL
to CONFIG_BPF_EVENTS, but the corresponding #ifdef controller in
ftrace_event.h for tra
On Saturday 27 June 2015 13:34:30 Gabriele Mazzotta wrote:
> Hi Pali,
>
> I've just noticed an issue with this patch. See the comment here
> below.
>
> Gabriele
>
> On Wednesday 29 April 2015 13:41:26 Pali Rohár wrote:
> > @@ -750,8 +777,8 @@ static int __init i8k_init_hwmon(void)
> >
> > i
On Saturday 27 June 2015 14:47:16 Pali Rohár wrote:
> On Saturday 27 June 2015 13:34:30 Gabriele Mazzotta wrote:
> > Hi Pali,
> >
> > I've just noticed an issue with this patch. See the comment here
> > below.
> >
> > Gabriele
> >
> > On Wednesday 29 April 2015 13:41:26 Pali Rohár wrote:
> > > @
On Saturday 27 June 2015 14:55:40 Gabriele Mazzotta wrote:
> On Saturday 27 June 2015 14:47:16 Pali Rohár wrote:
> > On Saturday 27 June 2015 13:34:30 Gabriele Mazzotta wrote:
> > > Hi Pali,
> > >
> > > I've just noticed an issue with this patch. See the comment here
> > > below.
> > >
> > > Gabr
The X86_VERBOSE_BOOTUP enables informational output during the
decompression stage with the earlyprintk. If CONFIG_EARLY_PRINTK
is not set, there are no reasons to make CONFIG_X86_VERBOSE_BOOTUP
possible for the configuration.
Signed-off-by: Alexander Kuleshov
---
Changes since v1:
* style fixes
On Fri, Jun 26, 2015 at 04:06:55PM -0700, Darren Hart wrote:
> Julia, do you have any particular objection to this specific patch? I didn't
> see
> a reason to prevent it going in.
I hate these patches...
We're saying "these functions have sanity checks so let's pass nonsense
values to them, it'
When handling signalling char, claim the termios write lock before
signalling waiting readers and writers to prevent further i/o
before flushing the echo and output buffers. This prevents a
userspace signal handler which may output from racing the terminal
flush.
Reference: Bugzilla #99351 ("Outpu
On Saturday 27 June 2015 15:01:34 Pali Rohár wrote:
> On Saturday 27 June 2015 14:55:40 Gabriele Mazzotta wrote:
> > On Saturday 27 June 2015 14:47:16 Pali Rohár wrote:
> > > On Saturday 27 June 2015 13:34:30 Gabriele Mazzotta wrote:
> > > > Hi Pali,
> > > >
> > > > I've just noticed an issue with
Hi all,
I've tested the lastest linus git kernel, and this kernel
no longer boot on my armadeus apf27. The last line of the
log are (after, the kernel is stalled) :
[0.00] CPU identified as i.MX27, silicon rev 2.1
[0.00] Switching to timer-based delay loop, resolution 60ns
[0
As per Documentation/hwmon/sysfs-interface, hwmon name attributes must
not include '-', so replace 'dell-smm' with 'dell_smm'.
Fixes: 039ae58503f3 ("hwmon: Allow to compile dell-smm-hwmon driver without
/proc/i8k")
Signed-off-by: Gabriele Mazzotta
---
drivers/hwmon/dell-smm-hwmon.c | 2 +-
1 fi
This patch introduces the setup_builtin_cmdline function which appends or
overrides boot_command_line with the builtin_cmdline if CONFIG_CMDLINE_BOOL
is set.
Previously this functional was in the setup_arch, but we need to move
it for getting actual command line as early as possible in the
arch/x8
The early_printk function is usable only after the setup_early_printk will
be executed. We pass 'earlyprintk' through the kernel command line. So, it
means that earlyprintk will be usable only after the 'parse_early_param'
will be executed or in another words earlyprintk is usable only during early
This patch introduces the setup_builtin_cmdline function which appends or
overrides boot_command_line with the builtin_cmdline if CONFIG_CMDLINE_BOOL
is set.
Previously this functional was in the setup_arch, but we need to move
it for getting actual command line as early as possible in the
arch/x8
This patch adds the call of the setup_builtin_cmdline to
handle builtin command line before we will setup earlyprintk.
Signed-off-by: Alexander Kuleshov
---
arch/x86/kernel/head32.c | 1 +
arch/x86/kernel/head64.c | 1 +
arch/x86/kernel/setup.c | 2 --
3 files changed, 2 insertions(+), 2 deleti
The earlyprintk is usable only after the setup_early_printk will
be executed. We pass 'earlyprintk' through the kernel command line, so it
will be usable only after the 'parse_early_param' will be executed. This means
that we have usable earlyprintk only during early boot, kernel decompression
and
This patch is only for test of the full patch series. It provides
a couple calls of the early_printk function.
[Only for testing]
Signed-off-by: Alexander Kuleshov
---
arch/x86/kernel/setup.c | 1 +
init/main.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/x86/kernel/s
On Fri, Jun 26, 2015 at 8:30 PM, Luck, Tony wrote:
>>> I'm here to report two panics which hang forever (the machine cannot
>>> reboot). It is because mgag200 doesn't work in panic context. It sleeps and
>>> allocates memory non-atomically.
>>
>> This is the same for all drm drivers, the drm ato
sorry, forgot to add version to this patch, please skip this patch.
2015-06-27 19:46 GMT+06:00 Alexander Kuleshov :
> This patch introduces the setup_builtin_cmdline function which appends or
> overrides boot_command_line with the builtin_cmdline if CONFIG_CMDLINE_BOOL
> is set.
>
> Previously thi
In some cases some sessions aren't freed.
For example, a session is allocated and then
if an error occur, just a error value is returned
without freeing the session. So allocating and freeing
session have to be matched as a pair even if an error occur.
Signed-off-by: taeung
---
tools/perf/builti
On Sat, Jun 27, 2015 at 12:02:37AM -0400, Theodore Ts'o wrote:
>
> I would tend to agree. The weird thing though is that I haven't seen
> this problem myself, despite running multiple regression tests before
> I sent the pull request, as well as running it on my laptop and doing
> kernel compiles
On Sat, Jun 27, 2015 at 03:52:56PM +0200, Daniel Vetter wrote:
> Hm, what do you mean by fixing this in the allocator? I've made some
> rough sketch of the problem space in
> http://www.x.org/wiki/DRMJanitors/ under "Make panic handling work".
> Problem is that the folks which know what to do (drm
On Wed, Jun 24, 2015 at 05:12:12PM +, Appana Durga Kedareswara Rao wrote:
Please *fix* you MUA to wrap lines properly
> > > +
> > > + if (cfg->reset)
> > > + return xilinx_cdma_chan_reset(chan);
> > Why do you want to reset this externally, that sounds bad to me
> If someone (clie
From: Markus Elfring
Further update suggestions were taken into account after a patch was applied
from static source code analysis.
Markus Elfring (2):
Delete unnecessary checks before two function calls
One function call less in mac_ioctl() after error detection
drivers/staging/wilc1000/l
Hi Krzysztof,
On Tue, Jun 23, 2015 at 9:54 AM, Krzysztof Opasiak
wrote:
> Hello,
>
> On 06/23/2015 12:01 AM, Ruslan Bilovol wrote:
>>
>> Now when udc-core supports binding to specific UDC by passing
>> its name via 'udc_name' member of usb_gadget_driver struct,
>> switch to this generic approach.
From: Markus Elfring
Date: Sat, 27 Jun 2015 15:56:57 +0200
The functions kfree() and release_firmware() test whether their argument
is NULL and then return immediately.
Thus the test around the calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus
From: Markus Elfring
Date: Sat, 27 Jun 2015 16:00:59 +0200
The kfree() function was called in two cases by the mac_ioctl() function
during error handling even if the passed variable did not contain a pointer
for a valid data item.
* This implementation detail could be improved by the introductio
On Wed, Jun 24, 2015 at 05:12:13PM +, Appana Durga Kedareswara Rao wrote:
> > where is the hardware addr programmed? I can see you are using sg list
> > passed for porgramming one side of a transfer where is other side
> > programmed?
>
> The actual programming happens in the start_transfer(I
On 06/27/2015 06:22 AM, Gabriele Mazzotta wrote:
As per Documentation/hwmon/sysfs-interface, hwmon name attributes must
not include '-', so replace 'dell-smm' with 'dell_smm'.
Fixes: 039ae58503f3 ("hwmon: Allow to compile dell-smm-hwmon driver without
/proc/i8k")
Signed-off-by: Gabriele Mazzott
On Sat, Jun 27, 2015 at 5:40 PM, Vinod Koul wrote:
[...]
>> Please let me know if you are not clear.
> No sorry am not...
>
> I asked how the device address in configured. For both MM2S S2MM you are
> using sg for memory address, where are you getting device adress, are you
> assuming/hardcoding o
>> From: Markus Elfring
>> Date: Sat, 22 Nov 2014 12:55:28 +0100
>>
>> The free_tce_table() function tests whether its argument is NULL and then
>> returns immediately. Thus the test around the call is not needed.
>>
>> This issue was detected by using the Coccinelle software.
>>
>> Signed-off-by:
On Sat, Jun 27, 2015 at 08:29:16AM +0200, Jiri Kosina wrote:
> On Fri, 26 Jun 2015, Greg Kroah-Hartman wrote:
>
> > > I thought udev used a whitelist of devices known to work okay with
> > > autosuspend. Does it really turn on autosuspend for _every_ USB HID
> > > device that is marked as remov
On Fri, Jun 26, 2015 at 09:13:38PM -0600, Shuah Khan wrote:
> On 06/26/2015 07:09 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.1.1 release.
> > There are 11 patches in this series, all will be posted as a response
> > to this one. If anyone has any issue
On Sat, Jun 27, 2015 at 01:48:44PM +0530, Sudip Mukherjee wrote:
> On Fri, Jun 26, 2015 at 06:09:03PM -0700, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.1.1 release.
> > There are 11 patches in this series, all will be posted as a response
> > to this one.
On Fri, Jun 26, 2015 at 11:07:11PM -0700, Guenter Roeck wrote:
> On 06/26/2015 06:09 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 4.1.1 release.
> >There are 11 patches in this series, all will be posted as a response
> >to this one. If anyone has any issue
On Fri, Jun 26, 2015 at 11:29 PM, Fengguang Wu wrote:
> Ah it has been reported, sorry for the duplicated report!
No problem. It was a good catch -- this bug seems to be quite
dependent on kernel config.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
Hi Peter,
On 06/25/2015 12:30 AM, Peter Hung wrote:
Add New Fintek SuperIO F81866(0x1010) & F71868(0x1106)
with H/W Monitor functions.
Signed-off-by: Peter Hung
---
drivers/hwmon/f71882fg.c | 50 ++--
1 file changed, 36 insertions(+), 14 deletions
On Sat, 27 Jun 2015, Jan Kiszka wrote:
> > Please explain _in detail_ what you mean with "changing a power button to a
> > reset button by acessing the SSMS ACPI method in a X121e".
> >
> > Are we trigering a bug somewhere that crashes the x121e and causes it to
> > reboot?
>
> Well, there aren't
On Sat, Jun 27, 2015 at 1:39 AM, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
>> So what's wrong with exposing them as a simplified PMU driver?
>>
>> That way we only expose the ones we want to - plus tooling can use all the
>> rich
>> perf features that can be used around this. (sampling, coun
On Sat, Jun 27, 2015 at 1:14 AM, Akinobu Mita wrote:
> Akinobu Mita wrote:
>> 2015-06-26 0:40 GMT+09:00 Ming Lei :
>> > On Thu, 25 Jun 2015 21:49:43 +0900
>> > Akinobu Mita wrote:
>> >> For example, there is a single hw queue (hctx) and two CPU queues
>> >> (ctx0 for CPU0, and ctx1 for CPU1). N
Salve
moto, mac Laptop, Kamera, Telefon
samsung 6, € 320
w eb: isgayre. com
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
On Sat, Jun 27, 2015 at 02:35:56PM +1000, Stephen Rothwell wrote:
> Hi Linus,
>
> On Fri, 26 Jun 2015 20:18:10 -0700 Linus Torvalds
> wrote:
> >
> > On Fri, Jun 26, 2015 at 9:01 AM, Tejun Heo wrote:
> > >
> > > Ooh, it isn't in mainline yet but pulling rcu tree will cause a silent
> > > conflic
On 06/22/2015 01:43 PM, Vivien Didelot wrote:
Hi Guenter,
On Jun 22, 2015, at 12:53 PM, Guenter Roeck li...@roeck-us.net wrote:
On Wed, Jun 17, 2015 at 06:58:59PM -0400, Vivien Didelot wrote:
Introduce a new struct max63xx_platform_data to support MAX63xx watchdog
chips connected via GPIO. A p
From: Markus Elfring
Date: Sat, 27 Jun 2015 18:12:14 +0200
The cleanup_one_si() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
dr
On Saturday 27 June 2015 16:39:09 Guenter Roeck wrote:
> On 06/27/2015 06:22 AM, Gabriele Mazzotta wrote:
> > As per Documentation/hwmon/sysfs-interface, hwmon name attributes
> > must not include '-', so replace 'dell-smm' with 'dell_smm'.
> >
> > Fixes: 039ae58503f3 ("hwmon: Allow to compile del
On Sat, 27 Jun 2015, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sat, 27 Jun 2015 16:00:59 +0200
>
> The kfree() function was called in two cases by the mac_ioctl() function
> during error handling even if the passed variable did not contain a pointer
> for a valid data item.
>
> *
On Sat, Jun 27, 2015 at 10:09:28AM +0200, Ingo Molnar wrote:
>
> * Linus Torvalds wrote:
>
> > On Fri, Jun 26, 2015 at 9:01 AM, Tejun Heo wrote:
> > >
> > > Ooh, it isn't in mainline yet but pulling rcu tree will cause a silent
> > > conflict with this pull request which leads to build failure.
Let me try to summarize some of the approaches with their pros and cons:
--- percpu segment ---
This is probably the simplest and might make sense regardless.
cmpxchg can be used to do an atomic push onto a linked list. I think
that unlocked cmpxchg16b can be used to get an atomic pop. (You'd
h
> From: Markus Elfring
> Date: Wed, 19 Nov 2014 14:24:20 +0100
>
> The pci_dev_put() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus E
On Fri, Jun 26, 2015 at 11:56 PM, Herbert Xu
wrote:
>
> So I think Tadeusz's patch is the simplest fix for 4.2. Could you
> please test it to see if it makes your warning go away?
Seems to silence it here.
I get the feeling that the patch is still wrong - why are not the
*tests* run at late tim
The casts are safe, since those conditions are only evaluated when sz >= 0.
Signed-off-by: Роман Донченко
---
arch/x86/include/asm/uaccess.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index a8df874..4c47
Hi Philippe,
On Sat, Jun 27, 2015 at 10:21 AM, Philippe Reynes wrote:
> Hi all,
>
> I've tested the lastest linus git kernel, and this kernel
> no longer boot on my armadeus apf27. The last line of the
> log are (after, the kernel is stalled) :
>
> [0.00] CPU identified as i.MX27, silicon
>> From: Markus Elfring
>> Date: Wed, 4 Feb 2015 21:54:45 +0100
>>
>> The functions phy_power_on() and vunmap() perform also input
>> parameter validation. Thus the test around their calls is not needed.
>>
>> This issue was detected by using the Coccinelle software.
>>
>> Signed-off-by: Markus El
Hi Fabio,
On 27/06/15 19:05, Fabio Estevam wrote:
Hi Philippe,
On Sat, Jun 27, 2015 at 10:21 AM, Philippe Reynes wrote:
Hi all,
I've tested the lastest linus git kernel, and this kernel
no longer boot on my armadeus apf27. The last line of the
log are (after, the kernel is stalled) :
[0
On Sat, Jun 27, 2015 at 2:26 PM, Philippe Reynes wrote:
> I've looked the code in drivers/clocksource/timer-imx-gpt.c, in the
> definition
> of imx_gpt_type, there is :
> GPT_TYPE_IMX21, /* i.MX21/27 */
>
> So I've done a little change in your patch, I've used imx21_timer_init_dt
On 06/26/2015 03:20 PM, Davidlohr Bueso wrote:
On Thu, 2015-06-25 at 08:37 -0600, Jens Axboe wrote:
- Code consolidation and cleanups from Christoph.
Andrew, it seems your fix for gcc never went in. I am hitting it in
Linus' tree.
https://urldefense.proofpoint.com/v1/url?u=http://www.
1 - 100 of 182 matches
Mail list logo
