first attempt at Evergreen 13.1 kernel

[Michal Kubecek]

Hello,

13.1 is still going to be supported for quite some time before it goes
into the Evergreen phase but I believe the kernel switch deserves some
time for testing. Thus I prepared a (SLE12 based) 3.12 kernel for
Evergreen in a similar way to the (SLE11-SP2 based) 3.0 kernel used in
Evergreen 11.4.

So far it's almost untested except that it builds and booted and has
been running on one machine for 11 hours. Everyone adventurous enough is
welcome to help with testing. The packages are available in

home:mkubecek:evergreen-13.1

OBS project, repository URL (for zypper) is

http://download.opensuse.org/repositories/home:/mkubecek:/evergreen-13.1/openSUSE_13.1/

The project and its repository also contain other packages providing
kernel modules. The only exception is i586 build of xen package as the
kernel doesn't provide 32-bit hypervisor; hopefully it's not going to be
a big problem.

Diff of the configurations is attached (left column is standard 13.1
kernel, right column the evergreen one). Except the missing i586
hypervisor code, the only potential problem is the change of
CONFIG_XEN_INTERFACE_VERSION, I'm going to look more into that.

I still have to check the full list of available modules.

Michal Kubeèek

[Carlos E. R.]

On 2014-09-07 22:07, Michal Kubecek wrote:

I think that your post did not reach the Evergreen mail list, so I
resend it complete to that list (on another post).

Post by Michal Kubecek
I still have to check the full list of available modules.

I have a question: why some modules are changed to... how do you call
it, in core, not module? Ie, 'y' instead of 'm'?

Not important, just curious.

- --
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 "Bottle" at Telcontar)

[Felix Miata]

Post by Carlos E. R.
I think that your post did not reach the Evergreen mail list, so I
resend it complete to that list (on another post).

I bet it shows up eventually. Evergreen posts usually show up here only after
significant delay.

[Michal Kubecek]

Post by Carlos E. R.
I think that your post did not reach the Evergreen mail list, so I
resend it complete to that list (on another post).

Yes, I forgot that I'm subscribed to Evergreen list only from my private
address, not the suse.cz one. So the message is waiting for moderator
approval. I subscribed from this address now so this mail should pass
normally.

Post by Carlos E. R.

Post by Michal Kubecek
I still have to check the full list of available modules.

I have a question: why some modules are changed to... how do you call
it, in core, not module? Ie, 'y' instead of 'm'?

