Re: Keeping track with latest kernel ? CVSweb ?
On Thursday, 28 February 2002 at 11:42:17 +1100, Andrew wrote: On Thu, 28 Feb 2002, Wilkinson,Alex wrote: ie a way to know that the kernel has been updated so I can compile the new one. cvsup and watch the output is probably easiest. Note that it's not possible to build a new kernel every time something changes. There are dozens of updates every day. Greg -- 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: Kernel Debugging over the Ethernet?
On Tuesday, 19 February 2002 at 21:36:25 -0800, George V. Neville-Neil wrote: Hi Folks, Now that Luigi has put in polling support for some ethernet drivers I was wondering how much work it would be to make the remote kernel debugging run over the ethernet. I have worked on systems like this before (it's the reason I did polling network device drivers in Wind River's VxWorks) but it depends on a debugging system that has the ability to have its back end swapped out. Who would I talk to about how kernel debugging works at the lowest layers right now? Which source files should I look at first. I was talking to Louis Gerbarg about this topic at the BSDCon last week. Apparently Darwin already has this functionality, so I suppose you'd like to take a look at it. Greg -- 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: Kernel Debugging over the Ethernet?
On Wednesday, 20 February 2002 at 16:52:48 -0800, Julian Elischer wrote: On Wed, 20 Feb 2002, George V. Neville-Neil wrote: I was talking to Louis Gerbarg about this topic at the BSDCon last week. Apparently Darwin already has this functionality, so I suppose you'd like to take a look at it. That depends on where they put it. If it depends on I/OKit then we won't be able to use it easily I figure. yes but we might as well be protocol compatible if possible :-) If only to re-use what they did in gdb :-) No question. But protocols are a separate issue. One of the most amusing things I discovered recently is that you can use a FreeBSD gdb to kernel debug Linux :-) Greg -- 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: Kernel Debugging over the Ethernet?
On Wednesday, 20 February 2002 at 17:03:38 -0800, Julian Elischer wrote: On Thu, 21 Feb 2002, Greg Lehey wrote: On Wednesday, 20 February 2002 at 16:52:48 -0800, Julian Elischer wrote: On Wed, 20 Feb 2002, George V. Neville-Neil wrote: I was talking to Louis Gerbarg about this topic at the BSDCon last week. Apparently Darwin already has this functionality, so I suppose you'd like to take a look at it. That depends on where they put it. If it depends on I/OKit then we won't be able to use it easily I figure. yes but we might as well be protocol compatible if possible :-) If only to re-use what they did in gdb :-) No question. But protocols are a separate issue. One of the most amusing things I discovered recently is that you can use a FreeBSD gdb to kernel debug Linux :-) you mean they use the same protocol? That's the obvious conclusion. Of course, Linux doesn't have serial gdb by default; you have to piece it together from all over the net. Greg -- 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: FreeBSD-1.X public cvs?
On Wednesday, 30 January 2002 at 9:41:15 -0700, Nate Williams wrote: Caldera's License Agreement: http://www.tuhs.org/Archive/Caldera-license.pdf Thanks. However, this isn't as specific as I'd like it to be. It implies that Net1/Net2 are now 'legal', but it doesn't give explicit release of said source code. Well, I have never heard claims that BSD was tainted by any USL release besides 32V, so this is good enough for me to put my 1.X tree up without fearing ugly lawyers. Now, where did all those CD's go... If all else fails I have stored my FreeBSD 1.0 CD as a precious gem ;) Cannot find the 386BSD 0.1 + PK024 QIC tape though :( A FreeBSD 1.X CVS tree has been found, which has it's first import as 386BSD 0.1 + PK 024. There are a couple minor points that need to be clarified from Caldera before it can be made public. There are? What are they? Who's doing it? Greg -- 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: FreeBSD-1.X public cvs?
- Forwarded message from Nate Williams [EMAIL PROTECTED] - Date: Tue, 29 Jan 2002 15:55:04 -0700 From: Nate Williams [EMAIL PROTECTED] To: Tony Finch [EMAIL PROTECTED] Cc: Dominic Marks [EMAIL PROTECTED], Nate Williams [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: FreeBSD-1.X public cvs? X-Mailer: VM 6.96 under 21.1 (patch 14) Cuyahoga Valley XEmacs Lucid Now that ancient unix has been relicensed with an old-style BSD licence, is the FreeBSD-1.X cvs repository going to be made public? Out of curiousity, why? Out of curiousity :) Kirk was surprised by how popular the CSRG archives CDs are. I got one of those too. :) And, where have you heard that it's been relicensed? http://minnie.tuhs.org/PUPS/ There's also a link from Caldera's own site http://www.caldera.com/company/news/ Thanks. I'm going to wait and see what happens w/regards to the talking heads on this, and if the consensus is that it's legal to post, I'll upload the bits to freefall. It's legal. Here's the original message. I'm also copying Dion Johnson. Dion, as I'm sure you're aware, we took the FreeBSD 1.x sources offline because they were tainted with ATT code. Now that 32V is free, there should be no further problem releasing them, right? Greg Date: Wed, 23 Jan 2002 15:03:37 -0800 From: Dion Johnson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], John Terpstra [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Liberal license for ancient UNIX sources Dear Warren, and friends, I'm happy to let you know that Caldera International has placed the ancient UNIX releases (V1-7 and 32V) under a BSD-style license. I've attached a PDF of the license letter hereto. Feel free to propogate it as you see fit. I apologize that this has taken so long. We do not have a well regulated archive of these ancient releases, so we must depend upon you UNIX enthusiasts, historians, and original authors to help the community of interested parties figure out exactly what is available, where, and how. Many thanks to Warren Toomey, of PUPS, and to Caldera's Bill Broderick, director of licensing services here. Both of these gentlemen were instrumental in making this happen. And thanks to our CEO, Ransom Love, whose vision for Caldera International prescribes cooperation and mutual respect for the open source communities. Of course, there are thousands of other people who should be acknowledged. I regret I do not have time or wisdom to make a list of them all, but maybe someone does, or has. Anyway, here it is. Feel free to write to us if you want to understand more about how/why Caldera International has released this code, or you have any other comments that we should hear. Sincerely, Dion L. Johnson II - [EMAIL PROTECTED] Product Manager and one of many open source enthusiasts in Caldera Intl. Paul Hatch - [EMAIL PROTECTED] Public Relations Manager at Caldera International -- 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: FreeBSD-1.X public cvs?
On Tuesday, 29 January 2002 at 15:56:32 -0800, Dion Johnson wrote: On Wed, Jan 30, 2002 at 10:05:20AM +1030, Greg Lehey wrote: On Tue, 29 Jan 2002 15:55:04 -0700, Nate Williams [EMAIL PROTECTED] wrote: And, where have you heard that it's been relicensed? http://minnie.tuhs.org/PUPS/ There's also a link from Caldera's own site http://www.caldera.com/company/news/ Thanks. I'm going to wait and see what happens w/regards to the talking heads on this, and if the consensus is that it's legal to post, I'll upload the bits to freefall. It's legal. Here's the original message. I'm also copying Dion Johnson. Dion, as I'm sure you're aware, we took the FreeBSD 1.x sources offline because they were tainted with ATT code. Now that 32V is free, there should be no further problem releasing them, right? Yes it is most certainly our intent to free up the ancient Unix sources so that they can be used, essentially, for anything. Caldera asks for some acknowledgement, and disclaims all the usual stuff. I cant completely answer the question about your archives since I have not examined them and I dont know what other taint may be present. But as far as the ancient Unix, and the ATT source license requirement is concerned, I think this part of the problem has gone away. Well, we restricted access to the repository only because of the USL lawsuit, so I'm pretty confident that there's nothing else in there which we know about. Caldera really does want this to be a happy, open source party of geek fun. We are not looking to trick anyone with secret legal viruses hidden in the code, or dark incantations buried in the fine print. ;-) Thanks :-) Greg -- 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: vinum write spanning
On Monday, 28 January 2002 at 18:34:10 +0100, Bernd Walter wrote: On Mon, Jan 28, 2002 at 09:49:59AM -0500, Jason Andresen wrote: I'm hoping there is an easy answer to this one... Is there some way vinum can be tickled such that it writes to all disks in a plex at once? For instance, say I have a 6 disk RAID5 array that I'm writing a 200MB file to. Is there some way I can make vinum attempt to write data to all of the drive simultaniously? You can't easily increase performance in a single file access case with more disks. Especialy in the R5 case where you have several blocks depend on the same parity. Well, in fact it's particularly interesting in the RAID-5 case: then you can write an entire band without having to read first, thus doubling the throughput. The problem with this approach is that FreeBSD is currently limited to an I/O size of 128 kB. A reasonable stripe size for RAID-5 is 300 kB or so, so in Jason's example you'd have to be able to issue an I/O request of 1.5 MB. Until this is possible, there's no point in writing the code (which would be possible, though not trivial). If vinum already does that I'm probably just saturating the PCI bus and there's nothing more I can do, but it seems like I should have a tougher time saturating the bus with 5400RPM drives... Vinum is designed for multiple file access which is a more common situation for a unix system. Well, it tries to be universally useful. But this particular optimization doesn't currently make sense. Greg -- 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: Oh my god, Google has a USENET archive going back to 1981!
[moved to -chat] On Monday, 7 January 2002 at 21:21:54 -0500, [EMAIL PROTECTED] wrote: In a message dated 01/07/2002 7:32:36 PM Eastern Standard Time, [EMAIL PROTECTED] writes: Drool away, buddy! Here's mine, and it still works (chicklet keyboard, built in cassette drive, metal filing cabinet company case,40 character BW monitor, and all): PET 2001-8 SN: 0031620 I have some of the original flyers for the PET and CBM boxes, as well as the yellow folded 4 page 8x11 BASIC Reference sheet, too... Space Invaders Anyone? 8-) 8-) Think they have the code to the C64 supermon assembler? I spend 3 evenings poking it in from Compute! and now I can't find the cassette anywhere. Why not search for it? I got 35 hits on +c64 +supermon. Greg -- 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: Does FreeBSD have a problem with some AMD processors?
On Friday, 28 December 2001 at 13:23:50 +0100, Søren Schmidt wrote: It seems Greg Lehey wrote: Information that could be interesting is (here my values): Processor:AMD Duron 850 Motherboard: ECS K7VZA Memory:1 128 MB SIMM, 100 MHz. What FreeBSD version are you using ? I have put a fix for the 686b southbridge bug in -current, but it is not in -stable yet... Hmm, this is 4-STABLE. Can you point me at the fix, and I'll try it out. I notice that the Linux dmesg says: PCI: Using IRQ router VIA [1106/0686] at 00:07.0 Applying VIA southbridge workaround. So that could be the issue. I've got a 686 Southbridge on the Athlon XP as well, but it's running -CURRENT. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply. For more information, see http://www.lemis.com/questions.html 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: Does FreeBSD have a problem with some AMD processors?
On Friday, 28 December 2001 at 6:21:04 -0800, Keith Simonsen wrote: Greg, Do not forget to check your power supply make/model. If you search on google for AMD's recommended hardware list, double check you're power supply is listed for your cpu. This wouldn't explain why it works fine under Linux (and yes, it's still going). Greg -- 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: Does FreeBSD have a problem with some AMD processors?
On Friday, 28 December 2001 at 14:46:12 -0600, Glenn Johnson wrote: On Fri, Dec 28, 2001 at 06:10:09PM +1030, Greg Lehey wrote: I've been using AMD processors almost exclusively in my main work machines for over 4 years, and I've been very happy with them. I'm currently running a K6/233, a K6/333, an Athlon 750, a Duron 850 and an Athlon XP 1700. Last August, though, I bought a machine which gave me a lot of trouble, the Duron 850 mentioned above. I found that it would freeze for no apparent reason. I established that it wasn't the memory by taking the memory of another machine and running it like that; it made no difference. I ended up also changing the motherboard and the processor, but the hangs continued. I could expect a hang within 8 hours when doing 'make release' Just for the fun of it, I tried running Linux on it. I've been running a kernel build and 'make clean' on it now for 36 hours, and it's still running fine. Yesterday some Linux friends of mine came around and looked at it and told me that the Linux kernel I was running on the machine (2.4.16) had had a number of AMD-specific fixes put in. He didn't go into more detail, unfortunately, but I'll ask him again when I have time: it could be something relating to chipset bugs we have seen and fixed. It would help to know, though, if other people are experiencing similar problems. Please let me know if you're having problems with AMD processors which seem to be specific to FreeBSD, especially if they're hangs (i.e. the machine stops reacting, but the display still shows the last state, it doesn't reboot or panic). I have had this exact problem. I have an Epox 8KTA board with a 1GHz Athlon (Thunderbird) with 256MB of PC-133 memory. I would consistently get random errors, usually during a compilation, using the default BIOS settings. After fiddling with some of the BIOS options, such as enabling PCI burst, the system runs pretty stable. However, occasionally I will get that freeze that you refer to during a buildworld. As far as I can tell though if I set the memory clock to 100MHz the problem goes away completely, or at least I have not observed it happen yet. This is a Duron, so it has a 100 MHz memory clock anyway. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply. For more information, see http://www.lemis.com/questions.html 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: Does FreeBSD have a problem with some AMD processors?
On Friday, 28 December 2001 at 23:12:40 +0100, Søren Schmidt wrote: It seems Glenn Johnson wrote: It is really hard for me to say if this is FreeBSD specific because I do not tend to stress the system much when I have Linux running. My wife has an identical system running Windows 98SE and she has no problems but I know that I have installed software from Epox that specifically addresses some issues with the VIA chipset so that may be why. From what I can tell the newest Epox BIOS for the 8kta3 does *not* install the 686b fix when it doesn't detect a SBLive! sound card, nice but not good enough :/ Hmm, it has just occurred to me that this 686B fix relates to ata disks, doesn't it? The machine I'm having the problem with doesn't have any ata disks: I deliberately took them out to eliminate this source of problems. So this could be a different problem. Greg -- 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
Does FreeBSD have a problem with some AMD processors?
I've been using AMD processors almost exclusively in my main work machines for over 4 years, and I've been very happy with them. I'm currently running a K6/233, a K6/333, an Athlon 750, a Duron 850 and an Athlon XP 1700. Last August, though, I bought a machine which gave me a lot of trouble, the Duron 850 mentioned above. I found that it would freeze for no apparent reason. I established that it wasn't the memory by taking the memory of another machine and running it like that; it made no difference. I ended up also changing the motherboard and the processor, but the hangs continued. I could expect a hang within 8 hours when doing 'make release' Just for the fun of it, I tried running Linux on it. I've been running a kernel build and 'make clean' on it now for 36 hours, and it's still running fine. Yesterday some Linux friends of mine came around and looked at it and told me that the Linux kernel I was running on the machine (2.4.16) had had a number of AMD-specific fixes put in. He didn't go into more detail, unfortunately, but I'll ask him again when I have time: it could be something relating to chipset bugs we have seen and fixed. It would help to know, though, if other people are experiencing similar problems. Please let me know if you're having problems with AMD processors which seem to be specific to FreeBSD, especially if they're hangs (i.e. the machine stops reacting, but the display still shows the last state, it doesn't reboot or panic). Information that could be interesting is (here my values): Processor:AMD Duron 850 Motherboard: ECS K7VZA Memory: 1 128 MB SIMM, 100 MHz. Greg -- For more information, see http://www.lemis.com/questions.html 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: Instead of JFS, why not a whole new FS?
On Monday, 17 December 2001 at 22:50:45 -, Dave Reyenga wrote: How about writing a new filesystem based on UFS? If it's based on UFS, it's not a new file system. This would save all of the hassle that JFS would bring: licensing, porting time, etc. There are no hassles with licensing. You'd be balancing porting time against writing time. Guess which would take longer. What I'm thinking is a filesystem that takes the current UFS and improves upon it. It could support larger partitions, That's relatively trivial. The big issue is compatibility. more partitions in a slice, That's relatively trivial. The big issue is compatibility. and perhaps a Journal partition (like the current swap partition) Well, I don't think the journal would be like swap. among other new features. That's pretty much what IBM did. They called the result JFS. Greg -- 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: Adding a new FS to FreeBSD
On Sunday, 16 December 2001 at 18:37:33 +1100, Warren Toomey wrote: I would say that FreeBSD already has a nearly-working UFS implementation. Also, the structure of UFS is so well documented in various books that, even if FreeBSD's UFS implementation was deficient, it could be rectified with reference to the books. I think we should put that in the fortune database :-) Greg -- 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: Caldera and the Ancient UNIX license
On Sunday, 16 December 2001 at 17:18:37 +1100, Warren Toomey wrote: In article by Greg Lehey: [about if and how Caldera is enforcing the Ancient UNIX http://www2.caldera.com/offers/ancient.html. Note also that in fact they allow access to the code via license described at http://www2.caldera.com/offers/ancient001/ without you first agreeing to the license...] That may be easier than you think. I'm copying Warren Toomey on this. Warren is (a) a FreeBSD user and (b) the person who negotiated these contracts in the first place. Warren, Peter is thinking of porting the 2BSD file system (not sure whether that's UFS or the original UNIX file system) to FreeBSD. As Terry observes, the current license doesn't allow that. Firstly, call me crazy, but I thought the 2BSD filesystem layout was essentially UFS, i.e i-nodes at the start, and therefore would be pretty much the same as /sys/ufs/ufs in FreeBSD. I'll have to do a compare of the source code and get back to you One of the things I said before you came in was that that depends on the value of 2. 2.0BSD certainly didn't have ffs. Which brings me to the question, does anybody know a good contact at Caldera who can point us to the `right person' to negotiate on this. I knew the guy at SCO who dealt with this, but not at Caldera. Hmm, I thought you would know. Have you asked Dion? Greg -- 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: Adding a new FS to FreeBSD
On Saturday, 15 December 2001 at 0:39:32 -0800, Terry Lambert wrote: Greg Lehey wrote: Do you have small images of this FS, as well as header files that are redistributable (e.g. BSD license) and/or code? If you have the tools sources (e.g. newfs, fsck, etc.), this would be useful, as well, since I could vnconfig a device and recreate an empty FS image with native tools (self hosted), as well. I've got everything here, but it sounds like Jeremy does too. Depending on the value of 2, this is either the old 6th edition file system or an early variant of UFS; either's not difficult. If anyone wants to put this stuff up on a web site so I can grab it before I go on vacation next week, I can work on it over the break, since I will probably be going stir-crazy anyway, jonesing for some code to write... Unfortunately, it's still copyrighted. You need an SCO license; want to go and get one of them? It doesn't cost anything, but I can't give the software to anybody who hasn't agreed to the conditions. Get the license at http://shop.caldera.com/caldera/ancient.html (yup, that's what SCO has become). Note that the link to PUPS in the follow-on page (http://www2.caldera.com/offers/ancient001/) is broken: it's now http://minnie.tuhs.org/PUPS/ Greg -- 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: Adding a new FS to FreeBSD
On Saturday, 15 December 2001 at 3:18:33 -0800, Terry Lambert wrote: Greg Lehey wrote: Unfortunately, it's still copyrighted. You need an SCO license; want to go and get one of them? It doesn't cost anything, but I can't give the software to anybody who hasn't agreed to the conditions. 8.4(b) says you can't give it to anyone, even if they do have the license, unless you contact Caldera first, and then maintain (in perpeturity) a list of the sources made available. This is rather contradicted by the bottom of http://www2.caldera.com/offers/ancient001/: Now that you have agreed to the license you may choose to apply for access to their archive of older UNIX or request a CD of this archive. I'm one of the people who make the archive available, so feel free to contact me :-) I think we are screwed by section 2.1(d) anyway: Commercial use by LICENSEE of SOURCE CODE PRODUCTS or of any result, enhancement or modification associated with the use of SOURCE CODE PRODUCTS under this AGREEMENT is not permitted. Basically, I couldn't get an article out of it because I could't disclose it to anyone but a licensesee, and only a licensee could use the code, and I couldn't give source to the licensee without the permission of Caldera, and once they had the code, they could not use it for anything commercial unless they negotiated a seperate commercial use license. That may be easier than you think. I'm copying Warren Toomey on this. Warren is (a) a FreeBSD user and (b) the person who negotiated these contracts in the first place. Warren, Peter is thinking of porting the 2BSD file system (not sure whether that's UFS or the original UNIX file system) to FreeBSD. As Terry observes, the current license doesn't allow that. Terry, the other thing you *can* do is access the source code once you have agreed to the conditions. See the reference to http://minnie.cs.adfa.edu.au/cgi-bin/pupsco.cgi at the bottom of the page http://www2.caldera.com/offers/ancient001/. Change this to http://minnie.tuhs.org/cgi-bin/pupsco.cgi and you should be able to access it. Again, Warren is the person to talk to if you have trouble. Frankly, if you want to provide small disk images (preferrably, very small, not multimegabyte) as I've described are needed anyway, along with a description of the what's on the images, along with such layout information as you feel comfortable providing, I'd pretty much rather reverse engineer the stuff than get a Caldera license. It's a slow way of doing things. Of course, if this is an old version of UFS, you might find it easy enough to get our current UFS to grok the layout. Note that Caldera is merely doing due diligence here; I don't think that they really care too much. Greg -- 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: Adding a new FS to FreeBSD
On Friday, 14 December 2001 at 6:16:27 -0800, Terry Lambert wrote: Peter Jeremy wrote: Since JFS has come up again... Are there any papers that explain how to integrate a new filesystem into FreeBSD? The relevant chapter in the FreeBSD Developers' Handbook (16) is a bit terse :-). Specifically, I'm looking at being able to read/write 2BSD filesystems on my FreeBSD machines. Do you have small images of this FS, as well as header files that are redistributable (e.g. BSD license) and/or code? If you have the tools sources (e.g. newfs, fsck, etc.), this would be useful, as well, since I could vnconfig a device and recreate an empty FS image with native tools (self hosted), as well. I've got everything here, but it sounds like Jeremy does too. Depending on the value of 2, this is either the old 6th edition file system or an early variant of UFS; either's not difficult. Greg -- 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: [SUGGESTION] - JFS for FreeBSD [VOTE]
On Wednesday, 12 December 2001 at 1:43:10 -0800, Hiten Pandya wrote: Hi, as i said also before, my intentions were never to cause havoc on the mailing list. :-) In simple terms, what i am saying is, the people who would like to port the JFS file system, should put a +1 in their next message and -1 if they dont like to port JFS. Then, i will count the votes, and if +1 outweighs -1, then i will try to gether developers who can help me in this task, and try to finish it by Sept. 2002. BUT, if -1 outweighs +1, then i will cancel the project and live it for my spare time, and will not go around asking everyone about it... OR, another way of doing this would be to, just try and get this JFS porting done by people who would like to do it (including me), and then put it on the FreeBSD site. This is the traditional way to do it. You don't need anybody's permission :-) You can also be sure that you won't get many replies either way, and those you get may not be representative of the project as a whole. Just Do It. Greg -- 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: [SUGGESTION] - JFS for FreeBSD
On Tuesday, 11 December 2001 at 1:08:23 -0800, Terry Lambert wrote: Greg Lehey wrote: FS porting to FreeBSD is actually pretty trivial(*), though some transactioning changes to the FreeBSD VFS layer consumers (the system calls and NFS server code) would be necessary to make the journal roll-back function correctly, following a failure. (*) Trivial: meaning grunt work is required; not necessarily an indicator of the amount of work, only the intellectual effort required for the job Considering that the current UFS implementation didn't need to be ported, and people are still working on the details, I think that this is a highly misleading statement. The current UFS has a number of issues which make it non-trivial; it was, in effect, a port; here is the short list: snip Live code always has issues, particularly if you are trying to pound a round peg into a square hole (hence Kirk taking up the task of a redesign). Of course. But you're missing the point: ufs is *not* a port, it has been with BSD since the beginning. There is a similar list of items for JFS which would need to be addressed, with the additional issue of the fact that it was not designed for FreeBSD. I think that everyone saying Ut oh! SCARY! gives people the wrong idea, and scares off potential contributors in these areas. I'm not saying that. I'm saying that it's non-trivial, which I suppose is what you mean when you say where are the patches?. As I said, I'm quite happy to help people port JFS2 to FreeBSD. On Tuesday, 11 December 2001 at 2:26:45 -0800, Hiten Pandya wrote: [... Hiten want's to GPL'ify FreeBSD ...] hi, first of all, i would like to clear of some point which have been taken wrongly. o My Intentions were never to GPL'ify FreeBSD :-) Agreed, I don't think anybody thought that. o The reason i started this discussion was because i think JFS/JFS2 would be a nice addition to FreeBSD like the rest of the other filesystems. o The JFS does _not_ have to be root, and even if people were to download it because it is GPL'ed, the size of the filesystem is only around 1.0MB If we port JFS2, it will be relatively trivial to have it as the root file system too. o It is hard to Port AIX or OS/2 based code, but we have to agree that, BSD Users were meant to take that kind of challenges, have taken before It's probably easier to port AIX based code than OS/2 or Linux based code. Greg -- 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: [SUGGESTION] - JFS for FreeBSD
On Tuesday, 11 December 2001 at 19:42:30 -0800, Terry Lambert wrote: Greg Lehey wrote: Of course. But you're missing the point: ufs is *not* a port, it has been with BSD since the beginning. There is a similar list of items for JFS which would need to be addressed, with the additional issue of the fact that it was not designed for FreeBSD. I maintain that the FreeBSD UFS *is* a port of the Heidemann implementation from the FICUS project, which had to be done because certain files were claimed to be contaminated with USL IP, and were removed as part of the USL/UCB settlement (6 key files from 5 subsystems, which they thought we couldn't rewrite from scratch in time to be a competitive threat). Which files? Did they require adapting to a different environment? I also maintain that the most difficult thing is getting the list of items, and, with the information from the UFS work in hand, the JFS specific items not on that list are trivial (there are exactly two items, in fact: log roll forward/backward, and transaction abort). I'd expect these to be the easiest parts, since they don't have too much to do with the rest of the system. One of the issues with Linux is that the interface to the rest of the system, and I don't expect these parts to have much interfacing to do. I think that everyone saying Ut oh! SCARY! gives people the wrong idea, and scares off potential contributors in these areas. I'm not saying that. I'm saying that it's non-trivial, which I suppose is what you mean when you say where are the patches?. As I said, I'm quite happy to help people port JFS2 to FreeBSD. I ported the entire GFS user space tools set, sans two, to FreeBSD in about 2 hours. I expect the user space tools for JFS2 to be pretty straightforward too. If we port JFS2, it will be relatively trivial to have it as the root file system too. Only, you will never be able to build a firewall, router, or other product that ships with it statically linked into the kernel, since that would violate the terms of the GPL (additional restrictions, and linked code not being GPL'ed). Fine, so we load the module. What's your point? What good is the damn thing, if the only people who can use it are ... Well, I suppose it'll still be good for them. Maybe. RMS has indicated a willingness to sue people distributing bipartite distributions, where the linking is delayed until installation to work around the letter of the GPL. Given his religious convictions, I can't see him *not*. Factor that into your decision. You want me personally to get him to agree that loading modules at boot time does not violate the GPL? Greg -- 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: [SUGGESTION] - JFS for FreeBSD
[Format recovered--see http://www.lemis.com/email/email-format.html] Long-short syndrome in first message. On Monday, 10 December 2001 at 14:01:53 -0800, Hiten Pandya wrote: hi all, this is a wild idea...suggestion... i wanted to ask if there were any _plans_ to port JFS (Journaled File System) to FreeBSD... as for JFS, it is developed by IBM for Linux and is licensed under GPL, so we could put this into src/gnu/ Well, JFS was developed by IBM for AIX. If you look at the header files, it is clearly derived from UFS. They later developed a completely new file system, JFS2, for OS/2, and later ported this version to Linux. It's also available for AIX, but the standard AIX file system is still the old JFS1. It is used on IBM MainFrames and Enterprise servers for high performance and maximum throughput... I don't think the zSeries (System/390) runs JFS. As I said above, the RS/6000 uses a different JFS file system. On Monday, 10 December 2001 at 17:39:35 -0500, Matthew Emmerton wrote: * Hiten Pandya [EMAIL PROTECTED] [011210 16:02] wrote: hi all, this is a wild idea...suggestion... i wanted to ask if there were any _plans_ to port JFS (Journaled File System) to FreeBSD... as for JFS, it is developed by IBM for Linux and is licensed under GPL, so we could put this into src/gnu/ It is used on IBM MainFrames and Enterprise servers for high performance and maximum throughput... I'm glad you took the time to read the marketting literature. The problem is that porting it is going to be a bit more complicated than just dumping it into src/gnu. Feel free to take a shot at porting it though, let us know when you're done. I'm gainfully employed by IBM (although not for FreeBSD pursuits), and have had this on my TODO list for a while. Well, I'm gainfully employed by IBM, both for FreeBSD and JFS. I've thought (and spoken) about this from time to time. It would be a lot of work. The licence issue is a real sticky point, especially since the GPL and BSD licences are like oil and water. Because of the GPL licence, JFS support can never become part of the GENERIC kernel, and any related support tools will have to exist as separate binaries (newfs.jfs, fsck.jfs), as is currently done with the EXT2FS filesystem. As others have pointed out, this is a detail. The real question is: will JFS2 buy anything? The only real way to find out is to try it. On Monday, 10 December 2001 at 17:47:11 -0500, Anthony Schneider wrote: I'm no expert on journaled filesystems, but isn't the freebsd softupdates option similar? No, at least not from a technical standpoint. From a user standpoint, they both try to make things faster and more reliable, but they do it in very different ways. perhaps there could be an upgrade to offer options SOFTERUPDATES as an equal-but-different alternative to jfs? And what would that do? Greg -- When replying to this message, please take care not to mutilate the original text. For more information, see http://www.lemis.com/email.html 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: [SUGGESTION] - JFS for FreeBSD
On Tuesday, 11 December 2001 at 10:56:17 +1030, Greg Lehey wrote: On Monday, 10 December 2001 at 17:39:35 -0500, Matthew Emmerton wrote: * Hiten Pandya [EMAIL PROTECTED] [011210 16:02] wrote: hi all, this is a wild idea...suggestion... i wanted to ask if there were any _plans_ to port JFS (Journaled File System) to FreeBSD... as for JFS, it is developed by IBM for Linux and is licensed under GPL, so we could put this into src/gnu/ It is used on IBM MainFrames and Enterprise servers for high performance and maximum throughput... I'm glad you took the time to read the marketting literature. The problem is that porting it is going to be a bit more complicated than just dumping it into src/gnu. Feel free to take a shot at porting it though, let us know when you're done. I'm gainfully employed by IBM (although not for FreeBSD pursuits), and have had this on my TODO list for a while. Well, I'm gainfully employed by IBM, both for FreeBSD and JFS. I've thought (and spoken) about this from time to time. It would be a lot of work. BTW, if anybody wants to do it anyway, let me know. I'm in a position to help with information, though possibly not with coding. Greg -- 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: [SUGGESTION] - JFS for FreeBSD
On Monday, 10 December 2001 at 22:45:22 -0800, Terry Lambert wrote: Hiten Pandya wrote: i wanted to ask if there were any _plans_ to port JFS (Journaled File System) to FreeBSD... Not unless you have plans. When I was an IBM employee, they would not change the license, and so it's impossible to ship a CDROM where it's the boot FS, or boxes on which it is the boot FS, and still have it be legal, because of the license conflicts. I fought this for about a year within IBM, before I gave up. Since then, it has become possible for the loader to load modules before booting the kernel. This means that, theoretically, it would be possible to have a JFS root file system. Given the strong opposition to the GPL in some factions of the FreeBSD project, I don't see this happening any time soon, especially since we still don't know if it will buy us anything. It is used on IBM MainFrames and Enterprise servers for high performance and maximum throughput... No, it's not. The Linux JFS is derived from the OS/2 JFS code, not the good AIX JFS code. That's correct, but note that AIX is moving to this code base too, so it's not as if it's second-rate. From what I've seen of the structures, JFS2 is *much* better than JFS1. I haven't compared performance. Greg -- 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: [SUGGESTION] - JFS for FreeBSD
On Monday, 10 December 2001 at 22:48:58 -0800, Terry Lambert wrote: Alfred Perlstein wrote: [ ... Hiten wants someone to GPLify FreeBSD ... ] I'm glad you took the time to read the marketting literature. The problem is that porting it is going to be a bit more complicated than just dumping it into src/gnu. Feel free to take a shot at porting it though, let us know when you're done. FS porting to FreeBSD is actually pretty trivial(*), though some transactioning changes to the FreeBSD VFS layer consumers (the system calls and NFS server code) would be necessary to make the journal roll-back function correctly, following a failure. (*) Trivial: meaning grunt work is required; not necessarily an indicator of the amount of work, only the intellectual effort required for the job Considering that the current UFS implementation didn't need to be ported, and people are still working on the details, I think that this is a highly misleading statement. Greg -- 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
Notwork solutions (was: who is postmaster?)
On Saturday, 1 December 2001 at 1:21:04 -0800, Julian Elischer wrote: On Fri, 30 Nov 2001, Peter Wemm wrote: Julian Elischer wrote: I've tried getting information about our (FreeBSD) mail system by mailing to postmaster but no-one answers.. so, who IS the postmaster at the moment? I have the .elischer.org domain set up at Netowrk solutions with a contact address of [EMAIL PROTECTED] however whenever I try change anything in the setup it sends an Austhorize this email to the registered email address ([EMAIL PROTECTED]). However they never turn up in my mailbox so I can't do anything (like change the contact email address :-) to maintian my domain. Is freebsd.org throwing away mail from network solutions? (are they blackhole'd?) Would you believe me if I told you that Network Solutions dont know how to configure the DNS on their systems? thanks.. That's quite amazing.. Yup. I had that problem too. I didn't hack to let them send email, but as a customer I did complain vociferously. Then I moved to Gandi. It really makes you wonder what kind of cowboys are running the Internet nowadays. Greg -- 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: UDMA33 and SiS5591 on FreeBSD 4.4-RELEASE
On Sunday, 2 December 2001 at 17:53:37 +1030, Richard Sharpe wrote: Greg Lehey wrote: On Saturday, 1 December 2001 at 13:05:53 +0100, Søren Schmidt wrote: It seems Zwane Mwaikambo wrote: Hi, I've got a box which boots up with UDMA33 but during the boot sequence gets write problems and ends up disabling it and i presume falling back to PIO4. I've tested the same box on Linux 2.4.2+ and have had no problems running it at UDMA33. Host: SiS 5591 (revision?) Disk: Seagate 3.2G ATA2 Ohhh, I need alot more info before I can tell whats going on.. I need at least the dmesg from a verbosely booted system and also a pciconf -l to tell what chips you have. Note that there are other chips out there which return the same PCI information but which appear to be capable of ATA 100. I recently gave a patch to Richard Sharpe (copied) which he says was able to get his SiS 5591 to run at ATA 100. I'm still waiting for feedback from him before forwarding it to you. I also have a machine with a SiS Attached is the patch I am using, which is based on what Greg gave me. It tries UDMA5 first, and steps down ... I'd really appreciate the dmesg output, in particular this line: + if (bootverbose) + printf (SiS 5513/5591, udmamode %d\n, udmamode); Hmm. I suppose you didn't do a verbose boot. Could you try it, please? Also, you said (elsewhere) you had some issues with the attached file. What were they? Greg -- 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: FreeBSD performing worse than Linux?
On Saturday, 1 December 2001 at 8:11:19 +1030, Richard Sharpe wrote: Matthew Dillon wrote: Well, this is embarassing. I can reproduce this completely running 4.4-stable (Nov 17th kernel) on two machines. With newreno turned on, a TCP NFS mount only gets 80K/sec. With newreno turned off on the transmit side, a TCP NFS mount gets 7MB/sec. The state of the delayed-ack sysctl is irrelevant. This is without running any nfsiod's (which would mask the degredation of the synchronous messaging). I have upgraded to 4.4-STABLE, and have hacked in some changes to ata-dma.c (provided by Greg Lehey, but I had to do it by hand) What did you have to do by hand? so my drive is now running at UDMA 100. Can you send me dmesg output? In particular, I had a printf output there to show what the BIOS had set. Background for other people: Richard has an IDE chip which claims to be a SiS 5591, which according to the data sheet can't do better than UDMA 33. When he runs Linux on the box, however, it claims to be running at UDMA 100, and this hack seems to have had the same effect. I have also ensured that disk write caching is on, which it seems to be by default in 4.4. Yes, I think this is correct. These changes have made a difference to the NetBench and dbench runs (improved them), but they have made no difference to the tbench runs, which only do network stuff. I'd like to see the new dbench results. The traffic in the tbench case is SMB taffic. Request/response, with a mixture of small requests and responses, and big request/small response or small request/big response, where big is 64K. I have switched off newreno, and it made no difference. I have switched off delayed_ack, and it reduced performance about 5 percent. I have made sure that SO_SNDBUF and SO_RCVBUF were set to 131072 (which seems to be the max), and it increased performance marginally (like about 2%), but consistently. Have you tried Matt Dillon's patch? I am still analysing the packet traces I have, but it seems to me that the crucial difference is Linux seems to delay longer before sending ACKs, and thus sends less ACKs. Since the ACK is piggybacked in the response (or the next request), it all works fine, and the reponse/request gets there sooner. However, I have not convinced myself that the saving of 20uS or so per request/response pair accounts for some 40+ Mb/s. As long as the ack traffic isn't saturating the link, and you're not running half-duplex, I can't see how that would be the problem. Greg -- 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: FreeBSD performing worse than Linux?
I think I made a mistake by not opening this immediately. Certainly I haven't seen any particularly animosity here so far, and Richard can defend himself, so: FreeBSD hackers, meet Richard Sharpe. Richard, meet the hackers. As I said, Richard's a member of the Samba team. He's also going to be working on FreeBSD in the foreseeable future, so his intentions here are completely honourable :-) He's sent me the report, but since I didn't say I would send it to the entire development team, I'll wait for his go-ahead (and the reply to a couple of questions) before sending it on. Greg On Wednesday, 28 November 2001 at 0:41:18 -0700, Nate Williams wrote: I've just been talking with a friend of mine from the Samba team. He's about to change jobs, and a lot of his work in future will involve FreeBSD. He's just been doing some performance testing, and while the numbers are pretty even (since he discovered soft updates :-), he's noticing some significant performance differences, particularly on the TCP/IP area. FWIW, I'm seeing this as well. However, this appears to be a new occurance, as we were using a FreeBSD 3.X system for our reference test platform. I recently updated it to FreeBSD 4.4-RELEASE, and I'm getting nothing but complaints about broken connections, poor performance, and very inconsistent results. They are now considering installing Linux on this box with the hope that they can get consistent results. (Unfortunately, FreeBSD 3.X is out because I convinced them that we needed to upgrade to 4.X due to security measures, so we can't go back.) Note, some of the performance issues were made better by disabling the TCP newreno implementation, but it's still poor and very inconsistent for hosts not on the local network, while the Linux box next to it gets much more consistent results. I know my lack of information isn't helping much, and that I've not done much to help debug the problem. However, all my attempts to track down what is causing this from a high-level (w/out digging into the code itself and analyzing tcpdump output) have come up empty. This is obviously something *somebody* (not me) should look in to. On Wednesday, 28 November 2001 at 0:51:11 -0700, Nate Williams wrote: On Wednesday, 28 November 2001 at 8:45:07 +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Nate Williams writes: Note, some of the performance issues were made better by disabling the TCP newreno implementation, but it's still poor and very inconsistent for hosts not on the local network, while the Linux box next to it gets much more consistent results. For what it's worth I have disabled newreno at my customer sites as well and felt and heard less bogosity since. It's actually pretty awful. However, even with the fix I merged back into RELENG_4, the performance with/without newreno is still *much* worse (in terms of consistantly giving the same results) than the code in FreeBSD 3.x. The interesting thing is that the application that's getting the most press is one of our field technicians downloading a file over anonymous ftp by hand, so it's not like we're generating tons of traffic, or alot of parallel connections. The connections hang, abort, and those that complete have numbers that are *all* over the map. However, when connected to a Linux box on the same network, none of these bad things occur. :( (And, we've verified the network is up by running ping in another window.) On Wednesday, 28 November 2001 at 18:22:10 +1030, Greg Lehey wrote: On Wednesday, 28 November 2001 at 1:56:14 -0700, Wes Peters wrote: On Wed, 28 Nov 2001 00:41:18 -0700 Nate Williams [EMAIL PROTECTED] wrote: FWIW, I'm seeing this as well. However, this appears to be a new occurance, as we were using a FreeBSD 3.X system for our reference test platform. I recently updated it to FreeBSD 4.4-RELEASE, and I'm getting nothing but complaints about broken connections, poor performance, and very inconsistent results. They are now considering installing Linux on this box with the hope that they can get consistent results. (Unfortunately, FreeBSD 3.X is out because I convinced them that we needed to upgrade to 4.X due to security measures, so we can't go back.) And they somehow think any variant of Linux is going to be better on this point? My recent experience with Linux would say otherwise, but that was on an Intel Architecture Labs variant that is somewhat out of date, too. Well, it ties in with Richard's experience. On Wednesday, 28 November 2001 at 0:56:02 -0700, Nate Williams wrote: FWIW, I'm seeing this as well. However, this appears to be a new occurance, as we were using a FreeBSD 3.X system for our reference test platform. I recently updated it to FreeBSD 4.4-RELEASE, and I'm getting nothing but complaints about broken connections, poor performance, and very inconsistent results. They are now considering installing Linux on this box
Re: FreeBSD performing worse than Linux?
On Wednesday, 28 November 2001 at 2:03:21 -0600, Alfred Perlstein wrote: * Greg Lehey [EMAIL PROTECTED] [011127 23:08] wrote: I've just been talking with a friend of mine from the Samba team. He's about to change jobs, and a lot of his work in future will involve FreeBSD. He's just been doing some performance testing, and while the numbers are pretty even (since he discovered soft updates :-), he's noticing some significant performance differences, particularly on the TCP/IP area. He is going to be sending me a copy of his preliminary report later today, and he doesn't mind sharing it. I'm a little concerned about the Them vs. Us attitude such a report could cause. He's not out to show that Linux is better than FreeBSD; on the contrary, he would be a lot happier if the results were in favour of FreeBSD, since otherwise he has to do something about it. I'd like a few of us to take a look at what he's done first, and either point out where he can tune the FreeBSD system, or how to find and eliminate the bottlenecks. Who's interested? I'm somewhat interested, it obviously depends on the level of detail and depth of this report, if it's as shallow as your and Nate's 'rumors' then I probably won't be able to help as I'll be too busy switching all my machines over to Linux rather than doing the legwork to get down to the bottom of this alleged performance problem. That's uncalled for. I said that I had more information coming in, as you can see above, and Nate did apologize for lack of information. We don't always have the time to do the research we want. I certainly don't. Which would have been more useful: say to Richard sorry, my plate's full, or I can't help you, but I'll try to find people who aren't too aggressive to help you. Nate has given some information. You can't blame him for not having the time to do the legwork. Greg -- 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: FreeBSD performing worse than Linux?
On Wednesday, 28 November 2001 at 2:22:40 -0600, Alfred Perlstein wrote: * Nate Williams [EMAIL PROTECTED] [011128 02:14] wrote: If you want me to shutup and go into a corner, it might make you feel better, but it certainly won't solve the real problem. I made it clear that my problem was not with the complaint itself. My problem with it was with the lack of technical backing or any real way for me to reproduce the problem. So no, I do not want you to shutup and go into a corner, I want you to get off your ass and gather us all up some useful information so that we can solve the problem. OK, we're agreed on that. So let's do it. Lastly, if these people are intent on running Linnex, they'll spread however much FUD that they need to and provide as little information as possible in order to effect the switch. That in itself is FUD. I've been working a lot with Linux users, and one thing I've consistently found is the large number of people who are really interested in using FreeBSD as an alternative. Here in South Australia we've got to the point where the local Linux user group recognizes FreeBSD as a viable alternative. Yes, there are fanatics on both sides, but we should try to ignore them, or convince them of the errors of their ways. Greg -- 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
FreeBSD performing worse than Linux?
I've just been talking with a friend of mine from the Samba team. He's about to change jobs, and a lot of his work in future will involve FreeBSD. He's just been doing some performance testing, and while the numbers are pretty even (since he discovered soft updates :-), he's noticing some significant performance differences, particularly on the TCP/IP area. He is going to be sending me a copy of his preliminary report later today, and he doesn't mind sharing it. I'm a little concerned about the Them vs. Us attitude such a report could cause. He's not out to show that Linux is better than FreeBSD; on the contrary, he would be a lot happier if the results were in favour of FreeBSD, since otherwise he has to do something about it. I'd like a few of us to take a look at what he's done first, and either point out where he can tune the FreeBSD system, or how to find and eliminate the bottlenecks. Who's interested? 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: FreeBSD performing worse than Linux?
On Wednesday, 28 November 2001 at 1:56:14 -0700, Wes Peters wrote: On Wed, 28 Nov 2001 00:41:18 -0700 Nate Williams [EMAIL PROTECTED] wrote: FWIW, I'm seeing this as well. However, this appears to be a new occurance, as we were using a FreeBSD 3.X system for our reference test platform. I recently updated it to FreeBSD 4.4-RELEASE, and I'm getting nothing but complaints about broken connections, poor performance, and very inconsistent results. They are now considering installing Linux on this box with the hope that they can get consistent results. (Unfortunately, FreeBSD 3.X is out because I convinced them that we needed to upgrade to 4.X due to security measures, so we can't go back.) And they somehow think any variant of Linux is going to be better on this point? My recent experience with Linux would say otherwise, but that was on an Intel Architecture Labs variant that is somewhat out of date, too. Well, it ties in with Richard's experience. Greg -- 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: HPT370 RAID or Vinum?
On Sunday, 11 November 2001 at 22:37:58 +0100, Paul van der Zwan wrote: In message [EMAIL PROTECTED], Mike Smith wrote: These cheap controllers don't have any algorithms at all to speak of; they're just ATA controllers with BIOS code that supposedly understands striping/mirroring. There is no algorithm to speak of involved with striping, and just a little more in mirroring in the error case, but anyways.. Unless you've fixed it, the error case handling in mirror mode is busted as well. The algorithms are in the 'ar' driver, which should really just be a vinum shim. Well, the way vinum is implemented that wont work unfortunately. There's no reason that 'ar' and Vinum couldn't be fixed to play together. Or at least, no technical reason. Indeed. It works. Well, currently there are some minor glitches. I just installed a vinum slice on /dev/ar0s1 and unless I do a 'vinum read /dev/ar0s1' vinum will not find the volumes. This causes the boot of my box ( -current btw) to fail at the mount of my filesystems. Is there a way to tell vinum to also look on /dev/ar* for its config?? This may be because ar doesn't have a devstat interface (my assumption). Currently Vinum looks in the devstat structures to find mass storage devices, but this will change when the root file system support gets rewritten (hopefully Real Soon Now). Greg -- 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: HPT370 RAID or Vinum?
On Sunday, 11 November 2001 at 9:33:56 +0100, Søren Schmidt wrote: It seems Mike Smith wrote: Agreed. I don't think the RAIDs will have the same parameters. Most of these cheap controllers have fairly simplistic algorithms. Note that I said guess, though. In my language, that means don't know for sure. I'd really like to see some objective benchmarks. Er. These cheap controllers don't have any algorithms at all to speak of; they're just ATA controllers with BIOS code that supposedly understands striping/mirroring. There is no algorithm to speak of involved with striping, and just a little more in mirroring in the error case, but anyways.. Well, there are questions of stripe size and whether you read entire stripes or just the part you want. The algorithms are in the 'ar' driver, which should really just be a vinum shim. Well, the way vinum is implemented that wont work unfortunately. Details? Greg -- 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: Vinum problem with JBOD on a 3ware?
On Tuesday, 30 October 2001 at 8:26:14 -0800, Jaye Mathisen wrote: I be stumped: newsfeed-inn# uname -a FreeBSD newsfeed-inn.meganews.com 4.4-STABLE FreeBSD 4.4-STABLE #0: Mon Oct 29 15:08:57 PST 2001 [EMAIL PROTECTED]:/n/FreeBSD/RELENG_4-2001-10-29/src/sys/compile/NEWSFEED-INN i386 Diskcontroller is a 3ware 7800, with 4 maxtor 20GB IDE's on it, which have all been scanned 1x with the maxblast software for a quick verification. newsfeed-inn# cat /root/vinum.config drive d1 device /dev/twed0d newsfeed-inn# vinum vinum - create -f /root/vinum.config 1: drive d1 device /dev/twed0d ** 1 Can't initialize drive d1: Operation not supported by device Currently Vinum has to know about each kind of disk device before it will use it. It doesn't know about twed. I'll send you a patch. Greg -- 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: I am desperate please help my hdd
On Saturday, 13 October 2001 at 19:08:24 -0400, Rob wrote: I am writing this mailing list in a desperate attempt to find out how to restore my hdd with out loosing all the data on it. Recently I added two additional hard drives to my freebsd 4.2 system. Once I booted up my system and dl'ed some things with wget a bunch of errors occurred resulting in kernel panic and then system halt. When I rebooted I get and error and cannot boot freebsd On Saturday, 13 October 2001 at 19:02:13 -0400, Rob wrote: I am writing this mailing list in a desperate attempt to find out how to restore my hdd with out loosing all the data on it. Recently I added two additional hard drives to my freebsd 4.2 system. Once I booted up my system and dl'ed some things with wget a bunch of errors occurred resulting in kernel panic and then system halt. When I rebooted I get and error and cannot boot freebsd Once is enough. -hackers is not for this sort of question. error: Verifying DMI Pool Data . int= err= efl=00010246 eip=1b2c eax=0002 ebx=0002 ecx=6564 edx= esi=00094cdc edi=22bf ebp=00094cbc esp=00094ca4 cs=002b ds=0033 es=0033 fs=0033 gs=0033 gs=0033 ss=0033 cs:eip=f7 35 98 24 00 00 89 c7-89 f9 0f af 0d 9c 24 00 ss:esp=00 00 00 00 e0 4c 09 00-dc 4c 09 00 bf 22 00 00 BTX halted This looks like a boot block problem. I can't see how it fits in with what you said you did. to try to fix this problem I installed a minimal install of fbsd on another hdd and ran fsck /dev/ad1a which said this: ** /dev/ad1a BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE /dev/ad1a: INCOMPLETE LABEL: type 4.2BSD fsize 0, frag 0, cpg 0, size 9809920 Did you do this while it was mounted? You shouldn't do that. You'll get bogus error messages because fsck goes straight to the disk and ignores buffer cache. If it's not mounted, then it looks like you have overwritten your primary superblock. There should be a backup one at offset 32. Try: # fsck -b 32 -n /dev/ad1a The -n will stop fsck from trying to change anything. This is important for badly mutilated file systems, since fsck is stupid enough to make things worse. Although it doesn't really help I can still df -h it; df /dev/ad1a prints: FilesystemSizeUsedAvail CapacityMounted on /dev/ad1a 4.5G1.5G2.7G36% fdisk /dev/ad1a prints: *Working on device /dev/ad1a * parameters extracted from in-core disklabel are: cylinders=621 heads=255 sectors/track=63 (16065 blks/cyl) parameters to be used for BIOS calclations are: cylinders=621 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: UNUSED The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 5 (24 meg), flag 80 (active) beg: cyl 0/ head 0/ sector 1; end:cyl 1023/ head 255/ sector 63 That's normal enough. Is the data on my hdd completely unrecoverable? We don't know yet. Is there anyway I could mount the partion? mount /dev/ad1a /blah (/blah is a directory) prints this: mount: /dev/ad1a on /blah: incorrect super block You can try mounting it read-only: # mount -o ro /dev/ad1a /mnt but probably you'll get the same error. On Monday, 15 October 2001 at 2:08:31 +0300, Giorgos Keramidas wrote: Rob [EMAIL PROTECTED] wrote: fsck /dev/ad1a which said this: You are probably looking in the wrong place for a partition table. Try this: # fdisk /dev/ad1 That is incorrect. That would look on a slice. We put file systems in partitions, such as /dev/ad1a. ** /dev/ad1a BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE /dev/ad1a: INCOMPLETE LABEL: type 4.2BSD fsize 0, frag 0, cpg 0, size 9809920 Are you using the disk in ``dangerously dedicated mode''? This has nothing to do with dedicated mode. The fdisk output above shows that he is using a Microsoft partition table. Otherwise your partition table of /dev/ad1 should show some slice, like /dev/ad1s1 and your BSD filesystems should have names like /dev/ad1s1a, /dev/ad1s1d, etc. No, /dev/ad1a is a compatibility partition and represents partition a of the first FreeBSD slice. What other disks are on your system? If this is your only disk, why is BSD on /dev/ad1 and not on /dev/ad0? Well, he did explain that he was adding disks. But you'll also find the system on /dev/ad1a if you have a Microsoft platform on ad0. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply. For more information, see http://www.lemis.com/questions.html See complete headers for address and phone numbers To Unsubscribe: send mail to
Re: setjmp/longjmp
On Wednesday, 3 October 2001 at 12:12:14 -0700, Julian Elischer wrote: I suppose it must have been Peter Penchev who wrote: On Wednesday, October 03, 2001 6:14 AM, Greg Lehey [EMAIL PROTECTED] wrote: On Tuesday, 2 October 2001 at 12:43:54 -0700, Julian Elischer wrote: On Tue, 2 Oct 2001, Peter Pentchev wrote: On Mon, Oct 01, 2001 at 10:56:24AM +0930, Greg Lehey wrote: [Format recovered--see http://www.lemis.com/email/email-format.html] On Friday, 28 September 2001 at 10:12:14 -0700, Julian Elischer wrote: On Fri, 28 Sep 2001, Gersh wrote: On Fri, 28 Sep 2001, Bernd Walter wrote: On Fri, Sep 28, 2001 at 07:03:51PM +0530, Anjali Kulkarni wrote: Does anyone know whether it is advisable or not to use setjmp/longjmp within kernel code? I could not see any setjmp/longjmp in kernel source code. Is there a good reason for this or can it be used? You need to look again, it's used in several places in the kernel. Look at sys/i386/i386/db_interface.c Yeah but it would probably be a pretty bad idea to use it without very careful thought. Especialy with the kernel becoming pre-emptable in the future.. Can you think of a scenario where it wouldn't work? Preemption doesn't tear stacks apart, right? How about a case of a longjmp() back from under an acquired lock/mutex? Like function A sets up a jump buffer, calls function B, B acquires a lock, B calls C, C longjmp()'s back to A; what happens to the lock? It would work if A were aware of B's lock and the possibility of a code path that would end up with it still being held; I presume that this is what Julian meant by 'very careful thought'. pretty much... That's wrong, of course, but I don't see what this has to do with preemptive kernels. This is the same incorrect usages as performing malloc() and then longjmp()ing over the free(). Right, that was my question too, doesent seem connected with pre-emptive kernels... basically it's just that pre-emtion just muddies the waters more.. Or statements which aren't backed up with examples? Greg -- 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: setjmp/longjmp
On Tuesday, 2 October 2001 at 12:43:54 -0700, Julian Elischer wrote: On Tue, 2 Oct 2001, Peter Pentchev wrote: On Mon, Oct 01, 2001 at 10:56:24AM +0930, Greg Lehey wrote: [Format recovered--see http://www.lemis.com/email/email-format.html] On Friday, 28 September 2001 at 10:12:14 -0700, Julian Elischer wrote: On Fri, 28 Sep 2001, Gersh wrote: On Fri, 28 Sep 2001, Bernd Walter wrote: On Fri, Sep 28, 2001 at 07:03:51PM +0530, Anjali Kulkarni wrote: Does anyone know whether it is advisable or not to use setjmp/longjmp within kernel code? I could not see any setjmp/longjmp in kernel source code. Is there a good reason for this or can it be used? You need to look again, it's used in several places in the kernel. Look at sys/i386/i386/db_interface.c Yeah but it would probably be a pretty bad idea to use it without very careful thought. Especialy with the kernel becoming pre-emptable in the future.. Can you think of a scenario where it wouldn't work? Preemption doesn't tear stacks apart, right? How about a case of a longjmp() back from under an acquired lock/mutex? Like function A sets up a jump buffer, calls function B, B acquires a lock, B calls C, C longjmp()'s back to A; what happens to the lock? It would work if A were aware of B's lock and the possibility of a code path that would end up with it still being held; I presume that this is what Julian meant by 'very careful thought'. pretty much... That's wrong, of course, but I don't see what this has to do with preemptive kernels. This is the same incorrect usages as performing malloc() and then longjmp()ing over the free(). Greg -- 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: setjmp/longjmp
[Format recovered--see http://www.lemis.com/email/email-format.html] On Friday, 28 September 2001 at 10:12:14 -0700, Julian Elischer wrote: On Fri, 28 Sep 2001, Gersh wrote: On Fri, 28 Sep 2001, Bernd Walter wrote: On Fri, Sep 28, 2001 at 07:03:51PM +0530, Anjali Kulkarni wrote: Does anyone know whether it is advisable or not to use setjmp/longjmp within kernel code? I could not see any setjmp/longjmp in kernel source code. Is there a good reason for this or can it be used? You need to look again, it's used in several places in the kernel. Look at sys/i386/i386/db_interface.c Yeah but it would probably be a pretty bad idea to use it without very careful thought. Especialy with the kernel becoming pre-emptable in the future.. Can you think of a scenario where it wouldn't work? Preemption doesn't tear stacks apart, right? Greg -- When replying to this message, please take care not to mutilate the original text. For more information, see http://www.lemis.com/email.html 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: VM: dynamic swap remapping (patch)
On Sunday, 30 September 2001 at 14:55:58 -0500, Alfred Perlstein wrote: * Jos Backus [EMAIL PROTECTED] [010930 14:35] wrote: On Sun, Sep 30, 2001 at 02:23:26PM -0500, Alfred Perlstein wrote: * Jos Backus [EMAIL PROTECTED] [010930 12:55] wrote: AIX has SIGDANGER. Anyone care to tell me how it works in AIX? If the interface is nice, cloning it would be kind of cool. I don't currently have access to an AIX system, but http://as400bks.rochester.ibm.com/doc_link/en_US/a_doc_lib/aixbman/admnconc/pag_space_under.htm has some (useful) info. It sure does! I think I'm going to make a proposal on -arch about this, to be perfectly honest, AIX has a good implementation, I haven't read it all yet, but it doesn't look like it gives the applications a notification when the danger is gone, we'll have to figure that out, or I'll have to read more into this. If it's any help, I have an AIX box here. It belongs to IBM, so I have to respect security issues, but I'll do what I can. Greg -- 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: VINUM PANIC ON -STABLE
On Sunday, 16 September 2001 at 20:04:46 -0700, [EMAIL PROTECTED] wrote: Hi Greg, On Mon, 17 Sep 2001 12:04:27 +0930, Greg Lehey wrote: Subdisk home.p0.s0: Size: 40822392320 bytes (38931 MB) State: up Plex home.p0 at offset 0 (0 B) Drive home1 (/dev/ad4s1h) at offset 135680 (132 kB) Subdisk home.p0.s1: Size: 39566177280 bytes (37733 MB) State: up Plex home.p0 at offset 285696 (279 kB) Drive home2 (/dev/ad6s1f) at offset 135680 (132 kB) These ones, though, are different. That's a bug in Vinum. You didn't say, but I assume that it was the newfs of home that caused the crash. It was newfs indeed. I had initially miscounted the size of the second partition and instead of repartitioning, decided to put 0 in the config file hoping that Vinum would choose the lowest common denominator. It should do. As I say, it's a bug. You should really repartition your physical drives (spindles) to have only one Vinum drive each. Then make sure that both subdisks are of the same size, and you shouldn't have any more problems. Yes, this doesn't fix the bug, but I'll work on that. Great, I'll do that. Do you have enough information to fix the bug? I think so. If not, I hope I have enough information to reproduce it. If anybody else listening wants to have a go, it's in the function update_plex_config in vinumconfig.c. I've taken a look, and there's no check there that the sizes are the same, though it does check that the subdisk sizes are a multiple of the stripe size. I presume the coredumps are of little use to you, because you already know what caused the crash, but please let me know if you want me to keep them. No, I should be able to reproduce it here. Thanks for the offer. Greg -- 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: VINUM PANIC ON -STABLE
[Format recovered--see http://www.lemis.com/email/email-format.html] On Saturday, 15 September 2001 at 18:39:20 -0700, [EMAIL PROTECTED] wrote: On Sun, 16 Sep 2001 09:38:20 +0930, Greg Lehey wrote: On Saturday, 15 September 2001 at 12:26:10 -0700, [EMAIL PROTECTED] wrote: 4) Supply the output of the vinum list command. 4 drives: D data1 State: up Device /dev/ad4s1g Avail: 0/10240 MB (0%) D home1 State: up Device /dev/ad4s1h Avail: 0/38931 MB (0%) D data2 State: up Device /dev/ad6s1e Avail: 0/10240 MB (0%) D home2 State: up Device /dev/ad6s1f Avail: 0/37733 MB (0%) 2 volumes: V data State: up Plexes: 1 Size: 19 GB V home State: up Plexes: 1 Size: 74 GB 2 plexes: P data.p0 S State: up Subdisks: 2 Size: 19 GB P home.p0 S State: up Subdisks: 2 Size: 74 GB 4 subdisks: S data.p0.s0State: up PO:0 B Size: 9 GB S data.p0.s1State: up PO: 279 kB Size: 9 GB S home.p0.s0State: up PO:0 B Size: 38 GB S home.p0.s1State: up PO: 279 kB Size: 36 GB 6) Supply an extract of the file /var/log/messages. Sep 12 14:06:10 depot login: ROOT LOGIN (root) ON ttyv0 Sep 12 14:07:29 depot login: ROOT LOGIN (root) ON ttyv1 Sep 13 01:58:14 depot /kernel: vinum: loaded Sep 13 01:58:15 depot /kernel: vinum: drive data1 is up Sep 13 01:58:15 depot /kernel: vinum: drive home1 is up Sep 13 01:58:15 depot /kernel: vinum: drive home2 is up Sep 13 01:58:15 depot /kernel: vinum: removing 499 blocks of partial stripe at the end of data.p0 Sep 13 01:58:15 depot /kernel: vinum: data.p0 must have equal sized subdisks Sep 13 01:58:15 depot /kernel: Correcting length of data.p0: was 20970756, is 20970757 I suspect that this is the problem. I've seen isolated cases where the stripe size didn't get fixed correctly, leaving holes in the volume. Could you send me the output of 'vinum l -v', please? And please don't wrap log output, it makes it a pain to read. Sep 14 10:58:46 wantadilla postfix/smtpd[17429]: reject: RCPT from ewey-rwcmta.excite.com[198.3.99.191]: 550 [EMAIL PROTECTED]: Sender address rejected: Mail rejected. See http://www.lemis.com/dontspam.html;; from=[EMAIL PROTECTED] to=[EMAIL PROTECTED] Do you understand now? I understand but not necessarily agree. I've never spammed anyone in my entire life. It's not my fault that some people abuse excite.com to send spam. Agreed. You're collateral damage. But I can't find that out until I hear about it. I've opened the server for you. Greg -- When replying to this message, please take care not to mutilate the original text. For more information, see http://www.lemis.com/email.html 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: HPT370 RAID or Vinum?
On Monday, 10 September 2001 at 10:11:28 -0700, [EMAIL PROTECTED] wrote: Hi there, I am trying to install FreeBSD on a (pseudo-) hardware ATA RAID volume which consists of two striped ATA disks connected to a Highpoint HPT370 controller.Pseudo- because FreeBSD detects the individual disks (ad4/ad6) as well as the striped volume (ar0). Besides the fact that ar0 isn't documented anywhere (except in /dev/MAKEDEV) and man 4 ar gives something completely irrelevant, which one is better to use: Highpoint built-in RAID (ar0), or ad4/ad6 striped with Vinum? I reckon if the RAID functions are implemented in HPT BIOS (in software), I'll be better off with Vinum. Ultimately, all RAID is software RAID. The issue is just how it's implemented. I'd guess that the HPT will give you far worse performance than Vinum, though I'd be very interested to see confirmation or denial of this guess. If you feel like benchmarking, contact me first. 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
mmap limits (was: need help)
On Wednesday, 1 August 2001 at 0:17:42 +0700, smail wrote: Hello freebsd-hackers, i need some help. my problem is about memory limit in mmap function. i can't mmap files infinitely, after some number of file mmaped in memory i've got an error, probably causing memory limit of 2 or 4 Gb. can you help me? my platform is FreeBSD 4.3/i386 [128Mb RAM, 4Gb swap]. You'll get more replies with an appropriate subject and some more details. Greg -- 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: Allocate a page at interrupt time
On Wednesday, 8 August 2001 at 0:27:23 -0700, Terry Lambert wrote: void wrote: Can you name one SMP OS implementation that uses an interrupt threads approach that doesn't hit a scaling wall at 4 (or fewer) CPUs, due to heavier weight thread context switch overhead? Solaris, if I remember my Vahalia book correctly (isn't that a favorite of yours?). As usual, IMO... Yes, I like the Vahalia book; I did technical review of it for Prentice Hall before its publication. Solaris hits the wall a little later, but it still hits the wall. Every SMP system experiences performance degradation at some point. The question is a matter of the extent. On Intel hardware, it has historically hit it at the same 4 CPUs where everyone else tends to hit it, for the same reasons; This is a very broad statement. You contradict it further down. as of Solaris 2.6, they have adopted the hybrid per CPU pool model recommended in Vahalia (Chapter 12). While I'm at it, I suppose I should recommend reading the definitive Solaris internals book, to date: Solaris Internals, Core Kernel Architecture Jim Mauro, Richard McDougall Prentice Hall ISBN: 0-13-022496-0 Yes, I have this book. It looks very good, but I haven't found time to read it. Solaris claims to scale to 64 processors while maintaining SMP, rather than real or virtual NUMA. It's been my own experience that this scaling claim is not entirely accurate, if what you are doing is a lot of kernel processing. I think that depends on how you interpret the claim. It can only mean that adding a 64th processor can still be of benefit. On the other hand, if you are running a lot of non-intersecting user space code (e.g. JVM's or CGI's), it's not as bad (and realized that FreeBSD is not that bad in the same situation, either: it's just not as common in practice as it is in theory). You're just describing a fact of life about UNIX SMP support. It should be noted that Solaris Interrupt threads are only used for interrupts of priority 10 and below: higher priority interrupts are _NOT_ handled by threads (interrupts at a priority level from 11 to 15). 10 is the clock interrupt. FreeBSD also has provision for not using interrupt threads for everything. It's clearly too early to decide which interrupts should be left as traditional interrupts, and we've done some shifting back and forth to get things to work. Note that the priority numbers are noise. In this statement, they're just a convenient way to distinguish between threaded and non-threaded interrupts. It should also be noted that Solaris maintains a per processor pool of interrupt threads for each of the lower priority interrupts, with a global thread that is used for handling of the clock interrupt. This is _very_ different than taking an interrupt thread, and rescheduling it on an arbitrary CPU, and as others have pointed out, the hardware used to do the scheduling is very different. I think somebody else has pointed out that we're very conscious of CPU affinity. In the 32 processor Sequent boxes, the actual system bus was different, and directly supported message passing. Was this better or worse? There is also specific hardware support for handling interrupts via threads, which is really not applicable to x86 or even the Alpha architectures on which FreeBSD currently runs, nor to the IA64 architecture (port in progress). In particular, there is a single system wide table, introduced with the UltraSPARC, that doesn't need to be locked to support interrupt handling. Also, the Sun system is still an IPL system, using level based blocking, rather than masking, and these threads can find themselves blocks on a mutex or condition variable for a relatively long time; if this happens, it resumes the previous thread _but does not drop its IPL below that of the suspended thread_, which is basically the Djikstra Banker's Algorithm method of avoiding priority inversion on interrupts (i.e. ugly). So you're saying we're doing it better? Finally, the Sun system borrows the context of the interrupted process (thread) for interrupt handling (the LWP). This is very similar to the technique employed with kernel vs. user space thread associations within the Windows kernels (this was one of the steps I was referring to when I said that NT had dealt with a number of scaling issues before it needed to, so that they would not turn into problems on 8-way and higher systems). This is also the method we're planning to use, as I'm sure you're aware from previous messages on the -smp list. Personally, I think that the Sun system is extremely succeptible to receiver livelock (Network interrupts are at 7, and disk interrupts are at 5, which means that so long as you are getting pounded with network interrupts for e.g. NFS read or write requests, you're not going to service the disk interrupts that will let you dispose of the traffic, nor
Re: Allocate a page at interrupt time
On Tuesday, 7 August 2001 at 1:58:21 -0700, Terry Lambert wrote: Bosko Milekic wrote: I keep wondering about the sagicity of running interrupts in threads... it still seems like an incredibly bad idea to me. I guess my major problem with this is that by running in threads, it's made it nearly impossibly to avoid receiver livelock situations, using any of the classical techniques (e.g. Mogul's work, etc.). References to published works? Just do an NCSTRL search on receiver livelock; you will get over 90 papers... http://ncstrl.mit.edu/ See also the list of participating institutions: http://ncstrl.mit.edu/Dienst/UI/2.0/ListPublishers It won't be that hard to find... Mogul has only published 92 papers. 8-) So much data, in fact, that you could hide anything behind it. Would you like to be more specific? It also has the unfortunate property of locking us into virtual wire mode, when in fact Microsoft demonstrated that wiring down interrupts to particular CPUs was good practice, in terms of assuring best performance. Specifically, running in virtual Can you point us at any concrete information that shows this? Specifically, without being Microsoft biased (as is most data published by Microsoft)? -- i.e. preferably third-party performance testing that attributes wiring down of interrupts to particular CPUs as _the_ performance advantage. FreeBSD was tested, along with Linux and NT, by Ziff Davis Labs, in Foster city, with the participation of Jordan Hubbard and Mike Smith. You can ask either of them for the results of the test; only the Linux and NT numbers were actually released. This was done to provide a non-biased baseline, in reaction to the Mindcraft benchmarks, where Linux showed so poorly. They ran quad ethernet cards, with quad CPUs; the NT drivers wired the cards down to seperate INT A/B/C/D interrupts, one per CPU. You carefully neglect to point out that this was the old SMP implementation. I think this completely invalidates any point you may have been trying to make. wire mode means that all your CPUs get hit with the interrupt, whereas running with the interrupt bound to a particular CPU reduces the overall overhead. Even what we have today, with Obviously. I mention it because this is the direction FreeBSD appears to be moving in. Right now, Intel is shipping with seperate PCI busses; there is one motherboard from their serverworks division that has 16 seperate PCI busses -- which means that you can do simultaneous gigabit card DMA to and from memory, without running into bus contention, so long as the memory is logically seperate. NT can use this hardware to its full potential; FreeBSD as it exists, can not, and FreeBSD as it appears to be heading today (interrupt threads, etc.) seems to be in the same boat as Linux, et. al.. PCI-X will only make things worse (8.4 gigabit, burst rate). What do interrupt threads have to do with this? Terry, we've done a lot of thinking about performance implications over the last 2 years, including addressing all of the points that you appear to raise. A lot of it is in the archives. It's quite possible that we've missed something important that you haven't. But if that's the case, we'd like you to state it. All I see is you coming in, waving your hands and shouting generalities which don't really help much. The fact that people are still listening is very much an indication of the hope that you might come up with something useful. But pointing to 92 papers and saying it's in there [somewhere] isn't very helpful. Greg -- 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
Failed hack attempt (was: your mail)
On Sunday, 15 July 2001 at 16:51:51 -0400, [EMAIL PROTECTED] wrote: am a kernel newbie. i tried adding code to the kernel and compiled it and installed . when i tried rebooting my new image the kernel panics with a fatal trap 12: page fault ( for which i know the reason). How do i boot the system now. how can i revert back to an earlier image? or how can i do it from a floppy? As a kernel newbie, you should get used to this kind of problem. Plan ahead. If you *do* run into trouble, and you want help, you need to give more information. Basically, though, you need to use kernel.old, which is either a file in / or a directory in /boot. You should also apply the same rules described in http://echunga.lemis.com/questions.html, including a descriptive subject. Greg -- 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: Some questions about kernel programming
On Thursday, 12 July 2001 at 6:58:09 -0500, [EMAIL PROTECTED] wrote:
Dear Friends
I have some questions about kernel programming:
You'd be better off sending mail like this to -hackers. I've followed
up there.
1. Why I can call some system calls functions into the kernel but
another not?, for example: I can call printf(), but I can't call
socket().
You can't call system calls from the kernel. printf() is a library
call in userland; there's a different, but similar printf() in the
kernel.
2. Into kernel I can call the socket low level functions
that this system calls invoke sosocket(), soconnect(), etc.
but, How I do replace the send() system call? Perhaps, Can I call
write() into kernel with same parameters?
For example :
/* res = send(skt, buf, buflen, 0); */
res = write (skt, buf, buflen);
write() doesn't exist in the kernel. The simple answer is you're
going to have to read what the send() syscall does and emulate it.
First, though, you need to answer the question why do I want to do
this in the kernel?
3. How I can copy a pointer string ( character array ) from user space to
kernel space using copyin() without the following problem (I can't
pass the length the explicitly from user land):
structMySystemCall_args {
char * address;
};
int MySystemCall( p,uap)
struct proc *p;
register struct MySystemCall_args *uap;
{
char *the_address;
printf( --- uap-address : %s\n, uap-address );
printf( --- (strlen (uap-address) * sizeof(char)) : %d \n,
(strlen (uap-address) * sizeof(char)) );
copyin(uap-address, the_address, (strlen (uap-address) * sizeof(char))
);
printf(the_address: %s \n, the_address );
printf(strlen (the_address): %d \n, strlen (the_address) );
When this code run in mode kernel:
--- uap-address : 127.0.0.1
--- (strlen (uap-address) * sizeof(char)) : 9
the_address : 127.0.0.1\M-\M-Y\M-GX\M-p+\M-@@\M-_\M-*\M-@
strlen (the_address): 20
This crash the kernel later...
You've forgotten the terminating \0. Add one to the length.
Greg
--
When replying to this message, please copy the original recipients.
If you don't, I may ignore the reply.
For more information, see http://www.lemis.com/questions.html
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: Re. The Foundation [was Re: FreeBSD Mall now BSDCentral]
On Sunday, 8 July 2001 at 15:47:18 -0600, Justin T. Gibbs wrote: Julian Stacey wrote: The sooner BOD appoint a handfull of non-execs, some nominated by core, the sooner it'll be easy to encourage Wind River to donate the trademark, before who knows what might happen at, to, or within Wind River ? The Foundation has yet to approach Wind River about the Trademark, so I cannot speculate on their disposition. What are your plans to change this situation? Greg -- 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: Anyone see todays Wall Street Journal article: Microsoft Using Free Software (or something to that effect)
[Format recovered--see http://www.lemis.com/email/email-format.html] Your MUA is a known text mutilator. You'd be better off getting a UNIX-based MUA: X-Mailer: Microsoft Outlook, Build 10.0.2616 On Wednesday, 20 June 2001 at 11:16:18 +0200, Jeroen Massar wrote: Jordan Hubbard [EMAIL PROTECTED] wrote: That's the BSD license for ya. There needs to be a license that says something to the effect of Anyone can use/buy/sell/modify/distribute this software with or without source code except Microsoft. Why? I'd personally be happy if Microsoft software was made a lot easier to use by incorporating BSD stuff. Imagine, a Windows 2000 firewall that didn't suck rocks, or DHCP renegotiation that didn't drop all my active connections by default when my modem hung up unexpectedly... It would be nice! Heheh. just looks like that Wallstreet journal thingy... complaining without even looking into it and thus stating loose unfounded facts, making you look very silly IMHO. It does? The article was written in cooperation with the FreeBSD project, and I think it was very well done. Perhaps you have some details you're withholding. I don't know what you define by ease of use, but that's probably personal and depends on what you want to use something for and not to forget how to use it :) OK, try replying to this message with your broken MUA and *fix* *up* all the breakage it causes. People don't do it because it's too difficult. I did it with my setup because I can't read it otherwise, and it's not too difficult. Which is easy to use? You might like to type a 'netsh.exe' to come into the Net Shell with all kinds of nice commands, you'll prolly like it :) I strongly doubt it. For your unexpected hang ups: Q239924 - How to Disable Media Sense for TCP/IP in Windows 2000 http://support.microsoft.com/support/kb/articles/Q239/9/24.ASP Description: This parameter controls DHCP Media Sense behavior. If you set this value data to 1, DHCP, and even non-DHCP, clients ignore Media Sense events from the interface. By default, Media Sense events trigger the DHCP client to take an action, such as attempting to obtain a lease (when a connect event occurs), or invalidating the interface and routes (when a disconnect event occurs). Which will fix your problems... You should really start using MSDN (or google which will also find it) instead of complaining without doing the proper research... In the unix/bsd/* world they call that RTFM - nicely said: Read The Faq and Manual, oh and don't forget to understand it either... Well, no, what Jordan was referring to was a bug, not a feature. And we don't need MSDN. We don't need Microsoft. On another note... something I already mailed in the former discussions: Port from UNIX to Win32: http://msdn.microsoft.com/library/devprods/vs6/visualc/vccore/_core_port _from_unix_to_win32.htm Your MUA broke the URL. Microsoft broke the page. It comes out blank on my browser. Maybe it's optimized to use Microsoft-only browsers. And for the rest using BSD sockets is quite easy one only needs to open the winsock.dll What will you find inside? and as it's using the BSD API it's quite easy to port it and winsock also allows ease of use with IPX, XNS, DECnet and others... Native NT/Win32 apps are usually written with the use of Events (WSAEventSelect() etc...) but that's a completely different subject, altough it also shows a bit of the part of the internal workings of the stack as they surely won't do a select() on filedescripts, though it looks the same it ain't :) I'm not sure what you're referring to. Recall that people here don't use Microsoft. The only thing people are really slamming Microsoft here is being hypocritical. Actually using BSD code is an action I support for any value of the licensee string. :) Microsoft Windows BSD naah... though you could make a BSD subsystem and plug that straight into NT... But that's what they have the POSIX subsystem for and not to forget Interix (http://www.microsoft.com/WINDOWS2000/interix/). You're missing the point. Hopes that clears some of the mess up for you. Not really. You seem to have completely missed the point, and I had to clean up your mess for you. Greg -- When replying to this message, please take care not to mutilate the original text. For more information, see http://www.lemis.com/email.html 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
Writing device drivers (was: help me please)
On Wednesday, 9 May 2001 at 10:40:50 +0530, Jayesh Krishna wrote: Hi guys... I am comfortable with Linux Device Drivers. Presently I am trying to write some pseudo-drivers in FreeBSD(4.2-Release). I tried out make_pseudo_driver.sh in the /usr/share/examples/drivers but it does not work :-( I also went through the FreeBSD Device Driver Writer's Guide by Eric L. Hernes but it seems to be outdated :-( Please someone point me out to some docs regarding writing device drivers in FreeBSD UTSL. Take a look at a similar driver and get to understand it. I'm afraid that this is an area which is woefully undocumented. You'll also get more replies if you put a useful text on the Subject: line. 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: vinum on 2 ide drives?
[redirected to -questions] On Wednesday, 9 May 2001 at 19:51:05 -0700, Dan Phoenix wrote: These 2 are from running it on each on the ide drives without vinum. [root@gorbag /mnt1]# dd if=/dev/zero of=bigfile bs=16384k count=1000 1000+0 records in 1000+0 records out 16777216000 bytes transferred in 799.865832 secs (20975038 bytes/sec) [root@gorbag /mnt2]# dd if=/dev/zero of=bigfile bs=16384k count=1000 1000+0 records in 1000+0 records out 16777216000 bytes transferred in 796.395885 secs (21066427 bytes/sec) [root@gorbag /mnt2]# This is from running it on both drives striped with vinum. [root@gorbag /backup]# dd if=/dev/zero of=bigfile bs=16384k count=1000 1000+0 records in 1000+0 records out 16777216000 bytes transferred in 1365.405607 secs (12287350 bytes/sec) [root@gorbag /backup]# seems to be quite abit slower.. Indeed. That's puzzling. now i was running systat -vm 1 while writing to the striped vinum drive and did see both of them getting hit equally. IN this case prob at around 99% IO on both of them half the time. [root@gorbag dphoenix]# cat /etc/vinum.conf drive ibm1 device /dev/ad1s1e drive ibm2 device /dev/ad2s1e volume stripe plex org striped 512s sd length 58643m drive ibm1 sd length 58643m drive ibm2 [root@gorbag dphoenix]# You shouldn't be using power-of-2 stripes. But that's not what's causing your problem.s ad1: 58644MB IBM-DTLA-307060 [119150/16/63] at ata0-slave UDMA33 ad2: 58644MB IBM-DTLA-307060 [119150/16/63] at ata1-master UDMA33 Nice drives. They should be much faster than that on dd, but you were going via the file system. Any suggestions to get some speed here? Or should i just go back to single ide drives split up again? I'd like to understand what's going on here first. This isn't typical behaviour. Since you seem to not have anything useful on the drives, could you repeat with rawio (/usr/ports/benchmarks/rawio)? We can also take this offline. Greg -- For more information, see http://www.lemis.com/questions.html 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: fd driver hacking to recover data
On Wednesday, 9 May 2001 at 22:04:34 -0700, Brian W. Buchanan wrote: Any fdc driver gurus in the house? I have a bunch of old floppy disks with some text files I'd like to recover. Many of them have errors and are unreadable past a certain point in the disk. Others I can't read from at all. The ones I can't read, period, are all 1.44MB-size floppies. I've tried dd'ing from /dev/fd0c, /dev/fd0.1440, etc., but exits with Input/Output Error before copying anything. The kernel prints: fd0c: hard error reading fsbn 0 of 0-31 (ST0 40abnrml ST1 1no_am ST2 0 cyl 0 hd 0 sec 1) I've been more successful reading 720K floppies from /dev/fd0.720, but many of them have errors that stop dd in its tracks, yielding another Input/Output error. The kernel prints: fd0c: hard error reading fsbn 1503 of 1488-1503 (ST0 44abnrml,top_head ST1 20bad_crc ST2 20bad_crc cyl 41 hd 1 sec 10) Since the files on the disks are just text, all I want to do is to be able to extract as many of the bits on the disk as possible, even if some of the bits are wrong, and then run strings over it and sort out the content. I've looked at the floppy driver source and it seems to be incredibly low-level, i.e. it turns the drive motor on and off, even. Can someone familiar with the driver give me some pointers as to what I'd have to modify to let it 1) read those 1.44MB disks, and 2) tolerate data errors? One possibility that I've used in the past is to use a 'read track' command. This was back in the days of 8 floppies, but I think the controllers still understand it. Basically the command starts at the index mark and transfers data with no kind of interpretation until the next index mark. It's up to the program to then find the start of each sector and extract the data. If you're up to this kind of hack, I can check for more details. 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: Optimal setup for large raid?
On Friday, 4 May 2001 at 12:58:58 -0400, Brad L. Chisholm wrote: I sent this to -questions a few days ago, but never received any response, so I thought I'd try here. My apologies if you've seen this more than once. I'm also interested in what might be appropriate filesystem settings (newfs) for a large volume like this which will contain relatively few, large files. - We are planning to create a large software raid volume, and I am interested in input about what might make the best configuration. We have 52 identical 9Gb drives (Seagate ST19171W) spread across 4 SCSI controllers (Adaptec AHA 2944UW), with 13 drives per controller. We want fault-tolerance, but cannot afford to waste 50% of our space for a mirrored (raid1) configuration. Thus, we are considering some sort of raid5 setup using vinum (possibly in combination with ccd). I can't see any advantage in using ccd here. It doesn't do RAID-5 itself, and Vinum does everything that ccd does. We are running FreeBSD 4.3-RELEASE, on a 550Mz P3 with 384Mb of memory. Possible configurations: Configuration #1: A single raid5 vinum volume consisting of all 52 drives. Questions: A) Is there a performance penalty for this many drives in a raid5 array? Not in normal operation. In degraded operation, where one drive is down, you have to read from *all* the drives to reconstruct a block on the dead drive. On the other hand, this would happen less often (every 51 accesses), so maybe it wouldn't be such a hit after all. In addition, you'd have a greater chance of a drive failing, and also a greater chance of two drives failing (which is unrecoverable). B) Should the plex be configured with sequential drives on different controllers? (i.e. if drives 1-13 are on controller 1, 14-27 on controller 2, 27-39 on controller 3, and 40-52 on controller 4, should the drive ordering be: 1,14,27,40,2,15,28,41,... or 1,2,3,4,5,6,7,8,... Good question. I suppose the hopping would give marginally better performance for single accesses, and since your files are big, this might be a better way to go. Configuration #2: Multiple raid5 vinum volumes (perhaps 1 per controller), combined into a single volume by striping the raid5 volumes. (Basically a raid50 setup.) Questions: A) Is this possible with vinum? No. From the documentation, it didn't appear to be, so we were considering using 'ccd' to stripe the raid5 volumes together. Ah, that was the reason. I still don't think this is a good idea. B) Would this perform better, worse, or about the same as #1? Under normal circumstances there shouldn't be any difference. Any other configurations that might prove superior? If you really need a single volume of that size, you're probably better off with scenario #1. The final volume will be used as an online backup area, and will contain a relatively few, large tar files. Write performance will likely be more important that read, although I realize using raid5 will impact write performance. To put it more clearly: write performance on RAID-5 is terrible, about 25% of read performance. Any suggestions on what might be the best stripe size to use? Not a power of 2, between 256 and 512 kB. 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
The future of multiprocessors (was: SMP in 2.4 (fwd))
On Wednesday, 18 April 2001 at 23:17:06 -0300, Rik van Riel wrote: On Wed, 18 Apr 2001, Dennis wrote: You think Intel isn't going to market dual/quad ia64 machines? Yes, but who'll need them? If nobody needed them, what would be the point in SELLING them ? That's never been an argument for a good salesperson. Think of selling refrigerators to Eskimos, or the small farmer with one cow who bought a milking machine and sold his cow to pay for it. I know you don't trust our technical instinct, but you might at least consider the business instinct of companies like Intel, IBM or Unisys (who all sell big SMP systems). Besides, there are LOTS of people who need tomorrow's performance yesterday. There will always be a big market for overpowered, overpriced SMP systems... And, of course, a bigger market for high-powered, reasonably priced MP systems. Note that it's cheaper to buy an SMP Intel MB with two 750 MHz processors than it is to buy one with a 1.5 GHz processor. And as for the "but you can wait 2 years until UP is faster than today's SMP" doesn't quite work for eg. investment banking and stock funds. More computing power means better calculations, which means more money. And for folks like them, computing power is not measured in FLOPS, but in ACRES. And when you're talking 3 acres of computing power, you'd better have some decend density (ie. SMP in 2U rackmounted boxes, or something similarly suitable). More to the point, the processors of the not-too-distant future will have multiple processors on the single die. Multiprocessors are here to stay. 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: A message to freebsd-hackers@FreeBSD.ORG
On Saturday, 31 March 2001 at 11:15:37 -0800, Jeremiah Gowdy wrote: Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] There's no need to copy the spammer. Did the message bounce, BTW? Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 8EA6A2E8167; Sat, 31 Mar 2001 11:06:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Weird. If you're going to quote the headers, quote them from the origin (bottom): Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 8EA6A2E8167; Sat, 31 Mar 2001 11:06:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: by hub.freebsd.org (bulk_mailer v1.12); Sat, 31 Mar 2001 11:06:12 -0800 Delivered-To: [EMAIL PROTECTED] Received: from mail.netaddress.com (jester.ddg.com [216.30.58.65]) by hub.freebsd.org (Postfix) with ESMTP id E883637B71C for [EMAIL PROTECTED]; Sat, 31 Mar 2001 11:06:04 -0800 (PST) (envelope-from [EMAIL PROTECTED]) Received: (from root@localhost) by mail.netaddress.com (8.9.3/8.9.3) id NAA02607; Sat, 31 Mar 2001 13:06:03 -0600 This message appears to originate from jester.ddg.com. hub received it, put it through majordomo and sent it out again. That's the header you quoted. 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: Vinum stripe size (was: tuning a VERY heavily (30.0) loaded server)
On Tuesday, 27 March 2001 at 0:05:03 -0800, Alfred Perlstein wrote: * Greg Lehey [EMAIL PROTECTED] [010326 23:47] wrote: On Tuesday, 20 March 2001 at 11:11:44 -0600, Michael C . Wu wrote: [Lengthy email, bear with me please, it is quite interesting. This box averages 30.0 load with no problems.] snip Average file size is about 4K. /home/bbsusers* is on a vinum stripe'd volume with 3 Ultra160 9G 1RPM drives on sym0 at stripe size 256K, Greg: I know this should be a prime number, No, there's no requirement for it to be a prime number. The only problem is that with 32 MB cylinder groups and a power of two stripe size and subdisk count, you end up with all the superblocks on one subdisk, which is a performance issue. Choose the stripe size so that the superblocks are roughly evenly distributed. can we safely use 150K stripe sizes? Safely, yes. But as somebody else has observed, you are probably disk I/O bound. Reducing the stripe size will tend to increase the disk load, though probably not very much if your files are all 4 kB. I'd go for something like 273 kB stripes. Do you think it'd be worth it to have vinum carp about what may be a non optimal stripe size? "Warning N is probably a bad idea for a stripe size, see docs" Only if it can recognize the fact correctly. 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: Vinum stripe size (was: tuning a VERY heavily (30.0) loaded server)
On Tuesday, 27 March 2001 at 9:39:36 +0100, Brian Somers wrote: On Tuesday, 20 March 2001 at 11:11:44 -0600, Michael C . Wu wrote: [Lengthy email, bear with me please, it is quite interesting. This box averages 30.0 load with no problems.] snip Average file size is about 4K. /home/bbsusers* is on a vinum stripe'd volume with 3 Ultra160 9G 1RPM drives on sym0 at stripe size 256K, Greg: I know this should be a prime number, No, there's no requirement for it to be a prime number. The only problem is that with 32 MB cylinder groups and a power of two stripe size and subdisk count, you end up with all the superblocks on one subdisk, which is a performance issue. Choose the stripe size so that the superblocks are roughly evenly distributed. A performance issue ? Surely you've misspelt ``reliability'' ? I don't see a reliability issue here. 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: Vinum stripe size (was: tuning a VERY heavily (30.0) loaded server)
On Tuesday, 27 March 2001 at 17:59:23 -0500, Brandon Gale wrote: Do you think it'd be worth it to have vinum carp about what may be a non optimal stripe size? "Warning N is probably a bad idea for a stripe size, see docs" Only if it can recognize the fact correctly. How about even having vinum recommend something? I'm open to code suggestions. The problem is that by the time you create it, it's too late. 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: Vinum stripe size (was: tuning a VERY heavily (30.0) loaded server)
On Tuesday, 27 March 2001 at 15:15:17 -0800, David O'Brien wrote: On Tue, Mar 27, 2001 at 05:16:53PM +0930, Greg Lehey wrote: No, there's no requirement for it to be a prime number. The only problem is that with 32 MB cylinder groups and a power of two stripe size and subdisk count, you end up with all the superblocks on one subdisk, The change I made to newfs to make "-c 22" the default, removes this power-of-two issue. Correct? It certainly changes it. 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: Vinum stripe size (was: tuning a VERY heavily (30.0) loaded server)
On Tuesday, 27 March 2001 at 16:38:33 -0800, Alfred Perlstein wrote: * Greg Lehey [EMAIL PROTECTED] [010327 16:21] wrote: On Tuesday, 27 March 2001 at 17:59:23 -0500, Brandon Gale wrote: Do you think it'd be worth it to have vinum carp about what may be a non optimal stripe size? "Warning N is probably a bad idea for a stripe size, see docs" Only if it can recognize the fact correctly. How about even having vinum recommend something? I'm open to code suggestions. The problem is that by the time you create it, it's too late. That's not true. For a certain definition of "too late", maybe not. By the time you've newfs'd it, stored data on it and deployed it into production it's too late. It's certainly later then. Right after you make the volume is a good time to print out a little banner telling them to check the docs, something like: "WARNING: selecting a stripe size can be tricky, you really should see the vinum(8) manpage specifically the section about FOO for suggestions for optimal stripe sizes." Yes, but then you've already selected your stripe size. About the best I can think of would be a utility function which calculates the stripe size based on the number of subdisks, the total size and the cylinder group size. You could then do something like plex org striped without the stripe size, and let vinum(8) decide the stripe size for you. As I said, code submissions welcome :-) 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: Vinum stripe size (was: tuning a VERY heavily (30.0) loaded server)
On Wednesday, 28 March 2001 at 1:40:27 +0100, Brian Somers wrote: On Tuesday, 27 March 2001 at 9:39:36 +0100, Brian Somers wrote: On Tuesday, 20 March 2001 at 11:11:44 -0600, Michael C . Wu wrote: [Lengthy email, bear with me please, it is quite interesting. This box averages 30.0 load with no problems.] snip Average file size is about 4K. /home/bbsusers* is on a vinum stripe'd volume with 3 Ultra160 9G 1RPM drives on sym0 at stripe size 256K, Greg: I know this should be a prime number, No, there's no requirement for it to be a prime number. The only problem is that with 32 MB cylinder groups and a power of two stripe size and subdisk count, you end up with all the superblocks on one subdisk, which is a performance issue. Choose the stripe size so that the superblocks are roughly evenly distributed. A performance issue ? Surely you've misspelt ``reliability'' ? I don't see a reliability issue here. I believe the only issue with having all your superblocks on one disk is a reliability thing - if you lose the disk you lose your superblock(s). Ah. Lose part of your file system and you lose your file system. Vinum has other ways of making up for that problem. Surely the only performance problem would be that of locality - if you use the partition a bit, that ``problem'' should go away though. No, under normal circumstances all metadata updates would go to the same disk, since they're just behind the superblock. 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: tuning a VERY heavily (30.0) loaded server
On Tuesday, 20 March 2001 at 11:04:16 -0800, Matt Dillon wrote: SWAP is never touched. :) last pid: 23395; load averages: 2.08, 2.92, 3.60up 0+01:29:58 02:03:27 1529 processes:24 running, 1505 sleeping CPU states: 40.5% user, 0.0% nice, 46.4% system, 1.1% interrupt, 12.0% idle Mem: 705M Active, 1369M Inact, 332M Wired, 99M Cache, 265M Buf, 7504K Free Swap: 512M Total, 512M Free A couple other people have mentioned that this is your swap load when the machine's quiet. MFS can exhaust your swap quickly, and if you scale these load numbers up by a factor of 10, I think you're going to touch swap. (Even here you're already down to 7M free mem.) That is almost certainly what is occuring. Since swap is otherwise not being used much, I'm going to retract my '3G of swap' recommendation (though if you ever repartition your disks I would still do it). You don't need 3G of swap, the 512M is fine as long as you scrap MFS. One of the reasons this question came up is because dumps weren't enabled. If they had been, we would have seen the problem. That's why I'd recommend at least as much swap as memory, even if it doesn't get touched. 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
Vinum stripe size (was: tuning a VERY heavily (30.0) loaded server)
On Tuesday, 20 March 2001 at 11:11:44 -0600, Michael C . Wu wrote: [Lengthy email, bear with me please, it is quite interesting. This box averages 30.0 load with no problems.] snip Average file size is about 4K. /home/bbsusers* is on a vinum stripe'd volume with 3 Ultra160 9G 1RPM drives on sym0 at stripe size 256K, Greg: I know this should be a prime number, No, there's no requirement for it to be a prime number. The only problem is that with 32 MB cylinder groups and a power of two stripe size and subdisk count, you end up with all the superblocks on one subdisk, which is a performance issue. Choose the stripe size so that the superblocks are roughly evenly distributed. can we safely use 150K stripe sizes? Safely, yes. But as somebody else has observed, you are probably disk I/O bound. Reducing the stripe size will tend to increase the disk load, though probably not very much if your files are all 4 kB. I'd go for something like 273 kB stripes. 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: Missing support in FreeBSD for large file sizes?
On Monday, 5 March 2001 at 17:23:53 -0700, Warner Losh wrote: In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes: What I can't understand is the reference to missing support for large file sizes - as far as I know, that's one of FreeBSD's strengths! Anybody care to guess what they mean here? It is crap. FreeBSD's API supports up to 2^63 byte files, but the kernel internal structures limit this to 2^41, or 2TB. In fact, at the moment we don't seem to be able to build file systems of more than 1 TB. This may be a bug. 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: gdb and debugging Linux binaries
On Thursday, 22 February 2001 at 13:55:07 -0800, Jim Pirzyk wrote: I have a question on how to debug Linux binaries. I have a core file from the linux binary, but if I use the FreeBSD gdb, it cannot find the shared libraries in /compat/linux/ If I use the /compat/linux/ /usr/bin/gdb, it says the core file is in the wrong format: Couldn't fetch registers from core file: File in wrong format Couldn't fetch register set 2 from core file: File in wrong format So what is the correct procedure for debugging Linux binaries? Have you tried the Linux gdb? 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: soft updates performance
On Monday, 12 February 2001 at 15:29:17 +0100, Dag-Erling Smorgrav wrote: Danny Braniss [EMAIL PROTECTED] writes: i've been doing some experiments with vinum, and doing a make buildworld (with obj on the same vinum) without soft-updates~ 1 hour with soft-updates ~ 40 minutes which is a bit better than 3% :-) what i can't figure out is why -j 4 didn't make any difference. Because your I/O system is already saturated. The point with -jNN is that one job can run while another is waiting for I/O to complete and vice versa, but as your CPU gets faster the time spent actually compiling etc. becomes insignificant next to the time spent doing I/O, and if you're already doing I/O as fast as you can there's no room for improvement. On a machine with a slower CPU or a faster I/O system, you'd see improvement. In fact, it's exactly the opposite. 'make world' is CPU-bound, so the speed of the I/O system is irrelevant. If it were I/O bound, soft updates *would* make a difference, because a number of unnecessary writes would be eliminated. 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: vinum and qmail (RE: qmail IO problems)
On Wednesday, 7 February 2001 at 13:41:29 -0800, Dan Phoenix wrote: btw ccd requires 2 other drives am i correct? No, you can use ccd with only 2 drives. So i just remove /var/ basically from fstab ...raid0 2 drives together and mount that as var...is my basic understanding. of course of 2 separate controllers..I still don;t see why that matters whether they are on separate controllers or not but my guess has to do with IDE unable to multitask idea.which is leading me to think that means down one controller? See my last message. You're close. 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: vinum and qmail (RE: qmail IO problems)
On Wednesday, 7 February 2001 at 13:31:26 -0800, Matt Dillon wrote: In anycase, while VINUM is great for striping disks I recommend that you use CCD to begin with, because CCD is a whole lot less complex. You can stripe IDE drives but the two drives must be on different IDE controllers (not just primary secondary, but each drive must be primary on its own controller). Then striping will help. I'd contest that. I find configuring ccd very confusing. But recall that error recovery with ccd is extremely primitive. With Vinum you can add mirroring on the fly, and if a mirror dies, the volume carries on running. Of course, I would not recommend using IDE at all if you are pushing 600MB/day in mail. You really should be using a SCSI based system... something like the VALINUX boxes (running either Linux or FreeBSD). If you have only one drive per IDE controller, performance can be very good. You definitely don't want more than one drive, though. 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: vinum and qmail (RE: qmail IO problems)
On Wednesday, 7 February 2001 at 13:16:44 -0800, Dan Phoenix wrote: On Wed, 7 Feb 2001, Andrew Reilly wrote: On Tue, Feb 06, 2001 at 12:13:57PM -0800, Alfred Perlstein wrote: * Andre Oppermann [EMAIL PROTECTED] [010206 12:07] wrote: Does sendmail even use fsync()? It better. :) Quick grep of the sendmail sources shows most of the six fsync calls protected by a flag (SuperSafe or nofsync ). I don't know what circumstances can provoke either of those flags to be zero, but if they can be, then it mightn't be doing any fsyncs. I went over to postfix to see if it did better.in fact it did on freebsd but still same problem with I/O. SOlution from talking to some people late last night would be to add another harddrive and stripe it with another drive using vinum. As you all know IDE does not do multitasking unlike scsi. My question is this vinum product...i beleive the superceder of ccdtaking another harddrive and striping it with the root ide drive would in theory destroy all contents of first IDE? Or can this volume manager take say a partition of first ide drive and made to work with another ide drive? Trying to figure out at this point whether concept is 2 other drives striped together say..using raid 0 or I can get away with just one other one. Thx in advance. At the moment there are two issues: 1. Vinum requires that all file systems be made out of subdisks in a "drive", which is really a partition. A drive has 265 sectors of config and label information at the beginning, so unless you have this space available, you can't turn a ufs partition into a Vinum object. You can convert the first file system after swap to Vinum by shrinking the swap and moving the start of the drive to 265 sectors before the beginning of the file system. Even so, you wouldn't be able to stripe things in this configuration, because striping rearranges the blocks on disk. But I suspect that with ufs, striping won't buy you much over concatenation, which *would* work in this scenario. I'm planning to change things so that Vinum can import external objects such as ufs partitions, for exactly this reason. But I still want to be able to have at least one Vinum drive on each spindle (i.e. physical drive), because Vinum is location independent: you can move spindles with Vinum drives on them to different locations (device names), and Vinum will still understand the configuration. This requires information on the spindle itself, of course. 2. The released version of Vinum still doesn't support a Vinum root file system. I'm planning to work on that, but it'll take a while. 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: Watch your devfs permissions in driver make_dev calls
On Friday, 2 February 2001 at 20:10:10 -0800, Peter Wemm wrote: Robert Watson wrote: crw-r--r-- 1 root wheel 78, 0 Dec 31 1969 pci This one may appear harmless, but it is not. It is trivially easy to create an alignment fault (fatal on an alpha) with the userland pciconf tool. We must not allow this to be used by users until the kernel part is fixed. Eg: try this on an alpha: pciconf -r -l pci0:x:x 0x3 - ie: read a longword at byte offset 3 in configuration space.. kaboom! This looks like a separate issue. Presumably you can do this as root as well. pciconf should check the parameters. 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: Chuck Cranor's PhD thesis on VM
On Sunday, 28 January 2001 at 21:10:34 -0700, Ronald G Minnich wrote: I am sorry I brought this up without a URL :-( I'm working on it. Garrett Rooney already posted it: http://www.ccrc.wustl.edu/pub/chuck 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: if_fxp driver info (which card then?)
On Friday, 26 January 2001 at 9:47:38 -0500, Jim Sander wrote: Linux people avoid the EtherExpress because they think something is wrong with the card. Intel EtherExpress Pro 10/100B cards in FreeBSD These cards work well in our many 3.x and 4.x systems. But I just built up a Redhat 6.2 box with one, and all seemed to be working fine, but after a while I started having various problems starting net services. The box would boot, but often would "hang" indefinitely when "Starting eth0" - requiring a hard reboot. I swapped to another EE-Pro NIC, new MB, different RAM, other cables, everything, but no change. Yes, these are exactly the problems I've heard of. After I switched to a linksys NIC, voila- everything worked without a problem. (so far) Of course the Intel NICs still work perfectly when put into a spare BSD system. So it's *not* that the cards themselves are unreliable. Perhaps the drivers controlling them? Perhaps a weird MB/NIC conflict of some sort? As I mentioned earlier, it's the drivers (two different ones) themselves. Linux people have different opinions about which is worse, but they do agree that both are pretty bad. That's why I've been saying that we shouldn't be looking at porting them. 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: if_fxp driver info
On Thursday, 25 January 2001 at 12:54:17 -0600, Jonathan Lemon wrote: On Thu, Jan 25, 2001 at 01:12:42PM -0500, Dennis wrote: At 10:58 PM 01/24/2001, Jonathan Lemon wrote: In article local.mail.freebsd-hackers/[EMAIL PROTECTED] you write: I'll look into the Linux driver, however, and see if it has anything useful in it. Historically the Linux Pro/100+ driver has totally sucked and was chalk-full of magic numbers being anded and ored. That's "chock full", and you're confusing the Becker driver (bad) with the Intel-supplied driver (slightly less bad). The intel driver seems to cover all the bases and has some nice glue routines for determining the part and features available. I havent tested it under load, but I wonder if intel would consider supporting it if someone ported it over to freebsd? they have drivers for just about every other major OS except BSD. it would be nice if the driver was updated BEFORE cards and MBs that dont work started showing up on the loading dock. Every time I get a shipment we have to hold our breath until we try one out. The documentation is available, if you want to (or have to) sign an NDA. People who have the NDA documentation are perfectly capable of writing a driver, although the source can't be released. It would probably be possible to release a binary driver, but why do anything to help Intel, given their unhelpful attitude? If they have a published, freely distributable driver for linux. why would you have to sign an NDA to port it to FreeBSD? I dont think so. Not anymore anyway. Thats the whole point of this thread... Having looked at the Linux driver, the FreeBSD driver, and the documentation, I can tell you that assuredly not all of the features are documented in the Linux driver. Also, porting requires changing things, and without an understanding of _WHY_ things are done the way they are, you can end up invaderdently changing something that turns out to be critical. Also, the Intel driver isn't put together very well, so you might end up with a lower performance driver after all is said and done. Performance isn't even the main thing. As I said earlier, it's plain bloody unreliable. Linux people avoid the EtherExpress because they think something is wrong with the card. They were surprised when I reported that it works without any problems under FreeBSD. Do we really want to change that? 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: Kernel Hacking (i tried not to make it lame)
On Thursday, 25 January 2001 at 22:03:35 -0500, [EMAIL PROTECTED] wrote: hey guys i know you probably get this question all the time but i am looking into getting into doing somekernel hacking first i will tell you some thing i have assumed about it: 1.) you should know atleast more programming language well (probably C would be best) 2.) you should know some basic stuff about FreeBSD internels (i am planning on getting The Design and Implementation of the 4.4BSD Operating System Correct on both counts. that is about it the rest really is a blur and is so complex and huge i have no idea where to begin hope i wasn't to lame guys :-) Well, once you have the book, look at something you might find interesting, and play around with it a bit. If you keep a "diary of a learning hacker" on the web, you might do a great favour to a number of people like yourself. If you run into trouble, ask here. 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: if_fxp driver info
On Wednesday, 24 January 2001 at 17:08:16 -0500, Dennis wrote: I'll look into the Linux driver, however, and see if it has anything useful in it. Historically the Linux Pro/100+ driver has totally sucked and was chalk-full of magic numbers being anded and ored. That's "chock full", and you're confusing the Becker driver (bad) with the Intel-supplied driver (slightly less bad). The intel driver seems to cover all the bases and has some nice glue routines for determining the part and features available. We recently did some testing of these drivers at my company. We found both drivers to be very bad, and the consensus was that the Intel driver was worse. We were not able to keep a link up under load for more than a few hours. I havent tested it under load, but I wonder if intel would consider supporting it if someone ported it over to freebsd? they have drivers for just about every other major OS except BSD. it would be nice if the driver was updated BEFORE cards and MBs that dont work started showing up on the loading dock. Every time I get a shipment we have to hold our breath until we try one out. I've come in in the middle of this discussion, so maybe there's something I don't know, but on the same hardware and running FreeBSD, I had no problems. Why should we want to replace the driver with something which doesn't work well? 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: if_fxp driver info
On Wednesday, 24 January 2001 at 21:07:45 -0800, Matt Jacob wrote: I've come in in the middle of this discussion, so maybe there's something I don't know, but on the same hardware and running FreeBSD, I had no problems. Why should we want to replace the driver with something which doesn't work well? There's been a hint of 'vendor supported' We saw no evidence of that. 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
Daemon images (was: One thing linux does better than FreeBSD...)
On Monday, 15 January 2001 at 13:40:38 +0100, Poul-Henning Kamp wrote: There is one point where I have to conceed defeat to Linux. That fat little penguin is everywhere. The main reason we practically don't see beastie at all is that there is no artwork to get hold of anywhere... Please, somebody, anybody: Can we have some beastie artwork in usable sizes for posters, T-shirts and such ??? And images which will fit on business cards, please. 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
Daemon images (was: One thing linux does better than FreeBSD...)
On Monday, 15 January 2001 at 8:41:51 -0800, Richard Hodges wrote: On Mon, 15 Jan 2001, Poul-Henning Kamp wrote: There is one point where I have to conceed defeat to Linux. That fat little penguin is everywhere. The main reason we practically don't see beastie at all is that there is no artwork to get hold of anywhere... Please, somebody, anybody: Can we have some beastie artwork in usable sizes for posters, T-shirts and such ??? I'm not an artist, but I can visualize a graphic that I think would be pretty cool... Picture the Daemon standing next to a penguin. The penguin is holding a flag, as if a colorguard. Make that a MS flag. And the Daemon is setting it on fire... That's not the impression I'd like to make. 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: Daemon images (was: One thing linux does better than FreeBSD
On Monday, 15 January 2001 at 16:00:55 -0800, John Baldwin wrote: On 15-Jan-01 Greg Lehey wrote: On Monday, 15 January 2001 at 13:40:38 +0100, Poul-Henning Kamp wrote: There is one point where I have to conceed defeat to Linux. That fat little penguin is everywhere. The main reason we practically don't see beastie at all is that there is no artwork to get hold of anywhere... Please, somebody, anybody: Can we have some beastie artwork in usable sizes for posters, T-shirts and such ??? And images which will fit on business cards, please. Greg The little beastie in the BSDi logo fits rather nicely on my business card... URL? 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
Dump analysis (was: Ideas? (fwd))
On Monday, 8 January 2001 at 10:04:44 +0200, Roman Shterenzon wrote: * Roman Shterenzon [EMAIL PROTECTED] [010107 10:24] wrote: Hi, Could you please take a look at : http://www.freebsd.org/cgi/query-pr.cgi?pr=24019 It's my friend's PR. Can you give me some hints on how can I debug this issue. I'm completely puzzled here. It panics on "goto out" with page fault. What I understand from it is that the block at the address it tries to jmp to isn't present. But it's kernel code which is never swapped out. Does it mean that the address was rewritten? If it's so, what can rewrite this address? Ideas? My first suspicion here is that the sources are out of sync with the kernel you're debugging. It's very important to ensure that they are absolutely in sync. Here are a couple of incantations to throw at this dump (you may recognize the second one from an earlier mail exchange): (kgdb) x/10i epread (kgdb) x/10i 0xc012a038 The first one should show the beginning of the function; if it's in sync it will look like (modulo addresses): (kgdb) x/10i epread 0xc0165f8c epread:push %ebp 0xc0165f8d epread+1: mov%esp,%ebp 0xc0165f8f epread+3: sub$0x1c,%esp 0xc0165f92 epread+6: push %edi 0xc0165f93 epread+7: push %esi 0xc0165f94 epread+8: push %ebx 0xc0165f95 epread+9: mov0x8(%ebp),%eax 0xc0165f98 epread+12: mov%eax,0xfff4(%ebp) 0xc0165f9b epread+15: mov0x118(%eax),%edx 0xc0165fa1 epread+21: add$0x8,%edx In particular, those first two instructions are at the beginning of just about every function, so if you don't find them, you should check whether your code is in sync. P.S. Can it be due to faulty hardware? Or faulty Italian cuisine? In each case, not if it's repeatable. 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: StrongARM support? (was also: Group for porting to other proccessor families)
On Monday, 8 January 2001 at 0:22:01 +0800, Kathy Quinlan wrote: Hi all Is their a group of FreeBSD Enthusiasts that are working on porting free to embedded controllers that are not x86 I am in the process of developing a security / access / building management system, and am looking at using free on all my outlying units. I am not interested in using pc104 etc but using processors like the atmel thumb processor, this is a risc based uC capable of handling 64Mb of flash ram for program and working ram. why do I want an OS for an industrial app, simple some units may be standalone and need dialling into, building units will probably be TCP/IP. If I understand correctly, this is an ARM architecture. Almost the same time you wrote that, this message was sent to -hackers: On Sunday, 7 January 2001 at 6:20:26 -0800, Jordan Hubbard wrote: [missing attribution to Michael C. Wu] I'm definitely interested in both StrongARM and PPC. (and so are very many people) My understanding is that FreeBSD *wants* a FreeBSD/ARM, but lack the resources/man-power to do so. I'd prefer to see an official decision on the above by someone (hint hint -core :)) though. I don't think any "official decision" would say anything we in core haven't already said individually and many times over the years. Sure, FreeBSD wants ARM and PPC ports but currently lacks, at least to our knowledge, the man-power to lead and support such a project. You said it yourself. If some motivated individuals out there would like to change that situation, you have our full support! Porting to ARM isn't going to be trivial, but the obvious first step is to get interested people together. Note that we've had a SPARC porting effort languishing out there for years now. If ARM is to do better, it will need significant support. Jordan's response above was made without his -core hat on. If people want a response from -core (which I suspect will probably be very similar), they should send mail to -core asking for it. 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: debugging kernel buffer overwrite
[following up to -hackers]
On Tuesday, 2 January 2001 at 14:35:39 -0500, Jeff Fellin wrote:
I previous sent this mail on freebsd-current, but realize it
was probably an incorrect list. So, I am reposting on to
freebsd-questions. If this is still the wrong list could
someone tell me the best list to post this question to?
FreeBSD-hackers, probably. -questions is for administrative rather
than programming issues.
I am having a problem with a device driver that uses physio
to transfer data to a SCSI adapter. Some times the after
passing the buffer to the CAM system, via xpt_action, the
buffer contents are modified. I've traced my driver and cannot
determine how this could be happening. I am running on a single
CPU Pentium II system with all system config defaults.
What I would like to do is to dynamically set a watch point
on the buffer used by the write system call for the duration
of sending the data to the SCSI adapter. I want to do this
dynamically instead of manually setting a breakpoint in the
code and manually setting the watch point, because the problem
occurs around the 90'th time, and I don't want SCSI bus timeouts
while typing the watch address.
I've examined the ddb code, and thought that if I emulated the
steps in db_trap() for the command of setting a watchpoint it
would work. However, it doesn't appear to be working.
What I've done is:
/* possible on data xfer = 512 bytes */
if (condition for problem) {
db_watchpoint_cmd(bp-bio_addr, bp-bio_addr,
bp-bio_count, "rw");
Why "rw"? The parameter is a char *, which is the type of "rw".
db_continue_cmd(0, 0, 0, "w"):
db_restart_at_pc(FALSE);
}
When the buffer is done transmitting I do the following:
db_clear_watchpoints();
db_deletewatch_cmd(bp-bio_addr, bp-cio_addr,
bp-cio_count, "rw");
db_continue_cmd(0, 0, 0, "w");
db_restart_at_pc(FALSE);
My driver trace printf's show the data at bp-bio_addr was
changed from 0x601000a3 to 0x0.
That's a strange initial address. I didn't think we had anything
mapped at 0x601000a3.
Additional traces show the data from the first 200+ bytes is changed
to zero.
In the buffer header, or in the data buffer?
Any guidance on how to use the ddb functions to debug this problem
are appreciated. Also, alternative methods to determine what is
overwriting the buffer. In looking at the data on a SCSI bus
analyzer, the entire buffer has been zero'ed out.
Hmm. You don't say what goes wrong, nor whether your breakpoints ever
get set. In the past I've used the debug registers for this, which
has the advantage that, if you know where it's going to get broken,
you can set a memory access breakpoint and catch it in the act. I can
drag out the functions if you like.
Greg
--
When replying to this message, please copy the original recipients.
If you don't, I may ignore the reply.
For more information, see http://www.lemis.com/questions.html
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: kernel debugging suggestion needed
On Tuesday, 2 January 2001 at 14:03:16 -0800, Doug White wrote:
On Tue, 2 Jan 2001, Zhiui Zhang wrote:
I have written a KLD and am debugging it. The program often hangs after
runs for a while (I guess it enters into some dead loop). Is there a way
to attach to the process and somehow find out which code it is executing
(with remote debugging or ddb)?
kld debugging is a bit tricky. Take a look at the debugging macros and
bits that Greg Lehey put together for vinum for a starting point. You have
to calculate the appropriate offset to get to the KLD code in gdb.
Doug Rabson has described an alternative to me, but I never got it to
work. My hack walks down the list of klds looking for a name starting
with 'v'; you can change this to something which identifies your kld,
and you'll need to change the name of the kld itself, of course. I
also have a number of other macros in files in
/usr/src/sys/modules/vinum.
Here's the macro:
define asf
set $file = linker_files.tqh_first
set $found = 0
while ($found == 0)
if (*$file-filename == 'v')
set $found = 1
else
set $file = $file-link.tqe_next
end
end
shell /usr/bin/objdump --section-headers sys/modules/vinum/vinum.ko | grep ' .text'
| awk '{print "add-symbol-file sys/modules/vinum/vinum.ko \$file-address+0x" $4}'
.asf
source .asf
end
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: kernel debugging suggestion needed
On Tuesday, 2 January 2001 at 23:22:49 -0500, Zhiui Zhang wrote: On Tue, 2 Jan 2001, Doug White wrote: On Tue, 2 Jan 2001, Zhiui Zhang wrote: I have written a KLD and am debugging it. The program often hangs after runs for a while (I guess it enters into some dead loop). Is there a way to attach to the process and somehow find out which code it is executing (with remote debugging or ddb)? kld debugging is a bit tricky. Take a look at the debugging macros and bits that Greg Lehey put together for vinum for a starting point. You have to calculate the appropriate offset to get to the KLD code in gdb. I already did this. I hope that I can find a way to know which process is running which part of the KLD code endlessly. There are other macros in my .gdbinits which give you backtraces of other processes. 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: -STABLE+vinum+smp+softupdates+CVSup(local CVS repo)==corruption?
On Thursday, 28 December 2000 at 14:03:31 +, Josef Karthauser wrote: On Tue, Dec 26, 2000 at 05:30:09PM -0500, David E. Cross wrote: I have run across a problem since updating to -STABLE a week or so ago... my CVS vinum partition would go corrupt after a few updates. I have been running with no softupdates on my system for a day now and no problems. Has anyone else seen this? Is that with vinum raid 5? If so there are know problems with raid 5 and you should either help Greg to fix them or avoid raid 5 like the plague lest your data corrupts itself. I can't recall any data corruption. The problems you were seeing were panics where buffer headers got corrupted, and they happened to a very small number of people (not including myself, which makes it difficult to catch them). I think I might have a solution there. It's currently being tested in -CURRENT, but before that I'd like to find somebody who can reproduce the original problem. I certainly don't think it's a reason to avoid RAID-5, like the plague or otherwise. You'll notice that David's problem has nothing to do with that, nor with Vinum at all, it would seem: On Thursday, 28 December 2000 at 11:52:03 -0500, David E. Cross wrote: No, I am just using vinum stripes. The problem seems to have fixed itself when I got a ufs_readwrite.c update from Matt after it was committed. This is an interesting problem, since I am not entirely sure what fixed it, if it is really fixed, etc... Indeed. Was this just the CVS repo? 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: -STABLE+vinum+smp+softupdates+CVSup(local CVS repo)==corruption?
On Tuesday, 26 December 2000 at 17:30:09 -0500, David E. Cross wrote: I have run across a problem since updating to -STABLE a week or so ago... my CVS vinum partition would go corrupt after a few updates. I have been running with no softupdates on my system for a day now and no problems. Has anyone else seen this? I haven't heard of any such problem, but with the details you give, it's difficult to tell. 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
Optimizations (was: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c))
On Tuesday, 19 December 2000 at 16:01:52 -0800, David O'Brien wrote: On Mon, Dec 18, 2000 at 01:11:12PM -0600, Jacques A. Vidrine wrote: /* Case 1 */ /* Case 2 */ if (data) vs. free(data) free(data); Actually from an optimization standpoint, #1 can be worse (ie, harder on the processor). You've got a conditional jump there that is using branch prediction HW to track (which means there is some other conditional branch you're not, you're fetching both the taken and not take paths, etc... If the function call isn't expensive, #2 can be "faster". In which processors is a function call anywhere near as cheap as a conditional local branch? 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: GDB Displaying all vars in a stack frame.
On Friday, 8 December 2000 at 18:29:26 -0600, Stephen Hocking wrote: Is there some simple one-liner command that allows me to display the values of all the variables within the current stack frame? info local 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: Printer problems, please help
[redirected to -questions; I don't consider this an in-depth technical question] On Wednesday, 29 November 2000 at 21:03:10 +0100, Rink Springer wrote: [Posted this to questions too, but no one appeared to know.. maybe someone here does?] Hi, I've installed FreeBSD 4.2-RELEASE on a server here (AMD K6-2 333MHz, 64MB RAM), which does gatewaying, firewalling, NATd and finally, samba, samba for printing. The box works like a charm, but printing doesn't. The printer connected to it is an Epson Stylus Color 600, hooked to /dev/lpt0. When I print the Windoze test page, it works (lpq happily says the file is 200KB, and it gets printed). However, whenever I try to print some image that is about 1MB in the print queue, the printer prints a small part, and the rest will not be printed. In fact, the entire queue entry is gone! Does anyone know what has caused this? I noticed some stray IRQ 7's, but even if I enable polling mode (using lptcontrol -p), it doesn't work. I need to get this printer working soon. It worked fine using RedHat Linux 6.1. I have pretty much the same setup. Well, the CPU side is the same, but the printer's a Stylus 740. If you print documents of this size, you're probably talking about images. How do you convert the image? If you're using filters, let's see them. Also, you don't have a file size limit in /etc/printcap, do you? Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply. For more information, see http://www.lemis.com/questions.html 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: looking for kernel hacking info
On Tuesday, 14 November 2000 at 16:32:49 -0500, Paonia Ezrine wrote: I am looking for info on programing in kernel land. System calls, howto's etc. I have not found anything that realy covers this stuff any and all help would be welcomed! The system calls are described in section 2 of the manual. 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: looking for kernel hacking info
On Tuesday, 14 November 2000 at 21:14:25 -0500, Paonia Ezrine wrote: On Tuesday, 14 November 2000 at 16:32:49 -0500, Paonia Ezrine wrote: I am looking for info on programing in kernel land. System calls, howto's etc. I have not found anything that realy covers this stuff any and all help would be welcomed! The system calls are described in section 2 of the manual. thanks. do you mean handbook? No, the manual. That's the real name for the man pages. Read it with man(1). 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: looking for kernel hacking info
On Wednesday, 15 November 2000 at 10:08:45 +, visi0n wrote: The THC have a documentation about freebsd kernel space. packetstorm.securify.com/groups/thc/bsdkern.htm Repeating the full URL for the benefit of mutt users, this is http://packetstorm.securify.com/groups/thc/bsdkern.htm This is an interesting document. It describes how to insert a Trojan into the FreeBSD kernel When it came out, we discussed it and decided that it would be of no danger to a properly secured system. On the other hand, the documentation is relatively well done. We should really import it. 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: Determining CPU on SMP box
On Tuesday, 24 October 2000 at 7:37:12 -0400, Christopher Harrer wrote: Hello All, Is there a way to determine which CPU I'm currently executing on in a SMP box? I've found references to proc-p_oncpu, but I'm not sure if this is the best way to determine where I'm executing. I'd like to be able to "trace" various actions within my driver and one of the fields I want to keep track of is what CPU I'm executing on. Which version of FreeBSD? 5-CURRENT has the ktr functions, which you could use for your tracing. They include CPU information. Unfortunately we don't have a man page yet. 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: UDMA ICRC WRITE ERROR
On Sunday, 15 October 2000 at 13:58:15 +0200, Frank Nobis wrote: Hi, I have a IDE drive spitting out this messages: ad3: UDMA ICRC WRITE ERROR blk# 48562489 retrying ad3: UDMA ICRC READ ERROR blk# 24576329 retrying ad3: UDMA ICRC WRITE ERROR blk# 69108025 retrying ad3: UDMA ICRC WRITE ERROR blk# 73728313 retrying Is this always the same drive? From the boot messages: atapci0: Intel PIIX4 ATA33 controller port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: 8063MB IBM-DTTA-350840 [16383/16/63] at ata0-master using UDMA33 ad1: 42934MB WDC WD450AA-00BAA0 [87233/16/63] at ata0-slave using UDMA33 ad2: 42934MB WDC WD450AA-00BAA0 [87233/16/63] at ata1-master using UDMA33 ad3: 42934MB WDC WD450AA-00BAA0 [87233/16/63] at ata1-slave using UDMA33 Do I have to exchange the drive ? I think I should. You could try setting PIO mode first. In the case of replacing is the best thing to do, that leads to the question, how to replace this drive ? Shut the machine down. Replace drive, making sure the jumpers are set correctly. Reboot. It is a part of a vinum raid5 volume. Is detach and attach the right way ? No. Take a look at the description on http://www.vinumvm.org/. Sorry, I don't know the exact URL, and I'm currently off the net. One thing that occurs to me is that I suspect you're using ad[123] as your RAID-5 drive. That's seriously sub-optimal for performance, but it also means that ad2 and ad3 will frequently have transfers outstanding at the same time. That might be the real issue; you might find that if you swap ad1 and ad3 (which you can do without losing data on the volume), you will continue having problems with the new ad3. PS. If someone want more information about the System (PRESMPNG) dual PIII on an ASUS P2B-DS, just let me know. I want avoid spamming the list with big config and dmesg output Right, we don't need them. Read http://www.vinumvm.org/how-to-debug.html for details regarding Vinum 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: dual console with matrox g400
On Tuesday, 10 October 2000 at 0:35:07 -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Greg Lehey writes: Well, you obviously need two keyboards and two mice. I can't think of a case where that would be useful, but with x2x (in the Ports collection) you can allow different people access to the same server. In 1990 I shared a Solbourne workstation with a friend. It had two graphics/I/O boards, which ment that you could have two independent video consoles on it at the same time. Worked a whole lot better than one would have expected given the relative primitive tehcnology of the time. Glad to see that PCs are catching up :-) I had a PC with two graphics cards long before that. It was relatively common to have a machine with both CGA and MDA, and there were some debuggers which would handle both (debug a full-screen application with the debug output on the other monitor). 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: dual console with matrox g400
On Tuesday, 10 October 2000 at 0:51:50 -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Greg Lehey writes: I had a PC with two graphics cards long before that. It was relatively common to have a machine with both CGA and MDA, and there were some debuggers which would handle both (debug a full-screen application with the debug output on the other monitor). True. But I've not seen a PC that could have multiple keyboards/mice until USB came along. Well, I did see some kludges, but they were fairly rare. Now, many different solutions exist that you can mix and match... Well, multiple mice were never an issue, but the keyboard was. I had done some thinking about a serial keyboard, but mainly to get away from the stupid layouts of PC keyboards. 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
