public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Witbrodt <dawitbro@sbcglobal.net>
To: linux-kernel@vger.kernel.org
Cc: Yinghai Lu <yhlu.kernel@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: HPET regression in 2.6.26 versus 2.6.25
Date: Tue, 5 Aug 2008 15:16:37 -0700 (PDT)	[thread overview]
Message-ID: <502507.7481.qm@web82105.mail.mud.yahoo.com> (raw)



> please boot with "debug apic=verbose initcall_debut" to check exactly
> where it hangs...

In my OP, I mentioned that I submitted a bug report to the Debian BTS
before coming to LKML.  I hoped to keep the bug an internal Debian matter,
since the kernels I compile were always from Debianized kernel sources.

Below I comply with your request, booting the kernel built from the HEAD
of the git tree I downloaded yesterday, dated 
    Fri Aug 1 14:59:11 2008 -0700

and with commit ID
    2b12a4c524812fb3f6ee590a02e65b95c8c32229


Before continuing, I would like to mention that in my original post to
the Debian BTS, I reported the last lines on the screen for several
kernels booted with "debug earlyprink=vga initcall_debug loglevel=7".
I originally thought I was to blame -- some error in my '.config' --
so, unfortunately, I made a lot of irrelevant noise in the Debian BTS
thread as I scrambled to determine the cause of the freeze.  So maybe
the info there is not useful at all, but here is the link again, 
Just In Case:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493479


OK, now booting 2.6.27-rc1 with "ro debug apic=verbose initcall_debug"...
Here is the last visible output before the freeze:
=========================================

calling chr_dev_init+0x0/0xa2
initcall chr_dev_init returned 0 after 0 msecs
calling firmware_class_init+0x0/0x71
initcall firmware_class_init returned 0 after 0 msecs
calling loopback_init+0x0/0xc
initcall loopback_init returned 0 after 0 msecs
calling cpufreq_gov_performance_init+0x0/0xc
initcall cpufreq_gov_performance_init returned 0 after 0 msecs
calling init_acpi_pm_clocksource+0x0/0xb4
initcall init_acpi_pm_clocksource returned 0 after 0 msecs
calling pci_bios_assign_resources+0x0/0x8b
pci 0000:00:01.0: PCI bridge, secondary bus 0000:01
pci 0000:00:01.0:   IO window: 0xe000-0xefff
pci 0000:00:01.0:   MEM window: 0xfdd00000-0xfdefffff
pci 0000:00:01.0:   PREFETCH window: 0x000000d8000000-0x000000dfffffff
pci 0000:00:14.4: PCI bridge, secondary bus 0000:02
pci 0000:00:14.4:   IO window: 0xd000-0xdfff
pci 0000:00:14.4:   MEM window: 0xfdc00000-0xfdcfffff
pci 0000:00:14.4:   PREFETCH window: 0x000000fdf00000-0x000000fdffffff
initcall pci_bios_assign_resources returned 0 after 285696 msecs
calling inet_init+0x0/0x250
NET: Registered protocol family 2
=========================================

I can tell you that the "285696" figure is way off if "msecs" is
supposed to mean milliseconds.  It might be accurate if microseconds
are intended, but the entire process from GRUB handing off to the
kernel until the freeze occurs is just a few moments:  3 seconds at
the most, probably less.

This info was copied by hand.  I had no other way to transfer the info
into this post, so I apologize in advance for any errors.  I did
double check it, but some of those hex values are typos waiting to
happen....  (I'm pretty sure I got them right, though  ;)

Only 3 files were impacted by the commit that is causing the freeze
for my machine with the ECS mboard.  If you would like to give me
some code to insert in those files (or other files) that would 
print more helpful output during the boot, I would be more than
happy to give it a try.


Dave W.

             reply	other threads:[~2008-08-05 22:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-05 22:16 David Witbrodt [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-08-08 22:48 HPET regression in 2.6.26 versus 2.6.25 David Witbrodt
2008-08-08 10:32 David Witbrodt
2008-08-06  4:45 David Witbrodt
2008-08-05 21:12 David Witbrodt
2008-08-05 14:14 David Witbrodt
2008-08-05 19:19 ` Yinghai Lu
2008-08-04 23:57 David Witbrodt
2008-08-05 13:58 ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=502507.7481.qm@web82105.mail.mud.yahoo.com \
    --to=dawitbro@sbcglobal.net \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=yhlu.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox