Re: drm2 regression: backlight adjustment on ivybridge no longer works
2015-01-24 23:25 GMT+01:00 Adrian Chadd adr...@freebsd.org: Hi, I've just found a regression. The backlight adjustment doesn't work on my ivybridge mobile laptop (Lenovo X230) after the dri update. I've added debugging. It's making it all the way to the pch backlight panel update routine in intel_panel.c, but it's not changing the backlight appearance itself. The intel_backlight program from intel-gpu-tools also no longer changes the backlight value. I'm going to finish rebuilding -HEAD on the sandy bridge laptop here and try it out. Thanks, -adrian Hi, I have the same issue on my Samsung Ativ 2 laptop. Regards, Maurizio ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Is anyone using the schedgraph.d script?
... ignore it for now; I ran some other profiling and then when I tried schedgraph.d again, it started spitting out events for that CPU. I'll file a PR if I see it happen more often. :( -a On 26 January 2015 at 12:05, Adrian Chadd adr...@freebsd.org wrote: Hi, I'm having problems with Ryan's schedgraph.d script (people.freebsd.org/~rstone/dtrace/) It runs fine, but if a CPU core is 100% busy, I get zero scheduler events logged from it. Said core is doing around 30,000 syscalls a second, around 250,000 context switches and 125,000 interrupt sa second - but whilst it's doing this, I get zero events from dtrace for said CPU. Has anyone hit this kind of situation before? -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Memory corruption in a master perl process after child exits - only under FreeBSD 10.0 amd64 (not in 10.1 or 9.*)
There is a problem report since July 2014 in a Perl bug tracker, which seems to affect only FreeBSD 10.0 amd64 (regardless of a version of Perl or usage of clang vs. gcc compiler): https://rt.perl.org/Ticket/Display.html?id=122199 I wonder if someone intimately familiar with handling of virtual memory, fork, swap, and process exit / wait(2) under FreeBSD would be able to recognize what has changed in these areas between 9.2 - 10.0 and 10.0 - 10.1, so that only 10.0 is misbehaving, but 10.1 apparently fixed the problem again. Below is my short summary of the issue (it is the last comment in the referenced problem report). Further details are in that PR. It's been a real mystery, difficult to reproduce, but definitely there. It might be a Perl bug, but it looks ever more likely that it is a FreeBSD issue. Mark After upgrading to FreeBSD 10.1 (from 10.0) and running the same application with the same version of Perl for two months now, with child process periodic retiring and re-spawning new child process by a master process as previously under FreeBSD 9.x, I can now confirm that the problem no longer occurs. I can also confirm that the problem under 10.0 can be avoided by not letting child processes to voluntarily exit, so the master process never sees a child termination in wait() and never needs to spawn (fork) another child process. A brief summary of the problem: Setup: an application consisting of a master perl process spawning worker child processes, which periodically voluntarily self-terminate, to be replaced by a fresh child process forked from the master process. Environent: - occurs only on FreeBSD 10.0 amd64, any recent version of perl, gcc or clang. - does not occur on FreeBSD 9.x or 10.1, and not on i383, not reproducible on Linux What seems to be happening: - a child process after doing some work (possibly touching swap) does a normal exit; - a parent process gets a SIGCHLD signal, handles a wait() and for some obscure reason some of its memory gets corrupted; - a parent process forks creating a new worker child process, which inherits corrupted sections of parent's memory, consequently later leading to its (child) crash if it happens to use that part of the memory (opcodes or data structures) during its normal work. Any newly born child process inherits the same memory corruption and crashes alike. So it seems the problem is somehow connected with how FreeBSD 10.0 on amd64 manages virtual memory (fork, exit, wait, possibly involving swap). The problem is apparently fixed in 10.1, and not present in 9.x. Does anybody have a sound explanation? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Is anyone using the schedgraph.d script?
Hi, I'm having problems with Ryan's schedgraph.d script (people.freebsd.org/~rstone/dtrace/) It runs fine, but if a CPU core is 100% busy, I get zero scheduler events logged from it. Said core is doing around 30,000 syscalls a second, around 250,000 context switches and 125,000 interrupt sa second - but whilst it's doing this, I get zero events from dtrace for said CPU. Has anyone hit this kind of situation before? -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Will all kernel functions be loaded into memory, in the same address space with kernel modules?
My purpose is to modify kernel function instructions directly through memory at runtime. First I use objdump -S kernel to see the function names and their addresses. And then I use pointers to peek into the content at certain function address area (.text segment). However, their content is different from the result from objdump -S kernel. I use a FreeBSD 10.1 kernel, which has no ASLR supported as I know. Is it because that the kernel function addresses are relocated? Or some kernel functions are not loaded into memory? Or is it not suitable to peek kernel .text content from a kernel module? I only objdump -S the built kernel with debug symbols, not .ko files. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Is anyone using the schedgraph.d script?
On 26 January 2015 at 19:01, Ryan Stone ryst...@gmail.com wrote: Hm, there was one bug in that script. I uploaded a fixed version. The fix was: - printf(%d %d KTRGRAPH group:\thread\, id:\%s/%s tid %d\, state:\runq add\, attributes: prio:%d, linkedto:\%s/%s tid %d\\n, cpu, timestamp, args[0]-td_proc-p_comm, args[0]-td_name, args[0]-td_tid, args[0]-td_priority, curthread-td_proc-p_comm, curthread-td_name, args[0]-td_tid); + printf(%d %d KTRGRAPH group:\thread\, id:\%s/%s tid %d\, state:\runq add\, attributes: prio:%d, linkedto:\%s/%s tid %d\\n, cpu, timestamp, args[0]-td_proc-p_comm, args[0]-td_name, args[0]-td_tid, args[0]-td_priority, curthread-td_proc-p_comm, curthread-td_name, curthread-td_tid); Note that the last printf argument used args[0] instead of curthread as intended. Cool! Thanks! One other thing that I have noticed with the schedgraph data gathering is that unlike KTR, in dtrace every CPU gathers its data into a CPU-local buffer. This can mean that a CPU that sees a large number of scheduler events will roll over its ring buffer much more quickly than a lightly loaded CPU. This can lead to a confusing or misleading schedgraph output at the beginning of the time period. You can mitigate this problem by allowing dtrace to allocate a larger ring buffer with: #pragma D option bufsize=32m (You can potentially tune it even higher than that, but that's a good place to start) Finally, I've noticed that schedgraph seems to have problems auto-detecting the clock frequency, so I tend to forcifully specify 1GHz (dtrace always outputs time in units of ns, so this is always correct to do with dtrace-gather data) Good to know. Is there any reason why this isn't just checked into -HEAD and -10? -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Is anyone using the schedgraph.d script?
Hm, there was one bug in that script. I uploaded a fixed version. The fix was: - printf(%d %d KTRGRAPH group:\thread\, id:\%s/%s tid %d\, state:\runq add\, attributes: prio:%d, linkedto:\%s/%s tid %d\\n, cpu, timestamp, args[0]-td_proc-p_comm, args[0]-td_name, args[0]-td_tid, args[0]-td_priority, curthread-td_proc-p_comm, curthread-td_name, args[0]-td_tid); + printf(%d %d KTRGRAPH group:\thread\, id:\%s/%s tid %d\, state:\runq add\, attributes: prio:%d, linkedto:\%s/%s tid %d\\n, cpu, timestamp, args[0]-td_proc-p_comm, args[0]-td_name, args[0]-td_tid, args[0]-td_priority, curthread-td_proc-p_comm, curthread-td_name, curthread-td_tid); Note that the last printf argument used args[0] instead of curthread as intended. One other thing that I have noticed with the schedgraph data gathering is that unlike KTR, in dtrace every CPU gathers its data into a CPU-local buffer. This can mean that a CPU that sees a large number of scheduler events will roll over its ring buffer much more quickly than a lightly loaded CPU. This can lead to a confusing or misleading schedgraph output at the beginning of the time period. You can mitigate this problem by allowing dtrace to allocate a larger ring buffer with: #pragma D option bufsize=32m (You can potentially tune it even higher than that, but that's a good place to start) Finally, I've noticed that schedgraph seems to have problems auto-detecting the clock frequency, so I tend to forcifully specify 1GHz (dtrace always outputs time in units of ns, so this is always correct to do with dtrace-gather data) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: drm2 regression: backlight adjustment on ivybridge no longer works
Ranjan1018 . sent: 26 January 2015 06:19: 2015-01-24 23:25 GMT+01:00 Adrian Chadd adr...@freebsd.org: The backlight adjustment doesn't work on my ivybridge mobile laptop (Lenovo X230) after the dri update. I have the same issue on my Samsung Ativ 2 laptop. I have a Sandy Bridge laptop (Apple MacBook Pro 8,2) - HD 3000: vgapci0@pci0:0:2:0: class=0x03 card=0x00db106b chip=0x01268086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family Integrated Graphics Controller' class = display subclass = VGA It is running: FreeBSD pwyll.foxkit.us 11.0-CURRENT #1 r277781M: Mon Jan 26 18:41:15 CST 2015 r...@pwyll.foxkit.us:/usr/obj/usr/src/sys/GENERIC amd64 I have no issues using acpi_video's sysctls (hw.acpi.video.lcd0.brightness) to adjust backlight, though it does not have good granularity. The stepping is about 7, so it goes as 13%..20%..27%..35%..etc. The intel_backlight program from intel-gpu-tools also no longer changes the backlight value. This program works fine for me on both an older kernel (r277523) and this kernel (r277781), after applying some patches to allow the library to build on FreeBSD. It also has better granularity (the stepping is 2-3). If there is anything I can do/run to aide in debugging why it works for me but not others, let me know. Best, Andrew -- Andrew Wilcox, C/C++/Python developer, kernel hacker Blog: http://blog.foxkit.us/ WWW: http://foxkit.us/ GitHub: https://github.com/awilfox ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
