[DISSOLVED] was kernel panics, fs corruption, rsync, mem/efi...

cfr · 2012-03-08 20:08:10

Until today, Arch was running essentially fine on my laptop. Today, I had a kernel panic which forced me to cold reboot the machine. On reboot, I got more panics. I get panics whether I boot to runlevel 3, runlevel 5 or runlevel s. I get them with the lts kernel as well as the current one.

I even get kernel panics if I boot from the install usb I installed from in November.

The only boot which seems to work is booting finnix which is installed to a separate partition for emergency use.

fsck reports lots of errors. If I get it to fix one error, it finds more on the next run. Sometimes it will claim the fs is clean but fsck -fn says there are still errors. Sometimes fsck -f will give the partition a clean bill of health but if I repeat it, it will find new errors.

I have tried with fsck from finnix and fsck from the install media and from the system in single user mode. The latter two end with kernel panics.

smartctl finds no problems with the disk.

fsck also finds problems with my backups which are stored on an external drive. This drive was not attached when the original kernel panic occurred. It showed errors without any kernel panic occurring while it was connected. However, fscking it from the arch install media just caused another kernel panic.

At least, they look like kernel panics. I'm not sure whether they are or not because in some cases (not the original), I can switch to another tty. Just I very quickly get a crash there too once that has happened and commands tend to hang, especially disk related commands such as blkid or fsck, or give errors.

I desperately need advice. I have critical data on the drive. My backup is entirely current but since that too has errors, I'm not sure what to do for the best. So far, everything I've tried seems to have only made the situation worse - fsck, looking at the backup, booting from the install media...

Most fsck errors seem to concern incorrect inodes (it offers to clear them), inodes with illegal blocks (it offers to clear them), directory structure e.g. illegal characters in entries (it offers to fix them), incorrect references etc. In some cases, attempts to fix things don't seem to succeed: another run produces the same errors. In other cases, fsck wants to undo previous fixes on a second run e.g. for the same node it will say the reference count is 4 and should be 1 but if I let it fix that, on the next run it will say it is 1 but should be 4. I'm also getting "internal errors" due to missing information.

I'm ending up with a lot of things in lost+found...

The system is currently booted from the install media. I'm trying to shutdown as I'm on my fourth tty but it has hung trying to unmount filesystems.

Filesystems with errors are primarily ext4 because most of my filesystems are ext4.

Last edited by cfr (2012-03-10 03:14:51)

alphaniner · 2012-03-08 20:40:32

I had a somewhat similar situation after a crash in Windows years ago. The problems seemed to persist after rebooting but it came down to a bad sata cable/connection. One thing I learned is to avoid writing to the drive as much as possible until you know what is wrong.

You may be beyond that point with your system drive, but as long as you haven't written to the external drive since the first panic (including fsck repair attempts), there's no reason it should be corrupted. If I were you, I'd try to hook that drive to a different machine and see if it checks out there.

Sorry I can't be more help.

cfr · 2012-03-08 21:29:48

Oops. OK. So I think I did let fsck make some "repair" to a couple of partitions on the external. However, I've hooked the external up to another machine and the only errors fsck found were missing lost+found directories on two partitions I hadn't "repaired" so I let it create those and everything checked out. I've got one stray inode under lost+found on my root partition. This is an ascii file - looks like a file from an include/ directory for QT. I assume that this shouldn't be too difficult to restore to its rightful place or to replace with a new copy.

In particular, the backup partitions of /home and /mnt/between just lacked lost+founds. (I think because I haven't quite got rsync right and it has been deleting them.)

fsck on that machine is definitely not trying to fix numerous layers of errors as mine was.

So that means there is something seriously wrong with my laptop which is affecting the finnix emergency partition as well, right?

So my question is: what should my next move be? Is this likely to be a hardware issue? Or should I wipe the harddrive and pull stuff back from backup or what? Or should I just reinstall partitions?

LoBo3268715 · 2012-03-08 21:58:43

If I were you I'd immediately go into data saving mode since you have critical data on the drive, then I would start to diagnose the problem. How old is your HDD? Did you update the system recently?

cfr · 2012-03-08 22:36:12

I'm pretty convinced that my panic about my backup was misplaced though I may need to repair something on the root partition because of the stray inode due to fsck. But another machine finds /home and /mnt/between clean (and /usr/local where there's a little but I have that elsewhere too). That's pretty much all my research, teaching, personal stuff etc. So even if the hdd in my laptop is a lost cause, I should be OK. My last backup was in the early hours of this morning and I didn't do any significant work electronically before I started having problems. So I've pretty much done what I can in that direction. I wish I hadn't run fsck on my backup root partition but the worse case scenario would be reinstalling and reconfiguring arch from scratch and I don't think it is anywhere near that bad though I probably would have to figure out where to put the stray inode back. (I have also calmed down slightly now it no longer looks as if my teaching materials and research are evaporating before my eyes...)

