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: David Xu To: bug-follo...@freebsd.org, guilla...@morinfr.org Cc: Kostik Belousov , John Baldwin Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Date: Sun, 29 Aug 2010 14:55:32 +0800 Without the previous signal wrapper patch I posted (I am not sure I will use it, because it is too complex), I think there is another way to avoid sigprocmask, I have ever written a system call sc_shared_t*schedctl(void); which returns shared data area between userland and kernel. userland code sets a flag in the data area to disable signal delivering. when kernel code wants to deliver signal, it also checks the flag, and does not deliver signals if the flag is set, then the problem would be fixed: http://people.freebsd.org/~davidxu/schedctl/ ___ 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: ports/150078: security/tor: Recursive dependencies on ports tor and vidalia and weird vidalia default dependencies.
Old Synopsis: Recursive dependencies on ports tor and vidalia and weird vidalia default dependencies. New Synopsis: security/tor: Recursive dependencies on ports tor and vidalia and weird vidalia default dependencies. Responsible-Changed-From-To: freebsd-bugs->freebsd-ports-bugs Responsible-Changed-By: remko Responsible-Changed-When: Sun Aug 29 08:35:52 UTC 2010 Responsible-Changed-Why: Ports thingy http://www.freebsd.org/cgi/query-pr.cgi?pr=150078 ___ 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/150076: ipv6 no longer working on cvsup4.freebsd.org
Synopsis: ipv6 no longer working on cvsup4.freebsd.org State-Changed-From-To: open->closed State-Changed-By: remko State-Changed-When: Sun Aug 29 08:38:50 UTC 2010 State-Changed-Why: Hello, thank you for the report, but sadly we dont include mirror items in our bug database. I forwarded this message to hubs@ which might be a more appropriate location. Thanks for bringing this to the attention and hopefully we can resolve this as soon as possible. http://www.freebsd.org/cgi/query-pr.cgi?pr=150076 ___ 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/125325: Annoying grep(1) bug with --color
The following reply was made to PR bin/125325; it has been noted by GNATS. From: Alexander Best To: bug-follo...@freebsd.org Cc: Subject: Re: bin/125325: Annoying grep(1) bug with --color Date: Sun, 29 Aug 2010 09:51:22 + it would be interesting to see how the new BSD licensed grep handles this case. -- a13x ___ 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/125325: Annoying grep(1) bug with --color
The following reply was made to PR bin/125325; it has been noted by GNATS. From: Alexander Best To: bug-follo...@freebsd.org Cc: Subject: Re: bin/125325: Annoying grep(1) bug with --color Date: Sun, 29 Aug 2010 10:07:16 + ok just checked. GNU grep and BSD grep behave exactly the same in this case. :) cheers. alex -- a13x ___ 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/121550: [drm] Can't config graphics for ATI Radeon Xpress 200M
Synopsis: [drm] Can't config graphics for ATI Radeon Xpress 200M State-Changed-From-To: feedback->closed State-Changed-By: vwe State-Changed-When: Sun Aug 29 10:08:49 UTC 2010 State-Changed-Why: with r187021 support for the device has been brought into 7-STABLE http://www.freebsd.org/cgi/query-pr.cgi?pr=121550 ___ 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/144411: [patch] mtree(8) doesn't reject non-regular files for -X
On Tue, Mar 30, 2010 at 5:40 PM, Garrett Cooper wrote: > On Tue, Mar 30, 2010 at 12:12 PM, Bruce Evans wrote: >> On Wed, 31 Mar 2010, Bruce Evans wrote: >> >>> On Tue, 30 Mar 2010, Garrett Cooper wrote: >>> Hi, I'm not 100% satisfied with this patch now. Looking back it fails the following case: -P Do not follow symbolic links in the file hierarchy, instead con- sider the symbolic link itself in any comparisons. This is the default. >>> >>> -P should have the same semantics and description in all utilities. The >>> description should not have grammar errors like the above (comma splice). >>> ... >>> I now see that the grammar error is from the original version of mtree(1), >>> and is probably one of the things you don't like. mtree also has -L, but >>> not -R or -P or -h. It is not clear how any utility that traverses trees >>> can work without a full complement of -[HLPR] or how any utility that >>> ... >> >> Looking at the actual patch, I now see that it is about a completely >> different problem. You would only need to understand the amount of >> brokenness of -P to see if you need to use lstat(). I think -P is so >> broken that mtree on symlinks doesn't work at all and not using lstat() >> would be safest. > > Hmmm... so I take it that this is actually the first step in many to > fixing this underlying problem? I suppose I should be opening bugs for > all of the itemized issues that you see in mtree(8) so someone can > submit patches to fix the utility? > >> The patch has some style bugs. > > Please expound on this -- I want to improve my style (without having > to rewrite the entire program of course) -- so that it conforms more > to the projects overall style rules; of course there are some cases > where I can't readily do that (like pkg_install -- ugh), but I'll do > my best to make sure that the rules are withheld. Just for the record, here's the latest patch that I submitted to Bruce for this PR. Thanks, -Garrett bin.45529.2.diff Description: Binary data ___ 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/144411: [patch] mtree(8) doesn't reject non-regular files for -X
On Sun, Aug 29, 2010 at 3:54 AM, Garrett Cooper wrote:
> On Tue, Mar 30, 2010 at 5:40 PM, Garrett Cooper wrote:
>> On Tue, Mar 30, 2010 at 12:12 PM, Bruce Evans wrote:
>>> On Wed, 31 Mar 2010, Bruce Evans wrote:
>>>
On Tue, 30 Mar 2010, Garrett Cooper wrote:
> Hi,
> I'm not 100% satisfied with this patch now. Looking back it fails
> the following case:
>
> -P Do not follow symbolic links in the file hierarchy, instead
> con-
> sider the symbolic link itself in any comparisons. This is the
> default.
-P should have the same semantics and description in all utilities. The
description should not have grammar errors like the above (comma splice).
...
I now see that the grammar error is from the original version of mtree(1),
and is probably one of the things you don't like. mtree also has -L, but
not -R or -P or -h. It is not clear how any utility that traverses trees
can work without a full complement of -[HLPR] or how any utility that
...
>>>
>>> Looking at the actual patch, I now see that it is about a completely
>>> different problem. You would only need to understand the amount of
>>> brokenness of -P to see if you need to use lstat(). I think -P is so
>>> broken that mtree on symlinks doesn't work at all and not using lstat()
>>> would be safest.
>>
>> Hmmm... so I take it that this is actually the first step in many to
>> fixing this underlying problem? I suppose I should be opening bugs for
>> all of the itemized issues that you see in mtree(8) so someone can
>> submit patches to fix the utility?
>>
>>> The patch has some style bugs.
>>
>> Please expound on this -- I want to improve my style (without having
>> to rewrite the entire program of course) -- so that it conforms more
>> to the projects overall style rules; of course there are some cases
>> where I can't readily do that (like pkg_install -- ugh), but I'll do
>> my best to make sure that the rules are withheld.
>
> Just for the record, here's the latest patch that I submitted to
> Bruce for this PR.
Dog gone it; attached the wrong patch. This is the right patch..
-Garrett
Index: excludes.c
===
--- excludes.c (revision 211961)
+++ excludes.c (working copy)
@@ -30,9 +30,10 @@
#include
__FBSDID("$FreeBSD$");
+#include
+#include
+#include /* XXX for mtree.h */
#include
-#include /* XXX for mtree.h */
-#include
#include
#include
@@ -63,11 +64,18 @@
void
read_excludes_file(const char *name)
{
+ struct stat exclude_stat;
+ struct exclude *e;
FILE *fp;
char *line, *str;
- struct exclude *e;
size_t len;
+ /* Make sure that `name' points to a real file. */
+ if (stat(name, &exclude_stat) != 0)
+ err(EXIT_FAILURE, "stat: %s", name);
+ if (!S_ISREG(exclude_stat.st_mode))
+ errx(EXIT_FAILURE, "invalid exclude file: %s", name);
+
fp = fopen(name, "r");
if (fp == 0)
err(1, "%s", name);
___
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: Kostik Belousov To: David Xu Cc: bug-follo...@freebsd.org, guilla...@morinfr.org, John Baldwin Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Date: Sun, 29 Aug 2010 14:57:56 +0300 --siH5g6X9/kbebbtM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 29, 2010 at 02:55:32PM +0800, David Xu wrote: > Without the previous signal wrapper patch I posted (I am not sure > I will use it, because it is too complex), I think there is another way > to avoid sigprocmask, I have ever written a system call >=20 > sc_shared_t *schedctl(void); >=20 >=20 > which returns shared data area between userland and kernel. > userland code sets a flag in the data area to disable signal delivering. > when kernel code wants to deliver signal, it also checks the flag, and > does not deliver signals if the flag is set, then the problem would be=20 > fixed: > http://people.freebsd.org/~davidxu/schedctl/ >=20 I only skimmed over the (incomplete) change. It seems it has issues with rfork(). In particular, when shared vm space between two processes becomes forked. Also, it is not clear to me what would happen if the shared page paged out or user mode explicitely unmap(2) the shared region. At least the kernel mapping should be invalidated, otherwise kernel might modify random memory. I do not like the idea of using additional non-observable state bits, in addition to the signal mask, to block the signal delivery. IMHO, it subverts the signal mechanism, and, in case of memory corruption, makes debugging too hard. --siH5g6X9/kbebbtM Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkx6S0QACgkQC3+MBN1Mb4iR0ACgvk00JTKvHNa01CmoJCJCeT+D 8F8An0rCa1Z3ZbLlLgi1UC8ICZCxczv0 =LWTr -END PGP SIGNATURE- --siH5g6X9/kbebbtM-- ___ 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/143029: [libc] poll(2) can return too large a number
Synopsis: [libc] poll(2) can return too large a number Responsible-Changed-From-To: freebsd-bugs->kib Responsible-Changed-By: vwe Responsible-Changed-When: Sun Aug 29 12:06:38 UTC 2010 Responsible-Changed-Why: over kib for MFC reminder http://www.freebsd.org/cgi/query-pr.cgi?pr=143029 ___ 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/86485: [patch] hexdump(1): hexdump -s speedup on /dev
Synopsis: [patch] hexdump(1): hexdump -s speedup on /dev State-Changed-From-To: open->analyzed State-Changed-By: arundel State-Changed-When: Sun Aug 29 12:01:55 UTC 2010 State-Changed-Why: The cause for this issue is the use of getchar() which tests every character against EOF. This causes huge overhead as can be seen in this comparison between the BSD and Linux hexdump versions: FreeBSD:Linux: real 44,85 real 0.00 user 4,51 user 0.00 sys 38,76 sys 0.00 The command used for this was 'time -p hexdump -n 100 -s 10 /dev/random'. Higher values for -s would simply take too much time on FreeBSD. ;) Responsible-Changed-From-To: freebsd-bugs->arundel Responsible-Changed-By: arundel Responsible-Changed-When: Sun Aug 29 12:01:55 UTC 2010 Responsible-Changed-Why: Assign to me. Although i don't have commit rights to src i'm working on this issue atm. http://www.freebsd.org/cgi/query-pr.cgi?pr=86485 ___ 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: conf/123516: [periodic] Daily Security Logs Not Reporting Failed Logins
Synopsis: [periodic] Daily Security Logs Not Reporting Failed Logins State-Changed-From-To: open->closed State-Changed-By: vwe State-Changed-When: Sun Aug 29 12:45:52 UTC 2010 State-Changed-Why: fixed by r180111, thank you for your report http://www.freebsd.org/cgi/query-pr.cgi?pr=123516 ___ 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/149948: [panic] when starting net/ladvd
Old Synopsis: Panic when starting ladvd New Synopsis: [panic] when starting net/ladvd State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Sun Aug 29 13:26:03 UTC 2010 State-Changed-Why: Vladislav, w/o a backtrace or any other information, it's quite hard to tell where the problem might come from. Your screenshot suggests, there's a NULL pointer causing the trouble. Can you please try at first the following command and post us it's output: addr2line -e /boot/kernel/kernel.symbols 0x806aa114 If your kernel config is near GENERIC, the problem might be in sys/net80211/ieee80211_node.c:2328 Having a backtrace would make things simpler. If you're brave enough, you may try to get the kernel dump onto a usb thumb drive (I'm using this for embedded machines, where I don't have the space to store dumps). It works find, just take a look at dumpon(8). If you got a dump, please use the kernel debugger to get the backtrace. http://www.freebsd.org/cgi/query-pr.cgi?pr=149948 ___ 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/149464: [libc] [rtld] dlclose(3) can access freed memory and crash
Synopsis: [libc] [rtld] dlclose(3) can access freed memory and crash Responsible-Changed-From-To: freebsd-bugs->secteam Responsible-Changed-By: remko Responsible-Changed-When: Sun Aug 29 14:12:34 UTC 2010 Responsible-Changed-Why: For review / check to secteam http://www.freebsd.org/cgi/query-pr.cgi?pr=149464 ___ 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/143568: ktrace(1) is limited with other user's "filesize" limit
Synopsis: ktrace(1) is limited with other user's "filesize" limit Responsible-Changed-From-To: freebsd-bugs->secteam Responsible-Changed-By: remko Responsible-Changed-When: Sun Aug 29 14:13:06 UTC 2010 Responsible-Changed-Why: For review / check to sectaem http://www.freebsd.org/cgi/query-pr.cgi?pr=143568 ___ 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/149412: bdes(1) in CFB/OFB modes can't decrypt own output
Synopsis: bdes(1) in CFB/OFB modes can't decrypt own output Responsible-Changed-From-To: freebsd-bugs->secteam Responsible-Changed-By: remko Responsible-Changed-When: Sun Aug 29 14:13:37 UTC 2010 Responsible-Changed-Why: For review/check to secteam http://www.freebsd.org/cgi/query-pr.cgi?pr=149412 ___ 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/146541: [patch] add check option to md5(1)
Synopsis: [patch] add check option to md5(1) Responsible-Changed-From-To: freebsd-bugs->sectaem Responsible-Changed-By: remko Responsible-Changed-When: Sun Aug 29 14:13:57 UTC 2010 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=146541 ___ 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/149948: [panic] when starting net/ladvd
# addr2line -e /boot/kernel/kernel.symbols 0x806aa114 /usr/src/sys/amd64/amd64/support.S:101 The server is in the data center, there is IPMI-KVM, but then through him to connect usb-flash - do not understand ... My kernel: cpu HAMMER device acpi device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapist # ATAPI tape drives device ataraid # ATA RAID drives device atkbd # AT keyboard device atkbdc # AT keyboard controller device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device bpf # Berkeley packet filter device cd # CD device cdce# Generic USB over Ethernet device ch # SCSI media changers device cpufreq device cue # CATC USB Ethernet device da # Direct Access (disks) device ehci# EHCI PCI->USB interface (USB 2.0) device em # Intel PRO/1000 Gigabit Ethernet Family device ether # Ethernet support device firmware# firmware assist module device fxp # Intel EtherExpress PRO/100B (82557, 82558) device igb # Intel PRO/1000 PCIE Server Gigabit Family device kbdmux # keyboard multiplexer device kue # Kawasaki LSI USB Ethernet device loop# Network loopback device lpt # Printer device md # Memory "disks" device miibus # MII bus support device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device ohci# OHCI PCI->USB interface device pass# Passthrough device (direct SCSI access) device pci device plip# TCP/IP over parallel device ppbus # Parallel port bus (required) device ppc device ppi # Parallel port interface device device psm # PS/2 mouse device pty # BSD-style compatibility pseudo ttys device random # Entropy device device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device rue # RealTek RTL8150 USB Ethernet device sa # Sequential Access (tape etc) device sc device scbus # SCSI bus (required for SCSI) device ses # SCSI Environmental Services (and SAF-TE) device splash # Splash screen and screen saver support device tun # Packet tunnel. device twe # 3ware ATA RAID device uark# Technologies ARK3116 based serial adapters device uart# Generic UART driver device ubsa# Belkin F5U103 and compatible serial adapters device udav# Davicom DM9601E USB device uftdi # For FTDI usb serial adapters device uhci# UHCI PCI->USB interface device uhid# "Human Interface Devices" device uipaq # Some WinCE based devices device ukbd# Keyboard device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device uplcom # Prolific PL-2303 serial adapters device usb # USB Bus (required) device uslcom # SI Labs CP2101/CP2102 serial adapters device uvscom # USB serial support for DDI pocket's PHS device vga # VGA video card driver device carp#Common Address Redundancy Protocol device disc device enc # IPsec interface. device faith #for IPv6 and IPv4 translation device gif #IPv6 and IPv4 tunneling device gre #IP over IP tunneling device if_bridge #Bridge interface device ksyms device lagg#Link aggregation interface device mem device pf #PF OpenBSD packet-filter firewall device pflog #logging support interface for PF device pfsync #synchronization interface for PF device stf #6to4 IPv6 over IPv4 encapsulation device tap #Virtual Ethernet driver device vlan#VLAN support (needs miibus) ident second-nextonmarket makeoptions
Re: kern/149948: [panic] when starting net/ladvd
On 08/29/10 16:29, Vladislav V. Prodan wrote: # addr2line -e /boot/kernel/kernel.symbols 0x806aa114 /usr/src/sys/amd64/amd64/support.S:101 The server is in the data center, there is IPMI-KVM, but then through him to connect usb-flash - do not understand ... Vladislav, please forgive me being stupid. I should have seen in my crystal ball that you're unable to access your usb ports. Anyway, I'm unable to crash my machine (just tested): # uname -a FreeBSD leto.sz.vwsoft.com 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r211914: Sat Aug 28 14:54:58 UTC 2010 vwe...@leto.sz.vwsoft.com:/usr/obj/usr/src/sys/GENERIC amd64 with net/ladvd just a few minutes installed before. ladvd doesn't run but it doesn't crash my machine. Still, we need a backtrace. You may want to make sure, your kernel sources and ports tree are up to date. Volker ___ 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/149948: [panic] when starting net/ladvd
I provoked a kernel panic on another machine. panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Cannot access memory at address 0xff019de0 (kgdb) #0 0x in ?? () Cannot access memory at address 0x0 (kgdb) 29.08.2010 16:33, v...@freebsd.org wrote: > Old Synopsis: Panic when starting ladvd > New Synopsis: [panic] when starting net/ladvd > > State-Changed-From-To: open->feedback > State-Changed-By: vwe > State-Changed-When: Sun Aug 29 13:26:03 UTC 2010 > State-Changed-Why: > Vladislav, > w/o a backtrace or any other information, it's quite hard to tell where > the problem might come from. > > Your screenshot suggests, there's a NULL pointer causing the trouble. > > Can you please try at first the following command and post us it's output: > addr2line -e /boot/kernel/kernel.symbols 0x806aa114 > > If your kernel config is near GENERIC, the problem might be in > sys/net80211/ieee80211_node.c:2328 > > Having a backtrace would make things simpler. If you're brave enough, you > may try to get the kernel dump onto a usb thumb drive (I'm using this for > embedded machines, where I don't have the space to store dumps). > It works find, just take a look at dumpon(8). > > If you got a dump, please use the kernel debugger to get the backtrace. > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=149948 > > > ___ 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/150089: Assertion failed: (errorcode == 0), function MutexImpl, file llvm/lib/System/Mutex.cpp, line 76. Abort trap (core dumped)
>Number: 150089 >Category: misc >Synopsis: Assertion failed: (errorcode == 0), function MutexImpl, file >llvm/lib/System/Mutex.cpp, line 76. Abort trap (core dumped) >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Aug 29 16:40:01 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Piotr >Release:FreeBSD 7.0-RELEASE >Organization: >Environment: # uname -a FreeBSD bsd.net 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 r...@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >Description: I've installed [B]havp-0.91_1 [/B] from ports on my freeBSD 7.0 Release and I'm getting this error: /usr/local/etc/rc.d # ./havp start added: not found Starting havp. [B]Assertion failed: (errorcode == 0), function MutexImpl, file llvm/lib/System/Mutex.cpp, line 76. Abort trap (core dumped)[/B] /usr/local/etc/rc.d # ./clamav-clamd start added: not found Starting clamav_clamd. LibClamAV Warning: *** LibClamAV Warning: *** This version of the ClamAV engine is outdated. *** LibClamAV Warning: *** DON'T PANIC! Read [url]http://www.clamav.net/support/faq[/url] *** LibClamAV Warning: *** LibClamAV Warning: *** LibClamAV Warning: *** This version of the ClamAV engine is outdated. *** LibClamAV Warning: *** DON'T PANIC! Read [url]http://www.clamav.net/support/faq[/url] *** LibClamAV Warning: *** >How-To-Repeat: install havp-0.91_1 from ports on freeBSD 7.0 Release >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"
Re: misc/147479: [patch] [calendar] Dan Moschuk has passed away
Synopsis: [patch] [calendar] Dan Moschuk has passed away Responsible-Changed-From-To: freebsd-bugs->core Responsible-Changed-By: imp Responsible-Changed-When: Sun Aug 29 10:49:47 MDT 2010 Responsible-Changed-Why: Core will take care of the cleanup here. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=147479 ___ 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/149948: [panic] when starting net/ladvd
These options were already in the kernel: options KDB makeoptions DEBUG=-g I added a few more: optionsINVARIANTS optionsINVARIANT_SUPPORT optionsWITNESS optionsWITNESS_SKIPSPIN And after the service ladvd onestart got hung system. Helped only reset the computer, coredump is not created. Aug 29 20:04:58 mary-teresa vlad11: /usr/local/etc/rc.d/ladvd: DEBUG: checkyesno: ladvd_enable is set to YES. Aug 29 20:04:58 mary-teresa vlad11: /usr/local/etc/rc.d/ladvd: DEBUG: run_rc_command: start_precmd: ladvd_check Aug 29 20:04:58 mary-teresa vlad11: /usr/local/etc/rc.d/ladvd: DEBUG: run_rc_command: doit: /usr/local/sbin/ladvd -a Aug 29 20:04:58 mary-teresa snmpd[3520]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa last message repeated 2 times Aug 29 20:04:58 mary-teresa snmpd[4612]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa last message repeated 3 times Aug 29 20:04:58 mary-teresa last message repeated 3 times Aug 29 20:04:58 mary-teresa snmpd[3520]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[4612]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[3520]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[4612]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[3520]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[3520]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[4612]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[4612]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[3520]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[4612]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[3520]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[4612]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[3520]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[3520]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[4612]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[3520]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[3520]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[4612]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[3520]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[4612]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[3520]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[4612]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa kernel: Aug 29 20:04:58 mary-teresa kernel: Aug 29 20:04:58 mary-teresa kernel: Fatal trap 12: page fault while in kernel mode Aug 29 20:04:58 mary-teresa kernel: cpuid = 1; apic id = 01 Aug 29 20:04:58 mary-teresa kernel: fault virtual address = 0x0 Aug 29 20:04:58 mary-teresa kernel: fault code = supervisor read data, page not present Aug 29 20:04:58 mary-teresa kernel: instruction pointer = 0x20:0x806850d4 Aug 29 20:04:58 mary-teresa kernel: stack pointer = 0x28:0xff804b057940 Aug 29 20:04:58 mary-teresa kernel: frame pointer = 0x28:0xff804b0579e0 Aug 29 20:04:58 mary-teresa snmpd[3520]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[4612]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa snmpd[4612]: RTM_NEWMADDR for unknown interface 0 Aug 29 20:04:58 mary-teresa kernel: Aug 29 20:04:58 mary-teresa kernel: code segment= base What else can I do to give more information on this error? 29.08.2010 18:29, Vladislav V. Prodan wrote: > I provoked a kernel panic on another machine. > > panic: page fault > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > Cannot access memory at address 0xff019de0 > (kgdb) #0 0x in ?? () > Cannot access memory at address 0x0 > (kgdb) > > > > 29.08.2010 16:33, v...@freebsd.org wrote: >> Old Synopsis: Panic when starting ladvd >> New Synopsis: [panic] when starting net/ladvd >> >> State-Changed-From-To: open->feedback >> State-Changed-By: vwe >> State-Changed-When: Sun Aug 29 13:26:03 UTC 2010 >> State-Changed-Why: >> Vladislav, >> w/o a backtrace or any other information, it's quite hard to tell where >> the problem might come from. >> >> Your screenshot suggests, there's a NULL pointer causing the trouble. >> >> Can you please t
Re: kern/149980: [patch] negative value integer to nanosleep(2) should fail with EINVAL
Old Synopsis: [PATCH] negative value integer to nanosleep(2) should fail with EINVAL New Synopsis: [patch] negative value integer to nanosleep(2) should fail with EINVAL State-Changed-From-To: open->analyzed State-Changed-By: vwe State-Changed-When: Sun Aug 29 20:00:22 UTC 2010 State-Changed-Why: double checked that and it's looking reasonable I think the checks for 'tv_nsec < 0' and 'tv_sec < 0' can be made in one go, but IMO it should not make a difference (assembler wise): Index: sys/kern/kern_time.c === --- sys/kern/kern_time.c(revision 211522) +++ sys/kern/kern_time.c(working copy) @@ -362,9 +362,9 @@ struct timeval tv; int error; - if (rqt->tv_nsec < 0 || rqt->tv_nsec >= 10) + if (rqt->tv_nsec < 0 || rqt->tv_nsec >= 10 || rqt->tv_sec < 0) return (EINVAL); - if (rqt->tv_sec < 0 || (rqt->tv_sec == 0 && rqt->tv_nsec == 0)) + if (rqt->tv_sec == 0 && rqt->tv_nsec == 0) return (0); getnanouptime(&ts); timespecadd(&ts, rqt); http://www.freebsd.org/cgi/query-pr.cgi?pr=149980 ___ 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/149980: [patch] negative value integer to nanosleep(2) should fail with EINVAL
The following reply was made to PR kern/149980; it has been noted by GNATS. From: Garrett Cooper To: v...@freebsd.org Cc: bug-followup Subject: Re: kern/149980: [patch] negative value integer to nanosleep(2) should fail with EINVAL Date: Sun, 29 Aug 2010 13:16:04 -0700 On Sun, Aug 29, 2010 at 1:03 PM, wrote: > Old Synopsis: [PATCH] negative value integer to nanosleep(2) should fail = with EINVAL > New Synopsis: [patch] negative value integer to nanosleep(2) should fail = with EINVAL > > State-Changed-From-To: open->analyzed > State-Changed-By: vwe > State-Changed-When: Sun Aug 29 20:00:22 UTC 2010 > State-Changed-Why: > double checked that and it's looking reasonable > I think the checks for 'tv_nsec < 0' and 'tv_sec < 0' can be made in one = go, > but IMO it should not make a difference (assembler wise): > > Index: sys/kern/kern_time.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/kern/kern_time.c =A0 =A0 =A0 =A0(revision 211522) > +++ sys/kern/kern_time.c =A0 =A0 =A0 =A0(working copy) > @@ -362,9 +362,9 @@ > =A0 =A0 =A0 =A0struct timeval tv; > =A0 =A0 =A0 =A0int error; > > - =A0 =A0 =A0 if (rqt->tv_nsec < 0 || rqt->tv_nsec >=3D 10) > + =A0 =A0 =A0 if (rqt->tv_nsec < 0 || rqt->tv_nsec >=3D 10 || rqt= ->tv_sec < 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (EINVAL); > - =A0 =A0 =A0 if (rqt->tv_sec < 0 || (rqt->tv_sec =3D=3D 0 && rqt->tv_nse= c =3D=3D 0)) > + =A0 =A0 =A0 if (rqt->tv_sec =3D=3D 0 && rqt->tv_nsec =3D=3D 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); > =A0 =A0 =A0 =A0getnanouptime(&ts); > =A0 =A0 =A0 =A0timespecadd(&ts, rqt); Same thing that bde@ asked me to create, so it naturally looks good :). The reason why I hadn't posted anything earlier about this bug is that bde@ brought it to my attention that there are additional issues with the timer code, mostly dealing with the fact that itimerfix isn't used when checking the bounds of the tv argument. There are other associated issues with using this though (itimerfix checks tv_msec, and nanosleep doesn't check the tv_msec field because nanosleep uses nanosecond granularity, not millisecond granularity). Thanks! -Garrett ___ 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/149980: [patch] negative value integer to nanosleep(2) should fail with EINVAL
The following reply was made to PR kern/149980; it has been noted by GNATS. From: Garrett Cooper To: Garrett Cooper Cc: v...@freebsd.org, bug-followup Subject: Re: kern/149980: [patch] negative value integer to nanosleep(2) should fail with EINVAL Date: Sun, 29 Aug 2010 13:17:44 -0700 On Sun, Aug 29, 2010 at 1:16 PM, Garrett Cooper wrote= : > On Sun, Aug 29, 2010 at 1:03 PM, =A0 wrote: >> Old Synopsis: [PATCH] negative value integer to nanosleep(2) should fail= with EINVAL >> New Synopsis: [patch] negative value integer to nanosleep(2) should fail= with EINVAL >> >> State-Changed-From-To: open->analyzed >> State-Changed-By: vwe >> State-Changed-When: Sun Aug 29 20:00:22 UTC 2010 >> State-Changed-Why: >> double checked that and it's looking reasonable >> I think the checks for 'tv_nsec < 0' and 'tv_sec < 0' can be made in one= go, >> but IMO it should not make a difference (assembler wise): >> >> Index: sys/kern/kern_time.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- sys/kern/kern_time.c =A0 =A0 =A0 =A0(revision 211522) >> +++ sys/kern/kern_time.c =A0 =A0 =A0 =A0(working copy) >> @@ -362,9 +362,9 @@ >> =A0 =A0 =A0 =A0struct timeval tv; >> =A0 =A0 =A0 =A0int error; >> >> - =A0 =A0 =A0 if (rqt->tv_nsec < 0 || rqt->tv_nsec >=3D 10) >> + =A0 =A0 =A0 if (rqt->tv_nsec < 0 || rqt->tv_nsec >=3D 10 || rq= t->tv_sec < 0) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (EINVAL); >> - =A0 =A0 =A0 if (rqt->tv_sec < 0 || (rqt->tv_sec =3D=3D 0 && rqt->tv_ns= ec =3D=3D 0)) >> + =A0 =A0 =A0 if (rqt->tv_sec =3D=3D 0 && rqt->tv_nsec =3D=3D 0) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); >> =A0 =A0 =A0 =A0getnanouptime(&ts); >> =A0 =A0 =A0 =A0timespecadd(&ts, rqt); > > Same thing that bde@ asked me to create, so it naturally looks good :). > > The reason why I hadn't posted anything earlier about this bug is that > bde@ brought it to my attention that there are additional issues with > the timer code, mostly dealing with the fact that itimerfix isn't used > when checking the bounds of the tv argument. There are other > associated issues with using this though (itimerfix checks tv_msec, > and nanosleep doesn't check the tv_msec field because nanosleep uses > nanosecond granularity, not millisecond granularity). One other thing that I failed to mention. itimerfix is used as a one-size fit-all solution in a lot of of pieces of code, s.t. it would affect other items like select(2), etc. -Garrett ___ 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/149969: [wlan] [ral] ralink rt2661 fails to maintain connection
Synopsis: [wlan] [ral] ralink rt2661 fails to maintain connection State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Sun Aug 29 20:27:52 UTC 2010 State-Changed-Why: David, does the device work for your if you disable powersave operation? Please note: For your IRQ question, the asterisk in the output indicates more devices being assigned to that IRQ but vmstat -i is unable to display all. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Sun Aug 29 20:27:52 UTC 2010 Responsible-Changed-Why: over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=149969 ___ 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/150095: [patch] Account for reserved itimers which shouldn't count against _SC_TIMER_MAX
>Number: 150095
>Category: kern
>Synopsis: [patch] Account for reserved itimers which shouldn't count
>against _SC_TIMER_MAX
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sun Aug 29 22:00:04 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Garrett Cooper
>Release:9-CURRENT
>Organization:
Cisco Systems, Inc.
>Environment:
FreeBSD orangebox.local 9.0-CURRENT FreeBSD 9.0-CURRENT #10 r211794M: Sun Aug
29 21:21:29 UTC 2010 gcoo...@orangebox.local:/usr/obj/usr/src/sys/ORANGEBOX
amd64
>Description:
Currently 3 reserve itimers are allocated purely for kernel use, but
unfortunately this breaks the SUSv4 requirement which states:
{TIMER_MAX}
Maximum number of timers per process supported by the implementation.
Minimum Acceptable Value: {_POSIX_TIMER_MAX}
..
{_POSIX_TIMER_MAX}
The per-process number of timers.
Value: 32
Example (from testcases/open_posix_testsuite/conformance/behavior/timers in the
LTP package):
$ ./1-1.run-test
[29] timer_create() did not return success: Resource temporarily unavailable
After applying this patch, things function as expected:
$ ./1-1.run-test
Test PASSED
>How-To-Repeat:
1. Grab LTP: the package needs to be July or later as I didn't apply many fixes
to the branch until post that date -- this may require grabbing the source from
git. See the sourceforge page for more info (http://sf.net/projects/ltp). Use
ltp/ltp-dev instead of ltp/ltp in the directions, if ltp-dev.git still exists
(I'm working on fixing that, because the directions on the webpage are
incorrect).
2. Go to the open_posix_testsuite directory: cd
$LTP_DIR/testcases/open_posix_testsuite
3. Generate the Makefiles: make generate-makefiles
4. Build the test: cd conformance/behavior/timers; make
5. Execute the test like: ./1-1.run-test
>Fix:
Patch attached with submission follows:
Index: sys/kern/kern_time.c
===
--- sys/kern/kern_time.c(revision 211794)
+++ sys/kern/kern_time.c(working copy)
@@ -356,9 +356,9 @@
struct timeval tv;
int error;
- if (rqt->tv_nsec < 0 || rqt->tv_nsec >= 10)
+ if (rqt->tv_sec < 0 || (rqt->tv_nsec < 0 || rqt->tv_nsec >= 10))
return (EINVAL);
- if (rqt->tv_sec < 0 || (rqt->tv_sec == 0 && rqt->tv_nsec == 0))
+ if (rqt->tv_sec == 0 && rqt->tv_nsec == 0)
return (0);
getnanouptime(&ts);
timespecadd(&ts, rqt);
@@ -995,7 +995,8 @@
PROC_LOCK(p);
if (preset_id != -1) {
- KASSERT(preset_id >= 0 && preset_id < 3, ("invalid preset_id"));
+ KASSERT(preset_id >= 0 && preset_id < TIMER_RESERVED,
+ ("invalid preset_id"));
id = preset_id;
if (p->p_itimers->its_timers[id] != NULL) {
PROC_UNLOCK(p);
@@ -1007,10 +1008,11 @@
* Find a free timer slot, skipping those reserved
* for setitimer().
*/
- for (id = 3; id < TIMER_MAX; id++)
+ for (id = TIMER_RESERVED; id < (TIMER_RESERVED + TIMER_MAX);
+ id++)
if (p->p_itimers->its_timers[id] == NULL)
break;
- if (id == TIMER_MAX) {
+ if (id == (TIMER_RESERVED + TIMER_MAX)) {
PROC_UNLOCK(p);
error = EAGAIN;
goto out;
@@ -1144,7 +1146,7 @@
ovalp = NULL;
PROC_LOCK(p);
- if (uap->timerid < 3 ||
+ if (uap->timerid < TIMER_RESERVED ||
(it = itimer_find(p, uap->timerid)) == NULL) {
PROC_UNLOCK(p);
error = EINVAL;
@@ -1176,7 +1178,7 @@
int error;
PROC_LOCK(p);
- if (uap->timerid < 3 ||
+ if (uap->timerid < TIMER_RESERVED ||
(it = itimer_find(p, uap->timerid)) == NULL) {
PROC_UNLOCK(p);
error = EINVAL;
@@ -1206,7 +1208,7 @@
int error ;
PROC_LOCK(p);
- if (uap->timerid < 3 ||
+ if (uap->timerid < TIMER_RESERVED ||
(it = itimer_find(p, uap->timerid)) == NULL) {
PROC_UNLOCK(p);
error = EINVAL;
@@ -1483,7 +1485,7 @@
* by new image.
*/
if (event == ITIMER_EV_EXEC)
- i = 3;
+ i = TIMER_RESERVED;
else if (event == ITIMER_EV_EXIT)
i = 0;
else
Index: sys/sys/timers.h
===
--- sys/sys/timers.h(revision 211794)
+++ sys/sys/timers.h(wor
Re: kern/150095: [patch] Account for reserved itimers which shouldn't count against _SC_TIMER_MAX
The following reply was made to PR kern/150095; it has been noted by GNATS. From: Garrett Cooper To: bug-follo...@freebsd.org, gcoo...@freebsd.org Cc: Subject: Re: kern/150095: [patch] Account for reserved itimers which shouldn't count against _SC_TIMER_MAX Date: Sun, 29 Aug 2010 15:17:44 -0700 --001636c5b05f914ff5048efdb74b Content-Type: text/plain; charset=ISO-8859-1 Sorry... some noise from nanosleep was in the last patch (another bug I filed -- kern/149980). This patch only deals with the items I described. Thanks, -Garrett --001636c5b05f914ff5048efdb74b Content-Type: text/plain; charset=US-ASCII; name="account-for-reserved-itimers.diff.txt" Content-Disposition: attachment; filename="account-for-reserved-itimers.diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gdggn4j40 SW5kZXg6IHN5cy9rZXJuL2tlcm5fdGltZS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9rZXJuL2tlcm5f dGltZS5jCShyZXZpc2lvbiAyMTE3OTQpCisrKyBzeXMva2Vybi9rZXJuX3RpbWUuYwkod29ya2lu ZyBjb3B5KQpAQCAtOTk1LDcgKzk5NSw4IEBACiAKIAlQUk9DX0xPQ0socCk7CiAJaWYgKHByZXNl dF9pZCAhPSAtMSkgewotCQlLQVNTRVJUKHByZXNldF9pZCA+PSAwICYmIHByZXNldF9pZCA8IDMs ICgiaW52YWxpZCBwcmVzZXRfaWQiKSk7CisJCUtBU1NFUlQocHJlc2V0X2lkID49IDAgJiYgcHJl c2V0X2lkIDwgVElNRVJfUkVTRVJWRUQsCisJCSAgICAoImludmFsaWQgcHJlc2V0X2lkIikpOwog CQlpZCA9IHByZXNldF9pZDsKIAkJaWYgKHAtPnBfaXRpbWVycy0+aXRzX3RpbWVyc1tpZF0gIT0g TlVMTCkgewogCQkJUFJPQ19VTkxPQ0socCk7CkBAIC0xMDA3LDEwICsxMDA4LDExIEBACiAJCSAq IEZpbmQgYSBmcmVlIHRpbWVyIHNsb3QsIHNraXBwaW5nIHRob3NlIHJlc2VydmVkCiAJCSAqIGZv ciBzZXRpdGltZXIoKS4KIAkJICovCi0JCWZvciAoaWQgPSAzOyBpZCA8IFRJTUVSX01BWDsgaWQr KykKKwkJZm9yIChpZCA9IFRJTUVSX1JFU0VSVkVEOyBpZCA8IChUSU1FUl9SRVNFUlZFRCArIFRJ TUVSX01BWCk7CisJCSAgICBpZCsrKQogCQkJaWYgKHAtPnBfaXRpbWVycy0+aXRzX3RpbWVyc1tp ZF0gPT0gTlVMTCkKIAkJCQlicmVhazsKLQkJaWYgKGlkID09IFRJTUVSX01BWCkgeworCQlpZiAo aWQgPT0gKFRJTUVSX1JFU0VSVkVEICsgVElNRVJfTUFYKSkgewogCQkJUFJPQ19VTkxPQ0socCk7 CiAJCQllcnJvciA9IEVBR0FJTjsKIAkJCWdvdG8gb3V0OwpAQCAtMTE0NCw3ICsxMTQ2LDcgQEAK IAkJb3ZhbHAgPSBOVUxMOwogCiAJUFJPQ19MT0NLKHApOwotCWlmICh1YXAtPnRpbWVyaWQgPCAz IHx8CisJaWYgKHVhcC0+dGltZXJpZCA8IFRJTUVSX1JFU0VSVkVEIHx8CiAJICAgIChpdCA9IGl0 aW1lcl9maW5kKHAsIHVhcC0+dGltZXJpZCkpID09IE5VTEwpIHsKIAkJUFJPQ19VTkxPQ0socCk7 CiAJCWVycm9yID0gRUlOVkFMOwpAQCAtMTE3Niw3ICsxMTc4LDcgQEAKIAlpbnQgZXJyb3I7CiAK IAlQUk9DX0xPQ0socCk7Ci0JaWYgKHVhcC0+dGltZXJpZCA8IDMgfHwKKwlpZiAodWFwLT50aW1l cmlkIDwgVElNRVJfUkVTRVJWRUQgfHwKIAkgICAoaXQgPSBpdGltZXJfZmluZChwLCB1YXAtPnRp bWVyaWQpKSA9PSBOVUxMKSB7CiAJCVBST0NfVU5MT0NLKHApOwogCQllcnJvciA9IEVJTlZBTDsK QEAgLTEyMDYsNyArMTIwOCw3IEBACiAJaW50IGVycm9yIDsKIAogCVBST0NfTE9DSyhwKTsKLQlp ZiAodWFwLT50aW1lcmlkIDwgMyB8fAorCWlmICh1YXAtPnRpbWVyaWQgPCBUSU1FUl9SRVNFUlZF RCB8fAogCSAgICAoaXQgPSBpdGltZXJfZmluZChwLCB1YXAtPnRpbWVyaWQpKSA9PSBOVUxMKSB7 CiAJCVBST0NfVU5MT0NLKHApOwogCQllcnJvciA9IEVJTlZBTDsKQEAgLTE0ODMsNyArMTQ4NSw3 IEBACiAJCSAqIGJ5IG5ldyBpbWFnZS4KIAkJICovCiAJCWlmIChldmVudCA9PSBJVElNRVJfRVZf RVhFQykKLQkJCWkgPSAzOworCQkJaSA9IFRJTUVSX1JFU0VSVkVEOwogCQllbHNlIGlmIChldmVu dCA9PSBJVElNRVJfRVZfRVhJVCkKIAkJCWkgPSAwOwogCQllbHNlCkluZGV4OiBzeXMvc3lzL3Rp bWVycy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9zeXMvdGltZXJzLmgJKHJldmlzaW9uIDIxMTc5NCkK KysrIHN5cy9zeXMvdGltZXJzLmgJKHdvcmtpbmcgY29weSkKQEAgLTgzLDYgKzgzLDggQEAKIAog I2RlZmluZQlJVENGX09OV09SS0xJU1QJMHgwMQogCisvKiBDbG9ja3MgcmVzZXJ2ZWQgYnkgc2V0 aXRpbWVyICovCisjZGVmaW5lIFRJTUVSX1JFU0VSVkVECTMKICNkZWZpbmUJVElNRVJfTUFYCTMy CiAKICNkZWZpbmUJSVRJTUVSX0xPQ0soaXQpCQltdHhfbG9jaygmKGl0KS0+aXRfbXR4KQpAQCAt OTQsNyArOTYsNyBAQAogCXN0cnVjdCBpdGltZXJsaXN0CWl0c192aXJ0dWFsOwogCXN0cnVjdCBp dGltZXJsaXN0CWl0c19wcm9mOwogCVRBSUxRX0hFQUQoLCBpdGltZXIpCWl0c193b3JrbGlzdDsK LQlzdHJ1Y3QgaXRpbWVyCQkqaXRzX3RpbWVyc1tUSU1FUl9NQVhdOworCXN0cnVjdCBpdGltZXIJ CSppdHNfdGltZXJzW1RJTUVSX1JFU0VSVkVEICsgVElNRVJfTUFYXTsKIH07CiAKIHN0cnVjdAlr Y2xvY2sgewo= --001636c5b05f914ff5048efdb74b-- ___ 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/150098: Jail names
>Number: 150098 >Category: misc >Synopsis: Jail names >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Sun Aug 29 22:40:03 UTC 2010 >Closed-Date: >Last-Modified: >Originator: cc >Release:8.0 Release >Organization: >Environment: >Description: It should be mentioned in the Handbook http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html and the man pages http://www.freebsd.org/cgi/man.cgi?query=jail&apropos=0&sektion=0&manpath=FreeBSD+8.1-RELEASE&format=html that jail names should contain only numbers or letters. Special characters and punctuation will confuse the parser. >How-To-Repeat: Try to create a jail with the name, for instance, jail-bird or jail_bird. The initialization file rc.conf will produce error messages at boot time. >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"
Re: kern/149948: [panic] when starting net/ladvd
The following reply was made to PR kern/149948; it has been noted by GNATS. From: Maxim Konovalov To: univers...@ukr.net Cc: bug-follo...@freebsd.org Subject: Re: kern/149948: [panic] when starting net/ladvd Date: Mon, 30 Aug 2010 09:29:08 +0400 (MSD) Hello, please try a patch in kern/149807: http://www.freebsd.org/cgi/query-pr.cgi?pr=149807&cat= and report me back the results. Thanks! -- Maxim Konovalov ___ 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"
