Re: mktemp() patch
At 12:07 AM -0500 6/9/00, Dan Nelson wrote: I still suggest not using symbols at all, since I'd like to be able to quickly remove tempfiles by hand without worrying if I have to escape # or ^, etc. Uh, if I understand the update, the '#' is ALREADY used for this, in the current implementation. If you haven't been having any trouble with it for the past few years, it seems odd to worry about it with the new implementation. Also, you do not have to worry about '^' in the middle of a filename. That is only significant when it's the first character of the line. Yes, someone might worry about it the first time they go to delete a file with one of those characters in it's name, but it won't take too long before they learn either to just 'rm blah*' or they'll learn that they do not have to worry about it. Just MO. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Latest pcm commits and ESS 1868...
With the latest pcm commits, there's a lot of pops and clicks during the playing of MP3's. This is with the ESS 1868 sound card. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
I still suggest not using symbols at all, since I'd like to be able to quickly remove tempfiles by hand without worrying if I have to escape # or ^, etc. Then disable globbing first. (csh et al) "set noglob" or (sh et al) "set -f noglob". John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
VMware detection code in boot loader
Would anyone object if I add a ficl word to detect whether we're booting
from a vmware virtual machine? I find it extremely useful when I'm running
FreeBSD as a guest under NT. Because it is a dual cpu box, I can't use a
single kernel to boot both directly or inside the virtual machine. With this
new word, I can determine which kernel to use in the loader script, saving
me the trouble to unload and reload a new kernel each time I reboot.
Here's the patch to the boot loader,
Index: boot/ficl/ficl.h
===
RCS file: /home/ncvs/src/sys/boot/ficl/ficl.h,v
retrieving revision 1.14
diff -u -r1.14 ficl.h
--- boot/ficl/ficl.h2000/06/01 18:10:43 1.14
+++ boot/ficl/ficl.h2000/06/07 18:18:38
@@ -860,6 +860,7 @@
#if defined(__i386__) !defined(TESTMAIN)
extern void ficlOutb(FICL_VM *pVM);
extern void ficlInb(FICL_VM *pVM);
+extern void vmware(FICL_VM *pVM);
#endif
#ifdef __cplusplus
Index: boot/ficl/words.c
===
RCS file: /home/ncvs/src/sys/boot/ficl/words.c,v
retrieving revision 1.27
diff -u -r1.27 words.c
--- boot/ficl/words.c 2000/06/01 18:10:43 1.27
+++ boot/ficl/words.c 2000/06/07 18:19:13
@@ -4800,6 +4800,7 @@
#ifdef __i386__
dictAppendWord(dp, "outb", ficlOutb, FW_DEFAULT);
dictAppendWord(dp, "inb", ficlInb,FW_DEFAULT);
+dictAppendWord(dp, "vmware",vmware, FW_DEFAULT);
#endif
#endif
Index: boot/ficl/i386/sysdep.c
===
RCS file: /home/ncvs/src/sys/boot/ficl/i386/sysdep.c,v
retrieving revision 1.7
diff -u -r1.7 sysdep.c
--- boot/ficl/i386/sysdep.c 1999/09/29 04:43:07 1.7
+++ boot/ficl/i386/sysdep.c 2000/06/07 18:18:13
@@ -111,6 +111,26 @@
c=inb(port);
stackPushINT(pVM-pStack,c);
}
+
+/*
+ * vmware ( -- version )
+ * Get vmware version.
+ */
+void
+vmware(FICL_VM *pVM)
+{
+int version, magic = 0;
+
+#defineVMWARE_MAGIC0x564d5868
+#defineVMWARE_PORT 0x5658
+
+ __asm __volatile("inl %%dx, %%eax"
+ : "=a" (version), "=b" (magic)
+ : "0" (VMWARE_MAGIC), "d" (VMWARE_PORT), "c" (0xa));
+ if (magic != VMWARE_MAGIC)
+ version = -1;
+ stackPushINT(pVM-pStack, version);
+}
#endif
#endif
To use this feature, you first create a file /boot/vmware.4th:
: vmware-conf
vmware dup 0 if
." VMware version " . cr
." Loading /boot/vmware.conf..." cr
s" /boot/vmware.conf" read-conf
else
drop
then
;
then create /boot/vmware.conf which sets the kernel to use:
kernel="/kernel.VMWARE"
finally, change your /boot/loader.rc to
include /boot/loader.4th
include /boot/vmware.4th
initialize drop
vmware-conf
boot-conf
check-password
-lq
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
Would anyone object if I add a ficl word to detect whether we're booting from a vmware virtual machine? Sounds good to me! -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
Mark Murray wrote: What is the purpose of this? It looks hugely wasteful to me. If you really need a single random bit, it is not good to waste a block of hard-gained gryptographic randomness; can you not use a pseudo-random bit-generator? arc4random() does not consume entropy except the first time it is called and when explicitly reseeded through arc4random_stir(). Apart from that it's a deterministic function (the arc4 stream cipher), but it's still a reasonably good cryptographic PRNG because arc4 is a cryptographically strong algorithm. But I repeat myself; are you still intending to use cryptographic security for one bit? What does that buy you? An attacker will laugh at the waste of resources that went into a coin-flip :-). Much better is to use something cheaper like time-of-day XOR 1 whatever. Pseudo random numbers are so cheap (or they should be) that you just don't want to try and 'optimize' here. It is much better to be conservative and use a good PRNG until it *proves* to be very problematic. Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _ \_ _(_) (_)/_\_| \ _|/' \/ (_)(_) (_)(_) (_)(_)' _\o_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
Luoqi Chen wrote: Would anyone object if I add a ficl word to detect whether we're booting from a vmware virtual machine? I find it extremely useful when I'm running FreeBSD as a guest under NT. Because it is a dual cpu box, I can't use a single kernel to boot both directly or inside the virtual machine. With this new word, I can determine which kernel to use in the loader script, saving me the trouble to unload and reload a new kernel each time I reboot. Here's the patch to the boot loader, Index: boot/ficl/ficl.h === RCS file: /home/ncvs/src/sys/boot/ficl/ficl.h,v retrieving revision 1.14 diff -u -r1.14 ficl.h --- boot/ficl/ficl.h2000/06/01 18:10:43 1.14 +++ boot/ficl/ficl.h2000/06/07 18:18:38 @@ -860,6 +860,7 @@ #if defined(__i386__) !defined(TESTMAIN) extern void ficlOutb(FICL_VM *pVM); extern void ficlInb(FICL_VM *pVM); +extern void vmware(FICL_VM *pVM); 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 ... Just my EC 0.02, Jeroen -- Jeroen C. van Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _ \_ _(_) (_)/_\_| \ _|/' \/ (_)(_) (_)(_) (_)(_)' _\o_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Can't make installworld :(
On Fri, Jun 09, 2000 at 01:53:35PM +0400, Hostas Red [EMAIL PROTECTED] wrote: I can't make installworld for some time with following message: vm/vm_object.h - vm/vm_object.ph vm/vm_page.h - vm/vm_page.ph vm/vm_pageout.h - vm/vm_pageout.ph vm/vm_pager.h - vm/vm_pager.ph vm/vm_param.h - vm/vm_param.ph vm/vm_prot.h - vm/vm_prot.ph vm/vm_zone.h - vm/vm_zone.ph vm/vnode_pager.h - vm/vnode_pager.ph *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl/utils/h2ph. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl/utils. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl. *** Error code 1 Some manipulations with manual installation of perl didn't help. :( Any ideas? I had same problem in the past. Some person, can't recall his name, said that it's known problem and discussed in the lists. His advice was to search in list archives. I've never found the exact answer but probably my search was wrong. Perhaps you'll have better luck. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
On Thu, Jun 08, 2000 at 08:47:36PM -0700, Kris Kennaway wrote: filesystems. For example, should we limit all FreeBSD file names to 8.3 single-case in case someone wants to run from an old-style MSDOS partition? Bad example. Not _all_ filenames but temp. ones only which allows to run FreeBSD binary in MSDOS FS with MSDOS files. Basically, I think the answer is not to use a nwfs or smbfs filesystem as your TMPDIR :-) mktemp() makes temp files in any directory including current one. -- 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: Can't make installworld :(
In message [EMAIL PROTECTED], Hosta s Red writes: I can't make installworld for some time with following message: vm/vm_object.h - vm/vm_object.ph vm/vm_page.h - vm/vm_page.ph vm/vm_pageout.h - vm/vm_pageout.ph vm/vm_pager.h - vm/vm_pager.ph vm/vm_param.h - vm/vm_param.ph vm/vm_prot.h - vm/vm_prot.ph vm/vm_zone.h - vm/vm_zone.ph vm/vnode_pager.h - vm/vnode_pager.ph *** Error code 1 I've seen this before. h2ph will return a non-zero exit status if it failed to open _any_ of the files listed on the command line. This will typically happen if you have a dangling symbolic link somewhere in /usr/include. The error message indicating exactly which files h2ph couldn't open will be somewhere among all the 'XX.h - XX.ph' messages. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
On Fri, 9 Jun 2000, Andrey A. Chernov wrote: On Thu, Jun 08, 2000 at 08:47:36PM -0700, Kris Kennaway wrote: filesystems. For example, should we limit all FreeBSD file names to 8.3 single-case in case someone wants to run from an old-style MSDOS partition? Bad example. Not _all_ filenames but temp. ones only which allows to run FreeBSD binary in MSDOS FS with MSDOS files. The point is the same. Files created by FreeBSD binaries during the course of operation don't conform to an 8.3 monocase naming scheme (think of dotfiles for example). I don't believe there's such a thing as a lowest common denominator of file system naming conventions - either a filesystem can support UFS names (perhaps through a translation later) or it's not suitable for running FreeBSD from. Basically, I think the answer is not to use a nwfs or smbfs filesystem as your TMPDIR :-) mktemp() makes temp files in any directory including current one. Yes, but in practice it's not used that way since you can't write to most directories on the system except ~ and /tmp and relatives. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
On Fri, 9 Jun 2000, Kris Kennaway wrote: The point is the same. Files created by FreeBSD binaries during the course of operation don't conform to an 8.3 monocase naming scheme (think of dotfiles for example). I don't believe there's such a thing as a lowest common denominator of file system naming conventions - either a filesystem can support UFS names (perhaps through a translation later) or it's not layer suitable for running FreeBSD from. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
But I repeat myself; are you still intending to use cryptographic security
for one bit? What does that buy you? An attacker will laugh at the waste
of resources that went into a coin-flip :-). Much better is to use something
cheaper like time-of-day XOR 1 whatever.
Pseudo random numbers are so cheap (or they should be) that you
just don't want to try and 'optimize' here. It is much better to
be conservative and use a good PRNG until it *proves* to be very
problematic.
Why not just XOR the whole lot into the current ${randomnumber}?
That way, at least the effort of the whole calculation is not wasted
as much.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Boot Manager
Greetings, What is the quick way to restore the boot manager (dual os). Lost it when I reloaded Win98. Have 4.0 CD, machine running 5.0-current. John Hengstler To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
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. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
extern void ficlOutb(FICL_VM *pVM); extern void ficlInb(FICL_VM *pVM); I'm an idiot. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Latest pcm commits and ESS 1868...
Donn Miller wrote: With the latest pcm commits, there's a lot of pops and clicks during the playing of MP3's. This is with the ESS 1868 sound card. - Donn I hate to send "me too" emails, but i think it's the driver. My SB Live has worked great until last night, when i caught my source up to date. I was running on source from 6/4 which worked fine. I'm going to check it out again in a bit to see if it's been updated. I recommend you do the same. -Otter 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: mktemp() patch
On Fri, Jun 09, 2000 at 12:58:27PM -0700, Kris Kennaway wrote: Bad example. Not _all_ filenames but temp. ones only which allows to run FreeBSD binary in MSDOS FS with MSDOS files. The point is the same. Files created by FreeBSD binaries during the course of operation don't conform to an 8.3 monocase naming scheme (think of dotfiles for example). I don't believe there's such a thing as a lowest common denominator of file system naming conventions - either a filesystem can support UFS names (perhaps through a translation later) or it's not suitable for running FreeBSD from. Dotfiles usually created in user's home directory which is in UFS. What I mean is simple processing using temp files, consider running zip or unzip binaries. Proper way will be to sense FS name/abilitites and tune available charset in accordance with them. mktemp() makes temp files in any directory including current one. Yes, but in practice it's not used that way since you can't write to most directories on the system except ~ and /tmp and relatives. I don't care about /tmp which is in UFS, I care about current directory. Probably /tmp-prefix sensing code helps to solve this. -- 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: mktemp() patch
On Fri, Jun 09, 2000 at 10:02:44PM +0200, Mark Murray wrote:
But I repeat myself; are you still intending to use cryptographic security
for one bit? What does that buy you? An attacker will laugh at the waste
of resources that went into a coin-flip :-). Much better is to use something
cheaper like time-of-day XOR 1 whatever.
Pseudo random numbers are so cheap (or they should be) that you
just don't want to try and 'optimize' here. It is much better to
be conservative and use a good PRNG until it *proves* to be very
problematic.
Why not just XOR the whole lot into the current ${randomnumber}?
That way, at least the effort of the whole calculation is not wasted
as much.
Why to XOR true random bits from arc4random() with non-random bits from
getpid()? It only weakens. Better way is just remove any getpid() code and
left arc4random() only.
--
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: mktemp() patch
"Andrey A. Chernov" wrote:
On Fri, Jun 09, 2000 at 10:02:44PM +0200, Mark Murray wrote:
But I repeat myself; are you still intending to use cryptographic security
for one bit? What does that buy you? An attacker will laugh at the waste
of resources that went into a coin-flip :-). Much better is to use something
cheaper like time-of-day XOR 1 whatever.
Pseudo random numbers are so cheap (or they should be) that you
just don't want to try and 'optimize' here. It is much better to
be conservative and use a good PRNG until it *proves* to be very
problematic.
Why not just XOR the whole lot into the current ${randomnumber}?
That way, at least the effort of the whole calculation is not wasted
as much.
Good point, there is no need to throw them away indeed.
Why to XOR true random bits from arc4random() with non-random bits from
getpid()? It only weakens. Better way is just remove any getpid() code and
left arc4random() only.
Then you will get collisions which you will have to deal with. I am not
familiar with the code but if we can handle collisions nicely then that
would be the way to go: 64^6 = 2^36 possibilities which is nice...
Cheers,
Jeroen
--
Jeroen C. van Gelderen o _ _ _
[EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_)
_ \_ _(_) (_)/_\_| \ _|/' \/
(_)(_) (_)(_) (_)(_)' _\o_
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
Kris Kennaway wrote: On Fri, 9 Jun 2000, Andrey A. Chernov wrote: On Thu, Jun 08, 2000 at 08:47:36PM -0700, Kris Kennaway wrote: filesystems. For example, should we limit all FreeBSD file names to 8.3 single-case in case someone wants to run from an old-style MSDOS partition? Bad example. Not _all_ filenames but temp. ones only which allows to run FreeBSD binary in MSDOS FS with MSDOS files. The point is the same. Files created by FreeBSD binaries during the course of operation don't conform to an 8.3 monocase naming scheme (think of dotfiles for example). I don't believe there's such a thing as a lowest common denominator of file system naming conventions - either a filesystem can support UFS names (perhaps through a translation later) or it's not suitable for running FreeBSD from. There really is no reason to use 72 characters instead of -say- 64. The increase in security is marginal and if the side-effect of using 64 is that it works with more filesystems than that is a Good Thing (TM). We are not alone in this world as -say- Microsoft tends to think. It's probably better to just get rid of the PID and use randomness troughout the name than to use 72 characters. 64^6 vs. 2*(72^3) . Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _ \_ _(_) (_)/_\_| \ _|/' \/ (_)(_) (_)(_) (_)(_)' _\o_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
Peter Wemm wrote: 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. Rethinking, emulation may not be the best suggestion. People might confuse it with Linux emulation. How about 'hardware' ? or 'platform' or your suggestion here ? Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _ \_ _(_) (_)/_\_| \ _|/' \/ (_)(_) (_)(_) (_)(_)' _\o_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freezing and rebooting with vidcontrol -m on
On Sat, 10 Jun 2000, Matthew Thyer wrote: Are you using power management (presumably so you can poweroff your ATX system) ? You must not use APM with an SMP kernel currently. Remove the lines in your /etc/rc.conf that read: apm_enable="YES" apmd_enable="YES" (Or change them to ="NO"). Or you can update your sources because this problem has just been fixed (but there are suspend/resume problems with SMP still). Been there, did that, suspend even works. Waiting on lusers to logout so I can reboot and try a new kernel, I think i might have been using some console options it didnt like. Adam wrote: Hi, I don't really know where to go with this issue on my own anymore so im tossing it to the list for suggestions. I had a celeron running in a Abit BX6-2 system running -current approx a month or 1.5 old. Today I moved the disks to a Abit BP6 Motherboard and recompiled the kernel for smp and the other hardware changes I intended to make. Well, when I boot it up it would get down to approx "starting i386 whatever" and the boot would stop, the keyboard wouldnt type (although numlock would work for x amount of time) and you couldnt drop into ddb. Sometimes it would stick in this braindead mode, sometimes if you tried typing things to get it unstuck it would just reboot after a brief total keyboard lockup. No panic, just a reboot. I booted singleuser and cleaned up my rc.conf, disabling some noncritical things, and got the system booting fine. I have a usb logitech mouse by the way. Later I noticed no mouse cursor on my consoles even though I had moused running, so I ran vidcontrol -m on. WHAM. I had found the culprit. Okay so I know what caused it and what not to run ;0 I took the opportunity to cvsup and upgrade the whole system to -current as of today, and to my dismay it still does the same thing. I really wish I could drop into ddb when it happens but it wont let me. If serial might be a better option I could probably dig out a null modem cable... Suggestions Please! 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
ps2 mouse troubles
Just one more report to add to the ps2 mouse discussion: Today I moved from 4.0 to -CURRENT. Now my mouse jumps around like other people are reporting. It worked fine before. I tried using a different mouse. I tried using NOCHECKSYNC (even though I'm not getting the messages). I tried this both with and without moused, in X and in syscons. Nothing fixed it. This machine is a desktop with no APM support running. I'm not using a KVM. The two kinds of mice were a Logitech TrackMan Marble+ (detected as Intellimouse) and a standard Microsoft Mouse. Does this info help anyone out? I'll include my dmesg (with -v enabled): Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #2: Fri Jun 9 23:34:10 EDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/RJK191 Calibrating clock(s) ... TSC clock: 167095319 Hz, i8254 clock: 1193539 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter "TSC" frequency 167046023 Hz CPU: Pentium/P55C (167.05-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping = 3 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX real memory = 83820544 (81856K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x002d8000 - 0x04fe7fff, 80805888 bytes (19728 pages) avail memory = 78757888 (76912K bytes) bios32: Found BIOS32 Service Directory header at 0xc00fdb70 bios32: Entry = 0xfdb80 (c00fdb80) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xdba1 pnpbios: Found PnP BIOS data at 0xc00f6d50 pnpbios: Entry = f:6906 Rev = 1.0 Other BIOS signatures found: ACPI: Preloaded elf kernel "kernel" at 0xc02bf000. Intel Pentium detected, installing workaround for F00F bug npx0: math processor on motherboard npx0: INT 16 interface i586_bzero() bandwidth = 175254118 bytes/sec bzero() bandwidth = 88425148 bytes/sec pcib0: Host to PCI bridge on motherboard found- vendor=0x8086, dev=0x7100, revid=0x01 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 found- vendor=0x8086, dev=0x7110, revid=0x01 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 found- vendor=0x8086, dev=0x7111, revid=0x01 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[20]: type 4, range 32, base ffa0, size 4, enabled found- vendor=0x8086, dev=0x7112, revid=0x01 class=0c-03-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=d, irq=10 map[20]: type 4, range 32, base ef80, size 5, enabled found- vendor=0x8086, dev=0x7113, revid=0x01 class=06-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[90]: type 4, range 32, base ff40, size 4, enabled found- vendor=0x1002, dev=0x4755, revid=0x9a class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=11 map[10]: type 1, range 32, base fe00, size 24, enabled map[14]: type 4, range 32, base ec00, size 8, enabled map[18]: type 1, range 32, base ffeff000, size 12, enabled found- vendor=0x1274, dev=0x5000, revid=0x00 class=04-01-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=10 map[10]: type 4, range 32, base ee80, size 6, enabled found- vendor=0x109e, dev=0x0350, revid=0x12 class=04-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=10 map[10]: type 3, range 32, base fddff000, size 12, enabled found- vendor=0x10b7, dev=0x9000, revid=0x00 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=11 map[10]: type 4, range 32, base ef00, size 6, enabled pci0: PCI bus on pcib0 pci0: Intel 82439TX System controller (MTXC) (vendor=0x8086, dev=0x7100) at 0.0 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xffa0-0xffaf at device 7.1 on pci0 ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xffa0 ata0: mask=03 status0=50 status1=00 ata0: mask=03 status0=50 status1=00 ata0: devices = 0x1 ata0: at 0x1f0 irq 14 on atapci0 ata1: iobase=0x0170 altiobase=0x0376 bmaddr=0xffa8 ata1: mask=01 status0=50 status1=ff ata1: mask=01 status0=00 status1=ff ata1: devices = 0x4 ata1: at 0x170 irq 15 on atapci0 pci0: Intel 82371AB/EB (PIIX4) USB controller (vendor=0x8086, dev=0x7112) at 7.2 irq 10 pci0: Intel 82371AB Power management controller (vendor=0x8086, dev=0x7113) at 7.3 pci0: ATI Mach64-GU graphics accelerator (vendor=0x1002, dev=0x4755) at 10.0 irq 11 pcm0: AudioPCI ES1370 port 0xee80-0xeebf
Re: VMware detection code in boot loader
Luoqi Chen wrote: Would anyone object if I add a ficl word to detect whether we're booting from a vmware virtual machine? I find it extremely useful when I'm running FreeBSD as a guest under NT. Because it is a dual cpu box, I can't use a single kernel to boot both directly or inside the virtual machine. With this new word, I can determine which kernel to use in the loader script, saving me the trouble to unload and reload a new kernel each time I reboot. Here's the patch to the boot loader, --- boot/ficl/ficl.h2000/06/01 18:10:43 1.14 +++ boot/ficl/ficl.h2000/06/07 18:18:38 @@ -860,6 +860,7 @@ #if defined(__i386__) !defined(TESTMAIN) extern void ficlOutb(FICL_VM *pVM); extern void ficlInb(FICL_VM *pVM); ^^^ +extern void vmware(FICL_VM *pVM); We have inb and outb. Can't vmware be written in Forth? If inl cannot be replaced with inb, I'd rather add inl than vmware. To use this feature, you first create a file /boot/vmware.4th: : vmware-conf vmware dup 0 if ." VMware version " . cr ." Loading /boot/vmware.conf..." cr s" /boot/vmware.conf" read-conf else drop then ; then create /boot/vmware.conf which sets the kernel to use: kernel="/kernel.VMWARE" finally, change your /boot/loader.rc to include /boot/loader.4th include /boot/vmware.4th initialize drop vmware-conf boot-conf check-password IMHO, it would be better to add exec="include /boot/vmware.4th" to the end of your /boot/loader.conf, and either execute vmware-conf from there or script the whole thing: s" arch-i386" environment? [if] \ Get vmware version, magic 0x564d868 ( VMware magic ) = [if] .( VMware version ) . cr .( Loading /boot/vmware.conf...) cr s" /boot/vmware.conf" read-conf [else] drop [then] [then] Either way, no changes to /boot/loader.rc would be required. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Hmmm - I have to go check this. My reality assumptions are shattered. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
IPFW, sound, and modules
Hi! Please excuse me, this is my first time posting a question. I know you people are only answering out of courtesy, and I appreciate any replies I may get. I was using FreeBSD 4.0 successfully with IPFW and Sound enabled. Recently I upgraded to 5.0 snapshot 2000/05/20 and my kernel now uses /modules/*.ko as much as possible. 1) So I took FIREWALL out of kernel configuration, and instead uses ipfw.ko. But now "ipfw add 15000 fwd 192.168.1.1 from any to 192.168.1.2" no longer works. I read from mailing lists that I need "options IPFIREWALL_FORWARD" in kernel configuration file. So I added that and recompile everything. Still doesn't work. My question is how do I enable forwarding in ipfw.ko? 2) Before upgrading to 5.0, my sound card worked well, and all I needed is to place "device pcm" in kernel configuration. But now, "mixer"... still works (I can use "cam" to adjust volume) and "line-in" still works (I can watch TV using "fxtv") but "wave" no longer work (Machine hangs when I run "mpg123"). Was there any changes to "pcm" driver recently? Thanks again. - Kelly To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