System was last updated yesterday. The major thing was the update from kde 4.8.0 to 4.8.1. Or very, very early this morning, most likely. The hdd is not old. I bought the laptop in November new. smartctl reported no issues with the drive. No errors. All scheduled tests completed 100% success. Nothing worrying looking. (And smartctl runs extended, short and conveyance tests regularly via cron job.)

One of the last configuration changes I made was to update a grub2 config file under /etc/grub.d which generates entries for runlevel 3 equivalent to those generated by 10_linux (which gets runlevel 5 given my inittab). I then regenerated /boot/efi/efi/grub/grub.cfg using grub-mkconfig. Basically, the config file is just like 10_linux except for 5 lines: a comment line; the addition of "3" in the two kernel command lines; the addition of " (no X11)" to the titles of two menu entries. In addition, the lines to create recovery entry are deleted as this would needlessly repeat the recovery entry from 10_linux.

I also recently installed tp_smapci but when I tried to load the module, I got an error so I uninstalled it again.

Last edited by cfr (2012-03-08 22:38:40)

cfr · 2012-03-09 00:25:46

I tried removing the hard drive and booting from the install usb key for arch. That worked OK but I wouldn't say I could guarantee something wouldn't go wrong if I kept going. It told me I have 8 cores which is a pleasant upgrade on 2 but still.

I've now replaced the hard drive and rebooted from the usb key.

I'm not really clear what I should do next. Should I reformat the hard drive? Recreate filesystems on the various partitions? What's the best approach?

I still don't know what's causing the problem and that's making me very nervous indeed...

cfr · 2012-03-09 00:51:04

Or, on second thoughts, maybe I should really reinstall arch as well since I ran fsck on my backup of the root partition? That would be a lot more work...

cfr · 2012-03-09 02:40:00

So I repartitioned my hdd and tried to use rsync to restore the partitions from backup. However, rsync fails with a segmentation fault.

.<snip>/.thumbnails/large/d23b345842b64c4c0d5b6ebe74f6cf07.png
[2973.678021] general protection fault: 0000 [#2] PREEMPT SMP
[2973.678021] CPU1
<snip - sorry, I'm copying this from the console>
rsync: writefd_unbuffered failed to write 4 bytes to socket [generator]: Broken pipe (32)
rsync error: error in rsync protocol data stream (code 12) at io.c(1530) [generator=3.0.8]
<snip>
Segmentation fault

Does this mean anything to somebody? I would copy out more but I would only get it wrong as it is mostly meaningless (looking) code.

I'm guessing rsync shouldn't do this even if there is a problem with a file?

cfr · 2012-03-09 02:53:01

And now it is just scrolling and scrolling error after error... Call Trace... Code... Call Trace... Code...

Looks like it is just looping and looping... Should I stop it?! How?

Last edited by cfr (2012-03-09 02:57:36)

cfr · 2012-03-09 04:01:54

So I guess it is definitely hardware... Running memtest from the arch usb key has so far produced 79360 (or 793374 if you look at the other table) errors. When I first got the memory, I tested it this way and it showed none so I guess it is not a config issue.

Does the high number of errors suggest this is more likely a CPU/motherboard issue? The memtest docs say that if you get just a few errors, they are likely valid. So I'm not sure whether that means lots make it less likely a memory issue?

alphaniner · 2012-03-09 14:19:59

Are you able to access the memory? If so, and there are multiple sticks, re-run memtest with each stick by itself. Then, if you isolate what seems to be a bad stick, move it to a slot that passed and see if you get the similar results. Keep a well-written record of all troubleshooting. It may garner you some respect from tech support and expedite a warranty claim if it comes to that.

cfr · 2012-03-09 17:27:46

Thanks. What I actually did was pull the two memory sticks I'd installed and reinstalled the single, smaller memory module which came with the laptop. I then ran memtest on that and got no errors. I guess that I might have just picked the good slot to reinstall into but I'm assuming right now that it is likely the memory itself. Anyway, I've passed it to a friend who actually ordered it along with some other things (to save paying p&p) and he's going to test it in another machine and return it if he gets errors there too. I guess if not, I'll try moving the original memory into the second slot and seeing if that gets errors in which case it would presumably be the laptop manufacturer's warranty I'd need to invoke. (I really hope it is the memory and not the slot!)

Because I'd partly corrupted my backup running fsck, I've tried to correct that. I had a stray inode in /lost+found and I think I've figured out what that was and where it was supposed to go. I got the name of the file from reading it and ran locate on the name. I then figured out which of the three results was missing from the filesystem and put it in the appropriate place.

I'm now booted back into Arch (!). On login, kactivitymanagerd immediately crashed. On the other hand, it has done this ever since the 4.8 update so I'm not sure it isn't to be expected. (Somebody reported solving this by removing both ~/.kde4 and ~/.local but, frankly, I'd lose too much that way. If it was just a couple of config files, fine, but everything?!)

Dropbox also claimed that I'd never associated this machine with an account and got me to setup my account again. Is this normal? I can't think what it could be using to identify my machine which would have changed. (Obviously partition UUIDs have changed but I assume it isn't trying to use _those_?) It then complained about not finding gksu. gksu is installed, though, at /usr/bin/gksu and I checked it still exists there. Then it reported being unable to set user_xattr in fstab. Frankly, I'd rather it didn't go fiddling with fstab behind my back. I don't know if this should be added to mount options for some partition or not. What would dropbox need this for?

I know these are different problems. Really what I'm trying to get at is this: can I trust the filesystem under these conditions or should I really be reinstalling arch? I'd still really need to pull stuff from /home and /mnt/between but I suppose I could reinstall the root system etc. (I just really don't want to have to...) I'm somewhat inclined to see how it goes but would appreciate advice from those more knowledgeable. I've disabled backups right now so that my existing backup isn't in danger of becoming further corrupted.

cfr · 2012-03-10 01:54:16

I am getting some worrying output in dmesg:

[    0.000000] Disabled fast string operations
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000008f000 (usable)
[    0.000000]  BIOS-e820: 000000000008f000 - 0000000000090000 (ACPI NVS)
[    0.000000]  BIOS-e820: 0000000000090000 - 00000000000a0000 (usable)
[    0.000000]  BIOS-e820: 0000000000100000 - 0000000040000000 (usable)
[    0.000000]  BIOS-e820: 0000000040000000 - 0000000040200000 (reserved)
[    0.000000]  BIOS-e820: 0000000040200000 - 000000007a1c9000 (usable)
[    0.000000]  BIOS-e820: 000000007a1c9000 - 000000007a6dc000 (reserved)
[    0.000000]  BIOS-e820: 000000007a6dc000 - 000000007a79f000 (ACPI NVS)
[    0.000000]  BIOS-e820: 000000007a79f000 - 000000007a7ff000 (ACPI data)
[    0.000000]  BIOS-e820: 000000007a7ff000 - 000000007a800000 (usable)
[    0.000000]  BIOS-e820: 00000000f80f8000 - 00000000f80f9000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  BIOS-e820: 0000000100000000 - 0000000100600000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] EFI v2.00 by Phoenix Technologies Ltd.
[    0.000000]  ACPI=0x7a7fe000  ACPI 2.0=0x7a7fe014  SMBIOS=0x7a665000 
[    0.000000] Kernel-defined memdesc doesn't match the one from EFI!
[    0.000000] EFI: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000001000) (0MB)
[    0.000000] EFI: mem01: type=7, attr=0xf, range=[0x0000000000001000-0x0000000000054000) (0MB)
[    0.000000] EFI: mem02: type=4, attr=0xf, range=[0x0000000000054000-0x0000000000055000) (0MB)
[    0.000000] EFI: mem03: type=3, attr=0xf, range=[0x0000000000055000-0x000000000008f000) (0MB)
[    0.000000] EFI: mem04: type=10, attr=0xf, range=[0x000000000008f000-0x0000000000090000) (0MB)
[    0.000000] EFI: mem05: type=3, attr=0xf, range=[0x0000000000090000-0x00000000000a0000) (0MB)
[    0.000000] EFI: mem06: type=2, attr=0xf, range=[0x0000000000100000-0x0000000000424000) (3MB)
[    0.000000] EFI: mem07: type=7, attr=0xf, range=[0x0000000000424000-0x000000001baa9000) (438MB)
[    0.000000] EFI: mem08: type=2, attr=0xf, range=[0x000000001baa9000-0x000000003942a000) (473MB)
[    0.000000] EFI: mem09: type=4, attr=0xf, range=[0x000000003942a000-0x000000003944a000) (0MB)
[    0.000000] EFI: mem10: type=7, attr=0xf, range=[0x000000003944a000-0x000000003b8c0000) (36MB)
[    0.000000] EFI: mem11: type=4, attr=0xf, range=[0x000000003b8c0000-0x000000003c41a000) (11MB)
[    0.000000] EFI: mem12: type=7, attr=0xf, range=[0x000000003c41a000-0x0000000040000000) (59MB)
[    0.000000] EFI: mem13: type=0, attr=0xf, range=[0x0000000040000000-0x0000000040200000) (2MB)
[    0.000000] EFI: mem14: type=7, attr=0xf, range=[0x0000000040200000-0x0000000075a33000) (856MB)
[    0.000000] EFI: mem15: type=1, attr=0xf, range=[0x0000000075a33000-0x0000000075a52000) (0MB)
[    0.000000] EFI: mem16: type=7, attr=0xf, range=[0x0000000075a52000-0x0000000076c75000) (18MB)
[    0.000000] EFI: mem17: type=4, attr=0xf, range=[0x0000000076c75000-0x0000000077279000) (6MB)
[    0.000000] EFI: mem18: type=7, attr=0xf, range=[0x0000000077279000-0x000000007727b000) (0MB)
[    0.000000] EFI: mem19: type=4, attr=0xf, range=[0x000000007727b000-0x000000007727c000) (0MB)
[    0.000000] EFI: mem20: type=7, attr=0xf, range=[0x000000007727c000-0x000000007727d000) (0MB)
[    0.000000] EFI: mem21: type=4, attr=0xf, range=[0x000000007727d000-0x0000000077ce5000) (10MB)
[    0.000000] EFI: mem22: type=7, attr=0xf, range=[0x0000000077ce5000-0x0000000077e1e000) (1MB)
[    0.000000] EFI: mem23: type=4, attr=0xf, range=[0x0000000077e1e000-0x0000000077e5e000) (0MB)
[    0.000000] EFI: mem24: type=7, attr=0xf, range=[0x0000000077e5e000-0x0000000077e5f000) (0MB)
[    0.000000] EFI: mem25: type=4, attr=0xf, range=[0x0000000077e5f000-0x0000000078282000) (4MB)
[    0.000000] EFI: mem26: type=7, attr=0xf, range=[0x0000000078282000-0x0000000078285000) (0MB)
[    0.000000] EFI: mem27: type=4, attr=0xf, range=[0x0000000078285000-0x00000000784d2000) (2MB)
[    0.000000] EFI: mem28: type=7, attr=0xf, range=[0x00000000784d2000-0x00000000785e5000) (1MB)
[    0.000000] EFI: mem29: type=4, attr=0xf, range=[0x00000000785e5000-0x00000000785ff000) (0MB)
[    0.000000] EFI: mem30: type=7, attr=0xf, range=[0x00000000785ff000-0x0000000078602000) (0MB)
[    0.000000] EFI: mem31: type=4, attr=0xf, range=[0x0000000078602000-0x000000007874a000) (1MB)
[    0.000000] EFI: mem32: type=7, attr=0xf, range=[0x000000007874a000-0x000000007874b000) (0MB)
[    0.000000] EFI: mem33: type=4, attr=0xf, range=[0x000000007874b000-0x000000007874f000) (0MB)
[    0.000000] EFI: mem34: type=7, attr=0xf, range=[0x000000007874f000-0x0000000078750000) (0MB)
[    0.000000] EFI: mem35: type=4, attr=0xf, range=[0x0000000078750000-0x0000000078782000) (0MB)
[    0.000000] EFI: mem36: type=7, attr=0xf, range=[0x0000000078782000-0x0000000078783000) (0MB)
[    0.000000] EFI: mem37: type=4, attr=0xf, range=[0x0000000078783000-0x0000000078795000) (0MB)
[    0.000000] EFI: mem38: type=7, attr=0xf, range=[0x0000000078795000-0x000000007879a000) (0MB)
[    0.000000] EFI: mem39: type=4, attr=0xf, range=[0x000000007879a000-0x00000000798c1000) (17MB)
...
[    0.000000] Disabled fast string operations
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000008f000 (usable)
[    0.000000]  BIOS-e820: 000000000008f000 - 0000000000090000 (ACPI NVS)
[    0.000000]  BIOS-e820: 0000000000090000 - 00000000000a0000 (usable)
[    0.000000]  BIOS-e820: 0000000000100000 - 0000000040000000 (usable)
[    0.000000]  BIOS-e820: 0000000040000000 - 0000000040200000 (reserved)
[    0.000000]  BIOS-e820: 0000000040200000 - 000000007a1c9000 (usable)
[    0.000000]  BIOS-e820: 000000007a1c9000 - 000000007a6dc000 (reserved)
[    0.000000]  BIOS-e820: 000000007a6dc000 - 000000007a79f000 (ACPI NVS)
[    0.000000]  BIOS-e820: 000000007a79f000 - 000000007a7ff000 (ACPI data)
[    0.000000]  BIOS-e820: 000000007a7ff000 - 000000007a800000 (usable)
[    0.000000]  BIOS-e820: 00000000f80f8000 - 00000000f80f9000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  BIOS-e820: 0000000100000000 - 0000000100600000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] EFI v2.00 by Phoenix Technologies Ltd.
[    0.000000]  ACPI=0x7a7fe000  ACPI 2.0=0x7a7fe014  SMBIOS=0x7a665000 
[    0.000000] Kernel-defined memdesc doesn't match the one from EFI!
[    0.000000] EFI: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000001000) (0MB)
[    0.000000] EFI: mem01: type=7, attr=0xf, range=[0x0000000000001000-0x0000000000054000) (0MB)
[    0.000000] EFI: mem02: type=4, attr=0xf, range=[0x0000000000054000-0x0000000000055000) (0MB)
[    0.000000] EFI: mem03: type=3, attr=0xf, range=[0x0000000000055000-0x000000000008f000) (0MB)
[    0.000000] EFI: mem04: type=10, attr=0xf, range=[0x000000000008f000-0x0000000000090000) (0MB)
[    0.000000] EFI: mem05: type=3, attr=0xf, range=[0x0000000000090000-0x00000000000a0000) (0MB)
[    0.000000] EFI: mem06: type=2, attr=0xf, range=[0x0000000000100000-0x0000000000424000) (3MB)
[    0.000000] EFI: mem07: type=7, attr=0xf, range=[0x0000000000424000-0x000000001baa9000) (438MB)
[    0.000000] EFI: mem08: type=2, attr=0xf, range=[0x000000001baa9000-0x000000003942a000) (473MB)
[    0.000000] EFI: mem09: type=4, attr=0xf, range=[0x000000003942a000-0x000000003944a000) (0MB)
[    0.000000] EFI: mem10: type=7, attr=0xf, range=[0x000000003944a000-0x000000003b8c0000) (36MB)
[    0.000000] EFI: mem11: type=4, attr=0xf, range=[0x000000003b8c0000-0x000000003c41a000) (11MB)
[    0.000000] EFI: mem12: type=7, attr=0xf, range=[0x000000003c41a000-0x0000000040000000) (59MB)
[    0.000000] EFI: mem13: type=0, attr=0xf, range=[0x0000000040000000-0x0000000040200000) (2MB)
[    0.000000] EFI: mem14: type=7, attr=0xf, range=[0x0000000040200000-0x0000000075a33000) (856MB)
[    0.000000] EFI: mem15: type=1, attr=0xf, range=[0x0000000075a33000-0x0000000075a52000) (0MB)
[    0.000000] EFI: mem16: type=7, attr=0xf, range=[0x0000000075a52000-0x0000000076c75000) (18MB)
[    0.000000] EFI: mem17: type=4, attr=0xf, range=[0x0000000076c75000-0x0000000077279000) (6MB)
[    0.000000] EFI: mem18: type=7, attr=0xf, range=[0x0000000077279000-0x000000007727b000) (0MB)
[    0.000000] EFI: mem19: type=4, attr=0xf, range=[0x000000007727b000-0x000000007727c000) (0MB)
[    0.000000] EFI: mem20: type=7, attr=0xf, range=[0x000000007727c000-0x000000007727d000) (0MB)
[    0.000000] EFI: mem21: type=4, attr=0xf, range=[0x000000007727d000-0x0000000077ce5000) (10MB)
[    0.000000] EFI: mem22: type=7, attr=0xf, range=[0x0000000077ce5000-0x0000000077e1e000) (1MB)
[    0.000000] EFI: mem23: type=4, attr=0xf, range=[0x0000000077e1e000-0x0000000077e5e000) (0MB)
[    0.000000] EFI: mem24: type=7, attr=0xf, range=[0x0000000077e5e000-0x0000000077e5f000) (0MB)
[    0.000000] EFI: mem25: type=4, attr=0xf, range=[0x0000000077e5f000-0x0000000078282000) (4MB)
[    0.000000] EFI: mem26: type=7, attr=0xf, range=[0x0000000078282000-0x0000000078285000) (0MB)
[    0.000000] EFI: mem27: type=4, attr=0xf, range=[0x0000000078285000-0x00000000784d2000) (2MB)
[    0.000000] EFI: mem28: type=7, attr=0xf, range=[0x00000000784d2000-0x00000000785e5000) (1MB)
[    0.000000] EFI: mem29: type=4, attr=0xf, range=[0x00000000785e5000-0x00000000785ff000) (0MB)
[    0.000000] EFI: mem30: type=7, attr=0xf, range=[0x00000000785ff000-0x0000000078602000) (0MB)
[    0.000000] EFI: mem31: type=4, attr=0xf, range=[0x0000000078602000-0x000000007874a000) (1MB)
[    0.000000] EFI: mem32: type=7, attr=0xf, range=[0x000000007874a000-0x000000007874b000) (0MB)
[    0.000000] EFI: mem33: type=4, attr=0xf, range=[0x000000007874b000-0x000000007874f000) (0MB)
[    0.000000] EFI: mem34: type=7, attr=0xf, range=[0x000000007874f000-0x0000000078750000) (0MB)
[    0.000000] EFI: mem35: type=4, attr=0xf, range=[0x0000000078750000-0x0000000078782000) (0MB)
[    0.000000] EFI: mem36: type=7, attr=0xf, range=[0x0000000078782000-0x0000000078783000) (0MB)
[    0.000000] EFI: mem37: type=4, attr=0xf, range=[0x0000000078783000-0x0000000078795000) (0MB)
[    0.000000] EFI: mem38: type=7, attr=0xf, range=[0x0000000078795000-0x000000007879a000) (0MB)
[    0.000000] EFI: mem39: type=4, attr=0xf, range=[0x000000007879a000-0x00000000798c1000) (17MB)
[    0.000000] EFI: mem40: type=7, attr=0xf, range=[0x00000000798c1000-0x0000000079ad4000) (2MB)
[    0.000000] EFI: mem41: type=2, attr=0xf, range=[0x0000000079ad4000-0x0000000079ada000) (0MB)
[    0.000000] EFI: mem42: type=3, attr=0xf, range=[0x0000000079ada000-0x000000007a1c9000) (6MB)
[    0.000000] EFI: mem43: type=5, attr=0x800000000000000f, range=[0x000000007a1c9000-0x000000007a1db000) (0MB)
[    0.000000] EFI: mem44: type=5, attr=0x800000000000000f, range=[0x000000007a1db000-0x000000007a2c9000) (0MB)
[    0.000000] EFI: mem45: type=6, attr=0x800000000000000f, range=[0x000000007a2c9000-0x000000007a302000) (0MB)
[    0.000000] EFI: mem46: type=6, attr=0x800000000000000f, range=[0x000000007a302000-0x000000007a3c9000) (0MB)
[    0.000000] EFI: mem47: type=0, attr=0xf, range=[0x000000007a3c9000-0x000000007a665000) (2MB)
[    0.000000] EFI: mem48: type=0, attr=0xf, range=[0x000000007a665000-0x000000007a6dc000) (0MB)
[    0.000000] EFI: mem49: type=10, attr=0xf, range=[0x000000007a6dc000-0x000000007a6f7000) (0MB)
[    0.000000] EFI: mem50: type=10, attr=0xf, range=[0x000000007a6f7000-0x000000007a79f000) (0MB)
[    0.000000] EFI: mem51: type=9, attr=0xf, range=[0x000000007a79f000-0x000000007a7e1000) (0MB)
[    0.000000] EFI: mem52: type=9, attr=0xf, range=[0x000000007a7e1000-0x000000007a7ff000) (0MB)
[    0.000000] EFI: mem53: type=4, attr=0xf, range=[0x000000007a7ff000-0x000000007a800000) (0MB)
[    0.000000] EFI: mem54: type=7, attr=0xf, range=[0x0000000100000000-0x0000000100600000) (6MB)
[    0.000000] EFI: mem55: type=11, attr=0x8000000000000001, range=[0x00000000f80f8000-0x00000000f80f9000) (0MB)
[    0.000000] EFI: mem56: type=11, attr=0x8000000000000001, range=[0x00000000fed1c000-0x00000000fed20000) (0MB)
[    0.000000] DMI 2.6 present.
...
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[    0.000000] No AGP bridge found
[    0.000000] last_pfn = 0x100600 max_arch_pfn = 0x400000000
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF uncachable
[    0.000000]   C0000-FFFFF write-protect
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 0FFC00000 mask FFFC00000 write-protect
[    0.000000]   1 base 000000000 mask F80000000 write-back
[    0.000000]   2 base 07C000000 mask FFC000000 uncachable
[    0.000000]   3 base 07B000000 mask FFF000000 uncachable
[    0.000000]   4 base 07A800000 mask FFF800000 uncachable
[    0.000000]   5 base 100000000 mask FE0000000 write-back
[    0.000000]   6 base 110000000 mask FF0000000 uncachable
[    0.000000]   7 base 108000000 mask FF8000000 uncachable
[    0.000000]   8 base 104000000 mask FFC000000 uncachable
[    0.000000]   9 base 102000000 mask FFE000000 uncachable
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] last_pfn = 0x7a800 max_arch_pfn = 0x400000000
[    0.000000] initial memory mapped : 0 - 20000000
[    0.000000] Base memory trampoline at [ffff880000098000] 98000 size 20480
[    0.000000] init_memory_mapping: 0000000000000000-000000007a800000
[    0.000000]  0000000000 - 007a800000 page 2M
[    0.000000] kernel direct mapping tables up to 7a800000 @ 1fffd000-20000000
[    0.000000] init_memory_mapping: 0000000100000000-0000000100600000
[    0.000000]  0100000000 - 0100600000 page 2M
[    0.000000] kernel direct mapping tables up to 100600000 @ 79ad4000-79ada000
[    0.000000] RAMDISK: 37a3a000 - 37d15000
[    0.000000] ACPI: RSDP 000000007a7fe014 00024 (v04 LENOVO)
[    0.000000] ACPI: XSDT 000000007a7fe120 00084 (v01 LENOVO TP-8Q    00001140 PTEC 00000002)
[    0.000000] ACPI: FACP 000000007a7eb000 000F4 (v03 LENOVO TP-8Q    00001140 PTL  00000002)
[    0.000000] ACPI: DSDT 000000007a7ee000 0FC7E (v02 LENOVO  SNB-CPT 00000000 INTL 20061109)
[    0.000000] ACPI: FACS 000000007a73c000 00040
[    0.000000] ACPI: ASF! 000000007a7ed000 000A5 (v32 LENOVO TP-8Q    00001140 PTL  00000002)
[    0.000000] ACPI: HPET 000000007a7ea000 00038 (v01 LENOVO TP-8Q    00001140 PTL  00000002)
[    0.000000] ACPI: APIC 000000007a7e9000 00098 (v01 LENOVO TP-8Q    00001140 PTL  00000002)
[    0.000000] ACPI: MCFG 000000007a7e8000 0003C (v01 LENOVO TP-8Q    00001140 PTL  00000002)
[    0.000000] ACPI: FACS 000000007a73c000 00040
[    0.000000] ACPI: ASF! 000000007a7ed000 000A5 (v32 LENOVO TP-8Q    00001140 PTL  00000002)
[    0.000000] ACPI: HPET 000000007a7ea000 00038 (v01 LENOVO TP-8Q    00001140 PTL  00000002)
[    0.000000] ACPI: APIC 000000007a7e9000 00098 (v01 LENOVO TP-8Q    00001140 PTL  00000002)
[    0.000000] ACPI: MCFG 000000007a7e8000 0003C (v01 LENOVO TP-8Q    00001140 PTL  00000002)
[    0.000000] ACPI: SLIC 000000007a7e7000 00176 (v01 LENOVO TP-8Q    00001140 PTEC 00000001)
[    0.000000] ACPI: TCPA 000000007a7e6000 00032 (v02    PTL   LENOVO 06040000 LNVO 00000001)
[    0.000000] ACPI: SSDT 000000007a7e5000 0073E (v01  PmRef  Cpu0Ist 00003000 INTL 20061109)
[    0.000000] ACPI: SSDT 000000007a7e4000 00996 (v01  PmRef    CpuPm 00003000 INTL 20061109)
[    0.000000] ACPI: UEFI 000000007a7e3000 0003E (v01 LENOVO TP-8Q    00001140 PTL  00000002)
[    0.000000] ACPI: UEFI 000000007a7e2000 00042 (v01 PTL      COMBUF 00000001 PTL  00000001)
[    0.000000] ACPI: UEFI 000000007a7e1000 00292 (v01 LENOVO TP-8Q    00001140 PTL  00000002)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-0000000100600000
[    0.000000] Initmem setup node 0 0000000000000000-0000000100600000
[    0.000000]   NODE_DATA [00000001005fb000 - 00000001005fffff]
[    0.000000]  [ffffea0000000000-ffffea00041fffff] PMD -> [ffff880074600000-ffff8800767fffff] on node 0
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000010 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x00100600
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[6] active PFN ranges
[    0.000000]     0: 0x00000010 -> 0x0000008f
[    0.000000]     0: 0x00000090 -> 0x000000a0
[    0.000000]     0: 0x00000100 -> 0x00040000
[    0.000000]     0: 0x00040200 -> 0x0007a1c9
[    0.000000]     0: 0x0007a7ff -> 0x0007a800
[    0.000000]     0: 0x00100000 -> 0x00100600
[    0.000000] On node 0 totalpages: 501081
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 10 pages reserved
[    0.000000]   DMA zone: 3909 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 16320 pages used for memmap
[    0.000000]   DMA32 zone: 479242 pages, LIFO batch:31
[    0.000000]   Normal zone: 24 pages used for memmap
[    0.000000]   Normal zone: 1512 pages, LIFO batch:0

