2009-04-17 15:16:08

by Jeff Mahoney

Subject: [BUG] IO-APIC + timer doesn't work!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all -

I saw this while booting 2.6.30-rc1, -rc2, and today's git, on one of
my development nodes. This output is with apic=debug. With noapic,
it still hung. Both outputs follow.

git bisect leads to commit 8d6f0c8214928f7c5083dd54ecb69c5d615b516e,
but I'm not seeing anything obvious there. Backing just that change
out doesn't fix it.

- -Jeff

apic=debug:

[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 2.6.30-rc2-vanilla (jeffm@sled2) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #22 SMP Thu Apr 16 17:25:38 EDT 2009
[ 0.000000] Command line: root=/dev/disk/by-id/ata-ST3120813AS_3LS0FAGL-part10 eth0=dhcp console=tty0 console=ttyS0,115200 resume=/dev/disk/by-id/ata-ST3120813AS_3LS0FAGL-part6 splash=silent showopts vga=0x314 apic=debug
[ 0.000000] KERNEL supported cpus:
[ 0.000000] Intel GenuineIntel
[ 0.000000] AMD AuthenticAMD
[ 0.000000] Centaur CentaurHauls
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000f7ff0000 (usable)
[ 0.000000] BIOS-e820: 00000000f7ff0000 - 00000000f7fff000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000f7fff000 - 00000000f8000000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved)
[ 0.000000] BIOS-e820: 0000000100000000 - 0000000200000000 (usable)
[ 0.000000] DMI 2.3 present.
[ 0.000000] AMI BIOS detected: BIOS may corrupt low RAM, working around it.
[ 0.000000] last_pfn = 0x200000 max_arch_pfn = 0x100000000
[ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[ 0.000000] last_pfn = 0xf7ff0 max_arch_pfn = 0x100000000
[ 0.000000] Scanning 0 areas for low memory corruption
[ 0.000000] modified physical RAM map:
[ 0.000000] modified: 0000000000000000 - 0000000000010000 (reserved)
[ 0.000000] modified: 0000000000010000 - 000000000009fc00 (usable)
[ 0.000000] modified: 000000000009fc00 - 00000000000a0000 (reserved)
[ 0.000000] modified: 00000000000e0000 - 0000000000100000 (reserved)
[ 0.000000] modified: 0000000000100000 - 00000000f7ff0000 (usable)
[ 0.000000] modified: 00000000f7ff0000 - 00000000f7fff000 (ACPI data)
[ 0.000000] modified: 00000000f7fff000 - 00000000f8000000 (ACPI NVS)
[ 0.000000] modified: 00000000ff780000 - 0000000100000000 (reserved)
[ 0.000000] modified: 0000000100000000 - 0000000200000000 (usable)
[ 0.000000] init_memory_mapping: 0000000000000000-00000000f7ff0000
[ 0.000000] init_memory_mapping: 0000000100000000-0000000200000000
[ 0.000000] RAMDISK: 37a0b000 - 37fefed3
[ 0.000000] ACPI: RSDP 00000000000f6d40 00024 (v02 ACPIAM)
[ 0.000000] ACPI: XSDT 00000000f7ff0100 00054 (v01 A M I OEMXSDT 06000514 MSFT 00000097)
[ 0.000000] ACPI: FACP 00000000f7ff0281 000F4 (v01 A M I OEMFACP 06000514 MSFT 00000097)
[ 0.000000] ACPI: DSDT 00000000f7ff0410 03591 (v01 0AAAA 0AAAA001 00000001 INTL 02002026)
[ 0.000000] ACPI: FACS 00000000f7fff000 00040
[ 0.000000] ACPI: APIC 00000000f7ff0380 00084 (v01 A M I OEMAPIC 06000514 MSFT 00000097)
[ 0.000000] ACPI: OEMB 00000000f7fff040 00041 (v01 A M I OEMBIOS 06000514 MSFT 00000097)
[ 0.000000] ACPI: SRAT 00000000f7ff39b0 00110 (v01 A M I OEMSRAT 06000514 MSFT 00000097)
[ 0.000000] ACPI: HPET 00000000f7ff3ac0 00038 (v01 A M I OEMHPET 06000514 MSFT 00000097)
[ 0.000000] ACPI: ASF! 00000000f7ff3b00 00086 (v01 AMIASF AMDSTRET 00000001 INTL 02002026)
[ 0.000000] SRAT: PXM 0 -> APIC 0 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 1 -> Node 0
[ 0.000000] SRAT: PXM 1 -> APIC 2 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 3 -> Node 1
[ 0.000000] SRAT: Node 0 PXM 0 100000-f8000000
[ 0.000000] SRAT: Node 1 PXM 1 100000000-200000000
[ 0.000000] SRAT: Node 0 PXM 0 100000000-100000000
[ 0.000000] SRAT: Node 0 PXM 0 0-9fc00
[ 0.000000] Bootmem setup node 0 0000000000000000-0000000100000000
[ 0.000000] NODE_DATA [000000000001c040 - 000000000003403f]
[ 0.000000] bootmap [0000000000035000 - 0000000000054fff] pages 20
[ 0.000000] (9 early reservations) ==> bootmem [0000000000 - 0100000000]
[ 0.000000] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000]
[ 0.000000] #1 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 - 0000008000]
[ 0.000000] #2 [0000200000 - 00009e0d9c] TEXT DATA BSS ==> [0000200000 - 00009e0d9c]
[ 0.000000] #3 [0037a0b000 - 0037fefed3] RAMDISK ==> [0037a0b000 - 0037fefed3]
[ 0.000000] #4 [000009d000 - 0000100000] BIOS reserved ==> [000009d000 - 0000100000]
[ 0.000000] #5 [00009e1000 - 00009e11ad] BRK ==> [00009e1000 - 00009e11ad]
[ 0.000000] #6 [0000010000 - 0000014000] PGTABLE ==> [0000010000 - 0000014000]
[ 0.000000] #7 [0000014000 - 0000018000] PGTABLE ==> [0000014000 - 0000018000]
[ 0.000000] #8 [0000018000 - 000001c040] MEMNODEMAP ==> [0000018000 - 000001c040]
[ 0.000000] Bootmem setup node 1 0000000100000000-0000000200000000
[ 0.000000] NODE_DATA [0000000100000000 - 0000000100017fff]
[ 0.000000] bootmap [0000000100018000 - 0000000100037fff] pages 20
[ 0.000000] (9 early reservations) ==> bootmem [0100000000 - 0200000000]
[ 0.000000] #0 [0000000000 - 0000001000] BIOS data page
[ 0.000000] #1 [0000006000 - 0000008000] TRAMPOLINE
[ 0.000000] #2 [0000200000 - 00009e0d9c] TEXT DATA BSS
[ 0.000000] #3 [0037a0b000 - 0037fefed3] RAMDISK
[ 0.000000] #4 [000009d000 - 0000100000] BIOS reserved
[ 0.000000] #5 [00009e1000 - 00009e11ad] BRK
[ 0.000000] #6 [0000010000 - 0000014000] PGTABLE
[ 0.000000] #7 [0000014000 - 0000018000] PGTABLE
[ 0.000000] #8 [0000018000 - 000001c040] MEMNODEMAP
[ 0.000000] Scan SMP from ffff880000000000 for 1024 bytes.
[ 0.000000] Scan SMP from ffff88000009fc00 for 1024 bytes.
[ 0.000000] Scan SMP from ffff8800000f0000 for 65536 bytes.
[ 0.000000] found SMP MP-table at [ffff8800000ff780] ff780
[ 0.000000] mpc: fa3b0-fa50c
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0x00000010 -> 0x00001000
[ 0.000000] DMA32 0x00001000 -> 0x00100000
[ 0.000000] Normal 0x00100000 -> 0x00200000
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[3] active PFN ranges
[ 0.000000] 0: 0x00000010 -> 0x0000009f
[ 0.000000] 0: 0x00000100 -> 0x000f7ff0
[ 0.000000] 1: 0x00100000 -> 0x00200000
[ 0.000000] Detected use of extended apic ids on hypertransport bus
[ 0.000000] Detected use of extended apic ids on hypertransport bus
[ 0.000000] ACPI: PM-Timer IO Port: 0x1008
[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
[ 0.000000] ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
[ 0.000000] IOAPIC[0]: apic_id 4, version 0, address 0xfec00000, GSI 0-23
[ 0.000000] ACPI: IOAPIC (id[0x05] address[0xfebff000] gsi_base[24])
[ 0.000000] IOAPIC[1]: apic_id 5, version 0, address 0xfebff000, GSI 24-27
[ 0.000000] ACPI: IOAPIC (id[0x06] address[0xfebfe000] gsi_base[28])
[ 0.000000] IOAPIC[2]: apic_id 6, version 0, address 0xfebfe000, GSI 28-31
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] ACPI: HPET id: 0x102282a0 base: 0xfec01000
[ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
[ 0.000000] mapped APIC to ffffffffff5fc000 (fee00000)
[ 0.000000] mapped IOAPIC to ffffffffff5fb000 (fec00000)
[ 0.000000] mapped IOAPIC to ffffffffff5fa000 (febff000)
[ 0.000000] mapped IOAPIC to ffffffffff5f9000 (febfe000)
[ 0.000000] PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
[ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
[ 0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
[ 0.000000] PM: Registered nosave memory: 00000000f7ff0000 - 00000000f7fff000
[ 0.000000] PM: Registered nosave memory: 00000000f7fff000 - 00000000f8000000
[ 0.000000] PM: Registered nosave memory: 00000000f8000000 - 00000000ff780000
[ 0.000000] PM: Registered nosave memory: 00000000ff780000 - 0000000100000000
[ 0.000000] Allocating PCI resources starting at f8800000 (gap: f8000000:7780000)
[ 0.000000] NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:4 nr_node_ids:2
[ 0.000000] PERCPU: Remapped at ffffc20000000000 with large pages, static data 71776 bytes
[ 0.000000] Built 2 zonelists in Node order, mobility grouping on. Total pages: 2033901
[ 0.000000] Policy zone: Normal
[ 0.000000] Kernel command line: root=/dev/disk/by-id/ata-ST3120813AS_3LS0FAGL-part10 eth0=dhcp console=tty0 console=ttyS0,115200 resume=/dev/disk/by-id/ata-ST3120813AS_3LS0FAGL-part6 splash=silent showopts vga=0x314 apic=debug
[ 0.000000] Initializing CPU#0
[ 0.000000] Experimental hierarchical RCU implementation.
[ 0.000000] Experimental hierarchical RCU init done.
[ 0.000000] NR_IRQS:4352 nr_irqs:576
[ 0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes)
[ 0.000000] Fast TSC calibration using PIT
[ 0.000000] Detected 2192.534 MHz processor.
[ 0.004000] Console: colour dummy device 80x25
[ 0.004000] console [tty0] enabled
[ 0.004000] console [ttyS0] enabled
[ 0.004000] allocated 82575360 bytes of page_cgroup
[ 0.004000] please try cgroup_disable=memory option if you don't want
[ 0.004000] Checking aperture...
[ 0.004000] No AGP bridge found
[ 0.004000] Node 0: aperture @ 0 size 32 MB
[ 0.004000] Your BIOS doesn't leave a aperture memory hole
[ 0.004000] Please enable the IOMMU option in the BIOS setup
[ 0.004000] This costs you 64 MB of RAM
[ 0.004000] Mapping aperture over 65536 KB of RAM @ 20000000
[ 0.004000] PM: Registered nosave memory: 0000000020000000 - 0000000024000000
[ 0.004000] Memory: 7981076k/8388608k available (3350k kernel code, 131588k absent, 275944k reserved, 1936k data, 1544k init)
[ 0.004000] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
[ 0.004010] Calibrating delay loop (skipped), value calculated using timer frequency.. 4385.06 BogoMIPS (lpj=8770136)
[ 0.008000] Security Framework initialized
[ 0.008000] SELinux: Disabled at boot.
[ 0.008000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[ 0.008000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 0.008000] Mount-cache hash table entries: 256
[ 0.008000] Initializing cgroup subsys ns
[ 0.008000] Initializing cgroup subsys cpuacct
[ 0.008000] Initializing cgroup subsys memory
[ 0.008000] Initializing cgroup subsys devices
[ 0.008000] Initializing cgroup subsys freezer
[ 0.008000] Initializing cgroup subsys net_cls
[ 0.008000] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[ 0.008000] CPU: L2 Cache: 1024K (64 bytes/line)
[ 0.008000] CPU 0/0x0 -> Node 0
[ 0.008000] CPU: Physical Processor ID: 0
[ 0.008000] CPU: Processor Core ID: 0
[ 0.008000] ACPI: Core revision 20090320
[ 0.008000] Setting APIC routing to flat
[ 0.008000] Getting VERSION: 40010
[ 0.008000] Getting VERSION: 40010
[ 0.008000] Getting ID: 0
[ 0.008000] Getting ID: ff000000
[ 0.008000] Getting LVT0: 700
[ 0.008000] Getting LVT1: 400
[ 0.008000] enabled ExtINT on CPU#0
[ 0.008000] ESR value before enabling vector: 0x00000004 after: 0x00000000
[ 0.008000] ENABLING IO-APIC IRQs
[ 0.008000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
[ 0.008000] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
[ 0.008000] ...trying to set up timer (IRQ0) through the 8259A ...
[ 0.008000] ..... (found apic 0 pin 0) ...
[ 0.008000] ....... failed.
[ 0.008000] ...trying to set up timer as Virtual Wire IRQ...
[ 0.008000] ..... failed.
[ 0.008000] ...trying to set up timer as ExtINT IRQ...
[ 0.008000] ..... failed :(.
[ 0.008000] Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the 'noapic' option.
[ 0.008000]
[ 0.008000] Pid: 1, comm: swapper Not tainted 2.6.30-rc2-vanilla #22
[ 0.008000] Call Trace:
[ 0.008000] [<ffffffff8053b810>] panic+0x84/0x13a
[ 0.008000] [<ffffffff8074e2e9>] setup_IO_APIC+0x487/0x8ea
[ 0.008000] [<ffffffff8053b911>] ? printk+0x4b/0x62
[ 0.008000] [<ffffffff8074922d>] native_smp_prepare_cpus+0x2ff/0x3a1
[ 0.008000] [<ffffffff8073d7c2>] kernel_init+0x69/0x1b5
[ 0.008000] [<ffffffff8020d12a>] child_rip+0xa/0x20
[ 0.008000] [<ffffffff8073d759>] ? kernel_init+0x0/0x1b5
[ 0.008000] [<ffffffff8020d120>] ? child_rip+0x0/0x20


Booting with noapic:
[...]
[ 0.008000] Initializing cgroup subsys ns
[ 0.008000] Initializing cgroup subsys cpuacct
[ 0.008000] Initializing cgroup subsys memory
[ 0.008000] Initializing cgroup subsys devices
[ 0.008000] Initializing cgroup subsys freezer
[ 0.008000] Initializing cgroup subsys net_cls
[ 0.008000] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[ 0.008000] CPU: L2 Cache: 1024K (64 bytes/line)
[ 0.008000] CPU 0/0x0 -> Node 0
[ 0.008000] CPU: Physical Processor ID: 0
[ 0.008000] CPU: Processor Core ID: 0
[ 0.008000] ACPI: Core revision 20090320
[ 0.008000] ACPI: setting ELCR to 0200 (from 0e20)
[ 0.008000] Setting APIC routing to flat
[ 0.008000] CPU0: AMD Engineering Sample stepping 00


- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAknonRsACgkQLPWxlyuTD7KSDwCdGI8FqGgvpiciBY+LRq9QZLQ/
1b0AnigAAQtzzYFR9InctfPynAS3J4aV
=PR8g
-----END PGP SIGNATURE-----

2009-04-18 08:33:33

by Jan Kiszka

Subject: Re: [BUG] IO-APIC + timer doesn't work!

Jeff Mahoney wrote:
> Hi all -
>
> I saw this while booting 2.6.30-rc1, -rc2, and today's git, on one of
> my development nodes. This output is with apic=debug. With noapic,
> it still hung. Both outputs follow.
>
> git bisect leads to commit 8d6f0c8214928f7c5083dd54ecb69c5d615b516e,
> but I'm not seeing anything obvious there. Backing just that change
> out doesn't fix it.
>
> -Jeff
>
> apic=debug:
>
> [ 0.000000] Initializing cgroup subsys cpuset
> [ 0.000000] Initializing cgroup subsys cpu
> [ 0.000000] Linux version 2.6.30-rc2-vanilla (jeffm@sled2) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #22 SMP Thu Apr 16 17:25:38 EDT 2009
> [ 0.000000] Command line: root=/dev/disk/by-id/ata-ST3120813AS_3LS0FAGL-part10 eth0=dhcp console=tty0 console=ttyS0,115200 resume=/dev/disk/by-id/ata-ST3120813AS_3LS0FAGL-part6 splash=silent showopts vga=0x314 apic=debug
> [ 0.000000] KERNEL supported cpus:
> [ 0.000000] Intel GenuineIntel
> [ 0.000000] AMD AuthenticAMD
> [ 0.000000] Centaur CentaurHauls
> [ 0.000000] BIOS-provided physical RAM map:
> [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> [ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> [ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> [ 0.000000] BIOS-e820: 0000000000100000 - 00000000f7ff0000 (usable)
> [ 0.000000] BIOS-e820: 00000000f7ff0000 - 00000000f7fff000 (ACPI data)
> [ 0.000000] BIOS-e820: 00000000f7fff000 - 00000000f8000000 (ACPI NVS)
> [ 0.000000] BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved)
> [ 0.000000] BIOS-e820: 0000000100000000 - 0000000200000000 (usable)
> [ 0.000000] DMI 2.3 present.
> [ 0.000000] AMI BIOS detected: BIOS may corrupt low RAM, working around it.
> [ 0.000000] last_pfn = 0x200000 max_arch_pfn = 0x100000000
> [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
> [ 0.000000] last_pfn = 0xf7ff0 max_arch_pfn = 0x100000000
> [ 0.000000] Scanning 0 areas for low memory corruption
> [ 0.000000] modified physical RAM map:
> [ 0.000000] modified: 0000000000000000 - 0000000000010000 (reserved)
> [ 0.000000] modified: 0000000000010000 - 000000000009fc00 (usable)
> [ 0.000000] modified: 000000000009fc00 - 00000000000a0000 (reserved)
> [ 0.000000] modified: 00000000000e0000 - 0000000000100000 (reserved)
> [ 0.000000] modified: 0000000000100000 - 00000000f7ff0000 (usable)
> [ 0.000000] modified: 00000000f7ff0000 - 00000000f7fff000 (ACPI data)
> [ 0.000000] modified: 00000000f7fff000 - 00000000f8000000 (ACPI NVS)
> [ 0.000000] modified: 00000000ff780000 - 0000000100000000 (reserved)
> [ 0.000000] modified: 0000000100000000 - 0000000200000000 (usable)
> [ 0.000000] init_memory_mapping: 0000000000000000-00000000f7ff0000
> [ 0.000000] init_memory_mapping: 0000000100000000-0000000200000000
> [ 0.000000] RAMDISK: 37a0b000 - 37fefed3
> [ 0.000000] ACPI: RSDP 00000000000f6d40 00024 (v02 ACPIAM)
> [ 0.000000] ACPI: XSDT 00000000f7ff0100 00054 (v01 A M I OEMXSDT 06000514 MSFT 00000097)
> [ 0.000000] ACPI: FACP 00000000f7ff0281 000F4 (v01 A M I OEMFACP 06000514 MSFT 00000097)
> [ 0.000000] ACPI: DSDT 00000000f7ff0410 03591 (v01 0AAAA 0AAAA001 00000001 INTL 02002026)
> [ 0.000000] ACPI: FACS 00000000f7fff000 00040
> [ 0.000000] ACPI: APIC 00000000f7ff0380 00084 (v01 A M I OEMAPIC 06000514 MSFT 00000097)
> [ 0.000000] ACPI: OEMB 00000000f7fff040 00041 (v01 A M I OEMBIOS 06000514 MSFT 00000097)
> [ 0.000000] ACPI: SRAT 00000000f7ff39b0 00110 (v01 A M I OEMSRAT 06000514 MSFT 00000097)
> [ 0.000000] ACPI: HPET 00000000f7ff3ac0 00038 (v01 A M I OEMHPET 06000514 MSFT 00000097)
> [ 0.000000] ACPI: ASF! 00000000f7ff3b00 00086 (v01 AMIASF AMDSTRET 00000001 INTL 02002026)
> [ 0.000000] SRAT: PXM 0 -> APIC 0 -> Node 0
> [ 0.000000] SRAT: PXM 0 -> APIC 1 -> Node 0
> [ 0.000000] SRAT: PXM 1 -> APIC 2 -> Node 1
> [ 0.000000] SRAT: PXM 1 -> APIC 3 -> Node 1
> [ 0.000000] SRAT: Node 0 PXM 0 100000-f8000000
> [ 0.000000] SRAT: Node 1 PXM 1 100000000-200000000
> [ 0.000000] SRAT: Node 0 PXM 0 100000000-100000000
> [ 0.000000] SRAT: Node 0 PXM 0 0-9fc00
> [ 0.000000] Bootmem setup node 0 0000000000000000-0000000100000000
> [ 0.000000] NODE_DATA [000000000001c040 - 000000000003403f]
> [ 0.000000] bootmap [0000000000035000 - 0000000000054fff] pages 20
> [ 0.000000] (9 early reservations) ==> bootmem [0000000000 - 0100000000]
> [ 0.000000] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000]
> [ 0.000000] #1 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 - 0000008000]
> [ 0.000000] #2 [0000200000 - 00009e0d9c] TEXT DATA BSS ==> [0000200000 - 00009e0d9c]
> [ 0.000000] #3 [0037a0b000 - 0037fefed3] RAMDISK ==> [0037a0b000 - 0037fefed3]
> [ 0.000000] #4 [000009d000 - 0000100000] BIOS reserved ==> [000009d000 - 0000100000]
> [ 0.000000] #5 [00009e1000 - 00009e11ad] BRK ==> [00009e1000 - 00009e11ad]
> [ 0.000000] #6 [0000010000 - 0000014000] PGTABLE ==> [0000010000 - 0000014000]
> [ 0.000000] #7 [0000014000 - 0000018000] PGTABLE ==> [0000014000 - 0000018000]
> [ 0.000000] #8 [0000018000 - 000001c040] MEMNODEMAP ==> [0000018000 - 000001c040]
> [ 0.000000] Bootmem setup node 1 0000000100000000-0000000200000000
> [ 0.000000] NODE_DATA [0000000100000000 - 0000000100017fff]
> [ 0.000000] bootmap [0000000100018000 - 0000000100037fff] pages 20
> [ 0.000000] (9 early reservations) ==> bootmem [0100000000 - 0200000000]
> [ 0.000000] #0 [0000000000 - 0000001000] BIOS data page
> [ 0.000000] #1 [0000006000 - 0000008000] TRAMPOLINE
> [ 0.000000] #2 [0000200000 - 00009e0d9c] TEXT DATA BSS
> [ 0.000000] #3 [0037a0b000 - 0037fefed3] RAMDISK
> [ 0.000000] #4 [000009d000 - 0000100000] BIOS reserved
> [ 0.000000] #5 [00009e1000 - 00009e11ad] BRK
> [ 0.000000] #6 [0000010000 - 0000014000] PGTABLE
> [ 0.000000] #7 [0000014000 - 0000018000] PGTABLE
> [ 0.000000] #8 [0000018000 - 000001c040] MEMNODEMAP
> [ 0.000000] Scan SMP from ffff880000000000 for 1024 bytes.
> [ 0.000000] Scan SMP from ffff88000009fc00 for 1024 bytes.
> [ 0.000000] Scan SMP from ffff8800000f0000 for 65536 bytes.
> [ 0.000000] found SMP MP-table at [ffff8800000ff780] ff780
> [ 0.000000] mpc: fa3b0-fa50c
> [ 0.000000] Zone PFN ranges:
> [ 0.000000] DMA 0x00000010 -> 0x00001000
> [ 0.000000] DMA32 0x00001000 -> 0x00100000
> [ 0.000000] Normal 0x00100000 -> 0x00200000
> [ 0.000000] Movable zone start PFN for each node
> [ 0.000000] early_node_map[3] active PFN ranges
> [ 0.000000] 0: 0x00000010 -> 0x0000009f
> [ 0.000000] 0: 0x00000100 -> 0x000f7ff0
> [ 0.000000] 1: 0x00100000 -> 0x00200000
> [ 0.000000] Detected use of extended apic ids on hypertransport bus
> [ 0.000000] Detected use of extended apic ids on hypertransport bus
> [ 0.000000] ACPI: PM-Timer IO Port: 0x1008
> [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
> [ 0.000000] ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
> [ 0.000000] IOAPIC[0]: apic_id 4, version 0, address 0xfec00000, GSI 0-23
> [ 0.000000] ACPI: IOAPIC (id[0x05] address[0xfebff000] gsi_base[24])
> [ 0.000000] IOAPIC[1]: apic_id 5, version 0, address 0xfebff000, GSI 24-27
> [ 0.000000] ACPI: IOAPIC (id[0x06] address[0xfebfe000] gsi_base[28])
> [ 0.000000] IOAPIC[2]: apic_id 6, version 0, address 0xfebfe000, GSI 28-31
> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> [ 0.000000] Using ACPI (MADT) for SMP configuration information
> [ 0.000000] ACPI: HPET id: 0x102282a0 base: 0xfec01000
> [ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
> [ 0.000000] mapped APIC to ffffffffff5fc000 (fee00000)
> [ 0.000000] mapped IOAPIC to ffffffffff5fb000 (fec00000)
> [ 0.000000] mapped IOAPIC to ffffffffff5fa000 (febff000)
> [ 0.000000] mapped IOAPIC to ffffffffff5f9000 (febfe000)
> [ 0.000000] PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
> [ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
> [ 0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
> [ 0.000000] PM: Registered nosave memory: 00000000f7ff0000 - 00000000f7fff000
> [ 0.000000] PM: Registered nosave memory: 00000000f7fff000 - 00000000f8000000
> [ 0.000000] PM: Registered nosave memory: 00000000f8000000 - 00000000ff780000
> [ 0.000000] PM: Registered nosave memory: 00000000ff780000 - 0000000100000000
> [ 0.000000] Allocating PCI resources starting at f8800000 (gap: f8000000:7780000)
> [ 0.000000] NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:4 nr_node_ids:2
> [ 0.000000] PERCPU: Remapped at ffffc20000000000 with large pages, static data 71776 bytes
> [ 0.000000] Built 2 zonelists in Node order, mobility grouping on. Total pages: 2033901
> [ 0.000000] Policy zone: Normal
> [ 0.000000] Kernel command line: root=/dev/disk/by-id/ata-ST3120813AS_3LS0FAGL-part10 eth0=dhcp console=tty0 console=ttyS0,115200 resume=/dev/disk/by-id/ata-ST3120813AS_3LS0FAGL-part6 splash=silent showopts vga=0x314 apic=debug
> [ 0.000000] Initializing CPU#0
> [ 0.000000] Experimental hierarchical RCU implementation.
> [ 0.000000] Experimental hierarchical RCU init done.
> [ 0.000000] NR_IRQS:4352 nr_irqs:576
> [ 0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes)
> [ 0.000000] Fast TSC calibration using PIT
> [ 0.000000] Detected 2192.534 MHz processor.
> [ 0.004000] Console: colour dummy device 80x25
> [ 0.004000] console [tty0] enabled
> [ 0.004000] console [ttyS0] enabled
> [ 0.004000] allocated 82575360 bytes of page_cgroup
> [ 0.004000] please try cgroup_disable=memory option if you don't want
> [ 0.004000] Checking aperture...
> [ 0.004000] No AGP bridge found
> [ 0.004000] Node 0: aperture @ 0 size 32 MB
> [ 0.004000] Your BIOS doesn't leave a aperture memory hole
> [ 0.004000] Please enable the IOMMU option in the BIOS setup
> [ 0.004000] This costs you 64 MB of RAM
> [ 0.004000] Mapping aperture over 65536 KB of RAM @ 20000000
> [ 0.004000] PM: Registered nosave memory: 0000000020000000 - 0000000024000000
> [ 0.004000] Memory: 7981076k/8388608k available (3350k kernel code, 131588k absent, 275944k reserved, 1936k data, 1544k init)
> [ 0.004000] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
> [ 0.004010] Calibrating delay loop (skipped), value calculated using timer frequency.. 4385.06 BogoMIPS (lpj=8770136)
> [ 0.008000] Security Framework initialized
> [ 0.008000] SELinux: Disabled at boot.
> [ 0.008000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
> [ 0.008000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
> [ 0.008000] Mount-cache hash table entries: 256
> [ 0.008000] Initializing cgroup subsys ns
> [ 0.008000] Initializing cgroup subsys cpuacct
> [ 0.008000] Initializing cgroup subsys memory
> [ 0.008000] Initializing cgroup subsys devices
> [ 0.008000] Initializing cgroup subsys freezer
> [ 0.008000] Initializing cgroup subsys net_cls
> [ 0.008000] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
> [ 0.008000] CPU: L2 Cache: 1024K (64 bytes/line)
> [ 0.008000] CPU 0/0x0 -> Node 0
> [ 0.008000] CPU: Physical Processor ID: 0
> [ 0.008000] CPU: Processor Core ID: 0
> [ 0.008000] ACPI: Core revision 20090320
> [ 0.008000] Setting APIC routing to flat
> [ 0.008000] Getting VERSION: 40010
> [ 0.008000] Getting VERSION: 40010
> [ 0.008000] Getting ID: 0
> [ 0.008000] Getting ID: ff000000
> [ 0.008000] Getting LVT0: 700
> [ 0.008000] Getting LVT1: 400
> [ 0.008000] enabled ExtINT on CPU#0
> [ 0.008000] ESR value before enabling vector: 0x00000004 after: 0x00000000
> [ 0.008000] ENABLING IO-APIC IRQs
> [ 0.008000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
> [ 0.008000] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> [ 0.008000] ...trying to set up timer (IRQ0) through the 8259A ...
> [ 0.008000] ..... (found apic 0 pin 0) ...
> [ 0.008000] ....... failed.
> [ 0.008000] ...trying to set up timer as Virtual Wire IRQ...
> [ 0.008000] ..... failed.
> [ 0.008000] ...trying to set up timer as ExtINT IRQ...
> [ 0.008000] ..... failed :(.
> [ 0.008000] Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the 'noapic' option.

Hmmmmm. That somehow reminds me of what I thought I had to fix in the
HPET emulation of QEMU just recently [1] - because of 2.6.30-rc's behavior.

Could you try if writing 'delta' a second time makes any difference on
that box?

diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 648b3a2..523d72b 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -324,6 +324,7 @@ static void hpet_set_mode(enum clock_event_mode mode,
HPET_TN_SETVAL | HPET_TN_32BIT;
hpet_writel(cfg, HPET_Tn_CFG(timer));
hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
+ hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
hpet_start_counter();
hpet_print_config();
break;

Thanks,
Jan

[1] http://permalink.gmane.org/gmane.comp.emulators.qemu/41570

Attachments:

2009-04-18 19:53:20

by Jeff Mahoney

Subject: Re: [BUG] IO-APIC + timer doesn't work!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jan Kiszka wrote:
> Jeff Mahoney wrote:
>> Hi all -
>>
>> I saw this while booting 2.6.30-rc1, -rc2, and today's git, on one of
>> my development nodes. This output is with apic=debug. With noapic,
>> it still hung. Both outputs follow.
>>
>> git bisect leads to commit 8d6f0c8214928f7c5083dd54ecb69c5d615b516e,
>> but I'm not seeing anything obvious there. Backing just that change
>> out doesn't fix it.

[snip]

> Hmmmmm. That somehow reminds me of what I thought I had to fix in the
> HPET emulation of QEMU just recently [1] - because of 2.6.30-rc's behavior.
>
> Could you try if writing 'delta' a second time makes any difference on
> that box?
>
> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
> index 648b3a2..523d72b 100644
> --- a/arch/x86/kernel/hpet.c
> +++ b/arch/x86/kernel/hpet.c
> @@ -324,6 +324,7 @@ static void hpet_set_mode(enum clock_event_mode mode,
> HPET_TN_SETVAL | HPET_TN_32BIT;
> hpet_writel(cfg, HPET_Tn_CFG(timer));
> hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
> + hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
> hpet_start_counter();
> hpet_print_config();
> break;
>

Thanks, Jan.

That fixed it for me.

- -Jeff

- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAknqL4EACgkQLPWxlyuTD7JGSQCfROvm+88YIifOzWNar0MOCs3F
s5QAoKDi1IKw0Qrk6dky3iQ+u3sF2eAh
=pgI6
-----END PGP SIGNATURE-----

2009-04-18 20:06:46

by Ingo Molnar

Subject: Re: [BUG] IO-APIC + timer doesn't work!

* Jeff Mahoney <[email protected]> wrote:

> > Hmmmmm. That somehow reminds me of what I thought I had to fix in the
> > HPET emulation of QEMU just recently [1] - because of 2.6.30-rc's behavior.
> >
> > Could you try if writing 'delta' a second time makes any difference on
> > that box?
> >
> > diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
> > index 648b3a2..523d72b 100644
> > --- a/arch/x86/kernel/hpet.c
> > +++ b/arch/x86/kernel/hpet.c
> > @@ -324,6 +324,7 @@ static void hpet_set_mode(enum clock_event_mode mode,
> > HPET_TN_SETVAL | HPET_TN_32BIT;
> > hpet_writel(cfg, HPET_Tn_CFG(timer));
> > hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
> > + hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
> > hpet_start_counter();
> > hpet_print_config();
> > break;
> >
>
> Thanks, Jan.
>
> That fixed it for me.

I've queued it up (and i've got a test-system that might be affected
by a similar problem - it shows a similar crash very rarely), but it
would be nice to know why this duplicate writeout makes a
difference. Jan?

Ingo

2009-04-18 20:25:47

by Jan Kiszka

Subject: Re: [BUG] IO-APIC + timer doesn't work!

Ingo Molnar wrote:
> * Jeff Mahoney <[email protected]> wrote:
>
>>> Hmmmmm. That somehow reminds me of what I thought I had to fix in the
>>> HPET emulation of QEMU just recently [1] - because of 2.6.30-rc's behavior.
>>>
>>> Could you try if writing 'delta' a second time makes any difference on
>>> that box?
>>>
>>> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
>>> index 648b3a2..523d72b 100644
>>> --- a/arch/x86/kernel/hpet.c
>>> +++ b/arch/x86/kernel/hpet.c
>>> @@ -324,6 +324,7 @@ static void hpet_set_mode(enum clock_event_mode mode,
>>> HPET_TN_SETVAL | HPET_TN_32BIT;
>>> hpet_writel(cfg, HPET_Tn_CFG(timer));
>>> hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
>>> + hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
>>> hpet_start_counter();
>>> hpet_print_config();
>>> break;
>>>
>> Thanks, Jan.
>>
>> That fixed it for me.
>
> I've queued it up (and i've got a test-system that might be affected
> by a similar problem - it shows a similar crash very rarely), but it
> would be nice to know why this duplicate writeout makes a
> difference. Jan?
>
> Ingo

Well, if you look at the HPET spec [1], you first find the explanation
of the Tn_VAL_SET_CNF bit (HPET_TN_SETVAL):

"[...] By writing this bit to a 1, the software is then allowed to
directly set a periodic timer's accumulator."

That may sound like "you write to the comparator register if 0, and if
1, you set the accumulator". That's also how HPET was emulated in QEMU
so far.

But then you read on about changing the period of a running timer:

"If the software resets the main counter, the value in the comparator’s
value register needs to reset as well. This can be done by setting the
Tn_VAL_SET_CNF bit. Again, to avoid race conditions, this should be
done with the main counter halted. The following usage model is expected:
1) Software clears the GLOBAL_ENABLE_CNF bit to prevent any interrupts
2) Software Clears the main counter by writing a value of 00000000h to it.
3) Software sets the TIMER0_VAL_SET_CNF bit.
4) Software writes the new value in the TIMER0_COMPARATOR_VAL register
5) Software sets the GLOBAL_ENABLE_CNF bit to enable interrupts."

And that somehow sounds like you only need to write the new period once,
with Tn_VAL_SET_CNF = 1.

I bet now that both interpretations are implemented in silicon somewhere
out there - but I'm all ears to learn the right one (and potentially
re-fix QEMU).

Jan

[1] http://www.intel.com/hardwaredesign/hpetspec_1.pdf

Attachments:

2009-04-18 20:32:58

by Ingo Molnar

Subject: Re: [BUG] IO-APIC + timer doesn't work!

* Jan Kiszka <[email protected]> wrote:

> Ingo Molnar wrote:
> > * Jeff Mahoney <[email protected]> wrote:
> >
> >>> Hmmmmm. That somehow reminds me of what I thought I had to fix in the
> >>> HPET emulation of QEMU just recently [1] - because of 2.6.30-rc's behavior.
> >>>
> >>> Could you try if writing 'delta' a second time makes any difference on
> >>> that box?
> >>>
> >>> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
> >>> index 648b3a2..523d72b 100644
> >>> --- a/arch/x86/kernel/hpet.c
> >>> +++ b/arch/x86/kernel/hpet.c
> >>> @@ -324,6 +324,7 @@ static void hpet_set_mode(enum clock_event_mode mode,
> >>> HPET_TN_SETVAL | HPET_TN_32BIT;
> >>> hpet_writel(cfg, HPET_Tn_CFG(timer));
> >>> hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
> >>> + hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
> >>> hpet_start_counter();
> >>> hpet_print_config();
> >>> break;
> >>>
> >> Thanks, Jan.
> >>
> >> That fixed it for me.
> >
> > I've queued it up (and i've got a test-system that might be affected
> > by a similar problem - it shows a similar crash very rarely), but it
> > would be nice to know why this duplicate writeout makes a
> > difference. Jan?
> >
> > Ingo
>
> Well, if you look at the HPET spec [1], you first find the explanation
> of the Tn_VAL_SET_CNF bit (HPET_TN_SETVAL):
>
> "[...] By writing this bit to a 1, the software is then allowed to
> directly set a periodic timer's accumulator."
>
> That may sound like "you write to the comparator register if 0, and if
> 1, you set the accumulator". That's also how HPET was emulated in QEMU
> so far.
>
> But then you read on about changing the period of a running timer:
>
> "If the software resets the main counter, the value in the comparator’s
> value register needs to reset as well. This can be done by setting the
> Tn_VAL_SET_CNF bit. Again, to avoid race conditions, this should be
> done with the main counter halted. The following usage model is expected:
> 1) Software clears the GLOBAL_ENABLE_CNF bit to prevent any interrupts
> 2) Software Clears the main counter by writing a value of 00000000h to it.
> 3) Software sets the TIMER0_VAL_SET_CNF bit.
> 4) Software writes the new value in the TIMER0_COMPARATOR_VAL register
> 5) Software sets the GLOBAL_ENABLE_CNF bit to enable interrupts."
>
> And that somehow sounds like you only need to write the new period once,
> with Tn_VAL_SET_CNF = 1.
>
> I bet now that both interpretations are implemented in silicon somewhere
> out there - but I'm all ears to learn the right one (and potentially
> re-fix QEMU).
>
> Jan
>
> [1] http://www.intel.com/hardwaredesign/hpetspec_1.pdf

i might be a bit slow today, but how does the above transform into:

hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));

? It sets the same register twice.

I'm totally happy if it does transform into that under some quirky
interpretation. Since it solved the problem for Jeff, we'll likely
add it even if there's no actual explanation ;-) But it would be
nice to somehow come up with a line of reasoning that ends with:

... and for that reason, we set the value twice:

hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));

right?

Ingo

2009-04-18 20:46:48

by Jan Kiszka

Subject: Re: [BUG] IO-APIC + timer doesn't work!

Ingo Molnar wrote:
> * Jan Kiszka <[email protected]> wrote:
>
>> Ingo Molnar wrote:
>>> * Jeff Mahoney <[email protected]> wrote:
>>>
>>>>> Hmmmmm. That somehow reminds me of what I thought I had to fix in the
>>>>> HPET emulation of QEMU just recently [1] - because of 2.6.30-rc's behavior.
>>>>>
>>>>> Could you try if writing 'delta' a second time makes any difference on
>>>>> that box?
>>>>>
>>>>> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
>>>>> index 648b3a2..523d72b 100644
>>>>> --- a/arch/x86/kernel/hpet.c
>>>>> +++ b/arch/x86/kernel/hpet.c
>>>>> @@ -324,6 +324,7 @@ static void hpet_set_mode(enum clock_event_mode mode,
>>>>> HPET_TN_SETVAL | HPET_TN_32BIT;
>>>>> hpet_writel(cfg, HPET_Tn_CFG(timer));
>>>>> hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
>>>>> + hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
>>>>> hpet_start_counter();
>>>>> hpet_print_config();
>>>>> break;
>>>>>
>>>> Thanks, Jan.
>>>>
>>>> That fixed it for me.
>>> I've queued it up (and i've got a test-system that might be affected
>>> by a similar problem - it shows a similar crash very rarely), but it
>>> would be nice to know why this duplicate writeout makes a
>>> difference. Jan?
>>>
>>> Ingo
>> Well, if you look at the HPET spec [1], you first find the explanation
>> of the Tn_VAL_SET_CNF bit (HPET_TN_SETVAL):
>>
>> "[...] By writing this bit to a 1, the software is then allowed to
>> directly set a periodic timer's accumulator."
>>
>> That may sound like "you write to the comparator register if 0, and if
>> 1, you set the accumulator". That's also how HPET was emulated in QEMU
>> so far.
>>
>> But then you read on about changing the period of a running timer:
>>
>> "If the software resets the main counter, the value in the comparator’s
>> value register needs to reset as well. This can be done by setting the
>> Tn_VAL_SET_CNF bit. Again, to avoid race conditions, this should be
>> done with the main counter halted. The following usage model is expected:
>> 1) Software clears the GLOBAL_ENABLE_CNF bit to prevent any interrupts
>> 2) Software Clears the main counter by writing a value of 00000000h to it.
>> 3) Software sets the TIMER0_VAL_SET_CNF bit.
>> 4) Software writes the new value in the TIMER0_COMPARATOR_VAL register
>> 5) Software sets the GLOBAL_ENABLE_CNF bit to enable interrupts."
>>
>> And that somehow sounds like you only need to write the new period once,
>> with Tn_VAL_SET_CNF = 1.
>>
>> I bet now that both interpretations are implemented in silicon somewhere
>> out there - but I'm all ears to learn the right one (and potentially
>> re-fix QEMU).
>>
>> Jan
>>
>> [1] http://www.intel.com/hardwaredesign/hpetspec_1.pdf
>
> i might be a bit slow today, but how does the above transform into:
>
> hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
> hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
>
> ? It sets the same register twice.

