EDIT: It seems like everything is still good after adding 'modprobe btusb' to /etc/rc.local to get bluetooth support back.
]]>@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.
]]>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
]]>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"?
@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.
]]>$ modinfo btusb
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!!!!!!!!!!!
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.
]]>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
]]>If so disable it and try again. Maybe you have set the DEVICES_TO_DISABLE_ON_STARTUP property, clear this one.
]]>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.
]]>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