Re: stuck NFS procs (LONG)
Ah!... ok, it is an NFS bug. I've been trying to track this down
for a while ever since you reported the 3.4 lockup bug. This is probably
related to a similar problem.
There is a bug somewhere related to NFS locking up while doing a
pagein from the executable image. It can occur when the binary
is ripped out from under the client but it also can apparently occur
if the program takes a signal during a pagein on a valid binary
that hasn't been ripped out.
If you still have this machine up, can you idle it and do a tcpdump
looking for NFS packets for a few minutes? I'd like to know if it is
doing an infinite retry of the page it got stuck on. Knowing what
it is trying to do and why it isn't aborting on error with a segfault
is the key.
After that, is there any chance you can panic this machine and get
a kernel dump?
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:(kgdb) back
:#0 mi_switch () at ../../kern/kern_synch.c:825
:#1 0xc0131781 in tsleep (ident=0xc054b220, priority=4,
:wmesg=0xc01ff83c "pgtblk", timo=0) at ../../kern/kern_synch.c:443
:#2 0xc014ea7c in allocbuf (bp=0xc532ec08, size=8192)
:at ../../kern/vfs_bio.c:1805
:#3 0xc014e5b0 in getblk (vp=0xca69b240, blkno=185, size=8192, slpflag=0,
:slptimeo=0) at ../../kern/vfs_bio.c:1566
:#4 0xc0180cde in nfs_getcacheblk (vp=0xca69b240, bn=185, size=8192,
:p=0xcac45520) at ../../nfs/nfs_bio.c:914
:#5 0xc017f9db in nfs_bioread (vp=0xca69b240, uio=0xcacbdf10, ioflag=8323072,
:cred=0xc16d4180, getpages=0) at ../../nfs/nfs_bio.c:409
:#6 0xc01a5204 in nfs_read (ap=0xcacbdec8) at ../../nfs/nfs_vnops.c:963
:#7 0xc0159f4f in vn_read (fp=0xc16268c0, uio=0xcacbdf10, cred=0xc16d4180,
:flags=0) at vnode_if.h:303
:#8 0xc013a06d in dofileread (p=0xcac45520, fp=0xc16268c0, fd=3,
:buf=0x805a000, nbyte=65536, offset=-1, flags=0)
:at ../../kern/sys_generic.c:179
:#9 0xc0139f77 in read (p=0xcac45520, uap=0xcacbdf94)
:at ../../kern/sys_generic.c:111
:#10 0xc01ea777 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 1,
: tf_esi = 65536, tf_ebp = -1077945672, tf_isp = -892608540, tf_ebx = 0,
: tf_edx = 16, tf_ecx = 13, tf_eax = 3, tf_trapno = 0, tf_err = 2,
: tf_eip = 134515596, tf_cs = 31, tf_eflags = 582, tf_esp = -1077945796,
: tf_ss = 39}) at ../../i386/i386/trap.c:1100
:
:
:I'll stop here.
:
:--
:David Cross | email: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: stuck NFS procs (LONG)
Ah!... ok, it is an NFS bug. I've been trying to track this down for a while ever since you reported the 3.4 lockup bug. This is probably related to a similar problem. There is a bug somewhere related to NFS locking up while doing a pagein from the executable image. It can occur when the binary is ripped out from under the client but it also can apparently occur if the program takes a signal during a pagein on a valid binary that hasn't been ripped out. If you still have this machine up, can you idle it and do a tcpdump looking for NFS packets for a few minutes? I'd like to know if it is doing an infinite retry of the page it got stuck on. Knowing what it is trying to do and why it isn't aborting on error with a segfault is the key. After that, is there any chance you can panic this machine and get a kernel dump? I can come close to idle... It should be realtively easy to identify the NFS packets in question, they will be stale FH replies from the server (as I pulled the backing store out from under it hoping that the retry would trigger a SEGV). Panic-ing it will be a bit trickier... the kernel is compiled with DDB *BUT* the only console is a serial console and I forgot to enable the ENABLE_DB_ON_SERIAL_BREAK thing-y. I am sure with gdb -k /kernel.debug /dev/mem and your expertise we could trip a panic somehow. For now, let me get you that NFS packetlog... -- David Cross | email: [EMAIL PROTECTED] Acting Lab Director | NYSLP: FREEBSD Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: stuck NFS procs (LONG)
I just ran a tcpdump -s1500 for 5 minutes, gathered ~21k of data over that time, no mentions of stale NFS handles from the NFS server... it would appear the NFS client is not asking for those pages (it makes sense, since if it asked and got the 'stale' error one would expect the SEGV). -- David Cross | email: [EMAIL PROTECTED] Acting Lab Director | NYSLP: FREEBSD Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
bpgetfile
Solaris has this nifty little tool for querying the bootparam server on a booting system. Handy little gadget for getting various system configuration at boot time. Neither OpenBSD nor FreeBSD have it (FreeBSD has callbootd, but I cannot get it to work easily), so I wrote a simple 'bpgetfile' for the CSLab to use for some of our diskless systems. The code is available at http://www.cs.rpi.edu/~crossd/FreeBSD/bpgetfile.tar.gz Have fun. -- David Cross | email: [EMAIL PROTECTED] Acting Lab Director | NYSLP: FREEBSD Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Device driver KLD module
History: I had a device driver for a BDM (Background Debug Module for Motorola 683xx CPUs) that worked fine as a kernel device and a LKM. It was based upon the LPT driver, because it attached to the parallel port, and the JOY LKM, cause it was simple. Present: I have updated the driver, it does work as a kernel device. It does not work as a KLD. It does not print its startup nor create a device. It was updated to match the current JOY KLD. It also appears the JOY KLD may not be working. Questions: 1) Does the JOY KLD actually work? What is the simplest way to test it. I have a joystick, but not sure how to read info from it. 2) If not I will fix it, if possible, while fixing my BDM. 3) Looking around it would seem that the VESA KLD might be the simplest KLD to look at. Is this true, or is there a better one? My source for the BDM driver is available, for anyone who wants to peek, is at: http://bdm.thehousleys.net/bdm.tgz . The full page with some more info is at: http://bdm.thehousleys.net . Thanks for all help. Jim -- microsoft: "where do you want to go today?" linux: "where do you want to go tomorrow?" BSD: "are you guys coming, or what?" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re:Device driver KLD module
If you want you may see my KLD drivers. Two of them for ISA and one for PCI bus. http://www.cronyx.ru/software/#sigma (version 3.2) Kurakin Roman PS I am not in the list. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
Patryk Zadarnowski wrote: You're being just plain silly. It takes about 5 minutes with the manuals to realize just how little AXP and IA-64 have in common: one is a classic superscalar out-of-order design, the other is just about the opposite: a typical explicit-ILP architecture. What makes IA-64 great is the 8 years of statistical analysis of real-life software the architecture design team spent fine-tuning the instruction set. What makes AXP great is the clock rates Digital/Compaq manages to pump into the beasts ;) What makes IA-64 great is the fact that it has not been deployed, so Intel can say whatever it pleases them. If you got REAL LIFE NUMBERS, based on REAL LIFE PERFORMANCE, then we can talk. Let's see how it does Quake, then we can talk. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "If you consider our help impolite, you should see the manager." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bpgetfile
"David E. Cross" wrote: Solaris has this nifty little tool for querying the bootparam server on a booting system. Handy little gadget for getting various system configuration at boot time. Neither OpenBSD nor FreeBSD have it (FreeBSD has callbootd, but I cannot get it to work easily), so I wrote a simple 'bpgetfile' for the CSLab to use for some of our diskless systems. The code is available at http://www.cs.rpi.edu/~crossd/FreeBSD/bpgetfile.tar.gz Cool. Wanna wrap it in a port and send-pr it? ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Recommended addition to FAQ (Troubleshooting)
I recently installed FreeBSD on my daughter's machine, remotely. She'd been on Windows3 since growing up and moving away from my NeXT, so "UNIX" wasn't a scary word to her, and she was getting tired of "Windows95 or better" on anything she was interested in, and certainly wanted "better" if she was going to change anyways. Well, just for a quickie, so she could play with it long enough to be familiar with it before moving on to FreeBSD, we tried to install Windows95, first. The install bombed three times, and we thought it was a scratched CD-ROM. VMM32 something-or-other failed to be installed each time, or so the bluescreen said AFTER what was supposedly a complete (minimal) install. So, boom, take the 3.2-STABLE diskettes I'd prepared ... boot up fine ... mfs mount CRASHRe-installed Windows3 (95 had thoroughly messed the drive) ... got back on line, got 3.4-RELEASE diskette images and fdimage.exe ... just to be sure, wrote the diskettes three times each from the .flp files. Again, good boot UNTIL the mfs mount. CRASH... So, Win3.1 was still installed on the hard drive, this time, downloaded 2.2.8 boot.flp in hopes that the smaller footprint would install (this is a K6-300 64Mx9-bit system with NO BIOS errors showing, and fast-boot turned off!). It did. Had slight problems getting PPP logged in (the username required a provider prefix). Started the install. Got to about slice 15 or so of the first distribution and BOOM... Kernel fault AGAIN! I can't praise highly enough, two software packages: http://reality.sgi.com/cbrady_denver/memtest86/ and http://www.qcc.sk.ca/~charlesc/software/memtester/ The former is a bootable image memory tester, built from some pieces of LiLo, Linux Kernel, and some good algorithms that sweep flat memory. The latter is a user-space utility that has different algorithms, and built for FreeBSD pretty easily (I've submitted my modifications to the author for a 2.2.8 build -- I don't have any hosts - yet - running 3.x). BOTH of these quickly identified flakey RAM that a supposedly full BIOS sweep of RAM totally missed, and that had caused "normal crashes" with her old Win3.1 installed. I'd really like to recommend that memtest86 be placed in tools/ from now on, including a pre-compiled .flp image. Anybody who's built a kern.flp and mfsroot.flp, or a boot.flp, will have NO problem creating a stand-alone i386 and up, memory tester from the "memtest.bin" file in the ZIP distribution, or the "precomp.bin" in the source .tar.gz Both are .flp images with a custom bootstrap loader. Similarly, I'd like to recommend that the user-space memtester be at LEAST added to the ports, although it wouldn't hurt to have it as a GPL'd part of the base distribution. For people who reboot rarely, it probably wouldn't hurt to run that one just before multiuser startup on every reboot. With the slight tweak I sent the author, the creation of a port for this should be trivial - and might not even be needed with the later FreeBSD versions. The reason I'm sending this to the DOC list, is that at a bare minimum, this info needs to be added to the FAQ and/or manual. To the hackers list because everybody reads it :) and I'm recommending changes to the distribution. Bruce Gingery [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
If you got REAL LIFE NUMBERS, based on REAL LIFE PERFORMANCE, then we can talk. Let's see how it does Quake, then we can talk. Alpha does quake? :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Recommended addition to FAQ (Troubleshooting)
On Fri, 18 Feb 2000, Bruce Gingery wrote: I can't praise highly enough, two software packages: http://reality.sgi.com/cbrady_denver/memtest86/ and http://www.qcc.sk.ca/~charlesc/software/memtester/ Sweet! I never knew that I've wanted one for all of these years until I saw you talking about them. :) Any OS vendor would do good to package these kinds of tools. -MB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
: Alpha does quake? :-) It supposedly does under Linux, at least (and if you're talking about Quake I). Sources at: http://www.idsoftware.com/q1source/ These sources might need a bit of work, even for Linux, though there are folks out there who have it running under Linux/Alpha. I'd assume a FreeBSD port would only be moderately difficult, if that. This is the sum total of what I know about this... -Ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Recommended addition to FAQ (Troubleshooting)
The situation here, I hate to say, is that you were simply very lucky in having a software memory tester show you anything at all. If your experience had been more typical, you would have run memtest86 and it would have declared your memory to be free of errors. Then you'd have gone right on having problems and losing more hair until you finally just came back to the memory and swapped it out on suspicion. Bingo, the problems are suddenly fixed and you're dragging memtest86 to KDE's trashcan with a resolve to never trust it again. The reason why software memory testers are so generally ineffectual is that there's a whole bunch of things getting in their way. Leaving aside for the moment the nasty problem of having your memory checker loaded into the bad memory in question, the cache also seriously gets in your way (and I'll bet you never even thought to turn both L1 and L2 caches off, did you? :-) by masking errors in a way which is transparent to the program. How's it supposed to know its accesses are getting cached or how much cache it has to "defeat" to get meaningful access to main memory? It can't, really, at least not in a way that's truly foolproof or workable across the entire range of Intel/AMD CPUs it might be run on, and that's why serious bench techs use hardware memory testers exclusively. I've used all kinds of software memory checkers, from "CheckIt" to highly proprietary packages that cost even more money, and the only thing they managed to convince me of is that swapping in known-good memory is the best and fastest way out of these situations. Unless you have a hardware memory tester available, trying to test it yourself is just too likely to give you a false sense of security and send you down more blind alleys. I've even put known BAD memory into boxes and had CheckIt tell me "looks good to me, boss!", just to verify my suspicion that it had lied to me before. It's also very slow to run a software memory tester without the caches enabled and swapping the memory is generally a whole lot faster than that. I'm impatient. :) So, to summarize, I am actually somewhat against the idea of including tools like this on the grounds that they can also help to convince people of the wrong things while they're debugging a problem. I also don't look forward to having to argue with users who've just run such tests and are still getting signal 11's but now refuse to believe that the memory could be bad because "they checked it." If I then turn around and tell them not to trust the tool I also stuck on the CD for them, they're going to ask why I put it there in the first place and a nice long argument will then ensue instead of us just replacing that damn memory and moving on. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Recommended addition to FAQ (Troubleshooting)
"Jordan K. Hubbard" [EMAIL PROTECTED] wrote: I've used all kinds of software memory checkers, from "CheckIt" to highly proprietary packages that cost even more money, and the only thing they managed to convince me of is that swapping in known-good memory is the best and fastest way out of these situations. Unless I'll second this. I've had memory problems in the past, and every memory checker I used said that the memory was good. Only by swapping out the bad memory (I don't have access to an hardware memory checker) was I able to fix my problems. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Recommended addition to FAQ (Troubleshooting)
On 18-Feb-00 Darryl Okahata wrote: "Jordan K. Hubbard" [EMAIL PROTECTED] wrote: I've used all kinds of software memory checkers, from "CheckIt" to highly proprietary packages that cost even more money, and the only thing they managed to convince me of is that swapping in known-good memory is the best and fastest way out of these situations. Unless I'll second this. I've had memory problems in the past, and every memory checker I used said that the memory was good. Only by swapping out the bad memory (I don't have access to an hardware memory checker) was I able to fix my problems. -- Darryl Okahata [EMAIL PROTECTED] Every "good" software based memory tester I have ever used took so long to tell me anything I could have gone to the store, bought more memory, and swapped it before it was done. I don't think adding it to the ports tree would be bad for those who are desperate, but deffinatly list it as a "basic" memory tester. Nicole DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message [EMAIL PROTECTED] |\ __ /| (`\ http://www.unixgirl.com/ [EMAIL PROTECTED] | o_o |__ ) ) http://www.dangermouse.org/ // \\ ---(((---(((- -- Powered by Coka-Cola and FreeBSD -- -- Stong enough for a man - But made for a Woman -- -- Microsoft: What bug would you like today? -- --- -- As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Defending against buffer overflows.
My attention has just been called to: http://immunix.org/StackGuard/mechanism.html Given all of the buffer overrun vulnerabilities that have been found in various network daemons over time, this seems like a worthwhile sort of technique to apply when compiling, in particular, network daemons and/or servers. I don't entirely agree with this fellow's approach however. I think that the ``canary'' word should be located at the bottom end of the current stack frame, i.e. in a place where no buffer overrun could possibly clobber it. Seems to me that this would be a nice and useful little enhancement for gcc. I wouldn't mind having something like a -fbuffer-overrun-checks option for gcc, and I would definitely use it when compiling network daemons. Anybody else got an opinion? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
[ My apologies if this is a repeat - my earlier mail didn't seem to make it ] On Fri, 18 Feb 2000 12:03:37 +1100, Patryk Zadarnowski [EMAIL PROTECTED] wrote: On the other hand, IA-64 is a very exotic architecture from the OS's point of view, and anyone planning to port *BSD to it should probably start planning ASAP. I'm a former Intel employee and I have worked on the Linux IA-64 project. I think there is plenty of planning to do to get an OS running on IA-64, which is more complex than most other architectures I've known. First of all - there is plenty of reading to do: http://developer.intel.com/design/ia-64/manuals/index.htm http://devresource.hp.com/devresource/Docs/Refs/IA64ISA/index.html Some of the design decisions to make: (a) Programming model - LP64 would probably be the most sensible (b) Page table architecture IA-64 supports both the long and short format VHPT (virtual hash page table). Linux chose to use the short format - which really uses no hashing. Linux has the concept of machine independent multi level page tables and has generic algorithms which manipulate them in machine independent code. Where possible, it tries to map them to hardware dependent page tables. On architectures like IA-64 and Power PC, this becomes a little awkward and Linux essentially treats hardware page tables as TLBs. The problem with the above approach is duplication of information between Linux page tables and hardware page tables and inefficient use of memory for page tables. I think OSes like FreeBSD which don't have a concept of machine independent page table are essentially free to do anything in the hat layer and thus have more flexibility. On Linux/IA-64, such duplication is avoided by having a 3 level page table and overloading the L3 page table with the hardware page table functionality. In a nutshell, all L3 page tables are mapped in a region in the *virtual* address space, such that to get the vtop translation for address P, you can just index into this "linear" virtual page table. Because the page table is in *virtual* address space, recursive faults are possible. A significant chunk of the virtual address space has to be reserved for this sparse, linear page table. The other alternative is to use a global hash page table and walk the collision chains in software. The advantage of this scheme is savings in terms of both physical memory and virtual address space, but a heavier dependence on the hardware implemented hashing algorithm's characteristics. It isn't really clear which one is superior, but FreeBSD's VM architecture allows a choice. (c) Handling the register stack on system call entry and exit Sparc has shown how frequent register stack flushing can offset the good effects of register stacks. IA-64 has some nice tricks which can be used to avoid the flush. (d) Restarting of system calls and interactions with the register stack Linux does this by using a gcc directive which was created for this purpose. The normal calling conventions allow input registers to be treated as scratch. But under this directive they will be preserved, so that system calls can be restarted. The disadvantage of this approach is compiler specific code (which Linux has not been averse to in the past) and some register allocation inefficiency in the kernel. The alternate approach is to return ERESTART from the system call, catch the error in libc and restart the system call with saved args. Other general notes: - Writing assembly code is tricky and writing efficient assembly code is trickier - Lots of architectural state to keep track of - Implementing setjmp and longjmp is tricky, because of the interaction with the register stack - Errata, lack of support can be worked around by looking at Linux sources I'd love to have technical discussions about the IA-64 architecture from an OS perspective, if anyone on this list is interested. Since last September, I've moved on to a new daytime job, which has nothing to do with operating systems or kernels. I have a limited amount of spare time and I'm willing to help out with a IA-64 port, if the FreeBSD project decides to pursue it. -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
:... :and Linux essentially treats hardware page tables as TLBs. : :The problem with the above approach is duplication of information between :Linux page tables and hardware page tables and inefficient use of memory :for page tables. : :I think OSes like FreeBSD which don't have a concept of machine independent :page table are essentially free to do anything in the hat layer and thus :have more flexibility. If I understand the hardware hash table method correctly, then I think the absolute best choice for FreeBSD is to use that method as it will allow us to get rid of the scaleability problems we have with the pv_entry_t scheme we use for IA32. The number of pv_entry_t's in an IA64 architecture wind up being fixed. How big can we make the hardware-assisted hash table? Also, a hash table scheme is a much better fit for a 64 bit address space model, especially with sparse mappings. The MIPS R4K and later all use a hash table scheme and it seems to work well for them. :I'd love to have technical discussions about the IA-64 architecture :from an OS perspective, if anyone on this list is interested. : :Since last September, I've moved on to a new daytime job, which has :nothing to do with operating systems or kernels. I have a limited amount :of spare time and I'm willing to help out with a IA-64 port, if the :FreeBSD project decides to pursue it. : : -Arun : -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
You're being just plain silly. It takes about 5 minutes with the manuals to realize just how little AXP and IA-64 have in common: one is a classic superscalar out-of-order design, the other is just about the opposite: a typical explicit-ILP architecture. What makes IA-64 great is the 8 years of statistical analysis of real-life software the architecture design team spent fine-tuning the instruction set. What makes AXP great is the clock rates Digital/Compaq manages to pump into the beasts ;) What makes IA-64 great is the fact that it has not been deployed, so Intel can say whatever it pleases them. If you got REAL LIFE NUMBERS, based on REAL LIFE PERFORMANCE, then we can talk. Let's see how it does Quake, then we can talk. This is rapidly becoming a stupid flame war so in the interest of keeping the list on-topic, I won't be replying publically to this thread from now on. ;) I *do* have some performance figures, as Intel has had the silicon for over six months now, but, of course, Intel being Intel, their lawyers keep everything under a wrap for now. Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: scsi target mode
Olaf Hoyer wrote: a. settings on the controller card (e.g. scsi id, termination) b. freebsd configuration on the initiator and target PCs. (e.g. do we use scsi_pt.c, scsi_target.c, etc). here's a diagram depicting what we want to do. we're trying to setup a PC (PC2 below) with an adaptec controller to act as an emulated disk. PC 1 will access the disks on PC 2. __ __ | PC1| scsi cable|PC2 scsi bus| | adaptec 2940 | = | adaptec 2940 disk | | SCSI ID=7 | | SCSI ID=0SCSI ID=5 | |__| |__| Hi! Well, I'd rather try (for simplification) following combo: I won't connect the two 2940 directly. What's the problem ? The only trick is to get termination right: enable it at the ends of the bus and disable it in the middle. Otherwise there is nothing special and I use configurations like this (mupti-path I/O and clusters) routinely at work. Also independently of the location of the cards on the bus you may have to disable the Adaptec BIOS to get the machines booted. But getting the Adaptec working as a target device may be quite tough if possible at all because it's firmware mey not be able of that. The card of choice for target applications is Symbios 8xx. Symbios even provides an example of a simple disk simulator for DOS in theis driver developer's kit. The next obstacle is that AFAIK scsi_target.c is not implementation of a target device. It is a pass-through interface for the host to pas sthe commands to any otherwise un-identified SCSI device. Some time ago I've written the target mode code for the Symbios cards, including a simple disk emulator (to the degree that it looked like a disk but did not store anything written to it) and a SCSI extender through FastEthernet. This was my little private enterprise but now as its commercial value is zero I feel ready to give the code. But the last version to which I ported it was early '98 3.0-current, so it would need considerable efforts to be ported to the current -current. And the software is not of production but of more prototype level of quality: it generally works but if errors or unexpected conditions happen they are not handled well. Actually, I'm even willing to port it, clean up and provide a generic target mode API if the FreeBSD core team would agree to commit it to the system. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
On Fri, Feb 18, 2000 at 04:06:55PM -0800, Matthew Dillon wrote: If I understand the hardware hash table method correctly, then I think the absolute best choice for FreeBSD is to use that method as it will allow us to get rid of the scaleability problems we have with the pv_entry_t scheme we use for IA32. The number of pv_entry_t's in an IA64 architecture wind up being fixed. How big can we make the hardware-assisted hash table? Smaller than 2**64. Minimum is 2**15. Also, a hash table scheme is a much better fit for a 64 bit address space model, especially with sparse mappings. The MIPS R4K and later all use a hash table scheme and it seems to work well for them. Madhu Talluri's paper on page tables for 64 bit address spaces claims that having collision chains is expensive - for 8 bytes of mapping information, the pointer and tag storage overhead is 16 bytes. Though page table space is important, in the age of big memory computers, I think performance and manageability are more important. -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: scsi target mode
Wilko Bulte wrote: On Tue, Feb 15, 2000 at 04:00:28PM -0600, David Scheidt wrote: Generally speaking 'joining' machines into cluster(like) you want to use differential SCSI buses. Yes. Of course, I think that you want to use differential SCSI for everything. Cableing is much easier, and much less fussy. It costs more though. And consumes a bit more power due to all the external diff xceiver chips. For in-cabinet single-ended or LVD works just fine. http://www.scsipro.com They make the Y-connectors. They also make the retranslators that can increase the maximal length of the cable dramatically (or at least their web site says so - did not try it myself yet). For the good and reasonably priced cables and terminators I can recommend AESP (http://www.aesp.com , http://www.tla-group.com is the reseller I bought from, had quite good experience). Personally I think that Fibre Channel may be a better choice for the clusters because of thinner cables and longer maximal length. Though it's more expensive. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
:... :and Linux essentially treats hardware page tables as TLBs. : :The problem with the above approach is duplication of information between :Linux page tables and hardware page tables and inefficient use of memory :for page tables. : :I think OSes like FreeBSD which don't have a concept of machine independent :page table are essentially free to do anything in the hat layer and thus :have more flexibility. If I understand the hardware hash table method correctly, then I think the absolute best choice for FreeBSD is to use that method as it will allow us to get rid of the scaleability problems we have with the pv_entry_t scheme we use for IA32. The number of pv_entry_t's in an IA64 architecture wind up being fixed. How big can we make the hardware-assisted hash table? Also, a hash table scheme is a much better fit for a 64 bit address space model, especially with sparse mappings. The MIPS R4K and later all use a hash table scheme and it seems to work well for them. Kevin Elphinstone did a PhD thesis on TLB structures for 64 bit address spaces and it turns out that hash tables perform quite poorly. I'd suggest GPTs instead, or maybe LPCtrie that Chris Szmajda has been working on here at UNSW. Both have the advantage of supporting multiple page sizes that IA64 (and Alpha) offer, and hence dramatically increasing the TLB coverage over what Linux (or any other commercial OS that took a bite at IA64) can achieve. Kevin's paper's at: ftp://ftp.cse.unsw.edu.au/pub/users/disy/papers/Elphinstone:phd.ps.gz Maybe that way we can somehow make use of the Itanium's 4GB page size ; Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
On Sat, 19 Feb 2000 12:10:14 +1100, Patryk Zadarnowski [EMAIL PROTECTED] wrote: Kevin Elphinstone did a PhD thesis on TLB structures for 64 bit address spaces and it turns out that hash tables perform quite poorly. I'd suggest GPTs instead, or maybe LPCtrie that Chris Szmajda has been working on here at UNSW. Both have the advantage of supporting multiple page sizes that IA64 (and Alpha) offer, and hence dramatically increasing the TLB coverage over what Linux (or any other commercial OS that took a bite at IA64) can achieve. Kevin's paper's at: ftp://ftp.cse.unsw.edu.au/pub/users/disy/papers/Elphinstone:phd.ps.gz Thanks for the great pointer. IA-64 short format = Linear virtual arrays described in this paper. Long format = conventional hashed page table. Page 116 on LVAs in the paper talks about the disadvantages of using the short format: (a) Increased TLB misses (b) Memory overhead similar to multilevel page tables I don't know if clustered page tables can be implemented with the hardware support present in IA-64. More investigation is needed. Maybe that way we can somehow make use of the Itanium's 4GB page size ; The best thing is the abilitity to have large pinned TLB entries - they're called TRs (translation registers) in the manuals. Linux for example maps all of kernel memory with one huge TR. This also accomplishes the traditional Linux way of mapping all of physical memory into kernel virtual. -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
