New error - lost data?
I've never seen this error. Its been occuring randomly on this machine, sometimes as often as every few minutes, sometimes days apart. Others have seen this error (based on a Google search) but nothing recent and nothing that conclusive. This is a very standard config that has been stable for quite a while. The panic: malloc: lost data implies to me that something is misbehaving with its memory allocations. Is this a hardware issue or an application problem? The kernel is 4.1 RELEASE. The RAM is ECC. Any assistance would be appreciated! Thanks, Deepak Jain AiNET Jun 5 01:02:56 play /kernel: panic: malloc: lost data Jun 5 01:02:56 play /kernel: Jun 5 01:02:56 play /kernel: syncing disks... 440 440 440 440 440 440 440 440 Jun 5 01:02:56 play /kernel: giving up on 433 buffers Jun 5 01:02:56 play /kernel: Uptime: 3m11s To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: New error - lost data?
Yes, its only happening on this one chassis so far. We'll try replacing the memory and see what happens. Thanks! Deepak Jain AiNET -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Assar Westerlund Sent: Friday, June 08, 2001 9:07 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: New error - lost data? "Deepak Jain" <[EMAIL PROTECTED]> writes: > Others have seen this error (based on a Google search) but nothing recent > and nothing that conclusive. This is a very standard config that has been > stable for quite a while. The panic: malloc: lost data implies to me that > something is misbehaving with its memory allocations. > > Is this a hardware issue or an application problem? The kernel is 4.1 > RELEASE. The RAM is ECC. It should not be an application problem. It indicates that the memory pool administered by the kernel malloc is corrupt. Either it's a bug in the kernel or bad memory. Does it only happen on that particular machine with that particular memory? /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
TCP information
Is there a utility/hack/patch that would allow a diligent sysadmin to obtain which specific TCP connections are generating retransmits and receiving packet drops? netstat will show me drops on an interface, but not on a specific source/dest pair? I am guessing something like a netstat -n, but instead of showing send/rec queues it shows retransmit or packet drops? Would there be much interest in this feature if we were to build it ourselves? Thanks in advance, Deepak Jain AiNET ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: TCP information
>If you've got a small enough amount of traffic, you could use > tcpdump to > snarf the headers and then use your favourite scripting languge > to look for > repeated sequence numbers (retransmits) and repeated acks (lost packets); > but I suspect this would be too slow for most purposes. Yeah, we thought about using a sniffer in front of a box to accomplish the same task to overcome the performance issue, but a more direct way would really be suitable to our application. Thanks! Deepak Jain AiNET ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: TCP information
> These types of statistics aren't kept. > > Generally, they are used only by network researchers, who hack > their stacks to get them. > > They usually do not make it into commercial product distributions > for performance reasons, and because every byte added to a tcpcb > structure is one byte less that can be used for something else. > In practice, adding 134 bytes of statistics to a tcpcb would > double its size and halve the number of simultaneous connections > you would be able to support with the same amount of RAM in a > given machine (as one example), if all of that memory had to > come out of the same space, all other things being equal. If the tcpcb struct were expanded/changed and the various increments were added in the appropriate packet pushing code, this would work right? Is there something non-obvious that one would need to worry about to undertake such a project? Thanks, Deepak Jain AiNET ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
em0, polling performance, P4 2.8ghz FSB 800mhz
I have a machine running 4.9. P4 2.8Ghz, 800mhz bus, Intel PRO/1000
ethernet connected to a Cisco, both sides are locked to 1000/FD.
The kernel has HZ=1000, and DEVICE_POLLING, IPFW, DUMMYNET, etc. After
only a few minutes of run time under an attack ~90,000 pps. The attack
has been limited at the router to JUST incoming TCP port 80 inbound
traffic. I don't know why the machine is having such a hard time under
the load. The cpu shows it is >90% idle even under the worst of the
attack. What am I doing wrong?
Thanks,
DJ
#sysctl -a |grep hz
kern.clockrate: { hz = 1000, tick = 1000, tickadj = 1, profhz = 1024,
stathz = 1
28 }
#sysctl -a |grep polling
kern.polling.burst: 544
kern.polling.each_burst: 30
kern.polling.burst_max: 550
kern.polling.idle_poll: 1
kern.polling.poll_in_trap: 0
kern.polling.user_frac: 50
kern.polling.reg_frac: 30
kern.polling.short_ticks: 44151
kern.polling.lost_polls: 84925
kern.polling.pending_polls: 0
kern.polling.residual_burst: 0
kern.polling.handlers: 1
kern.polling.enable: 1
kern.polling.phase: 0
kern.polling.suspect: 39272
kern.polling.stalled: 5
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.9-RELEASE #8: Sat Feb 28 23:42:41 GMT 2004
Timecounter "i8254" frequency 1193182 Hz
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2806.38-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0xf29 Stepping = 9
Features=0xbfebfbff
MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Hyperthreading: 2 logical CPUs
real memory = 2147418112 (2097088K bytes)
avail memory = 2085978112 (2037088K bytes)
Preloaded elf kernel "kernel" at 0xc04fa000.
Warning: Pentium 4 CPU: PSE disabled
Pentium Pro MTRR support enabled
md0: Malloc disk
Using $PIR table, 12 entries at 0xc00fdea0
npx0: on motherboard
npx0: INT 16 interface
pcib0: on motherboard
pci0: on pcib0
pcib1: at device 1.0 on pci0
pci1: on pcib1
pcib2: at device 3.0 on pci0
pci2: on pcib2
em0: port
0xb000-0xb01f
mem 0xf300-0xf301 irq 12 at device 1.0 on pci2
em0: Speed:N/A Duplex:N/A
uhci0: port 0xcc00-0xcc1f
irq 11 at
device 29.0 on pci0
usb0: on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1: port 0xc000-0xc01f
irq 3 at d
evice 29.1 on pci0
usb1: on uhci1
usb1: USB revision 1.0
uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2: port 0xc400-0xc41f
irq 12 at
device 29.2 on pci0
usb2: on uhci2
usb2: USB revision 1.0
uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
uhci3: port 0xc800-0xc81f
irq 11 at
device 29.3 on pci0
usb3: on uhci3
usb3: USB revision 1.0
uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub3: 2 ports with 2 removable, self powered
pci0: at 29.7 irq 7
pcib3: at device 30.0 on pci0
pci3: on pcib3
ahd0: port
0x9400-0x94ff,0x9000-0x90ff m
em 0xf202-0xf2021fff irq 11 at device 0.0 on pci3
aic7901A: Ultra320 Wide Channel A, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs
pci3: (vendor=0x105a, dev=0x3373) at 3.0 irq 10
pci3: at 7.0 irq 11
pci3: (vendor=0x8086, dev=0x1051) at 8.0 irq 5
isab0: at device 31.0 on pci0
isa0: on isab0
atapci0: port
0xf000-0xf00f,0-0x3,0-0x7,0-0x3,0-0
x7 irq 0 at device 31.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: (vendor=0x8086, dev=0x24d3) at 31.3 irq 9
orm0: at iomem 0xc-0xc7fff,0xc8000-0xd17ff on isa0
pmtimer0 on isa0
fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
atkbdc0: at port 0x60,0x64 on isa0
atkbd0: irq 1 on atkbdc0
kbd0 at atkbd0
vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0
sc0: at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1: configured irq 3 not in bitmap of probed irqs 0
ppc0: parallel port not found.
DUMMYNET initialized (011031)
IP packet filtering initialized, divert disabled, rule-based forwarding
enabled,
default to accept, logging limited to 100 packets/entry by default
Waiting 15 seconds for SCSI devices to settle
Mounting root from ufs:/dev/da0s1a
da0 at ahd0 bus 0 target 0 lun 0
da0: Fixed Direct Access SCSI-3 device
da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged
Queueing Enabl
ed
da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C)
em0: Link is up 1000 Mbps Full Duplex
Limiting closed port RST response from 76352 to 200 packets per second
Limiting closed port RST response from 75963 to 200 packets per second
Limiting closed port RST response from 74737 to 200 packets per second
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0, polling performance, P4 2.8ghz FSB 800mhz
It was kindly pointed out that I didn't including the symptoms of the
problem:
Without polling on, I get 70+% interrupt load, and I get live lock.
With polling on, I start getting huge amounts of input errors, packet
loss, and general unresponsiveness to the network. The web server on it
doesn't respond though it occassionally will open the connection, just
not respond. accept_filter on/off makes no difference. I have read other
posts that say em systems can more >200kpps without serious incident.
Thanks in advance,
DJ
Deepak Jain wrote:
I have a machine running 4.9. P4 2.8Ghz, 800mhz bus, Intel PRO/1000
ethernet connected to a Cisco, both sides are locked to 1000/FD.
The kernel has HZ=1000, and DEVICE_POLLING, IPFW, DUMMYNET, etc. After
only a few minutes of run time under an attack ~90,000 pps. The attack
has been limited at the router to JUST incoming TCP port 80 inbound
traffic. I don't know why the machine is having such a hard time under
the load. The cpu shows it is >90% idle even under the worst of the
attack. What am I doing wrong?
Thanks,
DJ
#sysctl -a |grep hz
kern.clockrate: { hz = 1000, tick = 1000, tickadj = 1, profhz = 1024,
stathz = 1
28 }
#sysctl -a |grep polling
kern.polling.burst: 544
kern.polling.each_burst: 30
kern.polling.burst_max: 550
kern.polling.idle_poll: 1
kern.polling.poll_in_trap: 0
kern.polling.user_frac: 50
kern.polling.reg_frac: 30
kern.polling.short_ticks: 44151
kern.polling.lost_polls: 84925
kern.polling.pending_polls: 0
kern.polling.residual_burst: 0
kern.polling.handlers: 1
kern.polling.enable: 1
kern.polling.phase: 0
kern.polling.suspect: 39272
kern.polling.stalled: 5
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.9-RELEASE #8: Sat Feb 28 23:42:41 GMT 2004
Timecounter "i8254" frequency 1193182 Hz
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2806.38-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0xf29 Stepping = 9
Features=0xbfebfbff
MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Hyperthreading: 2 logical CPUs
real memory = 2147418112 (2097088K bytes)
avail memory = 2085978112 (2037088K bytes)
Preloaded elf kernel "kernel" at 0xc04fa000.
Warning: Pentium 4 CPU: PSE disabled
Pentium Pro MTRR support enabled
md0: Malloc disk
Using $PIR table, 12 entries at 0xc00fdea0
npx0: on motherboard
npx0: INT 16 interface
pcib0: on motherboard
pci0: on pcib0
pcib1: at device 1.0 on pci0
pci1: on pcib1
pcib2: at device 3.0 on pci0
pci2: on pcib2
em0: port
0xb000-0xb01f
mem 0xf300-0xf301 irq 12 at device 1.0 on pci2
em0: Speed:N/A Duplex:N/A
uhci0: port 0xcc00-0xcc1f
irq 11 at
device 29.0 on pci0
usb0: on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1: port 0xc000-0xc01f
irq 3 at d
evice 29.1 on pci0
usb1: on uhci1
usb1: USB revision 1.0
uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2: port 0xc400-0xc41f
irq 12 at
device 29.2 on pci0
usb2: on uhci2
usb2: USB revision 1.0
uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
uhci3: port 0xc800-0xc81f
irq 11 at
device 29.3 on pci0
usb3: on uhci3
usb3: USB revision 1.0
uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub3: 2 ports with 2 removable, self powered
pci0: at 29.7 irq 7
pcib3: at device 30.0 on pci0
pci3: on pcib3
ahd0: port
0x9400-0x94ff,0x9000-0x90ff m
em 0xf202-0xf2021fff irq 11 at device 0.0 on pci3
aic7901A: Ultra320 Wide Channel A, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs
pci3: (vendor=0x105a, dev=0x3373) at 3.0 irq 10
pci3: at 7.0 irq 11
pci3: (vendor=0x8086, dev=0x1051) at 8.0 irq 5
isab0: at device 31.0 on pci0
isa0: on isab0
atapci0: port
0xf000-0xf00f,0-0x3,0-0x7,0-0x3,0-0
x7 irq 0 at device 31.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: (vendor=0x8086, dev=0x24d3) at 31.3 irq 9
orm0: at iomem 0xc-0xc7fff,0xc8000-0xd17ff on isa0
pmtimer0 on isa0
fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
atkbdc0: at port 0x60,0x64 on isa0
atkbd0: irq 1 on atkbdc0
kbd0 at atkbd0
vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0
sc0: at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1: configured irq 3 not in bitmap of probed irqs 0
ppc0: parallel port not found.
DUMMYNET initialized (011031)
IP packet filtering initialized, divert disabled, rule-based forwarding
enabled,
default to accept, logging limited to 100 packets/entry by default
Waiting 15 seconds for SCSI devices to settle
Mounting root from ufs:/dev/da0s1a
da0 at ahd0 bus 0 target 0 lun 0
da0: Fixed Direct Access SCSI-3 device
da0: 320.000MB/
Re: em0, polling performance, P4 2.8ghz FSB 800mhz
Don Bowman wrote: I have a machine running 4.9. P4 2.8Ghz, 800mhz bus, Intel PRO/1000 ethernet connected to a Cisco, both sides are locked to 1000/FD. The kernel has HZ=1000, and DEVICE_POLLING, IPFW, DUMMYNET, etc. After only a few minutes of run time under an attack ~90,000 pps. The attack has been limited at the router to JUST incoming TCP port 80 inbound traffic. I don't know why the machine is having such a hard time under the load. The cpu shows it is >90% idle even under the worst of the attack. What am I doing wrong? I think there's a problem with CPU time not getting properly accounted for in device polling, so it may be busier than you think. For this scenario, i would set net.inet.tcp.blackhole=2. You might be spending a lot of time creating the ICMP unreachable messages, rather than in the network driver (where device polling would help). I'd like to know more about the CPU time idea. I have net.inet.udp.blackhole=2 and net.inet.tcp.blackhole=2 because I saw a lot of dstunreachable packets out. The system can hyperthread, but I thought the singlethreading of polling might have been an issue, so I recompiled the kernel without SMP. DJ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0, polling performance, P4 2.8ghz FSB 800mhz
And this was picked up in the messages log: /kernel: stray irq 7 last message repeated 2 times /kernel: too many stray irq 7's; not logging any more DJ Don Bowman wrote: I have a machine running 4.9. P4 2.8Ghz, 800mhz bus, Intel PRO/1000 ethernet connected to a Cisco, both sides are locked to 1000/FD. The kernel has HZ=1000, and DEVICE_POLLING, IPFW, DUMMYNET, etc. After only a few minutes of run time under an attack ~90,000 pps. The attack has been limited at the router to JUST incoming TCP port 80 inbound traffic. I don't know why the machine is having such a hard time under the load. The cpu shows it is >90% idle even under the worst of the attack. What am I doing wrong? I think there's a problem with CPU time not getting properly accounted for in device polling, so it may be busier than you think. For this scenario, i would set net.inet.tcp.blackhole=2. You might be spending a lot of time creating the ICMP unreachable messages, rather than in the network driver (where device polling would help). --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0, polling performance, P4 2.8ghz FSB 800mhz
Don Bowman wrote: It was kindly pointed out that I didn't including the symptoms of the problem: Without polling on, I get 70+% interrupt load, and I get live lock. With polling on, I start getting huge amounts of input errors, packet loss, and general unresponsiveness to the network. The web server on it doesn't respond though it occassionally will open the connection, just not respond. accept_filter on/off makes no difference. I have read other posts that say em systems can more >200kpps without serious incident. Thanks in advance, DJ You may need to increase the MAX_RXD inside your em driver to e.g. 512. I didn't know if my card had a buffer bigger than the default 256. I can increase it, but I didn't know how to determine how big a MAX_RXD my card would support. When the system was under load, it was generating 2xHZ clock ticks (2000 when HZ was 1000) is that normal? With similar system, em can handle ~800Kpps of bridging. What settings did you use? Your earlier email showed a very large number of RST messages, which makes me suspect the blackhole actually wasn't enabled. Not exactly sure what you're trying to do here. It sounds like you are trying to generate a SYN flood on port 80, and your listen queue is backing up. You've increased kern.ipc.somaxconn? Does your application specify a fixed listen queue depth? Could it be increased? Are you using apache as the server? Could you use a kqueue-enabled one like thttpd? Using apache, might go to squid or thttpd. Didn't think it should make a big deal. Increased somaxconn. Basically the system is getting hammered (after all filtering at the router) with valid get requests on port 80. Have you checked net.inet.ip.intr_queue_drops? If its showing >0, check net.inet.ip.intr_queue_maxlen, perhaps increase it. net.inet.ip.intr_queue_maxlen: 500 net.inet.ip.intr_queue_drops: 0 p1003_1b.sigqueue_max: 0 No intr drops. Have you sufficient mbufs and clusters? netstat -m. 1026/5504/262144 mbufs in use (current/peak/max): 1026 mbufs allocated to data 1024/5460/65536 mbuf clusters in use (current/peak/max) 12296 Kbytes allocated to network (6% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines mbufs look fine. If you want to spend more time in kernel, perhaps change kern.polling.user_frac to 10? I'll do that. I might have HZ @ 2500 as well. You could use ipfw to limit the damage of a syn flood, e.g. a keep-state rule with a limit of ~2-5 per source IP, lower the timeouts, increase the hash buckets in ipfw, etc. This would use a mask on src-ip of all bits. something like: allow tcp from any to any setup limit src-addr 2 This is a great idea. We were trapping those who crossed our connection thresholds and blackholing them upstream (automatically, with a script). this would only allow 2 concurrent TCP sessions per unique source address. Depends on the syn flood you are expecting to experience. You could also use dummynet to shape syn traffic to a fixed level i suppose. now... this will switch the DoS condition to elsewhere in the kernel, and it might not win you anything. net.inet.ip.fw.dyn_buckets=16384 net.inet.ip.fw.dyn_syn_lifetime=5 net.inet.ip.fw.dyn_max=32000 might be called for if you try that approach. I see where that should get us. We'll see. Thanks! DJ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0, polling performance, P4 2.8ghz FSB 800mhz
You could use ipfw to limit the damage of a syn flood, e.g. a keep-state rule with a limit of ~2-5 per source IP, lower the timeouts, increase the hash buckets in ipfw, etc. This would use a mask on src-ip of all bits. something like: allow tcp from any to any setup limit src-addr 2 this would only allow 2 concurrent TCP sessions per unique source address. Depends on the syn flood you are expecting to experience. You could also use dummynet to shape syn traffic to a fixed level i suppose. Does that really help? If so, we need to optimize the syncache. :( I know that if I rate shape the setup traffic, it helps. DJ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
4.9 boot problem on em0 platform.
As a part of tracking down a performance issue, I tried building a custom kernel (with just IPFW, DUMMYNET added, NMBCLUSTERS, commenting out MATH_EMULATE, INET6, I386, I486). The system is currently running a kernel from a similar machine with the same settings. The machine does run on this kernel: 4.9-RELEASE FreeBSD 4.9-RELEASE #8, with the above options, but I have not been able to compile a 4.9-RELEASE #2 (which is the source tree on the machine) kernel that has an identical config file. So, when it builds itself from -RELEASE sources, it hangs at: "pmap_mapdev: Couldn't alloc kernel virtual memory" I couldn't find a reference to anything recent. Nothing non-default (from a GENERIC kernel) with respect to ACPI has been touched. I see a reference to -CURRENT from 9/03, but that's it. Should I turn off power management? Is there a way to prevent ACPI support from being loaded at the kernel level? Should I just cvsup to 4.9-RELENG and try it again? It would be very nice if this were some how related to my network performance problem, but that might be too much to hope for. :) Thanks in advance, DJ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4.9 boot problem on em0 platform.
Just a guess, but i think you've bumped nmbclusters or nmbufs up too much (or perhaps maxsockets, maxfds, ...) and have run out of KVA. You can tune clusters & mbufs in loader.conf without recompiling kernel. You will want to see what vm.zone_kmem_pages, vm.zone_kmem_kvaspace are showing you, vmstat -z, vmstat -m, etc. You may want to alter VM_KMEM_SIZE_SCALE to e.g. '2' if you are trying to put more into the kernel mem space. The kernel that works from another machine has the same settings (NMBCLUSTERS=65536, maxusers=512). The machine has 2GB of RAM. How do you undo the loader.conf settings when the machine won't boot because of the settings you made? :| thanks, Deepak ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: KVA space problems?
Dag-Erling Smørgrav wrote: First of all, you need to realize that GoBSD is a DragonFly advocacy site. That doesn't necessarily make it a bad site, but it does mean it's biased. I'm only going to respond to the opinion section of the post, not the technical patch. "The successor of the very stable and reliable line of the FreeBSD 4.x series is the development line of DragonFlyBSD." -http://gobsd.com/bsd My question to that author would be "Why base something off of something unstable?" For the record, we run over 35,000 FreeBSD machines all over the world (real number is higher, I'm just giving you the last total I have) as production, 24/7 machines on our own network. We are fine with DragonFly too, but its more like choosing from types of the same fruit, not necessarily apples and oranges.. think Golden Delicious vs Red Delicious. I don't have anything to technically discuss the memory concerns in that patch only that everything is solvable. Yahoo and hundreds of other companies rely on FreeBSD for production equipment. DJ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FW: Interesting Router Question
-Original Message- From: Deepak Jain [mailto:[EMAIL PROTECTED]] Sent: Monday, August 27, 2001 7:04 PM To: FreeBSD-Questions; freebsd-isp@FreeBSD. ORG Subject: Interesting Router Question We've got a customer running a FreeBSD router with 2 x 1GE interfaces [ti0 and ti1]. At no point was bandwidth an issue. The router was under some kind of ICMP attack: For about 30 minutes: icmp-response bandwidth limit 96304/200 pps icmp-response bandwidth limit 97801/200 pps icmp-response bandwidth limit 97936/200 pps icmp-response bandwidth limit 97966/200 pps icmp-response bandwidth limit 98230/200 pps icmp-response bandwidth limit 97998/200 pps icmp-response bandwidth limit 98132/200 pps icmp-response bandwidth limit 98326/200 pps icmp-response bandwidth limit 98091/200 pps icmp-response bandwidth limit 87236/200 pps icmp-response bandwidth limit 85108/200 pps icmp-response bandwidth limit 84609/200 pps icmp-response bandwidth limit 86915/200 pps icmp-response bandwidth limit 88917/200 pps icmp-response bandwidth limit 88218/200 pps icmp-response bandwidth limit 72871/2 pps icmp-response bandwidth limit 74934/2 pps icmp-response bandwidth limit 74507/2 pps icmp-response bandwidth limit 82928/2 pps icmp-response bandwidth limit 75657/2 pps The router is a dual 600mhz PIII and had a load average of about 0.2 peak during the entire event, but was running out of buffer space. A ping would return "No buffer space available". Performance became atrocious with high packet loss and latency, but completely buffer related. The mbuf settings are as follows: 1235/2640/67584 mbufs in use (current/peak/max): 1195 mbufs allocated to data 40 mbufs allocated to packet headers 592/1054/16896 mbuf clusters in use (current/peak/max) 2768 Kbytes allocated to network (5% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines sysctl settings: net.inet.ip.redirect: 0 net.local.stream.sendspace: 255360 net.local.stream.recvspace: 8192 net.inet.icmp.drop_redirect: 1 net.inet.icmp.log_redirect: 1 net.inet.icmp.bmcastecho: 0 net.inet.tcp.sendspace: 524288 net.inet.tcp.recvspace: 524288 net.inet.udp.recvspace: 524288 What settings need to be tweaked to allow more ICMP-related buffers to allow the system's CPU to discard packets normally. ipfw didn't help or hurt this performance [i.e., blocking ICMPs or not] same result. The solution was to install an ICMP filter on the Cisco feeding this customer. Under normal circumstances, this is what a netstat -i 1 returns: input(Total) output packets errs bytespackets errs bytes colls 43001 0 12845737 42965 0 12715776 0 42589 0 12426503 42624 0 12299112 0 42485 0 12804047 42409 0 12675087 0 42059 0 12324347 42060 0 12197342 0 42989 0 13004977 42985 0 12875017 0 42331 0 12608670 42353 0 12481620 0 42327 0 12941571 42252 0 12815136 0 42435 0 12414956 42451 0 12288774 0 43408 0 13065007 43369 0 12932819 0 42849 0 12649420 42853 0 12521309 0 42328 0 12918886 42349 0 12788549 0 44085 0 13469072 44009 0 13337215 0 47849 0 14434350 47686 0 14272423 0 Thanks for any assistance, Deepak Jain AiNET To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: FW: Interesting Router Question
I think this is EXACTLY what happened. We give the customer two upstream GigE connections and the customer is preferentially using one. Routes are actually staticly routed to both GigE interfaces. Is there an RFC you know of that says this is bad behavior? I guess we'll have to filter ICMP packets destined for the router from now on or remove one of the interfaces. Thanks, Deepak Jain AiNET -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Terry Lambert Sent: Friday, August 31, 2001 3:53 PM To: [EMAIL PROTECTED] Cc: freebsd-hackers@FreeBSD. ORG Subject: Re: FW: Interesting Router Question Deepak Jain wrote: > We've got a customer running a FreeBSD router with 2 x 1GE interfaces [ti0 > and ti1]. At no point was bandwidth an issue. > > The router was under some kind of ICMP attack: > > For about 30 minutes: > icmp-response bandwidth limit 96304/200 pps I've seen this happen in a lab when there are a large number of ICMP redirects coming into the machine from the next hop, which doesn't believe itself to be the next hop, directing you to the "real" next hop. This can happen with asymmetric routes. You can also see this in the NAT case, where you get a gateway redirect to the NAT box from the local gateway, with a "ping". Stopping and restarting the "ping" makes it honor the redirect for subsequent packets, but the initial "ping" program does not honor it after the first (or nth) time it gets the redirect: it merrily pounds away at the redirecting machine. I don't know why the route does not get adjusted like it should, so that subsequent attempts don't trigger the redirect, but it doesn't (this seems to be a problem with the FreeBSD routing code). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Routing Performance?
The new P4s are shipping with 800mhz RAMBUS memory modules. Wouldn't 2GB of 800mhz RAM go a long way to evening out the performance between a PC/FreeBSD box and all but the most specialized, packet-pushing ASICs? I was doing some rough figuring, and could see how a P4 with its new bus and memory path would have trouble forwarding at least 2Gb/s. Am I missing something? Deepak Jain AiNET To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Flow cache on FreeBSD?
Is there a way to provide functionality similar to ip flow cache stats on a FreeBSD router? Let me clarify, I am talking about being able to easily see groupings of traffic go through a FreeBSD box. So if a downstream customer is being attacked, a simple table in realtime [or near real-time] will show the attack characteristics [ip ranges, packet types, general number of packets, etc].? Thanks, Deepak Jain AiNET To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Kernel-loadable Root Kits
Short question: Is there a way to prevent the kernel from allowing loadable modules? Thought process -- --- With the advent of the kernel-loadable root kit, intrusion detection has gotten a bit more complicated. Is there a _simple_ solution to detecting the presence of a kernel-based root kit once it is running? Scenario: System is violated, Root kit is installed, Root kit [binaries] are deleted from the machine. Solution: Reboot machine How does one DETECT that the root kit is there in the first place to know to reboot it? Thanks, Deepak Jain AiNET To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: ping: sendto: No buffer space available
Try increasing your maxsockbuf: kern.ipc.maxsockbuf: 262144 is the default setting, try: sysctl -w kern.ipc.maxsockbuf=384000 [or higher, depending on your RAM and your network usage] There are a bunch of other network buffers you might want to tune as I am sure others will mention. Deepak Jain AiNET -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Saturday, February 09, 2002 2:58 PM To: [EMAIL PROTECTED] Subject: ping: sendto: No buffer space available Some times connections to my host freeze. What buffer ping talks about? ~:# ping p109 ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available PING p109.f434.n5020.z2.fidonet.org (192.168.44.109): 56 data bytes --- p109.f434.n5020.z2.fidonet.org ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss ~:# pstat -T 236/1064 files 0M/255M swap space ~:# netstat -m 97/128/4096 mbufs in use (current/peak/max): 49 mbufs allocated to data 48 mbufs allocated to packet headers 17/28/1024 mbuf clusters in use (current/peak/max) 88 Kbytes allocated to network (2% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines ~:# ifconfig ep0: flags=8c43 mtu 1500 inet 192.168.44.41 netmask 0xff00 broadcast 192.168.44.255 inet6 fe80::2a0:24ff:fe46:b823%ep0 prefixlen 64 scopeid 0x1 inet 192.168.44.42 netmask 0x broadcast 192.168.44.42 ether 00:a0:24:46:b8:23 media: Ethernet 10baseT/UTP faith0: flags=8000 mtu 1500 stf0: flags=0<> mtu 1280 lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff00 ppp0: flags=8051 mtu 1500 inet 192.168.10.202 --> 192.168.3.3 netmask 0xff00 ppp1: flags=8010 mtu 1500 ~:# uname -a FreeBSD f434.n5020.z2.fidonet.org 4.4-STABLE FreeBSD 4.4-STABLE #1: Wed Dec 26 22:47:45 MSK 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/PP i386 ~:# Seva. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
