From owner-freebsd-current Sun Jun 13 9: 9:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from icarus.idirect.com (icarus.idirect.com [207.136.80.7]) by hub.freebsd.org (Postfix) with ESMTP id D733414EAC for ; Sun, 13 Jun 1999 09:09:29 -0700 (PDT) (envelope-from brandon@targetnet.com) Received: from terminus.idirect.com (terminus.idirect.com [207.136.80.70]) by icarus.idirect.com (8.9.3/8.9.3) with ESMTP id MAA28533; Sun, 13 Jun 1999 12:09:28 -0400 (EDT) Received: from brandon (ts7-55t-47.idirect.com [209.161.246.142]) by terminus.idirect.com (8.9.3/8.9.3) with SMTP id MAA03204; Sun, 13 Jun 1999 12:09:21 -0400 (EDT) From: "Brandon Gale" To: , Subject: RE: Panics on my SMP system Date: Sun, 13 Jun 1999 12:08:07 -0400 Message-ID: <008a01beb5b6$ed0118e0$0201a8c0@brandon> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <199906130048.RAA15241@trane.lambdawerks.org> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Although I don't have any bt's or problem reports, I have had several crashes on my SMP machine as well. The MPS setting in the bios was at 1.1, put it to 1.4 and haven't had any problems since. The box wouldn't report CPU states in top, except when we took the box to BSD/OS. Box is a Dual Xeon 450 Thanks, | Brandon A. Gale | -----Original Message----- From: owner-freebsd-current@FreeBSD.ORG [mailto:owner-freebsd-current@FreeBSD.ORG]On Behalf Of Reginald S. Perry Sent: June 12, 1999 8:48 PM To: freebsd-current@FreeBSD.ORG Subject: Panics on my SMP system Hi there, I recently had a crash on my SMP system. Actually, I have had a number of crashes over the past six months, but have just recently had time to configure the system to get the crash dumps. Like a good citizen, I filed a problem report (kern/12127). I have now gotten another crash. I have attached the backtrace from the crash dump. If you refer to kern/12127, you will get all of the gory details about my setup.I would like to know two things. Should I file a separate problem report for this crash? Second, is there somewhere that I should upload the vmcores and the kernel.debug for the relevant developer to examine? Thanks, -Reggie trane# gdb -k /usr/src/sys/compile/TRANE/kernel.debug ./vmcore.1 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"... SMP 2 cpus IdlePTD 3325952 initial pcb at 2aee40 panicstr: from debugger panic messages: --- Fatal trap 12: page fault while in kernel mode mp_lock = 01000002; cpuid = 1; lapic.id = 01000000 fault virtual address = 0xe37295b0 fault code = supervisor write, page not present instruction pointer = 0x8:0xc014ec05 stack pointer = 0x10:0xc6f5ae28 frame pointer = 0x10:0xc6f5ae38 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 = 365 (communicator-4.6) interrupt mask = net tty bio cam <- SMP: XXX panic: from debugger mp_lock = 01000002; cpuid = 1; lapic.id = 01000000 panic: from debugger mp_lock = 01000003; cpuid = 1; lapic.id = 01000000 boot() called on cpu#1 dumping to dev (4,131081), offset 280576 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 boot (howto=260) at ../../kern/kern_shutdown.c:288 288 dumppcb.pcb_cr3 = rcr3(); (kgdb) where #0 boot (howto=260) at ../../kern/kern_shutdown.c:288 #1 0xc014c7d5 in panic (fmt=0xc025fdf4 "from debugger") at ../../kern/kern_shutdown.c:451 #2 0xc012e8ed in db_panic (addr=-1072370683, have_addr=0, count=1, modif=0xc6f5aca4 "") at ../../ddb/db_command.c:434 #3 0xc012e88d in db_command (last_cmdp=0xc028c050, cmd_table=0xc028beb0, aux_cmd_tablep=0xc02ac554) at ../../ddb/db_command.c:334 #4 0xc012e952 in db_command_loop () at ../../ddb/db_command.c:456 #5 0xc0130ab3 in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71 #6 0xc0212fbe in kdb_trap (type=12, code=0, regs=0xc6f5ade8) at ../../i386/i386/db_interface.c:157 #7 0xc0225c8e in trap_fatal (frame=0xc6f5ade8, eva=3815937456) at ../../i386/i386/trap.c:903 #8 0xc0225925 in trap_pfault (frame=0xc6f5ade8, usermode=0, eva=3815937456) at ../../i386/i386/trap.c:801 #9 0xc022556f in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -958059680, tf_esi = -958059200, tf_ebp = -956977608, tf_isp = -956977644, tf_ebx = -958059680, tf_edx = -1070804384, tf_ecx = 16777217, tf_eax = -479029840, tf_trapno = 12, tf_err = 2, tf_eip = -1072370683, tf_cs = 8, tf_eflags = 66194, tf_esp = -958059680, tf_ss = -958059200}) at ../../i386/i386/trap.c:427 #10 0xc014ec05 in wakeup (ident=0xc6e52b60) at ../../kern/kern_synch.c:692 #11 0xc015a90f in pipeclose (cpipe=0xc6e52d40) at ../../kern/sys_pipe.c:1099 #12 0xc015a82c in pipe_close (fp=0xc0bdb780, p=0xc648df20) at ../../kern/sys_pipe.c:1065 #13 0xc014507c in closef (fp=0xc0bdb780, p=0xc648df20) at ../../kern/kern_descrip.c:1082 #14 0xc0144e60 in fdfree (p=0xc648df20) at ../../kern/kern_descrip.c:994 #15 0xc014632a in exit1 (p=0xc648df20, rv=10) at ../../kern/kern_exit.c:201 #16 0xc014db96 in sigexit (p=0xc648df20, signum=10) at ../../kern/kern_sig.c:1251 #17 0xc014d9d9 in postsig (signum=10) at ../../kern/kern_sig.c:1157 #18 0xc0225fee in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 13495712, tf_esi = 9470, tf_ebp = -1077955960, tf_isp = -956977196, tf_ebx = 11829344, tf_edx = 342, tf_ecx = 103029, tf_eax = 0, tf_trapno = 548769888, tf_err = 7, tf_eip = 550790017, tf_cs = 31, tf_eflags = 662, tf_esp = -1077955976, tf_ss = 47}) at ../../i386/i386/trap.c:163 #19 0x20d46381 in ?? () #20 0xbfbfdfdc in ?? () #21 0x20bb4e10 in ?? () #22 0x20b5f527 in ?? () #23 0x20b601bd in ?? () #24 0x20b7b450 in ?? () #25 0x86a197 in ?? () #26 0x86e373 in ?? () #27 0x86e152 in ?? () #28 0x26e774 in ?? () #29 0x17c8e3 in ?? () #30 0x17c107 in ?? () #31 0x17bb7d in ?? () #32 0xec12d in ?? () #33 0xecce8 in ?? () #34 0x15ba73 in ?? () #35 0x6c5ee in ?? () #36 0x6c693 in ?? () #37 0x732094 in ?? () #38 0x8fd337 in ?? () #39 0x8fd2a3 in ?? () #40 0x56685 in ?? () #41 0x20b73cbb in ?? () #42 0x55b6e in ?? () #43 0x58ca1 in ?? () #44 0x1095 in ?? () (kgdb) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 13 10: 8:44 1999 Delivered-To: freebsd-current@freebsd.org Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (Postfix) with ESMTP id EEC4C150B5 for ; Sun, 13 Jun 1999 10:08:41 -0700 (PDT) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.9.3/8.9.3/Kp) with ESMTP id RAA00607 for ; Sun, 13 Jun 1999 17:08:39 GMT Message-ID: <3763E513.B9194F25@tdx.co.uk> Date: Sun, 13 Jun 1999 18:06:27 +0100 From: Karl Pielorz Organization: TDX - The Digital eXchange X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org Subject: Problem with recent current (from 11/6/99) and newly built kernel mounting drives Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi All, My 4.0-Current system isn't too well at the moment... I cvsup'd on Friday, rebuilt the world - installed the world, checked /etc for any changes, blew my old Kernel config away (and rebuilt one from Generic), restarted - and the system appears to 'stick' at the point of mounting a particular drive/partition during boot with the new kernel... The previous kernel was about 1 & 1/2 weeks older... I've narrowed this down specifically to this drive/partition: /dev/wd3s1e /var/crash ufs rw 1 1 The old kernel will mount/fsck it fine (fsck reports no errors), the new one just "goes to sleep" while trying to mount it (ps axl shows 'mount' to be in biord - and there's no disk lights on). I could blow the partition away (and hope that fixes it), but I'd rather find out what's going on... I use softupdates, but _not_ on that partition (nor on / and /usr). The machine is an SMP P-Pro200, w/256Mb RAM. I'm going to try and get some time to try the same with a single-CPU kernel to see if that helps... /dev is up to date, and all other partitions seem to be OK. I tried running a ktrace on the failing mount command (I'm not too good at this, the only way I could trace mount with command-line args was to create a shell-script that ran "mount /var/crash", then trace the script with "ktrace -i ./t.script". The output is quite long - a copy is at http://www.tdx.com/ktrace.txt and http://www.tdx.com/ktrace.out (rather than posting it here if it's something simple/stupid like pilot error :) Anyone got any suggestions what to try next? I have been away recently, I may have missed something in -current pertinent to this, but a quick check through the archives didn't appear to find anything... Cheers, -Karl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 13 10:14:53 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 9476014C29 for ; Sun, 13 Jun 1999 10:14:49 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id TAA03793; Sun, 13 Jun 1999 19:14:45 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Karl Pielorz Cc: current@FreeBSD.ORG Subject: Re: Problem with recent current (from 11/6/99) and newly built kernel mounting drives In-reply-to: Your message of "Sun, 13 Jun 1999 18:06:27 BST." <3763E513.B9194F25@tdx.co.uk> Date: Sun, 13 Jun 1999 19:14:44 +0200 Message-ID: <3791.929294084@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This could sound like disk trouble. Try this: boot into singleuser stty status ^T dd if=/dev/rwd3 of=/dev/null bs=64k press CTRL-T every so often and see if it stalls -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 13 10:57:54 1999 Delivered-To: freebsd-current@freebsd.org Received: from freja.webgiro.com (freja.webgiro.com [212.209.29.10]) by hub.freebsd.org (Postfix) with ESMTP id 2429A1514A for ; Sun, 13 Jun 1999 10:57:52 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by freja.webgiro.com (Postfix, from userid 1001) id 0895718D0; Sun, 13 Jun 1999 19:58:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by freja.webgiro.com (Postfix) with ESMTP id 0547249CC; Sun, 13 Jun 1999 19:58:49 +0200 (CEST) Date: Sun, 13 Jun 1999 19:58:49 +0200 (CEST) From: Andrzej Bialecki To: Tim Vanderhoek Cc: Brian Dean , freebsd-current@FreeBSD.ORG Subject: Re: can't install on machine with 8 Meg In-Reply-To: <19990612192410.A70348@mad> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 12 Jun 1999, Tim Vanderhoek wrote: > It is true that you can run a system with as little as 4 meg. I've > installed 2.2 on a system with 4 meg (it was one of the ones that had > a cool motherboard and needed 4 meg instead of 5). Joerg claims he > used to run FreeBSD on a system with only 2 meg. You can't use the > GENERIC installation kernel to run on these low-memory machines, > though. You most certainly can RUN in 4MB, even without any swap partition. I sit in front of such a system :-) - it runs shell, inetd, snmpd, can accept telnet connections, and work as a firewall. Well, with some additional hacking you could probably run in 2MB with swapping (but most of the system activity would be spent this way :-) Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 13 12:24:20 1999 Delivered-To: freebsd-current@freebsd.org Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (Postfix) with ESMTP id 4AD1714EA2 for ; Sun, 13 Jun 1999 12:24:17 -0700 (PDT) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.9.3/8.9.3/Kp) with ESMTP id TAA10064 for ; Sun, 13 Jun 1999 19:24:16 GMT Message-ID: <376404DB.6D227CDD@tdx.co.uk> Date: Sun, 13 Jun 1999 20:22:03 +0100 From: Karl Pielorz Organization: TDX - The Digital eXchange X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org Subject: Problem with recent current (from 11/6/99) and newly built kernel mounting drives Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi All, My 4.0-Current system isn't too well at the moment... I cvsup'd on Friday, rebuilt the world - installed the world, checked /etc for any changes, blew my old Kernel config away (and rebuilt one from Generic), restarted - and the system appears to 'stick' at the point of mounting a particular drive/partition during boot with the new kernel... The previous kernel was about 1 & 1/2 weeks older... I've narrowed this down specifically to this drive/partition: /dev/wd3s1e /var/crash ufs rw 1 1 The old kernel will mount/fsck it fine (fsck reports no errors), the new one just "goes to sleep" while trying to mount it (ps axl shows 'mount' to be in biord - and there's no disk lights on). I could blow the partition away (and hope that fixes it), but I'd rather find out what's going on... I use softupdates, but _not_ on that partition (nor on / and /usr). The machine is an SMP P-Pro200, w/256Mb RAM. I'm going to try and get some time to try the same with a single-CPU kernel to see if that helps... /dev is up to date, and all other partitions seem to be OK. I tried running a ktrace on the failing mount command (I'm not too good at this, the only way I could trace mount with command-line args was to create a shell-script that ran "mount /var/crash", then trace the script with "ktrace -i ./t.script". The output is quite long - a copy is at http://www.tdx.com/ktrace.txt and http://www.tdx.com/ktrace.out (rather than posting it here if it's something simple/stupid like pilot error :) Anyone got any suggestions what to try next? I have been away recently, I may have missed something in -current pertinent to this, but a quick check through the archives didn't appear to find anything... Cheers, -Karl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 13 15:44: 8 1999 Delivered-To: freebsd-current@freebsd.org Received: from argus.tfs.net (as2-p84.tfs.net [139.146.205.84]) by hub.freebsd.org (Postfix) with ESMTP id BF19C150F7 for ; Sun, 13 Jun 1999 15:44:00 -0700 (PDT) (envelope-from jbryant@argus.tfs.net) Received: (from jbryant@localhost) by argus.tfs.net (8.9.3/8.8.5) id RAA52418 for freebsd-current@freebsd.org; Sun, 13 Jun 1999 17:43:57 -0500 (CDT) From: Jim Bryant Message-Id: <199906132243.RAA52418@argus.tfs.net> Subject: sound driver setup To: freebsd-current@freebsd.org Date: Sun, 13 Jun 1999 17:43:57 -0500 (CDT) Reply-To: jbryant@unix.tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-files: The truth is that the X-Files is fiction X-Republican: The best kind!!! X-Operating-System: FreeBSD 4.0-CURRENT #31: Thu Apr 8 10:40:17 CDT 1999 X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG okay, here's the deal. I have a Tyan Thunder-2 Motherboard, S1696DLUA, running -current SMP. does anyone have successfully running: 1). the OPL3-SAx sound driver for the motherboard sound? 2). a Soundblaster-Live? I would appreciate a sample config file, as I'm at a loss as to the cause of these NOT being detected. jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 13 16:24:52 1999 Delivered-To: freebsd-current@freebsd.org Received: from zippy.dyn.ml.org (pm3-1.ppp.wenet.net [206.15.85.1]) by hub.freebsd.org (Postfix) with ESMTP id 3167515182 for ; Sun, 13 Jun 1999 16:24:49 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.9.3/8.9.1) with ESMTP id QAA28945; Sun, 13 Jun 1999 16:24:17 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Sun, 13 Jun 1999 16:24:17 -0700 (PDT) From: Alex Zepeda To: Joel Ray Holveck Cc: Brett Taylor , Tomer Weller , "" Subject: Re: KDE programs won't compile In-Reply-To: <86909xdfa3.fsf@detlev.UUCP> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > How do you mean "depreciated"? Should users not set it, or > applications not check for it, or what? [...] > The 2.0 kdelibs/README states: > IMPORTANT: most applications need KDEDIR as the directory where KDE is > installed. Please set this in your login file. > Of course, this could be out-of-date. Yes, I think this is out of date, I've just let intertia set in, and haven't removed it. I seem to recall a bunch of discussion about the removal of the KDEDIR variable, but as of yet, I still see a lot of getenv("KDEDIR"). Actually, I just checked this, if $KDEDIR isn't set it uses the compiletime default, so yes, KDEDIR isn't really needed, as long as ld can find the libs, and gcc can find the headers. > I do not know of an alternate mechanism. A brief examination of the > 2.0 kdebase and koffice configure.in's do not immediately reveal one > either, other than --prefix. Is this the accepted method, then? > What if a user wants to install something in a different place than > the rest of KDE? I think this is generally frowned upon, but I know kdebase has --disable-path-check, and I guess if something is based off the "KDE autoconf gunk" it could easily include that switch. If a program doesn't use autoconf or doesn't have the switch, you're stuck manually copying files. According to Stephan Kulow: blarf: the program has to KStandardDirs::registerPrefix() for now it just won't work (I'm rather pissed at KStandDirs right now anyways for breaking some stuff I spent time fixing, but that's another thread). > Which configure script did you take this from? I see the same code in > many bits of KDE itself. kdebase. Well, 90% of the autoconf code is shared between all the kde modules. It's been setup in the CVS/CVSup module kde-common if you want to take a look. - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 13 18: 2:30 1999 Delivered-To: freebsd-current@freebsd.org Received: from thelab.hub.org (nat192.211.mpoweredpc.net [142.177.192.211]) by hub.freebsd.org (Postfix) with ESMTP id 5AD3B14C35; Sun, 13 Jun 1999 18:02:19 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id WAA25268; Sun, 13 Jun 1999 22:02:13 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Sun, 13 Jun 1999 22:02:13 -0300 (ADT) From: The Hermit Hacker To: Matthew Dillon Cc: "David E. Cross" , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: MMAP() in STABLE/CURRENT ... In-Reply-To: <199906130459.VAA65612@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 12 Jun 1999, Matthew Dillon wrote: > :Anyway, I have a simple program that mmap()s a 1Gig file into memory, > :madvise()s it that it will be doing random access. If I quit and restart > :this program a couple of times (yes, it close()s and munmap()s the segment), > :my system will hard lock. By dropping into DDB once I found that it was > :stuck in 'vm_somethingorother_choosepage'. Does this ring any bells? Should > :I try to stop my system again? > : > :-- > :David Cross | email: crossd@cs.rpi.edu > > David, can you email this program to me please? > > Also, which FreeBSD release does this occur on? > > I've got about 6 mmap-related bugs on my plate at the moment. 3 of them > have been identified ( that is, I know why they deadlock the machine ), > but none have been fixed yet. Matt, I'll volunteer myself as a tester for this code under 3.2-STABLE, when you have it ready... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 13 18:22:11 1999 Delivered-To: freebsd-current@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 894BC14C95; Sun, 13 Jun 1999 18:22:07 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id VAA02659; Sun, 13 Jun 1999 21:22:00 -0400 (EDT) Message-Id: <199906140122.VAA02659@cs.rpi.edu> To: The Hermit Hacker Cc: Matthew Dillon , "David E. Cross" , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: MMAP() in STABLE/CURRENT ... In-Reply-To: Message from The Hermit Hacker of "Sun, 13 Jun 1999 22:02:13 -0300." Date: Sun, 13 Jun 1999 21:22:00 -0400 From: "David E. Cross" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here's the code: #include #include #include #include #include #include #define DBSIZE 733055625 int main(void) { int fd; unsigned char *dbp; fd=open(argv[1], O_CREAT | O_RDWR | O_TRUNC, 0600); lseek(fd, DBSIZE -1, SEEK_SET); write(fd, &fd, 1); dbp=mmap(NULL, DBSIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); close (fd); memset(dbp, 0, DBSIZE); munmap(dbp, DBSIZE); return 0; } } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 13 18:56:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from bytor.rush.net (bytor.rush.net [209.45.245.145]) by hub.freebsd.org (Postfix) with ESMTP id E2DAD14E92 for ; Sun, 13 Jun 1999 18:56:47 -0700 (PDT) (envelope-from lynch@bsdunix.net) Received: from localhost (lynch@localhost) by bytor.rush.net (8.9.3/8.9.3) with ESMTP id VAA10754; Sun, 13 Jun 1999 21:56:46 -0400 (EDT) Date: Sun, 13 Jun 1999 21:56:45 -0400 (EDT) From: Pat Lynch X-Sender: lynch@bytor.rush.net To: Jim Bryant Cc: freebsd-current@FreeBSD.ORG Subject: Re: sound driver setup In-Reply-To: <199906132243.RAA52418@argus.tfs.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG heh I had problems getting the onboard OPL to work as well, and there is no driver for the SB Live as of yet. When I have time I'll play around with the sound, as it shows as a "Plug and Pray" device (I can shut it off in userconfig with "pnp 1 0 disable" When I have tme to fool around with it (I just got back from usenix) I'll let you know what I come up with. -Pat ___________________________________________________________________________ Pat Lynch lynch@rush.net lynch@bsdunix.net Systems Administrator Rush Networking ___________________________________________________________________________ On Sun, 13 Jun 1999, Jim Bryant wrote: > okay, here's the deal. > > I have a Tyan Thunder-2 Motherboard, S1696DLUA, running -current SMP. > > does anyone have successfully running: > > 1). the OPL3-SAx sound driver for the motherboard sound? > 2). a Soundblaster-Live? > > I would appreciate a sample config file, as I'm at a loss as to the > cause of these NOT being detected. > > jim > -- > All opinions expressed are mine, if you | "I will not be pushed, stamped, > think otherwise, then go jump into turbid | briefed, debriefed, indexed, or > radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" > ------------------------------------------------------------------------------ > Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw > voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant > ------------------------------------------------------------------------------ > HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 13 19:42:27 1999 Delivered-To: freebsd-current@freebsd.org Received: from hotmail.com (f157.hotmail.com [207.82.251.36]) by hub.freebsd.org (Postfix) with SMTP id 5B43714BE2 for ; Sun, 13 Jun 1999 19:42:25 -0700 (PDT) (envelope-from bimaldas@hotmail.com) Received: (qmail 4946 invoked by uid 0); 14 Jun 1999 02:42:25 -0000 Message-ID: <19990614024225.4945.qmail@hotmail.com> Received: from 206.132.53.197 by wy1lg.hotmail.com with HTTP; Sun, 13 Jun 1999 19:42:25 PDT X-Originating-IP: [206.132.53.197] From: Bimal Das To: freebsd-current@FreeBSD.ORG Subject: Open my e-mail address ecdotechusa@yahoo.com Date: Sun, 13 Jun 1999 19:42:25 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear Sir, I am Bimal Das CEO of Ecotech Marketing in India. I just started my new company in USa called Ecotech technologies, L.L.C. I recently bought a software called dbmail at $149 from a uk company this is for sendingt bulk e-mail. I took the advantage of this and sent bulk e-mail for business promotion. I don't know that sending bulk e-mail is prohibited. The consequences are my e-mail address ecotechusa@yahoo.com is blocked which is casing me great loss and also my web site http://www.ecotechindia.com I request you to take necessary action and put my e-mail and web site in active. I promise that I will send any bulk e-mail in future. Thanking you Sincerely Bimal Das For Ecotech ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 13 20: 7:55 1999 Delivered-To: freebsd-current@freebsd.org Received: from ix.netcom.com (sil-wa15-09.ix.netcom.com [207.93.148.9]) by hub.freebsd.org (Postfix) with ESMTP id 7D273151F6 for ; Sun, 13 Jun 1999 20:07:50 -0700 (PDT) (envelope-from tomdean@ix.netcom.com) Received: (from tomdean@localhost) by ix.netcom.com (8.9.3/8.8.8) id UAA31932; Sun, 13 Jun 1999 20:07:48 -0700 (PDT) (envelope-from tomdean@ix.netcom.com) Date: Sun, 13 Jun 1999 20:07:48 -0700 (PDT) Message-Id: <199906140307.UAA31932@ix.netcom.com> X-Authentication-Warning: celebris.tddhome: tomdean set sender to tomdean@ix.netcom.com using -f From: Thomas Dean To: freebsd-current@FreeBSD.ORG Subject: Very Strange Local Network Behavior Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am running 4.0-current SMP as of yesterday. Since the make world and rebuilding the kernel, the local network is very strange. I changed the local network to be two machines, connected with a 10 foot coax, properly terminated. Ping starts off OK, a little slow. I seem to recall it being ~1ms for this setup. Then, it changes to take > 1 second. Pinging my ISP via ppp takes ~190ms, about normal. I have attached the output of ping and dmesg. tomdean ============================== # ping tddti PING tddti.tddhome (192.168.1.2): 56 data bytes 64 bytes from 192.168.1.2: icmp_seq=0 ttl=32 time=4.810 ms 64 bytes from 192.168.1.2: icmp_seq=1 ttl=32 time=7.483 ms 64 bytes from 192.168.1.2: icmp_seq=2 ttl=32 time=6.774 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=32 time=18.802 ms 64 bytes from 192.168.1.2: icmp_seq=4 ttl=32 time=5.451 ms 64 bytes from 192.168.1.2: icmp_seq=5 ttl=32 time=3.111 ms 64 bytes from 192.168.1.2: icmp_seq=6 ttl=32 time=87.740 ms 64 bytes from 192.168.1.2: icmp_seq=7 ttl=32 time=4.245 ms 64 bytes from 192.168.1.2: icmp_seq=8 ttl=32 time=4.702 ms 64 bytes from 192.168.1.2: icmp_seq=9 ttl=32 time=3.673 ms 64 bytes from 192.168.1.2: icmp_seq=10 ttl=32 time=8.894 ms 64 bytes from 192.168.1.2: icmp_seq=11 ttl=32 time=6.028 ms 64 bytes from 192.168.1.2: icmp_seq=12 ttl=32 time=4.990 ms 64 bytes from 192.168.1.2: icmp_seq=13 ttl=32 time=3.107 ms 64 bytes from 192.168.1.2: icmp_seq=14 ttl=32 time=27.055 ms 64 bytes from 192.168.1.2: icmp_seq=15 ttl=32 time=4.181 ms 64 bytes from 192.168.1.2: icmp_seq=16 ttl=32 time=4.713 ms 64 bytes from 192.168.1.2: icmp_seq=17 ttl=32 time=3.650 ms 64 bytes from 192.168.1.2: icmp_seq=18 ttl=32 time=5.951 ms 64 bytes from 192.168.1.2: icmp_seq=19 ttl=32 time=141.150 ms 64 bytes from 192.168.1.2: icmp_seq=20 ttl=32 time=1011.133 ms 64 bytes from 192.168.1.2: icmp_seq=21 ttl=32 time=1011.119 ms 64 bytes from 192.168.1.2: icmp_seq=22 ttl=32 time=1011.110 ms 64 bytes from 192.168.1.2: icmp_seq=23 ttl=32 time=1011.130 ms 64 bytes from 192.168.1.2: icmp_seq=24 ttl=32 time=1011.091 ms 64 bytes from 192.168.1.2: icmp_seq=25 ttl=32 time=1011.127 ms 64 bytes from 192.168.1.2: icmp_seq=26 ttl=32 time=1011.106 ms 64 bytes from 192.168.1.2: icmp_seq=27 ttl=32 time=1011.161 ms 64 bytes from 192.168.1.2: icmp_seq=28 ttl=32 time=1011.091 ms 64 bytes from 192.168.1.2: icmp_seq=29 ttl=32 time=1011.164 ms 64 bytes from 192.168.1.2: icmp_seq=30 ttl=32 time=1011.131 ms ^C --- tddti.tddhome ping statistics --- 32 packets transmitted, 31 packets received, 3% packet loss round-trip min/avg/max/stddev = 3.107/370.286/1011.164/476.031 ms === dmesg ====================== # dmesg Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Sat Jun 12 14:22:28 PDT 1999 tomdean@celebris:/usr/src/sys/compile/CELEBRIS-SMP Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P54C (586-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping=5 Features=0x3bf real memory = 100663296 (98304K bytes) avail memory = 94887936 (92664K bytes) Programming 16 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc02c7000. Intel Pentium detected, installing workaround for F00F bug npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 chip0: at device 0.0 on pci0 ncr0: irq 11 at device 1.0 on pci0 isab0: at device 2.0 on pci0 vga-pci0: irq 9 at device 6.0 on pci0 de0: irq 10 at device 8.0 on pci0 de0: DEC DE450-CA 21041 [10Mb/s] pass 1.1 de0: address 00:00:f8:02:76:db isa0: on motherboard fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> at fdc0 drive 0 atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: on isa0 sc0: on isa0 sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0 at port 0x378-0x37f irq 7 on isa0 ppc0: PC87334 chipset (PS2/NIBBLE) in COMPATIBLE mode lpt0: on ppbus 0 lpt0: Interrupt-driven port APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 Waiting 10 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 8) da0: 1042MB (2134305 512 byte sectors: 255H 63S/T 132C) cd0 at ncr0 bus 0 target 5 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 4.237MB/s transfers (4.237MHz, offset 8) cd0: cd present [59444 x 2048 byte records] da2 at ncr0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled da2: 1029MB (2109376 512 byte sectors: 255H 63S/T 131C) da1 at ncr0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled da1: 3090MB (6328861 512 byte sectors: 255H 63S/T 393C) changing root device to da1s1a To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 13 20:57: 5 1999 Delivered-To: freebsd-current@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.144.32]) by hub.freebsd.org (Postfix) with ESMTP id 705AE15099 for ; Sun, 13 Jun 1999 20:57:03 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.8.8/8.8.8) with ESMTP id UAA24869; Sun, 13 Jun 1999 20:56:54 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Date: Sun, 13 Jun 1999 20:56:53 -0700 (PDT) From: Doug White To: Tim Vanderhoek Cc: Brian Dean , freebsd-current@FreeBSD.ORG Subject: Re: can't install on machine with 8 Meg In-Reply-To: <19990612192410.A70348@mad> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 12 Jun 1999, Tim Vanderhoek wrote: > On Sat, Jun 12, 1999 at 01:08:00PM -0400, Brian Dean wrote: > > Hi, > > > > I'm installing 4.0-19990610-SNAP onto a machine with 8 Meg of memory > > and it fails as follows: > > > > pid 6 (sh), uid 0, was killed: out of swap space > > There's a rumour going around that you need 12 meg to install. Why, I > don't know. Becuase in 8MB sysinstall mysteriously tanks during extraction, and works fine with 12. No error message is produced, so I'm guessing it's a non- or silently-errorchecked malloc(). I can reproduce this. The docs are all wrong, thus the PR. Took us a while to figure out what was going on as NO ERROR MESSAGE WAS PRODUCED Doug White Internet: dwhite@resnet.uoregon.edu | FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite | www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 13 21:28:59 1999 Delivered-To: freebsd-current@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id 3C82014C1A for ; Sun, 13 Jun 1999 21:28:56 -0700 (PDT) (envelope-from cdillon@wolves.k12.mo.us) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.2) with ESMTP id XAA08636; Sun, 13 Jun 1999 23:29:37 -0500 (CDT) (envelope-from cdillon@wolves.k12.mo.us) Date: Sun, 13 Jun 1999 23:29:36 -0500 (CDT) From: Chris Dillon To: Doug White Cc: Tim Vanderhoek , Brian Dean , freebsd-current@FreeBSD.ORG Subject: Re: can't install on machine with 8 Meg In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 13 Jun 1999, Doug White wrote: > On Sat, 12 Jun 1999, Tim Vanderhoek wrote: > > > On Sat, Jun 12, 1999 at 01:08:00PM -0400, Brian Dean wrote: > > > Hi, > > > > > > I'm installing 4.0-19990610-SNAP onto a machine with 8 Meg of memory > > > and it fails as follows: > > > > > > pid 6 (sh), uid 0, was killed: out of swap space > > > > There's a rumour going around that you need 12 meg to install. Why, I > > don't know. > > Becuase in 8MB sysinstall mysteriously tanks during extraction, and works > fine with 12. No error message is produced, so I'm guessing it's a > non- or silently-errorchecked malloc(). I can reproduce this. The docs > are all wrong, thus the PR. > > Took us a while to figure out what was going on as NO ERROR MESSAGE WAS > PRODUCED I got 3.1 installed on an 8 MB machine, with a little bit of tweaking. I was doing it over PPP, so having the PPP client running and eating up some memory wasn't helping any. By creating a custom installation kernel with most of the unneeded devices removed, freeing up about a whole 1MB of RAM, everything went OK. It may be that freeing up just a few hundred KB of RAM would be enough to squeak by. -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures (SPARC under development). ( http://www.freebsd.org ) "One should admire Windows users. It takes a great deal of courage to trust Windows with your data." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 13 21:34:27 1999 Delivered-To: freebsd-current@freebsd.org Received: from argus.tfs.net (as2-p84.tfs.net [139.146.205.84]) by hub.freebsd.org (Postfix) with ESMTP id 9D49114C1A for ; Sun, 13 Jun 1999 21:34:18 -0700 (PDT) (envelope-from jbryant@argus.tfs.net) Received: (from jbryant@localhost) by argus.tfs.net (8.9.3/8.8.5) id XAA53459; Sun, 13 Jun 1999 23:33:47 -0500 (CDT) From: Jim Bryant Message-Id: <199906140433.XAA53459@argus.tfs.net> Subject: Re: Very Strange Local Network Behavior In-Reply-To: <199906140307.UAA31932@ix.netcom.com> from Thomas Dean at "Jun 13, 99 08:07:48 pm" To: tomdean@ix.netcom.com (Thomas Dean) Date: Sun, 13 Jun 1999 23:33:45 -0500 (CDT) Cc: freebsd-current@freebsd.org Reply-To: jbryant@unix.tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-files: The truth is that the X-Files is fiction X-Republican: The best kind!!! X-Operating-System: FreeBSD 4.0-CURRENT #31: Thu Apr 8 10:40:17 CDT 1999 X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG No problems here. I'm running from a kernel built from last night, and an installworld from yesterday morning. argus uses a 3c509, and wahoo uses a generic pci ethernet card. 50 foot coax, with termination, and a terminal server and x-terminal in between. This is an SMP kernel. Maybe you have a flakey radio shack coax [NEVER BUY COAX FROM RADIO SHACK!] or a flakey ethernet controller. First, I suggest going to a radio store [commercian or amatuer] and buy a good coax [or have one made], the connectors, the crimps, and the shielding will all be better. Also, watch the length of the coax. I don't at the moment recall the lengths to stay away from, but there are certain lengths that cause a high swr condition that will produce serious errors and possibly damage the tranceiver on the card. 8:20:21pm wahoo(3): ping argus PING argus (10.11.12.1): 56 data bytes 64 bytes from 10.11.12.1: icmp_seq=0 ttl=255 time=1.254 ms 64 bytes from 10.11.12.1: icmp_seq=1 ttl=255 time=1.168 ms 64 bytes from 10.11.12.1: icmp_seq=2 ttl=255 time=0.939 ms 64 bytes from 10.11.12.1: icmp_seq=3 ttl=255 time=0.942 ms 64 bytes from 10.11.12.1: icmp_seq=4 ttl=255 time=1.436 ms 64 bytes from 10.11.12.1: icmp_seq=5 ttl=255 time=0.939 ms 64 bytes from 10.11.12.1: icmp_seq=6 ttl=255 time=1.164 ms 64 bytes from 10.11.12.1: icmp_seq=7 ttl=255 time=1.539 ms 64 bytes from 10.11.12.1: icmp_seq=8 ttl=255 time=1.173 ms 64 bytes from 10.11.12.1: icmp_seq=9 ttl=255 time=1.314 ms 64 bytes from 10.11.12.1: icmp_seq=10 ttl=255 time=1.359 ms 64 bytes from 10.11.12.1: icmp_seq=11 ttl=255 time=1.547 ms 64 bytes from 10.11.12.1: icmp_seq=12 ttl=255 time=1.224 ms 64 bytes from 10.11.12.1: icmp_seq=13 ttl=255 time=1.186 ms 64 bytes from 10.11.12.1: icmp_seq=14 ttl=255 time=1.235 ms 64 bytes from 10.11.12.1: icmp_seq=15 ttl=255 time=1.545 ms 64 bytes from 10.11.12.1: icmp_seq=16 ttl=255 time=0.989 ms 64 bytes from 10.11.12.1: icmp_seq=17 ttl=255 time=1.644 ms 64 bytes from 10.11.12.1: icmp_seq=18 ttl=255 time=1.248 ms 64 bytes from 10.11.12.1: icmp_seq=19 ttl=255 time=1.621 ms 64 bytes from 10.11.12.1: icmp_seq=20 ttl=255 time=1.327 ms 64 bytes from 10.11.12.1: icmp_seq=21 ttl=255 time=1.176 ms 64 bytes from 10.11.12.1: icmp_seq=22 ttl=255 time=1.258 ms 64 bytes from 10.11.12.1: icmp_seq=23 ttl=255 time=1.259 ms 64 bytes from 10.11.12.1: icmp_seq=24 ttl=255 time=1.216 ms 64 bytes from 10.11.12.1: icmp_seq=25 ttl=255 time=1.207 ms 64 bytes from 10.11.12.1: icmp_seq=26 ttl=255 time=1.179 ms 64 bytes from 10.11.12.1: icmp_seq=27 ttl=255 time=1.049 ms 64 bytes from 10.11.12.1: icmp_seq=28 ttl=255 time=0.952 ms 64 bytes from 10.11.12.1: icmp_seq=29 ttl=255 time=1.390 ms ^C --- argus ping statistics --- 30 packets transmitted, 30 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.939/1.249/1.644/0.196 ms In reply: > I am running 4.0-current SMP as of yesterday. > > Since the make world and rebuilding the kernel, the local network is > very strange. > > I changed the local network to be two machines, connected with a 10 > foot coax, properly terminated. Ping starts off OK, a little slow. I > seem to recall it being ~1ms for this setup. Then, it changes to take > > 1 second. Pinging my ISP via ppp takes ~190ms, about normal. > > I have attached the output of ping and dmesg. > > tomdean > > ============================== > # ping tddti > PING tddti.tddhome (192.168.1.2): 56 data bytes > 64 bytes from 192.168.1.2: icmp_seq=0 ttl=32 time=4.810 ms > 64 bytes from 192.168.1.2: icmp_seq=1 ttl=32 time=7.483 ms > 64 bytes from 192.168.1.2: icmp_seq=2 ttl=32 time=6.774 ms > 64 bytes from 192.168.1.2: icmp_seq=3 ttl=32 time=18.802 ms > 64 bytes from 192.168.1.2: icmp_seq=4 ttl=32 time=5.451 ms > 64 bytes from 192.168.1.2: icmp_seq=5 ttl=32 time=3.111 ms > 64 bytes from 192.168.1.2: icmp_seq=6 ttl=32 time=87.740 ms > 64 bytes from 192.168.1.2: icmp_seq=7 ttl=32 time=4.245 ms > 64 bytes from 192.168.1.2: icmp_seq=8 ttl=32 time=4.702 ms > 64 bytes from 192.168.1.2: icmp_seq=9 ttl=32 time=3.673 ms > 64 bytes from 192.168.1.2: icmp_seq=10 ttl=32 time=8.894 ms > 64 bytes from 192.168.1.2: icmp_seq=11 ttl=32 time=6.028 ms > 64 bytes from 192.168.1.2: icmp_seq=12 ttl=32 time=4.990 ms > 64 bytes from 192.168.1.2: icmp_seq=13 ttl=32 time=3.107 ms > 64 bytes from 192.168.1.2: icmp_seq=14 ttl=32 time=27.055 ms > 64 bytes from 192.168.1.2: icmp_seq=15 ttl=32 time=4.181 ms > 64 bytes from 192.168.1.2: icmp_seq=16 ttl=32 time=4.713 ms > 64 bytes from 192.168.1.2: icmp_seq=17 ttl=32 time=3.650 ms > 64 bytes from 192.168.1.2: icmp_seq=18 ttl=32 time=5.951 ms > 64 bytes from 192.168.1.2: icmp_seq=19 ttl=32 time=141.150 ms > 64 bytes from 192.168.1.2: icmp_seq=20 ttl=32 time=1011.133 ms > 64 bytes from 192.168.1.2: icmp_seq=21 ttl=32 time=1011.119 ms > 64 bytes from 192.168.1.2: icmp_seq=22 ttl=32 time=1011.110 ms > 64 bytes from 192.168.1.2: icmp_seq=23 ttl=32 time=1011.130 ms > 64 bytes from 192.168.1.2: icmp_seq=24 ttl=32 time=1011.091 ms > 64 bytes from 192.168.1.2: icmp_seq=25 ttl=32 time=1011.127 ms > 64 bytes from 192.168.1.2: icmp_seq=26 ttl=32 time=1011.106 ms > 64 bytes from 192.168.1.2: icmp_seq=27 ttl=32 time=1011.161 ms > 64 bytes from 192.168.1.2: icmp_seq=28 ttl=32 time=1011.091 ms > 64 bytes from 192.168.1.2: icmp_seq=29 ttl=32 time=1011.164 ms > 64 bytes from 192.168.1.2: icmp_seq=30 ttl=32 time=1011.131 ms > ^C > --- tddti.tddhome ping statistics --- > 32 packets transmitted, 31 packets received, 3% packet loss > round-trip min/avg/max/stddev = 3.107/370.286/1011.164/476.031 ms > > === dmesg ====================== > # dmesg > Copyright (c) 1992-1999 The FreeBSD Project. > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > FreeBSD 4.0-CURRENT #0: Sat Jun 12 14:22:28 PDT 1999 > tomdean@celebris:/usr/src/sys/compile/CELEBRIS-SMP > Timecounter "i8254" frequency 1193182 Hz > CPU: Pentium/P54C (586-class CPU) > Origin = "GenuineIntel" Id = 0x525 Stepping=5 > Features=0x3bf > real memory = 100663296 (98304K bytes) > avail memory = 94887936 (92664K bytes) > Programming 16 pins in IOAPIC #0 > FreeBSD/SMP: Multiprocessor motherboard > cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee00000 > cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee00000 > io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec00000 > Preloaded elf kernel "kernel" at 0xc02c7000. > Intel Pentium detected, installing workaround for F00F bug > npx0: on motherboard > npx0: INT 16 interface > pcib0: on motherboard > pci0: on pcib0 > chip0: at device 0.0 on pci0 > ncr0: irq 11 at device 1.0 on pci0 > isab0: at device 2.0 on pci0 > vga-pci0: irq 9 at device 6.0 on pci0 > de0: irq 10 at device 8.0 on pci0 > de0: DEC DE450-CA 21041 [10Mb/s] pass 1.1 > de0: address 00:00:f8:02:76:db > isa0: on motherboard > fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 > fdc0: FIFO enabled, 8 bytes threshold > fd0: <1440-KB 3.5" drive> at fdc0 drive 0 > atkbdc0: at port 0x60-0x6f on isa0 > atkbd0: irq 1 on atkbdc0 > psm0: irq 12 on atkbdc0 > psm0: model Generic PS/2 mouse, device ID 0 > vga0: on isa0 > sc0: on isa0 > sc0: VGA color <16 virtual consoles, flags=0x0> > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > ppc0 at port 0x378-0x37f irq 7 on isa0 > ppc0: PC87334 chipset (PS2/NIBBLE) in COMPATIBLE mode > lpt0: on ppbus 0 > lpt0: Interrupt-driven port > APIC_IO: Testing 8254 interrupt delivery > APIC_IO: routing 8254 via pin 2 > Waiting 10 seconds for SCSI devices to settle > SMP: AP CPU #1 Launched! > da0 at ncr0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 10.000MB/s transfers (10.000MHz, offset 8) > da0: 1042MB (2134305 512 byte sectors: 255H 63S/T 132C) > cd0 at ncr0 bus 0 target 5 lun 0 > cd0: Removable CD-ROM SCSI-2 device > cd0: 4.237MB/s transfers (4.237MHz, offset 8) > cd0: cd present [59444 x 2048 byte records] > da2 at ncr0 bus 0 target 2 lun 0 > da2: Fixed Direct Access SCSI-2 device > da2: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled > da2: 1029MB (2109376 512 byte sectors: 255H 63S/T 131C) > da1 at ncr0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled > da1: 3090MB (6328861 512 byte sectors: 255H 63S/T 393C) > changing root device to da1s1a > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 13 21:55:39 1999 Delivered-To: freebsd-current@freebsd.org Received: from ix.netcom.com (sil-wa15-09.ix.netcom.com [207.93.148.9]) by hub.freebsd.org (Postfix) with ESMTP id 28F2D151C7 for ; Sun, 13 Jun 1999 21:55:36 -0700 (PDT) (envelope-from tomdean@ix.netcom.com) Received: (from tomdean@localhost) by ix.netcom.com (8.9.3/8.8.8) id VAA82259; Sun, 13 Jun 1999 21:55:30 -0700 (PDT) (envelope-from tomdean@ix.netcom.com) Date: Sun, 13 Jun 1999 21:55:30 -0700 (PDT) Message-Id: <199906140455.VAA82259@ix.netcom.com> X-Authentication-Warning: celebris.tddhome: tomdean set sender to tomdean@ix.netcom.com using -f From: Thomas Dean To: jbryant@unix.tfs.net Cc: freebsd-current@freebsd.org In-reply-to: <199906140433.XAA53459@argus.tfs.net> (message from Jim Bryant on Sun, 13 Jun 1999 23:33:45 -0500 (CDT)) Subject: Re: Very Strange Local Network Behavior References: <199906140433.XAA53459@argus.tfs.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The system worked correctly before the make/kernel rebuild. I just put a termination at the second machine to eliminate the remainder of the network. tomdean To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 13 22:17:38 1999 Delivered-To: freebsd-current@freebsd.org Received: from ix.netcom.com (sil-wa16-50.ix.netcom.com [207.93.148.178]) by hub.freebsd.org (Postfix) with ESMTP id 4EFB614F6A for ; Sun, 13 Jun 1999 22:17:33 -0700 (PDT) (envelope-from tomdean@ix.netcom.com) Received: (from tomdean@localhost) by ix.netcom.com (8.9.3/8.8.8) id WAA00638; Sun, 13 Jun 1999 22:17:31 -0700 (PDT) (envelope-from tomdean@ix.netcom.com) Date: Sun, 13 Jun 1999 22:17:31 -0700 (PDT) Message-Id: <199906140517.WAA00638@ix.netcom.com> X-Authentication-Warning: celebris.tddhome: tomdean set sender to tomdean@ix.netcom.com using -f From: Thomas Dean To: freebsd-current@FreeBSD.ORG Subject: Re: Very Strange Local Network Behavior References: <199906140433.XAA53459@argus.tfs.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Fixed. cvsup, make world, reboot fixed it. I rebooted before the make world and still had the problem. Notice the ping time is ~1ms, where before it was ~5ms before the ~1sec started. Strange. tomdean === ping ================= # ping tddti PING tddti.tddhome (192.168.1.2): 56 data bytes 64 bytes from 192.168.1.2: icmp_seq=0 ttl=32 time=2.130 ms 64 bytes from 192.168.1.2: icmp_seq=1 ttl=32 time=1.104 ms 64 bytes from 192.168.1.2: icmp_seq=2 ttl=32 time=1.096 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=32 time=1.093 ms 64 bytes from 192.168.1.2: icmp_seq=4 ttl=32 time=1.093 ms 64 bytes from 192.168.1.2: icmp_seq=5 ttl=32 time=1.091 ms 64 bytes from 192.168.1.2: icmp_seq=6 ttl=32 time=1.123 ms 64 bytes from 192.168.1.2: icmp_seq=7 ttl=32 time=1.108 ms 64 bytes from 192.168.1.2: icmp_seq=8 ttl=32 time=1.090 ms 64 bytes from 192.168.1.2: icmp_seq=9 ttl=32 time=1.096 ms 64 bytes from 192.168.1.2: icmp_seq=10 ttl=32 time=1.109 ms 64 bytes from 192.168.1.2: icmp_seq=11 ttl=32 time=1.098 ms 64 bytes from 192.168.1.2: icmp_seq=12 ttl=32 time=1.114 ms 64 bytes from 192.168.1.2: icmp_seq=13 ttl=32 time=1.115 ms 64 bytes from 192.168.1.2: icmp_seq=14 ttl=32 time=1.112 ms 64 bytes from 192.168.1.2: icmp_seq=15 ttl=32 time=1.096 ms 64 bytes from 192.168.1.2: icmp_seq=16 ttl=32 time=1.098 ms 64 bytes from 192.168.1.2: icmp_seq=17 ttl=32 time=1.113 ms 64 bytes from 192.168.1.2: icmp_seq=18 ttl=32 time=1.109 ms 64 bytes from 192.168.1.2: icmp_seq=19 ttl=32 time=1.119 ms 64 bytes from 192.168.1.2: icmp_seq=20 ttl=32 time=1.108 ms ^C --- tddti.tddhome ping statistics --- 21 packets transmitted, 21 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.090/1.153/2.130/0.219 ms To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 0: 7:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 81AC814EBD; Mon, 14 Jun 1999 00:07:31 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id AAA06800; Mon, 14 Jun 1999 00:07:29 -0700 (PDT) (envelope-from dillon) Date: Mon, 14 Jun 1999 00:07:29 -0700 (PDT) From: Matthew Dillon Message-Id: <199906140707.AAA06800@apollo.backplane.com> To: "David E. Cross" Cc: The Hermit Hacker , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: MMAP() in STABLE/CURRENT ... References: <199906140122.VAA02659@cs.rpi.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Here's the code: : :#include :#include :#include :#include :#include :#include : :#define DBSIZE 733055625 : :int main(void) :{ : int fd; : unsigned char *dbp; : : fd=open(argv[1], O_CREAT | O_RDWR | O_TRUNC, 0600); : lseek(fd, DBSIZE -1, SEEK_SET); : write(fd, &fd, 1); : dbp=mmap(NULL, DBSIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); : close (fd); : memset(dbp, 0, DBSIZE); : munmap(dbp, DBSIZE); : return 0; :} :} Someone asked me at USENIX what would happen if the filesystem filled up due to someone mmap'ing a file shared and then filled in its holes by modifying the mmaping. In your tests, are you intentionally filling up the filesystem? You appear to be writing a rather large file - 733MB. I'm just trying to narrow down where the bug is... the system isn't supposed to panic or deadlock even if you do fill up the filesystem. Your test program may also be hitting another known bug: If you dirty the pages underlying a mapped file the system does not currently limit the number of pages that can be dirtied. It is possible to eat up all available memory and cause a deadlock to occur when the system is unable to write the pages out to the file due to blocking on the access to the file's indirect blocks. Actually, I think this is the more likely scenario. This bug is already on my list. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 0:16: 2 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id CA63C14BD4; Mon, 14 Jun 1999 00:15:59 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id AAA06844; Mon, 14 Jun 1999 00:15:57 -0700 (PDT) (envelope-from dillon) Date: Mon, 14 Jun 1999 00:15:57 -0700 (PDT) From: Matthew Dillon Message-Id: <199906140715.AAA06844@apollo.backplane.com> To: The Hermit Hacker Cc: "David E. Cross" , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: MMAP() in STABLE/CURRENT ... References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> David, can you email this program to me please? :> :> Also, which FreeBSD release does this occur on? :> :> I've got about 6 mmap-related bugs on my plate at the moment. 3 of them :> have been identified ( that is, I know why they deadlock the machine ), :> but none have been fixed yet. : :Matt, I'll volunteer myself as a tester for this code under 3.2-STABLE, :when you have it ready... : :Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy :Systems Administrator @ hub.org :primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org I'll let the lists know when patches are available. It may be a while (like a week), I still have a lot of catching-up to do after being at USENIX all last week and my commit privs still need to be resolved. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 1: 2:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id B5A2314E0D for ; Mon, 14 Jun 1999 01:02:48 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id CAA43568; Mon, 14 Jun 1999 02:02:46 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id CAA81388; Mon, 14 Jun 1999 02:02:18 -0600 (MDT) Message-Id: <199906140802.CAA81388@harmony.village.org> To: Doug White Subject: Re: can't install on machine with 8 Meg Cc: Tim Vanderhoek , Brian Dean , freebsd-current@FreeBSD.ORG In-reply-to: Your message of "Sun, 13 Jun 1999 20:56:53 PDT." References: Date: Mon, 14 Jun 1999 02:02:15 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Doug White writes: : Becuase in 8MB sysinstall mysteriously tanks during extraction, and works : fine with 12. No error message is produced, so I'm guessing it's a : non- or silently-errorchecked malloc(). I can reproduce this. The docs : are all wrong, thus the PR. I'll have to see if my 9M system can cope... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 2:30:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from enst.enst.fr (enst.enst.fr [137.194.2.16]) by hub.freebsd.org (Postfix) with ESMTP id B1C7714E70 for ; Mon, 14 Jun 1999 02:30:43 -0700 (PDT) (envelope-from beyssac@enst.fr) Received: from bofh.enst.fr (bofh-2.enst.fr [137.194.2.37]) by enst.enst.fr (8.9.1a/8.9.1) with ESMTP id LAA13929; Mon, 14 Jun 1999 11:30:24 +0200 (MET DST) Received: by bofh.enst.fr (Postfix, from userid 12426) id 9B92DD226; Mon, 14 Jun 1999 11:30:23 +0200 (CEST) Message-ID: <19990614113023.A54926@enst.fr> Date: Mon, 14 Jun 1999 11:30:23 +0200 From: Pierre Beyssac To: Matthew Dillon , Joel Ray Holveck Cc: Garrett Wollman , Brian Feldman , current@FreeBSD.ORG Subject: Re: RE: net.inet.tcp.always_keepalive on as default ? References: <199906052344.TAA19843@khavrinen.lcs.mit.edu> <199906060057.UAA20103@khavrinen.lcs.mit.edu> <199906060626.XAA17701@apollo.backplane.com> <86d7z6j89k.fsf@detlev.UUCP> <199906130411.VAA65201@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199906130411.VAA65201@apollo.backplane.com>; from Matthew Dillon on Sat, Jun 12, 1999 at 09:11:23PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jun 12, 1999 at 09:11:23PM -0700, Matthew Dillon wrote: > I can only repeat: Turn them on and see if they effect you. You will > almost certainly find that they do not effect you. Ask your friend to > turn them on and see if they effect him. If he's tailing syslog in those Since it doesn't affect anybody according to you, you're implicitly admitting there's really no use turning them on either. Your argument self-destructs! Regarding syslog, you can perfectly tail a log which logs only urgent messages, i.e. you *won't* have any message in it in normal circonstances. Then you *don't* want it closed because of a temporary network outage. This discussion has been way beyond rational arguments from the beginning (the only real work on the matter, RFC 1122, has been discarded from the start as outdated), and PHK has committed the change more than one week ago, so I don't see the point in going on. -- Pierre Beyssac pb@enst.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 3:16:58 1999 Delivered-To: freebsd-current@freebsd.org Received: from fleming.cs.strath.ac.uk (fleming.cs.strath.ac.uk [130.159.196.126]) by hub.freebsd.org (Postfix) with ESMTP id BE0021508E; Mon, 14 Jun 1999 03:16:53 -0700 (PDT) (envelope-from roger@cs.strath.ac.uk) Received: from muir-10 (roger@muir-10.cs.strath.ac.uk [130.159.148.10]) by fleming.cs.strath.ac.uk (8.8.8/8.8.8) with SMTP id LAA02804 Mon, 14 Jun 1999 11:16:42 +0100 (BST) Message-ID: <3764D689.41C6@cs.strath.ac.uk> Date: Mon, 14 Jun 1999 11:16:41 +0100 From: Roger Hardiman Organization: University of Strathclyde X-Mailer: Mozilla 3.04Gold (X11; I; OSF1 V4.0 alpha) MIME-Version: 1.0 To: just matt , Juha.Nurmela@quicknet.inet.fi, Randy Bush Cc: multimedia@FreeBSD.ORG, current@FreeBSD.ORG Subject: Hauppauge MSP3430 audio fix. Please test References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG We now have working audio for Hauppauge WinCast/TV users with the MSP3430G DBX stereo chip. Thanks to Matt, Juhn, Randy and everyone else who got it working. An updated bt848/bt878 bktr driver for FreeBSD 3.1, 3.2, 3.x-stable and 4.x users can be found in the snapshots section of http://telepresence.dmem.strath.ac.uk/bt848 Please can you download and test. Also, can some European MSP3410/3415 users check the driver too to make sure I have not broken your support. Email your feedback to roger@cs.strath.ac.uk or roger@freebsd.org Bye Roger -- Roger Hardiman | Telepresence Research Group roger@cs.strath.ac.uk | DMEM, University of Strathclyde tel: 0141 548 2897 | Glasgow, Scotland, G1 1XJ, UK fax: 0141 552 0557 | http://telepresence.dmem.strath.ac.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 6:14:32 1999 Delivered-To: freebsd-current@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 54145152DB for ; Mon, 14 Jun 1999 06:14:24 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 10tWZD-0002Es-00 for current@freebsd.org; Mon, 14 Jun 1999 15:14:23 +0200 From: Sheldon Hearn To: current@freebsd.org Subject: inetd+libwrap bugfixes Date: Mon, 14 Jun 1999 15:14:22 +0200 Message-ID: <8609.929366062@axl.noc.iafrica.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, I'm following up to the discussion that's taken place recently over the issue of the base system not including a tcpd. I believe that quite a few folks want tcpd to make up for a few problems with our inetd's libwrap support. Those who fall into this category should try and comment on the diffs attached to PR 12097 . While it may be true that inetd's libwrap problems currently support the argument for a tcpd in the base system, our end goal is to offer an inetd that makes it completely unnecessary. This means that including a tcpd in the base system only to remove it later would be silly. Ciao, Sheldon. PS: It's amazing how many people have so much time for offering misguided arguments, yet so little for working on the issues. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 7:36:20 1999 Delivered-To: freebsd-current@freebsd.org Received: from smyk.apk.net (smyk.apk.net [207.54.158.17]) by hub.freebsd.org (Postfix) with ESMTP id C58EB15322 for ; Mon, 14 Jun 1999 07:36:09 -0700 (PDT) (envelope-from ipswitch@junior.apk.net) Received: from junior.apk.net (ipswitch@junior.apk.net [207.54.158.20]) by smyk.apk.net (8.9.3/8.9.3/apk.981124) with ESMTP id KAA08427 for ; Mon, 14 Jun 1999 10:27:21 -0400 (EDT) Received: (from ipswitch@localhost) by junior.apk.net (8.9.3/8.9.3) id KAA27214 for freebsd-current@freebsd.org; Mon, 14 Jun 1999 10:27:53 -0400 (EDT) X-Real-To: freebsd-current@freebsd.org Date: Mon, 14 Jun 1999 10:27:53 -0400 From: Ipswitch To: freebsd-current@freebsd.org Subject: Question on ports system Message-ID: <19990614102753.A25023@junior.apk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I really like the ports system, but there are times when it would be easier to use a package. Has anyone thought about combining the ports system with packages a bit? Perhaps an option like "make get" that would grab the package and install it for you. I guess I just like the way that ports work and would prefer this as a way of installing packages. Why packages at all? It can be faster... Stuart To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 7:53:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (Postfix) with ESMTP id E759414BD8 for ; Mon, 14 Jun 1999 07:53:43 -0700 (PDT) (envelope-from Dom.Mitchell@palmerharvey.co.uk) Received: from ho-nt-01.pandhm.co.uk (unverified) by mail.palmerharvey.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 14 Jun 1999 15:52:45 +0100 Received: from voodoo.pandhm.co.uk (VOODOO [10.100.35.12]) by ho-nt-01.pandhm.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MKM83NBT; Mon, 14 Jun 1999 15:44:52 +0100 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 10tYBm-00089z-00; Mon, 14 Jun 1999 15:58:18 +0100 To: Ipswitch Cc: freebsd-current@freebsd.org Subject: Re: Question on ports system X-Mailer: nmh-1.0 X-Colour: Green Organization: Palmer & Harvey McLane In-Reply-To: Ipswitch's message of "Mon, 14 Jun 1999 10:27:53 EDT" <19990614102753.A25023@junior.apk.net> Date: Mon, 14 Jun 1999 15:58:18 +0100 From: Dom Mitchell Message-Id: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 14 June 1999, Ipswitch proclaimed: > I really like the ports system, but there are times when it would be > easier to use a package. Has anyone thought about combining the ports > system with packages a bit? > > Perhaps an option like "make get" that would grab the package and install > it for you. > > I guess I just like the way that ports work and would prefer this as a > way of installing packages. You can make it fairly easy with a shell function: rpkgadd () { sudo pkg_add ftp://ftp.freebsd.org/pub/FreeBSD/packages/All/$1.tgz } (csh users can figure it out for themselves...) You can start to get more sophisticated than this, probably even to the point of including completion in zsh if you mirror the ls-lR file. As to adjusting bsd.port.mk - I've always been scared off by the complexity! -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator "Always think very hard before messing with TCP. And then don't." -- MC -- ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 9: 5:13 1999 Delivered-To: freebsd-current@freebsd.org Received: from lupo.thebarn.com (lupo.lcse.umn.edu [128.101.182.105]) by hub.freebsd.org (Postfix) with ESMTP id 92F58151B2 for ; Mon, 14 Jun 1999 09:05:01 -0700 (PDT) (envelope-from cattelan@thebarn.com) Received: from thebarn.com (jizz.thebarn.com [128.101.182.205]) by lupo.thebarn.com (8.9.3/8.9.1) with ESMTP id LAA41112; Mon, 14 Jun 1999 11:04:45 -0500 (CDT) Message-ID: <376527F0.395EB392@thebarn.com> Date: Mon, 14 Jun 1999 11:04:00 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.51C-SGI [en] (X11; U; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: jbryant@unix.tfs.net Cc: freebsd-current@FreeBSD.ORG Subject: Re: sound driver setup References: <199906132243.RAA52418@argus.tfs.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jim Bryant wrote: > okay, here's the deal. > > I have a Tyan Thunder-2 Motherboard, S1696DLUA, running -current SMP. > > does anyone have successfully running: > > 1). the OPL3-SAx sound driver for the motherboard sound? > 2). a Soundblaster-Live? > > I would appreciate a sample config file, as I'm at a loss as to the > cause of these NOT being detected. > Try this patch. If it still doesn't work, run pnpinfo and find out what Vendor ID it is reporting. i.e. Vendor ID YMH0802 (0x0208a865), Serial Number 0xffffffff Note the sound quality of that card... umm well it sucks! It is ok for simple stuff but I wouldn't try and listen to music. Index: ad1848.c =================================================================== RCS file: /usr/FreeBSD-CVS/src/sys/i386/isa/snd/ad1848.c,v retrieving revision 1.23 diff -u -r1.23 ad1848.c --- ad1848.c 1999/05/12 19:01:29 1.23 +++ ad1848.c 1999/05/12 22:07:15 @@ -1461,6 +1461,8 @@ s = "Yamaha SA2"; else if ( id == 0x3000a865) s = "Yamaha SA3"; + else if ( id == 0x2100a865) + s = "Yamaha SA3"; else if ( id == 0x0000a865) s = "Yamaha YMF719 OPL-SA3"; else if (vend_id == 0x8140d315) @@ -1520,7 +1522,8 @@ dev->id_alive = 16 ; /* number of io ports ? */ tmp_d = sb_op_desc ; if (vend_id==0x2000a865 || vend_id==0x3000a865 || - vend_id==0x0008a865 || vend_id==0x8140d315) { + vend_id==0x0008a865 || vend_id==0x8140d315 || + vend_id==0x2100a865 ) { /* Yamaha SA2/SA3 or ENSONIQ SoundscapeVIVO ENS4081 */ dev->id_iobase = d.port[0] ; tmp_d.alt_base = d.port[1] ; @@ -1539,6 +1542,7 @@ case 0x2000a865: /* Yamaha SA2 */ case 0x3000a865: /* Yamaha SA3 */ + case 0x2100a865: /* Yamaha SA3 */ case 0x0000a865: /* Yamaha TMF719 SA3 */ dev->id_iobase = d.port[1]; tmp_d.alt_base = d.port[0]; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 9:15:55 1999 Delivered-To: freebsd-current@freebsd.org Received: from thelab.hub.org (nat192.211.mpoweredpc.net [142.177.192.211]) by hub.freebsd.org (Postfix) with ESMTP id CACC814A12; Mon, 14 Jun 1999 09:15:51 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id NAA35438; Mon, 14 Jun 1999 13:15:23 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Mon, 14 Jun 1999 13:15:22 -0300 (ADT) From: The Hermit Hacker To: Matthew Dillon Cc: "David E. Cross" , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: MMAP() in STABLE/CURRENT ... In-Reply-To: <199906140715.AAA06844@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 14 Jun 1999, Matthew Dillon wrote: > > :> > :> David, can you email this program to me please? > :> > :> Also, which FreeBSD release does this occur on? > :> > :> I've got about 6 mmap-related bugs on my plate at the moment. 3 of them > :> have been identified ( that is, I know why they deadlock the machine ), > :> but none have been fixed yet. > : > :Matt, I'll volunteer myself as a tester for this code under 3.2-STABLE, > :when you have it ready... > : > :Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy > :Systems Administrator @ hub.org > :primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org > > I'll let the lists know when patches are available. It may be a while > (like a week), I still have a lot of catching-up to do after being at > USENIX all last week and my commit privs still need to be resolved. Those of us with production 3.2-STABLE machines patiently await :) Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 9:19:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 19D8614E25; Mon, 14 Jun 1999 09:19:29 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id MAA13146; Mon, 14 Jun 1999 12:19:17 -0400 (EDT) Message-Id: <199906141619.MAA13146@cs.rpi.edu> To: The Hermit Hacker Cc: Matthew Dillon , "David E. Cross" , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: MMAP() in STABLE/CURRENT ... In-Reply-To: Message from The Hermit Hacker of "Mon, 14 Jun 1999 13:15:22 -0300." Date: Mon, 14 Jun 1999 12:19:17 -0400 From: "David E. Cross" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 14 Jun 1999, Matthew Dillon wrote: > > :> > :> David, can you email this program to me please? > :> > :> Also, which FreeBSD release does this occur on? > :> > :> I've got about 6 mmap-related bugs on my plate at the moment. 3 of them > :> have been identified ( that is, I know why they deadlock the machine ), > :> but none have been fixed yet. > : > :Matt, I'll volunteer myself as a tester for this code under 3.2-STABLE, > :when you have it ready... > : > :Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy > :Systems Administrator @ hub.org > :primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org > > I'll let the lists know when patches are available. It may be a while > (like a week), I still have a lot of catching-up to do after being at > USENIX all last week and my commit privs still need to be resolved. I will also volunteer for this. Also, the drive in question has plently of space available for the large file. I think it is clearly the dirty pages issue you listed. -- David Cross | email: crossd@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 9:35:17 1999 Delivered-To: freebsd-current@freebsd.org Received: from dingo.cdrom.com (castles532.castles.com [208.214.165.96]) by hub.freebsd.org (Postfix) with ESMTP id B980414DFE for ; Mon, 14 Jun 1999 09:35:13 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id JAA02884; Mon, 14 Jun 1999 09:30:34 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199906141630.JAA02884@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Ipswitch Cc: freebsd-current@freebsd.org Subject: Re: Question on ports system In-reply-to: Your message of "Mon, 14 Jun 1999 10:27:53 EDT." <19990614102753.A25023@junior.apk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Jun 1999 09:30:34 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I really like the ports system, but there are times when it would be > easier to use a package. Has anyone thought about combining the ports > system with packages a bit? Not necessary, really. Try 'pkg_add -r ', eg. pkg_add -r emacs does what you think it should. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 10:32:57 1999 Delivered-To: freebsd-current@freebsd.org Received: from peedub.muc.de (newpc.muc.ditec.de [194.120.126.33]) by hub.freebsd.org (Postfix) with ESMTP id C5F1B14D6D for ; Mon, 14 Jun 1999 10:32:52 -0700 (PDT) (envelope-from garyj@peedub.muc.de) Received: from peedub.muc.de (localhost [127.0.0.1]) by peedub.muc.de (8.9.3/8.6.9) with ESMTP id TAA44297; Mon, 14 Jun 1999 19:30:57 +0200 (CEST) Message-Id: <199906141730.TAA44297@peedub.muc.de> X-Mailer: exmh version 2.0.2 2/24/98 To: Richard Michael Todd Cc: freebsd-current@FreeBSD.ORG Subject: Re: use of MMAP in new INN code... Reply-To: Gary Jennejohn In-reply-to: Your message of "Fri, 11 Jun 1999 12:21:50 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Jun 1999 19:30:57 +0200 From: Gary Jennejohn Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Richard Michael Todd writes: >In message Marc= Fourn >ier writes: >P.S. is there any easier way to get process struct addresses out of kgdb= other >than to keep doing "p (struct proc *)curproc->p_list->le_next->p_list->l= e_next >..." >until you find the process struct you're looking for? > seems like you should be able to shell-prompt> ps -M foo -N bar get the pid of the interesting process (kgdb) proc pid but I haven't tried it out. --- Gary Jennejohn Home - garyj@muc.de Work - garyj@fkr.dec.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 11:40:57 1999 Delivered-To: freebsd-current@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id AC54615331 for ; Mon, 14 Jun 1999 11:40:55 -0700 (PDT) (envelope-from cmpnerds@enteract.com) Received: (qmail 65556 invoked from network); 14 Jun 1999 18:40:54 -0000 Received: from adam.enteract.com (cmpnerds@206.54.252.1) by pop3-3.enteract.com with SMTP; 14 Jun 1999 18:40:54 -0000 Date: Mon, 14 Jun 1999 13:40:52 -0500 (CDT) From: cmpnerds To: freebsd-current@freebsd.org Subject: problem in audio.o?? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just cvsuped. First Generic Kernel worked. Attemptes to compile in sound (non voxware) and got the following error audio.o: In function `set_format': audio.o(.text+0x57): undefined reference to `DMAbuf_ioctl' audio.o: In function `audio_open': audio.o(.text+0xbe): undefined reference to `DMAbuf_open' audio.o(.text+0x125): undefined reference to `DMAbuf_ioctl' audio.o: In function `audio_release': audio.o(.text+0x1d3): undefined reference to `DMAbuf_start_output' audio.o(.text+0x207): undefined reference to `DMAbuf_release' audio.o: In function `audio_write': audio.o(.text+0x2de): undefined reference to `DMAbuf_start_output' audio.o(.text+0x32f): undefined reference to `DMAbuf_getwrbuffer' audio.o(.text+0x43b): undefined reference to `DMAbuf_start_output' audio.o: In function `audio_read': audio.o(.text+0x4b4): undefined reference to `DMAbuf_start_output' audio.o(.text+0x525): undefined reference to `DMAbuf_getrdbuffer' audio.o(.text+0x59c): undefined reference to `DMAbuf_rmchars' audio.o: In function `audio_ioctl': audio.o(.text+0x6de): undefined reference to `DMAbuf_start_output' audio.o(.text+0x715): undefined reference to `DMAbuf_start_output' audio.o(.text+0x791): undefined reference to `DMAbuf_ioctl' audio.o(.text+0x7e1): undefined reference to `DMAbuf_ioctl' audio.o(.text+0x8a9): undefined reference to `DMAbuf_ioctl' audio.o: In function `audio_poll': audio.o(.text+0x929): undefined reference to `DMAbuf_poll' sequencer.o: In function `seq_local_event': sequencer.o(.text+0xfad): undefined reference to `DMAbuf_start_devices' *** Error code 1 Stop. Help!!! Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 12:19:54 1999 Delivered-To: freebsd-current@freebsd.org Received: from argus.tfs.net (node42.unassigned245.tfs.net [139.146.245.42]) by hub.freebsd.org (Postfix) with ESMTP id D1E8015228; Mon, 14 Jun 1999 12:19:46 -0700 (PDT) (envelope-from jbryant@argus.tfs.net) Received: (from jbryant@localhost) by argus.tfs.net (8.9.3/8.8.5) id OAA76240; Mon, 14 Jun 1999 14:19:43 -0500 (CDT) From: Jim Bryant Message-Id: <199906141919.OAA76240@argus.tfs.net> Subject: Hauppage Wincast/TV Theatre card radio function To: freebsd-current@freebsd.org Date: Mon, 14 Jun 1999 14:19:41 -0500 (CDT) Cc: roger@cs.strath.ac.uk, roger@freebsd.org Reply-To: jbryant@unix.tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-files: The truth is that the X-Files is fiction X-Republican: The best kind!!! X-Operating-System: FreeBSD 4.0-CURRENT #31: Thu Apr 8 10:40:17 CDT 1999 X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG the default settings in the bktr driver for radio are 5.6 MHz high on this card. i have confirmed this using miniradio.c as well as xmradio. to listen to station 98.90, you must tune the driver to 93.30. I have verified this across the dial. i believe i gave my boot messages in a previous private message today informing you that I have had no problems so far using the modified driver you announced today. jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 13: 4:16 1999 Delivered-To: freebsd-current@freebsd.org Received: from alpha.netvision.net.il (alpha.netvision.net.il [194.90.1.13]) by hub.freebsd.org (Postfix) with ESMTP id A9EBF15579 for ; Mon, 14 Jun 1999 13:04:06 -0700 (PDT) (envelope-from spud@i.am) Received: from Tomer.DrugsAreGood.org (RAS7-p92.hfa.netvision.net.il [62.0.149.92]) by alpha.netvision.net.il (8.9.3/8.8.6) with SMTP id XAA14752 for ; Mon, 14 Jun 1999 23:04:04 +0300 (IDT) From: Tomer Weller To: FreeBSD Current Subject: /usr/src/UPDATING Date: Mon, 14 Jun 1999 22:45:51 +0300 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <99061422463101.00303@Tomer.DrugsAreGood.org> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG i've noticed no1 touches the /usr/src/UPDATING file... shame... ====================================== Tomer Weller spud@i.am wellers@netvision.net.il "Drugs are good, and if you do'em pepole think that you're cool", NoFX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 13:18:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from uni-sb.de (uni-sb.de [134.96.252.33]) by hub.freebsd.org (Postfix) with ESMTP id CBE7B14DCF for ; Mon, 14 Jun 1999 13:18:17 -0700 (PDT) (envelope-from netchild@Vodix.CS.Uni-SB.de) Received: from work.net.local (maxtnt-151.telip.uni-sb.de [134.96.71.22]) by uni-sb.de (8.9.3/1999031900) with ESMTP id WAA03298 for ; Mon, 14 Jun 1999 22:18:11 +0200 (CEST) X-Authentication-Warning: uni-sb.de: Host maxtnt-151.telip.uni-sb.de [134.96.71.22] claimed to be work.net.local Received: from Vodix.CS.Uni-SB.de (localhost.net.local [127.0.0.1]) by work.net.local (8.9.3/8.9.3) with ESMTP id RAA00531 for ; Mon, 14 Jun 1999 17:06:24 +0200 (CEST) (envelope-from netchild@Vodix.CS.Uni-SB.de) Message-Id: <199906141506.RAA00531@work.net.local> Date: Mon, 14 Jun 1999 17:06:22 +0200 (CEST) From: A.Leidinger@WJPServer.CS.Uni-SB.de Subject: Problems with afd0 & ZIP 100 To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, all disks (2) with a msdosfs on it didn't want to give access. dmesg: ata-pci0: at device 4.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 afd0: rewriteable drive at ata0 as slave afd0: 96MB (196608 sectors), 32 cyls, 64 heads, 96 S/T, 512 B/S afd0: Medium: Unknown media (0x0) A kernel with wfd instead of afd prints: wfd0: buggy Zip drive, 64-block transfer limit set fstab: /dev/afd0s4 /zip msdos rw,-u=1000,nosuid,noexec,-g=1000,nodev,noatime,noauto (103) root@ttyp0 # mount /zip msdos: /dev/afd0s4: Invalid argument (105) root@ttyp0 # ll /dev/afd0s4 brw-rw-rw- 1 root operator 32, 0x00050002 14 Jun 16:24 /dev/afd0s4 MTools: (106) root@ttyp0 # mdir z: init Z: non DOS media Cannot initialize 'Z:' (107) root@ttyp0 # grep z: /usr/local/etc/mtools.conf drive z: file="/dev/rafd0s4" (108) root@ttyp0 # ll /dev/rafd0s4 crw-rw-rw- 1 root operator 118, 0x00050002 14 Jun 16:24 /dev/rafd0s4 /usr/src/sys/dev/ata/atapi-fd.c: $Id: atapi-fd.c,v 1.10 1999/05/31 11:24:29 phk Exp $ -current from Jun 13 around 1am CEST. Is there something I've missed? Bye, Alexander. -- The fastest-moving thing in the world is a bad check. http://netchild.home.pages.de A.Leidinger+Home @ WJPServer.CS.Uni-SB.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 14:31:54 1999 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id F41AF15168 for ; Mon, 14 Jun 1999 14:31:43 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id OAA44446; Mon, 14 Jun 1999 14:31:28 -0700 (PDT) (envelope-from obrien) Message-ID: <19990614143128.A44407@nuxi.com> Date: Mon, 14 Jun 1999 14:31:28 -0700 From: "David O'Brien" To: Mike Smith Cc: freebsd-current@FreeBSD.ORG Subject: Re: Question on ports system Reply-To: obrien@NUXI.com References: <19990614102753.A25023@junior.apk.net> <199906141630.JAA02884@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199906141630.JAA02884@dingo.cdrom.com>; from Mike Smith on Mon, Jun 14, 1999 at 09:30:34AM -0700 X-Operating-System: FreeBSD 3.2-BETA Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Not necessary, really. Try 'pkg_add -r ', eg. > pkg_add -r emacs > does what you think it should. Not quite. :-( Fetching ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/Latest/ ^^^^^^^^ Maybe we need symlinks of ports//packages--latest/ and make ``pkg_add'' a little smarter. -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 14:55:41 1999 Delivered-To: freebsd-current@freebsd.org Received: from kushnir.kiev.ua (n187.cdialup.kar.net [195.178.130.187]) by hub.freebsd.org (Postfix) with ESMTP id AC0EB14DAE for ; Mon, 14 Jun 1999 14:55:19 -0700 (PDT) (envelope-from kushn@mail.kar.net) Received: from localhost (volodya@localhost) by kushnir.kiev.ua (8.9.3/8.9.3) with ESMTP id AAA36458 for ; Tue, 15 Jun 1999 00:55:08 +0300 (EEST) (envelope-from kushn@mail.kar.net) X-Authentication-Warning: kushnir.kiev.ua: volodya owned process doing -bs Date: Tue, 15 Jun 1999 00:55:07 +0300 (EEST) From: Vladimir Kushnir X-Sender: volodya@kushnir.kiev.ua To: freebsd-current@FreeBSD.ORG Subject: What happened to CTM src-cur? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is it only my problem or CTM src-cur deltas aren't generated since Jun 8? Regards, Vladimir ===========================|======================= Vladimir Kushnir | kushn@mail.kar.net, | Powered by FreeBSD kushnir@ap3.bitp.kiev.ua | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 15: 3:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id 4D2E615019 for ; Mon, 14 Jun 1999 15:03:30 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: (qmail 36901 invoked from network); 14 Jun 1999 22:03:27 -0000 Received: from shell-3.enteract.com (dscheidt@207.229.143.42) by pop3-3.enteract.com with SMTP; 14 Jun 1999 22:03:27 -0000 Received: from localhost (dscheidt@localhost) by shell-3.enteract.com (8.9.3/8.9.2) with SMTP id RAA09931; Mon, 14 Jun 1999 17:03:27 -0500 (CDT) (envelope-from dscheidt@enteract.com) X-Authentication-Warning: shell-3.enteract.com: dscheidt owned process doing -bs Date: Mon, 14 Jun 1999 17:03:27 -0500 (CDT) From: David Scheidt To: Vladimir Kushnir Cc: freebsd-current@FreeBSD.ORG Subject: Re: What happened to CTM src-cur? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 15 Jun 1999, Vladimir Kushnir wrote: > Is it only my problem or CTM src-cur deltas aren't generated since Jun 8? ftp://ftp.freebsd.org/pub/FreeBSD/CTM/cvs-cur/ has deltas upto 5419, dated Sun (?!) Jun 14, which is today. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 15:14:39 1999 Delivered-To: freebsd-current@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id 37EDC14E24 for ; Mon, 14 Jun 1999 15:14:34 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: (qmail 40888 invoked from network); 14 Jun 1999 22:14:09 -0000 Received: from shell-3.enteract.com (dscheidt@207.229.143.42) by pop3-3.enteract.com with SMTP; 14 Jun 1999 22:14:09 -0000 Received: from localhost (dscheidt@localhost) by shell-3.enteract.com (8.9.3/8.9.2) with SMTP id RAA09985; Mon, 14 Jun 1999 17:14:08 -0500 (CDT) (envelope-from dscheidt@enteract.com) X-Authentication-Warning: shell-3.enteract.com: dscheidt owned process doing -bs Date: Mon, 14 Jun 1999 17:14:08 -0500 (CDT) From: David Scheidt To: Chan Yiu Wah Cc: freebsd-current@freebsd.org Subject: Re: What happened to CTM src-cur? In-Reply-To: <199906142210.GAA12154@b1.hkstar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 15 Jun 1999, Chan Yiu Wah wrote: > > > > On Tue, 15 Jun 1999, Vladimir Kushnir wrote: > > > > > Is it only my problem or CTM src-cur deltas aren't generated since Jun 8? > ^^^^^^^ > > > > ftp://ftp.freebsd.org/pub/FreeBSD/CTM/cvs-cur/ > ^^^^^^^ > > > > has deltas upto 5419, dated Sun (?!) Jun 14, which is today. > > > > > > Are ^^^^ the same ? Er, probably not. David "Reading is hard!" Scheidt > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 15:43: 1 1999 Delivered-To: freebsd-current@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 4C1FA14E11 for ; Mon, 14 Jun 1999 15:42:58 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id SAA36478; Mon, 14 Jun 1999 18:42:35 -0400 (EDT) Date: Mon, 14 Jun 1999 18:42:35 -0400 (EDT) From: Chuck Robey To: David Scheidt Cc: Chan Yiu Wah , freebsd-current@FreeBSD.ORG Subject: Re: What happened to CTM src-cur? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 14 Jun 1999, David Scheidt wrote: > On Tue, 15 Jun 1999, Chan Yiu Wah wrote: > > > > > > > On Tue, 15 Jun 1999, Vladimir Kushnir wrote: > > > > > > > Is it only my problem or CTM src-cur deltas aren't generated since Jun 8? > > ^^^^^^^ > > > > > > ftp://ftp.freebsd.org/pub/FreeBSD/CTM/cvs-cur/ > > ^^^^^^^ > > > > > > has deltas upto 5419, dated Sun (?!) Jun 14, which is today. > > > > > > > > > > Are ^^^^ the same ? > > Er, probably not. > > David "Reading is hard!" Scheidt OK, Chan is right, fixing. > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 17:29:16 1999 Delivered-To: freebsd-current@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 00F1914D32 for ; Mon, 14 Jun 1999 17:29:14 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id UAA22149; Mon, 14 Jun 1999 20:28:54 -0400 (EDT) Message-Id: <199906150028.UAA22149@cs.rpi.edu> To: Chuck Robey Cc: David Scheidt , Chan Yiu Wah , freebsd-current@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: What happened to CTM src-cur? In-Reply-To: Message from Chuck Robey of "Mon, 14 Jun 1999 18:42:35 EDT." Date: Mon, 14 Jun 1999 20:28:54 -0400 From: "David E. Cross" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yes, that was far from my final patch :) It was intended for those with more clue, and a fresh look at the code (such as yourself ;) to help me out. I don't believe that we have handled all the problems, I believe almost any "error" condition may cause this... there are multiple points at which "error=" occurs, and it would seem to suggest that any may lead to this. I have a giant printout of this routine and I am atytempting to trace all the code paths. Could someone provide an indication as to what (paraphrasing) "vattr->va_size =-1" would parse to in english? -- David Cross The source will be with you, always. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 18:15: 9 1999 Delivered-To: freebsd-current@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 4C3601524F for ; Mon, 14 Jun 1999 18:15:01 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from lot.gsoft.com.au (lot.gsoft.com.au [203.38.152.106]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id KAA12732; Tue, 15 Jun 1999 10:44:52 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] 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: Tue, 15 Jun 1999 10:44:52 +0930 (CST) From: "Daniel O'Connor" To: cmpnerds Subject: RE: problem in audio.o?? Cc: freebsd-current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 14-Jun-99 cmpnerds wrote: > Just cvsuped. First Generic Kernel worked. Attemptes to compile > in sound (non voxware) and got the following error Can we get your kernel config file? It kind of looks like you didn't remove all the old sound stuff or something like that. If you want to use Luigi's driver you ONLY need -> controller pnp0 device pcm0 [at isa? port ? tty irq XX drq XX flags 0x0 (for ISA)] --- 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-current" in the body of the message From owner-freebsd-current Mon Jun 14 18:49:45 1999 Delivered-To: freebsd-current@freebsd.org Received: from bilby.prth.tensor.pgs.com (bilby.prth.tensor.pgs.com [157.147.232.237]) by hub.freebsd.org (Postfix) with ESMTP id E643114C47; Mon, 14 Jun 1999 18:48:46 -0700 (PDT) (envelope-from shocking@ariadne.prth.tensor.pgs.com) Received: from bandicoot.prth.tensor.pgs.com (bandicoot.prth.tensor.pgs.com [157.147.224.1]) by bilby.prth.tensor.pgs.com (8.9.3/8.8.8) with ESMTP id JAA21358; Tue, 15 Jun 1999 09:47:42 +0800 (WST) Received: from ariadne.tensor.pgs.com (ariadne [157.147.227.36]) by bandicoot.prth.tensor.pgs.com (8.9.3/8.8.8) with SMTP id JAA07246; Tue, 15 Jun 1999 09:48:41 +0800 (WST) Received: from ariadne by ariadne.tensor.pgs.com (SMI-8.6/SMI-SVR4) id JAA09202; Tue, 15 Jun 1999 09:48:40 +0800 Message-Id: <199906150148.JAA09202@ariadne.tensor.pgs.com> X-Mailer: exmh version 2.0.2 2/24/98 To: current@freebsd.org, multimedia@freebsd.org Subject: Voodoo device driver for current enclosed (2nd try!) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Jun 1999 09:48:40 +0800 From: Stephen Hocking-Senior Programmer PGS Tensor Perth Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Find herein the files that make up my so far unsuccessful attempt to writ= e a voodoo device driver. It was translated wholesale from Daryl Strauss's driver for Linux, although I've messed up something along the way. At the= moment, it will lock up the machine hard shortly after mmaping the card's= memory. I'm about to go on holidays for a week, so I thought I'd throw th= is out for you all to take a look at and hopefully find out what I've done wrong. In order to use it you will have to add to /sys/i386/conf/files.i386 the following line - pci/voodoo.c optional voodoo device-driver And then to your machine config file device voodoo0 # I hope this works.... You'll have to cut'n'paste the files into the appropriate directories (la= st time I sent a uuencoded tar file, but that hasn't appeared yet), config y= our kernel and recompile & reinstall your linux emulator module. You will als= o have to have the appropriate version of glide for your card (note that the dri= ver doesn't as yet support the voodoo3 series, although this would be trivial= to add), and a copy of the glide SDK. I've been using the little test progra= ms that come with the SDK. I apologise for the humungous size of this meesag= e, but I have nowhere I can put it up for public ftp. ------- CUT HERE --- /sys/pci/voodoo.c ---------- /* * Copyright ME * * voodoo driver * $Id: make_device_driver.sh,v 1.0 Tue Aug 18 14:09:07 EST 1998 crb Exp = $" */ #include "pci.h" #if NPCI >0 #include "opt_devfs.h" #include "voodoo.h" /* generated file.. * defines NVOODOO */ #include #include #include /* SYSINIT stuff */ #include /* cdevsw stuff */ #include #include #include /* malloc region * definitions */ #include /* DELAY() */ #include #include #include #include #include #include /* NCPI definitions */ #include /* pci variables etc. */ #include /* pci register * definitions etc. */ #include /* voodoo IOCTL * definitions */ #ifdef DEVFS #include /* DEVFS defintitions */ #endif /* DEVFS */ #ifndef _IOC_DIR #define _IOC_DIR(x) (x & IOC_DIRMASK) #endif #define VENDOR_3DFX 0x121a #define VENDOR_ALLIANCE 0x1142 #define ID_VOODOO1 1 #define ID_VOODOO2 2 #define ID_AT3D 0x643d #define VOODOO1 ((ID_VOODOO1 << 16) | VENDOR_3DFX) #define VOODOO2 ((ID_VOODOO2 << 16) | VENDOR_3DFX) #define RUSH ((ID_AT3D << 16) | VENDOR_ALLIANCE) #define PCI_VENDOR_ID_FREEBSD 0x0 #define PCI_DEVICE_ID_FREEBSD 0x2 #define PCI_COMMAND_FREEBSD 0x4 #define PCI_REVISION_ID_FREEBSD 0x8 #define PCI_BASE_ADDRESS_0_FREEBSD 0x10 #define SST1_PCI_SPECIAL1_FREEBSD 0x40 #define SST1_PCI_SPECIAL2_FREEBSD 0x44 #define SST1_PCI_SPECIAL3_FREEBSD 0x48 #define SST1_PCI_SPECIAL4_FREEBSD 0x54 #define VGA_INPUT_STATUS_1C 0x3DA #define VGA_MISC_OUTPUT_READ 0x3cc #define VGA_MISC_OUTPUT_WRITE 0x3c2 #define SC_INDEX 0x3c4 #define SC_DATA 0x3c5 /* Function prototypes (these should all be static except for voodoointr(= )) */ static d_open_t voodooopen; static d_close_t voodooclose; static d_ioctl_t voodooioctl; static d_mmap_t voodoommap; static char *voodooprobe(pcici_t tag, pcidi_t type); static void voodooattach(pcici_t tag, int unit); static u_long voodoocount; typedef struct pioData_t { short port; short size; int device; void *value; } pioData; typedef struct cardInfo_t { pcici_t tag; vm_offset_t virbase, physbase; int vendor; pcidi_t type; int addr; struct file *curFile; } cardInfo; #define MAXCARDS 16 cardInfo cards[MAXCARDS]; static int numCards=3D0; #define CDEV_MAJOR 107 static struct cdevsw voodoo_cdevsw =3D { voodooopen, voodooclose, noread, nowrite, voodooioctl, NULL, noreset, nodevtotty, nopoll, voodoommap, nostrategy, "voodoo", noparms, CDEV_MAJOR, nodump, nopsize, 0, 0, -1 }; static struct pci_device voodoo_device =3D { "voodoo", voodooprobe, voodooattach, &voodoocount, NULL }; /* The DATA_SET macro includes the pci device in the set of pci devices * that will be probed at config time. */ #ifdef COMPAT_PCI_DRIVER COMPAT_PCI_DRIVER (voodoo, voodoo_device); #else DATA_SET(pcidevice_set, voodoo_device); #endif #define UNIT(dev) minor(dev) /* assume one minor * number per unit */ /* * One of these per allocated device */ struct voodoo_softc { #ifdef DEVFS static void *devfs_token; #endif }; typedef struct voodoo_softc *sc_p; static sc_p sca[NVOODOO]; /* this function should discriminate if this device is * or is not handled by this driver, often this will be * as simple as testing the pci id of the device */ static void storeCard(pcici_t tag, pcidi_t type, char *name) { cards[numCards].tag =3D tag; cards[numCards].type =3D (type & 0xffff0000) >> 16; cards[numCards].vendor =3D type & 0xffff; pci_map_mem(tag, PCI_MAP_REG_START, & cards[numCards].virbase, &cards[n= umCards].physbase); cards[numCards].physbase &=3D ~0xF; /* cards[numCards].physbase =3D (pci_cfgread(tag, PCIR_MAPS, 4) & ~0xF= );*/ printf("%s has mem at phys 0x%lx, vir 0x%lx type 0x%x, vendor 0x%x\n", name, cards[numCards].physbase, cards[numCards].virbase, = cards[numCards].type, cards[numCards].vendor); /* Read configuration here */ numCards++; } static char * voodooprobe(pcici_t tag, pcidi_t type) { char *board_type =3D (char *)0; switch (type) { case VOODOO1: board_type =3D "3DFX Voodoo 1"; storeCard(tag, type, board_type); break; case VOODOO2: board_type =3D "3DFX Voodoo 2"; storeCard(tag, type, board_type); break; case RUSH: board_type =3D "AT3D Rush"; storeCard(tag, type, board_type); break; }; return board_type; } /* * Called if the probe succeeded. */ static void voodooattach(pcici_t tag, int unit) { sc_p scp =3D sca[unit]; /* Allocate storage for this instance . */ scp =3D malloc(sizeof(*scp), M_DEVBUF, M_NOWAIT); if (scp =3D=3D NULL) { uprintf("voodoo%d failed to allocate driver storage\n", unit); return; } bzero(scp, sizeof(*scp)); sca[unit] =3D scp; /* Store whatever seems wise. */ #if DEVFS scp->devfs_token =3D devfs_add_devswf(&voodoo_cdevsw, unit, DV_CHR, UID_ROOT, GID_KMEM, 0600, "3dfx%d", unit); #endif /* Set up video mem addresses and port i/o addresses. */ } /* * Macro to check that the unit number is valid * Often this isn't needed as once the open() is performed, * the unit number is pretty much safe.. The exception would be if we * implemented devices that could "go away". in which case all these rout= ines * would be wise to check the number, DIAGNOSTIC or not. */ #define CHECKUNIT(RETVAL) \ do { /* the do-while is a safe way to do this grouping */ \ if (unit > NVOODOO) { \ uprintf(__FUNCTION__ ":bad unit %d \n", unit); \ return (RETVAL); \ } \ if (scp =3D=3D NULL) { \ uprintf( __FUNCTION__ ": unit %d not attached\n", unit); \ return (RETVAL); \ } \ } while (0) #ifdef DIAGNOSTIC #define CHECKUNIT_DIAG(RETVAL) CHECKUNIT(RETVAL) #else /* DIAGNOSTIC */ #define CHECKUNIT_DIAG(RETVAL) #endif /* DIAGNOSTIC */ static int doQueryBoards(void) { /* printf("Called doQueryBoards %d\n", numCards); */ return numCards; } static int doQueryFetch(pioData *desc) { char retchar; short retword; int retlong; /* printf("Called doQueryFetch\n"); */ if (desc->device<0 || desc->device>=3DnumCards) return EINVAL; switch (desc->port) { case PCI_VENDOR_ID_FREEBSD: if (desc->size!=3D2) return EINVAL; copyout(&cards[desc->device].vendor, desc->value, desc->size); return 0; case PCI_DEVICE_ID_FREEBSD: if (desc->size!=3D2) return EINVAL; copyout(&cards[desc->device].type, desc->value, desc->size); return 0; case PCI_BASE_ADDRESS_0_FREEBSD: if (desc->size!=3D4) return EINVAL; copyout(&cards[desc->device].addr, desc->value, desc->size); return 0; case SST1_PCI_SPECIAL1_FREEBSD: if (desc->size!=3D4) return EINVAL; break; case PCI_REVISION_ID_FREEBSD: if (desc->size!=3D1) return EINVAL; break; case SST1_PCI_SPECIAL4_FREEBSD: if (desc->size!=3D4) return EINVAL; break; default: return EINVAL; } switch (desc->size) { case 1: retchar =3D pci_cfgread(cards[desc->device].tag, desc->port, 1); copyout(&retchar, desc->value, 1); break; case 2: retword =3D pci_cfgread(cards[desc->device].tag, desc->port, 2); copyout(&retword, desc->value, 2); break; case 4: retlong =3D pci_cfgread(cards[desc->device].tag, desc->port, 4); copyout(&retlong, desc->value, 4); break; default: return EINVAL; } return 0; } static int doQueryUpdate(pioData *desc) { int retval; int preval; int mask; char retchar; short retword; int retlong; printf("Called doQueryUpdate\n"); if (desc->device<0 || desc->device>=3DnumCards) return EINVAL; switch (desc->port) { case PCI_COMMAND_FREEBSD: if (desc->size!=3D2) return EINVAL; break; case SST1_PCI_SPECIAL1_FREEBSD: if (desc->size!=3D4) return EINVAL; break; case SST1_PCI_SPECIAL2_FREEBSD: if (desc->size!=3D4) return EINVAL; break; case SST1_PCI_SPECIAL3_FREEBSD: if (desc->size!=3D4) return EINVAL; break; case SST1_PCI_SPECIAL4_FREEBSD: if (desc->size!=3D4) return EINVAL; break; default: return EINVAL; } retval =3D pci_cfgread(cards[desc->device].tag, desc->port & ~0x3, 4); switch (desc->size) { case 1: copyin(desc->value, &retchar, 1); preval=3Dretchar<<(8*(desc->port&0x3)); mask=3D0xFF<<(8*(desc->port&0x3)); break; case 2: copyin(desc->value, &retword, 2); preval=3Dretword<<(8*(desc->port&0x3)); mask=3D0xFFFF<<(8*(desc->port&0x3)); break; case 4: copyin(desc->value, &retlong, 4); preval=3Dretlong; mask=3D~0; break; default: return EINVAL; } retval =3D (retval & ~mask) | preval; printf("Updating port %d with 0x%x\n", desc->port, retval); pci_cfgwrite(cards[desc->device].tag, desc->port, retval, 4); return 0; } static int doQuery(unsigned int cmd, pioData *desc) { /* printf("Called doQuery\n"); */ if (_IOC_NR(cmd)=3D=3D2) return doQueryBoards(); if (_IOC_NR(cmd)=3D=3D3) return doQueryFetch(desc); if (_IOC_NR(cmd)=3D=3D4) return doQueryUpdate(desc); return EINVAL; } static int doPIORead(pioData *desc) { char retchar; short retword; int retlong; printf("called doPIORead\n"); switch (desc->port) { case VGA_INPUT_STATUS_1C: break; case SC_INDEX: break; case SC_DATA: break; case VGA_MISC_OUTPUT_READ: break; default: return EPERM; } if (desc->size!=3D1) { return EINVAL; } switch (desc->size) { case 1: retchar=3Dinb(desc->port); copyout(&retchar, desc->value, sizeof(char)); break; case 2: retword=3Dinw(desc->port); copyout(&retword, desc->value, sizeof(short)); break; case 4: retlong=3Dinl(desc->port); copyout(&retlong, desc->value, sizeof(int)); break; default: return EINVAL; } return 0; } static int doPIOWrite(pioData *desc) { char retchar; short retword; int retlong; printf("Called doPIOWrite\n"); switch (desc->port) { case SC_INDEX: break; case SC_DATA: break; case VGA_MISC_OUTPUT_WRITE: break; default: return EPERM; } if (desc->size!=3D1) { return EINVAL; } switch (desc->size) { case 1: copyin(desc->value, &retchar, sizeof(char)); outb(desc->port, retchar); break; case 2: copyin(desc->value, &retword, sizeof(short)); outw(desc->port, retword); break; case 4: copyin(desc->value, &retlong, sizeof(int)); outl(desc->port, retlong); break; default: return EINVAL; } return 0; } static int doPIO(unsigned int cmd, pioData *desc) { printf("Called doPIO\n"); if (_IOC_DIR(cmd)=3D=3DIOCV_OUT) return doPIORead(desc); if (_IOC_DIR(cmd)=3D=3DIOCV_IN) return doPIOWrite(desc); return EINVAL; } static int = voodooioctl(dev_t dev, u_long cmd, caddr_t data, int flag, struct proc * = p) { int unit =3D UNIT(dev); sc_p scp =3D sca[unit]; pioData *desc =3D data; CHECKUNIT_DIAG(ENXIO); /* printf("Hey, somebody ioctl'd me with %x at %x!!\n", cmd, data); if (data !=3D NULL) printf("desc->device %d, desc->port %d, desc->s= ize %d desc->value 0x%x\n", desc->device, desc->port, desc->size, desc->value); */ switch (_IOC_TYPE(cmd)) { case '3': return doQuery(cmd, desc); break; case 0: return doPIO(cmd, desc); break; default: printf("And I didn't like it!\n"); return ENXIO; } return (0); } /* * You also need read, write, open, close routines. * This should get you started */ static int voodooopen(dev_t dev, int oflags, int devtype, struct proc * p) { int unit =3D UNIT(dev); sc_p scp =3D sca[unit]; printf("Voodoo opened!\n"); CHECKUNIT(ENXIO); /* Do processing */ return (0); } static int voodooclose(dev_t dev, int fflag, int devtype, struct proc * p) { int unit =3D UNIT(dev); sc_p scp =3D sca[unit]; CHECKUNIT_DIAG(ENXIO); /* Do processing */ return (0); } static int voodoommap(dev_t dev, vm_offset_t offset, int nprot) { int unit =3D UNIT(dev), i; sc_p scp =3D sca[unit]; CHECKUNIT_DIAG(-1); printf("Someone trying to mmap me on unit %d..\n", unit); /* Do processing */ if (offset >=3D 0x1000000) = return (-1); return (i386_btop(cards[unit].physbase + offset)); } /* * Now for some driver initialization. There are basically 2 options * here you can either use the drvinit function for initialization that * needs to occur before any probing is done, or keep state in a global * you can use in the probe routine to see if probe is being called for * the fist time, and do your initalization there. */ static void voodoo_drvinit(void *unused) { dev_t dev; dev =3D makedev(CDEV_MAJOR, 0); cdevsw_add(&voodoo_cdevsw); } SYSINIT(voodoodev, SI_SUB_DRIVERS, SI_ORDER_MIDDLE + CDEV_MAJOR, voodoo_drvinit, NULL) #endif /* NPCI */ ------------ CUT HERE -------- /sys/sys/voodooio.h ------------- /* * Definitions needed to access the voodoo device (ioctls etc) * see mtio.h , ioctl.h as examples */ #ifndef SYS_DHIO_H #define SYS_DHIO_H #ifndef KERNEL #include #endif /* #include */ /* * define an ioctl here */ #define DHIOCRESET _IO('D', 0) /* reset the voodoo device */ #define GETVOODOO 0x3302 #define SETVOODOO 0x3303 #define MOREVOODOO 0x3300 #define _IOC_NRBITS 8 #define _IOC_TYPEBITS 8 #define _IOC_SIZEBITS 14 #define _IOC_DIRBITS 2 #define _IOC_NRMASK ((1 << _IOC_NRBITS)-1) #define _IOC_TYPEMASK ((1 << _IOC_TYPEBITS)-1) #define _IOC_SIZEMASK ((1 << _IOC_SIZEBITS)-1) #define _IOC_DIRMASK ((1 << _IOC_DIRBITS)-1) #define _IOC_NRSHIFT 0 #define _IOC_TYPESHIFT (_IOC_NRSHIFT+_IOC_NRBITS) #define _IOC_SIZESHIFT (_IOC_TYPESHIFT+_IOC_TYPEBITS) #define _IOC_DIRSHIFT (_IOC_SIZESHIFT+_IOC_SIZEBITS) /* * Direction bits. */ #define _IOC_NONE 0U #define _IOC_WRITE 1U #define _IOC_READ 2U #define _IOCV(dir,type,nr,size) \ (((dir) << _IOC_DIRSHIFT) | \ ((type) << _IOC_TYPESHIFT) | \ ((nr) << _IOC_NRSHIFT) | \ ((size) << _IOC_SIZESHIFT)) /* used to create numbers */ #define _IOV(type,nr) _IOCV(_IOC_NONE,(type),(nr),0) #define _IORV(type,nr,size) _IOCV(_IOC_READ,(type),(nr),sizeof(size)) #define _IOWV(type,nr,size) _IOCV(_IOC_WRITE,(type),(nr),sizeof(size)) #define _IOWRV(type,nr,size) _IOCV(_IOC_READ|_IOC_WRITE,(type),(nr),sizeo= f(size)) /* used to decode ioctl numbers.. */ #define _IOC_DIR(nr) (((nr) >> _IOC_DIRSHIFT) & _IOC_DIRMASK) #define _IOC_TYPE(nr) (((nr) >> _IOC_TYPESHIFT) & _IOC_TYPEMASK) #define _IOC_NR(nr) (((nr) >> _IOC_NRSHIFT) & _IOC_NRMASK) #define _IOC_SIZE(nr) (((nr) >> _IOC_SIZESHIFT) & _IOC_SIZEMASK) /* ...and for the drivers/sound files... */ #define IOCV_IN (_IOC_WRITE << _IOC_DIRSHIFT) #define IOCV_OUT (_IOC_READ << _IOC_DIRSHIFT) #define IOCV_INOUT ((_IOC_WRITE|_IOC_READ) << _IOC_DIRSHIFT) #define IOCSIZE_MASK (_IOC_SIZEMASK << _IOC_SIZESHIFT) #define IOCSIZE_SHIFT (_IOC_SIZESHIFT) #endif ----------------- CUT HERE ---------- /sys/i386/linux/linux_ioctl.c -----= --- /* * Copyright (c) 1994-1995 S=F8ren Schmidt * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer * in this position and unchanged. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the= * documentation and/or other materials provided with the distribution= =2E * 3. The name of the author may not be used to endorse or promote produc= ts * derived from this software withough specific prior written permissi= on * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANT= IES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED= =2E * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, B= UT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF U= SE, * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE = OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * * $Id: linux_ioctl.c,v 1.33 1999/05/09 16:04:04 peter Exp $ */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #define ISSIGVALID(sig) ((sig) > 0 && (sig) < NSIG) struct linux_termio { unsigned short c_iflag; unsigned short c_oflag; unsigned short c_cflag; unsigned short c_lflag; unsigned char c_line; unsigned char c_cc[LINUX_NCC]; }; struct linux_termios { unsigned long c_iflag; unsigned long c_oflag; unsigned long c_cflag; unsigned long c_lflag; unsigned char c_line; unsigned char c_cc[LINUX_NCCS]; }; struct linux_winsize { unsigned short ws_row, ws_col; unsigned short ws_xpixel, ws_ypixel; }; static struct speedtab sptab[] =3D { { 0, 0 }, { 50, 1 }, { 75, 2 }, { 110, 3 }, { 134, 4 }, { 135, 4 }, { 150, 5 }, { 200, 6 }, { 300, 7 }, { 600, 8 }, { 1200, 9 }, { 1800, 10 }, { 2400, 11 }, { 4800, 12 }, { 9600, 13 }, { 19200, 14 }, { 38400, 15 }, = { 57600, 4097 }, { 115200, 4098 }, {-1, -1 } }; struct linux_serial_struct { int type; int line; int port; int irq; int flags; int xmit_fifo_size; int custom_divisor; int baud_base; unsigned short close_delay; char reserved_char[2]; int hub6; unsigned short closing_wait; unsigned short closing_wait2; int reserved[4]; }; static int linux_to_bsd_speed(int code, struct speedtab *table) { for ( ; table->sp_code !=3D -1; table++) if (table->sp_code =3D=3D code) return (table->sp_speed); return -1; } static int bsd_to_linux_speed(int speed, struct speedtab *table) { for ( ; table->sp_speed !=3D -1; table++) if (table->sp_speed =3D=3D speed) return (table->sp_code); return -1; } static void bsd_to_linux_termios(struct termios *bsd_termios, = struct linux_termios *linux_termios) { int i; #ifdef DEBUG printf("LINUX: BSD termios structure (input):\n"); printf("i=3D%08x o=3D%08x c=3D%08x l=3D%08x ispeed=3D%d ospeed=3D%d\n= ", bsd_termios->c_iflag, bsd_termios->c_oflag, bsd_termios->c_cflag, bsd_termios->c_lflag, bsd_termios->c_ispeed, bsd_termios->c_ospeed); printf("c_cc "); for (i=3D0; ic_cc[i]); printf("\n"); #endif linux_termios->c_iflag =3D 0; if (bsd_termios->c_iflag & IGNBRK) linux_termios->c_iflag |=3D LINUX_IGNBRK; if (bsd_termios->c_iflag & BRKINT) linux_termios->c_iflag |=3D LINUX_BRKINT; if (bsd_termios->c_iflag & IGNPAR) linux_termios->c_iflag |=3D LINUX_IGNPAR; if (bsd_termios->c_iflag & PARMRK) linux_termios->c_iflag |=3D LINUX_PARMRK; if (bsd_termios->c_iflag & INPCK) linux_termios->c_iflag |=3D LINUX_INPCK; if (bsd_termios->c_iflag & ISTRIP) linux_termios->c_iflag |=3D LINUX_ISTRIP; if (bsd_termios->c_iflag & INLCR) linux_termios->c_iflag |=3D LINUX_INLCR; if (bsd_termios->c_iflag & IGNCR) linux_termios->c_iflag |=3D LINUX_IGNCR; if (bsd_termios->c_iflag & ICRNL) linux_termios->c_iflag |=3D LINUX_ICRNL; if (bsd_termios->c_iflag & IXON) linux_termios->c_iflag |=3D LINUX_IXANY; if (bsd_termios->c_iflag & IXON) linux_termios->c_iflag |=3D LINUX_IXON; if (bsd_termios->c_iflag & IXOFF) linux_termios->c_iflag |=3D LINUX_IXOFF; if (bsd_termios->c_iflag & IMAXBEL) linux_termios->c_iflag |=3D LINUX_IMAXBEL; linux_termios->c_oflag =3D 0; if (bsd_termios->c_oflag & OPOST) linux_termios->c_oflag |=3D LINUX_OPOST; if (bsd_termios->c_oflag & ONLCR) linux_termios->c_oflag |=3D LINUX_ONLCR; if (bsd_termios->c_oflag & OXTABS) linux_termios->c_oflag |=3D LINUX_XTABS; linux_termios->c_cflag =3D bsd_to_linux_speed(bsd_termios->c_ispeed, sptab); linux_termios->c_cflag |=3D (bsd_termios->c_cflag & CSIZE) >> 4; if (bsd_termios->c_cflag & CSTOPB) linux_termios->c_cflag |=3D LINUX_CSTOPB; if (bsd_termios->c_cflag & CREAD) linux_termios->c_cflag |=3D LINUX_CREAD; if (bsd_termios->c_cflag & PARENB) linux_termios->c_cflag |=3D LINUX_PARENB; if (bsd_termios->c_cflag & PARODD) linux_termios->c_cflag |=3D LINUX_PARODD; if (bsd_termios->c_cflag & HUPCL) linux_termios->c_cflag |=3D LINUX_HUPCL; if (bsd_termios->c_cflag & CLOCAL) linux_termios->c_cflag |=3D LINUX_CLOCAL; if (bsd_termios->c_cflag & CRTSCTS) linux_termios->c_cflag |=3D LINUX_CRTSCTS; linux_termios->c_lflag =3D 0; if (bsd_termios->c_lflag & ISIG) linux_termios->c_lflag |=3D LINUX_ISIG; if (bsd_termios->c_lflag & ICANON) linux_termios->c_lflag |=3D LINUX_ICANON; if (bsd_termios->c_lflag & ECHO) linux_termios->c_lflag |=3D LINUX_ECHO; if (bsd_termios->c_lflag & ECHOE) linux_termios->c_lflag |=3D LINUX_ECHOE; if (bsd_termios->c_lflag & ECHOK) linux_termios->c_lflag |=3D LINUX_ECHOK; if (bsd_termios->c_lflag & ECHONL) linux_termios->c_lflag |=3D LINUX_ECHONL; if (bsd_termios->c_lflag & NOFLSH) linux_termios->c_lflag |=3D LINUX_NOFLSH; if (bsd_termios->c_lflag & TOSTOP) linux_termios->c_lflag |=3D LINUX_TOSTOP; if (bsd_termios->c_lflag & ECHOCTL) linux_termios->c_lflag |=3D LINUX_ECHOCTL; if (bsd_termios->c_lflag & ECHOPRT) linux_termios->c_lflag |=3D LINUX_ECHOPRT; if (bsd_termios->c_lflag & ECHOKE) linux_termios->c_lflag |=3D LINUX_ECHOKE; if (bsd_termios->c_lflag & FLUSHO) linux_termios->c_lflag |=3D LINUX_FLUSHO; if (bsd_termios->c_lflag & PENDIN) linux_termios->c_lflag |=3D LINUX_PENDIN; if (bsd_termios->c_lflag & IEXTEN) linux_termios->c_lflag |=3D LINUX_IEXTEN; for (i=3D0; ic_cc[i] =3D LINUX_POSIX_VDISABLE; linux_termios->c_cc[LINUX_VINTR] =3D bsd_termios->c_cc[VINTR]; linux_termios->c_cc[LINUX_VQUIT] =3D bsd_termios->c_cc[VQUIT]; linux_termios->c_cc[LINUX_VERASE] =3D bsd_termios->c_cc[VERASE]; linux_termios->c_cc[LINUX_VKILL] =3D bsd_termios->c_cc[VKILL]; linux_termios->c_cc[LINUX_VEOF] =3D bsd_termios->c_cc[VEOF]; linux_termios->c_cc[LINUX_VEOL] =3D bsd_termios->c_cc[VEOL]; linux_termios->c_cc[LINUX_VMIN] =3D bsd_termios->c_cc[VMIN]; linux_termios->c_cc[LINUX_VTIME] =3D bsd_termios->c_cc[VTIME]; linux_termios->c_cc[LINUX_VEOL2] =3D bsd_termios->c_cc[VEOL2]; linux_termios->c_cc[LINUX_VSWTC] =3D _POSIX_VDISABLE; linux_termios->c_cc[LINUX_VSUSP] =3D bsd_termios->c_cc[VSUSP]; linux_termios->c_cc[LINUX_VSTART] =3D bsd_termios->c_cc[VSTART]; linux_termios->c_cc[LINUX_VSTOP] =3D bsd_termios->c_cc[VSTOP]; linux_termios->c_cc[LINUX_VREPRINT] =3D bsd_termios->c_cc[VREPRINT]; linux_termios->c_cc[LINUX_VDISCARD] =3D bsd_termios->c_cc[VDISCARD]; linux_termios->c_cc[LINUX_VWERASE] =3D bsd_termios->c_cc[VWERASE]; linux_termios->c_cc[LINUX_VLNEXT] =3D bsd_termios->c_cc[VLNEXT]; for (i=3D0; ic_cc[i] =3D=3D _POSIX_VDISABLE) linux_termios->c_cc[i] =3D LINUX_POSIX_VDISABLE; } linux_termios->c_line =3D 0; #ifdef DEBUG printf("LINUX: LINUX termios structure (output):\n"); printf("i=3D%08lx o=3D%08lx c=3D%08lx l=3D%08lx line=3D%d\n", linux_termios->c_iflag, linux_termios->c_oflag, linux_termios->c_cflag, linux_termios->c_lflag, linux_termios->c_line); printf("c_cc "); for (i=3D0; ic_cc[i]); printf("\n"); #endif } static void linux_to_bsd_termios(struct linux_termios *linux_termios, struct termios *bsd_termios) { int i; #ifdef DEBUG printf("LINUX: LINUX termios structure (input):\n"); printf("i=3D%08lx o=3D%08lx c=3D%08lx l=3D%08lx line=3D%d\n", linux_termios->c_iflag, linux_termios->c_oflag, linux_termios->c_cflag, linux_termios->c_lflag, linux_termios->c_line); printf("c_cc "); for (i=3D0; ic_cc[i]); printf("\n"); #endif bsd_termios->c_iflag =3D 0; if (linux_termios->c_iflag & LINUX_IGNBRK) bsd_termios->c_iflag |=3D IGNBRK; if (linux_termios->c_iflag & LINUX_BRKINT) bsd_termios->c_iflag |=3D BRKINT; if (linux_termios->c_iflag & LINUX_IGNPAR) bsd_termios->c_iflag |=3D IGNPAR; if (linux_termios->c_iflag & LINUX_PARMRK) bsd_termios->c_iflag |=3D PARMRK; if (linux_termios->c_iflag & LINUX_INPCK) bsd_termios->c_iflag |=3D INPCK; if (linux_termios->c_iflag & LINUX_ISTRIP) bsd_termios->c_iflag |=3D ISTRIP; if (linux_termios->c_iflag & LINUX_INLCR) bsd_termios->c_iflag |=3D INLCR; if (linux_termios->c_iflag & LINUX_IGNCR) bsd_termios->c_iflag |=3D IGNCR; if (linux_termios->c_iflag & LINUX_ICRNL) bsd_termios->c_iflag |=3D ICRNL; if (linux_termios->c_iflag & LINUX_IXON) bsd_termios->c_iflag |=3D IXANY; if (linux_termios->c_iflag & LINUX_IXON) bsd_termios->c_iflag |=3D IXON; if (linux_termios->c_iflag & LINUX_IXOFF) bsd_termios->c_iflag |=3D IXOFF; if (linux_termios->c_iflag & LINUX_IMAXBEL) bsd_termios->c_iflag |=3D IMAXBEL; bsd_termios->c_oflag =3D 0; if (linux_termios->c_oflag & LINUX_OPOST) bsd_termios->c_oflag |=3D OPOST; if (linux_termios->c_oflag & LINUX_ONLCR) bsd_termios->c_oflag |=3D ONLCR; if (linux_termios->c_oflag & LINUX_XTABS) bsd_termios->c_oflag |=3D OXTABS; bsd_termios->c_cflag =3D (linux_termios->c_cflag & LINUX_CSIZE) << 4;= if (linux_termios->c_cflag & LINUX_CSTOPB) bsd_termios->c_cflag |=3D CSTOPB; if (linux_termios->c_cflag & LINUX_PARENB) bsd_termios->c_cflag |=3D PARENB; if (linux_termios->c_cflag & LINUX_PARODD) bsd_termios->c_cflag |=3D PARODD; if (linux_termios->c_cflag & LINUX_HUPCL) bsd_termios->c_cflag |=3D HUPCL; if (linux_termios->c_cflag & LINUX_CLOCAL) bsd_termios->c_cflag |=3D CLOCAL; if (linux_termios->c_cflag & LINUX_CRTSCTS) bsd_termios->c_cflag |=3D CRTSCTS; bsd_termios->c_lflag =3D 0; if (linux_termios->c_lflag & LINUX_ISIG) bsd_termios->c_lflag |=3D ISIG; if (linux_termios->c_lflag & LINUX_ICANON) bsd_termios->c_lflag |=3D ICANON; if (linux_termios->c_lflag & LINUX_ECHO) bsd_termios->c_lflag |=3D ECHO; if (linux_termios->c_lflag & LINUX_ECHOE) bsd_termios->c_lflag |=3D ECHOE; if (linux_termios->c_lflag & LINUX_ECHOK) bsd_termios->c_lflag |=3D ECHOK; if (linux_termios->c_lflag & LINUX_ECHONL) bsd_termios->c_lflag |=3D ECHONL; if (linux_termios->c_lflag & LINUX_NOFLSH) bsd_termios->c_lflag |=3D NOFLSH; if (linux_termios->c_lflag & LINUX_TOSTOP) bsd_termios->c_lflag |=3D TOSTOP; if (linux_termios->c_lflag & LINUX_ECHOCTL) bsd_termios->c_lflag |=3D ECHOCTL; if (linux_termios->c_lflag & LINUX_ECHOPRT) bsd_termios->c_lflag |=3D ECHOPRT; if (linux_termios->c_lflag & LINUX_ECHOKE) bsd_termios->c_lflag |=3D ECHOKE; if (linux_termios->c_lflag & LINUX_FLUSHO) bsd_termios->c_lflag |=3D FLUSHO; if (linux_termios->c_lflag & LINUX_PENDIN) bsd_termios->c_lflag |=3D PENDIN; if (linux_termios->c_lflag & IEXTEN) bsd_termios->c_lflag |=3D IEXTEN; for (i=3D0; ic_cc[i] =3D _POSIX_VDISABLE; bsd_termios->c_cc[VINTR] =3D linux_termios->c_cc[LINUX_VINTR]; bsd_termios->c_cc[VQUIT] =3D linux_termios->c_cc[LINUX_VQUIT]; bsd_termios->c_cc[VERASE] =3D linux_termios->c_cc[LINUX_VERASE]; bsd_termios->c_cc[VKILL] =3D linux_termios->c_cc[LINUX_VKILL]; bsd_termios->c_cc[VEOF] =3D linux_termios->c_cc[LINUX_VEOF]; bsd_termios->c_cc[VEOL] =3D linux_termios->c_cc[LINUX_VEOL]; bsd_termios->c_cc[VMIN] =3D linux_termios->c_cc[LINUX_VMIN]; bsd_termios->c_cc[VTIME] =3D linux_termios->c_cc[LINUX_VTIME]; bsd_termios->c_cc[VEOL2] =3D linux_termios->c_cc[LINUX_VEOL2]; bsd_termios->c_cc[VSUSP] =3D linux_termios->c_cc[LINUX_VSUSP]; bsd_termios->c_cc[VSTART] =3D linux_termios->c_cc[LINUX_VSTART]; bsd_termios->c_cc[VSTOP] =3D linux_termios->c_cc[LINUX_VSTOP]; bsd_termios->c_cc[VREPRINT] =3D linux_termios->c_cc[LINUX_VREPRINT]; bsd_termios->c_cc[VDISCARD] =3D linux_termios->c_cc[LINUX_VDISCARD]; bsd_termios->c_cc[VWERASE] =3D linux_termios->c_cc[LINUX_VWERASE]; bsd_termios->c_cc[VLNEXT] =3D linux_termios->c_cc[LINUX_VLNEXT]; for (i=3D0; ic_cc[i] =3D=3D LINUX_POSIX_VDISABLE) bsd_termios->c_cc[i] =3D _POSIX_VDISABLE; } bsd_termios->c_ispeed =3D bsd_termios->c_ospeed =3D linux_to_bsd_speed(linux_termios->c_cflag & LINUX_CBAUD, sptab); #ifdef DEBUG printf("LINUX: BSD termios structure (output):\n"); printf("i=3D%08x o=3D%08x c=3D%08x l=3D%08x ispeed=3D%d ospeed=3D%d\n", bsd_termios->c_iflag, bsd_termios->c_oflag, bsd_termios->c_cflag, bsd_termios->c_lflag, bsd_termios->c_ispeed, bsd_termios->c_ospeed); printf("c_cc "); for (i=3D0; ic_cc[i]); printf("\n"); #endif } static void bsd_to_linux_termio(struct termios *bsd_termios, = struct linux_termio *linux_termio) { struct linux_termios tmios; bsd_to_linux_termios(bsd_termios, &tmios); linux_termio->c_iflag =3D tmios.c_iflag; linux_termio->c_oflag =3D tmios.c_oflag; linux_termio->c_cflag =3D tmios.c_cflag; linux_termio->c_lflag =3D tmios.c_lflag; linux_termio->c_line =3D tmios.c_line; memcpy(linux_termio->c_cc, tmios.c_cc, LINUX_NCC); } static void linux_to_bsd_termio(struct linux_termio *linux_termio, struct termios *bsd_termios) { struct linux_termios tmios; int i; tmios.c_iflag =3D linux_termio->c_iflag; tmios.c_oflag =3D linux_termio->c_oflag; tmios.c_cflag =3D linux_termio->c_cflag; tmios.c_lflag =3D linux_termio->c_lflag; for (i=3D0; ic_cc, LINUX_NCC); linux_to_bsd_termios(&tmios, bsd_termios); } static void linux_tiocgserial(struct file *fp, struct linux_serial_struct *lss) { if (!fp || !lss) return; lss->type =3D LINUX_PORT_16550A; lss->flags =3D 0; lss->close_delay =3D 0; } static void linux_tiocsserial(struct file *fp, struct linux_serial_struct *lss) { if (!fp || !lss) return; } struct linux_cdrom_msf { u_char cdmsf_min0; u_char cdmsf_sec0; u_char cdmsf_frame0; u_char cdmsf_min1; u_char cdmsf_sec1; u_char cdmsf_frame1; }; struct linux_cdrom_tochdr { u_char cdth_trk0; u_char cdth_trk1; }; union linux_cdrom_addr { struct { u_char minute; u_char second; u_char frame; } msf; int lba; }; struct linux_cdrom_tocentry { u_char cdte_track; = u_char cdte_adr:4; u_char cdte_ctrl:4; u_char cdte_format; = union linux_cdrom_addr cdte_addr; u_char cdte_datamode; = }; #if 0 static void linux_to_bsd_msf_lba(u_char address_format, union linux_cdrom_addr *lp, union msf_lba *bp) { if (address_format =3D=3D CD_LBA_FORMAT) bp->lba =3D lp->lba; else { bp->msf.minute =3D lp->msf.minute; bp->msf.second =3D lp->msf.second; bp->msf.frame =3D lp->msf.frame; } } #endif static void bsd_to_linux_msf_lba(u_char address_format, union msf_lba *bp, union linux_cdrom_addr *lp) { if (address_format =3D=3D CD_LBA_FORMAT) lp->lba =3D bp->lba; else { lp->msf.minute =3D bp->msf.minute; lp->msf.second =3D bp->msf.second; lp->msf.frame =3D bp->msf.frame; } } static unsigned dirbits[4] =3D { IOC_VOID, IOC_OUT, IOC_IN, IOC_INOUT }; #define SETDIR(c) (((c) & ~IOC_DIRMASK) | dirbits[args->cmd >> 30]) int linux_ioctl(struct proc *p, struct linux_ioctl_args *args) { struct termios bsd_termios; struct linux_termios linux_termios; struct linux_termio linux_termio; struct filedesc *fdp =3D p->p_fd; struct file *fp; int (*func)(struct file *fp, u_long com, caddr_t data, struct proc *p= ); int bsd_line, linux_line; int error; #ifdef DEBUG printf("Linux-emul(%ld): ioctl(%d, %04lx, *)\n", = (long)p->p_pid, args->fd, args->cmd); #endif if ((unsigned)args->fd >=3D fdp->fd_nfiles = || (fp =3D fdp->fd_ofiles[args->fd]) =3D=3D 0) return EBADF; if (!fp || (fp->f_flag & (FREAD | FWRITE)) =3D=3D 0) { return EBADF; } func =3D fp->f_ops->fo_ioctl; switch (args->cmd & 0xffff) { case LINUX_TCGETA: if ((error =3D (*func)(fp, TIOCGETA, (caddr_t)&bsd_termios, p)) !=3D 0) return error; bsd_to_linux_termio(&bsd_termios, &linux_termio); return copyout((caddr_t)&linux_termio, (caddr_t)args->arg, sizeof(linux_termio)); case LINUX_TCSETA: linux_to_bsd_termio((struct linux_termio *)args->arg, &bsd_termios); return (*func)(fp, TIOCSETA, (caddr_t)&bsd_termios, p); case LINUX_TCSETAW: linux_to_bsd_termio((struct linux_termio *)args->arg, &bsd_termios); return (*func)(fp, TIOCSETAW, (caddr_t)&bsd_termios, p); case LINUX_TCSETAF: linux_to_bsd_termio((struct linux_termio *)args->arg, &bsd_termios); return (*func)(fp, TIOCSETAF, (caddr_t)&bsd_termios, p); case LINUX_TCGETS: if ((error =3D (*func)(fp, TIOCGETA, (caddr_t)&bsd_termios, p)) !=3D 0) return error; bsd_to_linux_termios(&bsd_termios, &linux_termios); return copyout((caddr_t)&linux_termios, (caddr_t)args->arg, sizeof(linux_termios)); case LINUX_TCSETS: linux_to_bsd_termios((struct linux_termios *)args->arg, &bsd_termios); return (*func)(fp, TIOCSETA, (caddr_t)&bsd_termios, p); case LINUX_TCSETSW: linux_to_bsd_termios((struct linux_termios *)args->arg, &bsd_termios); return (*func)(fp, TIOCSETAW, (caddr_t)&bsd_termios, p); case LINUX_TCSETSF: linux_to_bsd_termios((struct linux_termios *)args->arg, &bsd_termios); return (*func)(fp, TIOCSETAF, (caddr_t)&bsd_termios, p); = case LINUX_TIOCGPGRP: args->cmd =3D TIOCGPGRP; return ioctl(p, (struct ioctl_args *)args); case LINUX_TIOCSPGRP: args->cmd =3D TIOCSPGRP; return ioctl(p, (struct ioctl_args *)args); case LINUX_TIOCGWINSZ: args->cmd =3D TIOCGWINSZ; return ioctl(p, (struct ioctl_args *)args); case LINUX_TIOCSWINSZ: args->cmd =3D TIOCSWINSZ; return ioctl(p, (struct ioctl_args *)args); case LINUX_FIONREAD: args->cmd =3D FIONREAD; return ioctl(p, (struct ioctl_args *)args); case LINUX_FIONBIO: args->cmd =3D FIONBIO; return ioctl(p, (struct ioctl_args *)args); case LINUX_FIOASYNC: args->cmd =3D FIOASYNC; return ioctl(p, (struct ioctl_args *)args); case LINUX_FIONCLEX: args->cmd =3D FIONCLEX; return ioctl(p, (struct ioctl_args *)args); case LINUX_FIOCLEX: args->cmd =3D FIOCLEX; return ioctl(p, (struct ioctl_args *)args); case LINUX_TIOCEXCL: args->cmd =3D TIOCEXCL; return ioctl(p, (struct ioctl_args *)args); case LINUX_TIOCNXCL: args->cmd =3D TIOCNXCL; return ioctl(p, (struct ioctl_args *)args); case LINUX_TIOCCONS: args->cmd =3D TIOCCONS; return ioctl(p, (struct ioctl_args *)args); case LINUX_TIOCNOTTY: args->cmd =3D TIOCNOTTY; return ioctl(p, (struct ioctl_args *)args); case LINUX_SIOCGIFCONF: args->cmd =3D OSIOCGIFCONF; return ioctl(p, (struct ioctl_args *)args); case LINUX_SIOCGIFFLAGS: args->cmd =3D SIOCGIFFLAGS; return ioctl(p, (struct ioctl_args *)args); case LINUX_SIOCGIFADDR: args->cmd =3D OSIOCGIFADDR; return ioctl(p, (struct ioctl_args *)args); case LINUX_SIOCGIFDSTADDR: args->cmd =3D OSIOCGIFDSTADDR; return ioctl(p, (struct ioctl_args *)args); case LINUX_SIOCGIFBRDADDR: args->cmd =3D OSIOCGIFBRDADDR; return ioctl(p, (struct ioctl_args *)args); case LINUX_SIOCGIFNETMASK: args->cmd =3D OSIOCGIFNETMASK; return ioctl(p, (struct ioctl_args *)args); /* get hardware address */ case LINUX_SIOCGIFHWADDR: { int ifn; struct ifnet *ifp; struct ifaddr *ifa; struct sockaddr_dl *sdl; struct linux_ifreq *ifr =3D (struct linux_ifreq *)args->arg; /* = * Note that we don't actually respect the name in the ifreq structure, = as * Linux interface names are all different */ for (ifn =3D 0; ifn < if_index; ifn++) { ifp =3D ifnet_addrs[ifn]->ifa_ifp; /* pointer to interface */ if (ifp->if_type =3D=3D IFT_ETHER) { /* looks good */ /* walk the address list */ for (ifa =3D TAILQ_FIRST(&ifp->if_addrhead); ifa; ifa =3D TAILQ_NEXT(if= a, ifa_link)) { if ((sdl =3D (struct sockaddr_dl *)ifa->ifa_addr) && /* we have an = address structure */ (sdl->sdl_family =3D=3D AF_LINK) && /* it's a link address */ (sdl->sdl_type =3D=3D IFT_ETHER)) { /* for an ethernet link */ return(copyout(LLADDR(sdl), (caddr_t)&ifr->ifr_hwaddr.sa_data, LINUX_I= FHWADDRLEN)); } } } } return(ENOENT); /* ??? */ } case LINUX_SIOCADDMULTI: args->cmd =3D SIOCADDMULTI; return ioctl(p, (struct ioctl_args *)args); case LINUX_SIOCDELMULTI: args->cmd =3D SIOCDELMULTI; return ioctl(p, (struct ioctl_args *)args); case LINUX_FIOSETOWN: args->cmd =3D FIOSETOWN; return ioctl(p, (struct ioctl_args *)args); case LINUX_SIOCSPGRP: args->cmd =3D SIOCSPGRP; return ioctl(p, (struct ioctl_args *)args); case LINUX_FIOGETOWN: args->cmd =3D FIOGETOWN; return ioctl(p, (struct ioctl_args *)args); case LINUX_SIOCGPGRP: args->cmd =3D SIOCGPGRP; return ioctl(p, (struct ioctl_args *)args); case LINUX_SIOCATMARK: args->cmd =3D SIOCATMARK; return ioctl(p, (struct ioctl_args *)args); case LINUX_TIOCSETD: switch (args->arg) { case LINUX_N_TTY: bsd_line =3D TTYDISC; return (*func)(fp, TIOCSETD, (caddr_t)&bsd_line, p); case LINUX_N_SLIP: bsd_line =3D SLIPDISC; return (*func)(fp, TIOCSETD, (caddr_t)&bsd_line, p); case LINUX_N_PPP: bsd_line =3D PPPDISC; return (*func)(fp, TIOCSETD, (caddr_t)&bsd_line, p); default: return EINVAL; } case LINUX_TIOCGETD: bsd_line =3D TTYDISC; error =3D(*func)(fp, TIOCSETD, (caddr_t)&bsd_line, p); if (error) return error; switch (bsd_line) { case TTYDISC: linux_line =3D LINUX_N_TTY; break; case SLIPDISC: linux_line =3D LINUX_N_SLIP; break; case PPPDISC: linux_line =3D LINUX_N_PPP; break; default: return EINVAL; } return copyout(&linux_line, (caddr_t)args->arg, = sizeof(int)); case LINUX_SNDCTL_SEQ_RESET: args->cmd =3D SNDCTL_SEQ_RESET; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_SEQ_SYNC: args->cmd =3D SNDCTL_SEQ_SYNC; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_SYNTH_INFO: args->cmd =3D SNDCTL_SYNTH_INFO; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_SEQ_CTRLRATE: args->cmd =3D SNDCTL_SEQ_CTRLRATE; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_SEQ_GETOUTCOUNT: args->cmd =3D SNDCTL_SEQ_GETOUTCOUNT; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_SEQ_GETINCOUNT: args->cmd =3D SNDCTL_SEQ_GETINCOUNT; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_SEQ_PERCMODE: args->cmd =3D SNDCTL_SEQ_PERCMODE; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_FM_LOAD_INSTR: args->cmd =3D SNDCTL_FM_LOAD_INSTR; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_SEQ_TESTMIDI: args->cmd =3D SNDCTL_SEQ_TESTMIDI; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_SEQ_RESETSAMPLES: args->cmd =3D SNDCTL_SEQ_RESETSAMPLES; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_SEQ_NRSYNTHS: args->cmd =3D SNDCTL_SEQ_NRSYNTHS; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_SEQ_NRMIDIS: args->cmd =3D SNDCTL_SEQ_NRMIDIS; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_MIDI_INFO: args->cmd =3D SNDCTL_MIDI_INFO; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_SEQ_TRESHOLD: args->cmd =3D SNDCTL_SEQ_TRESHOLD; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_SYNTH_MEMAVL: args->cmd =3D SNDCTL_SYNTH_MEMAVL; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_DSP_GETOPTR : args->cmd =3D SNDCTL_DSP_GETOPTR; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_DSP_GETIPTR : args->cmd =3D SNDCTL_DSP_GETIPTR; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_DSP_SETTRIGGER: args->cmd =3D SNDCTL_DSP_SETTRIGGER; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_DSP_GETCAPS: args->cmd =3D SNDCTL_DSP_GETCAPS; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_DSP_RESET: args->cmd =3D SNDCTL_DSP_RESET; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_DSP_SYNC: args->cmd =3D SNDCTL_DSP_SYNC; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_DSP_SPEED: args->cmd =3D SNDCTL_DSP_SPEED; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_DSP_STEREO: args->cmd =3D SNDCTL_DSP_STEREO; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_DSP_GETBLKSIZE: /* LINUX_SNDCTL_DSP_SETBLKSIZE */ args->cmd =3D SNDCTL_DSP_GETBLKSIZE; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_DSP_SETFMT: args->cmd =3D SNDCTL_DSP_SETFMT; return ioctl(p, (struct ioctl_args *)args); case LINUX_SOUND_PCM_WRITE_CHANNELS: args->cmd =3D SOUND_PCM_WRITE_CHANNELS; return ioctl(p, (struct ioctl_args *)args); case LINUX_SOUND_PCM_WRITE_FILTER: args->cmd =3D SOUND_PCM_WRITE_FILTER; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_DSP_POST: args->cmd =3D SNDCTL_DSP_POST; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_DSP_SUBDIVIDE: args->cmd =3D SNDCTL_DSP_SUBDIVIDE; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_DSP_SETFRAGMENT: args->cmd =3D SNDCTL_DSP_SETFRAGMENT; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_DSP_GETFMTS: args->cmd =3D SNDCTL_DSP_GETFMTS; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_DSP_GETOSPACE: args->cmd =3D SNDCTL_DSP_GETOSPACE; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_DSP_GETISPACE: args->cmd =3D SNDCTL_DSP_GETISPACE; return ioctl(p, (struct ioctl_args *)args); case LINUX_SNDCTL_DSP_NONBLOCK: args->cmd =3D SNDCTL_DSP_NONBLOCK; return ioctl(p, (struct ioctl_args *)args); case LINUX_SOUND_MIXER_WRITE_VOLUME: args->cmd =3D SETDIR(SOUND_MIXER_WRITE_VOLUME); return ioctl(p, (struct ioctl_args *)args); case LINUX_SOUND_MIXER_WRITE_BASS: args->cmd =3D SETDIR(SOUND_MIXER_WRITE_BASS); return ioctl(p, (struct ioctl_args *)args); case LINUX_SOUND_MIXER_WRITE_TREBLE: args->cmd =3D SETDIR(SOUND_MIXER_WRITE_TREBLE); return ioctl(p, (struct ioctl_args *)args); case LINUX_SOUND_MIXER_WRITE_SYNTH: args->cmd =3D SETDIR(SOUND_MIXER_WRITE_SYNTH); return ioctl(p, (struct ioctl_args *)args); case LINUX_SOUND_MIXER_WRITE_PCM: args->cmd =3D SETDIR(SOUND_MIXER_WRITE_PCM); return ioctl(p, (struct ioctl_args *)args); case LINUX_SOUND_MIXER_WRITE_SPEAKER: args->cmd =3D SETDIR(SOUND_MIXER_WRITE_SPEAKER); return ioctl(p, (struct ioctl_args *)args); case LINUX_SOUND_MIXER_WRITE_LINE: args->cmd =3D SETDIR(SOUND_MIXER_WRITE_LINE); return ioctl(p, (struct ioctl_args *)args); case LINUX_SOUND_MIXER_WRITE_MIC: args->cmd =3D SETDIR(SOUND_MIXER_WRITE_MIC); return ioctl(p, (struct ioctl_args *)args); case LINUX_SOUND_MIXER_WRITE_CD: args->cmd =3D SETDIR(SOUND_MIXER_WRITE_CD); return ioctl(p, (struct ioctl_args *)args); case LINUX_SOUND_MIXER_WRITE_IMIX: args->cmd =3D SETDIR(SOUND_MIXER_WRITE_IMIX); return ioctl(p, (struct ioctl_args *)args); case LINUX_SOUND_MIXER_WRITE_ALTPCM: args->cmd =3D SETDIR(SOUND_MIXER_WRITE_ALTPCM); return ioctl(p, (struct ioctl_args *)args); case LINUX_SOUND_MIXER_WRITE_RECLEV: args->cmd =3D SETDIR(SOUND_MIXER_WRITE_RECLEV); return ioctl(p, (struct ioctl_args *)args); case LINUX_SOUND_MIXER_WRITE_IGAIN: args->cmd =3D SETDIR(SOUND_MIXER_WRITE_IGAIN); return ioctl(p, (struct ioctl_args *)args); case LINUX_SOUND_MIXER_WRITE_OGAIN: args->cmd =3D SETDIR(SOUND_MIXER_WRITE_OGAIN); return ioctl(p, (struct ioctl_args *)args); case LINUX_SOUND_MIXER_WRITE_LINE1: args->cmd =3D SETDIR(SOUND_MIXER_WRITE_LINE1); return ioctl(p, (struct ioctl_args *)args); case LINUX_SOUND_MIXER_WRITE_LINE2: args->cmd =3D SETDIR(SOUND_MIXER_WRITE_LINE2); return ioctl(p, (struct ioctl_args *)args); case LINUX_SOUND_MIXER_WRITE_LINE3: args->cmd =3D SETDIR(SOUND_MIXER_WRITE_LINE3); return ioctl(p, (struct ioctl_args *)args); case LINUX_SOUND_MIXER_READ_DEVMASK: args->cmd =3D SOUND_MIXER_READ_DEVMASK; return ioctl(p, (struct ioctl_args *)args); case LINUX_TIOCGSERIAL: linux_tiocgserial(fp, (struct linux_serial_struct *)args->arg); return 0; case LINUX_TIOCSSERIAL: linux_tiocsserial(fp, (struct linux_serial_struct *)args->arg); return 0; case LINUX_TCFLSH: args->cmd =3D TIOCFLUSH; switch (args->arg) { case LINUX_TCIFLUSH: args->arg =3D FREAD; break; case LINUX_TCOFLUSH: args->arg =3D FWRITE; break; case LINUX_TCIOFLUSH: args->arg =3D FREAD | FWRITE; break; default: return EINVAL; } return ioctl(p, (struct ioctl_args *)args); case LINUX_VT_OPENQRY: args->cmd =3D VT_OPENQRY; return ioctl(p, (struct ioctl_args *)args); case LINUX_VT_GETMODE: args->cmd =3D VT_GETMODE; return ioctl(p, (struct ioctl_args *)args); case LINUX_VT_SETMODE: = { struct vt_mode *mode; args->cmd =3D VT_SETMODE; mode =3D (struct vt_mode *)args->arg; if (!ISSIGVALID(mode->frsig) && ISSIGVALID(mode->acqsig)) mode->frsig =3D mode->acqsig; return ioctl(p, (struct ioctl_args *)args); } case LINUX_VT_GETSTATE: args->cmd =3D VT_GETACTIVE; return ioctl(p, (struct ioctl_args *)args); case LINUX_VT_ACTIVATE: args->cmd =3D VT_ACTIVATE; return ioctl(p, (struct ioctl_args *)args); case LINUX_VT_WAITACTIVE: args->cmd =3D VT_WAITACTIVE; return ioctl(p, (struct ioctl_args *)args); case LINUX_KDGKBMODE: args->cmd =3D KDGKBMODE; return ioctl(p, (struct ioctl_args *)args); case LINUX_KDSKBMODE: { int kbdmode; switch (args->arg) { case LINUX_KBD_RAW: kbdmode =3D K_RAW; return (*func)(fp, KDSKBMODE, (caddr_t)&kbdmode, p); case LINUX_KBD_XLATE: = kbdmode =3D K_XLATE; return (*func)(fp, KDSKBMODE , (caddr_t)&kbdmode, p); case LINUX_KBD_MEDIUMRAW: kbdmode =3D K_RAW; return (*func)(fp, KDSKBMODE , (caddr_t)&kbdmode, p); default: return EINVAL; } } case LINUX_KDGETMODE: args->cmd =3D KDGETMODE; return ioctl(p, (struct ioctl_args *)args); case LINUX_KDSETMODE: args->cmd =3D KDSETMODE; return ioctl(p, (struct ioctl_args *)args); case LINUX_KDSETLED: args->cmd =3D KDSETLED; return ioctl(p, (struct ioctl_args *)args); case LINUX_KDGETLED: args->cmd =3D KDGETLED; return ioctl(p, (struct ioctl_args *)args); case LINUX_KIOCSOUND: args->cmd =3D KIOCSOUND; return ioctl(p, (struct ioctl_args *)args); case LINUX_KDMKTONE: args->cmd =3D KDMKTONE; return ioctl(p, (struct ioctl_args *)args); case LINUX_CDROMPAUSE: args->cmd =3D CDIOCPAUSE; return ioctl(p, (struct ioctl_args *)args); case LINUX_CDROMRESUME: args->cmd =3D CDIOCRESUME; return ioctl(p, (struct ioctl_args *)args); case LINUX_CDROMPLAYMSF: args->cmd =3D CDIOCPLAYMSF; return ioctl(p, (struct ioctl_args *)args); case LINUX_CDROMPLAYTRKIND: args->cmd =3D CDIOCPLAYTRACKS; return ioctl(p, (struct ioctl_args *)args); case LINUX_CDROMSTART: args->cmd =3D CDIOCSTART; return ioctl(p, (struct ioctl_args *)args); case LINUX_CDROMSTOP: args->cmd =3D CDIOCSTOP; return ioctl(p, (struct ioctl_args *)args); case LINUX_CDROMEJECT: args->cmd =3D CDIOCEJECT; return ioctl(p, (struct ioctl_args *)args); case LINUX_CDROMRESET: args->cmd =3D CDIOCRESET; return ioctl(p, (struct ioctl_args *)args); case LINUX_CDROMREADTOCHDR: { struct ioc_toc_header th; struct linux_cdrom_tochdr lth; error =3D (*func)(fp, CDIOREADTOCHEADER, (caddr_t)&th, p); if (!error) { lth.cdth_trk0 =3D th.starting_track; lth.cdth_trk1 =3D th.ending_track; copyout((caddr_t)<h, (caddr_t)args->arg, sizeof(lth)); } return error; } case LINUX_CDROMREADTOCENTRY: { struct linux_cdrom_tocentry lte, *ltep =3D (struct linux_cdrom_tocentry *)args->arg; struct ioc_read_toc_single_entry irtse; irtse.address_format =3D ltep->cdte_format; irtse.track =3D ltep->cdte_track; error =3D (*func)(fp, CDIOREADTOCENTRY, (caddr_t)&irtse, p); if (!error) { lte =3D *ltep; lte.cdte_ctrl =3D irtse.entry.control; lte.cdte_adr =3D irtse.entry.addr_type; bsd_to_linux_msf_lba(irtse.address_format, &irtse.entry.addr, <e.cdte_addr); copyout((caddr_t)<e, (caddr_t)args->arg, sizeof(lte)); } return error; } case 0x3304: case 0x3303: case 0x3302: { int myretval; struct pioData { short port; short size; int device; void *value; } *desc; desc =3D (struct pioData *)args->arg; myretval =3D (*func)(fp, args->cmd, (caddr_t)args->arg, p); if (myretval !=3D EINVAL) { p->p_retval[0] =3D myretval; return 0; } else return myretval; } } uprintf("LINUX: 'ioctl' fd=3D%d, typ=3D0x%x(%c), num=3D0x%x not imple= mented\n", args->fd, (u_int)((args->cmd & 0xffff00) >> 8), (int)((args->cmd & 0xffff00) >> 8), (u_int)(args->cmd & 0xff)); return EINVAL; } -- = The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could prod= uce the Complete Works of Shakespeare; now, thanks to the Internet, we k= now this is not true." Robert Wilensky, University of Califor= nia To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 19:11:36 1999 Delivered-To: freebsd-current@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id A9BA914C47 for ; Mon, 14 Jun 1999 19:11:33 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id WAA37070; Mon, 14 Jun 1999 22:11:09 -0400 (EDT) Date: Mon, 14 Jun 1999 22:11:08 -0400 (EDT) From: Chuck Robey To: "David E. Cross" Cc: David Scheidt , Chan Yiu Wah , freebsd-current@FreeBSD.ORG Subject: Re: What happened to CTM src-cur? In-Reply-To: <199906150028.UAA22149@cs.rpi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 14 Jun 1999, David E. Cross wrote: > Yes, that was far from my final patch :) It was intended for those with more > clue, and a fresh look at the code (such as yourself ;) to help me out. > I don't believe that we have handled all the problems, I believe almost > any "error" condition may cause this... there are multiple points at which > "error=" occurs, and it would seem to suggest that any may lead to this. I > have a giant printout of this routine and I am atytempting to trace all the > code paths. > > Could someone provide an indication as to what (paraphrasing) "vattr->va_size > =-1" would parse to in english? ??? I'm compleletely floored. David, you included no context ... I have copies of the earlier messages, and I *still* can't figure out what you're talking about. [assuming this message is true to it's subject header ....] I do wish that it hadn't taken 6 days for someone to complain. The system was out of disk, it's restarted now, but it won't generate something for some hours yet. > > -- > David Cross > The source will be with you, always. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 19:19:56 1999 Delivered-To: freebsd-current@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id E65D414C47 for ; Mon, 14 Jun 1999 19:19:53 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: (qmail 95732 invoked from network); 15 Jun 1999 02:19:53 -0000 Received: from shell-1.enteract.com (dscheidt@207.229.143.40) by pop3-3.enteract.com with SMTP; 15 Jun 1999 02:19:53 -0000 Received: from localhost (dscheidt@localhost) by shell-1.enteract.com (8.9.3/8.9.2) with SMTP id VAA83579; Mon, 14 Jun 1999 21:19:52 -0500 (CDT) (envelope-from dscheidt@enteract.com) X-Authentication-Warning: shell-1.enteract.com: dscheidt owned process doing -bs Date: Mon, 14 Jun 1999 21:19:52 -0500 (CDT) From: David Scheidt To: Chuck Robey Cc: "David E. Cross" , Chan Yiu Wah , freebsd-current@FreeBSD.ORG Subject: Re: What happened to CTM src-cur? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 14 Jun 1999, Chuck Robey wrote: > On Mon, 14 Jun 1999, David E. Cross wrote: > > ??? I'm compleletely floored. David, you included no context ... I > have copies of the earlier messages, and I *still* can't figure out what > you're talking about. > > [assuming this message is true to it's subject header ....] It isn't. He is talking, I think, about Matt Dillons modifications to David Cross's NFS v3 panic problem in 3.2-STABLE. David Cross has been having problems sending coherent mail today, too much excitment at having found a really tricky bug. David Scheidt, who wondered why this showed up in my INBOX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 19:21:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id C7002151C0 for ; Mon, 14 Jun 1999 19:21:31 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id WAA37112; Mon, 14 Jun 1999 22:20:58 -0400 (EDT) Date: Mon, 14 Jun 1999 22:20:57 -0400 (EDT) From: Chuck Robey To: David Scheidt Cc: "David E. Cross" , Chan Yiu Wah , freebsd-current@FreeBSD.ORG Subject: Re: What happened to CTM src-cur? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 14 Jun 1999, David Scheidt wrote: > On Mon, 14 Jun 1999, Chuck Robey wrote: > > > On Mon, 14 Jun 1999, David E. Cross wrote: > > > > ??? I'm compleletely floored. David, you included no context ... I > > have copies of the earlier messages, and I *still* can't figure out what > > you're talking about. > > > > [assuming this message is true to it's subject header ....] > > It isn't. He is talking, I think, about Matt Dillons modifications to David > Cross's NFS v3 panic problem in 3.2-STABLE. David Cross has been having > problems sending coherent mail today, too much excitment at having found a > really tricky bug. Oh ... OK, I'd surely forgive him that! > > David Scheidt, who wondered why this showed up in my INBOX > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 19:26:44 1999 Delivered-To: freebsd-current@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 27D6E14C47; Mon, 14 Jun 1999 19:26:22 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from lot.gsoft.com.au (lot.gsoft.com.au [203.38.152.106]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id LAA13165; Tue, 15 Jun 1999 11:55:38 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199906150148.JAA09202@ariadne.tensor.pgs.com> Date: Tue, 15 Jun 1999 11:55:38 +0930 (CST) From: "Daniel O'Connor" To: Stephen Hocking-Senior Programmer PGS Tensor Perth Subject: RE: Voodoo device driver for current enclosed (2nd try!) Cc: multimedia@freebsd.org, current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 15-Jun-99 Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > Find herein the files that make up my so far unsuccessful attempt to write a > voodoo device driver. It was translated wholesale from Daryl Strauss's > driver for Linux, although I've messed up something along the way. At the > moment, it will lock up the machine hard shortly after mmaping the card's > memory. I'm about to go on holidays for a week, so I thought I'd throw this > out for you all to take a look at and hopefully find out what I've done > wrong. I just made a patch set out of it at http://www.dons.net.au/~darius/voodoo.patch Of course I have tested it or anything so it may be completely stuffed. It was made against -current as of yesterday... I did manage to build my kernel and the linux emulator, so the stuff is in the right place. --- 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-current" in the body of the message From owner-freebsd-current Mon Jun 14 20: 1: 7 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 363E614E4B for ; Mon, 14 Jun 1999 20:01:05 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA13883; Mon, 14 Jun 1999 20:00:59 -0700 (PDT) (envelope-from dillon) Date: Mon, 14 Jun 1999 20:00:59 -0700 (PDT) From: Matthew Dillon Message-Id: <199906150300.UAA13883@apollo.backplane.com> To: "David E. Cross" Cc: Chuck Robey , David Scheidt , Chan Yiu Wah , freebsd-current@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: What happened to CTM src-cur? References: <199906150028.UAA22149@cs.rpi.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Yes, that was far from my final patch :) It was intended for those with more :clue, and a fresh look at the code (such as yourself ;) to help me out. :I don't believe that we have handled all the problems, I believe almost :any "error" condition may cause this... there are multiple points at which :"error=" occurs, and it would seem to suggest that any may lead to this. I :have a giant printout of this routine and I am atytempting to trace all the :code paths. Hmm.. yes, you are right, it looks like there is another case around line 1440 of nfs_serv.c. if (!error) { nfsrv_object_create(nd.ni_vp); zfree(namei_zone, nd.ni_cnd.cn_pnbuf); if (exclusive_flag) { exclusive_flag = 0; VATTR_NULL(vap); bcopy(cverf, (caddr_t)&vap->va_atime, NFSX_V3CREATEVERF); >>>>>>>>> error = VOP_SETATTR(nd.ni_vp, vap, cred, procp); } } There is a possible case in handling the VOP_MKNOD call at line 1459. The section of code at line 1469 sets error but does not dispose of the vp anywhere later on: if ((error = lookup(&nd)) != 0) { zfree(namei_zone, nd.ni_cnd.cn_pnbuf); nfsm_reply(0); } Those are the only other two cases I can see. The other places where error is returned should leave nd.ni_vp NULL. The easiest solution is to track the vp and NULL it out whenever it gets vput, then put an KASSERT where the code returns to make sure vp is NULL. :Could someone provide an indication as to what (paraphrasing) "vattr->va_size :=-1" would parse to in english? I don't know. Yet :-) -Matt Matthew Dillon :-- :David Cross :The source will be with you, always. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 20:12: 8 1999 Delivered-To: freebsd-current@freebsd.org Received: from gizmo.internode.com.au (gizmo.internode.com.au [192.83.231.115]) by hub.freebsd.org (Postfix) with ESMTP id F115614E4B for ; Mon, 14 Jun 1999 20:11:47 -0700 (PDT) (envelope-from newton@gizmo.internode.com.au) Received: (from newton@localhost) by gizmo.internode.com.au (8.9.3/8.9.3) id MAA01182; Tue, 15 Jun 1999 12:41:03 +0930 (CST) (envelope-from newton) From: Mark Newton Message-Id: <199906150311.MAA01182@gizmo.internode.com.au> Subject: Re: ES1370 Sound problems To: naddy@mips.rhein-neckar.de (Christian Weisgerber) Date: Tue, 15 Jun 1999 12:41:03 +0930 (CST) Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <7jrdha$v9m$1@mips.rhein-neckar.de> from "Christian Weisgerber" at Jun 11, 99 06:29:30 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christian Weisgerber wrote: > Joe Clarke wrote: > > I currently re-added my es1370-based Ensoniq soundcard to my FreeBSD 3.2 > > system with the hope of getting Luigi's sound driver working with it. > > > > es1: rev 0x00 int a irq 10 on pci0.15.0 > ^^^ > > pcm1: using I/O space register mapping at 0x1800 > > At least with 4.0-CURRENT that's a problem. You need to patch > sys/pci/es1370.c, ca. line 150, in struct es_pci_driver. Replace "es" > by "pcm". I altered and tested this this morning; I've since committed the patch. Thanks for the heads-up -- Seems to be another newbus integration relic. - mark ---- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 20:19:41 1999 Delivered-To: freebsd-current@freebsd.org Received: from norn.ca.eu.org (cr965240-b.abtsfd1.bc.wave.home.com [24.113.19.137]) by hub.freebsd.org (Postfix) with ESMTP id 68ADB14E03 for ; Mon, 14 Jun 1999 20:19:39 -0700 (PDT) (envelope-from norn@norn.ca.eu.org) Received: by norn.ca.eu.org (Postfix, from userid 1000) id 05A4F9F; Mon, 14 Jun 1999 20:19:37 -0700 (PDT) Date: Mon, 14 Jun 1999 20:19:37 -0700 From: Chris Piazza To: Mark Newton Cc: Christian Weisgerber , freebsd-current@FreeBSD.ORG Subject: Re: ES1370 Sound problems Message-ID: <19990614201937.A1082@norn.ca.eu.org> References: <7jrdha$v9m$1@mips.rhein-neckar.de> <199906150311.MAA01182@gizmo.internode.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <199906150311.MAA01182@gizmo.internode.com.au>; from Mark Newton on Tue, Jun 15, 1999 at 12:41:03PM +0930 X-Operating-System: FreeBSD norn.ca.eu.org 4.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jun 15, 1999 at 12:41:03PM +0930, Mark Newton wrote: > > I altered and tested this this morning; I've since committed the > patch. Thanks for the heads-up -- Seems to be another newbus integration > relic. > What I'm wondering is why my es1370 has worked the entire time since the newbus integration. What exactly caused this to be a problem for some but not for me? -- Chris Piazza Abbotsford, BC, Canada cpiazza@home.net finger norn@norn.ca.eu.org for PGP key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 20:23:45 1999 Delivered-To: freebsd-current@freebsd.org Received: from gizmo.internode.com.au (gizmo.internode.com.au [192.83.231.115]) by hub.freebsd.org (Postfix) with ESMTP id 7966614E03 for ; Mon, 14 Jun 1999 20:23:42 -0700 (PDT) (envelope-from newton@gizmo.internode.com.au) Received: (from newton@localhost) by gizmo.internode.com.au (8.9.3/8.9.3) id MAA01316; Tue, 15 Jun 1999 12:52:57 +0930 (CST) (envelope-from newton) From: Mark Newton Message-Id: <199906150322.MAA01316@gizmo.internode.com.au> Subject: Re: ES1370 Sound problems To: cpiazza@home.net (Chris Piazza) Date: Tue, 15 Jun 1999 12:52:57 +0930 (CST) Cc: newton@internode.com.au, naddy@mips.rhein-neckar.de, freebsd-current@FreeBSD.ORG In-Reply-To: <19990614201937.A1082@norn.ca.eu.org> from "Chris Piazza" at Jun 14, 99 08:19:37 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chris Piazza wrote: > > I altered and tested this this morning; I've since committed the > > patch. Thanks for the heads-up -- Seems to be another newbus integration > > relic. > > What I'm wondering is why my es1370 has worked the entire time since the > newbus integration. What exactly caused this to be a problem for some > but not for me? Does yours do soundblaster emulation, and therefore come up with the soundblaster driver instead? - mark ---- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 20:26:15 1999 Delivered-To: freebsd-current@freebsd.org Received: from norn.ca.eu.org (cr965240-b.abtsfd1.bc.wave.home.com [24.113.19.137]) by hub.freebsd.org (Postfix) with ESMTP id F33891512F for ; Mon, 14 Jun 1999 20:26:12 -0700 (PDT) (envelope-from norn@norn.ca.eu.org) Received: by norn.ca.eu.org (Postfix, from userid 1000) id 279D7A0; Mon, 14 Jun 1999 20:26:12 -0700 (PDT) Date: Mon, 14 Jun 1999 20:26:12 -0700 From: Chris Piazza To: Mark Newton Cc: naddy@mips.rhein-neckar.de, freebsd-current@FreeBSD.ORG Subject: Re: ES1370 Sound problems Message-ID: <19990614202612.B1082@norn.ca.eu.org> References: <19990614201937.A1082@norn.ca.eu.org> <199906150322.MAA01316@gizmo.internode.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <199906150322.MAA01316@gizmo.internode.com.au>; from Mark Newton on Tue, Jun 15, 1999 at 12:52:57PM +0930 X-Operating-System: FreeBSD norn.ca.eu.org 4.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jun 15, 1999 at 12:52:57PM +0930, Mark Newton wrote: > Chris Piazza wrote: > > > > I altered and tested this this morning; I've since committed the > > > patch. Thanks for the heads-up -- Seems to be another newbus integration > > > relic. > > > > What I'm wondering is why my es1370 has worked the entire time since the > > newbus integration. What exactly caused this to be a problem for some > > but not for me? > > Does yours do soundblaster emulation, and therefore come up with the > soundblaster driver instead? es0: irq 5 at device 9.0 on pci0 pcm0: using I/O space register mapping at 0xd800 In my kernel conf I have a: device pcm0 -- Chris Piazza Abbotsford, BC, Canada cpiazza@home.net finger norn@norn.ca.eu.org for PGP key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 20:35:49 1999 Delivered-To: freebsd-current@freebsd.org Received: from gizmo.internode.com.au (gizmo.internode.com.au [192.83.231.115]) by hub.freebsd.org (Postfix) with ESMTP id 08906153EF for ; Mon, 14 Jun 1999 20:35:43 -0700 (PDT) (envelope-from newton@gizmo.internode.com.au) Received: (from newton@localhost) by gizmo.internode.com.au (8.9.3/8.9.3) id NAA01391; Tue, 15 Jun 1999 13:04:43 +0930 (CST) (envelope-from newton) From: Mark Newton Message-Id: <199906150334.NAA01391@gizmo.internode.com.au> Subject: Re: ES1370 Sound problems To: cpiazza@home.net (Chris Piazza) Date: Tue, 15 Jun 1999 13:04:43 +0930 (CST) Cc: newton@internode.com.au, naddy@mips.rhein-neckar.de, freebsd-current@FreeBSD.ORG In-Reply-To: <19990614202612.B1082@norn.ca.eu.org> from "Chris Piazza" at Jun 14, 99 08:26:12 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chris Piazza wrote: > > Does yours do soundblaster emulation, and therefore come up with the > > soundblaster driver instead? > > es0: irq 5 at device 9.0 on pci0 > pcm0: using I/O space register mapping at 0xd800 > In my kernel conf I have a: > device pcm0 Hmm - Until I patched it this morning, I got: es0: irq 11 at device 8.0 on pc pcm0: using I/O space register mapping at 0xe400 [ ... ] isa_compat: didn't get ports for pcm if I explicitly mentioned ports and IRQs, and the same messages but without the isa_compat message if I didn't. /dev/sndstat contained: FreeBSD Audio Driver (981002) Jun 11 1999 21:12:33 Installed devices: ... and nothing else, which wasn't particularly encouraging either. Does yours still work with the patch? The feeling I'd received from a bit of emailing I didn't last week and the traffic on this list over the weekend was that it was broken under 4.0-CURRENT for everyone. - mark ---- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 20:47:26 1999 Delivered-To: freebsd-current@freebsd.org Received: from norn.ca.eu.org (cr965240-b.abtsfd1.bc.wave.home.com [24.113.19.137]) by hub.freebsd.org (Postfix) with ESMTP id 4678714E7B for ; Mon, 14 Jun 1999 20:47:24 -0700 (PDT) (envelope-from norn@norn.ca.eu.org) Received: by norn.ca.eu.org (Postfix, from userid 1000) id 2D29573; Mon, 14 Jun 1999 20:47:23 -0700 (PDT) Date: Mon, 14 Jun 1999 20:47:23 -0700 From: Chris Piazza To: Mark Newton Cc: naddy@mips.rhein-neckar.de, freebsd-current@FreeBSD.ORG Subject: Re: ES1370 Sound problems Message-ID: <19990614204723.A331@norn.ca.eu.org> References: <19990614202612.B1082@norn.ca.eu.org> <199906150334.NAA01391@gizmo.internode.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <199906150334.NAA01391@gizmo.internode.com.au>; from Mark Newton on Tue, Jun 15, 1999 at 01:04:43PM +0930 X-Operating-System: FreeBSD norn.ca.eu.org 4.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jun 15, 1999 at 01:04:43PM +0930, Mark Newton wrote: > Chris Piazza wrote: > > > > Does yours do soundblaster emulation, and therefore come up with the > > > soundblaster driver instead? > > > > es0: irq 5 at device 9.0 on pci0 > > pcm0: using I/O space register mapping at 0xd800 > > In my kernel conf I have a: > > device pcm0 > > Hmm - Until I patched it this morning, I got: > > es0: irq 11 at device 8.0 on pc > pcm0: using I/O space register mapping at 0xe400 > [ ... ] > isa_compat: didn't get ports for pcm > > if I explicitly mentioned ports and IRQs, and the same messages but without > the isa_compat message if I didn't. /dev/sndstat contained: > > FreeBSD Audio Driver (981002) Jun 11 1999 21:12:33 > Installed devices: > > ... and nothing else, which wasn't particularly encouraging either. Odd :-). FreeBSD Audio Driver (981002) Jun 12 1999 11:07:22 Installed devices: pcm0: at 0xd800 irq 0 dma 0:0 is what I got before, and it's still the same. dmesg now reports: pcm0: irq 5 at device 9.0 on pci0 pcm0: using I/O space register mapping at 0xd800 > > Does yours still work with the patch? The feeling I'd received from > a bit of emailing I didn't last week and the traffic on this list over > the weekend was that it was broken under 4.0-CURRENT for everyone. > Yeah, it still works. -- Chris Piazza Abbotsford, BC, Canada cpiazza@home.net finger norn@norn.ca.eu.org for PGP key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 20:55:18 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 4F96814D1A for ; Mon, 14 Jun 1999 20:55:17 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA14268; Mon, 14 Jun 1999 20:55:14 -0700 (PDT) (envelope-from dillon) Date: Mon, 14 Jun 1999 20:55:14 -0700 (PDT) From: Matthew Dillon Message-Id: <199906150355.UAA14268@apollo.backplane.com> To: "David E. Cross" , Chuck Robey , David Scheidt , Chan Yiu Wah , freebsd-current@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: What happened to CTM src-cur? References: <199906150028.UAA22149@cs.rpi.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ack, you may have opened up a can of worms here. I don't even think that nfs_namei() does the right thing when it returns an error... it doesn't look like it clears the ndp->ni_vp either in some error cases. We are going to have to instrument the code - basically means NULLing out ni_vp and any local vnode pointer when the vnode in question is released so we can keep track of it and putting KASSERT()s in strategic places. nfs_namei() in nfs/nfs_subs.c and just about all the subroutines defined in nfs/nfs_serv.c. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 21:17: 9 1999 Delivered-To: freebsd-current@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 6F09B14DAE for ; Mon, 14 Jun 1999 21:17:06 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id AAA37420; Tue, 15 Jun 1999 00:15:27 -0400 (EDT) Date: Tue, 15 Jun 1999 00:15:27 -0400 (EDT) From: Chuck Robey To: Matthew Dillon Cc: "David E. Cross" , David Scheidt , Chan Yiu Wah , freebsd-current@FreeBSD.ORG, "David E. Cross" Subject: Re: What happened to CTM src-cur? In-Reply-To: <199906150355.UAA14268@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 14 Jun 1999, Matthew Dillon wrote: > Ack, you may have opened up a can of worms here. I don't even think > that nfs_namei() does the right thing when it returns an error... it > doesn't look like it clears the ndp->ni_vp either in some error cases. > > We are going to have to instrument the code - basically means NULLing > out ni_vp and any local vnode pointer when the vnode in question is > released so we can keep track of it and putting KASSERT()s in strategic > places. nfs_namei() in nfs/nfs_subs.c and just about all the subroutines > defined in nfs/nfs_serv.c. OK, you hijacked my thread ... OK, I've done worse, but please, could you change the subject line? We *do* still have a ctm outage here, it's clearing up (I hope) but I want feedback, and you've prevented it. > > -Matt > Matthew Dillon > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 21:21:45 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id A524414DAE for ; Mon, 14 Jun 1999 21:21:43 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA14439; Mon, 14 Jun 1999 21:21:43 -0700 (PDT) (envelope-from dillon) Date: Mon, 14 Jun 1999 21:21:43 -0700 (PDT) From: Matthew Dillon Message-Id: <199906150421.VAA14439@apollo.backplane.com> To: "David E. Cross" , David Scheidt , Chan Yiu Wah , freebsd-current@FreeBSD.ORG Subject: NFS vnode reference issues on server Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Ack, you may have opened up a can of worms here. I don't even think :> that nfs_namei() does the right thing when it returns an error... it :> doesn't look like it clears the ndp->ni_vp either in some error cases. :> :> We are going to have to instrument the code - basically means NULLing :> out ni_vp and any local vnode pointer when the vnode in question is :> released so we can keep track of it and putting KASSERT()s in strategic :> places. nfs_namei() in nfs/nfs_subs.c and just about all the subroutines :> defined in nfs/nfs_serv.c. : :OK, you hijacked my thread ... OK, I've done worse, but please, could :you change the subject line? We *do* still have a ctm outage here, it's :clearing up (I hope) but I want feedback, and you've prevented it. Oops, didn't even notice. Fixed. Ok, something for people following the code to look over if they have the time. This in nfs_subs.c, nfs_namei(). Question: ndp->ni_vp is non-NULL and appears to be referenced as of the time a badlink occurs, linklen is 0, or the link is too long. Do we have to release ndp->ni_vp and NULL it out in this case? I believe so. nfs_namei(...) { ... if (error) { badlink: >>>>>>>>>> release/NULL ndp->ni_vp ??? <<<<<<<<< if (ndp->ni_pathlen > 1) zfree(namei_zone, cp); break; } linklen = MAXPATHLEN - auio.uio_resid; if (linklen == 0) { error = ENOENT; goto badlink; } if (linklen + ndp->ni_pathlen >= MAXPATHLEN) { error = ENAMETOOLONG; goto badlink; } -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 14 23:12:57 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 37BCC14D90 for ; Mon, 14 Jun 1999 23:12:54 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA46322; Tue, 15 Jun 1999 00:12:53 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA90394; Tue, 15 Jun 1999 00:12:37 -0600 (MDT) Message-Id: <199906150612.AAA90394@harmony.village.org> To: Tomer Weller Subject: Re: /usr/src/UPDATING Cc: FreeBSD Current In-reply-to: Your message of "Mon, 14 Jun 1999 22:45:51 +0300." <99061422463101.00303@Tomer.DrugsAreGood.org> References: <99061422463101.00303@Tomer.DrugsAreGood.org> Date: Tue, 15 Jun 1999 00:12:37 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <99061422463101.00303@Tomer.DrugsAreGood.org> Tomer Weller writes: : i've noticed no1 touches the /usr/src/UPDATING file... shame... Nobody has sent me anything for this file in a long time. What's missing? Warner P.S. Can you forward "sam" at your domain to me :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 0:48:17 1999 Delivered-To: freebsd-current@freebsd.org Received: from ns.oeno.com (ns.oeno.com [194.100.99.145]) by hub.freebsd.org (Postfix) with SMTP id 18E9614EE4 for ; Tue, 15 Jun 1999 00:48:13 -0700 (PDT) (envelope-from will@ns.oeno.com) Received: (qmail 2981 invoked by uid 1001); 15 Jun 1999 07:48:11 -0000 To: Matthew Dillon Cc: current@freebsd.org Subject: Re: NFS vnode reference issues on server References: <199906150421.VAA14439@apollo.backplane.com.newsgate.clinet.fi> From: Ville-Pertti Keinonen Date: 15 Jun 1999 10:45:48 +0300 In-Reply-To: Matthew Dillon's message of "15 Jun 1999 07:21:58 +0300" Message-ID: <86d7yxoqj6.fsf@not.demophon.com> Lines: 19 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon writes: > Ok, something for people following the code to look over if they have > the time. This in nfs_subs.c, nfs_namei(). Question: ndp->ni_vp > is non-NULL and appears to be referenced as of the time a badlink > occurs, linklen is 0, or the link is too long. Do we have to > release ndp->ni_vp and NULL it out in this case? I believe so. Yes, and it would seem that you should also do this for the previous error return (ELOOP). There are no special cases for specific errors so all exits with error conditions should behave identically. Callers bail out without doing anything further with the nameidata on errors, apparently in all cases. A reference to the directory vnode appears to be lost in most cases of errors, as well (once again, the reference in the nameidata). In *some* cases, there is a reference in retdirp, but it's a different reference. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 1: 9: 3 1999 Delivered-To: freebsd-current@freebsd.org Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (Postfix) with ESMTP id 54A0214D6E for ; Tue, 15 Jun 1999 01:08:58 -0700 (PDT) (envelope-from Dom.Mitchell@palmerharvey.co.uk) Received: from ho-nt-01.pandhm.co.uk (unverified) by mail.palmerharvey.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 15 Jun 1999 09:08:05 +0100 Received: from voodoo.pandhm.co.uk (VOODOO [10.100.35.12]) by ho-nt-01.pandhm.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MKM83NKK; Tue, 15 Jun 1999 09:00:11 +0100 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 10toH5-000KT5-00; Tue, 15 Jun 1999 09:08:51 +0100 To: Warner Losh Cc: Tomer Weller , FreeBSD Current Subject: Re: /usr/src/UPDATING X-Mailer: nmh-1.0 X-Colour: Green Organization: Palmer & Harvey McLane In-Reply-To: Warner Losh's message of "Tue, 15 Jun 1999 00:12:37 MDT" <199906150612.AAA90394@harmony.village.org> Date: Tue, 15 Jun 1999 09:08:50 +0100 From: Dom Mitchell Message-Id: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 15 June 1999, Warner Losh proclaimed: > In message <99061422463101.00303@Tomer.DrugsAreGood.org> Tomer Weller writes: > : i've noticed no1 touches the /usr/src/UPDATING file... shame... > > Nobody has sent me anything for this file in a long time. > > What's missing? A note about vinum being taken out of the build whilst Greg Lehey was on holiday probably would have been in order. As it is, its probably going to be back in the tree fairly soon, seeing as he's back and active on the mailing lists... As a side note, I'd like to thank you for trying with this file; I find it really quite handy. -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator "Always think very hard before messing with TCP. And then don't." -- MC -- ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 1:40:36 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 0B93A14DC8 for ; Tue, 15 Jun 1999 01:40:30 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id BAA15539; Tue, 15 Jun 1999 01:39:14 -0700 (PDT) (envelope-from dillon) Date: Tue, 15 Jun 1999 01:39:14 -0700 (PDT) From: Matthew Dillon Message-Id: <199906150839.BAA15539@apollo.backplane.com> To: Ville-Pertti Keinonen Cc: current@freebsd.org Subject: Re: NFS vnode reference issues on server References: <199906150421.VAA14439@apollo.backplane.com.newsgate.clinet.fi> <86d7yxoqj6.fsf@not.demophon.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Matthew Dillon writes: : :> Ok, something for people following the code to look over if they have :> the time. This in nfs_subs.c, nfs_namei(). Question: ndp->ni_vp :> is non-NULL and appears to be referenced as of the time a badlink :> occurs, linklen is 0, or the link is too long. Do we have to :> release ndp->ni_vp and NULL it out in this case? I believe so. : :Yes, and it would seem that you should also do this for the previous :error return (ELOOP). There are no special cases for specific errors :so all exits with error conditions should behave identically. Callers :bail out without doing anything further with the nameidata on errors, :apparently in all cases. : :A reference to the directory vnode appears to be lost in most cases of :errors, as well (once again, the reference in the nameidata). In :*some* cases, there is a reference in retdirp, but it's a different :reference. Yup. I think I caught them all. Here is a new preliminary nfs_namei(). I think I caught all the weird cases. The ref counts related to *retdirp weren't broken, but they were confusing. ELOOP was broken too ... I had missed that. (Anyone who wants to) Take a look at this one and tell me what you think. -Matt Matthew Dillon #ifndef NFS_NOSERVER /* * Set up nameidata for a lookup() call and do it. * * If pubflag is set, this call is done for a lookup operation on the * public filehandle. In that case we allow crossing mountpoints and * absolute pathnames. However, the caller is expected to check that * the lookup result is within the public fs, and deny access if * it is not. * * If an error is returned, ndp->ni_vp will be left NULL. * * dirp may be set whether an error is returned or not, and must be * released by the caller. */ int nfs_namei(ndp, fhp, len, slp, nam, mdp, dposp, retdirp, p, kerbflag, pubflag) register struct nameidata *ndp; fhandle_t *fhp; int len; struct nfssvc_sock *slp; struct sockaddr *nam; struct mbuf **mdp; caddr_t *dposp; struct vnode **retdirp; struct proc *p; int kerbflag, pubflag; { register int i, rem; register struct mbuf *md; register char *fromcp, *tocp, *cp; struct iovec aiov; struct uio auio; struct vnode *dp; int error, rdonly, linklen; struct componentname *cnp = &ndp->ni_cnd; *retdirp = (struct vnode *)0; cnp->cn_pnbuf = zalloc(namei_zone); /* * Copy the name from the mbuf list to ndp->ni_pnbuf * and set the various ndp fields appropriately. */ fromcp = *dposp; tocp = cnp->cn_pnbuf; md = *mdp; rem = mtod(md, caddr_t) + md->m_len - fromcp; cnp->cn_hash = 0; for (i = 0; i < len; i++) { while (rem == 0) { md = md->m_next; if (md == NULL) { error = EBADRPC; goto out; } fromcp = mtod(md, caddr_t); rem = md->m_len; } if (*fromcp == '\0' || (!pubflag && *fromcp == '/')) { error = EACCES; goto out; } cnp->cn_hash += (unsigned char)*fromcp; *tocp++ = *fromcp++; rem--; } *tocp = '\0'; *mdp = md; *dposp = fromcp; len = nfsm_rndup(len)-len; if (len > 0) { if (rem >= len) *dposp += len; else if ((error = nfs_adv(mdp, dposp, len, rem)) != 0) goto out; } /* * Extract and set starting directory. */ error = nfsrv_fhtovp(fhp, FALSE, &dp, ndp->ni_cnd.cn_cred, slp, nam, &rdonly, kerbflag, pubflag); if (error) goto out; if (dp->v_type != VDIR) { vrele(dp); error = ENOTDIR; goto out; } if (rdonly) cnp->cn_flags |= RDONLY; /* * Set return directory. Reference to dp is implicitly transfered * to the returned pointer */ *retdirp = dp; if (pubflag) { /* * Oh joy. For WebNFS, handle those pesky '%' escapes, * and the 'native path' indicator. */ cp = zalloc(namei_zone); fromcp = cnp->cn_pnbuf; tocp = cp; if ((unsigned char)*fromcp >= WEBNFS_SPECCHAR_START) { switch ((unsigned char)*fromcp) { case WEBNFS_NATIVE_CHAR: /* * 'Native' path for us is the same * as a path according to the NFS spec, * just skip the escape char. */ fromcp++; break; /* * More may be added in the future, range 0x80-0xff */ default: error = EIO; zfree(namei_zone, cp); goto out; } } /* * Translate the '%' escapes, URL-style. */ while (*fromcp != '\0') { if (*fromcp == WEBNFS_ESC_CHAR) { if (fromcp[1] != '\0' && fromcp[2] != '\0') { fromcp++; *tocp++ = HEXSTRTOI(fromcp); fromcp += 2; continue; } else { error = ENOENT; zfree(namei_zone, cp); goto out; } } else *tocp++ = *fromcp++; } *tocp = '\0'; zfree(namei_zone, cnp->cn_pnbuf); cnp->cn_pnbuf = cp; } ndp->ni_pathlen = (tocp - cnp->cn_pnbuf) + 1; ndp->ni_segflg = UIO_SYSSPACE; if (pubflag) { ndp->ni_rootdir = rootvnode; ndp->ni_loopcnt = 0; if (cnp->cn_pnbuf[0] == '/') dp = rootvnode; } else { cnp->cn_flags |= NOCROSSMOUNT; } /* * Initialize for scan, set ni_startdir and bump ref on dp again * becuase lookup() will dereference ni_startdir. */ cnp->cn_proc = p; VREF(dp); ndp->ni_startdir = dp; for (;;) { cnp->cn_nameptr = cnp->cn_pnbuf; /* * Call lookup() to do the real work. If an error occurs, * ndp->ni_vp and ni_dvp are left uninitialized or NULL and * we do not have to dereference anything before returning. * In either case ni_startdir will be dereferenced and NULLed * out. */ error = lookup(ndp); if (error) break; /* * Check for encountering a symbolic link. Trivial * termination occurs if no symlink encountered. */ if ((cnp->cn_flags & ISSYMLINK) == 0) { nfsrv_object_create(ndp->ni_vp); if (cnp->cn_flags & (SAVENAME | SAVESTART)) { cnp->cn_flags |= HASBUF; return (0); } /* * no error, but do not save buffer either. Break * out of loop ( basically goto out; ). */ break; } /* * Validate symlink */ if ((cnp->cn_flags & LOCKPARENT) && ndp->ni_pathlen == 1) VOP_UNLOCK(ndp->ni_dvp, 0, p); if (!pubflag) { error = EINVAL; goto badlink2; } if (ndp->ni_loopcnt++ >= MAXSYMLINKS) { error = ELOOP; goto badlink2; } if (ndp->ni_pathlen > 1) cp = zalloc(namei_zone); else cp = cnp->cn_pnbuf; aiov.iov_base = cp; aiov.iov_len = MAXPATHLEN; auio.uio_iov = &aiov; auio.uio_iovcnt = 1; auio.uio_offset = 0; auio.uio_rw = UIO_READ; auio.uio_segflg = UIO_SYSSPACE; auio.uio_procp = (struct proc *)0; auio.uio_resid = MAXPATHLEN; error = VOP_READLINK(ndp->ni_vp, &auio, cnp->cn_cred); if (error) { badlink1: if (ndp->ni_pathlen > 1) zfree(namei_zone, cp); badlink2: vrele(ndp->ni_dvp); vput(ndp->ni_vp); ndp->ni_vp = NULL; ndp->ni_dvp = NULL; break; } linklen = MAXPATHLEN - auio.uio_resid; if (linklen == 0) { error = ENOENT; goto badlink1; } if (linklen + ndp->ni_pathlen >= MAXPATHLEN) { error = ENAMETOOLONG; goto badlink1; } /* * Adjust or replace path */ if (ndp->ni_pathlen > 1) { bcopy(ndp->ni_next, cp + linklen, ndp->ni_pathlen); zfree(namei_zone, cnp->cn_pnbuf); cnp->cn_pnbuf = cp; } else cnp->cn_pnbuf[linklen] = '\0'; ndp->ni_pathlen += linklen; /* * Cleanup refs for next loop and check if root directory * should replace current directory. Normally ni_dvp * becomes the new base directory and is cleaned up when * we loop. Explicitly null pointers after invalidation * to clarify operation. */ vput(ndp->ni_vp); ndp->ni_vp = NULL; if (cnp->cn_pnbuf[0] == '/') { vrele(ndp->ni_dvp); ndp->ni_dvp = ndp->ni_rootdir; VREF(ndp->ni_dvp); } ndp->ni_startdir = ndp->ni_dvp; ndp->ni_dvp = NULL; } out: zfree(namei_zone, cnp->cn_pnbuf); return (error); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 2:48:42 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 2F16714D14 for ; Tue, 15 Jun 1999 02:48:39 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id CAA15805; Tue, 15 Jun 1999 02:48:39 -0700 (PDT) (envelope-from dillon) Date: Tue, 15 Jun 1999 02:48:39 -0700 (PDT) From: Matthew Dillon Message-Id: <199906150948.CAA15805@apollo.backplane.com> To: Ville-Pertti Keinonen , current@FreeBSD.ORG Subject: Re: NFS vnode reference issues on server References: <199906150421.VAA14439@apollo.backplane.com.newsgate.clinet.fi> <86d7yxoqj6.fsf@not.demophon.com> <199906150839.BAA15539@apollo.backplane.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here's another dandy: in nfsm_subs.h, the nfsm_reply() macro will happily return(). It really needs to 'goto nfsmout;' instead, or it bypasses all the procedural cleanup. Doh! Talk about leaving things hanging! nfs_serv.c isn't as bad as I thought... there are only a handful of routines which are badly broken, nfsrv_create() being one of them. I'll continue tomorrow. Er, later today. And I'll do some life testing on my test boxes before I post the patches. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 2:57:11 1999 Delivered-To: freebsd-current@freebsd.org Received: from ns.oeno.com (ns.oeno.com [194.100.99.145]) by hub.freebsd.org (Postfix) with SMTP id 3DA1414D11 for ; Tue, 15 Jun 1999 02:57:07 -0700 (PDT) (envelope-from will@ns.oeno.com) Received: (qmail 6741 invoked by uid 1001); 15 Jun 1999 09:57:05 -0000 To: Matthew Dillon Cc: current@freebsd.org Subject: Re: NFS vnode reference issues on server References: <199906150421.VAA14439@apollo.backplane.com.newsgate.clinet.fi> <86d7yxoqj6.fsf@not.demophon.com> <199906150839.BAA15539@apollo.backplane.com.newsgate.clinet.fi> From: Ville-Pertti Keinonen Date: 15 Jun 1999 12:54:47 +0300 In-Reply-To: Matthew Dillon's message of "15 Jun 1999 12:05:53 +0300" Message-ID: <867lp5okk8.fsf@not.demophon.com> Lines: 7 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon writes: > (Anyone who wants to) Take a look at this one and tell me what you think. Looks right, although some changes seem gratuitous (unless they are meant to be performance optimizations). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 6:17:42 1999 Delivered-To: freebsd-current@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 71AE015217; Tue, 15 Jun 1999 06:17:38 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id JAA03470; Tue, 15 Jun 1999 09:17:34 -0400 (EDT) Date: Tue, 15 Jun 1999 09:17:34 -0400 (EDT) From: "Matthew N. Dodd" To: Bret Ford Cc: freebsd-questions@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Problems getting 3C597 up In-Reply-To: <199906042159.OAA17269@uop.cs.uop.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 4 Jun 1999, Bret Ford wrote: > I'm running 4.0 - current from the middle of May, approximately. > I recently acquired an EISA 3COM network adapter that I'm now > trying to install. Here's a snip from my dmesg output: This was fixed in version 1.45 of sys/i386/eisa/eisaconf.c > vx0: <3Com 3C597-TX Network Adapter> at slot 5 on eisa0 > vx0: No I/O space?! > device_probe_and_attach: vx0 attach returned -1 -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 7:26:46 1999 Delivered-To: freebsd-current@freebsd.org Received: from fleming.cs.strath.ac.uk (fleming.cs.strath.ac.uk [130.159.196.126]) by hub.freebsd.org (Postfix) with ESMTP id 7A1C014EFC; Tue, 15 Jun 1999 07:26:37 -0700 (PDT) (envelope-from roger@cs.strath.ac.uk) Received: from muir-10 (roger@muir-10.cs.strath.ac.uk [130.159.148.10]) by fleming.cs.strath.ac.uk (8.8.8/8.8.8) with SMTP id PAA25964 Tue, 15 Jun 1999 15:26:35 +0100 (BST) Message-ID: <3766629A.6231@cs.strath.ac.uk> Date: Tue, 15 Jun 1999 15:26:35 +0100 From: Roger Hardiman Organization: University of Strathclyde X-Mailer: Mozilla 3.04Gold (X11; I; OSF1 V4.0 alpha) MIME-Version: 1.0 To: current@freebsd.org, small@freebsd.org Subject: Announcing PicoBSD 0.44 for -current Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Announcing PicoBSD 0.44 availibility for -current. I have now upgraded FreeBSD 4.x-current to PicoBSD 0.44. This brings it into line with FreeBSD 3.2 which had already been updated to version 0.44 PicoBSD is a small, compact build of FreeBSD that can fit on a single floppy. http://www.freebsd.org/~picobsd -- Roger Hardiman | Telepresence Research Group roger@cs.strath.ac.uk | DMEM, University of Strathclyde tel: 0141 548 2897 | Glasgow, Scotland, G1 1XJ, UK fax: 0141 552 0557 | http://telepresence.dmem.strath.ac.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 7:41:31 1999 Delivered-To: freebsd-current@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id 1F19614EC7 for ; Tue, 15 Jun 1999 07:41:20 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5692) with SMTP id QAA15366; Tue, 15 Jun 1999 16:41:12 +0200 (MET DST) Date: Tue, 15 Jun 1999 16:41:11 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: Roger Hardiman Cc: current@FreeBSD.ORG Subject: Re: Announcing PicoBSD 0.44 for -current In-Reply-To: <3766629A.6231@cs.strath.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Congrats and thanks! Is there also a version available that fits on 720kb floppies :-] Nick On Tue, 15 Jun 1999, Roger Hardiman wrote: > Announcing PicoBSD 0.44 availibility for -current. > > > I have now upgraded FreeBSD 4.x-current to PicoBSD 0.44. > This brings it into line with FreeBSD 3.2 which had > already been updated to version 0.44 > > PicoBSD is a small, compact build of FreeBSD that can > fit on a single floppy. > http://www.freebsd.org/~picobsd > > -- > Roger Hardiman | Telepresence Research Group > roger@cs.strath.ac.uk | DMEM, University of Strathclyde > tel: 0141 548 2897 | Glasgow, Scotland, G1 1XJ, UK > fax: 0141 552 0557 | http://telepresence.dmem.strath.ac.uk > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 7:56:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from bsd.mbp.ee (bsd.mbp.ee [194.204.12.74]) by hub.freebsd.org (Postfix) with ESMTP id 21C30155CC for ; Tue, 15 Jun 1999 07:55:09 -0700 (PDT) (envelope-from mauri@aripaev.ee) Received: from lant.mbp.ee (lant.mbp.ee [194.204.12.41]) by bsd.mbp.ee (8.9.3/8.9.3) with ESMTP id RAA47943 for ; Tue, 15 Jun 1999 17:55:05 +0300 (EEST) (envelope-from mauri@aripaev.ee) Received: by lant.mbp.ee with Internet Mail Service (5.5.2232.9) id ; Tue, 15 Jun 1999 17:55:40 +0300 Message-ID: <554419C71610D211B3F808003636280213B0DE@lant.mbp.ee> From: Lauri Laupmaa To: "'current@freebsd.org'" Subject: fresh -STABLE & CCD Date: Tue, 15 Jun 1999 17:55:39 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Todays -STABLE works ok without CCD, but whenever I add pseudo-device = ccd 4 I get page fault while in kernel mode... current process idle Any ideas ? ______________ Lauri Laupmaa =C4rip=E4ev mauri@mbp.ee Ph. +372 66 70 369 +372 50 13 369 Fx. +372 66 70 165 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 9:55:14 1999 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 9C42315335; Tue, 15 Jun 1999 09:55:10 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id JAA62287; Tue, 15 Jun 1999 09:55:07 -0700 (PDT) (envelope-from obrien) Message-ID: <19990615095507.A53176@nuxi.com> Date: Tue, 15 Jun 1999 09:55:07 -0700 From: "David O'Brien" To: "Joseph T. Klein" Cc: current@FreeBSD.ORG, questions@FreeBSD.ORG Subject: Re: Real Producer and FreeBSD Reply-To: obrien@NUXI.com References: <3761DD82.B72DCAA0@titania.net> <3761EF1E.BCB3C092@newsguy.com> <3762960B.7D723FB6@titania.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <3762960B.7D723FB6@titania.net>; from Joseph T. Klein on Sat, Jun 12, 1999 at 12:16:59PM -0500 X-Operating-System: FreeBSD 3.2-BETA Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > encoding of Real Audio streams. I would prefer to run it under FreeBSD > but am having problems related to its willingness to play with > libc6 and glibstdc++2.8. Huh? ``glibstdc++2.8'' is a FreeBSD binary. When you run a Linux binary, you will never use this library. Maybe if you posted the errors you get when you try to run Real Producer we can help you figure out what is wrong with your configuration. -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 10:34:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from aeolus.conio.net (ci221559-a.grnvle1.sc.home.com [24.4.122.122]) by hub.freebsd.org (Postfix) with SMTP id D2ADE14C18 for ; Tue, 15 Jun 1999 10:34:27 -0700 (PDT) (envelope-from sam@conio.net) Received: (qmail 3425 invoked from network); 15 Jun 1999 17:36:56 -0000 Received: from ci221559-b.grnvle1.sc.home.com (HELO thanatos) (24.4.122.130) by ci221559-a.grnvle1.sc.home.com with SMTP; 15 Jun 1999 17:36:56 -0000 From: "Sam Stephenson" To: , Subject: 'w' patch Date: Tue, 15 Jun 1999 13:38:29 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01BEB734.5AA5A4A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0000_01BEB734.5AA5A4A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit There seem to be two problems (not even problems; more like annoyances) that exist in the 'w' command, both which involve unnecessary spacing that limits the size of the WHAT field. I have attached a patch to /usr/src/usr.bin/w/w.c which corrects the following: - The size of the USER field is now dynamically allocated as the length of the longest username, with a minimum of 5 spaces. In FreeBSD 2.2.x and lower, before long usernames existed, the field size was 8. It was enlarged to 16 to provide long username support, but on systems with shorter usernames, the wasted space can be bothersome. - UT_LINESIZE is redefined to 3; it was originally 5 because 'who' output shows the entire device name (e.g. ttyp0). Since 'w' only shows the 'p0' part, there are two unnecessary spaces. Please have a look at this patch, and consider implementing it into the source tree. --Sam Stephenson sam@conio.net ------=_NextPart_000_0000_01BEB734.5AA5A4A0 Content-Type: application/octet-stream; name="w.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="w.patch" 104a105,114=0A= > * UT_LINESIZE is 5 for who output, because the entire terminal device = name=0A= > * is shown (e.g. ttyp0). Since we only show the 'p0' in w, we'll = redefine=0A= > * this to 3 to save space.=0A= > */=0A= > #ifdef UT_LINESIZE=0A= > #undef UT_LINESIZE=0A= > #endif=0A= > #define UT_LINESIZE 3=0A= > =0A= > /*=0A= 138c148=0A= < int ch, i, nentries, nusers, wcmd, longidle;=0A= ---=0A= > int ch, i, nentries, nusers, wcmd, longidle, maxnamelen=3D5;=0A= 217a228,238=0A= > =0A= > /*=0A= > * Calculate the maximum number of spaces needed for=0A= > * each username. Previously 16; in 2.2.x and lower,=0A= > * when long usernames did not exist, 8 spaces were=0A= > * used. To avoid wasted space we will now do this=0A= > * dynamically.=0A= > */=0A= > if (strlen(utmp.ut_name) > maxnamelen)=0A= > maxnamelen =3D strlen(utmp.ut_name);=0A= > =0A= 252c273=0A= < #define WUSED (UT_NAMESIZE + UT_LINESIZE + UT_HOSTSIZE + \=0A= ---=0A= > #define WUSED (maxnamelen + UT_LINESIZE + UT_HOSTSIZE + \=0A= 255c276=0A= < UT_NAMESIZE, UT_NAMESIZE, HEADER_USER,=0A= ---=0A= > maxnamelen, maxnamelen, HEADER_USER,=0A= 382c403=0A= < UT_NAMESIZE, UT_NAMESIZE, ep->utmp.ut_name,=0A= ---=0A= > maxnamelen, maxnamelen, ep->utmp.ut_name,=0A= ------=_NextPart_000_0000_01BEB734.5AA5A4A0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 10:35:55 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id DDE03153DB for ; Tue, 15 Jun 1999 10:35:53 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA19577; Tue, 15 Jun 1999 10:34:32 -0700 (PDT) (envelope-from dillon) Date: Tue, 15 Jun 1999 10:34:32 -0700 (PDT) From: Matthew Dillon Message-Id: <199906151734.KAA19577@apollo.backplane.com> To: Ville-Pertti Keinonen Cc: current@freebsd.org Subject: Re: NFS vnode reference issues on server References: <199906150421.VAA14439@apollo.backplane.com.newsgate.clinet.fi> <86d7yxoqj6.fsf@not.demophon.com> <199906150839.BAA15539@apollo.backplane.com.newsgate.clinet.fi> <867lp5okk8.fsf@not.demophon.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Matthew Dillon writes: : :> (Anyone who wants to) Take a look at this one and tell me what you think. : :Looks right, although some changes seem gratuitous (unless they are :meant to be performance optimizations). I always insert a few gratuitous changes, just to annoy core. Sorry, I couldn't help it! :-) just kidding. I usually do code readability cleanups when I make involved changes. Sometimes people get too fancy when they code, which is what creates half of these bugs in the first place. Think of it as an investment in the future. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 10:49:12 1999 Delivered-To: freebsd-current@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id 3193D14FBB for ; Tue, 15 Jun 1999 10:49:04 -0700 (PDT) (envelope-from cmpnerds@enteract.com) Received: (qmail 84119 invoked from network); 15 Jun 1999 17:49:03 -0000 Received: from adam.enteract.com (cmpnerds@206.54.252.1) by pop3-3.enteract.com with SMTP; 15 Jun 1999 17:49:03 -0000 Date: Tue, 15 Jun 1999 12:49:02 -0500 (CDT) From: cmpnerds To: Daniel O'Connor Cc: freebsd-current@freebsd.org Subject: RE: problem in audio.o?? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1939726044-929468942=:6634" Sender: owner-freebsd-current@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-1939726044-929468942=:6634 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 15 Jun 1999, Daniel O'Connor wrote: > > On 14-Jun-99 cmpnerds wrote: > > Just cvsuped. First Generic Kernel worked. Attemptes to compile > > in sound (non voxware) and got the following error > > Can we get your kernel config file? > > It kind of looks like you didn't remove all the old sound stuff or something > like that. If you want to use Luigi's driver you ONLY need -> > controller pnp0 > device pcm0 [at isa? port ? tty irq XX drq XX flags 0x0 (for ISA)] > > --- > 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 > --0-1939726044-929468942=:6634 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=ELOCIN Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=ELOCIN Iw0KIyBFTE9DSU4gLS0gSk9ITidzIG1hY2hpbmUgd2l0aCBXRC9BSHgvTkNS L0JUeCBmYW1pbHkgZGlza3MNCiMNCiMgRm9yIG1vcmUgaW5mb3JtYXRpb24g cmVhZCB0aGUgaGFuZGJvb2sgcGFydCBTeXN0ZW0gQWRtaW5pc3RyYXRpb24g LT4gDQojIENvbmZpZ3VyaW5nIHRoZSBGcmVlQlNEIEtlcm5lbCAtPiBUaGUg Q29uZmlndXJhdGlvbiBGaWxlLiANCiMgVGhlIGhhbmRib29rIGlzIGF2YWls YWJsZSBpbiAvdXNyL3NoYXJlL2RvYy9oYW5kYm9vayBvciBvbmxpbmUgYXMN CiMgbGF0ZXN0IHZlcnNpb24gZnJvbSB0aGUgRnJlZUJTRCBXb3JsZCBXaWRl IFdlYiBzZXJ2ZXIgDQojIDxVUkw6aHR0cDovL3d3dy5GcmVlQlNELk9SRy8+ DQojDQojIEFuIGV4aGF1c3RpdmUgbGlzdCBvZiBvcHRpb25zIGFuZCBtb3Jl IGRldGFpbGVkIGV4cGxhbmF0aW9ucyBvZiB0aGUgDQojIGRldmljZSBsaW5l cyBpcyBwcmVzZW50IGluIHRoZSAuL0xJTlQgY29uZmlndXJhdGlvbiBmaWxl LiBJZiB5b3UgYXJlIA0KIyBpbiBkb3VidCBhcyB0byB0aGUgcHVycG9zZSBv ciBuZWNlc3NpdHkgb2YgYSBsaW5lLCBjaGVjayBmaXJzdCBpbiBMSU5ULg0K Iw0KIwkkSWQ6IEVMT0NJTix2IDEuMTcyIDE5OTkvMDUvMjEgMDQ6Mzc6MzUg d3BhdWwgRXhwICQNCg0KbWFjaGluZQkJaTM4Ng0KI2NwdQkJSTM4Nl9DUFUN CiNjcHUJCUk0ODZfQ1BVDQojY3B1CQlJNTg2X0NQVQ0KY3B1CQlJNjg2X0NQ VQ0KaWRlbnQJCUVMT0NJTg0KbWF4dXNlcnMJMTI4DQoNCiNtYWtlb3B0aW9u cwlERUJVRz0tZwkJI0J1aWxkIGtlcm5lbCB3aXRoIGdkYigxKSBkZWJ1ZyBz eW1ib2xzDQoNCiNvcHRpb25zCQlNQVRIX0VNVUxBVEUJCSNTdXBwb3J0IGZv ciB4ODcgZW11bGF0aW9uDQpvcHRpb25zCQlJTkVUCQkJI0ludGVyTkVUd29y a2luZw0Kb3B0aW9ucwkJRkZTCQkJI0JlcmtlbGV5IEZhc3QgRmlsZXN5c3Rl bQ0Kb3B0aW9ucwkJRkZTX1JPT1QJCSNGRlMgdXNhYmxlIGFzIHJvb3QgZGV2 aWNlIFtrZWVwIHRoaXMhXQ0Kb3B0aW9ucwkJTUZTCQkJI01lbW9yeSBGaWxl c3lzdGVtDQpvcHRpb25zCQlNRlNfUk9PVAkJI01GUyB1c2FibGUgYXMgcm9v dCBkZXZpY2UsICJNRlMiIHJlcSdlZA0Kb3B0aW9ucwkJTkZTCQkJI05ldHdv cmsgRmlsZXN5c3RlbQ0Kb3B0aW9ucwkJTkZTX1JPT1QJCSNORlMgdXNhYmxl IGFzIHJvb3QgZGV2aWNlLCAiTkZTIiByZXEnZWQNCm9wdGlvbnMJCU1TRE9T RlMJCQkjTVNET1MgRmlsZXN5c3RlbQ0Kb3B0aW9ucwkJQ0Q5NjYwCQkJI0lT TyA5NjYwIEZpbGVzeXN0ZW0NCm9wdGlvbnMJCUNEOTY2MF9ST09UCQkjQ0Qt Uk9NIHVzYWJsZSBhcyByb290LiAiQ0Q5NjYwIiByZXEnZWQNCm9wdGlvbnMJ CVBST0NGUwkJCSNQcm9jZXNzIGZpbGVzeXN0ZW0NCm9wdGlvbnMJCUNPTVBB VF80MwkJI0NvbXBhdGlibGUgd2l0aCBCU0QgNC4zIFtLRUVQIFRISVMhXQ0K b3B0aW9ucwkJU0NTSV9ERUxBWT0xNTAwMAkjQmUgcGVzc2ltaXN0aWMgYWJv dXQgSm9lIFNDU0kgZGV2aWNlDQpvcHRpb25zCQlVQ09OU09MRQkJI0FsbG93 IHVzZXJzIHRvIGdyYWIgdGhlIGNvbnNvbGUNCm9wdGlvbnMJCUZBSUxTQUZF CQkjQmUgY29uc2VydmF0aXZlDQpvcHRpb25zCQlVU0VSQ09ORklHCQkjYm9v dCAtYyBlZGl0b3INCm9wdGlvbnMJCVZJU1VBTF9VU0VSQ09ORklHCSN2aXN1 YWwgYm9vdCAtYyBlZGl0b3INCg0KDQojIFRvIG1ha2UgYW4gU01QIGtlcm5l bCwgdGhlIG5leHQgdHdvIGFyZSBuZWVkZWQNCiNvcHRpb25zCVNNUAkJCSMg U3ltbWV0cmljIE11bHRpUHJvY2Vzc29yIEtlcm5lbA0KI29wdGlvbnMJQVBJ Q19JTwkJCSMgU3ltbWV0cmljIChBUElDKSBJL08NCiMgT3B0aW9uYWxseSB0 aGVzZSBtYXkgbmVlZCB0d2Vha2VkLCAoZGVmYXVsdHMgc2hvd24pOg0KI29w dGlvbnMJTkNQVT0yCQkJIyBudW1iZXIgb2YgQ1BVcw0KI29wdGlvbnMJTkJV Uz00CQkJIyBudW1iZXIgb2YgYnVzc2VzDQojb3B0aW9ucwlOQVBJQz0xCQkJ IyBudW1iZXIgb2YgSU8gQVBJQ3MNCiNvcHRpb25zCU5JTlRSPTI0CQkjIG51 bWJlciBvZiBJTlRzDQoNCmNvbnRyb2xsZXIJaXNhMA0KY29udHJvbGxlcglw bnAwCQkJIyBQblAgc3VwcG9ydCBmb3IgSVNBDQpjb250cm9sbGVyCWVpc2Ew DQpjb250cm9sbGVyCXBjaTANCg0KY29udHJvbGxlcglmZGMwCWF0IGlzYT8g cG9ydCBJT19GRDEgaXJxIDYgZHJxIDINCmRpc2sJCWZkMAlhdCBmZGMwIGRy aXZlIDANCmRpc2sJCWZkMQlhdCBmZGMwIGRyaXZlIDENCg0KY29udHJvbGxl cgl3ZGMwCWF0IGlzYT8gcG9ydCBJT19XRDEgaXJxIDE0DQpkaXNrCQl3ZDAJ YXQgd2RjMCBkcml2ZSAwDQpkaXNrCQl3ZDEJYXQgd2RjMCBkcml2ZSAxDQoN CmNvbnRyb2xsZXIJd2RjMQlhdCBpc2E/IHBvcnQgSU9fV0QyIGlycSAxNQ0K ZGlzawkJd2QyCWF0IHdkYzEgZHJpdmUgMA0KZGlzawkJd2QzCWF0IHdkYzEg ZHJpdmUgMQ0KDQojIEFUQVBJIGRldmljZXMgb24gd2RjPw0KZGV2aWNlCQl3 Y2QwCQkjSURFIENELVJPTQ0KZGV2aWNlCQl3ZmQwCQkjSURFIEZsb3BweSAo ZS5nLiBMUy0xMjApDQpkZXZpY2UJCXdzdDAJCSNJREUgVGFwZSAoZS5nLiBU cmF2YW4pDQoNCiNBTEwgTVkgQUREUw0KI2NvbnRyb2xsZXIJc25kMA0KZGV2 aWNlCQlwY20wCWF0IGlzYT8gcG9ydCAweDUyYyBpcnEgNSBkcnEgMSBmbGFn cyAweDE1DQpvcHRpb25zCQlEREINCm9wdGlvbnMJCVNPRlRVUERBVEVTDQpw c2V1ZG8tZGV2aWNlCXNucAk1DQpwc2V1ZG8tZGV2aWNlCXNwZWFrZXINCg0K I0VuZCBwZiBNWSBhZGRzDQoNCiMgQSBzaW5nbGUgZW50cnkgZm9yIGFueSBv ZiB0aGVzZSBjb250cm9sbGVycyAobmNyLCBhaGIsIGFoYykgaXMNCiMgc3Vm ZmljaWVudCBmb3IgYW55IG51bWJlciBvZiBpbnN0YWxsZWQgZGV2aWNlcy4N CmNvbnRyb2xsZXIJbmNyMA0KY29udHJvbGxlcglhaGIwDQpjb250cm9sbGVy CWFoYzANCmNvbnRyb2xsZXIJaXNwMA0KDQojIFRoaXMgY29udHJvbGxlciBv ZmZlcnMgYSBudW1iZXIgb2YgY29uZmlndXJhdGlvbiBvcHRpb25zLCB0b28g bWFueSB0bw0KIyBkb2N1bWVudCBoZXJlICAtIHNlZSB0aGUgTElOVCBmaWxl IGluIHRoaXMgZGlyZWN0b3J5IGFuZCBsb29rIHVwIHRoZQ0KIyBkcHQwIGVu dHJ5IHRoZXJlIGZvciBtdWNoIGZ1bGxlciBkb2N1bWVudGF0aW9uIG9uIHRo aXMuDQpjb250cm9sbGVyICAgICAgZHB0MA0KDQpjb250cm9sbGVyCWFkdjAJ YXQgaXNhPyBwb3J0ID8gaXJxID8NCmNvbnRyb2xsZXIJYWR3MA0KY29udHJv bGxlcglidDAJYXQgaXNhPyBwb3J0ID8gaXJxID8NCmNvbnRyb2xsZXIJYWhh MAlhdCBpc2E/IHBvcnQgPyBpcnEgPw0KDQpjb250cm9sbGVyCXNjYnVzMA0K DQpkZXZpY2UJCWRhMAkjT25seSBuZWVkIG9uZSBvZiB0aGVzZSwgdGhlIGNv ZGUgZHluYW1pY2FsbHkgZ3Jvd3MNCmRldmljZQkJc2EwDQpkZXZpY2UJCXBh c3MwDQpkZXZpY2UJCWNkMA0KDQpkZXZpY2UJCXd0MAlhdCBpc2E/IHBvcnQg MHgzMDAgaXJxIDUgZHJxIDENCmRldmljZQkJbWNkMAlhdCBpc2E/IHBvcnQg MHgzMDAgaXJxIDEwDQoNCmNvbnRyb2xsZXIJbWF0Y2QwCWF0IGlzYT8gcG9y dCAweDIzMA0KDQpkZXZpY2UJCXNjZDAJYXQgaXNhPyBwb3J0IDB4MjMwDQoN CiMgYXRrYmRjMCBjb250cm9scyBib3RoIHRoZSBrZXlib2FyZCBhbmQgdGhl IFBTLzIgbW91c2UNCmNvbnRyb2xsZXIJYXRrYmRjMAlhdCBpc2E/IHBvcnQg SU9fS0JEDQpkZXZpY2UJCWF0a2JkMAlhdCBhdGtiZGM/IGlycSAxDQpkZXZp Y2UJCXBzbTAJYXQgYXRrYmRjPyBpcnEgMTINCg0KZGV2aWNlCQl2Z2EwCWF0 IGlzYT8gcG9ydCA/IGNvbmZsaWN0cw0KDQojIHNwbGFzaCBzY3JlZW4vc2Ny ZWVuIHNhdmVyDQpwc2V1ZG8tZGV2aWNlCXNwbGFzaA0KDQojIHN5c2NvbnMg aXMgdGhlIGRlZmF1bHQgY29uc29sZSBkcml2ZXIsIHJlc2VtYmxpbmcgYW4g U0NPIGNvbnNvbGUNCmRldmljZQkJc2MwCWF0IGlzYT8NCg0KIyBFbmFibGUg dGhpcyBhbmQgUENWVF9GUkVFQlNEIGZvciBwY3Z0IHZ0MjIwIGNvbXBhdGli bGUgY29uc29sZSBkcml2ZXINCiNkZXZpY2UJCXZ0MAlhdCBpc2E/DQojb3B0 aW9ucwkJWFNFUlZFUgkJCSMgc3VwcG9ydCBmb3IgWCBzZXJ2ZXINCiNvcHRp b25zCQlGQVRfQ1VSU09SCQkjIHN0YXJ0IHdpdGggYmxvY2sgY3Vyc29yDQoj IElmIHlvdSBoYXZlIGEgVGhpbmtQQUQsIHVuY29tbWVudCB0aGlzIGFsb25n IHdpdGggdGhlIHJlc3Qgb2YgdGhlIFBDVlQgbGluZXMNCiNvcHRpb25zCQlQ Q1ZUX1NDQU5TRVQ9MgkJIyBJQk0ga2V5Ym9hcmRzIGFyZSBub24tc3RkDQoN CmRldmljZQkJbnB4MAlhdCBuZXh1cz8gcG9ydCBJT19OUFggaXJxIDEzDQoN CiMNCiMgTGFwdG9wIHN1cHBvcnQgKHNlZSBMSU5UIGZvciBtb3JlIG9wdGlv bnMpDQojDQpkZXZpY2UJCWFwbTAgICAgYXQgbmV4dXM/IGRpc2FibGUgZmxh Z3MgMHgzMSAjIEFkdmFuY2VkIFBvd2VyIE1hbmFnZW1lbnQNCg0KIyBQQ0NB UkQgKFBDTUNJQSkgc3VwcG9ydA0KI2NvbnRyb2xsZXIJY2FyZDANCiNkZXZp Y2UJCXBjaWMwCWF0IGNhcmQ/DQojZGV2aWNlCQlwY2ljMQlhdCBjYXJkPw0K DQpkZXZpY2UJCXNpbzAJYXQgaXNhPyBwb3J0IElPX0NPTTEgZmxhZ3MgMHgx MCBpcnEgNA0KZGV2aWNlCQlzaW8xCWF0IGlzYT8gcG9ydCBJT19DT00yIGly cSAzDQpkZXZpY2UJCXNpbzIJYXQgaXNhPyBkaXNhYmxlIHBvcnQgSU9fQ09N MyBpcnEgNQ0KZGV2aWNlCQlzaW8zCWF0IGlzYT8gZGlzYWJsZSBwb3J0IElP X0NPTTQgaXJxIDkNCg0KIyBQYXJhbGxlbCBwb3J0DQpkZXZpY2UJCXBwYzAJ YXQgaXNhPyBwb3J0PyBmbGFncyAweDQwIGlycSA3DQpjb250cm9sbGVyCXBw YnVzMA0KZGV2aWNlCQlscHQwCWF0IHBwYnVzPw0KZGV2aWNlCQlwbGlwMAlh dCBwcGJ1cz8NCmRldmljZQkJcHBpMAlhdCBwcGJ1cz8NCiNjb250cm9sbGVy CXZwbzAJYXQgcHBidXM/DQoNCiMNCiMgVGhlIGZvbGxvd2luZyBFdGhlcm5l dCBOSUNzIGFyZSBhbGwgUENJIGRldmljZXMuDQojDQpkZXZpY2UgYWwwCQkj IEFETXRlayBBTDk4MSAoYGBDb21ldCcnKQ0KZGV2aWNlIGF4MAkJIyBBU0lY IEFYODgxNDBBDQpkZXZpY2UgZGUwCQkjIERFQy9JbnRlbCBEQzIxeDR4IChg YFR1bGlwJycpDQpkZXZpY2UgZnhwMAkJIyBJbnRlbCBFdGhlckV4cHJlc3Mg UFJPLzEwMEIgKDgyNTU3LCA4MjU1OCkNCmRldmljZSBteDAJCSMgTWFjcm9u aXggOTg3MTMvOTg3MTUvOTg3MjUgKGBgUE1BQycnKQ0KZGV2aWNlIHBuMAkJ IyBMaXRlLU9uIDgyYzE2OC84MmMxNjkgKGBgUE5JQycnKQ0KZGV2aWNlIHJs MAkJIyBSZWFsVGVrIDgxMjkvODEzOQ0KZGV2aWNlIHRsMAkJIyBUZXhhcyBJ bnN0cnVtZW50cyBUaHVuZGVyTEFODQpkZXZpY2UgdHgwCQkjIFNNQyA5NDMy VFggKDgzYzE3MCBgYEVQSUMnJykNCmRldmljZSB2cjAJCSMgVklBIFJoaW5l LCBSaGluZSBJSQ0KZGV2aWNlIHZ4MAkJIyAzQ29tIDNjNTkwLCAzYzU5NSAo YGBWb3J0ZXgnJykNCmRldmljZSB3YjAJCSMgV2luYm9uZCBXODlDODQwRg0K ZGV2aWNlIHhsMAkJIyAzQ29tIDNjOTB4IChgYEJvb21lcmFuZycnLCBgYEN5 Y2xvbmUnJykNCg0KIyBPcmRlciBpcyBpbXBvcnRhbnQgaGVyZSBkdWUgdG8g aW50cnVzaXZlIHByb2JlcywgZG8gKm5vdCogYWxwaGFiZXRpemUNCiMgdGhp cyBsaXN0IG9mIG5ldHdvcmsgaW50ZXJmYWNlcyB1bnRpbCB0aGUgcHJvYmVz IGhhdmUgYmVlbiBmaXhlZC4NCiMgUmlnaHQgbm93IGl0IGFwcGVhcnMgdGhh dCB0aGUgaWUwIG11c3QgYmUgcHJvYmVkIGJlZm9yZSBlcDAuIFNlZQ0KIyBy ZXZpc2lvbiAxLjIwIG9mIHRoaXMgZmlsZS4NCmRldmljZSBlZDAgYXQgaXNh PyBwb3J0IDB4MjgwIGlycSAxMCBpb21lbSAweGQ4MDAwDQpkZXZpY2UgaWUw IGF0IGlzYT8gcG9ydCAweDMwMCBpcnEgMTAgaW9tZW0gMHhkMDAwMA0KZGV2 aWNlIGVwMCBhdCBpc2E/IHBvcnQgMHgzMDAgaXJxIDEwDQpkZXZpY2UgZXgw IGF0IGlzYT8gcG9ydD8gaXJxPw0KZGV2aWNlIGZlMCBhdCBpc2E/IHBvcnQg MHgzMDAgaXJxID8NCmRldmljZSBsZTAgYXQgaXNhPyBwb3J0IDB4MzAwIGly cSA1IGlvbWVtIDB4ZDAwMDANCmRldmljZSBsbmMwIGF0IGlzYT8gcG9ydCAw eDI4MCBpcnEgMTAgZHJxIDANCmRldmljZSB4ZTAgYXQgaXNhPyBwb3J0PyBp cnEgPw0KZGV2aWNlIHplMCBhdCBpc2E/IHBvcnQgMHgzMDAgaXJxIDEwIGlv bWVtIDB4ZDgwMDANCmRldmljZSB6cDAgYXQgaXNhPyBwb3J0IDB4MzAwIGly cSAxMCBpb21lbSAweGQ4MDAwDQpkZXZpY2UgY3MwIGF0IGlzYT8gcG9ydCAw eDMwMCBpcnEgPw0KDQpwc2V1ZG8tZGV2aWNlCWxvb3ANCnBzZXVkby1kZXZp Y2UJZXRoZXINCnBzZXVkby1kZXZpY2UJc2wJMQ0KcHNldWRvLWRldmljZQlw cHAJMQ0KcHNldWRvLWRldmljZQl0dW4JMQ0KcHNldWRvLWRldmljZQlwdHkJ MjU2DQpwc2V1ZG8tZGV2aWNlCWd6aXAJCSMgRXhlYyBnemlwcGVkIGEub3V0 J3MNCg0KIyBLVFJBQ0UgZW5hYmxlcyB0aGUgc3lzdGVtLWNhbGwgdHJhY2lu ZyBmYWNpbGl0eSBrdHJhY2UoMikuDQojIFRoaXMgYWRkcyA0IEtCIGJsb2F0 IHRvIHlvdXIga2VybmVsLCBhbmQgc2xpZ2h0bHkgaW5jcmVhc2VzDQojIHRo ZSBjb3N0cyBvZiBlYWNoIHN5c2NhbGwuDQpvcHRpb25zCQlLVFJBQ0UJCSNr ZXJuZWwgdHJhY2luZw0KDQojIFRoaXMgcHJvdmlkZXMgc3VwcG9ydCBmb3Ig U3lzdGVtIFYgc2hhcmVkIG1lbW9yeSBhbmQgbWVzc2FnZSBxdWV1ZXMuDQoj DQpvcHRpb25zICAgICAgICAgU1lTVlNITQ0Kb3B0aW9ucyAgICAgICAgIFNZ U1ZNU0cNCm9wdGlvbnMgICAgICAgICBTWVNWU0VNDQoNCiMgIFRoZSBgYnBm aWx0ZXInIHBzZXVkby1kZXZpY2UgZW5hYmxlcyB0aGUgQmVya2VsZXkgUGFj a2V0IEZpbHRlci4gIEJlDQojICBhd2FyZSBvZiB0aGUgbGVnYWwgYW5kIGFk bWluaXN0cmF0aXZlIGNvbnNlcXVlbmNlcyBvZiBlbmFibGluZyB0aGlzDQoj ICBvcHRpb24uICBUaGUgbnVtYmVyIG9mIGRldmljZXMgZGV0ZXJtaW5lcyB0 aGUgbWF4aW11bSBudW1iZXIgb2YNCiMgIHNpbXVsdGFuZW91cyBCUEYgY2xp ZW50cyBwcm9ncmFtcyBydW5uYWJsZS4NCiNwc2V1ZG8tZGV2aWNlCWJwZmls dGVyIDQJI0JlcmtlbGV5IHBhY2tldCBmaWx0ZXINCg0KIyBVU0Igc3VwcG9y dA0KY29udHJvbGxlcgl1aGNpMA0KY29udHJvbGxlcglvaGNpMA0KY29udHJv bGxlcgl1c2IwDQojDQojZGV2aWNlCQl1Z2VuMA0KI2RldmljZQkJdWhpZDAN CiNkZXZpY2UJCXVrYmQwDQojZGV2aWNlCQl1bHB0MA0KI2NvbnRyb2xsZXIJ dW1hc3MwDQojZGV2aWNlCQl1bXMwDQo= --0-1939726044-929468942=:6634-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 11: 9: 1 1999 Delivered-To: freebsd-current@freebsd.org Received: from ozz.etrust.ru (ozz.etrust.ru [195.2.84.116]) by hub.freebsd.org (Postfix) with ESMTP id 78D9F1507A for ; Tue, 15 Jun 1999 11:08:49 -0700 (PDT) (envelope-from osa@etrust.ru) Received: from localhost (localhost [127.0.0.1]) by ozz.etrust.ru (Postfix) with ESMTP id AC3D23D2; Tue, 15 Jun 1999 22:08:44 +0400 (MSD) Date: Tue, 15 Jun 1999 22:08:44 +0400 (MSD) From: Osokin Sergey To: Mark Newton Cc: naddy@mips.rhein-neckar.de, freebsd-current@FreeBSD.ORG Subject: Re: ES1370 Sound problems In-Reply-To: <19990614204723.A331@norn.ca.eu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > > > Does yours do soundblaster emulation, and therefore come up with the > > > > soundblaster driver instead? > > > > > > es0: irq 5 at device 9.0 on pci0 > > > pcm0: using I/O space register mapping at 0xd800 > > > In my kernel conf I have a: > > > device pcm0 > > > > Hmm - Until I patched it this morning, I got: > > > > es0: irq 11 at device 8.0 on pc > > pcm0: using I/O space register mapping at 0xe400 > > [ ... ] > > isa_compat: didn't get ports for pcm > > > > if I explicitly mentioned ports and IRQs, and the same messages but without > > the isa_compat message if I didn't. /dev/sndstat contained: > > > > FreeBSD Audio Driver (981002) Jun 11 1999 21:12:33 > > Installed devices: > > > > ... and nothing else, which wasn't particularly encouraging either. > Some stranges. After today CVSup i recompile my kernel with SB 128 PCI. after reboot $ dmesg | grep pcm pcm0: irq 5 at device 11.0 on pci0 pcm0: using I/O space register mapping at 0xe800 but i have some stranges with playing .wav files: parts of some.wav 1 2 3 4 5 6 7 8 9 10 pcm0 play it is following: 2 3 4 5 6 7 8 9 10 1 What does it mean? Rgdz, Osokin Sergey aka oZZ, osa@etrust.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 12:17:28 1999 Delivered-To: freebsd-current@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id DCE6614CE0 for ; Tue, 15 Jun 1999 12:17:22 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: (qmail 17712 invoked from network); 15 Jun 1999 19:17:21 -0000 Received: from shell-1.enteract.com (dscheidt@207.229.143.40) by pop3-3.enteract.com with SMTP; 15 Jun 1999 19:17:21 -0000 Received: from localhost (dscheidt@localhost) by shell-1.enteract.com (8.9.3/8.9.2) with SMTP id OAA90191; Tue, 15 Jun 1999 14:17:20 -0500 (CDT) (envelope-from dscheidt@enteract.com) X-Authentication-Warning: shell-1.enteract.com: dscheidt owned process doing -bs Date: Tue, 15 Jun 1999 14:17:20 -0500 (CDT) From: David Scheidt To: Sam Stephenson Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: 'w' patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 15 Jun 1999, Sam Stephenson wrote: > There seem to be two problems (not even problems; more like annoyances) that > exist in the 'w' command, both which involve unnecessary spacing that limits > the size of the WHAT field. I have attached a patch to > /usr/src/usr.bin/w/w.c which corrects the following: I applied this to -CURRENT. The USER bit works correctly. IDLE and WHAT are broken, it appears. rally3# ./w 12:56PM up 5 days, 5:08, 16 users, load averages: 0.19, 0.04, 0.01 USER TTY FROM LOGIN@ IDLE WHAT dms v0 - Thu07AM 21 - dms p0 :0.0 12:32PM 21 - dms p1 :0.0 Thu07AM 21 - dms p2 :0.0 Thu07AM 21 - dms p3 :0.0 Thu09AM 21 - dms p4 :0.0 Thu04PM 21 - dms p5 - Mon02PM 21 - dms p6 :0.0 Fri01PM 21 - dms p7 :0.0 Mon10AM 21 - dms p8 :0.0 Mon11AM 21 - dms p9 :0.0 Mon11AM 21 - dms pa :0.0 7:41AM 21 - root pb :0.0 12:40PM 21 - jabba pc :0.0 12:53PM 21 - jabba1 pd :0.0 12:53PM 21 - jabba12345 pe :0.0 12:56PM 21 - One minor nit: I think two spaces between USER and TTY looks better. David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 12:52:48 1999 Delivered-To: freebsd-current@freebsd.org Received: from aeolus.conio.net (ci221559-a.grnvle1.sc.home.com [24.4.122.122]) by hub.freebsd.org (Postfix) with SMTP id A592E14F4B for ; Tue, 15 Jun 1999 12:52:44 -0700 (PDT) (envelope-from sam@conio.net) Received: (qmail 3638 invoked by uid 1001); 15 Jun 1999 19:55:17 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 15 Jun 1999 19:55:17 -0000 Date: Tue, 15 Jun 1999 15:55:17 -0400 (EDT) From: Sam Stephenson X-Sender: sam@aeolus To: David Scheidt Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: 'w' patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm using 3.2-STABLE. Could that be the problem? --Sam Stephenson sam@conio.net On Tue, 15 Jun 1999, David Scheidt wrote: > On Tue, 15 Jun 1999, Sam Stephenson wrote: > > > There seem to be two problems (not even problems; more like annoyances) that > > exist in the 'w' command, both which involve unnecessary spacing that limits > > the size of the WHAT field. I have attached a patch to > > /usr/src/usr.bin/w/w.c which corrects the following: > > I applied this to -CURRENT. The USER bit works correctly. IDLE and WHAT > are broken, it appears. > > rally3# ./w > 12:56PM up 5 days, 5:08, 16 users, load averages: 0.19, 0.04, 0.01 > USER TTY FROM LOGIN@ IDLE WHAT > dms v0 - Thu07AM 21 - > dms p0 :0.0 12:32PM 21 - > dms p1 :0.0 Thu07AM 21 - > dms p2 :0.0 Thu07AM 21 - > dms p3 :0.0 Thu09AM 21 - > dms p4 :0.0 Thu04PM 21 - > dms p5 - Mon02PM 21 - > dms p6 :0.0 Fri01PM 21 - > dms p7 :0.0 Mon10AM 21 - > dms p8 :0.0 Mon11AM 21 - > dms p9 :0.0 Mon11AM 21 - > dms pa :0.0 7:41AM 21 - > root pb :0.0 12:40PM 21 - > jabba pc :0.0 12:53PM 21 - > jabba1 pd :0.0 12:53PM 21 - > jabba12345 pe :0.0 12:56PM 21 - > > One minor nit: I think two spaces between USER and TTY looks better. > > David > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 14:17:21 1999 Delivered-To: freebsd-current@freebsd.org Received: from aeolus.conio.net (ci221559-a.grnvle1.sc.home.com [24.4.122.122]) by hub.freebsd.org (Postfix) with SMTP id 2AA93156A0 for ; Tue, 15 Jun 1999 14:17:14 -0700 (PDT) (envelope-from sam@conio.net) Received: (qmail 69896 invoked by uid 1001); 15 Jun 1999 21:19:47 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 15 Jun 1999 21:19:47 -0000 Date: Tue, 15 Jun 1999 17:19:47 -0400 (EDT) From: Sam Stephenson X-Sender: sam@aeolus To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: w.c patch for -CURRENT Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-140741642-929481587=:66181" Sender: owner-freebsd-current@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-140741642-929481587=:66181 Content-Type: TEXT/PLAIN; charset=US-ASCII Here's my w.c patch for -CURRENT. Sorry about the confusion. --Sam Stephenson sam@conio.net --0-140741642-929481587=:66181 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="w.patch.current" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="w.patch.current" MTA0YTEwNSwxMTQNCj4gICogVVRfTElORVNJWkUgaXMgNSBmb3Igd2hvIG91 dHB1dCwgYmVjYXVzZSB0aGUgZW50aXJlIHRlcm1pbmFsIGRldmljZSBuYW1l DQo+ICAqIGlzIHNob3duIChlLmcuIHR0eXAwKS4gIFNpbmNlIHdlIG9ubHkg c2hvdyB0aGUgJ3AwJyBpbiB3LCB3ZSdsbCByZWRlZmluZQ0KPiAgKiB0aGlz IHRvIDMgdG8gc2F2ZSBzcGFjZS4NCj4gICovDQo+ICNpZmRlZiBVVF9MSU5F U0laRQ0KPiAjdW5kZWYgVVRfTElORVNJWkUNCj4gI2VuZGlmDQo+ICNkZWZp bmUgVVRfTElORVNJWkUgMw0KPiANCj4gLyoNCjEzNmMxNDYNCjwgCWludCBj aCwgaSwgbmVudHJpZXMsIG51c2Vycywgd2NtZCwgbG9uZ2lkbGU7DQotLS0N Cj4gCWludCBjaCwgaSwgbmVudHJpZXMsIG51c2Vycywgd2NtZCwgbG9uZ2lk bGUsIG1heG5hbWVsZW49NTsNCjIxNWEyMjYsMjM2DQo+IAkJCQ0KPiAJCS8q DQo+IAkJICogQ2FsY3VsYXRlIHRoZSBtYXhtaW11bSBudW1iZXIgb2Ygc3Bh Y2VzIG5lZWRlZCBmb3INCj4gCQkgKiBlYWNoIHVzZXJuYW1lLiAgUHJldmlv dXNseSAxNjsgaW4gMi4yLnggYW5kIGxvd2VyLA0KPiAJCSAqIHdoZW4gbG9u ZyB1c2VybmFtZXMgZGlkIG5vdCBleGlzdCwgOCBzcGFjZXMgd2VyZQ0KPiAJ CSAqIHVzZWQuICBUbyBhdm9pZCB3YXN0ZWQgc3BhY2Ugd2Ugd2lsbCBub3cg ZG8gdGhpcw0KPiAJCSAqIGR5bmFtaWNhbGx5Lg0KPiAJCSAqLw0KPiAJCWlm IChzdHJsZW4odXRtcC51dF9uYW1lKSA+IG1heG5hbWVsZW4pDQo+IAkJCW1h eG5hbWVsZW4gPSBzdHJsZW4odXRtcC51dF9uYW1lKTsNCj4gCQkJDQoyNTBj MjcxDQo8ICNkZWZpbmUgV1VTRUQgIChVVF9OQU1FU0laRSArIFVUX0xJTkVT SVpFICsgVVRfSE9TVFNJWkUgKyBcDQotLS0NCj4gI2RlZmluZSBXVVNFRCAg KG1heG5hbWVsZW4gKyBVVF9MSU5FU0laRSArIFVUX0hPU1RTSVpFICsgXA0K MjUzYzI3NA0KPCAJCQkJVVRfTkFNRVNJWkUsIFVUX05BTUVTSVpFLCBIRUFE RVJfVVNFUiwNCi0tLQ0KPiAJCQkJbWF4bmFtZWxlbiwgbWF4bmFtZWxlbiwg SEVBREVSX1VTRVIsDQozODNjNDA0DQo8IAkJICAgIFVUX05BTUVTSVpFLCBV VF9OQU1FU0laRSwgZXAtPnV0bXAudXRfbmFtZSwNCi0tLQ0KPiAJCSAgICBt YXhuYW1lbGVuLCBtYXhuYW1lbGVuLCBlcC0+dXRtcC51dF9uYW1lLA0K --0-140741642-929481587=:66181-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 14:29:45 1999 Delivered-To: freebsd-current@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id BE89A1537D for ; Tue, 15 Jun 1999 14:29:34 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 79828 invoked by uid 1001); 15 Jun 1999 21:29:32 +0000 (GMT) To: sam@conio.net Cc: dscheidt@enteract.com, freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: 'w' patch From: sthaug@nethelp.no In-Reply-To: Your message of "Tue, 15 Jun 1999 15:55:17 -0400 (EDT)" References: X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 15 Jun 1999 23:29:32 +0200 Message-ID: <79826.929482172@verdi.nethelp.no> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm using 3.2-STABLE. Could that be the problem? Yes. w.c is different in current. At least one known bug has been fixed, which in 3.2-STABLE allows the LOGIN@ time to be partly overwritten. I use w.c from -current on all my 3.2-STABLE systems. Wish the -current version was backported to 3.2-STABLE. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 14:31:44 1999 Delivered-To: freebsd-current@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id BB1EA15627 for ; Tue, 15 Jun 1999 14:31:38 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: (qmail 68050 invoked from network); 15 Jun 1999 21:31:37 -0000 Received: from shell-1.enteract.com (dscheidt@207.229.143.40) by pop3-3.enteract.com with SMTP; 15 Jun 1999 21:31:37 -0000 Received: from localhost (dscheidt@localhost) by shell-1.enteract.com (8.9.3/8.9.2) with SMTP id QAA91001; Tue, 15 Jun 1999 16:31:37 -0500 (CDT) (envelope-from dscheidt@enteract.com) X-Authentication-Warning: shell-1.enteract.com: dscheidt owned process doing -bs Date: Tue, 15 Jun 1999 16:31:36 -0500 (CDT) From: David Scheidt To: Sam Stephenson Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: w.c patch for -CURRENT In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 15 Jun 1999, Sam Stephenson wrote: > Here's my w.c patch for -CURRENT. Sorry about the confusion. > > --Sam Stephenson > sam@conio.net My machine, which is -CURRENT as of thursday, produces this bash-2.02$ /usr/obj/usr/src/usr.bin/w/w 3:27PM up 5 days, 7:40, 16 users, load averages: 0.02, 0.02, 0.00 USER TTY FROM LOGIN@ IDLE WHAT dms v0 - Thu07AM 2:17 - dms p0 :0.0 12:32PM 2:17 - dms p1 :0.0 Thu07AM 2:17 - dms p2 :0.0 Thu07AM 2:17 - dms p3 :0.0 Thu09AM 2:17 - dms p4 :0.0 Thu04PM 2:17 - dms p5 - Mon02PM 2:17 - dms p6 :0.0 Fri01PM 2:17 - dms p7 :0.0 Mon10AM 2:17 - dms p8 :0.0 Mon11AM 2:17 - dms p9 :0.0 Mon11AM 2:17 - dms pa :0.0 7:41AM 2:17 - root pb :0.0 12:40PM 2:17 - jabba pc :0.0 12:53PM 2:17 - jabba1 pd :0.0 12:53PM 2:17 - dms pe :0.0 3:27PM 2:17 - I am updating to -CURRENT as of cvs-cur.5422, and will see what happens there. David scheidt > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 15:18:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 5FFC814D84 for ; Tue, 15 Jun 1999 15:18:25 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from bell.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 15 Jun 99 23:18:24 +0100 (BST) To: freebsd-current@freebsd.org Cc: iedowse@maths.tcd.ie Subject: NFS with IP aliases or multiple interfaces Date: Tue, 15 Jun 1999 23:18:24 +0100 From: Ian Dowse Message-ID: <9906152318.aa15606@salmon.maths.tcd.ie> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In certain setups with multiple network interfaces or IP aliases, nfsd(8) can send a reply using a source IP address that is not the same as the destination address of the request. This is explained in more detail in PRs 2858, 5964, 6412 and 9612. We just came across this problem locally, so I decided to attempt a fix. The patches included below appear to solve the problem in our configuration, but it has not been extensively tested, so I would be interested in any comments or suggestions. I'm particularly unsure about the new get_ifaddrs() function in nfsd.c, as much of it was copied from rwhod.c. (These patches are against -stable, and while they appear to apply cleanly to -current, I haven't actually tested them there) Essentially these changes cause nfsd to register one UDP socket for each interface as well as the wildcard socket. On the kernel side, I have removed 'nfs_udpsock' completely, because there is no longer just one UDP socket. Ian --- nfs_syscalls.c.orig Tue Jun 15 21:07:49 1999 +++ nfs_syscalls.c Tue Jun 15 22:22:48 1999 @@ -86,7 +86,7 @@ extern struct nfsstats nfsstats; extern int nfsrvw_procrastinate; extern int nfsrvw_procrastinate_v3; -struct nfssvc_sock *nfs_udpsock, *nfs_cltpsock; +struct nfssvc_sock *nfs_cltpsock; static int nuidhash_max = NFS_MAXUIDHASH; static void nfsrv_zapsock __P((struct nfssvc_sock *slp)); @@ -368,28 +368,24 @@ /* * Add it to the list, as required. */ - if (so->so_proto->pr_protocol == IPPROTO_UDP) { - tslp = nfs_udpsock; - if (tslp->ns_flag & SLP_VALID) { - FREE(mynam, M_SONAME); - return (EPERM); - } #ifdef ISO - } else if (so->so_proto->pr_protocol == ISOPROTO_CLTP) { + if (so->so_proto->pr_protocol == ISOPROTO_CLTP) { tslp = nfs_cltpsock; if (tslp->ns_flag & SLP_VALID) { - FREE(mynam, M_SONAME); + if (mynam != NULL) + FREE(mynam, M_SONAME); return (EPERM); } -#endif /* ISO */ } +#endif /* ISO */ if (so->so_type == SOCK_STREAM) siz = NFS_MAXPACKET + sizeof (u_long); else siz = NFS_MAXPACKET; error = soreserve(so, siz, siz); if (error) { - FREE(mynam, M_SONAME); + if (mynam != NULL) + FREE(mynam, M_SONAME); return (error); } @@ -867,13 +863,6 @@ TAILQ_INIT(&nfsd_head); nfsd_head_flag &= ~NFSD_CHECKSLP; - - nfs_udpsock = (struct nfssvc_sock *) - malloc(sizeof (struct nfssvc_sock), M_NFSSVC, M_WAITOK); - bzero((caddr_t)nfs_udpsock, sizeof (struct nfssvc_sock)); - STAILQ_INIT(&nfs_udpsock->ns_rec); - TAILQ_INIT(&nfs_udpsock->ns_uidlruhead); - TAILQ_INSERT_HEAD(&nfssvc_sockhead, nfs_udpsock, ns_chain); nfs_cltpsock = (struct nfssvc_sock *) malloc(sizeof (struct nfssvc_sock), M_NFSSVC, M_WAITOK); --- nfs_nqlease.c.orig Tue Jun 15 21:07:39 1999 +++ nfs_nqlease.c Tue Jun 15 21:23:21 1999 @@ -134,7 +134,7 @@ extern nfstype nfsv2_type[9]; extern nfstype nfsv3_type[9]; -extern struct nfssvc_sock *nfs_udpsock, *nfs_cltpsock; +extern struct nfssvc_sock *nfs_cltpsock; extern int nfsd_waiting; extern struct nfsstats nfsstats; @@ -381,11 +381,13 @@ if (slp == NQLOCALSLP) lph->lph_flag |= (LC_VALID | LC_LOCAL); - else if (slp == nfs_udpsock) { + else if (slp->ns_so->so_proto->pr_protocol == IPPROTO_UDP) { saddr = (struct sockaddr_in *)nam; - lph->lph_flag |= (LC_VALID | LC_UDP); + lph->lph_flag |= (LC_VALID | LC_UDP | LC_SREF); lph->lph_inetaddr = saddr->sin_addr.s_addr; lph->lph_port = saddr->sin_port; + lph->lph_slp = slp; + slp->ns_sref++; } else if (slp == nfs_cltpsock) { lph->lph_nam = dup_sockaddr(nam, 1); lph->lph_flag |= (LC_VALID | LC_CLTP); @@ -455,7 +457,8 @@ else return (0); } - if (slp == nfs_udpsock || slp == nfs_cltpsock) + if (slp->ns_so->so_proto->pr_protocol == IPPROTO_UDP || + slp == nfs_cltpsock) addr = nam; else addr = slp->ns_nam; @@ -514,7 +517,7 @@ saddr->sin_family = AF_INET; saddr->sin_addr.s_addr = lph->lph_inetaddr; saddr->sin_port = lph->lph_port; - so = nfs_udpsock->ns_so; + so = lph->lph_slp->ns_so; } else if (lph->lph_flag & LC_CLTP) { nam2 = lph->lph_nam; so = nfs_cltpsock->ns_so; --- nfsd.c.orig Tue Jun 15 14:15:50 1999 +++ nfsd.c Tue Jun 15 22:31:50 1999 @@ -52,6 +52,7 @@ #include #include #include +#include #include #include @@ -62,12 +63,17 @@ #include #include #include +#include +#include +#include + #ifdef NFSKERB #include #include #endif + #include #include #include @@ -84,6 +90,10 @@ int debug = 0; #endif +struct in_addr *ifaddr; +int ifaddr_count; + + struct nfsd_srvargs nsd; #ifdef OLD_SETPROCTITLE char **Argv = NULL; /* pointer to argument vector */ @@ -110,6 +120,7 @@ #endif #endif void usage __P((void)); +void get_ifaddrs __P((void)); /* * Nfs server daemon mostly just a user context for nfssvc() @@ -143,7 +154,7 @@ #endif fd_set ready, sockbits; int ch, cltpflag, connect_type_cnt, i, len, maxsock, msgsock; - int nfsdcnt, nfssvc_flag, on, reregister, sock, tcpflag, tcpsock; + int nfsdcnt, nfssvc_flag, on, reregister, tcpflag, tcpsock; int tp4cnt, tp4flag, tpipcnt, tpipflag, udpflag; #ifdef notyet int tp4sock, tpipsock; @@ -375,32 +386,55 @@ /* If we are serving udp, set up the socket. */ if (udpflag) { - if ((sock = socket(AF_INET, SOCK_DGRAM, 0)) < 0) { - syslog(LOG_ERR, "can't create udp socket"); - exit(1); - } - inetaddr.sin_family = AF_INET; - inetaddr.sin_addr.s_addr = INADDR_ANY; - inetaddr.sin_port = htons(NFS_PORT); - inetaddr.sin_len = sizeof(inetaddr); - if (bind(sock, - (struct sockaddr *)&inetaddr, sizeof(inetaddr)) < 0) { - syslog(LOG_ERR, "can't bind udp addr"); - exit(1); + int i; + int *sock; + + get_ifaddrs(); + + sock = malloc(ifaddr_count * sizeof(*sock)); + + for (i = 0; i < ifaddr_count; i++) { + int on = 1; + + if ((sock[i] = socket(AF_INET, SOCK_DGRAM, 0)) < 0) { + syslog(LOG_ERR, "can't create udp socket: %m"); + exit(1); + } + if (setsockopt(sock[i], SOL_SOCKET, SO_REUSEADDR, + &on, sizeof(on)) != 0) { + syslog(LOG_ERR, "setsockopt failed: %m"); + exit(1); + } + bzero(&inetaddr, sizeof(inetaddr)); + inetaddr.sin_family = AF_INET; + inetaddr.sin_addr.s_addr = ifaddr[i].s_addr; + inetaddr.sin_port = htons(NFS_PORT); + inetaddr.sin_len = sizeof(inetaddr); + if (bind(sock[i], (struct sockaddr *)&inetaddr, + sizeof(inetaddr)) < 0) { + syslog(LOG_ERR, "can't bind udp addr %s: %m", + inet_ntoa(ifaddr[i])); + exit(1); + } } if (!pmap_set(RPCPROG_NFS, 2, IPPROTO_UDP, NFS_PORT) || !pmap_set(RPCPROG_NFS, 3, IPPROTO_UDP, NFS_PORT)) { syslog(LOG_ERR, "can't register with udp portmap"); exit(1); } - nfsdargs.sock = sock; - nfsdargs.name = NULL; - nfsdargs.namelen = 0; - if (nfssvc(NFSSVC_ADDSOCK, &nfsdargs) < 0) { - syslog(LOG_ERR, "can't Add UDP socket"); - exit(1); + + for (i = 0; i < ifaddr_count; i++) { + nfsdargs.sock = sock[i]; + nfsdargs.name = NULL; + nfsdargs.namelen = 0; + if (nfssvc(NFSSVC_ADDSOCK, &nfsdargs) < 0) { + syslog(LOG_ERR, "can't Add UDP socket"); + exit(1); + } + (void)close(sock[i]); } - (void)close(sock); + + free(sock); } #ifdef ISO @@ -671,3 +705,87 @@ } #endif /* __FreeBSD__ */ #endif + + + +#define ROUNDUP(a) \ + ((a) > 0 ? (1 + (((a) - 1) | (sizeof(long) - 1))) : sizeof(long)) +#define ADVANCE(x, n) (x += ROUNDUP((n)->sa_len)) + +/* Get a list of local IP addresses, and store them in ifaddr[]. + * The first address will be INADDR_ANY as a fallback entry. + * The number of entries in the list is stored in ifaddr_count. + */ +void get_ifaddrs() { + register struct if_msghdr *ifm; + register struct ifa_msghdr *ifam; + size_t needed; + int mib[6], flags = 0; + char *buf, *lim, *next; + struct rt_addrinfo info; + + /* Create first address as wildcard */ + ifaddr = realloc(ifaddr, sizeof(*ifaddr) * (ifaddr_count + 1)); + ifaddr[ifaddr_count++].s_addr = INADDR_ANY; + + mib[0] = CTL_NET; + mib[1] = PF_ROUTE; + mib[2] = 0; + mib[3] = AF_INET; + mib[4] = NET_RT_IFLIST; + mib[5] = 0; + if (sysctl(mib, 6, NULL, &needed, NULL, 0) < 0) + errx(1, "route-sysctl-estimate"); + if ((buf = malloc(needed)) == NULL) + errx(1, "malloc"); + if (sysctl(mib, 6, buf, &needed, NULL, 0) < 0) + errx(1, "actual retrieval of interface table"); + lim = buf + needed; + + for (next = buf; next < lim; next += ifm->ifm_msglen) { + int i; + char *cp, *cplim; + struct sockaddr *saa[RTAX_MAX], *sa; + + ifm = (struct if_msghdr *)next; + if (ifm->ifm_type == RTM_IFINFO) { + flags = ifm->ifm_flags; + continue; + } + if ((flags & IFF_UP) == 0) + continue; + if (ifm->ifm_type != RTM_NEWADDR) + errx(1, "out of sync parsing NET_RT_IFLIST"); + ifam = (struct ifa_msghdr *)ifm; + info.rti_addrs = ifam->ifam_addrs; + cp = (char *)(ifam + 1); + cplim = ifam->ifam_msglen + (char *)ifam; + + bzero(saa, sizeof(saa)); + for (i = 0; i < RTAX_MAX && cp < cplim; i++) { + saa[i] = (struct sockaddr *)cp; + ADVANCE(cp, saa[i]); + } + + sa = saa[RTAX_GATEWAY]; + if (sa == 0 || sa->sa_family != AF_INET) + continue; + +#define SA2SIN(sa) (((struct sockaddr_in *)(sa))->sin_addr) + + /* Check if we've seen this address before */ + for (i = 0; i < ifaddr_count; i++) + if (ifaddr[i].s_addr == SA2SIN(sa).s_addr) { + sa = NULL; + break; + } + + if (sa == NULL) + continue; + + ifaddr = realloc(ifaddr, sizeof(*ifaddr) * (ifaddr_count + 1)); + ifaddr[ifaddr_count] = SA2SIN(sa); + ifaddr_count++; + } + free(buf); +} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 16:22:16 1999 Delivered-To: freebsd-current@freebsd.org Received: from isua1.iastate.edu (isua1.iastate.edu [129.186.1.201]) by hub.freebsd.org (Postfix) with ESMTP id B62F514F74 for ; Tue, 15 Jun 1999 16:22:09 -0700 (PDT) (envelope-from graphix@iastate.edu) Received: from localhost (graphix@localhost) by isua1.iastate.edu (8.8.5/8.8.5) with SMTP id SAA31703 for ; Tue, 15 Jun 1999 18:22:08 -0500 (CDT) Message-Id: <199906152322.SAA31703@isua1.iastate.edu> To: freebsd-current@freebsd.org Reply-To: kent@iastate.edu Subject: lpbb Date: Tue, 15 Jun 1999 18:22:07 CDT From: Kent Vander Velden Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What does one have to do to get lpbb working on -current? I think these are the relevant portions of the config file: controller smbus0 device smb0 at smbus? controller iicbus0 controller iicbb0 device ic0 at iicbus? device iic0 at iicbus? device iicsmb0 at iicbus? controller ppbus0 #controller vpo0 at ppbus? device lpt0 at ppbus? #device plip0 at ppbus? device ppi0 at ppbus? #device pps0 at ppbus? device lpbb0 at ppbus? device ppc0 at isa? port? irq 7 There is no mention of the iic system in dmesg but lpt and ppi show up: ppc: parallel port found at 0x378 ppc0: SMC registers CR1=0xbe CR4=0x0 SPP ppc0 at port 0x378-0x37f irq 7 on isa0 ppc0: SMC FDC37C665GT chipset (PS2/NIBBLE) in COMPATIBLE mode lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 The ppi device seems to work fine at least using a logic probe I can see the values changing on the bus as new values are sent to the device. One other related question: I used to be able to do the following to send test data onto the parallel port: cat /dev/kernel > /dev/lpt0 but I after a few second delay the following message comes back: /dev/lpt0: Device busy. and this is after killing lpd. Is this not allowed any longer with the introduction of the new parallel port bus system? Thanks. --- Kent Vander Velden kent@iastate.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 16:28:52 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 65B8215468 for ; Tue, 15 Jun 1999 16:28:49 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA23704; Tue, 15 Jun 1999 16:28:40 -0700 (PDT) (envelope-from dillon) Date: Tue, 15 Jun 1999 16:28:40 -0700 (PDT) From: Matthew Dillon Message-Id: <199906152328.QAA23704@apollo.backplane.com> To: Ian Dowse Cc: freebsd-current@FreeBSD.ORG, iedowse@maths.tcd.ie Subject: Re: NFS with IP aliases or multiple interfaces References: <9906152318.aa15606@salmon.maths.tcd.ie> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :In certain setups with multiple network interfaces or IP aliases, nfsd(8) :can send a reply using a source IP address that is not the same as the :destination address of the request. This is explained in more detail in :PRs 2858, 5964, 6412 and 9612. :... Dave Sharnoff has the same problem w/ NFS on idiom.com -- he has dozens of interfaces and can't isolate NFS on one side of his firewall because it uses the wrong IP addresses. If someone else doesn't review, test & commit your patch, I will, but it may be a little while. I need to get my commit privs back and have a bunch of other NFS-related stuff that is in the queue ahead of this. -Matt :(These patches are against -stable, and while they appear to apply cleanly :to -current, I haven't actually tested them there) : :Essentially these changes cause nfsd to register one UDP socket for each :interface as well as the wildcard socket. On the kernel side, I have :... :Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 17:58:55 1999 Delivered-To: freebsd-current@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 6C951151EB for ; Tue, 15 Jun 1999 17:58:39 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from lot.gsoft.com.au (lot.gsoft.com.au [203.38.152.106]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id KAA06137; Wed, 16 Jun 1999 10:28:28 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] 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: Wed, 16 Jun 1999 10:28:28 +0930 (CST) From: "Daniel O'Connor" To: cmpnerds Subject: RE: problem in audio.o?? Cc: freebsd-current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 15-Jun-99 cmpnerds wrote: > > Can we get your kernel config file? Any reason you haven't delete most of the stuff in here? Its kind of cluttered :-/ (space wasting too) And your kernel config compiles fine on my -current as of 2 days ago.. --- 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-current" in the body of the message From owner-freebsd-current Tue Jun 15 18:16:11 1999 Delivered-To: freebsd-current@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 1F0EF150F6 for ; Tue, 15 Jun 1999 18:16:06 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id VAA40898 for ; Tue, 15 Jun 1999 21:15:54 -0400 (EDT) Date: Tue, 15 Jun 1999 21:15:54 -0400 (EDT) From: Chuck Robey To: freebsd-current@FreeBSD.ORG Subject: ctm Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm sorry about the downtime, I haven't forgotten you. I found the problem, but the failure occured at the worst possible place, and I don't want to cause you all to reload, so I'm being careful about this. The last good diff was 3907. Look for 3908 to be a whopper, which will come out RSN (I can't be any more precise). ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 18:22:37 1999 Delivered-To: freebsd-current@freebsd.org Received: from PacHell.TelcoSucks.org (PacHell.TelcoSucks.org [207.90.181.5]) by hub.freebsd.org (Postfix) with ESMTP id 11B9F150F6 for ; Tue, 15 Jun 1999 18:22:28 -0700 (PDT) (envelope-from ulf@PacHell.TelcoSucks.org) Received: (from ulf@localhost) by PacHell.TelcoSucks.org (8.9.3/8.9.1) id SAA01784; Tue, 15 Jun 1999 18:22:37 -0700 (PDT) (envelope-from ulf) Message-ID: <19990615182237.A96948@TelcoSucks.org> Date: Tue, 15 Jun 1999 18:22:37 -0700 From: Ulf Zimmermann To: Chuck Robey , freebsd-current@FreeBSD.ORG Subject: Re: ctm Reply-To: ulf@Alameda.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Chuck Robey on Tue, Jun 15, 1999 at 09:15:54PM -0400 Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 3.2-STABLE Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jun 15, 1999 at 09:15:54PM -0400, Chuck Robey wrote: > I'm sorry about the downtime, I haven't forgotten you. I found the > problem, but the failure occured at the worst possible place, and I > don't want to cause you all to reload, so I'm being careful about this. > The last good diff was 3907. > > Look for 3908 to be a whopper, which will come out RSN (I can't be any > more precise). Chuck, should I go and get another disk for the system and do we maybe want to upgrade it to 3.x ? -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 18:37:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 0BC6A151FE for ; Tue, 15 Jun 1999 18:37:38 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id VAA40979; Tue, 15 Jun 1999 21:37:19 -0400 (EDT) Date: Tue, 15 Jun 1999 21:37:19 -0400 (EDT) From: Chuck Robey To: Ulf Zimmermann Cc: freebsd-current@FreeBSD.ORG Subject: Re: ctm In-Reply-To: <19990615182237.A96948@TelcoSucks.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 15 Jun 1999, Ulf Zimmermann wrote: > On Tue, Jun 15, 1999 at 09:15:54PM -0400, Chuck Robey wrote: > > I'm sorry about the downtime, I haven't forgotten you. I found the > > problem, but the failure occured at the worst possible place, and I > > don't want to cause you all to reload, so I'm being careful about this. > > The last good diff was 3907. > > > > Look for 3908 to be a whopper, which will come out RSN (I can't be any > > more precise). > > Chuck, > > should I go and get another disk for the system and do we maybe > want to upgrade it to 3.x ? All of the failures in the last year are attributable, at least initially, to lack of disk resources. Getting more disk would be wonderful, and gratefully appreciated by all the ctm'ers. Maybe being curmudgeonly about letting others put extra things on that disk would be appreciated too. I don't know about your funding, maybe you want to ask Jordan, I'm sure he'd pop for the disk. Our current problems were initiated by lack of disk (made much worse by *when* the disk problem hit us). ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 19:35:52 1999 Delivered-To: freebsd-current@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id A2222153DF for ; Tue, 15 Jun 1999 19:35:50 -0700 (PDT) (envelope-from cmpnerds@enteract.com) Received: (qmail 44832 invoked from network); 16 Jun 1999 02:35:49 -0000 Received: from adam.enteract.com (cmpnerds@206.54.252.1) by pop3-3.enteract.com with SMTP; 16 Jun 1999 02:35:49 -0000 Date: Tue, 15 Jun 1999 21:35:48 -0500 (CDT) From: cmpnerds To: Daniel O'Connor Cc: freebsd-current@freebsd.org Subject: RE: problem in audio.o?? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Can we get your kernel config file? > Any reason you haven't delete most of the stuff in here? Its kind of cluttered > :-/ I like to get everything working then remove stuff. > And your kernel config compiles fine on my -current as of 2 days ago.. Did you uncomment the: "controller pcm0" When I do it doesn't compile. sorry I forgot to remove it before i sent it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 19:43:25 1999 Delivered-To: freebsd-current@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 948DF1547C for ; Tue, 15 Jun 1999 19:43:21 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from lot.gsoft.com.au (lot.gsoft.com.au [203.38.152.106]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id MAA07184; Wed, 16 Jun 1999 12:13:14 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] 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: Wed, 16 Jun 1999 12:13:14 +0930 (CST) From: "Daniel O'Connor" To: cmpnerds Subject: RE: problem in audio.o?? Cc: freebsd-current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Jun-99 cmpnerds wrote: > I like to get everything working then remove stuff. Hmm OK. > > And your kernel config compiles fine on my -current as of 2 days ago.. > Did you uncomment the: "controller pcm0" > > When I do it doesn't compile. sorry I forgot to remove it before i sent > it. The pcm0 line in here is uncommented and it works fine.. Try updating your -current or switch to -stable. --- 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-current" in the body of the message From owner-freebsd-current Tue Jun 15 20:28:40 1999 Delivered-To: freebsd-current@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id C9B5614CFF for ; Tue, 15 Jun 1999 20:28:38 -0700 (PDT) (envelope-from cmpnerds@enteract.com) Received: (qmail 55978 invoked from network); 16 Jun 1999 03:28:37 -0000 Received: from adam.enteract.com (cmpnerds@206.54.252.1) by pop3-3.enteract.com with SMTP; 16 Jun 1999 03:28:37 -0000 Date: Tue, 15 Jun 1999 22:28:33 -0500 (CDT) From: cmpnerds To: Daniel O'Connor Cc: freebsd-current@freebsd.org Subject: RE: problem in audio.o?? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry again ..uncomment snd0..... On Wed, 16 Jun 1999, Daniel O'Connor wrote: > > On 16-Jun-99 cmpnerds wrote: > > I like to get everything working then remove stuff. > Hmm OK. > > > > And your kernel config compiles fine on my -current as of 2 days ago.. > > Did you uncomment the: "controller pcm0" > > > > When I do it doesn't compile. sorry I forgot to remove it before i sent > > it. > > The pcm0 line in here is uncommented and it works fine.. > > Try updating your -current or switch to -stable. > > --- > 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-current" in the body of the message From owner-freebsd-current Tue Jun 15 20:30:31 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id B802114CFF for ; Tue, 15 Jun 1999 20:30:29 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA25113; Tue, 15 Jun 1999 20:30:28 -0700 (PDT) (envelope-from dillon) Date: Tue, 15 Jun 1999 20:30:28 -0700 (PDT) From: Matthew Dillon Message-Id: <199906160330.UAA25113@apollo.backplane.com> To: "David E. Cross" , David Scheidt , Chan Yiu Wah , freebsd-current@FreeBSD.ORG Subject: NFS Test patch available for -CURRENT (was Re: NFS vnode ref issues on server) References: <199906150421.VAA14439@apollo.backplane.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here's the location: http://www.backplane.com/FreeBSD4/ It's in the 'NFS bugs first found by David E. Cross' section. The diff is *HUGE*, but strangly enough only covers three files :-) It does not cover nfs_node.c, so it should not interfere with the commit David is planning on doing. There are almost certainly bugs in the rewrite, so people who test this need to expect panics. If you get a panic, please use a DDB-enabled kernel and do a 'trace' -- the code is organized such that it should be fairly easy to track down the bugs. Whatever bugs there are will be minor ( I hope ). It is able to build world ( at least so far as I've gotten ), and it does run David's O_CREAT test code. It needs much more testing, though. Netstat on NFS server (2xSMP box with insane amounts of ram) while running the O_CREAT test program on two separate clients simultaniously with a buildworld on one of the clients. test3:/mnt# netstat -in 1 input (Total) output packets errs bytes packets errs bytes colls (just the two O_CREAT test programs running) 5025 0 899628 5024 0 1097738 19 5035 0 906642 5035 0 1106276 28 5038 0 896578 5038 0 1093918 15 4988 0 901424 4989 0 1100052 17 5011 0 907504 5010 0 1107182 14 5058 0 750524 5058 0 915936 9 4205 0 897390 4206 0 1094920 20 5036 0 631906 5035 0 744222 12 4136 0 462974 4137 0 558708 177 (the two O_CREAT test programs running and buildworld running) 2601 0 429798 2594 0 521616 295 2656 0 550306 2655 0 583742 343 2429 0 416518 2386 0 507574 402 2500 0 553238 2500 0 593134 326 The new code is mainly centered around nfs_serv.c and essentially rewrites most of the guts of most of the procedures to properly track and abort the NFS ops. It isn't pretty, but it is functional. There were simply too many problems to make simple bug fixes - just over three quarters of the procedures had incorrect termination code for handling nfsm_*() macro error conditions. NO changes were made to API's outside of NFS to accomodate the new code ( which is partially why it is still so messy ). Once we've stabilized it in -current and can show that it is at least not worse then the original code, and I get my commit privs back, I will MFC it into -stable. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 20:32:12 1999 Delivered-To: freebsd-current@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 4B82014CFF for ; Tue, 15 Jun 1999 20:31:56 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from lot.gsoft.com.au (lot.gsoft.com.au [203.38.152.106]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id NAA07523; Wed, 16 Jun 1999 13:01:19 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] 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: Wed, 16 Jun 1999 13:01:18 +0930 (CST) From: "Daniel O'Connor" To: cmpnerds Subject: RE: problem in audio.o?? Cc: freebsd-current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Jun-99 cmpnerds wrote: > Sorry again ..uncomment snd0..... You didn't read the sound docs properly pcm0 and snd0 (and friends like sb0 etc) are mutually exclusive. --- 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-current" in the body of the message From owner-freebsd-current Tue Jun 15 22:35:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by hub.freebsd.org (Postfix) with ESMTP id 2BA6C14C41 for ; Tue, 15 Jun 1999 22:35:23 -0700 (PDT) (envelope-from Matthew.Thyer@dsto.defence.gov.au) Received: from dsto-ms2.dsto.defence.gov.au (dsto-ms2.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au (8.7.5/8.7.3) with ESMTP id PAA22653 for ; Wed, 16 Jun 1999 15:02:33 +0930 (CST) Received: from exchsa1.dsto.defence.gov.au (unverified [131.185.2.94]) by dsto-ms2.dsto.defence.gov.au (Integralis SMTPRS 2.0.15) with ESMTP id for ; Wed, 16 Jun 1999 15:04:36 +0930 Received: from fuzz.dsto.defence.gov.au ([131.185.75.229]) by exchsa1.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id M9F3MVSF; Wed, 16 Jun 1999 15:05:17 +0930 Received: from dsto.defence.gov.au (localhost [127.0.0.1]) by fuzz.dsto.defence.gov.au (8.9.3/8.9.3) with ESMTP id PAA00582 for ; Wed, 16 Jun 1999 15:04:50 +0930 (CST) (envelope-from Matthew.Thyer@dsto.defence.gov.au) Message-Id: <3767377A.892F745A@dsto.defence.gov.au> Date: Wed, 16 Jun 1999 15:04:50 +0930 From: Matthew Thyer X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: "current@FreeBSD.org" Subject: FreeBSD-CURRENT CTM deltas have stopped ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The last one I got was: src-cur.3907.gz which is dated "Jun 8 14:42" my time (UTC +9.5 hours). I'm still getting ports-cur CTM deltas OK and the last one I received was ports-cur.2866.gz which is dated "Jun 16 03:46" my time. Please email me in your replies as I'm not up to date with the list. -- Matthew Thyer Phone: +61 8 8259 7249 Corporate Information Systems Fax: +61 8 8259 5537 Defence Science and Technology Organisation, Salisbury PO Box 1500 Salisbury South Australia 5108 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 15 23:48:52 1999 Delivered-To: freebsd-current@freebsd.org Received: from yamabiko.edu.isc.kyutech.ac.jp (yamabiko.edu.isc.kyutech.ac.jp [131.206.128.13]) by hub.freebsd.org (Postfix) with ESMTP id 92C06150DA for ; Tue, 15 Jun 1999 23:48:36 -0700 (PDT) (envelope-from p99209tn@iizuka.isc.kyutech.ac.jp) Received: from mozu.edu.isc.kyutech.ac.jp (mozu.edu.isc.kyutech.ac.jp [131.206.129.45]) by yamabiko.edu.isc.kyutech.ac.jp (8.9.1+3.1W/3.7W-yamabiko990316) with ESMTP id PAA09981 for ; Wed, 16 Jun 1999 15:48:35 +0900 (JST) Received: from mozu (p99209tn@localhost) by mozu.edu.isc.kyutech.ac.jp (8.8.5+2.7Wbeta5/3.4W2-ISCEDUi) with ESMTP id PAA08560 for ; Wed, 16 Jun 1999 15:48:34 +0900 (JST) Message-Id: <199906160648.PAA08560@mozu.edu.isc.kyutech.ac.jp> To: freebsd-current@freebsd.org Date: Wed, 16 Jun 1999 15:48:32 +0900 From: nojirino takashi Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG auth 9879429d unsubscribe freebsd-current p99209tn@iizuka.isc.kyutech.ac.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 0: 3:39 1999 Delivered-To: freebsd-current@freebsd.org Received: from radius.connectfree.net (ns1.connectfree.co.uk [212.1.130.32]) by hub.freebsd.org (Postfix) with ESMTP id EC96B153DB for ; Wed, 16 Jun 1999 00:03:37 -0700 (PDT) (envelope-from freebsd@sleepycat.ukpeople.net) Received: from sleepycat.ukpeople.net ([212.1.153.119]) by radius.connectfree.net (8.9.1/8.9.0) with ESMTP id IAA09336 for ; Wed, 16 Jun 1999 08:29:18 +0100 Received: (qmail 5161 invoked from network); 16 Jun 1999 07:00:25 -0000 Received: from ginger.sleepycat.ukpeople.net (HELO sleepycat.ukpeople.net) (192.168.0.2) by tabby.sleepycat.ukpeople.net with SMTP; 16 Jun 1999 07:00:25 -0000 Received: (qmail 385 invoked by uid 1002); 16 Jun 1999 07:01:24 -0000 Date: Wed, 16 Jun 1999 08:01:24 +0100 From: Timo Geusch To: freebsd-current@freebsd.org Subject: PNP'ify ep driver Message-ID: <19990616080124.A278@sleepycat.ukpeople.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG All, while trying to track down a problem in my -current box that only allows me to use the network if I remove the sound card first I came across the problem of the 3c5x9 in that box 'pretending' to be set to different values than those reported by the PNP BIOS. Of course having the ep network driver waiting for an interrupt from the sound card so it can go about retrieving data from the network card didn't really help performance. Doh. Adding the PNP probing support to the driver proved to be very simple. Hats off to the person who did the PNP support - it was really easy. However when I set about writing the pnp attached function it turns out that the card is still reporting its preferred settings (I/O 0x320/IRQ 10) instead of the PNP ones, so I figure that I actually must go about and convince the card that the driver knows better (i.e. reconfigure it). So, three questions: - Anyone knows where I can get the programmer documentation for the card? 3Com, presumably, but the last time I pestered them for docs they weren't exactly helpful. - Is it permissible at all for the driver to reconfigure the card (hey, it is for a good cause :-) or is this a strict no-no? - I only have systems with one of these cards in them. Provided I get this stuff sorted, any volunteer with more than one Etherlink III in their systems so they can test that I didn't break anything? Oh, and I know that these cards are not exactly the mutt's nuts. But it is hard to beat UKP 10 / card for a used network card over here. Especially if you don't want el cheapo dodgy NE200 clones, that is. Regards, Timo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 1:19: 7 1999 Delivered-To: freebsd-current@freebsd.org Received: from freja.webgiro.com (freja.webgiro.com [212.209.29.10]) by hub.freebsd.org (Postfix) with ESMTP id C84FA156B2 for ; Wed, 16 Jun 1999 01:18:59 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by freja.webgiro.com (Postfix, from userid 1001) id 9C6C018F7; Wed, 16 Jun 1999 10:18:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by freja.webgiro.com (Postfix) with ESMTP id 9960749CC; Wed, 16 Jun 1999 10:18:56 +0200 (CEST) Date: Wed, 16 Jun 1999 10:17:39 +0200 (CEST) From: Andrzej Bialecki To: Nick Hibma Cc: Roger Hardiman , current@FreeBSD.ORG Subject: Re: Announcing PicoBSD 0.44 for -current In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 15 Jun 1999, Nick Hibma wrote: > > Congrats and thanks! > > Is there also a version available that fits on 720kb floppies :-] It's possible, I think.. We need to change the architecture of PicoBSD first, though - could be enough just to use all modularity 4.x gives you, and which is not (yet) fully exploited in picobsd. Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 5:14: 9 1999 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 2642D1529A; Wed, 16 Jun 1999 05:14:05 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id OAA83009; Wed, 16 Jun 1999 14:14:02 +0200 (CEST) (envelope-from des) To: "Sam Stephenson" Cc: , Subject: Re: 'w' patch References: From: Dag-Erling Smorgrav Date: 16 Jun 1999 14:14:01 +0200 In-Reply-To: "Sam Stephenson"'s message of "Tue, 15 Jun 1999 13:38:29 -0400" Message-ID: Lines: 10 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Sam Stephenson" writes: > Please have a look at this patch, and consider implementing it into the > source tree. Please submit a PR ('send-pr') for this with a unidiff ('diff -u') rather than the old-style diff you posted here. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 5:29:55 1999 Delivered-To: freebsd-current@freebsd.org Received: from gal.netlab.sk (gal.netlab.sk [195.168.1.4]) by hub.freebsd.org (Postfix) with ESMTP id 012A7154CA for ; Wed, 16 Jun 1999 05:29:51 -0700 (PDT) (envelope-from tps@ti.sk) Received: from tps (root@qwyx.netlab.sk [195.168.0.2]) by gal.netlab.sk (8.9.3/8.9.3) with SMTP id OAA04259 for ; Wed, 16 Jun 1999 14:29:50 +0200 (CEST) Reply-To: From: "Tomas TPS Ulej" To: Subject: traceroute problem Date: Wed, 16 Jun 1999 14:29:50 +0200 Message-ID: <008a01beb7f3$ed898060$231da8c3@tps.tps.sk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG tps@[gal /home/tps] > traceroute localhost traceroute: unknown protocol (null) tps@[gal /home/tps] > uname -a FreeBSD gal.netlab.sk 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Sat Jun 5 22:41:38 CEST 1999 tps@gal.netlab.sk:/shared1/src/sys/compile/GENERIC i386 Why? -- Tomas TPS Ulej System Engineer tps@ti.sk, tu36-ripe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 5:41:36 1999 Delivered-To: freebsd-current@freebsd.org Received: from freesbee.t.dk (freesbee.t.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with SMTP id 3D8B315226 for ; Wed, 16 Jun 1999 05:41:33 -0700 (PDT) (envelope-from jesper@freesbee.t.dk) Received: (qmail 336 invoked by uid 1001); 16 Jun 1999 12:41:32 -0000 Date: Wed, 16 Jun 1999 14:41:32 +0200 From: Jesper Skriver To: Tomas TPS Ulej Cc: freebsd-current@freebsd.org Subject: Re: traceroute problem Message-ID: <19990616144132.A289@skriver.dk> References: <008a01beb7f3$ed898060$231da8c3@tps.tps.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.2i In-Reply-To: <008a01beb7f3$ed898060$231da8c3@tps.tps.sk>; from Tomas TPS Ulej on Wed, Jun 16, 1999 at 02:29:50PM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Works fine on today's current ... /Jesper On Wed, Jun 16, 1999 at 02:29:50PM +0200, Tomas TPS Ulej wrote: > tps@[gal /home/tps] > traceroute localhost > traceroute: unknown protocol (null) > > tps@[gal /home/tps] > uname -a > FreeBSD gal.netlab.sk 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Sat Jun 5 > 22:41:38 CEST 1999 tps@gal.netlab.sk:/shared1/src/sys/compile/GENERIC > i386 > > Why? > > -- > Tomas TPS Ulej > System Engineer > tps@ti.sk, tu36-ripe > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 7:12: 2 1999 Delivered-To: freebsd-current@freebsd.org Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (Postfix) with ESMTP id DC84C14DBF; Wed, 16 Jun 1999 07:11:56 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:YgIgnV8YsNtZvuXQmD4nr5yaHK1TrlAl@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.9.3/3.7Wpl2) with ESMTP id XAA10152; Wed, 16 Jun 1999 23:12:03 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id XAA03866; Wed, 16 Jun 1999 23:15:54 +0900 (JST) Message-Id: <199906161415.XAA03866@zodiac.mech.utsunomiya-u.ac.jp> To: sos@freebsd.org, dfr@freebsd.org, kato@freebsd.org, des@freebsd.org Cc: freebsd-current@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: syscons update - stage 2 snopshot 16 June Date: Wed, 16 Jun 1999 23:15:53 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is to announce the forth and the last, snapshot of the stage 2 of syscons update. I placed a set of patches in http://www.freebsd.org/~yokota/syscons-update.16June.tar.gz I would appreciate if you take a look and test the code. I intend to commit these changes to the source tree this weekend if all goes well. Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 8:11:15 1999 Delivered-To: freebsd-current@freebsd.org Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by hub.freebsd.org (Postfix) with ESMTP id 13DDB15451 for ; Wed, 16 Jun 1999 08:11:13 -0700 (PDT) (envelope-from culverk@wam.umd.edu) Received: from rac1.wam.umd.edu (root@rac1.wam.umd.edu [128.8.10.141]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id LAA07148 for ; Wed, 16 Jun 1999 11:11:11 -0400 (EDT) Received: from rac1.wam.umd.edu (sendmail@localhost [127.0.0.1]) by rac1.wam.umd.edu (8.9.3/8.9.3) with SMTP id LAA23080 for ; Wed, 16 Jun 1999 11:11:11 -0400 (EDT) Received: from localhost by rac1.wam.umd.edu (8.9.3/8.9.3) with ESMTP id LAA23076 for ; Wed, 16 Jun 1999 11:11:10 -0400 (EDT) X-Authentication-Warning: rac1.wam.umd.edu: culverk owned process doing -bs Date: Wed, 16 Jun 1999 11:11:10 -0400 (EDT) From: Kenneth Wayne Culver To: freebsd-current@freebsd.org Subject: Aureal Vortex sound driver Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I was told about 3 weeks ago that an Aureal Vortex soundcard driver was in the works, and would be done soon, I was just wondering about the progress of that driver; and I am fairly anxious to test it... :-) Kenneth Culver Computer Science Major at the University of Maryland, College Park. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 8:20:31 1999 Delivered-To: freebsd-current@freebsd.org Received: from kali.brainlink.com (kali.brainlink.com [206.127.58.27]) by hub.freebsd.org (Postfix) with ESMTP id 13A66154F4 for ; Wed, 16 Jun 1999 08:20:23 -0700 (PDT) (envelope-from tugrul@brainlink.com) Received: from buddha.brainlink.com ([206.127.58.23]) by kali.brainlink.com (Post.Office MTA v3.5.2 release 221 ID# 0-52824U2500L250S0V35) with ESMTP id com; Wed, 16 Jun 1999 11:19:10 -0400 Received: by buddha.brainlink.com (Postfix, from userid 1000) id 118C9A6; Wed, 16 Jun 1999 11:19:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by buddha.brainlink.com (Postfix) with ESMTP id F2D1DA4; Wed, 16 Jun 1999 11:19:51 -0400 (EDT) Date: Wed, 16 Jun 1999 11:19:51 -0400 (EDT) From: Tugrul Galatali To: Tomas TPS Ulej Cc: freebsd-current@freebsd.org Subject: Re: traceroute problem In-Reply-To: <008a01beb7f3$ed898060$231da8c3@tps.tps.sk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 16 Jun 1999, Tomas TPS Ulej wrote: > tps@[gal /home/tps] > traceroute localhost > traceroute: unknown protocol (null) [...] > > Why? > Need /etc/protocols I believe Tugrul Galatali > -- > Tomas TPS Ulej > System Engineer > tps@ti.sk, tu36-ripe > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 8:23: 5 1999 Delivered-To: freebsd-current@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id DEE9314BD8; Wed, 16 Jun 1999 08:23:00 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id LAA43571; Wed, 16 Jun 1999 11:22:09 -0400 (EDT) Date: Wed, 16 Jun 1999 11:22:09 -0400 (EDT) From: Chuck Robey To: Matthew Thyer Cc: "current@FreeBSD.org" , ulf@FreeBSD.ORG Subject: Re: FreeBSD-CURRENT CTM deltas have stopped ? In-Reply-To: <3767377A.892F745A@dsto.defence.gov.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 16 Jun 1999, Matthew Thyer wrote: > The last one I got was: src-cur.3907.gz > which is dated "Jun 8 14:42" my time (UTC +9.5 hours). > > I'm still getting ports-cur CTM deltas OK and the last one I received > was ports-cur.2866.gz which is dated "Jun 16 03:46" my time. > > Please email me in your replies as I'm not up to date with the list. The ctm source files (the files being maintained for ctm) got scragged during an update (disk full). On my own machine, I would go ahead, kill the entire set, and rebuild, but because (if I made an error) this would force all you guys to ftp huge deltas (because an error would force all you guys to reload) I decided to ask someone to check me. That someone is currently gatting about San Francisco, and as soon as I track him down, I'll begin the reconstruction. I'm sorry for the delay, but I don't want to force everyone to reload. OTOH, Ulf has spoken to me, and I think a new, larger disk for ctm is in the offing. We've needed one real badly, because of extra things that have been added to the machine, filling the once empty disks. I'll let Ulf make any announcement about the disk himself. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 8:29:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id 63AFA14BD8 for ; Wed, 16 Jun 1999 08:29:19 -0700 (PDT) (envelope-from Studded@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id IAA18703 for ; Wed, 16 Jun 1999 08:29:19 -0700 (PDT) (envelope-from Studded@gorean.org) Message-ID: <3767C2CE.3FFB13BE@gorean.org> Date: Wed, 16 Jun 1999 08:29:18 -0700 From: Studded Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Heavily loaded amd gets stuck Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In my continuing efforts to get a freebsd machine up and running in an all-sun shop I've run into some more problems with amd. I have the amd.conf and the map files in place, and amd mounts one directory at a time without hesitation. However when I try to mount many directories in rapid succession amd gets hung and refuses to answer any requests, although it does unmount the directories it mounted after the time interval. More disturbing to me is the fact that nothing, not even a kill -9 will terminate amd, I have to reboot the box. We have several scripts that mount user directories on various servers. If I run a script that attempts to access all of the user directories on all of the servers amd locks up around 63 or 64 out of 80. I'm using 3.2-Stable, but I'm sending this to -current because I know that there has been a lot of work on NFS lately. I am willing to try whatever it takes to get this working, conf options, patches, what have you. Thanks, Doug -- *** Chief Operations Officer, DALnet IRC network *** Nominated for quote of the year is the statement made by Representative Dick Armey (Texas), who when asked if he were in the President's place, would he resign, responded: "If I were in the President's place I would not get a chance to resign. I would be lying in a pool of my own blood hearing Mrs. Armey standing over me saying, 'How do I reload this damn thing?'" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 9: 2:56 1999 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 1C77F15495; Wed, 16 Jun 1999 09:02:46 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id JAA67951; Wed, 16 Jun 1999 09:02:35 -0700 (PDT) (envelope-from obrien) Message-ID: <19990616090235.A67903@nuxi.com> Date: Wed, 16 Jun 1999 09:02:35 -0700 From: "David O'Brien" To: Naoki Hamada Cc: freebsd-mobile@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: pccard boot.flp for *plain* 3.2-RELEASE Reply-To: obrien@FreeBSD.ORG References: <10710.928404651.1@peewee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Naoki Hamada on Sat, Jun 05, 1999 at 11:18:23AM +0900 X-Operating-System: FreeBSD 3.2-BETA Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > FreeBSD's isc-dhcp client was based on v2.0b1pl18 before May 8. It had > some bugs, which were fatal in many environments. This is the first I have heard of this (as maintainer of dhclient in /usr/src). Why weren't PR's sent documenting this? I (and three others I know) used v2.0b1pl18 at my site for our network connection w/zero problems. -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 9:11:13 1999 Delivered-To: freebsd-current@freebsd.org Received: from freesbee.t.dk (freesbee.t.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with SMTP id A690515460 for ; Wed, 16 Jun 1999 09:11:09 -0700 (PDT) (envelope-from jesper@freesbee.t.dk) Received: (qmail 3211 invoked by uid 1001); 16 Jun 1999 16:11:08 -0000 Date: Wed, 16 Jun 1999 18:11:08 +0200 From: Jesper Skriver To: Studded Cc: freebsd-current@freebsd.org Subject: Re: Heavily loaded amd gets stuck Message-ID: <19990616181108.A3124@skriver.dk> References: <3767C2CE.3FFB13BE@gorean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.2i In-Reply-To: <3767C2CE.3FFB13BE@gorean.org>; from Studded on Wed, Jun 16, 1999 at 08:29:18AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What version of NFS are you using, we just had a box that hang totally when doing a "make installworld" over NFS v3, both server and client running -current, it worked fine when we changed to v2 /Jesper On Wed, Jun 16, 1999 at 08:29:18AM -0700, Studded wrote: > In my continuing efforts to get a freebsd machine up and running in an > all-sun shop I've run into some more problems with amd. I have the amd.conf > and the map files in place, and amd mounts one directory at a time without > hesitation. However when I try to mount many directories in rapid > succession amd gets hung and refuses to answer any requests, although it > does unmount the directories it mounted after the time interval. More > disturbing to me is the fact that nothing, not even a kill -9 will > terminate amd, I have to reboot the box. > > We have several scripts that mount user directories on various servers. If > I run a script that attempts to access all of the user directories on all > of the servers amd locks up around 63 or 64 out of 80. > > I'm using 3.2-Stable, but I'm sending this to -current because I know that > there has been a lot of work on NFS lately. I am willing to try whatever it > takes to get this working, conf options, patches, what have you. > > Thanks, > > Doug > -- > *** Chief Operations Officer, DALnet IRC network *** > > Nominated for quote of the year is the statement made by Representative > Dick Armey (Texas), who when asked if he were in the President's place, > would he resign, responded: > > "If I were in the President's place I would not get a chance to resign. > I would be lying in a pool of my own blood hearing Mrs. Armey standing > over me saying, 'How do I reload this damn thing?'" > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 11:52:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 866CB154A1 for ; Wed, 16 Jun 1999 11:52:17 -0700 (PDT) (envelope-from ticso@cicely8.cicely.de) Received: from cicely7.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.8.6/8.8.6) with ESMTP id UAA06704 for ; Wed, 16 Jun 1999 20:45:16 +0200 (MET DST) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by cicely7.cicely.de (8.9.0/8.9.0) with ESMTP id UAA61133 for ; Wed, 16 Jun 1999 20:51:56 +0200 (CEST) Received: (from ticso@localhost) by cicely8.cicely.de (8.9.3/8.9.2) id UAA85773 for freebsd-current@freebsd.org; Wed, 16 Jun 1999 20:52:40 +0200 (CEST) (envelope-from ticso) Date: Wed, 16 Jun 1999 20:52:39 +0200 From: Bernd Walter To: freebsd-current@freebsd.org Subject: current GENERIC still panics for me Message-ID: <19990616205239.A85743@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This happend with kernel compiled using GENERIC: Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 FreeBSD/i386 bootstrap loader, Revision 0.7 636/65472kB (ticso@cicely5.cicely.de, Mon Jun 14 10:28:01 CEST 1999) Loading /boot/defaults/loader.conf /kernel text=0x1e02a3 data=0x23e00+0x1fa6c syms=[0x4+0x27cd0+0x4+0x27da7] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel]... Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Wed Jun 16 22:41:13 CEST 1999 root@:/var/d0/src-1999-06-14/src/sys/compile/GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: AMD-K6tm w/ multimedia extensions (233.03-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x562 Stepping=2 Features=0x8001bf real memory = 134217728 (131072K bytes) sio0: system console avail memory = 127012864 (124036K bytes) Preloaded elf kernel "kernel" at 0xc0376000. Probing for PnP devices: npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 chip0: at device 0.0 on pci0 isab0: at device 7.0 on pci0 ide_pci0: at device 7.1 on pci0 chip1: irq 5 at device 7.2 on pci0 pcib1: at device 9.0 on pci0 pci1: on pcib1 ahc0: irq 5 at device 4.0 on pci1 ahc0: aic7870 Single Channel A, SCSI Id=7, 16/255 SCBs ahc1: irq 11 at device 5.0 on pci1 RAID functionality unsupported device_probe_and_attach: ahc1 attach returned 6 ahc2: irq 5 at device 8.0 on pci1 ahc2: aic7870 Single Channel B, SCSI Id=7, 16/255 SCBs ahc3: irq 5 at device 12.0 on pci1 ahc3: aic7870 Single Channel C, SCSI Id=7, 16/255 SCBs pcib2: at device 10.0 on pci0 pci2: on pcib2 ahc4: irq 12 at device 4.0 on pci2 ahc4: aic7880 Single Channel A, SCSI Id=7, 16/255 SCBs ahc5: irq 5 at device 5.0 on pci2 ahc5: aic7880 Single Channel B, SCSI Id=7, 16/255 SCBs de0: irq 10 at device 11.0 on pci0 de0: Cogent 21140A [10-100Mb/s] pass 2.0 de0: address 00:00:92:9b:20:e7 pcib3: at device 12.0 on pci0 pci3: on pcib3 ahc6: irq 11 at device 4.0 on pci3 ahc6: aic7870 Single Channel A, SCSI Id=7, 16/255 SCBs ahc7: irq 10 at device 5.0 on pci3 RAID functionality unsupported device_probe_and_attach: ahc7 attach returned 6 ahc8: irq 11 at device 8.0 on pci3 panic: bus_dmamem_free: Invalid map freed Automatic reboot in 15 seconds - press a key on the console to abort I already wrote a more complete mail using an older kernel and a DDB Stack-Trace. If someone can tell me how I can help debugging this problem I will do it. The latest kernel I run before this problem was somewhere from April. Maybe it's releated to newbus changes? -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 12:14:20 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id D548E157BE for ; Wed, 16 Jun 1999 12:14:16 -0700 (PDT) (envelope-from Studded@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id MAA22972 for ; Wed, 16 Jun 1999 12:14:16 -0700 (PDT) (envelope-from Studded@gorean.org) Date: Wed, 16 Jun 1999 12:14:16 -0700 (PDT) From: Studded X-Sender: doug@dt054n86.san.rr.com To: freebsd-current@freebsd.org Subject: Re: Heavily loaded amd gets stuck In-Reply-To: <19990616181108.A3124@skriver.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 16 Jun 1999, Jesper Skriver wrote: > What version of NFS are you using, we just had a box that hang totally > when doing a "make installworld" over NFS v3, both server and client > running -current, it worked fine when we changed to v2 I thought of this, but I don't see any config options to downgrade amd. I'm looking through the source now, but any suggestions welcome. Thanks, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 12:37:57 1999 Delivered-To: freebsd-current@freebsd.org Received: from freesbee.t.dk (freesbee.t.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with SMTP id 9688F14EEE for ; Wed, 16 Jun 1999 12:37:52 -0700 (PDT) (envelope-from jesper@freesbee.t.dk) Received: (qmail 5915 invoked by uid 1001); 16 Jun 1999 19:37:51 -0000 Date: Wed, 16 Jun 1999 21:37:51 +0200 From: Jesper Skriver To: Studded Cc: freebsd-current@freebsd.org Subject: Re: Heavily loaded amd gets stuck Message-ID: <19990616213751.C5808@skriver.dk> References: <19990616181108.A3124@skriver.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.2i In-Reply-To: ; from Studded on Wed, Jun 16, 1999 at 12:14:16PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jun 16, 1999 at 12:14:16PM -0700, Studded wrote: > On Wed, 16 Jun 1999, Jesper Skriver wrote: > > > What version of NFS are you using, we just had a box that hang totally > > when doing a "make installworld" over NFS v3, both server and client > > running -current, it worked fine when we changed to v2 > > I thought of this, but I don't see any config options to downgrade > amd. I'm looking through the source now, but any suggestions welcome. I don't know (don't use amd), but there was a discussion on -current or -hackers a couple of weeks ago, you might want to search the archives. /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 12:38:56 1999 Delivered-To: freebsd-current@freebsd.org Received: from shell7.ba.best.com (shell7.ba.best.com [206.184.139.138]) by hub.freebsd.org (Postfix) with ESMTP id 4AC1B15730 for ; Wed, 16 Jun 1999 12:38:43 -0700 (PDT) (envelope-from spadger@shell7.ba.best.com) Received: (from spadger@localhost) by shell7.ba.best.com (8.9.3/8.9.2/best.sh) id MAA19843 for freebsd-current@FreeBSD.ORG; Wed, 16 Jun 1999 12:38:37 -0700 (PDT) From: Andrew Sparrow Message-Id: <199906161938.MAA19843@shell7.ba.best.com> Subject: Re: Heavily loaded amd gets stuck To: freebsd-current@FreeBSD.ORG Date: Wed, 16 Jun 1999 12:38:37 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > What version of NFS are you using, we just had a box that hang totally > > when doing a "make installworld" over NFS v3, both server and client > > running -current, it worked fine when we changed to v2 Yup, a previously-working AMD config wedged totally when I upgraded to 3.1-RELEASE (from 3.0-STABLE). I installed amd-utils as well - this didn't help ;-( > I thought of this, but I don't see any config options to downgrade > amd. I'm looking through the source now, but any suggestions welcome. I got this off the list, it hits the spot for me: /defaults type:=nfs;opts:=rw,intr,nfsv3,proto=udp,noconn HTH. Cheers, AS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 12:44:19 1999 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id DA89B1526E for ; Wed, 16 Jun 1999 12:44:14 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id MAA69231; Wed, 16 Jun 1999 12:44:03 -0700 (PDT) (envelope-from obrien) Message-ID: <19990616124403.A69195@nuxi.com> Date: Wed, 16 Jun 1999 12:44:03 -0700 From: "David O'Brien" To: Studded , Jesper Skriver Cc: freebsd-current@FreeBSD.ORG Subject: Re: Heavily loaded amd gets stuck Reply-To: obrien@FreeBSD.ORG References: <19990616181108.A3124@skriver.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Studded on Wed, Jun 16, 1999 at 12:14:16PM -0700 X-Operating-System: FreeBSD 3.2-BETA Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > when doing a "make installworld" over NFS v3, both server and client > > running -current, it worked fine when we changed to v2 When saying "NFSv3" one needs to be careful. NFS version X is the NFS protocol version. It does not tell the transport protcol -- ie. UDP or TCP. 3.1-STABLE+ defaults to NFSv3/UDP. It would be quite helpful to know if NFSv3/UDP works for your ``make install'' case. > I thought of this, but I don't see any config options to downgrade > amd. I'm looking through the source now, but any suggestions welcome. Look at the commit message archives and you will see where I hacked Amd to default to UDP over TCP. You can also force the downgrade to NFSv2 there. -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 12:44:54 1999 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 5E1FB15286 for ; Wed, 16 Jun 1999 12:44:50 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id MAA69242; Wed, 16 Jun 1999 12:44:48 -0700 (PDT) (envelope-from obrien) Message-ID: <19990616124448.B69195@nuxi.com> Date: Wed, 16 Jun 1999 12:44:48 -0700 From: "David O'Brien" To: Studded , freebsd-current@FreeBSD.ORG Subject: Re: Heavily loaded amd gets stuck Reply-To: obrien@FreeBSD.ORG References: <3767C2CE.3FFB13BE@gorean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <3767C2CE.3FFB13BE@gorean.org>; from Studded on Wed, Jun 16, 1999 at 08:29:18AM -0700 X-Operating-System: FreeBSD 3.2-BETA Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I have the amd.conf and the map files in place, and amd mounts one Can you post your amd.conf file? -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 12:46:11 1999 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 5961A1526E for ; Wed, 16 Jun 1999 12:46:07 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id MAA69264; Wed, 16 Jun 1999 12:46:05 -0700 (PDT) (envelope-from obrien) Message-ID: <19990616124605.C69195@nuxi.com> Date: Wed, 16 Jun 1999 12:46:05 -0700 From: "David O'Brien" To: Andrew Sparrow , freebsd-current@FreeBSD.ORG Subject: Re: Heavily loaded amd gets stuck Reply-To: obrien@FreeBSD.ORG References: <199906161938.MAA19843@shell7.ba.best.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199906161938.MAA19843@shell7.ba.best.com>; from Andrew Sparrow on Wed, Jun 16, 1999 at 12:38:37PM -0700 X-Operating-System: FreeBSD 3.2-BETA Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I got this off the list, it hits the spot for me: > > /defaults type:=nfs;opts:=rw,intr,nfsv3,proto=udp,noconn IMHO it is clearer to use "vers=3,proto=udp". To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 13:28:40 1999 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 340AA14CEB for ; Wed, 16 Jun 1999 13:28:36 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id NAA01324; Wed, 16 Jun 1999 13:28:23 -0700 Date: Wed, 16 Jun 1999 13:28:21 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Bernd Walter Cc: freebsd-current@FreeBSD.ORG Subject: Re: current GENERIC still panics for me In-Reply-To: <19990616205239.A85743@cicely8.cicely.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hmm! Try taking ahc8 out.... On Wed, 16 Jun 1999, Bernd Walter wrote: > This happend with kernel compiled using GENERIC: > > Console: serial port > BIOS drive A: is disk0 > BIOS drive C: is disk1 > BIOS drive D: is disk2 > > FreeBSD/i386 bootstrap loader, Revision 0.7 636/65472kB > (ticso@cicely5.cicely.de, Mon Jun 14 10:28:01 CEST 1999) > Loading /boot/defaults/loader.conf > /kernel text=0x1e02a3 data=0x23e00+0x1fa6c syms=[0x4+0x27cd0+0x4+0x27da7] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [kernel]... > Copyright (c) 1992-1999 The FreeBSD Project. > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > FreeBSD 4.0-CURRENT #0: Wed Jun 16 22:41:13 CEST 1999 > root@:/var/d0/src-1999-06-14/src/sys/compile/GENERIC > Timecounter "i8254" frequency 1193182 Hz > CPU: AMD-K6tm w/ multimedia extensions (233.03-MHz 586-class CPU) > Origin = "AuthenticAMD" Id = 0x562 Stepping=2 > Features=0x8001bf > real memory = 134217728 (131072K bytes) > sio0: system console > avail memory = 127012864 (124036K bytes) > Preloaded elf kernel "kernel" at 0xc0376000. > Probing for PnP devices: > npx0: on motherboard > npx0: INT 16 interface > pcib0: on motherboard > pci0: on pcib0 > chip0: at device 0.0 on pci0 > isab0: at device 7.0 on pci0 > ide_pci0: at device 7.1 on pci0 > chip1: irq 5 at device 7.2 on pci0 > pcib1: at device 9.0 on pci0 > pci1: on pcib1 > ahc0: irq 5 at device 4.0 on pci1 > ahc0: aic7870 Single Channel A, SCSI Id=7, 16/255 SCBs > ahc1: irq 11 at device 5.0 on pci1 > RAID functionality unsupported > device_probe_and_attach: ahc1 attach returned 6 > ahc2: irq 5 at device 8.0 on pci1 > ahc2: aic7870 Single Channel B, SCSI Id=7, 16/255 SCBs > ahc3: irq 5 at device 12.0 on pci1 > ahc3: aic7870 Single Channel C, SCSI Id=7, 16/255 SCBs > pcib2: at device 10.0 on pci0 > pci2: on pcib2 > ahc4: irq 12 at device 4.0 on pci2 > ahc4: aic7880 Single Channel A, SCSI Id=7, 16/255 SCBs > ahc5: irq 5 at device 5.0 on pci2 > ahc5: aic7880 Single Channel B, SCSI Id=7, 16/255 SCBs > de0: irq 10 at device 11.0 on pci0 > de0: Cogent 21140A [10-100Mb/s] pass 2.0 > de0: address 00:00:92:9b:20:e7 > pcib3: at device 12.0 on pci0 > pci3: on pcib3 > ahc6: irq 11 at device 4.0 on pci3 > ahc6: aic7870 Single Channel A, SCSI Id=7, 16/255 SCBs > ahc7: irq 10 at device 5.0 on pci3 > RAID functionality unsupported > device_probe_and_attach: ahc7 attach returned 6 > ahc8: irq 11 at device 8.0 on pci3 > panic: bus_dmamem_free: Invalid map freed > > Automatic reboot in 15 seconds - press a key on the console to abort > > I already wrote a more complete mail using an older kernel and > a DDB Stack-Trace. > If someone can tell me how I can help debugging this problem I will do it. > The latest kernel I run before this problem was somewhere from April. > Maybe it's releated to newbus changes? > > -- > B.Walter COSMO-Project http://www.cosmo-project.de > ticso@cicely.de info@cosmo-project.de > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 13:54:40 1999 Delivered-To: freebsd-current@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id EBA0A14EB3 for ; Wed, 16 Jun 1999 13:54:36 -0700 (PDT) (envelope-from ticso@cicely8.cicely.de) Received: from cicely7.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.8.6/8.8.6) with ESMTP id WAA13452; Wed, 16 Jun 1999 22:47:32 +0200 (MET DST) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by cicely7.cicely.de (8.9.0/8.9.0) with ESMTP id WAA61878; Wed, 16 Jun 1999 22:54:10 +0200 (CEST) Received: (from ticso@localhost) by cicely8.cicely.de (8.9.3/8.9.2) id WAA86009; Wed, 16 Jun 1999 22:54:54 +0200 (CEST) (envelope-from ticso) Date: Wed, 16 Jun 1999 22:54:53 +0200 From: Bernd Walter To: Matthew Jacob Cc: Bernd Walter , freebsd-current@FreeBSD.ORG Subject: Re: current GENERIC still panics for me Message-ID: <19990616225453.A85987@cicely8.cicely.de> References: <19990616205239.A85743@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Matthew Jacob on Wed, Jun 16, 1999 at 01:28:21PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jun 16, 1999 at 01:28:21PM -0700, Matthew Jacob wrote: > Hmm! Try taking ahc8 out.... > That's not that easy because it's a 3 Channel controler which holds ahc6 to ahc9. But if it might help I will do it tommorrow. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 14: 0: 7 1999 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 5338914F01 for ; Wed, 16 Jun 1999 14:00:01 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id NAA01448; Wed, 16 Jun 1999 13:59:55 -0700 Date: Wed, 16 Jun 1999 13:59:52 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Bernd Walter Cc: freebsd-current@FreeBSD.ORG Subject: Re: current GENERIC still panics for me In-Reply-To: <19990616225453.A85987@cicely8.cicely.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm thinking resource exhaustion.. On Wed, 16 Jun 1999, Bernd Walter wrote: > On Wed, Jun 16, 1999 at 01:28:21PM -0700, Matthew Jacob wrote: > > Hmm! Try taking ahc8 out.... > > > That's not that easy because it's a 3 Channel controler which holds > ahc6 to ahc9. > But if it might help I will do it tommorrow. > > -- > B.Walter COSMO-Project http://www.cosmo-project.de > ticso@cicely.de info@cosmo-project.de > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 15:15:12 1999 Delivered-To: freebsd-current@freebsd.org Received: from nu.binary.net (nu.binary.net [12.13.120.25]) by hub.freebsd.org (Postfix) with ESMTP id E396914C89; Wed, 16 Jun 1999 15:15:07 -0700 (PDT) (envelope-from nathan@rtfm.net) Received: from matrix.binary.net (nathan@matrix.binary.net [12.13.120.2]) by nu.binary.net (8.9.1a/8.9.0) with ESMTP id RAA55609; Wed, 16 Jun 1999 17:15:07 -0500 (CDT) Received: (from nathan@localhost) by matrix.binary.net (8.9.1a/8.9.1) id RAA29382; Wed, 16 Jun 1999 17:15:06 -0500 (CDT) Date: Wed, 16 Jun 1999 18:15:06 -0400 From: Nathan Dorfman To: davec@unforgettable.com Cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: kern/12226: IPFilter breaking with ipl ERROR Message-ID: <19990616181506.A28969@rtfm.net> References: <990615182820EX.12713@weba7.iname.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <990615182820EX.12713@weba7.iname.net>; from davec@unforgettable.com on Tue, Jun 15, 1999 at 06:28:20PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jun 15, 1999 at 06:28:20PM -0400, davec@unforgettable.com wrote: > >Synopsis: In 4.0-current the ipl driver breaks with "bogus cdevsw->d_maj = -1 > >Environment: > > FreeBSD 4.0-Current as of June 15, 1999 > Pentium233MMX, 128MB SDRAM, two UDMA2 HD's, one IDE HD. > PA-2007 motherboard, Matrox MillenniumII vid. 3COM905-TX NIC. > Kernel compiled with IPFILTER, IPFILTER_LOG, and bpfilter. > >Description: > Preloaded elf kernel "kernel" at 0xc030e000. > Intel Pentium detected, installing workaround for F00F bug > ipl: ERROR: driver has bogus cdevsw->d_maj = -1 > > For every rule ipf tries to process, the following error was produced: > > open device: Device not configured > ioctl(SIOCIPFFL): Bad file descriptor I've seen this since at least as early as June 3rd. Haven't said anything because I've not had time to see if there was already a fix, or at least the topic had been brought up. Maybe we're doing something wrong; ipf + ipnat not working at all sounds like something that'd get noticed real quick. Oh yeah, ipnat: # ipnat -l /dev/ipnat: open: Device not configured # grep IPFILTER /sys/i386/conf/LIMBO options IPFILTER options IPFILTER_LOG Same error message as the author of the send-pr above reports. Any ideas? -- Nathan Dorfman The statements and opinions in my Unix Admin @ Frontline Communications public posts are mine, not FCC's. "The light at the end of the tunnel is the headlight of an approaching train." --/usr/games/fortune To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 16: 6:32 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id B0B0D14D8E; Wed, 16 Jun 1999 16:06:26 -0700 (PDT) (envelope-from Studded@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id QAA25093; Wed, 16 Jun 1999 16:06:20 -0700 (PDT) (envelope-from Studded@gorean.org) Date: Wed, 16 Jun 1999 16:06:20 -0700 (PDT) From: Studded X-Sender: doug@dt054n86.san.rr.com To: "David O'Brien" Cc: Studded , freebsd-current@FreeBSD.ORG Subject: Re: Heavily loaded amd gets stuck In-Reply-To: <19990616124448.B69195@nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 16 Jun 1999, David O'Brien wrote: > > I have the amd.conf and the map files in place, and amd mounts one > > Can you post your amd.conf file? 65# more amd.conf [ global ] # Only search for maps of this type map_type = file # Search this path for maps search_path = /etc # Use this directory for amd's private mount points auto_dir = /mnt # How long the mounts should live, in seconds #cache_duration = 1800 # Log all activity to syslog (daemon) log_file = syslog:local7 log_options = all # Check /etc/hosts for hostnames normalize_hostnames = yes # Lock the amd process into memory, improves perf. #plock = yes # Use the special /default entry in maps selectors_on_default = yes # DEFINE AN AMD MOUNT POINT [ /Interfaces ] map_name = amd.Interfaces [ /Hold ] map_name = amd.Hold 67# more amd.Interfaces #/defaults type:=nfs;opts:=rw,nosuid /defaults type:=nfs;opts:=rw,nosuid,vers=2,proto=udp * rhost:=IP${key};rfs:=/Space/${key} 68# more amd.Hold #/defaults type:=nfs;opts:=rw,nosuid /defaults type:=nfs;opts:=rw,nosuid,vers=2,proto=udp netapp01 rhost:=netapp01;rfs:=/vol/Space/Hold * rhost:=${key};rfs:=/Space/Hold Also, here is the info from the log when amd starts up, just in case it's relevant: Jun 16 15:50:11 miva004 amd[137]: AM-UTILS VERSION INFORMATION: Jun 16 15:50:11 miva004 amd[137]: Copyright (c) 1997-1998 Erez Zadok Jun 16 15:50:11 miva004 amd[137]: Copyright (c) 1990 Jan-Simon Pendry Jun 16 15:50:11 miva004 amd[137]: Copyright (c) 1990 Imperial College of Science, Technology & Medicine Jun 16 15:50:11 miva004 amd[137]: Copyright (c) 1990 The Regents of the University of California. Jun 16 15:50:11 miva004 amd[137]: am-utils version 6.0 (build 320001). Jun 16 15:50:11 miva004 amd[137]: Built by root@miva004.simplenet.net on date Tue Jun 15 19:56:13 PDT 1999. Jun 16 15:50:11 miva004 amd[137]: cpu=i386 (little-endian), arch=i386, karch=i386. Jun 16 15:50:11 miva004 amd[137]: full_os=freebsd3.2-19990609-STABLE, os=freebsd3, osver=3.2-19990609-STABLE, vendor=unknown . Jun 16 15:50:11 miva004 amd[137]: Map support for: root, passwd, union, nis, ndbm, file, error. Jun 16 15:50:11 miva004 amd[137]: AMFS: nfs, link, nfsx, nfsl, host, linkx, program, union, inherit, Jun 16 15:50:11 miva004 amd[137]: ufs, lofs, cdfs, pcfs, auto, direct, toplvl, error. Jun 16 15:50:11 miva004 amd[137]: FS: cd9660, lofs, mfs, nfs, nfs3, null, msdos, tfs, ufs, umap, union. Jun 16 15:50:11 miva004 amd[137]: Network: wire="209.132.1.0" (netnumber=209.132.1). Jun 16 15:50:11 miva004 amd[137]: My ip addr is 0xd18401cc Jun 16 15:50:11 miva004 amd[138]: released controlling tty using setsid() Jun 16 15:50:11 miva004 amd[138]: file server localhost type local starts up Jun 16 15:50:11 miva004 amd[138]: Trying mount of /etc/amd.Hold on /Hold fstype toplvl Jun 16 15:50:11 miva004 amd[139]: /Hold: disabling nfs congestion window Jun 16 15:50:11 miva004 amd[138]: Trying mount of /etc/amd.Interfaces on /Interfaces fstype toplvl Jun 16 15:50:11 miva004 amd[140]: /Interfaces: disabling nfs congestion window Jun 16 15:50:11 miva004 amd[138]: initializing amd conf map /etc/amd.Hold of type file Jun 16 15:50:11 miva004 amd[138]: /etc/amd.Hold mounted fstype toplvl on /Hold Jun 16 15:50:11 miva004 amd[138]: initializing amd conf map /etc/amd.Interfaces of type file Jun 16 15:50:11 miva004 amd[138]: /etc/amd.Interfaces mounted fstype toplvl on /Interfaces One note about that, the snap date is incorrect, I built world from yesterday's cvsup. Also, I'm afraid I have bad news, when I ran the script that caused amd to hang last time with the options as in the map file above, this time it caused the whole system to hang, not just amd. To make matters worse, it borked the root filesystem so I had to go hook up the console and go single user to fix it. I am going to do some more experimentation now, but I thought I'd send a progress report. Thanks, Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 17:34:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id BCD3114E3B; Wed, 16 Jun 1999 17:34:44 -0700 (PDT) (envelope-from Studded@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id RAA26733; Wed, 16 Jun 1999 17:34:43 -0700 (PDT) (envelope-from Studded@gorean.org) Date: Wed, 16 Jun 1999 17:34:42 -0700 (PDT) From: Studded X-Sender: doug@dt054n86.san.rr.com To: freebsd-current@FreeBSD.ORG Cc: "David O'Brien" Subject: Re: Heavily loaded amd gets stuck In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 16 Jun 1999, Studded wrote: > caused amd to hang last time with the options as in the map file above, > this time it caused the whole system to hang, not just amd. To make > matters worse, it borked the root filesystem so I had to go hook up the > console and go single user to fix it. > > I am going to do some more experimentation now, but I thought I'd > send a progress report. Using all of the options in the previous message I got the following results when I dropped to the kernel debugger on the hung system: Bunch of stuff I'm assuming isn't important... Xresume1() --- interrupt vop_sharedlock() vn_lock() vrele() nfs_nget() mountnfs() nfs_mount() mount() syscall() Xint0x80_syscall() Now obviously the functions above were actually lines like, vop_sharedlock(bunchofstuffI'massumingarememoryaddresses) at vop_sharedlock(morestuff,etc.) I just ran the test without the "vers=2" option and it's locked up the system again, so I am going to go look at ddb and report back. The machine room is on the other side of the building so I'm shuttling back and forth. I'm also going to try the test with the vers=2 option and without the proto=udp option and see what kind of results I get. HTH, Doug -- *** Chief Operations Officer, DALnet IRC network *** On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 17:42:10 1999 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id ECFE214D10 for ; Wed, 16 Jun 1999 17:41:59 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id RAA16280; Wed, 16 Jun 1999 17:41:56 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id RAA66302; Wed, 16 Jun 1999 17:41:55 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Wed, 16 Jun 1999 17:41:55 -0700 (PDT) Message-Id: <199906170041.RAA66302@vashon.polstra.com> To: sobomax@altavista.net Subject: Re: Quiestion about /usr/libexec/ld-elf.so.1 In-Reply-To: <375D258E.FCAB01B6@altavista.net> Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <375D258E.FCAB01B6@altavista.net>, Maxim Sobolev wrote: > Does anybody know any legacy way to upgrade ld-elf.so.1 when making > world or it always should be reinstalled manually? Huh? It is installed by make world, just like everything else. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 17:42:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 3D84F15189 for ; Wed, 16 Jun 1999 17:42:40 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA32930; Wed, 16 Jun 1999 17:42:38 -0700 (PDT) (envelope-from dillon) Date: Wed, 16 Jun 1999 17:42:38 -0700 (PDT) From: Matthew Dillon Message-Id: <199906170042.RAA32930@apollo.backplane.com> To: "David E. Cross" , David Scheidt , Chan Yiu Wah , freebsd-current@FreeBSD.ORG Subject: NFS Test patch #2 available for -CURRENT (patch as of last night) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ( David, this is the same one you are already messing with - B2 ) I've been running my second patch as of last night with no problems so far. A couple of buildworlds with /usr/src and /usr/obj mounted via NFS, various stress tests, the create/remove test, and a few others. No problems so far. In fact, the machine has been disturbingly stable. http://www.backplane.com/FreeBSD4/ The patch is still just for -CURRENT. If it survives the next day or two I think it will be worth comitting, and then MFC'ing into -STABLE despite the complexity. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 18:19:58 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id C8F9914C03 for ; Wed, 16 Jun 1999 18:19:38 -0700 (PDT) (envelope-from Studded@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id SAA27086; Wed, 16 Jun 1999 18:19:35 -0700 (PDT) (envelope-from Studded@gorean.org) Date: Wed, 16 Jun 1999 18:19:35 -0700 (PDT) From: Studded X-Sender: doug@dt054n86.san.rr.com To: "David O'Brien" Cc: freebsd-current@freebsd.org Subject: Re: Heavily loaded amd gets stuck In-Reply-To: <19990616180131.A54575@dragon.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 16 Jun 1999, David O'Brien wrote: > > without the proto=udp option and see what kind of results I get. > > Rather than (or in addtion to) not using "proto=udp" use "proto=tcp". > The default in 3.2 is UDP, so removing the directive should not do > anything. Well, I've already done the tests, but thanks for the tip. :) Recapping, I have the following map file: /defaults type:=nfs;opts:=rw,nosuid * rhost:=IP${key};rfs:=/Space/${key} Adding to /defaults both the options "vers=2,proto=udp" yielded the kernel crash and ddb traceback I posted previously. With the above and just "proto=udp" I got the following: Xresume1() --- interrupt splx() nfs_nget() mountnfs() nfs_mount() mount() syscall() Xint0x80_syscall() The last 6 are identical in the first test, this test, and the test below. With the above map and adding only the option "vers=2" I got the following traceback: Xresume1() --- interrupt zfreei() nfs_reclaim() vclean() vgonel() getnewvnode() nfs_nget().... (last 6 same as above). If there is any more information you need, ddb commands to do, whatever just let me know. I will run a test now with the above map and add proto=tcp and see what I get. I'm only going to be at work tonight till 6:30 PDT, but (at this point) I have the Ok to work on it till it's fixed, so I can start again tomorrow morning. I am *highly* motivated to fix it since I've been pushing to use FreeBSD for several months, and now it's not working. To add insult to injury, the linux box that is my "competition" is up and running, using the amd-utils 6.0 (the same, yes?) and not having any problems. In case it matters, the box is a dual PIII-500 with a gig of ram. SMP is running fine, all the ram is recognized, completed a make world ok, etc. It's got an intel etherexpress pro 100 card running at 100 full duplex. Any other details you need, just let me know. Also, should I be considering a move to -current for this box? Is -current stable enough right now to run a fairly heavily loaded web server? If the NFS in -current is going to be doing better than what's in -stable it will be worth a little headache to change, since our structure depends on it heavily. Thank you very much for the help, Doug -- *** Chief Operations Officer, DALnet IRC network *** On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 16 18:32:53 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id 1BFD514C05 for ; Wed, 16 Jun 1999 18:32:40 -0700 (PDT) (envelope-from Studded@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id SAA27167; Wed, 16 Jun 1999 18:32:36 -0700 (PDT) (envelope-from Studded@gorean.org) Date: Wed, 16 Jun 1999 18:32:36 -0700 (PDT) From: Studded X-Sender: doug@dt054n86.san.rr.com To: freebsd-current@freebsd.org Cc: "David O'Brien" Subject: Re: Heavily loaded amd gets stuck In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Running the test with the "proto=tcp" option gave the same results in the kernel backtrace as did "proto=udp," namely: Xresume1() --- interrupt splx() nfs_nget() mountnfs() nfs_mount() mount() syscall() Xint0x80_syscall() The last 6 are identical in all the tests I've done. Thanks again, Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 0:20: 1 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id B3FEE14C94; Thu, 17 Jun 1999 00:19:57 -0700 (PDT) (envelope-from Studded@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id AAA28924; Thu, 17 Jun 1999 00:19:54 -0700 (PDT) (envelope-from Studded@gorean.org) Message-ID: <3768A199.DA9CB5AB@gorean.org> Date: Thu, 17 Jun 1999 00:19:53 -0700 From: Studded Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Sam Stephenson Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: 'w' patch References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sam Stephenson wrote: > > There seem to be two problems (not even problems; more like annoyances) that > exist in the 'w' command, both which involve unnecessary spacing that limits > the size of the WHAT field. I have attached a patch to > /usr/src/usr.bin/w/w.c which corrects the following: You might want to check the mail archives and the PR's... a couple of us did similar work about a year ago and ran into similar problems. At the time there was no interest in the purely cosmetic commits, IIRC. Doug -- *** Chief Operations Officer, DALnet IRC network *** Nominated for quote of the year is the statement made by Representative Dick Armey (Texas), who when asked if he were in the President's place, would he resign, responded: "If I were in the President's place I would not get a chance to resign. I would be lying in a pool of my own blood hearing Mrs. Armey standing over me saying, 'How do I reload this damn thing?'" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 2:22: 2 1999 Delivered-To: freebsd-current@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 644B314DEA for ; Thu, 17 Jun 1999 02:21:55 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 10uYMs-000IsD-00 for current@freebsd.org; Thu, 17 Jun 1999 11:21:54 +0200 From: Sheldon Hearn To: current@freebsd.org Subject: HEADS UP! Inetd's TCP Wrappers support changed Date: Thu, 17 Jun 1999 11:21:54 +0200 Message-ID: <72552.929611314@axl.noc.iafrica.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, My recent commit to inetd is probably worth a mention in UPDATING for two reasons: 1) Previously allowed builtin services (e.g. daytime) may be denied in existing configurations. Existing hosts.allow configurations may need to be reviewed. 2) The syslog selector requested in hosts.allow is now honoured. Existing syslog.conf configurations relying on broken inetd behaviour may need to be fixed. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 9:19:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from io.checker.org (h24-66-174-118.xx.wave.shaw.ca [24.66.174.118]) by hub.freebsd.org (Postfix) with ESMTP id 41F2C14BDA for ; Thu, 17 Jun 1999 09:19:16 -0700 (PDT) (envelope-from jake@checker.org) Received: from io.checker.org (localhost [127.0.0.1]) by io.checker.org (Postfix) with ESMTP id 27172D6 for ; Thu, 17 Jun 1999 09:18:27 -0700 (PDT) X-Mailer: exmh version 2.0.2 2/24/98 To: current@freebsd.org Subject: vinum in -current Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jun 1999 09:18:27 -0700 From: Jake Burkholder Message-Id: <19990617161828.27172D6@io.checker.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, /sys/modules/Makefile: # XXX vinum removed pending cdevsw changes review by grog. will a module from before the change (May 23rd) work with a new kernel? or can the patches that were sent be made available? Thank you, -- FreeBSD: The ultimate Linux kernel patch. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 10: 7:57 1999 Delivered-To: freebsd-current@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id CF23214F44 for ; Thu, 17 Jun 1999 10:05:53 -0700 (PDT) (envelope-from ticso@cicely8.cicely.de) Received: from cicely7.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.8.6/8.8.6) with ESMTP id SAA04219; Thu, 17 Jun 1999 18:58:48 +0200 (MET DST) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by cicely7.cicely.de (8.9.0/8.9.0) with ESMTP id TAA64663; Thu, 17 Jun 1999 19:05:27 +0200 (CEST) Received: (from ticso@localhost) by cicely8.cicely.de (8.9.3/8.9.2) id TAA87769; Thu, 17 Jun 1999 19:06:12 +0200 (CEST) (envelope-from ticso) Date: Thu, 17 Jun 1999 19:06:12 +0200 From: Bernd Walter To: Matthew Jacob Cc: Bernd Walter , freebsd-current@FreeBSD.ORG Subject: Re: current GENERIC still panics for me Message-ID: <19990617190611.A87753@cicely8.cicely.de> References: <19990616225453.A85987@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Matthew Jacob on Wed, Jun 16, 1999 at 01:59:52PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jun 16, 1999 at 01:59:52PM -0700, Matthew Jacob wrote: > > I'm thinking resource exhaustion.. > OK it's getting up without the card. > On Wed, 16 Jun 1999, Bernd Walter wrote: > > > On Wed, Jun 16, 1999 at 01:28:21PM -0700, Matthew Jacob wrote: > > > Hmm! Try taking ahc8 out.... > > > > > That's not that easy because it's a 3 Channel controler which holds > > ahc6 to ahc9. > > But if it might help I will do it tommorrow. > > > > -- > > B.Walter COSMO-Project http://www.cosmo-project.de > > ticso@cicely.de info@cosmo-project.de > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > > -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 11:27:51 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id 6C1CB14BD0 for ; Thu, 17 Jun 1999 11:27:40 -0700 (PDT) (envelope-from Studded@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id LAA03932; Thu, 17 Jun 1999 11:27:37 -0700 (PDT) (envelope-from Studded@gorean.org) Date: Thu, 17 Jun 1999 11:27:37 -0700 (PDT) From: Studded X-Sender: doug@dt054n86.san.rr.com To: Studded Cc: freebsd-current@freebsd.org, "David O'Brien" Subject: Re: Heavily loaded amd gets stuck In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 16 Jun 1999, Studded wrote: > Running the test with the "proto=tcp" option gave the same results > in the kernel backtrace as did "proto=udp," namely: > > Xresume1() > --- interrupt > splx() > nfs_nget() > mountnfs() > nfs_mount() > mount() > syscall() > Xint0x80_syscall() > > The last 6 are identical in all the tests I've done. At someone else's suggestions I tried the following: /defaults type:=nfs;opts:=rw,nosuid,vers=3,intr,proto=udp,noconn still with no joy. I did get a slighly different kernel trace though: Xresume1() --- interrupt vop_nounlock() vop_defaultop() nfs_inactive() vrele() Then the same last 6 functions as in all the other tests. Next step, I'm going to upgrade the box to -current and see if that helps. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 12:18:31 1999 Delivered-To: freebsd-current@freebsd.org Received: from par28.ma.ikos.com (par28.ma.ikos.com [137.103.105.228]) by hub.freebsd.org (Postfix) with ESMTP id DAD4014F4C for ; Thu, 17 Jun 1999 12:18:22 -0700 (PDT) (envelope-from tich@par28.ma.ikos.com) Received: (from tich@localhost) by par28.ma.ikos.com (8.8.7/8.8.7) id PAA14027 for freebsd-current@FreeBSD.org; Thu, 17 Jun 1999 15:18:42 -0400 Date: Thu, 17 Jun 1999 15:18:42 -0400 From: Richard Cownie Message-Id: <199906171918.PAA14027@par28.ma.ikos.com> To: freebsd-current@FreeBSD.org Subject: 4GB dram Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I still can't get a machine with 4GB dram to work. When was the last time anyone succeeded in running -CURRENT on a machine with 4GB dram ? This was working for me with 19990421-CURRENT, it doesn't work in 19990604-CURRENT. Since support for 4GB dram is the only reason I'm running -CURRENT rather than -STABLE, I would really like to know when this might get fixed. Thanks Richard Cownie (tich@ma.ikos.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 12:24:42 1999 Delivered-To: freebsd-current@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 5ABD414FAC for ; Thu, 17 Jun 1999 12:24:39 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id MAA09038; Thu, 17 Jun 1999 12:24:03 -0700 (PDT) Message-Id: <199906171924.MAA09038@implode.root.com> To: Richard Cownie Cc: freebsd-current@FreeBSD.ORG Subject: Re: 4GB dram In-reply-to: Your message of "Thu, 17 Jun 1999 15:18:42 EDT." <199906171918.PAA14027@par28.ma.ikos.com> From: David Greenman Reply-To: dg@root.com Date: Thu, 17 Jun 1999 12:24:03 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I still can't get a machine with 4GB dram to work. When was the last >time anyone succeeded in running -CURRENT on a machine with 4GB dram ? >This was working for me with 19990421-CURRENT, it doesn't work in >19990604-CURRENT. Since support for 4GB dram is the only reason >I'm running -CURRENT rather than -STABLE, I would really like to know >when this might get fixed. You need to provide more information - specifically, what happens when you try? -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 13: 9:20 1999 Delivered-To: freebsd-current@freebsd.org Received: from par28.ma.ikos.com (par28.ma.ikos.com [137.103.105.228]) by hub.freebsd.org (Postfix) with ESMTP id E8AE8155AB for ; Thu, 17 Jun 1999 13:09:11 -0700 (PDT) (envelope-from tich@par28.ma.ikos.com) Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by par28.ma.ikos.com (8.8.7/8.8.7) id QAA14119; Thu, 17 Jun 1999 16:08:44 -0400 From: Richard Cownie To: dg@root.com, David Greenman Subject: Re: 4GB dram Date: Thu, 17 Jun 1999 15:55:11 -0400 X-Mailer: KMail [version 1.1.0] Content-Type: text/plain Cc: freebsd-current@FreeBSD.ORG References: <199906171924.MAA09038@implode.root.com> MIME-Version: 1.0 Message-Id: <99061716084400.14101@par28.ma.ikos.com> Content-Transfer-Encoding: 8bit X-KMail-Mark: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 17 Jun 1999, David Greenman wrote: > >I still can't get a machine with 4GB dram to work. When was the last > >time anyone succeeded in running -CURRENT on a machine with 4GB dram ? > >This was working for me with 19990421-CURRENT, it doesn't work in > >19990604-CURRENT. Since support for 4GB dram is the only reason > >I'm running -CURRENT rather than -STABLE, I would really like to know > >when this might get fixed. > > You need to provide more information - specifically, what happens when you > try? > > -DG boot: kernel.4G -v Too many holes in the physical address space, giving up Copyright (c) .... Copyright (c) .... Fatal trap 12: page fault while in kernel mode ... As I've noted earlier, the getmemsize() code doesn't appear very safe w.r.t. 4GB limits. I tried rewriting to simplify this code and avoid these problems - with the rewritten version I got further, but then had a different crash later (but that could be due to a bug in my rewrite). It's desperately painful to debug this, because as far as I know the only way to get any kernel to boot is to power down the machine, physically unplug one of the dimms, power up again, install new kernel, power down, plug the dimm back in ... If I could fit the kernel on a floppy the debugging cycle would be much quicker, but it seems too big for that. Since the debugging is so painful, I would really like to find the latest version that worked with 4GB, so that I can eyeball a minimal set of source code changes. Richard Cownie (tich@ma.ikos.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 13:24:51 1999 Delivered-To: freebsd-current@freebsd.org Received: from shell.webmaster.com (mail.webmaster.com [209.133.28.73]) by hub.freebsd.org (Postfix) with ESMTP id 5EDB3154E0 for ; Thu, 17 Jun 1999 13:24:48 -0700 (PDT) (envelope-from davids@webmaster.com) Received: from whenever ([209.133.29.2]) by shell.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Thu, 17 Jun 1999 13:24:47 -0700 From: "David Schwartz" To: "Richard Cownie" Cc: Subject: RE: 4GB dram Date: Thu, 17 Jun 1999 13:24:47 -0700 Message-ID: <000301beb8ff$71b06730$021d85d1@whenever.youwant.to> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <99061716084400.14101@par28.ma.ikos.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It's desperately painful to debug this, because as far as I know the > only way to get any kernel to boot is to power down the machine, > physically > unplug one of the dimms, power up again, install new kernel, power down, > plug the dimm back in ... If I could fit the kernel on a floppy the > debugging cycle would be much quicker, but it seems too big for that. Setting MAXMEM to 2Gb doesn't allow the kernel to boot? Perhaps there's something wrong with the way MAXMEM is implemented. DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 13:41:46 1999 Delivered-To: freebsd-current@freebsd.org Received: from par28.ma.ikos.com (par28.ma.ikos.com [137.103.105.228]) by hub.freebsd.org (Postfix) with ESMTP id 6B8A6155A4 for ; Thu, 17 Jun 1999 13:41:41 -0700 (PDT) (envelope-from tich@par28.ma.ikos.com) Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by par28.ma.ikos.com (8.8.7/8.8.7) id QAA14131; Thu, 17 Jun 1999 16:41:57 -0400 From: Richard Cownie To: "David Schwartz" Subject: RE: 4GB dram Date: Thu, 17 Jun 1999 16:32:12 -0400 X-Mailer: KMail [version 1.1.0] Content-Type: text/plain Cc: References: <000301beb8ff$71b06730$021d85d1@whenever.youwant.to> MIME-Version: 1.0 Message-Id: <99061716415701.14101@par28.ma.ikos.com> Content-Transfer-Encoding: 8bit X-KMail-Mark: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 17 Jun 1999, David Schwartz wrote: > > It's desperately painful to debug this, because as far as I know the > > only way to get any kernel to boot is to power down the machine, > > physically > > unplug one of the dimms, power up again, install new kernel, power down, > > plug the dimm back in ... If I could fit the kernel on a floppy the > > debugging cycle would be much quicker, but it seems too big for that. > > Setting MAXMEM to 2Gb doesn't allow the kernel to boot? Perhaps there's > something wrong with the way MAXMEM is implemented. > > DS I believe that MAXMEM doesn't work the way it used to - I think the trouble is that getmemsize() now has a nested loop, and the way it looks at Maxmem/MAXMEM doesn't do much to break it out of the outer loop. I would have to try another experiment to be 100% sure that this doesn't work (earlier experiments were confused by the fact that 4 cpu's don't work, so I'm trying to deal with 2 independent problems); and I've given up the machine for now. But I don't think it works. Richard Cownie (tich@ma.ikos.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 13:55: 5 1999 Delivered-To: freebsd-current@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 6322E155A4 for ; Thu, 17 Jun 1999 13:55:01 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id OAA89992; Thu, 17 Jun 1999 14:54:52 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199906172054.OAA89992@panzer.plutotech.com> Subject: Re: 4GB dram In-Reply-To: <99061716084400.14101@par28.ma.ikos.com> from Richard Cownie at "Jun 17, 1999 03:55:11 pm" To: tich@ma.ikos.com (Richard Cownie) Date: Thu, 17 Jun 1999 14:54:52 -0600 (MDT) Cc: dg@root.com (David Greenman), freebsd-current@FreeBSD.ORG 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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Richard Cownie wrote... > On Thu, 17 Jun 1999, David Greenman wrote: > > >I still can't get a machine with 4GB dram to work. When was the last > > >time anyone succeeded in running -CURRENT on a machine with 4GB dram ? > > >This was working for me with 19990421-CURRENT, it doesn't work in > > >19990604-CURRENT. Since support for 4GB dram is the only reason > > >I'm running -CURRENT rather than -STABLE, I would really like to know > > >when this might get fixed. > > > > You need to provide more information - specifically, what happens when you > > try? > > > > -DG > > boot: kernel.4G -v > Too many holes in the physical address space, giving up > Copyright (c) .... > Copyright (c) .... > > Fatal trap 12: page fault while in kernel mode > ... > > As I've noted earlier, the getmemsize() code doesn't appear very safe > w.r.t. 4GB limits. I tried rewriting to simplify this code and avoid > these problems - with the rewritten version I got further, but then > had a different crash later (but that could be due to a bug in my > rewrite). > > It's desperately painful to debug this, because as far as I know the > only way to get any kernel to boot is to power down the machine, physically > unplug one of the dimms, power up again, install new kernel, power down, > plug the dimm back in ... If I could fit the kernel on a floppy the > debugging cycle would be much quicker, but it seems too big for that. One thing I did once was to put a stripped-down kernel on a UFS-formatted floppy. (I took out everything I could to get it down to a size that would fit on a floppy) Then, from the boot loader, you can do something like: load disk0:/kernel boot Or something like that. You may have to set one of the boot loader variables to get the thing to boot off your hard disk. You should be able to strip a kernel down enough to fit it on a floppy, although you will have to specify some non-standard options. Two options that you'll want to use are: options SCSI_NO_SENSE_STRINGS options SCSI_NO_OP_STRINGS That will disable SCSI sense code and op code description strings. > Since the debugging is so painful, I would really like to find the latest > version that worked with 4GB, so that I can eyeball a minimal set of source > code changes. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 14: 4:59 1999 Delivered-To: freebsd-current@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 0206214C4E for ; Thu, 17 Jun 1999 14:04:51 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id QAA24328; Thu, 17 Jun 1999 16:04:47 -0500 (CDT) Received: from free.pcs (free.PCS [148.105.10.51]) by right.PCS (8.6.13/8.6.4) with ESMTP id QAA06709; Thu, 17 Jun 1999 16:04:46 -0500 Received: (from jlemon@localhost) by free.pcs (8.8.6/8.8.5) id QAA22289; Thu, 17 Jun 1999 16:04:45 -0500 (CDT) Date: Thu, 17 Jun 1999 16:04:45 -0500 (CDT) From: Jonathan Lemon Message-Id: <199906172104.QAA22289@free.pcs> To: tich@ma.ikos.com, current@freebsd.org Subject: Re: 4GB dram X-Newsgroups: local.mail.freebsd-current In-Reply-To: References: Organization: Architecture and Operating System Fanatics Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >On Thu, 17 Jun 1999, David Greenman wrote: >> >I still can't get a machine with 4GB dram to work. When was the last >> >time anyone succeeded in running -CURRENT on a machine with 4GB dram ? >> >This was working for me with 19990421-CURRENT, it doesn't work in >> >19990604-CURRENT. Since support for 4GB dram is the only reason >> >I'm running -CURRENT rather than -STABLE, I would really like to know >> >when this might get fixed. >> >> You need to provide more information - specifically, what happens when you >> try? >> >> -DG > >boot: kernel.4G -v >Too many holes in the physical address space, giving up This indicates too many discontinuties for the phys_avail[] array to handle; you can try increasing the array size in machdep.c. >As I've noted earlier, the getmemsize() code doesn't appear very safe >w.r.t. 4GB limits. I tried rewriting to simplify this code and avoid >these problems - with the rewritten version I got further, but then >had a different crash later (but that could be due to a bug in my >rewrite). The getmemsize() code first interrogates the BIOS in order to build up a map of physical memory; the BIOS returns the map as a 64bit quantity, which is then forced into vm_offset_t, a 32bit quantity on the x86. This map is then passed to some code which performs memory checking, and is given the chance to 'veto' some of the memory ranges (like where the kernel lives, or artificially by MAXMEM). The resulting map is stored in the phys_avail[] array, which is used by the rest of the pmap code. The older memsize code in effect only had two ranges: (page 1 - bottom of ISA hole), and (end of kernel - top of memory). The only significant difference for the new code is that it supports multiple ranges, so I'm a little unsure why it would be unsafe for 4GB. Can you capture the SMAP lines that are output during the boot process? The specific information regarding the kernel panic would help also. >It's desperately painful to debug this, because as far as I know the >only way to get any kernel to boot is to power down the machine, physically >unplug one of the dimms, power up again, install new kernel, power down, >plug the dimm back in ... If I could fit the kernel on a floppy the >debugging cycle would be much quicker, but it seems too big for that. > >Since the debugging is so painful, I would really like to find the latest >version that worked with 4GB, so that I can eyeball a minimal set of source >code changes. As dg said, can you bring the system up by limiting MAXMEM? (either build a custom kernel, or set MAXMEM with npx0 size). If I've inadverdently broken MAXMEM, I'd like to know about it. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 14:18: 9 1999 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id EB0AC14C4E for ; Thu, 17 Jun 1999 14:18:04 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40323>; Fri, 18 Jun 1999 07:01:14 +1000 Date: Fri, 18 Jun 1999 07:17:54 +1000 From: Peter Jeremy Subject: CTM cvs-cur missing To: freebsd-current@FreeBSD.ORG Message-Id: <99Jun18.070114est.40323@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've just noticed that the last cvs-cur delta I received was ~28 hours ago. Is this related to the cvs-src problem that was discussed yesterday, or is this something new. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 14:30:25 1999 Delivered-To: freebsd-current@freebsd.org Received: from arnold.neland.dk (mail.neland.dk [194.255.12.232]) by hub.freebsd.org (Postfix) with ESMTP id 3FA6214CF0 for ; Thu, 17 Jun 1999 14:30:18 -0700 (PDT) (envelope-from leifn@neland.dk) Received: from localhost (localhost [127.0.0.1]) by arnold.neland.dk (8.9.3/8.9.3) with ESMTP id XAA98956 for ; Thu, 17 Jun 1999 23:30:11 +0200 (CEST) (envelope-from leifn@neland.dk) Date: Thu, 17 Jun 1999 23:30:11 +0200 (CEST) From: Leif Neland To: freebsd-current@FreeBSD.ORG Subject: kernel -c crashes on exit Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (btw, does anyone here know if a Linux kernel can reboot automatically after a crash? Nobody on the linux-lists I have found can answer... Anyway, back to FBSD:) If I enter config-mode at boot (kernel -c), the machine crashes when trying to save and exit. Fatal trap 12: page fault while in kernel mode. Fault virtual address = 0x4 Fault code = supervisor read, page not present Instruction pointer = 0x8:0xc020028e Stack pointer = 0x10:0xc02e0ecc Frame pointer = 0x10:0xc02e0eec 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 = Idle Interrupt mask = net tty bio cam kernel: type 12 trap, code = 0 Stopped at +xc020028e: movl 0x4(%eax),%edx db> ------8<-------------------------------------------------- config: machine i386 cpu I686_CPU ident "GINA" maxusers 32 options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000 #Be pessimistic about Joe SCSI device options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options DDB controller isa0 controller pnp0 # PnP support for ISA controller eisa0 controller pci0 controller fdc0 at isa? port IO_FD1 irq 6 drq 2 disk fd0 at fdc0 drive 0 controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0 at atkbdc? irq 12 device vga0 at isa? port ? conflicts pseudo-device splash device sc0 at isa? device npx0 at nexus? port IO_NPX irq 13 device apm0 at nexus? disable flags 0x31 # Advanced Power Management device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 device ppc0 at isa? port? irq 7 controller ppbus0 device lpt0 at ppbus? device ppi0 at ppbus? device ed0 at isa? port 0x2c0 irq 5 iomem 0xd8000 pseudo-device loop pseudo-device ether pseudo-device tun 2 pseudo-device pty 16 pseudo-device gzip # Exec gzipped a.out's options KTRACE #kernel tracing options SYSVSHM options SYSVMSG options SYSVSEM pseudo-device bpfilter 4 #Berkeley packet filter device pcm0 device pca0 at isa? port IO_TIMER1 controller ata0 device atadisk0 # ATA disk drives device atapicd0 # ATAPI CDROM drives options SOFTUPDATES pseudo-device sppp #Generic Synchronous PPP --------------8<------------------------------------------------- dmesg: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #42: Tue Jun 15 06:51:44 CEST 1999 root@gina.neland.dk:/usr/src/sys/compile/GINA Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (337.50-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping=2 Features=0x183f9ff real memory = 67096576 (65524K bytes) sio0: system console avail memory = 62345216 (60884K bytes) Preloaded elf kernel "kernel" at 0xc02cd000. Pentium Pro MTRR support enabled, default memory type is uncacheable Probing for PnP devices: CSN 1 Vendor ID: SDA0150 [0x5001814c] Serial 0x00a03244 Comp ID: @@@0000 [0x00000000] npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 chip0: at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vga-pci0: at device 0.0 on pci1 isab0: at device 4.0 on pci0 ata-pci0: at device 4.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 chip1: irq 5 at device 4.2 on pci0 chip2: at device 4.3 on pci0 es0: irq 5 at device 10.0 on pci0 pcm0: using I/O space register mapping at 0xd000 ed0: irq 10 at device 12.0 on pci0 ed0: address 00:80:ad:50:40:cf, type NE2000 (16 bit) devclass_alloc_unit: ed0 already exists, using next available unit number isa0: on motherboard fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> at fdc0 drive 0 atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: on isa0 sc0: on isa0 sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A 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 lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 pca0 at port 0x40 on isa0 pca0: PC speaker audio driver ata0: master: setting up UDMA2 mode on PIIX4 chip OK ad0: ATA-4 disk at ata0 as master ad0: 6197MB (12692295 sectors), 13431 cyls, 15 heads, 63 S/T, 512 B/S ad0: piomode=4, dmamode=2, udmamode=2 ad0: 16 secs/int, 31 depth queue, DMA mode changing root device to wd0s3a -----------------8<----------------------------------------------- Oh, if I enable isdnd, the machine crashes on incoming calls, but let's fix this first... Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 15: 9:19 1999 Delivered-To: freebsd-current@freebsd.org Received: from freja.webgiro.com (freja.webgiro.com [212.209.29.10]) by hub.freebsd.org (Postfix) with ESMTP id DC02814E1C for ; Thu, 17 Jun 1999 15:09:09 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by freja.webgiro.com (Postfix, from userid 1001) id ECBE618F7; Fri, 18 Jun 1999 00:09:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by freja.webgiro.com (Postfix) with ESMTP id E9D2A49CC; Fri, 18 Jun 1999 00:09:04 +0200 (CEST) Date: Fri, 18 Jun 1999 00:09:03 +0200 (CEST) From: Andrzej Bialecki To: Richard Cownie Cc: David Greenman , freebsd-current@FreeBSD.ORG Subject: Re: 4GB dram In-Reply-To: <99061716084400.14101@par28.ma.ikos.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 17 Jun 1999, Richard Cownie wrote: > It's desperately painful to debug this, because as far as I know the > only way to get any kernel to boot is to power down the machine, physically > unplug one of the dimms, power up again, install new kernel, power down, > plug the dimm back in ... If I could fit the kernel on a floppy the > debugging cycle would be much quicker, but it seems too big for that. ??? It's hard to believe you can't fit a gzipped kernel on the floppy... unless it's a 360kB one. The loader will boot it just fine. Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 15:24:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 1676014FE0 for ; Thu, 17 Jun 1999 15:24:19 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id RAA24680; Thu, 17 Jun 1999 17:24:16 -0500 (CDT) Received: from free.pcs (free.PCS [148.105.10.51]) by right.PCS (8.6.13/8.6.4) with ESMTP id RAA16144; Thu, 17 Jun 1999 17:24:15 -0500 Received: (from jlemon@localhost) by free.pcs (8.8.6/8.8.5) id RAA22474; Thu, 17 Jun 1999 17:24:15 -0500 (CDT) Date: Thu, 17 Jun 1999 17:24:15 -0500 (CDT) From: Jonathan Lemon Message-Id: <199906172224.RAA22474@free.pcs> To: tich@ma.ikos.com, current@freebsd.org Subject: Re: 4GB dram X-Newsgroups: local.mail.freebsd-current In-Reply-To: References: Organization: Architecture and Operating System Fanatics Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >On Thu, 17 Jun 1999, David Schwartz wrote: >> > It's desperately painful to debug this, because as far as I know the >> > only way to get any kernel to boot is to power down the machine, >> > physically >> > unplug one of the dimms, power up again, install new kernel, power down, >> > plug the dimm back in ... If I could fit the kernel on a floppy the >> > debugging cycle would be much quicker, but it seems too big for that. >> >> Setting MAXMEM to 2Gb doesn't allow the kernel to boot? Perhaps there's >> something wrong with the way MAXMEM is implemented. >> >> DS > >I believe that MAXMEM doesn't work the way it used to - I think the trouble >is that getmemsize() now has a nested loop, and the way it looks at >Maxmem/MAXMEM doesn't do much to break it out of the outer loop. The outer loop walks through the list of physical memory segments. The inner loop walks through each page in the segment. The inner loop is terminated when we've hit the smaller of: 1. the end of one of the physical memory segments 2. our artifically constrained MAXMEM. The outer loop isn't terminated early, but if there are more physical segments after case 2 above, they are ignored, as the inner loop is completely skipped. Initially, we set Maxmem to the end of the last physical memory segment, so it's identical to case 1 above. I just built a kernel with a smaller MAXMEM than physical memory, and is appears to work as advertised, but then, I don't have 2-4G of memory in my machine. :-) -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 15:56:45 1999 Delivered-To: freebsd-current@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 98FC214E2D for ; Thu, 17 Jun 1999 15:56:37 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id IAA06864; Fri, 18 Jun 1999 08:26:33 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id IAA54727; Fri, 18 Jun 1999 08:26:41 +0930 (CST) Date: Fri, 18 Jun 1999 08:26:41 +0930 From: Greg Lehey To: Jake Burkholder Cc: FreeBSD current users Subject: Re: vinum in -current Message-ID: <19990618082641.C9893@freebie.lemis.com> References: <19990617161828.27172D6@io.checker.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990617161828.27172D6@io.checker.org>; from Jake Burkholder on Thu, Jun 17, 1999 at 09:18:27AM -0700 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 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 17 June 1999 at 9:18:27 -0700, Jake Burkholder wrote: > Hi, > > /sys/modules/Makefile: > # XXX vinum removed pending cdevsw changes review by grog. > > will a module from before the change (May 23rd) work with a new kernel? > or can the patches that were sent be made available? Ugh. Somebody (I know who, but I'm not going to put him to shame in public) told me that phk had committed the changes. I didn't know that jb then went and removed them. I know we've been flaming phk for committing changes without reference, but since I was unreachable for a long time, I believe this was the correct thing to do. I'll review the changes and reenable the build. Sorry for the delay. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 16:11:41 1999 Delivered-To: freebsd-current@freebsd.org Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id D683914BD4 for ; Thu, 17 Jun 1999 16:11:27 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.1/8.9.1) id JAA26367; Fri, 18 Jun 1999 09:35:26 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199906172335.JAA26367@cimlogic.com.au> Subject: Re: vinum in -current In-Reply-To: <19990618082641.C9893@freebie.lemis.com> from Greg Lehey at "Jun 18, 1999 8:26:41 am" To: grog@lemis.com (Greg Lehey) Date: Fri, 18 Jun 1999 09:35:21 +1000 (EST) Cc: jake@checker.org, FreeBSD-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Lehey wrote: > On Thursday, 17 June 1999 at 9:18:27 -0700, Jake Burkholder wrote: > > Hi, > > > > /sys/modules/Makefile: > > # XXX vinum removed pending cdevsw changes review by grog. > > > > will a module from before the change (May 23rd) work with a new kernel? > > or can the patches that were sent be made available? > > Ugh. Somebody (I know who, but I'm not going to put him to shame in > public) told me that phk had committed the changes. I didn't know > that jb then went and removed them. I know we've been flaming phk for > committing changes without reference, but since I was unreachable for > a long time, I believe this was the correct thing to do. I'll review > the changes and reenable the build. Sorry for the delay. Hey, that's not true! phk noted in his commit message for all the _other_ stuff that he had posted vinum and i4b patches to the respective owners for review. I sent him mail saying that you were travelling and that he probably should commit the vinum patches without the review. He said he would prefer to take vinum out of the build instead. He said he would be offline for a few hours and if I was online, would I go ahead and make the commit. So I committed just the makefile change to prevent the build from failing. Check the cvs history and you will find _no_ vinum commits from me! -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 16:24:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 4CFBF1572A for ; Thu, 17 Jun 1999 16:24:23 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id IAA06999; Fri, 18 Jun 1999 08:54:22 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id IAA54978; Fri, 18 Jun 1999 08:54:30 +0930 (CST) Date: Fri, 18 Jun 1999 08:54:29 +0930 From: Greg Lehey To: John Birrell Cc: jake@checker.org, FreeBSD-current@FreeBSD.ORG Subject: Re: vinum in -current Message-ID: <19990618085428.K9893@freebie.lemis.com> References: <19990618082641.C9893@freebie.lemis.com> <199906172335.JAA26367@cimlogic.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199906172335.JAA26367@cimlogic.com.au>; from John Birrell on Fri, Jun 18, 1999 at 09:35:21AM +1000 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 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Friday, 18 June 1999 at 9:35:21 +1000, John Birrell wrote: > Greg Lehey wrote: >> On Thursday, 17 June 1999 at 9:18:27 -0700, Jake Burkholder wrote: >>> Hi, >>> >>> /sys/modules/Makefile: >>> # XXX vinum removed pending cdevsw changes review by grog. >>> >>> will a module from before the change (May 23rd) work with a new kernel? >>> or can the patches that were sent be made available? >> >> Ugh. Somebody (I know who, but I'm not going to put him to shame in >> public) told me that phk had committed the changes. I didn't know >> that jb then went and removed them. I know we've been flaming phk for >> committing changes without reference, but since I was unreachable for >> a long time, I believe this was the correct thing to do. I'll review >> the changes and reenable the build. Sorry for the delay. > > > > Hey, that's not true! > > phk noted in his commit message for all the _other_ stuff that he had > posted vinum and i4b patches to the respective owners for review. I sent > him mail saying that you were travelling and that he probably should > commit the vinum patches without the review. He said he would prefer to > take vinum out of the build instead. He said he would be offline for a > few hours and if I was online, would I go ahead and make the commit. > So I committed just the makefile change to prevent the build from > failing. Check the cvs history and you will find _no_ vinum commits > from me! > > Well, first, I'm not criticising anybody (much). We've had enough unpleasantness in the past, and I'm sure everybody was doing things with the best of intentions. What I saw was: RCS file: /src/ncvs/src/sys/modules/Makefile,v [snip] ---------------------------- revision 1.63 date: 1999/06/02 07:15:17; author: jb; state: Exp; lines: +3 -2 Remove vinum from the build until Greg reviews phk's cdevsw changes. Preferred by: phk (rather than committing the patch without review). ---------------------------- revision 1.62 date: 1999/05/15 06:13:27; author: grog; state: Exp; lines: +2 -5 Reenable vinum build. ---------------------------- revision 1.61 date: 1999/05/13 09:43:29; author: phk; state: Exp; lines: +5 -2 Vinum doesn't compile right now. Looking at it again, I confused 1.61 and 1.63 (which were, in fact, a couple of weeks apart). OK, I have a machine to rebuild (system disk on my test machine is gradually giving up the ghost), and I hope I'll have a working Vinum again later today (Friday). Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 16:58:24 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 2FCFD14C2F for ; Thu, 17 Jun 1999 16:58:21 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id RAA55578 for ; Thu, 17 Jun 1999 17:58:19 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id RAA08930 for ; Thu, 17 Jun 1999 17:58:36 -0600 (MDT) Message-Id: <199906172358.RAA08930@harmony.village.org> Subject: HEADS UP: PAO3 branch goes into the tree To: current@freebsd.org Date: Thu, 17 Jun 1999 17:58:36 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The PAO3 changes to FreeBSD 3.2 are about to be integrated into the FreeBSD CVS repository as its own branch off RELENG_3. itojin-san and the other nomads reached this agreement with -core at Usenix. This should have no impact on the user base, except that the ctm and cvsup updates will touch every file after I've put the TAG down and created the branch. The goal is to integrate those drivers and peices of the PAO system that are ready for integration and provide more exposure for the rest. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 17: 3:26 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 9130314F4C for ; Thu, 17 Jun 1999 17:03:22 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id SAA55610; Thu, 17 Jun 1999 18:03:19 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA09016; Thu, 17 Jun 1999 18:03:36 -0600 (MDT) Message-Id: <199906180003.SAA09016@harmony.village.org> To: Sheldon Hearn Subject: Re: Inetd's TCP Wrappers support changed Cc: current@FreeBSD.ORG In-reply-to: Your message of "Thu, 17 Jun 1999 11:21:54 +0200." <72552.929611314@axl.noc.iafrica.com> References: <72552.929611314@axl.noc.iafrica.com> Date: Thu, 17 Jun 1999 18:03:36 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [[ Trimmed HEADS UP from subject line ]] In message <72552.929611314@axl.noc.iafrica.com> Sheldon Hearn writes: : My recent commit to inetd is probably worth a mention in UPDATING for : two reasons: : : 1) Previously allowed builtin services (e.g. daytime) may be denied in : existing configurations. Existing hosts.allow configurations may need : to be reviewed. : : 2) The syslog selector requested in hosts.allow is now honoured. : Existing syslog.conf configurations relying on broken inetd behaviour : may need to be fixed. Do you have have a shorter entry that I could include in UPDATING? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 17:14:49 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id A1BD414D55 for ; Thu, 17 Jun 1999 17:14:42 -0700 (PDT) (envelope-from Studded@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id RAA06067; Thu, 17 Jun 1999 17:14:38 -0700 (PDT) (envelope-from Studded@gorean.org) Date: Thu, 17 Jun 1999 17:14:38 -0700 (PDT) From: Studded X-Sender: doug@dt054n86.san.rr.com To: Studded Cc: "David O'Brien" , freebsd-current@freebsd.org Subject: Re: Heavily loaded amd gets stuck In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Also, should I be considering a move to -current for this box? Is > -current stable enough right now to run a fairly heavily loaded web > server? If the NFS in -current is going to be doing better than what's in > -stable it will be worth a little headache to change, since our structure > depends on it heavily. Well I went ahead and tried -current, and got better results, but the same crash. With the following map: /defaults type:=nfs;opts:=rw,nosuid,vers=3,intr,proto=udp,noconn * rhost:=IP${key};rfs:=/Space/${key} It went MUCH farther through the script (mounted about 60 out of 80 directories) but it crashed just the same. Kernel stack trace looked like this: stuff Xresume1() --- interrupt bcmp() mountnfs() nfs_mount() mount() syscall() Xint0x80syscall() Now interestingly, the last 5 functions have been identical on every test. However, on this test the function nfs_nget(), which usually came right before mountnfs() on all the other tests was not present. However when I switched to vers=2 in the map, I got this: --- interrupt ssetlock() vop_sharedlock() vn_lock() vrele() nfs_nget() last 5 same as above. Also, the vn functions in this trace are the same as the ones I was getting with 3.2. I'm fixin' to try matt dillon's latest NFS patch next. Any other suggestions would be welcome. Thanks, Doug -- *** Chief Operations Officer, DALnet IRC network *** On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 17:17:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 9D8D3157A1 for ; Thu, 17 Jun 1999 17:17:24 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id RAA10128; Thu, 17 Jun 1999 17:19:04 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Warner Losh Cc: current@FreeBSD.ORG Subject: Re: HEADS UP: PAO3 branch goes into the tree In-reply-to: Your message of "Thu, 17 Jun 1999 17:58:36 MDT." <199906172358.RAA08930@harmony.village.org> Date: Thu, 17 Jun 1999 17:19:04 -0700 Message-ID: <10125.929665144@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG One word: YAY! :) > The PAO3 changes to FreeBSD 3.2 are about to be integrated into the > FreeBSD CVS repository as its own branch off RELENG_3. itojin-san and > the other nomads reached this agreement with -core at Usenix. > > This should have no impact on the user base, except that the ctm and > cvsup updates will touch every file after I've put the TAG down and > created the branch. > > The goal is to integrate those drivers and peices of the PAO system > that are ready for integration and provide more exposure for the rest. > > Warner > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 17:22:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 3584414FC7 for ; Thu, 17 Jun 1999 17:22:16 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id SAA55702; Thu, 17 Jun 1999 18:22:15 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA09264; Thu, 17 Jun 1999 18:22:32 -0600 (MDT) Message-Id: <199906180022.SAA09264@harmony.village.org> To: "Jordan K. Hubbard" Subject: Re: HEADS UP: PAO3 branch goes into the tree Cc: current@FreeBSD.ORG In-reply-to: Your message of "Thu, 17 Jun 1999 17:19:04 PDT." <10125.929665144@zippy.cdrom.com> References: <10125.929665144@zippy.cdrom.com> Date: Thu, 17 Jun 1999 18:22:32 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yup. If I can ever CVS to finish checking out the branch. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 17:24:17 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id B745714E15 for ; Thu, 17 Jun 1999 17:24:15 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id SAA55712 for ; Thu, 17 Jun 1999 18:24:14 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA09294 for ; Thu, 17 Jun 1999 18:24:31 -0600 (MDT) Message-Id: <199906180024.SAA09294@harmony.village.org> To: current@freebsd.org Subject: Apology (was HEADS UP: PAO3 branch goes into the tree ) Date: Thu, 17 Jun 1999 18:24:31 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I wrote: > The PAO3 changes to FreeBSD 3.2 are about to be integrated into the > FreeBSD CVS repository as its own branch off RELENG_3. itojin-san and > the other nomads reached this agreement with -core at Usenix. As everyone who knows itojun-san knows, I mistakenly misspelled his name. Please accept my humble apologies for this inexcusable mistake. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 18:12: 3 1999 Delivered-To: freebsd-current@freebsd.org Received: from jason.argos.org (a1-3b169.neo.rr.com [24.93.181.169]) by hub.freebsd.org (Postfix) with ESMTP id 15CD014BD0 for ; Thu, 17 Jun 1999 18:11:55 -0700 (PDT) (envelope-from mike@argos.org) Received: from localhost (mike@localhost) by jason.argos.org (8.9.1/8.9.1) with ESMTP id VAA15225; Thu, 17 Jun 1999 21:16:39 -0400 Date: Thu, 17 Jun 1999 21:16:39 -0400 (EDT) From: Mike Nowlin To: Leif Neland Cc: freebsd-current@FreeBSD.ORG Subject: Re: kernel -c crashes on exit In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > (btw, does anyone here know if a Linux kernel can reboot automatically > after a crash? Nobody on the linux-lists I have found can answer... > Anyway, back to FBSD:) Here's a chunk outta kernel 2.0.35, /usr/src/linux/kernel/panic.c do_unblank_screen(); if (panic_timeout > 0) { /* * Delay timeout seconds before rebooting the machine. * We can't use the "normal" timers since we just panicked.. */ printk(KERN_EMERG "Rebooting in %d seconds..",panic_timeout); for(i = 0; i < (panic_timeout*1000); i++) udelay(1000); #ifdef CONFIG_SCSI_GDTH gdth_halt(); #endif hard_reset_now(); } for(;;); --- end of chunk -- The default action is to simply halt -- but it does have the option to do a hard reset after panic_timeout seconds.... Didn't look into how this value gets set, but it's probably a LILO argument. Hope it answered your question. mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 19:14:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 0F29014C1A; Thu, 17 Jun 1999 19:14:44 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id LAA07691; Fri, 18 Jun 1999 11:44:43 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id LAA01748; Fri, 18 Jun 1999 11:44:51 +0930 (CST) Date: Fri, 18 Jun 1999 11:44:50 +0930 From: Greg Lehey To: FreeBSD current users , FreeBSD Hackers Subject: Remote serial gdb--status? Message-ID: <19990618114450.Q9893@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i 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 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've been away from work for several weeks, and I now find that I can no longer start remote serial gdb. I am using sio0 on the debugged machine side, and sio1 on the debugging machine side. Here are the relevant dmesg outputs: panic (debugged machine): sio0: system console sio0: gdb debugging port ... sio0 at port 0x3f8-0x3ff irq 4 flags 0x90 on isa0 sio0: type 16550A freebie (debugging machine): sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio1: interrupting at irq 3 I can communicate fine using cu, and a breakout box shows all modem signals asserte (DCD, DTR, DSR, RTS, CTS). When I go into remote debug on panic, RxD flashes, and when freebie tries to attach to panic, TxD flashes, so I'm obviously addressing the correct ports. I've checked the bit rate and configuration of the ports before going into debug, and they look right (9600 bps, cs8, -istrip, -parenb). I don't know what else to look for. Any ideas? Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 19:19:24 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id E619E14E14 for ; Thu, 17 Jun 1999 19:19:19 -0700 (PDT) (envelope-from Studded@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id TAA08286; Thu, 17 Jun 1999 19:19:17 -0700 (PDT) (envelope-from Studded@gorean.org) Date: Thu, 17 Jun 1999 19:19:17 -0700 (PDT) From: Studded X-Sender: doug@dt054n86.san.rr.com To: freebsd-current@freebsd.org Cc: "David O'Brien" Subject: Re: Heavily loaded amd gets stuck In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 17 Jun 1999, Studded wrote: > > Also, should I be considering a move to -current for this box? Is > > -current stable enough right now to run a fairly heavily loaded web > > server? If the NFS in -current is going to be doing better than what's in > > -stable it will be worth a little headache to change, since our structure > > depends on it heavily. > > Well I went ahead and tried -current, and got better results, but > the same crash. With the following map: > > /defaults type:=nfs;opts:=rw,nosuid,vers=3,intr,proto=udp,noconn > * rhost:=IP${key};rfs:=/Space/${key} > > It went MUCH farther through the script (mounted about 60 out of 80 > directories) but it crashed just the same. Kernel stack trace looked like > this: > > stuff > Xresume1() > --- interrupt > bcmp() > mountnfs() > nfs_mount() > mount() > syscall() > Xint0x80syscall() Ok, another interesting development. What the script I'm running does is go through each user account on our sun servers, reads a file, then uses certain values from that file to print out conf files on the local freebsd server that's acting as an NFS client (and crashing). So it's mounting a directory, reading 250 files, mounting the next directory, reading the next 250 files, and so on for a total of 80 directories. I changed the script so that after each reading the 250 files for each directory it did a 'sleep 10' before it started again. This allowed the script to run through to completion. So, I'm still open to new things to try here. Does anyone have any suggestions? I've been looking at nfsiod, all I had started was the default 4 because I thought they would spawn more if they needed more, but apparently they don't. Would more of those help? Would turning them off altogether help? I *really* need help with this since my boss is (justifiably I think) loathe to put this box into service without a little more concrete evidence that NFS can hold up. Would it be better to send this to -hackers? Maybe file a PR? I don't mean to sound like a pest, and yes I know that we're all volunteers, etc. But after wheedling for 4 months to try freebsd I'm kind of feeling the pinch here. :-/ Thanks for any help you can provide, Doug Ps, David if you want off the cc: list just let me know. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 21:12:44 1999 Delivered-To: freebsd-current@freebsd.org Received: from mail.rdc1.on.home.com (ha1.rdc1.on.wave.home.com [24.2.9.66]) by hub.freebsd.org (Postfix) with ESMTP id D589D1506A for ; Thu, 17 Jun 1999 21:12:42 -0700 (PDT) (envelope-from street@iname.com) Received: from mired.eh.local ([24.64.150.8]) by mail.rdc1.on.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990618041241.CAUX15006.mail.rdc1.on.home.com@mired.eh.local>; Thu, 17 Jun 1999 21:12:41 -0700 Received: (from kws@localhost) by mired.eh.local (8.9.3/8.9.3) id AAA02517; Fri, 18 Jun 1999 00:12:02 -0400 (EDT) (envelope-from kws) To: John Polstra Cc: sobomax@altavista.net, current@FreeBSD.ORG Subject: Re: Quiestion about /usr/libexec/ld-elf.so.1 References: <199906170041.RAA66302@vashon.polstra.com> From: Kevin Street Date: 18 Jun 1999 00:12:01 -0400 In-Reply-To: John Polstra's message of "Wed, 16 Jun 1999 17:41:55 -0700 (PDT)" Message-ID: <873dzq87vy.fsf@mired.eh.local> Lines: 16 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Polstra writes: > In article <375D258E.FCAB01B6@altavista.net>, Maxim Sobolev > wrote: > > > Does anybody know any legacy way to upgrade ld-elf.so.1 when making > > world or it always should be reinstalled manually? > > Huh? It is installed by make world, just like everything else. but unlike most other things it's installed with -C so the modification time does not usually change. -- Kevin Street street@iname.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 17 21:39:27 1999 Delivered-To: freebsd-current@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 6455414FBB for ; Thu, 17 Jun 1999 21:39:23 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id AAA51125; Fri, 18 Jun 1999 00:38:50 -0400 (EDT) Date: Fri, 18 Jun 1999 00:38:50 -0400 (EDT) From: Chuck Robey To: Peter Jeremy Cc: freebsd-current@FreeBSD.ORG Subject: Re: CTM cvs-cur missing In-Reply-To: <99Jun18.070114est.40323@border.alcanet.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 18 Jun 1999, Peter Jeremy wrote: > I've just noticed that the last cvs-cur delta I received was ~28 hours > ago. Is this related to the cvs-src problem that was discussed yesterday, > or is this something new. Yeah, it's something new. Somebody (I don't know who yet) added something large to the partition that ctm uses, and now there's no real room. I'm looking for whoever runs anoncvs. If I don't find him soon, then even though I don't know anything about anoncvs, I'm going to move it anyhow. If it breaks (and it might) that's too bad. I'm sorry I didn't so it today, I just had surgery 7 hours ago, I'm hurting right now, but I will do it tomorrow for sure (I'm not hurting that bad, I want ctm back up as badly as you do). ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 18 0:39:21 1999 Delivered-To: freebsd-current@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 66E1914C49 for ; Fri, 18 Jun 1999 00:39:16 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 10utEi-0006NV-00; Fri, 18 Jun 1999 09:38:52 +0200 From: Sheldon Hearn To: Warner Losh Cc: current@FreeBSD.ORG Subject: Re: Inetd's TCP Wrappers support changed In-reply-to: Your message of "Thu, 17 Jun 1999 18:03:36 CST." <199906180003.SAA09016@harmony.village.org> Date: Fri, 18 Jun 1999 09:38:52 +0200 Message-ID: <24520.929691532@axl.noc.iafrica.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 17 Jun 1999 18:03:36 CST, Warner Losh wrote: > Do you have have a shorter entry that I could include in UPDATING? How about Inetd now wraps all stream-based services, including internals. Syslog "severity" options are honoured. Installed syslog.conf and hosts.allow should be checked. ? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 18 1:14:42 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 5D2F71503E for ; Fri, 18 Jun 1999 01:14:37 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id CAA57181; Fri, 18 Jun 1999 02:14:36 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id CAA74657; Fri, 18 Jun 1999 02:14:57 -0600 (MDT) Message-Id: <199906180814.CAA74657@harmony.village.org> To: Sheldon Hearn Subject: Re: Inetd's TCP Wrappers support changed Cc: current@FreeBSD.ORG In-reply-to: Your message of "Fri, 18 Jun 1999 09:38:52 +0200." <24520.929691532@axl.noc.iafrica.com> References: <24520.929691532@axl.noc.iafrica.com> Date: Fri, 18 Jun 1999 02:14:56 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <24520.929691532@axl.noc.iafrica.com> Sheldon Hearn writes: : Inetd now wraps all stream-based services, including internals. : Syslog "severity" options are honoured. Installed syslog.conf : and hosts.allow should be checked. Works for me. I'll comit it shortly. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 18 4:55: 1 1999 Delivered-To: freebsd-current@freebsd.org Received: from matrix.42.org (matrix.42.org [194.246.250.200]) by hub.freebsd.org (Postfix) with ESMTP id 3886E14F6F for ; Fri, 18 Jun 1999 04:54:57 -0700 (PDT) (envelope-from sec@42.org) Received: (from sec@localhost) by matrix.42.org (8.8.8/8.8.5) id NAA01737 for freebsd-current@freebsd.org (sender ); Fri, 18 Jun 1999 13:54:57 +0200 (CEST) Date: Fri, 18 Jun 1999 13:54:56 +0200 From: Stefan `Sec` Zehl To: freebsd-current@freebsd.org Subject: Re: HEADS UP: PAO3 branch goes into the tree Message-ID: <19990618135456.A1715@matrix.42.org> References: <199906172358.RAA08930@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <199906172358.RAA08930@harmony.village.org>; from Warner Losh on Fri, Jun 18, 1999 at 02:01:31AM +0200 I-love-doing-this: really Accept-Languages: de, en X-URL: http://sec.42.org/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jun 18, 1999 at 02:01:31AM +0200, Warner Losh wrote: > The PAO3 changes to FreeBSD 3.2 are about to be integrated into the > FreeBSD CVS repository as its own branch off RELENG_3. itojin-san and > the other nomads reached this agreement with -core at Usenix. What happened to all that other decisions to be made at Usenix? (newbus vs. newconfig, and commit privileges come to my mind) CU, Sec -- Sometimes I think the surest sign, that intelligent life exists else where in our universe is, that none of it has tried to contact us. Calvin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 18 5:16:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id A1D6C14F6F for ; Fri, 18 Jun 1999 05:16:32 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id FAA03593; Fri, 18 Jun 1999 05:18:15 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Stefan `Sec` Zehl Cc: freebsd-current@FreeBSD.ORG Subject: Re: HEADS UP: PAO3 branch goes into the tree In-reply-to: Your message of "Fri, 18 Jun 1999 13:54:56 +0200." <19990618135456.A1715@matrix.42.org> Date: Fri, 18 Jun 1999 05:18:15 -0700 Message-ID: <3589.929708295@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What happened to all that other decisions to be made at Usenix? > (newbus vs. newconfig, and commit privileges come to my mind) Actually, none of these were decisions were scheduled to be made at Usenix. :) The newbus and newconfig stuff was already pretty much argued-out before USENIX, the goal of Usenix being to try and discuss this more in person and get from "arguing" to "discussing" plans on an ongoing basis. The commit bit decision was explicitly agreed would *not* happen at USENIX since other people in the decision loop didn't want to be left out of that. More public notification on that issue will follow shortly; we're still talking about it. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 18 10: 1:16 1999 Delivered-To: freebsd-current@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id AB85614D9B for ; Fri, 18 Jun 1999 10:01:12 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id MAA27320 for ; Fri, 18 Jun 1999 12:01:11 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id MAA03567; Fri, 18 Jun 1999 12:01:10 -0500 Message-ID: <19990618120110.30286@right.PCS> Date: Fri, 18 Jun 1999 12:01:10 -0500 From: Jonathan Lemon To: current@freebsd.org Subject: New-bus questions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG First, a request: I'm running into a problem with the new-bus PCI bus probing code, and am not sure where to look. If someone could give me an overview of how new-bus works, I would appreciate it. Now to the problem: I have a Compaq 3000 which I'm trying to get working. Under -STABLE, it detects 4 PCI buses, and probes the devices on the buses correctly. Under -current, it only detects 2 PCI buses. Unfortunatly, my boot device is on one of the non- detected buses, making debugging slightly difficult. FWIW, I can't get SMP working on this machine either, since only two PCI buses are listed in the MP table; and I can't see any "set Full MPTable" in Compaq's blasted Ctrl-A config utility. 1. Why does -stable work and not -current? 2. Does new-bus require an MP table (or equivalent) to detect the buses? -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 18 10: 5:38 1999 Delivered-To: freebsd-current@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 6DC7E14D9B for ; Fri, 18 Jun 1999 10:04:55 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id MAA27334 for ; Fri, 18 Jun 1999 12:04:54 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id MAA04050; Fri, 18 Jun 1999 12:04:52 -0500 Message-ID: <19990618120451.24697@right.PCS> Date: Fri, 18 Jun 1999 12:04:51 -0500 From: Jonathan Lemon To: current@freebsd.org Subject: New-bus driver question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm also trying to write a driver under new-bus. At what point is it safe to use interrupts to interrogate the card? Anytime after I call bus_setup_intr(), (for a PCI card), or do I need to delay interrupt-driven configuration with config_intrhook_establish()? -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 18 10:14: 6 1999 Delivered-To: freebsd-current@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id D4C3714CA4 for ; Fri, 18 Jun 1999 10:14:02 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id DAA02467; Sat, 19 Jun 1999 03:14:00 +1000 Date: Sat, 19 Jun 1999 03:14:00 +1000 From: Bruce Evans Message-Id: <199906181714.DAA02467@godzilla.zeta.org.au> To: current@FreeBSD.ORG, jlemon@americantv.com Subject: Re: New-bus driver question Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm also trying to write a driver under new-bus. At what point is >it safe to use interrupts to interrogate the card? Anytime after I >call bus_setup_intr(), (for a PCI card), or do I need to delay >interrupt-driven configuration with config_intrhook_establish()? The latter. Working of interrupts after bus_setup_intr() is machine-dependent, so drivers shouldn't assume that they work then. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 18 10:24: 5 1999 Delivered-To: freebsd-current@freebsd.org Received: from par28.ma.ikos.com (par28.ma.ikos.com [137.103.105.228]) by hub.freebsd.org (Postfix) with ESMTP id 71F1814D67 for ; Fri, 18 Jun 1999 10:23:57 -0700 (PDT) (envelope-from tich@par28.ma.ikos.com) Received: (from tich@localhost) by par28.ma.ikos.com (8.8.7/8.8.7) id NAA15730; Fri, 18 Jun 1999 13:24:14 -0400 Date: Fri, 18 Jun 1999 13:24:14 -0400 From: Richard Cownie Message-Id: <199906181724.NAA15730@par28.ma.ikos.com> To: freebsd-current@freebsd.org, tich@par28.ma.ikos.com Subject: fix for 4GB dram Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I seem to have a fix for the 4GB dram problem. Here's the SMAP info returned from the BIOS on an SC450NX with 4GB DRAM: type=01 base= 00000000 00000000 len= 00000000 0009e400 type=02 base= 00000000 0009e400 len= 00000000 00001c00 type=02 base= 00000000 000f0400 len= 00000000 0000fc00 type=01 base= 00000000 00100000 len= 00000000 f9dfac00 type=03 base= 00000000 f9efac00 len= 00000000 00005000 type=04 base= 00000000 f9effc00 len= 00000000 00000400 type=02 base= 00000000 fe300000 len= 00000000 01d00000 type=01 base= 00000001 00000000 len= 00000000 06100000 Note that the chipset remaps some of the DRAM up above the 4GB boundary - this entry in the table causes confusion, because the base address gets truncated to 32bits (though the comparison to detect non-monotonic entries is still 64bits). I added this code in /usr/src/sys/i386/i386/machdep.c:getmemsize() if (smap->type != 0x01) goto next_run; if (smap->length == 0) goto next_run; + if (*(u_int32_t *)((char *)&smap->base + 4) != 0) { + if (boothowto & RB_VERBOSE) { + printf("Memory above 4GB ignored\n"); + } + goto next_run; + } for (i = 0; i <= physmap_idx; i += 2) { if (smap->base < physmap[i + 1]) { if (boothowto & RB_VERBOSE) printf( "Overlapping or non-monotonic memory region, ignoring second region\n"); goto next_run; } } Now it seems to work (with options MAXMEM="((4096-64)*1024)" - haven't tried it with speculative memory probing yet). Thanks to Jonathan Lemon for steering me in the right direction. Richard Cownie (tich@ma.ikos.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 18 12:46:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 0B14114D84; Fri, 18 Jun 1999 12:46:21 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id MAA27989; Fri, 18 Jun 1999 12:45:44 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id MAA07634; Fri, 18 Jun 1999 12:45:45 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA13732; Fri, 18 Jun 99 12:45:43 PDT Message-Id: <376AA1E6.F529ED99@softweyr.com> Date: Fri, 18 Jun 1999 13:45:42 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Greg Lehey Cc: FreeBSD current users , FreeBSD Hackers Subject: Re: Remote serial gdb--status? References: <19990618114450.Q9893@freebie.lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Lehey wrote: > > I've been away from work for several weeks, and I now find that I can > no longer start remote serial gdb. I am using sio0 on the debugged > machine side, and sio1 on the debugging machine side. Here are the > relevant dmesg outputs: > > panic (debugged machine): > > sio0: system console > sio0: gdb debugging port > ... > sio0 at port 0x3f8-0x3ff irq 4 flags 0x90 on isa0 > sio0: type 16550A > > freebie (debugging machine): > > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > sio1: interrupting at irq 3 > > I can communicate fine using cu, and a breakout box shows all modem > signals asserte (DCD, DTR, DSR, RTS, CTS). When I go into remote > debug on panic, RxD flashes, and when freebie tries to attach to > panic, TxD flashes, so I'm obviously addressing the correct ports. > I've checked the bit rate and configuration of the ports before going > into debug, and they look right (9600 bps, cs8, -istrip, -parenb). I > don't know what else to look for. Any ideas? I think you need flags 0x50 (instead of 0x90) on panic. From sio(4): Meaning of flags: ... 0x00010 device is potential system console 0x00020 device is forced to become system console 0x00040 device is reserved for low-level IO (e. g. for remote kernel debugging) ... -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 18 15:37:46 1999 Delivered-To: freebsd-current@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id B337714E39 for ; Fri, 18 Jun 1999 15:37:40 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id RAA28448; Fri, 18 Jun 1999 17:37:38 -0500 (CDT) Received: from free.pcs (free.PCS [148.105.10.51]) by right.PCS (8.6.13/8.6.4) with ESMTP id RAA12304; Fri, 18 Jun 1999 17:37:37 -0500 Received: (from jlemon@localhost) by free.pcs (8.8.6/8.8.5) id RAA23654; Fri, 18 Jun 1999 17:37:36 -0500 (CDT) Date: Fri, 18 Jun 1999 17:37:36 -0500 (CDT) From: Jonathan Lemon Message-Id: <199906182237.RAA23654@free.pcs> To: grog@lemis.com, current@freebsd.org Subject: Re: Remote serial gdb--status? X-Newsgroups: local.mail.freebsd-current In-Reply-To: Organization: Architecture and Operating System Fanatics Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >I've been away from work for several weeks, and I now find that I can >no longer start remote serial gdb. I am using sio0 on the debugged >machine side, and sio1 on the debugging machine side. Here are the >relevant dmesg outputs: > >panic (debugged machine): > >sio0: system console >sio0: gdb debugging port >... >sio0 at port 0x3f8-0x3ff irq 4 flags 0x90 on isa0 >sio0: type 16550A > >freebie (debugging machine): > >sio1 at port 0x2f8-0x2ff irq 3 on isa0 >sio1: type 16550A >sio1: interrupting at irq 3 > >I can communicate fine using cu, and a breakout box shows all modem >signals asserte (DCD, DTR, DSR, RTS, CTS). When I go into remote >debug on panic, RxD flashes, and when freebie tries to attach to >panic, TxD flashes, so I'm obviously addressing the correct ports. >I've checked the bit rate and configuration of the ports before going >into debug, and they look right (9600 bps, cs8, -istrip, -parenb). I >don't know what else to look for. Any ideas? How about ``options GDB_REMOTE_CHAT'' in the kernel? I was just running gdb over a serial line today (flags 0x80), and didn't have any problems. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 18 20:14:53 1999 Delivered-To: freebsd-current@freebsd.org Received: from www.harrisburgacademy.org (2093702.harrisburgacademy.org [209.3.70.2]) by hub.freebsd.org (Postfix) with ESMTP id 856D5153B6 for ; Fri, 18 Jun 1999 20:14:29 -0700 (PDT) (envelope-from i.think@harrisburgacademy.org) Received: from nemox.looksharp.net ([199.224.85.212]) by www.harrisburgacademy.org (Netscape Messaging Server 3.5) with ESMTP id 430 for ; Fri, 18 Jun 1999 23:01:11 -0400 Message-ID: <376B0A00.2B57291E@nemox.looksharp.net> Date: Fri, 18 Jun 1999 23:09:52 -0400 From: NemoX X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: KNE40BT in freebsd only getting 45KB/sec ftp transfer to win98 machine Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am running FreeBSD-current and for some reason I am only getting~45KB/sec transfer to a computer running Windows 98. I have a Kingston KNE40BTcard and I can find no hardware error as to why I am only reaching those speeds. Could you suggest what may be the error? Andrew Tamm -- DISCLAIMER: Anyone sending me unsolicited commercial electronic mail will be charged a $100 fee for time spent reading it. Do NOT send this type of electronic mail to me. In reading this, you automatically agree to be subjected to these terms: US Code Title 47, Sec.227(a)(2)(B), a computer/modem/printer meets the definition of a telephone fax machine. By Sec.227(b)(1)(C), it is unlawful to send any unsolicited advertisement to such equipment. By Sec.227(b)(3)(C), a violation of the aforementioned Section is punishable by action to recover actual monetary loss, or $500, whichever is greater, for each violation To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 18 21:46:21 1999 Delivered-To: freebsd-current@freebsd.org Received: from argus.tfs.net (host1-126.birch.net [216.212.1.126]) by hub.freebsd.org (Postfix) with ESMTP id 9394714C58 for ; Fri, 18 Jun 1999 21:46:17 -0700 (PDT) (envelope-from jbryant@argus.tfs.net) Received: (from jbryant@localhost) by argus.tfs.net (8.9.3/8.8.5) id XAA00838; Fri, 18 Jun 1999 23:45:56 -0500 (CDT) From: Jim Bryant Message-Id: <199906190445.XAA00838@argus.tfs.net> Subject: Re: KNE40BT in freebsd only getting 45KB/sec ftp transfer to win98 machine In-Reply-To: <376B0A00.2B57291E@nemox.looksharp.net> from NemoX at "Jun 18, 99 11:09:52 pm" To: i.think@nemox.looksharp.net (NemoX) Date: Fri, 18 Jun 1999 23:45:55 -0500 (CDT) Cc: freebsd-current@freebsd.org Reply-To: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-files: The truth is that the X-Files is fiction X-Republican: The best kind!!! X-Operating-System: FreeBSD 4.0-CURRENT #31: Thu Apr 8 10:40:17 CDT 1999 X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In reply: > I am running FreeBSD-current and for some reason I am only > getting~45KB/sec > transfer to a computer running Windows 98. I have a Kingston > KNE40BTcard and I > can find no hardware error as to why I am only reaching those speeds. > Could you suggest what may be the error? > > Andrew Tamm ummmmmmm.. winblowz-98. jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 18 22:15:56 1999 Delivered-To: freebsd-current@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 743D314CE5 for ; Fri, 18 Jun 1999 22:15:50 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id GAA94989; Sat, 19 Jun 1999 06:16:52 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sat, 19 Jun 1999 06:16:52 +0100 (BST) From: Doug Rabson To: Jonathan Lemon Cc: current@freebsd.org Subject: Re: New-bus questions In-Reply-To: <19990618120110.30286@right.PCS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 18 Jun 1999, Jonathan Lemon wrote: > > First, a request: > > I'm running into a problem with the new-bus PCI bus probing code, > and am not sure where to look. If someone could give me an overview > of how new-bus works, I would appreciate it. > > Now to the problem: > > I have a Compaq 3000 which I'm trying to get working. Under > -STABLE, it detects 4 PCI buses, and probes the devices on > the buses correctly. Under -current, it only detects 2 PCI > buses. Unfortunatly, my boot device is on one of the non- > detected buses, making debugging slightly difficult. > > FWIW, I can't get SMP working on this machine either, since > only two PCI buses are listed in the MP table; and I can't see > any "set Full MPTable" in Compaq's blasted Ctrl-A config utility. > > > 1. Why does -stable work and not -current? > 2. Does new-bus require an MP table (or equivalent) to detect the buses? I think this is a machine with multiple host-pci bridges. Could you send me a dmesg so that I can see what chipset is being used. I think we can support this by pretending the second bridge is a pci-pci bridge. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 18 23: 0:38 1999 Delivered-To: freebsd-current@freebsd.org Received: from www.harrisburgacademy.org (2093702.harrisburgacademy.org [209.3.70.2]) by hub.freebsd.org (Postfix) with ESMTP id 5E72914C32 for ; Fri, 18 Jun 1999 23:00:28 -0700 (PDT) (envelope-from i.think@harrisburgacademy.org) Received: from nemox.looksharp.net ([199.224.85.108]) by www.harrisburgacademy.org (Netscape Messaging Server 3.5) with ESMTP id 448; Sat, 19 Jun 1999 01:47:16 -0400 Message-ID: <376B30A5.903C939E@nemox.looksharp.net> Date: Sat, 19 Jun 1999 01:54:45 -0400 From: NemoX X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: jbryant@tfs.net Cc: freebsd-current@freebsd.org Subject: Re: KNE40BT in freebsd only getting 45KB/sec ftp transfer to win98 machine References: <199906190445.XAA00838@argus.tfs.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG i cant believe what windows would slow it that much? is there someway to make sure that is the problem? i would prefer not to jump to that conclusion until its obvious Jim Bryant wrote: > In reply: > > I am running FreeBSD-current and for some reason I am only > > getting~45KB/sec > > transfer to a computer running Windows 98. I have a Kingston > > KNE40BTcard and I > > can find no hardware error as to why I am only reaching those speeds. > > Could you suggest what may be the error? > > > > Andrew Tamm > > ummmmmmm.. winblowz-98. > > jim > -- > All opinions expressed are mine, if you | "I will not be pushed, stamped, > think otherwise, then go jump into turbid | briefed, debriefed, indexed, or > radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" > ------------------------------------------------------------------------------ > Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw > voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant > ------------------------------------------------------------------------------ > HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message -- DISCLAIMER: Anyone sending me unsolicited commercial electronic mail will be charged a $100 fee for time spent reading it. Do NOT send this type of electronic mail to me. In reading this, you automatically agree to be subjected to these terms: US Code Title 47, Sec.227(a)(2)(B), a computer/modem/printer meets the definition of a telephone fax machine. By Sec.227(b)(1)(C), it is unlawful to send any unsolicited advertisement to such equipment. By Sec.227(b)(3)(C), a violation of the aforementioned Section is punishable by action to recover actual monetary loss, or $500, whichever is greater, for each violation To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 19 0: 4: 1 1999 Delivered-To: freebsd-current@freebsd.org Received: from gndrsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 8C64D14CF6 for ; Sat, 19 Jun 1999 00:03:53 -0700 (PDT) (envelope-from rgrimes@gndrsh.aac.dev.com) Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.9.3/8.9.3) id AAA65680; Sat, 19 Jun 1999 00:03:28 -0700 (PDT) (envelope-from rgrimes) From: "Rodney W. Grimes" Message-Id: <199906190703.AAA65680@gndrsh.aac.dev.com> Subject: Re: KNE40BT in freebsd only getting 45KB/sec ftp transfer to win98 machine In-Reply-To: <199906190445.XAA00838@argus.tfs.net> from Jim Bryant at "Jun 18, 1999 11:45:55 pm" To: jbryant@tfs.net Date: Sat, 19 Jun 1999 00:03:28 -0700 (PDT) Cc: i.think@nemox.looksharp.net (NemoX), freebsd-current@FreeBSD.ORG 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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In reply: > > I am running FreeBSD-current and for some reason I am only > > getting~45KB/sec > > transfer to a computer running Windows 98. I have a Kingston > > KNE40BTcard and I > > can find no hardware error as to why I am only reaching those speeds. > > Could you suggest what may be the error? > > > > Andrew Tamm > > ummmmmmm.. winblowz-98. More likely the card is in full duplex mode talking to a half duplex network. What type of hub/switch is the KNE40BT plugged into. One other thing to look for is what does the collision light look like? I've seen a batch of KNE100TX's that had real problems, I've had to RMA about 6 of them now due to link level failure of the hardware. They cause the collision light to come on almost solid, and behave like what you are seeing as far as transfer rates. The problem I was seeing seems to be temperature related. If you turn the machine off for a few hours and let it get nice and cool it will run for anywhere from 10 minutes to 6 hours just fine, then whamooo.... collisions from h*ll. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 19 0:52:16 1999 Delivered-To: freebsd-current@freebsd.org Received: from buffy.tpgi.com.au (buffy.tpgi.com.au [203.12.160.34]) by hub.freebsd.org (Postfix) with ESMTP id DB2D0151D8 for ; Sat, 19 Jun 1999 00:52:10 -0700 (PDT) (envelope-from eirvine@tpgi.com.au) Received: (from smtpd@localhost) by buffy.tpgi.com.au (8.8.7/8.8.7) id RAA24095; Sat, 19 Jun 1999 17:54:51 +1000 Received: from tar-56k-204.tpgi.com.au(203.26.26.204), claiming to be "tpgi.com.au" via SMTP by buffy.tpgi.com.au, id smtpda24072; Sat Jun 19 17:54:41 1999 Message-ID: <376B4C20.EDE2C8BF@tpgi.com.au> Date: Sat, 19 Jun 1999 17:52:00 +1000 From: Eddie Irvine X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: jbryant@tfs.net Cc: freebsd-current@FreeBSD.ORG Subject: Re: KNE40BT in freebsd only getting 45KB/sec ftp transfer to win98 machine References: <199906190445.XAA00838@argus.tfs.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Speed in what protocol? FTP? SMB? Appletalk? Have you checked the duplexing of cards on both machines? Use the DOS program that came with the ethernet cards to check. Unless your card is connected directly to a switch, it should be half duplex (I'm not sure on this, but that is my understanding). Jim Bryant wrote: > > In reply: > > I am running FreeBSD-current and for some reason I am only > > getting~45KB/sec > > transfer to a computer running Windows 98. I have a Kingston > > KNE40BTcard and I > > can find no hardware error as to why I am only reaching those speeds. > > Could you suggest what may be the error? > > > > Andrew Tamm > > ummmmmmm.. winblowz-98. > > jim > -- > All opinions expressed are mine, if you | "I will not be pushed, stamped, > think otherwise, then go jump into turbid | briefed, debriefed, indexed, or > radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" > ------------------------------------------------------------------------------ > Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw > voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant > ------------------------------------------------------------------------------ > HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message -- Eddie http://www1.tpgi.com.au/users/eirvine/index.html ________________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 19 1: 0:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 96E84151D8 for ; Sat, 19 Jun 1999 01:00:19 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id BAA10902; Sat, 19 Jun 1999 01:00:13 -0700 (PDT) (envelope-from obrien) Message-ID: <19990619010012.A10860@nuxi.com> Date: Sat, 19 Jun 1999 01:00:12 -0700 From: "David O'Brien" To: "Kenneth D. Merry" Cc: freebsd-current@FreeBSD.ORG Subject: Re: 4GB dram Reply-To: obrien@FreeBSD.ORG References: <99061716084400.14101@par28.ma.ikos.com> <199906172054.OAA89992@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199906172054.OAA89992@panzer.plutotech.com>; from Kenneth D. Merry on Thu, Jun 17, 1999 at 02:54:52PM -0600 X-Operating-System: FreeBSD 3.2-BETA Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > You should be able to strip a kernel down enough to fit it on a floppy, > although you will have to specify some non-standard options. Two options > that you'll want to use are: > > options SCSI_NO_SENSE_STRINGS > options SCSI_NO_OP_STRINGS > > That will disable SCSI sense code and op code description strings. Removing everything related to SCSI would also do the same thing, right? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 19 1: 3:40 1999 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 940F914C3A for ; Sat, 19 Jun 1999 01:03:38 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id BAA10927; Sat, 19 Jun 1999 01:03:31 -0700 (PDT) (envelope-from obrien) Message-ID: <19990619010330.B10860@nuxi.com> Date: Sat, 19 Jun 1999 01:03:30 -0700 From: "David O'Brien" To: David Scheidt , Chuck Robey Cc: freebsd-current@FreeBSD.ORG Subject: Re: bsd.lib.mk "@"'s Reply-To: obrien@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from David Scheidt on Mon, Jun 07, 1999 at 01:57:01PM -0500 X-Operating-System: FreeBSD 3.2-BETA Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > How often do your calls to ld, mv and rm fail? There certainly bit me on the EGCS import into the tree. (can't remember now if it was when changing libgcc or libstdc++) Took me quite a while to realize what was going wrong. -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 19 2:21:58 1999 Delivered-To: freebsd-current@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 5DE4814E93 for ; Sat, 19 Jun 1999 02:21:47 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 59647 invoked by uid 1001); 19 Jun 1999 09:21:46 +0000 (GMT) To: dfr@nlsystems.com Cc: jlemon@americantv.com, current@freebsd.org Subject: Re: New-bus questions From: sthaug@nethelp.no In-Reply-To: Your message of "Sat, 19 Jun 1999 06:16:52 +0100 (BST)" References: X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sat, 19 Jun 1999 11:21:46 +0200 Message-ID: <59645.929784106@verdi.nethelp.no> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I have a Compaq 3000 which I'm trying to get working. Under > > -STABLE, it detects 4 PCI buses, and probes the devices on > > the buses correctly. Under -current, it only detects 2 PCI > > buses. Unfortunatly, my boot device is on one of the non- > > detected buses, making debugging slightly difficult. > > > > FWIW, I can't get SMP working on this machine either, since > > only two PCI buses are listed in the MP table; and I can't see > > any "set Full MPTable" in Compaq's blasted Ctrl-A config utility. > > > > > > 1. Why does -stable work and not -current? > > 2. Does new-bus require an MP table (or equivalent) to detect the buses? > > I think this is a machine with multiple host-pci bridges. Could you send > me a dmesg so that I can see what chipset is being used. I think we can > support this by pretending the second bridge is a pci-pci bridge. If it's the Proliant 3000, it does indeed have two host-pci bridges. Here's the dmesg output for a box running 3.2-STABLE. (Those of you with sharp eyes might wonder about the memory lines. The box has 576 MB memory. We had some stability problems, and I suspected part of the upper memory was being used by the BIOS etc - so I made a kernel with MAXMEM of 572 MBytes. Later it turned out that the stability problems were probably due to insufficient mbuf clusters. After we upped this to 4096, the box has been extremely stable.) Steinar Haug, Nethelp consulting, sthaug@nethelp.no ---------------------------------------------------------------------- Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.2-STABLE #0: Wed Jun 2 23:21:41 CEST 1999 sthaug@newsfeed1.telia.no:/local/freebsd/src/sys/compile/NEWSFEED1 Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (686-class CPU) Origin = "GenuineIntel" Id = 0x651 Stepping=1 Features=0x183fbff> real memory = 599785472 (585728K bytes) avail memory = 580280320 (566680K bytes) Programming 28 pins in IOAPIC #0 EISA INTCONTROL = 00000620 IOAPIC #0 intpint 24 -> irq 5 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 8, version: 0x001b0011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc02cd000. eisa0: Probing for devices on the EISA bus Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 vga0: rev 0x22 int a irq 255 on pci0.6.0 chip1: rev 0x07 on pci0.15.0 chip2: rev 0x03 on pci0.17.0 Probing for devices on PCI bus 1: ncr0: rev 0x14 int a irq 19 on pci1.4.0 ncr1: rev 0x14 int b irq 18 on pci1.4.1 fxp0: rev 0x05 int a irq 18 on pci1.7.0 fxp0: Ethernet address 00:90:27:13:f6:21 tl0: rev 0x10 int a irq 17 on pci1.8.0 tl0: Ethernet address: 00:08:c7:1e:a7:35 tl0: autoneg complete, link status good (half-duplex, 100Mbps) Probing for devices on PCI bus 2: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0: failed to get data. psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (atapi): , removable, accel, dma, iordis acd0: drive speed 1378KB/sec, 128KB cache acd0: supported read types: CD-DA acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface APIC_IO: Testing 8254 interrupt delivery APIC_IO: Broken MP table detected: 8254 is not connected to IO APIC int pin 2 APIC_IO: routing 8254 via 8259 on pin 0 ccd0-3: Concatenated disk drivers Waiting 5 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! changing root device to da0s3da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) da2 at ncr0 bus 0 target 4 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da2: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) da3 at ncr0 bus 0 target 5 lun 0 da3: Fixed Direct Access SCSI-2 device da3: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da3: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) da1 at ncr0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 19 8: 6:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id AFCBA14BDD for ; Sat, 19 Jun 1999 08:06:43 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id KAA00338; Sat, 19 Jun 1999 10:06:43 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id KAA19897; Sat, 19 Jun 1999 10:06:42 -0500 Message-ID: <19990619100642.49750@right.PCS> Date: Sat, 19 Jun 1999 10:06:42 -0500 From: Jonathan Lemon To: Doug Rabson Cc: current@freebsd.org Subject: Re: New-bus questions References: <19990618120110.30286@right.PCS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: ; from Doug Rabson on Jun 06, 1999 at 06:16:52AM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jun 06, 1999 at 06:16:52AM +0100, Doug Rabson wrote: > > I think this is a machine with multiple host-pci bridges. Could you send > me a dmesg so that I can see what chipset is being used. I think we can > support this by pretending the second bridge is a pci-pci bridge. Okay, the dmesg is attached below. It is a Compaq Proliant 3000, but the dmesg output is different than the other one posted. -- Jonathan --------------------------------- cut here --------------------------------- Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.2-BETA #1: Fri May 21 13:13:10 CDT 1999 jlemon@fish.pcs:/usr/src/sys/compile/MONSTER Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 399064230 Hz CPU: Pentium II/Xeon/Celeron (399.06-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping=2 Features=0x183fbff> real memory = 268419072 (262128K bytes) avail memory = 258277376 (252224K bytes) Preloaded elf kernel "kernel.good" at 0xc02c6000. eisa0: Probing for devices on the EISA bus Probing for devices on PCI bus 0: chip0: rev 0x04 on pci0.0.0 chip1: rev 0x02 on pci0.0.1 vga0: rev 0x7a on pci0.5.0 chip2: rev 0x07 on pci0.9.0 chip3: rev 0x4d on pci0.15.0 chip4: rev 0x04 on pci0.17.0 chip5: rev 0x02 on pci0.17.1 Probing for devices on PCI bus 1: ida0: rev 0x03 int a irq 9 on pci1.0.0 ida0: drvs=1 firm_rev=3.04 ida0: unit 0 (id0): id0: 12279MB (25149120 total sec), 3082 cyl, 255 head, 32 sec, bytes/sec 512 ida: wdc vector stealing on (mode = always, boot major = 4) Probing for devices on PCI bus 2: ncr0: rev 0x14 int a irq 10 on pci2.4.0 ncr1: rev 0x14 int b irq 11 on pci2.4.1 fxp0: rev 0x05 int a irq 5 on pci2.8.0 fxp0: Ethernet address 00:08:c7:f9:06:87 Probing for devices on PCI bus 3: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in psm0: failed to get data. psm0 irq 12 on isa psm0: model GlidePoint, device ID 0 vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 flags 0x1 on motherboard npx0: INT 16 interface IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to accept, logging limited to 100 packets/entry Waiting 5 seconds for SCSI devices to settle changing root device to da0s1a da0 at ncr1 bus 0 target 6 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 501MB (1027548 512 byte sectors: 64H 32S/T 501C) ffs_mountfs: superblock updated for soft updates link_elf: symbol splash_register undefined > > -- > Doug Rabson Mail: dfr@nlsystems.com > Nonlinear Systems Ltd. Phone: +44 181 442 9037 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 19 8:16:44 1999 Delivered-To: freebsd-current@freebsd.org Received: from www.harrisburgacademy.org (2093702.harrisburgacademy.org [209.3.70.2]) by hub.freebsd.org (Postfix) with ESMTP id 336DB14EBD for ; Sat, 19 Jun 1999 08:16:39 -0700 (PDT) (envelope-from i.think@harrisburgacademy.org) Received: from nemox.looksharp.net ([199.224.85.108]) by www.harrisburgacademy.org (Netscape Messaging Server 3.5) with ESMTP id 475 for ; Sat, 19 Jun 1999 11:03:35 -0400 Message-ID: <376BB30E.F8CF9F09@nemox.looksharp.net> Date: Sat, 19 Jun 1999 11:11:10 -0400 From: NemoX X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 Cc: freebsd-current@FreeBSD.ORG Subject: Re: KNE40BT in freebsd only getting 45KB/sec ftp transfer to win98 machine References: <199906190703.AAA65680@gndrsh.aac.dev.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Collionsion light is off output of netstat -i de0 1500 00.c0.f0.38.02.9e 4347 0 4010 0 2 de0 1500 10/24 descartes 4347 0 4010 0 2 only 2 collisions The hub is a generic 5 port 10baseT hub, I'm not sure of anythign else on it. one thing i noticed is that the data light on the KNE40BT ( in the freebsd machine ) is flashing steadily, while the light on the win98 machine "Rodney W. Grimes" wrote: > More likely the card is in full duplex mode talking to a half duplex > network. What type of hub/switch is the KNE40BT plugged into. One > other thing to look for is what does the collision light look like? > > I've seen a batch of KNE100TX's that had real problems, I've had to > RMA about 6 of them now due to link level failure of the hardware. > They cause the collision light to come on almost solid, and behave > like what you are seeing as far as transfer rates. > > The problem I was seeing seems to be temperature related. If you turn > the machine off for a few hours and let it get nice and cool it will > run for anywhere from 10 minutes to 6 hours just fine, then whamooo.... > collisions from h*ll. -- DISCLAIMER: Anyone sending me unsolicited commercial electronic mail will be charged a $100 fee for time spent reading it. Do NOT send this type of electronic mail to me. In reading this, you automatically agree to be subjected to these terms: US Code Title 47, Sec.227(a)(2)(B), a computer/modem/printer meets the definition of a telephone fax machine. By Sec.227(b)(1)(C), it is unlawful to send any unsolicited advertisement to such equipment. By Sec.227(b)(3)(C), a violation of the aforementioned Section is punishable by action to recover actual monetary loss, or $500, whichever is greater, for each violation To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 19 10:27:12 1999 Delivered-To: freebsd-current@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id D028114E18; Sat, 19 Jun 1999 10:27:06 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id LAA06370; Sat, 19 Jun 1999 11:27:06 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199906191727.LAA06370@panzer.plutotech.com> Subject: Re: 4GB dram In-Reply-To: <19990619010012.A10860@nuxi.com> from "David O'Brien" at "Jun 19, 1999 01:00:12 am" To: obrien@FreeBSD.ORG Date: Sat, 19 Jun 1999 11:27:05 -0600 (MDT) Cc: freebsd-current@FreeBSD.ORG 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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien wrote... > > You should be able to strip a kernel down enough to fit it on a floppy, > > although you will have to specify some non-standard options. Two options > > that you'll want to use are: > > > > options SCSI_NO_SENSE_STRINGS > > options SCSI_NO_OP_STRINGS > > > > That will disable SCSI sense code and op code description strings. > > Removing everything related to SCSI would also do the same thing, right? Yes, and it would also keep him from accessing any SCSI devices. That may or may not be a problem for him. The other thing I should say is that those options are not for general consumption. They should only be used when you have to save space above all else. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 19 10:41: 2 1999 Delivered-To: freebsd-current@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 8AF5E14D07; Sat, 19 Jun 1999 10:40:50 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id NAA61296; Sat, 19 Jun 1999 13:40:17 -0400 (EDT) Date: Sat, 19 Jun 1999 13:40:17 -0400 (EDT) From: Chuck Robey To: "David O'Brien" Cc: David Scheidt , freebsd-current@FreeBSD.ORG Subject: Re: bsd.lib.mk "@"'s In-Reply-To: <19990619010330.B10860@nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 19 Jun 1999, David O'Brien wrote: > > How often do your calls to ld, mv and rm fail? > > There certainly bit me on the EGCS import into the tree. > (can't remember now if it was when changing libgcc or libstdc++) > > Took me quite a while to realize what was going wrong. God, it's been so long since this thread died ... quick, can anyone even identify what the argument was about? (Those of you with elephant memories, that was a joke!) > > -- > -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 19 15:29:38 1999 Delivered-To: freebsd-current@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 83427151DA for ; Sat, 19 Jun 1999 15:29:27 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id SAA77105 for ; Sat, 19 Jun 1999 18:28:51 -0400 (EDT) Date: Sat, 19 Jun 1999 18:28:51 -0400 (EDT) From: Chuck Robey To: current@freebsd.org Subject: ctm status Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG New disk going in tomorrow. It'll probably take a long while to copy things, but ctm will either be back late Sunday or sometime Monday. Thanks to Ulf for this, he's volunteering it for us! ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 19 15:39:52 1999 Delivered-To: freebsd-current@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 629FD1535F for ; Sat, 19 Jun 1999 15:39:40 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id SAA77161 for ; Sat, 19 Jun 1999 18:39:05 -0400 (EDT) Date: Sat, 19 Jun 1999 18:39:05 -0400 (EDT) From: Chuck Robey To: freebsd-current@FreeBSD.ORG Subject: laying down tags Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I notice that in the last 6 months a change has occurred in how we use our cvs tools, in that there's a great increase in the usage of tags. Every time someone lays down a tag it permanently grows the cvs archive. Has anyone looked recently at the size of that darn thing? It's getting very distinctly overweight. I know that ports have a lot to do with the growth of cvs, but not all by a long shot. I also notice that while I often want to see the last version of a particular port, I can not remember, ever, needing to see more than that. The ports tree's profusion of 2-4 versions of the same piece of software, often with little justification (as long as packages exist), is also greatly adding to the cvs archives corpulent state. I'm wondering if maybe permission to lay down a tag shouldn't be reserved to core, just because it might serve as a speed brake. I don't want to eliminate the process, but we're overdoing it. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 19 19: 0:44 1999 Delivered-To: freebsd-current@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 977CA14BE5 for ; Sat, 19 Jun 1999 19:00:42 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id TAA69075; Sat, 19 Jun 1999 19:02:13 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Chuck Robey Cc: freebsd-current@FreeBSD.ORG Subject: Re: laying down tags In-reply-to: Your message of "Sat, 19 Jun 1999 18:39:05 EDT." Date: Sat, 19 Jun 1999 19:02:13 -0700 Message-ID: <69071.929844133@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I notice that in the last 6 months a change has occurred in how we use > our cvs tools, in that there's a great increase in the usage of tags. And that's a good thing. Even though it adds some file bloat, insufficient use of tags has made some painful events in the past more painful than they had to be and it restricted other people from doing certain types of experimental work. We have been traditionally quite tag-shy for the reasons you mention and it limits the full benefits of CVS considerably to be so. > I also notice that while I often want to see the last version of a > particular port, I can not remember, ever, needing to see more than > that. The ports tree's profusion of 2-4 versions of the same piece of That's why ports are rarely tagged. In short, I disagree completely with you on the question of tags. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 19 20:50: 6 1999 Delivered-To: freebsd-current@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 0DA8214F22 for ; Sat, 19 Jun 1999 20:49:59 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id XAA77852; Sat, 19 Jun 1999 23:49:16 -0400 (EDT) Date: Sat, 19 Jun 1999 23:49:16 -0400 (EDT) From: Chuck Robey To: "Jordan K. Hubbard" Cc: freebsd-current@FreeBSD.ORG Subject: Re: laying down tags In-Reply-To: <69071.929844133@zippy.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 19 Jun 1999, Jordan K. Hubbard wrote: > > I notice that in the last 6 months a change has occurred in how we use > > our cvs tools, in that there's a great increase in the usage of tags. > > And that's a good thing. Even though it adds some file bloat, > insufficient use of tags has made some painful events in the past more > painful than they had to be and it restricted other people from doing > certain types of experimental work. We have been traditionally quite > tag-shy for the reasons you mention and it limits the full benefits of > CVS considerably to be so. > > > I also notice that while I often want to see the last version of a > > particular port, I can not remember, ever, needing to see more than > > that. The ports tree's profusion of 2-4 versions of the same piece of > > That's why ports are rarely tagged. I should not have brought up the thing about ports in that post, because while ports' bloat annoys me, it hasn't anything to do with tags, and probably just served to confuse. > In short, I disagree completely with you on the question of tags. Would you mind giving one example where not having tags hurt us? I just want to fix in my head the type of thing, because it seems to me that the same effect could have been gotten another (cheaper) way, and one example will probably set me straight. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message