HEADS UP: I386_CPU
I've requested a change for UPDATING: The kerrnel option I386_CPU is now mutually exclusive with the other cpu types. If you have an i386 system, be sure that it only had this line. Remove it for all other configurations. Note that this does not remove i386 support. The actual commit message follows: Modified files: sys/i386/confNOTES sys/i386/i386identcpu.c machdep.c pmap.c support.s sys/pc98/confGENERIC sys/pc98/i386machdep.c Log: Stop doing runtime checking on i386 cpus for cpu class. The cpu is slow enough as it is, without having to constantly check that it really is an i386 still. It was possible to compile out the conditionals for faster cpus by leaving out 'I386_CPU', but it was not possible to unconditionally compile for the i386. You got the runtime checking whether you wanted it or not. This change makes I386_CPU mutually exclusive with the other cpu types, and tidies things up a little in the process. Reviewed by: alfred, markm, phk, benno, jlemon, jhb, jake, grog, msmith, jasone, dcs, des (and a bunch more people who encouraged it) Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crash dumps during initialisation
"Newton, Harry" wrote: > I think we might be talking at cross-purposes here. What does the kernel do > if it panics before the /etc/rc script is run ? (i.e. before the dumpon > command is issued ). I can't believe that it reads /etc/rc.conf and locates > the dump_dev entry to determine where it should put the crash dump. In > 4.4BSD one could specify: > > config kernel root on swap on dump on > > but this no longer exists in FreeBSD ? Is this right, and why ? We are missing some infrastructure to get this to work really early in the boot sequence - how early do you need? It should be possible to come up with some tweaks so that we can dump right after the device that we want to dump to has probed its disk label to get the partition sizes etc. Exactly when this happens is something I am not yet sure of. With some tweaks it should be moderately easy to get dumps enabled at the point where boot -v says "Creating DISK xxx" and your dump device is shown.. at least for drivers that use the minidisk layer. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/i386/conf GENERIC
Sheldon Hearn wrote: > > > On 15 Jan 2001 01:38:00 +0100, Dag-Erling Smorgrav wrote: > > > I'm tempted to suggest that the freebsd-small and / or PicoBSD gang > > would be the right people to ask to maintain i386 support in FreeBSD. > > Guys, was Matt Dillon's suggestion infeasible? Can't we keep CPU_I386 > support and just make it mutually excllusive with SMP? Right now it is. But as long as we support a super-kernel that runs on 386's through p3's we've got problems due to the lack of the cmpxchg instruction. ie: the moment you add I386_CPU, we switch to the inefficient instruction sequence: " pushfl ;" " cli ; " " cmpl%1,%3 ; " " jne 1f ;" " movl%2,%3 ; " "1: " " sete%%al; " " movzbl %%al,%0 ; " " popfl ; " .. which disables interrupts... Your 1GHz cpu uses the slower 386-friendly version instead of the optimal 486-and-above sequence: " cmpxchgl %2,%3 ;" " setz%%al ; " " movzbl %%al,%0 ; " The 486-and-above sequence is made MPsafe by adding the lock prefix when compiling under SMP mode. At the very least, we should warn people that they are shooting themselves in the foot if they add I386_CPU to their kernel (eg: copied from RELENG_4) and IMHO we should make the compile fail if you attempt to mix types. The patch below does this: http://people.freebsd.org/~peter/i386_cleanup.diff 1: it removes the 486-and-above code from the 386-only cases. 2: it removes the runtime conditionals that everybody currently executes if I386_CPU is present 3: prevents people shooting themselves in the foot at 'make depend' stage if they accidently activate I386_CPU. To be clear: THIS DOES NOT REMOVE i386 SUPPORT! It will actually slightly improve i386 runtime speed by removing the useless conditional tests. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
Jordan Hubbard wrote: > > Let's put sysinstall back in sbin/ then. It _used_ to live there until som eo > ne > > moved it. :) > > I won't argue - move away! Just have one of the CVSmeisters do it as > a repo-copy, of course. We cannot repo-copy it to src/sbin - there is a copy there already. We could blow the old one away and lose the history (RELEASE_2_0 and earlier) but I guess that is no big deal these days. Personally I would prefer it in src/usr.sbin/sysinstall and have it dynamically linked. The release crunchgen can still take the .o's and make the giant /stand version.. dynamic: 390769 shared: 892921 On the other hand, if we had the static version in src/sbin, we could have a "LINKS+= /sbin/sysinstall /stand/sysinstall" and blow away the old installed version with each make world. This would avoid POLA with people following old instructions to run /stand/sysinstall. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem installing on T20
"Daniel C. Sobral" wrote: > Wm Brian McCane wrote: > > > > I have an IBM T20 laptop that I want to run FreeBSD on. I have run > > [etc] > > You have a problem which is technically called an "IBM laptop". IBM, in > their infinite wisdom, decided to hibernate on the first partition it > doesn't recognize (hypothesis #1) or on the first partition identified > as 165 decimal (hypothesis #2). Whatever the case is, when the shitty > thing boots, the BIOS checks said partition to see if the system had > hybernated. Upon finding stuff there (the FreeBSD partition), it does > something which screws the system and locks up. Well, I can definatively answer one thing. If you change the partition ID to 166 and change the boot code to boot from that, then the laptops are just happy. Paul Saab has an A20 or A21 something that has this problem and he changed nothing but the partition ID to 166 and it solved the problem. As far as I'm concerned, this pretty much clinches the need to provide an alternate partition id booting capability so that people can enter 166 (openbsd) or 175 (believed free) when sysinstall is doing the setup and the bootblocks will just deal with it. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems related to disappearnce of libgcc_r
"David O'Brien" wrote: > On Tue, Jan 09, 2001 at 07:53:29PM +0200, Maxim Sobolev wrote: > > I wonder if anyone noticed that disappearance of libgcc_r will cause lot of > > ports to break. Therefore it would be nice if some form of compatibility sh im > > is provided, for example symlink from /usr/lib/libgcc.a to /usr/lib/libgcc_ r.a > > automatically created by installworld would do the trick nicely. > > I really don't want to propogate libgcc_r. Lets just fix the ports that > break. They can be seen at http://bento.freebsd.org/ We need to be a little careful for ports that are supposed to work on RELENG_4 and -CURRENT. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: proposed small change to .cshrc
Matt Dillon wrote: > > :On Tue, Jan 09, 2001 at 09:45:14AM -0800, Archie Cobbs wrote: > : > :> + if ( `basename $SHELL` == "tcsh" ) then > :> + bindkey ^W backward-delete-word > :> + endif > : > :I generally test for tcsh like this: > : > : if ( $?tcsh ) then > : bindkey ^W backward-delete-word > : endif > : > :-- > :Jon Parise ([EMAIL PROTECTED]) . Rochester Inst. of Technology > > How about this: > > if ( $?tcsh ) then > bindkey "^W" backward-delete-word > bindkey -k up history-search-backward > bindkey -k down history-search-forward > endif I was about to write a 'over my dead body' here, but I tried it out and discovered that the POLA (for tcsh users) is not too bad after all. In fact, I think I will add this to my .tcshrc :-) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sio && serial console in -current?
Matthew Jacob wrote:
>
> Yeah, weird. I'm at 9600... What's wierd is that it's got to be some userland
> induced thing because printouts from the kernel are fine until init is
> invoked...
This is an ongoing "Hmm, that is strange!" type problem. There are several
symptoms that I see at times:
1: console turns to garbage part way through /etc/rc and comes back to life
when /etc/rc exits and getty starts
2: console *disappears* part way through /etc/rc and comes back to life
when /etc/rc exits and getty starts
3: there is a burst of garbage after /etc/rc and before getty
4: the problem you describe I think I have seen a long time ago, once.
5: ^T and ^C and ^\ do not work ("not a controlling terminal") during
the execution of /etc/rc. There are several different ways this happens
depending on whether you go via the single user shell or not.
This happens on some machines semi regularly and occasionally on others and
"never" (yet) on some others. These are all serial consoles, and all
machines are different. SMP machines are far worse than UP, but my UP
machines have this sort of thing occasionally too.
> sio for alpha seems fine. wahhh.
I am sure we can break it for compatability :-)
> > On 09-Jan-01 Matthew Jacob wrote:
> > >
> > > Something wierd has been happening lately- the serial console on my i386
> > > machine works fine up until init is forked.. THen the output is mangled, and
> > > one gets replicated and/or mangled stuff. On a reboot I'm getthing things
> > > like:
> > >
> > > Waiting (max 60
> > > seconds) for
> > > system process
> > > `bufdaemon''''' to
> > > stop...stopped
> > >
> > >
> > > It's like the output is being repeated...
> > >
> > >
> > > Anyone seen same?
> >
> > Nope, I've been booting my laptop over 115200 serial console to a my 4.x
> > workstation during ACPI testing w/o any problems. I've also logged in and done
> > stuff on it over 115200 as well.
> >
> >
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Make release barfs...
Poul-Henning Kamp wrote: > > -- > >>> stage 4: populating /usr/obj/usr/src/i386/usr/include > -- > ===> rpcsvc > rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h > rpcgen: cannot find any C preprocessor (cpp) > *** Error code 1 David O'Brien would be the most likely candidate having renamed cpp to cpp0. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_fpa.c is broke again.
Jim Bryant wrote: > Hi, it looks like if_fpa.c has been modified again, but was checked > into CVS untested. Actually, the problem is the opposite.. It has not been modified, but some of the old backwards compatability infrastructure got cleaned out, leaving fpa broken. It doesn't appear to be too hard to adapt to newbus, is it a major showstopper for you? > from a basic GENERIC, with nothing other than the fddi and fpa devices > added to the config, I get the attached messages on compile. > > also, i noticed that in pdareg.h, that the full duplex options are > included in the structs, but they are used nowhere int he driver > itself, that seems to use the adapter in half duplex mode. Are there > plans to add the full duplex functionality in the near future? > > --- > cc -c -O2 -mpentiumpro -march=pentiumpro -pipe -Wall -Wredundant-decls -Wnest ed-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winli ne -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src/sy s -I/usr/src/sys/dev -I/usr/src/sys/../include -I/usr/src/sys/contrib/dev/a cpica/Subsystem/Include -D_KERNEL -include opt_global.h -elf -mpreferred- stack-boundary=2 /usr/src/sys/dev/pdq/if_fpa.c > /usr/src/sys/dev/pdq/if_fpa.c:141: syntax error before `config_id' > /usr/src/sys/dev/pdq/if_fpa.c:143: warning: function declaration isn't a prot otype > /usr/src/sys/dev/pdq/if_fpa.c: In function `pdq_pci_probe': > /usr/src/sys/dev/pdq/if_fpa.c:144: `device_id' undeclared (first use in this function) > /usr/src/sys/dev/pdq/if_fpa.c:144: (Each undeclared identifier is reported on ly once > /usr/src/sys/dev/pdq/if_fpa.c:144: for each function it appears in.) > /usr/src/sys/dev/pdq/if_fpa.c: At top level: > /usr/src/sys/dev/pdq/if_fpa.c:152: syntax error before `config_id' > /usr/src/sys/dev/pdq/if_fpa.c:154: warning: function declaration isn't a prot otype > /usr/src/sys/dev/pdq/if_fpa.c: In function `pdq_pci_attach': > /usr/src/sys/dev/pdq/if_fpa.c:159: `unit' undeclared (first use in this funct ion) > /usr/src/sys/dev/pdq/if_fpa.c:165: warning: implicit declaration of function `pci_conf_read' > /usr/src/sys/dev/pdq/if_fpa.c:165: `config_id' undeclared (first use in this function) > /usr/src/sys/dev/pdq/if_fpa.c:169: warning: implicit declaration of function `pci_conf_write' > /usr/src/sys/dev/pdq/if_fpa.c:176: warning: implicit declaration of function `pci_map_mem' > /usr/src/sys/dev/pdq/if_fpa.c:194: warning: implicit declaration of function `pci_map_int' > /usr/src/sys/dev/pdq/if_fpa.c: At top level: > /usr/src/sys/dev/pdq/if_fpa.c:210: variable `fpadevice' has initializer but i ncomplete type > /usr/src/sys/dev/pdq/if_fpa.c:211: warning: excess elements in struct initial izer > /usr/src/sys/dev/pdq/if_fpa.c:211: warning: (near initialization for `fpadevi ce') > /usr/src/sys/dev/pdq/if_fpa.c:212: warning: excess elements in struct initial izer > /usr/src/sys/dev/pdq/if_fpa.c:212: warning: (near initialization for `fpadevi ce') > /usr/src/sys/dev/pdq/if_fpa.c:213: warning: excess elements in struct initial izer > /usr/src/sys/dev/pdq/if_fpa.c:213: warning: (near initialization for `fpadevi ce') > /usr/src/sys/dev/pdq/if_fpa.c:214: warning: excess elements in struct initial izer > /usr/src/sys/dev/pdq/if_fpa.c:214: warning: (near initialization for `fpadevi ce') > /usr/src/sys/dev/pdq/if_fpa.c:216: warning: excess elements in struct initial izer > /usr/src/sys/dev/pdq/if_fpa.c:216: warning: (near initialization for `fpadevi ce') > /usr/src/sys/dev/pdq/if_fpa.c:218: warning: type defaults to `int' in declara tion of `COMPAT_PCI_DRIVER' > /usr/src/sys/dev/pdq/if_fpa.c:218: warning: parameter names (without types) i n function declaration > /usr/src/sys/dev/pdq/if_fpa.c:218: warning: data definition has no type or st orage class > /usr/src/sys/dev/pdq/if_fpa.c:210: warning: `fpadevice' defined but not used > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/GENERIC. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > > jim > -- > All opinions expressed are mine, if you| "I will not be pushed, stamped, > think otherwise, then go jump into turbid | briefed, debriefed, indexed, or > radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" > - - > [EMAIL PROTECTED] KC5VDJ - HF to 23cm KC5VDJ@NW0I.#NEKS.KS.USA.NOA M > HF/VHF: IC-706MkII VHF/UHF/SHF: IC-T81AKPC3+ & PK-232MBXGrid:
HEADS UP: crypt(3) changes.
I have made some changes to libcrypt in -current. The libscrypt/libdescrypt symlink sillyness is gone and the installed libcrypt is fully functional. Since pw(8) and passwd(1) create md5 hashed passwords by default (see the optional entry in loginl.conf), the default algorithm selection mechanisms are almost irrelevant. However, some third party programs might be affected. It is possible to set the default hash method (md5 or des) - for crypt(3) calls in the absence of other clues such as a $1$ or the like. See crypt(3) for details. This should be a pretty low-impact change, but it might be worth a little extra care if you have some application that does something strange with crypt(). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current on ibm tp a20p?
Christian Carstensen wrote: > On Fri, 24 Nov 2000, Rogier R. Mulhuijzen wrote: > > > 1) is this a CardBus card maybe? > > It happens with > >a) Lucent WaveLAN (silver) >b) 3com 3c589d > > > > 2) What does 'pccardc dumpcis' return? > > Code 85 not found > Code 85 not found > code Unknown ignored > Code 134 not found > Code 134 not found This means your pccard memory window overlaps something. Do you have an ATI rage chipset by any chance? My Vaio has one of these and its rom is 80K long and goes from 0xc -> 0xd3fff. pccardd defaults to 0xd for mapping the CIS which is right underneath the ROM. Try: pccard_mem="0xd4000" in /etc/rc.conf. Or even 0xd8000 if that doesn't work. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
"Matthew N. Dodd" wrote: > On Wed, 8 Nov 2000, Terry Lambert wrote: > > Maybe it would be possible to have a separate "VLBus" bus that > > went in before the EISA bus? > > I'm still not clear as to why we need to differentiate them. There really > is no requirement that slot 0 be present (other than it being standard and > all.) > > Can we even tell if which EISA devices are really VL devices in disguise? Do you want to know what is even funnier? One of my onboard ahc *PCI* controllers (7895 based I think) also responds to the EISA probes if I enable EISA. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sendmail related changes
Gregory Neil Shapiro wrote: > leifn> Is there a way to make make world use my own sendmail.mc? > > There will be soon. I hope to have it in place before or during BSDcon. Yes, there has been one for ages. Add: "SENDMAIL_CF= myfile.cf" to /etc/make.conf, and the sendmail makefiles will build it from myfile.mc and install it as part of every buildworld. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent kernels won't boot
Mike Smith wrote: > > > That was it. Is the 4MB kernel size limit documented anywhere? > > > > I don't know :-) I luckily noticed this by a lot of trials. > > I'm not aware of any 4MB limit on kernel size (and I ought to be if there > is one 8). Can you run the details past me? (I've regularly booted much > larger kernels in the past...) Uhh, are you sure? Ignore the size of the file, what does 'size(1)' say about these large kernels? Does text+data+bss excede 4MB? I have a nagging suspicion that we only set up 4MB of page tables during the early part of the bootstrap process in locore.s. (forgive me for not looking, I have a most evil headache and locore.s is no way to improve it :-). Thinking about it some more, there may be a 3MB limit as we load above 1MB. I recall some heavy magic with the SMP bootstrap where we only use one PTD slot for 0-4MB in early boot Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP - cvs-1.11 imported
I've updated the cvs base code. I'm pretty confident that it has come through ok, but please keep an eye out for weird stuff due to repairs of merge conflicts. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: config(8) weirdness
EEK! I will take a look at this right now... Motomichi Matsuzaki wrote: > > Hi. > > At Sun, 27 Aug 2000 15:16:01 +0200 (CEST), > Alexander Leidinger <[EMAIL PROTECTED]> wrote: > > > Can anyone success compiling kernel with the following config? > > > > > > # ATA and ATAPI devices > > > device ata > > > device atadisk # ATA disk drives > > > #device atapicd # ATAPI CDROM drives > > > device atapifd # ATAPI floppy drives > > > #device atapist # ATAPI tape drives > > > #optionsATA_STATIC_ID #Static device numbering > > > #optionsATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices > > > > > I've the same problem. > > > This is obvous BUG of config(8), newly introduced 'count' feature. > > In /sys/conf/files.i386 : > > dev/ata/atapi-all.c count atapicd > dev/ata/atapi-all.c count atapifd > dev/ata/atapi-all.c count atapist > > On the current implementation, > the first line is only effective, > > i.e. same as: > > dev/ata/atapi-all.c count atapicd > #dev/ata/atapi-all.c count atapifd > #dev/ata/atapi-all.c count atapist > > Then, atapi-all.c will be copiled only when atapicd is enabled. > > > To exchange the lines of files.i386 takes effect as a symptomatic therapy. > But..., fix for config(8) is needed. > > -- > Motomichi Matsuzaki <[EMAIL PROTECTED]> > Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: New OpenSSH
Kris Kennaway wrote: > On Sun, 10 Sep 2000, David Malone wrote: > > > On Sun, Sep 10, 2000 at 03:30:54AM -0700, Kris Kennaway wrote: > > > > > * better interoperability with other ssh2 clients/servers > > > > Any idea if it can read non-OpenSSH DSA host keys? The version in > > 4.1 doesn't seem to be able too, though it can read non-OpenSSH > > RSA host keys. > > Hmm, I'm not sure. Try out ssh-keygen -x and -X. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: pmap_enter: attempted pmap_enter on 4MB page
[EMAIL PROTECTED] wrote: > > > pci50: physical bus=-1061225984 > > > > A little dubious, I think. Below is the dmesg(8) output from > > kernel.old, my last good kernel built yesterday, booted with ``boot > > -v''. > > > > The enclosed patch might be relevant. I got similar problems without > it. A more comprehensive fix is in -current now. ivars shouldn't have been used there at all. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DPT revision....(broken drivers in -STABLE)
Jonathan Chen wrote:
> On Wed, Aug 23, 2000 at 01:51:16PM -0500, Visigoth wrote:
>
> > Sorry for the cross post but
> >
> > Would it be possible to revert the DPT commits made by peter on
> > Mon Aug 7 18:48:14 2000 in the RELENG_4 branch? It seems that the
> > dpt_attatch is failing in bus_alloc_resource(9) for the IRQ, and I have
> > production machines that need worlds built for some other updates as
> > well.. I would be happy to install a -CURRENT machine and help debug
> > until it works, but for right now, there is NO DPT support in -STABLE for
> > the DPT PM3334UW. I had a pr started, but haven't been able to get any
> > response from the current maintainer.
> >
> > I am going to install a -CURRENT machine with a DPT in it and
> > start the process of working on the issue, but it would be nice if we can
> > keep -STABLE stable... ;)
>
> I just updated on my -STABLE machine and ran into the same exact problem.
> I also have on the machine SMP with APIC. The fix for this problem is
> simple:
Argh! I have committed this now, both in -current and RELENG_4. Thanks!
> Index: dpt_pci.c
> ===
> RCS file: /export/ncvs/src/sys/dev/dpt/dpt_pci.c,v
> retrieving revision 1.17.2.1
> diff -u -r1.17.2.1 dpt_pci.c
> --- dpt_pci.c 2000/08/07 18:48:14 1.17.2.1
> +++ dpt_pci.c 2000/08/26 21:40:26
> @@ -106,7 +106,7 @@
> }
>
> rid = 0;
> - irq = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, RF_ACTIVE);
> + irq = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, RF_ACTIVE |
RF_SHAREABLE);
> if (!irq) {
> device_printf(dev, "No irq?!\n");
> error = ENOMEM;
>
> (Everybody in unison, say "Doh!")
> Since this didn't change in the past two months, I'm guessing this was
> caused by somebody else futzing with APIC. In any case, I don't see why
> the DPT card shouldn't be allowed to share IRQs, and I'm now running the
> latest -STABLE on my DPT card.
>
> PS. Sorrry Matt for foiling your evil plot to get a free RAID card. ;)
>
> --
> (o_ 1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2 _o)
> \\\_\Jonathan Chen [EMAIL PROTECTED] /_///
> <) No electrons were harmed during production of this message (>
> ~
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: World breakage from exit->sys_exit change?
Mike Meyer wrote:
> Peter Wemm writes:
> > Argh! I knew today was going to stay a bad day.
>
> I had similar thoughts about mine, both before I started the build,
> and afterwards.
>
> > I am pretty sure I know how to fix this and will commit a fix shortly. If
you
> > want to try now, edit sys/kern/syscalls.master:
> > < 1 STD NOHIDE { void sys_exit(int rval); } sys_exit sys_exit_args
void
> > ---
> > > 1 STD NOHIDE { void sys_exit(int rval); } exit sys_exit_args voi
d
> > and cd src/sys/kern; make init_sysent.c
> > Then your world should build ok.
>
> That fix indeed seems to work (it managed to build cat), and looks
> saner than mine.
Anyway, it should be all fixed now (and has been committed for a while).
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: World breakage from exit->sys_exit change?
Argh! I knew today was going to stay a bad day.
I am pretty sure I know how to fix this and will commit a fix shortly. If you
want to try now, edit sys/kern/syscalls.master:
< 1 STD NOHIDE { void sys_exit(int rval); } sys_exit sys_exit_args void
---
> 1 STD NOHIDE { void sys_exit(int rval); } exit sys_exit_args void
and cd src/sys/kern; make init_sysent.c
Then your world should build ok.
Mike Meyer wrote:
> Ok, I give up. It seems that the world change from exit to sys_exit
> broke the world build, but I can't figure out where. I've fixed every
> occurence of SYS_exit in the source tree (this one seems to be
> src/lib/csu/i386/crt0.c, but there were some in gdb as well), and
> removed /usr/obj - and I still get the following error from
> buildworld:
>
> ===> bin/cat
> cc -O -pipe -march=pentium -Wall -Wformat -I/usr/obj/usr/src/i386/usr/inclu
de -c /usr/src/bin/cat/cat.c
> gzip -cn /usr/src/bin/cat/cat.1 > cat.1.gz
> cc -O -pipe -march=pentium -Wall -Wformat -I/usr/obj/usr/src/i386/usr/inclu
de -static -o cat cat.o
> /usr/obj/usr/src/i386/usr/lib/libc.a(_exit.o): In function `_exit':
> _exit.o(.text+0x2): undefined reference to `SYS_exit'
> *** Error code 1
> 1 error
>
> Is this one of those things that is going to require gyrations to get
> built?
>
> Thanx,
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Current Spontaneous Reboot
Noriyoshi Kawano wrote: > Me too. > But not SMP. Likewise. -current as of about an hour ago, no SMP, lotsa ram, buildworld about 3 hours ago. I saw no console because it was running X. > - dmesg > kernel trap 9 with interrupts disabled > > > Fatal trap 9: general protection fault while in kernel mode > instruction pointer = 0x8:0xc030ada4 > stack pointer = 0x10:0xcb6b1c30 > frame pointer = 0x10:0xcb6b1c80 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= resume, IOPL = 3 > current process = 298 (XF86_SVGA.xtt) > interrupt mask = > trap number = 9 > panic: general protection fault > > > syncing disks... 78 > Fatal double fault: > eip = 0xc02d8bfd > esp = 0xcb6afffc > ebp = 0xcb6b0090 > panic: double fault > Uptime: 1h20m34s > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: cvs commit: src/lib/libftpio Makefile (fwd)
"David O'Brien" wrote: > On Thu, Jul 06, 2000 at 06:05:50PM -0700, Peter Wemm wrote: > > This is *not* the same as the a.out behavior which searched directories to > > find the largest number. ELF uses the symlinks and no searching, which is > > why ld and ld-elf.so is faster when locating directories and does not need > > ldconfig or the ld.so.cache. > > Correct me if I am wrong, ld-elf.so does still need ldconfig. And > ld-elf.so does not use the symlink (if it did compat libs would not > work). The ELF ldconfig does nothing except set the default search path for finding libraries: peter@t8000[12:54am]~-183> hd /var/run/ld-elf.so.hints 45 68 6e 74 01 00 00 00 80 00 00 00 37 00 00 00 |Ehnt7...| 0010 00 00 00 00 36 00 00 00 00 00 00 00 00 00 00 00 |6...| 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0080 2f 75 73 72 2f 6c 69 62 3a 2f 75 73 72 2f 6c 69 |/usr/lib:/usr/li| 0090 62 2f 63 6f 6d 70 61 74 3a 2f 75 73 72 2f 58 31 |b/compat:/usr/X1| 00a0 31 52 36 2f 6c 69 62 3a 2f 75 73 72 2f 6c 6f 63 |1R6/lib:/usr/loc| 00b0 61 6c 2f 6c 69 62 00 |al/lib.| ld(1) resolves the symlinks. ld-elf.so.1 searches for the full filename in the directory path from ldconfig -elf. objdump --all-headers /usr/bin/vi: ... Dynamic Section: NEEDED libncurses.so.5 NEEDED libc.so.4 .. All ld-elf.so.1 has to do is look for the first one of: /usr/lib/libc.so.4 /usr/lib/compat/libc.so.4 /usr/X11R6/lib/libc.so.4 /usr/local/lib/libc.so.4 This is just done with a series of open(2) calls and is very cheap. The first one it can open it uses. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: cvs commit: src/lib/libftpio Makefile (fwd)
Kris Kennaway wrote: > If anyone has done a make world within the past few days you should remove > your libftpio.6 since the version bump was made in error. It's now back to > libftpio.5. It actually does not matter. Which major version new programs are linked against is controlled by which file the symlinks point to. peter@t8000[6:01pm]/usr/lib-113> ls -l libftpio.so* lrwxr-xr-x 1 root wheel 13 Jun 28 12:49 libftpio.so@ -> libftpio.so.5 -r--r--r-- 1 root wheel 14680 Jun 10 20:14 libftpio.so.5 -r--r--r-- 1 root wheel 17244 Jun 5 19:43 libftpio.so.6 -lftpio will follow the symlink, and read the headers in libftpio.so.5: 8000# objdump --all-headers /usr/lib/libftpio.so | grep SONAME SONAME libftpio.so.5 As a result, all programs linked with '-lftpio' will end up linking against libftpio.so.5 explicitly. This is *not* the same as the a.out behavior which searched directories to find the largest number. ELF uses the symlinks and no searching, which is why ld and ld-elf.so is faster when locating directories and does not need ldconfig or the ld.so.cache. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Config problems
Chuck Robey wrote: > deviceda0 at scbus 0 target 0 > deviceda1 at scbus 0 target 2 > deviceda2 at scbus 1 target 1 > > devicecd0 at scbus? > devicecd1 at scbus? Change 'scbus 0' to 'scbus0' and 'scbus 1' to 'scbus1' and the gethints.pl script will understand it. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Config problems
Chuck Robey wrote: > On Sun, 25 Jun 2000, Kenneth Wayne Culver wrote: > > > Hey chuck, except for the SMP stuff, your config looks mostly like mine (I > > only have a cpu line for i686) Let me know if there's anything I can do to > > help though. > > I'm about ready to post again, so this is good timing. > > I got the totally vague warning from gethints.pl to quiet by making my > disk section look much like the NOTES file. I then ran it by a brand new > config, and out spewed more than 25 errors. The entire section on wiring > down disks fails, and also all the stuff on npx, even tho that part was > copied verbatim from NOTES. You should get no errors from gethints.pl based on the disk section in NOTES file because those entries are actual hints for device.hints, not something that you put in a config file and feed to gethints.pl. > I have an Adaptec dual channel controller on my motherboard, and I have 3 > disks and 2 cdroms, which I want to wire down. There's lines in the NOTES > examples whose meanings just make no sense to me. Let me do a bit of > quoting: > > [from NOTES] > hint.scbus.0.at="ahc0" > hint.scbus.1.at="ahc1" > hint.scbus.1.bus="0" > hint.scbus.3.at="ahc2" > hint.scbus.3.bus="0" > hint.scbus.2.at="ahc2" > hint.scbus.2.bus="1" > hint.da.0.at="scbus0" > hint.da.0.target="0" > hint.da.0.unit="0" > hint.da.1.at="scbus3" > hint.da.1.target="1" > hint.da.2.at="scbus2" > hint.da.2.target="3" > hint.sa.1.at="scbus1" > hint.sa.1.target="6" > > > What does ``hint.scbus.1.bus="0"'' mean? Do I have to stick a number > after the "device ahc" and "device scbus" lines (the NOTES file > doesn't). Are there any other oddities I ought to know of? It works the same as the other devices: 'device scbus1 at ahc1 bus 0' becomes: hint.scbus.1.at="ahc1" hint.scbus.1.bus="0" When you have a trailing '?' character in an 'at' binding, you leave it out. eg: hint.scbus.1.at="ahc" (which would have meant "device scbus1 at ahc?") You do not stick numbers after the 'device ahc' and 'device scbus' lines. The device wiring comes from the hints (either /boot/device.hints or the statically compiled in hints) Perhaps you should post your old *ORIGINAL* config file and I'll do a worked example conversion... Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Config problems
Chuck Robey wrote: > I am getting a config error with the new gethints.pl stuff: > > unrecognized config token 1 This means the decoder for 'device ed0 at isa? flags 1' style lines did not like what was in one of your device lines. I have added a new line number message in the error so that it should be easier to spot what is going on. /home/ncvs/src/sys/i386/conf/gethints.pl,v <-- gethints.pl new revision: 1.5; previous revision: 1.4 Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: softupdates (a bit late, but...)
The softupdates license has changed to 2-clause BSD-style with no more restrictions on use. The files were repocopied into their "natural" locations (sys/ufs/ffs) so that symlinks are no longer required. This has been done retroactively to all older branches that have the soft updates code. The actual process of doing the copies etc got messed up, but it should have been sorted out now. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/contrib/softupdates softdep.h ffs_softdep.c
Adrian Chadd wrote: > On Thu, Jun 22, 2000, Julian Elischer wrote: > > [snip NetBSD making softupdates a mount option] > > > They obvioulsly DIDN'T discuss this with Kirk! > > > > this is not what he wants and for good reason.. > > see the long discussion son this topic in the archives. > > I've read the mail archives as to why. If these issues are still > valid, I'll withdrawl the idea :) Because fsck is supposed to be able to do things more intelligently when it knows the *previous* mount state, not the current state. ie: if a disk was last mounted in softupdates mode, fsck is supposed to do stuff differently (possibly doing as little as a superblock cleanup and deferring the lost-space recovery until much later). For the NetBSD version to work, what needs to happen is that the -osoftdep flag needs to be propagated to the superblock so that after reboot, fsck knows what to do. When it is next mounted, then update it to the new state. This gives us the ability to use the 'softdep' flag in fstab but without breaking fsck. Sure, fsck can look at what is *now* in fstab, but not what mode a given filesystem was in the last time it was mounted. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC from today does not detect system console on my box
"Jordan K. Hubbard" wrote: > > Err.. how did you run it? 'perl < MYKERNEL'? If you run 'perl MYKERNEL' > > it will generate nothing because I was kinda lame and didn't know how to do > > argument parsing. :-] > > Yep, I ran it exactly as you specified in your "HEADS UP" message > to -current. It generates no output for either GENERIC or for my > kernel config file: > > jkh@zippy-> perl gethints.pl < ZIPPY > jkh@zippy-> perl gethints.pl < GENERIC Uhh... gethints.pl is a once-only tool to help you get from an old config to a new one. Once you have stripped out the hints, gethints will find none. GENERIC.hints is the corresponding hints file for what used to be in GENERIC. If you had copied GENERIC to ZIPPY, you should probably use GENERIC.hints as your skeleton for /boot/device.hints Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC from today does not detect system console on my box
Chris Costello wrote:
> On Friday, June 16, 2000, Peter Wemm wrote:
> > Err.. how did you run it? 'perl < MYKERNEL'? If you run 'perl MYKERNEL'
> > it will generate nothing because I was kinda lame and didn't know how to do
> > argument parsing. :-]
>
>Couldn't have hurt to ask.
>
> while (defined($ARGV[0])) {
> # ... parse ...
> shift;
> }
>
>It'd work as perl script.pl arg1 arg2 ... or as ./script.pl
> arg1 arg2 ... (if +x).
How about that and as a stdin pipe as well if no args are specified?
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC from today does not detect system console on my box
"Jordan K. Hubbard" wrote: > > Did you ran the Perl skript to create the hints file and > > then change your KERNEL config like this? > > Yep! The Perl script generates no output and my kernel config file > matches the requirements perfectly. Though, if you'll read the > subject line again, you'll see I used GENERIC for my test anyway. :) Err.. how did you run it? 'perl < MYKERNEL'? If you run 'perl MYKERNEL' it will generate nothing because I was kinda lame and didn't know how to do argument parsing. :-] To be sure, next time you boot, press space to get into the loader and do a 'show' - you should see your hints in the environment. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC from today does not detect system console on my box
"Daniel C. Sobral" wrote: > "Jordan K. Hubbard" wrote: > > > > I tried booting a kernel this morning, just to see Peter's new > > "lean-n-mean" kernel config format in action, and I turned my > > workstation into a headless server in the process. :-) > > > > Most notably, these former entries were now missing from my dmesg > > output when I logged in remotely and poked around: > > > > atkbdc0: at port 0x60,0x64 on isa0 > > atkbd0: irq 1 on atkbdc0 > > psm0: irq 12 on atkbdc0 > > psm0: model Generic PS/2 mouse, device ID 0 > > vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 > > sc0: on isa0 > > I was just wondering what happens if no device.hints exists. It seems it > isn't installed by installkernel target, and the above are all part of > it. IMHO, the hints are a machine property, not a per-kernel property. Setting up a /boot/device.hints is (IMHO) a one-time task that never needs to be done more than once, and (again IMHO) the 'make install' had damn well better not mess with. This is especially important once kget(8) becomes the equivalent of 'kenv | grep '^hint' > /boot/device.hints' or something so that the userconfig.4th changes get saved for next time. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP!: config changes...
Chia-liang Kao wrote: > Hi, > > Is there anyway to put the device.hint stuff into kernel nevertheless? > My diskless box fetches the kernel would know nothing about things reside > in device.hint. That is what the hints directive is for. you could create a file "diskless.hints" and add the line to your config file: hints "/wherever/diskless.hints" and the contents of that file would be statically compiled in. You can still override them at boot time if you wish, but the basic set will be there. This is what GENERIC does right now. It compiles GENERIC.hints straight in. (see hints.c in compile/YOURKERNEL) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP!: config changes...
Peter Wemm wrote: > # update /boot/loader.conf > cd src/sys/boot; make obj depend all install Of course, it would be just my luck that there is a loader bug right now, and this command will throw you into the fire. ;-( If your loader complains about not being version 0.3+ or later and aborting, comment the version tests out of /boot/loader.4th as an interim. I have also just committed a last-minute introduced bug that prevented static hints files with full-line comments in them from working properly. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP!: config changes...
Matthew Jacob wrote: > > > # I cannot stress this enough: **SAVE A WORKING /kernel** > > cp /kernel /kernel.works > > Save a working /modules and /boot as well. Which is always good advice, but I can clarify the effect on these... The only change in /boot is /boot/defaults/loader.conf: diff -r1.26 -r1.27 24c24 < loader_conf_files="/boot/loader.conf /boot/loader.conf.local" --- > loader_conf_files="/boot/device.hints /boot/loader.conf /boot/loader.conf.local" ie: /boot/device.hints is searched for. If you override loader_conf_files in your own loader.conf, you will need to take care of it (or use static hints). /modules should be unchanged by these commits. I wimped out and have not set GENERIC use device.hints yet as I'm not sure how best to connect that up to the release process. Also note: if you do not use loader(8), you *MUST* compile the hints in statically. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP!: config changes...
*** CAUTION IS REQUIRED ***! FYI, an intrusive commit has been done that requires careful attention. If you ignore this or mess it up, it can burn your house down, shoot your dog, close your bank accounts, report you to the IRS, or maybe even something bad. An old version 51 config(8) will (I think) generate a buildable config. If you ignore the dire warnings and manage to get a kernel built somehow, you will have a less than fulfilling experience. Most likely you just will not be able to type anything as your console would be dead as the atkbd controller will have failed to probe. In a nutshell, what you need to do is: # update /usr/sbin/config cd src/usr.sbin/config; make cleandir obj depend && make all install # update /boot/loader.conf cd src/sys/boot; make obj depend all install # update your kernel config files cd src/sys/i386/conf perl gethints.pl < YOURKERNEL > /boot/device.hints vi YOURKERNEL change *ALL* "device foo0 at isa? port blah etc" to "device foo" - see GENERIC for examples. All the 'at ? port ?' stuff is handled by the new /boot/device.hints See GENERIC - if you use a static limited device (eg: fe, aha, le, etc) where GENERIC has 'device le 1' *and* you had more than one device (eg: device le0 at ..., device le1 at ...) then you will need to specify more units. (eg: "device le 2" in the example above.) # I cannot stress this enough: **SAVE A WORKING /kernel** cp /kernel /kernel.works This is not quite yet complete, but is fully functional. There may still be some syntax changes to the hints stuff in the future, so pay attention. With respect to LINT - we had a lot of documentation in the file that would have been lost if the 'at isa? port ...' was removed, so I've copied it to a file called 'NOTES' which is NOT something you can feed to config. This file is documentation only. I chose to not keep both LINT and NOTES as they would have gotten out of sync fairly quickly. However, it is still possible to generate a buildable test-coverage LINT. ie: cd src/sys/i386/conf; make LINT; config LINT LINT will be generated from the NOTES file. Hopefully I have not forgotten anything. I had to make minor tweaks after I generated and uploaded the patches. I have not tested it as well on the Alpha as I have on the i386. --- Forwarded Message Date:Tue, 13 Jun 2000 15:28:50 -0700 From:Peter Wemm <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/usr.sbin/config Makefile config.h config.y ... peter 2000/06/13 15:28:50 PDT Modified files: usr.sbin/config Makefile config.h config.y configvers.h lang.l main.c mkheaders.c mkmakefile.c mkoptions.c sys/alpha/conf GENERIC SIMOS sys/boot/forth loader.conf sys/conf Makefile.alpha Makefile.i386 Makefile.pc98 files.alpha files.i386 files.pc98 sys/i386/confGENERIC NEWCARD NOTES sys/i386/isa if_cx.c sys/i4b/driver i4b_isppp.c sys/i4b/tina-dd i4b_tina_dd.c sys/kern subr_bus.c sys/pc98/confGENERIC sys/pc98/pc98wd.c Added files: sys/alpha/conf GENERIC.hints gethints.pl sys/i386/confGENERIC.hints Makefile NEWCARD.hints gethints.pl makeLINT.pl sys/pc98/confGENERIC.hints gethints.pl Removed files: usr.sbin/config mkioconf.c sys/i386/confLINT Log: Borrow phk's axe and apply the next stage of config(8)'s evolution. Use Warner Losh's "hint" driver to decode ascii strings to fill the resource table at boot time. config(8) no longer generates an ioconf.c table - ie: the configuration no longer has to be compiled into the kernel. You can reconfigure your isa devices with the likes of this at loader(8) time: set hint.ed.0.port=0x320 userconfig will be rewritten to use this style interface one day and will move to /boot/userconfig.4th or something like that. It is still possible to statically compile in a set of hints into a kernel if you do not wish to use loader(8). See the "hints" directive in GENERIC as an example. All device wiring has been moved out of config(8). There is a set of helper scripts (see i386/conf/gethints.pl, and the same for alpha and pc98) that extract the 'at isa? port foo irq bar' from the old files and produces a hints file. If you install this file as /boot/device.hints (and update /boot/defaults/loader.conf - You can do a build/install in sys/boot) then loader will load it automatically for you. You can also compile in the hints directly with: hints "device.hints" as well. There are a few things that I'm not too
Re: mktemp() patch
David Scheidt wrote: > On Wed, 7 Jun 2000, Kris Kennaway wrote: > > :This patch was developed by Peter Jeremy and myself and increases the > :number of possible temporary filenames which can be generated by the > :mktemp() family, by more densely encoding the PID and using a larger set > :of characters to randomly pad with. > : > :Instead of using only alphabetic characters, the patch uses the following > :character set: > : > :0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~ > > ":" is path seperator in Apple's HFS filesystem. "@" is used as the line > erase character in some shells. "#" is rubout in some shells. # is a comment ~ at the beginning is a ~username ^ is an alias for | in old shells These could matter in the light of mktemp(1). file=`mktemp foo.` Why 74 characters? Why not 64? Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel config errors...
Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Donn Mi > ller writes: > >After a recent cvsup, I'm getting this error after doing a config -r: > > > >../../conf/files: coda/coda_fbsd.c must be optional, mandatory or standard > > recompile config(8). > > I don't know why peter didn't bump the magic-config-version-number. I did. But it seems the magic number checking is done after other work. :-( Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
"Daniel C. Sobral" wrote: > Mike Smith wrote: > > > > > VMware intercepts the inb/outb instruction to port 0x5658 when the eax > > > register is set to a magic value, otherwise it would be handled as any > > > other ports. > > > > I think, again, that adding an i386-specific word that detects the > > presence of VMware is a perfectly sensible idea, and it should simply be > > done. > > Given the way VMware works, I'd have nothing against making it a FICL > words, except... > > ...VMware is a port. For some reason, I dislike the idea of having > support targetted at exclusively one specific port. Though we have > features added specifically to deal with certain ports, they were all > more generic features. > > So, I see two alternatives here: > > 1) Add the Forth words that allow execution of assembler code (CODE > ;CODE), and hex-compile the code (as having a whole assembler around is > unreasonable). This enables similar problems to be solved without having > to change loader(8). > > 2) Add the VMware detecting to FICL, as originally suggested. > > While I have reservations about the latter, I'm not objecting to it. If > you, Luoqi, prefer to go that way, go ahead. Why make #2 vmware specific? Why not set $emulation to native,vmware,bochs, etc. This is applicable to any platform that may have some sort of emulator. Putting it in an environment variable has the advantage of having it passed through to the kernel environment too, so you might be able to use it in /etc/rc* as well. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
Christopher Masto wrote: > On Fri, Jun 09, 2000 at 01:14:35PM -0400, Jeroen C. van Gelderen wrote: > > I'm not sure it is a good idea to name this variable VMWare as > > that is implementation specific. It may be better to have a var > > named 'emulation' set to 'none' or 'vmware' or 'bochs' or ... > > Mmm.. or, giving forth the ability to do in/out instructions, so the > non-generic code would be entirely in the add-on forth piece. I'm > not sure if there are any security implications there.. at boot time > the machine is essentially as single-user as it's ever going to be. I prefer 'emulation' being set to 'native', 'vmware' etc. Consider that there is IA64, Alpha, sparc, ppc etc to deal with. Teaching the ficl scripts to do inb/outb would be bad. It would be much better to have a generic mechanism for informing the loader about possible emulation environments, eg you are using the IA64 emulator under an x86 box, or an x86 emulator on an Alpha, or an Alpha SIMOS emulation under x86, or whatever. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/lkm
Kent Hauser wrote: > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message Heh. Well, I can probaby answer the question you meant to ask. Yes, /dev/lkm is gone. See kldload(2) and kldload(8) etc. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP - minor API change in -current's old ISA drivers.
I've made old-style ISA drivers self identifying and got rid of the dreaded isa_compat.h table. As a consequence, the 'struct isa_driver' stuff has changed slightly to store the additional data that was in the compat tables and a new line is required (COMPAT_ISA_DRIVER()) so the driver registers itself with the device subsystem. This works essentially the same way as the COMPAT_PCI_DRIVER() stuff works. There shouldn't be any noticable changes except for the slight tweaks to the individual drivers. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: pmap_enter: attempted pmap_enter on 4MB page
Peter Wemm wrote: > Martin Cracauer wrote: > > I'm getting the appended panic when starting Xfree86 under a -current > > from today. I rebuild/reinstalled binutils (and kernel afterwards) > > and sys/boot. > > I think I know what is causing this. We're passing a non-page-aligned > address to pmap_kenter() in mem.c... I think I know how to fix it, but > I need to check if that is the actual problem. (I'm 99% sure it is) I've committed a fix for this now. Rev 1.84 of i386/i386/mem.c should stop this. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mpboot.s patch
Manfred Antar wrote: > At 04:33 AM 5/24/2000 +0200, [EMAIL PROTECTED] wrote: > >> >> With a current kernel I get this when booting: > >> >> > >> >> Programming 24 pins in IOAPIC #0 > >> >> AP #1 (PHY# 12) failed! > >> >> panic y/n [y] panic: bye-bye > >> >> mp_lock = 0001; cpuid = 0; lapic.id = > >> >> Uptime: 0s > > > >[...] > > > >> I think this has something to do > >> with the new binutils as a kernel built on the 14th and restored via tape works fine but if i > >> check out the sys tree from the 14th and build a kernel it panics at the A PIC probe. > > > >Try the enclosed patch. > > > >- Tor Egge > Tor > Works great > The patch didn't apply I think there is a "data32" > in the patch that isn't in the mpboot.s file > but when I applied the patch manually an added the data32 > the kernel built fine and boots both cpu's without a problem. > > although mptable still causes a panic : > > panic: pmap_enter: attempted pmap_enter on 4MB page > mp_lock = 0002; cpuid = 0; lapic.id = > boot() called on cpu#0 > Thanks > Manfred I believe I have fixed the 4MB pmap_enter related bugs. Please re-cvsup and try again. You are looking for i386/i386/mem.c: revision 1.84 date: 2000/05/24 14:22:22; author: peter; state: Exp; lines: +2 -1 pmap_enter() masked off the page offset bits, pmap_kenter() did not. This (I believe) is the cause of the XFree86 startup and mptable(8) panics when programs were reading from /dev/mem at non-page-aligned offsets. The offsets were being converted into random page flags in the page tables. :-( (including PG_PS = 4MB page size) Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: pmap_enter: attempted pmap_enter on 4MB page
Martin Cracauer wrote: > I'm getting the appended panic when starting Xfree86 under a -current > from today. I rebuild/reinstalled binutils (and kernel afterwards) > and sys/boot. I think I know what is causing this. We're passing a non-page-aligned address to pmap_kenter() in mem.c... I think I know how to fix it, but I need to check if that is the actual problem. (I'm 99% sure it is) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/contrib/ncurses/include curses.h.in src/contrib/ncurses/ncurses/trace lib_trace.c
"Andrey A. Chernov" wrote: > On Wed, May 24, 2000 at 02:09:24PM +1000, Bruce Evans wrote: > > > Previously it breaks system's /bin/sh so sh's trace() was wrongly renamed to > > > sh_trace() instead of fixing ncurses. > > > > FYI, it may also break ftp, but the problem is only visible when ftp is lin ked > > static, due to the problem with dynamic linkage in ld: > > > > /usr/src/usr.bin/ftp/cmds.c:906: warning: initialization makes integer from pointer without a cast > > /usr/libexec/elf/ld: Warning: size of symbol `trace' changed from 4 to 5 in lib_trace.o > > /usr/libexec/elf/ld: Warning: type of symbol `trace' changed from 1 to > 2 in lib_trace.o > > Yes, this bug is very dangerous and many places are affected so I fix > it immediately. > > The fact our ld can't detect multiply definitions when linking shared is > another issue - I recently send this to -current, but still got no reaction. This is by design. The symbol search order for dynamic linking is very clearly defined, and you *can* have lots of duplicate symbols. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Major device numbers and mem device redesign
Mark Murray wrote: > > > > I want to commit a new /dev/random RSN, so I'll be needing a major > > > > device; what is the procedure for getting one? I know how to steal one, > > > > but ISTR that this is not how it is done. > > > > > > Just edit sys/conf/majors and claim the next available number. > > > > You don't need one. You can use the same major/minor numbers. You can > > register multiple cdevsw's per major number with make_dev(); (do NOT > > use cdevsw_add() for this). > > How does this work for all the routines? When you register the > "new" minor number, can you be specifying new read/write/poll/ioctl/etc > routines? Yes. Each instance of make_dev() takes a cdevsw argument for the minor number in question. So, you could have /dev/mem read/write/ioctl etc routines for major 2, minor 0 and 1, while have minors 3 and 4 being installed with their own open/close/read/write/etc routines. Devices are looked up as a hash of major+minor, and the devsw entries from that point on. Presently: make_dev(&mem_cdevsw, 0, UID_ROOT, GID_KMEM, 0640, "mem"); make_dev(&mem_cdevsw, 1, UID_ROOT, GID_KMEM, 0640, "kmem"); make_dev(&mem_cdevsw, 2, UID_ROOT, GID_WHEEL, 0666, "null"); make_dev(&mem_cdevsw, 3, UID_ROOT, GID_WHEEL, 0644, "random"); make_dev(&mem_cdevsw, 4, UID_ROOT, GID_WHEEL, 0644, "urandom"); make_dev(&mem_cdevsw, 12, UID_ROOT, GID_WHEEL, 0666, "zero"); make_dev(&mem_cdevsw, 14, UID_ROOT, GID_WHEEL, 0600, "io"); There is no reason at all to stop each of those minor devices having their own cdevsw and handler functions. > I ask, as my RNG is a kld, and I want it to be as separate as possible > without getting ridiculous. Yes. You could just cut/paste the existing mem.c driver, and remove everything but the random hooks. In your init code register minors 3 and 4, and that's all you have to worry about. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Major device numbers and mem device redesign
Doug Rabson wrote: > On Sun, 21 May 2000, Mark Murray wrote: > > > Hi > > > > I want to commit a new /dev/random RSN, so I'll be needing a major > > device; what is the procedure for getting one? I know how to steal one, > > but ISTR that this is not how it is done. > > Just edit sys/conf/majors and claim the next available number. You don't need one. You can use the same major/minor numbers. You can register multiple cdevsw's per major number with make_dev(); (do NOT use cdevsw_add() for this). > > > > Also - Peter said something about the "mem" device needing > > to only contain the /dev/mem and /mem/kmem devices, and > > /dev/(random|urandom|null|zero) needing to move to MI areas. I have done > > this, as KLD's. Who wants to review? > > I'll take a look. > > -- > Doug Rabson Mail: [EMAIL PROTECTED] > Nonlinear Systems Ltd.Phone: +44 20 8442 9037 > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvsup on recent -CURRENT
Christian Weisgerber wrote: > (My original question should have gone out last Thursday but had > been stuck in a mail queue since.) > > Nick Hibma <[EMAIL PROTECTED]> wrote: > > > > TreeList failed: Network write failure: Connection closed > > > > Which host are you pilling from? I am slurping things out of > > cvsup.uk.freebsd.org and see the same messages. > > The problem was most apparent with cvsup.uk.openbsd.org, which is > probably the same machine. It was less severe with cvsup.pasta.cs.uit.no, > and didn't occur at all with cvsup3.de.freebsd.org and for localhost > connections. > > Disabling newreno > > sysctl -w net.inet.tcp.newreno=0 > > immediately fixed the problem, so I guess we have the culprit there. Yes, there is a known bug in the newreno code. It was committed prematurely (before Jayanth was ready). Jayanth has fixed the problem and is doing some serious testing before committing a fix and reactivating it. The newreno sysctl defaults to off for the time being and has for a few days. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/netinet tcp.h tcp_input.c tcp_output.c tcp_timer.c tcp_var.h
Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, "Andrey A. Chernov" writes: > >On Sat, May 13, 2000 at 01:39:11PM +0100, Brian Somers wrote: > >> This has been happening to me in environments with high packet loss, > >> and before the NewReno changes went in. It was only happening in a > >> rather dubious environment were there was high packet loss > >> (compressed PPP over uncompressed PPP over a saturated ISDN dialup > >> that drops up to one in every three packets). > > > >But this bug is gone (for me at least), when NewReno is turned off. > >Is it means that NewReno cause very high packet loss somehow? > > I can reproduce the problem when I cvsup over a lossy line, goes > away when newreno is disabled. Yes, I had Jayanth turn newreno off by default. Jonathan Lemon committed it before Jayanth was ready. We have fixed it locally and are running a torture test on it. The problem was that retransmits were sending the wrong data(!). Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: loader and libstand caution required.
Please be sure that you build and install libstand before building a loader! (or use buildworld, that should work) FICL is now active on the Alpha, and actually seems to work. The Alpha problems have been solved - it was an alignment issue of the end of code. Adding/removing code would make it fault. I am not sure if the x86 loader will be affected by a mismatch, but I would not like to bet on it. Be safe and make sure it is not linked against a stale libstand. :-) Cheers, -Peter --- Forwarded Message Date:Fri, 12 May 2000 15:45:16 -0700 From:Peter Wemm <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/sys/boot/alpha/common Makefile.common peter 2000/05/12 15:45:16 PDT Modified files: sys/boot/alpha/common Makefile.common Log: Reactivate the FICL hooks to make it be compiled in, but also initialize FICL. bootforth is now live on the Alpha! **BEWARE** - you *MUST* build and install a current libstand or you will most likely get zfree() panics at loader startup. We should now be able to set up the loader.conf stuff on the Alpha too. Revision ChangesPath 1.7 +9 -9 src/sys/boot/alpha/common/Makefile.common --- End of Forwarded Message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: EVENTHANDLER_DECLARE
Simon Shapiro wrote: > > On 10-May-00 Mike Smith wrote: > >> Sorry to bother y'll, but; > >> > >> Has anyone ever used that? I see no trace of any kernel > >> code calling it, and the at_shutdown code appears to be > >> gone. > > > > It's still used in the shutdown code; it was meant to be available for > > general use elsewhere, but I haven't seen anyone playing with it, so > > maybe the design tradeoffs were bad choices. > > I dunno. It seems to do anything I need; Call me with an argument. > I do not even need the priority. Well, you need to be called at "shutdown_post_sync" - anything before that is too soon as the kernel is still potentially pushing data out to the controller. This also happens to be where the module and bus shutdown events are called too. > >> BTW, for all it is worth, any caching controller not using > >> this is guaranteed to lose data. > > > > Wrong layer. You should be using the bus shutdown method; look at eg. > > the Mylex driver to see how this is done. You should probably call your > > flush routine from the suspend method as well. > > This is dangerous for the OSM. When the i2o OSM shuts an IOP > down, it is history. It will stop doing any work at all; network, > disk, console, mouse, whatever. I reserve that for really, really > shutdown/reset. > > This needs to happen after all other shutdown work was done, > but before a physical reset is sent to the hardware. > > There is no telling how long the IOP will take to return > from flush request. That is no problem.. you can take as long as you need. The filesystems are unmounted, all the system daemons have been shut down, all dirty data has been pushed to the controller, sync(2) has happened. The system will do nothing else until your controller's shutdown method has returned. If you want to reset it after doing the flush, there is nothing stopping you - you can do it however you need to. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: db 1.85 --> 2.x or 3.x?
Forrest Aldrich wrote: > I've been curious about this. Would someone clarify what in this > license prevents FreeBSD from including it, at some level? The problem is that we export the DB API from libc, and if anything uses the DB interface for a local application they'd be subject to the license below. Also, since DB 1.x is part of libc (including the getpwent() stuff for /etc/pwd.db etc), we're stuck with that file format as all binaries linked with that (or older libc major versions) versions of libc will not be able to lookup usernames if we change to 2.x. We could probably have a special hidden internal version of db 1.x to use within libc though. db 2.x+ is *way* too big to put in libc IMHO. For what it's worth, we do include it at "some level" - see ports/databases/ db.. This is safely out of the way of people using it accidently. > _F > > > Sleepycat Software Product Licensing > > Berkeley DB is an Open Sourcetm product, and complete source code is availabl e from our Web site. > > If you build an application that you do not redistribute outside of your site , or if you build an application and your source code is freely > available and redistributable by others, you may use Berkeley DB at no charge . You must, of course, abide by the terms of the copyrights > that apply to the Berkeley DB software. > > If you redistribute your application outside of your site and your source cod e is not freely available and redistributable by others, then you > require a commercial license from Sleepycat Software. Contact us for commerci al licensing terms and pricing. > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Old-style KLD file linuxelf found?
Donn Miller wrote: > Idea Receiver wrote: > > > > My mail server was down for pass few days. Hope I didnt miss anything > > important! > > > > Today, I try to make world and then rebuild the kernel. > > After I restart the machine, it shows "Old-style KLD file linuxelf found" > > and "Old-style KLD file linuxaout found" and then core dumped. > > > What you need to do is/ > > brandelf -t Linux /compat/linux/sbin/ldconfig > > and then reboot. Actually, I'm not sure that I see how this has to do with the message above. What was reported was a diagnostic message from the kernel module loader about having a kernel with the new kld interface but an old-style kld. The original poster has just got the kernel and kld's out of sync. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: loader updated to handle module metadata
Boris Popov wrote: > Loader was updated to handle module metadata which was introduced > by recent updates in kernel linker. This is related to a new way of > declaration of module dependencies. Not only that, but once we've settled on a versioning scheme, we will be using dependency tags with version numbers in order to detect incompatable interface changes before the kld gets a chance to crash the system. In a nutshell, we have a couple of MODULE_*() macros that create small data structures in linker_set's. The loader now knows *exactly* what is in the static kernel, and *exactly* what is inside a kld file. Remember, a kld can have zero or more "modules", and many do. miibus.ko, for example has about 12 modules and none are actually called "miibus". The key thin here is that if you compile 'device miibus' into your kernel, the loader can see it, and if you try and preload one of the miibus drivers (eg: if_dc, if_vr etc), the loader will now know that it does not need to preload a 'miibus' module from somewhere. How these are packaged has an effect on the overall scheme of things. As a hypothetical example, it would be possible to do this: ld -shared -o netbundle.ko setdef0.o if_dc.kld if_vr.kld if_xl.kld \ miibus.kld setdef1.o If you then preloaded 'netbundle', then you will get a whole stack of modules in one chunk. If you then kldload if_sk (another miibus user), it would automatically become a dependency on netbundle.ko in order to use the miibus code contained within it's internals. If you hand't loaded netbundle.ko (or something else that contained the miibus internals) then it would guess and try and load miibus.ko for you. One thing that I have on my TODO list is an inversion of the kernel build mechanism so that config(8)'s replacement arranges for building all these intermediate .kld file bundles according to your compile options. (eg: SMP, INVARIANTS etc). As a final step, the build process takes these .kld intermediate files and produces a static kernel and/or the final kld packaging you requested. Of course, getting this all finished and working is proving to be 'entertaining' :-). Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: module dependency metadata committed
A functional checkpoint of module metadata has been committed in -current. This is to provide a decent module-level dependency and versioning system, rather than the mostly-broken file-level system that presently exists. Not everything is in place yet, so the KMODDEPS lines in modules/*/Makefile are still there so that the current loader does the right thing still. There was work in the pipeline some time ago to implement the metadata strategy, but it's not strictly required yet. Dependency information is presently being done twice - once for loader's benefit (using KMODDEPS and DT_NEEDED), and one for the in-kernel code's benefit (using metadata in linker sets). I'm fairly sure it will work wothout causing too much trouble, I've been doing crash-and-burn testing over the last two days, and incidently, found some nasty bugs where I didn't expect to find them. The ipfw and linux kld's have a nasty habit of randomly corrupting the malloc pool on unload (even before my changes) - so don't try load/unload loops on those two. :-> See the commit message for more detail. There will be more work over the next few days, including resolving how the version numbers will be enforced. The present version numbers are ignored. The good news though.. once this is all done, the nasty suprises that turn up if you accidently get your kld's out of sync with a kernel should be a thing of the past. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone have OpenSSH + X11-fwd working?
"Andrew Reilly" wrote: > On Thu, Apr 20, 2000 at 07:23:00PM -0400, Brian Fundakowski Feldman wrote: > > On Thu, 20 Apr 2000, Chris Piazza wrote: > > > > > It's working from my 5.0 box to my 4.0-R box across town, too. > > > > > > -Chris > > > > Thanks. There's one data point. Now it's evidently nothing in the > > code, as it fails exactly the same way with 4.0-STABLE OpenSSH, > > -CURRENT OpenSSH, and my latest port update OpenSSH. > > > > I have no idea what it could be now. I suppose I'll investigate problems > > with XFree86 itself now :-/ This is extremely weird. > > Have you got "X11Forwarding yes" > > in the /etc/sshd_config? > > I had it set in my ~/.ssh/config file, but that made no > difference when the server was denying the requests. Thanks to > this conversation and man sshd, I've fixed the problem I was > having. Thanks. I hope we haven't changed the server default to stop forwarding.. the security risk is to the client, not the remote sshd server, therefore it is the client that should decide on whether to forward or not. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'miibus_if.h' file missing for 'dc' ethernet driver
attila! wrote: > > > ../../pci/if_dc.c:151: miibus_if.h: No such file or directory > > mkdep: compile failed > > 'find' on entire sys subsystem fails to show it, and I > pulled cvsups on 19th and 20th to see if it was in the > stream --nope. pulled a 'glimpse' of 'current' list but > found no reference. I suspect that you are missing 'device miibus' in your kernel config file... Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MAKEDEV warning
Warner Losh wrote: > In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes: > : >Almost none. I don't actually mount nfs partitions until I type mount > : >foo:/bar /bar. There's no network card active at that time anyway... > : > : But does the nfs filesystems you mount have any bdevs on them ? > > I've not mounted any filesystems when I get the message. I get it > when nfsd starts up in the boot process. Just a thought.. I got this message even though I thought I'd gotten rid of all bdevs.. It turned out there were some hidden in sub directories. Do a 'find /dev -type b' to be sure... :-) (if not, I'll shut up :-). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! linprocfs going away in 72 hours.
Julian Elischer wrote: > I presume this means that it should remain part of the standard system > but that the source should be moved to /sys/i386/linux? > > as long as it remains part of the system I don't care where it lives.. > It's too massively important to totally drop. Having it as a port was > a losing proposition. The biggest problem is that it re-opens a security hole that was explicitly patched in procfs. Also, the way I see it, the linux procfs should probably only be visible to linux sysvec processes... It would be a damn shame to let /compat/linux/procfs "sneak in" to the expected system requirements for bsd programs so that developers can use the easy way out rather than doing something properly. > Julian Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MLEN and crashes
Gary Jennejohn wrote: > Peter Wemm writes: > >Gary Jennejohn wrote: > >> Bruce Evans writes: > >> >On Mon, 3 Apr 2000, Gary Jennejohn wrote: > >> > > >> >> Bruce Evans writes: > >> >> >On Sun, 2 Apr 2000, Gary Jennejohn wrote: > >> >> >> I think we should nuke csu_hdr since it's not used anywhere. Is that > >> >> >> what you really mean ? > >> >> > > >> >> >Yes. I'm trying the following patch. Only tested at compile time. > >> >> > > >> >> [patch snipped] > >> >> > >> >> Thank you, Bruce ! This is pretty much the same patch I tested. > >> >> > >> >> So, should I commit it ? > >> > > >> >If you have tested it :-). > >> > > >> > >> I'm running with the change right now. No problems. > > > >I would prefer that we did this: > > > >#define MAX_LEN (min(128, MLEN)) > > > >or something like that. This should stop Bad Things happening if > >somebody recompiles with MLEN set specifically to 128 (and is an ideal > >MFC candidate for 4.x for when people set MLEN to 256 over there). > > > > This is a pretty good idea, too. But I already deleted csu_hdr in -current. > It would be easy enough to back out the change if there's consensus. No, leave csu_hdr deleted. I am only talking about also changing the #define MAX_LEN to something that's safe even if MLEN is overridden. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MLEN and crashes
Gary Jennejohn wrote: > Bruce Evans writes: > >On Mon, 3 Apr 2000, Gary Jennejohn wrote: > > > >> Bruce Evans writes: > >> >On Sun, 2 Apr 2000, Gary Jennejohn wrote: > >> >> I think we should nuke csu_hdr since it's not used anywhere. Is that > >> >> what you really mean ? > >> > > >> >Yes. I'm trying the following patch. Only tested at compile time. > >> > > >> [patch snipped] > >> > >> Thank you, Bruce ! This is pretty much the same patch I tested. > >> > >> So, should I commit it ? > > > >If you have tested it :-). > > > > I'm running with the change right now. No problems. I would prefer that we did this: #define MAX_LEN (min(128, MLEN)) or something like that. This should stop Bad Things happening if somebody recompiles with MLEN set specifically to 128 (and is an ideal MFC candidate for 4.x for when people set MLEN to 256 over there). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP buildworld times / performance tests
Matthew Dillon wrote: > > :> time make -j 20 buildworld build FreeBSD-current using 4.0 kernel > :> > :> 4745.607u 1673.646s 1:29:07.45 120.0% 1323+1599k 8237+251565io 1615p f+0w > :> > :> time make -j 20 buildworld build FreeBSD-current using 5.0 kernel > :> > :> 4696.987u 1502.278s 1:10:34.17 146.4% 1359+1641k 10889+4270io 1779pf +0w > : > :Can I ask why is there a huge difference in the number of io (251k vs 4k)? > :What is so different between 4.0 and 5.0 that causes this? > > That is very odd. I'm using the same make.conf on both machines > but even if they weren't the same 19 minutes should not make that sort > of difference in I/O statistics. One other possibility.. was the state of /usr/obj the same? make world does a lot less IO and is generally a fair bit quicker if /usr/obj is empty from the start. Just a thought... Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: INVARIANTS doesn't work?
Matthew Dillon wrote: > :Is there any good reason why we have two different options if they can > :only be used together? > : > :Greg > > I think it's so you can compile a kernel with INVARIANT_SUPPORT in > in order to support dynamic load modules which may have been compiled > with INVARIANTS. Or so that you can compile individual files with INVARIANTS by whatever means suits your needs. I'm aware of quite a few machines that run with #define INVARIANTS 1 near the top of kern_malloc.c. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Another current crash (cvs-cur.6183
Stephen Hocking-Senior Programmer PGS SPS Perth wrote: This one you need to tell phk about: this is one of his sanity checks that trapped and found an insane value. (and then crashed since you didn't have DDB) > #8 0xc0255f21 in Debugger (msg=0xc027b1e8 "d_iocmd botch") > at machine/cpufunc.h:64 > #9 0xc017385e in spec_strategy (ap=0xc5988df8) > at ../../miscfs/specfs/spec_vnops.c:438 > #10 0xc0173325 in spec_vnoperate (ap=0xc5988df8) > at ../../miscfs/specfs/spec_vnops.c:117 > #11 0xc020c3bd in ufs_vnoperatespec (ap=0xc5988df8) > at ../../ufs/ufs/ufs_vnops.c:2301 > #12 0xc0219167 in swapdev_strategy (ap=0xc5988e30) at vnode_if.h:923 > #13 0xc020d80e in swap_pager_putpages (object=0xc02f9ea0, m=0xc5988ee0, > count=1, sync=0, rtvals=0xc5988e74) at vnode_if.h:923 > #14 0xc020c427 in default_pager_putpages (object=0xc02f9ea0, m=0xc5988ee0, > c=1, sync=0, rtvals=0xc5988e74) at ../../vm/default_pager.c:133 > #15 0xc02175ea in vm_pageout_flush (mc=0xc5988ee0, count=1, flags=0) > at ../../vm/vm_pager.h:145 > #16 0xc021754d in vm_pageout_clean (m=0xc0464ae0) at ../../vm/vm_pageout.c:33 8 > #17 0xc0217e6e in vm_pageout_scan () at ../../vm/vm_pageout.c:914 > #18 0xc0218764 in vm_pageout () at ../../vm/vm_pageout.c:1350 > #19 0xc02565e0 in fork_trampoline () Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP; new options for -current!
If you are using old drivers that haven't been newbusified yet, you will need to add 'options COMPAT_OLDPCI' and/or 'options COMPAT_OLDISA' to your kernel configs and regenerate. Otherwise you will get compile failures. This is for -current only. 4.x is not affected. Incidently, I was encouraged to break the shims rather than put an option around them, but that was too drastic for now. This won't be happening in 4.x so be sure to consider which codebase you want to be running. Remember, -current is going to get rather bumpy soon once merges start happening.. -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: openssh question
Bill Fumerola wrote: > On Mon, Mar 06, 2000 at 11:29:39AM +0100, Edwin Kremer wrote: > > >" I do not recommend use of OpenSSH (or SSH1 generally, for that matter) . > > > > There hasn't been much followup on this. Anybody here who cares to > > comment on this? What issues are relevant here and how bad is it? > > I'm sure he'd much prefer you use the version that puts money in his pocket. To be fair, there *are* weaknesses in the ssh1 protocols. However, as you point out, it doesn't change the fact that Tatu Ylonen has a conflict of interest here. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Modem no longer found after u/g to 4.0-current - help
Mark Ovens wrote:
> On Sun, Mar 05, 2000 at 04:04:59PM +, Doug Rabson wrote:
> > On Sun, 5 Mar 2000, Mark Ovens wrote:
> >
> > > On Sun, Mar 05, 2000 at 01:04:23PM +, Doug Rabson wrote:
> > > > Could you send me the output of pnpinfo. I think we are missing a PnP I
D
> > > > in the sio driver.
> > > >
> > >
> > > The line I've added to sio.c is:
> > >
> > >
> > > {0x3024a341, NULL}, /* PMC2430 - Pace 56 Voice Internal Modem */
> >
> > Does the modem work with this addition? If so, I'll commit the change.
> >
>
> Yes :)
>
> sio2: at port 0x3e8-0x3ef irq 5 on
isa0
> sio2: type 16550A
Heh, it's already committed. (oops! :-)
> Why did it work before though, under 3.x, without this line in sio.c?
The PNP bios preconfigured it and left it laying around in port space,
so the old-style isa probes "found" it there.
Under 4.0, the isa code is much more pnp centric. It was possible for an
isa probe to find a "stray" device and then for the PNP device id to match
and then fail due to resource conflicts. So, it disables the programmable
cards first so this double probing cannot happen. It also means that it
needs to know the PNP id's for supported pnp hardware. Making this more
user tweakable is on the TODO list.
Cheers,
-Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 3.x/4.x branch date?
Warner Losh wrote: > In message <[EMAIL PROTECTED]> Kris Ke nnaway writes: > : Can someone tell me the exact date that 4.x was split from 3.x? I couldn't > : seem to pin it down based on the CVS repository. > > Based on sys/i386/conf/files.i386: > 1/20/99 to 2/10/99 > Based on sys/conf/files: > 1/17/99 to 1/21/99 > > So I'd say it was somewhere between 1/20/99 and 1/21/99. Is that > close enough for you to "exact"? The branching proccess takes a > while, so I think this is as close as you may get. sys/conf/newvers.sh is (or was) the best spot to look at: revision 1.42 date: 1999/01/21 03:07:33; author: jkh; state: Exp; lines: +2 -2 This is now 4.0-current revision 1.41.2.1 date: 1999/01/21 05:33:18; author: jkh; state: Exp; lines: +2 -2 Now we're -STABLE Note that this is GMT. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
international RSA code
I've added a port, ports/security/librsaintl, that should build and install the librsaINTL.* files in /usr/lib, in case you did a binary install or are stuck with the USA source. The port is quite a hack, but I'd be interested to know how it works for folks. Note that there have been several versions, so make sure you've got the current version before trying to use it. :-) This builds the optimized RSA code designed for use by the ssl code. It also is used by openssh. RSAREF requires big number format conversion, this code does not. RSAREF is also limited to 1024 bit keys, this code has no such limitation. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RSA/openssl compile problem
Christoph Kukulies wrote: > On Mon, Feb 28, 2000 at 11:47:22PM +0800, Peter Wemm wrote: > > "Jordan K. Hubbard" wrote: > > > > OK, I browsed through the source tree to locate something looking > > > > like an RSA package and found /usr/src/crypto/openssl > > > > > > /usr/src/crypto is just like /usr/src/contrib - you *never* attempt > > > to build things out of it. That will fail. > > OK, I cvsup'ed from ftp.internat.freebsd.org cvs-crypto > Just for the record, FWIW: > > # make -i > ===> lib > ===> lib/libcipher > ===> lib/libtelnet > ===> lib/libcrypto > ===> lib/librsaglue > ===> lib/libssl > ===> lib/librsausa > Warning: Object directory not changed from original /usr/src/secure/lib/librs ausa > ===> lib/librsaintl > Warning: Object directory not changed from original /usr/src/secure/lib/librs aintl > ===> lib/libssh > ===> libexec > ===> libexec/telnetd > ===> usr.bin > ===> usr.bin/bdes > ===> usr.bin/telnet > ===> usr.bin/openssl > cc -O -pipe -DMONOLITH -DNO_IDEA -I/usr/src/secure/usr.bin/openssl-o open ssl apps.o asn1pars.o ca.o ciphers.o crl.o crl2p7.o dgst.o dh.o dsa.o dsapa ram.o enc.o errstr.o gendh.o gendsa.o genrsa.o nseq.o openssl.o pkcs12.o pk cs7.o pkcs8.o req.o rsa.o s_cb.o s_client.o s_server.o s_socket.o s_time.o sess_id.o speed.o verify.o version.o x509.o -lssl -lcrypto > speed.o: In function `speed_main': > speed.o(.text+0x5f7): undefined reference to `RSA_PKCS1' > *** Error code 1 (ignored) > ===> usr.bin/scp > ===> usr.bin/ssh > ===> usr.bin/ssh-add > ===> usr.bin/ssh-agent > ===> usr.bin/ssh-keygen > ===> usr.sbin > ===> usr.sbin/sshd That's because you are trying to link openssl against the *old* /usr/lib/libcrypto. In all cases, you need to build/install libraries and includes before trying to compile and link against them. The dependency rules of what depends on what can be quite complex. 'buildworld' does this. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RSA/openssl compile problem
"Jordan K. Hubbard" wrote: > > OK, I browsed through the source tree to locate something looking > > like an RSA package and found /usr/src/crypto/openssl > > /usr/src/crypto is just like /usr/src/contrib - you *never* attempt > to build things out of it. That will fail. > > What you need is simply the rsaref package. I think somebody was > supposed to improve the wording that the stubs emit, the version I > originally committed (but Peter now has sole responsibility for :) > having only place-holder text. The real text should talk about > installing the rsaref package if you're in the US or the rsaintl > package if you're outside the US. Of course, the rsaintl package > doesn't quite *exist* yet, but that's another story. :-) librsaintl existed right from the start of the rsa (not rsaref) dlopen() functionality, see src/secure/lib/librsaintl. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crypto progress! (And a Biiiig TODO list)
Mark Murray wrote: > > I'm very uncomfortable with requiring Yet Another Daemon to manage > > (and screw up) password checking. Generally speaking, if I wouldn't > > trust a program with root privileges, I wouldn't trust it with my > > password, either (for obvious reasons). > > If "all those" suid programs could be "de-suid'ed", and replaced with > a simple "does this username/password pair check out?" daemon/module, > would that make you happier? As long as there is some sort of rate limiting system so that it doesn't provide a trivial online brute force password cracking service... Getting this right would be an interesting challenge. :-) Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FTP_INTERNAL_LS
"David O'Brien" wrote: > On Wed, Feb 16, 2000 at 09:04:44AM +0200, Sheldon Hearn wrote: > > > What about making FTP_INTERNAL_LS the default for 4.0? > > > > I'm very much in favour of this, > > Agreed. Do you want to bug JKH, or should I? ;) You're 6 months late, this is already done: revision 1.26 date: 1999/08/26 00:45:34; author: peter; state: Exp; lines: +1 -3 unifdef -DINTERNAL_LS - it's too useful to be off by default. If anyone really dislikes this, we could add a switch to disable it at runtime and check in popen.c. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sound Card
Ron 'The InSaNe One' Rosson wrote: > On Sun, 13 Feb 2000, MIHIRA Yoshiro was heard blurting out: > > > [EMAIL PROTECTED] wrote: > > > > >> Ron 'The InSaNe One' Rosson wrote: > > >> > Under 3.3-RELEASE with PAO the sound card work with this entry in the > > >> > config file: > > >> > > > >> >device pcm0 at isa? port ? tty irq 5 drq 1 flags 0x0 > > >> > > > >> > Here is what the dmesg output looked like with that entry: > > >> > > > >> >pcm0 at 0x220 irq 5 drq 1 on isa > > >> >ESS1879 (rev 11, native mode) > > >> > > > >> > Now under current I have tried both of these entries to get sound > > >> > working to no avail. > > >> > > > >> >device pcm0 at isa? port? irq 5 drq 1 flags 0x0 > > >> > > > >> >device pcm0 at isa? port? irq 5 drq 1 flags 0x15 > > >> > > > >> > Any assistance in this matter would be greatly appreciated. > > > > device pcm0 > > device sbc0at isa? port 0x220 irq 5 drq 1 flags 0x0 > > > The above worked.. here is the dmesg output of it: > > sbc0: at port 0x220-0x22f irq 5 drq 1 on isa0 > pcm0: on sbc0 > > and > insane-mental> cat /dev/sndstat > FreeBSD Audio Driver (newpcm) Feb 12 2000 16:45:04 > Installed devices: > pcm0: at io 0x220 irq 5 drq 1 (1p/1r channels) > > The only issue I have left is that when a sound is played everuything is > find till the end and it sounds like a fading echo. Did you actually try: options PNPBIOS device pcm device sbc It is important that you do this please, at least so we have a datapoint. Also, what version of -current? (if it's fairly new, you can even leave out 'device sbc' if you are running in PnP or PNPBIOS mode) I presume this is for a laptop, right? (you mentioned PAO but otherwise gave no clues). Does 'pnpinfo' report a pnp device? or is it a bios configured non-pnp chip on the motherboard? (in which case PNPBIOS should find it) Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Interesting compile glitch in -current
Bruce Evans wrote:
> On Sat, 12 Feb 2000, Peter Wemm wrote:
>
> > cc -fpic -DPIC -O -pipe -DLIBC_RCS -DSYSLIBC_RCS -I/home/src/lib/libc/inclu
de -D__DBINTERFACE_PRIVATE -DINET6 -DPOSIX_MISTAKE -I/home/src/lib/libc/../
libc/locale -DBROKEN_DES -DYP -I/usr/obj/home/src/i386/usr/include -c /home
/src/lib/libc/../libc/stdtime/localtime.c -o localtime.So
> > {standard input}: Assembler messages:
> > {standard input}:87: Warning: warning: unrecognized characters `@GOTOFF' in
expression
> > {standard input}:114: Warning: warning: unrecognized characters `@GOTOFF' i
n expression
> >
> > .. which is kinda disturbing..
>
> This seems to be non-cosmetic. gas apparently can't handle constants of
> the form address@GOTOFF. %ebx normally has to be added to these constants
> to get an address, but gcc sometimes "optimises"
> "leal address@GOTOFF(%ebx),%eax" to
> "movl $address@GOTOFF,%eax; addl %ebx,%eax".
The current binutils gas deals with this without a complaint BTW. And
mozilla compiled with the new binutils seems to work fine too while when
I compiled the same source with the old as/ld it was crashing at startup.
Cheers,
-Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: timed/adjtime() on -current
Ben Smithurst wrote: > Poul-Henning Kamp wrote: > > > Anyway: Don't used timed, use ntpd. > > Do you have any hints about using xntpd over an intermittent dialup > connection? At the moment, I use ntpdate to sync the time to my ISP's > servers when ever I go online, I can't see it being easy to tell xntpd > to sync the time when I tell it to, and only when I tell it to. Unless > you know otherwise? :-) Set your ppp filters carefully. Tell it that ntp packets (port 123) are not to cause a dialup, and are not to trigger the idle timer. The result of this will be that ntp will sync up while you are online but won't keep the connection alive and prevent an idle hangup (assuming you use idle timeouts). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sound Card
Ron 'The InSaNe One' Rosson wrote:
> Under 3.3-RELEASE with PAO the sound card work with this entry in the
> config file:
>
> device pcm0 at isa? port ? tty irq 5 drq 1 flags 0x0
>
> Here is what the dmesg output looked like with that entry:
>
> pcm0 at 0x220 irq 5 drq 1 on isa
> ESS1879 (rev 11, native mode)
>
> Now under current I have tried both of these entries to get sound
> working to no avail.
>
> device pcm0 at isa? port? irq 5 drq 1 flags 0x0
>
> device pcm0 at isa? port? irq 5 drq 1 flags 0x15
>
> Any assistance in this matter would be greatly appreciated.
Have you tried the following?
device pcm
device sbc
(with and without "options PNPBIOS")
sbc.c: {0x78187316, "ESS ES1878"}, /* ESS1878 */
sbc.c: {0x79187316, "ESS ES1879"}, /* ESS1879 */
Cheers,
-Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ABIT BP6 + UDMA66: ad_timeout: lost disk contact
"Dan Mack" wrote:
> I have basically the same system. BP6 (dual 400 SMP) + 2 UDMA66 Maxtor
> Drives. Under
> high I/O load, I get the lost disk contact messages. Sometimes I recover
> from
> the hang other times I have to hard reset the system.
>
> Yes I know that maxtor is not the highest quality but at $120 for 13GB ;-)
>
> Is there anything I can do to solve this problem besides buying new disks?
I use this, it solves my lockup problems at UDMA66 completely (ie: disables
it :-). After this I run reliably.
Index: ata-all.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v
retrieving revision 1.47
diff -u -r1.47 ata-all.c
--- ata-all.c 2000/02/04 10:20:20 1.47
+++ ata-all.c 2000/02/12 07:59:08
@@ -1188,8 +1188,10 @@
ata_umode(struct ata_params *ap)
{
if (ap->atavalid & ATA_FLAG_88) {
+#if 0
if (ap->udmamodes & 0x10) return (ap->cblid ? 4 : 2);
if (ap->udmamodes & 0x08) return (ap->cblid ? 3 : 2);
+#endif
if (ap->udmamodes & 0x04) return 2;
if (ap->udmamodes & 0x02) return 1;
if (ap->udmamodes & 0x01) return 0;
> Dan
> - Original Message -
> From: "Hans Ottevanger" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, February 12, 2000 10:31 AM
> Subject: ABIT BP6 + UDMA66: ad_timeout: lost disk contact
>
>
> > Hi folks,
> >
> > I am currently having problems with my new Dual Celeron testsystem,
> > when trying to use UDMA66.
> >
> > Hardware:
> >
> > ABIT BP6
> > 2x Celeron 466 (NOT overclocked)
> > 128 Mbyte RAM
> > Matrox G400 16 MByte
> > 3Com 905B
> > 2x Maxtor 92041U4 20 GByte
> > Aopen CDROM 48x
> >
> > One of the disks is master on the first "standard" disk channel, and
> > uses
> > UDMA33, the other is master on the first "fast" channel controlled by
> > the
> > on-board HPT-366, and is probed as UDMA66.
> >
> > When I use the UDMA33 disk, no problem occurs at all, I can even run
> > "make buildworld" without any problems. When accessing the disk on the
> > UDMA66 channel however, the system regularly hangs, followed by a
> > message
> > like:
> >
> > Feb 12 12:39:54 myhost /kernel: ad4: ad_timeout: lost disk contact -
> > resetting
> > Feb 12 12:39:54 myhost /kernel: ata2: resetting devices .. done
> >
> > After a few of these messages the system hangs completely, and needs to
> > be
> > rebooted.
> >
> > The problem already occurred during my first attempts to use UDMA66 last
> > week, but now persists using today's 4.0-CURRENT.
> > My kernel is derived from GENERIC, with SMP added, and devices removed
> > that
> > are not present. I do not yet use softupdates.
> >
> >
> > The problem can easily be reproduced by creating a large file as
> > follows:
> >
> > dd if=/dev/zero of=junk bs=1024k count=512
> >
> > This command runs without any problem. Reading this file with:
> >
> > dd if=junk of=/dev/null bs=1024k
> >
> > causes the problem to occur within a few seconds. Decreasing the
> > blocksize
> > makes the system survive somewhat longer, but the problem still occurs.
> > Only with a blocksize lower than 4k the system does not hang.
> >
> > Very strange is the fact that reading the raw device file with:
> >
> > dd if=/dev/ad4s1c of=/dev/null bs=1024k
> >
> > completes without problems, even with two commands running concurrently.
> >
> > I already tried to swap the disks, but the problem still occurs on the
> > one
> > that is using UDMA66. Even when switching to PIO using 'sysctl', the
> > system
> > still hangs, it just takes somewhat longer before it happens.
> >
> > Does anybody have an idea what happens ?
> >
> >
> > Kind regards,
> >
> > Hans
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
> >
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
>
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: newer binutils for CURRENT ?
Pascal Hofstee wrote:
> On Sat, Feb 12, 2000 at 03:36:12AM -0500, Donn Miller wrote:
> >
> > One possible thing to try would be to download the latest binutils
> > from the GNU ftp site or mirrors, compile, and install them in
> > /usr/local. Then, set /usr/local/bin as the first entry in your PATH
> > environment variable to override the default binutils. Well, I
> > haven't tried it in a while, so I don't know if binutils will work
> > without some patches.
> >
> > Or, we could just upgrade our stock binutils. :-)
>
> I would very much appreciate the latter option ...
Heh, what's the bet that it would fix this too? :-]
[5:17pm]~src/lib/libc-242# make localtime.So
cc -fpic -DPIC -O -pipe -DLIBC_RCS -DSYSLIBC_RCS -I/home/src/lib/libc/include
-D__DBINTERFACE_PRIVATE -DINET6 -DPOSIX_MISTAKE -I/home/src/lib/libc/../libc/locale
-DBROKEN_DES -DYP -c /home/src/lib/libc/../libc/stdtime/localtime.c -o localtime.So
{standard input}: Assembler messages:
{standard input}:87: Warning: warning: unrecognized characters `@GOTOFF' in expression
{standard input}:114: Warning: warning: unrecognized characters `@GOTOFF' in expression
gcc generates assembler that gas doesn't understand. :-(
Cheers,
-Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Interesting compile glitch in -current
cc -fpic -DPIC -O -pipe -DLIBC_RCS -DSYSLIBC_RCS -I/home/src/lib/libc/include
-D__DBINTERFACE_PRIVATE -DINET6 -DPOSIX_MISTAKE -I/home/src/lib/libc/../libc/locale
-DBROKEN_DES -DYP -I/usr/obj/home/src/i386/usr/include -c
/home/src/lib/libc/../libc/stdtime/localtime.c -o localtime.So
{standard input}: Assembler messages:
{standard input}:87: Warning: warning: unrecognized characters `@GOTOFF' in expression
{standard input}:114: Warning: warning: unrecognized characters `@GOTOFF' in expression
.. which is kinda disturbing..
Cheers,
-Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Hardwiring SCSI device ID broken?
Barry Bouwsma wrote: > > > > > > > > It seem hardwiring SCSI devices is broken in -current: > > > > > dmesg would be useful, otherwise we can't even begin to guess what ha ppened. > > > > > > > I don't have it in /var/log/messages, but I can reboot my machine > > > (that has this problem) and copy down what I see. > > Okay, this may or may not be relevant... > > I've re-ID'ed one disk to be at target 0. The kernel config is > supposed to wire target 1 to be da0. There is another disk at > target 2 (in my earlier tests, there were only two disks). > > Before the `Mounting root' entry I see the following now: > > (da0:ahc0:0:0:0): Duplicate Wired Device entry! > (da0:ahc0:0:0:0): Second device will not be wired > (da0:ahc0:0:0:0): Duplicate Wired Device entry! > (da0:ahc0:0:0:0): Second device will not be wired > > That's right, twice, with three disks. > When I only had two disks (that was the error I noted in the /var > logfiles), there was only a single pair of lines. > > Then I see... > Mounting root from ufs:da1s1a (I don't remember what I did earlier > to boot cleanly with another disk at target 0, I should try to > reproduce that in case there is any difference) > da2 at ahc0 bus 0 target 2 lun 0 > [...] > cd0 at ahc0 bus 0 target 6 lun 0 > [...] > da1 at ahc0 bus 0 target 1 lun 0 > [...] > da0 at ahc0 bus 0 target 0 lun 0 > > > Ideally, target 1 should be da1. It finds the fstab file but > that has da0 as root/swap/etc, not the da1 that the above dmesg > puts it at. So the problem is that mounting the filesystems > fails. > > Note that I had tried the kernel configuration several times with > different possibilities to keep `config' quiet, but none of them > resulted in the desired device being wired, so it is possible that > this kernel's config file isn't quite as clean as it should be. > I'll take a look at that and if need be, correct it and try again. > For this kernel, config did complain about the `0', so I think it > should be close to what I intended. > > Hope this is enough to help, if not, I'll provide more. The two- > line errors that repeat for the second and each following drive > present seem interesting... I'm sorry, I'm still not following this, there's far too much missing information. To fix this, we need to know: 1: the config file relating to the disks 2: the scsi device configuration 3: the dmesg output showing clearly what isn't working. Don't delete too much information, taking out too much data makes it impossible to figure out. 4: Prefereably an old dmesg showing how it used to work - check older /var/log/messages and /var/log/messages.*.gz - it should be in there. 5: a detailed explanation of what is going wrong, not just hints. Remember, we have no idea your respective systems are set up. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hardwiring SCSI device ID broken?
Igor Timkin wrote: > > Martin Cracauer wrote: > > > It seem hardwiring SCSI devices is broken in -current: > > > > > > LINT seems to recommend: > > > > > > device ahc > > > device scbus0 at ahc0 > > > device scbus1 at ahc1 bus 0 > > > > > > device sa0 at scbus1 target 4 > > > device sa1 at scbus1 target 5 > > > device cd0 at scbus1 target 6 > > > device cd1 at scbus1 target 2 > > > > > > However, config rejects it: > > > config: line 239: ahc 0 not defined > > > config: line 240: ahc 1 not defined > > > > But what happens at boot time? Does it work? (it should). > > No :( > > @(#)FreeBSD 4.0-2112-CURRENT #1: Sat Jan 15 08:01:12 MSK 2000 > > My kernel config: > device ahc0# AHA2940 and onboard AIC7xxx devices > device ahc1 > options AHC_ALLOW_MEMIO > options SCSI_DELAY=2000 #Be pessimistic about Joe SCSI device > > #device scbus0 > device scbus0 at ahc0 > device scbus1 at ahc1 > device da0 at scbus1 target 0 > device da1 at scbus1 target 1 > > First disk is da2. dmesg would be useful, otherwise we can't even begin to guess what happened. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pstat(8) depends on loader(8)???
John Baldwin wrote: > > On 07-Feb-00 Bruce Evans wrote: > > On Mon, 7 Feb 2000, Ruslan Ermilov wrote: > > > >> If I boot the system without loader(8), e.g. with /boot.config=kernel, > >> or by interrupting boot blocks and typing /kernel, swapinfo(8) fails: > >> > >> swapinfo: undefined symbol: _numvnodes > > > > This is because the elf format puts static symbols in an out-of-the-way > > section, and the boot2 stage of the bootstrap loads sections naively. > > Static symbols end up in a place where the kernel linker can't find > > them. `numvnodes' is a static symbol... Global symbols are found > > correctly. > > So all that needs to be fixed is for boot2.c to be more intelligent with ELF > images then? No, boot2 doesn't have room for this. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pstat(8) depends on loader(8)???
Garrett Wollman wrote: > < said: > > > If I boot with loader(8), everything is ok. > > Ideas? > > loader loads the kernel symbol table; boot2 does not. > > -GAWollman More to the point, a non-stripped kernel has *two* symbol tables. One that has the global symbols and is used for dynamic linking, and the other that has the debugging info in it including static symbols. loader(8) goes to a great deal of trouble to get the second table - it's very hard to get it when reading from a zlib decompression stream that can't be seek'ed. The ELF format defines a convenient 'load segment' table which defines (usually) two chunks of the file to be loaded into memory and at what addresses. The verbose symbol table is not part of this, but the global table is and we get it for free. Anyway, the correct fix is to make numvnodes global or to change it to a sysctl. Nothing that is referred to by the common libkvm applications should be static - this warning has been given before. running a strip on / kernel has the same effect as using boot2 - only global symbols are accessible. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 release cosmetics: ftpd
Doug Barton wrote: > Marc Schneiders wrote: > > > > On Tue, 1 Feb 2000, Will Saxon wrote: > > > > > Well, apparently we are supposed to replace a bunch of files is /etc > > > whenever we make world. There is a command called mergemaster that does > > > this, but the one time i used it (I did not read the directionsvery > > > carefully) I basically messed everything up. > > > > Yes, I don't like mergemaster either. > > Out of curiosity, what specifically do you not like about it? I realize > that not everyone is going to like/use it, but I am always interested in > ways to improve the program. I don't know about everyone else, but my main beef with it is that it doesn't use resources like cvs (when available) to do a smarter 3-way merge. It's got the version ID tags available so it could use that to extract the old unmodified version from cvs and use either rcsmerge or applying a patch generated by a diff of the old unmodied version and the current version. This is easier said than done though as the etc files are scattered all over the tree. :-/ However, when the path is available (ie: files with $FreeBSD$ rather than $Id$) then there is no guessing required. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ftp passive modem is on by defaut?
Dmitry Valdov wrote: > Hello! > > Why ftp passive mode is on by default? > > > > ftp localhost > Connected to localhost. > 220 home.dv.ru FTP server (Version 6.00LS) ready. > Name (localhost:dv): > 331 Password required for dv. > Password: > 230 User dv logged in. > Remote system type is UNIX. > Using binary mode to transfer files. > ftp> get /bin/sh /tmp/qqq > local: /tmp/qqq remote: /bin/sh > 229 Entering Extended Passive Mode (|||1049|) > [...] > ftp> passive > Passive mode off. > ftp> > > > Manpage shows: > > passive Toggle passive mode. If passive mode is turned on (default > is off), > [...] > > Dmitry. Try this: [4:04am]~-112# env | grep FTP FTP_PASSIVE_MODE=YES [4:04am]~-113# grep FTP /etc/login.conf :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\ ie: ftp(1)'s default is off, but the OS default configuration is to set it to on. This is actually a good thing, for what it's worth. It means you have a fighting chance of getting out through a firewall easily. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hardwiring SCSI device ID broken?
Martin Cracauer wrote: > It seem hardwiring SCSI devices is broken in -current: > > LINT seems to recommend: > > device ahc > device scbus0 at ahc0 > device scbus1 at ahc1 bus 0 > > device sa0 at scbus1 target 4 > device sa1 at scbus1 target 5 > device cd0 at scbus1 target 6 > device cd1 at scbus1 target 2 > > However, config rejects it: > config: line 239: ahc 0 not defined > config: line 240: ahc 1 not defined But what happens at boot time? Does it work? (it should). If the config messages bother you, change: "device ahc" to device ahc0 device ahc1 Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldloaded driver not called at load time
"Matthew N. Dodd" wrote: > On Mon, 31 Jan 2000, Mike Smith wrote: > > This is because the unknown driver is never revoked once it owns your > > device. It's a(nother) bug in the ISA bus code. 8( > > Looking at the code in sys/kern/subr_bus.c I'm not sure how any drivers > are revoked by a higher priority match. > > This is probably desirable given the nature of most drivers and one of the > reasons for letting BUS_PROBE_NOMATCH announce your 'unknown' hardware. > I never liked the unknown driver. I vote we kill it and let > isa_probe_nomatch() deal with things. (I'll have to write > isa_probe_nomatch() but I don't see that as a problem.) I'll dig out my patches for that area and send you a copy. We do need something when we use PNPBIOS because the motherboard devices are not programmable and their port space is "fixed". Their space needs to either be allocated to something or otherwise avoided when we are choosing ports for real programmable devices. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make installworld broken???
"Rodney W. Grimes" wrote: > Good analysis deleted... > > > src/usr.bin/xinstall could probably have been named src/usr.bin/install, > > but PROG has to be xinstall regardless. I guess they kept the two as > > xinstall for consistancy and in case there were other gotcha's like this. > > But you forgot what happens if you have a ``file'' named install: > > cd /tmp > mkdir install > make install > > Now you know the real reason the directory is called ``xinstall''. Ahh yes, of course. 'cd src/usr.bin; make install' would fail. :-) Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make installworld broken???
Andrzej Bialecki wrote:
> On Sun, 30 Jan 2000, John Polstra wrote:
>
> > > > It's source-dir is called "xinstall" btw.
> > > Why is the source called "xinstall"?
> >
> > To avoid colliding with the standard make target "install". If we
> > had utilities named "all", "depend", and "clean" we'd have to do the
> > same thing for them.
>
> Mhmmm... Isn't this something that .PHONY target is supposed to handle?
No. Consider:
PROG= install
all: ${PROG}
${PROG}:${OBJS}
cc -o ${PROG} ${OBJS}
install:
${INSTALL} ${PROG} ${BINDIR}
and with ${PROG} expanded out:
all: install
install:${OBJS}
cc -o install ${OBJS}
install:
${INSTALL} install ${BINDIR}
Spot the problem.. Does the target "install" mean "build the binary" or
"install the binary"?
src/usr.bin/xinstall could probably have been named src/usr.bin/install,
but PROG has to be xinstall regardless. I guess they kept the two as
xinstall for consistancy and in case there were other gotcha's like this.
Cheers,
-Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Printer fiascos.
Matthew Dillon wrote:
> When the new parallel port stuff was put several months ago, my
> machine stopped working. I had to set flags to 0x40 to make it
> work again. Flags of 0x40 force the driver to use the most
> basic probes possible. It was put in because a number of people's
> machines stopped working.
>
> It looks like Peter removed the flags 0x40 in rev 1.228 of GENERIC
> on Jan 14.
>
> At the time I had an argument with the author who insisted that
> the correct way to force 'basic' probing of the printer was to
> set the flags field in GENERIC rather then make the default a basic
> probe.
>
> * Peter, the comment in your log message makes no mention of the reason
> * for removing the flags. If you did this by accident could you please
> * set the flags back to 0x40?
The reason I did that was because flags 0x40 only does something if you
activate the PPC_PROBE_CHIPSET option. By default you get flags 0x40
type behavior and the intrusive probes are simply not even compiled into
the driver. If you activate the option, then you can also specify
flags 0x40 to disable the code you compiled in. In other words, GENERIC
does not require the flag any more as it doesn't have the option active.
#ifdef PPC_PROBE_CHIPSET
/* we have to differenciate available chipset modes,
* chipset running modes and IEEE-1284 operating modes
*
* after detection, the port must support running in compatible mode
*/
if (ppc->ppc_flags & 0x40) {
if (bootverbose)
printf("ppc: chipset forced to generic\n");
#endif
> Now, a huge number of changes have been made since the original problem
> was reported, so I could be puffing smoke here. I didn't see anything
> in the CVS logs, though, so I am assuming that the removal of the
> flags field was a mistake.
>
> David, try putting flags 0x40 back in and see if that fixes your
> problem.
>
> -Matt
> Matthew Dillon
> <[EMAIL PROTECTED]>
>
> :Why is it that a properly functioning printer is such a moving target
> :in FreeBSD?
> :
> :I don't mean to be argumentative, but under 3.x, the magic cookie to
> :make printers work (it appeared to be a flow control problem) was to
> :change
> :
> :device ppc0at isa? port? flags 0x40 net irq 7
> :
> :to
> :
> :device ppc0at isa? port? flags 0x40 tty irq 7
> :
> :Now... I've upgraded to -CURRENT, and it has a much more serious
> :problem. The line now reads
> :
> :device ppc0at isa? port? irq 7
> :
> :... so I havn't tried putting net or tty in it, but I have a printer
> :with a particular problem --- it will often fail to pick up a sheet of
> :paper. I suspect that this sets the paper out sense line of the
> :parallel port (?).
> :
> :When this happens, the entire machine freezes until someone feeds the
> :printer --- the momment it starts printing again, the computer
> :unfreezes.
> :
> :Printer-port related things probe as:
> :
> :ppc0: at port 0x378-0x37f irq 7 on isa0
> :ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
> :ppbus0: IEEE1284 device found /NIBBLE/PS2/ECP
> :Probing for PnP devices on ppbus0:
> :ppbus0: PCL,MLC,PML
> :lpt0: on ppbus0
> :lpt0: Interrupt-driven port
> :plip0: on ppbus0
> :ppi0: on ppbus0
> :
> :(I have tried putting the BIOS in different parallel port modes.)
> :
> :Dave.
> :
> :--
> :
> :|David Gilbert, Velocet Communications. | Two things can only be |
> :|Mail: [EMAIL PROTECTED] | equal if and only if they |
> :|http://www.velocet.net/~dgilbert | are precisely opposite. |
> :=GLO
>
>
Cheers,
-Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ep0 incorrectly probed
"Matthew N. Dodd" wrote: > On Fri, 28 Jan 2000, Peter Wemm wrote: > > pnpinfo doesn't have anything to do with what the kernel thinks. It's a > > userland program that manually resets and reconfigures the cards.. This is > > an absolute disaster if you happened to be using the hardware, eg: the soun d > > driver. After running pnpinfo, the hardware essentially "disappears". > > > > pciconf(8) does it properly, it asks the kernel via /dev/pci. pnpinfo uses > > /dev/io to bash on the ports directly. > > Thats kinda weird seeing as how pnpinfo correctly reports the settings as > detected/assigned by the kernel for all other cards. Hmm, I take some of that back. I'm still not 100% sure of the implications of what I'm seeing in src/contrib/pnpinfo, but it still makes me nervous. For example: Logical device #0 IO: 0x0534 0x0534 0x0534 0x0534 0x0534 0x0534 0x0534 0x0534 IRQ 5 0 DMA 1 0 IO range check 0x00 activate 0x01 versus: pcm0: at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0 Which is right? Does the device really have all 8 IO ranges assigned to the same address? (0x534) Or is pnpinfo wrong? Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ep0 incorrectly probed
"Matthew N. Dodd" wrote: > On Thu, 27 Jan 2000, Warner Losh wrote: > > We've had *BAD* luck with the ex driver doing this... > > Except that the ex driver doesn't do anything destructive in its identify > method now. > > I'm having a hell of a time getting the ex driver to attach in PnP mode > but thats another story. I think the i85295 needs some special kicking or > something but I don't have the manuals yet. It doesn't seem to be > assigned the resources the kernel picks out for it. This is shown by > 'pnpinfo'. pnpinfo doesn't have anything to do with what the kernel thinks. It's a userland program that manually resets and reconfigures the cards.. This is an absolute disaster if you happened to be using the hardware, eg: the sound driver. After running pnpinfo, the hardware essentially "disappears". pciconf(8) does it properly, it asks the kernel via /dev/pci. pnpinfo uses /dev/io to bash on the ports directly. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make release broken
Wilko Bulte wrote: > On Fri, Jan 21, 2000 at 09:19:22AM +0200, John Hay wrote: [..] > > cp: /usr/src/release/texts/HARDWARE.TXT: No such file or directory > > *** Error code 1 [..] > > It looks like the handling of HARDWARE.TXT in release/Makefile is broken. > > Duh.. John Polstra is working on cvs-moving i386/HARDWARE.TXT to make > this file the starting point for the generic HARDWARE.TXT > > There were some problems in doing this with cvs > > I guess this needs some time to get resolved. OK, here's the deal.. There is already a texts/HARDWARE.TXT, but it's been cvs rm'ed from -current. Since it's in use on 3.4, we can't just clobber it. So, if you want to move i386/HARDWARE.TXT up a level you're just going to have to copy the file and cvs add it in the new location. This will "revive" it in -current. We can't do anything about the lost history in i386/HARDWARE.TXT. Well, strictly speaking it can be merged but it's much more painful than it's worth. :-/ Just re-add the file and lets get on with it. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ...(file transfer crashes system) ethernet driver or IP stack bug?
Matthew Dillon wrote: > > :Thanks for the help matt. Here is the 'dmesg'... > : > :arnee > > Hmm. If possible I would try backing away from the ata driver entirely > and going back to the 'wd' driver. This isn't to say that the ata > driver is the problem, but it *could* be the problem. A number of peopl e > have had problems with the ata driver. There isn't anything else in your > config that strikes a chord... the rest of it looks ok to me. Not possible. the wd driver doesn't support the Promise ATA-66 controllers that he is using. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Feature test for OpenSSL + RSA
Sheldon Hearn wrote:
>
>
> On Mon, 17 Jan 2000 21:53:10 PST, Kris Kennaway wrote:
>
> > +.if defined(WITH_RSA) && ${WITH_RSA} == YES
> > + /usr/bin/touch /etc/ssl/openssl_hasrsa
>
> Um, are you sure you want that hard path, /etc/ssl ? Shouldn't there be
> a ${DESTDIR} in there? What do you need this for?
Yes, This should most definately have ${DESTDIR} for this sort of thing, but
even then I'm not sure this is a good change.. We have got to find a better
way than this.
Cheers,
-Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Integrated Vibra16 in -current
Andy Sparrow wrote: [..] > I've got a Micron W6-Li Lightning board with integrated Creative Vibra16X and > Adaptec 7880, and I run a WinTV card as well. I also have the ISA Waveblaster > daughter card that makes the sound setup effectively an AWE32. We probably need to find out what the PnP device ID is if it doesn't get found under pcm0/sbc0. > Given the Plug'n'Pray changes in -current, I pretty much expected to lose > AWE32 support (as I can no longer use the 'pnp' commands in 'userconfig' to > probe the "magic" ports for the AWE32). > > However, I wasn't expecting to lose the ability to use VoxWare altogether. How about 'device pcm0' and 'device sbc0'? > Without PNPBIOS, I got these messages (config file was the same one as used > under -STABLE, just converted by the simple expedient of fixing the complaint s > from 'config', mostly changing 'controller' to 'device' etc.): > > sb_reset_dsp failed > sb_reset_dsp failed > awe0 at port 0x620 on isa0 > AWE32: not detected > unknown0: at port 0x621-0x624 on isa0 > unknown1: at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,3 o n isa0 > unknown2: at port 0x201 on isa0 The output of 'pnpinfo' would be useful. > I tried adding PNPBIOS to the kernel options, with little improvement: PNPBIOS gets extra info about devices including the motherboard resources. It is only useful for PnP-aware device drivers, such as pcm/sbc etc. Voxware is not a PnP-aware device driver so don't expect it to work on a PnP card. > Switching 'PNP OS = YES' in the BIOS setup (it's a Phoenix BIOS) didn't > seem to make any difference to anything. PNP OS = YES tells the motherboard to not bother configuring any hardware that isn't needed to boot. This means things like sound cards and other devices (pci and isa) are left in a totally unconfigured state. > Worse, with PNPBIOS enabled, the WinTV card would not work either: > > bktr0: irq 17 at device 17.0 on pci0 > bktr0: could not map memory > device_probe_and_attach: bktr0 attach returned 6 > pci0: unknown card (vendor=0x109e, dev=0x0878) at 17.1 irq 17 This is because the bt878 has not been assigned any memory addresses. We don't do PCIBIOS calls to reassign these yet, so if you use 'PNP OS = YES' you are asking for trouble. > In fact, in -current, there's a few things that look odd. I always get this > complaint from the BrookTree driver (which I've never seen on 3.x): > > pci0: unknown card (vendor=0x109e, dev=0x0878) at 17.1 irq 17 > > I get this even if PNPBIOS isn't an option, and the card actually works... This is a quirk of the bt878 device and drivers. There are actually two logical devices in the chip: bktr0@pci0:10:0: class=0x04 card=0x217d6606 chip=0x036e109e rev=0x02 none0@pci0:10:1: class=0x048000 card=0x217d6606 chip=0x0878109e rev=0x02 For whatever reason, the bktr driver is only interested in the first one and leaves the second one unconfigured. > and I always see this too > devclass_alloc_unit: npx0 already exists, using next available unit number This is because you have 'device npx0 at isa? ...' - see GENERIC, it's supposed to be 'at nexus?' or just 'device npx0'. > Using the 'pcm0' and 'sbc0' driver (without any 'at isa?' etc. and without > PNPBIOS so the WinTV card is usable) seems to work fine, but I'm a little > confused as to why the VoxWare stuff can't work anymore. It's 'PNP OS = YES' that messes up the WinTV, not PNPBIOS. Ahh, pcm/sbc do work.. Use that then, the Voxware code's days are numbered. > Last but not least, 'xmcd' doesn't work for me under -CURRENT (integrated > AIC-7880 and Plextor PX-12TSi CD-ROM), it never recognises that a CD is > inserted, and an attempt to eject the CD from 'xmcd' gives a 'Inappropriate > IOCTL for device' message (sorry, I didn't make a note of the tag on the > front). This is a different set of problems. make sure you are using an up-to-date port and that you have rerun MAKEDEV to create the required devices in /dev (in particular the xpt* and pass* devices.) Also, make sure you have 'device pass0' in your kernel config. > Is this breakage of the built-in Vibra with VoxWare expected? Surprised > the heck out of me... Pretty much, yes. :-/ Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
