Seems that both Greg and I submitted the same patch and it just kept on
applying...
Cc: Greg KH <greg@kroah.com>
Cc: Kumar Gala <galak@freescale.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
If there are devices that use interrupts over a suspend event, ACPI must
restore the PCI interrupt links on resume. Anything else breaks any
device that hasn't been converted to the new (dubious) PM rules.
Drivers that need the irq free/re-aquire sequence can be done one by one
independently of this one.
There's no real guarantee that handle_mm_fault() will always be able to
break a COW situation - if an update from another thread ends up
modifying the page table some way, handle_mm_fault() may end up
requiring us to re-try the operation.
That's normally fine, but get_user_pages() ended up re-trying it as a
read, and thus a write access could in theory end up losing the dirty
bit or be done on a page that had not been properly COW'ed.
This makes get_user_pages() always retry write accesses as write
accesses by making "follow_page()" require that a writable follow has
the dirty bit set. That simplifies the code and solves the race: if the
COW break fails for some reason, we'll just loop around and try again.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Reported by: Jochen Hein (Bugzilla Bug 4312)
When there is disk I/O happening, the framebuffer has a little snow on
the screen. Once I/O has finished, no garbage remains on screen.
This bug was explained by: Knut Petersen
Most important is CRTC register 2f, signal quality is also improved for
higher vclk values by changing set_vclk() according to the X drivers and
cyblafb.c
The fix is to set the performance register (0x2f) with a more stable
value.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Reported by: Jochen Hein (Bugzilla Bug 4386)
booting leaves the end of long lines in the last line on screen when
scrolling. When X is running, scrolling puts garbage on the screen
(looks like X data) Console switch fixes the screen. Behaviour seems to
be identical with noaccel and without on the video=tridentfb parameter
in lilo.conf.
This bug was explained by: Knut_Petersen
Acceleration is broken for all BLADE 3D chips for all versions of kernel
2.6 except for 32bit modes. Most important reason is that the u32 col
parameter of the graphics engine needs the color value replicated to all
u8 of the u32 (8bit modes) and to both u16 of the u32.
Fix color value passed to graphics engine, verified by the reporter.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This removes sys_set_zone_reclaim() for now. While i'm sure Martin is
trying to solve a real problem, we must not hard-code an incomplete and
insufficient approach into a syscall, because syscalls are pretty much
for eternity. I am quite strongly convinced that this syscall must not
hit v2.6.13 in its current form.
Firstly, the syscall lacks basic syscall design: e.g. it allows the
global setting of VM policy for unprivileged users. (!) [ Imagine an
Oracle installation and a SAP installation on the same NUMA box fighting
over the 'optimal' setting for this flag. What will they do? Will they
try to set the flag to their own preferred value every second or so? ]
Secondly, it was added based on a single datapoint from Martin:
http://marc.theaimsgroup.com/?l=linux-mm&m=111763597218177&w=2
where Martin characterizes the numbers the following way:
' Run-to-run variability for "make -j" is huge, so these numbers aren't
terribly useful except to see that with reclaim the benchmark still
finishes in a reasonable amount of time. '
in other words: the fundamental problem has likely not been solved, only
a tendential move into the right direction has been observed, and a
handful of numbers were picked out of a set of hugely variable results,
without showing the variability data. How much variance is there
run-to-run?
I'd really suggest to first walk the walk and see what's needed to get
stable & predictable kernel compilation numbers on that NUMA box, before
adding random syscalls to tune a particular aspect of the VM ... which
approach might not even matter once the whole picture has been analyzed
and understood!
The third, most important point is that the syscall exposes VM tuning
internals in a completely unstructured way. What sense does it make to
have a _GLOBAL_ per-node setting for 'should we go to another node for
reclaim'? If then it might make sense to do this per-app, via numalib or
so.
The change is minimalistic in that it doesnt remove the syscall and the
underlying infrastructure changes, only the user-visible changes. We
could perhaps add a CAP_SYS_ADMIN-only sysctl for this hack, a'ka
/proc/sys/vm/swappiness, but even that looks quite counterproductive
when the generic approach is that we are trying to reduce the number of
external factors in the VM balance picture.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The ordering of setting and clearing device_add_pending went wrong on some
occasions, causing multifunction cards only to be handled correctly on the
first insertion, not on subsequent ones.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Avoid registering PCMCIA CF cards before other IDE stuff. This means the risk
of /dev/hd* being re-ordered is lessened. The _sane_ thing to assert any
ordering is to use udev, nameif and so on, of course.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
When you rm a watch, an IN_IGNORED event is sent down the event queue
with the watch descriptor that you just rm'd.
If you then add a watch you could get the ignored watch's wd and if you
haven't read the entire event queue, user space will think that it's
newly created watch was just ignored.
To avoid this problem we just use idr_get_new_above instead of
idr_get_new.
Signed-off-by: John McCutchan <ttb@tentacle.dhs.org>
Signed-off-by: Robert Love <rml@novell.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
When a file is moved over an existing file that you are watching,
inotify won't send you a DELETE_SELF event and it won't unref the inode
until the inotify instance is closed by the application.
Signed-off-by: John McCutchan <ttb@tentacle.dhs.org>
Signed-off-by: Robert Love <rml@novell.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch displays the name of the fbdev driver in sysfs.
Down the road this will replace the current proc handle we have.
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Drivers really only work well in SMP if they actually can be selected.
This is a leftover from the time when the 6pack drive only used to be
a bitrotten variant of the slip driver.
Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
Kconfig | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
--ReaqsoxgOBHFXBhH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi Jeff,
Here's a little patch fixing a typo in smc91x.h.
Regards,
Tony
--ReaqsoxgOBHFXBhH
Content-Type: text/x-chdr; charset=us-ascii
Content-Disposition: inline; filename="patch-fix-typo-smc91x.h"
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Yukon-Lite chipset needs workaround for revision 7 (or later).
Without this patch, chip gets stuck in low power mode and never
boots. Newer SysKonnect vendor code already had same patch.
Related bug in skge is http://bugs.gentoo.org/87822
Chris, please add for 2.6.12.2
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Contains general updates (additional configuration info, hopefully
better examples, updated some out of date info, and a bonus pass
through ispell to banish the "paramters.") and info specific to
gratuitous ARP and xmit policy functionality already in 2.6.13-rc2.
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
SCSI=m must disallow static drivers.
The problem is that all the SATA drivers depend on SCSI_SATA.
With SCSI=m and SCSI_SATA=y this allows the static enabling of the SATA
drivers with unwanted effects, e.g.:
- SCSI=m, SCSI_SATA=y, SCSI_ATA_ADMA=y
-> SCSI_ATA_ADMA is built statically but scsi/built-in.o is not linked
into the kernel
- SCSI=m, SCSI_SATA=y, SCSI_ATA_ADMA=y, SCSI_SATA_AHCI=m
-> SCSI_ATA_ADMA and libata are built statically but
scsi/built-in.o is not linked into the kernel,
SCSI_SATA_AHCI is built modular (unresolved symbols due to missing
libata)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Cc: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Cleanup code that is used to toggle LED's. Since we
get called from ethtool, can use that thread rather than
setting up a timer.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
During autonegotiation set PHY interrupt mask to ignore
bogus speed change interrupts.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
The code to clear fifo errors was incorrect and sending garbage
to the external phy. Removed the no longer used inline's funcs.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
The check for Yukon lite changes was restricting itself to
rev A3. It turns out that these changes are also true on A4
and later.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Cleanup the phy_lock deadlock because of relocking in the nway_reset path.
Reported by Francois Romieu.
Also, don't need to do irqsave/restore for blink,
just excluding bh is good enough.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Here is a fix for a typo, thanks Eliot Dresselhaus.
Since transmitter not active when device is down, it wasn't really noticed.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
The SK-9E boards use the Marvell Yukon2 chipset which
is not supported by the skge driver. Thanks to Ralph Roesler
for noticing.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Using Genesis board, I get harmless error reports. Rather than console
error, turn it into a error counter.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
The bug is evident when it is seen once. dst gc timer was backed off,
when gc queue is not empty. But this means that timer quickly backs off,
if at least one destination remains in use. Normally, the bug is invisible,
because adding new dst entry to queue cancels the backoff. But it shots
deadly with destination cache overflow when new destinations are not released
for long time f.e. after an interface goes down.
The fix is to cancel backoff when something was released.
Signed-off-by: Denis Lunev <den@sw.ru>
Signed-off-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Tunnel modules used to obtain module refcount each time when
some tunnel was created, which meaned that tunnel could be unloaded
only after all the tunnels are deleted.
Since killing old MOD_*_USE_COUNT macros this protection has gone.
It is possible to return it back as module_get/put, but it looks
more natural and practically useful to force destruction of all
the child tunnels on module unload.
Signed-off-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
masq_index is used for cleanup in case the interface address changes
(such as a dialup ppp link with dynamic addreses). Without this patch,
slave connections are not evicted in such a case, since they don't inherit
masq_index.
Signed-off-by: Harald Welte <laforge@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
ACPI is wrong. Devices should not release their IRQ's on suspend and
re-aquire them on resume. ACPI should just re-init the IRQ controller
instead of breaking most drivers very subtly.
Breakage reported by Hugh Dickins <hugh@veritas.com>
Undo: d8c4b4195c
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
An early version of the sk98lin patch was merged via Len's tree. But there
were subsequent updates as a result of review from Jeff. THis fixes things
up.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Jeff Garzik <jgarzik@pobox.com>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The patch adds boundary check for the MAX_GSI_NUM. Same as the update for
i386, the patch addresses a problem with ACPI SCI IRQ. The patch corrects
the code such that SCI IRQ is skipped and duplicate entry is avoided. The
VIA chipset uses 4-bit IRQ register for internal interrupt routing, and
therefore cannot handle IRQ numbers assigned to its devices. The patch
corrects this problem by allowing PCI IRQs below 16.
Signed-off-by: Natalie Protasevich <Natalie.Protasevich@unisys.com>
Acked-by: Andi Kleen <ak@muc.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This snuck in with an x86_64 change. Thanks to Richard Purdie
<rpurdie@rpsys.net> for spotting it.
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I was observing reproducible crashes on the "movw %bx,(%rsi)" instruction
below while a process in a recvfrom() system call was copying packet data
to user space. The patch below fixes the exception table and causes the
crash to no longer reproduce. Please apply.
Acked-by: Andi Kleen <ak@muc.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Fix 44x early serial debugging for big RAM configurations (more than 512M).
We cannot use default OpenBIOS virtual mapping, because it interferes with
pinned TLB entry.
While we are at it, move early UART mapping to TLB slot 0, so it can
survive longer during boot process (slot 1 is used by the first ioremap
call, effectively killing UART mapping if it occupies this slot). Also,
change UART TLB entry size to 4K (256M is too much for a bunch of registers
:). Squash some warnings on the way.
Tested on Ebony and Ocotea with 1G of RAM.
Thanks to Scott Coulter <scott.coulter@cyclone.com> for diagnosing this
problem.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We are iterating over all nodes in nr_free_zone_pages(). Because the
fallback zonelists contain all nodes in the system, and we walk all the
zonelists, we're counting memory multiple times (once for each node). This
caused us to make a size estimate of 32GB for an 8GB AMD64 box, which makes
all the dirty ratio calculations, etc incorrect.
There's still a further bug to fix from e820 holes causing overestimation
as well, but this fix is separate, and good as is, and fixes one class of
problems. Problem found by Badari, and tested by Ram Pai - thanks!
Signed-off-by: Martin J. Bligh <mbligh@mbligh.org>
Signed-off-by: Matt Dobson <colpatch@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
inotify system call support for PPC64
[ I don't think we need sys32 compatibility versions--and if we do, I
failed in life. ]
Signed-off-by: Robert Love <rml@novell.com>
Acked-by: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add inotify system call stubs to PPC32.
Signed-off-by: Robert Love <rml@novell.com>
Acked-by: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add reference count and disable ACPI PCI Interrupt Link
when no device still uses it.
Warn when drivers have not released Link at suspend time.
http://bugzilla.kernel.org/show_bug.cgi?id=3469
Signed-off-by: David Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Otherwise a platform that supports ACPI based cpufreq
and boots up at lowest possible speed could stay there
forever. This because the governor may request max speed,
but the code doesn't update if there is no change in
speed, and it assumed the initial state of max speed.
http://bugzilla.kernel.org/show_bug.cgi?id=4634
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
EC burst mode benefits many machines, some of
them significantly. However, our current
implementation fails on some machines such
as Rafael's Asus L5D.
This patch restores the alternative EC polling code,
which can be enabled at boot time via "ec_polling"
http://bugzilla.kernel.org/show_bug.cgi?id=4665
Signed-off-by: Luming Yu <luming.yu@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>