makeinfo broken ?
Hi! Of late I'm getting a signal 10 in makeinfo for numerous ports (eg. gcc31, semantic) and other non-port sources. And IIRC have been able to build the gcc31 port six weeks ago without any problems. world and kernel are of yesterday. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === gnu/lib/libobjc === gnu/lib/libg2c === gnu/usr.bin === gnu/usr.bin/bc === gnu/usr.bin/binutils === gnu/usr.bin/binutils/libiberty === gnu/usr.bin/binutils/libbfd cc1: warnings being treated as errors /usr/home/des/tinderbox/sparc64/src/contrib/binutils/bfd/elf-eh-frame.c: In function `_bfd_elf_discard_section_eh_frame': /usr/home/des/tinderbox/sparc64/src/contrib/binutils/bfd/elf-eh-frame.c:417: warning: comparison between signed and unsigned *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/gnu/usr.bin/binutils/libbfd. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/gnu/usr.bin/binutils. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/gnu/usr.bin. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/gnu. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: different packing of structs in kernel vs. userland ?
On Sun, 2002/07/14 at 23:08:21 -0400, Mike Barcroft wrote:
Thomas Moestl [EMAIL PROTECTED] writes:
(Disclaimer: my solution below is untested, so it may all be bogus)
As request, here are the test results.
Most rules work, except my final one:
%%%
bowie# ipfw add allow all from any to any
ipfw: getsockopt(IP_FW_ADD): Invalid argument
%%%
Oh, right, that's related: the kernel checks for a minimum size of the
passed data on two occasions, first in sooptcopyin(), and then again
in check_ipfw_struct().
It the size to be at least sizeof(struct ip_fw), however for
structures containing just one action (like the one for the command
above) this is again too much in the 64-bit case because of the
padding. Can you please try the attached patch (against the CVS
version)?
- thomas
--
Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/
[EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
Index: ip_fw.h
===
RCS file: /home/ncvs/src/sys/netinet/ip_fw.h,v
retrieving revision 1.71
diff -u -r1.71 ip_fw.h
--- ip_fw.h 8 Jul 2002 22:39:19 - 1.71
+++ ip_fw.h 15 Jul 2002 10:48:19 -
@@ -294,8 +294,9 @@
#define ACTION_PTR(rule) \
(ipfw_insn *)( (u_int32_t *)((rule)-cmd) + ((rule)-act_ofs) )
-#define RULESIZE(rule) (sizeof(struct ip_fw) + \
- ((struct ip_fw *)(rule))-cmd_len * 4 - 4)
+#defineRULESIZE_FROMLEN(len) (offsetof(struct ip_fw, cmd) + (len) * 4)
+#defineRULESIZE(rule) RULESIZE_FROMLEN(((struct ip_fw *)(rule))-cmd_len)
+#defineRULESIZE_MINRULESIZE_FROMLEN(1)
/*
* This structure is used as a flow mask and a flow id for various
Index: ip_fw2.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v
retrieving revision 1.4
diff -u -r1.4 ip_fw2.c
--- ip_fw2.c8 Jul 2002 22:46:01 - 1.4
+++ ip_fw2.c15 Jul 2002 10:38:09 -
@@ -2142,7 +2142,7 @@
int have_action=0;
ipfw_insn *cmd;
- if (size sizeof(*rule)) {
+ if (size RULESIZE_MIN) {
printf(ipfw: rule too short\n);
return (EINVAL);
}
@@ -2428,7 +2428,7 @@
case IP_FW_ADD:
rule = (struct ip_fw *)rule_buf; /* XXX do a malloc */
error = sooptcopyin(sopt, rule, sizeof(rule_buf),
- sizeof(struct ip_fw) );
+ RULESIZE_MIN);
size = sopt-sopt_valsize;
if (error || (error = check_ipfw_struct(rule, size)))
break;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: different packing of structs in kernel vs. userland ?
sorry but all this just does not make sense to me.
sizeof(foo) should give the same result irrespective of
where you use it.
Perhaps the best thing would be to put a
printf(struct ip_fw has size %d\n, sizeof(struct ip_fw));
both in ipfw2.c and somewhere in ip_fw2.c and see if there is
a mismatch between the two numbers.
cheers
luigi
On Mon, Jul 15, 2002 at 12:51:58PM +0200, Thomas Moestl wrote:
On Sun, 2002/07/14 at 23:08:21 -0400, Mike Barcroft wrote:
Thomas Moestl [EMAIL PROTECTED] writes:
(Disclaimer: my solution below is untested, so it may all be bogus)
As request, here are the test results.
Most rules work, except my final one:
%%%
bowie# ipfw add allow all from any to any
ipfw: getsockopt(IP_FW_ADD): Invalid argument
%%%
Oh, right, that's related: the kernel checks for a minimum size of the
passed data on two occasions, first in sooptcopyin(), and then again
in check_ipfw_struct().
It the size to be at least sizeof(struct ip_fw), however for
structures containing just one action (like the one for the command
above) this is again too much in the 64-bit case because of the
padding. Can you please try the attached patch (against the CVS
version)?
- thomas
--
Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/
[EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
Index: ip_fw.h
===
RCS file: /home/ncvs/src/sys/netinet/ip_fw.h,v
retrieving revision 1.71
diff -u -r1.71 ip_fw.h
--- ip_fw.h 8 Jul 2002 22:39:19 - 1.71
+++ ip_fw.h 15 Jul 2002 10:48:19 -
@@ -294,8 +294,9 @@
#define ACTION_PTR(rule) \
(ipfw_insn *)( (u_int32_t *)((rule)-cmd) + ((rule)-act_ofs) )
-#define RULESIZE(rule) (sizeof(struct ip_fw) + \
- ((struct ip_fw *)(rule))-cmd_len * 4 - 4)
+#define RULESIZE_FROMLEN(len) (offsetof(struct ip_fw, cmd) + (len) * 4)
+#define RULESIZE(rule) RULESIZE_FROMLEN(((struct ip_fw *)(rule))-cmd_len)
+#define RULESIZE_MINRULESIZE_FROMLEN(1)
/*
* This structure is used as a flow mask and a flow id for various
Index: ip_fw2.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v
retrieving revision 1.4
diff -u -r1.4 ip_fw2.c
--- ip_fw2.c 8 Jul 2002 22:46:01 - 1.4
+++ ip_fw2.c 15 Jul 2002 10:38:09 -
@@ -2142,7 +2142,7 @@
int have_action=0;
ipfw_insn *cmd;
- if (size sizeof(*rule)) {
+ if (size RULESIZE_MIN) {
printf(ipfw: rule too short\n);
return (EINVAL);
}
@@ -2428,7 +2428,7 @@
case IP_FW_ADD:
rule = (struct ip_fw *)rule_buf; /* XXX do a malloc */
error = sooptcopyin(sopt, rule, sizeof(rule_buf),
- sizeof(struct ip_fw) );
+ RULESIZE_MIN);
size = sopt-sopt_valsize;
if (error || (error = check_ipfw_struct(rule, size)))
break;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Please review and commit : Revised rpcgen (1) patch updated
In your mail dated Jul 14, 11:14 you wrote I'm still upset that we don't have tirpc99, when do you plan on porting that over? If you are interested, I have make a full check of NFS/RPC related code in FreeBSD current (June 24), and I have some mods to complete the port of kernel NFS and RPC applcations to TI-RPC and/or IPv6 The modified files are: == libexec/rpc.rquotad/rquotad.c == libexec/rpc.rstatd/rstatd.c == libexec/rpc.rusersd/rusersd.c == libexec/rpc.rwalld/rwalld.c == libexec/rpc.sprayd/sprayd.c == usr.sbin/rpc.statd/statd.c TI/RPC and IPv6 port == usr.bin/rusers/rusers.c == usr.sbin/keyserv/keyserv.c IPv6 port == sbin/mount_nfs/mount_nfs.8 == sbin/mount_nfs/mount_nfs.c == sbin/umount/umount.c == usr.bin/showmount/showmount.c add support of IPv6 litteral of the form [::1]:/mnt == sbin/mountd/exports.5 add IPv6 format information add -network machine_name/prefix support description == sbin/mountd/mountd.c add -network machine_name/prefix support, as IPv6 do not name networks == usr.bin/quota/quota.c TI/RPC and IPv6 port add support of IPv6 litteral of the form [::1]:/mnt == usr.sbin/inetd/inetd.8 add support for rpc IPv6 (rpc/udp46 ...) == usr.sbin/inetd/inetd.c add support for rpc IPv6 (rpc/udp46 ...) correction of bug if service switch between xxx6 and xxx46 == usr.sbin/rpc.lockd/kern.c IPv6 port (must also modify nfsclient/nfs_lock.h) == usr.sbin/rpc.statd/procs.c IPv6 port also correction of bugs which may hangs the daemon on restart (incorrect returned values) == usr.sbin/spray/spray.c correction of a bug (a NULL arg should be ) == sys/netinet6/udp6_usrreq.c Code modification to avoid changing sockaddr stored in kernel Bug correction on reception of non connected IPv6 mapped socket addresses on the same socket == sys/modules/nfsclient/Makefile == sys/modules/nfsserver/Makefile IPv6 port (add opt_inet6.h generation) == sys/nfsclient/nfs_lock.h == sys/nfsclient/nfs_lock.c == sys/nfsclient/nfs_socket.c == sys/nfsserver/nfs.h == sys/nfsserver/nfs_srvcache.c == sys/nfsserver/nfs_srvsock.c == sys/nfsserver/nfs_srvsubs.c == sys/nfsserver/nfs_syscalls.c IPv6 port (nfs diskless mount code has NOT been ported) -- Jean-Luc RICHIER ([EMAIL PROTECTED] [EMAIL PROTECTED]) Laboratoire Logiciels, Systemes et Reseaux (LSR-IMAG) IMAG-CAMPUS, BP 72, F-38402 St Martin d'Heres Cedex Tel : +33 4 76 82 72 32 Fax : +33 4 76 82 72 87 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Please review and commit : Revised rpcgen (1) patch updated
Hi, If you are interested, I have make a full check of NFS/RPC related code in FreeBSD current (June 24), and I have some mods to complete the port of kernel NFS and RPC applcations to TI-RPC and/or IPv6 The modified files are: Of course we are interested ! I knew that many servers did not yet support Ipv6 ! Great that someone has done the work and ported them. Can you make the diffs available publically ? Or do you like to send them just to the lists ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: different packing of structs in kernel vs. userland ?
On Mon, 2002/07/15 at 04:00:08 -0700, Luigi Rizzo wrote: sorry but all this just does not make sense to me. sizeof(foo) should give the same result irrespective of where you use it. OK, let me rephrase it: as I explained before, struct ip_fw has padding after 'cmd' (the last member) to ensure that arrays can be built from it safely, so that the first member will always be properly aligned. Since the first members must/should be aligned on an 8-bit boundary on 64-bit platforms, this means that sizeof(struct ip_fw) must be a multiple of 8, the size of the padding is 4 bytes (unless the situation is changed by reordering structure members). This can easily be checked on a 64-bit platform. The following program fragment: struct ip_fw f; printf(sizeof(ip_fw) = %d\n, (int)sizeof(f)); printf(offsetof(ip_fw, cmd) = %d\n, (int)offsetof(struct ip_fw, cmd)); printf(sizeof(ip_fw.cmd) = %d\n, (int)sizeof(f.cmd)); Produces this output on sparc64: sizeof(ip_fw) = 56 offsetof(ip_fw, cmd) = 48 sizeof(ip_fw.cmd) = 4 This illustrates that indeed, padding is appended after 'cmd'. In the (userland) ipfw2.c, you basically do the following: ipfw_insn *dst; /* sizeof(ipfw_insn) = 4 */ dst = (ipfw_insn *)rule-cmd; /* Write n instructions and increase dst accordingly. */ rule-cmd_len = (u_int32_t *)dst - (u_int32_t *)(rule-cmd); i = (void *)dst - (void *)rule; if (getsockopt(s, IPPROTO_IP, IP_FW_ADD, rule, i) == -1) err(EX_UNAVAILABLE, getsockopt(%s), IP_FW_ADD); Let's consider the case where only one instruction was added. In this case, dst was incremented once and points directly after cmd, so i is 52 on a 64-bit platform. However, sizeof(struct ip_fw) is 56 because the aformentioned 4 bytes of padding following 'cmd', so i sizeof(struct ip_fw). This explains why rules with just one instruction would not work properly in this case with just my first patch. Likewise, when adding more rules, the second one will be added to the memory location directly following 'cmd'. If padding is present, the second instruction will write into it. The size of the total structure will thus not be properly computed by the old RULESIZE macro: #define RULESIZE(rule) (sizeof(struct ip_fw) + \ ((struct ip_fw *)(rule))-cmd_len * 4 - 4) The '- 4' is meant to subtract the size of the cmd, which is accounted for in cmd_len. Still, you are counting the padding twice, once in the sizeof() and once in cmd_len. So, sizeof(struct ip_fw) is no different between userland and kernel, but the problem is that you don't use sizeof(struct ip_fw) in userland to compute the sizes (but pointer arithmetic), but you do use it for the checks in the kernel. - thomas -- Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/ [EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: different packing of structs in kernel vs. userland ?
On Mon, 2002/07/15 at 04:24:33 -0700, Terry Lambert wrote: Luigi Rizzo wrote: sorry but all this just does not make sense to me. sizeof(foo) should give the same result irrespective of where you use it. Perhaps the best thing would be to put a printf(struct ip_fw has size %d\n, sizeof(struct ip_fw)); both in ipfw2.c and somewhere in ip_fw2.c and see if there is a mismatch between the two numbers. I have to assume that what didn't make sense was that his patch worked? 8-). He's making the valid point that for: struct foo *fee; It's possible that: sizeof(struct foo) != (((char *)fee[1]) - ((char *)fee[0])) No, I do not. In fact, the opposite: sizeof(struct foo) = (((char *)fee[1]) - ((char *)fee[0])) _must_ always be true, since it is legal to compute the size of storage needed for an n-element array of struct foo by using (sizeof(struct foo) * n). My point was that, because of the above, any padding that might be required between the first and last member of two struct foo's immediately following each other must be _included_ in struct foo, after the last element. - thomas -- Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/ [EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
bug in awk implementation?
I was parsing ldif format with awk (formerly gawk) and found a buglet in
awk with the following script:
BEGIN {
RS=\n\n;
FS=(: |\n);
}
{ print $2; }
Fed the following output:
dn: Some Such DN
gidNumber: 1000
uidNumber: 1080
dn: Some Other DN
gidNumber: 1000
uidNumber: 1405
This is what I get:
one-true-awk:
Some Such DN
1000
1080
Some Other DN
1000
1405
gawk:
Some Such DN
Some Other DN
So, this seems to be a bug in the one-true-awk implementation. Any ideas
on how to fix this?
-gordon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: bug in awk implementation?
On Mon, Jul 15, 2002 at 08:20:58AM -0700, Gordon Tetlow wrote:
I was parsing ldif format with awk (formerly gawk) and found a buglet in
awk with the following script:
BEGIN {
RS=\n\n;
FS=(: |\n);
}
{ print $2; }
Fed the following output:
dn: Some Such DN
gidNumber: 1000
uidNumber: 1080
dn: Some Other DN
gidNumber: 1000
uidNumber: 1405
This is what I get:
one-true-awk:
Some Such DN
1000
1080
Some Other DN
1000
1405
Ok.
gawk:
Some Such DN
Some Other DN
Oh.
So, this seems to be a bug in the one-true-awk implementation. Any ideas
on how to fix this?
To me, this seems like a bug in 'gawk'. The AWK language uses
only the first character in RS as the record separator, to my
knowledge.
ciao,
-robert
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic at boot in ffs_valloc
Hi. On Wed, Jul 03, 2002 at 09:36:24PM +0200, Rasmus Skaarup wrote: I'm also suddenly having a panics - every 5 minutes actually, since my latest cvsup a few hours ago. They seem to be related to some ufs and ffs calls.. I'm not able to read my core dumps for some reason (gdb says kernel symbol 'cpuhead' not found.) and I don't have the time to scratch a backtrace down by hand just now. The panicstring is: bremfree: bp 0xc77e8670 not locked Sincerely, Rasmus Skaasrup On Wed, 3 Jul 2002, Andrew R. Reiter wrote: :I cvsup'd and built world+kernel a few hours ago and was happy to see :KDE working again, but I got a spontaneous reboot while trying to track :down a segfault in a mozilla build component. I boot -v'ed and as :soon as the login prompt came up I hit a panic. I'm guessing the :backgorund fsck had something to do with it. I'll hand-copy the trace :here; any debugging info needed while my box is stuck at the debugger, :lemme know: I don't have the output to show people since I was trying to reproduce but couldnt, but i got essentially the same panic, but it came only from a syscall to open() that called ufs_create() - ufs_makeinode - ffs_valloc() - panic. I can try and reproduce (tho, mine occured when just running cscope) and get a dump. same here, and I can reproduce the panic by: $ cd /tmp $ for i in `jot 300 1`; do touch $i; done this panics when $i reaches around 128 on my machine. However, the next one doesn't: $ mkdir /tmp/foo $ cd /tmp/foo $ for i in `jot 300 1`; do touch $i; done I have a 256Mbytes of swap-backed /tmp configured in /etc/rc.local as follows: $ cat /etc/rc.local mdmfs -p 1777 -s 256M md0 /tmp According to a post on an anonymous BBS in Japan, malloc-backed /tmp doesn't seem to trigger the panic. Regards. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bug in awk implementation?
On Mon, 15 Jul 2002 09:06:36 -0700 (PDT), Gordon Tetlow [EMAIL PROTECTED] said: Ah, okay, there is a distinct lack of documentation to that fact. I have figured out that I can just set RS= and that does the same thing. I suppose it would be helpful to have an awk book around. =) The Standard is clear: # The first character of the string value of RS shall be the input # record separator; a newline by default. If RS contains more than # one character, the results are unspecified. If RS is null, then # records are separated by sequences consisting of a newline plus # one or more blank lines, leading or trailing blank lines shall not # result in empty records at the beginning or end of the input, and a # newline shall always be a field separator, no matter what the # value of FS is. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: different packing of structs in kernel vs. userland ?
Thomas Moestl [EMAIL PROTECTED] writes: Oh, right, that's related: the kernel checks for a minimum size of the passed data on two occasions, first in sooptcopyin(), and then again in check_ipfw_struct(). It the size to be at least sizeof(struct ip_fw), however for structures containing just one action (like the one for the command above) this is again too much in the 64-bit case because of the padding. Can you please try the attached patch (against the CVS version)? Yes, this version works. %%% bowie# ipfw show 00100 0 0 allow ip from me to 192.168.3.1 00200 5484 allow udp from me to 192.168.3.13 00300 0 0 allow tcp from me to 192.168.3.0/24 established 00400 0 0 deny ip from me to 192.168.3.0/24 00500 9734 allow ip from any to any 65535 0 0 deny ip from any to any %%% Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: different packing of structs in kernel vs. userland ?
Richard Tobin wrote: Er, no, that's not right. Otherwise [ ... ] If everyone could read the text past my example of bad math, so that they could know it was an intentional example of bad math, live would be beautiful. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled
Peter Wemm writes: Eww! Care to confirm that the following works? I was going to just commit it since it is pretty obvious, but a brief sanity check would probably be an idea. (beware, xterm cut/paste whitespace damage). ddb runs with interrupts disabled and the other cpus halted. We could not get the 'ack' from the IPI. The panic was real - you'd have locked up hard if it had not triggered. db_write_bytes temporarily changes a local cpu mapping and changes it back while everything else is frozen. We do not need to do a coherent invalidate. That seems to work. Thanks! Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ast() assert failed ?
On Tue, Jul 16, 2002 at 07:04:46AM +1000, Bruce Evans wrote: Maybe. I got a few of these for my original ast() changes an instant after I committed them (long before KSEIII), but haven't been able to duplicate the problem (perhaps because they only occurred for SMP and I rarely run SMP). I use the following change which prints more info and fixes a spelling error (*blush*). Hey, Isn't this evil ? Jul 15 14:50:09 finfin kernel: failed to set signal flags properly for ast() Jul 15 14:50:09 finfin kernel: proc java sig 0x400, sigmask 0xfffef007, sigflag 0, astflag 0 Jul 15 14:50:09 finfin kernel: failed to set signal flags properly for ast() Jul 15 14:50:09 finfin kernel: proc java sig 0x400, sigmask 0xfffef007, sigflag 0, astflag 0 It's wierd since all of a sudden this showed up and I think I've been using this kernel for quite a while now (pre-pmap changes). No, wierd pmap problems so far... bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ast() assert failed ?
Maybe. I got a few of these for my original ast() changes an instant after I committed them (long before KSEIII), but haven't been able to duplicate the problem (perhaps because they only occurred for SMP and I rarely run SMP). I use the following change which prints more info and fixes a spelling error (*blush*). Bruce, I am reliably get these messages while using gdb on user processes. This started long before KSEIII. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ast() assert failed ?
On Mon, Jul 15, 2002 at 06:00:32PM -0400, Alexander Kabaev wrote: Bruce, I am reliably get these messages while using gdb on user processes. This started long before KSEIII. Right, I forgot to add that I was also running this program under gdb. I'm using the most recent -current right now. bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: bdwrite: buffer is not busy
And another one comes along: GNU gdb 5.2.0 (FreeBSD) 20020627 Copyright 2002 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 i386-undermydesk-freebsd... panic: bdwrite: buffer is not busy panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc2601cf4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc01d9b60 stack pointer = 0x10:0xd1efba7c frame pointer = 0x10:0xd1efba94 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 53252 (smtpd) trap number = 12 panic: page fault syncing disks... panic: bdwrite: buffer is not busy Uptime: 18h49m23s Dumping 256 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- #0 0x in ?? () -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: different packing of structs in kernel vs. userland ?
On Tue, 16 Jul 2002, David Taylor wrote: Bah, ignore me, it appears you've already admitted your post was rather less than clear :) -- David Taylor [EMAIL PROTECTED] The future just ain't what it used to be To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: bdwrite: buffer is not busy
Third one: GNU gdb 5.2.0 (FreeBSD) 20020627 Copyright 2002 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 i386-undermydesk-freebsd... panic: bdwrite: buffer is not busy panic messages: --- panic: bad pte syncing disks... panic: bdwrite: buffer is not busy Uptime: 3h37m11s Dumping 256 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- #0 0x in ?? () Does anyone know what is going on or how I can get some more information out of this dump to track this down? I'd really like to resolve this... -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === usr.sbin/i4b/isdntel === usr.sbin/i4b/isdntelctl === usr.sbin/i4b/isdntest === usr.sbin/i4b/isdntrace === usr.sbin/i4b/man === usr.sbin/boot0cfg === usr.sbin/keyserv === etc === etc/sendmail make: don't know how to make GENERIC. Stop To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
race condition in kern_descrip.c and fix
I found a race condition in kern_descrip.c, the race is in function falloc(),
it opens a race window at line 1147:
FILEDESC_UNLOCK(p-p_fd);
sx_xlock(filelist_lock);
FILEDESC_LOCK(p-p_fd);
fix:
--- kern_descrip.c Tue Jul 16 12:29:44 2002
+++ kern_descrip.c.new Tue Jul 16 12:26:50 2002
-1107,6 +1107,7
register struct file *fp, *fq;
int error, i;
+retry:
sx_xlock(filelist_lock);
if (nfiles = maxfiles) {
sx_xunlock(filelist_lock);
-1151,6 +1152,13
LIST_INSERT_AFTER(fq, fp, f_list);
} else {
LIST_INSERT_HEAD(filehead, fp, f_list);
+ }
+ if (p-p_fd-fd_ofiles[i] != NULL) {
+ fp-f_count = 0;
+ FILEDESC_UNLOCK(p-p_fd);
+ sx_xunlock(filelist_lock);
+ ffree(fp);
+ goto retry;
}
p-p_fd-fd_ofiles[i] = fp;
FILEDESC_UNLOCK(p-p_fd);
---
David Xu
¡Iì¹» ®Þ±éݨ¥¶Ý¢jçH:+éì¹» ®Þ~·nÇ\ººÞا¶¡Ü¨~Ø^ë,j
