Re: Clockwork 24 hour crash in 4.5-RELEASE-p5
- Original Message - From: Oliver Crow [EMAIL PROTECTED] Newsgroups: local.freebsd.stable Sent: Sunday, June 02, 2002 4:05 PM Subject: Re: Clockwork 24 hour crash in 4.5-RELEASE-p5 On Sun, 2 Jun 2002, mikea wrote: On Sat, Jun 01, 2002 at 08:37:21PM -0700, Oliver Crow wrote: I have a FreeBSD 4.5-p5 system that's crashing reliably every 24 hours +/- a few minutes. It's been doing this ever since I compiled a 4.5-p4 kernel on March 25th. I cvsup'd to 4.5-p5 and recompiled, but it's still crashing. Interesting story but true: A few years back, a client of ours had a z80 based mpm based system with three vt100 terminals. SOMETIME AROUND 5:00PM, EACH DAY (give or take a fews mins) the vt100 terminal on the main system blinked a little and the whols system crashed, locking out whatever anyone was doing on the other two as well. They were on a ups, they were on surgr suppressors, the serial cables were clean, eiii specs, we slowd down the baud rate, still happened. guess what: there was a postage meter (read BIG MF MAGNET) on the other side of the wall. 5pm, just before going home, the receptionist whould 'ch-chunk' about 40 letters. -- Michael Scheidell SECNAP Network Security, LLC (561) 368-9561 [EMAIL PROTECTED] http://www.secnap.net Either I'm missing data showing the crash time, or you didn't include it. When does this crash happen? Is it during a burst of cron-spawned activity? It doesn't crash during a burst of cron activity, no. It doesn't occur at exactly the same time each day, it moves around by a few minutes each time. If you reboot manually it'll crash at the same time the next day (ie, 24 hours after the reboot). Here's the log of reboots during April. You see it crashed every day between the first and the 16th. Then it didn't crash for 10 days. I rebooted manually on the 26th at 20:19, and it started crashing every day again. # last -f /var/log/wtmp.1 reboot reboot ~ Tue Apr 30 20:17 reboot ~ Mon Apr 29 20:17 reboot ~ Sun Apr 28 20:19 reboot ~ Sat Apr 27 20:19 reboot ~ Fri Apr 26 20:19 reboot ~ Fri Apr 26 19:49 reboot ~ Tue Apr 16 11:10 reboot ~ Tue Apr 16 11:03 reboot ~ Mon Apr 15 18:33 reboot ~ Sun Apr 14 18:37 reboot ~ Sat Apr 13 18:41 reboot ~ Fri Apr 12 18:45 reboot ~ Thu Apr 11 18:48 reboot ~ Thu Apr 11 18:00 reboot ~ Tue Apr 9 19:50 reboot ~ Mon Apr 8 19:54 reboot ~ Sun Apr 7 19:58 reboot ~ Sat Apr 6 19:00 reboot ~ Fri Apr 5 18:58 reboot ~ Thu Apr 4 18:58 reboot ~ Wed Apr 3 19:02 reboot ~ Tue Apr 2 19:00 reboot ~ Mon Apr 1 19:00 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Lame DNS question (can't set maxfiles to default after upgrade to Bind 8.2.4/FreeBSD 4.5-RELEASE-p3)
Dear Sir, Thank you for your reply. On Thu, Apr 25, 2002 at 08:39:21PM -0700, Doug Barton wrote: This would actually be better on freebsd-stable, for future reference. What do you mean by replication? Copying zone files from the master to the secondary; the problem servers are secondaries. In any case, does this still happen if you start named as root? That should give you an indication of whether it's a login.conf problem. There is no problem when running named as root. However, I would like to run it as bind. Also, did you run cap_mkdb after editing login.conf? Yes. A couple of times: I tried again when it failed. If the problem persists when starting the server as root, post your login.conf file in your response. Thank you, Yours sincerely. -- Stanley Hopcroft Network Specialist '...No man is an island, entire of itself; every man is a piece of the continent, a part of the main. If a clod be washed away by the sea, Europe is the less, as well as if a promontory were, as well as if a manor of thy friend's or of thine own were. Any man's death diminishes me, because I am involved in mankind; and therefore never send to know for whom the bell tolls; it tolls for thee...' from Meditation 17, J Donne. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Lame DNS question (can't set maxfiles to default after upgradeto Bind 8.2.4/FreeBSD 4.5-RELEASE-p3)
On Fri, 26 Apr 2002, Stanley Hopcroft wrote: Copying zone files from the master to the secondary; the problem servers are secondaries. How many zones are you talking about? named does not need to open a file descriptor for every single zone file for the whole life of the daemon. In any case, does this still happen if you start named as root? That should give you an indication of whether it's a login.conf problem. There is no problem when running named as root. By which you mean that you don't see the error message when you start it as root? If the problem persists when starting the server as root, post your login.conf file in your response. You didn't attach the file. -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: nfs_fsync: not dirty error in 4.5-RELEASE
On Wed, 27 Mar 2002, Wilko Bulte wrote: OK. I suppose you might want to try to catch a panic dump if you can. I don't think it's the maxusers setting. I filed a PR on this last week, my maxusers was set to 0. The PR contains a back trace as well. I don't have the number handy. I am running 4.5-STABLE (early March) and have experienced this on three different systems. Danny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Machine Lockups on 4.5-RELEASE
I have an AMD 486 DX-100 machine that has run flawlessly since 4.0-RELEASE. Although slow, I build custom kernels, and use ports to build and install software. The software on this machine is minimal as I use it for my firewall and to serve DHCP requests. Here is the list of installed ports: blacksheep# pkg_info autoconf213-2.13.000227_1 Automatically configure source code on many Un*x platforms dhcping-1.1 Send DHCP request to DHCP server for monitoring purposes gettext-0.10.35_1 GNU gettext package gmake-3.79.1GNU version of 'make' utility isakmpd-20020104OpenBSD IKE daemon isc-dhcp3-3.0.1.r6 ISC Dynamic Host Configuration Protocol client and server c libtool-1.3.4_2 Generic shared library support script m4-1.4_1GNU's m4 mpd-3.6 Multi-link PPP daemon based on netgraph(4) pkg_tarup-1.2_3 Generates binary package from installed package portupgrade-20020227 Very powerful FreeBSD ports/packages upgrading tool and mor ruby-1.6.7.2002.03.13 An object-oriented interpreted scripting language ruby-bdb1-0.1.6 Ruby interface to Berkeley DB revision 1.8x with full featu ruby-fnmatch-1.1b_1 A Ruby module which provides File::fnmatch and File::FNM_* ruby-optparse-0.8.6 Yet another command line option parser for Ruby sharity-light-1.2 An userland smbfs --- SMB to NFS protocols converter snort-1.8.3 Lightweight network intrusion detection system I've had no problems until upgrading from 4.4-RELEASE to 4.5-RELEASE. Since the upgrade, my machine locks up occasionally when under heavy load, doing things like compiling or updating to ports database. The only thing I can do at this point is power off/on the machine. I know at first this appears hardware related but I don't suspect it is because it started right after the upgrade. Is there anything that happened between 4.4 4.5 that could account for this? If so, has it been fixed in -STABLE? If it helps, I'd be willing to revert to 4.4-RELEASE and see if the problem persists. Thanks for any input, Drew dmesg output follows: blacksheep# dmesg Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.5-RELEASE #3: Tue Jan 29 21:45:21 PST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BLACKSHEEP Timecounter i8254 frequency 1193852 Hz CPU: AMD Enhanced Am486DX4 Write-Through (486-class CPU) Origin = AuthenticAMD Id = 0x484 Stepping = 4 Features=0x1FPU real memory = 50331648 (49152K bytes) config di sn0 config di lnc0 config di ie0 config di cs0 config en ed0 config po ed0 0x240 config ir ed0 9 config iom ed0 0xd8000 config f ed0 0 config en ed1 config po ed1 0x260 config ir ed1 11 config iom ed1 0xd config f ed1 0 config q avail memory = 45703168 (44632K bytes) Preloaded elf kernel kernel at 0xc034f000. Preloaded userconfig_script /boot/kernel.conf at 0xc034f09c. netsmb_dev: loaded md0: Malloc disk npx0: math processor on motherboard npx0: INT 16 interface isa0: ISA bus on motherboard isa0: too many dependant configs (8) orm0: Option ROM at iomem 0xc-0xc7fff on isa0 fdc0: NEC 765 or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fd0: 1440-KB 3.5 drive on fdc0 drive 0 fd1: 1200-KB 5.25 drive on fdc0 drive 1 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1 at port 0x170-0x177,0x376 irq 15 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x100 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 ed0 at port 0x240-0x25f iomem 0xd8000 irq 9 drq 0 on isa0 ed0: address 00:40:05:66:b2:55, type NE2000 (16 bit) ed1 at port 0x260-0x27f iomem 0xd irq 11 drq 0 on isa0 ed1: address 00:40:05:66:b2:52, type NE2000 (16 bit) IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to accept, unlimited logging IPsec: Initialized Security Association Processing. ad0: 814MB WDC AC2850F [1654/16/63] at ata0-master BIOSPIO ad1: 814MB WDC AC2850F [1654/16/63] at ata0-slave BIOSPIO ad2: 4103MB ST34342A [8894/15/63] at ata1-master BIOSPIO acd0: CDROM CRD-8160B at ata1-slave using BIOSPIO Mounting root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
4.5-RELEASE kernel panic
Hello All,
Below is an abbreviated kernel debugging session from a kernel panic. I
suspect this is due to a bug in the network routing code. Somehow, a null
pointer got thrown in the works. Could someone more knowledgable of these
things have a look? I can provide more information as requested.
Thanks!
My system: FreeBSD 4.5-RELEASE on an AMD Athlon 1 GHz, 512 MB RAM, Intel
Etherexpress PRO 100S.
What I found with gdb -k:
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x303031f
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01b9049
stack pointer = 0x10:0xc030cf78
frame pointer = 0x10:0xc030cfc8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask =
trap number = 12
(kgdb) bt
#0 dumpsys () at ../../kern/kern_shutdown.c:474
#1 0xc016fbfb in boot (howto=260) at ../../kern/kern_shutdown.c:313
#2 0xc016fff5 in panic (fmt=0xc030574c %s) at
../../kern/kern_shutdown.c:582
#3 0xc02b2faf in trap_fatal (frame=0xc030cd64, eva=48)
at ../../i386/i386/trap.c:956
#4 0xc02b2c5d in trap_pfault (frame=0xc030cd64, usermode=0, eva=48)
at ../../i386/i386/trap.c:849
#5 0xc02b2803 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -1070166208, tf_esi = 0, tf_ebp = -1070543444,
tf_isp = -1070543472, tf_ebx = -1070432644, tf_edx = 6832192,
tf_ecx = 8, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1071357192, tf_cs = 8, tf_eflags = 66050, tf_esp = 0,
tf_ss = 0}) at ../../i386/i386/trap.c:448
#6 0xc02462f8 in acquire_lock (lk=0xc0327e7c)
at ../../ufs/ffs/ffs_softdep.c:271
#7 0xc024a896 in softdep_fsync_mountdev (vp=0xe36db540)
at ../../ufs/ffs/ffs_softdep.c:3986
#8 0xc024ec5a in ffs_fsync (ap=0xc030ce20) at
../../ufs/ffs/ffs_vnops.c:134
#9 0xc024d8e7 in ffs_sync (mp=0xc198ec00, waitfor=2, cred=0xc1474500,
p=0xc0368f40) at vnode_if.h:558
#10 0xc019ffd3 in sync (p=0xc0368f40, uap=0x0) at
../../kern/vfs_syscalls.c:547
#11 0xc016f9ae in boot (howto=256) at ../../kern/kern_shutdown.c:234
#12 0xc016fff5 in panic (fmt=0xc030574c %s) at
../../kern/kern_shutdown.c:582
#13 0xc02b2faf in trap_fatal (frame=0xc030cf38, eva=50529055)
at ../../i386/i386/trap.c:956
#14 0xc02b2c5d in trap_pfault (frame=0xc030cf38, usermode=0, eva=50529055)
at ../../i386/i386/trap.c:849
#15 0xc02b2803 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -1047960544, tf_esi = 0, tf_ebp = -1070542904,
tf_isp = -1070543004, tf_ebx = 50529027, tf_edx = 0,
tf_ecx = -1048122492, tf_eax = 6424576, tf_trapno = 12, tf_err = 0,
tf_eip = -1071935415, tf_cs = 8, tf_eflags = 66054,
tf_esp = -1047960544, tf_ss = 50529027}) at
../../i386/i386/trap.c:448
#16 0xc01b9049 in rtalloc1 (dst=0xc1896420, report=0, ignflags=65792)
at ../../net/route.c:135
#17 0xc01c53e5 in in_addroute (v_arg=0xc1896420, n_arg=0x0,
head=0xc186ea80,
treenodes=0xc1e95c00) at ../../netinet/in_rmx.c:121
#18 0xc01b98e8 in rtrequest1 (req=11, info=0xc030d054, ret_nrt=0xc030d0b8)
at ../../net/route.c:692
#19 0xc01b9518 in rtrequest (req=11, dst=0xc030d130, gateway=0x0,
netmask=0x0,
flags=0, ret_nrt=0xc030d0b8) at ../../net/route.c:489
#20 0xc01b9097 in rtalloc1 (dst=0xc030d130, report=1, ignflags=256)
at ../../net/route.c:149
#21 0xc01b9004 in rtalloc_ign (ro=0xc030d12c, ignore=256)
at ../../net/route.c:111
#22 0xc1a22019 in ?? ()
#23 0xc1a22b73 in ?? ()
#24 0xc01c73b7 in ip_input (m=0xc1476600) at ../../netinet/ip_input.c:419
#25 0xc01c793b in ipintr () at ../../netinet/ip_input.c:843
#26 0xc02a7d95 in swi_net_next ()
(kgdb) up 16
#16 0xc01b9049 in rtalloc1 (dst=0xc1896420, report=0, ignflags=65792)
at ../../net/route.c:135
135 if (rnh (rn = rnh-rnh_matchaddr((caddr_t)dst, rnh))
(kgdb) list
130 int s = splnet(), err = 0, msgtype = RTM_MISS;
131
132 /*
133 * Look up the address in the table for that Address
Family
134 */
135 if (rnh (rn = rnh-rnh_matchaddr((caddr_t)dst, rnh))
136 ((rn-rn_flags RNF_ROOT) == 0)) {
137 /*
138 * If we find it and it's not the root node, then
139 * get a refernce on the rtentry associated.
(kgdb) print rnh
$1 = (struct radix_node_head *) 0x620800
(kgdb) print dst
$2 = (struct sockaddr *) 0xc1896420
(kgdb) print rn
$3 = (struct radix_node *) 0x0
(kgdb) print *rnh
cannot read proc at 0
(kgdb) print *dst
$4 = {sa_len = 0 '\000', sa_family = 97 'a',
sa_data = \211Á\020\002\000\000£\001\177\236\000\000\000}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: crashes on 4.5-RELEASE
Looks like I'm not the only one seeing this: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/22494 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/31710 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/30952 I suspect these are all the same problem. -jan- -- Jan L. Peterson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: crashes on 4.5-RELEASE
Just another datapoint... I turned off softupdates. The machine crashed in the xl code. Trace from DDB: xl_newbuf(c15b8000,c15b844c) xl_rxeof(c15b8000) xl_intr(c15b8000,660400,c690a834,1,cdf1fd48) intr_mux(c0e356c0,0,c6900010,10,c0190010) Xresume10() --- interrupt, eip = 0xc02afd22, esp = 0xcdf1fd08, ebp = 0xcdf1fd48 -- vec10(ce0b7000,8,0,0,0)) nfs_getcacheblk(ce0b7000,8,0,cdef1100,ce0b7000) nfs_write(cdf1fe64,c17d45c0,cdef1100,1000,c031cd00) vn_write(c17d45c0,cdf1fed4,c17ae200,0,cdef1100) dofilewrite(cdef1100,c17d45c0,4,8053f60,1000) write(cdef1100,cdf1ff80,1000,6,4) syscall(2f,2f,2f,4,6) Xint0x80_syscall() pretty consistent now... I can make it crash in less than five minutes after booting. -jan- -- Jan L. Peterson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
crashes on 4.5-RELEASE
Okay, I'm pretty sure this isn't a hardware problem now. I was seeing periodic crashes with 4.5-RELEASE on a new laptop I was building. Various posts on this list convinced me that I had a hardware problem. I tried swapping out the RAM and it seemed to crash less (and in a different place). Crashes after swapping the RAM were always in the xl routines. So, being convinced that I had a hardware problem (mother board or cpu or something like that), I swapped out the *entire machine*. I'm still seeing the crashes. So, I have /usr/ports nfs mounted from another freebsd box. I cd /usr/ports/misc/instant-workstation; make install The machine panics (sometimes right away, sometimes after several minutes). Here's the panic message: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc0fcec39 fault code = supervisor write, page not present instruction pointer = 0x8:0xc0205243 stack pointer = 0x10:0xcde4fbd0 frame pointer = 0x10:0xcde4fbe4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 80 (nfsiod) interrupt mask = net tty kernel: type 12 trap, code=0 Stopped at nfs_realign+0xdb: incb0(%eax,%edx,1) db trace nfs_realign(c0ea5200,14,0,1,cdeb0cc0) at nfs_realign+0xdb nfs_receive(c17ca280,cde4fc6c,cde4fc70,0,1) at nfs_receive+0x45d nfs_reply(c17ca280,cde4fdc0,0,20,10) at nfs_reply+0x45 nfs_request(ce0b3c80,c0e5bf00,6,0,c16dcc80) at nfs_request+0x39a nfs_readrpc(ce0b3c80,cde4fdc0,c16dcc80,c68a25b8,cdeb0cc0) at nfs_readrpc+0x538 nfs_doio(c68a25b8,c16dcc80,0) at nfs_doio+0x14b nfssvc_iod(cc379740,cc379740,2,cde4ff80,c37d880) at nfssvc_iod+0x1c2 nfssvc(cc379740,cde4ff80,2,0,bfbffdd8) at nfssvc+0x6f syscall2(2f,2f,2f,bfbffdd8,0) at syscall2+0x1f5 Xint0x80_syscall() at Xint0x80_syscall+0x25 db FYI, this machine is an HP Omnibook 6000. It has the xl ethernet built in and this is the interface I'm using. In this particular case, my entire sequence of events was: boot login su mount /usr/ports (from the nfs server) cd /usr/ports/misc/instant-workstation make clean make install kaboom Just had another crash, panic this time was again supervisor read, page not present, but current process was syncer. Traceback shows: malloc(...) initiate_write_inodeblock(...) softdep_disk_io_initiation(...) spec_strategy(...) bwrite(...) vop_stdbwrite(...) vop_defaultop(...) vfs_bio_awrite(...) spec_fsync(...) sched_sync(...) fork_trampoline(...) I do have soft updates turned on on the single / filesystem on this box. Should I turn them off? I would be happy to supply my kernel config file to anyone interested. P.S. I also have the problem with these Omnibooks that if you tell them to reboot (or halt followed by pressing any key to reboot), they hang in a weird kind of half power on state. The display goes black (the backlight turns off), but if you shine a flashlight on the LCD, you can still see text there. The Power light on the front does not turn off, and the machine still generates plenty of heat, but the cpu cooling fan will not turn itself on. Any suggestions for that? -jan- -- Jan L. Peterson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: crashes on 4.5-RELEASE
FYI, this machine is an HP Omnibook 6000. It has the xl ethernet built in and this is the interface I'm using. I've had one of these for over a year, and I use the network NFS fairly heavily. It's very stable for me (only remaining niggles on this platform for me were sound and xl0 post-resume - but these were completely addressed for me by a couple of commits just pre-4.5-RELEASE). I do have soft updates turned on on the single / filesystem on this box. Should I turn them off? They don't cause me any problems (in fact quite the opposite, I think), I've been running them for quite some time. Never caused a single funny for me.. I would be happy to supply my kernel config file to anyone interested. I'd be happy to provide you with mine, this might be quicker :) P.S. I also have the problem with these Omnibooks that if you tell them to reboot (or halt followed by pressing any key to reboot), they hang in a weird kind of half power on state. The display goes black (the backlight turns off), but if you shine a flashlight on the LCD, you can still see text there. The Power light on the front does not turn off, and the machine still generates plenty of heat, but the cpu cooling fan will not turn itself on. Any suggestions for that? Ahh yes, everything in this area used to work fine (including 'shutdown -p'), but broke after Warner made the PCI-routing changes for PCCARD. He can reproduce it with his hardware, and it's not a real big thing anyway (plus he's doing some good work *waves*, don't wanna distract him with trifles).. Just 'halt' the machine, and use the little power key in the top-left corner when it says to Press Any Key. It'll startup clean. Cheers, AS msg41843/pgp0.pgp Description: PGP signature
Re: crashes on 4.5-RELEASE
I have a fbsd file server that doesn't crash. The box that crashes is nfs mounting /usr/ports from the server. My thoughts are that there is some interaction in the nfs code with the xl driver. -jan- -- Jan L. Peterson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: panic on 4.5-RELEASE
Once upon a Wed, Feb 13 2002, Jan L. Peterson hit keys in the following order: I've just installed 4.5-RELEASE on my new hard drive in an HP Omnibook 6000. Doing heavy disk activity combined with network activity results in a panic. I discovered this first while doing an installworld off of a nfs mounted /usr/src and /usr/obj. Some fiddling left me with a broken system and I had to re-install. On the new install, I built a kernel with DDB in it and then tried tarring /usr/ports from a nfs mounted filesystem to a local filesystem. Boom again. I might have had a similair problem. haven't looked into it any deeper yet, but it looks like UDP NFS mounts with 16384 make the NFS server's kernel crash hard. after i found a workaround, i didn't have chance to trace this bug. My situation was that i was copying a bunch of stuff from a linux machine, which had options for nfs mounts set to 16384 byte blocks. When i set them to 8192, FreeBSD didn't crash any more. hope this helps... martijn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Weird path MTU autodiscovery problem in 4.5-RELEASE
Is the server filtering out ICMP traffic with ipfw or something? Alexey Luckyanchikov wrote: 14:06:48.477578 server.7 client.1371: . 1437:2897(1460) ack 10001 win 65535 (DF) (ttl 64, id 25428, len 1500) ^^^ Server send packet with size 1500 bytes 14:06:48.682558 router server: icmp: client unreachable - need to frag (mtu 1476) for server.7 client.1371: [|tcp] (DF) (ttl 61, id 25428, len 1500) (ttl 253, id 2491, len 56) ^^ Router say to server that he must to decrease packet size 14:07:04.477857 server.7 client.1371: . 1437:2897(1460) ack 10001 win 65535 (DF) (ttl 64, id 52781, len 1500) ^ But server ignore this information and still send 1500 bytes packets What's the result of 'sysctl net.inet.tcp.path_mtu_discovery' ?? Not that I can imagine, at the moment, what would set it to 0 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
4.5-Release kernel locking hard after 30 minutes
I tried to upgrade from 4.4-R to 4.5-R via CVSUP. Kernel compiled and installed fine (as generic, but includes ipfilter and stripped down to eliminate unnecessary devices). I started doing a buildworld, but after 30 mins of heavy compiling the machine locked solid - a hard reset required to recover. Never seen this before. I booted back to 4.4R Kernel and all is well again. PC is Asus Cuple-VM mobo (82C686B southbridge), 256Mb, integrated graphics, 60Gb IBM HD, 400MHz celeron, 2xFA311 NIC. Uptime is weeks with 4.4R under heavy usage (only tweaking the kernel has required a reboot). Suggestions of how to attack the 4.5 lockup problem? Neil To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Weird path MTU autodiscovery problem in 4.5-RELEASE
On Fri, Feb 01, 2002 at 02:53:26PM +0200, Alexey Luckyanchikov wrote: Hello, I have such network topology: ++++++ | Server | MTU 1500 | Router | MTU 1476 | Client | ++++++ [snip] 14:06:48.682558 router server: icmp: client unreachable - need to frag (mtu 1476) for server.7 client.1371: [|tcp] (DF) (ttl 61, id 25428, len 1500) (ttl 253, id 2491, len 56) ^^ Router say to server that he must to decrease packet size Is router the same IP address that server has as the route to client? That is, there aren't any aliases on router's interface with server making problems? -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
4.5-RELEASE
Hi, Its 4.5-RELEASE still planned for January 15, 2002? Holt __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: 4.5-RELEASE
Date: Mon, 31 Dec 2001 11:34:57 -0800 (PST) From: Holt Grendal [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hi, Its 4.5-RELEASE still planned for January 15, 2002? The latest information is always at http://www.freebsd.org/releases/ It's January 20, 2002. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
