Netgraph ng_bridge status message missing last three values?
I'm diagnosing a system that uses the Netgraph ng_bridge node to bridge
two Ethernet segments and the system seems to stop passing traffic at
randomly-triggered points (somewhat annoying for a system half a world
away behind a very restrictive firewall :-)
I've installed a cron job to dump the Netgraph bridge status messages to
a log file every few minutes. However, I've found that the ng_bridge
status message looks like this:
ngctl msg bnet0: getstats 0
STATS=Rec'd response getstats (4) from [10]::
Args: { recvOctets=474229151 recvPackets=3322699 recvMulticast=128640
recvBroadcast=105813 recvUnknown=2372 xmitOctets=516954216
xmitPackets=2968420 xmitMulticasts=8 xmitBroadcasts=339 }
but to aid diagnosis I would really like to see several values that,
according to ng_bridge.h, are in the stats structure, including
recvRunts, recvInvalid, loopDrops, loopDetects, and memoryFailures. It
looks like all the code is there to report the values of these
variables, but I can't seem to find anything that is dropping these
variables from ngctl's output.
Any help is greatly appreciated,
Guy
--
Guy Helmer, Ph.D.
Chief System Architect
Palisade Systems, Inc.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: docs for 3Com 3C515-TX NIC?
On Fri, 30 Jul 1999, Steve Price wrote: Anyone have detailed docs for 3Com's 3C515 NIC? I found Guy Helmer's driver, http://www.freebsd.org/~ghelmer/3c515/ but it didn't recognize the card I have. I was going to spend some time this weekend to see if I could figure out what was up. Just thought it might be easier if I had a little light reading material that described how the chip on it was supposed to work. :) Have you tried booting with the "-v" flag to see the driver's probe messages? Did you configure the card using the configuration "pnp" commands before the kernel starts booting? For example, config pnp 1 0 irq0 9 port0 0x360 enable os did the trick for me on a 3.2 system. When I did an install of FreeBSD 3.2 on a machine with a 3C515, I was pleasantly surprised when sysinstall captured this config command and wrote it to the kernel.conf file for future boots. Anyway, the card is mostly the same as the Vortex (if_vx.c driver) but with some ports changed. Sorry, I don't happen to have tech docs for the card. Good luck, Guy Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science Research Assistant, Ames Laboratory --- [EMAIL PROTECTED] Research Assistant, Dept. of Computer Science --- [EMAIL PROTECTED] http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SYN flood and freebsd?
On Mon, 29 Nov 1999, Mark D. Anderson wrote: i've searched around deja and freebsd.org and come up wanting (email archives show rarely show resolutions...). what is the current status in stable and latest regarding defense against SYN flood, and how is it implemented? i found some discussion regarding the inadequacy of the "SYN cookie" defense added to linux -- i couldn't make out whether that fix has actually been withdrawn from linux or not. i also didn't find an explanation of exactly what was bad about it -- something about firewalls or NAT. see for example: http://x41.deja.com/getdoc.xp?AN=491586304CONTEXT=942635225.1891434518hitnum=26 I can't comment about the SYN-cookie approach, since I haven't heard about its pitfalls. and openbsd has apparently settled on a random dropping of old half-open connections. appreciate some clarification on this, as well as pointers to where answers to things like this might be found, for those of us who don't want to run grep through kernel sources. There was some discussion about this on freebsd-net or freebsd-hackers in September 1996 which can be reviewed by using the mail list search page at http://www.freebsd.org/search/search.html. Anyway, the CVS history gives the definitive answer for which you are looking. The pages at http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c and http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/uipc_socket2.c shows that random drop was implemented (see tcp_input.c versions 1.54 1.55 and uipc_socket2.c versions 1.15 1.16). Guy Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science Research Assistant, Ames Laboratory --- [EMAIL PROTECTED] Research Assistant, Dept. of Computer Science --- [EMAIL PROTECTED] Teaching Assistant, ComS 652 Distributed Operating Systems http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PR #10971, not dead yet.
On Wed, 31 May 2000, David E. Cross wrote: If you can reproduce the problem regularly then I recommend putting a signal guard in to see if the corruption is being caused by the signal interrupting at an inausipcious moment. In main() block SIGHUP, SIGINT, SIGTERM, and SIGCHLD using sigsetmask(). Just prior to the select call unblock the signals. Just after the select call reblock the signals. And see if the corruption still occurs. If this fixes the problem, then there is probably something in the reaper() (in yp_main.c) that is causing corruption, probably by ripping a structure out from under whatever piece of code the signal happens to interrupt. I took a quick look at the code and as far as I can tell it implements no guards whatsoever. The inetd code had similar problems in the past. Alas, this is not something I have been able to reliably reproduce, it seems to trigger itself every so-often (and at inconvienient times). But no matter what I do by myself it will not trip. Is it possibly related to a low-memory situation? I'm trying to solve a problem in cron that sounds similar, and seems to be triggered when the machine goes into swapping. I'm unable to duplicate it myself :-( Guy Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science Research Assistant, Dept. of Computer Science --- [EMAIL PROTECTED] http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: if_dc and bridging
FWIW, we have seen similar problems (poor throughput, TX underrun, and watchdog timeouts) with plain TCP (not bridging) on systems with built-in Davicom DM9102 devices running FreeBSD 4.0 and 4.2. Reboot improves the performance for a while. There seems to be a few problems with the Davicom chip... Guy Helmer, Ph.D. http://www.palisadesys.com/~ghelmer/ Sr. Software Engineer, Palisade Systems [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jacques Fourie Sent: Wednesday, April 25, 2001 10:53 AM To: [EMAIL PROTECTED] Subject: if_dc and bridging When doing bridging (Luigi's standard bridging code) using two Davicom DM9102A NIC's, I am seeing some strange results. If I do a 'ping -s 8000' between two PC's sitting on either side of the bridge, I see a whole bunch of TX underrun errors on both NIC's of the bridge. Eventually both are put into store and forward mode. After this, I can hardly get any traffic through the bridge at all (maximum throughput I have seen is around 1kB/s). After a reboot, everything is OK again. Does anyone have any idea what is going on? (The bridge is running 4.2-RELEASE) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: IPFW bug/incoming TCP connections being let in.
On Thu, 19 Oct 2000, Nate Williams wrote: I had blocked incoming TCP connections coming into my network using IPFW, and I noticed that my brother was able to establish a Napster connection, even though I had blocked it earlier. I thought, no worries, I'll just block it at the port level. I read a couple of articles, and noted that connections from to the server should be blocked. Easy enough, I'll just block my clients from establishing connections to port . Unfortunately, that doesn't work. Looking at tcpdump output, the 'server' appears to initiates a TCP connection from - some random port. My firewall rules do *NOT* allow incoming TCP connections to be made to internal machines, since they only allow 'setup' packets to go out. So, how can Napster work? What happened to the 3-way handshake? I could see an issue if the OS's were hacked to get around this and not require a 3-way handshake, but the client in this case in a Win98 box. The remote napster client sends a message through the central Napster server, which relays the message to your Napster client to tell your machine to make a connection to the remote machine. This is so that, as long as one of the two Napster clients are not behind a firewall, the two clients can communicate directly. The client behind the firewall makes the connection to the client that isn't behind a firewall, since most firewalls are configured to allow internal machines to make connections to any outside machine. The regular 3-way handshake is occurring. It's just not initiated by the machine you would expect. You'd have to block outgoing SYNs to any outside host at port (but anyone who knows anything about ports could change their port number and get around your block). Guy Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science Research Assistant, Dept. of Computer Science --- [EMAIL PROTECTED] http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCPDUMP patch v1.1 and AppleTalk
On Wed, 8 Nov 2000, Konrad Heuer wrote: On Tue, 7 Nov 2000, Kris Kennaway wrote: On Tue, Nov 07, 2000 at 01:56:21PM +0100, Konrad Heuer wrote: After patching and installing, tcpdump can't be used anymore since it puts very heavy load onto the network via xl0 and AppleTalk broadcast messages (one message each 0.2 ms). Sorry, in the moment I don't know more details ... tcpdump shouldn't be sending any appletalk packets, I thought (I may be wrong, never used it on an appletalk network). Are you sure this is the problem? Kris Well, I don't know exactly what happens but I seems to be more complex than I thought first. It doesn't happen each time I start tcpdump but when some circumstances meet which I don't know my FreeBSD host begins to flood the network with AppelTalk broadcast requests as long as tcpdump keeps running. Killing tcpdump kills this flooding, too. I've never observed such a situation before I applied the last patch, and I use tcpdump frequently to analyze the one or other problem. On the other hand, our network environment isn't static, of course, and I can't be sure about other things that may have been changed from day to day. PureConjecture If you are running the daemon that supports Appletalk (is it netatalk?), perhaps the Appletalk daemon becomes confused when tcpdump puts the Ethernet interface into promiscuous mode. It may be that the daemon expects to see only the Appletalk traffic directed to it, and seeing *all* Appletalk traffic on the wire makes it go nuts. /PureConjecture Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science Research Assistant, Dept. of Computer Science --- [EMAIL PROTECTED] http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Maestro audio in Dell Latitude CPt
Does anyone happen to have patches for FreeBSD 4.2 to make the pcm driver drive the sound device in the Dell Latitude CPt (identified as vendor 0x125d, dev 0x199[89])? If so, could you either send them to me or provide a pointer to them? Thanks, Guy -- Guy Helmer, Ph.D. Sr. Software Engineer, Palisade Systems --- [EMAIL PROTECTED] http://www.palisadesys.com/~ghelmer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Vendors of multi-port PCI ethernet cards?
Wes Peters wrote on Tuesday, May 04, 2004 12:08 AM: On Monday 26 April 2004 12:56, Steven Hartland wrote: Intel still do iirc. - Original Message - From: Stephen Hocking Does anyone know where I can lay my hands on one of those 4 port ethernet cards that used to be around a while back? http://www.zipzoomfly.com/jsp/ProductDetail.jsp?ProductCode=251442 They didn't show 10/100 cards, but they're still around. Does anyone know of any commodity dual-port Ethernet NICs that fail-through if the power fails (e.g., for a filtering bridge)? I've been looking but I haven't found anything yet. Thanks, Guy Helmer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Niagara 2250/2260 dual Gigabit passthrough NIC watchdog driver?
I'm looking at the Interface Masters Niagara 2250 dual gig passthrough NIC for a filtering system. It has a watchdog timer that can bypass the interfaces if the software fails to update the timer. Interface Masters' web site claims FreeBSD 4 support, but when asked they were only able to provide a Linux driver. Has anyone done a FreeBSD driver for this card or patched if_em.c for it? Thanks, Guy Helmer -- Guy Helmer, Ph.D., Principal System Architect, Palisade Systems, Inc. [EMAIL PROTECTED] http://www.palisadesys.com/~ghelmer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: pcap/bpf in a multi-threaded environment
On Friday, November 09, 2001 5:56 AM Edwin Groothuis [EMAIL PROTECTED]
wrote:
The past couple of days I've been plagued by a strange behaviour
of something between libpcap and the bpf-device. As you can read
in PR bin/31649, the behaviour of libpcap is very different if you
compile it on gcc with or without -pthread:
Without -pthread, it calls the callback function everytime it has
received a packet.
With -pthread, it calls the callback function only when the
input-buffer (about 32Kb) is nearly full.
I've done some investigation (with my limited knowledge of what
happens between a call to read() and when it ends up in bpfread())
and saw the difference between a call with and without the -pthreads
option:
in /usr/src/contrib/libpcap/pcap-bpf.c, line 81, the function pcap_read():
cc = read(p-fd, (char *)p-buffer, p-bufsize);
at a certain moment, in the read()-code, bpfread() is called:
/sys/net/bpf.c, line 491
In a non-threaded environment, this if-statement is false
if (ioflag IO_NDELAY) {
splx(s);
return (EWOULDBLOCK);
}
In a threaded environment, the if-statement is true, splx(s) is
called and EWOULDBLOCK is returned. Then it's silent for a while,
while the packets are being collected (somewhere) and at a certain
moment the buffer is nearly full and the read() in pcap_read() is
finished.
So yeah, I'm stuck. All I want is in threaded mode to have the same
behaviour as I have in non-threaded mode. Anybody any ideas on how
to fix this?
The problem is probably due to the poll system call that the threaded
library does before performing the read(). In the non-threaded case, the
read() returns when the timeout is hit; in the threaded case, the threaded
library's poll() has to succeed before the read system call will be
executed, and poll() won't succeed until the buffer is full.
If you would like to try this patch (relative to FreeBSD 4.3) to
/sys/net/bpf.c and /sys/net/bpfdesc.h and let me know if it helps, I will
add this patch to PR 22063 and perhaps commit it if it passes review.
Guy Helmer
bpf-new.diff
Description: Binary data
Re: tty's and no login
Cole wrote: Hey Im not sure if this is the right list, but anyway, let me know if im wrong. What im trying to do is, have a custom program run on a specific tty. Say like ttyv4, or so. But I would like to do this without having to login to this ttyv. So instead of being presented with a login option, I would like to be able to switch to ttyv4, and have it show me the output of the program that is running and using that terminal for output. So exactly where about do you go about doing something like this? Is there something already created to do this? On a physically-secured machine I have this setup for ttyv1 in /etc/ttys: ttyv1 /usr/libexec/getty IPMonitor cons25 on secure and then in /etc/gettytab I have this entry for IPMonitor: IPMonitor:\ :al=ipmonitor:tc=Pc: Next, I have a special user named ipmonitor that is locked out (the password field is set to *LOCKED* in master.passwd) but has a special login script, like this: ipmonitor:*LOCKED*:65499:65499::0:0:IP Monitor Screen:/home/ipmonitor:/home/ipmonitor/bin/monitor.sh Finally, the special login script for ipmonitor is this simple script: #!/bin/sh exec /usr/bin/systat -ip I've also used vidcontrol with the -s option in a script like this to grab the screen. Hope this helps, Guy -- Guy Helmer, Ph.D. Principal System Architect Palisade Systems, Inc. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.7 RELEASE crashing when transferring large files over thenetwork
On 6 Nov 2002, Al-Afu wrote: Dear All, As per the subject line, I have been experiencing this for the past two weeks now. References: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=222082+0+archive/2002/freebsd-stable/20021027.freebsd-stable http://docs.freebsd.org/cgi/getmsg.cgi?fetch=630174+0+archive/2002/freebsd-stable/20021020.freebsd-stable Symptoms: When I transfer a large file across the network, either via SMB or scp, my 4.7-RELEASE will initiate a transfer for around a minute, then everything will cease. System will crash leaving no core dumps for me to submit a backtrace. I even have a 700MB file handy whenever I feel the mood to crash my 4.7-RELEASE. ... NOTE: I am ruling out faulty hardware since I dont get this behaviour if I re-boot with 4.6.2-RELEASE kernel. What hardware devices do you have on your system? In particular, the fxp driver in 4.7 for the Intel Fast Ethernet interface may cause crashes. A fix for this problem is being worked on... Guy -- Guy Helmer, Ph.D. http://www.palisadesys.com/~ghelmer Sr. Software Engineer, Palisade Systems [EMAIL PROTECTED] In this place it takes all the running you can do, to keep in the same place. -- Lewis Carroll's Through the Looking Glass To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: mount_null evil ?
On Mon, 2003-03-10 at 15:32, Andrew J Caines wrote: Marc, I?m currently developing a jail-management solution - I use a readonly mount_null for central software-management of the jails. The manpage was written May 1, 1995 - is using this tool still dangerous I have used it for read-only mounts since way back and have not have any problems, including brief periods of high I/O. I'd have reservations allowing unique data on a read-write mount, however I just did a few quick and simple tests of reads and writes on a rw null mount on my 4.8-RC box with no apparent problem. I seemed to be able to crash the kernel regularly under FreeBSD 4.5 when I used null mounts to share a read-only filesystem between jails. My application frequently rebuilt the jails by unmounting everything, wiping out the old jail subdirectories, writing new jail subdirectories, and remounting the shared read-only fs into each jail subdirectory. I gave up on null mounts and went back to having a separate copy of the entire filesystem for each jail. If null mounts work better now, I'll revisit it... Guy -- Guy Helmer [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: nullfs and unionfs
On Wednesday, December 19, 2001 7:09 PM BOUWSMA Beery wrote: Is it safe (relatively speaking) to use the null and the union filesystems? The LINT kernel config file still includes dire warnings, as do the man pages, but so far I've successfully mounted a handful of filesystems without panicking my system, though I've been careful to do it read-only when possible ... I do this by keeping the actual source read-write for cvsup in /usr/local/system, which I then mount_null read-only on /usr/src. (Likewise ports and stuff) Over top of this nullfs /usr/src I mount read-write my own directory which gets my changes in /usr/local/source-hacks. It looks like there are still some serious problems with this. I just tried a similar thing on FreeBSD 4.4 and 4.5. I created a directory of binaries to use for multiple jails, then null-mounted (read-only) the binaries for each of the jails to use. To allow the /etc and other parts of the jails to be written, I union-mounted a per-jail writeable filesystem over each of the null mounts. It seemed to work well until my jail setup program actually started a binary from inside the jail (i.e., from the null mount) when the kernel panic'ed with trap 12. Guy Helmer Palisade Systems, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: logging securelevel violations
Jeff Jirsa wrote: I've noticed that currently, violations of securelevel are aborted, but not typically logged. It seems like in addition to aborting whichever calls are in progress, logging an error might be beneficial. I recognize that this goes along the same lines as logging file permission errors, but if a file is marked immutable, the implicit value of the file should suggest that one might want to be able to audit attempted changes to that file. I think this would be useful, but I would be concerned about the rate at which these messages could come when someone is actively attacking a system. Perhaps such messages could go through a rate limiter mechanism similar to that now used by the network interfaces. I am not certain whether this addition would affect the TrustedBSD work, either. Guy Helmer To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: binary compatibility query
Carl Shapiro wrote: Kris Julian Thank you for clarifiying the compatibility situation. This information was exactly what I was looking for. I have a follow-up question based on this remark... On 5/5/08, Kris Kennaway [EMAIL PROTECTED] wrote: Actually we don't attempt to keep this form of ABI compatibility (running 6.3 binaries on 6.0, for example), because it basically precludes ever adding new functions to libc within a branch, or new syscalls to the kernel. You are correct that often binaries will not notice these accumulated changes though, or can be carefully constructed to avoid them. If my binary only executes system calls indirectly through libc interfaces, as far as libc and libm are concerned, are new symbols the only thing I need to worry about? Not necessarily. For example, the DNS resolver library was updated between FreeBSD 6.1 and 6.2 to bind 9's resolver library, resulting in the disappearance of the _res symbol in 6.2. As long as you depend only on public interfaces, though, you should be fine. Guy -- Guy Helmer, Ph.D. Chief System Architect Palisade Systems, Inc. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intermittent system hangs on 7.2-RELEASE-p1
Linda Messerschmidt wrote: Well, this is interesting. I got really frustrated with the other approach, so I thought I'd thin a machine down absolutely as far as I could, eliminate every possible source of delay, and see what happens. I killed everything... cron, RPC, NFS, devd, gmon, nrpe, everything. The Apache and its exerciser are now the only things running on the machine, and the Apache is only touching an md0 swap device mounted on /mnt. I *still* get the hangs. It hangs for all sorts of different periods, but the duration of the stall is approximately inversely proportional to the chance of seeing it. To get a short delay, you need wait only a little bit. If you want a 2-3 second delay, you may have to wait 15-20 minutes. On what sort of hardware is this hang occurring? Several months ago I was trying to resolve an intermittent hang under FreeBSD 7. I collected a large number of crashdumps I created using the kernel debugger when I caught the machine hanging, but the backtraces were very inconsistent, and the hang was only occurring on Xeons with multithreading (older 2.8GHz and 3.6GHz Xeons). I was able to prevent the hang by setting mach.hyperthreading_enabled=0 in /boot/loader.conf, but I am still not sure why it worked. Guy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Self-encrypting hard drives
I'm looking into using self-encrypting hard drives (TCG Opal standard) with FreeBSD. In particular I want to use the auto-lock mode. I can't seem to find the details regarding how the authentication key is provided to the drive, and where there is any support in FreeBSD to enable unlocking the drive for use. Any pointers would be appreciated. Thanks, Guy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: docs for 3Com 3C515-TX NIC?
On Fri, 30 Jul 1999, Steve Price wrote: Anyone have detailed docs for 3Com's 3C515 NIC? I found Guy Helmer's driver, http://www.freebsd.org/~ghelmer/3c515/ but it didn't recognize the card I have. I was going to spend some time this weekend to see if I could figure out what was up. Just thought it might be easier if I had a little light reading material that described how the chip on it was supposed to work. :) Have you tried booting with the -v flag to see the driver's probe messages? Did you configure the card using the configuration pnp commands before the kernel starts booting? For example, config pnp 1 0 irq0 9 port0 0x360 enable os did the trick for me on a 3.2 system. When I did an install of FreeBSD 3.2 on a machine with a 3C515, I was pleasantly surprised when sysinstall captured this config command and wrote it to the kernel.conf file for future boots. Anyway, the card is mostly the same as the Vortex (if_vx.c driver) but with some ports changed. Sorry, I don't happen to have tech docs for the card. Good luck, Guy Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science Research Assistant, Ames Laboratory --- ghel...@scl.ameslab.gov Research Assistant, Dept. of Computer Science --- ghel...@cs.iastate.edu http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Initio INI-* SCSI card support
On Mon, 2 Aug 1999, David O'Brien wrote: Has anybody taken a look at the FreeBSD driver source at http://www.initio.com/source.zip for the INI-* cards? Is this something we should import into -CURRENT? It would be handy for me if it were brought in. FWIW, I'm using this driver with an SIIG AP-10 SCSI card under -current. Guy Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science Research Assistant, Ames Laboratory --- ghel...@scl.ameslab.gov Research Assistant, Dept. of Computer Science --- ghel...@cs.iastate.edu http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Puzzling performance
On a FreeBSD 7.1 SCHED_ULE kernel, I have a large number of files opened and mmapped (with MAP_NOSYNC option) for shared-memory communication between processes. Normally, memcpy() copies data into these shared-memory buffers in a reasonable amount of time closely related to the size of the copy (roughly 10us per 10KB). However, due to performance issues I've found that sometimes a memcpy() takes an abnormally long time (10ms for 40KB, and I suspect longer times occurring when I have not had monitoring enabled). The system doesn't seem to be in memory overcommit -- there is just a minor amount of swap in use, and I've not seen page-ins or page-outs while watching systat or vmstat. Since I'm using MAP_NOSYNC, I would not expect the pager to flush dirty pages to disk and cause add delays. Any ideas where to look? Might it help to pin threads to CPUs in case a thread is getting moved to a different core? Thanks, Guy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Review of changes for getnetgrent.c
To close PR bin/83340, I have this change worked up to resolve memory
allocation failure handling and avoid creating bad entries in the grp list due
to memory allocation failures while building a new entry.
Before committing, I wanted to run it past others to see if there were any
problems with it.
Thanks,
Guy
svn diff lib/libc/gen
Index: lib/libc/gen/getnetgrent.c
===
--- lib/libc/gen/getnetgrent.c (revision 235606)
+++ lib/libc/gen/getnetgrent.c (working copy)
@@ -203,9 +203,7 @@
if (parse_netgrp(group))
endnetgrent();
else {
- grouphead.grname = (char *)
- malloc(strlen(group) + 1);
- strcpy(grouphead.grname, group);
+ grouphead.grname = strdup(group);
}
if (netf)
fclose(netf);
@@ -417,7 +415,7 @@
parse_netgrp(const char *group)
{
char *spos, *epos;
- int len, strpos;
+ int len, strpos, freepos;
#ifdef DEBUG
int fields;
#endif
@@ -454,9 +452,9 @@
while (pos != NULL *pos != '\0') {
if (*pos == '(') {
grp = (struct netgrp *)malloc(sizeof (struct netgrp));
+ if (grp == NULL)
+ return(1);
bzero((char *)grp, sizeof (struct netgrp));
- grp-ng_next = grouphead.gr;
- grouphead.gr = grp;
pos++;
gpos = strsep(pos, ));
#ifdef DEBUG
@@ -477,6 +475,13 @@
if (len 0) {
grp-ng_str[strpos] = (char *)
malloc(len + 1);
+ if (grp-ng_str[strpos] ==
NULL) {
+ for (freepos = 0;
freepos strpos; freepos++)
+ if
(grp-ng_str[freepos] != NULL)
+
free(grp-ng_str[freepos]);
+ free(grp);
+ return(1);
+ }
bcopy(spos, grp-ng_str[strpos],
len + 1);
}
@@ -490,6 +495,8 @@
grp-ng_str[strpos] = NULL;
}
}
+ grp-ng_next = grouphead.gr;
+ grouphead.gr = grp;
#ifdef DEBUG
/*
* Note: on other platforms, malformed netgroup
@@ -526,7 +533,7 @@
static struct linelist *
read_for_group(const char *group)
{
- char *pos, *spos, *linep, *olinep;
+ char *pos, *spos, *linep;
int len, olen;
int cont;
struct linelist *lp;
@@ -534,6 +541,7 @@
#ifdef YP
char *result;
int resultlen;
+ linep = NULL;
while (_netgr_yp_enabled || fgets(line, LINSIZ, netf) != NULL) {
if (_netgr_yp_enabled) {
@@ -554,6 +562,7 @@
free(result);
}
#else
+ linep = NULL;
while (fgets(line, LINSIZ, netf) != NULL) {
#endif
pos = (char *)line;
@@ -576,8 +585,14 @@
pos++;
if (*pos != '\n' *pos != '\0') {
lp = (struct linelist *)malloc(sizeof (*lp));
+ if (lp == NULL)
+ return(NULL);
lp-l_parsed = 0;
lp-l_groupname = (char *)malloc(len + 1);
+ if (lp-l_groupname == NULL) {
+ free(lp);
+ return(NULL);
+ }
bcopy(spos, lp-l_groupname, len);
*(lp-l_groupname + len) = '\0';
len = strlen(pos);
@@ -595,15 +610,15 @@
} else
cont = 0;
if (len 0) {
- linep = (char *)malloc(olen + len + 1);
- if (olen 0) {
- bcopy(olinep, linep, olen);
- free(olinep);
+ linep = (char *)reallocf(linep, olen +
len + 1);
+ if (linep
Re: Review of changes for getnetgrent.c
On May 18, 2012, at 6:09 PM, Xin Li wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/18/12 14:58, Guy Helmer wrote:
To close PR bin/83340, I have this change worked up to resolve
memory allocation failure handling and avoid creating bad entries
in the grp list due to memory allocation failures while building a
new entry.
Before committing, I wanted to run it past others to see if there
were any problems with it.
%%%
@@ -477,6 +475,13 @@
if (len 0) {
grp-ng_str[strpos] = (char *)
malloc(len + 1);
+ if (grp-ng_str[strpos] ==
NULL) {
+ for (freepos = 0;
freepos strpos; freepos++)
+ if
(grp-ng_str[freepos] != NULL)
+
free(grp-ng_str[freepos]);
+ free(grp);
+ return(1);
+ }
bcopy(spos, grp-ng_str[strpos],
len + 1);
%%%
Like this?
if (len 0) {
grp-ng_str[strpos] = (char *)
malloc(len + 1);
+ if (grp-ng_str[strpos] ==
NULL) {
+ int freepos;
+ for (freepos = 0;
freepos strpos; freepos++)
+
free(grp-ng_str[freepos]);
+ free(grp);
+ return(1);
+ }
bcopy(spos, grp-ng_str[strpos],
len + 1);
}
There are a few return without space between the keyword and return value.
Do you recommend I fix all those instances in the file, or just the instances
in this patch?
Thanks,
Guy
This message has been scanned by ComplianceSafe, powered by Palisade's
PacketSure.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Review of changes for getnetgrent.c
On May 21, 2012, at 2:29 PM, Xin Li wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/21/12 12:02, Guy Helmer wrote:
On May 18, 2012, at 6:09 PM, Xin Li wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 05/18/12 14:58, Guy Helmer wrote:
To close PR bin/83340, I have this change worked up to resolve
memory allocation failure handling and avoid creating bad
entries in the grp list due to memory allocation failures while
building a new entry.
Before committing, I wanted to run it past others to see if
there were any problems with it.
%%% @@ -477,6 +475,13 @@ if (len 0) { grp-ng_str[strpos] =
(char *) malloc(len + 1); + if
(grp-ng_str[strpos] == NULL)
{ + for (freepos = 0;
freepos strpos; freepos++) +
if (grp-ng_str[freepos] != NULL) +
free(grp-ng_str[freepos]); +
free(grp); +
return(1); +} bcopy(spos,
grp-ng_str[strpos], len + 1);
%%%
Like this?
if (len 0) { grp-ng_str[strpos] = (char *) malloc(len + 1); +
if (grp-ng_str[strpos] == NULL) { +
int freepos; + for
(freepos = 0; freepos strpos; freepos++) +
free(grp-ng_str[freepos]); +
free(grp); +
return(1); +
} bcopy(spos, grp-ng_str[strpos], len + 1); }
There are a few return without space between the keyword and
return value.
Do you recommend I fix all those instances in the file, or just the
instances in this patch?
I'd recommend fixing them all (note that you could run into a bigger
commit as the switch() is not style(9) conformant at this time) and we
normally do it in two different commits (one style, and another
functional) when possible.
OK, thank you.
Guy
This message has been scanned by ComplianceSafe, powered by Palisade's
PacketSure.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Wednesday, June 6, 2012 8:36:04 PM UTC-5, Mark Felder wrote: Hi guys I'm excitedly posting this from my phone. Good news for you guys, bad news for us -- we were building HA storage on vmware for a client and can now replicate the crash on demand. I'll be posting details when I get home to my PC tonight, but this hopefully is enough to replicate the crash for any curious followers: ESXi 5 9 or 9-STABLE HAST 1 cpu is fine 1GB of ram UFS SUJ on HAST device No special loader.conf, sysctl, etc No need for VMWare tools Run Bonnie++ on the HAST device We can get the crash to happen on the first run of bonnie++ right now. I'll post the exact specs and precise command run in the PR. We found an old post from 2004 when we looked up the process state obtained from CTRL+T -- flswai -- which describes the symptoms nearly perfectly. http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2004-02/0250.html Hopefully this gets us closer to a fix... Is this a crash or a hang? Over the past couple of weeks, I've been working with a FreeBSD 9.1RC1 system under VMware ESXi 5.0 with a 64GB UFS root FS and 2TB ZFS filesystem mounted via a virtual LSI SAS interface. Sometimes during heavy I/O load (rsync from other servers) on the ZFS FS, this shows up in /var/log/messages: Sep 21 02:14:55 backups kernel: (da1:mpt0:0:1:0): WRITE(10). CDB: 2a 0 5 ee 60 16 0 1 0 0 Sep 21 02:14:55 backups kernel: (da1:mpt0:0:1:0): CAM status: SCSI Status Error Sep 21 02:14:55 backups kernel: (da1:mpt0:0:1:0): SCSI status: Busy Sep 21 02:14:55 backups kernel: (da1:mpt0:0:1:0): Retrying command Sep 21 02:18:44 backups kernel: (da1:mpt0:0:1:0): WRITE(10). CDB: 2a 0 3 ef 42 51 0 1 0 0 Sep 21 02:18:44 backups kernel: (da1:mpt0:0:1:0): CAM status: SCSI Status Error Sep 21 02:18:44 backups kernel: (da1:mpt0:0:1:0): SCSI status: Busy Sep 21 02:18:44 backups kernel: (da1:mpt0:0:1:0): Retrying command Sep 21 02:18:48 backups kernel: (da1:mpt0:0:1:0): WRITE(10). CDB: 2a 0 3 ef 64 51 0 1 0 0 Sep 21 02:18:48 backups kernel: (da1:mpt0:0:1:0): CAM status: SCSI Status Error Sep 21 02:18:48 backups kernel: (da1:mpt0:0:1:0): SCSI status: Busy Sep 21 02:18:48 backups kernel: (da1:mpt0:0:1:0): Retrying command Sep 21 02:18:49 backups kernel: (da1:mpt0:0:1:0): WRITE(10). CDB: 2a 0 3 ef 66 51 0 1 0 0 Sep 21 02:18:49 backups kernel: (da1:mpt0:0:1:0): CAM status: SCSI Status Error Sep 21 02:18:49 backups kernel: (da1:mpt0:0:1:0): SCSI status: Busy ... Sep 21 05:06:18 backups kernel: (da1:mpt0:0:1:0): WRITE(10). CDB: 2a 0 41 f3 94 99 0 1 0 0 Sep 21 05:06:18 backups kernel: (da1:mpt0:0:1:0): CAM status: SCSI Status Error Sep 21 05:06:18 backups kernel: (da1:mpt0:0:1:0): SCSI status: Busy Sep 21 05:06:18 backups kernel: (da1:mpt0:0:1:0): Retrying command These have been happening roughly every other day. mpt0 and em0 were sharing int 18, so today I put hint.mpt.0.msi_enable=1 into /boot/devices.hints and rebooted; now mpt0 is using int 256. I'll see if it helps. Guy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Panic in bpf.c catchpacket()
Still working this problem I've previously mentioned, and my working theory now
is a race between catchpacket() and this code in bpfread():
/*
* At this point, we know we have something in the hold slot.
*/
BPFD_UNLOCK(d);
/*
* Move data from hold buffer into user space.
* We know the entire buffer is transferred since
* we checked above that the read buffer is bpf_bufsize bytes.
*
* XXXRW: More synchronization needed here: what if a second thread
* issues a read on the same fd at the same time? Don't want this
* getting invalidated.
*/
error = bpf_uiomove(d, d-bd_hbuf, d-bd_hlen, uio);
BPFD_LOCK(d);
d-bd_fbuf = d-bd_hbuf;
d-bd_hbuf = NULL;
d-bd_hlen = 0;
bpf_buf_reclaimed(d);
BPFD_UNLOCK(d);
Assuming it's unwise to hold the descriptor lock over the uiomove() call, it
seems we at least need to check to make sure bd_hbuf is still valid:
@@ -809,10 +948,15 @@ bpfread(struct cdev *dev, struct uio *uio, int iof
error = bpf_uiomove(d, d-bd_hbuf, d-bd_hlen, uio);
BPFD_LOCK(d);
- d-bd_fbuf = d-bd_hbuf;
- d-bd_hbuf = NULL;
- d-bd_hlen = 0;
- bpf_buf_reclaimed(d);
+ if (d-bd_hbuf == NULL) {
+ printf(bpfread: lost race: bd_hbuf=%p bd_sbuf=%p bd_fbuf=%p\n,
+ d-bd_hbuf, d-bd_sbuf, d-bd_fbuf);
+ } else {
+ d-bd_fbuf = d-bd_hbuf;
+ d-bd_hbuf = NULL;
+ d-bd_hlen = 0;
+ bpf_buf_reclaimed(d);
+ }
BPFD_UNLOCK(d);
return (error);
This still seems vulnerable to me -- a ROTATE_BUFFERS() or reset_d() could be
done between the BPFD_UNLOCK() and the bpf_uiomove(). Would a new lock to
protect the buffers be necessary, or a flag+condition variable to indicate
hold buffer in use?
Guy
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
IO Performance under VMware on LSI RAID controller
Normally I build VMware ESXi servers with enterprise-class WD SATA drives and I/O performance in FreeBSD VMs on the servers is fine. Whenever I build a VMware ESXi server with a RAID controller, IO performance is awful in FreeBSD VMs. I've previously seen this effect with VMware ESXi 3ware 9690SA-8I and 9650 RAID controllers, and now I'm seeing similar performance with a Dell 6/iR controller. Any suggestions would be appreciated. Guy Details of the current environment: VMware ESXi 5.1 on Dell R610 4GB RAM, SAS 6/iR controller, 2x500GB disks in RAID1 set (default stripe size) and 1x1TB (no RAID). From VMware's client, I see I/O rates in the sub-MBps range and latencies peaking occasionally at 80 ms. FreeBSD 9.2 (RC2) amd64 in a VM with 2GB RAM assigned, virtual disks assigned from both the RAID1 set and 1TB (no RAID) drive, UFS+soft updates file systems. The virtual drives show up in FreeBSD attached to an mpt virtual controller: mpt0: LSILogic 1030 Ultra4 Adapter port 0x1400-0x14ff mem 0xd004-0xd005,0xd002-0xd003 irq 17 at device 16.0 on pci0 mpt0: MPI Version=1.2.0.0 I don't see anything else sharing the interrupt - vmstat -i shows: irq17: mpt077503 27 gstat is showing an abysmal 6 to 16 ops/s for requests on the virtual disks. I've used gpart to setup the GPT partition table on the virtual disk assigned from the 1TB drive with alignment for the first UFS partition at 1MB to try to optimize alignment: Geom name: da0 modified: false state: OK fwheads: 255 fwsectors: 63 last: 268435422 first: 34 entries: 128 scheme: GPT Providers: 1. Name: da0p1 Mediasize: 524288 (512k) Sectorsize: 512 Stripesize: 0 Stripeoffset: 20480 Mode: r0w0e0 rawuuid: d9e6e3e8-1bdb-11e3-b7c5-000c29cbf143 rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f label: gpboot length: 524288 offset: 20480 type: freebsd-boot index: 1 end: 1063 start: 40 2. Name: da0p2 Mediasize: 2147483648 (2.0G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 1048576 Mode: r1w1e2 rawuuid: fbd6cf40-1bdb-11e3-b7c5-000c29cbf143 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: gprootfs length: 2147483648 offset: 1048576 type: freebsd-ufs index: 2 end: 4196351 start: 2048 3. Name: da0p3 Mediasize: 4294967296 (4.0G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 2148532224 Mode: r1w1e1 rawuuid: 0658208d-1bdc-11e3-b7c5-000c29cbf143 rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b label: gpswap length: 4294967296 offset: 2148532224 type: freebsd-swap index: 3 end: 12584959 start: 4196352 4. Name: da0p4 Mediasize: 130995437056 (122G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 2148532224 Mode: r1w1e2 rawuuid: 0ca5bc32-1bdc-11e3-b7c5-000c29cbf143 rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b label: gpusrfs length: 130995437056 offset: 6443499520 type: freebsd-swap index: 4 end: 268435422 start: 12584960 Consumers: 1. Name: da0 Mediasize: 137438953472 (128G) Sectorsize: 512 Mode: r3w3e8 sysctl vfs shows: vfs.ufs.dirhash_reclaimage: 5 vfs.ufs.dirhash_lowmemcount: 179 vfs.ufs.dirhash_docheck: 0 vfs.ufs.dirhash_mem: 0 vfs.ufs.dirhash_maxmem: 3481600 vfs.ufs.dirhash_minsize: 2560 vfs.ufs.rename_restarts: 0 vfs.nfs.downdelayinitial: 12 vfs.nfs.downdelayinterval: 30 vfs.nfs.keytab_enctype: 1 vfs.nfs.skip_wcc_data_onerr: 1 vfs.nfs.nfs3_jukebox_delay: 10 vfs.nfs.reconnects: 0 vfs.nfs.bufpackets: 4 vfs.nfs.debuglevel: 0 vfs.nfs.callback_addr: vfs.nfs.realign_count: 0 vfs.nfs.realign_test: 0 vfs.nfs.nfs_directio_allow_mmap: 1 vfs.nfs.nfs_keep_dirty_on_error: 0 vfs.nfs.nfs_directio_enable: 0 vfs.nfs.clean_pages_on_close: 1 vfs.nfs.commit_on_close: 0 vfs.nfs.prime_access_cache: 0 vfs.nfs.access_cache_timeout: 60 vfs.nfs.diskless_rootpath: vfs.nfs.diskless_valid: 0 vfs.nfs.nfs_ip_paranoia: 1 vfs.nfs.defect: 0 vfs.nfs.iodmax: 20 vfs.nfs.iodmin: 0 vfs.nfs.iodmaxidle: 120 vfs.devfs.rule_depth: 1 vfs.devfs.generation: 113 vfs.nfsd.disable_checkutf8: 0 vfs.nfsd.server_max_nfsvers: 4 vfs.nfsd.server_min_nfsvers: 2 vfs.nfsd.nfs_privport: 0 vfs.nfsd.async: 0 vfs.nfsd.enable_locallocks: 0 vfs.nfsd.issue_delegations: 0 vfs.nfsd.commit_miss: 0 vfs.nfsd.commit_blks: 0 vfs.nfsd.mirrormnt: 1 vfs.nfsd.minthreads: 1 vfs.nfsd.maxthreads: 1 vfs.nfsd.threads: 0 vfs.nfsd.request_space_used: 0 vfs.nfsd.request_space_used_highest: 0 vfs.nfsd.request_space_high: 13107200 vfs.nfsd.request_space_low: 8738133 vfs.nfsd.request_space_throttled: 0 vfs.nfsd.request_space_throttle_count: 0 vfs.nfsd.fha.enable: 1 vfs.nfsd.fha.bin_shift: 22 vfs.nfsd.fha.max_nfsds_per_fh: 8 vfs.nfsd.fha.max_reqs_per_nfsd: 0 vfs.nfsd.fha.fhe_stats: No file handle entries. vfs.pfs.trace: 0 vfs.pfs.vncache.misses: 0 vfs.pfs.vncache.hits: 0 vfs.pfs.vncache.maxentries: 0 vfs.pfs.vncache.entries: 0 vfs.acl_nfs4_old_semantics: 0 vfs.flushwithdeps: 0 vfs.unmapped_buf_allowed: 1 vfs.barrierwrites: 1
Re: IO Performance under VMware on LSI RAID controller
On Sep 19, 2013, at 11:25 AM, Guy Helmer guy.hel...@gmail.com wrote: Normally I build VMware ESXi servers with enterprise-class WD SATA drives and I/O performance in FreeBSD VMs on the servers is fine. Whenever I build a VMware ESXi server with a RAID controller, IO performance is awful in FreeBSD VMs. I've previously seen this effect with VMware ESXi 3ware 9690SA-8I and 9650 RAID controllers, and now I'm seeing similar performance with a Dell 6/iR controller. Any suggestions would be appreciated. Guy (Replying to self due to hint received off-list) I seem to remember controllers mentioned previously by FreeBSD device driver developers that don't deal well with large I/O requests. It turns out that may be the case with VMware device drivers as well -- reducing the VMware Disk.DiskMaxIOSize value from its huge default of 32676KB to 32KB seems to have helped. Disk ops/sec in the FreeBSD VM are now peaking over 400/sec. Guy signature.asc Description: Message signed with OpenPGP using GPGMail
