Re: localhost adress
Hi, Maybe the latest commit by 'tmm' fixes it: tmm 2003/11/22 19:02:00 PST FreeBSD src repository Modified files: sys/netinet in_pcb.c Log: bzero() the the sockaddr used for the destination address for rtalloc_ign() in in_pcbconnect_setup() before it is filled out. Otherwise, stack junk would be left in sin_zero, which could cause host routes to be ignored because they failed the comparison in rn_match(). This should fix the wrong source address selection for connect() to 127.0.0.1, among other things. Reviewed by:sam Approved by:re (rwatson) Revision ChangesPath 1.133 +1 -0 src/sys/netinet/in_pcb.c -- Ady (@freebsd.ady.ro) On Sat, 22 Nov 2003, Anthony Ginepro wrote: > Since my last current (FreeBSD renaissance.homeip.net 5.1-CURRENT > FreeBSD 5.1-CURRENT #0: Fri Nov 21 17:49:36 CET 2003), I couldn't > use anymore local network program like mlnet (telnet localhost 4000) > or squid as my adress is 81.65.xx.xx (from my modem-cable) instead > of 127.0.0.1. > > I didn't have this trouble with -CURRENT on the 17th of November. > > Is it related to tcp hostcache or is something weird in my config ? > > Anthony. > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
New technologies in FreeBSD 5.x vs. 4.x
Hi, I'm about to write an article on FreeBSD for PC Magazine Romania and I would like to concentrate on the new technologies introduced in FreeBSD 5.x. Where can I find a (preferrably detailed) list of the new technologies introduced with FreeBSD 5.x ? I would also like, if possible, to get in touch with a few of the main developers that took charge of coding them. Thank you very much, Adrian Penisoara Ady (@freebsd.ady.ro, @rofug.ro) ROFUG founder To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Forgotten locale dirs in etc/mtree/BSD.usr.dist
Hi, There is something strange going on here: these directories do appear in etc/mtree/BSD.usr.dist, but somehow they haven't been created neither by 'mergemaster -p', nor at the beginning of "make installworld". I had to re-run make "installworld" about three times and make two directiories (sr_YU.ISO8859-x) before it could complete without complaining about the missing directories. Could someone please clarify this ? Ady (@freebsd.ady.ro) | An age is called Dark not because the light fails to shine, but | | because people refuse to see it. | | -- James Michener, "Space" | On Wed, 23 Oct 2002, Adrian Penisoara wrote: > Hi, > > Someone (ache it seems) forgot to add the sr_YU.ISO8859-[25] > directories in /usr/share/locale to the BSD.usr.dist mtree file. > > This breaks installworld in -current. Please fix it. > > Thanks, > Ady (@freebsd.ady.ro) > > | An age is called Dark not because the light fails to shine, but | > | because people refuse to see it. | > | -- James Michener, "Space" | > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Forgotten locale dirs in etc/mtree/BSD.usr.dist
Hi, Someone (ache it seems) forgot to add the sr_YU.ISO8859-[25] directories in /usr/share/locale to the BSD.usr.dist mtree file. This breaks installworld in -current. Please fix it. Thanks, Ady (@freebsd.ady.ro) | An age is called Dark not because the light fails to shine, but | | because people refuse to see it. | | -- James Michener, "Space" | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: ALTQ integration developer preview
We have started a "ALTQ integration in FreeBSD" project which is headed towards integrating Mr. Kejiro's ALTQ framework into FreeBSD 5.0-current (and perhaps 4-stable later). The FreeBSD Core Team has been advised and we have received on principle approval. We are looking for help with committing these bits to the CVS tree. Please have a look at the proposed ALTQ package for 5.0-current, which is found here: http://www.rofug.ro/projects/freebsd-altq/altq-freebsd-5.0-current-May14.tar.gz Installation details are found in the README file; for further details consult the documentation referenced below. Please send us any comments you have, your feedback is valuable. ALTQ integration implies some changes in the network drivers code and in the design of the the network queues management. Here is a summary of the ALTQ design document: The BSD systems need better output queueing abstraction to support packet scheduling (e.g., CBQ) or active queue management (e.g., RED). To introduce a new model, we need to convert the existing code to be conformant to the new model. But the problem is that there are too many drivers to convert all at once. This is a proposal that allows incremental transition to the new model. (If we are going to modify the existing drivers, we need to get it right.) The model is designed for ALTQ but it is general enough for other implementations so that we can make the driver conversion once and for all. The new model removes direct references to the fields within ifp->if_snd, and defines the following macros to manipulate ifp->if_snd: IFQ_ENQUEUE(ifq, m, err) IFQ_DEQUEUE(ifq, m) IFQ_POLL(ifq, m) IFQ_PURGE(ifq) IFQ_IS_EMPTY(ifq) The new model also enforces some rules regarding how to use these macros. Another requirement for a driver is to work under rate-limiting. - IFQ_DEQUEUE() could return NULL even when IFQ_IS_EMPTY() is FALSE under rate-limiting. a driver should always check if (m == NULL). - a driver is supposed to call if_start from the tx complete interrupt under late-limiting (in order to trigger the next dequeue). For most drivers, it is a simple task of replacing old-style lines by the corresponding new-style lines, and usually just a few lines need to be modified. But some drivers need more than that. The old-style drivers still work with the original FIFO queue but they cannot take advantage of new queueing disciplines. For locking an output queue to support SMP, ALTQ uses the same model as in FreeBSD-5.0. One restriction is that, if a driver uses poll-and-dequeue, the driver needs to explicitly lock the queue between the poll operation and the dequeue operation. You can find more details here: http://www.csl.sony.co.jp/person/kjc/kjc/software/altq-new-design.txt http://www.csl.sony.co.jp/person/kjc/kjc/software.html#ALTQ Current development is headed by Kenjiro Cho and myself. If you want to join our efforts please subscribe to our mailing list by sending "subscribe" in the body of a message to [EMAIL PROTECTED] Adrian Penisoara Ady (@freebsd.ady.ro, @rofug.ro) ___ | Programming in BASIC causes brain damage. | | (Edsger Wybe Dijkstra)| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic:bremfree with today's current and linux-netscape
Hi, On Mon, 22 Apr 2002, Bruce Evans wrote: > Yes; I forgot to write the clause about it only being equivalent to a > panic if certain options (mainly INVARIANTS) are configured. > > > do see that falloc does lock the file descriptor table too, though --- > > I wonder how it ever worked. > > INVARIANTS causes a check of an assertion that non-recursive locks > like fd_mtx aren't actually misused recursively. The check causes more > panics than the misuse since the misuse is rarely fatal. I may be > missing something since I rarely use INVARIANTS and haven't checked > that it causes the panic deterministically. I think you're talking about the WITNESS option rather than INVARIANTS, that's the one who's at least documented in GENERIC as being responsible for mutex and deadlock checks. And this is somewhat confirmed by the face that an alternative kernel that I built doesn't panic and the difference between them two is that WITNESS is disabled in the non-panicking one. Happy debuggin' Ady (@freebsd.ady.ro) ___ | Programming in BASIC causes brain damage. | | (Edsger Wybe Dijkstra)| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic:bremfree with today's current and linux-netscape
Hi, On Sun, 21 Apr 2002, Kris Kennaway wrote: > On Sun, Apr 21, 2002 at 05:22:20PM +0300, Adrian Penisoara wrote: > > > Panicstring: bremfree: bp 0xc77fb678 not locked > > This isn't the real panic, it's a second panic caused by trying to > sync disks. D'oh... I hope the gdb trace left more marks. > > > How-to-repeat: launch linux-netscape while in X11 > > Are you absolutely sure all kernel modules are up to date? A > sure-fire way to cause panics with linux applications is to use an > out of date linux.ko. Isn't linux.ko supposed to be rebuilt every time the kernel is recompiled ? All kernel builds I do are done together w/ the modules. Or maybe the linux_base port has some code running in kernel (most certainly not) ? Anyway, the strange thing is that now, compiled with ALTQ support, the kernel doesn't panic anymore. Time to sratch the dust back in the old corners... Ady (@freebsd.ady.ro) ___ | Programming in BASIC causes brain damage. | | (Edsger Wybe Dijkstra)| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic:bremfree with today's current and linux-netscape
Hi,
Environment:
FreeBSD xphome.home.ady.ro 5.0-CURRENT FreeBSD 5.0-CURRENT #0:
Sun Apr 21 10:39:36 EEST 2002 i386
XFree86-4.2.0_1,1 (3dfx Velocity 100 graphics card)
gnome-1.4.1b2_2 + sawfish-gnome-1.0.1
linux_base-6.1_1
linux-netscape-communicator-4.79
Panicstring: bremfree: bp 0xc77fb678 not locked
How-to-repeat: launch linux-netscape while in X11
I've attached the stack trace from gdb'ing on the debug kernel file.
I'll keep the core (256Mb) around for a few hours, tell me if you need
further info.
Side note: are those "lock order reversal" meesages something to worry
about ?
Happy panicing,
Ady (@freebsd.ady.ro)
___
| Programming in BASIC causes brain damage. |
| (Edsger Wybe Dijkstra)|
Script started on Sun Apr 21 15:13:31 2002
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD at phsyical address 0x00434000
initial pcb at physical address 0x0031f3a0
panicstr: bremfree: bp 0xc77fb678 not locked
panic messages:
---
panic: recurse
syncing disks... panic: bremfree: bp 0xc77fb678 not locked
Uptime: 4m30s
Dumping 255 MB
ata0: resetting devices .. done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
#1 0xc019ce78 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:346
#2 0xc019d021 in panic (fmt=0xc02bdf5d "bremfree: bp %p not locked")
at /usr/src/sys/kern/kern_shutdown.c:490
#3 0xc01cdd0d in bremfree (bp=0xc77fb678) at /usr/src/sys/kern/vfs_bio.c:619
#4 0xc01cf403 in vfs_bio_awrite (bp=0xc77fb678)
at /usr/src/sys/kern/vfs_bio.c:1593
#5 0xc0178204 in spec_fsync (ap=0xcecfd95c)
at /usr/src/sys/fs/specfs/spec_vnops.c:403
#6 0xc0177df1 in spec_vnoperate (ap=0xcecfd95c)
at /usr/src/sys/fs/specfs/spec_vnops.c:121
#7 0xc024d105 in ffs_sync (mp=0xcdf41200, waitfor=2, cred=0xc7765980,
td=0xc02eb300) at vnode_if.h:441
#8 0xc01dbfb7 in sync (td=0xc02eb300, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:1224
#9 0xc019caba in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:254
#10 0xc019d021 in panic (fmt=0xc02ba6c8 "recurse")
at /usr/src/sys/kern/kern_shutdown.c:490
#11 0xc01b47a8 in witness_lock (lock=0xced36834, flags=8,
file=0xc02b3c40 "/usr/src/sys/kern/kern_descrip.c", line=1114)
at /usr/src/sys/kern/subr_witness.c:533
#12 0xc0195766 in _mtx_lock_flags (m=0xced36834, opts=0,
file=0xc02b3c40 "/usr/src/sys/kern/kern_descrip.c", line=1114)
at /usr/src/sys/kern/kern_mutex.c:314
---Type to continue, or q to quit---
#13 0xc0187203 in falloc (td=0xcec6ea3c, resultfp=0xcecfdaa0,
resultfd=0xcecfdaa8) at /usr/src/sys/kern/kern_descrip.c:1114
#14 0xc0187e3f in fdcheckstd (td=0xcec6ea3c)
at /usr/src/sys/kern/kern_descrip.c:1532
#15 0xc018b306 in execve (td=0xcec6ea3c, uap=0xcecfdcdc)
at /usr/src/sys/kern/kern_exec.c:372
#16 0xcea21aff in ?? ()
#17 0xc028e69b in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077950728, tf_esi = 145923594, tf_ebp = -1077950768,
tf_isp = -825238156, tf_ebx = -1077950728, tf_edx = 151214976,
tf_ecx = -1077950612, tf_eax = 11, tf_trapno = 12, tf_err = 2,
tf_eip = 685394187, tf_cs = 31, tf_eflags = 582, tf_esp = -1077950784,
tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1022
#18 0xc0281a0d in syscall_with_err_pushed ()
Cannot access memory at address 0xbfbfc6d0.
(kgdb) q
Script done on Sun Apr 21 15:13:38 2002
Re: make buildkernel fails - missing header
Hi, Bitten by the same rotten thing; luckily i had the older /usr/include/netinet/if_fddi.h header that I linked to in /usr/src/sys/netinet/if_fddi.h. Looking at the commit logs it seems that the right solution is to patch src/sys/netinet6/nd6.c to #include instead of . It compiles for me ... Ady (@freebsd.ady.ro) ___ | Programming in BASIC causes brain damage. | | (Edsger Wybe Dijkstra)| On Sat, 6 Apr 2002, Chris van der Pennen wrote: > make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | xargs env MKDEP_CPP="cc -E" > CC="cc" mkdep -a -f > .newdep -O -pipe -march=k6 -Wall -Wredundant-decls -Wnested-externs -Wstrict > -prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -ffo > rmat-extensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/de > v -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/s > rc/sys/../include -D_KERNEL -ffreestanding -include > opt_global.h -fno-common -mpreferred-stack-boundary=2 > /usr/src/sys/netinet6/nd6.c:67: netinet/if_fddi.h: No such file or directory > mkdep: compile failed > > after which make fails with error 1. > > find /usr/src | grep fddi turns up a c-file, but no headers. This is with a > cvsup as of a few minutes ago. > > I can attach the script file, if you like. > > Chris van der Pennen > > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Making sure /var/tmp/vi.recover exists during reboot
Hi, On Fri, 14 Jan 2000, Sheldon Hearn wrote: > > > On Fri, 14 Jan 2000 11:07:23 +0100, Trond Endrestol wrote: > > > If I want something preserved between reboots, I'll use /var/otmp > > which is the original /var/tmp or my own ~/tmp directory. > > Do whatever grooves your plumes, just don't expect the startup scripts > to be hacked around to support your disregard for the hier(7) manual > page. :-) Like I said, my hack doesn't contradict what hier(7) sais. It's 100% compatible ;-) ! Seriously now, I don't see why you hate so much the ideea of making some (most ?) people's life easier without breaking what's already been set... If it would really break things up then I would agree with you (indeed, the inital proposed chage, symlinking /var/tmp, is just a dirty workaround). > > Ciao, > Sheldon. > Ady (@warpnet.ro) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Making sure /var/tmp/vi.recover exists during reboot
Hi, On Fri, 14 Jan 2000, Sheldon Hearn wrote: > > > Let's try not to cross-post this any more, eh? I believe the suggested change interests both branches; -chat removed. > > On Fri, 14 Jan 2000 11:55:55 +0200, Adrian Penisoara wrote: > > > Then let's get the other way around (change in /etc/rc): > > No, you're missing the point. /var/tmp is expected to survive reboots. > That's its definition according to the hier(7) manual page. If you > choose to break that functionality, don't expect anyone to make > gratuitous changes to the FreeBSD startup scripts to support your > oddball configuration. :-) > > > And let me notice that the original script assumes existence of this > > directory whereas if I don't run vi I won't get one... > > It does so because of the definition of /var/tmp . > > > I use this small hack to get around the ugly error message I get every > > time I boot with MFS mounted /var/tmp -- suited me well until now. > > You shouldn't be mounting /var/tmp in MFS, because a memory file system > does not survive a reboot -- that's where you've gone wrong. I'm not discussing the definition of /var/tmp ! I just recognise that lots of people (including me) step over this rule (as they don't need those bits to survive reboots, for example) and they MFS mount /var/tmp (at least) for the sake of optimizing compile times (cc uses /var/tmp for temporary files). So that makes us otlaws but this doesn't change the facts... All I want is not to assume existence of /var/tmp/vi.recover in /etc/rc. Because this is a simple hack that by _no chance_ breakes any set rules I believe it to be very good commit candidate. Anyone care to do it ? > > Ciao, > Sheldon. > Thanks, Ady (@warpnet.ro) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Making sure /var/tmp/vi.recover exists during reboot
Hi, On Tue, 11 Jan 2000, Sheldon Hearn wrote: > Not until someone can explain how making /var/tmp a symlink to /tmp is > sensible, given that /var/tmp is documented as containing "temporary > files that are kept between system reboots" (see hier(7)). > > So basically, no. :-) Then let's get the other way around (change in /etc/rc): # Recover vi editor files. -find /var/tmp/vi.recover ! -type f -a ! -type d -delete +if [ -d /var/tmp/vi.recover ]; then + find /var/tmp/vi.recover ! -type f -a ! -type d -delete +fi vibackup=`echo /var/tmp/vi.recover/vi.*` if [ "$vibackup" != '/var/tmp/vi.recover/vi.*' ]; then echo 'Recovering vi editor sessions' And don't worry about loosing /var/tmp/vi.recover every time you reboot (unless you really care about loosing the abillity to recover vi edits between reboots) -- the first time you run vi it will recreate this directory. And let me notice that the original script assumes existence of this directory whereas if I don't run vi I won't get one... I use this small hack to get around the ugly error message I get every time I boot with MFS mounted /var/tmp -- suited me well until now. > > Ciao, > Sheldon. > Ady (@warpnet.ro) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Patches avail?] Re: MMAP() in STABLE/CURRENT ...
Hi again, On Wed, 6 Oct 1999, Adrian Penisoara wrote: > hi again, > > On Tue, 5 Oct 1999, Matthew Dillon wrote: > > > : The problem is that the machine is completely locked, I can't get into > > :the debugger with CTR-ALT-ESC; no panics so there are no coredumps > > :catched. Any advise ? Could you escape in the debugger when you were hit > > :by these bugs ? > > > > If it's completely locked up and ctl-alt-esc doesn't work (and normally > > does work - try it on a working system to make sure that you've compiled > > in the appropriate DDB options), and you aren't in an X display > > (ctl-alt-esc isn't useful when done from an X display)... then your > > lockup problem is unrelated to mmap. > > No X on the machine, but CTRL-ALT-ESC doesn't work. > And another thing: I tried the MMAP "exploit"/test that has been floating > around at that time on another 3.2-STABLE machine SMP with 2 Pentiums and > it does lock the machine but you can switch consoles and escape to the > debugger; on the production server (K6-2 300) everything goes dead when > it happens (I haven't tried the MMAP test)... > > You're probably right, it's not the MMAP bug; but it's not faulty > hardware -- I'll have an undeniable proof in a few days, I have downgraded > to 3.1-STABLE as of 20th April... > Whoops: a few hours after downgrading to 3.1-STABLE I had a double fault error (strange, it didn't look like a normal panic screen, just the message and the content of three registers, then the syncing disks message). It seems that I might be wrong about hardware not being the problem. I've changed the motherboard, CPU, memory and the video card and I'm waiting to see how much it's going to stay up (I have 1day 1hour uptime so far)... Thanks, Ady (@warpnet.ro) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Patches avail?] Re: MMAP() in STABLE/CURRENT ...
hi again, On Tue, 5 Oct 1999, Matthew Dillon wrote: > : The problem is that the machine is completely locked, I can't get into > :the debugger with CTR-ALT-ESC; no panics so there are no coredumps > :catched. Any advise ? Could you escape in the debugger when you were hit > :by these bugs ? > > If it's completely locked up and ctl-alt-esc doesn't work (and normally > does work - try it on a working system to make sure that you've compiled > in the appropriate DDB options), and you aren't in an X display > (ctl-alt-esc isn't useful when done from an X display)... then your > lockup problem is unrelated to mmap. No X on the machine, but CTRL-ALT-ESC doesn't work. And another thing: I tried the MMAP "exploit"/test that has been floating around at that time on another 3.2-STABLE machine SMP with 2 Pentiums and it does lock the machine but you can switch consoles and escape to the debugger; on the production server (K6-2 300) everything goes dead when it happens (I haven't tried the MMAP test)... You're probably right, it's not the MMAP bug; but it's not faulty hardware -- I'll have an undeniable proof in a few days, I have downgraded to 3.1-STABLE as of 20th April... > > If you are running an X display on this box, you may be able to get > more information in regards to the crash if you turn off X. > > : > : I have: squid (20Mb), nntpcached (17Mb SIZE, 1Mb RES), apache, named, > :MFS, a few PPP processes and the rest of the standard menu. > > The only programs known to cause the swap problem are innd and innxmit, > both part of the inn news system. No such thing (yet); and I heard that innd-stable is OK (I have INND-stable running on that SMP box and had no problems with it) ?... > > : OK, how about some workarounds, I can't wait anylonger for this to be > :fixed, my situation got critical. Should I downgrade to 3.1-RELEASE (that > :hadn't exhibit this way) or can I dare a 4.0-CURRENT (are these problems > :present in -current too ?) ? > : > : Thanks, > : Ady (@warpnet.ro) > > If the machine is locking up to the point where you cannot even drop > into DDB, this bug is not related to the known mmap() bugs. > > At this point I have no idea what might be causing your lockup problem. Neither do I, dammit... :-( > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > I'll get back to you in a few days. Thanks a lot, Ady (@warpnet.ro) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Patches avail?] Re: MMAP() in STABLE/CURRENT ...
Hi, On Mon, 4 Oct 1999, Adrian Penisoara wrote: > > I have a -stable production server that keeps (solidly) blocking pretty > often (I don't get over 3 days uptimes). If you need details just let me > know. Just to let you know: syncing every second in a loop like this: while true do sync ; sleep 1 done doesn't prove to be a workaround -- the system still locks up. I tried this as per Mattew's suggestion in an e-mail on the list. BTW: I'll downgrade to 3.1-STABLE as of aprox. end of April; I'll let you know if it's stable for me. Thanks, Ady (@warpnet.ro) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Patches avail?] Re: MMAP() in STABLE/CURRENT ...
Hi, On Mon, 4 Oct 1999, Matthew Dillon wrote: > : Excuse my intrusion, but could you be so kind to tell me whether you had > :the time to build patches for these MMAP-related freezes ? If not could > :you recommend me some workarounds ? > : > : I have a -stable production server that keeps (solidly) blocking pretty > :often (I don't get over 3 days uptimes). If you need details just let me > :know. > : > :>-Matt > :>Matthew Dillon > :><[EMAIL PROTECTED]> > : Thanks, > : Ady (@warpnet.ro) > > Well, your lockups may or may not be related to the remaining mmap > problems. They could be related to the swap fragmentation problems > in stable, or they could be related to something else entirely. In > order to determine the cause of your lockup problems, some additional > information is necessary. The easiest way to get the information is > to enable DDB and kernel core dumps so you can panic the machine from The problem is that the machine is completely locked, I can't get into the debugger with CTR-ALT-ESC; no panics so there are no coredumps catched. Any advise ? Could you escape in the debugger when you were hit by these bugs ? > the console and get a core. Once you have the core > 'cd /var/crash; ps -M vmcore.X -N kernel.X' (where X is the latest > dump number) can be used to determine what the processes were doing > when they locked up. > > The two most common VM-related lockups in -stable are: > > (1) swap metadata fragmentation due to paging in the face of large > running processes (system runs out of KVM), and I have: squid (20Mb), nntpcached (17Mb SIZE, 1Mb RES), apache, named, MFS, a few PPP processes and the rest of the standard menu. > > (2) write()ing the mmap'd area of one file descriptor to another. > OK, how about some workarounds, I can't wait anylonger for this to be fixed, my situation got critical. Should I downgrade to 3.1-RELEASE (that hadn't exhibit this way) or can I dare a 4.0-CURRENT (are these problems present in -current too ?) ? > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > Thanks, Ady (@warpnet.ro) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[Patches avail?] Re: MMAP() in STABLE/CURRENT ...
Hi,
On Mon, 14 Jun 1999, Matthew Dillon wrote:
>
> :>
> :> David, can you email this program to me please?
> :>
> :> Also, which FreeBSD release does this occur on?
> :>
> :> I've got about 6 mmap-related bugs on my plate at the moment. 3 of them
> :> have been identified ( that is, I know why they deadlock the machine ),
> :> but none have been fixed yet.
> :
> :Matt, I'll volunteer myself as a tester for this code under 3.2-STABLE,
> :when you have it ready...
> :
> :Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
> :Systems Administrator @ hub.org
> :primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
>
> I'll let the lists know when patches are available. It may be a while
> (like a week), I still have a lot of catching-up to do after being at
> USENIX all last week and my commit privs still need to be resolved.
>
Excuse my intrusion, but could you be so kind to tell me whether you had
the time to build patches for these MMAP-related freezes ? If not could
you recommend me some workarounds ?
I have a -stable production server that keeps (solidly) blocking pretty
often (I don't get over 3 days uptimes). If you need details just let me
know.
> -Matt
> Matthew Dillon
> <[EMAIL PROTECTED]>
>
Thanks,
Ady (@warpnet.ro)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: "The Matrix" screensaver, v.0.2
Hi, On Mon, 23 Aug 1999, Peter Wemm wrote: > > Maybe we *should* go approach the producers? I have gone to that movie > > several times, and I keep on enjoying it, so this is GOOD PR for them. > > Tell them there will be a reference to the movie web site or something. ;-) Actually the FreeBSD site already has a reference to them (they used an CG Render Farm of 32 Dual processor FreeBSD systems): http://www.freebsd.ady.ro/news/press-rel-1.html Read all about it ! ;-) > > > Cheers, > -Peter > Take care, Ady (@freebsd.ady.ro) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "The Matrix" screensaver, v.0.2
Hi again, > > http://www.freebsd.ady.ro/news/press-rel-1.html Whoops, that should have been http://www.freebsd.org/news/press-rel-1.html for all you fellows out there (the former is my local mirror)... Ady (@freebsd.ady.ro) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: the current kernel
Hi, On Tue, 2 Mar 1999, Kenneth Wayne Culver wrote: > with the latest kernel, I have had some problems: > > The first occured when I tried to use the arla AFS client. Everything > loads ok, but then after it is loaded, if I try to use it, the system > crashes. > > Second occured when I tried to start x11amp. The system crashed when I did > that. I have no idea what caused the crashes, but they don't happen with > my 3 day old kernel, and they happen with my 5 minute old kernel. Thanks X11amp always crushed my X server with the plain pcm sound driver; try it with OSS (http://www.se.opensound.com). > > > Kenneth Culver > > Ady (@freebsd.ady.ro) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
