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 category in which I put most of the recent changes to procfs and /bin/ps.
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 vmcore.9 | grep dgilbert_ ... 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
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: 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 Link 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: 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 nfs/nqnfs.h
#include nfs/nfsnode.h
+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 backward */
+
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: 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 nop,nop,timestamp 376766
38388,nop,[|tcp] (DF)
22:19:26.072995 192.168.12.106.1030 192.168.12.103.6500: .
3661250902:3661252342(1440) ack 1511615746 win 17280 nop,nop,timestamp 38388
376766,nop,nop,eol,[|tcp] (DF)
22:19:26.073031 192.168.12.106.1030 192.168.12.103.6500: .
3661252342:3661253782(1440) ack 1511615746 win 17280 nop,nop,timestamp 38388
376766,nop,nop,eol,[|tcp] (DF)
22:19:26.073057 192.168.12.106.1030 192.168.12.103.6500: .
3661253782:3661255222(1440) ack 1511615746 win 17280 nop,nop,timestamp 38388
376766,nop,nop,eol,[|tcp] (DF)
22:19:26.073082 192.168.12.106.1030 192.168.12.103.6500: .
3661255222:3661256662(1440) ack 1511615746 win 17280 nop,nop,timestamp 38388
376766,nop,nop,eol,[|tcp] (DF)
22:19:26.073108 192.168.12.106.1030 192.168.12.103.6500: .
3661256662:3661258102(1440) ack 1511615746 win 17280 nop,nop,timestamp 38388
376766,nop,nop,eol,[|tcp] (DF)
22:19:26.073132 192.168.12.106.1030 192.168.12.103.6500: .
3661258102:3661259542(1440) ack 1511615746 win 17280 nop,nop,timestamp 38388
376766,nop,nop,eol,[|tcp] (DF)
22:19:26.073158 192.168.12.106.1030 192.168.12.103.6500: .
3661259542:3661260982(1440) ack 1511615746 win 17280 nop,nop,timestamp 38388
376766,nop,nop,eol,[|tcp] (DF)
22:19:26.073182 192.168.12.106.1030 192.168.12.103.6500: .
3661260982:3661262422(1440) ack
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
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
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 machine/smp.h
#include machine/globaldata.h
+#include sys/dkstat.h/* For cpu_time */
#endif
#ifdef PERFMON
#include machine/perfmon.h
@@ -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;
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
