hey kernel info about patches

2016-03-10 Thread Xavier REEVIL 
hello everyones,
 i wanted to know if the kernel Debian 3.16.7-ckt20-1+deb8u4 (2016-02-29)
have been patched like the 4.1  for the intel atom .
Because before i haved linux mint , where i updated the kernel manualy to
the latest stable and it was less heat and it gain  more battery life for
my laptop.
So i let this links to explain what i was talking

thanks for reading

https://www.linux.com/news/embedded-mobile/mobile-linux/837216-linux-41-speeds-up-intel-atom-soc

http://lkml.iu.edu/hypermail/linux/kernel/1504.3/00809.html

Processed: Re: Bug#817816: System freeze with CPU hotplug

2016-03-10 Thread Debian Bug Tracking System 
Processing control commands:

> reopen -1
Bug #817816 {Done: Ben Hutchings } 
[linux-image-4.4.0-1-amd64] System freeze with CPU hotplug
Bug reopened
Ignoring request to alter fixed versions of bug #817816 to the same values 
previously set
> severity -1 normal
Bug #817816 [linux-image-4.4.0-1-amd64] System freeze with CPU hotplug
Severity set to 'normal' from 'critical'

-- 
817816: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817816
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#817816: System freeze with CPU hotplug

2016-03-10 Thread Ben Hutchings 
Control: reopen -1
Control: severity -1 normal

On Fri, 2016-03-11 at 01:12 +0100, Harry Junior wrote:
> On Thu, 10 Mar 2016 17:34:54 + Ben Hutchings  wrote:
> > 
> > On Thu, 2016-03-10 at 17:32 +0100, Harry Junior wrote:
> > > 
> > > Package: linux-image-4.4.0-1-amd64
> > > Version: 4.4.4-1
> > > Severity: critical
> > > Justification: renders system unusable
> > > 
> > > 
> > > When I run the following commands, the system freezes:
> > > 
> > > # echo 0 | tee /sys/devices/system/cpu/cpu*/online && echo 1 | sudo
> > > tee /sys/devices/system/cpu/cpu*/online
> > > 
> > > The system freezes randomly when the CPUs are being onlined or
> > > offlined. The system is installed on a VMware virtual machine with 4
> > > processors. Here's a stacktrace of the infinite loop:
> > [...]
> > 
> > You just asked to offline all CPUs, making the system unusable. Â I
> > don't see any bug here.
> I'm sorry to disagree, but the CPU0 can't be offlined and remains online:
[...]

Depending on the configuration, it may be possible to offline CPU0.
However, I have been informed that the kernel still prevents offlining
the last CPU - or at least it is supposed to.

So I'm reopening this, but correcting the severity.  ("renders system
unusable" does *not* mean the system hangs or crashes, it means the
system becomes unbootable or otherwise persistently broken.)

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.

signature.asc
Description: This is a digitally signed message part

Bug#812540: Add ARCH_HISI for Lemaker HiKey support

2016-03-10 Thread Martin Michlmayr 
* Ian Campbell  [2016-01-25 09:57]:
> > Please enable it so we can add HiKey support to Debian.
> 
> I suppose it will need more than just ARCH_HISI. Are you able to identify
> the full set of options (e.g. drivers and such) which are needed to make
> useful Lemaker support? If so I'd appreciate it (if not I can probably try
> and dig those out myself, but it might take me a while to around to it).

This might be a good starting point:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1098644.html

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#817816: System freeze with CPU hotplug

2016-03-10 Thread Harry Junior 
On Thu, 10 Mar 2016 17:34:54 + Ben Hutchings  wrote:
> On Thu, 2016-03-10 at 17:32 +0100, Harry Junior wrote:
>> Package: linux-image-4.4.0-1-amd64
>> Version: 4.4.4-1
>> Severity: critical
>> Justification: renders system unusable
>> 
>> 
>> When I run the following commands, the system freezes:
>> 
>> # echo 0 | tee /sys/devices/system/cpu/cpu*/online && echo 1 | sudo
>> tee /sys/devices/system/cpu/cpu*/online
>> 
>> The system freezes randomly when the CPUs are being onlined or
>> offlined. The system is installed on a VMware virtual machine with 4
>> processors. Here's a stacktrace of the infinite loop:
> [...]
> 
> You just asked to offline all CPUs, making the system unusable. Â I
> don't see any bug here.

I'm sorry to disagree, but the CPU0 can't be offlined and remains online:

$ ls -l /sys/devices/system/cpu/ | grep cpu | head -4
drwxr-xr-x 6 root root0 Mar 10 18:41 cpu0
drwxr-xr-x 6 root root0 Mar 10 18:41 cpu1
drwxr-xr-x 6 root root0 Mar 10 18:41 cpu2
drwxr-xr-x 6 root root0 Mar 10 18:41 cpu3

$ ls -l /sys/devices/system/cpu/cpu*/online
-rw-r--r-- 1 root root 4096 Mar 10 18:40 /sys/devices/system/cpu/cpu1/online
-rw-r--r-- 1 root root 4096 Mar 10 18:40 /sys/devices/system/cpu/cpu2/online
-rw-r--r-- 1 root root 4096 Mar 10 18:40 /sys/devices/system/cpu/cpu3/online

Bug#817816: marked as done (System freeze with CPU hotplug)

2016-03-10 Thread Debian Bug Tracking System 
Your message dated Thu, 10 Mar 2016 17:34:54 +
with message-id <1457631294.3001.54.ca...@decadent.org.uk>
and subject line Re: Bug#817816: System freeze with CPU hotplug
has caused the Debian Bug report #817816,
regarding System freeze with CPU hotplug
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
817816: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817816
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: linux-image-4.4.0-1-amd64
Version: 4.4.4-1
Severity: critical
Justification: renders system unusable


When I run the following commands, the system freezes:

# echo 0 | tee /sys/devices/system/cpu/cpu*/online && echo 1 | sudo tee 
/sys/devices/system/cpu/cpu*/online

The system freezes randomly when the CPUs are being onlined or offlined. The 
system is installed on a VMware virtual machine with 4 processors. Here's a 
stacktrace of the infinite loop:

---[regs]
  RAX: 0x8160AC40  RBX: 0x0003  RCX: 0x  
RDX: 0x0003  o d i t s Z a P c 
  RSI: 0x0286  RDI: 0x88004E6B7D98  RBP: 0x88004E6B7D98  
RSP: 0x88007CFCFDC0  RIP: 0x8110AD52
  R8 : 0x88007F60F380  R9 : 0x  R10: 0x81B004C0  
R11: 0x  R12: 0x88004E6B7DBC
  R13: 0x0282  R14: 0x88007F60F300  R15: 0x8110AD10
  CS: 0010  DS:   ES:   FS:   GS:   SS: 0018

---[code]
=> 0x8110ad52 :  mov    ebx,DWORD PTR [rbp+0x20]
   0x8110ad55 :  cmp    edx,ebx
   0x8110ad57 :  je     0x8110ad74 

   0x8110ad59 :  cmp    ebx,0x2
   0x8110ad5c :  je     0x8110ad9e 

   0x8110ad5e :  cmp    ebx,0x3
   0x8110ad61 :  jne    0x8110ad68 

   0x8110ad63 :  test   r14b,r14b
-
multi_cpu_stop (data=0x88004e6b7d98) at 
/build/linux-xT7CCq/linux-4.4.4/kernel/stop_machine.c:197
197 /build/linux-xT7CCq/linux-4.4.4/kernel/stop_machine.c: No such file or 
directory.
gdb$ bt
#0  multi_cpu_stop (data=0x88004e6b7d98) at 
/build/linux-xT7CCq/linux-4.4.4/kernel/stop_machine.c:197
#1  0x8110afed in cpu_stopper_thread (cpu=) at 
/build/linux-xT7CCq/linux-4.4.4/kernel/stop_machine.c:456
#2  0x81097d49 in smpboot_thread_fn (data=0x88004e6b7d98) at 
/build/linux-xT7CCq/linux-4.4.4/kernel/smpboot.c:163
#3  0x81094dfd in kthread (_create=0x88007ce82100) at 
/build/linux-xT7CCq/linux-4.4.4/kernel/kthread.c:209
#4  0x8158ed8f in ret_from_fork () at 
/build/linux-xT7CCq/linux-4.4.4/arch/x86/entry/entry_64.S:486
#5  0x in ?? ()
gdb$ x/x $rbp+0x20
0x88004e6b7db8: 0x0003

In the function multi_cpu_stop(), curstate equals MULTI_STOP_RUN and seems to 
never become equal to MULTI_STOP_EXIT. Let me know if you require additional 
informations.
Thanks--- End Message ---
--- Begin Message ---
On Thu, 2016-03-10 at 17:32 +0100, Harry Junior wrote:
> Package: linux-image-4.4.0-1-amd64
> Version: 4.4.4-1
> Severity: critical
> Justification: renders system unusable
> 
> 
> When I run the following commands, the system freezes:
> 
> # echo 0 | tee /sys/devices/system/cpu/cpu*/online && echo 1 | sudo
> tee /sys/devices/system/cpu/cpu*/online
> 
> The system freezes randomly when the CPUs are being onlined or
> offlined. The system is installed on a VMware virtual machine with 4
> processors. Here's a stacktrace of the infinite loop:
[...]

You just asked to offline all CPUs, making the system unusable.  I
don't see any bug here.

