- 14 Jun, 2012 1 commit
-
-
Anton Vorontsov authored
All the functionality is now supported by pstore and pstore_ram drivers. Signed-off-by:
Anton Vorontsov <anton.vorontsov@linaro.org> Acked-by:
Kees Cook <keescook@chromium.org> Acked-by:
Colin Cross <ccross@android.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 13 Jun, 2012 22 commits
-
-
Anton Vorontsov authored
Having automatic updates seems pointless for production system, and even dangerous and thus counter-productive: 1. If we can mount pstore, or read files, we can as well read /proc/kmsg. So, there's little point in duplicating the functionality and present the same information but via another userland ABI; 2. Expecting the kernel to behave sanely after oops/panic is naive. It might work, but you'd rather not try it. Screwed up kernel can do rather bad things, like recursive faults[1]; and pstore rather provoking bad things to happen. It uses: 1. Timers (assumes sane interrupts state); 2. Workqueues and mutexes (assumes scheduler in a sane state); 3. kzalloc (a working slab allocator); That's too much for a dead kernel, so the debugging facility itself might just make debugging harder, which is not what we want. Maybe for non-oops message types it would make sense to re-enable automatic updates, but so far I don't see any use case for this. Even for tracing, it has its own run-time/normal ABI, so we're only interested in pstore upon next boot, to retrieve what has gone wrong with HW or SW. So, let's disable the updates by default. [1] BUG: unable to handle kernel paging request at fffffffffffffff8 IP: [<ffffffff8104801b>] kthread_data+0xb/0x20 [...] Process kworker/0:1 (pid: 14, threadinfo ffff8800072c0000, task ffff88000725b100) [... Call Trace: [<ffffffff81043710>] wq_worker_sleeping+0x10/0xa0 [<ffffffff813687a8>] __schedule+0x568/0x7d0 [<ffffffff8106c24d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff81087e22>] ? call_rcu_sched+0x12/0x20 [<ffffffff8102b596>] ? release_task+0x156/0x2d0 [<ffffffff8102b45e>] ? release_task+0x1e/0x2d0 [<ffffffff8106c24d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff81368ac4>] schedule+0x24/0x70 [<ffffffff8102cba8>] do_exit+0x1f8/0x370 [<ffffffff810051e7>] oops_end+0x77/0xb0 [<ffffffff8135c301>] no_context+0x1a6/0x1b5 [<ffffffff8135c4de>] __bad_area_nosemaphore+0x1ce/0x1ed [<ffffffff81053156>] ? ttwu_queue+0xc6/0xe0 [<ffffffff8135c50b>] bad_area_nosemaphore+0xe/0x10 [<ffffffff8101fa47>] do_page_fault+0x2c7/0x450 [<ffffffff8106e34b>] ? __lock_release+0x6b/0xe0 [<ffffffff8106bf21>] ? mark_held_locks+0x61/0x140 [<ffffffff810502fe>] ? __wake_up+0x4e/0x70 [<ffffffff81185f7d>] ? trace_hardirqs_off_thunk+0x3a/0x3c [<ffffffff81158970>] ? pstore_register+0x120/0x120 [<ffffffff8136a37f>] page_fault+0x1f/0x30 [<ffffffff81158970>] ? pstore_register+0x120/0x120 [<ffffffff81185ab8>] ? memcpy+0x68/0x110 [<ffffffff8115875a>] ? pstore_get_records+0x3a/0x130 [<ffffffff811590f4>] ? persistent_ram_copy_old+0x64/0x90 [<ffffffff81158bf4>] ramoops_pstore_read+0x84/0x130 [<ffffffff81158799>] pstore_get_records+0x79/0x130 [<ffffffff81042536>] ? process_one_work+0x116/0x450 [<ffffffff81158970>] ? pstore_register+0x120/0x120 [<ffffffff8115897e>] pstore_dowork+0xe/0x10 [<ffffffff81042594>] process_one_work+0x174/0x450 [<ffffffff81042536>] ? process_one_work+0x116/0x450 [<ffffffff81042e13>] worker_thread+0x123/0x2d0 [<ffffffff81042cf0>] ? manage_workers.isra.28+0x120/0x120 [<ffffffff81047d8e>] kthread+0x8e/0xa0 [<ffffffff8136ba74>] kernel_thread_helper+0x4/0x10 [<ffffffff8136a199>] ? retint_restore_args+0xe/0xe [<ffffffff81047d00>] ? __init_kthread_worker+0x70/0x70 [<ffffffff8136ba70>] ? gs_change+0xb/0xb Code: be e2 00 00 00 48 c7 c7 d1 2a 4e 81 e8 bf fb fd ff 48 8b 5d f0 4c 8b 65 f8 c9 c3 0f 1f 44 00 00 48 8b 87 08 02 00 00 55 48 89 e5 <48> 8b 40 f8 5d c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 RIP [<ffffffff8104801b>] kthread_data+0xb/0x20 RSP <ffff8800072c1888> CR2: fffffffffffffff8 ---[ end trace 996a332dc399111d ]--- Fixing recursive fault but reboot is needed! Signed-off-by:
-
Anton Vorontsov authored
There is no behavioural change, the default value is still 60 seconds. Signed-off-by:
-
Anton Vorontsov authored
The code tried to maintain the global list of persistent ram zones, which isn't a great idea overall, plus since Android's ram_console is no longer there, we can remove some unused functions. Signed-off-by:
-
Anton Vorontsov authored
Suggested-by:
Shuah Khan <shuahkhan@gmail.com> Signed-off-by:
-
Anton Vorontsov authored
Since we use multiple regions, the messages are somewhat annoying. We do print total mapped memory already, so no need to print the information for each region in the library routines. Signed-off-by:
-
Anton Vorontsov authored
The console log size is configurable via ramoops.console_size module option, and the log itself is available via <pstore-mount>/console-ramoops file. Signed-off-by:
-
Anton Vorontsov authored
This will help make code clearer when we'll add support for other message types. The patch also changes return value from -EINVAL to 0 in case of end-of-records. The exact value doesn't matter for pstore (it should be just <= 0), but 0 feels more correct. Signed-off-by:
-
Anton Vorontsov authored
This will help make code clearer when we'll add support for other message types. This also makes probe() much shorter and understandable, plus makes mem/record size checking a bit easier. Implementation detail: we now use a paddr pointer, this will be used for allocating persistent ram zones for other message types. Signed-off-by:
-
Anton Vorontsov authored
We're about to add support for other message types, so let's rename some variables to not be confused later. Signed-off-by:
-
Anton Vorontsov authored
Pstore doesn't support logging kernel messages in run-time, it only dumps dmesg when kernel oopses/panics. This makes pstore useless for debugging hangs caused by HW issues or improper use of HW (e.g. weird device inserted -> driver tried to write a reserved bits -> SoC hanged. In that case we don't get any messages in the pstore. Therefore, let's add a runtime logging support: PSTORE_TYPE_CONSOLE. Signed-off-by:
-
Greg Kroah-Hartman authored
We need this for the pstore fixes that went into the staging-linus branch, so that things apply properly for the pstore/android code merge. Signed-off-by: -
Anton Vorontsov authored
There's no reason to extern it. The patch fixes the annoying sparse warning: CHECK fs/pstore/inode.c fs/pstore/inode.c:264:5: warning: symbol 'pstore_fill_super' was not declared. Should it be static? Signed-off-by:
-
Anton Vorontsov authored
Otherwise, unlinked file will reappear on the next boot. Reported-by:
-
Anton Vorontsov authored
A handy function that we will use outside of ram_core soon. But so far just factor it out and start using it in post_init(). Signed-off-by:
-
Anton Vorontsov authored
Otherwise, the files will survive just one reboot, and on a subsequent boot they will disappear. Signed-off-by:
-
Anton Vorontsov authored
Without the update, we'll only see the new dmesg buffer after the reboot, but previously we could see it right away. Making an oops visible in pstore filesystem before reboot is a somewhat dubious feature, but removing it wasn't an intentional change, so let's restore it. For this we have to make persistent_ram_save_old() safe for calling multiple times, and also extern it. Signed-off-by:
-
Devendra Naga authored
Signed-off-by:
Devendra Naga <devendra.aaru@gmail.com> Signed-off-by:
-
H Hartley Sweeten authored
All of the config options for comedi depend on COMEDI being selected. Wrap everything in an 'if COMEDI/endif' block and remove all the individual 'depends on COMEDI' in the Kconfig. Also, remove the redundant && ISA/PCI/PCMCIA/USB for the if blocks with those driver types. Signed-off-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Cc: Ian Abbott <abbott@mev.co.uk> Cc: Frank Mori Hess <fmhess@users.sourceforge.net> Signed-off-by:
-
Chris Yungmann authored
Signed-off-by:
Chris Yungmann <yungmann.chris@gmail.com> Signed-off-by:
-
William Blair authored
Added a do ... while (0) to a multi statement macro and reformatted a similar macro. Signed-off-by:
William Blair <wdblair@bu.edu> Signed-off-by:
-
Peter Meerwald authored
Signed-off-by:
Peter Meerwald <pmeerw@pmeerw.net> Signed-off-by:
-
Peter Meerwald authored
Signed-off-by:
-
- 12 Jun, 2012 17 commits
-
-
H Hartley Sweeten authored
This symbol is not defined in the kernel. It appears to be left over from the 2.4 kernel. Signed-off-by:
-
Peter Meerwald authored
indentation of parameter description, fix parameter name (@dev -> @indio_dev) in comments, IIO device info structure -> IIO device structure Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Peter Meerwald authored
Signed-off-by:
-
Peter Meerwald authored
Signed-off-by:
-
Peter Meerwald authored
v2: * "used in in-kernel" (Jonathan Cameron) Signed-off-by:
-
Peter Meerwald authored
v2: address comments by Jonathan Cameron * add more output power down modes * spelling of etc. Signed-off-by:
-
Peter Meerwald authored
Signed-off-by:
-
Michael Hennerich authored
drivers/iio/frequency/ad9523.c:378 ad9523_vco_out_map() warn: value 2 can't fit into 1 'out' Signed-off-by:
Michael Hennerich <michael.hennerich@analog.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Peter Meerwald authored
v5: * fix warnings (Jonathan Cameron) v4: * remove unused indio_dev pointer in mcp4725_data (Jonathan Cameron) * use u16 instead of unsigned short in mcp4725_data (Jonathan Cameron) * #include mcp4725.h from linux/iio/dac/ v3: * move from staging to drivers/iio * switch to chan_spec * dev_get_drvdata() -> dev_to_iio_dev() * annotate probe() and remove() with __devinit and __devexit v2 (based on comments from Jonathan Cameron and Lars-Peter Clausen): * did NOT switch to chan_spec yet * rebase to staging-next tree, update iio header locations * dropped dac.h #include, not needed * strict_strtol() -> kstrtol() * call iio_device_unregister() in remove() * everything in one patch Signed-off-by:
-
Dan Carpenter authored
GCC complains that we use an uninitialized variable if the user passes an invalid parameter to adf4350_read(). I decided that we should return -EINVAL instead in that case. However, when I looked up at adf4350_write() it returned -ENODEV for that condition. In the end, I decided the -EINVAL was the right thing and I change adf4350_write() to match. Signed-off-by:
-
Dan Carpenter authored
Sparse complains about this: drivers/iio/frequency/adf4350.c:58:29: warning: Initializer entry defined twice drivers/iio/frequency/adf4350.c:59:10: also defined here It looks like '|' was intended here instead of ','. Signed-off-by:
-
Peter Meerwald authored
Signed-off-by:
Roland Stigge <stigge@antcom.de> Acked-by:
-
Peter Meerwald authored
Signed-off-by:
-
Dan Carpenter authored
There was a return path which got missed accidentally. Signed-off-by:
-
H Hartley Sweeten authored
Access the individual comedi_subdevices using a pointer instead of directly accessing as an array. This is how the rest of the comedi core accesses them. Signed-off-by:
-
H Hartley Sweeten authored
comedi_alloc_subdevices can fail with -EINVAL or -ENOMEM. When it does fail make sure to pass the proper error code back. Signed-off-by:
-
H Hartley Sweeten authored
These comments are redundant. The function name 'comedi_alloc_subdevices' provides this information. Signed-off-by:
-
