Re: Will all kernel functions be loaded into memory, in the same address space with kernel modules?
On Tue, Jan 27, 2015 at 6:21 AM, Yue Chen ycyc...@gmail.com wrote: 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. Take a look at this branch: https://github.com/HardenedBSD/hardenedBSD/tree/hardened/current/intel-smap ___ 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 ___ 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
Callout lockups and spin-lock held to long panic..
All: I just wanted to send a note to let folks know I have finally dug to the bottom of the crashes that Sean Bruno has been seeing and will shortly have a fix committed for it. The problem was related to two callout_reset’s being run with migration happening and that callout was executing (or waiting to execute). The twin callout resets would in the end each remove the entry from the linked list (twice) thus corrupting the linked list. The software code would thus run, holding the CC_lock spinning forever going through the linked list.. causing the crash. I was able to reproduce this in a branch at netflix here so I can prove that the fix I have actually fixes the issue. It will be a couple more days of proving things out, followed by hopefully getting interested reviewer’s to review the patch.. and then from there I can commit it to head .. Best wishes R -- Randall Stewart 803-317-4952 (cell) ___ 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
panic in softdep_slowdown()
Got this in bhyve VM on boot up and mount: Starting file system checks: /dev/vtbd0p3: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/vtbd0p3: clean, 1617700 free (222876 frags, 174353 blocks, 5.9% fragmentation) Fatal trap 18: integer divide fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0x80895d63 stack pointer = 0x28:0xfe001eb5f220 frame pointer = 0x28:0xfe001eb5f2b0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 49 (mount) [ thread pid 49 tid 100045 ] Stopped at softdep_slowdown+0x1d3: idivl %ecx,%eax db bt Tracing pid 49 tid 100045 td 0xf800026ee000 softdep_slowdown() at softdep_slowdown+0x1d3/frame 0xfe001eb5f2b0 ffs_truncate() at ffs_truncate+0x1be/frame 0xfe001eb5f640 ufs_setattr() at ufs_setattr+0x4e5/frame 0xfe001eb5f6a0 VOP_SETATTR_APV() at VOP_SETATTR_APV+0x22a/frame 0xfe001eb5f710 VOP_SETATTR() at VOP_SETATTR+0x45/frame 0xfe001eb5f760 vn_truncate() at vn_truncate+0x196/frame 0xfe001eb5f870 fo_truncate() at fo_truncate+0x41/frame 0xfe001eb5f8b0 kern_ftruncate() at kern_ftruncate+0x16d/frame 0xfe001eb5f920 sys_ftruncate() at sys_ftruncate+0x27/frame 0xfe001eb5f940 syscallenter() at syscallenter+0x46e/frame 0xfe001eb5f9b0 amd64_syscall() at amd64_syscall+0x1f/frame 0xfe001eb5fab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe001eb5fab0 --- syscall (480, FreeBSD ELF64, sys_ftruncate), rip = 0x800b511fa, rsp = 0x7fffe998, rbp = 0x7fffeb90 --- db call doadump Dumping 60 out of 495 MB:..27%..54%..80% Dump complete = 0 db I've got the core file. -- Totus tuus, Glebius. ___ 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: Jenkins build became unstable: FreeBSD_HEAD-tests2 #604
On Tue, Jan 27, 2015 at 12:21 PM, jenkins-ad...@freebsd.org wrote: See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/604/ One of the expr tests seems to have broken after this change: https://lists.freebsd.org/pipermail/svn-src-all/2015-January/098238.html Can you take a look? -- Craig ___ 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
Jenkins build became unstable: FreeBSD_HEAD-tests2 #604
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/604/ ___ 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: Jenkins build became unstable: FreeBSD_HEAD-tests2 #604
On Tue, Jan 27, 2015 at 1:31 PM, Craig Rodrigues rodr...@freebsd.org wrote: On Tue, Jan 27, 2015 at 12:21 PM, jenkins-ad...@freebsd.org wrote: See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/604/ One of the expr tests seems to have broken after this change: https://lists.freebsd.org/pipermail/svn-src-all/2015-January/098238.html Can you take a look? Stefan enhanced bin/expr to do better overflow detection, so r277357 can be reverted. This can be verified like so: cd bin/expr/tests make obj; make depend; make all; sudo make install (cd /usr/tests/bin/expr; kyua test) Thanks! ___ 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
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #605
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/605/ ___ 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
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #606
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/606/ ___ 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
Questions on adding backlight support for the i915 driver
Hello, I want to add backlight support to the i915 driver in FreeBSD. It seems that two magic addresses are read and wrote from to change the backlight itself. It supports rather fine-level granularity all the way down to zero. Right now I use a hacked-up userland program that reads from/writes to these addresses, which is far from an ideal solution. I am interested in this because the acpi_video(4) driver does not support my backlight on my Dell Inspiron 15 3521 (not terribly suprising, on Linux I needed a special Dell-specific driver, and I'm not sure even that really used ACPI, I never really checked). My questions are really twofold: 1) How can this be exposed appropriately? I would prefer this be exposed generally so upower could grok it. As far as I can tell upower uses hw.acpi.video.lcd0 to control backlight. I am not sure that upower is doing the right thing here, though. 2) Where would the code go for this? The dri2 driver seems the most logical place, but maybe it belongs in X and exposed via a program? Or something else entirely that I'm not thinking of? I have experience developing PCI drivers and doing other PCI related doodads, and some kernel development experience, as well as general C experience, but I'm not by any means an expert on the matter. Cheers, Elizabeth Myers ___ 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: 27 January 2015 23:42: The regression was introduced in r277487. Looking closer at this revision, I believe I may see the issue. Most of the new tunables introduced in dev/drm2/i915/i915_drv.c are uninitialised and thus probably contain junk. It likely works for me because the firmware of my laptop 0s memory on EFI boot. I have uploaded a diff here that I believe may fix this. Please test and let me know: http://foxkit.us/FreeBSD/i915-uninitialised-var-fix.diff 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
RE: drm2 regression: backlight adjustment on ivybridge no longer works
Ranjan1018 . sent: 27 January 2015 23:42: my Samsung laptop has an Intel IvyBridge: [snip] The regression was introduced in r277487. The backlight adjustment works in FreeBSD 11.0-CURRENT r277395, r277486 but not in r277487, r277534 and r277639. Hrm. That is interesting. A few questions I have then. - What happens if you set drm.i915.invert_brightness to -1 in kenv(1) or /boot/loader.conf? - What happens if you set drm.i915.invert_brightness to 1 in kenv(1) or /boot/loader.conf? - What version of graphics/libdrm do you have installed? Did you rebuild it after installing the new kernel? (This shouldn't be necessary, but I am trying to gather all details.) Let's start there and see if we can pin down a cause. 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
bmake and .USEBEFORE
If I try the following: bar: .USE @echo @ = $(@) all: bar @echo here is all I always get bar is up to date Does anyone know how this is supposed to work? ___ 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
2015-01-27 7:38 GMT+01:00 Andrew Wilcox awil...@wilcox-tech.com: 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 Hi, my Samsung laptop has an Intel IvyBridge: vgapci0@pci0:0:2:0: class=0x03 card=0xc708144d chip=0x01668086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '3rd Gen Core processor Graphics Controller' class = display subclass = VGA The regression was introduced in r277487. The backlight adjustment works in FreeBSD 11.0-CURRENT r277395, r277486 but not in r277487, r277534 and r277639. 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: bmake and .USEBEFORE
On 1/28/15 1:41 PM, Julian Elischer wrote: If I try the following: bar: .USE @echo @ = $(@) all: bar @echo here is all oops the failing example should be .USEBEFORE.. I pasted the wrong clip. I always get bar is up to date Does anyone know how this is supposed to work? ___ 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 ___ 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
CURRENT fails to build: make_hash.c : error: indirection requires pointer operand
Somehow one of my boxes got a wrecked system during an update cycle. Now the
system
rejects building world with the error shown below. I also tried to cleanup
everything
(/usr/obj deleting) and performing a make toolchain - without success.
Is there a way to repair this mess?
[...]
cc -o make_hash -O2 -pipe -O3 -pipe -O3 -I.
-I/usr/obj/usr/src/lib/ncurses/ncurses/../ncurses
-I/usr/src/lib/ncurses/ncurses/../ncurses
-I/usr/src/lib/ncurses/ncurses/../ncurses
-I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include
-I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall -DNDEBUG
-DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=gnu99 -Qunused-arguments
-I/usr/obj/usr/src/tmp/legacy/usr/include
-DMAIN_PROGRAM
/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/make_hash.c
/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/make_hash.c:100:25:
error: indirection requires pointer operand ('int' invalid) return (int) (sum %
HASHTABSIZE); ^~~ ./hashsize.h:6:23: note: expanded from macro
'HASHTABSIZE'
#define HASHTABSIZE ( * 2) ^
~
/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/make_hash.c:111:21:
error: indirection requires pointer operand ('int' invalid) for (i = 0; i
HASHTABSIZE;
i++) { ^~~ ./hashsize.h:6:23: note: expanded from macro 'HASHTABSIZE'
#define
HASHTABSIZE ( * 2) ^
~
/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/make_hash.c:114:31:
error: expected expression for (i = 0; i CAPTABSIZE; i++)
{ ^
/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/make_hash.c:125:77:
error: expected expression printf(/* %d collisions out of %d entries */\n,
collisions,
CAPTABSIZE);
^
/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/make_hash.c:194:43:
error: expected expression struct name_table_entry *name_table =
typeCalloc(struct ^
/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/nc_alloc.h:107:59:
note:
expanded from macro 'typeCalloc' #define typeCalloc(type,elts) (type
*)calloc((size_t)(elts),sizeof(type)) ^
/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/make_hash.c:196:51:
error: indirection requires pointer operand ('int' invalid) HashValue
*hash_table =
typeCalloc(HashValue, HASHTABSIZE); ^~~
./hashsize.h:6:23: note: expanded from macro 'HASHTABSIZE'
#define HASHTABSIZE ( * 2)
^ ~
/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/nc_alloc.h:107:55:
note:
expanded from macro 'typeCalloc' #define typeCalloc(type,elts) (type
*)calloc((size_t)(elts),sizeof(type)) ^
/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/make_hash.c:227:32:
error: expected expression for (n = 0; (n CAPTABSIZE) fgets(buffer,
BUFSIZ, stdin);)
{ ^
/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/make_hash.c:268:28:
error: expected expression for (n = 0; n CAPTABSIZE; n++) {
^
/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/make_hash.c:283:28:
error: expected expression for (n = 0; n CAPTABSIZE; n++) {
^
/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/make_hash.c:299:28:
error: expected expression for (n = 0; n CAPTABSIZE; n++) {
^
/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/make_hash.c:314:5:
error: indirection requires pointer operand ('int' invalid) HASHTABSIZE + 1);
^~~
./hashsize.h:6:23: note: expanded from macro 'HASHTABSIZE'
pgpCmAupGMzX5.pgp
Description: OpenPGP digital signature