Ben.

-- 
Ben Hutchings
To err is human; to really foul things up requires a computer.


signature.asc
Description: This is a digitally signed message part
--- End Message ---

[PATCH] Fix hppa kernel crash at boot in block/blk-merge.c

2016-03-10 Thread Helge Deller 
Since kernel 4.3 we have a problem on hppa that it crashes at bootup
during the SCSI drive detection.
There are multiple threads about this issue and this link is maybe a good start:
https://patchwork.kernel.org/patch/8402441/.

Now, after quite some time, we could identify what's going wrong.
The attached patch avoids this crash by switching to compiling with
"-O1" instead of "-O2" for a function in block/blk-merge.c (for hppa only).

This patch is meant to be a temporary patch for the debian kernel, until we 
have been able to fix the real problem (in gcc and/or kernel code).

Would it be possible to add this patch to the debian kernel tree for
stable and experimental kernels in the meantime, so that we get bootable
kernels on hppa again?

Thanks,
Helge

diff -up ./block/blk-merge.c.org ./block/blk-merge.c
--- ./block/blk-merge.c.org 2016-03-10 09:44:33.171141161 +0100
+++ ./block/blk-merge.c 2016-03-10 09:47:33.391119064 +0100
@@ -80,7 +80,15 @@ static inline unsigned get_max_io_size(s
return sectors;
 }
 
-static struct bio *blk_bio_segment_split(struct request_queue *q,
+static struct bio *
+#ifdef __hppa__
+   /* 
+* gcc-4.9 miscompiles this function at O2, leading to a kernel crash 
at bootup.
+* So, let's temporarily compile this function with O1 until the bug is 
fully analyzed and fixed.
+*/
+   __attribute__ ((optimize("O1")))
+#endif
+blk_bio_segment_split(struct request_queue *q,
 struct bio *bio,
 struct bio_set *bs,
 unsigned *segs)

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-03-10 Thread Matt Fleming 
On Wed, 09 Mar, at 10:56:07PM, Matt Fleming wrote:
> On Wed, 09 Mar, at 11:01:18PM, Alexis Murzeau wrote:
> > 
> > Indeed I get the "Could not reserve range" message, and with a kernel
> > v4.3 the physical address 0x1 contains the value 1.
> > And this patch works and make a unmodified + this patch 4.4 debian
> > kernel boots, nice well found :)
>  
> Great, thanks for testing.
> 
> > However, now a bad page state is reported in dmesg (which doesn't seem
> > to affect the kernel to me as a user but might hide something buggy) :
> > [0.030096] BUG: Bad page state in process swapper/0  pfn:0
> > [0.030100] page:ea00 count:0 mapcount:1 mapping:
> >(null) index:0x0
> > [0.030102] flags: 0x0()
> > 
> > The efi_free_boot_services function seems to expect size == 0 to not
> > free non reserved memory according to commit 7d68dc3.
> > Not sure if this bad page state is related to this patch though, but I
> > don't get this with the 4.3 kernel.
> 
> Yeah, it's definitely related to my quick and dirty patch. I'll have a
> think about how to fix it properly tomorrow morning.

Alexis, could you, and anybody else that hit this bug, please try out
the attached patch? If it works for you I'll pull it into the EFI tree
ASAP - the merge window is approaching fast. 
commit 7738188068b9
Author: Matt Fleming 
Date:   Wed Mar 9 14:34:24 2016 +

x86/efi: Allow reserving E820_RESERVED regions

Some machines place EFI regions in the zero page (physical address
0x) and we need to ensure that they're mapped into the EFI
page tables now that the kernel doesn't do it for us with
trim_bios_range().