No, sorry, I missed to cite also this from the Tn_SET_VAL_CFG
explanation: "Software does NOT have to write this bit back to 0 (it
automatically clears)." So the second write will already take place
without it.

>
> I'm totally happy if it does transform into that under some quirky
> interpretation. Since it solved the problem for Jeff, we'll likely
> add it even if there's no actual explanation ;-) But it would be
> nice to somehow come up with a line of reasoning that ends with:
>
> ... and for that reason, we set the value twice:
>
> hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
> hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
>
> right?
>
> Ingo

I'd like to give someone from AMD or Intel or whoever already
implemented such a logic a chance to comment on it. If this doesn't
happen, you may add:

"Some HPET implementations apparently only allow exclusive access to
accumulator and comparator register, instead of writing both in parallel
if HPET_TN_SETVAL is set. In that case we have to write a second time
because HPET_TN_SETVAL will then be cleared again and the write will hit
the comparator register."

Jan

Attachments:

2009-04-20 08:59:26

by tip-bot for Andreas Herrmann

Subject: Re: [BUG] IO-APIC + timer doesn't work!

On Fri, Apr 17, 2009 at 11:15:39AM -0400, Jeff Mahoney wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all -
>
> I saw this while booting 2.6.30-rc1, -rc2, and today's git, on one of
> my development nodes. This output is with apic=debug. With noapic,
> it still hung. Both outputs follow.
>
> git bisect leads to commit 8d6f0c8214928f7c5083dd54ecb69c5d615b516e,
> but I'm not seeing anything obvious there. Backing just that change
> out doesn't fix it.
>
> - -Jeff

