You are not logged in.

#1 2012-08-27 15:08:18

robotangel
Member
From: cologne/germany
Registered: 2007-08-30
Posts: 63

[SOLVED] Kernel Panics on boot w/ 3.4.x-ARCH and 3.5.x-ck

Hi there,

I really hope there's someone able to help me again, this time. I recently bought a Lenovo E530 and installed arch on it. I was able to set it up successfully and it works like a charm (once it's booted up...). Now to my problem: Most times when I try to start I only get kernel panics and oopses and have to reboot before I even get to a graphical user interface. These panics and errors always come up at different stages in the boot process and always differ from each other, so I have not a bit of an idea what could be causing them... Windows and the Arch LTS Kernel seem to work fine. The strange thing is, when I boot up Windows or Arch with th LTS kernel, 3.5.2-ck and 3.4.9-ARCH won't throw oopses and panics at me for the next time I try to start them. Unfourtunately, I don't really want to use windows and the hardware support of this kinda new piece of hardware isn't quite as good with 3.0 as with the recent kernels (warnings about unsupported xHCI, slower i915 performance etc.). Again: Once the system is booted up I can use it for hours and it keeps being stable, there are no problems whatsoever.

/cat/cpuinfo

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 58
model name      : Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
stepping        : 9
microcode       : 0x12
cpu MHz         : 1200.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips        : 4990.49
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 58
model name      : Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
stepping        : 9
microcode       : 0x12
cpu MHz         : 1200.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips        : 4990.49
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 58
model name      : Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
stepping        : 9
microcode       : 0x12
cpu MHz         : 1200.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 2
apicid          : 2
initial apicid  : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips        : 4990.49
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 58
model name      : Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
stepping        : 9
microcode       : 0x12
cpu MHz         : 1200.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 2
apicid          : 3
initial apicid  : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips        : 4990.49
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

fdisk -l (I think it maybe could have something to do with XFS on luks, at least sometimes?)

Disk /dev/sdb: 64.0 GB, 64023257088 bytes
255 heads, 63 sectors/track, 7783 cylinders, total 125045424 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: 0xfe2cf8d6

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048    54274047    27136000    7  HPFS/NTFS/exFAT
/dev/sdb2        54274048   125042687    35384320   83  Linux

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: 0x48ad9188

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048      206847      102400    7  HPFS/NTFS/exFAT
/dev/sda2          206848   126978047    63385600    7  HPFS/NTFS/exFAT
/dev/sda3   *   126978048   127592447      307200   83  Linux
/dev/sda4       127592448   976771071   424589312   83  Linux

Disk /dev/mapper/HOME: 434.8 GB, 434777358336 bytes
255 heads, 63 sectors/track, 52858 cylinders, total 849174528 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 /dev/mapper/SSD: 8587 MB, 8587837440 bytes
255 heads, 63 sectors/track, 1044 cylinders, total 16773120 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

/dev/mapper/HOME is the xfs /home partition sda4. /dev/mapper/SSD is an image on ext4 /dev/sdb2.

