Filesystem is fscked! journal inode missing

I can no longer boot into my linux partition, I was trying to install ReactOS to an empty partition, I didn't think it would touch my other partitions, but nothing boots, I'm using knoppix right now, mounting /hda3 tells me 'mount: wrong fs type, bad option, bad superblock on /dev/hda3,' dmesg says 'EXT3-fs: journal inode is deleted.'
Is there any way to salvage this or at least save some data before reformating?

If it is just the journal that is broken, try:
mount -t ext2 /dev/hda3 [mountpoint]
ext3 can be read by the ext2 driver, and it bypasses the journal data.  If that works, you can just cp your data off it.  As for recovering, I suppose you could try use "tune2fs" to remake the journal.  I'd recommend backing up first though if you can, just in case.

Similar Messages

  • Activity Journal Template missing

    Hi
    To configure Activity I have done required settings & earlier I was able to see activity journal template in  activity transaction.But now I am not able to see any template in activity journal tab.
    Can any one help me.
    Regards,
    Natasha

    Hello,
    Please check in Define Activity Journals (T Code:CRMM_JOURNAL )
    We define Start date & End date for a Activity Journal Template type.
    Activity Journal Template is a time dependent.
    With Best Regards,
    Rajendra Sonawane

  • OS X Lion requires a journaling filesystem on my macbook pro.

    My Macbook Pro is stuck in Lion Limbo.
    This is an upgrade.  It claims my filesystem isn't journaling -- Diskutility shows that it is, but I did enable it anyway with the button press.   The Lion installer still can't see it, or something else didn't work well.
    I'm not sure where the installer downloaded to yet, in case I need to reboot this thing and restart the installation process.  But before I do that, I need to solve this problem.
    What can I do to fix this?
    Thanks!

    I solved the problem on my own.
    The solution is to enable Journaling (find that button at the top).  Exit the installation program then re-start it.  It's located under /Applications as "Install OS X Lion.dmg" or something like that. 
    Then, it works.

  • QFS filesystem "mm" device inode usage and recovery

    I have questions regarding inode usage on a QFS filesystem. Our QFS filesystem “mm” devices are filling up rather quickly and we are trying to understand why. The SAMFS/QFS documentation doesn’t go into that much detail on explaining inode usage from a metadevice standpoint. Here is a small part of the output from “samcmd –m” command:
    mm 1001 95% on 0 3.996G 206.875M [423680 inodes]
    mm 1001 100% on 0 3.996G 0 [0 inodes]
    The first question I have: When do the “mm” device inodes get created, or better yet get USED? I understand files and directories are assigned inodes, but we have observed that just creating files and directories doesn’t USE the “mm” inodes. I have created multiple files and directories in our QFS filesystem, ran the “samcmd –m” command, and the output of free inodes is still the same.
    Next question: How does the QFS filesystem recover “mm” device inodes? Just removing a couple files doesn’t increase the number of inodes available, but in one instance I deleted 60000 directories and suddenly over 400000 inodes are freed up. Is there a correlation between inodes freed up and the files? I would figure there would be one inode for each, but there seems to be more. I understand samfsck would recover inodes as well.
    Basically my goal is to understand when the inodes are created/used up and how they are recovered. I understand that I may need to add additional “mm” devices, using the samgrowfs command, but don’t want to do that quite yet. Any help understanding QFS "mm" device inode usage and recovery is appreciated.

    The PC was indeed turned off between the two checks.
    However the first check was not performed right before the shutdown, but few hours before it.
    :idea:
    (...) varying from browser cache data increase to a cronjob like updatedb, or even you installing or downloading something.
    When I've read these words I have started to "scroll" back in my memory buffer and eventually I've remembered that the only thing I did as superuser was to download some Firefox extensions which (surprise or not...) summed up to ~12M.
    So we have the answer for this one too thanks to your hints
    PS: That's exactly the reason why I've made a small / partition - to keep a close eye on it's usage and to ring some allarms when needed.
    Again, thank you. 

  • [solved] How to recoved data off a masacred filesystem

    I'm in trouble. I am trying to recover my main data partition. Here's how it happened:
    sdb1 - 680gb primary partition, ext4, around 300gb of data on it
    sdb2 - 60gb primary partition, ext4, for backing up system from sda1 with rsync
    Yesterday, while doing rsync backup on sdb2, I run gparted, which indicated that it cannot read partition table on sdb and displayed the whole of it as unallocated. I know that when I run gparted 30 earlier, the partition was still vissible.
    Nevertheless, I thought that's because of rsync and I thought reboot would fix that, because sdb1 was still mounted, and I was accessing all the data on it with no issues.
    When rsync was done, I rebooted an that was the last time I saw my data.
    Automounting during boot gives me:
    superblock could not be read or does not describe correct ext2 filesystem...
    So I tried to run
    $ sudo fsck.ext4 -p -b 98304 -B 4096 /dev/sdb
    fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb
    /dev/sdb:
    The superblock could not be read or does not describe a correct ext2
    filesystem. If the device is valid and it really contains an ext2
    filesystem (and not swap or ufs or something else), then the superblock
    is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
    $ sudo e2fsck -b 8193 /dev/sdb
    [sudo] password for juha:
    e2fsck 1.42.8 (20-Jun-2013)
    e2fsck: Bad magic number in super-block while trying to open /dev/sdb
    The superblock could not be read or does not describe a correct ext2
    filesystem. If the device is valid and it really contains an ext2
    filesystem (and not swap or ufs or something else), then the superblock
    is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
    I tried the same command with all superblock backups that were listed.
    $ sudo fsck -n /dev/sdb1
    fsck from util-linux 2.24
    e2fsck 1.42.8 (20-Jun-2013)
    ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
    fsck.ext4: Group descriptors look bad... trying backup blocks...
    fsck.ext4: Bad magic number in super-block while using the backup blocksfsck.ext4: going back to original superblock
    Superblock has an invalid journal (inode 8).
    Clear? no
    fsck.ext4: Illegal inode number while checking ext3 journal for /dev/sdb1
    /dev/sdb1: ********** WARNING: Filesystem still has errors **********
    I also run testdisk to see if it can find data from sdb1.
    It finds the partition (partition type is automatically selected as None) but it finds no files on sdb1, even after deep search.
    It does find data on sdb2, but that's just system partition backup I don't care about at this point.
    Also, just now I run this
    ]$ sudo fsck.ext4 -v /dev/sdb1
    e2fsck 1.42.8 (20-Jun-2013)
    ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
    fsck.ext4: Group descriptors look bad... trying backup blocks...
    fsck.ext4: Bad magic number in super-block while using the backup blocksfsck.ext4: going back to original superblock
    Superblock has an invalid journal (inode 8).
    Clear<y>? yes
    *** ext3 journal has been deleted - filesystem is now ext2 only ***
    Note: if several inode or block bitmap blocks or part
    of the inode table require relocation, you may wish to try
    running e2fsck with the '-b 32768' option first. The problem
    may lie only with the primary block group descriptors, and
    the backup block group descriptors may be OK.
    Block bitmap for group 256 is not in group. (block 1268396107)
    Relocate<y>? yes
    Inode bitmap for group 256 is not in group. (block 1125246092)
    Relocate<y>? yes
    Inode table for group 256 is not in group. (block 2088878841)
    WARNING: SEVERE DATA LOSS POSSIBLE.
    Relocate<y>? no
    One or more block group descriptor checksums are invalid. Fix<y>? yes
    Group descriptor 256 checksum is 0x6349, should be 0x9abd. FIXED.
    Inode bitmap for group 257 is not in group. (block 2837529440)
    Relocate<y>? yes
    Inode table for group 257 is not in group. (block 2199953455)
    WARNING: SEVERE DATA LOSS POSSIBLE.
    Relocate<y>? no
    Group descriptor 257 checksum is 0x02d4, should be 0xd13d. FIXED.
    Block bitmap for group 258 is not in group. (block 3896597355)
    Relocate<y>? yes
    Inode bitmap for group 258 is not in group. (block 2097244160)
    Relocate<y>? yes
    Inode table for group 258 is not in group. (block 2609271215)
    WARNING: SEVERE DATA LOSS POSSIBLE.
    Relocate<y>? no
    Group descriptor 258 checksum is 0xee91, should be 0xc246. FIXED.
    Block bitmap for group 259 is not in group. (block 805546298)
    Relocate<y>? yes
    Inode bitmap for group 259 is not in group. (block 3538423854)
    Relocate<y>? yes
    Inode table for group 259 is not in group. (block 2924444292)
    WARNING: SEVERE DATA LOSS POSSIBLE.
    Relocate<y>? no
    Group descriptor 259 checksum is 0xc190, should be 0x4c0d. FIXED.
    Block bitmap for group 260 is not in group. (block 338739984)
    Relocate<y>? yes
    Inode bitmap for group 260 is not in group. (block 902864749)
    Relocate<y>? yes
    Inode table for group 260 is not in group. (block 1901539298)
    WARNING: SEVERE DATA LOSS POSSIBLE.
    Relocate<y>? no
    Group descriptor 260 checksum is 0xac76, should be 0xac63. FIXED.
    Block bitmap for group 261 is not in group. (block 1660969779)
    Relocate<y>? yes
    Inode bitmap for group 261 is not in group. (block 209743725)
    Relocate<y>? yes
    Inode table for group 261 is not in group. (block 879935846)
    WARNING: SEVERE DATA LOSS POSSIBLE.
    Relocate<y>? no
    Group descriptor 261 checksum is 0x800e, should be 0x8fa5. FIXED.
    Block bitmap for group 262 is not in group. (block 1705519300)
    Relocate<y>? yes
    Inode bitmap for group 262 is not in group. (block 1360743755)
    Relocate<y>? yes
    Inode table for group 262 is not in group. (block 4107065764)
    WARNING: SEVERE DATA LOSS POSSIBLE.
    Relocate<y>? no
    Group descriptor 262 checksum is 0xc00d, should be 0xe8f3. FIXED.
    Inode bitmap for group 263 is not in group. (block 2205583287)
    Relocate<y>? yes
    Inode table for group 263 is not in group. (block 3636737468)
    WARNING: SEVERE DATA LOSS POSSIBLE.
    Relocate<y>? yes
    Group descriptor 263 checksum is 0x69a9, should be 0xb9a9. FIXED.
    Block bitmap for group 264 is not in group. (block 1471470759)
    Relocate<y>? yes
    Inode bitmap for group 264 is not in group. (block 1725839977)
    Relocate<y>? yes
    Inode table for group 264 is not in group. (block 2144458553)
    WARNING: SEVERE DATA LOSS POSSIBLE.
    Relocate<y>? no
    Group descriptor 264 checksum is 0xcd09, should be 0xea3a. FIXED.
    Block bitmap for group 265 is not in group. (block 3617231787)
    Relocate<y>? yes
    Inode bitmap for group 265 is not in group. (block 2640198439)
    Relocate<y>? yes
    Inode table for group 265 is not in group. (block 2725347176)
    WARNING: SEVERE DATA LOSS POSSIBLE.
    Relocate<y>? no
    Group descriptor 265 checksum is 0xbbb8, should be 0xb870. FIXED.
    Block bitmap for group 266 is not in group. (block 1840499818)
    Relocate<y>? yes
    Inode bitmap for group 266 is not in group. (block 3698703324)
    Relocate<y>? yes
    Inode table for group 266 is not in group. (block 2882301371)
    WARNING: SEVERE DATA LOSS POSSIBLE.
    Relocate<y>? no
    Group descriptor 266 checksum is 0xb3c9, should be 0x72d5. FIXED.
    Block bitmap for group 267 is not in group. (block 1968099309)
    Relocate<y>? yes
    Inode bitmap for group 267 is not in group. (block 2125019324)
    Relocate<y>? yes
    Inode table for group 267 is not in group. (block 2616321653)
    WARNING: SEVERE DATA LOSS POSSIBLE.
    Relocate<y>? no
    Group descriptor 267 checksum is 0x72bb, should be 0xc66c. FIXED.
    Block bitmap for group 268 is not in group. (block 3197564106)
    Relocate<y>? yes
    Inode bitmap for group 268 is not in group. (block 1173679527)
    Relocate<y>? yes
    Inode table for group 268 is not in group. (block 3081059840)
    WARNING: SEVERE DATA LOSS POSSIBLE.
    Relocate<y>? no
    Group descriptor 268 checksum is 0xee4e, should be 0x6c67. FIXED.
    Block bitmap for group 269 is not in group. (block 467880860)
    Relocate<y>? yes
    Inode bitmap for group 269 is not in group. (block 3461842583)
    Relocate<y>? yes
    Inode table for group 269 is not in group. (block 903401461)
    WARNING: SEVERE DATA LOSS POSSIBLE.
    Relocate<y>? no
    Group descriptor 269 checksum is 0x701d, should be 0x1735. FIXED.
    Block bitmap for group 270 is not in group. (block 1737084563)
    Relocate<y>? yes
    Inode bitmap for group 270 is not in group. (block 1617385180)
    Relocate<y>? yes
    Inode table for group 270 is not in group. (block 3944519733)
    WARNING: SEVERE DATA LOSS POSSIBLE.
    Relocate<y>? no
    Group descriptor 270 checksum is 0x1c78, should be 0x9f4e. FIXED.
    Block bitmap for group 271 is not in group. (block 3558332121)
    Relocate<y>? yes
    Inode bitmap for group 271 is not in group. (block 1481837154)
    Relocate<y>? yes
    Inode table for group 271 is not in group. (block 1108213120)
    WARNING: SEVERE DATA LOSS POSSIBLE.
    Relocate<y>? no
    Group descriptor 271 checksum is 0x3066, should be 0xce01. FIXED.
    Block bitmap for group 272 is not in group. (block 3294840462)
    Relocate<y>? yes
    Inode bitmap for group 272 is not in group. (block 1680662834)
    Relocate<y>? yes
    Inode table for group 272 is not in group. (block 747037043)
    WARNING: SEVERE DATA LOSS POSSIBLE.
    Relocate<y>? no
    Group descriptor 272 checksum is 0x7d96, should be 0xde7a. FIXED.
    Block bitmap for group 273 is not in group. (block 805709209)
    Relocate<y>? cancelled!
    Inode bitmap for group 273 is not in group. (block 220354588)
    Relocate<y>? cancelled!
    Inode table for group 273 is not in group. (block 281430039)
    WARNING: SEVERE DATA LOSS POSSIBLE.
    Relocate<y>? cancelled!
    Group descriptor 273 checksum is 0xa378, should be 0x6f41. FIXED.
    /dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****
    /dev/sdb1: ********** WARNING: Filesystem still has errors **********
    But as you can see, I chickened out on "SEVERE DATA LOSS POSSIBLE" warnings, and after few repeats, I just hit ctrl+c not sure if I should even touch that.
    What should I do here?
    Last edited by Lockheed (2013-12-19 17:27:12)

    The image is decompressed and takes 650GB, which is as much as the partition was on the drive. But I had not enough free space, so I had to save that image on the drive which had the original partition on it.
    I tried to check for locations of superblock:
    $ dumpe2fs /mnt/Disk_D/backup.img | grep -i superblockdumpe2fs 1.42.8 (20-Jun-2013)
    dumpe2fs: Attempt to read block from filesystem resulted in short read while reading journal super block
    No luck. So I tried this:
    $ mke2fs -n /mnt/Disk_D/backup.img
    mke2fs 1.42.8 (20-Jun-2013)
    /mnt/Disk_D/backup.img is not a block special device.
    Proceed anyway? (y,n) y
    Filesystem label=
    OS type: Linux
    Block size=4096 (log=2)
    Fragment size=4096 (log=2)
    Stride=0 blocks, Stripe width=0 blocks
    41762816 inodes, 167026688 blocks
    8351334 blocks (5.00%) reserved for the super user
    First data block=0
    Maximum filesystem blocks=4294967296
    5098 block groups
    32768 blocks per group, 32768 fragments per group
    8192 inodes per group
    Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
    102400000
    Now, if I understand correctly, to use it in "sb=" parameter with mount, I need to multiply those numbers by 4.
    So I tried the first one:
    $ sudo mount /mnt/Disk_D/backup.img /mnt/arch_backup -o loop,ro,sb=131072
    mount: wrong fs type, bad option, bad superblock on /dev/loop0,
    missing codepage or helper program, or other error
    In some cases useful info is found in syslog - try
    dmesg | tail or so.
    $ dmesg | tail
    [ 413.993564] CE: hpet increased min_delta_ns to 20115 nsec
    [ 765.048697] loop: module loaded
    [ 1291.820673] EXT4-fs (loop0): VFS: Can't find ext4 filesystem
    But the second one went better, or should I say "different":
    $ sudo mount /mnt/Disk_D/backup.img /mnt/arch_backup -o loop,ro,sb=393216
    mount: wrong fs type, bad option, bad superblock on /dev/loop0,
    missing codepage or helper program, or other error
    In some cases useful info is found in syslog - try
    dmesg | tail or so.
    $ dmesg | tail
    [ 1354.694258] Buffer I/O error on device loop0, logical block 98304
    [ 1354.694261] lost page write due to I/O error on loop0
    [ 1354.694264] EXT4-fs error (device loop0): ext4_iget:4044: inode #8: comm mount: bad extra_isize (17818 != 256)
    [ 1354.694271] EXT4-fs (loop0): no journal found
    I tried it with every following superblock, but the result was identical.
    What should I do now?
    I found here a similar error, and the advice was to delete journal and recreate it:
    http://tipsaboutmywork.blogspot.com/
    Remove the journal feature from the file system (downgrade to ext2)
    tune2fs -O ^has_journal /dev/sda8
    fsck to delete the journal:
    e2fsck -f /dev/sda8
    recreate the journal (change back to ext3)
    tune2fs -j /dev/sda8
    and finally, remount it.
    Does that have the potential to trash my data (like fsck did earlier) or does it just get rid of the journal, and not touching data?
    And if the later is the case, would that result in loss of filenames and folders like photorec recovery?
    Should I do that, or should I try something else first?
    Last edited by Lockheed (2013-12-07 16:13:40)

  • Mounting local filesystem - FAIL (yet the fs still mounts...) [SOLVED]

    After modifying my time/date setup (setting the hardware clock to UTC, and using a custom timezone file) I started to get a [FAIL] message during boot (after the system had resynched to drive times to the system time), and shutdown.
    @ boot time
    Mounting local filesystem
            Ext3-fs: barriers not enabled
            kjournal starting. Commit interval 5 seconds
            Ext3-fs (sda4): using internal journal
            Ext3-fs (sda4): mounted filesystem with ordered data mode
                                                                                                                     [FAIL]
    @ shutdown
    Unmounting Filesystem                    [FAIL]
    Nothing seems to be negatively affected, and the boot and shutdown processes continue without even pausing, and sda4 (my /home directory) certainly seems to by mounted (since I'm using it now).
    I've run fsck at boot a couple times, but the drives keep coming back clean. I've tried using my old timezone setup, but the fail message persists. I've successfully unmounted and mounted sda4 as Root, trying to generate an error message of some kind, but all I get is a successfully unmounted, or mounted, drive. I've unmounted sda4 priod to shutdown as well, but the message persists.
    The only place in the logs the [FAIL] message shows up is in /var/log/boot:
    Mounting local filesystem   [BUSY]  [FAIL]
    I'm at a loss. I would like to fix this, if only to be sure that it's not a symptom of a larger problem. At the very least, I'd like to know what is causing it.
    Last edited by uxrs75 (2011-08-02 06:40:31)

    You interpret correctly, Logicien. BIOS is set to UTC; HARDWARECLOCK="UTC". Time and date are a-ok.
    I ran mkinitcpio -p kernel26, but the message persists. I also tried using the live cd, and mounting each of the drives in turn. All of them mounted successfully, with no error messages. To verify that it is sda4, I commented the sda4 line out in fstab, and rebooted the machine. I got:
    Mounting Local Filesystems [FAIL]
    but none of the Ext3-fs stuff, and the boot process continued successfully. I'm wondering if it's something else.
    I'll try adding quiet to the kernel boot line later this evening and see what that brings about.
    rc.conf
    # /etc/rc.conf - Main Configuration for Arch Linux
    # LOCALIZATION
    # LOCALE: available languages can be listed with the 'locale -a' command
    # DAEMON_LOCALE: If set to 'yes', use $LOCALE as the locale during daemon
    # startup and during the boot process. If set to 'no', the C locale is used.
    # HARDWARECLOCK: set to "", "UTC" or "localtime", any other value will result
    # in the hardware clock being left untouched (useful for virtualization)
    # Note: Using "localtime" is discouraged, using "" makes hwclock fall back
    # to the value in /var/lib/hwclock/adjfile
    # TIMEZONE: timezones are found in /usr/share/zoneinfo
    # Note: if unset, the value in /etc/localtime is used unchanged
    # KEYMAP: keymaps are found in /usr/share/kbd/keymaps
    # CONSOLEFONT: found in /usr/share/kbd/consolefonts (only needed for non-US)
    # CONSOLEMAP: found in /usr/share/kbd/consoletrans
    # USECOLOR: use ANSI color sequences in startup messages
    LOCALE="en_US.UTF-8"
    DAEMON_LOCALE="no"
    HARDWARECLOCK="UTC"
    TIMEZONE="PST"
    KEYMAP="uk"
    CONSOLEFONT="ter-116n.psf.gz"
    #CONSOLEMAP="8859-1"
    USECOLOR="yes"
    # HARDWARE
    # MODULES: Modules to load at boot-up. Blacklisting is no longer supported.
    # Replace every !module by an entry as on the following line in a file in
    # /etc/modprobe.d:
    # blacklist module
    # See "man modprobe.conf" for details.
    MODULES=()
    # Udev settle timeout (default to 30)
    UDEV_TIMEOUT=30
    # Scan for FakeRAID (dmraid) Volumes at startup
    USEDMRAID="no"
    # Scan for BTRFS volumes at startup
    USEBTRFS="no"
    # Scan for LVM volume groups at startup, required if you use LVM
    USELVM="no"
    # NETWORKING
    # HOSTNAME: Hostname of machine. Should also be put in /etc/hosts
    HOSTNAME="darkstar"
    # Use 'ip addr' or 'ls /sys/class/net/' to see all available interfaces.
    # Wired network setup
    # - interface: name of device (required)
    # - address: IP address (leave blank for DHCP)
    # - netmask: subnet mask (ignored for DHCP) (optional, defaults to 255.255.255.0)
    # - broadcast: broadcast address (ignored for DHCP) (optional)
    # - gateway: default route (ignored for DHCP)
    # Static IP example
    # interface=eth0
    # address=192.168.0.2
    # netmask=255.255.255.0
    # broadcast=192.168.0.255
    # gateway=192.168.0.1
    # DHCP example
    # interface=eth0
    # address=
    # netmask=
    # gateway=
    interface=eth0
    address=
    netmask=
    broadcast=
    gateway=
    # Setting this to "yes" will skip network shutdown.
    # This is required if your root device is on NFS.
    NETWORK_PERSIST="no"
    # Enable these netcfg profiles at boot-up. These are useful if you happen to
    # need more advanced network features than the simple network service
    # supports, such as multiple network configurations (ie, laptop users)
    # - set to 'menu' to present a menu during boot-up (dialog package required)
    # - prefix an entry with a ! to disable it
    # Network profiles are found in /etc/network.d
    # This requires the netcfg package
    #NETWORKS=(main)
    # DAEMONS
    # Daemons to start at boot-up (in this order)
    # - prefix a daemon with a ! to disable it
    # - prefix a daemon with a @ to start it up in the background
    # If something other takes care of your hardware clock (ntpd, dual-boot...)
    # you should disable 'hwclock' here.
    DAEMONS=(hwclock syslog-ng dbus !network !netfs crond alsa mpd)
    fstab
    # /etc/fstab: static file system information
    # <file system> <dir> <type> <options> <dump> <pass>
    none /dev/pts devpts defaults 0 0
    none /dev/shm tmpfs defaults 0 0
    #none /proc/bus/usb usbfs auto,busgid=101,busmode=0775,devgid=101,devmode=0664 0 0
    /dev/sr0 /media/sr0 auto ro,users,noauto,unhide 0 0
    /dev/sr1 /media/sr1 auto ro,users,noauto,unhide 0 0
    #/dev/sda1 /boot ext2 defaults 0 1
    #/dev/sda2 swap swap defaults 0 0
    #/dev/sda3 / ext3 defaults 0 1
    #/dev/sda4 /home ext3 defaults 0 1
    UUID=597bd99a-173b-4b23-947d-b8a50859bcdd /boot ext2 defaults 0 1
    UUID=a51a3b55-7c5c-45bb-96eb-79cfd1a77f54 swap swap defaults 0 0
    UUID=c6ecf0fe-d2c4-4743-b639-1550295b65c6 / ext3 defaults 0 1
    UUID=ff7030b8-890a-4673-bd1c-f502ca5efb2b /home ext3 defaults 0 1
    /dev/sdb1 /media/sdb1 auto noauto,owner,users 0 0
    /dev/sdb1 /media/sdb1 auto noauto,owner,users 0 0
    /dev/sdc1 /media/sdc1 auto noauto,owner,users 0 0
    /dev/sdd1 /media/sdd1 auto noauto,owner,users 0 0
    /dev/sde1 /media/sde1 auto noauto,owner,users 0 0
    /dev/sdf1 /media/sdf1 auto noauto,owner,users 0 0
    fdisk -l
    Disk /dev/sda: 500.1 GB, 500107862016 bytes
    255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0x00000000
    Device Boot Start End Blocks Id System
    /dev/sda1 * 1 208844 104422 83 Linux
    /dev/sda2 208845 738989 265072+ 82 Linux swap / Solaris
    /dev/sda3 738990 103153364 51207187+ 83 Linux
    /dev/sda4 103153365 976768064 436807350 83 Linux
    dumpe2fs -h /dev/sda1
    dumpe2fs 1.41.14 (22-Dec-2010)
    Filesystem volume name: <none>
    Last mounted on: <not available>
    Filesystem UUID: 597bd99a-173b-4b23-947d-b8a50859bcdd
    Filesystem magic number: 0xEF53
    Filesystem revision #: 1 (dynamic)
    Filesystem features: ext_attr resize_inode dir_index filetype sparse_super
    Filesystem flags: signed_directory_hash
    Default mount options: (none)
    Filesystem state: not clean
    Errors behavior: Continue
    Filesystem OS type: Linux
    Inode count: 26208
    Block count: 104420
    Reserved block count: 5221
    Free blocks: 84721
    Free inodes: 26177
    First block: 1
    Block size: 1024
    Fragment size: 1024
    Reserved GDT blocks: 256
    Blocks per group: 8192
    Fragments per group: 8192
    Inodes per group: 2016
    Inode blocks per group: 252
    Filesystem created: Fri Apr 30 20:35:47 2010
    Last mount time: Thu Aug 19 05:44:48 2010
    Last write time: Mon Aug 1 13:58:14 2011
    Mount count: 8
    Maximum mount count: 23
    Last checked: Mon Aug 1 07:23:24 2011
    Check interval: 15552000 (6 months)
    Next check after: Sat Jan 28 07:23:24 2012
    Reserved blocks uid: 0 (user root)
    Reserved blocks gid: 0 (group root)
    First inode: 11
    Inode size: 128
    Default directory hash: half_md4
    Directory Hash Seed: f5f22ff8-0cb1-4c30-a172-ead082f0ad8a
    dumpe2fs -h /dev/sda3
    dumpe2fs 1.41.14 (22-Dec-2010)
    Filesystem volume name: <none>
    Last mounted on: <not available>
    Filesystem UUID: c6ecf0fe-d2c4-4743-b639-1550295b65c6
    Filesystem magic number: 0xEF53
    Filesystem revision #: 1 (dynamic)
    Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
    Filesystem flags: signed_directory_hash
    Default mount options: (none)
    Filesystem state: clean
    Errors behavior: Continue
    Filesystem OS type: Linux
    Inode count: 3203072
    Block count: 12801796
    Reserved block count: 640089
    Free blocks: 10487133
    Free inodes: 3000642
    First block: 0
    Block size: 4096
    Fragment size: 4096
    Reserved GDT blocks: 1020
    Blocks per group: 32768
    Fragments per group: 32768
    Inodes per group: 8192
    Inode blocks per group: 512
    Filesystem created: Fri Apr 30 20:35:51 2010
    Last mount time: Mon Aug 1 13:58:14 2011
    Last write time: Mon Aug 1 07:22:14 2011
    Mount count: 8
    Maximum mount count: 23
    Last checked: Mon Aug 1 07:22:14 2011
    Check interval: 15552000 (6 months)
    Next check after: Sat Jan 28 07:22:14 2012
    Reserved blocks uid: 0 (user root)
    Reserved blocks gid: 0 (group root)
    First inode: 11
    Inode size: 256
    Required extra isize: 28
    Desired extra isize: 28
    Journal inode: 8
    First orphan inode: 262152
    Default directory hash: half_md4
    Directory Hash Seed: 08e3f2db-7bb4-41fc-9364-9a9f637951ff
    Journal backup: inode blocks
    Journal features: journal_incompat_revoke
    Journal size: 128M
    Journal length: 32768
    Journal sequence: 0x0007df4e
    Journal start: 1
    dumpe2fs -h /dev/sda4
    dumpe2fs 1.41.14 (22-Dec-2010)
    Filesystem volume name: <none>
    Last mounted on: <not available>
    Filesystem UUID: ff7030b8-890a-4673-bd1c-f502ca5efb2b
    Filesystem magic number: 0xEF53
    Filesystem revision #: 1 (dynamic)
    Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
    Filesystem flags: signed_directory_hash
    Default mount options: (none)
    Filesystem state: clean
    Errors behavior: Continue
    Filesystem OS type: Linux
    Inode count: 27303936
    Block count: 109201837
    Reserved block count: 5460091
    Free blocks: 80860937
    Free inodes: 27074933
    First block: 0
    Block size: 4096
    Fragment size: 4096
    Reserved GDT blocks: 997
    Blocks per group: 32768
    Fragments per group: 32768
    Inodes per group: 8192
    Inode blocks per group: 512
    Filesystem created: Fri Apr 30 20:36:07 2010
    Last mount time: Mon Aug 1 13:58:14 2011
    Last write time: Mon Aug 1 13:58:14 2011
    Mount count: 8
    Maximum mount count: 25
    Last checked: Mon Aug 1 07:23:25 2011
    Check interval: 15552000 (6 months)
    Next check after: Sat Jan 28 07:23:25 2012
    Reserved blocks uid: 0 (user root)
    Reserved blocks gid: 0 (group root)
    First inode: 11
    Inode size: 256
    Required extra isize: 28
    Desired extra isize: 28
    Journal inode: 8
    Default directory hash: half_md4
    Directory Hash Seed: e8dbb219-f7fe-4878-96b6-9137361ce1e2
    Journal backup: inode blocks
    Journal features: journal_incompat_revoke
    Journal size: 128M
    Journal length: 32768
    Journal sequence: 0x0011b560
    Journal start: 1
    Last edited by uxrs75 (2011-08-02 06:19:11)

  • Recovering broken filesystems

    Before I ask my question, here's what the setup involved is:
    I have one SSD, which holds / and /boot (not LVMed), and one 2TB HDD that held /var, /tmp, swap, and 2 data partitions.I had run out of space, so I bought 2 more 2TB hard drives. I'd planned to make a degraded RAID5 out of them, put an LVM over top of it with partitions matching my existing ones, copy data over, then wipe the original disk and add it to the array.
    Now, what happened:
    Basically, I wasn't paying as much attention as I should have when I used fdisk. I knew what the 2TB drive's letter was before I added the two new ones, but of course I didn't consider that adding disks would change it. So, I formatted 2 disks, 1 of the new ones plus the old one, with a full-disk partition with the type set to Linux RAID auto-detect. Before I wrote anything else to them, though, I realized I'd reformatted the wrong disk. So, I formatted it back to an LVM partition, and used /etc/lvm/archive to recreate the physical volume. LVM figured it out and was happy.
    Here's where it gets a bit weird. Since LVM configurations are backed up before, not after, a new command is run, the last and largest of the partitions wasn't recreated by this. That was fine, though, the guide I was using ( http://insights.oetiker.ch/linux/lvm/ ) noted that, and had a way to restore that last partition. Since the command creating the backup of the configuration is in the backup, I could just run that with an extra flag. Well, that went fine too, I thought. LVM happily restored, everything was good. But, when I tried to get device-mapper to see them, the other 4 showed up in /dev/mapper, but this 5th one failed with an error about being too large for the target.
    But, I have (relatively) recent backups of that one, so I didn't concern myself with it. Restoring /var and the other data volume was my primary concern. So, I kept going. But even though LVM knew about them and device-mapper saw them, something was wrong with those partitions, too. I couldn't mount or fsck them. When I tried, I got a bad superblock/bad magic number error. So I tried one of the backup superblock locations. No dice. None of the partitions would work. Dumpe2fs didn't even see the superblocks.
    I thought that was especially strange, because no data apart from one mdadm partition's metadata should have been written. They should still be there, and since I'd "successfully" restored the volumes, their filesystems should be intact.
    From there I wasn't sure where to go, for a while. Finally, I took a look at the raw partitions. For example, cat /dev/G2/var | less. I could see my data, and in fact I could see text. Text files still show up undamaged. So why weren't things working?
    Next I looked at the volumes in hexdump. From here I'm less sure that my approach was right, because I don't know that much about the filesystems, but:
    I looked at the working partitions on another, similarly formatted computer (var, tmp, and a data volumes on a HDD, swap on its own non-LVMed partition, and / and /boot on the SSD). For example, comparing the tmp volumes. When I did hexdump -c -v on the working one, it began with:
    0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
    0000010 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
    The broken one, however, starts:
    0000000 \0 201 \0 \0 \0 201 001 \0 \0 201 002 \0 \0 201 003 \0
    0000010 \0 201 004 \0 \0 201 \f \0 \0 201 \r \0 \0 \0 \0 \0
    I wasn't sure what was going on there, but when I looked further down in the working one, I saw something that looked similar...
    0002000 002 200 \0 \0 002 200 001 \0 002 200 002 \0 002 200 003 \0
    0002010 002 200 004 \0 002 200 \f \0 002 200 \r \0 002 200 030 \0
    Similar things show up periodically throughout both volumes, so it's definitely filesystem related. Either inodes or superblock backups, right? (As I said, I don't know enough about the FSes to be confident about anything I say here). Either way, it looks like either when the LVM partition was recreated, or when the volumes were restored, things got shifted by some number of bytes from where they originally were.
    So, my questions: Am I right? Am I just totally off base here? Is there anything I can do to recover my data?
    I've spent the last couple days trying to get things fixed, so at this point even just a fresh pair of eyes on the problem would really help.

    Hi, JoshHardman. Welcome to the Nokia Support Discussions! Just to verify, did you create a backup file before this happened? Which files are you very interested in saving or recovering? Your contacts and paid apps are in sync with your Microsoft account while your media files can be synced to your One Drive account, aside from your memory card.
    Have you tried to press and hold the volume down and power keys until it vibrates? This should get your phone to reboot and respond properly again.
    Let us know the outcome.

  • New install - Filesystem check failed

    I did a new installation of Arch today, and in a random fit of thrillseeking I used syslinux instead of grub for the bootloader. The installation said it was successful, but after restarting Arch failed to boot. The error was in the filesystem check.
    /dev/sda5 is mounted. e2fsck: Cannot continue, aborting.
    /dev/sda5 is where /usr is mounted.
    Also, it complained that / is mounted read-only.
    First question is, how is /usr already mounted? I searched the forums and the most promising thing I found involved mkinitcpio; apparently it tries to take a shortcut and mount /usr early and somehow this happens before the filesystems are fscked. However, I added the shutdown and fsck hooks to /etc/mkinitcpio.conf which are supposed to fix this (https://wiki.archlinux.org/index.php/Mk … _partition), and nothing changed. So I'm out of ideas.
    Second, why is / read-only? fstab only has the 'defaults' option listed for /. syslinux.cfg had the line 'APPEND root=/dev/sda2 ro' so I figured it was probably read-only because of that, but I tried booting both with the ro gone and with it changed to rw, but nothing changed there either, it still gives the message that / is mounted read-only.
    My first inclination was just to disable the filesystem check in fstab, but that seemed like a cheap workaround. I'd really like to understand what the problem is.

    karol wrote:Did you rebuilt the kernel image after you added the hooks?
    No, I didn't realize I had to but that makes sense. Do I use the ABS, like this: https://wiki.archlinux.org/index.php/Ke … ild_System ? Do I need to do anything special to enable the hooks?

  • [SOLVED] Superblock has invalid ext3 journal after change of VMSPLIT

    I'm not sure if this is the appropriate forum for this, but here goes..
    I recently recompiled a custom kernel (toofishes' Eee kernel) which had NOHIGHMEM=y and VMSPLIT2G=y, enabling highmem and changing the split back to VMSPLIT3G. However, when it came to booting it, my login manager never popped up and instead I got a tty. Logging in gave me this output:
    /bin/ls: /lib/librt.so.1: unsupported version 372 of Verdef record
    and when I try to start X:
    xauth: creating new authority file /home/jickel/.serverauth.1892
    /usr/bin/X: error while loading shared libraries: libm.so.6: ELF load command alignment not page-aligned
    giving up.
    xinit: Connection refused (errno 111): unable to connect to X server
    xinit: No such process (errno 3): Server error.
    Plus some segfaults when quitting. It seems I did not configure the new memory setting properly, though I did remember to change the CONFIG_PAGE_OFFSET_ VALUE at least.
    Now when I try to boot using the default arch kernel to replace the faulty kernel, the file system check fails, and when I manually run fsck I get this question:
    Superblock has an invalid ext3 journal (inode 8).
    Clear<y>?
    I'm still pretty new to Linux, but it seems the change of memory might have forced a change in the FS journal. No idea where to go from here though, and I that answering yes to the above might hose my FS. What do you suggest I do? I recently backed up my system, luckily.
    Last edited by Jickel (2008-07-08 20:10:30)

    I did it manually, I'll try doing it the other way later then. Thanks for the advice!
    I guess those segfaults must have damaged the journals then. I'm still not sure how to repair this though.
    UPDATE: Well I deleted the journal, had the file system repaired, and had a new journal created. The fsck command reports everything is fine now, but I still get the "FILE SYSTEM CHECK FAILED - Please repair manually and reboot" box-thingy when I try to reboot. Any idea how do progress from here? I need a working system to update the kernel back to a working one.
    Oh, I found another thread where the OP has the same issue http://bbs.archlinux.org/viewtopic.php?pid=385792 . I'll go through the solutions suggested there and see if anything works. No word on results in that thread though.
    Last edited by Jickel (2008-07-08 05:37:44)

  • Raid5 issue after upgrade

    TLDR = scared to death to answer 'yes' to the following from e2fsck:
    Superblock has an invalid journal (inode 8).
    Clear<y>? cancelled!
    After upgrading to linux 3.2.14-1 (along with others important packages like udev, mkinitcpio, etc) my raid5 array would not assemble.  I don't have the original message but after two days have passed and watching the forums I'm sure it was related to this: https://bugs.archlinux.org/task/29344
    Anyways I'm past that issue and am now having filesystem problems with my raid array after recreating.  Note I'm currently using
    filesystem 2012.2-2
    linux 3.2.14-1
    mkinitcpio 0.8.5-1
    udev 181-5
    During the past two days of tinkering I've never let fsck touch the filesystem nor have I done anything like mkfs on it either.  Only thing I've done is re-create the array using mdadm and then seeing if I can mount it.
    The raid5 array contains /dev/sdb1 /dev/sdc1 and /dev/sdd1.  My initial though was thinking that somehow maybe the drive labels got renamed during the kernel upgrade so I've tried re-creating the array will all six possible permutations of the disks.  Nothing worked.  I know the original order was sdb1/sdc1/sdd1.
    Here is the dumpe2fs info for each of the disks:
    # dumpe2fs /dev/sdb1
    dumpe2fs 1.42.1 (17-Feb-2012)
    Filesystem volume name: <none>
    Last mounted on: /mnt/raid
    Filesystem UUID: 08bb1bfd-4932-494a-93ba-fe8fd37ea22c
    Filesystem magic number: 0xEF53
    Filesystem revision #: 1 (dynamic)
    Filesystem features: has_journal ext_attr resize_inode dir_index filetype sparse_super large_file
    Filesystem flags: signed_directory_hash
    Default mount options: (none)
    Filesystem state: clean
    Errors behavior: Continue
    Filesystem OS type: Linux
    Inode count: 122101760
    Block count: 488379968
    Reserved block count: 488379
    Free blocks: 106448913
    Free inodes: 121612868
    First block: 0
    Block size: 4096
    Fragment size: 4096
    Reserved GDT blocks: 907
    Blocks per group: 32768
    Fragments per group: 32768
    Inodes per group: 8192
    Inode blocks per group: 512
    RAID stride: 16
    RAID stripe width: 32
    Filesystem created: Thu Oct 8 23:09:57 2009
    Last mount time: Mon Apr 2 10:19:36 2012
    Last write time: Fri Apr 6 19:15:06 2012
    Mount count: 13
    Maximum mount count: 38
    Last checked: Sun Oct 30 06:54:03 2011
    Check interval: 15552000 (6 months)
    Next check after: Fri Apr 27 06:54:03 2012
    Lifetime writes: 12 GB
    Reserved blocks uid: 0 (user root)
    Reserved blocks gid: 0 (group root)
    First inode: 11
    Inode size: 256
    Required extra isize: 28
    Desired extra isize: 28
    Journal inode: 8
    Default directory hash: half_md4
    Directory Hash Seed: 84ce591f-34ae-43d0-846c-d8dae91ef4b9
    Journal backup: inode blocks
    dumpe2fs: A block group is missing an inode table while reading journal inode
    # dumpe2fs /dev/sdc1
    dumpe2fs 1.42.1 (17-Feb-2012)
    dumpe2fs: Bad magic number in super-block while trying to open /dev/sdc1
    Couldn't find valid filesystem superblock.
    # dumpe2fs /dev/sdd1
    dumpe2fs 1.42.1 (17-Feb-2012)
    dumpe2fs: Filesystem revision too high while trying to open /dev/sdd1
    Couldn't find valid filesystem superblock.
    When I create the array I see the following from mdadm.  Which is expected as it sees the existing filesystem:
    # mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 --metadata=0.90 /dev/sdb1 /dev/sdc1 /dev/sdd1
    mdadm: layout defaults to left-symmetric
    mdadm: chunk size defaults to 512K
    mdadm: layout defaults to left-symmetric
    mdadm: /dev/sdb1 appears to contain an ext2fs file system
    size=1953519872K mtime=Mon Apr 2 10:19:36 2012
    mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sun Apr 8 10:01:02 2012
    mdadm: layout defaults to left-symmetric
    mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sun Apr 8 10:01:02 2012
    mdadm: layout defaults to left-symmetric
    mdadm: /dev/sdd1 appears to contain an ext2fs file system
    size=2066852100K mtime=Sat Apr 7 05:08:08 2029
    mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sun Apr 8 10:01:02 2012
    mdadm: size set to 976759808K
    Continue creating array? y
    mdadm: array /dev/md0 started.
    The raid array is created without issue:
    # cat /proc/mdstat
    Personalities : [raid6] [raid5] [raid4]
    md0 : active raid5 sdb1[0] sdd1[2] sdc1[1]
    1953519616 blocks level 5, 512k chunk, algorithm 2 [3/3] [UUU]
    # mdadm --detail /dev/md0
    /dev/md0:
    Version : 0.90
    Creation Time : Sun Apr 8 14:56:14 2012
    Raid Level : raid5
    Array Size : 1953519616 (1863.02 GiB 2000.40 GB)
    Used Dev Size : 976759808 (931.51 GiB 1000.20 GB)
    Raid Devices : 3
    Total Devices : 3
    Preferred Minor : 0
    Persistence : Superblock is persistent
    Update Time : Sun Apr 8 18:07:19 2012
    State : clean
    Active Devices : 3
    Working Devices : 3
    Failed Devices : 0
    Spare Devices : 0
    Layout : left-symmetric
    Chunk Size : 512K
    UUID : fe541eb6:764599e3:5d64d1b1:6d03292e (local to host jackshrimp)
    Events : 0.19
    Number Major Minor RaidDevice State
    0 8 17 0 active sync /dev/sdb1
    1 8 33 1 active sync /dev/sdc1
    2 8 49 2 active sync /dev/sdd1
    # mdadm --examine --scan
    ARRAY /dev/md0 UUID=00000000:00000000:00000000:00000000
    spares=1
    ARRAY /dev/md0 UUID=fe541eb6:764599e3:5d64d1b1:6d03292e
    This is how I originally created the filesystem on the array (back in 10/2009).  Here with "-n" to show the superblock locations:
    # mkfs.ext3 -n -v -m .1 -b 4096 /dev/md0
    mke2fs 1.42.1 (17-Feb-2012)
    fs_types for mke2fs.conf resolution: 'ext3'
    Filesystem label=
    OS type: Linux
    Block size=4096 (log=2)
    Fragment size=4096 (log=2)
    Stride=16 blocks, Stripe width=32 blocks
    122101760 inodes, 488379904 blocks
    488379 blocks (0.10%) reserved for the super user
    First data block=0
    Maximum filesystem blocks=0
    14905 block groups
    32768 blocks per group, 32768 fragments per group
    8192 inodes per group
    Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
    102400000, 214990848
    I've tried running e2fsck with (-b) each of those blocks and none worked.  Here is what I get from e2fsck:
    # e2fsck /dev/md0
    e2fsck 1.42.1 (17-Feb-2012)
    e2fsck: Group descriptors look bad... trying backup blocks...
    e2fsck: Filesystem revision too high when using the backup blocks
    e2fsck: going back to original superblock
    e2fsck: Group descriptors look bad... trying backup blocks...
    e2fsck: Filesystem revision too high when using the backup blocks
    e2fsck: going back to original superblock
    Superblock has an invalid journal (inode 8).
    Clear<y>? cancelled!
    e2fsck: Illegal inode number while checking ext3 journal for /dev/md0
    /dev/md0: ********** WARNING: Filesystem still has errors **********
    While I'm quite sure the data is still there I'm freaking out about letting fsck do anything!
    Should I let fsck do what it want to do?  Any thoughts on how I can recover this array?  Any suggestions on other things I should try?
    Thanks for any and all help. 

    Then it looks similar to bug 6651232
    May I suggest you get in touch with Oracle support for this?

  • Random system freezes with different errors in syslog

    Hi,
    my system freezes randomly within one to 5 days. I tried to google for the error messages, but I found very much results for e.g. "kernel: general protection fault" or nothing for e.g. find_inode_fast. Most of the time the errors seem for me to have to do with a hard drive, because:
    - the freeze is often shortly after rsnapshot ran (anachron daily job)
    - the word 'inode' in strack traces
    - (I think 'Comm' stands for 'command'?!) Comm is often something which works with a hard drive, e.g. rm, unrar, rsnapshot
    So I ran 'fsck' and 'badblocks -n' on my SSD and checked the SMART status of both SSD and external drive (backup disk). But there is all fine, no errors.
    I hope someone can point me in the right direction where the error can be.
    Here are the full logs from journalctl http://pastebin.com/LTynE1sM and this is a shrinked version:
    Mär 23 07:15:19 maxxgubbl kernel: NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [kswapd0:61]
    Mär 23 07:15:19 maxxgubbl kernel: Modules linked in: dm_crypt algif_skcipher af_alg dm_mod fuse xt_multiport iptable_filter ip_tables x_tables bnep bluetooth rfkill nls_iso8859_1 nls_cp437 vfat fat snd_hda_codec_realtek snd_hda_codec_generic coretemp snd_hda_codec_hdmi hwmon intel_rapl iosf_mbi iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul mxm_wmi glue_helper ablk_helper cryptd ses enclosure serio_raw psmouse joydev mousedev lpc_ich i2c_i801 i2c_hid evdev gpio_lynxpoint i2c_designware_platform thermal dw_dmac battery fan wmi 8250_dw i2c_designware_core dw_dmac_core spi_pxa2xx_platform mac_hid snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep e1000e snd_pcm snd_timer mei_me snd shpchp
    Mär 23 07:15:19 maxxgubbl kernel: ptp mei soundcore pps_core processor acpi_pad sch_fq_codel ext4 crc16 mbcache jbd2 hid_generic usbhid hid sd_mod uas usb_storage atkbd libps2 ahci libahci libata xhci_pci ehci_pci xhci_hcd ehci_hcd scsi_mod usbcore usb_common i8042 serio sdhci_acpi sdhci led_class mmc_core i915 button intel_gtt i2c_algo_bit video drm_kms_helper drm i2c_core
    Mär 23 07:15:19 maxxgubbl kernel: CPU: 3 PID: 61 Comm: kswapd0 Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:15:19 maxxgubbl kernel: Hardware name: Gigabyte Technology Co., Ltd. Z97X-SOC/Z97X-SOC-CF, BIOS F5 MX 01/29/2015
    Mär 23 07:15:19 maxxgubbl kernel: task: ffff8807fb7d13e0 ti: ffff8807fa380000 task.ti: ffff8807fa380000
    Mär 23 07:15:19 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca12>] [<ffffffff810bca12>] queue_write_lock_slowpath+0x62/0xa0
    *repeating message*
    Mär 23 07:15:47 maxxgubbl kernel: NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [kswapd0:61]
    Mär 23 07:15:47 maxxgubbl kernel: Modules linked in: dm_crypt algif_skcipher af_alg dm_mod fuse xt_multiport iptable_filter ip_tables x_tables bnep bluetooth rfkill nls_iso8859_1 nls_cp437 vfat fat snd_hda_codec_realtek snd_hda_codec_generic coretemp snd_hda_codec_hdmi hwmon intel_rapl iosf_mbi iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul mxm_wmi glue_helper ablk_helper cryptd ses enclosure serio_raw psmouse joydev mousedev lpc_ich i2c_i801 i2c_hid evdev gpio_lynxpoint i2c_designware_platform thermal dw_dmac battery fan wmi 8250_dw i2c_designware_core dw_dmac_core spi_pxa2xx_platform mac_hid snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep e1000e snd_pcm snd_timer mei_me snd shpchp
    Mär 23 07:15:47 maxxgubbl kernel: ptp mei soundcore pps_core processor acpi_pad sch_fq_codel ext4 crc16 mbcache jbd2 hid_generic usbhid hid sd_mod uas usb_storage atkbd libps2 ahci libahci libata xhci_pci ehci_pci xhci_hcd ehci_hcd scsi_mod usbcore usb_common i8042 serio sdhci_acpi sdhci led_class mmc_core i915 button intel_gtt i2c_algo_bit video drm_kms_helper drm i2c_core
    Mär 23 07:15:47 maxxgubbl kernel: CPU: 3 PID: 61 Comm: kswapd0 Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:15:47 maxxgubbl kernel: Hardware name: Gigabyte Technology Co., Ltd. Z97X-SOC/Z97X-SOC-CF, BIOS F5 MX 01/29/2015
    Mär 23 07:15:47 maxxgubbl kernel: task: ffff8807fb7d13e0 ti: ffff8807fa380000 task.ti: ffff8807fa380000
    Mär 23 07:15:47 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca14>] [<ffffffff810bca14>] queue_write_lock_slowpath+0x64/0xa0
    Mär 23 07:15:50 maxxgubbl kernel: general protection fault: 0000 [#1] PREEMPT SMP
    Mär 23 07:15:50 maxxgubbl kernel: Modules linked in: dm_crypt algif_skcipher af_alg dm_mod fuse xt_multiport iptable_filter ip_tables x_tables bnep bluetooth rfkill nls_iso8859_1 nls_cp437 vfat fat snd_hda_codec_realtek snd_hda_codec_generic coretemp snd_hda_codec_hdmi hwmon intel_rapl iosf_mbi iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul mxm_wmi glue_helper ablk_helper cryptd ses enclosure serio_raw psmouse joydev mousedev lpc_ich i2c_i801 i2c_hid evdev gpio_lynxpoint i2c_designware_platform thermal dw_dmac battery fan wmi 8250_dw i2c_designware_core dw_dmac_core spi_pxa2xx_platform mac_hid snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep e1000e snd_pcm snd_timer mei_me snd shpchp
    Mär 23 07:15:50 maxxgubbl kernel: ptp mei soundcore pps_core processor acpi_pad sch_fq_codel ext4 crc16 mbcache jbd2 hid_generic usbhid hid sd_mod uas usb_storage atkbd libps2 ahci libahci libata xhci_pci ehci_pci xhci_hcd ehci_hcd scsi_mod usbcore usb_common i8042 serio sdhci_acpi sdhci led_class mmc_core i915 button intel_gtt i2c_algo_bit video drm_kms_helper drm i2c_core
    Mär 23 07:15:50 maxxgubbl kernel: CPU: 0 PID: 29456 Comm: unrar Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:15:50 maxxgubbl kernel: task: ffff88035f8f8000 ti: ffff8800a03d4000 task.ti: ffff8800a03d4000
    Mär 23 07:15:50 maxxgubbl kernel: RIP: 0010:[<ffffffffa03d9ccd>] [<ffffffffa03d9ccd>] __es_shrink+0x8d/0x2c0 [ext4]
    Mär 23 07:15:50 maxxgubbl kernel: note: unrar[29456] exited with preempt_count 1
    Mär 30 09:12:01 maxxgubbl anacron[14204]: Job `cron.daily' started
    Mär 30 09:15:07 maxxgubbl kernel: BUG: unable to handle kernel paging request at ffffffffffffff6f
    Mär 30 09:15:07 maxxgubbl kernel: IP: [<ffffffff811ecac0>] find_inode_fast+0x50/0xb0
    Mär 30 09:15:07 maxxgubbl kernel: Modules linked in: snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device dm_crypt algif_skcipher af_alg dm_mod fuse xt_multiport iptable_filter ip_tables x_tables bnep bluetooth rfkill snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi iTCO_wdt iTCO_vendor_support nls_iso8859_1 nls_cp437 vfat fat coretemp hwmon intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel mxm_wmi aesni_intel aes_x86_64 serio_raw lrw gf128mul psmouse glue_helper ablk_helper cryptd mousedev joydev lpc_ich i2c_i801 i2c_hid dw_dmac i2c_designware_platform gpio_lynxpoint thermal evdev fan battery i2c_designware_core dw_dmac_core wmi 8250_dw spi_pxa2xx_platform mac_hid snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep
    Mär 30 09:15:07 maxxgubbl kernel: snd_pcm e1000e snd_timer snd mei_me mei ptp soundcore shpchp pps_core acpi_pad processor sch_fq_codel ext4 crc16 mbcache jbd2 ses enclosure hid_generic usbhid hid sd_mod uas usb_storage atkbd libps2 ahci libahci libata xhci_pci ehci_pci xhci_hcd ehci_hcd scsi_mod usbcore usb_common i8042 serio sdhci_acpi sdhci led_class mmc_core i915 button intel_gtt i2c_algo_bit video drm_kms_helper drm i2c_core
    Mär 30 09:15:07 maxxgubbl kernel: CPU: 3 PID: 31657 Comm: rm Not tainted 3.19.2-1-ARCH #1
    Mär 30 09:15:07 maxxgubbl kernel: RIP: 0010:[<ffffffff811ecac0>] [<ffffffff811ecac0>] find_inode_fast+0x50/0xb0
    Mär 30 09:15:07 maxxgubbl kernel: RIP [<ffffffff811ecac0>] find_inode_fast+0x50/0xb0
    Apr 06 16:01:01 maxxgubbl crond[29831]: pam_unix(crond:session): session opened for user root by (uid=0)
    Apr 06 16:01:01 maxxgubbl CROND[29832]: (root) CMD (run-parts /etc/cron.hourly)
    Apr 06 16:01:01 maxxgubbl CROND[29831]: pam_unix(crond:session): session closed for user root
    Apr 06 16:01:20 maxxgubbl kernel: general protection fault: 0000 [#1] PREEMPT SMP
    Apr 06 16:01:20 maxxgubbl kernel: Modules linked in: dm_crypt algif_skcipher af_alg dm_mod fuse xt_multiport iptable_filter ip_tables x_tables bnep bluetooth rfkill joydev mousedev snd_hda_codec_realtek iTCO_wdt iTCO_vendor_support snd_hda_codec_generic snd_hda_codec_hdmi nls_iso8859_1 nls_cp437 vfat fat coretemp hwmon intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm mxm_wmi crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw serio_raw gf128mul glue_helper ablk_helper psmouse cryptd i2c_i801 shpchp lpc_ich i2c_hid dw_dmac fan thermal i2c_designware_platform battery dw_dmac_core i2c_designware_core wmi 8250_dw spi_pxa2xx_platform gpio_lynxpoint snd_hda_intel snd_hda_controller snd_hda_codec e1000e snd_hwdep snd_pcm snd_timer snd ptp pps_core mei_me soundcore
    Apr 06 16:01:20 maxxgubbl kernel: evdev mei ses mac_hid enclosure processor acpi_pad sch_fq_codel ext4 crc16 mbcache jbd2 hid_generic usbhid hid sd_mod uas usb_storage atkbd libps2 ahci libahci xhci_pci ehci_pci libata xhci_hcd ehci_hcd scsi_mod usbcore usb_common i8042 serio sdhci_acpi sdhci led_class mmc_core i915 button intel_gtt i2c_algo_bit video drm_kms_helper drm i2c_core
    Apr 06 16:01:20 maxxgubbl kernel: CPU: 0 PID: 29061 Comm: chrome Tainted: G B W 3.19.2-1-ARCH #1
    Apr 06 16:01:20 maxxgubbl kernel: RIP: 0010:[<ffffffff815623a0>] [<ffffffff815623a0>] _raw_spin_trylock+0x10/0x60
    Apr 06 16:01:20 maxxgubbl kernel: RIP [<ffffffff815623a0>] _raw_spin_trylock+0x10/0x60
    Apr 06 16:01:20 maxxgubbl kernel: note: chrome[29061] exited with preempt_count 2
    Apr 06 16:01:30 maxxgubbl kernel: Watchdog[19977]: segfault at 0 ip 00007feabed94716 sp 00007feaac91a7a0 error 6 in chrome[7feabaea7000+5153000]
    Apr 06 16:01:31 maxxgubbl systemd-coredump[30306]: Process 19965 (chrome) of user 1000 dumped core.
    Apr 06 16:01:40 maxxgubbl kernel: Watchdog[1135]: segfault at 0 ip 00007fa7a6a7d716 sp 00007fa7946037a0 error 6 in chrome[7fa7a2b90000+5153000]
    Apr 06 16:01:42 maxxgubbl systemd-coredump[30460]: Process 1125 (chrome) of user 1000 dumped core.
    Apr 08 07:38:35 maxxgubbl anacron[18833]: Job `cron.daily' started
    Apr 08 07:41:34 maxxgubbl kernel: general protection fault: 0000 [#1] PREEMPT SMP
    Apr 08 07:41:34 maxxgubbl kernel: Modules linked in: dm_crypt algif_skcipher af_alg dm_mod fuse xt_multiport iptable_filter ip_tables x_tables bnep bluetooth rfkill nls_iso8859_1 nls_cp437 snd_hda_codec_realtek vfat snd_hda_codec_generic fat coretemp snd_hda_codec_hdmi hwmon intel_rapl iosf_mbi x86_pkg_temp_thermal iTCO_wdt intel_powerclamp iTCO_vendor_support kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper mxm_wmi cryptd serio_raw psmouse i2c_i801 lpc_ich joydev i2c_hid mousedev spi_pxa2xx_platform dw_dmac thermal fan i2c_designware_platform battery wmi dw_dmac_core i2c_designware_core 8250_dw gpio_lynxpoint snd_hda_intel snd_hda_controller snd_hda_codec e1000e snd_hwdep snd_pcm snd_timer ptp snd pps_core shpchp mei_me mei soundcore
    Apr 08 07:41:34 maxxgubbl kernel: evdev processor mac_hid acpi_pad sch_fq_codel ext4 crc16 mbcache jbd2 ses enclosure hid_generic usbhid hid sd_mod uas usb_storage atkbd libps2 ahci libahci libata xhci_pci ehci_pci xhci_hcd ehci_hcd scsi_mod usbcore usb_common i8042 serio sdhci_acpi sdhci led_class mmc_core i915 button intel_gtt i2c_algo_bit video drm_kms_helper drm i2c_core
    Apr 08 07:41:34 maxxgubbl kernel: CPU: 1 PID: 31723 Comm: rsnapshot Not tainted 3.19.2-1-ARCH #1
    Apr 08 07:41:34 maxxgubbl kernel: RIP: 0010:[<ffffffff811eb168>] [<ffffffff811eb168>] __d_lookup_rcu+0xc8/0x160
    Apr 08 07:41:34 maxxgubbl kernel: RIP [<ffffffff811eb168>] __d_lookup_rcu+0xc8/0x160
    Apr 08 07:41:34 maxxgubbl anacron[18833]: Job `cron.daily' terminated (exit status: 1) (mailing output)
    Apr 08 07:41:34 maxxgubbl anacron[18833]: Can't find sendmail at /usr/sbin/sendmail, not mailing output
    Apr 08 07:41:34 maxxgubbl anacron[18833]: Normal exit (1 job run)
    Apr 08 07:41:51 maxxgubbl mopidy[4204]: INFO Loaded 60 Spotify playlists
    Apr 08 07:55:13 maxxgubbl kernel: Watchdog[8613]: segfault at 0 ip 00007f2158f5b716 sp 00007f2146ae17a0 error 6 in chrome[7f215506e000+5153000]
    Apr 08 07:55:14 maxxgubbl systemd-coredump[19176]: Process 8600 (chrome) of user 1000 dumped core.
    Apr 11 12:05:29 maxxgubbl kernel: general protection fault: 0000 [#1] PREEMPT SMP
    Apr 11 12:05:29 maxxgubbl kernel: Modules linked in: dm_crypt algif_skcipher af_alg dm_mod fuse xt_multiport iptable_filter ip_tables x_tables bnep bluetooth rfkill snd_hda_codec_realtek iTCO_wdt iTCO_vendor_support snd_hda_codec_generic snd_hda_codec_hdmi nls_iso8859_1 nls_cp437 vfat fat coretemp hwmon intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ses ghash_clmulni_intel mxm_wmi enclosure aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd serio_raw mousedev joydev psmouse i2c_i801 lpc_ich i2c_hid dw_dmac thermal i2c_designware_platform evdev battery wmi 8250_dw fan dw_dmac_core i2c_designware_core mac_hid spi_pxa2xx_platform gpio_lynxpoint snd_hda_intel snd_hda_controller e1000e snd_hda_codec snd_hwdep snd_pcm snd_timer mei_me ptp snd
    Apr 11 12:05:29 maxxgubbl kernel: pps_core mei shpchp soundcore processor acpi_pad sch_fq_codel ext4 crc16 mbcache jbd2 hid_generic usbhid hid sd_mod uas usb_storage atkbd libps2 ahci libahci libata xhci_pci ehci_pci xhci_hcd ehci_hcd scsi_mod usbcore usb_common i8042 serio sdhci_acpi sdhci led_class mmc_core i915 button intel_gtt i2c_algo_bit video drm_kms_helper drm i2c_core
    Apr 11 12:05:29 maxxgubbl kernel: CPU: 6 PID: 19333 Comm: tmux Not tainted 3.19.3-1-ARCH #1
    Apr 11 12:05:29 maxxgubbl kernel: RIP [<ffffffff811eb3d0>] __d_lookup+0x70/0x180
    Apr 11 12:05:47 maxxgubbl kernel: Watchdog[1324]: segfault at 0 ip 00007f408f31e716 sp 00007f407cea47a0 error 6 in chrome[7f408b431000+5153000]
    Apr 11 12:05:48 maxxgubbl systemd-coredump[19549]: Process 1314 (chrome) of user 1000 dumped core.
    Apr 11 12:06:29 maxxgubbl kernel: INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected by 4, t=18002 jiffies, g=951735, c=951734, q=136101)
    Apr 11 12:06:29 maxxgubbl kernel: INFO: Stall ended before state dump start
    *repeating message*
    Apr 11 12:27:29 maxxgubbl kernel: INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected by 5, t=396038 jiffies, g=951735, c=951734, q=2353156)
    Apr 11 12:27:29 maxxgubbl kernel: INFO: Stall ended before state dump start
    Apr 11 12:30:17 maxxgubbl kernel: general protection fault: 0000 [#2] PREEMPT SMP
    Apr 11 12:30:17 maxxgubbl kernel: Modules linked in: dm_crypt algif_skcipher af_alg dm_mod fuse xt_multiport iptable_filter ip_tables x_tables bnep bluetooth rfkill snd_hda_codec_realtek iTCO_wdt iTCO_vendor_support snd_hda_codec_generic snd_hda_codec_hdmi nls_iso8859_1 nls_cp437 vfat fat coretemp hwmon intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ses ghash_clmulni_intel mxm_wmi enclosure aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd serio_raw mousedev joydev psmouse i2c_i801 lpc_ich i2c_hid dw_dmac thermal i2c_designware_platform evdev battery wmi 8250_dw fan dw_dmac_core i2c_designware_core mac_hid spi_pxa2xx_platform gpio_lynxpoint snd_hda_intel snd_hda_controller e1000e snd_hda_codec snd_hwdep snd_pcm snd_timer mei_me ptp snd
    Apr 11 12:30:17 maxxgubbl kernel: pps_core mei shpchp soundcore processor acpi_pad sch_fq_codel ext4 crc16 mbcache jbd2 hid_generic usbhid hid sd_mod uas usb_storage atkbd libps2 ahci libahci libata xhci_pci ehci_pci xhci_hcd ehci_hcd scsi_mod usbcore usb_common i8042 serio sdhci_acpi sdhci led_class mmc_core i915 button intel_gtt i2c_algo_bit video drm_kms_helper drm i2c_core
    Apr 11 12:30:17 maxxgubbl kernel: CPU: 4 PID: 6405 Comm: tmux Tainted: G D 3.19.3-1-ARCH #1
    Apr 11 12:30:17 maxxgubbl kernel: RIP [<ffffffff811eb3d0>] __d_lookup+0x70/0x180
    Apr 11 12:30:29 maxxgubbl kernel: INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected by 3, t=450044 jiffies, g=951735, c=951734, q=2664999)
    Apr 11 12:30:29 maxxgubbl kernel: INFO: Stall ended before state dump start
    *repeating message*
    Apr 11 13:00:29 maxxgubbl kernel: INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected by 3, t=990097 jiffies, g=951735, c=951734, q=6531437)
    Apr 11 13:00:29 maxxgubbl kernel: INFO: Stall ended before state dump start
    Apr 14 14:01:01 maxxgubbl crond[4015]: pam_unix(crond:session): session opened for user root by (uid=0)
    Apr 14 14:01:01 maxxgubbl CROND[4016]: (root) CMD (run-parts /etc/cron.hourly)
    Apr 14 14:01:01 maxxgubbl CROND[4015]: pam_unix(crond:session): session closed for user root
    Apr 14 14:28:09 maxxgubbl kernel: BUG: unable to handle kernel paging request at fffffffffffffeff
    Apr 14 14:28:09 maxxgubbl kernel: IP: [<ffffffff811ec180>] __destroy_inode+0x60/0xe0
    Apr 14 14:28:09 maxxgubbl kernel: PGD 1814067 PUD 1816067 PMD 0
    Apr 14 14:28:09 maxxgubbl kernel: Oops: 0002 [#1] PREEMPT SMP
    Apr 14 14:28:09 maxxgubbl kernel: Modules linked in: dm_crypt algif_skcipher af_alg dm_mod fuse xt_multiport iptable_filter ip_tables x_tables bnep bluetooth rfkill snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi iTCO_wdt iTCO_vendor_support nls_iso8859_1 nls_cp437 vfat fat coretemp hwmon intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp kvm_intel mxm_wmi kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd serio_raw psmouse joydev i2c_i801 mousedev shpchp lpc_ich fan thermal i2c_hid i2c_designware_platform dw_dmac battery 8250_dw i2c_designware_core dw_dmac_core wmi gpio_lynxpoint spi_pxa2xx_platform snd_hda_intel snd_hda_controller e1000e snd_hda_codec snd_hwdep snd_pcm snd_timer snd mei_me ptp mei pps_core soundcore
    Apr 14 14:28:09 maxxgubbl kernel: evdev mac_hid acpi_pad processor sch_fq_codel ext4 crc16 mbcache jbd2 ses enclosure hid_generic usbhid hid sd_mod uas usb_storage atkbd libps2 ahci libahci libata xhci_pci ehci_pci xhci_hcd ehci_hcd scsi_mod usbcore usb_common i8042 serio sdhci_acpi sdhci led_class mmc_core i915 button intel_gtt i2c_algo_bit video drm_kms_helper drm i2c_core
    Apr 14 14:28:09 maxxgubbl kernel: CPU: 1 PID: 61 Comm: kswapd0 Not tainted 3.19.3-1-ARCH #1
    Apr 14 14:28:09 maxxgubbl kernel: RIP [<ffffffff811ec180>] __destroy_inode+0x60/0xe0
    Apr 14 14:28:21 maxxgubbl kernel: Watchdog[12299]: segfault at 0 ip 00007f688f8c7716 sp 00007f687d44d7a0 error 6 in chrome[7f688b9da000+5153000]
    Apr 14 14:28:21 maxxgubbl kernel: Watchdog[1354]: segfault at 0 ip 00007fda5557c716 sp 00007fda431027a0 error 6 in chrome[7fda5168f000+5153000]
    Apr 14 14:28:24 maxxgubbl systemd-coredump[2390]: Process 12287 (chrome) of user 1000 dumped core.
    Apr 14 14:28:25 maxxgubbl systemd-coredump[2391]: Process 1343 (chrome) of user 1000 dumped core.
    Apr 25 11:05:56 maxxgubbl udisks-daemon[5533]: **** Refreshing ATA SMART data for /sys/devices/pci0000:00/0000:00:1f.2/ata6/host5/target5:0:0/5:0:0:0/block/sdb
    Apr 25 11:05:56 maxxgubbl udisks-daemon[5533]: helper(pid 30331): launched job udisks-helper-ata-smart-collect on /dev/sdb
    Apr 25 11:05:56 maxxgubbl udisks-daemon[5533]: **** Refreshing ATA SMART data for /sys/devices/pci0000:00/0000:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block/sda
    Apr 25 11:05:56 maxxgubbl udisks-daemon[5533]: helper(pid 30332): launched job udisks-helper-ata-smart-collect on /dev/sda
    Apr 25 11:05:56 maxxgubbl udisks-daemon[5533]: helper(pid 30332): completed with exit code 2
    Apr 25 11:05:56 maxxgubbl udisks-daemon[5533]: helper(pid 30331): completed with exit code 0
    Apr 25 11:05:56 maxxgubbl udisks-daemon[5533]: **** EMITTING CHANGED for /sys/devices/pci0000:00/0000:00:1f.2/ata6/host5/target5:0:0/5:0:0:0/block/sdb
    Apr 25 11:35:56 maxxgubbl udisks-daemon[5533]: **** Refreshing ATA SMART data for /sys/devices/pci0000:00/0000:00:1f.2/ata6/host5/target5:0:0/5:0:0:0/block/sdb
    Apr 25 11:35:56 maxxgubbl udisks-daemon[5533]: helper(pid 10098): launched job udisks-helper-ata-smart-collect on /dev/sdb
    Apr 25 11:35:56 maxxgubbl udisks-daemon[5533]: **** Refreshing ATA SMART data for /sys/devices/pci0000:00/0000:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block/sda
    Apr 25 11:35:56 maxxgubbl udisks-daemon[5533]: helper(pid 10099): launched job udisks-helper-ata-smart-collect on /dev/sda
    Apr 25 11:35:56 maxxgubbl udisks-daemon[5533]: helper(pid 10098): completed with exit code 0
    Apr 25 11:35:56 maxxgubbl udisks-daemon[5533]: **** EMITTING CHANGED for /sys/devices/pci0000:00/0000:00:1f.2/ata6/host5/target5:0:0/5:0:0:0/block/sdb
    Apr 25 11:35:57 maxxgubbl udisks-daemon[5533]: helper(pid 10099): completed with exit code 0
    Apr 25 11:35:57 maxxgubbl udisks-daemon[5533]: **** EMITTING CHANGED for /sys/devices/pci0000:00/0000:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block/sda
    Apr 25 12:01:01 maxxgubbl crond[19968]: pam_unix(crond:session): session opened for user root by (uid=0)
    Apr 25 12:01:01 maxxgubbl CROND[19969]: (root) CMD (run-parts /etc/cron.hourly)
    Apr 25 12:01:01 maxxgubbl CROND[19968]: pam_unix(crond:session): session closed for user root
    Apr 25 12:05:56 maxxgubbl udisks-daemon[5533]: **** Refreshing ATA SMART data for /sys/devices/pci0000:00/0000:00:1f.2/ata6/host5/target5:0:0/5:0:0:0/block/sdb
    Apr 25 12:05:56 maxxgubbl udisks-daemon[5533]: helper(pid 21895): launched job udisks-helper-ata-smart-collect on /dev/sdb
    Apr 25 12:05:56 maxxgubbl udisks-daemon[5533]: **** Refreshing ATA SMART data for /sys/devices/pci0000:00/0000:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block/sda
    Apr 25 12:05:56 maxxgubbl udisks-daemon[5533]: helper(pid 21896): launched job udisks-helper-ata-smart-collect on /dev/sda
    Apr 25 12:05:56 maxxgubbl udisks-daemon[5533]: helper(pid 21895): completed with exit code 0
    Apr 25 12:05:56 maxxgubbl udisks-daemon[5533]: **** EMITTING CHANGED for /sys/devices/pci0000:00/0000:00:1f.2/ata6/host5/target5:0:0/5:0:0:0/block/sdb
    Apr 25 12:05:57 maxxgubbl udisks-daemon[5533]: helper(pid 21896): completed with exit code 0
    Apr 25 12:05:57 maxxgubbl udisks-daemon[5533]: **** EMITTING CHANGED for /sys/devices/pci0000:00/0000:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block/sda
    Apr 25 12:25:14 maxxgubbl kernel: ------------[ cut here ]------------
    Apr 25 12:25:14 maxxgubbl kernel: kernel BUG at fs/inode.c:509!
    Apr 25 12:25:14 maxxgubbl kernel: invalid opcode: 0000 [#1] PREEMPT SMP
    Apr 25 12:25:14 maxxgubbl kernel: Modules linked in: dm_crypt algif_skcipher af_alg dm_mod fuse xt_multiport iptable_filter ip_tables x_tables bnep bluetooth rfkill mousedev joydev nls_iso8859_1 nls_cp437 vfat fat iTCO_wdt iTCO_vendor_support coretemp hwmon intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel e1000e mxm_wmi aesni_intel aes_x86_64 lrw gf128mul glue_helper serio_raw ablk_helper mei_me cryptd ptp psmouse mei i2c_i801 lpc_ich pps_core shpchp battery wmi i2c_hid dw_dmac i2c_designware_platform dw_dmac_core gpio_lynxpoint i2c_designware_core 8250_dw spi_pxa2xx_platform snd_hda_codec_realtek acpi_pad fan snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore
    Apr 25 12:25:14 maxxgubbl kernel: evdev thermal mac_hid processor ses enclosure sch_fq_codel ext4 crc16 mbcache jbd2 hid_generic usbhid hid sd_mod uas usb_storage atkbd libps2 ahci libahci libata xhci_pci ehci_pci ehci_hcd xhci_hcd scsi_mod usbcore usb_common i8042 serio sdhci_acpi sdhci led_class mmc_core i915 button intel_gtt i2c_algo_bit video drm_kms_helper drm i2c_core
    Apr 25 12:25:14 maxxgubbl kernel: CPU: 2 PID: 61 Comm: kswapd0 Tainted: G W 3.19.3-3-ARCH #1
    Apr 25 12:25:14 maxxgubbl kernel: RIP [<ffffffff811ec728>] clear_inode+0x78/0xa0
    Apr 25 12:25:14 maxxgubbl kernel: note: kswapd0[61] exited with preempt_count 1
    Apr 25 12:35:56 maxxgubbl udisks-daemon[5533]: **** Refreshing ATA SMART data for /sys/devices/pci0000:00/0000:00:1f.2/ata6/host5/target5:0:0/5:0:0:0/block/sdb
    Apr 25 12:35:56 maxxgubbl udisks-daemon[5533]: helper(pid 807): launched job udisks-helper-ata-smart-collect on /dev/sdb
    Apr 25 12:35:56 maxxgubbl udisks-daemon[5533]: **** Refreshing ATA SMART data for /sys/devices/pci0000:00/0000:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block/sda
    Apr 25 12:35:56 maxxgubbl udisks-daemon[5533]: helper(pid 808): launched job udisks-helper-ata-smart-collect on /dev/sda
    Apr 25 12:35:56 maxxgubbl udisks-daemon[5533]: helper(pid 807): completed with exit code 0
    Apr 25 12:35:56 maxxgubbl udisks-daemon[5533]: **** EMITTING CHANGED for /sys/devices/pci0000:00/0000:00:1f.2/ata6/host5/target5:0:0/5:0:0:0/block/sdb
    Apr 25 12:35:56 maxxgubbl udisks-daemon[5533]: helper(pid 808): completed with exit code 0
    Apr 25 12:35:57 maxxgubbl udisks-daemon[5533]: **** EMITTING CHANGED for /sys/devices/pci0000:00/0000:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block/sda
    Apr 27 08:17:01 maxxgubbl anacron[32178]: Job `cron.daily' started
    Apr 27 08:27:24 maxxgubbl kernel: BUG: unable to handle kernel paging request at ffff88279caaf388
    Apr 27 08:27:24 maxxgubbl kernel: IP: [<ffffffff811e7bce>] d_lru_shrink_move+0x3e/0x90
    Apr 27 08:27:24 maxxgubbl kernel: PGD 1b32067 PUD 0
    Apr 27 08:27:24 maxxgubbl kernel: Oops: 0002 [#1] PREEMPT SMP
    Apr 27 08:27:24 maxxgubbl kernel: Modules linked in: dm_crypt algif_skcipher af_alg dm_mod fuse xt_multiport iptable_filter ip_tables x_tables bnep bluetooth rfkill snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi iTCO_wdt iTCO_vendor_support nls_iso8859_1 nls_cp437 vfat fat coretemp hwmon intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp kvm_intel mxm_wmi kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd serio_raw psmouse mousedev ses enclosure joydev i2c_i801 lpc_ich i2c_hid i2c_designware_platform fan thermal battery evdev dw_dmac 8250_dw i2c_designware_core wmi mac_hid dw_dmac_core spi_pxa2xx_platform gpio_lynxpoint acpi_pad snd_hda_intel snd_hda_controller snd_hda_codec e1000e snd_hwdep snd_pcm snd_timer snd
    Apr 27 08:27:24 maxxgubbl kernel: mei_me shpchp ptp soundcore mei pps_core processor sch_fq_codel ext4 crc16 mbcache jbd2 hid_generic usbhid hid sd_mod uas usb_storage atkbd libps2 ahci libahci libata xhci_pci ehci_pci xhci_hcd ehci_hcd scsi_mod usbcore usb_common i8042 serio sdhci_acpi sdhci led_class mmc_core i915 button intel_gtt i2c_algo_bit video drm_kms_helper drm i2c_core
    Apr 27 08:27:24 maxxgubbl kernel: CPU: 7 PID: 61 Comm: kswapd0 Not tainted 3.19.3-3-ARCH #1
    Apr 27 08:27:24 maxxgubbl kernel: RIP [<ffffffff811e7bce>] d_lru_shrink_move+0x3e/0x90
    Mai 03 08:21:28 maxxgubbl anacron[13822]: Job `cron.daily' started
    Mai 03 08:22:03 maxxgubbl kernel: BUG: unable to handle kernel paging request at 000000000000ff70
    Mai 03 08:22:03 maxxgubbl kernel: IP: [<ffffffff811ecc20>] find_inode_fast+0x50/0xb0
    Mai 03 08:22:03 maxxgubbl kernel: PGD bc1d1067 PUD bc1d0067 PMD 0
    Mai 03 08:22:03 maxxgubbl kernel: Oops: 0000 [#1] PREEMPT SMP
    Mai 03 08:22:03 maxxgubbl kernel: Modules linked in: dm_crypt algif_skcipher af_alg dm_mod fuse xt_multiport iptable_filter ip_tables x_tables bnep bluetooth rfkill iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi nls_iso8859_1 nls_cp437 vfat fat coretemp hwmon intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm mxm_wmi crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd serio_raw psmouse i2c_i801 lpc_ich joydev i2c_hid dw_dmac mousedev fan dw_dmac_core i2c_designware_platform battery wmi 8250_dw i2c_designware_core gpio_lynxpoint spi_pxa2xx_platform thermal snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm e1000e snd_timer snd soundcore mei_me mei ptp shpchp pps_core
    Mai 03 08:22:03 maxxgubbl kernel: evdev mac_hid acpi_pad processor sch_fq_codel ext4 crc16 mbcache jbd2 ses enclosure hid_generic usbhid hid sd_mod uas usb_storage atkbd libps2 ahci libahci xhci_pci libata ehci_pci xhci_hcd ehci_hcd scsi_mod usbcore usb_common i8042 serio sdhci_acpi sdhci led_class mmc_core i915 button intel_gtt i2c_algo_bit video drm_kms_helper drm i2c_core
    Mai 03 08:22:03 maxxgubbl kernel: CPU: 4 PID: 22260 Comm: rm Not tainted 3.19.3-3-ARCH #1
    Mai 03 08:22:03 maxxgubbl kernel: RIP [<ffffffff811ecc20>] find_inode_fast+0x50/0xb0
    Mai 04 08:31:49 maxxgubbl systemd-journal[181]: Missed 15768 kernel messages
    Mai 04 08:31:49 maxxgubbl kernel: b_state=0x04000029, b_size=4096
    Mai 04 08:31:49 maxxgubbl systemd-journal[181]: Missed 1922 kernel messages
    Mai 04 08:31:49 maxxgubbl kernel: b_state=0x04000029, b_size=4096
    Mai 04 08:31:49 maxxgubbl systemd-journal[181]: Missed 164 kernel messages
    Mai 04 08:31:49 maxxgubbl kernel: b_state=0x04000029, b_size=4096
    Mai 04 08:31:49 maxxgubbl systemd-journal[181]: Missed 2306 kernel messages
    Mai 04 08:31:49 maxxgubbl kernel: b_state=0x04000029, b_size=4096
    Mai 04 08:31:49 maxxgubbl systemd-journal[181]: Missed 145 kernel messages
    Mai 04 08:31:49 maxxgubbl kernel: __find_get_block_slow() failed. block=30942730, b_blocknr=17592216987146
    *repeating message*
    Mai 04 09:01:48 maxxgubbl systemd-journal[181]: Missed 241124 kernel messages
    Mai 04 09:01:48 maxxgubbl kernel: __find_get_block_slow() failed. block=30942730, b_blocknr=17592216987146
    Mai 04 09:01:49 maxxgubbl systemd-journal[181]: Missed 1588413 kernel messages
    Mai 04 09:01:49 maxxgubbl kernel: b_state=0x04000029, b_size=4096
    Mai 04 09:01:49 maxxgubbl systemd-journal[181]: Missed 234584 kernel messages
    Mai 04 09:01:49 maxxgubbl systemd-journal[181]: Missed 311481 kernel messages
    Mai 04 09:01:49 maxxgubbl kernel: __find_get_block_slow() failed. block=30942730, b_blocknr=17592216987146
    Mai 04 09:01:49 maxxgubbl systemd-journal[181]: Missed 23095 kernel messages
    Mai 04 09:01:49 maxxgubbl kernel: __find_get_block_slow() failed. block=30942730, b_blocknr=17592216987146
    # sdb3 is root partition on SSD and not full, 47GB free of 219GB
    lsblk:
    NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
    sda 8:0 0 931,5G 0 disk
    ├─sda1 8:1 0 488,3G 0 part
    │ └─jd 254:0 0 488,3G 0 crypt /home/hoschi/jd
    └─sda2 8:2 0 443,2G 0 part
    sdb 8:16 0 238,5G 0 disk
    ├─sdb1 8:17 0 512M 0 part /boot
    ├─sdb2 8:18 0 16G 0 part [SWAP]
    └─sdb3 8:19 0 222G 0 part /
    sdc 8:32 0 2,7T 0 disk
    └─sdc1 8:33 0 2,7T 0 part /home/hoschi/backup
    fstab:
    # /etc/fstab: static file system information
    # <file system> <dir> <type> <options> <dump> <pass>
    # /dev/sda1
    UUID=C804-1171 /boot vfat rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 2
    # /dev/sda3
    UUID=e20a6a61-42d1-48f2-b284-b3731cc41d68 / ext4 rw,noatime,data=ordered 0 1
    # /dev/sda2
    UUID=00e67419-7d79-4b9a-a58d-a3d7e4073d1c none swap defaults 0 0
    # backup
    UUID=f370cec6-2e81-458f-8ee5-0be15998b2ab /home/hoschi/backup ext4 defaults 0 2
    uname -a: Linux maxxgubbl 3.19.3-3-ARCH #1 SMP PREEMPT Wed Apr 8 14:10:00 CEST 2015 x86_64 GNU/Linux

    Thanks ashleygc! Through your post I read about microcodes which wasn't enabled on my system. Now I did that, because the wiki article said it increases stabillity. It seems there were installed for my CPU:
    ~ > dmesg | grep microcode
    [ 0.000000] CPU0 microcode updated early to revision 0x1c, date = 2014-07-03
    [ 0.095908] CPU1 microcode updated early to revision 0x1c, date = 2014-07-03
    [ 0.117050] CPU2 microcode updated early to revision 0x1c, date = 2014-07-03
    [ 0.138181] CPU3 microcode updated early to revision 0x1c, date = 2014-07-03
    [ 0.365317] microcode: CPU0 sig=0x306c3, pf=0x2, revision=0x1c
    [ 0.365320] microcode: CPU1 sig=0x306c3, pf=0x2, revision=0x1c
    [ 0.365324] microcode: CPU2 sig=0x306c3, pf=0x2, revision=0x1c
    [ 0.365328] microcode: CPU3 sig=0x306c3, pf=0x2, revision=0x1c
    [ 0.365332] microcode: CPU4 sig=0x306c3, pf=0x2, revision=0x1c
    [ 0.365336] microcode: CPU5 sig=0x306c3, pf=0x2, revision=0x1c
    [ 0.365339] microcode: CPU6 sig=0x306c3, pf=0x2, revision=0x1c
    [ 0.365343] microcode: CPU7 sig=0x306c3, pf=0x2, revision=0x1c
    [ 0.365371] microcode: Microcode Update Driver: v2.00 <[email protected]>, Peter Oruba
    Here are logs you mentioned:
    grep ' kernel: IP: ' /tmp/journal | less
    Mär 30 09:15:07 maxxgubbl kernel: IP: [<ffffffff811ecac0>] find_inode_fast+0x50/0xb0
    Apr 14 14:28:09 maxxgubbl kernel: IP: [<ffffffff811ec180>] __destroy_inode+0x60/0xe0
    Apr 27 08:27:24 maxxgubbl kernel: IP: [<ffffffff811e7bce>] d_lru_shrink_move+0x3e/0x90
    Mai 03 08:22:03 maxxgubbl kernel: IP: [<ffffffff811ecc20>] find_inode_fast+0x50/0xb0
    Mai 08 16:10:11 maxxgubbl kernel: IP: [<ffffffff81182063>] list_lru_walk_node+0xa3/0x190
    Mai 13 09:07:36 maxxgubbl kernel: IP: [<ffffffff811e9426>] __dentry_kill+0xf6/0x200
    Jun 04 11:14:22 maxxgubbl kernel: IP: [<ffffffff811f3998>] find_inode_fast+0x48/0xb0
    grep ' kernel: RIP: ' /tmp/journal | less
    Mär 23 07:07:23 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca14>] [<ffffffff810bca14>] queue_write_lock_slowpath+0x64/0xa0
    Mär 23 07:07:51 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca12>] [<ffffffff810bca12>] queue_write_lock_slowpath+0x62/0xa0
    Mär 23 07:08:19 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca14>] [<ffffffff810bca14>] queue_write_lock_slowpath+0x64/0xa0
    Mär 23 07:08:47 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca14>] [<ffffffff810bca14>] queue_write_lock_slowpath+0x64/0xa0
    Mär 23 07:09:15 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca14>] [<ffffffff810bca14>] queue_write_lock_slowpath+0x64/0xa0
    Mär 23 07:09:43 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca14>] [<ffffffff810bca14>] queue_write_lock_slowpath+0x64/0xa0
    Mär 23 07:10:11 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca12>] [<ffffffff810bca12>] queue_write_lock_slowpath+0x62/0xa0
    Mär 23 07:10:39 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca14>] [<ffffffff810bca14>] queue_write_lock_slowpath+0x64/0xa0
    Mär 23 07:11:07 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca12>] [<ffffffff810bca12>] queue_write_lock_slowpath+0x62/0xa0
    Mär 23 07:11:35 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca14>] [<ffffffff810bca14>] queue_write_lock_slowpath+0x64/0xa0
    Mär 23 07:12:03 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca12>] [<ffffffff810bca12>] queue_write_lock_slowpath+0x62/0xa0
    Mär 23 07:12:31 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca14>] [<ffffffff810bca14>] queue_write_lock_slowpath+0x64/0xa0
    Mär 23 07:12:59 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca14>] [<ffffffff810bca14>] queue_write_lock_slowpath+0x64/0xa0
    Mär 23 07:13:27 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca14>] [<ffffffff810bca14>] queue_write_lock_slowpath+0x64/0xa0
    Mär 23 07:13:55 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca10>] [<ffffffff810bca10>] queue_write_lock_slowpath+0x60/0xa0
    Mär 23 07:14:23 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca12>] [<ffffffff810bca12>] queue_write_lock_slowpath+0x62/0xa0
    Mär 23 07:14:51 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca10>] [<ffffffff810bca10>] queue_write_lock_slowpath+0x60/0xa0
    Mär 23 07:15:19 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca12>] [<ffffffff810bca12>] queue_write_lock_slowpath+0x62/0xa0
    Mär 23 07:15:47 maxxgubbl kernel: RIP: 0010:[<ffffffff810bca14>] [<ffffffff810bca14>] queue_write_lock_slowpath+0x64/0xa0
    Mär 23 07:15:50 maxxgubbl kernel: RIP: 0010:[<ffffffffa03d9ccd>] [<ffffffffa03d9ccd>] __es_shrink+0x8d/0x2c0 [ext4]
    Mär 30 09:15:07 maxxgubbl kernel: RIP: 0010:[<ffffffff811ecac0>] [<ffffffff811ecac0>] find_inode_fast+0x50/0xb0
    Apr 06 16:01:20 maxxgubbl kernel: RIP: 0010:[<ffffffff815623a0>] [<ffffffff815623a0>] _raw_spin_trylock+0x10/0x60
    Apr 08 07:41:34 maxxgubbl kernel: RIP: 0010:[<ffffffff811eb168>] [<ffffffff811eb168>] __d_lookup_rcu+0xc8/0x160
    Apr 11 12:05:29 maxxgubbl kernel: RIP: 0010:[<ffffffff811eb3d0>] [<ffffffff811eb3d0>] __d_lookup+0x70/0x180
    Apr 11 12:30:17 maxxgubbl kernel: RIP: 0010:[<ffffffff811eb3d0>] [<ffffffff811eb3d0>] __d_lookup+0x70/0x180
    Apr 14 14:28:09 maxxgubbl kernel: RIP: 0010:[<ffffffff811ec180>] [<ffffffff811ec180>] __destroy_inode+0x60/0xe0
    Apr 25 12:25:14 maxxgubbl kernel: RIP: 0010:[<ffffffff811ec728>] [<ffffffff811ec728>] clear_inode+0x78/0xa0
    Apr 27 08:27:24 maxxgubbl kernel: RIP: 0010:[<ffffffff811e7bce>] [<ffffffff811e7bce>] d_lru_shrink_move+0x3e/0x90
    Mai 03 08:22:03 maxxgubbl kernel: RIP: 0010:[<ffffffff811ecc20>] [<ffffffff811ecc20>] find_inode_fast+0x50/0xb0
    Mai 07 09:45:45 maxxgubbl kernel: RIP: 0010:[<ffffffff810f1dd6>] [<ffffffff810f1dd6>] smp_call_function_many+0x216/0x270
    Mai 07 09:46:13 maxxgubbl kernel: RIP: 0010:[<ffffffff810f1dd2>] [<ffffffff810f1dd2>] smp_call_function_many+0x212/0x270
    Mai 07 09:46:41 maxxgubbl kernel: RIP: 0010:[<ffffffff810f1dd6>] [<ffffffff810f1dd6>] smp_call_function_many+0x216/0x270
    Mai 07 09:47:09 maxxgubbl kernel: RIP: 0010:[<ffffffff810f1dd6>] [<ffffffff810f1dd6>] smp_call_function_many+0x216/0x270
    Mai 07 09:47:37 maxxgubbl kernel: RIP: 0010:[<ffffffff810f1dd6>] [<ffffffff810f1dd6>] smp_call_function_many+0x216/0x270
    Mai 08 16:10:11 maxxgubbl kernel: RIP: 0010:[<ffffffff81182063>] [<ffffffff81182063>] list_lru_walk_node+0xa3/0x190
    Mai 13 09:07:36 maxxgubbl kernel: RIP: 0010:[<ffffffff811e9426>] [<ffffffff811e9426>] __dentry_kill+0xf6/0x200
    Mai 22 09:17:48 maxxgubbl kernel: RIP: 0010:[<ffffffff8116d1db>] [<ffffffff8116d1db>] page_evictable+0x1b/0x40
    Jun 04 11:14:22 maxxgubbl kernel: RIP: 0010:[<ffffffff811f3998>] [<ffffffff811f3998>] find_inode_fast+0x48/0xb0
    grep -A1 'Call Trace' /tmp/journal | grep 0x | less
    Mär 18 09:33:39 maxxgubbl kernel: [<ffffffff8154fb74>] dump_stack+0x4e/0x71
    Mär 18 09:33:39 maxxgubbl kernel: [<ffffffff8154fb74>] dump_stack+0x4e/0x71
    Mär 23 07:07:23 maxxgubbl kernel: [<ffffffff815622c9>] _raw_write_lock+0x29/0x30
    Mär 23 07:07:51 maxxgubbl kernel: [<ffffffff815622c9>] _raw_write_lock+0x29/0x30
    Mär 23 07:08:19 maxxgubbl kernel: [<ffffffff815622c9>] _raw_write_lock+0x29/0x30
    Mär 23 07:08:47 maxxgubbl kernel: [<ffffffff815622c9>] _raw_write_lock+0x29/0x30
    Mär 23 07:09:15 maxxgubbl kernel: [<ffffffff815622c9>] _raw_write_lock+0x29/0x30
    Mär 23 07:09:43 maxxgubbl kernel: [<ffffffff815622c9>] _raw_write_lock+0x29/0x30
    Mär 23 07:10:11 maxxgubbl kernel: [<ffffffff815622c9>] _raw_write_lock+0x29/0x30
    Mär 23 07:10:39 maxxgubbl kernel: [<ffffffff815622c9>] _raw_write_lock+0x29/0x30
    Mär 23 07:11:07 maxxgubbl kernel: [<ffffffff815622c9>] _raw_write_lock+0x29/0x30
    Mär 23 07:11:35 maxxgubbl kernel: [<ffffffff815622c9>] _raw_write_lock+0x29/0x30
    Mär 23 07:12:03 maxxgubbl kernel: [<ffffffff815622c9>] _raw_write_lock+0x29/0x30
    Mär 23 07:12:31 maxxgubbl kernel: [<ffffffff815622c9>] _raw_write_lock+0x29/0x30
    Mär 23 07:12:59 maxxgubbl kernel: [<ffffffff815622c9>] _raw_write_lock+0x29/0x30
    Mär 23 07:13:27 maxxgubbl kernel: [<ffffffff815622c9>] _raw_write_lock+0x29/0x30
    Mär 23 07:13:55 maxxgubbl kernel: [<ffffffff815622c9>] _raw_write_lock+0x29/0x30
    Mär 23 07:14:23 maxxgubbl kernel: [<ffffffff815622c9>] _raw_write_lock+0x29/0x30
    Mär 23 07:14:51 maxxgubbl kernel: [<ffffffff815622c9>] _raw_write_lock+0x29/0x30
    Mär 23 07:15:19 maxxgubbl kernel: [<ffffffff815622c9>] _raw_write_lock+0x29/0x30
    Mär 23 07:15:47 maxxgubbl kernel: [<ffffffff815622c9>] _raw_write_lock+0x29/0x30
    Mär 23 07:15:50 maxxgubbl kernel: [<ffffffffa03da2bd>] ext4_es_scan+0xcd/0x150 [ext4]
    Mär 30 09:15:07 maxxgubbl kernel: [<ffffffff811ed745>] iget_locked+0x75/0x180
    Mär 31 13:35:03 maxxgubbl kernel: <IRQ> [<ffffffff8155cfdf>] dump_stack+0x4c/0x6e
    Apr 05 14:20:13 maxxgubbl kernel: [<ffffffff8155cfdf>] dump_stack+0x4c/0x6e
    Apr 06 08:55:00 maxxgubbl kernel: [<ffffffff8155cfdf>] dump_stack+0x4c/0x6e
    Apr 06 08:55:01 maxxgubbl kernel: [<ffffffff8155cfdf>] dump_stack+0x4c/0x6e
    Apr 06 14:51:53 maxxgubbl kernel: <IRQ> [<ffffffff8155cfdf>] dump_stack+0x4c/0x6e
    Apr 06 16:01:20 maxxgubbl kernel: [<ffffffff811e9a20>] shrink_dentry_list+0x60/0x330
    Apr 08 07:41:34 maxxgubbl kernel: [<ffffffff811dde73>] lookup_fast+0x53/0x300
    Apr 09 14:30:28 maxxgubbl kernel: [<ffffffff8155d19f>] dump_stack+0x4c/0x6e
    Apr 10 07:31:45 maxxgubbl kernel: <IRQ> [<ffffffff8155d19f>] dump_stack+0x4c/0x6e
    Apr 11 12:05:29 maxxgubbl kernel: [<ffffffff8123ff30>] ? tid_fd_revalidate+0x1f0/0x1f0
    Apr 11 12:30:17 maxxgubbl kernel: [<ffffffff8123ff30>] ? tid_fd_revalidate+0x1f0/0x1f0
    Apr 14 14:28:09 maxxgubbl kernel: [<ffffffff811ed3f6>] destroy_inode+0x26/0x70
    Apr 22 14:45:57 maxxgubbl kernel: <IRQ> [<ffffffff8155d19f>] dump_stack+0x4c/0x6e
    Apr 25 12:25:14 maxxgubbl kernel: [<ffffffffa03bae2e>] ext4_clear_inode+0x1e/0x90 [ext4]
    Apr 27 08:27:24 maxxgubbl kernel: [<ffffffff811e7dec>] dentry_lru_isolate+0x7c/0x100
    Mai 03 08:22:03 maxxgubbl kernel: [<ffffffff811ed8a5>] iget_locked+0x75/0x180
    Mai 07 09:45:01 maxxgubbl kernel: <NMI> [<ffffffff8155d19f>] dump_stack+0x4c/0x6e
    Mai 07 09:45:01 maxxgubbl kernel: [<ffffffffa03dd517>] ? ext4_es_free_extent+0x97/0x130 [ext4]
    Mai 07 09:45:45 maxxgubbl kernel: [<ffffffff81068970>] ? flush_tlb_func+0x1b0/0x1b0
    Mai 07 09:46:13 maxxgubbl kernel: [<ffffffff81068970>] ? flush_tlb_func+0x1b0/0x1b0
    Mai 07 09:46:41 maxxgubbl kernel: [<ffffffff81068970>] ? flush_tlb_func+0x1b0/0x1b0
    Mai 07 09:47:09 maxxgubbl kernel: [<ffffffff81068970>] ? flush_tlb_func+0x1b0/0x1b0
    Mai 07 09:47:37 maxxgubbl kernel: [<ffffffff81068970>] ? flush_tlb_func+0x1b0/0x1b0
    Mai 07 09:48:01 maxxgubbl kernel: [<ffffffffa03dd517>] ? ext4_es_free_extent+0x97/0x130 [ext4]
    Mai 08 16:10:11 maxxgubbl kernel: [<ffffffff811eab1b>] prune_dcache_sb+0x4b/0x80
    Mai 13 09:07:36 maxxgubbl kernel: [<ffffffff811e9bff>] shrink_dentry_list+0xdf/0x330
    Mai 13 14:43:43 maxxgubbl kernel: <IRQ> [<ffffffff8155d19f>] dump_stack+0x4c/0x6e
    Mai 21 14:31:48 maxxgubbl kernel: [<ffffffff8155d19f>] dump_stack+0x4c/0x6e
    Mai 22 09:17:48 maxxgubbl kernel: [<ffffffff8116d43e>] shrink_page_list+0x18e/0xb20
    Mai 22 15:07:01 maxxgubbl kernel: <IRQ> [<ffffffff8155d19f>] dump_stack+0x4c/0x6e
    Mai 30 12:56:10 maxxgubbl kernel: [<ffffffff81574b23>] dump_stack+0x4c/0x6e
    Mai 30 19:34:39 maxxgubbl kernel: [<ffffffff81576707>] schedule+0x37/0x90
    Mai 31 14:51:16 maxxgubbl kernel: <IRQ> [<ffffffff81574b23>] dump_stack+0x4c/0x6e
    Jun 04 11:14:22 maxxgubbl kernel: [<ffffffff811f46a2>] iget_locked+0x72/0x190
    Jun 05 14:33:06 maxxgubbl kernel: <IRQ> [<ffffffff81574b23>] dump_stack+0x4c/0x6e
    grep Tainted /tmp/journal | less
    Mär 18 09:33:39 maxxgubbl kernel: CPU: 1 PID: 4506 Comm: kworker/u16:37 Tainted: G W 3.18.6-1-ARCH #1
    Mär 23 07:07:51 maxxgubbl kernel: CPU: 3 PID: 61 Comm: kswapd0 Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:08:19 maxxgubbl kernel: CPU: 3 PID: 61 Comm: kswapd0 Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:08:47 maxxgubbl kernel: CPU: 3 PID: 61 Comm: kswapd0 Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:09:15 maxxgubbl kernel: CPU: 3 PID: 61 Comm: kswapd0 Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:09:43 maxxgubbl kernel: CPU: 3 PID: 61 Comm: kswapd0 Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:10:11 maxxgubbl kernel: CPU: 3 PID: 61 Comm: kswapd0 Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:10:39 maxxgubbl kernel: CPU: 3 PID: 61 Comm: kswapd0 Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:11:07 maxxgubbl kernel: CPU: 3 PID: 61 Comm: kswapd0 Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:11:35 maxxgubbl kernel: CPU: 3 PID: 61 Comm: kswapd0 Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:12:03 maxxgubbl kernel: CPU: 3 PID: 61 Comm: kswapd0 Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:12:31 maxxgubbl kernel: CPU: 3 PID: 61 Comm: kswapd0 Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:12:59 maxxgubbl kernel: CPU: 3 PID: 61 Comm: kswapd0 Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:13:27 maxxgubbl kernel: CPU: 3 PID: 61 Comm: kswapd0 Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:13:55 maxxgubbl kernel: CPU: 3 PID: 61 Comm: kswapd0 Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:14:23 maxxgubbl kernel: CPU: 3 PID: 61 Comm: kswapd0 Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:14:51 maxxgubbl kernel: CPU: 3 PID: 61 Comm: kswapd0 Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:15:19 maxxgubbl kernel: CPU: 3 PID: 61 Comm: kswapd0 Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:15:47 maxxgubbl kernel: CPU: 3 PID: 61 Comm: kswapd0 Tainted: G L 3.19.2-1-ARCH #1
    Mär 23 07:15:50 maxxgubbl kernel: CPU: 0 PID: 29456 Comm: unrar Tainted: G L 3.19.2-1-ARCH #1
    Apr 06 08:55:00 maxxgubbl kernel: CPU: 3 PID: 21393 Comm: rsync Tainted: G W 3.19.2-1-ARCH #1
    Apr 06 08:55:01 maxxgubbl kernel: CPU: 4 PID: 21392 Comm: rsync Tainted: G B W 3.19.2-1-ARCH #1
    Apr 06 14:51:53 maxxgubbl kernel: CPU: 0 PID: 0 Comm: swapper/0 Tainted: G B W 3.19.2-1-ARCH #1
    Apr 06 16:01:20 maxxgubbl kernel: CPU: 0 PID: 29061 Comm: chrome Tainted: G B W 3.19.2-1-ARCH #1
    Apr 11 12:30:17 maxxgubbl kernel: CPU: 4 PID: 6405 Comm: tmux Tainted: G D 3.19.3-1-ARCH #1
    Apr 25 12:25:14 maxxgubbl kernel: CPU: 2 PID: 61 Comm: kswapd0 Tainted: G W 3.19.3-3-ARCH #1
    Mai 07 09:45:45 maxxgubbl kernel: CPU: 0 PID: 393 Comm: Xorg Tainted: G W 3.19.3-3-ARCH #1
    Mai 07 09:46:13 maxxgubbl kernel: CPU: 0 PID: 393 Comm: Xorg Tainted: G W L 3.19.3-3-ARCH #1
    Mai 07 09:46:41 maxxgubbl kernel: CPU: 0 PID: 393 Comm: Xorg Tainted: G W L 3.19.3-3-ARCH #1
    Mai 07 09:47:09 maxxgubbl kernel: CPU: 0 PID: 393 Comm: Xorg Tainted: G W L 3.19.3-3-ARCH #1
    Mai 07 09:47:37 maxxgubbl kernel: CPU: 0 PID: 393 Comm: Xorg Tainted: G W L 3.19.3-3-ARCH #1
    Mai 21 14:31:48 maxxgubbl kernel: CPU: 1 PID: 10825 Comm: chrome Tainted: G W 3.19.3-3-ARCH #1
    Mai 22 09:17:48 maxxgubbl kernel: CPU: 2 PID: 61 Comm: kswapd0 Tainted: G B W 3.19.3-3-ARCH #1
    Mai 30 12:56:10 maxxgubbl kernel: CPU: 2 PID: 27047 Comm: WorkerPool/8042 Tainted: G O 4.0.4-2-ARCH #1
    Mai 31 14:51:16 maxxgubbl kernel: CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.0.4-2-ARCH #1
    Jun 04 11:14:22 maxxgubbl kernel: CPU: 0 PID: 27867 Comm: duplicity Tainted: G O 4.0.4-2-ARCH #1
    Jun 05 14:33:06 maxxgubbl kernel: CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.0.4-2-ARCH #1
    grep 'kernel: Code:' /tmp/journal | less
    Mär 23 07:07:23 maxxgubbl kernel: Code: 1f 84 00 00 00 00 00 f3 90 8b 17 84 d2 75 f8 89 d1 89 d0 83 c9 01 f0 0f b1 0f 39 d0 75 e9 ba ff 00 00 00 eb 04 66 90 f3 90 8b 07 <83> f8 01 75 f7 f0 0f b1 17 83 f8 01 75 ee eb bc b8 00 80 00 00
    Mär 23 07:07:51 maxxgubbl kernel: Code: 2e 0f 1f 84 00 00 00 00 00 f3 90 8b 17 84 d2 75 f8 89 d1 89 d0 83 c9 01 f0 0f b1 0f 39 d0 75 e9 ba ff 00 00 00 eb 04 66 90 f3 90 <8b> 07 83 f8 01 75 f7 f0 0f b1 17 83 f8 01 75 ee eb bc b8 00 80
    Mär 23 07:08:19 maxxgubbl kernel: Code: 1f 84 00 00 00 00 00 f3 90 8b 17 84 d2 75 f8 89 d1 89 d0 83 c9 01 f0 0f b1 0f 39 d0 75 e9 ba ff 00 00 00 eb 04 66 90 f3 90 8b 07 <83> f8 01 75 f7 f0 0f b1 17 83 f8 01 75 ee eb bc b8 00 80 00 00
    Mär 23 07:08:47 maxxgubbl kernel: Code: 1f 84 00 00 00 00 00 f3 90 8b 17 84 d2 75 f8 89 d1 89 d0 83 c9 01 f0 0f b1 0f 39 d0 75 e9 ba ff 00 00 00 eb 04 66 90 f3 90 8b 07 <83> f8 01 75 f7 f0 0f b1 17 83 f8 01 75 ee eb bc b8 00 80 00 00
    Mär 23 07:09:15 maxxgubbl kernel: Code: 1f 84 00 00 00 00 00 f3 90 8b 17 84 d2 75 f8 89 d1 89 d0 83 c9 01 f0 0f b1 0f 39 d0 75 e9 ba ff 00 00 00 eb 04 66 90 f3 90 8b 07 <83> f8 01 75 f7 f0 0f b1 17 83 f8 01 75 ee eb bc b8 00 80 00 00
    Mär 23 07:09:43 maxxgubbl kernel: Code: 1f 84 00 00 00 00 00 f3 90 8b 17 84 d2 75 f8 89 d1 89 d0 83 c9 01 f0 0f b1 0f 39 d0 75 e9 ba ff 00 00 00 eb 04 66 90 f3 90 8b 07 <83> f8 01 75 f7 f0 0f b1 17 83 f8 01 75 ee eb bc b8 00 80 00 00
    Mär 23 07:10:11 maxxgubbl kernel: Code: 2e 0f 1f 84 00 00 00 00 00 f3 90 8b 17 84 d2 75 f8 89 d1 89 d0 83 c9 01 f0 0f b1 0f 39 d0 75 e9 ba ff 00 00 00 eb 04 66 90 f3 90 <8b> 07 83 f8 01 75 f7 f0 0f b1 17 83 f8 01 75 ee eb bc b8 00 80
    Mär 23 07:10:39 maxxgubbl kernel: Code: 1f 84 00 00 00 00 00 f3 90 8b 17 84 d2 75 f8 89 d1 89 d0 83 c9 01 f0 0f b1 0f 39 d0 75 e9 ba ff 00 00 00 eb 04 66 90 f3 90 8b 07 <83> f8 01 75 f7 f0 0f b1 17 83 f8 01 75 ee eb bc b8 00 80 00 00
    Mär 23 07:11:07 maxxgubbl kernel: Code: 2e 0f 1f 84 00 00 00 00 00 f3 90 8b 17 84 d2 75 f8 89 d1 89 d0 83 c9 01 f0 0f b1 0f 39 d0 75 e9 ba ff 00 00 00 eb 04 66 90 f3 90 <8b> 07 83 f8 01 75 f7 f0 0f b1 17 83 f8 01 75 ee eb bc b8 00 80
    Mär 23 07:11:35 maxxgubbl kernel: Code: 1f 84 00 00 00 00 00 f3 90 8b 17 84 d2 75 f8 89 d1 89 d0 83 c9 01 f0 0f b1 0f 39 d0 75 e9 ba ff 00 00 00 eb 04 66 90 f3 90 8b 07 <83> f8 01 75 f7 f0 0f b1 17 83 f8 01 75 ee eb bc b8 00 80 00 00
    Mär 23 07:12:03 maxxgubbl kernel: Code: 2e 0f 1f 84 00 00 00 00 00 f3 90 8b 17 84 d2 75 f8 89 d1 89 d0 83 c9 01 f0 0f b1 0f 39 d0 75 e9 ba ff 00 00 00 eb 04 66 90 f3 90 <8b> 07 83 f8 01 75 f7 f0 0f b1 17 83 f8 01 75 ee eb bc b8 00 80
    Mär 23 07:12:31 maxxgubbl kernel: Code: 1f 84 00 00 00 00 00 f3 90 8b 17 84 d2 75 f8 89 d1 89 d0 83 c9 01 f0 0f b1 0f 39 d0 75 e9 ba ff 00 00 00 eb 04 66 90 f3 90 8b 07 <83> f8 01 75 f7 f0 0f b1 17 83 f8 01 75 ee eb bc b8 00 80 00 00
    Mär 23 07:12:59 maxxgubbl kernel: Code: 1f 84 00 00 00 00 00 f3 90 8b 17 84 d2 75 f8 89 d1 89 d0 83 c9 01 f0 0f b1 0f 39 d0 75 e9 ba ff 00 00 00 eb 04 66 90 f3 90 8b 07 <83> f8 01 75 f7 f0 0f b1 17 83 f8 01 75 ee eb bc b8 00 80 00 00
    Mär 23 07:13:27 maxxgubbl kernel: Code: 1f 84 00 00 00 00 00 f3 90 8b 17 84 d2 75 f8 89 d1 89 d0 83 c9 01 f0 0f b1 0f 39 d0 75 e9 ba ff 00 00 00 eb 04 66 90 f3 90 8b 07 <83> f8 01 75 f7 f0 0f b1 17 83 f8 01 75 ee eb bc b8 00 80 00 00
    Mär 23 07:13:55 maxxgubbl kernel: Code: c3 66 2e 0f 1f 84 00 00 00 00 00 f3 90 8b 17 84 d2 75 f8 89 d1 89 d0 83 c9 01 f0 0f b1 0f 39 d0 75 e9 ba ff 00 00 00 eb 04 66 90 <f3> 90 8b 07 83 f8 01 75 f7 f0 0f b1 17 83 f8 01 75 ee eb bc b8
    Mär 23 07:14:23 maxxgubbl kernel: Code: 2e 0f 1f 84 00 00 00 00 00 f3 90 8b 17 84 d2 75 f8 89 d1 89 d0 83 c9 01 f0 0f b1 0f 39 d0 75 e9 ba ff 00 00 00 eb 04 66 90 f3 90 <8b> 07 83 f8 01 75 f7 f0 0f b1 17 83 f8 01 75 ee eb bc b8 00 80
    Mär 23 07:14:51 maxxgubbl kernel: Code: c3 66 2e 0f 1f 84 00 00 00 00 00 f3 90 8b 17 84 d2 75 f8 89 d1 89 d0 83 c9 01 f0 0f b1 0f 39 d0 75 e9 ba ff 00 00 00 eb 04 66 90 <f3> 90 8b 07 83 f8 01 75 f7 f0 0f b1 17 83 f8 01 75 ee eb bc b8
    Mär 23 07:15:19 maxxgubbl kernel: Code: 2e 0f 1f 84 00 00 00 00 00 f3 90 8b 17 84 d2 75 f8 89 d1 89 d0 83 c9 01 f0 0f b1 0f 39 d0 75 e9 ba ff 00 00 00 eb 04 66 90 f3 90 <8b> 07 83 f8 01 75 f7 f0 0f b1 17 83 f8 01 75 ee eb bc b8 00 80
    Mär 23 07:15:47 maxxgubbl kernel: Code: 1f 84 00 00 00 00 00 f3 90 8b 17 84 d2 75 f8 89 d1 89 d0 83 c9 01 f0 0f b1 0f 39 d0 75 e9 ba ff 00 00 00 eb 04 66 90 f3 90 8b 07 <83> f8 01 75 f7 f0 0f b1 17 83 f8 01 75 ee eb bc b8 00 80 00 00
    Mär 23 07:15:50 maxxgubbl kernel: Code: 46 01 85 c0 0f 8e 8f 00 00 00 49 8b 87 18 04 00 00 48 39 d8 0f 84 ec 01 00 00 48 8b 48 08 48 8b 30 4c 8d a8 c8 fc ff ff 8b 7d c8 <48> 89 4e 08 48 89 31 49 8b 8f 20 04 00 00 85 ff 49 89 87 20 04
    Mär 30 09:15:07 maxxgubbl kernel: Code: 48 8d 98 30 ff ff ff 48 85 c0 49 0f 44 de eb 16 0f 1f 00 48 8b 9b d0 00 00 00 48 85 db 74 44 48 81 eb d0 00 00 00 48 85 db 74 38 <4c> 39 63 40 75 e2 4c 39 6b 28 75 dc 48 8d 83 88 00 00 00 48 89
    Apr 06 16:01:20 maxxgubbl kernel: Code: 00 00 f0 0f b1 17 85 c0 75 01 c3 55 48 89 e5 e8 27 a6 b5 ff 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 65 ff 05 83 95 aa 7e 48 89 e5 <0f> b7 07 31 d2 0f b6 cc 88 c2 38 c1 88 ce 74 20 65 ff 0d 69 95
    Apr 08 07:41:34 maxxgubbl kernel: Code: 18 75 d0 41 89 17 4c 89 c0 4c 8b 5b 20 44 89 ca eb 13 90 48 39 fe 75 bb 49 83 c3 08 48 83 c0 08 83 ea 08 74 23 48 8b 38 83 fa 07 <49> 8b 33 77 e3 8d 0c d5 00 00 00 00 4c 89 d0 48 31 fe 48 d3 e0
    Apr 11 12:05:29 maxxgubbl kernel: Code: 06 44 01 f8 69 c0 01 00 37 9e d3 e8 48 8d 1c c2 e8 a6 6f ee ff 48 8b 1b 48 83 e3 fe 75 0d eb 3b 0f 1f 00 48 8b 1b 48 85 db 74 30 <44> 39 7b 18 75 f2 4c 8d 73 50 4c 89 f7 e8 2e 6c 37 00 4c 39 63
    Apr 11 12:30:17 maxxgubbl kernel: Code: 06 44 01 f8 69 c0 01 00 37 9e d3 e8 48 8d 1c c2 e8 a6 6f ee ff 48 8b 1b 48 83 e3 fe 75 0d eb 3b 0f 1f 00 48 8b 1b 48 85 db 74 30 <44> 39 7b 18 75 f2 4c 8d 73 50 4c 89 f7 e8 2e 6c 37 00 4c 39 63
    Apr 14 14:28:09 maxxgubbl kernel: Code: 48 8b 7b 10 48 8d 47 ff 48 83 f8 fd 77 0a 48 85 ff 74 05 f0 ff 0f 74 5b 48 8b 7b 18 48 8d 47 ff 48 83 f8 fd 77 0a 48 85 ff 74 05 <f0> ff 0f 74 33 65 48 ff 0d 93 44 e2 7e 48 83 c4 08 5b 5d c3 0f
    Apr 25 12:25:14 maxxgubbl kernel: Code: 98 00 00 00 a8 20 74 33 a8 40 75 37 48 c7 83 98 00 00 00 60 00 00 00 5b 41 5c 5d c3 0f 1f 80 00 00 00 00 0f 0b 66 0f 1f 44 00 00 <0f> 0b 66 0f 1f 44 00 00 0f 0b 66 0f 1f 44 00 00 0f 0b 66 0f 1f
    Apr 27 08:27:24 maxxgubbl kernel: Code: f4 89 c2 81 e2 00 04 08 00 81 fa 00 00 08 00 75 44 80 cc 04 48 8b 8b 80 00 00 00 48 8d 93 80 00 00 00 89 03 48 8b 83 88 00 00 00 <48> 89 41 08 48 89 08 49 8b 44 24 08 49 89 54 24 08 4c 89 a3 80
    Mai 03 08:22:03 maxxgubbl kernel: Code: 48 8d 98 30 ff ff ff 48 85 c0 49 0f 44 de eb 16 0f 1f 00 48 8b 9b d0 00 00 00 48 85 db 74 44 48 81 eb d0 00 00 00 48 85 db 74 38 <4c> 39 63 40 75 e2 4c 39 6b 28 75 dc 48 8d 83 88 00 00 00 48 89
    Mai 07 09:45:45 maxxgubbl kernel: Code: 3b 05 e3 9e 7e 00 89 c1 0f 8d 7e fe ff ff 48 98 49 8b 55 00 48 03 14 c5 40 a1 8d 81 f6 42 18 01 48 89 d0 74 c8 f3 90 f6 40 18 01 <75> f8 eb be 0f b6 4d c4 4c 89 fa 4c 89 f6 44 89 ef e8 e4 fb ff
    Mai 07 09:46:13 maxxgubbl kernel: Code: 25 73 1d 00 3b 05 e3 9e 7e 00 89 c1 0f 8d 7e fe ff ff 48 98 49 8b 55 00 48 03 14 c5 40 a1 8d 81 f6 42 18 01 48 89 d0 74 c8 f3 90 <f6> 40 18 01 75 f8 eb be 0f b6 4d c4 4c 89 fa 4c 89 f6 44 89 ef
    Mai 07 09:46:41 maxxgubbl kernel: Code: 3b 05 e3 9e 7e 00 89 c1 0f 8d 7e fe ff ff 48 98 49 8b 55 00 48 03 14 c5 40 a1 8d 81 f6 42 18 01 48 89 d0 74 c8 f3 90 f6 40 18 01 <75> f8 eb be 0f b6 4d c4 4c 89 fa 4c 89 f6 44 89 ef e8 e4 fb ff
    Mai 07 09:47:09 maxxgubbl kernel: Code: 3b 05 e3 9e 7e 00 89 c1 0f 8d 7e fe ff ff 48 98 49 8b 55 00 48 03 14 c5 40 a1 8d 81 f6 42 18 01 48 89 d0 74 c8 f3 90 f6 40 18 01 <75> f8 eb be 0f b6 4d c4 4c 89 fa 4c 89 f6 44 89 ef e8 e4 fb ff
    Mai 07 09:47:37 maxxgubbl kernel: Code: 3b 05 e3 9e 7e 00 89 c1 0f 8d 7e fe ff ff 48 98 49 8b 55 00 48 03 14 c5 40 a1 8d 81 f6 42 18 01 48 89 d0 74 c8 f3 90 f6 40 18 01 <75> f8 eb be 0f b6 4d c4 4c 89 fa 4c 89 f6 44 89 ef e8 e4 fb ff
    Mai 08 16:10:11 maxxgubbl kernel: Code: 49 89 07 48 89 df 41 ff d5 83 f8 04 0f 87 a6 00 00 00 89 c2 ff 24 d5 20 ba 62 81 0f 1f 44 00 00 48 8b 43 08 48 8b 13 48 8b 7d c8 <48> 89 42 08 48 89 10 49 8b 46 10 49 89 5e 10 48 89 3b 48 89 43
    Mai 13 09:07:36 maxxgubbl kernel: Code: 11 8d 37 00 49 8d bc 24 88 00 00 00 e8 04 8d 37 00 41 8b 54 24 48 85 d2 0f 84 c7 00 00 00 48 8b 43 60 48 85 c0 0f 84 8a 00 00 00 <48> 8b 40 38 48 85 c0 0f 84 7d 00 00 00 4c 89 e6 48 89 df ff d0
    Mai 22 09:17:48 maxxgubbl kernel: Code: 08 5b 5d c3 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 e8 ba 9d 00 00 48 85 c0 74 11 <48> 8b 90 80 00 00 00 31 c0 f7 c2 00 00 00 10 75 0d 48 8b 03 48
    Jun 04 11:14:22 maxxgubbl kernel: Code: ec 08 49 8b 1e 48 85 db 75 15 eb 57 0f 1f 80 00 00 00 00 48 8b 9b d8 00 00 00 48 85 db 74 44 48 81 eb d8 00 00 00 48 85 db 74 38 <4c> 39 63 40 75 e2 4c 39 6b 28 75 dc 4c 8d bb 88 00 00 00 4c 89
    My current version is 'uname -a':
    Linux maxxgubbl 4.0.4-2-ARCH #1 SMP PREEMPT Fri May 22 03:05:23 UTC 2015 x86_64 GNU/Linux
    I also use another harddrive and another backup utility (deja dup instead of rsnapshot) for some days now, but this doesn't seems to help as you can see that 'duplicity' (deja dups utillity) was also one user space programm which froze the system. Now I try to see if microcode installation fixed the problem. I had to reboot the system for the installation of microcodes, so I have to wait and see how long my uptime gets.

  • [solved] How to convert fs from ext2 to ext3 on root partition?

    Hello there!
    Edit: It seems that the plan works! apparently it worked for alleyoopster also on a mounted fs.
    As the title says, I want to convert my fs on / from ext2 to ext3. After some research I think I know what
    to do, but want to make sure that I don't mess anything up....
    So here is the plan:
    boot with an install disc and leave the root partition unmounted (I know that in theory the conversion should
    work on a mounted fs, but it feels awkward to me and I want to avoid it....).
    Then use the
    tune2fs -j /dev/xxx
    command (the defaults for the forced checks are ok with me). Then reboot with the CD still in place, but use
    this time root=/dev/xxx. Then I can change my /etc/fstab (ext3 should have been able to be mounted as ext2 at
    the moment). Finally I have to rebuild my initrd image with
    mkinitcpio -p kernel26
    Then I should be able to boot into my system. And now the question: Can anyone verify that this is a valid approach
    and will work? Or knows a better way to do it?
    I'm grateful for any input
    Last edited by alafanky (2007-11-26 15:41:35)

    Have a look at the man for tune2fs and mkinitcpio
    man tune2fs
    man mkinitcpio
    I am looking at doing the same and as far as I can figure out it goes like this, BUT this is not a proven method just what I am thinking of doing, Maybe someone else can correct or add to this or confirm that it will work.
    1. Add journal parameter like this:
    tune2fs -j /dev/sda1
    2. Change the partition type from ext2 to ext3 in /etc/fstab
    3. For a standard  kernel re-create ramdisk with preset parameters (no good for custom kernel)
    mkinitcpio -p kernel26
    As the system is mounted it will create the journal inode in the top level, don't delete this, it will get hidden into the filesystem on reboot.
    Let me know if you make some progress. I may get brave and try it later.
    So in answer, yes pretty much the same but I think you can do it with the fs mounted.
    Last edited by alleyoopster (2007-11-26 12:44:29)

  • How to repair my lvm volume?

    I have
    # e2fsck -f /dev/media/media
    e2fsck 1.42.2 (27-Mar-2012)
    Superblock has an invalid journal (inode 8).
    Clear<y>? yes
    *** ext3 journal has been deleted - filesystem is now ext2 only ***
    The filesystem size (according to the superblock) is 1232118784 blocks
    The physical size of the device is 1220943872 blocks
    Either the superblock or the partition table is likely to be corrupt!
    Abort<y>? no
    Pass 1: Checking inodes, blocks, and sizes
    Group 16623's block bitmap (544702464) is bad. Relocate<y>? yes
    Group 16623's inode bitmap (544702465) is bad. Relocate<y>? yes
    Group 16624's block bitmap (544735232) is bad. Relocate<y>? yes
    Group 16624's inode bitmap (544735233) is bad. Relocate<y>? yes
    Group 16625's block bitmap (544768000) is bad. Relocate<y>? yes
    Group 16625's inode bitmap (544768001) is bad. Relocate<y>? yes
    Group 16626's block bitmap (544800768) is bad. Relocate<y>?
    Error writing block 1220968637 (Invalid argument) while getting next inode from scan. Ignore error<y>? yes
    Error writing block 1220968638 (Invalid argument) while getting next inode from scan. Ignore error<y>? yes
    Error writing block 1220968639 (Invalid argument) while getting next inode from scan. Ignore error<y>? yes
    Error writing block 1220968640 (Invalid argument) while getting next inode from scan. Ignore error<y>? yes
    Error writing block 1220968641 (Invalid argument) while getting next inode from scan. Ignore error<y>? yes
    Error writing block 1220968634 (Invalid argument) while getting next inode from scan. Ignore error<y>? yes
    Error writing block 1220968635 (Invalid argument) while getting next inode from scan. Ignore error<y>? yes
    Error writing block 1220968636 (Invalid argument) while getting next inode from scan. Ignore error<y>? yes
    Error reading block 1220968642 (Invalid argument) while getting next inode from scan. Ignore error<y>? yes
    I couldn't figure out what it said at the end since I had to leave a weight on the enter key to go through all the errors and it overflowed the output. But the other 3 times I've run it, it was something about multiple blocks for one inode and unable to move the inode or something, and then e2fsck aborts.
    I had done "e2fsck -cc" and that was a good 3+ days spent which didn't fix it either.
    and the setup im dealing with:
    Disk /dev/sdb: 3000.6 GB, 3000592982016 bytes
    256 heads, 63 sectors/track, 363376 cylinders, total 5860533168 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes
    Disk identifier: 0x00000000
    Device Boot Start End Blocks Id System
    /dev/sdb1 1 4294967295 2147483647+ ee GPT
    Partition 1 does not start on physical sector boundary.
    Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
    81 heads, 63 sectors/track, 382818 cylinders, total 1953525168 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0xd8295a24
    Device Boot Start End Blocks Id System
    /dev/sda1 2048 1953525167 976761560 8e Linux LVM
    Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes
    255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0x49f8bd43
    Device Boot Start End Blocks Id System
    /dev/sdd1 63 1953520064 976760001 8e Linux LVM
    Disk /dev/mapper/media-media: 5001.0 GB, 5000986099712 bytes
    255 heads, 63 sectors/track, 608001 cylinders, total 9767550976 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes
    Last edited by boast (2012-05-21 03:29:34)

    finally got to the end of one fsck
    Error writing block 1232109568 (Invalid argument) while reading inode and block bitmaps. Ignore error<y>? yes
    Error reading block 1232109569 (Invalid argument) while reading inode and block bitmaps. Ignore error<y>? yes
    Force rewrite<y>? yes
    (There are 1 inodes containing multiply-claimed blocks.)
    File ... (inode #77003937, mod time Sun Jul 9 12:44:01 1989)
    has 15 multiply-claimed block(s), shared with 1 file(s):
    <filesystem metadata>
    Clone multiply-claimed blocks<y>? yes
    Error writing block 1232109569 (Invalid argument). Ignore error<y>? yes
    Recreate journal<y>? yes
    Creating journal (32768 blocks):
    Done.
    *** journal has been re-created - filesystem is now ext3 again ***
    e2fsck: aborted
    /dev/media/media: ***** FILE SYSTEM WAS MODIFIED *****
    /dev/media/media: ********** WARNING: Filesystem still has errors **********
    edit: I consider it gone forever now. Googled and tried everything I found with no luck. Using photorec now to recover what I can.
    Last edited by boast (2012-05-24 21:52:39)

  • Big Content Access Performance Challenge

    Partitioning solution: GPT
    + Window 8.1 is capable to process 64-bit GPT partitions - even those created by parted-program under Linux OS
    + big disks available with full capacity
    Formatting solution (at the time being):
    1) Window 8.1: NTFS
       + works also under Linux with ntfs-3g installed
       - missing ext4 features such as journaling missing
    2) Linux: EXT4 with mkfs.ext4
       + ext4 features such as journaling
    Challenge: big data performance is zero with Windows 8.1 Enterprise Evaluation at the moment
    Problem 1: big partitions (>2TB): not available!
    Problem 2: big files (> 2TB): no access !
    Problem 3: big hard disks ( > 2TB): no access!
    Notes:
    a) 64-bit Linux OS was able to a) create b) access c) operate with ok performance big (>2TB) content/data/files in >4TB disks
    b)  " ** not accessible **"  message to be considered because content IS accessible once a 64-bit software is installed 
    c)  " ** the volume does not contain a recognized file system ** message should rather be something like
               "sorry, system can not recognize file system, please install/get .... solution"
    d) 32-bit system should NOT offer format as an option for with 64-bit big data !
    e) NTFS- format should not be offered for big > 2TB data by 32-bit software!
    f) it's hard for user to know whether problems are due to 32-bit programs when 32-bit programs itself don't
       recognize the fact that they are processing big data - this challenge is the same to other 32/64-bit hybrid OS systems  
    Question: what is the add-on software and where to download to get access to EXT4 disks used by 64-bit OS ?

    Thanks for your advice!
    More detailed info:
    - file size example 3.3TB <=> is 64-bit
    - partition size example: 4TB <=> is 64-bit
    - hard disk example: 4 TB hd used for enterpise big data apps <=> is 64-bit
    - partioned by 64-bit parted software in enterpise Linux
    - formatted by 64-bit mkfs.ext4 in enterpise Linux
      where
      - ext4 is fourth extended filesystem is a journaling file system for Linux
      - can support volumes with sizes up to 1 exbibyte (EiB) and files with sizes up to 16 tebibytes (TiB).[
    Goal: to explore Windows 8.1 Enteprise Evaluation performance with big data using big data content created by other 64-bit Linux
    Questions:
    1) do I need to install something to make Windows 8.1 Enteprise Evaluation handle properly big data ?
    2) what software does Microsoft recommends for Ext4 ?
    3) will the final Windows 8.1 Enteprise Evaluation embed Ext4 ?
    4) which tools and apps does Microsoft recommend
       a) to read ext4 format big data for writing it to different hard disk created by Win 8.1 with GPT ?
          - goal is to use 64-bit Linux big data in Windows 8.1 Enteprise Evaluation
       b) to read from hard disk created by Win 8.1 with GPT and to write to ext4 format disk ?
          - goal is to use Windows 8.1 Enteprise Evaluation big data in 64-bit Linux
    5) why did Microsoft diskpart give NTFS as only formatting option for big volumes:
    > diskpart <-- in command mode
    DISKPART > LIST VOLUME
    SELECT VOLUME 17 <-- one of volumes
    FILESYSTEMS --> Current File System
    Type: RAW <-- in Linux system this is EXT4
    File Systems supported for formatting: NTFS <--- *** only NTFS where max file size < 2TB***

  • Unable to migrate data from Time Machine

    Attempted to move up to Mavericks. I created a bootable USB drive using the Mavericks installed and proceeded to do my usual 'wipe & install'.
    Everything went smoothly as it had done previously with Lion and Mountain Lion.
    Once installed i attempted to migrate my data from my Time Machine backups but there is where i ran into my problem.
    The migration assistant see's the sparesbundles and allows me to choose either mine or my wifes backups but i can not continue because there is an error stating "No volumes found in backup"
    Now i understand that Mavericks was only very recently released but has anybody encountered this problem or is it specifically related to Mavericks?

    Hi, i found why my setup assistant failed and "solved" this problem in different way.
    The problem was, that my Time Machine backup was not fully complete.
    How did i find it? I go to the directory /var/log. There is a file called setup.log. Inside install.log i found following messages from setup assistant:
    Nov  7 13:33:12 localhost Setup Assistant[160]: Processing `file:///Volumes/Time%20Machine/Macintosh.sparsebundle/'...
    Nov  7 13:33:13 localhost Setup Assistant[160]:         Re-Mounted disk disk2s2 @ /Volumes/Time Machine Backups
    Nov  7 13:33:13 localhost Setup Assistant[160]: . Found disk (diskIdentifier=disk2s2, mountpoint=/Volumes/Time Machine Backups, isInternal=0, filesystem=Case-sensitive Journaled HFS+ hfs Mac OS Extended (Groß-/Kleinschreibung und Journaled) Apple_HFSX)
    Nov  7 13:33:13 localhost Setup Assistant[160]: X /Volumes/Time Machine Backups: Missing CoreServices.
    Nov  7 13:33:13 localhost Setup Assistant[160]: X /Volumes/Time Machine Backups/Backups.backupdb/.RecoverySets/0/com.apple.recovery.boot: Missing CoreServices.
    Nov  7 13:33:13 localhost Setup Assistant[160]: X /Volumes/Time Machine Backups/Backups.backupdb/Macintosh/2013-11-05-112634/Macintosh HD: Missing CoreServices.
    Nov  7 13:33:14 localhost Setup Assistant[160]:  -> Mounted backup image 'file:///Volumes/Time%20Machine/Macintosh.sparsebundle/' at {(
    Nov  7 13:33:14 localhost Setup Assistant[160]: X /Volumes/Time Machine Backups: Missing CoreServices.
    Nov  7 13:33:14 localhost Setup Assistant[160]: X /Volumes/Time Machine Backups/Backups.backupdb/.RecoverySets/0/com.apple.recovery.boot: Missing CoreServices.
    Nov  7 13:33:14 localhost Setup Assistant[160]: X /Volumes/Time Machine Backups/Backups.backupdb/Macintosh/2013-11-05-112634/Macintosh HD: Missing CoreServices.
    It seems that something wrong with my backup. I love backups which won't work.
    After searching the internet i found following website:
    http://pondini.org/TM/D10.html
    It seems that these error happend at my system. I mounted the sparsebundle from NAS-Server with the finder and searched the filestructure. Yep, exactly the described problem. My backup imcludes only the user account, nothing else from OS. So the setup assistant do not accept this backup as source medium. This is very bad, because Maverick runs 10 days on may MAC before my SSD crashed....
    What have i done:
    Clean installation of maverick
    create of a new user with system admin rights - a different than in backups
    installed software manually
    copy all user-home-directories from the mounted sparsebundle-backup to my clean mac
    recreated the user-accounts
    a Lot of work, but i do not lost any data
    At the moment i create a very new full backup
    Thanks to Apple for the high quality Time Machine software

Maybe you are looking for

  • How to determine the process alias using condition technique in Transportation & Shipment Scheudling?

    Dear All, I am trying to use the functionality Transportation and Shipment Scheduling in GATP. I would like to know that how the sytem determines the process alias using condition technique in Transportation & Shipment Scheudling? As the Transportati

  • How do you select multiple / separate words in Pages?

    Hi, I currently have Pages 5.5 (2109) and the title is self-explanatory. I'm trying to shift over from Microsoft Word, but this one function seems not to be at present. Can somebody help me? If it does not exist, is there any way you can dictate it?

  • Divs moving when zooming in on screen

    Hi I am finding that the lower four divs on my homepage design are jumping around if I zoom in and out, only in IE works OK in FF and Chrome. It was working ok even though the divs are fixed width and floated left. But I must have changed something t

  • Confusing Scenario: Alert Analytic in Performance Management

    I have a Dashboard with two pages: Page 1 for Finance and the other for the Supply chain area. Both of these pages contain the Alert Anlytic. Now what i want and have been struggling to do so far, is that the Finance area users should see the Finance

  • Business Case- Need inputs

    Hi Experts, Please let me know what does a business case satnds for in general. I had been asked to prepare a business case for my client and I donot have any clue about this. Would be a real help if any one cen please pass me on soem older templates