Re: stange console problem
If I copy GENERIC to DEBUG and recompile the kernel it will not boot properly copy the file back to GENERIC and everything seems fine? I have searched the archives and read UPDATING, but nothing jumps out at me. Does anybody have any idea where I could look next? Chad On Sun, Jan 28, 2001 at 10:16:02PM -0700, Chad David wrote: On a current from last Sunday I recompiled a new kernel with just makeoptions DEBUG=-g and options DDB added to GENERIC and when I boot I see the first few spins of the loader booting the kernel and then all video output stops. After the boot finishs I get a login prompt but no keyboard response or video after that. Have you tried removing the 'makeoptions' line and using 'config -g KERNCONF' instead? That's how I build my debug kernels, and that worked fine last time I did it (last week or so). Also, when you copy the GENERIC file to another name, do you update the ident line? This should normally not matter but you never know with debugging kernels. In both cases you would need to examine the config utility. DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
vn, vnconfig and MFS death-warrant!
I have made mount_mfs and vnconfig print a warning and sleep for 15 seconds before continuing. Please convert to using mdconfig(8) for TMPFS uses. March 1st I will remove the functionality from mount_mfs and vnconfig, leaving only the message which will be an error obviously. April 1st I will remove vn, vnconfig and mount_mfs entirely. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: stange console problem
"Rogier R. Mulhuijzen" [EMAIL PROTECTED] writes: Have you tried removing the 'makeoptions' line and using 'config -g KERNCONF' instead? [...] Also, when you copy the GENERIC file to another name, do you update the ident line? None of this has any bearing on the problem, which was caused by a bug in gensetdefs.pl. Please update your source tree and rebuild your kernel. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
lock order reversal message
Hi, Booting with a kernel built from today's source (with devfs also in), I see this lock order reversal message: ### Routing daemons:. Doing IPv6 network setup:add net :::0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 net.inet6.ip6.forwarding: 0 - 0 net.inet6.ip6.accept_rtadv: 0 - 0 net.inet6.ip6.accept_rtadv: 0 - 1 lock order reversal 1st vnode interlock last acquired @ ../../kern/vfs_vnops.c:644 2nd 0xc02d5280 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:940 3rd 0xc85d314c vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:949 add net fe80::: gateway ::1 add net ff02::: gateway fe80::2a0:c9ff:fe8d:7c5f%fxp0 ND default interface = fxp0 IPv4 mapped IPv6 address support=YES. Additional daemons: syslogd. ### The machine is a SMP box, if that makes a difference. It does not seem to cause harm because it continue booting and I can log in. The disks are scsi on an adaptec ahc controller, with most partitions on da0 and /usr/obj a link to a partition on da2. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: stange console problem
None of this has any bearing on the problem, which was caused by a bug in gensetdefs.pl. Please update your source tree and rebuild your kernel. Eek. I had the gensetdefs.pl problem too, but my machine just seemed to lock. He says his machine does go on running. I have been pretty tied up lately, so maybe I read his post a bit too quickly. DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vn, vnconfig and MFS death-warrant!
"Poul-Henning Kamp" [EMAIL PROTECTED] wrote in message news:29877.980850630@critter... I have made mount_mfs and vnconfig print a warning and sleep for 15 seconds before continuing. Please convert to using mdconfig(8) for TMPFS uses. March 1st I will remove the functionality from mount_mfs and vnconfig, leaving only the message which will be an error obviously. April 1st I will remove vn, vnconfig and mount_mfs entirely. Could these modifications be ported to -STABLE to ease up the transition from -STABLE to -CURRENT ? I don't know if this is tied deeply on other changes in -CURRENT, but if it is not I'd like to use the new facility. Let me know if you want me to do some testing prior to committing the changes to -STABLE. I will happily contribute any help I can. Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: BSD Documentation
In [EMAIL PROTECTED], Beau wrote: Hi, I;m new to FreeBSD and want to have a read of the manual before I start installing willy-nilly, and I was wondering if there is a version available with the entire handbook in one html document? or a zip/tar containing it all would be fine. Thanks for your help and I look forward to BSDing! ftp://ftp.freebsd.org/pub/FreeBSD/doc/handbook/ -Robert To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
CONNER CFP1080 Filesystem Corruption
I just submitted a PR and patch in kern/24740 to fix a tagged queueing related filesystem corruption problem on CONNER CFP1080 drives. The patch adds an entry to the xpt_quirk_tabke. Anyone willing to commit this for me? Regards, Phone: (250)387-8437 Cy SchubertFax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: [EMAIL PROTECTED] Open Systems Group, ITSD, ISTA Province of BC --- Forwarded Message [headers removed] Date: Tue, 30 Jan 2001 08:30:01 -0800 (PST) Message-Id: [EMAIL PROTECTED] To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Subject: Re: kern/24740: CONNER CFP1080 Tagged Queueing Filesystem Corruption Reply-To: [EMAIL PROTECTED], [EMAIL PROTECTED] In-Reply-To: Your message of Tue, 30 Jan 2001 08:28:12 -0800 (PST) [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Resent-To: [EMAIL PROTECTED] Resent-Date: Tue, 30 Jan 2001 08:31:20 -0800 Resent-From: Cy Schubert [EMAIL PROTECTED] Thank you very much for your problem report. It has the internal identification `kern/24740'. The individual assigned to look at your report is: freebsd-bugs. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=24740 Category: kern Responsible:freebsd-bugs Synopsis: filesystem corruption CFP1080 CAM SCSI cam_xpt.c Arrival-Date: Tue Jan 30 08:30:01 PST 2001 --- End of Forwarded Message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vn, vnconfig and MFS death-warrant!
In message [EMAIL PROTECTED], "Patrick Bihan-F aou" writes: Could these modifications be ported to -STABLE to ease up the transition from -STABLE to -CURRENT ? I don't know if this is tied deeply on other changes in -CURRENT, but if it is not I'd like to use the new facility. I think I would rather leave -stable out of this for now. There are too many deployed production systems I think. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vn, vnconfig and MFS death-warrant!
At Tue, 30 Jan 2001 11:30:30 +0100, Poul-Henning Kamp [EMAIL PROTECTED] wrote: March 1st I will remove the functionality from mount_mfs and vnconfig, leaving only the message which will be an error obviously. April 1st I will remove vn, vnconfig and mount_mfs entirely. I think we should postpone the complete removing for a year (on release of 5.2), to give people a migration sugar. System upgrading (4.x - 5.x) will cause confusing situation, for example, living old 4.x vnconfig binary and new and splendid mdconfig. -- 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
RE: vn, vnconfig and MFS death-warrant!
Hi, Could these modifications be ported to -STABLE to ease up the transition from -STABLE to -CURRENT ? I don't know if this is tied deeply on other changes in -CURRENT, but if it is not I'd like to use the new facility. I think I would rather leave -stable out of this for now. There are too many deployed production systems I think. Just to make my intentions clear, I am not asking to remove vn/vnconfig(8)/mfs from -STABLE, I was just asking for the inclusion of md/mdconfig in -STABLE so that people (at least me :) ) can get ready for the day 5.0 will becomes -STABLE... My other problem is that I use vn's heavily and I find that some of their limitations are really annoying. While I could hack the relevent code to make myself happy, I think that there is little value in me doing that when it is obvious that they are going away in the not so distant future (5.0). Anyway, this is not a big deal. Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vn, vnconfig and MFS death-warrant!
Uh, self castigation. Sorry for inconvenience. At Tue, 30 Jan 2001 11:30:30 +0100, Poul-Henning Kamp [EMAIL PROTECTED] wrote: March 1st I will remove the functionality from mount_mfs and vnconfig, leaving only the message which will be an error obviously. April 1st I will remove vn, vnconfig and mount_mfs entirely. I think we should postpone the complete removing for a year till (on release of 5.2), to give people a migration sugar. == Otherwise System upgrading (4.x - 5.x) will cause confusing situation, ^ for example, living old 4.x vnconfig binary and together new and splendid mdconfig. ^ -- 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
Voodoo3 + XFree4 + DRM - simple_lock ? :-)
I've made a roadmap to getting hardware accel 3d support using a Voodoo3
under XFree-4. I've attached it in case anyone is interested.
However, recently simple_lock and friends seem to have disappeared, and the
kernel modules make some use of them (although there is still reference
to it in machine/smptests.h)
It looked like I could replace them with calls to mtx_* stuff
Removing the calls to simple_lock etc sure made it run a lot faster though,
but, I think I'd rather have the safety.
What are the 'new' corresponding structures and calls for simple_lock ?
This is a roadmap for getting a native 3d Accelerated XFree 4 under FreeBSD.
The XFree4 port changes fairly regularly so patches might have proven
difficult (and I don't want to maintain a patchset for every revision).
The instructions here can be followed with any tree even if stuff moves.
These won't work for a -current after the beginning of January
2001, since the simple_lock stuff has gone away in anticipation
of SMPng I assume.
I've only done this using a PCI Voodoo 3 2000 Card, but, I'd assume if your
card is working correctly then this will probably also work for you with
some minor modifications.
If you're using a 3dfx card, you'll need to grab the Glide SDK and install
the headers. And you'll need to grab the source for Glide 3 and install the
libraries. It compiled ok here, so I don't anticipate too many problems.
Glide Libraries:
Glide3x_devel-2.2-2.i386.rpm
to install;
rpm2cpio Glide3x_devel-2.2-2.i386.rpm | cpio -i -d
cp -r usr/include/glide3 /usr/include
Glide_V3-DRI-3.10-6.src.rpm
to install;
rpm2cpio Glide_V3-DRI-3.10-6.src.rpm | cpio -i
You'll get a Glide3.10.tar.gz
unpack that in a new directory;
mkdir glide3
cd glide3
tar zxvf ../Glide3.10.tar.gz
make -f makefile.linux
look in the lib directory
some of the symlinks are hosed, and will need to be fixed
cp the glide3 libraries to /usr/lib
This is for XFree-4.0.1 port revision 9 through to (so far)
XFree-4.0.2 port revision 5
cd /usr/ports/x11/XFree-4
make extract
make patch
make configure (answer the questions).
edit work/xc/config/cf/FreeBSD.cf
and add;
#define BuildXF86DRM YES
#define BuildXF86DRI YES
#define HasGlide3YES
At the bottom before the
#include bsdLib.rules
cd work/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel
Someone fell asleep at the wheel here over at VA-Linux, I assume it
was a CVS snapshot that was half finished... but, other than this
thing, good work :-)
Basically you want to change all references to SYSCTL_HANDLER_ARGS
to (SYSCTL_HANDLER_ARGS) in;
drmP.h
drm/memory.c
drm/sysctl.c
edit tdfx/tdfx_drv.c and change
callout_init(dev-timer) to
callout_init(dev-timer,0)
go back to the top of your XFree-4 tree and do;
make
make install (if you already have XFree 4 installed you can probably
skip this and continue on from here to get the kernel modules you need).
Now you have to wander back down to
work/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel
copy drm.ko to /usr/local/modules (or somewhere else convenient).
and copy tdfx/tdfx.ko to /usr/local/modules/tdfx_drm.ko (this clashes
with an existing native tdfx module for 'older' hardware). If this
wasn't built automatically just type make in the tdfx directory and it
should be built for you.
kldload drm.ko
this requires the agp module to load, even if you don't have an agp card.
kldload tdfx_drm.ko
You should see similar to this;
drm0: 3Dfx Voodoo 3 graphics accelerator port 0xdc00-0xdcff mem
0xe800-0xe9ff,0xee00-0xefff irq 0 at device 14.0 on pci0
info: [drm] Initialized tdfx 1.0.0 19991009 on minor 0
If all goes well make an entry in /usr/local/etc/rc.d that loads your
local modules on boot (or edit your /boot/ files if you're really game).
I have this in /usr/local/etc/rc.d/3dfx.sh
#!/bin/sh
case $1 in
start)
[ -d /usr/local/modules ] (
[ -x /usr/local/modules/drm.ko ] (
kldload /usr/local/modules/drm.ko
)
[ -x /usr/local/modules/tdfx_drm.ko ] (
kldload /usr/local/modules/tdfx_drm.ko
)
echo -n ' XF86-DRI'
)
;;
stop)
kldunload tdfx_drm.ko
kldunload drm.ko
;;
*)
echo "usage: `basename $0` {start|stop}" 2
exit 64
;;
esac
In your /etc/X11/XF86Config you need to also have
Load "glx"
Load "dri"
If you have an existing libGL.so.14 in /usr/X11R6/lib
mv it to libGL.so.14.old and symlink libGL.so.14 to libGL.so.1
(ports requiring Mesa check for libGL.so.14, and will link to the hardware
accelerated version).
3D acceleration only
Re: CONNER CFP1080 Filesystem Corruption
On Tue, Jan 30, 2001 at 08:41:44 -0800, Cy Schubert - ITSD Open Systems Group wrote: I just submitted a PR and patch in kern/24740 to fix a tagged queueing related filesystem corruption problem on CONNER CFP1080 drives. The patch adds an entry to the xpt_quirk_tabke. Anyone willing to commit this for me? I'll handle it. See my reply to the PR. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Voodoo3 + XFree4 + DRM - simple_lock ? :-)
On Wed, Jan 31, 2001 at 04:54:30AM +1000, Andrew Kenneth Milton wrote: However, recently simple_lock and friends seem to have disappeared, and the kernel modules make some use of them (although there is still reference to it in machine/smptests.h) It looked like I could replace them with calls to mtx_* stuff Removing the calls to simple_lock etc sure made it run a lot faster though, but, I think I'd rather have the safety. What are the 'new' corresponding structures and calls for simple_lock ? Mutexes should be used in places where simplelocks were used. With few exceptions, sleep mutexes should be used (even though simplelocks were spin locks). See mutex(9) for details. Be forewarned that there is work in progress to clean up the mutex API that will probably be checked in within a week. Transitioning from the current mutex API to the upcoming one will be trivial, but it will have to be done if you convert to mutexes in the next few days. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lock order reversal message
On Tue, Jan 30, 2001 at 01:56:26PM +0200, John Hay wrote: Booting with a kernel built from today's source (with devfs also in), I see this lock order reversal message: ### Routing daemons:. Doing IPv6 network setup:add net :::0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 net.inet6.ip6.forwarding: 0 - 0 net.inet6.ip6.accept_rtadv: 0 - 0 net.inet6.ip6.accept_rtadv: 0 - 1 lock order reversal 1st vnode interlock last acquired @ ../../kern/vfs_vnops.c:644 2nd 0xc02d5280 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:940 3rd 0xc85d314c vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:949 add net fe80::: gateway ::1 add net ff02::: gateway fe80::2a0:c9ff:fe8d:7c5f%fxp0 ND default interface = fxp0 IPv4 mapped IPv6 address support=YES. Additional daemons: syslogd. ### The machine is a SMP box, if that makes a difference. It does not seem to cause harm because it continue booting and I can log in. This shouldn't be a problem. The lock order reversal has been there for a long time and hasn't caused any problems, but since simplelocks were used before, we didn't have any diagnostics to tell us it was there. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Voodoo3 + XFree4 + DRM - simple_lock ? :-)
Jason Evans wrote: On Wed, Jan 31, 2001 at 04:54:30AM +1000, Andrew Kenneth Milton wrote: However, recently simple_lock and friends seem to have disappeared, and the kernel modules make some use of them (although there is still reference to it in machine/smptests.h) It looked like I could replace them with calls to mtx_* stuff Removing the calls to simple_lock etc sure made it run a lot faster though, but, I think I'd rather have the safety. What are the 'new' corresponding structures and calls for simple_lock ? Mutexes should be used in places where simplelocks were used. With few exceptions, sleep mutexes should be used (even though simplelocks were spin locks). See mutex(9) for details. Be forewarned that there is work in progress to clean up the mutex API that will probably be checked in within a week. Transitioning from the current mutex API to the upcoming one will be trivial, but it will have to be done if you convert to mutexes in the next few days. where can we see the new spec (or at least a sample)? Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Voodoo3 + XFree4 + DRM - simple_lock ? :-)
On Tue, Jan 30, 2001 at 01:18:05PM -0800, Julian Elischer wrote: Jason Evans wrote: Mutexes should be used in places where simplelocks were used. With few exceptions, sleep mutexes should be used (even though simplelocks were spin locks). See mutex(9) for details. Be forewarned that there is work in progress to clean up the mutex API that will probably be checked in within a week. Transitioning from the current mutex API to the upcoming one will be trivial, but it will have to be done if you convert to mutexes in the next few days. where can we see the new spec (or at least a sample)? This is the most recent patch. I expect that the final result will be pretty similar, though Bosko may still change a couple of details: http://people.freebsd.org/~bmilekic/code/mutex_cleanup-5.patch Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fatal trap 12 panic when starting vinum plex
On a very current -current, I get this reproducable panic when I try to revive a vinum plex: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = 0100 fault virtual address = 0x1a0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc015f01d stack pointer = 0x10:0xdfad6ca0 frame pointer = 0x10:0xdfad6cac code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 612 (vinum) kernel: type 12 trap, code=0 CPU0 stopping CPUs: 0x0002... stopped. Stopped at mtx_enter_hard+0x125: movl0x1a0(%edx),%eax db trace mtx_enter_hard(c28e3930,0,0,0,c28e3900) at mtx_enter_hard+0x125 _mtx_enter(c28e3930,0,c2830240,87,0) at _mtx_enter+0x132 lockrange(0,cec3f330,c28e3900,c25f6000,2) at lockrange+0x31 revive_block(2,c25f6000,c2816d00,dfa90a80,0) at revive_block+0x2f6 start_object(c25f6000,0,c2816d00,dfa90a80,d9d4ac30) at start_object+0x10d setstate(c25f6000,dfad6e08,c2816d00,c25f6000,dfad6dd8) at setstate+0x1fd vinumioctl(c2816d00,c400464c,c25f6000,3,dfa90a80) at vinumioctl+0x4c1 spec_ioctl(dfad6e08,dfad6df0,c020e5f1,dfad6e08,dfad6e98) at spec_ioctl+0x2c spec_vnoperate(dfad6e08,dfad6e98,c019e8ac,dfad6e08,c292ddc0) at spec_vnoperate+0x15 ufs_vnoperatespec(dfad6e08,c292ddc0,0,400,c0283780) at ufs_vnoperatespec+0x15 vn_ioctl(c292ddc0,c400464c,c25f6000,dfa90a80,dfa90a80) at vn_ioctl+0x110 ioctl(dfa90a80,dfad6f80,bfbff64c,bfbff1cc,2) at ioctl+0x20a syscall2(2f,2f,2f,2,bfbff1cc) at syscall2+0x2a0 Xint0x80_syscall() at Xint0x80_syscall+0x23 --- syscall 0x36, eip = 0x8072ecc, esp = 0xbfbff1a0, ebp = 0xbfbff68c --- db Dunno if this is actually vinum, or it is caused by the mere fact that I'm trying to run -current. Anyway, it happens in UP as well as SMP, and I am not using DEVFS. Oh, one more thing: the vinum volume (raid01) apparantly runs without any problems - as long as I don't try to revive a faulty plex within the volume. /Niels Chr. -- Niels Christian Bank-Pedersen, NCB1-RIPE. "Hey, are any of you guys out there actually *using* RFC 2549?" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Bug in tftpd ?
Hi, I think i just encountered a bug in FreeBSD's tftpd-implementation. Actually it's a bug that i spotted a while back with a friend of mine in NetBSD's implementation, but never really bothered with it since i don't use tftpd myself, but i am in a position now where i need to with FreeBSD. The bug only triggers when trying to fetch files bigger than 32 MB. On NetBSD it happened around a 16 MB boundary ... (but i may have interpreted blocksizes wrong). The issue is located in a minor difference in tftpd's own "block" count and arpa/tftp.h 's struct tftphdr 's "tu_block" type declaration arpa/tftp.h defines the block count: unsigned short tu_block; /* block # */ tftpd.c 's xmitfile and recvfile functions define the block count: volatile int block; What happens is kinda obvious after quite a lot of data has been sent without any problems ... suddenly tftpd's block-counter starts wrapping while arpa/tftp.h's block counter does simply increase more. This results in "TIMEOUT errors" as the block-sequence numbers simply won't match any more. If patches are required let me know ... -- Pascal Hofstee daeron @ shadowmere . student . utwente . nl begin LOVE-LETTER-FOR-YOU.TXT.vbs I'm a signature virus. Please copy me and help me spread. end To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vn, vnconfig and MFS death-warrant!
Just a note. phk March 1st I will remove the functionality from mount_mfs and phk vnconfig, leaving only the message which will be an error obviously. Before March 1st, src/release/Makefile, src/release/scripts/doFS.sh, src/release/texts/FLOPPIES.TXT, and some PicoBSD stuffs need some work to convert from vnconfig(8) to mdconfig(8). Is Anybody working on this? -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Voodoo3 + XFree4 + DRM - simple_lock ? :-)
Hey, I've been fooling with this (and Glide3) but under FBSD 4.2. Didn't have the time or inclination to do it under the latest current. Good to see someone's been crazy^Wbrave enough to try. It'd bee really nice if someone could make the kernel modules part of the current tree, the same way they are under Linux. Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: stange console problem
Problem solved. cp GENERIC.hints DEBUG.hints Without them it isn't very happy... did I miss this as a requirement somewhere, or is my hardware/timing just a little funky? Chad On Tue, Jan 30, 2001 at 04:03:10PM +0100, Rogier R. Mulhuijzen wrote: None of this has any bearing on the problem, which was caused by a bug in gensetdefs.pl. Please update your source tree and rebuild your kernel. Eek. I had the gensetdefs.pl problem too, but my machine just seemed to lock. He says his machine does go on running. I have been pretty tied up lately, so maybe I read his post a bit too quickly. DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: stange console problem
Chad David wrote: Problem solved. cp GENERIC.hints DEBUG.hints Without them it isn't very happy... did I miss this as a requirement somewhere, or is my hardware/timing just a little funky? Yes, you were not reading the commit messages or UPDATING or -current. You should have a /boot/device.hints for your machine. You dont need GENERIC.hints or DEBUG.hints if you have this set up correctly. As a head start, you can cp GENERIC.hints to /boot/device.hints and you're done. config and 'make install' will not let you forget this.. Were you installing your kernel by hand or something? Chad On Tue, Jan 30, 2001 at 04:03:10PM +0100, Rogier R. Mulhuijzen wrote: None of this has any bearing on the problem, which was caused by a bug in gensetdefs.pl. Please update your source tree and rebuild your kernel. Eek. I had the gensetdefs.pl problem too, but my machine just seemed to lock. He says his machine does go on running. I have been pretty tied up lately, so maybe I read his post a bit too quick ly. DocWilco 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
