no lo0 device on kernel boot
I've beat up my friends enough on this one... 4.1-RELEASE on an i586 scsi box from micron, de0 ethernet and ppp0 running out a serial port. I built a custom kernel (make depend, make, make install) and booted it. After much hair-pulling, it turns out there was no lo0 device configured. So I modified rc.conf to force network_interfaces="lo0 de0" and all that does is cause it to display a message at boot time that lo0 is not present. After even more hair-pulling, I've discovered the following: Both the generic kernel (the result of the original installation, not a result of a build of GENERIC; although a build of GENERIC also behaves the same), and my custom kernel behave the same: 1. When installed as /kernel and booted as the default (i.e. hands off) there is no lo0 device present. 2. When the boot process is intercepted and they are manually booted using: boot: 0:da(0,a)/boot/loader /kernel the lo0 device is present. When first installed from the release cd, I don't know whether the kernel booted properly or not, because I didn't have networking set up and wasn't paying any attention to the lo device. So... Any ideas about what the heck is going on and how to fix it? I'm running out of hair, and I didn't have that much to start with... Gary Aitken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm_pageout_scan badness
ok, since I got about 6 requests in four hours to be Cc'd, I'm throwing this back onto the list. Sorry for the double-response that some people are going to get! I am going to include some additional thoughts in the front, then break to my originally private email response. I ran a couple of tests with MAP_NOSYNC to make sure that the fragmentation issue is real. It definitely is. If you create a file by ftruncate()ing it to a large size, then mmap() it SHARED + NOSYNC, then modify the file via the mmap, massive fragmentation occurs on the file. This is easily demonstrated by issuing a sequential read on the file and noting that the system is not able to do any clustering whatsoever and gets a measily 0.6MB/sec of throughput (on a disk that can do 12-15MB/sec). (and the disk seeks wildly during the read). When you create a large file and fill it with zero's, THEN mmap() it SHARED + NOSYNC and write to it randomly via the mmap(), the file remains laid on disk optimally. However, I noticed something interesting! When I dd if=file of=/dev/null bs=32k the file the first time after randomly writing it and then fsync()ing it, I only get 4MB/sec of throughput. If I dd the file a second time I get around 8MB/sec. If I dd it the third time I get the platter speed - 12-15MB/sec. The issue here has to do with the fact that the file is partially cached in the first two dd runs. The partially cached file shortcuts the I/O clustering code, preventing it from issueing read aheads once it hits a buffer that is already in the cache. So if you have a spattering of cached blocks and then read a file sequentially, you actually get lower throughput then if you don't have *any* cached blocks and then read the file sequentially. Verrry interesting! I think it may be beneficial to the clustering code to issue the full read-ahead even if some of the blocks in the middle are already cached. The clustering code only operates when sequential operation is detected, so I don't think it can make things worse. large file == at least 2 x main memory. -- original response -- Ok, lets concentrate on your hishave, artclean, artctrl, and overview numbers. :-rw-rw-r-- 1 news news 436206889 Dec 3 05:22 history :-rw-rw-r-- 1 news news 67 Dec 3 05:22 history.dir :-rw-rw-r-- 1 news news 8100 Dec 1 01:55 history.hash :-rw-rw-r-- 1 news news 5400 Nov 30 22:49 history.index : :More observations that may or may not mean anything -- before rebooting, :I timed the `fsync' commands on the 108MB and 72MB history files, as note: the fsync command will not flush MAP_NOSYNC pages. :The time taken to do the `fsync' was around one minute for the two :history files. And around 1 second for the BerkeleyDB file... This is an indication of file fragmentation, probably due to holes in the history file being filled via the mmap() instead of filled via write(). In order for MAP_NOSYNC to be reasonable, you have to fix the code that extends a file via ftruncate()s to write() zero's into the extended portion. :data getting flushed to disk, then it seems like someone's priorities :are a bit, well, wrong. The way I see it, by giving the MAP_NOSYNC :flag, I'm sort of asking for preferential treatment, kinda like mlock, :even though that's not available to me as `news' user. The pages are treated the way any VM page is treated... they'll be cached based on use. I don't think this is the problem. Ok, lets look at a summary of your timing results: hishave overv artcleanartctrl 38857(26474)112176(6077)12264(6930) 2297(308) 22114(28196)136855(6402)12757(7295) 1257(322) 13614(24312)156723(6071)13232(6800) 324(244) 9944(25198) 164223(6620)13441(7753) 255(160) 2777(50732) 24979(3788) 29821(4017) 131(51) 31975(11904)21593(3320) 25148(3567) 5935(340) Specifically, look at the last one where it blew up on you. hishave and artctrl are much worse, overview and artclean are about the same. This is an indication of excessive seeking on the history disk. I believe that this seeking may be due to file fragmentation. There is an easy way to test file fragmentation. Kill off everything and do a 'dd if=history of=/dev/null bs=32k'. Do the same for history.hash and history.index. Look at the iostat on the history drive. Specifically, do an 'iostat 1' and look at the KB/t (kilobytes per transfer). You should see 32-64KB/t. If you see 8K/t the file is severely fragmented. Go through the entire history file(s) w/ dd... the fragmentation may occur near the end. If the file turns out to be fragmented, the only way to fix it is to
Re: vm_pageout_scan badness
:> I'm going to take this off of hackers and to private email. My reply :> will be via private email. : :Actually, I was enjoying the discussion, since I was learning something :in the process of hearing you debug this remotely. : :It sure beats the K&R vs. ANSI discussion. :) : :Nate Heh. Well, I didn't think there'd be as much interest as there is, so I guess I'll throw it back onto the mailing list. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm_pageout_scan badness
> I'm going to take this off of hackers and to private email. My reply > will be via private email. Actually, I was enjoying the discussion, since I was learning something in the process of hearing you debug this remotely. It sure beats the K&R vs. ANSI discussion. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
most efficient/precise monotonic clock for I686_CPU?
What is the most efficient way to get a relatively precise (say, at least millisecond) time value that is guaranteed to inrease monotonically (even if, say, xntpd adjust the system clock), either portable, or FreeBSD-specific? Is there some user library for using the Pentium performance clock thingy? I have, of course, looked at gettimeofday(2). Is this what I should be using? Does it involve a system call? -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
In message <[EMAIL PROTECTED]> Andrew Gallatin writes: : I'd vote for leaving the access permissions as is. I'd agree with that. We don't know that all PCI hardware will not cause problems when arbitrary locations in config space are read. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD random for Alpha?
On Wed, 22 Nov 2000 15:18:27 +0200, Sheldon Hearn <[EMAIL PROTECTED]> wrote: >Anyone want to have a look at this? It's from the GNU awk maintainer. >- --- Forwarded Message > >From: Aharon Robbins <[EMAIL PROTECTED]> >Date: Wed, 22 Nov 2000 11:59:10 +0200 >Message-ID: <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: BSD random for Alpha? >Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > >Hi. I've switched to the new random.c you sent me for gawk. My >Linux/Alpha Guru reports that the code in it assumes that sizeof(long) >is always 4, and one particular test doesn't "look" very random on >the Alpha. > >My question is, is there a better version of random that can deal >with both 32 and 64 bit systems in the same source code? Would >the NetBSD people maybe have such a thing? Try a Fibonacci-sequence random number generator (they're mentioned in Knuth). The general form is: X[n] = (X[n-j] + X[n-k]) mod m where m is any power of 2 (implying that the same generator can be used with any word-size) and k-j > 15. Knuth includes a table of `good' values for j and k. The period is >> 2^k. Off the top of my head (24,55) is a good pair. (The only downside according to Knuth is a lack of theory to explain the behaviour, though this may have been rectified in the 25(?) years since it was written). The normal implementation is an array of size k with two indices representing [n-j] and [n-k], which wrap as appropriate. The initial values should not be all even. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Arg! Siginfo and pthreads again
> On Sun, 3 Dec 2000, Peter Dufault wrote: > > Again I've forgotten that SIGINFO dumps the pthread info and created > > several gigabytes of /tmp files: > > > > > rt% rm /tmp/uthread* > > > /bin/rm: Argument list too long. > > > > I don't consider it bad form to use SIGINFO to see if processes are > > still around without first installing a SIGINFO handler. > > Can't you use `kill -0 pid` if you just want to see if the process > is around? Yes, I can and I should. I guess I forgot. I'll fix my code. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
M_ZERO patches.
I'd like to commit a large chunk of the remaining M_ZERO patches I've collected up later this week. These patches touch various parts of the system, so I'd apreciate if people could take a look at them. http://www.maths.tcd.ie/~dwmalone/mzero.patch I've listed the files it effects below. It is rather long, so to try to even out which bits of it get looked at, I've put a letter beside some of the files. If you have 10 minutes to spare then start at the letter your name begins with and keep going 'till you're fed up! David. sys/compat/linux/linux_mib.cA sys/contrib/dev/oltr/if_oltr.c sys/dev/ccd/ccd.c sys/dev/eisa/eisaconf.c sys/dev/fb/fb.c sys/dev/ida/ida.c B sys/dev/kbd/atkbd.c sys/dev/kbd/atkbdc.c sys/dev/kbd/kbd.c sys/dev/lmc/if_lmc.c sys/dev/lmc/if_lmc_fbsd3.c C sys/dev/lnc/if_lnc_pci.c sys/dev/md/md.c sys/dev/musycc/musycc.c sys/dev/null/null.c sys/dev/pdq/if_fpa.cD sys/dev/ppbus/ppbconf.c sys/dev/ppbus/vpo.c sys/dev/rp/rp.c sys/dev/rp/rp_isa.c sys/dev/rp/rp_pci.c E sys/dev/si/si.c sys/dev/syscons/syscons.c sys/dev/vn/vn.c sys/fs/devfs/devfs_devs.c sys/fs/devfs/devfs_vfsops.c F sys/fs/hpfs/hpfs_vfsops.c sys/i386/i386/busdma_machdep.c sys/i386/i386/i686_mem.c sys/i386/i386/k6_mem.c sys/i386/i386/mp_machdep.c G sys/i386/i386/nexus.c sys/i386/i386/userconfig.c sys/i386/i386/vm_machdep.c sys/i386/isa/cy.c sys/i386/isa/if_ar.cH sys/i386/isa/if_sr.c sys/i386/isa/intr_machdep.c sys/i386/isa/isa_compat.c sys/i386/isa/istallion.c sys/i386/isa/rp.c I sys/i386/isa/stallion.c sys/i386/isa/bs/bsfunc.c sys/i386/isa/bs/bsif.c sys/ia64/ia64/busdma_machdep.c sys/ia64/ia64/sscdisk.c J sys/isa/atkbdc_isa.c sys/isa/fd.c sys/isa/isa_common.c sys/isa/pnpparse.c sys/isofs/cd9660/cd9660_vfsops.cK sys/kern/kern_conf.c sys/kern/kern_descrip.c sys/kern/kern_event.c sys/kern/kern_jail.c sys/kern/kern_linker.c L sys/kern/kern_mutex.c sys/kern/kern_sysctl.c sys/kern/link_elf.c sys/kern/subr_blist.c sys/kern/subr_bus.c M sys/kern/subr_kobj.c sys/kern/subr_prof.c sys/kern/subr_rman.c sys/kern/tty.c sys/kern/tty_pty.c N sys/kern/tty_snoop.c sys/kern/uipc_socket.c sys/kern/uipc_syscalls.c sys/kern/vfs_init.c sys/kern/vfs_subr.c O sys/kern/vfs_syscalls.c sys/miscfs/union/union_vfsops.c sys/msdosfs/msdosfs_vfsops.c sys/net/bpf.c sys/net/bridge.cP sys/net/if.c sys/net/if_ef.c sys/net/if_sl.c sys/net/if_tap.c sys/net/if_tun.cR sys/net/rtsock.c sys/netatalk/at_control.c sys/netatalk/ddp_usrreq.c sys/netinet/in.c sys/netinet/in_hostcache.c S sys/netinet/in_pcb.c sys/netinet/ip_dummynet.c sys/netinet/ip_fw.c sys/netinet/tcp_input.c sys/netipx/ipx.cT sys/netipx/ipx_ip.c sys/netipx/ipx_pcb.c sys/netipx/spx_usrreq.c sys/netnatm/natm_pcb.c sys/nfs/nfs_nqlease.c U sys/nfs/nfs_srvcache.c sys/nfs/nfs_syscalls.c sys/ntfs/ntfs_subr.c sys/ntfs/ntfs_vfsops.c sys/pc98/i386/userconfig.c V sys/pc98/pc98/fd.c sys/pc98/pc98/syscons.c sys/pc98/pc98/wd.c sys/pc98/pc98/wd_cd.c sys/pc98/pc98/wfd.c W sys/pc98/pc98/wst.c sys/pci/if_fxp.c sys/pci/if_mn.c sys/pci/if_tx.c sys/pci/isp_pci.c XY sys/pci/ncr.c sys/pci/pci.c sys/pci/pci_compat.c sys/pci/simos.c sys/ufs/ffs/ffs_softdep.c Z sys/ufs/ffs/ffs_vfsops.c sys/ufs/ufs/ufs_quota.c sys/vm/swap_pager.c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm_pageout_scan badness
:errr then keep me in the CC : :it's interesting : :-- : __--_|\ Julian Elischer : / \ [EMAIL PROTECTED] Sure thing. Anyone else who wants to be in the Cc, email me. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm_pageout_scan badness
Matt Dillon wrote: > > I'm going to take this off of hackers and to private email. My reply > will be via private email. > > -Matt > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message errr then keep me in the CC it's interesting -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm_pageout_scan badness
I'm going to take this off of hackers and to private email. My reply will be via private email. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
More logging questions....
I have a machine running FreeBSD 4.2, and when it boots up, I can watch the console, and everything is highlighted (bright white), then I guess it moves on to starting processes from init, rc.local and such, and the console is loggin stuff on the screen in normal text (not highlighted). This information is NOT in the messages file, nor in the dmesg output. The last information logged to both (dmesg and /var/log/messages) is the last disk drive initialization. I see on the screen some error about ld.so not found, Apache, and some other things, but I can't find out where that information is being logged, so I can look at it remotely. Does anyone have any idea where I can find this information? The rc.local file, and scripts in the /usr/local/etc/rc.d directory don't appear to be executing on startup, and I need to figure out what's causing the problem. Help appreciated, Chuck Rock To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Arg! Siginfo and pthreads again
On Sun, 3 Dec 2000, Peter Dufault wrote: > Again I've forgotten that SIGINFO dumps the pthread info and created > several gigabytes of /tmp files: > > > rt% rm /tmp/uthread* > > /bin/rm: Argument list too long. > > I don't consider it bad form to use SIGINFO to see if processes are > still around without first installing a SIGINFO handler. Can't you use `kill -0 pid` if you just want to see if the process is around? > Am I the only one ever burnt by this? > Do other user-space thread systems handle this similarly? > Maybe an info thread can block at an info fifo in conjunction > with a "psthread" program. Now that we can accomodate more than 31 signals, we could always add a SIGTHRINFO (or something more aptly named) instead of using SIGINFO. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
VMware hanging -- Memory deadlock?
I have a vaio z505le with 192MB running 4.2-STABLE (cvsupped today). I've been trying to get vmware running properly on it. I first configured vmware on the vaio, created a win2k type virtual disk, set ram in the VM to 80M, and copied a happily working win2k virtual disk from another system over the skeleton one that the config wizard created. I'm running the latest port of XFree86 4.0.1. Each time I start vmware the system gets part of the way through the VM boot process and then hangs. The only thing that still responds is the mouse. A top process running in an xterm locks up, as does the getty on the serial console. I can break into ddb from the serial console. I've found that dropping the memory size for the VM down to 64MB works (68MB doesn't). When running the 64MB VM top shows: 70M Active, 34M Inactive, 75M Wired, ~9M Cache, 29M Buf, ~6M Free Does anyone have any suggestions on how to debug this? Thanks, barry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Arg! Siginfo and pthreads again
Again I've forgotten that SIGINFO dumps the pthread info and created several gigabytes of /tmp files: > rt% rm /tmp/uthread* > /bin/rm: Argument list too long. I don't consider it bad form to use SIGINFO to see if processes are still around without first installing a SIGINFO handler. Am I the only one ever burnt by this? Do other user-space thread systems handle this similarly? Maybe an info thread can block at an info fifo in conjunction with a "psthread" program. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
Andrew Gallatin wrote: > > Kenneth D. Merry writes: > > As for PCIOCREAD, it only allows reading of PCI registers, so the question > > there is whether there are any potential security implications to allowing > > non-root users to read PCI registers. If reading configuration registers > > caused performance degredation, for instance. > > I think that you might be able to crash an alpha with an unaligned > access trap by reading an int or short an from an unaligned offset in > config space. At least this used to be true.. I'd vote for leaving > the access permissions as is. I've accidently toasted boxes with this before. We really should fix it some time Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
