Re: panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11)
Another instance, with a sligthly different stacktrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00e612ae40 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00e612aef0 vpanic() at vpanic+0x126/frame 0xfe00e612af30 kassert_panic() at kassert_panic+0x136/frame 0xfe00e612afa0 _vn_lock() at _vn_lock+0x70/frame 0xfe00e612b010 zfs_lookup() at zfs_lookup+0x44d/frame 0xfe00e612b0a0 zfs_freebsd_lookup() at zfs_freebsd_lookup+0x91/frame 0xfe00e612b1e0 VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xea/frame 0xfe00e612b210 vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame 0xfe00e612b260 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xea/frame 0xfe00e612b290 null_lookup() at null_lookup+0x8b/frame 0xfe00e612b300 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xea/frame 0xfe00e612b330 lookup() at lookup+0x590/frame 0xfe00e612b3c0 namei() at namei+0x524/frame 0xfe00e612b490 vn_open_cred() at vn_open_cred+0x28f/frame 0xfe00e612b5e0 vop_stdvptocnp() at vop_stdvptocnp+0x17d/frame 0xfe00e612b920 null_vptocnp() at null_vptocnp+0x2b/frame 0xfe00e612b980 VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0xf0/frame 0xfe00e612b9b0 vn_vptocnp_locked() at vn_vptocnp_locked+0x118/frame 0xfe00e612ba20 vn_fullpath1() at vn_fullpath1+0x1ca/frame 0xfe00e612ba80 kern___getcwd() at kern___getcwd+0xd6/frame 0xfe00e612bae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe00e612bbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe00e612bbf0 kgdb stacktrace: #1 0x80302ca5 in db_fncall (dummy1=value optimized out, dummy2=value optimized out, dummy3=value optimized out, dummy4=value optimized out) at /usr/src-svn/sys/ddb/db_command.c:578 #2 0x8030298d in db_command (cmd_table=value optimized out) at /usr/src-svn/sys/ddb/db_command.c:449 #3 0x80306bef in db_script_exec ( scriptname=0xfe00e612aad0 kdb.enter.panic, warnifnotfound=value optimized out) at /usr/src-svn/sys/ddb/db_script.c:302 #4 0x80306a26 in db_script_kdbenter (eventname=0x0) at /usr/src-svn/sys/ddb/db_script.c:324 #5 0x803050ab in db_trap (type=value optimized out, code=0) at /usr/src-svn/sys/ddb/db_main.c:230 #6 0x80696c33 in kdb_trap (type=3, code=0, tf=value optimized out) at /usr/src-svn/sys/kern/subr_kdb.c:656 #7 0x809b0e92 in trap (frame=0xfe00e612ae20) at /usr/src-svn/sys/amd64/amd64/trap.c:571 #8 0x80996122 in calltrap () at /usr/src-svn/sys/amd64/amd64/exception.S:231 #9 0x806963ee in kdb_enter (why=0x80b3c985 panic, msg=value optimized out) at cpufunc.h:63 #10 0x8065ec96 in vpanic (fmt=value optimized out, ap=value optimized out) at /usr/src-svn/sys/kern/kern_shutdown.c:752 #11 0x8065eb46 in kassert_panic (fmt=value optimized out) at /usr/src-svn/sys/kern/kern_shutdown.c:647 #12 0x807167c0 in _vn_lock (vp=0xf80013ca41d8, flags=2098176, file=0x81508fe5 /usr/src-svn/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c, line=1518) at /usr/src-svn/sys/kern/vfs_vnops.c:1436 #13 0x8148417d in zfs_lookup () at /usr/src-svn/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1518 #14 0x814844e1 in zfs_freebsd_lookup (ap=0xfe00e612b220) at /usr/src-svn/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:6106 #15 0x80a6b34a in VOP_CACHEDLOOKUP_APV (vop=value optimized out, a=value optimized out) at vnode_if.c:195 #16 0x806f480f in vfs_cache_lookup (ap=value optimized out) at vnode_if.h:80 #17 0x80a6b1fa in VOP_LOOKUP_APV (vop=value optimized out, a=value optimized out) at vnode_if.c:127 #18 0x80578ecb in null_lookup (ap=0xfe00e612b378) at vnode_if.h:54 #19 0x80a6b1fa in VOP_LOOKUP_APV (vop=value optimized out, a=value optimized out) at vnode_if.c:127 #20 0x806fc980 in lookup (ndp=0xfe00e612b678) at vnode_if.h:54 #21 0x806fc0f4 in namei (ndp=0xfe00e612b678) at /usr/src-svn/sys/kern/vfs_lookup.c:298 #22 0x80715f5f in vn_open_cred (ndp=0xfe00e612b678, flagp=0xfe00e612b800, cmode=0, vn_open_flags=value optimized out, cred=0xf8006c41de00, fp=0x0) at /usr/src-svn/sys/kern/vfs_vnops.c:205 #23 0x806f7b5d in vop_stdvptocnp (ap=value optimized out) at /usr/src-svn/sys/kern/vfs_default.c:797 #24 0x805797fb in null_vptocnp (ap=0xfe00e612b9c8) at /usr/src-svn/sys/fs/nullfs/null_vnops.c:824 #25 0x80a6fb40 in VOP_VPTOCNP_APV (vop=value optimized out, a=value optimized out) at vnode_if.c:3647 #26 0x806f5048 in vn_vptocnp_locked (vp=0xfe00e612ba50, cred=0xf8006c41de00, buf=0xf80002bae000 ..., buflen=0xfe00e612ba4c) at vnode_if.h:1564 #27 0x806f4b6a in vn_fullpath1 (td=0xf80061c26490,
Re: firebox build fails post clang-3.4 merge
On 28 Feb 2014, at 01:51, Michael Butler i...@protected-networks.net wrote: I guess what I'm trying to get at is that I am used to a compiler which takes one of two actions, irrespective of the complexities of the source language or target architecture .. 1) the compiler has no definitive translation of semantic intent because the code is ambiguous - produces an error for the programmer to that effect 2) the compiler has no idea how to translate unambiguous code into functional machine code - produces an error for the compiler author(s) benefit to expose missing code-generation cases If you're actually used to compilers like this, then I can only assume that you normally only compile programs that are a single compilation unit with no dynamic flow control (e.g. function pointers or data-dependent conditionals), because that's the only case where it is possible to implement a compiler that does what you claim you are used to. You're certainly not used to any C/C++ compiler that's been released in the last 20 years. The reason for the 'land mines', as you put it, is that the compiler has determined that a certain code path ought to be unreachable, either because of programmer-provided annotations or some knowledge of the language semantics, but can't statically prove that it really is because it can't do full symbolic execution of the entire program to prove that it is in all cases, for all possible inputs. It then has two choices: - Merrily continue with this assumption, and if it happens to be wrong continue executing code with the program in an undefined state. - Insert something that will cause abnormal program termination, allowing it to be debugged and (hopefully) preventing it becoming an arbitrary code execution vulnerability. In the vast majority of cases, sadly, it will actually do the first. It will try, however, to do the latter if it won't harm performance too much. You can, alternatively, ask the compiler not to take advantage of any of this knowledge for optimisation and aggressively tell you if you're doing anything that might be unsafe. Compiling with these options gives you code that runs at around 10-50% of the speed of an optimised compile. Maybe that's what you're used to? Now, things are looking promising for you. The estimates we did a couple of years ago showed that (as long as you don't use shared libraries), it should be feasible (although quite time consuming) to do the sorts of analysis that you're used to for moderate sized codebases once computers with 1-2TB of RAM become common. At the current rate of development, that's only a couple more years away. It may still take a few weeks to compile though... David ___ 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: About kevent
Kohji Okuno wrote this message on Fri, Feb 28, 2014 at 11:13 +0900: I have a question about kevent. How should the userland judge knote which is cleared from knlist by knlist_clear() or knlist_delete()? It looks like I need to read the code better... knlist_clear (killkn=0) and knlist_delete (killkn=1) are wrappers around knlist_cleardel... Looking at the code of knlist_cleardel, if killkn is set (knlist_delete) the knote will be dropped (free'd)... if it is not set, the flags _EOF and _ONESHOT will be set such that it'll be returned soon.. Now that I look at the code, KNOTE_ACTIVATE is never called to be put on the list to be delivered, so now I'm not sure if it works the way it's suppose to... I have a feeling that the notes might hang around forever until the kq fd is closed... I'm also puzzled as to why _DETACHED isn't set, which would seem to mean that we'll call f_detach when we close the kq, which I assume could cause a panic... This needs to be investigated/tested... -- John-Mark GurneyVoice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. Hi, Thank you for your comment. I tried test by usb_dev. When a USB device is lost suddenly, I can receive EV_EOF|EV_ONESHOT on kevent-flags. Regards, Kohji Okuno ___ 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: netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory
Hiroki Sato wrote: ia Hiroki Sato wrote: ia Hm, how about the attached one? ia ia I think the cause is just a race when length of the sysctl's output ia is changed in kernel after the buffer allocation in userspace, not ia memory shortage. Size of the routing table can quickly change. ia ia You are correct. It's growing at about 9000 entries per second (I ia wish it were faster). ia ia This is what the output looks like now. I guess I'm not the average ia case. Can you try the attached patch? It will attempt to enlarge the buffer every retry. I think the routing table grows too fast. It still fails. Ian -- Ian Freislich ___ 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: lockmgr still held [tmpfs] [vm_map_remove()-vdropl()] (r262186: Thu Feb 20)
While using poudriere:
Unread portion of the kernel message buffer:
panic: lockmgr still held
cpuid = 12
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe124804f7a0
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe124804f850
vpanic() at vpanic+0x126/frame 0xfe124804f890
kassert_panic() at kassert_panic+0x139/frame 0xfe124804f900
lockdestroy() at lockdestroy+0x3b/frame 0xfe124804f920
vdropl() at vdropl+0x1c8/frame 0xfe124804f960
vm_object_deallocate() at vm_object_deallocate+0x10b/frame 0xfe124804f9c0
vm_map_process_deferred() at vm_map_process_deferred+0x89/frame
0xfe124804f9f0
vm_map_remove() at vm_map_remove+0xc8/frame 0xfe124804fa20
vmspace_exit() at vmspace_exit+0xc9/frame 0xfe124804fa60
exit1() at exit1+0x541/frame 0xfe124804fad0
sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe124804fae0
ia32_syscall() at ia32_syscall+0x270/frame 0xfe124804fbf0
Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfe124804fbf0
--- syscall (1, FreeBSD ELF32, sys_sys_exit), rip = 0x281014df, rsp =
0xc45c, rbp = 0xc468 ---
#4 0x808c00db in lockdestroy (lk=0xf80a88a285f0) at
/usr/src/sys/kern/kern_lock.c:440
440 KASSERT(lk-lk_lock == LK_UNLOCKED, (lockmgr still held));
(kgdb) print *lk
$1 = {lock_object = {lo_name = 0x8201a1bd tmpfs, lo_flags =
116588552, lo_data = 0, lo_witness = 0xfe6fec00}, lk_lock =
18446735288132049184, lk_exslpfail = 0,
lk_timo = 51, lk_pri = 96}
I have a core.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
ia64 r260914 GENERIC kernel: /usr/src/sys/dev/vt/vt_core.c:261: undefined reference to kbd_get_keyboard and so on
ia64 r260914 GENERIC kernel contains: device kbdmux # keyboard multiplexer device vt # Virtual terminals device vt_vga # VGA terminal device Trying to build it, I get: linking kernel.debug vt_core.o: In function `vt_window_switch': /usr/src/sys/dev/vt/vt_core.c:261: undefined reference to `kbd_get_keyboard' /usr/src/sys/dev/vt/vt_core.c:263: undefined reference to `kbdsw' /usr/src/sys/dev/vt/vt_core.c:263: undefined reference to `kbdsw' vt_core.o: In function `vtterm_cnprobe': /usr/src/sys/dev/vt/vt_core.c:862: undefined reference to `kbd_configure' vt_core.o: In function `vt_allocate_keyboard': /usr/src/sys/dev/vt/vt_core.c:559: undefined reference to `kbd_allocate' /usr/src/sys/dev/vt/vt_core.c:565: undefined reference to `kbd_get_keyboard' /usr/src/sys/dev/vt/vt_core.c:567: undefined reference to `kbd_find_keyboard2' /usr/src/sys/dev/vt/vt_core.c:579: undefined reference to `kbdsw' /usr/src/sys/dev/vt/vt_core.c:579: undefined reference to `kbdsw' /usr/src/sys/dev/vt/vt_core.c:570: undefined reference to `kbd_get_keyboard' /usr/src/sys/dev/vt/vt_core.c:569: undefined reference to `kbd_find_keyboard2' /usr/src/sys/dev/vt/vt_core.c:583: undefined reference to `kbd_allocate' vt_core.o: In function `vtterm_ioctl': /usr/src/sys/dev/vt/vt_core.c:1447: undefined reference to `kbd_get_keyboard' /usr/src/sys/dev/vt/vt_core.c:1449: undefined reference to `kbdsw' /usr/src/sys/dev/vt/vt_core.c:1449: undefined reference to `kbdsw' /usr/src/sys/dev/vt/vt_core.c:1465: undefined reference to `kbd_get_keyboard' /usr/src/sys/dev/vt/vt_core.c:1467: undefined reference to `kbdsw' /usr/src/sys/dev/vt/vt_core.c:1467: undefined reference to `kbdsw' /usr/src/sys/dev/vt/vt_core.c:1488: undefined reference to `kbd_get_keyboard' /usr/src/sys/dev/vt/vt_core.c:1490: undefined reference to `kbdsw' /usr/src/sys/dev/vt/vt_core.c:1490: undefined reference to `kbdsw' /usr/src/sys/dev/vt/vt_core.c:1610: undefined reference to `kbd_get_keyboard' /usr/src/sys/dev/vt/vt_core.c:1615: undefined reference to `kbd_allocate' /usr/src/sys/dev/vt/vt_core.c:1619: undefined reference to `kbd_release' /usr/src/sys/dev/vt/vt_core.c:1622: undefined reference to `kbd_get_keyboard' /usr/src/sys/dev/vt/vt_core.c:1625: undefined reference to `kbdsw' /usr/src/sys/dev/vt/vt_core.c:1625: undefined reference to `kbdsw' /usr/src/sys/dev/vt/vt_core.c:1637: undefined reference to `kbd_get_keyboard' /usr/src/sys/dev/vt/vt_core.c:1642: undefined reference to `kbd_release' vt_core.o: In function `vtterm_cngetc': /usr/src/sys/dev/vt/vt_core.c:906: undefined reference to `kbd_get_keyboard' /usr/src/sys/dev/vt/vt_core.c:912: undefined reference to `kbdsw' /usr/src/sys/dev/vt/vt_core.c:912: undefined reference to `kbdsw' /usr/src/sys/dev/vt/vt_core.c:931: undefined reference to `kbdsw' /usr/src/sys/dev/vt/vt_core.c:931: undefined reference to `kbdsw' vt_core.o: In function `vt_kbdevent': /usr/src/sys/dev/vt/vt_core.c:539: undefined reference to `kbd_release' /usr/src/sys/dev/vt/vt_core.c:546: undefined reference to `kbdsw' /usr/src/sys/dev/vt/vt_core.c:546: undefined reference to `kbdsw' *** [kernel.debug] Error code 1 Am I missing something else? Or should these 3 devices be removed from GENERIC? Thanks Anton ___ 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: Feature Proposal: Transparent upgrade of crypt() algorithms
On 28 Feb 2014, at 02:14, Allan Jude free...@allanjude.com wrote: With r262501 (http://svnweb.freebsd.org/base?view=revisionrevision=262501) importing the upgraded bcrypt from OpenBSD and eventually changing the default identifier for bcrypt to $2b$ it reminded me of a feature that is often seen in Forum software and other web apps. … This would make it much easier to transition a very large userbase from md5crypt to bcrypt or sha512crypt, rather than expiring the passwords or something. The sleeping accounts won’t be upgraded, so be left at the ‘insecure’ algorithm. I do see the point of automatic updating of password hashes for a newer algorithm, but ‘not needing expiry’ isn’t the right argument. It is actually an argument opposing your change! What you probably meant was: don’t hassle users with the change in algorithm, possibly only the users that haven’t ever logged in after 6 months. Nick signature.asc Description: Message signed with OpenPGP using GPGMail
pcDuino support
I'd like to buy something for my kids to play with and I was thing about pcDuino, because of the nice specs. I'd like to know if the pcDuino support is complete now for FreeBSD-10. Should I buy it? If not, what is the BEST recommendation? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 I can't hear you -- I'm using the scrambler. ___ 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: firebox build fails post clang-3.4 merge
On 27 Feb 2014, at 01:57, Don Lewis truck...@freebsd.org wrote: On 26 Feb, Michael Butler wrote: On 02/18/14 12:10, Michael Butler wrote: Is anyone else seeing firefox failing to install after the clang-3.4 merge? As in xpcshell dumping core .. An update .. Recompiling with GCC48 on -current yields the same result. Seems to run correctly when invoked from the command-line but seg-faults with errno = 4 (invalid instruction) from the build Giving up and using the Linux port .. :-( I've also seen this problem with clang-3.4 on i386. It looks like a clang bug to me. Clang is putting ud2 instructions in its output which are guaranteed to fault when it compiles nsAppRunner.cpp. See http://www.freebsd.org/cgi/query-pr.cgi?pr=187103. I tried compiling the offending file with gcc46 and didn't see the problem in the assembly output. Indeed, this is clang bug with stdcall calling conventions. See the upstream bug http://llvm.org/PR19007 (thanks to Benjamin Kramer for reducing this). I have followed up on the bug with a workaround, which can be used until this bug is fixed upstream, and I can import the fix. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
On 2014-02-28 10:07, Nick Hibma wrote: On 28 Feb 2014, at 02:14, Allan Jude free...@allanjude.com wrote: With r262501 (http://svnweb.freebsd.org/base?view=revisionrevision=262501) importing the upgraded bcrypt from OpenBSD and eventually changing the default identifier for bcrypt to $2b$ it reminded me of a feature that is often seen in Forum software and other web apps. … This would make it much easier to transition a very large userbase from md5crypt to bcrypt or sha512crypt, rather than expiring the passwords or something. The sleeping accounts won’t be upgraded, so be left at the ‘insecure’ algorithm. I do see the point of automatic updating of password hashes for a newer algorithm, but ‘not needing expiry’ isn’t the right argument. It is actually an argument opposing your change! What you probably meant was: don’t hassle users with the change in algorithm, possibly only the users that haven’t ever logged in after 6 months. Nick The algorithm upgrade would upgrade everyone, including people who changed their password just 5 days ago. If an account is dormant, and never logs in, even a password expirey wouldn't force a password change, because the user never logs in. To better rephrase my point, the goal is to avoid having to adjust every users password expirey to yesterday, in order to force them all to set new passwords. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: About kevent
Kohji Okuno wrote this message on Fri, Feb 28, 2014 at 21:29 +0900: Kohji Okuno wrote this message on Fri, Feb 28, 2014 at 11:13 +0900: I have a question about kevent. How should the userland judge knote which is cleared from knlist by knlist_clear() or knlist_delete()? It looks like I need to read the code better... knlist_clear (killkn=0) and knlist_delete (killkn=1) are wrappers around knlist_cleardel... Looking at the code of knlist_cleardel, if killkn is set (knlist_delete) the knote will be dropped (free'd)... if it is not set, the flags _EOF and _ONESHOT will be set such that it'll be returned soon.. Now that I look at the code, KNOTE_ACTIVATE is never called to be put on the list to be delivered, so now I'm not sure if it works the way it's suppose to... I have a feeling that the notes might hang around forever until the kq fd is closed... I'm also puzzled as to why _DETACHED isn't set, which would seem to mean that we'll call f_detach when we close the kq, which I assume could cause a panic... This needs to be investigated/tested... Thank you for your comment. I tried test by usb_dev. When a USB device is lost suddenly, I can receive EV_EOF|EV_ONESHOT on kevent-flags. Ok, good, that means the documentation in knlist_clear(9) is correct... Thanks for verifing this for me... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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
signal 8 (floating point exception) upon resume
Hi, On my i386 -HEAD laptops (running -HEAD as of last night, but it's been a problem for a while) I occasionally hit a point where I get an FPE on _all_ processes upon resume. I can still do a clean shutdown through the power-button method, but I can't do anything else. Has anyone seen this before? Does anyone have an inkling of an idea why I'd be getting FPE's for things like ps and sh? -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
HEADS UP: sparc64 backend for llvm/clang imported
Hi, In r262613 I have merged the clang-sparc64 branch back to head. This imports an updated sparc64 backend for llvm and clang, allowing clang to bootstrap itself on sparc64, and to completely build world. To be able to build the GENERIC kernel, there is still one patch to be finalized, see below. If you have any sparc64 hardware, and are not afraid to encounter rough edges, please try out building and running your system with clang. To do so, update to at least r262613, and enable the following options in e.g. src.conf, or in your build environment: WITH_CLANG=y WITH_CLANG_IS_CC=y WITH_LIBCPLUSPLUS=y (optional) Alternatively, if you would rather keep gcc as /usr/bin/cc for the moment, build world using just WITH_CLANG, enabling clang to be built (by gcc) and installed. After installworld, you can then set CC=clang, CXX=clang++ and CPP=clang-cpp for building another world. For building the sparc64 kernel, there is one open issue left, which is that sys/sparc64/include/pcpu.h uses global register variables, and this is not supported by clang. A preliminary patch for this is attached, but it may or may not blow up your system, please beware! The patch changes the pcpu and curpcb global register variables into inline functions, similar to what is done on other architectures. However, the current approach is not optimal, and the emitted code is slightly different from what gcc outputs. Any improvements to this patch are greatly appreciated! Last but not least, thanks go out to Roman Divacky for his work with llvm/clang upstream in getting the sparc64 backend into shape. -Dimitry clang-sparc64-pcpu-1.diff Description: Binary data signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ia64 r260914 GENERIC kernel: /usr/src/sys/dev/vt/vt_core.c:261: undefined reference to kbd_get_keyboard and so on
On Friday, February 28, 2014 9:23:28 am Anton Shterenlikht wrote: ia64 r260914 GENERIC kernel contains: device kbdmux # keyboard multiplexer device vt # Virtual terminals device vt_vga # VGA terminal device Trying to build it, I get: Try this: Index: conf/files.ia64 === --- conf/files.ia64 (revision 262614) +++ conf/files.ia64 (working copy) @@ -52,7 +52,7 @@ dev/fb/vga.c optionalvga dev/hwpmc/hwpmc_ia64.c optionalhwpmc dev/io/iodev.c optionalio -dev/kbd/kbd.c optionalatkbd | sc | ukbd +dev/kbd/kbd.c optionalatkbd | sc | ukbd | vt dev/syscons/scterm-teken.c optionalsc dev/syscons/scvgarndr.coptionalsc vga dev/syscons/scvtb.coptionalsc -- John Baldwin ___ 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: HEADS UP: sparc64 backend for llvm/clang imported
On Fri, Feb 28, 2014 at 08:22:06PM +0100, Dimitry Andric wrote: Hi, In r262613 I have merged the clang-sparc64 branch back to head. This imports an updated sparc64 backend for llvm and clang, allowing clang to bootstrap itself on sparc64, and to completely build world. To be able to build the GENERIC kernel, there is still one patch to be finalized, see below. Wow! Great work all! I really didn't expect that we'd end up with a viable sparc64 backend in clang given how long it sat on the sidelines and the fact that the clang ports have been marked broken there for years. -- Brooks pgpb2fAGDcUTG.pgp Description: PGP signature
Re: signal 8 (floating point exception) upon resume
On Friday, February 28, 2014 1:15:45 pm Adrian Chadd wrote:
Hi,
On my i386 -HEAD laptops (running -HEAD as of last night, but it's
been a problem for a while) I occasionally hit a point where I get an
FPE on _all_ processes upon resume.
I can still do a clean shutdown through the power-button method, but I
can't do anything else.
Has anyone seen this before? Does anyone have an inkling of an idea
why I'd be getting FPE's for things like ps and sh?
I'm guessing fpcurthread is stale. We should probably be flushing
the FPU state on suspend and starting off without any FPU state on
resume.
Ah, see this bit here in x86/acpica/acpi_wakeup.c:
int
acpi_sleep_machdep(struct acpi_softc *sc, int state)
{
...
if (savectx(susppcbs[0])) {
#ifdef __amd64__
ctx_fpusave(susppcbs[0]-pcb_fpususpend);
#endif
...
}
Looks like you need to implement ctx_fpusave() for i386. kib@ did it as part
of the AVX work, but I wonder if you can just steal the amd64 ctx_fpusave()
and have it call npxsave() instead of fpxsave()? Not sure if you'd need it to
be in asm as it is on amd64 or if you can do this in C.
--
John Baldwin
___
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: Feature Proposal: Transparent upgrade of crypt() algorithms
On Friday, February 28, 2014 12:16:45 pm Allan Jude wrote: On 2014-02-28 10:07, Nick Hibma wrote: On 28 Feb 2014, at 02:14, Allan Jude free...@allanjude.com wrote: With r262501 (http://svnweb.freebsd.org/base?view=revisionrevision=262501) importing the upgraded bcrypt from OpenBSD and eventually changing the default identifier for bcrypt to $2b$ it reminded me of a feature that is often seen in Forum software and other web apps. … This would make it much easier to transition a very large userbase from md5crypt to bcrypt or sha512crypt, rather than expiring the passwords or something. The sleeping accounts won’t be upgraded, so be left at the ‘insecure’ algorithm. I do see the point of automatic updating of password hashes for a newer algorithm, but ‘not needing expiry’ isn’t the right argument. It is actually an argument opposing your change! What you probably meant was: don’t hassle users with the change in algorithm, possibly only the users that haven’t ever logged in after 6 months. Nick The algorithm upgrade would upgrade everyone, including people who changed their password just 5 days ago. If an account is dormant, and never logs in, even a password expirey wouldn't force a password change, because the user never logs in. To better rephrase my point, the goal is to avoid having to adjust every users password expirey to yesterday, in order to force them all to set new passwords. I think Nick's point is you do want passwords using the old hash to expire are some point if they haven't been auto-converted. -- John Baldwin ___ 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: panic: lockmgr still held [tmpfs] [vm_map_remove()-vdropl()] (r262186: Thu Feb 20)
On Friday, February 28, 2014 9:18:51 am Bryan Drewery wrote:
While using poudriere:
Unread portion of the kernel message buffer:
panic: lockmgr still held
cpuid = 12
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe124804f7a0
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe124804f850
vpanic() at vpanic+0x126/frame 0xfe124804f890
kassert_panic() at kassert_panic+0x139/frame 0xfe124804f900
lockdestroy() at lockdestroy+0x3b/frame 0xfe124804f920
vdropl() at vdropl+0x1c8/frame 0xfe124804f960
vm_object_deallocate() at vm_object_deallocate+0x10b/frame
0xfe124804f9c0
vm_map_process_deferred() at vm_map_process_deferred+0x89/frame
0xfe124804f9f0
vm_map_remove() at vm_map_remove+0xc8/frame 0xfe124804fa20
vmspace_exit() at vmspace_exit+0xc9/frame 0xfe124804fa60
exit1() at exit1+0x541/frame 0xfe124804fad0
sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe124804fae0
ia32_syscall() at ia32_syscall+0x270/frame 0xfe124804fbf0
Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfe124804fbf0
--- syscall (1, FreeBSD ELF32, sys_sys_exit), rip = 0x281014df, rsp =
0xc45c, rbp = 0xc468 ---
#4 0x808c00db in lockdestroy (lk=0xf80a88a285f0) at
/usr/src/sys/kern/kern_lock.c:440
440 KASSERT(lk-lk_lock == LK_UNLOCKED, (lockmgr still held));
(kgdb) print *lk
$1 = {lock_object = {lo_name = 0x8201a1bd tmpfs, lo_flags =
116588552, lo_data = 0, lo_witness = 0xfe6fec00}, lk_lock =
18446735288132049184, lk_exslpfail = 0,
lk_timo = 51, lk_pri = 96}
Can you please grab people.freebsd.org/~jhb/gdb/*
and then do 'cd /path/to/files', 'source gdb6', 'frame 4', 'lockmgr_owner lk'?
--
John Baldwin
___
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: Feature Proposal: Transparent upgrade of crypt() algorithms
On 27 February 2014 20:14, Allan Jude free...@allanjude.com wrote: With r262501 (http://svnweb.freebsd.org/base?view=revisionrevision=262501) importing the upgraded bcrypt from OpenBSD and eventually changing the default identifier for bcrypt to $2b$ it reminded me of a feature that is often seen in Forum software and other web apps. Transparent algorithm upgrade. ... I would strongly support this I think Nick's point is you do want passwords using the old hash to expire are some point if they haven't been auto-converted. Password expiry is an orthogonal issue and should be up to administrator policy. This might actually be more applicable with my next suggestion, exposing tuneables to control the number of rounds for bcrypt and sha512crypt. As this would make it easy to upgrade all existing bcrypt/sha512crypt hashes from the default number of rounds (10^4 and 5000 respectively) to higher values. Another orthogonal issue: I'd like to see the results of the password hashing competition (see: https://password-hashing.net/. -- Eitan Adler ___ 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: iwn(4) in -HEAD supporting Centrino Wireless-N 135
I've attached my iwn debug messages to this email starting with the point I tried to associate to the Wifi. Thanks again for looking at this! Kind regards, Tom On Thu, Feb 27, 2014 at 12:13:51PM -0800, Adrian Chadd wrote: On 26 February 2014 23:52, Alexandr shur...@shurik.kiev.ua wrote: Tom, could you: 1. compile kernel WITH_IWNDEBUG 2. sysctl dev.iwn.0.debug=0x1 3. wlandebug -i wlan0 auth+assoc 4. Associate with AP in 11n mode 5. Send us appropriate /var/log/messages Then I try to compare it with my log. Please do. I've been trying to track down the source of this ht just doesn't work! but it works fine with all of the Intel NICs I have here. Can someone see if they can find a mtaching NIC online (amazon,ebay?) Owning one that I can whack in a laptop is likely going ot help things a lot. Thanks, -a Feb 28 22:55:20 kernel: wlan0: Ethernet address: 0c:d2:92:0e:aa:e2 Feb 28 22:55:20 wpa_supplicant[2424]: Successfully initialized wpa_supplicant Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 1 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 6 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 11 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 7 status 1 Feb 28 22:55:20 wpa_supplicant[2423]: Successfully initialized wpa_supplicant Feb 28 22:55:20 wpa_supplicant[2426]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Device not configured Feb 28 22:55:20 wpa_supplicant[2426]: wlan0: Failed to initiate AP scan Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 1 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 6 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 11 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 7 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 13 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 2 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 3 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 4 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 5 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 8 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 9 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 10 status 1 Feb 28 22:55:20 kernel: iwn_notif_intr: scanning channel 12 status 1 Feb 28 22:55:20 wpa_supplicant[2426]: wlan0: Trying to associate with a0:f3:c1:35:a3:6c (SSID='pertho' freq=2462 MHz) Feb 28 22:55:20 wpa_supplicant[2425]: wlan0: Trying to associate with a0:f3:c1:35:a3:6c (SSID='pertho' freq=2462 MHz) Feb 28 22:55:21 kernel: iwn_tx_data_raw: qid 3 idx 0 len 6 nsegs 1 Feb 28 22:55:21 kernel: iwn_tx_data_raw: qid 3 idx 1 len 6 nsegs 1 Feb 28 22:55:21 kernel: iwn5000_tx_done: qid 3 idx 0 retries 0 nkill 0 rate 420a duration 778 status 201 Feb 28 22:55:21 kernel: iwn5000_tx_done: qid 3 idx 1 retries 0 nkill 0 rate 420a duration 778 status 201 Feb 28 22:55:21 kernel: iwn_tx_data_raw: qid 3 idx 2 len 87 nsegs 1 Feb 28 22:55:21 kernel: iwn5000_tx_done: qid 3 idx 2 retries 0 nkill 0 rate 420a duration 1426 status 201 Feb 28 22:55:21 kernel: iwn_set_link_quality: 1stream antenna=0x01, 2stream antenna=0x03, ntxstreams=1 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=0, txrate=7, rate=0x87 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=1, txrate=6, rate=0x86 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=2, txrate=5, rate=0x85 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=3, txrate=4, rate=0x84 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=4, txrate=3, rate=0x83 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=5, txrate=2, rate=0x82 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=6, txrate=1, rate=0x81 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=7, txrate=0, rate=0x80 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=8, txrate=0, rate=0x80 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=9, txrate=0, rate=0x80 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=10, txrate=0, rate=0x80 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=11, txrate=0, rate=0x80 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=12, txrate=0, rate=0x80 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=13, txrate=0, rate=0x80 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=14, txrate=0, rate=0x80 Feb 28 22:55:21 kernel: iwn_set_link_quality: i=15, txrate=0, rate=0x80 Feb 28 22:55:21 kernel: wlan0: link state changed to UP Feb 28 22:55:21 wpa_supplicant[2425]: wlan0: Associated with a0:f3:c1:35:a3:6c Feb 28 22:55:21 wpa_supplicant[2426]: wlan0: Associated with a0:f3:c1:35:a3:6c Feb 28 22:55:21 dhclient[2746]: send_packet: No buffer space available Feb 28 22:55:22 kernel: iwn_tx_data: qid 3 idx 3 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:22 kernel: iwn_tx_data: qid 3 idx 4 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:22 kernel: iwn5000_tx_done: qid 3 idx 3 retries 16 nkill 0 rate 80006902 duration 2815 status
Re: iwn(4) in -HEAD supporting Centrino Wireless-N 135
Hi, the interesting bits: Feb 28 22:55:22 kernel: iwn_tx_data: qid 3 idx 3 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:22 kernel: iwn_tx_data: qid 3 idx 4 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:22 kernel: iwn5000_tx_done: qid 3 idx 3 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:22 kernel: iwn5000_tx_done: qid 3 idx 4 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:23 kernel: iwn_tx_data: qid 3 idx 5 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:23 kernel: iwn_tx_data: qid 3 idx 6 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:23 kernel: iwn5000_tx_done: qid 3 idx 5 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:23 kernel: iwn5000_tx_done: qid 3 idx 6 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:24 kernel: iwn_tx_data: qid 3 idx 7 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:24 kernel: iwn_tx_data: qid 3 idx 8 len 129 nsegs 2 rate 0002 plcp 0x420a Feb 28 22:55:24 kernel: iwn5000_tx_done: qid 3 idx 7 retries 16 nkill 0 rate 80006902 duration 2815 status 83 Feb 28 22:55:24 kernel: iwn5000_tx_done: qid 3 idx 8 retries 16 nkill 0 rate 80006902 duration 2815 status 83 .. so it's failing to transmit the management frames after association - they're being transmitted at MCS0 and the AP is just plain not ACKing them. Now, I don't know why this is. It's trying to transmit the initial frame at non-MCS rates, but I have a feeling the multi-rate retry table thing is confusing it and it's trying to send it as MCS. So maybe the AP doesn't like management frames at MCS rates. I'll have to think about this a little. -a On 28 February 2014 15:07, Tom Murphy free...@pertho.net wrote: I've attached my iwn debug messages to this email starting with the point I tried to associate to the Wifi. Thanks again for looking at this! Kind regards, Tom On Thu, Feb 27, 2014 at 12:13:51PM -0800, Adrian Chadd wrote: On 26 February 2014 23:52, Alexandr shur...@shurik.kiev.ua wrote: Tom, could you: 1. compile kernel WITH_IWNDEBUG 2. sysctl dev.iwn.0.debug=0x1 3. wlandebug -i wlan0 auth+assoc 4. Associate with AP in 11n mode 5. Send us appropriate /var/log/messages Then I try to compare it with my log. Please do. I've been trying to track down the source of this ht just doesn't work! but it works fine with all of the Intel NICs I have here. Can someone see if they can find a mtaching NIC online (amazon,ebay?) Owning one that I can whack in a laptop is likely going ot help things a lot. Thanks, -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
Re: signal 8 (floating point exception) upon resume
... how'd this ever work in the past then?
-a
On 28 February 2014 13:08, John Baldwin j...@freebsd.org wrote:
On Friday, February 28, 2014 1:15:45 pm Adrian Chadd wrote:
Hi,
On my i386 -HEAD laptops (running -HEAD as of last night, but it's
been a problem for a while) I occasionally hit a point where I get an
FPE on _all_ processes upon resume.
I can still do a clean shutdown through the power-button method, but I
can't do anything else.
Has anyone seen this before? Does anyone have an inkling of an idea
why I'd be getting FPE's for things like ps and sh?
I'm guessing fpcurthread is stale. We should probably be flushing
the FPU state on suspend and starting off without any FPU state on
resume.
Ah, see this bit here in x86/acpica/acpi_wakeup.c:
int
acpi_sleep_machdep(struct acpi_softc *sc, int state)
{
...
if (savectx(susppcbs[0])) {
#ifdef __amd64__
ctx_fpusave(susppcbs[0]-pcb_fpususpend);
#endif
...
}
Looks like you need to implement ctx_fpusave() for i386. kib@ did it as part
of the AVX work, but I wonder if you can just steal the amd64 ctx_fpusave()
and have it call npxsave() instead of fpxsave()? Not sure if you'd need it to
be in asm as it is on amd64 or if you can do this in C.
--
John Baldwin
___
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: firebox build fails post clang-3.4 merge
On 28 Feb, Dimitry Andric wrote: On 27 Feb 2014, at 01:57, Don Lewis truck...@freebsd.org wrote: On 26 Feb, Michael Butler wrote: On 02/18/14 12:10, Michael Butler wrote: Is anyone else seeing firefox failing to install after the clang-3.4 merge? As in xpcshell dumping core .. An update .. Recompiling with GCC48 on -current yields the same result. Seems to run correctly when invoked from the command-line but seg-faults with errno = 4 (invalid instruction) from the build Giving up and using the Linux port .. :-( I've also seen this problem with clang-3.4 on i386. It looks like a clang bug to me. Clang is putting ud2 instructions in its output which are guaranteed to fault when it compiles nsAppRunner.cpp. See http://www.freebsd.org/cgi/query-pr.cgi?pr=187103. I tried compiling the offending file with gcc46 and didn't see the problem in the assembly output. Indeed, this is clang bug with stdcall calling conventions. See the upstream bug http://llvm.org/PR19007 (thanks to Benjamin Kramer for reducing this). I have followed up on the bug with a workaround, which can be used until this bug is fixed upstream, and I can import the fix. Thanks for the fast work! The patched solve the problem for me and I was able to install and run firefox on 11.0-CURRENT i386. ___ 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: firebox build fails post clang-3.4 merge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/28/14 12:05, Dimitry Andric wrote: Indeed, this is clang bug with stdcall calling conventions. See the upstream bug http://llvm.org/PR19007 (thanks to Benjamin Kramer for reducing this). I have followed up on the bug with a workaround, which can be used until this bug is fixed upstream, and I can import the fix. -Dimitry There's another instance of the same construct in xpcom/glue/pldhash.h which caught me out. If the attachment makes it, it's a similar patch to fix that, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlMRImoACgkQQv9rrgRC1JIvzQCeO7Cs92YT1BOIcLknTgl4+nnv 928Anje6QCr0qMSXsCdRpsjVigNLhjJT =wO1Y -END PGP SIGNATURE- ___ 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: HEADS UP: sparc64 backend for llvm/clang imported
Dimitry Andric wrote this message on Fri, Feb 28, 2014 at 20:22 +0100:
In r262613 I have merged the clang-sparc64 branch back to head. This
imports an updated sparc64 backend for llvm and clang, allowing clang to
bootstrap itself on sparc64, and to completely build world. To be able
to build the GENERIC kernel, there is still one patch to be finalized,
see below.
If you have any sparc64 hardware, and are not afraid to encounter rough
edges, please try out building and running your system with clang. To
do so, update to at least r262613, and enable the following options in
e.g. src.conf, or in your build environment:
WITH_CLANG=y
WITH_CLANG_IS_CC=y
WITH_LIBCPLUSPLUS=y (optional)
Alternatively, if you would rather keep gcc as /usr/bin/cc for the
moment, build world using just WITH_CLANG, enabling clang to be built
(by gcc) and installed. After installworld, you can then set CC=clang,
CXX=clang++ and CPP=clang-cpp for building another world.
For building the sparc64 kernel, there is one open issue left, which is
that sys/sparc64/include/pcpu.h uses global register variables, and this
is not supported by clang. A preliminary patch for this is attached,
but it may or may not blow up your system, please beware!
The patch changes the pcpu and curpcb global register variables into
inline functions, similar to what is done on other architectures.
However, the current approach is not optimal, and the emitted code is
slightly different from what gcc outputs. Any improvements to this
patch are greatly appreciated!
Last but not least, thanks go out to Roman Divacky for his work with
llvm/clang upstream in getting the sparc64 backend into shape.
Ok, I have a new pcpu patch to try. I have only compile tested it.
It is available here:
https://www.funkthat.com/~jmg/sparc64.pcpu.patch
I've also attached it.
Craig, do you mind testing it?
This patch also removes curpcb as it appears to not be used by any
sparc64 C code. A GENERIC kernel compiles fine, and fxr only turns up
curpcb used in machdep code, and no references to it under sparc64.
This is not a proper solution in that
it can mean counters/stats can be copied/moved to other cpus overwriting
the previous values if a race happens... We use
PCPU_SET(mem, PCPU_GET(mem) + val) for PCPU_ADD, not great, but it's
no worse than what we were previously using..
Until we get a proper fix which involves mapping all the cpu's PCPU
data on all CPUs, this will have to sufice..
This patch is based upon, I believe, a patch from Marius and possibly
modified by rdivacky.
Thanks for testing..
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
Index: pcpu.h
===
--- pcpu.h (revision 261863)
+++ pcpu.h (working copy)
@@ -70,11 +70,82 @@
struct pcb;
struct pcpu;
-register struct pcb *curpcb __asm__(__XSTRING(PCB_REG));
-register struct pcpu *pcpup __asm__(__XSTRING(PCPU_REG));
+/*
+ * Evaluates to the byte offset of the per-cpu variable name.
+ */
+#define __pcpu_offset(name) \
+ __offsetof(struct pcpu, name)
-#define PCPU_GET(member) (pcpup-pc_ ## member)
+/*
+ * Evaluates to the type of the per-cpu variable name.
+ */
+#define __pcpu_type(name) \
+ __typeof(((struct pcpu *)0)-name)
+#define __PCPU_GET(name) __extension__ ({ \
+ __pcpu_type(name) __res; \
+ \
+ switch (sizeof(__res)) { \
+ case 1:\
+ __asm __volatile(ldub [% __XSTRING(PCPU_REG) + %1], %0 \
+ : =r (__res) : i (__pcpu_offset(name))); \
+ break; \
+ case 2:\
+ __asm __volatile(lduh [% __XSTRING(PCPU_REG) + %1], %0\
+ : =r (__res) : i (__pcpu_offset(name))); \
+ break; \
+ case 4:\
+ __asm __volatile(ld [% __XSTRING(PCPU_REG) + %1], %0\
+ : =r (__res) : i (__pcpu_offset(name))); \
+ break; \
+ case 8:\
+ __asm __volatile(ldd [% __XSTRING(PCPU_REG) + %1], %0\
+ : =r (__res) : i (__pcpu_offset(name))); \
+ break; \
+ default: \
+ /* XXX - what to put here? */;\
+ }\
+ __res;\
+ })
+
+#define __PCPU_SET(name, val) __extension__ ({ \
+ __pcpu_type(name) __val; \
+ \
+ __val = (val); \
+ switch (sizeof(__val)) { \
+ case 1:\
+ __asm __volatile(stub %0, [% __XSTRING(PCPU_REG) + %1] \
+ : : r (__val), i (__pcpu_offset(name))); \
+ break; \
+ case 2:\
+ __asm __volatile(stuh %0, [% __XSTRING(PCPU_REG) + %1]\
+ : : r (__val), i (__pcpu_offset(name))); \
+ break; \
+ case 4:\
+ __asm __volatile(st %0, [% __XSTRING(PCPU_REG) + %1]\
+ : : r (__val), i (__pcpu_offset(name))); \
+ break; \
+ case 8:\
+ __asm __volatile(std %0, [% __XSTRING(PCPU_REG) + %1]\
+ : : r (__val), i (__pcpu_offset(name))); \
+ break; \
+ default: \
+ /* XXX - what to put here? */;\
+ }\
+ __val;\
+ })
Re: signal 8 (floating point exception) upon resume
On 28 February 2014 15:35, Adrian Chadd adr...@freebsd.org wrote:
... how'd this ever work in the past then?
.. and I've submitted it as a PR:
kern/187152
Thanks,
-a
-a
On 28 February 2014 13:08, John Baldwin j...@freebsd.org wrote:
On Friday, February 28, 2014 1:15:45 pm Adrian Chadd wrote:
Hi,
On my i386 -HEAD laptops (running -HEAD as of last night, but it's
been a problem for a while) I occasionally hit a point where I get an
FPE on _all_ processes upon resume.
I can still do a clean shutdown through the power-button method, but I
can't do anything else.
Has anyone seen this before? Does anyone have an inkling of an idea
why I'd be getting FPE's for things like ps and sh?
I'm guessing fpcurthread is stale. We should probably be flushing
the FPU state on suspend and starting off without any FPU state on
resume.
Ah, see this bit here in x86/acpica/acpi_wakeup.c:
int
acpi_sleep_machdep(struct acpi_softc *sc, int state)
{
...
if (savectx(susppcbs[0])) {
#ifdef __amd64__
ctx_fpusave(susppcbs[0]-pcb_fpususpend);
#endif
...
}
Looks like you need to implement ctx_fpusave() for i386. kib@ did it as part
of the AVX work, but I wonder if you can just steal the amd64 ctx_fpusave()
and have it call npxsave() instead of fpxsave()? Not sure if you'd need it
to
be in asm as it is on amd64 or if you can do this in C.
--
John Baldwin
___
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: panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11)
Jeremie Le Hen wrote: Another instance, with a sligthly different stacktrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00e612ae40 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00e612aef0 vpanic() at vpanic+0x126/frame 0xfe00e612af30 kassert_panic() at kassert_panic+0x136/frame 0xfe00e612afa0 _vn_lock() at _vn_lock+0x70/frame 0xfe00e612b010 zfs_lookup() at zfs_lookup+0x44d/frame 0xfe00e612b0a0 zfs_freebsd_lookup() at zfs_freebsd_lookup+0x91/frame 0xfe00e612b1e0 VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xea/frame 0xfe00e612b210 vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame 0xfe00e612b260 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xea/frame 0xfe00e612b290 null_lookup() at null_lookup+0x8b/frame 0xfe00e612b300 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xea/frame 0xfe00e612b330 lookup() at lookup+0x590/frame 0xfe00e612b3c0 namei() at namei+0x524/frame 0xfe00e612b490 vn_open_cred() at vn_open_cred+0x28f/frame 0xfe00e612b5e0 vop_stdvptocnp() at vop_stdvptocnp+0x17d/frame 0xfe00e612b920 null_vptocnp() at null_vptocnp+0x2b/frame 0xfe00e612b980 VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0xf0/frame 0xfe00e612b9b0 vn_vptocnp_locked() at vn_vptocnp_locked+0x118/frame 0xfe00e612ba20 vn_fullpath1() at vn_fullpath1+0x1ca/frame 0xfe00e612ba80 kern___getcwd() at kern___getcwd+0xd6/frame 0xfe00e612bae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe00e612bbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe00e612bbf0 kgdb stacktrace: #1 0x80302ca5 in db_fncall (dummy1=value optimized out, dummy2=value optimized out, dummy3=value optimized out, dummy4=value optimized out) at /usr/src-svn/sys/ddb/db_command.c:578 #2 0x8030298d in db_command (cmd_table=value optimized out) at /usr/src-svn/sys/ddb/db_command.c:449 #3 0x80306bef in db_script_exec ( scriptname=0xfe00e612aad0 kdb.enter.panic, warnifnotfound=value optimized out) at /usr/src-svn/sys/ddb/db_script.c:302 #4 0x80306a26 in db_script_kdbenter (eventname=0x0) at /usr/src-svn/sys/ddb/db_script.c:324 #5 0x803050ab in db_trap (type=value optimized out, code=0) at /usr/src-svn/sys/ddb/db_main.c:230 #6 0x80696c33 in kdb_trap (type=3, code=0, tf=value optimized out) at /usr/src-svn/sys/kern/subr_kdb.c:656 #7 0x809b0e92 in trap (frame=0xfe00e612ae20) at /usr/src-svn/sys/amd64/amd64/trap.c:571 #8 0x80996122 in calltrap () at /usr/src-svn/sys/amd64/amd64/exception.S:231 #9 0x806963ee in kdb_enter (why=0x80b3c985 panic, msg=value optimized out) at cpufunc.h:63 #10 0x8065ec96 in vpanic (fmt=value optimized out, ap=value optimized out) at /usr/src-svn/sys/kern/kern_shutdown.c:752 #11 0x8065eb46 in kassert_panic (fmt=value optimized out) at /usr/src-svn/sys/kern/kern_shutdown.c:647 #12 0x807167c0 in _vn_lock (vp=0xf80013ca41d8, flags=2098176, file=0x81508fe5 /usr/src-svn/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c, line=1518) at /usr/src-svn/sys/kern/vfs_vnops.c:1436 #13 0x8148417d in zfs_lookup () at /usr/src-svn/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1518 #14 0x814844e1 in zfs_freebsd_lookup (ap=0xfe00e612b220) at /usr/src-svn/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:6106 #15 0x80a6b34a in VOP_CACHEDLOOKUP_APV (vop=value optimized out, a=value optimized out) at vnode_if.c:195 #16 0x806f480f in vfs_cache_lookup (ap=value optimized out) at vnode_if.h:80 #17 0x80a6b1fa in VOP_LOOKUP_APV (vop=value optimized out, a=value optimized out) at vnode_if.c:127 #18 0x80578ecb in null_lookup (ap=0xfe00e612b378) at vnode_if.h:54 #19 0x80a6b1fa in VOP_LOOKUP_APV (vop=value optimized out, a=value optimized out) at vnode_if.c:127 #20 0x806fc980 in lookup (ndp=0xfe00e612b678) at vnode_if.h:54 #21 0x806fc0f4 in namei (ndp=0xfe00e612b678) at /usr/src-svn/sys/kern/vfs_lookup.c:298 #22 0x80715f5f in vn_open_cred (ndp=0xfe00e612b678, flagp=0xfe00e612b800, cmode=0, vn_open_flags=value optimized out, cred=0xf8006c41de00, fp=0x0) at /usr/src-svn/sys/kern/vfs_vnops.c:205 #23 0x806f7b5d in vop_stdvptocnp (ap=value optimized out) at /usr/src-svn/sys/kern/vfs_default.c:797 #24 0x805797fb in null_vptocnp (ap=0xfe00e612b9c8) at /usr/src-svn/sys/fs/nullfs/null_vnops.c:824 #25 0x80a6fb40 in VOP_VPTOCNP_APV (vop=value optimized out, a=value optimized out) at vnode_if.c:3647 #26 0x806f5048 in vn_vptocnp_locked (vp=0xfe00e612ba50, cred=0xf8006c41de00,
Re: pcDuino support
Hi, On Fri, Feb 28, 2014 at 11:55 PM, Odhiambo Washington odhia...@gmail.comwrote: I'd like to buy something for my kids to play with and I was thing about pcDuino, because of the nice specs. I'd like to know if the pcDuino support is complete now for FreeBSD-10. We have just basic support of Allwinner A10/A20 SoC in src tree. Only usb ehci and gpio support is there. I hope EMAC ethernet controller and mmc drivers go into src tree soon maybe after some code polishes. So for kids maybe RPI or Beaglebone black can be useful, since these are more supported and yet not so expensive. Another options could be Freescale SoC boards like wandboard, phytec Cosmic board etc. hope this helps, Ganbold Should I buy it? If not, what is the BEST recommendation? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 I can't hear you -- I'm using the scrambler. ___ 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
