The x86_64 arch/x86/kernel/Makefile uses references into
arch/x86/kernel/cpu/... to use code from there.
Unifiy it with the nicely structured i386 way and reuse the existing
subdirectory make rules.
Also move the machine check related source into ...kernel/cpu/mcheck,
where the other machine check related code is.
No code change.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Move mce.c to mce_32.c to allow the later move of the x86_64 mce.c
from arch/x86/kernel/ to ...kernel/cpu/mcheck
No code change.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Prepare the makefiles in x86/kernel/cpu and x86/kernel/cpu/mcheck to
be used by the x86_64 build as well.
No code change.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Preperatory patch to simplify the sharing of Makefiles in
arch/x86.
Linus came up with this during a discussion about the ugliness of
ifeq($CONFIG_X86_32),y) and obj-$(CONFIG_X86_32) in the shared
Makefiles.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Most of contents in crash are same.
Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Merge mmu_32.h and mmu_64.h into mmu.h.
Signed-off-by: Chris Snook <csnook@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
The previous patch wasn't correctly handling the 'count' variable. If
a CPU gave bad results on the 1st or 2nd run but good results on the
3rd, it wouldn't do the correct thing. No idea if any such CPU
exists, but the patch below handles that case by discarding the bad
runs.
If a bad result (too quick, or too slow) occurs on any of the 3 runs
it will be discarded.
Also updated some comments to explain what's going on.
Signed-off-by: Dave Johnson <djohnson@sw.starentnetworks.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
I ran into this problem on a system that was unable to obtain NTP sync
because the clock was running very slow (over 10000ppm slow). ntpd had
declared all of its peers 'reject' with 'peer_dist' reason.
On investigation, the tsc_khz variable was significantly incorrect
causing xtime to run slow. After a reboot tsc_khz was correct so I
did a reboot test to see how often the problem occurred:
Test was done on a 2000 Mhz Xeon system. Of 689 reboots, 8 of them
had unacceptable tsc_khz values (>500ppm):
range of tsc_khz # of boots % of boots
---------------- ---------- ----------
< 1999750 0 0.000%
1999750 - 1999800 21 3.048%
1999800 - 1999850 166 24.128%
1999850 - 1999900 241 35.029%
1999900 - 1999950 211 30.669%
1999950 - 2000000 42 6.105%
2000000 - 2000000 0 0.000%
2000050 - 2000100 0 0.000%
[...]
2000100 - 2015000 1 0.145% << BAD
2015000 - 2030000 6 0.872% << BAD
2030000 - 2045000 1 0.145% << BAD
2045000 < 0 0.000%
The worst boot was 2032.577 Mhz, over 1.5% off!
It appears that on rare occasions, mach_countup() is taking longer to
complete than necessary.
I suspect that this is caused by the CPU taking a periodic SMI
interrupt right at the end of the 30ms calibration loop. This would
cause the loop to delay while the SMI BIOS hander runs. The resulting
TSC value is beyond what it actually should be resulting in a higher
tsc_khz.
The below patch makes native_calculate_cpu_khz() take the best
(shortest duration, lowest khz) run of it's 3 calibration loops. If a
SMI goes off causing a bad result (long duration, higher khz) it will
be discarded.
With the patch applied, 300 boots of the same system produce good
results:
range of tsc_khz # of boots % of boots
---------------- ---------- ----------
< 1999750 0 0.000%
1999750 - 1999800 30 10.000%
1999800 - 1999850 166 55.333%
1999850 - 1999900 89 29.667%
1999900 - 1999950 15 5.000%
1999950 < 0 0.000%
Problem was found and tested against 2.6.18. Patch is against 2.6.22.
Signed-off-by: Dave Johnson <djohnson@sw.starentnetworks.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
I missed an obvious one!
x86 CPUs are defined not to reorder stores past earlier loads, so there is
no hardware memory barrier required to implement a release-consistent store
(all stores are, by definition).
So ditch the generic lock bitops, and implement optimised versions for x86,
which removes the mfence from __clear_bit_unlock (which is already a useful
primitive for SLUB).
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
It seems commit 09cadedbdc was incomplete
due to a clash with the x86 architecture merge.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Make some improvements for Documentation/watchdog/src/watchdog-simple.c.
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Driver for the watchdog timer. Still doesn't reboots the machine
on some boards, but we have improved and cleaned it
Signed-off-by: Matteo Croce <technoboy85@gmail.com>
Signed-off-by: Nicolas Thill <nico@openwrt.org>
Signed-off-by: Enrik Berkhan <Enrik.Berkhan@akk.org>
Signed-off-by: Christer Weinigel <wingel@nano-system.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
ICP's Wafer 5823 SBC has, as far as I can tell, the same WDT as many,
if not all ICP's SBC's (that do have a WDT). I have tested it with
several boards, including Rocky 4783, Rocky 3703 and Rocky 3782.
I propose a rename of the Wafer 5823 watchdog timer driver
to something like "IPC (SBC) Watchdog Timer", to reflect that it
works with other IPC boards (maybe even all of them).
Signed-off-by: Veljkovic Srdjan <sveljko@gvs.co.yu>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
The original serial-number calculations based on WWPN no longer
apply to newer ISPs (ISP24xx and ISP25xx). These newer board's
serial number reside in the VPD.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
For recent ISPs, software during CS_UNDERRUN handling must
determine if the two residuals, firmware-calculated and FCP_RSP,
are different to recognize if a frame has been dropped. Update
the driver to catch this condition, and clear the
SS_RESIDUAL_UNDER and lscsi_status bits. This logic is
consistent with what earlier firmwares did by explicitly
cracking open the FCP_RSP statuses and clearing
SS_RESIDUAL_UNDER.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Recent ISPs need only the single MMIO BAR to manipulate HW
registers. Unfortunately, ISP21xx, ISP22xx, ISP23xx, and ISP63xx
type cards still require the I/O mapped region to manipulate the
FLASH via the two HW flash-registers (flash_address and
flash_data).
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Original implementation would not use the burst-write mechanisms
for requests equal to OPTROM_BURST_DWORDS transfer dwords.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Since both NVRAM and VPD regions of the flash reside on unaligned
sector boundaries, during update, the driver must perform a
read-modify-write operation to the composite NVRAM/VPD region.
This affects ISP25xx type boards only.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
As the intermixing may cause issues where HCCR bits could be
cleared inappropriately during MSI/MSI-X interrupt handling.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Commit b9f2c044 replaced mv643xx_get_stats_count() with
mv643xx_get_sset_count(), but forgot to hook it up.
drivers/net/mv643xx_eth.c:2678: warning: mv643xx_get_sset_count defined but not used
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
This function just printed a message to the user; move the print to its
only caller, and turn it into an starget_printk.
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This structure is accessed by the device; the fewer Linux things in it,
the better. Using the pci_dev pointer from the hostdata requires a lot
of changes:
- Pass Scsi_Host to a lot of routines which currently take a sym_hcb.
- Set the Scsi_Host as the pci drvdata (instead of the sym_hcb)
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Make sym_interrupt return an irqreturn_t instead of void, and take a
Scsi_Host instead of a sym_hcb. Pass the Scsi_Host to the interrupt
handler instead of the sym_hcb. Rename the host_data to sym_data.
Keep a pci_dev pointer in the sym_data. Rename the Scsi_Host from
instance to shost.
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
These macros aren't needed any more. They used to be used for SPARC.
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
If we have a scsi_cmnd, it gives the user more information than the
sym_name, and maybe the target.
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
By introducing the use_dac(), set_dac() and DMA_DAC_MASK macros, we can
eliminate a lot of ifdefs from the code. We now rely on the compiler to
optimise away a few things that we'd formerly relied on the preprocessor
to do. This makes sym_setup_bus_dma_mask() small enough to inline into
its only caller.
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
With sysfs making these options tunable at runtime, there's no
justification for keeping this horrendously complex specification
string around.
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
These struct elements record info that is never needed
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Following the same path as ->revision_id, remove ->device_id
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Auke missed the sym2 driver in his initial sweep.
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Thomas Gleixner