From owner-freebsd-hackers Sun Nov 23 00:24:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA28181 for hackers-outgoing; Sun, 23 Nov 1997 00:24:58 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sunny.bog.msu.su (dima@sunny.bog.msu.su [158.250.20.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA28171 for ; Sun, 23 Nov 1997 00:24:51 -0800 (PST) (envelope-from dima@bog.msu.su) Received: from localhost (dima@localhost) by sunny.bog.msu.su (8.8.6/8.8.0) with SMTP id LAA06059; Sun, 23 Nov 1997 11:19:32 +0300 (????) Date: Sun, 23 Nov 1997 11:19:31 +0300 (????) From: Dmitry Khrustalev To: Jaye Mathisen cc: David Greenman , hackers@FreeBSD.ORG Subject: Re: Serious performance issue with 2.2.5-RELEASE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 22 Nov 1997, Jaye Mathisen wrote: > > I do not believe so. What ever it is definitely appears related to > swapping/paging somehow. I beleive the following patch to apache should improve situation: --- alloc.c.old Sun Nov 23 11:15:31 1997 +++ alloc.c Sun Nov 23 11:16:34 1997 @@ -199,7 +199,8 @@ /* Nope. */ min_size += BLOCK_MINFREE; - return malloc_block((min_size > BLOCK_MINALLOC) ? min_size : BLOCK_MINALLOC); + return malloc_block((min_size > BLOCK_MINALLOC - sizeof(union block_hdr)) ? + min_size : BLOCK_MINALLOC - sizeof(union block_hdr)); } > > I get these LA spikes in the several hundreds, the disk light is on solid > for 2-3 minutes, then it all goes away. > > System accounting doesn't show any unusual pattern of apps being run. The > vast majority are perl scripts. > > There's about 1100 processes on the machine, give or take a few, with > about 80MB RAM free. > > NFS is compiled in, but not used. > > I have also disabled ntpd thinking something was hanging there, but > no dice. > > > > On Sat, 22 Nov 1997, David Greenman wrote: > > > >I upgraded my web server to 2.2.5 from 2.2.2-stable, dated sometime in > > >July. > > > > > >Big mistake. > > > > > >The only update to take place was the make buildworld, make installworld, > > >no other configuration files were modified, nor any changes to startup > > >scripts, etc. > > > > > >I now get these weird pauses where everything on the machine just freezes > > >for 30-40 seconds, sometimes longer. NFS is compiled in, but not in use. > > > > > >The system was a web server, and was happily serving up several hundred > > >domains. Now with the upgrade, I'll be lucky to keep them. Not good. > > > > > >It's a Super Micro P6, 384MB RAM, 2 SCSI disks off a bus-logic controller. > > > > > >Any ideas appreciated. I have built a new kernel from sources supped > > >11/7, but it doesn't seem to be any better. > > > > Is it possible that the slowness could actually be a network related > > problem involving the updated 'de' driver in 2.2.5? > > > > -DG > > > > David Greenman > > Core-team/Principal Architect, The FreeBSD Project > > > From owner-freebsd-hackers Sun Nov 23 01:36:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA01239 for hackers-outgoing; Sun, 23 Nov 1997 01:36:59 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from atlantis.ping.at (a064.static.Vienna.AT.EU.net [193.154.186.64]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA01220 for ; Sun, 23 Nov 1997 01:36:53 -0800 (PST) (envelope-from hfwirth@eunet.at) Received: from atlantis (localhost.ping.at [127.0.0.1]) by atlantis.ping.at (8.8.8/8.6.12) with SMTP id KAA00684; Sun, 23 Nov 1997 10:36:55 +0100 (MET) Message-ID: <3477F937.41C67EA6@eunet.at> Date: Sun, 23 Nov 1997 10:36:55 +0100 From: "Helmut F. Wirth" X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Adaptec 2940 timeout problems, again Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I just sent a new bug report: The (at last for me old) problem with the ADAPTEC reporting "timed out while idle" bites again: sd0: SCB 0x1 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 SEQADDR = 0x8 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa sd0: Queueing an Abort SCB sd0: Abort Message Sent sd0: SCB 1 - Abort Completed. sd0: no longer in timeout .... The behaviour is improved somewhat as the system seems to recover in many cases. But a hard reset does not help, if the system hangs: I have to power cycle the system to bring the disk to work again. The disk is in a very peculiar state, as it responds to the BIOS while booting, but it then hangs during the boot (boot block loads, then it hangs). Here is the relevant part of the kernel boot: Nov 23 09:42:58 atlantis /kernel: ahc0: aic7880 Single Channel, SCSI Id=7, 16 SCBs Nov 23 09:42:58 atlantis /kernel: ahc0: waiting for scsi devices to settle Nov 23 09:42:58 atlantis /kernel: scbus0 at ahc0 bus 0 Nov 23 09:42:58 atlantis /kernel: sd0 at scbus0 target 0 lun 0 Nov 23 09:42:58 atlantis /kernel: sd0: type 0 fixed SCSI 2 Nov 23 09:42:58 atlantis /kernel: sd0: Direct-Access 2050MB (4199760 512 byte sectors) Nov 23 09:42:58 atlantis /kernel: sd1 at scbus0 target 1 lun 0 Nov 23 09:42:58 atlantis /kernel: sd1: type 0 fixed SCSI 2 Nov 23 09:42:58 atlantis /kernel: sd1: Direct-Access 1034MB (2118144 512 byte sectors) Nov 23 09:42:58 atlantis /kernel: sd2 at scbus0 target 2 lun 0 Nov 23 09:42:58 atlantis /kernel: sd2: type 0 fixed SCSI 2 Nov 23 09:42:58 atlantis /kernel: sd2: Direct-Access 2151MB (4406960 512 byte sectors) Nov 23 09:42:58 atlantis /kernel: sd3 at scbus0 target 3 lun 0 Nov 23 09:42:58 atlantis /kernel: sd3: type 0 removable SCSI 2 Nov 23 09:42:58 atlantis /kernel: sd3: Direct-Access Nov 23 09:42:58 atlantis /kernel: sd3: ILLEGAL REQUEST asc:24,0 Invalid field in CDB Nov 23 09:42:58 atlantis /kernel: sd3 could not mode sense (4). Using ficticious geometry Nov 23 09:42:58 atlantis /kernel: Nov 23 09:42:58 atlantis /kernel: sd3: NOT READY asc:3a,0 Medium not present Nov 23 09:42:58 atlantis /kernel: sd3: could not get size I have currently AHC_ALLOW_MEMIO, AHC_TAGENABLE and AHC_SCBPAGING_ENABLE *disabled*, i.e. they are not in my kernel configuration. The error occurs with heavy disk load (for example while building world for FreeBSD-current). It seems to be limited to sd0, a QUANTUM ATLAS disk. The second QUANTUM disk (sd2) has *upgraded* firmware, for the first disk there is no upgrade available (the disk is about one year older). For more detail please see my bug report (i386/5128). Any hints ? This is really annoying, any hint would help. Thank you. Helmut F. Wirth Email: hfwirth@eunet.at From owner-freebsd-hackers Sun Nov 23 02:05:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA02356 for hackers-outgoing; Sun, 23 Nov 1997 02:05:45 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ha1.rdc1.nj.home.com (siteadm@ha1.rdc1.nj.home.com [24.3.128.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA02348 for ; Sun, 23 Nov 1997 02:05:41 -0800 (PST) (envelope-from luomat@luomat.peak.org) Received: from luomat.peak.org ([24.2.83.40]) by ha1.rdc1.nj.home.com (Netscape Mail Server v2.02) with ESMTP id AAA27256; Sun, 23 Nov 1997 02:05:40 -0800 Received: (from luomat@localhost) by luomat.peak.org (8.8.5/8.8.7) id FAA00765; Sun, 23 Nov 1997 05:05:39 -0500 (EST) Message-Id: <199711231005.FAA00765@luomat.peak.org> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 4.1mach v148) X-Image-URL: http://www.peak.org/~luomat/next/luomat@peak.org.tiff In-Reply-To: <3477F937.41C67EA6@eunet.at> X-Nextstep-Mailer: Mail 4.1mach (Enhance 2.0b6.5) Received: by NeXT.Mailer (1.148.RR) From: Timothy J Luoma Date: Sun, 23 Nov 97 05:05:31 -0500 To: "Helmut F. Wirth" Subject: Re: Adaptec 2940 timeout problems, again cc: freebsd-hackers@freebsd.org References: <3477F937.41C67EA6@eunet.at> X-Image-URL-Disclaimer: hey, it's off my student ID, gimme a break ;-) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Author: "Helmut F. Wirth" Original-Date: Sun, 23 Nov 1997 10:36:55 +0100 Message-ID: <3477F937.41C67EA6@eunet.at> > Any hints ? This is really annoying, any hint would help. I don't know if this will help, but when I was having a problem like this under NeXTStep, it was the wrong setting for the Adaptec termination.... I think I had it on AUTOTERM and it needed to be on DISABLED. I might be wrong, YMMV, use @ your own risk etc etc but if you have not tried that it might be one option. TjL From owner-freebsd-hackers Sun Nov 23 04:54:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA06860 for hackers-outgoing; Sun, 23 Nov 1997 04:54:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id EAA06855 for ; Sun, 23 Nov 1997 04:53:58 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id NAA20050; Sun, 23 Nov 1997 13:53:57 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id NAA00720; Sun, 23 Nov 1997 13:51:33 +0100 (MET) Message-ID: <19971123135133.QT63402@uriah.heep.sax.de> Date: Sun, 23 Nov 1997 13:51:33 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Cc: scott@cray-ymp.acm.stuorg.vt.edu (Scott Gasch) Subject: Re: Question about swapping References: <199711202147.QAA27967@cray-ymp.acm.stuorg.vt.edu> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199711202147.QAA27967@cray-ymp.acm.stuorg.vt.edu>; from Scott Gasch on Nov 20, 1997 16:47:46 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Scott Gasch wrote: > Did I miss something? Reading the swapinfo and swapon > man pages led me to believe there was no two partition > limit... There's a four partition limit in -current. I don't understand the possible source for a two partition limit though. The actual limit is NSWAPDEV, which is a kernel compile-time option (well, not a good one, it's not officially supported, you gotta recompile vm_swap.o after changing the option). NSWAPDEV defaults to 4 in /sys/vm/vm_swap.c. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Nov 23 08:20:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA16777 for hackers-outgoing; Sun, 23 Nov 1997 08:20:52 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA16772 for ; Sun, 23 Nov 1997 08:20:47 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA21371 (5.67b/IDA-1.5 for FreeBSD-hackers@freebsd.org); Sun, 23 Nov 1997 17:20:45 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id MAA07250; Sun, 23 Nov 1997 12:55:06 +0100 (MET) From: Wilko Bulte Message-Id: <199711231155.MAA07250@yedi.iaf.nl> Subject: Re: volume control on SCSI Toshiba CDdrive To: jack@diamond.xtalwind.net (jack) Date: Sun, 23 Nov 1997 12:55:06 +0100 (MET) Cc: FreeBSD-hackers@freebsd.org (FreeBSD hackers list) In-Reply-To: from "jack" at Nov 22, 97 01:33:54 pm X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As jack wrote... > On Sat, 22 Nov 1997, Wilko Bulte wrote: > > > The 4x Toshiba audio volume was controllable using the WorkMan 'slide'. > > It seems that the 12x Toshiba does not respond to this. AFAIK > > the volume stuff is part of the SCSI standard these days. > > May be a Toshiba thing. I've got a > > (ahc0:6:0): "TOSHIBA CD-ROM XM-3801TA 0207" type 5 removable SCSI 2 > > mixer and xmixer work fine. None of the X or commandline cdplayers can > set the volume. With my previous drive Sep 6 19:52:12 yedi /kernel: (ncr0:4:0): "TOSHIBA CD-ROM XM-5301TA 0925" the volumecontrol worked just fine.. Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ---------------- Support your local daemons: run [Free,Net]BSD Unix --Yoda From owner-freebsd-hackers Sun Nov 23 09:47:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA20992 for hackers-outgoing; Sun, 23 Nov 1997 09:47:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sierra.covalent.net (sierra.covalent.net [208.214.59.61]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA20984 for ; Sun, 23 Nov 1997 09:47:21 -0800 (PST) (envelope-from randy@sierra.covalent.net) Received: from sierra (localhost [127.0.0.1]) by sierra.covalent.net (8.8.7/8.8.2) with ESMTP id LAA12054; Sun, 23 Nov 1997 11:47:05 -0600 (CST) Message-Id: <199711231747.LAA12054@sierra.covalent.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: Jaye Mathisen cc: David Greenman , hackers@FreeBSD.ORG Subject: Re: Serious performance issue with 2.2.5-RELEASE In-reply-to: mrcpu's message of Sat, 22 Nov 1997 22:51:33 -0800. X-uri: http://www.zyzzyva.com/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Nov 1997 11:47:05 -0600 From: Randy Terbush Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I've been seeing the same sorts of problems on a P5-200. Single 4GB SCSI Ultrawide Adaptec 2940 UW 128MB RAM IPFIREWALL IPDIVERT NFS NETATALK Cyclades The system is an NFS client and web server. If NFS mounts are made *without* nfsv2 option, NFS services will hang after about 2 days. This machine has multiple network interfaces. ed, fxp, ep I too have come to the conclusion that it is long delays moving things in and out of swap. I'm happy to share more information if someone requests it. Note: the same setup was working fine running 2.2-STABLE. -Randy > I do not believe so. What ever it is definitely appears related to > swapping/paging somehow. > > I get these LA spikes in the several hundreds, the disk light is on solid > for 2-3 minutes, then it all goes away. > > System accounting doesn't show any unusual pattern of apps being run. The > vast majority are perl scripts. > > There's about 1100 processes on the machine, give or take a few, with > about 80MB RAM free. > > NFS is compiled in, but not used. > > I have also disabled ntpd thinking something was hanging there, but > no dice. > > > > On Sat, 22 Nov 1997, David Greenman wrote: > > > >I upgraded my web server to 2.2.5 from 2.2.2-stable, dated sometime in > > >July. > > > > > >Big mistake. > > > > > >The only update to take place was the make buildworld, make installworld, > > >no other configuration files were modified, nor any changes to startup > > >scripts, etc. > > > > > >I now get these weird pauses where everything on the machine just freezes > > >for 30-40 seconds, sometimes longer. NFS is compiled in, but not in use. > > > > > >The system was a web server, and was happily serving up several hundred > > >domains. Now with the upgrade, I'll be lucky to keep them. Not good. > > > > > >It's a Super Micro P6, 384MB RAM, 2 SCSI disks off a bus-logic controller. > > > > > >Any ideas appreciated. I have built a new kernel from sources supped > > >11/7, but it doesn't seem to be any better. > > > > Is it possible that the slowness could actually be a network related > > problem involving the updated 'de' driver in 2.2.5? > > > > -DG > > > > David Greenman > > Core-team/Principal Architect, The FreeBSD Project > > From owner-freebsd-hackers Sun Nov 23 13:18:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA02264 for hackers-outgoing; Sun, 23 Nov 1997 13:18:40 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iworks.InterWorks.org (deischen@iworks.interworks.org [128.255.18.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA02254 for ; Sun, 23 Nov 1997 13:18:36 -0800 (PST) (envelope-from deischen@iworks.InterWorks.org) Received: (from deischen@localhost) by iworks.InterWorks.org (8.7.5/) id PAA23932 for freebsd-hackers@freebsd.org; Sun, 23 Nov 1997 15:20:55 -0600 (CST) Message-Id: <199711232120.PAA23932@iworks.InterWorks.org> Date: Sun, 23 Nov 1997 15:20:55 -0600 (CST) From: "Daniel M. Eischen" To: freebsd-hackers@freebsd.org Subject: pthread_cond_timedwait returning wrong error? Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is EAGAIN the correct error for a timeout from a pthread_cond_timedwait() call? I would think that ETIMEDOUT would be more appropriate. I got hung up on this in trying to upgrade the port of GNAT. It seems that all the other GNAT targets rely on ETIMEDOUT being returned from a timeout in pthread_cond_timedwait(). Namely, OpenVMS, Solaris, RTEMS, Linux, and DEC Unix. Should I submit a PR with patch to correct it? Dan Eischen deischen@iworks.InterWorks.org From owner-freebsd-hackers Sun Nov 23 14:55:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA08233 for hackers-outgoing; Sun, 23 Nov 1997 14:55:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cleopatra.ultra.net (cleopatra.ultra.net [199.232.56.35]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA08204 for ; Sun, 23 Nov 1997 14:55:11 -0800 (PST) (envelope-from moncrg@ma.ultranet.com) Received: from d8.b66.cmb.ma.ultra.net (d8.b66.cmb.ma.ultra.net [209.6.66.8]) by cleopatra.ultra.net (8.8.5/ult1.05) with SMTP id RAA08484; Sun, 23 Nov 1997 17:54:51 -0500 (EST) From: moncrg@ma.ultranet.com (Greg Moncreaff) To: hackers@FreeBSD.ORG Cc: matt@3am-software.com Subject: (fwd) Re: [q] 2.2.5 ifmib (dot3), sysctl; (de,ed) ATTN wollman, bde Date: Sun, 23 Nov 1997 22:54:55 GMT Message-ID: <3479b3f0.2157593@pop.ma.ultranet.com> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id OAA08208 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 21 Nov 1997 21:29:17 GMT, in comp.unix.bsd.freebsd.misc kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote: >Sorry, I can't answer your questions, but I think >you'll probably get faster response to your questions if >you send mail to either the freebsd-hacker or freebsd-current >mailing list. Although I see occasional posts by Bruce (bde), >I think neither Garrett or Bruce regularly read the newsgroups. > >BTW, Matt Thomas (matt@3am-software.com) wrote the if_de.f driver, >so you might address this question to him. > >In article <3475ECFC.7EA3@res.raytheon.com>, > Greg Moncreaff writes: >> this looks promising but none of the drivers seem to 'plug in' >> to this interface. if_de has a stat table very close to the >> dot3 mib (why doesn't it use if_mib.h?) if_ed actually declares >> an instance of the dot3 stats and connects it to if_link... >> >> what is needed to go the rest of the distance? is there some >> missing SYSCTL_??? delclaration? what would it look like? it >> looks like there was some thinking on it in ncr.c that didn't get >> finished... >-- >Steve From owner-freebsd-hackers Sun Nov 23 15:05:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA08920 for hackers-outgoing; Sun, 23 Nov 1997 15:05:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from zen.nash.org (nash.pr.mcs.net [204.95.47.72]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA08896 for ; Sun, 23 Nov 1997 15:05:04 -0800 (PST) (envelope-from alex@zen.nash.org) Received: (from alex@localhost) by zen.nash.org (8.8.8/8.8.7) id RAA19042; Sun, 23 Nov 1997 17:01:37 -0600 (CST) (envelope-from alex) Message-Id: <199711232301.RAA19042@zen.nash.org> Date: Sun, 23 Nov 1997 17:01:37 -0600 (CST) From: Alex Nash Reply-To: nash@mcs.com Subject: Re: pthread_cond_timedwait returning wrong error? To: deischen@iworks.InterWorks.org cc: freebsd-hackers@freebsd.org In-Reply-To: <199711232120.PAA23932@iworks.InterWorks.org> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 23 Nov, Daniel M. Eischen wrote: > > Is EAGAIN the correct error for a timeout from a > pthread_cond_timedwait() call? I would think that > ETIMEDOUT would be more appropriate. According to my 1996 edition of ANSI/IEEE std 1003.1, you are correct -- ETIMEDOUT should be returned. I've committed a fix for this into -current. Thanks. Alex From owner-freebsd-hackers Sun Nov 23 18:58:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA25837 for hackers-outgoing; Sun, 23 Nov 1997 18:58:29 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ren.dtir.qld.gov.au (firewall-user@ns.dtir.qld.gov.au [203.108.138.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA25826 for ; Sun, 23 Nov 1997 18:58:22 -0800 (PST) (envelope-from syssgm@dtir.qld.gov.au) Received: by ren.dtir.qld.gov.au; id MAA04446; Mon, 24 Nov 1997 12:59:07 +1000 (EST) Received: from ogre.dtir.qld.gov.au(167.123.8.3) by ren.dtir.qld.gov.au via smap (3.2) id xma004432; Mon, 24 Nov 97 12:58:37 +1000 Received: from localhost.dtir.qld.gov.au (localhost.dtir.qld.gov.au [127.0.0.1]) by ogre.dtir.qld.gov.au (8.8.7/8.8.7) with SMTP id MAA20135; Mon, 24 Nov 1997 12:57:40 +1000 (EST) Message-Id: <199711240257.MAA20135@ogre.dtir.qld.gov.au> X-Authentication-Warning: ogre.dtir.qld.gov.au: localhost.dtir.qld.gov.au [127.0.0.1] didn't use HELO protocol To: Wilko Bulte cc: freebsd-hackers@freebsd.org, syssgm@dtir.qld.gov.au Subject: Re: volume control on SCSI Toshiba CDdrive References: <199711212325.AAA06628@yedi.iaf.nl> In-Reply-To: <199711212325.AAA06628@yedi.iaf.nl> from Wilko Bulte at "Fri, 21 Nov 1997 23:25:59 +0000" Date: Mon, 24 Nov 1997 12:57:39 +1000 From: Stephen McKay Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Friday, 21st November 1997, Wilko Bulte wrote: >I just changed my old 4x Toshiba cdrom to a 12x Toshiba. >To be precise, it is a TOSHIBA CD-ROM XM-5701TA 3136. > >The 4x Toshiba audio volume was controllable using the WorkMan 'slide'. >It seems that the 12x Toshiba does not respond to this. AFAIK >the volume stuff is part of the SCSI standard these days. > >Any comments of fellow XM5701 owners? I have the same problem. Everything else works. :-) xmcd could control volume on my old NEC 4x, but the new Toshiba ignores it. It's just about impossible to keep a list of good working hardware. :-( Does anyone have an inside contack at Toshiba? Maybe there is a workaround. If not, at least they will be able to club somebody! Stephen. From owner-freebsd-hackers Sun Nov 23 20:11:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA00983 for hackers-outgoing; Sun, 23 Nov 1997 20:11:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA00976 for ; Sun, 23 Nov 1997 20:11:37 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id UAA22956; Sun, 23 Nov 1997 20:02:35 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd022954; Sun Nov 23 20:02:27 1997 Date: Sun, 23 Nov 1997 20:00:19 -0800 (PST) From: Julian Elischer To: Alex Nash cc: deischen@iworks.InterWorks.org, freebsd-hackers@freebsd.org Subject: Re: pthread_cond_timedwait returning wrong error? In-Reply-To: <199711232301.RAA19042@zen.nash.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk don't forget 2.2.x (it has basically the same code) On Sun, 23 Nov 1997, Alex Nash wrote: > On 23 Nov, Daniel M. Eischen wrote: > > > > Is EAGAIN the correct error for a timeout from a > > pthread_cond_timedwait() call? I would think that > > ETIMEDOUT would be more appropriate. > > According to my 1996 edition of ANSI/IEEE std 1003.1, you are correct -- > ETIMEDOUT should be returned. I've committed a fix for this into > -current. > > Thanks. > > Alex > > > From owner-freebsd-hackers Sun Nov 23 20:40:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA02766 for hackers-outgoing; Sun, 23 Nov 1997 20:40:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA02759 for ; Sun, 23 Nov 1997 20:40:10 -0800 (PST) (envelope-from bsampley@bsampley.vip.best.com) Received: from bsampley (bsampley.vip.best.com [206.184.160.196]) by proxy4.ba.best.com (8.8.7/8.8.BEST) with SMTP id UAA29503 for ; Sun, 23 Nov 1997 20:38:53 -0800 (PST) Date: Sun, 23 Nov 1997 20:35:20 -0800 (PST) From: Burton Sampley X-Sender: bsampley@bsampley To: hackers@FreeBSD.org Subject: problem mounting /cdrom w/ 2.2.5-R (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Greetings, I sent the original copy of this message to -questions, if you subscribe to both, sorry. This is a weird problem that I can't figure out. BTW, the 2 Mavericks are intentionally not being mounted. We upgraded to a larger HD, but I left the old drives in the box long enough to determine that all necessary user data has been cp'd to the new drive. One other thing I don't understand. The Adaptec 2842 (? w/floppy) SCSI card is actually a VLB card, but it's being probed as eisa. It that correct? Thanks for your help. - - burton - - --------- (fwd) I just completed a new install of 2.2.5-R on to a 'virgin' HD at work. I'm having a strange problem I don't understand. If I try to mount a cdrom with mount /cdrom (as root) I get the following error: root@thingie(101)# mount /cdrom cd9660: /dev/cd0a: Device not configured root@thingie(102)# cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/sd0s1b none swap sw 0 0 /dev/sd0a / ufs rw 1 1 /dev/sd0s1f /usr ufs rw 2 2 /dev/sd0s1e /var ufs rw 2 2 proc /proc procfs rw 0 0 /dev/cd0a /cdrom cd9660 ro,noauto 0 0 root@thingie(103)# If I try mounting the *same* cdrom with mount_cd9660 /dev/cd0a or mount -t cd9660 /dev/cd0a it works. I have included a copy of my /etc/fstab which has not been modified since the install. Any ideas? Here's the output from dmesg; Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 2.2.5-RELEASE #0: Tue Oct 21 14:33:00 GMT 1997 jkh@time.cdrom.com:/usr/src/sys/compile/GENERIC CPU: i486DX (486-class CPU) real memory = 16777216 (16384K bytes) avail memory = 14438400 (14100K bytes) ahc0: at 0x1c00-0x1cff irq 11 on eisa0 slot 1 ahc0: aic7770 >= Rev E, Single Channel, SCSI Id=7, 4 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "QUANTUM FIREBALL ST2.1S 0F0C" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 2068MB (4235629 512 byte sectors) (ahc0:1:0): "QUANTUM MAVERICK 540S 0905" type 0 fixed SCSI 2 sd1(ahc0:1:0): Direct-Access 516MB (1057758 512 byte sectors) (ahc0:2:0): "QUANTUM MAVERICK 540S 0905" type 0 fixed SCSI 2 sd2(ahc0:2:0): Direct-Access 516MB (1057758 512 byte sectors) (ahc0:3:0): "TOSHIBA CD-ROM XM-3701TA 2965" type 5 removable SCSI 2 cd0(ahc0:3:0): CD-ROM can't get the size (ahc0:4:0): "ARCHIVE Python 25588-XXX 2.96" type 1 removable SCSI 2 st0(ahc0:4:0): Sequential-Access density code 0x0, variable blocks, write-enabled Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 at 0x300-0x31f irq 10 on isa ed0: address 00:40:c7:59:d1:aa, type NE2000 (16 bit) sio0 not found at 0x3f8 sio1 not found at 0x2f8 lpt0 not found at 0xffffffff fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in npx0 flags 0x1 on motherboard npx0: INT 16 interface changing root device to sd0a cd0(ahc0:3:0): NOT READY asc:3a,0 Medium not present cd0(ahc0:3:0): NOT READY asc:3a,0 Medium not present - - burton - - --------------- Burton Sampley bsampley@best.com or bsampley@haywire.csuhayward.edu PGP key available at http://www.best.com/~bsampley/pgp.html -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNHkEEHt2O8KJtMdBAQGXKAQAg8b2jWNqPA48PN7mEYT5VFJCUS3KdcQl LxQPmLYYNZjjNa+/+ajQYHLXpPkUU5YGBlk9wjgy6j85B2+GWoHeVGKukHM45Wve FmZd1Q1SRu4+VUJAuPHjdloKI0A/BjQTMyEA2IEC+GjmBbRiY4pvEwbEgjfshg1n DXQkHSU5oPc= =1QI/ -----END PGP SIGNATURE----- From owner-freebsd-hackers Sun Nov 23 20:48:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA03311 for hackers-outgoing; Sun, 23 Nov 1997 20:48:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA03300 for ; Sun, 23 Nov 1997 20:48:25 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-53-93.ca.us.ibm.net (slip129-37-53-93.ca.us.ibm.net [129.37.53.93]) by out1.ibm.net (8.8.5/8.6.9) with SMTP id EAA71270; Mon, 24 Nov 1997 04:47:49 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans Cc: hackers@freebsd.org Subject: Re: Status of 650 UART support Date: Mon, 24 Nov 1997 05:48:49 GMT Message-ID: <347901e5.3980414@smtp-gw01.ny.us.ibm.net> References: <199711230739.SAA19794@godzilla.zeta.org.au> In-Reply-To: <199711230739.SAA19794@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id UAA03301 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 23 Nov 1997 18:39:28 +1100, Bruce Evans wrote: >>After emptying the block, you could leave any remaining characters in >>the FIFO, and simply get them on the next interrupt >Here is some (low quality, old and unfinished) code for doing this. >It has some interface changes (void *vcom, and siointr1() called >directly from XintrN()) that won't work in -current. I applied the patch to 2.2.5 sio.c -- the first hunk failed but the rest succeeded. Just curious, what is vcom all about? In any case, after starting to analyze the patch vs. sio.c I have many questions of a more urgent nature. In siointr I read the following comment: >/* > * Loop until there is no activity on any port. This is necessary > * to get an interrupt edge more than to avoid another interrupt. > * If the IRQ signal is just an OR of the IRQ signals from several > * devices, then the edge from one may be lost because another is > * on. > */ I believe this is untrue. If so, that may call certain aspects of siointr into question. On an ISA bus, several devices cannot OR their IRQ lines at all, unless you are willing to heat up a soldering iron, or purchase a multiport card with hardware logic for IRQ sharing. Otherwise, the totem pole output of any one device holding its line low will sink the output of all others to ground and you will never see an interrupt from any of the ORed devices. Any device which is active *must* either pull the line to ground or drive it high. An active device cannot float its output, because a transition from floating to high will not guarantee a rising edge. The transition *must* be from ground to high. Without soldering techniques or extra hardware logic, the only type of ISA bus IRQ ORing possible is where the devices have tri-state outputs and only one is active while the rest float. An example is the classic case of COM1/COM3 where both try to use the same IRQ line, but not simultaneously. They "share" the IRQ line like you and I might share a book -- we can't both use it at the same time. Incidentally, there is some code in sioprobe which floats the IRQ output of all UARTs, attempting to find all which may be "sharing" an IRQ in the COM1/COM3 manner. I would change that and force users to set up their COM ports correctly (at least for UNIX). ;-) I changed my own copy of sioprobe to drive the IRQ output, letting each UART pull its line to ground during sioprobe. I had to do that because I built a homebrewed OR gate for all the serial cards in one of my test machines, and I forgot to use a pull down resistor on each input and there wasn't enough room left on my proto board to add them after I was finished. It was much quicker to change that one line of code in sioprobe than throw out my custom design and start all over. Anyway, I want to purse this issue of whether looping in siointr is "necessary to get an interrupt edge," because it has a direct impact on how siointr might be improved with UART burst mode input. I wrote a code fragment in Turbo C which implements a highly optimized framework (not a finished product) for UART receiver burst mode if you want to see it. It also handles the case of FIFO timeout where you need to read characters in the usual way, one at a time. I tested it in a small terminal program and it works well. I would like to integrate it with sio.c, but I'm never satisfied with my C code until I've eliminated all goto statements. Extracting the many from sio.c might take a long time, and I don't know if I'm ready to jump into that snakepit. John From owner-freebsd-hackers Sun Nov 23 20:49:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA03406 for hackers-outgoing; Sun, 23 Nov 1997 20:49:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iworks.InterWorks.org (deischen@iworks.interworks.org [128.255.18.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA03398 for ; Sun, 23 Nov 1997 20:49:50 -0800 (PST) (envelope-from deischen@iworks.InterWorks.org) Received: (from deischen@localhost) by iworks.InterWorks.org (8.7.5/) id WAA24529; Sun, 23 Nov 1997 22:52:07 -0600 (CST) Message-Id: <199711240452.WAA24529@iworks.InterWorks.org> Date: Sun, 23 Nov 1997 22:52:07 -0600 (CST) From: "Daniel M. Eischen" To: julian@whistle.com, nash@mcs.com Subject: Re: pthread_cond_timedwait returning wrong error? Cc: freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > don't forget 2.2.x > (it has basically the same code) > > On Sun, 23 Nov 1997, Alex Nash wrote: > > > On 23 Nov, Daniel M. Eischen wrote: > > > > > > Is EAGAIN the correct error for a timeout from a > > > pthread_cond_timedwait() call? I would think that > > > ETIMEDOUT would be more appropriate. > > > > According to my 1996 edition of ANSI/IEEE std 1003.1, you are correct -- > > ETIMEDOUT should be returned. I've committed a fix for this into > > -current. > > > > Thanks. > > > > Alex While we're on the subject, can someone please add uthread_sigwait to Makefile.inc in lib/libc_r/uthread? I've been wanting this for a while; the GNAT port needs this to work. The code is there, it's just that the function isn't included in the make. *** Makefile.inc.orig Sun Nov 16 19:06:14 1997 --- Makefile.inc Sun Nov 23 23:42:23 1997 *************** *** 83,88 **** --- 83,89 ---- uthread_sigprocmask.c \ uthread_sigsetmask.c \ uthread_sigsuspend.c \ + uthread_sigwait.c \ uthread_socket.c \ uthread_socketpair.c \ uthread_spec.c \ One last question. The other GNAT targets (Linux, Open/VMS, RTEMS, etc) all seem to want the errno to be _returned_ by pthread_cond_timedwait (and a couple of others too). This seems wrong, -1 should be returned, and the error code should be retrieved from the thread-safe errno. What does the POSIX spec say about the return value of pthread_cond_timedwait()? Dan Eischen deischen@iworks.InterWorks.org From owner-freebsd-hackers Sun Nov 23 22:36:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA08686 for hackers-outgoing; Sun, 23 Nov 1997 22:36:52 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA08681 for ; Sun, 23 Nov 1997 22:36:48 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id RAA01234; Mon, 24 Nov 1997 17:28:47 +1100 Date: Mon, 24 Nov 1997 17:28:47 +1100 From: Bruce Evans Message-Id: <199711240628.RAA01234@godzilla.zeta.org.au> To: bde@zeta.org.au, mouth@ibm.net Subject: Re: Status of 650 UART support Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I applied the patch to 2.2.5 sio.c -- the first hunk failed but the >rest succeeded. =20 > >Just curious, what is vcom all about? In any case, after starting to It's about fixing an old bogus/slow interface. >>/* >> * Loop until there is no activity on any port. This is necessary >> * to get an interrupt edge more than to avoid another interrupt. >> * If the IRQ signal is just an OR of the IRQ signals from several >> * devices, then the edge from one may be lost because another is >> * on. >> */ > >I believe this is untrue. If so, that may call certain aspects of >siointr into question. =20 This is true :-). >On an ISA bus, several devices cannot OR their IRQ lines at all, >unless you are willing to heat up a soldering iron, or purchase a >multiport card with hardware logic for IRQ sharing. Otherwise, the >totem pole output of any one device holding its line low will sink the >output of all others to ground and you will never see an interrupt >from any of the ORed devices. This is also true :-). The code being discussed is for multiport cards with (simple) hardware logic for IRQ sharing. Not-so-simple hardware might have a way to force an edge, but siointr() is for the general case so it can't have support for or dependencies on this. The code is configured by option COM_MULTIPORT and is not used by default. Unfortunately, if you want to use just one multiport card then you have to configure COM_MULTIPORT and the code gets used for all ports, slowing down the non-multiport cards unnecessarily. Part of the patch is about fixing this (this part is very incomplete). >Incidentally, there is some code in sioprobe which floats the IRQ >output of all UARTs, attempting to find all which may be "sharing" an >IRQ in the COM1/COM3 manner. I would change that and force users to >set up their COM ports correctly (at least for UNIX). ;-) It actually attempts to float them all to begin with, then drives one. Sharing is only detected indirectly as probe failures. The usual misconfiguration is COM1/COM3 on irq4 and COM2/COM4 on irq3, but with the FreeBSD config not changed from the default of COM3 on irq5 and COM4 on irq9, so that the static conflict checking doesn't help. Another misconfiguration is COM3 or COM4 not in the FreeBSD config, but present and driving an irq that is shared with the COM1 or COM2 irq. For some reason ;-), most users don't understand the "test N failed" messages for these errors. I don't want to throw away the checking completely because users that misconfigure the COM3-4 irqs need it most. If the floating stuff could be trusted then we could determine the actual irq and print a better error message "probe failed due to irq misconfiguration (configured as 5, seems to be 4; use `?' if you want auto-configuration of 4)". >I changed my own copy of sioprobe to drive the IRQ output, letting >each UART pull its line to ground during sioprobe. I had to do that >because I built a homebrewed OR gate for all the serial cards in one >of my test machines, and I forgot to use a pull down resistor on each >input and there wasn't enough room left on my proto board to add them >after I was finished. It was much quicker to change that one line of >code in sioprobe than throw out my custom design and start all over. You mean all at the start? It's not very nice to drive sio1-N in the probe for sio0. The unhacked version just floats sio0-N and then drives the the device being probed, leaving it driven after a successful probe so that with correct configurations precisely sio0-M will be driven when sio(M+1) is probed. Even this much cross-device handling caused problems with S3 cards. The problems were worked around by disabling sio2-3 in GENERIC. This prevents all accesses to the sio2-3 registers (which may actually be video registers). Unfortunately, this breaks the floating stuff if sio2-3 are present. Users should enable them if they exist so that they don't interfere with sio0-1. Incorrect irq configuration should then just result in sio2-3 not being found. >Anyway, I want to purse this issue of whether looping in siointr is >"necessary to get an interrupt edge," because it has a direct impact >on how siointr might be improved with UART burst mode input. It's certainly necessary for simple OR gates. The IRQ outputs of the UARTs are independent so there is no guarantee that a falling edge on one will make it to the output of the OR gate. More complicated h/w could watch all the inputs and arrange for a falling edge on the final output if there is a falling edge on any input. I think this would be a good kludge for generic boards that have to work with slightly broken drivers, but it wouldn't be best - it would cause more interrupts than necessary (probably not many more). It's the scan for an active port that is wasteful. The best way to handle it would be to have a single register (32 bits if necessary :-) that gives the status of all UART irq outputs outputs on the board. I think most multiport boards have 8-bit register(s) for this. FreeBSD doesn't support them because there is no standard and I don't have any multiport boards :-). More complicated h/w could have other interesting UART outputs and programmable priorities for the active interrupts supported... (the driver can't handle scheduling very well since it would have to do too much i/o to decide which fifo needs servicing most urgently, etc). >I wrote a code fragment in Turbo C which implements a highly optimized >framework (not a finished product) for UART receiver burst mode if you >want to see it. It also handles the case of FIFO timeout where you >need to read characters in the usual way, one at a time. I tested it >in a small terminal program and it works well. Not really. I think I know what to do, butnot how to integrate it. >I would like to integrate it with sio.c, but I'm never satisfied with >my C code until I've eliminated all goto statements. Extracting the >many from sio.c might take a long time, and I don't know if I'm ready >to jump into that snakepit. There's only 3 in the standard version and they're just to get out of error cases :-). The gotos in the patch are mostly because I didn't want to integrate it properly until it was working. I expect future versions will have multiple variants of the interrupt handler (a separate one for the multiport case, etc). I don't know how to manage this right - siointr1 is too big to have 10 copies of. Bruce From owner-freebsd-hackers Sun Nov 23 22:39:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA08778 for hackers-outgoing; Sun, 23 Nov 1997 22:39:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns3.harborcom.net (ns3.harborcom.net [206.158.4.7]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA08772 for ; Sun, 23 Nov 1997 22:39:21 -0800 (PST) (envelope-from bradley@harborcom.net) Received: from bradley by ns3.harborcom.net with smtp (Exim 1.73 #1) id 0xZsAv-0005Xy-00; Mon, 24 Nov 1997 01:39:17 -0500 Date: Mon, 24 Nov 1997 01:39:17 -0500 (EST) From: Bradley Dunn X-Sender: bradley@ns3.harborcom.net To: freebsd-hackers@freebsd.org Subject: Re: pthread_cond_timedwait returning wrong error? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 23 Nov 1997, Julian Elischer wrote: > don't forget 2.2.x > (it has basically the same code) > > > Is EAGAIN the correct error for a timeout from a > > > pthread_cond_timedwait() call? I would think that > > > ETIMEDOUT would be more appropriate. > > > > According to my 1996 edition of ANSI/IEEE std 1003.1, you are correct -- > > ETIMEDOUT should be returned. I've committed a fix for this into > > -current. While we are talking about threads, any comments on PR-4376? Bradley From owner-freebsd-hackers Sun Nov 23 22:51:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA09279 for hackers-outgoing; Sun, 23 Nov 1997 22:51:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA09274 for ; Sun, 23 Nov 1997 22:50:56 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id XAA23080; Sun, 23 Nov 1997 23:50:46 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id XAA29471; Sun, 23 Nov 1997 23:49:00 -0700 (MST) Date: Sun, 23 Nov 1997 23:49:00 -0700 (MST) From: Marc Slemko To: Dmitry Khrustalev cc: hackers@freebsd.org Subject: Re: Serious performance issue with 2.2.5-RELEASE (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk While the below change will result a better fit between Apache's memory pools and the system malloc(), I am somewhat skeptical that it will have any noticable impact on 99% of the systems and even more skeptical that it could have any real impact on the problems of this thread. For those that aren't familiar with Apache's memory pools, what the below change does is make Apache use 8k as the smallest size requested from malloc() instead of a silly 8k + ~12 bytes. > ---------- Forwarded message ---------- > Date: Sun, 23 Nov 1997 11:19:31 +0300 (????) > From: Dmitry Khrustalev > To: Jaye Mathisen > Cc: David Greenman , hackers@freebsd.org > Subject: Re: Serious performance issue with 2.2.5-RELEASE > > > > On Sat, 22 Nov 1997, Jaye Mathisen wrote: > > > > > I do not believe so. What ever it is definitely appears related to > > swapping/paging somehow. > > I beleive the following patch to apache should improve situation: > > --- alloc.c.old Sun Nov 23 11:15:31 1997 > +++ alloc.c Sun Nov 23 11:16:34 1997 > @@ -199,7 +199,8 @@ > /* Nope. */ > > min_size += BLOCK_MINFREE; > - return malloc_block((min_size > BLOCK_MINALLOC) ? min_size : BLOCK_MINALLOC); > + return malloc_block((min_size > BLOCK_MINALLOC - sizeof(union block_hdr)) ? > + min_size : BLOCK_MINALLOC - sizeof(union block_hdr)); > } From owner-freebsd-hackers Sun Nov 23 23:51:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA13377 for hackers-outgoing; Sun, 23 Nov 1997 23:51:28 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA13372 for ; Sun, 23 Nov 1997 23:51:25 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA02180; Mon, 24 Nov 1997 08:51:24 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id IAA03041; Mon, 24 Nov 1997 08:47:50 +0100 (MET) Message-ID: <19971124084750.LV48775@uriah.heep.sax.de> Date: Mon, 24 Nov 1997 08:47:50 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Cc: bsampley@bsampley.vip.best.com (Burton Sampley) Subject: Re: problem mounting /cdrom w/ 2.2.5-R (fwd) References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Burton Sampley on Nov 23, 1997 20:35:20 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Burton Sampley wrote: > I just completed a new install of 2.2.5-R on to a 'virgin' HD at work. > I'm having a strange problem I don't understand. If I try to mount a > cdrom with mount /cdrom (as root) I get the following error: > > root@thingie(101)# mount /cdrom > cd9660: /dev/cd0a: Device not configured This corresponds to: > npx0 flags 0x1 on motherboard > npx0: INT 16 interface > changing root device to sd0a > cd0(ahc0:3:0): NOT READY asc:3a,0 Medium not present > cd0(ahc0:3:0): NOT READY asc:3a,0 Medium not present ...these medium not present messages. Somehow, your drive seems to think twice about whether it's actually got a medium or not. The way you invoke the mount command is irrelevant, but those messages are the indication of the evil that's going on. Apparently, the drive finally makes up its mind if you ask it often enough (which incidentally happened to be an explicit call to mount_cd9660). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Nov 23 23:54:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA13698 for hackers-outgoing; Sun, 23 Nov 1997 23:54:52 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hotmail.com (F9.hotmail.com [207.82.250.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA13687 for ; Sun, 23 Nov 1997 23:54:50 -0800 (PST) (envelope-from kami35@hotmail.com) Received: (qmail 13189 invoked by uid 0); 24 Nov 1997 07:54:20 -0000 Message-ID: <19971124075420.13188.qmail@hotmail.com> Received: from 200.3.119.193 by www.hotmail.com with HTTP; Sun, 23 Nov 1997 23:54:20 PST X-Originating-IP: [200.3.119.193] From: "Gustavo surace" To: hackers@freebsd.org Content-Type: text/plain Date: Sun, 23 Nov 1997 23:54:20 PST Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk unsubscribe ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-freebsd-hackers Mon Nov 24 00:09:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA14700 for hackers-outgoing; Mon, 24 Nov 1997 00:09:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA14695 for ; Mon, 24 Nov 1997 00:09:30 -0800 (PST) (envelope-from bsampley@bsampley.vip.best.com) Received: from bsampley (bsampley.vip.best.com [206.184.160.196]) by proxy3.ba.best.com (8.8.7/8.8.BEST) with SMTP id AAA28140; Mon, 24 Nov 1997 00:08:57 -0800 (PST) Date: Mon, 24 Nov 1997 00:05:33 -0800 (PST) From: Burton Sampley X-Sender: bsampley@bsampley To: Joerg Wunsch cc: hackers@FreeBSD.ORG Subject: Re: problem mounting /cdrom w/ 2.2.5-R (fwd) In-Reply-To: <19971124084750.LV48775@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Joerg, Actually, if I force it with either mount_cd9660 /dev/cd0a or mount -t cd9660 /dev/cd0a it *always* works. If I mount it explicitly and then umount the drive, then try it again w/ mount /cdrom it still fails. I've tried repeating mount /cdrom numerous times in a row, but it still refuses to mount the cdrom using that method. I'll try again tomorrow and post my results (the machine's at work, I'm a home, I forgot to leave a cd in the drive). I assumed the media not present erorr was just the cdrom complaining about being booted w/o a cd. - burton - On Mon, 24 Nov 1997, J Wunsch wrote: > As Burton Sampley wrote: > > > I just completed a new install of 2.2.5-R on to a 'virgin' HD at work. > > I'm having a strange problem I don't understand. If I try to mount a > > cdrom with mount /cdrom (as root) I get the following error: > > > > root@thingie(101)# mount /cdrom > > cd9660: /dev/cd0a: Device not configured > > This corresponds to: > > > npx0 flags 0x1 on motherboard > > npx0: INT 16 interface > > changing root device to sd0a > > cd0(ahc0:3:0): NOT READY asc:3a,0 Medium not present > > cd0(ahc0:3:0): NOT READY asc:3a,0 Medium not present > > ...these medium not present messages. Somehow, your drive seems to > think twice about whether it's actually got a medium or not. The way > you invoke the mount command is irrelevant, but those messages are the > indication of the evil that's going on. Apparently, the drive finally > makes up its mind if you ask it often enough (which incidentally > happened to be an explicit call to mount_cd9660). > > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) > --------------- Burton Sampley bsampley@best.com or bsampley@haywire.csuhayward.edu PGP key available at http://www.best.com/~bsampley/pgp.html From owner-freebsd-hackers Mon Nov 24 00:18:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA15292 for hackers-outgoing; Mon, 24 Nov 1997 00:18:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from chouette.inria.fr (chouette.inria.fr [138.96.24.103]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA15277 for ; Mon, 24 Nov 1997 00:18:38 -0800 (PST) (envelope-from Emmanuel.Duros@sophia.inria.fr) Received: by chouette.inria.fr (8.8.6/8.8.5) id JAA05136; Mon, 24 Nov 1997 09:18:31 +0100 (MET) Date: Mon, 24 Nov 1997 09:18:31 +0100 (MET) Message-Id: <199711240818.JAA05136@chouette.inria.fr> From: Emmanuel Duros To: hackers@FreeBSD.ORG Subject: Re: My fbsd router looses packets ! Reply-to: Emmanuel.Duros@sophia.inria.fr Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I have finally located where the pb came from. The driver of the b2 interface initiates a DMA transfer every time it needs to send a packet. The isa_dmastart() is called for every transfer. When there is at the same an incoming traffic on the other interface (I tried a Lance and a DEC Ethernet card), the PC losses packets on b1. When I comment out the isa_dmastart(), there is no more losses on b1 (but nothing is sent via b2!). I have not been able to explain this behavior yet. To me, my code looks fine, I use the set of isa_dma* functions to initiate a dma transfer, release a chanel,... My PC router (Pentium Pro) has a supermicro motherboard with 6 (!) PCI slots and 3 ISA slots (Ref: Super P6DNH). It is not very common to use this sort of motherboard, I though it might be a bit tricky for FBSD to handle it. I then took another PC (Pentium Pro) with a more classical motherboard, I put inside the HD I was using with the SuperMicro motherboard. This way I kept exactly the same code. I specified in the BIOS the IRQ which was used by my dvbtx interface. I boot up the station and guess what, it works just fine! I can stream video between A and C routed by B at several Mbps without a single packet loss. Is there anybody who can give an explanation to this ? I also took another P6DNH motherboard with the same result (losses). I also tried this code successfully on other different motherboards... Emmanuel. Julian Elischer wrote: > which is the isa bus interface? > > > > > Julian Elischer wrote: > > > > >> Emmanuel Duros wrote: > > >> > > >> My fbsd (2.2.2 release) router has two communication interfaces and when > > >> it routes packets between its interfaces, it looses lots of packets ! > > >> > > >> Here is the network configuration: > > >> > > >> --- --------- --- > > >> |A| | B | |C| > > >> --- --------- --- > > >> | (b1) | | (b2) | > > >> -------------------------- -------------------------- > > >> > > >> b1 is an Ethernet interface, b2 is a dvb interface, it is a satellite > > >> communication card (a send-only interface). I wrote the device > > >> driver for the latter. > > >> > > >> I have used a video conferencing application to verify the communication > > >> between the stations: > > >> > > >> 1) A generates a video stream to B up to several Mbps: NO LOSSES > > >> 2) B generates a video stream to C up to several Mbps: NO LOSSES > > >> 3) A generates a video stream to C at 100-200 kbps and I get 5 to > > >> 30 % loss rate > > >> > > >> 1) ensures that the connectivity between A and B is fine > > >> 2) ensures that the connectivity between B and C is fine > > >> 3) shows that there is a routing pb !!! > > >> ... > > > > > > > > >An ISA bus can only really support 1 ethernet and still leave > > >any CPU time for other actions. > > > > > >can you stream video from B tpo A and C at the same time? > > >how about from A and C to B at the same time.? > > > > When I currently stream video from B to C and from A to B: > > > > - No losses on C (whatever bit rate up to several Mbps) > > - High loss rate on B > > > > Looking at what goes through the interface b1 shows errors. > > > > $ netstat -I de0 -w 1 > > > > input (de0) output > > packets errs bytes packets errs bytes colls > > 46 3 32003 0 0 222 0 > > 40 2 25126 0 0 398 0 > > .... > > > > When I stop streaming video from B to C, there is no more errors and I > > can increase the bit rate from A up to several Mbps without loss (!!!). > > > > When I currently stream video from B to C and from B to A, everything is > > fine in spite of the fact that the PC is relatively overloaded! > > > > b2 is an interface (on ISA with DMA transfers) which generates an > > interrupt as it is ready to send more paquets. I thought it could have > > been a pb with the interrupt generated by de0 as it receives a packet > > but according to dmesg (see below) there is no conflict. > > > > Still trying to sort this out! > > > > Emmanuel > > > > >> Beside this, it is not the first time I have used this network > > >> configuration, it used to work very well on another a fbsd router > > >> running a one year old snapshot. > > >> > > >> I have got absolutely no idea where my pb comes from, I have checked > > >> IRQs, probable overlapping ports and everything looks fine to me. I do > > >> not think it comes from my driver because of 2) and because it used to > > >> work very well before I changed the PC and the fbsd OS version. > > >> > > >> I join the output of the dmesg in case this can help... > > >> Thanks a lot for any help! > > >> > > >> Emmanuel > > >> > > >> PS: For information the send-only interface (dvtx0) has an ISA bus and > > >> performs DMA transfers > > >> > > >> ------- > > >> Copyright (c) 1992-1997 FreeBSD Inc. > > >> Copyright (c) 1982, 1986, 1989, 1991, 1993 > > >> The Regents of the University of California. All rights reserved. > > >> > > >> FreeBSD 2.2.2-RELEASE #5: Wed Nov 19 21:10:31 GMT 1997 > > >> eduros@pacman.inria.fr:/usr/src/sys/compile/PACMAN_TX > > >> CPU: Pentium Pro (199.43-MHz 686-class CPU) > > >> Origin = "GenuineIntel" Id = 0x619 Stepping=9 > > >> Features=0xfbff>,MTRR,PGE,MCA,CMOV>> > > >> real memory = 67108864 (65536K bytes) > > >> avail memory = 62619648 (61152K bytes) > > >> Probing for devices on PCI bus 0: > > >> chip0 > rev 2 on pci0:0 > > >> chip1 > rev 1 on pci0:7:0 > > >> chip2 > rev 0 on pci0:7:1 > > >> vga0 > rev 1 int a irq 10 on pci0:17 > > >> de0 > rev 17 int a irq 15 on pci0:18 > > >> de0: 21041 [10Mb/s] pass 1.1 > > >> de0: address 00:00:c0:6b:ea:df > > >> chip3 > rev 1 on pci0:20:0 > > >> pci0:20:1: Intel Corporation, device=0x1960, class=memory (misc) int a irq 9 [no driver assigned] > > >> Probing for devices on PCI bus 1: > > >> ahc0 > rev 0 int a irq 10 on pci1:1 > > >> ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs > > >> ahc0 waiting for scsi devices to settle > > >> (ahc0:0:0): "CONNER CFP2107W 2.14GB 1524" type 0 fixed SCSI 2 > > >> sd0(ahc0:0:0): Direct-Access 2048MB (4194304 512 byte sectors) > > >> Probing for devices on the ISA bus: > > >> sc0 at 0x60-0x6f irq 1 on motherboard > > >> sc0: VGA color <16 virtual consoles, flags=0x0>> > > >> 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: NEC 72065B > > >> fd0: 1.44MB 3.5in > > >> wdc0 at 0x1f0-0x1f7 irq 14 on isa > > >> wdc0: unit 0 (atapi): >, removable, ovlap, dma, iordis > > >> wcd0: 2066Kb/sec, 128Kb cache, audio play, 256 volume levels, ejectable tray > > >> wcd0: no disc inside, unlocked > > >> dvtx0: 0.9b1 version - Probing... > > >> dvtx0 at 0x310 irq 11 drq 5 on isa > > >> npx0 on motherboard > > >> npx0: INT 16 interface > > >> ccd0-3: Concatenated disk drivers > > >> de0: enabling 10baseT port > From owner-freebsd-hackers Mon Nov 24 00:44:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA16825 for hackers-outgoing; Mon, 24 Nov 1997 00:44:16 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from lily.ezo.net (root@lily.ezo.net [206.102.130.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA16815 for ; Mon, 24 Nov 1997 00:44:11 -0800 (PST) (envelope-from jflowers@ezo.net) Received: from lily.ezo.net (jflowers@localhost.ezo.net [127.0.0.1]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id DAA03019 for ; Mon, 24 Nov 1997 03:43:09 -0500 (EST) Date: Mon, 24 Nov 1997 03:43:09 -0500 (EST) From: Jim Flowers To: freebsd-hackers@freebsd.org Subject: inet_addr function? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am tyring to debug a C program that uses functions named inet_ntoa and inet_addr. I found inet_ntoa ok but there does not seem to be an inet_addr, anywhere. It's purpose is to convert a dotted quad (###.###.###.###) Internet address into an unsigned long. I suppose if worse comes to worse I could just write it but the context looks as if it is supposed to be an OS function that I should just be able to get in a .h file somewhere. Any help? ; Thanks. Jim Flowers #4 ISP on C|NET, #1 in Ohio From owner-freebsd-hackers Mon Nov 24 00:50:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA17422 for hackers-outgoing; Mon, 24 Nov 1997 00:50:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA17410 for ; Mon, 24 Nov 1997 00:50:39 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA02658; Mon, 24 Nov 1997 09:50:38 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id JAA03245; Mon, 24 Nov 1997 09:30:09 +0100 (MET) Message-ID: <19971124093009.OQ45903@uriah.heep.sax.de> Date: Mon, 24 Nov 1997 09:30:09 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Cc: bsampley@bsampley.vip.best.com (Burton Sampley) Subject: Re: problem mounting /cdrom w/ 2.2.5-R (fwd) References: <19971124084750.LV48775@uriah.heep.sax.de> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Burton Sampley on Nov 24, 1997 00:05:33 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Burton Sampley wrote: > Actually, if I force it with either mount_cd9660 /dev/cd0a or mount -t > cd9660 /dev/cd0a it *always* works. That's really weird, since the other mount commands don't do anything else: uriah # ktrace -i mount /cdrom uriah # kdump | grep -E 'NAMI|exec' 3230 ktrace NAMI "/etc/malloc.conf" 3230 ktrace CALL execve(0xefbfd330,0xefbfd7f4,0xefbfd800) 3230 ktrace NAMI "/sbin/mount" 3230 mount RET execve 0 3230 mount NAMI "/etc/fstab" 3230 mount NAMI "/etc/malloc.conf" 3230 mount NAMI "." 3230 mount NAMI "/" 3230 mount NAMI "cdrom" 3230 mount NAMI "cdrom" 3230 mount NAMI "/cdrom" 3231 mount CALL execve(0xefbfd09c,0xefbfd600,0xefbfd808) 3231 mount NAMI "/sbin/mount_cd9660" 3231 mount_cd9660 RET execve 0 3231 mount_cd9660 NAMI "/etc/malloc.conf" 3231 mount_cd9660 NAMI "/dev/cd0a" 3231 mount_cd9660 NAMI "/cdrom" 3231 mount_cd9660 NAMI "/dev/cd0a" 3230 mount NAMI "/var/run/mountd.pid" As you can see, `mount' has subsequently called `mount_cd9660', to do the dirty work of mounting a cd9660 filesystem it doesn't know anything about. The trace also shows that the generic mount command doesn't touch /dev/cd0a at all. > I assumed the media not present erorr was just the cdrom > complaining about being booted w/o a cd. Nope. If you've got `noauto' in your fstab, the CD won't be touched at boot time after the device probe happened (which was earlier). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Nov 24 02:10:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA21855 for hackers-outgoing; Mon, 24 Nov 1997 02:10:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA21850 for ; Mon, 24 Nov 1997 02:10:20 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id CAA28632; Mon, 24 Nov 1997 02:01:46 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd028629; Mon Nov 24 02:01:38 1997 Date: Mon, 24 Nov 1997 01:59:28 -0800 (PST) From: Julian Elischer To: Joerg Wunsch cc: hackers@freebsd.org, Burton Sampley Subject: Re: problem mounting /cdrom w/ 2.2.5-R (fwd) In-Reply-To: <19971124093009.OQ45903@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk mount /cdrom uses the read-only flag becasue it's in the fstab. I'm not convinced that mount_cd9660 sets it by default. (not seen the code, but that might be the kind of difference that may be happenning.....) On Mon, 24 Nov 1997, J Wunsch wrote: > As Burton Sampley wrote: > > > Actually, if I force it with either mount_cd9660 /dev/cd0a or mount -t > > cd9660 /dev/cd0a it *always* works. > > That's really weird, since the other mount commands don't do anything > else: > > uriah # ktrace -i mount /cdrom > uriah # kdump | grep -E 'NAMI|exec' > 3230 ktrace NAMI "/etc/malloc.conf" > 3230 ktrace CALL execve(0xefbfd330,0xefbfd7f4,0xefbfd800) > 3230 ktrace NAMI "/sbin/mount" > 3230 mount RET execve 0 > 3230 mount NAMI "/etc/fstab" > 3230 mount NAMI "/etc/malloc.conf" > 3230 mount NAMI "." > 3230 mount NAMI "/" > 3230 mount NAMI "cdrom" > 3230 mount NAMI "cdrom" > 3230 mount NAMI "/cdrom" > 3231 mount CALL execve(0xefbfd09c,0xefbfd600,0xefbfd808) > 3231 mount NAMI "/sbin/mount_cd9660" > 3231 mount_cd9660 RET execve 0 > 3231 mount_cd9660 NAMI "/etc/malloc.conf" > 3231 mount_cd9660 NAMI "/dev/cd0a" > 3231 mount_cd9660 NAMI "/cdrom" > 3231 mount_cd9660 NAMI "/dev/cd0a" > 3230 mount NAMI "/var/run/mountd.pid" > > As you can see, `mount' has subsequently called `mount_cd9660', to do > the dirty work of mounting a cd9660 filesystem it doesn't know > anything about. The trace also shows that the generic mount command > doesn't touch /dev/cd0a at all. > > > I assumed the media not present erorr was just the cdrom > > complaining about being booted w/o a cd. > > Nope. If you've got `noauto' in your fstab, the CD won't be touched > at boot time after the device probe happened (which was earlier). > > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) > From owner-freebsd-hackers Mon Nov 24 02:22:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA22406 for hackers-outgoing; Mon, 24 Nov 1997 02:22:03 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id CAA22399 for ; Mon, 24 Nov 1997 02:21:57 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA03795; Mon, 24 Nov 1997 11:20:58 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id LAA05898; Mon, 24 Nov 1997 11:04:07 +0100 (MET) Message-ID: <19971124110407.36661@uriah.heep.sax.de> Date: Mon, 24 Nov 1997 11:04:07 +0100 From: J Wunsch To: freebsd-hackers@FreeBSD.ORG Cc: Jim Flowers Subject: Re: inet_addr function? Reply-To: Joerg Wunsch References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Jim Flowers on Mon, Nov 24, 1997 at 03:43:09AM -0500 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Jim Flowers wrote: > I am tyring to debug a C program that uses functions named inet_ntoa > and inet_addr. I found inet_ntoa ok but there does not seem to be an > inet_addr, anywhere. Then you probably need some glasses to look. :) Either the declaration as well as the implementation are fine in place, in the .h files mentioned in the manual page: j@uriah 66% nm /usr/lib/libc.so.3.0 | fgrep inet_addr 00042640 T _inet_addr j@uriah 67% fgrep inet_addr /usr/include/arpa/inet.h unsigned long inet_addr __P((const char *)); -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Nov 24 06:11:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA04776 for hackers-outgoing; Mon, 24 Nov 1997 06:11:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from vinyl.quickweb.com (vinyl.quickweb.com [209.112.4.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA04761 for ; Mon, 24 Nov 1997 06:10:55 -0800 (PST) (envelope-from mark@quickweb.com) Received: (from mark@localhost) by vinyl.quickweb.com (8.8.7/8.6.12) id JAA06859; Mon, 24 Nov 1997 09:12:06 -0500 (EST) Message-ID: <19971124091206.61860@vmunix.com> Date: Mon, 24 Nov 1997 09:12:06 -0500 From: Mark Mayo To: Burton Sampley Cc: Joerg Wunsch , hackers@freebsd.org Subject: Re: problem mounting /cdrom w/ 2.2.5-R (fwd) References: <19971124084750.LV48775@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: ; from Burton Sampley on Mon, Nov 24, 1997 at 12:05:33AM -0800 X-Operating-System: FreeBSD 2.2.5-STABLE i386 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, Nov 24, 1997 at 12:05:33AM -0800, Burton Sampley wrote: > Joerg, > > Actually, if I force it with either mount_cd9660 /dev/cd0a or mount -t > cd9660 /dev/cd0a it *always* works. If I mount it explicitly and then > umount the drive, then try it again w/ mount /cdrom it still fails. I've > tried repeating mount /cdrom numerous times in a row, but it still refuses > to mount the cdrom using that method. You know, I have a machine which exhibits similar behaviour. I ended up changing /dev/cd0a to /dev/cd0c in the fstab and then everything worked fine and it's been happy ever since. I have no idea if 'a' or 'c' is the correct usage, but 'c' seems to work for me. I also had weird things happening when I mounted cd0a, like being able to see directory listings, but any attempt to use the file would get me a "file not found" error. Fun! -Mark > I'll try again tomorrow and post my > results (the machine's at work, I'm a home, I forgot to leave a cd in the > drive). I assumed the media not present erorr was just the cdrom > complaining about being booted w/o a cd. > > - burton - > > On Mon, 24 Nov 1997, J Wunsch wrote: > > > As Burton Sampley wrote: > > > > > I just completed a new install of 2.2.5-R on to a 'virgin' HD at work. > > > I'm having a strange problem I don't understand. If I try to mount a > > > cdrom with mount /cdrom (as root) I get the following error: > > > > > > root@thingie(101)# mount /cdrom > > > cd9660: /dev/cd0a: Device not configured > > > > This corresponds to: > > > > > npx0 flags 0x1 on motherboard > > > npx0: INT 16 interface > > > changing root device to sd0a > > > cd0(ahc0:3:0): NOT READY asc:3a,0 Medium not present > > > cd0(ahc0:3:0): NOT READY asc:3a,0 Medium not present > > > > ...these medium not present messages. Somehow, your drive seems to > > think twice about whether it's actually got a medium or not. The way > > you invoke the mount command is irrelevant, but those messages are the > > indication of the evil that's going on. Apparently, the drive finally > > makes up its mind if you ask it often enough (which incidentally > > happened to be an explicit call to mount_cd9660). > > > > -- > > cheers, J"org > > > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > > Never trust an operating system you don't have sources for. ;-) > > > > --------------- > > Burton Sampley > bsampley@best.com or bsampley@haywire.csuhayward.edu > PGP key available at http://www.best.com/~bsampley/pgp.html > -- ------------------------------------------------------------------------ Mark Mayo mark@vmunix.com RingZero Comp. http://www.vmunix.com/mark finger mark@vmunix.com for my PGP key and GCS code ------------------------------------------------------------------------ Win95/NT - 32 bit extensions and a graphical shell for a 16 bit patch to an an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition. -UGU From owner-freebsd-hackers Mon Nov 24 11:06:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA24952 for hackers-outgoing; Mon, 24 Nov 1997 11:06:52 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from usr01.primenet.com (tlambert@usr01.primenet.com [206.165.6.201]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA24942 for ; Mon, 24 Nov 1997 11:06:47 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id MAA14773; Mon, 24 Nov 1997 12:06:37 -0700 (MST) From: Terry Lambert Message-Id: <199711241906.MAA14773@usr01.primenet.com> Subject: Re: Status of 650 UART support To: mouth@ibm.net (John Kelly) Date: Mon, 24 Nov 1997 19:06:36 +0000 (GMT) Cc: bde@zeta.org.au, hackers@freebsd.org In-Reply-To: <347901e5.3980414@smtp-gw01.ny.us.ibm.net> from "John Kelly" at Nov 24, 97 05:48:49 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >/* > > * Loop until there is no activity on any port. This is necessary > > * to get an interrupt edge more than to avoid another interrupt. > > * If the IRQ signal is just an OR of the IRQ signals from several > > * devices, then the edge from one may be lost because another is > > * on. > > */ > > I believe this is untrue. If so, that may call certain aspects of > siointr into question. > > On an ISA bus, several devices cannot OR their IRQ lines at all, > unless you are willing to heat up a soldering iron, or purchase a > multiport card with hardware logic for IRQ sharing. Otherwise, the > totem pole output of any one device holding its line low will sink the > output of all others to ground and you will never see an interrupt > from any of the ORed devices. I think this is specifically for the 4 port "Comtrol Hostess" boards. > Incidentally, there is some code in sioprobe which floats the IRQ > output of all UARTs, attempting to find all which may be "sharing" an > IRQ in the COM1/COM3 manner. I would change that and force users to > set up their COM ports correctly (at least for UNIX). ;-) Actually, it's possible for DOS machines to be perfectly happy in switching interrupt driven input from COM1 (to say a terminal server) to COM3 (to say a modem). UNIX systems should be able to function on the same hardware Windows95 can function on, I think. At the very worst, there should be an open interlock on the devices, but both should remain accessible in the general sense of allowing me to close one to open the other (ie: alternate the interrupt programming based on the open). At best, both devices should be queriable and function simultaneously (as in the loop you question, above). Philosophically, you should buy good hardware. But also philosophically, you should work on the hardware you're given. > Anyway, I want to purse this issue of whether looping in siointr is > "necessary to get an interrupt edge," because it has a direct impact > on how siointr might be improved with UART burst mode input. Is this one of those "take an interrupt, then poll like hell" type drivers? 8-). > I wrote a code fragment in Turbo C which implements a highly optimized > framework (not a finished product) for UART receiver burst mode if you > want to see it. The more code, the merrier. 8-). > It also handles the case of FIFO timeout where you > need to read characters in the usual way, one at a time. I tested it > in a small terminal program and it works well. This is typically handled using a line discipline to drop the FIFO trigger level (ie: for serial mice, etc.). I believe there's also a timeout based trigger for long packet protocols that really need the FIFO to reduce service overhead (ie: for high speed ppp and slip). Are you using a different approach? > I would like to integrate it with sio.c, but I'm never satisfied with > my C code until I've eliminated all goto statements. Extracting the > many from sio.c might take a long time, and I don't know if I'm ready > to jump into that snakepit. Please, don't. The compiler will put the jump instructions back in, anyway, and all you'll have done is increase the code path by one or more tests, slowing the thing down. A goto is a perfectly reasonable way to handle an exception, and it's much easier to find the target of a "goto" than a "break", especially given stylistic differences over placement of squiggly brackets. 8-(. I think Bruce's code is already pretty optimal (FASTINTR is his baby); that's not to say that you shouldn't integrate what you have (maybe you should; I haven't seen it, hence my question marks, above), but be careful. Not all of the reasons for a particular approach are documented (ie: you knew there was a loop, and what it putatively claimed to do, but there wasn't a reason *why* included in the comment, etc.). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Nov 24 11:42:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA27802 for hackers-outgoing; Mon, 24 Nov 1997 11:42:59 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from lab321.ru (anonymous1.omsk.net.ru [194.226.32.34]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA27782 for ; Mon, 24 Nov 1997 11:42:48 -0800 (PST) (envelope-from kev@lab321.ru) Received: from Kev.l321.omsk.net.ru (kev.l321.omsk.net.ru [194.226.33.68]) by lab321.ru (8.8.5-MVC-230497/8.8.5) with ESMTP id BAA04889 for ; Tue, 25 Nov 1997 01:41:34 +0600 (OSK) Received: from lab321.ru (localhost.l321.omsk.net.ru [127.0.0.1]) by Kev.l321.omsk.net.ru (8.8.8/8.8.5) with ESMTP id BAA03412 for ; Tue, 25 Nov 1997 01:42:59 GMT Message-ID: <347A2D21.8BB4368E@lab321.ru> Date: Tue, 25 Nov 1997 01:42:57 +0000 From: Eugeny Kuzakov Reply-To: Eugeny.Kuzakov@lab321.ru Organization: Powered by FreeBSD. X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 3.0-971117-SNAP i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: vrweb for FreeBSD port Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk HI All ! I just installed subj. But it need vrwave. Now I trying ti compile it for FreeBSD. I anyone already done it ? I can make port of vrwave. If anyone interesting this software... -- Best wishes, Eugeny Kuzakov Laboratory 321 ( Omsk, Russia ) kev@lab321.ru From owner-freebsd-hackers Mon Nov 24 12:01:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA29536 for hackers-outgoing; Mon, 24 Nov 1997 12:01:26 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA29526; Mon, 24 Nov 1997 12:01:20 -0800 (PST) (envelope-from bsampley@bsampley.vip.best.com) Received: from bsampley (bsampley.vip.best.com [206.184.160.196]) by proxy4.ba.best.com (8.8.7/8.8.BEST) with SMTP id MAA18587; Mon, 24 Nov 1997 12:00:00 -0800 (PST) Date: Mon, 24 Nov 1997 11:56:30 -0800 (PST) From: Burton Sampley X-Sender: bsampley@bsampley To: Mark Mayo cc: Joerg Wunsch , hackers@freebsd.org, questiosn@freebsd.org Subject: Re: problem mounting /cdrom w/ 2.2.5-R (fwd) In-Reply-To: <19971124091206.61860@vmunix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Thanks you everybody for your help. I think I just figured out the problem. I'm still at home now, but I had another employee load a cdrom in the drive so I could continue to attempt to diagnose the problem. This time mount /cdrom worked perfectly. Here's my assumption: I must have attempted to mount the cdrom too soon after loading the cdrom in the drive. It's an old 4X SCSI Toshiba CDROM drive. Instead of giving me a device not ready error to the console (BTW, I just reviewed /var/log/messages where it DID give a NOT READY error from /kernel) it gave a device not configured error message. I assumed this was a problem w/ 2.2.5-R. My assumption was wrong. I apologize for wasting everybody's time looking for an answer. If I would have just taken an extra minute to review /var/log/messages, there would have been no need to post my original message. Here's my solution: 1. Always review the logs before posting a question! 2. Slow down and be patient with older equipment. FYI: This server was built from 'spare parts' (486DX33, 16 meg) as a development platform for our web server (which also runs FBSD: www.savi.com) Thanks again and I truly apologize. - - burton - - --------------- Burton Sampley bsampley@best.com or bsampley@haywire.csuhayward.edu PGP key available at http://www.best.com/~bsampley/pgp.html -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNHnb9nt2O8KJtMdBAQHFPwP8CvLPyXbuZytDnPtY4w3RB3eXOjIt5poL jJav1KCjAZ7Ct9rjIK57yIzMtzEhXin9F84l3qn0JxKwiRgrzUq3f2BWuuH0AKG+ 8kYKU2jsmay8Usm9sWHOKGf1lC11YfYM8WWtMNNhSCNchoPMZZGTn7WfVHpjexmm Cy/9KPeqK7w= =36R+ -----END PGP SIGNATURE----- From owner-freebsd-hackers Mon Nov 24 12:22:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA01736 for hackers-outgoing; Mon, 24 Nov 1997 12:22:18 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA01730 for ; Mon, 24 Nov 1997 12:22:13 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA20107 (5.67b/IDA-1.5 for freebsd-hackers@FreeBSD.ORG); Mon, 24 Nov 1997 21:22:19 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id VAA02289; Mon, 24 Nov 1997 21:12:09 +0100 (MET) From: Wilko Bulte Message-Id: <199711242012.VAA02289@yedi.iaf.nl> Subject: Re: volume control on SCSI Toshiba CDdrive To: syssgm@dtir.qld.gov.au (Stephen McKay) Date: Mon, 24 Nov 1997 21:12:09 +0100 (MET) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199711240257.MAA20135@ogre.dtir.qld.gov.au> from "Stephen McKay" at Nov 24, 97 12:57:39 pm X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Stephen McKay wrote... > On Friday, 21st November 1997, Wilko Bulte wrote: > > >I just changed my old 4x Toshiba cdrom to a 12x Toshiba. > >To be precise, it is a TOSHIBA CD-ROM XM-5701TA 3136. > > > >The 4x Toshiba audio volume was controllable using the WorkMan 'slide'. > >It seems that the 12x Toshiba does not respond to this. AFAIK > >the volume stuff is part of the SCSI standard these days. > > > >Any comments of fellow XM5701 owners? > > I have the same problem. Everything else works. :-) > > xmcd could control volume on my old NEC 4x, but the new Toshiba ignores it. > It's just about impossible to keep a list of good working hardware. :-( > > Does anyone have an inside contack at Toshiba? Maybe there is a workaround. > If not, at least they will be able to club somebody! I'll try to find out at work. Digital buys a lot of Toshiba drives, so maybe I can get more info on this. Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko @ yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ---------------- Support your local daemons: run [Free,Net]BSD Unix ------ From owner-freebsd-hackers Mon Nov 24 15:29:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA15412 for hackers-outgoing; Mon, 24 Nov 1997 15:29:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from zen.nash.org (nash.pr.mcs.net [204.95.47.72]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA15392 for ; Mon, 24 Nov 1997 15:29:21 -0800 (PST) (envelope-from alex@zen.nash.org) Received: (from alex@localhost) by zen.nash.org (8.8.8/8.8.7) id RAA00644; Mon, 24 Nov 1997 17:25:25 -0600 (CST) (envelope-from alex) Message-Id: <199711242325.RAA00644@zen.nash.org> Date: Mon, 24 Nov 1997 17:25:25 -0600 (CST) From: Alex Nash Reply-To: nash@mcs.com Subject: Re: pthread_cond_timedwait returning wrong error? To: deischen@iworks.InterWorks.org cc: julian@whistle.com, nash@mcs.com, freebsd-hackers@freebsd.org In-Reply-To: <199711240452.WAA24529@iworks.InterWorks.org> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 23 Nov, Daniel M. Eischen wrote: > One last question. The other GNAT targets (Linux, Open/VMS, > RTEMS, etc) all seem to want the errno to be _returned_ by > pthread_cond_timedwait (and a couple of others too). This > seems wrong, -1 should be returned, and the error code should > be retrieved from the thread-safe errno. What does the POSIX > spec say about the return value of pthread_cond_timedwait()? The spec says that the error code is returned from the function directly, and not via errno. Unfortunately our threads library appears to return -1 and set errno instead. Alex From owner-freebsd-hackers Mon Nov 24 15:34:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA15780 for hackers-outgoing; Mon, 24 Nov 1997 15:34:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ultra.ultra.net.au (chaos@ultra.ultra.net.au [203.20.237.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA15765; Mon, 24 Nov 1997 15:33:54 -0800 (PST) (envelope-from chaos@ultra.net.au) Received: from localhost (chaos@localhost) by ultra.ultra.net.au (8.8.8/8.8.8) with SMTP id JAA11255; Tue, 25 Nov 1997 09:34:47 +1000 (EST) Date: Tue, 25 Nov 1997 09:34:47 +1000 (EST) From: Simon Coggins To: freebsd-questions@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Cyrix 6x686 M2 MMX P166+, and kernel panic bug Solved! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Okie since I had no replies from anyone that I didn't have before (Thank you to all those that did reply I tried them all and to no avail). So I decided to get down and dirty and hack the kernel.. Well with the help of the debugger and alittle poking around I found it.. The debugger reported: Stop at identblue+0x31: wrmsr Trace showed: identblue() finishidentcpu() init386() I went into sys/i386/386/identcpu.c and changed the identblue() function to always return 0 (as i know my Chip isn't a blue lighting). My kernel now boots fine and I haven't seen any ill effects from it yet.. the CPU is also detected properly Altho the Speed is alittle slow. But I don't understand how that is calculated so I'll leave it up to the real hackers :) Hope that helps someone.. PS for those fbsd guys if this is any help i also got the cyrixreg values: CCR0=2 CCR1=82 CCR2=80 CCR3=0CR0=80000011 Regards Simon From owner-freebsd-hackers Mon Nov 24 15:35:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA16055 for hackers-outgoing; Mon, 24 Nov 1997 15:35:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from zen.nash.org (nash.pr.mcs.net [204.95.47.72]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA16045 for ; Mon, 24 Nov 1997 15:35:41 -0800 (PST) (envelope-from alex@zen.nash.org) Received: (from alex@localhost) by zen.nash.org (8.8.8/8.8.7) id RAA00666; Mon, 24 Nov 1997 17:33:17 -0600 (CST) (envelope-from alex) Message-Id: <199711242333.RAA00666@zen.nash.org> Date: Mon, 24 Nov 1997 17:33:17 -0600 (CST) From: Alex Nash Reply-To: nash@mcs.com Subject: Re: pthread_cond_timedwait returning wrong error? To: bradley@dunn.org cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 24 Nov, Bradley Dunn wrote: > On Sun, 23 Nov 1997, Julian Elischer wrote: > >> don't forget 2.2.x >> (it has basically the same code) > >> > > Is EAGAIN the correct error for a timeout from a >> > > pthread_cond_timedwait() call? I would think that >> > > ETIMEDOUT would be more appropriate. >> > >> > According to my 1996 edition of ANSI/IEEE std 1003.1, you are correct -- >> > ETIMEDOUT should be returned. I've committed a fix for this into >> > -current. > > While we are talking about threads, any comments on PR-4376? You are 100% right about the return value being incorrect. Unfortunately, this problem is present in many more functions than just pthread_join(). >From what I can tell by looking at an old DEC OSF/1 reference on pthreads, returning -1 an setting errno is the way things used to work. Apparently POSIX has changed that. Alex From owner-freebsd-hackers Mon Nov 24 15:39:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA16333 for hackers-outgoing; Mon, 24 Nov 1997 15:39:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iworks.InterWorks.org (deischen@iworks.interworks.org [128.255.18.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA16328 for ; Mon, 24 Nov 1997 15:39:24 -0800 (PST) (envelope-from deischen@iworks.InterWorks.org) Received: (from deischen@localhost) by iworks.InterWorks.org (8.7.5/) id RAA26968; Mon, 24 Nov 1997 17:41:34 -0600 (CST) Message-Id: <199711242341.RAA26968@iworks.InterWorks.org> Date: Mon, 24 Nov 1997 17:41:34 -0600 (CST) From: "Daniel M. Eischen" To: nash@mcs.com Subject: Re: pthread_cond_timedwait returning wrong error? Cc: freebsd-hackers@freebsd.org, julian@whistle.com Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > What does the POSIX spec say about the return value of > > pthread_cond_timedwait()? > > The spec says that the error code is returned from the function > directly, and not via errno. Unfortunately our threads library > appears to return -1 and set errno instead. > > Alex Shall I send a PR against our threads library? Or do we care that our threads library isn't totally POSIX compliant? Dan Eischen deischen@iworks.InterWorks.org From owner-freebsd-hackers Mon Nov 24 16:00:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA17709 for hackers-outgoing; Mon, 24 Nov 1997 16:00:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from zen.nash.org (nash.pr.mcs.net [204.95.47.72]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA17703 for ; Mon, 24 Nov 1997 16:00:17 -0800 (PST) (envelope-from alex@zen.nash.org) Received: (from alex@localhost) by zen.nash.org (8.8.8/8.8.7) id RAA00771; Mon, 24 Nov 1997 17:59:13 -0600 (CST) (envelope-from alex) Message-Id: <199711242359.RAA00771@zen.nash.org> Date: Mon, 24 Nov 1997 17:59:13 -0600 (CST) From: Alex Nash Reply-To: nash@mcs.com Subject: Re: pthread_cond_timedwait returning wrong error? To: deischen@iworks.InterWorks.org cc: nash@mcs.com, freebsd-hackers@freebsd.org, julian@whistle.com In-Reply-To: <199711242341.RAA26968@iworks.InterWorks.org> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 24 Nov, Daniel M. Eischen wrote: >> > What does the POSIX spec say about the return value of >> > pthread_cond_timedwait()? >> >> The spec says that the error code is returned from the function >> directly, and not via errno. Unfortunately our threads library >> appears to return -1 and set errno instead. >> >> Alex > > Shall I send a PR against our threads library? Or do we > care that our threads library isn't totally POSIX compliant? I'm going to try and clean up the return values the next chance I get (which is probably this weekend). Feel free to submit a PR if you wish, but I wouldn't bother including diffs -- it'll be as much work to verify the diffs as to actually do the work :) Alex From owner-freebsd-hackers Mon Nov 24 16:09:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA18291 for hackers-outgoing; Mon, 24 Nov 1997 16:09:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA18281; Mon, 24 Nov 1997 16:09:42 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (tc-if3-24.ida.net [208.141.171.129]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id RAA03942; Mon, 24 Nov 1997 17:09:33 -0700 Date: Mon, 24 Nov 1997 17:08:56 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: Simon Coggins cc: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Cyrix 6x686 M2 MMX P166+, and kernel panic bug Solved! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 25 Nov 1997, Simon Coggins wrote: > > Okie since I had no replies from anyone that I didn't have before (Thank you > to all those that did reply I tried them all and to no avail). > > So I decided to get down and dirty and hack the kernel.. Well with the help > of the debugger and alittle poking around I found it.. Just curious... How did you specifically use a debugger with the kernel? Are there any references for doing this? -- Charles Mott P.S. It looks like you did a really good bit of detective work here. > > The debugger reported: > > Stop at identblue+0x31: wrmsr > > Trace showed: > identblue() > finishidentcpu() > init386() > From owner-freebsd-hackers Mon Nov 24 16:10:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA18448 for hackers-outgoing; Mon, 24 Nov 1997 16:10:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA18429; Mon, 24 Nov 1997 16:10:36 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id QAA19224; Mon, 24 Nov 1997 16:05:12 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd019221; Mon Nov 24 16:05:05 1997 Message-ID: <347A15AE.4487EB71@whistle.com> Date: Mon, 24 Nov 1997 16:02:55 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@freebsd.org CC: peter@freebsd.org Subject: BIND 8.1.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is anyone working to actually pull the new BIND into the default freeBSD tree? I'm working with it here and am wondering if it wouldn't be the best thing to 'import' it into the FreeBSD tree, rather than doing it all 'privatly'. Has there been a discussion about bind 8? My presumption is that everyone agrees that we'll move to it 'eventually'. does anyone have ideas as to when 'eventually' is? Has anyone looked ato how much work it is to actually merge in the new libc stuff? julian From owner-freebsd-hackers Mon Nov 24 17:15:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA22414 for hackers-outgoing; Mon, 24 Nov 1997 17:15:26 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from zeus.carroll.com (zeus.carroll.com [199.224.10.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA22407 for ; Mon, 24 Nov 1997 17:15:22 -0800 (PST) (envelope-from jim@carroll.com) Received: from apollo.carroll.com [199.224.10.3] by zeus.carroll.com with ESMTP (8.8.5/0) id UAA14124; Mon, 24 Nov 1997 20:15:17 -0500 Received: by apollo.carroll.com (8.8.5) is UAA10346; Mon, 24 Nov 1997 20:15:16 -0500 Date: Mon, 24 Nov 1997 20:15:15 -0500 From: Jim Carroll To: freebsd-hackers@freebsd.org Subject: Retrieve ethernet mac address Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Could someone point me towards how to retrieve an ethernet mac address from user-land code ? If it matters, we are running 2.2.1 If someone has a working snippet, I would be grateful. A good pointer towards a FAQ or doc would also be helpful. I have been staring at netstat and ifconfig source for a few hours, but am having trouble making heads or tails. netstat usese kvm() and ifconfig uses sysctl(). I can't find enough docs of either method to get my head around what is needed to just extract mac address. Thanks --- Jim C., President | C A R R O L L - N E T, Inc. 201-488-1332 | New Jersey's Premier Internet Service Provider www.carroll.com | From owner-freebsd-hackers Mon Nov 24 17:30:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA23439 for hackers-outgoing; Mon, 24 Nov 1997 17:30:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA23389; Mon, 24 Nov 1997 17:30:38 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id SAA26213; Mon, 24 Nov 1997 18:30:33 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id SAA24765; Mon, 24 Nov 1997 18:30:30 -0700 Date: Mon, 24 Nov 1997 18:30:30 -0700 Message-Id: <199711250130.SAA24765@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: hackers@freebsd.org, peter@freebsd.org Subject: Re: BIND 8.1.1 In-Reply-To: <347A15AE.4487EB71@whistle.com> References: <347A15AE.4487EB71@whistle.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > My presumption is that everyone agrees that we'll move to it > 'eventually'. does anyone have ideas as to when 'eventually' is? I thought the advice from Paul was to 'wait awhile' and integrate when everything got finished up, which means 'wait awhile' to me. :) Nate From owner-freebsd-hackers Mon Nov 24 18:15:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA27440 for hackers-outgoing; Mon, 24 Nov 1997 18:15:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA27416 for ; Mon, 24 Nov 1997 18:15:22 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-195-86.nc.us.ibm.net (slip129-37-195-86.nc.us.ibm.net [129.37.195.86]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id CAA117334; Tue, 25 Nov 1997 02:15:05 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans Cc: hackers@freebsd.org Subject: Re: Status of 650 UART support Date: Tue, 25 Nov 1997 03:16:08 GMT Message-ID: <347d42b4.7857680@smtp-gw01.ny.us.ibm.net> References: <199711240628.RAA01234@godzilla.zeta.org.au> In-Reply-To: <199711240628.RAA01234@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id SAA27434 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 24 Nov 1997 17:28:47 +1100, Bruce Evans wrote: >simplest approach leads to 3 i/o's per byte of input instead of 2 >(IIR, LSR, RXDATA) instrad of (LSR, RXDATA). Not in my code. I can read the IIR once, and if checking the LSR reveals no errors, and the IIR indicates a FIFO interrupt (as opposed to FIFO timeout), I have a FIFO of bytes, full at least to the trigger level I previously set in the FCR, and I can safely read them all with one in-line assembler REP INSB instruction emitted by Turbo C (can GCC do that?). I've implemented a circular buffer which lets me write the burst into one contiguous area even in the case where it extends beyond the "virtual" end. With a 650 UART set for a FIFO trigger level of 24 bytes, I only add two INB's of overhead to a burst of 24 bytes. That's a worthwhile improvement. >>I changed my own copy of sioprobe to drive the IRQ output, letting >>each UART pull its line to ground during sioprobe. >You mean all at the start? It's not very nice to drive sio1-N in >the probe for sio0. Why not? That is exactly what you want to do if you have several inputs feeding an OR gate. You never want an OR gate input floating. True, If a user has the classic COM1/COM3 conflict neither one will probe correctly. But that's the way it should be. >>Anyway, I want to purse this issue of whether looping in siointr is >>"necessary to get an interrupt edge," because it has a direct impact >>on how siointr might be improved with UART burst mode input. > >It's certainly necessary for simple OR gates. The IRQ outputs of the >UARTs are independent True. > so there is no guarantee that a falling edge on one will make it to the > output of the OR gate. After building and testing such a device myself, I still don't understand what you're driving at here. Of what consequence is a falling edge on any of the UART INT outputs? The PIC which ultimately receives the electrical signal as output from the OR gate has no care for falling edges, only rising ones. >The code being discussed is for multiport cards >with (simple) hardware logic for IRQ sharing. Not-so-simple hardware >might have a way to force an edge, but siointr() is for the general >case so it can't have support for or dependencies on this. I don't understand this either. In the case of an OR gate which implements, as you say, "(simple) hardware logic for IRQ sharing," why is there a need to "force an edge" at all? The OR gate is simply going to alternate its output between +5v when any input is true, and ground when all inputs are false. When it changes its output from ground to +5v, the PIC sees the rising edge and recognizes an interrupt. The OR gate acts as a buffer between the independent UART INT outputs and the input of the PIC. It seems so simple to me. What am I missing? >>I wrote a code fragment ... if you want to see it. >Not really. I think I know what to do, butnot how to integrate it. As you wish. If I find some time to hack mine, I hope you won't mind more questions about sio.c. >>I'm never satisfied with my C code until I've eliminated all goto >> statements. > >There's only 3 in the standard version and they're just to get out >of error cases :-) I counted 16 in the -current version. John From owner-freebsd-hackers Mon Nov 24 18:15:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA27493 for hackers-outgoing; Mon, 24 Nov 1997 18:15:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA27486 for ; Mon, 24 Nov 1997 18:15:51 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-195-86.nc.us.ibm.net (slip129-37-195-86.nc.us.ibm.net [129.37.195.86]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id CAA40144; Tue, 25 Nov 1997 02:15:14 GMT From: mouth@ibm.net (John Kelly) To: Terry Lambert Cc: hackers@FreeBSD.ORG Subject: Re: Status of 650 UART support Date: Tue, 25 Nov 1997 03:16:18 GMT Message-ID: <347b37fe.5114506@smtp-gw01.ny.us.ibm.net> References: <199711241906.MAA14773@usr01.primenet.com> In-Reply-To: <199711241906.MAA14773@usr01.primenet.com> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id SAA27489 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 24 Nov 1997 19:06:36 +0000 (GMT), Terry Lambert wrote: >Actually, it's possible for DOS machines to be perfectly happy in >switching interrupt driven input from COM1 (to say a terminal server) >to COM3 (to say a modem). Single tasking DOS will do one or the other, but not both during the same period of time. >both should remain accessible in the general sense of allowing me >to close one to open the other (ie: alternate the interrupt programming >based on the open). That might be nice for a casual user, but for the type of FreeBSD use prevalent, I don't think it has much value, and I would whack it. >Philosophically, you should buy good hardware. But also philosophically, >you should work on the hardware you're given. I've probably thrown out more hardware than I've kept. Maybe that's why I'm so poor. >> I wrote a code fragment in Turbo C which implements a highly optimized >> framework (not a finished product) for UART receiver burst mode >Is this one of those "take an interrupt, then poll like hell" type >drivers? 8-). Not exactly. Take an interrupt, check the IIR and LSR, and if no errors in your FIFO, execute one assembler REP INSB instruction to empty it. It can't be any tighter. >> if you want to see it. >The more code, the merrier. 8-). Bruce said he wasn't particularly interested, but I'm willing to share my idea with anyone who is. >>I've eliminated all goto statements. >The compiler will put the jump instructions back in, anyway >and all you'll have done is increase the code path by one or > more tests, slowing the thing down. I know the compiler emits jumps but that's beside the point. Relentlessly eliminating all goto statements forces me to analyze the problem to a greater depth, and consistently produces code which is easier to read and comprehend. By organizing well, you won't have many extra tests, and the clock cycles of those few will be insignificant. The new goto-less code is usually so much more efficient and well organized that a few extra test clock cycles are mere drops in a sea of improvement. John From owner-freebsd-hackers Mon Nov 24 18:18:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA28475 for hackers-outgoing; Mon, 24 Nov 1997 18:18:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from send1b.yahoomail.com (send1b.yahoomail.com [205.180.60.23]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA28467 for ; Mon, 24 Nov 1997 18:18:17 -0800 (PST) (envelope-from rgireyev@yahoo.com) Message-ID: <19971125021806.22306.rocketmail@send1b.yahoomail.com> Received: from [156.153.255.234] by send1b; Mon, 24 Nov 1997 18:18:06 PST Date: Mon, 24 Nov 1997 18:18:06 -0800 (PST) From: Rudy Gireyev Subject: LS120 driver To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Howdy ya'll! A big log fell on my head the other day and right after that I thought hey, why don't I write a device driver for the LS120 drive(s) for FreeBSD. These beasts are backwards compatible all the way to the very useful 720K capacity, 1.44 Meg and of course the 120Meg, the latter requiring a new disk type. As I thought about this more, and the damage appeared to set in, I came up with some questions which I now present for your review: 1. Am I totally crazy? (Optional reply) 2. Is someone already working on such an animal? 3. This will be my first device driver, and I'm sure noone knows who I am, so it may be an improper thing for me to do at this time, so I guess this is an opportunity for a core like team member to jump in and say "Hey BUB layoff!" 4. Currently there are three types of those drives, Internal IDE, External-parallel and PCMCIA one. Which one would be best to start with. Since I can only afford one and the internal one is the cheapest I'm leaning there. The drivers I imagine will be very similar to IOMEGA Zip/Jaz drives. So if anyone is intimately (or reasonably) familiar with those DDs jump in on this answer. 5. Is the Device driver for the internal Zip drive bootable? External-parallel? External-PCMCIA? 6. I guess If all this shakes down, then I'll have to go to Imation, apparently the principal player, and ask for specifications. If anyone has horror stories or how to approach this diplomatically or even which department usually takes care of that kinda stuff, please let me know. Offline is fine. For list only repliers, hi J'org :-), I'm currently not subscribed to -hackers, so shoot 'em my way, please, as gently as possible. Thanks a lot for any and all help. Your humble scholar, Rudy. __________________________________________________________________ Sent by Yahoo! Mail. Get your free e-mail at http://mail.yahoo.com From owner-freebsd-hackers Mon Nov 24 18:29:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA29450 for hackers-outgoing; Mon, 24 Nov 1997 18:29:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from thor.inlink.com (ultra.inlink.com [206.196.96.100]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA29439 for ; Mon, 24 Nov 1997 18:29:38 -0800 (PST) (envelope-from rcdii@thor.inlink.com) Received: from shell.inlink.com. (rcdii@shell1.inlink.com [206.196.96.60]) by thor.inlink.com (8.8.7/V8) with SMTP id UAA14676 for ; Mon, 24 Nov 1997 20:29:10 -0600 (CST) Received: by shell.inlink.com. (SMI-8.6/SMI-SVR4) id UAA16064; Mon, 24 Nov 1997 20:28:55 -0600 Date: Mon, 24 Nov 1997 20:28:55 -0600 From: rcdii@thor.inlink.com (Robert Dunn) Message-Id: <199711250228.UAA16064@shell.inlink.com.> Content-Type: text Apparently-To: hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk unsuscribe From owner-freebsd-hackers Mon Nov 24 18:30:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA29580 for hackers-outgoing; Mon, 24 Nov 1997 18:30:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from thor.inlink.com (ultra.inlink.com [206.196.96.100]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA29575 for ; Mon, 24 Nov 1997 18:30:48 -0800 (PST) (envelope-from rcdii@thor.inlink.com) Received: from shell.inlink.com. (rcdii@shell1.inlink.com [206.196.96.60]) by thor.inlink.com (8.8.7/V8) with SMTP id UAA14996 for ; Mon, 24 Nov 1997 20:30:19 -0600 (CST) Received: by shell.inlink.com. (SMI-8.6/SMI-SVR4) id UAA16093; Mon, 24 Nov 1997 20:30:04 -0600 Date: Mon, 24 Nov 1997 20:30:04 -0600 From: rcdii@thor.inlink.com (Robert Dunn) Message-Id: <199711250230.UAA16093@shell.inlink.com.> Content-Type: text Apparently-To: hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk sorry, unsubscribe From owner-freebsd-hackers Mon Nov 24 19:20:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA03332 for hackers-outgoing; Mon, 24 Nov 1997 19:20:45 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA03322 for ; Mon, 24 Nov 1997 19:20:38 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id TAA25096; Mon, 24 Nov 1997 19:20:11 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd025094; Mon Nov 24 19:20:09 1997 Message-ID: <347A4367.6201DD56@whistle.com> Date: Mon, 24 Nov 1997 19:17:59 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Jim Carroll CC: freebsd-hackers@FreeBSD.ORG Subject: Re: Retrieve ethernet mac address References: Content-Type: multipart/mixed; boundary="------------63DECDAD62319AC452BFA1D7" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. --------------63DECDAD62319AC452BFA1D7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The following snippet dumps ALL the addresses of all the interfaces. the LINK address contains the MAC address in there. you'll have to dig it out.. Jim Carroll wrote: > > Could someone point me towards how to retrieve an ethernet mac address from > user-land code ? If it matters, we are running 2.2.1 > > If someone has a working snippet, I would be grateful. A good pointer > towards a FAQ or doc would also be helpful. > > I have been staring at netstat and ifconfig source for a few hours, but am > having trouble making heads or tails. netstat usese kvm() and ifconfig uses > sysctl(). I can't find enough docs of either method to get my head around > what is needed to just extract mac address. > > Thanks > > --- > Jim C., President | C A R R O L L - N E T, Inc. > 201-488-1332 | New Jersey's Premier Internet Service Provider > www.carroll.com | --------------63DECDAD62319AC452BFA1D7 Content-Type: text/plain; charset=us-ascii; name="dumpifs.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dumpifs.c" #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include void showbytes(unsigned char *cptr,int len) { int i,j; for (j = 0 ;len > 0 ;j++) { for ( i = 0; i < 16; i++) { printf("0x%x ",*cptr++); if (--len == 0) break; } printf("\n"); } } void print_sa (struct sockaddr *sap) { char buf[128]; printf("len=%d,",sap->sa_len); switch(sap->sa_family) { case AF_LINK: printf(" family=LINK\n"); { char *cptr; struct sockaddr_dl *sdl = (struct sockaddr_dl *)sap; cptr = sdl->sdl_data; printf("index=%u, type=%u ", sdl->sdl_index, sdl->sdl_type); printf("nlen=%u, alen=%u, slen=%u\n", sdl->sdl_nlen, sdl->sdl_alen, sdl->sdl_slen); if(sdl->sdl_nlen) { bcopy(cptr,buf,sdl->sdl_nlen); buf[sdl->sdl_nlen] = 0; printf(" name = %s\n",buf); cptr += sdl->sdl_nlen; } if(sdl->sdl_alen) { printf(" address = "); showbytes(cptr,sdl->sdl_alen); cptr += sdl->sdl_alen; } if(sdl->sdl_slen) { printf(" selector = "); showbytes(cptr,sdl->sdl_slen); cptr += sdl->sdl_slen; } } break; case AF_INET: printf(" family=INET\n"); printf("[%s]", inet_ntoa(((struct sockaddr_in *)sap)->sin_addr)); printf(".%hu\n",((struct sockaddr_in *)sap)->sin_port); break; default: printf(" family=%d\n",sap->sa_family); showbytes(sap->sa_data,sap->sa_len-2); } } /* * Get the configuration from the kernel. Only called if there's no * configuration. */ void getifconf( void ) { struct ifconf ifc; struct ifreq ifrs[ 64 ], *ifr, *nextifr; struct interface *iface, *niface; int s; struct sockaddr *sa_p; int ifrsize = 0; bzero(&ifc,sizeof(struct ifconf)); bzero(ifrs,sizeof(struct ifreq) * 64); if (( s = socket( AF_INET, SOCK_DGRAM, 0 )) < 0 ) { perror( "socket" ); exit( 1 ); } ifc.ifc_len = sizeof( ifrs ); ifc.ifc_buf = (caddr_t)ifrs; if ( ioctl( s, SIOCGIFCONF, &ifc ) < 0 ) { perror( "getifconf" ); exit( 1 ); } for ( ifr = ifc.ifc_req; ifc.ifc_len >= sizeof( struct ifreq ); ifr = nextifr, ifc.ifc_len -= ifrsize) { /* * in BSD4.4, this returns an entry for every address * Associated with the if. including physical.. they * include a sockaddr which is VARIABLE LENGTH! * * Calculate the length of this entry. */ sa_p = &(ifr->ifr_addr); print_sa(&(ifr->ifr_addr)); /* print_sa(&(ifr->ifr_dstaddr)); print_sa(&(ifr->ifr_broadaddr)); */ ifrsize = IFNAMSIZ + sa_p->sa_len; nextifr = (struct ifreq *)((caddr_t)ifr + ifrsize); /* * Now get it's flags */ if ( ioctl( s, SIOCGIFFLAGS, ifr ) < 0 ) { perror( ifr->ifr_name ); exit( 1 ); } printf("FLAGS = 0x%x\n",(unsigned short)ifr->ifr_flags); printf("\n"); } if ( ifc.ifc_len != 0 ) { fprintf( stderr, "Funky gifconf return.\n" ); exit( 1 ); } (void)close( s ); return; } main() { getifconf(); exit(0); } --------------63DECDAD62319AC452BFA1D7 Content-Type: text/plain; charset=us-ascii; name="dumpifs.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dumpifs.c" #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include void showbytes(unsigned char *cptr,int len) { int i,j; for (j = 0 ;len > 0 ;j++) { for ( i = 0; i < 16; i++) { printf("0x%x ",*cptr++); if (--len == 0) break; } printf("\n"); } } void print_sa (struct sockaddr *sap) { char buf[128]; printf("len=%d,",sap->sa_len); switch(sap->sa_family) { case AF_LINK: printf(" family=LINK\n"); { char *cptr; struct sockaddr_dl *sdl = (struct sockaddr_dl *)sap; cptr = sdl->sdl_data; printf("index=%u, type=%u ", sdl->sdl_index, sdl->sdl_type); printf("nlen=%u, alen=%u, slen=%u\n", sdl->sdl_nlen, sdl->sdl_alen, sdl->sdl_slen); if(sdl->sdl_nlen) { bcopy(cptr,buf,sdl->sdl_nlen); buf[sdl->sdl_nlen] = 0; printf(" name = %s\n",buf); cptr += sdl->sdl_nlen; } if(sdl->sdl_alen) { printf(" address = "); showbytes(cptr,sdl->sdl_alen); cptr += sdl->sdl_alen; } if(sdl->sdl_slen) { printf(" selector = "); showbytes(cptr,sdl->sdl_slen); cptr += sdl->sdl_slen; } } break; case AF_INET: printf(" family=INET\n"); printf("[%s]", inet_ntoa(((struct sockaddr_in *)sap)->sin_addr)); printf(".%hu\n",((struct sockaddr_in *)sap)->sin_port); break; default: printf(" family=%d\n",sap->sa_family); showbytes(sap->sa_data,sap->sa_len-2); } } /* * Get the configuration from the kernel. Only called if there's no * configuration. */ void getifconf( void ) { struct ifconf ifc; struct ifreq ifrs[ 64 ], *ifr, *nextifr; struct interface *iface, *niface; int s; struct sockaddr *sa_p; int ifrsize = 0; bzero(&ifc,sizeof(struct ifconf)); bzero(ifrs,sizeof(struct ifreq) * 64); if (( s = socket( AF_INET, SOCK_DGRAM, 0 )) < 0 ) { perror( "socket" ); exit( 1 ); } ifc.ifc_len = sizeof( ifrs ); ifc.ifc_buf = (caddr_t)ifrs; if ( ioctl( s, SIOCGIFCONF, &ifc ) < 0 ) { perror( "getifconf" ); exit( 1 ); } for ( ifr = ifc.ifc_req; ifc.ifc_len >= sizeof( struct ifreq ); ifr = nextifr, ifc.ifc_len -= ifrsize) { /* * in BSD4.4, this returns an entry for every address * Associated with the if. including physical.. they * include a sockaddr which is VARIABLE LENGTH! * * Calculate the length of this entry. */ sa_p = &(ifr->ifr_addr); print_sa(&(ifr->ifr_addr)); /* print_sa(&(ifr->ifr_dstaddr)); print_sa(&(ifr->ifr_broadaddr)); */ ifrsize = IFNAMSIZ + sa_p->sa_len; nextifr = (struct ifreq *)((caddr_t)ifr + ifrsize); /* * Now get it's flags */ if ( ioctl( s, SIOCGIFFLAGS, ifr ) < 0 ) { perror( ifr->ifr_name ); exit( 1 ); } printf("FLAGS = 0x%x\n",(unsigned short)ifr->ifr_flags); printf("\n"); } if ( ifc.ifc_len != 0 ) { fprintf( stderr, "Funky gifconf return.\n" ); exit( 1 ); } (void)close( s ); return; } main() { getifconf(); exit(0); } --------------63DECDAD62319AC452BFA1D7-- From owner-freebsd-hackers Mon Nov 24 19:24:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA03599 for hackers-outgoing; Mon, 24 Nov 1997 19:24:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freya.circle.net (freya.circle.net [209.95.95.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA03458 for ; Mon, 24 Nov 1997 19:23:11 -0800 (PST) (envelope-from tcobb@staff.circle.net) Received: by FREYA with Internet Mail Service (5.0.1457.3) id ; Mon, 24 Nov 1997 22:24:05 -0500 Message-ID: <8188AD2EBC3CD111B7A30060082F32A403AB82@FREYA> From: Troy Cobb To: freebsd-hackers@FreeBSD.ORG, "'Jim Carroll'" Subject: RE: Retrieve ethernet mac address Date: Mon, 24 Nov 1997 22:24:04 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Monday, November 24, 1997 8:15 PM, Jim Carroll wrote: > > Could someone point me towards how to retrieve an ethernet mac address from > user-land code ? If it matters, we are running 2.2.1 Look into /usr/src/usr.sbin/arp/arp.c - Troy From owner-freebsd-hackers Mon Nov 24 20:20:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA08049 for hackers-outgoing; Mon, 24 Nov 1997 20:16:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from tokyonet-entrance.astec.co.jp (tokyonet-entrance.astec.co.jp [202.239.16.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA08034 for ; Mon, 24 Nov 1997 20:15:56 -0800 (PST) (envelope-from junichi@astec.co.jp) Received: from amont.astec.co.jp (amont.astec.co.jp [172.20.10.1]) by tokyonet-entrance.astec.co.jp (8.8.8+2.7Wbeta7/3.6W-astecMX2.3) with ESMTP id NAA29189; Tue, 25 Nov 1997 13:15:48 +0900 (JST) Received: from stone.astec.co.jp (stone.astec.co.jp [172.20.10.23]) by amont.astec.co.jp (8.7.6/3.6Wbeta5-astecMX2.4) with ESMTP id NAA27775; Tue, 25 Nov 1997 13:15:47 +0900 (JST) Received: (from junichi@localhost) by stone.astec.co.jp (8.8.5/3.5W-solaris1-1.2) id NAA17212; Tue, 25 Nov 1997 13:15:46 +0900 (JST) Message-Id: <199711250415.NAA17212@stone.astec.co.jp> To: Rudy Gireyev cc: freebsd-hackers@FreeBSD.ORG Subject: Re: LS120 driver In-reply-to: Your message of "Mon, 24 Nov 1997 18:18:06 PST." <19971125021806.22306.rocketmail@send1b.yahoomail.com> Date: Tue, 25 Nov 1997 13:15:45 +0900 From: Satoh Junichi Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > A big log fell on my head the other day and right after that > I thought hey, why don't I write a device driver for the LS120 > drive(s) for FreeBSD. These beasts are backwards compatible all > the way to the very useful 720K capacity, 1.44 Meg and of course > the 120Meg, the latter requiring a new disk type. > As I thought about this more, and the damage appeared to set in, I > came up with some questions which I now present for your review: I wrote a driver for the ATAPI LS-120. ^^^^^ It allows to read/write following disks: . 120MB . 1.44MB . 1.25MB (PC-9801 format, 1024Byte/sec) . 1.2MB . 720KB If you try to use it, you can download it from ftp://ftp.freebsd.org/pub/FreeBSD/incoming/atapi-LS120-driver-971124.tar.gz or http://www.jp.freebsd.org/~junichi --- Junichi From owner-freebsd-hackers Mon Nov 24 20:38:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA09012 for hackers-outgoing; Mon, 24 Nov 1997 20:38:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA09007 for ; Mon, 24 Nov 1997 20:38:03 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id EAA15754; Tue, 25 Nov 1997 04:08:44 GMT Date: Tue, 25 Nov 1997 13:08:44 +0900 (JST) From: Michael Hancock To: Rudy Gireyev cc: freebsd-hackers@FreeBSD.ORG Subject: Re: LS120 driver In-Reply-To: <19971125021806.22306.rocketmail@send1b.yahoomail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 24 Nov 1997, Rudy Gireyev wrote: > 2. Is someone already working on such an animal? http://www.jp.freebsd.org/~junichi/ has one in progress. From owner-freebsd-hackers Mon Nov 24 21:13:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA11216 for hackers-outgoing; Mon, 24 Nov 1997 21:13:18 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nomis.Simon-Shapiro.ORG (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA11201 for ; Mon, 24 Nov 1997 21:13:13 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 12273 invoked by uid 1000); 25 Nov 1997 05:13:27 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-111797 [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: Mon, 24 Nov 1997 21:13:27 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: Me, Just me... From: Simon Shapiro To: "Jamil J. Weatherbee" Subject: RE: SCSI Errors & CCD Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 21-Nov-97 Jamil J. Weatherbee wrote: > > I purchased two 4.3 gig IBM External Scsi drives and want to use ccd > to > make them mirrors of each other. I would like to install from my > 2.2.5 > cds onto these drives. Is there a way to set it up to install onto > mirrored drives at install time or can I do this later? > > I want to be able to boot off of these ccd drives. > > > What does the following mean: Certainty: * You have a problem :-) Possibilities: * You did not pay enough for the cables. * There a stub in the cable. Stubs are bad. * The AHA is not terminated correctly (check the BIOS ^a settings). * Neither side is providing TERM-POWER (normaly the HBA should). * Both sides provide TERM_POWER. * The drive is terminated, in addition to the external terminator. * Deffective drive * Deffective AHA > > It appeared when I was trying to install 2.2.5 on my external IBM > 4.3gig > Ultra SCSI. I am using a 2940 ultra, and are properly active > terminated > externally. The adapter is set to use ultra mode(20mhz?) on this > device > which is id0. This is the only device external, and the only device > period (3' cable). > > sd0(ahc0:0:0): parity error during data-in phase > sd0(ahc0:0:0): ABORTED COMMAND > sd0(ahc0:0:0): Initiator Detected error message received, retries: 2 > > sometimes retries were 1-4 > > here is my dmesg: > > Copyright (c) 1992-1997 FreeBSD Inc. > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > > FreeBSD 2.2.5-STABLE #0: Thu Nov 20 20:52:17 PST 1997 > root@shellx.acroal.com:/usr/src/sys/compile/SHELLX > CPU: Pentium Pro (179.63-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x617 Stepping=7 > > Features=0xfbff,MTRR,PGE > ,MCA,CMOV> > real memory = 67108864 (65536K bytes) > avail memory = 62496768 (61032K bytes) > DEVFS: ready for devices > Probing for devices on PCI bus 0: > chip0 rev 2 on > pci0:0 > chip1 rev 1 on pci0:7:0 > chip2 rev 0 on pci0:7:1 > vga0 rev 2 int a irq 11 on pci0:15 > ahc0 rev 1 int a irq 9 on > pci0:16 > ahc0: aic7860 Single Channel, SCSI Id=7, 3 SCBs > ahc0 waiting for scsi devices to settle > (ahc0:0:0): "IBM DCAS-34330 S60B" type 0 fixed SCSI 2 > sd0(ahc0:0:0): Direct-Access 4134MB (8467200 512 byte sectors) > Probing for devices on the ISA bus: > sc0 at 0x60-0x6f irq 1 on motherboard > sc0: VGA color <16 virtual consoles, flags=0x0> > ed0 at 0x300-0x31f irq 10 on isa > ed0: address 00:40:05:3c:8e:0f, type NE2000 (16 bit) > sio0 at 0x3f8-0x3ff irq 4 on isa > sio0: type 16550A > sio1 at 0x2f8-0x2ff irq 3 on isa > sio1: type 16550A > lpt0 at 0x378-0x37f irq 7 on isa > lpt0: Interrupt-driven port > lp0: TCP/IP capable interface > 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 (wd0): > wd0: 2014MB (4124736 sectors), 4092 cyls, 16 heads, 63 S/T, 512 B/S > wdc1 at 0x170-0x177 irq 15 on isa > wdc1: unit 0 (wd2): > wd2: 3815MB (7814016 sectors), 7752 cyls, 16 heads, 63 S/T, 512 B/S > wdc1: unit 1 (atapi): , removable, dma, iordis > wcd0: 689Kb/sec, 112Kb cache, audio play, 127 volume levels, > ejectable tray > wcd0: 120mm data disc loaded, unlocked > npx0 flags 0x1 on motherboard > npx0: INT 16 interface > sb0 at 0x220 irq 5 drq 1 on isa > sb0: > sbxvi0 at 0x0 drq 5 on isa > sbxvi0: > sbmidi0 at 0x330 on isa > > DEVFS: ready to run > IP packet filtering initialized, divert enabled, logging disabled > > If Microsoft Built Cars: There would be an "Engine Pro" with bigger turbos, but it would be slower on most existing roads. Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 From owner-freebsd-hackers Mon Nov 24 21:13:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA11310 for hackers-outgoing; Mon, 24 Nov 1997 21:13:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nomis.Simon-Shapiro.ORG (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA11294 for ; Mon, 24 Nov 1997 21:13:42 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 12286 invoked by uid 1000); 25 Nov 1997 05:13:31 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-111797 [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: <199711202326.SAA02346@bual.research.att.com> Date: Mon, 24 Nov 1997 21:13:31 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: Me, Just me... From: Simon Shapiro To: ji@research.att.com Subject: Re: Problems mounting a cd-rom drive on 2.2_RELENG Cc: lile@stdio.com, hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 20-Nov-97 John Ioannidis wrote: >> anarchy: # mount /cdrom >> cd9660: /dev/cd0a: Invalid argument > > Looks like your kernel and your /sbin/mount_cd9660 are not happy with > each other. Make sure you run the mount program that goes with the > kernel you are running. If you are tracking FreeBSD-current, make > sure > your mount_cd9660 is: > "$Id: mount_cd9660.c,v 1.7.2.1 1997/08/17 13:30:23 joerg Exp$"; > The mount program that comes with 2.2.2-RELEASE does not work. > > /ji You are probably right, but may not be completely so: We had this problem in -current, sometimes between the end of October, and the 12th of November. It seems gone now, but the problem was from a release build. If Microsoft Built Cars: There would be an "Engine Pro" with bigger turbos, but it would be slower on most existing roads. Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 From owner-freebsd-hackers Mon Nov 24 21:14:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA11477 for hackers-outgoing; Mon, 24 Nov 1997 21:14:45 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nomis.Simon-Shapiro.ORG (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA11455 for ; Mon, 24 Nov 1997 21:14:38 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 12320 invoked by uid 1000); 25 Nov 1997 05:13:34 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-111797 [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: <199711191001.LAA06385@sos.freebsd.dk> Date: Mon, 24 Nov 1997 21:13:34 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: Me, Just me... From: Simon Shapiro To: sos@FreeBSD.dk Subject: RE: Mail spam, sigh... Cc: (FreeBSD hackers) Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 19-Nov-97 Søren Schmidt wrote: > > If any of you gets a message back from my system claiming you > should be shot or something to that extent, well, I'm sorry. > The amount of JUNKmail recently has demanded that I enable > my hysteric mail filter again, and its pretty harsh (one > unsolicited mail, and that doamin is toast). > Sorry for any inconvinience, but the filter stays this time... What is ``unsolicited'' ? You only want replies to your mail? That WILL reduce your incoming mail to zero, alright. If Microsoft Built Cars: There would be an "Engine Pro" with bigger turbos, but it would be slower on most existing roads. Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 From owner-freebsd-hackers Mon Nov 24 21:14:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA11500 for hackers-outgoing; Mon, 24 Nov 1997 21:14:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nomis.Simon-Shapiro.ORG (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA11433 for ; Mon, 24 Nov 1997 21:14:25 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 12304 invoked by uid 1000); 25 Nov 1997 05:13:32 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-111797 [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: Mon, 24 Nov 1997 21:13:32 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: Me, Just me... From: Simon Shapiro To: Tom Subject: Re: Partitioning suggestions? Cc: hackers@FreeBSD.ORG, craig@ProGroup.COM, Don.Lewis@tsc.tdk.com, Terry Lambert Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 20-Nov-97 Tom wrote: > > On Wed, 19 Nov 1997, Terry Lambert wrote: > >> > I can't accept that idea of a "graceful" failure. I don't know >> > if there >> > are any "catastrophic" (ie. eaten e-mail, destroyed password >> > files, etc) failures in FreeBSD, due to full filesystems. But the >> > so-called graceful failures are the real essence of this thread. >> > How do >> > you avoid them in the first place? >> >> By not engaging in sysadm pilot error that results in filled drives. > > In what universe is this? Point me to a mail server that you use, > and > I will fill one or more filesystems for you. Then when done, I will > blame > it on your pilot error. > >> > > That doesn't guarantee it. What if your FS fills up with PID >> > > files? >> > >> > What would be creating pid files in /var/log? >> >> In /var. > > The original poster, said to make /var/log a separate filesystem. > This goes along with my point, because it would eliminate the > problem. Moreover. In ALL our production servers we have: /var /var/tmp /var/spool /var/account /var/log /var/qmail And more. We have to be careful. Getting to some of our systems resembles parts of Jurrasic Park. We HATE crashed systems. Rebooting is rarely an option... Simon > > Tom > If Microsoft Built Cars: There would be an "Engine Pro" with bigger turbos, but it would be slower on most existing roads. Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 From owner-freebsd-hackers Mon Nov 24 21:14:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA11531 for hackers-outgoing; Mon, 24 Nov 1997 21:14:54 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nomis.Simon-Shapiro.ORG (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA11494 for ; Mon, 24 Nov 1997 21:14:47 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 12322 invoked by uid 1000); 25 Nov 1997 05:13:35 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-111797 [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: Mon, 24 Nov 1997 21:13:34 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: Me, Just me... From: Simon Shapiro To: Tom Subject: Re: Partitioning suggestions? Cc: hackers@FreeBSD.ORG, craig@ProGroup.COM, Don.Lewis@tsc.tdk.com, Terry Lambert Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 19-Nov-97 Tom wrote: ... >> I) Filling the disk up should not be catastrophic, even if it >> does occur. > > How can it not be catastrophic? Think about a mail server. It > will > have to refuse e-mail, if there is no spool space. That is > catastrophic. Only if a million dollars check got lost. A descent MTA should not dump mail on the floor if the disk is full. Thsi is what stat(2) is for. A catastrophic failure is one that damages the system and stops it from working; like Slowlaris when the filesystem is full (write into the next slixe and destroy that too.). Actually, if you look at an MTA as a database application (one which stores and retrievs data, based on client requests), you get the willies looking at most MTA programs and their disregard to safety and sanity. This is not an O/S problem. disk Partitioning? The more the marrier. > >> II) Only root processes can override the reserve. This means pilot >> error in the most general sense. Pilot error can also write >> over the front of a raw disk; how does the software prevent >> one kind of pilot error, but not the other? It can't. > > Who cares? Many process run as root, so they are all competing for > the > reserve. Also, non-root processes can be critical too. If a process (not a human) routinely and automatically overrides the reserve, then there is, by definition, no reserve. It is like the speed limit; Makes the politicians feel like they are actually contributing to society. >> III) If you have a root process which is a daemon, good sense >> dictates that the process will have its own controls to >> prevent overriding the reserve. The syslog argument >> remains bogus, since you should use newsyslog instead, >> and avoid the issue. > > newsyslog can limit logs to a particular size. It has no idea of > how > much space might actually be available. It can not avoid the issue, > perhaps only limit it. It is only guarrenteed to avoid the issue, if > /var/log is a separate filesystem. A ten line change can fix that. Check for free space before you write. You do look both ways before you cross a busy street. Right? Tery is right. These are bugs which are trivial to fix. >> For each example of badly behaved software you can come up with, I >> will either point to a well behaved piece of software, or I will >> simply say "then fix it". > > Please, let me use your magic wand on my software. I have no idea > on > how applications might continue to work without impairment with full > filesystems. Seems to defy the laws of this uniserve. The application may be impaired. But should not crash. the system should not be impaired. MTA can defer messages, word processors can refuse to save. vipw can refuse to write over good files, etc. RDBMS (true ones) do NOT use the filesystem for this exact reason. >> The FreeBSD penchant for destroying passwd files when the disk is >> full >> is an *error* in FreeBSD, and should be corrected. Then I can point >> at (I) above, and state "so what? So the disk is full...". > > Who said it destroyed the passwd file? It just attempts to build > new > files, it it runs out of storage, it aborts, leaving the original > passwd > file. It kinda leaves you in lurch though, because you can't make > any > changes to it. The rm(1) command still works. So does mv(1). It is acceptable for a system which is running into resource bind to stop accepting new transactions, so long it tells you why it stops receiving. What you describe is perfectly correct behavior. Even the best latex has limits on stretching - This is why we abandoned using it for disk media :-). Besides, most disk manufacturers still use metal for platters - does not stretch worth a darn :-) If Microsoft Built Cars: There would be an "Engine Pro" with bigger turbos, but it would be slower on most existing roads. Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 From owner-freebsd-hackers Mon Nov 24 21:15:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA11674 for hackers-outgoing; Mon, 24 Nov 1997 21:15:29 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nomis.Simon-Shapiro.ORG (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA11632 for ; Mon, 24 Nov 1997 21:15:19 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 12342 invoked by uid 1000); 25 Nov 1997 05:13:36 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-111797 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Mon, 24 Nov 1997 21:13:36 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: Me, Just me... From: Simon Shapiro To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, freebsd-smp@freebsd.org Subject: Compiler Bug??? Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I hope someone reads this and actually responds. I cross-mail to these lists as some people I am trying to reach do not read either of these lists and it touches all (I think). O/S: FreeBSD 3.0-current as of last few days. X11 3.3.1, compiled here (mainly to get rid of the libtermcap problem). Scenario 1: Xfmail of 17-Nov-97 with xforms 0.88: Compiles fine, then produces dozens of ``Bad Attribute'' and `Bad Coordinates''. These come from libX11. Tearing my hair out did not help, so I boot UP (was on SMP). The problem is... GONE! Recompile on UP, reboot SMP... Problem is... Yup, GONE! Scenario 2: Boot SMP again. Compile and run Xcoral 3.1. Pretty cool editor and finally can do ``normal'' cut-n-paste, etc. So I set its geometry in .Xdefaults to =200x400. Nope. Will not chnge size. I modify parse.c to have the ugly printf you see below: flags = XParseGeometry ( buf, &x, &y, &width, &he (void)fprintf(stderr, "%s.%d: x = %d, y = %d, w = %d, h =%d\n", __FILE__, __LINE__, x, y, width, height); It says: parse.c.843: x = -272640524, y = 537577259, w = 200, h = 400 (x, y are corrdinates which are unspecified, which is OK to look this ugly) Size is still huge (about 600x800). So I add another printf: if ( (width < ((DisplayWidth ( dpy, DefaultScreen (dpy )) * 2 ) || width > DisplayWidth ( dpy, DefaultScreen (dpy ) ) ) opt->width = (DisplayWidth ( dpy, DefaultScreen (dpy ) ) *7) / 10; else opt->width = width; if ( (height < ((DisplayHeight ( dpy, DefaultScreen (dpy )) * 1 ) /5 )) || height > DisplayHeight ( dpy, DefaultScreen (dpy ) ) ) opt->height = (DisplayHeight ( dpy, DefaultScreen (dpy ) ) * 6) / 10; else opt->height = height; (void)fprintf(stderr, "%s.%d:width = %d, height = %d\n", __FILE__, __LINE__, opt->width = width, opt->height); Guess what? The window now has the specified geometry! I would not have paid much attention to these, unless I also had the problem where cc1 dumps core when we run make -j8 world, some times. Re-boot clears the crashing of the compiler. I really am NOT a compiler person (what are you simon? dunno...), so I cannot intelligently proceed without some intelligent help. If Microsoft Built Cars: There would be an "Engine Pro" with bigger turbos, but it would be slower on most existing roads. Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 From owner-freebsd-hackers Mon Nov 24 21:16:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA12021 for hackers-outgoing; Mon, 24 Nov 1997 21:16:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nomis.Simon-Shapiro.ORG (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA11941 for ; Mon, 24 Nov 1997 21:16:33 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 12398 invoked by uid 1000); 25 Nov 1997 05:13:47 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-111797 [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: <199711180932.EAA01115@dyson.iquest.net> Date: Mon, 24 Nov 1997 21:13:47 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: Me, Just me... From: Simon Shapiro To: "John S. Dyson" Subject: Re: Optimizing HD I/O. What size to use to read/write? Cc: hackers@FreeBSD.ORG, reyesf@super.zippo.com Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 18-Nov-97 John S. Dyson wrote: > Francisco Reyes said: >> I am going to start working on a program which will be heavy on I/O. >> I was wondering what would be a good size to read/write at a time. >> >> What is the minimun block size FreeBSD allocates? 4K? 8K? Is it HD >> dependent? >> > One more comment, if you are doing sequential I/O, you really don't > want > to do read/writes less than 4K-8K. You are likely into diminishing > returns beyond 8K. I'd say it applies to random access even more. Especially if there is more than one client for the disk I/O. On SCSI, up to about 8K, the dominant factor is bus handling, data is a small fraction. After 8K data starts showing up (and this is where wide/ultra/shmultra start making a difference). > > -- > John > dyson@freebsd.org > jdyson@nc.com If Microsoft Built Cars: There would be an "Engine Pro" with bigger turbos, but it would be slower on most existing roads. Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 From owner-freebsd-hackers Mon Nov 24 21:47:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA14095 for hackers-outgoing; Mon, 24 Nov 1997 21:47:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA14090 for ; Mon, 24 Nov 1997 21:47:19 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.5) with ESMTP id VAA02822 for ; Mon, 24 Nov 1997 21:47:11 -0800 (PST) Message-Id: <199711250547.VAA02822@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: hackers@freebsd.org Subject: You got Curls?? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Nov 1997 21:47:11 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk http://www.cag.lcs.mit.edu/curl/ "Curl is a new language for creating web documents with almost any sort of content, fom simple formatted text to complex interactive applets" Cheers, Amancio From owner-freebsd-hackers Mon Nov 24 23:15:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA19523 for hackers-outgoing; Mon, 24 Nov 1997 23:15:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA19513 for ; Mon, 24 Nov 1997 23:14:56 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id RAA00411; Tue, 25 Nov 1997 17:40:13 +1030 (CST) Message-Id: <199711250710.RAA00411@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Jim Carroll cc: freebsd-hackers@freebsd.org Subject: Re: Retrieve ethernet mac address In-reply-to: Your message of "Mon, 24 Nov 1997 20:15:15 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Nov 1997 17:40:12 +1030 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Could someone point me towards how to retrieve an ethernet mac address from > user-land code ? If it matters, we are running 2.2.1 The best way is using sysctl() as with ifconfig(8). I realise that this is a little fugly. Can you be more specific about which MAC address you want, and what associations you want with the address? > If someone has a working snippet, I would be grateful. A good pointer > towards a FAQ or doc would also be helpful. The best suggestion I can make is to look at the source, and the way that the sysctl variables are established when an interface is created. > I have been staring at netstat and ifconfig source for a few hours, but am > having trouble making heads or tails. netstat usese kvm() and ifconfig uses > sysctl(). I can't find enough docs of either method to get my head around > what is needed to just extract mac address. If all you want is a list of MAC addresses for the local system, I would use ifconfig(8) and awk(1). 8) mike From owner-freebsd-hackers Mon Nov 24 23:46:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA21916 for hackers-outgoing; Mon, 24 Nov 1997 23:46:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from pluto.senet.com.au (root@pluto.senet.com.au [203.11.90.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA21908 for ; Mon, 24 Nov 1997 23:46:07 -0800 (PST) (envelope-from darius@holly.rd.net) Received: from holly.rd.net (root@c2-p38.senet.com.au [203.56.237.103]) by pluto.senet.com.au (8.8.7/8.8.7) with ESMTP id SAA21082 for ; Tue, 25 Nov 1997 18:15:58 +1030 Received: from holly.rd.net (darius@localhost.rd.net [127.0.0.1]) by holly.rd.net (8.8.5/8.8.5) with ESMTP id SAA16393 for ; Tue, 25 Nov 1997 18:18:59 +1030 (CST) Message-Id: <199711250748.SAA16393@holly.rd.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: freebsd-hackers@freebsd.org Subject: Shared Libraries and debugging Reply-to: darius@senet.com.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Nov 1997 18:18:59 +1030 From: "Daniel J. O'Connor" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I was fiddling with some code which links against shared libraries, and noticed that when viewing a core dumb with gdb, it doesn't load the symbols from the shared libraries, so consequently debugging the program is kind of akward. Is this 'the way it is' or am I doing something wrong? --------------- Daniel O'Connor 3rd Year Computer Science at Flinders University http://www.geocities.com/CapeCanaveral/7200 From owner-freebsd-hackers Mon Nov 24 23:48:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22097 for hackers-outgoing; Mon, 24 Nov 1997 23:48:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from pluto.senet.com.au (root@pluto.senet.com.au [203.11.90.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA22092 for ; Mon, 24 Nov 1997 23:48:41 -0800 (PST) (envelope-from darius@holly.rd.net) Received: from holly.rd.net (root@c2-p38.senet.com.au [203.56.237.103]) by pluto.senet.com.au (8.8.7/8.8.7) with ESMTP id SAA21248 for ; Tue, 25 Nov 1997 18:18:37 +1030 Received: from holly.rd.net (darius@localhost.rd.net [127.0.0.1]) by holly.rd.net (8.8.5/8.8.5) with ESMTP id SAA16413 for ; Tue, 25 Nov 1997 18:21:40 +1030 (CST) Message-Id: <199711250751.SAA16413@holly.rd.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: freebsd-hackers@freebsd.org Subject: ATAPI as an LKM Reply-to: darius@senet.com.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Nov 1997 18:21:40 +1030 From: "Daniel J. O'Connor" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I am trying to add stuff to the ATAPI cd driver, and so made it an LKM so I din't have to reboot (as often =) I had to also make the ATAPI driver an LKM because it couldn't link properly with 'option ATAPI_STATIC' :-/ OK, fair enough, I do this, and then cdcontrol doesn't work :) You tell it to play a track, and it just gets ignored, getting status is OK, but the TOC is unavailable. Any ideas? Thanks! --------------- Daniel O'Connor 3rd Year Computer Science at Flinders University http://www.geocities.com/CapeCanaveral/7200 From owner-freebsd-hackers Tue Nov 25 01:11:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA28164 for hackers-outgoing; Tue, 25 Nov 1997 01:11:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA28157 for ; Tue, 25 Nov 1997 01:11:53 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id UAA29294; Tue, 25 Nov 1997 20:10:00 +1100 Date: Tue, 25 Nov 1997 20:10:00 +1100 From: Bruce Evans Message-Id: <199711250910.UAA29294@godzilla.zeta.org.au> To: bde@zeta.org.au, mouth@ibm.net Subject: Re: Status of 650 UART support Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>simplest approach leads to 3 i/o's per byte of input instead of 2 >>(IIR, LSR, RXDATA) instrad of (LSR, RXDATA). > >Not in my code. I can read the IIR once, and if checking the LSR >reveals no errors, and the IIR indicates a FIFO interrupt (as opposed >to FIFO timeout), I have a FIFO of bytes, full at least to the trigger >level I previously set in the FCR, and I can safely read them all I was writing about the error case. >with one in-line assembler REP INSB instruction emitted by Turbo C >(can GCC do that?). I've implemented a circular buffer which lets me Yes, but you should use the standard i386 function insb() instead of raw asm (it gives the same code as good asm). I tried using it for output, but it was no faster than repeated outb()s on my system. >write the burst into one contiguous area even in the case where it >extends beyond the "virtual" end. Good trick. >>>I changed my own copy of sioprobe to drive the IRQ output, letting >>>each UART pull its line to ground during sioprobe. > >>You mean all at the start? It's not very nice to drive sio1-N in >>the probe for sio0. > >Why not? That is exactly what you want to do if you have several >inputs feeding an OR gate. You never want an OR gate input floating. > >True, If a user has the classic COM1/COM3 conflict neither one will >probe correctly. But that's the way it should be. Sorry, the usual ISA case is most important. >> so there is no guarantee that a falling edge on one will make it to the >> output of the OR gate. > >After building and testing such a device myself, I still don't >understand what you're driving at here. Of what consequence is a >falling edge on any of the UART INT outputs? The PIC which ultimately >receives the electrical signal as output from the OR gate has no care >for falling edges, only rising ones. It does care. After an irq has been acked, the edge latch remains set until the irq goes low (or at least until it is low when sampled on the next bus clock cycle). The handler must not return with the edge latch set, at least for 16x50 devices, since if the edge latch is set then there must be a device irq and returning would give up the only chance of handling the irq. >>The code being discussed is for multiport cards >>with (simple) hardware logic for IRQ sharing. Not-so-simple hardware >>might have a way to force an edge, but siointr() is for the general >>case so it can't have support for or dependencies on this. > >I don't understand this either. In the case of an OR gate which >implements, as you say, "(simple) hardware logic for IRQ sharing," >why is there a need to "force an edge" at all? The OR gate is simply See above. >going to alternate its output between +5v when any input is true, and >ground when all inputs are false. When it changes its output from >ground to +5v, the PIC sees the rising edge and recognizes an >interrupt. The OR gate acts as a buffer between the independent UART >INT outputs and the input of the PIC. The CPU won't see the rising edge if the level is already high from an IRQ on another UART. >As you wish. If I find some time to hack mine, I hope you won't mind >more questions about sio.c. Not quite so many questions as before now, please. >>There's only 3 in the standard version and they're just to get out >>of error cases :-) > >I counted 16 in the -current version. 3 in siointr1(). Bruce From owner-freebsd-hackers Tue Nov 25 03:54:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA07431 for hackers-outgoing; Tue, 25 Nov 1997 03:54:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from wakko.visint.co.uk (wakko.visint.co.uk [194.207.134.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA07419; Tue, 25 Nov 1997 03:54:08 -0800 (PST) (envelope-from steve@visint.co.uk) Received: from dylan.visint.co.uk (dylan.visint.co.uk [194.207.134.180]) by wakko.visint.co.uk (8.8.5/8.7.3) with SMTP id LAA15002; Tue, 25 Nov 1997 11:53:33 GMT Date: Tue, 25 Nov 1997 11:53:33 +0000 (GMT) From: Stephen Roome Reply-To: Stephen Roome To: Nate Williams cc: Julian Elischer , hackers@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: BIND 8.1.1 In-Reply-To: <199711250130.SAA24765@mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 24 Nov 1997, Nate Williams wrote: > > My presumption is that everyone agrees that we'll move to it > > 'eventually'. does anyone have ideas as to when 'eventually' is? > > I thought the advice from Paul was to 'wait awhile' and integrate when > everything got finished up, which means 'wait awhile' to me. :) I was under the impression that there are some fairly important changes in BIND 8.1.1, and especially after all the recent stuff with alternic and nominet I guess there's people upgrading the default bind by hand now, which is probably a pain! Couldn't 8.1.1 be made a package/port in the meantime, it would make life a bit easier for all the isp folks who run FreeBSD. I reckon it'd be a fairly heavily used port if someone did it. Along with sendmail BIND is also a fairly important consideration when deciding what platform I'm going to be running assuming I'm a new isp. How many (any?) new users will chose Linux/BSDi/Solaris or whatever else is now running 8.1.1 by default ? Steve. -- Steve Roome - Vision Interactive Ltd. Tel:+44(0)117 9730597 Home:+44(0)976 241342 WWW: http://dylan.visint.co.uk/ From owner-freebsd-hackers Tue Nov 25 04:16:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA08603 for hackers-outgoing; Tue, 25 Nov 1997 04:16:28 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id EAA08580 for ; Tue, 25 Nov 1997 04:16:09 -0800 (PST) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 13739 invoked by uid 1001); 25 Nov 1997 12:15:43 +0000 (GMT) To: steve@visint.co.uk Cc: hackers@FreeBSD.ORG Subject: Re: BIND 8.1.1 In-Reply-To: Your message of "Tue, 25 Nov 1997 11:53:33 +0000 (GMT)" References: X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 25 Nov 1997 13:15:42 +0100 Message-ID: <13737.880460142@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I was under the impression that there are some fairly important changes in > BIND 8.1.1, and especially after all the recent stuff with alternic and > nominet I guess there's people upgrading the default bind by hand now, > which is probably a pain! > > Couldn't 8.1.1 be made a package/port in the meantime, it would make life > a bit easier for all the isp folks who run FreeBSD. I don't see what the big deal is about BIND 8.1.1. If anybody wants to make it a port, by all means - but as of right now, all you need to do is "make clean; make depend; make". It compiles out of the box on 2.2 and newer. You only really need named (and named-xfer), the client-side functionality is basically the same in 4.9.6 and 8.1.1. > I reckon it'd be a fairly heavily used port if someone did it. Along with > sendmail BIND is also a fairly important consideration when deciding what > platform I'm going to be running assuming I'm a new isp. As far as I know there are no *security* reasons to switch to 8.1.1 - the security fixes that are in 8.1.1 are also in 4.9.6. If you switch to 8.1.1 you're most likely doing it in order to use some of the new functionality in 8.1.1 - but the people who need the new features are going to have to tweak the named.conf file anyway. > How many (any?) new users will chose Linux/BSDi/Solaris or whatever else > is now running 8.1.1 by default ? I know of *no* systems being delivered with bind 8.1.1 today - there are no systems running 8.1.1 "by default". On the other hand, I run 8.1.1 on several FreeBSD systems (and I also did the initial port, in the ISC sense, of BIND 8 to FreeBSD). 8.1.1 runs very well on FreeBSD - but I don't really see why people are so eager to make it the default yet. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-hackers Tue Nov 25 04:47:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA09907 for hackers-outgoing; Tue, 25 Nov 1997 04:47:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from itesec.hsc.fr (root@itesec.hsc.fr [192.70.106.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA09890; Tue, 25 Nov 1997 04:46:52 -0800 (PST) (envelope-from pb@hsc.fr) Received: from mars.hsc.fr (pb@mars.hsc.fr [192.70.106.44]) by itesec.hsc.fr (8.8.8/8.8.5/itesec-1.10-nospam) with ESMTP id NAA03259; Tue, 25 Nov 1997 13:46:03 +0100 (MET) Received: (from pb@localhost) by mars.hsc.fr (8.8.5/8.8.5/pb-19970301) id NAA23355; Tue, 25 Nov 1997 13:46:02 +0100 (MET) Message-ID: <19971125134601.ZD51524@mars.hsc.fr> Date: Tue, 25 Nov 1997 13:46:01 +0100 From: Pierre.Beyssac@hsc.fr (Pierre Beyssac) To: steve@visint.co.uk (Stephen Roome) Cc: nate@mt.sri.com (Nate Williams), julian@whistle.com (Julian Elischer), hackers@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: BIND 8.1.1 References: <199711250130.SAA24765@mt.sri.com> X-Mailer: Mutt 0.59.1e Mime-Version: 1.0 In-Reply-To: ; from Stephen Roome on Nov 25, 1997 11:53:33 +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Stephen Roome: > I was under the impression that there are some fairly important changes in > BIND 8.1.1, and especially after all the recent stuff with alternic and > nominet I guess there's people upgrading the default bind by hand now, > which is probably a pain! You don't need 8.1.1 to get the latest security fixes: BIND 4.9.6 has the same fixes. I think that's the version included in FreeBSD 2.2.5. I believe the 4.9.x series are intended to receive all such fixes. Making BIND 8.1.1 the default under FreeBSD 2.2.x has the drawback that it would break existing 2.2.x installations relying on BIND 4.x configs. -- Pierre.Beyssac@hsc.fr From owner-freebsd-hackers Tue Nov 25 04:56:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA10372 for hackers-outgoing; Tue, 25 Nov 1997 04:56:36 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from wakko.visint.co.uk (wakko.visint.co.uk [194.207.134.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA10364 for ; Tue, 25 Nov 1997 04:56:32 -0800 (PST) (envelope-from steve@visint.co.uk) Received: from dylan.visint.co.uk (dylan.visint.co.uk [194.207.134.180]) by wakko.visint.co.uk (8.8.5/8.7.3) with SMTP id MAA15302; Tue, 25 Nov 1997 12:56:05 GMT Date: Tue, 25 Nov 1997 12:56:04 +0000 (GMT) From: Stephen Roome To: sthaug@nethelp.no cc: hackers@FreeBSD.ORG Subject: Re: BIND 8.1.1 In-Reply-To: <13737.880460142@verdi.nethelp.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 25 Nov 1997 sthaug@nethelp.no wrote: > As far as I know there are no *security* reasons to switch to 8.1.1 - > the security fixes that are in 8.1.1 are also in 4.9.6. If you switch > to 8.1.1 you're most likely doing it in order to use some of the new > functionality in 8.1.1 - but the people who need the new features are > going to have to tweak the named.conf file anyway. If there's no secuity implications then there's no rush, true, and if no-one else is sending it out by default again, there's no rush. But when will it be the default? If there's no bugs (well, no serious ones that have been found) then why delay ? I suppose when it's fully tested, but this is a lot of testing, certainly more than some of the things that might have gone into 2.2.5-RELEASE, like the appletalk stack for example, although that might have been tested a lot, I'm assuming that's not the case. [Not to slight 2.2.5, which IMHO in all other respects is good.] Steve. Steve Roome - Vision Interactive Ltd. Tel:+44(0)117 9730597 Home:+44(0)976 241342 WWW: http://dylan.visint.co.uk/ From owner-freebsd-hackers Tue Nov 25 06:07:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA14015 for hackers-outgoing; Tue, 25 Nov 1997 06:07:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from glacier.wise.edt.ericsson.se (glacier-ext.wise.edt.ericsson.se [193.180.251.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA13999 for ; Tue, 25 Nov 1997 06:07:32 -0800 (PST) (envelope-from etxelin@kk.etx.ericsson.se) Received: from kkb3 (kkb3.kk.etx.ericsson.se [130.100.97.23]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with SMTP id PAA05670 for ; Tue, 25 Nov 1997 15:07:26 +0100 (MET) Received: from kk667.kk.etx.ericsson.se by kkb3 (SMI-8.6/LME-2.2.6) id PAA11349; Tue, 25 Nov 1997 15:04:04 +0100 From: etxelin@kk.etx.ericsson.se (ETX-B-SL Elin Wedlund) Received: by kk667.kk.etx.ericsson.se (SMI-8.6/client-1.6) id PAA25920; Tue, 25 Nov 1997 15:04:07 +0100 Date: Tue, 25 Nov 1997 15:04:07 +0100 Message-Id: <199711251404.PAA25920@kk667.kk.etx.ericsson.se> To: freebsd-hackers@freebsd.org Subject: linux jdk - sockets X-Sun-Charset: US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I'm trying to use the linux jdk1.1.3 on freebsd with linux emulation. Everything works fine, except the most important for me: I cannot connect to a ServerSocket, getting the error message "transport endpoint already connected", even though no connection has been established to that server socket (and that shouldn't matter, either!) I am SURE that it is not my program that is wrong (e.g. it works with the same jdk on Linux). The problem is not in the ServerSocket, since I can connect e.g. from a Linux machine to a ServerSocket on a freebsd machine. It also works fine within a freebsd machine. It is only when I try to connect FROM a FreeBSD machine (to any type of machine) it goes wrong. I have the impression that quite a few of you are using the linux jdk on freebsd, and at least someone must have tried to use TCP sockets? Anyone have any idea of what I could do to fix it? Appreciate _any_ response! /Elin From owner-freebsd-hackers Tue Nov 25 07:26:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA19291 for hackers-outgoing; Tue, 25 Nov 1997 07:26:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from osmail.onesource.com (osmail.onesource.com [206.33.228.58]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA19269 for ; Tue, 25 Nov 1997 07:26:03 -0800 (PST) (envelope-from 7ox4p7Iud@mustan1gleg.net) From: 7ox4p7Iud@mustan1gleg.net Received: from 787tF51cu (usr36-dialup26.mix2.Atlanta.mci.net [166.55.59.218]) by osmail.onesource.com (2.0 Build 2119 (Berkeley 8.8.4)/8.8.4) with SMTP id KAB00902; Tue, 25 Nov 1997 10:23:34 -0500 DATE: 24 Nov 10 10:29:08 AM Message-ID: TO: wemail@4uonthe.net SUBJECT: We will mail 4 U Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk LET US DO YOUR BULK MAILINGS!!! ..$250 PER MILLION THE WAY OF THE FUTURE FOR SUCCESS IN YOUR BUSINESS! Our company will do bulk emailing for your product/service. Addresses are extracted daily by four of our computers, which run 24 hours a day 7 days a week, scanning the net for new addresses. They are fresh! Over 36 million addresses on file. No more than 2 pages (50 lines), no porn and no foul language. We do not do targeted mailings at this price. Targeted mailings $150 per 50,000 addresses extracted. There are no lower prices on the net. Your mailing can be done in a matter of hours. We have 4 computers extracting addresses 24/7. For the fastest service, cheapest prices and cleanest mailings call our processing and new accounts office at 904-282-0945, Monday - Friday 9 - 5 EST. If the line is busy, please keep trying, as bulk mailing is growing fast. We do want to work with you to advertise your product. $250 per million expires December 1, 1997. Price increases to $350 per million, $250 per 500,000. All orders received before December 1 will not reflect the increase. Even with the increase, we will still be the best prices on the net. To have your name removed, call our processing office. Any negative responses will be dealt with accordingly. From owner-freebsd-hackers Tue Nov 25 07:29:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA19570 for hackers-outgoing; Tue, 25 Nov 1997 07:29:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from bonaire (osmail2.onesource.com [206.33.230.240]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA19564 for ; Tue, 25 Nov 1997 07:29:03 -0800 (PST) (envelope-from 5p0G806BN@1yrdue.net) From: 5p0G806BN@1yrdue.net Received: from x5shuFdVb (usr36-dialup26.mix2.Atlanta.mci.net [166.55.59.218]) by bonaire (2.0 Build 2119 (Berkeley 8.8.4)/8.8.4) with SMTP id KAA00817; Tue, 25 Nov 1997 10:19:50 -0500 DATE: 24 Nov 10 10:24:50 AM Message-ID: TO: wemail@4uonthe.net SUBJECT: We will mail 4 U Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk LET US DO YOUR BULK MAILINGS!!! ..$250 PER MILLION THE WAY OF THE FUTURE FOR SUCCESS IN YOUR BUSINESS! Our company will do bulk emailing for your product/service. Addresses are extracted daily by four of our computers, which run 24 hours a day 7 days a week, scanning the net for new addresses. They are fresh! Over 36 million addresses on file. No more than 2 pages (50 lines), no porn and no foul language. We do not do targeted mailings at this price. Targeted mailings $150 per 50,000 addresses extracted. There are no lower prices on the net. Your mailing can be done in a matter of hours. We have 4 computers extracting addresses 24/7. For the fastest service, cheapest prices and cleanest mailings call our processing and new accounts office at 904-282-0945, Monday - Friday 9 - 5 EST. If the line is busy, please keep trying, as bulk mailing is growing fast. We do want to work with you to advertise your product. $250 per million expires December 1, 1997. Price increases to $350 per million, $250 per 500,000. All orders received before December 1 will not reflect the increase. Even with the increase, we will still be the best prices on the net. To have your name removed, call our processing office. Any negative responses will be dealt with accordingly. From owner-freebsd-hackers Tue Nov 25 07:37:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA20733 for hackers-outgoing; Tue, 25 Nov 1997 07:37:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from pemail.net (pemail.net [194.152.67.114]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA20712 for ; Tue, 25 Nov 1997 07:37:41 -0800 (PST) (envelope-from N.Wright@pemail.net) Message-Id: <199711251537.HAA20712@hub.freebsd.org> Received: (qmail 434 invoked from network); 25 Nov 1997 15:37:16 -0000 Received: from pemail.net (HELO mailhost.pemail.net) (194.152.67.114) by pemail.net with SMTP; 25 Nov 1997 15:37:16 -0000 Date: Tue, 25 Nov 1997 15:37:16 +0000 (GMT) From: Nicholas Wright Subject: DOES JDK1.1.3 EXIST FOR FreeBSD? To: hackers@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Please reply to me personally, as I do not read this mailing list. --------------------------------------------------- PersonalConnections, my home on the web. Free email and your own webpage: http://www.Pconnections.net --------------------------------------------------- My PersonalEmail : N.Wright@Pemail.net My PersonalPage: http://Ppage.net/?N.Wright From owner-freebsd-hackers Tue Nov 25 07:38:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA20794 for hackers-outgoing; Tue, 25 Nov 1997 07:38:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from germanium.xtalwind.net (germanium.xtalwind.net [205.160.242.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA20779 for ; Tue, 25 Nov 1997 07:38:10 -0800 (PST) (envelope-from jack@diamond.xtalwind.net) Received: from localhost (localhost.xtalwind.net [127.0.0.1]) by germanium.xtalwind.net (8.8.8/8.8.7) with SMTP id KAA03770; Tue, 25 Nov 1997 10:37:58 -0500 (EST) Date: Tue, 25 Nov 1997 10:37:58 -0500 (EST) From: jack X-Sender: jack@germanium.xtalwind.net To: Stephen Roome cc: hackers@FreeBSD.ORG Subject: Re: BIND 8.1.1 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 25 Nov 1997, Stephen Roome wrote: > I was under the impression that there are some fairly important changes in > BIND 8.1.1, and especially after all the recent stuff with alternic and > nominet I guess there's people upgrading the default bind by hand now, > which is probably a pain! Actually it is rather painless. Just `make install' and run the included script to update the data files. -------------------------------------------------------------------------- Jack O'Neill Finger jacko@diamond.xtalwind.net or jack@xtalwind.net http://www.xtalwind.net/~jacko/pubpgp.html #include for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD -------------------------------------------------------------------------- From owner-freebsd-hackers Tue Nov 25 07:39:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA20915 for hackers-outgoing; Tue, 25 Nov 1997 07:39:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA20892; Tue, 25 Nov 1997 07:38:55 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id IAA01171; Tue, 25 Nov 1997 08:38:52 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id IAA27156; Tue, 25 Nov 1997 08:38:50 -0700 Date: Tue, 25 Nov 1997 08:38:50 -0700 Message-Id: <199711251538.IAA27156@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Stephen Roome Cc: Nate Williams , Julian Elischer , hackers@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: BIND 8.1.1 In-Reply-To: References: <199711250130.SAA24765@mt.sri.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > My presumption is that everyone agrees that we'll move to it > > > 'eventually'. does anyone have ideas as to when 'eventually' is? > > > > I thought the advice from Paul was to 'wait awhile' and integrate when > > everything got finished up, which means 'wait awhile' to me. :) > > I was under the impression that there are some fairly important changes in > BIND 8.1.1 This is true, but none of those changes are 'security' or necessary changes for most users. > Couldn't 8.1.1 be made a package/port in the meantime, it would make life > a bit easier for all the isp folks who run FreeBSD. Why? ISP's are *very* safe running BIND 4.9.6, which is the default in all FreeBSD versions except 2.1.X. All of the known security holes are fixed in that version, and it has the advantage of being compatible (setup-wise) with all older versions of BIND in use today. > How many (any?) new users will chose Linux/BSDi/Solaris or whatever else > is now running 8.1.1 by default ? Only those who don't do their homework. There is no need for 8.1.1 for *anyone*, and since it will be changing, it'll be *more* work for them to upgrade to the next version when it comes up since it will also contain new changes, while if they stick with 4.9.6 (or if new bugs are found, 4.9.7, or whatever) until BIND 8 'stabilizes', the upgrade will only require *one* big change, rather than possibly lots of changes as BIND 8 is modified. I'm sure Paul Vixie doesn't want the same thing to happen with BIND that happened with sendmail, so that the sendmail.cf file changed on a regular basis, and that a new version was required every week. I'll bet he wants to get all of the little 'niggly details' shaken out of BIND 8 before calling it *the* new standard, so that's why he's still maintaining Bind 4.9.X for folks. Now, that's not to say that he's unwilling to have you test BIND 8 (cause how else will all the 'niggly details' get shaken out if people don't test it), but it's certainly not required to have a secure system. Nate From owner-freebsd-hackers Tue Nov 25 09:41:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA01407 for hackers-outgoing; Tue, 25 Nov 1997 09:41:16 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA01386 for ; Tue, 25 Nov 1997 09:41:02 -0800 (PST) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 15737 invoked by uid 1001); 25 Nov 1997 17:40:49 +0000 (GMT) To: nate@mt.sri.com Cc: hackers@FreeBSD.ORG Subject: Re: BIND 8.1.1 In-Reply-To: Your message of "Tue, 25 Nov 1997 08:38:50 -0700" References: <199711251538.IAA27156@mt.sri.com> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 25 Nov 1997 18:40:49 +0100 Message-ID: <15735.880479649@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > How many (any?) new users will chose Linux/BSDi/Solaris or whatever else > > is now running 8.1.1 by default ? > > Only those who don't do their homework. There is no need for 8.1.1 for > *anyone*, There may not be much need for 8.1.1 for new users with a reasonably standard configuration. There's certainly a need for 8.1.1 features in many other, more complex configurations. For instance, the ability to only listen to *some* interface addresses is important to many ISPs. > and since it will be changing, it'll be *more* work for them > to upgrade to the next version when it comes up since it will also > contain new changes, while if they stick with 4.9.6 (or if new bugs are > found, 4.9.7, or whatever) until BIND 8 'stabilizes', the upgrade will > only require *one* big change, rather than possibly lots of changes as > BIND 8 is modified. I think you have this wrong. BIND 8 is already sufficiently stable that it runs on several root name servers ({a,c,f,g,i,}.root-servers.net), and in my own "back yard", it is used for one of the authoritative name servers for the 'no' (Norway) domain. We plan to switch one more of the 'no' name servers to 8.1.1 soon. The biggest change is the named.boot -> named.conf change from 4.9.x to 8.1.1. > I'm sure Paul Vixie doesn't want the same thing to happen with BIND that > happened with sendmail, so that the sendmail.cf file changed on a > regular basis, and that a new version was required every week. I'll bet > he wants to get all of the little 'niggly details' shaken out of BIND 8 > before calling it *the* new standard, so that's why he's still > maintaining Bind 4.9.X for folks. AFAIK Paul Vixie/ISC are *not* maintaining 4.9.x in any way except possibly for important security fixes. Paul Vixie has stated publicly that 4.9.6 is the last release in the 4.9.x series. > Now, that's not to say that he's unwilling to have you test BIND 8 > (cause how else will all the 'niggly details' get shaken out if people > don't test it), but it's certainly not required to have a secure system. BIND 8 is not required for security reasons, but may be required for *other* reasons. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-hackers Tue Nov 25 09:47:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA01836 for hackers-outgoing; Tue, 25 Nov 1997 09:47:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA01830 for ; Tue, 25 Nov 1997 09:47:08 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id KAA15925; Tue, 25 Nov 1997 10:47:01 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd015894; Tue Nov 25 10:46:51 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id KAA02503; Tue, 25 Nov 1997 10:46:49 -0700 (MST) From: Terry Lambert Message-Id: <199711251746.KAA02503@usr08.primenet.com> Subject: Re: pthread_cond_timedwait returning wrong error? To: nash@mcs.com Date: Tue, 25 Nov 1997 17:46:48 +0000 (GMT) Cc: bradley@dunn.org, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199711242333.RAA00666@zen.nash.org> from "Alex Nash" at Nov 24, 97 05:33:17 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > While we are talking about threads, any comments on PR-4376? > > You are 100% right about the return value being incorrect. > Unfortunately, this problem is present in many more functions than just > pthread_join(). > > From what I can tell by looking at an old DEC OSF/1 reference on > pthreads, returning -1 an setting errno is the way things used to work. > Apparently POSIX has changed that. Given that "errno" is a global variable, this is actually a good thing. How many times have you wished for: errno = lseek(int fildes, off_t newoffset, int whence, off_t *oldoffset) Or: errno = lseek(int fildes, off_t *offset, int whence) Instead of: off_t lseek(int fildes, off_t offset, int whence) So that you didn't have to worry about the sign bit? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Nov 25 10:01:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA02975 for hackers-outgoing; Tue, 25 Nov 1997 10:01:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA02968 for ; Tue, 25 Nov 1997 10:01:11 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id LAA16957; Tue, 25 Nov 1997 11:01:10 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd016942; Tue Nov 25 11:01:03 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id LAA04173; Tue, 25 Nov 1997 11:01:01 -0700 (MST) From: Terry Lambert Message-Id: <199711251801.LAA04173@usr08.primenet.com> Subject: Re: Status of 650 UART support To: mouth@ibm.net (John Kelly) Date: Tue, 25 Nov 1997 18:01:01 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <347b37fe.5114506@smtp-gw01.ny.us.ibm.net> from "John Kelly" at Nov 25, 97 03:16:18 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Actually, it's possible for DOS machines to be perfectly happy in > >switching interrupt driven input from COM1 (to say a terminal server) > >to COM3 (to say a modem). > > Single tasking DOS will do one or the other, but not both during the > same period of time. The point is not to do both, but to switch, as you say. > >both should remain accessible in the general sense of allowing me > >to close one to open the other (ie: alternate the interrupt programming > >based on the open). > > That might be nice for a casual user, but for the type of FreeBSD use > prevalent, I don't think it has much value, and I would whack it. How about instead of that, if they are shared, it works in this conflict adverse way (ie: only one at a time) and if they're not, it works your way? That way it works, period, instead of not working with the default hardware configuration you get with new commodity machines (as opposed to one you buy from Rod Grimes). Surprisingly, most people run FreeBSD on hardware they have instead of hardware they buy for that purpose, even if you and I aren't in that group. > >> if you want to see it. > > >The more code, the merrier. 8-). > > Bruce said he wasn't particularly interested, but I'm willing to share > my idea with anyone who is. You hadn't described your method, only your reason (hacked hardware) that you felt it should be everyone's method. 8-). Try again, now. > >>I've eliminated all goto statements. > > >The compiler will put the jump instructions back in, anyway > >and all you'll have done is increase the code path by one or > > more tests, slowing the thing down. > > I know the compiler emits jumps but that's beside the point. > > Relentlessly eliminating all goto statements forces me to analyze the > problem to a greater depth, and consistently produces code which is > easier to read and comprehend. I find the same thing from relentlessly removing comments. It forces me to write code that doesn't need comments. But that doesn't mean the trade is worth it. > By organizing well, you won't have many extra tests, and the clock > cycles of those few will be insignificant. The new goto-less code is > usually so much more efficient and well organized that a few extra > test clock cycles are mere drops in a sea of improvement. No clock cycles are insignificant. One long term goal is deadlining based RealTime scheduling. With respect, anal elimination of goto's shows a Pascal as a first language background. This isn't bad, but it does cast a perverse light on the universe. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Nov 25 10:15:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA03953 for hackers-outgoing; Tue, 25 Nov 1997 10:15:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA03943 for ; Tue, 25 Nov 1997 10:15:30 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA02274; Tue, 25 Nov 1997 11:15:29 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA27881; Tue, 25 Nov 1997 11:15:27 -0700 Date: Tue, 25 Nov 1997 11:15:27 -0700 Message-Id: <199711251815.LAA27881@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Nicholas Wright Cc: hackers@freebsd.org Subject: Re: DOES JDK1.1.3 EXIST FOR FreeBSD? In-Reply-To: <199711251537.HAA20712@hub.freebsd.org> References: <199711251537.HAA20712@hub.freebsd.org> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Please reply to me personally, as I do not read this mailing list. No, but folks have stated the the Linux JDK1.1.3 works well under emulation. Nate From owner-freebsd-hackers Tue Nov 25 10:54:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA08414 for hackers-outgoing; Tue, 25 Nov 1997 10:54:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from luomat.peak.org (cc344191-a.ewndsr1.nj.home.com [24.2.83.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA08302; Tue, 25 Nov 1997 10:53:53 -0800 (PST) (envelope-from luomat@luomat.peak.org) Received: (from luomat@localhost) by luomat.peak.org (8.8.8/8.8.8) id NAA01005; Tue, 25 Nov 1997 13:53:54 -0500 (EST) Message-Id: <199711251853.NAA01005@luomat.peak.org> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 4.1mach v148) X-Image-URL: http://www.peak.org/~luomat/next/luomat@peak.org.tiff X-Nextstep-Mailer: Mail 4.1mach (Enhance 2.1) Received: by NeXT.Mailer (1.148.RR) From: Timothy J Luoma Date: Tue, 25 Nov 97 13:53:44 -0500 To: freebsd-chat@freebsd.org, freebsd-current@freebsd.org, freebsd-doc@freebsd.org, freebsd-emulation@freebsd.org, freebsd-hackers@freebsd.org, freebsd-multimedia@freebsd.org, freebsd-ports@freebsd.org, freebsd-questions@freebsd.org, freebsd-stable@freebsd.org Subject: Re: We will mail 4 U cc: spamcomplaints@MCI.NET, SPAM-L@PEACH.EASE.LSOFT.COM Reply-To: SPAM-L@PEACH.EASE.LSOFT.COM X-Image-URL-Disclaimer: hey, it's off my student ID, gimme a break ;-) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk My apologies for the wide-crosspost, I just wanted to save some folks some time. >From searching several phone directories online, it appears that the person who sent this spam did so on behalf of: Jack Luke 39 Panda Av Middleburg, FL 32068-4765 (904) 282-0945 That was the phone number listed in the spam which hit about 8 or 9 times on the FreeBSD lists, and I assume the wider internet as well. Keep in mind that this information might be outdated, but all the reverse phone directories I used came up with this same name. I could not find a real-email address for him in FL by that name, and his name is too common for a general email search (which turned up several matches). Be sure to voice your complaint to MCI, who owned the dialups which were used to send this crap. spamcomplaints@MCI.NET If anyone is near Jack, please feel free to give him a call and pass along our fondest thanks for sending this crap repeatedly to the same addresses. TjL, spam-hater From owner-freebsd-hackers Tue Nov 25 11:12:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA10105 for hackers-outgoing; Tue, 25 Nov 1997 11:12:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA10097 for ; Tue, 25 Nov 1997 11:12:18 -0800 (PST) (envelope-from nash@Jupiter.Mcs.Net) Received: from Jupiter.Mcs.Net (nash@Jupiter.mcs.net [192.160.127.88]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id NAA23862; Tue, 25 Nov 1997 13:12:17 -0600 (CST) Received: from localhost (nash@localhost) by Jupiter.Mcs.Net (8.8.7/8.8.2) with SMTP id NAA04308; Tue, 25 Nov 1997 13:12:16 -0600 (CST) Date: Tue, 25 Nov 1997 13:12:16 -0600 (CST) From: Alex Nash To: Terry Lambert cc: nash@mcs.com, bradley@dunn.org, freebsd-hackers@freebsd.org Subject: Re: pthread_cond_timedwait returning wrong error? In-Reply-To: <199711251746.KAA02503@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 25 Nov 1997, Terry Lambert wrote: > > You are 100% right about the return value being incorrect. > > Unfortunately, this problem is present in many more functions than just > > pthread_join(). > > > > From what I can tell by looking at an old DEC OSF/1 reference on > > pthreads, returning -1 an setting errno is the way things used to work. > > Apparently POSIX has changed that. > > Given that "errno" is a global variable, this is actually a good thing. errno is thread-specific. #define errno (* __error()) Alex From owner-freebsd-hackers Tue Nov 25 11:25:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA10964 for hackers-outgoing; Tue, 25 Nov 1997 11:25:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA10948 for ; Tue, 25 Nov 1997 11:25:16 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (dialin3.anlw.anl.gov [141.221.254.103]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id MAA05915; Tue, 25 Nov 1997 12:25:08 -0700 Date: Tue, 25 Nov 1997 12:24:36 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: Terry Lambert cc: freebsd-hackers@freebsd.org Subject: Re: pthread_cond_timedwait returning wrong error? In-Reply-To: <199711251746.KAA02503@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 25 Nov 1997, Terry Lambert wrote: > > > While we are talking about threads, any comments on PR-4376? > > > > You are 100% right about the return value being incorrect. > > Unfortunately, this problem is present in many more functions than just > > pthread_join(). > > > > From what I can tell by looking at an old DEC OSF/1 reference on > > pthreads, returning -1 an setting errno is the way things used to work. > > Apparently POSIX has changed that. > > Given that "errno" is a global variable, this is actually a good thing. > I was wondering whether maybe errno could be a thread-specific variable rather than global -- mabye via use of a macro. I was looking through libc_r sources, but I couldn't discern what was being done in this regard. To me, having all the *_r reentrant functions is a big nuisance. Charles Mott From owner-freebsd-hackers Tue Nov 25 12:51:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA26760 for hackers-outgoing; Tue, 25 Nov 1997 12:51:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from unicorn.uk1.vbc.net (unicorn.uk1.vbc.net [194.207.2.11]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA26732 for ; Tue, 25 Nov 1997 12:51:02 -0800 (PST) (envelope-from gordon@drogon.net) Received: from localhost (gordon@localhost) by unicorn.uk1.vbc.net (8.8.5/8.8.5) with SMTP id UAA13534; Tue, 25 Nov 1997 20:50:06 GMT Date: Tue, 25 Nov 1997 20:50:06 +0000 (GMT) From: Gordon Henderson X-Sender: gordon@unicorn To: Stephen Roome cc: sthaug@nethelp.no, hackers@FreeBSD.ORG Subject: Re: BIND 8.1.1 In-Reply-To: Message-ID: Distribution: world Organization: Home for lost Drogons MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 25 Nov 1997, Stephen Roome wrote: > On Tue, 25 Nov 1997 sthaug@nethelp.no wrote: > > As far as I know there are no *security* reasons to switch to 8.1.1 - > > the security fixes that are in 8.1.1 are also in 4.9.6. If you switch > > to 8.1.1 you're most likely doing it in order to use some of the new > > functionality in 8.1.1 - but the people who need the new features are > > going to have to tweak the named.conf file anyway. > > If there's no secuity implications then there's no rush, true, and if > no-one else is sending it out by default again, there's no rush. > > But when will it be the default? If there's no bugs (well, no serious ones > that have been found) then why delay ? Converting the zone files from 4.X format to 8.x format might not be a trivial task for some people. True, there is a little perl script which will do the bulk of the work, but for an ISP who acts as secondary for 1000's of their customers zones, they also have to make sure that they can get the information in the right format from their customer! 8.1.1 compiles and installs out of the box on all FreeBSD's I've tried it on and it seems to work well, so I'm sure it will happen, but not right away... Gordon From owner-freebsd-hackers Tue Nov 25 13:02:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA28906 for hackers-outgoing; Tue, 25 Nov 1997 13:02:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA28876 for ; Tue, 25 Nov 1997 13:02:36 -0800 (PST) (envelope-from mrcpu@cdsnet.net) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id NAA15736 for ; Tue, 25 Nov 1997 13:02:25 -0800 (PST) Date: Tue, 25 Nov 1997 13:02:25 -0800 (PST) From: Jaye Mathisen To: hackers@freebsd.org Subject: How many loopback interfaces has anybody successfully used? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Just curious. Had an idea for something, but it would depend on FreeBSD's ability to handle a few thousand or so IP's on loopback aliases. From owner-freebsd-hackers Tue Nov 25 13:16:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA00350 for hackers-outgoing; Tue, 25 Nov 1997 13:16:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from heron.doc.ic.ac.uk (Q9opXqmdf0ohMeYa7vEDxArSO1ZRgwgf@heron.doc.ic.ac.uk [146.169.2.31]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA00345 for ; Tue, 25 Nov 1997 13:16:06 -0800 (PST) (envelope-from njs3@doc.ic.ac.uk) Received: from ash3.doc.ic.ac.uk [146.169.16.31] ([37by/aD7OGPBwpR0L9xF19DF2sRx+Uhr]) by heron.doc.ic.ac.uk with smtp (Exim 1.62 #3) id 0xaSMH-0005JO-00; Tue, 25 Nov 1997 21:17:25 +0000 Received: from njs3 by ash3.doc.ic.ac.uk with local (Exim 1.62 #1) id 0xaSKB-0005Lk-00; Tue, 25 Nov 1997 21:15:15 +0000 From: njs3@doc.ic.ac.uk (Niall Smart) Date: Tue, 25 Nov 1997 21:15:14 +0000 In-Reply-To: Charles Mott "Re: pthread_cond_timedwait returning wrong error?" (Nov 25, 12:24pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Charles Mott , Terry Lambert Subject: Re: pthread_cond_timedwait returning wrong error? Cc: freebsd-hackers@freebsd.org Message-Id: Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Nov 25, 12:24pm, Charles Mott wrote: } Subject: Re: pthread_cond_timedwait returning wrong error? > > To me, having all the *_r reentrant functions is a big nuisance. Yeah, lets invent our own standard! Or maybe we should just leave out threads altogether and stick with badly designed interfaces! Niall From owner-freebsd-hackers Tue Nov 25 14:11:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA06801 for hackers-outgoing; Tue, 25 Nov 1997 14:11:53 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA06770 for ; Tue, 25 Nov 1997 14:11:45 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199711252211.OAA06770@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA115465786; Wed, 26 Nov 1997 09:09:46 +1100 From: Darren Reed Subject: Re: BIND 8.1.1 To: gordon@drogon.net (Gordon Henderson) Date: Wed, 26 Nov 1997 09:09:46 +1100 (EDT) Cc: steve@visint.co.uk, sthaug@nethelp.no, hackers@FreeBSD.ORG In-Reply-To: from "Gordon Henderson" at Nov 25, 97 08:50:06 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Gordon Henderson, sie said: > > Converting the zone files from 4.X format to 8.x format might not be a > trivial task for some people. True, there is a little perl script which > will do the bulk of the work, but for an ISP who acts as secondary for > 1000's of their customers zones, they also have to make sure that they can > get the information in the right format from their customer! Well, it shouldn't take long to write a perl script to convert that information into an entry for BIND 8 if they're already passing you something to plug into the BIND 4 .conf file. Configuration file difference aside, either someone takes the plunge and merges all the BIND 8 features into BIND 4.9.6 (creating a BIND 4.10 or wahtever) and continually updates to match or FreeBSD changes to BIND 8 (a much more sensible idea). Personally, aside from the new parts to the configuration file (which I believe add lots of gnarly new features), I find the new syntax much easier to read and more intuitive. Sure your file might be bigger, but it won't hurt your brain as much. Darren From owner-freebsd-hackers Tue Nov 25 14:15:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA07417 for hackers-outgoing; Tue, 25 Nov 1997 14:15:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from per.plex.nl (SPARCserver.plex.nl [193.67.154.10]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA07377 for ; Tue, 25 Nov 1997 14:15:23 -0800 (PST) (envelope-from jbackus@plex.nl) Received: from jos.mp-c.com (isdn-118.plex.nl [194.229.212.40]) by per.plex.nl (SMI-8.6/SMI-SVR4) id XAA25684; Tue, 25 Nov 1997 23:12:43 +0100 X-Disclaimer: Plex is a public access Internet provider Received: (qmail 2047 invoked by uid 1000); 25 Nov 1997 21:48:29 -0000 Message-ID: <19971125214829.2046.qmail@jos.mp-c.com> To: Stephen Roome cc: sthaug@nethelp.no, hackers@FreeBSD.ORG Subject: Re: BIND 8.1.1 In-reply-to: Your message of "Tue, 25 Nov 1997 12:56:04 GMT." Reply-To: Jos Backus Date: Tue, 25 Nov 1997 22:48:29 +0100 From: Jos Backus Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message you wr ote: >But when will it be the default? If there's no bugs (well, no serious ones >that have been found) then why delay ? Because of the missing noforward patch/functionality, is one reason I can think of. Groetjes, Jos -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ jbackus@plex.nl _/_/ _/_/_/ #include From owner-freebsd-hackers Tue Nov 25 14:20:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA08263 for hackers-outgoing; Tue, 25 Nov 1997 14:20:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from unix.tfs.net (node29.tfs.net [207.2.220.29]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA08222 for ; Tue, 25 Nov 1997 14:20:07 -0800 (PST) (envelope-from jbryant@unix.tfs.net) Received: (from jbryant@localhost) by unix.tfs.net (8.8.7/8.8.5) id QAA23189; Tue, 25 Nov 1997 16:19:56 -0600 (CST) From: Jim Bryant Message-Id: <199711252219.QAA23189@unix.tfs.net> Subject: Re: We will mail 4 U In-Reply-To: <199711251853.NAA01005@luomat.peak.org> from Timothy J Luoma at "Nov 25, 97 01:53:44 pm" To: SPAM-L@PEACH.EASE.LSOFT.COM Date: Tue, 25 Nov 1997 16:19:55 -0600 (CST) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@unix.tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply: > My apologies for the wide-crosspost, I just wanted to save some folks some time. > > >From searching several phone directories online, it appears that the person > who sent this spam did so on behalf of: > > Jack Luke > 39 Panda Av > Middleburg, FL 32068-4765 > (904) 282-0945 > > That was the phone number listed in the spam which hit about 8 or 9 times on > the FreeBSD lists, and I assume the wider internet as well. apparently, the phone number is not Jack's nor has it ever been... it appears to be a company in the same city though, and they say that 39 Panda Ave is a residential address. i referred them to call MCI to complain, as well as to call their congresscritter in support of H.R. 1748... I don't know if anyone else has called the number, but i did tell them that at least a few million mailings went out with their phone number on it [given that it hit this list more than once]. 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+ From owner-freebsd-hackers Tue Nov 25 14:24:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA08871 for hackers-outgoing; Tue, 25 Nov 1997 14:24:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA08846 for ; Tue, 25 Nov 1997 14:24:46 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (dialin3.anlw.anl.gov [141.221.254.103]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id PAA06380; Tue, 25 Nov 1997 15:24:38 -0700 Date: Tue, 25 Nov 1997 15:24:05 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: Niall Smart cc: hackers@freebsd.org Subject: Re: pthread_cond_timedwait returning wrong error? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 25 Nov 1997, Niall Smart wrote: > On Nov 25, 12:24pm, Charles Mott wrote: > } Subject: Re: pthread_cond_timedwait returning wrong error? > > > > To me, having all the *_r reentrant functions is a big nuisance. > > Yeah, lets invent our own standard! Or maybe we should just leave out > threads altogether and stick with badly designed interfaces! > > Niall I quess I was referring to the *_r functions on Solaris that I don't see anywhere else. Are these standard? I think having the standard Unix function calls with hidden thread addaptations like the errno solution (mapping errno to a function) explained by Alex Nash seems like a good idea to me. What I have observed from Solaris, FreeBSD, Linux and OSF is that there doesn't seem to be any standard that is obvious to me. Even OSF 3.2 and 4.0 are different from each other. This is a major source of annoyance if one is trying to develop software which will cleanly compile accross different platforms. Charles Mott From owner-freebsd-hackers Tue Nov 25 14:28:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA09477 for hackers-outgoing; Tue, 25 Nov 1997 14:28:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA09457 for ; Tue, 25 Nov 1997 14:28:16 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id IAA00304; Tue, 25 Nov 1997 08:43:15 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp01.primenet.com, id smtpd000288; Tue Nov 25 08:43:11 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id PAA28520; Tue, 25 Nov 1997 15:27:30 -0700 (MST) From: Terry Lambert Message-Id: <199711252227.PAA28520@usr05.primenet.com> Subject: Re: pthread_cond_timedwait returning wrong error? To: cmott@srv.net (Charles Mott) Date: Tue, 25 Nov 1997 22:27:30 +0000 (GMT) Cc: tlambert@primenet.com, freebsd-hackers@freebsd.org In-Reply-To: from "Charles Mott" at Nov 25, 97 12:24:36 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > From what I can tell by looking at an old DEC OSF/1 reference on > > > pthreads, returning -1 an setting errno is the way things used to work. > > > Apparently POSIX has changed that. > > > > Given that "errno" is a global variable, this is actually a good thing. > > > > I was wondering whether maybe errno could be a thread-specific variable > rather than global -- mabye via use of a macro. I was looking through > libc_r sources, but I couldn't discern what was being done in this regard. It's really thread specific, not global. But this means that it's useless for returning status between threads. The old POSIX had it as a global, and not per thread. It seems they fixed the problem two ways. > To me, having all the *_r reentrant functions is a big nuisance. Sorry; blame POSIX again, for mandating static user data areas for function returns. The *_r functions are supposed to fix that by making the functions use user buffers, etc.. POSIX needs to unify itself. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Nov 25 14:43:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA11877 for hackers-outgoing; Tue, 25 Nov 1997 14:43:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA11848; Tue, 25 Nov 1997 14:43:03 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id IAA02035; Tue, 25 Nov 1997 08:58:09 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp01.primenet.com, id smtpd002021; Tue Nov 25 08:58:00 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id PAA29439; Tue, 25 Nov 1997 15:42:16 -0700 (MST) From: Terry Lambert Message-Id: <199711252242.PAA29439@usr05.primenet.com> Subject: Re: Compiler Bug??? To: shimon@simon-shapiro.org Date: Tue, 25 Nov 1997 22:42:15 +0000 (GMT) Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, freebsd-smp@freebsd.org In-Reply-To: from "Simon Shapiro" at Nov 24, 97 09:13:36 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Boot SMP again. Compile and run Xcoral 3.1. Pretty cool editor and > finally can do ``normal'' cut-n-paste, etc. So I set its geometry in > .Xdefaults to =200x400. Nope. Will not chnge size. > > I modify parse.c to have the ugly printf you see below: > > flags = XParseGeometry ( buf, &x, &y, &width, &he > (void)fprintf(stderr, "%s.%d: x = %d, y = %d, w = %d, h =%d\n", > __FILE__, __LINE__, x, y, width, height); > > It says: > > parse.c.843: x = -272640524, y = 537577259, w = 200, h = 400 > > (x, y are corrdinates which are unspecified, which is OK to look this > ugly) > > Size is still huge (about 600x800). [ ... add more printf()'s ... ] > Guess what? The window now has the specified geometry! This one looks like timing. You probably need to call Xsync() to ensure the GC is written before you use it, or that the attributes are set before you map the window, etc.. Common X programmer pilot error. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Nov 25 14:50:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA13058 for hackers-outgoing; Tue, 25 Nov 1997 14:50:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA13029; Tue, 25 Nov 1997 14:50:25 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id PAA29120; Tue, 25 Nov 1997 15:50:22 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpd029102; Tue Nov 25 15:50:13 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id PAA29727; Tue, 25 Nov 1997 15:50:06 -0700 (MST) From: Terry Lambert Message-Id: <199711252250.PAA29727@usr05.primenet.com> Subject: Re: BIND 8.1.1 To: nate@mt.sri.com (Nate Williams) Date: Tue, 25 Nov 1997 22:50:06 +0000 (GMT) Cc: steve@visint.co.uk, nate@mt.sri.com, julian@whistle.com, hackers@FreeBSD.ORG, peter@FreeBSD.ORG In-Reply-To: <199711251538.IAA27156@mt.sri.com> from "Nate Williams" at Nov 25, 97 08:38:50 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > How many (any?) new users will chose Linux/BSDi/Solaris or whatever else > > is now running 8.1.1 by default ? > > Only those who don't do their homework. There is no need for 8.1.1 for > *anyone*, and since it will be changing, it'll be *more* work for them > to upgrade to the next version when it comes up since it will also > contain new changes, while if they stick with 4.9.6 (or if new bugs are > found, 4.9.7, or whatever) until BIND 8 'stabilizes', the upgrade will > only require *one* big change, rather than possibly lots of changes as > BIND 8 is modified. > > I'm sure Paul Vixie doesn't want the same thing to happen with BIND that > happened with sendmail, so that the sendmail.cf file changed on a > regular basis, and that a new version was required every week. I'll bet > he wants to get all of the little 'niggly details' shaken out of BIND 8 > before calling it *the* new standard, so that's why he's still > maintaining Bind 4.9.X for folks. Last time I talked to him about it, he said that there will be no further developement on 4.9.X after X==6. This was about a month and a half ago. The big pain on an 8.x upgrade is the config file format has changed (there's good reasons for this, though it remains annoying no matter how good the reasons). The changeover will have to be eaten at some point; better to do it while there are existing conversion scripts, IMO; how smooth would an upgrade from 1.1.5.1 to -current be today? 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Nov 25 14:56:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA13986 for hackers-outgoing; Tue, 25 Nov 1997 14:56:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA13956 for ; Tue, 25 Nov 1997 14:56:25 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id JAA00387; Wed, 26 Nov 1997 09:21:50 +1030 (CST) Message-Id: <199711252251.JAA00387@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Jaye Mathisen cc: hackers@freebsd.org Subject: Re: How many loopback interfaces has anybody successfully used? In-reply-to: Your message of "Tue, 25 Nov 1997 13:02:25 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Nov 1997 09:21:50 +1030 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Just curious. Had an idea for something, but it would depend on FreeBSD's > ability to handle a few thousand or so IP's on loopback aliases. Definitely no problem. Just stack 'em up. 8) mike From owner-freebsd-hackers Tue Nov 25 15:26:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA16123 for hackers-outgoing; Tue, 25 Nov 1997 15:26:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA16015; Tue, 25 Nov 1997 15:26:02 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id JAA07735; Tue, 25 Nov 1997 09:40:35 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp01.primenet.com, id smtpd007685; Tue Nov 25 09:40:28 1997 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA02240; Tue, 25 Nov 1997 16:24:36 -0700 (MST) From: Terry Lambert Message-Id: <199711252324.QAA02240@usr05.primenet.com> Subject: Re: We will mail 4 U To: SPAM-L@PEACH.EASE.LSOFT.COM Date: Tue, 25 Nov 1997 23:24:35 +0000 (GMT) Cc: freebsd-chat@freebsd.org, freebsd-current@freebsd.org, freebsd-doc@freebsd.org, freebsd-emulation@freebsd.org, freebsd-hackers@freebsd.org, freebsd-multimedia@freebsd.org, freebsd-ports@freebsd.org, freebsd-questions@freebsd.org, freebsd-stable@freebsd.org, spamcomplaints@MCI.NET In-Reply-To: <199711251853.NAA01005@luomat.peak.org> from "Timothy J Luoma" at Nov 25, 97 01:53:44 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > From searching several phone directories online, it appears that the person > who sent this spam did so on behalf of: > > Jack Luke > 39 Panda Av > Middleburg, FL 32068-4765 > (904) 282-0945 It is pretty obvious (to me, anyway) that this is a targetted trojan of the type that was used to flood ml.org. Also, you will note that the putative "relay host" is running a highly hacked version of sendmail (EHLO it). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Nov 25 15:35:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA17121 for hackers-outgoing; Tue, 25 Nov 1997 15:35:54 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA17116 for ; Tue, 25 Nov 1997 15:35:51 -0800 (PST) (envelope-from karl@Mars.mcs.net) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id RAA16430; Tue, 25 Nov 1997 17:35:02 -0600 (CST) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id RAA20087; Tue, 25 Nov 1997 17:35:01 -0600 (CST) Message-ID: <19971125173501.09696@mcs.net> Date: Tue, 25 Nov 1997 17:35:01 -0600 From: Karl Denninger To: Darren Reed Cc: Gordon Henderson , steve@visint.co.uk, sthaug@nethelp.no, hackers@freebsd.org Subject: Re: BIND 8.1.1 References: <199711252211.OAA06770@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199711252211.OAA06770@hub.freebsd.org>; from Darren Reed on Wed, Nov 26, 1997 at 09:09:46AM +1100 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, Nov 26, 1997 at 09:09:46AM +1100, Darren Reed wrote: > In some mail from Gordon Henderson, sie said: > > > > Converting the zone files from 4.X format to 8.x format might not be a > > trivial task for some people. True, there is a little perl script which > > will do the bulk of the work, but for an ISP who acts as secondary for > > 1000's of their customers zones, they also have to make sure that they can > > get the information in the right format from their customer! > > Well, it shouldn't take long to write a perl script to convert that > information into an entry for BIND 8 if they're already passing you > something to plug into the BIND 4 .conf file. > > Configuration file difference aside, either someone takes the plunge > and merges all the BIND 8 features into BIND 4.9.6 (creating a BIND > 4.10 or wahtever) and continually updates to match or FreeBSD changes > to BIND 8 (a much more sensible idea). > > Personally, aside from the new parts to the configuration file (which > I believe add lots of gnarly new features), I find the new syntax much > easier to read and more intuitive. Sure your file might be bigger, > but it won't hurt your brain as much. > > Darren Its a one-time changeover. We made it months ago, and have never regretted it. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex support on ALL modems Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost From owner-freebsd-hackers Tue Nov 25 15:38:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA17333 for hackers-outgoing; Tue, 25 Nov 1997 15:38:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA17328 for ; Tue, 25 Nov 1997 15:38:21 -0800 (PST) (envelope-from abial@korin.warman.org.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.8/8.8.5) with SMTP id AAA12999 for ; Wed, 26 Nov 1997 00:40:54 +0100 (CET) Date: Wed, 26 Nov 1997 00:40:53 +0100 (CET) From: Andrzej Bialecki To: freebsd-hackers@FreeBSD.ORG Subject: Screen/font related questions... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi! Could somebody explain me in a few words what screenmaps are for? I'd read the manpage but it's nonexistent... When should/can I use them? And related question (perhaps to ache): part of ISO_8859-2 characters overlaps with semigraphics, which gives very ugly look to every program that uses line-drawing characters... Can I do something to avoid this? (perhaps unicode, if FreeBSD supports unicode {which is another interesting question}). Andrzej Bialecki ---------------------+--------------------------------------------------------- abial@warman.org.pl | if(halt_per_mth > 0) { fetch("http://www.freebsd.org") } Research & Academic | "Be open-minded, but don't let your brains to fall out." Network in Poland | All of the above (and more) is just my personal opinion. ---------------------+--------------------------------------------------------- From owner-freebsd-hackers Tue Nov 25 15:50:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA18005 for hackers-outgoing; Tue, 25 Nov 1997 15:50:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from monk.via.net (monk.via.net [140.174.204.10]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA17997 for ; Tue, 25 Nov 1997 15:50:42 -0800 (PST) (envelope-from joe@via.net) Received: (from joe@localhost) by monk.via.net (8.6.11/8.6.12) id PAA27977; Tue, 25 Nov 1997 15:39:48 -0800 Date: Tue, 25 Nov 1997 15:39:48 -0800 From: Joe McGuckin Message-Id: <199711252339.PAA27977@monk.via.net> To: gordon@drogon.net Subject: Re: BIND 8.1.1 Cc: hackers@FreeBSD.ORG X-Sun-Charset: US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Converting the zone files from 4.X format to 8.x format might not be a >trivial task for some people. True, there is a little perl script which >will do the bulk of the work, but for an ISP who acts as secondary for >1000's of their customers zones, they also have to make sure that they can >get the information in the right format from their customer! >8.1.1 compiles and installs out of the box on all FreeBSD's I've tried it >on and it seems to work well, so I'm sure it will happen, but not right >away... I wrote a perl script to convert the named.boot into the proper format for named.conf. No big deal. It took about 15 minutes. From owner-freebsd-hackers Tue Nov 25 15:56:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA18461 for hackers-outgoing; Tue, 25 Nov 1997 15:56:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA18449 for ; Tue, 25 Nov 1997 15:55:57 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id PAA23788; Tue, 25 Nov 1997 15:44:25 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd023779; Tue Nov 25 15:44:21 1997 Message-ID: <347B6251.41C67EA6@whistle.com> Date: Tue, 25 Nov 1997 15:42:09 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: nash@mcs.com CC: cbray@best.com, freebsd-hackers@freebsd.org Subject: Re: malloc() problems in children after using rfork() References: <199711220154.TAA05968@zen.nash.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk nash@mcs.net wrote: > > On 21 Nov, Julian Elischer wrote: > >> The only locking malloc() performs is pthread_mutex_lock/unlock in the > >> libc_r version. The non-threaded version provides no locking at all. > [...] > > I just saw the other email > > > > he's using 2.2.5 > > rfmem don't work in 2.2.x. > > well it DOES but it only shares EXISTING memory. > > new allocations are not shared.. > > and in a subsequent email... > > > New allocations from the kernel (done after the rfork) > > are not shared.. > > this was fixed in -current but I'm pretty sure john has not back-ported > > it. > > Unless I'm missing something, even if the fix was brought into -stable > it still won't allow multiple rforked(RFMEM|RFPROC) processes to malloc > out of a shared data segment (without locking, of course). > > Alex of course you are right, and I'm not sure of the locking state of malloc. I do belive SOME work was done on it but I don't know if it was completed. From owner-freebsd-hackers Tue Nov 25 15:56:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA18582 for hackers-outgoing; Tue, 25 Nov 1997 15:56:18 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA18566 for ; Tue, 25 Nov 1997 15:56:11 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id PAA23874; Tue, 25 Nov 1997 15:47:15 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd023868; Tue Nov 25 15:47:13 1997 Message-ID: <347B62FD.167EB0E7@whistle.com> Date: Tue, 25 Nov 1997 15:45:01 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Charles Mott CC: Terry Lambert , freebsd-hackers@freebsd.org Subject: Re: pthread_cond_timedwait returning wrong error? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Charles Mott wrote: > > On Tue, 25 Nov 1997, Terry Lambert wrote: > > > > While we are talking about threads, any comments on PR-4376? > > > > > > You are 100% right about the return value being incorrect. > > > Unfortunately, this problem is present in many more functions than just > > > pthread_join(). > > > > > > From what I can tell by looking at an old DEC OSF/1 reference on > > > pthreads, returning -1 an setting errno is the way things used to work. > > > Apparently POSIX has changed that. > > > > Given that "errno" is a global variable, this is actually a good thing. > > > > I was wondering whether maybe errno could be a thread-specific variable > rather than global -- mabye via use of a macro. I was looking through > libc_r sources, but I couldn't discern what was being done in this regard. > > To me, having all the *_r reentrant functions is a big nuisance. > > Charles Mott errno is defined in threads systems as: errno[thread_number] or similar tricks.. From owner-freebsd-hackers Tue Nov 25 16:04:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA19418 for hackers-outgoing; Tue, 25 Nov 1997 16:04:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA19379 for ; Tue, 25 Nov 1997 16:03:59 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id PAA24277; Tue, 25 Nov 1997 15:56:15 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd024259; Tue Nov 25 15:56:08 1997 Message-ID: <347B6515.2781E494@whistle.com> Date: Tue, 25 Nov 1997 15:53:57 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Jaye Mathisen CC: hackers@freebsd.org Subject: Re: How many loopback interfaces has anybody successfully used? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk we have used systems with lo0 and lo1 I don't know of any reason it wouldn't work with more.. Jaye Mathisen wrote: > > Just curious. Had an idea for something, but it would depend on FreeBSD's > ability to handle a few thousand or so IP's on loopback aliases. From owner-freebsd-hackers Tue Nov 25 16:23:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA20987 for hackers-outgoing; Tue, 25 Nov 1997 16:23:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA20974 for ; Tue, 25 Nov 1997 16:23:09 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id QAA18659; Tue, 25 Nov 1997 16:22:22 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma018653; Tue Nov 25 16:22:08 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id QAA03526; Tue, 25 Nov 1997 16:22:08 -0800 (PST) From: Archie Cobbs Message-Id: <199711260022.QAA03526@bubba.whistle.com> Subject: Re: BIND 8.1.1 In-Reply-To: from Gordon Henderson at "Nov 25, 97 08:50:06 pm" To: gordon@drogon.net (Gordon Henderson) Date: Tue, 25 Nov 1997 16:22:08 -0800 (PST) Cc: steve@visint.co.uk, sthaug@nethelp.no, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Gordon Henderson writes: > On Tue, 25 Nov 1997, Stephen Roome wrote: > > On Tue, 25 Nov 1997 sthaug@nethelp.no wrote: > > > As far as I know there are no *security* reasons to switch to 8.1.1 - > > > the security fixes that are in 8.1.1 are also in 4.9.6. If you switch > > > to 8.1.1 you're most likely doing it in order to use some of the new > > > functionality in 8.1.1 - but the people who need the new features are > > > going to have to tweak the named.conf file anyway. > > > > If there's no secuity implications then there's no rush, true, and if > > no-one else is sending it out by default again, there's no rush. > > > > But when will it be the default? If there's no bugs (well, no serious ones > > that have been found) then why delay ? > > Converting the zone files from 4.X format to 8.x format might not be a > trivial task for some people. True, there is a little perl script which > will do the bulk of the work, but for an ISP who acts as secondary for > 1000's of their customers zones, they also have to make sure that they can > get the information in the right format from their customer! I thought that 8.x config files were different, but the zone file format was the same.. am I mistaken? Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Tue Nov 25 16:45:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA22932 for hackers-outgoing; Tue, 25 Nov 1997 16:45:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA22921 for ; Tue, 25 Nov 1997 16:45:31 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id QAA18747; Tue, 25 Nov 1997 16:34:22 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma018745; Tue Nov 25 16:34:06 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id QAA03557; Tue, 25 Nov 1997 16:34:06 -0800 (PST) From: Archie Cobbs Message-Id: <199711260034.QAA03557@bubba.whistle.com> Subject: Re: Upgrade function and root dir In-Reply-To: <199711220847.AAA12954@Gatekeeper.Alameda.net> from Ulf Zimmermann at "Nov 22, 97 00:47:59 am" To: ulf@Alameda.net (Ulf Zimmermann) Date: Tue, 25 Nov 1997 16:34:06 -0800 (PST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ulf Zimmermann writes: > Would it be possible to change the upgrade function, so that is not > necessary overwrites the dot files in /root ? I always save it, but > it would be one step less ;-) Yeah! Me too. Just save them as .cshrc.old, etc. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Tue Nov 25 16:50:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA23399 for hackers-outgoing; Tue, 25 Nov 1997 16:50:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA23383 for ; Tue, 25 Nov 1997 16:50:02 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id LAA01546; Wed, 26 Nov 1997 11:15:26 +1030 (CST) Message-Id: <199711260045.LAA01546@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: warpy cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Possible problem with ftpd 6.00 In-reply-to: Your message of "Tue, 25 Nov 1997 09:58:56 +1100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Nov 1997 11:15:25 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk (redirected to -hackers, as this is not really appropriate for -security) > This morning I noticed something I didn't think should be happening. That > being the password being used by an anonymous user logging into ftp > showing up in the process list. This is intentional, as it provides a possibly useful piece of information. > However this did not happen when I logged > in as a normal user. Obviously there isn't much upon first glance that can > be done to exploit it (at least I think so), but does it need to occur at > all? What possible problems can you see with it? mike From owner-freebsd-hackers Tue Nov 25 16:57:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA24148 for hackers-outgoing; Tue, 25 Nov 1997 16:57:28 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from omnivax (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA24141 for ; Tue, 25 Nov 1997 16:57:11 -0800 (PST) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id TAA03805; Tue, 25 Nov 1997 19:30:21 -0500 From: Bill Paul Message-Id: <199711260030.TAA03805@skynet.ctr.columbia.edu> Subject: Re: BIND 8.1.1 To: gordon@drogon.net (Gordon Henderson) Date: Tue, 25 Nov 1997 19:30:19 -0500 (EST) Cc: hackers@freebsd.org In-Reply-To: from "Gordon Henderson" at Nov 25, 97 08:50:06 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the towns in all the world, Gordon Henderson had to walk into mine and say: > On Tue, 25 Nov 1997, Stephen Roome wrote: > > > On Tue, 25 Nov 1997 sthaug@nethelp.no wrote: > > > As far as I know there are no *security* reasons to switch to 8.1.1 - > > > the security fixes that are in 8.1.1 are also in 4.9.6. If you switch > > > to 8.1.1 you're most likely doing it in order to use some of the new > > > functionality in 8.1.1 - but the people who need the new features are > > > going to have to tweak the named.conf file anyway. > > > > If there's no secuity implications then there's no rush, true, and if > > no-one else is sending it out by default again, there's no rush. > > > > But when will it be the default? If there's no bugs (well, no serious ones > > that have been found) then why delay ? Consider for a moment that BIND includes more than just named and named-xfer. There's also the client side resolver code, which needs to be merged correctly into libc. In BIND 8.x, this is complicated by the addition of IRS, the Information Retrieval System. (Don't be alarmed if you've never noticed the irs directory in the BIND 8.x source distribution before; I think even the implementors have forgotten about it, to the point where they forgot to include an irs.conf(5) man page until I asked about it on Usenet. :) IRS is more or less the same thing as Sun's Name Service Switch, which is part of Solaris 2.x. For those who don't know, in Solaris you have a file called /etc/nsswitch.conf where you can specify things like: passwd: files nis nisplus group: files nis nisplus hosts: files dns This controls how the various getXXXbyname()/getXXXbyaddr()/getXXXent() routines behave. For the 'hosts' case, gethostbyname(3) will first search the /etc/hosts files, then, if that doesn't procude a match, it will do a DNS lookup. If that in turn doesn't pan out, you get back an error. IRS is similar in concept but a bit different in implementation: with Sun's Name Service Switch, lookup methods are implemented as shared objects (.so files) which can be dlopen()ed on the fly, thereby allowing user-defined methods to be added without recompiling. IRS doesn't support this: if you want to add a new method, you have to recompile libbind (or libc, if the code is merged). If you have binaries linked statically with libbind, then you have to recompile those too. IRS could probably be modified to support the shared object approach, though care must be taken to insure that it would work correctly with statically linked objects (with older FreeBSD releases, it wasn't possible to use dlopen()/dlsym() and friends in a statically linked executable). I for one want IRS because it will make adding support for NIS+ (and maybe LDAP or, dare I say it, NDS) much easier, but incorporating it will take a lot of work since it will require modifying a lot of src/lib/libc/gen, possibly scrapping much of the getXXXent.c modules in favor of the IRS equivalents. This in turn requires lots of testing to make sure nothing gets horribly screwed up and that no existing functionality is lost. Before somebody brings it up, yes I know the GNU libc (and hence Linux) contains a name service switch implementation. I'd rather have IRS. 'Nuff said. > Converting the zone files from 4.X format to 8.x format might not be a > trivial task for some people. True, there is a little perl script which > will do the bulk of the work, but for an ISP who acts as secondary for > 1000's of their customers zones, they also have to make sure that they can > get the information in the right format from their customer! I do a small amount of secondary service; the conversion script seemed to do the right thing for me when I switched to 8.1.1. I'm a bit confused here though: the _named config_ file format has changed, but the _zone file_ format shouldn't have. The 8.1.1 named liked my 4.9.6 zone files just fine. Maybe I lead a charmed life. > 8.1.1 compiles and installs out of the box on all FreeBSD's I've tried it > on and it seems to work well, so I'm sure it will happen, but not right > away... I run it on SunOS 4.1.3 myself. Seems a bit less of a memory hog than 4.9.6. Again, I'm not so much worried about switching named/named-xfer as I am about merging the client side code into libc. I'm pretty sure this is Peter Wemm's department. I'm also pretty sure he'd rather it wasn't. :) -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= From owner-freebsd-hackers Tue Nov 25 17:01:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA24533 for hackers-outgoing; Tue, 25 Nov 1997 17:01:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from lsd.relcom.eu.net (lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA24524 for ; Tue, 25 Nov 1997 17:01:18 -0800 (PST) (envelope-from ache@lsd.relcom.eu.net) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.8/8.8.8) id EAA29118; Wed, 26 Nov 1997 04:00:55 +0300 (MSK) (envelope-from ache) Date: Wed, 26 Nov 1997 04:00:51 +0300 (MSK) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: Andrzej Bialecki cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Screen/font related questions... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 26 Nov 1997, Andrzej Bialecki wrote: > And related question (perhaps to ache): part of ISO_8859-2 characters > overlaps with semigraphics, which gives very ugly look to every program > that uses line-drawing characters... It is impossible if all tuned properly, all programs fetch semigraphics from termcap entry. Usually it means that you use wrong TERM value, not 8859-2 one (I don't remember if Latin2 termcap entry actually exist, but Latin1 exist for shure). If Latin2 termcap entry not exist, it should be added. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-hackers Tue Nov 25 17:02:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA24714 for hackers-outgoing; Tue, 25 Nov 1997 17:02:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA24705 for ; Tue, 25 Nov 1997 17:02:30 -0800 (PST) (envelope-from nash@Mercury.mcs.net) Received: from Mercury.mcs.net (nash@Mercury.mcs.net [192.160.127.80]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id TAA26481; Tue, 25 Nov 1997 19:02:07 -0600 (CST) Received: from localhost (nash@localhost) by Mercury.mcs.net (8.8.7/8.8.2) with SMTP id TAA16650; Tue, 25 Nov 1997 19:02:07 -0600 (CST) Date: Tue, 25 Nov 1997 19:02:06 -0600 (CST) From: Alex Nash To: julian@whistle.com cc: cbray@best.com, freebsd-hackers@freebsd.org Subject: Re: malloc() problems in children after using rfork() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 25 Nov, Julian Elischer wrote: >> Unless I'm missing something, even if the fix was brought into -stable >> it still won't allow multiple rforked(RFMEM|RFPROC) processes to malloc >> out of a shared data segment (without locking, of course). > > of course you are right, and I'm not sure of the locking state of > malloc. > > I do belive SOME work was done on it but I don't > know if it was completed. malloc uses pthread_mutex_lock/pthread_mutex_unlock in libc_r, but no locking is performed in libc. I recall phk talking about making malloc safe from signal handlers (because some program(s) were invoking malloc in signal handlers), but deciding against the overhead that would be necessary to do so. Alex From owner-freebsd-hackers Tue Nov 25 17:14:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA25713 for hackers-outgoing; Tue, 25 Nov 1997 17:14:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA25684 for ; Tue, 25 Nov 1997 17:14:37 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id BAA23284; Wed, 26 Nov 1997 01:13:39 GMT Date: Wed, 26 Nov 1997 10:13:38 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: nash@mcs.com, bradley@dunn.org, freebsd-hackers@FreeBSD.ORG Subject: Re: pthread_cond_timedwait returning wrong error? In-Reply-To: <199711251746.KAA02503@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 25 Nov 1997, Terry Lambert wrote: > > From what I can tell by looking at an old DEC OSF/1 reference on > > pthreads, returning -1 an setting errno is the way things used to work. > > Apparently POSIX has changed that. > > Given that "errno" is a global variable, this is actually a good thing. This would give you some nasty races to deal with, it'd be a nightmare. Mike Hancock From owner-freebsd-hackers Tue Nov 25 17:14:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA25721 for hackers-outgoing; Tue, 25 Nov 1997 17:14:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: (from jmb@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA25617; Tue, 25 Nov 1997 17:14:10 -0800 (PST) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199711260114.RAA25617@hub.freebsd.org> Subject: Re: We will mail 4 U To: tlambert@primenet.com (Terry Lambert) Date: Tue, 25 Nov 1997 17:14:10 -0800 (PST) Cc: SPAM-L@PEACH.EASE.LSOFT.COM, freebsd-chat@freebsd.org, freebsd-current@freebsd.org, freebsd-doc@freebsd.org, freebsd-emulation@freebsd.org, freebsd-hackers@freebsd.org, freebsd-multimedia@freebsd.org, freebsd-ports@freebsd.org, freebsd-questions@freebsd.org, freebsd-stable@freebsd.org, spamcomplaints@MCI.NET In-Reply-To: <199711252324.QAA02240@usr05.primenet.com> from "Terry Lambert" at Nov 25, 97 11:24:35 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > > > From searching several phone directories online, it appears that the person > > who sent this spam did so on behalf of: > > > > Jack Luke > > 39 Panda Av > > Middleburg, FL 32068-4765 > > (904) 282-0945 > > It is pretty obvious (to me, anyway) that this is a targetted trojan of > the type that was used to flood ml.org. > > Also, you will note that the putative "relay host" is running a highly > hacked version of sendmail (EHLO it). > "hacked version of sendmail" ????? EHLO is standard esmtp. this is old stuff already. see the rfc's (rfc1825 perhaps) two relay hosts were the ns servers for amgen.com. why are nameservers configured to relay mail? jmb From owner-freebsd-hackers Tue Nov 25 17:26:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA26783 for hackers-outgoing; Tue, 25 Nov 1997 17:26:43 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cheops.anu.edu.au (daemon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA26772 for ; Tue, 25 Nov 1997 17:26:35 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199711260126.RAA26772@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA152636138; Wed, 26 Nov 1997 12:02:18 +1100 From: Darren Reed Subject: Re: BIND 8.1.1 To: archie@whistle.com (Archie Cobbs) Date: Wed, 26 Nov 1997 12:02:17 +1100 (EDT) Cc: gordon@drogon.net, steve@visint.co.uk, sthaug@nethelp.no, hackers@FreeBSD.ORG In-Reply-To: <199711260022.QAA03526@bubba.whistle.com> from "Archie Cobbs" at Nov 25, 97 04:22:08 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Archie Cobbs, sie said: > > > Converting the zone files from 4.X format to 8.x format might not be a > > trivial task for some people. True, there is a little perl script which > > will do the bulk of the work, but for an ISP who acts as secondary for > > 1000's of their customers zones, they also have to make sure that they can > > get the information in the right format from their customer! > > I thought that 8.x config files were different, but the zone file > format was the same.. am I mistaken? No. From owner-freebsd-hackers Tue Nov 25 17:28:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA26975 for hackers-outgoing; Tue, 25 Nov 1997 17:28:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: (from jmb@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA25617; Tue, 25 Nov 1997 17:14:10 -0800 (PST) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199711260114.RAA25617@hub.freebsd.org> Subject: Re: We will mail 4 U To: tlambert@primenet.com (Terry Lambert) Date: Tue, 25 Nov 1997 17:14:10 -0800 (PST) Cc: SPAM-L@PEACH.EASE.LSOFT.COM, freebsd-chat@freebsd.org, freebsd-current@freebsd.org, freebsd-doc@freebsd.org, freebsd-emulation@freebsd.org, freebsd-hackers@freebsd.org, freebsd-multimedia@freebsd.org, freebsd-ports@freebsd.org, freebsd-questions@freebsd.org, freebsd-stable@freebsd.org, spamcomplaints@MCI.NET In-Reply-To: <199711252324.QAA02240@usr05.primenet.com> from "Terry Lambert" at Nov 25, 97 11:24:35 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > > > From searching several phone directories online, it appears that the person > > who sent this spam did so on behalf of: > > > > Jack Luke > > 39 Panda Av > > Middleburg, FL 32068-4765 > > (904) 282-0945 > > It is pretty obvious (to me, anyway) that this is a targetted trojan of > the type that was used to flood ml.org. > > Also, you will note that the putative "relay host" is running a highly > hacked version of sendmail (EHLO it). > "hacked version of sendmail" ????? EHLO is standard esmtp. this is old stuff already. see the rfc's (rfc1825 perhaps) two relay hosts were the ns servers for amgen.com. why are nameservers configured to relay mail? jmb From owner-freebsd-hackers Tue Nov 25 17:30:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA27394 for hackers-outgoing; Tue, 25 Nov 1997 17:30:26 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA27384 for ; Tue, 25 Nov 1997 17:30:20 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id RAA27570 for ; Tue, 25 Nov 1997 17:23:52 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd027566; Tue Nov 25 17:23:46 1997 Date: Tue, 25 Nov 1997 17:21:35 -0800 (PST) From: Julian Elischer To: hackers@freebsd.org Subject: New syscall on -stable!?! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I did a 'make world' today in a chroot environment on a 2.2.5 (approx) machine.. The source was checked out to RELENG_2_2 Half way through the install things started failing with sig12. Has someone changed the libraries and included a -current syscall? (or did my cvs checkout get the wrong sources somewhere?) I'm redoing the checkout but I'm pretty sure I got it right. it was checked out around 00:00 GMT on the 25th. thoughts? julian From owner-freebsd-hackers Tue Nov 25 17:40:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA28449 for hackers-outgoing; Tue, 25 Nov 1997 17:40:51 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nomis.Simon-Shapiro.ORG (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA28407 for ; Tue, 25 Nov 1997 17:40:40 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 528 invoked by uid 1000); 26 Nov 1997 01:40:48 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-111797 [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: <199711251538.IAA27156@mt.sri.com> Date: Tue, 25 Nov 1997 17:40:48 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: Me, Just me... From: Simon Shapiro To: Nate Williams Subject: Re: BIND 8.1.1 Cc: peter@FreeBSD.ORG, hackers@FreeBSD.ORG, Julian Elischer , Stephen Roome Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 25-Nov-97 Nate Williams wrote: ... > Only those who don't do their homework. There is no need for 8.1.1 > for > *anyone*, and since it will be changing, it'll be *more* work for > them > to upgrade to the next version when it comes up since it will also > contain new changes, while if they stick with 4.9.6 (or if new bugs > are > found, 4.9.7, or whatever) until BIND 8 'stabilizes', the upgrade > will > only require *one* big change, rather than possibly lots of changes > as > BIND 8 is modified. While your theory is a good one, reality disagrees with you. * There is no such thing as stable software. I saw some recent changes to dd.c, and this one predates Unix. * Most people operate on perception, not on reality (so much so that they confuse the two :-). Many people will choose other Unices over FreeBSD if they preceive it to be anything less than ``hotest''. * More new Network users (ISPs included) will choose Windoze NT over Unix because of what they perceive it to be. I fight this one every day. * None of the above is in support of 8.1.1 or 9.2.3. Neither is it against it. * The idea of making BIND into a package is excellent. All of the above are opinions, not facts, thus describing perception, not reality :-) > I'm sure Paul Vixie doesn't want the same thing to happen with BIND > that > happened with sendmail, That, by definition cannot happen. Simon From owner-freebsd-hackers Tue Nov 25 18:10:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA01558 for hackers-outgoing; Tue, 25 Nov 1997 18:10:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA01553 for ; Tue, 25 Nov 1997 18:10:43 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id SAA28746 for ; Tue, 25 Nov 1997 18:01:37 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd028744; Tue Nov 25 18:01:27 1997 Date: Tue, 25 Nov 1997 17:59:16 -0800 (PST) From: Julian Elischer To: hackers@freebsd.org Subject: issetugid(2) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This has broken all sorts of things here. I thought that the syscall interface for 2.2.x was being kept unchanged. This call makes it impossible to run binaries (e.g. vi) compiled under 2.2.5+ on a 2.2.2 machine. Surely the library routine that calls this should cope with it not being in the kernel, in the same way that Peter did his new syscalls. was this considered teh 'correct thing to do?' was there discussion? I must have dismissed it and now it's bitten me :( I have many machiens on people's desks here running everything from 2.1.0 to 2.2.5, but teh chroot environments they use are all 2.2.2. I was upgrading the chroot environment to 2.2.5(+) but it can only be used on the newest machines, and I don't want to have to upgrade all those machines..! Peter, how did you trap your new syscalls? (i can't even remember which they were) I'll see if I can work up a similar workaround if I can find a reference. julian (GRRR) From owner-freebsd-hackers Tue Nov 25 19:22:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA08802 for hackers-outgoing; Tue, 25 Nov 1997 19:22:59 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from milehigh.denver.net (milehigh.denver.net [204.144.180.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA08795 for ; Tue, 25 Nov 1997 19:22:55 -0800 (PST) (envelope-from jdc@milehigh.denver.net) Received: (from jdc@localhost) by milehigh.denver.net (8.8.7/8.8.5) id UAA22156; Tue, 25 Nov 1997 20:23:36 -0700 (MST) Message-ID: <19971125202336.17517@denver.net> Date: Tue, 25 Nov 1997 20:23:36 -0700 From: John-David Childs To: hackers@freebsd.org Subject: Re: BIND 8.1.1 References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 In-Reply-To: ; from Gordon Henderson on Tue, Nov 25, 1997 at 08:50:06PM +0000 Organization: Enterprise Internet Solutions Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tuesday November 25, 1997, Gordon Henderson had this to say about "Re: BIND 8.1.1": > On Tue, 25 Nov 1997, Stephen Roome wrote: > > Converting the zone files from 4.X format to 8.x format might not be a > trivial task for some people. True, there is a little perl script which > will do the bulk of the work, but for an ISP who acts as secondary for > 1000's of their customers zones, they also have to make sure that they can > get the information in the right format from their customer! That is a big issue for me...as I have quite a few secondaries who are running NT 4.9.whatever and I always come up with "record too short" when I do a named-xfer from Bind 8.1.1 (2.2.5-RELEASE) but works flawlessly when I retrieve the zone info from any of several 4.9.6 versions of Unix BIND. Other than that, 8.1.1 has a few goodies under the hood which convinced me to install it on my main DNS boxes last May. I wrote a csh script (my perl still sucks but I'm getting there :), to convert my *.boot, primary and secondary zone files to the 8.X format in about 30 minutes. > 8.1.1 compiles and installs out of the box on all FreeBSD's I've tried it > on and it seems to work well, so I'm sure it will happen, but not right > away... > > Gordon -- John-David Childs (JC612) Enterprise Internet Solutions System Administrator @denver.net/Internet-Coach/@ronan.net & Network Engineer 1031 S. Parker Rd. #I-8 Denver, CO 80231 As of this^H^H^H^H next week, passwords will be entered in Morse code. From owner-freebsd-hackers Tue Nov 25 19:31:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA09622 for hackers-outgoing; Tue, 25 Nov 1997 19:31:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA09612 for ; Tue, 25 Nov 1997 19:31:03 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id TAA12821; Tue, 25 Nov 1997 19:30:13 -0800 (PST) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id TAA21757; Tue, 25 Nov 1997 19:30:12 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id TAA28648; Tue, 25 Nov 1997 19:30:10 -0800 (PST) From: Don Lewis Message-Id: <199711260330.TAA28648@salsa.gv.tsc.tdk.com> Date: Tue, 25 Nov 1997 19:30:10 -0800 In-Reply-To: Jos Backus "Re: BIND 8.1.1" (Nov 25, 10:48pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Jos Backus , Stephen Roome Subject: Re: BIND 8.1.1 Cc: sthaug@nethelp.no, hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Nov 25, 10:48pm, Jos Backus wrote: } Subject: Re: BIND 8.1.1 } } In message you wr } ote: } >But when will it be the default? If there's no bugs (well, no serious ones } >that have been found) then why delay ? } } Because of the missing noforward patch/functionality, is one reason I can } think of. There are bugs in that patch anyway (if it's not forwarding, it'll only ever query one server and if the one it picks is down ...). The automagic address sorting in responses to local queries was removed between 4.9.x and 8.1. I've got a patch to add it back, and I've heard that this feature will be restored to the 8.x series due to popular demand. --- Truck From owner-freebsd-hackers Tue Nov 25 19:38:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA10605 for hackers-outgoing; Tue, 25 Nov 1997 19:38:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA10595 for ; Tue, 25 Nov 1997 19:37:57 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xaY9E-0001jg-00; Tue, 25 Nov 1997 19:28:20 -0800 Date: Tue, 25 Nov 1997 19:27:38 -0800 (PST) From: Tom To: Joe McGuckin cc: gordon@drogon.net, hackers@freebsd.org Subject: Re: BIND 8.1.1 In-Reply-To: <199711252339.PAA27977@monk.via.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 25 Nov 1997, Joe McGuckin wrote: > I wrote a perl script to convert the named.boot into the proper format for > named.conf. No big deal. It took about 15 minutes. And what a waste that was. 8.8.1 includes a perfectly good converter already. Tom From owner-freebsd-hackers Tue Nov 25 19:39:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA10716 for hackers-outgoing; Tue, 25 Nov 1997 19:39:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA10700; Tue, 25 Nov 1997 19:39:05 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id TAA12875; Tue, 25 Nov 1997 19:37:24 -0800 (PST) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id TAA21919; Tue, 25 Nov 1997 19:37:23 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id TAA28668; Tue, 25 Nov 1997 19:37:22 -0800 (PST) From: Don Lewis Message-Id: <199711260337.TAA28668@salsa.gv.tsc.tdk.com> Date: Tue, 25 Nov 1997 19:37:21 -0800 In-Reply-To: Pierre.Beyssac@hsc.fr (Pierre Beyssac) "Re: BIND 8.1.1" (Nov 25, 1:46pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Pierre.Beyssac@hsc.fr (Pierre Beyssac), steve@visint.co.uk (Stephen Roome) Subject: Re: BIND 8.1.1 Cc: nate@mt.sri.com (Nate Williams), julian@whistle.com (Julian Elischer), hackers@FreeBSD.ORG, peter@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Nov 25, 1:46pm, Pierre Beyssac wrote: } Subject: Re: BIND 8.1.1 } According to Stephen Roome: } Making BIND 8.1.1 the default under FreeBSD 2.2.x has the drawback that } it would break existing 2.2.x installations relying on BIND 4.x configs. Yes, and there is also the issue of what to do about the IRS library is someone else has mentioned. I vote against changing the 2.2.x BIND from 4.9.x to 8.1.x, but 3.x is a different kettle of fish. BTW, there are a number of patches floating around for 8.1.1 which should be included if this version is integrated. You might want to wait for 8.1.2 which appears to be in the works since I just got a confirmation message that one of my patches will be included. --- Truck From owner-freebsd-hackers Tue Nov 25 19:48:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA11626 for hackers-outgoing; Tue, 25 Nov 1997 19:48:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA11619 for ; Tue, 25 Nov 1997 19:48:20 -0800 (PST) (envelope-from mrcpu@cdsnet.net) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id TAA15599 for ; Tue, 25 Nov 1997 19:48:18 -0800 (PST) Date: Tue, 25 Nov 1997 19:48:18 -0800 (PST) From: Jaye Mathisen To: hackers@freebsd.org Subject: Maybe I'm missing something here. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk P6, 512MB RAM, 2.2.5-stable as of Monday. There's something like 1100 processes (web servers running on this), doing nothing. (no clients). maxusers is set to 128, and kern.maxfiles is set to 16384. Here's some vmstat output for a few seconds. 0 0 0198624124324 1 0 0 0 0 0 0 0 0 0 242 1610 525 0 11 89 0 0 0198624124324 1 0 0 0 0 0 0 0 0 0 242 1571 512 1 8 91 0 0 0198624124324 1 0 0 0 0 0 6 0 0 0 251 1838 602 2 15 83 0 0 0198624124324 1 0 0 0 0 0 0 0 0 0 240 1571 512 3 10 87 0 0 0198624124324 1 0 0 0 0 0 0 0 0 0 245 1571 511 1 10 89 0 0 0198624124324 1 0 0 0 0 0 0 0 0 0 242 1664 543 1 8 91 0 0 0198624124324 1 0 0 0 0 0 0 0 0 0 242 1574 514 0 13 87 0 0 0198624124324 1 0 0 0 0 0 0 0 0 0 241 1571 512 1 10 89 If nothing is going on, where is the system CPU time going? No disk activity, , no paging/swapping, no access, except my over-the-network xterm and vmstat -s. top shows nothing. everthing except top is sitting in select or lockf for as far down as I looked. lastpid hasn't changed for the 15 seconds or so when I checked. Top shows 6% of my time in interrupt, 3.8% in system. netstat -i shows nothing except what looks to be the correct amount of traffic for my xterm output. Do these numbers look right? Looking at a 2.2.2 server doing almost the same thing, things just seem lower all-the-way around, but of course, w/o identical loads, it doesn't mean anything. From owner-freebsd-hackers Tue Nov 25 20:00:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA12627 for hackers-outgoing; Tue, 25 Nov 1997 20:00:54 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA12605 for ; Tue, 25 Nov 1997 20:00:45 -0800 (PST) (envelope-from brian@awfulhak.org) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.7/8.8.7) with ESMTP id CAA25473; Wed, 26 Nov 1997 02:42:55 GMT (envelope-from brian@gate.lan.awfulhak.org) Message-Id: <199711260242.CAA25473@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: Jaye Mathisen cc: hackers@freebsd.org Subject: Re: How many loopback interfaces has anybody successfully used? In-reply-to: Your message of "Tue, 25 Nov 1997 13:02:25 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Nov 1997 02:42:55 +0000 From: Brian Somers Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Just curious. Had an idea for something, but it would depend on FreeBSD's > ability to handle a few thousand or so IP's on loopback aliases. The only problem I'd expect is a speed one. The interface addresses are stored in a linear list. You may get better performance by configuring a number of loopback interfaces (say tun0-tun99), thus having 100th of the aliases on each. I haven't tried anything of this scale though..... -- Brian , , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Tue Nov 25 20:17:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA14077 for hackers-outgoing; Tue, 25 Nov 1997 20:17:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA14049 for ; Tue, 25 Nov 1997 20:17:15 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199711260417.UAA14049@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA195567796; Wed, 26 Nov 1997 15:16:36 +1100 From: Darren Reed Subject: Re: issetugid(2) To: julian@whistle.com (Julian Elischer) Date: Wed, 26 Nov 1997 15:16:36 +1100 (EDT) Cc: hackers@FreeBSD.ORG In-Reply-To: from "Julian Elischer" at Nov 25, 97 05:59:16 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk where did this syscall come from ? Someone doing OpenBSD compatibility ? In some mail from Julian Elischer, sie said: > > This has broken all sorts of things here. > I thought that the syscall interface for 2.2.x was being kept > unchanged. > This call makes it impossible to run binaries (e.g. vi) > compiled under 2.2.5+ on a 2.2.2 machine. > Surely the library routine that calls this > should cope with it not being in the kernel, > in the same way that Peter did his new syscalls. > > was this considered teh 'correct thing to do?' > was there discussion? > > I must have dismissed it and now it's bitten me :( > > I have many machiens on people's desks here running everything > from 2.1.0 to 2.2.5, but teh chroot environments they use are all > 2.2.2. I was upgrading the chroot environment to 2.2.5(+) but > it can only be used on the newest machines, and I don't want to have to > upgrade all those machines..! > > Peter, how did you trap your new syscalls? (i can't even remember > which they were) > I'll see if I can work up a similar workaround if I can find a reference. > > > julian > (GRRR) From owner-freebsd-hackers Tue Nov 25 20:36:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA15678 for hackers-outgoing; Tue, 25 Nov 1997 20:36:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA15672 for ; Tue, 25 Nov 1997 20:36:50 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id PAA02455; Wed, 26 Nov 1997 15:02:14 +1030 (CST) Message-Id: <199711260432.PAA02455@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: Re: issetugid(2) In-reply-to: Your message of "Tue, 25 Nov 1997 17:59:16 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Nov 1997 15:02:13 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > This has broken all sorts of things here. > I thought that the syscall interface for 2.2.x was being kept > unchanged. Er, so did I. > This call makes it impossible to run binaries (e.g. vi) > compiled under 2.2.5+ on a 2.2.2 machine. > Surely the library routine that calls this > should cope with it not being in the kernel, > in the same way that Peter did his new syscalls. Um. Peter brought issetugid() back from -current. I had assumed that he'd done the Right Thing with it. > was this considered teh 'correct thing to do?' No. > was there discussion? Not AFAIR. > Peter, how did you trap your new syscalls? (i can't even remember > which they were) > I'll see if I can work up a similar workaround if I can find a reference. Look in libc/gen/getcwd.c in -current (at least). mike From owner-freebsd-hackers Tue Nov 25 21:09:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA18335 for hackers-outgoing; Tue, 25 Nov 1997 21:09:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nomis.Simon-Shapiro.ORG (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA18321 for ; Tue, 25 Nov 1997 21:09:00 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 4248 invoked by uid 1000); 26 Nov 1997 05:09:17 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-111797 [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: <199711252250.PAA29727@usr05.primenet.com> Date: Tue, 25 Nov 1997 21:09:17 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: Me, Just me... From: Simon Shapiro To: Terry Lambert Subject: Re: BIND 8.1.1 Cc: peter@freebsd.org, hackers@freebsd.org, julian@whistle.com, steve@visint.co.uk, (Nate Williams) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 25-Nov-97 Terry Lambert wrote: ... > The big pain on an 8.x upgrade is the config file format has changed > (there's good reasons for this, though it remains annoying no matter > how good the reasons). You are not forgetting the integration of the new resolver library into libc, new header files, etc. Right? Simon From owner-freebsd-hackers Tue Nov 25 22:30:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA23108 for hackers-outgoing; Tue, 25 Nov 1997 22:30:38 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA23103; Tue, 25 Nov 1997 22:30:32 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id WAA04705; Tue, 25 Nov 1997 22:20:55 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd004703; Tue Nov 25 22:20:54 1997 Date: Tue, 25 Nov 1997 22:18:43 -0800 (PST) From: Julian Elischer To: Simon Shapiro cc: Terry Lambert , peter@freebsd.org, hackers@freebsd.org, steve@visint.co.uk, nate@mt.sri.com Subject: Re: BIND 8.1.1 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk but they are not really needed as they have about the same functioanlity as before. (the format over the wire is still the same). On Tue, 25 Nov 1997, Simon Shapiro wrote: > > On 25-Nov-97 Terry Lambert wrote: > ... > > > The big pain on an 8.x upgrade is the config file format has > changed > > (there's good reasons for this, though it remains annoying no matter > > how good the reasons). > > You are not forgetting the integration of the new resolver library into > libc, new header files, etc. Right? > > Simon > > From owner-freebsd-hackers Tue Nov 25 23:38:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA27148 for hackers-outgoing; Tue, 25 Nov 1997 23:38:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.css-mps.ru ([194.154.87.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA27141 for ; Tue, 25 Nov 1997 23:38:27 -0800 (PST) (envelope-from ns.css-mps.ru!kirill) Received: from juli by ns.css-mps.ru with ESMTP id KAA18897; (8.6.11/vak/1.9) Wed, 26 Nov 1997 10:38:32 +0300 Message-Id: <199711260738.KAA18897@ns.css-mps.ru> From: "kirill" To: Date: Wed, 26 Nov 1997 11:37:13 +0300 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I have problem with my 3c509 Plag & Play. ( FreeBSD 2.2.2 ) What can I do? From owner-freebsd-hackers Wed Nov 26 00:14:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA29580 for hackers-outgoing; Wed, 26 Nov 1997 00:14:16 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA29574 for ; Wed, 26 Nov 1997 00:14:12 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.5) id SAA24977; Wed, 26 Nov 1997 18:43:58 +1030 (CST) Message-ID: <19971126184357.38414@lemis.com> Date: Wed, 26 Nov 1997 18:43:57 +1030 From: Greg Lehey To: kirill Cc: freebsd-hackers@freefall.FreeBSD.org Subject: Re: your mail References: <199711260738.KAA18897@ns.css-mps.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <199711260738.KAA18897@ns.css-mps.ru>; from kirill on Wed, Nov 26, 1997 at 11:37:13AM +0300 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, Nov 26, 1997 at 11:37:13AM +0300, kirill wrote: > I have problem with my 3c509 Plag & Play. ( FreeBSD 2.2.2 ) > What can I do? Send it to me and I'll look at it for you. Greg From owner-freebsd-hackers Wed Nov 26 00:25:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA00138 for hackers-outgoing; Wed, 26 Nov 1997 00:25:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.stu.neva.ru (root@ns.stu.neva.ru [194.85.96.53]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA29964 for ; Wed, 26 Nov 1997 00:21:58 -0800 (PST) (envelope-from ksw@stu.neva.ru) Received: from elm.stu.neva.ru ([195.208.113.78] EHLO elm.stu.neva.ru ident: NO-IDENT-SERVICE [port 4360]) by ns.stu.neva.ru with ESMTP id <23188-170>; Wed, 26 Nov 1997 11:18:16 +0300 Message-ID: X-Mailer: XFMail 1.2-beta-110497 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199711260738.KAA18897@ns.css-mps.ru> Date: Wed, 26 Nov 1997 11:21:42 +0300 (MSK) Reply-To: "Sergey V. Kupreenko" Organization: Central State Institute of Robotics & Technical Cybernetics From: "Sergey V. Kupreenko" To: kirill Subject: RE: Cc: freebsd-hackers@freefall.FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 26-Nov-97 kirill wrote: > I have problem with my 3c509 Plag & Play. ( FreeBSD 2.2.2 ) What kind of problem do you have? In general, you should use vx driver for 3C509 ethercard. If you wish you can describe your problems to me more detailed. You can write me in Russian (KOI8-R) > What can I do? ------------ With best wishes, Sergey V. Kupreenko (óÅÒÇÅÊ ëÕÐÒÅÅÎËÏ), E-mail: ksw@neva.ru, ksw@rusnet.ru Office phone: +7 (812)-552-0946, RUSNet Ltd., Central Center/Institute of Robotics and Technical Cybernetics, St.-Petersburg, Russia. From owner-freebsd-hackers Wed Nov 26 00:52:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA01581 for hackers-outgoing; Wed, 26 Nov 1997 00:52:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA01569 for ; Wed, 26 Nov 1997 00:52:43 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id IAA06526; Wed, 26 Nov 1997 08:47:08 +0100 From: Luigi Rizzo Message-Id: <199711260747.IAA06526@labinfo.iet.unipi.it> Subject: Re: your mail To: grog@lemis.com (Greg Lehey) Date: Wed, 26 Nov 1997 08:47:08 +0100 (MET) Cc: kirill@css-mps.ru, freebsd-hackers@freefall.FreeBSD.org In-Reply-To: <19971126184357.38414@lemis.com> from "Greg Lehey" at Nov 26, 97 06:43:38 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Wed, Nov 26, 1997 at 11:37:13AM +0300, kirill wrote: > > I have problem with my 3c509 Plag & Play. ( FreeBSD 2.2.2 ) > > What can I do? > > Send it to me and I'll look at it for you. :) if the card is really a Plug and Play unit, you can always try to use my PnP code (http://www.iet.unipi.it/~luigi/FreeBSD.html) to configure the card so that FreeBSD will find it afterwards. cheers luigi From owner-freebsd-hackers Wed Nov 26 01:00:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA02173 for hackers-outgoing; Wed, 26 Nov 1997 01:00:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA02164 for ; Wed, 26 Nov 1997 01:00:34 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id BAA19067; Wed, 26 Nov 1997 01:00:00 -0800 (PST) To: "kirill" cc: freebsd-hackers@freefall.FreeBSD.org In-reply-to: Your message of "Wed, 26 Nov 1997 11:37:13 +0300." <199711260738.KAA18897@ns.css-mps.ru> Date: Wed, 26 Nov 1997 01:00:00 -0800 Message-ID: <19057.880534800@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I have problem with my 3c509 Plag & Play. ( FreeBSD 2.2.2 ) > What can I do? 1. Ask freebsd-questions, not freebsd-hackers. 2. Include some actual detail, since "problem" could be anything from "returns `ep0: device timeout'" to "won't fit into a PCI slot, no matter how much I've been trying to force it in." Without details, your question is worse than useless to all of us. Jordan From owner-freebsd-hackers Wed Nov 26 01:01:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA02252 for hackers-outgoing; Wed, 26 Nov 1997 01:01:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from solaric.UkrCard.Kiev.UA (ukrcard-gu.gu.net [194.93.170.125]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA02186 for ; Wed, 26 Nov 1997 01:00:41 -0800 (PST) (envelope-from alex@UkrCard.Kiev.UA) Received: from solaric.UkrCard.Kiev.UA (localhost.ukrcard.kiev.ua [127.0.0.1]) by solaric.UkrCard.Kiev.UA (8.8.7/8.8.7) with SMTP id LAA00180; Wed, 26 Nov 1997 11:00:29 +0200 (EET) (envelope-from alex@UkrCard.Kiev.UA) Message-ID: <347BE52C.167EB0E7@UkrCard.Kiev.UA> Date: Wed, 26 Nov 1997 09:00:28 +0000 From: Alexander Tatmaniants Organization: UkrCard Joint Stock Co. X-Mailer: Mozilla 3.03 (X11; I; FreeBSD 2.2-971102-SNAP i386) MIME-Version: 1.0 To: kirill CC: freebsd-hackers@freefall.FreeBSD.org Subject: Re: References: <199711260738.KAA18897@ns.css-mps.ru> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk kirill wrote: > > I have problem with my 3c509 Plag & Play. ( FreeBSD 2.2.2 ) > What can I do? disable pnp whith 3c5x9cfg.exe utility From owner-freebsd-hackers Wed Nov 26 01:07:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA02625 for hackers-outgoing; Wed, 26 Nov 1997 01:07:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from solaric.UkrCard.Kiev.UA (ukrcard-gu.gu.net [194.93.170.125]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA02620 for ; Wed, 26 Nov 1997 01:06:51 -0800 (PST) (envelope-from alex@UkrCard.Kiev.UA) Received: from solaric.UkrCard.Kiev.UA (localhost.ukrcard.kiev.ua [127.0.0.1]) by solaric.UkrCard.Kiev.UA (8.8.7/8.8.7) with SMTP id LAA00500; Wed, 26 Nov 1997 11:06:52 +0200 (EET) (envelope-from alex@UkrCard.Kiev.UA) Message-ID: <347BE6AA.2781E494@UkrCard.Kiev.UA> Date: Wed, 26 Nov 1997 09:06:50 +0000 From: Alexander Tatmaniants Organization: UkrCard Joint Stock Co. X-Mailer: Mozilla 3.03 (X11; I; FreeBSD 2.2-971102-SNAP i386) MIME-Version: 1.0 To: "Sergey V. Kupreenko" CC: kirill , freebsd-hackers@freefall.FreeBSD.org Subject: Re: References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sergey V. Kupreenko wrote: > > On 26-Nov-97 kirill wrote: > > I have problem with my 3c509 Plag & Play. ( FreeBSD 2.2.2 ) > > What kind of problem do you have? > In general, you should use vx driver for 3C509 ethercard. If you ^^ - i use ep driver for 3c509 NIC > wish you can describe your problems to me more detailed. You can > write me in Russian (KOI8-R) > > > What can I do? > > ------------ > With best wishes, > Sergey V. Kupreenko (óÅÒÇÅÊ ëÕÐÒÅÅÎËÏ), > E-mail: ksw@neva.ru, ksw@rusnet.ru > Office phone: +7 (812)-552-0946, > RUSNet Ltd., > Central Center/Institute of Robotics and Technical Cybernetics, > St.-Petersburg, Russia. From owner-freebsd-hackers Wed Nov 26 01:09:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA02793 for hackers-outgoing; Wed, 26 Nov 1997 01:09:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mail.award.de (mail.award.de [195.30.16.205]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id BAA02779 for ; Wed, 26 Nov 1997 01:09:21 -0800 (PST) (envelope-from timog@mail.award.de) Received: (qmail 14928 invoked by uid 1015); 26 Nov 1997 09:00:27 -0000 Message-ID: <19971126100027.53229@mail.award.de> Date: Wed, 26 Nov 1997 10:00:27 +0100 From: tg@award.de To: hackers@freebsd.org Subject: PIIX configuration Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e Reply_To: Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello all, while looking through the source in /sys/pci yesterday, I noticed that the detection code for the Intel 82371xx IDE chip (PIIX) was present in 2 places. The detection code in pcisupport.c will find the chip first, claim it and display that it found one, but will not do anything with the chip. This effectively blocks the detection code in wd82371.c, which means that the more sophisticated code there does not get executed at all, so no DMA setup. Quite a pity if your IDE disk supports DMA. As I was playing around (OK, hacking around) in the wd PCI interface stuff trying to speed up my IDE disk (it's nearly 3 times faster when using Linux, but I want to run FREEBSD), I wondered if there was any sound technical reason behind this ? Regards, Timo P.S.: I would appreciate replies to be cc'ed to this address, as I only subscribe to hackers-digest. From owner-freebsd-hackers Wed Nov 26 01:37:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA03941 for hackers-outgoing; Wed, 26 Nov 1997 01:37:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns.stu.neva.ru (root@ns.stu.neva.ru [194.85.96.53]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA03908 for ; Wed, 26 Nov 1997 01:36:28 -0800 (PST) (envelope-from ksw@stu.neva.ru) Received: from elm.stu.neva.ru ([195.208.113.78] EHLO elm.stu.neva.ru ident: NO-IDENT-SERVICE [port 38664]) by ns.stu.neva.ru with ESMTP id <23402-170>; Wed, 26 Nov 1997 12:33:14 +0300 Message-ID: X-Mailer: XFMail 1.2-beta-110497 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <347BE6AA.2781E494@UkrCard.Kiev.UA> Date: Wed, 26 Nov 1997 12:36:47 +0300 (MSK) Reply-To: "Sergey V. Kupreenko" Organization: Central State Institute of Robotics & Technical Cybernetics From: "Sergey V. Kupreenko" To: Alexander Tatmaniants Subject: Re: Cc: freebsd-hackers@freefall.FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 26-Nov-97 Alexander Tatmaniants wrote: > Sergey V. Kupreenko wrote: >> >> On 26-Nov-97 kirill wrote: >> > I have problem with my 3c509 Plag & Play. ( FreeBSD 2.2.2 ) >> >> What kind of problem do you have? >> In general, you should use vx driver for 3C509 ethercard. If you > ^^ - i use ep driver for 3c509 NIC Sorry, You are right. I confused it with 3Com 590 ethernet card. ep driver is really for 3C509 cards. > >> wish you can describe your problems to me more detailed. You can >> write me in Russian (KOI8-R) >> >> > What can I do? >> >> ------------ >> With best wishes, >> Sergey V. Kupreenko (óÅÒÇÅÊ ëÕÐÒÅÅÎËÏ), >> E-mail: ksw@neva.ru, ksw@rusnet.ru >> Office phone: +7 (812)-552-0946, >> RUSNet Ltd., >> Central Center/Institute of Robotics and Technical Cybernetics, >> St.-Petersburg, Russia. ------------ With best wishes, Sergey V. Kupreenko (óÅÒÇÅÊ ëÕÐÒÅÅÎËÏ), E-mail: ksw@neva.ru, ksw@rusnet.ru Office phone: +7 (812)-552-0946, RUSNet Ltd., Central Center/Institute of Robotics and Technical Cybernetics, St.-Petersburg, Russia. From owner-freebsd-hackers Wed Nov 26 02:14:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA06033 for hackers-outgoing; Wed, 26 Nov 1997 02:14:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from unicorn.uk1.vbc.net (unicorn.uk1.vbc.net [194.207.2.11]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA06025 for ; Wed, 26 Nov 1997 02:14:11 -0800 (PST) (envelope-from gordon@drogon.net) Received: from localhost (gordon@localhost) by unicorn.uk1.vbc.net (8.8.5/8.8.5) with SMTP id KAA14819; Wed, 26 Nov 1997 10:13:35 GMT Date: Wed, 26 Nov 1997 10:13:34 +0000 (GMT) From: Gordon Henderson X-Sender: gordon@unicorn To: Archie Cobbs cc: steve@visint.co.uk, sthaug@nethelp.no, hackers@freebsd.org Subject: Re: BIND 8.1.1 In-Reply-To: <199711260022.QAA03526@bubba.whistle.com> Message-ID: Distribution: world Organization: Home for lost Drogons MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 25 Nov 1997, Archie Cobbs wrote: > > Converting the zone files from 4.X format to 8.x format might not be a > > trivial task for some people. True, there is a little perl script which > > will do the bulk of the work, but for an ISP who acts as secondary for > > 1000's of their customers zones, they also have to make sure that they can > > get the information in the right format from their customer! > > I thought that 8.x config files were different, but the zone file > format was the same.. am I mistaken? Oops - no I did mean the .boot/.conf files.. Gordon From owner-freebsd-hackers Wed Nov 26 02:34:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA06868 for hackers-outgoing; Wed, 26 Nov 1997 02:34:27 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA06861 for ; Wed, 26 Nov 1997 02:34:20 -0800 (PST) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.8/8.8.8) id LAA05158; Wed, 26 Nov 1997 11:31:15 +0100 (MET) (envelope-from sos) Message-Id: <199711261031.LAA05158@sos.freebsd.dk> Subject: Re: PIIX configuration In-Reply-To: <19971126100027.53229@mail.award.de> from "tg@award.de" at "Nov 26, 97 10:00:27 am" To: tg@award.de Date: Wed, 26 Nov 1997 11:31:13 +0100 (MET) Cc: hackers@FreeBSD.ORG From: Søren Schmidt Reply-to: sos@FreeBSD.dk X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to tg@award.de who wrote: > Hello all, > while looking through the source in /sys/pci yesterday, I noticed that the > detection code for the Intel 82371xx IDE chip (PIIX) was present in 2 places. > > The detection code in pcisupport.c will find the chip first, claim it and > display that it found one, but will not do anything with the chip. > > This effectively blocks the detection code in wd82371.c, which means that the > more sophisticated code there does not get executed at all, so no DMA setup. > Quite a pity if your IDE disk supports DMA. You must be looking at a 2.2.x system. For more up to date (E)IDE driver system look in curent, there is suppport for DMA etc modes. > As I was playing around (OK, hacking around) in the wd PCI interface stuff > trying to speed up my IDE disk (it's nearly 3 times faster when using Linux, > but I want to run FREEBSD), I wondered if there was any sound technical reason > behind this ? Most of the speed difference comes from the fact that linux has delayed write on as default, try mounting your disks with the async flag, and you will see semilar performance (and less security against corrupted disks on power outages etc). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Wed Nov 26 03:09:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA08612 for hackers-outgoing; Wed, 26 Nov 1997 03:09:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA08607 for ; Wed, 26 Nov 1997 03:09:52 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id MAA21433 for hackers@freebsd.org; Wed, 26 Nov 1997 12:09:43 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id LAA15612; Wed, 26 Nov 1997 11:21:33 +0100 (MET) Message-ID: <19971126112133.64082@uriah.heep.sax.de> Date: Wed, 26 Nov 1997 11:21:33 +0100 From: J Wunsch To: hackers@freebsd.org Subject: Re: problem mounting /cdrom w/ 2.2.5-R (fwd) Reply-To: Joerg Wunsch References: <19971124093009.OQ45903@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Julian Elischer on Mon, Nov 24, 1997 at 01:59:28AM -0800 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Julian Elischer wrote: > mount /cdrom uses the read-only flag > becasue it's in the fstab. > I'm not convinced that mount_cd9660 sets it by default. It does. The cd9660 code would reject an attempt to mount a CD-ROM without MNT_RDONLY anyway. Here's the snippet from mount_cd9660: /* * ISO 9660 filesystems are not writeable. */ mntflags |= MNT_RDONLY; args.export.ex_flags = MNT_EXRDONLY; args.fspec = dev; args.export.ex_root = DEFAULT_ROOTUID; args.flags = opts; -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Nov 26 03:10:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA08679 for hackers-outgoing; Wed, 26 Nov 1997 03:10:07 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA08656 for ; Wed, 26 Nov 1997 03:10:02 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id MAA21438 for hackers@freebsd.org; Wed, 26 Nov 1997 12:09:54 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id LAA15625; Wed, 26 Nov 1997 11:26:10 +0100 (MET) Message-ID: <19971126112610.49923@uriah.heep.sax.de> Date: Wed, 26 Nov 1997 11:26:10 +0100 From: J Wunsch To: hackers@freebsd.org Subject: Re: problem mounting /cdrom w/ 2.2.5-R (fwd) Reply-To: Joerg Wunsch References: <19971124091206.61860@vmunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Burton Sampley on Mon, Nov 24, 1997 at 11:56:30AM -0800 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Burton Sampley wrote: > Here's my assumption: > > I must have attempted to mount the cdrom too soon after loading the cdrom > in the drive. It's an old 4X SCSI Toshiba CDROM drive. Instead of giving > me a device not ready error to the console (BTW, I just reviewed > /var/log/messages where it DID give a NOT READY error from /kernel) it > gave a device not configured error message. Device not ready errors are silently discarded when opening a device, and ENXIO (`Device not configured') is returned. AFAIK, this is the `politically correct' behaviour. ENXIO can mean quite a number of errors (unfortunately). And yes, Toshiba drives require quite some time until they are ready after the insertion of a new medium. As a general rule, wait until the yellow LED went off, and start the mount command then. It would be better if they indicated a `Logical unit is in the process of becoming ready' instead (which FreeBSD repeatedly retries until success, or until a different message appears). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Nov 26 03:46:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA10615 for hackers-outgoing; Wed, 26 Nov 1997 03:46:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA10585 for ; Wed, 26 Nov 1997 03:46:03 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199711261146.DAA10585@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA252274752; Wed, 26 Nov 1997 22:45:52 +1100 From: Darren Reed Subject: I20 To: hackers@freebsd.org Date: Wed, 26 Nov 1997 22:45:52 +1100 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Reading a computer rag article about I20, they menion that Linux International is seeking SIG membership. Obviously LI is interested in making their drivers, etc, available freely as source code... Anyway, that's just FYI. From owner-freebsd-hackers Wed Nov 26 03:50:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA10983 for hackers-outgoing; Wed, 26 Nov 1997 03:50:16 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA10978 for ; Wed, 26 Nov 1997 03:50:13 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id DAA10116 for ; Wed, 26 Nov 1997 03:48:43 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd010111; Wed Nov 26 03:48:34 1997 Date: Wed, 26 Nov 1997 03:46:23 -0800 (PST) From: Julian Elischer To: hackers@freebsd.org Subject: DEVFS/SLICE passes milestone Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-827044085-880544783=:2992" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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-827044085-880544783=:2992 Content-Type: TEXT/PLAIN; charset=US-ASCII San francisco, Early Tuesday morning, DEVFS passed a critical milestone today when my PC here booted up a kernel using only DEVFS based devices. The kernel used DEVFS to find the root device and mount it, finding it by NAME (sd1s1a) rather than by major/minor numbers. The disk devices were all created dynamically using the "slice" subsystem so that all IO to the disks was flowing through the SLICE system's "IOreq" entrypoints rather than the older disk 'strategy()' entrypoints. The disk partitionning is being handled by separate MBR and DISKLABEL SLICE objects, rather than by the older disk 'slicing' code. The drivers have SLICE entrypoints added, in addition to the usual entrypoints, which are no longer being used. teh SLICE code is also known as "storage layering". On my system here, the lowest layer is the driver, which exports a single slice. The driver does not know about any partitioning (in the new code that is). It does IO requiests and that is all. The next layer is an MBR type object, that takes the single slice exported by the driver and exports in turn N slices, one for each MBR (fdisk) partition. On each disk, One of these slices is in turn passed to a DISKLABEL object, that takes in a single MBR slice and exports a slice for each disklabel partition. All these slices regardless of layer are identical in behaviour. the top layer HAPPENS to have filesystems on each slice. since All disklslices are now handled by the same code their major numbers are all the same. The minor numbers are allocated dynamically as increasing integers. i.e. SLICE code NEEDS DEVFS. yes I know the dates and link counts are wrong.. next steps: 1/ clean it up 2/ figure out why I suddenly have an extra swap device (a worry) 3/ fix dates and links 4/ make all major numbers irrelevant by bypassing the devsw tables. 4a/ Allocate majors dynamically (used only to allow a device to be shown to be unique) 5/ remove all references to dev_t in the kernel :-) julian attached find 'mount' output and disk related lines from 'ls -l /dev' --0-827044085-880544783=:2992 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=devs Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: DQpicnctLS0tLS0tICAyNyByb290ICBrbWVtICAgICAgIDE0LCAgIDMgTm92 IDI2IDAzOjExIGZkMA0KYnJ3LS0tLS0tLSAgIDMgcm9vdCAga21lbSAgICAg ICAxNCwgICA3IE5vdiAyNiAwMzoxMSBmZDAuMTIwMA0KYnJ3LS0tLS0tLSAg IDMgcm9vdCAga21lbSAgICAgICAxNCwgICA2IE5vdiAyNiAwMzoxMSBmZDAu MTQ0MA0KYnJ3LS0tLS0tLSAgIDMgcm9vdCAga21lbSAgICAgICAxNCwgICA1 IE5vdiAyNiAwMzoxMSBmZDAuMTQ4MA0KYnJ3LS0tLS0tLSAgIDMgcm9vdCAg a21lbSAgICAgICAxNCwgICA0IE5vdiAyNiAwMzoxMSBmZDAuMTcyMA0KYnJ3 LS0tLS0tLSAgIDMgcm9vdCAga21lbSAgICAgICAxNCwgIDEwIE5vdiAyNiAw MzoxMSBmZDAuNzIwDQpicnctLS0tLS0tICAgMyByb290ICBrbWVtICAgICAg IDE0LCAgIDkgTm92IDI2IDAzOjExIGZkMC44MDANCmJydy0tLS0tLS0gICAz IHJvb3QgIGttZW0gICAgICAgMTQsICAgOCBOb3YgMjYgMDM6MTEgZmQwLjgy MA0KYnJ3LS0tLS0tLSAgMjcgcm9vdCAga21lbSAgICAgICAxNCwgICAzIE5v diAyNiAwMzoxMSBmZDBhDQpicnctLS0tLS0tICAyNyByb290ICBrbWVtICAg ICAgIDE0LCAgIDMgTm92IDI2IDAzOjExIGZkMGINCmJydy0tLS0tLS0gIDI3 IHJvb3QgIGttZW0gICAgICAgMTQsICAgMyBOb3YgMjYgMDM6MTEgZmQwYw0K YnJ3LS0tLS0tLSAgMjcgcm9vdCAga21lbSAgICAgICAxNCwgICAzIE5vdiAy NiAwMzoxMSBmZDBkDQpicnctLS0tLS0tICAyNyByb290ICBrbWVtICAgICAg IDE0LCAgIDMgTm92IDI2IDAzOjExIGZkMGUNCmJydy0tLS0tLS0gIDI3IHJv b3QgIGttZW0gICAgICAgMTQsICAgMyBOb3YgMjYgMDM6MTEgZmQwZg0KYnJ3 LS0tLS0tLSAgMjcgcm9vdCAga21lbSAgICAgICAxNCwgICAzIE5vdiAyNiAw MzoxMSBmZDBnDQpicnctLS0tLS0tICAyNyByb290ICBrbWVtICAgICAgIDE0 LCAgIDMgTm92IDI2IDAzOjExIGZkMGgNCmJydy0tLS0tLS0gICAzIHJvb3Qg IGttZW0gICAgICAgMTQsICAxMSBEZWMgMzEgIDE5NjkgZmQwczENCmJydy0t LS0tLS0gICAzIHJvb3QgIGttZW0gICAgICAgMTQsICAxMiBEZWMgMzEgIDE5 NjkgZmQwczFhDQpicnctLS0tLS0tICAgMyByb290ICBrbWVtICAgICAgIDE0 LCAgMTMgRGVjIDMxICAxOTY5IGZkMHMxYg0KYnJ3LS0tLS0tLSAgIDMgcm9v dCAga21lbSAgICAgICAxNCwgIDE0IERlYyAzMSAgMTk2OSBmZDBzMg0KYnJ3 LS0tLS0tLSAgIDMgcm9vdCAga21lbSAgICAgICAxNCwgIDE1IERlYyAzMSAg MTk2OSBmZDBzNA0KYnJ3LS0tLS0tLSAgIDMgcm9vdCAga21lbSAgICAgICAx NCwgIDE2IERlYyAzMSAgMTk2OSBmZDBzNGENCmJydy0tLS0tLS0gICAzIHJv b3QgIGttZW0gICAgICAgMTQsICAxNyBEZWMgMzEgIDE5NjkgZmQwczRiDQpj cnctLS0tLS0tICAyNyByb290ICBrbWVtICAgICAgIDIwLCAgIDMgTm92IDI2 IDAzOjExIHJmZDANCmNydy0tLS0tLS0gICAzIHJvb3QgIGttZW0gICAgICAg MjAsICAgNyBOb3YgMjYgMDM6MTEgcmZkMC4xMjAwDQpjcnctLS0tLS0tICAg MyByb290ICBrbWVtICAgICAgIDIwLCAgIDYgTm92IDI2IDAzOjExIHJmZDAu MTQ0MA0KY3J3LS0tLS0tLSAgIDMgcm9vdCAga21lbSAgICAgICAyMCwgICA1 IE5vdiAyNiAwMzoxMSByZmQwLjE0ODANCmNydy0tLS0tLS0gICAzIHJvb3Qg IGttZW0gICAgICAgMjAsICAgNCBOb3YgMjYgMDM6MTEgcmZkMC4xNzIwDQpj cnctLS0tLS0tICAgMyByb290ICBrbWVtICAgICAgIDIwLCAgMTAgTm92IDI2 IDAzOjExIHJmZDAuNzIwDQpjcnctLS0tLS0tICAgMyByb290ICBrbWVtICAg ICAgIDIwLCAgIDkgTm92IDI2IDAzOjExIHJmZDAuODAwDQpjcnctLS0tLS0t ICAgMyByb290ICBrbWVtICAgICAgIDIwLCAgIDggTm92IDI2IDAzOjExIHJm ZDAuODIwDQpjcnctLS0tLS0tICAyNyByb290ICBrbWVtICAgICAgIDIwLCAg IDMgTm92IDI2IDAzOjExIHJmZDBhDQpjcnctLS0tLS0tICAyNyByb290ICBr bWVtICAgICAgIDIwLCAgIDMgTm92IDI2IDAzOjExIHJmZDBiDQpjcnctLS0t LS0tICAyNyByb290ICBrbWVtICAgICAgIDIwLCAgIDMgTm92IDI2IDAzOjEx IHJmZDBjDQpjcnctLS0tLS0tICAyNyByb290ICBrbWVtICAgICAgIDIwLCAg IDMgTm92IDI2IDAzOjExIHJmZDBkDQpjcnctLS0tLS0tICAyNyByb290ICBr bWVtICAgICAgIDIwLCAgIDMgTm92IDI2IDAzOjExIHJmZDBlDQpjcnctLS0t LS0tICAyNyByb290ICBrbWVtICAgICAgIDIwLCAgIDMgTm92IDI2IDAzOjEx IHJmZDBmDQpjcnctLS0tLS0tICAyNyByb290ICBrbWVtICAgICAgIDIwLCAg IDMgTm92IDI2IDAzOjExIHJmZDBnDQpjcnctLS0tLS0tICAyNyByb290ICBr bWVtICAgICAgIDIwLCAgIDMgTm92IDI2IDAzOjExIHJmZDBoDQpjcnctLS0t LS0tICAgMyByb290ICBrbWVtICAgICAgIDIwLCAgMTEgRGVjIDMxICAxOTY5 IHJmZDBzMQ0KY3J3LS0tLS0tLSAgIDMgcm9vdCAga21lbSAgICAgICAyMCwg IDEyIERlYyAzMSAgMTk2OSByZmQwczFhDQpjcnctLS0tLS0tICAgMyByb290 ICBrbWVtICAgICAgIDIwLCAgMTMgRGVjIDMxICAxOTY5IHJmZDBzMWINCmNy dy0tLS0tLS0gICAzIHJvb3QgIGttZW0gICAgICAgMjAsICAxNCBEZWMgMzEg IDE5NjkgcmZkMHMyDQpjcnctLS0tLS0tICAgMyByb290ICBrbWVtICAgICAg IDIwLCAgMTUgRGVjIDMxICAxOTY5IHJmZDBzNA0KY3J3LS0tLS0tLSAgIDMg cm9vdCAga21lbSAgICAgICAyMCwgIDE2IERlYyAzMSAgMTk2OSByZmQwczRh DQpjcnctLS0tLS0tICAgMyByb290ICBrbWVtICAgICAgIDIwLCAgMTcgRGVj IDMxICAxOTY5IHJmZDBzNGINCmNydy0tLS0tLS0gICAzIHJvb3QgIGttZW0g ICAgICAgMjAsICAgMCBOb3YgMjYgMDM6MTEgcnNkMA0KY3J3LS0tLS0tLSAg IDMgcm9vdCAgd2hlZWwgICAgICAxMywgMHgyMDAwMDAwMCBOb3YgMjYgMDM6 MTEgcnNkMC5jdGwNCmNydy0tLS0tLS0gICAzIHJvb3QgIGttZW0gICAgICAg MjAsICAyOSBEZWMgMzEgIDE5NjkgcnNkMHMxDQpjcnctLS0tLS0tICAgMyBy b290ICBrbWVtICAgICAgIDIwLCAgMzAgRGVjIDMxICAxOTY5IHJzZDBzMg0K Y3J3LS0tLS0tLSAgIDMgcm9vdCAga21lbSAgICAgICAyMCwgIDMxIERlYyAz MSAgMTk2OSByc2QwczJhDQpjcnctLS0tLS0tICAgMyByb290ICBrbWVtICAg ICAgIDIwLCAgMzIgRGVjIDMxICAxOTY5IHJzZDBzMmINCmNydy0tLS0tLS0g ICAzIHJvb3QgIGttZW0gICAgICAgMjAsICAzMyBEZWMgMzEgIDE5NjkgcnNk MHMyZA0KY3J3LS0tLS0tLSAgIDMgcm9vdCAga21lbSAgICAgICAyMCwgICAx IE5vdiAyNiAwMzoxMSByc2QxDQpjcnctLS0tLS0tICAgMyByb290ICB3aGVl bCAgICAgIDEzLCAweDIwMDAwMDA4IE5vdiAyNiAwMzoxMSByc2QxLmN0bA0K Y3J3LS0tLS0tLSAgIDMgcm9vdCAga21lbSAgICAgICAyMCwgIDIyIERlYyAz MSAgMTk2OSByc2QxczENCmNydy0tLS0tLS0gICAzIHJvb3QgIGttZW0gICAg ICAgMjAsICAyMyBEZWMgMzEgIDE5NjkgcnNkMXMxYQ0KY3J3LS0tLS0tLSAg IDMgcm9vdCAga21lbSAgICAgICAyMCwgIDI0IERlYyAzMSAgMTk2OSByc2Qx czFiDQpjcnctLS0tLS0tICAgMyByb290ICBrbWVtICAgICAgIDIwLCAgMjUg RGVjIDMxICAxOTY5IHJzZDFzMWQNCmNydy0tLS0tLS0gICAzIHJvb3QgIGtt ZW0gICAgICAgMjAsICAyNiBEZWMgMzEgIDE5NjkgcnNkMXMxZQ0KY3J3LS0t LS0tLSAgIDMgcm9vdCAga21lbSAgICAgICAyMCwgIDI3IERlYyAzMSAgMTk2 OSByc2QxczFmDQpjcnctLS0tLS0tICAgMyByb290ICBrbWVtICAgICAgIDIw LCAgMjggRGVjIDMxICAxOTY5IHJzZDFzMWcNCmNydy0tLS0tLS0gICAzIHJv b3QgIGttZW0gICAgICAgMjAsICAgMiBOb3YgMjYgMDM6MTEgcnNkMg0KY3J3 LS0tLS0tLSAgIDMgcm9vdCAgd2hlZWwgICAgICAxMywgMHgyMDAwMDAxMCBO b3YgMjYgMDM6MTEgcnNkMi5jdGwNCmNydy0tLS0tLS0gICAzIHJvb3QgIGtt ZW0gICAgICAgMjAsICAxOCBEZWMgMzEgIDE5NjkgcnNkMnMxDQpjcnctLS0t LS0tICAgMyByb290ICBrbWVtICAgICAgIDIwLCAgMTkgRGVjIDMxICAxOTY5 IHJzZDJzMWINCmNydy0tLS0tLS0gICAzIHJvb3QgIGttZW0gICAgICAgMjAs ICAyMCBEZWMgMzEgIDE5NjkgcnNkMnMxZA0KY3J3LS0tLS0tLSAgIDMgcm9v dCAga21lbSAgICAgICAyMCwgIDIxIERlYyAzMSAgMTk2OSByc2QyczFlDQpi cnctLS0tLS0tICAgMyByb290ICBrbWVtICAgICAgIDE0LCAgIDAgTm92IDI2 IDAzOjExIHNkMA0KYnJ3LS0tLS0tLSAgIDMgcm9vdCAga21lbSAgICAgICAx NCwgIDI5IERlYyAzMSAgMTk2OSBzZDBzMQ0KYnJ3LS0tLS0tLSAgIDMgcm9v dCAga21lbSAgICAgICAxNCwgIDMwIERlYyAzMSAgMTk2OSBzZDBzMg0KYnJ3 LS0tLS0tLSAgIDMgcm9vdCAga21lbSAgICAgICAxNCwgIDMxIERlYyAzMSAg MTk2OSBzZDBzMmENCmJydy0tLS0tLS0gICAzIHJvb3QgIGttZW0gICAgICAg MTQsICAzMiBEZWMgMzEgIDE5Njkgc2QwczJiDQpicnctLS0tLS0tICAgMyBy b290ICBrbWVtICAgICAgIDE0LCAgMzMgRGVjIDMxICAxOTY5IHNkMHMyZA0K YnJ3LS0tLS0tLSAgIDMgcm9vdCAga21lbSAgICAgICAxNCwgICAxIE5vdiAy NiAwMzoxMSBzZDENCmJydy0tLS0tLS0gICAzIHJvb3QgIGttZW0gICAgICAg MTQsICAyMiBEZWMgMzEgIDE5Njkgc2QxczENCmJydy0tLS0tLS0gICAzIHJv b3QgIGttZW0gICAgICAgMTQsICAyMyBEZWMgMzEgIDE5Njkgc2QxczFhDQpi cnctLS0tLS0tICAgMyByb290ICBrbWVtICAgICAgIDE0LCAgMjQgRGVjIDMx ICAxOTY5IHNkMXMxYg0KYnJ3LS0tLS0tLSAgIDMgcm9vdCAga21lbSAgICAg ICAxNCwgIDI1IERlYyAzMSAgMTk2OSBzZDFzMWQNCmJydy0tLS0tLS0gICAz IHJvb3QgIGttZW0gICAgICAgMTQsICAyNiBEZWMgMzEgIDE5Njkgc2QxczFl DQpicnctLS0tLS0tICAgMyByb290ICBrbWVtICAgICAgIDE0LCAgMjcgRGVj IDMxICAxOTY5IHNkMXMxZg0KYnJ3LS0tLS0tLSAgIDMgcm9vdCAga21lbSAg ICAgICAxNCwgIDI4IERlYyAzMSAgMTk2OSBzZDFzMWcNCmJydy0tLS0tLS0g ICAzIHJvb3QgIGttZW0gICAgICAgMTQsICAgMiBOb3YgMjYgMDM6MTEgc2Qy DQpicnctLS0tLS0tICAgMyByb290ICBrbWVtICAgICAgIDE0LCAgMTggRGVj IDMxICAxOTY5IHNkMnMxDQpicnctLS0tLS0tICAgMyByb290ICBrbWVtICAg ICAgIDE0LCAgMTkgRGVjIDMxICAxOTY5IHNkMnMxYg0KYnJ3LS0tLS0tLSAg IDMgcm9vdCAga21lbSAgICAgICAxNCwgIDIwIERlYyAzMSAgMTk2OSBzZDJz MWQNCmJydy0tLS0tLS0gICAzIHJvb3QgIGttZW0gICAgICAgMTQsICAyMSBE ZWMgMzEgIDE5Njkgc2QyczFlDQoNCi9kZXYvc2QxczFhIG9uIC8gKGxvY2Fs KQ0KZGV2ZnMgb24gZHVtbXlfbW91bnQgKGxvY2FsKQ0KZGV2ZnMgb24gL2Rl diAobG9jYWwpDQovZGV2L3NkMHMyZCBvbiAvdXNyIChsb2NhbCwgbm9hdGlt ZSkNCmRldmZzIG9uIC9kZXZzIChsb2NhbCkNCi9kZXYvc2QxczFkIG9uIC90 bXAgKGFzeW5jaHJvbm91cywgbG9jYWwsIG5vYXRpbWUpDQovZGV2L3NkMXMx ZSBvbiAvdmFyIChsb2NhbCkNCi9kZXYvc2QyczFkIG9uIC91c3IvcG9ydHMg KGFzeW5jaHJvbm91cywgbG9jYWwsIG5vYXRpbWUpDQovZGV2L3NkMXMxZyBv biAvdXNyL3BvcnRzL2Rpc3RmaWxlcyAoYXN5bmNocm9ub3VzLCBORlMgZXhw b3J0ZWQsIGxvY2FsLCBub2F0aW1lKQ0KL2Rldi9zZDJzMWUgb24gL3Vzci9z cmMgKGFzeW5jaHJvbm91cywgbG9jYWwsIG5vYXRpbWUpDQovZGV2L3NkMXMx ZiBvbiAvdXNyL29iaiAoYXN5bmNocm9ub3VzLCBsb2NhbCwgbm9hdGltZSkN Ci9kZXYvc2QwczJhIG9uIC91c3Ivb2JqL3Vzci9zcmMvdG1wIChhc3luY2hy b25vdXMsIGxvY2FsLCBub2F0aW1lKQ0KcHJvY2ZzIG9uIC9wcm9jIChsb2Nh bCkNCg== --0-827044085-880544783=:2992-- From owner-freebsd-hackers Wed Nov 26 04:33:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA13152 for hackers-outgoing; Wed, 26 Nov 1997 04:33:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from heron.doc.ic.ac.uk (+DIcYY4Hwhb2UrSDyD1o6Q0k6YdHuXOs@heron.doc.ic.ac.uk [146.169.2.31]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id EAA13138 for ; Wed, 26 Nov 1997 04:33:02 -0800 (PST) (envelope-from njs3@doc.ic.ac.uk) Received: from ash3.doc.ic.ac.uk [146.169.16.31] ([JAN4awqvQujo8cHw8KeFN6Ct46dKCTva]) by heron.doc.ic.ac.uk with smtp (Exim 1.62 #3) id 0xaggN-000085-00; Wed, 26 Nov 1997 12:35:07 +0000 Received: from njs3 by ash3.doc.ic.ac.uk with local (Exim 1.62 #1) id 0xageF-0005pH-00; Wed, 26 Nov 1997 12:32:55 +0000 From: njs3@doc.ic.ac.uk (Niall Smart) Date: Wed, 26 Nov 1997 12:32:54 +0000 In-Reply-To: Charles Mott "Re: pthread_cond_timedwait returning wrong error?" (Nov 25, 3:24pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Charles Mott , Niall Smart Subject: Re: pthread_cond_timedwait returning wrong error? Cc: hackers@freebsd.org Message-Id: Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Nov 25, 3:24pm, Charles Mott wrote: } Subject: Re: pthread_cond_timedwait returning wrong error? > On Tue, 25 Nov 1997, Niall Smart wrote: > > On Nov 25, 12:24pm, Charles Mott wrote: > > } Subject: Re: pthread_cond_timedwait returning wrong error? > > > > > > To me, having all the *_r reentrant functions is a big nuisance. > > > > Yeah, lets invent our own standard! Or maybe we should just leave out > > threads altogether and stick with badly designed interfaces! > > > I quess I was referring to the *_r functions on Solaris that I don't see > anywhere else. Are these standard? Yes, to the POSIX pthreads standard. > I think having the standard Unix > function calls with hidden thread addaptations like the errno solution > (mapping errno to a function) explained by Alex Nash seems like a good > idea to me. I think this is a kludge, although it is compliant with the POSIX API and the best option given the circumstances. WindowsNT uses GetLastError() or somesuch, I would prefer to see something like this. (of course, in libc_r errno does expand to a function call, I just don't think its good to have this ``hidden'' expansion) Also, it is not practical to fix all broken interfaces in this way, consider getpwent(), to make the existing interface thread safe it would have to use thread specific data internally. This overcomplicates its implementation, a better way is to make the thread provide the thread specific data (e.g. from a buffer on the stack) If every interface in libc_r that used static data was converted to use thread specific data its complexity, and therefore the number of bugs, would rise substantically > What I have observed from Solaris, FreeBSD, Linux and OSF is that there > doesn't seem to be any standard that is obvious to me. Even OSF 3.2 and > 4.0 are different from each other. This is a major source of annoyance if > one is trying to develop software which will cleanly compile accross > different platforms. This is probably due to the various operating systems implementing different drafts of the POSIX standard, hopefully in the next releases of the OS' incompatabilities will not be an issue. (yeah right!) :) Regards, Niall From owner-freebsd-hackers Wed Nov 26 04:43:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA13650 for hackers-outgoing; Wed, 26 Nov 1997 04:43:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mail.award.de (mail.award.de [195.30.16.205]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id EAA13638 for ; Wed, 26 Nov 1997 04:43:01 -0800 (PST) (envelope-from timog@mail.award.de) Received: (qmail 3616 invoked by uid 1015); 26 Nov 1997 12:36:02 -0000 Message-ID: <19971126133602.62657@mail.award.de> Date: Wed, 26 Nov 1997 13:36:02 +0100 From: tg@award.de To: sos@FreeBSD.dk Cc: hackers@freebsd.org Subject: Re: PIIX configuration References: <19971126100027.53229@mail.award.de> <199711261031.LAA05158@sos.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88e In-Reply-To: =?iso-8859-1?Q?=3C199711261031=2ELAA05158=40sos=2Efreebsd=2Edk=3E=3B_fro?= =?iso-8859-1?Q?m_S=F8ren_Schmidt_on_Wed=2C_Nov_26=2C_1997_at_11=3A31=3A1?= =?iso-8859-1?Q?3AM_+0100?= Reply_To: Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, Nov 26, 1997 at 11:31:13AM +0100, Søren Schmidt wrote: > In reply to tg@award.de who wrote: > > Hello all, > > while looking through the source in /sys/pci yesterday, I noticed that the > > detection code for the Intel 82371xx IDE chip (PIIX) was present in 2 places. > > > > The detection code in pcisupport.c will find the chip first, claim it and > > display that it found one, but will not do anything with the chip. > > > > This effectively blocks the detection code in wd82371.c, which means that the > > more sophisticated code there does not get executed at all, so no DMA setup. > > Quite a pity if your IDE disk supports DMA. > > You must be looking at a 2.2.x system. > For more up to date (E)IDE driver system look in curent, there is > suppport for DMA etc modes. Err... Sh*t. That's why I always ask MY customers which version they are using. The system in question is a 2.2.5-Stable cvsupped 11/17. Sorry. Is there any chance to take the code from current and mix it into 2,2,x without too much work ? > Most of the speed difference comes from the fact that linux has delayed > write on as default, try mounting your disks with the async flag, and > you will see semilar performance (and less security against corrupted > disks on power outages etc). I don't think that the major speed difference comes from the sync vs. async mounting. The speed difference was measured using bonnie with files > 100M and that's about twice the available RAM. Besides, I usually mount anything sync if possible. Old electrical installation, you know :-). Regards, Timo From owner-freebsd-hackers Wed Nov 26 05:48:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA17692 for hackers-outgoing; Wed, 26 Nov 1997 05:48:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA17652 for ; Wed, 26 Nov 1997 05:47:59 -0800 (PST) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.8/8.8.8) id OAA05497; Wed, 26 Nov 1997 14:48:27 +0100 (MET) (envelope-from sos) Message-Id: <199711261348.OAA05497@sos.freebsd.dk> Subject: Re: PIIX configuration In-Reply-To: <19971126133602.62657@mail.award.de> from "tg@award.de" at "Nov 26, 97 01:36:02 pm" To: tg@award.de Date: Wed, 26 Nov 1997 14:48:27 +0100 (MET) Cc: sos@freebsd.dk, hackers@FreeBSD.ORG From: Søren Schmidt Reply-to: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to tg@award.de who wrote: > > > > You must be looking at a 2.2.x system. > > For more up to date (E)IDE driver system look in curent, there is > > suppport for DMA etc modes. > > Err... Sh*t. That's why I always ask MY customers which version they are using. > The system in question is a 2.2.5-Stable cvsupped 11/17. Sorry. > > Is there any chance to take the code from current and mix it into 2,2,x without > too much work ? > Well, it should be, the author of the DMA code did it on a 2.2.x system.. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Wed Nov 26 05:55:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA18179 for hackers-outgoing; Wed, 26 Nov 1997 05:55:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA18173 for ; Wed, 26 Nov 1997 05:55:41 -0800 (PST) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.8/8.8.8) id OAA05520; Wed, 26 Nov 1997 14:56:01 +0100 (MET) (envelope-from sos) Message-Id: <199711261356.OAA05520@sos.freebsd.dk> Subject: Re: DEVFS/SLICE passes milestone In-Reply-To: from Julian Elischer at "Nov 26, 97 03:46:23 am" To: julian@whistle.com (Julian Elischer) Date: Wed, 26 Nov 1997 14:56:01 +0100 (MET) Cc: hackers@FreeBSD.ORG From: Søren Schmidt Reply-to: sos@FreeBSD.dk X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Julian Elischer who wrote: > > San francisco, Early Tuesday morning, > > DEVFS passed a critical milestone today when my PC here booted up a kernel > using only DEVFS based devices. The kernel used DEVFS to find the root > device and mount it, finding it by NAME (sd1s1a) rather than by > major/minor numbers. The disk devices were all created dynamically using > the "slice" subsystem so that all IO to the disks was flowing through the > SLICE system's "IOreq" entrypoints rather than the older disk 'strategy()' > entrypoints. > > The disk partitionning is being handled by separate MBR and DISKLABEL > SLICE objects, rather than by the older disk 'slicing' code. > The drivers have SLICE entrypoints added, in addition to the usual > entrypoints, which are no longer being used. > teh SLICE code is also known as "storage layering". Klokkerholm early wednesday afternoon, I would like if you where concentrating on makeing DEVFS work, then started to play with new SLICE code. Now we get a monster patch that noone has the time to deal with (you should know that now you have Terry onboard :) ), and thereby has much less chance of getting into the sources. We asked you to clean up DEVFS and get it to work, or it would be thrown out, not to pull in further "enhancements"..... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Wed Nov 26 07:14:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA23276 for hackers-outgoing; Wed, 26 Nov 1997 07:14:43 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA23270 for ; Wed, 26 Nov 1997 07:14:41 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-53-114.ca.us.ibm.net (slip129-37-53-114.ca.us.ibm.net [129.37.53.114]) by out1.ibm.net (8.8.5/8.6.9) with SMTP id PAA120308; Wed, 26 Nov 1997 15:14:25 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans Cc: hackers@FreeBSD.ORG Subject: 650 UART, SIO driver, 8259 PIC Date: Wed, 26 Nov 1997 16:15:30 GMT Message-ID: <347c331c.3815914@smtp-gw01.ny.us.ibm.net> References: <199711250910.UAA29294@godzilla.zeta.org.au> In-Reply-To: <199711250910.UAA29294@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id HAA23271 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 25 Nov 1997 20:10:00 +1100, Bruce Evans wrote: >>The PIC which ultimately receives the electrical signal as output from >> the OR gate has no care for falling edges, only rising ones. > >It does care. After an irq has been acked, the edge latch remains set >until the irq goes low (or at least until it is low when sampled on the >next bus clock cycle). The handler must not return with the edge latch >set, at least for 16x50 devices, since if the edge latch is set then >there must be a device irq and returning would give up the only chance >of handling the irq. I don't see the potential for that problem with FIFOed UARTs where several have their INT output ORed on a multiport interrupt sharing card. Perhaps with non-FIFOed UARTS. One of my objectives is implementing input burst mode for 550 (or better) UARTs. A second driver called sio550.c could shed the legacy 8250/16450 baggage. That's not only reasonable, it's even wise given the prevalence of 550s and higher in the market today. And as far as the edge latch goes, the handler apparently *can* safely return with the edge latch set if there was a down/up transition on the IRQ line before EOI. Although that seems unlikely because of the relatively large time needed to refill any UART to its FIFO trigger level after draining it once, perhaps theoretically it could happen on a multiport card where you've acked your interrupt, drained all the UARTs (only once, not looping for a second pass), and then receive a new interrupt from one of the UARTs you've already drained. I gather that is the case you are concerned about. If you can't reach the last UART before INT is raised a second time by a previously drained UART, then you are saturated with serial interrupts and your machine would be overloaded to the point of doing no useful work except servicing serial interrupts. That is the only case where you would never have a down/up transition on the IRQ line after clearing the INT output of the last UART, and then the issue of a lost interrupt becomes moot anyway. But in the non-pathological case of a machine which is able to do other useful work, by clearing the INT output of the last UART before any of the previously drained UARTs can raise their INT output again, you will have at least one down/up transition on the IRQ line. If you agree with following writer's conclusion, the handler *can* safely issue EOI and return after making only one pass to drain the UARTs. Attributed to Chris Hall (chris@locomotive.com) 2. The Jargon An interrupt source, fed into an 8259A, is known as an IRQ -- Interrupt Request. An 8259A has 8 IRQ inputs. The 8 IRQ inputs are fed into an 8 bit Interrupt Request Register (IRR), via some "rising edge" detection logic (8 bit Edge Sense Register -- ESR). The 8259A can be told to mask off any of the IRQ. The 8259A has an 8 bit Interrupt Mask Register (IMR). A one bit in the IMR masks off the corresponding IRQ. To perform its priority arbitration the 8259A has an 8 bit In Service Register (ISR). In the register a bit is set to 1 when the corresponding interrupt has been passed to the CPU, and the CPU has not yet signalled End of Interrupt (EOI) The CPU interrupt input is known as INTR. The 8259A interrupt output is known as INT, which is connected to the CPU (wait for it) INTR, or to another 8259A's IRQ. The 8 IRR bits are ANDed with the NOT of the IMR, giving the interrupt request input to the priority arbitration logic. Reading between the lines, there is an INT latch, which is set by the OR of the bits of (IRR AND NOT IMR) higher than the highest priority bit in the ISR. On an original PC there are 8 possible interrupt sources IRQ0 to IRQ7, fed into one 8259A (I/O address #020..#03F). On AT's and beyond, there are 16 possible interrupt sources IRQ0 to IRQ15, fed into two 8259A's. One 8259A (known as #1, I/O address #020..#03F) is the "Master" and the other is a "Slave" (known as #2, I/O address #0A0..#0BF). Only the Master's INT is connected to the CPU's INTR. The Slave's INT is connected to the Master's IRQ2. 3. The Mechanisms The PC sets the 8259A into: * Edge Triggered Interrupts * Cascaded (on AT and later) ; Single (on earlier machines) * Not Special Fully Nested (to do with Slave 8259A, see below) * Not Buffered Normal EOI (Not Automatic EOI on INTA) With this in mind, we will start with the simple cases, and work up. 3.1 One 8259A, All IRQ Unmasked, No Interrupts In Service and None Active. So we start from the simplest possible quiescent state. The sequence of actions is as follows: 0 The ESR, ISR, IRR and IMR are all zero. 1 IRQ3 becomes active (goes to 1) 2 B3 of the ESR is set to 1 3 B3 of the IRR is set to 1 4 B3 of the IMR is 0, so the IRR B3 is passed to the priority arbitration logic. 5 All bits of the ISR are 0 (no interrupts are in service), so the priority arbitration logic sets the INT latch -- so the INT output is set active. 6 Eventually the CPU issues the first of two INTA cycles. The contents of the IRR are frozen. The 8259A selects the highest priority IRR (B3) and sets the corresponding ISR (B3). 7 Setting B3 of the ISR clears B3 of the ESR. 8 The CPU issues the second of two INTA cycles. The 8259A issues the interrupt vector associated with the highest priority ISR (B3). The contents of the IRR are unfrozen. 9 The INT latch is cleared -- so the INT output is set inactive. 10 B3 of the IRR is set to 0 (IRR is unfrozen and B3 of ESR is zero). 11 At some time in the future, the CPU issues an EOI command, which clears B3 of the ISR. IRQ3 can remain active beyond step 10, without generating any further interrupts -- because B3 of IRR has been cleared. To produce another interrupt requires IRQ3 to go inactive (0), and then active (1) again. 3.2 Meaning of "Edge Triggered Interrupt Mode" The behavior of the ESR, IRR and ISR described above is what happens in the famous Edge Triggered Interrupt Mode. The purpose is to allow for IRQ signals to be short down/up pulses. When the 8259A is reset the ESR is set to zero. An upward transition of the IRQ sets the corresponding ESR bit to 1, which allows the IRQ state to be copied to the IRR -- provoking the interrupt. When the interrupt is acknowledged the ISR bit is set, which resets the ESR bit, which forces the IRR bit to zero -- irrespective of the IRQ. So even if IRQ is still 1 when the ISR bit is cleared, at End of Interrupt, no further interrupts will be generated. 3.3 What Happens if IRQ Changes with the Interrupt is In Service It is clear what happens if IRQ does not do any further down/up transitions until after EOI. It is OK for IRQ to go down before EOI, but going up again is not explicitly described in the manuals. If a down/up IRQ transition cannot be prevented before EOI, then it can be (reasonably safely) assumed that this will generate a further interrupt after EOI -- provided the IRQ is still up (active, 1) at EOI. Multiple down/up transitions can be assumed to have the same effect. From owner-freebsd-hackers Wed Nov 26 07:33:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA24600 for hackers-outgoing; Wed, 26 Nov 1997 07:33:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from consys.com (consys.com [209.60.202.194]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA24595 for ; Wed, 26 Nov 1997 07:33:37 -0800 (PST) (envelope-from rcarter@consys.com) Received: from dnstoo.consys.com (dnstoo.ConSys.COM [209.60.202.195]) by consys.com (8.8.6/8.8.6) with ESMTP id IAA08636; Wed, 26 Nov 1997 08:32:18 -0700 (MST) Received: from dnstoo.consys.com (localhost [127.0.0.1]) by dnstoo.consys.com (8.8.8/8.8.6) with ESMTP id IAA17419; Wed, 26 Nov 1997 08:33:31 -0700 (MST) Message-Id: <199711261533.IAA17419@dnstoo.consys.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Julian Elischer cc: hackers@freebsd.org Subject: Re: issetugid(2) In-reply-to: Your message of "Tue, 25 Nov 1997 17:59:16 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Nov 1997 08:33:30 -0700 From: "Russell L. Carter" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk } }This has broken all sorts of things here. }I thought that the syscall interface for 2.2.x was being kept }unchanged. }This call makes it impossible to run binaries (e.g. vi) }compiled under 2.2.5+ on a 2.2.2 machine. }Surely the library routine that calls this }should cope with it not being in the kernel, }in the same way that Peter did his new syscalls. } }was this considered teh 'correct thing to do?' }was there discussion? } }I must have dismissed it and now it's bitten me :( } }I have many machiens on people's desks here running everything }from 2.1.0 to 2.2.5, but teh chroot environments they use are all }2.2.2. I was upgrading the chroot environment to 2.2.5(+) but }it can only be used on the newest machines, and I don't want to have to }upgrade all those machines..! } }Peter, how did you trap your new syscalls? (i can't even remember }which they were) }I'll see if I can work up a similar workaround if I can find a reference. } } }julian }(GRRR) Satoshi sent a mail about October 30th, wondering why this hadn't caused people problems. I ran into it yesterday, cvsupping a 6 month old 2.2-STABLE to whatever it is today. The buildworld and installworld went without problems but when I tried to login to user accounts or launch another xterm, oops! Bash wants issetugid. So part of the reason for this particular email is to put a note in the mail archives: make sure you rebuild bash when you update to 2.2.5+! Oh, and if I didn't have SSH configured for root, this would have been a lot more pain as the system in question doesn't have an easily accessed console... (csh doesn't need issetugid...) Russell From owner-freebsd-hackers Wed Nov 26 09:30:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA03280 for hackers-outgoing; Wed, 26 Nov 1997 09:30:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA03269 for ; Wed, 26 Nov 1997 09:30:18 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id SAA26409; Wed, 26 Nov 1997 18:30:06 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id SAA17239; Wed, 26 Nov 1997 18:20:59 +0100 (MET) Message-ID: <19971126182058.04145@uriah.heep.sax.de> Date: Wed, 26 Nov 1997 18:20:58 +0100 From: J Wunsch To: freebsd-hackers@FreeBSD.ORG Cc: darius@senet.com.au Subject: Re: Shared Libraries and debugging Reply-To: Joerg Wunsch References: <199711250748.SAA16393@holly.rd.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199711250748.SAA16393@holly.rd.net>; from Daniel J. O'Connor on Tue, Nov 25, 1997 at 06:18:59PM +1030 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Daniel J. O'Connor wrote: > I was fiddling with some code which links against shared libraries, and > noticed that when viewing a core dumb with gdb, it doesn't load the symbols > from the shared libraries, so consequently debugging the program is kind of > akward. I usually set a breakpoint at main(), run it till there, and then voila!, you can also specify breakpoints at shared lib functions... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Nov 26 09:55:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA05088 for hackers-outgoing; Wed, 26 Nov 1997 09:55:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from inertia.dfacades.com (inertia.dfacades.com [207.155.93.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA05081 for ; Wed, 26 Nov 1997 09:55:39 -0800 (PST) (envelope-from dleeds@dfacades.com) Received: (from dleeds@localhost) by inertia.dfacades.com (8.8.7/8.8.7) id JAA08980 for hackers@freebsd.org; Wed, 26 Nov 1997 09:59:01 -0800 (PST) From: Daniel Leeds Message-Id: <199711261759.JAA08980@inertia.dfacades.com> Subject: bpf and clog To: hackers@freebsd.org Date: Wed, 26 Nov 1997 09:59:01 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL35 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk im tring to get clog up and running and am running into a problem that says /dev/bpf0 is not configured. i did a MAKEDEV bpf0 and it does exist. is there something i have to add to the kerenel for bpffilter ??? thanks for any help From owner-freebsd-hackers Wed Nov 26 10:22:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA06782 for hackers-outgoing; Wed, 26 Nov 1997 10:22:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA06759 for ; Wed, 26 Nov 1997 10:22:34 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id TAA27650 for freebsd-hackers@FreeBSD.ORG; Wed, 26 Nov 1997 19:22:32 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id TAA17595; Wed, 26 Nov 1997 19:07:09 +0100 (MET) Message-ID: <19971126190709.50923@uriah.heep.sax.de> Date: Wed, 26 Nov 1997 19:07:09 +0100 From: J Wunsch To: freebsd-hackers@FreeBSD.ORG Subject: Re: Screen/font related questions... Reply-To: Joerg Wunsch References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88 In-Reply-To: ; from Andrzej Bialecki on Wed, Nov 26, 1997 at 12:40:53AM +0100 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Andrzej Bialecki wrote: > Could somebody explain me in a few words what screenmaps are for? I'd read > the manpage but it's nonexistent... When should/can I use them? You might wanna use them when you can't load a font, but yet have a desire to display something different than the default IBM437 codeset. This eg. applies to Hercules cards. If you can load a font, that's preferable since just remapping doesn't make you all the desired characters available. Fixing your other problem in a more elegant way is IMHO impossible with the current way syscons is handling fonts (which restricts the number of simultaneously available characters to 256). pcvt addresses this problem by using 512 character cells, at the expense of having only 8 colors available. (It's also using screen mapping all the time so ISO 8859-1 or its closest approximation in IBM437 is the default.) I remember Søren mentioning the idea to use softfonts and a display running in graphics mode as another way out. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Nov 26 10:24:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA06955 for hackers-outgoing; Wed, 26 Nov 1997 10:24:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA06933; Wed, 26 Nov 1997 10:24:18 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id SAA07459; Wed, 26 Nov 1997 18:19:44 +0100 From: Luigi Rizzo Message-Id: <199711261719.SAA07459@labinfo.iet.unipi.it> Subject: udp question related to icmp... To: hackers@freebsd.org Date: Wed, 26 Nov 1997 18:19:43 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, just now i tried to use connect on a SOCK_DGRAM to avoid having to specify the destination address every time. Things worked perfectly with multicast, and by pure luck they worked while i was doing testing on my machine. When i tried with a remote machine which was not listening, a problem came out: the remote machine was (presumably) sending back ICMP port unreachable, which caused the kernel to disable further writes to that socket, so after the first few packets, nothing went out anymore. Further investigation in vat sources (net.cc) shows that the problem is well known (although not mentioned in the manpages). I was almost going to apply the fix to the kernel mentioned in vat's net.cc when I realized that after all it is not such a terrible idea to report failures (due to ICMP port unreachable) up to the application, if nothing else to avoid flooding the net with undesired data. So... I started writing this email looking for a fix, but now I guess I just have to point this behaviour to your attention... Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Wed Nov 26 10:39:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA08149 for hackers-outgoing; Wed, 26 Nov 1997 10:39:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA08142 for ; Wed, 26 Nov 1997 10:39:07 -0800 (PST) (envelope-from benedict@echonyc.com) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id NAA09536; Wed, 26 Nov 1997 13:38:38 -0500 (EST) Date: Wed, 26 Nov 1997 13:38:38 -0500 (EST) From: Snob Art Genre To: Daniel Leeds cc: hackers@FreeBSD.ORG Subject: Re: bpf and clog In-Reply-To: <199711261759.JAA08980@inertia.dfacades.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 26 Nov 1997, Daniel Leeds wrote: > > > im tring to get clog up and running and am running into a problem > that says /dev/bpf0 is not configured. i did a MAKEDEV bpf0 and it > does exist. > > is there something i have to add to the kerenel for bpffilter Absolutely: % grep bpfilter /usr/src/sys/i386/conf/LINT # The `bpfilter' pseudo-device enables the Berkeley Packet Filter. Be pseudo-device bpfilter 4 #Berkeley packet filter You probably don't need four bpf devices configured, so feel free to change the number. Ben "You have your mind on computers, it seems." From owner-freebsd-hackers Wed Nov 26 10:45:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA08699 for hackers-outgoing; Wed, 26 Nov 1997 10:45:20 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA08637; Wed, 26 Nov 1997 10:44:52 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id SAA07496; Wed, 26 Nov 1997 18:40:17 +0100 From: Luigi Rizzo Message-Id: <199711261740.SAA07496@labinfo.iet.unipi.it> Subject: Re: udp question related to icmp... To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Wed, 26 Nov 1997 18:40:17 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <199711261719.SAA07459@labinfo.iet.unipi.it> from "Luigi Rizzo" at Nov 26, 97 06:19:24 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [added -multimedia in Bcc because the problem seems to affect vat...] > Further investigation in vat sources (net.cc) shows that the problem is > well known (although not mentioned in the manpages). I was almost going > to apply the fix to the kernel mentioned in vat's net.cc when I > realized that after all it is not such a terrible idea to report failures > (due to ICMP port unreachable) up to the application, if nothing else > to avoid flooding the net with undesired data. more on this: from vat's sources (net.cc): * This bug originated at CSRG in Berkeley * and was present in the BSD Reno networking * code release. It has since been fixed * in 4.4BSD and OSF-3.x. It is know to remain * in AIX-4.1.3. * * A fix is to change the following lines from * kern/uipc_socket.c: * * if (so_serror) * snderr(so->so_error); * * to: * * if (so->so_error) { * error = so->so_error; * so->so_error = 0; * splx(s); * goto release; * } looking at our kern/uipc_socket.c (i am running 2.2.1) it appears that the fix has been applied in some way only in soreceive, not in sosend. So I am a bit unsure about the above comment related to 4.4BSD ... this would also explain why, in some cases, when I fire vat using unicast before the remote party, i cannot be heard... Luigi > > So... I started writing this email looking for a fix, but now I guess I > just have to point this behaviour to your attention... > > Cheers > Luigi > -----------------------------+-------------------------------------- > Luigi Rizzo | Dip. di Ingegneria dell'Informazione > email: luigi@iet.unipi.it | Universita' di Pisa > tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) > fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ > _____________________________|______________________________________ > From owner-freebsd-hackers Wed Nov 26 10:53:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA09272 for hackers-outgoing; Wed, 26 Nov 1997 10:53:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from marlin.exis.net (root@marlin.exis.net [205.252.72.102]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA09261 for ; Wed, 26 Nov 1997 10:53:48 -0800 (PST) (envelope-from stefan@exis.net) Received: from sailfish.exis.net (sailfish.exis.net [205.252.72.104]) by marlin.exis.net (8.8.4/8.8.5) with SMTP id NAA02369; Wed, 26 Nov 1997 13:53:37 -0500 Date: Wed, 26 Nov 1997 13:37:35 -0500 (EST) From: Stefan Molnar To: Daniel Leeds cc: hackers@FreeBSD.ORG Subject: Re: bpf and clog In-Reply-To: <199711261759.JAA08980@inertia.dfacades.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > im tring to get clog up and running and am running into a problem > that says /dev/bpf0 is not configured. i did a MAKEDEV bpf0 and it > does exist. > > is there something i have to add to the kerenel for bpffilter Yes there is a kernal option to add option bpfilter n n= the number of interfaces you wanto to snoop on Stefan From owner-freebsd-hackers Wed Nov 26 10:55:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA09399 for hackers-outgoing; Wed, 26 Nov 1997 10:55:26 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from spokane.vmunix.com (p15a.radium.sentex.ca [207.245.212.80]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA09365 for ; Wed, 26 Nov 1997 10:55:03 -0800 (PST) (envelope-from mark@spokane.vmunix.com) Received: (from mark@localhost) by spokane.vmunix.com (8.8.8/8.8.7) id NAA00951; Wed, 26 Nov 1997 13:56:50 -0500 (EST) Message-ID: <19971126135649.31538@vmunix.com> Date: Wed, 26 Nov 1997 13:56:49 -0500 From: Mark Mayo To: hackers@freebsd.org Subject: Japan FreeBSD RC5!! Wow! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e X-Operating-System: FreeBSD 3.0-CURRENT i386 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Wow, I just peeded at the latest RC564 stats, and the Japan FreeBSD Users Group is kicking ass!! As of right now, they're the #1 team at their current rate. #7 overall, but it looks like within 1 or 2 days they'll be at #5 or so. Very impressive. I knew FreeBSD was a pretty hot ticket in Japan, but I had no idea it was this hot!! Team-FreeBSD is also doing quite well, 16th overall but moving up - 11th best rate yesterday. Good stuff as well. It really looks good for FreeBSD when we're placing high up in the RC5 stats. Now we just have to get the operating system numbers up, although it looks like we'll finally pass OS/2 in the next few days. Phew! -Mark -- ------------------------------------------------------------------------ Mark Mayo mark@vmunix.com RingZero Comp. http://www.vmunix.com/mark finger mark@vmunix.com for my PGP key and GCS code ------------------------------------------------------------------------ Win95/NT - 32 bit extensions and a graphical shell for a 16 bit patch to an an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition. -UGU From owner-freebsd-hackers Wed Nov 26 11:46:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA13607 for hackers-outgoing; Wed, 26 Nov 1997 11:46:16 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA13602 for ; Wed, 26 Nov 1997 11:46:12 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id MAA18246; Wed, 26 Nov 1997 12:50:26 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpd018237; Wed Nov 26 12:50:22 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id MAA13372; Wed, 26 Nov 1997 12:45:34 -0700 (MST) From: Terry Lambert Message-Id: <199711261945.MAA13372@usr08.primenet.com> Subject: Re: issetugid(2) To: rcarter@consys.com (Russell L. Carter) Date: Wed, 26 Nov 1997 19:45:34 +0000 (GMT) Cc: julian@whistle.com, hackers@freebsd.org In-Reply-To: <199711261533.IAA17419@dnstoo.consys.com> from "Russell L. Carter" at Nov 26, 97 08:33:30 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Satoshi sent a mail about October 30th, wondering why this hadn't > caused people problems. I ran into it yesterday, cvsupping a > 6 month old 2.2-STABLE to whatever it is today. The buildworld > and installworld went without problems but when I tried to > login to user accounts or launch another xterm, oops! Bash wants > issetugid. OK, I give up. What the heck is it useful for, besides giving a false sense of security to user space programs which may be replaced and thus choose not to cooperate with the security model that it requires? And just what is the security model it requires anyway? Seems to be utterly useless to me... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Nov 26 11:52:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA14111 for hackers-outgoing; Wed, 26 Nov 1997 11:52:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA14061; Wed, 26 Nov 1997 11:51:54 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id GAA00533; Wed, 26 Nov 1997 06:06:55 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd000481; Wed Nov 26 06:06:43 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id MAA13523; Wed, 26 Nov 1997 12:49:45 -0700 (MST) From: Terry Lambert Message-Id: <199711261949.MAA13523@usr08.primenet.com> Subject: Re: BIND 8.1.1 To: shimon@simon-shapiro.org Date: Wed, 26 Nov 1997 19:49:44 +0000 (GMT) Cc: tlambert@primenet.com, peter@freebsd.org, hackers@freebsd.org, julian@whistle.com, steve@visint.co.uk, nate@mt.sri.com In-Reply-To: from "Simon Shapiro" at Nov 25, 97 09:09:17 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > The big pain on an 8.x upgrade is the config file format has > changed > > (there's good reasons for this, though it remains annoying no matter > > how good the reasons). > > You are not forgetting the integration of the new resolver library into > libc, new header files, etc. Right? Users only have to worry about the config files, since that's the only "upgrade visible" piece. The work of integrating it into FreeBSD has to happen sooner or later, since 4.9.6 is the last release on that tree, and the cost is going to remain constant. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Nov 26 12:11:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA15467 for hackers-outgoing; Wed, 26 Nov 1997 12:11:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA15457 for ; Wed, 26 Nov 1997 12:11:07 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id GAA03095; Wed, 26 Nov 1997 06:27:28 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd003084; Wed Nov 26 06:27:25 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id NAA14950; Wed, 26 Nov 1997 13:10:29 -0700 (MST) From: Terry Lambert Message-Id: <199711262010.NAA14950@usr08.primenet.com> Subject: Re: BIND 8.1.1 To: shimon@i-connect.net Date: Wed, 26 Nov 1997 20:10:29 +0000 (GMT) Cc: hackers@freebsd.org In-Reply-To: from "Simon Shapiro" at Nov 26, 97 10:47:46 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 26 Nov 1977, Simon Shapiro wrote: > * Put BIND 8.1.x in /usr/ports as a port [ ... ] > > On Tue, 25 Nov 1997, Simon Shapiro wrote: > >> You are not forgetting the integration of the new resolver library > >> into > >> libc, new header files, etc. Right? These statements are incompatible. BIND 8.1.x requires integration into libc. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Nov 26 12:13:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA15640 for hackers-outgoing; Wed, 26 Nov 1997 12:13:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA15635 for ; Wed, 26 Nov 1997 12:13:16 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA01989 (5.67b/IDA-1.5 for hackers@FreeBSD.ORG); Wed, 26 Nov 1997 21:13:15 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id TAA02122; Wed, 26 Nov 1997 19:25:39 +0100 (MET) From: Wilko Bulte Message-Id: <199711261825.TAA02122@yedi.iaf.nl> Subject: Re: problem mounting /cdrom w/ 2.2.5-R (fwd) To: joerg_wunsch@uriah.heep.sax.de Date: Wed, 26 Nov 1997 19:25:39 +0100 (MET) Cc: hackers@FreeBSD.ORG In-Reply-To: <19971126112610.49923@uriah.heep.sax.de> from "J Wunsch" at Nov 26, 97 11:26:10 am X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As J Wunsch wrote... > As Burton Sampley wrote: > > > Here's my assumption: > > > > I must have attempted to mount the cdrom too soon after loading the cdrom > > in the drive. It's an old 4X SCSI Toshiba CDROM drive. Instead of giving > > me a device not ready error to the console (BTW, I just reviewed > > /var/log/messages where it DID give a NOT READY error from /kernel) it > > gave a device not configured error message. > > Device not ready errors are silently discarded when opening a device, > and ENXIO (`Device not configured') is returned. AFAIK, this is the > `politically correct' behaviour. ENXIO can mean quite a number of > errors (unfortunately). > > And yes, Toshiba drives require quite some time until they are ready Very much so yep. > after the insertion of a new medium. As a general rule, wait until > the yellow LED went off, and start the mount command then. It would > be better if they indicated a `Logical unit is in the process of > becoming ready' instead (which FreeBSD repeatedly retries until > success, or until a different message appears). And it's not only the 4x Toshiba, the 12x XM5701 has the same quirk.. Bah. I'm going to try the 12x Toshiba with Digital firmware in it to see if this makes any difference. Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko @ yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ---------------- Support your local daemons: run [Free,Net]BSD Unix ------ From owner-freebsd-hackers Wed Nov 26 12:13:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA15661 for hackers-outgoing; Wed, 26 Nov 1997 12:13:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from spoon.beta.com (spoon.beta.com [199.165.180.33] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA15634 for ; Wed, 26 Nov 1997 12:13:16 -0800 (PST) (envelope-from mcgovern@spoon.beta.com) Received: from spoon.beta.com (localhost [127.0.0.1]) by spoon.beta.com (8.8.7/8.8.7) with ESMTP id PAA02709 for ; Wed, 26 Nov 1997 15:12:48 -0500 (EST) (envelope-from mcgovern@spoon.beta.com) Message-Id: <199711262012.PAA02709@spoon.beta.com> To: hackers@freebsd.org Subject: Union and Portal FSs Date: Wed, 26 Nov 1997 15:12:48 -0500 From: "Brian J. McGovern" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Just out of curiousity, how "decayed" are the Union and Portal filesystems,and, more importantly, is anyone working on them? As my next exercise in futility (after character device drivers), I figured I'd try taking on a file system. Anyone care to comment where they stand, so I can make an educated decision as to whether I should go for it? -Brian From owner-freebsd-hackers Wed Nov 26 12:30:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA16707 for hackers-outgoing; Wed, 26 Nov 1997 12:30:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA16699 for ; Wed, 26 Nov 1997 12:30:36 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA22556; Wed, 26 Nov 1997 12:21:56 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd022553; Wed Nov 26 12:21:50 1997 Date: Wed, 26 Nov 1997 12:19:37 -0800 (PST) From: Julian Elischer To: S?ren Schmidt cc: hackers@FreeBSD.ORG Subject: Re: DEVFS/SLICE passes milestone In-Reply-To: <199711261356.OAA05520@sos.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id MAA16703 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Unfortunatly the existing code is inherrently broken by design. After discussing this with PHK we agreed that the two changes were intertwined. DEVFS works fine without the slice changes, except that you can't do disk partitions because of the broken-ness. i.e it works fine for diskless systems. You can do devfs without SLICES but it won't help you too much because of this. I have been consulting others on this as I go.. On Wed, 26 Nov 1997, S?ren Schmidt wrote: > In reply to Julian Elischer who wrote: > > > > San francisco, Early Tuesday morning, > > > > DEVFS passed a critical milestone today when my PC here booted up a kernel > > using only DEVFS based devices. The kernel used DEVFS to find the root > > device and mount it, finding it by NAME (sd1s1a) rather than by > > major/minor numbers. The disk devices were all created dynamically using > > the "slice" subsystem so that all IO to the disks was flowing through the > > SLICE system's "IOreq" entrypoints rather than the older disk 'strategy()' > > entrypoints. > > > > The disk partitionning is being handled by separate MBR and DISKLABEL > > SLICE objects, rather than by the older disk 'slicing' code. > > The drivers have SLICE entrypoints added, in addition to the usual > > entrypoints, which are no longer being used. > > teh SLICE code is also known as "storage layering". > > Klokkerholm early wednesday afternoon, > > I would like if you where concentrating on makeing DEVFS work, then > started to play with new SLICE code. Now we get a monster patch that > noone has the time to deal with (you should know that now you have > Terry onboard :) ), and thereby has much less chance of getting into > the sources. > We asked you to clean up DEVFS and get it to work, or it would be > thrown out, not to pull in further "enhancements"..... > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team > Even more code to hack -- will it ever end > .. > From owner-freebsd-hackers Wed Nov 26 12:35:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA17046 for hackers-outgoing; Wed, 26 Nov 1997 12:35:54 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA17039 for ; Wed, 26 Nov 1997 12:35:50 -0800 (PST) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.8/8.8.8) id VAA06175; Wed, 26 Nov 1997 21:36:11 +0100 (MET) (envelope-from sos) Message-Id: <199711262036.VAA06175@sos.freebsd.dk> Subject: Re: DEVFS/SLICE passes milestone In-Reply-To: from Julian Elischer at "Nov 26, 97 12:19:37 pm" To: julian@whistle.com (Julian Elischer) Date: Wed, 26 Nov 1997 21:36:10 +0100 (MET) Cc: sos@freebsd.dk, hackers@FreeBSD.ORG From: Søren Schmidt Reply-to: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Julian Elischer who wrote: > Unfortunatly the existing code is inherrently broken by design. Now you tell us :(, that is the exact reason for our reservations on what goes in and what does not nowadays.... > After discussing this with PHK we agreed that the two changes were > intertwined. Well, depends on viewpoint, but I'll buy that... > DEVFS works fine without the slice changes, except that > you can't do disk partitions because of the broken-ness. > i.e it works fine for diskless systems. > > You can do devfs without SLICES but it won't help you too much because of > this. > > I have been consulting others on this as I go.. I know :), I just wanted to get this straight, we don't want a new "inherrently broken by design" subsystem again. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Wed Nov 26 13:01:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18856 for hackers-outgoing; Wed, 26 Nov 1997 13:01:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA18841 for ; Wed, 26 Nov 1997 13:00:57 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA23632; Wed, 26 Nov 1997 12:55:33 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd023629; Wed Nov 26 12:55:32 1997 Date: Wed, 26 Nov 1997 12:53:19 -0800 (PST) From: Julian Elischer To: S?ren Schmidt cc: hackers@FreeBSD.ORG Subject: Re: DEVFS/SLICE passes milestone In-Reply-To: <199711262036.VAA06175@sos.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id NAA18842 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 26 Nov 1997, S?ren Schmidt wrote: > In reply to Julian Elischer who wrote: > > Unfortunatly the existing code is inherrently broken by design. > > Now you tell us :(, that is the exact reason for our reservations > on what goes in and what does not nowadays.... It's not DEVFS that's broken, it's the existing slice system. it's too intertwined with itself. It's close to impossible to untangle it enough to make things happen in the order needed. an example.. slices are only noticed when you open the device. How do you open /dev/rsd0a if you don't know that it exists? The present code works because /dev/has entries that are always present, whether or not the system knows that the slice exists. with dynamic assignment of new slice types and partitionning schemes (e.g. raid) the device node may not exist.. then how do you open it to find that the slice exists? Dynamic devices are inherrently incompatible with devices that only make their nodes when you OPEN them. (you can't see the device because it isn't open, you can't open it becasue you can't see it) The new code is a LOT easier to read than the existing SLICE code as it breaks the functionality up into handlers, for each kind of slice so it's not all mashed in together. it allows us to dynamically and easily add new layers e.g. raid, mirroring etc. with minimal work. The DEVFS changes are separate, but as I don't run a diskless system, I cannot go further with DEVFS until I have the SLICE code fixed. Now that that is going, I have a chance of getting DEVFS production grade. > > > After discussing this with PHK we agreed that the two changes were > > intertwined. > > Well, depends on viewpoint, but I'll buy that... PHK tried to rewrite the slice code, but ended up needing a devfs (he wrote a 'make my device-daemon' (poor-man's devfs) I tried to get devfs up to production quality, but needed a new SLICE layer. The obvious answer is to merge the two efforts. > > > DEVFS works fine without the slice changes, except that > > you can't do disk partitions because of the broken-ness. > > i.e it works fine for diskless systems. > > > > You can do devfs without SLICES but it won't help you too much because of > > this. > > > > I have been consulting others on this as I go.. > > I know :), I just wanted to get this straight, we don't want a new > "inherrently broken by design" subsystem again. devfs isn't inherrently broken. it's just incompatible with BDE's slice code. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team > Even more code to hack -- will it ever end > .. > From owner-freebsd-hackers Wed Nov 26 13:09:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA19653 for hackers-outgoing; Wed, 26 Nov 1997 13:09:52 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA19643 for ; Wed, 26 Nov 1997 13:09:48 -0800 (PST) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 25868 invoked by uid 1001); 26 Nov 1997 21:09:41 +0000 (GMT) To: tlambert@primenet.com Cc: hackers@FreeBSD.ORG Subject: Re: BIND 8.1.1 In-Reply-To: Your message of "Wed, 26 Nov 1997 20:10:29 +0000 (GMT)" References: <199711262010.NAA14950@usr08.primenet.com> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Wed, 26 Nov 1997 22:09:41 +0100 Message-ID: <25866.880578581@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > These statements are incompatible. BIND 8.1.x requires integration > into libc. Not as long as you only want to use named/named-xfer. And that's what a lot of people do. A port would be just fine for this. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-hackers Wed Nov 26 14:28:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA25073 for hackers-outgoing; Wed, 26 Nov 1997 14:28:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.6.51]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA25068 for ; Wed, 26 Nov 1997 14:28:03 -0800 (PST) (envelope-from plm@muon.xs4all.nl) Received: from asterix.xs4all.nl (root@asterix.xs4all.nl [194.109.6.11]) by smtp1.xs4all.nl (8.8.6/XS4ALL) with ESMTP id XAA03640 for ; Wed, 26 Nov 1997 23:27:54 +0100 (MET) Received: from muon.xs4all.nl (uucp@localhost) by asterix.xs4all.nl (8.8.6/8.8.6) with UUCP id XAA20008 for freebsd.org!freebsd-hackers; Wed, 26 Nov 1997 23:23:57 +0100 (MET) Received: by muon.xs4all.nl id m0xanma-0003g4C (Debian Smail-3.2 1996-Jul-4 #2); Wed, 26 Nov 1997 21:10:00 +0100 (CET) To: freebsd-hackers@freebsd.org Subject: Re: DOES JDK1.1.3 EXIST FOR FreeBSD? References: <87lnyb5ysj.fsf@totally-fudged-out-message-id> From: Peter Mutsaers Date: 26 Nov 1997 21:10:00 +0100 In-Reply-To: Nate Williams's message of Tue, 25 Nov 1997 11:15:27 -0700 Message-ID: <87hg8zs9gn.fsf@muon.xs4all.nl> Lines: 14 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> On Tue, 25 Nov 1997 11:15:27 -0700, Nate Williams said: >> Please reply to me personally, as I do not read this mailing list. NW> No, but folks have stated the the Linux JDK1.1.3 works well NW> under emulation. I tried it last night. It does work for local applets, but the appletviewer used with remote URL's didn't seem to work. It does work on Linux... :-( -- /\_/\ ( o.o ) Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know ) ^ ( plm@xs4all.nl | the Netherlands | what I'm doing. From owner-freebsd-hackers Wed Nov 26 15:24:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA29178 for hackers-outgoing; Wed, 26 Nov 1997 15:24:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iq.org (proff@profane.iq.org [203.4.184.222]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA29173 for ; Wed, 26 Nov 1997 15:24:16 -0800 (PST) (envelope-from proff@iq.org) Received: (qmail 5570 invoked by uid 110); 26 Nov 1997 23:22:20 -0000 Date: 26 Nov 1997 23:22:20 -0000 Message-ID: <19971126232220.5569.qmail@iq.org> From: Julian Assange To: hackers@freebsd.org Subject: detecting devfs from userland? Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there anyway to detect if the running kernel was built with -DDEVFS, other than trying to mount -t devfs ? (i.e a way that doesn't require root privs? sysctl -a is of no use here. Cheers, Julian. From owner-freebsd-hackers Wed Nov 26 16:11:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA02102 for hackers-outgoing; Wed, 26 Nov 1997 16:11:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA02090 for ; Wed, 26 Nov 1997 16:10:54 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id QAA02771; Wed, 26 Nov 1997 16:10:42 -0800 (PST) Message-ID: <19971126161042.30719@hydrogen.nike.efn.org> Date: Wed, 26 Nov 1997 16:10:42 -0800 From: John-Mark Gurney To: Julian Assange Cc: hackers@FreeBSD.ORG Subject: Re: detecting devfs from userland? References: <19971126232220.5569.qmail@iq.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <19971126232220.5569.qmail@iq.org>; from Julian Assange on Wed, Nov 26, 1997 at 11:22:20PM -0000 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Julian Assange scribbled this message on Nov 26: > > Is there anyway to detect if the running kernel was built with > -DDEVFS, other than trying to mount -t devfs ? (i.e a way that > doesn't require root privs? sysctl -a is of no use here. lsvfs.. don't worry, didn't know about it until bruce mentioned it to me.. :) -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-hackers Wed Nov 26 16:26:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA03339 for hackers-outgoing; Wed, 26 Nov 1997 16:26:23 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA03331 for ; Wed, 26 Nov 1997 16:26:20 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id RAA23564; Wed, 26 Nov 1997 17:26:19 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd003036; Wed Nov 26 15:30:04 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id PAA21453; Wed, 26 Nov 1997 15:11:50 -0700 (MST) From: Terry Lambert Message-Id: <199711262211.PAA21453@usr08.primenet.com> Subject: Re: DEVFS/SLICE passes milestone To: sos@freebsd.dk Date: Wed, 26 Nov 1997 22:11:50 +0000 (GMT) Cc: julian@whistle.com, hackers@freebsd.org In-Reply-To: <199711262036.VAA06175@sos.freebsd.dk> from "S?ren Schmidt" at Nov 26, 97 09:36:10 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I know :), I just wanted to get this straight, we don't want a new > "inherrently broken by design" subsystem again. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Inre this comment and the previous comment about my large patches to the filesystem: my union mounts work, do yours? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Nov 26 16:29:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA03614 for hackers-outgoing; Wed, 26 Nov 1997 16:29:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from thought.calbbs.com (thought.calbbs.com [207.71.213.16]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA03607 for ; Wed, 26 Nov 1997 16:29:37 -0800 (PST) (envelope-from brian@smarter.than.nu) Received: from localhost (localhost [127.0.0.1]) by thought.calbbs.com (8.8.7/8.6.12) with SMTP id QAA06023; Wed, 26 Nov 1997 16:26:57 -0800 (PST) Date: Wed, 26 Nov 1997 16:26:57 -0800 (PST) From: "Brian W. Buchanan" X-Sender: brian@thought.calbbs.com To: Julian Assange cc: hackers@freebsd.org Subject: Re: detecting devfs from userland? In-Reply-To: <19971126232220.5569.qmail@iq.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 26 Nov 1997, Julian Assange wrote: > > Is there anyway to detect if the running kernel was built with > -DDEVFS, other than trying to mount -t devfs ? (i.e a way that > doesn't require root privs? sysctl -a is of no use here. dmesg|grep DEVFS -- Brian Buchanan brian@smarter.than.nu No security through obscurity! Demand full source code! 4.4BSD for the masses - http://www.freebsd.org From owner-freebsd-hackers Wed Nov 26 16:42:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA04338 for hackers-outgoing; Wed, 26 Nov 1997 16:42:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA04329 for ; Wed, 26 Nov 1997 16:42:02 -0800 (PST) (envelope-from sef@garth.kithrup.com) Received: from garth.kithrup.com (garth.kithrup.com [205.179.156.41]) by kithrup.com (8.8.8/8.8.7) with ESMTP id QAA07272 for ; Wed, 26 Nov 1997 16:42:01 -0800 (PST) (envelope-from sef@garth.kithrup.com) Received: (from sef@localhost) by garth.kithrup.com (8.8.5/8.7.3) id QAA00355 for hackers@freebsd.org; Wed, 26 Nov 1997 16:41:56 -0800 (PST) Date: Wed, 26 Nov 1997 16:41:56 -0800 (PST) From: Sean Eric Fagan Message-Id: <199711270041.QAA00355@garth.kithrup.com> To: hackers@freebsd.org Subject: procfs patches Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk These are the kernel side of the truss work I've been doing for the past few years. I'm running a 2.2 system with these patches. The truss and procctl programs are at http://www.freebsd.org/~sef/truss -- it works, and even works for linux binaries. (I'm working on even better version, that will be able to print out the arguments in an intelligent fashion, but that's nowhere near ready.) Enjoy. I expect to check this stuff in "soon" (hopefully within a couple of weekends). Note that you need to rebuild libkvm, ps, gdb, and all LKM's -- I kinda paniced one of my systems when I forgot about that, and went multiuser ;). Also note the new file -- sys/pioctl.h. Index: i386/i386/trap.c =================================================================== RCS file: /kithrup/cvs/src/sys/i386/i386/trap.c,v retrieving revision 1.114 diff -u -r1.114 trap.c --- trap.c 1997/11/06 19:28:09 1.114 +++ trap.c 1997/11/15 05:05:46 @@ -49,6 +49,7 @@ #include #include #include +#include #include #include #include @@ -959,6 +960,8 @@ p->p_retval[0] = 0; p->p_retval[1] = frame.tf_edx; + STOPEVENT(p, S_SCE, callp->sy_narg); + error = (*callp->sy_call)(p, args); switch (error) { @@ -1009,6 +1012,14 @@ if (KTRPOINT(p, KTR_SYSRET)) ktrsysret(p->p_tracep, code, error, p->p_retval[0]); #endif + + /* + * This works because errno is findable through the + * register set. If we ever support an emulation where this + * is not the case, this code will need to be revisited. + */ + STOPEVENT(p, S_SCX, code); + } /* Index: kern/init_main.c =================================================================== RCS file: /kithrup/cvs/src/sys/kern/init_main.c,v retrieving revision 1.74 diff -u -r1.74 init_main.c --- init_main.c 1997/11/07 08:52:53 1.74 +++ init_main.c 1997/11/15 05:05:45 @@ -417,6 +417,12 @@ * Charge root for one process. */ (void)chgproccnt(0, 1); + + /* + * Initialize the procfs flags (to 0, of course) + */ + p->p_stops = p->p_stype = p->p_step = 0; + } SYSINIT(p0init, SI_SUB_INTRINSIC, SI_ORDER_FIRST, proc0_init, NULL) Index: kern/kern_exec.c =================================================================== RCS file: /kithrup/cvs/src/sys/kern/kern_exec.c,v retrieving revision 1.68 diff -u -r1.68 kern_exec.c --- kern_exec.c 1997/11/06 19:29:08 1.68 +++ kern_exec.c 1997/11/15 05:05:45 @@ -40,6 +40,7 @@ #include #include #include +#include #include #include #include @@ -338,6 +339,8 @@ * If tracing the process, trap to debugger so breakpoints * can be set before the program executes. */ + STOPEVENT(p, S_EXEC, 0); + if (p->p_flag & P_TRACED) psignal(p, SIGTRAP); Index: kern/kern_exit.c =================================================================== RCS file: /kithrup/cvs/src/sys/kern/kern_exit.c,v retrieving revision 1.60 diff -u -r1.60 kern_exit.c --- kern_exit.c 1997/11/20 19:09:43 1.60 +++ kern_exit.c 1997/11/22 06:55:04 @@ -46,6 +46,7 @@ #include #include #include +#include #include #include #include @@ -113,6 +114,7 @@ register struct proc *q, *nq; register struct vmspace *vm; ele_p ep = exit_list; + extern void procfs_exit(pid_t); if (p->p_pid == 1) { printf("init died (signal %d, exit %d)\n", @@ -155,6 +157,14 @@ #ifdef PGINPROF vmsizmon(); #endif + STOPEVENT(p, S_EXIT, rv); + + /* + * Now that we're back from stopevent(), force a close + * of all open procfs files for this process. + */ + procfs_exit(p->p_pid); + /* * Check if any LKMs need anything done at process exit. * e.g. SYSV IPC stuff Index: kern/kern_sig.c =================================================================== RCS file: /kithrup/cvs/src/sys/kern/kern_sig.c,v retrieving revision 1.35 diff -u -r1.35 kern_sig.c --- kern_sig.c 1997/11/06 19:29:14 1.35 +++ kern_sig.c 1997/11/27 00:34:07 @@ -49,6 +49,7 @@ #include #include #include +#include #include #include #include @@ -743,15 +744,19 @@ register sig_t action; int mask; - if ((u_int)signum >= NSIG || signum == 0) + if ((u_int)signum >= NSIG || signum == 0) { + printf("psignal: signum %d\n", signum); panic("psignal signal number"); + } mask = sigmask(signum); prop = sigprop[signum]; /* - * If proc is traced, always give parent a chance. + * If proc is traced, always give parent a chance; + * if signal event is tracked by procfs, give *that* + * a chance, as well. */ - if (p->p_flag & P_TRACED) + if ((p->p_flag & P_TRACED) || (p->p_stops & S_SIG)) action = SIG_DFL; else { /* @@ -948,6 +953,8 @@ register int signum, mask, prop; for (;;) { + int traced = (p->p_flag & P_TRACED) || (p->p_stops & S_SIG); + mask = p->p_siglist & ~p->p_sigmask; if (p->p_flag & P_PPWAIT) mask &= ~stopsigmask; @@ -956,11 +963,14 @@ signum = ffs((long)mask); mask = sigmask(signum); prop = sigprop[signum]; + + STOPEVENT(p, S_SIG, signum); + /* * We should see pending but ignored signals * only if P_TRACED was on when they were posted. */ - if (mask & p->p_sigignore && (p->p_flag & P_TRACED) == 0) { + if ((mask & p->p_sigignore) && (traced == 0)) { p->p_siglist &= ~mask; continue; } @@ -974,7 +984,8 @@ do { stop(p); mi_switch(); - } while (!trace_req(p) && p->p_flag & P_TRACED); + } while (!trace_req(p) + && p->p_flag & P_TRACED); /* * If the traced bit got turned off, go back up @@ -1118,6 +1129,8 @@ signum, action, ps->ps_flags & SAS_OLDMASK ? ps->ps_oldmask : p->p_sigmask, 0); #endif + STOPEVENT(p, S_SIG, signum); + if (action == SIG_DFL) { /* * Default action, where the default is to kill @@ -1235,6 +1248,8 @@ struct vattr vattr; int error, error1; char name[MAXCOMLEN+6]; /* progname.core */ + + STOPEVENT(p, S_CORE, 0); if (p->p_flag & P_SUGID) return (EFAULT); Index: kern/sys_process.c =================================================================== RCS file: /kithrup/cvs/src/sys/kern/sys_process.c,v retrieving revision 1.32 diff -u -r1.32 sys_process.c --- sys_process.c 1997/11/12 12:28:12 1.32 +++ sys_process.c 1997/11/15 05:05:44 @@ -503,3 +503,22 @@ { return 1; } + +/* + * stopevent() + * Stop a process because of a procfs event; + * stay stopped until p->p_step is cleared + * (cleared by PIOCCONT in procfs). + */ + +void +stopevent(struct proc *p, unsigned int event, unsigned int val) { + p->p_step = 1; + + do { + p->p_xstat = val; + p->p_stype = event; /* Which event caused the stop? */ + wakeup(&p->p_stype); /* Wake up any PIOCWAIT'ing procs */ + tsleep(&p->p_step, PWAIT, "stopevent", 0); + } while (p->p_step); +} Index: kern/vfs_vnops.c =================================================================== RCS file: /kithrup/cvs/src/sys/kern/vfs_vnops.c,v retrieving revision 1.41 diff -u -r1.41 vfs_vnops.c --- vfs_vnops.c 1997/11/07 08:53:11 1.41 +++ vfs_vnops.c 1997/11/15 05:05:43 @@ -453,8 +453,9 @@ /* fall into ... */ default: +#if 0 return (ENOTTY); - +#endif case VFIFO: case VCHR: case VBLK: Index: miscfs/procfs/procfs_subr.c =================================================================== RCS file: /kithrup/cvs/src/sys/miscfs/procfs/procfs_subr.c,v retrieving revision 1.17 diff -u -r1.17 procfs_subr.c --- procfs_subr.c 1997/08/02 14:32:18 1.17 +++ procfs_subr.c 1997/11/15 05:05:43 @@ -351,3 +351,14 @@ return (0); } + +void +procfs_exit(pid_t pid) +{ + struct pfsnode *pfs; + + for (pfs = pfshead; pfs ; pfs = pfs->pfs_next) { + if (pfs->pfs_pid == pid) + vgone(PFSTOV(pfs)); + } +} Index: miscfs/procfs/procfs_vnops.c =================================================================== RCS file: /kithrup/cvs/src/sys/miscfs/procfs/procfs_vnops.c,v retrieving revision 1.42 diff -u -r1.42 procfs_vnops.c --- procfs_vnops.c 1997/11/07 08:53:15 1.42 +++ procfs_vnops.c 1997/11/15 05:12:51 @@ -55,6 +55,7 @@ #include #include #include +#include static int procfs_abortop __P((struct vop_abortop_args *)); static int procfs_access __P((struct vop_access_args *)); @@ -63,6 +64,7 @@ static int procfs_close __P((struct vop_close_args *)); static int procfs_getattr __P((struct vop_getattr_args *)); static int procfs_inactive __P((struct vop_inactive_args *)); +static int procfs_ioctl __P((struct vop_ioctl_args *)); static int procfs_lookup __P((struct vop_lookup_args *)); static int procfs_open __P((struct vop_open_args *)); static int procfs_print __P((struct vop_print_args *)); @@ -184,6 +186,79 @@ } /* + * do an ioctl operation on a pfsnode (vp). + * (vp) is not locked on entry or exit. + */ +static int +procfs_ioctl(ap) + struct vop_ioctl_args *ap; +{ + struct pfsnode *pfs = VTOPFS(ap->a_vp); + struct proc *procp; + int error; + int signo; + struct procfs_status *psp; + + procp = pfind(pfs->pfs_pid); + if (procp == NULL) { + return ENOTTY; + } + + switch (ap->a_command) { + case PIOCBIS: + procp->p_stops |= *(unsigned int*)ap->a_data; + break; + case PIOCBIC: + procp->p_stops &= ~*(unsigned int*)ap->a_data; + break; + case PIOCSFL: + procp->p_pfsflags = (unsigned char)*(unsigned int*)ap->a_data; + *(unsigned int*)ap->a_data = procp->p_stops; + break; + case PIOCSTATUS: + psp = (struct procfs_status *)ap->a_data; + psp->state = (procp->p_step == 0); + psp->flags = procp->p_pfsflags; + psp->events = procp->p_stops; + if (procp->p_step) { + psp->why = procp->p_stype; + psp->val = procp->p_xstat; + } else { + psp->why = psp->val = 0; /* Not defined values */ + } + break; + case PIOCWAIT: + psp = (struct procfs_status *)ap->a_data; + if (procp->p_step == 0) { + error = tsleep(&procp->p_stype, PWAIT | PCATCH, "piocwait", 0); + if (error) + return error; + } + psp->state = 1; /* It stopped */ + psp->flags = procp->p_pfsflags; + psp->events = procp->p_stops; + psp->why = procp->p_stype; /* why it stopped */ + psp->val = procp->p_xstat; /* any extra info */ + break; + case PIOCCONT: /* Restart a proc */ + if (procp->p_step == 0) + return EINVAL; /* Can only start a stopped process */ + if (ap->a_data && (signo = *(int*)ap->a_data)) { + if (signo >= NSIG || signo <= 0) + return EINVAL; + if (error = psignal(procp, signo)) + return error; + } + procp->p_step = 0; + wakeup(&procp->p_step); + break; + default: + return (ENOTTY); + } + return 0; +} + +/* * do block mapping for pfsnode (vp). * since we don't use the buffer cache * for procfs this function should never @@ -908,6 +983,7 @@ { &vop_setattr_desc, (vop_t *) procfs_setattr }, { &vop_symlink_desc, (vop_t *) procfs_badop }, { &vop_write_desc, (vop_t *) procfs_rw }, + { &vop_ioctl_desc, (vop_t *) procfs_ioctl }, { NULL, NULL } }; static struct vnodeopv_desc procfs_vnodeop_opv_desc = Index: sys/proc.h =================================================================== RCS file: /kithrup/cvs/src/sys/sys/proc.h,v retrieving revision 1.46 diff -u -r1.46 proc.h --- proc.h 1997/11/06 19:29:45 1.46 +++ proc.h 1997/11/15 05:05:42 @@ -151,6 +151,11 @@ short p_locks; /* DEBUG: lockmgr count of held locks */ short p_simple_locks; /* DEBUG: count of held simple locks */ + unsigned int p_stops; /* procfs event bitmask */ + unsigned int p_stype; /* procfs stop event type */ + char p_step; /* procfs stop *once* flag */ + unsigned char p_pfsflags; /* procfs flags */ + char p_pad3[2]; /* padding for alignment */ register_t p_retval[2]; /* syscall aux returns */ /* End area that is zeroed on creation. */ @@ -270,6 +275,10 @@ if (--(s)->s_count == 0) \ FREE(s, M_SESSION); \ } + +extern void stopevent(struct proc*, unsigned int, unsigned int); +#define STOPEVENT(p,e,v) do { \ + if ((p)->p_stops & (e)) stopevent(p,e,v); } while (0) /* hold process U-area in memory, normally for ptrace/procfs work */ #define PHOLD(p) { \ Index: i386/i386/trap.c =================================================================== --- /dev/null Wed Nov 26 16:08:20 1997 +++ sys/pioctl.h Fri Nov 14 21:08:15 1997 @@ -0,0 +1,33 @@ +#include + +#if 0 +struct procfs_status { + int state; /* 0 for running, 1 for stopped */ + int why; /* what event, if any, proc stopped on */ + unsigned int val; /* Any extra data */ +}; +#else +struct procfs_status { + int state; /* Running, stopped, something else? */ + int flags; /* Any flags */ + unsigned long events; /* Events to stop on */ + int why; /* What event, if any, proc stopped on */ + unsigned long val; /* Any extra data */ +}; +#endif + +#define PIOCBIS _IOW('p', 1, unsigned int) /* Set event flag */ +#define PIOCBIC _IOW('p', 2, unsigned int) /* Clear event flag */ +#define PIOCSFL _IOR('p', 3, unsigned int) /* Set flags */ + /* wait for proc to stop */ +#define PIOCWAIT _IOR('p', 4, struct procfs_status) +#define PIOCCONT _IOW('p', 5, int) /* Continue a process */ + /* Get proc status */ +#define PIOCSTATUS _IOW('p', 6, struct procfs_status) + +#define S_EXEC 0x00000001 /* stop-on-exec */ +#define S_SIG 0x00000002 /* stop-on-signal */ +#define S_SCE 0x00000004 /* stop on syscall entry */ +#define S_SCX 0x00000008 /* stop on syscall exit */ +#define S_CORE 0x00000010 /* stop on coredump */ +#define S_EXIT 0x00000020 /* stop on exit */ From owner-freebsd-hackers Wed Nov 26 16:50:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA04912 for hackers-outgoing; Wed, 26 Nov 1997 16:50:51 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA04903 for ; Wed, 26 Nov 1997 16:50:46 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id QAA01487; Wed, 26 Nov 1997 16:39:35 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd001485; Wed Nov 26 16:39:30 1997 Date: Wed, 26 Nov 1997 16:37:18 -0800 (PST) From: Julian Elischer To: Julian Assange cc: hackers@freebsd.org Subject: Re: detecting devfs from userland? In-Reply-To: <19971126232220.5569.qmail@iq.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk at the moment, there is a line in the output of mount that looks like: devfs on dummy_mount (local) even if you haven't mounted it, as there is always the kernel's internal mountpoint which you can't get to, but which is not optional. also there is a line in the dmesg saying: DEVFS: ready to run. (or similar) On 26 Nov 1997, Julian Assange wrote: > > Is there anyway to detect if the running kernel was built with > -DDEVFS, other than trying to mount -t devfs ? (i.e a way that > doesn't require root privs? sysctl -a is of no use here. > > Cheers, > Julian. > From owner-freebsd-hackers Wed Nov 26 17:27:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA10787 for hackers-outgoing; Wed, 26 Nov 1997 17:27:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA10782 for ; Wed, 26 Nov 1997 17:27:20 -0800 (PST) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.7) id RAA14186; Wed, 26 Nov 1997 17:27:20 -0800 (PST) (envelope-from sef) Date: Wed, 26 Nov 1997 17:27:20 -0800 (PST) From: Sean Eric Fagan Message-Id: <199711270127.RAA14186@kithrup.com> To: hackers@freebsd.org Reply-To: sef@kithrup.com Subject: Re: procfs patches In-Reply-To: <199711270041.QAA00355.kithrup.freebsd.hackers@garth.kithrup.com> Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199711270041.QAA00355.kithrup.freebsd.hackers@garth.kithrup.com> you write: >These are the kernel side of the truss work I've been doing for the past >few years. I'm running a 2.2 system with these patches. I should make this clear -- the patches I sent out were for -current, not for 2.2. Sean. From owner-freebsd-hackers Wed Nov 26 17:39:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA11666 for hackers-outgoing; Wed, 26 Nov 1997 17:39:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA11661 for ; Wed, 26 Nov 1997 17:39:27 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (tc-if2-19.ida.net [208.141.171.76]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id SAA08930 for ; Wed, 26 Nov 1997 18:39:18 -0700 Date: Wed, 26 Nov 1997 18:38:41 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: hackers@freebsd.org Subject: Adaptive scheduling Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've been thinking about writing an engine which would adaptively shcedule packets over a crowded link. The idea would be to schedule packets based on bandwidth consumption, with both stream and source IP address taken into account. The idea is to give the light users good response, but slow down large transfers a little. There might be other scheduling algorithms also. I see this as a type of state based routing in which all data streams are monitored. The idea would be to have a drop-in module similar to what is already done for natd and ppp -alias. It is not that difficult to schedule outgoing packets, but incoming traffic is difficult to control. In the case of tcp streams, one suggestion has been to rewrite the window value on the tcp packets so that holding back ACKs will slow down the incoming stream after about two packets or so. Additionally, it is possible to send icmp source quench packets to try to slow down external sources. I don't know that these mechanisms will work very well, though. I would be interested to hear other ideas on the subject. Charles Mott From owner-freebsd-hackers Wed Nov 26 18:44:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA25311 for hackers-outgoing; Wed, 26 Nov 1997 18:44:17 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA25256 for ; Wed, 26 Nov 1997 18:44:00 -0800 (PST) (envelope-from mrcpu@cdsnet.net) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id SAA25785 for ; Wed, 26 Nov 1997 18:43:55 -0800 (PST) Date: Wed, 26 Nov 1997 18:43:55 -0800 (PST) From: Jaye Mathisen To: hackers@freebsd.org Subject: How many rules maximum in ipfw? Oh wait, comment... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk My ipfw -a list is coming out at exactly 1024 lines, which tain't enough... (and isn't showing all the rules I have defined). I looked at ip_fw.h in /sys/netinet, and didn't see a constant that limited the length of the rule chain. Given that you can have rule numbers 65000, I would've assumed you could really have that many rules. Need more input... WHere is this sucker at? I'm really only using it for IP accounting, not actually filtering anything at this moment in time. If it has an impact on run-time performance, perhaps it can be set in make.conf ala TOP's user list? Or in the kernel config file? Oh wait, better check ipfw. Yep, there it is, in list(ac,av). It statically sets it to 1024... Perhaps this can be raised to a higher number in the source tree, or maybe user-definable as listed above, or maybe a command-line parameter? I'll hack it, just somebody tell me what makes the most sense. From owner-freebsd-hackers Wed Nov 26 18:57:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA26604 for hackers-outgoing; Wed, 26 Nov 1997 18:57:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dfw-ix13.ix.netcom.com (dfw-ix13.ix.netcom.com [206.214.98.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA26586 for ; Wed, 26 Nov 1997 18:57:50 -0800 (PST) (envelope-from scrantr@ix.netcom.com) Received: (from smap@localhost) by dfw-ix13.ix.netcom.com (8.8.4/8.8.4) id UAA03293 for ; Wed, 26 Nov 1997 20:57:16 -0600 (CST) Received: from col-oh21-13.ix.netcom.com(207.220.130.141) by dfw-ix13.ix.netcom.com via smap (V1.3) id rma003250; Wed Nov 26 20:56:35 1997 Message-ID: <347CE21E.2B5E@ix.netcom.com> Date: Wed, 26 Nov 1997 21:59:43 -0500 From: Richard Scranton Reply-To: scrantr@ix.netcom.com Organization: LDA Systems, Columbus X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: hackers@FreeBSD.org Subject: list digest Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Is the digest broken? I haven't received one in weeks. I tried to subscribe again, and majordomo told me I was already subscribed. -- __________________________________________________________________ Richard Scranton LDA SYSTEMS Information Management Consulting scrantr@ix.netcom.com Columbus Cincinnati Cleveland Toledo Atlanta From owner-freebsd-hackers Wed Nov 26 19:32:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA02103 for hackers-outgoing; Wed, 26 Nov 1997 19:32:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dog.farm.org (gw-hssi-2.farm.org [209.66.103.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA02073 for ; Wed, 26 Nov 1997 19:32:18 -0800 (PST) (envelope-from dog.farm.org!dk) Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id TAA25467; Wed, 26 Nov 1997 19:28:21 -0800 (PST) Date: Wed, 26 Nov 1997 19:28:21 -0800 (PST) From: Dmitry Kohmanyuk Message-Id: <199711270328.TAA25467@dog.farm.org> To: proff@iq.org (Julian Assange), julian@whistle.com Cc: freebsd-hackers@freebsd.org Subject: Re: detecting devfs from userland? Newsgroups: cs-monolit.gated.lists.freebsd.hackers Organization: FARM Computing Association Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <19971126232220.5569.qmail@iq.org> you wrote: > Is there anyway to detect if the running kernel was built with > -DDEVFS, other than trying to mount -t devfs ? (i.e a way that > doesn't require root privs? sysctl -a is of no use here. I think that having devfs creating its own device would be nice thing for this purpose... i.e., just stat "/dev/devfs" to check if devfs is running. As an added bonus, devfs operations can be added by reading, writing, or ioctl'ing this device. this can work if you need to check whether devfs is running _now_, as opposed to knowing whether it is compiled into the kernel. Julian, your comments? From owner-freebsd-hackers Wed Nov 26 19:48:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA07326 for hackers-outgoing; Wed, 26 Nov 1997 19:48:40 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sparticus.bright.net (sparticus.bright.net [205.212.123.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA07220 for ; Wed, 26 Nov 1997 19:48:27 -0800 (PST) (envelope-from guynmatt@mail.bright.net) Received: from mattmcdougal (find4-cs-15.dial.bright.net [205.212.145.195]) by sparticus.bright.net (8.8.7/8.8.7/FNG) with ESMTP id WAA26025 for ; Wed, 26 Nov 1997 22:47:52 -0500 (EST) Message-Id: <199711270347.WAA26025@sparticus.bright.net> From: "Matthew R. McDougal" To: Subject: I WILL HELP!! Date: Wed, 26 Nov 1997 22:48:12 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I would be glad to be a BETA tester for any of you following releases. You can contact me via email at guynmatt@mail.bright.net Sincerely, Matthew R. McDougal From owner-freebsd-hackers Wed Nov 26 22:07:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA00920 for hackers-outgoing; Wed, 26 Nov 1997 22:07:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from localhost.zilker.net (jump-x2-1096.jumpnet.com [207.8.67.96]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA00904 for ; Wed, 26 Nov 1997 22:06:58 -0800 (PST) (envelope-from marquard@zilker.net) Received: (from marquard@localhost) by localhost.zilker.net (8.8.8/8.8.3) id XAA16737; Wed, 26 Nov 1997 23:14:41 -0600 (CST) To: freebsd-hackers@freebsd.org Subject: Re: Adaptive scheduling References: From: Dave Marquardt Date: 26 Nov 1997 23:14:09 -0600 In-Reply-To: Charles Mott's message of "Wed, 26 Nov 1997 18:38:41 -0700 (MST)" Message-ID: <85g1oisyu6.fsf@localhost.zilker.net> Lines: 30 X-Mailer: Quassia Gnus v0.17/XEmacs 19.16 - "Lille" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Charles Mott writes: > It is not that difficult to schedule outgoing packets, but incoming > traffic is difficult to control. In the case of tcp streams, one > suggestion has been to rewrite the window value on the tcp packets so that > holding back ACKs will slow down the incoming stream after about two > packets or so. Additionally, it is possible to send icmp source quench > packets to try to slow down external sources. I don't know that these > mechanisms will work very well, though. Does FreeBSD do anything with the IP Type of Service bits? That might be a place to start, given that many Telnet implementations already set certain TOS bits that would indicate interactive traffic. Charles, another place you might look is the IETF RSVP work, and the IETF Integrated Services over Specific Links (or something like that) working group. Most of the discussion I've heard regarding RSVP is only looking at the outgoing packet problem so far, though I can't claim to be deeply involved in RSVP work (I do work on TCP/IP for IBM's AIX, so I do have some knowledge about networking and TCP/IP). The problem with incoming traffic is that it's pretty unpredictable. You may be getting new TCP connections coming in, broadcasts, and IP multicasts (though you generally have to ask for those). If you really want to slow down a remote TCP sender, don't just delay his ACKs, drop several of his packets on the floor :-). Your idea of decreasing the advertised window ought to work also. Sort of a congestion window on the receive side rather than the sending side. I like it. -Dave From owner-freebsd-hackers Wed Nov 26 22:22:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA01697 for hackers-outgoing; Wed, 26 Nov 1997 22:22:39 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA01691 for ; Wed, 26 Nov 1997 22:22:35 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.8) id AAA00635; Thu, 27 Nov 1997 00:38:34 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199711270538.AAA00635@dyson.iquest.net> Subject: Re: procfs patches In-Reply-To: <199711270041.QAA00355@garth.kithrup.com> from Sean Eric Fagan at "Nov 26, 97 04:41:56 pm" To: sef@kithrup.com (Sean Eric Fagan) Date: Thu, 27 Nov 1997 00:38:33 -0500 (EST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sean Eric Fagan said: > > These are the kernel side of the truss work I've been doing for the past > few years. I'm running a 2.2 system with these patches. > That is good stuff. Haven't reviewed the code, but I seriously depend on tools like this. John From owner-freebsd-hackers Wed Nov 26 23:10:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA04859 for hackers-outgoing; Wed, 26 Nov 1997 23:10:52 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA04842 for ; Wed, 26 Nov 1997 23:10:45 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xaxxP-0002Rx-00; Wed, 26 Nov 1997 23:01:52 -0800 Date: Wed, 26 Nov 1997 23:01:50 -0800 (PST) From: Tom To: Charles Mott cc: hackers@freebsd.org Subject: Re: Adaptive scheduling In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 26 Nov 1997, Charles Mott wrote: > I've been thinking about writing an engine which would adaptively shcedule > packets over a crowded link. The idea would be to schedule packets based > on bandwidth consumption, with both stream and source IP address taken > into account. The idea is to give the light users good response, but slow > down large transfers a little. There might be other scheduling algorithms > also. Very similar idea to Cisco's "fair queueing" queueing strategy. Basically it looks at how many "conversations" are going on, and makes sure none of them dominate the queue. It works really quite. When a particular server was doing a trasnfers a _lot_ of data over a T1 here rtt to that particular system went up to over 400ms and some packet loss, but other systems on the same T1 barely noticed it. Cisco's also do "custom priority" queues, where you define filters that match traffic to various priority levels (ex. high, medium, and low). I wish FreeBSD filters more generic so could be used by such a queueing system. ... > It is not that difficult to schedule outgoing packets, but incoming > traffic is difficult to control. In the case of tcp streams, one > suggestion has been to rewrite the window value on the tcp packets so that > holding back ACKs will slow down the incoming stream after about two > packets or so. Additionally, it is possible to send icmp source quench > packets to try to slow down external sources. I don't know that these > mechanisms will work very well, though. I don't like it. Just setup "fair queuing" or whatever on all systems on your physical network. After all, whatever inbound traffic you get, came out of something. > I would be interested to hear other ideas on the subject. > > Charles Mott > > > Tom From owner-freebsd-hackers Wed Nov 26 23:43:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA06751 for hackers-outgoing; Wed, 26 Nov 1997 23:43:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA06725; Wed, 26 Nov 1997 23:43:23 -0800 (PST) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.7) id XAA08912; Wed, 26 Nov 1997 23:43:19 -0800 (PST) (envelope-from sef) Date: Wed, 26 Nov 1997 23:43:19 -0800 (PST) From: Sean Eric Fagan Message-Id: <199711270743.XAA08912@kithrup.com> To: security@freebsd.org, hackers@freebsd.org Reply-To: sef@kithrup.com Subject: Updated f00f workaround Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Well, I was waiting for someone else to do anything about this, but everybody is apparantly busy :). This isn't quite right -- I think there should be a less obviously-i386 method of making the page in question non-writable; there should be a better way to allocate two page-aligned pages of memory; and the check for the fault address should be done lower, but I don't know the code well enough to decide where. Note that these patches are relative to my 2.2-ish source code, but should apply fairly cleanly to any of the distributions. Also note that I don't have anything ifdef'd out just yet, although that'll happen before I check it in. Index: i386/i386/identcpu.c =================================================================== RCS file: /usr/home/sef/CVS-kernel/sys/i386/i386/identcpu.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 identcpu.c --- identcpu.c 1997/03/01 02:57:12 1.1.1.1 +++ identcpu.c 1997/11/27 07:15:00 @@ -78,6 +78,8 @@ { "Pentium Pro", CPUCLASS_686 }, /* CPU_686 */ }; +int has_f00f_bug = 0; + void identifycpu(void) { @@ -105,6 +107,7 @@ break; case 0x500: strcat(cpu_model, "Pentium"); /* nb no space */ + has_f00f_bug = 1; break; case 0x600: strcat(cpu_model, "Pentium Pro"); Index: i386/i386/machdep.c =================================================================== RCS file: /usr/home/sef/CVS-kernel/sys/i386/i386/machdep.c,v retrieving revision 1.2 diff -u -r1.2 machdep.c --- machdep.c 1997/03/01 05:36:35 1.2 +++ machdep.c 1997/11/27 07:39:00 @@ -803,6 +803,10 @@ struct gate_descriptor idt[NIDT]; /* interrupt descriptor table */ union descriptor ldt[NLDT]; /* local descriptor table */ +struct gate_descriptor *t_idt; +unsigned char f00f_idt[PAGE_SIZE * 3]; /* XXX */ +int has_f00f_bug; + static struct i386tss dblfault_tss; static char dblfault_stack[PAGE_SIZE]; @@ -1393,6 +1397,37 @@ /* setup proc 0's pcb */ proc0.p_addr->u_pcb.pcb_flags = 0; proc0.p_addr->u_pcb.pcb_cr3 = IdlePTD; +} + +void f00f_hack(void); +SYSINIT(f00f_hack, SI_SUB_INTRINSIC, SI_ORDER_FIRST, f00f_hack, NULL); + +void +f00f_hack(void) { + struct region_descriptor r_idt; + unsigned char *tmp; + int i; + vm_offset_t vp; + unsigned *pte; + + if (!has_f00f_bug) + return; + + printf("Intel Pentium F00F detected, installing workaround\n"); + + r_idt.rd_limit = sizeof(idt) - 1; + + tmp = (unsigned char*)roundup2((unsigned)f00f_idt, PAGE_SIZE); + tmp += PAGE_SIZE - (7 * 8); /* Put 7 entries in lower page */ + t_idt = (struct gate_descriptor*)tmp; + bcopy(idt, t_idt, sizeof(idt)); + r_idt.rd_base = (int)t_idt; + lidt(&r_idt); + vp = trunc_page(t_idt); + pte = (unsigned*)vtopte(vp); + *pte = *pte & ~PG_RW; /* Mark page as non-writable */ + invlpg(vp); + return; } /* Index: i386/i386/trap.c =================================================================== RCS file: /usr/home/sef/CVS-kernel/sys/i386/i386/trap.c,v retrieving revision 1.3 diff -u -r1.3 trap.c --- trap.c 1997/11/24 08:19:19 1.3 +++ trap.c 1997/11/27 07:38:59 @@ -134,6 +134,11 @@ static void userret __P((struct proc *p, struct trapframe *frame, u_quad_t oticks)); +extern struct gate_descriptor *t_idt; +extern int has_f00f_bug; +static int f00f_traps[] = { T_DIVIDE, T_TRCTRAP, T_NMI, T_BPTFLT, + T_OFLOW, T_BOUND, T_PRIVINFLT }; + static inline void userret(p, frame, oticks) struct proc *p; @@ -190,6 +195,7 @@ u_long eva; #endif +restart: type = frame.tf_trapno; code = frame.tf_err; @@ -257,6 +263,8 @@ i = trap_pfault(&frame, TRUE); if (i == -1) return; + if (i == -2) + goto restart; if (i == 0) goto out; @@ -599,6 +607,21 @@ eva = rcr2(); va = trunc_page((vm_offset_t)eva); + + if (has_f00f_bug && + (eva >= (unsigned int)t_idt) && + (eva <= (unsigned int)(((unsigned char*)t_idt) + 7*8))) { + int nr; + + /* + * I think this bit of code should only happen + * on a Pentium with the F00F bug, as nothing else + * should really try to write to the IDT page. + */ + nr = (eva - (unsigned int)t_idt) / 8; + frame->tf_trapno = f00f_traps[nr]; + return -2; + } if (va >= KERNBASE) { /* From owner-freebsd-hackers Thu Nov 27 00:22:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA08621 for hackers-outgoing; Thu, 27 Nov 1997 00:22:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA08614 for ; Thu, 27 Nov 1997 00:21:55 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id JAA07384; Thu, 27 Nov 1997 09:21:46 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id IAA00457; Thu, 27 Nov 1997 08:57:17 +0100 (MET) Message-ID: <19971127085717.19775@uriah.heep.sax.de> Date: Thu, 27 Nov 1997 08:57:17 +0100 From: J Wunsch To: hackers@FreeBSD.ORG Cc: "Brian J. McGovern" Subject: Re: Union and Portal FSs Reply-To: Joerg Wunsch References: <199711262012.PAA02709@spoon.beta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199711262012.PAA02709@spoon.beta.com>; from Brian J. McGovern on Wed, Nov 26, 1997 at 03:12:48PM -0500 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Brian J. McGovern wrote: > Just out of curiousity, how "decayed" are the Union and Portal > filesystems,and, more importantly, is anyone working on them? Kazu did quite some work on unionfs, and i think it's basically usable these days. There are still some odds in it (which i'm not sure of whether they can be easily resolved), like an open attempt with write intent will yield an EROFS if the lower layer is a read/only filesystem. UFS union mounts ("mount -o union /dev/fd0 /somewhere") seem to have a different set of problems. I've got this one basically to work, in an attempt to mount a writable floppy over a read/only CD-ROM /etc, but when i recently tried under -current with a lower-layer NFS, the writes went through into the lower layer, ick. :( No idea on portals... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Nov 27 00:36:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA09356 for hackers-outgoing; Thu, 27 Nov 1997 00:36:13 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.96.1.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA09348 for ; Thu, 27 Nov 1997 00:36:09 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.7/8.8.7) with SMTP id DAA14128; Thu, 27 Nov 1997 03:36:03 -0500 (EST) Date: Thu, 27 Nov 1997 03:36:03 -0500 (EST) From: "Matthew N. Dodd" To: Sean Eric Fagan cc: hackers@FreeBSD.ORG Subject: Re: procfs patches In-Reply-To: <199711270127.RAA14186@kithrup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 26 Nov 1997, Sean Eric Fagan wrote: > I should make this clear -- the patches I sent out were for -current, not > for 2.2. Shhsh... They might hear you and stop working. (2.2.5-STABLE from 112697 sup, patches required some tweaking). Good job, looks kinda nifty. I wonder if your work makes porting strace any easier. /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ From owner-freebsd-hackers Thu Nov 27 01:50:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA13616 for hackers-outgoing; Thu, 27 Nov 1997 01:50:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from main.gbdata.com (digital-02-140.hou.neoworld.net [206.109.29.140]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA13602 for ; Thu, 27 Nov 1997 01:50:27 -0800 (PST) (envelope-from gclarkii@main.gbdata.com) Received: (from gclarkii@localhost) by main.gbdata.com (8.8.7/8.8.5) id DAA05190 for freebsd-hackers@freebsd.org; Thu, 27 Nov 1997 03:50:21 -0600 (CST) From: Gary Clark II Message-Id: <199711270950.DAA05190@main.gbdata.com> Subject: conflict link.h dlfcn.h To: freebsd-hackers@freebsd.org Date: Thu, 27 Nov 1997 03:50:21 -0600 (CST) Reply-To: gclarkii@brewich.com X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I'm in the process of trying to get postgresql to run and have ran into a conflict in our header files. Here is what the prototypes look like in both link.h and postgresql: void *dlopen(const *char, int); int dlclose(void *); void *dlsym(void *, const char *) const char *dlerror(void) Here is what they look like in dlfcn.h void *dlopen( *char, int); int dlclose(void *); void *dlsym(void *, char *) char *dlerror(void) Note the lack of const in use in dlfcn.h. This causes postgresql to toss its cookies here and require a hack. Which one is correct? Gary -- Gary Clark II (N5VMF) | I speak only for myself and "maybe" my company gclarkii@Brewich.COM | Fallen member of the FreeBSD Doc Team From owner-freebsd-hackers Thu Nov 27 02:27:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA15179 for hackers-outgoing; Thu, 27 Nov 1997 02:27:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA15174 for ; Thu, 27 Nov 1997 02:27:52 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id LAA09069; Thu, 27 Nov 1997 11:26:12 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id LAA01076; Thu, 27 Nov 1997 11:24:44 +0100 (MET) Message-ID: <19971127112444.43782@uriah.heep.sax.de> Date: Thu, 27 Nov 1997 11:24:44 +0100 From: J Wunsch To: freebsd-hackers@FreeBSD.ORG Cc: gclarkii@brewich.com Subject: Re: conflict link.h dlfcn.h Reply-To: Joerg Wunsch References: <199711270950.DAA05190@main.gbdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199711270950.DAA05190@main.gbdata.com>; from Gary Clark II on Thu, Nov 27, 1997 at 03:50:21AM -0600 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Gary Clark II wrote: > I'm in the process of trying to get postgresql to run and have ran into > a conflict in our header files. IMHO that has been resolved long since. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Nov 27 02:54:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA15877 for hackers-outgoing; Thu, 27 Nov 1997 02:54:06 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from macon.informatik.uni-tuebingen.de (macon2.Informatik.Uni-Tuebingen.De [134.2.13.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA15870 for ; Thu, 27 Nov 1997 02:54:00 -0800 (PST) (envelope-from sperber@informatik.uni-tuebingen.de) Received: from modas.informatik.uni-tuebingen.de (modas.Informatik.Uni-Tuebingen.De [134.2.12.3]) by macon.informatik.uni-tuebingen.de (8.8.4/8.8.3/AIX-4.1/WSI-1.0) with SMTP id LAA14598 for ; Thu, 27 Nov 1997 11:53:52 +0100 Received: by modas.informatik.uni-tuebingen.de (AIX 4.1/UCB 5.64/4.03) id AA22924; Thu, 27 Nov 1997 11:53:47 +0100 To: hackers@freebsd.org Subject: lpt ioctl question Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-8859-1 From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 27 Nov 1997 11:53:46 +0100 Message-Id: Lines: 10 X-Mailer: Gnus v5.5/XEmacs 20.3 - "Vatican City" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id CAA15872 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there an ioctl or something to send an init signal to an lpt port? I can't make head nor tail of the driver source code. Please email me directly. Any help is much appreciated. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From owner-freebsd-hackers Thu Nov 27 03:12:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA16580 for hackers-outgoing; Thu, 27 Nov 1997 03:12:13 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from omnix.net (root@omnix.net [194.183.217.130]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA16572 for ; Thu, 27 Nov 1997 03:12:05 -0800 (PST) (envelope-from didier@omnix.net) Received: from localhost (didier@localhost [127.0.0.1]) by omnix.net (8.8.5/8.8.5) with SMTP id LAA03812 for ; Thu, 27 Nov 1997 11:12:00 GMT Date: Thu, 27 Nov 1997 12:12:00 +0100 (CET) From: Didier Derny To: hackers@freebsd.org Subject: RealAudio/Video Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there any solution to use the linux Version of RealAudio on FreeBSD ? RealAudio is complaining about a ioctl problem LINUX: 'ioctl' fd=6 typ=0x450(P), num=0xf not implemented. I'm using a soundblaster sb16 card. thanks for your help. -- Didier Derny didier@omnix.net From owner-freebsd-hackers Thu Nov 27 04:02:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA18502 for hackers-outgoing; Thu, 27 Nov 1997 04:02:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA18497 for ; Thu, 27 Nov 1997 04:02:11 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1] (may be forged)) by rah.star-gate.com (8.8.8/8.8.5) with ESMTP id EAA00254; Thu, 27 Nov 1997 04:01:59 -0800 (PST) Message-Id: <199711271201.EAA00254@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Didier Derny cc: hackers@freebsd.org Subject: Re: RealAudio/Video In-reply-to: Your message of "Thu, 27 Nov 1997 12:12:00 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Nov 1997 04:01:59 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk If you have a recent -current then shouldn't have any problems using the realaudio player with your sb card. Cheers, Amancio > > Is there any solution to use the linux Version of RealAudio on > FreeBSD ? > > RealAudio is complaining about a ioctl problem > > LINUX: 'ioctl' fd=6 typ=0x450(P), num=0xf not implemented. > > I'm using a soundblaster sb16 card. > > > thanks for your help. > > -- > Didier Derny > didier@omnix.net > > > > From owner-freebsd-hackers Thu Nov 27 05:51:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA23099 for hackers-outgoing; Thu, 27 Nov 1997 05:51:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA23087 for ; Thu, 27 Nov 1997 05:51:19 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id OAA11192; Thu, 27 Nov 1997 14:51:06 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id OAA00395; Thu, 27 Nov 1997 14:24:26 +0100 (MET) Message-ID: <19971127142426.29903@uriah.heep.sax.de> Date: Thu, 27 Nov 1997 14:24:26 +0100 From: J Wunsch To: hackers@FreeBSD.ORG Cc: "Michael Sperber [Mr. Preprocessor]" Subject: Re: lpt ioctl question Reply-To: Joerg Wunsch References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Michael Sperber [Mr. Preprocessor] on Thu, Nov 27, 1997 at 11:53:46AM +0100 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Michael Sperber [Mr. Preprocessor] wrote: > Is there an ioctl or something to send an init signal to an lpt port? No, but it's sent on each open() of the printer anyway. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Nov 27 06:39:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA25413 for hackers-outgoing; Thu, 27 Nov 1997 06:39:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA25408 for ; Thu, 27 Nov 1997 06:39:47 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id GAA00549; Thu, 27 Nov 1997 06:42:44 -0800 (PST) Message-Id: <199711271442.GAA00549@implode.root.com> To: Dave Marquardt cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Adaptive scheduling In-reply-to: Your message of "26 Nov 1997 23:14:09 CST." <85g1oisyu6.fsf@localhost.zilker.net> From: David Greenman Reply-To: dg@root.com Date: Thu, 27 Nov 1997 06:42:44 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Charles Mott writes: >> It is not that difficult to schedule outgoing packets, but incoming >> traffic is difficult to control. In the case of tcp streams, one >> suggestion has been to rewrite the window value on the tcp packets so that >> holding back ACKs will slow down the incoming stream after about two >> packets or so. Additionally, it is possible to send icmp source quench >> packets to try to slow down external sources. I don't know that these >> mechanisms will work very well, though. > >Does FreeBSD do anything with the IP Type of Service bits? Yes, both telnet and ftp set the TOS as appropriate. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Thu Nov 27 06:48:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA25750 for hackers-outgoing; Thu, 27 Nov 1997 06:48:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA25743 for ; Thu, 27 Nov 1997 06:48:28 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id PAA11788 for freebsd-hackers@freebsd.org; Thu, 27 Nov 1997 15:48:26 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id PAA00659; Thu, 27 Nov 1997 15:39:41 +0100 (MET) Message-ID: <19971127153941.48321@uriah.heep.sax.de> Date: Thu, 27 Nov 1997 15:39:41 +0100 From: J Wunsch To: FreeBSD hackers Subject: [j@uriah.heep.sax.de: Re: conflict link.h dlfcn.h] Reply-To: Joerg Wunsch Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mail directly to Gary bounced... but i think it's ok to send this into public as well. Perhaps he can read it. -----Forwarded message from J Wunsch ----- Message-ID: <19971127143120.03791@uriah.heep.sax.de> Date: Thu, 27 Nov 1997 14:31:21 +0100 From: J Wunsch To: Gary Clark II Subject: Re: conflict link.h dlfcn.h Reply-To: Joerg Wunsch As Gary Clark II wrote: > Well this is in 3.0-current as of about a week ago and I've still got the > problem. > > How was it resolved....???? Strange. In my copy of , i've got: /* * dl*() prototypes. */ extern void *dlopen __P((char *, int)); extern int dlclose __P((void *)); extern void *dlsym __P((void *, char *)); extern char *dlerror __P((void)); i.e., no `const'. Surely this should rather suck in instead. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) -----End of forwarded message----- -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Nov 27 07:21:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA27750 for hackers-outgoing; Thu, 27 Nov 1997 07:21:58 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from omnix.net (root@omnix.net [194.183.217.130]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA27745 for ; Thu, 27 Nov 1997 07:21:54 -0800 (PST) (envelope-from didier@omnix.net) Received: from localhost (didier@localhost [127.0.0.1]) by omnix.net (8.8.5/8.8.5) with SMTP id PAA11116; Thu, 27 Nov 1997 15:21:43 GMT Date: Thu, 27 Nov 1997 16:21:43 +0100 (CET) From: Didier Derny To: Amancio Hasty cc: hackers@FreeBSD.ORG Subject: Re: RealAudio/Video In-Reply-To: <199711271201.EAA00254@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 27 Nov 1997, Amancio Hasty wrote: > > If you have a recent -current then shouldn't have any problems > using the realaudio player with your sb card. > > > Cheers, > Amancio > > > > > Is there any solution to use the linux Version of RealAudio on > > FreeBSD ? > > > > RealAudio is complaining about a ioctl problem > > > > LINUX: 'ioctl' fd=6 typ=0x450(P), num=0xf not implemented. > > > > I'm using a soundblaster sb16 card. > > > > > > thanks for your help. > > > > -- > > Didier Derny > > didier@omnix.net > > > > > > > > > > > Thanks for your help. as I had an urgent need of realaudio, I patched the linux emulator to return 1 for the GETCAPS and ignore the other ioctl that failed with realaudio. I'll try at home. I have the October 6 Snapshot Installed. -- Didier Derny didier@omnix.net From owner-freebsd-hackers Thu Nov 27 09:58:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA09468 for hackers-outgoing; Thu, 27 Nov 1997 09:58:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from darius.concentric.net (darius.concentric.net [207.155.184.79]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA09448 for ; Thu, 27 Nov 1997 09:58:34 -0800 (PST) (envelope-from candicepante@rocketmail.com) From: candicepante@rocketmail.com Received: from newman.concentric.net (newman.concentric.net [207.155.184.71]) by darius.concentric.net (8.8.8/(97/11/17 5.8)) id MAA01993; Thu, 27 Nov 1997 12:53:46 -0500 (EST) [1-800-745-2747 The Concentric Network] Received: from user900.meznet4.net (ts014d34.chi-il.concentric.net [206.173.187.190]) by newman.concentric.net (8.8.8) id MAA08748; Thu, 27 Nov 1997 12:53:27 -0500 (EST) Message-Id: <199711271753.MAA08748@newman.concentric.net> To: ha@ma1.seikyou.ne.jp Subject: Shhh...are they asleep yet? FREE Pixxxs *! Reply-To: candicepante@rocketmail.com Date: Fri, 8 Sep 97 14:24:52 EST Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk X-Info:Filtered Via The Remove List At http://www.antispam.org X-Info:Sent Using A Free Copy Of The Zenith Bulk Emailer Shhhh......are they asleep yet? Good...then it's just you and me... Candice's FREE Pixxxs and Links I won't tell any one...I hope you won't either. Candice :) P.S. The site is ONLY for those: over 18, who can legally view nudity in their area and are not offended by adult material. *** Important Message - Sent Using The Zenith Bulk Emailer *** *** For Your FREE Copy Of This Program - http://209.27.224.16 *** From owner-freebsd-hackers Thu Nov 27 10:44:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA14796 for hackers-outgoing; Thu, 27 Nov 1997 10:44:04 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA14790 for ; Thu, 27 Nov 1997 10:44:01 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA20253 (5.67b/IDA-1.5 for hackers@FreeBSD.ORG); Thu, 27 Nov 1997 19:40:21 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id TAA01333; Thu, 27 Nov 1997 19:21:43 +0100 (MET) From: Wilko Bulte Message-Id: <199711271821.TAA01333@yedi.iaf.nl> Subject: Re: DEVFS/SLICE passes milestone To: tlambert@primenet.com (Terry Lambert) Date: Thu, 27 Nov 1997 19:21:43 +0100 (MET) Cc: sos@freebsd.dk, julian@whistle.com, hackers@FreeBSD.ORG In-Reply-To: <199711262211.PAA21453@usr08.primenet.com> from "Terry Lambert" at Nov 26, 97 10:11:50 pm X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote... > > > I know :), I just wanted to get this straight, we don't want a new > > "inherrently broken by design" subsystem again. > > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > Sxren Schmidt (sos@FreeBSD.org) FreeBSD Core Team > > Inre this comment and the previous comment about my large patches > to the filesystem: my union mounts work, do yours? Oh OH! Are you people preparing to start a major flamefest again? > Terry Lambert _ ______________________________________________________________________ | / o / / _ Bulte email: wilko @ yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ---------------- Support your local daemons: run [Free,Net]BSD Unix ------ From owner-freebsd-hackers Thu Nov 27 11:12:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA15878 for hackers-outgoing; Thu, 27 Nov 1997 11:12:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA15864 for ; Thu, 27 Nov 1997 11:12:01 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id TAA05434; Thu, 27 Nov 1997 19:11:58 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id UAA12968; Thu, 27 Nov 1997 20:11:50 +0100 (MET) Date: Thu, 27 Nov 1997 20:11:50 +0100 (MET) Message-Id: <199711271911.UAA12968@bitbox.follo.net> From: Eivind Eklund To: Jaye Mathisen CC: hackers@FreeBSD.ORG In-reply-to: Jaye Mathisen's message of Wed, 26 Nov 1997 18:43:55 -0800 (PST) Subject: Re: How many rules maximum in ipfw? Oh wait, comment... References: Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Oh wait, better check ipfw. Yep, there it is, in list(ac,av). It > statically sets it to 1024... Perhaps this can be raised to a higher > number in the source tree, or maybe user-definable as listed above, or > maybe a command-line parameter? I'll hack it, just somebody tell me what > makes the most sense. IMHO: Dynamic allocation. ipfw shouldn't limit the number of rules; if anything should be allowed to limit this, it should be the kernel. Eivind. From owner-freebsd-hackers Thu Nov 27 11:12:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA15932 for hackers-outgoing; Thu, 27 Nov 1997 11:12:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from vinyl.quickweb.com (vinyl.quickweb.com [209.112.4.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA15927 for ; Thu, 27 Nov 1997 11:12:32 -0800 (PST) (envelope-from mark@quickweb.com) Received: (from mark@localhost) by vinyl.quickweb.com (8.8.7/8.6.12) id OAA08723; Thu, 27 Nov 1997 14:13:54 -0500 (EST) Message-ID: <19971127141353.57146@vmunix.com> Date: Thu, 27 Nov 1997 14:13:53 -0500 From: Mark Mayo To: Amancio Hasty Cc: Didier Derny , hackers@FreeBSD.ORG Subject: Re: RealAudio/Video References: <199711271201.EAA00254@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <199711271201.EAA00254@rah.star-gate.com>; from Amancio Hasty on Thu, Nov 27, 1997 at 04:01:59AM -0800 X-Operating-System: FreeBSD 2.2.5-STABLE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Nov 27, 1997 at 04:01:59AM -0800, Amancio Hasty wrote: > If you have a recent -current then shouldn't have any problems > using the realaudio player with your sb card. Is one supposed to use the traditional snd0 Voxware drivers, or Luigi's new sound code for this? TIA, -Mark > > > Cheers, > Amancio > > > > > Is there any solution to use the linux Version of RealAudio on > > FreeBSD ? > > > > RealAudio is complaining about a ioctl problem > > > > LINUX: 'ioctl' fd=6 typ=0x450(P), num=0xf not implemented. > > > > I'm using a soundblaster sb16 card. > > > > > > thanks for your help. > > > > -- > > Didier Derny > > didier@omnix.net > > > > > > > > > -- ------------------------------------------------------------------------ Mark Mayo mark@vmunix.com RingZero Comp. http://www.vmunix.com/mark finger mark@vmunix.com for my PGP key and GCS code ------------------------------------------------------------------------ Win95/NT - 32 bit extensions and a graphical shell for a 16 bit patch to an an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition. -UGU From owner-freebsd-hackers Thu Nov 27 11:54:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA18569 for hackers-outgoing; Thu, 27 Nov 1997 11:54:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA18563; Thu, 27 Nov 1997 11:54:15 -0800 (PST) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.7) id LAA24160; Thu, 27 Nov 1997 11:54:14 -0800 (PST) (envelope-from sef) Date: Thu, 27 Nov 1997 11:54:14 -0800 (PST) From: Sean Eric Fagan Message-Id: <199711271954.LAA24160@kithrup.com> To: hackers@freebsd.org, security@freebsd.org Reply-To: sef@kithrup.com Subject: Re: Updated f00f workaround Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Okay, I took Stephen McKay's suggestions to heart, and here are what I hope are the final diffs. I'm currently running this kernel in multiuser mode, and haven't noticed any problems (yet, anyway ;)). Overhead should be minimal. Index: identcpu.c =================================================================== RCS file: /usr/home/sef/CVS-kernel/sys/i386/i386/identcpu.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 identcpu.c --- identcpu.c 1997/03/01 02:57:12 1.1.1.1 +++ identcpu.c 1997/11/27 19:48:34 @@ -78,6 +78,10 @@ { "Pentium Pro", CPUCLASS_686 }, /* CPU_686 */ }; +#ifndef NO_F00F_HACK +int has_f00f_bug = 0; +#endif + void identifycpu(void) { @@ -105,6 +109,14 @@ break; case 0x500: strcat(cpu_model, "Pentium"); /* nb no space */ +#ifndef NO_F00F_HACK + /* + * XXX - If/when Intel fixes the bug, this + * should also check the version of the + * CPU, not just that it's a Pentium. + */ + has_f00f_bug = 1; +#endif break; case 0x600: strcat(cpu_model, "Pentium Pro"); Index: machdep.c =================================================================== RCS file: /usr/home/sef/CVS-kernel/sys/i386/i386/machdep.c,v retrieving revision 1.2 diff -u -r1.2 machdep.c --- machdep.c 1997/03/01 05:36:35 1.2 +++ machdep.c 1997/11/27 19:48:34 @@ -803,6 +803,11 @@ struct gate_descriptor idt[NIDT]; /* interrupt descriptor table */ union descriptor ldt[NLDT]; /* local descriptor table */ +#ifndef NO_F00F_HACK +struct gate_descriptor *t_idt; +int has_f00f_bug; +#endif + static struct i386tss dblfault_tss; static char dblfault_stack[PAGE_SIZE]; @@ -1394,6 +1399,42 @@ proc0.p_addr->u_pcb.pcb_flags = 0; proc0.p_addr->u_pcb.pcb_cr3 = IdlePTD; } + +#ifndef NO_F00F_HACK +void f00f_hack(void); +SYSINIT(f00f_hack, SI_SUB_INTRINSIC, SI_ORDER_FIRST, f00f_hack, NULL); + +void +f00f_hack(void) { + struct region_descriptor r_idt; + unsigned char *tmp; + int i; + vm_offset_t vp; + unsigned *pte; + + if (!has_f00f_bug) + return; + + printf("Intel Pentium F00F detected, installing workaround\n"); + + r_idt.rd_limit = sizeof(idt) - 1; + + tmp = kmem_alloc(kernel_map, PAGE_SIZE * 2); + if (((unsigned int)tmp) & 4095) + panic("kern_alloc returned non-page-aligned memory"); + /* Put the first seven entries in the lower page */ + t_idt = (struct gate_descriptor*)(tmp + PAGE_SIZE - (7*8)); + bcopy(idt, t_idt, sizeof(idt)); + r_idt.rd_base = (int)t_idt; + lidt(&r_idt); + vp = trunc_page(t_idt); + if (vm_map_protect(kernel_map, tmp, tmp + (PAGE_SIZE*2), + VM_PROT_READ, FALSE) != KERN_SUCCESS) + panic("vm_map_protect failed"); + invlpg(vp); /* XXX -- is this necessary? */ + return; +} +#endif /* NO_F00F_HACK */ /* * The registers are in the frame; the frame is in the user area of Index: trap.c =================================================================== RCS file: /usr/home/sef/CVS-kernel/sys/i386/i386/trap.c,v retrieving revision 1.3 diff -u -r1.3 trap.c --- trap.c 1997/11/24 08:19:19 1.3 +++ trap.c 1997/11/27 19:48:35 @@ -134,6 +134,11 @@ static void userret __P((struct proc *p, struct trapframe *frame, u_quad_t oticks)); +#ifndef NO_F00F_HACK +extern struct gate_descriptor *t_idt; +extern int has_f00f_bug; +#endif + static inline void userret(p, frame, oticks) struct proc *p; @@ -190,6 +195,9 @@ u_long eva; #endif +#ifndef NO_F00F_HACK +restart: +#endif type = frame.tf_trapno; code = frame.tf_err; @@ -257,6 +265,10 @@ i = trap_pfault(&frame, TRUE); if (i == -1) return; +#ifndef NO_F00F_HACK + if (i == -2) + goto restart; +#endif if (i == 0) goto out; @@ -603,7 +615,18 @@ if (va >= KERNBASE) { /* * Don't allow user-mode faults in kernel address space. + * An exception: if the faulting address is the invalid + * instruction entry in the IDT, then the Intel Pentium + * F00F bug workaround was triggered, and we need to + * treat it is as an illegal instruction, and not a page + * fault. */ +#ifndef NO_F00F_HACK + if ((eva == (unsigned int)&t_idt[6]) && has_f00f_bug) { + frame->tf_trapno = T_PRIVINFLT; + return -2; + } +#endif if (usermode) goto nogo; From owner-freebsd-hackers Thu Nov 27 12:22:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA20082 for hackers-outgoing; Thu, 27 Nov 1997 12:22:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nomis.simon-shapiro.org (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA20076 for ; Thu, 27 Nov 1997 12:22:28 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 27164 invoked by uid 1000); 27 Nov 1997 20:22:42 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-111997 [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: <199711262010.NAA14950@usr08.primenet.com> Date: Thu, 27 Nov 1997 12:22:42 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon shapiro Foundation From: Simon Shapiro To: Terry Lambert Subject: Re: BIND 8.1.1 Cc: hackers@freebsd.org, shimon@i-Connect.Net Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 26-Nov-97 Terry Lambert wrote: > On Wed, 26 Nov 1977, Simon Shapiro wrote: >> * Put BIND 8.1.x in /usr/ports as a port > > [ ... ] > >> > On Tue, 25 Nov 1997, Simon Shapiro wrote: >> >> You are not forgetting the integration of the new resolver >> >> library >> >> into >> >> libc, new header files, etc. Right? > > These statements are incompatible. BIND 8.1.x requires integration > into libc. To be integrated, it requires integration :-) To be used as a package/add-on, it does not appear to require integration into libc, but you know better. Simon From owner-freebsd-hackers Thu Nov 27 12:23:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA20143 for hackers-outgoing; Thu, 27 Nov 1997 12:23:13 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from nomis.simon-shapiro.org (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA20104 for ; Thu, 27 Nov 1997 12:22:56 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 27215 invoked by uid 1000); 27 Nov 1997 20:22:46 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-111997 [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: Thu, 27 Nov 1997 12:22:46 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon shapiro Foundation From: Simon Shapiro To: Julian Elischer Subject: RE: DEVFS/SLICE passes milestone Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk If you want me to try and test it, let me have a patch. Simon On 26-Nov-97 Julian Elischer wrote: > San francisco, Early Tuesday morning, > > DEVFS passed a critical milestone today when my PC here booted up a > kernel > using only DEVFS based devices. The kernel used DEVFS to find the > root > device and mount it, finding it by NAME (sd1s1a) rather than by > major/minor numbers. The disk devices were all created dynamically > using > the "slice" subsystem so that all IO to the disks was flowing through > the > SLICE system's "IOreq" entrypoints rather than the older disk > 'strategy()' > entrypoints. > > The disk partitionning is being handled by separate MBR and DISKLABEL > SLICE objects, rather than by the older disk 'slicing' code. > The drivers have SLICE entrypoints added, in addition to the usual > entrypoints, which are no longer being used. > teh SLICE code is also known as "storage layering". > > On my system here, the lowest layer is the driver, > which exports a single slice. The driver does not know about any > partitioning (in the new code that is). It does IO requiests and that > is > all. > The next layer is an MBR type object, that takes the single slice > exported by the driver and exports in turn N slices, one for each > MBR (fdisk) partition. On each disk, One of these slices is in turn > passed to a DISKLABEL object, that takes in a single MBR slice > and exports a slice for each disklabel partition. All these slices > regardless of layer are identical in behaviour. > the top layer HAPPENS to have filesystems on each slice. > > since All disklslices are now handled by the same code > their major numbers are all the same. The minor numbers are > allocated dynamically as increasing integers. > i.e. SLICE code NEEDS DEVFS. > > yes I know the dates and link counts are wrong.. > > next steps: > 1/ clean it up > 2/ figure out why I suddenly have an extra swap device (a worry) > 3/ fix dates and links > 4/ make all major numbers irrelevant by bypassing the devsw tables. > 4a/ Allocate majors dynamically (used only to allow a device > to be shown to be unique) > 5/ remove all references to dev_t in the kernel :-) > > julian > > > attached find 'mount' output and disk related lines from 'ls -l /dev' > > If Microsoft Built Cars: There would be an "Engine Pro" with bigger turbos, but it would be slower on most existing roads. Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 From owner-freebsd-hackers Thu Nov 27 14:40:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA28123 for hackers-outgoing; Thu, 27 Nov 1997 14:40:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA28117; Thu, 27 Nov 1997 14:40:04 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id PAA00322; Thu, 27 Nov 1997 15:40:29 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp03.primenet.com, id smtpd000298; Thu Nov 27 15:40:22 1997 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id PAA12847; Thu, 27 Nov 1997 15:38:07 -0700 (MST) From: Terry Lambert Message-Id: <199711272238.PAA12847@usr07.primenet.com> Subject: Re: BIND 8.1.1 To: peter@netplex.com.au (Peter Wemm) Date: Thu, 27 Nov 1997 22:38:06 +0000 (GMT) Cc: tlambert@primenet.com, shimon@simon-shapiro.org, peter@freebsd.org, hackers@freebsd.org, julian@whistle.com, steve@visint.co.uk, nate@mt.sri.com In-Reply-To: <199711270204.KAA01487@spinner.netplex.com.au> from "Peter Wemm" at Nov 27, 97 10:04:50 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The main "problem" is that 8.1.1 has been out for a while and a fair few > significant bugs have been found and fixed - but I at least am missing some > of the fixes that I've seen followup discussions about on the lists. If > the ISC collected them together and released 8.1.2 that'd be a big help. This is what "vendor branches" are for... 8-). > The libc resolver interface is a seperate animal to the named server. We > don't have to change libc just to get bind 8.1.x up. I'm not entirely > sure that I'm completely in favour of the way that the irs resolver is > done, I'd like to see room for adding new types at run time, perhaps via > .so objects etc. Some of the basic types would have to be permanently > present though so that static binaries (ugh!) are still useable. Me too. I'd like to see the same for address families so I can dynamically put the ISO and XNS networking back in if I want to (which I do). But at least the new framework is not fundamentally opposed to the idea (ie: it would fit pretty well, but require an irs.conf file change to implement). It's not like trying to dynamically add VOP's.. ;-). Actually, right now, I'm more worried about 2.2.5 going the way of 4.9.6 (ie: no one upgrades to 3.0 jut like 8.1.1). A bit of a stabilization problem, if nothing else. I would say "put it in 3.0, since the upgrade is going to be an expensive one no matter how you slice it, and you might as well hide the cost there". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Nov 27 14:49:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA28463 for hackers-outgoing; Thu, 27 Nov 1997 14:49:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA28455; Thu, 27 Nov 1997 14:49:37 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id JAA02497; Thu, 27 Nov 1997 09:07:31 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp01.primenet.com, id smtpd002470; Thu Nov 27 09:07:22 1997 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id PAA13327; Thu, 27 Nov 1997 15:48:55 -0700 (MST) From: Terry Lambert Message-Id: <199711272248.PAA13327@usr07.primenet.com> Subject: Re: Updated f00f workaround To: sef@kithrup.com Date: Thu, 27 Nov 1997 22:48:55 +0000 (GMT) Cc: hackers@freebsd.org, security@freebsd.org In-Reply-To: <199711271954.LAA24160@kithrup.com> from "Sean Eric Fagan" at Nov 27, 97 11:54:14 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Okay, I took Stephen McKay's suggestions to heart, and here are what I hope > are the final diffs. I'm currently running this kernel in multiuser mode, > and haven't noticed any problems (yet, anyway ;)). Overhead should be > minimal. This is going to sound wierd, because it means you would need to include replacement trap() and trap_pfault() code, but... Any chance of writing this as an LKM? This would allow binary patch for those people who can't/won't recompile their kernels, and would make it an administrative choice. It would also make it easier to carry between versions (I thought of this because you used a SYSINIT() for it). I've often thought that the FPU emulator should be done this way, and the math libraries and FPU instruction inlining not be special cased... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Nov 27 14:53:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA28718 for hackers-outgoing; Thu, 27 Nov 1997 14:53:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA28706 for ; Thu, 27 Nov 1997 14:53:28 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id WAA09137; Thu, 27 Nov 1997 22:49:02 +0100 From: Luigi Rizzo Message-Id: <199711272149.WAA09137@labinfo.iet.unipi.it> Subject: Re: RealAudio/Video To: mark@vmunix.com (Mark Mayo) Date: Thu, 27 Nov 1997 22:49:02 +0100 (MET) Cc: hasty@rah.star-gate.com, didier@omnix.net, hackers@FreeBSD.ORG In-Reply-To: <19971127141353.57146@vmunix.com> from "Mark Mayo" at Nov 27, 97 02:13:34 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > If you have a recent -current then shouldn't have any problems > > using the realaudio player with your sb card. > > Is one supposed to use the traditional snd0 Voxware drivers, or > Luigi's new sound code for this? both should work. luigi From owner-freebsd-hackers Thu Nov 27 14:56:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA28899 for hackers-outgoing; Thu, 27 Nov 1997 14:56:03 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA28870 for ; Thu, 27 Nov 1997 14:55:58 -0800 (PST) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.8/8.8.7) with ESMTP id OAA18209; Thu, 27 Nov 1997 14:55:56 -0800 (PST) (envelope-from jdp) Message-Id: <199711272255.OAA18209@austin.polstra.com> To: hackers@freebsd.org Subject: Re: Shared Libraries and debugging In-Reply-To: <19971126182058.04145@uriah.heep.sax.de> References: <199711250748.SAA16393@holly.rd.net> <19971126182058.04145@uriah.heep.sax.de> Organization: Polstra & Co., Seattle, WA Cc: darius@senet.com.au Date: Thu, 27 Nov 1997 14:55:56 -0800 From: John Polstra Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <19971126182058.04145@uriah.heep.sax.de>, J Wunsch wrote: > As Daniel J. O'Connor wrote: > > > I was fiddling with some code which links against shared libraries, and > > noticed that when viewing a core dumb with gdb, it doesn't load the symbols > > from the shared libraries, so consequently debugging the program is kind of > > akward. > > I usually set a breakpoint at main(), run it till there, and then > voila!, you can also specify breakpoints at shared lib functions... But he was asking about core dumps. And he's right, it doesn't work. I've been looking into it, and I have a fix to the dynamic linker that seems to make it work fine. I'll commit it after I do a make world and a little bit more testing. Judging by the cause of the problem, I doubt that it ever worked. In order to examine shared libraries, gdb needs to look at the dynamic linker's table which records where they were loaded into memory. The dynamic linker has always recorded this information in a MAP_ANON region way up high in the address space. But such regions are not written to the core file when a core dump occurs. So gdb has not been able to get the information it needs. To fix it, I changed the dynamic linker to use the system malloc. (Much easier said than done!) Now it allocates its data structures from the same arena that the user program allocates from. Its data structures consequently now get written to the core file, and gdb finds them and works properly. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Thu Nov 27 14:58:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA29022 for hackers-outgoing; Thu, 27 Nov 1997 14:58:13 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA29012 for ; Thu, 27 Nov 1997 14:58:09 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA00138; Thu, 27 Nov 1997 16:03:05 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp02.primenet.com, id smtpd000133; Thu Nov 27 16:03:04 1997 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id PAA13589; Thu, 27 Nov 1997 15:57:32 -0700 (MST) From: Terry Lambert Message-Id: <199711272257.PAA13589@usr07.primenet.com> Subject: Re: DEVFS/SLICE passes milestone To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Thu, 27 Nov 1997 22:57:32 +0000 (GMT) Cc: tlambert@primenet.com, sos@freebsd.dk, julian@whistle.com, hackers@FreeBSD.ORG In-Reply-To: <199711271821.TAA01333@yedi.iaf.nl> from "Wilko Bulte" at Nov 27, 97 07:21:43 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > I know :), I just wanted to get this straight, we don't want a new > > > "inherrently broken by design" subsystem again. > > > > Inre this comment and the previous comment about my large patches > > to the filesystem: my union mounts work, do yours? > > Oh OH! Are you people preparing to start a major flamefest again? No. I was simply addressing the backhanded putdown of code that works in the context of ``we don't want a new "inherrently broken by design" subsystem again''. The current VFS code meets that criteria. I can phrase it another way, if you want: You don't want a new one... but you want to keep the old ones? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Nov 27 14:59:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA29106 for hackers-outgoing; Thu, 27 Nov 1997 14:59:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA29101 for ; Thu, 27 Nov 1997 14:59:53 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id QAA02225; Thu, 27 Nov 1997 16:01:30 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp03.primenet.com, id smtpd002212; Thu Nov 27 16:01:26 1997 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id PAA14136; Thu, 27 Nov 1997 15:59:16 -0700 (MST) From: Terry Lambert Message-Id: <199711272259.PAA14136@usr07.primenet.com> Subject: Re: detecting devfs from userland? To: proff@iq.org (Julian Assange) Date: Thu, 27 Nov 1997 22:59:16 +0000 (GMT) Cc: hackers@freebsd.org In-Reply-To: <19971126232220.5569.qmail@iq.org> from "Julian Assange" at Nov 26, 97 11:22:20 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Is there anyway to detect if the running kernel was built with > -DDEVFS, other than trying to mount -t devfs ? (i.e a way that > doesn't require root privs? sysctl -a is of no use here. Access everything, and if you get an EXNIO or one of you peripherals can't be accessed because the node was never created, then you're not running DEVFS. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Nov 27 15:02:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA29294 for hackers-outgoing; Thu, 27 Nov 1997 15:02:45 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA29281 for ; Thu, 27 Nov 1997 15:02:40 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.5) with ESMTP id PAA01697; Thu, 27 Nov 1997 15:02:29 -0800 (PST) Message-Id: <199711272302.PAA01697@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: mark@vmunix.com (Mark Mayo) cc: didier@omnix.net, hackers@FreeBSD.ORG Subject: Re: RealAudio/Video In-reply-to: Your message of "Thu, 27 Nov 1997 22:49:02 +0100." <199711272149.WAA09137@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Nov 1997 15:02:28 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > If you have a recent -current then shouldn't have any problems > > > using the realaudio player with your sb card. > > > > Is one supposed to use the traditional snd0 Voxware drivers, or > > Luigi's new sound code for this? > > both should work. > > luigi Whenever possible try to use Luigi's sound driver. Cheers, Amancio From owner-freebsd-hackers Thu Nov 27 15:08:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA29621 for hackers-outgoing; Thu, 27 Nov 1997 15:08:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA29616 for ; Thu, 27 Nov 1997 15:08:21 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id QAA00780; Thu, 27 Nov 1997 16:08:21 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp04.primenet.com, id smtpd000767; Thu Nov 27 16:08:18 1997 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id QAA14601; Thu, 27 Nov 1997 16:08:06 -0700 (MST) From: Terry Lambert Message-Id: <199711272308.QAA14601@usr07.primenet.com> Subject: Re: detecting devfs from userland? To: dk+@ua.net Date: Thu, 27 Nov 1997 23:08:06 +0000 (GMT) Cc: proff@iq.org, julian@whistle.com, freebsd-hackers@freebsd.org In-Reply-To: <199711270328.TAA25467@dog.farm.org> from "Dmitry Kohmanyuk" at Nov 26, 97 07:28:21 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I think that having devfs creating its own device would be nice thing > for this purpose... i.e., just stat "/dev/devfs" to check if devfs > is running. As an added bonus, devfs operations can be added by > reading, writing, or ioctl'ing this device. > > this can work if you need to check whether devfs is running _now_, > as opposed to knowing whether it is compiled into the kernel. You can do the same thing by doing a stat of /dev and looking for an st_ino of 2. The devices themselves, especially in the new SLICE stuff that he's done, should be self-referrential. I'm still trying to talk him into putting them in a hierarchy (with little success... you SVR4 device name traditionalists can rest easy: you still get you have your long cryptic device names for now...). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Nov 27 15:12:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA29814 for hackers-outgoing; Thu, 27 Nov 1997 15:12:49 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA29807 for ; Thu, 27 Nov 1997 15:12:47 -0800 (PST) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.8/8.8.7) with ESMTP id PAA18270 for ; Thu, 27 Nov 1997 15:12:46 -0800 (PST) (envelope-from jdp) Message-Id: <199711272312.PAA18270@austin.polstra.com> To: hackers@freebsd.org Subject: Re: [j@uriah.heep.sax.de: Re: conflict link.h dlfcn.h] In-Reply-To: <19971127153941.48321@uriah.heep.sax.de> References: <19971127153941.48321@uriah.heep.sax.de> Organization: Polstra & Co., Seattle, WA Date: Thu, 27 Nov 1997 15:12:45 -0800 From: John Polstra Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <19971127153941.48321@uriah.heep.sax.de>, J Wunsch wrote: > > Strange. In my copy of , i've got: > > /* > * dl*() prototypes. > */ > extern void *dlopen __P((char *, int)); > extern int dlclose __P((void *)); > extern void *dlsym __P((void *, char *)); > extern char *dlerror __P((void)); > > i.e., no `const'. Surely this should rather suck in instead. (Nice Freudian slip, Joerg! ;-) ---------------^^^^ You're right, those prototypes don't belong in . I remember I had plans to take them out of there, but I must have gotten distracted. I'm about to rebuild world on my -current machine, so I'll remove them and make sure it doesn't cause any problems. If it works out OK, I'll commit the change Real Soon Now. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Thu Nov 27 15:21:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA00333 for hackers-outgoing; Thu, 27 Nov 1997 15:21:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA00328 for ; Thu, 27 Nov 1997 15:21:06 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id XAA09193; Thu, 27 Nov 1997 23:16:53 +0100 From: Luigi Rizzo Message-Id: <199711272216.XAA09193@labinfo.iet.unipi.it> Subject: a networking question... To: hackers@freebsd.org Date: Thu, 27 Nov 1997 23:16:53 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have the following problem with UDP: if I receive a packet with recvmsg, the identity of the sender is returned in a sockaddr structure. However, I have no idea of the destination address this packet was sent to. On a multihomed machine, this might be a problem even with unicast; on a single-homed machine, this is a problem with multicast. Is there any way to be returned the destination address as well ? Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Thu Nov 27 15:41:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA01249 for hackers-outgoing; Thu, 27 Nov 1997 15:41:45 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA01244 for ; Thu, 27 Nov 1997 15:41:42 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (tc-if3-24.ida.net [208.141.171.129]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id QAA10045; Thu, 27 Nov 1997 16:41:23 -0700 Date: Thu, 27 Nov 1997 16:40:35 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: John Polstra cc: hackers@FreeBSD.ORG, darius@senet.com.au Subject: Re: Shared Libraries and debugging In-Reply-To: <199711272255.OAA18209@austin.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 27 Nov 1997, John Polstra wrote: > Judging by the cause of the problem, I doubt that it ever worked. In > order to examine shared libraries, gdb needs to look at the dynamic > linker's table which records where they were loaded into memory. The > dynamic linker has always recorded this information in a MAP_ANON > region way up high in the address space. But such regions are not > written to the core file when a core dump occurs. So gdb has not been > able to get the information it needs. So memory allocated with mmap() is not dumped in a core file? Is this not possible or just not desirable? Charles Mott From owner-freebsd-hackers Thu Nov 27 15:46:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA01521 for hackers-outgoing; Thu, 27 Nov 1997 15:46:52 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mail.scsn.net (scsn.net [206.25.246.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA01516 for ; Thu, 27 Nov 1997 15:46:47 -0800 (PST) (envelope-from dmaddox@scsn.net) Received: from rhiannon.scsn.net ([208.133.153.41]) by mail.scsn.net (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-41950U6000L1100S0) with ESMTP id AAA138; Thu, 27 Nov 1997 18:46:34 -0500 Received: (from root@localhost) by rhiannon.scsn.net (8.8.8/8.8.7) id SAA16483; Thu, 27 Nov 1997 18:46:26 -0500 (EST) (envelope-from root) Message-ID: <19971127184625.53314@scsn.net> Date: Thu, 27 Nov 1997 18:46:25 -0500 From: dmaddox@scsn.net (Donald J. Maddox) To: Luigi Rizzo Cc: Mark Mayo , hasty@rah.star-gate.com, didier@omnix.net, hackers@FreeBSD.ORG Subject: Re: RealAudio/Video Reply-To: dmaddox@scsn.net References: <19971127141353.57146@vmunix.com> <199711272149.WAA09137@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199711272149.WAA09137@labinfo.iet.unipi.it>; from Luigi Rizzo on Thu, Nov 27, 1997 at 10:49:02PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Nov 27, 1997 at 10:49:02PM +0100, Luigi Rizzo wrote: > > > If you have a recent -current then shouldn't have any problems > > > using the realaudio player with your sb card. > > > > Is one supposed to use the traditional snd0 Voxware drivers, or > > Luigi's new sound code for this? > > both should work. > > luigi Neither works on my -current box... I no longer get the error messages about unsupported ioctls, but the player still hangs after each frame of video. Hitting the pause button followed by play will advance one frame each time, accompanied by a very brief spurt of audio. I have tried this with both pcm0 and snd0. Here is my current dmesg output, followed by `cat /dev/sndstat`: # dmesg Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-CURRENT #0: Mon Nov 24 17:28:36 EST 1997 root@rhiannon.scsn.net:/usr/src/sys/compile/RHIANNON CPU: Pentium (166.19-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x1bf real memory = 33554432 (32768K bytes) avail memory = 30605312 (29888K bytes) Probing for devices on PCI bus 0: chip0: rev 0x01 on pci0.0.0 chip1: rev 0x00 on pci0.7.0 ide_pci0: rev 0x00 on pci0.7.1 ahc0: rev 0x00 int a irq 12 on pci0.10.0 ahc0: aic7880 Wide Channel, SCSI Id=7, 16/255 SCBs scbus0 at ahc0 bus 0 ahc0: target 0 Tagged Queuing Device sd0 at scbus0 target 0 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access 2040MB (4178874 512 byte sectors) sd0: with 2708 cyls, 19 heads, and an average 81 sectors/track ahc0: target 1 Tagged Queuing Device sd1 at scbus0 target 1 lun 0 sd1: type 0 fixed SCSI 2 sd1: Direct-Access 507MB (1039329 512 byte sectors) sd1: with 2380 cyls, 6 heads, and an average 72 sectors/track vga0: rev 0x00 int a irq 11 on pci0.12.0 Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio3 at 0x2e8-0x2ef irq 9 on isa sio3: type 16550A pca0 on motherboard pca0: PC speaker audio driver wdc0 at 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa wdc0: unit 0 (wd0): , DMA, 32-bit, multi-block-32 wd0: 1277MB (2615760 sectors), 2595 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (atapi): , removable, iordy atapi0.1: unknown phase fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in npx0 on motherboard npx0: INT 16 interface sb0 at 0x220 irq 5 drq 1 on isa snd0: sbxvi0 at ? drq 5 on isa snd0: sbmidi0 at 0x330 on isa snd0: opl0 at 0x388 on isa snd0: joy0 at 0x201 on isa joy0: joystick ccd0-3: Concatenated disk drivers # cat /dev/sndstat VoxWare Sound Driver:3.5-alpha15-970902 (Wed Aug 6 22:58:35 PDT 1997 Amancio Hasty@rah.star-gate.com) Config options: Installed drivers: Type 1: OPL-2/OPL-3 FM Type 2: SoundBlaster Type 6: SoundBlaster16 Type 7: SB16 MIDI Card config: SoundBlaster at 0x220 irq 5 drq 1 SoundBlaster16 at 0xffffffff irq 1 drq 5 SB16 MIDI at 0x330 irq 1 OPL-2/OPL-3 FM at 0x388 irq 1 Audio devices: 0: SoundBlaster 16 4.13 Synth devices: 0: Yamaha OPL-3 Midi devices: 0: SoundBlaster 16 Midi Timers: 0: System clock Mixers: 0: SoundBlaster From owner-freebsd-hackers Thu Nov 27 15:51:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA01939 for hackers-outgoing; Thu, 27 Nov 1997 15:51:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA01931 for ; Thu, 27 Nov 1997 15:51:43 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (tc-if3-24.ida.net [208.141.171.129]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id QAA10057; Thu, 27 Nov 1997 16:51:33 -0700 Date: Thu, 27 Nov 1997 16:50:55 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: Luigi Rizzo cc: hackers@FreeBSD.ORG Subject: Re: a networking question... In-Reply-To: <199711272216.XAA09193@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 27 Nov 1997, Luigi Rizzo wrote: > I have the following problem with UDP: > > if I receive a packet with recvmsg, the identity of the sender is > returned in a sockaddr structure. However, I have no idea of the > destination address this packet was sent to. > > On a multihomed machine, this might be a problem even with unicast; > on a single-homed machine, this is a problem with multicast. > > Is there any way to be returned the destination address as well ? > > Cheers > Luigi I had a similar question which was kindly answered by a person named Alex (bag@sinbin.demos.su). He suggested that I use the recvmsg() call, and IP_RECVDSTADDR option enabled (man 4 ip). Another approach is to open a distinct socket for each address you are listening on and then using select() and FD_ISSET to see which socket and therefore which address the packet arrived at. Charles Mott From owner-freebsd-hackers Thu Nov 27 16:07:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA02750 for hackers-outgoing; Thu, 27 Nov 1997 16:07:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA02735 for ; Thu, 27 Nov 1997 16:07:03 -0800 (PST) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.8/8.8.7) with ESMTP id QAA18537; Thu, 27 Nov 1997 16:07:00 -0800 (PST) (envelope-from jdp) Message-Id: <199711280007.QAA18537@austin.polstra.com> To: Charles Mott cc: hackers@FreeBSD.ORG Subject: Re: Shared Libraries and debugging In-reply-to: Your message of "Thu, 27 Nov 1997 16:40:35 MST." Date: Thu, 27 Nov 1997 16:07:00 -0800 From: John Polstra Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > So memory allocated with mmap() is not dumped in a core file? Right. You get the "u" area and the data segment and the stack segment. The data segment is the contiguous region from "etext" up to the sbrk(2) level. I.e., its data + bss + the heap. > Is this not possible Practically anything would be possible. :-) > or just not desirable? Sometimes it might be desirable, and sometimes not. It would require a new core file format that permitted multiple noncontiguous segments. (ELF core files could handle this -- they have the same format as ELF object files.) And of course it would complicate the kernel code that generates core files. And you could end up with some mighty large core files at times. Most mmapped areas are just shared libraries, which still exist on disk. True, they have some data areas that might have been changed by the program, but the data areas in shared libraries are usually relatively small. If you dumped the mmapped areas, you'd probably want to limit it to only the writable regions, on the assumption that the read-only regions could be gotten from the underlying files on disk. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Thu Nov 27 16:50:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA04896 for hackers-outgoing; Thu, 27 Nov 1997 16:50:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA04889 for ; Thu, 27 Nov 1997 16:50:38 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id BAA20731 for hackers@FreeBSD.ORG; Fri, 28 Nov 1997 01:50:36 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id BAA03210; Fri, 28 Nov 1997 01:45:18 +0100 (MET) Message-ID: <19971128014518.63714@uriah.heep.sax.de> Date: Fri, 28 Nov 1997 01:45:18 +0100 From: J Wunsch To: hackers@FreeBSD.ORG Subject: Re: [j@uriah.heep.sax.de: Re: conflict link.h dlfcn.h] Reply-To: Joerg Wunsch References: <19971127153941.48321@uriah.heep.sax.de> <199711272312.PAA18270@austin.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199711272312.PAA18270@austin.polstra.com>; from John Polstra on Thu, Nov 27, 1997 at 03:12:45PM -0800 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As John Polstra wrote: > > i.e., no `const'. Surely this should rather suck in instead. > > (Nice Freudian slip, Joerg! ;-) ---------------^^^^ Not really. Poor English, combined with enough laziness to not look into a dictionary for better wording. ;) But we met in person already, John, so you know i'm not that good with my English at all... > .., I'll commit the change Real Soon Now. ^^^^^^^^^^^^^ Hmm, too bad, i thought we could hope for a final solution within _this_ millenium. <:-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Nov 27 16:52:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA04959 for hackers-outgoing; Thu, 27 Nov 1997 16:52:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from seidata.com (seidata.com [206.160.242.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA04953; Thu, 27 Nov 1997 16:51:38 -0800 (PST) (envelope-from mike@seidata.com) Received: from localhost (mike@localhost) by seidata.com (8.8.8/8.8.5) with SMTP id TAA17048; Thu, 27 Nov 1997 19:50:20 -0500 (EST) Date: Thu, 27 Nov 1997 19:50:19 -0500 (EST) From: Mike To: Stephen Roome cc: Nate Williams , Julian Elischer , hackers@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: BIND 8.1.1 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Couldn't 8.1.1 be made a package/port in the meantime, it would make > life a bit easier for all the isp folks who run FreeBSD. It would promote that key virtue of system administration: laziness. ;) Indeed, I'm sure it could easily be made a package, but... > How many (any?) new users will chose Linux/BSDi/Solaris or whatever else > is now running 8.1.1 by default ? If installing BIND 8 causes a potential sysadmin to choose another OS, that sysadmin won't last long in the real world. The BIND 8 install is cliche easy (1-2-3). See http://www.isc.org. --- Mike Hoskins SEI Data Network Services, Inc. mike@seidata.com From owner-freebsd-hackers Thu Nov 27 17:16:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA06440 for hackers-outgoing; Thu, 27 Nov 1997 17:16:48 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA06435 for ; Thu, 27 Nov 1997 17:16:44 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id CAA20988 for hackers@FreeBSD.ORG; Fri, 28 Nov 1997 02:16:41 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id CAA03286; Fri, 28 Nov 1997 02:03:08 +0100 (MET) Message-ID: <19971128020308.23184@uriah.heep.sax.de> Date: Fri, 28 Nov 1997 02:03:08 +0100 From: J Wunsch To: hackers@FreeBSD.ORG Subject: Re: Shared Libraries and debugging Reply-To: Joerg Wunsch References: <199711250748.SAA16393@holly.rd.net> <19971126182058.04145@uriah.heep.sax.de> <199711272255.OAA18209@austin.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199711272255.OAA18209@austin.polstra.com>; from John Polstra on Thu, Nov 27, 1997 at 02:55:56PM -0800 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As John Polstra wrote: > > I usually set a breakpoint at main(), run it till there, and then > > voila!, you can also specify breakpoints at shared lib functions... > > But he was asking about core dumps. And he's right, it doesn't work. I missed this detail, but i think the same trick did work for me by accident. Probably, i was just lucky enough that subsequential runs of the same program caused the same mappings. Since running a program until the entry of main() causes all the (default) shared libs to be mapped, i've got something that could be used even with a coredump. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu Nov 27 17:18:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA06650 for hackers-outgoing; Thu, 27 Nov 1997 17:18:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA06641 for ; Thu, 27 Nov 1997 17:18:01 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.5) with ESMTP id RAA00357; Thu, 27 Nov 1997 17:17:44 -0800 (PST) Message-Id: <199711280117.RAA00357@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: dmaddox@scsn.net cc: Luigi Rizzo , Mark Mayo , didier@omnix.net, hackers@freebsd.org Subject: Re: RealAudio/Video In-reply-to: Your message of "Thu, 27 Nov 1997 18:46:25 EST." <19971127184625.53314@scsn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Nov 1997 17:17:44 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk How recent is your 3.0 -current? The latest 3.0 -current works. Amancio From owner-freebsd-hackers Thu Nov 27 17:22:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA07048 for hackers-outgoing; Thu, 27 Nov 1997 17:22:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mail.scsn.net (scsn.net [206.25.246.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA07035 for ; Thu, 27 Nov 1997 17:21:57 -0800 (PST) (envelope-from dmaddox@scsn.net) Received: from rhiannon.scsn.net ([208.133.153.41]) by mail.scsn.net (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-41950U6000L1100S0) with ESMTP id AAA192; Thu, 27 Nov 1997 20:21:46 -0500 Received: (from root@localhost) by rhiannon.scsn.net (8.8.8/8.8.7) id UAA19468; Thu, 27 Nov 1997 20:21:37 -0500 (EST) (envelope-from root) Message-ID: <19971127202134.04438@coladlp1.scsn.net> Date: Thu, 27 Nov 1997 20:21:34 -0500 From: "Donald J. Maddox" To: Amancio Hasty Cc: dmaddox@scsn.net, Luigi Rizzo , Mark Mayo , didier@omnix.net, hackers@freebsd.org Subject: Re: RealAudio/Video Reply-To: dmaddox@scsn.net References: <19971127184625.53314@scsn.net> <199711280117.RAA00357@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199711280117.RAA00357@rah.star-gate.com>; from Amancio Hasty on Thu, Nov 27, 1997 at 05:17:44PM -0800 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, Nov 27, 1997 at 05:17:44PM -0800, Amancio Hasty wrote: > > How recent is your 3.0 -current? > > The latest 3.0 -current works. > > Amancio FreeBSD ppp41.coladlp1.scsn.net 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Mon Nov 24 17:28:36 EST 1997 root@rhiannon.scsn.net:/usr/src/sys/compile/RHIANNON i386 From owner-freebsd-hackers Thu Nov 27 17:54:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA09178 for hackers-outgoing; Thu, 27 Nov 1997 17:54:03 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ren.dtir.qld.gov.au (firewall-user@ns.dtir.qld.gov.au [203.108.138.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA09173 for ; Thu, 27 Nov 1997 17:54:00 -0800 (PST) (envelope-from syssgm@dtir.qld.gov.au) Received: by ren.dtir.qld.gov.au; id LAA15541; Fri, 28 Nov 1997 11:54:10 +1000 (EST) Received: from ogre.dtir.qld.gov.au(167.123.8.3) by ren.dtir.qld.gov.au via smap (3.2) id xma015531; Fri, 28 Nov 97 11:53:57 +1000 Received: from troll.dtir.qld.gov.au (troll.dtir.qld.gov.au [167.123.8.1]) by ogre.dtir.qld.gov.au (8.8.7/8.8.7) with ESMTP id LAA03678; Fri, 28 Nov 1997 11:54:01 +1000 (EST) Received: (from syssgm@localhost) by troll.dtir.qld.gov.au (8.8.5/8.8.5) id LAA05490; Fri, 28 Nov 1997 11:54:01 +1000 (EST) Date: Fri, 28 Nov 1997 11:54:01 +1000 (EST) Message-Id: <199711280154.LAA05490@troll.dtir.qld.gov.au> To: freebsd-hackers@freebsd.org cc: syssgm@dtir.qld.gov.au Subject: Re: Updated f00f workaround References: <199711270743.XAA08912@kithrup.com> In-Reply-To: <199711270743.XAA08912@kithrup.com> from Sean Eric Fagan at "Thu, 27 Nov 1997 07:43:19 +0000" From: Stephen McKay Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [Yesterday hub.freebsd.org rejected this with '550 Access denied' so let's see how it goes today!] On Thursday, 27th November 1997, Sean Eric Fagan wrote: >Well, I was waiting for someone else to do anything about this, but >everybody is apparantly busy :). Yeah, even though this is fun (in a sicko way) and highly technical (Homer: Hmmmm, processor erratum!) it still has to compete for time with the dramas of Real Life(tm). Pity. >This isn't quite right -- I think there should be a less obviously-i386 >method of making the page in question non-writable; there should be a better >way to allocate two page-aligned pages of memory You don't want to do that nasty stuff. I would allocate 2 pages with addr = kmem_alloc(kernel_map, 2*PAGE_SIZE); and unmap the first page with vm_map_protect(kernel_map, addr, addr+PAGE_SIZE, VM_PROT_NONE, FALSE); though it is unclear to me how this relates to vm_page_protect() which would have played with PG_WRITEABLE. Oh well, more reading to be done. Um, having just re-read your code, you are expecting the F00F instruction to write to the IDT? [Quick trot over to www.intel.com] Well, that's an odd thing, eh? It will page fault on a non-writable IDT when thinking about delivering an Invalid Opcode Exception! Hopefully it's just because of the lock prefix, or these Intel processors are weird! So, if you are using that workaround, I think you only have to allocate one page, put the goodies in it, and make it read-only with vm_map_protect(). You have to read between the lines, but Intel is implying that there is no split-over-a-page-boundary requirement for this one, and that only exception 6 will cause a page fault. They claim that you only have to do the split trick if you want to update the exception handlers for 7 and up on the fly. Even if we wanted to do that, we could just turn it on, frob, and turn it off. No user code would run in that interval. >and the check for the >fault address should be done lower, but I don't know the code well enough to >decide where. The IDT is in kernel memory and the fault will come from ring 0, so you want to move your test down a bit (to before line 642 of my 2.2.5-stable trap.c after the comment "...kernel virtual address addresses always have pte pages mapped...") to avoid triggering from user mode accesses. Also the Intel notes imply that an explicit equality test of the faulting address against the exception 6 address is sufficient, so you should be able to convert your test to: if (eva == (int)&t_idt[6] && has_f00f_bug) { frame->tf_trapno = T_PRIVINFLT; return -2; } Final warning: I only look like I know what I'm doing. I've never actually done any of this! :-) Stephen. From owner-freebsd-hackers Thu Nov 27 18:08:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA10449 for hackers-outgoing; Thu, 27 Nov 1997 18:08:33 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA10444 for ; Thu, 27 Nov 1997 18:08:29 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.5) with ESMTP id SAA00587; Thu, 27 Nov 1997 18:08:02 -0800 (PST) Message-Id: <199711280208.SAA00587@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: dmaddox@scsn.net cc: Luigi Rizzo , Mark Mayo , didier@omnix.net, hackers@freebsd.org Subject: Re: RealAudio/Video In-reply-to: Your message of "Thu, 27 Nov 1997 20:21:34 EST." <19971127202134.04438@coladlp1.scsn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Nov 1997 18:08:01 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk mail me back /sys/i386/isa/sound/audio.c Tnks, Amancio From owner-freebsd-hackers Thu Nov 27 19:27:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA14917 for hackers-outgoing; Thu, 27 Nov 1997 19:27:52 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from teel.info-noire.com (slpp-51.interlinx.qc.ca [207.134.144.70]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA14911 for ; Thu, 27 Nov 1997 19:27:47 -0800 (PST) (envelope-from alex@teel.info-noire.com) Received: from localhost (alex@localhost) by teel.info-noire.com (8.8.8/8.8.5) with SMTP id WAA04088; Thu, 27 Nov 1997 22:27:41 -0500 (EST) Date: Thu, 27 Nov 1997 22:27:41 -0500 (EST) From: Alex Boisvert Reply-To: Alex Boisvert To: John Polstra cc: hackers@FreeBSD.ORG, darius@senet.com.au Subject: Re: Shared Libraries and debugging In-Reply-To: <199711272255.OAA18209@austin.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > But he was asking about core dumps. And he's right, it doesn't work. > I've been looking into it, and I have a fix to the dynamic linker that > seems to make it work fine. I'll commit it after I do a make world > and a little bit more testing. > Can this be "added" to -stable sometimes? If not, can the patches be applied to a -stable system without too much fuss? I'd like to have that "feature" when debugging. (I can wait 'till you test the beast, though) Regards, Alex. From owner-freebsd-hackers Thu Nov 27 21:44:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA21907 for hackers-outgoing; Thu, 27 Nov 1997 21:44:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA21870 for ; Thu, 27 Nov 1997 21:43:57 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (tc-if3-24.ida.net [208.141.171.129]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id WAA10339 for ; Thu, 27 Nov 1997 22:43:48 -0700 Date: Thu, 27 Nov 1997 22:43:01 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: hackers@freebsd.org Subject: flock() question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Below are two test programs. What I observe is that if a file descriptor is opened and a process forks, then advisory locking does not appear to work. On the other hand, if the process forks, and then the file is opened independently by each process, advisory locking works perfectly well. Is this correct? From reading the man page on flock(2), I would have guessed that locking would have worked in both situations. I am running 2.2.2-R. -- Charles Mott *** Test 1: open() before fork() *** #include #include #include #include main() { int fd; fd = open("locktest", O_WRONLY | O_CREAT, 0644); fork(); for (;;) { printf("(1) pid=%d\n", getpid()); flock(fd, LOCK_EX); printf("(2) pid=%d\n", getpid()); sleep(5); printf("(3) pid=%d\n", getpid()); flock(fd, LOCK_UN); } } *** Test 2: open() after fork() *** #include #include #include #include main() { int fd; fork(); fd = open("locktest", O_WRONLY | O_CREAT, 0644); for (;;) { printf("(1) pid=%d\n", getpid()); flock(fd, LOCK_EX); printf("(2) pid=%d\n", getpid()); sleep(5); printf("(3) pid=%d\n", getpid()); flock(fd, LOCK_UN); } } From owner-freebsd-hackers Thu Nov 27 22:19:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA23379 for hackers-outgoing; Thu, 27 Nov 1997 22:19:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from super.zippo.com (perry.zippo.com [207.211.168.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA23370 for ; Thu, 27 Nov 1997 22:19:22 -0800 (PST) (envelope-from reyesf@super.zippo.com) Received: (from reyesf@localhost) by super.zippo.com (8.8.6/8.8.7) id WAA15203; Thu, 27 Nov 1997 22:19:22 -0800 (PST) Message-Id: <199711280619.WAA15203@super.zippo.com> From: "Francisco Reyes" To: "hackers@freebsd.org" Date: Fri, 28 Nov 97 01:18:56 -0400 Reply-To: "Francisco Reyes" Priority: Normal X-Mailer: PMMail 1.95a For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Why bootup message doesn't stay longer? (2.2.5) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Once I got 2.2.5 I was pleasantly surprised by the new bootup message. However, I find it does not stay on long enough. I think a better approach is to have a longer time and have an option to press a key to turn off the timer for this time. The reasons behind this is that new users would be the ones reading that first page. The current amount of time is too little for a new comer to look at the info displayed. From owner-freebsd-hackers Thu Nov 27 22:52:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA25024 for hackers-outgoing; Thu, 27 Nov 1997 22:52:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA25018 for ; Thu, 27 Nov 1997 22:52:32 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id XAA09600; Thu, 27 Nov 1997 23:52:29 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id XAA28248; Thu, 27 Nov 1997 23:51:23 -0700 (MST) Date: Thu, 27 Nov 1997 23:51:22 -0700 (MST) From: Marc Slemko To: Charles Mott cc: hackers@FreeBSD.ORG Subject: Re: flock() question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 27 Nov 1997, Charles Mott wrote: > Below are two test programs. What I observe is that if a file descriptor > is opened and a process forks, then advisory locking does not appear to > work. On the other hand, if the process forks, and then the file is > opened independently by each process, advisory locking works perfectly > well. > > Is this correct? From reading the man page on flock(2), I would have Locking works fine. It just doesn't do what you think it does. > guessed that locking would have worked in both situations. I am running > 2.2.2-R. from the man page: Locks are on files, not file descriptors. That is, file descriptors du- plicated through dup(2) or fork(2) do not result in multiple instances of a lock, but rather multiple references to a single lock. If a process holding a lock on a file forks and the child explicitly unlocks the file, the parent will lose its lock. See the USE_FLOCK_SERIALIZED_ACCEPT stuff in Apache before 1..3b3 for an example of how not to do it. See the USE_FLOCK_SERIALIZED_ACCEPT stuff in Apache 1.3b3 for an example of how to do it. Essentially it boils down to what you say. It is a pain and is a horrible broken thing about flock() locking. OTOH, fcntl() locking doesn't work that way and it is also horrible broken. Neither of the semantics are great, and both are arguably dumb in certain ways. Hmm. It looks like if you have multiple processes blocked on the same lock in FreeBSD (well, 2.2 anyway), they are all woken up when the lock is freed. Yes, only one will get the lock but they will all be woken. Unless I am reading the code wrong... This is in contrast to multiple processes blocking in accept(), where only one will be woken up. From owner-freebsd-hackers Thu Nov 27 23:46:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA27779 for hackers-outgoing; Thu, 27 Nov 1997 23:46:58 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA27772 for ; Thu, 27 Nov 1997 23:46:55 -0800 (PST) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.8/8.8.8) id IAA11480 for hackers@freebsd.org; Fri, 28 Nov 1997 08:42:07 +0100 (MET) (envelope-from sos) Message-Id: <199711280742.IAA11480@sos.freebsd.dk> Subject: LM78 what port # ?? To: hackers@freebsd.org (FreeBSD hackers) Date: Fri, 28 Nov 1997 08:42:06 +0100 (MET) From: Søren Schmidt Reply-to: sos@FreeBSD.dk X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Simple question: What port # are the LM78 system monitor chips located at in varios PC's, there might even be a concensus on it :) (No, I dont have a MB with one, but I'm building an ISA board with one) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Fri Nov 28 00:25:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA00300 for hackers-outgoing; Fri, 28 Nov 1997 00:25:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA00293 for ; Fri, 28 Nov 1997 00:25:30 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id IAA09681; Fri, 28 Nov 1997 08:19:05 +0100 From: Luigi Rizzo Message-Id: <199711280719.IAA09681@labinfo.iet.unipi.it> Subject: Re: RealAudio/Video To: dmaddox@scsn.net Date: Fri, 28 Nov 1997 08:19:05 +0100 (MET) Cc: mark@vmunix.com, hasty@rah.star-gate.com, didier@omnix.net, hackers@FreeBSD.ORG In-Reply-To: <19971127184625.53314@scsn.net> from "Donald J. Maddox" at Nov 27, 97 06:46:06 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Thu, Nov 27, 1997 at 10:49:02PM +0100, Luigi Rizzo wrote: > > > > If you have a recent -current then shouldn't have any problems > > > > using the realaudio player with your sb card. > > > > > > Is one supposed to use the traditional snd0 Voxware drivers, or > > > Luigi's new sound code for this? > > > > both should work. > > > > luigi > > Neither works on my -current box... I no longer get the error > messages about unsupported ioctls, but the player still hangs after the version of my driver which supports realaudio (including the changes to linux_ioctl.c) is snd971117.tgz -- not completely sure if it is already in -current but should be. cheers luigi From owner-freebsd-hackers Fri Nov 28 01:40:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA03893 for hackers-outgoing; Fri, 28 Nov 1997 01:40:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from kott.my.domain (root@pm332-14.dialip.mich.net [207.74.188.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA03888 for ; Fri, 28 Nov 1997 01:40:08 -0800 (PST) (envelope-from dakott@alpha.delta.edu) Received: from kott.my.domain (dakott@kott.my.domain [192.168.0.1]) by kott.my.domain (8.8.8/8.8.5) with SMTP id EAA00582; Fri, 28 Nov 1997 04:05:17 -0500 (EST) Date: Fri, 28 Nov 1997 04:05:15 -0500 (EST) From: David Kott To: Francisco Reyes cc: "hackers@freebsd.org" Subject: Re: Why bootup message doesn't stay longer? (2.2.5) In-Reply-To: <199711280619.WAA15203@super.zippo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 28 Nov 1997, Francisco Reyes wrote: > I think a better approach is to have a longer time and have an option > to press a key to turn off the timer for this time. > > The reasons behind this is that new users would be the ones reading > that first page. The current amount of time is too little for a new > comer to look at the info displayed. > You have only to type a single character at the prompt (your keypress) to read this message. also, I think you can change that under /usr/src/sys/i386/boot/biosboot/Makefile with the BOOTWAIT?= 5000 parameter... if you were so inclined. -d From owner-freebsd-hackers Fri Nov 28 02:08:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA05483 for hackers-outgoing; Fri, 28 Nov 1997 02:08:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA05473 for ; Fri, 28 Nov 1997 02:08:03 -0800 (PST) (envelope-from semen@iclub.nsu.ru) Received: from localhost (semen@localhost) by iclub.nsu.ru (8.8.8/8.8.5) with SMTP id QAA22945 for ; Fri, 28 Nov 1997 16:08:01 +0600 (NS) Date: Fri, 28 Nov 1997 16:08:01 +0600 (NS) From: Ustimenko Semen To: hackers@FreeBSD.org Subject: EtherPower II 10/100 (aka SMC9432TX) driver Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk New version of driver released, BPF now supported! http://iclub.nsu.ru/~semen/smc9432tx/smc9432tx.html If somebody knows where to get informaion on EtherPower II card, tell me. Thank you. From owner-freebsd-hackers Fri Nov 28 02:20:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA05958 for hackers-outgoing; Fri, 28 Nov 1997 02:20:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA05948 for ; Fri, 28 Nov 1997 02:20:49 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id LAA25226 for hackers@FreeBSD.ORG; Fri, 28 Nov 1997 11:20:42 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id LAA05385; Fri, 28 Nov 1997 11:08:36 +0100 (MET) Message-ID: <19971128110836.02671@uriah.heep.sax.de> Date: Fri, 28 Nov 1997 11:08:36 +0100 From: J Wunsch To: hackers@FreeBSD.ORG Subject: Re: BIND 8.1.1 Reply-To: Joerg Wunsch References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Mike on Thu, Nov 27, 1997 at 07:50:19PM -0500 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Mike wrote: > > Couldn't 8.1.1 be made a package/port in the meantime, it would make > > life a bit easier for all the isp folks who run FreeBSD. > > It would promote that key virtue of system administration: laziness. ;) > Indeed, I'm sure it could easily be made a package, but... Folks, if you would, instead of arguing over and over again, watch the commit logs a little, you had noticed it: jseger 1997/11/25 16:24:20 PST ports/net/bind8 - Imported sources jseger 1997/11/25 16:25:16 PST Modified files: net Makefile Log: Activate bind8 Revision Changes Path 1.130 +2 -1 ports/net/Makefile ;-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Fri Nov 28 03:04:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA07792 for hackers-outgoing; Fri, 28 Nov 1997 03:04:43 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA07787 for ; Fri, 28 Nov 1997 03:04:37 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id DAA14169; Fri, 28 Nov 1997 03:07:25 -0800 (PST) Message-Id: <199711281107.DAA14169@implode.root.com> To: Marc Slemko cc: Charles Mott , hackers@FreeBSD.ORG Subject: Re: flock() question In-reply-to: Your message of "Thu, 27 Nov 1997 23:51:22 MST." From: David Greenman Reply-To: dg@root.com Date: Fri, 28 Nov 1997 03:07:25 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Hmm. It looks like if you have multiple processes blocked on the >same lock in FreeBSD (well, 2.2 anyway), they are all woken up when >the lock is freed. Yes, only one will get the lock but they will >all be woken. Unless I am reading the code wrong... This is in >contrast to multiple processes blocking in accept(), where only >one will be woken up. The optimized wakeup case for accept() is that way because I optimized it. :-) You're probably right about flock(), but I haven't gotten around to looking at that and other potential wakeup optimizations. Changes like that have to be made with great care...what seems obvious often doesn't turn out that way. :-) -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Fri Nov 28 05:00:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA11733 for hackers-outgoing; Fri, 28 Nov 1997 05:00:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA11728 for ; Fri, 28 Nov 1997 05:00:08 -0800 (PST) (envelope-from narvi@Haldjas.folklore.ee) Received: from haldjas.folklore.ee (haldjas.folklore.ee [172.17.2.1] (may be forged)) by haldjas.folklore.ee (8.8.7/8.8.4) with SMTP id OAA05590; Fri, 28 Nov 1997 14:59:49 +0200 (EET) Date: Fri, 28 Nov 1997 14:59:49 +0200 (EET) From: Narvi To: Joerg Wunsch cc: hackers@FreeBSD.ORG, "Brian J. McGovern" Subject: Re: Union and Portal FSs In-Reply-To: <19971127085717.19775@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 27 Nov 1997, J Wunsch wrote: > As Brian J. McGovern wrote: > > > Just out of curiousity, how "decayed" are the Union and Portal > > filesystems,and, more importantly, is anyone working on them? > > Kazu did quite some work on unionfs, and i think it's basically usable > these days. There are still some odds in it (which i'm not sure of > whether they can be easily resolved), like an open attempt with write > intent will yield an EROFS if the lower layer is a read/only > filesystem. > > UFS union mounts ("mount -o union /dev/fd0 /somewhere") seem to have a > different set of problems. I've got this one basically to work, in an > attempt to mount a writable floppy over a read/only CD-ROM /etc, but > when i recently tried under -current with a lower-layer NFS, the > writes went through into the lower layer, ick. :( > > No idea on portals... At least some time ago portalfs worked well enough for tcp connections. Haven't tried filesystems. Sander There is no love, no good, no happiness and no future - all these are just illusions. > > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) > From owner-freebsd-hackers Fri Nov 28 05:46:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA13623 for hackers-outgoing; Fri, 28 Nov 1997 05:46:58 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ren.dtir.qld.gov.au (firewall-user@ns.dtir.qld.gov.au [203.108.138.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA13618 for ; Fri, 28 Nov 1997 05:46:53 -0800 (PST) (envelope-from syssgm@dtir.qld.gov.au) Received: by ren.dtir.qld.gov.au; id XAA05329; Fri, 28 Nov 1997 23:47:15 +1000 (EST) Received: from ogre.dtir.qld.gov.au(167.123.8.3) by ren.dtir.qld.gov.au via smap (3.2) id xma005327; Fri, 28 Nov 97 23:47:05 +1000 Received: from localhost.dtir.qld.gov.au (localhost.dtir.qld.gov.au [127.0.0.1]) by ogre.dtir.qld.gov.au (8.8.7/8.8.7) with SMTP id XAA01518; Fri, 28 Nov 1997 23:46:58 +1000 (EST) Message-Id: <199711281346.XAA01518@ogre.dtir.qld.gov.au> X-Authentication-Warning: ogre.dtir.qld.gov.au: localhost.dtir.qld.gov.au [127.0.0.1] didn't use HELO protocol To: freebsd-hackers@freebsd.org cc: syssgm@dtir.qld.gov.au Subject: Re: flock() question References: In-Reply-To: from Marc Slemko at "Fri, 28 Nov 1997 06:51:22 +0000" Date: Fri, 28 Nov 1997 23:46:57 +1000 From: Stephen McKay Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Friday, 28th November 1997, Marc Slemko wrote: >On Thu, 27 Nov 1997, Charles Mott wrote: > >Locking works fine. It just doesn't do what you think it does. > >> guessed that locking would have worked in both situations. I am running >> 2.2.2-R. > >from the man page: > > Locks are on files, not file descriptors. That is, file descriptors du- > plicated through dup(2) or fork(2) do not result in multiple instances of > a lock, but rather multiple references to a single lock. If a process > holding a lock on a file forks and the child explicitly unlocks the file, > the parent will lose its lock. It's not entirely obvious from this that 1) your own exclusive lock will not prevent you from trying to assert an exclusive lock and 2) you are identified by your file table entry. In other words, you can lock the same file over and over and it doesn't nest. And you and your child are the same locker because you refer to the same file table entry. This is the mechanism in action in the first example program. It's so obscure that I think a manpage rewrite is in order, probably with some sample usage. For example, locks don't really apply to "files" (ie dev/inode) but to "file table entries" (ie channels to files), so an example that opens the same file twice and attempts to lock both file descriptors would deadlock. A few of these should scare most people off. :-) Please beat me to this rewrite. Otherwise it goes on my list. Bit dusty that list, but if the "rellies" leave me alone this Christmas we might see some action. :-) Stephen. From owner-freebsd-hackers Fri Nov 28 06:25:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA15271 for hackers-outgoing; Fri, 28 Nov 1997 06:25:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA15257 for ; Fri, 28 Nov 1997 06:25:27 -0800 (PST) (envelope-from jak@cetlink.net) Received: from hot1.auctionfever.com (ts1-cltnc-24.cetlink.net [209.54.58.24]) by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id JAA11661 for ; Fri, 28 Nov 1997 09:25:22 -0500 (EST) From: jak@cetlink.net (John Kelly) To: hackers@FreeBSD.org Subject: installworld, no space Date: Fri, 28 Nov 1997 15:26:27 GMT Message-ID: <3480e13b.3468623@mail.cetlink.net> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id GAA15258 Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I ran out of space during installworld. Is it safe to move /usr/src to an NFS server and symlink to its new location and start up installworld again? By "safe" I mean will it work that way? John From owner-freebsd-hackers Fri Nov 28 07:44:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA20351 for hackers-outgoing; Fri, 28 Nov 1997 07:44:53 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from anlsun.ebr.anlw.anl.gov (anlsun.ebr.anlw.anl.gov [141.221.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA20346 for ; Fri, 28 Nov 1997 07:44:50 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (dialin1.anlw.anl.gov [141.221.254.101]) by anlsun.ebr.anlw.anl.gov (8.6.11/8.6.11) with SMTP id IAA10882; Fri, 28 Nov 1997 08:44:37 -0700 Date: Fri, 28 Nov 1997 08:44:05 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: Stephen McKay cc: hackers@freebsd.org Subject: Re: flock() question In-Reply-To: <199711281346.XAA01518@ogre.dtir.qld.gov.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 28 Nov 1997, Stephen McKay wrote: > It's not entirely obvious from this that 1) your own exclusive lock will > not prevent you from trying to assert an exclusive lock and 2) you are > identified by your file table entry. In other words, you can lock the > same file over and over and it doesn't nest. And you and your child are > the same locker because you refer to the same file table entry. This > is the mechanism in action in the first example program. > > It's so obscure that I think a manpage rewrite is in order, probably with > some sample usage. For example, locks don't really apply to "files" > (ie dev/inode) but to "file table entries" (ie channels to files), so > an example that opens the same file twice and attempts to lock both > file descriptors would deadlock. A few of these should scare most > people off. :-) > > Please beat me to this rewrite. Otherwise it goes on my list. Bit > dusty that list, but if the "rellies" leave me alone this Christmas > we might see some action. :-) I'll try to do a rewrite and send you something within a week or two. The main problem I have is locating the relevant source code to verify exactly what is going on. There was no flock.c in /usr/src/lib/libc that I could identify and /usr/syr/sys/kern/kern_flock.c was a little opaque to me. Charles Mott From owner-freebsd-hackers Fri Nov 28 08:26:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA22614 for hackers-outgoing; Fri, 28 Nov 1997 08:26:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from white.lambton.on.ca (white.lambton.on.ca [192.139.190.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA22609 for ; Fri, 28 Nov 1997 08:26:30 -0800 (PST) (envelope-from david@lambton.on.ca) Received: from localhost (david@localhost) by white.lambton.on.ca (8.8.7/8.8.7) with SMTP id LAA11236; Fri, 28 Nov 1997 11:26:11 -0500 (EST) Date: Fri, 28 Nov 1997 11:26:11 -0500 (EST) From: David Grant To: Søren Schmidt cc: FreeBSD hackers Subject: Re: LM78 what port # ?? In-Reply-To: <199711280742.IAA11480@sos.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id IAA22610 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The ASUS motherboards are at 0x290 on the isa bus. I haven't started writing code yet. Anyone else working on this? Dave On Fri, 28 Nov 1997, Søren Schmidt wrote: > > Simple question: > > What port # are the LM78 system monitor chips located at in varios > PC's, there might even be a concensus on it :) > > (No, I dont have a MB with one, but I'm building an ISA board with one) > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team > Even more code to hack -- will it ever end > .. > ----- David Grant VE3DGR +1 519 542-7751 x348 Lambton College, Sarnia, ON, CANADA +1 519 542-6667 FAX From owner-freebsd-hackers Fri Nov 28 10:00:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA27800 for hackers-outgoing; Fri, 28 Nov 1997 10:00:22 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA27793 for ; Fri, 28 Nov 1997 10:00:20 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id JAA05112; Fri, 28 Nov 1997 09:55:40 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd005110; Fri Nov 28 09:55:34 1997 Date: Fri, 28 Nov 1997 09:53:19 -0800 (PST) From: Julian Elischer To: Francisco Reyes cc: "hackers@freebsd.org" Subject: Re: Why bootup message doesn't stay longer? (2.2.5) In-Reply-To: <199711280619.WAA15203@super.zippo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk sorry for the previous message, I though you meant teh KERNEL boot messages.. On Fri, 28 Nov 1997, Francisco Reyes wrote: > Once I got 2.2.5 I was pleasantly surprised by the new bootup > message. However, I find it does not stay on long enough. > > I think a better approach is to have a longer time and have an option > to press a key to turn off the timer for this time. > > The reasons behind this is that new users would be the ones reading > that first page. The current amount of time is too little for a new > comer to look at the info displayed. > > From owner-freebsd-hackers Fri Nov 28 10:00:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA27817 for hackers-outgoing; Fri, 28 Nov 1997 10:00:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA27801 for ; Fri, 28 Nov 1997 10:00:22 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id JAA05100; Fri, 28 Nov 1997 09:54:30 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd005098; Fri Nov 28 09:54:25 1997 Date: Fri, 28 Nov 1997 09:52:11 -0800 (PST) From: Julian Elischer To: Francisco Reyes cc: "hackers@freebsd.org" Subject: Re: Why bootup message doesn't stay longer? (2.2.5) In-Reply-To: <199711280619.WAA15203@super.zippo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk hit the 'scroll-lock' key to freeze them, or, if you missed something, hit scroll-lock' to freeze, and the page-up key to go back up the scroll-buffer. hit 'scroll-lock' again to unfreeze, and let the system continue. On Fri, 28 Nov 1997, Francisco Reyes wrote: > Once I got 2.2.5 I was pleasantly surprised by the new bootup > message. However, I find it does not stay on long enough. > > I think a better approach is to have a longer time and have an option > to press a key to turn off the timer for this time. > > The reasons behind this is that new users would be the ones reading > that first page. The current amount of time is too little for a new > comer to look at the info displayed. > > From owner-freebsd-hackers Fri Nov 28 10:12:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA28465 for hackers-outgoing; Fri, 28 Nov 1997 10:12:59 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA28450 for ; Fri, 28 Nov 1997 10:12:54 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id FAA09194; Sat, 29 Nov 1997 05:10:56 +1100 Date: Sat, 29 Nov 1997 05:10:56 +1100 From: Bruce Evans Message-Id: <199711281810.FAA09194@godzilla.zeta.org.au> To: bde@zeta.org.au, mouth@ibm.net Subject: Re: 650 UART, SIO driver, 8259 PIC Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>next bus clock cycle). The handler must not return with the edge latch >>set, at least for 16x50 devices, since if the edge latch is set then >>there must be a device irq and returning would give up the only chance >>of handling the irq. > >I don't see the potential for that problem with FIFOed UARTs where >several have their INT output ORed on a multiport interrupt sharing >card. Perhaps with non-FIFOed UARTS. I see a large potential. Consider one UART on sio1. It will take at least 2 usec for the interrupt handler to be entered and clear the interrupt (it will usually take longer; the worst case for a 16550 is about 70 usec). For input at 115200 bps, it will interrupt about 822 times per second, so the UART will drive the IRQ high for at least 0.1644% of the time. Consider another UART on sio0 and suppose it is handling satuated input at 115200 bps and that the interrupts are asynchronous with the interrupts from the first device. It will interrupt at about 822 times per second and there will be a problem 0.1644% of the time. The chance of a problem after 1 second (if we start scanning for interrupts on sio0 and don't go back to sio0 after finding an interrupt on sio1) is 1 - (1 - 1644/10**6)**822 = 74 in 100. For non-FIFO UARTS there will be 14 times more interrupts per second and a chance of a problem of almost 100 in 100. In practice the interrupts will not be completely asynchronous. For two channels of saturated input, the interrupt frequencies will be determined mostly by the clock frequencies on the transmitters, and problems will occur when the two clocks are almost in phase. >One of my objectives is implementing input burst mode for 550 (or >better) UARTs. A second driver called sio550.c could shed the legacy >8250/16450 baggage. That's not only reasonable, it's even wise given >the prevalence of 550s and higher in the market today. They're not different enough to justify a completely different driver. >And as far as the edge latch goes, the handler apparently *can* safely >return with the edge latch set if there was a down/up transition on >the IRQ line before EOI. Although that seems unlikely because of the I think the EOI timing doesn't make any difference when CPU interrupts are kept disabled throughout interrupt handling, as they are for "fast" interrupt handlers like siointr(). Fast interrupt handlers delay explicitly sending and EOI until after the interrupt is handled. This is for bogus historical reasons. Auto EOI is normally used for the first ICU, so sending an EOI early gets tested too. "Slow" interrupt handlers must send the EOI early for FreeBSD's interrupt mechanism to work at all. >relatively large time needed to refill any UART to its FIFO trigger >level after draining it once, perhaps theoretically it could happen on >a multiport card where you've acked your interrupt, drained all the >UARTs (only once, not looping for a second pass), and then receive a >new interrupt from one of the UARTs you've already drained. I gather >that is the case you are concerned about. Not really. As you pointed out, it isn't a problem for input except in the overloaded case. It is a problem if input is mixed with output or there is another active UART. Mixed i/o is similar to i/i on mixed devices - there's just a divisor of 16 instead of 14 in the calculations. >But in the non-pathological case of a machine which is able to do >other useful work, by clearing the INT output of the last UART before >any of the previously drained UARTs can raise their INT output again, >you will have at least one down/up transition on the IRQ line. If you That would be a pessimization. It requires _two_ extra outputs per port (one to mess up the INT enable and one to restore it). The best case for the current loop is one extra input per port, and this can be arranged to be the usual case with some small changes). Changing the INT enable also amplifies bugs in 8250s :-). >agree with following writer's conclusion, the handler *can* safely >issue EOI and return after making only one pass to drain the UARTs. > >Attributed to Chris Hall (chris@locomotive.com) I don't think he concluded much about EOI. >... >3. The Mechanisms > >The PC sets the 8259A into: ^^ BIOS > > * Edge Triggered Interrupts > * Cascaded (on AT and later) ; Single (on earlier machines) > * Not Special Fully Nested (to do with Slave 8259A, see below) > * Not Buffered Normal EOI (Not Automatic EOI on INTA) FreeBSD sets Auto EOI for the first ICU by default, and Auto EOI for the second ICU is good for serial devices if it works. >3.1 One 8259A, All IRQ Unmasked, No Interrupts In Service > and None Active. >... > 7 Setting B3 of the ISR clears B3 of the ESR. > 8 The CPU issues the second of two INTA cycles. The > 8259A issues the interrupt vector associated with the > highest priority ISR (B3). The contents of the IRR > are unfrozen. According to the diagram in the Intel data sheet, and my experiments, the IRR follows a signal from the edge latch until the edge latch is cleared - it reads as 0. > 9 The INT latch is cleared -- so the INT output is set > inactive. According to the diagram in the Intel data sheet, and my experiments, the edge latch isn't cleared until the external interrupt goes away. > 10 B3 of the IRR is set to 0 (IRR is unfrozen and B3 of > ESR is zero). > 11 At some time in the future, the CPU issues an EOI > command, which clears B3 of the ISR. EOI mainly affects the priority logic. >... >3.2 Meaning of "Edge Triggered Interrupt Mode" > >The behavior of the ESR, IRR and ISR described above is what >happens in the famous Edge Triggered Interrupt Mode. ^^infamous :-) Bruce From owner-freebsd-hackers Fri Nov 28 10:20:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA28917 for hackers-outgoing; Fri, 28 Nov 1997 10:20:36 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA28912 for ; Fri, 28 Nov 1997 10:20:32 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id KAA05358; Fri, 28 Nov 1997 10:13:21 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd005356; Fri Nov 28 10:13:10 1997 Date: Fri, 28 Nov 1997 10:10:56 -0800 (PST) From: Julian Elischer To: Terry Lambert cc: dk+@ua.net, proff@iq.org, freebsd-hackers@freebsd.org Subject: Re: detecting devfs from userland? In-Reply-To: <199711272308.QAA14601@usr07.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 27 Nov 1997, Terry Lambert wrote: > > I think that having devfs creating its own device would be nice thing > > for this purpose... i.e., just stat "/dev/devfs" to check if devfs > > is running. As an added bonus, devfs operations can be added by > > reading, writing, or ioctl'ing this device. > > > > this can work if you need to check whether devfs is running _now_, > > as opposed to knowing whether it is compiled into the kernel. > > You can do the same thing by doing a stat of /dev and looking > for an st_ino of 2. actually no, as the root ino in devfs is not 2, and the ino for .. IS 2 regardless of what FS it is.. lsvfs shows the devfs, if it is compiled, and 'mount|grep devfs' will show you if it's presently active on /dev. I'm not sure that much more is needed. > > The devices themselves, especially in the new SLICE stuff that > he's done, should be self-referrential. I'm still trying to > talk him into putting them in a hierarchy (with little success... > you SVR4 device name traditionalists can rest easy: you still get > you have your long cryptic device names for now...). A hierarchy is good but has the following problems 1/ violates "Principle of least surprise" (POLS) 2/ if you have /dev/disk/sd0/slice1/partA, then how do you access /dev/disk/sd0? because htat is a directory. you need to either: (A) make devfs allow devices to respond to directory operations.. and therefore confuse everybody.. "hey if /dev/disk/sd0 is a device, how can /dev/disk/sd0/slice1 exist?" OR (B) define the hierachy as: /dev/disk /dev/disk/sd0 /dev/disk/sd0/all /dev/disk/sd0/slice1 /dev/disk/sd0/slice1/all <--device /dev/disk/sd0/slice1/part1 <--directory /dev/disk/sd0/slice1/part1/all <--device "all" might be 'device', but you get the picture it's messy and confusing, (though not AS confusing as option (B)). If objection 1 violates POLS, then solution (A) REALLY violates it, though if we were designing a new OS that's what I would do. (it's easy to do) julian > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > From owner-freebsd-hackers Fri Nov 28 11:00:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA01273 for hackers-outgoing; Fri, 28 Nov 1997 11:00:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA01212 for ; Fri, 28 Nov 1997 11:00:01 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.8/8.8.5) with SMTP id KAA00243 for ; Fri, 28 Nov 1997 10:59:45 -0800 (PST) Date: Fri, 28 Nov 1997 10:59:45 -0800 (PST) From: "Jamil J. Weatherbee" To: hackers@freebsd.org Subject: Drive Mirroring Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have two exact duplicate drives and I want the second (sd1) to be an exact duplicate of the first. Unfortunately ccd doesn't work here because the drives aren't bootable, you cannot install on ccd drives from the cds etc. One way to accomplish this is to go to single-user, sync, and then dd if=/dev/sd0 of=/dev/sd1 bs=1024k. Unfortunately using this method on a running system probably will corrupt the hell out of the copied over filesystem. I've also tried using dump, but for these 4.3 giggers it takes about 2 hours every night to remake filesystems on the second drive and dump | restore to it. Can anyone think of a way I could maintain an entire mirrored system without ccd, perhaps some software that nightly looks at the changes on one drive and puts them over to the second without basically rewriting the whole thing. From owner-freebsd-hackers Fri Nov 28 11:01:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA01356 for hackers-outgoing; Fri, 28 Nov 1997 11:01:16 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA01347 for ; Fri, 28 Nov 1997 11:01:08 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA07471 (5.67b/IDA-1.5 for hackers@FreeBSD.ORG); Fri, 28 Nov 1997 20:00:58 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id TAA01619; Fri, 28 Nov 1997 19:12:25 +0100 (MET) From: Wilko Bulte Message-Id: <199711281812.TAA01619@yedi.iaf.nl> Subject: Re: DEVFS/SLICE passes milestone To: tlambert@primenet.com (Terry Lambert) Date: Fri, 28 Nov 1997 19:12:25 +0100 (MET) Cc: tlambert@primenet.com, sos@freebsd.dk, julian@whistle.com, hackers@FreeBSD.ORG In-Reply-To: <199711272257.PAA13589@usr07.primenet.com> from "Terry Lambert" at Nov 27, 97 10:57:32 pm X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote... > > > > > I know :), I just wanted to get this straight, we don't want a new > > > > "inherrently broken by design" subsystem again. > > > > > > Inre this comment and the previous comment about my large patches > > > to the filesystem: my union mounts work, do yours? > > > > Oh OH! Are you people preparing to start a major flamefest again? > > No. I was simply addressing the backhanded putdown of code that Great. I was a bit worried ;-) _ ______________________________________________________________________ | / o / / _ Bulte email: wilko @ yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ---------------- Support your local daemons: run [Free,Net]BSD Unix ------ From owner-freebsd-hackers Fri Nov 28 11:46:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA04064 for hackers-outgoing; Fri, 28 Nov 1997 11:46:11 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA04057 for ; Fri, 28 Nov 1997 11:46:01 -0800 (PST) (envelope-from arg@arg1.demon.co.uk) Received: (from arg@localhost) by arg1.demon.co.uk (8.8.5/8.8.5) id TAA02398; Fri, 28 Nov 1997 19:47:41 GMT Date: Fri, 28 Nov 1997 19:47:40 +0000 (GMT) From: Andrew Gordon X-Sender: arg@server.arg.sj.co.uk To: Sren Schmidt cc: FreeBSD hackers Subject: Re: LM78 what port # ?? In-Reply-To: <199711280742.IAA11480@sos.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 28 Nov 1997, Sren Schmidt wrote: > > Simple question: > > What port # are the LM78 system monitor chips located at in varios > PC's, there might even be a concensus on it :) The Intel PR440 (Dual PPro) motherboard claims to have "Hardware monitor ASIC" at 0x0290-0x0297. Unfortunately, the datasheet doesn't tell you any more about this hardware - it suggests that you access it via the DMI BIOS. From owner-freebsd-hackers Fri Nov 28 12:12:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA05651 for hackers-outgoing; Fri, 28 Nov 1997 12:12:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA05646 for ; Fri, 28 Nov 1997 12:12:27 -0800 (PST) (envelope-from jak@cetlink.net) Received: from hot1.auctionfever.com (ts1-cltnc-45.cetlink.net [209.54.58.45]) by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id PAA29222; Fri, 28 Nov 1997 15:12:12 -0500 (EST) From: jak@cetlink.net (John Kelly) To: Bruce Evans Cc: hackers@freebsd.org Subject: Re: 650 UART, SIO driver, 8259 PIC Date: Fri, 28 Nov 1997 21:13:17 GMT Message-ID: <347f2aea.22335910@mail.cetlink.net> References: <199711281810.FAA09194@godzilla.zeta.org.au> In-Reply-To: <199711281810.FAA09194@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id MAA05647 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 29 Nov 1997 05:10:56 +1100, Bruce Evans wrote: >According to the diagram in the Intel data sheet, and my experiments, >the IRR follows a signal from the edge latch until the edge latch is >cleared - it reads as 0. > >> 9 The INT latch is cleared -- so the INT output is set >> inactive. > >According to the diagram in the Intel data sheet, and my experiments, >the edge latch isn't cleared until the external interrupt goes away. > >> 10 B3 of the IRR is set to 0 (IRR is unfrozen and B3 of >> ESR is zero). I don't know what experiment you performed, but using a volt meter and some ISR test code with dummy loops long enough to watch the voltage change, I've proven that a down/up transition on the external IRQ line before EOI will produce a new interrupt when exiting the ISR, assuming the external IRQ line is still high upon exit (which it would be). >>other useful work, by clearing the INT output of the last UART before >>any of the previously drained UARTs can raise their INT output again, >>you will have at least one down/up transition on the IRQ line. If you > >That would be a pessimization. It requires _two_ extra outputs per >port (one to mess up the INT enable and one to restore it). That's not what I meant. :-( I'm not going to poke the UART twice to toggle interrupt enable. The act of draining the FIFO will cause each UART to pull its INT output (pin 30 on a 40-pin DIP) to ground. In the case of an 8-port shared interrupt card, at the instant the last UART is drained below its FIFO trigger level, all eight INT output pins will be at ground. If one of the eight is subsequently refilled to receive trigger level it will raise its INT output high again, but that's OK because since all eight were at ground, you have a low to high transition and a new interrupt after exiting the ISR. So far, I have been discussing only the problems associated with receive data, completely ignoring the complications of transmitter interrupts. But I've been trying to accurately establish the facts of the simple case first. John From owner-freebsd-hackers Fri Nov 28 12:14:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA05766 for hackers-outgoing; Fri, 28 Nov 1997 12:14:30 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from silvia.HIP.Berkeley.EDU (ala-ca34-55.ix.netcom.com [207.93.143.183]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA05755 for ; Fri, 28 Nov 1997 12:14:23 -0800 (PST) (envelope-from asami@vader.cs.berkeley.edu) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.8/8.6.9) id MAA21785; Fri, 28 Nov 1997 12:14:14 -0800 (PST) Date: Fri, 28 Nov 1997 12:14:14 -0800 (PST) Message-Id: <199711282014.MAA21785@silvia.HIP.Berkeley.EDU> To: jamil@trojanhorse.ml.org CC: hackers@freebsd.org In-reply-to: (jamil@trojanhorse.ml.org) Subject: Re: Drive Mirroring From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * and dump | restore to it. Can anyone think of a way I could maintain an * entire mirrored system without ccd, perhaps some software that nightly * looks at the changes on one drive and puts them over to the second without * basically rewriting the whole thing. Partition the drives as root / the rest, ccd the two "rest" partitions and partition them as you wish (/var, /usr, /usr/local, etc.). Write a script that does the following every night: newfs /dev/rsd1a mount -o async /dev/sd1a /mnt cd / find -dx . | cpio -dump /mnt umount /mnt Granted, this will leave a small window of vulnerability during the script is running, but if the root partition is small enough, it should be real quick. Satoshi From owner-freebsd-hackers Fri Nov 28 12:14:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA05767 for hackers-outgoing; Fri, 28 Nov 1997 12:14:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from super.zippo.com (perry.zippo.com [207.211.168.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA05758 for ; Fri, 28 Nov 1997 12:14:25 -0800 (PST) (envelope-from reyesf@super.zippo.com) Received: (from reyesf@localhost) by super.zippo.com (8.8.6/8.8.7) id MAA05355; Fri, 28 Nov 1997 12:14:22 -0800 (PST) Message-Id: <199711282014.MAA05355@super.zippo.com> From: "Francisco Reyes" To: "David Kott" Cc: "hackers@freebsd.org" Date: Fri, 28 Nov 97 15:13:56 -0400 Reply-To: "Francisco Reyes" Priority: Normal X-Mailer: PMMail 1.95a For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: Why bootup message doesn't stay longer? (2.2.5) Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 28 Nov 1997 04:05:15 -0500 (EST), David Kott wrote: >> The reasons behind this is that new users would be the ones reading >> that first page. The current amount of time is too little for a new >> comer to look at the info displayed. >> > >You have only to type a single character at the prompt (your keypress) to >read this message. I have 2.2.5 at work so can't check the "single character" right now, but the point I was trying to raise is that for "newcomers" this message doesn't stay long enough. >also, I think you can change that under >/usr/src/sys/i386/boot/biosboot/Makefile >with the >BOOTWAIT?= 5000 I knew for sure that there would be a place to change it, but I never read it anyway so "I" don't need to increase. I just think that if we make it longer there would be a benefit to new users. By default there are options that are power user friendly (in this case the message doesn't stay long), but ill suited for new comers. I think it should be the other way around. If a setting can be changed and saved to a configuration file and the setting has a "friendly" mode then the default should be the friendly mode (ie the screen stays longer). From owner-freebsd-hackers Fri Nov 28 12:55:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA08230 for hackers-outgoing; Fri, 28 Nov 1997 12:55:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dihelix.com (caliban.dihelix.com [198.180.136.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA08222 for ; Fri, 28 Nov 1997 12:55:26 -0800 (PST) (envelope-from langfod@dihelix.com) Received: (from langfod@localhost) by dihelix.com (8.8.7/8.8.8) id KAA25809; Fri, 28 Nov 1997 10:54:19 -1000 (HST) (envelope-from langfod) Message-Id: <199711282054.KAA25809@dihelix.com> Subject: Re: Drive Mirroring In-Reply-To: <199711282014.MAA21785@silvia.HIP.Berkeley.EDU> from Satoshi Asami at "Nov 28, 97 12:14:14 pm" To: asami@cs.berkeley.edu (Satoshi Asami) Date: Fri, 28 Nov 1997 10:54:18 -1000 (HST) Cc: jamil@trojanhorse.ml.org, hackers@FreeBSD.ORG From: "David Langford" X-blank-line: This space intentionaly left blank. X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > * and dump | restore to it. Can anyone think of a way I could maintain an > * entire mirrored system without ccd, perhaps some software that nightly > * looks at the changes on one drive and puts them over to the second without > * basically rewriting the whole thing. > >Partition the drives as root / the rest, ccd the two "rest" partitions >and partition them as you wish (/var, /usr, /usr/local, etc.). Write >a script that does the following every night: > >newfs /dev/rsd1a >mount -o async /dev/sd1a /mnt >cd / >find -dx . | cpio -dump /mnt >umount /mnt > >Granted, this will leave a small window of vulnerability during the >script is running, but if the root partition is small enough, it >should be real quick. > >Satoshi Any thought on what is required to make a "snapshot" feature in FreeBSD? -David Langford langfod@dihelix.com From owner-freebsd-hackers Fri Nov 28 15:21:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA16566 for hackers-outgoing; Fri, 28 Nov 1997 15:21:49 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from inertia.dfacades.com (inertia.dfacades.com [207.155.93.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA16560 for ; Fri, 28 Nov 1997 15:21:44 -0800 (PST) (envelope-from dleeds@dfacades.com) Received: (from dleeds@localhost) by inertia.dfacades.com (8.8.7/8.8.7) id PAA18196 for hackers@freebsd.org; Fri, 28 Nov 1997 15:25:04 -0800 (PST) From: Daniel Leeds Message-Id: <199711282325.PAA18196@inertia.dfacades.com> Subject: land patch? To: hackers@freebsd.org Date: Fri, 28 Nov 1997 15:25:03 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL35 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk is there a patch for freebsd 2.2.5 to defeat the land attack? is it just one file in the kernel source tree that needs to be rebuilt with the newest code? thanks From owner-freebsd-hackers Fri Nov 28 16:34:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA20428 for hackers-outgoing; Fri, 28 Nov 1997 16:34:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA20423 for ; Fri, 28 Nov 1997 16:34:39 -0800 (PST) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.8/8.8.7) with ESMTP id QAA24655; Fri, 28 Nov 1997 16:34:35 -0800 (PST) (envelope-from jdp) Message-Id: <199711290034.QAA24655@austin.polstra.com> To: boia01@gel.usherb.ca Subject: Re: Shared Libraries and debugging In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Date: Fri, 28 Nov 1997 16:34:35 -0800 From: John Polstra Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article , Alex Boisvert wrote: > > But he was asking about core dumps. And he's right, it doesn't work. > > I've been looking into it, and I have a fix to the dynamic linker that > > seems to make it work fine. I'll commit it after I do a make world > > and a little bit more testing. > > > > Can this be "added" to -stable sometimes? Yes, I will merge the change into -stable after it's been well tested in -current. Be patient, though. This is not the kind of change that should be hurried into -stable. The dynamic linker is a critical component of the system, secondary only to the kernel. If it doesn't work properly, almost everything falls apart. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Fri Nov 28 17:37:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA23676 for hackers-outgoing; Fri, 28 Nov 1997 17:37:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA23666 for ; Fri, 28 Nov 1997 17:37:11 -0800 (PST) (envelope-from dawes@rf900.physics.usyd.edu.au) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.8.5/8.8.2) id MAA26990; Sat, 29 Nov 1997 12:36:19 +1100 (EST) Message-ID: <19971129123619.61979@rf900.physics.usyd.edu.au> Date: Sat, 29 Nov 1997 12:36:19 +1100 From: David Dawes To: hackers@FreeBSD.ORG Subject: Re: Shared Libraries and debugging References: <199711272255.OAA18209@austin.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: ; from Charles Mott on Thu, Nov 27, 1997 at 04:40:35PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Nov 27, 1997 at 04:40:35PM -0700, Charles Mott wrote: >On Thu, 27 Nov 1997, John Polstra wrote: >> Judging by the cause of the problem, I doubt that it ever worked. In >> order to examine shared libraries, gdb needs to look at the dynamic >> linker's table which records where they were loaded into memory. The >> dynamic linker has always recorded this information in a MAP_ANON >> region way up high in the address space. But such regions are not >> written to the core file when a core dump occurs. So gdb has not been >> able to get the information it needs. > >So memory allocated with mmap() is not dumped in a core file? Is this not >possible or just not desirable? Linux seems to (but then it uses ELF). I've seen an unfortunate side-effect of this on Linux when reading the mmapped MMIO area from a Millennium while dumping an Xserver core file. The result was a machine lockup because reads from a part of the MMIO area can initiate a graphics command. We worked around this by unmapping when receiving a trapped signal, but that doesn't help when signal trapping is turned off. David From owner-freebsd-hackers Fri Nov 28 17:56:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA24726 for hackers-outgoing; Fri, 28 Nov 1997 17:56:14 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from silvia.HIP.Berkeley.EDU (ala-ca34-55.ix.netcom.com [207.93.143.183]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA24719 for ; Fri, 28 Nov 1997 17:56:07 -0800 (PST) (envelope-from asami@vader.cs.berkeley.edu) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.8/8.6.9) id RAA22650; Fri, 28 Nov 1997 17:55:42 -0800 (PST) Date: Fri, 28 Nov 1997 17:55:42 -0800 (PST) Message-Id: <199711290155.RAA22650@silvia.HIP.Berkeley.EDU> To: narvi@Haldjas.folklore.ee CC: joerg_wunsch@uriah.heep.sax.de, hackers@freebsd.org, mcgovern@spoon.beta.com In-reply-to: (message from Narvi on Fri, 28 Nov 1997 14:59:49 +0200 (EET)) Subject: Re: Union and Portal FSs From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * On Thu, 27 Nov 1997, J Wunsch wrote: I'm following up on someone else's post regarding yet another person because I don't know if Mr. Kato is on -hackers. * > Kazu did quite some work on unionfs, and i think it's basically usable ^^^^ That's Mr. Kato. ("Kazu" is the syscons person.) Satoshi From owner-freebsd-hackers Fri Nov 28 18:01:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA24978 for hackers-outgoing; Fri, 28 Nov 1997 18:01:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA24972 for ; Fri, 28 Nov 1997 18:01:14 -0800 (PST) (envelope-from jak@cetlink.net) Received: from hot1.auctionfever.com (ts1-cltnc-46.cetlink.net [209.54.58.46]) by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id VAA20573; Fri, 28 Nov 1997 21:00:51 -0500 (EST) From: jak@cetlink.net (John Kelly) To: Bruce Evans Cc: hackers@freebsd.org Subject: Re: 650 UART, SIO driver, 8259 PIC Date: Sat, 29 Nov 1997 03:01:56 GMT Message-ID: <3480750d.41296569@mail.cetlink.net> References: <199711281810.FAA09194@godzilla.zeta.org.au> In-Reply-To: <199711281810.FAA09194@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id SAA24973 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 29 Nov 1997 05:10:56 +1100, Bruce Evans wrote: >I see a large potential. Consider one UART on sio1. It will take >at least 2 usec for the interrupt handler to be entered and clear the >interrupt (it will usually take longer; the worst case for a 16550 is >about 70 usec). For input at 115200 bps, it will interrupt about 822 >times per second, so the UART will drive the IRQ high for at least 0.1644% >of the time. Consider another UART on sio0 and suppose it is handling >satuated input at 115200 bps and that the interrupts are asynchronous >with the interrupts from the first device. It will interrupt at about >822 times per second and there will be a problem 0.1644% of the time. The >chance of a problem after 1 second (if we start scanning for interrupts on >sio0 and don't go back to sio0 after finding an interrupt on sio1) is 1 - >(1 - 1644/10**6)**822 = 74 in 100. That's no guarantee of avoiding a missed interrupt either. After checking sio0 a second time and finding no interrupts, it will take a few clock cycles to reach to reach the instruction which sends EOI and then exit the ISR. How can you be sure that sio1 does not reinterrupt before you exit cleanly? You can't. The reason it works is because you do get a new interrupt after exiting the ISR. It becomes clear if you trace the steps backwards: Prior to checking sio0 for a second time, you had drained sio1, clearing its interrupt. Prior to that you had drained sio0, clearing its interrupt. Now you've come around full circle and checked sio0 again. You know that the state of sio0 has not changed since the last time you looked at it - sio0 has pulled its INT output to ground for the entire time it took to make that full circle. You also know that during all that time where sio0 held its INT output to ground, you drained sio1, causing its INT output to be pulled to ground. That means that all the (two) UARTs on your multiport board have simultaneously pulled their output to ground for at least some brief time -- the proof is clear. So if a new interrupt occurs before you can exit the ISR, you will have a low/high transition on the IRQ line, ESR will record the new edge, and when you exit the ISR you will get a new interrupt. But it breaks down with more than two UARTs. In the case of sio0, sio1, and sio2, when you go back to recheck sio0 and find no interrupt, you don't know whether sio1 may have resignaled a new interrupt before sio2 could be drained. If it did, your external IRQ line would have been held high for the entire time, and ESR would not sense any edge. So now you have to recheck sio1 also. But then what about sio0? It could also reinterrupt, your IRQ line never goes ground, ESR cannot sense any edge, and you lose an interrupt. And so on and so on ... with more than two UARTs, you can never stop looping or you might miss an interrupt! For more than two UARTs, the only assurance of avoiding all lost receiver interrupts is that once you start draining the first UART, you *must* always reach the last UART and start draining it before any of the others can resignal a new receiver interrupt. And that will depend on the maximum bit rate, the FIFO trigger level of the UARTs, and how tight the code can be made. Complicating the equation with transmitter interrupts is premature until resolving the receiver issues. John From owner-freebsd-hackers Fri Nov 28 18:33:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA26495 for hackers-outgoing; Fri, 28 Nov 1997 18:33:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA26489 for ; Fri, 28 Nov 1997 18:33:22 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.8/8.8.5) with SMTP id SAA00891; Fri, 28 Nov 1997 18:33:05 -0800 (PST) Date: Fri, 28 Nov 1997 18:33:05 -0800 (PST) From: "Jamil J. Weatherbee" To: Satoshi Asami cc: hackers@freebsd.org Subject: Re: Drive Mirroring In-Reply-To: <199711282014.MAA21785@silvia.HIP.Berkeley.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk One problem with this: If the system is rebooted with only one drive it crashes, second you cannot do a out of the box install on ccded drives so they are pretty useless tom me for anything but data. I actually tried the exact scenario you suggest. On Fri, 28 Nov 1997, Satoshi Asami wrote: > * and dump | restore to it. Can anyone think of a way I could maintain an > * entire mirrored system without ccd, perhaps some software that nightly > * looks at the changes on one drive and puts them over to the second without > * basically rewriting the whole thing. > > Partition the drives as root / the rest, ccd the two "rest" partitions > and partition them as you wish (/var, /usr, /usr/local, etc.). Write > a script that does the following every night: > > newfs /dev/rsd1a > mount -o async /dev/sd1a /mnt > cd / > find -dx . | cpio -dump /mnt > umount /mnt > > Granted, this will leave a small window of vulnerability during the > script is running, but if the root partition is small enough, it > should be real quick. > > Satoshi > From owner-freebsd-hackers Fri Nov 28 18:56:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA27401 for hackers-outgoing; Fri, 28 Nov 1997 18:56:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from silvia.HIP.Berkeley.EDU (ala-ca34-55.ix.netcom.com [207.93.143.183]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA27395 for ; Fri, 28 Nov 1997 18:56:22 -0800 (PST) (envelope-from asami@vader.cs.berkeley.edu) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.8/8.6.9) id SAA22913; Fri, 28 Nov 1997 18:56:15 -0800 (PST) Date: Fri, 28 Nov 1997 18:56:15 -0800 (PST) Message-Id: <199711290256.SAA22913@silvia.HIP.Berkeley.EDU> To: jamil@trojanhorse.ml.org CC: hackers@freebsd.org In-reply-to: (jamil@trojanhorse.ml.org) Subject: Re: Drive Mirroring From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * One problem with this: If the system is rebooted with only one drive it * crashes, second you cannot do a out of the box install on ccded drives so * they are pretty useless tom me for anything but data. I can't help you about the second one, but you can make it boot (manually) by editing /etc/ccd.conf (remove the mirror flag and the dead partition). Satoshi From owner-freebsd-hackers Fri Nov 28 19:40:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA29638 for hackers-outgoing; Fri, 28 Nov 1997 19:40:04 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA29617 for ; Fri, 28 Nov 1997 19:40:01 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.8/8.8.5) with SMTP id TAA03958; Fri, 28 Nov 1997 19:32:31 -0800 (PST) Date: Fri, 28 Nov 1997 19:31:11 -0800 (PST) From: "Jamil J. Weatherbee" To: Satoshi Asami cc: hackers@freebsd.org Subject: Re: Drive Mirroring In-Reply-To: <199711290256.SAA22913@silvia.HIP.Berkeley.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Would a software RAID implementation be able to cope with having a drive removed? When the drive is reconnected it should simply take care of bringing it up to date or completely remaking it from the current master. There is no reason that this should not be a standard feature, as SCSI disks die all the time. I want to have a solution where the probability of total failure is reduced exponentially. Namely you can pull off and insert drives as needed without having to think about it, a total no-brainer for the kind of people who might be using these systems. Now I looked at some adaptec SCSI adapters that are supposed to do this in hardware, but I didn't really feel like buying a $900 scsi adapter to see if it properly functions with freebsd. Checksums should be kept on CCD blocks to insure that the contents of a corrupted drive are not being mirrored over. I keep dat tapes like everyone else, but have you ever tried restoring a completely wiped system off of a dat tape? Especially when the drive is remote over an ethernet? You end up having to install enough of a system so that you can do the recovery. I want to stack 3 triple redundant SCSI drives and be able to smash two of them with a sledge hammer without a system glitch (I'll watch out for pass through cables). On Fri, 28 Nov 1997, Satoshi Asami wrote: > * One problem with this: If the system is rebooted with only one drive it > * crashes, second you cannot do a out of the box install on ccded drives so > * they are pretty useless tom me for anything but data. > > I can't help you about the second one, but you can make it boot > (manually) by editing /etc/ccd.conf (remove the mirror flag and the > dead partition). > > Satoshi > From owner-freebsd-hackers Fri Nov 28 20:04:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA01016 for hackers-outgoing; Fri, 28 Nov 1997 20:04:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from daemon.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA01007 for ; Fri, 28 Nov 1997 20:04:34 -0800 (PST) (envelope-from grog@lemis.com) Received: (from grog@localhost) by daemon.lemis.com (8.8.8/8.8.7) id OAA15282; Sat, 29 Nov 1997 14:33:16 +1030 (CST) (envelope-from grog) Message-ID: <19971129143315.51603@lemis.com> Date: Sat, 29 Nov 1997 14:33:15 +1030 From: Greg Lehey To: "Jamil J. Weatherbee" Cc: Satoshi Asami , hackers@FreeBSD.ORG Subject: Re: Drive Mirroring References: <199711290256.SAA22913@silvia.HIP.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Jamil J. Weatherbee on Fri, Nov 28, 1997 at 07:31:11PM -0800 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Nov 28, 1997 at 07:31:11PM -0800, Jamil J. Weatherbee wrote: > > Would a software RAID implementation be able to cope with having a drive > removed? When the drive is reconnected it should simply take care of > bringing it up to date or completely remaking it from the current > master. Briefly, yes. I'm working on this implementation. If you're interested, I can give some details as soon as I get this book off my back. Greg From owner-freebsd-hackers Fri Nov 28 20:17:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA01580 for hackers-outgoing; Fri, 28 Nov 1997 20:17:59 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mother.sneaker.net.au (akm@mother.sneaker.net.au [203.30.3.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA01450 for ; Fri, 28 Nov 1997 20:14:57 -0800 (PST) (envelope-from akm@mother.sneaker.net.au) Received: (from akm@localhost) by mother.sneaker.net.au (8.8.5/8.8.5) id PAA23032; Sat, 29 Nov 1997 15:22:12 +1100 (EST) From: Andrew Kenneth Milton Message-Id: <199711290422.PAA23032@mother.sneaker.net.au> Subject: Re: Drive Mirroring To: jamil@trojanhorse.ml.org (Jamil J. Weatherbee) Date: Sat, 29 Nov 1997 15:22:12 +1100 (EST) Cc: asami@cs.berkeley.edu, hackers@FreeBSD.ORG In-Reply-To: from "Jamil J. Weatherbee" at Nov 28, 97 07:31:11 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk +-----[ Jamil J. Weatherbee ]------------------------------ | | | Would a software RAID implementation be able to cope with having a drive | removed? The last implementation I saw of software RAID on Solaris didn't (about two years ago). It wouldn't boot from the secondary drives, it wouldn't run if one of the disks were missing, it wouldn't gracefully continue if the second drive died. It would mirror to the second drive, but, that's about it. It wouldn't re-synch the disks correctly either when you finally got around to replacing one of them. (The primary disk always had to be the current one, so if it died, you had to swap the ID on that, and add in a new one as the secondary). I haven't seen if it got any better since then, and I haven't had any experiences with any other RAID packages, so I don't know what else is out there. -- ,-_|\ SneakerNet | Andrew Milton | GSM: +61(41)6 022 411 / \ P.O. Box 154 | akm@sneaker.net.au | Fax: +61(2) 9746 8233 \_,-._/ N Strathfield +--+----------------------+---+ Ph: +61(2) 9746 8233 v NSW 2137 | Low cost Internet Solutions | From owner-freebsd-hackers Fri Nov 28 20:41:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA02516 for hackers-outgoing; Fri, 28 Nov 1997 20:41:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from daemon.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA02507 for ; Fri, 28 Nov 1997 20:41:19 -0800 (PST) (envelope-from grog@lemis.com) Received: (from grog@localhost) by daemon.lemis.com (8.8.8/8.8.7) id PAA23000; Sat, 29 Nov 1997 15:10:57 +1030 (CST) (envelope-from grog) Message-ID: <19971129151057.57891@lemis.com> Date: Sat, 29 Nov 1997 15:10:57 +1030 From: Greg Lehey To: Andrew Kenneth Milton Cc: "Jamil J. Weatherbee" , asami@cs.berkeley.edu, hackers@FreeBSD.ORG Subject: Re: Drive Mirroring References: <199711290422.PAA23032@mother.sneaker.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <199711290422.PAA23032@mother.sneaker.net.au>; from Andrew Kenneth Milton on Sat, Nov 29, 1997 at 03:22:12PM +1100 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, Nov 29, 1997 at 03:22:12PM +1100, Andrew Kenneth Milton wrote: >> -----[ Jamil J. Weatherbee ]------------------------------ >> >> >> Would a software RAID implementation be able to cope with having a drive >> removed? > > The last implementation I saw of software RAID on Solaris didn't > (about two years ago). > > It wouldn't boot from the secondary drives, Booting is a different matter. It's a lot more complicated, since you need to explain RAID to the bootstrap. I don't think that's feasible. But once the system is up and running, all other file systems should be able to be RAID. Greg From owner-freebsd-hackers Fri Nov 28 21:51:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA06501 for hackers-outgoing; Fri, 28 Nov 1997 21:51:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dfw-ix3.ix.netcom.com (dfw-ix3.ix.netcom.com [206.214.98.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA06496 for ; Fri, 28 Nov 1997 21:51:28 -0800 (PST) (envelope-from jerry_hicks@bigfoot.com) Received: (from smap@localhost) by dfw-ix3.ix.netcom.com (8.8.4/8.8.4) id XAA17571 for ; Fri, 28 Nov 1997 23:50:50 -0600 (CST) Received: from atl-ga15-03.ix.netcom.com(204.32.174.99) by dfw-ix3.ix.netcom.com via smap (V1.3) id rma017558; Fri Nov 28 23:50:44 1997 Message-ID: <347FAD4B.D1E682A@bigfoot.com> Date: Sat, 29 Nov 1997 00:51:07 -0500 From: Jerry Hicks Reply-To: jerry_hicks@bigfoot.com Organization: TerraEarth X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Re: Drive Mirroring References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jamil J. Weatherbee wrote: > > I have two exact duplicate drives and I want the second (sd1) to be an > exact duplicate of the first. Unfortunately ccd doesn't work here because > the drives aren't bootable, you cannot install on ccd drives from the cds > etc. One way to accomplish this is to go to single-user, sync, and then > dd if=/dev/sd0 of=/dev/sd1 bs=1024k. Unfortunately using this method on a > running system probably will corrupt the hell out of the copied over > filesystem. I've also tried using dump, but for these 4.3 giggers it > takes about 2 hours every night to remake filesystems on the second drive > and dump | restore to it. Can anyone think of a way I could maintain an > entire mirrored system without ccd, perhaps some software that nightly > looks at the changes on one drive and puts them over to the second without > basically rewriting the whole thing. Using QNX, we developed a cellular switch which boots from a flash 'disk'. A ram disk is created and the root filesystem is created there. The contents of the root filesystem are extracted from a gzipped archive on the flash before entering userland. An unused byte of the memory in the CMOS clock chip is used to save a persistent status code indicating whether to boot in operational, faulted, or service modes. You can get flash for a PC in several forms, including PCMCIA adapters for widely available flash cards. We used ZiaTech hardware which features user-writable flash integrated on the CPU board. IMO, this sort of configuration would be pretty neat to have for a FreeBSD net server. It alleviates a lot of the concerns one might deploying a high-availability system. Software upgrades are a snap too. We do ours remotely (worldwide from Memphis, TN). I don't specifically know how to work out the FreeBSD swapping related issues. Don't think it would be much though (?) Off to www.dejanews.com... Good Luck, Jerry Hicks jerry_hicks@bigfoot.com From owner-freebsd-hackers Fri Nov 28 21:59:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA06846 for hackers-outgoing; Fri, 28 Nov 1997 21:59:17 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA06832 for ; Fri, 28 Nov 1997 21:59:10 -0800 (PST) (envelope-from dawes@rf900.physics.usyd.edu.au) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.8.5/8.8.2) id QAA28433; Sat, 29 Nov 1997 16:59:05 +1100 (EST) Message-ID: <19971129165905.08819@rf900.physics.usyd.edu.au> Date: Sat, 29 Nov 1997 16:59:05 +1100 From: David Dawes To: hackers@FreeBSD.ORG Subject: Re: Drive Mirroring References: <199711290422.PAA23032@mother.sneaker.net.au> <19971129151057.57891@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <19971129151057.57891@lemis.com>; from Greg Lehey on Sat, Nov 29, 1997 at 03:10:57PM +1030 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, Nov 29, 1997 at 03:10:57PM +1030, Greg Lehey wrote: >On Sat, Nov 29, 1997 at 03:22:12PM +1100, Andrew Kenneth Milton wrote: >>> -----[ Jamil J. Weatherbee ]------------------------------ >>> >>> >>> Would a software RAID implementation be able to cope with having a drive >>> removed? >> >> The last implementation I saw of software RAID on Solaris didn't >> (about two years ago). >> >> It wouldn't boot from the secondary drives, > >Booting is a different matter. It's a lot more complicated, since you >need to explain RAID to the bootstrap. I don't think that's >feasible. But once the system is up and running, all other file >systems should be able to be RAID. The Veritas software that Sun supplies with their Sparc storage arrays these days does allow this. It was one of the first things I tried (having a mirrored boot disk, removing the one it usually boots from, and booting from the other). In the configuration I tested, the boot disk and its mirror were both "normal" disks attached to the primary scsi controller, and not disks in the storage arrays. Mirroring is the only RAID type supported for boot disks though. David From owner-freebsd-hackers Fri Nov 28 22:29:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA08998 for hackers-outgoing; Fri, 28 Nov 1997 22:29:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from mother.sneaker.net.au (mother.sneaker.net.au [203.30.3.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA08981 for ; Fri, 28 Nov 1997 22:29:42 -0800 (PST) (envelope-from akm@mother.sneaker.net.au) Received: (from akm@localhost) by mother.sneaker.net.au (8.8.5/8.8.5) id RAA24377 for hackers@freebsd.org; Sat, 29 Nov 1997 17:38:57 +1100 (EST) From: Andrew Kenneth Milton Message-Id: <199711290638.RAA24377@mother.sneaker.net.au> Subject: Re: Drive Mirroring To: hackers@freebsd.org Date: Sat, 29 Nov 1997 17:38:57 +1100 (EST) In-Reply-To: <19971129151057.57891@lemis.com> from "Greg Lehey" at Nov 29, 97 03:10:57 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk +-----[ Greg Lehey ]------------------------------ | | On Sat, Nov 29, 1997 at 03:22:12PM +1100, Andrew Kenneth Milton wrote: | >> -----[ Jamil J. Weatherbee ]------------------------------ | >> | >> | >> Would a software RAID implementation be able to cope with having a drive | >> removed? | > | > The last implementation I saw of software RAID on Solaris didn't | > (about two years ago). | > | > It wouldn't boot from the secondary drives, | | Booting is a different matter. I agree, (although if you had a list of alternatives to boot from...) but, it's usually difficult to explain this to clueless suit type people who have expectations of what the software they just bought can do. I don't think many people would want to mirror their boot partition, since it's pretty static. The people from Periphonics wanted $25,000 (USD 1995) for a 1 gig scsi drive for the rack mounted Sun that sits in their IVR Box. Any other drives void the warranty. We decided it was cheaper to void the warranty. The disk in the Sun is already pre-partitioned (one big one), and those that be wouldn't let me re-partition it sanely. Hence they wanted the whole disk mirrored, boot and all. -- ,-_|\ SneakerNet | Andrew Milton | GSM: +61(41)6 022 411 / \ P.O. Box 154 | akm@sneaker.net.au | Fax: +61(2) 9746 8233 \_,-._/ N Strathfield +--+----------------------+---+ Ph: +61(2) 9746 8233 v NSW 2137 | Low cost Internet Solutions | From owner-freebsd-hackers Fri Nov 28 22:55:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA10607 for hackers-outgoing; Fri, 28 Nov 1997 22:55:43 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA10602 for ; Fri, 28 Nov 1997 22:55:38 -0800 (PST) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id RAA27918; Sat, 29 Nov 1997 17:25:27 +1030 (CST) (envelope-from grog) Message-ID: <19971129172526.39614@lemis.com> Date: Sat, 29 Nov 1997 17:25:26 +1030 From: Greg Lehey To: David Dawes Cc: hackers@FreeBSD.ORG Subject: Re: Drive Mirroring References: <199711290422.PAA23032@mother.sneaker.net.au> <19971129151057.57891@lemis.com> <19971129165905.08819@rf900.physics.usyd.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <19971129165905.08819@rf900.physics.usyd.edu.au>; from David Dawes on Sat, Nov 29, 1997 at 04:59:05PM +1100 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, Nov 29, 1997 at 04:59:05PM +1100, David Dawes wrote: > On Sat, Nov 29, 1997 at 03:10:57PM +1030, Greg Lehey wrote: >> On Sat, Nov 29, 1997 at 03:22:12PM +1100, Andrew Kenneth Milton wrote: >>>> Would a software RAID implementation be able to cope with having a drive >>>> removed? >>> >>> The last implementation I saw of software RAID on Solaris didn't >>> (about two years ago). >>> >>> It wouldn't boot from the secondary drives, >> >> Booting is a different matter. It's a lot more complicated, since you >> need to explain RAID to the bootstrap. I don't think that's >> feasible. But once the system is up and running, all other file >> systems should be able to be RAID. > > The Veritas software that Sun supplies with their Sparc storage arrays > these days does allow this. It was one of the first things I tried > (having a mirrored boot disk, removing the one it usually boots from, > and booting from the other). In the configuration I tested, the boot > disk and its mirror were both "normal" disks attached to the primary > scsi controller, and not disks in the storage arrays. Mirroring is the > only RAID type supported for boot disks though. Yes, Tandem supplies Veritas as well, and Version 2 (which is even more convoluted than Version 1) supports booting from a Veritas volume. It does this by imposing significant restrictions on the format of root volumes. It's not nice--I'd guess that it would make more sense to have a really intelligent boot to handle things until Veritas (or whatever) was up and running. For the benefit of those who don't know Veritas: it runs as a number of processes, notably the Volume Daemon. Until that's up and running, you can't mount Veritas volumes (virtual disks). Greg From owner-freebsd-hackers Fri Nov 28 23:11:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA11960 for hackers-outgoing; Fri, 28 Nov 1997 23:11:54 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA11954 for ; Fri, 28 Nov 1997 23:11:49 -0800 (PST) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id RAA28018; Sat, 29 Nov 1997 17:41:29 +1030 (CST) (envelope-from grog) Message-ID: <19971129174129.61865@lemis.com> Date: Sat, 29 Nov 1997 17:41:29 +1030 From: Greg Lehey To: Andrew Kenneth Milton Cc: hackers@FreeBSD.ORG Subject: Re: Drive Mirroring References: <19971129151057.57891@lemis.com> <199711290638.RAA24377@mother.sneaker.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <199711290638.RAA24377@mother.sneaker.net.au>; from Andrew Kenneth Milton on Sat, Nov 29, 1997 at 05:38:57PM +1100 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, Nov 29, 1997 at 05:38:57PM +1100, Andrew Kenneth Milton wrote: >> -----[ Greg Lehey ]------------------------------ >> Booting is a different matter. > > I agree, (although if you had a list of alternatives to boot from...) > but, it's usually difficult to explain this to clueless suit type people > who have expectations of what the software they just bought can do. That's fine. They don't need to understand the technical background. They paid for a solution, now they want a solution. > I don't think many people would want to mirror their boot partition, since > it's pretty static. Right, assuming (as is common in SysV) that they have a separate boot partition, probably mounted on /stand. But the root file system is a whole different kettle of fish. > The people from Periphonics wanted $25,000 (USD 1995) for a 1 gig > scsi drive for the rack mounted Sun that sits in their IVR Box. Any > other drives void the warranty. We decided it was cheaper to void > the warranty. Yup, I'd understand that, especially when I consider how much the warranty is probably worth. > The disk in the Sun is already pre-partitioned (one big one), and those that > be wouldn't let me re-partition it sanely. Hence they wanted the whole > disk mirrored, boot and all. Sounds like SNI. A minimum of 5 partitions on a 1 GB drive, and the install utility is set up so that you just *can't* do without any of them. Greg From owner-freebsd-hackers Sat Nov 29 00:42:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA17838 for hackers-outgoing; Sat, 29 Nov 1997 00:42:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from pluto.senet.com.au (root@pluto.senet.com.au [203.11.90.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA17829 for ; Sat, 29 Nov 1997 00:42:36 -0800 (PST) (envelope-from darius@holly.rd.net) Received: from holly.rd.net (root@c2-p22.senet.com.au [203.56.237.87]) by pluto.senet.com.au (8.8.7/8.8.7) with ESMTP id TAA03369; Sat, 29 Nov 1997 19:12:27 +1030 Received: from holly.rd.net (darius@localhost.rd.net [127.0.0.1]) by holly.rd.net (8.8.5/8.8.5) with ESMTP id TAA14519; Sat, 29 Nov 1997 19:17:15 +1030 (CST) Message-Id: <199711290847.TAA14519@holly.rd.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: Daniel Leeds Cc: hackers@freebsd.org Subject: Re: land patch? In-reply-to: Your message of "Fri, 28 Nov 1997 15:25:03 -0800." <199711282325.PAA18196@inertia.dfacades.com> Reply-to: darius@senet.com.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 29 Nov 1997 19:17:15 +1030 From: "Daniel J. O'Connor" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > is there a patch for freebsd 2.2.5 to defeat the land attack? > is it just one file in the kernel source tree that needs to be > rebuilt with the newest code? I tried this on my 2.2.2 machine, and it survived with no problems! :) Ditto for teardrop. --------------- Daniel O'Connor 3rd Year Computer Science at Flinders University http://www.geocities.com/CapeCanaveral/7200 From owner-freebsd-hackers Sat Nov 29 01:12:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA19273 for hackers-outgoing; Sat, 29 Nov 1997 01:12:46 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from unix.tfs.net (node30.tfs.net [207.2.220.30]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA19266 for ; Sat, 29 Nov 1997 01:12:42 -0800 (PST) (envelope-from jbryant@unix.tfs.net) Received: (from jbryant@localhost) by unix.tfs.net (8.8.7/8.8.5) id DAA06897; Sat, 29 Nov 1997 03:12:19 -0600 (CST) From: Jim Bryant Message-Id: <199711290912.DAA06897@unix.tfs.net> Subject: Re: Drive Mirroring In-Reply-To: <19971129174129.61865@lemis.com> from Greg Lehey at "Nov 29, 97 05:41:29 pm" To: grog@lemis.com (Greg Lehey) Date: Sat, 29 Nov 1997 03:12:18 -0600 (CST) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@unix.tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply: > > The disk in the Sun is already pre-partitioned (one big one), and those that > > be wouldn't let me re-partition it sanely. Hence they wanted the whole > > disk mirrored, boot and all. > > Sounds like SNI. A minimum of 5 partitions on a 1 GB drive, and the > install utility is set up so that you just *can't* do without any of > them. heh... i know someone who refused to put /opt on his boot drive, and couldn't figure out why install didn't work right... as for your RAID, are you going to do the vold thing, or will it be more integral? also, will it be part of the base dist, like ccd is, or a third-party thing? When will it be testable? 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+ From owner-freebsd-hackers Sat Nov 29 01:16:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA19421 for hackers-outgoing; Sat, 29 Nov 1997 01:16:55 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA19410 for ; Sat, 29 Nov 1997 01:16:50 -0800 (PST) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id TAA00991; Sat, 29 Nov 1997 19:46:37 +1030 (CST) (envelope-from grog) Message-ID: <19971129194634.50223@lemis.com> Date: Sat, 29 Nov 1997 19:46:35 +1030 From: Greg Lehey To: jbryant@unix.tfs.net Cc: freebsd-hackers@freebsd.org Subject: Re: Drive Mirroring References: <19971129174129.61865@lemis.com> <199711290912.DAA06897@unix.tfs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <199711290912.DAA06897@unix.tfs.net>; from Jim Bryant on Sat, Nov 29, 1997 at 03:12:18AM -0600 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, Nov 29, 1997 at 03:12:18AM -0600, Jim Bryant wrote: > In reply: >>> The disk in the Sun is already pre-partitioned (one big one), and those that >>> be wouldn't let me re-partition it sanely. Hence they wanted the whole >>> disk mirrored, boot and all. >> >> Sounds like SNI. A minimum of 5 partitions on a 1 GB drive, and the >> install utility is set up so that you just *can't* do without any of >> them. > > heh... i know someone who refused to put /opt on his boot drive, and > couldn't figure out why install didn't work right... > > as for your RAID, are you going to do the vold thing, or will it be > more integral? I'll be doing something like vold, though I haven't decided whether I really *need* a daemon running all the time. Raid will be a plex type, along with the standard concatenated and striped kinds. > also, will it be part of the base dist, like ccd is, or a > third-party thing? That's partially for the FreeBSD team to decide, but since it's being funded by a third party, they don't want to release it immediately. They have committed to releasing the code under a Berkeley-like agreement, however. > When will it be testable? Real Soon Now. Maybe January. At least in part. If you're interested, I'll see what I can do. Greg From owner-freebsd-hackers Sat Nov 29 04:20:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA29221 for hackers-outgoing; Sat, 29 Nov 1997 04:20:59 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA29214 for ; Sat, 29 Nov 1997 04:20:52 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id NAA11719 for hackers@freebsd.org; Sat, 29 Nov 1997 13:20:48 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id NAA09591; Sat, 29 Nov 1997 13:09:11 +0100 (MET) Message-ID: <19971129130911.48275@uriah.heep.sax.de> Date: Sat, 29 Nov 1997 13:09:11 +0100 From: J Wunsch To: hackers@freebsd.org Subject: Re: Union and Portal FSs Reply-To: Joerg Wunsch References: <199711290155.RAA22650@silvia.HIP.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199711290155.RAA22650@silvia.HIP.Berkeley.EDU>; from Satoshi Asami on Fri, Nov 28, 1997 at 05:55:42PM -0800 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Satoshi Asami wrote: > * > Kazu did quite some work on unionfs, and i think it's basically usable > ^^^^ > That's Mr. Kato. ("Kazu" is the syscons person.) Sorry sorry... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Nov 29 04:40:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA00415 for hackers-outgoing; Sat, 29 Nov 1997 04:40:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA00389 for ; Sat, 29 Nov 1997 04:40:16 -0800 (PST) (envelope-from brian@awfulhak.org) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.7/8.8.7) with ESMTP id MAA24102; Sat, 29 Nov 1997 12:34:55 GMT (envelope-from brian@gate.lan.awfulhak.org) Message-Id: <199711291234.MAA24102@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: gclarkii@brewich.com cc: freebsd-hackers@freebsd.org Subject: Re: conflict link.h dlfcn.h In-reply-to: Your message of "Thu, 27 Nov 1997 03:50:21 CST." <199711270950.DAA05190@main.gbdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 29 Nov 1997 12:34:54 +0000 From: Brian Somers Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hello, > > I'm in the process of trying to get postgresql to run and have ran into > a conflict in our header files. > > Here is what the prototypes look like in both link.h and postgresql: > void *dlopen(const *char, int); > int dlclose(void *); > void *dlsym(void *, const char *) > const char *dlerror(void) > > Here is what they look like in dlfcn.h > void *dlopen( *char, int); > int dlclose(void *); > void *dlsym(void *, char *) > char *dlerror(void) > > Note the lack of const in use in dlfcn.h. This causes postgresql to > toss its cookies here and require a hack. > > Which one is correct? The const one. I recently added the const'ness, but it was added to both. I suspect foul play from a ``make world''. dlfcn.h comes from /usr/src/lib/csu/i386/ - is that version correct ? I also note that link.h has been removed from the sources now :-) > Gary > > > -- > Gary Clark II (N5VMF) | I speak only for myself and "maybe" my company > gclarkii@Brewich.COM | Fallen member of the FreeBSD Doc Team -- Brian , , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Sat Nov 29 08:52:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA08441 for hackers-outgoing; Sat, 29 Nov 1997 08:52:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from zippy.dyn.ml.org (garbanzo@tokyo-35.ppp.hooked.net [206.169.229.35]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA08436 for ; Sat, 29 Nov 1997 08:52:42 -0800 (PST) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.7/8.8.7) with SMTP id IAA00448; Sat, 29 Nov 1997 08:52:28 -0800 (PST) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Sat, 29 Nov 1997 08:52:26 -0800 (PST) From: Alex X-Sender: garbanzo@zippy.dyn.ml.org To: "Daniel J. O'Connor" cc: Daniel Leeds , hackers@freebsd.org Subject: Re: land patch? In-Reply-To: <199711290847.TAA14519@holly.rd.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 29 Nov 1997, Daniel J. O'Connor wrote: > > > is there a patch for freebsd 2.2.5 to defeat the land attack? > > is it just one file in the kernel source tree that needs to be > > rebuilt with the newest code? > I tried this on my 2.2.2 machine, and it survived with no problems! :) > Ditto for teardrop. According to someone on BugTraq, a bug was "fixed" with the tcp-stack after 2.2.2, that makes 2.2.5 machines vunerable to these attacks. Patches should have already been checked into the source tree, and can be retreived via cvsup or ctm (see the handbook http://www.freebsd.org/handbook). - alex From owner-freebsd-hackers Sat Nov 29 10:20:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA12418 for hackers-outgoing; Sat, 29 Nov 1997 10:20:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA12406 for ; Sat, 29 Nov 1997 10:20:31 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xbqt2-0001Fp-00; Sat, 29 Nov 1997 09:41:00 -0800 Date: Sat, 29 Nov 1997 09:40:53 -0800 (PST) From: Tom To: Alex cc: "Daniel J. O'Connor" , Daniel Leeds , hackers@freebsd.org Subject: Re: land patch? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 29 Nov 1997, Alex wrote: > On Sat, 29 Nov 1997, Daniel J. O'Connor wrote: > > > > is there a patch for freebsd 2.2.5 to defeat the land attack? > > > is it just one file in the kernel source tree that needs to be > > > rebuilt with the newest code? > > I tried this on my 2.2.2 machine, and it survived with no problems! :) > > Ditto for teardrop. > > According to someone on BugTraq, a bug was "fixed" with the tcp-stack > after 2.2.2, that makes 2.2.5 machines vunerable to these attacks. > Patches should have already been checked into the source tree, and can be > retreived via cvsup or ctm (see the handbook > http://www.freebsd.org/handbook). However, it is very unclear what the effect of the this bug was. land.c certainly doesn't seem to hang FreeBSD, but it does mess with the stack a bit. Using tcpdump on an old FreeBSD system, the land.c seems to cause a packet to repeat over and over again. It seems to eat up some CPU, and some buffer space. > - alex Tom From owner-freebsd-hackers Sat Nov 29 10:50:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA13967 for hackers-outgoing; Sat, 29 Nov 1997 10:50:47 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA13960 for ; Sat, 29 Nov 1997 10:50:44 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id KAA24567; Sat, 29 Nov 1997 10:49:02 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd024564; Sat Nov 29 10:48:52 1997 Date: Sat, 29 Nov 1997 10:46:36 -0800 (PST) From: Julian Elischer To: Greg Lehey cc: Andrew Kenneth Milton , hackers@freebsd.org Subject: Re: Drive Mirroring In-Reply-To: <19971129174129.61865@lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk booting off mirrored disks isn't too hard. booting off striped disks is a real problem and booting off mirrored floppies is a snap. (swap floppy, hit reset) :) I had a system where the root is a MFS in a partition marked with ID 164 and when it has booted it loads everything from partitions marked 165. (which COULD have been mirrored or even striped) On Sat, 29 Nov 1997, Greg Lehey wrote: > On Sat, Nov 29, 1997 at 05:38:57PM +1100, Andrew Kenneth Milton wrote: > >> -----[ Greg Lehey ]------------------------------ > >> Booting is a different matter. > > > > I agree, (although if you had a list of alternatives to boot from...) > > but, it's usually difficult to explain this to clueless suit type people > > who have expectations of what the software they just bought can do. > > That's fine. They don't need to understand the technical background. > They paid for a solution, now they want a solution. > > > I don't think many people would want to mirror their boot partition, since > > it's pretty static. > > Right, assuming (as is common in SysV) that they have a separate boot > partition, probably mounted on /stand. But the root file system is a > whole different kettle of fish. > > > The people from Periphonics wanted $25,000 (USD 1995) for a 1 gig > > scsi drive for the rack mounted Sun that sits in their IVR Box. Any > > other drives void the warranty. We decided it was cheaper to void > > the warranty. > > Yup, I'd understand that, especially when I consider how much the > warranty is probably worth. > > > The disk in the Sun is already pre-partitioned (one big one), and those that > > be wouldn't let me re-partition it sanely. Hence they wanted the whole > > disk mirrored, boot and all. > > Sounds like SNI. A minimum of 5 partitions on a 1 GB drive, and the > install utility is set up so that you just *can't* do without any of > them. > > Greg > From owner-freebsd-hackers Sat Nov 29 11:18:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA15301 for hackers-outgoing; Sat, 29 Nov 1997 11:18:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA15296 for ; Sat, 29 Nov 1997 11:17:56 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id GAA14582; Sun, 30 Nov 1997 06:15:59 +1100 Date: Sun, 30 Nov 1997 06:15:59 +1100 From: Bruce Evans Message-Id: <199711291915.GAA14582@godzilla.zeta.org.au> To: bde@zeta.org.au, jak@cetlink.net Subject: Re: 650 UART, SIO driver, 8259 PIC Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>According to the diagram in the Intel data sheet, and my experiments, >>the edge latch isn't cleared until the external interrupt goes away. >> >>> 10 B3 of the IRR is set to 0 (IRR is unfrozen and B3 of >>> ESR is zero). > >I don't know what experiment you performed, but using a volt meter and >... I set an IRQ input to known states (driving it with a 16x50), disabled CPU interrupts, and read the IRR. The behaviour depends on whether the the interrupt has been latched when interrupts are disabled. >>>other useful work, by clearing the INT output of the last UART before >>>any of the previously drained UARTs can raise their INT output again, >>>you will have at least one down/up transition on the IRQ line. If you >> >>That would be a pessimization. It requires _two_ extra outputs per >>port (one to mess up the INT enable and one to restore it). > >That's not what I meant. :-( I'm not going to poke the UART twice to >toggle interrupt enable. > >The act of draining the FIFO will cause each UART to pull its INT >output (pin 30 on a 40-pin DIP) to ground. In the case of an 8-port Not if there is a transmitter, modem status or line status interrupt pending at the instant the FIFO is drained (to just below the trigger level). >shared interrupt card, at the instant the last UART is drained below >its FIFO trigger level, all eight INT output pins will be at ground. Not if you didn't drain one of the previous UARTs (because its fifo wasn't full when you looked at it; draining partially full fifos would be a pessimization). Then there may be a receiver interrupt pending on one of the previous UARTs. Similarly, not if a transmitter, modem status or line status interrupt has become pending on one of the previous UARTs. Bruce From owner-freebsd-hackers Sat Nov 29 12:14:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA18541 for hackers-outgoing; Sat, 29 Nov 1997 12:14:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from zippy.dyn.ml.org (garbanzo@libya-240.ppp.hooked.net [206.169.227.240]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA18533 for ; Sat, 29 Nov 1997 12:14:47 -0800 (PST) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.7/8.8.7) with SMTP id MAA25536; Sat, 29 Nov 1997 12:15:24 -0800 (PST) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Sat, 29 Nov 1997 12:15:24 -0800 (PST) From: Alex X-Sender: garbanzo@zippy.dyn.ml.org To: Tom cc: "Daniel J. O'Connor" , Daniel Leeds , hackers@freebsd.org Subject: Re: land patch? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 29 Nov 1997, Tom wrote: > > According to someone on BugTraq, a bug was "fixed" with the tcp-stack > > after 2.2.2, that makes 2.2.5 machines vunerable to these attacks. > > Patches should have already been checked into the source tree, and can be > > retreived via cvsup or ctm (see the handbook > > http://www.freebsd.org/handbook). > > However, it is very unclear what the effect of the this bug was. land.c > certainly doesn't seem to hang FreeBSD, but it does mess with the stack a > bit. Using tcpdump on an old FreeBSD system, the land.c seems to cause > a packet to repeat over and over again. It seems to eat up some CPU, and > some buffer space. That's probably what the bug is. Afterall spiking cpu loads could be considered a DoS attack, especially if you send hundreds of them to a ocmputer. - alex From owner-freebsd-hackers Sat Nov 29 12:18:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA18849 for hackers-outgoing; Sat, 29 Nov 1997 12:18:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA18843 for ; Sat, 29 Nov 1997 12:18:01 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id HAA16179; Sun, 30 Nov 1997 07:17:23 +1100 Date: Sun, 30 Nov 1997 07:17:23 +1100 From: Bruce Evans Message-Id: <199711292017.HAA16179@godzilla.zeta.org.au> To: bde@zeta.org.au, jak@cetlink.net Subject: Re: 650 UART, SIO driver, 8259 PIC Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >...The >>chance of a problem after 1 second (if we start scanning for interrupts = >on >>sio0 and don't go back to sio0 after finding an interrupt on sio1) is 1 = >- >>(1 - 1644/10**6)**822 =3D 74 in 100. > >That's no guarantee of avoiding a missed interrupt either. After >checking sio0 a second time and finding no interrupts, it will take a >few clock cycles to reach to reach the instruction which sends EOI and >then exit the ISR. How can you be sure that sio1 does not reinterrupt >before you exit cleanly? Well, it can't interrupt the CPU since CPU interrupts are masked. New interrupts only get as far as the IRR in the ICU. Most of them could be detected by reading the IRR, but that would be a pessimization, and anyway ... >You can't. The reason it works is because you do get a new interrupt >after exiting the ISR. Right. ... even if you read the IRR just before returning, an interrupt may occur after you read the IRR but before you return fully. BTW, I remember why an EOI is sent on return and not at the start for the non-auto-EOI case. It is to reduce interrupt latency. >It becomes clear if you trace the steps backwards: Prior to checking >sio0 for a second time, you had drained sio1, clearing its interrupt. >Prior to that you had drained sio0, clearing its interrupt. Now >you've come around full circle and checked sio0 again. You know that >the state of sio0 has not changed since the last time you looked at it >- sio0 has pulled its INT output to ground for the entire time it took >to make that full circle. It's slightly more complicated: 1. We don't always handle all the pending interrupts in siointr1(). This may result in the loop being iterated once more than necessary, but it only costs a few integer instructions since it avoids a check of the IIR after siointr1() returns. 2. Two more iterations of the loop after handling _all_ (that we noticed) would be required for things to work like you said. One more is required to check that the sloppy handling done by siointr1() was actually complete. and subtler: 3. However, we only do one more. This works because xx(x)50 UARTs never drop their IRQ unless they are accessed in a certain way (or reset, or power fails, etc.). This implies that if there is no interrupt pending on any of the UARTs when they are looked at in the loop, there must have been no interrupt pending at the start of the loop, so the edge latch must have been inactive at that time and any subsequent interrupt will be seen by the ICU and we will get interrupted after we return. >You also know that during all that time where sio0 held its INT output >to ground, you drained sio1, causing its INT output to be pulled to >ground. Not quite - see above. >That means that all the (two) UARTs on your multiport board >have simultaneously pulled their output to ground for at least some >brief time -- the proof is clear. So if a new interrupt occurs before >you can exit the ISR, you will have a low/high transition on the IRQ >line, ESR will record the new edge, and when you exit the ISR you will >get a new interrupt. Correct. >But it breaks down with more than two UARTs. In the case of sio0, No. >... >So now you have to recheck sio1 also. But then what about sio0? It >could also reinterrupt, your IRQ line never goes ground, ESR cannot >sense any edge, and you lose an interrupt. And so on and so on ... >with more than two UARTs, you can never stop looping or you might miss >an interrupt! We just go around once more when another interrupt becomes pending. More than once is unlikely, and infinitely often is impossible if the system isn't overloaded just handling the interrupts. Bruce From owner-freebsd-hackers Sat Nov 29 14:00:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA23066 for hackers-outgoing; Sat, 29 Nov 1997 14:00:37 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA23061 for ; Sat, 29 Nov 1997 14:00:33 -0800 (PST) (envelope-from jak@cetlink.net) Received: from hot1.auctionfever.com (ts1-cltnc-46.cetlink.net [209.54.58.46]) by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id RAA16448; Sat, 29 Nov 1997 17:00:17 -0500 (EST) From: jak@cetlink.net (John Kelly) To: Bruce Evans Cc: hackers@freebsd.org Subject: Re: 650 UART, SIO driver, 8259 PIC Date: Sat, 29 Nov 1997 23:01:21 GMT Message-ID: <348095b5.441871@mail.cetlink.net> References: <199711292017.HAA16179@godzilla.zeta.org.au> In-Reply-To: <199711292017.HAA16179@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id OAA23062 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 30 Nov 1997 07:17:23 +1100, Bruce Evans wrote: >>then exit the ISR. How can you be sure that sio1 does not reinterrupt >>before you exit cleanly? >Well, it can't interrupt the CPU since CPU interrupts are masked. That's not what I meant by a new interrupt. Perhaps I should have said "interrupt request presented to the 8259." >New interrupts only get as far as the IRR in the ICU. That's what I meant. >power fails, etc.). This implies that if there is no interrupt pending >on any of the UARTs when they are looked at in the loop, there must have >been no interrupt pending at the start of the loop, so the edge latch >must have been inactive at that time and any subsequent interrupt will >be seen by the ICU and we will get interrupted after we return. OK, I see it now. I did not realize that a complete pass with no interrupt proves that when starting the pass all were low. But as the number of ports per shared IRQ increases, so does the overhead of using that technique. I would like to find a more efficient means if possible. I now see the value of the UNIX status register (which SIO ignores) on my shared interrupt multiport board. The board maker did not even document how it works, but I would guess that for each UART it has a bit which follows the state of the UART's INT output. I may poke around on the board to see if that's true. You could simply read the status register to see if all eight were low and then safely exit the ISR. And you could also avoid checking every UART every time you enter the ISR. John From owner-freebsd-hackers Sat Nov 29 14:25:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA24003 for hackers-outgoing; Sat, 29 Nov 1997 14:25:04 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA23994 for ; Sat, 29 Nov 1997 14:24:59 -0800 (PST) (envelope-from jak@cetlink.net) Received: from hot1.auctionfever.com (ts1-cltnc-46.cetlink.net [209.54.58.46]) by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id RAA17738; Sat, 29 Nov 1997 17:24:33 -0500 (EST) From: jak@cetlink.net (John Kelly) To: Bruce Evans Cc: hackers@freebsd.org Subject: Re: 650 UART, SIO driver, 8259 PIC Date: Sat, 29 Nov 1997 23:25:37 GMT Message-ID: <3481a093.3224591@mail.cetlink.net> References: <199711292017.HAA16179@godzilla.zeta.org.au> In-Reply-To: <199711292017.HAA16179@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id OAA23998 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 30 Nov 1997 07:17:23 +1100, Bruce Evans wrote: >BTW, I remember why an EOI is sent on return and not at the start >for the non-auto-EOI case. That was my next question. :-) >It is to reduce interrupt latency. I guess that depends on how you measure latency. But it seems that the requesting device must wait the same length of time to get service either way, at least in the case where the ISR leaves CPU interrupts disabled until exiting with IRET automatically reenables them. Perhaps EOI at the start (like auto-EOI) would be useful if the ISR reenabled CPU interrupts to allow other devices to pre-empt the current ISR. John From owner-freebsd-hackers Sat Nov 29 14:43:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA24809 for hackers-outgoing; Sat, 29 Nov 1997 14:43:49 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from zippy.dyn.ml.org (root@ghana-141.ppp.hooked.net [206.169.228.141]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA24799 for ; Sat, 29 Nov 1997 14:43:43 -0800 (PST) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.7/8.8.7) with SMTP id OAA01645; Sat, 29 Nov 1997 14:29:18 -0800 (PST) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Sat, 29 Nov 1997 14:29:17 -0800 (PST) From: Alex X-Sender: garbanzo@zippy.dyn.ml.org To: Julian Assange cc: hackers@FreeBSD.ORG Subject: Re: detecting devfs from userland? In-Reply-To: <19971126232220.5569.qmail@iq.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 26 Nov 1997, Julian Assange wrote: > > Is there anyway to detect if the running kernel was built with > -DDEVFS, other than trying to mount -t devfs ? (i.e a way that > doesn't require root privs? sysctl -a is of no use here. I'm suprised nobody mentioned this earlier, but you might want to try getvfsbyname(3). However it seems that the manpages are only correct if _NEW_VFSCONF is defined (which it isn't on my system). The correct prototype seems to be vfsconf * getvfsbyname(char *). - alex From owner-freebsd-hackers Sat Nov 29 19:04:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA09890 for hackers-outgoing; Sat, 29 Nov 1997 19:04:24 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from kai.communique.net (Kai.communique.net [204.27.67.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA09883 for ; Sat, 29 Nov 1997 19:04:20 -0800 (PST) (envelope-from nectar@NECTAR.COM) Received: (from smap@localhost) by kai.communique.net (8.8.8/8.8.7) id VAA23688 for ; Sat, 29 Nov 1997 21:08:37 -0600 (CST) X-Authentication-Warning: kai.communique.net: smap set sender to using -f Received: from localhost.communique.net(127.0.0.1) by kai.communique.net via smap (V2.0) id xma023685; Sat, 29 Nov 97 21:08:17 -0600 Date: Sat, 29 Nov 1997 21:08:14 -0600 (CST) From: Jacques Vidrine X-Sender: nectar@kai.communique.net To: freebsd-hackers@FreeBSD.ORG Subject: pthreads In-Reply-To: <199711300155.RAA05855@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, Where can I find a status of pthread support for FreeBSD-current? I've not had experience with them before, but I have attempted to compile Python 1.5b1 with thread support, and the resulting application is not stable (in particular I've had problems with signals and the thread APIs themselves). My application is compiled with '-nodefaultlibs -lc_r -lgcc' ... I'm not sure if this is the best (or even correct) approach. I would appreciate any comments/suggestions/help anyone has to offer. Thanks!! Jacques Vidrine From owner-freebsd-hackers Sat Nov 29 19:13:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA10614 for hackers-outgoing; Sat, 29 Nov 1997 19:13:19 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from vinyl.quickweb.com (vinyl.quickweb.com [209.112.4.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA10609 for ; Sat, 29 Nov 1997 19:13:16 -0800 (PST) (envelope-from chrisc@vmunix.com) Received: from localhost (chrisc@localhost) by vinyl.quickweb.com (8.8.7/8.6.12) with SMTP id WAA26374 for ; Sat, 29 Nov 1997 22:14:35 -0500 (EST) Date: Sat, 29 Nov 1997 22:14:35 -0500 (EST) From: Chris Coleman X-Sender: chrisc@vinyl.quickweb.com To: hackers@freebsd.org Subject: Drive Mirroring. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Maybe I am missing the point of this conversation, but at work here we use a program called 'rdist'. It is in the packages collection. It copies all the files from one computer to another; we use it to copyu all our files from one disk to the other. It makes a perfect copy/backup. We installed the boot sector on the backup disk, and when/if the main disk crashes, we just unplug it and reboot. I would think it would work if you had two ccd'd disk sets. --Chris From owner-freebsd-hackers Sat Nov 29 20:53:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA16007 for hackers-outgoing; Sat, 29 Nov 1997 20:53:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA16002 for ; Sat, 29 Nov 1997 20:53:50 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id PAA29084; Sun, 30 Nov 1997 15:52:01 +1100 Date: Sun, 30 Nov 1997 15:52:01 +1100 From: Bruce Evans Message-Id: <199711300452.PAA29084@godzilla.zeta.org.au> To: bde@zeta.org.au, jak@cetlink.net Subject: Re: 650 UART, SIO driver, 8259 PIC Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>BTW, I remember why an EOI is sent on return and not at the start >>for the non-auto-EOI case. > >That was my next question. :-) > >>It is to reduce interrupt latency. > >I guess that depends on how you measure latency. But it seems that >the requesting device must wait the same length of time to get service >either way, at least in the case where the ISR leaves CPU interrupts >disabled until exiting with IRET automatically reenables them. Not sending the EOI early always reduces latency by the time it takes to do 1-2 i/o's (depending on how many of AUTO_EOI_1 and AUTO_EOI_2 are configured). Sending the EOI later only adds (almost unavoidable) latency if there another interrupt has become pending, but this is unlikely. >Perhaps EOI at the start (like auto-EOI) would be useful if the ISR >reenabled CPU interrupts to allow other devices to pre-empt the >current ISR. It's necessary for other devices to preempt the current ISR, and always done for "slow" interrupts (actually, the interrupt system preempts the current ISR and then decides what to do based on its own table of priorities). Preemption is not supported or very useful for "fast" interrupts. 8250 interrupts for a single UART can be handled so fast (5-10 i/o's) that there is no point in preempting them. This is not quite true for 16550 interrupts for multiple UARTs on one irq, but the scheduling for allowing interrupts is difficult. Bruce From owner-freebsd-hackers Sat Nov 29 21:42:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA18207 for hackers-outgoing; Sat, 29 Nov 1997 21:42:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA18199 for ; Sat, 29 Nov 1997 21:42:02 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id VAA03610; Sat, 29 Nov 1997 21:41:00 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd003608; Sat Nov 29 21:40:52 1997 Date: Sat, 29 Nov 1997 21:38:36 -0800 (PST) From: Julian Elischer To: hackers@freebsd.org cc: Julian Elischer Subject: Stackable storage Alpha release Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Over the last couple of years I have been slowely trying to increase the modularity of freeBSD. One of the things that I really didn't like about UNiX when I first started using it was the 'disconnection' between the contents of /dev and reality. To this end I have been working in the background on DEVFS. A device filesystem which allows (in fact requires) the device drivers to keep the exported picture of available devices in sync with what is actually attached. DEVFS has had it's ups and downs, but one of the difficulties it has had, is in dealing with the current idea of slices and partitions. Particularly, the way in which slices and devices are all mixed together. I finally gave up, and have spent the last 4 weeks or so rewriting The disk storage system. This comes from discussions I have had with PHK at TFS, and others (e.g. Peter Wemm in Perth) over the last few years. Redoing this, which is so basic to the system of course requires that many things be changed. A lot of the changes turn out to be clean-ups. For example, the code for interpretting the boot device as handed in by the bootblocks could be a lot cleaner. Mounting the root filesystem is in general a messy business in freeBSD, and a general cleanup there might make things easier to fix in the future. I have now a set of sample code and patches for freeBSD-current which allow the system to run on a DEVFS, using a primative version of the rewritten storage code. Anyone interested can get a copy of the changes from hub.freebsd.org in: ftp://hub.freebsd.org/pub/scsi/slice.tar.gz unpack the tar file in /sys to get all teh new files, then apply the patch slicediff that it leaves in /sys to get file CHANGES. This is very early code. It can however run on must systems that have scsi or IDE drives. (As long as bad144 is not used) there are the following points to be made: 1/ I have yet to integrate a whole bunch of work that phk has done on this, as I elected to get to a booting and running stage, before I did that. 2/ This code will not support old ESDI drives that cannot report their geometry. (there is support for it, but it is unfinished, and a change in direction is under way after a discussion with Mike Smith.) 3/ You need to change all the entries in /etc/fstab to use their CANONICAL names. e.g. sd1s1a rather that sd1a. There should be an entry of the form: devfs /dev devfs rw 1 1 possibly BEFORE root. 4/ As I write this you need to boot single user, and manually do a 'mount /dev' fsck -p ^D I'm not yet sure why. Rather than just proceding into multi-user mode, I would suggest trying out your devices in single-user mode anyway. 5/ there is a file i386/isa/ide.c this is wd.c with all the old code removed, and some cleanups. I did this just to see how much difference, removing all the old stuff made. 6/ The SCSI disk can still be accessed through the old interface in parallel with the new interface. the IDE disk cannot. If you boot with the root fs mounted from a DEVFS device, you will not be able to do the "mount -u / " from the normal /dev. so root has to be either devfs or not. If you use the "options SLICE", then you will get your root device from in internal kernel-only instance of devfs. 7/ I have no support or reading or writing 'in-core disklabels' yet. fdisk works on the raw device (warning, ANY raw device) and so does disklabel using the -r flag. There is no core-dump support yet in the new stuff. Storage Layering: Here is a brief description of storage layering: Every device exports a single storage interface. This is called a 'slice' Each slice is represented by a "struct slice". The struct has one and only one handler below it, (in this case the driver) and one or zero handlers above it. The slice itself exports a device to the devfs, so even if a raw disk had no handler above it, it would still have one raw device available for use. (e.g. rdsd0). If the slice were divided up using fdisk, so that an MBR was installed, defining some partitions, then the handler abovethe raw slice would be the MBR handler. If howeverm it were divided up using the "dangerously dedicated" mode, with a disklabel defining partitions, then the disklabel handler would be the handler above the slice. Each partitionning of the slice by the handler, produces more 'slices'. They export the identical interface that the lower slice does, so that it might be possible to fdisk an fdisk partiton for example. The only notable diffenence between two slices at different layers is they name. sd0->sd0s1->sd0s1a if we left out the fdisk stage, it would be: sdd0->sd0a and if we divided up an fdisk partition, using an MBR, we might see: sd0->sd0s1->sd0s1s1->sd0s1s1a (assuming we then disklabeled it) it is up to any handler to define how many slices it mutiplexes to above and below, but the slices themselves cannot multiplex. Thsi what eventually appears is a sandwich of: slices (sd0s1a) (sd0s1b) | | handler (disklabel) | slices (sd0s1) (sd0s2) (vn0a) (vn0b) | | | | handler ( MBR ) (disklabel) | | slices (sd0) (wd0) (vn0) | | | handler/driver (sd.c) (wd.c) (vn.c) There would be other layers eventually. e.g. A layer to do bad-block mapping (cough, I forgot to say I was't doing that yet?) A layer to do CCD or RAID type things. The 'slice' structure is well known, in that all handlers know all the fields, and can access them. This provides a 'mailbox' (SIC) for handlers to identify and communicate with each other, without needing too much knowledge about each other. The handlers supply an array of methods that they support, either from calls from above, or calls from below. I am still cleaning up the way that handlers invoke each-other's methods so be kind.. :) Comments are not only welcome, they are sought! If you repartition a disk, the entries in /dev should dynamically change. The present version however maintains consitency, by disallowing opens on lever level devices while higher level devices ar eopen, so you cannot at this time repartition your root disk while running on it. (I'm not convinced this is a good thing, but I should support it). julian I hope I haven't left anything out.. BTW SOS and Luigi.. thw patch includes DEVFS fixes for your device drivers.