Bug 5757 - BIOS USB emulation causes new Linux SMP init failure - Dell precision workstation 650
Summary: BIOS USB emulation causes new Linux SMP init failure - Dell precision worksta...
Status: REJECTED WILL_NOT_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: USB (show other bugs)
Hardware: i386 Linux
: P2 blocking
Assignee: Greg Kroah-Hartman
URL:
Keywords:
Depends on:
Blocks: USB
  Show dependency tree
 
Reported: 2005-12-17 16:45 UTC by trilight
Modified: 2008-10-08 07:51 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.14.4
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
current kernel config 2.6.14.4 (8.85 KB, application/octet-stream)
2005-12-17 16:47 UTC, trilight
Details
DSDT table straight from the bios (7.08 KB, application/octet-stream)
2005-12-17 16:55 UTC, trilight
Details
kern.log and a very recent dmesg of a successful boot (17.05 KB, application/octet-stream)
2005-12-20 00:53 UTC, trilight
Details
dmidecode information (deleted)
2005-12-22 12:43 UTC, trilight
Details

Description trilight 2005-12-17 16:45:07 UTC
Most recent kernel where this bug did not occur: redhat enterprise / 2.6.9
Distribution: debian sarge / vanilla kernel 2.6.11 to .14.4
Hardware Environment: 

Dell precision workstation 650 
dual xeon w/ HT / 512MB ECC 
Intel 75705 motherboard

Software Environment:

Problem Description:

I noticed that the system after X reboots, this time 4, it boots up
successfuly and i see no errors from ACPI during boot. This is without
any boot parameters. Previously i used acpi=off noapic which increased
the chance of a successful boot (not sure about this, didn't count that)

But during those automatic reboots this is the info i could capture (it
did not get logged btw):

"
<cpu0 is detected and described>
...booting processor 1/2 EIP 2000....
inquiring remote apic #1
apic #1 ID failed
apic #1 VERSION failed
apic # SPIV failed
....not responding cpu #1
cannot use it
then the same happens when it goes to the next cpu, only then it says
apic #6 (sometimes #7)
cannot use it
"

The weird thing is that now for example i booted up perfectly,no errors,
no acpi weirdness...is this a kernel issue ? The previous o.s was linux
Redhat Enterprise which never had these problems. Also it boots up fine with
microsoft 2k/xp.

Steps to reproduce:

I don't know, this is specific to this system.
Comment 1 trilight 2005-12-17 16:47:26 UTC
Created attachment 6853 [details]
current kernel config 2.6.14.4
Comment 2 trilight 2005-12-17 16:53:07 UTC
additional testing information:

I tried countless ways to solve this problem before i filled this bugreport. 

- tried basically all boot parameters for acpi, apic ...
- tried many kernel configurations like enabling/disabling certain functions
- triple checked kernel config and third parties to check for mistakes, none
- captured the DSDT and noticed during recompile several errors but they don't
look as serious to the current problem (no expert so can't be sure)
(DSDT table included)
Comment 3 trilight 2005-12-17 16:55:31 UTC
Created attachment 6854 [details]
DSDT table straight from the bios

The workstation is using the latest bios from dell which is A05.
Comment 4 trilight 2005-12-17 17:09:05 UTC
These are the errors when recompiling the DSDT table:

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20050930 [Dec 15 2005]
Copyright (C) 2000 - 2005 Intel Corporation
Supports ACPI Specification Revision 3.0

dsdt.dsl   338:         Notify (\_SB.PCI0.USB0, 0x02)
Error    1061 -        Object does not exist ^  (\_SB.PCI0.USB0)

dsdt.dsl   351:         Notify (\_SB.PCI0.USB1, 0x02)
Error    1061 -        Object does not exist ^  (\_SB.PCI0.USB1)

dsdt.dsl   364:         Notify (\_SB.PCI0.USB2, 0x02)
Error    1061 -        Object does not exist ^  (\_SB.PCI0.USB2)

dsdt.dsl   377:         Notify (\_SB.PCI0, 0x02)
Error    1061 -   Object does not exist ^  (\_SB.PCI0)

dsdt.dsl   384:         Notify (\_SB.PCI0.PCI4, 0x02)
Error    1061 -        Object does not exist ^  (\_SB.PCI0.PCI4)

dsdt.dsl   400:         Notify (\_SB.PCI0.ISA.KBD, 0x02)
Error    1061 -           Object does not exist ^  (\_SB.PCI0.ISA.KBD)

dsdt.dsl  1784:                 Device (DMA)
Error    1094 -                           ^ syntax error, unexpected
PARSEOP_DMA, expecting PARSEOP_NAMESEG or PARSEOP_NAMESTRING

ASL Input:  dsdt.dsl - 3096 lines, 93624 bytes, 515 keywords
Compilation complete. 7 Errors, 0 Warnings, 0 Remarks, 53 Optimizations

Comment 5 trilight 2005-12-17 23:43:51 UTC
additional information:

it for sure works fine if i do acpi=off noapic on the boot prompt.
Comment 6 trilight 2005-12-18 07:34:51 UTC
additional info, correction:

this is an intel motherboard E7505
Comment 7 Shaohua 2005-12-19 20:46:56 UTC
Can you attach the full dmesg output of working and unworking cases?
Comment 8 trilight 2005-12-20 00:53:22 UTC
Created attachment 6862 [details]
kern.log and a very recent dmesg of a successful boot

I'd greatly appreciate it if this could be solved, been struggling with it for
days and nights.

I'm including a kern-1.log consisting of 2 starts, one with a 2.4.32 kernel and
one with a 2.6.14.4 kernel (i marked the place). In the latter there is an
interesting oops related to smp which might give an expert the right
information.

Also including a dmesg of just a few minutes ago, after like 5 reboots the
system started as it should with 2 physical and 2 logical cpu's.

Please keep in mind that when it goes wrong the errors i mentioned in this bug
can't get logged and the box restarts quickly after it tried booting the second
cpu and inquiring the apics.
Comment 9 Shaohua 2005-12-20 01:05:57 UTC
It appears you disabled ACPI in the failed case. If no ACPI, ht can't be 
enabled. please enable ACPI and try again.
Comment 10 trilight 2005-12-20 01:26:58 UTC
Yes, that's the emergency kernel (2.4.32), with disabling acpi and noapic it
usually boots up so i can at least get to a prompt. 

For the rest when i don't disasble acpi/apic in the emergency kernel behaviour
is the same.

I got with some good help from a friend to smpboot.c , the part which should
boot up the second cpu is where things somehow go wrong.
Comment 11 trilight 2005-12-20 01:35:32 UTC
btw, it's a i7505 not e7505 mobo.
Comment 12 trilight 2005-12-20 01:49:56 UTC
I also have to note that i tried freebsd 6 with a custom kernel to enable smp
and it panics when it gets the apics sending a failure.

(btw, e7505, i guess i7505 might express some other part or so)
Comment 13 trilight 2005-12-20 03:03:57 UTC
Let me know if you need any information i can get for you.
Comment 14 Shaohua 2005-12-20 18:51:34 UTC
For the dmesg from 2.6.14, can you attach a full message (using dmesg -
s40000). You just get the last several lines of info.
>re the oops info
Yes, the oops is quite strange. It appears the CPU 1 executes the code very 
late.
It would be better if you can give us the dmesg from working/unworking kernel 
(2.6, better with boot option apic=debug). Thanks.
Comment 15 trilight 2005-12-21 04:21:03 UTC
Thanks for looking into this btw !

I already attached the dmesg of a working kernel, even 2 working kernels, 2.4.32
without acpi support and noapic, and 2.6.14.4 with acpi + apic support, please
check the previous attachment. (they're in the dmesg file)

So this is what i could note from my monitor just before the reboot occurs:

Booting processor 1/1 eip 2000 
Not responding
Inquiring remote APIC #6
... APIC #1 ID: FAILED
... APIC #1 VERSION: FAILED
... APIC #1 SPIV: FAILED
CPU #1 not responding - cannot use it
Booting processor 1/6 eip 2000
Not responding
... APIC #6 ID: FAILED
... APIC #6 VERSION: FAILED
... APIC #6 SPIV: FAILED
CPU #6 not responding - cannot use it
Booting processor 1/7 eip 2000
NOt responding
... APIC #7 ID: FAILED
... APIC #7 VERSION: FAILED
... APIC #7 SPIV: FAILED
CPU #7 not responding - cannot use it

btw, i noticed when i used acpi=debug the system kept rebooting, even after 17
reboots it did not continue. So i didn't use acpi=debug and now it booted after
3 reboots. So this is also something which we need to look at i guess.

Comment 16 trilight 2005-12-21 04:42:53 UTC
I also tried a few days ago to change a bit of code in smpboot.c according to
the following:

     /*
                 * allow APs to start initializing.
                 */
                Dprintk("Before Callout %d.\n", cpu);
                cpu_set(cpu, cpu_callout_map);
                Dprintk("After Callout %d.\n", cpu);

                /*
                 * Wait 5s total for a response
                 */
                for (timeout = 0; timeout < 50000; timeout++) {
                        if (cpu_isset(cpu, cpu_callin_map))
--------------------------> cpu_online_map
                                break; /* It has booted */
                        udelay(100);
                }

                if (cpu_isset(cpu, cpu_callin_map)) {
--------------------------------> cpu_online_map
                        /* number CPUs logically, starting from 1 (BSP is 0)
*/
                        Dprintk("CPU has booted.\n");
                } else {
                        boot_error = 1;
                        if (*((volatile unsigned char
*)phys_to_virt(SMP_TRAMPOLINE_BASE))
                                        == 0xA5)
                                /* trampoline started but...? */
                                printk("Stuck ??\n");
                        else
                                /* trampoline code not run */
                                printk("Not responding.\n");
#if APIC_DEBUG
                        inquire_remote_apic(apicid);
#endif
                } 



I replaced cpu_callin_map to cpu_online_map, this caused the system not reboot
but show various crashes and continue with the first cpu to boot.


I got it from this link:

http://groups.google.com/group/linux.kernel/browse_frm/thread/ee892bb3680aa46f/58194aedd45afe9b?tvc=1#58194aedd45afe9b


although it was meant for a 64bit system it did at least something.
Comment 17 trilight 2005-12-21 05:02:15 UTC
When it finished booting, i did a cat /proc/cpuinfo and i see only 1 cpu with
the previous change in smpboot.c. When i do cat /proc/interrupts then i see 4
cpu's but only 1 handling interrupts and the rest has 0.
Comment 18 trilight 2005-12-21 05:10:42 UTC
I have to correct myself, it seems after a few reboots that even with the change
in smpboot.c it still reboots sometimes and not finishing boot.

the only way now is with acpi=off noapic to get a normal boot.
Comment 19 Len Brown 2005-12-21 18:28:05 UTC
please attach the output from dmidecode, available in /usr/sbin
or from http://www.nongnu.org/dmidecode/
Comment 20 trilight 2005-12-22 12:43:03 UTC
Created attachment 6880 [details]
dmidecode information

Okay, included the dmidicode information, this is captured while the system
booted normally (well, after 7 reboots this time).

Really appreciate it that you guys are looking into this !

Thanks
Comment 21 trilight 2005-12-22 14:14:40 UTC
Please note also that after a "normal" boot then after a few hours, sometimes
less, applications start to crash randomly. This could be gnome-terminal,
gnome-control-panel, joe (editor), vmware, xawtv, and so on.

Here is a cat of the interrupts after a "normal" boot:

           CPU0       CPU1       CPU2       CPU3
  0:    1962881          0          0          0    IO-APIC-edge  timer
  1:      15252          0          0          0    IO-APIC-edge  i8042
  7:          0          0          0          0    IO-APIC-edge  parport0
  8:   12292269          0          0          0    IO-APIC-edge  rtc
  9:          0          0          0          0   IO-APIC-level  acpi
 14:         21          0          0          0    IO-APIC-edge  ide0
 15:         13          0          0          0    IO-APIC-edge  ide1
169:     149590          0          0          0   IO-APIC-level  bttv0
177:         57          0          0          0   IO-APIC-level  uhci_hcd:usb4
185:      93148          0          0          0   IO-APIC-level  ide2, ide3
193:          5          0          0          0   IO-APIC-level  ehci_hcd:usb1
201:    1358332          0          0          0   IO-APIC-level  uhci_hcd:usb2,
nvidia
209:     891083          0          0          0   IO-APIC-level  uhci_hcd:usb3
217:          0          0          0          0   IO-APIC-level  Intel 82801DB-ICH4
225:      30385          0          0          0   IO-APIC-level  EMU10K1
233:      51353          0          0          0   IO-APIC-level  eth0
NMI:          0          0          0          0
LOC:    1962766    1962511    1962764    1962763
ERR:          0
MIS:          0

Comment 22 Shaohua 2005-12-22 20:43:13 UTC
Please try 'apic=debug' not 'acpi=debug'. Also, please attach a full dmesg 
(using dmesg -s40000). The log you attached just includes the last several 
lines. We need look at the full dmesg (the information about booting a CPU is 
printed very earily). Thanks!
Comment 23 trilight 2005-12-23 00:54:57 UTC
Ok, i'm going to boot with apic=debug. (btw, when i do dmesg -s40000 that's all
i get, there is no more than what you see, this included kern.log, messages too)
Comment 24 trilight 2005-12-23 01:48:41 UTC
additional info:

When i boot with acpi off and noapic i notice sometimes "spurious interrupt"
messages, usually irq 7. Although i'm not unfamiliar with these messages since i
saw them on several occassions in the past.
Comment 25 trilight 2005-12-23 04:36:32 UTC
I tried apic=debug but there is hardly any information shown, not in kern.log, 
not in dmesg, not in messages, not in syslog.

Maybe because some debugging options in the kernel are turned off ? 

Anyway, when i had alot of debug options enabled in the kernel i found these in 
the logs, looks like it has good info:

These are when i used the 2.4.32(+grsec, but grsec has nothing to do with this) 
emergency kernel:

Dec 19 07:26:55 localhost kernel: Inspecting /boot/System.map-2.4.32-grsec
Dec 19 07:26:55 localhost kernel: Loaded 22595 symbols from /boot/System.map-
2.4.32-grsec.
Dec 19 07:26:55 localhost kernel: Symbols match kernel version 2.4.32.
Dec 19 07:26:55 localhost kernel: Loaded 69 symbols from 5 modules.
Dec 19 07:26:55 localhost kernel: Linux version 2.4.32-grsec (root@hypercube) 
(gcc version 3.3.5 (Debian 1:3.3.5-13)) #2 SMP Mon Nov 21 16:50:22 CET 2005
Dec 19 07:26:55 localhost kernel: BIOS-provided physical RAM map:
Dec 19 07:26:55 localhost kernel:  BIOS-e820: 0000000000000000 - 
00000000000a0000 (usable)
Dec 19 07:26:55 localhost kernel:  BIOS-e820: 00000000000f0000 - 
0000000000100000 (reserved)
Dec 19 07:26:55 localhost kernel:  BIOS-e820: 0000000000100000 - 
000000001ff75000 (usable)
Dec 19 07:26:55 localhost kernel:  BIOS-e820: 000000001ff75000 - 
000000001ff77000 (ACPI NVS)
Dec 19 07:26:55 localhost kernel:  BIOS-e820: 000000001ff77000 - 
000000001ff98000 (ACPI data)
Dec 19 07:26:55 localhost kernel:  BIOS-e820: 000000001ff98000 - 
0000000020000000 (reserved)
Dec 19 07:26:55 localhost kernel:  BIOS-e820: 00000000fec00000 - 
00000000fec90000 (reserved)
Dec 19 07:26:55 localhost kernel:  BIOS-e820: 00000000fee00000 - 
00000000fee10000 (reserved)
Dec 19 07:26:55 localhost kernel:  BIOS-e820: 00000000ffb00000 - 
0000000100000000 (reserved)
Dec 19 07:26:55 localhost kernel: 0MB HIGHMEM available.
Dec 19 07:26:55 localhost kernel: 511MB LOWMEM available.
Dec 19 07:26:55 localhost kernel: found SMP MP-table at 000fe710
Dec 19 07:26:55 localhost kernel: hm, page 000fe000 reserved twice.
Dec 19 07:26:55 localhost kernel: hm, page 000ff000 reserved twice.
Dec 19 07:26:55 localhost kernel: hm, page 000f0000 reserved twice.
Dec 19 07:26:55 localhost kernel: On node 0 totalpages: 130933
Dec 19 07:26:55 localhost kernel: zone(0): 4096 pages.
Dec 19 07:26:55 localhost kernel: zone(1): 126837 pages.
Dec 19 07:26:55 localhost kernel: zone(2): 0 pages.
Dec 19 07:26:55 localhost kernel: ACPI: RSDP (v000 
DELL                                      ) @ 0x000febc0
Dec 19 07:26:55 localhost kernel: ACPI: RSDT (v001 DELL    WS 650  0x00000009 
ASL  0x00000061) @ 0x000fd4f1
Dec 19 07:26:55 localhost kernel: ACPI: FADT (v001 DELL    WS 650  0x00000009 
ASL  0x00000061) @ 0x000fd529
Dec 19 07:26:55 localhost kernel: ACPI: SSDT (v001   DELL    st_ex 0x00001000 
MSFT 0x0100000d) @ 0xfffefba1
Dec 19 07:26:55 localhost kernel: ACPI: MADT (v001 DELL    WS 650  0x00000009 
ASL  0x00000061) @ 0x000fd59d
Dec 19 07:26:55 localhost kernel: ACPI: BOOT (v001 DELL    WS 650  0x00000009 
ASL  0x00000061) @ 0x000fd621
Dec 19 07:26:55 localhost kernel: ACPI: ASF! (v016 DELL    WS 650  0x00000009 
ASL  0x00000061) @ 0x000fd649
Dec 19 07:26:55 localhost kernel: ACPI: DSDT (v001   DELL    dt_ex 0x00001000 
MSFT 0x0100000d) @ 0x00000000
Dec 19 07:26:55 localhost kernel: ACPI: Local APIC address 0xfee00000
Dec 19 07:26:55 localhost kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] 
enabled)
Dec 19 07:26:55 localhost kernel: Processor #0 Pentium 4(tm) XEON(tm) APIC 
version 20
Dec 19 07:26:55 localhost kernel: ACPI: LAPIC (acpi_id[0x02] lapic_id[0x06] 
enabled)
Dec 19 07:26:55 localhost kernel: Processor #6 Pentium 4(tm) XEON(tm) APIC 
version 20
Dec 19 07:26:55 localhost kernel: ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] 
enabled)
Dec 19 07:26:55 localhost kernel: Processor #1 Pentium 4(tm) XEON(tm) APIC 
version 20
Dec 19 07:26:55 localhost kernel: WARNING: NR_CPUS limit of 2 reached. 
Processor ignored.
Dec 19 07:26:55 localhost kernel: ACPI: LAPIC (acpi_id[0x04] lapic_id[0x07] 
enabled)
Dec 19 07:26:55 localhost kernel: Processor #7 Pentium 4(tm) XEON(tm) APIC 
version 20
Dec 19 07:26:55 localhost kernel: WARNING: NR_CPUS limit of 2 reached. 
Processor ignored.
Dec 19 07:26:55 localhost kernel: Using ACPI for processor (LAPIC) 
configuration information
Dec 19 07:26:55 localhost kernel: Intel MultiProcessor Specification v1.4
Dec 19 07:26:55 localhost kernel:     Virtual Wire compatibility mode.
Dec 19 07:26:55 localhost kernel: OEM ID: DELL     Product ID: WS 650       
APIC at: 0xFEE00000
Dec 19 07:26:55 localhost kernel: I/O APIC #8 Version 32 at 0xFEC00000.
Dec 19 07:26:55 localhost kernel: I/O APIC #10 Version 32 at 0xFEC80000.
Dec 19 07:26:55 localhost kernel: I/O APIC #9 Version 32 at 0xFEC80800.
Dec 19 07:26:55 localhost kernel: Enabling APIC mode: Flat.^IUsing 3 I/O APICs
Dec 19 07:26:55 localhost kernel: Processors: 2
Dec 19 07:26:55 localhost kernel: Kernel command line: BOOT_IMAGE=Ecore ro 
root=2101 acpi=ht noapic
Dec 19 07:26:55 localhost kernel: Initializing CPU#0
Dec 19 07:26:55 localhost kernel: Detected 2392.332 MHz processor.
Dec 19 07:26:55 localhost kernel: Console: colour VGA+ 80x25
Dec 19 07:26:55 localhost kernel: Calibrating delay loop... 4771.02 BogoMIPS
Dec 19 07:26:55 localhost kernel: Memory: 513436k/523732k available (2306k 
kernel code, 9912k reserved, 386k data, 152k init, 0k highmem)
Dec 19 07:26:55 localhost kernel: Dentry cache hash table entries: 65536 
(order: 7, 524288 bytes)
Dec 19 07:26:55 localhost kernel: Inode cache hash table entries: 32768 (order: 
6, 262144 bytes)
Dec 19 07:26:55 localhost kernel: Mount cache hash table entries: 512 (order: 
0, 4096 bytes)
Dec 19 07:26:55 localhost kernel: Buffer cache hash table entries: 32768 
(order: 5, 131072 bytes)
Dec 19 07:26:55 localhost kernel: Page-cache hash table entries: 131072 (order: 
7, 524288 bytes)
Dec 19 07:26:55 localhost kernel: CPU: Trace cache: 12K uops, L1 D cache: 8K
Dec 19 07:26:55 localhost kernel: CPU: L2 cache: 512K
Dec 19 07:26:55 localhost kernel: CPU: Physical Processor ID: 0
Dec 19 07:26:55 localhost kernel: Intel machine check architecture supported.
Dec 19 07:26:55 localhost kernel: Intel machine check reporting enabled on 
CPU#0.
Dec 19 07:26:55 localhost kernel: CPU:     After generic, caps: bfebfbff 
00000000 00000000 00000000
Dec 19 07:26:55 localhost kernel: CPU:             Common caps: bfebfbff 
00000000 00000000 00000000
Dec 19 07:26:55 localhost kernel: Enabling fast FPU save and restore... done.
Dec 19 07:26:55 localhost kernel: Enabling unmasked SIMD FPU exception 
support... done.
Dec 19 07:26:55 localhost kernel: Checking 'hlt' instruction... OK.
Dec 19 07:26:55 localhost kernel: POSIX conformance testing by UNIFIX
Dec 19 07:26:55 localhost kernel: mtrr: v1.40 (20010327) Richard Gooch 
(rgooch@atnf.csiro.au)
Dec 19 07:26:55 localhost kernel: mtrr: detected mtrr type: Intel
Dec 19 07:26:55 localhost kernel: CPU: Trace cache: 12K uops, L1 D cache: 8K
Dec 19 07:26:55 localhost kernel: CPU: L2 cache: 512K
Dec 19 07:26:55 localhost kernel: CPU: Physical Processor ID: 0
Dec 19 07:26:55 localhost kernel: Intel machine check reporting enabled on 
CPU#0.
Dec 19 07:26:55 localhost kernel: CPU:     After generic, caps: bfebfbff 
00000000 00000000 00000000
Dec 19 07:26:55 localhost kernel: CPU:             Common caps: bfebfbff 
00000000 00000000 00000000
Dec 19 07:26:55 localhost kernel: CPU0: Intel(R) Xeon(TM) CPU 2.40GHz stepping 
09
Dec 19 07:26:55 localhost kernel: per-CPU timeslice cutoff: 1462.89 usecs.
Dec 19 07:26:55 localhost kernel: enabled ExtINT on CPU#0
Dec 19 07:26:55 localhost kernel: ESR value before enabling vector: 00000040
Dec 19 07:26:55 localhost kernel: ESR value after enabling vector: 00000000
Dec 19 07:26:55 localhost kernel: Booting processor 1/6 eip 3000
Dec 19 07:26:55 localhost kernel: Not responding.
Dec 19 07:26:55 localhost kernel: Error: only one processor found.
Dec 19 07:26:55 localhost kernel: WARNING: No sibling found for CPU 0.
Dec 19 07:26:55 localhost kernel: Using local APIC timer interrupts.
Dec 19 07:26:55 localhost kernel: calibrating APIC timer ...
Dec 19 07:26:55 localhost kernel: ..... CPU clock speed is 2392.3125 MHz.
Dec 19 07:26:55 localhost kernel: ..... host bus clock speed is 132.9060 MHz.
Dec 19 07:26:55 localhost kernel: cpu: 0, clocks: 1329060, slice: 664530
Dec 19 07:26:55 localhost kernel: 
CPU0<T0:1329056,T1:664512,D:14,S:664530,C:1329060>
Dec 19 07:26:55 localhost kernel: Waiting on wait_init_idle (map = 0x0)
Dec 19 07:26:55 localhost kernel: All processors have done init_idle
Dec 19 07:26:55 localhost kernel: ACPI: Subsystem revision 20040326
Dec 19 07:26:55 localhost kernel: ACPI: Interpreter disabled.
Dec 19 07:26:55 localhost kernel: PCI: PCI BIOS revision 2.10 entry at 0xfbdf2, 
last bus=5
Dec 19 07:26:55 localhost kernel: PCI: Using configuration type 1
Dec 19 07:26:55 localhost kernel: PCI: Probing PCI hardware
Dec 19 07:26:55 localhost kernel: PCI: Probing PCI hardware (bus 00)
Dec 19 07:26:55 localhost kernel: PCI: Ignoring BAR0-3 of IDE controller 00:1f.1

