FreeBSD_HEAD-tests - Build #1057 - Fixed
FreeBSD_HEAD-tests - Build #1057 - Fixed: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1057/ to view the results. ___ 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
Vendor code grouping
Hi, I'm currently working on a device driver port and given its architecture I would need to add some vendor maintained code to vendor-sys. In this particular case I know that there is some code from this vendor (Cavium) already present in vendor-sys (namely octeon-sdk). It deals with the same hardware as my driver but from a different perspective. The octeon-sdk works with Octeon processor as a FreeBSD host whereas the code I have to put into vendor-sys (let's call it cnnic-sdk) works from a device perspective (Octeon is a PCIe target). Normally I would assume that the correct place to put the new vendor code would be a new directory (i.e. vendor-sys/cnnic-sdk/dist), however in this case I was thinking whether it would make sense (and/or is allowed) to group those two pieces of software as sub-directories of a single vendor directory: cavium? If I'm not mistaken there is already something similar done with vendor/NetBSD but each sub-project lives inside the same repository (in dist). In my case I would like to have the two Octeon related projects in separate repositories as they are developed and updated separately. At the same time I don't want to re-invent the wheel or do something not in FreeBSD spirit of work. So to sum things up what would make the most sense: 1. Put my vendor code into a new directory in vendor-sys (i.e. vendor-sys/cnnic-sdk/dist), 2. Create vendor-sys/cavium and put octeon-sdk into vendor-sys/cavium/octeon-sdk/dist and my code into vendor-sys/cavium/cnnic-sdk/dist, 3. Create vendor-sys/cavium/dist and put octeon-sdk into vendor-sys/cavium/dist/octeon-sdk and my code into vendor-sys/cavium/dist/cnnic-sdk? Thanks in advance for Your help! -- Best Regards, Stanisław Kardach ___ 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: am335x-bone.dts not exist
On May 24, 2015, at 7:44 PM, Tim Kientzle t...@kientzle.com wrote: On May 24, 2015, at 12:55 AM, Oleksandr Tymoshenko go...@bluezbox.com wrote: On May 24, 2015, at 12:12 AM, Garrett Cooper yaneurab...@gmail.com wrote: On May 24, 2015, at 0:07, Oleksandr Tymoshenko go...@bluezbox.com wrote: On May 23, 2015, at 7:21 PM, Andrey Fesenko f0and...@gmail.com wrote: # uname -a FreeBSD des.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r283306: Sat May 23 11:56:46 MSK 2015 root@des.local:/usr/obj/usr/src/sys/GENERIC amd64 I'm build BEAGLEBONE with crochet. build error Mounting UFS partition 1 at /usr/obj/_.mount.freebsd Installing U-Boot from : /usr/local/share/u-boot/u-boot-beaglebone Error: beaglebone.dts:29.1-2 syntax error FATAL ERROR: Unable to parse input tree file /usr/src/sys/boot/fdt/dts/arm/beaglebone.dts contain #include am335x-bone.dts but this file not existence. Need use am335x-evm.dts or else? am335x-bone.dts in in sys/gnu/dts/arm/, it's a file provided by vendor (TI) I guess crochet does not have this path as include path when compiling dts files. Pardon me for being a bit daft potentially, but shouldn’t #include work for all dts files (look for #include in this doc: http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf )? Thanks! #include in dts file is handled by cpp(1). /include/ is handled by dtc I believe You can take a look at how FreeBSD compiles dts files in sys/tools/fdt/make_dtb.sh crochet does not have cpp stage of compilation and before my TI code/devicetree refactoring none of the dts files referenced in crochet used #include. That's why problem never appeared. Fix is just a matter of fixing freebsd_install_fdt in lib/freebsd.sh. If nobody beats me to it I'll try to fix it and submit pull request to Tim. I’m testing a fix for this now. Thanks for providing such detailed information. Is there any reason the standard dts to dtb script isn’t being used instead of enshrining another copy of that outside the tree which may break if/when we need to enhance the current script? Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: cam(4) timeouts in bhyve/kyua runs up on Jenkins?
On Apr 28, 2015, at 0:54, Alexander Motin m...@freebsd.org wrote: Hi. On 27.04.2015 21:17, Garrett Cooper wrote: On Apr 27, 2015, at 11:16, Garrett Cooper yaneurab...@gmail.com wrote: I was looking at the console log for the latest kyua run and I’ve noticed that it’s timing out a bit more [1] than it was previously [2]. I’ve seen some of your commits recently to cam(4) dealing with bhyve — has there been a performance regression there? Thanks! -NGie 1. https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/940/console 2. https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/983/console (Sorry for not being more explicit for the archives) These are the timeouts I’m referring to: ahcich0: is cs ss 1f00 rs 1f00 tfd 50 serr cmd 1000dc17 (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 08 a8 54 1e 40 00 00 00 00 00 00 (ada0:ahcich0:0:0:0): CAM status: Command timeout (ada0:ahcich0:0:0:0): Retrying command Last time I was more working on bhyve host disk emulation, rather then on cam(4) running on guest. Considering that, what guest and what host versions are you running? Is there any other load on host except this VM that could cause I/O delays high enough to trigger timeouts? What are you using to back the virtual disk (file, zvol, ...)? I have no idea what the Jenkins slaves are running in terms of configuration/version/etc. You’ll have to ask jenkins-admin@… Thanks! -NGie signature.asc Description: Message signed with OpenPGP using GPGMail
Linuxulator: CRASH
I have a boinc-client installation running World Community Grid science that's been working fine for months. Updated to current -HEAD, and now we crash the kernel if it's running. The backtrace points to the linuxulator. Ideas? borg.lerctr.org dumped core - see /var/crash/vmcore.17 Mon May 25 15:38:26 CDT 2015 FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #45 r283537: Mon May 25 15:10:23 CDT 2015 r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0xfe2e7240 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80e96273 stack pointer = 0x28:0xfe2eb49c7600 frame pointer = 0x28:0xfe2eb49c7610 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 = 1128 (wcgrid_fahv_vina_pr) trap number = 12 panic: page fault cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe2eb49c7150 vpanic() at vpanic+0x189/frame 0xfe2eb49c71d0 panic() at panic+0x43/frame 0xfe2eb49c7230 trap_fatal() at trap_fatal+0x379/frame 0xfe2eb49c7290 trap_pfault() at trap_pfault+0x22e/frame 0xfe2eb49c7330 trap() at trap+0x4b5/frame 0xfe2eb49c7540 calltrap() at calltrap+0x8/frame 0xfe2eb49c7540 --- trap 0xc, rip = 0x80e96273, rsp = 0xfe2eb49c7600, rbp = 0xfe2eb49c7610 --- copystr() at copystr+0x13/frame 0xfe2eb49c7610 namei() at namei+0xdb/frame 0xfe2eb49c76d0 kern_execve() at kern_execve+0x24c/frame 0xfe2eb49c7a20 linux_common_execve() at linux_common_execve+0x84/frame 0xfe2eb49c7a60 linux_execve() at linux_execve+0xad/frame 0xfe2eb49c7ae0 ia32_syscall() at ia32_syscall+0x288/frame 0xfe2eb49c7bf0 Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfe2eb49c7bf0 --- syscall (0, Linux ELF32, linux_nosys), rip = 0x8048110, rsp = 0xcca4, rbp = 0 --- Uptime: 1m33s Dumping 2647 out of 64457 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/linux_common.ko.symbols...done. Loaded symbols for /boot/kernel/linux_common.ko.symbols Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. Loaded symbols for /boot/kernel/if_lagg.ko.symbols Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done. Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done. Loaded symbols for /boot/kernel/snd_spicds.ko.symbols Reading symbols from /boot/kernel/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel/coretemp.ko.symbols Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. Loaded symbols for /boot/kernel/ichsmb.ko.symbols Reading symbols from /boot/kernel/smbus.ko.symbols...done. Loaded symbols for /boot/kernel/smbus.ko.symbols Reading symbols from /boot/kernel/ichwd.ko.symbols...done. Loaded symbols for /boot/kernel/ichwd.ko.symbols Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. Loaded symbols for /boot/kernel/cpuctl.ko.symbols Reading symbols from /boot/kernel/crypto.ko.symbols...done. Loaded symbols for /boot/kernel/crypto.ko.symbols Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. Loaded symbols for /boot/kernel/cryptodev.ko.symbols Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. Loaded symbols for /boot/kernel/dtraceall.ko.symbols Reading symbols from /boot/kernel/profile.ko.symbols...done. Loaded symbols for /boot/kernel/profile.ko.symbols Reading symbols from /boot/kernel/dtrace.ko.symbols...done. Loaded symbols for /boot/kernel/dtrace.ko.symbols Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols Reading symbols from /boot/kernel/systrace.ko.symbols...done. Loaded symbols for /boot/kernel/systrace.ko.symbols Reading symbols from /boot/kernel/sdt.ko.symbols...done. Loaded symbols for /boot/kernel/sdt.ko.symbols Reading symbols from /boot/kernel/lockstat.ko.symbols...done. Loaded symbols for /boot/kernel/lockstat.ko.symbols Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. Loaded symbols for /boot/kernel/fasttrap.ko.symbols Reading symbols from
Re: Linuxulator: CRASH
On May 25, 2015, at 13:41, Larry Rosenman l...@lerctr.org wrote: I have a boinc-client installation running World Community Grid science that's been working fine for months. Updated to current -HEAD, and now we crash the kernel if it's running. The backtrace points to the linuxulator. Ideas? borg.lerctr.org dumped core - see /var/crash/vmcore.17 Mon May 25 15:38:26 CDT 2015 FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #45 r283537: Mon May 25 15:10:23 CDT 2015 r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0xfe2e7240 fault code= supervisor read data, page not present instruction pointer = 0x20:0x80e96273 stack pointer = 0x28:0xfe2eb49c7600 frame pointer = 0x28:0xfe2eb49c7610 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 = 1128 (wcgrid_fahv_vina_pr) trap number = 12 panic: page fault cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe2eb49c7150 vpanic() at vpanic+0x189/frame 0xfe2eb49c71d0 panic() at panic+0x43/frame 0xfe2eb49c7230 trap_fatal() at trap_fatal+0x379/frame 0xfe2eb49c7290 trap_pfault() at trap_pfault+0x22e/frame 0xfe2eb49c7330 trap() at trap+0x4b5/frame 0xfe2eb49c7540 calltrap() at calltrap+0x8/frame 0xfe2eb49c7540 --- trap 0xc, rip = 0x80e96273, rsp = 0xfe2eb49c7600, rbp = 0xfe2eb49c7610 --- copystr() at copystr+0x13/frame 0xfe2eb49c7610 namei() at namei+0xdb/frame 0xfe2eb49c76d0 kern_execve() at kern_execve+0x24c/frame 0xfe2eb49c7a20 linux_common_execve() at linux_common_execve+0x84/frame 0xfe2eb49c7a60 linux_execve() at linux_execve+0xad/frame 0xfe2eb49c7ae0 ia32_syscall() at ia32_syscall+0x288/frame 0xfe2eb49c7bf0 Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfe2eb49c7bf0 --- syscall (0, Linux ELF32, linux_nosys), rip = 0x8048110, rsp = 0xcca4, rbp = 0 --- Uptime: 1m33s Dumping 2647 out of 64457 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/linux_common.ko.symbols...done. Loaded symbols for /boot/kernel/linux_common.ko.symbols Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. Loaded symbols for /boot/kernel/if_lagg.ko.symbols Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done. Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done. Loaded symbols for /boot/kernel/snd_spicds.ko.symbols Reading symbols from /boot/kernel/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel/coretemp.ko.symbols Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. Loaded symbols for /boot/kernel/ichsmb.ko.symbols Reading symbols from /boot/kernel/smbus.ko.symbols...done. Loaded symbols for /boot/kernel/smbus.ko.symbols Reading symbols from /boot/kernel/ichwd.ko.symbols...done. Loaded symbols for /boot/kernel/ichwd.ko.symbols Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. Loaded symbols for /boot/kernel/cpuctl.ko.symbols Reading symbols from /boot/kernel/crypto.ko.symbols...done. Loaded symbols for /boot/kernel/crypto.ko.symbols Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. Loaded symbols for /boot/kernel/cryptodev.ko.symbols Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. Loaded symbols for /boot/kernel/dtraceall.ko.symbols Reading symbols from /boot/kernel/profile.ko.symbols...done. Loaded symbols for /boot/kernel/profile.ko.symbols Reading symbols from /boot/kernel/dtrace.ko.symbols...done. Loaded symbols for /boot/kernel/dtrace.ko.symbols Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols Reading symbols from /boot/kernel/systrace.ko.symbols...done. Loaded symbols for /boot/kernel/systrace.ko.symbols Reading symbols from /boot/kernel/sdt.ko.symbols...done. Loaded symbols for /boot/kernel/sdt.ko.symbols Reading symbols from /boot/kernel/lockstat.ko.symbols...done. Loaded symbols for
Re: Linuxulator: CRASH
On Mon, May 25, 2015 at 03:41:18PM -0500, Larry Rosenman wrote: I have a boinc-client installation running World Community Grid science that's been working fine for months. Updated to current -HEAD, and now we crash the kernel if it's running. The backtrace points to the linuxulator. r283544, but this is not final fix. -- Have fun! chd ___ 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_HEAD-tests - Build #1058 - Unstable
FreeBSD_HEAD-tests - Build #1058 - Unstable: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1058/ to view the results. ___ 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_HEAD_i386 - Build #192 - Failure
FreeBSD_HEAD_i386 - Build #192 - Failure: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/192/ to view the results. ___ 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: Slow shutdown
2015-05-24 22:33 GMT+02:00 Garrett Cooper yaneurab...@gmail.com: On May 24, 2015, at 6:33, Ranjan1018 . 21474...@gmail.com wrote: On my laptop running r283297, after the message “All buffers synced.” and before “Uptime: …..” it takes more than 55 seconds. Not a lot of info here to diagnose your issue... - What happens if you hit control-t, i.e. what wait channel does it print out? control-t doesn't works. - What filesystems do you have mounted (fuse, NFS, UFS, ZFS)? ZFS and NTFS via fuse, removing NTFS mount doesn't reduce the shutdown time. - What’s your root media (SSDs, SATA/PATA hard drives, etc)? SATA. Thanks.. Thanks to you. I noticed that with the command ‘shutdown -h now’ the phrase “The operating system has halted. Please press any key to reboot.” is missing, pressing a key the laptop reboots. 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: am335x-bone.dts not exist
On May 24, 2015, at 6:44 PM, Tim Kientzle t...@kientzle.com wrote: On May 24, 2015, at 12:55 AM, Oleksandr Tymoshenko go...@bluezbox.com wrote: On May 24, 2015, at 12:12 AM, Garrett Cooper yaneurab...@gmail.com wrote: On May 24, 2015, at 0:07, Oleksandr Tymoshenko go...@bluezbox.com wrote: On May 23, 2015, at 7:21 PM, Andrey Fesenko f0and...@gmail.com wrote: # uname -a FreeBSD des.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r283306: Sat May 23 11:56:46 MSK 2015 root@des.local:/usr/obj/usr/src/sys/GENERIC amd64 I'm build BEAGLEBONE with crochet. build error Mounting UFS partition 1 at /usr/obj/_.mount.freebsd Installing U-Boot from : /usr/local/share/u-boot/u-boot-beaglebone Error: beaglebone.dts:29.1-2 syntax error FATAL ERROR: Unable to parse input tree file /usr/src/sys/boot/fdt/dts/arm/beaglebone.dts contain #include am335x-bone.dts but this file not existence. Need use am335x-evm.dts or else? am335x-bone.dts in in sys/gnu/dts/arm/, it's a file provided by vendor (TI) I guess crochet does not have this path as include path when compiling dts files. Pardon me for being a bit daft potentially, but shouldn’t #include work for all dts files (look for #include in this doc: http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf )? Thanks! #include in dts file is handled by cpp(1). /include/ is handled by dtc I believe You can take a look at how FreeBSD compiles dts files in sys/tools/fdt/make_dtb.sh crochet does not have cpp stage of compilation and before my TI code/devicetree refactoring none of the dts files referenced in crochet used #include. That's why problem never appeared. Fix is just a matter of fixing freebsd_install_fdt in lib/freebsd.sh. If nobody beats me to it I'll try to fix it and submit pull request to Tim. I’m testing a fix for this now. Thanks for providing such detailed information. This should be fixed now. Tim ___ 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: Linuxulator: CRASH
On Mon, May 25, 2015 at 11:55:36PM +0300, Chagin Dmitry wrote: On Mon, May 25, 2015 at 03:41:18PM -0500, Larry Rosenman wrote: I have a boinc-client installation running World Community Grid science that's been working fine for months. Updated to current -HEAD, and now we crash the kernel if it's running. The backtrace points to the linuxulator. r283544, but this is not final fix. -- Have fun! chd Thanks! That fixes the crash -- I'll watch for follow-on commits. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 ___ 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: Linuxulator: CRASH
On Mon, May 25, 2015 at 04:12:32PM -0500, Larry Rosenman wrote:
On Mon, May 25, 2015 at 11:55:36PM +0300, Chagin Dmitry wrote:
On Mon, May 25, 2015 at 03:41:18PM -0500, Larry Rosenman wrote:
I have a boinc-client installation running World Community Grid science
that's been working fine for months.
Updated to current -HEAD, and now we crash the kernel if it's running.
The backtrace points to the linuxulator.
r283544, but this is not final fix.
chd
Thanks! That fixes the crash -- I'll watch for follow-on commits.
this need more testing before land:
diff --git a/sys/compat/linux/linux_emul.c b/sys/compat/linux/linux_emul.c
index a28da8d..c2bf3ae 100644
--- a/sys/compat/linux/linux_emul.c
+++ b/sys/compat/linux/linux_emul.c
@@ -219,6 +219,18 @@ void
linux_proc_exec(void *arg __unused, struct proc *p, struct image_params *imgp)
{
struct thread *td = curthread;
+ struct thread *othertd;
+
+ /*
+* In a case of execing from linux binary properly detach
+* other threads from the user space.
+*/
+ if (__predict_false(SV_PROC_ABI(p) == SV_ABI_LINUX)) {
+ FOREACH_THREAD_IN_PROC(p, othertd) {
+ if (td != othertd)
+ (p-p_sysent-sv_thread_detach)(othertd);
+ }
+ }
/*
* In a case of execing to linux binary we create linux
--
Have fun!
chd
___
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: am335x-bone.dts not exist
On May 25, 2015, at 8:25 AM, Warner Losh i...@bsdimp.com wrote: On May 24, 2015, at 7:44 PM, Tim Kientzle t...@kientzle.com wrote: On May 24, 2015, at 12:55 AM, Oleksandr Tymoshenko go...@bluezbox.com wrote: On May 24, 2015, at 12:12 AM, Garrett Cooper yaneurab...@gmail.com wrote: On May 24, 2015, at 0:07, Oleksandr Tymoshenko go...@bluezbox.com wrote: On May 23, 2015, at 7:21 PM, Andrey Fesenko f0and...@gmail.com wrote: # uname -a FreeBSD des.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r283306: Sat May 23 11:56:46 MSK 2015 root@des.local:/usr/obj/usr/src/sys/GENERIC amd64 I'm build BEAGLEBONE with crochet. build error Mounting UFS partition 1 at /usr/obj/_.mount.freebsd Installing U-Boot from : /usr/local/share/u-boot/u-boot-beaglebone Error: beaglebone.dts:29.1-2 syntax error FATAL ERROR: Unable to parse input tree file /usr/src/sys/boot/fdt/dts/arm/beaglebone.dts contain #include am335x-bone.dts but this file not existence. Need use am335x-evm.dts or else? am335x-bone.dts in in sys/gnu/dts/arm/, it's a file provided by vendor (TI) I guess crochet does not have this path as include path when compiling dts files. Pardon me for being a bit daft potentially, but shouldn’t #include work for all dts files (look for #include in this doc: http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf )? Thanks! #include in dts file is handled by cpp(1). /include/ is handled by dtc I believe You can take a look at how FreeBSD compiles dts files in sys/tools/fdt/make_dtb.sh crochet does not have cpp stage of compilation and before my TI code/devicetree refactoring none of the dts files referenced in crochet used #include. That's why problem never appeared. Fix is just a matter of fixing freebsd_install_fdt in lib/freebsd.sh. If nobody beats me to it I'll try to fix it and submit pull request to Tim. I’m testing a fix for this now. Thanks for providing such detailed information. Is there any reason the standard dts to dtb script isn’t being used instead of enshrining another copy of that outside the tree which may break if/when we need to enhance the current script? Until recently, this didn’t seem necessary; it was a lot simpler to just invoke dtc. But times change: https://github.com/freebsd/crochet/commit/22d7555 Tim ___ 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_HEAD-tests - Build #1059 - Fixed
FreeBSD_HEAD-tests - Build #1059 - Fixed: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1059/ to view the results. ___ 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: Linuxulator: CRASH
On Tue, May 26, 2015 at 12:31:03AM +0300, Chagin Dmitry wrote:
On Mon, May 25, 2015 at 04:12:32PM -0500, Larry Rosenman wrote:
On Mon, May 25, 2015 at 11:55:36PM +0300, Chagin Dmitry wrote:
On Mon, May 25, 2015 at 03:41:18PM -0500, Larry Rosenman wrote:
I have a boinc-client installation running World Community Grid science
that's been working fine for months.
Updated to current -HEAD, and now we crash the kernel if it's running.
The backtrace points to the linuxulator.
r283544, but this is not final fix.
chd
Thanks! That fixes the crash -- I'll watch for follow-on commits.
this need more testing before land:
diff --git a/sys/compat/linux/linux_emul.c b/sys/compat/linux/linux_emul.c
index a28da8d..c2bf3ae 100644
--- a/sys/compat/linux/linux_emul.c
+++ b/sys/compat/linux/linux_emul.c
@@ -219,6 +219,18 @@ void
linux_proc_exec(void *arg __unused, struct proc *p, struct image_params
*imgp)
{
struct thread *td = curthread;
+ struct thread *othertd;
+
+ /*
+ * In a case of execing from linux binary properly detach
+ * other threads from the user space.
+ */
+ if (__predict_false(SV_PROC_ABI(p) == SV_ABI_LINUX)) {
+ FOREACH_THREAD_IN_PROC(p, othertd) {
+ if (td != othertd)
+ (p-p_sysent-sv_thread_detach)(othertd);
+ }
+ }
/*
* In a case of execing to linux binary we create linux
--
Have fun!
chd
Applied, and running -- will let you know if it crashes or mis-behaves.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 108 Turvey Cove, Hutto, TX 78634-5688
___
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_HEAD_i386 - Build #193 - Fixed
FreeBSD_HEAD_i386 - Build #193 - Fixed: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/193/ to view the results. ___ 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: am335x-bone.dts not exist
On Tue, May 26, 2015 at 1:19 AM, Tim Kientzle t...@kientzle.com wrote: On May 25, 2015, at 8:25 AM, Warner Losh i...@bsdimp.com wrote: On May 24, 2015, at 7:44 PM, Tim Kientzle t...@kientzle.com wrote: On May 24, 2015, at 12:55 AM, Oleksandr Tymoshenko go...@bluezbox.com wrote: On May 24, 2015, at 12:12 AM, Garrett Cooper yaneurab...@gmail.com wrote: On May 24, 2015, at 0:07, Oleksandr Tymoshenko go...@bluezbox.com wrote: On May 23, 2015, at 7:21 PM, Andrey Fesenko f0and...@gmail.com wrote: # uname -a FreeBSD des.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r283306: Sat May 23 11:56:46 MSK 2015 root@des.local:/usr/obj/usr/src/sys/GENERIC amd64 I'm build BEAGLEBONE with crochet. build error Mounting UFS partition 1 at /usr/obj/_.mount.freebsd Installing U-Boot from : /usr/local/share/u-boot/u-boot-beaglebone Error: beaglebone.dts:29.1-2 syntax error FATAL ERROR: Unable to parse input tree file /usr/src/sys/boot/fdt/dts/arm/beaglebone.dts contain #include am335x-bone.dts but this file not existence. Need use am335x-evm.dts or else? am335x-bone.dts in in sys/gnu/dts/arm/, it's a file provided by vendor (TI) I guess crochet does not have this path as include path when compiling dts files. Pardon me for being a bit daft potentially, but shouldn’t #include work for all dts files (look for #include in this doc: http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf )? Thanks! #include in dts file is handled by cpp(1). /include/ is handled by dtc I believe You can take a look at how FreeBSD compiles dts files in sys/tools/fdt/make_dtb.sh crochet does not have cpp stage of compilation and before my TI code/devicetree refactoring none of the dts files referenced in crochet used #include. That's why problem never appeared. Fix is just a matter of fixing freebsd_install_fdt in lib/freebsd.sh. If nobody beats me to it I'll try to fix it and submit pull request to Tim. I’m testing a fix for this now. Thanks for providing such detailed information. Is there any reason the standard dts to dtb script isn’t being used instead of enshrining another copy of that outside the tree which may break if/when we need to enhance the current script? Until recently, this didn’t seem necessary; it was a lot simpler to just invoke dtc. But times change: https://github.com/freebsd/crochet/commit/22d7555 Tim It's working :) % uname -a FreeBSD bb.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r283544: Tue May 26 01:54:44 MSK 2015 root@des.local:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE-V6 arm ___ 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