This looks similar to http://bugzilla.kernel.org/show_bug.cgi?id=12961

Can you please provide lspci -nnxxx and dmesg when booting with hpet=verbose.

Thanks,

Andreas

2009-04-20 09:04:34

by tip-bot for Andreas Herrmann

Subject: Re: [BUG] IO-APIC + timer doesn't work!

On Fri, Apr 17, 2009 at 11:15:39AM -0400, Jeff Mahoney wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all -
>
> I saw this while booting 2.6.30-rc1, -rc2, and today's git, on one of
> my development nodes. This output is with apic=debug. With noapic,
> it still hung. Both outputs follow.
>
> git bisect leads to commit 8d6f0c8214928f7c5083dd54ecb69c5d615b516e,
> but I'm not seeing anything obvious there. Backing just that change
> out doesn't fix it.

It's the next commit c23e253e67c9d8a91a0ffa33c1f571a17f0a2403 that
causes the problems.

On another system I've seen that resetting the HPET_COUNTER did not
take effect. I am going to provide a fix for that but had no time yet
to test this on an affected system.


Regards,
Andreas

2009-04-20 14:23:49

by Jeff Mahoney

Subject: Re: [BUG] IO-APIC + timer doesn't work!

00:06.0 PCI bridge [0604]: Advanced Micro Devices [AMD] AMD-8111 PCI [1022:7460] (rev 07)
00: 22 10 60 74 17 01 30 02 07 00 04 06 00 40 01 00
10: 00 00 00 00 00 00 00 00 00 03 03 40 90 b0 00 02
20: 90 fc a0 fe f0 ff 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 00 0a 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 04 06 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 08 f0 86 00 20 00 00 00 d0 00 00 00 22 00 01 00
d0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 0d 00 0c 00 0d 00 0d 00 13 00 0c 00 00 00 00 00
f0: 08 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00

