Re: KLD naming
well you're about to get your first test we are releasing the netgrpah code in full production form tonigh (if the version we've put together for release passes all tests tonight) The whole thing installs as KLD modules (or linked in of course) our present names are all predicated with ng_ hence ng_socket ng_rfc1490, ng_frame_relay etc the base module is 'netgraph'. now what would you suggest? we can still cahnge it before we release and no-body knows any better but after is always harder to change than beefore.. julian On Wed, 20 Jan 1999, Mike Smith wrote: > > On Wed, Jan 20, 1999 at 07:19:15PM -0800, David O'Brien wrote: > > [..] > > > etc? This is what the original poster suggested, and nobody has really > > > given a good response what is wrong with the "grouping" being expressed > > > in the modules' name. Mike Smith and Andrzej Bialecki have given good > > > reasons why *not* to go to a subdirectory structure. > > > > What would you name a network stack? For example: > > > > net_mpls_tdp.ko > > net_mpls_ldp.ko > > net_mpls_core.ko > > > > or > > net_h323v2_yada.ko > > net_h323v2_yadayada.ko > > net_h323v2_barf.ko > > > > or > > codec_g711.ko > > codec_g7231a.ko > > codec_g729.ko > > > > Is that acceptable? Anyone have better ideas? > > I guess it depends on how fancy we want to get. Here are some examples > that I've been rolling around; some are fanciful, some practical) > > dev_generic device (eg. dev_sio) > bus_bus support (eg. bus_pci) > netif_ network interface (eg. netif_ed) > netproto_ network protocol (eg. netproto_arp) > netdomain_ network domain (eg. netdomain_ip) > vfs_VFS layer (eg. vfs_nfs) > kern_ kernel infrastructure (eg. kern_vfs) > syscall_loadable system calls (eg. syscall_sendfile) > > I don't think we want to make the mistake of being too specific about > what pigeonhole something falls into. In many cases, we might want new > categories when a new case arises, eg. for USB we might have: > > bus_usb.ko > usb_hub.ko > usb_mouse.ko > usb_keyboard.ko > usb_disk.ko > usb_scanner.ko > ... > > There's no ambiguity here, the names are simple and convey a direct > set of relationships. Your examples (except the first) do a pretty > good job of the same thing. > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ m...@smith.net.au > \\ The race is long, and in the \\ msm...@freebsd.org > \\ end it's only with yourself. \\ msm...@cdrom.com > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: some guidance on forked cvsup please
I currently run a 2.2.8 machine. Is there a guide somewhere on the exact process of bringing this up to the forthcoming 3.0 stable branch, such as the conversion from sdX to CAM, a.out to Elf, what softupdates are and who should use them, SMP, and the like? I am about to buy a new, dual proc mainboard to coincide with 3.0 going stable, and all of these are of interest to me, but I'm not sure the best way to migrate from the 'old' 2.2.x system to the 'new' 3.x system. Thanks! Jamie On Wed, Jan 20, 1999 at 11:57:09PM -0800, Matthew Dillon wrote: > > It's real simple. The -stable is the 3.x branch. This is the branch > that Jordan just created tonight. So, for example, if you do a > 'cvs log kern/vfs_bio.c' you will see this: > > ... > head: 1.193 > ... > RELENG_3: 1.193.0.2 > RELENG_3_BP: 1.193 > > What this means is that the HEAD of the CVS tree is 1.193, and > RELENG_3 ( the new -stable ) has been forked off as 1.193.0.2. > > If your files are currently checked out and have the HEAD branch's > revision, then anything you checkin will be checked in under > -current ( the -4.x tree ). > > If your files are currently checked out and have RELENG_3's branch > revision, then anything you check in will be checked in under > -stable ( the -3.x tree ). > > If you haven't messed with your CVS tree and it was previously > -current ( 3.x ), it is still -current, but is now 4.x. > > -Matt > Matthew Dillon > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: KLD naming
> well you're about to get your first test > we are releasing the netgrpah code in full production form tonigh (if > the version we've put together for release passes all tests tonight) > The whole thing installs as KLD modules (or linked in of course) > > our present names are all predicated with ng_ > hence ng_socket ng_rfc1490, ng_frame_relay etc > the base module is 'netgraph'. > > now what would you suggest? > we can still cahnge it before we release and no-body knows any better but > after is always harder to change than beefore.. Hmm. Where does "netgraph" fit in? From your earlier commits, I presume it's a domain, so I would suggest: netdomain_netgraph.ko netgraph_rfc1490.ko netgraph_framerelay.ko ... ie. don't be afraid to be verbose. I'd certainly say "no" to a two-letter abbreviation. > julian > > > On Wed, 20 Jan 1999, Mike Smith wrote: > > > > On Wed, Jan 20, 1999 at 07:19:15PM -0800, David O'Brien wrote: > > > [..] > > > > etc? This is what the original poster suggested, and nobody has really > > > > given a good response what is wrong with the "grouping" being expressed > > > > in the modules' name. Mike Smith and Andrzej Bialecki have given good > > > > reasons why *not* to go to a subdirectory structure. > > > > > > What would you name a network stack? For example: > > > > > > net_mpls_tdp.ko > > > net_mpls_ldp.ko > > > net_mpls_core.ko > > > > > > or > > > net_h323v2_yada.ko > > > net_h323v2_yadayada.ko > > > net_h323v2_barf.ko > > > > > > or > > > codec_g711.ko > > > codec_g7231a.ko > > > codec_g729.ko > > > > > > Is that acceptable? Anyone have better ideas? > > > > I guess it depends on how fancy we want to get. Here are some examples > > that I've been rolling around; some are fanciful, some practical) > > > > dev_generic device (eg. dev_sio) > > bus_bus support (eg. bus_pci) > > netif_ network interface (eg. netif_ed) > > netproto_ network protocol (eg. netproto_arp) > > netdomain_ network domain (eg. netdomain_ip) > > vfs_VFS layer (eg. vfs_nfs) > > kern_ kernel infrastructure (eg. kern_vfs) > > syscall_loadable system calls (eg. syscall_sendfile) > > > > I don't think we want to make the mistake of being too specific about > > what pigeonhole something falls into. In many cases, we might want new > > categories when a new case arises, eg. for USB we might have: > > > > bus_usb.ko > > usb_hub.ko > > usb_mouse.ko > > usb_keyboard.ko > > usb_disk.ko > > usb_scanner.ko > > ... > > > > There's no ambiguity here, the names are simple and convey a direct > > set of relationships. Your examples (except the first) do a pretty > > good job of the same thing. > > > > -- > > \\ Sometimes you're ahead, \\ Mike Smith > > \\ sometimes you're behind. \\ m...@smith.net.au > > \\ The race is long, and in the \\ msm...@freebsd.org > > \\ end it's only with yourself. \\ msm...@cdrom.com > > > > > > > > To Unsubscribe: send mail to majord...@freebsd.org > > with "unsubscribe freebsd-current" in the body of the message > > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: /etc/nsswitch.conf
Mike Nguyen writes: > I noticed that NetBSD is switching over to using /etc/nsswitch.conf (like > Slowlaris, PH-UX, etc.). Would it be a good idea to do this for FreeBSD too > (when I first started using FreeBSD, it took me a long time to figure out the > analogous file for hostname lookups was /etc/host.conf) -- it seems > consolidating all that config information would in one place would be a good > thing. There was talk of integrating into libc something which we already have in our tree: irs.conf. It's part of the bind source. Nothing seems to have happened though. It's a fairly major change to lots of libc. -- When I said "we", officer, I was referring to myself, the four young ladies, and, of course, the goat. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: New version of Vinum
At 02:13 PM 1/21/99 +1030, you wrote: >I've just committed a new version of Vinum with a large number of >changes. It works fine here, much better than the old version, but >there's just a possibility that things may go wrong. If you have >trouble, please let me know immediately. Greg, Was this just committed to -current, or is this also in -stable (now that it exists)? I'd like to move to -stable, but if the latest Vinum mods are going to take a while to move to -current I'll be staying here for the duration. :) -ck To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Heads up! New swapper and VM changes have been committed to -4.x
It's all in. The more feedback the better. You will have to recompile KVM-related support programs, especially pstat. I also suggest recompiling libkvm, ps, top, vmstat, systat, etc... The new swapper is not understood by top or systat yet but it is well understood by pstat -s ( aka swapinfo ), and pstat -ss will dump the radix tree. One thing I haven't been able to test, because I forgot: Interleaved swap ( more then one swap device ). I'll try to test that ASAP. I've tested everything else as well as I've been able, mainly by running 'make -j30 buildworld', make on various ports, eatmem, and other applications all at once on my test box. No comments on syntax, please, the commit is understood to be rough and the syntax and comments will be fixed up with more commits. I intend to make further forced commits to document special items, such as core bug fixes, and addlib other comments. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Heads up! New swapper and VM changes have been committed to -4.x
On Thursday, 21 January 1999 at 0:55:38 -0800, Matthew Dillon wrote: > It's all in. The more feedback the better. > > You will have to recompile KVM-related support programs, especially > pstat. I also suggest recompiling libkvm, ps, top, vmstat, systat, > etc... > > The new swapper is not understood by top or systat yet but it is > well understood by pstat -s ( aka swapinfo ), and pstat -ss will > dump the radix tree. > > One thing I haven't been able to test, because I forgot: Interleaved > swap ( more then one swap device ). I'll try to test that ASAP. Please let us know when you've done it. I think I'll hold off until then. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: KLD naming
On Wed, 20 Jan 1999, Mike Smith wrote: > I guess it depends on how fancy we want to get. Here are some examples > that I've been rolling around; some are fanciful, some practical) > > dev_generic device (eg. dev_sio) > bus_bus support (eg. bus_pci) > netif_ network interface (eg. netif_ed) > netproto_ network protocol (eg. netproto_arp) > netdomain_ network domain (eg. netdomain_ip) > vfs_VFS layer (eg. vfs_nfs) > kern_ kernel infrastructure (eg. kern_vfs) > syscall_loadable system calls (eg. syscall_sendfile) > > I don't think we want to make the mistake of being too specific about > what pigeonhole something falls into. In many cases, we might want new > categories when a new case arises, eg. for USB we might have: > > bus_usb.ko > usb_hub.ko > usb_mouse.ko > usb_keyboard.ko > usb_disk.ko > usb_scanner.ko > ... > > There's no ambiguity here, the names are simple and convey a direct > set of relationships. Your examples (except the first) do a pretty > good job of the same thing. This is good. As far as I'm concerned, we should go with this. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: New version of Vinum
On Thursday, 21 January 1999 at 0:24:24 -0800, Chris Knight wrote: > At 02:13 PM 1/21/99 +1030, you wrote: >> I've just committed a new version of Vinum with a large number of >> changes. It works fine here, much better than the old version, but >> there's just a possibility that things may go wrong. If you have >> trouble, please let me know immediately. > > Greg, > > Was this just committed to -current, or is this also in -stable (now that > it exists)? It was committed to the tree minutes before the tagging, so currently both branches have the same content. > I'd like to move to -stable, but if the latest Vinum mods are going to > take a while to move to -current I'll be staying here for the duration. :) Well, it's more like the other way round: the changes go to -current first, and then move to -stable. You can expect a number of changes in both versions in the next few weeks. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Heads up! New swapper and VM changes being committed to -4.x tonight.
On Wed, 20 Jan 1999, Matthew Dillon wrote: > The new swapper and a bunch of VM stuff I've been sitting > on is going to be committed into the new -current tree tonight. I'm more than willing to test it in low memory conditions.. :-) I have that special 386SX/4MB RAM machine in the corner to test things like picobsd memory requirements... Andrzej Bialecki ++---++ - ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+---+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| |http://www.freebsd.org/~picobsd/ ~-+==---+-+ - To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Experiences with aout-to-elf and new bootblocks
Peter Jeremy wrote: > > tutorial: http://www.freebsd.org/~peter/elfday.html). I found that > /boot/loader could load my 2.x kernel (although it happily handled ^^ You mean "could not", right? > [gzip'd] -current kernels in both a.out and ELF format). The stage2 > loader boot: prompt happily loaded the 2.x kernel. When /boot/loader > tries to load my 2.x kernel, the screen displays gibberish and the > system locks up (hard reset needed). Any ideas on this one? Is it kzipped, your 2.x kernel? (Is there any detail about it that you think it is not relevant? :-) > Finally, whilst I can happily load a 3.x kernel from my 2nd HD, > the kernel is confused about where it's loading from: It can't > find root and panics. > > System details: PII-266 with IDE disks: > primary master: wd0: dualboot (W95/FreeBSD 2.x) > primary slave:ATAPI cdrom > secondary master: wd2: FreeBSD 3.0 (not dangerously dedicated) > secondary slave: not present > > Both the 2.x and -current kernels correctly recognize both disks > during the probes. When I try to boot from wd2a, the kernel > reports: > changing root device to wd1s1a > changing root device to wd1a > error 6: panic cannot mount root(2) > > If I recall correctly, the problem here is that the BIOS is reporting > the 2 HDs as 0 and 1, rather than 0 and 2. I can't recall what the > work-around is (I'd prefer not to juggle the disks). Any suggestions? Well, kind of. You "hard code" the name wd2 in your kernel configuration file. Loader assigns numbers sequentially. Either we teach loader to hard code names (which is probably an excellent idea), or you assign names to your hd following loader's logic. Ie, s/wd2/wd1/ in your kernel configuration file (and rebuild :). BTW, what *devfs* would call that second drive, anyone? I suspect this "hard coding" might not be... healthy... -- Daniel C. Sobral(8-DCS) d...@newsguy.com If you sell your soul to the Devil and all you get is an MCSE from it, you haven't gotten market rate. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Experiences with aout-to-elf and new bootblocks
On Thu, 21 Jan 1999 18:21:45 +0900, "Daniel C. Sobral" wrote: > Well, kind of. You "hard code" the name wd2 in your kernel > configuration file. Loader assigns numbers sequentially. FWIW, I've never seen FreeBSD boot off a drive on the secondary IDE controller using a boot manager on the primary. I haven't tried with CURRENT. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Experiences with aout-to-elf and new bootblocks
FWIW, I've done it under 2.2.7 by 1) installing booteasy on both wd0 *AND* wd2 2) altering the boot.config to 1:wd(2,a)kernel 3) compiling above kernel with config kernel root on wd2 Mark In message <74039.916912...@axl.noc.iafrica.com>, Sheldon Hearn writes: > > >On Thu, 21 Jan 1999 18:21:45 +0900, "Daniel C. Sobral" wrote: > >> Well, kind of. You "hard code" the name wd2 in your kernel >> configuration file. Loader assigns numbers sequentially. > >FWIW, I've never seen FreeBSD boot off a drive on the secondary IDE >controller using a boot manager on the primary. I haven't tried with >CURRENT. > >Ciao, >Sheldon. > >To Unsubscribe: send mail to majord...@freebsd.org >with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: KLD naming
> -Original Message- > From: Julian Elischer [mailto:jul...@whistle.com] > Sent: Thursday, January 21, 1999 7:58 AM > To: Mike Smith > Cc: Christian Kuhtz; David O'Brien; curr...@freebsd.org > Subject: Re: KLD naming > > > well you're about to get your first test > we are releasing the netgrpah code in full production form tonigh (if > the version we've put together for release passes all tests tonight) > The whole thing installs as KLD modules (or linked in of course) > > our present names are all predicated with ng_ > hence ng_socket ng_rfc1490, ng_frame_relay etc > the base module is 'netgraph'. > > now what would you suggest? > we can still cahnge it before we release and no-body knows > any better but > after is always harder to change than beefore.. Why not have a third party identifier on the front, e.g. whistle_ng_rfc1490 You can determine your own naming scheme then and if we make this standard then it will ensure that third party supplied modules don't result in name space conflicts. It's perfectly feasible in the future that different companies might produce competing modules for subsystems, sound for example, so we might as well deal with this possibility now. Makes it easier to identify the source of the modules as well. Perhaps we should adopt a FreeBSD prefix on core modules so you can see from ls what's part of the OS and what's been added in from elsewhere. Although I'm in favour of this naming scheme over directories you can reach the point where the names are holding too much metainformation that really should be directory structure. There wouldn't be need for directories at all if you put the structure in the filename :-) Paul. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Make world dies on 3.0 STABLE
I just csvup'ed the sources...(I had the sources from January 12's snapshot). While trying to do a "make world", eventually I get this message. c++ -pg -I/usr/obj/usr/src/tmp/usr/include/g++ -nostdinc -O -pipe -I/usr/src/gnu /lib/libstdc++/../../../contrib/libg++/include -I/usr/obj/usr/src/tmp/usr/includ e/g++ -I. -I/usr/obj/usr/src/tmp/usr/include -I/usr/src/gnu/lib/libstdc++/../../ ../contrib/libg++/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/libg++/l ibio -I/usr/src/gnu/lib/libstdc++/../../../contrib/libg++/libstdc++ -fno-implici t-templates -c /usr/src/gnu/lib/libstdc++/../../../contrib/libg++/libio/fstream. cc -o fstream.po /usr/obj/usr/src/tmp/usr/include/g++/streambuf.h: In method `void ios::clear(int = 0)': In file included from /usr/obj/usr/src/tmp/usr/include/g++/iostream.h:31, from /usr/obj/usr/src/tmp/usr/include/g++/fstream.h:30, from /usr/src/gnu/lib/libstdc++/../../../contrib/libg++/libio/f stream.cc:34: /usr/obj/usr/src/tmp/usr/include/g++/streambuf.h:202: `_strbuf' undeclared (firs t use this function) /usr/obj/usr/src/tmp/usr/include/g++/streambuf.h:202: (Each undeclared identifie r is reported only once /usr/obj/usr/src/tmp/usr/include/g++/streambuf.h:202: for each function it appea rs in.) /usr/obj/usr/src/tmp/usr/include/g++/streambuf.h: In method `class streambuf * i os::rdbuf() const': /usr/obj/usr/src/tmp/usr/include/g++/streambuf.h:220: `_strbuf' undeclared (firs t use this function) /usr/obj/usr/src/tmp/usr/include/g++/streambuf.h: In method `class streambuf * i os::rdbuf(class streambuf *)': /usr/obj/usr/src/tmp/usr/include/g++/streambuf.h:222: `_strbuf' undeclared (firs t use this function) /usr/obj/usr/src/tmp/usr/include/g++/streambuf.h: In method `void ios::init(stru ct streambuf *, class ostream * = 0)': /usr/obj/usr/src/tmp/usr/include/g++/streambuf.h:458: `_strbuf' undeclared (firs t use this function) /usr/obj/usr/src/tmp/usr/include/g++/iostream.h: In method `class ostream & ostr eam::put(char)': In file included from /usr/obj/usr/src/tmp/usr/include/g++/fstream.h:30, from /usr/src/gnu/lib/libstdc++/../../../contrib/libg++/libio/f stream.cc:34: /usr/obj/usr/src/tmp/usr/include/g++/iostream.h:56: `_strbuf' undeclared (first use this function) /usr/obj/usr/src/tmp/usr/include/g++/iostream.h: In method `struct streambuf * o stream::ostreambuf() const': /usr/obj/usr/src/tmp/usr/include/g++/iostream.h:104: `_strbuf' undeclared (first use this function) /usr/obj/usr/src/tmp/usr/include/g++/iostream.h: In method `int istream::get()': /usr/obj/usr/src/tmp/usr/include/g++/iostream.h:165: `_strbuf' undeclared (first use this function) /usr/obj/usr/src/tmp/usr/include/g++/iostream.h: In method `class istream & istr eam::putback(char)': /usr/obj/usr/src/tmp/usr/include/g++/iostream.h:177: `_strbuf' undeclared (first use this function) /usr/obj/usr/src/tmp/usr/include/g++/iostream.h: In method `class istream & istr eam::unget()': /usr/obj/usr/src/tmp/usr/include/g++/iostream.h:180: `_strbuf' undeclared (first use this function) /usr/obj/usr/src/tmp/usr/include/g++/iostream.h: In method `struct streambuf * i stream::istreambuf() const': /usr/obj/usr/src/tmp/usr/include/g++/iostream.h:187: `_strbuf' undeclared (first use this function) *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. and then dies! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
NFS v3 issue
With NFS v3 there seem still to be some open issues. Im running the latest (4.0)-current with the new vm/NFS changes. While I haven't found any problems with NFSv2 so far, v3 still seems to make trouble. I noticed the error some months ago, while my /usr/obj was NFS mounted, and a build failed while making termcap.db. Today, I gave it another try. I copied /usr/src/share/termcap into an NFS mounted directory and did a "make". I compared the output of termcap.db with the one build on the local drive. While the NFS mounted one was only 1077760 bytes in size, the correct size (from the local build) should be 1245184 bytes. I did the build several times, everytime I got the same values. I then remounted the direcory NFSv2. Now the build produced the right file (in size and content). The NFS Server is a Solaris 7 machine. Can anyone else confirm this error? Daniel To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Promise FastTrack PCI IDE controller
I've been playing with a Promise FastTrack RAID (IDE) controller with 3.0-current as of yesterday. Although it is recognised in the PCI bus probe as a "Promise Ultra/33" (it has the same vendor/chip ID as the non-RAID card), the probes in i386/isa/wd.c fail. I added some debugging printfs to the code, and have found that wdreset() is failing. By changing the code to ignore that failure, it gets further, and correctly identifies the attached disks. I can even access the disks sufficiently to read the partition table with fdisk (but with timeouts). I've included some information from a verbose boot, and the debugging printfs I added. I don't have any programming docs for this hardware, and I don't know much about IDE controllers at this level. If anyone has any suggestions of where I might look for the problems, they'd be most welcome. FWIW, the IDE driver in Linux (2.0.35) handles the card OK. FreeBSD 3.0-CURRENT #11: Thu Jan 21 17:28:17 EST 1999 ... ide_pci1: rev 0x01 int a irq 11 on pci0.18.0 ide_pci1: adding drives to controller 2: 4 5using shared irq11. 6 7 promise_status: port0: 0xeff0, port0_alt: 0xefe4, port1: 0xefa8, port1_alt: 0xefe0 promise_status: dma control blk address: 0xef80, int: 1, irq: 11 drivebits0-1: 4249f4 drivetiming0: pa: 0x4, pb: 0x9, mb: 0x2, mc: 0x2 drivetiming1: pa: 0x4, pb: 0x13, mb: 0x7, mc: 0xf drivebits2-3: 4249f4 drivetiming2: pa: 0x4, pb: 0x9, mb: 0x2, mc: 0x2 drivetiming3: pa: 0x4, pb: 0x13, mb: 0x7, mc: 0xf promise_status: port0: 0xeff0, port0_alt: 0xefe4, port1: 0xefa8, port1_alt: 0xefe0 promise_status: dma control blk address: 0xef80, int: 1, irq: 11 drivebits0-1: 4249f4 drivetiming0: pa: 0x4, pb: 0x9, mb: 0x2, mc: 0x2 drivetiming1: pa: 0x4, pb: 0x13, mb: 0x7, mc: 0xf drivebits2-3: 4249f4 drivetiming2: pa: 0x4, pb: 0x9, mb: 0x2, mc: 0x2 drivetiming3: pa: 0x4, pb: 0x13, mb: 0x7, mc: 0xf ide_pci: busmaster 0 status: 04 from port: ef82 promise_status: port0: 0xeff0, port0_alt: 0xefe4, port1: 0xefa8, port1_alt: 0xefe0 promise_status: dma control blk address: 0xef80, int: 1, irq: 11 drivebits0-1: 4249f4 drivetiming0: pa: 0x4, pb: 0x9, mb: 0x2, mc: 0x2 drivetiming1: pa: 0x4, pb: 0x13, mb: 0x7, mc: 0xf drivebits2-3: 4249f4 drivetiming2: pa: 0x4, pb: 0x9, mb: 0x2, mc: 0x2 drivetiming3: pa: 0x4, pb: 0x13, mb: 0x7, mc: 0xf promise_status: port0: 0xeff0, port0_alt: 0xefe4, port1: 0xefa8, port1_alt: 0xefe0 promise_status: dma control blk address: 0xef80, int: 1, irq: 11 drivebits0-1: 4249f4 drivetiming0: pa: 0x4, pb: 0x9, mb: 0x2, mc: 0x2 drivetiming1: pa: 0x4, pb: 0x13, mb: 0x7, mc: 0xf drivebits2-3: 4249f4 drivetiming2: pa: 0x4, pb: 0x9, mb: 0x2, mc: 0x2 drivetiming3: pa: 0x4, pb: 0x13, mb: 0x7, mc: 0xf ide_pci: busmaster 1 status: 04 from port: ef8a ... wdc2: wdd_candma is set for ide_pci1 wdc2: I/O to 0xeff0 does work wdc2: reset failed wdc2: wd_cyl for master is 63397 (0xf7a5) wdc2: wd_cyl for slave is 63397 (0xf7a5) wdc2: second reset failed wdc2: controller only command OK wdc2 at 0xeff0-0xeff7 flags 0xa0ffa0ff on isa ide_pci: generic_dmainit eff0:0: warning, IDE controller timing not set wd4: wdsetmode() setting transfer mode to 22 wd(2,0): wdgetctlr: gc 45a cyl 16383 trk 16 sec 63 type 3 sz 924 model IBM-DTTA-351680 wdc2: unit 0 (wd4): , DMA, 32-bit, multi-block-16 wd4: 16124MB (33022080 sectors), 32760 cyls, 16 heads, 63 S/T, 512 B/S wd4: ATA INQUIRE valid = 0007, dmamword = 0007, apio = 0003, udma = 0207 wdc3: wdd_candma is set for ide_pci1 wdc3: I/O to 0xefa8 does work wdc3: reset failed wdc3: wd_cyl for master is 63397 (0xf7a5) wdc3: wd_cyl for slave is 63397 (0xf7a5) wdc3: second reset failed wdc3: controller only command OK wdc3 at 0xefa8-0xefaf flags 0xa0ffa0ff on isa ide_pci: generic_dmainit efa8:0: warning, IDE controller timing not set wd6: wdsetmode() setting transfer mode to 22 wd(3,0): wdgetctlr: gc 45a cyl 16383 trk 16 sec 63 type 3 sz 924 model IBM-DTTA-351680 wdc3: unit 0 (wd6): , DMA, 32-bit, multi-block-16 wd6: 16124MB (33022080 sectors), 32760 cyls, 16 heads, 63 S/T, 512 B/S wd6: ATA INQUIRE valid = 0007, dmamword = 0007, apio = 0003, udma = 0207 at this point, run 'fdisk wd4' wd(2,0): wdsetctlr: C 32760 H 16 S 63 wd4: interrupt timeout (status 50 error 0) wd4: wdtimeout() DMA status 1 wd4: wdunwedge failed (status 50 error 0) wd4s1: type 0x6, start 63, end = 96389, size 96327 : OK wd(2,0): wdsetctlr: C 32760 H 16 S 63 wd4: interrupt timeout (status 50 error 0) wd4: wdtimeout() DMA status 1 wd4: wdunwedge failed (status 50 error 0) wd4: interrupt timeout (status 50 error 0) wd4: wdtimeout() DMA status 1 wd4: wdunwedge failed (status 50 error 0) at this point, run 'fdisk wd6' wd(3,0): wdsetctlr: C 32760 H 16 S 63 wd6: DMA failure, DMA status 0 wd6s1: type 0x6, start 63, end = 96389, size 96327 : OK wd(3,0): wdsetctlr: C 32760 H 16 S 63 wd6: DMA failure, DMA status 0 wd6: interrupt timeout (status 50 error 0) wd6: wdtimeout() DMA status 1 wd6: wdunwedge failed (status 58 error 0) David To Unsubscribe: send ma
Re: Promise FastTrack PCI IDE controller
It seems David Dawes wrote:
> I've been playing with a Promise FastTrack RAID (IDE) controller with
> 3.0-current as of yesterday. Although it is recognised in the PCI bus
> probe as a "Promise Ultra/33" (it has the same vendor/chip ID as the
> non-RAID card), the probes in i386/isa/wd.c fail. I added some debugging
> printfs to the code, and have found that wdreset() is failing. By
> changing the code to ignore that failure, it gets further, and correctly
> identifies the attached disks. I can even access the disks sufficiently
> to read the partition table with fdisk (but with timeouts).
Hmm, I run one of my systems with the Ultra/33, but with the following
patch, without that it wont recognise a lone CDROM/TAPE, but requires
a disk to be present. It also includes some other patches, including
a fix for SMP system which Julian broke in rev1.183 of wd.c.
I also run the card without its BIOS, as that tends to get in the way.
I think the FastTrack is just an Ultra/33 with another BIOS chip on it.
- Søren
Index: wd.c
===
RCS file: /home/ncvs/src/sys/i386/isa/wd.c,v
retrieving revision 1.186
diff -u -r1.186 wd.c
--- wd.c1999/01/17 05:46:24 1.186
+++ wd.c1999/01/19 18:29:23
@@ -350,9 +350,11 @@
goto reset_ok;
#endif
DELAY(RECOVERYTIME);
+/* Allow atapi only channels to work proberly SOS
if (wdreset(du) != 0) {
goto nodevice;
}
+*/
reset_ok:
/* execute a controller only command */
@@ -1084,10 +1086,11 @@
du = wddrives[dkunit(bp->b_dev)];
/* finish off DMA */
- if (du->dk_flags & (DKFL_DMA|DKFL_USEDMA)) {
+ if ((du->dk_flags & (DKFL_DMA|DKFL_SINGLE)) == DKFL_DMA) {
/* XXX SMP boxes sometimes generate an early intr. Why? */
- if ((wddma[du->dk_interface].wdd_dmastatus(du->dk_dmacookie) &
WDDS_INTERRUPT)
- != 0)
+ if ((wddma[du->dk_interface].wdd_dmastatus(du->dk_dmacookie) &
+ WDDS_INTERRUPT) == 0)
+ return;
dmastat = wddma[du->dk_interface].wdd_dmadone(du->dk_dmacookie);
}
@@ -1568,6 +1571,7 @@
if (wdwait(du, 0, TIMEOUT) < 0)
return (1);
if( command == WDCC_FEATURES) {
+ outb(wdc + wd_sdh, WDSD_IBM | (du->dk_unit << 4) | head);
outb(wdc + wd_features, count);
if ( count == WDFEA_SETXFER )
outb(wdc + wd_seccnt, sector);
@@ -2289,9 +2293,8 @@
{
int err = 0;
- if ((du->dk_flags & (DKFL_DMA|DKFL_USEDMA)) && du->dk_dmacookie)
+ if ((du->dk_flags & (DKFL_DMA|DKFL_SINGLE)) == DKFL_DMA)
wddma[du->dk_interface].wdd_dmadone(du->dk_dmacookie);
-
(void)wdwait(du, 0, TIMEOUT);
outb(du->dk_altport, WDCTL_IDS | WDCTL_RST);
DELAY(10 * 1000);
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: Promise FastTrack PCI IDE controller
On Thu, Jan 21, 1999 at 01:21:03PM +0100, Søren Schmidt wrote: >It seems David Dawes wrote: >> I've been playing with a Promise FastTrack RAID (IDE) controller with >> 3.0-current as of yesterday. Although it is recognised in the PCI bus >> probe as a "Promise Ultra/33" (it has the same vendor/chip ID as the >> non-RAID card), the probes in i386/isa/wd.c fail. I added some debugging >> printfs to the code, and have found that wdreset() is failing. By >> changing the code to ignore that failure, it gets further, and correctly >> identifies the attached disks. I can even access the disks sufficiently >> to read the partition table with fdisk (but with timeouts). > >Hmm, I run one of my systems with the Ultra/33, but with the following >patch, without that it wont recognise a lone CDROM/TAPE, but requires >a disk to be present. It also includes some other patches, including >a fix for SMP system which Julian broke in rev1.183 of wd.c. That didn't improve things, but with the patch I got lots of messages like the following (for a disk attached to the onboard PIIX4): wd1: DMA failure, DMA status 0 (The box isn't SMP.) >I also run the card without its BIOS, as that tends to get in the way. >I think the FastTrack is just an Ultra/33 with another BIOS chip on it. I'll try pulling the BIOS tomorrow. We didn't get this card for it's RAID features anyway. Thanks. David To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Promise FastTrack PCI IDE controller
It seems David Dawes wrote:
>
> That didn't improve things, but with the patch I got lots of messages
> like the following (for a disk attached to the onboard PIIX4):
>
> wd1: DMA failure, DMA status 0
>
> (The box isn't SMP.)
Hmm, and it is an uptodate -current system ??
Just use this part then:
Index: wd.c
===
RCS file: /home/ncvs/src/sys/i386/isa/wd.c,v
retrieving revision 1.186
diff -u -r1.186 wd.c
--- wd.c1999/01/17 05:46:24 1.186
+++ wd.c1999/01/19 18:29:23
@@ -350,9 +350,11 @@
goto reset_ok;
#endif
DELAY(RECOVERYTIME);
+/* Allow atapi only channels to work proberly SOS
if (wdreset(du) != 0) {
goto nodevice;
}
+*/
reset_ok:
/* execute a controller only command */
> >I also run the card without its BIOS, as that tends to get in the way.
> >I think the FastTrack is just an Ultra/33 with another BIOS chip on it.
>
> I'll try pulling the BIOS tomorrow. We didn't get this card for it's
> RAID features anyway.
That helped me in a lot if situations, but performance wont be as good
as we seem not to initialize the chip(s)...
I have the specsheets somewhere if anybody is interested...
- Søren
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Spontaneous system freezes
I'm trying to get 3.0-RELEASE to run as stable as possible on a PII with aic7895 onboard scsi controller. my dmesg output is: Timecounter "i8254" frequency 1193182 Hz cost 3126 ns Timecounter "TSC" frequency 349069134 Hz cost 140 ns CPU: Pentium II (quarter-micron) (349.07-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping=2 Features=0x183fbff> real memory = 134217728 (131072K bytes) avail memory = 127844352 (124848K bytes) Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 chip1: rev 0x02 on pci0.1.0 chip2: rev 0x02 on pci0.7.0 chip3: rev 0x01 int d irq 11 on pci0.7.2 chip4: rev 0x02 on pci0.7.3 vga0: rev 0x3a int a irq 255 on pci0.8.0 de0: rev 0x20 int a irq 10 on pci0.10.0 de0: 21140A [10-100Mb/s] pass 2.0 de0: address 00:48:54:00:07:b1 ahc0: rev 0x04 int a irq 5 on pci0.12.0 ahc0: aic7895 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: rev 0x04 int b irq 5 on pci0.12.1 ahc1: Using left over BIOS settings ahc1: aic7895 Wide Channel B, SCSI Id=7, 16/255 SCBs Probing for devices on PCI bus 1: 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 flags 0x10 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 psm0 at 0x60-0x64 irq 12 on motherboard psm0: model Generic PS/2 mouse, device ID 0 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 Waiting 15 seconds for SCSI devices to settle sa0 at ahc0 bus 0 target 5 lun 0 sa0: Removable Sequential Access SCSI2 device sa0: 3.300MB/s transfers da4 at ahc1 bus 0 target 2 lun 0 da4: Fixed Direct Access SCSI2 device da4: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled da4: 4340MB (924 512 byte sectors: 64H 32S/T 4340C) da5 at ahc1 bus 0 target 3 lun 0 da5: Fixed Direct Access SCSI2 device da5: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled da5: 4340MB (924 512 byte sectors: 64H 32S/T 4340C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI2 device da0: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI2 device da1: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) changing root device to da0s1a I'm having spontaneous freezes whenever I compile anything, be it a kernel build or a port install. Beeing more specific, it's a total system freeze. Nothing on the console (have DDB in the kernel), no response to pings, and total keyboard freeze. Can anyone shed any light on this? tia M Ferreira To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Changes to pam_kerberosIV broke ftpd
It appears that revision 1.9 of lib/libpam/modules/pam_kerberosIV/klogin.c and revision 1.3 of lib/libpam/modules/pam_kerberosIV/pam_kerberosIV.c broke ftpd when compiling with MAKE_KERBEROS defined. The errors I get when compiling with 4.0-current sources (and presumably 3.0-stable though I haven't tried compiling that yet) cvsup'd last night at about 11:00 pm CST are: ===> libexec/ftpd [...] cc -O -pipe -DSETPROCTITLE -DSKEY -DLOGIN_CAP -DVIRTUAL_HOSTING -Wall -I/usr/src/libexec/ftpd/../../contrib-crypto/telnet -DKERBEROS -I/usr/obj/usr/src/tmp/usr/include -o ftpd ftpd.o ftpcmd.o logwtmp.o popen.o skey-stuff.o klogin.o -lskey -lmd -lcrypt -lutil -lkrb -ldes ftpd.o: In function `pass': ftpd.o(.text+0x11c9): undefined reference to `klogin' klogin.o: In function `_pam_klogin': klogin.o(.text+0x3e): undefined reference to `_pam_noticketsdontcomplain' klogin.o(.text+0xd2): undefined reference to `_pam_krbtkfile_env' klogin.o(.text+0x1a3): undefined reference to `_pam_notickets' This could be the case for other Kerberized programs, but this is as far as my 'make world' got. -Patrick Patrick L. Hartling | Research Assistant, ICEMT myst...@friley-184-92.res.iastate.edu | Carver Lab - 0095E Black Engineering http://www.public.iastate.edu/~oz/ | http://www.icemt.iastate.edu/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: KLD naming
On Thu, Jan 21, 1999 at 09:34:28AM +, Doug Rabson wrote: > On Wed, 20 Jan 1999, Mike Smith wrote: > > > I guess it depends on how fancy we want to get. Here are some examples > > that I've been rolling around; some are fanciful, some practical) > > > > dev_generic device (eg. dev_sio) > > bus_bus support (eg. bus_pci) > > netif_ network interface (eg. netif_ed) > > netproto_ network protocol (eg. netproto_arp) > > netdomain_ network domain (eg. netdomain_ip) How is the difference between netproto & netdomain defined? I'm running into a case where I can easily turn the stack upside down (say, running frame-relay over IP over MPLS in an IP tunnel over PPP -- that's almost working actually). It sounds like netdomain is somehow higher up in the stack than netproto.. even though they're all protocols. Comments? Cheers, Chris -- "Logic is a little bird, sitting in a tree; that smells *awful*." -- /usr/bin/fortune [Disclaimer: I speak for myself and my views are my own and not in any way to be construed as the views of BellSouth Corporation. ] To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: make release produces unbootable boot floppies, no boot loader, no /kernel
>From: "John W. DeBoskey" >Date: Thu, 21 Jan 1999 00:54:36 -0500 (EST) > If you really want to make things easier for the beginner, why >not provide a DOS boot program. Then you wouldn't even have to >worry about boot floppies. Tell new folks to copy the boot program >to the DOS partition and run it from DOS. Case closed. No boot >floppy required. I can imagine half a dozen ways to make this work. Although I'll cheerfully admit that I'm probably in the minority in this respect, such an approach would do me not one whit of good, since, given a desired objective, I have no idea how to make MS-DOS accomplish it. (I'm coming at FreeBSD with no background in PCs at all, about 12+ years working with UNIX, about 12 years as an IBM mainframe (MVS) systems programmer, and some years before that of various other types of systems. In my (somewhat limited) experience, when I've tried to use MS-DOS for anything, more than half the time either the application or the machine would hang or crash; thus, I'd be hard-pressed to advocate reliance upon that mechanism for anything of perceived importance.) Cheers, david -- David Wolfskill UNIX System Administrator d...@whistle.comvoice: (650) 577-7158 pager: (650) 371-4621 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: /etc/nsswitch.conf
Yes, indeed, I have looked at nsd in Irix 6.5 and I like it. What Irix does well, Irix does very well (save a couple of PRs I have filed with SGI of course ;). -- David Cross To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
mountd
I posted this awhile ago to -questions, but never received a reply. We have a number of FreeBSD NFS servers here. Occasionally we need to change the exports list on the servers and send mountd a SIGHUP. This leads to a condition that in many ways is much worse than a server reboot. What happens is for the duration of mountd reading the exports file it denies all NFS requests. This has a number of bad effects; 1) any user home and system directories become unavailable, with the error 'permission denied' 2) (and this is far worse), any process with a mapped .text segment off of the NFS server, should it branch to code not in the cache gets immediately killed. This include user processes that are running from home directories, and system processes (such as ssh). If we were to reboot the machine it would just hang those connections until the machine came back, without killing anyone. Is there a solution to this problem? I know that none of HP-UX, IRIX, or Solaris have this problem. -- David Cross To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
keymaps
I recently looked at keymaps in /usr/share/syscons/keymaps and found many minor errors. In addition to that, there is so much inconsistency among existing keymaps. True that national keyboards have different layout of regular keys (alphanumeric keys and symbol keys). But, it is absurd that functions keys and special keys are handled in so many different ways. The syscons keymap can assign special functions to key strokes, such as `suspend', `next virtual screen'. However, some keymaps don't have these special functions assigned to any key strokes. The other keymaps may have them but assign them differently. There is no standard here. So, I would propose the following key assignment to be the standard from now on. I compiled this list based on existing keymaps and recent input from a contributer (thanks, J M Alcaide!) If this assignment is not desirable for some keymaps, such as Russian and Dvorak maps which are rather unique, they may be made exceptions. But, unless there is a good reason to make other exceptions, I will modify the other national keymaps to adapt these key assignments. Any comments? I am open to suggestions. Kazu * 101/102/104 Enhanced Keyboard support Key CodeKey Stroke Function - 1 Ctrl-Alt-EscEnter DDB (debug). 57 Ctrl-Alt-Space Suspend (susp). 70 ScrollLock Backscroll (slock). 84 Alt-SysRq(PrintScreen) - (nop) 92 PrintScreen Switch to the next vty (next). 104 Pause Start screen saver (saver). 104 Alt-Pause Suspend (susp). 105 Left Windowsfkey62 106 Right Windows fkey63 107 Menufkey64 108 Ctrl-Break(Pause) Enter DDB (debug). The separate SysRq key doesn't exist on the enhanced keyboard. It is combined with the PrintScreen key. The SysRq code is generated when the Alt and the PrintScreen keys are pressed together. The separate Break key doesn't exist on the enhanced keyboard. It is combined with the Pause key. The Break code is generated when the Ctrl and the Pause keys are pressed together. The above assignments for the keycodes 1, 57, 70, 84 and 92 are compatible with many, if not all, existing keymaps. The assignments for 104 and 108 are new. Many keymaps lacks entries for 105 through 107. * 84 Keyboard support Key CodeKey Stroke Function - 1 Ctrl-Alt-EscEnter DDB (debug). 57 Ctrl-Alt-Space Suspend (susp). 70 ScrollLock Backscroll (slock). 84 SysRq - (nop) 92 Shift-PrintScreen(*)Switch to the next vty (next). 104 Ctrl-Pause(NumLock) Start screen saver (saver). 104 Ctrl-Alt-Pause(NumLock) Suspend (susp). 108 Ctrl-Break(ScrollLock) Enter DDB (debug). The separate PrintScreen key doesn't exist on the 84 keyboard. It is combined with the numpad * key. The PrintScreen code is generated when the Shift and the numpad * keys are pressed together. The separate Pause key doesn't exist on the 84 keyboard. It is combined with the NumLock key. The Pause code is generated when the Ctrl and the NumlLock keys are pressed together. The separate Break key doesn't exist on the 84 keyboard. It is combined with the ScrollLock key. The Break code is generated when the Ctrl and the ScrollLock keys are pressed together. * Proposed keymap Combining the support for the 84 keyboard and the enhanced keyboard described above, we will get the following keymap entries. alt ctrlalt alt ctrl code base shift ctrl shift alt shift ctrl shift - 1 esc esc esc esc esc esc debug esc 57 ' ' ' ' null ' ' ' ' ' ' susp ' ' 70 slock slock slock slock slock slock slock slock 84 nop nop nop nop nop nop nop nop 92 next next nop nop nop nop nop nop 104 saver nop saver nop susp nop susp nop 105 nop nop nop nop nop nop nop nop 106 nop nop nop nop nop nop nop nop 107 nop nop nop nop nop nop nop nop 108 nop nop debug nop nop nop nop nop <> To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Using LinuxThreads
Hi, On Tue, Jan 19, 1999 at 09:11:51AM -0600, Richard Seaman, Jr. wrote: > Actually, the new version, in FreeBSD "ports" form, doesn't require > -DLINUXTHREADS anymore, but it does require -I/usr/local/include to > pick up the right header, since it installs a pthread.h into > /usr/local/include. This conflicts with the pthread.h in /usr/include. This is nagging at me. Having two headers of the same name, but importantly different content is asking for touble. There needs to be a way to ensure that only one or the other is picked up. The best way I can think of is to only include the contents of the user thread pthread.h if _THREAD_SAFE is defined (to force people to use the right defines...) and the contents of kernel thread pthread.h if _REENTRANT (and not _THREAD_SAFE) is defined. This has the added bonus of meaning that most linux apps wont have to be patched. To many applications have configure scripts which might find /usr/local/lib/libpthread, but not /usr/local/include/pthread.h, or find /usr/lib/libc_r and find /usr/local/include/pthread.h. Can gcc be made to define _THREAD_SAFE automatically if -pthread is given? And _REENTRANT if -kthread is given? What are the plans for the import of the LinuxThreads stuff into the src tree? Or is it going to remain a port, and the source tree position be reserved for a future kernel threads implementation? My mind says it is to closely tied to the OS to be a port. And when are COMPAT_LINUX_THREADS and VM_STACK going away? Regards, -Jeremy -- | "In this world of temptation, I will stand for what is right. --+-- With a heart of salvation, I will hold up the light. |If I live or if I die, if I laugh or if I cry, |in this world of temptation, I will stand." -Pam Thum To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: KLD naming
On Thu, 21 Jan 1999 p...@originative.co.uk wrote: > > Why not have a third party identifier on the front, e.g. > > whistle_ng_rfc1490 > > You can determine your own naming scheme then and if we make this > standard then it will ensure that third party supplied modules don't > result in name space conflicts. It's perfectly feasible in the future > that different companies might produce competing modules for subsystems, > sound for example, so we might as well deal with this possibility now. > Makes it easier to identify the source of the modules as well. Perhaps > we should adopt a FreeBSD prefix on core modules so you can see from ls > what's part of the OS and what's been added in from elsewhere. > > Although I'm in favour of this naming scheme over directories you can > reach the point where the names are holding too much metainformation > that really should be directory structure. There wouldn't be need for > directories at all if you put the structure in the filename :-) Well whistle is giving htis away so we don'tthink it should be whistle_xxx any more than the kernel should be UCB/... It occur to me that eventually every single device driver will be a KLD an also a lot of other things besides... there are going to be a LOT of files in /modules > > Paul. > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: keymaps
Kazutaka YOKOTA wrote: > > * 101/102/104 Enhanced Keyboard support > > Key CodeKey Stroke Function > - > 1 Ctrl-Alt-EscEnter DDB (debug). > 57 Ctrl-Alt-Space Suspend (susp). > 70 ScrollLock Backscroll (slock). > 84 Alt-SysRq(PrintScreen) - (nop) > 92 PrintScreen Switch to the next vty (next). > 104 Pause Start screen saver (saver). > 104 Alt-Pause Suspend (susp). > 105 Left Windowsfkey62 > 106 Right Windows fkey63 > 107 Menufkey64 > 108 Ctrl-Break(Pause) Enter DDB (debug). I am afraid of being myself the cause of a keymap revolution!! 8-) As I said in a previous message to freebsd-bugs, I think that mapping the saver to the "base" Pause key could annoy people accustomed to pressing this key to stop the screen output. I would map the [very useful] saver function to Shift-Pause (Shift-Ctrl-NumLock on the 84 KB ?) or, perhaps better, Break (Ctrl-Pause on the 104 KB, Ctrl-ScrollLock on the 84 KB). Another suggestion: I would move the debug function from Break to SysReq (Alt-PrtScr on the 104 KB); I think that associating SysReq to the debugger is intuitive. Then, the now free Break key could be used for the saver function (as suggested above) or, perhaps, the DOS-like "etx" (Ctrl-C) character (I'm supposing the usual stty intr ^C). > * 84 Keyboard support > > Key CodeKey Stroke Function > - > 1 Ctrl-Alt-EscEnter DDB (debug). > 57 Ctrl-Alt-Space Suspend (susp). > 70 ScrollLock Backscroll (slock). > 84 SysRq - (nop) > 92 Shift-PrintScreen(*)Switch to the next vty (next). > 104 Ctrl-Pause(NumLock) Start screen saver (saver). > 104 Ctrl-Alt-Pause(NumLock) Suspend (susp). > 108 Ctrl-Break(ScrollLock) Enter DDB (debug). > > The separate PrintScreen key doesn't exist on the 84 keyboard. It is > combined with the numpad * key. The PrintScreen code is generated > when the Shift and the numpad * keys are pressed together. > > The separate Pause key doesn't exist on the 84 keyboard. It is > combined with the NumLock key. The Pause code is generated when the > Ctrl and the NumlLock keys are pressed together. > > The separate Break key doesn't exist on the 84 keyboard. It is > combined with the ScrollLock key. The Break code is generated when > the Ctrl and the ScrollLock keys are pressed together. > > * Proposed keymap > > Combining the support for the 84 keyboard and the enhanced keyboard > described above, we will get the following keymap entries. > alt > ctrlalt alt ctrl > code base shift ctrl shift alt shift ctrl shift > - > 1 esc esc esc esc esc esc debug esc > 57 ' ' ' ' null ' ' ' ' ' ' susp ' ' > 70 slock slock slock slock slock slock slock slock > 84 nop nop nop nop nop nop nop nop > 92 next next nop nop nop nop nop nop > 104 saver nop saver nop susp nop susp nop > 105 nop nop nop nop nop nop nop nop > 106 nop nop nop nop nop nop nop nop > 107 nop nop nop nop nop nop nop nop > 108 nop nop debug nop nop nop nop nop > There is something I do not understand. Is it possible to generate the Ctrl-Key104 and Alt-Ctrl-Key104 combinations? These are not available on the 104 KB (Ctrl-Pause ==> Break) and, on the 84 KB, Ctrl-NumLock yields the "base" Pause (or Ctrl-Pause?)... Another question: the numpad '*' key (keycode 55) has this mapping in most keymaps: 055 '*''*'nscr nscr '*''*'nscr nscr You told me that the nscr function was needed for the 84 KBD, but now you are saying that, on that KB, the PrtScrn code (92) is generated by Shift-Numpad*. Now I cannot understand the utility of that mapping for the keycode 055... --JMA --- José Mª Alcaide | mailto:j...@we.lc.ehu.es Universidad del PaÃs Vasco | http://www.we.lc.ehu.es/~jose Dpto. de Electricidad y Electrónica | Facultad de Ciencias - Campus de Lejona | Tel.: +34-946012479 48940 Lejona (Vizcaya) - SPAIN | Fax: +34-944858139 --- "Go ahead... make my day." - H. Callahan To Unsubscribe: send mail to majord...@freebsd.org with "unsub
Re: KLD naming
On Thu, 21 Jan 1999, Christian Kuhtz wrote: > On Thu, Jan 21, 1999 at 09:34:28AM +, Doug Rabson wrote: > > On Wed, 20 Jan 1999, Mike Smith wrote: > > > > > I guess it depends on how fancy we want to get. Here are some examples > > > that I've been rolling around; some are fanciful, some practical) > > > > > > dev_generic device (eg. dev_sio) > > > bus_bus support (eg. bus_pci) > > > netif_ network interface (eg. netif_ed) > > > netproto_ network protocol (eg. netproto_arp) > > > netdomain_ network domain (eg. netdomain_ip) > > How is the difference between netproto & netdomain defined? I'm running into > a case where I can easily turn the stack upside down (say, running frame-relay > over IP over MPLS in an IP tunnel over PPP -- that's almost working actually). > > It sounds like netdomain is somehow higher up in the stack than netproto.. > even though they're all protocols. > > Comments? > > Cheers, > Chris > > -- > "Logic is a little bird, sitting in a tree; that smells *awful*." > -- /usr/bin/fortune > > [Disclaimer: I speak for myself and my views are my own and not in any way to > be construed as the views of BellSouth Corporation. ] > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: KLD naming
> -Original Message- > From: Julian Elischer [mailto:jul...@whistle.com] > Sent: Thursday, January 21, 1999 5:39 PM > To: p...@originative.co.uk > Cc: m...@smith.net.au; c...@adsu.bellsouth.com; obr...@nuxi.com; > curr...@freebsd.org > Subject: RE: KLD naming > > Well whistle is giving htis away so we don'tthink it should > be whistle_xxx > any more than the kernel should be UCB/... > It occur to me that eventually every single device driver > will be a KLD > an also a lot of other things besides... > there are going to be a LOT of files in /modules Ok, in this case maybe it doesn't apply but in general we should determine what the guidelines for third party module developers should be to avoid namespace clashes. I though a FreeBSD prefix for modules shipped as part of FreeBSD would be useful to list all those modules that are *not* third party supplied when you've got a directory full of the things. Paul. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
KVA/KVM shortages
On tuesday I crashed a machine after it ran out of kvm. (dual PII 400 with 768MB RAM) poking about in the code adding: options "VM_KMEM_SIZE=(24*1024*1024)" options "VM_KMEM_SIZE_MAX=(128*1024*1024)" seems like a good way foward. Is it? -- GeoffB To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
More make release woes
Looks like the Alpha AXP boot floppy has bitten the dust also: Making the regular boot floppy. Compressing doc files... disklabel: ioctl DIOCWLABEL: Operation not supported by device Warning: Block size restricts cylinders per group to 4. Warning: 2880 sector(s) in last cylinder unallocated /dev/rvn0c: 2880 sectors in 1 cylinders of 1 tracks, 5760 sectors 1.4MB in 1 cyl groups (4 c/g, 11.25MB/g, 192 i/g) super-block backups (for fsck -b #) at: 32, cpio: write error: No space left on device *** Error code 1 (ignored) *** Error code 1 Stop. *** Error code 1 Stop. Sigh. Oh well. I was hoping to get a SNAP out with all the changes Matt did. Guess not. Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
SCSI errors from IBM Netfinity 3500
I'm getting a lot of these SCSI disk errors from Current as of Sunday with the onboard Adaptec Controler with an IBM netfinity 3500. Can someone tell me if I should worry and/or what they mean? Thanks, ed (da0:ahc0:0:0:0): parity error during Data-In phase. SEQADDR == 0x10e SCSIRATE == 0x88 (da0:ahc0:0:0:0): parity error during Data-In phase. SEQADDR == 0x4f SCSIRATE == 0x88 (da0:ahc0:0:0:0): parity error during Data-In phase. SEQADDR == 0x10f SCSIRATE == 0x88 (da0:ahc0:0:0:0): parity error during Data-In phase. SEQADDR == 0x10e SCSIRATE == 0x88 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Using LinuxThreads
On Thu, Jan 21, 1999 at 06:12:29PM +0200, Jeremy Lea wrote: > On Tue, Jan 19, 1999 at 09:11:51AM -0600, Richard Seaman, Jr. wrote: > > Actually, the new version, in FreeBSD "ports" form, doesn't require > > -DLINUXTHREADS anymore, but it does require -I/usr/local/include to > > pick up the right header, since it installs a pthread.h into > > /usr/local/include. This conflicts with the pthread.h in /usr/include. > > This is nagging at me. Having two headers of the same name, but importantly > different content is asking for touble. There needs to be a way to ensure > that only one or the other is picked up. The best way I can think of is to > only include the contents of the user thread pthread.h if _THREAD_SAFE is > defined (to force people to use the right defines...) and the contents of > kernel thread pthread.h if _REENTRANT (and not _THREAD_SAFE) is defined. > This has the added bonus of meaning that most linux apps wont have to be > patched. Actually, its more complicated than this. Currently, _THREAD_SAFE is a switch for turning on libc_r behaviour when compiling libc_r, but it is a switch for more general thread safe behaviour in the header files for libc and libc_r. In other words, threaded applications linking against either libc or libc_r should define _THREAD_SAFE. But, when compiling libc, _THREAD_SAFE should be turned off. Very confusing IMHO. Now, on the topic of conflicting pthread.h files, I agree this is a problem. One choice, which I originally implemented, is to fix pthread.h so it pulls in the right data based on a swtich (eg. if LINUXTHREADS is defined, pull in LT headers, else pull in user threads headers). I don't like using _THREAD_SAFE for this test, for the reason mentioned above. And I don't like using _REENTRANT because its so widely used and it could still confure people. The second choice, which is what the current version of the "port" does, is to put the conflicting headers in different directories, and require the application to define the order of the include files to get the right one in. There are proglems either way, and I don't really prefer one over the other. > To many applications have configure scripts which might find > /usr/local/lib/libpthread, but not /usr/local/include/pthread.h, or find > /usr/lib/libc_r and find /usr/local/include/pthread.h. Yes. This is a problem. But, taking glib as an example, and using glib-1.1.13 directly (not the "port", which is kind of messed up for linuxthreads), the following configure script does the right thing: $ CPPFLAGS="-D_THREAD_SAFE -I/usr/local/include" LDFLAGS="-L/usr/local/lib" ./configure --with-threads=posix This isn't that bad, and I think you need to customize your configure scripts (normally) if you're using threads, anyway. > What are the plans for the import of the LinuxThreads stuff into the src > tree? Or is it going to remain a port, and the source tree position be > reserved for a future kernel threads implementation? My mind says it is to > closely tied to the OS to be a port. It can be a port. I suspect there will be more support for its possible inclusion this way. The current version at lt.tar.com is in ports form. Granted, it depends to an unusual degree (for a port) on having the src tree around. > And when are COMPAT_LINUX_THREADS and VM_STACK going away? I have no idea. I was hoping that at least COMPAT_LINUX_THREADS would go away before the branch. I don't have commit authority, so it isn't up to me. -- Richard Seamman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: keymaps
Kazutaka YOKOTA wrote: : > 104 Pause Start screen saver (saver). : > The above assignments for the keycodes 1, 57, 70, 84 and 92 are > compatible with many, if not all, existing keymaps. So far so good! > The assignments for 104 and 108 are new. 104 (Pause?) does the "Backscroll" on my Libretto 70. I'd hate to lose that. M To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
make world fails -- libcrypt's Makefile?
Current cvsup'd today at 12:08 EST -- make world failed looking for /usr/src/secure/lib/libcrypt/crypt-md5.c. It appears that crypt-md5.c and crypt.3 were moved to /usr/src/lib/libcrypt/ on Thu Jan 21 13:50:09 1999 UTC by brandon, but /usr/src/secure/lib/libcrypt/Makefile still references crypt-md5.c and crypt.3 SRCS= crypt.c crypt-md5.c md5c.c MAN3= crypt.3 -- Regards, Norman C. Rice, Jr. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Heads up! New swapper and VM changes being committed to -4.x tonight.
In message Andrzej Bialecki writes: : I'm more than willing to test it in low memory conditions.. :-) I have : that special 386SX/4MB RAM machine in the corner to test things like : picobsd memory requirements... So how well does this work? I have a 4MB machine that I'd like to run FreeBSD on, including X on a low res screen... Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Mail archive question
Given a message id and a mailing list, is there some way construct a URL that will fetch that mail message. This will make doing the UPDATING file a little easier when long messages are sent to -current. I can say blah blah blah changed, see for details. Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: KLD naming
> > Well whistle is giving htis away so we don'tthink it should > > be whistle_xxx > > any more than the kernel should be UCB/... > > It occur to me that eventually every single device driver > > will be a KLD > > an also a lot of other things besides... > > there are going to be a LOT of files in /modules > > Ok, in this case maybe it doesn't apply but in general we should > determine what the guidelines for third party module developers should > be to avoid namespace clashes. I though a FreeBSD prefix for modules > shipped as part of FreeBSD would be useful to list all those modules > that are *not* third party supplied when you've got a directory full of > the things. I've thought about this, and I think it would be a very bad idea. We want to keep this *simple*. In the case of, eg. OSS, one might expect: dev_oss.ko oss_yamaha.ko oss_sb16.ko ... There's no need to add extra crap just to identify the vendor. It doesn't serve any really useful purpose - we will have metainformation elsewhere that can be used to link modules comprising a product together - there's no need to duplicate it in the filename. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
klogin.o(.text+0x3e): undefined reference to `_pam_noticketsdontcomplain'
Just wanted to let you know ... cc -O -pipe -DSETPROCTITLE -DSKEY -DLOGIN_CAP -DVIRTUAL_HOSTING -Wall -I/home/src/libexec/ftpd/../../contrib-crypto/telnet -DKERBEROS -I/usr/obj/home/src/tmp/usr/include -o ftpd ftpd.o ftpcmd.o logwtmp.o popen.o skey-stuff.o klogin.o -lskey -lmd -lcrypt -lutil -lkrb -ldes ftpd.o: In function `pass': ftpd.o(.text+0x11c9): undefined reference to `klogin' klogin.o: In function `_pam_klogin': klogin.o(.text+0x3e): undefined reference to `_pam_noticketsdontcomplain' klogin.o(.text+0x96): undefined reference to `_pam_krbtkfile_env' klogin.o(.text+0x167): undefined reference to `_pam_notickets' *** Error code 1 1 error -- Andreas Klemmhttp://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example, in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html "NT = Not Today" (Maggie Biggs) ``powered by FreeBSD SMP'' To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Using LinuxThreads
On Thu, 21 Jan 1999, Richard Seaman, Jr. wrote: > > And when are COMPAT_LINUX_THREADS and VM_STACK going away? > > I have no idea. I was hoping that at least COMPAT_LINUX_THREADS > would go away before the branch. I don't have commit authority, > so it isn't up to me. > hmm did you send me the patches? I can certainly do it now..(given a patch set to apply) I just realised however, that if we make them go away we break SMP right? hmm I guess we only break it for programs that woudltry use it which should be none if you run SMP :-) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
cvsup failures
I've been seeing this since yesterday morning when trying to cvsup: Rmdir ispell/word2x Delete ispell/yodl/Makefile,v Delete ispell/yodl/files/md5,v Rmdir ispell/yodl/files Delete ispell/yodl/patches/patch-aa,v Rmdir ispell/yodl/patches Delete ispell/yodl/pkg/COMMENT,v Delete ispell/yodl/pkg/DESCR,v Delete ispell/yodl/pkg/PLIST,v Rmdir ispell/yodl/pkg Rmdir ispell/yodl Rmdir ispell *** *** runtime error: ***ASSERT failed ***file "../src/FileStatus.m3", line 467 *** Abort trap (core dumped) Any known problems, or should I clear out my repository and start over? Jacques Vidrine / n...@nectar.com / nec...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Using LinuxThreads
At 06:12 PM 1/21/99 +0200, Jeremy Lea wrote: >On Tue, Jan 19, 1999 at 09:11:51AM -0600, Richard Seaman, Jr. wrote: >> Actually, the new version, in FreeBSD "ports" form, doesn't require >> -DLINUXTHREADS anymore, but it does require -I/usr/local/include to >> pick up the right header, since it installs a pthread.h into >> /usr/local/include. This conflicts with the pthread.h in /usr/include. It doesn't conflict, it overrides the pthread.h in /usr/include iff the port is installed AND the application is compiled with -I/usr/local/include. Sounds a lot like how various other 'replacement' libraries are implemented. >This is nagging at me. Having two headers of the same name, but importantly >different content is asking for touble. There needs to be a way to ensure >that only one or the other is picked up. The best way I can think of is to >only include the contents of the user thread pthread.h if _THREAD_SAFE is >defined (to force people to use the right defines...) and the contents of >kernel thread pthread.h if _REENTRANT (and not _THREAD_SAFE) is defined. >This has the added bonus of meaning that most linux apps wont have to be >patched. Of course, this would only work if the contents of the two pthread.h files were merged. I'm not sure this is a good idea. If you did this, do NOT use -D_REENTRANT or -D_THREAD_SAFE as the conditional to determine the content. Use -DLINUXTHREADS or something. >To many applications have configure scripts which might find >/usr/local/lib/libpthread, but not /usr/local/include/pthread.h, or find >/usr/lib/libc_r and find /usr/local/include/pthread.h. Garbage in, garbage out. If the configure script in handed ill defined environment settings (CPPFLAGS, LDFLAGS) you get what you deserve! > Can gcc be made to define _THREAD_SAFE automatically if -pthread >is given? And _REENTRANT if -kthread is given? -pthread/-kthread, in my option, should be considerred linker options (basically just a short hand for -lc_r -nostdlib) BTW, why does FreeBSD use -D_THREAD_SAFE AND -D_REENTRANT (math.h) while most other PThread (final) implementations use -D_REENTRANT? Also, the cc(1) says to use -D_THREADSAFE not -D_THREAD_SAFE. Personallly, I think -DREENTRANT should be used for include all prototypes for reentrant functions not requiring thread support (like strtok_r) and -D_THREAD_SAFE routines only implemented in -lc_r. If possible, functions should be implemented in both -lc and -lc_r such that 3rd party libraries wouldn't have to create both a -lfoolib vs. -lfoolib_r versions (unless their _r versions requires threading). Kurt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Using LinuxThreads
On Thu, Jan 21, 1999 at 11:04:38AM -0800, Julian Elischer wrote: > > > On Thu, 21 Jan 1999, Richard Seaman, Jr. wrote: > > > > And when are COMPAT_LINUX_THREADS and VM_STACK going away? > > > > I have no idea. I was hoping that at least COMPAT_LINUX_THREADS > > would go away before the branch. I don't have commit authority, > > so it isn't up to me. > > > > hmm did you send me the patches? No. You said you wanted Peter to do it. I offered to send patches upon request, but never got a request. :) > > I can certainly do it now..(given a patch set to apply) Ok. I'll send it. Do you want VM_STACK out too? > I just realised however, that if we make them go away we break > SMP right? No. I don't think the patches affect SMP one way or the other. If someone tries to run kernel threads of any kind (linuxthreads in emulation, linuxthread in FreeBSD native, any other kernel threads implementation that uses rfork with RFMEM) rfork will fail, with or without the patches (unless you apply Luoqi Chen's pmap patches). I see no reason the patches shouldn't work with SMP when rfork gets fixed, but I haven't tried it. > hmm I guess we only break it for programs that woudltry use it > which should be none if you run SMP :-) See above. -- Richard Seamman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SCSI errors from IBM Netfinity 3500
Edwin Culp wrote... > I'm getting a lot of these SCSI disk errors from Current as of Sunday > with the onboard Adaptec Controler with an IBM netfinity 3500. Can > someone tell me if I should worry and/or what they mean? > > Thanks, > > ed > > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0x88 > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x4f > SCSIRATE == 0x88 > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10f > SCSIRATE == 0x88 > (da0:ahc0:0:0:0): parity error during Data-In phase. > SEQADDR == 0x10e > SCSIRATE == 0x88 You have a cabling or termination problem. Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
kld meta info (Re: KLD naming)
Is there meta information in a .ko file? That way you could do a kldinfo to find out where to go for more info, etc. On Thu, Jan 21, 1999 at 11:13:49AM -0800, Mike Smith wrote: > I've thought about this, and I think it would be a very bad idea. > > We want to keep this *simple*. In the case of, eg. OSS, one might > expect: > > dev_oss.ko > oss_yamaha.ko > oss_sb16.ko > ... > > There's no need to add extra crap just to identify the vendor. It > doesn't serve any really useful purpose - we will have metainformation > elsewhere that can be used to link modules comprising a product > together - there's no need to duplicate it in the filename. -- "Logic is a little bird, sitting in a tree; that smells *awful*." -- /usr/bin/fortune [Disclaimer: I speak for myself and my views are my own and not in any way to be construed as the views of BellSouth Corporation. ] To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: mountd
On Thu, 21-Jan-1999 at 10:54:36 -0500, David E. Cross wrote: > I posted this awhile ago to -questions, but never received a reply. > > We have a number of FreeBSD NFS servers here. Occasionally we need to > change the exports list on the servers and send mountd a SIGHUP. This > leads to a condition that in many ways is much worse than a server reboot. > > What happens is for the duration of mountd reading the exports file it denies > all NFS requests. This has a number of bad effects; 1) any user home and > system directories become unavailable, with the error 'permission denied' 2) > (and this is far worse), any process with a mapped .text segment off of the > NFS server, should it branch to code not in the cache gets immediately killed. > This include user processes that are running from home directories, and system > processes (such as ssh). If we were to reboot the machine it would just > hang those connections until the machine came back, without killing anyone. > > Is there a solution to this problem? I know that none of HP-UX, IRIX, or > Solaris have this problem. Please, please, if anyone knows a solution for this, drop me a note also... Thanks, -Andre To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kld meta info (Re: KLD naming)
> > Is there meta information in a .ko file? That way you could do a kldinfo to > find out where to go for more info, etc. There's not time to standardise this, so I would say that 3.x .ko files won't have metainformation internally, no. Certainly 4.x .ko files will carry a lot more metainformation with them, and that may include this, yes. > On Thu, Jan 21, 1999 at 11:13:49AM -0800, Mike Smith wrote: > > I've thought about this, and I think it would be a very bad idea. > > > > We want to keep this *simple*. In the case of, eg. OSS, one might > > expect: > > > > dev_oss.ko > > oss_yamaha.ko > > oss_sb16.ko > > ... > > > > There's no need to add extra crap just to identify the vendor. It > > doesn't serve any really useful purpose - we will have metainformation > > elsewhere that can be used to link modules comprising a product > > together - there's no need to duplicate it in the filename. > > -- > "Logic is a little bird, sitting in a tree; that smells *awful*." > -- /usr/bin/fortune > > [Disclaimer: I speak for myself and my views are my own and not in any way to > be construed as the views of BellSouth Corporation. ] -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
src/secure breaks world
cd /usr/src/secure/lib/libcrypt; /usr/obj/usr/src/tmp/usr/bin/make -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED cleandepend; /usr/obj/usr/src/tmp/usr/bin/make -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED all; /usr/obj/usr/src/tmp/usr/bin/make -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED -B install cleandir obj rm -f .depend /usr/obj/usr/src/secure/lib/libcrypt/GPATH /usr/obj/usr/src/secure/lib/libcrypt/GRTAGS /usr/obj/usr/src/secure/lib/libcrypt/GSYMS /usr/obj/usr/src/secure/lib/libcrypt/GTAGS make: don't know how to make crypt-md5.c. Stop *** Error code 2 1 error Seem crypt-md5.c was moved into the attic, but the Makefile was updated. -- Steve finger ka...@troutmask.apl.washington.edu http://troutmask.apl.washington.edu/~clesceri/kargl.html To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Using LinuxThreads
On Thu, 21 Jan 1999, Richard Seaman, Jr. wrote: > On Thu, Jan 21, 1999 at 11:04:38AM -0800, Julian Elischer wrote: > > > > > > On Thu, 21 Jan 1999, Richard Seaman, Jr. wrote: > > > > > > And when are COMPAT_LINUX_THREADS and VM_STACK going away? > > > > > > I have no idea. I was hoping that at least COMPAT_LINUX_THREADS > > > would go away before the branch. I don't have commit authority, > > > so it isn't up to me. > > > > > > > hmm did you send me the patches? > > No. You said you wanted Peter to do it. I offered to send > patches upon request, but never got a request. :) > > > > > I can certainly do it now..(given a patch set to apply) > > Ok. I'll send it. Do you want VM_STACK out too? yes > > > I just realised however, that if we make them go away we break > > SMP right? > > No. I don't think the patches affect SMP one way or the other. > If someone tries to run kernel threads of any kind (linuxthreads > in emulation, linuxthread in FreeBSD native, any other kernel > threads implementation that uses rfork with RFMEM) rfork will > fail, with or without the patches (unless you apply Luoqi Chen's > pmap patches). > > I see no reason the patches shouldn't work with SMP when rfork > gets fixed, but I haven't tried it. ok send them and I'll commit julian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: KLD naming
> I've taken this off list. I'm not sure we're quite addressing the same > issue. No, I think we were at angles for a bit here. But I do believe that this is something work copying to people on the list, as you do raise a very good point. I hope this was on -current. 8) > > I've thought about this, and I think it would be a very bad idea. > > > > We want to keep this *simple*. In the case of, eg. OSS, one might > > expect: > > > > dev_oss.ko > > oss_yamaha.ko > > oss_sb16.ko > > ... > > > > There's no need to add extra crap just to identify the vendor. It > > doesn't serve any really useful purpose - we will have > > metainformation elsewhere that can be used to link modules > > comprising a product together - there's no need to duplicate it > > in the filename. > > It's not a question, primarily, of being able to identify the vendor > from the filename, it's more the case of different vendors not both > choosing the *same* filename thereby making it very difficult to install > them both at the same time. I'm saying primarily since if we do have a > vendor prefix in the filename it would make it easy to see where a > module came from but that is not my main motivation for suggesting it. > > I'm proposing that the guidleline be that anyone wishing to publish > their own modules (i.e. not contribute them to the FreeBSD source base) > should effectively create their own namespace by prefixing the filename > with a vendor code. This would make clashes a lot less likely and if > necessary a registry of vendor codes would have to be made available. > > I can't see how you can avoid namespace clashes otherwise. Third party > developers aren't likely to communicate with each other to ensure > uniqueness so it's better that the naming convention provide a mechanism > for such parties to ensure that the filenames they choose don't clash > with other people's modules. Ah, understood. I'd be inclined to use a suffix, so that our prefix-based classification scheme still worked, eg. dev_ahc_Adaptec.ko kern_descrypt_RSA.ko etc. > It'd be very irritating to pop a floppy in the machine that you got from > some vendor, run install and then find that some important module had > been overwritten from the vendor disk, or that the install failed > because it couldn't copy over all the modules. Understood now, yes. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: PR filed on dying daemons bug
In article <199812280019.qaa22...@hub.freebsd.org> you wrote: > On 28 Dec, Dmitrij Tejblum wrote: >> I once suggested this patch: >> > [ patch snipped ] >> >> Dima >> > My, I forgot about that patch. It is working so far right now (I've > managed to bring the swap usage to levels which would trigger the bug > before, and nothing has happened yet) > Thank you very much for that patch, please consider this a premature > positive response :) > I haven't had any negative side-effects as a result of this patch, and > it might just be my imagination but it seemed to take much more work to > get the machine to swap than before. If I'm not mistaken, I was that person who gave the positive response to Dima's patch. Since applying it I was not able to reproduce "daemons dying". Though it seems that nobody responsible for FreeBSD VM paied attention to that. I think that it happened so that people who do not see the problem on their machines just do not beleive the problem really exist ;) :(. > -- > Jason Garman http://fs.sso.sytexinc.com/~jgarman/ > Student, University of Marylandgar...@earthling.net > Words of Wisdom from the Simpsons:Whois: JAG145 > "'The President did it' is not an excuse" -- Bart Simpson's punishment --- "I didn't know it was impossible when I did it." To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Using LinuxThreads
On Thu, Jan 21, 1999 at 11:42:14AM -0800, Kurt D. Zeilenga wrote: > >This is nagging at me. Having two headers of the same name, but importantly > >different content is asking for touble. There needs to be a way to ensure > >that only one or the other is picked up. The best way I can think of is to > >only include the contents of the user thread pthread.h if _THREAD_SAFE is > >defined (to force people to use the right defines...) and the contents of > >kernel thread pthread.h if _REENTRANT (and not _THREAD_SAFE) is defined. > >This has the added bonus of meaning that most linux apps wont have to be > >patched. > > Of course, this would only work if the contents of the two pthread.h files > were merged. I'm not sure this is a good idea. I'm not advocating any changes. But, IMO the best way to do it, if you did, wouldn't be to merge the files, but rather to re-implemnt pthread.h like: #ifdef LINUXTHREADS #include <..pointer to lt pthread.h file..> #else #include <..pointer to user thread pthread.h file..> #endif > If you did this, do NOT use -D_REENTRANT or -D_THREAD_SAFE as the conditional > to determine the content. Use -DLINUXTHREADS or something. Right. > BTW, why does FreeBSD use -D_THREAD_SAFE AND -D_REENTRANT (math.h) > while most other PThread (final) implementations use -D_REENTRANT? Don't know. Using _REENTRANT would be preferable, IMO. > > Also, the cc(1) says to use -D_THREADSAFE not -D_THREAD_SAFE. Hmm. Not on my machine. :) > Personallly, I think -DREENTRANT should be used for include all prototypes > for reentrant functions not requiring thread support (like strtok_r) and > -D_THREAD_SAFE routines only implemented in -lc_r. I think _THREAD_SAFE should be used as a switch when compiling libc/libc_r to turn on libc_r specific options, which is how it is primarily used now. _REENTRANT should be used in all libc/libc_r and system headers to turn on generic thread safe options. > If possible, functions > should be implemented in both -lc and -lc_r such that 3rd party libraries > wouldn't have to create both a -lfoolib vs. -lfoolib_r versions (unless > their _r versions requires threading). For kernel threading you just use libc. Whether or not libc generates thread safe (re-entrant) calls depends on whether its also linked with a library that 1) sets __isthreaded to a non-zero value, 2) has a _spinlock() implementationm, and 3) implements the functions flockfile, funlockfile, etc. There are also a few macros in header files that require _THREAD_SAFE to be defined to be thread safe. libc_r could be modified so that is doesn't replace libc, but rather is an addon, comparable to the kernel threaded libc case. But, it would involve a bit of work. -- Richard Seamman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: /etc/nsswitch.conf
"Joerg B. Micheel" writes: > > consolidating all that config information in one place, such as > > /etc/rc.conf, would be a good thing. > Agreed, it really isn't such a good idea to clutter /etc/ with all > those single line configuration files. Actually, they did it for a reason, and it's not really a *bad* reason. It makes automated administration a lot easier - e.g. writing scripts that modify the system config etc. Solaris (and SysV in general) is *very* geared towards automated adminning. That's not necessarily a bad thing, if it's done properly, but I don't agree with the way they chose to solve some of the problems that arise when you do that. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Using LinuxThreads
Julian Elischer wrote: [..] > > > I just realised however, that if we make them go away we break > > > SMP right? > > > > No. I don't think the patches affect SMP one way or the other. > > If someone tries to run kernel threads of any kind (linuxthreads > > in emulation, linuxthread in FreeBSD native, any other kernel > > threads implementation that uses rfork with RFMEM) rfork will > > fail, with or without the patches (unless you apply Luoqi Chen's > > pmap patches). > > > > I see no reason the patches shouldn't work with SMP when rfork > > gets fixed, but I haven't tried it. > > ok send them and I'll commit > > julian Wait a day or two for the VM dust to settle otherwise there will be no telling which set of code is causing problems. The POSIX options probably need to go on with this or there isn't much point doing it since it's part of what the linux threads package calls. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
[no subject]
subscribe current To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: KVA/KVM shortages
> On tuesday I crashed a machine after it ran out of kvm. (dual PII 400 with > 768MB RAM) poking about in the code adding: > > options "VM_KMEM_SIZE=(24*1024*1024)" > options "VM_KMEM_SIZE_MAX=(128*1024*1024)" > > seems like a good way foward. Is it? >From what I can see, you shouldn't need to set VM_KMEM_SIZE_MAX unless you're also setting VM_KMEM_SIZE_SCALE. I just committed a tweak that allows you to say: set kern.vm.kmem.size= at the loader prompt or in /boot/loader.rc to override the default VM_KMEM_SIZE value. If anyone has any more of these tunables that can easily be enhanced like this, please let me know. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
-D_REENTRANT (Was: Using LinuxThreads)
"Richard Seaman, Jr." wrote: > > BTW, why does FreeBSD use -D_THREAD_SAFE AND -D_REENTRANT (math.h) > > while most other PThread (final) implementations use -D_REENTRANT? > Don't know. Using _REENTRANT would be preferable, IMO. Now if only a committer would agree... (I'll send patches if needed). > > Also, the cc(1) says to use -D_THREADSAFE not -D_THREAD_SAFE. > Hmm. Not on my machine. :) http://www.freebsd.org/cgi/man.cgi?query=cc&apropos=0&sektion=0&manpath=FreeBSD+3.0-current&format=html > > Personallly, I think -DREENTRANT should be used for include all prototypes > > for reentrant functions not requiring thread support (like strtok_r) and > > -D_THREAD_SAFE routines only implemented in -lc_r. > > I think _THREAD_SAFE should be used as a switch when compiling libc/libc_r to > turn on libc_r specific options, which is how it is primarily used now. Then it shouldn't be used in the headers if at all possible! > _REENTRANT should be used in all libc/libc_r and system headers to turn on > generic thread safe options. -D_REENTRANT should turn on reentrant functions, some of which may or may not be thread safe, that do not require threading support to implement. Reentrant functions that require threading support to implement should only be behind a different define. I think the problem is that folks tend to think the reentrant functions are only for use in threaded applications. They are quite useful in non-threaded applications as well (especially strtok_r). > > If possible, functions > > should be implemented in both -lc and -lc_r such that 3rd party libraries > > wouldn't have to create both a -lfoolib vs. -lfoolib_r versions (unless > > their _r versions requires threading). > > For kernel threading you just use libc. Whether or not libc generates > thread safe (re-entrant) calls depends on whether its also linked with > a library that 1) sets __isthreaded to a non-zero value, 2) has a _spinlock() > implementationm, and 3) implements the functions flockfile, funlockfile, etc. > There are also a few macros in header files that require _THREAD_SAFE to > be defined to be thread safe. I was hoping to be able to produce one ldap library that could be safely linked with or without threads. However, if I must define _THREAD_SAFE to generate code to be linked with threads then I must produce two libraries (-lfoolib compiled with -U_THREAD_SAFE and -lfoolib_r with -D_THREAD_SAFE). This is quite painful. Many 3rd packages won't go through the pain. They will generate one library and assume all users will compile/link with compatible flags. Of course, most users don't know how their libraries were built nor pay much attention when configure dependent software. We run into this big time with OpenLDAP and third party packages such as DB2. It gets real complicated with try to link with multiple third party libs which may or may not be compiled with -D_THREAD_SAFE. errno was the biggest problem, but its conditional declaration of it has long since been removed. 3rd party library implementors need to be careful when using any function with a conditional declaration as you don't know which you'll get when an application is linked. We also only use reentrant functions where exist in -lc and avoid functions such as feof that may have conditional declarations. This allows us to build one -lldap that *can be* safely used by both threaded and non-threaded applications. > libc_r could be modified so that is doesn't replace libc, but rather is > an addon, comparable to the kernel threaded libc case. But, it would > involve a bit of work. > > -- > Richard Seamman, Jr. email: d...@tar.com > 5182 N. Maple Lanephone: 414-367-5450 > Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: klogin.o(.text+0x3e): undefined reference to `_pam_noticketsdontcomplain'
In article <19990121201420.a50...@titan.klemm.gtn.com>, Andreas Klemm wrote: > cc -O -pipe -DSETPROCTITLE -DSKEY -DLOGIN_CAP -DVIRTUAL_HOSTING -Wall > -I/home/src/libexec/ftpd/../../contrib-crypto/telnet -DKERBEROS > -I/usr/obj/home/src/tmp/usr/include -o ftpd ftpd.o ftpcmd.o logwtmp.o > popen.o skey-stuff.o klogin.o -lskey -lmd -lcrypt -lutil -lkrb -ldes > ftpd.o: In function `pass': > ftpd.o(.text+0x11c9): undefined reference to `klogin' > klogin.o: In function `_pam_klogin': > klogin.o(.text+0x3e): undefined reference to `_pam_noticketsdontcomplain' > klogin.o(.text+0x96): undefined reference to `_pam_krbtkfile_env' > klogin.o(.text+0x167): undefined reference to `_pam_notickets' Sorry folks! Pointy hat, please. I fixed it now, in both -current and RELENG_3. John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: src/secure breaks world
On Thu, Jan 21, 1999 at 12:26:04PM -0800, Steve Kargl wrote: > cd /usr/src/secure/lib/libcrypt; /usr/obj/usr/src/tmp/usr/bin/make -DNOINFO > -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED cleandepend; > /usr/obj/usr/src/tmp/usr/bin/make -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE > -DNOSHARED all; /usr/obj/usr/src/tmp/usr/bin/make -DNOINFO -DNOMAN -DNOPIC > -DNOPROFILE -DNOSHARED -B install cleandir obj > rm -f .depend /usr/obj/usr/src/secure/lib/libcrypt/GPATH > /usr/obj/usr/src/secure/lib/libcrypt/GRTAGS > /usr/obj/usr/src/secure/lib/libcrypt/GSYMS > /usr/obj/usr/src/secure/lib/libcrypt/GTAGS > make: don't know how to make crypt-md5.c. Stop > *** Error code 2 > 1 error > > Seem crypt-md5.c was moved into the attic, but the Makefile was updated. Do you mean "wasn't" updated? I am not sure that fixing the Makefile will resolve all the issues with the recent libcrypt changes. -- Regards, Norman C. Rice, Jr. > -- > Steve > > finger ka...@troutmask.apl.washington.edu > http://troutmask.apl.washington.edu/~clesceri/kargl.html To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: src/secure breaks world
Norman C. Rice wrote: > On Thu, Jan 21, 1999 at 12:26:04PM -0800, Steve Kargl wrote: > > make: don't know how to make crypt-md5.c. Stop > > *** Error code 2 > > 1 error > > > > Seem crypt-md5.c was moved into the attic, but the Makefile was updated. > > Do you mean "wasn't" updated? Yes, of course. I think faster than I type. > I am not sure that fixing the Makefile will resolve all the issues with the > recent libcrypt changes. I agree because there is now src/lib/libcrypt/crypt-md5.c, and its unclear whether one should delete crypt-md5.c from SRCS in the Makefile or change .PATH to pick up the new file. -- Steve finger ka...@troutmask.apl.washington.edu http://troutmask.apl.washington.edu/~clesceri/kargl.html To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: KLD naming
> -Original Message- > From: Mike Smith [mailto:m...@smith.net.au] > Sent: Thursday, January 21, 1999 8:25 PM > To: p...@originative.co.uk > Cc: curr...@freebsd.org > Subject: Re: KLD naming > ... > Ah, understood. I'd be inclined to use a suffix, so that our > prefix-based classification scheme still worked, eg. > > dev_ahc_Adaptec.ko > kern_descrypt_RSA.ko > > etc. Hmm, wouldn't this impose our kernel structure onto modules? This might not be desirable for external developers, they may just want to provide a single module rather than split the product into submodules that fit our categories. Why not allow SafeCo_firewall.ko rather than netif_foo_SafeCo.ko netproto_bar_SafeCo.ko etc. Paul. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Current compile problem
I cvsup'ed current today, and am having a problem with the build. I am running current as of a couple of weeks ago, and during the buildworld, I get an error in the /usr/src/secure/lib/libcrypt directory, because the Makefile is refering to crypt.c crypt-md5.c md5c.c and crypt.3, but only crypt.c seems to exist. I double checked all the example cvsup files I could find, to make sure something hasn't changed in the crypto stuff, but it all looks fine to me. Did some files get missed in a commit? I also tried removing the non-existent files from the Makefile, but that errors out later with undefined symbols. I'm cvsup'ing src-all, src-crypto, src-secure, and src-eBones. Steve -- --- Steven Jorgensen st...@khoral.com st...@haunt.com --+ Khoral Research Inc. | PHONE: (505) 837-6500 6200 Uptown Blvd, Suite 200 | FAX: (505) 881-3842 Albuquerque, NM 87110 | URL: http://www.khoral.com/ --- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: KVA/KVM shortages
>> On tuesday I crashed a machine after it ran out of kvm. (dual PII 400 with >> 768MB RAM) poking about in the code adding: >> >> options "VM_KMEM_SIZE=(24*1024*1024)" >> options "VM_KMEM_SIZE_MAX=(128*1024*1024)" >> >> seems like a good way foward. Is it? > >>From what I can see, you shouldn't need to set VM_KMEM_SIZE_MAX unless >you're also setting VM_KMEM_SIZE_SCALE. > >I just committed a tweak that allows you to say: > > set kern.vm.kmem.size= > >at the loader prompt or in /boot/loader.rc to override the default >VM_KMEM_SIZE value. > >If anyone has any more of these tunables that can easily be enhanced >like this, please let me know. Is there a way from the boot loader that one can find out what options are available to be tuned? -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: KVA/KVM shortages
> > > >If anyone has any more of these tunables that can easily be enhanced > >like this, please let me know. > >Is there a way from the boot loader that one can find out what options > are available to be tuned? At the moment, the values are picked up on-demand by the kernel as it's initialising its state from the preprocessor defines, so there's no metainformation that can be extracted from the kernel to determine the tunables that are available. This could be improved in a number of ways - it would be achievable, for example, to have a macro: is_set = GET_KERN_TUNABLE(name, "description", variable); which exported "name" and "description" via a linker set which could be extracted by the loader. In the meantime, "help set tunables" inside the loader contains a list of the ones I've updated so far (the source for this is in sys/boot/common/help.common) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: splash screen & xdm
This, no response on Ctrl-Alt-F1, happens as well when you kill the X server (because it is somehow stuck) so that the login prompt of xdm appears again. So I bet it has something to do with and is either located in syscons or in X. Nick > > It seems that if the splash screen image is not cleared (ie: press any > > key) before xdm starts up then once logged in the user is unable to > > switch to a vitual terminal (ie: ctrl-alt-f1 etc), and it just beeps > > when those keys are pressed. > > Solution? Putting the command kldunload splash_bmp before the line that > > loads xdm seems to work. Is this a bug or just the way things are? > > It's arguably a bug - the splash should be cleared before the vty > switch that X makes. > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ m...@smith.net.au > \\ The race is long, and in the \\ msm...@freebsd.org > \\ end it's only with yourself. \\ msm...@cdrom.com > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > > FreeBSD USB Driver Development -- e-mail: n_hi...@freebsd.org home page: http://www.etla.net/~n_hibma/usb/usb.pl mailing list: usb-...@egroups.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
CVS tags to use?
The readme in /usr/share/examples hasn't been updated in a while... WHat tag should I be using now to track 3.0-current/3.1? (Not the 4.x branch). Right now, I have tag=., and I can't get a compilable kernel to save my life, problems in syscons. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: make world broken in /lib
"me too" -DNOSECURE seems to help but it hasn't completed yet. julian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: CVS tags to use?
On Thu, 21 Jan 1999, Jaye Mathisen wrote: > > > The readme in /usr/share/examples hasn't been updated in a while... > > WHat tag should I be using now to track 3.0-current/3.1? (Not the 4.x > branch). > > Right now, I have tag=., and I can't get a compilable kernel to save my > life, problems in syscons. I have tag=RELENG_3, which gave me: FreeBSD PigStuy.nws.net 3.0-STABLE FreeBSD 3.0-STABLE #13: Thu Jan 21 17:45:26 EST 1999 sp...@pigstuy.nws.net:/usr/src/sys/compile/MYKERNEL2 i386 3.0-RELEASE is 3_0_0_RELEASE. I just got bit by syscons- do you have the new syscons configuration? I needed to change: device sc0 at isa? port "IO_KBD" conflicts tty irq 1 vector scintr to: controller atkbdc0 at isa? port IO_KBD tty device atkbd0 at isa? tty irq 1 device psm0at isa? tty irq 12 device vga0at isa? port ? conflicts device sc0 at isa? tty Or else both my psm and syscons drivers would scream various functions they couldn't find. Hope this solves your problem. -Spike Gronim spo...@ix.netcom.com The majority only rules those who let them. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
PNP and new bootloader with ELF kernel
Hi, I am currently running 3.0-RELEASE -current last updated 15th Jan (I think) and after a make world things were great kernel builds in an instant, computer boots faster etc etc. However I am unable to use help in the new bootloader, it sais the file boot.help cant be found and as such I do not know how to set up my PnP cards. Before I used -c at boot followed by pnp 1 enable etc., but this does not work now. How do I set up the CSN now as I get CSN 1 disabled and CSN 2 disabled on boot. Also I would like to remove the previous boot screen and boot straight into the new bootloader, so can a dos partition be configured to boot from the new bootloader Sorry if this has already been answered anywhere but I cant find it ! Is there any extensive documentation on the new ELF system ? Thanks for any help -- Tim To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: src/secure breaks world
> On Thu, Jan 21, 1999 at 12:26:04PM -0800, Steve Kargl wrote: > > cd /usr/src/secure/lib/libcrypt; /usr/obj/usr/src/tmp/usr/bin/make > > -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED cleandepend; > > /usr/obj/usr/src/tmp/usr/bin/make -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE > > -DNOSHARED all; /usr/obj/usr/src/tmp/usr/bin/make -DNOINFO -DNOMAN -DNOPIC > > -DNOPROFILE -DNOSHARED -B install cleandir obj > > rm -f .depend /usr/obj/usr/src/secure/lib/libcrypt/GPATH > > /usr/obj/usr/src/secure/lib/libcrypt/GRTAGS > > /usr/obj/usr/src/secure/lib/libcrypt/GSYMS > > /usr/obj/usr/src/secure/lib/libcrypt/GTAGS > > make: don't know how to make crypt-md5.c. Stop > > *** Error code 2 > > 1 error > > > > Seem crypt-md5.c was moved into the attic, but the Makefile was updated. > > Do you mean "wasn't" updated? > > I am not sure that fixing the Makefile will resolve all the issues with the > recent libcrypt changes. I just finished a make world, here're the changes I made, Makefile.inc1: delete secure/lib/libcrypt from bootstrap library list lib/Makefile: delete secure/lib/libcrypt from SUBDIR list secure/lib/libcrypt:rename crypt.c to crypt-des.c -lq > -- > Regards, > Norman C. Rice, Jr. > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: keymaps
>> 104 Pause Start screen saver (saver). >: >> The above assignments for the keycodes 1, 57, 70, 84 and 92 are >> compatible with many, if not all, existing keymaps. > >So far so good! > >> The assignments for 104 and 108 are new. > >104 (Pause?) does the "Backscroll" on my Libretto 70. I'd hate to >lose that. ScrollLock does "back scroll" too. You want both? Kazu To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Problem loading 2.x kernel with new bootblocks [Re: Experiences with aout-to-elf and new bootblocks]
Splitting the thread... "Daniel C. Sobral" wrote: >> /boot/loader could load my 2.x kernel (although it happily handled > ^^ >You mean "could not", right? That's correct. >Is it kzipped, your 2.x kernel? (Is there any detail about it that >you think it is not relevant? :-) Further point: a GENERIC 2.2.6-RELEASE kernel boots successfully, so it is something about my kernel. The config file and boot messages are below. FWIW, boot -d still hangs, so it's dying fairly early. The kernel is not gzip'd - it's installed using `make install'. System details: PII-266 with IDE disks: primary master: wd0: dualboot (W95/FreeBSD 2.x) primary slave:ATAPI cdrom secondary master: wd2: FreeBSD 3.0 (not dangerously dedicated) secondary slave: not present The kernel has been built with gcc-2.8.1 -O2. My 2.x config file: machine "i386" cpu "I686_CPU" ident gsm_xt maxusers20 options FAILSAFE#Be conservative config kernel root on wd0 options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options USER_LDT# user-level control of i386 LDT options SYSVSHM options SHMMAX=16777216 options SYSVSEM options SYSVMSG options "MD5" options DDB options KTRACE #kernel tracing options PERFMON options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options INET#InterNETworking pseudo-device ether pseudo-device loop pseudo-device bpfilter 4 pseudo-device tun 1 options FFS #Berkeley Fast Filesystem options NFS #Network Filesystem options "CD9660"#ISO 9660 Filesystem options FDESC #File descriptor filesystem options KERNFS #Kernel filesystem options MFS #Memory filesystem options MSDOSFS #MSDOS Filesystem options PROCFS #Process filesystem pseudo-device pty 256 pseudo-device speaker pseudo-device log pseudo-device gzip# Exec gzipped a.out's pseudo-device vn controller isa0 options "AUTO_EOI_1" controller pci0 controller pnp0 device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr options MAXCONS=12 # number of virtual consoles device npx0at isa? port "IO_NPX" flags 0x1 irq 13 vector npxintr controller wdc0at isa? port "IO_WD1" flags 0x80ff80ff bio irq 14 vector wdintr diskwd0 at wdc0 drive 0 diskwd1 at wdc0 disable drive 1 controller wdc1at isa? disable port "IO_WD2" bio irq 15 vector wdintr diskwd2 at wdc1 disable drive 0 diskwd3 at wdc1 disable drive 1 options ATAPI #Enable ATAPI support for IDE bus options ATAPI_STATIC#Don't do it as an LKM device wcd0#IDE CD-ROM controller fdc0at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr diskfd0 at fdc0 drive 0 diskfd1 at fdc0 disable drive 1 device lpt0at isa? port? tty irq 7 vector lptintr device psm0at isa? port "IO_KBD" conflicts tty irq 12 vector psmintr device apm0at isa? # Advanced Power Management device sio0at isa? port "IO_COM1" tty irq 4 vector siointr device sio1at isa? port "IO_COM2" tty irq 3 vector siointr device pcm0 at isa? port ? tty irq 5 drq 1 flags 0x13 vector pcmintr device pca0 at isa? port IO_TIMER1 tty device joy0at isa? port "IO_GAME" device tx0 options "CLK_USE_I586_CALIBRATION" The boot messages: Copyright (c) 1992-1998 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 2.2.6-RELEASE #1: Tue Dec 1 07:58:15 EST 1998 r...@gsmx07.alcatel.com.au:/usr/src/sys/compile/gsmx CPU: Pentium Pro (267.32-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x633 Stepping=3 Features=0x80f9ff real memory = 67108864 (65536K bytes) avail memory = 63406080 (61920K bytes) Probing for devices on PCI bus 0: chip0 rev 3 on pci0:0:0 chip1 rev 3 on pci0:1:0 chip2 rev 1 on pci0:7:0 chip3 rev 1 on pci0:7:1 chip4 rev 1 int d irq 11 on pci0:7:2 chip5 rev 1 on pci0:7:3 vga0 rev 0 int a irq 10 on pci0:9:0 tx0 rev 6 int a irq 9 on pci0:10:0 tx0: address 00:e0:29:24:34:1f, type SMC9432TX, phy QS6612, Auto-Neg 10Mbps Probing for devices on PCI bus 1: Probing for PnP devices: CSN 1 Vendor ID: CTL00f0 [0xf0008c0e] Serial 0x pcm1 (SB16pnp sn 0x) at 0x220 irq 5 drq 1 flags 0x13 id 14 Probing for devices on the ISA bu
Booting from 2nd IDE [Re: Experiences with aout-to-elf and new bootblocks]
"Daniel C. Sobral" wrote:
>Well, kind of. You "hard code" the name wd2 in your kernel
>configuration file. [...] Ie, s/wd2/wd1/
> in your kernel configuration file (and rebuild :).
It was wd0 (the generic). Making it wd2 didn't help.
Mark Blackman wrote:
>FWIW, I've done it under 2.2.7 by
>
>1) installing booteasy on both wd0 *AND* wd2
>2) altering the boot.config to
> 1:wd(2,a)kernel
This works for an a.out 3.0 kernel, but the old bootloader can't handle
ELF kernels, so this isn't a usable solution.
>3) compiling above kernel with
> config kernel root on wd2
This made no difference.
Since typing on a keyboard is easier than opening the box, I wrote the
following kludge. It builds a bitmap of IDE devices as it probes them
and then counts active IDE devices to work out the actual unit number.
Index: i386/autoconf.c
===
RCS file: /home/CVSROOT/./src/sys/i386/i386/autoconf.c,v
retrieving revision 1.110
diff -u -r1.110 autoconf.c
--- autoconf.c 1998/10/26 07:05:34 1.110
+++ autoconf.c 1999/01/21 23:18:18
@@ -433,6 +433,10 @@
#define FDMAJOR 2
#define FDUNITSHIFT 6
+/* KLUDGE for bios handling of multiple devices */
+#defineWDMAJOR 0
+intwd_mask = 0;/* mask of WD devices found during probe */
+
/*
* Attempt to find the device from which we were booted.
* If we can do so, and not instructed not to do so,
@@ -467,6 +471,18 @@
slice = COMPATIBILITY_SLICE;
part = RAW_PART;
mindev = unit << FDUNITSHIFT;
+ } else if (majdev == WDMAJOR) {
+ /*
+* XXX kludge to handle holes in numbering
+*/
+ for (part = 0, mindev = unit; part < 32 && mindev >= 0; part++)
+ if (wd_mask & (1 << part))
+ mindev--;
+ if (mindev == -1)
+ unit = part - 1;
+
+ part = B_PARTITION(bootdev);
+ mindev = dkmakeminor(unit, slice, part);
} else {
part = B_PARTITION(bootdev);
mindev = dkmakeminor(unit, slice, part);
Index: isa/wd.c
===
RCS file: /home/CVSROOT/./src/sys/i386/isa/wd.c,v
retrieving revision 1.186
diff -u -r1.186 wd.c
--- wd.c1999/01/17 05:46:24 1.186
+++ wd.c1999/01/21 23:18:18
@@ -223,6 +223,8 @@
static struct buf rwdbuf[NWD]; /* buffers for raw IO */
#endif
+extern int wd_mask;/* This is a KLUDGE */
+
static int wdprobe(struct isa_device *dvp);
static int wdattach(struct isa_device *dvp);
static void wdustart(struct disk *du);
@@ -551,6 +553,8 @@
DEVSTAT_NO_ORDERED_TAGS,
DEVSTAT_TYPE_DIRECT |
DEVSTAT_TYPE_IF_IDE);
+ /* KLUDGE: mark drive as present */
+ wd_mask |= 1 << lunit;
} else {
free(du, M_TEMP);
wddrives[lunit] = NULL;
-
This successfully allows me to boot from wd2. I agree that it doesn't
address the general problem (in particular, it can't handle the case
where the BIOS doesn't see a device that the kernel probe does see,
and doesn't support SCSI).
Peter
--
Peter Jeremy (VK2PJ)peter.jer...@alcatel.com.au
Alcatel Australia Limited
41 Mandible St Phone: +61 2 9690 5019
ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: Problem loading 2.x kernel with new bootblocks [Re: Experiences with aout-to-elf and new bootblocks]
> The kernel has been built with gcc-2.8.1 -O2. Please rebuild with the system compiler and -O at most. We're hard-pressed enough as it is to support our own software without introducing complete unknowns into the equation. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
PLEASE: back out recent crypt breakage
The recent changes to src/secure/libcrypt have severely broken "make buildworld". Can some please back out the recent changes, and give to the committer named "brandon" a pointed hat? PS: This makes my attempt to test Matt's VM change rather difficult. -- Steve finger ka...@troutmask.apl.washington.edu http://troutmask.apl.washington.edu/~clesceri/kargl.html To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: keymaps
my vote: A version of the standard keymap with CapsLock and LeftCtl functions swapped so the control key is under my left finger like God intended! Greg, home of us.iso-lock-ctl.kbd To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Trouble executing from NFS with latest 4.0-current
Execute anything from NFS would result in an "Input/output error", but if I do a hexdump of the executable first, the execution would be successful. If I reverse the order, i.e., execute first then hexdump, execution would fail and hexdump would hang at "pgtblk". No problem with FFS. -lq To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Promise FastTrack PCI IDE controller
On Thu, Jan 21, 1999 at 02:06:22PM +0100, Søren Schmidt wrote: >It seems David Dawes wrote: >> >> That didn't improve things, but with the patch I got lots of messages >> like the following (for a disk attached to the onboard PIIX4): >> >> wd1: DMA failure, DMA status 0 >> >> (The box isn't SMP.) > >Hmm, and it is an uptodate -current system ?? >Just use this part then: It might have been related to some of the other changes I had made. With a new clean wd.c and your patch I don't get the "wd1: DMA failure, DMA status 0" messages. The Promise card doesn't behave any differently though. >> >I also run the card without its BIOS, as that tends to get in the way. >> >I think the FastTrack is just an Ultra/33 with another BIOS chip on it. >> >> I'll try pulling the BIOS tomorrow. We didn't get this card for it's >> RAID features anyway. > >That helped me in a lot if situations, but performance wont be as good >as we seem not to initialize the chip(s)... When I remove the BIOS it works OK. The initialisation is different though. For the drives on the PIIX4 I get: wdc0 at 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa wdc0: unit 0 (wd0): , DMA, 32-bit, multi-block-16 wd0: 16124MB (33022080 sectors), 32760 cyls, 16 heads, 63 S/T, 512 B/S wd0: ATA INQUIRE valid = 0007, dmamword = 0007, apio = 0003, udma = 0407 for the ones on the Promise card I get: wdc2 at 0xeff0-0xeff7 flags 0xa0ffa0ff on isa wdc2: unit 0 (wd4): , DMA, 32-bit, multi-block-16 wd4: 16124MB (33022080 sectors), 32760 cyls, 16 heads, 63 S/T, 512 B/S wd4: ATA INQUIRE valid = 0007, dmamword = 0407, apio = 0003, udma = 0007 I also get the following warning, but only for the secondary controller on the Promise card: ide_pci: generic_dmainit efa8:0: warning, IDE controller timing not set and in the PCI probe section: ide_pci: busmaster 0 status: 60 from port: ef82 ide_pci: ide0:0 has been configured for DMA by BIOS ide_pci: ide0:1 has been configured for DMA by BIOS ... ide_pci: busmaster 1 status: 00 from port: ef8a The performance isn't as good, as you say. For one of these disks on the PIIX4 I get about 12 MByte/s for a large (1GB) sequential read from the raw device. I only get about 4 MByte/s for one of the same disks on the Promise controller. I presume that's because it isn't initialised to the fastest DMA mode? The performance is adequate for our needs though, so removing the BIOS is a workable solution. Thanks. David To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Trouble executing from NFS with latest 4.0-current
:Execute anything from NFS would result in an "Input/output error", but if I do :a hexdump of the executable first, the execution would be successful. If I :reverse the order, i.e., execute first then hexdump, execution would fail and :hexdump would hang at "pgtblk". No problem with FFS. : :-lq Hmmm. It's working fine for me between two FreeBSD boxes. Do a cvs diff against your entire /usr/src/sys tree first to make sure you are up to date on all the patches. If it's still broken, we need to identify whether it is NFSV2, V3, and whether the problem is related to FreeBSD<->FreeBSD or FreeBSD w/ some other platform. Also any mount options, such as read and write buffer settings, etc... -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: More make release woes
It's time to do a functional split on boot.flp / kern+mfsroot.flp builds. Hmmm. What to axe.. Let me thwap on this a bit over the weekend. :) - Jordan > > Looks like the Alpha AXP boot floppy has bitten the dust also: > > Making the regular boot floppy. > Compressing doc files... > disklabel: ioctl DIOCWLABEL: Operation not supported by device > Warning: Block size restricts cylinders per group to 4. > Warning: 2880 sector(s) in last cylinder unallocated > /dev/rvn0c: 2880 sectors in 1 cylinders of 1 tracks, 5760 sectors > 1.4MB in 1 cyl groups (4 c/g, 11.25MB/g, 192 i/g) > super-block backups (for fsck -b #) at: > 32, > cpio: write error: No space left on device > *** Error code 1 (ignored) > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > > > Sigh. Oh well. I was hoping to get a SNAP out with all the changes > Matt did. Guess not. > > Gary > -- > Gary Palmer FreeBSD Core Team Member > FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
top broken - VM sideeffect?
Looks like top's broken. It no longer shows swap space status on 4.0-CURRENT. Side effect of the VM update? -- "Logic is a little bird, sitting in a tree; that smells *awful*." -- /usr/bin/fortune [Disclaimer: I speak for myself and my views are my own and not in any way to be construed as the views of BellSouth Corporation. ] To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Make Release this afternoon.
What is the trick to get past this problem? Or can a release not be made as before? Thanks a lot, ed disklabel: ioctl DIOCWLABEL: Operation not supported by device Warning: Block size restricts cylinders per group to 4. Warning: 2880 sector(s) in last cylinder unallocated /dev/rvn0c: 2880 sectors in 1 cylinders of 1 tracks, 5760 sectors 1.4MB in 1 cyl groups (4 c/g, 11.25MB/g, 32 i/g) super-block backups (for fsck -b #) at: 32, /mnt: write failed, file system is full cpio: write error: No space left on device *** Error code 1 Stop. *** Error code 1 (ignored) *** Error code 1 Stop. *** Error code 1 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Problem loading 2.x kernel with new bootblocks
Mike Smith wrote:
>> The kernel has been built with gcc-2.8.1 -O2.
>
>Please rebuild with the system compiler and -O at most.
It makes no difference. The kernel loads and runs happily from the
old bootloader, but crashes with /boot/loader. (I disabled my
gcc-2.8.1, changed make.conf to -O, re-ran config; make depend; make;
make install).
Something that `fell off' my previous posting (it was implied in the
context of my original posting):
Both disks have Booteasy installed. wd0 has the old bootblocks
(from 2.2.6-RELEASE) and FreeBSD 2.x installed on slice 2. wd2
has the new bootblocks and 3.0-current built from CTM 'cvs-cur 4996'
occupying all of slice 1 (which is all of the disk).
The boot sequences are:
disk0 booteasy offers: W95, FreeBSD, Disk1:
- select FreeBSD and 2.x boots successfully
- select `disk1' and the disk1 booteasy offers: BSD, disk0
Select BSD and the new /boot/loader comes up. If I let it continue, I
wind up with the 3.0 (customised, ELF) kernel booting successfully.
If I abort /boot/loader's autostart (giving me a prompt), then (as per
Peter Wemm's elfday tutorial) issue the commands:
set currdev=disk1s2a
load /kernel
boot -s
the system displays garbage on the screen and doesn't respond to anything
gentler than the reset button.
If I load the GENERIC 2.2.6-RELEASE kernel, ("load /kernel.GENERIC" above)
then it works.
Any suggestions as to my next step?
Peter
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: keymaps
In message <199901220043.laa22...@lightning.itga.com.au> Gregory Bond writes: : my vote: A version of the standard keymap with CapsLock and LeftCtl : functions swapped so the control key is under my left finger like : God intended! What's wrong with us.unix.kbd? Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: top broken - VM sideeffect?
: :Looks like top's broken. It no longer shows swap space status on 4.0-CURRENT. :Side effect of the VM update? Yes. I've only made pstat -s ( aka swapinfo ) work so far. systat -swap is also broken. Both are on my TODO list. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: top broken - VM sideeffect?
On Thursday, 21 January 1999 at 21:23:52 -0500, Christian Kuhtz wrote: > > Looks like top's broken. It no longer shows swap space status on 4.0-CURRENT. > Side effect of the VM update? Yup. Matt announced it. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
libexpcrypt?
Hi, after todays build I wasn't able to login: Instead of installing libdescrypt.* and linking libcrypt.* to libdescrypt.* I suddenly got libexpcrypt.* files, with no DES code in. It seems the international secure distribution isn't in sync any more. I am missing /usr/src/secure/lib/libcrypt/crypt-des.c I have also noticed the major number in the library bump. Is it safe for the transition period still link libcrypt.so.3 to libdescrypt.so.2? Daniel To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: NFS v3 issue
:With NFS v3 there seem still to be some open issues. :Im running the latest (4.0)-current with the new vm/NFS changes. :While I haven't found any problems with NFSv2 so far, v3 still seems to make :trouble. : :I noticed the error some months ago, while my /usr/obj was NFS mounted, and :a build failed while making termcap.db. Today, I gave it another try. :I copied /usr/src/share/termcap into an NFS mounted directory and did :a "make". I compared the output of termcap.db with the one build on the local :drive. :While the NFS mounted one was only 1077760 bytes in size, the correct :size (from the local build) should be 1245184 bytes. I did the build :several times, everytime I got the same values. I then remounted the :direcory NFSv2. Now the build produced the right file (in size and content). : :The NFS Server is a Solaris 7 machine. : :Can anyone else confirm this error? : :Daniel I can't help you here, but I want to make sure: The problems you are having are the same problems you were having a few months ago? ( I want to make sure I haven't introduced new problems in -4.x, and if I have to fix them ASAP! ). -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: KVA/KVM shortages
> Mike Smith writes: > > > I just committed a tweak that allows you to say: > > > > set kern.vm.kmem.size= > > > > at the loader prompt or in /boot/loader.rc to override the default > > VM_KMEM_SIZE value. > > > > If anyone has any more of these tunables that can easily be enhanced > > like this, please let me know. > > > How about all the parameters that are assigned in param.c? Why not > make them all tweakable in the loader.rc, rather than having to patch > the kernel. Because they're not all used in fashions that either make tuning them really desirable, or easy. I looked at all of them and decided that most weren't actually really candidates for that sort of hackery. > Actually, thinking about this a little more ... > The loader knows where all symbols are in memory. Why not a general > mechanism to let you reassign the value of any "variable" used in > the kernel or in a module. I presume that the loader allocates bss > for the kernel and each module as it loads it. So I presume I can > assign a value to a variable that would ordinarily take on a 0 > value, too. Because most of them are initialised at runtime from preprocessor defines, so tweaking their initial values wouldn't save anything (you'd have to hack the code anyway to have it not override a non-zero initial value). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Trouble executing from NFS with latest 4.0-current
> :Execute anything from NFS would result in an "Input/output error", but if I > do > :a hexdump of the executable first, the execution would be successful. If I > :reverse the order, i.e., execute first then hexdump, execution would fail and > :hexdump would hang at "pgtblk". No problem with FFS. > : > :-lq > > Hmmm. It's working fine for me between two FreeBSD boxes. Do a > cvs diff against your entire /usr/src/sys tree first to make > sure you are up to date on all the patches. > > If it's still broken, we need to identify whether it is NFSV2, V3, > and whether the problem is related to FreeBSD<->FreeBSD or FreeBSD > w/ some other platform. Also any mount options, such as read and > write buffer settings, etc... > > -Matt > > Matthew Dillon > > Sorry, it was an outdated nfs.ko, please disregard the report. I had some trouble with making world because of the libcrypt stuff and I'm still struggling to get everything installed right. -lq To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: PNP and new bootloader with ELF kernel
On Thu, Jan 21, 1999 at 23:03:45 +, Tim wrote: > How do I set up the CSN now as I get CSN 1 disabled and CSN 2 disabled > on boot. you can put this pnp information in /kernel.config and, in your /boot/boot.conf, put load /kernel load -t userconfig_script /kernel.config boot this works fine on my box > Also I would like to remove the previous boot screen and boot straight > into the new bootloader, so can a dos partition be configured to boot > from the new bootloader just execute the following command : disklabel -B -b /boot/boot1 -s /boot/boot2 is which you boot from ex : disklabel -B -b /boot/boot1 -s /boot/boot2 wd0s1 -- mailto:ijl...@dragon2.net?subject="send pgp key" to get my pgp public key key finger print : FA 38 7E 91 FA 22 FA F6 63 04 E3 B5 A1 9F 0C CD To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: CVS tags to use?
On Thu, 21 Jan 1999, Jaye Mathisen wrote: > > The readme in /usr/share/examples hasn't been updated in a while... > > WHat tag should I be using now to track 3.0-current/3.1? (Not the 4.x > branch). > > Right now, I have tag=., and I can't get a compilable kernel to save my > life, problems in syscons. RELENG_3 Related to the above question though, is when should I drop my subscription to current, and move to stable (the mailing lists) I presume that for a while the current mailing list will be more relavent as people on it will at least remember similear problems, while the -stable list will have 2.2.x users who have never seen our porblems. Gradually this would change though, as the 4.x path moves beyond the 3.x track in significant ways. (Already a couple important changes are in the 4.x track) I guess the big questions is where do I look for 3.x Head-up messages. -- http://www.black-hole.com/users/henrymiller/ h...@black-hole.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: keymaps
On Fri, 22 Jan 1999, Gregory Bond wrote: > my vote: A version of the standard keymap with CapsLock and LeftCtl > functions > swapped so the control key is under my left finger like God intended! My vote is both of the above. I've never found a use for CapsLock, but LeftCtl is important enough that I wouldn't mind it duplicated. Most people I know are like this. (Yes of course there needs to be a way to get at capslock for those who really need it) -- http://www.black-hole.com/users/henrymiller/ h...@black-hole.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
New keyboard setting for sysinstall
I have modified sysinstall to include support for the Finnish
keyboards. (I know, we had a discussion less than 1 year ago
about the Swedish and the Finnish keyboards :-) I hope this
gets in 3.1-RELEASE as some Finnish users may be unaware of
the fact that they might use the Swedish keyboard settings...
Below is an uucoded diff file from /usr/src.
/Martti
begin 644
finnish.gz
M'XL("'=RIS8"`V9I;FYI]NV$?[9_2M0-ZW\(<(`F"227-EN>A'D>OP#N\`,$7!Q"7
m...@x,#EL5I'.;Q47Z=
)Y-\%J;IT9-P'(^2-&Y.L^1\Y^7%G/T03ICK,+?5=[U^
MVV-.K]?[K-%HV&JO5O3[CH\5#Y8_HL
PZK7JGPZ#(V,Z]F^/C6]:8LFP69Y=1
M>,7NW32/7[UX\/#%[9&ZUHQ8(Y6_>27Q]SE[]-U/3[YY
?GJ?#>)FDD_9('.[
M;?...@u#"=)?...@$_1qg`.:\;3N!G,@-X+1I/h...@-)\,d...@dl_7s6=5h=-img;^#
R1
M[MF\.9XF02-C>0(7\JL%.Y#D;^.ANI"_3?)<:VP^1LB;PS?3+!R+7_R"N`$Q
m...@4_%?c8p
Q%,OD$AN7`+%3>G_-F9))IJ]/W>E:98MW5:MV^U]HL4L<+ZH[?
M0ID*7KS04P]+?'@3L_CR^(+3
QR?3R6QOQ+_.^'V^7?`R229CN
M[4;32>ZV4V>WSN33/%.7ZHRLC4N#_>P2N&\_.V
3\[\TT&7(0-WF6Q[.S$WS,
M>]%%F+&#?);M<^L-_[?:E],HB^/)97BU-XQ'X3R=G>51)LJK=?K
MMZW*
\5MU_M76M8.7NKIZ&+MAN]]FX:])ROB`[M9WM!(;Q]?\2?"+0]&)'\/L
M^"*.QG4&Q=-X]HA;^=
4D'*1qg3u...@q'RFL=)]F_RZ[K>NM/8`IRHZ?!YVV
M:$^5I\.8/0_/8\:OOU?+,MI$5Z(!<^/R
5A>E#]&@NM?#17-R&HB;;;>XWR)C:T+^]7*[[7#6M!?'6`3[
)X$F$+>V$4Q9/9
M/MSWXC)R**LHYOM;=@/6CR8GVMP+N.W5QM^GN=6FOH<%13WA'2H;'_`VS?L,N73`.;C4A`L7-T?(5BXV^>
M"[#9B`1B;(*.#VN:,B38;$0",7:*CL\`\H1I8+,1"<38*W1\
CH.7QAK8;$0B
M%.NZ/0C4O>[&4+`<5I3L%4D7PCS.XG^:0L%_[HXG$`2B#'<4")-4!YN-2,2-
M
I!%L&DJ#(O%`L2'>]S?X!*87&MAL:DP\4&R.CJ=2VIX&-AN1@&*'Z/@`I3V=
M:6"S$0DH=H2.)P
!A--;`9B,24.PY.GX/,)#!%<%F(Q)0[`4Z_JFV'IIM-B*!
M&/LS.OY06]>"S48D$&/'Z/@(X`T.
f...@2;C4@@QJ;h...@-&(:V&Q$(A3K^N*F
M^!;?M%/Z=VU]-5V9@'X+9G&`L[BS<7]BW&$0B0.S&&
*`$_0V+NBR0^99[`O%
MIKA?+PU$`HJM86L'6^X*?%#LKTCR-YRI\X$&-AN-"2CV'3K^%4"^!TFP
v...@$
M%!NAX[%HN.3VGI\M]F(!&)L'1V_WJR3VN\LBFU#C&TB2=]"\GL;
M"2...@21g`/.E#:]\:S!NE(
E$*#;#J5`:B*2]F#1J[N0P;A)L-B(1BDWQ5;PT
M$`DHEF%K3'_C7+XH(9_G5XL2D<"N0)P?;`%$
(A0[&L?7_%5=`'_K$,`W4`+X
M6L#O7KS%(h$...@%_@&"D@/BN^%HAJ768&(NDH$NR"
MBUWP\%GQM4#X!\P,
1-)5)-...@%%[o@X;/B:X'p[s$s...@21sl@HM=\/!9\;5`
MW'Z+F8%(>K!G`15+6-XAVFR*I"L(<_
20L/SN:[,1B5(L#_OJ!*0PL*>21"F6
MAWUU`E(8B$0IEH=]=0)2&(A$*9:'?1FO9:"6H(*X"8A$
*9:'?7G(51R(1"F6
MAWUUR%48B$0IEH=]>]m6!...@$a5c>=A7YYB%09
$$
M*L;RL*_.,0L#D2C%\K"OSC$+`Y$HQ?*PKT[*"@.1>(OYI'88%AA,X<5-`I'X
M:QHM#FH6!^
T/<-`==!9[*>-NR/AFL$JB%.M@<'4QN'JX"OE=;1%>!R*A&(O!
MU<7...@zn$jy`?:(KP.1-+[``<.
/:'8#,\/2...@.1.-h.l2phg?1<;3N'8RY3#24>
M<4\H-L-]7&d...@$g^q9)0&(FDOEHS20"2=Q9)1&H
BDNXCVI8%(@d...@+@U$HL78
MTB!)G)868tl...@qmc00b19c2p.1>#MP!1_;'2!#JRP1A;^V%RH.
1-+&?F!`
m...@5$t4$*%$\i((HN4F`\+`6IN8UA/K8K/8...@1we>"N$MP?(,'M0/J2
.;[A?R[9;,L)[bzf...@9n68q>D&
M&E0)[BK!726X]02WX^/\:)LFH,6VE.!V0"W;
M[>,FN&VV*L%=);A))Q9;x02ws...@gle;V*R50GN*L%=);BK!'>5X/Z?)+B+
MPR>1X"x.58*[2g...@enz_^`k1+<58*[2G!7">xjp?w_e^#^+p...@p$1p``
`
end
---
Martti Kuparinen
http://www.hut.fi/~kuparine
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: Using LinuxThreads
d...@tar.com said:
%For kernel threading you just use libc. Whether or not libc generates
% thread safe (re-entrant) calls depends on whether its also linked
%with a library that 1) sets __isthreaded to a non-zero value, 2) has a
%_spinlock() implementationm, and 3) implements the functions
%flockfile, funlockfile, etc. There are also a few macros in header
%files that require _THREAD_SAFE to be defined to be thread safe.
%libc_r could be modified so that is doesn't replace libc, but rather
%is an addon, comparable to the kernel threaded libc case. But, it
%would involve a bit of work.
I thought so at first, but then I had to look at wait4 today and
now I'm not so sure. At least some of libc_r is very closely
tied to the uthread scheduler:
uthread_wait4.c:
#include
#include
#ifdef _THREAD_SAFE
#include
#include "pthread_private.h"
pid_t
wait4(pid_t pid, int *istat, int options, struct rusage * rusage)
{
pid_t ret;
/* Perform a non-blocking wait4 syscall: */
while ((ret = _thread_sys_wait4(pid, istat, options | WNOHANG,
rusage)) == 0 && (options & WNOHANG) == 0) {
/* Reset the interrupted operation flag: */
_thread_run->interrupted = 0;
/* Schedule the next thread while this one waits: */
_thread_kern_sched_state(PS_WAIT_WAIT, __FILE__, __LINE__);
/* Check if this call was interrupted by a signal: */
if (_thread_run->interrupted) {
errno = EINTR;
ret = -1;
break;
}
}
return (ret);
}
#endif
Russell
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: keymaps
Kazutaka YOKOTA wrote: > ScrollLock does "back scroll" too. You want both? My Libretto 70CT has no Scroll Lock, only a Pause. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: top broken - VM sideeffect?
yes matt said that it was broken... On Thu, 21 Jan 1999, Christian Kuhtz wrote: > > Looks like top's broken. It no longer shows swap space status on 4.0-CURRENT. > Side effect of the VM update? > > -- > "Logic is a little bird, sitting in a tree; that smells *awful*." > -- /usr/bin/fortune > > [Disclaimer: I speak for myself and my views are my own and not in any way to > be construed as the views of BellSouth Corporation. ] > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
