Re: RE: network got stuck during high nfs-load
The way I usually handle pseudo users via sendmail is to route them via a dummy subdomain. So, for example, my main server is 'apollo.backplane.com'. I route mail destined for 'pop.apollo.backplane.com' to my special pop mail backend. My /etc/aliases and other forwarding tables then simply map the usernames that I want to route to the dummy domain. For example, the pop user 'fubar' would be mapped to '[EMAIL PROTECTED]', where 'fubar' does not exist in the password file or anything like that. In sendmail, it is a simple addition to ruleset 98: R$+ + $* < @ pplus . $=w > $* $#popplus $: $1 < @ pplus . $3 > $4 R$+ + $* < @ pplus . $=w . > $* $#popplus $: $1 < @ pplus . $3 > $4 R$* < @ pplus . $=w > $*$#popplus $: $1 < @ pplus . $2 > $3 R$* < @ pplus . $=w . > $* $#popplus $: $1 < @ pplus . $2 > $3 And then add the new mailer: Mpopplus, P=/usr/local/bin/dpopmail, F=SDEFhlMsu, S=10/30, R=20/40, U=dpop, A=dpopmail $u -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: network got stuck during high nfs-load
I'm now getting a similar thing with the latest -STABLE build.
NFS isn't involved, but this is on a heavily used webserver.
NIC is a 3COM 3C905b.
Ifconfig up and down works for about 5 packets, that's it. netstat
was showing either errors inbound, or absolutely nothing.
This happens about once per day now, on this machine. I've
had to switch back to a UP kernel to avoid this (and another
bug about processes getting wedged on a processor).
I think this is an SMP problem, so I've included freebsd-smp
in the reply.
-Troy Cobb
Circle Net, Inc.
http://www.circle.net
> -Original Message-
> From: Martin Blapp [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, July 31, 1999 9:57 AM
> To: [EMAIL PROTECTED]
> Subject: network got stuck during high nfs-load
>
>
>
> Hi driver gurus,
>
> Today I had heavy NFS-load on my CURRENT-SMP machine while compiling
> world. Suddenly all NFS-Clients stopped working. I was't
> able to ping
> the server from inside my /29 subnet, same with ping the
> others from
> the server itself. I changed cables, plugged them in and
> out, did some
> ifconfig up down, deleted routes and added them again ...
> nothing. But
> the card was still sending from time to time (once a
> second) with 100%
> load many 0 bytes - like some waves:
>
> (tcp-dump from same subnet, MAC Adress 0:a0:cc:66:32:97 is
> the NFS-Server)
>
> --
>
> 13:53:41.673733 0:a0:cc:66:32:97 > 0:a0:cc:66:32:97 null
> test/C len=43
>
>
> 00
>
> 13:53:41.773706 0:a0:cc:66:32:97 > 0:a0:cc:66:32:97 null
> test/C len=43
>
>
> 00
>
> It looks like a endless loop somewhere in the de0-driver ...
>
> I was able to ping the machine from itself via loopback and
> via the local
> ip. No stucked processes at all, the running make
> buildworld was still
> running. Also the load was normal, I couldn't see some
> special behaviour ...
>
> I paniced the server and made a crashdump. If anybody is
> interested in
> this strange behaviour, just write me back ... After a
> reboot, all worked
> again, but that's not a good solution ;)
>
> Martin
>
> PS: cvsup is from yesterday (30.7.1999) at 22:00 CET and I included
> a backtrace and a dmesg from my server ...
>
> backtrace from debug.kernel
> ---
>
> #0 boot (howto=260) at ../../kern/kern_shutdown.c:291
> #1 0xc01538c9 in panic (fmt=0xc0277c14 "from debugger")
> at ../../kern/kern_shutdown.c:505
> #2 0xc012df19 in db_panic (addr=-1071398025, have_addr=0, count=-1,
> modif=0xff80dddc "") at ../../ddb/db_command.c:434
> #3 0xc012deb7 in db_command (last_cmdp=0xc02a6f30,
> cmd_table=0xc02a6d90,
> aux_cmd_tablep=0xc02c572c) at ../../ddb/db_command.c:334
> #4 0xc012df7e in db_command_loop () at ../../ddb/db_command.c:456
> #5 0xc012ffbb in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
> #6 0xc023c0c2 in kdb_trap (type=3, code=0, regs=0xff80ded0)
> at ../../i386/i386/db_interface.c:157
> #7 0xc02524a0 in trap (frame={tf_fs = 24, tf_es = 16,
> tf_ds = 16, tf_edi
> = 0,
> tf_esi = -1070741376, tf_ebp = -8331496, tf_isp = -8331524,
> tf_ebx = -1070741376, tf_edx = -1070689184, tf_ecx = 16777217,
> tf_eax = 38, tf_trapno = 3, tf_err = 0, tf_eip =
> -1071398025, tf_cs
> = 8,
> tf_eflags = 582, tf_esp = -1071030749, tf_ss = -1071045718})
> at ../../i386/i386/trap.c:534
> #8 0xc023c377 in Debugger (msg=0xc02923aa "manual escape
> to debugger")
> at machine/cpufunc.h:64
> #9 0xc0236d7c in scgetc (sc=0xc02c3ca0, flags=2)
> at ../../dev/syscons/syscons.c:3813
> #10 0xc0232529 in sckbdevent (thiskbd=0xc02db0a0, event=0,
> arg=0xc02c3ca0)
> at ../../dev/syscons/syscons.c:688
> #11 0xc022bd77 in atkbd_intr (kbd=0xc02db0a0, arg=0x0)
> at ../../dev/kbd/atkbd.c:535
> #12 0xc02692d7 in atkbd_isa_intr (arg=0xc05a2100) at
> ../../isa/atkbd_isa.c:125
>
> dmesg-output
>
>
> Copyright (c) 1992-1999 The FreeBSD Project.
> Copyright (c) 1982, 1986, 1989, 1
network got stuck during high nfs-load
Hi driver gurus,
Today I had heavy NFS-load on my CURRENT-SMP machine while compiling
world. Suddenly all NFS-Clients stopped working. I was't able to ping
the server from inside my /29 subnet, same with ping the others from
the server itself. I changed cables, plugged them in and out, did some
ifconfig up down, deleted routes and added them again ... nothing. But
the card was still sending from time to time (once a second) with 100%
load many 0 bytes - like some waves:
(tcp-dump from same subnet, MAC Adress 0:a0:cc:66:32:97 is the NFS-Server)
--
13:53:41.673733 0:a0:cc:66:32:97 > 0:a0:cc:66:32:97 null test/C len=43
00
13:53:41.773706 0:a0:cc:66:32:97 > 0:a0:cc:66:32:97 null test/C len=43
00
It looks like a endless loop somewhere in the de0-driver ...
I was able to ping the machine from itself via loopback and via the local
ip. No stucked processes at all, the running make buildworld was still
running. Also the load was normal, I couldn't see some special behaviour ...
I paniced the server and made a crashdump. If anybody is interested in
this strange behaviour, just write me back ... After a reboot, all worked
again, but that's not a good solution ;)
Martin
PS: cvsup is from yesterday (30.7.1999) at 22:00 CET and I included
a backtrace and a dmesg from my server ...
backtrace from debug.kernel
---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:291
#1 0xc01538c9 in panic (fmt=0xc0277c14 "from debugger")
at ../../kern/kern_shutdown.c:505
#2 0xc012df19 in db_panic (addr=-1071398025, have_addr=0, count=-1,
modif=0xff80dddc "") at ../../ddb/db_command.c:434
#3 0xc012deb7 in db_command (last_cmdp=0xc02a6f30, cmd_table=0xc02a6d90,
aux_cmd_tablep=0xc02c572c) at ../../ddb/db_command.c:334
#4 0xc012df7e in db_command_loop () at ../../ddb/db_command.c:456
#5 0xc012ffbb in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#6 0xc023c0c2 in kdb_trap (type=3, code=0, regs=0xff80ded0)
at ../../i386/i386/db_interface.c:157
#7 0xc02524a0 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi
= 0,
tf_esi = -1070741376, tf_ebp = -8331496, tf_isp = -8331524,
tf_ebx = -1070741376, tf_edx = -1070689184, tf_ecx = 16777217,
tf_eax = 38, tf_trapno = 3, tf_err = 0, tf_eip = -1071398025, tf_cs
= 8,
tf_eflags = 582, tf_esp = -1071030749, tf_ss = -1071045718})
at ../../i386/i386/trap.c:534
#8 0xc023c377 in Debugger (msg=0xc02923aa "manual escape to debugger")
at machine/cpufunc.h:64
#9 0xc0236d7c in scgetc (sc=0xc02c3ca0, flags=2)
at ../../dev/syscons/syscons.c:3813
#10 0xc0232529 in sckbdevent (thiskbd=0xc02db0a0, event=0, arg=0xc02c3ca0)
at ../../dev/syscons/syscons.c:688
#11 0xc022bd77 in atkbd_intr (kbd=0xc02db0a0, arg=0x0)
at ../../dev/kbd/atkbd.c:535
#12 0xc02692d7 in atkbd_isa_intr (arg=0xc05a2100) at
../../isa/atkbd_isa.c:125
dmesg-output
Copyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-CURRENT #1: Fri Jul 30 21:31:06 CEST 1999
[EMAIL PROTECTED]:/usr/src/sys/compile/FUCHUR
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium/P55C (586-class CPU)
Origin = "GenuineIntel" Id = 0x543 Stepping = 3
Features=0x8003bf
real memory = 67108864 (65536K bytes)
avail memory = 61652992 (60208K bytes)
Programming 24 pins in IOAPIC #0
FreeBSD/SMP: Multiprocessor motherboard
cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee0
cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee0
io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0
Preloaded elf kernel "kernel" at 0xc034.
Intel Pentium detected, installing workaround for F00F bug
Probing for PnP devices:
npx0: on motherboard
npx0: INT 16 interface
pcib0: on motherboard
pci0: on pcib0
isab0: at device 7.0 on pci0
ide_pci0: at device 7.1 on pci0
de0: irq 17 at device 9.0 on pci0
de0: 21140A [10-100Mb/s] pass 2.0
de0: address 00:a0:cc:66:32:97
vga-pci0: irq 18 at
device 10.0 on pci0
ahc0: irq 19 at device 12.0 on pci0
ahc0: Using left over BIOS settings
ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs
isa0: on motherboard
fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
wdc0 at port 0x1f0-0x1f7 irq 14 on isa0
wdc0: unit 0 (atapi): , removable, accel,
ovlap, dma, iordis
wcd0: drive speed 5512KB/sec, 256KB cache
wcd0: supported read types: CD-R, CD-RW, CD-DA
wcd0: Audio: play, 255 volum