commit 7d68dc3f1003 ("x86, efi: Do not reserve boot services regions
within reserved areas").

Reported-by: Alexis Murzeau 
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815125
Cc: Maarten Lankhorst 
Cc: Borislav Petkov 
Cc: Ingo Molnar 
Cc: Ben Hutchings 
Signed-off-by: Matt Fleming 

diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 2326bf51978f..ae850932dd16 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -164,6 +164,25 @@ efi_status_t efi_query_variable_store(u32 attributes, 
unsigned long size,
 EXPORT_SYMBOL_GPL(efi_query_variable_store);
 
 /*
+ * This function must be used to ensure we do not free already reserved
+ * regions, since that means they're owned by somebody else. Only
+ * reserve (and then free) regions:
+ *
+ * - Not within any part of the kernel
+ * - Not the bios reserved area (E820_RESERVED)
+ */
+static bool can_free_region(u64 start, u64 size)
+{
+   if (start + size > __pa_symbol(_text) && start <= __pa_symbol(_end))
+   return false;
+
+   if (!e820_all_mapped(start, start+size, E820_RAM))
+   return false;
+
+   return true;
+}
+
+/*
  * The UEFI specification makes it clear that the operating system is free to 
do
  * whatever it wants with boot services code after ExitBootServices() has been
  * called. Ignoring this recommendation a significant bunch of EFI 
implementations 
@@ -180,26 +199,50 @@ void __init efi_reserve_boot_services(void)
efi_memory_desc_t *md = p;
u64 start = md->phys_addr;
u64 size = md->num_pages << EFI_PAGE_SHIFT;
+   bool already_reserved;
 
if (md->type != EFI_BOOT_SERVICES_CODE &&
md->type != EFI_BOOT_SERVICES_DATA)
continue;
-   /* Only reserve where possible:
-* - Not within any already allocated areas
-* - Not over any memory area (really needed, if above?)
-* - Not within any part of the kernel
-* - Not the bios reserved area
-   */
-   if ((start + size > __pa_symbol(_text)
-   && start <= __pa_symbol(_end)) ||
-   !e820_all_mapped(start, start+size, E820_RAM) ||
-   memblock_is_region_reserved(start, size)) {
-   /* Could not reserve, skip it */
-   md->num_pages = 0;
-   memblock_dbg("Could not reserve boot range 
[0x%010llx-0x%010llx]\n",
-start, start+size-1);
-   } else
+
+   already_reserved = memblock_is_region_reserved(start, size);
+
+   /*
+* Because the following memblock_reserve() is paired
+* with free_bootmem_late() for this region in
+* efi_free_boot_services(), we must be extremely
+* careful not to reserve, and subsequently free,
+* critical regions of memory (like the kernel image) or
+

Bug#817816: System freeze with CPU hotplug

2016-03-10 Thread Harry Junior 
Package: linux-image-4.4.0-1-amd64
Version: 4.4.4-1
Severity: critical
Justification: renders system unusable


When I run the following commands, the system freezes:

# echo 0 | tee /sys/devices/system/cpu/cpu*/online && echo 1 | sudo tee 
/sys/devices/system/cpu/cpu*/online

The system freezes randomly when the CPUs are being onlined or offlined. The 
system is installed on a VMware virtual machine with 4 processors. Here's a 
stacktrace of the infinite loop:

---[regs]
  RAX: 0x8160AC40  RBX: 0x0003  RCX: 0x  
RDX: 0x0003  o d i t s Z a P c 
  RSI: 0x0286  RDI: 0x88004E6B7D98  RBP: 0x88004E6B7D98  
RSP: 0x88007CFCFDC0  RIP: 0x8110AD52
  R8 : 0x88007F60F380  R9 : 0x  R10: 0x81B004C0  
R11: 0x  R12: 0x88004E6B7DBC
  R13: 0x0282  R14: 0x88007F60F300  R15: 0x8110AD10
  CS: 0010  DS:   ES:   FS:   GS:   SS: 0018

---[code]
=> 0x8110ad52 :  mov    ebx,DWORD PTR [rbp+0x20]
   0x8110ad55 :  cmp    edx,ebx
   0x8110ad57 :  je     0x8110ad74 

   0x8110ad59 :  cmp    ebx,0x2
   0x8110ad5c :  je     0x8110ad9e 

   0x8110ad5e :  cmp    ebx,0x3
   0x8110ad61 :  jne    0x8110ad68 

   0x8110ad63 :  test   r14b,r14b
-
multi_cpu_stop (data=0x88004e6b7d98) at 
/build/linux-xT7CCq/linux-4.4.4/kernel/stop_machine.c:197
197 /build/linux-xT7CCq/linux-4.4.4/kernel/stop_machine.c: No such file or 
directory.
gdb$ bt
#0  multi_cpu_stop (data=0x88004e6b7d98) at 
/build/linux-xT7CCq/linux-4.4.4/kernel/stop_machine.c:197
#1  0x8110afed in cpu_stopper_thread (cpu=) at 
/build/linux-xT7CCq/linux-4.4.4/kernel/stop_machine.c:456
#2  0x81097d49 in smpboot_thread_fn (data=0x88004e6b7d98) at 
/build/linux-xT7CCq/linux-4.4.4/kernel/smpboot.c:163
#3  0x81094dfd in kthread (_create=0x88007ce82100) at 
/build/linux-xT7CCq/linux-4.4.4/kernel/kthread.c:209
#4  0x8158ed8f in ret_from_fork () at 
/build/linux-xT7CCq/linux-4.4.4/arch/x86/entry/entry_64.S:486
#5  0x in ?? ()
gdb$ x/x $rbp+0x20
0x88004e6b7db8: 0x0003

In the function multi_cpu_stop(), curstate equals MULTI_STOP_RUN and seems to 
never become equal to MULTI_STOP_EXIT. Let me know if you require additional 
informations.
Thanks