Kurt Hackel [Mon, 1 May 2006 20:49:20 +0000 (13:49 -0700)]
ocfs2: dlm_remaster_locks() should never exit without completing
We cannot restart recovery. Once we begin to recover a node, keep the state
of the recovery intact and follow through, regardless of any other node
deaths that may occur.
Signed-off-by: Kurt Hackel <kurt.hackel@oracle.com> Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
Kurt Hackel [Mon, 1 May 2006 20:47:50 +0000 (13:47 -0700)]
ocfs2: special case recovery lock in dlmlock_remote()
If the previous master of the recovery lock dies, let calc_usage take it
down completely and let the caller completely redo the dlmlock() call.
Otherwise, there will never be an opportunity to re-master the lockres and
recovery wont be able to progress.
Signed-off-by: Kurt Hackel <kurt.hackel@oracle.com> Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
Kurt Hackel [Mon, 1 May 2006 20:32:27 +0000 (13:32 -0700)]
ocfs2: pending mastery asserts and migrations should block each other
Use the existing structure for blocking migrations when ASTs are pending to
achieve the same result. If we can catch the assert before it goes on the
wire, just cancel it and let the migration continue.
Signed-off-by: Kurt Hackel <kurt.hackel@oracle.com> Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
Now we never change the owner of a lock resource until unmount or node
death. This will be re-enabled once some issues in the algorithm used have
been resolved.
Signed-off-by: Kurt Hackel <kurt.hackel@oracle.com> Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
Kurt Hackel [Mon, 1 May 2006 20:27:10 +0000 (13:27 -0700)]
ocfs2: do not unconditionally purge the lockres in dlmlock_remote()
In dlmlock_remote(), do not call purge_lockres until the lock resource
actually changes. otherwise, the mastery info on the lockres will go away
underneath the caller.
Signed-off-by: Kurt Hackel <kurt.hackel@oracle.com> Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
Kurt Hackel [Mon, 1 May 2006 19:02:07 +0000 (12:02 -0700)]
ocfs2: increase backoff before waiting for recovery
When mastering non-recovery lock resources, additional time was frequently
needed to allow the disk heartbeat to catch up with the network timeout. the
recovery lock resource is time critical and avoids this path.
Signed-off-by: Kurt Hackel <kurt.hackel@oracle.com> Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
Joel Becker [Fri, 17 Mar 2006 01:40:37 +0000 (17:40 -0800)]
[PATCH] ocfs2: Alloc at least a page for the DLM hash
The OCFS2 DLM allocates a number of pages for a hash to lookup locks.
There was a bug where a PAGE_SIZE bigger than the hash size (eg, 64K
pages) would result in zero pages allocated.
Signed-off-by: Joel Becker <joel.becker@oracle.com> Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial:
typo fixes
Clean up 'inline is not at beginning' warnings for usb storage
Storage class should be first
i386: Trivial typo fixes
ixj: make ixj_set_tone_off() static
spelling fixes
fix paniced->panicked typos
Spelling fixes for Documentation/atomic_ops.txt
move acknowledgment for Mark Adler to CREDITS
remove the bouncing email address of David Campbell
Karsten Keil [Mon, 26 Jun 2006 18:21:01 +0000 (20:21 +0200)]
[PATCH] fix processing of the last byte in isdn_readbchan_tty()
The changes in the tty handling contain a bug while accessing
the last byte in the skb. Since special sequence for control of
DTMF and FAX via ttyI* devices handled via this path, these services
do not work anymore.
"It seems too little tested: "losetup -d /dev/loop0" fails with
EINVAL because nothing sets lo_thread; but even when you patch
loop_thread() to set lo->lo_thread = current, it can't survive
more than a few dozen iterations of the loop below (with a tmpfs
mounted on /tst):
j=0
cp /dev/zero /tst
while :
do
let j=j+1
echo "Doing pass $j"
losetup /dev/loop0 /tst/zero
mkfs -t ext2 -b 1024 /dev/loop0 >/dev/null 2>&1
mount -t ext2 /dev/loop0 /mnt
umount /mnt
losetup -d /dev/loop0
done
it collapses with failed ioctl then BUG_ON(!bio).
I think the original lo_done completion was more subtle and safe
than the kthread conversion has allowed for."
* git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild: (40 commits)
kbuild: trivial fixes in Makefile
kbuild: adding symbols in Kconfig and defconfig to TAGS
kbuild: replace abort() with exit(1)
kbuild: support for %.symtypes files
kbuild: fix silentoldconfig recursion
kbuild: add option for stripping modules while installing them
kbuild: kill some false positives from modpost
kbuild: export-symbol usage report generator
kbuild: fix make -rR breakage
kbuild: append -dirty for updated but uncommited changes
kbuild: append git revision for all untagged commits
kbuild: fix module.symvers parsing in modpost
kbuild: ignore make's built-in rules & variables
kbuild: bugfix with initramfs
kbuild: modpost build fix
kbuild: check license compatibility when building modules
kbuild: export-type enhancement to modpost.c
kbuild: add dependency on kernel.release to the package targets
kbuild: `make kernelrelease' speedup
kconfig: KCONFIG_OVERWRITECONFIG
...
Greg Ungerer [Mon, 26 Jun 2006 06:33:15 +0000 (16:33 +1000)]
[PATCH] m68knommu: use configurable RAM setup page_offset.h
Remove board specific base RAM conditionals from page_offset.h
With the Kconfig time configurable RAM setup none of this is required.
It is all based on the Kconfig (CONFIG_RAMBASE) option now.
Greg Ungerer [Mon, 26 Jun 2006 06:33:05 +0000 (16:33 +1000)]
[PATCH] m68knommu: use configurable RAM setup in linker script
Remove the fixed RAM configurations for each board type from the
linker script. Replace with simple defines usng the flexible RAM
configuration options. This cleans out of lot of board specific
munging of addresses.
Greg Ungerer [Mon, 26 Jun 2006 06:32:59 +0000 (16:32 +1000)]
[PATCH] m68knommu: create configurable RAM setup
Reworked the way RAM regions are defined. Instead of coding all the
variations for each board type we now just configure RAM base and size
in the usual Kconfig setup. This much simplifies the code, and makes it
a lot more flexible when setting up new boards or board varients.
Greg Ungerer [Mon, 26 Jun 2006 06:34:09 +0000 (16:34 +1000)]
[PATCH] m68knommu: remove unused vars from generic 68328 start code
Clean out unused variable definitions from 68328 start up code.
Also use a more appropriate start address for the case of relocating
the kernel code to RAM (from ROM/flash).
Greg Ungerer [Mon, 26 Jun 2006 06:34:04 +0000 (16:34 +1000)]
[PATCH] m68knommu: remove __ramvec from 68328/pilot start code
__ramvec has been removed from the linker script. The vector base
address is defined as a configurable option, use that. Remove its
use from the 68328/pilot startup code.
* master.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb:
V4L/DVB (4227): Update this driver for recent header file movement.
V4L/DVB (4223): Add V4L2_CID_MPEG_STREAM_VBI_FMT control
V4L/DVB (4222): Always switch tuner mode when calling VIDIOC_S_FREQUENCY.
V4L/DVB (4221): Add HM12 YUV format define.
V4L/DVB (4219): Av7110: analog sound output of DVB-C rev 2.3
V4L/DVB (4217): Fix a misplaced closing bracket/else, which caused swzigzag not to be called
V4L/DVB (4215): Make VIDEO_CX88_BLACKBIRD a separate build option
V4L/DVB (4214): Make VIDEO_CX2341X a selectable build option
V4L/DVB (4213): Cx88: cleanups
V4L/DVB (4211): Fix an Oops for all fe that have get_frontend_algo == NULL
Take two, now without spurious whitespace :( Applies to git & 2.6.17-rc6
CONFIG_DEBUG_STACKOVERFLOW existed for x86_64 in 2.4, but seems to have gone AWOL in 2.6.
I've pretty much just copied this over from the 2.4 code, with
appropriate tweaks for the 2.6 kernel, plus a bugfix. I'd personally
rather see it printed out the way other arches do it, i.e.
bytes-remaining-until-overflow, rather than having to do the subtraction
yourself. Also, only 128 bytes remaining seems awfully late to issue a
warning. But I'll start here :)
Christian Kujau [Mon, 26 Jun 2006 12:00:02 +0000 (14:00 +0200)]
[PATCH] x86_64: msi_apic.c build fix
CC drivers/pci/msi-apic.o
In file included from include/asm/msi.h:11,
from drivers/pci/msi.h:71,
from drivers/pci/msi-apic.c:8:
include/asm/smp.h:103: error: syntax error before '->' token
akpm: nasty. It appears to be
static inline unsigned int cpu_mask_to_apicid(cpumask_t cpumask)
[PATCH] x86_64: i386/x86-64 Add nmi watchdog support for new Intel CPUs
Intel now has support for Architectural Performance Monitoring Counters
( Refer to IA-32 Intel Architecture Software Developer's Manual
http://www.intel.com/design/pentium4/manuals/253669.htm ). This
feature is present starting from Intel Core Duo and Intel Core Solo processors.
What this means is, the performance monitoring counters and some performance
monitoring events are now defined in an architectural way (using cpuid).
And there will be no need to check for family/model etc for these architectural
events.
Below is the patch to use this performance counters in nmi watchdog driver.
Patch handles both i386 and x86-64 kernels.
Keith Owens [Mon, 26 Jun 2006 11:59:56 +0000 (13:59 +0200)]
[PATCH] x86_64: Avoid broadcasting NMI IPIs
On some i386/x86_64 systems, sending an NMI IPI as a broadcast will
reset the system. This seems to be a BIOS bug which affects machines
where one or more cpus are not under OS control. It occurs on HT
systems with a version of the OS that is not compiled without HT
support. It also occurs when a system is booted with max_cpus=n where
2 <= n < cpus known to the BIOS. The fix is to always send NMI IPI as
a mask instead of as a broadcast.
Siddha, Suresh B [Mon, 26 Jun 2006 11:59:53 +0000 (13:59 +0200)]
[PATCH] x86_64: fix apic error on bootup
Appended patch fixes the "APIC error on CPUX: 00(40)" observed during bootup.
From SDM Vol-3A "Valid Interrupt Vectors" section:
"When an illegal vector value (0-15) is written to an LVT entry
and the delivery mode is Fixed, the APIC may signal an illegal
vector error, with out regard to whether the mask bit is set
or whether an interrupt is actually seen on input."
Chuck Ebbert [Mon, 26 Jun 2006 11:59:50 +0000 (13:59 +0200)]
[PATCH] x86_64: enlarge window for stack growth
Allow stack growth so the 'enter' instruction works. Also
fixes problem in compat_sys_kexec_load() which could allocate
more than 128 bytes using compat_alloc_user_space().
Keith Owens [Mon, 26 Jun 2006 11:59:41 +0000 (13:59 +0200)]
[PATCH] x86_64: Standardize i386/x86_64 handling of NMI_VECTOR
x86_64 and i386 behave inconsistently when sending an IPI on vector 2
(NMI_VECTOR). Make both behave the same, so IPI 2 is sent as NMI.
The crash code was abusing send_IPI_allbutself() by passing a code
instead of a vector, it only worked because crash knew about the
internal code of send_IPI_allbutself(). Change crash to use NMI_VECTOR
instead, and remove the comment about how crash was abusing the function.
This patch is a pre-requisite for fixing the problem where sending an
IPI as NMI would reboot some Dell Xeon systems. I cannot fix that
problem while crash continus to abuse send_IPI_allbutself().
It also removes the inconsistency between i386 and x86_64 for
NMI_VECTOR. That will simplify all the RAS code that needs to bring
all the cpus to a clean stop, even when one or more cpus are spinning
disabled.
Sergey Vlasov [Mon, 26 Jun 2006 11:59:32 +0000 (13:59 +0200)]
[PATCH] x86_64: Do not use -ffunction-sections for modules
Currently CONFIG_REORDER uses -ffunction-sections for all code;
however, creating a separate section for each function is not useful
for modules and just adds bloat. Moving this option from CFLAGS to
CFLAGS_KERNEL shrinks module object files (e.g., the module tree for a
kernel built with most drivers as modules shrinked from 54M to 46M),
and decreases the number of sysfs files in /sys/module/*/sections/
directories.
Defaulting to a value not evenly divisible by four makes little sense,
as four values are displayed per line (and hence the rest of the line
would otherwise be wasted).
Rohit Seth [Mon, 26 Jun 2006 11:59:14 +0000 (13:59 +0200)]
[PATCH] x86_64: x86_64 setup.c - printing cmp related boottime information
Getting phys_proc_id and cpu_core_id information to be printed at boot
time for AMD processors. Also matching the Node related boot time
information that gets printed for Intel and AMD processors for NUMA
configurations.
Andi Kleen [Mon, 26 Jun 2006 11:59:11 +0000 (13:59 +0200)]
[PATCH] i386/x86-64/ia64: Move polling flag into thread_info_status
During some profiling I noticed that default_idle causes a lot of
memory traffic. I think that is caused by the atomic operations
to clear/set the polling flag in thread_info. There is actually
no reason to make this atomic - only the idle thread does it
to itself, other CPUs only read it. So I moved it into ti->status.
Converted i386/x86-64/ia64 for now because that was the easiest
way to fix ACPI which also manipulates these flags in its idle
function.
Cc: Nick Piggin <npiggin@novell.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Len Brown <len.brown@intel.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Jan Beulich [Mon, 26 Jun 2006 11:59:02 +0000 (13:59 +0200)]
[PATCH] x86_64: miscellaneous mm/init.c fixes
- fix an off-by-one error in phys_pmd_init()
- prevent phys_pmd_init() from removing mappings established earlier
- fix the direct mapping early printk to in fact show the end of the range
- remove an apparently orphan comment
Jacob Shin [Mon, 26 Jun 2006 11:58:50 +0000 (13:58 +0200)]
[PATCH] x86_64: mce_amd relocate sysfs files
Get rid of /sys/devices/system/threshold directory and move
mce_amd thresholding files into the machine sysfs directory --
/sys/devices/system/machinecheck.
Vojtech Pavlik [Mon, 26 Jun 2006 11:58:35 +0000 (13:58 +0200)]
[PATCH] x86_64: Explain why HPET T0_CMP register is written twice
After writing the CFG register, the first value written to the T0_CMP
register is the value at which next interrupt should be triggered, every
value after that sets the period of the interrupt. For that reason, the code
needs to write the value twice - to set both the phase and period.
[AK: I had already figured it out by myself, but it's still useful
to have a comment for this.]
Vojtech Pavlik [Mon, 26 Jun 2006 11:58:26 +0000 (13:58 +0200)]
[PATCH] x86_64: Add X86_FEATURE_RDTSCP, fix rdtscp in /proc/cpuinfo
This patch adds the X86_FEATURE_RDTSCP #define, so that kernel code can
check for the feature easily and also fixes the location of the "rdtscp"
string in the cpuinfo tables.
Vojtech Pavlik [Mon, 26 Jun 2006 11:58:20 +0000 (13:58 +0200)]
[PATCH] x86_64: Add useful constants to time.h
In timekeeping code, one often does need to use conversion constants. Naming
these leads to code that's easier to understand, showing the reader between
which units the conversion is made.
Rohit Seth [Mon, 26 Jun 2006 11:58:17 +0000 (13:58 +0200)]
[PATCH] x86_64: moving phys_proc_id and cpu_core_id to cpuinfo_x86
Most of the fields of cpuinfo are defined in cpuinfo_x86 structure.
This patch moves the phys_proc_id and cpu_core_id for each processor to
cpuinfo_x86 structure as well.
Jon Mason [Mon, 26 Jun 2006 11:58:14 +0000 (13:58 +0200)]
[PATCH] x86_64: Calgary IOMMU - Calgary specific bits
This patch hooks Calgary into the build, the x86-64 IOMMU
initialization paths, and introduces the Calgary specific bits. The
implementation draws inspiration from both PPC (which has support for
the same chip but requires firmware support which we don't have on
x86-64) and gart. Calgary is different from gart in that it support a
translation table per PHB, as opposed to the single gart aperture.
Changes from previous version:
* Addition of boot-time disablement for bus-level translation/isolation
(e.g, enable userspace DMA for things like X)
* Usage of newer IOMMU abstraction functions
This patch creates a new interface for IOMMUs by adding a centralized
location for IOMMU allocation (for translation tables/apertures) and
IOMMU initialization. In creating these, code was moved around for
abstraction, uniformity, and consiceness.
Take note of the move of the iommu_setup bootarg parsing code to
__setup. This is enabled by moving back the location of the aperture
allocation/detection to mem init (which while ugly, was already the
location of the swiotlb_init).
While a slight departure from the previous patch, I belive this provides
the true intention of the previous versions of the patch which changed
this code. It also makes the addition of the upcoming calgary code much
cleaner than previous patches.
[AK: Removed one broken change. iommu_setup still has to be called
early]
swiotlb relies on the gart specific iommu_aperture variable to know if
we discovered a hardware IOMMU before swiotlb initialization. Introduce
iommu_detected to do the same thing, but in a HW IOMMU neutral manner,
in preparation for adding the Calgary HW IOMMU.
projects / linux-2.6 / log