Displaying 6 results from an estimated 6 matches for "ftrace_dump_on_oop".
Did you mean:
ftrace_dump_on_oops
2017 Jul 11
4
[regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335
..., you have plugged into the NVIDIA board when
> this happens?
A Philips 273V, via DVI.
> 3. Any boot parameters, esp relating to ACPI, PM, or related?
None for those, what's there that will be unfamiliar to you are for
patches that aren't applied.
nortsched hpc_cpusets skew_tick=1 ftrace_dump_on_oops audit=0
nodelayacct cgroup_disable=memory rtkthreads=1 rtworkqueues=2 panic=60
ignore_loglevel crashkernel=256M,high
-Mike
2017 Jul 11
0
[regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335
...n
>> this happens?
>
> A Philips 273V, via DVI.
>
>> 3. Any boot parameters, esp relating to ACPI, PM, or related?
>
> None for those, what's there that will be unfamiliar to you are for
> patches that aren't applied.
>
> nortsched hpc_cpusets skew_tick=1 ftrace_dump_on_oops audit=0
> nodelayacct cgroup_disable=memory rtkthreads=1 rtworkqueues=2 panic=60
> ignore_loglevel crashkernel=256M,high
OK, thanks. So in other words, a fairly standard desktop with a PCIe
board plugged in. No funny business. (Laptops can create a ton of
additional weirdness, which I assum...
2017 Jul 11
2
[regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335
Greetings,
I met $subject in master-rt post drm merge, but taking the config
(attached) to virgin v4.12-10624-g9967468c0a10, it's reproducible.
KERNEL: vmlinux-4.12.0.g9967468-preempt.gz
DUMPFILE: vmcore
CPUS: 8
DATE: Tue Jul 11 18:55:28 2017
UPTIME: 00:02:03
LOAD AVERAGE: 3.43, 1.39, 0.52
TASKS: 467
NODENAME: homer
RELEASE:
2016 Jul 28
0
[PATCH 6/7] qemu: Implement virtio-pstore device
...linux is crashing. I think you want something very very
> simple that will still work when you crash. Like maybe
> a serial device?
Well, I dont' know. As you know, the kernel oops dump is already sent
to serial device but it's rather slow. As I wrote in the cover
letter, enabling ftrace_dump_on_oops makes it even worse.. Also
pstore saves the (compressed) binary data so I thought it'd be better
to have a dedicated IO channel.
I know that we can't rely on anything in kernel when the kernel is
crashing. In the virtualization environment, I think it'd be great if
it can dump the c...
2016 Jul 28
3
[PATCH 6/7] qemu: Implement virtio-pstore device
On Thu, Jul 28, 2016 at 12:08:30AM +0900, Namhyung Kim wrote:
> Add virtio pstore device to allow kernel log files saved on the host.
> It will save the log files on the directory given by pstore device
> option.
>
> $ qemu-system-x86_64 -device virtio-pstore,directory=dir-xx ...
>
> (guest) # echo c > /proc/sysrq-trigger
So if the point is handling system crashes, I
2016 Jul 28
3
[PATCH 6/7] qemu: Implement virtio-pstore device
On Thu, Jul 28, 2016 at 12:08:30AM +0900, Namhyung Kim wrote:
> Add virtio pstore device to allow kernel log files saved on the host.
> It will save the log files on the directory given by pstore device
> option.
>
> $ qemu-system-x86_64 -device virtio-pstore,directory=dir-xx ...
>
> (guest) # echo c > /proc/sysrq-trigger
So if the point is handling system crashes, I