Re: matthew dillon
I don't know who he is either, but much to my regret this nonsense has forced me off the list. Bye everyone, it's been a great 9 years, and it's a great OS, and you're great people! I hope this mess gets worked out someday. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [FAQ] The Open Source Stackable PC BIOS (fwd)
On Fri, 13 Dec 2002, Bruce M Simpson wrote: Two words: Open Firmware. if it has open in the name, it's not open firmware is useless to me. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [FAQ] The Open Source Stackable PC BIOS (fwd)
On Fri, 13 Dec 2002, Bruce M Simpson wrote: Were you aware of the OpenBIOS project? I've only been working with them for about the last three years. re open firmware: where was taht source tree again? ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [FAQ] The Open Source Stackable PC BIOS (fwd)
On Fri, 13 Dec 2002, Terry Lambert wrote: Actually, the interesting part would be a survey of which BIOS calls are actually used (a survey by a BIOS writer, maybe, hint hint 8-)). we've got a good fellow on freebsd-clusters doing the survey, and then we're going to see how to hook up freebsd and freebios (aka linuxbios). The real question is fail-safe on unimplemented BIOS calls, which should return a characteristic error. good idea! That doesn't mean you have to implement it in your reduced BIOS, but it does mean that you have to implement proper indication of failures, when calls you don't implement are used (again, sorry). gotcha. Thanks, as usual, Terry :-) ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: biometrics
I thought I saw one of them at freenix a few years back? not sure. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [FAQ] The Open Source Stackable PC BIOS (fwd)
On Thu, 12 Dec 2002, Terry Lambert wrote: I guess it's not OK to make BIOS calls into the BIOS? not if it's my lazy bios that doesn't support them. Isn't that what BIOS's are for?!? agreed, but I was hoping that we could move beyond this bios stuff. Can't we all just get along :-) ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
[FAQ] The Open Source Stackable PC BIOS (fwd)
We would sure like to be able to boot freebsd, but freebsd makes bios calls. Any way we can change this (i.e. pass info freebsd needs via tables). Openbsd boots, so does win2k, so we're not linux-centric. ron -- Forwarded message -- Date: Mon, 9 Dec 2002 21:19:15 -0500 (EST) From: Adam Sulmicki [EMAIL PROTECTED] To: Linux BIOS Mailing List [EMAIL PROTECTED] Subject: [FAQ] The Open Source Stackable PC BIOS Hello, I have updated the FAQ with various comments from Booting from floppy thread. Comments on FAQ welcome. http://www.eax.com/ADLO-FAQ.html This FAQ does not intend to duplicate LinuxBIOS FAQ but rather give a bird view of the various BIOS projects and give someone new to the BIOS projects better idea what's it about and why someone would want to do this. In this release: new question * Q10: What is what? heavily updated * Q3: So is this accomplishment just art for art's sake? updated question * Q6: So when can I expect to see it in commerical motherboards? -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: maxusers and random system freezes
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. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Show me the light
Put a voltmeter on the PP port. Measure voltage. put am ammeter on the PP port. measure current. (start at 10 amps to be safe, trust me, you're not going to cause the ammeter any trouble). See if Voc and Isc are in a usable range. If not, go get yerself a little reed relay or solid state relay. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Show me the light
On Mon, 28 Oct 2002 [EMAIL PROTECTED] wrote: As far as I remember, there is open collector output on parallel port, so your wish impossible %-) oops, I forgot that little deal. Yup, you need a pullup. you can get PP relay modules for not much. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Runlevels and opcodes
On 27 Sep 2002, Ryan Sommers wrote: *** But what does prevent a user-level process from executing wild instructions (RESET, traps, other dangerous instructions and undocumented features) ? I'm probably less knowledgeable then you are but in protected-mode programming isn't the kernel responsible for making sure no programs go rogue? in some ways, but wild instructions are the province of the architecture. You can't execute them in user mode. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hey, is there space for a newbie? =)
On Wed, 25 Sep 2002, Bruce M Simpson wrote: Anyone looked at OpenBIOS? The line has to be drawn somewhere... as regards supporting multiple chipsets/CPUs. Personally I like the idea of being able to do PXE-like booting on non-Intel platforms. sure, and it will probably run on top of linuxbios. we're working with them. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hey, is there space for a newbie? =)
I still wish somebody would do a bproc port for freebsd (see http://www.clustermatic.org) or get freebsd loadable from linuxbios (http://www.linuxbios.org). We load plan 9 and WinCE, so how much does freebsd need? ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: intermezzo?
intermezzo probably is not impossible on freebsd. I worked on the early versions and most of the hard work is done outside the kernel. It would be nice to see it on freebsd. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: intermezzo?
On Fri, 6 Sep 2002, Terry Lambert wrote: Sarnoff has done a similar implementation for FreeBSD, called MNFS, which had an integrated distributed cache coherency protocol, and was implemented for FreeBSD circa 1996. goodness, that's me! They're pretty different however. MNFS was for distributed shared memory and was designed to ensure that mmap'ed blocks from the same file remainted consistent across a set of clients. Intermezzo is kind of like coda done right. The intermezzo name refers to the code that layers between the VFS layer of Linux and ext2/3. OPs from the VFS layer can be redirected to user mode from the intermezzo code. I think intermezzo is doable on freebsd, it just takes time. Also, it is a module. Maybe they wanted a patent. 8-). Fortunately Peter Braam doesn't worry about patents :-) Peter was here yesterday and tells us that intermezzo can now run over tmpfs. That's cool, I had done something like that two years ago but it was a bit of work and now it just works fine. ron 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?
a couple years ago I did 64 boxes with fbsd using a boot cdrom that did a network install. 7 minutes per box, i punched out 8 cds. Took one hour. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
On Wed, 24 Apr 2002, Richard Sharpe wrote: Multicast! BootIX (nee InCom) have support for this in their BootROMS. it might not be hard to hack into Etherboot et al. bproc now uses multicast for distributing new kernels and init ram disks, if you want to see an example. It's on sourceforge. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PCI Probing Utility?
On Fri, 22 Feb 2002, Michael Smith wrote: Is there some quick, down dirty way of assessing the bus-speeds of PCI slots/busses on a given box? I have a whole rack of systems with FreeBSD 4.5 on 'em, and need to know the PCI bus configuration for each. Unfortunately, no. The Yahoo! folks have worked on some old SMBios code I wrote that might be able to extract the information you require, but there's nothing trivially visible in PCI config space that will tell you this. It gets worse. We just measured some Compaq SP750s here. We see a 10% variance on PCI bandwidth on boxes with the same part #s. Further looking around shows the north bridge on slow machines was fabricated in Korea, and the faster one was fabricated in Phillipines. Looking at north bridge register settings shows different values. So here are identical boxes with nothing to tell you they're different, that act different. The lesson is that if you want to know the BW of a given box, to some reasonable certainty, you will have to measure it. The boxes' sibling will give you no useful data. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: in-kernel HTTP Server for FreeBSD?
On 17 Feb 2002, Dag-Erling Smorgrav wrote: Roy Sigurd Karlsbakk [EMAIL PROTECTED] writes: sendfile() isn't zero-copy, it's just two-less-copies. zero-copy means zero copy-operations within memory To an MCSE, maybe. I think Roy is right. AFAIK the term zero copy was invented by Van Jacobsen ca. 1990 to describe an optimized TCP stack he had working with the Witless interface project he did with HP, while he was still at LBL. Witless was an FDDI interface with interesting properties -- still well worth studying today. And, there was one copy in the TCP for Witless. You had to read zero copy to mean Zero copies more than the absolute minimum. When we did the MINI interface at the SRC (ca. 1994), which had one less copy than Witless, we jokingly called it a -1 copy interface. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: OS Textbook FreeBSD Appendix
On Tue, 29 Jan 2002 [EMAIL PROTECTED] wrote: As far as I remember from reading the Lyons' book, there were 16 mapping descriptors for text and data each. I think, 1/16 of the address space is not too big, and in absolute values it's the size of today's pages (4KB). well I had dropped this thread as I figured the list would not want to hear it, but yes you're right. The KT-11 MMU worked this way. I still have my manuals, as it was a pretty interesting piece of hardware. Unix was the first OS to actually use the split I/D capability, so while the various DEC OSes were stuck at 64K Unix programs could run at 64kI/64kD. Also user mode/super mode/kernel mode each got its own set. There was also a weird instruction called MFPU (move from previous user space) that allowed bcopy shared memory-type programming. Once again Unix actually used this, the DEC OSes did not, so Unix was the first to find the bugs in this hardware too. Once university as I recall actually added the wire to its machine to make MFPU work correctly ... The kinds of things you had to do in Unix on an 18-bit-physical address space machine with 16-bit addressing bear interesting similarities to what we have to do now on 36-bit mode Pentiums with 32-bit addresses. What goes around comes around ... ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: HOW to debug memory corruption efficiently?
I would give Insure a try if you can't afford Purify. Either one is better than just about anything else you'll find in the open source world. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: OS Textbook FreeBSD Appendix
On Mon, 28 Jan 2002, DOROVSKOY,IGOR (A-Portsmouth,ex1) wrote: I've took a brief look on Unix presentation and was wondering, why author says that ...most Unix systems have not permitted shared memory because the PDP-11 hardware did not encourage it...? where'd they get this? that's an odd statement. Shared memory was used all the time on Unix on -11s, that's the whole point of the shared text a.out format. Of course shared read-only text is not exactly the standard shared memory, but at the same time it shows feasibility. The address space was so small though that other mechanisms were used. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Reading BIOS from userland
A stupid little program you can use to dump the bios and hunt for version
strings etc.
default is to mmap the last 1MB of the 32-bit space and write it to fildes
1. optional arg 1 is the base (it gets 16 thanks to a strtol bug that
may no longer be there); optional arg 2 is the size.
Tested on just about everything linux, I don't see any obvious gotchas for
freebsd.
ron
#include stdio.h
#include fcntl.h
#include unistd.h
#include sys/mman.h
main(int argc, char *argv[])
{
int i;
volatile unsigned char *cp;
int fd;
volatile void *v;
off_t nvram = 0xfff0;
/* avoid linux mmap bug */
size_t length = 0x10 /*- 0x1000*/;
if (argc 1)
nvram = (strtol(argv[1], 0, 0)) 16;
if (argc 2)
length = (strtol(argv[2], 0, 0)) ;
if((fd = open(/dev/mem,O_RDWR)) != -1)
{
v = mmap(0, length, PROT_READ | PROT_WRITE, MAP_SHARED,fd,nvram);
fprintf(stderr, mmap returns %p\n, v);
if ( (int)v == -1)
{
perror(mmap);
exit(1);
}
} else {
perror(open /dev/mem);
exit(1);
}
write(1, v, length);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: switching to real mode
On Thu, 6 Dec 2001, Terry Lambert wrote: Dmitry Konyshev wrote: For some odd reason I need to load another OS (no matter which one, everything that known about it is its boot sector number) at the end of the reboot syscall. Could someone please explain how to switch processor to real mode and continue program execution from some point in low memory? you can check out the various linux-boot-linux programs that do this. It gets complex. Four examples: bootimg, LOBOS, two-kernel-monte, and kexec. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re[2]: switching to real mode
On Thu, 6 Dec 2001, Dmitry Konyshev wrote: I saw an example of switching in real mode in linux' sources (it looks pretty clear) and thouhgt it is possible to do the same under FreeBSD. The problem is I'm absolutely lost in FreeBSD's physical memory management implementation (page tables and directory and so on). That code is quite broken. You need to check out the ones I mentioned earlier. All that the code does in the linux kernel is fail badly. Actually there used to be in freebsd some really nice code for popping into real mode and back again. It was to support calling BIOS for certain things. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: switching to real mode
On Thu, 6 Dec 2001, Terry Lambert wrote: It isn't enough to do what he wants, though. He wants to effectively return to real mode and jump to a real mode boot strap loader, as if in the second stage of a boot manager, after the partition to boot has been selected (e.g. Reboot to Linux, Reboot to Windows, Reboot to XXX). I understand the desire now. It all depends on how much work he's willing to do. no, you are right. It's just that the freebsd code for this is a nice tutorial, then when he looks at bootimg or whatever it will be easier to understand. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: switching to real mode
On Thu, 6 Dec 2001, Ronald G Minnich wrote: no, you are right. It's just that the freebsd code for this is a nice tutorial, then when he looks at bootimg or whatever it will be easier to ^^^ NOT a typo. bootimg is Werner Almesberger's (LILO guy) linux-boots-linux code. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: switching to real mode
On Thu, 6 Dec 2001, Mike Smith wrote: As John said, actually, really going back to real mode is hard. It would be easier to just reboot the system, especially since we have probably left hardware in odd states. True. For two kernel monte and LOBOS we never leave protected mode before booting the new OS. Getting into real mode just isn't that important. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sysctls for hardware monitoring?
On Thu, 22 Nov 2001, Harti Brandt wrote: What's bad about using files? Just to be different? Isn't it easier to select, poll, kqueue, what ever on files than on sysctls? /proc files are horrible if you sample at reasonable rates, say 10-100 hz. We found (on Linux, maybe fbsd is better) that sampling rpc.rstatd at 10 hz. ate 10% of a 500 Mhz. PII. ouch. We also found that sampling rpc.rstatd took 10 MILLISECONDS on the same machine. Moving to sysctl we found we could sample at 1Khz. with no significant load on the machine. See the Supermon paper at ALS2001 for more info. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Duping a hard disk
On Tue, 23 Oct 2001, Peter Pentchev wrote: Is there anything wrong with dd(1)? A lot. Best way I found was dump | restore, i.e. mkfs /dev/newdisk mount /dev/newdisk /newdisk dump 0f - / | (cd /newdisk; restore rf -) or equivalent ... - yes, you can use tar, but you have to remember all the options - yes, you can use dd, if you don't mind copying EVERY BLOCK, including the ones full of zeros or that are unused - over the network, you can compress the data I dup'ed 64 machines this way once over the network and it went FAST. What we used to do is have a CD boot disk (we built one 128-node cluster with NO FLOPPIES -- floppies suck). It works well. Of course with the bproc stuff we are totally out of the disk dup business for clusters, but for desktops it is nice to be able to slam a cdrom in and have the machine initialized. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: clustering code
On Wed, 17 Oct 2001, Sergey Babkin wrote: And directly comparing the number of nodes with Beowulf-style clusters is not fair. The Beowulf clusters can be reasonably efficiently used only for a very limited class of problems with very high parallelism of subtasks, high computational complexity of each subtask and very low interactions between them. So they are a quite degenerated case and pretty useless for business applications. You can't use qualitative characterizations like high, high, very low for this. Do you have numbers? Basically I don't agree. But let's take this off the list. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: power supplies
On Sun, 30 Sep 2001 [EMAIL PROTECTED] wrote: I had almost exactly the same experience with a Tyan motherboard, excapt that it was not a network but video card in my case. Unplugging the power cord from the machine between removing one card and inserting another (or possibly the same) one has helped. Though I don't know why it happens. I've seen similar stuff although have not (yet) fried a PS. I've had chipset lockup that requred unplugging AC for 30+ seconds before it was resolved. A simple power cycle with the power switch was not sufficient. Bear in mind that power supplies are never really off any more. There is always power applied to motherboards as long as AC is hot. I expect that sloppy enough design could result in these types of problems. Soft power off is not as perfect. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: TCPIP cksum offload on FreeBSD 4.2
On Thu, 27 Sep 2001, Andrew Gallatin wrote: I just wanted to say that you did a hell of a job with the csum offload stuff in FreeBSD. FreeBSD is the only OS that I'm aware of which allows a driver to choose not to handle csum'ing IP frags on transmit. Having the option to not handle frags is very, very handy. I wish other platforms had it. I have a question on the checksum offloading. Has anyone measured any incidence of data corruption between the PCI card and memory. In other words, when you offload checksums the end-to-end checking becomes card-to-card checking, and the possibility exists that what goes in memory at the destination end is not what was sent at the source. Very remote possibility, of course, but ... It's not that the data gets corrupted (usually). It's that once-in-a-100-trillion errors could result in the occasional dropped half-packet or missed word (i.e. overflow). The missed word problem is usual a miscommunication between card and PCI chipset about how a PCI ABORT is supposed to work ... which we've seen on some very recent just-released chipset/network card combinations,. Does this happen? Yes. We've seen it on, to name just two, HIPPI800 and Myrinet cards. In each case it was not actual data corruption, it was can't happen DMA scenarios that once in a very long while (1 in 10^14 or so) resulted in bits of packets getting corrupted. Each of these cards has a very high-quality end-end CRC for the data, and Myrinet has flow control. We're not the only place that has seen this problem, and I've been told that many commerical Myrinet clients run IP over Myrinet because of these types of problems (of course FreeBSD has the fastest IP over Myrinet anyway, so it's not like that's a huge problem). Is it likely? Well, on one cluster here, with 48 machines and 12 interfaces per machine, it's not only likely, it's a given. Without software checksums you are going to get data corruption. What I don't know is whether offloaded checksums on commodity ethernet cards have seen anything similar. I assume that checksums across all the frags are done by the kernel (i.e. NFS would checksum the full UDP packet)? Has anyone measured to see if there is corruption occuring on the frags, ever? Of course it would probably take a while ... Thanks in advance for any information you might have. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: TCPIP cksum offload on FreeBSD 4.2
On Thu, 27 Sep 2001, Andrew Gallatin wrote: No, you're missing the point almost entirely. The checksum is not skipped. It is calculated by the DMA engine based on the data that's transferred across the I/O bus on the receiver (and / or the sender). If the data is incorrect as seen by the receiving nic, the checksum will be wrong and the packet will be dropped. you still have a potential problem here with variance in chipsets, namely the case of broken ABORT or other unusual PCI cycle handling (missed word problem). I agree it's a low probability. But we've seen it, just a week or two ago on a brand new box. But then we tend to see things here nobody else sees due to our scale. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: TCPIP cksum offload on FreeBSD 4.2
On Thu, 27 Sep 2001, Andrew Gallatin wrote: At this level, you're basically screwed. A sofware checksum isn't even an option on other PCI users, like disk controllers. If you don't trust your PCI chipset, what do you do about things like that? I'm rather curious -- what was the problematic hardware combination? Can't say yet :-( But it is one of the fancy network interfaces that essentially runs an RTOS on the NIC so it can help you. Actually fancy $5000 network interfaces are in general less reliable than your average garden-variety $2 IDE chip. Partly because they have so much capability. So we don't worry a lot about lossage with IDE. But it's a big problem on expensive, high end, high performance network interfaces. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: TCPIP cksum offload on FreeBSD 4.2
On Thu, 27 Sep 2001, Andrew Gallatin wrote: Geez. All I wanted to do was pat Jonathan on the back for coming up with what is apparently the most flexible and well though out mechanism out there. it's great work. I was mainly curious to see if anyone had measured this kind of problem. Thanks ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Routing Performance?
On Mon, 3 Sep 2001 [EMAIL PROTECTED] wrote: While not Intel, I understand the Alpha port is coming along nicely: http://www.api-networks.com/products/up1000-board.shtml http://www.api-networks.com/products/up1100-board.shtml http://www.api-networks.com/products/up2000-board.shtml The last is a dual processor alpha board. Alpha motherboards have generally better memory IO, including 2.6 Gb/Sec to main memory. Unfortunately it can only take 2 gig of RAM. It has dual 64 bit PCI busses though, and can be had with dual 64bit SCSI Ultra Wide on it. you do know that API just layed off (almost) all their alpha people, right? alpha is dead. Thank compaq any time. ron (who owns 112 Compaq Alpha boxes, and 16 API CS20s) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PCI Enumeration
On Sat, 25 Aug 2001, Mike Smith wrote: I/O space is easy, but memory space is hard. Userspace access to physical memory is a big no-no in the *nix world. I want to disagree just a bit. If you look at myrinet, or the many fpga cards, it's the standard modus operandi. You have to do it that way. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: the =+ operator
On Fri, 10 Aug 2001, Jan Knepper wrote: I just checked on this =+ and =- with the guy that wrote the first native C++ compiler and he does not recall it at first being that way... of course not. It had changed long before C++. You have to go back to 1976 to find this. I have been programming C++ myself for over 10 years and *never* heard this before. I do not know where it comes from. Guess I'll repeat it. Go find the original V6 Unix Documents for use with the Unix time sharing system and look in there. These were made available ca. 1976. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: exec() doesn't update access time
On Wed, 25 Jul 2001, David E. Cross wrote: In my case it would be usefull as I was trying to tell the last time 'telnetd' was run. (yes, not perfect, but better than nothing) well, for caching file systems it is very useful to have an exec set atime. Helps you figure out which files can be pruned from the cache. This sounds like a good fix. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: best way to migrate to a new disk
On Sun, 8 Jul 2001, Warner Losh wrote: In message Pine.BSF.4.21.0107071842230.58871-10@beppo Matthew Jacob writes: : tar cfl - . | (cd /altroot/local_fs tar xpf -) Don't use tar. It loses devices, can't handle holey files well and a number of other minor clitches. Use dump instead. yes, tar is a horrible way to do this. newfs /dev/whatever mount /dev/whatever /new cd /new dump 0f - /dev/your-root-device | restore rf - At least that's how I do it ... ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
cluster software: consider bproc
For those of you still looking at cluster stuff: I'd take a close look at www.scyld.com and see what they have. The key piece is bproc, which is now a sourceforge open source project set up by Erik Hendriks. You might want to look at bproc and see if that API could be implemented in FreeBSD. The Scyld cluster model results in clean, easily managed clusters. I've just brought up a 128-node Alpha cluster here with Scyld. You set up the front end and you're done. Even more fun, we're booting the first level out of FLASH via LinuxBIOS. I'd still like to see FreeBSD boot out of flash too, but don't have the time -- I'd be happy to work with interested parties though. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Interesting article.
On Sun, 15 Apr 2001, Robert Watson wrote: On Sun, 15 Apr 2001, Julian Elischer wrote: http://www.microsoft.com/backstage/column_T2_1.htm this gives a blank screen... maybe they removed it. I found I had some netscape interop problems. Trying hitting reload a couple of times. well there's a shock ... a microsoft web page not working with netscape? ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Snowhite and the Seven Dwarfs - The REAL story!
On Mon, 29 Jan 2001, Hahaha wrote: Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and polite with Snowhite. When they go out work at mornign, they promissed a *huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven Dwarfs enter... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Snowhite and the Seven Dwarfs - The REAL story!
On Mon, 29 Jan 2001, Ronald G Minnich wrote: On Mon, 29 Jan 2001, Hahaha wrote: Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and polite with Snowhite. When they go out work at mornign, they promissed a *huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven Dwarfs enter... uh, sorry about that last stupid email thing I just sent somehow. I'm not even sure what I did. Time for coffee. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Chuck Cranor's PhD thesis on VM
I am sorry I brought this up without a URL :-( I'm working on it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
cranor URL
A more complete one than the earlier one (though the earlier one is fine too). ron -- Forwarded message -- Date: Sun, 28 Jan 2001 19:10:05 -0500 From: Chuck Cranor [EMAIL PROTECTED] To: Ronald G Minnich [EMAIL PROTECTED] Subject: Re: Kernel Hacking (i tried not to make it lame) (fwd) On Sat, Jan 27, 2001 at 06:50:27PM -0700, Ronald G Minnich wrote: I mentioned your work, now I get this question over and over ... cool. the dissertation is at: http://www.ccrc.wustl.edu/pub/chuck/psgz/diss.ps.gz To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel Hacking (i tried not to make it lame)
I still think a really neat source for kernel hacking is Chuck Cranor's PhD thesis. He describes the kernel equivalent of open-heart surgery: replacing the old VM with a new one, while keep the kernel alive. Neat stuff. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Clustering FreeBSD
On Fri, 19 Jan 2001, Brooks Davis wrote: For those who want a simple, stupid way to do this, making an MPI application is a convenient first step. MPI is pretty similar to PVM except that I don't know of anyone in the high performance computing community that still uses PVM for new applications (I'm sure they exist, but they are not exactly common.) For some reason the Open Source community still has this bizare idea that PVM is the way to go. MPI is way to heavy for process spawning. We have measured appallingly long times here on our clusters, up to 30 seconds just to get things running on 64 nodes. I keep offering this, and keep getting no takers, but I do have a tool called vex that will get 128 processes running on 128 nodes in 1/2 second. See it at http://www.lanl.gov/~rminnich/. That's the level of performance you want for a start. It actually runs tons better on FreeBSD than on Linux due to Linux TCP silliness. You really want a single login, single IP address, cluster. There's an example: http://www.scyld.com. You need a process model that's much more capable than what we have now. Three ways to go that I can think of. The worst is to nfs-mount all the /proc on the front-end. Yuck. The second-coolest-thing to do is to build a "bproc"-like interface for freebsd. The absolute coolest thing is (do I repeat myself :-) put plan-9 style remote process and private name spaces into freebsd. Before you comment on the plan9 idea, if you have not read the docs, go read them. Bproc gives you a global name space for processes, which is ok but not as scalable as the plan9 approach. But the Scyld stuff is quite nice, we're using it here on two clusters. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Clustering FreeBSD
Sorry, the wrong URL. http://www.acl.lanl.gov/~rminnich ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: keeping lots of systems all the same...
I just redid the autocacher in totally GPL'ed form. the paper on the original one is at http://www.acl.lanl.gov/~rminnich The new one is much simpler and works well. This could be useful, it gives you a caching file system for NFS. let me know if interested. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DSM Facility for FreeBSD
On Thu, 30 Nov 2000, Tim Tsai wrote: Also, my requirements are significantly more relaxed than a true DSM model (and much more lightweight is preferred).. I really just need synchronized views of data on a "reasonable" effort basis (i.e. it's OK if one client/peer sees slightly older data. Sequence is important though). check out http://www.acl.lanl.gov/~rminnich, see zounds. Worked well for me on clusters. The only DSM I've ever seen that supports IP multicast for updates. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
pci maps
if your cards are on pci bus 0, not behind a bridge, you can set the base addresses to pretty much any value you want even after the OS is up -- you just have to make sure the drivers are all informed. But it's no big deal, you can do it from user mode if you have access to ports cf8/cfc. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Boot off USB SanDisk?
On Fri, 20 Oct 2000, David Miller wrote: Would FreeBSD have any idea how to boot off such a beast? Alternatively, anyone know of an ISA/PCI adapter with enough bios on it to boot off a similar flash? Put it in millenium disk-on-chip, 60 MB (soon) in the 32-pin DIP slot found on most mainboards nowadays (yes, they have moved from surface mount back to dip!) I'm booting to single-user in 3 seconds using these things. The IDE delays are high, even for Flash IDE, so going for the socket is a good thing. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Adaptec AIC 7899 SCSI
On Fri, 6 Oct 2000, Danny Braniss wrote: anyway, NT: ok FreeBSD: 4.1.1 does not see it BSDi: 4.1 does see the controller but does not find any disks Linux: not yet tested. works here. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: anonymous memory map vs mmap on /dev/zero
On Wed, 4 Oct 2000, FengYue wrote: It seems that mmap on /dev/zero is more portable. no really, It won't work at all correctly on linux, and on Tru64 it does the totally wrong thing, but the (fd = -1, MAP_ANONYMOUS) does the right thing on tru64. It's disappointing that this works so unportably :-( ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPC, shared memory, syncronization AND threads...
On Wed, 16 Aug 2000, Peter Jeremy wrote: Here's a simple test-and-set function for the 386 (tested and works): Actually, this isn't particularly good coding. It isn't SMP-safe. you caught me! I'm a lousy assembly programmer! Actually, that code is so old it predates SMP by a bit ... I like your improved version ... that one goes in my archives. Thanks! ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPC, shared memory, syncronization AND threads...
OK, here's a note from long ago, when this came up before.
Dated: Tue Jul 2 10:48:16 1996
The idea is simple: tset is the fastest, but you only want to spin so
long. Then you want to drop into the kernel, and wait for someone to wake
you up. This thing was quite fast on freebsd, even four years ago. In fact
I have yet to see anything faster, but I'm willing to be corrected.
--
Here's a simple test-and-set function for the 386 (tested and works):
int
tset(int *i, int lockval, int unlockval)
{
int j = 0;
asm("movl 16(%ebp), %eax");
asm("movl 8(%ebp),%ecx");
asm("movl 12(%ebp),%edx");
asm("cmpxchg %edx, (%ecx)");
asm("jne failed");
asm("movl %eax, -4(%ebp)");
asm("jmp done");
asm("failed: movl %eax, -4(%ebp)");
asm("done:");
return j;
}
This will run a bit faster than a file lock system call :-). But what about
contention? notice that this function, if it fails, fails. so we need a
retry strategy. IF you fail, should you spin forever? NO! Do that, and
you eat the processor doing nothing. You ought to have a reasonable way
to, say, spin one or two more times, then go to a more heavyweight sleep.
SO: here's the fastlock library call (#ifdef USEMOD is for LKM )
void
fastlock(int *address, int lockval, int unlockval)
{
int testval;
#ifdef USEMOD
static int syscallnum = -1;
if (syscallnum 0)
syscallnum = syscallfind("fastlock");
if (syscallnum 0) {
perror("fastlock syscallfind");
return;
}
#endif
testval = tset(address, lockval, unlockval);
if (testval == unlockval) {
#ifdef FASTLOCKDEBUG
printf("(%d)fastlock quickout\n", getpid());
#endif
return;
}
/* attempt to lock failed. test then wait in kernel sleep() */
while (1)
{
/* set the high-order bit. This tells the unlocker to do the system
* call and free up the lock.
*/
(void) tset(address, testval|0x8000,testval);
#ifdef FASTLOCKDEBUG
printf("(%d)hang in there\n", getpid());
#endif
/* we should be checking here to make sure that high-order bit is
* set. But this second tset fails only
* in the event of contention, in which case
* someone else has set the high-order
* bit too ... seems pointless, esp. given that fastlock has a timeout
*/
syscall(syscallnum, 1, address, unlockval);
testval = tset(address, lockval, unlockval);
if (testval == unlockval)
return;
}
}
So what are we doing? We're doing the tset. If it fails, then we do one
more tset, to set the high order bit, then drop into the fastlock system
call. Once we return from that, we try to tset the variable again. If
that fails, we drop once again into the system call.
Here's fastunlock:
void
fastunlock(int *address, int unlockval)
{
int dosyscall = 0;
static int syscallnum = -1; /* this is really in the file */
#ifdef USEMOD
if (syscallnum 0)
syscallnum = syscallfind("fastlock");
if (syscallnum 0) {
perror("fastunlock syscallfind");
return;
}
#endif
if (*address 0x8000)
dosyscall = 1;
*address = unlockval;
#ifdef FASTLOCKDEBUG
printf("(%d)fastunlock dosyscall is %d\n", getpid(), dosyscall);
if (dosyscall) printf("conflict %d\n", getpid());
fflush(stdout);
#endif
if (dosyscall)
syscall(syscallnum, 0, address, unlockval);
}
Ok, this one tests to see if it needs to wake any sleepers, clears the
memory variable, then drops into the kernel if needed (if (dosyscall) ...)
Here's the system call. Note several things:
1) the definition of 'unlocked' is passed in to the system call for the
final test, not assumed to be zero.
2) The 'address' argument does NOT NEED TO BE AN ADDRESS. it's a number
that all the procs have to agree on, that is all.
3) if you accidently awake more than one sleeper, the loop in fastlock
handles that properly
4) This system call handles both waking up and sleeping
5) For my measurements, this thing is a whole lot faster than anything
else available on (e.g.) freebsd. Questions to me.
int
fastlock(p, uap, retval)
struct proc *p;
struct flu *uap;
int retval[];
{
extern int hz;
retval[0] = 0;
/*
printf("fastlockunlock: com %d address 0x%x unlocked %d\n",
uap-com, uap-address, uap-unlocked);
*/
if (uap-com == 0) /* unlock */
wakeup((void *) uap-address);
else
{
/* last chance */
/* try one last time to see if it is unlocked */
int curval = fuword((void *) uap-address);
if (curval == uap-unlocked)
return;
tsleep((void *) uap-address, PUSER, NULL, 10*hz);
Re: IPC, shared memory, syncronization AND threads...
On Tue, 15 Aug 2000, Jonas Bulow wrote: After doing some more thinking about the cmpxchgl-lock, it's quite hard to use it together with a technique involving the kernel. well, no I don't think it is. I used to use it a lot, see my earlier post from today. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Linux NVIDIA drivers vs. default XFree86 drivers (WAS: RE: Videocard support)
actually you're not even getting kernel driver source for linux. What you're getting is an ugly binary blob that looks like the guts of an NT driver, plus enough source stuff to let the kernel hook to the binary blob. It's not pretty. And, as you might expect, it's a little prone to failure. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
On Mon, 19 Jun 2000, Neil Blakey-Milner wrote: On Thu 2000-06-15 (15:25), Ronald G Minnich wrote: 'linuxbios' will only support booting off Linux partitions? linuxbios is getting to be a misnomer, but ... linuxbios is a simple chunk of FLASH-based code that gunzips a kernel image to RAM. That's it. It doesn't do much of anything but get DRAM turned on (not hard) and some other bits that OSes don't yet do well. Although, I am finding that increasingly the open source OSes are taking on more and more hardware tasks because so many BIOSes screw up hardware config. The APIC support in the more recent kernels is pretty amazing. LinuxBIOS DOES NOT: 1) read disks 2) talk to network cards 3) etc. It knows how to get ram up, it is mostly written in C (except for that 'get ram up' part, obviously), and it counts on the OS to do the heavy lifting. It works on two very different motherboards. We're working on an Alpha port now. Our long term goal is not to control this thing. Best case scenario is the vendors buy in and support it directly. We have one case in hand where this is happening. Mainboards from this one vendor will ship with LinuxBIOS in flash. We have a couple of industrial partners at this point, including a new one that just wrote me this morning who you would recognize (you'll see their name on the web page in a week or so). I would love to see FreeBSD support work. I can't do it much anymore, since unfortunately the HPC cluster community seems less and less concerned with FreeBSD nowadays, which I think is a tragedy. But I'll do what I can. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd bios.
On Mon, 19 Jun 2000, Parag Patel wrote: It's fairly simple, other than dealing with the various motherboard/chipset vagaries. So far those vagaries are not much code, something like 200 lines tops. It's possible to make a complete BIOS based on Linux that in turn loads and boots another kernel, but that I don't think that this is what the LinuxBIOS folks are attempting. Actually, we aren't attempting it, we've got it working. see the LOBOS paper on the www.linuxbios.org web page. One option is that we start linux from NVRAM, talk to a DHCP server, and as a result we suck a kernel down over the network and boot it. Linux (or FreeBSD) make far more capable network boot programs than such things as PXE. And LinuxBIOS is SMALLER than the Intel BIOS it replaces. You can get complicated. LinuxBIOS loads, talks to DHCP, is sent some KLDs, the KLDs drive the boot device, and so on. So the thing in NVRAM can be little more than a netboot. A number: sun's net bootstrap is 200K. Instead they have (or will have) access to the flash from within Linux to load a kernel directly into flash (along with its startup code) rather than placing it into /. (Please correct me if I'm wrong.) You have both options. We're going to use them. Personally, I'd set it up to hold two kernel images - one for testing and one for emergency recovery. If a bad kernel gets into the flash, recovering will be ... painful. But there may not be enough room. There will be enough in future, next generation mainboards have 2 MB or more flash. My cheap DFI mainboard at home has 2 MB flash. For now, there is enough room in current mainboards, and more to come (I am told that the current driver for flash is MP3 players, which only demand more and more and more and ...) ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd bios.
sorry, jordan. my bad. Anyway we're going to try a kernel next week that parag sent me. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd bios.
(paul asks a good microcode question). I can't answer it yet. Here's my take on this: we're going to do a proof of concept of this idea. We now have three partners: SiS, Compaq, and Dell. Long-term goal is to get industry to pick it up. This is a means to an end. I don't want to be Mr. LinuxBIOS forever . If it works, my life is easier: I've got a totally open source BIOS. If I want to net boot over Myrinet, no problem. If I want to net boot over SCI, no problem. There is lots of other stuff I get *if this works*. I can use a 100 mbit/second network for node maintenance instead of a 9600 baud serial port (am I the only guy who is amazed that we're STILL using 9600 baud to run our consoles?) If it doesn't work, well, that's a datapoint. If it doesn't work on everything out there just yet, That's not failure. We were in this same boat in 1991, and things worked out in spite of a lot of doomsayers. I'll specify in my next cluster RFQ that It Must Run LinuxBIOS. Simple. Companies who want to play, can. Those who don't, won't. But what the heck, it's been a lot of fun. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
On Fri, 16 Jun 2000, Parag Patel wrote:
No-one else seems to be interested.
actually, that's not quite true. we're seeing a fair amount of interest
here. I suspect vendors are not that interested in supporting another BIOS
unless/until they see potential $$$ ("value proposition" in MBA speak). We
seem to have found a workable value proposition here. It won't cost them
anything, and they get the results of our work on sourceforge.net, and
there may be competitive advantage in the Linux market at some point.
I think Parag's work is quite good but he has a tougher job than we do.
but we'll see how it all plays out :-)
ron
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
On Thu, 15 Jun 2000, Stefan Molnar wrote: Why? PXE will allow net installs, or diskless. And Serial Console is already supported. ( On some high end machines serial console works in the prom as well). well, now you see why i'm not pushing linuxbios too hard in the freebsd world. If you think PXE and serial consoles fix your cluster problems, then you haven't build anything really big. PXE is not a good design. But I'm not interested in arguing ... ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
freebsd bios.
So, I repeat: easily done, not acceptable to freebsd core. I think this situation reflects on the freebsd community and not in a positive way. If you care, sometime this year you'll be able to buy motherboards that boot Linux from flash. SiS is working hard on this and has committed people and hardware. So if you want that capability, you'll get it with Linux, not FreeBSD. Not because it's not doable, it's because people don't seem to get it. It's kind of a shame. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
On Thu, 15 Jun 2000, Sergey Babkin wrote: Mike Smith wrote: I'd suggest you go talk to Parag Patel, who's just wasted about three months of his life trying to make SmartFirmware run on _one_ supposedly well-documented board. Parag is nobody's fool, and I consider his results pretty representative of the issue. I just mentioned to mike that parag has been talking to me for the last while, and in fact is encouraged enough by recent results that he's taking another look. Maybe I'm completely mistunderstanding the subject, but what about EFI (Extendable Firmware Interface) ? It's the We're looking at it. Do you really believe in reference implementations? I don't. I sure hope they've stopped zeroing memory on reset ... this is one of the drivers for linuxbios. But it is still interesting. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd bios.
here's what we can. Somebody send a kernel for an L440GX+ that has pretty minimal stuff. I'd prefer it to have IDE, no networking, no SCSI, i.e. a pretty small thing. I'll try to use it as the payload for linuxbios and see if it boots. The key is that freebsd may need to change a few things to make it bootable from cold hardware. I don't think this is for sure, but it may happen. I hope the team is receptive to such changes ... ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rexec as root
On Fri, 12 May 2000, Nick Sayer wrote: I would like to gather some opinions in regards to _very slightly_ backing off on rexec's security. rexec makes the following checks, and refuses to allow usage if any are true: uid == 0 I turned off this check at sarnoff six years ago. rexec allows you to quickly run lots of commands across a cluster, given the right tool (see http:/www.acl.lanl.gov/~rminnich and look at vex). Using rexec I could run commands across a 128-node cluster in less than a second. Nothing I have ever seen is nearly as fast. A secure low-overhead remote exec is the right thing; rexec with uid == 0 disabled is the next-best thing. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel's GX managment port client, or any hints on the specs?
On Fri, 21 Apr 2000, Anthony Bourov wrote: We host a whole bunch of servers, all FreeBSD, and many of them run on intel GX motherboards, which have a feature called EMP. Basically, I didn't go to much detail into this, I got that it is a way to monitor/control the server through modem/null-modem client. But they provide their own client-NT/95 only of course, and it didn't look like the communication is clear text. Does anyone know if anyone was planning to write something for this, or if there are specs available. I probably don't need the know monitoring thing, just a way to do a remote reset. argonne is working on scripts to talk to this. Don't know how far they got. I think EMP is stupid, personally, but worse, it's the usual "this is proprietary" story from Intel. We're doing this: www.linuxbios.org instead. And, oh yeah, with our reset you won't reboot with zero'd memory. You get your syslog back, for example. You could if you wanted get an 'OS core dump' like the good old days. In general, are there any good remote reset solutions, one that would invoke a hard reset, but not one of those that will completely cut the power to the server, and then turn it back on, I found that it's pretty likely to get problems if you use that enough. Not really at present. Hard to believe but lotsa people still think remote power off is a good reset solution. bleah. ah, just joking, but I was thinking of buying one of these: http://www.draganfly.com/products_4eh.html put a little camera and solenoid on it, then have it fly around and hit reset on our cluster from the convenience of my cube :-) Less joking: buy 128 solenoids, screw them to the front of your nodes, make them remote control, voila, remote reset :-) Seriously: get rid of that crummy intel bios and put something in there that will give you some actual capability. Think about it, the L440GX has a 100,000,000 bps network yet uses a 9,600 bps management network. Ridiculous. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel's GX managment port client, or any hints on the specs?
On Fri, 21 Apr 2000, Parag Patel wrote: Well, OK, that and I toasted the board. Or bent a pin - not sure really. Hey, there's an idea I like. Toasting the board. Get a nice campfire going and toast the board. cool. Should go well with hotdogs and marshmallows. Did you get actual good docs with that mainboard? ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is traditional unixes kernel really stable ?
On Fri, 7 Apr 2000, Gustavo V G C Rios wrote: What all you think about that ? I think you need to do a literature search for, oh, say, six months and get back to us. You'll need to read ca. 256-512 or so articles. I'm not kidding. You should start reading papers from the 1960s. And oh yes, don't ignore Plan 9 just because it doesn't fit a convenient category. Also, go ahead and look at NT, but put it in the "successful marketing covering for bad implementation" column. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
How good a job of PCI config will freebsd do?
Question, has anyone tried booting freebsd on raw hardware, i.e. absent a bios? I am curious as to how good a job it can do if, e.g., no enable bits are set in PIIX4, BARs are not set on PCI devices, no IRQs are assigned, and so on. Anyone feel they are close enough to this to say? See www.acl.lanl.gov/linuxbios to see why I am asking. I see no reason I could not also put FreeBSD as the BIOS in nvram as well. If you're trying to build a cluster, you have to kill the BIOS. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How good a job of PCI config will freebsd do?
On Wed, 29 Mar 2000, Mike Smith wrote: Yeep. You don't know Fra Dolcini, do you? That looks like a Really Unpleasant Undertaking. 8( It's getting there. Also SiS is now a supporter. Long term, we may see motherboards specifically designed for the OSS community, with real docs yet. Also, I can't see any way to get to 3-second reboot (one of the things we need) given the stupid way BIOSes work. PXE is not an answer. cluster hardware over for a pile of IA64 boxes just yet, but it strikes me that it'd be easier just to write a userland flash updater than to rewrite the BIOS from scratch. 8) You haven't look at how intel designs and documents some of their motherboards, particularly the L440GX+. They won't tell people what they need to know to update flash on this one. Result: you have to boot DOS to upgrade flash. Stupid of them. Also, there are an amazing number of advantages to having a real OS in the flash. Once you start thinking about it, it becomes hard to live without. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
How a normal user can crash any linux system (fwd)
anybody want to try this on -current? ron -- Forwarded message -- Date: Wed, 22 Mar 2000 16:02:40 +0100 From: Michael Lampe [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: How a normal user can crash any linux system I found the following by accident playing with PVM. If you start the 'gexample' from the examples directory with dimension=1 and no of tasks=32 on one machine, it becomes almost immediately completely un- usable and begins with heavy swapping. Considering how much memory would be necessary for this computation before starting it would have avoided the trouble. So the processes go on allocating memory until physical memory and swap is exhausted. At this point processes are killed and now things are really becoming interesting: One would expect that the misbehaving gexample processes are killed or maybe other processes started by the same user. Actually random processes are killed: I've seen klogd, syslogd, cron, gpm and inetd disappear. In some cases the machine was unaccessible locally as well as remotely, but the kernel seemed to be still running -- ping showed the machine still up. Apart from the specific system processes that are killed, the problem can be reproduced under many different configurations. I have tried SuSE 6.0 with kernel 2.2.12, SuSE 6.2 with kernel 2.2.14, LinuxPPC R4/R5 (Red Hat 5.x based) with some recent 2.2.x kernels and finally the SuSE pre-release for PPC. PVM was 3.4.x. Any comments - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Copy-on-write filesystem
On Fri, 3 Mar 2000, Michael Bacarella wrote: Can someone tell me why copy-on-write filesystems would be bad? It's a good idea. Peter Braam and I have written a device (called memdev) for linux (sorry!) that implements a virtual-memory-backed copy-on-write block device (like the loopback device, but uses anon vm pages for store). It's pretty interesting. It's quite fast, and copy-on-write does seem to work OK for a filesystem. I'm using this thing as one of two pieces of a new private name space implementation that would also work quite well on freebsd. note it's not really a file system, but a loopback block device which does copy-on-write for new blocks. You can also use it to easily implement translucent file system behaviour. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re/Fwd: freebsd specific search
On Wed, 2 Feb 2000, Michael Bacarella wrote: Granted, a lot of Linux distributions are totally unsuited for a server environment. Compared to that, I could understand why the server-orientedness of FreeBSD is attractive, but I certainly couldn't put up a reasonable arguement for either side in Slackware Linux vs. FreeBSD. Linux is definitely a less reliable system for clustering than freebsd. I've got 5 years of running them both at Sarnoff to back me up. Maybe I was doing something wrong, but I'm seeing similar problems here at the ACL on Linux. We ran into four classes of problems that linux had that freebsd did not. These problems are still not fixed as of 2.2.x or 2.3.x. 1) network stack. heavy use of udp can result in a hung kernel. Trivial TCP servers that need to take lots of connections cause trouble -- clients start getting ECONNREFUSED after a while 2) nfs. Hit nfs hard and random clients will hang. The dirty little secret of linux clusters is that 'everyone knows' that you don't run client nfs on linux cluster nodes if you want the cluster to stay up. This came out clearly at a cluster conference last spring (JCP4). 3) vm system. There's still some strange problems in there. 4) ext2. ext2 does not handle unplanned outages well. There is a reasonable chance that after a power fail you're going to have trouble if you have 100 nodes or more. You'll see 2 or 3 in need of help. freebsd was just more solid on our clusters. But note that linux isn't standing still -- it's just not as good as freebsd yet. I had one freebsd cluster that ran through 5 years of anything we could throw at it -- power fail, etc. It took disk death to finally halt one node and require me to hook up a keyboard to it to reload it. Our general experience was that NT fails a lot, esp. if you ask it to talk to a network or run a screensaver. Linux clusters run a long time, but power outages and other unplanned events will cause it trouble. Freebsd tolerates very high levels of abuse. The UFS guys really know their stuff. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: perfmon
You also might want to check out SGI's PCP tools. I know, they're only out for linux just now, but they are nice and could be ported. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rfork() [was: Concept check]
On Wed, 12 Jan 2000, Luoqi Chen wrote: It's almost a regular fork(), we lose all the advantages of a single address space. A rfork(RFMEM) wrapper can achieve the same level of usability without sacrificing the performance, and IMO is a preferred solution. I don't see this at all. You get many of the advantages of the single address space: everything is shared save the stack. Most people who have brought this up over the years want this type of behaviour, and find themselves having to hack it in user mode, and not enjoying the experience. I used this very version of rfork extensively for years for shared-memory programming and it was fine. Anyway, if I get to this it goes on my web page .. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rfork() [was: Concept check]
On Wed, 12 Jan 2000, Alexander Litvin wrote: Matthew Dillon [EMAIL PROTECTED] wrote: :BTW, concerning rfork(RFMEM). Could somebody explain me, why the :following simple program is coredumping: You cannot call rfork() with RFMEM directly from a C program. You have to use assembly (has anyone created a native clone() call yet to do all the hard work?). OK, I'd like to propose another option to rfork to make it a little more usable for mortals. The option is RFSTACK. This will cause rfork to work like my original version, in that the stack segment (all memory from USERSTACK and up) will be cloned. This would really make a big improvement in rfork usability. Comments? ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: modifying an object file
you can do this kind of thing with the bfd tools ... ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting a new MAP_ flag into mmap() prior to 4.x freeze
good flag. If you look at my old mnfs stuff you can see our solution : we ignored sync :-) This is a good move. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ELF putting inode at the front of a file
On Mon, 6 Dec 1999, Zhihui Zhang wrote: I have modified FFS filesystem code to put the disk inode at the beginning of a file, i.e, the logical block #0 of each file begins with 128 bytes of its disk inode and the rest of it are file data. first question I have is, why? ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ELF putting inode at the front of a file
On Mon, 6 Dec 1999, Zhihui Zhang wrote: I am doing some research on filesystem. I guess it may be faster to put the disk inode with its file data together so that both can be read into memory in one I/O. I still don't get it. To get the file, you do a lookup. So the inode is in memory. The you call the handler for the executable. But the inode is in memory at this point what am I missing? ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tmpfs .. ?
Sorry I missed this question. Check www.acl.lanl.gov/~rminnich for v9fs and see if you can use it. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: memory-to-memory copy
On Wed, 1 Dec 1999, Zhihui Zhang wrote: I used to know that memory to memory copy is done by the DMA controller in the I/O bridge (Actually, this knowledge confues me because DMA controller Now, that brings back memories :-) check out the original dma chip design, ca. infinite years ago. Wow, did freebsd ever use this for bcopy? Hard to see that it would pay ... I know that early 8086 code did use it though. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: wacky rpc.lockd idea...
On Mon, 22 Nov 1999, David E. Cross wrote: I've noticed about 99% of the panics on our machines are the result of NFS, more often than not it is the result of a backing store file being blown away underneath the client. ie. person editing a file on one machine, compiling and running on a second, then removing the binary on the first machine. If we had a working lock manager could we not have the kernel open a shared lock on anything it had in backing store, would that not assure that files didn't go poof in the night? I think you're really proposing to add state to NFS, but add it via a 'back door', the lockd. I think this is not as good an idea as getting coda or intermezzo working -- for the latter, www.inter-mezzo.org nfs is just plain broken for this sort of thing, and has been forever. I'm not sure you want to start grafting on fixes of this sort. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A file with holes - a bug?
On Mon, 22 Nov 1999, Zhihui Zhang wrote: lseek(fileno(fp), 3 * 8192, SEEK_CUR); don't mix things that use file descriptors with stdio. End of problem. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, that's it, enough is enough! (rpc.lockd)
Actually I wrote a system call for opening a file given a file handle for freebsd a while back (oh, gee, has it really been 5 years ...), as part of mnfs i'll try to find it. You don't need to map it to a filename to make it go. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
On Wed, 27 Oct 1999, Chuck Youse wrote: One of the biggest reasons for the difference: FreeBSD, by default, performs _synchronous_ metadata updates, and Linux performs asynchronous metadata updates. It's definitely a bit slower, but the payoff is in reliability. I have seen more than one [production!] Linux machine completely trash its filesystems because the implementors decided that their "NT-killer" must have good performance at the expense of serious, production-quality reliability. To put it slightly more strongly: as far as I'm concerned ext2 is not a serious fs if you really care about handling power failures and other such fun things. In clusters as small as 64 machines I've measured a 5% probability that after a power failure one of the 64 ext2 file systems will have a trashed root file system. With freebsd, over a four-year span, running through lots of power outages, I didn't lose an FFS file system even *once* (except for the disk that burned up, but not even FFS can fix that one). ext2 needs a lot of help. Evidently it will be getting it soon, though. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why FFS is THAT slower than EXT2 ?
On Wed, 27 Oct 1999, Ilia Chipitsine wrote: as far as I remember ext2 has some "counter". I used to use Linux and it performed 'fsck' from time to time (even if fs was clearly unmounted). that is a very good thing to have. And it's a good thing because ... well, maybe because it's not that reliable an FS. I actually can't see it as a good thing if you have a file system that doesn't need it. I do not recall that FreeBSD did such thing. It might not have needed to. It never has in five years for me. The numbers are from my old job at sarnoff, see my web page ... for a while in 1997-99 we had "things go wrong" about once a month. Over the space of 18 months as "things went wrong" we found ourselves having to fix at least one Linux box each time. On average it was four. I DID lose FFS even it was mounted "sync", not async. I guess I was lucky :-) anyway, I'll drop this thread, just trying to fill in some info. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: return to real mode
well, I'll go check that. I'm finding that there is fair amounts of code out there that is broken. Thanks to the wonderful PC bios you have a hard time sometimes telling the difference between code that crashes into the bios and code that actually works right, since the result is the same either way :-) rn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NFS and RPC
You have a lot mixed up here. On Thu, 23 Sep 1999, Zhihui Zhang wrote: Once inside the kernel, the NFS daemons can not use RPC library any more, they must create/interprete RPC format messages themselves. My guess this is for performance reason and because there is no kernel-to-kernel RPC. There is kernel-to-kernel RPC. NFS in the kernel on both client and server sides use RPC. They don't use -lrpc though ... Since the kernel part of NFS code does not use RPC library routines, why FreeBSD still conforms to the RPC format for NFS requests/replies? Is this for compatibily with other NFS servers/clients that are implemented entirely as user-level code and with RPC library routines? Because some NFS servers run in user mode (automount, amd, early linux, even *very* early sunos). Some clients run in user mode too (mostly evil hacker software ... but also Bigfoot, see www.acl.lanl.gov/~rminnich) One more question is about how to assembly a RPC request from several mbufs? I notice that there is a check for 0x8000 in the routine nfsrv_getstream() for the last fragment. that's to support rpc over tcp. You need to look at the code again. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
the only portable user ids are names as strings. you can kludge and kludge but at some point the kludges will pile up too high, fall over, and hurt somebody. how many new options did we see proposed in the last 12 hours for this problem? ron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
I lost track of the quotes. | --- With the help of Veritas Software Corp., SGI will work to add | key features of its Irix operating system to the Linux platform. | Currently, Irix runs on the MIPS platform. Once SGI switches | entirely to Intel Corp.'s IA/64 platform, that will be the end of | Irix. | | SGI is also forming an alliance with NEC Corp. to increase its | market share in Japan. These paragraphs are contradictory. It implies an end to MIPS. an end to irix and an end to MIPS on desktop and server platforms has no big effect on MIPS processors. The big volume for MIPS is embedded, or so I am told. For an interesting take on all this visit www.mipsabi.org ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
On Mon, 16 Aug 1999, Terry Lambert wrote: The concept of private namespaces does not exist on FreeBSD. It would require a modification of the lookup mechanism, and, potentially, a seperation of credentials from the process into a session manager. Yeah but you can fake it pretty well without such mods. I've done it once already on linux and the same techniques I used would work on freebsd. But I can't get anyone interested :-( ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
On Mon, 16 Aug 1999, Mike Smith wrote: But I can't get anyone interested :-( Uh, we're all interested; where's the code? v9fs is the first piece. The servers are done. But I'm mostly out of the freebsd hacking business at this point (except for maybe via drivers) so I need some help to get the rest of it plugged into freebsd. I'm no longer supported to do this kind of thing. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: shared memory crash
don't use shmget if you can. Use mmap'ed files. The SYSV shm interface is incredibly dumb. ron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
I lost track of the quotes. | --- With the help of Veritas Software Corp., SGI will work to add | key features of its Irix operating system to the Linux platform. | Currently, Irix runs on the MIPS platform. Once SGI switches | entirely to Intel Corp.'s IA/64 platform, that will be the end of | Irix. | | SGI is also forming an alliance with NEC Corp. to increase its | market share in Japan. These paragraphs are contradictory. It implies an end to MIPS. an end to irix and an end to MIPS on desktop and server platforms has no big effect on MIPS processors. The big volume for MIPS is embedded, or so I am told. For an interesting take on all this visit www.mipsabi.org ron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
