[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Pinpointing faulty kernel driver?

On Wed, 04 Apr 2012 21:19:21 +0200, Lars Skovlund wrote:

> Sorry for the delay, I am rather busy at the moment.

No problem.

> On Wed, Mar 28, 2012 at 04:14:05PM +0000, Camaleón wrote:


>> > I read the manual and found out how to drop into the initramfs debug
>> > shell, but I am unsure how to proceed from here. I guess the problem
>> > could be a faulty driver that I need to disable, but I know of no
>> > (efficient) way to find out which one. Ideally, I would load one
>> > driver at a time, and see when the problem occurs.
>> > 
>> > Can anyone help? Or am I completely off track with this problem?
>> Can you take a snapshot of the screen and upload somewhere? Maybe there
>> is additional info alongside the "Waiting for /dev to be fully
>> populated" message that can provide any insightful information about
>> the source of the problem.
> I realize this complicates matters a lot, but the exact crash points are
> different each time. So I need to somehow get the log information out in
> text format and put it somewhere. I had the idea of getting udev to spit
> out copious amounts of debug information. The interesting thing is when
> I do this, 3.1.x seems to get stuck for a while waiting for timeouts. It
> does, however, still boot - unlike 3.2.x.
> Any ideas as to how I can get the information out without resorting to
> screendumps?

You can send the output to another machine using a serial cable and 
instructing the kernel to dump the message there. I had to do this years 
ago to debug a kernel crash from a VM but to be sincere, I doubt I can 
nowadays repeat that milestone, I don't remember the steps :-)

Look, Ubuntu has some good doc about this:

Kernel Debugging Tricks

The easiest way (which will allow you to read the screen) would be  
slowing the kernel output messages, I would start from there.

>> > I am running the latest packages in both kernel series, and the 3.1
>> > series does not have the problem.
>> Are you using any special kernel module that may require to be re-
>> compiled (as for example, the VGA driver) or any special module for the
>> hard disk controller?
> My list of loaded modules follows (taken from 3.1.x). I have had some
> complaints about missing wifi firmware for a while (this is a desktop
> box, so I don't care about it) even though I have both
> linux-firmware-(non)free packages installed.

A message warning for a missing firmware could render that device 
inoperable but nothing more.

> Your help is very much appreciated.


Thanks for the module listing :-)

It seems that you're using a usual SATA configuration at the BIOS (ahci), 
I mean, nothing "fancy" that may require for specific hard disk 
controller module to be present and thus preventing the system from 
booting normally. 

Anyway, you can check if by appending "rootdelay=9" to the kernel line at 
GRUB's boot menu you can get rid of the "waiting... to be fully 
populated" message.



Reply to: