Andrew Morton [Mon, 10 May 2004 06:25:57 +0000 (23:25 -0700)]
[PATCH] Reduce TLB flushing during process migration
From: Martin Hicks <mort@wildopensource.com>
Another optimization patch from Jack Steiner, intended to reduce TLB
flushes during process migration.
Most architextures should define tlb_migrate_prepare() to be flush_tlb_mm(),
but on i386, it would be a wasted flush, because i386 disconnects previous
cpus from the tlb flush automatically.
Andrew Morton [Mon, 10 May 2004 06:25:45 +0000 (23:25 -0700)]
[PATCH] sched: add local load metrics
From: Nick Piggin <piggin@cyberone.com.au>
This patch removes the per runqueue array of NR_CPU arrays. Each time we
want to check a remote CPU's load we check nr_running as well anyway, so
introduce a cpu_load which is the load of the local runqueue and is kept
updated in the timer tick. Put them in the same cacheline.
This has additional benefits of having the cpu_load consistent across all
CPUs and more up to date. It is sampled better too, being updated once per
timer tick.
This shouldn't make much difference in scheduling behaviour, but all
benchmarks are either as good or better on the 16-way NUMAQ: hackbench,
reaim, volanomark are about the same, tbench and dbench are maybe a bit
better. kernbench is about one percent better.
John reckons it isn't a big deal, but it does save 4K per CPU or 2MB total
on his big systems, so I figure it must be a bit kinder on the caches. I
think it is just nicer in general anyway.
Andrew Morton [Mon, 10 May 2004 06:25:34 +0000 (23:25 -0700)]
[PATCH] sched: SMT niceness handling
From: Con Kolivas <kernel@kolivas.org>
This patch provides full per-package priority support for SMT processors
(aka pentium4 hyperthreading) when combined with CONFIG_SCHED_SMT.
It maintains cpu percentage distribution within each physical cpu package
by limiting the time a lower priority task can run on a sibling cpu
concurrently with a higher priority task.
It introduces a new flag into the scheduler domain
unsigned int per_cpu_gain; /* CPU % gained by adding domain cpus */
This is empirically set to 15% for pentium4 at the moment and can be
modified to support different values dynamically as newer processors come
out with improved SMT performance. It should not matter how many siblings
there are.
How it works is it compares tasks running on sibling cpus and when a lower
static priority task is running it will delay it till
high_priority_timeslice * (100 - per_cpu_gain) / 100 <= low_prio_timeslice
eg. a nice 19 task timeslice is 10ms and nice 0 timeslice is 102ms On
vanilla the nice 0 task runs on one logical cpu while the nice 19 task runs
unabated on the other logical cpu. With smtnice the nice 0 runs on one
logical cpu for 102ms and the nice 19 sleeps till the nice 0 task has 12ms
remaining and then will schedule.
Real time tasks and kernel threads are not altered by this code, and kernel
threads do not delay lower priority user tasks.
with lots of thanks to Zwane Mwaikambo and Nick Piggin for help with the
coding of this version.
If this is merged, it is probably best to delay pushing this upstream in
mainline till sched_domains gets tested for at least one major release.
Andrew Morton [Mon, 10 May 2004 06:25:11 +0000 (23:25 -0700)]
[PATCH] sched-group-power
From: Nick Piggin <piggin@cyberone.com.au>
The following patch implements a cpu_power member to struct sched_group.
This allows special casing to be removed for SMT groups in the balancing
code. It does not take CPU hotplug into account yet, but that shouldn't be
too hard.
I have tested it on the NUMAQ by pretending it has SMT. Works as expected.
Active balances across nodes.
Andrew Morton [Mon, 10 May 2004 06:25:00 +0000 (23:25 -0700)]
[PATCH] sched_balance_exec(): don't fiddle with the cpus_allowed mask
From: Rusty Russell <rusty@rustcorp.com.au>,
Nick Piggin <piggin@cyberone.com.au>
The current sched_balance_exec() sets the task's cpus_allowed mask
temporarily to move it to a different CPU. This has several issues,
including the fact that a task will see its affinity at a bogus value.
So we change the migration_req_t to explicitly specify a destination CPU,
rather than the migration thread deriving it from cpus_allowed. If the
requested CPU is no longer valid (racing with another set_cpus_allowed,
say), it can be ignored: if the task is not allowed on this CPU, there will
be another migration request pending.
This change allows sched_balance_exec() to tell the migration thread what
to do without changing the cpus_allowed mask.
So we rename __set_cpus_allowed() to move_task(), as the cpus_allowed mask
is now set by the caller. And move_task_away(), which the migration thread
uses to actually perform the move, is renamed __move_task().
I also ignore offline CPUs in sched_best_cpu(), so sched_migrate_task()
doesn't need to check for offline CPUs.
Ulterior motive: this approach also plays well with CPU Hotplug.
Previously that patch might have seen a task with cpus_allowed only
containing the dying CPU (temporarily due to sched_balance_exec) and
forcibly reset it to all cpus, which might be wrong. The other approach is
to hold the cpucontrol sem around sched_balance_exec(), which is too much
of a bottleneck.
Andrew Morton [Mon, 10 May 2004 06:24:49 +0000 (23:24 -0700)]
[PATCH] sched: handle inter-CPU jiffies skew
From: Nick Piggin <piggin@cyberone.com.au>
John Hawkes discribed this problem to me:
There *is* a small problem in this area, though, that SuSE avoids.
"jiffies" gets updated by cpu0. The other CPUs may, over time, get out of
sync (and they're initialized on ia64 to start out being out of sync), so
it's no guarantee that every CPU will wake up from its timer interrupt and
see a "jiffies" value that is guaranteed to be last_jiffies+1. Sometimes
the jiffies value may be unchanged since the last wakeup. Sometimes the
jiffies value may have incremented by 2 (or more, especially if cpu0's
interrupts are disabled for long stretches of time). So an algoithm that
says, "I'll call load_balance() only when jiffies is *exactly* N" is going
to fail on occasion, either by calling load_balance() too often or not
often enough. ***
I fixed this by adding a last_balance field to struct sched_domain, and
working off that.
Andrew Morton [Mon, 10 May 2004 06:24:38 +0000 (23:24 -0700)]
[PATCH] sched: implement domains for i386 HT
From: Nick Piggin <piggin@cyberone.com.au>
The following patch builds a scheduling description for the i386
architecture using cpu_sibling_map to set up SMT if CONFIG_SCHED_SMT is
set.
It could be made more fancy and collapse degenerate domains at runtime (ie.
1 sibling per CPU, or 1 NUMA node in the computer).
From: Zwane Mwaikambo <zwane@arm.linux.org.uk>
This fixes an oops due to cpu_sibling_map being uninitialised when a
system with no MP table (most UP boxen) boots a CONFIG_SMT kernel. What
also happens is that the cpu_group lists end up not being terminated
properly, but this oops kills it first. Patch tested on UP w/o MP table,
2x P2 and UP Xeon w/ no siblings.
From: "Martin J. Bligh" <mbligh@aracnet.com>,
Nick Piggin <piggin@cyberone.com.au>
Change arch_init_sched_domains to use cpu_online_map
Andrew Morton [Mon, 10 May 2004 06:24:26 +0000 (23:24 -0700)]
[PATCH] sched: cpu_sibling_map to cpu_mask
From: Nick Piggin <piggin@cyberone.com.au>
This is a (somewhat) trivial patch which converts cpu_sibling_map from an
array of CPUs to an array of cpumasks. Needed for >2 siblings per package,
but it actually can simplify code as it allows the cpu_sibling_map to be
set up even when there is 1 sibling per package. Intel want this, I use it
in the next patch to build scheduling domains for the P4 HT.
From: Thomas Schlichter <thomas.schlichter@web.de>
Andrew Morton [Mon, 10 May 2004 06:24:15 +0000 (23:24 -0700)]
[PATCH] scheduler domain balancing improvements
From: Nick Piggin <piggin@cyberone.com.au>
This patch gets the sched_domain scheduler working better WRT balancing.
Its been tested on the NUMAQ. Among other things it changes to the way SMT
load calculation works so as not to active load blances when it shouldn't.
It still has a problem with SMT and NUMA: it will put a task on each
sibling in a node before moving tasks to another node. It should probably
start moving tasks after each *physical* CPU is filled.
To fix, you need "how much CPU power in this domain?" At the moment we
approximate # runqueues == CPU power, and hack around it at the CPU
physical domain by counting all sibling runqueues as 1.
It isn't hard to correctly work the CPU power out, but once CPU hotplug is
in the equation it becomes much more hotplug events. If anyone is actually
interested in getting this fixed, that is.
Andrew Morton [Mon, 10 May 2004 06:23:54 +0000 (23:23 -0700)]
[PATCH] sched: scheduler domain support
From: Nick Piggin <piggin@cyberone.com.au>
This is the core sched domains patch. It can handle any number of levels
in a scheduling heirachy, and allows architectures to easily customize how
the scheduler behaves. It also provides progressive balancing backoff
needed by SGI on their large systems (although they have not yet tested
it).
It is built on top of (well, uses ideas from) my previous SMP/NUMA work, and
gets results very similar to them when using the default scheduling
description.
Benchmarks
==========
Martin was seeing I think 10-20% better system times in kernbench on the 32
way. I was seeing improvements in dbench, tbench, kernbench, reaim,
hackbench on a 16-way NUMAQ. Hackbench in fact had a non linear element
which is all but eliminated. Large improvements in volanomark.
Cross node task migration was decreased in all above benchmarks, sometimes by
a factor of 100!! Cross CPU migration was also generally decreased. See
this post:
http://groups.google.com.au/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&frame=right&th=a406c910b30cbac4&seekm=UAdQ.3hj.5%40gated-at.bofh.it#link2
Results on a hyperthreading P4 are equivalent to Ingo's shared runqueues
patch (which is a big improvement).
Some examples on the 16-way NUMAQ (this is slightly older sched domain code):
Tiny patch to make -mm3 compile on an NUMA box with NR_CPUS >
BITS_PER_LONG.
From: "Martin J. Bligh" <mbligh@aracnet.com>
Fix a minor nit with the find_busiest_group code. No functional change,
but makes the code simpler and clearer. This patch does two things ...
adds some more expansive comments, and removes this if clause:
Thus the if statement is redundant, and only makes the code harder to
read ;-)
From: Rick Lindsley <ricklind@us.ibm.com>
In find_busiest_group(), after we exit the do/while, we select our
imbalance. But max_load, avg_load, and this_load are all unsigned, so
min(x,y) will make a bad choice if max_load < avg_load < this_load (that
is, a choice between two negative [very large] numbers).
Unfortunately, there is a bug when max_load never gets changed from zero
(look in the loop and think what happens if the only load on the machine is
being created by cpu groups of which we are a member). And you have a
recipe for some really bogus values for imbalance.
Even if you fix the max_load == 0 bug, there will still be times when
avg_load - this_load will be negative (thus very large) and you'll make the
decision to move stuff when you shouldn't have.
This patch allows for this_load to set max_load, which if I understand
the logic properly is correct. With this patch applied, the algorithm is
*much* more conservative ... maybe *too* conservative but that's for
another round of testing ...
Andrew Morton [Mon, 10 May 2004 06:23:42 +0000 (23:23 -0700)]
[PATCH] sched: improved resolution in find_busiest_node
From: Nick Piggin <piggin@cyberone.com.au>
From: Frank Cornelis <frank.cornelis@elis.ugent.be>
In order to get the best possible resolution we need to use NR_CPUS instead
of the constant value 10. load is an int, so no need to worry about
overflows...
Linus Torvalds [Sun, 9 May 2004 11:43:07 +0000 (04:43 -0700)]
Mark the ACPI CPU throttle and timer IO regions busy.
This should help some laptops where the generic PCI
code might otherwise believe that this range is unused.
The ACPI IO range is usually not visible as a standard
BAR.
Andi Kleen [Sun, 9 May 2004 11:25:35 +0000 (04:25 -0700)]
[PATCH] Fix x86-64 compilation without iommu for 2.6.6rc3
Various people hit this in earlier kernels. The x86-64 kernel did not compile
without CONFIG_IOMMU_GART in various configurations. Just add the missing symbol
and export it. Also export iommu_merge while I am at it.
Andi Kleen [Sun, 9 May 2004 11:25:24 +0000 (04:25 -0700)]
[PATCH] Fix machine check handler on x86-64
This fixes a bug in the new machine check handler on x86-64.
One nasty part was that when you got an MCE during boot up
then it would not always print it on the screen, but still
panic because it attempted to kill the idle task.
This patch does:
- Always use KERN_EMERG when printing MCEs
- Always panic and print on screen before killing idle loop
or init.
Marc Singer [Sun, 9 May 2004 16:31:40 +0000 (17:31 +0100)]
[ARM PATCH] 1817/1: lh7a40x #2 (2/7) core-include
Patch from Marc Singer
Include files for this updated lh7a40x patch set. The changes in this
set from the previous are mostly cosmetic. The memory macros were
reworked in order to be more similar to the other ARM versions. The
previous versions produced the same results, but the forms are
slightly different.
Marc Singer [Sun, 9 May 2004 16:27:51 +0000 (17:27 +0100)]
[ARM PATCH] 1816/1: lh7a40x #2 (1/7) core
Patch from Marc Singer
Updated change set for the 2.6.5 kernel *and* for the April 8th arm
patch. Also included are changes suggested by Russell that merge
several of the files in the mach- directory. I have also endeavored
to remove all unnecessary whitespace additions.
Note that since I've found the cause of an annoying user-space crash,
I believe that this patch is OK. The crash appears to have nothing to
do with the system setup.
Tony Lindgren [Sun, 9 May 2004 11:56:38 +0000 (12:56 +0100)]
[ARM PATCH] 1847/1: OMAP update 2/2: include files
Patch from Tony Lindgren
This patch syncs the mainline kernel with the linux-omap tree. The
patch contains following updates:
- Move virtual IO area to 0xfefb0000 from 0xfffb0000 to fix parts of
IO area overlapping with ARM Linux reserved memory area
- Add support to OMAP-730, OMAP-5912, and OMAP-1710 processors
- Reorganize board support
- Add OMAP core detection
This patch requires ARM Linux patch 1844/1 be applied to compile
OMAP-730 and OMAP-5912
Tony Lindgren [Sun, 9 May 2004 11:52:15 +0000 (12:52 +0100)]
[ARM PATCH] 1846/1: OMAP update 1/2: arch files
Patch from Tony Lindgren
This patch syncs the mainline kernel with the linux-omap tree. The
patch contains following updates:
- Move virtual IO area to 0xfefb0000 from 0xfffb0000 to fix parts of
IO area overlapping with ARM Linux reserved memory area
- Add support to OMAP-730, OMAP-5912, and OMAP-1710 processors
- Reorganize board support
- Add OMAP core detection
This patch requires ARM Linux patch 1844/1 be applied to compile
OMAP-730 and OMAP-5912
Linus Torvalds [Sat, 8 May 2004 13:38:51 +0000 (06:38 -0700)]
Waste less memory in dentries.
We don't bother aligining them on a cacheline boundary, since
that is totally excessive in some configurations (especially
P4's with 128-byte cachelines).
Instead, we make the minimum inline string size a bit longer,
and re-order a few fields that allow for better packing on
64-bit architectures, for better memory utilization.
Andrew Morton [Sat, 8 May 2004 10:25:27 +0000 (03:25 -0700)]
[PATCH] run populate_rootfs() before initcalls
I moved this a little too late - we need to run populate_rootfs() before
running initcalls because some driver initcalls need to open files for
firmware.
The populate_rootfs() call is still coming after init_idle(), so it won't
knock the scheduler over.
This is a version of Binary Increase Control (BIC) TCP
developed by NCSU. It is yet another TCP congestion control
algorithm for handling big fat pipes. For normal size congestion
windows it behaves the same as existing TCP Reno, but when window
is large it uses additive increase to ensure fairness and when
window is small it uses binary search increase.
For more details see the BIC TCP web page
http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/
The original code was for web100 (2.4); this version is pretty
much the same but targeted for 2.6 with less sysctl parameters
and more constants.
I don't have a real high speed long haul network to test, but
when running over 1G links with delays, the performance is more stable
(ie tests are repeatable) and as fast as existing Reno.
[SCTP]: Fix multihomed connection failures on 64-bit systems.
Avoid the use of sizeof() and pointer arithmetic to get to the end
of sctp_cookie structure. Instead use the last element peer_init which
is a zero-sized array as the offset.
James Morris [Sat, 8 May 2004 08:05:57 +0000 (01:05 -0700)]
[NET]: Add sock_create_lite()
The purpose of this is to allow sockets created by the kernel in this way
to be passed through the LSM socket creation hooks and be labeled and
mediated in the same manner as other sockets.
This patches addresses a class of potential issues with LSMs, where such
sockets will not be labeled correctly (if at all), or mediated during
creation. Under SELinux, it fixes a specific bug where RPC sockets
created by the kernel during TCP NFS serving are unlabeled.
James Morris [Sat, 8 May 2004 08:00:33 +0000 (01:00 -0700)]
[NET]: Add sock_create_kern()
Under SELinux, and potentially other LSMs, we need to be able to
distinguish between user sockets and kernel sockets. For SELinux
specifically, kernel sockets need to be specially labeled during creation,
then bypass access control checks (they are controlled by the kernel
itself and not subject to SELinux mediation).
This addresses a class of potential issues in SELinux where, for example,
a TCP NFS session times out, then the kernel re-establishes an RPC
connection upon further user activity. We do not want such kernel
created sockets to be labeled with user security contexts.
sock_create() and sock_create_kern() are wrapper functions, which seems
semantically clearer to me than e.g. adding a flag to sock_create(). If
you prefer the latter, then let me know.
The patch also adds an argument to the LSM socket creation functions
indicating whether the socket being created is a kernel socket or not.
Andrew Morton [Sat, 8 May 2004 03:43:30 +0000 (20:43 -0700)]
[PATCH] fix WARN_ON on XFS module unload
From: Christoph Hellwig <hch@lst.de>
This one is a little funny. The SGI trees don't show this issue because dmapi
and quota are separate modules so they must be unloaded before xfs_fs_exit can
be called at all.
So let's move the exitcalls for them in mainline first to simulate that
behaviour.
This patch fixes a bug in the pmac-zilog driver where if you enable
CRTSCTS mode, it won't output data when CTS is asserted. On
powermacs, the CTS input is inverted. It also fixes a logic bug in
testing for CTS and DCD changes.
NTFS: 2.1.8 release - If the $LogFile indicates a clean shutdown and a
read-write (re)mount is requested, empty $LogFile by overwriting it
with 0xff bytes to ensure that Windows cannot cause data corruption
by replaying a stale journal after Linux has written to the volume.
NTFS: Read the journal ($LogFile) and determine if the volume has been shutdown cleanly
and force a read-only mount if not (fs/ntfs/super.c and fs/ntfs/logfile.c). This
is a little bit of a crude check in that we only look at the restart areas and
not at the actual log records so that there will be a very small number of cases
where we think that a volume is dirty when in fact it is clean. This should only
affect volumes that have not been shutdown cleanly and did not have any pending,
non-check-pointed i/o.
Stas Sergeev [Fri, 7 May 2004 02:35:35 +0000 (19:35 -0700)]
[PATCH] Fix IO bitmap invalidate
There is a bug where if any process that obtained an IO access
permissions via ioperm() does not explicitly "drop" that permissions,
the IO permissions don't get properly invalidated on process exit.
The cause is that exit_thread() only invalidates the per-thread
io_bitmap pointer, but doesn't invalidate the per-TSS io_bitmap pointer
as well.
As the per-thread pointer is invalidated, __switch_to() doesn't take
care of that one either, so the per-TSS pointer stays valid as long as
some other process does ioperm().
This fixes the problem - it invalidates the per-TSS io_bitmap pointer
and the problem goes away.
When Patrick removed ide_notify_reboot() in 2.5.42, he didn't notice
that it meant that IDE no longer had any shutdown() functionality.
So we did the right thing on suspend, but not on shutdown.
ide_notify_reboot() was only doing STANDBY on shutdown (because FLUSH
'doesn't work' in 2.4 too) but it worked okay and we still should do STANDBY
on shutdown because some broken disks flush their caches.
Thus just calls bus->suspend() (FLUSH+STANDBY) at shutdown time. We can
add some safety delay later - 2.4 doesn't have any.
I've updated the logips2pp driver to detect the MX310 and MX510 mice
and also made it more maintainable by putting everything into one
table instead of having 4 arrays for them (the MX700 support wasn't
added correctly in the last revision).
[PATCH] IDE disk cache flush at unopportune momemnts
This makes the idedisk_release function only flush the cache on final
release; with the recent 2.6 blocklayer updates release gets called
somewhat frequently, and at times where IO is outstanding to the disk.
This bug didn't trigger before simply because ide_cacheflush_p() always
was a nop.
Nitin A. Kamble [Thu, 6 May 2004 23:26:06 +0000 (16:26 -0700)]
[PATCH] mxcsr patch for i386 & x86-64
This enables proper mxcsr register masking: the magic mask "0xffbf"
is not necessarily correct for all CPU's, and there is an architected
way to discover the proper MXCSR feature bits by examining the fxsave
results.
Please refer to IA32 Software Developer's Manual, Volume 1, Section
11.6.6 for more details.
Petr Vandrovec [Thu, 6 May 2004 03:22:19 +0000 (20:22 -0700)]
[PATCH] ncpfs data corruption when using large TCP transfers
ncpfs was forgetting to update iovec's iov_base field whenever partial
transmission occured. This was causing data corruption during large
(60kB) writes.
The code now also passes copy of iovec to the sock_sendmsg, so it does
not rely on network stack updating (or not updating) passed iovec in
case of success (or failure).
Paul Wagland [Thu, 6 May 2004 00:50:40 +0000 (17:50 -0700)]
[PATCH] bug fix for megaraid memory leak
I was going through the code looking for bits and pieces to pull across
into the new LSI Logic beta megaraid driver /sys fs code and came across
this one.
LSI Logic have already fixed this issue for the 2.4 driver, and the new
beta driver does not use the /proc filesystem at all, so no problem
there.
The problem is that resources are not freed upon certain error
conditions in the in-kernel megaraid driver, to quote from Lester
Hightower (who originally found the issue):
"The problem occurs only in the circumstance where one reads one of
the /proc/megaraid/hba<X>/diskdrives-ch<N> files where the card <X>
does not have channel <N> on it. Most people would likely not
notice this leak in normal operation, but due to the way that we
monitor our MegaRaid cards in our company (we read these /proc
entries every 180s) so we found the leak rather quickly, and
unpleasantly (when your kernel eats all your RAM)."
Anyway, here is the fix, compiled and tested OK for me.
From: Alan Cox <alan@redhat.com>, Arjan van de Ven <arjanv@redhat.com>
- calculate drive->wcache for non-removable disks too
- flush the cache before unlocking the door on removable media,
otherwise you have a small race with the human
There is an bug in bigsmp sub-architecture, due to which it will not
enable all the CPUs when the BIOS-APICIDs are not 0 to n-1 (where n is
total number of CPUs). Particularly, only 2 CPU comes up on a system
that has 4 CPUs with BIOS APICID as (0, 1, 6, 7).=20
The bug is root caused to check_apicid_present(bit) call in smpboot.c,
when bigsmp is expecting apicid in place of bit.
check_apicid_present(bit) in bigsmp subarchitecture checks the bit with
phys_id_present_map (which is actually map representing all apicids and
not bit).
One solution is to change check_apicid_present(bit) to
check_apicid_present(apicid), in smp_boot_cpus(). But, it can affect
all the other subarchitectures in various subtle ways. So, here is a
simple alternate fix (Thanks to Martin Bligh), which solves the above
problem.
[ Confirmation from Martin:
Looks fine, it's exactly the same fix we use for Summit. Since
we're using the other method instead of the bitmap, this check
isn't needed, so we can just bypass it. This way also has the
great advantage of being isolated to the bigsmp subarch, so it only
needs testing there ;-)
]
Andrew Morton [Wed, 5 May 2004 09:46:18 +0000 (02:46 -0700)]
[PATCH] cciss update
From: <mikem@beardog.cca.cpqcorp.net>
This patch adds support for 2 new controllers. The first is a PCI-Express
version of the 6400. The second is actually a SATA controller using the cciss
interface.
[PATCH] fixup for C1 Halt Disconnect problem on nForce2 chipsets
Based on information provided by "Allen Martin" <AMartin@nvidia.com>:
A hang is caused when the CPU generates a very fast CONNECT/HALT cycle
sequence. Workaround is to set the SYSTEM_IDLE_TIMEOUT to 80 ns.
This allows the state-machine and timer to return to a proper state within
80 ns of the CONNECT and probe appearing together. Since the CPU will not
issue another HALT within 80 ns of the initial HALT, the failure condition
is avoided.
[PATCH] allow drivers to claim the lapic NMI watchdog HW
Here is an updated lapic NMI ownership tracking patch which
should address the issues that were raised with the first one:
- Simplified the API function names to {reserve,release}_lapic_nmi().
- Rewrote the ownership tracking code to use two individually named
flags instead of using arithmetic and the sign. The code is now
simple enough that no "hiding" macros are needed. (Thanks Albert
for that suggestion.)
Gerd Knorr [Wed, 5 May 2004 01:16:54 +0000 (18:16 -0700)]
[PATCH] Fix oops in video_register_device
degerrit@web.de wrote:
"I caused an oops in unusual circumstances by accidentally "forcing" a
video device number which was too high or already taken (don't know
which). I assume this probably shouldn't give an oops (though it was my
fault), so here's a bugreport..."
Fixed by adding a range check for the number passed in by the driver.
This adds some initial support for the latest model of iBook G4 (still
need some work on the clock chip at least and some radeonfb updates that
I'll send later along with other fixes for this driver).
It also removes a useless delay and fixes detection of the airport card
on the "Windtunnel" class desktop G4 machines.
[PATCH] ppc/ppc64: Cleanup PPC970 CPU initialization
This cleans up the code used to initialize the 970 CPU.
More specifically, it adds support for the 970FX, makes sure we don't
touch registers we aren't supposed to when running in LPAR mode, and
stop blindly zeroing out HID4 and HID5, we just clear the bits we really
want clear in there and leave the rest to the firmware.
Chris Wright [Tue, 4 May 2004 11:48:34 +0000 (04:48 -0700)]
[PATCH] fix queues_count accounting in mqueue_delete_inode()
During mqueue_get_inode(), it's possible that kmalloc() of the
info->messages array will fail. This failure mode will cause the
queues_count to be (incorrectly) decremented twice. This patch uses
info->messages on mqueue_delete_inode() to determine whether the
mqueue was every truly created, and hence proper accounting is needed
on destruction.
Alex Williamson [Tue, 4 May 2004 17:18:13 +0000 (18:18 +0100)]
[SERIAL] 8250_hcdp needs irq sharing
Patch from Alex Williamson
Here's a trivial patch that makes 8250_hcdp setup the correct flags
when IRQ sharing is enabled for serial ports.
The HCDP table tells us if the device is a PCI UART. We can use this
to set the shared interrupt flag as well as program the interrupt with
the correct polarity/trigger (should get rid of "changing vector <x>
from IO-SAPIC-edge to IO-SAPIC-level" messages at bootup). This also
allows non-PCI UARTs to be left un-shareable, which is likely much
more safe (edge triggered).
The bit that I'm keying on is still part of the older 1.0a HCDP spec,
so should be implemented (it was on all the boxes I tested). If
there's firmware out there that doesn't set this bit or the interrupt
supported flag, the HCDP UART may run in polling mode, but should
still be functional.
projects / linux / log