I'm not sure what to make of this. Do I need to remake the kernel for boot using mkinitcpio? Or do I need to repopulate /boot/efi/efi/grub/? I see there's some sort of inconsistency about memory. I'm wondering if one bit of the system is working with stale data about the installed RAM that I need to somehow update while the other bit is detecting the available RAM "live" and getting a different answer (since I've basically pulled 2*4G of RAM and installed 1*2G from a different source.)

Edit: I was getting this before my system went nuts with my previous memory installed and no problems. So worrying though it may be, I don't think it is more worrying than usual...

Last edited by cfr (2012-03-10 03:13:42)

Arch Linux

#1 2012-03-08 20:08:10

[DISSOLVED] was kernel panics, fs corruption, rsync, mem/efi...

#2 2012-03-08 20:40:32

Re: [DISSOLVED] was kernel panics, fs corruption, rsync, mem/efi...

#3 2012-03-08 21:29:48

Re: [DISSOLVED] was kernel panics, fs corruption, rsync, mem/efi...

#4 2012-03-08 21:58:43

Re: [DISSOLVED] was kernel panics, fs corruption, rsync, mem/efi...

#5 2012-03-08 22:36:12

Re: [DISSOLVED] was kernel panics, fs corruption, rsync, mem/efi...

#6 2012-03-09 00:25:46

Re: [DISSOLVED] was kernel panics, fs corruption, rsync, mem/efi...

#7 2012-03-09 00:51:04

Re: [DISSOLVED] was kernel panics, fs corruption, rsync, mem/efi...

#8 2012-03-09 02:40:00

Re: [DISSOLVED] was kernel panics, fs corruption, rsync, mem/efi...

#9 2012-03-09 02:53:01

Re: [DISSOLVED] was kernel panics, fs corruption, rsync, mem/efi...

#10 2012-03-09 04:01:54

Re: [DISSOLVED] was kernel panics, fs corruption, rsync, mem/efi...

#11 2012-03-09 14:19:59

Re: [DISSOLVED] was kernel panics, fs corruption, rsync, mem/efi...

#12 2012-03-09 17:27:46

Re: [DISSOLVED] was kernel panics, fs corruption, rsync, mem/efi...

#13 2012-03-10 01:54:16

Re: [DISSOLVED] was kernel panics, fs corruption, rsync, mem/efi...

Board footer