00:07.0 ISA bridge [0601]: Advanced Micro Devices [AMD] AMD-8111 LPC [1022:7468] (rev 05)
00: 22 10 68 74 0f 00 20 02 05 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 22 10 68 74
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 30 07 80 01 00 00 80 0f fd 00 01 00 00 00 c0
50: 00 00 00 00 8d 71 00 00 48 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 22 10 68 74 00 de 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 01 10 c0 fe 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:07.1 IDE interface [0101]: Advanced Micro Devices [AMD] AMD-8111 IDE [1022:7469] (rev 03)
00: 22 10 69 74 05 00 00 02 03 8a 01 01 00 20 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: a1 ff 00 00 00 00 00 00 00 00 00 00 22 10 69 74
30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00
40: 03 f0 00 00 00 00 00 00 a8 a8 a8 20 3f 00 ff 20
50: 03 03 03 c0 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 22 10 69 74 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:07.2 SMBus [0c05]: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 [1022:746a] (rev 02)
00: 22 10 6a 74 01 00 00 02 02 00 05 0c 00 40 00 00
10: 01 cc 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 22 10 6a 74
30: 00 00 00 00 00 00 00 00 00 00 00 00 09 04 00 00
40: 02 00 05 0c 22 10 6a 74 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:07.3 Bridge [0680]: Advanced Micro Devices [AMD] AMD-8111 ACPI [1022:746b] (rev 05)
00: 22 10 6b 74 00 00 80 02 05 00 80 06 00 40 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 22 10 6b 74
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 80 b1 09 04 00 00 00 00 20 04 50 00 00 00 00 03
50: 01 00 00 00 0f 00 00 00 01 10 00 00 00 00 00 00
60: 00 00 80 06 13 00 00 00 00 00 00 00 00 00 00 00
70: 06 29 4b d5 0c 00 00 00 00 00 00 00 22 10 6b 74
80: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 4f c1 39 00 00 00 00 00 00 00 00 00 00 00 00 00

