08 Jan, 2012
1 commit
-
* 'driver-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (73 commits)
arm: fix up some samsung merge sysdev conversion problems
firmware: Fix an oops on reading fw_priv->fw in sysfs loading file
Drivers:hv: Fix a bug in vmbus_driver_unregister()
driver core: remove __must_check from device_create_file
debugfs: add missing #ifdef HAS_IOMEM
arm: time.h: remove device.h #include
driver-core: remove sysdev.h usage.
clockevents: remove sysdev.h
arm: convert sysdev_class to a regular subsystem
arm: leds: convert sysdev_class to a regular subsystem
kobject: remove kset_find_obj_hinted()
m86k: gpio - convert sysdev_class to a regular subsystem
mips: txx9_sram - convert sysdev_class to a regular subsystem
mips: 7segled - convert sysdev_class to a regular subsystem
sh: dma - convert sysdev_class to a regular subsystem
sh: intc - convert sysdev_class to a regular subsystem
power: suspend - convert sysdev_class to a regular subsystem
power: qe_ic - convert sysdev_class to a regular subsystem
power: cmm - convert sysdev_class to a regular subsystem
s390: time - convert sysdev_class to a regular subsystem
...Fix up conflicts with 'struct sysdev' removal from various platform
drivers that got changed:
- arch/arm/mach-exynos/cpu.c
- arch/arm/mach-exynos/irq-eint.c
- arch/arm/mach-s3c64xx/common.c
- arch/arm/mach-s3c64xx/cpu.c
- arch/arm/mach-s5p64x0/cpu.c
- arch/arm/mach-s5pv210/common.c
- arch/arm/plat-samsung/include/plat/cpu.h
- arch/powerpc/kernel/sysfs.c
and fix up cpu_is_hotpluggable() as per Greg in include/linux/cpu.h
07 Jan, 2012
2 commits
-
* 'x86-cleanups-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86: Use "do { } while(0)" for empty lock_cmos()/unlock_cmos() macros
x86: Use "do { } while(0)" for empty flush_tlb_fix_spurious_fault() macro
x86, CPU: Drop superfluous get_cpu_cap() prototype
arch/x86/mm/pageattr.c: Quiet sparse noise; local functions should be static
arch/x86/kernel/ptrace.c: Quiet sparse noise
x86: Use kmemdup() in copy_thread(), rather than duplicating its implementation
x86: Replace the EVT_TO_HPET_DEV() macro with an inline function -
This resolves the conflict in the arch/arm/mach-s3c64xx/s3c6400.c file,
and it fixes the build error in the arch/x86/kernel/microcode_core.c
file, that the merge did not catch.The microcode_core.c patch was provided by Stephen Rothwell
who was invaluable in the merge issues involved
with the large sysdev removal process in the driver-core tree.Signed-off-by: Greg Kroah-Hartman
22 Dec, 2011
1 commit
-
The sysdev.h file should not be needed by any in-kernel code, so remove
the .h file from these random files that seem to still want to include
it.The sysdev code will be going away soon, so this include needs to be
removed no matter what.Cc: Jiandong Zheng
Cc: Scott Branden
Cc: Russell King
Cc: Kukjin Kim
Cc: David Brown
Cc: Daniel Walker
Cc: Bryan Huntsman
Cc: Ben Dooks
Cc: Wan ZongShun
Cc: Haavard Skinnemoen
Cc: Hans-Christian Egtvedt
Cc: Guan Xuetao
Cc: "Venkatesh Pallipadi
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Grant Likely
Cc: Richard Purdie
Cc: Matthew Garrett
Signed-off-by: Kay Sievers
09 Dec, 2011
1 commit
-
When HPET is operating in RTC mode, the TN_ENABLE bit on timer1
controls whether the HPET or the RTC delivers interrupts to irq8. When
the system goes into suspend, the RTC driver sends a signal to the
HPET driver so that the HPET releases control of irq8, allowing the
RTC to wake the system from suspend. The switchover is accomplished by
a write to the HPET configuration registers which currently only
occurs while servicing the HPET interrupt.On some systems, I have seen the system suspend before an HPET
interrupt occurs, preventing the write to the HPET configuration
register and leaving the HPET in control of the irq8. As the HPET is
not active during suspend, it does not generate a wake signal and RTC
alarms do not work.This patch forces the HPET driver to immediately transfer control of
the irq8 channel to the RTC instead of waiting until the next
interrupt event.Signed-off-by: Mark Langsdorf
Link: http://lkml.kernel.org/r/20111118153306.GB16319@alberich.amd.com
Tested-by: Andreas Herrmann
Signed-off-by: Andreas Herrmann
Signed-off-by: Thomas Gleixner
Cc: stable@vger.kernel.org
05 Dec, 2011
1 commit
-
The original macro worked only when applied to variables named
'evt'. While this could have been fixed by simply renaming the
macro argument, a more type-safe replacement is preferred.Signed-off-by: Ferenc Wagner
Cc: Venkatesh Pallipadi \(Venki\)
Link: http://lkml.kernel.org/r/8ed5c66c02041226e8cf8b4d5d6b41e543d90bd6.1321626272.git.wferi@niif.hu
Signed-off-by: Ingo Molnar
01 Nov, 2011
1 commit
-
These files were implicitly getting EXPORT_SYMBOL via device.h
which was including module.h, but that will be fixed up shortly.By fixing these now, we can avoid seeing things like:
arch/x86/kernel/rtc.c:29: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL’
arch/x86/kernel/pci-dma.c:20: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL’
arch/x86/kernel/e820.c:69: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL_GPL’[ with input from Randy Dunlap and also
from Stephen Rothwell ]Signed-off-by: Paul Gortmaker
23 Jul, 2011
1 commit
-
* 'x86-vdso-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86-64, vdso: Do not allocate memory for the vDSO
clocksource: Change __ARCH_HAS_CLOCKSOURCE_DATA to a CONFIG option
x86, vdso: Drop now wrong comment
Document the vDSO and add a reference parser
ia64: Replace clocksource.fsys_mmio with generic arch data
x86-64: Move vread_tsc and vread_hpet into the vDSO
clocksource: Replace vread with generic arch data
x86-64: Add --no-undefined to vDSO build
x86-64: Allow alternative patching in the vDSO
x86: Make alternative instruction pointers relative
x86-64: Improve vsyscall emulation CS and RIP handling
x86-64: Emulate legacy vsyscalls
x86-64: Fill unused parts of the vsyscall page with 0xcc
x86-64: Remove vsyscall number 3 (venosys)
x86-64: Map the HPET NX
x86-64: Remove kernel.vsyscall64 sysctl
x86-64: Give vvars their own page
x86-64: Document some of entry_64.S
x86-64: Fix alignment of jiffies variable
15 Jul, 2011
1 commit
-
The vsyscall page now consists entirely of trap instructions.
Cc: John Stultz
Signed-off-by: Andy Lutomirski
Link: http://lkml.kernel.org/r/637648f303f2ef93af93bae25186e9a1bea093f5.1310639973.git.luto@mit.edu
Signed-off-by: H. Peter Anvin
14 Jul, 2011
1 commit
-
The vread field was bloating struct clocksource everywhere except
x86_64, and I want to change the way this works on x86_64, so let's
split it out into per-arch data.Cc: x86@kernel.org
Cc: Clemens Ladisch
Cc: linux-ia64@vger.kernel.org
Cc: Tony Luck
Cc: Fenghua Yu
Cc: John Stultz
Cc: Thomas Gleixner
Signed-off-by: Andy Lutomirski
Link: http://lkml.kernel.org/r/3ae5ec76a168eaaae63f08a2a1060b91aa0b7759.1310563276.git.luto@mit.edu
Signed-off-by: H. Peter Anvin
09 Jun, 2011
2 commits
-
There are multiple declarations of global_clock_event in header files
specific to particular clock event implementations. Consolidate them
in and make sure all users include that header.Signed-off-by: Ralf Baechle
Cc: Venkatesh Pallipadi (Venki)
Link: http://lkml.kernel.org/r/20110601180610.762763451@duck.linux-mips.net
Signed-off-by: Thomas Gleixner -
Signed-off-by: Ralf Baechle
Cc: linux-mips@linux-mips.org
Link: http://lkml.kernel.org/r/20110601180610.054254048@duck.linux-mips.net
Signed-off-by: Thomas Gleixnerarch/arm/mach-footbridge/isa-timer.c | 2 +-
arch/mips/cobalt/time.c | 2 +-
arch/mips/jazz/irq.c | 2 +-
arch/mips/kernel/i8253.c | 2 +-
arch/mips/mti-malta/malta-time.c | 2 +-
arch/mips/sgi-ip22/ip22-time.c | 2 +-
arch/mips/sni/time.c | 2 +-
arch/x86/kernel/apic/apic.c | 2 +-
arch/x86/kernel/apm_32.c | 2 +-
arch/x86/kernel/hpet.c | 2 +-
arch/x86/kernel/i8253.c | 2 +-
arch/x86/kernel/time.c | 2 +-
drivers/block/hd.c | 2 +-
drivers/clocksource/i8253.c | 2 +-
drivers/input/gameport/gameport.c | 2 +-
drivers/input/joystick/analog.c | 2 +-
drivers/input/misc/pcspkr.c | 2 +-
include/linux/i8253.h | 11 +++++++++++
sound/drivers/pcsp/pcsp.h | 2 +-
19 files changed, 29 insertions(+), 18 deletions(-)
06 Jun, 2011
1 commit
-
Currently the HPET mapping is a user-accessible syscall
instruction at a fixed address some of the time.A sufficiently determined hacker might be able to guess when.
Signed-off-by: Andy Lutomirski
Cc: Jesper Juhl
Cc: Borislav Petkov
Cc: Linus Torvalds
Cc: Arjan van de Ven
Cc: Jan Beulich
Cc: richard -rw- weinberger
Cc: Mikael Pettersson
Cc: Andi Kleen
Cc: Brian Gerst
Cc: Louis Rilling
Cc: Valdis.Kletnieks@vt.edu
Cc: pageexec@freemail.hu
Link: http://lkml.kernel.org/r/ab41b525a4ca346b1ca1145d16fb8d181861a8aa.1307292171.git.luto@mit.edu
Signed-off-by: Ingo Molnar
19 May, 2011
1 commit
-
No need to recalculate the frequency and the conversion factors over
and over. Calculate the frequency once and use the new config/register
interface and let the core code do the math.Signed-off-by: Thomas Gleixner
Cc: John Stultz
Reviewed-by: Ingo Molnar
Link: http://lkml.kernel.org/r/%3C20110518210136.646482357%40linutronix.de%3E
12 Mar, 2011
1 commit
-
genirq is switching to a consistent name space for the irq related
functions. Convert x86. Conversion was done with coccinelle.Signed-off-by: Thomas Gleixner
13 Dec, 2010
1 commit
-
commit 995bd3bb5 (x86: Hpet: Avoid the comparator readback penalty)
chose 8 HPET cycles as a safe value for the ETIME check, as we had the
confirmation that the posted write to the comparator register is
delayed by two HPET clock cycles on Intel chipsets which showed
readback problems.After that patch hit mainline we got reports from machines with newer
AMD chipsets which seem to have an even longer delay. See
http://thread.gmane.org/gmane.linux.kernel/1054283 and
http://thread.gmane.org/gmane.linux.kernel/1069458 for further
information.Boris tried to come up with an ACPI based selection of the minimum
HPET cycles, but this failed on a couple of test machines. And of
course we did not get any useful information from the hardware folks.For now our only option is to chose a paranoid high and safe value for
the minimum HPET cycles used by the ETIME check. Adjust the minimum ns
value for the HPET clockevent accordingly.Reported-Bistected-and-Tested-by: Markus Trippelsdorf
Signed-off-by: Thomas Gleixner
LKML-Reference:
Cc: Simon Kirby
Cc: Borislav Petkov
Cc: Andreas Herrmann
Cc: John Stultz
27 Oct, 2010
1 commit
-
Silly though it is, completions and wait_queue_heads use foo_ONSTACK
(COMPLETION_INITIALIZER_ONSTACK, DECLARE_COMPLETION_ONSTACK,
__WAIT_QUEUE_HEAD_INIT_ONSTACK and DECLARE_WAIT_QUEUE_HEAD_ONSTACK) so I
guess workqueues should do the same thing.s/INIT_WORK_ON_STACK/INIT_WORK_ONSTACK/
s/INIT_DELAYED_WORK_ON_STACK/INIT_DELAYED_WORK_ONSTACK/Cc: Peter Zijlstra
Acked-by: Tejun Heo
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
22 Oct, 2010
1 commit
-
…/git/tip/linux-2.6-tip
* 'x86-timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86: Hpet: Avoid the comparator readback penalty
12 Oct, 2010
1 commit
-
Signed-off-by: Thomas Gleixner
Reviewed-by: Ingo Molnar
01 Oct, 2010
1 commit
-
create_irq() returns -1 if the interrupt allocation failed, but the
code checks for irq == 0.Use create_irq_nr() instead.
Signed-off-by: Thomas Gleixner
Cc: Venkatesh Pallipadi
LKML-Reference:
Cc: stable@kernel.org
Signed-off-by: H. Peter Anvin
18 Sep, 2010
1 commit
-
Due to the overly intelligent design of HPETs, we need to workaround
the problem that the compare value which we write is already behind
the actual counter value at the point where the value hits the real
compare register. This happens for two reasons:1) We read out the counter, add the delta and write the result to the
compare register. When a NMI or SMI hits between the read out and
the write then the counter can be ahead of the event already2) The write to the compare register is delayed by up to two HPET
cycles in certain chipsets.We worked around this by reading back the compare register to make
sure that the written value has hit the hardware. For certain ICH9+
chipsets this can require two readouts, as the first one can return
the previous compare register value. That's bad performance wise for
the normal case where the event is far enough in the future.As we already know that the write can be delayed by up to two cycles
we can avoid the read back of the compare register completely if we
make the decision whether the delta has elapsed already or not based
on the following calculation:cmp = event - actual_count;
If cmp is less than 8 HPET clock cycles, then we decide that the event
has happened already and return -ETIME. That covers the above #1 and
#2 problems which would cause a wait for HPET wraparound (~306
seconds).Signed-off-by: Thomas Gleixner
Tested-by: Nix
Tested-by: Artur Skawina
Cc: Damien Wyart
Tested-by: John Drescher
Cc: Venkatesh Pallipadi
Cc: Arjan van de Ven
Cc: Andreas Herrmann
Tested-by: Borislav Petkov
Cc: Suresh Siddha
LKML-Reference:
15 Sep, 2010
1 commit
-
This more or less reverts commits 08be979 (x86: Force HPET
readback_cmp for all ATI chipsets) and 30a564be (x86, hpet: Restrict
read back to affected ATI chipsets) to the status of commit 8da854c
(x86, hpet: Erratum workaround for read after write of HPET
comparator).The delta to commit 8da854c is mostly comments and the change from
WARN_ONCE to printk_once as we know the call path of this function
already.This needs really in depth explanation:
First of all the HPET design is a complete failure. Having a counter
compare register which generates an interrupt on matching values
forces the software to do at least one superfluous readback of the
counter register.While it is nice in theory to program "absolute" time events it is
practically useless because the timer runs at some absurd frequency
which can never be matched to real world units. So we are forced to
calculate a relative delta and this forces a readout of the actual
counter value, adding the delta and programming the compare
register. When the delta is small enough we run into the danger that
we program a compare value which is already in the past. Due to the
compare for equal nature of HPET we need to read back the counter
value after writing the compare rehgister (btw. this is necessary for
absolute timeouts as well) to make sure that we did not miss the timer
event. We try to work around that by setting the minimum delta to a
value which is larger than the theoretical time which elapses between
the counter readout and the compare register write, but that's only
true in theory. A NMI or SMI which hits between the readout and the
write can easily push us beyond that limit. This would result in
waiting for the next HPET timer interrupt until the 32bit wraparound
of the counter happens which takes about 306 seconds.So we designed the next event function to look like:
match = read_cnt() + delta;
write_compare_ref(match);
return read_cnt() < match ? 0 : -ETIME;At some point we got into trouble with certain ATI chipsets. Even the
above "safe" procedure failed. The reason was that the write to the
compare register was delayed probably for performance reasons. The
theory was that they wanted to avoid the synchronization of the write
with the HPET clock, which is understandable. So the write does not
hit the compare register directly instead it goes to some intermediate
register which is copied to the real compare register in sync with the
HPET clock. That opens another window for hitting the dreaded "wait
for a wraparound" problem.To work around that "optimization" we added a read back of the compare
register which either enforced the update of the just written value or
just delayed the readout of the counter enough to avoid the issue. We
unfortunately never got any affirmative info from ATI/AMD about this.One thing is sure, that we nuked the performance "optimization" that
way completely and I'm pretty sure that the result is worse than
before some HW folks came up with those.Just for paranoia reasons I added a check whether the read back
compare register value was the same as the value we wrote right
before. That paranoia check triggered a couple of years after it was
added on an Intel ICH9 chipset. Venki added a workaround (commit
8da854c) which was reading the compare register twice when the first
check failed. We considered this to be a penalty in general and
restricted the readback (thus the wasted CPU cycles) to the known to
be affected ATI chipsets.This turned out to be a utterly wrong decision. 2.6.35 testers
experienced massive problems and finally one of them bisected it down
to commit 30a564be which spured some further investigation.Finally we got confirmation that the write to the compare register can
be delayed by up to two HPET clock cycles which explains the problems
nicely. All we can do about this is to go back to Venki's initial
workaround in a slightly modified version.Just for the record I need to say, that all of this could have been
avoided if hardware designers and of course the HPET committee would
have thought about the consequences for a split second. It's out of my
comprehension why designing a working timer is so hard. There are two
ways to achieve it:1) Use a counter wrap around aware compare_reg
Reported-by: Artur Skawina
Reported-by: Damien Wyart
Reported-by: John Drescher
Cc: Venkatesh Pallipadi
Cc: Ingo Molnar
Cc: H. Peter Anvin
Cc: Arjan van de Ven
Cc: Andreas Herrmann
Cc: Borislav Petkov
Cc: stable@kernel.org
Acked-by: Suresh Siddha
Signed-off-by: Thomas Gleixner
13 Aug, 2010
1 commit
-
The current computation, introduced with f12a15be63, of FSEC_PER_SEC using
the multiplication of (FSEC_PER_NSEC * NSEC_PER_SEC) is performed only
with 32bit integers on small machines, resulting in an overflow and a
*very* short intervals being programmed. An interrupt storm follows.Note that we also have to specify FSEC_PER_SEC as being long long to
overcome the same limitations.Signed-off-by: Chris Wilson
Signed-off-by: John Stultz
Cc: Thomas Gleixner
Acked-by: Ingo Molnar
Acked-by: H. Peter Anvin
Signed-off-by: Linus Torvalds
27 Jul, 2010
1 commit
-
This converts the most common of the x86 clocksources over to use
clocksource_register_hz/khz.Signed-off-by: John Stultz
LKML-Reference:
Signed-off-by: Thomas Gleixner
23 Jul, 2010
1 commit
-
hpet_disable is called unconditionally on machine reboot if hpet support
is compiled in the kernel.
hpet_disable only checks if the machine is hpet capable but doesn't make
sure that hpet has been initialized.[ tglx: Made it a one liner and removed the redundant hpet_address check ]
Signed-off-by: Stefano Stabellini
Acked-by: Venkatesh Pallipadi
LKML-Reference:
Cc: stable@kernel.org
Signed-off-by: Thomas Gleixner
29 Apr, 2010
1 commit
-
After programming the HPET, we do a readback as a workaround for
ATI/SBx00 chipsets as a synchronization. Unfortunately this triggers
an erratum in newer ICH chipsets (ICH9+) where reading the comparator
immediately after the write returns the old value. Furthermore, as
always, I/O reads are bad for performance.Therefore, restrict the readback to the chipsets that need it, or, for
debugging purposes, when we are running with hpet=verbose.Signed-off-by: Thomas Gleixner
Acked-by: Venkatesh Pallipadi
LKML-Reference:
Signed-off-by: H. Peter Anvin
08 Apr, 2010
1 commit
-
…git/x86/linux-2.6-tip
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip:
x86: Fix double enable_IR_x2apic() call on SMP kernel on !SMP boards
x86: Increase CONFIG_NODES_SHIFT max to 10
ibft, x86: Change reserve_ibft_region() to find_ibft_region()
x86, hpet: Fix bug in RTC emulation
x86, hpet: Erratum workaround for read after write of HPET comparator
bootmem, x86: Fix 32bit numa system without RAM on node 0
nobootmem, x86: Fix 32bit numa system without RAM on node 0
x86: Handle overlapping mptables
x86: Make e820_remove_range to handle all covered case
x86-32, resume: do a global tlb flush in S4 resume
02 Apr, 2010
2 commits
-
We think there exists a bug in the HPET code that emulates the RTC.
In the normal case, when the RTC frequency is set, the rtc driver tells
the hpet code about it here:int hpet_set_periodic_freq(unsigned long freq)
{
uint64_t clc;if (!is_hpet_enabled())
return 0;if (freq >= hpet_clockevent.shift;
hpet_pie_delta = (unsigned long) clc;
}
return 1;
}If freq is set to 64Hz (DEFAULT_RTC_INT_FREQ) or lower, then
hpet_pie_limit (a static) is set to non-zero. Then, on every one-shot
HPET interrupt, hpet_rtc_timer_reinit is called to compute the next
timeout. Well, that function has this logic:if (!(hpet_rtc_flags & RTC_PIE) || hpet_pie_limit)
delta = hpet_default_delta;
else
delta = hpet_pie_delta;Since hpet_pie_limit is not 0, hpet_default_delta is used. That
corresponds to 64Hz.Now, if you set a different rtc frequency, you'll take the else path
through hpet_set_periodic_freq, but unfortunately no one resets
hpet_pie_limit back to 0.Boom....now you are stuck with 64Hz RTC interrupts forever.
The patch below just resets the hpet_pie_limit value when requested freq
is greater than DEFAULT_RTC_INT_FREQ, which we think fixes this problem.Signed-off-by: Alok N Kataria
LKML-Reference:
Signed-off-by: Daniel Hecht
Cc: Venkatesh Pallipadi
Cc: Thomas Gleixner
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: H. Peter Anvin -
On Wed, Feb 24, 2010 at 03:37:04PM -0800, Justin Piszcz wrote:
> Hello,
>
> Again, on the Intel DP55KG board:
>
> # uname -a
> Linux host 2.6.33 #1 SMP Wed Feb 24 18:31:00 EST 2010 x86_64 GNU/Linux
>
> [ 1.237600] ------------[ cut here ]------------
> [ 1.237890] WARNING: at arch/x86/kernel/hpet.c:404 hpet_next_event+0x70/0x80()
> [ 1.238221] Hardware name:
> [ 1.238504] hpet: compare register read back failed.
> [ 1.238793] Modules linked in:
> [ 1.239315] Pid: 0, comm: swapper Not tainted 2.6.33 #1
> [ 1.239605] Call Trace:
> [ 1.239886] [] ? warn_slowpath_common+0x73/0xb0
> [ 1.240409] [] ? tick_dev_program_event+0x38/0xc0
> [ 1.240699] [] ? warn_slowpath_fmt+0x40/0x50
> [ 1.240992] [] ? tick_dev_program_event+0x38/0xc0
> [ 1.241281] [] ? hpet_next_event+0x70/0x80
> [ 1.241573] [] ? tick_dev_program_event+0x38/0xc0
> [ 1.241859] [] ? tick_handle_oneshot_broadcast+0xe2/0x100
> [ 1.246533] [] ? timer_interrupt+0x1a/0x30
> [ 1.246826] [] ? handle_IRQ_event+0x39/0xd0
> [ 1.247118] [] ? handle_edge_irq+0xb8/0x160
> [ 1.247407] [] ? handle_irq+0x15/0x20
> [ 1.247689] [] ? do_IRQ+0x62/0xe0
> [ 1.247976] [] ? ret_from_intr+0x0/0xa
> [ 1.248262] [] ? mwait_idle+0x57/0x80
> [ 1.248796] [] ? cpu_idle+0x5c/0xb0
> [ 1.249080] ---[ end trace db7f668fb6fef4e1 ]---
>
> Is this something Intel has to fix or is it a bug in the kernel?This is a chipset erratum.
Thomas: You mentioned we can retain this check only for known-buggy and
hpet debug kind of options. But here is the simple workaround patch for
this particular erratum.Some chipsets have a erratum due to which read immediately following a
write of HPET comparator returns old comparator value instead of most
recently written value.Erratum 15 in
"Intel I/O Controller Hub 9 (ICH9) Family Specification Update"
(http://www.intel.com/assets/pdf/specupdate/316973.pdf)Workaround for the errata is to read the comparator twice if the first
one fails.Signed-off-by: Venkatesh Pallipadi
LKML-Reference:
Signed-off-by: H. Peter Anvin
Cc: Venkatesh Pallipadi
Cc:
30 Mar, 2010
1 commit
-
…it slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
05 Feb, 2010
1 commit
-
Pass the clocksource as an argument to the clocksource resume callback.
Needed so we can point out which CMT channel the sh_cmt.c driver shall
resume.Signed-off-by: Magnus Damm
Cc: john stultz
Cc: Paul Mundt
Signed-off-by: Andrew Morton
Signed-off-by: Thomas Gleixner
23 Jan, 2010
1 commit
-
HPET MSI on platforms with ATI SB700/SB800 as they seem to have some
side-effects on floppy DMA. Do not use HPET MSI on such platforms.Original problem report from Mark Hounschell
http://lkml.indiana.edu/hypermail/linux/kernel/0912.2/01118.html[ This patch needs to go to stable as well. But, there are some
conflicts that prevents the patch from going as is. I can
rebase/resubmit to stable once the patch goes upstream.
hpa: still Cc:'ing stable@ as an FYI. ]Tested-by: Mark Hounschell
Signed-off-by: Venkatesh Pallipadi
Cc:
LKML-Reference:
Signed-off-by: H. Peter Anvin
28 Nov, 2009
1 commit
-
Andrew complained rightly that the WARN_ON in hpet_next_event() is
confusing and the code comment not really helpful.Change it to WARN_ONCE and print the reason in clear text. Change the
comment to explain what kind of hardware wreckage we deal with.Pointed-out-by: Andrew Morton
Signed-off-by: Thomas Gleixner
Cc: Venki Pallipadi
28 Aug, 2009
1 commit
-
x86 arch support for remapping HPET MSI's by associating the HPET timer block
with the interrupt-remapping HW unit and setting up appropriate irq_chipSigned-off-by: Suresh Siddha
Cc: Venkatesh Pallipadi
Cc: David Woodhouse
Cc: Jesse Barnes
Cc: Jay Fenlason
LKML-Reference:
Signed-off-by: Thomas Gleixner
22 Aug, 2009
1 commit
-
On 64-bits, using unsigned long when unsigned int suffices
needlessly creates larger code (due to the need for REX
prefixes), and most of the logic in hpet.c really doesn't need
64-bit operations.At once this avoids the need for a couple of type casts.
Signed-off-by: Jan Beulich
Cc: Shaohua Li
Cc: Venkatesh Pallipadi
LKML-Reference:
Signed-off-by: Ingo Molnar
12 Aug, 2009
1 commit
-
If CPU support always running local APIC timer, per-cpu hpet
timer could be disabled, which is useless and wasteful in such
case. Let's leave the timers to others.The effect is that we reserve less timers.
Signed-off-by: Shaohua Li
Cc: venkatesh.pallipadi@intel.com
LKML-Reference:
Signed-off-by: Ingo Molnar
15 Jun, 2009
1 commit
-
timer interrupts are excluded from being disabled during suspend. The
clock events code manages the disabling of clock events on its own
because the timer interrupt needs to be functional before the resume
code reenables the device interrupts.The hpet per cpu timers request their interrupt without setting the
IRQF_TIMER flag so suspend_device_irqs() disables them as well which
results in a fatal resume failure on the boot CPU.Adding IRQF_TIMER to the interupt flags when requesting the hpet per
cpu timer interrupts solves the problem.Reported-by: Benjamin S.
Signed-off-by: Thomas Gleixner
Tested-by: Benjamin S.
Cc: stable@kernel.org
22 Apr, 2009
2 commits
-
(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
Signed-off-by: Andreas Herrmann
Tested-by: Jeff Mahoney
LKML-Reference:
Signed-off-by: Ingo Molnar -
Pass clocksource pointer to the read() callback for clocksources. This
allows us to share the callback between multiple instances.[hugh@veritas.com: fix powerpc build of clocksource pass clocksource mods]
[akpm@linux-foundation.org: cleanup]
Signed-off-by: Magnus Damm
Acked-by: John Stultz
Cc: Thomas Gleixner
Signed-off-by: Hugh Dickins
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
23 Feb, 2009
1 commit
-
Impact: fix system hang on some systems operating with HZ_1000
On a system that stalled with HZ_1000, the first value written to
T0_CMP (when the main counter was not stopped) did not trigger an
interrupt. Instead after the main counter wrapped around (after
several minutes) an interrupt was triggered and afterwards the
periodic interrupt took effect.This can be fixed by implementing HPET spec recommendation for
programming the periodic mode (i.e. stopping the main counter).Signed-off-by: Andreas Herrmann
Cc: Mark Hounschell
Cc: Borislav Petkov
Signed-off-by: Ingo Molnar