September 2013 - openSUSE Kernel - openSUSE Mailing Lists

[opensuse-kernel] aacraid driver crash when it shouldn't
by Bruno Friedmann 15 Sep '13

15 Sep '13

Hi there, I'm facing an issue with 3.11 coming from our kernel-stable repos A intel motherboard + i7 3770 32Gb ram with an adaptec 6805 adapter. (8 intel ssd 510 series 120 go attached in a raid6 array) The bundle adaptec + ssd in raid6 has worked during months (with openSUSE 12.1) without any glitches. Now this night we received that kind of error Sep 15 02:06:52 clochette.disney.interne kernel: aacraid: Host adapter abort request (6,0,0,0) Sep 15 02:06:52 clochette.disney.interne kernel: aacraid: Host adapter abort request (6,0,0,0) Sep 15 02:06:52 clochette.disney.interne kernel: aacraid: Host adapter reset request. SCSI hang ? Sep 15 02:07:07 clochette.disney.interne kernel: sd 6:0:0:0: [sde] Medium access timeout failure. Offlining disk! Sep 15 02:07:07 clochette.disney.interne kernel: sd 6:0:0:0: Device offlined - not ready after error recovery Sep 15 02:07:07 clochette.disney.interne kernel: sd 6:0:0:0: Device offlined - not ready after error recovery Sep 15 02:07:07 clochette.disney.interne kernel: sd 6:0:0:0: [sde] Unhandled error code Sep 15 02:07:07 clochette.disney.interne kernel: sd 6:0:0:0: [sde] Sep 15 02:07:07 clochette.disney.interne kernel: Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK Sep 15 02:07:07 clochette.disney.interne kernel: sd 6:0:0:0: [sde] CDB: Sep 15 02:07:07 clochette.disney.interne kernel: Write(10): 2a 00 02 b7 f4 00 00 00 20 00 Sep 15 02:07:07 clochette.disney.interne kernel: end_request: I/O error, dev sde, sector 45609984 Sep 15 02:07:07 clochette.disney.interne kernel: Buffer I/O error on device dm-4, logical block 5252224 Sep 15 02:07:07 clochette.disney.interne kernel: lost page write due to I/O error on dm-4 Sep 15 02:07:07 clochette.disney.interne kernel: Buffer I/O error on device dm-4, logical block 5252225 Sep 15 02:07:07 clochette.disney.interne kernel: lost page write due to I/O error on dm-4 Sep 15 02:07:07 clochette.disney.interne kernel: Buffer I/O error on device dm-4, logical block 5252226 Sep 15 02:07:07 clochette.disney.interne kernel: lost page write due to I/O error on dm-4 Sep 15 02:07:07 clochette.disney.interne kernel: Buffer I/O error on device dm-4, logical block 5252227 Sep 15 02:07:07 clochette.disney.interne kernel: lost page write due to I/O error on dm-4 Sep 15 02:07:07 clochette.disney.interne kernel: sd 6:0:0:0: [sde] Unhandled error code Sep 15 02:07:07 clochette.disney.interne kernel: sd 6:0:0:0: [sde] Sep 15 02:07:07 clochette.disney.interne kernel: Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT Sep 15 02:07:07 clochette.disney.interne kernel: sd 6:0:0:0: [sde] CDB: Sep 15 02:07:07 clochette.disney.interne kernel: Write(10): 2a 00 31 3e f6 20 00 00 08 00 Sep 15 02:07:07 clochette.disney.interne kernel: end_request: I/O error, dev sde, sector 826209824 Sep 15 02:07:07 clochette.disney.interne kernel: Buffer I/O error on device dm-3, logical block 853188 Sep 15 02:07:07 clochette.disney.interne kernel: lost page write due to I/O error on dm-3 Sep 15 02:07:07 clochette.disney.interne kernel: sd 6:0:0:0: rejecting I/O to offline device Sep 15 02:07:07 clochette.disney.interne kernel: Buffer I/O error on device dm-3, logical block 2981929 Sep 15 02:07:07 clochette.disney.interne kernel: sd 6:0:0:0: rejecting I/O to offline device Sep 15 02:07:07 clochette.disney.interne kernel: sd 6:0:0:0: rejecting I/O to offline device Sep 15 02:07:07 clochette.disney.interne kernel: Buffer I/O error on device dm-3, logical block 2981929 Sep 15 02:07:07 clochette.disney.interne kernel: sd 6:0:0:0: rejecting I/O to offline device Sep 15 02:07:07 clochette.disney.interne kernel: Buffer I/O error on device dm-3, logical block 45451 Sep 15 02:07:07 clochette.disney.interne kernel: lost page write due to I/O error on dm-3 Sep 15 02:07:07 clochette.disney.interne kernel: sd 6:0:0:0: rejecting I/O to offline device Sep 15 02:07:07 clochette.disney.interne kernel: Buffer I/O error on device dm-3, logical block 785908 Sep 15 02:07:07 clochette.disney.interne kernel: lost page write due to I/O error on dm-3 Sep 15 02:07:07 clochette.disney.interne kernel: sd 6:0:0:0: rejecting I/O to offline device Sep 15 02:07:07 clochette.disney.interne kernel: Buffer I/O error on device dm-3, logical block 810442 Sep 15 02:07:07 clochette.disney.interne kernel: lost page write due to I/O error on dm-3 Sep 15 02:07:07 clochette.disney.interne kernel: sd 6:0:0:0: rejecting I/O to offline device But after checking kernel changelog I've found this commit for 3.10 series which should have fix it? Author: Mahesh Rajashekhara <Mahesh.Rajashekhara@XXXXX> Date: Tue Jun 18 17:02:07 2013 +0530 SCSI: aacraid: Fix for arrays are going offline in the system. System hangs commit c5bebd829dd95602c15f8da8cc50fa938b5e0254 upstream. One of the customer had reported that the set of raid logical arrays will become unavailable (I/O offline) after a long hours of IO stress test. The OS wouldn`t be accessible afterwards and require a hard reset. This driver patch has a fix for race condition between the doorbell and the circular buffer. The driver is modified to do an extra read after clearing the doorbell in case there had been a completion posted during the small timing window. With this fix, we ran IO stress for ~13 days. There were no IO failures. Signed-off-by: Mahesh Rajashekhara <Mahesh.Rajashekhara@XXXX> Signed-off-by: James Bottomley <JBottomley@XXXX> Signed-off-by: Greg Kroah-Hartman <gregkh@XXXXX> Then it's hard to find what's going wrong ? Should the firmware being downgraded to previous rev 19076 as it was before the mainboard change and openSUSE 12.3 installation ? On this Raid6 we have a LVM group which contain virtuals machines who were running with a consequent load (oracle dumps) running from 1.5 to 2 hours. Thanks for any pointer, or feedback I can provide more information if needed. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member GPG KEY : D5C9B751C4653227 irc: tigerfoot

1 1

[opensuse-kernel] BtrFS as default fs?
by Jeff Mahoney 12 Sep '13

12 Sep '13

Hi all - Last month I posted queries to this list (and several other locations, including the forums) asking about people's experiences with btrfs. For the most part it seemed like the experience had improved over time. Most of the concerns were either with interactions with zypper or old perceptions of instability that were based more on old impressions than new testing. With the exception of an ENOSPC issue that had been recently fixed, users actively using the file system seemed pretty satisfied with it. I posted a followup question a week or two later asking what people thought about limiting the 'supported' feature set in the way we do in SLES so that it's clear to all users which parts of the file system are considered stable. A quick table of what that looks like: Supported Unsupported --------- ----------- Snapshots Inode cache Copy-on-Write Auto Defrag Subvolumes RAID Metadata Integrity Compression Data Integrity Send / Receive Online metadata scrubbing Hot add/remove Manual defrag Seeding devices Manual deduplication (soon) Multiple devices "Big" Metadata (supported read-only) Over time this table will change. Items from the Unsupported list will move to the Supported list as they mature. That proposal was pretty well received except, predictably, by those using the features listed. In practice, all that's required for those users to continue uninterrupted is to add the 'allow_unsupported=1' option to the btrfs module either on the kernel command line or /etc/modprobe.d. There is nothing inherently limiting to any openSUSE user with this practice. The features are all still in the code and available immediately just by setting a flag. It can even be done safely after module load or even after file systems that don't use the unsupported features have been mounted. I intend to introduce this functionality into openSUSE soon. One other aspect to consider: Even though they are independent projects, we've been focusing heavily on btrfs support in the SLES product. As a result, the openSUSE kernel will end up getting much of that work 'for free' since most of the same people maintain the kernel for both projects. So that's the "why it's safe" part of the proposal. I haven't gotten to the "why" yet, but then you probably already know the "whys". Subvolumes. Built-in snapshots that don't corrupt themselves when an exception table runs out of space. Built-in integrity verification via checksums. Built-in proactive metadata semantic checking via scrubbing. Online defrag. Soon we'll see online deduplication of arbitrary combinations of files. The code is written, it just needs to be pulled in. You've seen the rest of the feature set. Once we test more of it under load and ensure that it's mature enough to roll out, you'll get those features for free. So, I'd like to propose that we use btrfs as the default file system for the 13.1 release before we release the first beta. Thanks for your time. -Jeff -- Jeff Mahoney SUSE Labs

16 30

[opensuse-kernel] Update of Kernel:openSUSE-12.2
by Eugene Istomin 10 Sep '13

10 Sep '13

Hello, can you update OpenSUSE 12.2 kernels ( 3.4 LTS branch , https://build.opensuse.org/project/show/Kernel:openSUSE-12.2) to 3.4.60/3.4.61? Thanks. -- Best regards, Eugene Istomin -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 1

[opensuse-kernel] Re: openSUSE Build Service - Kernel
by Michal Marek 06 Sep '13

06 Sep '13

On 6.9.2013 10:55, Eugene Istomin wrote: > Hello sirs, > > > > can you update OpenSUSE 12.2 kernels ( 3.4 LTS branch , > https://build.opensuse.org/project/show/Kernel:openSUSE-12.2) to 3.4.60? Hi Eugene, such requests are best directed to the opensuse-kernel(a)opensuse.org mailing list. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

1 0

[opensuse-kernel] [RFC PATCH 00/18 v3] Signature verification of hibernate snapshot
by Lee, Chun-Yi 05 Sep '13

05 Sep '13

Hi experts, This patchset is the implementation for signature verification of hibernate snapshot image. The origin idea is from Jiri Kosina: Let EFI bootloader generate key-pair in UEFI secure boot environment, then pass it to kernel for sign/verify S4 image. Due to there have potential threat from the S4 image hacked, it may causes kernel lost the trust in UEFI secure boot. Hacker attack the S4 snapshot image in swap partition through whatever exploit from another trusted OS, and the exploit may don't need physical access machine. So, this patchset give the ability to kernel for parsing the RSA private key from EFI bootloader, then using the private key to generate the signature of S4 snapshot image. Kernel put the signature to snapshot header, and verify the signature when kernel try to recover snapshot image to memory. ============== How To Enable ============== Set enable the CONFIG_SNAPSHOT_VERIFICATION kernel config. And you can also choice which hash algorithm should snapshot be signed with. Then rebuild kernel. Please note this function need UEFI bootloader's support to generate key-pair in UEFI secure boot environment, e.g. shim. Current shim implementation by Gary Lin: Git: https://github.com/lcp/shim/tree/s4-key-upstream RPM: https://build.opensuse.org/package/show/home:gary_lin:UEFI/shim Please use the shim from above URL if you want to try. Please remember add the hash of shim to db in UEFI BIOS because it didn't sign by Microsoft or any OSV key. ========= Behavior ========= The RSA key-pair are generated by EFI bootloader(e.g. shim) in UEFI secure boot environment, so this function binding with EFI secure boot enabled. The kernel behavior is: + UEFI Secure Boot ON. Kernel found private key from shim: Kernel will run the signature check when S4. + UEFI Secure Boot ON. Kernel didn't find key from shim: Kernel will lock down S4 function. + UEFI Secure Boot OFF Kernel will disable S4 signature check, and ignore any keys from EFI bootloader. Unconditional allow hibernate launch. On EFI bootloader side, the behavior as following: + First, kernel will check the following 2 EFI variable: S4SignKey-fe141863-c070-478e-b8a3-878a5dc9ef21 [BootService] S4WakeKey-fe141863-c070-478e-b8a3-878a5dc9ef21 [Runtime][Volatile] S4SignKey and S4WakeKey is a RSA key-pair: - S4SignKey is a private key that's used to generate signature of S4 snapshot. The blob format of S4SignKey is PKCS#8 uncompressed format, it should packaged a RSA private key that's followed PKCS#1. - S4WakeKey is a public key that's used to verify signature of S4 snapshot. The blob format of S4WakeKey is X.509 format, it should packaged a RSA public key that's followed PKCS#1. + EFI bootloader must generate RSA key-pair when system boot: - Bootloader store the public key to EFI boottime variable by itself - Bootloader put The private key to S4SignKey EFI variable for forward to kernel. + EFI stub kernel will load the S4SignKey blob to RAM before ExitBootServices, then copy to a memory page to maintain by hibernate_key.c. This private key will used to sign snapshot when S4. + When machine resume from hibernate: - EFI bootloader should copy the public key from boottime variable to S4WakeKey EFI variable. - Bootloader need generates a new key-pair for next round S4 usage. It should put new private key to S4SignKey variable. + EFI bootlaoder need check the following EFI runtime variable for regenerate new key-pair: GenS4Key-fe141863-c070-478e-b8a3-878a5dc9ef21 The size of GenS4Key is 1 byte, OS(kernel or userland tool) will set it to "1" for notify efi bootloader regenerate key-pair. ============== Implementation ============== Whole implementation including 3 parts: shim, asymmetric keys and hibernate: + shim: Current solution implemented by Gary Lin: https://github.com/lcp/shim/tree/s4-key-upstream Please use shim from the above URL if you want to try. Please remember add this shim to db because it didn't sign by Microsoft or any OSV key. + Asymmetric keys: This patchset implemented uncompressed PKCS#8 and RSA private key parser, it also implement the signature generation operation of RSASSA-PKCS1-v_5 in PKCS#1 spec. [RFC3447 sec 8.2.2] Set CONFIG_PKCS8_PRIVATE_KEY_INFO_PARSER=y will give kernel the abilities to parsing private key in uncompressed PKCS#8 blob and generate signature. + Hibernate: Set CONFIG_SNAPSHOT_VERIFICATION=y will enable the function of snapshot signature generation and verification. I reserved 512 byes size in snapshot header for store the signature that's generated from the digest with SHA algorithms. For adapt S4 signature check to secure boot, I have porting 3 patches from Fedora kernel, authors are Josh Boyer and Matthew Garrett. I also add Cc. to them. Please help review this RFC patchset! Appreciate for any comments! v3: - Load S4 sign key before ExitBootServices in efi stub. - In Makefile, moved hibernate_keys.o before hibernate.o for load S4 sign key before check hibernate image. It makes sure the new sign key will be transfer to resume target kernel. - Set "depends on EFI_STUB" in Kconfig. v2: - Moved SNAPSHOT_VERIFICATION kernel config to earlier patch. - Add dummy functions to simplify the ifdef check. - Sent to opensuse-kernel(a)opensuse.org for review: http://lists.opensuse.org/opensuse-kernel/2013-08/msg00025.html v1: - Internal review - github: https://github.com/joeyli/linux-s4sign/commits/devel-s4sign Josh Boyer (1): Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode Lee, Chun-Yi (15): asymmetric keys: add interface and skeleton for implement signature generation asymmetric keys: implement EMSA_PKCS1-v1_5-ENCODE in rsa asymmetric keys: separate the length checking of octet string from RSA_I2OSP asymmetric keys: implement OS2IP in rsa asymmetric keys: implement RSASP1 asymmetric keys: support parsing PKCS #8 private key information asymmetric keys: explicitly add the leading zero byte to encoded message Hibernate: introduced RSA key-pair to verify signature of snapshot Hibernate: generate and verify signature of snapshot Hibernate: Avoid S4 sign key data included in snapshot image Hibernate: applied SNAPSHOT_VERIFICATION config to switch signature check Hibernate: adapt to UEFI secure boot with signature check Hibernate: show the verification time for monitor performance Hibernate: introduced SNAPSHOT_SIG_HASH config for select hash algorithm Hibernate: notify bootloader regenerate key-pair for snapshot verification Matthew Garrett (2): Secure boot: Add new capability efi: Enable secure boot lockdown automatically when enabled in firmware Documentation/kernel-parameters.txt | 7 + Documentation/x86/zero-page.txt | 2 + arch/x86/boot/compressed/eboot.c | 121 ++++++++++ arch/x86/include/asm/bootparam_utils.h | 8 +- arch/x86/include/asm/efi.h | 9 + arch/x86/include/uapi/asm/bootparam.h | 4 +- arch/x86/kernel/setup.c | 7 + arch/x86/platform/efi/efi.c | 68 ++++++ crypto/asymmetric_keys/Kconfig | 11 + crypto/asymmetric_keys/Makefile | 16 ++ crypto/asymmetric_keys/pkcs8.asn1 | 19 ++ crypto/asymmetric_keys/pkcs8_info_parser.c | 152 ++++++++++++ crypto/asymmetric_keys/pkcs8_parser.h | 23 ++ crypto/asymmetric_keys/pkcs8_private_key.c | 148 ++++++++++++ crypto/asymmetric_keys/pkcs8_rsakey.asn1 | 29 +++ crypto/asymmetric_keys/private_key.h | 29 +++ crypto/asymmetric_keys/public_key.c | 32 +++ crypto/asymmetric_keys/rsa.c | 283 ++++++++++++++++++++++- crypto/asymmetric_keys/signature.c | 28 +++ include/crypto/public_key.h | 28 +++ include/keys/asymmetric-subtype.h | 6 + include/linux/cred.h | 2 + include/linux/efi.h | 18 ++ include/uapi/linux/capability.h | 6 +- kernel/cred.c | 17 ++ kernel/power/Kconfig | 77 ++++++- kernel/power/Makefile | 1 + kernel/power/hibernate.c | 37 +++ kernel/power/hibernate_keys.c | 329 ++++++++++++++++++++++++++ kernel/power/main.c | 11 +- kernel/power/power.h | 35 +++ kernel/power/snapshot.c | 345 +++++++++++++++++++++++++++- kernel/power/swap.c | 22 ++ kernel/power/user.c | 22 ++ 34 files changed, 1925 insertions(+), 27 deletions(-) create mode 100644 crypto/asymmetric_keys/pkcs8.asn1 create mode 100644 crypto/asymmetric_keys/pkcs8_info_parser.c create mode 100644 crypto/asymmetric_keys/pkcs8_parser.h create mode 100644 crypto/asymmetric_keys/pkcs8_private_key.c create mode 100644 crypto/asymmetric_keys/pkcs8_rsakey.asn1 create mode 100644 crypto/asymmetric_keys/private_key.h create mode 100644 kernel/power/hibernate_keys.c -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

9 60

[opensuse-kernel] Apresentadora Priscilla Alcantara
by PRIKOTA PRODU��ES 05 Sep '13

05 Sep '13

1 0

[opensuse-kernel] modprobe: unrecognized option '--allow-unsupported-modules'
by Cristian Rodríguez 05 Sep '13

05 Sep '13

Hi: Apparently the "unsupported modules" thing has crawled into openSUSE Factory mkinitrd , everytime I run it tells me: modprobe: unrecognized option '--allow-unsupported-modules' /lib/mkinitrd/scripts/setup-modules.sh check_supported_kernel should just return 0 in openSUSE as it is meaningless and nothing else supports this concept of "unsupported modules" (not systemd, not udev, not kmod, etc..etc.. none of the modern stack does) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 2

[opensuse-kernel] enabling function tracer
by Andi Kleen 04 Sep '13

04 Sep '13

Hi, One thing that I find inconvenient with standard open suse kernels is that the function tracing support is disabled (CONFIG_FUNCTION_TRACER). I know it's in the tracing kernel, but that has a lot of stuff that is really slow. It's incredibly useful to quickly debug or analyze things without recompiling. I know the thing had significant overhead in the old days, but since dynamic mcount patching was added the overhead should be fairly low (<1-2%) when disabled. Any chance to enable it by default? I also noticed that some ftrace features should be also cheap are also disabled like CONFIG_TRACER_SNAPSHOT. And it's not clear why block trace is disabled too, it should be also practically free when disabled. But at least the function tracer would be nice. -Andi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 2

[opensuse-kernel] dmesg not good
by Felix Miata 04 Sep '13

04 Sep '13

KDE4: 2.4GHz Celeron 1GB RAM http://fm.no-ip.com/Tmp/SUSE/Factory/t2240-dmesg-trap-os131m4-311rc7.txt Xorg OK KDE plenty slow KDE3: 2.4GHz P4 1GB RAM http://fm.no-ip.com/Tmp/SUSE/Factory/gx260-dmesg-trap-os131m4-311rc7.txt http://fm.no-ip.com/SS/os131m4Xconfig-gx260-i845Gk3corrupt.png Both systems run 13.1M4/3.11.rc7 on i845G video. As check within past 10 or so hours I updated both of these, plus other 13.1M4/KDE3 systems with Radeon and Nouveau video, and one with 13.1M4/KDE4/Radeon without noticing any video corruption, but I didn't look for traps in their dmesgs either, since I didn't notice register dumps on tty1 during boot on them. So, kernel problem? Intel driver problem? KDE problem? Multi problem? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

1 1

[opensuse-kernel] Kernel naming scheme for 13.1
by Jeff Mahoney 03 Sep '13

03 Sep '13

Hi all - One of the things I'd like to consider for openSUSE 13.1 is changing the naming scheme to include the release in the uname -r output so that when there is a version collision between openSUSE and SLES, we can tell the difference. I've introduced a similar proposal for the naming change to the SLES kernels, so this isn't a case of making the distinction only with openSUSE. So instead of: 3.7.10-1.11-default We could have: 3.7.10-1.11.oS12.3-default I suppose the kernel release for Factory would be: 3.7.10-1.11.oSF-default Feedback I've heard off-list has been that some people prefer to have the project abbreviation in the uname strings be all lower case. It's easier on the eyes, but I don't have a strong opinion either way. -Jeff -- Jeff Mahoney SUSE Labs

4 9