Re: r269471 make unusable VT console
On 16.08.2014 01:51, Nathan Whitehorn wrote: It also has bad effects on boot time. My desktop takes something like 3 times as long to boot after r269471. If it can't be fixed quickly, it needs to be reverted. Just a quick note: I'm working on an update to vt_vga. The current patch already fixes the draw speed problem, but I'm not finished yet (the mouse cursor is broken as well as some other small annoyances). -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: nscd not caching
On Aug 18, 2014, at 10:42 AM, Eggert, Lars l...@netapp.com wrote: Hi, On 2014-8-17, at 18:10, Adam McDougall mcdou...@egr.msu.edu wrote: We were using +: type entries in the local password and group tables and I believe we used an unmodified /etc/nsswitch.conf (excluding cache lines while testing nscd): I tried that setup too, and it doesn't seem to be caching any NIS lookups either. The current NIS server is 25ms away, which is a pain. I'm trying to get a local slave set up, which will make the need for nscd go away, but it would sure be nice if it worked in the meantime. At our site, we never had enough load to outright require nscd on FreeBSD, although there were some areas where caching had a usability benefit. Load is not an issue, latency is (see above). I know that this a bit late but have you ever considered Hesiod? it uses DNS/txt. we have been using it since the days when BSDi had no NIS support and haven’t seen a ypserver not responding since :-) danny ___ 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: nscd not caching
Bezüglich Peter Wemm's Nachricht vom 17.08.2014 19:18 (localtime): On Sunday 17 August 2014 15:22:02 O. Hartmann wrote: Am Sun, 17 Aug 2014 13:09:10 + Eggert, Lars l...@netapp.com schrieb: Nobody using nscd? Really? I can only speak for myself and I stopped using nscd since the support is crap. A while ago (t 1 1/2 years) I realised within a OpenLDAP environment, that when nscd is running, sometimes the system simple forgets about root - this is painful while installing/updating ports and getting interrupted with a weird error unknown user root. nscd is supposed to be used in large environments where the cost for a user lookup, like in OpenLDAP, is worse. But obviously FreeBSD isn't used in that large environments with OpenLDAP and I'm wondering what the purpose of nscd is. The other problem is that net/nss_ldap and security/pam_ldap have kind of been left behind for performance and robustness. People who use this seriousy tend to discover net/nss-pam-ldapd fairly quickly which has its own caching proxy and eliminates the need for nscd. With nss_ldap and pam_ldap, the openldap client libraries and startup cost is linked into every single binary that uses it. WIth pam-nss-ldapd, it's a simple unix domain socket (with peercred authentication) and no heavy-weight libraries in the consumers. The proxy on the other end of the socket keeps a ldap connection open (with an idle timeout). The whole thing was vastly more robust and efficient. At least that's what we found in the freebsd.org cluster. nss-pam-ldapd was two or three orders of magnitude more usable and got rid of nscd in the process. For us, nscd worked, but it just didn't save much effort because it was a per-uid cache. ie: if jkh had just caused a ldap search, and peter repeated it, it had to be done again from scratch. The downside for nss-pam-ldapd was that it uses a non-extensible wire protocol and didn't have room for bsd-style login classes. This exactly refelcts my experiences too, which is why I'm wondering if net/nss-pam-ldapd is a serious base candidate. When nscd showed up (arround 7.0-Release if I remember correctly), it was a big and highly appreciated improovement for me, reducing interactivity lags of gnome e.g. by at least a factor of 4 for usual desktop user tasks when user database was LDAP driven. At that time there were rumors that FreeBSD needs LDAP user-database support, but with the glitches of net/nss_ldap, it seemed that there's no ready-to-implement solution at that time. Things changed completely with net/nss-pam-ldapd. Haven't had any negative experiences with single-LDAP backend networks. Haven't had big environments yet either, but I think it's time to think about base-LDAP-support again. net/nss-pam-ldapd is GPL licensed, so I guess it won't get into base, but it was a great template, is it? -Harry signature.asc Description: OpenPGP digital signature
Re: nscd not caching
On 2014-8-18, at 20:23, John-Mark Gurney j...@funkthat.com wrote: Why not run a local slave on your server? I am trying to get one set up. It requires a change request to our organization's IT, which is, ahem, not always lightning fast. Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Re: nscd not caching
On 2014-8-19, at 13:54, Daniel Braniss da...@cs.huji.ac.il wrote: I know that this a bit late but have you ever considered Hesiod? it uses DNS/txt. we have been using it since the days when BSDi had no NIS support and haven’t seen a ypserver not responding since :-) I don't control the master NIS infrastructure, I just want to use it (with a server that is unfortunately 25ms away). We will move to LDAP at some time, but in the meantime, a functioning nscd would be nice. Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Re: nscd not caching
On 08/19/2014 09:14, Harald Schmalzbauer wrote: Bezüglich Peter Wemm's Nachricht vom 17.08.2014 19:18 (localtime): On Sunday 17 August 2014 15:22:02 O. Hartmann wrote: Am Sun, 17 Aug 2014 13:09:10 + Eggert, Lars l...@netapp.com schrieb: Nobody using nscd? Really? I can only speak for myself and I stopped using nscd since the support is crap. A while ago (t 1 1/2 years) I realised within a OpenLDAP environment, that when nscd is running, sometimes the system simple forgets about root - this is painful while installing/updating ports and getting interrupted with a weird error unknown user root. nscd is supposed to be used in large environments where the cost for a user lookup, like in OpenLDAP, is worse. But obviously FreeBSD isn't used in that large environments with OpenLDAP and I'm wondering what the purpose of nscd is. The other problem is that net/nss_ldap and security/pam_ldap have kind of been left behind for performance and robustness. People who use this seriousy tend to discover net/nss-pam-ldapd fairly quickly which has its own caching proxy and eliminates the need for nscd. With nss_ldap and pam_ldap, the openldap client libraries and startup cost is linked into every single binary that uses it. WIth pam-nss-ldapd, it's a simple unix domain socket (with peercred authentication) and no heavy-weight libraries in the consumers. The proxy on the other end of the socket keeps a ldap connection open (with an idle timeout). The whole thing was vastly more robust and efficient. At least that's what we found in the freebsd.org cluster. nss-pam-ldapd was two or three orders of magnitude more usable and got rid of nscd in the process. For us, nscd worked, but it just didn't save much effort because it was a per-uid cache. ie: if jkh had just caused a ldap search, and peter repeated it, it had to be done again from scratch. The downside for nss-pam-ldapd was that it uses a non-extensible wire protocol and didn't have room for bsd-style login classes. This exactly refelcts my experiences too, which is why I'm wondering if net/nss-pam-ldapd is a serious base candidate. When nscd showed up (arround 7.0-Release if I remember correctly), it was a big and highly appreciated improovement for me, reducing interactivity lags of gnome e.g. by at least a factor of 4 for usual desktop user tasks when user database was LDAP driven. At that time there were rumors that FreeBSD needs LDAP user-database support, but with the glitches of net/nss_ldap, it seemed that there's no ready-to-implement solution at that time. Things changed completely with net/nss-pam-ldapd. Haven't had any negative experiences with single-LDAP backend networks. Haven't had big environments yet either, but I think it's time to think about base-LDAP-support again. net/nss-pam-ldapd is GPL licensed, so I guess it won't get into base, but it was a great template, is it? +1 for nss-pam-ldapd. We were using nss_ldap+pam_ldap, but switched to nss-pam-ldapd. It's much faster and very reliable. We have several multi-user FreeBSD systems (build servers, doing lots of lookups), dozens of concurrent users and hundreds of total users, and Active Directory servers. The way nss_ldap links the LDAP libraries into every process is not just inefficient: it can be fatal. Thunderbird includes (or formerly included?) its own private LDAP libraries. These conflicted with those used by nss_ldap, so that Thunderbird would often crash. I don't know if this is still a problem, but it's not /my/ problem anymore. As for the base system, pkg install nss-pam-ldapd is embarrassingly easy and /much/ easier than adding to the base system. Eric ___ 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: DEADLKRES crash
On 08/18/2014 16:45, Ryan Stone wrote: The first thing that I'd like to see is (in kgdb): set $td=(struct thread)0xf8002abeb000 tid $td-td_tid bt That will show us the backtrace of the thread that was blocked for so long. Make that: set $td=(struct thread *)0xf8002abeb000 tid $td-td_tid bt Eric ___ 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: DEADLKRES crash
On 2014-08-19 08:42, Eric van Gyzen wrote: On 08/18/2014 16:45, Ryan Stone wrote: The first thing that I'd like to see is (in kgdb): set $td=(struct thread)0xf8002abeb000 tid $td-td_tid bt That will show us the backtrace of the thread that was blocked for so long. Make that: set $td=(struct thread *)0xf8002abeb000 tid $td-td_tid bt Eric #0 doadump (textdump=1) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) set $td=(struct thread *)0xf8002abeb000 Current language: auto; currently minimal (kgdb) tid $td-td_tid [Switching to thread 469 (Thread 100681)]#0 sched_switch ( td=0xf8002abeb000, newtd=value optimized out, flags=value optimized out) at /usr/src/sys/kern/sched_ule.c:1931 1931cpuid = PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=0xf8002abeb000, newtd=value optimized out, flags=value optimized out) at /usr/src/sys/kern/sched_ule.c:1931 #1 0x80a107d9 in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:493 #2 0x80a4c442 in sleepq_switch (wchan=value optimized out, pri=value optimized out) at /usr/src/sys/kern/subr_sleepqueue.c:552 #3 0x80a4c2a3 in sleepq_wait (wchan=0xf80070a4dd50, pri=96) at /usr/src/sys/kern/subr_sleepqueue.c:631 #4 0x809eb1fa in sleeplk (lk=value optimized out, flags=value optimized out, ilk=value optimized out, wmesg=value optimized out, pri=value optimized out, timo=value optimized out) at /usr/src/sys/kern/kern_lock.c:225 #5 0x809eaa06 in __lockmgr_args (lk=0xf80070a4dd50, flags=value optimized out, ilk=0xf80070a4dd80, wmesg=value optimized out, pri=value optimized out, timo=value optimized out) at /usr/src/sys/kern/kern_lock.c:931 #6 0x8092e092 in nfs_lock1 (ap=value optimized out) at lockmgr.h:97 #7 0x80f2d57c in VOP_LOCK1_APV (vop=value optimized out, a=value optimized out) at vnode_if.c:2082 #8 0x80abd22a in _vn_lock (vp=0xf80070a4dce8, flags=value optimized out, file=0x8110db88 /usr/src/sys/kern/vfs_subr.c, line=2137) at vnode_if.h:859 #9 0x80aad4e7 in vget (vp=0xf80070a4dce8, flags=524544, ---Type return to continue, or q return to quit--- td=0xf8002abeb000) at /usr/src/sys/kern/vfs_subr.c:2137 #10 0x80aa1491 in vfs_hash_get (mp=0xf8002aa1e990, hash=1741450670, flags=value optimized out, td=0xf8002abeb000, vpp=0xfe100c75c670, fn=0x80935820 newnfs_vncmpf) at /usr/src/sys/kern/vfs_hash.c:88 #11 0x809314bd in ncl_nget (mntp=0xf8002aa1e990, fhp=0xf80070ccf4a4 \001, fhsize=12, npp=0xfe100c75c6e0, lkflags=value optimized out) at /usr/src/sys/fs/nfsclient/nfs_clnode.c:114 #12 0x809340fd in nfs_statfs (mp=0xf8002aa1e990, sbp=0xf8002aa1ea48) at /usr/src/sys/fs/nfsclient/nfs_clvfsops.c:288 #13 0x80aa7ade in __vfs_statfs (mp=0x0, sbp=0xf8002aa1ea48) at /usr/src/sys/kern/vfs_mount.c:1706 #14 0x80ab4f5e in kern_getfsstat (td=0xf8002abeb000, buf=value optimized out, bufsize=value optimized out, bufseg=UIO_USERSPACE, flags=value optimized out) at /usr/src/sys/kern/vfs_syscalls.c:511 #15 0x80e1625a in amd64_syscall (td=0xf8002abeb000, traced=0) at subr_syscall.c:133 #16 0x80df760b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:390 #17 0x0008010fc83a in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) 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: nscd not caching
Bezüglich Eric van Gyzen's Nachricht vom 19.08.2014 15:39 (localtime): On 08/19/2014 09:14, Harald Schmalzbauer wrote: … At least that's what we found in the freebsd.org cluster. nss-pam-ldapd was two or three orders of magnitude more usable and got rid of nscd in the process. For us, nscd worked, but it just didn't save much effort because it was a per-uid cache. ie: if jkh had just caused a ldap search, and peter repeated it, it had to be done again from scratch. The downside for nss-pam-ldapd was that it uses a non-extensible wire protocol and didn't have room for bsd-style login classes. This exactly refelcts my experiences too, which is why I'm wondering if net/nss-pam-ldapd is a serious base candidate. When nscd showed up (arround 7.0-Release if I remember correctly), it was a big and highly appreciated improovement for me, reducing interactivity lags of gnome e.g. by at least a factor of 4 for usual desktop user tasks when user database was LDAP driven. At that time there were rumors that FreeBSD needs LDAP user-database support, but with the glitches of net/nss_ldap, it seemed that there's no ready-to-implement solution at that time. Things changed completely with net/nss-pam-ldapd. Haven't had any negative experiences with single-LDAP backend networks. Haven't had big environments yet either, but I think it's time to think about base-LDAP-support again. net/nss-pam-ldapd is GPL licensed, so I guess it won't get into base, but it was a great template, is it? +1 for nss-pam-ldapd. We were using nss_ldap+pam_ldap, but switched to nss-pam-ldapd. It's much faster and very reliable. We have several multi-user FreeBSD systems (build servers, doing lots of lookups), dozens of concurrent users and hundreds of total users, and Active Directory servers. The way nss_ldap links the LDAP libraries into every process is not just inefficient: it can be fatal. Thunderbird includes (or formerly included?) its own private LDAP libraries. These conflicted with those used by nss_ldap, so that Thunderbird would often crash. I don't know if this is still a problem, but it's not /my/ problem anymore. As for the base system, pkg install nss-pam-ldapd is embarrassingly easy and /much/ easier than adding to the base system. 'pkg install' is incredibly convenient these days, for sure, but in my world, hosts that don't need internet acces don't have internet access (4 out of 5). To make things worse, nfs exports aren't root-mapped (other than the default nobody:nobody), so I quiet often have the case that I have to provide net/nss-pam-ldapd via ISO-9660 image (for VMguests) or CD-media. That's not so convenient. Another limitation of 'pkg install' is that I can't influence what to install. Sometimes I want nss_ldap without pam_ldap. Therefore I'd need a compiler (somthing my production machines don't have) and ports, which in my case can't be fetched from internet nor from the NFS server (the latter has to be entered as LDAP user…) That's why I'd love to see base system LDAP support – I think it's very important to be able to setup a network computer in networks, which aren't interconnected with other networks/internet; these days more important ever since possible… -Harry signature.asc Description: OpenPGP digital signature
Re: DEADLKRES crash
On 8/19/2014 8:53 AM, Larry Rosenman wrote: On 2014-08-19 08:42, Eric van Gyzen wrote: On 08/18/2014 16:45, Ryan Stone wrote: The first thing that I'd like to see is (in kgdb): set $td=(struct thread)0xf8002abeb000 tid $td-td_tid bt That will show us the backtrace of the thread that was blocked for so long. Make that: set $td=(struct thread *)0xf8002abeb000 tid $td-td_tid bt Eric #0 doadump (textdump=1) at pcpu.h:219 219pcpu.h: No such file or directory. in pcpu.h (kgdb) set $td=(struct thread *)0xf8002abeb000 Current language: auto; currently minimal (kgdb) tid $td-td_tid [Switching to thread 469 (Thread 100681)]#0 sched_switch ( td=0xf8002abeb000, newtd=value optimized out, flags=value optimized out) at /usr/src/sys/kern/sched_ule.c:1931 1931cpuid = PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=0xf8002abeb000, newtd=value optimized out, flags=value optimized out) at /usr/src/sys/kern/sched_ule.c:1931 #1 0x80a107d9 in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:493 #2 0x80a4c442 in sleepq_switch (wchan=value optimized out, pri=value optimized out) at /usr/src/sys/kern/subr_sleepqueue.c:552 #3 0x80a4c2a3 in sleepq_wait (wchan=0xf80070a4dd50, pri=96) at /usr/src/sys/kern/subr_sleepqueue.c:631 #4 0x809eb1fa in sleeplk (lk=value optimized out, flags=value optimized out, ilk=value optimized out, wmesg=value optimized out, pri=value optimized out, timo=value optimized out) at /usr/src/sys/kern/kern_lock.c:225 #5 0x809eaa06 in __lockmgr_args (lk=0xf80070a4dd50, flags=value optimized out, ilk=0xf80070a4dd80, wmesg=value optimized out, pri=value optimized out, timo=value optimized out) at /usr/src/sys/kern/kern_lock.c:931 #6 0x8092e092 in nfs_lock1 (ap=value optimized out) at lockmgr.h:97 #7 0x80f2d57c in VOP_LOCK1_APV (vop=value optimized out, a=value optimized out) at vnode_if.c:2082 #8 0x80abd22a in _vn_lock (vp=0xf80070a4dce8, flags=value optimized out, file=0x8110db88 /usr/src/sys/kern/vfs_subr.c, line=2137) at vnode_if.h:859 #9 0x80aad4e7 in vget (vp=0xf80070a4dce8, flags=524544, ---Type return to continue, or q return to quit--- td=0xf8002abeb000) at /usr/src/sys/kern/vfs_subr.c:2137 #10 0x80aa1491 in vfs_hash_get (mp=0xf8002aa1e990, hash=1741450670, flags=value optimized out, td=0xf8002abeb000, vpp=0xfe100c75c670, fn=0x80935820 newnfs_vncmpf) at /usr/src/sys/kern/vfs_hash.c:88 #11 0x809314bd in ncl_nget (mntp=0xf8002aa1e990, fhp=0xf80070ccf4a4 \001, fhsize=12, npp=0xfe100c75c6e0, lkflags=value optimized out) at /usr/src/sys/fs/nfsclient/nfs_clnode.c:114 #12 0x809340fd in nfs_statfs (mp=0xf8002aa1e990, sbp=0xf8002aa1ea48) at /usr/src/sys/fs/nfsclient/nfs_clvfsops.c:288 #13 0x80aa7ade in __vfs_statfs (mp=0x0, sbp=0xf8002aa1ea48) at /usr/src/sys/kern/vfs_mount.c:1706 #14 0x80ab4f5e in kern_getfsstat (td=0xf8002abeb000, buf=value optimized out, bufsize=value optimized out, bufseg=UIO_USERSPACE, flags=value optimized out) at /usr/src/sys/kern/vfs_syscalls.c:511 #15 0x80e1625a in amd64_syscall (td=0xf8002abeb000, traced=0) at subr_syscall.c:133 #16 0x80df760b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:390 #17 0x0008010fc83a in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Looks like the one I hit recently as well: http://lists.freebsd.org/pipermail/freebsd-fs/2014-July/019843.html This lock should probably be excluded from the DEADLKRES. I have not had time to follow-up on it, but it's a trivial thing to add it to the list. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: panic: pmap active 0xfffff8002d2ae9f8
On 8/18/2014 3:41 AM, Konstantin Belousov wrote: On Fri, Aug 15, 2014 at 10:38:25PM -0500, Bryan Drewery wrote: On 2014-08-13 10:38, Bryan Drewery wrote: On 6/24/2014 4:28 PM, Craig Rodrigues wrote: Hi, I have a system running CURRENT at r266925 from May 31. While doing some software builds using poudriere, the system panicked. Unfortunately this system was not configured with swap space, so I cannot do a kernel dump. The system is currently at the ddb prompt. Here is the backtrace: Here is the backtrace from ddb: panic: pmap active 0xf8002d2ae9f8 cpuid = 5 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe183958a7d0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe183958a880 vpanic() at vpanic+0x126/frame 0xfe183958a8c0 kassert_panic() at kassert_panic+0x139/frame 0xfe183958a930 pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe183958aa20 vmspace_exit() at vmspace_exit+0xa1/frame 0xfe183958aa60 exit1() at exit1+0x541/frame 0xfe183958aad0 sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe183958aae0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfe183958abf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe183958abf0 --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip - 0x800b195aa, rsp - 0x7ffe3e8, rbp = 0x7e400 KDB: enter: panic [ thread pid 94762 tid 101570 ] Stopped at kdb_enter+0x3e: movq$0.kdb_why db Is this a known problem? Are there other commands I should type at the ddb prompt? -- Craig I have run into this as well on r269147: panic: pmap active 0xf80035f422f8 cpuid = 10 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe124852b7d0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe124852b880 vpanic() at vpanic+0x126/frame 0xfe124852b8c0 kassert_panic() at kassert_panic+0x139/frame 0xfe124852b930 pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe124852ba20 vmspace_exit() at vmspace_exit+0x9c/frame 0xfe124852ba60 exit1() at exit1+0x541/frame 0xfe124852bad0 sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe124852bae0 ia32_syscall() at ia32_syscall+0x270/frame 0xfe124852bbf0 Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfe124852bbf0 --- syscall (1, FreeBSD ELF32, sys_sys_exit), rip = 0x297e386f, rsp = 0xd7ac, rbp = 0xd7b8 --- KDB: enter: panic [ thread pid 85335 tid 101517 ] Stopped at kdb_enter+0x3e: movq$0,kdb_why db call doadump Dump failed. Partition too small. = 0 Got it again on recent r269950 while building with poudriere: panic: pmap active 0xf8113c3c6d78 cpuid = 10 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe1248acc7d0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1248acc880 vpanic() at vpanic+0x126/frame 0xfe1248acc8c0 kassert_panic() at kassert_panic+0x139/frame 0xfe1248acc930 pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe1248acca20 vmspace_exit() at vmspace_exit+0x9c/frame 0xfe1248acca60 exit1() at exit1+0x541/frame 0xfe1248accad0 sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe1248accae0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfe1248accbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1248accbf0 --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x80387fadc, rsp = 0x7fffd4e8, rbp = 0x7fffd5a0 --- KDB: enter: panic [ thread pid 84433 tid 101503 ] Stopped at kdb_enter+0x3e: movq$0,kdb_why db call doadump Dump failed. Partition too small. = 0 The interesting information is pmap-pm_active, for pmap address reported by the panic. Easiest way to get the active mask is using kgdb on vmcore. Ok. I'll add in a larger dedicated dump device to cover the memory size blocking debugging my recent panics. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: r269471 make unusable VT console
On 19.08.2014 10:42, Jean-Sébastien Pédron wrote: On 16.08.2014 01:51, Nathan Whitehorn wrote: It also has bad effects on boot time. My desktop takes something like 3 times as long to boot after r269471. If it can't be fixed quickly, it needs to be reverted. Just a quick note: I'm working on an update to vt_vga. Hello! Here's a first version of the patch I was talking about: https://people.freebsd.org/~dumbbell/vt/vt-vga.5.patch What's new/fixed: o vt_vga introduces a new callback, vd_bitblt_text_t, which takes as argument the text buffer, the dirty area, the font and the cursor (position, map, colors). With all this information at hand, it can redraw the dirty area with almost no read from the video memory. This greatly improves the performance. The implementation is quite naive and I put a lot of comments. This could probably be simplfied/improved. The cursor is drawn at the same time than the text: this avoids flickering of the mouse pointer. The patch reads from the video memory only when the byte to write uses more than 2 colors (fg/bg). But this only happens with colored text around the cursor or with fonts who's width isn't a multiple of 8. o In vt_flush(), handle the cursor position before getting the dirty area. This fixes a bug where, if we move the cursor too fast, its new location is outside the marked area and it disappears from the screen. While here, mark the new position of the cursor as dirty, not only the old one. For the cursor to be drawn, VWF_MOUSE_HIDE must not be set *and* VDF_MOUSECURSOR must be set! Before, only the former was checked when deciding if the cursor position should be marked as dirty. Finally, if the cursor didn't move, don't mark its position as dirty. Before, these two problems caused major redraw of a large part of the screen for nothing, due to a mouse pointer location of [0;0] (even if disabled) and its position always marked as dirty. o When the mouse state is changed, mark its position as dirty. o The flush timer is paused during a window switch. In the case of vt_vga, vga_initialize() is called and it messes with VGA registers and the video memory. If vt_flush() is triggered at the same time, unexpected data are displayed. This is fixed, though, there's still a annoying flickering, because the sync signal is temporarily stopped during vga_initialize(). o The patch includes another non-related patch, which tries to stabilize the refresh rate. Currently, we schedule the next redraw in 40 ms (25 Hz), but that doesn't count for the time taken to redraw. o Change how the mouse is enabled/disabled/shown/hidden. Now, the GETLEVEL and GETMODE ioctls don't touch this. Everything goes through the CONS_MOUSECTL ioctl. This fixes vidcontrol -m on|off. Known issues: o Instead of having an if (bitblt_text != NULL) check in vt_flush(), I'll add a generic bitblt_text callback which implements the old code, so that other drivers can be changed incrementally. o In vt_vga, the screen flickers during a window switch, because it stops the sync signal and zeroes the memory. It would be nice to avoid that. o Several issues when the font is changed: 1. The offset to center the text area is global, not per window. Therefore other window are not centered anymore. 2. There's a bug with my patch, where other windows have the top-left letter wrongly shifted. 3. When the text area changes (compared to the whole screen), there's garbage in the borders. 4. The text cursor (the square) may be broken on other windows. o The mouse pointer is somtimes not erased during a move. o The text square cursor handling in vt_vga could be improved: colors are just reversed, we shouldn't change the fg/bg colors, just write a 0x00 pattern instead. o The vt_flush() timer could maybe be stopped when there's nothing to draw. No need to wakeup a core for that. Any comments? -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: r269471 make unusable VT console
On 08/19/14 09:28, Jean-Sébastien Pédron wrote: On 19.08.2014 10:42, Jean-Sébastien Pédron wrote: On 16.08.2014 01:51, Nathan Whitehorn wrote: It also has bad effects on boot time. My desktop takes something like 3 times as long to boot after r269471. If it can't be fixed quickly, it needs to be reverted. Just a quick note: I'm working on an update to vt_vga. Hello! Here's a first version of the patch I was talking about: https://people.freebsd.org/~dumbbell/vt/vt-vga.5.patch Thanks! What's new/fixed: o vt_vga introduces a new callback, vd_bitblt_text_t, which takes as argument the text buffer, the dirty area, the font and the cursor (position, map, colors). With all this information at hand, it can redraw the dirty area with almost no read from the video memory. This greatly improves the performance. The implementation is quite naive and I put a lot of comments. This could probably be simplfied/improved. The cursor is drawn at the same time than the text: this avoids flickering of the mouse pointer. The patch reads from the video memory only when the byte to write uses more than 2 colors (fg/bg). But this only happens with colored text around the cursor or with fonts who's width isn't a multiple of 8. Why is this necessary? I'd really prefer to avoid complicating this API. One of the great things about writing newcons drivers is that there is basically only one function you need to implement. If the current API does not provide enough information to do this efficiently, I'd much rather change it than add new callbacks. -Nathan o In vt_flush(), handle the cursor position before getting the dirty area. This fixes a bug where, if we move the cursor too fast, its new location is outside the marked area and it disappears from the screen. While here, mark the new position of the cursor as dirty, not only the old one. For the cursor to be drawn, VWF_MOUSE_HIDE must not be set *and* VDF_MOUSECURSOR must be set! Before, only the former was checked when deciding if the cursor position should be marked as dirty. Finally, if the cursor didn't move, don't mark its position as dirty. Before, these two problems caused major redraw of a large part of the screen for nothing, due to a mouse pointer location of [0;0] (even if disabled) and its position always marked as dirty. o When the mouse state is changed, mark its position as dirty. o The flush timer is paused during a window switch. In the case of vt_vga, vga_initialize() is called and it messes with VGA registers and the video memory. If vt_flush() is triggered at the same time, unexpected data are displayed. This is fixed, though, there's still a annoying flickering, because the sync signal is temporarily stopped during vga_initialize(). o The patch includes another non-related patch, which tries to stabilize the refresh rate. Currently, we schedule the next redraw in 40 ms (25 Hz), but that doesn't count for the time taken to redraw. o Change how the mouse is enabled/disabled/shown/hidden. Now, the GETLEVEL and GETMODE ioctls don't touch this. Everything goes through the CONS_MOUSECTL ioctl. This fixes vidcontrol -m on|off. Known issues: o Instead of having an if (bitblt_text != NULL) check in vt_flush(), I'll add a generic bitblt_text callback which implements the old code, so that other drivers can be changed incrementally. o In vt_vga, the screen flickers during a window switch, because it stops the sync signal and zeroes the memory. It would be nice to avoid that. o Several issues when the font is changed: 1. The offset to center the text area is global, not per window. Therefore other window are not centered anymore. 2. There's a bug with my patch, where other windows have the top-left letter wrongly shifted. 3. When the text area changes (compared to the whole screen), there's garbage in the borders. 4. The text cursor (the square) may be broken on other windows. o The mouse pointer is somtimes not erased during a move. o The text square cursor handling in vt_vga could be improved: colors are just reversed, we shouldn't change the fg/bg colors, just write a 0x00 pattern instead. o The vt_flush() timer could maybe be stopped when there's nothing to draw. No need to wakeup a core for that. Any comments? ___ 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: r269471 make unusable VT console
On 19.08.2014 19:46, Nathan Whitehorn wrote: On 08/19/14 09:28, Jean-Sébastien Pédron wrote: o vt_vga introduces a new callback, vd_bitblt_text_t, which takes as argument the text buffer, the dirty area, the font and the cursor (position, map, colors). Why is this necessary? I'd really prefer to avoid complicating this API. One of the great things about writing newcons drivers is that there is basically only one function you need to implement. If the current API does not provide enough information to do this efficiently, I'd much rather change it than add new callbacks. I don't want to have two callbacks for the same feature either, and I'd like to transition other drivers to this new one. The current bitbltchr callback only knows about one character. In the case of vt_vga, if this character (or the cursor) isn't aligned on 8-pixels boundaries, it needs to redraw several blocks of pixels. With this character-centric approach, if a block needs a redraw, it'll be refreshed for the character on its left side, then refreshed again for the character on its right side. The advantage of giving the callback the whole text/area is that it allows the driver to manipulate the pixels block by block, instead of character by character. The patch isn't finished yet. Meanwhile, I'll commit the bug fixes I made (especially the cursor handling in vt_flush()). But eventually, the plan is to convert all drivers to this new callback, if you find the new API sensible. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: r269471 make unusable VT console
Hey, this is cool! So hm, why are you still doing any reading? Don't you now have all the information you need to write out the font and cursor information for each given set of 8 pixels? -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: r269471 make unusable VT console
On 19.08.2014 21:20, Adrian Chadd wrote: Hey, this is cool! So hm, why are you still doing any reading? Don't you now have all the information you need to write out the font and cursor information for each given set of 8 pixels? I read a lot about VGA in the past days but I'm new to this interface, so my reasonning may be wrong. Anyway, here it is: To write a group of 8 pixels with only 2 colors, I write a byte using background color in an offscreen memory, read it back to load it in the latches, put the foreground color in the Set/Reset register, then write the character/cursor to its final location in video memory. Because the background color almost never changes, only one read is made the first time we load the background color, and then only writes. This is fast. If the group of 8 pixels uses 3 or more colors, I can't use Write Mode 3 alone. I see two possibilities: 1. Set Write Mode 0, then for each plane, compute the byte to write (1 bit out of 4 of each pixel's color), activate one plane, write the byte (repeat for each plane), restore Write Mode 3 and the relevant registers. 2. Stay in Write Mode 3, do a read/write for each colors. The first solution has a constant time of execution. The second one depends on the number of colors. In the end, I guess both solutions are expensive, but hopefully are rarely used. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: r269471 make unusable VT console
On 08/19/14 12:02, Jean-Sébastien Pédron wrote: On 19.08.2014 19:46, Nathan Whitehorn wrote: On 08/19/14 09:28, Jean-Sébastien Pédron wrote: o vt_vga introduces a new callback, vd_bitblt_text_t, which takes as argument the text buffer, the dirty area, the font and the cursor (position, map, colors). Why is this necessary? I'd really prefer to avoid complicating this API. One of the great things about writing newcons drivers is that there is basically only one function you need to implement. If the current API does not provide enough information to do this efficiently, I'd much rather change it than add new callbacks. I don't want to have two callbacks for the same feature either, and I'd like to transition other drivers to this new one. The current bitbltchr callback only knows about one character. In the case of vt_vga, if this character (or the cursor) isn't aligned on 8-pixels boundaries, it needs to redraw several blocks of pixels. With this character-centric approach, if a block needs a redraw, it'll be refreshed for the character on its left side, then refreshed again for the character on its right side. The advantage of giving the callback the whole text/area is that it allows the driver to manipulate the pixels block by block, instead of character by character. The patch isn't finished yet. Meanwhile, I'll commit the bug fixes I made (especially the cursor handling in vt_flush()). But eventually, the plan is to convert all drivers to this new callback, if you find the new API sensible. That sounds great. There are only a few (3?) discrete implementations of bitbltchr in the tree right now, so the conversion should be easy. -Nathan ___ 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: r269471 make unusable VT console
Hi, On 19 August 2014 12:40, Jean-Sébastien Pédron dumbb...@freebsd.org wrote: On 19.08.2014 21:20, Adrian Chadd wrote: Hey, this is cool! So hm, why are you still doing any reading? Don't you now have all the information you need to write out the font and cursor information for each given set of 8 pixels? I read a lot about VGA in the past days but I'm new to this interface, so my reasonning may be wrong. Anyway, here it is: To write a group of 8 pixels with only 2 colors, I write a byte using background color in an offscreen memory, read it back to load it in the latches, put the foreground color in the Set/Reset register, then write the character/cursor to its final location in video memory. Because the background color almost never changes, only one read is made the first time we load the background color, and then only writes. This is fast. If the group of 8 pixels uses 3 or more colors, I can't use Write Mode 3 alone. I see two possibilities: 1. Set Write Mode 0, then for each plane, compute the byte to write (1 bit out of 4 of each pixel's color), activate one plane, write the byte (repeat for each plane), restore Write Mode 3 and the relevant registers. Yup. That's how I've done it in the past. There's no read required and computing that stuff on modern CPUs is really cheap. -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
