search for: ftrace_dump_on_oop

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