Re: Remote GDB *still* buggy...
On Wed, Jun 14, 2000 at 12:27:27PM -0600, Justin T. Gibbs wrote: On Wednesday, 14 June 2000 at 11:05:41 -0600, Justin T. Gibbs wrote: I still can't get remote GDB to work correctly in a 5.0-current environment at speeds greater than 9600bps. Is anyone else experiencing similar results? I thought that grog had fixed this... So did I. Are you just getting hangs? What kind of UART? On which side of the connection? I'm using my Thinkpad 770X as the GDB host and it says: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A On the machine I'm trying to debug, a Dell Precision 410, I have: sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A Isn't it needed anymore to set flags 0x80 on the debug port? -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbfs second mount
On Sun, 18 Jun 2000, kit wrote: The problem I am having is that the second mount kills the first. then on ls BP I get ls: BP: Broken pipe Thats strange, I have four smbfs mounts on my machine. I thought that that might be because I had only 1 device entry in /dev/net so I did No, device entry used only at the mount time and freed when mount_smbfs command terminated. Which didn't help. What else should I check or try to get more than one concurent smbfs mounted? Please send the output of 'smbutil -v lc' and 'df' commands to me. Exact version of NT server and SP number will be also useful. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP!: config changes...
On Fri, 16 Jun 2000, Peter Wemm wrote: 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) This thread is long, so maybe I missed something.. Can we have the *.hints file loadable as a module of some special type (like kernel.conf), and searched for during configuration like userconfig did? Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 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
On Sat, 17 Jun 2000, Matthew Dillon wrote:
...
It looks like sccnattach() is calling scvidprobe() and scvidprobe()
is then:
0xc023484b scvidprobe+7: cmpl $0x0,0x10(%ebp)
0xc023484f scvidprobe+11: setne %al
0xc0234852 scvidprobe+14: movzbl %al,%eax
0xc0234855 scvidprobe+17: push %eax
0xc0234856 scvidprobe+18: call 0xc0229c90 vid_configure
0xc023485b scvidprobe+23: push %ebx
0xc023485c scvidprobe+24: push $0xc0282682
0xc0234861 scvidprobe+29: call 0xc0229b4c vid_find_adapter
Calling vid_configure and vid_configure is dying.
The list is generated from a linker_set ... one of those special linker
lists.
Something's broken the list maybe the DATA_SET macro is something ilke
that.
Dependencies for setdef.h were broken by removing ioconf.o from ${OBJS}.
Previously, any change in the configuration resulted in a change to
ioconf.c, so setdefs.h got rebuilt. Now, removing whole drivers doesn't
change anything in ${OBJS}, so the old setdefs.h gets used and the wrong
amount of space is allocated for some linker sets. This bug cost me a
few hours when I tried removing console drivers in order to debug the
console initialization bugs.
This quick fix also backs out rev.1.180:
diff -c2 Makefile.i386~ Makefile.i386
*** Makefile.i386~ Sun Jun 18 21:22:28 2000
--- Makefile.i386 Sun Jun 18 21:31:50 2000
***
*** 173,178
${NORMAL_C}
! setdef0.c setdef1.c setdefs.h: ${OBJS} param.o
! @gensetdefs ${OBJS} param.o
# this rule stops ./assym.s in .depend from causing problems
--- 172,177
${NORMAL_C}
! setdef0.c setdef1.c setdefs.h: Makefile ${OBJS}
! @gensetdefs ${OBJS}
# this rule stops ./assym.s in .depend from causing problems
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
pcm problems in vaio 600re
hi! did anyone have success getting the sound card in the VAIO 600RE laptop to work? dmesg | grep pcm says: pcm0: Yamaha DS-1E (YMF744) mem 0xfecf-0xfecf7fff irq 9 at device 9.0 on pci0 doing a cat /kernel /dev/audio0 does make a sound, indeed... but trying with mpg123 on a file doesn't :-( Is there any way to do some debugging on this, or does anyone know how to get this to work? Mark -- Nice testing in little China... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Remote GDB *still* buggy...
: On the machine I'm trying to debug, a Dell Precision 410, I have: : sio1 at port 0x2f8-0x2ff irq 3 on isa0 : sio1: type 16550A : : Isn't it needed anymore to set flags 0x80 on the debug port? : :Yes. That was the output from a generic kernel. My debug kernel :was crashing the machine. 8-) I'm using flags 0xC0 for the debug :kernel. : :__ :Justin Bruce's patch didn't hurt, but it didn't help my -Os crashes either. I have to fallback to -O kernels, which sucks. I have no clue where the problem is. I am able to turn DDB and INVARIANT* on again. I haven't tried remote GDB debugging. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
** HEADS UP ** Binutils upgrade in 1 hour
In about an hour, I will be upgrading Binutils to 2.10 release. This will take several hours to do. During this time, you may not want to CVSup. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** Binutils upgrade in 1 hour
: :In about an hour, I will be upgrading Binutils to 2.10 release. This :will take several hours to do. During this time, you may not want to :CVSup. : :-- :-- David([EMAIL PROTECTED]) Any chance this will make -Os kernel compiles work again? -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** Binutils upgrade in 1 hour
On Sun, Jun 18, 2000 at 11:57:04AM -0700, Matthew Dillon wrote: Any chance this will make -Os kernel compiles work again? No clue. The Binutils that -CURRENT currently has is a snapshot of the 2.10 release branch (from Sourceware's anoncvs server). There is only 1.5 mo's. difference between the two and at the point I took the snapshot, the Binutils developers were being very cautious what they let into that branch. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic with userquota(softupdates?)
From: Kevin Day [EMAIL PROTECTED] Subject: Panic with userquota(softupdates?) To: [EMAIL PROTECTED] Date: Fri, 16 Jun 2000 18:55:01 -0500 (CDT) Cc: [EMAIL PROTECTED] I keep getting panics in dqget(ufs_quota.c), with a -current from a couple of days ago. I think this might be softupdates related, since I can't make it happen with softupdates turned off, although it's quite possible that it has nothing to do with it. Does anyone have any idea what might be causing this? Any other information that might be useful here? -- Kevin I have just committed a change to sys/contrib/softupdates/ffs_softdep.c (delta 1.68) which corrects a panic in the kernel when quotas and soft updates are used together. While the specific problem that I fixed appears somewhat different than the one you are reporting, it may be related. I suggest that you update to the above delta and see if it solves your problem. If your problem persists, let me know. As always, if you can give a specific set of inputs which trigger the problem, that is always helpful in tracking it down. Kirk McKusick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
As one of the proponents of the change, my apologies for not taking part in this thread earlier - I am way behind in my reading of most of the lists. On Thu, Jun 08, 2000 at 11:11:42AM +1000, Kris Kennaway wrote: Instead of using only alphabetic characters, the patch uses the following character set: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~ This was discussed in -audit as well - and most of the points brought up here have already been discussed there. Peter, I hope I've got the right version of the patch Looks about right. The character set matches my last suggestion (the only other item was making base64 and padchar `const'). On Thu, Jun 08, 2000 at 04:08:18PM +1000, Matthew Dillon wrote: It would be a good idea to avoid any punctuation. Could you please provide some rationale for this statement. I agree there are valid reasons for not using some specific characters, but I don't see any justification for a blanket ban. On Fri, Jun 09, 2000 at 04:15:45AM +1000, Garance A Drosihn wrote: context that reads blah@blah:blah as userid@hostname:fname Good point. I hadn't considered the impact of letting [rs]cp loose on the output from mktemp. At the same time, I do like to see the set expanded as much as possible, without causing any problems. That was my rationale as well. I went through the 7-bit printable set and wiped out the characters I though would cause problems. On Thu, Jun 08, 2000 at 09:51:34PM +1000, Bruce Evans wrote: Why are we still using the pid? It is highly non-random. It was originally used to ensure a separate starting point for separate processes, The other advantage is that it was easy to locate and delete temp files associated with dead processes. Given the change to a BASE64 PID, this is no longer true and I agree with Kris that it can be dropped. If you need to clean up after dead processes, you'll need to use lsof or fstat to work out what files are still wanted. On Fri, Jun 09, 2000 at 01:48:20PM +1000, Kris Kennaway wrote: I'm not sure that weird filesystems are a valid argument against mktemp() naming - there are LOTS of UNIX code which assumes UNIX namespace conventions, and it's not just mktemp() which is going to break on weird 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? I agree with Kris here. I briefly considered the problem of support for non-UFS filesystems and decided that it was reasonable for standard Unix utilities to make use of the facilities offered by the native filesystem - ie UFS. In any case, I believe that mktemp(3) will always return a valid filename for the filesystem (though it might take some time to pick one). _gettemp() [the function underlying mktemp(3), mkstemp(3) etc] invokes lstat(2) on each sample path and requires that lstat() returns ENOENT for it to succeed. If lstat() is given an invalid pathname, it should return something like EINVAL - which will make _gettemp() try again. If a filesystem implementation returns ENOENT when given a pathname that is not valid on that filesystem, then the filesystem implementation is broken and should be fixed. Note that AFAIK, currently FreeBSD cannot meet mkstemp guarantees on _any_ non-local filesystem (and some shared filesystem types) because the relevant locking mechanisms either don't exist or don't work. On Fri, Jun 09, 2000 at 02:57:02PM +1000, Garance A Drosihn wrote: Should the new mktemp check some kind of environment variable, and use a different list (or maybe even a totally different algorithm) depending on the value? I think that selecting between a number of different algorithms based on an environment variable might be over-kill. However it could be useful to allow the user to control the character set used by mktemp() via an environment variable. For example MKTEMP_CHARSET="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz._-" would give you the POSIX portable filename character set (apart from the `no leading hyphen' bit). Maybe support two variables - one to defines the allowable initial characters and another to define the allowable following characters if it's different. The downside is that this means that the user can pretty much control the temporary filenames used by processes - which means it would need to be disabled for setuid (and maybe setgid) processes. On Fri, Jun 09, 2000 at 03:08:57PM +1000, 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. ... I'd rather stick with easy-to-read and type tempnames. `easy-to-read and type' is basically incompatible with `hard-to-guess'. I'd suggest that most people will be deleting mktemp filenames using wildcards, shell-completion or cut-and-paste. Any shell that can't understand a filename that it has globbed is broken. Similarly, any shell that
-e option to umount?
What do people think about adding a -e option to umount(8) to eject a removable medium where possible? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers 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
(In general, I don't think I like putting the hints in a separate place or even a separate file... now I have two or three files I have to deal with rather then one config file. It makes managing bunches of config files annoying. I wish that the earlier format hadn't been ripped out. I don't see much of an advantage of moving it into a loader-accessible file). The hints file itself is largely just filler; large chunks of it are going to go away properly soon as the drivers it's still helping out learn more about PnP. As has already been pointed out, it's also correct for the hints file to be associated with the system, not the kernel. -- \\ 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
compiling kernel with -Os or -O2
Anyone try to compile the kernel with an optimization higher than -O, such as -Os or -O2? For example, when I compile my kernel with -Os, I get a "fatal trap 12: page fault in supervisor mode" right after I see this on my screen while the kernel is booting: 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 #0: Sun Jun 18 19:06:34 EDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/CUSTOM Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P55C (166.45-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping = 3 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX real memory = 62914560 (61440K bytes) This is all the further the boot gets before the page fault. Of course, as David O'Brien pointed out, optimization levels beyond -O aren't supported. But, I'm curious as to what the cause of this is, as it may reveal a deeper problem someplace. For example, is the problem with binutils, the kernel source code, or both? Hopefully, we'll find out after the binutils upgrade is complete. I should point out that using -O to compile the kernel gives no problems booting; it's just -Os that causes the problems for me. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
What do people think about adding a -e option to umount(8) to eject a removable medium where possible? SGIs and SUNs use an 'eject' command for CDs and DAT tapes. Here are the manpages for comparison: Irix 6.5: http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650db=manfname=/usr/share/catman/u_man/cat1/eject.zsrch=eject Solaris 2.7: http://www.FreeBSD.org/cgi/man.cgi?query=ejectapropos=0sektion=0manpath=SunOS+5.7format=html Regards, Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
SGIs and SUNs use an 'eject' command for CDs and DAT tapes. OpenBSD 2.6 uses 'mt' and 'eject' NetBSD 1.4 uses 'eject' as well. http://www.FreeBSD.org/cgi/man.cgi?query=ejectapropos=0sektion=0manpath=OpenBSD+2.6format=html http://www.FreeBSD.org/cgi/man.cgi?query=ejectapropos=0sektion=0manpath=NetBSD+1.4format=html Regards, Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
/usr/ports/sysutils/eject On Mon, Jun 19, 2000 at 02:09:44AM +0200, Marc van Woerkom wrote: SGIs and SUNs use an 'eject' command for CDs and DAT tapes. OpenBSD 2.6 uses 'mt' and 'eject' NetBSD 1.4 uses 'eject' as well. http://www.FreeBSD.org/cgi/man.cgi?query=ejectapropos=0sektion=0manpath=OpenBSD+2.6format=html http://www.FreeBSD.org/cgi/man.cgi?query=ejectapropos=0sektion=0manpath=NetBSD+1.4format=html Regards, Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Charles Anderson[EMAIL PROTECTED] No quote, no nothin' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
On Sun, 18 Jun 2000, Warner Losh wrote: In message [EMAIL PROTECTED] "Jeroen C. van Gelderen" writes: : 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. I disagree with this strongly. PRNG have proven time and time again to weaken security due to their less than random nature. It is my judgement that going down this path would be very bad, especially when cryptographically strong random number generators exist and are part of the base FreeBSD system. We should just use those... Actually thats what Jeroen was referring to - use of arc4random(). It's still a PRNG :-) 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
FOLLOWING config changes? : Kernel profiling support
I've recently cleaned up and updated my sources, saving some changes I made elsewhere. I performed a buildworld, installworld, etc. yesterday night with no problems. When I rebuilt my kernel, after having collected the appropriate hints for the system and modified my kernel configuration file appropriately, I had some trouble booting it. The loader would load the kernel into memory but when it was time to `boot' it, I was not able to see anything on the console, this includes the initial copyright message. Furthermore, my keyboard was unresponsive. However, I could tell that the kernel was booting nonetheless (even though I could not see it), judging by the hard disk drives' activity (and upon checking /var/log/messages after I booted with my previously saved kernel). I then decided to rebuild the kernel with the hints statically compiled in, and this worked fine, and the kernel booted properly. Note that I did not use any notable optimisation flag during the build, and that this is all on i386 architecture. However, I decided to build a kernel with profiling support this morning (config -p KERNEL, etc.), and I left the hints compiled in statically. The kernel built fine, but when it came time to boot it, again, no response from keyboard, nothing at the console. This time though, the kernel wasn't even booting. Has anybody noticed/tried this recently? Am I forgetting something? Cheers, Bosko. -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 [EMAIL PROTECTED] * http://www.technokratis.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: bioops patch.
Background: Ideally struct buf should have had a real OO like operations vector like vnodes have it, and struct bioops is the first step towards that. struct buf will eventually become merely an iocmd structure, so why do we want to complicate things here? No, struct buf will remain the cache-handle. the iocmd is called struct bio. Even if struct buf stays around, its cache-handle role will be diminished, probably just a translation layer to vm object based caching. We already have an OO method for bwrite: VOP_BWRITE(), the problem is most of the code are still calling bwrite() directly. Will it solve your problem if we change every bwrite() into a VOP_BWRITE()? Well, I'm not sure it is correct to go the detour around Vnodes, if we do, we need to add VOP_BAWRITE, VOP_BDWRITE and all those other operations as well. Don't you need bp-b_ops-bawrite(), bp-b_ops-bdwrite() as well? I feel it's better to go through the vnode, because for all the bufs belong to the same vnode, these b_ops are most likely to be the same. And for a stackable filesystem, you may easily implement a passthru call with vnode, how would you deal with it using struct buf? But what vnode would you use for a buffer associated with a freeblock bitmap ? Each buffer belongs to a vnode, a buffer associated with a freeblock bitmap belongs to the device vnode, and that's the vnode we could use. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. -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
In [EMAIL PROTECTED], Luoqi Chen wrote: It is not the loader's job to detect the underlying hardware configuration. I disagree. I would like to tell which machine I am booting on to choose an appropriate kernel. Eventually (it may take a while) we should be able to boot any i386/AT based machine with a single kernel which dynamically loads drivers for available hardware (and different locking modules for UP and SMP for that matter). My -current harddisk (physically) moves between 3 machines with very different requirements, not just SMP. FPU, few or much RAM, ISA stuff on identical places etc. I can select the kernel manually, but after a crash or power fail I might not be in a position to do it again. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FOLLOWING config changes? : Kernel profiling support
Ya know, I never thought about checkign /var/log/messages on mine to see
if it was, in fact, booting (I thought it was, it sounded like it was, but
I couldn't think of a way to check) ...
Using kernel sources up-to-date as of a few hours ago, I've tried to pare
my optimzatins down to a simple '-O -pipe', and I'm getting the same thing
as you, where I effectively get:
Booting kernel ...
\
on my screen, and that's the end of it. Looking at /var/log/messages, it
looks like I am getting a full reboot happening, right down to
initializing 'vmmon', but nothing to my screen.
I've been trying to follow the -current list to see if any ideas/solutions
pop up, but the only things I've noticed so far have revolved around
optimization issues, but its more then possible that I missed a message
...
My last good kernel, that boot'd fine, is:
@(#)FreeBSD 5.0-CURRENT #0: Wed Jun 14 01:03:00 ADT 2000
With every other one since resulting in the above ...
On Sun, 18 Jun 2000, Bosko Milekic wrote:
I've recently cleaned up and updated my sources, saving some changes
I made elsewhere. I performed a buildworld, installworld, etc. yesterday
night with no problems.
When I rebuilt my kernel, after having collected the appropriate hints
for the system and modified my kernel configuration file appropriately, I
had some trouble booting it. The loader would load the kernel into memory
but when it was time to `boot' it, I was not able to see anything on the
console, this includes the initial copyright message. Furthermore, my
keyboard was unresponsive. However, I could tell that the kernel was
booting nonetheless (even though I could not see it), judging by the hard
disk drives' activity (and upon checking /var/log/messages after I booted
with my previously saved kernel).
I then decided to rebuild the kernel with the hints statically compiled
in, and this worked fine, and the kernel booted properly. Note that I did
not use any notable optimisation flag during the build, and that this is
all on i386 architecture.
However, I decided to build a kernel with profiling support this morning
(config -p KERNEL, etc.), and I left the hints compiled in statically.
The kernel built fine, but when it came time to boot it, again, no
response from keyboard, nothing at the console. This time though, the
kernel wasn't even booting.
Has anybody noticed/tried this recently? Am I forgetting something?
Cheers,
Bosko.
--
Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237
[EMAIL PROTECTED] * http://www.technokratis.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
On Sun, 18 Jun 2000 21:06:52 +, Charles Anderson wrote: /usr/ports/sysutils/eject On Mon, Jun 19, 2000 at 02:09:44AM +0200, Marc van Woerkom wrote: SGIs and SUNs use an 'eject' command for CDs and DAT tapes. Whether as a separate command or as part of umount this is certainly something worth having by default. In particular new users may be a while before they find ports/packages or will just end up in the questions list. Also speaking from my own experience I would have expected something like this to be part of the system and would have never even looked for a port. Francisco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FOLLOWING config changes? : Kernel profiling support
Yes, this is what I initially got. Although I'm not quite interested in this particular problem. What I need is profiling to work. Still, what you should look at is adding the `hints' directive to your kernel configuration file, if you haven't done so already. See if that fixes your problem. On Mon, 19 Jun 2000, The Hermit Hacker wrote: Ya know, I never thought about checkign /var/log/messages on mine to see if it was, in fact, booting (I thought it was, it sounded like it was, but I couldn't think of a way to check) ... Using kernel sources up-to-date as of a few hours ago, I've tried to pare my optimzatins down to a simple '-O -pipe', and I'm getting the same thing as you, where I effectively get: Booting kernel ... \ on my screen, and that's the end of it. Looking at /var/log/messages, it looks like I am getting a full reboot happening, right down to initializing 'vmmon', but nothing to my screen. I've been trying to follow the -current list to see if any ideas/solutions pop up, but the only things I've noticed so far have revolved around optimization issues, but its more then possible that I missed a message ... My last good kernel, that boot'd fine, is: @(#)FreeBSD 5.0-CURRENT #0: Wed Jun 14 01:03:00 ADT 2000 With every other one since resulting in the above ... -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 [EMAIL PROTECTED] * http://www.technokratis.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
Francisco Reyes wrote: Whether as a separate command or as part of umount this is certainly something worth having by default. In particular new users may be a while before they find ports/packages or will just end up in the questions list. Well, you could have both. For example, you could have the -e switch to umount which performs the eject function. In addition, you could have "eject" as a link to umount, and umount itself would check argv[0] to see if it is being executed as eject or umount. If it's eject instead of umount, then perform whatever action the -e flag does. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
** HEADS UP ** upgrade to Binutils 2.10 postponed
Due to an issue of being able to tell just what the official Binutils 2.10 source is, I've put off the upgrade. Hopefully I can do it tomorrow. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FOLLOWING config changes? : Kernel profiling support
that did her, thanks ... should this maybe be mentioned in
/usr/src/UPDATING? I've gotten into the habit of pretty much checking
there first, and saw no mention of this (could be blind too, its happened
before) ...
On Mon, 19 Jun 2000, Bosko Milekic wrote:
Yes, this is what I initially got. Although I'm not quite interested in
this particular problem. What I need is profiling to work.
Still, what you should look at is adding the `hints' directive to your
kernel configuration file, if you haven't done so already. See if that
fixes your problem.
On Mon, 19 Jun 2000, The Hermit Hacker wrote:
Ya know, I never thought about checkign /var/log/messages on mine to see
if it was, in fact, booting (I thought it was, it sounded like it was, but
I couldn't think of a way to check) ...
Using kernel sources up-to-date as of a few hours ago, I've tried to pare
my optimzatins down to a simple '-O -pipe', and I'm getting the same thing
as you, where I effectively get:
Booting kernel ...
\
on my screen, and that's the end of it. Looking at /var/log/messages, it
looks like I am getting a full reboot happening, right down to
initializing 'vmmon', but nothing to my screen.
I've been trying to follow the -current list to see if any ideas/solutions
pop up, but the only things I've noticed so far have revolved around
optimization issues, but its more then possible that I missed a message
...
My last good kernel, that boot'd fine, is:
@(#)FreeBSD 5.0-CURRENT #0: Wed Jun 14 01:03:00 ADT 2000
With every other one since resulting in the above ...
--
Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237
[EMAIL PROTECTED] * http://www.technokratis.com/
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
In message [EMAIL PROTECTED] Mitsuru IWASAKI writes: : Hi, here is the latest report on our ACPI project's progress. As I told you on the Train in Tokyo: Cool! Way Cool! ACPI should enable us to properly put the chipsets in laptops to sleep and then wake them up again. Right now pccard insert/removal can be missed when you put a laptop to sleep... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