00:0a.0 PCI bridge [0604]: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge [1022:7450] (rev 12)
00: 22 10 50 74 16 01 30 02 12 00 04 06 00 40 81 00
10: 00 00 00 00 00 00 00 00 00 02 02 40 f1 01 20 22
20: 80 fc 80 fc 51 ff 51 ff 00 00 00 00 00 00 00 00
30: 00 00 00 00 a0 00 00 00 00 00 00 00 ff 00 05 00
40: 04 00 1c 00 00 00 00 00 02 0d 00 00 01 2c 00 00
50: 00 00 03 00 00 00 05 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 07 b8 83 00 50 00 03 00 0e 00 ff ff 02 00 ff ff
b0: 00 00 00 00 00 00 00 00 08 c0 00 80 00 00 00 05
c0: 08 00 4a 00 20 00 11 11 20 00 00 00 22 04 35 00
d0: 02 00 35 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 08 08 0d 00 08 08 0d 00 0f 0f 15 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:0a.1 PIC [0800]: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC [1022:7451] (rev 01)
00: 22 10 51 74 06 00 00 02 01 10 00 08 00 00 00 00
10: 04 f0 bf fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 22 10 c0 36
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 03 00 00 00 04 f0 bf fe 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:0b.0 PCI bridge [0604]: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge [1022:7450] (rev 12)
00: 22 10 50 74 17 01 30 02 12 00 04 06 00 40 81 00
10: 00 00 00 00 00 00 00 00 00 01 01 40 81 81 20 02
20: 70 fc 70 fc f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 a0 00 00 00 00 00 00 00 ff 00 05 00
40: 04 00 1f 00 00 00 00 00 00 00 00 00 01 2c 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 07 b8 03 00 58 00 03 00 0e 00 ff ff 02 00 ff ff
b0: 00 00 00 00 00 00 00 00 08 00 00 80 00 00 00 06
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:0b.1 PIC [0800]: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC [1022:7451] (rev 01)
00: 22 10 51 74 06 00 00 02 01 10 00 08 00 00 00 00
10: 04 e0 bf fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 22 10 c0 36
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 03 00 00 00 04 e0 bf fe 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100]
00: 22 10 00 11 00 00 10 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00
40: 01 01 03 00 02 02 01 00 01 01 01 00 01 01 01 00
50: 01 01 01 00 01 01 01 00 01 01 01 00 01 01 01 00
60: 10 00 03 00 e4 02 00 00 20 c8 0e 0f 3c 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 08 a0 01 21 20 00 11 11 22 06 75 80 02 00 00 00
90: 13 56 13 04 00 00 00 00 03 00 00 00 00 00 00 00
a0: 08 c0 01 21 d0 00 11 77 22 04 75 80 02 00 00 00
b0: 12 86 42 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 08 00 01 21 20 00 11 11 22 04 75 80 02 00 00 00
d0: 56 04 51 02 00 00 ff 00 07 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101]
00: 22 10 01 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 03 00 00 00 00 00 ff 00 03 00 00 01 01 00 ff 01
50: 00 00 00 00 02 00 00 00 00 00 00 00 03 00 00 00
60: 00 00 00 00 04 00 00 00 00 00 00 00 05 00 00 00
70: 00 00 00 00 06 00 00 00 00 00 00 00 07 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 03 0a 00 00 20 0b 00 00 03 00 f8 00 20 ff ff 00
c0: 13 10 00 00 20 f0 ff 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 03 02 00 ff 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102]
00: 22 10 02 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 01 00 00 00 01 20 00 00 01 40 00 00 01 60 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 9e e0 0f 00 9e e0 0f 00 9e e0 0f 00 9e e0 0f
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 77 00 00 00 00 00 00 00 42 35 82 13 31 0b 10 00
90: 00 8c 03 48 08 0a 7b 0e 00 00 00 00 09 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 16 63 72 8e 35 00 00 00 ba f6 0c 00 03 e4 ac 08
c0: 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: da c3 49 ad d9 51 8a 18 ba c9 0f 0d 94 70 80 06
e0: b8 7e 9b 36 d7 4d 5e d9 8b 85 36 0a 5f d7 df 34
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103]
00: 22 10 03 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: ff 3b 00 00 40 00 40 08 00 00 00 00 00 00 00 00
50: 28 fe ff ff 00 00 00 00 00 00 00 00 00 47 6a 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 11 01 02 51 11 80 00 50 00 38 00 08 1a 22 00 00
80: 00 00 07 23 13 21 13 00 00 00 00 00 00 00 00 00
90: 03 00 00 00 10 00 00 00 00 d4 f6 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 3e 00 00 20 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 07 a7 e2 04 10 27 60 20 25 00 00 00
e0: 00 00 00 00 24 11 52 14 1f 11 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:19.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100]
00: 22 10 00 11 00 00 10 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00
40: 02 02 01 00 01 01 03 00 01 01 01 00 01 01 01 00
50: 01 01 01 00 01 01 01 00 01 01 01 00 01 01 01 00
60: 11 00 03 00 e4 00 00 00 20 c8 0e 0f 10 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 08 a0 01 21 20 00 11 11 22 06 75 80 02 00 00 00
90: 13 56 13 04 00 00 00 00 03 00 00 00 00 00 00 00
a0: 08 c0 01 21 d0 00 11 77 22 04 75 80 02 00 00 00
b0: 91 75 20 02 00 00 00 00 00 00 00 00 00 00 00 00
c0: 08 00 01 21 d0 00 11 77 22 04 75 80 02 00 00 00
d0: 56 05 51 02 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:19.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101]
00: 22 10 01 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 03 00 00 00 00 00 ff 00 03 00 00 01 01 00 ff 01
50: 00 00 00 00 02 00 00 00 00 00 00 00 03 00 00 00
60: 00 00 00 00 04 00 00 00 00 00 00 00 05 00 00 00
70: 00 00 00 00 06 00 00 00 00 00 00 00 07 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 03 0a 00 00 20 0b 00 00 03 00 f8 00 20 ff ff 00
c0: 13 10 00 00 20 f0 ff 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 03 02 00 ff 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:19.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102]
00: 22 10 02 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 01 00 00 00 01 20 00 00 01 40 00 00 01 60 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 9e e0 0f 00 9e e0 0f 00 9e e0 0f 00 9e e0 0f
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 77 00 00 00 00 00 00 00 42 35 82 13 31 0b 10 00
90: 00 8c 03 48 08 0a 7b 0e 00 00 00 00 09 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: c8 f3 cf 8c 35 00 00 00 b6 bd 0a aa e4 3e 28 2f
c0: 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 8d e2 78 da e5 a4 d9 20 62 ee ea 7b a7 eb 6c 8a
e0: b6 df c3 2a 60 4f 5c 75 5c 3d f7 f5 db cd 34 b8
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:19.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103]
00: 22 10 03 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: ff 3b 00 00 40 00 40 08 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 40 8d 59 00
60: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 11 01 02 51 11 80 00 50 00 38 00 08 1a 22 00 00
80: 00 00 07 23 13 21 13 00 00 00 00 00 00 00 00 00
90: 03 00 00 00 10 00 00 00 00 d4 f6 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 3e 00 00 80 ff 8f 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 07 a7 e2 04 10 27 60 20 25 00 00 00
e0: 00 00 00 00 24 08 50 10 1f 11 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01:03.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller [1106:3044] (rev 46)
00: 06 11 44 30 17 01 10 02 46 10 00 0c 10 40 00 00
10: 00 f8 7f fc 01 8c 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 e9 e8
30: 00 00 00 00 50 00 00 00 00 00 00 00 05 01 00 20
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 01 00 02 e4 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

02:09.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet [14e4:1648] (rev 03)
00: e4 14 48 16 46 01 b0 02 03 00 00 02 10 40 80 00
10: 04 00 80 fc 00 00 00 00 04 00 8f fc 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 e4 14 44 16
30: 00 00 8e fc 40 00 00 00 00 00 00 00 05 01 40 00
40: 07 48 08 00 48 02 43 04 01 50 02 c0 00 21 00 00
50: 03 58 28 00 38 a0 00 88 05 00 86 00 00 00 00 00
60: 01 00 00 00 65 08 00 00 98 02 03 20 00 40 9f 76
70: e2 30 00 00 c6 00 00 80 4c 5b 03 00 00 00 00 00
80: 00 00 00 00 0b 61 8b d9 34 00 13 04 82 90 28 02
90: 09 97 00 01 67 00 00 00 00 00 00 00 67 00 00 00
a0: 00 00 00 00 9f 01 00 00 00 00 00 00 b2 01 00 00
b0: 00 00 00 00 00 00 00 c2 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

02:09.1 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet [14e4:1648] (rev 03)
00: e4 14 48 16 06 01 b0 02 03 00 00 02 10 40 80 00
10: 04 00 83 fc 00 00 00 00 04 00 82 fc 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 e4 14 44 16
30: 00 00 81 fc 40 00 00 00 00 00 00 00 0a 02 40 00
40: 07 48 32 00 49 02 43 04 01 50 02 c0 00 20 00 00
50: 03 58 00 00 01 04 11 08 05 00 86 00 00 00 20 04
60: 00 00 40 00 00 00 00 00 9a 02 03 20 00 40 9f 76
70: a2 32 00 00 c6 00 00 00 10 70 00 00 00 00 00 00
80: 00 00 00 00 68 a1 1e d3 34 00 00 00 fe 90 60 02
90: 01 07 00 01 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

03:00.0 USB Controller [0c03]: Advanced Micro Devices [AMD] AMD-8111 USB [1022:7464] (rev 0b)
00: 22 10 64 74 17 01 80 02 0b 10 03 0c 00 40 80 00
10: 00 c0 af fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 22 10 64 74
30: 00 00 00 00 00 00 00 00 00 00 00 00 09 04 00 50
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 22 10 64 74 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

03:00.1 USB Controller [0c03]: Advanced Micro Devices [AMD] AMD-8111 USB [1022:7464] (rev 0b)
00: 22 10 64 74 17 01 80 02 0b 10 03 0c 00 40 00 00
10: 00 d0 af fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 22 10 64 74
30: 00 00 00 00 00 00 00 00 00 00 00 00 09 04 00 50
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 22 10 64 74 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

03:05.0 Mass storage controller [0180]: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller [1095:3114] (rev 02)
00: 95 10 14 31 07 01 b0 02 02 00 80 01 10 40 00 00
10: 01 bc 00 00 81 b8 00 00 01 b8 00 00 01 ac 00 00
20: 81 a8 00 00 00 ec af fe 00 00 00 00 95 10 14 31
30: 00 00 a0 fe 60 00 00 00 00 00 00 00 0a 01 00 00
40: 02 00 00 00 00 18 40 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 01 00 22 06 00 40 00 64 00 00 00 00 00 00 00 00
70: 08 00 60 00 00 10 91 37 00 00 60 00 00 00 00 00
80: 03 00 00 00 22 00 00 00 00 00 00 00 bf 7e f7 3f
90: 00 00 00 09 ff ff 00 00 00 00 00 19 00 00 00 00
a0: 01 21 15 65 dd 62 dd 62 92 43 92 43 09 40 09 40
b0: 01 21 15 65 dd 62 dd 62 92 43 92 43 09 40 09 40
c0: 84 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

03:06.0 VGA compatible controller [0300]: ATI Technologies Inc Rage XL [1002:4752] (rev 27)
00: 02 10 52 47 87 00 90 02 27 00 00 03 10 40 00 00
10: 00 00 00 fd 01 b0 00 00 00 f0 af fe 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 08 80
30: 00 00 ac fe 5c 00 00 00 00 00 00 00 0b 01 08 00
40: 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 02 5c 10 00 01 00 00 ff 00 00 00 00 01 00 02 06
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Attachments:

2009-04-21 18:01:28

by tip-bot for Andreas Herrmann

Subject: Re: [BUG] IO-APIC + timer doesn't work!

On Mon, Apr 20, 2009 at 10:23:18AM -0400, Jeff Mahoney wrote:
> Andreas Herrmann wrote:
> > On Fri, Apr 17, 2009 at 11:15:39AM -0400, Jeff Mahoney wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Hi all -
> >>
> >> I saw this while booting 2.6.30-rc1, -rc2, and today's git, on one of
> >> my development nodes. This output is with apic=debug. With noapic,
> >> it still hung. Both outputs follow.
> >>
> >> git bisect leads to commit 8d6f0c8214928f7c5083dd54ecb69c5d615b516e,
> >> but I'm not seeing anything obvious there. Backing just that change
> >> out doesn't fix it.
> >>
> >> - -Jeff
> >
> > This looks similar to http://bugzilla.kernel.org/show_bug.cgi?id=12961
> >
> > Can you please provide lspci -nnxxx and dmesg when booting with hpet=verbose.
>
> Sure, attached.
>
> -Jeff
>
> --
> Jeff Mahoney
> SUSE Labs

> [ 0.004000] hpet: hpet_enable(842):
> [ 0.004000] hpet: ID: 0x10228203, PERIOD: 0x429b17f
> [ 0.004000] hpet: CFG: 0x0, STATUS: 0x0
> [ 0.004000] hpet: COUNTER_l: 0x0, COUNTER_h: 0x0
> [ 0.004000] hpet: T0: CFG_l: 0x10, CFG_h: 0xfdefa
> [ 0.004000] hpet: T0: CMP_l: 0xffffffff, CMP_h: 0x0
> [ 0.004000] hpet: T0 ROUTE_l: 0x0, ROUTE_h: 0x0
> [ 0.004000] hpet: T1: CFG_l: 0x0, CFG_h: 0xfdefa
> [ 0.004000] hpet: T1: CMP_l: 0xffffffff, CMP_h: 0x0
> [ 0.004000] hpet: T1 ROUTE_l: 0x0, ROUTE_h: 0x0
> [ 0.004000] hpet: T2: CFG_l: 0x0, CFG_h: 0xfdefa
> [ 0.004000] hpet: T2: CMP_l: 0xffffffff, CMP_h: 0x0
> [ 0.004000] hpet: T2 ROUTE_l: 0x0, ROUTE_h: 0x0
> [ 0.004000] hpet: hpet_set_mode(328):
> [ 0.004000] hpet: ID: 0x10228203, PERIOD: 0x429b17f
> [ 0.004000] hpet: CFG: 0x3, STATUS: 0x1
> [ 0.004000] hpet: COUNTER_l: 0x2b4a5, COUNTER_h: 0x0
^^^^^^^
> [ 0.004000] hpet: T0: CFG_l: 0x261c, CFG_h: 0xfdefa
> [ 0.004000] hpet: T0: CMP_l: 0xdfb7, CMP_h: 0x0
^^^^^^

Same as in above mentioned bugzilla (and btw with similar chipset).
First I thought that reset of HPET_COUNTER had no effect but in fact
this worked. HPET implementation on that chipset differs from
other implementation wrt setting the delta when programmed in
periodic mode. T0_CMP is less than COUNTER (next interrupt
usually happens after COUNTER overflows). But this does
not matter as the kernel detected that timer does not properly
work:

..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...

See for instance
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24674.pdf

I suggest to partially revert my last hpet-commit. See attached patch.

Attached patch was tested on a system with AMD81xx chipset and also on
the system where I've encountered the system hang when main counter
was neither reset or stopped during programming of HPET in periodic mode.


Regards,
Andreas


---
x86: hpet: fix periodic mode programming on AMD 81xx

Impact: fix boot time hang on machines with AMD 81xx chipset

(See http://bugzilla.kernel.org/show_bug.cgi?id=12961)

It partially reverts commit c23e253e67c9d8a91a0ffa33c1f571a17f0a2403
(x86: hpet: stop HPET_COUNTER when programming periodic mode)

HPET on AMD 81xx chipset needs a second write (with HPET_TN_SETVAL
cleared) to T0_CMP register to set the period in periodic mode.

With this patch HPET_COUNTER is still stopped but not reset when HPET
is programmed in periodic mode. This should help to avoid races when
HPET is programmed in periodic mode and fixes a boot time hang that
I've observed on a machine when using 1000HZ.

Signed-off-by: Andreas Herrmann <[email protected]>
---
arch/x86/kernel/hpet.c | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 648b3a2..b30f79c 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -236,6 +236,10 @@ static void hpet_stop_counter(void)
unsigned long cfg = hpet_readl(HPET_CFG);
cfg &= ~HPET_CFG_ENABLE;
hpet_writel(cfg, HPET_CFG);
+}
+
+static void hpet_reset_counter(void)
+{
hpet_writel(0, HPET_COUNTER);
hpet_writel(0, HPET_COUNTER + 4);
}
@@ -250,6 +254,7 @@ static void hpet_start_counter(void)
static void hpet_restart_counter(void)
{
hpet_stop_counter();
+ hpet_reset_counter();
hpet_start_counter();
}

@@ -309,7 +314,7 @@ static int hpet_setup_msi_irq(unsigned int irq);
static void hpet_set_mode(enum clock_event_mode mode,
struct clock_event_device *evt, int timer)
{
- unsigned long cfg;
+ unsigned long cfg, cmp, now;
uint64_t delta;

switch (mode) {
@@ -317,12 +322,23 @@ static void hpet_set_mode(enum clock_event_mode mode,
hpet_stop_counter();
delta = ((uint64_t)(NSEC_PER_SEC/HZ)) * evt->mult;
delta >>= evt->shift;
+ now = hpet_readl(HPET_COUNTER);
+ cmp = now + (unsigned long) delta;
cfg = hpet_readl(HPET_Tn_CFG(timer));
/* Make sure we use edge triggered interrupts */
cfg &= ~HPET_TN_LEVEL;
cfg |= HPET_TN_ENABLE | HPET_TN_PERIODIC |
HPET_TN_SETVAL | HPET_TN_32BIT;
hpet_writel(cfg, HPET_Tn_CFG(timer));
+ hpet_writel(cmp, HPET_Tn_CMP(timer));
+ udelay(1);
+ /*
+ * HPET on AMD 81xx needs a second write (with HPET_TN_SETVAL
+ * cleared) to T0_CMP to set the period. The HPET_TN_SETVAL
+ * bit is automatically cleared after the first write.
+ * (See AMD-8111 HyperTransport I/O Hub Data Sheet,
+ * Publication # 24674)
+ */
hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
hpet_start_counter();
hpet_print_config();
--
1.6.2

2009-04-22 10:20:30

by tip-bot for Andreas Herrmann

Subject: Re: [BUG] IO-APIC + timer doesn't work!

On Sat, Apr 18, 2009 at 10:46:32PM +0200, Jan Kiszka wrote:
> Ingo Molnar wrote:
> > * Jan Kiszka <[email protected]> wrote:
> >
> >> Ingo Molnar wrote:
> >>> * Jeff Mahoney <[email protected]> wrote:
> >>>
> >>>>> Hmmmmm. That somehow reminds me of what I thought I had to fix in the
> >>>>> HPET emulation of QEMU just recently [1] - because of 2.6.30-rc's behavior.
> >>>>>
> >>>>> Could you try if writing 'delta' a second time makes any difference on
> >>>>> that box?
> >>>>>
> >>>>> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
> >>>>> index 648b3a2..523d72b 100644
> >>>>> --- a/arch/x86/kernel/hpet.c
> >>>>> +++ b/arch/x86/kernel/hpet.c
> >>>>> @@ -324,6 +324,7 @@ static void hpet_set_mode(enum clock_event_mode mode,
> >>>>> HPET_TN_SETVAL | HPET_TN_32BIT;
> >>>>> hpet_writel(cfg, HPET_Tn_CFG(timer));
> >>>>> hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
> >>>>> + hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
> >>>>> hpet_start_counter();
> >>>>> hpet_print_config();
> >>>>> break;
> >>>>>
> >>>> Thanks, Jan.
> >>>>
> >>>> That fixed it for me.
> >>> I've queued it up (and i've got a test-system that might be affected
> >>> by a similar problem - it shows a similar crash very rarely), but it
> >>> would be nice to know why this duplicate writeout makes a
> >>> difference. Jan?
> >>>
> >>> Ingo
> >> Well, if you look at the HPET spec [1], you first find the explanation
> >> of the Tn_VAL_SET_CNF bit (HPET_TN_SETVAL):
> >>
> >> "[...] By writing this bit to a 1, the software is then allowed to
> >> directly set a periodic timer's accumulator."
> >>
> >> That may sound like "you write to the comparator register if 0, and if
> >> 1, you set the accumulator". That's also how HPET was emulated in QEMU
> >> so far.
> >>
> >> But then you read on about changing the period of a running timer:
> >>
> >> "If the software resets the main counter, the value in the comparator’s
> >> value register needs to reset as well. This can be done by setting the
> >> Tn_VAL_SET_CNF bit. Again, to avoid race conditions, this should be
> >> done with the main counter halted. The following usage model is expected:
> >> 1) Software clears the GLOBAL_ENABLE_CNF bit to prevent any interrupts
> >> 2) Software Clears the main counter by writing a value of 00000000h to it.
> >> 3) Software sets the TIMER0_VAL_SET_CNF bit.
> >> 4) Software writes the new value in the TIMER0_COMPARATOR_VAL register
> >> 5) Software sets the GLOBAL_ENABLE_CNF bit to enable interrupts."
> >>
> >> And that somehow sounds like you only need to write the new period once,
> >> with Tn_VAL_SET_CNF = 1.
> >>
> >> I bet now that both interpretations are implemented in silicon somewhere
> >> out there - but I'm all ears to learn the right one (and potentially
> >> re-fix QEMU).
> >>
> >> Jan
> >>
> >> [1] http://www.intel.com/hardwaredesign/hpetspec_1.pdf
> >
> > i might be a bit slow today, but how does the above transform into:
> >
> > hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
> > hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
> >
> > ? It sets the same register twice.
>
> No, sorry, I missed to cite also this from the Tn_SET_VAL_CFG
> explanation: "Software does NOT have to write this bit back to 0 (it
> automatically clears)." So the second write will already take place
> without it.
>
> >
> > I'm totally happy if it does transform into that under some quirky
> > interpretation. Since it solved the problem for Jeff, we'll likely
> > add it even if there's no actual explanation ;-) But it would be
> > nice to somehow come up with a line of reasoning that ends with:
> >
> > ... and for that reason, we set the value twice:
> >
> > hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
> > hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
> >
> > right?
> >
> > Ingo
>
> I'd like to give someone from AMD or Intel or whoever already
> implemented such a logic a chance to comment on it. If this doesn't
> happen, you may add:

