Re: Flash (was: Re: Sound card support)
Good luck using it under current. First site you hit quits netscape without reasons... ...until you drop out of X and see a __sh_getcontext IIRC warning on your console. If you can hack on the flash plugin's Makefile, try add -fno-exceptions there. Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel: -mpreferred-stack-boundary=2 ??
Bruce Evans wrote: I would have expected the most generally efficient way to align doubles and the new PIII obkects to be aligning the stack only in functions that have such objects on the stack. This requires at most one extra instruction: andl $~0xf,$esp 16-byte alignment I think, it's not that simple in the usual case when the object is accessed via (%ebp-someconstant). Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
Maybe I can at least commit the addition of "volatile" to the source code. That will work around that particular bug until egcs is fixed... FWIW, the newly committed gcc-2.95.2 doesn't "fix" the problem. Are you sure? GCC-2.95.2 seems OK here. Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A call to squease more bytes from `boot2'
Try "-mpreferred-stack-boundary=2". Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious locking problem in CURRENT
Brian Fundakowski Feldman wrote: There were zero comments about what order things happen in; in fact, the ordering in this case is Just Plain Lame (TM). It's much more correct to explicitly check for fp-f_count == 1. Not sure what you mean. The commit clearly states that POSIX and BSD locking intentionally handled in different ways here. Frankly, I see nothing lame in the ordering. The second VOP_ADVLOCK just should be moved to fdrop(). BTW, I have another little concern with that commit: It make possible for last close() of a file descriptor to return 0 instead of the error from VOP_CLOSE(), and the error from VOP_CLOSE() to be ignored. When a process do closef() on a descriptor "held" by another process (by fhold(), e.g. the process do read() on the descriptor), it will just return 0 without the call to fo_close(). Then, when the other process drop the descriptor, fdrop() call fo_close() but the error is thrown away. No? Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freefall hangs w/ nfs
Matthew Dillon wrote: Actually, what I meant was that AMD itself is equivalent to a loopback mount, whether or not you make loopback mounts through it. No. The loopback deadlock happen when the nfs server handle a write operation. But there cannot be any writes in the amd filesystem. The filesystem only contains symlinks to outside. Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: {a}sync updates (was Re: make install trick)
"David Schwartz" wrote: We're talking about the special case of small root partitions, such that softupdates inability to make empty space available quickly can make the difference between a major operation's success or failure. This is almost impossible on a 1.8Gb root partition. [sorry, cannot resist...] real-life story Once upon a time, a month or so ago, there were ~30G of free space on our 130G filesystem (with softupdates). An important application that was going to create a ~35G file was running. It already written out 1G or so. My colleague called me and sayed: "I removed a 10G of files TWO HOURS ago and the space didn't free up yet!!! The free space isn't going to appear!!! What do we do now???" Well, after I stopped the application with kill -STOP, and temporary killed off another I/O consuming program, the free space started to appear and after several minutes there were 40G of free space. /real-life story I think that the problem in this particular case was inability of the syncer to run as fast as it supposed to. It is assummed that syncer fsync 1/30 of all files and process the softupdates worklist every second. If there are several I/O bound processes running, the syncer will not have enough I/O bandwidth to do this job in the required speed. Perhaps running several syncer processes could help. (OTOH, the machine in question is running a quite old version of FreeBSD-CURRENT, it is possible things are already better. I don't see serious changes in softupdates code from that moment, tough. It is also possible that the machine is mistuned in some way, but I don't know how :-() Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wierd message
Kenneth Culver wrote: what does this message mean? Sep 24 18:34:04 culverk /kernel: arpresolve: can't allocate llinfo for 127.0.0.1rt I don't know how you got it, but here is an easy way to do so: In /etc/rc.conf: network_interfaces="ed0 lo0" ifconfig_ed0="DHCP" (ed0 apparently can be replaced with any other NIC) Then run amd. (I don't know why amd is the first program I tried that trigger it.) The workaround (fix?) is to put lo0 before ed0. But sysinstall put network interfaces in this order :-(. I have seen this when I recently installed 3.3-RELEASE on a new machine. As I ssuspect, this is because DHCP do something like route add -host yout ip 127.0.0.1 before lo0 is ifconfiged. Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ccd build failure
"Matthew D. Fuller" wrote: OK: #!/bin/sh (cvs status | grep '^File:' | grep -v 'Status: Up-to-date$') 2 /dev/null Excuse me, I apparently completely missed the idea, but what is wrong with cvs -qn up ? Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: (P)review: sigset_t for more than 32 signals
typedef struct {
unsigned int n;
uint64_t v;
} sigset_t;
You can't use any BSD or FreeBSD specific types (such as u_int32)t) in
publicly visible types (such as sigset_t). It breaks programs because it's
not ANSI and/or Posix.
You can use internal names like __uint32_t from machine/ansi.h for. They
are in the implementation namespace.
Dima
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Perl still broken in 4.0-CURRENT
Pascal Hofstee wrote: Hi, Perl seems to be broken for about 3 consecutive days now Anybody have any idea what might be causing this ? I suspect it is the recent changes in rtld. Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFSv3 on freebsd--solaris
The client system -- A FreeBSD client system - has a buffer cache. The buffer cache holds an abstraction for both files and directories. Well, the discussion is about FreeBSD NFS server, not about FreeBSD NFS client. Neither FreeBSD server cannot assume FreeBSD client, nor FreeBSD client can assume FreeBSD server. The NFS server is a simple thing that just do what the client requested, for example read the directory. Bugs in the FreeBSD NFS client is completely different story. Our NFS implementation on the client caches the NFS directory via the buffer cache. It translates the cookies returned by the server to a block number and offset as cached in the client's buffer cache. See nfs_readdirrpc() in sys/nfs/nfs_vnops.c This creates a directory-block abstraction on the client. The 'cookies' the client returns to processes are based on this abstraction and do not match the cookies returned by the server. The problem that we have is that our buffer cache abstraction essentially fits a variable number of directory entries returned from the server. If a file is created or deleted on the server, our buffer cache abstraction gets thrown for a loop. The client _cannot_ depend on that if a file is created or removed on the server, the "bad cookie" error is returned in next readdir. RFC1813 does not require it in any way. In order to maintain consistency within the set of cached pages (note: I'm not talking about cache coherency with the server here, just consistency within the buffer cache on the client), our buffer cache abstraction is currently dependant on the verifier key changing on the server. I don't why it was done this way -- perhaps mtime was found to not be sufficient. Maybe because it doesn't have sufficient resolution under NFSv2. Under NFSv3 it should theoretically have sufficient resolution but how many servers do you know keep the nanoseconds field updated? I don't believe in it. First of all, NFSv2 has no verifiers, and work reasonably well. (There is a belief that NFSv2 is much more reliable than NFSv3, you know.) Then, invalidation of cached data is heavily depended on mtime anyway. The client don't do readdir RPC if it think that its cache is valid, it only verify the mtime. Finally, -current has a debugging printf in "bad cookie" handling code for about 4 months, and noone complain that his logs filled with the message. I think I now understand why the "bad cookie" handling code don't do the right thing. Removing files in the directory effectively shift its content to the left. So, if you read the directory and remove files in the same time, you will miss some entries. When applied to files, the use of mtime to determine when to flush the cache is nothing more then an inconvenience. But the use of mtime to determine when to flush a directory cache can be fatal. I still don't see why. If you want to change the way our directory verifier works, you have to completely rewrite the directory caching code for the client. I think you can argue that the verifier is not being implemented properly, but I'm not going to let anyone change it unless the directory caching code on the client is rewritten at the same time to use the server's cookies directly. Really? Right now the server's cookies are only used by the client to demark client-buffer-cache buffer boundries. The actual cookies returned to the *process* running on the client are translated from the client's buffer cache abstraction of the NFS directory. The change that would have to be made would be for the server's cookies to be passed through all the way to the process sitting on the client rather then translated in the buffer cache. Then cache consistency in our client would then not be as sensitive to the varying amounts of information the server sends us and we could safely leave the verifier alone on the server. This would require us to change the abstraction our client uses significantly -- it would not longer be able to use the cookies passed to it by the user process as direct offsets into the client's buffer cache. Hmm. I don't think such a big changes in the directory caching is necessary at all, though I didn't actually think about it. Anyway, the verifiers only add to the breakage (see above). Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFSv3 on freebsd--solaris
[sorry for some delay...] Doug Rabson wrote: I think we should not ever reject a client's cookie. Consider a local program that scan the directoty with the getdirentries() syscall. The offset in the directory is essentially the cookie that would be sent to an NFS client. But we never "reject" the offset, and everyone is happy. (Not to mention NFSv2, where we never reject a client's cookie too). So, what we are trying to achieve by rejecting a NFSv3 client's cookie? Notify the client that the directory contents may have been compacted and therefore that their seek offsets are now wrong. You apparently missed my above paragraph. Do we notify a local process about such a condition? Then, what is so special about compacting? What if I quickly moved out a directory content and replaced it with something completely different? How you can recover after it? With rm -r, the recovery is easy, but how the recovery will work if the program is, say, du? From rfc1813: If the server detects that the cookie is no longer valid, the server will reject the READDIR request with the status, NFS3ERR_BAD_COOKIE. I propose that our cookies are always valid, just like directory offsets after getdirentries() syscall (on a local filesystems). The client should be careful to avoid holding directory entry cookies across operations that modify the directory contents, such as REMOVE and CREATE. It seems to me that the solaris client is holding directory cookies across a REMOVE operation and therefore should expect to get stale cookie errors occaisionally. Yes. FreeBSD programs typically use fts(3), which read whole directory before return its content to the application. That is, the rule is honored. But this solution is in the userland. Our NFS client used to have the same problem (a long time ago) and I put code into it to re-read the directory if its cookies are stale. (According to a mail recently sent to -hackers, that doesn't work. In -current, the recovery code has a debugging printf(), so I guess the code only triggered in very rare cases (see above).) Anyway, I don't actually care what is correct NFS client behavior. I am saying that sending "bad cookie" error is not useful for FreeBSD sever. Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newfs of a ccd failing?
I've had this problem since at least FreeBSD 3.1-RELEASE (it works in 2.2.7/2.2.8). Same problem in 3.2-RELEASE and -current (as of last night). Can someone reproduce this error? I can't believe that you can't newfs a ccd... did I miss something? I always see the error message last months, but it is harmless in practice - the filesystem is OK, the ccd is ready to use. newfs: ioctl (WDINFO): No such process newfs: /dev/rccd0c: can't rewrite disk label Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Thread stack allocation (was Re: cvs commit: src/lib/libc_r Makefile src/lib/libc_r/uthread pthread_private.h uthread_create.c uthread_gc.c uthread_init.c)
On Mon, 12 Jul 1999, Dmitrij Tejblum wrote: Alan Cox wrote: When you create a stack or grow an existing stack, the minimum chunk size is 128K. This make use of "growable" stacks in libc_r particulary useful, given that libc_r make "growable" only 64K stacks. That is a problem, to be sure. In order to make effective use of growable stacks, each stack really needs to be at least 256KB. However, Alan also pointed out that growable stacks are a bit of a non-feature, since the VM is lazy about backing mapped regions. In light of this, I'm leaning toward using MAP_ANON instead of MAP_STACK. I don't see how MAP_ANON is better than MAP_STACK. These changes create other troubles. For example, they limit the size of the initial thread to 1M, and this is too little and not tunable. Making the initial stack size tunable at runtime would require a non-standard interface. How big is big enough? I picked 1MB rather randomly; increasing the value is quite easy. One possible solution would be to pay at least some heed to the value of getrlimit(RLIMIT_STACK, ..). Well, why you map stacks on fixed address, and in the process stack? I think, you could map it at random address. (And mprotect the red zone). Another problem with the changes I made was also pointed out by Alan. Each stack is a separate region, and with the red zones, there end up being two regions for every stack. This apparently has a direct impact on page table lookups. Somehow, the stack allocation code needs to be more economical in this regard, but I haven't thought of a slick method yet. Anyway, what are the advantages of mmap over malloc? Especially if you change MAP_STACK to MAP_ANON? Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
Louis A. Mamakos wrote: Before documenting it, how about we fix it's name to be more accurate to newcomers: net.inet.tcp.always_makedead, etc. There's no part of this (in many cases misguided) mechanism that keeps anything alive. I disagree. I use keepalive exactly to keep my connections (mostly ssh sessions) alive. The sysadmin of our corporate LAN made our router drop all connections idle for 15 minutes or so. As I understand, the router send fake RST packets. The sysadmin believe that it increase security. I tried to convince him to not do it, I tried to kill him, but didn't succeed. So, now I set net.inet.tcp.keepidle to a really low value, and it keeps my connections alive! Dima To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kvm_getswapinfo is broken
Andrey A. Chernov wrote: Just check 'swapinfo' in recent -current, it shows /dev/(null) as swap device, it means that devinfo() call in kvm_getswapinfo() returns NULL, i.e. called with wrong argument which is swinfo.sw_dev This is a known problem. It is because dev_t in kernel and dev_t and userland are now different things. This is worse on the alpha, where they also have different sizes. So, on the alpha, the numbers are broken too, not just device names. Supposedly, it will be fixed by a junior kernel hacker. Dima To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: calcru and upages
Peter Wemm wrote: Bruce Evans wrote: calcru() access p_stats, which is in upages. Therefore, as I understand, it should not be called on a swapped out process. Neither calcru() nor Does anyone object to moving everything except the stack from the upages to the proc table? This would certainly make my sleep better. However, IMO the real problem here is the hackish way the VM maintain upages. It is not so hard to make such incorrect accesses to u-area detected better. I used this: --- vm_glue.c Thu May 20 00:24:18 1999 +++ vm_glue.c Thu May 20 00:27:33 1999 @@ -317,6 +317,9 @@ faultin(p) setrunqueue(p); p-p_flag |= P_INMEM; + p-p_stats = p-p_addr-u_stats; + if (p-p_sigacts == NULL) + p-p_sigacts = p-p_addr-u_sigacts; /* undo the effect of setting SLOCK above */ --p-p_lock; @@ -516,6 +519,9 @@ swapout(p) (void) splhigh(); p-p_flag = ~P_INMEM; p-p_flag |= P_SWAPPING; + p-p_stats = NULL; + if (p-p_sigacts == p-p_addr-u_sigacts) + p-p_sigacts = NULL; if (p-p_stat == SRUN) remrq(p); (void) spl0(); Probably better idea would be pass MAP_NOFAULT in a non-currently-existent argument to kmem_alloc_pageable() in pmap_new_proc(). Well, we have three things that are about the same size: struct pcb u_pcb;240 bytes struct sigacts u_sigacts;292 bytes struct pstats u_stats; 248 bytes On the other hand: sizeof (struct proc) = 328 bytes. the pcb contains a heap of space for the FP state. It accounts for 176 of the 240 bytes, leaving 64-odd bytes left for the pcb proper. The ldt pointers need to move to proc scope for rfork()/clone(), and gc'ing a few things that can get it as low as 40 - 48 bytes. pcb_savefpu has padding in case a FPU emulator is used and is actually smaller than 176 bytes, and could be changed depending on whether it's a real or emulated fpu. I guess, this is bit different on alpha ;-). IMHO, I'd move them to reference counted malloc'ed structs since sigacts needs to be shared for clone/rforked processes. I think sigacts is already sometimes shared, and not stored in u-area in these cases. I think there is also benefit to having the sigacts at least malloced, one day we should be able to extend the signals beyond the existing 32 set, at least for the 32 extra RT signals. Isn't this an argument for keep them in upages? When the struct is larger, you want to swap it out stronger? I personally would love to see this come out of the upages, it makes tracking through a stack overflow even harder. We could put an unmapped red-line page below the bottom stack page to ensure we get a double fault on an overflow instead of mystery corruptions etc. Why not move 'struct user' on top of the upages, above the kernel stack? Sayed all that, I don't actually suggest to keep struct user. I almost hate it. Dima To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
calcru and upages
calcru() access p_stats, which is in upages. Therefore, as I understand, it should not be called on a swapped out process. Neither calcru() nor its callers seem to ensure this. At least the call in procfs_dostatus() may happen on a swapped out process. (It test for P_INMEM for another access to p_stats several lines before :-/) Dima To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Berkeley DB 1.85 -- 2.0
Andrey A. Chernov wrote: On Fri, May 14, 1999 at 11:15:35AM -0400, John R. LoVerso wrote: Of course, DB 2 is still available as an easily installed port/package. Not so easily, it conflict with libc's DB in subtle but harmful manner. Only if it is configured with --enable-compat185. Just Don't Do That. (Yep, the port do it, and for this reason I consider it broken). Dima To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: make world croaks in perl ??
Yup, this is supposed to fix the problem, that I introduced a day before. The problem was 'make -jN'-depended. Sorry for the inconvinience. BTW, I hope there will be no 'Your makefile has been rebuilt' failures anymore. Dima Steve Kargl wrote: It doesn't fix it here, but dt committed a fix to a Makefile in the Perl tree. This might actually fix the problem. I'm rebuilding now to see. Poul-Henning Kamp wrote: Hmm, double make cleandir fixed it. Could a conveniently located perl wizard try to figure out what this is tripping over and fix the build ? In message 9459.926593...@critter.freebsd.dk, Poul-Henning Kamp writes: Is anybody but me seeing this ? === gnu/usr.bin/perl === gnu/usr.bin/perl/libperl === gnu/usr.bin/perl/miniperl sh config_h.sh Extracting config.h (with variable substitutions) cc -nostdinc -O -pipe -I/usr/src/gnu/usr.bin/perl/miniperl/../../../../contrib/p erl5 -I/usr/obj/usr/src/gnu/usr.bin/perl/miniperl -I/usr/obj/usr/src/tmp/usr/i nclude -c /usr/src/gnu/usr.bin/perl/miniperl/../../../../contrib/perl5/miniperlm ain.c cc -nostdinc -O -pipe -I/usr/src/gnu/usr.bin/perl/miniperl/../../../../contrib/p erl5 -I/usr/obj/usr/src/gnu/usr.bin/perl/miniperl -I/usr/obj/usr/src/tmp/usr/i nclude -static -o miniperl miniperlmain.o -lperl -lm -lcrypt === gnu/usr.bin/perl/perl make: don't know how to make writemain.sh. Stop *** Error code 2 -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: SPAM
Jonathan M. Bresler wrote: with volunteers, we could moderate the list(s). mail transfer would be slower as we wait for the moderator(s) to approve each piece of email. if we use more than one moderator per list, the time-sequence of email would be lostwe would get some very strange threads...could be enteraining. Have you ever considered only allowing list members to post, or are there difficulties that make this impossible? I suggest following approach: moderate only mail that lack the mailing list name in To: or Cc: headers. It is far from ideal, but I think would work reasonably well. Dima To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: msdosfs problems?
Alex Zepeda wrote: panic: vm_page_bits: illegal base/size 4096/2048 The panic is hopefully just fixed in vnode_pager.c rev.1.107. I didn't quite understand if you have other msdosfs problems. Dima To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Simple DOS against 3.x locks box solid
Matthew Dillon wrote:
We'll get a quick fix committed but the lockmgr stuff needs a real
going-over... having interrupts using the general lockmgr call is
a disaster waiting to happen.
Hmmm. After I looked a bit further, it looks like a bug in the
scheduler (?). Here is the stack trace:
#9 0xc01ff64e in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 0,
tf_esi = 16777216, tf_ebp = -999002708, tf_isp = -999002744,
tf_ebx = -1071228500, tf_edx = -2, tf_ecx = 0, tf_eax = 0,
tf_trapno = 12, tf_err = 0, tf_eip = -1072584332, tf_cs = 8,
tf_eflags = 66050, tf_esp = -999002524, tf_ss = -1071228500})
at ../../i386/i386/trap.c:438
#10 0xc011a974 in lockmgr (lkp=0xc02659ac, flags=1, interlkp=0x0, p=0x0)
at ../../kern/kern_lock.c:217
#11 0xc01d8c5b in vm_map_lookup (var_map=0xc4746e64, vaddr=3294351360,
fault_typea=1 '\001', out_entry=0xc4746e68, object=0xc4746e5c,
pindex=0xc4746e60, out_prot=0xc4746e4b ю\a, wired=0xc4746e44)
at ../../vm/vm_map.c:2463
#12 0xc01d4153 in vm_fault (map=0xc02659ac, vaddr=3294351360,
fault_type=1 '\001', fault_flags=0) at ../../vm/vm_fault.c:197
#13 0xc01ff9ac in trap_pfault (frame=0xc4746f18, usermode=0, eva=3294351360)
at ../../i386/i386/trap.c:825
#14 0xc01ff64e in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 46137344,
tf_esi = -1071149988, tf_ebp = -999002244, tf_isp = -999002304,
tf_ebx = 18341888, tf_edx = -1000615936, tf_ecx = -1005747008,
tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071650796, tf_cs = 8,
tf_eflags = 65606, tf_esp = -1072552121, tf_ss = -999654400})
at ../../i386/i386/trap.c:438
#15 0xc01fe814 in swtch_com ()
#16 0xc01ff859 in trap (frame={tf_es = 47, tf_ds = 47, tf_edi = 20,
tf_esi = 136019608, tf_ebp = -1077948228, tf_isp = -999002156,
tf_ebx = 307, tf_edx = 136220264, tf_ecx = 136630944,
tf_eax = 135716928, tf_trapno = 7, tf_err = 0, tf_eip = 134536416,
tf_cs = 31, tf_eflags = 514, tf_esp = -1077948244, tf_ss = 47})
at ../../i386/i386/trap.c:195
#17 0xc01f5aa3 in swi_ast_user ()
the trap in swtch_com() (frame #15) is here:
/* switch address space */ - line 622
movl%cr3,%ebx
cmplPCB_CR3(%edx),%ebx - trap
je 4f
I don't think this line is supposed to cause a trap...
Dima
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Simple DOS against 3.x locks box solid
Matthew Dillon wrote:
- error = acquire(lkp, extflags,
- LK_HAVE_EXCL | LK_WANT_EXCL | LK_WANT_UPGRADE);
+ if (p-p_flag P_DEADLKTREAT) {
+ error = acquire(
This is broken: p may be NULL, it is checked several lines before.
My kernel just paniced for this reason.
Well, sorry for late response, but: what was wrong with Tor Egge's
workaround from kern/8416?
Dima
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: tail /proc/map/*
Bruce Evans wrote:
tail(1) assumes that mmap(2) works on works on regular files. mmap(2) on
the irregular regular files /proc/*/map returns success but doesn't work.
IMO, it ought to work. There should be no reason why regular files on
procfs are more irregular than regular files on NFS.
The first access to the mmapped memory usually causes the kernel to
printf messages like the following:
vnode_pager: *** WARNING *** stale FS getpages
(Still no such messages here. I still don't run the Terry's submission
that just introduced the message and spread a lot of same trivial
getpages/putpages routines over the kernel... I hope to clean out all
this junk some day, (when everyone will finally forget that matter ;-)
The message is not quite relevant to the problem, though.)
No strategy for buffer at 0xf12828e8
: 0xf3877800: type VREG, usecount 4, writecount 0, refcount 0, flags (VOBJBUF)
tag VT_PROCFS, type 11, pid 591, mode 124, flags 0
: 0xf3877800: type VREG, usecount 4, writecount 0, refcount 0, flags (VOBJBUF)
tag VT_PROCFS, type 11, pid 591, mode 124, flags 0
vnode_pager_getpages: I/O read error
That is because procfs define a bogus BMAP operation, but don't define
a STRATEGY operation. The BMAP operation apparently only useful to
break mmap(2).
After the BMAP code removed, another procfs bugs become apparent.
procfs claim that /proc/*/map files are all sizeof(struct regs)( == 76) bytes
length (:-|), but don't allow read only 76 bytes from the 'map' file.
It confuse the vm code that conver mmap to read, but it also may
confuse other things. If I change the size of the 'map' file to something
larger, tail /proc/*/map output something quite reasonable.
I think procfs_domap should do what requested, and should not try to
guarantee atomicity, as now: anyhow, any file may change it content
between reads, not just under procfs. Also, procfs could compute 'map'
file size more accurately.
Apparently, such a mmap implementation has coherency problems. But I
don't think that they are more difficult to solve (or more serious)
than in NFS case.
Dima
P.S. This is the changes that allow me to see a reasonable good result
from 'tail /proc/*/map'.
--- procfs_vnops.c Sun Feb 28 15:33:52 1999
+++ procfs_vnops.c Sun Feb 28 17:29:22 1999
@@ -560,6 +560,12 @@
case Ptype:
case Pmap:
+ vap-va_bytes = vap-va_size = 4096;
+ vap-va_nlink = 1;
+ vap-va_uid = procp-p_ucred-cr_uid;
+ vap-va_gid = procp-p_ucred-cr_gid;
+ break;
+
case Pregs:
vap-va_bytes = vap-va_size = sizeof(struct reg);
vap-va_nlink = 1;
@@ -982,7 +988,7 @@
{ vop_abortop_desc,(vop_t *) procfs_abortop },
{ vop_access_desc, (vop_t *) procfs_access },
{ vop_advlock_desc,(vop_t *) procfs_badop },
- { vop_bmap_desc, (vop_t *) procfs_bmap },
+ /*{ vop_bmap_desc, (vop_t *) procfs_bmap },*/
{ vop_close_desc, (vop_t *) procfs_close },
{ vop_create_desc, (vop_t *) procfs_badop },
{ vop_getattr_desc,(vop_t *) procfs_getattr },
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
Jos Backus wrote: On Tue, Feb 23, 1999 at 02:41:14AM +0300, Dmitrij Tejblum wrote: Jos Backus wrote: This occurs almost immediately after copying a file to an msdos fs. I can provide more info if that is deemed useful. I suspect your kernel compiled with INVARIANTS, Yes, and with INVARIANTS_SUPPORT as well as per Matt's instructions. you load msdosfs module dynamically, and the module isn't compiled with INVARIANTS. This is after a successful world and subsequent kernel build. If so, don't do that. I'm not aware that I do, really. jos:/usr/src/sys/modules/msdos# grep INVARIANTS * jos:/usr/src/sys/modules/msdos# jos:/usr/src/sys/msdosfs# grep INVARIANTS * jos:/usr/src/sys/msdosfs# Inline functions in vm/vm_zone.h depend on INVARIANTS. These functions used in msdosfs and in other parts of the kernel. How does one add INVARIANTS support to modules? You could add -DINVARIANTS to CFLAGS in sys/module/msdosfs/Makefile. You better just link msdosfs statically, or remove INVARIANTS from your kernel. That is, INVARIANTS in kernel incompatible with dynamic loading. Dima To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
Jos Backus wrote: This occurs almost immediately after copying a file to an msdos fs. I can provide more info if that is deemed useful. I suspect your kernel compiled with INVARIANTS, you load msdosfs module dynamically, and the module isn't compiled with INVARIANTS. If so, don't do that. If not, please provide more info. Dima To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: msdosfs is dead, Jim.
Brian Feldman wrote: The basic problem is that msdosfs panic()s quite easily with a zone not free error (INVARIANTS is /ON/ in the kernel), when I attempt to do a rw mount of a FAT16. Don't you, by a chance, load msdosfs module dynamically? If so, the module must also be compiled with INVARIANTS Dima To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Serious locking problem in CURRENT
David Malone wrote: A child process seems to be able to let go of a parent's lock on 4.0 by closing a file discriptor, the same doesn't seem to be true on 3.3. So, apparently, it was broken in rev. 1.68 of kern_descript.c. (Another example that comments (in closef() in this case) serve no purpose :-/). BTW, I have another little concern with that commit: It make possible for last close() of a file descriptor to return 0 instead of the error from VOP_CLOSE(), and the error from VOP_CLOSE() to be ignored. Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
