Bug 8195

Created attachment 10749 [details]
dmesg while booted with noapic

Created attachment 10750 [details]
/proc/interrupts while booted with noapic

If system doesn't block while initializing the clock I have no problem

Created attachment 10751 [details]
dmesg while booted normal

Created attachment 10752 [details]
/proc/interrupts while booted normal

What is the latest kernel that works with no cmdline workarounds?

What, exactly, is the failure?
Does it happen only sometimes, and the "normal" dmesg below
is from one of the times it did not happen?
If yes, where in the dmesg would the hang be if it occurred?

> Nvidia board detected. Ignoring ACPI timer override.
> If you got timer trouble try acpi_use_timer_override

What do you see when you follow this advice?

Any difference booting with nmi_watchdog=0?

re: noapic
> spurious 8259A interrupt: IRQ15.
> irq 7: nobody cared (try booting with the "irqpoll" option)

Why were you using "noapic"?
Does the hang also occur in noapic mode?

yes, the failure happen only sometimes (and only if I boot without noapic), and
the "normal" dmesg is from one of the times it did not happen.
If I use acpi=off I can't boot
If I use acpi_use_timer_override or acpi_use_timer_override system sometimes
hangs on "Setting system clock using the hardware clock"
If I boot without option system sometimes hangs on "Setting system clock using
the hardware clock"
If I boot with noapic & irqpoll I have same problem
Now I have to try with nmi_watchdog=0
Thanks

no indication this is related to ACPI itself,
throwing it over the wall timers sub-system.

I expect the first thing they'll ask is for you to boot with 
hres=off, then they'll ask you to try the latest 2.6.21

On Wed, 2007-03-14 at 18:15 -0700, bugme-daemon@bugzilla.kernel.org
wrote:
> no indication this is related to ACPI itself,
> throwing it over the wall timers sub-system.
> 
> I expect the first thing they'll ask is for you to boot with 
> hres=off, then they'll ask you to try the latest 2.6.21

No. I won't ask that, because 2.6.20 has no high res timers :)

Also the hardware clock setting is RTC subsystem and not related to
timers / clocksources et al. (CC-ed David).

Paky,

booting with noapic on a SMP box does not make much sense. Does the
problem ever happen when you boot w/o "noapic" on the commandline ?

If yes, is the box completely stuck or does SysRq-T work ?

Thanks,

	tglx

Reply-To: david-b@pacbell.net

http://bugzilla.kernel.org/show_bug.cgi?id=8195

On Thursday 15 March 2007 1:39 am, Thomas Gleixner wrote:
> Also the hardware clock setting is RTC subsystem and not related to
> timers / clocksources et al. (CC-ed David).

I can't make much sense of this bug report, but I don't
see anything related to RTCs.  The oddness relates to irq #7,
which ISTR is normally parport but gets mapped to EHCI given
the "noapic" flag; and that rtc would use irq #8 instead.

This looks to be just another case of bogus IRQ mapping.
Nothing related to RTC or USB.

Hi.

I can confirm this issue with a HP Pavilion DV9205us. It has a similar hardware
(chipset nforce-mcp51...)

I proceeded the same steps by Paky described in "Additional Comment #7" and I
have the same results.

Booting w/o noapic, the kernel hangs (only sometimes) when run hwclock to
read/set the clock.

Does the issue exist w/ 2.6.21-rc6?

Finally I tried kernel 2.6.21..
The system seem to boot normal without kernel options..
and all seems to go good!!
thank you, Linux!
thank you all..