It was changed by "make oldconfig" which is usually caused by some
change in dependencies. For example, change of CONFIG_CRYPTO_SHA1 was
probably caused by mainline commit f8eb8a132 ("apparmor: add the ability
to report a sha1 hash of loaded policy") and CONFIG_ZLIB_DEFLATE by
mainline commit 90ce4ca66 ("pstore/Kconfig: Select ZLIB_DEFLATE and
ZLIB_INFLATE where PSTORE is selected").

Michal Kubeček

[Carlos E. R.]

Post by Michal Kubecek

Post by Carlos E. R.
I have a question: why some modules are changed to... how do you
call it, in core, not module? Ie, 'y' instead of 'm'?

It was changed by "make oldconfig" which is usually caused by some
change in dependencies. For example, change of CONFIG_CRYPTO_SHA1
was probably caused by mainline commit f8eb8a132 ("apparmor: add
the ability to report a sha1 hash of loaded policy") and
Select ZLIB_DEFLATE and ZLIB_INFLATE where PSTORE is selected").

Ah, I see. Thanks. :-)

- --
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 "Bottle" at Telcontar)

[Felix Miata]

Post by Michal Kubecek
13.1 is still going to be supported for quite some time before it goes
into the Evergreen phase but I believe the kernel switch deserves some
time for testing. Thus I prepared a (SLE12 based) 3.12 kernel for
Evergreen in a similar way to the (SLE11-SP2 based) 3.0 kernel used in
Evergreen 11.4.
So far it's almost untested except that it builds and booted and has
been running on one machine for 11 hours. Everyone adventurous enough is
welcome to help with testing. The packages are available in
home:mkubecek:evergreen-13.1
OBS project, repository URL (for zypper) is
http://download.opensuse.org/repositories/home:/mkubecek:/evergreen-13.1/openSUSE_13.1/

Was 32 bit kernel-desktop i586 instead of its 13.1 normal i686 intentional?
http://download.opensuse.org/update/13.1/i586/kernel-default-3.11.10-21.1.i586.rpm
http://download.opensuse.org/update/13.1/i686/kernel-desktop-3.11.10-21.1.i686.rpm

(Again, I've forgotten how to determine what CPU characteristics dictate use
of i586 instead of the i686 distro installer default, and what to Google for
to find out. :-p )

Other than above, and being newer builds than what he has there now, have
yours any material difference from Jiri's 3.12s he offered us since 11 weeks
ago? I've been running those on nearly all my 13.1 installations since the
week following his announcement:
http://lists.opensuse.org/opensuse-kernel/2014-06/msg00089.html

[Michal Kubecek]

Post by Felix Miata
Was 32 bit kernel-desktop i586 instead of its 13.1 normal i686
intentional?
http://download.opensuse.org/update/13.1/i586/kernel-default-3.11.10-
21.1.i586.rpm
http://download.opensuse.org/update/13.1/i686/kernel-desktop-3.11.10-
21.1.i686.rpm

It's not intentional. There is probably some difference either in the
(generated) specfile or in project/package metadata. I'm going to look
into it.

Post by Felix Miata
Other than above, and being newer builds than what he has there now,
have yours any material difference from Jiri's 3.12s he offered us
since 11 weeks ago? I've been running those on nearly all my 13.1
http://lists.opensuse.org/opensuse-kernel/2014-06/msg00089.html

As far as I can see, Jiri's packages are based on stable-3.12.y:

https://git.kernel.org/cgit/linux/kernel/git/jirislaby/linux-stable.git/

while mine are based on SLE12 sources:

http://kernel.opensuse.org/branches/SLE12

I believe the latter would be easier to maintain but I'm open to
discussion.

Michal Kubeček

[Michal Kubecek]

Post by Felix Miata
Was 32 bit kernel-desktop i586 instead of its 13.1 normal i686
intentional?
http://download.opensuse.org/update/13.1/i586/kernel-default-3.11.10-> 21.1.i586.rpm
http://download.opensuse.org/update/13.1/i686/kernel-desktop-3.11.10-> 21.1.i686.rpm

New version from yesterday (3.12.28-3) has the same architectures as
standard 13.1 kernel (i586 for -default, i686 for all other flavors).

Michal Kubeček

[Felix Miata]

Post by Michal Kubecek

Post by Felix Miata
Was 32 bit kernel-desktop i586 instead of its 13.1 normal i686 intentional?
http://download.opensuse.org/update/13.1/i586/kernel-default-3.11.10-> 21.1.i586.rpm
http://download.opensuse.org/update/13.1/i686/kernel-desktop-3.11.10-> 21.1.i686.rpm

New version from yesterday (3.12.28-3) has the same architectures as
standard 13.1 kernel (i586 for -default, i686 for all other flavors).

Linux g5eas 3.12.28-3-desktop #1 SMP PREEMPT Sun Sep 21 17:17:58 UTC 2014 (2250e86) x86_64 x86_64 x86_64 GNU/Linux

Anything here that looks wrong?
[ 35.802111] FS-Cache: Netfs 'nfs' registered for caching
[ 37.121689] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
[ 37.130869] NFSD: starting 90-second grace period (net ffffffff81c8e840)
[ 39.408387] systemd-journald[223]: Received request to flush runtime journal from PID 1
[ 60.868667] type=1006 audit(1411682170.260:2): pid=1180 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=1 res=1
[ 66.624822] NFS: Registering the id_resolver key type
[ 66.624850] Key type id_resolver registered
[ 66.624855] Key type id_legacy registered
[ 118.444549] Uhhuh. NMI received for unknown reason 21 on CPU 0.
[ 118.444549] Do you have a strange power saving mode enabled?
[ 118.444549] Dazed and confused, but trying to continue

I dont' remember seeing anything like this tail with Jiri's 3.12 or original kernel.

processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Pentium(R) 4 CPU 3.20GHz
stepping : 5
cpu MHz : 1200.000
(single core, Hyper-Threading)

Z7/Z9 (XG20 core) gfxchip (non-KMS)

P.S.
# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

[Petr Mladek]

Post by Felix Miata

Post by Michal Kubecek

Post by Felix Miata
Was 32 bit kernel-desktop i586 instead of its 13.1 normal i686 intentional?
http://download.opensuse.org/update/13.1/i586/kernel-default-3.11.10-> 21.1.i586.rpm
http://download.opensuse.org/update/13.1/i686/kernel-desktop-3.11.10-> 21.1.i686.rpm

New version from yesterday (3.12.28-3) has the same architectures as
standard 13.1 kernel (i586 for -default, i686 for all other flavors).

Linux g5eas 3.12.28-3-desktop #1 SMP PREEMPT Sun Sep 21 17:17:58 UTC 2014 (2250e86) x86_64 x86_64 x86_64 GNU/Linux
Anything here that looks wrong?
[ 35.802111] FS-Cache: Netfs 'nfs' registered for caching
[ 37.121689] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
[ 37.130869] NFSD: starting 90-second grace period (net ffffffff81c8e840)
[ 39.408387] systemd-journald[223]: Received request to flush runtime journal from PID 1
[ 60.868667] type=1006 audit(1411682170.260:2): pid=1180 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=1 res=1
[ 66.624822] NFS: Registering the id_resolver key type
[ 66.624850] Key type id_resolver registered
[ 66.624855] Key type id_legacy registered
[ 118.444549] Uhhuh. NMI received for unknown reason 21 on CPU 0.
[ 118.444549] Do you have a strange power saving mode enabled?
[ 118.444549] Dazed and confused, but trying to continue

IMHO, this might happen for example when there is handled IPMI during
NMI.

You might check if there is anything suspicious in ipmi log. You need
to install "ipmitool" package and do as root:

modprobe ipmi_devintf
modprobe ipmi_si
ipmitool sel list


Also could you please paste more from dmesg, even after this warning?
The message from NMI handler is printed long after the previous
line. It is related to some event that is still in progress. If
the event fails, the related error would be later in the log.

Just to be sure. Is this reproducible? It might also be a nearly
impossible race. In this case, it might be unrelated to the kernel update.

Best Regards,
Petr