You are not logged in.
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 )
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 !!
Solution: blacklist btusb module
Last edited by robotangel (2012-09-03 23:40:09)
Offline
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 packages • Zsh and other configs
Offline
Thank you for your reply
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 ?
Offline
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 packages • Zsh and other configs
Offline
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"
Last edited by robotangel (2012-08-28 12:31:03)
Offline
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 packages • Zsh and other configs
Offline
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
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
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
@K - I had problems with e4rat before. Disable it and see it your problem is fixed.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
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
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
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
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. 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
@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
$ modinfo btusb
Last edited by graysky (2012-09-02 11:28:32)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
@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
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.
Offline
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
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
Offline
@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
@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