CUT - anything after this is just the usual noise.

This i found in /var/log/debug, it contains some interesting info when i had 
debugging options on:
Dec 19 02:07:29 localhost kernel: CPU:     After generic, caps: bfebfbff 
00000000 00000000 00000000
Dec 19 02:07:29 localhost kernel: CPU:             Common caps: bfebfbff 
00000000 00000000 00000000
Dec 19 02:07:29 localhost kernel: CPU:     After generic, caps: bfebfbff 
00000000 00000000 00000000
Dec 19 02:07:29 localhost kernel: CPU:             Common caps: bfebfbff 
00000000 00000000 00000000
Dec 19 02:07:29 localhost kernel: CPU:     After generic, caps: bfebfbff 
00000000 00000000 00000000
Dec 19 02:07:29 localhost kernel: CPU:             Common caps: bfebfbff 
00000000 00000000 00000000
Dec 19 02:07:29 localhost kernel: init IO_APIC IRQs
Dec 19 02:07:29 localhost kernel:  IO-APIC (apicid-pin) 8-0, 8-16, 8-17, 8-18, 
8-19, 8-20, 8-21, 8-22, 8-23, 9-0, 9-1, 9-2, 9-3, 9-4, 9-5, 9-6, 9-7, 9-8,
Dec 19 02:07:29 localhost kernel: ACPI: PCI Interrupt Routing Table 
[\_SB_.PCI0._PRT]
Dec 19 02:07:29 localhost kernel: ACPI: PCI Interrupt Routing Table 
[\_SB_.PCI0.PCI1._PRT]
Dec 19 02:07:29 localhost kernel: ACPI: PCI Interrupt Routing Table 
[\_SB_.PCI0.PCI1.PCI2._PRT]
Dec 19 02:07:29 localhost kernel: ACPI: PCI Interrupt Routing Table 
[\_SB_.PCI0.PCI1.PCI3._PRT]
Dec 19 02:07:29 localhost kernel: ACPI: PCI Interrupt Routing Table 
[\_SB_.PCI0.PCI4._PRT]
Dec 19 02:07:29 localhost kernel: 00:00:01[A] -> 8-16 -> IRQ 16 level low
Dec 19 02:07:29 localhost kernel: 00:00:01[B] -> 8-17 -> IRQ 17 level low
Dec 19 02:07:29 localhost kernel: 00:00:1f[A] -> 8-18 -> IRQ 18 level low
Dec 19 02:07:29 localhost kernel: 00:00:1e[D] -> 8-19 -> IRQ 19 level low
Dec 19 02:07:29 localhost kernel: 00:00:1d[D] -> 8-23 -> IRQ 23 level low
Dec 19 02:07:29 localhost kernel: 00:02:1d[A] -> 9-0 -> IRQ 24 level low
Dec 19 02:07:29 localhost kernel: 00:02:1d[B] -> 9-1 -> IRQ 25 level low
Dec 19 02:07:29 localhost kernel: 00:02:1d[C] -> 9-2 -> IRQ 26 level low
Dec 19 02:07:29 localhost kernel: 00:02:1d[D] -> 9-3 -> IRQ 27 level low
Dec 19 02:07:29 localhost kernel: 00:02:1f[A] -> 10-0 -> IRQ 48 level low
Dec 19 02:07:29 localhost kernel: 00:02:1f[B] -> 10-1 -> IRQ 49 level low
Dec 19 02:07:29 localhost kernel: 00:02:1f[C] -> 10-2 -> IRQ 50 level low
Dec 19 02:07:29 localhost kernel: 00:02:1f[D] -> 10-3 -> IRQ 51 level low
Dec 19 02:07:29 localhost kernel: 00:03:0c[D] -> 9-4 -> IRQ 28 level low
Dec 19 02:07:29 localhost kernel: 00:03:0d[A] -> 9-5 -> IRQ 29 level low
Dec 19 02:07:29 localhost kernel: 00:03:0d[B] -> 9-6 -> IRQ 30 level low
Dec 19 02:07:29 localhost kernel: 00:03:0d[C] -> 9-7 -> IRQ 31 level low
Dec 19 02:07:29 localhost kernel: 00:03:0d[D] -> 9-8 -> IRQ 32 level low
Dec 19 02:07:29 localhost kernel: 00:05:0c[A] -> 8-20 -> IRQ 20 level low
Dec 19 02:07:29 localhost kernel: 00:05:0d[A] -> 8-21 -> IRQ 21 level low
Dec 19 02:07:29 localhost kernel: 00:05:0d[B] -> 8-22 -> IRQ 22 level low
Dec 19 02:07:29 localhost kernel: number of MP IRQ sources: 15.
Dec 19 02:07:29 localhost kernel: number of IO-APIC #8 registers: 24.
Dec 19 02:07:29 localhost kernel: number of IO-APIC #9 registers: 24.
Dec 19 02:07:29 localhost kernel: number of IO-APIC #10 registers: 24.
Dec 19 02:07:29 localhost kernel: IO APIC #8......
Dec 19 02:07:29 localhost kernel: .... register #00: 08000000
Dec 19 02:07:29 localhost kernel: .......    : physical APIC id: 08
Dec 19 02:07:29 localhost kernel: .......    : Delivery Type: 0
Dec 19 02:07:29 localhost kernel: .......    : LTS          : 0
Dec 19 02:07:29 localhost kernel: .... register #01: 00178020
Dec 19 02:07:29 localhost kernel: .......     : max redirection entries: 0017
Dec 19 02:07:29 localhost kernel: .......     : PRQ implemented: 1
Dec 19 02:07:29 localhost kernel: .......     : IO APIC version: 0020
Dec 19 02:07:29 localhost kernel: .... register #02: 00000000
Dec 19 02:07:29 localhost kernel: .......     : arbitration: 00
Dec 19 02:07:29 localhost kernel: .... register #03: 00000001
Dec 19 02:07:29 localhost kernel: .......     : Boot DT    : 1
Dec 19 02:07:29 localhost kernel: .... IRQ redirection table:
Dec 19 02:07:29 localhost kernel:  NR Log Phy Mask Trig IRR Pol Stat Dest Deli 
Vect:
Dec 19 02:07:29 localhost kernel:  NR Log Phy Mask Trig IRR Pol Stat Dest Deli 
Vect:
Dec 19 02:07:29 localhost kernel:  00 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  01 003 03  0    0    0   0   0    1    1    
39
Dec 19 02:07:29 localhost kernel:  02 003 03  0    0    0   0   0    1    1    
31
Dec 19 02:07:29 localhost kernel:  03 003 03  0    0    0   0   0    1    1    
41
Dec 19 02:07:29 localhost kernel:  04 003 03  0    0    0   0   0    1    1    
49
Dec 19 02:07:29 localhost kernel:  05 003 03  0    0    0   0   0    1    1    
51
Dec 19 02:07:29 localhost kernel:  06 003 03  0    0    0   0   0    1    1    
59
Dec 19 02:07:29 localhost kernel:  07 003 03  0    0    0   0   0    1    1    
61
Dec 19 02:07:29 localhost kernel:  08 003 03  0    0    0   0   0    1    1    
69
Dec 19 02:07:29 localhost kernel:  09 003 03  0    1    0   0   0    1    1    
71
Dec 19 02:07:29 localhost kernel:  0a 003 03  0    0    0   0   0    1    1    
79
Dec 19 02:07:29 localhost kernel:  0b 003 03  0    0    0   0   0    1    1    
81
Dec 19 02:07:29 localhost kernel:  0c 003 03  0    0    0   0   0    1    1    
89
Dec 19 02:07:29 localhost kernel:  0d 003 03  0    0    0   0   0    1    1    
91
Dec 19 02:07:29 localhost kernel:  0e 003 03  0    0    0   0   0    1    1    
99
Dec 19 02:07:29 localhost kernel:  0f 003 03  0    0    0   0   0    1    1    
A1
Dec 19 02:07:29 localhost kernel:  10 003 03  1    1    0   1   0    1    1    
A9
Dec 19 02:07:29 localhost kernel:  11 003 03  1    1    0   1   0    1    1    
B1
Dec 19 02:07:29 localhost kernel:  12 003 03  1    1    0   1   0    1    1    
B9
Dec 19 02:07:29 localhost kernel:  13 003 03  1    1    0   1   0    1    1    
C1
Dec 19 02:07:29 localhost kernel:  14 003 03  1    1    0   1   0    1    1    
7A
Dec 19 02:07:29 localhost kernel:  15 003 03  1    1    0   1   0    1    1    
82
Dec 19 02:07:29 localhost kernel:  16 003 03  1    1    0   1   0    1    1    
8A
Dec 19 02:07:29 localhost kernel:  17 003 03  1    1    0   1   0    1    1    
C9
Dec 19 02:07:29 localhost kernel: IO APIC #9......
Dec 19 02:07:29 localhost kernel: .... register #00: 09000000
Dec 19 02:07:29 localhost kernel: .......    : physical APIC id: 09
Dec 19 02:07:29 localhost kernel: .......    : Delivery Type: 0
Dec 19 02:07:29 localhost kernel: .......    : LTS          : 0
Dec 19 02:07:29 localhost kernel: .... register #01: 00178020
Dec 19 02:07:29 localhost kernel: .......     : max redirection entries: 0017
Dec 19 02:07:29 localhost kernel: .......     : PRQ implemented: 1
Dec 19 02:07:29 localhost kernel: .......     : IO APIC version: 0020
Dec 19 02:07:29 localhost kernel: .... register #02: 09000000
Dec 19 02:07:29 localhost kernel: .......     : arbitration: 09
Dec 19 02:07:29 localhost kernel: .... register #03: 00000001
Dec 19 02:07:29 localhost kernel: .......     : Boot DT    : 1
Dec 19 02:07:29 localhost kernel: .... IRQ redirection table:
Dec 19 02:07:29 localhost kernel:  NR Log Phy Mask Trig IRR Pol Stat Dest Deli 
Vect:
Dec 19 02:07:29 localhost kernel:  00 003 03  1    1    0   1   0    1    1    
D1
Dec 19 02:07:29 localhost kernel:  01 003 03  1    1    0   1   0    1    1    
D9
Dec 19 02:07:29 localhost kernel:  02 003 03  1    1    0   1   0    1    1    
E1
Dec 19 02:07:29 localhost kernel:  03 003 03  1    1    0   1   0    1    1    
E9
Dec 19 02:07:29 localhost kernel:  04 003 03  1    1    0   1   0    1    1    
52
Dec 19 02:07:29 localhost kernel:  05 003 03  1    1    0   1   0    1    1    
5A
Dec 19 02:07:29 localhost kernel:  06 003 03  1    1    0   1   0    1    1    
62
Dec 19 02:07:29 localhost kernel:  07 003 03  1    1    0   1   0    1    1    
6A
Dec 19 02:07:29 localhost kernel:  08 003 03  1    1    0   1   0    1    1    
72
Dec 19 02:07:29 localhost kernel:  09 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  0a 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  0b 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  0c 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  0d 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  0e 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  0f 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  10 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  11 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  12 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  13 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  14 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  15 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  16 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  17 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel: IO APIC #10......
Dec 19 02:07:29 localhost kernel: .... register #00: 0A000000
Dec 19 02:07:29 localhost kernel: .......    : physical APIC id: 0A
Dec 19 02:07:29 localhost kernel: .......    : Delivery Type: 0
Dec 19 02:07:29 localhost kernel: .......    : LTS          : 0
Dec 19 02:07:29 localhost kernel: .... register #01: 00178020
Dec 19 02:07:29 localhost kernel: .......     : max redirection entries: 0017
Dec 19 02:07:29 localhost kernel: .......     : PRQ implemented: 1
Dec 19 02:07:29 localhost kernel: .......     : IO APIC version: 0020
Dec 19 02:07:29 localhost kernel: .... register #02: 0A000000
Dec 19 02:07:29 localhost kernel: .......     : arbitration: 0A
Dec 19 02:07:29 localhost kernel: .... register #03: 00000001
Dec 19 02:07:29 localhost kernel: .......     : Boot DT    : 1
Dec 19 02:07:29 localhost kernel: .... IRQ redirection table:
Dec 19 02:07:29 localhost kernel:  NR Log Phy Mask Trig IRR Pol Stat Dest Deli 
Vect:
Dec 19 02:07:29 localhost kernel:  00 003 03  1    1    0   1   0    1    1    
32
Dec 19 02:07:29 localhost kernel:  01 003 03  1    1    0   1   0    1    1    
3A
Dec 19 02:07:29 localhost kernel:  02 003 03  1    1    0   1   0    1    1    
42
Dec 19 02:07:29 localhost kernel:  03 003 03  1    1    0   1   0    1    1    
4A
Dec 19 02:07:29 localhost kernel:  04 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  05 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  06 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  07 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  08 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  09 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  0a 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  0b 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  0c 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  0d 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  0e 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  0f 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  10 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  11 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  12 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  13 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  14 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  15 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  16 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel:  17 000 00  1    0    0   0   0    0    0    
00
Dec 19 02:07:29 localhost kernel: IRQ to pin mappings:
Dec 19 02:07:29 localhost kernel: IRQ0 -> 0:2
Dec 19 02:07:29 localhost kernel: IRQ1 -> 0:1
Dec 19 02:07:29 localhost kernel: IRQ3 -> 0:3
Dec 19 02:07:29 localhost kernel: IRQ4 -> 0:4
Dec 19 02:07:29 localhost kernel: IRQ5 -> 0:5
Dec 19 02:07:29 localhost kernel: IRQ6 -> 0:6
Dec 19 02:07:29 localhost kernel: IRQ7 -> 0:7
Dec 19 02:07:29 localhost kernel: IRQ8 -> 0:8
Dec 19 02:07:29 localhost kernel: IRQ9 -> 0:9
Dec 19 02:07:29 localhost kernel: IRQ10 -> 0:10
Dec 19 02:07:29 localhost kernel: IRQ11 -> 0:11
Dec 19 02:07:29 localhost kernel: IRQ12 -> 0:12
Dec 19 02:07:29 localhost kernel: IRQ13 -> 0:13
Dec 19 02:07:29 localhost kernel: IRQ14 -> 0:14
Dec 19 02:07:29 localhost kernel: IRQ15 -> 0:15
Dec 19 02:07:29 localhost kernel: IRQ16 -> 0:16
Dec 19 02:07:29 localhost kernel: IRQ17 -> 0:17
Dec 19 02:07:29 localhost kernel: IRQ18 -> 0:18
Dec 19 02:07:29 localhost kernel: IRQ19 -> 0:19
Dec 19 02:07:29 localhost kernel: IRQ20 -> 0:20
Dec 19 02:07:29 localhost kernel: IRQ21 -> 0:21
Dec 19 02:07:29 localhost kernel: IRQ22 -> 0:22
Dec 19 02:07:29 localhost kernel: IRQ23 -> 0:23
Dec 19 02:07:29 localhost kernel: IRQ24 -> 1:0
Dec 19 02:07:29 localhost kernel: IRQ25 -> 1:1
Dec 19 02:07:29 localhost kernel: IRQ26 -> 1:2
Dec 19 02:07:29 localhost kernel: IRQ27 -> 1:3
Dec 19 02:07:29 localhost kernel: IRQ28 -> 1:4
Dec 19 02:07:29 localhost kernel: IRQ29 -> 1:5
Dec 19 02:07:29 localhost kernel: IRQ30 -> 1:6
Dec 19 02:07:29 localhost kernel: IRQ31 -> 1:7
Dec 19 02:07:29 localhost kernel: IRQ32 -> 1:8
Dec 19 02:07:29 localhost kernel: IRQ48 -> 2:0
Dec 19 02:07:29 localhost kernel: IRQ49 -> 2:1
Dec 19 02:07:29 localhost kernel: IRQ50 -> 2:2
Dec 19 02:07:29 localhost kernel: IRQ51 -> 2:3
Dec 19 02:07:29 localhost kernel: PCI: Setting latency timer of device 00:1d.7 
to 64
Dec 19 02:07:29 localhost kernel: PCI: cache line size of 128 is not supported 
by device 00:1d.7
Dec 19 02:07:29 localhost kernel: PCI: Setting latency timer of device 00:1d.0 
to 64
Dec 19 02:07:29 localhost kernel: PCI: Setting latency timer of device 00:1d.1 
to 64
Dec 19 02:07:29 localhost kernel: PCI: Setting latency timer of device 00:1d.2 
to 64
Dec 19 02:07:29 localhost kernel: i2c-core.o: adapter bt848 #0 registered as 
adapter 0.
Dec 19 02:07:29 localhost kernel: i2c-core.o: driver generic i2c audio driver 
registered.
Dec 19 02:07:29 localhost kernel: i2c-core.o: driver i2c TV tuner driver 
registered.
Dec 19 02:07:29 localhost kernel: i2c-core.o: client [Philips PAL_BG (FI1216 
and comp] registered to adapter [bt848 #0](pos. 0).
Dec 19 02:07:29 localhost kernel: usbaudio: constructing mixer for Terminal 3 
type 0x0301
Dec 19 02:07:29 localhost kernel: usb_audio_parsecontrol: usb_audio_state at 
df631d40
Dec 19 02:20:20 localhost kernel: CPU:     After generic, caps: bfebfbff 
00000000 00000000 00000000
Dec 19 02:20:20 localhost kernel: CPU:             Common caps: bfebfbff 
00000000 00000000 00000000
Dec 19 02:20:20 localhost kernel: CPU:     After generic, caps: bfebfbff 
00000000 00000000 00000000
Dec 19 02:20:20 localhost kernel: CPU:             Common caps: bfebfbff 
00000000 00000000 00000000
Dec 19 02:20:20 localhost kernel: CPU:     After generic, caps: bfebfbff 
00000000 00000000 00000000
Dec 19 02:20:20 localhost kernel: CPU:             Common caps: bfebfbff 
00000000 00000000 00000000
Dec 19 02:20:20 localhost kernel: init IO_APIC IRQs
Dec 19 02:20:20 localhost kernel:  IO-APIC (apicid-pin) 8-0, 8-16, 8-17, 8-18, 
8-19, 8-20, 8-21, 8-22, 8-23, 9-0, 9-1, 9-2, 9-3, 9-4, 9-5, 9-6, 9-7, 9-8,
Dec 19 02:20:20 localhost kernel: ACPI: PCI Interrupt Routing Table 
[\_SB_.PCI0._PRT]
Dec 19 02:20:20 localhost kernel: ACPI: PCI Interrupt Routing Table 
[\_SB_.PCI0.PCI1._PRT]
Dec 19 02:20:20 localhost kernel: ACPI: PCI Interrupt Routing Table 
[\_SB_.PCI0.PCI1.PCI2._PRT]
Dec 19 02:20:20 localhost kernel: ACPI: PCI Interrupt Routing Table 
[\_SB_.PCI0.PCI1.PCI3._PRT]
Dec 19 02:20:20 localhost kernel: ACPI: PCI Interrupt Routing Table 
[\_SB_.PCI0.PCI4._PRT]
Dec 19 02:20:20 localhost kernel: 00:00:01[A] -> 8-16 -> IRQ 16 level low
Dec 19 02:20:20 localhost kernel: 00:00:01[B] -> 8-17 -> IRQ 17 level low
Dec 19 02:20:20 localhost kernel: 00:00:1f[A] -> 8-18 -> IRQ 18 level low
Dec 19 02:20:20 localhost kernel: 00:00:1e[D] -> 8-19 -> IRQ 19 level low
Dec 19 02:20:20 localhost kernel: 00:00:1d[D] -> 8-23 -> IRQ 23 level low
Dec 19 02:20:20 localhost kernel: 00:02:1d[A] -> 9-0 -> IRQ 24 level low
Dec 19 02:20:20 localhost kernel: 00:02:1d[B] -> 9-1 -> IRQ 25 level low
Dec 19 02:20:20 localhost kernel: 00:02:1d[C] -> 9-2 -> IRQ 26 level low
Dec 19 02:20:20 localhost kernel: 00:02:1d[D] -> 9-3 -> IRQ 27 level low
Dec 19 02:20:20 localhost kernel: 00:02:1f[A] -> 10-0 -> IRQ 48 level low
Dec 19 02:20:20 localhost kernel: 00:02:1f[B] -> 10-1 -> IRQ 49 level low
Dec 19 02:20:20 localhost kernel: 00:02:1f[C] -> 10-2 -> IRQ 50 level low

Dec 19 02:20:20 localhost kernel: 00:02:1f[D] -> 10-3 -> IRQ 51 level low
Dec 19 02:20:20 localhost kernel: 00:03:0c[D] -> 9-4 -> IRQ 28 level low
Dec 19 02:20:20 localhost kernel: 00:03:0d[A] -> 9-5 -> IRQ 29 level low
Dec 19 02:20:20 localhost kernel: 00:03:0d[B] -> 9-6 -> IRQ 30 level low
Dec 19 02:20:20 localhost kernel: 00:03:0d[C] -> 9-7 -> IRQ 31 level low
Dec 19 02:20:20 localhost kernel: 00:03:0d[D] -> 9-8 -> IRQ 32 level low
Dec 19 02:20:20 localhost kernel: 00:05:0c[A] -> 8-20 -> IRQ 20 level low
Dec 19 02:20:20 localhost kernel: 00:05:0d[A] -> 8-21 -> IRQ 21 level low
Dec 19 02:20:20 localhost kernel: 00:05:0d[B] -> 8-22 -> IRQ 22 level low
Dec 19 02:20:20 localhost kernel: number of MP IRQ sources: 15.
Dec 19 02:20:20 localhost kernel: number of IO-APIC #8 registers: 24.
Dec 19 02:20:20 localhost kernel: number of IO-APIC #9 registers: 24.
Dec 19 02:20:20 localhost kernel: number of IO-APIC #10 registers: 24.
Dec 19 02:20:20 localhost kernel: IO APIC #8......
Dec 19 02:20:20 localhost kernel: .... register #00: 08000000
Dec 19 02:20:20 localhost kernel: .......    : physical APIC id: 08
Dec 19 02:20:20 localhost kernel: .......    : Delivery Type: 0
Dec 19 02:20:20 localhost kernel: .......    : LTS          : 0
Dec 19 02:20:20 localhost kernel: .... register #01: 00178020
Dec 19 02:20:20 localhost kernel: .......     : max redirection entries: 0017
Dec 19 02:20:20 localhost kernel: .......     : PRQ implemented: 1
Dec 19 02:20:20 localhost kernel: .......     : IO APIC version: 0020
Dec 19 02:20:20 localhost kernel: .... register #02: 00000000
Dec 19 02:20:20 localhost kernel: .......     : arbitration: 00
Dec 19 02:20:20 localhost kernel: .... register #03: 00000001
Dec 19 02:20:20 localhost kernel: .......     : Boot DT    : 1
Dec 19 02:20:20 localhost kernel: .... IRQ redirection table:

and so on..




Comment 26 trilight 2005-12-23 04:38:16 UTC
(also i had a limit of 2 cpu's in the 2.4.32 emergency kernel, not that it 
mattered for the behaviour i got with 2.6.x)
Comment 27 trilight 2005-12-26 00:40:10 UTC
OMG ! I found what was causing this whole issue ! Well, at least with the help
of google i found in the redhat bugzilla exactly what was causing this and also
how to produce this problem ! UNBELIEVABLE ! 

It looks like if i disable usb emulation and usb controller in the bios then
everything goes PERFECT ! I mean, i booted to be sure like 16 times in a row and
not one failed, all cpu's responded and came up superfast.

Here is the link: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138892


and here is the initial link i found with some code to fix it i believe:

http://www.ussg.iu.edu/hypermail/linux/kernel/0502.0/0148.html
next reply:
http://www.ussg.iu.edu/hypermail/linux/kernel/0502.0/0316.html

I hope this is enough for you guys to be able to fix it or at least have a
workaround for this. 

Thanks !


Comment 28 trilight 2005-12-26 00:47:05 UTC
PS:

could this whole issue exist because of those errors i posted from the DSDT
table which somehow also have to do with USB ? 
Comment 29 trilight 2005-12-26 01:00:34 UTC
PS:

It looks like there were patches sent from a guy from suse but not implemented yet 

http://lwn.net/Articles/157675/
Comment 30 trilight 2005-12-26 01:21:47 UTC
I tried usb-handoff=1 at the boot prompt but it didn't help.
So i went to the bios, enabled the usb controller but disabled usb emulation,
this worked ! I can now use all my usb devices and also boot goes fine.

So it looks like the usb emulation of the bios is causing all this.

I assume it has no use to adjust the kernel for usb emulation since the usb
emulation allows to boot from usb devices ? Correct me if i'm wrong, but this
should be solved by Dell (the usb emulation part) ?

Thanks !
Comment 31 trilight 2005-12-26 01:24:31 UTC
But then i wonder, usb_emulation somehow DOES make the kernel go crazy ...
Comment 32 trilight 2005-12-26 01:44:33 UTC
Sorry for the flood of messages;

The following works perfect:

Leaving the usb controller ON in the bios
Disabling usb emulation in the bios

From the bios description dell added it says that if usb emulation is off in the
bios then usb emultion will stop when the operating system is loaded. IF it's on
then it'll continue even if the o.s is loaded.

But eitherway, it looks like the kernel has a problem if usb emulation is on in
the bios and fails to work. Windows 2k server+ and XP pro+ and latest redhat
workstation do not have a problem with this if usb emulation is on. So i think
it would be really great if this can be somehow fixed/workound for the community
not using the above.

Currently the workaround is to leave usb emulation off and the system will boot
perfectly every time.
Comment 33 trilight 2005-12-31 09:05:54 UTC
Sometimes i notice this in the logs:

bttv0: OCERR @ 1fde001c,bits: VSYNC HSYNC OFLOW RISCI* OCERR*
Comment 34 trilight 2005-12-31 09:06:25 UTC
Forget about the above msg, it was meant for a different bug report.
Comment 35 Per 2006-01-07 04:55:31 UTC
Hi,  
  
I have the exact same problem on my hyperthreading computer.  
Kernel 2.6.15 (also ocurred on 2.6.14).  
  
When booting up it stops for a few seconds on "Booting processor 1/1" and then  
complains that it doesn't respond "CPU #1 not responding - cannot use it.".  
  
Previously my workaround was that if I touch the USB keyboard in grub (dual  
booting with on other OS), everything will start as normal and CPU#1 is  
responding.  
  
I just tried your fix, disabling the BIOS emulation for usb keyboard and it  
works perfectly.  
However, now I can neither get into the BIOS (without resetting it with some  
jumper) nor can I boot my  other OS.  
 
My motherboard is an ABIT VT7 
(http://www.abit.com.tw/page/en/motherboard/motherboard_detail.php?pMODEL_NAME=VT7&fMTYPE=Socket+478) 
with the latest bios version (v1.4). 
 
Comment 36 trilight 2006-01-07 05:44:27 UTC
Hi !

It somehow seems to do with usb_handoff by the bios to the o.s, somehow when the
bios stays active with usb emulation the kernel goes insane. 

I guess you can simply use a ps/2 keyboard for now to get into the bios and such.

But it's weird, i mean, i disabled it in my bios but when the linux takes over
control then all usb devices like the mouse work.

You shouldn't disable usb controller, only usb emulation.

Let me know how it goes mate !

Thanks

PS: i didn't hear anything from the acpi experts, i hope some one can
investigate this since other o.s' work just fine with usb emulation.
Comment 37 Len Brown 2007-03-09 01:37:29 UTC
Glad that you found the root cause.
I don't see how the failure might be related to ACPI.

Not immediately clear why different versions of Linux behave differently
in the face of USB emulation.

Bumping this over to USB.
Comment 38 Natalie Protasevich 2008-03-11 00:06:01 UTC
Maybe Alan can take a look into this problem.
Comment 39 Alan Stern 2008-03-11 09:56:25 UTC
Early USB handoff has been in the kernel for a long time now.  What happens with a recent kernel, like 2.6.24?
Comment 40 Adam Pribyl 2008-09-11 08:29:04 UTC
This problem still exhibits for me on latest kernel release. Fix is easy, but you have to find what's going on...
Comment 41 Alan Stern 2008-09-11 08:57:54 UTC
It's possible that other operating systems do their USB handoff before initializing the second CPU, whereas Linux does the USB handoff afterward.  If that's what triggers the BIOS bug, I don't know whether we can fix it.  The order of events during system startup is rather delicate; if it were changed then probably a bunch of other computers would stop working.
Comment 42 Adam Pribyl 2008-09-14 11:23:43 UTC
This is not specific to Dell precision workstation 650. With kernel 2.6.26.3-29.fc9.i686 (Fedora) it seems that it exhibits on even more machines than before - according to user reports on mailing list.
Comment 43 Alan Stern 2008-09-18 07:51:54 UTC
I don't know what user reports or what mailing list you're talking about.

And of course the problem isn't specific to a particular workstation.  It's caused by a bug in the BIOS, so it will show up on any machine using the same BIOS.

Can you attach a dmesg log from your boot-up?
Comment 44 Adam Pribyl 2008-09-19 04:58:51 UTC
https://www.redhat.com/archives/fedora-test-list/2008-September/msg00208.html

at the moment I do not have access to this machine, however this is HP Pavilion s3240. I am not sure the HP and Dell uses same bios... but yes this is most probably problem with bios.
Comment 45 Alan 2008-09-22 16:06:04 UTC
At least for the 650 you need a firmware update
Comment 46 Alan 2008-10-08 07:51:23 UTC
From the rumour and off the record vendor comment department I gather that
- The bug came from the reference BIOS code
- It's fixed in various vendor BIOS updates
- The probable effect is that USB keyboard emulation only works on the boot processor

And its documented.

So closing this as a WONTFIX - not our bug and vendor firmware fixes exist. If you can't get new firmware pop into the BIOS and turn off USB keyboard emulation.

Note You need to log in before you can comment on or make changes to this bug.