SMPNG kernel on UP
I've noticed a few things wrong with the SMPNG code. These are mostly impressions. As I learn more about them, I'll file more formal bug reports. This is an FYI to fellow travelers along the path. 1) You can't have I386_CPU at all. This is likely bad in the long run, but OK for now. 2) APM is now broken. It worked after the ACPI integration, but after the SMPNG stuff neither apm -z nor the BIOS keys seems to suspend. 3) Linux emuation is panics the machine in linux_open on a normal boot. 4) Need to rebuild all libkvm things, yet again, but make world fixed that :-) 5) USB ethernet is more likely to hang the machine than it was before. This hand is transient, however. I have seen one crash removing the USB adapter that I didn't used to see, but wasn't in a position to look at it in detail. 6) Switching virtual termintals from the X server to the console is busted. 7) SSH to a machine on my local network is dog slow sometimes. I can type about one line or two lines ahead of it in email when it happens. It feels like a network pause of about 1-2 seconds. Local windows behave well during these episodes. 8) The machine seems to pause more often than it used to for reasons totally unknown at this time. These pauses last for several seconds and then things are good again. This might be related to #7, but the total machine pauses happen w/o any network connections. Next time this happens, I'll hit capslock to see if the interrupts are blocked or not. But other than that, the system is usable. I've been able to build world on my laptop running this afternoon's tree. I've also been able to do some development with it as well, both in X and on the console. Things are much more stable than I had feared, but less stable than I like them. Since I knew what I was getting into, it isn't a huge deal, but I wanted to give feedback to people about this. Now is a bad time to be thinking about cuting a production machine/snapshot from the -current branch. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMPNG kernel on UP
Warner Losh wrote: I've noticed a few things wrong with the SMPNG code. These are mostly impressions. As I learn more about them, I'll file more formal bug reports. This is an FYI to fellow travelers along the path. 1) You can't have I386_CPU at all. This is likely bad in the long run, but OK for now. Err, this should be fixed now. Do you have the latest i386/include/smp.h? 2) APM is now broken. It worked after the ACPI integration, but after the SMPNG stuff neither apm -z nor the BIOS keys seems to suspend. Hmm. 3) Linux emuation is panics the machine in linux_open on a normal boot. Hate to ask, but are you sure it is loading the right module? With the kernel.ko change, modules don't live in the same place anymore, and I haven't seen any commits to kldload, /etc/rc, or linux.sh that takes this into account. 5) USB ethernet is more likely to hang the machine than it was before. This hand is transient, however. I have seen one crash removing the USB adapter that I didn't used to see, but wasn't in a position to look at it in detail. Hmm, ok. 7) SSH to a machine on my local network is dog slow sometimes. I can type about one line or two lines ahead of it in email when it happens. It feels like a network pause of about 1-2 seconds. Local windows behave well during these episodes. Hmm, haven't seen this. 8) The machine seems to pause more often than it used to for reasons totally unknown at this time. These pauses last for several seconds and then things are good again. This might be related to #7, but the total machine pauses happen w/o any network connections. Next time this happens, I'll hit capslock to see if the interrupts are blocked or not. Haven't seen this either. :( Here are some of the known issues that are gotchas: 1) sio is broken. It doesn't receieve any data, although Greg has just fixed this and should be committing a fix shortly. 2) There seem to be some problems with possibly the ahc controller (haven't tried ata yet) where after several hours of heavy load (-j 256 buildworlds and the like) the disk driver will hang. The machine will run fine, top still runs over ssh, for example. However, any process that accesses the disk hangs since it blocks forever waiting on the disk, thus rendering the machine useless. Note that this only happens with SMP. UP seems to be very stable. I haven't had a UP kernel panic or freeze in weeks. 3) The alpha is not entirely stable. I'm working on adding interrupt threads to the alpha right now, which will hopefully help. I think there are some areas in the kernel that are assuming we have the type of locking we have on x86 with ithreads, and am hoping that alpha ithreads will fix those assumptions. Also, there are many changes in dfr's alpha patches that I at least do not understand, and it possibly some of them are incomplete/bogus. Now is a bad time to be thinking about cuting a production machine/snapshot from the -current branch. Are there good times for this? ;-) Warner -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'interrupt-level buffer overflows' for sio device?
On Thu, 7 Sep 2000, Warner Losh wrote: Also, this is interrupt level overflows. We can run the fast interrupts fast enough to harvest characters from the hardware. What's not happening is that sio's bottom half isn't being run fast enough so the interrupt level buffers overflow. Not surprising, since sio's bottom half scheduler (schedsofttty()) is now null. The top half apparently only gets scheduled if there is an output interrupt, a fake output interrupt (flags 0x8) a modem status change, or urgent data. Urgent data probably keeps it going for slip and pppd, but there is no urgent data in the termios line discipline. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMPNG kernel on UP
On Fri, 08 Sep 2000 00:36:12 CST, Warner Losh wrote: 6) Switching virtual termintals from the X server to the console is busted. This does not appear to be a problem here, with SMPng and XFree86-3.3.6. 7) SSH to a machine on my local network is dog slow sometimes. I can type about one line or two lines ahead of it in email when it happens. It feels like a network pause of about 1-2 seconds. Local windows behave well during these episodes. I also haven't noticed this. Have you managed to determine that it's SSH and not your X11 terminal emulator? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
netscape
Hi, I have installed netscape4-navigator and I can't launch its. I've got following message: ld.so failed: Can't find shared library "libXt.so.6.0" What can I do? Piotr Wozniak To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: microuptime() went backwards
If I build the kernel without apm, then there is no clock because the statclock is broken on this computer. = | Kenneth Culver | FreeBSD: The best NT upgrade| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Fri, 8 Sep 2000, Greg Lehey wrote: On Friday, 8 September 2000 at 0:18:07 -0400, Kenneth Wayne Culver wrote: On Fri, 8 Sep 2000, Greg Lehey wrote: On Thursday, 7 September 2000 at 22:49:30 -0400, Kenneth Wayne Culver wrote: The point I'm making is that we've had these problems before SMPng, and that you can't automatically assume that it's SMPng just because you get the messages. On the other hand, the 7 digits seem to be a pretty reliable signature. I'm getting this error while starting XFree86 4.0.1 on my laptop computer, and I'm using FreeBSD 4.1-STABLE, so I'm sure it's not the SMP stuff that's causing it. Right, but you're not getting the 7 digit microsecond count, right? You should contact phk. Well, here is one of the messeges: Sep 7 14:35:55 laptop /kernel: microuptime() went backwards (10412.355980 - 10412, -694583121) this is bad.. right ? :-) Well, at any rate it looks very funny. If this is a laptop, try building a kernel without apm and see if that helps. 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: netscape
On 08-Sep-00 Piotr Woniak wrote: Hi, I have installed netscape4-navigator and I can't launch its. I've got following message: ld.so failed: Can't find shared library "libXt.so.6.0" You are using the FreeBSD a.out version of Netscape. For this to work you need the 2.2/3.x compat distribution installed. You can install this with sysinstall. Another option is to use the Linux version (ports/www/linux-netscape47-communicator) which has the added advantage of having more plugins (eg flash) available. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: linux module breaks current
On Thu, 07 Sep 2000 16:04:11 +0200, Sheldon Hearn wrote: Just a warning to anyone wanting to try out SMPng -- make sure that you hdon't have ``linux_enable="YES"'' in /etc/rc.conf. I got a kernel trap when /etc/rc tried to load the linux module. I haven't had time to get a panic and backtrace to Marcel, but I thought I'd send this warning for now. I'd like to feed back that this was pilot error. Although I had up-to-date modules in /boot/kernel, I still had stale modules in /modules. The bottom line? Be sure to remove your /modules when you upgrade. If you want to keep your old modules around to support an old kernel, do this: if [ ! -d /boot/kernel.old ]; then mv /modules /boot/kernel.old chflags noschg /kernel mv /kernel /boot/kernel.old/kernel.ko chflags noschg /boot/kernel.old/kernel.ko fi The linuxulator is working just fine for me under the new SMPng. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMPNG kernel on UP
On Fri, 08 Sep 2000 00:01:54 MST, John Baldwin wrote: 3) Linux emuation is panics the machine in linux_open on a normal boot. Hate to ask, but are you sure it is loading the right module? With the kernel.ko change, modules don't live in the same place anymore, and I haven't seen any commits to kldload, /etc/rc, or linux.sh that takes this into account. I got annoyed when I read your question, so I set out to reproduce the fatal trap. Of course, since I got the trap, I've deleted my /modules directory. So you're aboslutely right. :-) See my reply to my own message with the subject "HEADS UP: linux module breaks current" to this list. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
New ATA tagged queuing patch available
From the README: ATA-tagged-queueing-diff-0908: Add support for ATA channels with both a master and a slave, even combos where only on of them supports tagged queuing should work now. Also only switch on tagged queuing on IBM DPTA DTLA series drives, the older DJNA has firmware problems. I am working on a SW solution to that, but for now only enable tagged queuing on drives that is known to work. Get it from http://freebsd.dk, and let me know your results If I dont get any serious problem reports I'll commit this shortly, making FreeBSD the first OS that has tagged Queuing support for ATA drives :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CFR: acpi userland manpages
On Fri, Sep 01, 2000 at 12:09:31AM +0900, Mitsuru IWASAKI wrote: Hi, I've just imported acpi userland tools and writing manpages for them with contributers in Japan. Please review them and send any comments (or diffs) for me ([EMAIL PROTECTED]) in terms of English/roff or whatever. The draft version of manpages are available at http://people.FreeBSD.org/~iwasaki/acpi/acpidump.8 http://people.FreeBSD.org/~iwasaki/acpi/amldb.8 I've just found the time to give them a quick once over, and I'd have no problem with them going in as they are. There are some grammar changes, and possibly terminology changes that might be appropriate, but I haven't got the time to enumerate them all at the moment, and I'm sure the wider community can make suggestions as time goes on. Sheldon can probably render an opinion on their usage of the macros. N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: netscape
Hi, I have installed netscape4-navigator and I can't launch its. I've got following message: ld.so failed: Can't find shared library "libXt.so.6.0" What can I do? Piotr Wozniak You need to install the XFree86 a.out library package. It's in the packages directory from the 4.1-RELEASE.. I bet there's something there for -current as well. - Dave Rivers - -- [EMAIL PROTECTED] Work: (919) 676-0847 Get your mainframe (370) `C' compiler at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: docs on how to upgraded boot loader ...
Ah, okay, for some reason I was looking at the 'disklabel -B' stuff, but
that never worked :( I've gotten into the habit of doing the whole
'buildkernel/buildworld/etc' procedure, and just hadn['t gotten to the
point doing the 'installworld' :(
thanks ...
On Thu, 7 Sep 2000, Warner Losh
wrote:
In message [EMAIL PROTECTED] The Hermit Hacker
writes:
: How do I upgrade it 'with the new kernel', as the UPDATING file
: suggests? I've looked at the man pages for loader, and it doesn't suggest
: anything ... help?
cd /usr/src
make buildworld
make buildkernel
make installkernel
cd sys
make install
cd ..
Optionally reboot in single user mode
cd /usr/src
make installworld
Or if you like taking chances, and with the fixes I just committed:
# assume that /usr/obj exists from prior run
cd /usr/src/lib/libstand
make depend make all # add install here w/o my fixes
cd ../../sys
make depend make all install
cd i386/conf
config FOO
cd ../../compile/FOO
make depend make all install
reboot
But we've had enough changes in sys recently that you'll need new
libkvm utilities, so you might as well do the first series of
commands.
Warner
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: Oddities with the new binutils
Repost of old mail now that I've made my ISP register their mail relays (which took three months for them to understand!). I know this is ancient but being in the archives may help someone. It was a kernel problem. I made a new kernel from sources of about 8 hours ago and the problem has dissappeared from my home machine (have to wait until after the long weekend [- in Oz] to test the work machine). It seems that something in the May 29th kernel was causing problems for X. Matthew Thyer wrote: It may not be FP itself. In fact I have seen some other strange graphic corruption at home when running xplanet in the background and xanim. When the planet turns, the top 20 or so rows of the root window get corrupted with some of the image of the currently playing animation in xanim. I haven't mentioned this yet because I've only been running xplanet since post-binutils so I cant compare it with previous behaviour. It would appear to be an Xserver problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/usr/local/etc/rc.d and /etc/rc.d
[I know this was discussed a couple of months ago but since nothings
been committed yet I throw in my 3 month old email that I haven't
been able to send due to my stupid ISP with unregistered mail relays]
Please read as I have done a fair bit of thinking on this matter as
the sysadmin of many commercial UNIX systems (SunOS, Solaris, IRIX,
HP-UX, True64) plus FreeBSD and Linux (we'll just call it UNIX even
though that's debatable). [NOTE I'm 750 behind on my cvs-all mail so
dont hassle me as I haven't read this thread yet but feel the need to
respond before we end up with some wierd non backward compatible
system that's totally different from common UNIX systems].
I would like to see startup and shutdown scripts exist in a single
directory ("/usr/local/etc/rc.d/" for ports and eventually
"/etc/rc.d" when the system migrates to the same scheme).
The startup and shutdown functionality would be in the same script
and the scripts should be named starting with a capital 'S' for
startup and a capital 'K' for shutdown (I'm also keen on the HPUX
startmsg and stopmsg one liners).
There's no need for the seperate SYSV init.d directory as scripts
will be off if they dont start with the right naming convention.
As for runlevels... thats not BSD and I dont know any SYSV admin
who uses them (I dont count the RedHat hack to turn on X).
The scripts will be differentiated from existing scripts (the old
system) as the new system will only act on scripts that have a digit
in the second character of their name (there could be a backward
compatability process to act on all the others afterwards which
would be disabled by default... presumably "disabled.S99rc.compat"
or some such name).
Stop scripts will be a symbolic link to their startup script
counterpart (and would simply not be executed if the K* file doesn't
exist). Symbolic links make it clear they are the same script.
Scripts would be executed in alphabetical order (after the S or K)
so the sysadmin has control over the execution order which is
important.
Scripts would source common functions from a system file so we have
control over future changes in functionality/reporting. This would
also make the template script very simple.
Eventually I would like the system to migrate to such a scheme but
maintain the backward compatibility scripts /etc/netstart which
could be implemented either by simply 'knowing' which rc scripts
do network functionality or by reserving a range of numbers for
network startup --- HACK!
I'd really like the system to allow stuff like "/etc/rc.d/S84named
reread" (or "restart", "reload" whatever is acceptable).
I'd also really like at least named and perl to be removed from the
base system but that's another thread.
One of the big turn offs to FreeBSD in the System V world is:
"What!, why do I need to know which signal to send blah to reload
it ?".
The backward compatibilty hack script in "/usr/local/etc/rc.d/"
would ignore files starting with "README" and "disabled" (and
maybe other typical disabling naming methods).
This is not too much of a hack as the backward compatibility
script would go away in a release or two.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local/etc/rc.d and /etc/rc.d
On Fri 2000-09-08 (22:53), Matthew Thyer wrote:
I would like to see startup and shutdown scripts exist in a single
directory ("/usr/local/etc/rc.d/" for ports and eventually
"/etc/rc.d" when the system migrates to the same scheme).
I don't think we should move away from the 'base' system and 'extra'
stuff differentiation. Any script that can support /etc/rc.d can
probably support /usr/local/etc/rc.d, /usr/X11R6/etc/rc.d, and others
based on a variable in /etc/rc.conf.
The startup and shutdown functionality would be in the same script
and the scripts should be named starting with a capital 'S' for
startup and a capital 'K' for shutdown (I'm also keen on the HPUX
startmsg and stopmsg one liners).
Why not just use chmod +x or chmod -x, like we do already? This means
not having to rename things.
The scripts will be differentiated from existing scripts (the old
system) as the new system will only act on scripts that have a digit
in the second character of their name (there could be a backward
compatability process to act on all the others afterwards which
would be disabled by default... presumably "disabled.S99rc.compat"
or some such name).
I prefer chmod +x and chmod -x.
Stop scripts will be a symbolic link to their startup script
counterpart (and would simply not be executed if the K* file doesn't
exist). Symbolic links make it clear they are the same script.
I don't see the point.
Scripts would be executed in alphabetical order (after the S or K)
so the sysadmin has control over the execution order which is
important.
I'd prefer a dependency based system. (cf. Eivind Eklund's newrc, at
http://people.FreeBSD.org/~eivind/newrc.tar.gz)
Scripts would source common functions from a system file so we have
control over future changes in functionality/reporting. This would
also make the template script very simple.
I imagine that's the way to do it.
Eventually I would like the system to migrate to such a scheme but
maintain the backward compatibility scripts /etc/netstart which
could be implemented either by simply 'knowing' which rc scripts
do network functionality or by reserving a range of numbers for
network startup --- HACK!
This is why you want dependencies.
I'd really like the system to allow stuff like "/etc/rc.d/S84named
reread" (or "restart", "reload" whatever is acceptable).
That's a natural extension to the current method, yes. We should be
sure to fail on something we don't understand, and not (like we may do
now) run the default start script.
I'd also really like at least named and perl to be removed from the
base system but that's another thread.
I'll comment when you bring it up. Warning: perl is necessary for
kernel builds.
One of the big turn offs to FreeBSD in the System V world is:
"What!, why do I need to know which signal to send blah to reload
it ?".
I agree. We need a simpler system. Simple, and obvious. None of this
complex symlink stuff.
Neil
--
Neil Blakey-Milner
Sunesi Clinical Systems
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Please consider some cosmetic changes in boot messages
Anyone else noticed how FreeBSD is inconsistent with the use of words like "Doing", "setting" and "starting" in the boot messages ? For instance, I think the following fragment of my boot should change from: Additional routing options: tcp extensions=NO TCP keepalive=YES. routing daemons:. Mounting NFS file systems. additional daemons: syslogd. checking for core dump...savecore: no core dump Doing additional network setup: portmap. Starting final network daemons: mountd nfsd rpc.statd nfsiod NFS access cache ti me=2. setting ELF ldconfig path: /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib setting a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout starting standard daemons: inetd cron usbd. Initial rc.i386 initialization: apm apmd. rc.i386 configuring syscons: font8x16 font8x14 font8x8 blank_time allscreens. additional ABI support:. Local package initialization: fkeys SETI@home xfstt. Additional TCP options:. To: (I've put * against the changed lines) Additional routing options: tcp extensions=NO TCP keepalive=YES. routing daemons:. Mounting NFS file systems. additional daemons: syslogd. checking for core dump...savecore: no core dump * additional network setup: portmap. * final network daemons: mountd nfsd rpc.statd nfsiod NFS access cache time=2. * ELF ldconfig path: /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib * a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout * standard daemons: inetd cron usbd. * rc.i386 initialization: apm apmd. rc.i386 configuring syscons: font8x16 font8x14 font8x8 blank_time allscreens. additional ABI support:. Local package initialization: fkeys SETI@home xfstt. Additional TCP options:. And finally, for filesystems with = 10^6 blocks free, the fsck -p output (second line) hits exactly 80 chars which makes syscons leave a blank line before the next line of output. Call me pedantic but could we change the word "fragmentation" to "fragmented" to give room for many more blocks in the filesystem before wrapping. I'm sure the answer is no due to histerical raisins but its worth a try ;) /dev/ad0s2e: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s2e: clean, 5929804 free (2252 frags, 740944 blocks, 0.0% fragmentation) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local/etc/rc.d and /etc/rc.d
Replying to my own message. In summary, the main things the scheme I describe gives us are: - control over startup/shutdown order with the numbers - accomodates older scripts (by just not having the K script linked to the S, script things wont be started again at shutdown time). - enough similarity to SYSV to not confuse - ability to easily disable scripts (rename to not start with S[0-9] or K[0-9]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: call for testers: init securelevel patch
"BE" == Bruce Evans [EMAIL PROTECTED] writes: BE revision 1.9 BE date: 1997/06/25 07:31:47; author: joerg; state: Exp; lines: +2 -2 BE Don't ever allow lowering the securelevel at all. Allowing it does BE nothing good except of opening a can of (potential or real) security BE holes. People maintaining a machine with higher security requirements BE need to be on the console anyway, so there's no point in not forcing BE them to reboot before starting maintenance. That last sentence makes me think that the person who decided this does not use a network to update that machine, ie NFS mounting /usr/src. It is a royal PITA to get networking up and going after a single-user reboot to get out of secure level. Perhaps one of the secure level restrictions should be that you cannot attach to pid 1 via the debugger. Does the kernel have an idea of single user mode or is that purely a user space thing? Perhaps the kernel could drop the restrictions when in single user mode itself. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG MIME spoken herehttp://www.khera.org/~vivek/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please consider some cosmetic changes in boot messages
On Fri, 08 Sep 2000 23:07:22 +0930, Matthew Thyer wrote: Anyone else noticed how FreeBSD is inconsistent with the use of words like "Doing", "setting" and "starting" in the boot messages ? Yes, but I wouldn't worry about it at this stage. I have a plan to revamp the way that the startup process's output is presented and stored for later viewing. I need to chat to some folks first about the best way to do this, first. Be patient, and look forward to something interesting in 5.0-RELEASE. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: microuptime() went backwards / SHMSEG
Steve Ames wrote: Just upgraded to -CURRENT as of about noon (EST) today. At reboot I got a lot of these: microuptime() went backwards (1.7682417 - 1.997434) I recall reading in -current earlier this week that someone was looking for victims getting this. What further information can I provide? -Steve If it is of any relevance, I got hundreds of these messages from 4.0-RELEASE, on my Athlon 1Ghz, Abit KA7-100 system. So many, in fact, that every time it happened, I was left with no choice but to reboot, as it slowly brought the system to its knees. Building the kernel without apm fixed the problem, and I have since had no problems. -- "I'm entirely unaccountable for any moments of sanity contained herein." :s/Windows/UNIX John Toon | [EMAIL PROTECTED] | "Sonnilon" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local/etc/rc.d and /etc/rc.d
Neil Blakey-Milner wrote: On Fri 2000-09-08 (22:53), Matthew Thyer wrote: The startup and shutdown functionality would be in the same script and the scripts should be named starting with a capital 'S' for startup and a capital 'K' for shutdown (I'm also keen on the HPUX startmsg and stopmsg one liners). Why not just use chmod +x or chmod -x, like we do already? This means not having to rename things. You could do either with my scheme. Stop scripts will be a symbolic link to their startup script counterpart (and would simply not be executed if the K* file doesn't exist). Symbolic links make it clear they are the same script. I don't see the point. The point is that people are worried about scripts that aren't aware of the "start" and "stop" argument trying to start apps again at shutdown time. With my scheme, the script wont be executed at shutdown time if the K* script doesn't exist. Scripts would be executed in alphabetical order (after the S or K) so the sysadmin has control over the execution order which is important. I'd prefer a dependency based system. (cf. Eivind Eklund's newrc, at http://people.FreeBSD.org/~eivind/newrc.tar.gz) I haven't looked at this yet but off the top of my head, a dependency based system sounds overly complicated (consider ports authors) and unecessarily different from other systems. I'd also really like at least named and perl to be removed from the base system but that's another thread. I'll comment when you bring it up. Warning: perl is necessary for kernel builds. I know but I'm pretty keen on awk and would like all the perl dependencies to be re-written with awk or other tools as I dislike FreeBSD being dependent on such a beast as perl which should only exist as a port. Just look at the pain of getting perl 5.6.0 into the system. I know the perl lovers will hate me but I thinks its worth having some ugly awk to get away from elegant perl being required in the base system. I'd go further to say that the whole base OS needs to be more modularised ala Solaris and Linux especially since we dont have an established binary patch process. Its pretty hard to sell FreeBSD to my work masters when the only patch method is source code patches or a complete rebuild of -STABLE or just wait until the next release. A more modular system could be upgraded more easily. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] Matthew Thyer who needs a new .sig To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local/etc/rc.d and /etc/rc.d
On Sat 2000-09-09 (00:05), Matthew Thyer wrote: Stop scripts will be a symbolic link to their startup script counterpart (and would simply not be executed if the K* file doesn't exist). Symbolic links make it clear they are the same script. I don't see the point. The point is that people are worried about scripts that aren't aware of the "start" and "stop" argument trying to start apps again at shutdown time. With my scheme, the script wont be executed at shutdown time if the K* script doesn't exist. If it's there, it gets executed. If it's there, it was put there. If it was put there, it'll have support for "start" and "stop". If an administrator puts a script in there that does the wrong thing, that's his fault. He could use the fall-back rc.local method. We needn't support stupid behaviour by complicating the matter. Scripts would be executed in alphabetical order (after the S or K) so the sysadmin has control over the execution order which is important. I'd prefer a dependency based system. (cf. Eivind Eklund's newrc, at http://people.FreeBSD.org/~eivind/newrc.tar.gz) I haven't looked at this yet but off the top of my head, a dependency based system sounds overly complicated (consider ports authors) and unecessarily different from other systems. I am considering port authors, and I think that dependency-based systems will be _much_ better for them. Thanks for bringing it up. # before zope # before apache # after networking # after nfs is much better than: S10.networking.sh S20.nfs.sh S40.zope.sh S45.apache.sh and then figuring to use S43.foo.sh. I'd also really like at least named and perl to be removed from the base system but that's another thread. I'll comment when you bring it up. Warning: perl is necessary for kernel builds. I know but I'm pretty keen on awk and would like all the perl dependencies to be re-written with awk or other tools as I dislike FreeBSD being dependent on such a beast as perl which should only exist as a port. Just look at the pain of getting perl 5.6.0 into the system. I know the perl lovers will hate me but I thinks its worth having some ugly awk to get away from elegant perl being required in the base system. I'm not particularly attached to perl, but it has a convenience in some sections, like ports, that is unmatched by sed and awk. Note the excessive use of "perl -i -pe 's/foo/bar/'" for in-place substitution. I've asked on at least two occasions for a simple, easy-to-use, thing to do it without doing a two-liner that copies to another file, and then replaces the old file with the new file. I'd go further to say that the whole base OS needs to be more modularised ala Solaris and Linux especially since we dont have an established binary patch process. Its pretty hard to sell FreeBSD to my work masters when the only patch method is source code patches or a complete rebuild of -STABLE or just wait until the next release. A more modular system could be upgraded more easily. I agree. I'd suggest you check out the freebsd-libh mailing list, and ask there about how to check out the libh sources. Your contributions to the libh project will aid development of the next-generation package management and installer. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local/etc/rc.d and /etc/rc.d
Neil Blakey-Milner wrote: On Sat 2000-09-09 (00:05), Matthew Thyer wrote: The point is that people are worried about scripts that aren't aware of the "start" and "stop" argument trying to start apps again at shutdown time. With my scheme, the script wont be executed at shutdown time if the K* script doesn't exist. If it's there, it gets executed. If it's there, it was put there. If it was put there, it'll have support for "start" and "stop". If an administrator puts a script in there that does the wrong thing, that's his fault. He could use the fall-back rc.local method. We needn't support stupid behaviour by complicating the matter. I'm behind on cvs-all and freebsd-current so forgive me but I'm basing my comments on rc.shutdown executing /usr/local/etc/rc.d/* with argument "stop". Which seems very dangerous given that people may not have rebuilt their ports for a long time. With my way the old scripts may not even be run until the admin reads up on the new scheme. # before zope # before apache # after networking # after nfs is much better than: S10.networking.sh S20.nfs.sh S40.zope.sh S45.apache.sh and then figuring to use S43.foo.sh. We'll have to disagree on this point. Given that we've had no order control in the past and that ports are generally (yes its bad to generalise) not dependent on each other, should the situation arise I think that any admin worth his/her pay can work out how to change the order with the numbers. Remember that I'm trying to stay remotely compatible with other systems. We dont have to re-invent the wheel. I still think a dependency based system is way more complicated than what is required. I'm not particularly attached to perl, but it has a convenience in some sections, like ports, that is unmatched by sed and awk. Note the excessive use of "perl -i -pe 's/foo/bar/'" for in-place substitution. I've asked on at least two occasions for a simple, easy-to-use, thing to do it without doing a two-liner that copies to another file, and then replaces the old file with the new file. My point is that its worth some ugly awk and sed to get away from the base OS depending on perl. I dont care how elegant perl is. Thats about all I'll say on this thread got to sleep. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: call for testers: init securelevel patch
On Fri, 8 Sep 2000, Vivek Khera wrote: "BE" == Bruce Evans [EMAIL PROTECTED] writes: BE revision 1.9 BE holes. People maintaining a machine with higher security requirements BE need to be on the console anyway, so there's no point in not forcing BE them to reboot before starting maintenance. That last sentence makes me think that the person who decided this does not use a network to update that machine, ie NFS mounting /usr/src. It is a royal PITA to get networking up and going after a single-user reboot to get out of secure level. He would probably say that using nfs is inconsistent with being secure. If you only use nfs for updating the machine, then the PITA for securing it then may be larger than the PITA for starting networking. Perhaps one of the secure level restrictions should be that you cannot attach to pid 1 via the debugger. This was implemented at about the same time as rev.1.9. Does the kernel have an idea of single user mode or is that purely a user space thing? Perhaps the kernel could drop the restrictions when in single user mode itself. It's almost pure user space. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: call for testers: init securelevel patch
On Fri, 8 Sep 2000, Vivek Khera wrote: "BE" == Bruce Evans [EMAIL PROTECTED] writes: BE revision 1.9 BE date: 1997/06/25 07:31:47; author: joerg; state: Exp; lines: +2 -2 BE Don't ever allow lowering the securelevel at all. Allowing it does BE nothing good except of opening a can of (potential or real) security BE holes. People maintaining a machine with higher security requirements BE need to be on the console anyway, so there's no point in not forcing BE them to reboot before starting maintenance. Perhaps one of the secure level restrictions should be that you cannot attach to pid 1 via the debugger. You can't. Ever since Apr 1997 you couldn't attach gdb to init. -Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: netscape
I have installed netscape4-navigator and I can't launch its.
I've got following message:
ld.so failed: Can't find shared library "libXt.so.6.0"
Assuming you have the a.out libraries installed as per the
other messages, you probably need to assign the LD_LIBRARY_PATH
in the "which netscape" file to be your LD_LIBRARY_AOUT_PATH
(I believe that is the correct name for it).
assign LD_LIBRARY_PATH=${LD_LIBRARY_AOUT_PATH}
since the native netscape doesn't bother to read any library path
but the "standard" one, which of course points to ELF libraries,
and not a.out ones...
Bruce
--
---
Bruce Burden[EMAIL PROTECTED] Tandem Computers Inc.
512-432-8944Network Verification 14231 Tandem Blvd.
Auto answer(4 rings) Austin, TX 78726
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: netscape
On 08-Sep-00 Bruce Burden wrote: since the native netscape doesn't bother to read any library path but the "standard" one, which of course points to ELF libraries, and not a.out ones... You're supposed to use ldconfig -aout for that.. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SMPng CPU states
I've built world and kernel yesterday, and was delighted to see the AIC7xxx problems had gone away. I actually got tripped up by having Linux emulation enabled and forgetting to remove old modules, but that was fixed quick. All-in-all, I'm not having a rough time at all with the new code. My machine has been up for 7.5 hours now without a hiccup. I DID notice that I can't load X without a hang, which I think is the same AGP problem someone else mentioned. The only other thing I've noticed is top telling me that the CPU is steady at 50.0% system and 50.0% idle. The box is completely quiescent, except for me ssh'd in and running top. vmstat says sy=50 and id=50 as well. If I start a CPU-chewing process (sh -c 'while true; do true; done') the resultant CPU usage in %user seems to come from %system. -- Brandon Hume- hume - BOFH.Halifax.NS.Ca, http://WWW.BOFH.Halifax.NS.Ca/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local/etc/rc.d and /etc/rc.d
On Sep 9, 12:05am, Matthew Thyer wrote: } Subject: Re: /usr/local/etc/rc.d and /etc/rc.d } Neil Blakey-Milner wrote: } I'd prefer a dependency based system. (cf. Eivind Eklund's newrc, at } http://people.FreeBSD.org/~eivind/newrc.tar.gz) How does this compare with what NetBSD implemented? } I haven't looked at this yet but off the top of my head, a dependency } based system sounds overly complicated (consider ports authors) and } unecessarily different from other systems. NetBSD switched to a dependency based system a while back. Judging by the traffic on their mail lists, it was somewhat controversial ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local/etc/rc.d and /etc/rc.d
On Fri 2000-09-08 (11:12), Don Lewis wrote: On Sep 9, 12:05am, Matthew Thyer wrote: } Subject: Re: /usr/local/etc/rc.d and /etc/rc.d } Neil Blakey-Milner wrote: } I'd prefer a dependency based system. (cf. Eivind Eklund's newrc, at } http://people.FreeBSD.org/~eivind/newrc.tar.gz) How does this compare with what NetBSD implemented? } I haven't looked at this yet but off the top of my head, a dependency } based system sounds overly complicated (consider ports authors) and } unecessarily different from other systems. NetBSD switched to a dependency based system a while back. Judging by the traffic on their mail lists, it was somewhat controversial ... Eivind's system is almost exactly the same. I wonder if they used it as a base. (they also seem to use etc/default from March this year) Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMPng CPU states
Brandon Hume wrote: I've built world and kernel yesterday, and was delighted to see the AIC7xxx problems had gone away. I actually got tripped up by having Linux emulation enabled and forgetting to remove old modules, but that was fixed quick. All-in-all, I'm not having a rough time at all with the new code. My machine has been up for 7.5 hours now without a hiccup. I DID notice that I can't load X without a hang, which I think is the same AGP problem someone else mentioned. The only other thing I've noticed is top telling me that the CPU is steady at 50.0% system and 50.0% idle. The box is completely quiescent, except for me ssh'd in and running top. vmstat says sy=50 and id=50 as well. If I start a CPU-chewing process (sh -c 'while true; do true; done') the resultant CPU usage in %user seems to come from %system. Process accounting is somewhat broken. The actual runtime of each process (p_runtime, or TIME in top) is accurate, but many of the other statistics are broken at the moment since statclock() no longer has a proper stackframe to work with. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New ATA tagged queuing patch available
On Fri, 8 Sep 2000, Soren Schmidt wrote: If I dont get any serious problem reports I'll commit this shortly, making FreeBSD the first OS that has tagged Queuing support for ATA drives :) Wow, even before Windows? :-) -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures. ( http://www.freebsd.org ) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: microuptime() went backwards
Sep 7 14:35:55 laptop /kernel: microuptime() went backwards (10412.355980 - 10412, -694583121)y this is bad.. right ? :-) Well, at any rate it looks very funny. If this is a laptop, try building a kernel without apm and see if that helps. It only helps "hide" the problem. There's either *extremely* bogus data coming in, or an arithmetic or sequencing error that's allowing a corrupt timecounter to be seen. It might help to see the negative number as hex... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world broken
looks like the boot loader is killing -current. I have a patch, but it just cuts all the offending references. Comments? rebuild/reinstall libstand. Sorry; should have HEADS-UPped that one. Warner cc -nostdlib -static -Ttext 0x0 -o loader.sym /usr/obj/home/imp/FreeBSD/src/sys/boot/i386/loader/../btx/lib/crt0.o main.o conf.o bcache.o boot.o commands.o console.o devopen.o interp.o interp_backslash.o interp_parse.o load_aout.o load_elf.o ls.o misc.o module.o panic.o isapnp.o pnp.o interp_forth.o vers.o /usr/obj/home/imp/FreeBSD/src/sys/boot/i386/loader/../../ficl/libficl.a /usr/obj/home/imp/FreeBSD/src/sys/boot/i386/loader/../libi386/libi386.a -lstand /usr/obj/home/imp/FreeBSD/src/sys/boot/i386/loader/../libi386/libi386.a(pxe.o): In function `pxe_enable': pxe.o(.text+0x552): undefined reference to `nfs_root_node' *** Error code 1 Stop in /home/imp/FreeBSD/src/sys/boot/i386/loader. *** Error code 1 Stop in /home/imp/FreeBSD/src/sys/boot/i386. *** Error code 1 ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Dirty buffers on reboot..
Ok, an update on the dirty buffers on reboot: If you use the reboot command, you will get dirty buffers. If you use 'shutdown -r now' instead, you won't get dirty buffers. Thus, as a workaround for now, use the shutdown command to reboot your box until we can track this down. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: microuptime() went backwards
In message [EMAIL PROTECTED], Mike Smith writes: Sep 7 14:35:55 laptop /kernel: microuptime() went backwards (10412.355980 - 10412, -694583121)y this is bad.. right ? :-) Well, at any rate it looks very funny. If this is a laptop, try building a kernel without apm and see if that helps. It only helps "hide" the problem. There's either *extremely* bogus data coming in, or an arithmetic or sequencing error that's allowing a corrupt timecounter to be seen. It might help to see the negative number as hex... I have collected all the emails I've received and I have identified at least two different causes: There is a bogus i8254 implementation on certain Athlon Mobos, this is a non-brainer since they should not use the i8254 but the TSC. There are negative numbers coming in from both the i8254 and in a few cases from the TSC. NTIMECOUNTER may be too low for certain systems, I'm still waiting for some feedback on that. Either way, I have a patch which I need to burn in in my lab, but right now I have a hard time getting my SMP box to even print out "Copyright..." when it boots :-( -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Installed SMP patch and now mouse doesn't work?
On Wed, 6 Sep 2000, John Baldwin wrote: The Hermit Hacker wrote: Have nothing else to go on yet ... I updated both the current source code and installed the SMP patch from Sept 5th. Everything installed great, rebooted and I can work in character mode ... go to X, and the mouse gives me no activity, where it did just before the upgrade ... Am still investigating at this end, but if anyone else has experience similar and knows how to fix? Uh, all of the SMPng boxes so far haven't had mice. :P Is your mouse a serial mouse? There seem to be some problems with input on the sio devices. This is because the schedsofttty() call is commented out so the high-level interrupt routine in sio is never entered. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8348 3944 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: microuptime() went backwards
I have collected all the emails I've received and I have identified at least two different causes: There is a bogus i8254 implementation on certain Athlon Mobos, this is a non-brainer since they should not use the i8254 but the TSC. s/TSC/ACPI timer/ It might even work on those systems. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: microuptime() went backwards
Could all this be in any way related to the statclock not working on certain systems (like my Dell Inspiron)?? Also, could the "rtc" device as listed in systat -vm not being there (I'm assuming this is the statclock) be causing scheduling anomalies? I ask because I am trying to get gaim (multi-threaded, and using gtk which is threaded as well) to work on my laptop. It works on my desktop (-CURRENT), and on my friend's desktop (-STABLE) but not on my laptop (-STABLE). Just wondering... Thanks. = | Kenneth Culver | FreeBSD: The best NT upgrade| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Fri, 8 Sep 2000, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Mike Smith writes: Sep 7 14:35:55 laptop /kernel: microuptime() went backwards (10412.355980 - 10412, -694583121)y this is bad.. right ? :-) Well, at any rate it looks very funny. If this is a laptop, try building a kernel without apm and see if that helps. It only helps "hide" the problem. There's either *extremely* bogus data coming in, or an arithmetic or sequencing error that's allowing a corrupt timecounter to be seen. It might help to see the negative number as hex... I have collected all the emails I've received and I have identified at least two different causes: There is a bogus i8254 implementation on certain Athlon Mobos, this is a non-brainer since they should not use the i8254 but the TSC. There are negative numbers coming in from both the i8254 and in a few cases from the TSC. NTIMECOUNTER may be too low for certain systems, I'm still waiting for some feedback on that. Either way, I have a patch which I need to burn in in my lab, but right now I have a hard time getting my SMP box to even print out "Copyright..." when it boots :-( -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: microuptime() went backwards
On Thu, 7 Sep 2000, John Baldwin wrote: Most definitely an SMPng issue. If you take a SMP machine and compile a UP and an SMP kernel on it, the SMP kernel will boot fine, whereas the UP kernel will generate these warnings. John, not quite, I have an SMP box that I got these warnings on, spent the better part of the day trying to reproduce them (after the machine became unresponsive last night) the machine is a N440BX Night (Intel) motherboard, with two PII 333's. the board has everything onboard except the disks. the only change besides building an SMPng kernel was to take out COMPAT_OLDPCI. If I can find out more for you I will, however I'm leaving for vacation at 7:30 AM tomorrow morning. -Trish __ Trish Lynch FreeBSD - The Power to Serve[EMAIL PROTECTED] Rush Networking [EMAIL PROTECTED] VA Linux Systems[EMAIL PROTECTED] O|S|D|N [EMAIL PROTECTED] --- Q: Have you guys ever been on Sesame Street as special guests? A (from Geddy): No. Much to the dismay of my daughter. Q: Would you be on Sesame Street if you were asked? A (again from Geddy): G: Yes. How could you turn Sesame Street down? That borders on criminal. -Geddy Lee From Rush, on Rockline. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mouse works!!
serial mouse works with currrent sources ... thanks guys
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: /usr/local/etc/rc.d and /etc/rc.d
On Fri, Sep 08, 2000 at 04:47:15PM +0200, Neil Blakey-Milner wrote: Note the excessive use of "perl -i -pe 's/foo/bar/'" for in-place substitution. I've asked on at least two occasions for a simple, easy-to-use, thing to do it without doing a two-liner that copies to another file, and then replaces the old file with the new file. If it weren't for perl, we'd probably already have `sed -i' :-) -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr
Seigo Tanimura wrote: I have been suffering from this problem for almost 2 months. When I remove a pcmcia ethernet card from my laptop PC, routed(8) announces updated routing information by multicast, leading to a kernel panic. Ejecting an interface configured up will do that. ifconfig the interface `down' and then `delete' before ejecting it. Interfaces in promiscuous mode will always result in a reboot. I *usually* get away with ejecting an active card if it's not in promiscuous mode. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New ATA tagged queuing patch available
On Friday, 8 September 2000 at 13:48:37 -0500, Chris Dillon wrote: On Fri, 8 Sep 2000, Soren Schmidt wrote: If I dont get any serious problem reports I'll commit this shortly, making FreeBSD the first OS that has tagged Queuing support for ATA drives :) Wow, even before Windows? :-) He did say "OS". 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: SMPng CPU states
On Friday, 8 September 2000 at 14:17:58 -0300, Brandon Hume wrote: I've built world and kernel yesterday, and was delighted to see the AIC7xxx problems had gone away. I actually got tripped up by having Linux emulation enabled and forgetting to remove old modules, but that was fixed quick. All-in-all, I'm not having a rough time at all with the new code. My machine has been up for 7.5 hours now without a hiccup. I DID notice that I can't load X without a hang, which I think is the same AGP problem someone else mentioned. FWIW, I've had no trouble running X on my development box. Well, the monitor can only do 640x480, but that's not an OS issue. 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: /usr/local/etc/rc.d and /etc/rc.d
Don Lewis wrote: On Sep 9, 12:05am, Matthew Thyer wrote: } Subject: Re: /usr/local/etc/rc.d and /etc/rc.d } Neil Blakey-Milner wrote: } I'd prefer a dependency based system. (cf. Eivind Eklund's newrc, at } http://people.FreeBSD.org/~eivind/newrc.tar.gz) How does this compare with what NetBSD implemented? } I haven't looked at this yet but off the top of my head, a dependency } based system sounds overly complicated (consider ports authors) and } unecessarily different from other systems. NetBSD switched to a dependency based system a while back. Judging by the traffic on their mail lists, it was somewhat controversial ... I'd consider it overly complicated because: - The OS vendor can work out the correct order for system component startup and set the numbers right once per release so who needs the overhead and complexity of a dependency based system ? - The ports collection is so huge these days that we need to make it easier rather than harder for non-hardcore FreeBSD users to submit and maintain their own ports. Its already hard enough to do a port right especially if it should have ifdefs on the version of FreeBSD to work correctly in -STABLE and -CURRENT. Port authors really need -CURRENT and -STABLE installed and maintain a copy of the repository to DTRT. - The SysV style number based system is fine in that port authors can all use the same number (say S50myport) unless it needs to be changed due to the unlikely need for ordering (remember we haven't had ordering to date and there are ~3700 ports). - Dont think of /usr/local/etc/rc.d being just for the ports collection, people will put there own startup scripts there too and will find it very easy to just pick the right numbers ala SysV. I do admin SysV systems of all types (mainly Solaris, HPUX, IRIX, True64 - yes I work for Defence) as my paid job so I know how easy the number order system is to use. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dirty buffers on reboot..
Ok, an update on the dirty buffers on reboot:
If you use the reboot command, you will get dirty buffers. If you use
'shutdown -r now' instead, you won't get dirty buffers. Thus, as a workaround
for now, use the shutdown command to reboot your box until we can track this
down.
I suggest using some method to allow interrupt threads to run during
the shutdown. Perhaps the current process priority should be elevated
so it is guaranteed to be scheduled after the last interrupt thread
instead of some unrelated process.
Index: kern_shutdown.c
===
RCS file: /home/ncvs/src/sys/kern/kern_shutdown.c,v
retrieving revision 1.80
diff -u -r1.80 kern_shutdown.c
--- kern_shutdown.c 2000/09/07 01:32:51 1.80
+++ kern_shutdown.c 2000/09/09 01:42:20
@@ -220,6 +220,7 @@
if (!cold (howto RB_NOSYNC) == 0 waittime 0) {
register struct buf *bp;
int iter, nbusy;
+ int subiter;
waittime = 0;
printf("\nsyncing disks... ");
@@ -247,7 +248,18 @@
break;
printf("%d ", nbusy);
sync(proc0, NULL);
- DELAY(5 * iter);
+
+ if (curproc != NULL) {
+ for (subiter = 0; subiter 50 * iter; subiter++) {
+ mtx_enter(sched_lock, MTX_SPIN);
+ setrunqueue(curproc);
+ mi_switch(); /* Allow interrupt threads to run */
+ mtx_exit(sched_lock, MTX_SPIN);
+ DELAY(1000);
+ }
+ } else
+ DELAY(5 * iter);
+
}
printf("\n");
/*
- Tor Egge
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local/etc/rc.d and /etc/rc.d
On Sat 2000-09-09 (11:25), Matthew Thyer wrote:
Don Lewis wrote:
On Sep 9, 12:05am, Matthew Thyer wrote:
} Subject: Re: /usr/local/etc/rc.d and /etc/rc.d
} Neil Blakey-Milner wrote:
} I'd prefer a dependency based system. (cf. Eivind Eklund's newrc, at
} http://people.FreeBSD.org/~eivind/newrc.tar.gz)
How does this compare with what NetBSD implemented?
} I haven't looked at this yet but off the top of my head, a dependency
} based system sounds overly complicated (consider ports authors) and
} unecessarily different from other systems.
NetBSD switched to a dependency based system a while back. Judging by
the traffic on their mail lists, it was somewhat controversial ...
I'd consider it overly complicated because:
- The OS vendor can work out the correct order for system component
startup and set the numbers right once per release so who needs
the overhead and complexity of a dependency based system ?
We don't work with machines "once per release". Keeping those numbered
files in CVS will also suck if we rearrange things.
You're making an assumption that there is overhead and complexity in a
dependency-based system. The NetBSD one seems incredibly no-nonsense
and direct - the core of /etc/rc is:
files=`rcorder -s nostart /etc/rc.d/*`
for i in $files; do
run_rc_script $i start
done
Here's a simple dependency example:
/
#!/bin/sh
#
# $NetBSD: timed,v 1.2 2000/03/13 04:04:10 lukem Exp $
#
# PROVIDE: timed
# REQUIRE: DAEMON
. /etc/rc.subr
name="timed"
command="/usr/sbin/${name}"
load_rc_config $name
run_rc_command "$1"
\
Or a more complex on:
/
#!/bin/sh
#
# $NetBSD: postfix,v 1.3 2000/04/30 12:21:00 lukem Exp $
#
# PROVIDE: mail
# REQUIRE: LOGIN
# we could do this, but make mail start late, so that things like
# .forward's are not processed until the system is fully operational
## REQUIRE: DAEMON
. /etc/rc.subr
name="postfix"
required_files="/etc/${name}/main.cf"
extra_commands="reload"
start_precmd="checkyesno postfix"
start_cmd="postfix start"
stop_precmd=$start_precmd
stop_cmd="postfix stop"
reload_precmd=$start_precmd
reload_cmd="postfix reload"
load_rc_config $name
run_rc_command "$1"
\
This is really easy to understand and document, and the few people of
all levels of proficiency I've just asked think this is cool.
- The ports collection is so huge these days that we need to make it
easier rather than harder for non-hardcore FreeBSD users to
submit and maintain their own ports. Its already hard enough to
do a port right especially if it should have ifdefs on the version
of FreeBSD to work correctly in -STABLE and -CURRENT. Port authors
really need -CURRENT and -STABLE installed and maintain a copy of the
repository to DTRT.
Most of the ports submitters I know personally only have -RELEASE
machines. They seem to do fine.
I don't see how the SysV way is any easier than the dependency-based
system. The dependency-based system means you can set it up, and then
leave it alone and never worry about renumbering.
- The SysV style number based system is fine in that port authors can
all use the same number (say S50myport) unless it needs to be changed
due to the unlikely need for ordering (remember we haven't had
ordering
to date and there are ~3700 ports).
This applies equally to a dependency-based system. Most will use the
PORTS requirement, I imagine, which'd be equivalent to the current
system, and which we could tweak from a central place if needs be,
without changing every single port.
- Dont think of /usr/local/etc/rc.d being just for the ports collection,
people will put there own startup scripts there too and will find it
very easy to just pick the right numbers ala SysV.
Only to have the vendor re-number things in the next release, and spoil
their carefully-located numbers? Dependencies are a big win here too.
All in all I'm delighted with the NetBSD dependency-based system that
has been pointed out to me. It'd be great to synchronise with their
system, and share and help develop their code (which, from casual
inspection, is great, and looks like it may never need changes).
It kinda makes me wonder what I'll do when I see that RedHat machine at
work. (:
Neil
--
Neil Blakey-Milner
Sunesi Clinical Systems
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
