We want to ensure that we get all the console messages, even ones
that occur while the printing CPU is not yet online.
Change-Id: I1d2694d05ac9415669a92f38efdd8e71c927705b
Signed-off-by: Dima Zavin <dima@android.com>
This reverts commit ffdab0c0c4.
Not needed anymore in 2.6.39 and 3.0, dev_get_stats has been fixed
and may be called from atomic context. See:
1ac9ad1 net: remove dev_txq_stats_fold()
Make sure there is no pending ctrlrequest before removing the config.
Otherwise the ctrlrequest complete callback could access structures
after they have been freed. Unbind cancels pending transfers but not
ep0 requests.
Bug: 5513065 5440193
Change-Id: I063c22bf5d104a3d2df71cf622409459fac5f27a
Signed-off-by: Benoit Goby <benoit@android.com>
If an idle notifier modifies a timer, calling the notifier after
the sched tick has been stopped may leave the sched tick set too
early. Move teh idle notifier call before the call to
tick_nohz_stop_sched_tick.
Change-Id: I0db3284bec6d0193bc5e2a57650ab06bd8342319
Signed-off-by: Colin Cross <ccross@android.com>
Reset next_string_id to 0 before enabling the gadget driver. Otherwise,
after a large number of enable/disable cycles, bind will fail
because we cannot allocate new string ids. String ids cannot be larger
than 254 per USB spec.
Change-Id: I44f5fece45008b7a0a18c025d4eb5ce842585c28
Signed-off-by: Benoit Goby <benoit@android.com>
This improves compatbility with a lot of headset / chipset
combinations. Ideally this should not be needed.
Change-Id: I8b676701e12e416aa7d60801b9d353b15d102709
Signed-off-by: hyungseoung.yoo <hyungseoung.yoo@samsung.com>
Signed-off-by: Jaikumar Ganesh <jaikumarg@android.com>
The current code checks if abs(delta_delta.tv_sec) is greater or
equal to two before it discards the old delta value, but this can
trigger at close to -1 seconds since -1.000000001 seconds is stored
as tv_sec -2 and tv_nsec 999999999 in a normalized timespec.
rtc_resume had an early return check if the rtc value had not changed
since rtc_suspend. This effectivly stops time for the duration of the
short sleep. Check if sleep_time is positive after all the adjustments
have been applied instead since this allows the old_system adjustment
in rtc_suspend to have an effect even for short sleep cycles.
Change-Id: I00b45c0349ec91a4bab9b41a126b377515427898
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Arve suggested making sure we catch possible negative sleep time
intervals that could be passed into timekeeping_inject_sleeptime.
CC: Arve Hjønnevåg <arve@android.com>
CC: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Because the RTC interface is only a second granular interface,
each time we read from the RTC for suspend/resume, we introduce a
half second (on average) of error.
In order to avoid this error accumulating as the system is suspended
over and over, this patch measures the time delta between the RTC
and the system CLOCK_REALTIME.
If the delta is less then 2 seconds from the last suspend, we compensate
by using the previous time delta (keeping it close). If it is larger
then 2 seconds, we assume the clock was set or has been changed, so we
do no correction and update the delta.
Note: If NTP is running, ths could seem to "fight" with the NTP corrected
time, where as if the system time was off by 1 second, and NTP slewed the
value in, a suspend/resume cycle could undo this correction, by trying to
restore the previous offset from the RTC. However, without this patch,
since each read could cause almost a full second worth of error, its
possible to get almost 2 seconds of error just from the suspend/resume
cycle alone, so this about equal to any offset added by the compensation.
Further on systems that suspend/resume frequently, this should keep time
closer then NTP could compensate for if the errors were allowed to
accumulate.
Credits to Arve Hjønnevåg for suggesting this solution.
This patch also improves some of the variable names and adds more clear
comments.
CC: Arve Hjønnevåg <arve@android.com>
CC: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
The current split between this and the fiq debugger is awkward and does
not have any benefit (the interface between the two is also too simplistic).
The fiq debugger code itself needs a lot of refactoring, part of which
would be to split out some components that are arch indpendent.
So, for now, move this very small piece back into the fiq_debugger.
Change-Id: Ie4ec2a2f5d907be1691a0eb6ae9304aad29ecd14
Signed-off-by: Dima Zavin <dima@android.com>
If the fiq console is enabled, then don't filter the console output
while sysrq command is in progress.
Change-Id: I9389d757373a5fdca5cbf61f0723667510d3ae88
This code is moved here from the drivers/misc/kernel_debugger.
Change-Id: Iccf21c4313a8516a917125ca93f64baa5f354228
Signed-off-by: Dima Zavin <dima@android.com>
* Add attribute hispeed_freq, which defaults to max.
* Rename go_maxspeed_load to go_hispeed_load.
* If hit go_hispeed_load and at min speed, go to hispeed_freq;
if hit go_hispeed_load and already above min speed go to max
speed.
Change-Id: I1050dec5f013fc1177387352ba787a7e1c68703e
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Calculate intermediate speed by applyng CPU load to current speed, not
max speed.
Change-Id: Idecf598b9a203b07c989c5d9e9c6efc67a1afc2e
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Such that interactive cpufreq governor uses up-to-date idle time
information.
Reported by Colin Cross <ccross@android.com>
Change-Id: I06425444f800f803afc9dc7a6ad0fdb46c918bb6
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Currently, calling tcp_nuke_addr to reset IPv6 connections
resets IPv4 connections as well, because all Android
framework sockets are dual-stack (i.e., IPv6) sockets, and
we don't check the source address to see if the connection
was in fact an IPv4 connection.
Fix this by checking the source address and not resetting
the connection if it's a mapped address.
Also slightly tweak the IPv4 code path, which doesn't check
for mapped addresses either. This was not causing any
problems because tcp_is_local normally always returns true
for LOOPBACK4_IPV6 (127.0.0.6), because the loopback
interface is configured as as 127.0.0.0/8. However,
checking explicitly for LOOPBACK4_IPV6 makes the code a bit
more robust.
Bug: 5535055
Change-Id: I4d6ed3497c5b8643c864783cf681f088cf6b8d2a
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Under the following conditions, __alloc_pages_slowpath can loop
forever:
gfp_mask & __GFP_WAIT is true
gfp_mask & __GFP_FS is false
reclaim and compaction make no progress
order <= PAGE_ALLOC_COSTLY_ORDER
The gfp conditions are normally invalid, because !__GFP_FS
disables most of the reclaim methods that __GFP_WAIT would
wait for. However, these conditions happen very often during
suspend and resume, when pm_restrict_gfp_mask() effectively
converts all GFP_KERNEL allocations into __GFP_WAIT.
The oom killer is not run because gfp_mask & __GFP_FS is false,
but should_alloc_retry will always return true when order is less
than PAGE_ALLOC_COSTLY_ORDER. __alloc_pages_slowpath will
loop forever between the rebalance label and should_alloc_retry,
unless another thread happens to release enough pages to satisfy
the allocation.
Add a check to detect when PM has disabled __GFP_FS, and do not
retry if reclaim is not making any progress.
[taken from patch on lkml by Mel Gorman, commit message by ccross]
Change-Id: I864a24e9d9fd98bd0e3d6e9c1e85b6c1b766850e
Signed-off-by: Colin Cross <ccross@android.com>
Add some logging to make it clear just how the emmc timeout
was handled.
Change-Id: Id33fd28d8b9778dc4e85db829e2637a328eddab4
Signed-off-by: Ken Sumrall <ksumrall@android.com>
Check the status bits in the r/w command response for any errors.
If error bits are set, then we won't have seen any data transferred,
so it's pointless doing any further checking.
Change-Id: If118a4bcbb0e57a7d95b5e40d662fca87fdcba7f
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Command channel errors fall into four classes:
1. The command was issued with the card in the wrong state
2. The command failed to be received by the card correctly
3. The cards response failed to be received by the host (CRC error)
4. The card failed to respond to the card
For (1), in theory we should know that the card is in the correct state.
However, a failed stop command (or other failure) may result in the card
remaining in a data transfer state from the previous command. If we
detect this condition, we try to recover by sending a stop command.
For the initial commands (set block count and the read/write command)
no data will have been transferred. All that we need deal with is
retrying at this point. A failed stop command can be remedied as
above.
If we are unable to recover the card (eg, the card ignores our requests
for status, or we don't recognise the error code) then we immediately
fail the request.
Change-Id: Ief109a57fd21a247381b38f1164c22f0344f0284
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
