Re: Missing quote in comment in 8.3 9.0 9.1RC2 etc/sendmail/freebsd.mc
On Tue, Dec 4, 2012 at 7:16 PM, Garrett Cooper yaneg...@gmail.com wrote: On Tue, Dec 4, 2012 at 7:03 PM, Eitan Adler li...@eitanadler.com wrote: On 4 December 2012 21:23, Julian H. Stacey j...@berklix.com wrote: Hi, Reference: From: Eitan Adler li...@eitanadler.com Date: Tue, 4 Dec 2012 20:58:20 -0500 Message-id: caf6rxgk5wtmzubta_8oepez8n23+8wyf85deqs-i+igtkfj...@mail.gmail.com Eitan Adler wrote: On 4 December 2012 20:21, Julian H. Stacey j...@berklix.com wrote: At Wed Dec 5 02:16:29 CET 2012 the web ref fails: http://www.freebsd.org/cgi/query-pr.cgi?pr=174108 There is no bug in the bin category beyond 174103 This is a known issue. I'm not sure what is causing it. Your bug made it (check the freebsd-bugs mailing list) but the web interface can't find it. -- Eitan Adler Thanks Eitan, OK I see http://lists.freebsd.org/pipermail/freebsd-bugs/2012-December/051052.html Garrett C mentioned it was slow wait a bit. Normally it takes about 15 minutes for it to sync and cron to catch up.Something else is going on here. Clusteradm, can you comment? It took almost an hour on Sunday, FYI. -Garrett cvsup and cvsupd started giving SIGBUS after the last installworld. I haven't looked too closely yet. I am inclined to replace the data transfer from freefall - www.freebsd.org with a straight up rsync. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV All of this is for nothing if we don't go to the stars - JMS/B5 If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Soliciting opinions on an extension of the bootinfo structure
On Thu, Sep 8, 2011 at 3:25 PM, Peter Grehan gre...@freebsd.org wrote: I'm proposing an extension framework for the bootinfo structure used to pass information from the bootstrap/loader to the kernel. Although I'm only proposing this for the MIPS bootinfo, it's completely applicable to any of them. What I propose is adding an optional platform extension structure: bootinfo_pext, surrounded by #ifdef BOOTINFO_PEXT Any reason not to put the vendor bits into another piece of loader metadata ? That seems the extensible way to add additional info from the loader, rather than extending bootinfo (as was the case pre-loader days). later, It sounds like they're not using loader, which is probably a reasonable thing for their environment. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV All of this is for nothing if we don't go to the stars - JMS/B5 If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
TIME WARP! Re: HEADS UP: GCC 4.2.0 is coming
On Wed, Oct 8, 2008 at 12:57 AM, O. Hartmann [EMAIL PROTECTED] wrote: Alexander Kabaev wrote: On Fri, 18 May 2007 19:20:07 -0400 Alexander Kabaev [EMAIL PROTECTED] wrote: HEADS UP: I will start importing GCC 4.2.0 bits in about one hour and plan to finish in a couple of hours after that. The src/ tree will be utterly broken meanwhile. I'll send an 'all clear' message when done. Done. Just for those who aren't on the cutting edge: why gcc 4.2.0 and not 4.2.1 as it is used in 7.X? Regards, O. Sorry about that. I accidently revived a bunch of stuck email messages from our mailing list processing system. These messages from 2007 came back to life somehow. (Hint: Mailman's 'unshunt' command doesn't give a usage message) -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; KI6FJV All of this is for nothing if we don't go to the stars - JMS/B5 If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs: how to put vendor-deleted file into Attic?
On Thursday 26 July 2007, Xin LI wrote: Hi, While maintaining some third party contributed software packages I ran into a problem where, say, if I remove a file from the vendor branch (the file was never dragged off the vendor branch), it does not appear in Attic. Is there a way to move it into Attic (presumably this would give better checkout speed for -HEAD)? Cheers, The way you do this is: cvs checkout -r1.1.1 contrib/whatever cvs rm files cvs commit This puts the deletion on the 1.1.1 vendor branch. HEAD picks it up automatically, and if the file becomes alive again in the future, HEAD continues to track it. And there is metadata recorded to track when it was deleted and came back alive etc. -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TDF_NEEDRESCHED when extending pcb on x86
On Monday 28 February 2005 02:57 pm, Denis Ustimenko wrote:
Hi, there!
I've tried s3switch utility from ports on 5.2.1 and found that
i386_set_ioperm syscall doesn't work properly. The next code illustrates
the problem. It will get SIGBUS with very high probability.
#include sys/types.h
#include machine/sysarch.h
#include machine/cpufunc.h
int main()
{
if ( i386_set_ioperm( 0x80, 1, 1)) {
perror(XXX);
return 1;
}
inb( 0x80);
return 0;
}
Now I have no 5.3 or CURRENT system but brief looking on code shows that
it should give the same result on them.
The problem occurs when we extend pcb and set TDF_NEEDRESCHED bit hoping
that thread will be rescheduled and new TSS will be loaded. But
sched_switch function skips cpu_switch when thread was not changed and
ltr is not executed.
I think it would be better to fix the semantics of TDF_NEEDRESCHED. I was
thinking that mi_switch could negate the cpu_switch optimization if
TDF_NEEDRESCHED was set. That would avoid duplicating the internal knowledge
of the pcb/tss/etc handling in this code.
-Peter
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My project wish-list for the next 12 months
On Wednesday 01 December 2004 05:17 pm, Foxfair Hu wrote: On Wed, Dec 01, 2004 at 03:02:40PM -0700, Scott Long wrote: All, [] 1. Keyboard multiplexer. We are running into problems with making ps/2 and USB/bluetooth keyboards work together and work with KVMs. Having a virtual keyboard device that multiplexes the various real keyboard devices and handles hotplug can solve this mess pretty effectively. I know that there has been a lot of talk about this on mailing lists recently but I don't know how much progress is being made so I'm listing it here. How about reuse NetBSD's wscons ? I've kept an eye on it and thought it should be a good start for FreeBSD. Only if it has 100% identical look/feel to syscons. ie: same key maps, same ioctl's, same Xserver interface, same escape codes, etc. If not, then over my dead body! -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: isp driver not 64 bit?
On Tuesday 30 November 2004 11:39 am, Wilko Bulte wrote: On Mon, Nov 29, 2004 at 08:05:39PM -0500, [EMAIL PROTECTED] wrote.. After a bunch of frustrating debugging, I've tenatively come to the conclusion that the isp(4) driver is not 64 bit safe --- at the very least insofar as the amd64 platform is concerned. Side note: isp(4) has been in use for years on Alpha, and I do not recall having seen problems like yours on it. Mind you, not much FC connections I ever used on it. The only thing critical for success on Alpha is loading ispfw.ko *always*. Matt (mjacob) has noted that multiple times, and he is absolutely right. Wilko I haven't seen an alpha with more than 2G of ram that we booted on. Is it possible that isp has never been tested with 4G ram? Secondly.. what release is this on? I'm wondering if the horrific busdma bugs in 5.3-RELEASE might be a problem if the machine does have 4G ram. Third, is this a machine ram size problem or a disk volume size problem? The original post was about a 131G FC volume and calculating the wrong number of sectors and the wrong sector size... -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: isp driver not 64 bit?
On Tuesday 30 November 2004 02:54 pm, David O'Brien wrote: On Tue, Nov 30, 2004 at 03:42:55PM -0500, David Gilbert wrote: I just heard back from some people still onsite. The ISP driver booted with everything the same except hw.physmem=2g works. It's a memory issue. Try hw.physmem=4g. It should be the 4GB boundary, not 2GB boundary that is causing you trouble. I wonder if the isp driver is using 32 bit signed addressing for its dma control blocks or something.. I have an ISP-something scsi controller that I could probably extract from an itanic box, but I've got to get more ram in my test machine.. -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! KSE needs more attention
On Monday 07 June 2004 07:33 am, Thomas Moestl wrote: On Sun, 2004/06/06 at 14:59:21 -0700, Kris Kennaway wrote: On Sun, Jun 06, 2004 at 03:49:13PM -0600, Scott Long wrote: amd64 is approaching critical mass for tier-1. There are a number of developers that own amd64 hardware now, and a number of users who are asking about it on the mailing lists. Peter is finishing up the last blocking item for it (kld's) not including the observed KSE problems. It's very close and I _will_ hold up the release for it to get done. amd64 is the future of commodity computing and we aren't going to ignore it for 5-STABLE. amd64 has a bug with swapping - when something begins to access swap, the entire system becomes almost entirely unresponsive (e.g. no mouse response for up to 10 seconds) until it stops. Peter has some ideas about it, but it's a serious enough bug that it forced me to stop using amd64 as my desktop machine (hello, kde!). Hmmm, I have encountered a similar problem on sparc64 once; the reason was that vm_pageout_map_deactivate_pages() calls pmap_remove() for the range from the start to the end of the process's vm_map when a process is swapped out. Start and end are VM_MIN_ADDRESS and VM_MAXUSER_ADDRESS respectively, and on 64-bit architectures, that range is very large (128TB on ia64 if I'm not mistaken), so the iteration in pmap_remove() must be carefully designed to make as large steps as possible to avoid long run times (or to not iterate over the range at all if it becomes too large, which we did on sparc64). It seems that the amd64 version of pmap_remove() will essentially always iterate in 2MB (level 2 page table) steps, regardless of whether there is mapping for the respective level 2 table in the table levels above; that means that in the previously mentioned case, the outer loop will usually run for about 67 million iterations (the resident count guard may not be of much use here if a stack page is left at the very end of the address space). Since there are a few memory accesses needed in each iterations, that may already be the cause of such a delay. You know, this sounds spot-on! Thanks for the tip! -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP: list posting policy changed
If you subscribe using a different address than you post, you will need to *also* subscribe your regular posting address as well. After you have subscribed that, you can go onto the options page and turn off mail delivery for that address. eg: If your subscription address is: [EMAIL PROTECTED] but you normally post to the lists as '[EMAIL PROTECTED]', then you will need to *also* subscribe '[EMAIL PROTECTED]' and set its delivery options to 'no mail'. Your inbound email will come in as usual to your list address and the mailing list software will allow your normal address to post as well. Sorry for the hassle, but things have just got too damn silly lately. Regardless of the sender filter, you should do this anyway because the spam filter gives a special bonus to subscribers and is especially harsh on non-subscribers. While I'm here, we could use a bit of help with the list moderation functions. If there are regular readers with some spare time on their hands who would like to help, please let me know. The moderator interface to the queue is web form based, point-and-shoot, and easy to operate. It would be an excellent thing for folks who are looking for a way to contribute but don't have the technical expertise. -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: list posting policy changed
On Friday 19 December 2003 03:21 pm, Peter Wemm wrote: If you subscribe using a different address than you post, you will need to *also* subscribe your regular posting address as well. After you have subscribed that, you can go onto the options page and turn off mail delivery for that address. Since I didn't say last time, this is for just -current and -hackers. -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nVidia nForce2 potential owners please read (take two)
Greg 'groggy' Lehey wrote: On Monday, 29 September 2003 at 12:45:35 -0700, Tony A, Fields wrote: Thanks for your effort to get the nVidia folks to pony up the documentation. I unfortunately purchased a system that has a motherboard that uses the MCP2 network adapter chip set. I now have to rethink how I am going to configure the system as a file server that straddles the enterprise wide intranet and a local lab network while maintaining some isolation between the two. A 100 Mb/s NIC will cost you about $10. But in a 1U case, it won't fit since you likely do not have any PCI slots and depend on what is on the motherboard. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nForce MCP network driver - working
Q wrote: Hi, I am in the final stages of porting the NVidia Linux nForce MCP network driver to FreeBSD-5.1 and am after some experienced users/developers with access to this hardware to do some testing to find out what breaks, and what doesn't work. My driver makes use of the Linux nvnetlib.o API library, and should therefore be compliant with the NVidia Linux distribution license. The driver currently appears to be stable on my hardware (an MSI K7N420 Pro), although I haven't done much stress testing, nor do I have access to an nForce2 based motherboard to test. I have a set of nForce2 and nForce3 based boards, but they all run 5.x and the nForce3 is an athlon64 system. This is still very much a work in progress, but it has been stable enough for me to actually use productively so I thought I would share the wealth, so to speak, with the rest of the community. If you are interested in testing this, email me offline. I am also interested in how many people would like to see a FreeBSD-4.x version. PS: I am still waiting for NVidia to reply to any of my emails. :( Fun fun. :-( Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [future patch] dropping user privileges on demand
ari wrote: Currently, root is the only user that can actually drop significant privileges, as root is the only user that has access to such functions. This is flawed --- any user should be able to relinquish his privileges, and i've begun a patch to put this into effect. However, the fact that this is a security-related kernel feature modification warrants peer-review, in both design and implementation. It would be unwise of me to create the patch without consulting such. The web page that discusses the patch may be found at: http://www.episec.com/people/edelkind/patches/kernel/flowpriv/ I welcome any discussion and criticism. The biggest risk is that you may have aquired something priviliged in your process memory space or file descriptor table. If you are then fully unpriviliged, then things like ptrace(), core dumps etc, become a minefield. For example, if a process did a getpwnam() before dropping privs, then it may have a cached copy of the secret master.passwd data in memory. Anyway, thats something to keep in mind. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible issue with in-kernel ELF loader.
Matthew Dillon wrote: I got an odd bug report for DragonFly today. Apparently the module loader was broken, the kernel complained about not being able to find 'globaldata'. It turns out that the kernel's internal ELF loader is misinterpreting an ABS symbol (i.e. set with .SET in assembly) whos value is 0 as being 'not found', and once that is fixed it was also confusing the absolute symbol with a COMMON symbol. Thanks for the pointer. FWIW, We use -fno-common on 5.x to avoid common symbols even existing in the first place. There were a few missing externs that this turned up. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fat Cat Media Newsletter
Sorry, this one slipped through. I had just reset the spamassassin bayesian filter because of a rather silly thing that I did that poisoned the database. (hint: dont whitelist your mailing list sender address, that causes most spam to be scored as about -90 or so and autolearned as ham) Its interesting to see the mime stripping at work though. This had fairly nasty tracking and javascript in the original email. Unfortunately the stripping makes downstream spamassassins even less interested. Mine at home rated the cleaned version at 0.5 :-(. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dynamic hints
Nicolas Souchu wrote: Is that possible to change hints once booted? I noticed in the archive it was planned but none of the man pages refer to such a feature. Any patch around? Yes, sort-of. kenv(8) can change the strings. But I suspect it is too late for something like isa since I think it would have done a pass at boot to create the attachment nodes. But as configuration knobs for drivers that want to examine a string directly via getenv() etc, those would not be too late. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Trailing whitespace in FreeBSD
Jordan Hubbard wrote: Wow, deja-vu! Hey! I've got a GREAT idea! I whipped up this nifty perl script and I can run it over the src tree to delete all the trailing whitespace! And even better, I can collapse tabs at the beginning of lines! What a great deal! That should be good for a few hundred commits! :-) - Jordan On Monday, February 10, 2003, at 03:00 PM, Simon L. Nielsen wrote: Hello I have noticed that that several FreeBSD files (.c, .h and so on) have trailing whitespace (spaces/tabs after last charecter on a line). Should I send patches for this, or is it not important to fix? A random example is stdbool.h v. 1.6 on line 30 which has a trailing tab. -- Simon L. Nielsen mime-attachment To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Trailing whitespace in FreeBSD
Mike Silbersack wrote: On Mon, 10 Feb 2003, Jordan K Hubbard wrote: * Obligatory trivia: I wonder how many remember that freefall was named after Rod's passion for the sport I've always wondered about that... unfortunately, the answer is much less exciting than I had expected it to be. THANKS FOR RUINING MY BELIEFS ABOUT FREEBSD, JORDAN. Heh, bet you didn't know that bento's predecessor was called thud. And we had a 'ripcord' for a while too. I just dont remember exactly which machine it became. I think it was a temporary name for the machine that became hub. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Problem opening /dev/ad0{,s2} O_RDWR (also disklabel, grub) on 5.0.
George Hartzell wrote: Daniel Lang writes: Hi George, George Hartzell wrote on Sat, Jan 25, 2003 at 06:38:07PM -0800: [..] open(/dev/ad0, 1)', and 'call open(/dev/ad0, 2)' made it clear that anything that would write to the disk was failing. [..] disklabel: /dev/ad0s2: Operation not permitted [..] So, my questions are: 1) does this ring a bell with anyone? 2) Is there something in 5.0 that requires special magic to write to the raw disk devices? You need to run in securelevel 1. Check sysctl kern.securelevel, and read init(8). I guess you have some rc.conf entry that raises your securelevel, most probably resulting from the sysinstall. That's not it, kern.securelevel is -1 and this is in /etc/rc.conf kern_securelevel_enable=NO. Any other thoughts? g. Yes, this is a not-quite-yet resolved side effect of GEOM that is due to be fixed any minute now. Geom is overly protective when partitions are open and mounted. For example, if ad0s1a is open, you cannot open ad0s1 or ad0 for read/write since they overlap the ad0s1a device which has an exclusive lock on it. This is a problem for installing boot code like you were trying to do at the start of the thread. The old partition code had some huge holes in it that meant it was really easy to do bad things, and over time things started taking advantage of it. There are several things you can do. 1) Boot off floppy or fixit cdrom or something and fix it. 2) use the NO_GEOM kernel compile option 3) Or try this hack: ftp://ftp.jurai.net/users/winter/patches/geom-foot.patch This adds a kern.geom.allow_foot_shooting sysctl. #3 is the most useful option at the moment because it enables you to turn on the sysctl and do the update, but still give GEOM a good workout and test in the real world. It is new in 5.0 and it would be nice to get every bit of real-world testing possible. NO_GEOM is fairly likely to not be in 5.1, so we need to get any more suprises found and taken care of. If you are feeling like some excitement, talk with [EMAIL PROTECTED] and see if he has patches for adding disklabel bootcode write support in a usable state for testing yet. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Technical Differences of *BSD and Linux
[dropped linux-kernel] Bill Studenmund wrote: On Fri, 24 Jan 2003, arief_mulya wrote: 4. Any chance of merging the very best part of each kernel? 5. Or is it possible to do so? No, I don't forsee merging. der Mouse pointed out the GPL issue, which is one where I think the BSD and Linux folks will just agree to disagree. Besides some big issues of ideology, there is also the issue of some strong personalities in the various camps that simply do not get along well with the other strong personalities in other camps. Some of the lines of division just happen to keep these people apart and further away from each others throats. Trying to do mergers in the past (yes, it has been tried) has caused collisions with consequences that lingered for quite some time. Past experience has shown that failed merger attempts have been damaging because the resulting bad feelings interfere with cooperation and cross-pollination for some time. To the original poster: This kind of posting is very unhelpful. If you want to learn about the different systems, subscribe to some of the mailing lists for each group, and watch for a while so that you can build your own understanding of what is going on in the respective groups. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: patch to remove random #define MIN/MAX implementations from around the kernel
Matthew Dillon wrote: :On Tue, Jan 21, 2003 at 07:25:44PM -0800, Matthew Dillon wrote: : This patch is going to go in on the weekend unless someone has any : worthwhile nits about it. It was submitted by Hiten Pandya. : : Index: contrib/dev/oltr/if_oltr.c : : Index: contrib/ipfilter/netinet/ip_proxy.c : : Index: netinet6/nd6.c : :You shouldn't modify vendor code for minor purposes. : :Kris The vendor code in question has been modified *extensively* since it was imported, (and of course I would give Darren a head's up in regards to ipfilter). Unless you have a more specific reason I don't really think a general blanket statement is sufficient reason to not do the commit, at least not in this case. Didn't we explicitly make it like this? ie: you'd be backing out a previous set of intentional commits by doing this... Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: devd, crunchgen, C++, and /rescue
Tim Kientzle wrote: I'm slowly tracking down the remaining minor issues with my all-static crunchgen-ed /rescue implementation. This includes pretty much everything from /bin and /sbin, as well as a few useful tools from /usr/bin and /usr/sbin. However, I've just run into an ugly problem. Specifically, devd is now written in C++ (as of a few weeks ago) and crunchgen does _not_ play well with C++ programs. For now, this means that devd will not be in /rescue. I'm not entirely happy about this. Policy question: Is C++ considered acceptable in /bin and /sbin? (I presume so, since Warner's doing it.) Technical Question: Does anyone know how to get crunchgen to play nicely with C++ programs? (I've tried a couple of simple changes to the generated makefile with no success.) Usability Question: How necessary is devd likely to be for people recovering from serious disaster? (Imagine that /usr, /bin, and /sbin are all broken. Will some people require devd to get a network adapter or hot-plug CD-ROM running, for example?) Personally, I dont think it is a big deal. /rescue is for the case where normal system services are hosed and you want as little running as possible, and the only things that run are what you specifically run. I cannot think of anything that devd might do that a sysadmin who is competent enough to rescue a dead system that doesn't have /usr mounted couldn't do also. I'd prefer to run dhclient by hand anyway thank you. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Compaq-prolient ML370/smp problem
Danny Braniss wrote: hi, this box works ok with non SMP kernel, but the SMP gets stuck in APIC_IO: Testing 8254 interrupt delivery Yes, unfortunately we know what the problem is. For some reason, both the 8254 timer *and* the RTC are not connected to the IO APIC. We have a hack that tests the 8254 timer and does a workaround, but we do not yet have a workaround for the RTC (real time clock) interrupt not working. Remind me in a few days. We have this problem at work and I'm tinkering with something that should probably work around it enough to get going. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: One Filesystem vnode operations declare problem.
ouyang kai wrote: From: Peter Wemm [EMAIL PROTECTED] Undefined. The bubble sort that orders these could leave it in any state. Woo. thank you. In mi_startup(), the kernel will register those device/modules, and excute the 'func' declared by SYSINIT, right? Yes. I think the kernel will have not real / filesystem until kernel completes the SI_SUB_ROOT_CONF register. How the kernel get those info we stored in / filesystem, such as 'loader.conf' and part of '/etc/rc'? The kernel use the BIOS model? I am puzzled. /boot/loader runs before the kernel and uses the BIOS to access the device. It passes information to the kernel through metadata, environment variables and other metadata. The kernel and any kernel threads created before ROOT_CONF do not have access to file system space. The init process begins by setting its / to the root vnode, effectively chrooting to the recently mounted file system. Then that process can exec /sbin/init and /sbin/init can run /etc/rc. But in 5.0, both SI_SUB_DEVFS and SI_SUB_DRIVERS(GEOM) will be loaded before the SI_SUB_ROOT_CONF. Both of them will initial, specail GEOM, so they will create special device in '/dev'. why can we see those device after the system is normal. For example: mount /dev/ad0s2e /usr/share1 mount /dev/ad0s1f /usr now, we can not see the '/dev/ad0s2e' filesystem context. devfs has two parts. The first is a device registry of sorts.. things like geom tell devfs that there will be a node called ad0s2e. Later on it also provides a mountable file system to export that data to the user processes. This means that geom and drivers create nodes long before there is a root file system and devfs remembers them for when /dev is finally mounted. No, unionfs is a stacked file system. For example, you could create a read/ write layer stacked on top of a cdrom. This would allow you to create files which would end up in the top layer, but unmodified files could be read from the bottom layer. If you rm a file, a whiteout record gets created to make it appear that the file got deleted from the cdrom etc. Unfortunately, this works better in theory than in practice due to many layering problems in our kernel and VM system that are still work in progress. That is a whole different topic though. Now, I have a more understanding about it. If I want to learn more about that, where can I get info from internet? Could you commend some articles or documents about that? Do some searches for John Heidemann and the Ficus project. There is no VOP_SET. I think you mean VFS_SET(). This connects the file system itself to the kernel. VNODEOP_SET() connects the vnode descriptions to the kernel. Sorry, I write a mistake. ufs/ffs are a mini-filesystem-stack. ffs provides the on-disk infrastructure, while ufs is layered on top of it to provide name space. This is quite well hidden though and is mostly a behind-the-scenes thing. At one point there was a log structured file system that shared a lot of code this way. The file systems provide multiple operation vectors due to the way that device and named pipe nodes exist. For ufs/ffs, the actual connection point for /dev/ttyv0 (for example) lived on disk. When the user opened it, the file system would substitute the normal file based vectors for the specfs vectors. That way, the vnode would behave like a device. And the same goes for the fifo (named pipe) nodes. For FreeBSD 5.0, we have a seperate file system for /dev, so the specfs nodes in ufs/ffs are not normally used. But they do still work and are sometimes used for jail(8) environments. Yes, I know in 5.0, we can use 'dev' filesystem. Based on DEVFS, when we create device, we usually call 'make_dev', in this function, we can create device in DEVFS through 'devfs_create_hook'. Or we destroy device in DEVFS through 'devfs_destroy_hook'.I think the DEVFS is special for 'device', I do not know why the DEVFS support both 'normal' and 'specfs'. I guess it we use normarl file operation such as 'ls' or 'find'in '/dev/', it use the 'normarl' vop; we use 'devfs rules', it use the 'special' vop, right? If I guess right, but the kernel how to know it should use which vop? It is up to the file system to get it right. The normal procedure is to use namei() which does VOP_LOOKUP() calls to each file system. As a side effect of doing a lookup, the file system itself returns a new vnode pointer that corresponds to the name being looked up. If we are using a ufs/ffs file system then the fs code will set the operations vector in the vnode iself to point to either the specfs or regular vop entries. See v_op in struct vnode. For devfs and the seperate /dev case it is similar.. for devfs there are two types of vnodes.. The first is the special device type (devfs_specop_entries[]), and the second is the vnodes that are used for traversing the directory structure (directory files, symlinks etc
Re: One Filesystem vnode operations declare problem.
ouyang kai wrote: From: Peter Wemm [EMAIL PROTECTED] The name of the macro is a little strange, that is more of a historical relic where we used to declare these things in something called a 'linker set'. These days it is handled by a SYSINIT() function that registers the vnode ops. I know in mi_startup(),the kernel will try to load the modules registered by SYSINIT. I think its order is: firstly according 'sysinit_sub_id'; secondly,if the 'sysinit_sub_id' are the same, it is accord 'sysinit_elem_order', right? I wonder if both of them is the same, the kernel will try to load which. For example: SYSINIT(nameA, SI_SUB_DRIVERS, SI_ORDER_FIRST, initA, NULL); SYSINIT(nameB, SI_SUB_DRIVERS, SI_ORDER_FIRST, initB, NULL); which do the kernel load firstly? Undefined. The bubble sort that orders these could leave it in any state. Our vnode op system is fully dynamic. We can create new VOP_xxx() functions on the fly. But for this to work, they need to be registered and assigned an index number in the system vectors. The act of referencing a foo vector in the xxx_opv_desc table adds support for a VOP_FOO(). For example, suppose we have some remote file system loadable module that supports remote file copies. That filesystem could introduce VOP_COPYFILE() that would cause the file to be copied on the server, rather than the source file being read by the client and then copied back to the new file. We could then load another module that adds a copyfile(2) syscall that calls VOP_COPYFILE(). And because of the vnode stacking system and the VOP_DEFAULT() vectors, we could even mount union fs's over the top of this hypothetical file system, even though at the time that unionfs was compiled there was no VOP_COPYFILE operation to pass down the stack. union fs's means what? FreeBSD's UFS is result that union of UFS and FFS, right? No, unionfs is a stacked file system. For example, you could create a read/ write layer stacked on top of a cdrom. This would allow you to create files which would end up in the top layer, but unmodified files could be read from the bottom layer. If you rm a file, a whiteout record gets created to make it appear that the file got deleted from the cdrom etc. Unfortunately, this works better in theory than in practice due to many layering problems in our kernel and VM system that are still work in progress. That is a whole different topic though. Quite a while ago, the kernel used to have a static list of supported VOP_* calls. This has not been the case for quite some time now. Any file system can create any VOP_* that it likes. Based on your words, I still do not understand those difference among those VOP_SET. :(. I think your viewpoints is that the number of VOP_SETs and the function of VOP_SETs is decided by the filesystem, right? I want to know the general purposes of those VOP_SETs. For example: in FFS: VNODEOP_SET(ffs_vnodeop_opv_desc); I think it is normal operation vectors. VNODEOP_SET(ffs_specop_opv_desc); I think it is special operation vectors. But I do not know its purpose. VNODEOP_SET(ffs_fifoop_opv_desc); I think it is FIFO operation vectors. Why do those three VOP_SETs have many repeated defines? Or All my thought is wrong? There is no VOP_SET. I think you mean VFS_SET(). This connects the file system itself to the kernel. VNODEOP_SET() connects the vnode descriptions to the kernel. ufs/ffs are a mini-filesystem-stack. ffs provides the on-disk infrastructure, while ufs is layered on top of it to provide name space. This is quite well hidden though and is mostly a behind-the-scenes thing. At one point there was a log structured file system that shared a lot of code this way. The file systems provide multiple operation vectors due to the way that device and named pipe nodes exist. For ufs/ffs, the actual connection point for /dev/ttyv0 (for example) lived on disk. When the user opened it, the file system would substitute the normal file based vectors for the specfs vectors. That way, the vnode would behave like a device. And the same goes for the fifo (named pipe) nodes. For FreeBSD 5.0, we have a seperate file system for /dev, so the specfs nodes in ufs/ffs are not normally used. But they do still work and are sometimes used for jail(8) environments. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: One GNU ASM syntax problem
kai ouyang wrote: I do not know the difference between + and =. why? Thank you, I got it from 'info gcc'. It is the reason that Extended asm supports input-output or read-write operands. Use the constraint character `+' to indicate such an operand and list it with the output operands.. Also be aware that different versions of gcc treat this differently. We use gcc-2.95 on FreeBSD 4.x and gcc-3.2.1 on FreeBSD 5.x. Those versions are much more sensitive and have stricter requirements than gcc-2.8 and earlier. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: maxusers and random system freezes
Ronald G. Minnich wrote: On Thu, 5 Dec 2002, David Schultz wrote: Linux used to do that, but AFAIK it doesn't anymore. Linux puts kvm at 0xc000, kernel at physical 0x10, etc. There was a time when you could address all of physical memory just by direct-mapping the PTEs, since base of 0xc000 means KVM space of 0x4000. Those days are gone. Sort-of. They now use a milti-tiered memory pool system. The first block is direct mapped in using 4MB pages. That works out to something like 930MB or so. The balance (they have a 1GB KVA space too) is pageable to allow the kernel to access memory outside of the first 930MB (or whatever the exact amount is). What linux does that I find interesting is that they agressively *move* user pages in order to get best use of that 930MB pool. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: One Filesystem vnode operations declare problem.
kai ouyang wrote: Hi, everybody, I have some questions about FS vnode operations. I found the filesystems always declare vnode operations by VNODEOP_SET more than once. For example: In DEVFS: VNODEOP_SET(devfs_vnodeop_opv_desc); VNODEOP_SET(devfs_specop_opv_desc); In FFS: VNODEOP_SET(ffs_vnodeop_opv_desc); VNODEOP_SET(ffs_specop_opv_desc); VNODEOP_SET(ffs_fifoop_opv_desc); Why? Why can not the kerenel use only devfs_vnodeop_opv_desc or ffs_vnodeop_opv_desc? Another words, I want to know the difference among those VNODEOP_SET in one filesystem. The name of the macro is a little strange, that is more of a historical relic where we used to declare these things in something called a 'linker set'. These days it is handled by a SYSINIT() function that registers the vnode ops. Our vnode op system is fully dynamic. We can create new VOP_xxx() functions on the fly. But for this to work, they need to be registered and assigned an index number in the system vectors. The act of referencing a foo vector in the xxx_opv_desc table adds support for a VOP_FOO(). For example, suppose we have some remote file system loadable module that supports remote file copies. That filesystem could introduce VOP_COPYFILE() that would cause the file to be copied on the server, rather than the source file being read by the client and then copied back to the new file. We could then load another module that adds a copyfile(2) syscall that calls VOP_COPYFILE(). And because of the vnode stacking system and the VOP_DEFAULT() vectors, we could even mount union fs's over the top of this hypothetical file system, even though at the time that unionfs was compiled there was no VOP_COPYFILE operation to pass down the stack. Quite a while ago, the kernel used to have a static list of supported VOP_* calls. This has not been the case for quite some time now. Any file system can create any VOP_* that it likes. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Shrinking /(s)bin: A Proposal
Lamont Granquist wrote: RedHat systems have only two statically linked binaries in their systems and it is one of the things that I viscerally hate about RedHat. You have to look on another system or lookup on the net which shell to use instead of /sbin/init and then play around with a massively minimal set of things you can do to the filesystem in order to fix your system. I hate that. I particularly hate that because whenever it comes up I just did something stupid enough to nuke my libc and I'm not a happy camper. I want to just boot into single user and fix the system. Also, the lack of 'mv' being statically linked is what caused me to learn so much about how to recover from libc being nuked on RedHat boxes. Its good to have any common utilities people might think of to use to update libc to be statically linked. Of course I can see where on early-90s era systems, or on embedded systems, you'd want to go with the smallest /[s]bin you can get in which case the buildworld option makes perfect sense. I have no use for this option though. I'm happy to gleefully burn through the 20MB of disk space. 20MB of disk space is cheap these days -- 99% of FreeBSD users will never notice that it is gone... Have you been actually reading this? peter@daintree[2:55pm]/-101 cd /rescue peter@daintree[2:55pm]/rescue-102 file rescue rescue: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 5.0, statically linked, stripped Note: Static linked. peter@daintree[2:55pm]/rescue-103 file sh sh: symbolic link to rescue peter@daintree[2:55pm]/rescue-104 file cp cp: symbolic link to rescue peter@daintree[2:55pm]/rescue-105 file init init: symbolic link to rescue Adding things like mv etc to this is *trivial*. If you get hosed, and have to drop into single user, we'll arrange it so that $PATH has got /rescue at the beginning. Since adding things like mv to the static linked crunched binary is trivial, you'd actually be seeing an improvement over the bloat case. On Fri, 15 Nov 2002, Peter Wemm wrote: Robert Watson wrote: On Thu, 14 Nov 2002, Doug Rabson wrote: : I'm open to patches for building /[s]bin as dynamic. If you have : time and can coordinate with [EMAIL PROTECTED] to build the patch, I : would appreciate it. % make NOSHARED=NO buildworld No patches necessary. We do this all the time at work, and it works fabulously. I do this for disk based systems that have / and /usr on the same file system too. To do it right for split root/usr installations requires a few patches though. The rtld and the libs required for /[s]bin need to move to / an d compat symlinks created from /usr. A suitable crunchgen'ed binary for /recover would be useful too. I had some local patches that did a subset of this -- moved ld.so to /lib , as well as installing shared libraries to /lib instead of /usr/lib for th e base system. I seem to recall I also had to tweak some defaults in ld.so or rtld or the like, though. I agree that the right path to support full y dynamic systems properly is to adopt the approach taken by NetBSD: provid e a decent /recover with crunchgen, etc. I do use fully dynamic stuff for some local test boxes, makes upgrading libc code for development purposes much easier, as well as supporting dlsym() for /sbin, which is very usefu l in my environment. For what its worth: peter@daintree[4:55pm]/rescue-222# ls -sh@dumpfs@ ipmon@ mount_portalfs@ rm@ [@ dumpon@ ipnat@ mount_std@ rmdir@ adjkerntz@ echo@ kenv@ mount_udf@ route@ atacontrol@ ed@ kill@ mount_umapfs@ routed@ badsect@expr@ kldconfig@ mount_unionfs@ rtsol@ camcontrol@ fdisk@ kldload@mv@ savecore@ cat@fdisk_pc98@ kldstat@natd@ setfacl@ ccdconfig@ fsck@ kldunload@ newfs@ sh@ chio@ fsck_ffs@ ldconfig@ newfs_msdos@shutdown@ chmod@ fsck_msdosfs@ ln@ nfsiod@ slattach@ clri@ fsdb@ ls@ nos-tun@sleep@ comcontrol@ fsirand@mca@pax@spppcontrol @ conscontrol@gbde@ md5@ping@ startslip@ cp@ getfacl@mdconfig@ ping6@ stty@ date@ gpt@mdmfs@ ps@ swapon@ dd@ growfs@ mkdir@ pwd@sync@ devd@ hostname@ mknod@ quotacheck@ sysctl@ devfs@ ifconfig@ mount@ raidctl@test@ df@ init@ mount_cd9660@ rcorder@tunefs@ dhclient@ ip6fw
Re: Shrinking /(s)bin: A Proposal
Robert Watson wrote: On Thu, 14 Nov 2002, Doug Rabson wrote: : I'm open to patches for building /[s]bin as dynamic. If you have : time and can coordinate with [EMAIL PROTECTED] to build the patch, I : would appreciate it. % make NOSHARED=NO buildworld No patches necessary. We do this all the time at work, and it works fabulously. I do this for disk based systems that have / and /usr on the same file system too. To do it right for split root/usr installations requires a few patches though. The rtld and the libs required for /[s]bin need to move to / and compat symlinks created from /usr. A suitable crunchgen'ed binary for /recover would be useful too. I had some local patches that did a subset of this -- moved ld.so to /lib, as well as installing shared libraries to /lib instead of /usr/lib for the base system. I seem to recall I also had to tweak some defaults in ld.so or rtld or the like, though. I agree that the right path to support fully dynamic systems properly is to adopt the approach taken by NetBSD: provide a decent /recover with crunchgen, etc. I do use fully dynamic stuff for some local test boxes, makes upgrading libc code for development purposes much easier, as well as supporting dlsym() for /sbin, which is very useful in my environment. For what its worth: peter@daintree[4:55pm]/rescue-222# ls -sh@dumpfs@ ipmon@ mount_portalfs@ rm@ [@ dumpon@ ipnat@ mount_std@ rmdir@ adjkerntz@ echo@ kenv@ mount_udf@ route@ atacontrol@ ed@ kill@ mount_umapfs@ routed@ badsect@expr@ kldconfig@ mount_unionfs@ rtsol@ camcontrol@ fdisk@ kldload@mv@ savecore@ cat@fdisk_pc98@ kldstat@natd@ setfacl@ ccdconfig@ fsck@ kldunload@ newfs@ sh@ chio@ fsck_ffs@ ldconfig@ newfs_msdos@shutdown@ chmod@ fsck_msdosfs@ ln@ nfsiod@ slattach@ clri@ fsdb@ ls@ nos-tun@sleep@ comcontrol@ fsirand@mca@pax@spppcontrol@ conscontrol@gbde@ md5@ping@ startslip@ cp@ getfacl@mdconfig@ ping6@ stty@ date@ gpt@mdmfs@ ps@ swapon@ dd@ growfs@ mkdir@ pwd@sync@ devd@ hostname@ mknod@ quotacheck@ sysctl@ devfs@ ifconfig@ mount@ raidctl@test@ df@ init@ mount_cd9660@ rcorder@tunefs@ dhclient@ ip6fw@ mount_ext2fs@ rcp@umount@ disklabel@ ipf@mount_msdosfs@ realpath@ dmesg@ ipfs@ mount_nfs@ reboot@ domainname@ ipfstat@mount_ntfs@ rescue* dump@ ipfw@ mount_nullfs@ restore@ peter@daintree[4:55pm]/rescue-223# ls -l ./rescue -rwxr-xr-x 1 root wheel 2725532 Nov 15 16:52 ./rescue* peter@daintree[4:55pm]/rescue-224# ./sh # ./ls -l ./rescue -rwxr-xr-x 1 root wheel 2725532 Nov 15 16:52 ./rescue That's 2.7M to replace roughly 30M of /bin + /sbin. Warner quoted some numbers for a dynamic / case. I think we'd be looking in the order of a few megs of shared libs, plus about 2MB for /bin+/sbin. ie: a reduction from ~30M to somewhere in the area of about 7MB, and that includes the crunched static /rescue/*. This might actually fit on my SMP Pentium-90 box that was installed late 1995. :-) I didn't spend much time on the crunch stuff, I was mostly curious to see how it worked and what it could do. I was suprised at how easy it was to produce a binary. I haven't polished it up and haven't done any bmake glue. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [hardware] Tagged Command Queuing or Larger Cache ?
David Schultz wrote: Thus spake Peter Wemm [EMAIL PROTECTED]: Actually, not even then. Modern IDE drives only write entire tracks at a time. If you modify a single sector, then the drive has to read the entire track into the buffer, in-place edit the sector, and then rewrite the entir e track. [...] And that completely blows FFS's assumptions out of the water. And what is sad is that many SCSI disks are similar these days. But not all of them (I'm told). I've heard this before. It would be very useful to have information about which drives have this misfeature, but I guess it isn't the sort of thing that hard drive manufacturers like to advertise. Does anyone have any data on track-writing drives? IBM used to claim it as a feature and have patents on it. As best as I can tell, all IDE disks have it since about 1999 or so. Quantum and IBM certainly did, as it was a way of getting the drive capacity up and reducing the cost. One way that you can tell is by seeing how big the slowdown is when write caching is turned off and whether you see the same slowdown slowdown regardless of any sector interleaving. ie: if writing to every 10th or 20th (or whatever) sector is just as slow as writing to every sector with write caching turned off, then you have a track-write drive. This is because every single sector write causes the entire track to be written. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [hardware] Tagged Command Queuing or Larger Cache ?
Daniel O'Connor wrote: On Tue, 2002-10-29 at 02:40, Chuck Robey wrote: Personally I find that no HD manufacturer has a good reputation - they have all made trashy drives at one point. Give the general time it takes for problems to surface vs product lifetimes makes deciding what to buy a PITA :( No, I'd take issue with that, hitting on all HD mfrs in general, it has more to do with the technology, and the focus of the market it's aimed at. In general, SCSI drives have a far better rep than the IDE drives. That probably has to do with the market sector they focus on. With one exception (a heat problem I probably must blame on myself doing some learning) I've had no problems with scsi drives, and I beat hell out of them. They sure do have a better rep. but they DO cost 4x as much :) (Not including a controller) I guess if you *must* run IDE, then run raid arrays. If you don't run either, then you can't complain if you buy the cheapest and don't get the best reliability. Indeed, though in general I find it pretty hard to justify SCSI prices in the particular application we have. A seperate parallel thread is running on -alpha (bad!), where the question of whether tagged queueing on IDE was safe or not. === (I wrote:) Peter Jeremy wrote: The safe states are: tagging caching or no-caching (which is slow). Actually, not even then. Modern IDE drives only write entire tracks at a time. If you modify a single sector, then the drive has to read the entire track into the buffer, in-place edit the sector, and then rewrite the entire track. As you can imagine, this violates the basic assumptions of FFS and softdep. They assume that only sectors that are written to are at risk, and do all their ordering based on that assumption. But the assumption is completely bogus. Even with no-caching it doesn't work because if the drive loses power after only having written half of the track, then you risk losing the rest - the track is written from wherever, and not any index marks. ie: the track is just as likely to overwrite the second half of the sectors first, and when you lose power, you have two copies of the first half of the sectors. Basically you have to assume that the entire track and all of the nearby sectors could get lost or trashed. And that completely blows FFS's assumptions out of the water. And what is sad is that many SCSI disks are similar these days. But not all of them (I'm told). Basically if you get a power failure, you are totally screwed. softdep will save you from a hard OS level lockup/reset though. === Personally, I find that the sub-5ms seek time on scsi drives contributes a fair bit to the percieved speed of the box under load. Without serious load though, it is very hard to tell the difference between scsi and ide. Most of the recent scsi drives I've used are between about 4.1ms through 4.5ms seek vs ide drives at between 8ms and 12ms seek time. What IDE calls 'tagged queueing' seems to be little more than allowing ide drives to release the bus while they go and do something. It dramatically improves the bus contention when you have a pair of drives on a single ide channel.. almost to the point that there is little or no degradation when you are hammering both drives at once. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [hardware] Tagged Command Queuing or Larger Cache ?
.@babolo.ru wrote: Daniel O'Connor wrote: As you can imagine, this violates the basic assumptions of FFS and softdep. They assume that only sectors that are written to are at risk, and do all their ordering based on that assumption. But the assumption is completely bogus. Even with no-caching it doesn't work because if the drive loses power after only having written half of the track, then you risk losing the rest - the track is written from wherever, and not any index marks. ie: the track is just as likely to overwrite the second half of the sectors first, and when you lose power, you have two copies of the first half of the sectors. Basically you have to assume that the entire track and all of the nearby sectors could get lost or trashed. I usually lose 4..8 sectors cluster on fast power down on IBM IDE drives. Repairable. Maybe so, but FFS is written with the assumption that only the sector being written is at risk. Even losing 4-8 sectors blows that out the window if it happens to be metadata. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [ GEOM tests ] vinum drives lost
Bruce Evans wrote: On Fri, 4 Oct 2002, Poul-Henning Kamp wrote: Worst case you will have the option to use: options NOGEOM options vinum A NOGEOM option would be as acceptable as a NOFFS option for turning off forcing of the one true file system down everyone's throats. Part of the problem there is a weakness in config that I've threatened to fix on more than one occasion. We do not have a way to have options default to on and let people turn the option off. Negative options (options NOFOO) are a poor substitute. In the past, a couple of things were unifdefed that might have been better served as being 'default to on' options or drivers. This of course is ignoring the issue of geom vs the disklabel code. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Disk space over 1 TB
Attila Nagy wrote: Hello, Just a quick question: with the recent (past 1-2 months) commits made to CURRENT, is it possible to use more than 1 TB of disk space? (this would be a hardware RAID array, accessed via SCSI as a single ID, so no ccd, vinum or other magic) The i386 port uses the generic disklabel code, which has 32 bit logical block addressing, which means that the partitions themselves are limited to 1TB or so. The GEOM work-in-progress is 64 bit clean internally and has at least one 64 bit clean partition method (EFI, from ia64) but that wouldn't be usable on boot disks without a fair bit of bootblock work and the userland tools to produce it are very raw at this stage. But one could theoretically use a 64 bit EFI layout on a large external raid and boot from a smaller disk. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Disk space over 1 TB
Wilko Bulte wrote: On Thu, Sep 26, 2002 at 10:59:21AM -0700, Peter Wemm wrote: Attila Nagy wrote: Hello, Just a quick question: with the recent (past 1-2 months) commits made to CURRENT, is it possible to use more than 1 TB of disk space? (this would be a hardware RAID array, accessed via SCSI as a single ID, so no ccd, vinum or other magic) The i386 port uses the generic disklabel code, which has 32 bit logical block addressing, which means that the partitions themselves are limited to And the Alpha port? I have some multi TB disk arrays around at work that I can play with :) Yes. If you can figure out how to construct an EFI GPT partition structure on it, 'GEOM' will detect and use it via sys/geom/geom_gpt.c. Note that /sbin/gpt needs lots of work. Right now the only way to do things is to use fdisk to initialize it and convert it to gpt. This turned out to be rather painful, but I eventually convinced it to do what I needed. It shouldn't be all that hard to finish it off. The biggest problem I had was that GEOM didn't have any way to do this live. I had to create the partitions on a non-geom kernel, then reboot to see if it worked etc. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
Maxime Henrion wrote: Kris Kennaway wrote: On Fri, Sep 06, 2002 at 05:55:47PM -0700, Maxime Henrion wrote: I've got a very similar patch which I believe to be a bit more complete because it also updates the MACHINE_CPU variable which lists the features available on a particular CPU. I attach it to this mail. Oops, I forgot that part. How about sse2 though? Forgot that one. Here is an updated patch. I'm quite sure that on the Intel side, only the pentium 4 have sse2, but I don't know if any AMD chip supports it yet. The attached patch only adds it for p4's. Both of the Hammer cpus support SSE2 FWIW. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 64 bit API/ABI changes proposal for -current
Matthew Dillon wrote:
About 34 system calls need work (with time changes), approximately
16 without time changes. I've included a summary at the end.
The questions before us:
* What to do about time representation.
* Whether to create a new syscall vector or use the existing
vector.
I have thought long and hard about this and I now believe that we
should keep our existing vector, even though it's become a real mess,
at least through the release. This will also allow us to convert
to a 64 bit time representation without blowing anything up. The
original API calls would of course remain valid.
wait4() - wait464()
*stat() - *stat64()
getrusage() - getrusage64()
getfsstat() - getfsstat64()
*statfs() - *statfs64()
*itimer() - *itimer64()
select()- select64()
gettimeofday() - gettimeofday64()
settimeofday() - settimeofday64()
*times()- *times64()
adjtime() - adjtime64()
quotactl() - quotactl64()
Matt, I realize you have thought long and hard about this, but I want to
make a couple of points.
1) 32 bit i386 already has its fate sealed. AMD are switching to 64 bit,
and Intel are doing the same (either x86-64 or their own 64 bit environment,
depending on which rumors you listen to).
2) Many of these calls *are* 64 bit already on 64 bit platforms. Adding
an additional layer here just makes life harder when we 64 bit is the norm.
For example, get/settimeofday, *itimer, select, etc etc use timeval:
struct timeval {
longtv_sec; /* seconds */
longtv_usec;/* and microseconds */
};
and that, folks, is 64 bit on 64 bit platforms already.
3) 5.0 is not going to last till anywhere near year 2038. In the next year,
or two at tops, it is going to be perfectly clear what the future of common
64 bit hardware will look like
4) Changing time_t to 64 bit using long long on a native 32 bit platform
is a f*cking nightmare. I've tried this and it got very nasty very quickly.
5) Changing time_t to 64 bit is trivial on a native 64 bit platform. I
have done this on an ia64 machine. The sparc64 folks indicated they wanted
to do the same. Much of the work has been done already.
I worry that jumping in prematurely will leave us with a legacy issues that
will haunt us for year and years to come, while the linux folks laugh at
our pain and convoluted API's because they've already set their internal
time_t to 64 bit on their 64 bit platforms.
I urge folks to hold off just a bit longer so that we can get 5.x stable
and in shape and released without blowing up 50% of our ports due to long
long time_t problems. re@ is already having nightmares about 5.0, we do
not need this thrown into the mix yet. Especially when the right solution
will become more obvious as the 64 bit desktop machine dust settles.
Also, hackers@ is really not the place for this.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: 64 bit API/ABI changes proposal for -current
Matthew Dillon wrote: :4) Changing time_t to 64 bit using long long on a native 32 bit platform :is a f*cking nightmare. I've tried this and it got very nasty very quickly. This is not what I proposed. I proposed adding new system calls to completely and permanently fix all of our outstanding issues and then providing a compiler option to allow developers to select which API they want presented. Well, one thing that I would not be against is a clean divorce of the syscall layer and libc. That then gives us the freedom to implement alternative API selections etc at compile time pretty easily. I just really do not want to see this sort of thing turning up: time_t foo = time(0); printf(the time is %lld\n, (long long)foo); /* i386 compatability */ .. because that hurts our 64 bit platforms down the road when long long becomes 128 bit. intmax_t/%j etc has similar problems as it then takes the native 64 bit time type (long) and converts it to a synthetic 128 bit type. ie: %j and intmax_t etc are just as bad. My first exposure to a unix OS had some pretty horrific stat structure versioning and evilness (svr4). It was a real nightmare, except you never got to wake up and discover that it was all over. I am not against providing 64 bit extentions for 32 bit systems, but it really needs to be done so that it all becomes a giant NOP when on native 64 bit systems. Something like the large-file-summit API extensions that all magically go away after the transition period or when you get a chance to do a total ABI breakaway. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 64 bit API/ABI changes proposal for -current
Matthew Dillon wrote:
Well, then what we want is a new syscall vector, duplicate libraries,
and a compiler option, and leave all the function names the same
(which means no bintime but allows us to retain everything else).
-current would release supporting both with the compiler option
defaulting to --unix32 on the IA32 and --unix64 on 64 bit platforms,
and then down the line the compiler option would default to --unix64
on all platforms, and then down the line a little more the original
syscall vector would become a compatibility option that most people
leave out.
Argh! This is way overkill. It is *not* what I was advocating.
The time to do this is when we bump libc's major number, not duplicating
libraries etc. That's a worst case outcome especially when it isn't needed.
It would be far less disruptive to add an additional group of 64 bit
time aware API's that are optional and portable. Leave the standards-defined
API's alone.
For example, in your previous suggestion, you had:
typedef int64_t time64_t;
struct timeval64 {
time64_ttv_sec;
int64_t tv_frac;/* N/2^63 fractional */
};
#ifdef __UNIX_API64__
#define timeval timeval64
#endif
You simply *cannot do this* and remain posix compliant on 64 bit machines.
We do not just go and change posix api's just for the sake of leaving out a
64 in a name. If you are going to modify code to use tv_frac, then you
may as well refer to it in a 'struct timeval64' and be done with it.
I suspect there would be far less confusion if they were not named so closely
to their standardized counterparts.
Changing code to work with --unix64 on 32 bit systems becomes useless
when we have 64 bit native systems, because we then need to un-port it..
(remember --unix64 changes struct timeval.tv_usec to .tv_frac, so code that
is cleaned to work on --unix64 will no longer compile on a native
64 bit posix compliant environment)
Maybe I'm getting all upset about nothing, but you are scaring the hell
out of me so far.
The advantage of all of this is that the 32 bit code stays intact and
compatible in both source and binary forms, which means no further
disruption of -current, just a lot of ABI work on my part. I already
did a dry run of the libc changes necessary and given the chance to
adjust things incrementally (which can be done with this methodology),
it's a lot of grunt work but nothing that I couldn't do in a few weeks.
Well, I'd like to see a working prototype before anything is committed.
Changes in this area are of massive importance to the whole project, so we
*must* get it right and agreed apon, or leave it alone. It would also be
really good if you could get some buy-in from the other *bsd/linux folks.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: More dynamic KVA_SPACE
mark tinguely wrote: Another interesting processor family is the AMD x86-64 ClawHammer. I do not know the progress the FreeBSD/x86-64 project. I would imagine the major difficulty will be getting a running compiler. Nope, the compiler is already pretty robust. I just wish AMD added an 8K page size so the Page Table Maps did not eat so much memory. It would have been nice, yes. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Ultra320 drivers?
Lars Eggert wrote: This is a cryptographically signed message in MIME format. Peter Wemm wrote: Jonathan Lemon wrote: I have an IBM box that has a dual LSI 53c1030 controller on the motherboard. Our SYM driver doesn't appear to have support for this device; under Linux it is supported by a Fusion/MPT driver from LSI. Any chance of getting a driver for this chip? I have an IA64 box with a 1030 as well. :-/ We just got a bunch of Dell machines that have this controller as well. Any news about support in sym? No, you want the 'mpt' driver that Matt Jacob recently committed. The 1030 has nothing in common with sym. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: top shows all zeroes.
Patrick Thomas wrote: ok, after 2+ days, for no discernible reason I now have real top stats back. This has occurred within the last 20 minutes, and I have done nothing at all on the system save normal operation. vmstat -i now tells me: # vmstat -i ... rtc irq8 479105 2 ... The 497105 number is steadily rising ... and now, about 30 mins later I am at: rtc irq8 938264 4 --pt This has happened before. For some reason, the RTC stops sending the 128Hz statclock (statistics clock) interrupts. One way to unwedge that in the past was to break into ddb and do a 'show rtc' command.. but that is hardly a solution. I thought we had solved this problem. APM however is a known culprit for causing badness here. On Mon, 26 Aug 2002, Lars Eggert wrote: Patrick Thomas wrote: Now, when I repeat vmstat -i, all of these numbers (or rather, all of the large numbers) increase _except_ for `rtc irq8`. interrupt total rate mux irq114851 12 ata0 irq14 94219240 atkbd0 irq1 399 1 fdc0 irq6 2 0 ppc0 irq7 1 0 clk irq039123100 Total 138595354 Large ones increasing, too, but I don't seem to have rtc. Further, regarding the APM conjecture, this is a server and (although I may be mistaken) does not have APM in the bios at all - I have also removed it from the kernel. dmesg tends to confirm the absence of APM. Mine's a laptop with APM enabled (BIOS + kernel). Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: CAM wiring, LUNs and duplicate wired entries
Kenneth D. Merry wrote:
On Mon, Aug 19, 2002 at 13:52:33 -0700, Terry Lambert wrote:
Kenneth D. Merry wrote:
I don't think that's the problem. I think the problem is that the device
at target 8 is getting identified to camperiphnextunit() as a wired devic
e,
when it isn't.
Try the attached patch and see if it fixes things for you.
I haven't tried compiling or running this, so beware.
That's some sneaky code. 8-). If this works and you commit it,
can you add an expository comment?
Maybe. Peter Wemm wrote the hardwiring code, and would likely be in a
slightly better position to explain it.
Actually, Justin implemented the original design, I just changed the
underlying mechanism that it uses. It still uses Justin's algorithms but
looks in different places for the source data. I sort-of understand it,
but it has been a while since I looked at it. :-)
Regarding the patch, yes, it does look like the 'hit = 0' should go inside
the loop. I would have done it more explicitly though, eg:
+++ cam_periph.c2002/08/20 06:48:50
@@ -332,3 +332,2 @@
unit = 0;
- hit = 0;
@@ -338,2 +337,3 @@
while ((i = resource_locate(i, periph_name)) != -1) {
+ hit = 0;
dname = resource_query_name(i);
The same problem is on -current too. It is probably worth changing hit
to wired since that is what it means.
I think this bug came from an earlier verson of the changes where this was
a multi-layered loop, and the resetting of 'hit' got moved too far out when
it collapsed to a single loop.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Increasing size of if_flags field in the ifnet structure [patch
Maxim Sobolev wrote: There is no much point in this patch, because it will increase size of struct ifreq, which means that no ioctl's from older apps will be accept ed anyway. Therefore, there is no difference between those two, while my approach is obviously cleaner. It does not increase size of struct ifreq. This is a union not a struct as You see. Oh, yes, you are obviously correct. However, I still wonder if your patch is endianless-safe. FWIW, for 4.x, endianness is not a problem since all the 4.x platforms are little-endian. For 5.x we should make a clean break. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Thread-safe resolver [patches for review]
Maxim Sobolev wrote: I also would like to hear from you whether or not you think that we need all those gethostbyXXX_r(3) functions. Yes. Because autoconf looks for them and will assume non-reentrancy if they are not present. Also, for source compatability with linux and solaris and just about everything else that implements this stuff. The expectation is that gethostbyXXX is non-safe and that gethostbyXXX_r is safe. If you can make the non_r versions safe then that is a bonus I guess. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: very minor vm_map.c typo ?
Dominic Marks wrote: Hello, In vm_map.c, in the vm_map_insert(...) function there is the following piece of code which checks if the addresses supplied to the function are valid: ** if ((start map-min_offset) || (end map-max_offset) || (start = end)) return (KERN_INVALID_ADDRESS); ** Specifically, I am interested in the final comparison. Is it possible that start == end could ever be correct? Do zero sized entries ever get inserted? (I don't see why you would ever wish to do this, please explain it to me if there is a reason). That would most likely be a case of defensive programming, especially in case of a sign wraparound problem or the like. No, inserting a zero-length map entry isn't valid and the defensive case comes for free. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Name service switch
Paul Khavkine wrote: Hi folks. Since FreeBSD currently lacks a fully functional NSS implementation why dont we use IRS from BIND ? Is there any problems with that ? We already have NSS in 5.x, which is just as functional as IRS. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: dump on mounted fs
Mark W. Krentel wrote: Dump still works on a mounted file system in Freebsd, right? That is, a write that completes before dump is started will be in the dump, even if the data is in memory? I don't mean writing to a file during the dump, that's a separate problem. I only recently learned that this doesn't work in Linux and I wanted to check that it's (still?) ok in Freebsd. Apparently, in the 2.4 Linux kernels, the buffer and page caches make it impossible for dump to always get the correct version of a file, even if there are no writes during the dump. It takes a umount before dump will see all of the changes (yuck). Anyone know about Solaris, IRIX, etc? Dump on a live FS is always risky. FreeBSD in 4.x and earlier will have up to about a 30 second delay before a write() makes it to physical disk. However, 5.x have snapshots where you can take a virtual snapshot of the file system device as it existed at the instant that you create it. You can then take a coherent dump that *will* be accurate. fsck uses snapshots in 5.x to do background fsck to reclaim lost resources. 5.0 should be released sometime this century. :-) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: resolver workaround conceptually possible ?
Patrick Thomas wrote: I am under the impression that at this time there is no workaround for the resolver problem - you are forced to reinstall or upgrade. I am curious though, is it at least conceptually possible that there could be a workaround ? If so, what would it entail ? Assuming that bind9 has been fixed, you could use bind9 for your local resolver and it will filter anything nasty out as a side effect of the fact that it always constructs replies, rather than caching a reply and forwarding the reply as-is to the resolver client (as bind8 does). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: swapoff?
David Schultz wrote: Thus spake Matthew Dillon [EMAIL PROTECTED]: Implementing swapoff is a bunch of grunt-work but not too hard in concept. Basically the work involved is this: Sounds like a plan, and not too tricky. Perhaps I'll see if I can figure it out when I have some free time. * Make a calculation to be sure that it is possible to turn off the swap device and not run the system out of VM. If it is not possible do not allow the swapoff. Can't you have a race condition here where you decide that you have enough space, and by the time you've deallocated half of the swapfile that's no longer the case? It seems like the correct thing to do in that case is abort the system call (which could be painful). Perhaps the best thing to do in this case is wait for vm_pageout_scan to kill a few pigs. One system I used to use years and years ago seperated this process into stages. The swap(1M) command could be used to enable, disable and 'weight' allocation to swap areas. The add was easy. 'delete' would cause the device to be attempted to be paged in, but if the system looked like it was going to run out of resources it would fail and stop right there. You could either turn allocation back on, or kill processes or wait for the pager catch up with moving stuff out to other swap spaces. When (if) it finally hit zero inuse, it would be deleted. It did manage multiple swap spaces as seperate entities with different fill levels etc [rather than one giant logical swap area], so doing it this way kinda made sense. I did actually use it once and it even worked. :-) (I cannibalized my /tmp file system and used it for swap for a project, and then turned it off and re-mkfs'ed it) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: swapoff?
Matthew Dillon wrote: We are not going to be doing any sort of weighting. It's an idea whos time has come... and gone again. It might have been useful 8 years ago but it is not useful today. Thank goodness! :-) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Large variables on stack
Terry Lambert wrote: Yar Tikhiy wrote: As I see, there are many spots in the FreeBSD userland sources where multi-kilobyte automatic variables (e.g., string buffers) are used. I've been taught that such variables would better be static or allocated on heap. So the following question comes to my mind: To stay portable to a reasonable degree, how large on-stack variables can be used? Depends on the system and the stack. Typically, if you want your code to be portable, you will use as little stack as possible: -- --- Space Stack size -- --- user 8MB (FreeBSD: 64MB) user thread 8K (or settable by user on pthread_create) user signals 40K[8K] (or settable via sigaltstack) kernel8K (max; usable is closer to 4K) -- --- Note that this assumes none of the stack is used elsewhere; in the kernel example, ther is slightly over 3K used, on average, by the time you get to run. FWIW; This isn't correct for -current anymore. We have about 7.6K of kernel stack now, and a guard page below it to force a double fault in case of an oveflow. The pcb is above the kernel stack now, and the user area is completely seperate. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: security problem in sysctl?
Bernd Walter wrote: On Fri, Jul 12, 2002 at 10:23:35PM +0100, void wrote: On Wed, Jul 10, 2002 at 02:30:19PM +0200, Bogdan TARU wrote: Hi guys, I have just rebooted my machine, and immediately after boot I have run 'sysctl -a' as an usual user. Well, in 'kern.msgbuf' I have found the whole master.passwd file, with combinations of usernames/passwords. Isn't that a security threat? Do you know how it got in there in the first place? I'd say that's the security problem. I would asume something like editing the passwd in single use mode. kern.msgbuf should be closed for non root users - IMO. The real problem is that a year or so ago phk added code that unconditionally logged the /dev/console output in the msgbuf so that it could be logged as /var/log/console.log. This is one of the unfortunate side effects. Another one is that /dev/console output blows away the boot messages. I've been looking for an excuse to disable and/or reimplement this properly for ages, but it never got urgent enough. IMHO, the console output should go to a seperate buffer [which is restricted to root-only], and uses a different output channel to syslogd. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: offtopic: low level format of IDE drive.
Julian Elischer wrote: this is not a 'reformat' what I want to do is an old-fashionned refomat/verify where the controller writes new track headers etc. The thing is, just about all IDE drives more than a few GB or so do 'track writing' and have no fixed sectoring or sector positioning. ie: each time you write a single sector to a track, it does a read-modify-write of *THE ENTIRE TRACK*. This is why we have to have write caching turned on for IDE drives to get decent performance. Without it, it essentially rewrites the entire track over and over and over again because it cannot fill its write buffer in order to write a contiguous block to completely replace what was there before. ie: each track is one giant physical sector with multiple logical sectors inside it. The really annoying thing is that most newer scsi drives do this too. The sad thing is that this makes softdep almost completely useless, because the basic assumption is that sectors that were not explicitly written to will not be touched. The problem is that this isn't the case, even with write caching turned off. Writing a single sector causes the drive to completely rebuild the track and all the sectors on it... in a different relative postition to what was there before. The resulting power off midwrite can cause an absolute mess in sectors *adjacent* to where soft updates was carefully writing to. This means that the 'power off failsafe' file system idea isn't possible with these drives. The only thing that can deal with this sort of failure mode is being willing to resort to 'newfs and restore' or a log structured file system (can you say LFS?). Get a UPS if you value the data. :-] Back to the topic for a moment.. In theory, dd if=/dev/zero of=disk bs=64k is as good as it gets for a low level format, on these drive. With write caching turned on, you are causing every single bit on the disk to be written to, including the metadata. And the dd if=/dev/disk of=/dev/null is the read verify. Some drives can have write verify turned on (I know of certain maxtor models) where the drive will read back the data and rewrite the entire track if necessary. Take the above with a grain of salt, I've never actually worked at a drive manufacturer. The only thing for sure is that all hard drives suck. :-) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: swap huge mem systems
Chuck Robey wrote: Nowadays, what with the price of fast memory at such low levels, I'm buying more memory than I really need, just because it's *so* cheap, the price has gone up before, and it's possible (maybe likely) that next year's popular new app will need the memory. I'm probably not alone in doing this. It's causing me to wonder about how much swap to allocate. I used to follow the rule that I dedicate twice as much disk memory to swap as I have RAM. Now, with my new system, I'm getting a gig of RAM, but it seems ridiculous to dedicate 2G of disk to swap. Under these conditions, what's the real bottom limit (if you have one gig of RAM) for how much swap you can get away with? One Gig? Less? Always have enough space reserved so that you can take a crashdump. You will be regretting it someday if you do not. Allowing for memory upgrades is a factor here too. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: offtopic: low level format of IDE drive.
Chris Knight wrote: Howdy, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mike Silbersack Sent: Tuesday, 9 July 2002 10:53 To: Peter Wemm Cc: Julian Elischer; John Nielsen; [EMAIL PROTECTED] Subject: Re: offtopic: low level format of IDE drive. [snip] So, this basically means that even a journalling filesystem wouldn't be much safer... how about battery backed up controllers - would those provide protection? (I suspect not, but maybe they're more sophisticated than I thought.) That's right - a journalled filesystem doesn't help. Nor does battery backed up controllers. If the drive has come back and told the controller that it has written the data, then the controller - battery backed up or not - will mark those sectors as written. If it's a caching controller, then the cache entries for those sectors will be returned to the free list pool. The only way a journalled filesystem would help is if during replay, it checked that all the sectors matched prior to the checkpoint; ie write out all the sectors after the last checkpoint, then check sectors prior to the last checkpoint. That way, the journalled filesystem would know that the data had been written correctly. Yes. Journalled filesystems are just normal file systems with a journal of recent *intentional* modifications to specific sectors. It cannot save you from modifications to *other* sectors as a side effect of writing. Does anyone have a detailed list of which SCSI drives do track writes rather than sector writes? You can find out by turning write caching on and off. camcontrol modepage daN. You want -m 8, the WCE bit. (write cache enable). I do not remember which -P args you need. If you see a HUGE difference in writing smallish blocks to disk between WCE on vs off, then you have a track write drive. A true sectored drive would have much less of a slowdown. I do not have a comparable set handy to get a better idea of what to expect. Really small writes cost scsi overhead though, so that adds to the slowdown. If I was to take a best guiess, I would expect a factor 10+ slowdown for track-write drives on 4K blocksize writes, vs factor 2-5 slowdown for a sectored drive. This is the slowdown factor when turning WCE off. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Best way to install on Dozens of boxes?
Michael Scheidell wrote: If I want to install FBSD 4.5 on dozens of identical boxes, what is the best way? I don't want to take the disks out and dup/mirror them, not dozens of them. The hardware supports pxe and I had half a hope that I could set up a master system with bootpd, let each target system boot by itself and load its own image. This would be to a 'virgin' hd, with no slice or partitions yet. What about a master boot cd rom? What about setting up and alternate ftp source and 'release' image? one that we managed and controlled? At yahoo, we do this by the thousand. We netboot using PXE, and have about a 30MB 'mfsroot' image that is preloaded by the netboot loader. The system boots up to a fairly full functional mini-freebsd. Then, from NFS, we run a script (clone - we used to do this disk-to-disk) that partitions and installs a set of cpio.gz images from the NFS server. We just tell the clone script what hostname we want (it looks it up in DNS) and what drive to install on (we have a lot of hardware variation) and any tweaks to partition sizes. We did write our own tool to do the partitioning and bootblock installs. scripting fdisk/disklabel/etc is too painful - especially when some of our installs need to preserve a server 'system partition' (ugh). The netboot takes less than a minute, the install takes 2-3 minutes at the most. After the network install is done, power off (netbooted remember) and turn off netboot and we're away. We also find this environment invalueable for repairing damaged systems. Simply netboot the machine in the rack (we have the netboot environment available just about everywhere) and we have a fairly functional system running from ramdisk that we can use to work on a corrupted OS. We haven't used sysinstall at yahoo for years - except for a small number of isolated incidents. Our needs are probably different to yours though, because we need to do this continually and the time investment to build the system has well and truely paid off. If you only have a small number to do, a custom sysinstall is probably more suitable. I believe Alfred's PXE pages describe this. You may like to burn a CD-RW or something for it if that works for you. http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pxe/ Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: tunings for many httpds...
Patrick Thomas wrote: Incidently, looking at the PV entry angle for a moment. Suppose you create a 1GB sysvshm (pageable) segment. That's 262144 pages. Mapping thi s once means you consume 262144 PV entries. At 28 bytes each, that is about 7.3MB of KVM. Now, fork this process 300 times. The numbers become 78643200 PV entries taking up about 2.2GB of PV entries that would like to fit in the 1G KVA space. We dont even nearly have a way to fit all this in. This is the killer reason for SHM_PHYS stuff. It avoids the PV load which has to fit into a single confined space. The cost of the page table pages sucks, but at least that is spread over the VM space of 300 processes. Ok, I'm confused now - so I understood you to originally say that SHM does not eat into KVA regardless of whether I set the kern.ipc.shm_use_phys to '1' or not. This leads me to conclude that setting that sysctl to 1 will probably not be the magic bullet to stop my system from inexplicably halting. (my system with greatly (4x) increased SHM/SEM/etc. settings) But now in this post ... are you saying that from the PV entry angle that KVA _is_ sometimes used for SHM, when we create a pageable segment ? Or are you just providing a thought experiment and pointing out that if it _were_ done this way then XYZ bad things would occur ? PV entries are normally used for user virtual mapping space. Be it mmap, sysvshm, whatever. Massive sharing uses an additional set of PV entries for each copy shared even though the same pages are used in both processes. This can add up, eg: when you have large (1G-ish) mappings mapped several hundred times on *pageable* space. No, SHM does not eat into KVA for the SHM data pages themselves. The use_phys effectively turns the data pages into un-pageable (ie: cannot ever be swapped out to disk, no matter what) space so that PV entries are not used either. We run into these problems at work with large mmap segments. a 1.5 to 2GB file mapped into 200 apaches will bring a machine to its knees. Anyway, if you have a single process in an event loop instead of an apache style massive-fork model, then you do not hit this problem at all. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Ultra320 drivers?
Jonathan Lemon wrote: I have an IBM box that has a dual LSI 53c1030 controller on the motherboard. Our SYM driver doesn't appear to have support for this device; under Linux it is supported by a Fusion/MPT driver from LSI. Any chance of getting a driver for this chip? I have an IA64 box with a 1030 as well. :-/ Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ICU_LEN with IO APIC
John Baldwin wrote: On 31-May-2002 Bosko Milekic wrote: On Fri, May 31, 2002 at 12:12:00PM +0300, Aaro J Koskinen wrote: Hello, Is there any particular reason why the number of interrupts is limited to 32 on APIC systems? Is it just a conservative guess on the number of interrupts anyone might want to need...? I'm not sure but perhaps this is historical (and now also required again), but if we use a word to mask out interrupts than after 32 we run out of bits. Who needs more than 32 interrupts anyway?! :-) Actually, the historical value in stable is 24 because the same 32-bit word shares the 8 softinterrupts with 24 hardware interrupts. I think the APIC only has 32 interrupt pins however. Historically it was because ipending and friends were a 32 bit word. Even now, we have a stack of 32 bit bitfields in this area. It isn't uncommon to have 2 IO apics with 24 pins each. Fortunately there are rarely more than about 20 or so in use in total. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: __STDC__ removal?
Alfred Perlstein wrote: NetBSD is nuking almost all __STDC__ usages because it's always defined. Do we want to do the same? The exception I've seen is for assembler files where old style C is needed to avoid conflicts. Umm, do we need it there in asm headers? We do not use the traditional cpp for our assembler files. I would be suprised if we needed it. In fact, I would be suprised if we build with -traditional any more. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: __STDC__ removal?
Alfred Perlstein wrote: * Peter Wemm [EMAIL PROTECTED] [020529 00:42] wrote: Alfred Perlstein wrote: NetBSD is nuking almost all __STDC__ usages because it's always defined. Do we want to do the same? The exception I've seen is for assembler files where old style C is needed to avoid conflicts. Umm, do we need it there in asm headers? We do not use the traditional cpp for our assembler files. I would be suprised if we needed it. In fact, I would be suprised if we build with -traditional any more. Well then we can nuke it from asm files too! Whee! Well, subject of course to it actually working.. :-) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: any file -- symbol in .o file
Jonathan Mini wrote:
Take a look at file2c. You'll need to run the source through the compiler
first, but that is easy to do with make.
You probably also want to look at objcopy. You can skip the compile step
if you're prepared to use a bit of linker magic:
peter@overcee[10:28pm]/tmp-192 cat p.c
extern char __start_buf[]; /* magic */
extern char __stop_buf[]; /* more magic */
main()
{
printf(%.100s\n, __start_buf);
}
peter@overcee[10:28pm]/tmp-193 cc -c p.c
peter@overcee[10:28pm]/tmp-194 objcopy --add-section buf=/etc/termcap \
--set-section-flags buf=load,alloc p.o p2.o
peter@overcee[10:28pm]/tmp-195 cc -o p2 p2.o
peter@overcee[10:29pm]/tmp-196 ./p2
# Copyright (c) 1980, 1985, 1989, 1993
# The Regents of the University of California. All rights re
The trick is that __start_[sectionname] and __stop_[sectionname] are magic.
The other trick is that you have to set the flags to load,alloc or you will
be somewhat disappointed.
Bear in mind that the sections are verbatim, ie: not null terminated. You
would have to do address arithmetic on the delimiter symbols to get the
size.
E.B. Dreger [[EMAIL PROTECTED]] wrote :
Greetings all,
While writing CGIs in C, I'm getting a bit sick of escaping
quotes and line continuations in strings. Not a huge deal,
perhaps, but there must be a better way. Strings end up in .data
or .rodata in object files to be linked...
I'm about to whip up a utility that will take any arbitrary
file and store the contents in a .o file (complete with symbol
names so one can actually link, of course).
Instead of compiling:
const char foo[] = \Escape\ chars make strings in 'C'
code...\n\
...messy. Line breaks can be troublesome and add\
unexpected whitespace to one's code. ;
simply put the desired unescaped text in a file:
Escape chars make strings in 'C' code...
...messy. Line breaks can be troublesome and add
unexpected whitespace to one's code.
then run the utility.
Large amounts of embedded HTML/XML/XHTML are just beginning to
bug me.
Note that it wouldn't be limited to text, either. If one wished
to take a raw-binary lookup table for a sine wave, that would
make no difference.
If there's interest, I'll post it for download. I also have a
few other ideas, and certainly am open to suggestions.
--
Eddy
Brotsman Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence
~
Date: Mon, 21 May 2001 11:23:58 + (GMT)
From: A Trap [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Please ignore this portion of my mail signature.
These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to [EMAIL PROTECTED], or you are likely to
be blocked.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
--
Jonathan Mini [EMAIL PROTECTED]
http://www.haikugeek.com
He who is not aware of his ignorance will be only misled by his knowledge.
-- Richard Whatley
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: tuning a CPU bound server
Hiten Pandya wrote: --- Peter Wemm [EMAIL PROTECTED] wrote: The only real problem that I know of with postfix is that it still suffers from select(2) collisions (FreeBSD kernel problem) when it tries to shut down a bunch of idle smtp senders. That can cause transient load average spikes - this can be a bit alarming but doesn't actually affect things very much. Just wondering, are these the kind of problems which can be solved by using the kqueue(2) mechanism, or am I talking nuts again? Regards. Yes, kqueue solves it nicely. I overestimated the work required. In fact, it looks like it would be quite easy to do. There are three places that need work. src/util/events.c (the main event loop, keeps a persistent select mast) src/util/readable.c (quick select-until-readable) src/util/writable.c (quick select-until-writable) events.c is practically begging to be converted to kqueue as it has explicit init/register/unregister/loop type operation that allows callers to register/unregister callbacks for given fd's when they become readable or writable. This is the exact scenario that kqueue is ideal for. The other two are not heavily used and could quickly whip up their own mini kqueue for the task. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: tuning a CPU bound server
Doug White wrote: qmail is also very inefficient when it comes to large delivery -- the fork per message and the qmail-remote trigger-hitting will eventually bottleneck you. It's probable you've run into it. My sympathies. :) You might try *dropping* concurrencyremote somewhat to reduce the context-switch thrash (although your context-switch numbers aren't too high, I've seen worse and the machine wasn't taxed too heavily). If it isn't done already, make sure all of qmail is statically linked rather than dynamically linked with shared libraries. qmail is well known as being brutal for hammering fork/exec, and that is faster on statically linked executables. No, I am not kidding. If you are not particularly wedded to qmail, you might try postfix or something else like it. postfix avoids fork/exec since it uses persistent processes and file descriptor passing. mx2.freebsd.org (pentium-3/850 w/ 512M of ram) uses an outbound concurrency of 512 and rarely ever gets more than a few percent of cpu in use. Newer versions of postfix support VERP (if you really want one recipient per envelope) and the qmail client-side submission protocols. The only real problem that I know of with postfix is that it still suffers from select(2) collisions (FreeBSD kernel problem) when it tries to shut down a bunch of idle smtp senders. That can cause transient load average spikes - this can be a bit alarming but doesn't actually affect things very much. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: tuning a CPU bound server
Alfred Perlstein wrote: * Peter Wemm [EMAIL PROTECTED] [020516 15:41] wrote: The only real problem that I know of with postfix is that it still suffers from select(2) collisions (FreeBSD kernel problem) when it tries to shut down a bunch of idle smtp senders. That can cause transient load average spikes - this can be a bit alarming but doesn't actually affect things very much. Is there a paper on avoiding this? I know how Linux does it, but they seem to need to hammer on the scheduler lock quite a bit as a workaround. Postfix minimizes it on freebsd by using file locking to avoid many of the key scenarios. But that does not catch them all. kqueue would completely solve it, but the author wants to keep it clean and portable. I would actually like to see a proof-of-concept implementation of kqueue though, but that would need somebody who is more familiar with kqueue than I. It would probably require greater abstraction of postfix to allow a select, poll, kqueue, /dev/poll etc style choice of backends. We could probably sell the author on this sort of thing though. FreeBSD's bug is is twofold: 1) we can only track one process selecting on a shared fd at one time, and 2) we never deregister selects. Tracking more than one is fine, but that either requires memory management as a result of making it dynamic (there is no point making space for 5 to select at once if we are failing with 600+ selecting at once). Memory management then requires that we have an opportunity to 'deselect' so that we can free up resources. Hmmm... We can do this lazily reuse and reclaim stale dynamic records the *next* time a new select happens or when the file is closed or something. The fundamental problem is that select() is supposed to be instantanious and stateless. kqueue solves it by seperating the register/deregister state from the checking of pending events so that we can keep the state active across the loops and avoid the expense of register/deregistering each time. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: question: hacking init_main.c
Terry Lambert wrote:
Jake Burkholder wrote:
Wrong, no cookie. kernel printf uses the low level console which is
initialized by cninit, which is called from init386 (etc), before
mi_startup.
My best guess at what's happening is that the subsystem numbers are
sparse, and have high numerical values, so you can't really index
an array with them. ie you're trying to print sysinit_descr[0x100]
etc. The best way I've found to do what you want is to use
linker_ddb_search_symbol and linker_ddb_symbol_values on the sysinit
function pointer to find its name, and to print the numerical value
of the order/subsystem.
T TERRY PLZ TO BE RESEARCHING NEXT TIME LUV JAKE
Jake,
*I wrote* init_main.c and kernel.h and the original SYSINIT() code;
Julian just committed it.
Terry: Just because you wrote parts of it, doesn't mean that you are
right. If you actually read the code, you would know that the console
is initialized **WAY** before sysinit is even started. It may have been
that way once in your version of the code, but it has never been that way
for FreeBSD itself.
Please see my Copyrights on the files.
You don't want to start using the kernel printf until the console
code is initialized. Trace through the code, and you will see some
bogosities that result from n-nserial console, and interaction with
the dmesg buffer.
I personally have added printfs that show the sysinits running before. I
have done it many times in fact.
note locore.s:
callinit386
callmi_startup
Now, note machdep.c:
void
init386(first)
{
...
/*
* Initialize the console before we print anything out.
*/
cninit();
if (metadata_missing)
printf(WARNING: loader(8) metadata is missing!\n);
...
}
Console probe/attach is **NOT** driven by sysinit. Please spend 30 seconds
reading the code before spreading misinformed FUD.
Would it make you happier if I removed SI_SUB_CONSOLE to prove the point?
Hmm, I think I will.. It seems to be confusing some people.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Broadcom BCM5701 Chipset problems
Terry Lambert wrote: Has anyone tapped the manufacturer on the shoulder hard enough to get an answer? Why are you not using Linux or another supported OS? No, they so far have steadfastly refused to supply information about bugs and errata in such a way that we could use them in an open source driver. ie: you cannot get anything without an NDA that basically forfeits the souls of your next 5 generations of offspring if you even mention there might be bug in the hardware to your next door neighbor with a quiet whisper. OK, that's overdoing it :-), but you get the idea of the problem. Their NDA process just doesn't cater for open source development. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Soft interrupts
Josef Karthauser wrote:
Do we have soft interrupts?
Here's a bit of code from the NetBSD usb stack, and I'm trying to work
out what it would be in FreeBSDland.
sc-sc_bus-soft = softintr_establish(IPL_SOFTNET,
sc-sc_bus-methods-soft_intr, sc-sc_bus);
if (sc-sc_bus-soft == NULL) {
printf(%s: can't register softintr\n, USBDEVNAME(sc-sc_dev
));
sc-sc_dying = 1;
USB_ATTACH_ERROR_RETURN;
}
Can someone point me to a man page please?
Joe
You probably want to have a good look at usb_ethersubr.c - it does this
sort of thing already, but for different reasons. On FreeBSD, the usb
hardware interrupts ran (pre-SMPng) as bio, not net. All of the
assumptions, problems and workarounds for this from pre-SMPng are now
invalid or irrelevant. usb_ethersubr.c can be gutted right down now
since splnet and splbio are irrelevant. The problems that NetBSD
has to deal with are no longer the same for us. The softint stuff
is probably harmful for us because it would mean an *extra* context
switch. (from the uhci/ohci ithread to the swinet ithread).
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
Kenneth Culver wrote: I'm actually still not seeing a match between what's in truss, and what's in my printed-out args, but it seems to be working anyway... Argh, it's not working again... It was working on an install of ms office, but it won't work on some old windows game.. (winex) and it's still not setting the last arg (or register properly): truss output: linux_mmap2(0x6543,0x10,0x3,0x11,0x9,0x6) = 1698889728 (0x6543) notice that the last arg is 0x6, that's the page offset... what the kernel prints for the same call: mmap2(0x6543, 1048576, 3, 0x0011, 9, 0) notice that they both have all the same values until you get to the last one... at which point the value is wrong... Apparently this only causes problems on some windows programs that one may try to execute, and not on others... So, where can I force this to get set? Ken Try this: RCS file: /home/ncvs/src/sys/i386/linux/linux_sysvec.c,v retrieving revision 1.99 diff -u -2 -r1.99 linux_sysvec.c --- linux_sysvec.c 4 Apr 2002 17:49:46 - 1.99 +++ linux_sysvec.c 24 Apr 2002 23:57:23 - @@ -711,4 +711,5 @@ args[3] = tf-tf_esi; args[4] = tf-tf_edi; + args[5] = tf-tf_ebp; *params = NULL; /* no copyin */ } Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
Kenneth Culver wrote:
Brandon S Allbery KF8NH writes:
On Wed, 2002-04-24 at 10:41, Andrew Gallatin wrote:
Maybe the argument isn't where you expect it to be, but is there.
Can you make a test program which calls mmap2 with its 6th arg as
something unique like 0xdeadbeef? Then print out (in hex :) the trapf
rame
from the linux prepsyscall routine see if you can find the deadbeef.
My recollection is that beyond 5 arguments, a pointer to the remaining
ones is passed. (But my recollection may be wrong and I don't wish to
subject myself to the source cesspool at the moment)
I think that's how it used to work. Apparently, they've changed it
recently and they now pass 6 args in registers. Eg, in the linux
kernel sources, old_mmap() fetches its args via copy_from_user(),
whereas the newer sys_mmap2() doesn't.
Drew
Yep, according to the docs and source code I looked at in the linux
kernel, the sixth arg is in the ebp register. I've looked all over the
FreeBSD kernel and the linux emulator for the place that actually sets
these, and unfortunately, due to my lack of asm coding knowledge, I can't
find anything.
Here's where it happens:
sys/i386/linux/linux_sysvec.c
static void
linux_prepsyscall(struct trapframe *tf, int *args, u_int *code, caddr_t *params)
{
args[0] = tf-tf_ebx;
args[1] = tf-tf_ecx;
args[2] = tf-tf_edx;
args[3] = tf-tf_esi;
args[4] = tf-tf_edi;
*params = NULL; /* no copyin */
}
You probably want to add:
args[5] = tf-tf_ebp;
so that it ends up in the syscallargs struct.
For FreeBSD syscalls, we copy this from the top of stack for the number of
32 bit words specified in the syscall table in i386/trap.c:
if (params (i = narg * sizeof(int))
(error = copyin(params, (caddr_t)args, (u_int)i))) {
(narg comes from the syscall table).
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: sendmail complaining about filedescriptors?
Wilko Bulte wrote: On -stable as of last week I see sendmail log errors on file descriptors as in: Apr 22 09:29:16 freebie sm-msp-queue[126]: starting daemon (8.12.2): queueing @00:30:00 Apr 22 09:29:50 freebie sendmail[253]: File descriptors missing on startup: s tdout, stderr; Bad file descriptor Apr 22 09:29:50 freebie sendmail[253]: g3M7To31000253: from=wkb, size=449, cl ass=0, nrcpts=1, msgid=[EMAIL PROTECTED], relay=wkb@l ocalhost etc. Mail arrives OK, mergemaster has been run. This is usually because fstat(2) fails on file descriptors that have been revoked. By the time that message is printed, the /dev/console descriptors that were inherited from /etc/rc etc would have been revoke(2)'ed by the getty on /dev/ttyv0 or ttyd0. cron also used to do this. It would end up with handles to the console that would get revoked, and sendmail would get upset when cron fired it up. I fixed that a while back in cron to ensure that it had valid handles. Have a look at lsof/fstat output for the revoked fd's, and you'll probably find some new ones now. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendmail complaining about filedescriptors?
Gregory Neil Shapiro wrote: wkb Apr 22 09:29:50 freebie sendmail[253]: File descriptors missing on start up: stdout, stderr; Bad file descriptor sendmail always checks it's first three fd's at startup to avoid the problem that has just come to light in the FreeBSD security announcement. This is what is logged if sendmail has problems with them. It can be ignored as sendmail attaches /dev/null to them. In this particular case it's a false alarm. There are fd's there, but they got revoke(2)'ed by the getty on the console. fstat(2) returns EBADF on the revoked fd's and is impossible to tell the difference between a revoke'd fd and a non-existing fd. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ssh + compiled-in SKEY support considered harmful?
Mike Meyer wrote: In [EMAIL PROTECTED], Jordan Hubbard jkh@win ston.freebsd.org typed: My question: Who's wrong here, FreeBSD or Mac OS X? If the latter, Someone decided that FreeBSD should do challengeresponse authentication by default. You can fix it by uncommenting the line #ChallengeResponseAuthentication no in /etc/ssh/sshd_config. AHA! I've been wondering about this too. I cheated and set Protocol 1,2 to avoid the whole issue. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fatal trap 12: page fault while in kernel mode
Terry Lambert wrote: David Greenman wrote: #16 0xc0152220 in tsleep () #17 0xc016abfe in m_clalloc_wait () #18 0xc01c8b14 in nfs_realign () #19 0xc01c9653 in nfsrv_rcv () #20 0xc01701d0 in sowakeup () #21 0xc01abd7c in udp_input () #22 0xc01a1bfb in ip_input () #23 0xc01a1c5b in ipintr () This is basically telling you that there is a bug in the NFS code that i s incorrectly trying to do a wait type of allocation in an interrupt contex t, which is not valid. You can't sleep when there is no process context. Amusing. Then the fix is probably to take the proc pointer of the proc whose socket is being used to do the call, which is the third argument to nfssvc_addsock(), and put it into the structure pointed to by struct nfssvc_sock * as the argument to the upcall. Then, in the upcall code in nfsrv_rcv(), pass the proc pointer down as the process context. I think, actually, that multiple sleeps by the same process are also disallowed (;^)), so probably... You will need to modify nfs_realign() to take a waitflag, as propagated from nfsrv_rcv()... and then pass it through on the MCLGET and the MGET, to make sure that if the alloc fails, that it's OK. This does point out a problem in MCLGET() (the macro that wraps m_clalloc_wait()) wanting a process context. Probably, the best thing would be to pass a proc p in, and if it's NULL, just imply no wait semantics. What an ugly mess... Terry, if you spent half of the time reading the code as speculating and writing about your wild speculation, you'd know that we already have a waitflag for nfsrv_rcv() to track safeness to wait or not. The bug is that nfs_realign doesn't take the 'waitflag' argument and has two 'can wait' mbuf allocation calls. The fix is trivial and hardly ugly. But then again, anybody who actually bothered to read the code before posting would know that. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Interesting sysctl variables in Mac OS X with hw info
Sergey Babkin wrote: Terry Lambert wrote: It got really bogged down when someone pointed out that they were running CPUs with different clock rates in their SMP box, just to see what the net effect would be. THe As far as I understand, you just physically can't do it: the P-II CPU initialization depends on all the CPUs on the bus running at the same rate. Or if you can do it then you still should never do it. Unless you actually have a NUMA machine (as opposed to an SMP machine). Nope, you most certainly can do this, I have such a box. One cpu is running at 866MHz, the other at 933MHz. The front-side-bus is the same speed though (133MHz), just the internal clock multiplier within the cpu is different. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Intel 820 RNG
Mark Murray wrote: But, back to the topic. We have taken the OpenBSD driver for the RNG on the i810 chipset (and some other i8x0 chipsets), and ported it to FreeBSD-4.4. We made some enhancements to get more of the available random data bandwidth. We want to clean them up a little and submit them as a PR, but have not had time to. If you're interested I can send you the patches and you can give them a try. Hi. Please send me what you have. I thought it was an add-on to the firmware hub rather than the 820 chipset proper. The firmware hubs seems to be just about everywhere these days on intel chipset motherboards.. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Missing PT_READ_U
Bakul Shah wrote:
Zap 'ptrace(PT_READ_U, ...)' and 'ptrace(PT_WRITE_U, ...)' since they
are a really nasty interface that should have been killed long ago
when 'ptrace(PT_[SG]ETREGS' etc came along. The entity that they
operate on (struct user) will not be around much longer since it
is part-per-process and part-per-thread in a post-KSE world.
Yeah I saw that before sending out my query. This should've
waited until after KSE is in place.
the uarea is pretty much a shadow of its former self
The fields have been scattered across two structures.
What is ups trying to find out?
Signal handling state of the process being debugged (whether
ignored/caught etc).I haven't dug deeper into it so I
don't know why it wants that but it seems to be pretty deeply
wired in.
There are other ways to get all the information in question.
There isn't. I don't think procfs will give me that either.
May be PT_{SET,GET}SIGSTATE should be added?
As the culprit behind PT_READ_U's demise, I'm willing to dive in
and help here if needed.
Incidently, PT_READ_U didn't actually work for the case where the
signal handlers were shared between rfork()'ed processes.
Do you have any suggestions as to how PT_GET/SETSIGSTATE should look and
feel? UPS's requirements seem pretty trivial (ie: return the handler
for a given signal number), but that feels a bit minimalistic given that
we have flags and a mask per signal as well. There is also the signal
mask as well (masks are 128 bit).
On the other hand, maybe we should just keep it simple for ptrace() since
the API is so limited.
BTW, what is being added to allow debugging a post-KSE world
process?
-- bakul
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: In-Kernel HTTP Server (name preference)
Mike Silbersack wrote: On Mon, 18 Feb 2002, Hiten Pandya wrote: hi all, As to conclude this thread (for me.), I have come to the decision of actually starting a project for making a BSD Licensed in-kernel HTTPd server. The project will be on SourceForge.net. As you all know, that when starting a project, a name is needed for project; I completely out of ideas, and I have literally no creative skills. :) If you want to be really useful, I have a better first step for you. :) Common wisdom seems to be that Apache is slow, other httpds are faster, custom ones are fastest. However, I don't think I've actually seen any comparisons since this one of thttpd vs others: http://www.acme.com/software/thttpd/benchmarks.html Before starting work on a kernel httpd, you might wish to run similar benchmarks (with perhaps only 5 different httpds) to see what the current performance of FreeBSD is; it may turn out that some limitation in the TCP stack is hit even by userland httpds, and your effort would be better spent on fixing that first. The problem is that our threads implementation sucks. The moment that thttpd has to do an actual disk read on freebsd, the whole thing comes to a screeching halt. Threaded http servers do not stand up to real-world loads on freebsd, unless there are very specially constructred scenarios in place.. ie: everything is in ram, no FS calls ever block, etc. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: fork rate limit
Mike Silbersack wrote: 2. Limit the number of procs to an appropriate number. Previously, it was easy to set maxproc overly high by setting a large maxusers value. With this change, proc-related structures will only be able to consume about 1/2 of all system memory. Without this limitation, a high maxusers setting and a forkbomb could easily consume all system memory, leaving virtually no chance for the system to recover. + /* * The following can be overridden after boot via sysctl. Note: * unless overriden, these macros are ultimately based on maxusers. */ maxproc = NPROC; TUNABLE_INT_FETCH(kern.maxproc, maxproc); + if (maxproc automaxproc) + maxproc = automaxproc; maxfiles = MAXFILES; TUNABLE_INT_FETCH(kern.maxfiles, maxfiles); No. Root's overrides come *after* automagic settings, regardless of how well intentioned the settings are. If you are going to do this, it should be something along the lines of: maxproc = NPROC; if (maxproc automaxproc) maxproc = automaxproc; TUNABLE_INT_FETCH(kern.maxproc, maxproc); Even this isn't quite right, because NPROC may be a compile option which must be respected. The default #define NPROC may need adjusting. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [nicole@unixgirl.com: What is biord?]
Alfred Perlstein wrote: * David Malone [EMAIL PROTECTED] [020116 14:30] wrote: On Wed, Jan 16, 2002 at 02:18:25PM -0800, Josef Grosch wrote: I have a mysql database that seems slow and when looking at it in top it always seems to be in a state of biord What the heck is biord I can't find this anywere 22:21:gonzo 3% fgrep biord /usr/src/sys/kern/* /usr/src/sys/kern/vfs_bio.c:tsleep(bp-b_xflags, PRIBIO, bior d, 0); /usr/src/sys/kern/vfs_bio.c:tsleep(bp, PRIBIO, biord, 0); If you have a look at the code, in vfs_bio.c around these lines, you'll see it is to do with waiting for buffers to be read or written. Basically it means that the database is spending alot of its time waiting for the disk to catch up. If you compile mysql using the linuxthreads port instead of freebsd native threads you _might_ see a performance improvement. -Alfred If mysql is blocking on bioread, then it is stalling the entire thread engine when one hits disk IO. Using the linuxthreads port cant help but make it work better / more smoothly.. especially if there are multiple clients. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: userland program panics freebsd 4.3
Kris Kennaway wrote: On Thu, Dec 20, 2001 at 09:10:14AM -0500, Michael Scheidell wrote: I doubt hardware related I can get it to do it on two seperate boxes. OK, then you need to get more details as explained. My gut reaction tells me that this is either a kernel stack overflow or out of KVM. The kernel stack overflow problem was fixed in 4.4-STABLE some time back (change UPAGES from 2 to 3 in the kernel) so that the kernel stack changes from 4.5K to 8.5K. The other possibility is that he's configured the kernel so big (maxusers too high etc) and he's running out of KVM. No tuning information was supplied (kernel configs, any sysctl/tunable changes etc). I'd be interested to know what this says: # gdb -k /kernel /dev/mem (kgdb) print ((struct vm_map *)kernel_map)-size Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 3Com driver problems
FYI, this is another [EMAIL PROTECTED] clone. [EMAIL PROTECTED] wrote: with 3Com905B devices. And a quick search did not reveal any major problems with the 3com cards. A quick search of what? Get some perspective. The hackers are only interested in cards that they use, and they all use intel for high end stuff. Bill paul is too busy writing drivers for some new gigabit card to worry about old stuff. (note that most of his drivers are optimised for the Alpha and not i386...like what pct of people are using Alpha?) And there is apparantly no interest in fixing anything or finding out whats wrong because some guy at freebsd with a 2 inch weener keeps knocking me off the list...they dont like criticism. I've already fixed it, so all im trying to do is save you a lot of time doing work thats already been done. Actually, the cards are very much optimized for the i386. See the lack of using bus_dma for example, which is required for these cards to work on things ike sparc64. Grow up and realize that not all the world is an i386. Ports like sparc64, powerpc, ia64, and x86-64 are being added and they are not exactly like the i386. I've used 3com cards (xl(4)) without any problems. They are rather nice cards and Bill Paul prefers those to Intel cards since Intel is so nazi with its docco. :) To Guret: Please don't listen to Dennis. He is feeding you lies so that you will go buy? his better ethernet drivers. He is very obnoxious and thus has been banne d from the lists several times. This is just another one of his silly aliases . We dont sell ethernet drivers, and Im not trying to hide. Why does linux have specific code to disable the stats under load if Im making this up? Why can you lock up a FreeBSD 4.4 system with a 3com card at 20Kpps due to counter overflow interrupts in about 3 seconds? Its too bad that pointing out bugs is deemed as being obnoxious. Maybe its why they were complaining that linux outperforms Freebsd last week? Guret, I apologize for trying to help. Im sure these fellows at freebsd.org will work painstakingly to help you find your problem. But since they are in denial about there being anything wrong with it, you most likely are sunk. Try to front end your machine with a switch...the 5 cards is most likely your problem. With each device you increase your bus contention (ie worsen the worst case bus master scenario)...either that or get a 4 port card that is more efficient than 5 individual cards. DB To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 3com card problems
FYI: This is another [EMAIL PROTECTED] clone. [EMAIL PROTECTED] wrote: Hi, You claim the 3Coms are no good choice for FBSD. I have always been very satisfied with 3Com905B devices. And a quick search did not reveal any major problems with the 3com cards. Pls, can you explain the problem in more detail or direct me to more detailed information (how to avoid impacts with STATS ...) Thank you Gernot Hueber To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NFS: How to make FreeBSD fall on its face in one easy step
Jordan Hubbard wrote: I should point out that FSX can be used against any filesystem, and that there are reports locally (at Apple) that it's great for killing FreeBSD machines. I wasn't able to reproduce this when I tried, but I may not have let it run long enough. Oh, it blows freebsd.apple.com right out of the water with a kernel panic after running for just 3 seconds from an OS X box on the same LAN segment. :) To be clear, what exactly are you doing? It sounds like you're exporting something from freebsd, mounting it on OSX and running this tool on OSX against the filesystem exported from freebsd ? If so, What mount options? NFSv2 or v3? Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
Terry Lambert wrote: Greg Lehey wrote: 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. ? OK, I load the kernel from the JFS. I mount the root FS, which is a JFS. I read the module jfs.ko from the JFS so that I can mount the root FS, which is a JFS, so I can read the module jfs.ko from the JFS so that I can mount the root FS, which is a JFS, so I can read the module jfs.ko from the JFS so that I can mount the root FS, which is a JFS, so I can... Do you see the problem yet? It is not a problem. The *kernel* does not load jfs.ko, it is loader itself. There is no reason why a trivial non-gpl jfs reader couldn't be written for boot2 and loader if the need was great enough. Or have /boot as a seperate file system (eg: UFS or FAT32). We do this on IA64 where /boot is a FAT32 filesystem (not exactly, but close enough. I usually mount it on /efi and make /boot/ a symlink to /efi/boot so that in EFI we have a /boot as well). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Performance issue
Poul-Henning Kamp wrote: There are many effects that could cause this, for instance if FreeBSD manages to align things differently in relation to the CPU cache you could get some very interesting waste of time that way. Based on the data you show me, I can't really say that something is wrong or right either way. One thing that Linux does that we do not do is that they have different versions of libc compiled specifically for different cpu types, and at boot time set the correct paths. eg: /lib/i386/libc.so.6.whatever This means that Linux's glibc is using an i686 optimized bzero(), but the FreeBSD one is using an i386 optimized bzero(). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: who is postmaster?
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? peter@hub[4:39pm]/etc/postfix-58# host opsmail.prod.netsol.com Host not found. Anyway, I have added a special override to allow network solutions' misconfigured systems to send mail. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A comparison of Samba performance on FreeBSD 4.3-RELEASE and Linux 2.4.13ac4
Richard Sharpe wrote: attached is a preliminary report on a comparison of Samba performance on FreeBSD 4.3-RELEASE and Linux 2.4.13ac4. Are you aware that 4.3-RELEASE has IDE drive write caching turned off by default? What was the Linux system configured with? 4.4-RELEASE has it back on again by default. Secondly, are you using a GENERIC kernel or a tuned kernel? GENERIC is quite unrealistic these days due to supporting the lowest possible cpu (i386). There is a significant amount of overhead to support this. We really need to ship with a number of different kernels and install the best-match at install time. I have noticed that linux distributions have been doing this for quite some time, and even go as far as installing different libc's depending on cpu type. You mentioned using fsync() vs fdatasync(). fsync() is pretty much the worst possible thing that you can do to a softupdates file system as it effectively negates all benefits of the dependency tracking, but still incurs the significant expense of doing the tracking and unwinding. I would be curious to know what things looked like without fsync/fdatasync (on both sides for fairness), and with a freebsd non-softupdates filesystem mounted in async mode for parity with linux's async ext2fs. I can't say that I'm too suprised with the results though. It is fairly well known that Linux's network stack generally has lower latency, and the SMB request-response type protocol (is it still lockstep these days?) tends to make this visible. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Intel gigabit driver
Jonathan Lemon wrote: In article local.mail.freebsd-hackers/[EMAIL PROTECTED] you write: What happend at Intel? Their driver is even released under the BSD license! (and the Linux one under the GPL) Many Intel software products are released under a BSD-like license. Consider the ACPI CA codebase we use. The driver will be committed to -CURRENT first and MFC'ed to -STABLE later. Really? What about the gx driver? The 'gx' driver was committed so that Jonathan's code would be on record, since he'd spent so much time and effort on it. Testing so far has indicated that the Intel driver is generally superior, but No, sorry. Testing has shown no such thing; the performance of the drivers is equivalent, or even that gx has a slight edge. Well, the experience on irc.snoogans.org begs to differ. The Intel driver sustained much higher rates under attack than what it took to make gx fall over completely. The Intel driver will be the preferred driver for these cards. That still is under discussion. More to the point, let the respective drivers stand on their own merits. There is no need to decide for one or the other. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Intel gigabit driver
Mike Smith wrote: The Intel driver will be the preferred driver for these cards. That still is under discussion. More to the point, let the respective drivers stand on their own merits. There is no need to decide for one or the other. This is, unfortunately, not entirely true. One of them is going to have to be the default, since we can't have them both attach to the card. 8) Right now it's the user's choice. Neither are in GENERIC. We have a preload mechanism that can serve us well enough for this for the time being until it is clear what we should do. CDROM installs are most likely going to use cdldr soon so we will have the entire module suite available from loader. For boot floppies we should probably use the one that is smaller on disk.. but we also have the the embryonic driver disk in the pipeline for real floppy installs. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD (as a Guest OS), VMware X11
Glenn Gombert wrote: In case anyone is interested...I have X11 running with FreeBSD as a Guest operating system under Win2K..the current XFree86 server (v 4.101) that is in the ports collection, runs ok with the generic wm that comes with XFree86, when I try and run KDE under 'Current' I get .. /usr/X11R6/lib/libXext.so.6 Undefined symbol __stderrp...for some reason ... Be sure you have COMPAT4X=yes in /etc/make.conf. If you didn't, then do this: cd /usr/src/lib/compat/compat4x.i386 make obj make all make install Then all __stderrp etc stuff will go away, except for some *really* binaries that use libc_r.so.3 Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Ok, who broke timed?
Leo Bicknell wrote: On Mon, Nov 19, 2001 at 04:51:29PM -0800, John Baldwin wrote: That looks very promising indeed. Hrmm. I should go see if NetBSD has fix ed this. I guess having timeval be different sizes on different archs is a bi t of a pain. :( Perhaps it should use uint32_t? Or perhaps struct tsp should u se its own variant of timeval with uint32_t or some such. Ugh. If timeval is different sizes on different archs then I would recomend the work be done take it to 64 bits, not 32. It fixes a problem in about 30 years. :-) Unfortunately, it isn't our on-the-wire protocol to modify. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tracking down BTX halted
Doug White wrote: On Fri, 16 Nov 2001, Sandeep Joshi wrote: I changed the disklabels on a few SCSI disks and now I keep getting these BTX halted messages every time I reboot. Lemme guess, you're running them in 'dangerously dedicated' mode. There is a bug in Adaptec BIOSen that they will not tolerate DD disks. Put proper partition tables on them and they should behave. It's not so much a BIOS bug but the fact that we specify an illegal geometry in the fake fdisk table. This can cause bios's that are about to use the fdisk table to emulate C/H/S geometry to do a divide by zero. This is usually what shows up in the BTX faults. Both of the posted BTX faults have int= which is a divide-by-zero. see i386/i386/machdep.c for identifying the int values: setidt(0, IDTVEC(div), SDT_SYS386TGT, SEL_KPL, GSEL(GCODE_SEL, SEL_KPL)); ^^^ int 0 = 'div' (divide by zero) The specific problem is that the fake fdisk table specifies 256 heads, which is not possible to represent in the int13 interface. The maximum allowed is 255 heads. (hint: 256 in an 8-bit register rounds to 0, hence the divide-by-zero). This is the cause of EFI (ia64) hangs, the infamous Thinkpad T20/A20 series system lockups, countless bios crashes, etc. The problem is that you cant *not* get dangerously-dedicated mode. Our boot1 has got a dangerously-dedicated fdisk table unconditionally compiled in. You can fix it so that it doesn't crash stuff, but we still shouldn't be forcing it on people like that. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tracking down BTX halted
Doug White wrote: On Fri, 16 Nov 2001, Matthew Emmerton wrote: There is a bug in Adaptec BIOSen that they will not tolerate DD disks. Which controllers have this bug? I've got a whole bunch of 7880 and 79xx controllers with disks running in DD mode and never have had this problem. Happens to me on L440GX+ boards. It happens randomly all over the place. I think it also depends on the default bios settings too.. ie: whether you've got Large Drive support on or off, and what mode it is in. FWIW, this puts a legal geometry back into boot1: +++ boot1.s 2001/11/18 01:42:26 @@ -353,7 +353,7 @@ .fill 0x30,0x1,0x0 part4: .byte 0x80, 0x00, 0x01, 0x00 - .byte 0xa5, 0xff, 0xff, 0xff + .byte 0xa5, 0xfe, 0xff, 0xff# 1023 cyl, 255 heads, 63 sec .byte 0x00, 0x00, 0x00, 0x00 .byte 0x50, 0xc3, 0x00, 0x00# 5 sectors long, bleh But that stops the MBR kernel code from recognizing it as a bogus DD table and it will try to interpret it, thinking that you only have a 25 meg drive. I wish we could take this crud out with a shotgun. If somebody is going to boot off a disk, obey the rules with a real MBR and fdisk table. If somebody doesn't want a fdisk table, then dont fudge around with a fake one, and dont pretend that it is bootable. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: pmap_collect() and PG_UNMANAGED
David Xu wrote:
This is a multi-part message in MIME format.
--=_NextPart_000_000C_01C162B1.0ECE7770
Content-Type: text/plain;
charset=gb2312
Content-Transfer-Encoding: quoted-printable
Hi,
is there any reason why pmap_collect() in /sys/i386/i386/pmap.c does =
not
check PG_UNMANAGED flag? unmanaged page does not have pv_entry =
associated,
so call pmap_remove_all() has side effect, PG_MAPPED and PG_WRITEABLE =
are=20
roughly cleared.
--
David Xu
Did you have something like this in mind?
@@ -1729,7 +1729,7 @@
for(i = 0; i vm_page_array_size; i++) {
m = vm_page_array[i];
if (m-wire_count || m-hold_count || m-busy ||
- (m-flags PG_BUSY))
+ (m-flags (PG_BUSY | PG_UNMANAGED)))
continue;
pmap_remove_all(m);
}
BTW; please stop posting MIME/HTML onto mailing lists.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: getenv_foo and TUNABLE_FOO_FETCH change
John Baldwin wrote:
Also, one final note about using do { } while(0). If you actually read
style(9), you will see that you are supposed to use it for compound statement
s,
not just for any macro that happens to be more than one line long. If the
macro's body is a single statement, it doesn't need the do { } while (0) bit.
It was there so that the macro didn't have a value. Since you're
changing this so they all have a meaningful return (eg: TUNABLE_STR_FETCH()
did not before) then removing this makes sense.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: where are kernel modules located?
Zhihui Zhang wrote: Could you please tell me where in the source the KLD location is determined? I found out that the KLD can be loaded under / in 4.3-Release even if I have a newer copy under /modules. This gives me a lot of trouble debugging. Look at the sysctl kern.module_path - that is the exact order that things are searched for on any given system. Thanks, -Zhihui On Sat, 20 Oct 2001, Warner Losh wrote: In message Pine.SOL.4.21.0110201648520.23011-10@onyx Zhihui Zhang wri tes: : Kernel modules are supposed to locate under /modules. It turns out we ca n : find it under /. So where are kernel models located exactly? In -stable it is /modules (except for about 8 hours in the last few days when they bogusly wound up in / due to a foobar by yours truly). In current they live in /boot/kernel/*. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
