Re: vt [was: Re: [Bug 235564] INDEX.keymaps for vt contains "from-" keymaps but the files are missing]
On Mon, Mar 09, 2020 at 10:37:52AM -0400, Ed Maste wrote: > On Sun, 8 Mar 2020 at 17:13, Andy Farkas wrote: > > > > Is anyone actually working on the vt(4) driver? Will it ever > > become feature-parity with the old sc(4) driver? > > Yes, and yes. What specific missing functionality are you affected by? > > > I've noticed some weird things happening on my console recently... > > like psychedelicly-colour-coded kernel messages.. far out, man. > > I don't think this is related to vt(4), but it would help if you > provided more details (including the version you're running). Take a look at r334530. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: [Bug 207223] acpica/acpi_battery.c: introduce hw.acpi.battery.rate sysctl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/10/2016 15:35, bugzilla-nore...@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207223 > > --- Comment #4 from Sean Bruno--- hrm. Is it > mW/second or something? A rate indicates some factor of time. > Watt already is Joule/second, i.e. Energy per Time -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJW4ZWBAAoJEH3raMNeVmMFoCcQAKDx6JonRNEbcLRs1f40ObNg UTiLfgFtlh+N5PlXxFIwOThir18EC/cOk/v0E+/jy6FDjp6Pg2xKuQxyQpgIi3I3 0pZMq8+s5NMF29asWdJ3ogh1JfgV1kialU9bXkm9eMzvC5/9pRVhTSR4Y49QJUO2 T4vcybE8K61pJI+K5vacHY3wwE7AL7aHE0srlrD6EUXgFcQ238vUwEVYE2w0fZrD XKvOTl2tCQs8WnY1n80zjB/eh8x3Bd1q/hWu9WdIrZTyh8tbSgQwVZMQ4bUx6Bep FTuHSgkW28SZ+drlwjg9/Mlv+VZLSsOIJkXV5v9H4+Ylln1hYktlndyBTyVq9c1x wqhzizGUimmCUl00eRmlEG65JO4ArRxsnhrsV8gBUKj6HqMQ/Bu7UmLU8if69/lH 6xGCDMBxSKViBYAzrCvTNTzrKHrTu1ESKE4mz32wZ7cwo/nqAX114o4nnmdkk8tb /rp6jmmYAVezoSWp9r/zzl3zHMBU5WWFV5eBDmHvzT+pWrfLhO61sL5SHZz9JqUk UWmQiQ258OvgWRLFCodncKvnUVqglit2QtUjJnWtzIjHbfbmQCvZmfb934al5GsB qbz3G4lIVTtBtoeV8XtLZtx/pFQDnzyG+2jXV/YWh6lZpsPI8+HLDMd+QQPWm31X DozkOtiwz12PSq+2T3lx =7dwQ -END PGP SIGNATURE- ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/184466: kernel doesn't compilling with options NFS_DEBUG
Number: 184466 Category: kern Synopsis: kernel doesn't compilling with options NFS_DEBUG Confidential: no Severity: non-critical Priority: low Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Tue Dec 03 09:50:00 UTC 2013 Closed-Date: Last-Modified: Originator: Konstantin Release:9.2 RELEASE Organization: home Environment: FreeBSD web_storage1 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26 22:50:31 UTC 2013 r...@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 Description: I inserted options NFS_DEBUG in kernel config and try to build kernel building stops with following: linking kernel.debug nfs_clbio.o: In function `ncl_asyncio': /usr/src/sys/fs/nfsclient/nfs_clbio.c:1457: undefined reference to `nfs_debug' /usr/src/sys/fs/nfsclient/nfs_clbio.c:1500: undefined reference to `nfs_debug' /usr/src/sys/fs/nfsclient/nfs_clbio.c:1474: undefined reference to `nfs_debug' /usr/src/sys/fs/nfsclient/nfs_clbio.c:1443: undefined reference to `nfs_debug' /usr/src/sys/fs/nfsclient/nfs_clbio.c:1534: undefined reference to `nfs_debug' nfs_clnfsiod.o:/usr/src/sys/fs/nfsclient/nfs_clnfsiod.c:319: more undefined references to `nfs_debug' follow *** [kernel.debug] Error code 1 Stop in /usr/obj/usr/src/sys/STORAGE. *** [buildkernel] Error code 1 Stop in /usr/src. *** [buildkernel] Error code 1 Stop in /usr/src. How-To-Repeat: Recompile kernel with options NFS_DEBUG Fix: Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
misc/183126: ������� ������������� FreeBSD - �� ������
Number: 183126 Category: misc Synopsis: ËÏÍÁÎÄÕ ÒÁÚÒÁÂÏÔÞÉËÏ× FreeBSD - ÎÁ ÐÅÎÓÉÀ Confidential: no Severity: non-critical Priority: low Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: update Submitter-Id: current-users Arrival-Date: Sun Oct 20 14:20:00 UTC 2013 Closed-Date: Last-Modified: Originator: konstantin Release:9.1, 9.2 Organization: myhouse Environment: Description: áÄÒÅÓÁ ÎÁÈÏÖÄÅÎÉÑ ÐÏÒÔÏ× ÍÅÎÑÀÔÓÑ ÎÅÓËÏÌØËÏ ÒÁÚ × ÓÕÔËÉ!!! How-To-Repeat: Fix: úÁËÒÙÔØ ÒÁÚÒÁÂÏÔËÕ ÓÉÓÔÅÍÙ, É ÚÁÎÑÔØÓÑ ÞÅÍ-ÔÏ ÂÏÌÅÅ ÐÏÌÅÚÎÙÍ ÄÌÑ ÏÂÝÅÓÔ×Á. óÅÔÉ ÚÁÂÉ×ÁÔØ ÎÅ ÂÕÄÅÔÅ. Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
kern/181375: disk free space blackhole magic
Number: 181375 Category: kern Synopsis: disk free space blackhole magic Confidential: no Severity: non-critical Priority: low Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Sun Aug 18 14:30:00 UTC 2013 Closed-Date: Last-Modified: Originator: Konstantin Release:FreeBSD 8.3 - FreeBSD 8.4 Organization: Kaspersky Lab Environment: FreeBSD 8.3-RELEASE-p5 FreeBSD 8.3-RELEASE-p5 #1: Thu Dec 6 17:13:30 UTC 2012 r...@tb.kaspersky-labs.com:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD test 8.4-RELEASE FreeBSD 8.4-RELEASE #0 r251259: Sun Jun 2 21:26:57 UTC 2013 r...@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 Description: FreeBSD 8.3 - FreeBSD 8.4 amd64 SMP soft updates noatime A daemon running as unprivileged user writes a log. Newsyslog rotates this log every hour and compress it by gzip. Some time later (about 1-2 weeks on our real systems) filesystem gets full. df and du show different results. Kill processes ('/etc/rc.d/jail stop' to be honest) doesn't help. Finally, it is impossible to umount this partition. We get Device busy error, but fstat and/or lsof doesn't show something. We know about open file deletion issue and other reasons why df and du shows different results, but it looks like it is not our case. Our real systems use jail environment, but it is possible to repeat this strange behavior without jail. We could not repeat this on non-SMP system, but it is not heavily tested. Below are more details: # tunefs -p /dev/mfid0p4 tunefs: POSIX.1e ACLs: (-a)disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f)16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) We tested with disabled Soft Updates. It did not help. /etc/fstat: /dev/mfid0p4/jail ufs rw,noatime 2 2 We tested without noatime options. It did not help. jail newsyslog.conf: /var/log/urep.txt kuser:logv 664 24 * 1 Z /var/run/kur.service.pid real logs: -rw-rw-r-- 1 1001 1002 17361916663 Aug 16 18:59 urep.txt -rw-rw-r-- 1 1001 1002 5801630304 Aug 16 18:00 urep.txt.0.gz -rw-rw-r-- 1 1001 1002 4950129578 Aug 16 17:00 urep.txt.1.gz -rw-rw-r-- 1 1001 1002 2333474330 Aug 16 08:00 urep.txt.10.gz -rw-rw-r-- 1 1001 1002 1154592135 Aug 16 07:00 urep.txt.11.gz -rw-rw-r-- 1 1001 1002783671738 Aug 16 06:00 urep.txt.12.gz -rw-rw-r-- 1 1001 1002641988029 Aug 16 05:00 urep.txt.13.gz -rw-rw-r-- 1 1001 1002711639597 Aug 16 04:00 urep.txt.14.gz -rw-rw-r-- 1 1001 1002858166595 Aug 16 03:00 urep.txt.15.gz -rw-rw-r-- 1 1001 1002 1129264281 Aug 16 02:00 urep.txt.16.gz -rw-rw-r-- 1 1001 1002 1825284327 Aug 16 01:00 urep.txt.17.gz -rw-rw-r-- 1 1001 1002 2336803342 Aug 16 00:00 urep.txt.18.gz -rw-rw-r-- 1 1001 1002 2412378597 Aug 15 23:00 urep.txt.19.gz -rw-rw-r-- 1 1001 1002 5808607921 Aug 16 16:00 urep.txt.2.gz -rw-rw-r-- 1 1001 1002 2751801103 Aug 15 22:00 urep.txt.20.gz -rw-rw-r-- 1 1001 1002 2546710751 Aug 15 21:00 urep.txt.21.gz -rw-rw-r-- 1 1001 1002 2540838045 Aug 15 20:00 urep.txt.22.gz -rw-rw-r-- 1 1001 1002 3015737372 Aug 15 19:00 urep.txt.23.gz -rw-rw-r-- 1 1001 1002 3251842089 Aug 15 18:00 urep.txt.24.gz -rw-rw-r-- 1 1001 1002 5239690207 Aug 16 15:00 urep.txt.3.gz -rw-rw-r-- 1 1001 1002 6059472499 Aug 16 14:00 urep.txt.4.gz -rw-rw-r-- 1 1001 1002 6249745715 Aug 16 13:00 urep.txt.5.gz -rw-rw-r-- 1 1001 1002 6314110754 Aug 16 12:00 urep.txt.6.gz -rw-rw-r-- 1 1001 1002 6142097019 Aug 16 11:00 urep.txt.7.gz -rw-rw-r-- 1 1001 1002 5700280821 Aug 16 10:00 urep.txt.8.gz -rw-rw-r-- 1 1001 1002 3843021410 Aug 16 09:00 urep.txt.9.gz # dmesg pid 81826 (ksn_urlrepd), uid 1001 inumber 15002792 on /jail: filesystem full pid 81826 (ksn_urlrepd), uid 1001 inumber 15002792 on /jail: filesystem full pid 81826 (ksn_urlrepd), uid 1001 inumber 15002792 on /jail: filesystem full pid 81826 (ksn_urlrepd), uid 1001 inumber 15002792 on /jail: filesystem full # df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/mfid0p29.7G1.1G8.0G12%/ devfs 1.0k1.0k 0B 100%/dev /dev/mfid0p4256G238G
kern/181257: bge link status change
Number: 181257 Category: kern Synopsis: bge link status change Confidential: no Severity: non-critical Priority: low Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Tue Aug 13 09:20:00 UTC 2013 Closed-Date: Last-Modified: Originator: Konstantin Release:9.1-RELEASE and 9.2-BETA1 Organization: Environment: 1-st system FreeBSD BSD_ev1 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 2-nd system FreeBSD smtp1.merlion.ru 9.2-BETA1 FreeBSD 9.2-BETA1 #0 r253470: Sun Mar 3 19:01:47 MSK 2013 root@dcgate1:/usr/obj/usr/src/sys/GATE amd64 Description: bge interfaces doesn't logging link state changes. Interface is up and status is active, after unplugging cable there's no message either in /var/log/messages nor on console (kern.consmute=0). If plug cable in interface, there's no message in log also. But if exec ifconfig command when cable unplaged - message appears. After plug cable back appears link up message. How-To-Repeat: 1.Plug network cable into bge interface, bring it up. 2.Unplug cable from bge interface. (there's no log messages) 3.Plug cable back. (still no messages) 4. Unplug cable from bge interface. (still no messages) 5. exec ifconfig command from terminal. 6. Message 'link down' appears. 7. Plug cable in bge interface. Link change to up appears. 8. If unplug cable from bge there's no message until ifconfig executed. Fix: There's no way to solve the problem. Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64
The following reply was made to PR kern/131597; it has been noted by GNATS. From: Konstantin Belousov kostik...@gmail.com To: Jilles Tjoelker jil...@stack.nl Cc: bug-follo...@freebsd.org, John Baldwin j...@freebsd.org, guilla...@morinfr.org, thera...@freebsd.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Date: Mon, 1 Jul 2013 03:24:06 +0300 --tdVUlQTxnujgnAno Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 30, 2013 at 11:28:55PM +0200, Jilles Tjoelker wrote: On Sun, Jun 30, 2013 at 06:12:32AM +0300, Konstantin Belousov wrote: On Sat, Jun 29, 2013 at 11:53:35PM +0200, Jilles Tjoelker wrote: On Fri, 28 Jun 2013 20:45:38 +0300, Konstantin Belousov wrote: As I said, libunwind relies on the signal blocking behaviour to be able to unwind from the signal handler. =20 OK :( =20 I am a bit concerned, though, that this is only needed for the unthreaded programming environment. libthr has an efficient method for postponing signals that avoids system calls. Moving that mechanism to libc, although it is a bit hard, may be an option. =20 Well, the right answer then is, in fact, to merge libc and libthr. I implemented ELF filters as the first required step, but did not progressed the task further. =20 IMO the merge is mostly mechanical, the complication is due to the fact that the work should be done in branch and takes a lot of time. As result, the libc and libthr changes during development are conflicting and have to be constantly resolved. =20 A full merge would make people unhappy who want a separate unthreaded programming environment so that, for example, libstdc++ can allocate smaller data structures without locks. (Note that this requires breaking pthread_once() in the unthreaded programming environment.) libgcc++ could switch to the method used by all other platforms, on the FreeBSD too. It seems that the presence of the pthread_cancel() symbol works as an indicator. We can easily implement the switch locally, and I am sure that upstream will accept such change. =20 However, even without pthread_create() and pthread_once(), a lot of functionality could be moved from libthr to libc, assuming we are willing to declare mixing and matching libc and libthr versions completely unsupported (by adding a check). For example, the signal handling, cancellation checks and errno. In the case of dynamic linking, a partial merge will require fewer symbols to be exported FBSDprivate_1.0 which reduces PLT indirection and will make up for some overhead. We already do not support mixing different versions of libc and libthr, since libthr copies the pthread stubs over the libc table. =20 An example of this partial merge is lib/libc/gen/sem_new.c. In fact, the export of the pthread* symbols from libc is very unfortunate. --tdVUlQTxnujgnAno Content-Type: application/pgp-signature -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR0MwlAAoJEJDCuSvBvK1BSkwP+wa9pn0DcrxOlt16Kl5bARph +yQriobX54RilXMBEuhB07IFxN+iECGgbXieq3iPMhY5Q925doZIjIKViFfnPWfy MD4dpQKxpVInL77/GOPeBzGcqNtMg/Ubfn4pKAP9Mmv+mNIjPOVOka8zzDwTCyrR NkNMyA4bNtUWVnb6y1yb1t2PUP3W9RTjhbC9xgfCwXzL1IwwWZwMv0+Ate75E5EY I7F+eOUqhCWNHUHfw4ezF7ZqB7faY9/ScGJTKbOlJ8C9h0BtnNeb/zCZXsgu4+UN Gt6LtpQib5eya05braKOJVaALpksQ+MHTNvWmMmodBLnjHu4fyVfBTmAwNkk+VnQ UaXMpGsiuGev4ebfF3ccVDVYgsUXM4mZM+RmyBoMKJ64fNtXO+esBNSBqAPH2GzK WE426lq+MPXj4kG5WXGiW7oDY4L1jYM8yEH+E5NL1MdEXZmDiKvPvRQjEfnaB8HJ 9XgJCKEDSPuxD1lkmLhLzEke0SCN+r+CoDbbyL5MSPzCSQjeYxCy27iO7yg/G/65 +wzPwLTtR2V/ujuDcYUVXCDff/Uqcs44rlcfQ9fzpOyWa0Z2bZ+7zyVs4xhwhW4Y Y8tV+yLXRjwPMyoUv+ODDbEZlUpob2Kj9wiVqB/9r4lwunDpDUzTq1v2+JNl9jTr R1ZGkOAUMKWZzxhaJqgj =N7Lu -END PGP SIGNATURE- --tdVUlQTxnujgnAno-- ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64
The following reply was made to PR kern/131597; it has been noted by GNATS. From: Konstantin Belousov kostik...@gmail.com To: John Baldwin j...@freebsd.org Cc: bug-follo...@freebsd.org, guilla...@morinfr.org, thera...@freebsd.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Date: Fri, 28 Jun 2013 20:17:21 +0300 --hhtCH1hro9pJkPIH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 28, 2013 at 08:47:55AM -0400, John Baldwin wrote: Looking at this again, the patch committed in 178807 is just wrong and sh= ould=20 be reverted. There is no state in rtld that needs to be protected via a = write=20 lock. GCC is too lazy to use their own locking to protect shared state= =20 between threads and wants the runtime linker to enforce this. Their=20 justification that glibc doesn't allow concurrent execution of this isn't= a=20 valid excuse. For an API like this that just walks a list and invokes a= =20 callback, if the callback manipulates shared state owned by the caller, t= he=20 caller should be responsible for sychronizing access to it, not rtld! =20 Instead I think we should apply the patch in the original GCC bug to our = in- tree GCC and to our GCC ports. This should remove the sigprocmask calls = and not penalize other users of dl_iterate_phdr() for GCC's poor behavior. In other words, we should become knowingly incompatible with the stock GCC and with other consumers of dl_iterate_phdr(), like libunwind ? E.g. libunwind ability to unwind from the signal handler relies on this behaviour. --hhtCH1hro9pJkPIH Content-Type: application/pgp-signature -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRzcUgAAoJEJDCuSvBvK1BBuwQAIWoFrFkw9Op7RybuuAw9K5h f49+JDpcscYrQcF8KSYWiUdV3ZcoBnubqKpT+6vWm5MQ4PwUCEv3ouKAhD/oe4n+ oJg3pQz+mFicI7s0Wr3rJFyf0vO5wcHnxDOq7XdjHIPlGqTZcnOjubdCJ42xpZkT 7004JA8B8WHitjh+9qJGQWOUDfBzUWDE3WwieqpYnKricnFhJh8/6gTg6abbZGkE 6szxxKdPMUHJ28X54HU1DV9A2TJgfjLsGIzneQtfpOp7TTIyTKfn2hFHp5eLhWB/ voH0HAegdg7ew3MaCl2fnGKb6UR0h3yShowp3KfH1LozmZNDw6C/6VSKwy55aSYY GaVXlWEhniim7NaRgP2okdMPEz07pUt3KoIN5mQGrlvgusTUa7YXcrwCm97l72dT EqjgffvFUPmmHP38jhgf/wkI1aQ6tY7eSqSLDM+MMBX6TnPKx4EAr3H/tc79idEx O89zUHFJPuI7YY563O+dR0Bm09kIDPVNb3hTG09JF2KCxY3QYlje8Iu5ndKOLCi+ HvFwnTLpDEFEd22oNWdSeNUq97Rr2mAMSv5dk9A+a8mtsRbzPSeuylIKSEEKquDu USJ2ZyISoTnZbb6Iz6SYkZRn8vOBRUfBbpPRcAJh2FkBTegl7JE7dS3tM7C26uzf MxGTc8YbAXTWA1XFxyZR =hwdp -END PGP SIGNATURE- --hhtCH1hro9pJkPIH-- ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64
The following reply was made to PR kern/131597; it has been noted by GNATS. From: Konstantin Belousov kostik...@gmail.com To: John Baldwin j...@freebsd.org Cc: bug-follo...@freebsd.org, guilla...@morinfr.org, thera...@freebsd.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Date: Fri, 28 Jun 2013 20:45:38 +0300 --8C4Pdt+UNHoLxtm5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 28, 2013 at 01:38:39PM -0400, John Baldwin wrote: On Friday, June 28, 2013 1:17:21 pm Konstantin Belousov wrote: On Fri, Jun 28, 2013 at 08:47:55AM -0400, John Baldwin wrote: Looking at this again, the patch committed in 178807 is just wrong an= d should=20 be reverted. There is no state in rtld that needs to be protected vi= a a write=20 lock. GCC is too lazy to use their own locking to protect shared sta= te=20 between threads and wants the runtime linker to enforce this. Their= =20 justification that glibc doesn't allow concurrent execution of this i= sn't a=20 valid excuse. For an API like this that just walks a list and invoke= s a=20 callback, if the callback manipulates shared state owned by the calle= r, the=20 caller should be responsible for sychronizing access to it, not rtld! =20 Instead I think we should apply the patch in the original GCC bug to = our in- tree GCC and to our GCC ports. This should remove the sigprocmask ca= lls and not penalize other users of dl_iterate_phdr() for GCC's poor behavior. =20 In other words, we should become knowingly incompatible with the stock GCC and with other consumers of dl_iterate_phdr(), like libunwind ? E.g. libunwind ability to unwind from the signal handler relies on this behaviour. =20 Does libunwind depend on rtld single-threading to lock state shared with other threads? If it does it should manage that itself. If GCC and/or libunwind want to share arbitrary state between threads, or protect state from being accessed by a signal handler, then GCC and/or libunwind should manage that. rtld can't possibly (and shouldn't) know the rules about how that state that is private to GCC/libunwind is managed. libunwind depends on the dl_iterate_phdr() signal-safety. =20 What if you had a consumer of this that wanted to access the state outside of the callback? Then it already has to manage all the locking itself to be safe anyway. =20 Put another way, requiring dl_iterate_phdr() to providing locking for con= sumers would be equivalent to code assuming that C++'s for_each() template in algorithm provided locking to callers. That is entirely upside-down. I think I should revive the fast sigprocmask patch. --8C4Pdt+UNHoLxtm5 Content-Type: application/pgp-signature -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRzcvBAAoJEJDCuSvBvK1B9UgP/jne8523ys+JZDGUn9izYhJk LlT5LSSARhTcbREEsIevB5VQt2pbDtKsca/fCtLmaasPN5cb8XgLeyy1J3caB742 LdrXLcczv8PvSJM0D7EDTH6ktGrmAl0i9cHb8sLqHuPAD7/ZNBJRfJXWdRe4Rs3r /A78kqAdyGlJAupQ+2ocbtsIOg8F1G3L3b7iZ+gA7+txErCv5th6H3+lXalpF+8X 40FDUvpoU9roOesa9vKcQLFWcBMedLkVmTujmHrvFfMuz6zXu+0Anje5Zc0LPOSu hst4vYimFxn/VXQuU5qmGKhhz0o0jtwJzdF836aJotx2tsQWuBLWZiKSBffKQFeB D6aK0GlMlK/i6LQD+LeJbjB+k0/jxgK6ZtdetUPnPCUjeHE5IKDrm1Z0yMzMC/20 H5AQ3WdFR7Jvu11ZK6jp2aqX6BDUTTwW85c1Y/k2n5+I48vD1EDXRDO73aQkHyM8 0EU5kCPS1CRbXsf4XeGlye/YhJBNS7Hp/tdNSjhSjHckA78xLUsoKeo6LfCmFtG6 GT8oDSmyugQl6QwCNzNp9bjKJ3wSI1TZjBr8GNQI/kXZJpaJkFb6mzLLLhUbjtt/ XHrA2gaJDE9eTlOohoBO8zJ8bXe1ykK/YuduXdsAfpqKH4KckkEqUiA1ptrMV7C6 9olJnLJJMrgbMjv955u6 =/5H4 -END PGP SIGNATURE- --8C4Pdt+UNHoLxtm5-- ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: bin/171662: procstat(1) fails to recognize AT_TIMEKEEP
The following reply was made to PR bin/171662; it has been noted by GNATS. From: Konstantin Belousov kostik...@gmail.com To: Jan Beich jbe...@tormail.org Cc: freebsd-gnats-sub...@freebsd.org, troc...@freebsd.org Subject: Re: bin/171662: procstat(1) fails to recognize AT_TIMEKEEP Date: Sat, 15 Sep 2012 17:04:42 +0300 --Gs9iBZf6UKWgztis Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 15, 2012 at 02:26:36AM -0900, Jan Beich wrote: =20 Number: 171662 Category: bin Synopsis: procstat(1) fails to recognize AT_TIMEKEEP Confidential: no Severity: non-critical Priority: low Responsible:freebsd-bugs State: open Quarter: =20 Keywords: =20 Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Sat Sep 15 11:50:09 UTC 2012 Closed-Date: Last-Modified: Originator: Jan Beich Release:FreeBSD 10.0-CURRENT amd64 Organization: Environment: Description: How-To-Repeat: $ procstat -x $(pgrep firefox) PID COMM AUXV VALUE 90996 firefox AT_PHDR 0x400040 90996 firefox AT_PHENT 56 90996 firefox AT_PHNUM 8 90996 firefox AT_PAGESZ4096 90996 firefox AT_FLAGS 0 90996 firefox AT_ENTRY 0x401790 90996 firefox AT_BASE 0x80060d000 90996 firefox AT_EXECPATH 0x7fffefc8 90996 firefox AT_OSRELDATE 118 90996 firefox AT_CANARY0x7fffef88 90996 firefox AT_CANARYLEN 64 90996 firefox AT_NCPUS 2 90996 firefox AT_PAGESIZES 0x7fffef70 90996 firefox AT_PAGESIZESLEN 24 90996 firefox22 0x7190 90996 firefox AT_STACKPROT EXECUTABLE Fix: Release-Note: Audit-Trail: Unformatted: Yes, I forgot about procstat at all when I added AT_TIMEKEEP. I also noted that AT_COUNT is defined in the switch statement, which is not useful. AT_COUNT is not an auxv at all, it is just count. diff --git a/usr.bin/procstat/procstat_auxv.c b/usr.bin/procstat/procstat_a= uxv.c index 9bf7afb..b78e13a 100644 --- a/usr.bin/procstat/procstat_auxv.c +++ b/usr.bin/procstat/procstat_auxv.c @@ -231,9 +231,11 @@ procstat_auxv(struct kinfo_proc *kipp) else PRINT(AT_STACKPROT, %s, EXECUTABLE); break; - case AT_COUNT: - PRINT(AT_COUNT, %ld, (long)auxv[i].a_un.a_val); +#ifdef AT_TIMEKEEP + case AT_TIMEKEEP: + PRINT(AT_TIMEKEEP, %p, auxv[i].a_un.a_ptr); break; +#endif default: PRINT_UNKNOWN(auxv[i].a_type, auxv[i].a_un.a_val); break; --Gs9iBZf6UKWgztis Content-Type: application/pgp-signature -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBUivoACgkQC3+MBN1Mb4hzpgCfbYe5K3wLrY3o6jqEwMt+CaiL OGsAn3+FVxju/YcO6AFi4ZQGaA1qexxg =J8Zi -END PGP SIGNATURE- --Gs9iBZf6UKWgztis-- ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
bin/171279: bsnmpd can reply from other address
Number: 171279 Category: bin Synopsis: bsnmpd can reply from other address Confidential: no Severity: serious Priority: medium Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Mon Sep 03 14:50:04 UTC 2012 Closed-Date: Last-Modified: Originator: Konstantin Kukushkin Release:FreeBSD 9.0-STABLE amd64 Organization: Rambler Internet Holding, LLC Environment: System: FreeBSD vpn1-m1.rambler.ru 9.0-STABLE FreeBSD 9.0-STABLE #2 r231584M: Mon Feb 13 18:24:25 MSK 2012 gleb...@vpn1-m1.rambler.ru:/usr/obj/usr/home/glebius/9/sys/VPN amd64 Description: bsnmpd by default listen INADDR_ANY, and on multihomed system daemon can receive queries to some addresses. When replying to query bsdnmp simply use sendto(), so OS build response datagram with source ip nearest to sender, which can be not equal to destination ip on source query. This is ok for net-snmp utils like snmpget snmpwalk, but this can't work with statefull firewalls like ipfw(4) or pf(4). Please fix it. How-To-Repeat: I used multihomed host vpn1-m1: [pts/2] dark@vpn1-m1:~ ( ifconfig bge0 inet ; ifconfig lo0 inet )|grep inet inet 81.19.94.147 netmask 0xfff8 broadcast 81.19.94.151 inet 127.0.0.1 netmask 0xff00 inet 81.19.64.133 netmask 0x inet 81.19.79.1 netmask 0x with ``onestarted`` bsnmpd: [pts/2] dark@vpn1-m1:~ sudo /etc/rc.d/bsnmpd onestart Starting bsnmpd. [pts/2] dark@vpn1-m1:~ sockstat | grep 'bsnmpd.*161' root bsnmpd 38365 6 udp4 *:161 *:* and other host for query to address, routed to vpn1-m1: [pts/53] dark@dark:~ ifconfig re0 inet|grep inet inet 81.19.64.109 netmask 0xffe0 broadcast 81.19.64.127 [pts/53] dark@dark:~ snmpget -v 2c -c public 81.19.64.133 sysDescr.0 Timeout: No Response from 81.19.64.133. tcpdump on multihomed host shows that bsnmpd reply from source other that query destination: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bge0, link-type EN10MB (Ethernet), capture size 65535 bytes 15:17:16.007788 IP 81.19.64.109.60689 81.19.64.133.161: GetRequest(28) .1.3.6.1.2.1.1.1.0 15:17:16.008005 IP 81.19.94.147.161 81.19.64.109.60689: GetResponse(76) .1.3.6.1.2.1.1.1.0=vpn1-m1.rambler.ru 4212937669 FreeBSD 9.0-STABLE Fix: Other udp servers like named try to create listen socket bind()'ed on adresses from getifaddrs() output, not INADDR_ANY. While daemon receiving query on bind()'ed socket it knows on which address query was sent, and can reply right. Unfortunately I don't know any other mechanism getting datagram destination address in FreeBSD, in Linux there is 'IP_PKTINFO' socket option for this. Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/128870: [pccbb] Interrupt Storm when plugging in PCMCIA Card (HP NC8000 Notebook)
The following reply was made to PR kern/128870; it has been noted by GNATS. From: Konstantin Vasilev konstantin.vasil...@gmail.com To: bug-follo...@freebsd.org, a_wehrm...@hotmail.com Cc: Subject: Re: kern/128870: [pccbb] Interrupt Storm when plugging in PCMCIA Card (HP NC8000 Notebook) Date: Mon, 04 Jun 2012 15:23:23 +0400 Hi all, I have the same problem on 9.0 RELEASE. Wireless card driver is ath. Interrupt storm dramatically slows my system. -- With best regards, Konstantin Vasilev ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable sleep with apparently no syscall (empty wchan)
The following reply was made to PR kern/166340; it has been noted by GNATS. From: Konstantin Belousov kostik...@gmail.com To: Christian Esken christian.es...@trivago.com Cc: bug-follo...@freebsd.org, a...@freebsd.org Subject: Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable sleep with apparently no syscall (empty wchan) Date: Tue, 27 Mar 2012 20:46:26 +0300 --KldKAdupQSLqpq2E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 27, 2012 at 05:30:48PM +0200, Christian Esken wrote: Konstantin Belousov wrote: Thank you for the data. Semi-obviously, the callout_stop() call in sleepq_check_timeout() have to return 0, otherwise we would not call mi_switch() there. But I do not see how this can happen, because the callout state, printed from kgdb, still indicates that callout is pending. Callout cannot be reset while in sleepq code. =20 So there are two possible routes to go forward: preferrable is for you to extract the self-contained C program that would illustrate the issue and send this sample to me. Second is to recompile your kernel with INVARIANTS/WITNESS and possibly KTR and see what happen. =20 I repeated the test with INVARIANTS/WITNESS and KTR compiled in (actually WITNESS was already included during the last test). =20 I ran KTR with nothing filtered out, and formatted the dump with ktrdump -cftH -i ktr.out. The whole log is excessive (1GB), so I have extrated two short sections (see attachment). =20 The first section shows the last action of the application, namely a succselful sendto() to a TCP socket, and then waiting for an answer via recvfrom(). The second section illustrates the lock/unlock sequence of the sleep mutex for the recfrom(). It goes like LOCK, LOCK, UNLOCK. =20 This time the signal status is different. We have a pending signal: USER PID PPID PENDING CAUGHT IGNORED BLOCKED STAT WCHAN nobody 9163 1 4000 80005006 79f880100 D-=20 =20 Looks like SIGPROF (27). Just wondering where it comes from. =20 This is irrelevant, and probably red-herring. The issue there is failing callout_stop() while callout seems to be still pending. Also, mask 0x4000 of the pending signals indicates that SIGTERM is pending, not SIGPROF. I probably want the data from your ktr dump, either all entries for the stuck process and all entries for facility CALLOUT, or just the whole dump. Last entries of your log shred do not make much sense, since the process must enter _sleep() function which logs this fact right after locking sleepq. But log ends on so_rcv mutex lock. Please, when collecting the data, collect the whole set, i.e. include procstat -kk pid output together with the ktr, as well as kgdb output, so that I can be sure that we chasing one, and not N bugs. --KldKAdupQSLqpq2E Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9x/PIACgkQC3+MBN1Mb4hbeACfYyUTEE5GV/SeDO4fNf4ErfHY 27oAoIGj2TMOBtQRi5P+q/v+nrKOFhFb =0tFs -END PGP SIGNATURE- --KldKAdupQSLqpq2E-- ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable sleep with apparently no syscall (empty wchan)
The following reply was made to PR kern/166340; it has been noted by GNATS. From: Konstantin Belousov kostik...@gmail.com To: Christian Esken christian.es...@trivago.com Cc: bug-follo...@freebsd.org, a...@freebsd.org Subject: Re: misc/166340: Process under FreeBSD 9.0 hangs in uninterruptable sleep with apparently no syscall (empty wchan) Date: Mon, 26 Mar 2012 16:51:42 +0300 Thank you for the data. Semi-obviously, the callout_stop() call in sleepq_check_timeout() have to return 0, otherwise we would not call mi_switch() there. But I do not see how this can happen, because the callout state, printed from kgdb, still indicates that callout is pending. Callout cannot be reset while in sleepq code. So there are two possible routes to go forward: preferrable is for you to extract the self-contained C program that would illustrate the issue and send this sample to me. Second is to recompile your kernel with INVARIANTS/WITNESS and possibly KTR and see what happen. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
misc/159707: Olson's timezone database is old for Russia in 7.X/8.X
Number: 159707 Category: misc Synopsis: Olson's timezone database is old for Russia in 7.X/8.X Confidential: no Severity: non-critical Priority: low Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Fri Aug 12 11:10:08 UTC 2011 Closed-Date: Last-Modified: Originator: Konstantin Release:8.X/7.X Organization: Kaspersky Lab Environment: Description: The problem is that in 7.X and 8.X (except CURRENT 8-STABLE) Olsons timezone database for Europe is obsolete. I have found current version 8.33 only in RELENG_8. This spring Russian government had canceled Daylight saving time. So if you are still using 7.X or 8.0, 8.1, 8.2 in Russia, this fall you will definitely have problems with you timezone. Whole country will stay with UTC+4 and you will back to winter time UTC+3. That is not good at all =) Please update share/zoneinfo in src and add new /usr/share/zoneinfo/ files in binary update. How-To-Repeat: Fix: 1) Download new europe version from ftp://elsie.nci.nih.gov/pub/ or from RELENG_8 to /usr/src/share/zoneinfo/ 2) cd /usr/src/share/zoneinfo/ 4) make clean; make install 5) (if it's needed) cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
RE: misc/157499: fetch confused me with it's error message
The following reply was made to PR bin/157499; it has been noted by GNATS. From: Konstantin Malov konstantin.ma...@kaspersky.com To: Jaakko Heinonen j...@freebsd.org Cc: bug-follo...@freebsd.org bug-follo...@freebsd.org Subject: RE: misc/157499: fetch confused me with it's error message Date: Thu, 2 Jun 2011 12:48:07 +0400 I agree with this. So real problem is that this error message 'Syntax error, command unrecogni= zed' appears with warnx function:=20 warnx(%s: %s, URL, fetchLastErrString);=20 There are three such places in fetch.c where warnx is used without addition= al information about error cause. I don't know what to add in this place:=20 402 /* set the protocol timeout. */ 403 fetchTimeout =3D timeout; 404 405 /* just print size */ 406 if (s_flag) { 407 if (timeout) 408 alarm(timeout); 409 r =3D fetchStat(url, us, flags); 410 if (timeout) 411 alarm(0); 412 if (sigalrm || sigint) 413 goto signal; 414 if (r =3D=3D -1) { 415 warnx(%s, fetchLastErrString); 416 goto failure; 417 } 418 if (us.size =3D=3D -1) 419 printf(Unknown\n); 420 else 421 printf(%jd\n, (intmax_t)us.size); 422 goto success; 423 } But for last two I can suggest this patch:=20 --- fetch.c.orig2011-06-02 12:06:26.0 +0400 +++ fetch.c 2011-06-02 12:28:25.0 +0400 @@ -463,7 +463,7 @@ if (sigalrm || sigint) goto signal; if (f =3D=3D NULL) { - warnx(%s: %s, URL, fetchLastErrString); + warnx(data fetch from '%s' failed with error: %s, URL, fe= tchLastErrString); if (i_flag strcmp(url-scheme, SCHEME_HTTP) =3D=3D 0 fetchLastErrCode =3D=3D FETCH_OK strcmp(fetchLastErrString, Not Modified) =3D=3D 0)= { @@ -574,7 +574,7 @@ */ url-offset =3D 0; if ((f =3D fetchXGet(url, us, flags)) =3D=3D NULL)= { - warnx(%s: %s, URL, fetchLastErrString); + warnx(data fetch from '%s' failed with err= or: %s, URL, fetchLastErrString); goto failure; } if (sigint) -Original Message- From: Jaakko Heinonen [mailto:j...@freebsd.org]=20 Sent: Thursday, June 02, 2011 12:01 PM To: Konstantin Malov Cc: bug-follo...@freebsd.org Subject: Re: misc/157499: fetch confused me with it's error message On 2011-06-01, Konstantin wrote: I have found out some strange error handling in /usr/bin/fetch. Here it is:=20 =20 # fetch ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz fetch: ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz: Syntax= error, command unrecognized USER anonymous 331 Please specify the password. PASS r...@h-ksn-hkg-fe-2.kaspersky-labs.com 500 OOPS: cannot change directory:/home/ftp fetch: ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz: Synta= x error, command unrecognized This is how reply code 500 is defined in RFC 959: 500Syntax error, command unrecognized. This may include errors such as command line too long. --=20 Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
misc/157499: fetch confused me with it's error message
Number: 157499 Category: misc Synopsis: fetch confused me with it's error message Confidential: no Severity: non-critical Priority: low Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Wed Jun 01 14:20:05 UTC 2011 Closed-Date: Last-Modified: Originator: Konstantin Release:8.2-RELEASE/7.3-RELEASE Organization: Kaspersky Lab Environment: FreeBSD ourhost.kaspersky.com 7.3-RELEASE-p3 FreeBSD 7.3-RELEASE-p3 #0: Tue Sep 21 18:03:17 MSD 2010 r...@ourhost.kaspersky.com:/usr/obj/usr/src/sys/GENERIC amd64 Description: I have found out some strange error handling in /usr/bin/fetch. Here it is: # fetch ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz fetch: ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz: Syntax error, command unrecognized So it's very confusing error message. With some extra debug it looks more clear: # fetch -vvv ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz scheme: [ftp] user: [] password: [] host: [ftp.freebsd.org] port: [0] document: [/pub/FreeBSD/ports/ports/ports.tar.gz] --- ftp.freebsd.org:21 looking up ftp.freebsd.org connecting to ftp.freebsd.org:21 220 Welcome to freebsd.isc.org. How-To-Repeat: Fix: Release-Note: Audit-Trail: Unformatted: USER anonymous 331 Please specify the password. PASS r...@h-ksn-hkg-fe-2.kaspersky-labs.com 500 OOPS: cannot change directory:/home/ftp fetch: ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz: Syntax error, command unrecognized # host ftp.freebsd.org ftp.freebsd.org has address 204.152.184.73 ftp.freebsd.org has address 87.51.34.132 ftp.freebsd.org has address 149.20.64.73 ftp.freebsd.org has IPv6 address 2001:4f8:0:2::e ftp.freebsd.org has IPv6 address 2001:6c8:2:600::132 Actually this problem exists only with 204.152.184.73 server. See ftp connect to it: # ftp ftp open ftp.freebsd.org Trying 204.152.184.73... Connected to ftp.freebsd.org. 220 Welcome to freebsd.isc.org. Name (ftp.freebsd.org:root): ftp 331 Please specify the password. Password: 500 OOPS: cannot change directory:/home/ftp ftp: Login failed. ftp exit 500 OOPS: priv_sock_get_cmd I don't know why fetch on 7.3 sticked to this server and I had error 'Syntax error, command unrecognized' every time I run fetch. It could be some problem in DNS resolving algorithm on 7.3. On 8.2 fetch works with different servers, so I had this error n ot very often. Anyway, error message 'Syntax error, command unrecognized' on some FTP problems sounds very confusing for me. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
kern/156545: mv could break UFS on SMP systems
Number: 156545 Category: kern Synopsis: mv could break UFS on SMP systems Confidential: no Severity: serious Priority: low Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Thu Apr 21 10:20:08 UTC 2011 Closed-Date: Last-Modified: Originator: Konstantin Release:8.X/7.X Organization: Kasperksy Lab Environment: # uname -a FreeBSD test-host 8.2-RELEASE FreeBSD 8.2-RELEASE #1: Thu Apr 7 14:23:20 UTC 2011 root@host:/usr/obj/amd64/usr/src/sys/GENERIC amd64 Description: We have found out a strange mv(1) behaviour on SMP systems with UFS. If two or more processes are trying to move the same dir from one source, it could break UFS. It works on 7.X/8.X amd64 systems. Actually, i think, it works on all systems with SMP on all platforms. I guess that the problem is somewhere in ./sys/ufs/ufs/ufs_vnops.c because i can't repeat it for an example on ZFS partition. After UFS break you will see this: # mount /dev/da0p2 on / (ufs, local, noatime) devfs on /dev (devfs, local, multilabel) /dev/da0p4 on /data (ufs, local, noatime, soft-updates) # cd /data/test # ls -lai total 40 11540480 drwxr-xr-x 5 root wheel512 Apr 21 17:30 . 2 drwxr-xr-x 8 root wheel512 Apr 21 17:29 .. 11543482 drwxr-xr-x 3 root wheel 16384 Apr 21 17:37 dst1 11543483 drwxr-xr-x 3 root wheel512 Apr 21 17:37 dst2 11540481 drwxr-xr-x 2 root wheel 16384 Apr 21 17:37 src 4 -rw-r--r-- 1 root wheel738 Apr 21 17:33 test.pl # ls -lai dst1 total 20 11543482 drwxr-xr-x 3 root wheel 16384 Apr 21 17:37 . 11540480 drwxr-xr-x 5 root wheel512 Apr 21 17:30 .. 11541475 drwx-- 3 root wheel512 Apr 21 17:36 03qOT # ls -lai dst2 total 6 11543483 drwxr-xr-x 3 root wheel 512 Apr 21 17:37 . 11540480 drwxr-xr-x 5 root wheel 512 Apr 21 17:30 .. 11541475 drwx-- 3 root wheel 512 Apr 21 17:36 03qOT # rm -rf dst1/03qOT rm: dst1/03qOT: Invalid argument # rm -rf dst2/03qOT rm: dst2/03qOT: Invalid argument The only way to fix it is to unmount the partition and run the fsck on it. # fsck -vy /data start /data wait fsck_ufs -y /dev/da0p4 ** /dev/da0p4 ** Last Mounted on /data ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames /test/dst1/03qOT IS AN EXTRANEOUS HARD LINK TO DIRECTORY /test/dst1/03qOT REMOVE? yes BAD INODE NUMBER FOR '..' I=11541475 OWNER=root MODE=40700 SIZE=512 MTIME=Apr 21 17:36 2011 DIR=/test/dst2/03qOT UNEXPECTED SOFT UPDATE INCONSISTENCY FIX? yes ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts LINK COUNT DIR I=11541475 OWNER=root MODE=40700 SIZE=512 MTIME=Apr 21 17:36 2011 COUNT 3 SHOULD BE 2 ADJUST? yes LINK COUNT DIR I=11543482 OWNER=root MODE=40755 SIZE=16384 MTIME=Apr 21 17:37 2011 COUNT 3 SHOULD BE 2 ADJUST? yes ** Phase 5 - Check Cyl groups 7757 files, 87291 used, 134202352 free (256 frags, 16775262 blocks, 0.0% fragmentation) * FILE SYSTEM IS CLEAN * * FILE SYSTEM WAS MODIFIED * How-To-Repeat: You can use this script to repeat the problem: #!/usr/local/bin/perl use strict; my $iterations = 50; my $dirs = 1000; mkdir 'src'; for(1..$iterations) { print Iterations $_\n; do_test(); } sub do_test { print Creating $dirs sample directories...\n; for(1..$dirs) { my $dirname = `mktemp -d src/X`; chomp $dirname; system(touch $dirname/data touch $dirname/meta); print $_ ; } print done\n; my ($pid1, $pid2) = (do_job('src', 'dst1'), do_job('src', 'dst2')); waitpid($pid1, 0); waitpid($pid2, 0); } sub do_job { my ($src, $dst) = @_; my $pid = fork(); return $pid if $pid != 0; system(mkdir -p $dst ls $src | xargs -I _ mv -n $src/_ $dst); system(rm -rf $dst/*) == 0 or die; exit(0); } Fix: Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
kern/155004: kernel panic in bce0 driver
Number: 155004 Category: kern Synopsis: kernel panic in bce0 driver Confidential: no Severity: serious Priority: low Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Thu Feb 24 14:10:07 UTC 2011 Closed-Date: Last-Modified: Originator: Konstantin Release:7.3 Organization: Kasperksy Lab Environment: FreeBSD 7.3-RELEASE-p2 FreeBSD 7.3-RELEASE-p2 #0: Fri Sep 10 16:59:11 MSD 2010 root@/usr/obj/usr/src/sys/GENERIC amd64 Description: We have some IBM System x3550 servers with Broadcom NetXtreme II BCM5708 NICs. Sometimes kernel panic occurs on them under high load (about 900-950Mbs and 70-90 kpps). # kgdb kernel.debug /var/crash/vmcore.6 Unread portion of the kernel message buffer: 118Feb 22 15:39:51 d-ca1 syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...1 0 done All buffers synced. Uptime: 29m2s Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x10 fault code = supervisor read data, page not present instruction pointer = 0x8:0x802bed2a stack pointer = 0x10:0xff80001b7b70 frame pointer = 0x10:0x0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 30 (irq257: bce1) trap number = 12 panic: page fault cpuid = 1 Uptime: 29m2s Physical memory: 4082 MB Dumping 1385 MB: 1370 1354 1338 1322 1306 1290 1274 1258 1242 1226 1210 1194 1178 1162 1146 1130 1114 1098 1082 1066 1050 1034 1018 1002 986 970 954 938 922 906 890 874 858 842 826 810 794 778 762 746 730 714 698 682 666 650 634 618 602 586 570 554 538 522 506 490 474 458 442 426 410 394 378 362 346 330 314 298 282 266 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10 (kgdb) where #0 doadump () at pcpu.h:195 #1 0x0004 in ?? () #2 0x805285f9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #3 0x80528a02 in panic (fmt=0x104 Address 0x104 out of bounds) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0x807ec813 in trap_fatal (frame=0xff000158aae0, eva=Variable eva is not available. ) at /usr/src/sys/amd64/amd64/trap.c:777 #5 0x807ecbe5 in trap_pfault (frame=0xff80001b7ac0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:693 #6 0x807ed50c in trap (frame=0xff80001b7ac0) at /usr/src/sys/amd64/amd64/trap.c:464 #7 0x807d614e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:218 #8 0x802bed2a in bce_intr (xsc=Variable xsc is not available. ) at /usr/src/sys/dev/bce/if_bce.c:5771 #9 0x80506a92 in ithread_loop (arg=0xff000158ea60) at /usr/src/sys/kern/kern_intr.c:1181 #10 0x805034e3 in fork_exit (callout=0x80506930 ithread_loop, arg=0xff000158ea60, frame=0xff80001b7c80) at /usr/src/sys/kern/kern_fork.c:811 #11 0x807d652e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:554 #12 0x in ?? () #13 0x in ?? () #14 0x0001 in ?? () #15 0x in ?? () #16 0x in ?? () #17 0x in ?? () #18 0x in ?? () #19 0x in ?? () #20 0x in ?? () #21 0x in ?? () ---Type return to continue, or q return to quit--- (kgdb) up 8 #8 0x802bed2a in bce_intr (xsc=Variable xsc is not available. ) at /usr/src/sys/dev/bce/if_bce.c:5771 5771sc-rx_mbuf_ptr[sw_rx_cons_idx] = NULL; (kgdb) p *sc $2 = {bce_ifp = 0xff0001591800, bce_dev = 0xff0001575100, bce_unit = 1 '\001', bce_res_mem = 0xff0001688c00, bce_ifmedia = {ifm_mask = 0, ifm_media = 0, ifm_cur = 0x0, ifm_list = {lh_first = 0x0}, ifm_change = 0, ifm_status = 0}, bce_btag = 1, bce_bhandle = 18446742977654030336, bce_vhandle = 18446742977654030336, bce_res_irq = 0xff0001688580, bce_mtx = {lock_object = {lo_name = 0xff00015856d0 bce1, lo_type = 0x80856f26 network driver, lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 18446742974220511970, mtx_recurse = 0}, bce_intr = 0x802bea80 bce_intr, bce_intrhand = 0xff0001688b00, bce_irq_rid = 1, bce_msi_count = 1, bce_chipid = 1460146208, bce_flags = 97, bce_cap_flags = 9, bce_phy_flags = 2, bce_shared_hw_cfg = 325, bce_port_hw_cfg = 0, max_bus_addr = 1099511627775, bus_speed_mhz = 133, link_width = 0, link_speed = 0, bce_flash_info = 0x80a64330, bce_flash_size = 270336
misc/152988: no need for ip6fw in /etc/netstart
Number: 152988 Category: misc Synopsis: no need for ip6fw in /etc/netstart Confidential: no Severity: non-critical Priority: low Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Fri Dec 10 13:30:10 UTC 2010 Closed-Date: Last-Modified: Originator: Konstantin Release:8.1 Organization: Kasperksy Lab Environment: FreeBSD 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:55:53 UTC 2010 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Description: # /etc/netstart .. /etc/netstart.orig: /etc/rc.d/ip6fw: not found .. # fgrep ip6fw /etc/netstart /etc/rc.d/ip6fw ${_start} # # find /etc/rc.d/ -name ip6fw # there is no ip6fw script in 8.1 any more, but it presents in /etc/netstart How-To-Repeat: just run /etc/netstart =) and Fix: --- /etc/netstart.orig 2010-12-10 16:21:34.0 +0300 +++ /etc/netstart 2010-12-10 16:22:11.0 +0300 @@ -55,7 +55,6 @@ /etc/rc.d/dhclient ${_start} /etc/rc.d/ppp ${_start} /etc/rc.d/ipfw ${_start} -/etc/rc.d/ip6fw ${_start} /etc/rc.d/network_ipv6 ${_start} /etc/rc.d/routing ${_start} /etc/rc.d/mroute6d ${_start} Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
kern/150858: GEOM_LABEL is not compatible with newfs -r flag
Number: 150858 Category: kern Synopsis: GEOM_LABEL is not compatible with newfs -r flag Confidential: no Severity: non-critical Priority: medium Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Wed Sep 22 12:00:12 UTC 2010 Closed-Date: Last-Modified: Originator: Konstantin Kukushkin Release:8.1-STABLE Organization: Rambler Environment: FreeBSD dash.local 8.1-STABLE FreeBSD 8.1-STABLE #0: Wed Sep 22 13:18:16 MSD 2010 r...@dash.local:/var/tmp/obj/usr/src/sys/EEE8 i386 Description: For any provider, GEOM_LABEL strictly checks that ufs occupied all its space. But filesystem can be smaller, in case if newfs(8) was run with -r flag. So, GEOM_LABEL is not compatible with newfs -r flag. When check is more permissive (as in attached patch) all work OK: [pts/0] r...@dash:/usr/home/dark# uname -rp 8.1-STABLE i386 [pts/0] r...@dash:/usr/home/dark# ll /dev/ufsid/ total 0 crw-r- 1 root operator0, 93 22 ÓÅÎ 17:24 4992d90831a79611 [pts/0] r...@dash:/usr/home/dark# mdconfig -s 32m md0 [pts/0] r...@dash:/usr/home/dark# newfs -r 4 -U /dev/md0 /dev/md0: 32.0MB (65532 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 8.00MB, 512 blks, 1024 inodes. with soft updates super-block backups (for fsck -b #) at: 160, 16544, 32928, 49312 [pts/0] r...@dash:/usr/home/dark# ll /dev/ufsid/ total 0 crw-r- 1 root operator0, 93 22 ÓÅÎ 17:24 4992d90831a79611 crw-r- 1 root operator0, 118 22 ÓÅÎ 13:38 4c99ce860db39b88 [pts/0] r...@dash:/usr/home/dark# glabel status Name Status Components ntfs/sys N/A ada0s1 msdosfs/SYS N/A ada0s2 msdosfs/BIOS N/A ada0s3 ntfs/BIG N/A ada1s2 ufsid/4992d90831a79611 N/A ada1s1a ufsid/4c99ce860db39b88 N/A md0 How-To-Repeat: radius# uname -rp 8.1-20100726-SNAP i386 radius# ll /dev/ufsid/ total 0 crw-r- 1 root operator0, 98 21 ÓÅÎ 22:01 4c98f1c148b0469b crw-r- 1 root operator0, 99 21 ÓÅÎ 22:01 4c98f1c978a6bb52 radius# mdconfig -s 32m md0 radius# newfs -r 4 -U /dev/md0 /dev/md0: 32.0MB (65532 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 8.00MB, 512 blks, 1024 inodes. with soft updates super-block backups (for fsck -b #) at: 160, 16544, 32928, 49312 radius# ll /dev/ufsid/ total 0 crw-r- 1 root operator0, 98 21 ÓÅÎ 22:01 4c98f1c148b0469b crw-r- 1 root operator0, 99 21 ÓÅÎ 22:01 4c98f1c978a6bb52 radius# glabel status Name Status Components ufsid/4c98f1c148b0469b N/A ada2d ufsid/4c98f1c978a6bb52 N/A ada3d Fix: Use attached patch. Patch attached with submission follows: --- /sys/geom/label/g_label_ufs.c.orig 2010-07-11 23:06:52.0 +0400 +++ /sys/geom/label/g_label_ufs.c 2010-09-22 12:21:23.0 +0400 @@ -83,10 +83,10 @@ continue; /* Check for magic and make sure things are the right size */ if (fs-fs_magic == FS_UFS1_MAGIC fs-fs_fsize 0 - pp-mediasize / fs-fs_fsize == fs-fs_old_size) { + pp-mediasize / fs-fs_fsize = fs-fs_old_size) { /* Valid UFS1. */ } else if (fs-fs_magic == FS_UFS2_MAGIC fs-fs_fsize 0 - pp-mediasize / fs-fs_fsize == fs-fs_size) { + pp-mediasize / fs-fs_fsize = fs-fs_size) { /* Valid UFS2. */ } else { g_free(fs); Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
kern/147951: VIMAGE + CARP = kernel crash
Number: 147951 Category: kern Synopsis: VIMAGE + CARP = kernel crash Confidential: no Severity: serious Priority: medium Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Thu Jun 17 20:20:02 UTC 2010 Closed-Date: Last-Modified: Originator: Konstantin Release:8.0 RELEASE, 8.1 BETA 1 Organization: VAENGA telecom Environment: FreeBSD WEB2 8.0-RELEASE FreeBSD 8.0-RELEASE #1: Thu Jun 17 19:38:21 MSD 2010 r...@web2:/usr/obj/usr/src/sys/G-VIMAGE-MR amd64 Description: FreeBSD crashes on carp interface creation. Tested on: - 8.0 RELEASE - 8.1 BETA 1 Full kernel config in attachement. How-To-Repeat: Startup point: clean installation. Add following options to GENERIC kernel: options VIMAGE options ROUTETABLES=16 options DEVICE_POLLING device carp rebuild kernel boot with new kernel ifconfig bge0 10.0.0.1/24 ifconfig carp0 create ifconfig carp0 vhid 4 pass 12345 advbase 1 advskew 20 10.0.0.2/24 kernel crash Fix: Remove following options from kernel config: options VIMAGE Patch attached with submission follows: # # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.531.2.4.2.2 2009/11/09 23:48:01 kensmith Exp $ cpu HAMMER ident GENERIC # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. # Use the following to compile in values accessible to the kernel # through getenv() (or kenv(1) in userland). The format of the file # is 'variable=value', see kenv(1) # # env GENERIC.env #makeoptionsDEBUG=-g# Build kernel with gdb(1) debug symbols options VIMAGE options ROUTETABLES=16 options DEVICE_POLLING # Speedup network options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols # SCTP option is not compatible with options VIMAGE # options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL# Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY# BSD 4.3 TTY compat (sgtty) options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores