Commit 64e9159f5d ("serial_core:
uart_set_ldisc infrastructure") introduced the ability for low-level
serial drivers to be informed when the tty ldisc changes.
However, the actual tty-layer function that does this callback for
serial devices was declared with the wrong type, having a spurious and
unused 'ldisc' argument.
This fixed the resulting compiler warning by just removing it.
Acked-by: Blithering Idiot <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip:
x86, fpu: fix CONFIG_PREEMPT=y corruption of application's FPU stack
suspend-vs-iommu: prevent suspend if we could not resume
x86: section mismatch fix
x86: fix Xorg crash with xf86MapVidMem error
x86: fix pointer type warning in arch/x86/mm/init_64.c:early_memtest
x86: fix bad pmd ffff810000207xxx(9090909090909090)
x86: ioremap fix failing nesting check
x86: fix broken math-emu with lazy allocation of fpu area
x86: enable preemption in delay
x86: disable preemption in native_smp_prepare_cpus
x86: fix APIC warning on 32bit v2
The d_instantiate hook for Smack can hang on the root inode of a
filesystem if the file system code has not really done all the set-up.
Fuse is known to encounter this problem.
This change detects an attempt to instantiate a root inode and addresses
it early in the processing, before any attempt is made to do something
that might hang.
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Tested-by: Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
libata-sff: Fix oops reported in kerneloops.org for pnp devices with no ctl
libata: kill unused constants
sata_mv: PHY_MODE4 cleanups
[libata] ata_piix: more acer short cable quirks
[libata] ACPI: Properly handle bay devices in dock stations
* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
[SCSI] qla2xxx: Update version number to 8.02.01-k4.
[SCSI] qla2xxx: Correct handling of AENs postings for vports.
[SCSI] qla2xxx: Revert "qla2xxx: Use proper HA during asynchronous event handling."
[SCSI] ibmvscsi: Non SCSI error status fixup
[SCSI] fusion mpt: fix target missing after resetting external raid
[SCSI] fix intermittent oops in scsi_bus_uevent
[SCSI] qla2xxx: Update version number to 8.02.01-k3.
[SCSI] qla2xxx: Revert "qla2xxx: Validate mid-layer 'underflow' during check-condition handling."
[SCSI] qla2xxx: Disable local-interrupts while polling for RISC status.
[SCSI] qla2xxx: Extend the 'fw_dump' SYSFS node the ability to initiate a firmware dump.
[SCSI] qla2xxx: Don't depend on mailbox return values while enabling FCE tracing.
[SCSI] qla2xxx: Convert vport_sem to a mutex
[SCSI] qla2xxx: firmware semaphore to mutex
[SCSI] qla2xxx: Correct locking within MSI-X interrupt handlers.
[SCSI] qla2xxx: Display driver version at module init-time.
[SCSI] qla2xxx: Return correct port_type to FC-transport for Vports.
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb:
kgdbts: Use HW breakpoints with CONFIG_DEBUG_RODATA
kgdb: use common ascii helpers and put_unaligned_be32 helper
__le16 fields used as host-endian.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Steve French <smfrench@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* wMaxPacketSize is le16; copying it to a field of local structure and then
using that field as host-endian (size of object to be allocated) is broken.
* bMaxPacketSize0 is 8-bit; feeding it to le16_to_cpu() is bogus and since the
result is used as host-endian, it's not even misspelled cpu_to_le16().
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Jürgen Mell reported an FPU state corruption bug under CONFIG_PREEMPT,
and bisected it to commit v2.6.19-1363-gacc2076, "i386: add sleazy FPU
optimization".
Add tsk_used_math() checks to prevent calling math_state_restore()
which can sleep in the case of !tsk_used_math(). This prevents
making a blocking call in __switch_to().
Apparently "fpu_counter > 5" check is not enough, as in some signal handling
and fork/exec scenarios, fpu_counter > 5 and !tsk_used_math() is possible.
It's a side effect though. This is the failing scenario:
process 'A' in save_i387_ia32() just after clear_used_math()
Got an interrupt and pre-empted out.
At the next context switch to process 'A' again, kernel tries to restore
the math state proactively and sees a fpu_counter > 0 and !tsk_used_math()
This results in init_fpu() during the __switch_to()'s math_state_restore()
And resulting in fpu corruption which will be saved/restored
(save_i387_fxsave and restore_i387_fxsave) during the remaining
part of the signal handling after the context switch.
Bisected-by: Jürgen Mell <j.mell@t-online.de>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Tested-by: Jürgen Mell <j.mell@t-online.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@kernel.org
iommu/gart support misses suspend/resume code, which can do bad stuff,
including memory corruption on resume. Prevent system suspend in case we
would be unable to resume.
Signed-off-by: Pavel Machek <pavel@suse.cz>
Tested-by: Patrick <ragamuffin@datacomm.ch>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Fix this:
WARNING: vmlinux.o(.text+0x114bb): Section mismatch in reference from
the function nopat() to the function .cpuinit.text:pat_disable()
The function nopat() references
the function __cpuinit pat_disable().
This is often because nopat lacks a __cpuinit
annotation or the annotation of pat_disable is wrong.
Reported-by: "Fabio Comolli" <fabio.comolli@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Clarify the usage of mtrr_lookup() in PAT code, and to make PAT code
resilient to mtrr lookup problems.
Specifically, pat_x_mtrr_type() is restructured to highlight, under what
conditions we look for mtrr hint. pat_x_mtrr_type() uses a default type
when there are any errors in mtrr lookup (still maintaining the pat
consistency). And, reserve_memtype() highlights its usage ot mtrr_lookup
for request type of '-1' and also defaults in a sane way on any mtrr
lookup failure.
pat.c looks at mtrr type of a range to get a hint on what mapping type
to request when user/API: (1) hasn't specified any type (/dev/mem
mapping) and we do not want to take performance hit by always mapping
UC_MINUS. This will be the case for /dev/mem mappings used to map BIOS
area or ACPI region which are WB'able. In this case, as long as MTRR is
not WB, PAT will request UC_MINUS for such mappings.
(2) user/API requests WB mapping while in reality MTRR may have UC or
WC. In this case, PAT can map as WB (without checking MTRR) and still
effective type will be UC or WC. But, a subsequent request to map same
region as UC or WC may fail, as the region will get trackked as WB in
PAT list. Looking at MTRR hint helps us to track based on effective type
rather than what user requested. Again, here mtrr_lookup is only used as
hint and we fallback to WB mapping (as requested by user) as default.
In both cases, after using the mtrr hint, we still go through the
memtype list to make sure there are no inconsistencies among multiple
users.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Tested-by: Rufus & Azrael <rufus-azrael@numericable.fr>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Changed the call to find_e820_area_size to pass u64 instead of unsigned long.
Signed-off-by: Kevin Winchester <kjwinchester@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
OGAWA Hirofumi and Fede have reported rare pmd_ERROR messages:
mm/memory.c:127: bad pmd ffff810000207xxx(9090909090909090).
Initialization's cleanup_highmap was leaving alignment filler
behind in the pmd for MODULES_VADDR: when vmalloc's guard page
would occupy a new page table, it's not allocated, and then
module unload's vfree hits the bad 9090 pmd entry left over.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Mika Kukkonen noticed that the nesting check in early_iounmap() is not
actually done.
Reported-by: Mika Kukkonen <mikukkon@srv1-m700-lanp.koti>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: torvalds@linux-foundation.org
Cc: arjan@linux.intel.com
Cc: mikukkon@iki.fi
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Fix the math emulation that got broken with the recent lazy allocation of FPU
area. init_fpu() need to be added for the math-emulation path aswell
for the FPU area allocation.
math emulation enabled kernel booted fine with this, in the presence
of "no387 nofxsr" boot param.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: hpa@zytor.com
Cc: mingo@elte.hu
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
The RT team has been searching for a nasty latency. This latency shows
up out of the blue and has been seen to be as big as 5ms!
Using ftrace I found the cause of the latency.
pcscd-2995 3dNh1 52360300us : irq_exit (smp_apic_timer_interrupt)
pcscd-2995 3dN.2 52360301us : idle_cpu (irq_exit)
pcscd-2995 3dN.2 52360301us : rcu_irq_exit (irq_exit)
pcscd-2995 3dN.1 52360771us : smp_apic_timer_interrupt (apic_timer_interrupt
)
pcscd-2995 3dN.1 52360771us : exit_idle (smp_apic_timer_interrupt)
Here's an example of a 400 us latency. pcscd took a timer interrupt and
returned with "need resched" enabled, but did not reschedule until after
the next interrupt came in at 52360771us 400us later!
At first I thought we somehow missed a preemption check in entry.S. But
I also noticed that this always seemed to happen during a __delay call.
pcscd-2995 3dN.2 52360836us : rcu_irq_exit (irq_exit)
pcscd-2995 3.N.. 52361265us : preempt_schedule (__delay)
Looking at the x86 delay, I found my problem.
In git commit 35d5d08a08, Andrew Morton
placed preempt_disable around the entire delay due to TSC's not working
nicely on SMP. Unfortunately for those that care about latencies this
is devastating! Especially when we have callers to mdelay(8).
Here I enable preemption during the loop and account for anytime the task
migrates to a new CPU. The delay asked for may be extended a bit by
the migration, but delay only guarantees that it will delay for that minimum
time. Delaying longer should not be an issue.
[
Thanks to Thomas Gleixner for spotting that cpu wasn't updated,
and to place the rep_nop between preempt_enabled/disable.
]
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Cc: akpm@osdl.org
Cc: Clark Williams <clark.williams@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: "Luis Claudio R. Goncalves" <lclaudio@uudg.org>
Cc: Gregory Haskins <ghaskins@novell.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andi Kleen <andi-suse@firstfloor.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
for http://bugzilla.kernel.org/show_bug.cgi?id=10613
BIOS bug, APIC version is 0 for CPU#0! fixing up to 0x10. (tell your hw vendor)
v2: fix 64 bit compilation
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Gabriel C <nix.or.die@googlemail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
- Make ata_sff_altstatus private so nobody uses it by mistake
- Drop the 400nS delay from it
Add
ata_sff_irq_status - encapsulates the IRQ check logic
This function keeps the existing behaviour for altstatus using devices. I
actually suspect the logic was wrong before the changes but -rc isn't the
time to play with that
ata_sff_sync - ensure writes hit the device
Really we want an io* operation for 'is posted' eg ioisposted(ioaddr) so
that we can fix the nasty delay this causes on most systems.
- ata_sff_pause - 400nS delay
Ensure the command hit the device and delay 400nS
- ata_sff_dma_pause
Ensure the I/O hit the device and enforce an HDMA1:0 transition delay.
Requires altstatus register exists, BUG if not so we don't risk
corruption in MWDMA modes. (UDMA the checksum will save your backside in
theory)
The only other complication then is devices with their own handlers.
rb532 can use dma_pause but scc needs to access its own altstatus
register for internal errata workarounds so directly call the drivers own
altstatus function.
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
The handling for PHY_MODE4 was originally just cloned from the
Marvell proprietary driver (with their blessing).
But we can do better than that.
Tidy things up with some judicious mask definitions, to improve maintainability.
Signed-off-by: Mark Lord <mlord@pobox.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Add ICH6 on ACER Aspire 1694WLMi to list of laptops that use short cables
rather than 80 wire
OriginalAuthor: Tiago Sousa
OriginalLocation: http://launchpadlibrarian.net/11627664/new.ich_laptop.short.cables.diff
Bug: #187121
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: maximilian attems <max@stro.at>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
* Differentiate between bay devices in dock stations and others:
- When an ACPI_NOTIFY_EJECT_REQUEST appears, just signal uevent to
userspace (that is when the optional eject button on a bay device is
pressed/pulled) giving the possibility to unmount file systems and to
clean up. Also, only send uevent in case we get an EJECT_REQUEST
without doing anything else. In other cases, you'll get an add/remove
event because libata attaches/detaches the device.
- In case of a dock event, which in turn signals an
ACPI_NOTIFY_EJECT_REQUEST, immediately detach the device, because it
may already have been gone
* In case of an ACPI_NOTIFY_DEVICE/BUS_CHECK, evaluate _STA to check if
the device has been plugged or unplugged. If plugged, hotplug it, if
unplugged, just signal event to userspace
(initial patch by Matthew Garrett <mjg59@srcf.ucam.org>)
* Call ACPI _EJ0 for detached devices
Signed-off-by: Holger Macht <hmacht@suse.de>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Use quirk table to assign ALC268_TOSHIBA to COMPAL IFL90/JFL-92 laptops.
No analog output on autoprobe.
Signed-off-by: Tony Vroon <tony@linx.net>
Tested-by: Guri <gurashka@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The tty layer provides a callback that is used when the line discipline
is changed. Some hardware uses this to configure hardware specific
features such as IrDA mode on serial ports. Unfortunately the serial
layer does not provide this feature or pass it down to drivers.
Blackfin used to hack around this by rewriting the tty ops, but those are
now properly shared and const so the hack fails. Instead provide the
proper operations.
This change plus a follow up from the Blackfin guys is needed to avoid
blackfin losing features in this release.
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
RSK7203 is supportable through the generic machvec, so we add a defconfig
for those bits. This gets updated with more complete board support later.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Both the PNP/PCI conflict detection quirk and the PNP system
driver must use the same mechanism to mark resources as disabled.
I think it's best to keep the resource and to keep the type bit
(IORESOURCE_MEM, etc), so that we match the list from firmware
as closely as possible.
Fixes this regression from 2.6.25: http://lkml.org/lkml/2008/6/1/82
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Tested-by: Avuton Olrich <avuton@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Since mmc_spi.h uses irqreturn_t type, it should include appropriate
header, otherwise build will break if users didn't include it (some of
them do not use interrupts).
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/blackfin-2.6:
8250 Serial Driver: revert extra IRQ flag definition patch
Blackfin arch: update anomaly headers from toolchain trunk
Blackfin arch: Remove bad and usless code
Blackfin arch: Fix bug - set corret SSEL and IRQ to enable AD7877 on BF527
Blackfin arch: Fix typo. it should be _outsw_8
Blackfin arch: Cleanup no functional changes
4k stacks on nommu ends up blowing up with all sorts of interesting
slab corruption. Disable this by default unless BROKEN is also
enabled.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
As noted by Matthew Wilcox:
Kyle McMartin just tracked down a bug on parisc to a missing
"memory" clobber in the inline assembly implementation of
ip_fast_csum. The FRV, SH and Xtensa ports are also missing a
memory clobber, so I thought it would be polite to let you know.
The bug manifests as dropped network packets (obviously they have
the wrong checksum). It started appearing for parisc with GCC 4.3.
The GCC manual says:
If your assembler instructions access memory in an unpredictable
fashion, add `memory' to the list of clobbered registers. This
will cause GCC to not keep memory values cached in registers
across the assembler instruction and not optimize stores or loads
to that memory.
I see that FRV has a 400 byte memory output which may prevent this
problem from appearing, but SH and Xtensa have nothing to prevent
this bug. Hope this saves you a few days of debugging.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
