Bug 355811 - Huge delays when booting the kernel
Summary: Huge delays when booting the kernel
Status: RESOLVED DUPLICATE of bug 346478
Alias: None
Product: openSUSE 11.0
Classification: openSUSE
Component: Kernel (show other bugs)
Version: Alpha 1
Hardware: i586 Other
: P5 - None : Critical (vote)
Target Milestone: ---
Assignee: E-mail List
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-23 23:02 UTC by Magnus Boman
Modified: 2008-01-26 17:30 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Magnus Boman 2008-01-23 23:02:07 UTC 
I experience huge delays every time I boot the kernel. It's been like this for all kernels that's been in Factory.

I'm on an IBM ThinkPad T43P
Kernel: 2.6.24-rc8-git2-3-pae

===================
Boot logging started on /dev/tty1(/dev/console) at Wed Jan 23 22:36:43 2008
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
ACPI: Processor [CPU] (supports 8 throttling states)
ACPI: Thermal Zone [THM0] (73 C)
SCSI subsystem initialized
ahci: probe of 0000:00:1f.2 failed with error -22
ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ]
IBM TrackPoint firmware: 0x0e, buttons: 3/3
input: TPPS/2 IB< TrackPoint as /devices/platform/i8042/serio1/input/input2
===> Sits here for >30 seconds
scsi0 : ata_piix
scsi1 : ata_piix
ata1: SATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0x18c0 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x18c8 irq 15
===> Sits here for >30 seconds
ata1.00: ATA-6: HTS721080G9AT00, MC4IA5
ata1.00: 156301488 sectors, multi 16: LBA
ata1.00: applying bridge limits
ata1.00: configure for UDMA/100
===> Sits here for >30 seconds
Clocksource tsc unstable (delta = -214161090677)
===> Sits here for ~10 seconds, then finally boots normally
Comment 1 Forgotten User qMyteedNxa 2008-01-26 17:30:52 UTC 
this is a known issue related to linux timer.
try booting with clock=pit and you shouldn`t see that behaviour.

*** This bug has been marked as a duplicate of bug 346478 ***