Re: world broken
Julian Elischer wrote: can you announce when the fixes are in place? I'll do better; I am about to back it all out. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kvm question
On Fri, 22 Jan 1999, Archie Cobbs wrote: Unrelated question: SYSINIT() doesn't work from KLD modules. Is this problem being addressed? you mean sysctl -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
:It's definately happening still, sorry. :-( I recompiled a 100% static :kernel and have had three more explosions, usually after starting exmh. :(exmh takes 10 to 15MB of ram on this system due to my mailbox folder :sizes). : :However, a clue.. The SMP box that is doing fine is a P6, an NFS client :and server (loading nfs.ko, it fsck's fast, so I use that box for making :sure the modules work). The one that is crashing, is a P5, an NFS client :and server (static kernel), and with a MFS /tmp. Both run softupdates (up :to date src/contrib/sys). : :I suspect MFS is the key. There's the new VOP_FREEBLKS() stuff you added, :and the corresponding calls to madvise to free the pages. : :Given madvise()'s murky history, I can't help but feel suspicious about it. : :I've unmounted /tmp and am about to thrash the machine. At the :moment, it's sitting on: Swap: 120M Total, 376K Used, 120M Free : :Cheers, :-Peter Hmmm. It's possible. A quick look at the exmh source indicates that it uses /tmp a lot. I've been doing make buildworld's with a 300MB MFS /usr/obj, but those are typically nothing more then simple file creates, reads, and writes. Presumably exmh is doing something more sophisticated. Try changing the panic in vm/vm_page.c to a printf() ( if (m-dirty) panic(found dirty cache page %p, m); if (m-dirty) printf( found dirty cache page %p (%p,%d,%x) obtype %d obflags %x, m, m-object, (int)m-pindex, (int)m-flags, (int)m-object-type, (int)m-object-flags ); Lets see what we get. This should tell me what kind of object the page is attached to and the flags of the page and object. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
Poul-Henning Kamp writes: ... to make up our mind about it. [ clear arguments for DEVFS and why persistence is complicated ] This email was a few weeks ago, and there was a lively debate, then Julian sent an email listing some issues/requirements, and then the thread kindof died and now we're back to where we were before, which is not any further on.. So I'd like to make another attempt to get agreement on the next step here, so that *something* can happen. We need to get more people using DEVFS, so we can gain some experience feedback. I don't think DEVFS has any issues that are not surmountable. However, at some point you must take the next step. To do this, we need to come up with a 'next step' that doesn't necessarily make everybody happy, but does make enough people happy that they can use it and it becomes somewhat 'mainstream'... Here's my proposal, which is basically the same thing Poul was suggesting: - Have a non-persistent DEVFS in the kernel; when devices appear they have the default permissions - Have an /etc/rc.devices script to make any site-specific customizations at boot up - Have a mount flag that would disable the apperance of new devices - DEVFS remains a kernel option for now To try and answer some of the issues from Julian's email, in the interest of making decisions so we can proceed: 3/ The filesystem needs to give a method to allow new devices to appear as created. If the layout of a /chroot/dev filesystem has been changed, then you need to work out WHERE in the filesystem to create the new device. Devices should appear in the same place (relative to the root of the mount) every time. For now, this path can be hardwired in the device driver. 4/ If a user changes the name of a device or makes a link to it, those devices must still be removed when the device becomes invalid. ... 6/ If a process has a device open and it 'goes away', what should happen? No automatic removal of device nodes.. if the device goes away, then operations start returning ENXIO or whatever. After all, this is what a non-DEVFS system would do in the same situation (if it could). 7/ Persistence is I think a WOFTAM. Some people want it. It could be ignored in my opinion but you should at least have a scheme in mind.. My suggestion is to pick up permissions and owners from inodes of the same name read from the filesystem on which the devfs was mounted. A synthetic / filesystem (An idea that I know Poul has been kicking around for a while) wouldn't be able to do that, but there are other ideas I guess. Devices appear with default permissions and ownership... always. What about a new device that appears when I insert my PCCARD? Well, you can always do what you do now, which is not have them appear, So at least things get no worse. Well, actually now I have the device node with my special permissions set already created in /dev, so when the PCCARD is inserted, the device node already exists with those permissions... Good question.. for now, we ignore this case (and potentially lose a few DEVFS customers). Solving this can be part of the next step. Ideas: (a) have a user daemon; (b) have DEVFS inherit permissions from a 'stub' node of the same name that already exists (if any) when the device appears (then /etc/rc.devices could do its thing for these dynamically appearing nodes as well). 5/ If a device has its modification time changed, does that change reflect through all instances of that device? (E.g. /dev/xxx and /chroot/dev/xxx). What about permissions? What about ownerships? No.. separate nodes are separate files, they just refer to the same device. OK.. so there is some percentage X% of people for whom this proposal would be sufficient to use DEVFS on their systems. Personally, I find it hard to believe that X is not a large number, because for normal usage you'd get exactly what we have now, functionally speaking. It seems like this proposal would make DEVFS acceptable for a large percentage of folks.. but definitely not 100% -- and that's OK for a first step. Ultimately, we want to get to a fully DEVFS world. By taking a few steps at a time, and getting people to *use* it, we can eventually discover and address everybody's concerns. Comments?? The issue here is not whether this proposal is a sufficient *final* incarnation of DEVFS, but whether it's a sufficient next step.. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kvm question
Julian Elischer writes: On Fri, 22 Jan 1999, Archie Cobbs wrote: Unrelated question: SYSINIT() doesn't work from KLD modules. Is this problem being addressed? you mean sysctl Oops, thanks.. SYSCTL() doesn't work from KLD modules but SYSINIT() does. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
Matthew Dillon wrote: :It's definately happening still, sorry. :-( I recompiled a 100% static :kernel and have had three more explosions, usually after starting exmh. :(exmh takes 10 to 15MB of ram on this system due to my mailbox folder :sizes). : :However, a clue.. The SMP box that is doing fine is a P6, an NFS client :and server (loading nfs.ko, it fsck's fast, so I use that box for making :sure the modules work). The one that is crashing, is a P5, an NFS client :and server (static kernel), and with a MFS /tmp. Both run softupdates (up :to date src/contrib/sys). : :I suspect MFS is the key. There's the new VOP_FREEBLKS() stuff you added, :and the corresponding calls to madvise to free the pages. : :Given madvise()'s murky history, I can't help but feel suspicious about it. : :I've unmounted /tmp and am about to thrash the machine. At the :moment, it's sitting on: Swap: 120M Total, 376K Used, 120M Free : :Cheers, :-Peter Hmmm. It's possible. A quick look at the exmh source indicates that it uses /tmp a lot. I've been doing make buildworld's with a 300MB MFS /usr/obj, but those are typically nothing more then simple file creates, reads, and writes. Presumably exmh is doing something more sophisticated. I've since disabled MFS, compiled out a couple of other things I'm not using very often and generally cleaned things up. I've had three more panics since turning off MFS, so that wasn't it. :-( Anyway, I've just recompiled without SMP. There were some very strange things happening on the serial console again that I really do not like the look of. Console output has been disappearing and getting duplicated. Try changing the panic in vm/vm_page.c to a printf() ( I'll do that. FWIW, this has happened while the system has been nearly quiescent all the way through to being thrashed with parallel cvs updates etc running. Most times it waits till exmh is running. Last time (when recompiling without SMP) it crashed when it came to linking the kernel (and no exmh running). I'll see if it still crashes in uniprocessor mode, if so, I'll put some debugging in and see if I can find anything out. The kernel was last built on Jan 16, and that one works fine still, so I'm pretty sure it isn't hardware. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kvm question
Archie Cobbs wrote: Julian Elischer writes: On Fri, 22 Jan 1999, Archie Cobbs wrote: Unrelated question: SYSINIT() doesn't work from KLD modules. Is this problem being addressed? you mean sysctl Oops, thanks.. SYSCTL() doesn't work from KLD modules but SYSINIT() does. -Archie Yes, this is well known. :-( The only way it's going to work is by a major rebuild of the underlying linker set based initialization mechanism. linker sets cannot be updated at module load/unload time. The present mechanism has the nice advantage that the directory tree part of the name is kept in the symbol space and only the terminal node name is an ascii string in the kernel data space. I can't think of an easy way of rebuilding sysctl without loosing that feature. About the best I can think of is some sort of gensetdefs-like tool to scan the binaries of the modules to create a descriptor for any internal sysctl tables - at minimum it needs to know where in the heirarchy it needs to be attached. kern_linker.c can then look for it and attach it to the sysctl tree, once sysctl gets updated to allow dynamic extensions like that. Cheers, -Peter -- Peter Wemm pe...@netplex.com.au Netplex Consulting No coffee, No workee! :-) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
#error This ain't NetBSD. You lose!
A very interesting error during last nights buildworld. In think the fix is obvious. === usr.bin/xlint/xlint cc -O2 -m486 -pipe -DCOMPAT_LINUX_THREADS -DVM_STACK -I/ust/src/usr.bin/xlint/xlint/../lint1 -I/usr/obj/ust/src/tmp/usr/include -c /ust/src/usr.bin/xlint/xlint/xlint.c cc -O2 -m486 -pipe -DCOMPAT_LINUX_THREADS -DVM_STACK -I/ust/src/usr.bin/xlint/xlint/../lint1 -I/usr/obj/ust/src/tmp/usr/include -c /ust/src/usr.bin/xlint/xlint/../lint1/mem.c gzip -cn /ust/src/usr.bin/xlint/xlint/lint.1 lint.1.gz /ust/src/usr.bin/xlint/xlint/xlint.c:333: #error This ain't NetBSD. You lose! *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error -- Brian Litzinger br...@litzinger.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! New swapper and VM changes have been committed to -4.x
On Thu, Jan 21, 1999 at 12:55:38AM -0800, Matthew Dillon wrote: One thing I haven't been able to test, because I forgot: Interleaved swap ( more then one swap device ). I'll try to test that ASAP. I've tried, with sources cvsupped at 0600 22/11/1999 UTC. On a 128MB machine, and a make -j32 buildworld going, all seems to be running well - and possibly more responsive than the last time I tried anything other than -j4 (which was a long time ago). swapinfo output looks a little odd: Device 1K-blocks UsedAvail Capacity Type /dev/da0s2b19660819372 17710810%Interleaved /dev/da3b 19670419140 17743610%Interleaved Total 393056 3930560 100% The totals don't appear to add up. -- Adrian Wontroba To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: readdir cd9660 direntp-d_type == bug (more)
On 22 Jan, Bruce Evans wrote:
/cdrom:
.(type: unknown)
.. (type: unknown)
autorun.inf (type: unknown)
This is because the cd9660 file system doesn't implement d_type.
man dirent or man readdir didn`t note that it`s possible to have this
behavior.
#define _POSIX_SOURCE
#include sys/types.h
#include dirent.h
...
while((dent_p = readdir(dir_p)))
{
printf(%-40s (type: %s)\n, dent_p-d_name, types[dent_p-d_type]);
}
This probably shouldn't compile, since d_type isn't in POSIX.1. POSIX.1
It compiles, output above.
only guarantees d_name in struct dirent. Names beginning with d_ are
reserved for use in dirent.h, but FreeBSD normally attempts to give
strict POSIX.1 if _POSIX_SOURCE is defined.
So it`s a bug, but in a different way I want. :(
Without _POSIX_SOURCE it didn`t work either.
Is it useless, because we can only say it works _perhaps_ (and we
have to stat the entry), or is it a bug?
Bye,
Alexander.
--
http://netchild.home.pages.de A.Leidinger @ wurzelausix.cs.uni-sb.de
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
PLIP code giving funny logs...
Hi I het a lot of this in my PLIP connection: Jan 23 14:44:00 gratis /kernel: X Jan 23 14:44:00 gratis /kernel: X Jan 23 14:44:01 gratis /kernel: RR Jan 23 14:44:01 gratis /kernel: RR Jan 23 14:44:02 gratis /kernel: X^X^R Jan 23 14:44:02 gratis /kernel: X^X^R Seems that in src/sys/dev/ppbus/if_plip.c there is #ifndef DEBUG #define DEBUG #endif Is this really necessary? What do the letters actually mean? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: softupdates bug shows on zip drive and parallel port in NIBBLE mode
On Sat, Jan 23, 1999 at 01:34:40AM -0500, Mikhail Teterin wrote: I tried both cam and bio -- no difference. It is not that it's slow -- I was prepared for that, it is that it totally hangs -- forever. I narrowed it down to softupdates. If I disable the softupdates on the cartridge's filesystem copying finishes successfully. Somehow the `cp' process takes 150% of the CPU time (purely single CPU system), but that's a different story, I guess. The drive is polling-capable only. So it makes no difference with the cam/bio configuration. And it explains your performance result. I hope, this sad experience of mine will help further improve softupdates. Thanks. -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: PLIP code giving funny logs...
On Sat, Jan 23, 1999 at 02:59:22PM +0200, Mark Murray wrote: Hi I het a lot of this in my PLIP connection: Jan 23 14:44:00 gratis /kernel: X Jan 23 14:44:00 gratis /kernel: X Jan 23 14:44:01 gratis /kernel: RR Jan 23 14:44:01 gratis /kernel: RR Jan 23 14:44:02 gratis /kernel: X^X^R Jan 23 14:44:02 gratis /kernel: X^X^R Seems that in src/sys/dev/ppbus/if_plip.c there is #ifndef DEBUG #define DEBUG #endif Is this really necessary? What do the letters actually mean? An error occured, timeout, incorrect handshake.. It was intended to catch potential problems of the plip driver. I should remove it now. Thanks for your note. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Nicholas. -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: softupdates bug shows on zip drive and parallel port in NIBBLE mode
=I tried both cam and bio -- no difference. It is not that it's =slow -- I was prepared for that, it is that it totally hangs -- =forever. = =I narrowed it down to softupdates. If I disable the softupdates on =the cartridge's filesystem copying finishes successfully. Somehow =the `cp' process takes 150% of the CPU time (purely single CPU system), =but that's a different story, I guess. =The drive is polling-capable only. So it makes no difference with the =cam/bio configuration. And it explains your performance result. I figured that. I only wonder if the driver can be made to poll less often -- yielding to others. But it works reliably now that I do not use SoftUpdates on it. Thanks! -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: world broken
Has this been done yet? It has been over 7 hours since the post and I have only seen two source changes, and they are in sys/pci by roger. Tom Veldhouse ve...@visi.com Mark Murray wrote: Julian Elischer wrote: can you announce when the fixes are in place? I'll do better; I am about to back it all out. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: world broken
Never mind, I was using the RELENG_3 tag during CVSup. Sorry. Thomas T. Veldhouse wrote: Has this been done yet? It has been over 7 hours since the post and I have only seen two source changes, and they are in sys/pci by roger. Tom Veldhouse ve...@visi.com Mark Murray wrote: Julian Elischer wrote: can you announce when the fixes are in place? I'll do better; I am about to back it all out. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Device Framework Overview
I've just posted a brief overview of the new device system in FreeBSD at http://www.freebsd.org/~dfr/devices.html. The information content is fairly small but it might help someone who is trying to understand the source code. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: world broken
Thomas T. Veldhouse wrote: Has this been done yet? It has been over 7 hours since the post and I have only seen two source changes, and they are in sys/pci by roger. Hours ago :-). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
-current (aka 4.x) breaks libtool
Hi This isn't exactly topic here, but it might be useful as a little hint or warning... Even most recent versions of libtool (1.2e imho) fail to check for freebsd4* (as expected). As a result, they set can_build_shared to no which disables building of shared libraries. This affects most major projects like kde or gnome and can result in major abuse of disk- and memory space :) (some kde or gnome binaries tend to get *very* large when linked statically). Workarounds ? I'am currently using --host=i386-unknown-freebsd3 as a possible workaround, another way might be a small modification of ltconfig. Sorry, if this has been already mentioned... -- # /AS/ http://privat.schlund.de/entropy/ # # # # If Jesus was never born, we would not have a Y2K problem.# To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Make world dies on 3.0 STABLE
On Thu, Jan 21, 1999 at 07:41:20AM -0400, Victor Salaman wrote: I just csvup'ed the sources...(I had the sources from January 12's snapshot). While trying to do a make world, eventually I get this message. c++ -pg -I/usr/obj/usr/src/tmp/usr/include/g++ -nostdinc -O -pipe -I/usr/src/gnu [snipped] Stop. *** Error code 1 Stop. and then dies! What's your migration path? I went from 3.0-current to 3.0-release and then to 3.0-stable successfully. I have noticed that 'ppp -auto -alias demand' no longer works for me, however. Anybody else experiencing this gremlin? -- Tom To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kvm question
I ran into an interesting problem in the process of modifying netstat to understand the PF_NETGRAPH protocol family. netstat uses kvm_read(), etc. to read kernel symbols. However, this doesn't work when the symbols you're looking for are in an KLD module (eg, ng_socket.ko) -- the symbol will not be found. So I added some code/hackery to look for any loaded modules and if on named ng_socket.ko was found, try finding the symbol in there. My question is, should kvm_read() and friends be enhanced with this ability to find a symbol by searching through the loaded KLD modules? Seems a bit hackish, but then again so is the whole kvm() idea. No; you should be using sysctl to get at the information. I'd be willing to add this code if so.. it's not much. Unrelated question: SYSINIT() doesn't work from KLD modules. Is this problem being addressed? It does; it's critical to the functioning of KLD modules in general. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kvm question
Julian Elischer writes: On Fri, 22 Jan 1999, Archie Cobbs wrote: Unrelated question: SYSINIT() doesn't work from KLD modules. Is this problem being addressed? you mean sysctl Oops, thanks.. SYSCTL() doesn't work from KLD modules but SYSINIT() does. What I get for being too fast. 8) Yes, there's a desire to see this fixed; it requires a significant rewrite of the sysctl stuff unfortunately. Mark Murray was working on this but probably as a 4.x feature; if you have something simpler you feel up to contributing in the short term you'd be very popular. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
On Sat, 23 Jan 1999, Peter Wemm wrote: Matthew Dillon wrote: :It's definately happening still, sorry. :-( I recompiled a 100% static :kernel and have had three more explosions, usually after starting exmh. :(exmh takes 10 to 15MB of ram on this system due to my mailbox folder :sizes). : :However, a clue.. The SMP box that is doing fine is a P6, an NFS client :and server (loading nfs.ko, it fsck's fast, so I use that box for making :sure the modules work). The one that is crashing, is a P5, an NFS client :and server (static kernel), and with a MFS /tmp. Both run softupdates (up :to date src/contrib/sys). : :I suspect MFS is the key. There's the new VOP_FREEBLKS() stuff you added, :and the corresponding calls to madvise to free the pages. : :Given madvise()'s murky history, I can't help but feel suspicious about it. : :I've unmounted /tmp and am about to thrash the machine. At the :moment, it's sitting on: Swap: 120M Total, 376K Used, 120M Free : :Cheers, :-Peter Hmmm. It's possible. A quick look at the exmh source indicates that it uses /tmp a lot. I've been doing make buildworld's with a 300MB MFS /usr/obj, but those are typically nothing more then simple file creates, reads, and writes. Presumably exmh is doing something more sophisticated. I've since disabled MFS, compiled out a couple of other things I'm not using very often and generally cleaned things up. I've had three more panics since turning off MFS, so that wasn't it. :-( Anyway, I've just recompiled without SMP. There were some very strange things happening on the serial console again that I really do not like the look of. Console output has been disappearing and getting duplicated. Try changing the panic in vm/vm_page.c to a printf() ( I'll do that. FWIW, this has happened while the system has been nearly quiescent all the way through to being thrashed with parallel cvs updates etc running. Most times it waits till exmh is running. Last time (when recompiling without SMP) it crashed when it came to linking the kernel (and no exmh running). I'll see if it still crashes in uniprocessor mode, if so, I'll put some debugging in and see if I can find anything out. The kernel was last built on Jan 16, and that one works fine still, so I'm pretty sure it isn't hardware. I just had one of these on one of my alphas. The machine is UP (obviously), no MFS, no dynamically loaded stuff. It was doing an installworld with NFSv3 mounted source, local obj. All filesystems were using softupdates. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
On Sat, 23 Jan 1999, Doug Rabson wrote: I just had one of these on one of my alphas. The machine is UP (obviously), no MFS, no dynamically loaded stuff. It was doing an installworld with NFSv3 mounted source, local obj. All filesystems were using softupdates. I made it happen again by doing the same installworld but this time I caught it in the debugger. I'll leave the machine up for a while in case someone has some idea of how to debug it. The stacktrace looks like this: #0 Debugger () at ../../alpha/alpha/db_interface.c:260 #1 0xfc36c2c0 in panic () at ../../kern/kern_shutdown.c:444 #2 0xfc4942fc in vm_page_alloc () at ../../vm/vm_page.c:1041 #3 0xfc3a1b54 in allocbuf () at ../../kern/vfs_bio.c:1791 #4 0xfc3a13d4 in getblk () at ../../kern/vfs_bio.c:1572 #5 0xfc46a150 in ffs_balloc () at ../../ufs/ffs/ffs_balloc.c:170 #6 0xfc4772dc in ffs_write () at vnode_if.h:1015 #7 0xfc3b3c00 in vn_write () at vnode_if.h:331 #8 0xfc37f72c in write () at ../../kern/sys_generic.c:270 #9 0xfc4b0a4c in syscall () at ../../alpha/alpha/trap.c:620 #10 0xfc4a416c in XentSys () at ../../alpha/alpha/exception.s:127 -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
make aout-to-elf-bbuild failure
-current as of early this morning % make aout-to-elf-bbuild ... cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 pccard/*.h /usr/obj/aout/usr/src/tmp/usr/include/pccard cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 posix4/*.h /usr/obj/aout/usr/src/tmp/usr/include/posix4 cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 sys/*.h /usr/obj/aout/usr/src/tmp/usr/include/sys cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 vm/*.h /usr/obj/aout/usr/src/tmp/usr/include/vm cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 isofs/cd9660/*.h /usr/obj/aout/usr/src/tmp/usr/include/isofs/cd9660 cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 ufs/ffs/*.h /usr/obj/aout/usr/src/tmp/usr/include/ufs/ffs install: ufs/ffs/ffs_softdep.h: No such file or directory *** Error code 71 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kvm question
Mike Smith writes: Yes, there's a desire to see this fixed; it requires a significant rewrite of the sysctl stuff unfortunately. Mark Murray was working on this but probably as a 4.x feature; if you have something simpler you feel up to contributing in the short term you'd be very popular. Peter pointed out that having the sysctl's as symbols was a nice advantage of the current system. How important is this? If we were willing to give this up, then the SYSCTL() macro could just expand to a SYSINIT() that called sysctl_add_subtree() (or whatever you want to call it) upon loading. This sysctl_add_subtree() would maintain the sysctl tree... it would allow new subtrees and nodes to be added when new KLD's were loaded. It could also subtree support removal when the KLD goes away. Seems pretty straightforward, but I'm probably missing something. I don't think any user-land programs would have to change. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
:I made it happen again by doing the same installworld but this time I :caught it in the debugger. I'll leave the machine up for a while in case :someone has some idea of how to debug it. The stacktrace looks like this: : :#0 Debugger () at ../../alpha/alpha/db_interface.c:260 :#1 0xfc36c2c0 in panic () at ../../kern/kern_shutdown.c:444 :#2 0xfc4942fc in vm_page_alloc () at ../../vm/vm_page.c:1041 :#3 0xfc3a1b54 in allocbuf () at ../../kern/vfs_bio.c:1791 The panic message should be printing the address of the vm_page_t that it caught. From the debugger, dump that vm_page_t with 'print'. print *0xADDRESS Do about 8 print's bumping the address by 4 ( in hex ) for each. It would be even better if we could figure out the contents and type of the underlying object. -Matt Matthew Dillon dil...@backplane.com :-- :Doug RabsonMail: d...@nlsystems.com :Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: make aout-to-elf-bbuild failure
In article m1047wh-0008...@rip.psg.com, Randy Bush ra...@psg.com wrote: -current as of early this morning % make aout-to-elf-bbuild ... cd /usr/src/include/../sys; install -C -o root -g wheel -m 444 ufs/ffs/*.h /usr/obj/aout/usr/src/tmp/usr/include/ufs/ffs install: ufs/ffs/ffs_softdep.h: No such file or directory *** Error code 71 Judging from these messages, I'd guess that you have a symbolic link /usr/src/sys/ufs/ffs/ffs_softdep.h that points to a non-existent file. Delete it. The correct link names are ffs_softdep.c and softdep.h. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Nobody ever went broke underestimating the taste of the American public. -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
On Sat, 23 Jan 1999, Matthew Dillon wrote:
:I made it happen again by doing the same installworld but this time I
:caught it in the debugger. I'll leave the machine up for a while in case
:someone has some idea of how to debug it. The stacktrace looks like this:
:
:#0 Debugger () at ../../alpha/alpha/db_interface.c:260
:#1 0xfc36c2c0 in panic () at ../../kern/kern_shutdown.c:444
:#2 0xfc4942fc in vm_page_alloc () at ../../vm/vm_page.c:1041
:#3 0xfc3a1b54 in allocbuf () at ../../kern/vfs_bio.c:1791
The panic message should be printing the address of the vm_page_t that
it caught.
From the debugger, dump that vm_page_t with 'print'.
print *0xADDRESS
Do about 8 print's bumping the address by 4 ( in hex ) for each.
It would be even better if we could figure out the contents and type
of the underlying object.
I have full symbols:
(gdb) fr 2
#2 0xfc4942fc in vm_page_alloc () at ../../vm/vm_page.c:1041
1041panic(found dirty cache page %p, m);
(gdb) l
1036 */
1037
1038if (qtype == PQ_CACHE) {
1039#if !defined(MAX_PERF)
1040if (m-dirty)
1041panic(found dirty cache page %p, m);
1042
1043#endif
1044vm_page_busy(m);
1045vm_page_protect(m, VM_PROT_NONE);
(gdb) p m
$4 = (struct vm_page *) 0xfe108f40
(gdb) p *m
$5 = {pageq = {tqe_next = 0x0, tqe_prev = 0xfc52ecc8}, hnext = 0x0,
listq = {tqe_next = 0xfe090fe0, tqe_prev = 0xfe0bb6b8},
object = 0xfe00050e2a10, pindex = 12, phys_addr = 88940544, queue = 172,
flags = 128, pc = 41, wire_count = 0, hold_count = 0, act_count = 5 '\005',
busy = 0 '\000', valid = 65535, dirty = 65535}
--
Doug Rabson Mail: d...@nlsystems.com
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: kvm question
Mike Smith writes: My question is, should kvm_read() and friends be enhanced with this ability to find a symbol by searching through the loaded KLD modules? Seems a bit hackish, but then again so is the whole kvm() idea. No; you should be using sysctl to get at the information. Yes in *one particular application* using sysctl would be better.. but that's not the question. The question is, should this bug in libkvm be fixed? Until and unless someone is willing to convert every program that uses libkvm to use sysctl or procfs or whatever, I think this is a fair question. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
aic driver status
For everybody who has been waiting for me finish the aic driver I thought I should give a status report. My move is mostly complete and I am trying to get back to working in the aic driver. Unfortunately I have run into hardware problems. Having just bought a house I can not afford to run out and buy all new hardware. I am currently trying to diagnose the problem, (it could be one or more of: controller, cpu, memory, motherboard). While I would still like to do the driver myself, if there is anybody out there who is itching to work on it themselves you might get in touch with me. Brian Beattie| The only problem with beat...@aracnet.com | winning the rat race ... www.aracnet.com/~beattie | in the end you're still a rat To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
Doug Rabson wrote:
On Sat, 23 Jan 1999, Matthew Dillon wrote:
:I made it happen again by doing the same installworld but this time I
:caught it in the debugger. I'll leave the machine up for a while in case
:someone has some idea of how to debug it. The stacktrace looks like this:
:
:#0 Debugger () at ../../alpha/alpha/db_interface.c:260
:#1 0xfc36c2c0 in panic () at ../../kern/kern_shutdown.c:444
:#2 0xfc4942fc in vm_page_alloc () at ../../vm/vm_page.c:1041
:#3 0xfc3a1b54 in allocbuf () at ../../kern/vfs_bio.c:1791
The panic message should be printing the address of the vm_page_t that
it caught.
From the debugger, dump that vm_page_t with 'print'.
print *0xADDRESS
Do about 8 print's bumping the address by 4 ( in hex ) for each.
It would be even better if we could figure out the contents and type
of the underlying object.
I have full symbols:
(gdb) fr 2
#2 0xfc4942fc in vm_page_alloc () at ../../vm/vm_page.c:1041
1041panic(found dirty cache page %p, m);
(gdb) l
1036 */
1037
1038if (qtype == PQ_CACHE) {
1039#if !defined(MAX_PERF)
1040if (m-dirty)
1041panic(found dirty cache page %p, m);
1042
1043#endif
1044vm_page_busy(m);
1045vm_page_protect(m, VM_PROT_NONE);
(gdb) p m
$4 = (struct vm_page *) 0xfe108f40
(gdb) p *m
$5 = {pageq = {tqe_next = 0x0, tqe_prev = 0xfc52ecc8}, hnext = 0x0,
listq = {tqe_next = 0xfe090fe0, tqe_prev = 0xfe0bb6b8},
object = 0xfe00050e2a10, pindex = 12, phys_addr = 88940544, queue = 172
,
flags = 128, pc = 41, wire_count = 0, hold_count = 0, act_count = 5 '\005',
busy = 0 '\000', valid = 65535, dirty = 65535}
--
Doug, Matt wanted some things from m-object too.. If it's still there
can you grab it?
printf(
found dirty cache page %p (%p,%d,%x) obtype %d obflags %x,
m,
m-object,
(int)m-pindex,
(int)m-flags,
(int)m-object-type,
(int)m-object-flags
);
BTW; in vm_map.c:
/*
* vm_map_clean
*
* Push any dirty cached pages in the address range to their pager.
* If syncio is TRUE, dirty pages are written synchronously.
* If invalidate is TRUE, any cached pages are freed as well.
*
* Returns an error if any part of the specified range is not mapped.
*/
This kinda suggests that dirty cached pages might not be all that
unusual.. but the code in question seems to be working at a different
level.
Cheers,
-Peter
--
Peter Wemm pe...@netplex.com.au Netplex Consulting
No coffee, No workee! :-)
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: -current (aka 4.x) breaks libtool
At 05:47 PM 1/23/99 +0100, Alexander Sanda wrote:
Even most recent versions of libtool (1.2e imho) fail to check for
freebsd4* (as expected). As a result, they set can_build_shared to no
which disables building of shared libraries.
Here is a simple patch (which I'll forward this to the libtool
maintainers).
I've just applied the following to the OpenLDAP copy of ltconfig.
It should work for FreeBSD 4.0 and beyond...
Index: ltconfig
===
RCS file: /repo/OpenLDAP/pkg/ldap/build/ltconfig,v
retrieving revision 1.4
diff -u -r1.4 ltconfig
--- ltconfig1998/12/21 22:08:06 1.4
+++ ltconfig1999/01/23 19:38:42
@@ -776,8 +776,13 @@
hardcode_shlibpath_var=no
;;
- # FreeBSD 3, at last, uses gcc -shared to do shared libraries.
- freebsd3*)
+ freebsd1*)
+ld_shlibs=no
+can_build_shared=no
+;;
+
+ # FreeBSD 3 and greater uses gcc -shared to do shared libraries.
+ freebsd* )
archive_cmds='$CC -shared -o $lib$libobjs'
hardcode_libdir_flag_spec='-R$libdir'
hardcode_direct=yes
@@ -1129,8 +1134,12 @@
finish_cmds='PATH=$PATH:/sbin ldconfig -m $libdir'
shlibpath_var=LD_LIBRARY_PATH
;;
+
+freebsd1*)
+ dynamic_linker=no
+ ;;
-freebsd3*)
+freebsd*)
version_type=freebsd
library_names_spec='${libname}${release}.so.$versuffix $libname.so'
if [ -x `/usr/bin/objformat` ]; then
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
Peter Wemm wrote: Matthew Dillon wrote: [..] Try changing the panic in vm/vm_page.c to a printf() ( I'll do that. BTW; what are the dangers of this? lost disk writes or corruption? Can we (as a workaround) push the page that we found back onto a dirty queue and try again after some diagnostics? FWIW, this has happened while the system has been nearly quiescent all the way through to being thrashed with parallel cvs updates etc running. Most times it waits till exmh is running. Last time (when recompiling without SMP) it crashed when it came to linking the kernel (and no exmh running). I'll see if it still crashes in uniprocessor mode, if so, I'll put some debugging in and see if I can find anything out. The kernel was last built on Jan 16, and that one works fine still, so I'm pretty sure it isn't hardware. It crashed in uniprocessor mode about 60 seconds after sending this mail. It's got a really trimmed down kernel config and no modules loaded or in use. I have not disabled softupdates yet, that's next. This particular machine won't reboot by itself after it's been running in SMP mode (it's really old), so I have to manually reset it. I went to sleep straight after that, and it ran the whole time I was asleep. After getting up again, I started exmh, and it crashed 30 seconds later. There was no swapping in progress, I have been tunning top -s1 to see what the swap and memory state is when it dies. Unfortunately I lost the last one, but it generally looks like this: last pid: 6293; load averages: 0.51, 0.52, 0.65up 0+01:40:54 14:19:06 40 processes: 1 running, 39 sleeping CPU states: 4.6% user, 0.0% nice, 11.8% system, 1.5% interrupt, 82.1% idle Mem: 19M Active, 9236K Inact, 13M Wired, 3068K Cache, 4691K Buf, 508K Free Swap: 120M Total, 128K Used, 120M Free This machine has 48M of ram, one swap partition only. Oh, one other thing that occurred to me.. Under 4.0-current, I regularly (ie: within 30 seconds of boot) get if_de tranmitter underflows. My console corruption was happening at the instant that de0 was being configured with ifconfig. exmh is running to a remote display over that de0 interface. Under Jan 16 3.0-current, I do not get that tranmitter underflow.. The only thin I can think of about if_de that's unusual that is VM related (apart from the complexity of the code) is that it uses configmalloc(). I wonder if this is somehow setting the scene for the later failures? It's certainly suspicious that has done strange things when being ifconfig'ed, including things like trashing the serial console on no less than a dozen occasions. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
On Sun, 24 Jan 1999, Peter Wemm wrote:
Doug Rabson wrote:
On Sat, 23 Jan 1999, Matthew Dillon wrote:
:I made it happen again by doing the same installworld but this time I
:caught it in the debugger. I'll leave the machine up for a while in case
:someone has some idea of how to debug it. The stacktrace looks like
this:
:
:#0 Debugger () at ../../alpha/alpha/db_interface.c:260
:#1 0xfc36c2c0 in panic () at ../../kern/kern_shutdown.c:444
:#2 0xfc4942fc in vm_page_alloc () at ../../vm/vm_page.c:1041
:#3 0xfc3a1b54 in allocbuf () at ../../kern/vfs_bio.c:1791
The panic message should be printing the address of the vm_page_t that
it caught.
From the debugger, dump that vm_page_t with 'print'.
print *0xADDRESS
Do about 8 print's bumping the address by 4 ( in hex ) for each.
It would be even better if we could figure out the contents and type
of the underlying object.
I have full symbols:
(gdb) fr 2
#2 0xfc4942fc in vm_page_alloc () at ../../vm/vm_page.c:1041
1041panic(found dirty cache page %p, m);
(gdb) l
1036 */
1037
1038if (qtype == PQ_CACHE) {
1039#if !defined(MAX_PERF)
1040if (m-dirty)
1041panic(found dirty cache page %p, m);
1042
1043#endif
1044vm_page_busy(m);
1045vm_page_protect(m, VM_PROT_NONE);
(gdb) p m
$4 = (struct vm_page *) 0xfe108f40
(gdb) p *m
$5 = {pageq = {tqe_next = 0x0, tqe_prev = 0xfc52ecc8}, hnext = 0x0,
listq = {tqe_next = 0xfe090fe0, tqe_prev = 0xfe0bb6b8},
object = 0xfe00050e2a10, pindex = 12, phys_addr = 88940544, queue =
172
,
flags = 128, pc = 41, wire_count = 0, hold_count = 0, act_count = 5
'\005',
busy = 0 '\000', valid = 65535, dirty = 65535}
--
Doug, Matt wanted some things from m-object too.. If it's still there
can you grab it?
printf(
found dirty cache page %p (%p,%d,%x) obtype %d obflags %x,
m,
m-object,
(int)m-pindex,
(int)m-flags,
(int)m-object-type,
(int)m-object-flags
);
He sent me private mail asking for m-object which I replied to. Here is
*m-object:
$6 = {object_list = {tqe_next = 0xfe0005369870,
tqe_prev = 0xfe000527e0b8}, shadow_head = {tqh_first = 0x0,
tqh_last = 0xfe00050e2a20}, shadow_list = {tqe_next = 0x0,
tqe_prev = 0xfe00052d2020}, memq = {tqh_first = 0xfe0c8f80,
tqh_last = 0xfe115a78}, generation = 897, type = OBJT_DEFAULT,
size = 23, ref_count = 1, shadow_count = 0, pg_color = 4,
hash_rand = -15145890, flags = 8192, paging_in_progress = 0, behavior = 0,
resident_page_count = 15, cache_count = 15, wire_count = 0,
backing_object = 0x0, backing_object_offset = 0, last_read = 0,
pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, handle = 0x0,
un_pager = {vnp = {vnp_size = 754}, devp = {devp_pglist = {
tqh_first = 0x2f2, tqh_last = 0x0}}, swp = {swp_bcount = 754}}}
BTW; in vm_map.c:
/*
* vm_map_clean
*
* Push any dirty cached pages in the address range to their pager.
* If syncio is TRUE, dirty pages are written synchronously.
* If invalidate is TRUE, any cached pages are freed as well.
*
* Returns an error if any part of the specified range is not mapped.
*/
This kinda suggests that dirty cached pages might not be all that
unusual.. but the code in question seems to be working at a different
level.
I'm not too familiar with this code. It is only called from msync(2) as
far as I can see.
--
Doug Rabson Mail: d...@nlsystems.com
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Failure to make buildworld on RELENG_3
It seems to be the same problem we have been having with current. Should it be crypt stuff be backed out of here as well? === libpam/modules/pam_radius === libpam/modules/pam_skey === libpam/modules/pam_tacplus === libpam/modules/pam_unix === libpam/libpam ld -o pam_static_modules.o -r -Bforcearchive pam_static.o ../modules/pam_cleartext_pass_ok/libpam_cleart ext_pass_ok.a ../modules/pam_kerberosIV/libpam_kerberosIV.a ../modules/pam_radius/libpam_radius.a ../mod ules/pam_skey/libpam_skey.a ../modules/pam_tacplus/libpam_tacplus.a ../modules/pam_unix/libpam_unix.a ../modules/pam_cleartext_pass_ok/libpam_cleartext_pass_ok.a(pam_cleartext_pass_ok.o): Definition of symb ol `_pam_sm_authenticate' (multiply defined) ../modules/pam_cleartext_pass_ok/libpam_cleartext_pass_ok.a(pam_cleartext_pass_ok.o): Definition of symb ol `_pam_sm_setcred' (multiply defined) ../modules/pam_kerberosIV/libpam_kerberosIV.a(pam_kerberosIV.o): Definition of symbol `_pam_sm_authentic ate' (multiply defined) ../modules/pam_kerberosIV/libpam_kerberosIV.a(pam_kerberosIV.o): Definition of symbol `_pam_sm_setcred' (multiply defined) ../modules/pam_radius/libpam_radius.a(pam_radius.o): Definition of symbol `_pam_sm_authenticate' (multip ly defined) ../modules/pam_radius/libpam_radius.a(pam_radius.o): Definition of symbol `_pam_sm_setcred' (multiply de fined) ../modules/pam_skey/libpam_skey.a(pam_skey.o): Definition of symbol `_pam_sm_authenticate' (multiply def ined) ../modules/pam_skey/libpam_skey.a(pam_skey.o): Definition of symbol `_pam_sm_setcred' (multiply defined) ../modules/pam_tacplus/libpam_tacplus.a(pam_tacplus.o): Definition of symbol `_pam_sm_authenticate' (mul tiply defined) ../modules/pam_tacplus/libpam_tacplus.a(pam_tacplus.o): Definition of symbol `_pam_sm_setcred' (multiply defined) ../modules/pam_unix/libpam_unix.a(pam_unix.o): Definition of symbol `_pam_sm_authenticate' (multiply def ined) ../modules/pam_unix/libpam_unix.a(pam_unix.o): Definition of symbol `_pam_sm_setcred' (multiply defined) *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. Tom Veldhoue ve...@visi.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
:[..] : Try changing the panic in vm/vm_page.c to a printf() ( : : I'll do that. : :BTW; what are the dangers of this? lost disk writes or corruption? Can :we (as a workaround) push the page that we found back onto a dirty queue :and try again after some diagnostics? That's ok, don't worry about it... Doug's debug output gives me the same info. :It crashed in uniprocessor mode about 60 seconds after sending this mail. :It's got a really trimmed down kernel config and no modules loaded or in :use. I have not disabled softupdates yet, that's next. I don't get it why can't I reproduce this problem? Can you email me your kernel configuration? Are you using any special devices like vn or something ? :Oh, one other thing that occurred to me.. Under 4.0-current, I regularly :(ie: within 30 seconds of boot) get if_de tranmitter underflows. My :console corruption was happening at the instant that de0 was being :configured with ifconfig. exmh is running to a remote display over that :de0 interface. : :Under Jan 16 3.0-current, I do not get that tranmitter underflow.. : :The only thin I can think of about if_de that's unusual that is VM related :(apart from the complexity of the code) is that it uses configmalloc(). I :wonder if this is somehow setting the scene for the later failures? It's :certainly suspicious that has done strange things when being ifconfig'ed, :including things like trashing the serial console on no less than a dozen :occasions. : :Cheers, :-Peter Hmmm.. HMM. contigmalloc, eh? You might be onto something here. I will investigate it. The problem was are having is that, somehow, a vm_page_t in the PQ_CACHE is being set dirty. Sinc vm_page_cache() panics if m-dirty is set, then m-dirty must be getting set *after* the page has been moved to the cache. contigmalloc() looks suspicious. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
current version bump brakes libtool
I'm sorry if this was already discussed -- I just re-subscribed to current. In many places in config scripts, host_os is checked against freebsd2 | freebsd3 Absence of freebsd4 breaks stuff, like, for example, kdelibs11 port, which refuses to build shared libraries on an unknown platform such as freebsd4 (see kdelibs11/work/kdelibs/admin/ltconfig). -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
Matthew Dillon wrote: [..] :Oh, one other thing that occurred to me.. Under 4.0-current, I regularly :(ie: within 30 seconds of boot) get if_de tranmitter underflows. My :console corruption was happening at the instant that de0 was being :configured with ifconfig. exmh is running to a remote display over that :de0 interface. : :Under Jan 16 3.0-current, I do not get that tranmitter underflow.. : :The only thin I can think of about if_de that's unusual that is VM related :(apart from the complexity of the code) is that it uses configmalloc(). I :wonder if this is somehow setting the scene for the later failures? It's :certainly suspicious that has done strange things when being ifconfig'ed, :including things like trashing the serial console on no less than a dozen :occasions. : :Cheers, :-Peter Hmmm.. HMM. contigmalloc, eh? You might be onto something here. I will investigate it. The problem was are having is that, somehow, a vm_page_t in the PQ_CACHE is being set dirty. Sinc vm_page_cache() panics if m-dirty is set, then m-dirty must be get ting set *after* the page has been moved to the cache. contigmalloc() looks suspicious. Damn, I must be loosing my mind. if_de doesn't use contigmalloc.. it either did, or was going to as a result of the problem of the transmit descriptor array crossing a page boundary that had to be contiguous. In the end there were two seperate malloc's, each less than PAGE_SIZE. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
On Sun, 24 Jan 1999, Peter Wemm wrote: Oh, one other thing that occurred to me.. Under 4.0-current, I regularly (ie: within 30 seconds of boot) get if_de tranmitter underflows. My console corruption was happening at the instant that de0 was being configured with ifconfig. exmh is running to a remote display over that de0 interface. Under Jan 16 3.0-current, I do not get that tranmitter underflow.. One of my alpha boxes has always got a few of these errors when it first transmits a largish packet. It happened under NetBSD and FreeBSD since I bought the machine (about June last year I think). Andrew Gallatin has seen similar errors on OSF1. I think its harmless. The only thin I can think of about if_de that's unusual that is VM related (apart from the complexity of the code) is that it uses configmalloc(). I wonder if this is somehow setting the scene for the later failures? It's certainly suspicious that has done strange things when being ifconfig'ed, including things like trashing the serial console on no less than a dozen occasions. I can't see where if_de is using contigmalloc(). I thought the bus_dma code in there wasn't used on FreeBSD. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Bootstrap loader problems on CURRENT
As of Today's 4.0-CURRENT My system Halts on boot-up after the BTX Driver showing my BIOS-drives, with the following message: FreeBSD/i386 bootstrap loader, Revision 0.2 (dae...@shadowmere. etc...) ficlExecFD: Error at line 1 then it shows a lot of Register-information with the message System halted this is when trying to execute boot/loader When I am fast enough on the Boot-Manager Boot-prompt .. I am able to simply type /kernel instead of 0:wd(0,a)/boot/loader and my System Will boot the 4.0-kernel and run fine. I CVSup-ed the sources earlier today .. (about 6-7 hours) Pascal Hofstee - dae...@shadowmere.student.utwente.nl -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS d- s+: a-- C++ UB P+ L- E--- W- N+ o? K- w--- O? M V? PS+ PE Y-- PGP-- t+ 5 X-- R tv+ b+ DI D- G e* h+ r- y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: make aout-to-elf-build failure
an hour further on /usr/obj/aout/usr/src/tmp/usr/libexec/elf/ld: warning: libcrypt.so.2, needed by /usr/obj/elf/usr/src/kerberosIV/libexec/kauthd/../../lib/libkrb/libkrb.so, not found (try using --rpath) /usr/obj/elf/usr/src/kerberosIV/libexec/kauthd/../../lib/libkrb/libkrb.so: undefined reference to `crypt' *** Error code 1 Stop. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Failure to make buildworld on RELENG_3
Thomas T. Veldhouse wrote: It seems to be the same problem we have been having with current. Should it be crypt stuff be backed out of here as well? _Completely_ Different issue. :-( M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
dirty fs after apm power off
I have noticed this behaviour on at least one machine. If I shutdown the machine with apm power off, the filesystem is dirty and has to been checked on the next reboot. It seems, the power is cut too fast. I don't have any problems with reboots. It seems the drive doesn't have the time to write the superblock back to disk. I simply put a DELAY(400) in the apm_power_off() routine and the problem fades away. Any thoughts on doing this a configurable option? It doesn't break anything, it only takes a few seconds longer for the machine to power off. The drive is a Maxtor Diamond Max (90432D2) 4GB IDE drive in an Asus SP98 board. Daniel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: dirty fs after apm power off
probably the drive needs write-caching turned off... On Sat, 23 Jan 1999, D. Rock wrote: I have noticed this behaviour on at least one machine. If I shutdown the machine with apm power off, the filesystem is dirty and has to been checked on the next reboot. It seems, the power is cut too fast. I don't have any problems with reboots. It seems the drive doesn't have the time to write the superblock back to disk. I simply put a DELAY(400) in the apm_power_off() routine and the problem fades away. Any thoughts on doing this a configurable option? It doesn't break anything, it only takes a few seconds longer for the machine to power off. The drive is a Maxtor Diamond Max (90432D2) 4GB IDE drive in an Asus SP98 board. Daniel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -current (aka 4.x) breaks libtool
On Sat, 23 Jan 1999, Kurt D. Zeilenga wrote:
At 05:47 PM 1/23/99 +0100, Alexander Sanda wrote:
Even most recent versions of libtool (1.2e imho) fail to check for
freebsd4* (as expected). As a result, they set can_build_shared to no
which disables building of shared libraries.
Here is a simple patch (which I'll forward this to the libtool
maintainers).
I don't really like that because it assumes that FreeBSD 3.0 and greater
will all have compatable binutils. Somehow I don't think this is going to
be the case (or there's a strong chance that it won't be the case). That
said, the following is what I've commited to the KDE tree.
Index: ltconfig
===
RCS file: /home/kde/kde-common/admin/ltconfig,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- ltconfig1998/12/16 13:55:25 1.14
+++ ltconfig1999/01/21 07:17:16 1.15
@@ -1209,6 +1209,15 @@
hardcode_shlibpath_var=no
;;
+ # FreeBSD 4, uses gcc -shared to do shared libraries, for the time being.
+ freebsd4*)
+archive_cmds='$CC -shared -o $lib$libobjs$deplibs'
+hardcode_libdir_flag_spec='-R$libdir'
+hardcode_direct=yes
+hardcode_minus_L=no
+hardcode_shlibpath_var=no
+;;
+
hpux9*)
archive_cmds='$rm $objdir/$soname~$LD -b +s +b $install_libdir -o
$objdir/$soname$libobjs$deplibs~test $objdir/$soname = $lib || mv
$objdir/$soname $lib'
hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
@@ -1606,7 +1615,7 @@
shlibpath_var=PATH
;;
-freebsd2* | freebsd3*)
+freebsd2* | freebsd3* | freebsd4*)
objformat=`test -x /usr/bin/objformat /usr/bin/objformat || echo aout`
version_type=freebsd-$objformat
library_names_spec='${libname}${release}.so$versuffix $libname.so'
- alex
| Contrary to popular belief, penguins are not the salvation of modern |
| technology. Neither do they throw parties for the urban proletariat. |
| Powered by FreeBSDhttp://www.freebsd.org/ |
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
kernel 4, userland 3 = trouble?
I build a current-4 kernel on gina and installed it on arnold. Then I added 32MB ram. nfs'mounted gina's /usr/src and /usr/obj on arnold, and tried an installworld. But I got random reboots, I guess it was signal 11, segmentation fault. Could it be because I had a current-4 kernel, but a stable-3 userland? Or is it just bad ram? I downgraded /usr/src to stable-3, and made another kernel for arnold. I also removed the 32MB, leaving another 32 MB. Now I could do a complete installworld without errors. Which is the likely cause of the errors? bad ram or kernel and userland out of sync the wrong way? Leif To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: dirty fs after apm power off
This is what I also thought. But how do I turn off write caching on IDE disks. I know how to do on SCSI bit (mode page 8 byte 2 bit 2 clear), but I have absolutely no clue how this can be achieved on IDE disks. I normally turn off write caching on all drives I install. The drive shouldn't shuffle the carefully sorted file system blocks. Daniel probably the drive needs write-caching turned off... On Sat, 23 Jan 1999, D. Rock wrote: I have noticed this behaviour on at least one machine. If I shutdown the machine with apm power off, the filesystem is dirty and has to been checked on the next reboot. It seems, the power is cut too fast. I don't have any problems with reboots. It seems the drive doesn't have the time to write the superblock back to disk. I simply put a DELAY(400) in the apm_power_off() routine and the problem fades away. Any thoughts on doing this a configurable option? It doesn't break anything, it only takes a few seconds longer for the machine to power off. The drive is a Maxtor Diamond Max (90432D2) 4GB IDE drive in an Asus SP98 board. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: dirty fs after apm power off
D. Rock wrote: This is what I also thought. But how do I turn off write caching on IDE disks. I know how to do on SCSI bit (mode page 8 byte 2 bit 2 clear), but I have absolutely no clue how this can be achieved on IDE disks. I normally turn off write caching on all drives I install. The drive shouldn't shuffle the carefully sorted file system blocks. Some BIOSes have an APM setting that forces a delay before turning the power supply off. -- JMA --- José Mª Alcaide | mailto:j...@we.lc.ehu.es Universidad del PaÃs Vasco | http://www.we.lc.ehu.es/~jose Dpto. de Electricidad y Electrónica | Facultad de Ciencias - Campus de Lejona | Tel.: +34-946012479 48940 Lejona (Vizcaya) - SPAIN | Fax: +34-944858139 --- Go ahead... make my day. - H. Callahan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
ack! LaTeX?
Do any of the LaTeX ports work anymore, or do I have something
grubby in my ${LOCALBASE}?
I tried latex, teTeX, and teTeX-beta... each had one problem
or another. latex can't be fetched, teTeX-beta can't build,
and teTeX doesn't work after being installed.
Jacques Vidrine / n...@nectar.com / nec...@freebsd.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
$150K+ Per Year / Home-Based / NOT MLM
We are sorry if you received this email in error. To be removed from this list please send an email to the address below. mailto:getl...@tfz.net; $ ENTREPRENEURS $ *Tired of working for someone else and getting paid what they feel you're worth? *Tired of the get-rich-quick $5 fantasy programs? *Tired of the MLM dream scene? *Looking for a legitimate home-based enterprise that can generate you $10k-$20k+ monthly? THEN CHECK THIS OUT!!! 90% profit on all sales that pay you from $1250-$6250 per sale No personal selling or convince me tactics involved No special skills or equipment required or inventory to keep Complete information system in place does the explaining for you Free-enterprise in its purest form, not MLM or franchise Full training and support in an environment of upmost integrity Exceptional products, not vitamins, lotions, and potions Lead generation system that brings qualified prospects to you Multiple 6 figure income realistically attainable in 1st year 2 to 3 year retirement program... PERIOD! This program is all about money... how to make it, how to keep it, and how to make it work for you. CALL NOW!!! 1-888-316-1204 Leave your name and number. After a brief interview, I will get you all the information you need to make your own relaxed and intelligent decision about your future. (Serious inquiries only please) J. Hampton To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! New swapper and VM changes have been committed to -4.x
On Sat, Jan 23, 1999 at 10:46:30AM +, Adrian Wontroba wrote: I've tried, with sources cvsupped at 0600 22/11/1999 UTC. On a 128MB ! 0 (sigh, up too late) -- Adrian Wontroba To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Device Framework Overview
Is this the first page of a 20 page document giving examples and pointers? :-) On Sat, 23 Jan 1999, Doug Rabson wrote: I've just posted a brief overview of the new device system in FreeBSD at http://www.freebsd.org/~dfr/devices.html. The information content is fairly small but it might help someone who is trying to understand the source code. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd.Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Device Framework Overview
On Sat, 23 Jan 1999, Julian Elischer wrote: Is this the first page of a 20 page document giving examples and pointers? :-) No.. Its just an overview at the moment (it started off as some email explaining roughly how the thing fits together). Maybe I'll find the time to write some more sometime. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! New swapper and VM changes have been committed to -4.x
:swapinfo output looks a little odd: : : :Device 1K-blocks UsedAvail Capacity Type :/dev/da0s2b19660819372 17710810%Interleaved :/dev/da3b 19670419140 17743610%Interleaved :Total 393056 3930560 100% : :The totals don't appear to add up. Make sure your /usr/src/lib/libkvm is updated. Also update /usr/src/include/kvm.h. Then update and recompile top, systat, and pstat. -Matt :-- :Adrian Wontroba : :To Unsubscribe: send mail to majord...@freebsd.org :with unsubscribe freebsd-current in the body of the message : To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
On Sun, 24 Jan 1999, Peter Wemm wrote: [..] Oh, one other thing that occurred to me.. Under 4.0-current, I regularly (ie: within 30 seconds of boot) get if_de tranmitter underflows. My console corruption was happening at the instant that de0 was being configured with ifconfig. exmh is running to a remote display over that de0 interface. Here too... pretty quickly after boot on a SMP machine (current as of Jan 12) that pushes quite a bit of traffic, the following messages appear: de0: abnormal interrupt: transmit underflow (raising TX threshold to 96|256) de0: abnormal interrupt: transmit underflow (raising TX threshold to 128|512) de0: abnormal interrupt: transmit underflow (raising TX threshold to 160|1024) The card is: de0: Digital 21140A Fast Ethernet rev 0x22 int a irq 16 on pci0.12.0 de0: 21140A [10-100Mb/s] pass 2.2 de0: address 00:c0:f0:1f:5d:0d de0: enabling Full Duplex 100baseTX port Actually a Kingston clone, not a real DEC (so 1/5th of the price - but the receiver doesn't go audibly *click* when it's autosensing). So far I've gotten this message once: de0: abnormal interrupt: transmit underflow (switching to store-and-forward mode) Any harm in them, or can I safely ignore them? Would it be a good idea to raise the TX threshold by default, if only to avoid the messages? It's plugged into a Catalyst switch, if it makes any difference... -- Niels. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
Yes, we're working on it in a sub-group. Since the panic message is a new one -- it's one I added that never existed in -3.x, it is possible that the bug is not related to my VM stuff but related to something else going on. I've found a number of other bugs in the greater VM system which I am comitting fixes for, *BUT* I don't think any of them are related to this particular panic. I am also comitting some very strict KASSERT checking to try to catch the problem earlier. Everyone running 4.x kernels should add the following options to your kernel config: options INVARIANTS options INVARIANT_SUPPORT -Matt Matthew Dillon dil...@backplane.com :On Sun, 24 Jan 1999, Peter Wemm wrote: : :[..] : Oh, one other thing that occurred to me.. Under 4.0-current, I regularly : (ie: within 30 seconds of boot) get if_de tranmitter underflows. My : console corruption was happening at the instant that de0 was being : configured with ifconfig. exmh is running to a remote display over that : de0 interface. : :Here too... pretty quickly after boot on a SMP machine (current as of Jan :12) that pushes quite a bit of traffic, the following messages appear: : :de0: abnormal interrupt: transmit underflow (raising TX threshold to 96|256) :de0: abnormal interrupt: transmit underflow (raising TX threshold to 128|512) :de0: abnormal interrupt: transmit underflow (raising TX threshold to 160|1024) : :The card is: : :de0: Digital 21140A Fast Ethernet rev 0x22 int a irq 16 on pci0.12.0 :de0: 21140A [10-100Mb/s] pass 2.2 :de0: address 00:c0:f0:1f:5d:0d :de0: enabling Full Duplex 100baseTX port : :Actually a Kingston clone, not a real DEC (so 1/5th of the price - but the :receiver doesn't go audibly *click* when it's autosensing). : :So far I've gotten this message once: : :de0: abnormal interrupt: transmit underflow (switching to store-and-forward mode) : :Any harm in them, or can I safely ignore them? Would it be a good idea to :raise the TX threshold by default, if only to avoid the messages? :It's plugged into a Catalyst switch, if it makes any difference... : : : -- Niels. : : :To Unsubscribe: send mail to majord...@freebsd.org :with unsubscribe freebsd-current in the body of the message : To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
fetch
Hey guys: I thought I'd put this up for discussion here. Does anyone have objections to changing the default behavior for how the long password for fetch is chosen? Most FTP servers which do check the password given for an anonymous login, expect either 'username@' or 'usern...@valid.fqdn'. If the password is given just simply as 'usern...@host', login is refused. Can we do one of the following changes? a) make 'username@' the default b) leave 'usern...@domain' the default, as long as it can be verified to be a valid domain name, otherwise make it 'username@' Either way, the default could be overwritten by FTP_PASSWORD. Sure, I could achieve the above that way, too. However, it appears to make more sense to chose the described default than the current default, given the way anonymous FTP works. Please comment... Cheers, Chris -- Economics is extremely useful as a form of employment for economists. -- John Kenneth Galbraith [Disclaimer: I speak for myself and my views are my own and not in any way to be construed as the views of BellSouth Corporation. ] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
:Here too... pretty quickly after boot on a SMP machine (current as of Jan :12) that pushes quite a bit of traffic, the following messages appear: : :de0: abnormal interrupt: transmit underflow (raising TX threshold to 96|256) :de0: abnormal interrupt: transmit underflow (raising TX threshold to 128|512) :de0: abnormal interrupt: transmit underflow (raising TX threshold to 160|1024) : :The card is: : :de0: Digital 21140A Fast Ethernet rev 0x22 int a irq 16 on pci0.12.0 :de0: 21140A [10-100Mb/s] pass 2.2 :de0: address 00:c0:f0:1f:5d:0d :de0: enabling Full Duplex 100baseTX port Three people getting these panics, three people with DEC ethernet cards. Random complaints about card during ifconfig: speaker goes click, console gets junked, etc etc etc. Is there anyone having this panic who does NOT have a DEC ethernet card ? I still don't think the card is causing the problem, but it would be nice if we could rule it out. GRIN -Matt : -- Niels. Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
Here too... pretty quickly after boot on a SMP machine (current as of Jan 12) that pushes quite a bit of traffic, the following messages appear: de0: abnormal interrupt: transmit underflow (raising TX threshold to 96|256) [..] Three people getting these panics, three people with DEC ethernet cards. Random complaints about card during ifconfig: speaker goes click, console gets junked, etc etc etc. Actually, I haven't had the console of that SMP machine junked yet, but that's because there is no console worth speaking of. Previous reboot was because processes like tail(1) only appeared to hang, unkillable except by -9, and after attaching monitor and keyboard, upon pressing Enter at a login: prompt the cursor would only advance a line once... But that was a week ago, and it's a *busy* news server (that's not hitting swap), I was just curious about the error messages from the de driver. -- Niels. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
:But that was a week ago, and it's a *busy* news server (that's not hitting :swap), I was just curious about the error messages from the de driver. : : -- Niels. The transmit underflow messages: de0: abnormal interrupt: transmit underflow (raising TX threshold to 96|256) de0: abnormal interrupt: transmit underflow (raising TX threshold to 128|512) de0: abnormal interrupt: transmit underflow (raising TX threshold to 160|1024) can typically be ignored. It simply means that the DEC card has too small a transmit FIFO and is getting DMA underflows. Stupid card. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
On Sat, 23 Jan 1999, Matthew Dillon wrote: Yes, we're working on it in a sub-group. Since the panic message is a new one -- it's one I added that never existed in -3.x, it is possible that the bug is not related to my VM stuff but related to something else going on. I've found a number of other bugs in the greater VM system which I am comitting fixes for, *BUT* I don't think any of them are related to this particular panic. I am also comitting some very strict KASSERT checking to try to catch the problem earlier. Everyone running 4.x kernels should add the following Ahem, would you kindly define 'everyone'? options to your kernel config: options INVARIANTS options INVARIANT_SUPPORT -Matt Matthew Dillon dil...@backplane.com :On Sun, 24 Jan 1999, Peter Wemm wrote: : :[..] : Oh, one other thing that occurred to me.. Under 4.0-current, I regularly : (ie: within 30 seconds of boot) get if_de tranmitter underflows. My : console corruption was happening at the instant that de0 was being : configured with ifconfig. exmh is running to a remote display over that : de0 interface. : :Here too... pretty quickly after boot on a SMP machine (current as of Jan :12) that pushes quite a bit of traffic, the following messages appear: : :de0: abnormal interrupt: transmit underflow (raising TX threshold to 96|256) :de0: abnormal interrupt: transmit underflow (raising TX threshold to 128|512) :de0: abnormal interrupt: transmit underflow (raising TX threshold to 160|1024) : :The card is: : :de0: Digital 21140A Fast Ethernet rev 0x22 int a irq 16 on pci0.12.0 :de0: 21140A [10-100Mb/s] pass 2.2 :de0: address 00:c0:f0:1f:5d:0d :de0: enabling Full Duplex 100baseTX port : :Actually a Kingston clone, not a real DEC (so 1/5th of the price - but the :receiver doesn't go audibly *click* when it's autosensing). : :So far I've gotten this message once: : :de0: abnormal interrupt: transmit underflow (switching to store-and-forward mode) : :Any harm in them, or can I safely ignore them? Would it be a good idea to :raise the TX threshold by default, if only to avoid the messages? :It's plugged into a Catalyst switch, if it makes any difference... : : : -- Niels. : : :To Unsubscribe: send mail to majord...@freebsd.org :with unsubscribe freebsd-current in the body of the message : To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
: : I am also comitting some very strict KASSERT checking to try to catch : the problem earlier. Everyone running 4.x kernels should add the following : :Ahem, would you kindly define 'everyone'? Anyone, everyone, everybody, all ... any individual using the -4.x kernels needs to understand the highly experimental nature of said kernels. Turning on INVARIANTS is just plain smart. For many reasons but I will give you the top two: * The sanity checks could save your disks when someone commits a major mistake. * The sanity checks make it easier for bugs to be found and fixed when they do occur. -4.x is just getting on its feet, nobody should be shipping product with it for a while ( if they are, they are insane ). -Matt Matthew Dillon dil...@backplane.com : options to your kernel config: : : options INVARIANTS : options INVARIANT_SUPPORT To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
Matthew Dillon wrote: :But that was a week ago, and it's a *busy* news server (that's not hitting :swap), I was just curious about the error messages from the de driver. : : -- Niels. The transmit underflow messages: de0: abnormal interrupt: transmit underflow (raising TX threshold to 96|256) de0: abnormal interrupt: transmit underflow (raising TX threshold to 128|512) de0: abnormal interrupt: transmit underflow (raising TX threshold to 160|1024 ) can typically be ignored. It simply means that the DEC card has too smal l a transmit FIFO and is getting DMA underflows. Stupid card. As I understand it, what's happening is that it's reacting to pci bus congestion by raising the preread threshholds. It degenerates to fetching the entire frame into on-card (or chip) memory before beginning transmission. On my system I can understand it, it's a 2xP5 with a shared L2 cache on a Neptune chipset - something that isn't known for speed. Once you get two processors hammering the system bus, *plus* mix in an EISA scsi controller, I could well imagine the memory bus getting thrashed. I'm not sure how to read the messages. Looking at the if_pn driver as well, it looks like both start with a FIFO threshold of 72 bytes. I think that '160|1024' (for example) means start transmitting when the FIFO has fetched 160 bytes and don't stop fetching unless we hit 1024 bytes in the fifo. Store and forward mode (I believe) is a degenerate case where it fetches the entire packet into the buffer before beginning transmission. Bill Paul's if_pn driver doesn't react to an underflow at all.. it stays at 72/128 permanently. For what it's worth, the de cards are the only ones I've found that can work at all on this system at 100Mbit. The realtek 8139 cards (cheap!) went belly-up on the spot, no suprise there. I don't have an fxp card to test. -Matt Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
2Re: panic: found dirty cache page 0xf046f1c0
On Sat, 23 Jan 1999, Matthew Dillon wrote: i have 'ed' driver and mine blows up as well. :Here too... pretty quickly after boot on a SMP machine (current as of Jan :12) that pushes quite a bit of traffic, the following messages appear: : :de0: abnormal interrupt: transmit underflow (raising TX threshold to 96|256) :de0: abnormal interrupt: transmit underflow (raising TX threshold to 128|512) :de0: abnormal interrupt: transmit underflow (raising TX threshold to 160|1024) : :The card is: : :de0: Digital 21140A Fast Ethernet rev 0x22 int a irq 16 on pci0.12.0 :de0: 21140A [10-100Mb/s] pass 2.2 :de0: address 00:c0:f0:1f:5d:0d :de0: enabling Full Duplex 100baseTX port Three people getting these panics, three people with DEC ethernet cards. Random complaints about card during ifconfig: speaker goes click, console gets junked, etc etc etc. s there anyone having this panic who does NOT have a DEC ethernet card ? I still 04don't think the card is causing the problem, but it wouldif we could rule it out. GRIN :( FreeBSD bright.reserved 4.0-CURRENT FreeBSD 4.0-CURRENT #2: Sat Jan 23 20:55:25 EST 1999 perl...@bright.reserved:/usr/src/sys/compile/bright i386 ~ # ifconfig -a ed1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 192.168.2.20 netmask 0xff00 broadcast 192.168.2.255 ether 00:00:21:4e:29:c3 tun0: flags=8010POINTOPOINT,MULTICAST mtu 1500 sl0: flags=c012BROADCAST,POINTOPOINT,LINK2,MULTICAST mtu 552 ppp0: flags=8010POINTOPOINT,MULTICAST mtu 1500 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00 Make release made my machine reboot, i hooked up a serial consol to it, i'll show my backtrace/etc if it happens again... wh00ps :) it just did: (this is by hand) -- panic: found dirty cache page 0xf047ae60 Debugger(panic) Stopped at Debugger+0x37: movl$0, in_Debugger db c syncing disks... panic: found dirty cache page 0xf047ae60 Debugger(panic) Stopped at Debugger+0x37: movl$0, in_Debugger db c -- i'm enabling crash dumps, i hope to god it doesn't eat my machine again. btw, i'm hardly 'stressing' this machine it's a k6-233+96ram and i'm running X and doing a 'make release' Is it safe to enable crashdumps on IDE disks yet? -Alfred -Matt : -- Niels. Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ack! LaTeX?
Hi, I tried latex, teTeX, and teTeX-beta... each had one problem or another. latex can't be fetched, teTeX-beta can't build, and teTeX doesn't work after being installed. How is teTeX not working? I'm using a month or so old version of -current (back in the 3.0 days) on my home machine and teTeX works fine there. Brett ** Brett Taylorbr...@peloton.physics.montana.edu http://peloton.physics.montana.edu/brett/ love isn't someplace that we fall, it's something that we do To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: 2Re: panic: found dirty cache page 0xf046f1c0
: :i have 'ed' driver and mine blows up as well. : :panic: found dirty cache page 0xf047ae60 :Debugger(panic) Ok, so much for if_de being the cause. BTW, for anybody who doesn't want to wait for us to find the bug, you can comment out the MADV_FREE code and that should put a stop to it. The MADV_FREE code isn't broken, but it seems to cause the bug to occur which is why *I* haven't commented it out - I'd rather find the bug. Also, update your kernel trees and turn on the INVARIANTS options: options INVARIANTS options INVARIANT_SUPPORT -Matt Matthew Dillon dil...@backplane.com : :btw, i'm hardly 'stressing' this machine it's a k6-233+96ram and :i'm running X and doing a 'make release' : :Is it safe to enable crashdumps on IDE disks yet? : :-Alfred I don't know. I wasn't aware that there was a problem with crash dumps on ide disks. There shouldn't be. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Death to LKM screen savers? (was: Re: HEADS UP: i386 a.out LKM support now an option..)
What if we declare death to LKM screen savers and remove them from the source tree? After all KLD screen savers are working well. Kazu As of a few minutes ago, I committed some changes that: 1: make the LKM code use the common VFS and syscall registration routines 2: make an 'options LKM' option. 3: build an 'lkm' loadable kld module This means that if you are still using an a.out kernel and are loading LKM's specifically, you either need to add 'options LKM' to your config, or do a 'kldload lkm' to load the /dev/lkm support routines. [...] However, the thought has occurred on many occasions that it might be an idea to make a stand on this and remove the LKM build support. It will clean up a few interfaces. If this doesn't happen for 3.1, it's definately on my agenda for after the branch. Converting the common LKM's to kld modules is pretty easy, and even the ones with custom load/unload code are not too hard. I'd be interested to get a feeling for whether this should be done for 3.1 or later. (Remember, OSS have a KLD version now for 3.0). To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
:On my system I can understand it, it's a 2xP5 with a shared L2 cache on a :Neptune chipset - something that isn't known for speed. Once you get two :processors hammering the system bus, *plus* mix in an EISA scsi :controller, I could well imagine the memory bus getting thrashed. When we started throwing together Duel-P-II machines, we basically had to throw away our DEC chipset cards... I think that the DEC chip cards, at least the older ones, have serious PCI spec bugs that cause them to operate incorrectly on duel-cpu machines when more then one cpu is populated. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: 2Re: panic: found dirty cache page 0xf046f1c0
On Sat, 23 Jan 1999, Matthew Dillon wrote: : :i have 'ed' driver and mine blows up as well. : :panic: found dirty cache page 0xf047ae60 :Debugger(panic) Ok, so much for if_de being the cause. BTW, for anybody who doesn't want to wait for us to find the bug, you can comment out the MADV_FREE code and that should put a stop to it. The MADV_FREE code isn't broken, but it seems to cause the bug to occur which is why *I* haven't commented it out - I'd rather find the bug. Also, update your kernel trees and turn on the INVARIANTS options: options INVARIANTS options INVARIANT_SUPPORT cvsup'd and added, i'm going to run the code for a bit hopefully to get you some output from the INVARIANTS. :Is it safe to enable crashdumps on IDE disks yet? I don't know. I wasn't aware that there was a problem with crash dumps on ide disks. There shouldn't be. Last 3 times i enabled it, it dumped on the wrong partition because it got confused about LBA mode, anyone have a suggestion to test to make sure it won't dump on my /usr instead of swap? (i don't have LBA enabled in my IDE disk flags 0xe0ffe0ff) -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Death to LKM screen savers? (was: Re: HEADS UP: i386 a.out LKM support now an option..)
Kazutaka YOKOTA yok...@zodiac.mech.utsunomiya-u.ac.jp writes: What if we declare death to LKM screen savers and remove them from the source tree? After all KLD screen savers are working well. Sure. I don't see any reason to keep them. I'll do the deed. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Failure to make buildworld on RELENG_3
In article 36aa271c.1bcfa...@visi.com,
Thomas T. Veldhouse ve...@visi.com wrote:
It seems to be the same problem we have been having with current.
Should it be crypt stuff be backed out of here as well?
=== libpam/modules/pam_radius
=== libpam/modules/pam_skey
=== libpam/modules/pam_tacplus
=== libpam/modules/pam_unix
=== libpam/libpam
ld -o pam_static_modules.o -r -Bforcearchive pam_static.o
../modules/pam_cleartext_pass_ok/libpam_cleart
ext_pass_ok.a ../modules/pam_kerberosIV/libpam_kerberosIV.a
../modules/pam_radius/libpam_radius.a ../mod
ules/pam_skey/libpam_skey.a ../modules/pam_tacplus/libpam_tacplus.a
../modules/pam_unix/libpam_unix.a
../modules/pam_cleartext_pass_ok/libpam_cleartext_pass_ok.a(pam_cleartext_pass_ok.o):
Definition of symb
ol `_pam_sm_authenticate' (multiply defined)
...
Did you use -DNOCLEAN in your make world? (Or is it in your
/etc/make.conf file?) It looks like it. Otherwise, why did nothing
get built in the various modules subdirectories.
And are you sure all of your sources are up to date?
I tested this stuff with a full make world on a -current ELF system.
In addition, I tested libpam and login for all combinations of
{{aout,elf}{dynamic linking,NOSHARED=yes}}. The relevant sources are
identical in the RELENG_3 branch, except for the RCS $Id$ strings of
course.
I'd recommend doing a make clean cleandepend in src/lib/libpam
and trying again.
John
--
John Polstra j...@polstra.com
John D. Polstra Co., Inc.Seattle, Washington USA
Nobody ever went broke underestimating the taste of the American public.
-- H. L. Mencken
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Death to LKM screen savers? (was: Re: HEADS UP: i386 a.out LKM support now an option..)
Dag-Erling Smorgrav d...@flood.ping.uio.no writes: Kazutaka YOKOTA yok...@zodiac.mech.utsunomiya-u.ac.jp writes: What if we declare death to LKM screen savers and remove them from the source tree? After all KLD screen savers are working well. Sure. I don't see any reason to keep them. I'll do the deed. Doh, they were already axed by sos in late December. 'cvs co src/lkm' still creates directories for them though. I'm sure someone with more CVS experience than me will be able to explain why :) DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Bootstrap loader problems on CURRENT
Pascal Hofstee wrote: As of Today's 4.0-CURRENT My system Halts on boot-up after the BTX Driver showing my BIOS-drives, with the following message: FreeBSD/i386 bootstrap loader, Revision 0.2 (dae...@shadowmere. etc...) ficlExecFD: Error at line 1 then it shows a lot of Register-information with the message System halted this is when trying to execute boot/loader When I am fast enough on the Boot-Manager Boot-prompt .. I am able to simply type /kernel instead of 0:wd(0,a)/boot/loader and my System Will boot the 4.0-kernel and run fine. This is most likely my fault. The only place where ficlExecFD gets executed is during initialization, when loading /boot/boot.4th. What do you have there? I suppose you have no trouble booting if you rename that file, correct? I suspect you have a builtin command (those shown by ?) in the first line of that file, and with my recent changes, these commands have evidenced a bug in ficl, which I have been delaying dealing with until I get an answer from ficl's author. If that file is essential to you (and it's contents cannot be placed in loader.rc), I'll send you a patch that should get you going, for now. BTW, ficl's builtin command behavior got changed. I was avoiding bugging Mike to up loader's version (which is now available with loader_version environment?) until I could change include to process fourth source, instead of just builtins, and *that* depends on the above mentioned bug getting fixed. -- Daniel C. Sobral(8-DCS) d...@newsguy.com If you sell your soul to the Devil and all you get is an MCSE from it, you haven't gotten market rate. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Death to LKM screen savers? (was: Re: HEADS UP: i386 a.out LKM support now an option..)
In article xzpyamtnwl0@flood.ping.uio.no, Dag-Erling Smorgrav d...@flood.ping.uio.no wrote: Doh, they were already axed by sos in late December. 'cvs co src/lkm' still creates directories for them though. I'm sure someone with more CVS experience than me will be able to explain why :) Always use -P when you check out sources: cvs co -P src/lkm. And when you update sources already checked out, use cvs upd -Pd. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Nobody ever went broke underestimating the taste of the American public. -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Death to LKM screen savers? (was: Re: HEADS UP: i386 a.out LKM support now an option..)
On Sat, 23 Jan 1999, John Polstra wrote: In article xzpyamtnwl0@flood.ping.uio.no, Dag-Erling Smorgrav d...@flood.ping.uio.no wrote: Doh, they were already axed by sos in late December. 'cvs co src/lkm' still creates directories for them though. I'm sure someone with more CVS experience than me will be able to explain why :) Always use -P when you check out sources: cvs co -P src/lkm. And when you update sources already checked out, use cvs upd -Pd. cvs up (not cvsup) takes me a LONG time to execute, i've been using '-z3' for comppression because i'm on dialup, is this ok with you guys? (it doesn't help much though...) cvs -z3 up -Pd src i'm also using ssh for transport as rlogin doesn't work well for me. -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: 2Re: panic: found dirty cache page 0xf046f1c0
On Sat, 23 Jan 1999, Matthew Dillon wrote: : :i have 'ed' driver and mine blows up as well. : :panic: found dirty cache page 0xf047ae60 :Debugger(panic) Ok, so much for if_de being the cause. BTW, for anybody who doesn't want to wait for us to find the bug, you can comment out the MADV_FREE code and that should put a stop to it. The MADV_FREE code isn't broken, but it seems to cause the bug to occur which is why *I* haven't commented it out - I'd rather find the bug. Also, update your kernel trees and turn on the INVARIANTS options: options INVARIANTS options INVARIANT_SUPPORT -Matt Matthew Dillon dil...@backplane.com : :btw, i'm hardly 'stressing' this machine it's a k6-233+96ram and :i'm running X and doing a 'make release' : :Is it safe to enable crashdumps on IDE disks yet? : :-Alfred I don't know. I wasn't aware that there was a problem with crash dumps on ide disks. There shouldn't be. Crashdumps on IDE disks never stopped working for me. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Death to LKM screen savers? (was: Re: HEADS UP: i386 a.out LKM support now an option..)
On Sat, 23 Jan 1999, John Polstra wrote: In article xzpyamtnwl0@flood.ping.uio.no, Dag-Erling Smorgrav d...@flood.ping.uio.no wrote: Doh, they were already axed by sos in late December. 'cvs co src/lkm' still creates directories for them though. I'm sure someone with more CVS experience than me will be able to explain why :) Always use -P when you check out sources: cvs co -P src/lkm. And when you update sources already checked out, use cvs upd -Pd. cvs up (not cvsup) takes me a LONG time to execute, i've been using '-z3' for comppression because i'm on dialup, is this ok with you guys? (it doesn't help much though...) cvs -z3 up -Pd src i'm also using ssh for transport as rlogin doesn't work well for me. There's no point using ssh and -z3, just compress the ssh session. Also, you should try running in readonly (cvs -R) mode - locking is expensive. Finally, why not just use a local repository you weenie? 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: 2Re: panic: found dirty cache page 0xf046f1c0
On Sat, Jan 23, 1999 at 06:51:54PM -0800, Matthew Dillon wrote: : :btw, i'm hardly 'stressing' this machine it's a k6-233+96ram and :i'm running X and doing a 'make release' : :Is it safe to enable crashdumps on IDE disks yet? : :-Alfred I don't know. I wasn't aware that there was a problem with crash dumps on ide disks. There shouldn't be. FWIW, I've had crash dumps enabled on my IDE-based system for a long time, and never had a problem with them. -- ++ | Lee Cremeans -- Manassas, VA, USA (WakkyMouse on DALnet and WTnet)| |lcrem...@tidalwave.net| http://st-lcremean.tidalwave.net/~lee | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: dirty fs after apm power off
I have noticed this behaviour on at least one machine. If I shutdown the machine with apm power off, the filesystem is dirty and has to been checked on the next reboot. It seems, the power is cut too fast. I don't have any problems with reboots. It seems the drive doesn't have the time to write the superblock back to disk. I simply put a DELAY(400) in the apm_power_off() routine and the problem fades away. Any thoughts on doing this a configurable option? It doesn't break anything, it only takes a few seconds longer for the machine to power off. The drive is a Maxtor Diamond Max (90432D2) 4GB IDE drive in an Asus SP98 board. Ok, simple programming project for you. Find a suitable location, and add a SYSCTL node (eg. kern.shutdown.poweroff_delay) and SYSINIT to register an at_shutdown function that delays that long just before the power-off routines are called. Test it, file a PR and gimme the PR number. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: found dirty cache page 0xf046f1c0
I've committed one bug fix to the 'found dirty cache page' bug -- turns out vm_map_split() was the culprit, renaming pages without removing them from PQ_CACHE. The bug was introduced in -3.0, and hit the KASSERT() I put in -4.x. I've committed a general inlining of 'changing the page dirty status to VM_PAGE_BITS_ALL' and put a sanity check in the inline. If this problem occurs again, you will get a different panic. One of: vm_page_dirty: page in cache! vm_page_busy: page already busy!!! vm_page_wakeup: page not busy!!! If your box drops into DDB, please get a backtrace and report it to the list or to me and we should be able to track down any remaining dirty-pages-in-PQ_CACHE bugs. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Death to LKM screen savers? (was: Re: HEADS UP: i386 a.out LKM support now an option..)
On Sat, 23 Jan 1999, Mike Smith wrote: Always use -P when you check out sources: cvs co -P src/lkm. And when you update sources already checked out, use cvs upd -Pd. cvs up (not cvsup) takes me a LONG time to execute, i've been using '-z3' for comppression because i'm on dialup, is this ok with you guys? (it doesn't help much though...) cvs -z3 up -Pd src i'm also using ssh for transport as rlogin doesn't work well for me. There's no point using ssh and -z3, just compress the ssh session. Also, you should try running in readonly (cvs -R) mode - locking is expensive. Finally, why not just use a local repository you weenie? 8) Because, certain other weenies :) have web pages up on http://www.freebsd.org/handbook that don't explain how to do this, and aren't very clear on the topics that ARE discussed. :) so can i overlay my cvsup and my cvs trees somehow? this would be ideal. -Alfred why did i buy that sparc again? Perlstein To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: 2Re: panic: found dirty cache page 0xf046f1c0
On Sun, 24 Jan 1999, Brian Feldman wrote: :btw, i'm hardly 'stressing' this machine it's a k6-233+96ram and :i'm running X and doing a 'make release' : :Is it safe to enable crashdumps on IDE disks yet? : :-Alfred I don't know. I wasn't aware that there was a problem with crash dumps on ide disks. There shouldn't be. Crashdumps on IDE disks never stopped working for me. gee, that's nice to know. Brian, search the -current lists about this, there was/is some confusion in the driver about LBA. Basically, LBA would work at ALL times for the disk, except during a crash dump where it would use those addresses as CHS or something and cream one of my partitions. This lovely affected 2 seperate machines. -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
dummynet causes crash?
.(02:36:11)(r...@bright.reserved) ipfw add pipe 1 ip from server to cvsup.freebsd.org (long pause i assume DNS) 0 pipe 1 ip from 192.168.2.20 to 198.104.92.71 .(02:36:26)(r...@bright.reserved) ~perlsta # ipfw pipe 1 config bw 18Kbit/s delay 20ms .(02:36:45)(r...@bright.reserved) ~perlsta # ipfw l 00100 pipe 1 ip from 192.168.2.20 to 198.104.92.71 65535 allow ip from any to any .(02:36:52)(r...@bright.reserved) ~perlsta # *BAM* Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc116 fault code = supervisor read, page not present ip = 0x8:0xf0193f37 sp = 0x10:0xf028409c fp = 0x10:0xf02840c8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interupt enabled, resume, IOPL = 0 current process = idle interupt mask = net tty kernel: type 12 trap, code=0 Stopped at ether_output+0x4b: testb $0x1,0x38(%ebx) the only thing i can think of is that dummynet doesn't like not being told if a pipe is 'in' or 'out' :/ my ether card is a: ed card, a 'realteck 8029' Alfred Perlstein - Programmer, HotJobs Inc. - www.hotjobs.com -- There are operating systems, and then there's FreeBSD. -- http://www.freebsd.org/4.0-current To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
