commit 21ec7f6dbf upstream.
If irq flags tracing is enabled the TRACE_IRQS_ON macros expands to
a function call which clobbers registers %r0-%r5. The macro is used
in the code path for single stepped system calls. The argument
registers %r2-%r6 need to be restored from the stack before the system
call function is called.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 7a48143678 upstream.
Unsurprisingly, Texas Instruments TSB43AB23 exhibits the same behaviour
as TSB43AB22/A in dual buffer IR DMA mode: If descriptors are located
at physical addresses above the 31 bit address range (2 GB), the
controller will overwrite random memory. With luck, this merely
prevents video reception. With only a little less luck, the machine
crashes.
We use the same workaround here as with TSB43AB22/A: Switch off the
dual buffer capability flag and use packet-per-buffer IR DMA instead.
Another possible workaround would be to limit the coherent DMA mask to
31 bits.
In Linux 2.6.33, this change serves effectively only as documentation
since dual buffer mode is not used for any controller anymore. But
somebody might want to re-enable it in the future to make use of
features of dual buffer DMA that are not available in packet-per-buffer
mode.
In Linux 2.6.32 and older, this update is vital for anyone with this
controller, more than 2 GB RAM, a 64 bit kernel, and FireWire video or
audio applications.
We have at least four reports:
http://bugzilla.kernel.org/show_bug.cgi?id=13808http://marc.info/?l=linux1394-user&m=126154279004083https://bugzilla.redhat.com/show_bug.cgi?id=552142http://marc.info/?l=linux1394-user&m=126432246128386
Reported-by: Paul Johnson
Reported-by: Ronneil Camara
Reported-by: G Zornetzer
Reported-by: Mark Thompson
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 4bdadb9785 upstream.
Having missed the ENOMEM return via i915_gem_fault(), there are probably
other paths that I also missed. By not enabling NORETRY by default these
paths can run the shrinker and take memory from the system (but not from
our own inactive lists because our shrinker can not run whilst we hold
the struct mutex) and this may allow the system to survive a little longer
whilst our drivers consume all available memory.
References:
OOM killer unexpectedly called with kernel 2.6.32
http://bugzilla.kernel.org/show_bug.cgi?id=14933
v2: Pass gfp into page mapping.
v3: Use new read_cache_page_gfp() instead of open-coding.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 0531b2aac5 upstream.
It's a simplified 'read_cache_page()' which takes a page allocation
flag, so that different paths can control how aggressive the memory
allocations are that populate a address space.
In particular, the intel GPU object mapping code wants to be able to do
a certain amount of own internal memory management by automatically
shrinking the address space when memory starts getting tight. This
allows it to dynamically use different memory allocation policies on a
per-allocation basis, rather than depend on the (static) address space
gfp policy.
The actual new function is a one-liner, but re-organizing the helper
functions to the point where you can do this with a single line of code
is what most of the patch is all about.
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit f1053a7ca9 upstream.
Since commit 9d2e9d66a3
mptsas driver fails to allocate memory for the MPT chain buffers
for second LSI adapter on PPC440SPe Katmai platform:
...
ioc1: LSISAS1068E B3: Capabilities={Initiator}
mptbase: ioc1: ERROR - Unable to allocate Reply, Request, Chain Buffers!
mptbase: ioc1: ERROR - didn't initialize properly! (-3)
mptsas: probe of 0002:31:00.0 failed with error -3
This commit increased MPT_FC_CAN_QUEUE value but initChainBuffers()
doesn't differentiate between SAS and FC causing increased allocation
for SAS case, too. Later pci_alloc_consistent() fails to allocate
increased chain buffer pool size for SAS case.
Provide a fix by looking at the bus type and using appropriate
MPT_SAS_CAN_QUEUE value while calculation of the number of chain
buffers.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Acked-by: Kashyap Desai <kashyap.desai@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 63c43b0ec1 upstream.
Because of the terrible structuring of scsi-bidi-commands
it breaks some of the life time rules of a scsi-command.
It is now not allowed to free up the block-request before
cleanup and partial deallocation of the scsi-command. (Which
is not so for none bidi commands)
The right fix to this problem would be to make bidi command
a first citizen by allocating a scsi_sdb pointer at scsi command
just like cmd->prot_sdb. The bidi sdb should be allocated/deallocated
as part of the get/put_command (Again like the prot_sdb) and the
current decoupling of scsi_cmnd and blk-request should be kept.
For now make sure scsi_release_buffers() is called before the
call to blk_end_request_all() which might cause the suicide of
the block requests. At best the leak of bidi buffers, at worse
a crash, as there is a race between the existence of the bidi_request
and the free of the associated bidi_sdb.
The reason this was never hit before is because only OSD has the potential
of doing asynchronous bidi commands. (So does bsg but it is never used)
And OSD clients just happen to do all their bidi commands synchronously, up
until recently.
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
For disk devices, a new uevent parameter 'NPARTS' specifies the number
of partitions detected by the kernel. Partition devices get 'PARTN' which
specifies the partitions index in the table.
Signed-off-by: San Mehat <san@google.com>
For UP systems this is not required, and results in a more consistent
sample interval.
Signed-off-by: Jocelyn Falempe <jocelyn.falempe@motorola.com>
Signed-off-by: Mike Chan <mike@android.com>
erase kpanic partition when there is no data(console and thread)
Signed-off-by: Tom Zhu <a2289c@android-hal-04.(none)>
Signed-off-by: San Mehat <san@google.com>
Add bad block handling in apanic
Signed-off-by: Tom Zhu <ling.zhu@motorola.com>
Signed-off-by: San Mehat <san@google.com>
misc: apanic: Improved bad-block / watchdog handling
1. handle cases that there is no more good blocks
2. touch softlockup watchdog at the start of apanic
3. change unsigned char get_bb() to unsigned int get_bb()
4. return idx instead of rc2, to keep the previous written pages.
Signed-off-by: Tom Zhu <ling.zhu@motorola.com>
Signed-off-by: San Mehat <san@google.com>
This driver triggers when the kernel panics and attempts to
write critical debug data to the flash.
Signed-off-by: San Mehat <san@google.com>
drivers: apanic: checkpatch fixes
Signed-off-by: San Mehat <san@google.com>
apanic: Fix a few cases of calling non-atomic things from atomic
We need to pay special care to not enrage cond_resched(), and the
base nand bb stuff calls schedule() so thats out.
Signed-off-by: San Mehat <san@google.com>
This is extremely useful in diagnosing remote crashes, and is based heavily
on original work by <md@google.com>.
Signed-off-by: San Mehat <san@google.com>
Cc: Michael Davidson <md@google.com>
[ARM] process: Use uber-safe probe_kernel_address() to read mem when dumping.
This prevents the dump from taking pagefaults / external aborts.
Signed-off-by: San Mehat <san@google.com>
Signed-off-by: San Mehat <san@google.com>
mtd: nand_base: fix nand_panic_wait
fix the problem of nand_panic_wait
Signed-off-by: Tom Zhu <a2289c@android-hal-04.(none)>
Signed-off-by: San Mehat <san@google.com>
Rather than hard-lock the kernel, we now BUG() when a driver takes
> 3 seconds to suspend. If the underlying platform supports panic dumps,
then the data can be collected for debug.
Signed-off-by: San Mehat <san@google.com>
power_save is a feature to allow HID devices to control the sniff mode.
Unfortunately it also prevents us exiting sniff mode on some A2DP devices
that do not explicitly exit sniff mode themselves, resulting in skipping
audio.
Marcel is trying to finalize a setsockopt() API to control whether power_save
is enabled on a per socket basis. In the mean-time, turn off power_save for
Android, since we do not have official HID support, and this is causing
problems for A2DP which we do support.
(Note the power_save logic is reversed, 0 is on, 1 is off).
Change-Id: Ife4478055128b81669bf49308d2e2199e1aa11a1
Signed-off-by: Nick Pelly <npelly@google.com>
With Bluetooth 2.1 ACL packets can be flushable or non-flushable. This changes
makes the default ACL packet non-flushable, and allows selection of flushable
packets on a per-L2CAP socket basis with L2CAP_LM_FLUSHABLE.
Note the HCI Write Automatic Flush Timeout command also needs to be issued
to set the flush timeout to non-zero.
Need to featurize this change to Bluetooth 2.1 chipsets only before pushing
upstream.
Signed-off-by: Nick Pelly <npelly@google.com>
When in sniff mode with a long interval time (1.28s) it can take 4+ seconds to
establish a SCO link. Fix by requesting active mode before requesting SCO
connection. This improves SCO setup time to ~500ms.
Bluetooth headsets that use a long interval time, and exhibit the long SCO
connection time include Motorola H790, HX1 and H17. They have a CSR 2.1 chipset
Verified this behavior and fix with host Bluetooth chipsets: BCM4329 and
TI1271.
Signed-off-by: Nick Pelly <npelly@google.com>
This is to support the Motorola HF850 carkit which reports the error code 0x10
for an eSCO attempt, even though it advertises eSCO support. Here is the
hcidump:
2009-09-22 15:40:24.492391 < HCI Command: Setup Synchronous Connection
(0x01|0x0028) plen 17
handle 1 voice setting 0x0060
2009-09-22 15:40:24.493002 > HCI Event: Command Status (0x0f) plen 4
Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
2009-09-22 15:40:30.594869 > HCI Event: Synchronous Connect Complete (0x2c)
plen 17
status 0x10 handle 257 bdaddr 00:50:CD:20:C6:84 type eSCO
Error: Connection Accept Timeout Exceeded
With this patch we will retry with a SCO connection, which succeeds.
Unfortunately the Moto HF850 also takes 5 seconds to return the error for the
eSCO attempt, so it will still take 5 seconds to fallback to SCO with this
patch.
Signed-off-by: Nick Pelly <npelly@google.com>
Legacy pairing is a bit of a problem because on the incoming end it is
impossible to know pairing has begun:
2009-09-18 18:29:24.115692 > HCI Event: Connect Request (0x04) plen 10
bdaddr 00:23:D4:04:51:7A class 0x58020c type ACL
2009-09-18 18:29:24.115966 < HCI Command: Accept Connection Request (0x01|0x0009) plen 7
bdaddr 00:23:D4:04:51:7A role 0x00
Role: Master
2009-09-18 18:29:24.117065 > HCI Event: Command Status (0x0f) plen 4
Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
2009-09-18 18:29:24.282928 > HCI Event: Role Change (0x12) plen 8
status 0x00 bdaddr 00:23:D4:04:51:7A role 0x00
Role: Master
2009-09-18 18:29:24.291534 > HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 1 bdaddr 00:23:D4:04:51:7A type ACL encrypt 0x00
2009-09-18 18:29:24.291839 < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
handle 1
2009-09-18 18:29:24.292144 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
bdaddr 00:23:D4:04:51:7A mode 1
2009-09-18 18:29:24.293823 > HCI Event: Command Status (0x0f) plen 4
Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
2009-09-18 18:29:24.303588 > HCI Event: Max Slots Change (0x1b) plen 3
handle 1 slots 5
2009-09-18 18:29:24.309448 > HCI Event: Read Remote Supported Features (0x0b) plen 11
status 0x00 handle 1
Features: 0xff 0xff 0x2d 0xfe 0x9b 0xff 0x79 0x83
2009-09-18 18:29:24.345916 < HCI Command: Remote Name Request (0x01|0x0019) plen 10
bdaddr 00:23:D4:04:51:7A mode 2 clkoffset 0x0000
2009-09-18 18:29:24.346923 > HCI Event: Command Status (0x0f) plen 4
Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
2009-09-18 18:29:24.375793 > HCI Event: Remote Name Req Complete (0x07) plen 255
status 0x00 bdaddr 00:23:D4:04:51:7A name 'test'
2009-09-18 18:29:34.332190 < HCI Command: Disconnect (0x01|0x0006) plen 3
handle 1 reason 0x13
There are some mainline patches such as "Add different pairing timeout for
Legacy Pairing" but they do not address the HCI sequence above.
I think the real solution is to avoid using CreateBond(), and instead make
the profile connection immediately. This way both sides will use a longer
timeout because there is a higher level connection in progress, and we will
not end up with the useless HCI sequence above.
Signed-off-by: Nick Pelly <npelly@google.com>
GM carkits with LGE BT chipsets return this error code when eSCO is attempted.
Signed-off-by: Jaikumar Ganesh <jaikumar@google.com>
Acked-by: Nick Pelly <npelly@google.com>
This fixes a bug where shutdown() and close() on a rfcomm socket during ACL
connection would not cause HCI Create Connection Cancel.
Signed-off-by: Nick Pelly <npelly@google.com>
Some platforms do not want to power down rfkill devices on suspend.
Change-Id: I62a11630521c636d54a4a02ab9037a43435925f5
Signed-off-by: Nick Pelly <npelly@google.com>
This provides kernel_debugger() which can be called from an interrupt
context low level debugger wedge to execute commands that inspect
kernel state. It doesn't do much on its own.
Signed-off-by: Brian Swetland <swetland@google.com>
kernel_debugger_core: Add sysrq command.
sysrq <c> will run the sysrq command <c> and dump what
was added to the kernel log while the command ran.
Signed-off-by: Brian Swetland <swetland@google.com>
Signed-off-by: Arve Hjønnevåg <arve@android.com>
net: Fix a bitmask in PPPoPNS and rename constants in PPPoPNS and PPPoLAC.
Signed-off-by: Chia-chi Yeh <chiachi@android.com>
net: Fix a potential deadlock while releasing PPPoLAC/PPPoPNS socket.
PPP driver guarantees that no thread will be executing start_xmit() after
returning from ppp_unregister_channel(). To achieve this, a spinlock (downl)
is used. In pppolac_release(), ppp_unregister_channel() is called after sk_udp
is locked. At the same time, another thread might be running in pppolac_xmit()
with downl. Thus a deadlock will occur if the thread tries to lock sk_udp.
The same situation might happen on sk_raw in pppopns_release().
Signed-off-by: Chia-chi Yeh <chiachi@android.com>
net: Force PPPoLAC and PPPoPNS to bind an interface before creating PPP channel.
It is common to manipulate the routing table after configuring PPP device.
Since both PPPoLAC and PPPoPNS run over IP, care must be taken to make sure
that there is no loop in the routing table.
Although this can be done by adding a host route, it might still cause
problems when the interface is down for some reason.
To solve this, this patch forces both drivers to bind an interface before
creating PPP channel, so the system will not re-route the tunneling sockets
to another interface when the original one is down. Another benefit is that
now the host route is no longer required, so there is no need to remove it
when PPP channel is closed.
Signed-off-by: Chia-chi Yeh <chiachi@android.com>
net: Avoid sleep-inside-spinlock in PPPoLAC and PPPoPNS.
Since recv() and xmit() are called with a spinlock held, routines which might
sleep cannot be used. This issue is solved by following changes:
Incoming packets are now processed in backlog handler, recv_core(), instead of
recv(). Since backlog handler is always executed with socket spinlock held, the
requirement of ppp_input() is still satisfied.
Outgoing packets are now processed in workqueue handler, xmit_core(), instead of
xmit(). Note that kernel_sendmsg() is no longer used to prevent touching dead
sockets.
In release(), lock_sock() and pppox_unbind_sock() ensure that no thread is in
recv_core() or xmit(). Then socket handlers are restored before release_sock(),
so no packets will leak in backlog queue.
Signed-off-by: Chia-chi Yeh <chiachi@android.com>
net: Fix msg_iovlen in PPPoLAC and PPPoPNS.
Although any positive value should work (which is always true in both drivers),
the correct value should be 1.
Signed-off-by: Chia-chi Yeh <chiachi@android.com>
Rather than using explicit euid == 0 checks when trying to move
tasks into a cgroup via CFS, move permission checks into each
specific cgroup subsystem. If a subsystem does not specify a
'can_attach' handler, then we fall back to doing our checks the old way.
This way non-root processes can add arbitrary processes to
a cgroup if all the registered subsystems on that cgroup agree.
Also change explicit euid == 0 check to CAP_SYS_ADMIN
Signed-off-by: San Mehat <san@google.com>
The shadowing mechanism is used to ensure that the right
interlocking happens when an object is renamed over an existing object.
Extreme power fail stress testing revealed that garbage collection could
disrupt the shadowing process causing object loss.
This fixes the problem and has survived millions of simulated power failures.
Change-Id: I1c9c4365632c0f8be4ed6a4b41534a732ea81507
Signed-off-by: Charles Manning <cdhmanning@gmail.com>
This aproach uses a search context iterator to allow yaffs to be
unlocked during the filldir. The search context stores the next
object to visited. If changes to the directory (ie unlinks) cause
the directory to be modified then a callback moves the iterator
to the next object if need be, thus preventing the iterator from
being corrupted.
Change-Id: Ia4735e42732f03a396ced7275e33facdc4f1beac
Signed-off-by: Charles Manning <cdhmanning@gmail.com>
Unrooted files should only happen due to a now fixed bug that
would rmdir non-empty directories.
Unrooted files are now re-rooted in lost_found.
This also introduces a mechanism to empty out lost and found at
mount, thus recaliming this space. This option may be controlled
via a compile flag and overridden with a mount option.
Signed-off-by: Charles Manning <cdhmanning@gmail.com>
An ealy return from checkpoint opening caused the writing flag
to be set incorrectly which caused the wrong execution path during
the close.
Also clean up space left behind by aborted checkpoints.
Also jsut neaten up NULL handling.
Signed-off-by: Charles Manning <cdhmanning@gmail.com>
yaffs_write_end may get called with copied == 0 if the requested write was
interrupted by a signal, but user-space will not restart the write if -ENOSPC
is returned.
Signed-off-by: Arve Hjønnevåg <arve@android.com>