I didn't implement logic but checked the AMD 81xx documentation. And
this exactly describes that depending on HPET_TN_SETVAL either
accumulator or comparator is set. That is the reason why my last HPET
patch broke HPET on that chipset. I've provided a patch to partially
revert that commit. See

http://marc.info/?l=linux-kernel&m=124033700530097

The patch was successfully verified for bugzilla
http://bugzilla.kernel.org/show_bug.cgi?id=12961

IMHO it should be applied asap to tip tree.


Regards,

Andreas

--
Operating | Advanced Micro Devices GmbH
System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
Research | Geschäftsführer: Jochen Polster, Thomas M. McCoy, Giuliano Meroni
Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
(OSRC) | Registergericht München, HRB Nr. 43632

2009-04-22 10:47:04

by Ingo Molnar

Subject: Re: [BUG] IO-APIC + timer doesn't work!

* Andreas Herrmann <[email protected]> wrote:

> On Sat, Apr 18, 2009 at 10:46:32PM +0200, Jan Kiszka wrote:
> > Ingo Molnar wrote:
> > > * Jan Kiszka <[email protected]> wrote:
> > >
> > >> Ingo Molnar wrote:
> > >>> * Jeff Mahoney <[email protected]> wrote:
> > >>>
> > >>>>> Hmmmmm. That somehow reminds me of what I thought I had to fix in the
> > >>>>> HPET emulation of QEMU just recently [1] - because of 2.6.30-rc's behavior.
> > >>>>>
> > >>>>> Could you try if writing 'delta' a second time makes any difference on
> > >>>>> that box?
> > >>>>>
> > >>>>> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
> > >>>>> index 648b3a2..523d72b 100644
> > >>>>> --- a/arch/x86/kernel/hpet.c
> > >>>>> +++ b/arch/x86/kernel/hpet.c
> > >>>>> @@ -324,6 +324,7 @@ static void hpet_set_mode(enum clock_event_mode mode,
> > >>>>> HPET_TN_SETVAL | HPET_TN_32BIT;
> > >>>>> hpet_writel(cfg, HPET_Tn_CFG(timer));
> > >>>>> hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
> > >>>>> + hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
> > >>>>> hpet_start_counter();
> > >>>>> hpet_print_config();
> > >>>>> break;
> > >>>>>
> > >>>> Thanks, Jan.
> > >>>>
> > >>>> That fixed it for me.
> > >>> I've queued it up (and i've got a test-system that might be affected
> > >>> by a similar problem - it shows a similar crash very rarely), but it
> > >>> would be nice to know why this duplicate writeout makes a
> > >>> difference. Jan?
> > >>>
> > >>> Ingo
> > >> Well, if you look at the HPET spec [1], you first find the explanation
> > >> of the Tn_VAL_SET_CNF bit (HPET_TN_SETVAL):
> > >>
> > >> "[...] By writing this bit to a 1, the software is then allowed to
> > >> directly set a periodic timer's accumulator."
> > >>
> > >> That may sound like "you write to the comparator register if 0, and if
> > >> 1, you set the accumulator". That's also how HPET was emulated in QEMU
> > >> so far.
> > >>
> > >> But then you read on about changing the period of a running timer:
> > >>
> > >> "If the software resets the main counter, the value in the comparator’s
> > >> value register needs to reset as well. This can be done by setting the
> > >> Tn_VAL_SET_CNF bit. Again, to avoid race conditions, this should be
> > >> done with the main counter halted. The following usage model is expected:
> > >> 1) Software clears the GLOBAL_ENABLE_CNF bit to prevent any interrupts
> > >> 2) Software Clears the main counter by writing a value of 00000000h to it.
> > >> 3) Software sets the TIMER0_VAL_SET_CNF bit.
> > >> 4) Software writes the new value in the TIMER0_COMPARATOR_VAL register
> > >> 5) Software sets the GLOBAL_ENABLE_CNF bit to enable interrupts."
> > >>
> > >> And that somehow sounds like you only need to write the new period once,
> > >> with Tn_VAL_SET_CNF = 1.
> > >>
> > >> I bet now that both interpretations are implemented in silicon somewhere
> > >> out there - but I'm all ears to learn the right one (and potentially
> > >> re-fix QEMU).
> > >>
> > >> Jan
> > >>
> > >> [1] http://www.intel.com/hardwaredesign/hpetspec_1.pdf
> > >
> > > i might be a bit slow today, but how does the above transform into:
> > >
> > > hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
> > > hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
> > >
> > > ? It sets the same register twice.
> >
> > No, sorry, I missed to cite also this from the Tn_SET_VAL_CFG
> > explanation: "Software does NOT have to write this bit back to 0 (it
> > automatically clears)." So the second write will already take place
> > without it.
> >
> > >
> > > I'm totally happy if it does transform into that under some quirky
> > > interpretation. Since it solved the problem for Jeff, we'll likely
> > > add it even if there's no actual explanation ;-) But it would be
> > > nice to somehow come up with a line of reasoning that ends with:
> > >
> > > ... and for that reason, we set the value twice:
> > >
> > > hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
> > > hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
> > >
> > > right?
> > >
> > > Ingo
> >
> > I'd like to give someone from AMD or Intel or whoever already
> > implemented such a logic a chance to comment on it. If this doesn't
> > happen, you may add:
>
> I didn't implement logic but checked the AMD 81xx documentation. And
> this exactly describes that depending on HPET_TN_SETVAL either
> accumulator or comparator is set. That is the reason why my last HPET
> patch broke HPET on that chipset. I've provided a patch to partially
> revert that commit. See
>
> http://marc.info/?l=linux-kernel&m=124033700530097
>
> The patch was successfully verified for bugzilla
> http://bugzilla.kernel.org/show_bug.cgi?id=12961
>
> IMHO it should be applied asap to tip tree.

Applied to tip:x86/urgent, thanks Andreas!

I've also removed the trial baloon patch below - your patch is a
full replacement for it, correct?

Ingo

------------------->
>From ff3bb72cc6af05828504b964ff1d1bd193524b63 Mon Sep 17 00:00:00 2001
From: Jan Kiszka <[email protected]>
Date: Sat, 18 Apr 2009 10:33:14 +0200
Subject: [PATCH] x86, hpet: fix "IO-APIC + timer doesn't work!"

Jeff Mahoney wrote:

