| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Disable Vista compatibility for Sony VGN-NS50B_L.
https://bugzilla.kernel.org/show_bug.cgi?id=12904#c46
Note that this change is a workaround, not a permanent fix.
For the permanent fix is to figure out what compatibility
means and to actually be compatible...
Tested-by: Voldemar <[email protected]>
Signed-off-by: Zhang Rui <[email protected]>
Signed-off-by: Len Brown <[email protected]>
|
|
The code block braced with CONFIG_ACPI_PROCFS is unblanced. When
CONFIG_ACPI_PROCFS=n, kernel trace will be produced like:
Call Trace:
[<c111637d>] ? remove_proc_entry+0x20d/0x290
[<c111637d>] ? remove_proc_entry+0x20d/0x290
[<c103b02c>] warn_slowpath_common+0x6c/0xc0
[<c111637d>] ? remove_proc_entry+0x20d/0x290
[<c103b0c6>] warn_slowpath_fmt+0x26/0x30
[<c111637d>] remove_proc_entry+0x20d/0x290
[<c1116bd7>] ? proc_register+0x117/0x1f0
[<c1116e83>] ? proc_mkdir_mode+0x33/0x50
[<c14f483c>] ? acpi_fan_init+0x0/0x2c
[<c14f485f>] acpi_fan_init+0x23/0x2c
[<c1001123>] do_one_initcall+0x23/0x180
[<c107dcf7>] ? init_irq_proc+0x67/0x80
[<c14d43bd>] kernel_init+0x13c/0x20e
[<c1030e50>] ? schedule_tail+0x20/0x90
[<c1389e06>] ? syscall_exit+0x5/0x16
[<c14d4281>] ? kernel_init+0x0/0x20e
[<c14d4281>] ? kernel_init+0x0/0x20e
[<c10032f6>] kernel_thread_helper+0x6/0x30
---[ end trace a7919e7f17c0a725 ]---
Then also bracket later error checking code with ACPI_PROCFS
option to avoid mismatch problem.
Signed-off-by: Liang Li <[email protected]>
Signed-off-by: Len Brown <[email protected]>
|
|
https://bugzilla.kernel.org/show_bug.cgi?id=13931 describes a bug where
a system fails to successfully resume after the second suspend. Maxim
Levitsky discovered that this could be rectified by forcibly saving
and restoring the ACPI non-volatile state. The spec indicates that this
is only required for S4, but testing the behaviour of Windows by adding
an ACPI NVS region to qemu's e820 map and registering a custom memory
read/write handler reveals that it's saved and restored even over suspend
to RAM. We should mimic that behaviour to avoid other broken platforms.
Signed-off-by: Matthew Garrett <[email protected]>
Signed-off-by: Len Brown <[email protected]>
|
|
Saving platform non-volatile state may be required for suspend to RAM as
well as hibernation. Move it to more generic code.
Signed-off-by: Matthew Garrett <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Tested-by: Maxim Levitsky <[email protected]>
Signed-off-by: Len Brown <[email protected]>
|
|
* master.kernel.org:/home/rmk/linux-2.6-arm:
ARM: 6164/1: Add kto and kfrom to input operands list.
ARM: 6166/1: Proper prefetch abort handling on pre-ARMv6
ARM: 6165/1: trap overflows on highmem pages from kmap_atomic when debugging
ARM: 6152/1: ux500 make it possible to disable localtimers
[ARM] pxa/spitz: Correctly register WM8750
[ARM] pxa/palmtc: storage class should be before const qualifier
ARM: 6146/1: sa1111: Prevent deadlock in resume path
ARM: 6145/1: ux500 MTU clockrate correction
ARM: 6144/1: TCM memory bug freeing bug
ARM: VFP: Fix vfp_put_double() for d16-d31
|
|
Checking to se if the IO daisy chain is enabled should be checking the
PM_WKEN register, not the PM_WKST register. Reading PM_WKST tells us
if an event occurred, not whether or not it is enabled.
Apparently, we've been lucky until now in that a pending event has not
been there during enable. However, on 3630/Zoom3, I noticed because
of the WARN that this timeout was always happening.
Signed-off-by: Kevin Hilman <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
The addition of the new debounce code (commit
168ef3d9a56bd8bffe0ef4189c450888b4aefefe) broke the auto-disable of
debounce clocks on idle by forgetting to update the debounce clock
enable mask.
Add back the updating of bank->dbck_enable_mask so debounce clocks are
auto-disabled.
Signed-off-by: Kevin Hilman <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
The kernel timer queue is being run currently from a GP timer running in a one
shot mode, which works in a way that when it expires, it will also stop.
Usually during this situation, the interrupt handler will ack the interrupt,
load a new value to the timer and start it again. During suspend, the
situation is slightly different, as we disable interrupts just before
timekeeping is suspended, which leaves a small window where the timer can
expire before it is stopped, and will leave the interrupt flag pending.
This pending interrupt will prevent ARM sleep entry, thus now we ack it always
when we are attempting to stop a timer.
Signed-off-by: Tero Kristo <[email protected]>
Acked-by: Kevin Hilman <[email protected]>
[[email protected]: removed the ifdef to make the patch cover omap1 also]
Signed-off-by: Tony Lindgren <[email protected]>
|
|
Based on Intel Vol3b (March 2010), the event
SNOOPQ_REQUEST_OUTSTANDING is restricted to counters 0,1 so
update the event table for Intel Westmere accordingly.
Signed-off-by: Stephane Eranian <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: <[email protected]> # .34.x
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
When processing events we want to give visual feedback to the user when
using the newt browser, so there are ui_progress calls in
__perf_session__process_events, but those should check if newt is being
used.
Reported-by: Srikar Dronamraju <[email protected]>
Tested-by: Srikar Dronamraju <[email protected]>
Cc: Ananth N Mavinakayanahalli <[email protected]>
Cc: Frédéric Weisbecker <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Masami Hiramatsu <[email protected]>,
Cc: Peter Zijlstra <[email protected]>
Cc: Srikar Dronamraju <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Tom Zanussi <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
Reported-by: Stephen Rothwell <[email protected]>
Signed-off-by: Michal Marek <[email protected]>
|
|
|
|
In commit 1f8438a85366 (icmp: Account for ICMP out errors), I did a typo
on IPV6 side, using ICMP6_MIB_OUTMSGS instead of ICMP6_MIB_OUTERRORS
Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Realtek confirmed that a 20us delay is needed after mdio_read and
mdio_write operations. Reduce the delay in mdio_write, and add it
to mdio_read too. Also add a comment that the 20us is from hw specs.
Signed-off-by: Timo Teräs <[email protected]>
Acked-by: Francois Romieu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
|
|
Since commit cc772ab7cdcaa24d1fae332d92a1602788644f7a ("gianfar: Add
hardware RX timestamping support"), the driver no longer works on
at least MPC8313ERDB and MPC8568EMDS boards (and possibly much more
boards as well).
That's how MPC8313 Reference Manual describes RCTRL_TS_ENABLE bit:
Timestamp incoming packets as padding bytes. PAL field is set
to 8 if the PAL field is programmed to less than 8. Must be set
to zero if TMR_CTRL[TE]=0.
I see that the commit above sets this bit, but it doesn't handle
TMR_CTRL. Manfred probably had this bit set by the firmware for
his boards. But obviously this isn't true for all boards in the
wild.
Also, I recall that Freescale BSPs were explicitly disabling the
timestamping because of a performance drop.
For now, the best way to deal with this is just disable the
timestamping, and later we can discuss proper device tree bindings
and implement enabling this feature via some property.
Signed-off-by: Anton Vorontsov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
The extra ! character means that these conditions are always false.
Signed-off-by: Dan Carpenter <[email protected]>
Acked-by: Sjur Braendeland <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
This patch implements a work around for Erratum 5, "3.3 V Fiber Speed
Selection." If the hardware wiring does not respect this erratum, then
fiber optic mode will not work properly.
Signed-off-by: Richard Cochran <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Patch is against latest Linus master branch and is expected to be
safe bug fix.
You get:
ACPI: HARDWARE addr space,NOT supported yet
for each ACPI defined CPU which status is active, but exceeds
maxcpus= count.
As these "not booted" CPUs do not run an idle routine
and echo X >/proc/acpi/processor/*/throttling did not work
I couldn't find a way to really access not onlined/booted
machines. Still this should get fixed and
/proc/acpi/processor/X dirs of cores exceeding maxcpus
should not show up.
I wonder whether this could get cleaned up by truncating possible cpu mask
and nr_cpu_ids to setup_max_cpus early some day
(and not exporting setup_max_cpus anymore then).
But this needs touching of a lot other places...
Signed-off-by: Thomas Renninger <[email protected]>
CC: [email protected]
CC: [email protected]
CC: [email protected]
Signed-off-by: Len Brown <[email protected]>
|
|
Generating the file in make modules_install was broken as well, because
it didn't work in a readonly filesystem and otherwise it generated a
root-owned file which is not wanted.
Reported-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Michal Marek <[email protected]>
|
|
When I introduced the global variable gsi_end I thought gsi_end on
io_apics was one past the end of the gsi range for the io_apic. After
it was pointed out the the range on io_apics was inclusive I changed
my global variable to match. That was a big mistake. Inclusive
semantics without a range start cannot describe the case when no gsi's
are allocated. Describing the case where no gsi's are allocated is
important in sfi.c and mpparse.c so that we can assign gsi numbers
instead of blindly copying the gsi assignments the BIOS has done as we
do in the acpi case.
To keep from getting the global variable confused with the gsi range
end rename it gsi_top.
To allow describing the case where no gsi's are allocated have gsi_top
be one place the highest gsi number seen in the system.
This fixes an off by one bug in sfi.c:
Reported-by: jacob pan <[email protected]>
This fixes the same off by one bug in mpparse.c:
This fixes an off unreachable by one bug in acpi/boot.c:irq_to_gsi
Reported-by: Yinghai <[email protected]>
Signed-off-by: Eric W. Biederman <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
|
|
BugLink: http://bugs.launchpad.net/bugs/591416
There are a number of network drivers (bridge, bonding, etc) that are not yet
receive multi-queue enabled and use alloc_netdev(), so don't print a
num_rx_queues imbalance warning in that case.
Also, only print the warning once for those drivers that _are_ multi-queue
enabled.
Signed-off-by: Tim Gardner <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
|
|
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (21 commits)
mac80211: fix deauth before assoc
iwlwifi: add missing rcu_read_lock
mac80211: fix function pointer check
wireless: remove my name from the maintainer list
ath5k: fix NULL pointer in antenna configuration
p54usb: Add device ID for Dell WLA3310 USB
wl1251: fix a memory leak in probe
ipmr: dont corrupt lists
8139too: fix buffer overrun in rtl8139_init_board
asix: check packet size against mtu+ETH_HLEN instead of ETH_FRAME_LEN
r8169: fix random mdio_write failures
ip6mr: fix a typo in ip6mr_for_each_table()
iwlwifi: move sysfs_create_group to post request firmware
iwlwifi: add name to Maintainers list
iwl3945: fix internal scan
iwl3945: enable stuck queue detection on 3945
ipv6: avoid high order allocations
ath5k: retain promiscuous setting
ath5k: depend on CONFIG_PM_SLEEP for suspend/resume functions
mac80211: process station blockack action frames from work
...
|
|
* 'for-2.6.35' of git://linux-nfs.org/~bfields/linux:
nfsd4: shut down callback queue outside state lock
nfsd: nfsd_setattr needs to call commit_metadata
|
|
Reinstate the null behaviour that the in-kernel gdbstub had for the GDB
remote protocol 'p' command (retrieve a single register value) prior to
commit 7ca8b9c0dafd ("frv: extend gdbstub to support more features of
gdb").
Before that, the 'p' command just returned an empty reply, which causes
gdb to then go and use the 'g' command. However, since that commit, the
'p' command returns an error string, which causes gdb to abort its
connection to the target.
Not all gdb versions are affected, some use try 'g' first, and if that
works, don't bother with 'p', and so don't see the error.
Signed-off-by: David Howells <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
|
|
* 'msm-urgent' of git://codeaurora.org/quic/kernel/dwalker/linux-msm:
mmc: msm: fix compile error on MSM7x30
msm: dma: add completion.h header
|
|
* 'for-linus' of git://git.monstr.eu/linux-2.6-microblaze:
microblaze: Fix sg_dma_len() regression
microblaze: Define ARCH_SLAB_MINALIGN to fix slab crash
|
|
MSM7x30 isn't supported in this driver yet. If ones tried to compile it in
with MSM7x30 configure you get,
linux-2.6/drivers/mmc/host/msm_sdcc.c: In function 'msmsdcc_fifo_addr':
linux-2.6/drivers/mmc/host/msm_sdcc.c:165: error: 'MSM_SDC1_PHYS' undeclared (first use in this function)
linux-2.6/drivers/mmc/host/msm_sdcc.c:165: error: (Each undeclared identifier is reported only once
linux-2.6/drivers/mmc/host/msm_sdcc.c:165: error: for each function it appears in.)
linux-2.6/drivers/mmc/host/msm_sdcc.c:167: error: 'MSM_SDC2_PHYS' undeclared (first use in this function)
linux-2.6/drivers/mmc/host/msm_sdcc.c:169: error: 'MSM_SDC3_PHYS' undeclared (first use in this function)
linux-2.6/drivers/mmc/host/msm_sdcc.c:171: error: 'MSM_SDC4_PHYS' undeclared (first use in this function)
So we add a Kconfig check to prevent this.
Signed-off-by: Daniel Walker <[email protected]>
|
|
10, 233 is allocated officially to /dev/kmview which is shipping in
Ubuntu and Debian distributions. vhost_net seem to have borrowed it
without making a proper request and this causes regressions in the other
distributions.
vhost_net can use a dynamic minor so use that instead. Also update the
file with a comment to try and avoid future misunderstandings.
cc: [email protected]
Signed-off-by: Alan Cox <[email protected]>
[ We should have caught this before 2.6.34 got released. - Linus ]
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Add a spin_unlock missing on the error path.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression E1;
@@
* spin_lock(E1,...);
<+... when != E1
if (...) {
... when != E1
* return ...;
}
...+>
* spin_unlock(E1,...);
// </smpl>
Signed-off-by: Julia Lawall <[email protected]>
Signed-off-by: Avi Kivity <[email protected]>
|
|
This is obviously a left-over from the the old interface taking the
size. Apparently a mostly harmless issue with the current iommu_unmap
implementation.
Signed-off-by: Jan Kiszka <[email protected]>
Acked-by: Joerg Roedel <[email protected]>
Signed-off-by: Avi Kivity <[email protected]>
|
|
If cr0.wp=0, we have to allow the guest kernel access to a page with pte.w=0.
We do that by setting spte.w=1, since the host cr0.wp must remain set so the
host can write protect pages. Once we allow write access, we must remove
user access otherwise we mistakenly allow the user to write the page.
Reviewed-by: Xiao Guangrong <[email protected]>
Signed-off-by: Avi Kivity <[email protected]>
|
|
Always invalidate spte and flush TLBs when changing page size, to make
sure different sized translations for the same address are never cached
in a CPU's TLB.
Currently the only case where this occurs is when a non-leaf spte pointer is
overwritten by a leaf, large spte entry. This can happen after dirty
logging is disabled on a memslot, for example.
Noticed by Andrea.
KVM-Stable-Tag
Signed-off-by: Marcelo Tosatti <[email protected]>
Signed-off-by: Avi Kivity <[email protected]>
|
|
This patch implements a workaround for AMD erratum 383 into
KVM. Without this erratum fix it is possible for a guest to
kill the host machine. This patch implements the suggested
workaround for hypervisors which will be published by the
next revision guide update.
[jan: fix overflow warning on i386]
[xiao: fix unused variable warning]
Cc: [email protected]
Signed-off-by: Joerg Roedel <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Signed-off-by: Xiao Guangrong <[email protected]>
Signed-off-by: Avi Kivity <[email protected]>
|
|
This patch moves handling of the MC vmexits to an earlier
point in the vmexit. The handle_exit function is too late
because the vcpu might alreadry have changed its physical
cpu.
Cc: [email protected]
Signed-off-by: Joerg Roedel <[email protected]>
Signed-off-by: Avi Kivity <[email protected]>
|
|
kvmppc_e500_exit() is a module_exit function, so it should be tagged
with __exit, not __init. The incorrect annotation was added by commit
2986b8c72c272ea58edd37903b042c6da985627d.
Signed-off-by: Jean Delvare <[email protected]>
Cc: [email protected]
Signed-off-by: Alexander Graf <[email protected]>
Signed-off-by: Avi Kivity <[email protected]>
|
|
This shoud fix the problem with SysRq mode staying half-way enabled
and interfereing with normal PrtScrn operation after user presses ALT
for the first time.
Reported-and-tested-by: Éric Piel <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
The set_type() function can change the chip implementation when the
trigger mode changes. That might result in using an non-initialized
irq chip when called from __setup_irq() or when called via
set_irq_type() on an already enabled irq.
The set_irq_type() function should not be called on an enabled irq,
but because we forgot to put a check into it, we have a bunch of users
which grew the habit of doing that and it never blew up as the
function is serialized via desc->lock against all users of desc->chip
and they never hit the non-initialized irq chip issue.
The easy fix for the __setup_irq() issue would be to move the
irq_chip_set_defaults(desc->chip) call after the trigger setting to
make sure that a chip change is covered.
But as we have already users, which do the type setting after
request_irq(), the safe fix for now is to call irq_chip_set_defaults()
from __irq_set_trigger() when desc->set_type() changed the irq chip.
It needs a deeper analysis whether we should refuse to change the chip
on an already enabled irq, but that'd be a large scale change to fix
all the existing users. So that's neither stable nor 2.6.35 material.
Reported-by: Esben Haabendal <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Benjamin Herrenschmidt <[email protected]>
Cc: linuxppc-dev <[email protected]>
Cc: [email protected]
|
|
The commit "asm-generic: add NEED_SG_DMA_LENGTH to define sg_dma_len()"
18e98307de0d746cb0845ebf66535ce2184c25a2 broke microblaze compilation.
dma_direct_map_sg() sets sg->dma_length, however microblaze doesn't
set NEED_SG_DMA_LENGTH so scatterlist strcutres doesn't include
dma_length.
sg->dma_length is always equal to sg->length on microblaze. So we
don't need to set set dma_length, that is, microblaze can simply use
sg->length.
Signed-off-by: FUJITA Tomonori <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
|
|
The commit "mm: Move ARCH_SLAB_MINALIGN and
ARCH_KMALLOC_MINALIGN to <linux/slab_def.h>"
1f0ce8b3dd667dca7 which moved the ARCH_SLAB_MINALIGN
default into the global header broke FLAT for Microblaze.
Error message:
slab error in verify_redzone_free(): cache `idr_layer_cache':
memory outside object was overwritten
Signed-off-by: Michal Simek <[email protected]>
|
|
The code that hashes and unhashes connections from the connection table
is missing locking of the connection being modified, which opens up a
race condition and results in memory corruption when this race condition
is hit.
Here is what happens in pretty verbose form:
CPU 0 CPU 1
------------ ------------
An active connection is terminated and
we schedule ip_vs_conn_expire() on this
CPU to expire this connection.
IRQ assignment is changed to this CPU,
but the expire timer stays scheduled on
the other CPU.
New connection from same ip:port comes
in right before the timer expires, we
find the inactive connection in our
connection table and get a reference to
it. We proper lock the connection in
tcp_state_transition() and read the
connection flags in set_tcp_state().
ip_vs_conn_expire() gets called, we
unhash the connection from our
connection table and remove the hashed
flag in ip_vs_conn_unhash(), without
proper locking!
While still holding proper locks we
write the connection flags in
set_tcp_state() and this sets the hashed
flag again.
ip_vs_conn_expire() fails to expire the
connection, because the other CPU has
incremented the reference count. We try
to re-insert the connection into our
connection table, but this fails in
ip_vs_conn_hash(), because the hashed
flag has been set by the other CPU. We
re-schedule execution of
ip_vs_conn_expire(). Now this connection
has the hashed flag set, but isn't
actually hashed in our connection table
and has a dangling list_head.
We drop the reference we held on the
connection and schedule the expire timer
for timeouting the connection on this
CPU. Further packets won't be able to
find this connection in our connection
table.
ip_vs_conn_expire() gets called again,
we think it's already hashed, but the
list_head is dangling and while removing
the connection from our connection table
we write to the memory location where
this list_head points to.
The result will probably be a kernel oops at some other point in time.
This race condition is pretty subtle, but it can be triggered remotely.
It needs the IRQ assignment change or another circumstance where packets
coming from the same ip:port for the same service are being processed on
different CPUs. And it involves hitting the exact time at which
ip_vs_conn_expire() gets called. It can be avoided by making sure that
all packets from one connection are always processed on the same CPU and
can be made harder to exploit by changing the connection timeouts to
some custom values.
Signed-off-by: Sven Wegener <[email protected]>
Cc: [email protected]
Acked-by: Simon Horman <[email protected]>
Signed-off-by: Patrick McHardy <[email protected]>
|
|
Commit 48feb337475a arm: omap: switch over to gpio_set_debounce caused
"undefined reference to omap_set_gpio_debounce" build error.
The fix is to use the generic gpiolib function.
Cc: Felipe Balbi <[email protected]>
Cc: Kevin Hilman <[email protected]>
Signed-off-by: Santosh Shilimkar <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
Fixes following error,
CC arch/arm/mach-omap2/usb-ehci.o
arch/arm/mach-omap2/usb-ehci.c:263: error: implicit declaration of function
'DMA_BIT_MASK'
arch/arm/mach-omap2/usb-ehci.c:263: error: initializer element is not constant
make[1]: *** [arch/arm/mach-omap2/usb-ehci.o] Error 1
Signed-off-by: Amit Kucheria <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
The memory allocated for sgt structure is not freed on error
when sg_alloc_table is called in sgtable_alloc().
Signed-off-by: Satish Kumar <[email protected]>
Signed-off-by: Manjunatha GK <[email protected]>
Cc: Vimal Singh <[email protected]>
Signed-off-by: Hiroshi DOYU <[email protected]>
Signed-off-by: Tony Lindgen <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
firewire: core: check for 1394a compliant IRM, fix inaccessibility of Sony camcorder
|
|
This reverts commit cfecde435dda78248d6fcdc424bed68d5db6be0b, since it
seems to cause some systems to not come up with any video output at all
(or video that only comes on when X starts up).
Fixes bugzilla:
http://bugzilla.kernel.org/show_bug.cgi?id=16163
Reported-and-tested-by: David John <[email protected]>
Tested-by: Nick Bowler <[email protected]>
Acked-by: Carl Worth <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (23 commits)
drm/radeon: don't poll tv dac if crtc2 is in use.
drm/radeon: reset i2c valid to avoid incorrect tv-out polling.
drm/nv50: fix iommu errors caused by device reading from address 0
drm/nouveau: off by one in init_i2c_device_find()
nouveau: off by one in nv50_gpio_location()
drm/nouveau: completely fail init if we fail to map the PRAMIN BAR
drm/nouveau: match U/DP script against SOR link
drm/radeon/kms/pm: resurrect printing power states
drm/radeon/kms: add trivial debugging for voltage
drm/radeon/kms/r600+: use voltage from requested clock mode (v3)
drm/radeon/kms/pm: track current voltage (v2)
drm/radeon/kms/pm: Disable voltage adjust on RS780/RS880
drm/radeon/kms: fix typo in printing the HPD info
drm/radeon/kms/pm: add mid profile
drm/radeon/kms/pm: Misc fixes
drm/radeon/kms/combios: fix typo in voltage fix
drm/radeon/kms/evergreen: set accel_enabled
drm/vmwgfx: return -EFAULT for copy_to_user errors
drm/drm_crtc: return -EFAULT on copy_to_user errors
drm/fb: use printk to print out the switching to text mode error.
...
|
|
* 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6:
[S390] Update default configuration.
[S390] arch/s390/kvm: Use GFP_ATOMIC when a lock is held
[S390] kprobes: add parameter check to module_free()
[S390] appldata/extmem/kvm: add missing GFP_KERNEL flag
|
|
sync can currently take a really long time if a concurrent writer is
extending a file. The problem is that the dirty pages on the address
space grow in the same direction as write_cache_pages scans, so if
the writer keeps ahead of writeback, the writeback will not
terminate until the writer stops adding dirty pages.
For a data integrity sync, we only need to write the pages dirty at
the time we start the writeback, so we can stop scanning once we get
to the page that was at the end of the file at the time the scan
started.
This will prevent operations like copying a large file preventing
sync from completing as it will not write back pages that were
dirtied after the sync was started. This does not impact the
existing integrity guarantees, as any dirty page (old or new)
within the EOF range at the start of the scan will still be
captured.
This patch will not prevent sync from blocking on large writes into
holes. That requires more complex intervention while this patch only
addresses the common append-case of this sync holdoff.
Signed-off-by: Dave Chinner <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|