[PATCH] ktest: take submenu into account
grub-reboot selects the submenu's first menuentry (title is "1>0") rather than
ktest's
menuentry (title is "2") by mistake.
===
$ sudo cat /boot/grub/grub.cfg | grep -E "^menuentry|^submenu"
...
menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os
$menuentry_id_option '...' {
...
submenu 'Advanced options for Ubuntu' $menuentry_id_option '...' {
...
menuentry 'ktest' {
...
===
Correct it by taking submenu entries into account in get_grub2_index().
Signed-off-by: Satoru Takeuchi <satoru.takeu...@gmail.com>
---
tools/testing/ktest/ktest.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index 0c8b61f..6cf135a 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -1821,7 +1821,7 @@ sub get_grub2_index {
$grub_number++;
$found = 1;
last;
- } elsif (/^menuentry\s/) {
+ } elsif (/^menuentry\s|^submenu\s/) {
$grub_number++;
}
}
--
2.7.4
[PATCH] ktest: take submenu into account
grub-reboot selects the submenu's first menuentry (title is "1>0") rather than
ktest's
menuentry (title is "2") by mistake.
===
$ sudo cat /boot/grub/grub.cfg | grep -E "^menuentry|^submenu"
...
menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os
$menuentry_id_option '...' {
...
submenu 'Advanced options for Ubuntu' $menuentry_id_option '...' {
...
menuentry 'ktest' {
...
===
Correct it by taking submenu entries into account in get_grub2_index().
Signed-off-by: Satoru Takeuchi
---
tools/testing/ktest/ktest.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index 0c8b61f..6cf135a 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -1821,7 +1821,7 @@ sub get_grub2_index {
$grub_number++;
$found = 1;
last;
- } elsif (/^menuentry\s/) {
+ } elsif (/^menuentry\s|^submenu\s/) {
$grub_number++;
}
}
--
2.7.4
[PATCH] brd: prevent overflow caused by too large rd_size parameter
The max value of rd_size parameter is ULONG_MAX from the following commit.
Commit 366f4aea649a65c3735d91b4409d84c771811290 ("brd: Switch rd_size
to unsigned long")
However, this parameter * 1024 will be set as inode->i_size corresponding
to brd devices and it's a signed value. To prevent overflow, this parameter
should be equal to or smaller than the max value of sector_t >> 11, 10 bits
are for 1024 and 1 bit is for sign bit.
Signed-off-by: Satoru Takeuchi <satoru.takeu...@gmail.com>
---
drivers/block/brd.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index 104b71c..2b00e7d 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -546,6 +546,14 @@ static int __init brd_init(void)
* dynamically.
*/
+ /*
+* rd_size * 1024 will be set as its inode->i_size and it's a signed
+* value. So rd_size should be equal to or smaller than the max value
+* of sector_t >> 11, 10 bits are for 1024 and 1 bit is for sign bit.
+*/
+ if (rd_size >> (sizeof(sector_t) * 8 - 11))
+ return -EINVAL;
+
if (register_blkdev(RAMDISK_MAJOR, "ramdisk"))
return -EIO;
--
2.7.4
[PATCH] brd: prevent overflow caused by too large rd_size parameter
The max value of rd_size parameter is ULONG_MAX from the following commit.
Commit 366f4aea649a65c3735d91b4409d84c771811290 ("brd: Switch rd_size
to unsigned long")
However, this parameter * 1024 will be set as inode->i_size corresponding
to brd devices and it's a signed value. To prevent overflow, this parameter
should be equal to or smaller than the max value of sector_t >> 11, 10 bits
are for 1024 and 1 bit is for sign bit.
Signed-off-by: Satoru Takeuchi
---
drivers/block/brd.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index 104b71c..2b00e7d 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -546,6 +546,14 @@ static int __init brd_init(void)
* dynamically.
*/
+ /*
+* rd_size * 1024 will be set as its inode->i_size and it's a signed
+* value. So rd_size should be equal to or smaller than the max value
+* of sector_t >> 11, 10 bits are for 1024 and 1 bit is for sign bit.
+*/
+ if (rd_size >> (sizeof(sector_t) * 8 - 11))
+ return -EINVAL;
+
if (register_blkdev(RAMDISK_MAJOR, "ramdisk"))
return -EIO;
--
2.7.4
Re: [FYI] GCC segfaults under heavy multithreaded compilation with AMD Ryzen
2017-08-11 19:07 GMT+09:00 Borislav Petkov <b...@alien8.de>: > On Wed, Jul 26, 2017 at 06:54:01AM +0900, Satoru Takeuchi wrote: >> # I'm a LKML subscriber, but not a x86 list subscriber >> >> I found the following new linux kernel bugzilla about Ryzen related problem. >> Since many developers don't check this bugzilla and I've also >> encountered this problem, >> I decided to introduce this problem here. >> >> https://bugzilla.kernel.org/show_bug.cgi?id=196481: >> > I am running Ubuntu and installed the mainline kernel from the mainline >> > PPA. >> > It seems like the Ryzen processor has some bug that leads to gcc crashing >> > when compiling a very large program under heavy load. This is easily >> > reproduced >> > in my system using the script from >> > >> > https://github.com/suaefar/ryzen-test >> > >> > (It assumes that you are running Ubuntu, maybe Debian also works. Just >> > clone it and run the > script kill_ryzen.sh. It downloads the gcc 7.1 code >> > and start multiple compilations of it. If any >> > compilations fails its warns the user giving the time to detect failure). >> > >> > There is already a bug report about this in the FreeBSD bugzilla >> > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399#c89). >> > There is also a thread on the subject in AMD community forum >> > (https://community.amd.com/thread/215773?start=300=0) >> > and Phoronix >> > (https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads). > > Apparently, you can RMA your CPU: > > https://www.phoronix.com/scan.php?page=news_item=Ryzen-Segv-Response > Sorry for late reply and thank you for letting me know. I've already RMA'ed my CPU and the new one works fine. I have one more Ryzen which I got for investigating this problem and I'll RMA it soon. Regards, Satoru > -- > Regards/Gruss, > Boris. > > ECO tip #101: Trim your mails when you reply. > --
Re: [FYI] GCC segfaults under heavy multithreaded compilation with AMD Ryzen
2017-08-11 19:07 GMT+09:00 Borislav Petkov : > On Wed, Jul 26, 2017 at 06:54:01AM +0900, Satoru Takeuchi wrote: >> # I'm a LKML subscriber, but not a x86 list subscriber >> >> I found the following new linux kernel bugzilla about Ryzen related problem. >> Since many developers don't check this bugzilla and I've also >> encountered this problem, >> I decided to introduce this problem here. >> >> https://bugzilla.kernel.org/show_bug.cgi?id=196481: >> > I am running Ubuntu and installed the mainline kernel from the mainline >> > PPA. >> > It seems like the Ryzen processor has some bug that leads to gcc crashing >> > when compiling a very large program under heavy load. This is easily >> > reproduced >> > in my system using the script from >> > >> > https://github.com/suaefar/ryzen-test >> > >> > (It assumes that you are running Ubuntu, maybe Debian also works. Just >> > clone it and run the > script kill_ryzen.sh. It downloads the gcc 7.1 code >> > and start multiple compilations of it. If any >> > compilations fails its warns the user giving the time to detect failure). >> > >> > There is already a bug report about this in the FreeBSD bugzilla >> > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399#c89). >> > There is also a thread on the subject in AMD community forum >> > (https://community.amd.com/thread/215773?start=300=0) >> > and Phoronix >> > (https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads). > > Apparently, you can RMA your CPU: > > https://www.phoronix.com/scan.php?page=news_item=Ryzen-Segv-Response > Sorry for late reply and thank you for letting me know. I've already RMA'ed my CPU and the new one works fine. I have one more Ryzen which I got for investigating this problem and I'll RMA it soon. Regards, Satoru > -- > Regards/Gruss, > Boris. > > ECO tip #101: Trim your mails when you reply. > --
[FYI] GCC segfaults under heavy multithreaded compilation with AMD Ryzen
# I'm a LKML subscriber, but not a x86 list subscriber I found the following new linux kernel bugzilla about Ryzen related problem. Since many developers don't check this bugzilla and I've also encountered this problem, I decided to introduce this problem here. https://bugzilla.kernel.org/show_bug.cgi?id=196481: > I am running Ubuntu and installed the mainline kernel from the mainline PPA. > It seems like the Ryzen processor has some bug that leads to gcc crashing > when compiling a very large program under heavy load. This is easily > reproduced > in my system using the script from > > https://github.com/suaefar/ryzen-test > > (It assumes that you are running Ubuntu, maybe Debian also works. Just clone > it and run the > script kill_ryzen.sh. It downloads the gcc 7.1 code and > start multiple compilations of it. If any > compilations fails its warns the user giving the time to detect failure). > > There is already a bug report about this in the FreeBSD bugzilla > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399#c89). > There is also a thread on the subject in AMD community forum > (https://community.amd.com/thread/215773?start=300=0) > and Phoronix > (https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads). > > This is probably a processor bug. But I thought that I should try to call the > attention of > the kernel developers to this issue as it may be possible to workaround it in > the kernel. > > Obs: If I disable SMT in BIOS the problem gets much better moving from > failures > after a couple of minute to one failure in 3 to 4 hours) What I want here is that this problem is known by many people, especially by x86 experts, asking the hint to find the root cause, and making the reliable workaround patch. Summary of this problem from my point of view: - gcc sometimes fails with SEGV at random - at least part of this problem is caused by running instructions at "RIP - 0x40" - tens of people encountered this problem - probably it is a hardware problem: many OSes WSL, NetBSD, and FreeBSD encountered the very similar problem. In addition, this problem happens with ECC memory and memtest86 clean memory - the root cause is not found yet. AMD have seemed to try to find it for several months, but there have been no update from AMD yet - There are workaround patch in FreeBSD, but it's not sure that it's a reliable one since the root cause is not sure Fore more detail, please refer to the links at the above mentioned bugzilla. Regards, Satoru
[FYI] GCC segfaults under heavy multithreaded compilation with AMD Ryzen
# I'm a LKML subscriber, but not a x86 list subscriber I found the following new linux kernel bugzilla about Ryzen related problem. Since many developers don't check this bugzilla and I've also encountered this problem, I decided to introduce this problem here. https://bugzilla.kernel.org/show_bug.cgi?id=196481: > I am running Ubuntu and installed the mainline kernel from the mainline PPA. > It seems like the Ryzen processor has some bug that leads to gcc crashing > when compiling a very large program under heavy load. This is easily > reproduced > in my system using the script from > > https://github.com/suaefar/ryzen-test > > (It assumes that you are running Ubuntu, maybe Debian also works. Just clone > it and run the > script kill_ryzen.sh. It downloads the gcc 7.1 code and > start multiple compilations of it. If any > compilations fails its warns the user giving the time to detect failure). > > There is already a bug report about this in the FreeBSD bugzilla > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399#c89). > There is also a thread on the subject in AMD community forum > (https://community.amd.com/thread/215773?start=300=0) > and Phoronix > (https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads). > > This is probably a processor bug. But I thought that I should try to call the > attention of > the kernel developers to this issue as it may be possible to workaround it in > the kernel. > > Obs: If I disable SMT in BIOS the problem gets much better moving from > failures > after a couple of minute to one failure in 3 to 4 hours) What I want here is that this problem is known by many people, especially by x86 experts, asking the hint to find the root cause, and making the reliable workaround patch. Summary of this problem from my point of view: - gcc sometimes fails with SEGV at random - at least part of this problem is caused by running instructions at "RIP - 0x40" - tens of people encountered this problem - probably it is a hardware problem: many OSes WSL, NetBSD, and FreeBSD encountered the very similar problem. In addition, this problem happens with ECC memory and memtest86 clean memory - the root cause is not found yet. AMD have seemed to try to find it for several months, but there have been no update from AMD yet - There are workaround patch in FreeBSD, but it's not sure that it's a reliable one since the root cause is not sure Fore more detail, please refer to the links at the above mentioned bugzilla. Regards, Satoru
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Fri, 28 Apr 2017 15:34:06 +0200, Paolo Bonzini wrote: > > > > On 27/04/2017 02:42, Satoru Takeuchi wrote: > > At Wed, 26 Apr 2017 18:58:27 +0200, > >> On 26/04/2017 13:47, Satoru Takeuchi wrote: > >>> OK, here it is. > >> > >> It looks like the cause is that AMD has removed TBM instructions > >> compared to e.g. Piledriver, so libvirt resorts to a much older base > >> model (thanks to Dave Gilbert for sorting through the list of feature > >> bits). > > ... and the libvirt people also told me that: > > - a more recent QEMU would have enabled CPU leaf 0xD, making it possible > to use AVX inside the guest. > > - a more recent libvirt would have used Opteron_G5 as a base instead of > Opteron_G3. Oh, thank you for letting me know! Satoru > > Thanks, > > Paolo > > >> Can you please run this script: > >> > >> http://libvirt.org/git/?p=libvirt.git;a=blob_plain;f=tests/cputestdata/cpu-gather.sh;h=83963557ec4075d351be09e17994ac5300bc5d1f;hb=HEAD > >> > >> and send the output? > > > > > > OK. Here is the result. > > > > ``` > > # bash tests-cputestdata-cpu-gather.sh > > model name : AMD Ryzen 7 1800X Eight-Core Processor > > CPU: > >0x 0x00: eax=0x000d ebx=0x68747541 ecx=0x444d4163 > > edx=0x69746e65 > >0x0001 0x00: eax=0x00800f11 ebx=0x09100800 ecx=0x7ed8320b > > edx=0x178bfbff > >0x0002 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x0003 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x0005 0x00: eax=0x0040 ebx=0x0040 ecx=0x0003 > > edx=0x > >0x0006 0x00: eax=0x0004 ebx=0x ecx=0x0001 > > edx=0x > >0x0007 0x00: eax=0x ebx=0x209c01a9 ecx=0x > > edx=0x > >0x0008 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x0009 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x000a 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x000c 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x000d 0x00: eax=0x0007 ebx=0x0340 ecx=0x0340 > > edx=0x > >0x000d 0x01: eax=0x000f ebx=0x0340 ecx=0x > > edx=0x > >0x000d 0x02: eax=0x0100 ebx=0x0240 ecx=0x > > edx=0x > >0x000d 0x03: eax=0x ebx=0x ecx=0x > > edx=0x > >0x8000 0x00: eax=0x801f ebx=0x68747541 ecx=0x444d4163 > > edx=0x69746e65 > >0x8001 0x00: eax=0x00800f11 ebx=0x2000 ecx=0x35c233ff > > edx=0x2fd3fbff > >0x8002 0x00: eax=0x20444d41 ebx=0x657a7952 ecx=0x2037206e > > edx=0x30303831 > >0x8003 0x00: eax=0x69452058 ebx=0x2d746867 ecx=0x65726f43 > > edx=0x6f725020 > >0x8004 0x00: eax=0x73736563 ebx=0x2020726f ecx=0x20202020 > > edx=0x00202020 > >0x8005 0x00: eax=0xff40ff40 ebx=0xff40ff40 ecx=0x20080140 > > edx=0x40040140 > >0x8006 0x00: eax=0x26006400 ebx=0x66006400 ecx=0x02006140 > > edx=0x00808140 > >0x8007 0x00: eax=0x ebx=0x001b ecx=0x > > edx=0x6599 > >0x8008 0x00: eax=0x3030 ebx=0x0007 ecx=0x400f > > edx=0x > >0x8009 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x800a 0x00: eax=0x0001 ebx=0x8000 ecx=0x > > edx=0x0001bcff > >0x800b 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x800c 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x800d 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x800e 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x800f 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x8010 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x8011 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x8012 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x8013 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x8014 0x00: eax=0x ebx=0x ecx=0x
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Fri, 28 Apr 2017 15:34:06 +0200, Paolo Bonzini wrote: > > > > On 27/04/2017 02:42, Satoru Takeuchi wrote: > > At Wed, 26 Apr 2017 18:58:27 +0200, > >> On 26/04/2017 13:47, Satoru Takeuchi wrote: > >>> OK, here it is. > >> > >> It looks like the cause is that AMD has removed TBM instructions > >> compared to e.g. Piledriver, so libvirt resorts to a much older base > >> model (thanks to Dave Gilbert for sorting through the list of feature > >> bits). > > ... and the libvirt people also told me that: > > - a more recent QEMU would have enabled CPU leaf 0xD, making it possible > to use AVX inside the guest. > > - a more recent libvirt would have used Opteron_G5 as a base instead of > Opteron_G3. Oh, thank you for letting me know! Satoru > > Thanks, > > Paolo > > >> Can you please run this script: > >> > >> http://libvirt.org/git/?p=libvirt.git;a=blob_plain;f=tests/cputestdata/cpu-gather.sh;h=83963557ec4075d351be09e17994ac5300bc5d1f;hb=HEAD > >> > >> and send the output? > > > > > > OK. Here is the result. > > > > ``` > > # bash tests-cputestdata-cpu-gather.sh > > model name : AMD Ryzen 7 1800X Eight-Core Processor > > CPU: > >0x 0x00: eax=0x000d ebx=0x68747541 ecx=0x444d4163 > > edx=0x69746e65 > >0x0001 0x00: eax=0x00800f11 ebx=0x09100800 ecx=0x7ed8320b > > edx=0x178bfbff > >0x0002 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x0003 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x0005 0x00: eax=0x0040 ebx=0x0040 ecx=0x0003 > > edx=0x > >0x0006 0x00: eax=0x0004 ebx=0x ecx=0x0001 > > edx=0x > >0x0007 0x00: eax=0x ebx=0x209c01a9 ecx=0x > > edx=0x > >0x0008 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x0009 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x000a 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x000c 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x000d 0x00: eax=0x0007 ebx=0x0340 ecx=0x0340 > > edx=0x > >0x000d 0x01: eax=0x000f ebx=0x0340 ecx=0x > > edx=0x > >0x000d 0x02: eax=0x0100 ebx=0x0240 ecx=0x > > edx=0x > >0x000d 0x03: eax=0x ebx=0x ecx=0x > > edx=0x > >0x8000 0x00: eax=0x801f ebx=0x68747541 ecx=0x444d4163 > > edx=0x69746e65 > >0x8001 0x00: eax=0x00800f11 ebx=0x2000 ecx=0x35c233ff > > edx=0x2fd3fbff > >0x8002 0x00: eax=0x20444d41 ebx=0x657a7952 ecx=0x2037206e > > edx=0x30303831 > >0x8003 0x00: eax=0x69452058 ebx=0x2d746867 ecx=0x65726f43 > > edx=0x6f725020 > >0x8004 0x00: eax=0x73736563 ebx=0x2020726f ecx=0x20202020 > > edx=0x00202020 > >0x8005 0x00: eax=0xff40ff40 ebx=0xff40ff40 ecx=0x20080140 > > edx=0x40040140 > >0x8006 0x00: eax=0x26006400 ebx=0x66006400 ecx=0x02006140 > > edx=0x00808140 > >0x8007 0x00: eax=0x ebx=0x001b ecx=0x > > edx=0x6599 > >0x8008 0x00: eax=0x3030 ebx=0x0007 ecx=0x400f > > edx=0x > >0x8009 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x800a 0x00: eax=0x0001 ebx=0x8000 ecx=0x > > edx=0x0001bcff > >0x800b 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x800c 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x800d 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x800e 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x800f 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x8010 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x8011 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x8012 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x8013 0x00: eax=0x ebx=0x ecx=0x > > edx=0x > >0x8014 0x00: eax=0x ebx=0x ecx=0x
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Wed, 26 Apr 2017 18:58:27 +0200, Paolo Bonzini wrote: > > > > On 26/04/2017 13:47, Satoru Takeuchi wrote: > > OK, here it is. > > It looks like the cause is that AMD has removed TBM instructions > compared to e.g. Piledriver, so libvirt resorts to a much older base > model (thanks to Dave Gilbert for sorting through the list of feature bits). > > Can you please run this script: > > http://libvirt.org/git/?p=libvirt.git;a=blob_plain;f=tests/cputestdata/cpu-gather.sh;h=83963557ec4075d351be09e17994ac5300bc5d1f;hb=HEAD > > and send the output? OK. Here is the result. ``` # bash tests-cputestdata-cpu-gather.sh model name : AMD Ryzen 7 1800X Eight-Core Processor CPU: 0x 0x00: eax=0x000d ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 0x0001 0x00: eax=0x00800f11 ebx=0x09100800 ecx=0x7ed8320b edx=0x178bfbff 0x0002 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x0003 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x0005 0x00: eax=0x0040 ebx=0x0040 ecx=0x0003 edx=0x 0x0006 0x00: eax=0x0004 ebx=0x ecx=0x0001 edx=0x 0x0007 0x00: eax=0x ebx=0x209c01a9 ecx=0x edx=0x 0x0008 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x0009 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x000a 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x000c 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x000d 0x00: eax=0x0007 ebx=0x0340 ecx=0x0340 edx=0x 0x000d 0x01: eax=0x000f ebx=0x0340 ecx=0x edx=0x 0x000d 0x02: eax=0x0100 ebx=0x0240 ecx=0x edx=0x 0x000d 0x03: eax=0x ebx=0x ecx=0x edx=0x 0x8000 0x00: eax=0x801f ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 0x8001 0x00: eax=0x00800f11 ebx=0x2000 ecx=0x35c233ff edx=0x2fd3fbff 0x8002 0x00: eax=0x20444d41 ebx=0x657a7952 ecx=0x2037206e edx=0x30303831 0x8003 0x00: eax=0x69452058 ebx=0x2d746867 ecx=0x65726f43 edx=0x6f725020 0x8004 0x00: eax=0x73736563 ebx=0x2020726f ecx=0x20202020 edx=0x00202020 0x8005 0x00: eax=0xff40ff40 ebx=0xff40ff40 ecx=0x20080140 edx=0x40040140 0x8006 0x00: eax=0x26006400 ebx=0x66006400 ecx=0x02006140 edx=0x00808140 0x8007 0x00: eax=0x ebx=0x001b ecx=0x edx=0x6599 0x8008 0x00: eax=0x3030 ebx=0x0007 ecx=0x400f edx=0x 0x8009 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x800a 0x00: eax=0x0001 ebx=0x8000 ecx=0x edx=0x0001bcff 0x800b 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x800c 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x800d 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x800e 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x800f 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8010 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8011 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8012 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8013 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8014 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8015 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8016 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8017 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8018 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8019 0x00: eax=0xf040f040 ebx=0x ecx=0x edx=0x 0x801a 0x00: eax=0x0003 ebx=0x ecx=0x edx=0x 0x801b 0x00: eax=0x03ff ebx=0x ecx=0x edx=0x 0x801c 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x801d 0x00: eax=0x4121 ebx=0x01c0003f ecx=0x003f edx=0x 0x801e 0x00: eax=0x0009 ebx=0x0104 ecx=0x edx=0x 0x801f 0x00: eax=0x0007 ebx=0x016f ecx=0x000f edx=0x 0x8086 0x00: eax=0x ebx=0x ecx=0x edx=0x 0xc000 0x00: eax=0x ebx=0x ecx=0x edx=0x warning: host doesn't support requested feature: CPUID.8001H:EDX [bit 0] warning: host doesn't support requested feature: CPUID.8001H:EDX [bit 1] warning: host doesn't support requested feature: CPUID.8001H:EDX [bit 2] warning: host doesn't support requested feature: CPUID.8001H:EDX [bit 3] warning: host doesn't suppo
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Wed, 26 Apr 2017 18:58:27 +0200, Paolo Bonzini wrote: > > > > On 26/04/2017 13:47, Satoru Takeuchi wrote: > > OK, here it is. > > It looks like the cause is that AMD has removed TBM instructions > compared to e.g. Piledriver, so libvirt resorts to a much older base > model (thanks to Dave Gilbert for sorting through the list of feature bits). > > Can you please run this script: > > http://libvirt.org/git/?p=libvirt.git;a=blob_plain;f=tests/cputestdata/cpu-gather.sh;h=83963557ec4075d351be09e17994ac5300bc5d1f;hb=HEAD > > and send the output? OK. Here is the result. ``` # bash tests-cputestdata-cpu-gather.sh model name : AMD Ryzen 7 1800X Eight-Core Processor CPU: 0x 0x00: eax=0x000d ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 0x0001 0x00: eax=0x00800f11 ebx=0x09100800 ecx=0x7ed8320b edx=0x178bfbff 0x0002 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x0003 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x0005 0x00: eax=0x0040 ebx=0x0040 ecx=0x0003 edx=0x 0x0006 0x00: eax=0x0004 ebx=0x ecx=0x0001 edx=0x 0x0007 0x00: eax=0x ebx=0x209c01a9 ecx=0x edx=0x 0x0008 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x0009 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x000a 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x000c 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x000d 0x00: eax=0x0007 ebx=0x0340 ecx=0x0340 edx=0x 0x000d 0x01: eax=0x000f ebx=0x0340 ecx=0x edx=0x 0x000d 0x02: eax=0x0100 ebx=0x0240 ecx=0x edx=0x 0x000d 0x03: eax=0x ebx=0x ecx=0x edx=0x 0x8000 0x00: eax=0x801f ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 0x8001 0x00: eax=0x00800f11 ebx=0x2000 ecx=0x35c233ff edx=0x2fd3fbff 0x8002 0x00: eax=0x20444d41 ebx=0x657a7952 ecx=0x2037206e edx=0x30303831 0x8003 0x00: eax=0x69452058 ebx=0x2d746867 ecx=0x65726f43 edx=0x6f725020 0x8004 0x00: eax=0x73736563 ebx=0x2020726f ecx=0x20202020 edx=0x00202020 0x8005 0x00: eax=0xff40ff40 ebx=0xff40ff40 ecx=0x20080140 edx=0x40040140 0x8006 0x00: eax=0x26006400 ebx=0x66006400 ecx=0x02006140 edx=0x00808140 0x8007 0x00: eax=0x ebx=0x001b ecx=0x edx=0x6599 0x8008 0x00: eax=0x3030 ebx=0x0007 ecx=0x400f edx=0x 0x8009 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x800a 0x00: eax=0x0001 ebx=0x8000 ecx=0x edx=0x0001bcff 0x800b 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x800c 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x800d 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x800e 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x800f 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8010 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8011 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8012 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8013 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8014 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8015 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8016 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8017 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8018 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x8019 0x00: eax=0xf040f040 ebx=0x ecx=0x edx=0x 0x801a 0x00: eax=0x0003 ebx=0x ecx=0x edx=0x 0x801b 0x00: eax=0x03ff ebx=0x ecx=0x edx=0x 0x801c 0x00: eax=0x ebx=0x ecx=0x edx=0x 0x801d 0x00: eax=0x4121 ebx=0x01c0003f ecx=0x003f edx=0x 0x801e 0x00: eax=0x0009 ebx=0x0104 ecx=0x edx=0x 0x801f 0x00: eax=0x0007 ebx=0x016f ecx=0x000f edx=0x 0x8086 0x00: eax=0x ebx=0x ecx=0x edx=0x 0xc000 0x00: eax=0x ebx=0x ecx=0x edx=0x warning: host doesn't support requested feature: CPUID.8001H:EDX [bit 0] warning: host doesn't support requested feature: CPUID.8001H:EDX [bit 1] warning: host doesn't support requested feature: CPUID.8001H:EDX [bit 2] warning: host doesn't support requested feature: CPUID.8001H:EDX [bit 3] warning: host doesn't suppo
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Tue, 25 Apr 2017 23:58:50 +0900, Masami Hiramatsu wrote: > > Hello, > > 2017-04-24 22:09 GMT+09:00 Satoru Takeuchi <satoru.takeu...@gmail.com>: > > At Mon, 24 Apr 2017 14:48:46 +0200, > > Borislav Petkov wrote: > >> > >> On Mon, Apr 24, 2017 at 09:39:12PM +0900, Satoru Takeuchi wrote: > >> > I used the following auto-test tool (its backend is ktest). > >> > > >> > https://github.com/satoru-takeuchi/elkdat > >> > > >> > This problem can be reproduced by the following command on Ubuntu 16.04. > >> > > >> > ``` > >> > $ sudo apt-get install git vagrant libvirt-bin libvirt-dev > >> > kernel-package qemu-kvm libssl-dev libncurses5-dev > >> > >> Can you minimize that reproducer? I.e, can you dump only the qemu > >> command line options from this setup? > >> > >> They're enough to be able to start a guest with your config without me > >> having to install all that other stuff. > > > > OK. Is it sufficient information? > > > > ``` > > qemu-system-x86_64 -enable-kvm -name elkdat_ktest -S -machine > > pc-i440fx-xenial,accel=kvm,usb=off -cpu > > Opteron_G3,+smap,+adx,+rdseed,+bmi2,+smep,+avx2,+bmi1,+fsgsbase,+perfctr_nb,+perfctr_core,+topoext,+tce,+wdt,+skinit,+osvw, > +3dnowprefetch,+cr8legacy,+extapic,+cmp_legacy,+pdpe1gb,+fxsr_opt,+mmxext,+rdrand,+f16c,+avx,+osxsave,+xsave,+aes,+movbe,+sse4.2,+sse4.1,+fma,+ssse3,+pclmuldq,+ht, > +vme -m 512 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid > 12de0e96-5d01-4ab0-b0b3-165f5560 -no-user-config -nodefaults -chardev > socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-elkdat_ktest/monitor.sock,server,nowait > -mon chardev=charmonitor,id=monitor,mode=control -rtc > base=utc -no-shutdown -boot strict=on -device > piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive > file=/var/lib/libvirt/images/ > elkdat_ktest.img,format=qcow2,if=none,id=drive-virtio-disk0 -device > virtio-blk-pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio- > disk0,bootindex=1 -netdev tap,fd=26,id=h > > ostnet0,vhost=on,vhostfd=28 -device > > virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e4:6f:3e,bus=pci.0,addr=0x5 > > -chardev > pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc > 127.0.0.1:0 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device > virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on > > ``` > > I also could reproduce this with Fedora 25 on Core i7-4770S, > with below options. > > "-cpu > Opteron_G3,+smap,+adx,+rdseed,+bmi2,+smep,+avx2,+bmi1,+fsgsbase,+perfctr_nb,+perfctr_core,+topoext,+tce,+wdt,+skinit,+osvw,+3dnowprefetch,+cr8legacy,+extapic,+cmp_legacy,+pdpe1gb,+fxsr_opt,+mmxext,+rdrand,+f16c,+avx,+osxsave,+xsave,+aes,+movbe,+sse4.2,+sse4.1,+fma,+ssse3,+pclmuldq,+vme > -M pc -enable-kvm -M pc -enable-kvm " > > And a quick investigation showed that this crash happened when I > replaced the "Opteron_G3" with "Opteron_G2", "Opteron_G1", "Westmere" > and "Nehalem" (I didn't check older than that). But I didn't see the > crash when I specify "Opteron_G4" or "Opteron_G5", or newer than > "SandyBridge". > > So, I guess this maybe caused by the combinations of cpu model and > flags which must not exist, maybe qemu changes available instruction > set based on cpu model, but linux checks only cpu feature flag. Yeah, probably so. I succeeded to boot my own kernel with "Opteron_G5" model and disabling "fma4", "tbm", and "xop" which Ryzen doesn't support. As Paolo said in other mail, The boot also succeeded with "host-passthrough" mode rather than "host-model". I'll wait for adding "Ryzen (or Zen?)" model to qemu. Regards, Satoru > > Thank you, > > -- > Masami Hiramatsu <mhira...@kernel.org>
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Tue, 25 Apr 2017 23:58:50 +0900, Masami Hiramatsu wrote: > > Hello, > > 2017-04-24 22:09 GMT+09:00 Satoru Takeuchi : > > At Mon, 24 Apr 2017 14:48:46 +0200, > > Borislav Petkov wrote: > >> > >> On Mon, Apr 24, 2017 at 09:39:12PM +0900, Satoru Takeuchi wrote: > >> > I used the following auto-test tool (its backend is ktest). > >> > > >> > https://github.com/satoru-takeuchi/elkdat > >> > > >> > This problem can be reproduced by the following command on Ubuntu 16.04. > >> > > >> > ``` > >> > $ sudo apt-get install git vagrant libvirt-bin libvirt-dev > >> > kernel-package qemu-kvm libssl-dev libncurses5-dev > >> > >> Can you minimize that reproducer? I.e, can you dump only the qemu > >> command line options from this setup? > >> > >> They're enough to be able to start a guest with your config without me > >> having to install all that other stuff. > > > > OK. Is it sufficient information? > > > > ``` > > qemu-system-x86_64 -enable-kvm -name elkdat_ktest -S -machine > > pc-i440fx-xenial,accel=kvm,usb=off -cpu > > Opteron_G3,+smap,+adx,+rdseed,+bmi2,+smep,+avx2,+bmi1,+fsgsbase,+perfctr_nb,+perfctr_core,+topoext,+tce,+wdt,+skinit,+osvw, > +3dnowprefetch,+cr8legacy,+extapic,+cmp_legacy,+pdpe1gb,+fxsr_opt,+mmxext,+rdrand,+f16c,+avx,+osxsave,+xsave,+aes,+movbe,+sse4.2,+sse4.1,+fma,+ssse3,+pclmuldq,+ht, > +vme -m 512 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid > 12de0e96-5d01-4ab0-b0b3-165f5560 -no-user-config -nodefaults -chardev > socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-elkdat_ktest/monitor.sock,server,nowait > -mon chardev=charmonitor,id=monitor,mode=control -rtc > base=utc -no-shutdown -boot strict=on -device > piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive > file=/var/lib/libvirt/images/ > elkdat_ktest.img,format=qcow2,if=none,id=drive-virtio-disk0 -device > virtio-blk-pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio- > disk0,bootindex=1 -netdev tap,fd=26,id=h > > ostnet0,vhost=on,vhostfd=28 -device > > virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e4:6f:3e,bus=pci.0,addr=0x5 > > -chardev > pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc > 127.0.0.1:0 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device > virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on > > ``` > > I also could reproduce this with Fedora 25 on Core i7-4770S, > with below options. > > "-cpu > Opteron_G3,+smap,+adx,+rdseed,+bmi2,+smep,+avx2,+bmi1,+fsgsbase,+perfctr_nb,+perfctr_core,+topoext,+tce,+wdt,+skinit,+osvw,+3dnowprefetch,+cr8legacy,+extapic,+cmp_legacy,+pdpe1gb,+fxsr_opt,+mmxext,+rdrand,+f16c,+avx,+osxsave,+xsave,+aes,+movbe,+sse4.2,+sse4.1,+fma,+ssse3,+pclmuldq,+vme > -M pc -enable-kvm -M pc -enable-kvm " > > And a quick investigation showed that this crash happened when I > replaced the "Opteron_G3" with "Opteron_G2", "Opteron_G1", "Westmere" > and "Nehalem" (I didn't check older than that). But I didn't see the > crash when I specify "Opteron_G4" or "Opteron_G5", or newer than > "SandyBridge". > > So, I guess this maybe caused by the combinations of cpu model and > flags which must not exist, maybe qemu changes available instruction > set based on cpu model, but linux checks only cpu feature flag. Yeah, probably so. I succeeded to boot my own kernel with "Opteron_G5" model and disabling "fma4", "tbm", and "xop" which Ryzen doesn't support. As Paolo said in other mail, The boot also succeeded with "host-passthrough" mode rather than "host-model". I'll wait for adding "Ryzen (or Zen?)" model to qemu. Regards, Satoru > > Thank you, > > -- > Masami Hiramatsu
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Wed, 26 Apr 2017 09:48:22 +0200, Paolo Bonzini wrote: > > > > On 25/04/2017 11:36, Borislav Petkov wrote: > > Looking at CR4: 003006f0, it doesn't have OSXSAVE set. I.e., bit > > 18. And when that bit is not set, VMOVDQA raises an #UD. > > > > And for some reason qemu doesn't like it even if you request that bit with > > +osxsave: > > > > warning: host doesn't support requested feature: CPUID.01H:ECX.osxsave [bit > > 27] > > > > Even though the corresponding bit in CPUID on the host is set: > > > > 0x0001: EAX=0x00800f00, EBX=0x40200800, ECX=0x7ed8320b, EDX=0x178bfbff > >^ > > Paolo, any thoughts? > > The OSXSAVE CPUID bit is not set by QEMU, it is set by the OS itself > (indirectly) when it sets CR4.OSXSAVE. QEMU says it's not available > (probably) because the Opteron_G3 CPU model does not have the 0xD CPUID > leaf. > > I think you're using libvirt's "host-model" CPU model. That model needs > QEMU/libvirt support for each host CPU family, and in general it often > gives rise to bugs such as the one you're reporting, Yes, I used "host-model". > > Change it to host-passthrough, I changed it as you said and my own kernel succeeded to boot, thank you! > and please send us the output of/proc/cpuinfo so we can add support for Ryzen > in "host-model". OK, here it is. ``` $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 23 model : 1 model name : AMD Ryzen 7 1800X Eight-Core Processor stepping: 1 microcode : 0x800111c cpu MHz : 2200.000 cache size : 512 KB physical id : 0 siblings: 16 core id : 0 cpu cores : 8 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_l2 mwaitx hw_pstate vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic overflow_recov succor smca bugs: fxsave_leak sysret_ss_attrs null_seg bogomips: 7186.66 TLB size: 2560 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm hwpstate eff_freq_ro [13] [14] processor : 1 vendor_id : AuthenticAMD cpu family : 23 model : 1 model name : AMD Ryzen 7 1800X Eight-Core Processor stepping: 1 microcode : 0x800111c cpu MHz : 2200.000 cache size : 512 KB physical id : 0 siblings: 16 core id : 0 cpu cores : 8 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_l2 mwaitx hw_pstate vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic overflow_recov succor smca bugs: fxsave_leak sysret_ss_attrs null_seg bogomips: 7186.66 TLB size: 2560 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm hwpstate eff_freq_ro [13] [14] processor : 2 vendor_id : AuthenticAMD cpu family : 23 model : 1 model name : AMD Ryzen 7 1800X Eight-Core Processor stepping: 1 microcode : 0x800111c cpu MHz : 2200.000 cache size : 512 KB physical id : 0 siblings: 16 core id : 1 cpu cores : 8 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Wed, 26 Apr 2017 09:48:22 +0200, Paolo Bonzini wrote: > > > > On 25/04/2017 11:36, Borislav Petkov wrote: > > Looking at CR4: 003006f0, it doesn't have OSXSAVE set. I.e., bit > > 18. And when that bit is not set, VMOVDQA raises an #UD. > > > > And for some reason qemu doesn't like it even if you request that bit with > > +osxsave: > > > > warning: host doesn't support requested feature: CPUID.01H:ECX.osxsave [bit > > 27] > > > > Even though the corresponding bit in CPUID on the host is set: > > > > 0x0001: EAX=0x00800f00, EBX=0x40200800, ECX=0x7ed8320b, EDX=0x178bfbff > >^ > > Paolo, any thoughts? > > The OSXSAVE CPUID bit is not set by QEMU, it is set by the OS itself > (indirectly) when it sets CR4.OSXSAVE. QEMU says it's not available > (probably) because the Opteron_G3 CPU model does not have the 0xD CPUID > leaf. > > I think you're using libvirt's "host-model" CPU model. That model needs > QEMU/libvirt support for each host CPU family, and in general it often > gives rise to bugs such as the one you're reporting, Yes, I used "host-model". > > Change it to host-passthrough, I changed it as you said and my own kernel succeeded to boot, thank you! > and please send us the output of/proc/cpuinfo so we can add support for Ryzen > in "host-model". OK, here it is. ``` $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 23 model : 1 model name : AMD Ryzen 7 1800X Eight-Core Processor stepping: 1 microcode : 0x800111c cpu MHz : 2200.000 cache size : 512 KB physical id : 0 siblings: 16 core id : 0 cpu cores : 8 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_l2 mwaitx hw_pstate vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic overflow_recov succor smca bugs: fxsave_leak sysret_ss_attrs null_seg bogomips: 7186.66 TLB size: 2560 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm hwpstate eff_freq_ro [13] [14] processor : 1 vendor_id : AuthenticAMD cpu family : 23 model : 1 model name : AMD Ryzen 7 1800X Eight-Core Processor stepping: 1 microcode : 0x800111c cpu MHz : 2200.000 cache size : 512 KB physical id : 0 siblings: 16 core id : 0 cpu cores : 8 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_l2 mwaitx hw_pstate vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic overflow_recov succor smca bugs: fxsave_leak sysret_ss_attrs null_seg bogomips: 7186.66 TLB size: 2560 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm hwpstate eff_freq_ro [13] [14] processor : 2 vendor_id : AuthenticAMD cpu family : 23 model : 1 model name : AMD Ryzen 7 1800X Eight-Core Processor stepping: 1 microcode : 0x800111c cpu MHz : 2200.000 cache size : 512 KB physical id : 0 siblings: 16 core id : 1 cpu cores : 8 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Mon, 24 Apr 2017 14:48:46 +0200, Borislav Petkov wrote: > > On Mon, Apr 24, 2017 at 09:39:12PM +0900, Satoru Takeuchi wrote: > > I used the following auto-test tool (its backend is ktest). > > > > https://github.com/satoru-takeuchi/elkdat > > > > This problem can be reproduced by the following command on Ubuntu 16.04. > > > > ``` > > $ sudo apt-get install git vagrant libvirt-bin libvirt-dev kernel-package > > qemu-kvm libssl-dev libncurses5-dev > > Can you minimize that reproducer? I.e, can you dump only the qemu > command line options from this setup? > > They're enough to be able to start a guest with your config without me > having to install all that other stuff. OK. Is it sufficient information? ``` qemu-system-x86_64 -enable-kvm -name elkdat_ktest -S -machine pc-i440fx-xenial,accel=kvm,usb=off -cpu Opteron_G3,+smap,+adx,+rdseed,+bmi2,+smep,+avx2,+bmi1,+fsgsbase,+perfctr_nb,+perfctr_core,+topoext,+tce,+wdt,+skinit,+osvw,+3dnowprefetch,+cr8legacy,+extapic,+cmp_legacy,+pdpe1gb,+fxsr_opt,+mmxext,+rdrand,+f16c,+avx,+osxsave,+xsave,+aes,+movbe,+sse4.2,+sse4.1,+fma,+ssse3,+pclmuldq,+ht,+vme -m 512 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 12de0e96-5d01-4ab0-b0b3-165f5560 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-elkdat_ktest/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/elkdat_ktest.img,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=26,id=h ostnet0,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e4:6f:3e,bus=pci.0,addr=0x5 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on ``` Thanks, Satoru > > Thanks. > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Mon, 24 Apr 2017 14:48:46 +0200, Borislav Petkov wrote: > > On Mon, Apr 24, 2017 at 09:39:12PM +0900, Satoru Takeuchi wrote: > > I used the following auto-test tool (its backend is ktest). > > > > https://github.com/satoru-takeuchi/elkdat > > > > This problem can be reproduced by the following command on Ubuntu 16.04. > > > > ``` > > $ sudo apt-get install git vagrant libvirt-bin libvirt-dev kernel-package > > qemu-kvm libssl-dev libncurses5-dev > > Can you minimize that reproducer? I.e, can you dump only the qemu > command line options from this setup? > > They're enough to be able to start a guest with your config without me > having to install all that other stuff. OK. Is it sufficient information? ``` qemu-system-x86_64 -enable-kvm -name elkdat_ktest -S -machine pc-i440fx-xenial,accel=kvm,usb=off -cpu Opteron_G3,+smap,+adx,+rdseed,+bmi2,+smep,+avx2,+bmi1,+fsgsbase,+perfctr_nb,+perfctr_core,+topoext,+tce,+wdt,+skinit,+osvw,+3dnowprefetch,+cr8legacy,+extapic,+cmp_legacy,+pdpe1gb,+fxsr_opt,+mmxext,+rdrand,+f16c,+avx,+osxsave,+xsave,+aes,+movbe,+sse4.2,+sse4.1,+fma,+ssse3,+pclmuldq,+ht,+vme -m 512 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 12de0e96-5d01-4ab0-b0b3-165f5560 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-elkdat_ktest/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/elkdat_ktest.img,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=26,id=h ostnet0,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e4:6f:3e,bus=pci.0,addr=0x5 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on ``` Thanks, Satoru > > Thanks. > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Mon, 24 Apr 2017 13:07:53 +0200,
Borislav Petkov wrote:
>
> On Mon, Apr 24, 2017 at 03:58:05PM +0900, Satoru Takeuchi wrote:
> > Recently I bought a new Ryzen machine. When I tried to test v4.11-rc8 on
> > it, it failed to boot
> > with the following panic log.
> >
> > ```
> > ...
> > [0.227720] raid6: sse2x1 gen() 7985 MB/s
> > [0.295709] raid6: sse2x1 xor() 8181 MB/s
> > [0.363706] raid6: sse2x2 gen() 17531 MB/s
> > [0.431699] raid6: sse2x2 xor() 11098 MB/s
> > [0.499693] raid6: sse2x4 gen() 18509 MB/s
> > [0.567688] raid6: sse2x4 xor() 10177 MB/s
> > [0.571692] invalid opcode: [#1] SMP
> > [0.572312] Modules linked in:
> > [0.572822] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc8-ktest #1
> > [0.573734] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > Ubuntu-1.8.2-1ubuntu1 04/01/2014
> ^^
>
> Next time your report a bug, say it is a guest on the *very* first line
> of your report.
I'm very sorry.
>
> Now, how do you start your guest exactly? Full cmdline pls.
I used the following auto-test tool (its backend is ktest).
https://github.com/satoru-takeuchi/elkdat
This problem can be reproduced by the following command on Ubuntu 16.04.
```
$ sudo apt-get install git vagrant libvirt-bin libvirt-dev kernel-package
qemu-kvm libssl-dev libncurses5-dev
...
$ sudo usermod -aG libvirt
```
Log out and back in here.
```
$ sudo sed -i'' "s/Specification.all = nil/Specification.reset/"
/usr/lib/ruby/vendor_ruby/vagrant/bundler.rb # See
https://github.com/vagrant-libvirt/vagrant-libvirt/issues/575 for more details
about this patching
$ vagrant plugin install vagrant-libvirt
$ git clone https://github.com/satoru-takeuchi/elkdat.git
...
$ cp -r /path/to/linux/source elkdat/linux
$ cd elkdat
$ ./init # start guest
...
$ pushd linux
...
$ git checkout v4.11-rc8
...
$ popd
...
$ ./test boot# build and boot v4.11-rc8
... # kernel panic happens here
```
The core of the starting guest process of above mentioned tools is as follows.
1. Add the vagrant box for the guest VM
```
$ vagrant box add elastic/ubuntu-16.04-x86_64 --provider libvirt
...
```
2. Start the VM with the following Vagrantfile.
```
$ cd elkdat
$ vagrant up
```
The summary of Vagrantfile is here.
```
Vagrant.configure("2") do |config|
...
config.vm.define :ktest do |vm|
vm.vm.box = "elastic/ubuntu-16.04-x86_64"
vm.vm.synced_folder './', '/vagrant', type: 'rsync'
vm.vm.provider :libvirt do |domain|
domain.cpus = 2
end
end
...
end
```
Thanks,
Satoru
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Mon, 24 Apr 2017 13:07:53 +0200,
Borislav Petkov wrote:
>
> On Mon, Apr 24, 2017 at 03:58:05PM +0900, Satoru Takeuchi wrote:
> > Recently I bought a new Ryzen machine. When I tried to test v4.11-rc8 on
> > it, it failed to boot
> > with the following panic log.
> >
> > ```
> > ...
> > [0.227720] raid6: sse2x1 gen() 7985 MB/s
> > [0.295709] raid6: sse2x1 xor() 8181 MB/s
> > [0.363706] raid6: sse2x2 gen() 17531 MB/s
> > [0.431699] raid6: sse2x2 xor() 11098 MB/s
> > [0.499693] raid6: sse2x4 gen() 18509 MB/s
> > [0.567688] raid6: sse2x4 xor() 10177 MB/s
> > [0.571692] invalid opcode: [#1] SMP
> > [0.572312] Modules linked in:
> > [0.572822] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc8-ktest #1
> > [0.573734] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > Ubuntu-1.8.2-1ubuntu1 04/01/2014
> ^^
>
> Next time your report a bug, say it is a guest on the *very* first line
> of your report.
I'm very sorry.
>
> Now, how do you start your guest exactly? Full cmdline pls.
I used the following auto-test tool (its backend is ktest).
https://github.com/satoru-takeuchi/elkdat
This problem can be reproduced by the following command on Ubuntu 16.04.
```
$ sudo apt-get install git vagrant libvirt-bin libvirt-dev kernel-package
qemu-kvm libssl-dev libncurses5-dev
...
$ sudo usermod -aG libvirt
```
Log out and back in here.
```
$ sudo sed -i'' "s/Specification.all = nil/Specification.reset/"
/usr/lib/ruby/vendor_ruby/vagrant/bundler.rb # See
https://github.com/vagrant-libvirt/vagrant-libvirt/issues/575 for more details
about this patching
$ vagrant plugin install vagrant-libvirt
$ git clone https://github.com/satoru-takeuchi/elkdat.git
...
$ cp -r /path/to/linux/source elkdat/linux
$ cd elkdat
$ ./init # start guest
...
$ pushd linux
...
$ git checkout v4.11-rc8
...
$ popd
...
$ ./test boot# build and boot v4.11-rc8
... # kernel panic happens here
```
The core of the starting guest process of above mentioned tools is as follows.
1. Add the vagrant box for the guest VM
```
$ vagrant box add elastic/ubuntu-16.04-x86_64 --provider libvirt
...
```
2. Start the VM with the following Vagrantfile.
```
$ cd elkdat
$ vagrant up
```
The summary of Vagrantfile is here.
```
Vagrant.configure("2") do |config|
...
config.vm.define :ktest do |vm|
vm.vm.box = "elastic/ubuntu-16.04-x86_64"
vm.vm.synced_folder './', '/vagrant', type: 'rsync'
vm.vm.provider :libvirt do |domain|
domain.cpus = 2
end
end
...
end
```
Thanks,
Satoru
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Mon, 24 Apr 2017 15:58:05 +0900,
Satoru Takeuchi wrote:
>
> [1 ]
> Recently I bought a new Ryzen machine. When I tried to test v4.11-rc8 on it,
> it failed to boot
> with the following panic log.
>
> ```
> ...
> [0.227720] raid6: sse2x1 gen() 7985 MB/s
> [0.295709] raid6: sse2x1 xor() 8181 MB/s
> [0.363706] raid6: sse2x2 gen() 17531 MB/s
> [0.431699] raid6: sse2x2 xor() 11098 MB/s
> [0.499693] raid6: sse2x4 gen() 18509 MB/s
> [0.567688] raid6: sse2x4 xor() 10177 MB/s
> [0.571692] invalid opcode: [#1] SMP
> [0.572312] Modules linked in:
> [0.572822] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc8-ktest #1
> [0.573734] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> Ubuntu-1.8.2-1ubuntu1 04/01/2014
> [0.575040] task: 8f791e1c task.stack: 9c72c00d
> [0.575865] RIP: 0010:raid6_avx21_gen_syndrome+0x3d/0x120
> [0.576634] RSP: 0018:9c72c00d3d70 EFLAGS: 00010246
> [0.577376] RAX: RBX: 9c72c00d3dc0 RCX:
> fffedb97
> [0.578327] RDX: RSI: 1000 RDI:
> 0012
> [0.579283] RBP: 9c72c00d3da0 R08: R09:
> 00cd
> [0.580243] R10: fffedb86 R11: a617008d R12:
> 1000
> [0.581211] R13: 8f791e39e000 R14: 8f791e39f000 R15:
> 0012
> [0.582163] FS: () GS:8f791fc0()
> knlGS:
> [0.583324] CS: 0010 DS: ES: CR0: 80050033
> [0.584128] CR2: CR3: 1be09000 CR4:
> 003006f0
> [0.585078] Call Trace:
> [0.594952] raid6_select_algo+0x116/0x30b
> [0.595592] ? libcrc32c_mod_init+0x2b/0x2b
> [0.596240] do_one_initcall+0x53/0x1a0
> [0.596843] ? parse_args+0x2cf/0x490
> [0.597421] kernel_init_freeable+0x182/0x21c
> [0.598077] ? rest_init+0x80/0x80
> [0.598626] kernel_init+0xe/0x100
> [0.599175] ret_from_fork+0x2c/0x40
> [0.599741] Code: 55 41 54 53 48 89 d3 48 8d 14 c5 00 00 00 00 41 89 ff 49
> 89 f4 48 83 ec 08 4c 8b 2c c3 4c 8b 74 13 08 48 89 55 d0 e8 53 ed a9 ff
> fd 6f 05 2b 2d 4e 00 c5 e5 ef db 4d 85 e4 48 8b 55 d0 0f 84
> [0.602215] RIP: raid6_avx21_gen_syndrome+0x3d/0x120 RSP: 9c72c00d3d70
> [0.603154] ---[ end trace 17ee01f86b8fc548 ]---
> [0.603850] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b
> [0.603850]
> [0.605276] ---[ end Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b
> ...
> ```
>
> This panic occured at lib/raid6/avx2.c#raid6_avx21_gen_syndrome() and this
> function consists of many AVX instructions.
>
> lib/raid6/avx2.c:
> ```
> /*
> * Plain AVX2 implementation
> */
> static void raid6_avx21_gen_syndrome(int disks, size_t bytes, void **ptrs)
> {
> u8 **dptr = (u8 **)ptrs;
> u8 *p, *q;
> int d, z, z0;
>
> z0 = disks - 3; /* Highest data disk */
> p = dptr[z0+1]; /* XOR parity */
> q = dptr[z0+2]; /* RS syndrome */
>
> kernel_fpu_begin();
>
> asm volatile("vmovdqa %0,%%ymm0" : : "m" (raid6_avx2_constants.x1d[0]));
> asm volatile("vpxor %ymm3,%ymm3,%ymm3");/* Zero temp */
>
> for (d = 0; d < bytes; d += 32) {
> asm volatile("prefetchnta %0" : : "m" (dptr[z0][d]));
> asm volatile("vmovdqa %0,%%ymm2" : : "m" (dptr[z0][d]));/* P[0]
> */
> asm volatile("prefetchnta %0" : : "m" (dptr[z0-1][d]));
> asm volatile("vmovdqa %ymm2,%ymm4");/* Q[0] */
> asm volatile("vmovdqa %0,%%ymm6" : : "m" (dptr[z0-1][d]));
> for (z = z0-2; z >= 0; z--) {
> asm volatile("prefetchnta %0" : : "m" (dptr[z][d]));
> asm volatile("vpcmpgtb %ymm4,%ymm3,%ymm5");
> asm volatile("vpaddb %ymm4,%ymm4,%ymm4");
> asm volatile("vpand %ymm0,%ymm5,%ymm5");
> asm volatile("vpxor %ymm5,%ymm4,%ymm4");
> asm volatile("vpxor %ymm6,%ymm2,%ymm2");
> asm volatile("vpxor %ymm6,%ymm4,%ymm4");
> asm volatile("vmovdqa %0,%%ymm6" : : "m" (dptr[z][d]));
> }
> asm volatile("vpcmpgtb %ymm4,%ymm3,%ymm5");
> asm volatile("vp
Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
At Mon, 24 Apr 2017 15:58:05 +0900,
Satoru Takeuchi wrote:
>
> [1 ]
> Recently I bought a new Ryzen machine. When I tried to test v4.11-rc8 on it,
> it failed to boot
> with the following panic log.
>
> ```
> ...
> [0.227720] raid6: sse2x1 gen() 7985 MB/s
> [0.295709] raid6: sse2x1 xor() 8181 MB/s
> [0.363706] raid6: sse2x2 gen() 17531 MB/s
> [0.431699] raid6: sse2x2 xor() 11098 MB/s
> [0.499693] raid6: sse2x4 gen() 18509 MB/s
> [0.567688] raid6: sse2x4 xor() 10177 MB/s
> [0.571692] invalid opcode: [#1] SMP
> [0.572312] Modules linked in:
> [0.572822] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc8-ktest #1
> [0.573734] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> Ubuntu-1.8.2-1ubuntu1 04/01/2014
> [0.575040] task: 8f791e1c task.stack: 9c72c00d
> [0.575865] RIP: 0010:raid6_avx21_gen_syndrome+0x3d/0x120
> [0.576634] RSP: 0018:9c72c00d3d70 EFLAGS: 00010246
> [0.577376] RAX: RBX: 9c72c00d3dc0 RCX:
> fffedb97
> [0.578327] RDX: RSI: 1000 RDI:
> 0012
> [0.579283] RBP: 9c72c00d3da0 R08: R09:
> 00cd
> [0.580243] R10: fffedb86 R11: a617008d R12:
> 1000
> [0.581211] R13: 8f791e39e000 R14: 8f791e39f000 R15:
> 0012
> [0.582163] FS: () GS:8f791fc0()
> knlGS:
> [0.583324] CS: 0010 DS: ES: CR0: 80050033
> [0.584128] CR2: CR3: 1be09000 CR4:
> 003006f0
> [0.585078] Call Trace:
> [0.594952] raid6_select_algo+0x116/0x30b
> [0.595592] ? libcrc32c_mod_init+0x2b/0x2b
> [0.596240] do_one_initcall+0x53/0x1a0
> [0.596843] ? parse_args+0x2cf/0x490
> [0.597421] kernel_init_freeable+0x182/0x21c
> [0.598077] ? rest_init+0x80/0x80
> [0.598626] kernel_init+0xe/0x100
> [0.599175] ret_from_fork+0x2c/0x40
> [0.599741] Code: 55 41 54 53 48 89 d3 48 8d 14 c5 00 00 00 00 41 89 ff 49
> 89 f4 48 83 ec 08 4c 8b 2c c3 4c 8b 74 13 08 48 89 55 d0 e8 53 ed a9 ff
> fd 6f 05 2b 2d 4e 00 c5 e5 ef db 4d 85 e4 48 8b 55 d0 0f 84
> [0.602215] RIP: raid6_avx21_gen_syndrome+0x3d/0x120 RSP: 9c72c00d3d70
> [0.603154] ---[ end trace 17ee01f86b8fc548 ]---
> [0.603850] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b
> [0.603850]
> [0.605276] ---[ end Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b
> ...
> ```
>
> This panic occured at lib/raid6/avx2.c#raid6_avx21_gen_syndrome() and this
> function consists of many AVX instructions.
>
> lib/raid6/avx2.c:
> ```
> /*
> * Plain AVX2 implementation
> */
> static void raid6_avx21_gen_syndrome(int disks, size_t bytes, void **ptrs)
> {
> u8 **dptr = (u8 **)ptrs;
> u8 *p, *q;
> int d, z, z0;
>
> z0 = disks - 3; /* Highest data disk */
> p = dptr[z0+1]; /* XOR parity */
> q = dptr[z0+2]; /* RS syndrome */
>
> kernel_fpu_begin();
>
> asm volatile("vmovdqa %0,%%ymm0" : : "m" (raid6_avx2_constants.x1d[0]));
> asm volatile("vpxor %ymm3,%ymm3,%ymm3");/* Zero temp */
>
> for (d = 0; d < bytes; d += 32) {
> asm volatile("prefetchnta %0" : : "m" (dptr[z0][d]));
> asm volatile("vmovdqa %0,%%ymm2" : : "m" (dptr[z0][d]));/* P[0]
> */
> asm volatile("prefetchnta %0" : : "m" (dptr[z0-1][d]));
> asm volatile("vmovdqa %ymm2,%ymm4");/* Q[0] */
> asm volatile("vmovdqa %0,%%ymm6" : : "m" (dptr[z0-1][d]));
> for (z = z0-2; z >= 0; z--) {
> asm volatile("prefetchnta %0" : : "m" (dptr[z][d]));
> asm volatile("vpcmpgtb %ymm4,%ymm3,%ymm5");
> asm volatile("vpaddb %ymm4,%ymm4,%ymm4");
> asm volatile("vpand %ymm0,%ymm5,%ymm5");
> asm volatile("vpxor %ymm5,%ymm4,%ymm4");
> asm volatile("vpxor %ymm6,%ymm2,%ymm2");
> asm volatile("vpxor %ymm6,%ymm4,%ymm4");
> asm volatile("vmovdqa %0,%%ymm6" : : "m" (dptr[z][d]));
> }
> asm volatile("vpcmpgtb %ymm4,%ymm3,%ymm5");
> asm volatile("vp
[BUG] x86: failed to boot a kernel on a Ryzen machine
Recently I bought a new Ryzen machine. When I tried to test v4.11-rc8 on it, it
failed to boot
with the following panic log.
```
...
[0.227720] raid6: sse2x1 gen() 7985 MB/s
[0.295709] raid6: sse2x1 xor() 8181 MB/s
[0.363706] raid6: sse2x2 gen() 17531 MB/s
[0.431699] raid6: sse2x2 xor() 11098 MB/s
[0.499693] raid6: sse2x4 gen() 18509 MB/s
[0.567688] raid6: sse2x4 xor() 10177 MB/s
[0.571692] invalid opcode: [#1] SMP
[0.572312] Modules linked in:
[0.572822] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc8-ktest #1
[0.573734] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Ubuntu-1.8.2-1ubuntu1 04/01/2014
[0.575040] task: 8f791e1c task.stack: 9c72c00d
[0.575865] RIP: 0010:raid6_avx21_gen_syndrome+0x3d/0x120
[0.576634] RSP: 0018:9c72c00d3d70 EFLAGS: 00010246
[0.577376] RAX: RBX: 9c72c00d3dc0 RCX: fffedb97
[0.578327] RDX: RSI: 1000 RDI: 0012
[0.579283] RBP: 9c72c00d3da0 R08: R09: 00cd
[0.580243] R10: fffedb86 R11: a617008d R12: 1000
[0.581211] R13: 8f791e39e000 R14: 8f791e39f000 R15: 0012
[0.582163] FS: () GS:8f791fc0()
knlGS:
[0.583324] CS: 0010 DS: ES: CR0: 80050033
[0.584128] CR2: CR3: 1be09000 CR4: 003006f0
[0.585078] Call Trace:
[0.594952] raid6_select_algo+0x116/0x30b
[0.595592] ? libcrc32c_mod_init+0x2b/0x2b
[0.596240] do_one_initcall+0x53/0x1a0
[0.596843] ? parse_args+0x2cf/0x490
[0.597421] kernel_init_freeable+0x182/0x21c
[0.598077] ? rest_init+0x80/0x80
[0.598626] kernel_init+0xe/0x100
[0.599175] ret_from_fork+0x2c/0x40
[0.599741] Code: 55 41 54 53 48 89 d3 48 8d 14 c5 00 00 00 00 41 89 ff 49
89 f4 48 83 ec 08 4c 8b 2c c3 4c 8b 74 13 08 48 89 55 d0 e8 53 ed a9 ff fd
6f 05 2b 2d 4e 00 c5 e5 ef db 4d 85 e4 48 8b 55 d0 0f 84
[0.602215] RIP: raid6_avx21_gen_syndrome+0x3d/0x120 RSP: 9c72c00d3d70
[0.603154] ---[ end trace 17ee01f86b8fc548 ]---
[0.603850] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[0.603850]
[0.605276] ---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
...
```
This panic occured at lib/raid6/avx2.c#raid6_avx21_gen_syndrome() and this
function consists of many AVX instructions.
lib/raid6/avx2.c:
```
/*
* Plain AVX2 implementation
*/
static void raid6_avx21_gen_syndrome(int disks, size_t bytes, void **ptrs)
{
u8 **dptr = (u8 **)ptrs;
u8 *p, *q;
int d, z, z0;
z0 = disks - 3; /* Highest data disk */
p = dptr[z0+1]; /* XOR parity */
q = dptr[z0+2]; /* RS syndrome */
kernel_fpu_begin();
asm volatile("vmovdqa %0,%%ymm0" : : "m" (raid6_avx2_constants.x1d[0]));
asm volatile("vpxor %ymm3,%ymm3,%ymm3");/* Zero temp */
for (d = 0; d < bytes; d += 32) {
asm volatile("prefetchnta %0" : : "m" (dptr[z0][d]));
asm volatile("vmovdqa %0,%%ymm2" : : "m" (dptr[z0][d]));/* P[0]
*/
asm volatile("prefetchnta %0" : : "m" (dptr[z0-1][d]));
asm volatile("vmovdqa %ymm2,%ymm4");/* Q[0] */
asm volatile("vmovdqa %0,%%ymm6" : : "m" (dptr[z0-1][d]));
for (z = z0-2; z >= 0; z--) {
asm volatile("prefetchnta %0" : : "m" (dptr[z][d]));
asm volatile("vpcmpgtb %ymm4,%ymm3,%ymm5");
asm volatile("vpaddb %ymm4,%ymm4,%ymm4");
asm volatile("vpand %ymm0,%ymm5,%ymm5");
asm volatile("vpxor %ymm5,%ymm4,%ymm4");
asm volatile("vpxor %ymm6,%ymm2,%ymm2");
asm volatile("vpxor %ymm6,%ymm4,%ymm4");
asm volatile("vmovdqa %0,%%ymm6" : : "m" (dptr[z][d]));
}
asm volatile("vpcmpgtb %ymm4,%ymm3,%ymm5");
asm volatile("vpaddb %ymm4,%ymm4,%ymm4");
asm volatile("vpand %ymm0,%ymm5,%ymm5");
asm volatile("vpxor %ymm5,%ymm4,%ymm4");
asm volatile("vpxor %ymm6,%ymm2,%ymm2");
asm volatile("vpxor %ymm6,%ymm4,%ymm4");
asm volatile("vmovntdq %%ymm2,%0" : "=m" (p[d]));
asm volatile("vpxor %ymm2,%ymm2,%ymm2");
asm volatile("vmovntdq %%ymm4,%0" : "=m" (q[d]));
asm volatile("vpxor %ymm4,%ymm4,%ymm4");
}
asm volatile("sfence" : : : "memory");
kernel_fpu_end();
}
```
This problem can be bypassed by the following patch.
```
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 2d44933..b589097 100644
--- a/arch/x86/Makefile
+++
[BUG] x86: failed to boot a kernel on a Ryzen machine
Recently I bought a new Ryzen machine. When I tried to test v4.11-rc8 on it, it
failed to boot
with the following panic log.
```
...
[0.227720] raid6: sse2x1 gen() 7985 MB/s
[0.295709] raid6: sse2x1 xor() 8181 MB/s
[0.363706] raid6: sse2x2 gen() 17531 MB/s
[0.431699] raid6: sse2x2 xor() 11098 MB/s
[0.499693] raid6: sse2x4 gen() 18509 MB/s
[0.567688] raid6: sse2x4 xor() 10177 MB/s
[0.571692] invalid opcode: [#1] SMP
[0.572312] Modules linked in:
[0.572822] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc8-ktest #1
[0.573734] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Ubuntu-1.8.2-1ubuntu1 04/01/2014
[0.575040] task: 8f791e1c task.stack: 9c72c00d
[0.575865] RIP: 0010:raid6_avx21_gen_syndrome+0x3d/0x120
[0.576634] RSP: 0018:9c72c00d3d70 EFLAGS: 00010246
[0.577376] RAX: RBX: 9c72c00d3dc0 RCX: fffedb97
[0.578327] RDX: RSI: 1000 RDI: 0012
[0.579283] RBP: 9c72c00d3da0 R08: R09: 00cd
[0.580243] R10: fffedb86 R11: a617008d R12: 1000
[0.581211] R13: 8f791e39e000 R14: 8f791e39f000 R15: 0012
[0.582163] FS: () GS:8f791fc0()
knlGS:
[0.583324] CS: 0010 DS: ES: CR0: 80050033
[0.584128] CR2: CR3: 1be09000 CR4: 003006f0
[0.585078] Call Trace:
[0.594952] raid6_select_algo+0x116/0x30b
[0.595592] ? libcrc32c_mod_init+0x2b/0x2b
[0.596240] do_one_initcall+0x53/0x1a0
[0.596843] ? parse_args+0x2cf/0x490
[0.597421] kernel_init_freeable+0x182/0x21c
[0.598077] ? rest_init+0x80/0x80
[0.598626] kernel_init+0xe/0x100
[0.599175] ret_from_fork+0x2c/0x40
[0.599741] Code: 55 41 54 53 48 89 d3 48 8d 14 c5 00 00 00 00 41 89 ff 49
89 f4 48 83 ec 08 4c 8b 2c c3 4c 8b 74 13 08 48 89 55 d0 e8 53 ed a9 ff fd
6f 05 2b 2d 4e 00 c5 e5 ef db 4d 85 e4 48 8b 55 d0 0f 84
[0.602215] RIP: raid6_avx21_gen_syndrome+0x3d/0x120 RSP: 9c72c00d3d70
[0.603154] ---[ end trace 17ee01f86b8fc548 ]---
[0.603850] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[0.603850]
[0.605276] ---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
...
```
This panic occured at lib/raid6/avx2.c#raid6_avx21_gen_syndrome() and this
function consists of many AVX instructions.
lib/raid6/avx2.c:
```
/*
* Plain AVX2 implementation
*/
static void raid6_avx21_gen_syndrome(int disks, size_t bytes, void **ptrs)
{
u8 **dptr = (u8 **)ptrs;
u8 *p, *q;
int d, z, z0;
z0 = disks - 3; /* Highest data disk */
p = dptr[z0+1]; /* XOR parity */
q = dptr[z0+2]; /* RS syndrome */
kernel_fpu_begin();
asm volatile("vmovdqa %0,%%ymm0" : : "m" (raid6_avx2_constants.x1d[0]));
asm volatile("vpxor %ymm3,%ymm3,%ymm3");/* Zero temp */
for (d = 0; d < bytes; d += 32) {
asm volatile("prefetchnta %0" : : "m" (dptr[z0][d]));
asm volatile("vmovdqa %0,%%ymm2" : : "m" (dptr[z0][d]));/* P[0]
*/
asm volatile("prefetchnta %0" : : "m" (dptr[z0-1][d]));
asm volatile("vmovdqa %ymm2,%ymm4");/* Q[0] */
asm volatile("vmovdqa %0,%%ymm6" : : "m" (dptr[z0-1][d]));
for (z = z0-2; z >= 0; z--) {
asm volatile("prefetchnta %0" : : "m" (dptr[z][d]));
asm volatile("vpcmpgtb %ymm4,%ymm3,%ymm5");
asm volatile("vpaddb %ymm4,%ymm4,%ymm4");
asm volatile("vpand %ymm0,%ymm5,%ymm5");
asm volatile("vpxor %ymm5,%ymm4,%ymm4");
asm volatile("vpxor %ymm6,%ymm2,%ymm2");
asm volatile("vpxor %ymm6,%ymm4,%ymm4");
asm volatile("vmovdqa %0,%%ymm6" : : "m" (dptr[z][d]));
}
asm volatile("vpcmpgtb %ymm4,%ymm3,%ymm5");
asm volatile("vpaddb %ymm4,%ymm4,%ymm4");
asm volatile("vpand %ymm0,%ymm5,%ymm5");
asm volatile("vpxor %ymm5,%ymm4,%ymm4");
asm volatile("vpxor %ymm6,%ymm2,%ymm2");
asm volatile("vpxor %ymm6,%ymm4,%ymm4");
asm volatile("vmovntdq %%ymm2,%0" : "=m" (p[d]));
asm volatile("vpxor %ymm2,%ymm2,%ymm2");
asm volatile("vmovntdq %%ymm4,%0" : "=m" (q[d]));
asm volatile("vpxor %ymm4,%ymm4,%ymm4");
}
asm volatile("sfence" : : : "memory");
kernel_fpu_end();
}
```
This problem can be bypassed by the following patch.
```
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 2d44933..b589097 100644
--- a/arch/x86/Makefile
+++
Linux kernel statistics from the other perspective than existing ones
I wrote an article about linux kernel statistics by analyzing linux kernel source code. Although there are many such the articles, most of them mainly focus on who develops linux kernel. However, this article doesn't care about that at all. It focuses on the following things instead. - Which subsystems the kernel consists of? - Which type of drivers are the main contents in the whole drivers code? - Whether the newly added drivers code are mainly for new drivers or for existing ones? - What are the characteristics of both rc kernels and stable kernels? Please take a look at it. https://github.com/satoru-takeuchi/linux-kernel-statistics/blob/master/README.md Thanks, Satoru
Linux kernel statistics from the other perspective than existing ones
I wrote an article about linux kernel statistics by analyzing linux kernel source code. Although there are many such the articles, most of them mainly focus on who develops linux kernel. However, this article doesn't care about that at all. It focuses on the following things instead. - Which subsystems the kernel consists of? - Which type of drivers are the main contents in the whole drivers code? - Whether the newly added drivers code are mainly for new drivers or for existing ones? - What are the characteristics of both rc kernels and stable kernels? Please take a look at it. https://github.com/satoru-takeuchi/linux-kernel-statistics/blob/master/README.md Thanks, Satoru
[PATCH] cgroup: change the limit of CGROUP_SUBSYS_COUNT depending on the size of the corresponding bitmasks
The limit of CGROUP_SUBSYS_COUNT is hardcoded to 16. This value comes from the size of the corresponding bitmasks, u16. It's better to change this limit depending on the size of the corresponding bitmasks because of the following reasons. - to avoid setting the wrong limit when the size of the corresponding bitmasks are changed - to make the meaning of this limit clear Signed-off-by: Satoru Takeuchi <satoru.takeu...@gmail.com> --- kernel/cgroup/cgroup.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c index 4885132..576b184 100644 --- a/kernel/cgroup/cgroup.c +++ b/kernel/cgroup/cgroup.c @@ -4490,7 +4490,8 @@ int __init cgroup_init(void) struct cgroup_subsys *ss; int ssid; - BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > 16); + BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > (sizeof(cgroup_disable_mask) * __CHAR_BIT__)); + BUG_ON(percpu_init_rwsem(_threadgroup_rwsem)); BUG_ON(cgroup_init_cftypes(NULL, cgroup_base_files)); BUG_ON(cgroup_init_cftypes(NULL, cgroup1_base_files)); -- 2.7.4
[PATCH] cgroup: change the limit of CGROUP_SUBSYS_COUNT depending on the size of the corresponding bitmasks
The limit of CGROUP_SUBSYS_COUNT is hardcoded to 16. This value comes from the size of the corresponding bitmasks, u16. It's better to change this limit depending on the size of the corresponding bitmasks because of the following reasons. - to avoid setting the wrong limit when the size of the corresponding bitmasks are changed - to make the meaning of this limit clear Signed-off-by: Satoru Takeuchi --- kernel/cgroup/cgroup.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c index 4885132..576b184 100644 --- a/kernel/cgroup/cgroup.c +++ b/kernel/cgroup/cgroup.c @@ -4490,7 +4490,8 @@ int __init cgroup_init(void) struct cgroup_subsys *ss; int ssid; - BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > 16); + BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > (sizeof(cgroup_disable_mask) * __CHAR_BIT__)); + BUG_ON(percpu_init_rwsem(_threadgroup_rwsem)); BUG_ON(cgroup_init_cftypes(NULL, cgroup_base_files)); BUG_ON(cgroup_init_cftypes(NULL, cgroup1_base_files)); -- 2.7.4
[ANNOUNCE] elkdat: an easy linux kernel development and test tool
elkdat is a tool to ease linux kernel development/test. It automatically setups linux kernel source repository and a VM for linux kernel development and test. In addition, It runs the following kinds of tests automatically just by one command. - build, install, boot you own kernel - run your own tests on your own kernel - test the all patches in a patchset - find a problematic commit with bisect NOTE: Actually these features are achieved by ktest. elkdat is just a ktest's wrapper. Special thanks to Steven Rostedt! Here are some examples. * Boot your own kernel ``` $ ./test boot ``` * Run your own test on your own kernel ``` $ ./test test /path/to/your/own/test ``` * Test whether all patches in your patcheset are bootable or not one by one ``` $ ./test patchcheck boot ``` * Find which commit introduces an un-bootable bug by bysect ``` ./test bisect boot ``` For more information, please refer to the following URL. https://github.com/satoru-takeuchi/elkdat Thanks, Satoru
[ANNOUNCE] elkdat: an easy linux kernel development and test tool
elkdat is a tool to ease linux kernel development/test. It automatically setups linux kernel source repository and a VM for linux kernel development and test. In addition, It runs the following kinds of tests automatically just by one command. - build, install, boot you own kernel - run your own tests on your own kernel - test the all patches in a patchset - find a problematic commit with bisect NOTE: Actually these features are achieved by ktest. elkdat is just a ktest's wrapper. Special thanks to Steven Rostedt! Here are some examples. * Boot your own kernel ``` $ ./test boot ``` * Run your own test on your own kernel ``` $ ./test test /path/to/your/own/test ``` * Test whether all patches in your patcheset are bootable or not one by one ``` $ ./test patchcheck boot ``` * Find which commit introduces an un-bootable bug by bysect ``` ./test bisect boot ``` For more information, please refer to the following URL. https://github.com/satoru-takeuchi/elkdat Thanks, Satoru
[PATCH] mm: remove unnecessary description about a non-exist gfp flag
Since __GFP_NOACCOUNT is removed by the following commit,
its description is not necessary.
commit 20b5c3039863 ("Revert 'gfp: add __GFP_NOACCOUNT'")
Signed-off-by: Satoru Takeuchi <takeuchi_sat...@jp.fujitsu.com>
---
include/linux/gfp.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index af1f2b2..7c76a6e 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -101,8 +101,6 @@ struct vm_area_struct;
*
* __GFP_NOMEMALLOC is used to explicitly forbid access to emergency reserves.
* This takes precedence over the __GFP_MEMALLOC flag if both are set.
- *
- * __GFP_NOACCOUNT ignores the accounting for kmemcg limit enforcement.
*/
#define __GFP_ATOMIC ((__force gfp_t)___GFP_ATOMIC)
#define __GFP_HIGH ((__force gfp_t)___GFP_HIGH)
--
2.5.0
[PATCH] mm: remove unnecessary description about a non-exist gfp flag
Since __GFP_NOACCOUNT is removed by the following commit,
its description is not necessary.
commit 20b5c3039863 ("Revert 'gfp: add __GFP_NOACCOUNT'")
Signed-off-by: Satoru Takeuchi
---
include/linux/gfp.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index af1f2b2..7c76a6e 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -101,8 +101,6 @@ struct vm_area_struct;
*
* __GFP_NOMEMALLOC is used to explicitly forbid access to emergency reserves.
* This takes precedence over the __GFP_MEMALLOC flag if both are set.
- *
- * __GFP_NOACCOUNT ignores the accounting for kmemcg limit enforcement.
*/
#define __GFP_ATOMIC ((__force gfp_t)___GFP_ATOMIC)
#define __GFP_HIGH ((__force gfp_t)___GFP_HIGH)
--
2.5.0
Re: [PATCH 3.12 00/78] 3.12.36-stable review
At Fri, 9 Jan 2015 09:59:10 -0800, Guenter Roeck wrote: > > On Fri, Jan 09, 2015 at 11:30:32AM +0100, Jiri Slaby wrote: > > This is the start of the stable review cycle for the 3.12.36 release. > > There are 78 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. > > > > Responses should be made by Tue Jan 13 11:29:45 CET 2015. > > Anything received after that time might be too late. > > > Build results: > total: 135 pass: 135 fail: 0 > Qemu tests: > total: 27 pass: 27 fail: 0 > > Details are available at http://server.roeck-us.net:8010/builders. > > Guenter Plus, this kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 00/78] 3.12.36-stable review
At Fri, 9 Jan 2015 09:59:10 -0800, Guenter Roeck wrote: On Fri, Jan 09, 2015 at 11:30:32AM +0100, Jiri Slaby wrote: This is the start of the stable review cycle for the 3.12.36 release. There are 78 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. Responses should be made by Tue Jan 13 11:29:45 CET 2015. Anything received after that time might be too late. Build results: total: 135 pass: 135 fail: 0 Qemu tests: total: 27 pass: 27 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. Guenter Plus, this kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.18 00/84] 3.18.2-stable review
At Tue, 6 Jan 2015 17:49:03 -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.18.2 release. > There are 84 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. > > Responses should be made by Fri Jan 9 01:40:07 UTC 2015. > Anything received after that time might be too late. All 3.10.64-rc1, 3.14.28-rc1, 3.17.8-rc1, and 3.18.2-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.18.2-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > > - > Pseudo-Shortlog of commits: > > Greg Kroah-Hartman > Linux 3.18.2-rc1 > > Filipe Manana > Btrfs: fix fs corruption on transaction abort if device supports discard > > Josef Bacik > Btrfs: make sure logged extents complete in the current transaction V3 > > Josef Bacik > Btrfs: do not move em to modified list when unpinning > > David Sterba > btrfs: fix wrong accounting of raid1 data profile in statfs > > Josef Bacik > Btrfs: make sure we wait on logged extents when fsycning two subvols > > Michael Halcrow > eCryptfs: Remove buggy and unnecessary write in file name decode routine > > Tyler Hicks > eCryptfs: Force RO mount when encrypted view is enabled > > Jan Kara > udf: Check component length before reading it > > Jan Kara > udf: Verify symlink size before loading it > > Jan Kara > udf: Verify i_size when loading inode > > Jan Kara > udf: Check path length when reading symlink > > Oleg Nesterov > exit: pidns: alloc_pid() leaks pid_namespace if child_reaper is exiting > > Joonsoo Kim > mm/CMA: fix boot regression due to physical address of high_memory > > Jan Kara > ncpfs: return proper error from NCP_IOC_SETROOT ioctl > > Rabin Vincent > crypto: af_alg - fix backlog handling > > Richard Guy Briggs > audit: restore AUDIT_LOGINUID unset ABI > > Paul Moore > audit: don't attempt to lookup PIDs when changing PID filtering audit > rules > > Richard Guy Briggs > audit: use supplied gfp_mask from audit_buffer in > kauditd_send_multicast_skb > > Eric W. Biederman > userns: Unbreak the unprivileged remount tests > > Eric W. Biederman > userns: Allow setting gid_maps without privilege when setgroups is > disabled > > Eric W. Biederman > userns: Add a knob to disable setgroups on a per user namespace basis > > Eric W. Biederman > userns: Rename id_map_mutex to userns_state_mutex > > Eric W. Biederman > userns: Only allow the creator of the userns unprivileged mappings > > Eric W. Biederman > userns: Check euid no fsuid when establishing an unprivileged uid mapping > > Eric W. Biederman > userns: Don't allow unprivileged creation of gid mappings > > Eric W. Biederman > userns: Don't allow setgroups until a gid mapping has been setablished > > Eric W. Biederman > userns: Document what the invariant required for safe unprivileged > mappings. > > Eric W. Biederman > groups: Consolidate the setgroups permission checks > > Eric W. Biederman > umount: Disallow unprivileged mount force > > Eric W. Biederman > mnt: Update unprivileged remount test > > Eric W. Biederman > mnt: Implicitly add MNT_NODEV on remount when it was implicitly added by > mount > > Luis Henriques > thermal: Fix error path in thermal_init() > > Eric W. Biederman > mnt: Fix a memory stomp in umount > > Johannes Berg > mac80211: free management frame keys when removing station > > Andreas Müller > mac80211: fix multicast LED blinking and counter > > Jes Sorensen > mac80211: avoid using uninitialized stack data > > Felix Fietkau > mac80211: copy chandef from AP vif to VLANs > > Takashi Iwai > KEYS: Fix stale key registration at error path &
Re: [PATCH 3.18 00/84] 3.18.2-stable review
At Tue, 6 Jan 2015 17:49:03 -0800, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.18.2 release. There are 84 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. Responses should be made by Fri Jan 9 01:40:07 UTC 2015. Anything received after that time might be too late. All 3.10.64-rc1, 3.14.28-rc1, 3.17.8-rc1, and 3.18.2-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.18.2-rc1.gz and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman gre...@linuxfoundation.org Linux 3.18.2-rc1 Filipe Manana fdman...@suse.com Btrfs: fix fs corruption on transaction abort if device supports discard Josef Bacik jba...@fb.com Btrfs: make sure logged extents complete in the current transaction V3 Josef Bacik jba...@fb.com Btrfs: do not move em to modified list when unpinning David Sterba dste...@suse.cz btrfs: fix wrong accounting of raid1 data profile in statfs Josef Bacik jba...@fb.com Btrfs: make sure we wait on logged extents when fsycning two subvols Michael Halcrow mhalc...@google.com eCryptfs: Remove buggy and unnecessary write in file name decode routine Tyler Hicks tyhi...@canonical.com eCryptfs: Force RO mount when encrypted view is enabled Jan Kara j...@suse.cz udf: Check component length before reading it Jan Kara j...@suse.cz udf: Verify symlink size before loading it Jan Kara j...@suse.cz udf: Verify i_size when loading inode Jan Kara j...@suse.cz udf: Check path length when reading symlink Oleg Nesterov o...@redhat.com exit: pidns: alloc_pid() leaks pid_namespace if child_reaper is exiting Joonsoo Kim iamjoonsoo@lge.com mm/CMA: fix boot regression due to physical address of high_memory Jan Kara j...@suse.cz ncpfs: return proper error from NCP_IOC_SETROOT ioctl Rabin Vincent rabin.vinc...@axis.com crypto: af_alg - fix backlog handling Richard Guy Briggs r...@redhat.com audit: restore AUDIT_LOGINUID unset ABI Paul Moore pmo...@redhat.com audit: don't attempt to lookup PIDs when changing PID filtering audit rules Richard Guy Briggs r...@redhat.com audit: use supplied gfp_mask from audit_buffer in kauditd_send_multicast_skb Eric W. Biederman ebied...@xmission.com userns: Unbreak the unprivileged remount tests Eric W. Biederman ebied...@xmission.com userns: Allow setting gid_maps without privilege when setgroups is disabled Eric W. Biederman ebied...@xmission.com userns: Add a knob to disable setgroups on a per user namespace basis Eric W. Biederman ebied...@xmission.com userns: Rename id_map_mutex to userns_state_mutex Eric W. Biederman ebied...@xmission.com userns: Only allow the creator of the userns unprivileged mappings Eric W. Biederman ebied...@xmission.com userns: Check euid no fsuid when establishing an unprivileged uid mapping Eric W. Biederman ebied...@xmission.com userns: Don't allow unprivileged creation of gid mappings Eric W. Biederman ebied...@xmission.com userns: Don't allow setgroups until a gid mapping has been setablished Eric W. Biederman ebied...@xmission.com userns: Document what the invariant required for safe unprivileged mappings. Eric W. Biederman ebied...@xmission.com groups: Consolidate the setgroups permission checks Eric W. Biederman ebied...@xmission.com umount: Disallow unprivileged mount force Eric W. Biederman ebied...@xmission.com mnt: Update unprivileged remount test Eric W. Biederman ebied...@xmission.com mnt: Implicitly add MNT_NODEV on remount when it was implicitly added by mount Luis Henriques luis.henriq...@canonical.com thermal: Fix error path in thermal_init() Eric W. Biederman ebied...@xmission.com mnt: Fix a memory stomp in umount Johannes Berg johannes.b...@intel.com mac80211: free management frame keys when removing station Andreas Müller g...@stapelspeicher.org mac80211: fix multicast LED blinking and counter Jes Sorensen jes.soren...@redhat.com mac80211: avoid using
Re: [PATCH] btrfs: clear bio reference after submit_one_bio()
Hi Naota, On 2015/01/06 1:01, Naohiro Aota wrote: > After submit_one_bio(), `bio' can go away. However submit_extent_page() > leave `bio' referable if submit_one_bio() failed (e.g. -ENOMEM on OOM). > It will cause invalid paging request when submit_extent_page() is called > next time. > > I reproduced ENOMEM case with the following script (need > CONFIG_FAIL_PAGE_ALLOC, and CONFIG_FAULT_INJECTION_DEBUG_FS). I confirmed that this problem reproduce with 3.19-rc3 and not reproduce with 3.19-rc3 with your patch. Tested-by: Satoru Takeuchi Thank you for reporting this problem with the reproducer and fixing it too. NOTE: I used v3.19-rc3's tools/testing/fault-injection/failcmd.sh for the following "./failcmd.sh". >./failcmd.sh -p $percent -t $times -i $interval \ >--ignore-gfp-highmem=N --ignore-gfp-wait=N --min-order=0 \ >-- \ >cat $directory/file > /dev/null * 3.19-rc1 + your patch === # ./run 512+0 records in 512+0 records out # === * 3.19-rc3 === # ./run 512+0 records in 512+0 records out [ 188.433726] run (776): drop_caches: 1 [ 188.682372] FAULT_INJECTION: forcing a failure. name fail_page_alloc, interval 100, probability 111000, space 0, times 3 [ 188.689986] CPU: 0 PID: 954 Comm: cat Not tainted 3.19.0-rc3-ktest #1 [ 188.693834] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [ 188.698466] 0064 88007b343618 816e5563 88007fc0fc78 [ 188.702730] 81c655c0 88007b343638 813851b5 0010 [ 188.707043] 0002 88007b343768 81188126 88007b3435a8 [ 188.711283] Call Trace: [ 188.712620] [] dump_stack+0x45/0x57 [ 188.715330] [] should_fail+0x135/0x140 [ 188.718218] [] __alloc_pages_nodemask+0xd6/0xb30 [ 188.721567] [] ? blk_rq_map_sg+0x35/0x170 [ 188.724558] [] ? virtio_queue_rq+0x145/0x2b0 [virtio_blk] [ 188.728191] [] ? btrfs_submit_compressed_read+0xcf/0x4d0 [btrfs] [ 188.732079] [] ? kmem_cache_alloc+0x1cb/0x230 [ 188.735153] [] ? mempool_alloc_slab+0x15/0x20 [ 188.738188] [] alloc_pages_current+0x9a/0x120 [ 188.741153] [] btrfs_submit_compressed_read+0x1a9/0x4d0 [btrfs] [ 188.744835] [] btrfs_submit_bio_hook+0x1c1/0x1d0 [btrfs] [ 188.748225] [] ? lookup_extent_mapping+0x13/0x20 [btrfs] [ 188.751547] [] ? btrfs_get_extent+0x98/0xad0 [btrfs] [ 188.754656] [] submit_one_bio+0x67/0xa0 [btrfs] [ 188.757554] [] submit_extent_page.isra.35+0xd7/0x1c0 [btrfs] [ 188.760981] [] __do_readpage+0x31d/0x7b0 [btrfs] [ 188.763920] [] ? btrfs_create_repair_bio+0x110/0x110 [btrfs] [ 188.767382] [] ? btrfs_submit_direct+0x7b0/0x7b0 [btrfs] [ 188.770671] [] ? btrfs_lookup_ordered_range+0x13d/0x180 [btrfs] [ 188.774366] [] __extent_readpages.constprop.42+0x2ba/0x2d0 [btrfs] [ 188.778031] [] ? btrfs_submit_direct+0x7b0/0x7b0 [btrfs] [ 188.781241] [] extent_readpages+0x169/0x1b0 [btrfs] [ 188.784322] [] ? btrfs_submit_direct+0x7b0/0x7b0 [btrfs] [ 188.789014] [] btrfs_readpages+0x1f/0x30 [btrfs] [ 188.792028] [] __do_page_cache_readahead+0x18c/0x1f0 [ 188.795078] [] ondemand_readahead+0xdf/0x260 [ 188.797702] [] ? btrfs_congested_fn+0x5f/0xa0 [btrfs] [ 188.800718] [] page_cache_async_readahead+0x71/0xa0 [ 188.803650] [] generic_file_read_iter+0x40f/0x5e0 [ 188.806480] [] new_sync_read+0x7e/0xb0 [ 188.808832] [] __vfs_read+0x18/0x50 [ 188.811068] [] vfs_read+0x8a/0x140 [ 188.813298] [] SyS_read+0x46/0xb0 [ 188.815486] [] ? __audit_syscall_exit+0x1f6/0x2a0 [ 188.818293] [] system_call_fastpath+0x12/0x17 [ 188.821005] BUG: unable to handle kernel paging request at 0001000c [ 188.821984] IP: [] submit_one_bio+0x43/0xa0 [btrfs] [ 188.821984] PGD 7bad3067 PUD 0 [ 188.821984] Oops: [#1] SMP [ 188.821984] Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables bnep bluetooth rfkill btrfs xor raid6_pq microcode 8139too serio_raw virtio_balloon 8139cp mii nfsd auth_rpcgss nfs_acl lockd grace sunrpc virtio_blk ata_generic pata_acpi [ 188.821984] CPU: 1 PID: 954 Comm: cat Not tainted 3.19.0-rc3-ktest #1 [ 188.821984] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [ 188.821984] task: 880037665220 ti: 88007b34 task.ti: 88007b34 [ 188.821984] RIP: 0010:[] [] submit_one_bio+0x43/0xa0 [btrfs] [ 188.821984] RSP: 0018:88007b3438c8 EFLAGS: 00010202 [ 188.821984] RAX: RBX: 88007c282ba8 RCX: 00010001 [ 188.821984] RDX: RSI: fff4 RDI: [ 188.821984] RBP: 88007b3438d8 R08: ea0001e33100 R09: 000
Re: [PATCH] btrfs: clear bio reference after submit_one_bio()
Hi Naota, On 2015/01/06 1:01, Naohiro Aota wrote: After submit_one_bio(), `bio' can go away. However submit_extent_page() leave `bio' referable if submit_one_bio() failed (e.g. -ENOMEM on OOM). It will cause invalid paging request when submit_extent_page() is called next time. I reproduced ENOMEM case with the following script (need CONFIG_FAIL_PAGE_ALLOC, and CONFIG_FAULT_INJECTION_DEBUG_FS). I confirmed that this problem reproduce with 3.19-rc3 and not reproduce with 3.19-rc3 with your patch. Tested-by: Satoru Takeuchi takeuchi_sat...@jp.fujitsu.com Thank you for reporting this problem with the reproducer and fixing it too. NOTE: I used v3.19-rc3's tools/testing/fault-injection/failcmd.sh for the following ./failcmd.sh. ./failcmd.sh -p $percent -t $times -i $interval \ --ignore-gfp-highmem=N --ignore-gfp-wait=N --min-order=0 \ -- \ cat $directory/file /dev/null * 3.19-rc1 + your patch === # ./run 512+0 records in 512+0 records out # === * 3.19-rc3 === # ./run 512+0 records in 512+0 records out [ 188.433726] run (776): drop_caches: 1 [ 188.682372] FAULT_INJECTION: forcing a failure. name fail_page_alloc, interval 100, probability 111000, space 0, times 3 [ 188.689986] CPU: 0 PID: 954 Comm: cat Not tainted 3.19.0-rc3-ktest #1 [ 188.693834] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [ 188.698466] 0064 88007b343618 816e5563 88007fc0fc78 [ 188.702730] 81c655c0 88007b343638 813851b5 0010 [ 188.707043] 0002 88007b343768 81188126 88007b3435a8 [ 188.711283] Call Trace: [ 188.712620] [816e5563] dump_stack+0x45/0x57 [ 188.715330] [813851b5] should_fail+0x135/0x140 [ 188.718218] [81188126] __alloc_pages_nodemask+0xd6/0xb30 [ 188.721567] [81339075] ? blk_rq_map_sg+0x35/0x170 [ 188.724558] [a0010705] ? virtio_queue_rq+0x145/0x2b0 [virtio_blk] [ 188.728191] [a01bd00f] ? btrfs_submit_compressed_read+0xcf/0x4d0 [btrfs] [ 188.732079] [811d99fb] ? kmem_cache_alloc+0x1cb/0x230 [ 188.735153] [81181265] ? mempool_alloc_slab+0x15/0x20 [ 188.738188] [811cee1a] alloc_pages_current+0x9a/0x120 [ 188.741153] [a01bd0e9] btrfs_submit_compressed_read+0x1a9/0x4d0 [btrfs] [ 188.744835] [a0178621] btrfs_submit_bio_hook+0x1c1/0x1d0 [btrfs] [ 188.748225] [a018b7b3] ? lookup_extent_mapping+0x13/0x20 [btrfs] [ 188.751547] [a0179c08] ? btrfs_get_extent+0x98/0xad0 [btrfs] [ 188.754656] [a01901d7] submit_one_bio+0x67/0xa0 [btrfs] [ 188.757554] [a0193f27] submit_extent_page.isra.35+0xd7/0x1c0 [btrfs] [ 188.760981] [a019509d] __do_readpage+0x31d/0x7b0 [btrfs] [ 188.763920] [a0195f10] ? btrfs_create_repair_bio+0x110/0x110 [btrfs] [ 188.767382] [a0179b70] ? btrfs_submit_direct+0x7b0/0x7b0 [btrfs] [ 188.770671] [a018f88d] ? btrfs_lookup_ordered_range+0x13d/0x180 [btrfs] [ 188.774366] [a01958ca] __extent_readpages.constprop.42+0x2ba/0x2d0 [btrfs] [ 188.778031] [a0179b70] ? btrfs_submit_direct+0x7b0/0x7b0 [btrfs] [ 188.781241] [a01969b9] extent_readpages+0x169/0x1b0 [btrfs] [ 188.784322] [a0179b70] ? btrfs_submit_direct+0x7b0/0x7b0 [btrfs] [ 188.789014] [a0176b0f] btrfs_readpages+0x1f/0x30 [btrfs] [ 188.792028] [8118bf5c] __do_page_cache_readahead+0x18c/0x1f0 [ 188.795078] [8118c09f] ondemand_readahead+0xdf/0x260 [ 188.797702] [a016c5df] ? btrfs_congested_fn+0x5f/0xa0 [btrfs] [ 188.800718] [8118c291] page_cache_async_readahead+0x71/0xa0 [ 188.803650] [8118017f] generic_file_read_iter+0x40f/0x5e0 [ 188.806480] [811f43be] new_sync_read+0x7e/0xb0 [ 188.808832] [811f55d8] __vfs_read+0x18/0x50 [ 188.811068] [811f569a] vfs_read+0x8a/0x140 [ 188.813298] [811f5796] SyS_read+0x46/0xb0 [ 188.815486] [81125806] ? __audit_syscall_exit+0x1f6/0x2a0 [ 188.818293] [816eb8e9] system_call_fastpath+0x12/0x17 [ 188.821005] BUG: unable to handle kernel paging request at 0001000c [ 188.821984] IP: [a01901b3] submit_one_bio+0x43/0xa0 [btrfs] [ 188.821984] PGD 7bad3067 PUD 0 [ 188.821984] Oops: [#1] SMP [ 188.821984] Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables bnep bluetooth rfkill btrfs xor raid6_pq microcode 8139too serio_raw virtio_balloon 8139cp mii nfsd auth_rpcgss nfs_acl lockd grace sunrpc virtio_blk ata_generic pata_acpi [ 188.821984] CPU: 1 PID: 954 Comm: cat Not tainted 3.19.0-rc3-ktest #1
Re: [PATCH 3.2 00/27] 3.2.66-rc1 review
At Mon, 29 Dec 2014 02:11:30 +0100, Ben Hutchings wrote: > > This is the start of the stable review cycle for the 3.2.66 release. > There are 27 patches in this series, which will be posted as responses > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Dec 31 12:00:00 UTC 2014. > Anything received after that time might be too late. This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > A combined patch relative to 3.2.65 will be posted as an additional > response to this. A shortlog and diffstat can be found below. > > Ben. > > - > > Al Viro (2): > deal with deadlock in d_walk() > [ca5358ef75fc69fee5322a38a340f5739d997c10] > move d_rcu from overlapping d_child to overlapping d_alias > [946e51f2bf37f1656916eb75bd0742ba33983c28] > > Anatol Pomozov (1): > ext4: make orphan functions be no-op in no-journal mode > [c9b92530a723ac5ef8e352885a1862b18f31b2f5] > > Andy Lutomirski (2): > x86, kvm: Clear paravirt_enabled on KVM guests for espfix32's benefit > [29fa6825463c97e5157284db80107d1bfac5d77b] > x86/tls: Validate TLS entries to protect espfix > [41bdc78544b8a93a9c6814b8bbbfef966272abbe] > > Ard Biesheuvel (1): > crypto: ghash-clmulni-intel - use C implementation for setkey() > [8ceee72808d1ae3fb191284afc2257a2be964725] > > Ben Hutchings (2): > drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets > [5188cd44c55db3e92cd9e77a40b5baa7ed4340f7] > drivers/net: macvtap and tun depend on INET > [de11b0e8c569b96c2cf6a811e3805b7aeef498a3] > > Dan Carpenter (1): > [media] ttusb-dec: buffer overflow in ioctl > [f2e323ec96077642d397bb1c355def536d489d16] > > Daniel Borkmann (3): > net: sctp: fix NULL pointer dereference in af->from_addr_param on > malformed packet > [e40607cbe270a9e8360907cb1e62ddf0736e4864] > net: sctp: fix memory leak in auth key management > [4184b2a79a7612a9272ce20d639934584a1f3786] > net: sctp: use MAX_HEADER for headroom reserve in output path > [9772b54c55266ce80c639a80aa68eeb908f8ecf5] > > Daniel Vetter (1): > drm/i915: Unlock panel even when LVDS is disabled > [b0616c5306b342ceca07044dbc4f917d95c4f825] > > David Herrmann (1): > drm: fix DRM_IOCTL_MODE_GETFB handle-leak > [101b96f32956ee99bf1468afaf572b88cda9f88b] > > Devin Ryles (1): > AHCI: Add DeviceIDs for Sunrise Point-LP SATA controller > [249cd0a187ed4ef1d0af7f74362cc2791ec5581b] > > Dmitry Torokhov (1): > sata_fsl: fix error handling of irq_of_parse_and_map > [aad0b624129709c94c2e19e583b6053520353fa8] > > Eric Dumazet (2): > tcp: md5: do not use alloc_percpu() > [349ce993ac706869d553a1816426d3a4bfda02b1] > tcp: md5: remove spinlock usage in fast path > [71cea17ed39fdf1c0634f530ddc6a2c2fc601c2b] > > Grygorii Strashko (1): > i2c: davinci: generate STP always when NACK is received > [9ea359f7314132cbcb5a502d2d8ef095be1f45e4] > > Hugh Dickins (1): > mm: fix swapoff hang after page migration and fork > [2022b4d18a491a578218ce7a4eca8666db895a73] > > Jan Kara (1): > udf: Avoid infinite loop when processing indirect ICBs > [c03aa9f6e1f938618e6db2e23afef0574efeeb65] > > Jiri Pirko (1): > ipv4: fix nexthop attlen check in fib_nh_match > [f76936d07c4eeb36d8dbb64ebd30ab46ff85d9f7] > > Martin Schwidefsky (1): > s390,time: revert direct ktime path for s390 clockevent device > [8adbf78ec4839c1dc4ff20c9a1f332a7bc99e6e6] > > Nadav Amit (1): > KVM: x86: Don't report guest userspace emulation error to userspace > [a2b9e6c1a35afcc0973acb72e591c714e78885ff] > > Paolo Bonzini (1): > x86: kvm: use alternatives for VMCALL vs. VMMCALL if kernel text is > read-only > [c1118b3602c2329671ad5ec8bdf8e374323d6343] > > Tejun Heo (1): > ahci: disable MSI on SAMSUNG 0xa800 SSD
Re: [PATCH 3.2 00/27] 3.2.66-rc1 review
At Mon, 29 Dec 2014 02:11:30 +0100, Ben Hutchings wrote: This is the start of the stable review cycle for the 3.2.66 release. There are 27 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Dec 31 12:00:00 UTC 2014. Anything received after that time might be too late. This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru A combined patch relative to 3.2.65 will be posted as an additional response to this. A shortlog and diffstat can be found below. Ben. - Al Viro (2): deal with deadlock in d_walk() [ca5358ef75fc69fee5322a38a340f5739d997c10] move d_rcu from overlapping d_child to overlapping d_alias [946e51f2bf37f1656916eb75bd0742ba33983c28] Anatol Pomozov (1): ext4: make orphan functions be no-op in no-journal mode [c9b92530a723ac5ef8e352885a1862b18f31b2f5] Andy Lutomirski (2): x86, kvm: Clear paravirt_enabled on KVM guests for espfix32's benefit [29fa6825463c97e5157284db80107d1bfac5d77b] x86/tls: Validate TLS entries to protect espfix [41bdc78544b8a93a9c6814b8bbbfef966272abbe] Ard Biesheuvel (1): crypto: ghash-clmulni-intel - use C implementation for setkey() [8ceee72808d1ae3fb191284afc2257a2be964725] Ben Hutchings (2): drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets [5188cd44c55db3e92cd9e77a40b5baa7ed4340f7] drivers/net: macvtap and tun depend on INET [de11b0e8c569b96c2cf6a811e3805b7aeef498a3] Dan Carpenter (1): [media] ttusb-dec: buffer overflow in ioctl [f2e323ec96077642d397bb1c355def536d489d16] Daniel Borkmann (3): net: sctp: fix NULL pointer dereference in af-from_addr_param on malformed packet [e40607cbe270a9e8360907cb1e62ddf0736e4864] net: sctp: fix memory leak in auth key management [4184b2a79a7612a9272ce20d639934584a1f3786] net: sctp: use MAX_HEADER for headroom reserve in output path [9772b54c55266ce80c639a80aa68eeb908f8ecf5] Daniel Vetter (1): drm/i915: Unlock panel even when LVDS is disabled [b0616c5306b342ceca07044dbc4f917d95c4f825] David Herrmann (1): drm: fix DRM_IOCTL_MODE_GETFB handle-leak [101b96f32956ee99bf1468afaf572b88cda9f88b] Devin Ryles (1): AHCI: Add DeviceIDs for Sunrise Point-LP SATA controller [249cd0a187ed4ef1d0af7f74362cc2791ec5581b] Dmitry Torokhov (1): sata_fsl: fix error handling of irq_of_parse_and_map [aad0b624129709c94c2e19e583b6053520353fa8] Eric Dumazet (2): tcp: md5: do not use alloc_percpu() [349ce993ac706869d553a1816426d3a4bfda02b1] tcp: md5: remove spinlock usage in fast path [71cea17ed39fdf1c0634f530ddc6a2c2fc601c2b] Grygorii Strashko (1): i2c: davinci: generate STP always when NACK is received [9ea359f7314132cbcb5a502d2d8ef095be1f45e4] Hugh Dickins (1): mm: fix swapoff hang after page migration and fork [2022b4d18a491a578218ce7a4eca8666db895a73] Jan Kara (1): udf: Avoid infinite loop when processing indirect ICBs [c03aa9f6e1f938618e6db2e23afef0574efeeb65] Jiri Pirko (1): ipv4: fix nexthop attlen check in fib_nh_match [f76936d07c4eeb36d8dbb64ebd30ab46ff85d9f7] Martin Schwidefsky (1): s390,time: revert direct ktime path for s390 clockevent device [8adbf78ec4839c1dc4ff20c9a1f332a7bc99e6e6] Nadav Amit (1): KVM: x86: Don't report guest userspace emulation error to userspace [a2b9e6c1a35afcc0973acb72e591c714e78885ff] Paolo Bonzini (1): x86: kvm: use alternatives for VMCALL vs. VMMCALL if kernel text is read-only [c1118b3602c2329671ad5ec8bdf8e374323d6343] Tejun Heo (1): ahci: disable MSI on SAMSUNG 0xa800 SSD [2b21ef0aae65f22f5ba86b13c4588f6f0c2dbefb] Vasily Averin (1): ipv4: dst_entry leak in ip_send_unicast_reply() [4062090e3e5caaf55bed4523a69f26c3265cc1d2] Makefile | 4 +- arch/powerpc/platforms/cell/spufs/inode.c | 4 +- arch/s390/kernel/time.c| 19 +-- arch/x86/crypto/ghash-clmulni-intel_asm.S | 28 - arch/x86/crypto/ghash-clmulni
Re: [PATCH 3.12 000/197] 3.12.31-stable review
Hi Jiri,
At Fri, 17 Oct 2014 10:11:30 +0200,
Jiri Slaby wrote:
>
> This is the start of the stable review cycle for the 3.12.31 release.
> There are 197 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.
>
> Responses should be made by Tue Oct 21 10:08:49 CEST 2014.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
>
> http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.31-rc1.xz
> and the diffstat can be found below.
This kernel passed my test.
- Test Cases:
- Build this kernel.
- Boot this kernel.
- Build the latest mainline kernel with this kernel.
- Test Tool:
https://github.com/satoru-takeuchi/test-linux-stable
- Test Result (kernel .config, ktest config and test log):
http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz
- Build Environment:
- OS: Debian Jessy x86_64
- CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
- memory: 8GB
- Test Target Environment:
- Debian Jessy x86_64 (KVM guest on the Build Environment)
- # of vCPU: 2
- memory: 2GB
Thanks,
Satoru
>
> thanks,
> js
>
> ===
>
>
> Al Viro (1):
> don't bugger nd->seq on set_root_rcu() from follow_dotdot_rcu()
>
> Alan Douglas (1):
> xtensa: fix address checks in dma_{alloc,free}_coherent
>
> Alan Stern (1):
> USB: EHCI: unlink QHs even after the controller has stopped
>
> Alex Deucher (8):
> drm/radeon/dpm: set the thermal type properly for special configs
> drm/radeon: add connector quirk for fujitsu board
> drm/radeon: don't reset dma on NI/SI init
> drm/radeon: don't reset sdma on CIK init
> drm/radeon: don't reset dma on r6xx-evergreen init
> drm/radeon/cik: use a separate counter for CP init timeout
> vgaswitcheroo: add vga_switcheroo_fini_domain_pm_ops
> drm/nouveau/runpm: fix module unload
>
> Alex Gartrell (1):
> ipvs: Maintain all DSCP and ECN bits for ipv6 tun forwarding
>
> Andreas Bomholtz (1):
> USB: cp210x: add support for Seluxit USB dongle
>
> Andreas Rohner (1):
> nilfs2: fix data loss with mmap()
>
> Andrew Hunter (1):
> jiffies: Fix timeval conversion to jiffies
>
> Andrey Vagin (2):
> fsnotify/fdinfo: use named constants instead of hardcoded values
> fs/notify: don't show f_handle if exportfs_encode_inode_fh failed
>
> Andy Shevchenko (2):
> dmaengine: dw: introduce dwc_dostart_first_queued() helper
> dmaengine: dw: don't perform DMA when dmaengine_submit is called
>
> Anssi Hannula (1):
> dm cache: fix race causing dirty blocks to be marked as clean
>
> Anton Altaparmakov (1):
> Fix nasty 32-bit overflow bug in buffer i/o code.
>
> Arnd Bergmann (1):
> staging/lustre: disable virtual block device for 64K pages
>
> Aurelien Jarno (1):
> MIPS: ZBOOT: add missing include
>
> Benjamin Tissoires (1):
> HID: logitech-dj: prevent false errors to be shown
>
> Bjørn Mork (2):
> USB: sierra: avoid CDC class functions on "68A3" devices
> USB: sierra: add 1199:68AA device ID
>
> Brennan Ashton (1):
> USB: option: add VIA Telecom CDS7 chipset device id
>
> Bryan O'Donoghue (1):
> serial: 8250: Add Quark X1000 to 8250_pci.c
>
> Chen-Yu Tsai (1):
> i2c: mv64xxx: continue probe when clock-frequency is missing
>
> Chris Wilson (1):
> drm/i915: Flush the PTEs after updating them before suspend
>
> Christian Borntraeger (1):
> KVM: s390/mm: try a cow on read only pages for key ops
>
> Clemens Ladisch (2):
> ALSA: core: fix buffer overflow in snd_info_get_line()
> ALSA: pcm: fix fifo_size frame calculation
>
> Cong Wang (1):
> perf: Fix a race condition in perf_remove_from_context()
>
> Dan Carpenter (2):
> NFC: microread: Potential overflows in microread_target_discovered()
> partitions: aix.c: off by one bug
>
> Daniel Borkmann (1):
> netlink: reset network header before passing to taps
>
> Daniel Vetter (1):
> drm/i915: Fix EIO/wedged handling in gem fault handler
>
> Dave Martin (1):
> ARM: 7897/1: kexec: Use the right ISA for relocate_new_kernel
>
> David Jeffery (1):
> nfs: Don't busy-wait on SIGKILL in __nfs_iocounter_wait
>
> David Rientjes (1):
> mm, slab: initialize object alignment on cache creation
>
> Denis CIOCCA (1):
> iio:magnetometer: bugfix magnetometers gain values
>
> Dmitry Torokhov (2):
> Input: synaptics - add support for ForcePads
> Input: atkbd - do not try 'deactivate' keyboard on any LG laptops
>
> Eliad Peller (1):
> regulatory: add NUL to alph
Re: [PATCH 3.12 000/197] 3.12.31-stable review
Hi Jiri,
At Fri, 17 Oct 2014 10:11:30 +0200,
Jiri Slaby wrote:
This is the start of the stable review cycle for the 3.12.31 release.
There are 197 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.
Responses should be made by Tue Oct 21 10:08:49 CEST 2014.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.31-rc1.xz
and the diffstat can be found below.
This kernel passed my test.
- Test Cases:
- Build this kernel.
- Boot this kernel.
- Build the latest mainline kernel with this kernel.
- Test Tool:
https://github.com/satoru-takeuchi/test-linux-stable
- Test Result (kernel .config, ktest config and test log):
http://satoru-takeuchi.org/test-linux-stable/results/version-test
datetime.tar.xz
- Build Environment:
- OS: Debian Jessy x86_64
- CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
- memory: 8GB
- Test Target Environment:
- Debian Jessy x86_64 (KVM guest on the Build Environment)
- # of vCPU: 2
- memory: 2GB
Thanks,
Satoru
thanks,
js
===
Al Viro (1):
don't bugger nd-seq on set_root_rcu() from follow_dotdot_rcu()
Alan Douglas (1):
xtensa: fix address checks in dma_{alloc,free}_coherent
Alan Stern (1):
USB: EHCI: unlink QHs even after the controller has stopped
Alex Deucher (8):
drm/radeon/dpm: set the thermal type properly for special configs
drm/radeon: add connector quirk for fujitsu board
drm/radeon: don't reset dma on NI/SI init
drm/radeon: don't reset sdma on CIK init
drm/radeon: don't reset dma on r6xx-evergreen init
drm/radeon/cik: use a separate counter for CP init timeout
vgaswitcheroo: add vga_switcheroo_fini_domain_pm_ops
drm/nouveau/runpm: fix module unload
Alex Gartrell (1):
ipvs: Maintain all DSCP and ECN bits for ipv6 tun forwarding
Andreas Bomholtz (1):
USB: cp210x: add support for Seluxit USB dongle
Andreas Rohner (1):
nilfs2: fix data loss with mmap()
Andrew Hunter (1):
jiffies: Fix timeval conversion to jiffies
Andrey Vagin (2):
fsnotify/fdinfo: use named constants instead of hardcoded values
fs/notify: don't show f_handle if exportfs_encode_inode_fh failed
Andy Shevchenko (2):
dmaengine: dw: introduce dwc_dostart_first_queued() helper
dmaengine: dw: don't perform DMA when dmaengine_submit is called
Anssi Hannula (1):
dm cache: fix race causing dirty blocks to be marked as clean
Anton Altaparmakov (1):
Fix nasty 32-bit overflow bug in buffer i/o code.
Arnd Bergmann (1):
staging/lustre: disable virtual block device for 64K pages
Aurelien Jarno (1):
MIPS: ZBOOT: add missing linux/string.h include
Benjamin Tissoires (1):
HID: logitech-dj: prevent false errors to be shown
Bjørn Mork (2):
USB: sierra: avoid CDC class functions on 68A3 devices
USB: sierra: add 1199:68AA device ID
Brennan Ashton (1):
USB: option: add VIA Telecom CDS7 chipset device id
Bryan O'Donoghue (1):
serial: 8250: Add Quark X1000 to 8250_pci.c
Chen-Yu Tsai (1):
i2c: mv64xxx: continue probe when clock-frequency is missing
Chris Wilson (1):
drm/i915: Flush the PTEs after updating them before suspend
Christian Borntraeger (1):
KVM: s390/mm: try a cow on read only pages for key ops
Clemens Ladisch (2):
ALSA: core: fix buffer overflow in snd_info_get_line()
ALSA: pcm: fix fifo_size frame calculation
Cong Wang (1):
perf: Fix a race condition in perf_remove_from_context()
Dan Carpenter (2):
NFC: microread: Potential overflows in microread_target_discovered()
partitions: aix.c: off by one bug
Daniel Borkmann (1):
netlink: reset network header before passing to taps
Daniel Vetter (1):
drm/i915: Fix EIO/wedged handling in gem fault handler
Dave Martin (1):
ARM: 7897/1: kexec: Use the right ISA for relocate_new_kernel
David Jeffery (1):
nfs: Don't busy-wait on SIGKILL in __nfs_iocounter_wait
David Rientjes (1):
mm, slab: initialize object alignment on cache creation
Denis CIOCCA (1):
iio:magnetometer: bugfix magnetometers gain values
Dmitry Torokhov (2):
Input: synaptics - add support for ForcePads
Input: atkbd - do not try 'deactivate' keyboard on any LG laptops
Eliad Peller (1):
regulatory: add NUL to alpha2
Emmanuel Grumbach (1):
Revert iwlwifi: dvm: don't enable CTS to self
Eric Dumazet (1):
packet: handle too big packets for PACKET_V3
Fan Du (1):
i2c: ismt: use correct length when copy buffer
Felipe Balbi (4):
usb: host: xhci: fix compliance mode workaround
usb: dwc3: omap: fix ordering for runtime pm calls
usb: dwc3: core: fix order of PM runtime calls
usb: dwc3: core: fix ordering for PHY suspend
Filipe Brandenburger (1):
xattr: fix check
Re: [PATCH 3.17 00/25] 3.17.1-stable review
At Tue, 14 Oct 2014 05:26:07 +0200, Greg Kroah-Hartman wrote: > > On Tue, Oct 14, 2014 at 04:39:11AM +0200, Greg Kroah-Hartman wrote: > > On Mon, Oct 13, 2014 at 08:19:56AM -0700, Guenter Roeck wrote: > > > On 10/12/2014 07:24 PM, Greg Kroah-Hartman wrote: > > > >This is the start of the stable review cycle for the 3.17.1 release. > > > >There are 25 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. > > > > > > > >Responses should be made by Wed Oct 15 02:24:45 UTC 2014. > > > >Anything received after that time might be too late. > > > > > > > > > > Build results: > > > total: 134 pass: 134 fail: 0 > > > > > > Qemu test results: > > > total: 30 pass: 30 fail: 0 > > > > > > Details are available at http://server.roeck-us.net:8010/builders. > > > > Thanks for testing all 3 of these and letting me know. > > All 4, sorry... Those 4 kernels also passd my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.17 00/25] 3.17.1-stable review
At Tue, 14 Oct 2014 05:26:07 +0200, Greg Kroah-Hartman wrote: On Tue, Oct 14, 2014 at 04:39:11AM +0200, Greg Kroah-Hartman wrote: On Mon, Oct 13, 2014 at 08:19:56AM -0700, Guenter Roeck wrote: On 10/12/2014 07:24 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.17.1 release. There are 25 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. Responses should be made by Wed Oct 15 02:24:45 UTC 2014. Anything received after that time might be too late. Build results: total: 134 pass: 134 fail: 0 Qemu test results: total: 30 pass: 30 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. Thanks for testing all 3 of these and letting me know. All 4, sorry... Those 4 kernels also passd my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.16 00/26] 3.16.5-stable review
At Tue, 7 Oct 2014 21:48:04 -0700, Greg Kroah-Hartman wrote: > > On Tue, Oct 07, 2014 at 07:47:13PM -0700, Guenter Roeck wrote: > > On 10/07/2014 04:19 PM, Greg Kroah-Hartman wrote: > > >This is the start of the stable review cycle for the 3.16.5 release. > > >There are 26 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. > > > > > >Responses should be made by Thu Oct 9 23:18:40 UTC 2014. > > >Anything received after that time might be too late. > > > > > > > Build results: > > total: 136 pass: 136 fail: 0 > > Qemu tests: > > total: 30 pass: 30 fail: 0 > > > > Details are available at http://server.roeck-us.net:8010/builders. > > Wonderful, thanks for testing all 3 of these and letting me know. Plus, all these kernels passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.16 00/26] 3.16.5-stable review
At Tue, 7 Oct 2014 21:48:04 -0700, Greg Kroah-Hartman wrote: On Tue, Oct 07, 2014 at 07:47:13PM -0700, Guenter Roeck wrote: On 10/07/2014 04:19 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.16.5 release. There are 26 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. Responses should be made by Thu Oct 9 23:18:40 UTC 2014. Anything received after that time might be too late. Build results: total: 136 pass: 136 fail: 0 Qemu tests: total: 30 pass: 30 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. Wonderful, thanks for testing all 3 of these and letting me know. Plus, all these kernels passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.16 000/357] 3.16.4-stable review
At Fri, 3 Oct 2014 14:26:26 -0700, Greg Kroah-Hartman wrote: > > - > Note: This is a big stable release. Mostly my fault for being on the > road last week, combined with an unusually large number of patches being > tagged for the stable tree. Anyway, I've caught up with all pending > patches before 3.17-rc7, so if you have marked something for the stable > tree that I have not applied, or emailed the stable@v.k.o list asking > for a patch, that is not here, please let me know. > - > > This is the start of the stable review cycle for the 3.16.4 release. > There are 357 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. > > Responses should be made by Sun Oct 5 21:28:42 UTC 2014. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.16.4-rc1.gz > and the diffstat can be found below. Al 3.16.4-rc1, 3.14.20-rc1, and 3.10.56-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > thanks, > > greg k-h > > - > Pseudo-Shortlog of commits: > > Greg Kroah-Hartman > Linux 3.16.4-rc1 > > Stephen Boyd > clk: qcom: Fix PLL rate configurations > > Stephen Boyd > clk: qcom: mdp_lut_clk is a child of mdp_src > > Stephen Boyd > clk: qcom: Fix MN frequency tables, parent map, and jpegd > > Arnd Bergmann > staging/lustre: disable virtual block device for 64K pages > > Theodore Ts'o > ext4: avoid trying to kfree an ERR_PTR pointer > > Theodore Ts'o > ext4: propagate errors up to ext4_find_entry()'s callers > > Gu Zheng > aio: block exit_aio() until all context requests are completed > > Suman Tripathi > ahci_xgene: Removing NCQ support from the APM X-Gene SoC AHCI SATA Host > Controller driver. > > Nishanth Menon > clk: ti: divider: Provide error check for incoming parameters in set_rate > > Tero Kristo > clk: prevent erronous parsing of children during rate change > > Nishanth Menon > clk: ti: dra7-atl: Provide error check for incoming parameters in set_rate > > Viresh Kumar > cpufreq: update 'cpufreq_suspended' after stopping governors > > Dan Carpenter > partitions: aix.c: off by one bug > > Andy Shevchenko > dmaengine: dw: don't perform DMA when dmaengine_submit is called > > Andy Shevchenko > dmaengine: dw: introduce dwc_dostart_first_queued() helper > > Ulf Hansson > mmc: mmci: Reverse IRQ handling for the arm_variant > > Pablo Neira Ayuso > netfilter: nf_tables: don't update chain with unset counters > > Julian Anastasov > ipvs: fix ipv6 hook registration for local replies > > Daniel Borkmann > netfilter: x_tables: allow to use default cgroup match > > Alex Gartrell > ipvs: Maintain all DSCP and ECN bits for ipv6 tun forwarding > > Eric Dumazet > netfilter: xt_hashlimit: perform garbage collection from process context > > NeilBrown > md/raid1: intialise start_next_window for READ case to avoid hang > > NeilBrown > md/raid1: fix_read_error should act on all non-faulty devices. > > NeilBrown > md/raid1: count resync requests in nr_pending. > > NeilBrown > md/raid1: update next_resync under resync_lock. > > NeilBrown > md/raid1: Don't use next_resync to determine how far resync has progressed > > NeilBrown > md/raid1: make sure resync waits for conflicting writes to complete. > > NeilBrown > md/raid1: be more cautious where we read-balance during resync. > > NeilBrown > md/raid1: clean up request counts properly in close_sync() > > Zhaowei Yuan > media: vb2: fix plane index sanity check in vb2_plane_cookie() > > Hans Verkuil > media: vb2: fix vb2 state check when start_streaming fails > > Hans Verkuil > media: videobuf2-dma-sg: fix for wrong GFP mask to > sg_alloc_table_from_pages > > Mauro Car
Re: [PATCH 3.16 000/357] 3.16.4-stable review
At Fri, 3 Oct 2014 14:26:26 -0700, Greg Kroah-Hartman wrote: - Note: This is a big stable release. Mostly my fault for being on the road last week, combined with an unusually large number of patches being tagged for the stable tree. Anyway, I've caught up with all pending patches before 3.17-rc7, so if you have marked something for the stable tree that I have not applied, or emailed the stable@v.k.o list asking for a patch, that is not here, please let me know. - This is the start of the stable review cycle for the 3.16.4 release. There are 357 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. Responses should be made by Sun Oct 5 21:28:42 UTC 2014. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.16.4-rc1.gz and the diffstat can be found below. Al 3.16.4-rc1, 3.14.20-rc1, and 3.10.56-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman gre...@linuxfoundation.org Linux 3.16.4-rc1 Stephen Boyd sb...@codeaurora.org clk: qcom: Fix PLL rate configurations Stephen Boyd sb...@codeaurora.org clk: qcom: mdp_lut_clk is a child of mdp_src Stephen Boyd sb...@codeaurora.org clk: qcom: Fix MN frequency tables, parent map, and jpegd Arnd Bergmann a...@arndb.de staging/lustre: disable virtual block device for 64K pages Theodore Ts'o ty...@mit.edu ext4: avoid trying to kfree an ERR_PTR pointer Theodore Ts'o ty...@mit.edu ext4: propagate errors up to ext4_find_entry()'s callers Gu Zheng guz.f...@cn.fujitsu.com aio: block exit_aio() until all context requests are completed Suman Tripathi stripa...@apm.com ahci_xgene: Removing NCQ support from the APM X-Gene SoC AHCI SATA Host Controller driver. Nishanth Menon n...@ti.com clk: ti: divider: Provide error check for incoming parameters in set_rate Tero Kristo t-kri...@ti.com clk: prevent erronous parsing of children during rate change Nishanth Menon n...@ti.com clk: ti: dra7-atl: Provide error check for incoming parameters in set_rate Viresh Kumar viresh.ku...@linaro.org cpufreq: update 'cpufreq_suspended' after stopping governors Dan Carpenter dan.carpen...@oracle.com partitions: aix.c: off by one bug Andy Shevchenko andriy.shevche...@linux.intel.com dmaengine: dw: don't perform DMA when dmaengine_submit is called Andy Shevchenko andriy.shevche...@linux.intel.com dmaengine: dw: introduce dwc_dostart_first_queued() helper Ulf Hansson ulf.hans...@linaro.org mmc: mmci: Reverse IRQ handling for the arm_variant Pablo Neira Ayuso pa...@netfilter.org netfilter: nf_tables: don't update chain with unset counters Julian Anastasov j...@ssi.bg ipvs: fix ipv6 hook registration for local replies Daniel Borkmann dbork...@redhat.com netfilter: x_tables: allow to use default cgroup match Alex Gartrell agartr...@fb.com ipvs: Maintain all DSCP and ECN bits for ipv6 tun forwarding Eric Dumazet eduma...@google.com netfilter: xt_hashlimit: perform garbage collection from process context NeilBrown ne...@suse.de md/raid1: intialise start_next_window for READ case to avoid hang NeilBrown ne...@suse.de md/raid1: fix_read_error should act on all non-faulty devices. NeilBrown ne...@suse.de md/raid1: count resync requests in nr_pending. NeilBrown ne...@suse.de md/raid1: update next_resync under resync_lock. NeilBrown ne...@suse.de md/raid1: Don't use next_resync to determine how far resync has progressed NeilBrown ne...@suse.de md/raid1: make sure resync waits for conflicting writes to complete. NeilBrown ne...@suse.de md/raid1: be more cautious where we read-balance during resync. NeilBrown ne...@suse.de md/raid1: clean up request counts properly in close_sync() Zhaowei Yuan zhaowei.y...@samsung.com media: vb2: fix plane index sanity check in vb2_plane_cookie() Hans Verkuil hans.verk...@cisco.com media: vb2: fix vb2 state check when start_streaming fails Hans Verkuil hverk...@xs4all.nl media
Re: [PATCH 3.12 00/96] 3.12.30-stable review
At Wed, 1 Oct 2014 10:57:39 +0200, Jiri Slaby wrote: > > This is the start of the stable review cycle for the 3.12.30 release. > There are 96 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. > > This one is special. First, it is rounded (30). Second, most of the > patches are performance improvements. They are coming from SUSE > Enterprise Linux and all are backed by proper testing and performance > measurements. All this patchset was prepared and sent by Mel Gorman > with a support of other patchers from SUSE. Thanks to all of them. > > As this is special, I am gicing a whole week for responses. So > responses should be made by Wed Oct 8 09:12:02 CEST 2014. Anything > received after that time might be too late. > > The whole patch series can be found in one patch at: > > http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.30-rc1.xz > and the diffstat can be found below. > > thanks, > js This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > === > > > Al Viro (1): > callers of iov_copy_from_user_atomic() don't need pagecache_disable() > > Bob Liu (2): > mm: thp: cleanup: mv alloc_hugepage to better place > mm: thp: khugepaged: add policy for finding target node > > Christoph Lameter (1): > vmscan: reclaim_clean_pages_from_list() must use mod_zone_page_state() > > Damien Ramonda (1): > readahead: fix sequential read cache miss detection > > Dan Streetman (4): > swap: change swap_info singly-linked list to list_head > lib/plist: add helper functions > lib/plist: add plist_requeue > swap: change swap_list_head to plist, add swap_avail_head > > Dave Chinner (1): > fs/superblock: unregister sb shrinker before ->kill_sb() > > David Rientjes (9): > mm, compaction: avoid isolating pinned pages > mm, compaction: determine isolation mode only once > mm, compaction: ignore pageblock skip when manually invoking > compaction > mm, migration: add destination page freeing callback > mm, compaction: return failed migration target pages back to freelist > mm, compaction: add per-zone migration pfn cache for async compaction > mm, compaction: embed migration mode in compact_control > mm, compaction: terminate async compaction when rescheduling > mm, thp: only collapse hugepages to nodes with affinity for > zone_reclaim_mode > > Davidlohr Bueso (1): > mm: per-thread vma caching > > Fabian Frederick (1): > mm/readahead.c: inline ra_submit > > Han Pingtian (1): > mm: prevent setting of a value less than 0 to min_free_kbytes > > Heesub Shin (1): > mm/compaction: clean up unused code lines > > Hugh Dickins (4): > mm: fix bad rss-counter if remap_file_pages raced migration > mm: fix direct reclaim writeback regression > shmem: fix init_page_accessed use to stop !PageLRU bug > mm/memory.c: use entry = ACCESS_ONCE(*pte) in handle_pte_fault() > > Jens Axboe (1): > mm/filemap.c: avoid always dirtying mapping->flags on O_DIRECT > > Jerome Marchand (2): > mm: make copy_pte_range static again > memcg, vmscan: Fix forced scan of anonymous pages > > Jianyu Zhan (1): > mm/swap.c: clean up *lru_cache_add* functions > > Johannes Weiner (5): > lib: radix-tree: add radix_tree_delete_item() > mm: shmem: save one radix tree lookup when truncating swapped pages > mm: filemap: move radix tree hole searching here > mm + fs: prepare for non-page entries in page cache radix trees > mm: madvise: fix MADV_WILLNEED on shmem swapouts > > Joonsoo Kim (7): > slab: correct pfmemalloc check > mm/compaction: disallow high-order page for migration target > mm/compaction: do not call suitable_migration_target() on every page > mm/compaction: change the timing to check to drop the spinlock > mm/compaction: check pageblock suitability once per pageblock > mm/compaction: clean-up code on success of ballon isolation > vmalloc: use rcu list iterator to reduce vmap_area_lock contention > > KOSAKI Motohiro (2): > mm: get rid of unne
Re: [PATCH 3.12 00/96] 3.12.30-stable review
At Wed, 1 Oct 2014 10:57:39 +0200, Jiri Slaby wrote: This is the start of the stable review cycle for the 3.12.30 release. There are 96 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. This one is special. First, it is rounded (30). Second, most of the patches are performance improvements. They are coming from SUSE Enterprise Linux and all are backed by proper testing and performance measurements. All this patchset was prepared and sent by Mel Gorman with a support of other patchers from SUSE. Thanks to all of them. As this is special, I am gicing a whole week for responses. So responses should be made by Wed Oct 8 09:12:02 CEST 2014. Anything received after that time might be too late. The whole patch series can be found in one patch at: http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.30-rc1.xz and the diffstat can be found below. thanks, js This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru === Al Viro (1): callers of iov_copy_from_user_atomic() don't need pagecache_disable() Bob Liu (2): mm: thp: cleanup: mv alloc_hugepage to better place mm: thp: khugepaged: add policy for finding target node Christoph Lameter (1): vmscan: reclaim_clean_pages_from_list() must use mod_zone_page_state() Damien Ramonda (1): readahead: fix sequential read cache miss detection Dan Streetman (4): swap: change swap_info singly-linked list to list_head lib/plist: add helper functions lib/plist: add plist_requeue swap: change swap_list_head to plist, add swap_avail_head Dave Chinner (1): fs/superblock: unregister sb shrinker before -kill_sb() David Rientjes (9): mm, compaction: avoid isolating pinned pages mm, compaction: determine isolation mode only once mm, compaction: ignore pageblock skip when manually invoking compaction mm, migration: add destination page freeing callback mm, compaction: return failed migration target pages back to freelist mm, compaction: add per-zone migration pfn cache for async compaction mm, compaction: embed migration mode in compact_control mm, compaction: terminate async compaction when rescheduling mm, thp: only collapse hugepages to nodes with affinity for zone_reclaim_mode Davidlohr Bueso (1): mm: per-thread vma caching Fabian Frederick (1): mm/readahead.c: inline ra_submit Han Pingtian (1): mm: prevent setting of a value less than 0 to min_free_kbytes Heesub Shin (1): mm/compaction: clean up unused code lines Hugh Dickins (4): mm: fix bad rss-counter if remap_file_pages raced migration mm: fix direct reclaim writeback regression shmem: fix init_page_accessed use to stop !PageLRU bug mm/memory.c: use entry = ACCESS_ONCE(*pte) in handle_pte_fault() Jens Axboe (1): mm/filemap.c: avoid always dirtying mapping-flags on O_DIRECT Jerome Marchand (2): mm: make copy_pte_range static again memcg, vmscan: Fix forced scan of anonymous pages Jianyu Zhan (1): mm/swap.c: clean up *lru_cache_add* functions Johannes Weiner (5): lib: radix-tree: add radix_tree_delete_item() mm: shmem: save one radix tree lookup when truncating swapped pages mm: filemap: move radix tree hole searching here mm + fs: prepare for non-page entries in page cache radix trees mm: madvise: fix MADV_WILLNEED on shmem swapouts Joonsoo Kim (7): slab: correct pfmemalloc check mm/compaction: disallow high-order page for migration target mm/compaction: do not call suitable_migration_target() on every page mm/compaction: change the timing to check to drop the spinlock mm/compaction: check pageblock suitability once per pageblock mm/compaction: clean-up code on success of ballon isolation vmalloc: use rcu list iterator to reduce vmap_area_lock contention KOSAKI Motohiro (2): mm: get rid of unnecessary overhead of trace_mm_page_alloc_extfrag() mm: __rmqueue_fallback() should respect pageblock type Linus Torvalds (1): mm: don't pointlessly use BUG_ON() for sanity check Mel Gorman (30): mm, x86: Account for TLB flushes only when debugging x86/mm: Clean up inconsistencies when flushing TLB ranges x86/mm: Eliminate redundant page table walk during TLB range flushing mm: compaction: trace
[RFC] ktest doc: Automated test of linux kernel by using ktest v1.1.3
Hi, I revised ktest documentation. v1.1.2->v1.1.3: Support not only debian/jessy, but also CentOS7 as target system http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest It's not the ktest reference guild, but the quick learning guild of ktest especially focuses on some important features. After reading this document, you'll be able to do the following work automatically. - test all patches of your patchset, and - bisect to find the problematic commit I believe it saves plenty of your time. Feel free to ask me if you have any comments/questions. Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 000/142] 3.12.29-stable review
At Fri, 26 Sep 2014 08:45:36 -0700, Guenter Roeck wrote: > > On Fri, Sep 26, 2014 at 11:45:33AM +0200, Jiri Slaby wrote: > > This is the start of the stable review cycle for the 3.12.29 release. > > There are 142 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. > > > > Responses should be made by Tue Sep 30 11:45:24 CEST 2014. > > Anything received after that time might be too late. > > > > Hi Jiri, > > Build results: > total: 135 pass: 135 fail: 0 > > Qemu test results: > total: 21 pass: 21 fail: 0 > > Both obviously look good, however my tree doesn't match your review request. > It includes 245 patches instead of just 142. > > Looks like your tree is a bit ahead of time, so I guess that is ok. > Is there a way for me to avoid this when pulling in your pending changes ? > So far I pull the changes from the stable-3.12-queue branch in your > repository at kernel.org. > > Thanks, > Guenter Plus, this kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 000/142] 3.12.29-stable review
At Fri, 26 Sep 2014 08:45:36 -0700, Guenter Roeck wrote: On Fri, Sep 26, 2014 at 11:45:33AM +0200, Jiri Slaby wrote: This is the start of the stable review cycle for the 3.12.29 release. There are 142 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. Responses should be made by Tue Sep 30 11:45:24 CEST 2014. Anything received after that time might be too late. Hi Jiri, Build results: total: 135 pass: 135 fail: 0 Qemu test results: total: 21 pass: 21 fail: 0 Both obviously look good, however my tree doesn't match your review request. It includes 245 patches instead of just 142. Looks like your tree is a bit ahead of time, so I guess that is ok. Is there a way for me to avoid this when pulling in your pending changes ? So far I pull the changes from the stable-3.12-queue branch in your repository at kernel.org. Thanks, Guenter Plus, this kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] ktest doc: Automated test of linux kernel by using ktest v1.1.3
Hi, I revised ktest documentation. v1.1.2-v1.1.3: Support not only debian/jessy, but also CentOS7 as target system http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest It's not the ktest reference guild, but the quick learning guild of ktest especially focuses on some important features. After reading this document, you'll be able to do the following work automatically. - test all patches of your patchset, and - bisect to find the problematic commit I believe it saves plenty of your time. Feel free to ask me if you have any comments/questions. Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 00/45] 3.4.104-rc1 review
Hi Li,
At Tue, 23 Sep 2014 10:27:39 +0800,
Zefan Li wrote:
>
> From: Zefan Li
>
> This is the start of the stable review cycle for the 3.4.104 release.
> There are 45 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.
>
> Responses should be made by Thu Sep 25 02:03:31 UTC 2014.
> Anything received after that time might be too late.
This kernel passed my test.
- Test Cases:
- Build this kernel.
- Boot this kernel.
- Build the latest mainline kernel with this kernel.
- Test Tool:
https://github.com/satoru-takeuchi/test-linux-stable
- Test Result (kernel .config, ktest config and test log):
http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz
- Build Environment:
- OS: Debian Jessy x86_64
- CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
- memory: 8GB
- Test Target Environment:
- Debian Jessy x86_64 (KVM guest on the Build Environment)
- # of vCPU: 2
- memory: 2GB
Thanks,
Satoru
>
> A combined patch relative to 3.4.103 will be posted as an additional
> response to this. A shortlog and diffstat can be found below.
>
> thanks,
>
> Zefan Li
>
>
>
> Aaro Koskinen (1):
> MIPS: OCTEON: make get_system_type() thread-safe
>
> Alan Douglas (1):
> xtensa: fix address checks in dma_{alloc,free}_coherent
>
> Andi Kleen (1):
> slab/mempolicy: always use local policy from interrupt context
>
> Anton Blanchard (1):
> ibmveth: Fix endian issues with rx_no_buffer statistic
>
> Arjun Sreedharan (1):
> pata_scc: propagate return value of scc_wait_after_reset
>
> Benjamin Tissoires (1):
> HID: logitech-dj: prevent false errors to be shown
>
> Brennan Ashton (1):
> USB: option: add VIA Telecom CDS7 chipset device id
>
> Daniel Mack (1):
> ASoC: pxa-ssp: drop SNDRV_PCM_FMTBIT_S24_LE
>
> Dave Chiluk (1):
> stable_kernel_rules: Add pointer to netdev-FAQ for network patches
>
> Fengguang Wu (1):
> unicore32: select generic atomic64_t support
>
> Florian Fainelli (1):
> MIPS: perf: Fix build error caused by unused
> counters_per_cpu_to_total()
>
> Greg KH (1):
> USB: serial: pl2303: add device id for ztek device
>
> Guan Xuetao (2):
> UniCore32-bugfix: Remove definitions in asm/bug.h to solve difference
> between native and cross compiler
> UniCore32-bugfix: fix mismatch return value of __xchg_bad_pointer
>
> Hans de Goede (1):
> xhci: Treat not finding the event_seg on COMP_STOP the same as
> COMP_STOP_INVAL
>
> Huang Rui (1):
> usb: xhci: amd chipset also needs short TX quirk
>
> James Forshaw (1):
> USB: whiteheat: Added bounds checking for bulk command response
>
> Jan Kara (2):
> isofs: Fix unbounded recursion when processing relocated directories
> ext2: Fix fs corruption in ext2_get_xip_mem()
>
> Jaša Bartelj (1):
> USB: ftdi_sio: Added PID for new ekey device
>
> Jiri Kosina (4):
> HID: fix a couple of off-by-ones
> HID: logitech: perform bounds checking on device_id early enough
> HID: magicmouse: sanity check report size in raw_event() callback
> HID: picolcd: sanity check report size in raw_event() callback
>
> Joerg Roedel (1):
> iommu/amd: Fix cleanup_domain for mass device removal
>
> Johan Hovold (3):
> USB: ftdi_sio: add Basic Micro ATOM Nano USB2Serial PID
> USB: serial: fix potential stack buffer overflow
> USB: serial: fix potential heap buffer overflow
>
> Mark Einon (1):
> staging: et131x: Fix errors caused by phydev->addr accesses before
> initialisation
>
> Mark Rutland (2):
> ARM: 8128/1: abort: don't clear the exclusive monitors
> ARM: 8129/1: errata: work around Cortex-A15 erratum 830321 using
> dummy strex
>
> Max Filippov (3):
> xtensa: replace IOCTL code definitions with constants
> xtensa: fix TLBTEMP_BASE_2 region handling in fast_second_level_miss
> xtensa: fix a6 and a7 handling in fast_syscall_xtensa
>
> Michael Cree (2):
> alpha: Fix fall-out from disintegrating asm/system.h
> alpha: add io{read,write}{16,32}be functions
>
> Michael S. Tsirkin (1):
> kvm: iommu: fix the third parameter of kvm_iommu_put_pages
> (CVE-2014-3601)
>
> NeilBrown (1):
> md/raid6: avoid data corruption during recovery of double-degraded
> RAID6
>
> Paul Gortmaker (1):
> 8250_pci: fix warnings in backport of Broadcom TruManage support
>
> Pavel Shilovsky (1):
> CIFS: Fix wrong directory attributes after rename
>
> Ralf Baechle (1):
> MIPS: Fix accessing to per-cpu data when flushing the cache
>
> Stefan Kristiansson (1):
Re: [PATCH 3.4 00/45] 3.4.104-rc1 review
Hi Li,
At Tue, 23 Sep 2014 10:27:39 +0800,
Zefan Li wrote:
From: Zefan Li lize...@huawei.com
This is the start of the stable review cycle for the 3.4.104 release.
There are 45 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.
Responses should be made by Thu Sep 25 02:03:31 UTC 2014.
Anything received after that time might be too late.
This kernel passed my test.
- Test Cases:
- Build this kernel.
- Boot this kernel.
- Build the latest mainline kernel with this kernel.
- Test Tool:
https://github.com/satoru-takeuchi/test-linux-stable
- Test Result (kernel .config, ktest config and test log):
http://satoru-takeuchi.org/test-linux-stable/results/version-test
datetime.tar.xz
- Build Environment:
- OS: Debian Jessy x86_64
- CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
- memory: 8GB
- Test Target Environment:
- Debian Jessy x86_64 (KVM guest on the Build Environment)
- # of vCPU: 2
- memory: 2GB
Thanks,
Satoru
A combined patch relative to 3.4.103 will be posted as an additional
response to this. A shortlog and diffstat can be found below.
thanks,
Zefan Li
Aaro Koskinen (1):
MIPS: OCTEON: make get_system_type() thread-safe
Alan Douglas (1):
xtensa: fix address checks in dma_{alloc,free}_coherent
Andi Kleen (1):
slab/mempolicy: always use local policy from interrupt context
Anton Blanchard (1):
ibmveth: Fix endian issues with rx_no_buffer statistic
Arjun Sreedharan (1):
pata_scc: propagate return value of scc_wait_after_reset
Benjamin Tissoires (1):
HID: logitech-dj: prevent false errors to be shown
Brennan Ashton (1):
USB: option: add VIA Telecom CDS7 chipset device id
Daniel Mack (1):
ASoC: pxa-ssp: drop SNDRV_PCM_FMTBIT_S24_LE
Dave Chiluk (1):
stable_kernel_rules: Add pointer to netdev-FAQ for network patches
Fengguang Wu (1):
unicore32: select generic atomic64_t support
Florian Fainelli (1):
MIPS: perf: Fix build error caused by unused
counters_per_cpu_to_total()
Greg KH (1):
USB: serial: pl2303: add device id for ztek device
Guan Xuetao (2):
UniCore32-bugfix: Remove definitions in asm/bug.h to solve difference
between native and cross compiler
UniCore32-bugfix: fix mismatch return value of __xchg_bad_pointer
Hans de Goede (1):
xhci: Treat not finding the event_seg on COMP_STOP the same as
COMP_STOP_INVAL
Huang Rui (1):
usb: xhci: amd chipset also needs short TX quirk
James Forshaw (1):
USB: whiteheat: Added bounds checking for bulk command response
Jan Kara (2):
isofs: Fix unbounded recursion when processing relocated directories
ext2: Fix fs corruption in ext2_get_xip_mem()
Jaša Bartelj (1):
USB: ftdi_sio: Added PID for new ekey device
Jiri Kosina (4):
HID: fix a couple of off-by-ones
HID: logitech: perform bounds checking on device_id early enough
HID: magicmouse: sanity check report size in raw_event() callback
HID: picolcd: sanity check report size in raw_event() callback
Joerg Roedel (1):
iommu/amd: Fix cleanup_domain for mass device removal
Johan Hovold (3):
USB: ftdi_sio: add Basic Micro ATOM Nano USB2Serial PID
USB: serial: fix potential stack buffer overflow
USB: serial: fix potential heap buffer overflow
Mark Einon (1):
staging: et131x: Fix errors caused by phydev-addr accesses before
initialisation
Mark Rutland (2):
ARM: 8128/1: abort: don't clear the exclusive monitors
ARM: 8129/1: errata: work around Cortex-A15 erratum 830321 using
dummy strex
Max Filippov (3):
xtensa: replace IOCTL code definitions with constants
xtensa: fix TLBTEMP_BASE_2 region handling in fast_second_level_miss
xtensa: fix a6 and a7 handling in fast_syscall_xtensa
Michael Cree (2):
alpha: Fix fall-out from disintegrating asm/system.h
alpha: add io{read,write}{16,32}be functions
Michael S. Tsirkin (1):
kvm: iommu: fix the third parameter of kvm_iommu_put_pages
(CVE-2014-3601)
NeilBrown (1):
md/raid6: avoid data corruption during recovery of double-degraded
RAID6
Paul Gortmaker (1):
8250_pci: fix warnings in backport of Broadcom TruManage support
Pavel Shilovsky (1):
CIFS: Fix wrong directory attributes after rename
Ralf Baechle (1):
MIPS: Fix accessing to per-cpu data when flushing the cache
Stefan Kristiansson (1):
openrisc: add missing header inclusion
Stephen Hemminger (1):
USB: sisusb: add device id for Magic Control USB video
Takashi Iwai (1):
ALSA: hda/realtek - Avoid setting wrong COEF on ALC269 co
Trond Myklebust (1):
NFSv4: Fix problems with close in the presence of a delegation
Documentation/stable_kernel_rules.txt |3 ++
arch/alpha/include/asm/io.h |5 +++
arch/alpha/oprofile/common.c |1 +
arch/arm/kernel/entry-header.S
Re: [PATCH 3.16 000/158] 3.16.3-stable review
At Mon, 15 Sep 2014 12:23:59 -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.16.3 release. > There are 158 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. > > Responses should be made by Wed Sep 17 19:25:26 UTC 2014. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.16.3-rc1.gz > and the diffstat can be found below. All 3.10.55-rc1, 3.14.19-rc1, and 3.6.3-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > thanks, > > greg k-h > > - > Pseudo-Shortlog of commits: > > Greg Kroah-Hartman > Linux 3.16.3-rc1 > > David Howells > KEYS: Fix termination condition in assoc array garbage collection > > David Howells > KEYS: Fix use-after-free in assoc_array_gc() > > Pavel Shilovsky > CIFS: Fix SMB2 readdir error handling > > Linus Torvalds > vfs: fix bad hashing of dentries > > Mario Kleiner > drm/nouveau: Bump version from 1.1.1 to 1.1.2 > > Mario Kleiner > drm/nouveau: Dis/Enable vblank irqs during suspend/resume. > > Bart Van Assche > IB/srp: Fix deadlock between host removal and multipathd > > Jeff Moyer > dm table: propagate QUEUE_FLAG_NO_SG_MERGE > > Tejun Heo > blkcg: don't call into policy draining if root_blkg is already gone > > Roger Quadros > mtd: nand: omap: Fix 1-bit Hamming code scheme, omap_calculate_ecc() > > Kevin Hao > mtd/ftl: fix the double free of the buffers allocated in build_maps() > > Pavel Shilovsky > CIFS: Fix wrong restart readdir for SMB1 > > Pavel Shilovsky > CIFS: Fix wrong filename length for SMB2 > > Pavel Shilovsky > CIFS: Fix directory rename error > > Pavel Shilovsky > CIFS: Fix wrong directory attributes after rename > > Steve French > CIFS: Possible null ptr deref in SMB2_tcon > > Pavel Shilovsky > CIFS: Fix async reading on reconnects > > Pavel Shilovsky > CIFS: Fix STATUS_CANNOT_DELETE error mapping for SMB2 > > Ilya Dryomov > libceph: do not hard code max auth ticket len > > Ilya Dryomov > libceph: add process_one_ticket() helper > > Sage Weil > libceph: gracefully handle large reply messages from the mon > > Ilya Dryomov > libceph: set last_piece in ceph_msg_data_pages_cursor_init() correctly > > Chris Mason > xfs: don't zero partial page cache pages during O_DIRECT write > > Dave Chinner > xfs: don't zero partial page cache pages during O_DIRECT writes > > Dave Chinner > xfs: don't dirty buffers beyond EOF > > Dave Chinner > xfs: quotacheck leaves dquot buffers without verifiers > > Dave Chinner > xfs: ensure verifiers are attached to recovered buffers > > Doug Ledford > RDMA/uapi: Include socket.h in rdma_user_cm.h > > Steve Wise > RDMA/iwcm: Use a default listen backlog if needed > > NeilBrown > md/raid10: Fix memory leak when raid10 reshape completes. > > NeilBrown > md/raid10: fix memory leak when reshaping a RAID10. > > NeilBrown > md/raid6: avoid data corruption during recovery of double-degraded RAID6 > > NeilBrown > md/raid5: avoid livelock caused by non-aligned writes. > > NeilBrown > md/raid1,raid10: always abort recover on write error. > > Al Viro > fix copy_tree() regression > > Ilya Dryomov > rbd: rework rbd_request_fn() > > Al Viro > __generic_file_write_iter(): fix handling of sync error after DIO > > Vignesh Raman > Bluetooth: Avoid use of session socket after the session gets freed > > Johan Hedberg > Bluetooth: Fix using uninitialized variable when pairing > > Vladimir Davydov > Bluetooth: never linger on process exit > > Johan Hedberg > Bluetooth: Fix tracking local SSP authentication requirement > > Marcel Holtmann > Bluetooth: Fix merge
Re: [PATCH 3.16 000/158] 3.16.3-stable review
At Mon, 15 Sep 2014 12:23:59 -0700, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.16.3 release. There are 158 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. Responses should be made by Wed Sep 17 19:25:26 UTC 2014. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.16.3-rc1.gz and the diffstat can be found below. All 3.10.55-rc1, 3.14.19-rc1, and 3.6.3-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman gre...@linuxfoundation.org Linux 3.16.3-rc1 David Howells dhowe...@redhat.com KEYS: Fix termination condition in assoc array garbage collection David Howells dhowe...@redhat.com KEYS: Fix use-after-free in assoc_array_gc() Pavel Shilovsky pshilov...@samba.org CIFS: Fix SMB2 readdir error handling Linus Torvalds torva...@linux-foundation.org vfs: fix bad hashing of dentries Mario Kleiner mario.kleiner...@gmail.com drm/nouveau: Bump version from 1.1.1 to 1.1.2 Mario Kleiner mario.kleiner...@gmail.com drm/nouveau: Dis/Enable vblank irqs during suspend/resume. Bart Van Assche bvanass...@acm.org IB/srp: Fix deadlock between host removal and multipathd Jeff Moyer jmo...@redhat.com dm table: propagate QUEUE_FLAG_NO_SG_MERGE Tejun Heo t...@kernel.org blkcg: don't call into policy draining if root_blkg is already gone Roger Quadros rog...@ti.com mtd: nand: omap: Fix 1-bit Hamming code scheme, omap_calculate_ecc() Kevin Hao haoke...@gmail.com mtd/ftl: fix the double free of the buffers allocated in build_maps() Pavel Shilovsky pshilov...@samba.org CIFS: Fix wrong restart readdir for SMB1 Pavel Shilovsky pshilov...@samba.org CIFS: Fix wrong filename length for SMB2 Pavel Shilovsky pshilov...@samba.org CIFS: Fix directory rename error Pavel Shilovsky pshilov...@samba.org CIFS: Fix wrong directory attributes after rename Steve French smfre...@gmail.com CIFS: Possible null ptr deref in SMB2_tcon Pavel Shilovsky pshilov...@samba.org CIFS: Fix async reading on reconnects Pavel Shilovsky pshilov...@samba.org CIFS: Fix STATUS_CANNOT_DELETE error mapping for SMB2 Ilya Dryomov ilya.dryo...@inktank.com libceph: do not hard code max auth ticket len Ilya Dryomov ilya.dryo...@inktank.com libceph: add process_one_ticket() helper Sage Weil s...@redhat.com libceph: gracefully handle large reply messages from the mon Ilya Dryomov ilya.dryo...@inktank.com libceph: set last_piece in ceph_msg_data_pages_cursor_init() correctly Chris Mason c...@fb.com xfs: don't zero partial page cache pages during O_DIRECT write Dave Chinner dchin...@redhat.com xfs: don't zero partial page cache pages during O_DIRECT writes Dave Chinner dchin...@redhat.com xfs: don't dirty buffers beyond EOF Dave Chinner dchin...@redhat.com xfs: quotacheck leaves dquot buffers without verifiers Dave Chinner dchin...@redhat.com xfs: ensure verifiers are attached to recovered buffers Doug Ledford dledf...@redhat.com RDMA/uapi: Include socket.h in rdma_user_cm.h Steve Wise sw...@opengridcomputing.com RDMA/iwcm: Use a default listen backlog if needed NeilBrown ne...@suse.de md/raid10: Fix memory leak when raid10 reshape completes. NeilBrown ne...@suse.de md/raid10: fix memory leak when reshaping a RAID10. NeilBrown ne...@suse.de md/raid6: avoid data corruption during recovery of double-degraded RAID6 NeilBrown ne...@suse.de md/raid5: avoid livelock caused by non-aligned writes. NeilBrown ne...@suse.de md/raid1,raid10: always abort recover on write error. Al Viro v...@zeniv.linux.org.uk fix copy_tree() regression Ilya Dryomov ilya.dryo...@inktank.com rbd: rework rbd_request_fn() Al Viro v...@zeniv.linux.org.uk __generic_file_write_iter(): fix handling of sync error after DIO Vignesh Raman vignesh_ra...@mentor.com Bluetooth: Avoid use of session socket after the session gets freed Johan Hedberg johan.hedb...@intel.com Bluetooth: Fix using uninitialized
Re: [PATCH 3.2 000/131] 3.2.63-rc1 review
At Thu, 11 Sep 2014 06:30:06 -0700, Guenter Roeck wrote: > > On 09/11/2014 05:32 AM, Ben Hutchings wrote: > > This is the start of the stable review cycle for the 3.2.63 release. > > There are 131 patches in this series, which will be posted as responses > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sat Sep 13 12:32:13 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 111 pass: 106 fail: 5 > Failed builds: > microblaze:mmu_defconfig > microblaze:nommu_defconfig > mips:allmodconfig > xtensa:defconfig > xtensa:allmodconfig > > Qemu test results: > total: 18 pass: 17 fail: 1 > Failed tests: > microblaze:microblaze_defconfig > > Results are as expected and an improvement over previous releases, > where sparc64:allmodconfig used to fail as well. The failing qemu > test was added to the list of tests only recently and is a known > problem. > > Guenter Plus, this kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.2 000/131] 3.2.63-rc1 review
At Thu, 11 Sep 2014 06:30:06 -0700, Guenter Roeck wrote: On 09/11/2014 05:32 AM, Ben Hutchings wrote: This is the start of the stable review cycle for the 3.2.63 release. There are 131 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Sep 13 12:32:13 UTC 2014. Anything received after that time might be too late. Build results: total: 111 pass: 106 fail: 5 Failed builds: microblaze:mmu_defconfig microblaze:nommu_defconfig mips:allmodconfig xtensa:defconfig xtensa:allmodconfig Qemu test results: total: 18 pass: 17 fail: 1 Failed tests: microblaze:microblaze_defconfig Results are as expected and an improvement over previous releases, where sparc64:allmodconfig used to fail as well. The failing qemu test was added to the list of tests only recently and is a known problem. Guenter Plus, this kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ktest: add ability to skip during BISECT_MANUAL
Hi Chris,
Sorry for late reply.
2014-08-28 3:26 GMT+09:00 Chris J Arges :
> When doing a manual bisect, a build can fail or a test can be inconclusive.
> In these cases it would be helpful to be able to skip the test entirely.
>
> Signed-off-by: Chris J Arges
It look good to me.
Reviewed-by: Satoru Takeuchi
Thanks,
Satoru
>
> ---
> tools/testing/ktest/ktest.pl | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
> index 55ab700..72010f4 100755
> --- a/tools/testing/ktest/ktest.pl
> +++ b/tools/testing/ktest/ktest.pl
> @@ -2336,15 +2336,17 @@ sub success {
>
> sub answer_bisect {
> for (;;) {
> - doprint "Pass or fail? [p/f]";
> + doprint "Pass, fail, or skip? [p/f/s]";
> my $ans = ;
> chomp $ans;
> if ($ans eq "p" || $ans eq "P") {
> return 1;
> } elsif ($ans eq "f" || $ans eq "F") {
> return 0;
> + } elsif ($ans eq "s" || $ans eq "S") {
> + return -1;
> } else {
> - print "Please answer 'P' or 'F'\n";
> + print "Please answer 'p', 'f', or 's'\n";
> }
> }
> }
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ktest: add ability to skip during BISECT_MANUAL
Hi Chris,
Sorry for late reply.
2014-08-28 3:26 GMT+09:00 Chris J Arges chris.j.ar...@canonical.com:
When doing a manual bisect, a build can fail or a test can be inconclusive.
In these cases it would be helpful to be able to skip the test entirely.
Signed-off-by: Chris J Arges chris.j.ar...@canonical.com
It look good to me.
Reviewed-by: Satoru Takeuchi satoru.takeu...@gmail.com
Thanks,
Satoru
---
tools/testing/ktest/ktest.pl | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index 55ab700..72010f4 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -2336,15 +2336,17 @@ sub success {
sub answer_bisect {
for (;;) {
- doprint Pass or fail? [p/f];
+ doprint Pass, fail, or skip? [p/f/s];
my $ans = STDIN;
chomp $ans;
if ($ans eq p || $ans eq P) {
return 1;
} elsif ($ans eq f || $ans eq F) {
return 0;
+ } elsif ($ans eq s || $ans eq S) {
+ return -1;
} else {
- print Please answer 'P' or 'F'\n;
+ print Please answer 'p', 'f', or 's'\n;
}
}
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.16 00/17] 3.16.1-stable review
At Sat, 9 Aug 2014 08:49:16 -0700, Greg Kroah-Hartman wrote: > > On Sat, Aug 09, 2014 at 08:43:01AM -0600, Shuah Khan wrote: > > On 08/08/2014 03:35 PM, Greg Kroah-Hartman wrote: > > >This is the start of the stable review cycle for the 3.16.1 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. > > > > > >Responses should be made by Sun Aug 10 21:34:49 UTC 2014. > > >Anything received after that time might be too late. > > > > > >The whole patch series can be found in one patch at: > > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.16.1-rc1.gz > > >and the diffstat can be found below. > > > > > >thanks, > > > > > >greg k-h > > > > > > > Compiled and booted on my test system. No dmesg regressions. > > Thanks for testing all of these and letting me know. > > greg k-h All 3.16.1-rc1, 3.15.10-rc1, 3.14.17-rc1, 3.10.53-rc1, and 3.4.103-rc1 passed my test. # Five stable-rc kernels! It's the largest number I've ever tested at a one time :-) - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.16 00/17] 3.16.1-stable review
At Sat, 9 Aug 2014 08:49:16 -0700, Greg Kroah-Hartman wrote: On Sat, Aug 09, 2014 at 08:43:01AM -0600, Shuah Khan wrote: On 08/08/2014 03:35 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.16.1 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. Responses should be made by Sun Aug 10 21:34:49 UTC 2014. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.16.1-rc1.gz and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. Thanks for testing all of these and letting me know. greg k-h All 3.16.1-rc1, 3.15.10-rc1, 3.14.17-rc1, 3.10.53-rc1, and 3.4.103-rc1 passed my test. # Five stable-rc kernels! It's the largest number I've ever tested at a one time :-) - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.2 00/94] 3.2.62-rc1 review
At Mon, 4 Aug 2014 10:55:44 -0700, Guenter Roeck wrote: > > On Mon, Aug 04, 2014 at 05:48:31PM +0100, Ben Hutchings wrote: > > This is the start of the stable review cycle for the 3.2.62 release. > > There are 94 patches in this series, which will be posted as responses > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Wed Aug 06 17:00:00 UTC 2014. > > Anything received after that time might be too late. > > > Build results: > total: 111 pass: 105 fail: 6 > Failed builds: > microblaze:mmu_defconfig > microblaze:nommu_defconfig > mips:allmodconfig > sparc64:allmodconfig > xtensa:defconfig > xtensa:allmodconfig > > Qemu tests all passed. > > This is a significant improvement over the previous versions, where we used > to see up to 10 build failures. The previously failing builds for unicore32 > and score now pass, as well as alpha:allmodconfig. > > Note that I rearranged arm builds to improve test coverage. > > Details are available at http://server.roeck-us.net:8010/builders. > > Guenter This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 00/42] 3.15.9-stable review
At Tue, 5 Aug 2014 16:27:04 -0700, Greg Kroah-Hartman wrote: > > On Tue, Aug 05, 2014 at 05:07:00PM -0600, Shuah Khan wrote: > > On 08/05/2014 12:13 PM, Greg Kroah-Hartman wrote: > > >This is the start of the stable review cycle for the 3.15.9 release. > > >There are 42 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. > > > > > >Responses should be made by Thu Aug 7 18:13:05 UTC 2014. > > >Anything received after that time might be too late. > > > > > >The whole patch series can be found in one patch at: > > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.9-rc1.gz > > >and the diffstat can be found below. > > > > > >thanks, > > > > > >greg k-h > > > > > > > Compiled and booted on my test system. No dmesg regressions > > compared to previous 3.15.8 > > Thanks for testing all of these and letting me know. > > greg k-h All 3.15.9-rc1, 3.14.16-rc1, 3.10.52-rc1, and 3.4.102-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 00/42] 3.15.9-stable review
At Tue, 5 Aug 2014 16:27:04 -0700, Greg Kroah-Hartman wrote: On Tue, Aug 05, 2014 at 05:07:00PM -0600, Shuah Khan wrote: On 08/05/2014 12:13 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.15.9 release. There are 42 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. Responses should be made by Thu Aug 7 18:13:05 UTC 2014. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.9-rc1.gz and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions compared to previous 3.15.8 Thanks for testing all of these and letting me know. greg k-h All 3.15.9-rc1, 3.14.16-rc1, 3.10.52-rc1, and 3.4.102-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.2 00/94] 3.2.62-rc1 review
At Mon, 4 Aug 2014 10:55:44 -0700, Guenter Roeck wrote: On Mon, Aug 04, 2014 at 05:48:31PM +0100, Ben Hutchings wrote: This is the start of the stable review cycle for the 3.2.62 release. There are 94 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Aug 06 17:00:00 UTC 2014. Anything received after that time might be too late. Build results: total: 111 pass: 105 fail: 6 Failed builds: microblaze:mmu_defconfig microblaze:nommu_defconfig mips:allmodconfig sparc64:allmodconfig xtensa:defconfig xtensa:allmodconfig Qemu tests all passed. This is a significant improvement over the previous versions, where we used to see up to 10 build failures. The previously failing builds for unicore32 and score now pass, as well as alpha:allmodconfig. Note that I rearranged arm builds to improve test coverage. Details are available at http://server.roeck-us.net:8010/builders. Guenter This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 00/94] 3.12.26-stable review
At Wed, 30 Jul 2014 12:22:27 -0700, Guenter Roeck wrote: > > On Wed, Jul 30, 2014 at 02:15:03PM +0200, Jiri Slaby wrote: > > This is the start of the stable review cycle for the 3.12.26 release. > > There are 94 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. > > > > Responses should be made by Fri Aug 1 14:11:10 CEST 2014. > > Anything received after that time might be too late. > > > Build results: > total: 139 pass: 139 fail: 0 > > Qemu tests all passed. > > Details are available at http://server.roeck-us.net:8010/builders. > > Guenter This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 00/37] 3.15.8-stable review
At Tue, 29 Jul 2014 18:48:36 -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.15.8 release. > There are 37 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. > > Responses should be made by Fri Aug 1 01:48:13 UTC 2014. > Anything received after that time might be too late. All 3.15.8-rc1, 3.14.15-rc1, 3.10.51-rc1, and 3.4.101-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.8-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > > - > Pseudo-Shortlog of commits: > > Greg Kroah-Hartman > Linux 3.15.8-rc1 > > Guenter Roeck > platform_get_irq: Revert to platform_get_resource if of_irq_get fails > > Johannes Berg > nl80211: move set_qos_map command into split state > > Konstantin Khlebnikov > mm: do not call do_fault_around for non-linear fault > > Amit Shah > hwrng: virtio - ensure reads happen after successful probe > > Linus Torvalds > Fix gcc-4.9.0 miscompilation of load_balance() in scheduler > > Naoya Horiguchi > mm: hugetlb: fix copy_hugetlb_page_range() > > Jerome Glisse > drm/radeon: fix cut and paste issue for hawaii. > > Christian König > drm/radeon: fix irq ring buffer overflow handling > > Sven Wegener > x86_32, entry: Store badsys error code in %eax > > Vasily Averin > fs: umount on symlink leaks mnt count > > Randy Dunlap > parport: fix menu breakage > > Guenter Roeck > hwmon: (smsc47m192) Fix temperature limit and vrm write operations > > John David Anglin > parisc: Remove SA_RESTORER define > > Maxime COQUELIN > pinctrl: st: Fix irqmux handler > > Andrew Gallagher > fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT > > Miklos Szeredi > fuse: s_time_gran fix > > Silesh C V > coredump: fix the setting of PF_DUMPCORE > > Dmitry Torokhov > Input: fix defuzzing logic > > Hans de Goede > Input: synaptics - add min/max quirk for pnp-id LEN2002 (Edge E531) > > Mikulas Patocka > slab_common: fix the check for duplicate slab names > > Tyrel Datwyler > powerpc/pseries: dynamically added OF nodes need to call of_node_init > > Minchan Kim > zram: avoid lockdep splat by revalidate_disk > > Tony Luck > tracing: Fix wraparound problems in "uptime" trace clock > > Tejun Heo > blkcg: don't call into policy draining if root_blkg is already gone > > Romain Degez > ahci: add support for the Promise FastTrak TX8660 SATA HBA (ahci mode) > > Martin Schwidefsky > s390/ptrace: fix PSW mask check > > Tejun Heo > libata: introduce ata_host->n_tags to avoid oops on SAS controllers > > Kevin Hao > libata: support the ata host which implements a queue depth less than 32 > > Christoph Hellwig > block: don't assume last put of shared tags is for the host > > Mikulas Patocka > block: provide compat ioctl for BLKZEROOUT > > Max Filippov > xtensa: fix sysmem reservation at the end of existing block > > Christoph Hellwig > nfs: only show Posix ACLs in listxattr if actually present > > Antti Palosaari > media: tda10071: force modulation to QPSK on DVB-S > > Hans Verkuil > media: hdpvr: fix two audio bugs > > Antti Palosaari > media: af9035: override tuner id when bad value set into eeprom > > Rickard Strandqvist > media: media: v4l2-core: v4l2-dv-timings.c: Cleaning up code wrong value > used in aspect ratio > > Arnd Bergmann > media: staging: tighten omap4iss dependencies > > > - > > Diffstat: > > Makefile | 6 +++-- > arch/parisc/include/uapi/asm/signal.h | 2 -- > arch/powerpc/platforms/pseries/dlpar.c| 1 + > arch/powerpc/platforms/pseries/reconfig.c | 1 + > arch
Re: [PATCH 3.15 00/37] 3.15.8-stable review
At Tue, 29 Jul 2014 18:48:36 -0700, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.15.8 release. There are 37 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. Responses should be made by Fri Aug 1 01:48:13 UTC 2014. Anything received after that time might be too late. All 3.15.8-rc1, 3.14.15-rc1, 3.10.51-rc1, and 3.4.101-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.8-rc1.gz and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman gre...@linuxfoundation.org Linux 3.15.8-rc1 Guenter Roeck li...@roeck-us.net platform_get_irq: Revert to platform_get_resource if of_irq_get fails Johannes Berg johannes.b...@intel.com nl80211: move set_qos_map command into split state Konstantin Khlebnikov koc...@gmail.com mm: do not call do_fault_around for non-linear fault Amit Shah amit.s...@redhat.com hwrng: virtio - ensure reads happen after successful probe Linus Torvalds torva...@linux-foundation.org Fix gcc-4.9.0 miscompilation of load_balance() in scheduler Naoya Horiguchi n-horigu...@ah.jp.nec.com mm: hugetlb: fix copy_hugetlb_page_range() Jerome Glisse jgli...@redhat.com drm/radeon: fix cut and paste issue for hawaii. Christian König christian.koe...@amd.com drm/radeon: fix irq ring buffer overflow handling Sven Wegener sven.wege...@stealer.net x86_32, entry: Store badsys error code in %eax Vasily Averin v...@parallels.com fs: umount on symlink leaks mnt count Randy Dunlap rdun...@infradead.org parport: fix menu breakage Guenter Roeck li...@roeck-us.net hwmon: (smsc47m192) Fix temperature limit and vrm write operations John David Anglin dave.ang...@bell.net parisc: Remove SA_RESTORER define Maxime COQUELIN maxime.coque...@st.com pinctrl: st: Fix irqmux handler Andrew Gallagher andrew...@fb.com fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT Miklos Szeredi mszer...@suse.cz fuse: s_time_gran fix Silesh C V svella...@mvista.com coredump: fix the setting of PF_DUMPCORE Dmitry Torokhov d...@chromium.org Input: fix defuzzing logic Hans de Goede hdego...@redhat.com Input: synaptics - add min/max quirk for pnp-id LEN2002 (Edge E531) Mikulas Patocka mpato...@redhat.com slab_common: fix the check for duplicate slab names Tyrel Datwyler tyr...@linux.vnet.ibm.com powerpc/pseries: dynamically added OF nodes need to call of_node_init Minchan Kim minc...@kernel.org zram: avoid lockdep splat by revalidate_disk Tony Luck tony.l...@intel.com tracing: Fix wraparound problems in uptime trace clock Tejun Heo t...@kernel.org blkcg: don't call into policy draining if root_blkg is already gone Romain Degez romain.de...@gmail.com ahci: add support for the Promise FastTrak TX8660 SATA HBA (ahci mode) Martin Schwidefsky schwidef...@de.ibm.com s390/ptrace: fix PSW mask check Tejun Heo t...@kernel.org libata: introduce ata_host-n_tags to avoid oops on SAS controllers Kevin Hao haoke...@gmail.com libata: support the ata host which implements a queue depth less than 32 Christoph Hellwig h...@lst.de block: don't assume last put of shared tags is for the host Mikulas Patocka mpato...@redhat.com block: provide compat ioctl for BLKZEROOUT Max Filippov jcmvb...@gmail.com xtensa: fix sysmem reservation at the end of existing block Christoph Hellwig h...@lst.de nfs: only show Posix ACLs in listxattr if actually present Antti Palosaari cr...@iki.fi media: tda10071: force modulation to QPSK on DVB-S Hans Verkuil hverk...@xs4all.nl media: hdpvr: fix two audio bugs Antti Palosaari cr...@iki.fi media: af9035: override tuner id when bad value set into eeprom Rickard Strandqvist rickard_strandqv...@spectrumdigital.se media: media: v4l2-core: v4l2-dv-timings.c: Cleaning up code wrong value used in aspect ratio Arnd Bergmann a...@arndb.de media: staging: tighten omap4iss dependencies - Diffstat: Makefile | 6 +++-- arch
Re: [PATCH 3.12 00/94] 3.12.26-stable review
At Wed, 30 Jul 2014 12:22:27 -0700, Guenter Roeck wrote: On Wed, Jul 30, 2014 at 02:15:03PM +0200, Jiri Slaby wrote: This is the start of the stable review cycle for the 3.12.26 release. There are 94 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. Responses should be made by Fri Aug 1 14:11:10 CEST 2014. Anything received after that time might be too late. Build results: total: 139 pass: 139 fail: 0 Qemu tests all passed. Details are available at http://server.roeck-us.net:8010/builders. Guenter This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 000/109] 3.15.7-stable review
At Sat, 26 Jul 2014 12:01:22 -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.15.7 release. > There are 109 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. > > Responses should be made by Mon Jul 28 19:02:07 UTC 2014. > Anything received after that time might be too late. All 3.15.7-rc1, 3.14.14-rc1, 3.10.50-rc1, and 3.4.100-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.7-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > > - > Pseudo-Shortlog of commits: > > Greg Kroah-Hartman > Linux 3.15.7-rc1 > > Anton Kolesov > ARC: Implement ptrace(PTRACE_GET_THREAD_AREA) > > Linus Torvalds > Don't trigger congestion wait on dirty-but-not-writeout pages > > Emmanuel Grumbach > iwlwifi: mvm: disable CTS to Self > > Marek Vasut > ARM: dts: imx: Add alias for ethernet controller > > Sebastian Andrzej Siewior > gpio: dwapb: drop irq_setup_generic_chip() > > Benjamin LaHaise > aio: protect reqs_available updates from changes in interrupt handlers > > Or Gerlitz > IB/mlx5: Enable "block multicast loopback" for kernel consumers > > Michael Brown > x86/efi: Include a .bss section within the PE/COFF headers > > Mateusz Guzik > sched: Fix possible divide by zero in avg_atom() calculation > > Peter Zijlstra > locking/mutex: Disable optimistic spinning on some architectures > > Takashi Iwai > PM / sleep: Fix request_firmware() error at resume > > Steve Wise > RDMA/cxgb4: Initialize the device status page > > Mike Snitzer > dm cache metadata: do not allow the data block size to change > > Mike Snitzer > dm thin metadata: do not allow the data block size to change > > Ted Juan > mtd: devices: elm: fix elm_context_save() and elm_context_restore() > functions > > Hannes Frederic Sowa > random: check for increase of entropy_count because of signed conversion > > Viresh Kumar > cpufreq: move policy kobj to policy->cpu at resume > > Peter Zijlstra > x86, tsc: Fix cpufreq lockup > > Amit Shah > hwrng: fetch randomness only after device init > > John Stultz > alarmtimer: Fix bug where relative alarm timers were treated as absolute > > Dave Airlie > Revert "drm/i915: reverse dp link param selection, prefer fast over wide > again" > > Alex Deucher > drm/radeon: avoid leaking edid data > > Jason Wang > drm/qxl: return IRQ_NONE if it was not our irq > > Alex Deucher > drm/radeon: set default bl level to something reasonable > > Tomasz Figa > irqchip: gic: Fix core ID calculation when topology is read from DT > > Suravee Suthikulpanit > irqchip: gic: Add binding probe for ARM GIC400 > > Matthias Brugger > irqchip: gic: Add support for cortex a7 compatible string > > Martin Lau > ring-buffer: Fix polling on trace_pipe > > Amitkumar Karwar > mwifiex: fix Tx timeout issue > > HATAYAMA Daisuke > perf/x86/intel: ignore CondChgd bit to avoid false NMI handling > > Jiri Olsa > perf: Do not allow optimized switch for non-cloned events > > Zoltan Kiss > xen-netback: Fix pointer incrementation to avoid incorrect logging > > Zoltan Kiss > xen-netback: Fix releasing header slot on error path > > Zoltan Kiss > xen-netback: Fix releasing frag_list skbs in error path > > Zoltan Kiss > xen-netback: Fix handling frag_list on grant op error path > > Eric Dumazet > ipv4: fix buffer overflow in ip_options_compile() > > Ben Hutchings > dns_resolver: Null-terminate the right string > > Manuel Schölling > dns_resolver: assure that dns_query() result is null-terminated > > Christoph Schulz > net: ppp: don't call sk_chk_filter twice > >
Re: [PATCH 3.15 000/109] 3.15.7-stable review
At Sat, 26 Jul 2014 12:01:22 -0700, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.15.7 release. There are 109 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. Responses should be made by Mon Jul 28 19:02:07 UTC 2014. Anything received after that time might be too late. All 3.15.7-rc1, 3.14.14-rc1, 3.10.50-rc1, and 3.4.100-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.7-rc1.gz and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman gre...@linuxfoundation.org Linux 3.15.7-rc1 Anton Kolesov anton.kole...@synopsys.com ARC: Implement ptrace(PTRACE_GET_THREAD_AREA) Linus Torvalds torva...@linux-foundation.org Don't trigger congestion wait on dirty-but-not-writeout pages Emmanuel Grumbach emmanuel.grumb...@intel.com iwlwifi: mvm: disable CTS to Self Marek Vasut ma...@denx.de ARM: dts: imx: Add alias for ethernet controller Sebastian Andrzej Siewior bige...@linutronix.de gpio: dwapb: drop irq_setup_generic_chip() Benjamin LaHaise b...@kvack.org aio: protect reqs_available updates from changes in interrupt handlers Or Gerlitz ogerl...@mellanox.com IB/mlx5: Enable block multicast loopback for kernel consumers Michael Brown mbr...@fensystems.co.uk x86/efi: Include a .bss section within the PE/COFF headers Mateusz Guzik mgu...@redhat.com sched: Fix possible divide by zero in avg_atom() calculation Peter Zijlstra pet...@infradead.org locking/mutex: Disable optimistic spinning on some architectures Takashi Iwai ti...@suse.de PM / sleep: Fix request_firmware() error at resume Steve Wise sw...@opengridcomputing.com RDMA/cxgb4: Initialize the device status page Mike Snitzer snit...@redhat.com dm cache metadata: do not allow the data block size to change Mike Snitzer snit...@redhat.com dm thin metadata: do not allow the data block size to change Ted Juan ted.j...@gmail.com mtd: devices: elm: fix elm_context_save() and elm_context_restore() functions Hannes Frederic Sowa han...@stressinduktion.org random: check for increase of entropy_count because of signed conversion Viresh Kumar viresh.ku...@linaro.org cpufreq: move policy kobj to policy-cpu at resume Peter Zijlstra pet...@infradead.org x86, tsc: Fix cpufreq lockup Amit Shah amit.s...@redhat.com hwrng: fetch randomness only after device init John Stultz john.stu...@linaro.org alarmtimer: Fix bug where relative alarm timers were treated as absolute Dave Airlie airl...@redhat.com Revert drm/i915: reverse dp link param selection, prefer fast over wide again Alex Deucher alexander.deuc...@amd.com drm/radeon: avoid leaking edid data Jason Wang jasow...@redhat.com drm/qxl: return IRQ_NONE if it was not our irq Alex Deucher alexander.deuc...@amd.com drm/radeon: set default bl level to something reasonable Tomasz Figa t.f...@samsung.com irqchip: gic: Fix core ID calculation when topology is read from DT Suravee Suthikulpanit suravee.suthikulpa...@amd.com irqchip: gic: Add binding probe for ARM GIC400 Matthias Brugger matthias@gmail.com irqchip: gic: Add support for cortex a7 compatible string Martin Lau ka...@fb.com ring-buffer: Fix polling on trace_pipe Amitkumar Karwar akar...@marvell.com mwifiex: fix Tx timeout issue HATAYAMA Daisuke d.hatay...@jp.fujitsu.com perf/x86/intel: ignore CondChgd bit to avoid false NMI handling Jiri Olsa jo...@redhat.com perf: Do not allow optimized switch for non-cloned events Zoltan Kiss zoltan.k...@citrix.com xen-netback: Fix pointer incrementation to avoid incorrect logging Zoltan Kiss zoltan.k...@citrix.com xen-netback: Fix releasing header slot on error path Zoltan Kiss zoltan.k...@citrix.com xen-netback: Fix releasing frag_list skbs in error path Zoltan Kiss zoltan.k...@citrix.com xen-netback: Fix handling frag_list on grant op error path Eric Dumazet eduma...@google.com ipv4: fix buffer overflow in ip_options_compile() Ben Hutchings b
Re: [PATCH 3.12 000/170] 3.12.25-stable review
At Fri, 18 Jul 2014 06:47:32 -0700, Guenter Roeck wrote: > > On 07/18/2014 05:16 AM, Jiri Slaby wrote: > > On 07/18/2014 02:12 PM, Jiri Slaby wrote: > >> This is the start of the stable review cycle for the 3.12.25 release. > >> There are 170 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. > >> > >> Responses should be made by Sun Jul 20 12:11:21 2014 > > > > Oh, this should have been two *workdays*, i.e. the deadline is Jul 22. > > > > Build results: > total: 137 pass: 137 fail: 0 > > Qemu tests all passed. > > Details are available at http://server.roeck-us.net:8010/builders. > > Guenter > Plus, it passed my test too. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 000/170] 3.12.25-stable review
At Fri, 18 Jul 2014 06:47:32 -0700, Guenter Roeck wrote: On 07/18/2014 05:16 AM, Jiri Slaby wrote: On 07/18/2014 02:12 PM, Jiri Slaby wrote: This is the start of the stable review cycle for the 3.12.25 release. There are 170 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. Responses should be made by Sun Jul 20 12:11:21 2014 Oh, this should have been two *workdays*, i.e. the deadline is Jul 22. Build results: total: 137 pass: 137 fail: 0 Qemu tests all passed. Details are available at http://server.roeck-us.net:8010/builders. Guenter Plus, it passed my test too. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 00/84] 3.15.6-stable review
At Wed, 16 Jul 2014 18:50:45 -0700, Greg Kroah-Hartman wrote: > > On Wed, Jul 16, 2014 at 05:12:28PM -0700, Guenter Roeck wrote: > > On 07/16/2014 04:09 PM, Greg Kroah-Hartman wrote: > > >On Tue, Jul 15, 2014 at 04:16:57PM -0700, Greg Kroah-Hartman wrote: > > >>This is the start of the stable review cycle for the 3.15.6 release. > > >>There are 84 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. > > >> > > >>Responses should be made by Thu Jul 17 23:17:00 UTC 2014. > > >>Anything received after that time might be too late. > > >> > > >>The whole patch series can be found in one patch at: > > >> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.6-rc1.gz > > >>and the diffstat can be found below. > > > > > >Due to some problems with Xen, I've removed a bunch of patches from this > > >series (and the 3.4, 3.10, and 3.14 series) and done a -rc2 release with > > >the updated set: > > > > > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.6-rc2.gz > > > > > > > Build and qemu test for all releases is still fine. > > Great, thanks for letting me know. > > greg k-h All -rc2es passed my test too. Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 00/84] 3.15.6-stable review
At Wed, 16 Jul 2014 18:50:45 -0700, Greg Kroah-Hartman wrote: On Wed, Jul 16, 2014 at 05:12:28PM -0700, Guenter Roeck wrote: On 07/16/2014 04:09 PM, Greg Kroah-Hartman wrote: On Tue, Jul 15, 2014 at 04:16:57PM -0700, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.15.6 release. There are 84 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. Responses should be made by Thu Jul 17 23:17:00 UTC 2014. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.6-rc1.gz and the diffstat can be found below. Due to some problems with Xen, I've removed a bunch of patches from this series (and the 3.4, 3.10, and 3.14 series) and done a -rc2 release with the updated set: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.6-rc2.gz Build and qemu test for all releases is still fine. Great, thanks for letting me know. greg k-h All -rc2es passed my test too. Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 00/84] 3.15.6-stable review
At Tue, 15 Jul 2014 21:28:16 -0700, Guenter Roeck wrote: > > On 07/15/2014 04:16 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.15.6 release. > > There are 84 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. > > > > Responses should be made by Thu Jul 17 23:17:00 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 139 pass: 139 fail: 0 > > Qemu tests all passed. > > Another set of perfect results. > > Details are available at http://server.roeck-us.net:8010/builders. All 3.15.6-rc1, 3.14.13-rc1, 3.10.49-rc1, and 3.4.99-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. # "selftests" is not added to this list yet. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 00/84] 3.15.6-stable review
At Tue, 15 Jul 2014 21:28:16 -0700, Guenter Roeck wrote: On 07/15/2014 04:16 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.15.6 release. There are 84 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. Responses should be made by Thu Jul 17 23:17:00 UTC 2014. Anything received after that time might be too late. Build results: total: 139 pass: 139 fail: 0 Qemu tests all passed. Another set of perfect results. Details are available at http://server.roeck-us.net:8010/builders. All 3.15.6-rc1, 3.14.13-rc1, 3.10.49-rc1, and 3.4.99-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. # selftests is not added to this list yet. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Btrfs: use BUG_ON
Hi Himangi,
(2014/07/09 7:21), Himangi Saraogi wrote:
Use BUG_ON(x) rather than if(x) BUG();
The semantic patch that fixes this problem is as follows:
//
@@ identifier x; @@
-if (x) BUG();
+BUG_ON(x);
//
Strictly speaking, BUG_ON() is "if (unlikely(x)) BUG".
Anyway, I consider that put this condition in unlikely()
in this case is good.
BTW, there are many "if BUG()" case under fs/btrfs.
How about fix all of them?
===
$ grep -rnH -B 1 "BUG()" fs/btrfs | grep -A 1 'if.*('
fs/btrfs/inode.c-6318- } else if (create && PageUptodate(page)) {
fs/btrfs/inode.c:6319: BUG();
--
fs/btrfs/volumes.c-2626-else if (ret)
fs/btrfs/volumes.c:2627:BUG(); # <- your patch
fixes it.
--
fs/btrfs/volumes.c-3092-if (ret == 0)
fs/btrfs/volumes.c:3093:BUG(); /* FIXME break ? */
--
fs/btrfs/raid56.c-2048- if (rbio->faila == -1) {
fs/btrfs/raid56.c:2049: BUG();
===
Thanks,
Satoru
Signed-off-by: Himangi Saraogi
Acked-by: Julia Lawall
---
fs/btrfs/volumes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 6104676..63e746e 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -2623,8 +2623,8 @@ again:
found_key.offset);
if (ret == -ENOSPC)
failed++;
- else if (ret)
- BUG();
+ else
+ BUG_ON(ret);
}
if (found_key.offset == 0)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.2 000/125] 3.2.61-rc1 review
At Tue, 08 Jul 2014 18:27:37 -0700, Guenter Roeck wrote: > > On 07/08/2014 12:01 PM, Ben Hutchings wrote: > > This is the start of the stable review cycle for the 3.2.61 release. > > There are 125 patches in this series, which will be posted as responses > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Jul 10 19:01:49 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 109 pass: 71 fail: 38 > Failed builds: > alpha:allmodconfig > arm:defconfig > arm:imx_v4_v5_defconfig > arm:mxs_defconfig > arm:dove_defconfig > arm:kirkwood_defconfig > arm:omap2plus_defconfig > arm:tegra_defconfig > arm:u8500_defconfig > arm:at91sam9rl_defconfig > arm:pxa910_defconfig > arm:mackerel_defconfig > arm:ixp4xx_defconfig > arm:vexpress_defconfig > arm:msm_defconfig > arm:at91rm9200_defconfig > arm:at91sam9263_defconfig > arm:at91sam9g45_defconfig > arm:assabet_defconfig > i386:defconfig > i386:allyesconfig > i386:allmodconfig > m32r:defconfig > microblaze:mmu_defconfig > microblaze:nommu_defconfig > mips:defconfig > mips:allmodconfig > mips:bcm47xx_defconfig > mips:bcm63xx_defconfig > mips:ar7_defconfig > mips:fuloong2e_defconfig > mips:malta_defconfig > score:defconfig > sparc64:allmodconfig > um:defconfig > unicore32:defconfig > xtensa:defconfig > xtensa:allmodconfig > > Qemu images fail to build for mips, mips64, and x86. > > Build error seems to be always the same. > > lib/nlattr.c: In function 'nla_parse': > lib/nlattr.c:201:3: error: dereferencing pointer to incomplete type > make[1]: *** [lib/nlattr.o] Error 1 > > Culprit is bfc5184b69 (netlink: rate-limit leftover bytes warning > and print process name). In 3.2, it is necessary to include > explicitly to get the definition of 'struct task_struct'. > > Details are available at http://server.roeck-us.net:8010/builders. > > Guenter > This kernel passed my test. I didn't hit the problem which Guenter reported since I only test x86_64 arch. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.2 000/125] 3.2.61-rc1 review
At Tue, 08 Jul 2014 18:27:37 -0700, Guenter Roeck wrote: On 07/08/2014 12:01 PM, Ben Hutchings wrote: This is the start of the stable review cycle for the 3.2.61 release. There are 125 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Jul 10 19:01:49 UTC 2014. Anything received after that time might be too late. Build results: total: 109 pass: 71 fail: 38 Failed builds: alpha:allmodconfig arm:defconfig arm:imx_v4_v5_defconfig arm:mxs_defconfig arm:dove_defconfig arm:kirkwood_defconfig arm:omap2plus_defconfig arm:tegra_defconfig arm:u8500_defconfig arm:at91sam9rl_defconfig arm:pxa910_defconfig arm:mackerel_defconfig arm:ixp4xx_defconfig arm:vexpress_defconfig arm:msm_defconfig arm:at91rm9200_defconfig arm:at91sam9263_defconfig arm:at91sam9g45_defconfig arm:assabet_defconfig i386:defconfig i386:allyesconfig i386:allmodconfig m32r:defconfig microblaze:mmu_defconfig microblaze:nommu_defconfig mips:defconfig mips:allmodconfig mips:bcm47xx_defconfig mips:bcm63xx_defconfig mips:ar7_defconfig mips:fuloong2e_defconfig mips:malta_defconfig score:defconfig sparc64:allmodconfig um:defconfig unicore32:defconfig xtensa:defconfig xtensa:allmodconfig Qemu images fail to build for mips, mips64, and x86. Build error seems to be always the same. lib/nlattr.c: In function 'nla_parse': lib/nlattr.c:201:3: error: dereferencing pointer to incomplete type make[1]: *** [lib/nlattr.o] Error 1 Culprit is bfc5184b69 (netlink: rate-limit leftover bytes warning and print process name). In 3.2, it is necessary to include linux/sched.h explicitly to get the definition of 'struct task_struct'. Details are available at http://server.roeck-us.net:8010/builders. Guenter This kernel passed my test. I didn't hit the problem which Guenter reported since I only test x86_64 arch. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Btrfs: use BUG_ON
Hi Himangi,
(2014/07/09 7:21), Himangi Saraogi wrote:
Use BUG_ON(x) rather than if(x) BUG();
The semantic patch that fixes this problem is as follows:
// smpl
@@ identifier x; @@
-if (x) BUG();
+BUG_ON(x);
// /smpl
Strictly speaking, BUG_ON() is if (unlikely(x)) BUG.
Anyway, I consider that put this condition in unlikely()
in this case is good.
BTW, there are many if BUG() case under fs/btrfs.
How about fix all of them?
===
$ grep -rnH -B 1 BUG() fs/btrfs | grep -A 1 'if.*('
fs/btrfs/inode.c-6318- } else if (create PageUptodate(page)) {
fs/btrfs/inode.c:6319: BUG();
--
fs/btrfs/volumes.c-2626-else if (ret)
fs/btrfs/volumes.c:2627:BUG(); # - your patch
fixes it.
--
fs/btrfs/volumes.c-3092-if (ret == 0)
fs/btrfs/volumes.c:3093:BUG(); /* FIXME break ? */
--
fs/btrfs/raid56.c-2048- if (rbio-faila == -1) {
fs/btrfs/raid56.c:2049: BUG();
===
Thanks,
Satoru
Signed-off-by: Himangi Saraogi himangi...@gmail.com
Acked-by: Julia Lawall julia.law...@lip6.fr
---
fs/btrfs/volumes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 6104676..63e746e 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -2623,8 +2623,8 @@ again:
found_key.offset);
if (ret == -ENOSPC)
failed++;
- else if (ret)
- BUG();
+ else
+ BUG_ON(ret);
}
if (found_key.offset == 0)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 000/122] 3.15.5-stable review
At Tue, 08 Jul 2014 06:26:21 -0700, Guenter Roeck wrote: > > On 07/07/2014 04:56 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.15.5 release. > > There are 122 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. > > > > Responses should be made by Wed Jul 9 23:57:10 UTC 2014. > > Anything received after that time might be too late. > > > > > Build results: > total: 139 pass: 136 fail: 3 > Failed builds: > powerpc:allmodconfig (binutils 2.23) > powerpc:allmodconfig (binutils 2.24) > unicore32:defconfig > > Qemu tests all passed. > > Results are as expected. > > Details are available at http://server.roeck-us.net:8010/builders. > > For the unicore32 build to pass in this release, the following > additional patches would be needed. > > 73fa540618 drivers/rtc/rtc-puv3.c: remove ">" for typo issue > c863810cef drivers/rtc/rtc-puv3.c: use dev_dbg() instead of dev_debug() for > typo issue > > A workaround patch to address the powerpc build failures is pending. > I'll send you a note after it is available if Ben doesn't Cc: stable. 3.15.5-rc1, 3.14.12-rc1, 3.10.48-rc1, and 3.4.98-rc1 passed my test. Build errors in 3.14.11 and 3.10.11-rc1 disappeared. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > Guenter > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 000/122] 3.15.5-stable review
At Tue, 08 Jul 2014 06:26:21 -0700, Guenter Roeck wrote: On 07/07/2014 04:56 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.15.5 release. There are 122 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. Responses should be made by Wed Jul 9 23:57:10 UTC 2014. Anything received after that time might be too late. Build results: total: 139 pass: 136 fail: 3 Failed builds: powerpc:allmodconfig (binutils 2.23) powerpc:allmodconfig (binutils 2.24) unicore32:defconfig Qemu tests all passed. Results are as expected. Details are available at http://server.roeck-us.net:8010/builders. For the unicore32 build to pass in this release, the following additional patches would be needed. 73fa540618 drivers/rtc/rtc-puv3.c: remove dev- for typo issue c863810cef drivers/rtc/rtc-puv3.c: use dev_dbg() instead of dev_debug() for typo issue A workaround patch to address the powerpc build failures is pending. I'll send you a note after it is available if Ben doesn't Cc: stable. 3.15.5-rc1, 3.14.12-rc1, 3.10.48-rc1, and 3.4.98-rc1 passed my test. Build errors in 3.14.11 and 3.10.11-rc1 disappeared. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/59] 3.14.11-stable review
At Sat, 5 Jul 2014 12:10:58 -0700, Greg Kroah-Hartman wrote: > > On Sat, Jul 05, 2014 at 02:56:55PM +0200, Takashi Iwai wrote: > > At Sat, 05 Jul 2014 18:21:04 +0900, > > Satoru Takeuchi wrote: > > > > > > Hi Greg, > > > > > > Add Takashi Iwai to this thread. > > > > > > At Sat, 05 Jul 2014 16:00:41 +0900, > > > Satoru Takeuchi wrote: > > > > > > > > At Fri, 04 Jul 2014 22:45:42 -0700, > > > > Guenter Roeck wrote: > > > > > > > > > > On 07/04/2014 03:18 PM, Greg Kroah-Hartman wrote: > > > > > > This is the start of the stable review cycle for the 3.14.11 > > > > > > release. > > > > > > There are 59 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. > > > > > > > > > > > > Responses should be made by Sun Jul 6 22:15:27 UTC 2014. > > > > > > Anything received after that time might be too late. > > > > > > > > > > > > > > > > Build results: > > > > > total: 144 pass: 130 skipped: 4 fail: 10 > > > > > Failed builds: > > > > > alpha:allmodconfig > > > > > i386:allyesconfig > > > > > i386:allmodconfig > > > > > powerpc:allmodconfig (binutils 2.23) > > > > > powerpc:allmodconfig (binutils 2.24) > > > > > sparc64:allmodconfig > > > > > unicore32:defconfig > > > > > x86_64:allyesconfig > > > > > x86_64:allmodconfig > > > > > xtensa:allmodconfig > > > > > > > > > > Qemu test for x86 failed. > > > > > > > > > > Build error is the same as seen with 3.14. > > > > > > > > > > sound/pci/hda/patch_sigmatel.c: In function 'stac92hd95_fixup_hp_led': > > > > > sound/pci/hda/patch_sigmatel.c:4143:3: error: implicit declaration of > > > > > function 'codec_dbg' [-Werror=implicit-function-declaration] > > > > > > > > This kernel failed to build with the following error. Probably the root > > > > cause is the same as Guenter. I'm now bisecting to find the problematic > > > > patch... > > > > > > The following patch caused the boot failure of both this kernel and > > > 3.10.47-rc1. > > > > > > alsa-hda-adjust-speaker-hpf-and-add-led-support-for-hp-spectre-13.patch: > > > === > > > From 8b3dfdaf0c25a584cb31d04d2574115cf2d422ab Mon Sep 17 00:00:00 2001 > > > From: Takashi Iwai > > > Date: Tue, 24 Jun 2014 13:55:25 +0200 > > > Subject: ALSA: hda - Adjust speaker HPF and add LED support for HP > > > Spectre 13 > > > > > > From: Takashi Iwai > > > > > > commit 8b3dfdaf0c25a584cb31d04d2574115cf2d422ab upstream. > > > > > > HP Spectre 13 has the IDT 92HD95 codec, and BIOS seems to set the > > > default high-pass filter in some "safer" range, which results in the > > > very soft tone from the built-in speakers in contrast to Windows. > > > Also, the mute LED control is missing, since 92HD95 codec still has no > > > HP-specific fixups for GPIO setups. > > > > > > This patch adds these missing features: the HPF is adjusted by the > > > vendor-specific verb, and the LED is set up from a DMI string (but > > > with the default polarity = 0 assumption due to the incomplete BIOS on > > > the given machine). > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74841 > > > Signed-off-by: Takashi Iwai > > > Signed-off-by: Greg Kroah-Hartman > > > ... > > > === > > > > > > This patch uses codec_dbg(), however, this macro is intrdocuded by the > > > following patch and it's not applied to these stable-tree yet. > > > > > > === > > > ommit 4e76a8833fac8dc1735aa5be7d1b3c92c65e209e > > > Author: Takashi Iwai > > > Date: Tue Feb 25 12:21:03 2014 +0100 &g
Re: [PATCH 3.14 00/59] 3.14.11-stable review
Hi Greg, Add Takashi Iwai to this thread. At Sat, 05 Jul 2014 16:00:41 +0900, Satoru Takeuchi wrote: > > At Fri, 04 Jul 2014 22:45:42 -0700, > Guenter Roeck wrote: > > > > On 07/04/2014 03:18 PM, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 3.14.11 release. > > > There are 59 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. > > > > > > Responses should be made by Sun Jul 6 22:15:27 UTC 2014. > > > Anything received after that time might be too late. > > > > > > > Build results: > > total: 144 pass: 130 skipped: 4 fail: 10 > > Failed builds: > > alpha:allmodconfig > > i386:allyesconfig > > i386:allmodconfig > > powerpc:allmodconfig (binutils 2.23) > > powerpc:allmodconfig (binutils 2.24) > > sparc64:allmodconfig > > unicore32:defconfig > > x86_64:allyesconfig > > x86_64:allmodconfig > > xtensa:allmodconfig > > > > Qemu test for x86 failed. > > > > Build error is the same as seen with 3.14. > > > > sound/pci/hda/patch_sigmatel.c: In function 'stac92hd95_fixup_hp_led': > > sound/pci/hda/patch_sigmatel.c:4143:3: error: implicit declaration of > > function 'codec_dbg' [-Werror=implicit-function-declaration] > > This kernel failed to build with the following error. Probably the root > cause is the same as Guenter. I'm now bisecting to find the problematic > patch... The following patch caused the boot failure of both this kernel and 3.10.47-rc1. alsa-hda-adjust-speaker-hpf-and-add-led-support-for-hp-spectre-13.patch: === >From 8b3dfdaf0c25a584cb31d04d2574115cf2d422ab Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Tue, 24 Jun 2014 13:55:25 +0200 Subject: ALSA: hda - Adjust speaker HPF and add LED support for HP Spectre 13 From: Takashi Iwai commit 8b3dfdaf0c25a584cb31d04d2574115cf2d422ab upstream. HP Spectre 13 has the IDT 92HD95 codec, and BIOS seems to set the default high-pass filter in some "safer" range, which results in the very soft tone from the built-in speakers in contrast to Windows. Also, the mute LED control is missing, since 92HD95 codec still has no HP-specific fixups for GPIO setups. This patch adds these missing features: the HPF is adjusted by the vendor-specific verb, and the LED is set up from a DMI string (but with the default polarity = 0 assumption due to the incomplete BIOS on the given machine). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74841 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman ... === This patch uses codec_dbg(), however, this macro is intrdocuded by the following patch and it's not applied to these stable-tree yet. === ommit 4e76a8833fac8dc1735aa5be7d1b3c92c65e209e Author: Takashi Iwai Date: Tue Feb 25 12:21:03 2014 +0100 ALSA: hda - Replace with standard printk Use dev_err() and co for messages from HD-audio controller and codec drivers. The codec drivers are mostly bound with codec objects, so some helper macros, codec_err(), codec_info(), etc, are provided. They merely wrap the corresponding dev_xxx(). There are a few places still calling snd_printk() and its variants as they are called without the codec or device context. Signed-off-by: Takashi Iwai ... === Unfortunately I failed to apply this patch to 3.14.11-rc1 with the following error log. === $ git apply ~/src/test-linux-stable/extra_patch.txt error: patch failed: sound/pci/hda/hda_intel.c:897 error: sound/pci/hda/hda_intel.c: patch does not apply error: sound/pci/hda/hda_sysfs.c: No such file or directory === I'm not sure whether we should drop this patch or should apply extra patches to remove this build failure. Any idea? Thanks, Satoru > > === > ... > home/sat/src/test-linux-stable/linux-stable/sound/pci/hda/patch_sigmatel.c:4143:3: > error: implicit declaration of function ‘codec_dbg’ > [-Werror=implicit-function-declaration] >codec_dbg(codec, "mute LED gpio %d polarity %d\n", >^ > LD [M] sound/pci/echoaudio/snd-indigoio.o > LD [M] sound/pci/echoaudio/snd-indigodj.o > LD [M] sound/pci
Re: [PATCH 3.10 00/46] 3.10.47-stable review
At Fri, 04 Jul 2014 22:43:40 -0700, Guenter Roeck wrote: > > On 07/04/2014 03:19 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.10.47 release. > > There are 46 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. > > > > Responses should be made by Sun Jul 6 22:15:52 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 144 pass: 125 skipped: 6 fail: 13 > Failed builds: > alpha:allmodconfig > i386:defconfig > i386:allyesconfig > i386:allmodconfig > powerpc:allmodconfig (binutils 2.23) > powerpc:allmodconfig (binutils 2.24) > score:defconfig > sparc64:allmodconfig > unicore32:defconfig > x86_64:defconfig > x86_64:allyesconfig > x86_64:allmodconfig > xtensa:allmodconfig > > Qemu test for x86 failed with a build error. > > This is not as expected. New build error is always the same as far as I can > see: > > sound/pci/hda/patch_sigmatel.c: In function 'stac92hd95_fixup_hp_led': > sound/pci/hda/patch_sigmatel.c:3578:3: error: implicit declaration of > function 'codec_dbg' [-Werror=implicit-function-declaration] Failed with the following log. It's also the same as Guenter's problem. Probably both 3.14.11-rc1 and 3.10.11-rc1 hit the same problem. === ... /home/sat/src/test-linux-stable/linux-stable/sound/pci/hda/patch_sigmatel.c: In function ‘stac92hd95_fixup_hp_led’: /home/sat/src/test-linux-stable/linux-stable/sound/pci/hda/patch_sigmatel.c:3578:3: error: implicit declaration of function ‘codec_dbg’ [-Werror=implicit-function-declaration] codec_dbg(codec, "mute LED gpio %d polarity %d\n", ^ ... CC net/ipv6/icmp.o cc1: some warnings being treated as errors /home/sat/src/test-linux-stable/linux-stable/scripts/Makefile.build:308: recipe for target 'sound/pci/hda/patch_sigmatel.o' failed make[4]: *** [sound/pci/hda/patch_sigmatel.o] Error 1 /home/sat/src/test-linux-stable/linux-stable/scripts/Makefile.build:455: recipe for target 'sound/pci/hda' failed make[3]: *** [sound/pci/hda] Error 2 /home/sat/src/test-linux-stable/linux-stable/scripts/Makefile.build:455: recipe for target 'sound/pci' failed make[2]: *** [sound/pci] Error 2 /home/sat/src/test-linux-stable/linux-stable/Makefile:795: recipe for target 'sound' failed make[1]: *** [sound] Error 2 ... LD net/built-in.o Makefile:130: recipe for target 'sub-make' failed make: *** [sub-make] Error 2 FAILED! CRITICAL FAILURE... failed build === - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > Guenter > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/59] 3.14.11-stable review
At Fri, 04 Jul 2014 22:45:42 -0700, Guenter Roeck wrote: > > On 07/04/2014 03:18 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.14.11 release. > > There are 59 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. > > > > Responses should be made by Sun Jul 6 22:15:27 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 144 pass: 130 skipped: 4 fail: 10 > Failed builds: > alpha:allmodconfig > i386:allyesconfig > i386:allmodconfig > powerpc:allmodconfig (binutils 2.23) > powerpc:allmodconfig (binutils 2.24) > sparc64:allmodconfig > unicore32:defconfig > x86_64:allyesconfig > x86_64:allmodconfig > xtensa:allmodconfig > > Qemu test for x86 failed. > > Build error is the same as seen with 3.14. > > sound/pci/hda/patch_sigmatel.c: In function 'stac92hd95_fixup_hp_led': > sound/pci/hda/patch_sigmatel.c:4143:3: error: implicit declaration of > function 'codec_dbg' [-Werror=implicit-function-declaration] This kernel failed to build with the following error. Probably the root cause is the same as Guenter. I'm now bisecting to find the problematic patch... === ... home/sat/src/test-linux-stable/linux-stable/sound/pci/hda/patch_sigmatel.c:4143:3: error: implicit declaration of function ‘codec_dbg’ [-Werror=implicit-function-declaration] codec_dbg(codec, "mute LED gpio %d polarity %d\n", ^ LD [M] sound/pci/echoaudio/snd-indigoio.o LD [M] sound/pci/echoaudio/snd-indigodj.o LD [M] sound/pci/echoaudio/snd-indigoiox.o LD [M] sound/pci/echoaudio/snd-indigodjx.o CC [M] sound/pci/hda/patch_via.o LD sound/pci/ice1712/built-in.o CC [M] sound/pci/ice1712/ice1712.o cc1: some warnings being treated as errors /home/sat/src/test-linux-stable/linux-stable/scripts/Makefile.build:308: recipe for target 'sound/pci/hda/patch_sigmatel.o' failed make[4]: *** [sound/pci/hda/patch_sigmatel.o] Error 1 ... CC drivers/iommu/irq_remapping.o /home/sat/src/test-linux-stable/linux-stable/scripts/Makefile.build:455: recipe for target 'sound/pci/hda' failed make[3]: *** [sound/pci/hda] Error 2 ... /home/sat/src/test-linux-stable/linux-stable/scripts/Makefile.build:455: recipe for target 'sound/pci' failed make[2]: *** [sound/pci] Error 2 /home/sat/src/test-linux-stable/linux-stable/Makefile:841: recipe for target 'sound' failed make[1]: *** [sound] Error 2 ... Makefile:133: recipe for target 'sub-make' failed make: *** [sub-make] Error 2 FAILED! CRITICAL FAILURE... failed build ... === - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > Guenter > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 00/19] 3.4.97-stable review
At Fri, 04 Jul 2014 22:39:01 -0700, Guenter Roeck wrote: > > On 07/04/2014 03:15 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.4.97 release. > > There are 19 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. > > > > Responses should be made by Sun Jul 6 22:14:29 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 137 pass: 111 skipped: 20 fail: 6 > Failed builds: > alpha:allmodconfig > arm:spear6xx_defconfig > score:defconfig > sparc64:allmodconfig > unicore32:defconfig > xtensa:allmodconfi > > Qemu tests all passed. > > Results are as expected. > > Details are available at http://server.roeck-us.net:8010/builders. This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Satoru > > Guenter > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 00/66] 3.15.4-stable review
At Fri, 04 Jul 2014 22:48:02 -0700, Guenter Roeck wrote: > > On 07/04/2014 03:13 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.15.4 release. > > There are 66 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. > > > > Responses should be made by Sun Jul 6 22:13:57 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 144 pass: 136 skipped: 5 fail: 3 > Failed builds: > powerpc:allmodconfig (binutils 2.23) > powerpc:allmodconfig (binutils 2.24) > unicore32:defconfig > > Qemu tests all passed. > > Results are as expected. > > Details are available at http://server.roeck-us.net:8010/builders. > > On a side note, would be great if you can update the master branch > of -stable at some point. It is still at -rc2. This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Satoru > > Thanks, > Guenter > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 00/66] 3.15.4-stable review
At Fri, 04 Jul 2014 22:48:02 -0700, Guenter Roeck wrote: On 07/04/2014 03:13 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.15.4 release. There are 66 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. Responses should be made by Sun Jul 6 22:13:57 UTC 2014. Anything received after that time might be too late. Build results: total: 144 pass: 136 skipped: 5 fail: 3 Failed builds: powerpc:allmodconfig (binutils 2.23) powerpc:allmodconfig (binutils 2.24) unicore32:defconfig Qemu tests all passed. Results are as expected. Details are available at http://server.roeck-us.net:8010/builders. On a side note, would be great if you can update the master branch of -stable at some point. It is still at -rc2. This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Satoru Thanks, Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 00/19] 3.4.97-stable review
At Fri, 04 Jul 2014 22:39:01 -0700, Guenter Roeck wrote: On 07/04/2014 03:15 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.4.97 release. There are 19 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. Responses should be made by Sun Jul 6 22:14:29 UTC 2014. Anything received after that time might be too late. Build results: total: 137 pass: 111 skipped: 20 fail: 6 Failed builds: alpha:allmodconfig arm:spear6xx_defconfig score:defconfig sparc64:allmodconfig unicore32:defconfig xtensa:allmodconfi Qemu tests all passed. Results are as expected. Details are available at http://server.roeck-us.net:8010/builders. This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Satoru Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/59] 3.14.11-stable review
At Fri, 04 Jul 2014 22:45:42 -0700, Guenter Roeck wrote: On 07/04/2014 03:18 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.11 release. There are 59 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. Responses should be made by Sun Jul 6 22:15:27 UTC 2014. Anything received after that time might be too late. Build results: total: 144 pass: 130 skipped: 4 fail: 10 Failed builds: alpha:allmodconfig i386:allyesconfig i386:allmodconfig powerpc:allmodconfig (binutils 2.23) powerpc:allmodconfig (binutils 2.24) sparc64:allmodconfig unicore32:defconfig x86_64:allyesconfig x86_64:allmodconfig xtensa:allmodconfig Qemu test for x86 failed. Build error is the same as seen with 3.14. sound/pci/hda/patch_sigmatel.c: In function 'stac92hd95_fixup_hp_led': sound/pci/hda/patch_sigmatel.c:4143:3: error: implicit declaration of function 'codec_dbg' [-Werror=implicit-function-declaration] This kernel failed to build with the following error. Probably the root cause is the same as Guenter. I'm now bisecting to find the problematic patch... === ... home/sat/src/test-linux-stable/linux-stable/sound/pci/hda/patch_sigmatel.c:4143:3: error: implicit declaration of function ‘codec_dbg’ [-Werror=implicit-function-declaration] codec_dbg(codec, mute LED gpio %d polarity %d\n, ^ LD [M] sound/pci/echoaudio/snd-indigoio.o LD [M] sound/pci/echoaudio/snd-indigodj.o LD [M] sound/pci/echoaudio/snd-indigoiox.o LD [M] sound/pci/echoaudio/snd-indigodjx.o CC [M] sound/pci/hda/patch_via.o LD sound/pci/ice1712/built-in.o CC [M] sound/pci/ice1712/ice1712.o cc1: some warnings being treated as errors /home/sat/src/test-linux-stable/linux-stable/scripts/Makefile.build:308: recipe for target 'sound/pci/hda/patch_sigmatel.o' failed make[4]: *** [sound/pci/hda/patch_sigmatel.o] Error 1 ... CC drivers/iommu/irq_remapping.o /home/sat/src/test-linux-stable/linux-stable/scripts/Makefile.build:455: recipe for target 'sound/pci/hda' failed make[3]: *** [sound/pci/hda] Error 2 ... /home/sat/src/test-linux-stable/linux-stable/scripts/Makefile.build:455: recipe for target 'sound/pci' failed make[2]: *** [sound/pci] Error 2 /home/sat/src/test-linux-stable/linux-stable/Makefile:841: recipe for target 'sound' failed make[1]: *** [sound] Error 2 ... Makefile:133: recipe for target 'sub-make' failed make: *** [sub-make] Error 2 FAILED! CRITICAL FAILURE... failed build ... === - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 00/46] 3.10.47-stable review
At Fri, 04 Jul 2014 22:43:40 -0700, Guenter Roeck wrote: On 07/04/2014 03:19 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.47 release. There are 46 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. Responses should be made by Sun Jul 6 22:15:52 UTC 2014. Anything received after that time might be too late. Build results: total: 144 pass: 125 skipped: 6 fail: 13 Failed builds: alpha:allmodconfig i386:defconfig i386:allyesconfig i386:allmodconfig powerpc:allmodconfig (binutils 2.23) powerpc:allmodconfig (binutils 2.24) score:defconfig sparc64:allmodconfig unicore32:defconfig x86_64:defconfig x86_64:allyesconfig x86_64:allmodconfig xtensa:allmodconfig Qemu test for x86 failed with a build error. This is not as expected. New build error is always the same as far as I can see: sound/pci/hda/patch_sigmatel.c: In function 'stac92hd95_fixup_hp_led': sound/pci/hda/patch_sigmatel.c:3578:3: error: implicit declaration of function 'codec_dbg' [-Werror=implicit-function-declaration] Failed with the following log. It's also the same as Guenter's problem. Probably both 3.14.11-rc1 and 3.10.11-rc1 hit the same problem. === ... /home/sat/src/test-linux-stable/linux-stable/sound/pci/hda/patch_sigmatel.c: In function ‘stac92hd95_fixup_hp_led’: /home/sat/src/test-linux-stable/linux-stable/sound/pci/hda/patch_sigmatel.c:3578:3: error: implicit declaration of function ‘codec_dbg’ [-Werror=implicit-function-declaration] codec_dbg(codec, mute LED gpio %d polarity %d\n, ^ ... CC net/ipv6/icmp.o cc1: some warnings being treated as errors /home/sat/src/test-linux-stable/linux-stable/scripts/Makefile.build:308: recipe for target 'sound/pci/hda/patch_sigmatel.o' failed make[4]: *** [sound/pci/hda/patch_sigmatel.o] Error 1 /home/sat/src/test-linux-stable/linux-stable/scripts/Makefile.build:455: recipe for target 'sound/pci/hda' failed make[3]: *** [sound/pci/hda] Error 2 /home/sat/src/test-linux-stable/linux-stable/scripts/Makefile.build:455: recipe for target 'sound/pci' failed make[2]: *** [sound/pci] Error 2 /home/sat/src/test-linux-stable/linux-stable/Makefile:795: recipe for target 'sound' failed make[1]: *** [sound] Error 2 ... LD net/built-in.o Makefile:130: recipe for target 'sub-make' failed make: *** [sub-make] Error 2 FAILED! CRITICAL FAILURE... failed build === - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/version-test datetime.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/59] 3.14.11-stable review
Hi Greg, Add Takashi Iwai to this thread. At Sat, 05 Jul 2014 16:00:41 +0900, Satoru Takeuchi wrote: At Fri, 04 Jul 2014 22:45:42 -0700, Guenter Roeck wrote: On 07/04/2014 03:18 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.11 release. There are 59 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. Responses should be made by Sun Jul 6 22:15:27 UTC 2014. Anything received after that time might be too late. Build results: total: 144 pass: 130 skipped: 4 fail: 10 Failed builds: alpha:allmodconfig i386:allyesconfig i386:allmodconfig powerpc:allmodconfig (binutils 2.23) powerpc:allmodconfig (binutils 2.24) sparc64:allmodconfig unicore32:defconfig x86_64:allyesconfig x86_64:allmodconfig xtensa:allmodconfig Qemu test for x86 failed. Build error is the same as seen with 3.14. sound/pci/hda/patch_sigmatel.c: In function 'stac92hd95_fixup_hp_led': sound/pci/hda/patch_sigmatel.c:4143:3: error: implicit declaration of function 'codec_dbg' [-Werror=implicit-function-declaration] This kernel failed to build with the following error. Probably the root cause is the same as Guenter. I'm now bisecting to find the problematic patch... The following patch caused the boot failure of both this kernel and 3.10.47-rc1. alsa-hda-adjust-speaker-hpf-and-add-led-support-for-hp-spectre-13.patch: === From 8b3dfdaf0c25a584cb31d04d2574115cf2d422ab Mon Sep 17 00:00:00 2001 From: Takashi Iwai ti...@suse.de Date: Tue, 24 Jun 2014 13:55:25 +0200 Subject: ALSA: hda - Adjust speaker HPF and add LED support for HP Spectre 13 From: Takashi Iwai ti...@suse.de commit 8b3dfdaf0c25a584cb31d04d2574115cf2d422ab upstream. HP Spectre 13 has the IDT 92HD95 codec, and BIOS seems to set the default high-pass filter in some safer range, which results in the very soft tone from the built-in speakers in contrast to Windows. Also, the mute LED control is missing, since 92HD95 codec still has no HP-specific fixups for GPIO setups. This patch adds these missing features: the HPF is adjusted by the vendor-specific verb, and the LED is set up from a DMI string (but with the default polarity = 0 assumption due to the incomplete BIOS on the given machine). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74841 Signed-off-by: Takashi Iwai ti...@suse.de Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org ... === This patch uses codec_dbg(), however, this macro is intrdocuded by the following patch and it's not applied to these stable-tree yet. === ommit 4e76a8833fac8dc1735aa5be7d1b3c92c65e209e Author: Takashi Iwai ti...@suse.de Date: Tue Feb 25 12:21:03 2014 +0100 ALSA: hda - Replace with standard printk Use dev_err() and co for messages from HD-audio controller and codec drivers. The codec drivers are mostly bound with codec objects, so some helper macros, codec_err(), codec_info(), etc, are provided. They merely wrap the corresponding dev_xxx(). There are a few places still calling snd_printk() and its variants as they are called without the codec or device context. Signed-off-by: Takashi Iwai ti...@suse.de ... === Unfortunately I failed to apply this patch to 3.14.11-rc1 with the following error log. === $ git apply ~/src/test-linux-stable/extra_patch.txt error: patch failed: sound/pci/hda/hda_intel.c:897 error: sound/pci/hda/hda_intel.c: patch does not apply error: sound/pci/hda/hda_sysfs.c: No such file or directory === I'm not sure whether we should drop this patch or should apply extra patches to remove this build failure. Any idea? Thanks, Satoru === ... home/sat/src/test-linux-stable/linux-stable/sound/pci/hda/patch_sigmatel.c:4143:3: error: implicit declaration of function ‘codec_dbg’ [-Werror=implicit-function-declaration] codec_dbg(codec, mute LED gpio %d polarity %d\n, ^ LD [M] sound/pci/echoaudio/snd-indigoio.o LD [M] sound/pci/echoaudio/snd-indigodj.o LD [M] sound/pci/echoaudio/snd-indigoiox.o LD [M] sound/pci/echoaudio/snd-indigodjx.o CC [M] sound/pci/hda/patch_via.o LD sound/pci/ice1712/built-in.o CC [M] sound/pci/ice1712/ice1712.o cc1: some warnings being treated as errors /home/sat/src/test-linux-stable/linux-stable/scripts/Makefile.build:308
Re: [PATCH 3.14 00/59] 3.14.11-stable review
At Sat, 5 Jul 2014 12:10:58 -0700, Greg Kroah-Hartman wrote: On Sat, Jul 05, 2014 at 02:56:55PM +0200, Takashi Iwai wrote: At Sat, 05 Jul 2014 18:21:04 +0900, Satoru Takeuchi wrote: Hi Greg, Add Takashi Iwai to this thread. At Sat, 05 Jul 2014 16:00:41 +0900, Satoru Takeuchi wrote: At Fri, 04 Jul 2014 22:45:42 -0700, Guenter Roeck wrote: On 07/04/2014 03:18 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.11 release. There are 59 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. Responses should be made by Sun Jul 6 22:15:27 UTC 2014. Anything received after that time might be too late. Build results: total: 144 pass: 130 skipped: 4 fail: 10 Failed builds: alpha:allmodconfig i386:allyesconfig i386:allmodconfig powerpc:allmodconfig (binutils 2.23) powerpc:allmodconfig (binutils 2.24) sparc64:allmodconfig unicore32:defconfig x86_64:allyesconfig x86_64:allmodconfig xtensa:allmodconfig Qemu test for x86 failed. Build error is the same as seen with 3.14. sound/pci/hda/patch_sigmatel.c: In function 'stac92hd95_fixup_hp_led': sound/pci/hda/patch_sigmatel.c:4143:3: error: implicit declaration of function 'codec_dbg' [-Werror=implicit-function-declaration] This kernel failed to build with the following error. Probably the root cause is the same as Guenter. I'm now bisecting to find the problematic patch... The following patch caused the boot failure of both this kernel and 3.10.47-rc1. alsa-hda-adjust-speaker-hpf-and-add-led-support-for-hp-spectre-13.patch: === From 8b3dfdaf0c25a584cb31d04d2574115cf2d422ab Mon Sep 17 00:00:00 2001 From: Takashi Iwai ti...@suse.de Date: Tue, 24 Jun 2014 13:55:25 +0200 Subject: ALSA: hda - Adjust speaker HPF and add LED support for HP Spectre 13 From: Takashi Iwai ti...@suse.de commit 8b3dfdaf0c25a584cb31d04d2574115cf2d422ab upstream. HP Spectre 13 has the IDT 92HD95 codec, and BIOS seems to set the default high-pass filter in some safer range, which results in the very soft tone from the built-in speakers in contrast to Windows. Also, the mute LED control is missing, since 92HD95 codec still has no HP-specific fixups for GPIO setups. This patch adds these missing features: the HPF is adjusted by the vendor-specific verb, and the LED is set up from a DMI string (but with the default polarity = 0 assumption due to the incomplete BIOS on the given machine). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74841 Signed-off-by: Takashi Iwai ti...@suse.de Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org ... === This patch uses codec_dbg(), however, this macro is intrdocuded by the following patch and it's not applied to these stable-tree yet. === ommit 4e76a8833fac8dc1735aa5be7d1b3c92c65e209e Author: Takashi Iwai ti...@suse.de Date: Tue Feb 25 12:21:03 2014 +0100 ALSA: hda - Replace with standard printk Use dev_err() and co for messages from HD-audio controller and codec drivers. The codec drivers are mostly bound with codec objects, so some helper macros, codec_err(), codec_info(), etc, are provided. They merely wrap the corresponding dev_xxx(). There are a few places still calling snd_printk() and its variants as they are called without the codec or device context. Signed-off-by: Takashi Iwai ti...@suse.de ... === Unfortunately I failed to apply this patch to 3.14.11-rc1 with the following error log. === $ git apply ~/src/test-linux-stable/extra_patch.txt error: patch failed: sound/pci/hda/hda_intel.c:897 error: sound/pci/hda/hda_intel.c: patch does not apply error: sound/pci/hda/hda_sysfs.c: No such file or directory === I'm not sure whether we should drop this patch or should apply extra patches to remove this build failure. Any idea? Just drop the patch from 3.14 and earlier stable kernels. If anyone wants to use the laptop, they should use 3.15.x or later kernel. The second patch cannot be used
Re: [PATCH 1/1] FS/BTRFS: replace count*size kzalloc by kcalloc
(2014/07/02 9:01), David Sterba wrote: On Wed, Jun 25, 2014 at 08:35:43PM +0200, Fabian Frederick wrote: kcalloc manages count*sizeof overflow. Cc: Chris Mason Cc: Josef Bacik Cc: linux-bt...@vger.kernel.org Signed-off-by: Fabian Frederick Reviewed-by: David Sterba Reviewed-by: Satoru Takeuchi -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 000/181] 3.12.24-stable review
At Mon, 30 Jun 2014 13:51:22 +0200, Jiri Slaby wrote: > > This is the start of the stable review cycle for the 3.12.24 release. > There are 181 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. > > Responses should be made by Wed Jul 2 11:49:58 2014 > Anything received after that time might be too late. This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
