3dfx device driver
Hi, I am just updating about the driver. I mad a few significant changes that are up at http://pohl.ececs.uc.edu/~cokane now. -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu PGP signature
What happens with SECURELVL? (init complains)
Now init always complains: init: cannot get kernel security level: No such file or directory It is because KERN_SECURELVL define still present in /sys/sysctl.h but gone from kern_mib.c Moreover, even define is gone from kern_mib.c, sysctl_kern_securelvl() function is still there! Please clean up the mess. -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Unknown Devices
At 2 Jun 2000 21:09:16 GMT, John Hengstler [EMAIL PROTECTED] wrote: pci0: unknown card (vendor=0x11c1, dev=0x0441) at 9.0 irq 9 http://www.yourvote.com/pci/pciread.asp?venid=0x11c1 says that chip is ATT Microelectronics' WinModem. This is not yet supported by FreeBSD. -- Jun Kuriyama [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Unknown Devices
On 05-Jun-00 John Hengstler wrote: I don't know that what the actual modem is inside. The system is a Compaq Presario 1200. I rather think that means Lucent windows only modem. It does in my 1690. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory changes in current?
Alexander Sanda wrote: Anyone aware of them? After building a complete kernel + world with a very recent -current (Saturday morning, european time) I now get lots of shared memory errors in gnome (most coming from gdk and imlib, some from Xfree 4 aswell). I recompiled parts of gnome (gtk+, imlib, glib) and the situation has slightly changed, but gdk still throws a lot of shmget() failed: errors. It has noting to do with kernel/gnome. XFree 4.0 is known to be very hungry for the shared memory, so you should increase SHMSEG parameter in your kernel config file. There are no guidelines as to what exact number will be sufficient, so you should define it in experimental way. I personally set it to 100 (options SHMSEG=100) and do not see any warnings anymore. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ls
FYI: It seems that color support in 'ls' is clean now. I have no ideas or bug reports to fix it more. -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ls
On Tue, Jun 06, 2000 at 05:07:59PM +0300, Maxim Sobolev wrote: There is colorls-related PR 18616 (http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18616). Please take a look at it and close if it is mandatory or merge if not. Our system color-'ls' already don't have this bug. Know nothing about colors from ports. -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ls
"Andrey A. Chernov" wrote: On Tue, Jun 06, 2000 at 05:07:59PM +0300, Maxim Sobolev wrote: There is colorls-related PR 18616 (http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18616). Please take a look at it and close if it is mandatory or merge if not. Our system color-'ls' already don't have this bug. Know nothing about colors from ports. Probably it would be nice if colorls from the ports will be synchronized with one in /usr/src, so users of 4.0 and downward could benefit from your efforts as well. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FrontPage Extensions
[reply to an old mail found in archives] Terry Lambert writes: For what it's worth, the FP security issues are very well documented by ReadyToRun Software's site (these are the folks who do the UNIX ports for Microsoft). They also keep both BSDI 2.1 and 3.0 binaries available, and they know about FreeBSD (it's mentioned in the FAQ as an unsupported platform; apparently someone was having problems with the MD5 password hashing. Someone who cares should send them mail on how to update their FAQ to be more correct, and to raise FreeBSD's visibility as a platform -- e.g. what versions to us4e for what, install instructions for FreeBSD, etc.). FWIW, they now have a native FreeBSD version (FP extensions SR1, the port needs to be updated BTW) -- works like a charm with minor changes to one of the port patches. The binaries are 3.3, linked dynamically -- compat3x will get this working. Caveat: if you misconfigure your VirtualHost in some way, any call to the FP-patched Apache to that subweb's /_vti_bin/ will make it (apache) segfault. Will debug this if I find time. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SMP + APM = panic - fixed!
Hi, We're having this problem for long time (from the old 4.0-CURRENT days), but Mr. SUMITANI discovered a bug and fixed it. The problem was that we got worng gdt pointer for the current cpu, then panic... The followings is a patch to fix the problem. Thanks a lot, SUMITANI-san! Please test this and I'll commit MFC this if we have no problem with this fix. I love to have APM enabled SMP system with 4.1-RELEASE. Index: bios.c === RCS file: /home/ncvs/src/sys/i386/i386/bios.c,v retrieving revision 1.32 diff -u -r1.32 bios.c --- bios.c 2000/05/17 19:44:16 1.32 +++ bios.c 2000/06/06 16:47:46 @@ -262,7 +262,7 @@ union descriptor *p_gdt; #ifdef SMP -p_gdt = gdt[cpuid]; +p_gdt = gdt[cpuid * NGDT]; #else p_gdt = gdt; #endif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP + APM = panic - fixed!
On Wed, Jun 07, 2000 at 02:06:15AM +0900, Mitsuru IWASAKI wrote: We're having this problem for long time (from the old 4.0-CURRENT days), but Mr. SUMITANI discovered a bug and fixed it. The problem was that we got worng gdt pointer for the current cpu, then panic... The followings is a patch to fix the problem. Thanks a lot, SUMITANI-san! Please test this and I'll commit MFC this if we have no problem with this fix. I don't have an SMP + APM system around at the moment, but the fix does look correct to me, go ahead and commit it. Thanks for tracking this down! -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP + APM = panic - fixed!
Please test this and I'll commit MFC this if we have no problem with this fix. I don't have an SMP + APM system around at the moment, but the fix does look correct to me, go ahead and commit it. Thanks for tracking this down! Thank you for reviewing this. I'm going to comit tomorrow night (JST), then MFC on early next week if no problems are reported. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Check for ports updates
Hi! Is there already a tool that checks the installed ports for available updates in /usr/ports? I've written such a tool, which seems to work fine already. Anyone interested? Ciao, Thomas Schürger. http://www.menden.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Check for ports updates
On Tue, Jun 06, 2000 at 09:27:16PM +0200, Thomas Schuerger wrote: Is there already a tool that checks the installed ports for available updates in /usr/ports? I've written such a tool, which seems to work fine already. Anyone interested? pkg_version(1) -- Will Andrews [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Check for ports updates
Is there already a tool that checks the installed ports for available
updates in /usr/ports?
I've written such a tool, which seems to work fine already. Anyone
interested?
pkg_version(1)
Ah, haven't seen that before. The output of pkg_version is very
canonical, but not very readable for humans. And it's slower than my
version... ;-)
Here is my version called "ports_updates":
-
#!/usr/bin/perl
# $Id: ports_updates,v 1.1 2000/06/01 20:24:06 schuerge Exp $
#
# 2601 schuerge first checkin
#
# TODO: Make version check more sophisticated. Currently the version strings are
# compared lexicographically, which may sometimes not be what is expected.
#
# ports_updates - fast check for available updates of installed ports
#
# (C) 2000 by Thomas Schürger Mail: [EMAIL PROTECTED]
#
# invocation:
# ports_updates
#
# description:
# Checks for each installed port if a newer version is available
# in /usr/ports. Ports are output in a sorted manner.
#
# Uses efficient merge-sort like algorithm for detecting updated
# port versions. The file /usr/ports/INDEX is inspected for
# detecting updates, which is not updated daily in the ports
# collection. Therefore the results are just almost exact.
#
$installedports = `\\ls -1 /var/db/pkg | sort -t "-" +0 -1`;
@installedports = split(/\n/, $installedports);
$c = 0;
foreach $i ( @installedports )
{
next if($i =~ /^\./); # super-user ls also lists dot-files
$i =~ /(.*)-([^\-].*)/;
$installedname[$c] = $1;
$installedversion[$c] = $2;
$c++;
}
$ports = ` cut -f "1-2" -d "|" /usr/ports/INDEX | sort -t "-" +0 -1`;
@ports = split(/\n/, $ports);
$c = 0;
foreach $i ( @ports )
{
$i =~ /^(.*)-([^\-\|].*)\|(.*)/;
$name[$c] = $1;
$version[$c] = $2;
$location[$c] = $3;
# $location[$c] =~ s/^\/usr\/ports\///;
$c++;
}
@a = stat("/usr/ports/INDEX");
$time = localtime($a[9]);
$age = -M "/usr/ports/INDEX";
if($age = 30)
{
printf("Ports available: %4d (last port index update: %s)\n",($#ports+1),$time);
}
else
{
printf("Ports available: %4d (last port index update %d day%s
ago)\n",($#ports+1),$age,$age == 1 ? "" : "s");
}
printf("Ports installed: %4d\n",($#installedname+1));
$c = 0; # counter for @ports
$d = 0; # counter for @installedports
while($c = $#name $d = $#installedname)
{
$a = $name[$c] cmp $installedname[$d];
# printf("%4d %-30s %-10s %4d %-30s %-10s
$a\n",$c,$name[$c],$version[$c],$d,$installedname[$d],$installedversion[$d]);
if($a == 0)
{
$ver = $version[$c];
$instver = $installedversion[$d];
if($ver gt $instver) # newer version available?
{
if(!$header) # has the table header not been printed yet?
{
print "\nThe following installed ports should be updated:\n\n";
print "Port name/usr/ports Installed Port location\n";
print
"--\n";
$header = 1;
}
printf("%-20s %-12s %-10s %s\n",$name[$c],$ver,$instver,$location[$c]);
}
}
$c++ if($a = 0);
if($a 0)
{
push(@obsolete,$installedname[$d]."-".$installedversion[$d]);
}
$d++ if($a = 0);
}
if(!$header)
{
print "\nCongratulations, all installed ports are up-to-date!\n";
}
if($#obsolete = 0)
{
print "\nThe following ports are installed but are no longer available in
/usr/ports\n";
print "(or now have a different name) and should be considered for deletion:\n\n";
foreach $i (@obsolete)
{
print "$i\n",
}
}
--
Ciao,
Thomas Schürger. http://www.menden.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Mesa segfaults
Hi! I'm having problems with Mesa 3.2. Some OpenGL programs don't work at all (they quit with a segmentation fault on initialization), some other programs work a short time and then crash the same way. I installed 4.0-Release some days ago (I had 4.0-Current before that), but that didn't solve the problem, neither did remaking the Mesa port. Is anyone else experiencing this? Any ideas of what to do? Ciao, Thomas Schürger. http://www.menden.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
problem creating new kernels with 20000604 snap
hi, i am a bit in trouble with a june 4th snap of -current. I have successfully installed it, and even compiled and installed a kernel using the GENERIC config. However when i try to remove devices from there, with high probability i end up in a panic while booting, generally in loader_preload() which tries to dereference a null pointer. I cannot really track down what is going on -- the loader shows something like module miibus module usb module splash and if i remove any usb device, or something ethernet using the mii bus, or (it seems) even some scsi device, it panics. Is this a bug or a feature ? Should i just keep all the pieces in GENERIC and add my options there ? help appreciated. thanks luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 ---+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Check for ports updates
If memory serves me right, Thomas Schuerger wrote: Is there already a tool that checks the installed ports for available updates in /usr/ports? I've written such a tool, which seems to work fine already. Anyone interested? pkg_version(1) Ah, haven't seen that before. The output of pkg_version is very canonical, but not very readable for humans. And it's slower than my version... ;-) Without having looked at ports_updates yet, let me just mention that: 1. If you want human-readable output, try "pkg_version -v". Maybe that should have been a default; certainly I always run it that way. But in the case that a program was going to postprocess the output, I didn't want it to have to wade through a bunch of pretty-printing stuff to get the results it needed. 2. When I was writing pkg_version, speed wasn't exactly a big priority to me, since pretty much *anything* was faster than what I was doing. Bruce. PS. I've been really bad about ignoring suggestions for pkg_version, mostly because it does everything I need/want it to do right now. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problem creating new kernels with 20000604 snap
On Tue, Jun 06, 2000 at 11:46:41PM +0200, Luigi Rizzo wrote: hi, i am a bit in trouble with a june 4th snap of -current. I have successfully installed it, and even compiled and installed a kernel using the GENERIC config. However when i try to remove devices from there, with high probability i end up in a panic while booting, generally in loader_preload() which tries to dereference a null pointer. I cannot really track down what is going on -- the loader shows something like module miibus module usb module splash and if i remove any usb device, or something ethernet using the mii bus, or (it seems) even some scsi device, it panics. I've seen something similar on Alpha when I removed the dc driver (leaving xl and miibus in). Removing dc and config / make depend / make /make install / reboot left me with a crashing alpha box. It only got as far as the loader printing a few lines on loading modules. And then a 'kernel stack not valid, HALT' line. Doing config -r on the same kernel config file worked OK. Is this a bug or a feature ? Should i just keep all the pieces in GENERIC and add my options there ? I don't pretend to understand this.. -- Wilko Bulte FreeBSD, the power to serve http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: not making a splash
I've tried to get a splash screen with two different 320x200x256 bitmaps now, and all I get is a blank screen. Is there something else I'm missing? Would you type 'boot -v' at the boot loader prompt and send me /var/run/dmesg.boot? I also like to see the output from 'vidcontrol -i mode' and 'vidcontrol -i adapter'. Are you sure the bitmap file is in BMP format and is not larger than 320x200? Is it possible for me to have a look at the file? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
vmware
I fianlly have vmware2 working on my current box, but I have noticed a couple things in my log, and I wanted to ask about them. Here's a little bit at the end: sio1: 3 more silo overflows (total 1268) /dev/vmmon: Vmx86_DestroyVM: unlocked pages: 359971, unlocked dirty pages: 217740 I guess I can understand the large number of silo overflows. I noticed that I can't seem to get any mails when I have vmware working, and I wish that wasn't so. The part that really worries me, tho, is the virtual memory warning. I was doing a lot of Windows software installation (which dragged on *really* slowly), but is there anything to be worried about in that warning above? Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FrontPage Extensions
From: "Phil Regnauld" [EMAIL PROTECTED] Terry Lambert writes: For what it's worth, the FP security issues are very well documented by ReadyToRun Software's site (these are the folks who do the UNIX ports for Microsoft). They also keep both BSDI 2.1 and 3.0 binaries available, and they know about FreeBSD (it's mentioned in the FAQ as an unsupported platform; apparently someone was having problems with the MD5 password hashing. Someone who cares should send them mail on how to update their FAQ to be more correct, and to raise FreeBSD's visibility as a platform -- e.g. what versions to us4e for what, install instructions for FreeBSD, etc.). FWIW, they now have a native FreeBSD version (FP extensions SR1, the port needs to be updated BTW) -- works like a charm with minor changes to one of the port patches. Yes, there is only a minor change that is needed to the port to get it working with FP 2K SR1. See PR 18581, PR 18788 I did find a problem with fpsrvadm.exe. If you have libcrypt linked to libscrypt, then fpsrvadm.exe creates an invalid MD5 password (I believe the buffer RTR used to hold the password returned from the crypt function is too small for the MD5 passwords). I have informed RTR and they said a fix would be available in the next release. For the time being the port (apache13-fp, or upcomming mod_frontpage) will still need to use the BSDI extentions, and statically compile the apache server with libdescrypt.a on systems where libcrypt is linked to libscrypt. Caveat: if you misconfigure your VirtualHost in some way, any call to the FP-patched Apache to that subweb's /_vti_bin/ will make it (apache) segfault. Will debug this if I find time. I haven't come across this problem. But I do know that it will segfault if you are not using a patched suexec, as the unpatched suexec will not allow fpexe to run. Scot PS. This is off topic for current, so please remove current when replying. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP + APM = panic - fixed!
On Wed, 7 Jun 2000, Mitsuru IWASAKI wrote: We're having this problem for long time (from the old 4.0-CURRENT days), but Mr. SUMITANI discovered a bug and fixed it. The problem was that we got worng gdt pointer for the current cpu, then panic... The followings is a patch to fix the problem. Thanks a lot, SUMITANI-san! Yes, this fixes panic and even 'halt -p' works as expected. 'zzz' command works too, but machine never come back from the suspend mode (looks like interrupt controller programmed incorrectly or something like this). -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
odd error in bioscall.s
I have this problem while building a kernel from sources cvsup'ed
today:
cc -c -x assembler-with-cpp -DLOCORE -O -pipe -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
-fformat-extensions -ansi -g -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL
-include opt_global.h -elf -mpreferred-stack-boundary=2 ../../i386/i386/bioscall.s
{standard input}: Assembler messages:
{standard input}:774: Error: operands given don't match any known 386 instruction
{standard input}:839: Error: operands given don't match any known 386 instruction
*** Error code 1
Stop in /usr/src/sys/compile/MANATEE.
The file bioscall.s has only 163 lines. Where is it getting 774 and
839?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
