Re: Digi AccelePort-USB 2, 4 or 8 port serial terminal server ?
> Nice serial server, anyone working for serial support on USB ? > Have an 8 port and could help getting support for it or testing > drivers. If you are or someone else is willing to write a driver under NDA I can give you the e-mail address of a guy who can give you the specifications for it. I dropped the idea of writing the driver as there were other, open source projects to be working on. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Hardware list idea
> I think openbsd asks users to email them the output of 'dmesg', > so they can tell which drivers are really of interest to the > greatest number of their users. Seems like a reasonable idea. You might want to include the list of packages installed from the base CD's as well to prime the packages that need to be there. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Basic question about threads and SMP
Being multi-threaded has almost nothing to do with being multi-processor. Multi-threading means that your application has multiple threads of execution that are able to run simultaneously. The multi-processing capability of your box means that 2 threads of execution, be it a process or a thread within a process, are executed _literally_ at the same time, and not in simulated concurrency like it happens on a UP box. Whether or not any application should be compiled with libc_r depends solely on the application itself. And, as you suggest, that is decided at build time. If applications support multi-threading they normally come with a Makefile using libc_r. Now, whether you want to multi-thread Apache is totally different issue ... Nick On Wed, 1 Dec 1999, Doug Barton wrote: > You know, a stray thought just occured to me, which hopefully > won't sound to silly to people who know about this stuff. :) If I have an > SMP box (using -Current specifically) do I want to be compiling things > with -lc_r? I'm thinking specifically of mission critical things like > apache, but in general will other ports and such take advantage of > libc_r if they are compiled with it, or would a program that _can_ take > advantage of it already have that built in, say into autoconf or some > such? What about other parts of the base system? I'm assuming that the > kernel is covered by virtue of the fact that I've enabled the SMP options, > yes? > > I'm trying to learn more about SMP, threads, and such like in > general. The recent conversations about those topics on the lists have > been very educational. I'm still wading through them, but I appreciate > being able to sit on the sidelines and glean bits here and there. > > Thanks, > > Doug > -- > "Welcome to the desert of the real." > > - Laurence Fishburne as Morpheus, "The Matrix" > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI DMA lockups in 3.2 (3.3 maybe?)
[snip] > I am a good programmer and can fix things :-). But I've had to deal with > a number of nightmare situations by commercial entities deploying FreeBSD > and at least three (including one very recently) where commercial entities > have refused to upgrade past 2.2.x due to perceived stability problems. [snip] > > -Matt > Matthew Dillon we can not identify the specific problem from this message. without sufficient information to indentify and hopefully reproduce the problem, we can not address it. please provide this information if it is available to you. if it is not, please provide us contact information for the commercial entities experiencing the problem. jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI DMA lockups in 3.2 (3.3 maybe?)
The "issue" that i first cited is that the core people in FreeBSD seemed disinterested in 3.x soon after its release. Development on 4.0 shouldnt even have begun until 3.x was stabilized. 3.0 wasnt ready for prime time when it was released and the work needed to get it there hasnt been done due to the fascination with 4.0. DB At 10:46 PM 12/4/99 -0800, Matthew Dillon wrote: > >:> >:> He didn't say this until after the situation had started to degrade. >:> >:> Besides, he's right. 3.x has serious problems. >: >:All running software has serious problems, that's why it is never considered >:done. Taking the time to enumerate specific problems that are currently >:plaguing an installation is the only way anyone can possibly hope to help. >:Problems reports of "It don't work" are helpful to absolutely noone. > >This simply isn't true. I have written plenty of software (large >projects) that do not have serious problems and, in fact, some do not >have any known problems at all. I have written several operating systems >and one of them is least as complex as the FreeBSD core (but not as >complex if you count drivers) which are bug-free (that is, there have >been no recorded crashes and except for feature updates have never been >rebooted). > >FreeBSD can become 'bug free' insofar as it is possible to become bug >free. You have to believe that it can happen or it won't. I believe >it can -- my personal goal for the project is to make the core bug free >and uncrashable (and here I mean only with a network and disk driver, >and not all the other drivers out there which would be an impossible >task). Since I've actually *written* bug-free and uncrashable OS cores >I am confident that it is possible to do with FreeBSD. > >Many of the issues relating to FreeBSD's instability and the many bugs >in the core have nothing to do with continuing development work >per-say, but instead has to do with an attitude that allows major >pollution to be introduced into the code to optimize very specific >cases (which destabilizes the source at the same time), and the lack of >proper documention within the source code. It is precisely these two >things which I have concentrated on the most - by rewriting where >necessary, generalizing optimizations (and ripping quite a few out of >the VM system entirely), and documenting the hell out of any procedure >I modify with succinct comments. > >There are two good examples of code pollution and, needless to say, they >have been responsible for a huge number of bugs over the years. Hundreds >of bugs at least. The first example is all the VM hacking that was >done to accomodate partial cache instantiation and, most noteably, >partial byte-range writes for NFS. So far this year I have managed to >rip about half of those hacks out at relatively little cost (a few >esoteric NFS write cases will be slower is all and buffer cache writing >is slightly slower due to the extra system process, but hopefully made up >by the move to an O(1) algorithm (previously an O(N^2) algorithm). > >The second example is the VFS layer implemenation and, most especially, >VOP_LOOKUP(). VOP_LOOKUP() has caused no end of trouble but the VFS layer >implementation with all of its locking assumptions and return requirements >has made filesystem design problematic at best. There is enormous >complexity in the lookup, directory scanning, VFS cache code that hides >bugs and that could be removed with a rewrite. > >In general, it is possible to fix these problems but some of those fixes >require significant rewriting. You have to be willing to rewrite and >take your lumps up front or you may be faced with a situation where >new problems are found with a subsystem for years to come. The best >example of this in my case is the getnewbuf() code. The code was >originally optimized with so many 'hacks' that it created at least half >a dozen serious bugs in the system. When I first rewrote it I encountered >a huge amount of resistance from certain people who believed (wrongly) that >rewriting would create more bugs then it fixed. While a few bugs were >introduced (that's the 'taking your lumps part), the generalization of >the code made finding and fixing them much, much easier and this will >ultimately lead to a better track record down the road. > >I applaud the removal of dead code that has been going on, though I have >major problems with the way some of it has been gone about. Compared >to what some committers have been doing recently, the dead code removal >that Alan and I had done to the VM system earlier in the year was a walk >in the part. I am dead set against 'hiding' bugs by trying to cache >around them instead of fixing them, which is essentially the c
Re: Inverting a gdb -k mapping?
On Thursday, 2 December 1999 at 22:32:44 -0500, David Gilbert wrote: > I can grep through the vmcore.x file and find the offset of the string > I put on the stack by > > strings -t x > ... but how do I associate that back with an address inside gdb -k? With utmost difficult. > My problem is that vinum (or something related to it) is trashing > the stack and trying to return to 0x0 is panic'ing the kernel (of > course). > > ... now... bt in gdb -k on this shows the series of trap calls and > ends with frame 5 as: > > #5 0x0 in ?? () I think I probably should take a look at this. I don't know what I'll find, but there are a number of possibilities. I don't think that mapping the physical memory image to the virtual memory address is one of them. What might help is searching the area round frame 5 for a likely looking ebp value which would point further back down the stack. You can also help it, of course, by setting a static variable, say "dgilbert_last_stack" to the ebp value every time you enter a function. You don't need any other information; the backtrace will take you straight back. Use the 'btr' command (in /usr/src/sys/modules/vinum/.gdbinit.kernel). You'll get faster response from me if you copy me on messages like this; I read them eventually (usually), but I read messages sent directly to me sooner. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tmpfs .. ?
In message <[EMAIL PROTECTED]>, Matthew Dillon <[EMAIL PROTECTED]> wrote: >Mail queue files are persistant enough (upwards of 5 days if a destination >is down) that you run a real risk of losing something important if >you crash and wipe. I would not use MFS at all and I would only use VN >with persistant store, but the performance is going to be similar to >using a normal filesystem so it may not be worth doing. Yea, someone else I was talking with about this said the same thing. I just can't get over the nagging feeling that (for the mail spool directory) there ought to be something that is ultra-super-deluxe fast that I should be using. :-) > Normal > filesystems with softupdates turned on make pretty good mail spools though OK, I've seen several mentions now of `softupdates', and I think that I have a general (vague?) notion of what `softupdates' is all about, but allow me to disaply my ignorance one more time and ask which man page (or document) I should be looking at to learn all of the specifics regarding `softupdates'. (I looked at `man tunefs' and I don't see nuttin' there, so where exactly is/are `softupdates' documented?) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI DMA lockups in 3.2 (3.3 maybe?)
On Mon, 6 Dec 1999, Dennis wrote: > The "issue" that i first cited is that the core people in FreeBSD seemed > disinterested in 3.x soon after its release. Development on 4.0 shouldnt > even have begun until 3.x was stabilized. 3.0 wasnt ready for prime time > when it was released and the work needed to get it there hasnt been done > due to the fascination with 4.0. > > DB It was never stated that 3.0 was ready for prime-time, and in fact, quite the opposite was stated. Development on 4.0 did start when 3.X was stable, but that doesn't mean bugs which cause instability under very specific conditions still weren't found. MANY of the things done in 4.0 by Matt, for instance, cannot be merged into RELENG_3 without making huge, sweeping changes. These changes wouldn't have been made in the "stable", non-development branch. They weren't. They were made in the development branch, HEAD, 4.0. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI DMA lockups in 3.2 (3.3 maybe?)
You write: : we can not identify the specific problem from this message. : without sufficient information to indentify and hopefully reproduce : the problem, we can not address it. please provide this information : if it is available to you. if it is not, please provide us contact : information for the commercial entities experiencing the problem. I work at Yahoo. My address there is "[EMAIL PROTECTED]". On a recent project I encountered two show-stopping bugs with 3.3-release that did not exist in 2.2.8-release: 1) Random crashes in FXP interrupt or low-level IP code. Something is clobbering the kernel stack--possibly the NCR driver, since using an Adaptec made the problem stop, as did a backport of the CAM driver Peter Wemm tried. This was on an N440BX, which is becoming quite common in server applications. Other installations are apparantly seeing the same problem on this hardware. 2) A hard loop in the pagedaemon. This was especially egregious, since it meant the system had to be rebooted from the console--and since the application could elicit the problem within a few minutes. Disabling the use of mmap() for file update in the application prevented the problem. After spending a day trying to cook up a test program that elicited the same behavior that the application did, I gave up for lack of time. But there have been other reports of late that sound like this problem, mostly in high VM/RAM situations. That's two serious bugs that exist in 3.3-release but not in 2.2.8-release. Looking back through the archives, I can see that I'm not the only one who has experienced them. I came away from the experience with the feeling that the FreeBSD project has some serious Q/A problems... and I can assure you, I'm not alone in this feeling. -Ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI DMA lockups in 3.2 (3.3 maybe?)
In message <[EMAIL PROTECTED]>, Matthew Dillon <[EMAIL PROTECTED]> wrote: >So, I think it *IS* possible to make FreeBSD sufficiently bug-free that >people become 'surprised' when they are able to crash a box running it. FYI - Part of the reason that _I_ jumped onto the FreeBSD bandwagon (not that long ago) was that FreeBSD was advertised as being basically uncrashable. As you might imagine, I was rather disappointed to learn that the ``never crashes'' claims that I had read (on www.freebsd.org?) were not always true in practice... at least not on the heavily-stressed 2.2.8 system that I was running awhile back. (That system has now been taken out of service for reasons entirely unrelated to the OS.) Having said that however, I guess that I should also clarify that the crashes I had been experiencing with that 2.2.8 system might perhaps have been easily solved (at the time) if it had not been for an unfortunate combination of factors (i.e. swap partition having been allocated too small, more memory being added to the system) that made it impossible for me to get any sort of a system crash dump to analyze. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tmpfs .. ?
On Sun, 5 Dec 1999, Ronald F. Guilmette wrote: > > Normal > > filesystems with softupdates turned on make pretty good mail spools though > > OK, I've seen several mentions now of `softupdates', and I think that I > have a general (vague?) notion of what `softupdates' is all about, but > allow me to disaply my ignorance one more time and ask which man page > (or document) I should be looking at to learn all of the specifics > regarding `softupdates'. (I looked at `man tunefs' and I don't see > nuttin' there, so where exactly is/are `softupdates' documented?) See src/sys/ufs/ffs/README.softupdates, which tells you what you need to get them to work, and http://www.ece.cmu.edu/~ganger/CSE-TR-254-95/ David Scheidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Strange SCSI sickness
My apologies for posting this digression from the usual weighty matters that are discussed here on -hackers, but I'm really in a tizzy about this. Going through my waiting mail this morning (on my personal desktop system named `segfault.monkeys.com') I found the following message from the nightly Security Check run. (This system is running stock 3.3 from a CD.) I'm really quite worried about this, and I want to know what it all means. `da0' is my primary SCSI drive and holds a LOT of stuff that is near and dear to me (including a lot of stuff which I DO NOT HAVE BACKED UP) along with all of the OS files. The controller is an AHA-2940U (not wide). The da0 disk is a Quantum Viking 4.5GB SCSI. I have never had any problem with this drive before, even though I used it on Linux for several months. This (FreeBSD) system has been running just fine, with no problems, for several weeks. And now this! I looked at the log files in /var/log and found out that these SCSI errors mostly seem to have occured at around 2:00 local time last night... when I was in bed and asleep. This morning, the system still _seems_ to be running just fine, but I'm worried... I just want to know, on a scale from 1 to 10, what level of panic should I now be experiencing relative to the kernel SCSI errors shown below? Should I be furiously backing everything up to tape as we speak? --- Forwarded Message Return-Path: root Received: (from root@localhost) by monkeys.com (8.9.3/8.9.3) id BAA20422 for root; Sun, 5 Dec 1999 01:59:42 -0800 (PST) Date: Sun, 5 Dec 1999 01:59:42 -0800 (PST) From: Charlie Root Message-Id: <[EMAIL PROTECTED]> Subject: segfault.monkeys.com security check output X-Original-Recipient: RFC822;[EMAIL PROTECTED] checking setuid files and devices: checking for uids of 0: root 0 toor 0 checking for passwordless accounts: segfault.monkeys.com kernel log messages: > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x53 > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x53 > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10d > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Message-In phase. > SEQADDR == 0x152 > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0xf > (da0:ahc0:0:0:0): parity error during Dat
Re: Strange SCSI sickness
On Sun, 5 Dec 1999, Ronald F. Guilmette wrote: > The controller is an AHA-2940U (not wide). The da0 disk is a Quantum > Viking 4.5GB SCSI. I have never had any problem with this drive before, > even though I used it on Linux for several months. > > This (FreeBSD) system has been running just fine, with no problems, for > several weeks. And now this! Before throwing the "this worked in Linux!" crap around, please consider that it is possible Linux just didn't report the errors. just a possibility... -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Strange SCSI sickness
On Sun, 5 Dec 1999, Bill Fumerola wrote: > On Sun, 5 Dec 1999, Ronald F. Guilmette wrote: > > > The controller is an AHA-2940U (not wide). The da0 disk is a Quantum > > Viking 4.5GB SCSI. I have never had any problem with this drive before, > > even though I used it on Linux for several months. > > > > This (FreeBSD) system has been running just fine, with no problems, for > > several weeks. And now this! > > Before throwing the "this worked in Linux!" crap around, please consider > that it is possible Linux just didn't report the errors. > > just a possibility... > > -- > - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - > - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - "... even though I used it on Linux for several months." I read that as meaning "the drive worked despite the fact that it was on Linux". Dan Seguin Texar Software, Corporation. The trouble with doing something right the first time is that nobody appreciates how difficult it was. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
NFS server bound to specific local address
Hi, I've just noticed that (on STABLE, at least) it doesn't seem possible to run an NFS server on a machine, and have it service requests from clients talking to anything other than the base address. For example, if I ifconfig fxp0 inet 192.168.0.11 ifconfig fxp0 inet 192.168.0.16 alias and then have clients attempt to mount 192.168.0.16:/foo, the clients will not successfully mount the shared volume; this is (according to some posts on the subject I found in the -questions archive) because the client is expecting replies from 192.168.0.16, but the server is sending them from 192.168.0.16. This is correct behaviour by the client, since trusting NFS replies from any old address would be silly. It seems to me that _my_ requirements would be satisfied if an NFS request from a client could have its destination address recorded, so that any replies to that specific request could be sourced from the address expected by the client. Would this obviously break anything else? Would this be a security-conscious modification? Does -current already do this? If "no, yes, no" I'll have a look myself. Just keen not to overlap with anybody else's effort. -- Ua lawa küpono ka hakahaka pä o këia pä malule To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Sendmail (was Re: tmpfs .. ?)
In the last episode (Dec 05), Ronald F. Guilmette said: > Matthew Dillon <[EMAIL PROTECTED]> wrote: > > Mail queue files are persistant enough (upwards of 5 days if a > > destination is down) that you run a real risk of losing something > > important if you crash and wipe. I would not use MFS at all and I > > would only use VN with persistant store, but the performance is > > going to be similar to using a normal filesystem so it may not be > > worth doing. > > Yea, someone else I was talking with about this said the same thing. > > I just can't get over the nagging feeling that (for the mail spool > directory) there ought to be something that is ultra-super-deluxe > fast that I should be using. :-) Sendmail 8.10 seems to have some performance enhancements, including "memory-buffered files to reduce file system overhead by not creating temporary files on disk", "New queue file naming system which uses a filename guaranteed to be unique for 60 years. This allows queue IDs to be assigned without fancy file system locking", and "QueueSortOrder=Filename will sort the queue by filename. This avoids opening and reading each queue file when preparing to run the queue". I don't know if any of them really help, but it's worth looking at. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tmpfs .. ?
In message <[EMAIL PROTECTED]>, you wrote: >See src/sys/ufs/ffs/README.softupdates, which tells you what you need to get >them to work Thank you. I'll definitely be looking at that. P.S. The other reference you gave: >http://www.ece.cmu.edu/~ganger/CSE-TR-254-95/ seem to no longer be useful/functional. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Strange SCSI sickness
> "... even though I used it on Linux for several months." > > I read that as meaning "the drive worked despite the fact that it was on > Linux". Well, just to inject a note of reality into this discussion: 1. It's quite possible that the drive and/or the cabling in this system has been defective all along. 2. It's equally possible that the linux driver simply doesn't report the errors but, as FreeBSD does, retries the failing operations. This would result in a system which appeared to work just fine, just more slowly at times (which would probably not even be noticed). 3. Any system I saw spitting out errors like this would get the following treatment, in roughly this order: 3a) Complete check of all cables and the seating of connectors. 3b) Examination of the drive(s) in question for any cooling or mounting deficiencies. Depending on the SCSI errors in question, I might even investigate firmware updates for the drive(s). 3c) Examination of the controller for correct seating and bus slot (in older PCI mobos, this makes a difference) as well as its firmware revision level. I'd also, obviously, look into any recent FreeBSD driver updates to see if I was running afoul of something recently added. If nothing in software appeared to be the culprit and I was still seeing the errors after doing steps 3a-3c above, I'd then pop in another drive and copy my data to it, removing the old drive afterwards and setting it aside in my "suspect" pile. If the errors still occurred, I'd replace the SCSI cabling and move the old drive from the "suspect" to the "spare" pile. If it still didn't work, I'd move the old SCSI cabling to my spare pile as well and replace the controller. After that I can't tell you what I'd do next since I've never had a problem persist after going all the way down this road. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Strange SCSI sickness
> >3b) Examination of the drive(s) in question for any cooling or >mounting deficiencies. Depending on the SCSI errors in question, >I might even investigate firmware updates for the drive(s). > I actually used to get these *exact* errors a couple of years ago on various 2.x systems. At first, I had assumed a bug in the driver (the ahc driver was noted as still having some bugs at the time, if I recall correctly). The errors would rare (every month or so, but they would come in batches). I kept upgrading, from 2.1.5, through 2.2.5 hoping that the errors would go away. Now, my ignorance being point out, it turned out that the errors were actually heat-induced. I had 2 5-year old 7200RPM drives in each of the systems, that besides being noisy, got pretty hot. Of course, they weren't hot when I mounted them :), and I had mounted them right next to each other in the case. It helped a little when I spaced the drives apart from each other. Then I found these neat full-length expansion cards which have 2 fans mounted on them. Got that situated to circulate additional air across the drives and never had any problem since (those systems have been running for over a year since without incident). Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Director of Technical Services, ALC Communications http://www.alcnet.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Strange SCSI sickness
> 3. Any system I saw spitting out errors like this would get the following >treatment, in roughly this order: > >3a) Complete check of all cables and the seating of connectors. > >3b) Examination of the drive(s) in question for any cooling or >mounting deficiencies. Depending on the SCSI errors in question, >I might even investigate firmware updates for the drive(s). > >3c) Examination of the controller for correct seating and bus slot >(in older PCI mobos, this makes a difference) as well as its >firmware revision level. > 3d) Any system experiencieng scsi parity errors should have all components power cycled (for self healing termpwr- fuses) and any pluggable termpwr fuses checked (these are exceedingly rare now- but if you had a SparcStation, they'd be the first thing to check- they're next to the ethernet connector on the motherboard). If you're not using an active terminator, you should be. Check for multiple termination- both ends of the bus must have termination enabled, nothing else- check drive and hba. If necessary, derate off of Ultra to Fast to see if this was the source of problems. [ a parity error indicates trashed signals. a parity error in data phase indicates signal reflection, skew, or rise time problems. signal quality is greatly affected by: bus length, termination, cable impedance mismatches ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Strange SCSI sickness
In message <[EMAIL PROTECTED]>, Bill Fumerola <[EMAIL PROTECTED]> wrote: >On Sun, 5 Dec 1999, Ronald F. Guilmette wrote: > >> The controller is an AHA-2940U (not wide). The da0 disk is a Quantum >> Viking 4.5GB SCSI. I have never had any problem with this drive before, >> even though I used it on Linux for several months. >> >> This (FreeBSD) system has been running just fine, with no problems, for >> several weeks. And now this! > >Before throwing the "this worked in Linux!" crap around, please consider >that it is possible Linux just didn't report the errors. > >just a possibility... Ummm Hello! Is it just vaguely possible that you are perhaps just a little bit touchy about anything that might even perversely be (mis-)construed as a compari- son between FreeBSD and Linux? Please read what I wrote. No comparison of any kind between these two OSes was either expressed or implied. In order to help clarify the problem, I merely noted that this specific *DISK DRIVE* has been operating with no problems (under *both* FreeBSD and Linux) for some time now. If anything, I believe that this combined evidence strongly points to a newly-developed *HARDWARE* problem in the *DISK DRIVE*. To reiterate, no OS comparisons were either expressed or implied. Furthermore, having just witnessed (here) someone else being roasted over an open flame for having FAILED to provide all relevant details regarding the background of some problem, I find it rather inexplicable that _I_ should now be roasted for having done the exact opposite, i.e. having provided as much potentially useful background information about my specific problem as possible. P.S. I'm a complete agnostic with regards to OSes. I have neither any specific religious beliefs with regards to OSes, nor any desire whatsoever to engage in religious flame wars about them. I have better things to do. P.P.S. Since joining the -hackers list only a short time ago, I've made every effort to restrain myself from my natural tendency to either begin, or to participate in flame wars. I've done that despite the fact that at about half of the traffic here on -hackers since I joined seem to consist of flames (of one form or another) that I have been tempted to jump into the middle of, _and_ despite the fact that I myself have a well and widely known propensity to start or participate in flaming myself. I came here only to learn and to benefit from the combined wisdom here... not to read flames or to be flamed. A simple plea: Can we all just get along? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tmpfs .. ?
On Sun, 5 Dec 1999, Ronald F. Guilmette wrote: > > In message <[EMAIL PROTECTED]>, you > P.S. The other reference you gave: > > >http://www.ece.cmu.edu/~ganger/CSE-TR-254-95/ > > seem to no longer be useful/functional. That is because it should be ~ganger/CSE-TR-254-95/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Strange SCSI sickness
In message <[EMAIL PROTECTED]>, "Jordan K. Hubbard" <[EMAIL PROTECTED]> wrote: >> "... even though I used it on Linux for several months." >> >> I read that as meaning "the drive worked despite the fact that it was on >> Linux". > >Well, just to inject a note of reality into this discussion: > >1. It's quite possible that the drive and/or the cabling in this > system has been defective all along. I suspect not, based upon the history. I think that the drive and/or controler has just developed this sickness within the past 24 hours. >2. It's equally possible that the linux driver simply doesn't report > the errors but, as FreeBSD does, retries the failing operations. > This would result in a system which appeared to work just fine, > just more slowly at times (which would probably not even be > noticed). FreeBSD was also perfectly happy with this drive (and controller) for weeks... up until last night. >3. Any system I saw spitting out errors like this would get the following > treatment, in roughly this order: (I now think that my first order of business should be to start making backup tapes as quick as I can. :-) > 3a) Complete check of all cables and the seating of connectors. > > 3b) Examination of the drive(s) in question for any cooling or ^^^ The drive is mounted in a crappy external box with perfectly lousy ventilation. I just touched the drive and guess what... It's hot as Hades. I think I found my answer. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No Subject
Question,
I am a graduate student at Duke University. Currently, I am part of a team to
build a terabit router using a cluster connected with Myrinet. One aspect of
the project is to tune the devices & drivers to perform cooperatively... In a
routing situation, the 1500B dma takes roughly 11us over PCI 32/33Mhz. If the
processor (driver) is checking the command accept status of a NIC, it can
take a "long" time to get a response from the NIC. For gigabit routing, you
have to roughly processes 1pkt/ 8-10us . For starters, I changed up the
driver code in fxp_start to break up a large dma transactions into smaller
chunks,.. to make bus arbitration work using a finer grain time slice. Hence,
the processor stalls less when it checks if a NIC command was accepted.
The question: Why doesn't this work... it seem so straight forward...
using netperf, the driver works when the message size is less than
FXP_MAX_SEGMENT_SIZE, .. I am using FXP_MAX_SEGMENT_SIZE of 1024
--
fxp_start()
/*
* Go through each of the mbufs in the chain and initialize
* the transmit buffer descriptors with the physical address
* and size of the mbuf.
*/
tbdinit:
for (m = mb_head, segment = 0; m != NULL; m = m->m_next) {
if (m->m_len != 0) {
unsigned int sub_segments,
counter;
uint8_t *mbuf_data_addr = mtod(m,uint8_t *);
sub_segments = (m->m_len / FXP_MAX_SEGMENT_SIZE)
+ (((m->m_len % FXP_MAX_SEGMENT_SIZE) != 0)?1:0);
if (segment + sub_segments >= FXP_NTXSEG)
break;
for(counter = 0;counter < sub_segments;counter++)
{
txp->tbd[segment].tb_addr =
vtophys(mbuf_data_addr + (counter * FXP_MAX_SEGMENT_SIZE));
txp->tbd[segment].tb_size
= (sub_segments == (counter+1))?(m->m_len %
FXP_MAX_SEGMENT_SIZE):FXP_MAX_SEGMENT_SIZE;
/*
vtophys(mtod(m, vm_offset_t))
+ (counter * FXP_MAX_SEGMENT_SIZE);
*/
segment++;
}
}
}
if (m != NULL) {
.
-
Unfortunately, I don't have the intel docs on the card, which requires a NDA...
If you can help, it would be much appreciated.
thanks,
kurt
--
Some output when it's running
/*if(mb_head->m_pkthdr.len > FXP_MAX_SEGMENT_SIZE)
printf("Pha %u, Kva %u, counter %u,segment %u, length %u, subs %u, tbs %u, mss %u\n",
txp->tbd[segment].tb_addr,
mbuf_data_addr + (counter * FXP_MAX_SEGMENT_SIZE),
counter, segment, m->m_len,
sub_segments, txp->tbd[segment].tb_size,
FXP_MAX_SEGMENT_SIZE);
*/
Pha 39110690, Kva 3229624354, counter 0,segment 0, length 34, subs 1, tbs 34, mss 1024
Pha 129788744, Kva 3229076296, counter 0,segment 1, length 1208, subs 2, tbs 1024, mss
1024
Pha 129789768, Kva 3229077320, counter 1,segment 2, length 1208, subs 2, tbs 184, mss
1024
Pha 131485696, Kva 3229200384, counter 0,segment 3, length 272, subs 1, tbs 272, mss
1024
Pha 39637282, Kva 3229626658, counter 0,segment 0, length 34, subs 1, tbs 34, mss 1024
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Strange SCSI sickness
> >1. It's quite possible that the drive and/or the cabling in this > > system has been defective all along. > > I suspect not, based upon the history. > > I think that the drive and/or controler has just developed this sickness > within the past 24 hours. > > >2. It's equally possible that the linux driver simply doesn't report > > the errors but, as FreeBSD does, retries the failing operations. > > This would result in a system which appeared to work just fine, > > just more slowly at times (which would probably not even be > > noticed). > > FreeBSD was also perfectly happy with this drive (and controller) for > weeks... up until last night. > > >3. Any system I saw spitting out errors like this would get the following > > treatment, in roughly this order: > > (I now think that my first order of business should be to start making > backup tapes as quick as I can. :-) > > > 3a) Complete check of all cables and the seating of connectors. > > > > 3b) Examination of the drive(s) in question for any cooling or > ^^^ > > The drive is mounted in a crappy external box with perfectly lousy > ventilation. > > I just touched the drive and guess what... It's hot as Hades. > > I think I found my answer. > [stuff snipped] If it already hasn't been done, we should capture the procedure that Jordan posted, added to by Matt and maybe post it to the troubleshooting part of the guide(s). Unlike some of us who've been fooling with computers since pre-1985, this standard operating procedure may not be second nature. Dan Seguin Texar Software, Corporation. The trouble with doing something right the first time is that nobody appreciates how difficult it was. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NFS server bound to specific local address
On Mon, Dec 06, 1999 at 09:15:55AM +1300, Joe Abley wrote: > I've just noticed that (on STABLE, at least) it doesn't seem possible > to run an NFS server on a machine, and have it service requests from > clients talking to anything other than the base address. We've some patches which Matt Dillon just applied to -current which allow this to work correctly. The patches are quite simple and were developed here for a 3.3-STABLE machine, so it should be easy to backport them. It is probably too late to get them into 3.4 at this stage. (The pr was kern/13049 but something slightly different got committed in the end). David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tmpfs .. ?
On Sat, 04 Dec 1999 15:44:49 -0800, "Ronald F. Guilmette" <[EMAIL PROTECTED]> wrote: >Specifically, I'm planning a large mail server... which will use Sendmail... >and I'd really like to allocate the Sendmail queue files... which typically >have a rather short lifespan... on/in some sort of filesystem (e.g. an >mfs or else this VN thing you are talking about) that would tend to give >petter performance than just using an ordinary disk-based filesystem. This doesn't sound like a good application for a temporary filesystem. Whilst the files do typically have a short lifetime, and there are lots of them, they represent mail items which your server has accepted responsibility for delivering. Also, the queue files can potentially exist for several days (the default timeout is 5 days). I would suggest that UFS with softupdates represents a better performance/ reliability tradeoff than MFS or a swap-backed vnode. The main problem is that sendmail places all queue files (and there are several for each undelivered message) in one directory - and very large directories are not handled particularly efficently by UFS. The simple solutions are: 1) switch to an alternative MTA that doesn't display this behaviour. 2) hack sendmail to have multiple subdirectories within the main queue directory - with the subdirectory chosen by hashing the sendmail job id. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Strange SCSI sickness
As Kelly Yancey wrote ... > > > >3b) Examination of the drive(s) in question for any cooling or > >mounting deficiencies. Depending on the SCSI errors in question, > >I might even investigate firmware updates for the drive(s). > > > > I actually used to get these *exact* errors a couple of years ago on > various 2.x systems. At first, I had assumed a bug in the driver (the ahc > driver was noted as still having some bugs at the time, if I recall > correctly). The errors would rare (every month or so, but they would come > in batches). I kept upgrading, from 2.1.5, through 2.2.5 hoping that the > errors would go away. Now, my ignorance being point out, it turned out > that the errors were actually heat-induced. Another interesting cause for problems is duff powersupplies. As the proverb goes "every machine is as good as it's PSU". E.g. I just struggeled with a DLT tape unit that inexplicable reset itself. After examining the 5Volts rail with a scope I found glitches on it whenever the drive did a bit of rewinding (dropping out of streaming mode). Had me stumped for a while. W/ -- | / o / / _ Arnhem, The Netherlands - The FreeBSD Project |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Strange SCSI sickness
> Another interesting cause for problems is duff powersupplies. As the > proverb goes "every machine is as good as it's PSU". E.g. I just struggeled > with a DLT tape unit that inexplicable reset itself. After examining the > 5Volts rail with a scope I found glitches on it whenever the drive did a > bit of rewinding (dropping out of streaming mode). Had me stumped for a > while. > That's pretty rare these days. It used to happen all the time when switching power supplies first appeared (motorboating is what we called it), but even recently I had a marginal supply that supplied 4.4VDC- *just* enough to function *most* of the time. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Strange SCSI sickness
In message <[EMAIL PROTECTED]>, Kelly Yancey <[EMAIL PROTECTED]> wrote: >> >>3b) Examination of the drive(s) in question for any cooling or >>mounting deficiencies. Depending on the SCSI errors in question, >>I might even investigate firmware updates for the drive(s). >> > > I actually used to get these *exact* errors a couple of years ago on >various 2.x systems. At first, I had assumed a bug in the driver (the ahc >driver was noted as still having some bugs at the time, if I recall >correctly). The errors would rare (every month or so, but they would come >in batches). I kept upgrading, from 2.1.5, through 2.2.5 hoping that the >errors would go away. Now, my ignorance being point out, it turned out >that the errors were actually heat-induced. > I had 2 5-year old 7200RPM drives in each of the systems, that besides >being noisy, got pretty hot. Of course, they weren't hot when I mounted >them :), and I had mounted them right next to each other in the case. >It helped a little when I spaced the drives apart from each other. Then >I found these neat full-length expansion cards which have 2 fans mounted >on them. Got that situated to circulate additional air across the drives >and never had any problem since (those systems have been running for over >a year since without incident). Yowza. I found two web sites recently where a nice veriety of different types of useful cooling devices (mostly for PeeCee type systems) are available: http://www.3dcool.com/ and: http://www.icedmocha.com/ I bought two ``slot fans'' from www.icedmocha.com recently, and I think I'm sure now where one of those two fans is going. :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: natd is jumpy
Hi, > >and disable natd and the firewall code, these delays go away so I am > >assuming that it is natd/firewall/divert that is responsible for this > >delay. > > I think that is a bad assumption. [snip] > I'm running FreeBSD 3.3 with IPFIREWALL, IPDIVERT, and natd also over a > 56k modem, and I _never_ have seen the kind of slow echo effect you > are speaking of, except on very rare occasions when _somebody_ between > me and whichever machine I'm talking to happens to be dropping a lot of > packets. And obviously, in those cases, it ain't the fault of my FreeBSD > box. > > >Is there a parameter or anything that I can tune to eliminate or > >reduce this affect? > > But seriously, next time it happens, try doing some pings to the remote > system that you are telnetting to. Look for dropped packets. Doing a > couple of traceroutes to the remote system from your location might pro- > vide some useful info also. OK, here's a little snippet from 'ping': [bsd@vger]:/conf- ping dean PING dean (10.26.2.60): 56 data bytes 64 bytes from 10.26.2.60: icmp_seq=0 ttl=252 time=3146.649 ms 64 bytes from 10.26.2.60: icmp_seq=1 ttl=252 time=2172.951 ms 64 bytes from 10.26.2.60: icmp_seq=2 ttl=252 time=1184.808 ms 64 bytes from 10.26.2.60: icmp_seq=3 ttl=252 time=198.578 ms 64 bytes from 10.26.2.60: icmp_seq=4 ttl=252 time=1725.051 ms 64 bytes from 10.26.2.60: icmp_seq=5 ttl=252 time=737.457 ms 64 bytes from 10.26.2.60: icmp_seq=6 ttl=252 time=128.368 ms 64 bytes from 10.26.2.60: icmp_seq=7 ttl=252 time=127.593 ms 64 bytes from 10.26.2.60: icmp_seq=8 ttl=252 time=160.611 ms 64 bytes from 10.26.2.60: icmp_seq=9 ttl=252 time=148.561 ms 64 bytes from 10.26.2.60: icmp_seq=10 ttl=252 time=138.905 ms 64 bytes from 10.26.2.60: icmp_seq=11 ttl=252 time=194.196 ms 64 bytes from 10.26.2.60: icmp_seq=12 ttl=252 time=226.685 ms 64 bytes from 10.26.2.60: icmp_seq=13 ttl=252 time=1194.855 ms 64 bytes from 10.26.2.60: icmp_seq=14 ttl=252 time=127.343 ms 64 bytes from 10.26.2.60: icmp_seq=15 ttl=252 time=138.772 ms No dropped packets, but definitely some occasional long delays before I get the echo. However, I must concede, based on other respondants, that something else must be going on and I cannot necessarily attribute this to divert/firewall/natd. However, the above numbers don't really illustrate the long response times that I experience while typing at the shell prompt, or in elm. It's really frustrating. I have an external US Robotics Sportster modem and I can see the rx/tx leds which are both off during the times when there was a delay, so I can confirm that there was no other line-contention on my end. Currently, I am connected from my home into work via a ppp link. I notice the delays primarily when connected into work. Here's a traceroute from my home machine to my work machine: [bsd@vger]:/bsd- traceroute dean traceroute to dean (10.26.2.60), 30 hops max, 40 byte packets 1 R09d016Rb410nc0.net.sas.com (172.16.0.1) 120.659 ms 139.603 ms 121.679 ms 2 R01r025Rb319nc0.net.sas.com (172.25.1.2) 116.139 ms 113.945 ms 119.767 ms 3 R42axxxRb319nc0.net.sas.com (10.19.0.3) 118.763 ms 125.350 ms 184.147 ms 4 dean (10.26.2.60) 132.987 ms 119.363 ms 120.193 ms Using netstat, I see 6 input errors on my ppp0 interface. I can't account for the cause of these, maybe they are a clue: Name Mtu Network AddressIpkts IerrsOpkts Oerrs Coll ppp0 1500 68826 673148 0 0 ppp0 1500 172.16brdean 68826 673148 0 0 Thanks for the suggestions. I'll keep looking. -Brian -- Brian Dean [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Portable way to compare struct stat's?
At 3:17 PM -0500 12/4/99, Robert Watson wrote: >On 4 Dec 1999, Assar Westerlund wrote: > > > Garance A Drosihn <[EMAIL PROTECTED]> writes: > > > In the case of AFS, I think you'd want to expand the size of st_dev. > > > All files in an AFS volume are "one device", I would think. If the > > > "device" is gone (ie, the volume is not mounted), then all files in > > > that "device" (volume) will not be available. > > > > I'm confused. Did you mean `st_ino' there? I agree that you want to > > see the whole AFS space as a single device. > >I agree. Well, I'm happy to have it that way if everyone prefers that, but I really did mean to suggest that each AFS volume would be a separate device. Not "all of AFS" as one device, or even "all of one AFS cell" as one device. Do we have one device for "all NFS filesystems from all hosts"?(my assumption is "no", but maybe I'm wrong (*)). In local filesystems, a device is a partition on one hard disk. That one partition could be unavailable (ie, "not mounted"), in which case all files in that partition are not available. In AFS, the "mountable quantity" is a volume. You can mount the same volume in multiple places in AFS-land, in fact. If there's an AFS problem, you can be in a situation where "most" of an AFS cell is up, but particular volumes are not available because they are being salvaged. To me, all of this seems to indicate that AFS volumes are pretty analogous to what are used for devices on a local file system. But really, any way we could arrange it would be fine with me... (*) - I'm told that SGI's claim that all mounts (except lofs) will have a unique st_dev, including NFS mounts. On the other hand, I'm also told that linux seems to use the same st_dev value for all NFS mounts from a given host. In my mind, the linux behavior would suggest one st_dev value per AFS cell... --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
new Intel 100Mbps card
Hi, I got some new Intel 10/100Mbps network interfaces recently, but unfortunately found that FreeBSD (version 4.0-19990827-CURRENT) doesn't recognize them. These are called the "Intel InBusiness 10/100 PCI Network Adaptor". Unfortunately, these are the only ones supported in the stores now, so I can't find the older 10/100+ and 10/100B kind. After looking at the boot messages, I found that these cards have a device_id of 0x1030 - which is different than the one supported by the fxp driver in FreeBSD (0x1229 - defined in /sys/pci/if_fxpreg.h as FXP_DEVICEID_i82557). I changed the driver (fxp_probe() function in /sys/pci/if_fxp.c) to also recognize the device_id 0x1030. The cards now work, but I haven't stress tested them for performance. Can someone tell me if the fxp driver is compatible with these cards (at least it seems to work). If so, it'll be nice if the future releases of the driver also support this card. - Mohit To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Sv: Strange SCSI sickness
> > If it already hasn't been done, we should capture the procedure that > Jordan posted, added to by Matt and maybe post it to the troubleshooting > part of the guide(s). > > > Unlike some of us who've been fooling with computers since pre-1985, this > standard operating procedure may not be second nature. > Perhaps the order of checking could be weighted(sp?) against the price of equipment, eg feeling the temperature of the drive before replacing a $0.50 termpwr fuse before replacing $xx cable or a $xxx diskdrive... Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI DMA lockups in 3.2 (3.3 maybe?)
> On a recent project I encountered two show-stopping bugs with 3.3-release > that did not exist in 2.2.8-release: > > 1) Random crashes in FXP interrupt or low-level IP code. Something is >clobbering the kernel stack--possibly the NCR driver, since using an >Adaptec made the problem stop, as did a backport of the CAM driver >Peter Wemm tried. This was on an N440BX, which is becoming quite >common in server applications. Other installations are apparantly >seeing the same problem on this hardware. So far the problem appears to require a combination of the 440BX chipset, an Intel EtherExpress and the 'fxp' driver, and an NCR/Symbios/LSI SCSI adapter and either the 'ncr' or 'sym' driver. We've tried on a number of occasions to diagnose this problem, but there have been many issues that have prevented it's resolution. These have included lack of interest on the driver developers' parts, lack of access to or cooperation from people complaining of the bug, and an inability to reproduce it in a useful fashion. It's been an eye-opening exercise and we're trying to learn what we can from it, as well as actually fix it for good. > 2) A hard loop in the pagedaemon. This was especially egregious, since >it meant the system had to be rebooted from the console--and since >the application could elicit the problem within a few minutes. >Disabling the use of mmap() for file update in the application >prevented the problem. After spending a day trying to cook up a >test program that elicited the same behavior that the application >did, I gave up for lack of time. But there have been other reports >of late that sound like this problem, mostly in high VM/RAM situations. > > That's two serious bugs that exist in 3.3-release but not in 2.2.8-release. > Looking back through the archives, I can see that I'm not the only one who > has experienced them. I came away from the experience with the feeling that > the FreeBSD project has some serious Q/A problems... and I can assure you, > I'm not alone in this feeling. Neither are we. But, since FreeBSD is a volunteer-developed project, and since you admit above that you have contributed to the lack of QA, I'm not entirely sure what your point is. We need this feedback in a timely fashion in order to do something with it. 3 months after a release is not "timely" by any stretch of the imagination, and without that sort of assistance, I have no idea what you think we can do to improve the situation. Yes, we want to improve our QA. But when customers come up months after the fact and complain about something that we could never possibly have either known or even guessed about during the development process, the best we can do is try to fix the problem then and there. If you want to improve that situation, you can; in your position you have plenty of opportunities to make a major contribution to the overall quality of FreeBSD releases. OTOH, if you choose not to do so, it's mere honesty to observe that you need to take a share of the blame for the current situation. ps: The N440BX is actually being phased out, however there are very large numbers of them still in production, yes. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: natd is jumpy
Brian Dean writes: > No dropped packets, but definitely some occasional long delays before > I get the echo. However, I must concede, based on other respondants, > that something else must be going on and I cannot necessarily > attribute this to divert/firewall/natd. > > However, the above numbers don't really illustrate the long response > times that I experience while typing at the shell prompt, or in elm. > It's really frustrating. > > I have an external US Robotics Sportster modem and I can see the rx/tx > leds which are both off during the times when there was a delay, so I > can confirm that there was no other line-contention on my end. Could be you have a noisy line and your modem error correction is kicking in. Try configuring your modem to disable error correction and see if it changes things. This is consistent with your rx/tx lights -- typically they only light up when there's traffic on the serial line (not the telephone line). -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
vfs_bio questions/nfs cluster commit
I've been trying to workout mega-clusters for NFS, since afaik the
vfs_cluster code will only do 64k chunks and we can benifit greatly
by compacting ranges for commit RPCs.
The problem, is that it seems that NFS has been having issues, doing
large appends on my box (lptest 80 10 > /nfsmount/foo) seems
to just get stuck even without my new code. Is anyone else having
this problem on a recent -current?
It seems that taking out the sync rpc commit in nfs_writebp may
have been a mistake, it appears that it allows a buffer that _must_
be free'd to be delayed for commit, i'm not sure if the code makes
sure that the buffer is written sync if we need it to be?
I'm not sure it's ok to do this becasue afaik a written but uncommitted
bp is marked as delay-write? (B_DELWRI) We don't really get our
buffers back until a buffer is committed.
Anyhow back to the commit clustering..
Does anyone want to take a look at this?
When a buffer is scheduled to be committed from nfs_doio() the
nfs_cluster_commit() function trys to find adjacent buffers and
include them in one giant mega-commit, then it frees the buffers.
Last thing, the paranioa check in nfs_subr.c looks bogus because
we are at splbio(), or is it essential that this check be done?
XXX: this code _almost_ works :)
Index: nfs_bio.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_bio.c,v
retrieving revision 1.80
diff -u -u -r1.80 nfs_bio.c
--- nfs_bio.c 1999/10/29 18:09:11 1.80
+++ nfs_bio.c 1999/12/06 05:01:33
@@ -62,6 +62,8 @@
#include
#include
+static int nfs_cluster_commit __P((struct vnode *vp, struct buf *bp,
+ struct proc *p));
static struct buf *nfs_getcacheblk __P((struct vnode *vp, daddr_t bn, int size,
struct proc *p));
@@ -1006,6 +1008,10 @@
nmp = VFSTONFS(mp);
if (nmp->nm_flag & NFSMNT_INT) {
+ /*
+* don't spin on signals not applicable to interupting an
+* NFS operation, try short term non-interuptable requests
+*/
bp = getblk(vp, bn, size, PCATCH, 0);
while (bp == (struct buf *)0) {
if (nfs_sigintr(nmp, (struct nfsreq *)0, p))
@@ -1347,27 +1353,9 @@
/*
* If we only need to commit, try to commit
*/
- if (bp->b_flags & B_NEEDCOMMIT) {
- int retv;
- off_t off;
-
- off = ((u_quad_t)bp->b_blkno) * DEV_BSIZE + bp->b_dirtyoff;
- bp->b_flags |= B_WRITEINPROG;
- retv = nfs_commit(
- bp->b_vp, off, bp->b_dirtyend-bp->b_dirtyoff,
- bp->b_wcred, p);
- bp->b_flags &= ~B_WRITEINPROG;
- if (retv == 0) {
- bp->b_dirtyoff = bp->b_dirtyend = 0;
- bp->b_flags &= ~B_NEEDCOMMIT;
- bp->b_resid = 0;
- biodone(bp);
+ if (bp->b_flags & B_NEEDCOMMIT &&
+ nfs_cluster_commit(vp, bp, p) == 0)
return (0);
- }
- if (retv == NFSERR_STALEWRITEVERF) {
- nfs_clearcommit(bp->b_vp->v_mount);
- }
- }
/*
* Setup for actual write
@@ -1460,4 +1448,172 @@
nfs_clearcommit(vp->v_mount);
biodone(bp);
return (error);
+}
+
+/*
+ * nfs_cluster_commit(vp, bp, p)
+ *
+ * This function is called on a NFS buffer that needs a commit RPC
+ * Even though the buffer may already be clustered, clustering is limited
+ * to 64k chunks, try to grab an even bigger range by scanning forward and
+ * backward in the file.
+ */
+static int
+nfs_cluster_commit(vp, bp, p)
+ struct vnode*vp;
+ struct buf *bp;
+ struct proc *p;
+{
+ struct buf *cbufs[16], *holdbp;
+ int commit_idx, retv, flags, pass, i, dirty_off, dirty_end, s, gap;
+ int pre_count=0, post_count=0;
+ u_quad_tsblkno, eblkno, lblkno;
+ /* start, end, logical block number */
+
+ KASSERT(bp->b_flags & B_NEEDCOMMIT, ("NFS commit without B_NEEDCOMMIT"));
+
+ flags = B_DELWRI | B_NEEDCOMMIT;
+ gap = 0;
+ commit_idx = 0;
+ pass = 0;
+ sblkno = eblkno = (u_quad_t)bp->b_blkno;
+ dirty_end = bp->b_dirtyend;
+ dirty_off = bp->b_dirtyoff;
+
+ s = splbio();
+ /*
+* first pass scan forward, second backwards from bp
+*/
+pass:
+ lblkno = bp->b_blkno;
+ holdbp = bp;
+
+ /*
+* don't scan too much and don't overflow buf pointer array
+*/
+ while (gap < 4 && commit_idx < (sizeof(cbufs)/sizeof(cbufs[0]))) {
+
+ /* scan forward or back
Re: vfs_bio questions/nfs cluster commit
oh, one more thing... (replying to myself) On Sun, 5 Dec 1999, Alfred Perlstein wrote: > > I've been trying to workout mega-clusters for NFS, since afaik the > vfs_cluster code will only do 64k chunks and we can benifit greatly > by compacting ranges for commit RPCs. My code seems to have the strange side-effect that it also fixes normal commit clustering for NFS which afaik is broken. can anyone confirm this? -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Basic question about threads and SMP
Nick Hibma wrote: > > Being multi-threaded has almost nothing to do with being > multi-processor. Multi-threading means that your application has > multiple threads of execution that are able to run simultaneously. > > The multi-processing capability of your box means that 2 threads of > execution, be it a process or a thread within a process, are executed > _literally_ at the same time, and not in simulated concurrency like it > happens on a UP box. Note that this happens ONLY if both threads of execution are processor mobile. If your system supports user-space threads as part of a process and the process can't be split across CPUs, you might as well have a UP system. (Except everything else can run on the other processor, so SMP is still a small win.) This is the situation with threads and SMP in -current. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: new Intel 100Mbps card
Mohit Aron wrote: > > Hi, > I got some new Intel 10/100Mbps network interfaces recently, but > unfortunately found that FreeBSD (version 4.0-19990827-CURRENT) doesn't > recognize them. These are called the "Intel InBusiness 10/100 PCI Network > Adaptor". Unfortunately, these are the only ones supported in the stores now, > so I can't find the older 10/100+ and 10/100B kind. > > After looking at the boot messages, I found that these cards have a device_id > of 0x1030 - which is different than the one supported by the fxp driver in > FreeBSD (0x1229 - defined in /sys/pci/if_fxpreg.h as FXP_DEVICEID_i82557). It's probably an 82558 chip. Does it support Wake-on-LAN? > I changed the driver (fxp_probe() function in /sys/pci/if_fxp.c) to also > recognize the device_id 0x1030. The cards now work, but I haven't stress tested > them for performance. > > Can someone tell me if the fxp driver is compatible with these cards (at least > it seems to work). If so, it'll be nice if the future releases of the driver > also support this card. Add the device IDs to the list in the driver and recompile. If it works, send me the diffs and I'll commit it for you. I might even be able to beat one of the cards out of Intel, I used to work for the InBusiness (formerly Dayna Communications) crowd. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI DMA lockups in 3.2 (3.3 maybe?)
Matthew Dillon wrote: > : > :All running software has serious problems, that's why it is never considered > :done. Taking the time to enumerate specific problems that are currently > :plaguing an installation is the only way anyone can possibly hope to help. > :Problems reports of "It don't work" are helpful to absolutely noone. > > This simply isn't true. I have written plenty of software (large > projects) that do not have serious problems and, in fact, some do not > have any known problems at all. I have written several operating systems > and one of them is least as complex as the FreeBSD core (but not as > complex if you count drivers) which are bug-free (that is, there have > been no recorded crashes and except for feature updates have never been > rebooted). So you haven't discovered the rest of the bugs in the system. Software is created by humans, and humans are fallible, therefore the software is also fallible. Any claims of divinity on your part will be summarily rejected. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
3c589d w/ freebsd 3.3 works badly.
How reliable should the ep0 driver be with 3c389d pcmcia cards ? It gets detected by pccardd without any problems and a driver is attached to it, but I'm not getting much in the way of performance from it with "link2" selected for UTP (doesn't work with "media 10baset/utp"). It's being used in conjunction with cardbus on a gateway solo 9100. I suspect that it isn't getting interrupted properly, although nothing is telling me what IRQ is being given to it. Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ejecting card with 3.3 causes hang ?
ejecting a modem pcmcia card caused 3.3 to do the following: /kernel: sio2 unload,gone /kernel: Return IRQ=11 /kernel: Card removed, slot 1 /kernel: Card inserted, slot 0 and then it was frozen. Will there be a 3.4 with things like this fixed ? Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Basic question about threads and SMP
%Nick Hibma wrote: %> %> Being multi-threaded has almost nothing to do with being %> multi-processor. Multi-threading means that your application has %> multiple threads of execution that are able to run simultaneously. %> %> The multi-processing capability of your box means that 2 threads of %> execution, be it a process or a thread within a process, are executed %> _literally_ at the same time, and not in simulated concurrency like it %> happens on a UP box. % %Note that this happens ONLY if both threads of execution are processor %mobile. If your system supports user-space threads as part of a %process and the process can't be split across CPUs, you might as well %have a UP system. (Except everything else can run on the other %processor, so SMP is still a small win.) % %This is the situation with threads and SMP in -current. % The LinuxThreads port is currently busted for SMP but when it is fixed it will indeed use multiple processors: last pid: 395; load averages: 0.50, 0.11, 0.04 up 0+00:13:00 20:00:40 37 processes: 6 running, 31 sleeping CPU states: 65.8% user, 0.0% nice, 0.0% system, 0.0% interrupt, 34.2% idle Mem: 8780K Active, 9116K Inact, 19M Wired, 68K Cache, 7000K Buf, 466M Free Swap: 1024M Total, 1024M Free PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 393 rcarter 31 0 876K 152K CPU1 1 0:01 17.16% 2.39% ex3 394 rcarter 29 0 876K 152K RUN0 0:00 15.76% 2.20% ex3 391 rcarter 30 0 876K 152K RUN1 0:01 14.71% 2.05% ex3 395 rcarter 30 0 876K 152K RUN0 0:01 14.01% 1.95% ex3 392 rcarter 30 0 876K 152K RUN0 0:00 13.66% 1.90% ex3 Russell %-- %"Where am I, and what am I doing in this handbasket?" % %Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ % % %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
Re: PCI DMA lockups in 3.2 (3.3 maybe?)
Mike, So I'm to blame that my project schedule didn't happen to coincide with the FreeBSD release schedule? Give me a break. The project hasn't even gone into production yet. And I think you'll find that your apparent assumption that no one was told about the problems is equally rash. I posted a note here, and spent a considerable amount of time working with one of the core members in outlining the problems and finding workarounds. Yahoo devoted six machines to a series of experiments to characterize the problems and seek solutions even though using 2.2.8 was always a ready option. I think you'll find that people's willingness to contribute to your "volunteer-developed project" depends upon a little forbearance and understanding on your part. Communication is neither going to be as timely nor as well-formed as you might like. Scan the archives and you'll find ample evidence for phenomena like both issues I described, but never in a form that says, "here's your bug--now fix it." If you take a defensive attitude, you'll never see such things. Believe it or not, I'm on your side. -Ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3c589d w/ freebsd 3.3 works badly.
On Mon, 6 Dec 1999, Darren Reed wrote: > How reliable should the ep0 driver be with 3c389d pcmcia cards ? It gets > detected by pccardd without any problems and a driver is attached to it, > but I'm not getting much in the way of performance from it with "link2" > selected for UTP (doesn't work with "media 10baset/utp"). It's being > used in conjunction with cardbus on a gateway solo 9100. I suspect that > it isn't getting interrupted properly, although nothing is telling me > what IRQ is being given to it. I'm still trying to track down a watchdog timeout problem with if_ep. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tmpfs .. ?
Sorry I missed this question. Check www.acl.lanl.gov/~rminnich for v9fs and see if you can use it. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sv: Strange SCSI sickness
On Mon, 6 Dec 1999, Leif Neland wrote: > > > > > If it already hasn't been done, we should capture the procedure that > > Jordan posted, added to by Matt and maybe post it to the troubleshooting > > part of the guide(s). > > > > > > Unlike some of us who've been fooling with computers since pre-1985, this > > standard operating procedure may not be second nature. > > > > Perhaps the order of checking could be weighted(sp?) against the price > of equipment, eg feeling the temperature of the drive before replacing > a $0.50 termpwr fuse before replacing $xx cable or a $xxx diskdrive... How about using a VOM to check the fuse? > > Leif > > > > > 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
No Subject
> Question, > > I am a graduate student at Duke University. Currently, I am part of a team to > build a terabit router using a cluster connected with Myrinet. One aspect of > the project is to tune the devices & drivers to perform cooperatively... In a > routing situation, the 1500B dma takes roughly 11us over PCI 32/33Mhz. If the > processor (driver) is checking the command accept status of a NIC, it can > take a "long" time to get a response from the NIC. For gigabit routing, you > have to roughly processes 1pkt/ 8-10us . For starters, I changed up the > driver code in fxp_start to break up a large dma transactions into smaller > chunks,.. to make bus arbitration work using a finer grain time slice. Hence, > the processor stalls less when it checks if a NIC command was accepted. > > The question: Why doesn't this work... it seem so straight forward... I'm not sure about the code in question, but the basic assumptions you're making about PCI's behaviour are flawed. To achieve the goal you're trying to, you need to reduce the value of the PCI bus latency timer for the peripheral(s) that you're hoping to interrupt. Breaking up the DMA transactions leaves you vulnerable to the PCI peripheral noticing that the two segments are contiguous and coalescing them again into a single master write. Also, you don't want the (high) overhead of forcing a re-arbitration all the time, rather you want to guarantee the worst-case cycle time involved in polling the peripheral. Again, to achieve this, you want to look at how the PCI bus latency timer works and use it instead. You will always get the best performance out of PCI by avoiding _anything_ that involves arbitrating for the bus. PCI bus transactions are reasonably expensive to start. 8( -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: new Intel 100Mbps card
> I got some new Intel 10/100Mbps network interfaces recently, but > unfortunately found that FreeBSD (version 4.0-19990827-CURRENT) doesn't > recognize them. These are called the "Intel InBusiness 10/100 PCI Network > Adaptor". Unfortunately, these are the only ones supported in the stores now, > so I can't find the older 10/100+ and 10/100B kind. > > After looking at the boot messages, I found that these cards have a device_id > of 0x1030 - which is different than the one supported by the fxp driver in > FreeBSD (0x1229 - defined in /sys/pci/if_fxpreg.h as FXP_DEVICEID_i82557). > I changed the driver (fxp_probe() function in /sys/pci/if_fxp.c) to also > recognize the device_id 0x1030. The cards now work, but I haven't stress tested > them for performance. Bah. It sounds like an Intel ploy so that they can trivially identify these cards and put the "right" name up in the Windows network setup box. This isn't quite what the idea was with PCI IDs originally. 8( > Can someone tell me if the fxp driver is compatible with these cards (at least > it seems to work). If so, it'll be nice if the future releases of the driver > also support this card. It's probably reasonable to assume that if the driver works at all, it'll work just fine. You can help us out here by looking closely at the large funny-looking chip on the card and telling us what the part numbers on it are, since that's the only way for us to work out what the part actually is. There's quite a good chance that it's a part we already support, and all that Intel have done is change the PCI device ID in the EEPROM. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tty level buffer overflows
> > > Er, you should read the sio(4) manpage too. tty-level buffer overflows > > have nothing to do with interrupt latency/execution time. > > You mean this: > > sio%d: tty-level buffer overflow. Problem in the application. Input has > arrived faster than the given module could process it and some has been > lost. Yup. Ignore the "problem in the application" part, as that predicates that the kernel and driver are working properly, which doesn't seem to be the case. The problem here is that the buffer between the top side of the driver and the application isn't being drained fast enough. It would be educational to know what the app is sleeping on when these messages are emitted; just dropping to ddb and using 'ps' would probably be enough. There has to be some reason that the process is either not being woken when data arrives, or is being held up somewhere else for long enough that the clist overflows. Does the problem still manifest with the recent scheduler changes? Perhaps the comms processes are being unfairly scheduled against for some reason? > Normally I might agree with this, but I use a tty line on a 150Mhz i386 to > be a serial console for another freebsd box. This is a NS16550A with a 16 > byte fifo. This systems is effectively idle except for this task. So, I'm > running tip and I get constant tty-level buffer overflows at 9600 baud. > > I also have a 8 (well, 6 now since I moved and one of the system boards > blew a backplane interface chip) 50 Mhz processor SS1000 running Solaris > 2.6. It has 5 Zilog (2 byte fifo) 8530 chips running constant console > sessions with regular large amounts of output (debugging and panicing > other solaris systems for Fibre Channel work) via tip. There has never > been a lost character that I can see except due to power outage. I am > convinced to a moral certainty and beyond a reasonable doubt that if I had > a single 50Mhz processor I'd have the same experience. > > Since the Solaris tip and the FreeBSD tip are essentially identical (both > derive from BSD 4.X tip), I'd like to try and understand how this is an > application problem :-). > > -matt > > > > -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: new Intel 100Mbps card
>
> It's probably an 82558 chip. Does it support Wake-on-LAN?
>
Not sure what Wake-on-LAN means. I believe there are some cards out there
now that support some kind of network management. This is not that if that
helps.
>
> Add the device IDs to the list in the driver and recompile. If it works,
> send me the diffs and I'll commit it for you. I might even be able to beat
> one of the cards out of Intel, I used to work for the InBusiness (formerly
> Dayna Communications) crowd. ;^)
>
Like I said in my last mail, I've already done that. It works. Here are the
patches for FreeBSD-4.0-19990827-CURRENT. Please note that I tested it out
on FreeBSD-2.2.6 and ported it to FreeBSD-4.0-19990827-CURRENT (I don't have
root on a FreeBSD-4.0-19990827-CURRENT machine). Also please read the results
of some tests that I've done on the card - they're discussed after the patch
below.
--- Cut Here -
diff -ur /sys/pci/if_fxp.c pci/if_fxp.c
--- /sys/pci/if_fxp.c Tue Jul 6 14:23:25 1999
+++ pci/if_fxp.cSun Dec 5 22:33:33 1999
@@ -501,10 +501,20 @@
static int
fxp_probe(device_t dev)
{
- if ((pci_get_vendor(dev) == FXP_VENDORID_INTEL) &&
- (pci_get_device(dev) == FXP_DEVICEID_i82557)) {
- device_set_desc(dev, "Intel EtherExpress Pro 10/100B
Ethernet");
- return 0;
+ if (pci_get_vendor(dev) == FXP_VENDORID_INTEL) {
+ switch (pci_get_device(dev)) {
+ case FXP_DEVICEID_i82557:
+ device_set_desc(dev,
+ "Intel EtherExpress Pro 10/100B Ethernet");
+ return 0;
+
+ case FXP_DEVICEID_i82558:
+ device_set_desc(dev,
+ "Intel InBusiness 10/100 Ethernet");
+
+ return 0;
+ }
+
}
return ENXIO;
diff -ur /sys/pci/if_fxpreg.h pci/if_fxpreg.h
--- /sys/pci/if_fxpreg.hThu Feb 11 17:41:21 1999
+++ pci/if_fxpreg.h Sun Dec 5 22:29:13 1999
@@ -29,6 +29,7 @@
#define FXP_VENDORID_INTEL 0x8086
#define FXP_DEVICEID_i825570x1229
+#define FXP_DEVICEID_i825580x1030
#define FXP_PCI_MMBA 0x10
#define FXP_PCI_IOBA 0x14
--- Cut Here -
I tested out the card by doing some long TCP transfers over it on a LAN. It
seems to work fine but once in a while (1 in 1000 packets approximately), it
seems to receive truncated IP packets. I have thoroughly tested this out - the
sending host is not sending any truncated packets. The problem only lies on the
receiving host - the one that's using the new card. Also, it seems that the
packet in question is finally received correctly - however the sending host
never transmitted the packet again. It seems the receiving host (the one with
the new card) first gets a truncated packet and then gets the full packet.
I'm attaching a segment of tcpdump trace that demonstrates this problem. The
first and the last packets in this trace are the truncated and full versions
in question. Finally, I must add that I repeated the experiment with two hosts
both having the old 10/100B cards - I didn't see any truncated IP packets.
However, each time I used the new card, I saw truncated IP packets. I've also
the other Intel InBusiness cards - they all give the same problem (this rules
out the possibility that any one card has a hardware problem).
22:19:26.072982 truncated-ip - 8 bytes missing!192.168.12.103.6500 >
192.168.12.106.1030: . ack 3661249462 win 7920 (DF)
22:19:26.072995 192.168.12.106.1030 > 192.168.12.103.6500: .
3661250902:3661252342(1440) ack 1511615746 win 17280 (DF)
22:19:26.073031 192.168.12.106.1030 > 192.168.12.103.6500: .
3661252342:3661253782(1440) ack 1511615746 win 17280 (DF)
22:19:26.073057 192.168.12.106.1030 > 192.168.12.103.6500: .
3661253782:3661255222(1440) ack 1511615746 win 17280 (DF)
22:19:26.073082 192.168.12.106.1030 > 192.168.12.103.6500: .
3661255222:3661256662(1440) ack 1511615746 win 17280 (DF)
22:19:26.073108 192.168.12.106.1030 > 192.168.12.103.6500: .
3661256662:3661258102(1440) ack 1511615746 win 17280 (DF)
22:19:26.073132 192.168.12.106.1030 > 192.168.12.103.6500: .
3661258102:3661259542(1440) ack 1511615746 win 17280 (DF)
22:19:26.073158 192.168.12.106.1030 > 192.168.12.103.6500: .
3661259542:3661260982(1440) ack 1511615746 win 17280 (DF)
22:19:26.073182 192.168.12.106.1030 > 192.168.12.103.6500: .
3661260982:3661262422(1440) ack 1511615746 win 17280 (DF)
22:19:26.073206 192.168.12.106.1030 > 192.168.12.103.6500: .
3661262422:3661263862(1440) ack 1511615746 win 17280 (DF)
22:19:26.074336 192.168.12.103.6500 > 192.168.12.106.1030: . ack 3661249462 win 7920
(DF)
- Mohit
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: fxp, xl driver question .. (routing)
On Sun, 05 Dec 1999, you wrote: > > > The question: Why doesn't this work... it seem so straight forward... > > I'm not sure about the code in question, but the basic assumptions you're > making about PCI's behaviour are flawed. To achieve the goal you're > trying to, you need to reduce the value of the PCI bus latency timer for > the peripheral(s) that you're hoping to interrupt. I don't want to interrupt the devices.. which would require the transaction to reoccur... I do agree(from the book PCI System Architecture), the Master Latency Timer should be decreased, but I still need the DMA transactions to complete sooner from the time GNT# is removed by the arbiter. > Breaking up the DMA transactions leaves you vulnerable to the PCI > peripheral noticing that the two segments are contiguous and coalescing > them again into a single master write. I don't think the NIC will do this... However it it possible... From 3com docs, the 3c509bs don't... But I could probably reorder the dma requests to force seperate transactions... maybe, maybe not. > Also, you don't want the (high) > overhead of forcing a re-arbitration all the time, rather you want to > guarantee the worst-case cycle time involved in polling the peripheral. > Again, to achieve this, you want to look at how the PCI bus latency timer > works and use it instead. I understand how it is working, but the I still beleive smaller DMA transactions, while somewhat inefficient, will shorten the latency to something reasonable. > You will always get the best performance out of PCI by avoiding > _anything_ that involves arbitrating for the bus. PCI bus transactions > are reasonably expensive to start. 8( > I agree. If I knew I could avoid handshaking the device, I would skip it... It takes 20+% of the forwarding time.. I have another question: Is there a way to get the compiler to do a non blocking mem read ? load to a hardwired zeroed register? thanks a bunch, kurt > > > > -- > \\ Give a man a fish, and you feed him for a day. \\ Mike Smith > \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] > \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] -- uname -a > Linux wookie.vandelden.com 2.2.13 #1 < To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: new Intel 100Mbps card
> #define FXP_VENDORID_INTEL 0x8086 > #define FXP_DEVICEID_i825570x1229 >+#define FXP_DEVICEID_i825580x1030 This wouldn't be correct. The 82558 has been used for years on Pro/100+ boards and they ID as 0x1229. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: new Intel 100Mbps card
> > > #define FXP_VENDORID_INTEL 0x8086 > > #define FXP_DEVICEID_i825570x1229 > >+#define FXP_DEVICEID_i825580x1030 > >This wouldn't be correct. The 82558 has been used for years on Pro/100+ > boards and they ID as 0x1229. > Sorry, I forgot to say about the above. Since Wes Peters suggested that it might be a 82558, it put the above name. Please correct it to whatever the name should be. - Mohit To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: new Intel 100Mbps card
> > Bah. It sounds like an Intel ploy so that they can trivially identify > these cards and put the "right" name up in the Windows network setup box. > This isn't quite what the idea was with PCI IDs originally. 8( Probably. One of our faculty actually bought what seems like a slightly different version of this card. That had some kind of network management on it. The difference is that it has the same device_id as the earlier 82557 and is recognized by FreeBSD without any changes. However, upon looking at the two cards (the one that I got and the on that that faculty member got) they look pretty much the same (except for some small chips missing on my card that seem to control the network management features). I tried the other card out too - it also seems to give the IP truncated packet errors (I just posted about that in my last mail to freebsd-hackers list). > > It's probably reasonable to assume that if the driver works at all, it'll > work just fine. You can help us out here by looking closely at the large > funny-looking chip on the card and telling us what the part numbers on it > are, since that's the only way for us to work out what the part actually > is. There's quite a good chance that it's a part we already support, and > all that Intel have done is change the PCI device ID in the EEPROM. > This time there is no "large" chip on the card. The older cards that I have do have a large chip with 82557 etched on them. There is a thin, square and rather small (compared to the older cards) chip that says GD82559 on it. The same chip seems to be also there on the card that I mentioned above (from the faculty member). Please let me know if I can help in any other way with the cards - there are several chips on it and I'm not sure which one you're really looking for. - Mohit To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: new Intel 100Mbps card
> >> >> > #define FXP_VENDORID_INTEL 0x8086 >> > #define FXP_DEVICEID_i825570x1229 >> >+#define FXP_DEVICEID_i825580x1030 >> >>This wouldn't be correct. The 82558 has been used for years on Pro/100+ >> boards and they ID as 0x1229. >> > > >Sorry, I forgot to say about the above. Since Wes Peters suggested that it >might be a 82558, it put the above name. Please correct it to whatever the >name should be. From your other email it sounds like it has an 82559. Intel has been shipping that for more than a year as well on boards that ID as 0x1229, so apparantly the chip being used doesn't correlate with the ID number. In this case I'd recommend changing the above defines to "FXP_DEVICE_ID_1" and "FXP_DEVICE_ID_2" respectively. If you are confident that your 0x1230 Pro/100 is working correctly, including stuff related to manual selection of the speed and duplex, then I'll take care of making the changes to the driver. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: new Intel 100Mbps card
> >From your other email it sounds like it has an 82559. Intel has been > shipping that for more than a year as well on boards that ID as 0x1229, > so apparantly the chip being used doesn't correlate with the ID number. I mentioned another similar card in my last posting. That one I got from a faculty member (he's Alan Cox - also works on FreeBSD). That card is very similar (in looks and performance) to the one that I got but has the device ID of 0x1229 (same as 10/100B). Additionally, Alan mentioned that some small additional chips on it are supposed to do some kind of network mgmnt - I believe that was the Wake-on-LAN feature. The card that I have, however, is similar, but has a different PCI device_Id - 0x1030. So you're probably right in that the chip doesn't correlate with the ID number. > In this case I'd recommend changing the above defines to "FXP_DEVICE_ID_1" > and "FXP_DEVICE_ID_2" respectively. If you are confident that your 0x1230 > Pro/100 is working correctly, including stuff related to manual selection > of the speed and duplex, then I'll take care of making the changes to > the driver. Its 0x1030 - not 0x1230. I've tried it only in full-duplex and it works fine (except for the truncated IP packets that I mailed about). My /etc/rc.conf has "media 100baseTX mediaopt full-duplex" for the ifconfig command. I was able to get about 77 Mbps on a 100Mbps LAN with this card. With the older ones, I can get about 93 Mbps (which is the maximum if packet headers are taken into account). The difference in performance is probably due to the truncated IP packets I mentioned. I can try other settings on this card if you can tell me which ones you're interested in. - Mohit To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: new Intel 100Mbps card
Mohit Aron wrote: > > > > > > #define FXP_VENDORID_INTEL 0x8086 > > > #define FXP_DEVICEID_i825570x1229 > > >+#define FXP_DEVICEID_i825580x1030 > > > >This wouldn't be correct. The 82558 has been used for years on Pro/100+ > > boards and they ID as 0x1229. > > > > Sorry, I forgot to say about the above. Since Wes Peters suggested that it > might be a 82558, it put the above name. Please correct it to whatever the > name should be. If you can't find the id on the chip, I'll see what I can track down at Intel tomorrow. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: new Intel 100Mbps card
> > If you can't find the id on the chip, I'll see what I can track down at > Intel tomorrow. > I am looking up the Intel website. The chip indeed is 82559. Also there doesn't seem to be a correlation between the chip and the PCI device_id. I have two network cards (I mentioned them in my last postings) with different device_ids but the same 82559 chip on them. >From the Intel's page, I was able to find the technical names for the two cards that I've been talking about. 1) Intel InBusiness 10/100 adaptor - this one has a device_id of 0x1030. 2) Pro/100+ PCI Management adaptor (board id number is 721383-xxx). This has the usual PCI device_id of 0x1229. The relevant website that displays the above information is: http://support.intel.com/support/network/adapter/pro100/21397.htm - Mohit To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Per CPU timekeeping for SMP
Here's a reimplementation of my earlier per cpu time keeping patch
on SMP. The attached patch is against a 11/20/99 -current that I
cvsup'ed.
1. On UP,
sys_time is a global and contains the system wide stats
cpu_time is a global and is essentially the same as sys_time.
2. On SMP
sys_time contains the system wide stats
cpu_time has been changed to a pointer in the per-cpu space.
On BSP, this pointer points to a static array cpu0_cpu_time
On APs, this space is kmem_alloc'ed
Perhaps I should wrap cpu_time in a structure (cpu_info ?), which
could be the right place to store all per CPU info.
3. I've taken the liberty of changing CP_* to CPU_*. I hope the new names
better convey the meaning of the variables and are acceptable.
4. I've gotten sysctls working for sys_time -
$ sysctl -A | grep kern.stats
kern.stats.systime.user: 25150
kern.stats.systime.nice: 3878
kern.stats.systime.sys: 14071
kern.stats.systime.intr: 7395
kern.stats.systime.idle: 5326029
I'm working on generating the per cpu sysctls.
5. The machine specific code for Alpha will need some changes - which I
can implement, but have no way of compiling or testing.
6. All the existing utilties which depended on peeking at cp_time will
break (which is a good thing, IMO - so that I can fix them. :-) They
will all be converted to use sysctl, as time permits.
Now, about the release schedule for this work - am I too late for the
12/15 feature freeze ? I'd appreciate some comments on the implementation,
so that if there are any issues, I can fix them before 12/15.
-Arun
Index: i386/i386/genassym.c
===
RCS file: /home/adsharma/cvs_root/freebsd-sys/i386/i386/genassym.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 genassym.c
--- genassym.c 1999/11/20 23:46:06 1.1.1.4
+++ genassym.c 1999/12/05 19:45:42
@@ -205,6 +205,7 @@
printf("#define\tGD_PRV_PADDR1 %#x\n", OS(globaldata, gd_prv_PADDR1));
printf("#define\tPS_IDLESTACK %#x\n", OS(privatespace, idlestack));
printf("#define\tPS_IDLESTACK_TOP %#x\n", sizeof(struct privatespace));
+ printf("#define\tGD_CPU_TIME %#x\n", OS(globaldata, gd_cpu_time));
#endif
printf("#define\tKCSEL %#x\n", GSEL(GCODE_SEL, SEL_KPL));
Index: i386/i386/globals.s
===
RCS file: /home/adsharma/cvs_root/freebsd-sys/i386/i386/globals.s,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 globals.s
--- globals.s 1999/08/31 05:12:09 1.1.1.2
+++ globals.s 1999/12/05 19:46:11
@@ -79,6 +79,7 @@
.setgd_currentldt,globaldata + GD_CURRENTLDT
#endif
+
#ifndef SMP
.globl _curproc, _curpcb, _npxproc
.globl _common_tss, _switchtime, _switchticks
@@ -122,6 +123,9 @@
.setgd_prv_CADDR2,globaldata + GD_PRV_CADDR2
.setgd_prv_CADDR3,globaldata + GD_PRV_CADDR3
.setgd_prv_PADDR1,globaldata + GD_PRV_PADDR1
+
+ .globl gd_cpu_time
+ .setgd_cpu_time,globaldata + GD_CPU_TIME
#endif
#if defined(SMP) || defined(APIC_IO)
Index: i386/i386/machdep.c
===
RCS file: /home/adsharma/cvs_root/freebsd-sys/i386/i386/machdep.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 machdep.c
--- machdep.c 1999/11/20 23:46:07 1.1.1.4
+++ machdep.c 1999/12/05 21:59:13
@@ -114,6 +114,7 @@
#ifdef SMP
#include
#include
+#include /* For cpu_time */
#endif
#ifdef PERFMON
#include
@@ -143,6 +144,10 @@
static MALLOC_DEFINE(M_MBUF, "mbuf", "mbuf");
+#ifdef SMP
+static cpu0_cpu_time[NCPUSTATES];
+#endif
+
int_udatasel, _ucodesel;
u_int atdevbase;
@@ -1964,6 +1969,11 @@
proc0.p_addr->u_pcb.pcb_mpnest = 1;
#endif
proc0.p_addr->u_pcb.pcb_ext = 0;
+
+#ifdef SMP
+ /* Setup cpu0's cpu_time */
+ cpu_time = &cpu0_cpu_time;
+#endif
}
#if defined(I586_CPU) && !defined(NO_F00F_HACK)
Index: i386/i386/mp_machdep.c
===
RCS file: /home/adsharma/cvs_root/freebsd-sys/i386/i386/mp_machdep.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 mp_machdep.c
--- mp_machdep.c1999/11/20 23:46:07 1.1.1.4
+++ mp_machdep.c1999/12/05 19:48:29
@@ -243,6 +243,11 @@
/** XXX FIXME: what system files declare these??? */
extern struct region_descriptor r_gdt, r_idt;
+extern long sys_time[NCPUSTATES];
+#ifndef SMP
+extern long cpu_time[NCPUSTATES];
+#endif
+
intbsp_apic_ready = 0; /* flags useability of BSP apic */
intmp_ncpus; /* # of CPUs, including BSP */
intmp_naps;/* # of Applications processors */
@@ -1798,6 +1803,9 @@
SMPpt[pg + 3] = 0; /* *prv_CMAP3 */
SMPpt[pg + 4] = 0; /* *prv_PMAP1 */
+ /* space for
Re: new Intel 100Mbps card
David Greenman wrote: > > > > >Sorry, I forgot to say about the above. Since Wes Peters suggested that it > >might be a 82558, it put the above name. Please correct it to whatever the > >name should be. > >From your other email it sounds like it has an 82559. Intel has been > shipping that for more than a year as well on boards that ID as 0x1229, > so apparantly the chip being used doesn't correlate with the ID number. > In this case I'd recommend changing the above defines to "FXP_DEVICE_ID_1" > and "FXP_DEVICE_ID_2" respectively. If you are confident that your 0x1230 > Pro/100 is working correctly, including stuff related to manual selection > of the speed and duplex, then I'll take care of making the changes to > the driver. This might be the new 82559ER; I'm downloading the datasheet now. Have a peek at: http://developer.intel.com/design/network/datashts/index.htm -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: new Intel 100Mbps card
Wes Peters wrote: > > This might be the new 82559ER; I'm downloading the datasheet now. Have > a peek at: > > http://developer.intel.com/design/network/datashts/index.htm Nope, that one is apparently device ID 0x1209. Too bad they don't have a PCI device ID cross-reference on the web site. Bleh. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
