Most recent kernel where this bug did *NOT* occur: Distribution: Gentoo Linux 2006.1 x86_64 Hardware Environment: HP Pavilion dv6146eu Software Environment: Problem Description: Steps to reproduce:
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..