Re: PROBLEM: E6850 has an 8+ minute delay during boot
On Dec 15, 2007 1:07 AM, Len Brown <[EMAIL PROTECTED]> wrote: > > try CONFIG_HIGH_RES_TIMERS=n > try "hpet=disable" The problem still manifests when I unset CONFIG_HIGH_RES_TIMERS, CONFIG_HPET_TIMER, and CONFIG_NO_HZ (for good measure) in the kernel config. The delay occurs later in the bootup process now. Here's a dmesg snippet: [ 31.895755] TCP established hash table entries: 131072 (order: 8, 1048576 bytes) [ 31.896046] TCP bind hash table entries: 65536 (order: 7, 524288 bytes) [ 31.896203] TCP: Hash tables configured (established 131072 bind 65536) [ 31.896244] TCP reno registered [ 31.907674] checking if image is initramfs... it is [ 541.796307] Freeing initrd memory: 44299k freed [ 541.796748] audit: initializing netlink socket (disabled) [ 541.796798] audit(1197764951.576:1): initialized Thanks, Arun = Full dmesg: [0.00] Initializing cgroup subsys cpuset [0.00] Linux version 2.6.24-rc5 ([EMAIL PROTECTED]) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #2 SMP Sat Dec 15 23:38:57 EST 2007 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 00099c00 (usable) [0.00] BIOS-e820: 00099c00 - 000a (reserved) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - 7fe9 (usable) [0.00] BIOS-e820: 7fe9 - 7fee3000 (ACPI NVS) [0.00] BIOS-e820: 7fee3000 - 7fef (ACPI data) [0.00] BIOS-e820: 7fef - 7ff0 (reserved) [0.00] BIOS-e820: e000 - f000 (reserved) [0.00] BIOS-e820: fec0 - 0001 (reserved) [0.00] 1150MB HIGHMEM available. [0.00] 896MB LOWMEM available. [0.00] found SMP MP-table at 000f3f00 [0.00] Entering add_active_range(0, 0, 523920) 0 entries of 256 used [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] Normal 4096 -> 229376 [0.00] HighMem229376 -> 523920 [0.00] Movable zone start PFN for each node [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 -> 523920 [0.00] On node 0 totalpages: 523920 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 4064 pages, LIFO batch:0 [0.00] Normal zone: 1760 pages used for memmap [0.00] Normal zone: 223520 pages, LIFO batch:31 [0.00] HighMem zone: 2301 pages used for memmap [0.00] HighMem zone: 292243 pages, LIFO batch:31 [0.00] Movable zone: 0 pages used for memmap [0.00] DMI 2.5 present. [0.00] ACPI: RSDP 000F97A0, 0024 (r2 DELL ) [0.00] ACPI: XSDT 7FEE3080, 005C (r1 DELLFX0942302E31 AWRD0) [0.00] ACPI: FACP 7FEE7200, 00F4 (r3 DELLFX0942302E31 AWRD0) [0.00] ACPI: DSDT 7FEE3200, 3FFC (r1 DELL AWRDACPI 1000 MSFT 300) [0.00] ACPI: FACS 7FE9, 0040 [0.00] ACPI: HPET 7FEE73C0, 0038 (r1 DELLFX0942302E31 AWRD 98) [0.00] ACPI: MCFG 7FEE7400, 003C (r1 DELLFX0942302E31 AWRD0) [0.00] ACPI: SLIC 7FEE7440, 0176 (r1 DELLFX0942302E31 AWRD0) [0.00] ACPI: DMY2 7FEE75C0, 0080 (r1 DELLFX0942302E31 AWRD0) [0.00] ACPI: APIC 7FEE7300, 0084 (r1 DELLFX0942302E31 AWRD0) [0.00] ACPI: SSDT 7FEE7CA0, 0380 (r1 PmRefCpuPm 3000 INTL 20041203) [0.00] ACPI: PM-Timer IO Port: 0x408 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] Processor #0 6:15 APIC version 20 [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) [0.00] Processor #1 6:15 APIC version 20 [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled) [0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled) [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1]) [0.00] ACPI: IOAPIC (id[0x04] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 4, version 32, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] ACPI: IRQ0 used by override. [0.00] ACPI: IRQ2 used by override. [0.00] ACPI: IRQ9 used by override. [0.00] Enabling APIC mode: Flat. Using 1 I/O APICs [0.00] Using ACPI (MADT) for SMP configuration information [0.00] Allocating
Re: PROBLEM: E6850 has an 8+ minute delay during boot
On Dec 15, 2007 1:07 AM, Len Brown [EMAIL PROTECTED] wrote: snip try CONFIG_HIGH_RES_TIMERS=n try hpet=disable The problem still manifests when I unset CONFIG_HIGH_RES_TIMERS, CONFIG_HPET_TIMER, and CONFIG_NO_HZ (for good measure) in the kernel config. The delay occurs later in the bootup process now. Here's a dmesg snippet: [ 31.895755] TCP established hash table entries: 131072 (order: 8, 1048576 bytes) [ 31.896046] TCP bind hash table entries: 65536 (order: 7, 524288 bytes) [ 31.896203] TCP: Hash tables configured (established 131072 bind 65536) [ 31.896244] TCP reno registered [ 31.907674] checking if image is initramfs... it is [ 541.796307] Freeing initrd memory: 44299k freed [ 541.796748] audit: initializing netlink socket (disabled) [ 541.796798] audit(1197764951.576:1): initialized Thanks, Arun = Full dmesg: [0.00] Initializing cgroup subsys cpuset [0.00] Linux version 2.6.24-rc5 ([EMAIL PROTECTED]) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #2 SMP Sat Dec 15 23:38:57 EST 2007 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 00099c00 (usable) [0.00] BIOS-e820: 00099c00 - 000a (reserved) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - 7fe9 (usable) [0.00] BIOS-e820: 7fe9 - 7fee3000 (ACPI NVS) [0.00] BIOS-e820: 7fee3000 - 7fef (ACPI data) [0.00] BIOS-e820: 7fef - 7ff0 (reserved) [0.00] BIOS-e820: e000 - f000 (reserved) [0.00] BIOS-e820: fec0 - 0001 (reserved) [0.00] 1150MB HIGHMEM available. [0.00] 896MB LOWMEM available. [0.00] found SMP MP-table at 000f3f00 [0.00] Entering add_active_range(0, 0, 523920) 0 entries of 256 used [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] Normal 4096 - 229376 [0.00] HighMem229376 - 523920 [0.00] Movable zone start PFN for each node [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 - 523920 [0.00] On node 0 totalpages: 523920 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 4064 pages, LIFO batch:0 [0.00] Normal zone: 1760 pages used for memmap [0.00] Normal zone: 223520 pages, LIFO batch:31 [0.00] HighMem zone: 2301 pages used for memmap [0.00] HighMem zone: 292243 pages, LIFO batch:31 [0.00] Movable zone: 0 pages used for memmap [0.00] DMI 2.5 present. [0.00] ACPI: RSDP 000F97A0, 0024 (r2 DELL ) [0.00] ACPI: XSDT 7FEE3080, 005C (r1 DELLFX0942302E31 AWRD0) [0.00] ACPI: FACP 7FEE7200, 00F4 (r3 DELLFX0942302E31 AWRD0) [0.00] ACPI: DSDT 7FEE3200, 3FFC (r1 DELL AWRDACPI 1000 MSFT 300) [0.00] ACPI: FACS 7FE9, 0040 [0.00] ACPI: HPET 7FEE73C0, 0038 (r1 DELLFX0942302E31 AWRD 98) [0.00] ACPI: MCFG 7FEE7400, 003C (r1 DELLFX0942302E31 AWRD0) [0.00] ACPI: SLIC 7FEE7440, 0176 (r1 DELLFX0942302E31 AWRD0) [0.00] ACPI: DMY2 7FEE75C0, 0080 (r1 DELLFX0942302E31 AWRD0) [0.00] ACPI: APIC 7FEE7300, 0084 (r1 DELLFX0942302E31 AWRD0) [0.00] ACPI: SSDT 7FEE7CA0, 0380 (r1 PmRefCpuPm 3000 INTL 20041203) [0.00] ACPI: PM-Timer IO Port: 0x408 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] Processor #0 6:15 APIC version 20 [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) [0.00] Processor #1 6:15 APIC version 20 [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled) [0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled) [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1]) [0.00] ACPI: IOAPIC (id[0x04] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 4, version 32, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] ACPI: IRQ0 used by override. [0.00] ACPI: IRQ2 used by override. [0.00] ACPI: IRQ9 used by override. [0.00] Enabling APIC mode: Flat. Using 1 I/O APICs [0.00] Using ACPI (MADT) for SMP configuration information [0.00] Allocating PCI
Re: PROBLEM: E6850 has an 8+ minute delay during boot
On Friday 14 December 2007 04:10, Arun Thomas wrote: > Hi, > > My Dell Vostro desktop w/ an Intel E6850 dual-core 3GHz CPU has an 8+ > minute delay during boot. The machine seems to run fine after it > boots. The problem occurs on the Ubuntu gutsy 2.6.22-14 kernel, > 2.6.23.9, and 2.6.24-rc5. I have upgraded to the most recent Dell BIOS > version (1.0.8). I am running an SMP kernel currently, but the problem > presents itself in uniprocessor mode (nosmp) also. I'm running the > machine in 32-bit mode w/hyperthreading configured. > > Here are a few interesting things in the dmesg output for the > 2.6.24-rc5 kernel (smp). The full dmesg is also included farther down. > > [ 20.101501] CPU: After generic identify, caps: bfebfbff 2010 > e3fd 0001 > [ 20.101505] monitor/mwait feature present. > [ 20.101506] using mwait in idle threads. > [ 20.101508] CPU: L1 I cache: 32K, L1 D cache: 32K > [ 20.101509] CPU: L2 cache: 4096K > [ 20.101511] CPU: Physical Processor ID: 0 > [ 20.101511] CPU: Processor Core ID: 0 > [ 20.101513] CPU: After all inits, caps: bfebfbff 2010 > 3940 e3fd 0001 > [ 20.101517] Compat vDSO mapped to e000. > [ 20.101525] Checking 'hlt' instruction... OK. > [ 20.117651] SMP alternatives: switching to UP code > [ 20.118574] ACPI: Core revision 20070126 > [ 20.175154] CPU0: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz stepping > 0b > [ 20.175163] SMP alternatives: switching to SMP code > [ 20.175437] Booting processor 1/1 eip 3000 > [ 20.185881] Initializing CPU#1 > [ 527.926587] Calibrating delay using timer specific routine.. > 200566.59 BogoMIPS (lpj=401133185) > [ 527.926592] CPU: After generic identify, caps: bfebfbff 2010 try CONFIG_HIGH_RES_TIMERS=n try "hpet=disable" -Len -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
Arun Thomas wrote: On Dec 14, 2007 2:01 PM, H. Peter Anvin <[EMAIL PROTECTED]> wrote: Thomas Gleixner wrote: The problem is caused by an SMI during the calibration routine. We really need to come up with a solid solution which does not rely on the periodic timer coming in, when there is something else (HPET, pm_timer) available. How long is the SMI? Is there some instrumentation code somewhere which would allow me to determine this? If not, can you give me some hints on where to add the instrumentation code? Well, the most obvious way to do it would be to run the calibration loop a large number of times, and observe the statistical variation. In particular, one should see a bi- or multimodal pattern where the difference between the peaks amount to the "lost time". When we have a clue about the loss of time then we can figure out how to detect it. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
On Dec 14, 2007 2:01 PM, H. Peter Anvin <[EMAIL PROTECTED]> wrote: > Thomas Gleixner wrote: > > > > The problem is caused by an SMI during the calibration routine. We > > really need to come up with a solid solution which does not rely on > > the periodic timer coming in, when there is something else (HPET, > > pm_timer) available. > > How long is the SMI? Is there some instrumentation code somewhere which would allow me to determine this? If not, can you give me some hints on where to add the instrumentation code? Thanks, Arun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
Thomas Gleixner wrote: The problem is caused by an SMI during the calibration routine. We really need to come up with a solid solution which does not rely on the periodic timer coming in, when there is something else (HPET, pm_timer) available. I have a look into this. Arun, do you have an USB keyboard plugged in ? If not, can you connect one and check, whether it changes things or not ? How long is the SMI? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
Thomas Gleixner wrote: .. Arun, do you have an USB keyboard plugged in ? If not, can you connect one and check, whether it changes things or not ? .. One of my two affected boxes has a USB mouse plugged in, and it makes no difference one way or another. No USB keyboards here, though. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
Arun Thomas wrote: ... [ 31.670148] TCP bind hash table entries: 65536 (order: 7, 524288 bytes) [ 31.670351] TCP: Hash tables configured (established 131072 bind 65536) [ 31.670391] TCP reno registered [ 31.681591] checking if image is initramfs...<7>Switched to high resolution mode on CPU 0 [ 540.133678] Clocksource tsc unstable (delta = 299978139535 ns) [ 540.137708] Time: hpet clocksource has been installed. [ 540.432798] it is [ 541.570364] Freeing initrd memory: 44428k freed [ 541.570748] audit: initializing netlink socket (disabled) ... Ahh... BINGO! This is very likely the same problem that I first reported back in 2.6.21(20?), when NOHZ and HPET first came in! It never occurred to me to wait a full 8-minutes though, so I just rebooted again after a 1-2 minute wait each time. Seen on Core2Duo T7400 and Core2Quad E6600 systems, with kernels 2.6.21/22 at various points. Not consistent -- sometimes it would boot after a few attempts, sometimes not. It always hung around the "Switched to high resolution mode" messages. Thomas Gleixner wrote: The problem is caused by an SMI during the calibration routine. We really need to come up with a solid solution which does not rely on the periodic timer coming in, when there is something else (HPET, pm_timer) available. ... Oh good, an explanation! Now we just need a creative fix. One thing that *might* be sufficient, would be to do the delay loop calibration twice, and compare the results to see if they're within 10% (pick a number) of each other. Is there a flag or something that SMI sets that we could poll before/after the calibration? That could be used to tell us that it needs redoing ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
On Dec 14, 2007 5:43 AM, Thomas Gleixner <[EMAIL PROTECTED]> wrote: > > Arun, do you have an USB keyboard plugged in ? If not, can you connect > one and check, whether it changes things or not ? I had a USB keyboard and mouse connected when I encountered the problem. Do you want me to try with a PS/2 keyboard/mouse? Thanks, Arun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
On Fri, 14 Dec 2007, Jiri Slaby wrote: > On 12/14/2007 11:01 AM, Arun Thomas wrote: > > On Dec 14, 2007 4:53 AM, Andrew Morton <[EMAIL PROTECTED]> wrote: > >> On Fri, 14 Dec 2007 04:10:31 -0500 "Arun Thomas" <[EMAIL PROTECTED]> wrote: > >> > > some time before: > [ 20.101392] Calibrating delay using timer specific routine.. > 5989.01 BogoMIPS (lpj=11978034) > > >>> [ 20.185881] Initializing CPU#1 > >>> [ 527.926587] Calibrating delay using timer specific routine.. > >>> 200566.59 BogoMIPS (lpj=401133185) > >> Silly question: is that delay actually observeable by a human, > >> or is it just a leap in the printk timestamping? > > > > Good question. Yes, it's human-observable. The kernel "hangs" for 8 > > mins by my wall clock, and then it continues to boot up. > > By the way, the same processor here, but > Calibrating delay using timer specific routine.. 5984.76 BogoMIPS > (lpj=11969527) > for the second core. > > The calibration is some kind of weird there. > > If any info needed from me, feel free to ask (x86_64 here). No problems with > it > here AFAIK. The problem is caused by an SMI during the calibration routine. We really need to come up with a solid solution which does not rely on the periodic timer coming in, when there is something else (HPET, pm_timer) available. I have a look into this. Arun, do you have an USB keyboard plugged in ? If not, can you connect one and check, whether it changes things or not ? Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
On 12/14/2007 11:01 AM, Arun Thomas wrote: > On Dec 14, 2007 4:53 AM, Andrew Morton <[EMAIL PROTECTED]> wrote: >> On Fri, 14 Dec 2007 04:10:31 -0500 "Arun Thomas" <[EMAIL PROTECTED]> wrote: >> some time before: [ 20.101392] Calibrating delay using timer specific routine.. 5989.01 BogoMIPS (lpj=11978034) >>> [ 20.185881] Initializing CPU#1 >>> [ 527.926587] Calibrating delay using timer specific routine.. >>> 200566.59 BogoMIPS (lpj=401133185) >> Silly question: is that delay actually observeable by a human, >> or is it just a leap in the printk timestamping? > > Good question. Yes, it's human-observable. The kernel "hangs" for 8 > mins by my wall clock, and then it continues to boot up. By the way, the same processor here, but Calibrating delay using timer specific routine.. 5984.76 BogoMIPS (lpj=11969527) for the second core. The calibration is some kind of weird there. If any info needed from me, feel free to ask (x86_64 here). No problems with it here AFAIK. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
On Dec 14, 2007 4:53 AM, Andrew Morton <[EMAIL PROTECTED]> wrote: > > On Fri, 14 Dec 2007 04:10:31 -0500 "Arun Thomas" <[EMAIL PROTECTED]> wrote: > > > [ 20.185881] Initializing CPU#1 > > [ 527.926587] Calibrating delay using timer specific routine.. > > 200566.59 BogoMIPS (lpj=401133185) > > Silly question: is that delay actually observeable by a human, > or is it just a leap in the printk timestamping? Good question. Yes, it's human-observable. The kernel "hangs" for 8 mins by my wall clock, and then it continues to boot up. Thanks, Arun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
On Fri, 14 Dec 2007 04:10:31 -0500 "Arun Thomas" <[EMAIL PROTECTED]> wrote: > My Dell Vostro desktop w/ an Intel E6850 dual-core 3GHz CPU has an 8+ > minute delay during boot. The machine seems to run fine after it > boots. The problem occurs on the Ubuntu gutsy 2.6.22-14 kernel, > 2.6.23.9, and 2.6.24-rc5. I have upgraded to the most recent Dell BIOS > version (1.0.8). I am running an SMP kernel currently, but the problem > presents itself in uniprocessor mode (nosmp) also. I'm running the > machine in 32-bit mode w/hyperthreading configured. > > Here are a few interesting things in the dmesg output for the > 2.6.24-rc5 kernel (smp). The full dmesg is also included farther down. > > [ 20.101501] CPU: After generic identify, caps: bfebfbff 2010 > e3fd 0001 > [ 20.101505] monitor/mwait feature present. > [ 20.101506] using mwait in idle threads. > [ 20.101508] CPU: L1 I cache: 32K, L1 D cache: 32K > [ 20.101509] CPU: L2 cache: 4096K > [ 20.101511] CPU: Physical Processor ID: 0 > [ 20.101511] CPU: Processor Core ID: 0 > [ 20.101513] CPU: After all inits, caps: bfebfbff 2010 > 3940 e3fd 0001 > [ 20.101517] Compat vDSO mapped to e000. > [ 20.101525] Checking 'hlt' instruction... OK. > [ 20.117651] SMP alternatives: switching to UP code > [ 20.118574] ACPI: Core revision 20070126 > [ 20.175154] CPU0: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz stepping > 0b > [ 20.175163] SMP alternatives: switching to SMP code > [ 20.175437] Booting processor 1/1 eip 3000 > [ 20.185881] Initializing CPU#1 > [ 527.926587] Calibrating delay using timer specific routine.. > 200566.59 BogoMIPS (lpj=401133185) > [ 527.926592] CPU: After generic identify, caps: bfebfbff 2010 > e3fd 0001 > [ 527.926595] monitor/mwait feature present. > [ 527.926596] CPU: L1 I cache: 32K, L1 D cache: 32K > [ 527.926597] CPU: L2 cache: 4096K > [ 527.926599] CPU: Physical Processor ID: 0 Silly question: is that delay actually observeable by a human, or is it just a leap in the printk timestamping? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
On Fri, 14 Dec 2007 04:10:31 -0500 Arun Thomas [EMAIL PROTECTED] wrote: My Dell Vostro desktop w/ an Intel E6850 dual-core 3GHz CPU has an 8+ minute delay during boot. The machine seems to run fine after it boots. The problem occurs on the Ubuntu gutsy 2.6.22-14 kernel, 2.6.23.9, and 2.6.24-rc5. I have upgraded to the most recent Dell BIOS version (1.0.8). I am running an SMP kernel currently, but the problem presents itself in uniprocessor mode (nosmp) also. I'm running the machine in 32-bit mode w/hyperthreading configured. Here are a few interesting things in the dmesg output for the 2.6.24-rc5 kernel (smp). The full dmesg is also included farther down. [ 20.101501] CPU: After generic identify, caps: bfebfbff 2010 e3fd 0001 [ 20.101505] monitor/mwait feature present. [ 20.101506] using mwait in idle threads. [ 20.101508] CPU: L1 I cache: 32K, L1 D cache: 32K [ 20.101509] CPU: L2 cache: 4096K [ 20.101511] CPU: Physical Processor ID: 0 [ 20.101511] CPU: Processor Core ID: 0 [ 20.101513] CPU: After all inits, caps: bfebfbff 2010 3940 e3fd 0001 [ 20.101517] Compat vDSO mapped to e000. [ 20.101525] Checking 'hlt' instruction... OK. [ 20.117651] SMP alternatives: switching to UP code [ 20.118574] ACPI: Core revision 20070126 [ 20.175154] CPU0: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz stepping 0b [ 20.175163] SMP alternatives: switching to SMP code [ 20.175437] Booting processor 1/1 eip 3000 [ 20.185881] Initializing CPU#1 [ 527.926587] Calibrating delay using timer specific routine.. 200566.59 BogoMIPS (lpj=401133185) [ 527.926592] CPU: After generic identify, caps: bfebfbff 2010 e3fd 0001 [ 527.926595] monitor/mwait feature present. [ 527.926596] CPU: L1 I cache: 32K, L1 D cache: 32K [ 527.926597] CPU: L2 cache: 4096K [ 527.926599] CPU: Physical Processor ID: 0 Silly question: is that delay actually observeable by a human, or is it just a leap in the printk timestamping? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
On 12/14/2007 11:01 AM, Arun Thomas wrote: On Dec 14, 2007 4:53 AM, Andrew Morton [EMAIL PROTECTED] wrote: On Fri, 14 Dec 2007 04:10:31 -0500 Arun Thomas [EMAIL PROTECTED] wrote: some time before: [ 20.101392] Calibrating delay using timer specific routine.. 5989.01 BogoMIPS (lpj=11978034) [ 20.185881] Initializing CPU#1 [ 527.926587] Calibrating delay using timer specific routine.. 200566.59 BogoMIPS (lpj=401133185) Silly question: is that delay actually observeable by a human, or is it just a leap in the printk timestamping? Good question. Yes, it's human-observable. The kernel hangs for 8 mins by my wall clock, and then it continues to boot up. By the way, the same processor here, but Calibrating delay using timer specific routine.. 5984.76 BogoMIPS (lpj=11969527) for the second core. The calibration is some kind of weird there. If any info needed from me, feel free to ask (x86_64 here). No problems with it here AFAIK. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
On Dec 14, 2007 4:53 AM, Andrew Morton [EMAIL PROTECTED] wrote: On Fri, 14 Dec 2007 04:10:31 -0500 Arun Thomas [EMAIL PROTECTED] wrote: [ 20.185881] Initializing CPU#1 [ 527.926587] Calibrating delay using timer specific routine.. 200566.59 BogoMIPS (lpj=401133185) Silly question: is that delay actually observeable by a human, or is it just a leap in the printk timestamping? Good question. Yes, it's human-observable. The kernel hangs for 8 mins by my wall clock, and then it continues to boot up. Thanks, Arun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
On Fri, 14 Dec 2007, Jiri Slaby wrote: On 12/14/2007 11:01 AM, Arun Thomas wrote: On Dec 14, 2007 4:53 AM, Andrew Morton [EMAIL PROTECTED] wrote: On Fri, 14 Dec 2007 04:10:31 -0500 Arun Thomas [EMAIL PROTECTED] wrote: some time before: [ 20.101392] Calibrating delay using timer specific routine.. 5989.01 BogoMIPS (lpj=11978034) [ 20.185881] Initializing CPU#1 [ 527.926587] Calibrating delay using timer specific routine.. 200566.59 BogoMIPS (lpj=401133185) Silly question: is that delay actually observeable by a human, or is it just a leap in the printk timestamping? Good question. Yes, it's human-observable. The kernel hangs for 8 mins by my wall clock, and then it continues to boot up. By the way, the same processor here, but Calibrating delay using timer specific routine.. 5984.76 BogoMIPS (lpj=11969527) for the second core. The calibration is some kind of weird there. If any info needed from me, feel free to ask (x86_64 here). No problems with it here AFAIK. The problem is caused by an SMI during the calibration routine. We really need to come up with a solid solution which does not rely on the periodic timer coming in, when there is something else (HPET, pm_timer) available. I have a look into this. Arun, do you have an USB keyboard plugged in ? If not, can you connect one and check, whether it changes things or not ? Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
On Dec 14, 2007 5:43 AM, Thomas Gleixner [EMAIL PROTECTED] wrote: Arun, do you have an USB keyboard plugged in ? If not, can you connect one and check, whether it changes things or not ? I had a USB keyboard and mouse connected when I encountered the problem. Do you want me to try with a PS/2 keyboard/mouse? Thanks, Arun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
Thomas Gleixner wrote: .. Arun, do you have an USB keyboard plugged in ? If not, can you connect one and check, whether it changes things or not ? .. One of my two affected boxes has a USB mouse plugged in, and it makes no difference one way or another. No USB keyboards here, though. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
Arun Thomas wrote: ... [ 31.670148] TCP bind hash table entries: 65536 (order: 7, 524288 bytes) [ 31.670351] TCP: Hash tables configured (established 131072 bind 65536) [ 31.670391] TCP reno registered [ 31.681591] checking if image is initramfs...7Switched to high resolution mode on CPU 0 [ 540.133678] Clocksource tsc unstable (delta = 299978139535 ns) [ 540.137708] Time: hpet clocksource has been installed. [ 540.432798] it is [ 541.570364] Freeing initrd memory: 44428k freed [ 541.570748] audit: initializing netlink socket (disabled) ... Ahh... BINGO! This is very likely the same problem that I first reported back in 2.6.21(20?), when NOHZ and HPET first came in! It never occurred to me to wait a full 8-minutes though, so I just rebooted again after a 1-2 minute wait each time. Seen on Core2Duo T7400 and Core2Quad E6600 systems, with kernels 2.6.21/22 at various points. Not consistent -- sometimes it would boot after a few attempts, sometimes not. It always hung around the Switched to high resolution mode messages. Thomas Gleixner wrote: The problem is caused by an SMI during the calibration routine. We really need to come up with a solid solution which does not rely on the periodic timer coming in, when there is something else (HPET, pm_timer) available. ... Oh good, an explanation! Now we just need a creative fix. One thing that *might* be sufficient, would be to do the delay loop calibration twice, and compare the results to see if they're within 10% (pick a number) of each other. Is there a flag or something that SMI sets that we could poll before/after the calibration? That could be used to tell us that it needs redoing ? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
Thomas Gleixner wrote: The problem is caused by an SMI during the calibration routine. We really need to come up with a solid solution which does not rely on the periodic timer coming in, when there is something else (HPET, pm_timer) available. I have a look into this. Arun, do you have an USB keyboard plugged in ? If not, can you connect one and check, whether it changes things or not ? How long is the SMI? -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
On Dec 14, 2007 2:01 PM, H. Peter Anvin [EMAIL PROTECTED] wrote: Thomas Gleixner wrote: The problem is caused by an SMI during the calibration routine. We really need to come up with a solid solution which does not rely on the periodic timer coming in, when there is something else (HPET, pm_timer) available. How long is the SMI? Is there some instrumentation code somewhere which would allow me to determine this? If not, can you give me some hints on where to add the instrumentation code? Thanks, Arun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
Arun Thomas wrote: On Dec 14, 2007 2:01 PM, H. Peter Anvin [EMAIL PROTECTED] wrote: Thomas Gleixner wrote: The problem is caused by an SMI during the calibration routine. We really need to come up with a solid solution which does not rely on the periodic timer coming in, when there is something else (HPET, pm_timer) available. How long is the SMI? Is there some instrumentation code somewhere which would allow me to determine this? If not, can you give me some hints on where to add the instrumentation code? Well, the most obvious way to do it would be to run the calibration loop a large number of times, and observe the statistical variation. In particular, one should see a bi- or multimodal pattern where the difference between the peaks amount to the lost time. When we have a clue about the loss of time then we can figure out how to detect it. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: E6850 has an 8+ minute delay during boot
On Friday 14 December 2007 04:10, Arun Thomas wrote: Hi, My Dell Vostro desktop w/ an Intel E6850 dual-core 3GHz CPU has an 8+ minute delay during boot. The machine seems to run fine after it boots. The problem occurs on the Ubuntu gutsy 2.6.22-14 kernel, 2.6.23.9, and 2.6.24-rc5. I have upgraded to the most recent Dell BIOS version (1.0.8). I am running an SMP kernel currently, but the problem presents itself in uniprocessor mode (nosmp) also. I'm running the machine in 32-bit mode w/hyperthreading configured. Here are a few interesting things in the dmesg output for the 2.6.24-rc5 kernel (smp). The full dmesg is also included farther down. [ 20.101501] CPU: After generic identify, caps: bfebfbff 2010 e3fd 0001 [ 20.101505] monitor/mwait feature present. [ 20.101506] using mwait in idle threads. [ 20.101508] CPU: L1 I cache: 32K, L1 D cache: 32K [ 20.101509] CPU: L2 cache: 4096K [ 20.101511] CPU: Physical Processor ID: 0 [ 20.101511] CPU: Processor Core ID: 0 [ 20.101513] CPU: After all inits, caps: bfebfbff 2010 3940 e3fd 0001 [ 20.101517] Compat vDSO mapped to e000. [ 20.101525] Checking 'hlt' instruction... OK. [ 20.117651] SMP alternatives: switching to UP code [ 20.118574] ACPI: Core revision 20070126 [ 20.175154] CPU0: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz stepping 0b [ 20.175163] SMP alternatives: switching to SMP code [ 20.175437] Booting processor 1/1 eip 3000 [ 20.185881] Initializing CPU#1 [ 527.926587] Calibrating delay using timer specific routine.. 200566.59 BogoMIPS (lpj=401133185) [ 527.926592] CPU: After generic identify, caps: bfebfbff 2010 try CONFIG_HIGH_RES_TIMERS=n try hpet=disable -Len -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