mount

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=1817244k,nr_inodes=454311,mode=755)
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
/dev/sdb2 on / type ext4 (rw,noatime,discard,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=21,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
/dev/mapper/HOME on /home type xfs (rw,relatime,attr2,nobarrier,noquota)
/dev/sda3 on /boot type ext2 (rw,relatime)
/dev/mapper/SSD on /home/marco/SSD type ext2 (rw,noatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)

lsmod

Module                  Size  Used by
loop                   18160  2 
joydev                  9991  0 
snd_hda_codec_hdmi     23672  1 
snd_hda_codec_conexant    46122  1 
xfs                   749724  1 
exportfs                3665  1 xfs
arc4                    1410  2 
iwlwifi               310987  0 
snd_hda_intel          24053  3 
mac80211              395712  1 iwlwifi
snd_hda_codec          94305  3 snd_hda_codec_hdmi,snd_hda_codec_conexant,snd_hda_intel
snd_hwdep               6300  1 snd_hda_codec
uvcvideo               69437  0 
snd_pcm                74958  3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
videobuf2_vmalloc       2468  1 uvcvideo
snd_page_alloc          7217  2 snd_pcm,snd_hda_intel
videobuf2_memops        2246  1 videobuf2_vmalloc
thinkpad_acpi          62497  0 
videobuf2_core         20415  1 uvcvideo
videodev               93086  1 uvcvideo
snd_timer              18966  1 snd_pcm
nvram                   5906  1 thinkpad_acpi
cfg80211              170255  2 iwlwifi,mac80211
serio_raw               4653  0 
r8169                  48993  0 
iTCO_wdt               12813  0 
media                  10213  2 uvcvideo,videodev
btusb                  11764  0 
bluetooth             190551  1 btusb
microcode              12345  0 
coretemp                5654  0 
psmouse                70792  0 
pcspkr                  1899  0 
i2c_i801                8180  0 
rfkill                 15604  4 cfg80211,thinkpad_acpi,bluetooth
snd                    58997  14 snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_hda_codec_conexant,snd_pcm,snd_hda_codec,snd_hda_intel,thinkpad_acpi
iTCO_vendor_support     1929  1 iTCO_wdt
mii                     4123  1 r8169
mei                    32152  0 
thermal                 7959  0 
acpi_cpufreq            5933  1 
soundcore               5410  1 snd
ac                      2376  0 
wmi                     8475  0 
battery                 6517  0 
mperf                   1299  1 acpi_cpufreq
evdev                   9754  23 
processor              26567  5 acpi_cpufreq
sg                     25344  0 
autofs4                24023  2 
ext4                  424871  3 
crc16                   1359  2 ext4,bluetooth
jbd2                   73919  1 ext4
mbcache                 5977  1 ext4
xts                     3101  16 
gf128mul                6050  1 xts
dm_crypt               16496  2 
dm_mod                 70918  5 dm_crypt
sr_mod                 14823  0 
cdrom                  35648  1 sr_mod
sd_mod                 29239  5 
aesni_intel            43154  65 
aes_x86_64              7508  1 aesni_intel
aes_generic            26138  2 aesni_intel,aes_x86_64
ahci                   20549  3 
ghash_clmulni_intel     4237  0 
cryptd                  8741  18 ghash_clmulni_intel,aesni_intel
libahci                20023  1 ahci
crc32c_intel            1987  0 
ehci_hcd               41026  0 
libata                167611  2 ahci,libahci
xhci_hcd               81472  0 
scsi_mod              132736  4 sg,libata,sd_mod,sr_mod
usbcore               147661  5 btusb,uvcvideo,ehci_hcd,xhci_hcd
usb_common               954  1 usbcore
i915                  438112  3 
video                  11307  1 i915
button                  4502  1 i915
i2c_algo_bit            5391  1 i915
intel_agp              10936  1 i915
intel_gtt              14047  3 i915,intel_agp
drm_kms_helper         33051  1 i915
drm                   208958  4 i915,drm_kms_helper
i2c_core               20369  6 drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit,videodev

Screenshots (are the error messages stored in plain text somewhere on the hdd? if so, just tell me, I will paste them then smile )
http://dl.dropbox.com/u/1128129/arch/1.jpg
http://dl.dropbox.com/u/1128129/arch/2.jpg
http://dl.dropbox.com/u/1128129/arch/3.jpg
http://dl.dropbox.com/u/1128129/arch/4.jpg

Thank you very very much for your help in advance smile !!

Solution: blacklist btusb module

Last edited by robotangel (2012-09-03 23:40:09)

Offline

#2 2012-08-27 20:35:42

graysky
Wiki Maintainer
From: :wq
Registered: 2008-12-01
Posts: 10,592
Website

Re: [SOLVED] Kernel Panics on boot w/ 3.4.x-ARCH and 3.5.x-ck

Using Linux-ck from AUR?  Did you modify the config at all?  Did you try 3.5.3-2 which was released an h ago?

Last edited by graysky (2012-08-27 20:39:49)


CPU-optimized Linux-ck packages @ Repo-ck  • AUR packagesZsh and other configs

Offline

#3 2012-08-27 23:10:42

robotangel
Member
From: cologne/germany
Registered: 2007-08-30
Posts: 63

Re: [SOLVED] Kernel Panics on boot w/ 3.4.x-ARCH and 3.5.x-ck

Thank you for your reply smile

I'm using linux-ck-corex from your repo, 3.4.9-ARCH is from core. 3.5.3-2 panics, too. I did not touch the config. What I noticed is that the kernel panics and oopses always happen as soon as /home is mounted (which is the luks-encrypted /dev/sda4 partition). So I suspected maybe luks and xfs didn't play together nicely (and because of the xfs-message in screenshot 4) and tried reformatting it to ext4. This didn't solve the problem, however.

Meanwhile, I've ran memtest and the integrated lenovo hard disk diagnostics tool. Both weren't able to find anything wrong with my hardware, either. The laptop is barely one week old, I personally couldn't imagine this happens because of broken hardware components, either.

Any ideas sad ?

Offline

#4 2012-08-28 01:38:42

graysky
Wiki Maintainer
From: :wq
Registered: 2008-12-01
Posts: 10,592
Website

Re: [SOLVED] Kernel Panics on boot w/ 3.4.x-ARCH and 3.5.x-ck

Does 3.5.3-1-ARCH from [testing] work wo/ errors?  Does 3.4.9-1-ARCH?  I didn't understand your first post.

Last edited by graysky (2012-08-28 01:40:08)


CPU-optimized Linux-ck packages @ Repo-ck  • AUR packagesZsh and other configs

Offline

#5 2012-08-28 12:30:26

robotangel
Member
From: cologne/germany
Registered: 2007-08-30
Posts: 63

Re: [SOLVED] Kernel Panics on boot w/ 3.4.x-ARCH and 3.5.x-ck

Neither do (as good as 3.0). But since I reformatted /home with ext4 the panics happen less frequently, only every 5 or 6 starts or so. That's a number I can live with, even though it would be nice if it would "just work" smile

Last edited by robotangel (2012-08-28 12:31:03)

Offline

#6 2012-08-28 16:31:15

graysky
Wiki Maintainer
From: :wq
Registered: 2008-12-01
Posts: 10,592
Website

Re: [SOLVED] Kernel Panics on boot w/ 3.4.x-ARCH and 3.5.x-ck

OK. I wanted to ounderstand if this is caused by the ck patchset or not.  Based on what you wrote, I believe it is not.


CPU-optimized Linux-ck packages @ Repo-ck  • AUR packagesZsh and other configs

Offline

#7 2012-08-28 17:04:17

Kopfweh
Member
Registered: 2011-08-06
Posts: 77

Re: [SOLVED] Kernel Panics on boot w/ 3.4.x-ARCH and 3.5.x-ck

graysky wrote:

OK. I wanted to ounderstand if this is caused by the ck patchset or not.  Based on what you wrote, I believe it is not.

I'm using the regular kernel form the official core repo and I've the problem with kernel panics at boot, too. So if we've got the same problem, than it's not caused by the ck patchset...I rather thought it might be caused by e4rat-preload. Do you use this?

edit: wiki-page:
https://wiki.archlinux.org/index.php/E4rat

Last edited by Kopfweh (2012-08-28 17:05:46)

Offline

#8 2012-08-28 18:00:16

scott_fakename
Member
Registered: 2012-08-15
Posts: 92

Re: [SOLVED] Kernel Panics on boot w/ 3.4.x-ARCH and 3.5.x-ck

I just upgraded my kernel too from the core repos, and ever since then it *sometimes* won't boot. I don't know if it's the same thing.

The time at which it freezes is where it would normally switch from the first console resolution to the better, higher console resolution (if that makes sense). Then sometimes it will give me a screen of vertical green lines and lock up completely, or it might just give me a black screen and lock up completely, or it might just boot up fine, with no problems. Fallback initramfs behaves the same.

Is this similar to your problem? I only mention it here because the timing is coincident. If it's completely different I'll make my own post.

Offline

#9 2012-08-28 21:03:13

@op
Member
Registered: 2011-04-05
Posts: 49

Re: [SOLVED] Kernel Panics on boot w/ 3.4.x-ARCH and 3.5.x-ck

This seems familiar, do you have TLP installed?

If so disable it and try again. Maybe you have set the DEVICES_TO_DISABLE_ON_STARTUP property, clear this one.

Offline

#10 2012-08-28 21:53:55

graysky
Wiki Maintainer
From: :wq
Registered: 2008-12-01
Posts: 10,592
Website

Re: [SOLVED] Kernel Panics on boot w/ 3.4.x-ARCH and 3.5.x-ck

@K - I had problems with e4rat before.  Disable it and see it your problem is fixed.


CPU-optimized Linux-ck packages @ Repo-ck  • AUR packagesZsh and other configs

Offline

#11 2012-09-02 02:14:30

robotangel
Member
From: cologne/germany
Registered: 2007-08-30
Posts: 63

Re: [SOLVED] Kernel Panics on boot w/ 3.4.x-ARCH and 3.5.x-ck

Hi there,

sorry I didn't answer for so long, had a lot to do. I don't use e4rat, it probably wouldn't make sense on a SSD anyway. I don't think the problem is the i915 driver, either. When I include i915 into my initramfs there are no problems with KMS, it boots up until it crashes. As a last resort, I tried to reinstall the whole system... with no luck. The kernel panics still occur at almost every start. Unfourtunately I really can't live with that so I tried installing feodra. The fedora kernel (3.5.2-3.fc17 atm) just works, I didn't see one kernel panic until yet (and I have started the system quite a few times now).

That said, I'm really willing to get this fixed and file bug reports as I love Arch and want to continue using it, but that's just not possible for me atm. The problem is, I have no idea where to start looking for the error and the reason it occurs as it always panics with a different error in different stages of the boot process (mostly, the last thing I see is the OK for mounting all my partitions).

So, please help me and tell me where I can start looking, I will try to install arch on a usb stick or something in the next few days to be able to reproduce any steps neccessary.

Thank you smile

edit: TLP wasn't installed as my laptop isn't supported by it anyway. I used laptop-mode-tools, but even when I hadn't installed lmt it crashed

Last edited by robotangel (2012-09-02 02:18:05)

Offline

#12 2012-09-02 02:42:56

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [SOLVED] Kernel Panics on boot w/ 3.4.x-ARCH and 3.5.x-ck

I've seen one kernel panic in the last couple of days with systemd right after seeing the OK for all partitions mounted, too. The last thing I saw was that target swap was reached OK. Then I got:

BUG: unable to handle kernel NULL pointer dereference at 0000...0018
...
Shutting down cpus with NMI.
panic occurred...

But I don't know if it is related. I'm also using i915 on a ThinkPad. I don't have TLP installed or e4rat. But, again, I've only seen this once.


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#13 2012-09-02 11:02:23

Whef
Member
Registered: 2012-08-26
Posts: 33

Re: [SOLVED] Kernel Panics on boot w/ 3.4.x-ARCH and 3.5.x-ck

Oh my God guys, am I your man today. GET. EXCITED. But first, some background.

So basically, for the past 5 days I've been ripping my balls off over random kernel panics at boot. I just got my ASUS Zenbook Prime UX31A laptop, and heading into college I know one thing: I'm switching to Linux. Arch Linux is particularly badass, so the first thing I did was

dd if=/dev/urandom of=/dev/sda

and let that sit for 6 hours getting rid of Windows. This was on the 23rd of last month.

Then, it was time to install Arch Linux. I had practiced a few months back in a VM and managed to do it successfully several times, so I wasn't too worried. Unfortunately, by the time my laptop arrived Arch had ditched the GUI installer in favor of manual commandline installations. So, I really had no idea what I was doing and had to relearn the entire process. Furthermore, I had to learn about all this stuff I had no idea about (partitioning, bootloaders, UEFI, etc.). As it turns out I guess it was kind of a good thing because in the end I've learned a lot more about my system.

When I was finally ready to make the jump and install Arch fur reelz on my laptop I followed everything to the letter, and it didn't work. To this day I'm still unsure if I did something wrong, but whatever the case the BIOS simply wasn't recognizing anything bootable. As it seems, the UX31A BIOS isn't backward compatible with BIOS. That is to say, it's solely UEFI (could be wrong, but I'm using UEFI now fine). So, I had to go out and learn everything about UEFI (something I earlier decided against, in favor of GRUB+standard BIOS).