> I saw this while booting 2.6.30-rc1, -rc2, and today's git, on one of
> my development nodes. This output is with apic=debug. With noapic,
> it still hung. Both outputs follow.
>
> git bisect leads to commit 8d6f0c8214928f7c5083dd54ecb69c5d615b516e,
> but I'm not seeing anything obvious there. Backing just that change
> out doesn't fix it.
>
> enabled ExtINT on CPU#0
> ESR value before enabling vector: 0x00000004 after: 0x00000000
> ENABLING IO-APIC IRQs
> ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
> ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> ...trying to set up timer (IRQ0) through the 8259A ...
> ..... (found apic 0 pin 0) ...
> ....... failed.
> ...trying to set up timer as Virtual Wire IRQ...
> ..... failed.
> ...trying to set up timer as ExtINT IRQ...
> ..... failed :(.
> Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the 'noapic' option.

Hmmmmm. That somehow reminds me of what I thought I had to fix in the
HPET emulation of QEMU just recently [1] - because of 2.6.30-rc's behavior.

Lets try a quirk: write 'delta' a second time.

[1] http://permalink.gmane.org/gmane.comp.emulators.qemu/41570

[ Impact: fix rare boot panic ]

Tested-by: Jeff Mahoney <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/kernel/hpet.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 648b3a2..523d72b 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -324,6 +324,7 @@ static void hpet_set_mode(enum clock_event_mode mode,
HPET_TN_SETVAL | HPET_TN_32BIT;
hpet_writel(cfg, HPET_Tn_CFG(timer));
hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
+ hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
hpet_start_counter();
hpet_print_config();
break;

2009-04-22 11:22:32

by tip-bot for Andreas Herrmann

Subject: [tip:x86/urgent] x86: hpet: fix periodic mode programming on AMD 81xx

Commit-ID: 86d855f62fabe344a4f66f509def6594abef9a91
Gitweb: http://git.kernel.org/tip/86d855f62fabe344a4f66f509def6594abef9a91
Author: Andreas Herrmann <[email protected]>
AuthorDate: Tue, 21 Apr 2009 20:00:37 +0200
Committer: Ingo Molnar <[email protected]>
CommitDate: Wed, 22 Apr 2009 12:44:55 +0200

x86: hpet: fix periodic mode programming on AMD 81xx

(See http://bugzilla.kernel.org/show_bug.cgi?id=12961)

It partially reverts commit c23e253e67c9d8a91a0ffa33c1f571a17f0a2403
(x86: hpet: stop HPET_COUNTER when programming periodic mode)

HPET on AMD 81xx chipset needs a second write (with HPET_TN_SETVAL
cleared) to T0_CMP register to set the period in periodic mode.

With this patch HPET_COUNTER is still stopped but not reset when HPET
is programmed in periodic mode. This should help to avoid races when
HPET is programmed in periodic mode and fixes a boot time hang that
I've observed on a machine when using 1000HZ.

[ Impact: fix boot time hang on machines with AMD 81xx chipset ]

Signed-off-by: Andreas Herrmann <[email protected]>
Cc: Jeff Mahoney <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>


---
arch/x86/kernel/hpet.c | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 3f0019e..81408b9 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -236,6 +236,10 @@ static void hpet_stop_counter(void)
unsigned long cfg = hpet_readl(HPET_CFG);
cfg &= ~HPET_CFG_ENABLE;
hpet_writel(cfg, HPET_CFG);
+}
+
+static void hpet_reset_counter(void)
+{
hpet_writel(0, HPET_COUNTER);
hpet_writel(0, HPET_COUNTER + 4);
}
@@ -250,6 +254,7 @@ static void hpet_start_counter(void)
static void hpet_restart_counter(void)
{
hpet_stop_counter();
+ hpet_reset_counter();
hpet_start_counter();
}

@@ -309,7 +314,7 @@ static int hpet_setup_msi_irq(unsigned int irq);
static void hpet_set_mode(enum clock_event_mode mode,
struct clock_event_device *evt, int timer)
{
- unsigned long cfg;
+ unsigned long cfg, cmp, now;
uint64_t delta;

switch (mode) {
@@ -317,12 +322,23 @@ static void hpet_set_mode(enum clock_event_mode mode,
hpet_stop_counter();
delta = ((uint64_t)(NSEC_PER_SEC/HZ)) * evt->mult;
delta >>= evt->shift;
+ now = hpet_readl(HPET_COUNTER);
+ cmp = now + (unsigned long) delta;
cfg = hpet_readl(HPET_Tn_CFG(timer));
/* Make sure we use edge triggered interrupts */
cfg &= ~HPET_TN_LEVEL;
cfg |= HPET_TN_ENABLE | HPET_TN_PERIODIC |
HPET_TN_SETVAL | HPET_TN_32BIT;
hpet_writel(cfg, HPET_Tn_CFG(timer));
+ hpet_writel(cmp, HPET_Tn_CMP(timer));
+ udelay(1);
+ /*
+ * HPET on AMD 81xx needs a second write (with HPET_TN_SETVAL
+ * cleared) to T0_CMP to set the period. The HPET_TN_SETVAL
+ * bit is automatically cleared after the first write.
+ * (See AMD-8111 HyperTransport I/O Hub Data Sheet,
+ * Publication # 24674)
+ */
hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
hpet_start_counter();
hpet_print_config();

2009-04-22 13:42:20

by Jeff Mahoney

Subject: Re: [BUG] IO-APIC + timer doesn't work!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas Herrmann wrote:
> On Sat, Apr 18, 2009 at 10:46:32PM +0200, Jan Kiszka wrote:
>> Ingo Molnar wrote:
>>> * Jan Kiszka <[email protected]> wrote:
>>>
>>>> Ingo Molnar wrote:
>>>>> * Jeff Mahoney <[email protected]> wrote:
>>>>>
>>>>>>> Hmmmmm. That somehow reminds me of what I thought I had to fix in the
>>>>>>> HPET emulation of QEMU just recently [1] - because of 2.6.30-rc's behavior.
>>>>>>>
>>>>>>> Could you try if writing 'delta' a second time makes any difference on
>>>>>>> that box?
>>>>>>>
>>>>>>> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
>>>>>>> index 648b3a2..523d72b 100644
>>>>>>> --- a/arch/x86/kernel/hpet.c
>>>>>>> +++ b/arch/x86/kernel/hpet.c
>>>>>>> @@ -324,6 +324,7 @@ static void hpet_set_mode(enum clock_event_mode mode,
>>>>>>> HPET_TN_SETVAL | HPET_TN_32BIT;
>>>>>>> hpet_writel(cfg, HPET_Tn_CFG(timer));
>>>>>>> hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
>>>>>>> + hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
>>>>>>> hpet_start_counter();
>>>>>>> hpet_print_config();
>>>>>>> break;
>>>>>>>
>>>>>> Thanks, Jan.
>>>>>>
>>>>>> That fixed it for me.
>>>>> I've queued it up (and i've got a test-system that might be affected
>>>>> by a similar problem - it shows a similar crash very rarely), but it
>>>>> would be nice to know why this duplicate writeout makes a
>>>>> difference. Jan?
>>>>>
>>>>> Ingo
>>>> Well, if you look at the HPET spec [1], you first find the explanation
>>>> of the Tn_VAL_SET_CNF bit (HPET_TN_SETVAL):
>>>>
>>>> "[...] By writing this bit to a 1, the software is then allowed to
>>>> directly set a periodic timer's accumulator."
>>>>
>>>> That may sound like "you write to the comparator register if 0, and if
>>>> 1, you set the accumulator". That's also how HPET was emulated in QEMU
>>>> so far.
>>>>
>>>> But then you read on about changing the period of a running timer:
>>>>
>>>> "If the software resets the main counter, the value in the comparator’s
>>>> value register needs to reset as well. This can be done by setting the
>>>> Tn_VAL_SET_CNF bit. Again, to avoid race conditions, this should be
>>>> done with the main counter halted. The following usage model is expected:
>>>> 1) Software clears the GLOBAL_ENABLE_CNF bit to prevent any interrupts
>>>> 2) Software Clears the main counter by writing a value of 00000000h to it.
>>>> 3) Software sets the TIMER0_VAL_SET_CNF bit.
>>>> 4) Software writes the new value in the TIMER0_COMPARATOR_VAL register
>>>> 5) Software sets the GLOBAL_ENABLE_CNF bit to enable interrupts."
>>>>
>>>> And that somehow sounds like you only need to write the new period once,
>>>> with Tn_VAL_SET_CNF = 1.
>>>>
>>>> I bet now that both interpretations are implemented in silicon somewhere
>>>> out there - but I'm all ears to learn the right one (and potentially
>>>> re-fix QEMU).
>>>>
>>>> Jan
>>>>
>>>> [1] http://www.intel.com/hardwaredesign/hpetspec_1.pdf
>>> i might be a bit slow today, but how does the above transform into:
>>>
>>> hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
>>> hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
>>>
>>> ? It sets the same register twice.
>> No, sorry, I missed to cite also this from the Tn_SET_VAL_CFG
>> explanation: "Software does NOT have to write this bit back to 0 (it
>> automatically clears)." So the second write will already take place
>> without it.
>>
>>> I'm totally happy if it does transform into that under some quirky
>>> interpretation. Since it solved the problem for Jeff, we'll likely
>>> add it even if there's no actual explanation ;-) But it would be
>>> nice to somehow come up with a line of reasoning that ends with:
>>>
>>> ... and for that reason, we set the value twice:
>>>
>>> hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
>>> hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
>>>
>>> right?
>>>
>>> Ingo
>> I'd like to give someone from AMD or Intel or whoever already
>> implemented such a logic a chance to comment on it. If this doesn't
>> happen, you may add:
>
> I didn't implement logic but checked the AMD 81xx documentation. And
> this exactly describes that depending on HPET_TN_SETVAL either
> accumulator or comparator is set. That is the reason why my last HPET
> patch broke HPET on that chipset. I've provided a patch to partially
> revert that commit. See
>
> http://marc.info/?l=linux-kernel&m=124033700530097
>
> The patch was successfully verified for bugzilla
> http://bugzilla.kernel.org/show_bug.cgi?id=12961
>
> IMHO it should be applied asap to tip tree.

Just to chime in here, my system works with this patch as well.

- -Jeff

- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAknvHpkACgkQLPWxlyuTD7IrOACgjzfCJ2XkFNJCRFOpbEg/Vv5v
VtgAnAnXuZETej+f5z4WjGosm7RcGIcW
=5f/F
-----END PGP SIGNATURE-----

2009-04-22 14:02:28

by tip-bot for Andreas Herrmann

Subject: [tip:x86/urgent] x86: hpet: fix periodic mode programming on AMD 81xx

Commit-ID: 7a6f9cbb37120c745fc187083fb5c3de4dca4f97
Gitweb: http://git.kernel.org/tip/7a6f9cbb37120c745fc187083fb5c3de4dca4f97
Author: Andreas Herrmann <[email protected]>
AuthorDate: Tue, 21 Apr 2009 20:00:37 +0200
Committer: Ingo Molnar <[email protected]>
CommitDate: Wed, 22 Apr 2009 15:53:40 +0200

x86: hpet: fix periodic mode programming on AMD 81xx

(See http://bugzilla.kernel.org/show_bug.cgi?id=12961)

It partially reverts commit c23e253e67c9d8a91a0ffa33c1f571a17f0a2403
(x86: hpet: stop HPET_COUNTER when programming periodic mode)

HPET on AMD 81xx chipset needs a second write (with HPET_TN_SETVAL
cleared) to T0_CMP register to set the period in periodic mode.

With this patch HPET_COUNTER is still stopped but not reset when HPET
is programmed in periodic mode. This should help to avoid races when
HPET is programmed in periodic mode and fixes a boot time hang that
I've observed on a machine when using 1000HZ.

[ Impact: fix boot time hang on machines with AMD 81xx chipset ]

Reported-by: Jeff Mahoney <[email protected]>
Signed-off-by: Andreas Herrmann <[email protected]>
Tested-by: Jeff Mahoney <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>


---
arch/x86/kernel/hpet.c | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 3f0019e..81408b9 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -236,6 +236,10 @@ static void hpet_stop_counter(void)
unsigned long cfg = hpet_readl(HPET_CFG);
cfg &= ~HPET_CFG_ENABLE;
hpet_writel(cfg, HPET_CFG);
+}
+
+static void hpet_reset_counter(void)
+{
hpet_writel(0, HPET_COUNTER);
hpet_writel(0, HPET_COUNTER + 4);
}
@@ -250,6 +254,7 @@ static void hpet_start_counter(void)
static void hpet_restart_counter(void)
{
hpet_stop_counter();
+ hpet_reset_counter();
hpet_start_counter();
}

@@ -309,7 +314,7 @@ static int hpet_setup_msi_irq(unsigned int irq);
static void hpet_set_mode(enum clock_event_mode mode,
struct clock_event_device *evt, int timer)
{
- unsigned long cfg;
+ unsigned long cfg, cmp, now;
uint64_t delta;

switch (mode) {
@@ -317,12 +322,23 @@ static void hpet_set_mode(enum clock_event_mode mode,
hpet_stop_counter();
delta = ((uint64_t)(NSEC_PER_SEC/HZ)) * evt->mult;
delta >>= evt->shift;
+ now = hpet_readl(HPET_COUNTER);
+ cmp = now + (unsigned long) delta;
cfg = hpet_readl(HPET_Tn_CFG(timer));
/* Make sure we use edge triggered interrupts */
cfg &= ~HPET_TN_LEVEL;
cfg |= HPET_TN_ENABLE | HPET_TN_PERIODIC |
HPET_TN_SETVAL | HPET_TN_32BIT;
hpet_writel(cfg, HPET_Tn_CFG(timer));
+ hpet_writel(cmp, HPET_Tn_CMP(timer));
+ udelay(1);
+ /*
+ * HPET on AMD 81xx needs a second write (with HPET_TN_SETVAL
+ * cleared) to T0_CMP to set the period. The HPET_TN_SETVAL
+ * bit is automatically cleared after the first write.
+ * (See AMD-8111 HyperTransport I/O Hub Data Sheet,
+ * Publication # 24674)
+ */
hpet_writel((unsigned long) delta, HPET_Tn_CMP(timer));
hpet_start_counter();
hpet_print_config();

2009-04-22 17:14:29

by tip-bot for Andreas Herrmann

Subject: Re: [BUG] IO-APIC + timer doesn't work!

On Wed, Apr 22, 2009 at 12:46:29PM +0200, Ingo Molnar wrote:

... snip ...

> Applied to tip:x86/urgent, thanks Andreas!
>
> I've also removed the trial baloon patch below - your patch is a
> full replacement for it, correct?

Yes.

Thanks,
Andreas