| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
BugLink: http://bugs.launchpad.net/bugs/581312
This message is informational in nature but is causing users to think
that there's a problem. Demote to pr_debug to silence it by default.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
Fixes arm build failure:
drivers/net/ethernet/stmicro/stmmac/mmc_core.c:142:2: error: implicit
declaration of function 'pr_debug'
[-Werror=implicit-function-declaration]
include/linux/printk.h:47:2: error: unknown type name 'va_list'
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
Signed-off-by: Andy Whitcroft <apw@canonical.com>
|
|
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
|
|
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
|
|
When headers are converted to userspace headers they may include
relative includes. For example x86 has the following in its
asm/posix_types.h:
# ifdef __i386__
# include "posix_types_32.h"
# else
# include "posix_types_64.h"
# endif
However this is not safe in the face of the gcc option -I- which removes
"the directory the file I am being included from" from the search list.
Convert these references to <dir/...> form avoiding this.
BugLink: http://bugs.launchpad.net/bugs/824377
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
BugLink: http://bugs.launchpad.net/bugs/838402
The Dell Latitude E6220 doesn't reboot unless reboot=pci is set.
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
|
|
BugLink: http://bugs.launchpad.net/bugs/768039
The Dell Optiplex 990 doesn't reboot unless reboot=pci is set.
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
|
|
Disable MSI for the O2 Micro, Inc. firewire controller.
BugLink: http://bugs.launchpad.net/bugs/801719
Upstream: http://marc.info/?t=131475896500002&r=1&w=2
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
|
|
BugLink: http://bugs.launchpad.net/bugs/818933
The Dell Optiplex 790 doesn't reboot unless reboot=pci is set.
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
|
|
The Dell Latitude E6520 doesn't reboot unless reboot=pci is set.
BugLink: http://bugs.launchpad.net/bugs/833705
Cc: <stable@kernel.org>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
|
|
Grub may be able to select a graphics mode and paint a splash screen
for us. If so it needs to be able to tell us it has done so. Add
support for detecting a new graphics mode selected bit in the
screen_info passed over at boot. Use this to automatically enable
vt_handoff mode.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
Introduce a new VT mode KD_TRANSPARENT which endevours to leave the current
content of the framebuffer untouched. This allows the bootloader to insert
a graphical splash and have the kernel maintain it until the OS splash
can take over. When we finally switch away (either through programs like
plymouth or manually) the content is lost and the VT reverts to text mode.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
[apw@canonical.com: This has no upstream traction but is used by powertop,
so its worth carrying.]
PowerTOP would like to be able to show who is keeping the disk
busy by dirtying data. The most logical spot for this is in the vfs
in the mark_inode_dirty() function. Doing this on the block level
is not possible because by the time the IO hits the block layer the
guilty party can no longer be found ("kjournald" and "pdflush" are not
useful answers to "who caused this file to be dirty).
The trace point follows the same logic/style as the block_dump code
and pretty much dumps the same data, just not to dmesg (and thus to
/var/log/messages) but via the trace events streams.
Note: This patch was posted to lkml and might potentially go into 2.6.33 but I
have not seen which maintainer will take it.
Signed-of-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Amit Kucheria <amit.kucheria@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
|
|
Track pages which undergo readahead and for each record which were
actually consumed, via either read or faulted into a map. This allows
userspace readahead applications (such as ureadahead) to track which
pages in core at the end of a boot are actually required and generate an
optimal readahead pack. It also allows pack adjustment and optimisation
in parallel with readahead, allowing the pack to evolve to be accurate
as userspace paths change. The status of the pages are reported back via
the mincore() call using a newly allocated bit.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
ubuntu-2.6/ubuntu/dm-raid4-5/dm-raid4-5.c:1579:9: error: too many
arguments to function 'dm_io_client_create'
The above build failure was a result of upstream commit:
commit bda8efec5c706a672e0714d341a342e811f0262a
Author: Mikulas Patocka <mpatocka@redhat.com>
Date: Sun May 29 13:03:09 2011 +0100
dm io: use fixed initial mempool size
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
Plugging for IOs to block devices was changed to an explicit, per task
base. This converts the module to the new framework, fixing the compile
failure.
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
Add support to debug S3 early resume by flashing the keyboard
LEDs three times in the realmode path. This is useful to allow
one to determine if S3 hangs occur in the BIOS or during the early
resume phase.
Add kernel parameter acpi_sleep=s3_leds to enable the s3 debugging
option. This can also be enabled by writing 8 to
/proc/sys/kernel/acpi_video_flags.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
BugLink: http://bugs.launchpad.net/bugs/778043
Move to enabling a write-combining MTRR by default, this then matches
the uvesafb module.
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
|
|
BugLink: http://bugs.launchpad.net/bugs/778043
As noted by the reporter the mtrr kernel command line option is actually a
positive numeric not a boolean, move the module parameter we add to match.
Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
|
|
When building on arm we run into the following build error due to
gcc-4.6 optimizing do_div into a uldivmod call:
ERROR: "__aeabi_uldivmod" [drivers/scsi/megaraid/megaraid_sas.ko] undefined!
Inline some assembly to prevent the compiler optimization.
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
commit 7b6d91daee5cac6402186ff224c3af39d79f4a0e
Author: Christoph Hellwig <hch@lst.de>
Date: Sat Aug 7 18:20:39 2010 +0200
block: unify flags for struct bio and struct request
Follow the following transitions:
bio_rw_flagged(bio, BIO_RW_BARRIER)) ->
(bio->bi_rw & REQ_HARDBARRIER) ->
(bio->bi_rw & REQ_FLUSH)
Signed-off-by: Andy Whitcroft <apw@canonical.com>
|
|
BugLink: http://bugs.launchpad.net/bugs/684666
We need the aufs headers in the linux-libc-headers, add support for
including files from the ubuntu include directory.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
|
|
suspend/resume"
This reverts commit 93cddb91e1a94859adfd99982b47da8328c3cfc1.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
|
|
OriginalAuthor: Timo Aaltonen <tjaalton@ubuntu.com>
BugLink: http://bugs.launchpad.net/bugs/348861
Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
|
|
When a drm driver is initialised we first allocate and initialise the
drm minor numbers including creating the sysfs files, then we trigger
the driver load method. The act of creating the sysfs files triggers the
uevent. This means udev may start programs which open /dev/dri/card0 and
other interfaces, this can occur before the load method has even started
and thus before the driver has fully initialised its data structures.
In the case of plymouthd this leads to it opening and closing (in disgust)
the interface, which in turn leads to a kernel panic as the mutexes are
yet to be initialised.
This patch delays the linking up of the drm devices minor numbers until
the driver is fully initialised. As it is possible for consumers of
these interfaces to reach them before they are fully initialised we
arrange for opens of these devices to return EAGAIN until the device is
fully initialised.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
OriginalAuthor: Amazona from Ben Howard <behoward@amazon.com>
BugLink: http://bugs.launchpad.net/bugs/634316
The pv-ops kernel suffers from poor performance when using Amazon's
Elastic block storage (EBS). This patch from Amazon improves pv-ops
kernel performance, and has not exhibited any regressions.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
This reverts the second part of patch:
commit 6da20c89af64b75302399369a90b9d50c1a87665
Author: Adrian Hunter <adrian.hunter@nokia.com>
Date: Mon Feb 15 10:03:34 2010 -0800
omap_hsmmc: Ensure regulator enable / disable are paired
Without this the kernel fails to initialize the SDHC card and find the
root partition. Work is currently underway with the community to find a
real solution to the problem. This a temporary measure to unblock
developers and will have to be reverted when the real fix gets upstream.
BugLink: https://bugs.launchpad.net/bugs/591941
Signed-off-by: Mathieu Poirier <mathieu.poirier@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
Import fix_xen_guest_on_old_EC2.patch from fedora 14
Legacy hypervisors (RHEL 5.0 and RHEL 5.1) do not handle guest writes to
cr4 gracefully. If a guest attempts to write a bit of cr4 that is
unsupported, then the HV is so offended it crashes the domain. While
later guest kernels (such as RHEL6) don't assume the HV supports all
features, they do expect nicer responses. That assumption introduced
code that probes whether or not xsave is supported early in the boot. So
now when attempting to boot a RHEL6 guest on RHEL5.0 or RHEL5.1 an early
crash will occur.
This patch is quite obviously an undesirable hack. The real fix for this
problem should be in the HV, and is, in later HVs. However, to support
running on old HVs, RHEL6 can take this small change. No impact will
occur for running on any RHEL HV (not even RHEL 5.5 supports xsave).
There is only potential for guest performance loss on upstream Xen.
All this by way of explanation for why is this patch not going upstream.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
When this patch was rolled forward, likely between Dapper and Hardy
a chunk of initialisation was lost. Pull this back in so we actually
have an vesafb_info structure initialised. Else we may well panic when
we rmmod vesafb.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
BugLink: http://bugs.launchpad.net/bugs/601226
When CUPS loads, it tries to load several drivers it may need. When
one of these drivers, specifically parport_pc is loaded, it attempts
to write to address space normally reserved for ISA transactions.
On OMAP based systems, this causes a segmentation fault.
Signed-off-by: Lee Jones <lee.jones@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
The original aynchronous boot patch (UBUNTU: SAUCE: Make populate_rootfs asynchronous)
did not take into consideration the case when CONFIG_BLK_DEV_INITRD=n,
e.g., populate_rootfs_domain becomes undefined. Therefore, add it to
noinitramfs.c where its use is benign.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Original-patch-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Surbhi Palande <surbhi.palande@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
BugLink: http://bugs.launchpad.net/bugs/586386
Some init packages such as upstart find having all of the kernel parameters
passed in useful. Currently they have to open up /proc/cmdline and
reparse that to obtain this information. Add a kernel configuration
option to enable passing of all options.
Note, enabling this option will reduce the chances that a fallback from
/sbin/init to /bin/bash or /bin/sh will succeed. Though it should be
noted that there are commonly unknown options present which would already
break this fallback. init=/bin/foo provides explicit control over options
which is unaffected by this change.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
BugLink: http://bugs.launchpad.net/bugs/458201
Triggered by the following backtrace:
WARNING: at
/build/buildd/linux-2.6.32/arch/x86/include/asm/dma-mapping.h:154
___free_dma_mem_cluster+0x102/0x110()
[<ffffffff81064f9b>] warn_slowpath_common+0x7b/0xc0
[<ffffffff81064ff4>] warn_slowpath_null+0x14/0x20
[<ffffffff8139a2a2>] ___free_dma_mem_cluster+0x102/0x110
[<ffffffff8139a072>] __sym_mfree+0xd2/0x100
[<ffffffff8139a109>] __sym_mfree_dma+0x69/0x100
[<ffffffff8139245f>] sym_hcb_free+0x8f/0x1f0
This patch never will be accepted upstream because the WARN_ON
is supposed to perevent driver development which is only
compatible with x86 on x86 (ARM can sleep in that function).
The right way to fix it would be to make the offending function
use locks in the right way but that requires careful implementation.
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
|
|
Need to include linux/slab.h to prevent implicit declaration of
functions which otherwise result in build failures.
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
The following commit removes unused params from dm_get_device().
Convert dm-raid4-5 to match:
commit 8215d6ec5fee1e76545decea2cd73717efb5cb42
Author: Nikanth Karthikesan <knikanth@novell.com>
Date: Sat Mar 6 02:32:27 2010 +0000
dm table: remove unused dm_get_device range parameters
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
The following commit adds a fn callback arguement to dm_dirty_log_create().
convert dm-raid4-5 to match:
commit 87a8f240e9bcf025ba45e4563c842b0d59c5e8ef
Author: Mikulas Patocka <mpatocka@redhat.com>
Date: Thu Dec 10 23:52:01 2009 +0000
dm log: add flush callback fn
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
|
|
BugLink: http://bugs.launchpad.net/bugs/397734
It seems that users are have a high expectation that the eject button
on their CDROM drive will eject the disk regardless of whether it is in
use or not. To this end we are now changing the default LOCK mode for
mounted CDROMS to 0 to allow ejects. This however does not handle the
direct open cases like music and video players. From the launchpad bug
commentary:
So, according to the upstream discussion David Zeuthen recommended
to just not lock CD-ROM trays by default. Kernel/userspace already
handles prematurely removed USB storage devices reasonably, and with
read-only devices like CD-ROMs it is even less of an issue. So we
should just set /proc/sys/dev/cdrom/lock to 0 by default.
Note that we still will have the drive mounted after the eject. There is a
media change uevent generated and this will be used to trigger the unmount
of the drive in udisks. The burner software will also have to be looked
at to ensure they are explicitly locking the drive closed during the burn.
This will all be handled under the bug above.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Colin King <colin.king@canonical.com>
|
|
Based on a patch from Rafael J. Wysocki. This patch prints suspend/resume
information for each driver/device to dmesg.
[apw@canonical.com: rejigged to split config updates]
[apw@canonical.com: move the configuration item fix build when full PM
is not enabled]
Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
|
|
Needed so that 'make defconfig && make' works.
Signed-off-by: Colin Watson <cjwatson@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
|
|
BugLink: http://bugs.launchpad.net/bugs/510937
With the introduction of wireless USB hubs the product, manufacturer,
and serial number are now mutable. This necessitates new locking in the
consumers of these values including the sysfs read routines in order to
prevent use-after-free acces to these values. These extra locks create
significant lock contention leading to increased boot times (0.3s for an
example Atom based system). Move update of these values to RCU based
locking.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
|
|
commit 757fd770c649b0dfa6eeefc2d5e2ea3119b6be9c upstream (linux-2.6-tip)
Found by Ingo Molnar's automated tester.
Reported-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
LKML-Reference: <20100123113359.GA29555@one.firstfloor.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
|
|
commit f91c4d2649531cc36e10c6bc0f92d0f99116b209 upstream (linux-2.6-tip)
cpu_specific_poll is a global variable, and it should have a global
namespace name. Since it is MCE-specific (it takes a struct mce *),
rename it mce_cpu_specific_poll.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: Andi Kleen <andi@firstfloor.org>
LKML-Reference: <20100121221711.GA8242@basil.fritz.box>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
|
|
commit c773f70fd6b53ee646727f871833e53649907264 upstream (linux-2.6-tip)
Xeon 75xx doesn't log physical addresses on corrected machine check
events in the standard architectural MSRs. Instead the address has to
be retrieved in a model specific way. This makes it impossible to do
predictive failure analysis.
Implement cpu model specific code to do this in mce-xeon75xx.c using a
new hook that is called from the generic poll code. The code retrieves
the physical address/DIMM of the last corrected error from the
platform and makes the address look like a standard architectural MCA
address for further processing.
In addition the DIMM information is retrieved and put into two new
aux0/aux1 fields in struct mce. These fields are specific to a given
CPU. These fields can then be decoded by mcelog into specific DIMM
information. The latest mcelog version has support for this.
Longer term this will be likely in a different output format, but
short term that seemed like the least intrusive solution. Older mcelog
can deal with an extended record.
There's no code to print this information on a panic because this only
works for corrected errors, and corrected errors do not usually result
in panics.
The act of retrieving the DIMM/PA information can take some time, so
this code has a rate limit to avoid taking too much CPU time on a
error flood.
The whole thing can be loaded as a module and has suitable PCI-IDs so
that it can be auto-loaded by a distribution. The code also checks
explicitely for the expected CPU model number to make sure this code
doesn't run anywhere else.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
LKML-Reference: <20100121221711.GA8242@basil.fritz.box>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
|
|
BugLink: http://bugs.launchpad.net/bugs/507211
When instantiating the battery object on to the acpi bus in the kernel
we talk to the BIOS to get the current battery state. This can take
a long time and holds the acpi bus object locked for the duration.
This leads to any other object wishing to add itself that bus blocking.
This leads to unpredicatable delays of up to .3s when initialising the
hpet during boot depending on execution order. Make the first update of
the battery asynchronous. Move the acpi bus handling back synchronous.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
|
|
Check to see if the machine has more than one active CPU, if it does
then it is worth starting the decode of the rootfs earlier.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
|
|
The results of scanning for devices is to trigger udev events therefore
we can push this processing async.
This reduces kernel initialisation time (the time from bootloader to
starting userspace) by several 10ths of a second x86 32bit systems.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
|
|
The expansion of the initramfs is completely independant of other
boot activities. The original data is already present at boot and the
filesystem is not required until we are ready to start init. It is
therefore reasonable to populate the rootfs asynchronously. Move this
processing to an async call.
This reduces kernel initialisation time (the time from bootloader to
starting userspace) by several 10ths of a second on a selection of test
hardware particularly SMP systems, although UP system also benefit.
Signed-off-by: Surbhi Palande <surbhi.palande@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
|
|
BugLink: http://bugs.launchpad.net/bugs/458982
acpi_video_bus_start_devices() in drivers/acpi/video.c sets the default
ACPI DOS value to 0, which lets the OS handle toggling of display output
but still leaves the BIOS handling brightness levels automatically when
connecting/disconnecting AC.
We want the OS to handle both where possible, so a better default would
be to set this to 4.
This likely will regress systems using proprietary video drivers which
will need to change this setting back using the sysfs interfaces.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
|