Since I was going with UEFI, I figured I might as well take advantage of the epic new EFISTUB featured in the kernel, allowing the kernel to effectively boot itself. And so it was, I delved into the confusion and ambiguity of UEFI technology and the lack of accessible information on the subject. Eventually I figured it out and got my laptop booting into UEFI mode, figured how booting works and all that jazz (which I won't go into...), but needless to say it was another setback.

Finally, once I got Arch Linux up and running I noticed something odd. About half the time I booted, I would hang on a black screen. Sometimes my caps lock key would flash, and after a Google of what that meant I knew I was in trouble. And a very small percentage of the time I would actually see a stack trace from a kernel panic. For a while I ignored it, but eventually it got to the point where it was the only remaining issue with my Arch install and I had to face it.

Prior to this occurrence I was working on getting my consolefonts working with systemd. This involved me adding the Intel i915 driver to MODULES in /etc/mkinitcpio.conf. When I did this, I noticed two things: 1. I could always see the kernel panics. 2. The kernel panics happened much more frequently. For this reason, I think this bug may somehow be interlinked with the i915 drivers (though they are not to blame).

So, what does all of this have to do with your issue? Basically, nothing. I just wanted to tell a story to sympathetic ears. big_smile At any rate, I finally started on this problem. Since my root path is encrypted, on startup I get the encrypt hook and it asks me for my password. I observed that I could leave it at the password prompt indefinitely and I would not kernel panic, and that there was a 0% chance of kernel panics before I entered my password. This was key in solving the issue, because it gave me and my friend, who was instrumental in helping me solve it, an idea of where in the boot process the error was occurring.

In fact, the error didn't happen until a few seconds after the boot – sometimes even after I reached the login prompt. Because of this, me and my friend (okay, primarily my friend) realized that the issue was when systemd started to load extra modules, not required for system boot, such as the ones found in initramfs. It was really just a hunch – but one that would pay off.

This is where it gets cool. I extracted three pieces of information from my system: 1. All the modules loaded at boot (when I successfully booted with the issue) using lsmod. 2. All the modules loaded by the initramfs from autodetect, using mkinitcpio -M. 3. All the modules loaded by initramfs hooks using mkinitcpio -v.

With these three pieces of information and some DOPE scripting, I was able to construct a list of all the modules loaded that weren't part of initramfs. As it turned out, it came to a total of 31 modules. If we operate under the assumption that it's a single module going out of control, then simple math tells us that 5 binary splits would give find us which module it was (2^5 = 32).

With this in mind, and tons, and tons, and tons.... and TONS of restarting, entering my 20 character randomly generated encryption password with symbols, mixed case and digits... I am able to present to you the defective module.

btusb

To disable it, simply blacklist it using kmod (works on both systemd and SysV).

I don't know what btusb does, because the first thing after finding this was Google “btusb kernel panics,” and this is the first thing I got. Thanks to OP for posting lsmod in the thread so Google could find it.

Here's some pictures of the kernel panics I received:
http://i.imgur.com/wwJfH.jpg
http://i.imgur.com/tqTKO.jpg
http://i.imgur.com/Q71Ir.jpg

FAQ
Q: But Whef, what are we going to do now that you solved all of our problems? We have no purpose!
A: Now? NOW?!?! NOW WE FIND WHO'S TO BLAME FOR THIS NONSENSE!!!!!!!!! ONWARDS!!!!!!!!!!!

Last edited by Whef (2012-09-02 11:14:39)

Offline

#14 2012-09-02 11:24:49

graysky
Wiki Maintainer
From: :wq
Registered: 2008-12-01
Posts: 10,592
Website

Re: [SOLVED] Kernel Panics on boot w/ 3.4.x-ARCH and 3.5.x-ck

@Whef - tl; dr.  The forums aren't a personal blog.  The value in your post is diluted with all the extraneous info you added to it hmm

$ modinfo btusb

Last edited by graysky (2012-09-02 11:28:32)


CPU-optimized Linux-ck packages @ Repo-ck  • AUR packagesZsh and other configs

Offline

#15 2012-09-02 11:28:42

Whef
Member
Registered: 2012-08-26
Posts: 33

Re: [SOLVED] Kernel Panics on boot w/ 3.4.x-ARCH and 3.5.x-ck

graysky wrote:

@Whef - tl; dr.  The forums aren't a personal blog.  The value in your post is diluted with all the extraneous info you added to it hmm

Luckily, I disagree, because after several days ramming my head against this I would have gladly read an entire novel if it meant finding a solution. Anyways, it's a fun read. big_smile

Offline

#16 2012-09-02 14:38:19

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [SOLVED] Kernel Panics on boot w/ 3.4.x-ARCH and 3.5.x-ck

I've seen bluetooth related stuff cause kernel panics under Linux before. (Last time it was absolutely reliable but I had no idea at that point of how I might stop it happening.)

I'm reluctant to disable bluetooth and I've only seen one panic which might not even be related...

@Whef,
What makes you think the problem is "interlinked with the i915 drivers"?


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#17 2012-09-02 19:27:45

robotangel
Member
From: cologne/germany
Registered: 2007-08-30
Posts: 63

Re: [SOLVED] Kernel Panics on boot w/ 3.4.x-ARCH and 3.5.x-ck

Whef wrote:

Luckily, I disagree, because after several days ramming my head against this I would have gladly read an entire novel if it meant finding a solution.

/sign.

Well, I tried to do this on my freshly installed arch-on-a-usb-key. And well, what am I supposed to say? IT WORKED. It really seems like the btusb module is causing all that trouble, I restarted the system at least 10 times now and there wasn't a single kernel panic. Of course I'm just asking myself whether I should try to install arch on my internal harddisk again and get rid of fedora, but frankly I'm not feeling well with this. I mean, the btusb module worked just fine under fedora, too and when I manually load it after the system has booted up, there isn't anything to complain about, either.

I think I'll try to do it, wish me luck (it better won't fail! I really could imagine myself getting pretty angry if it won't work!). Anyhow, my offer still holds: If anyone could assist me and point me to the right directions, I'm willing to do whatever it needs to solve this issue (I want to be able to use my bluetooth module, after all...).

Thank all of you very, very much so far, you've been of great help smile

Offline

#18 2012-09-02 19:55:15

Whef
Member
Registered: 2012-08-26
Posts: 33

Re: [SOLVED] Kernel Panics on boot w/ 3.4.x-ARCH and 3.5.x-ck

@cfr It's nothing concrete, just a guess. The evidence is this:
1. Under normal boot, the display would turn off and the i915 drivers would load up. When experiencing issues with btusb, 9 times out of 10 it would kernel panic in synchronization with the screen turning off, such that it wouldn't even turn back on without the drivers and I couldn't see the kernel panic. The reliability of the timing of the kernel panic right when the screen turned off for what would be a normal graphics driver load is suspicious.
2. When putting the i915 drivers in the initramfs, causing them to be loaded BEFORE the btusb module had time to load, the frequency of the kernel panics increased dramatically. My working theory is that it's a race condition between btusb and the i915 driver, which is supported by the fact that in the kernel panic the functions messing up is get_next_timer_interrupt.

@robotangel Good luck. And I can't imagine it taking too long to fix such a severe issue with the modules, now that we have a good idea of where the issue lies.

Last edited by Whef (2012-09-02 20:16:36)

Offline

#19 2012-10-02 20:09:52

prurigro
Member
Registered: 2008-03-14
Posts: 18

Re: [SOLVED] Kernel Panics on boot w/ 3.4.x-ARCH and 3.5.x-ck

@Whef: Thank you so much for posting your findings! I've been trying to figure this out for months now, and even began to give into the idea that it would be a problem until some future kernel upgrade happened to tweak the offending code in just the right way. I never would have guessed it was something so simple, though that's not to imply that figuring it out would have been. Anyway, your efforts are very much appreciated- Thanks again!

EDIT: It seems like everything is still good after adding 'modprobe btusb' to /etc/rc.local to get bluetooth support back.

Last edited by prurigro (2012-10-02 20:34:13)

Offline

Board footer

Powered by FluxBB