Re: DP2 iso crash on boot
On Tue, Nov 19, 2002 at 01:21:56PM -0500, Matt Haught wrote: With the DP2 iso (from ftp5), I get a crash on boot right after the acpi module is loaded. The error is (manually copied) and occured 5 out of 5 times that I tried: I recently worked on loading 5.0 onto a dual Xeon which panic'd in a similar way. You might be able to avoid the problem by stopping the loader before it boots the kernel, and issuing: unset ACPI_LOAD at the loader prompt. Then issue the boot command manually. That may get you going. If so, you should be able to add the following to your /boot/loader.conf file: exec=unset ACPI_LOAD Good luck! -Brian -- Brian Dean [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory overwrite problem in the -current kernel ??
On Tue, Apr 23, 2002 at 01:54:17PM +0200, Poul-Henning Kamp wrote: This commit detects a memory overwrite problem in the kernel which happens before we ever get into userland for the first time. Do you know the address being corrupted? If so, try breaking into ddb early on and set a hardware watchpoint. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rc.diskless2 fails to create /var/log/lastlog
On Wed, Oct 17, 2001 at 04:07:28PM +0200, Harti Brandt wrote: Hi, /var/log/lastlog is not in /etc/newsyslog.conf and is for this reason no created upon boot. This gives an error message each time one logs into the system. The append patch creates the file. Committed. Thanks! -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
On Sat, Apr 21, 2001 at 05:34:31PM +0200, Sheldon Hearn wrote: So we have two problems: 1) Calling cp(1) repetitively is inefficient. 2) The argument list is too big for cp(1). Extending cp(1) will not solve (2). Extending xargs(1) will solve both. So why is an extension to cp(1) being proposed? But extending cp does solve the problem. The proposal was to make % cp -d target src1 src2 ... srcN Be equivalent to; % cp src1 src2 ... srcN target This makes cp work with xargs; % cat ReallyBigListOfFiles | xargs cp -d target -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
On Fri, Apr 20, 2001 at 07:26:18PM -0700, Rodney W. Grimes wrote: (cat bigfilelist; echo destdir) | xargs cp I like this version of the patch!! It's much much cleaner than hacking up cp or xargs, it even follows the unix principle of using simple tools and glueing them togeather to do bigger jobs, is unix implementation independent, and is very clear in what it does. It's clean, simple, and unfortunately, totally bogus. Try: echo 1 2 3 4 5 6 7 8 9 | xargs -n 4 echo Now consider what would happen with the above suggested construct with a very long file list. I don't see a problem with adding an option to cp to treat the first argument as the target instead of the last argument. It's a simple solution, the code change is simple, and it produces the exact desired result. What's the problem? -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Failed using CD-ROM as root filesystem
On Mon, Apr 16, 2001 at 01:27:24PM +0900, Makoto MATSUSHITA wrote: I've tried to use (bootable) CD-ROM as root filesystem (I want have this because it's good alternative of fixit.flp), but it seems that GENERIC kernel doesn't understand where is root filesystem. What I did are: [ procedure deleted ] It seems that something goes wrong in setrootbyname(). Any clues? P.S.: I've also tried with 4-stable kernel, and it goes pretty well. I've been doing something similar with the latest code in -stable and have got it working very well. My purposes are varied, but I'm mainly experimenting with setting up a cd-rom based firewall device using a more traditional layout as opposed to the picobsd methods. -Brian -- Brian Dean [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.diskless{1,2} files
On Mon, Apr 02, 2001 at 09:28:29AM -0700, Matt Dillon wrote: Oops. That was broken allright. It's definitely correct to copy the files in reverse order so the network files override the defaults, and the per-host files override the network files. -Matt Cool, I'll commit a fix shortly. Thanks, -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.diskless{1,2} files
On Fri, Mar 30, 2001 at 02:53:25PM -0800, Matt Dillon wrote:
P.S. To anyone who wants to cleanup the rc.diskless files,
please be my guest! I wrote them originally and they worked
'ok', but then some people mangled them and ever since they
haven't worked right. I don't have time to clean them up
myself. They could use a complete rewriting, IMHO.
-Matt
I've used these to set up a NFS root area for a bunch of servers, but
each server has a local disk where I put /var, swap, and a /local
mount point for things that need to be accessed a lot. I found
rc.diskless1 was fine, but I needed to hack up rc.diskless2 pretty
thoroughly for my own situation. It provided a good template, though :)
However, there was one area that I thought you did kind've backwards.
That was the sucking in of the /etc files. I'm referring to the
following in rc.diskless1 where you check for host-specific files,
followed by network, then a default config:
if [ -d /conf/${bootp_ipa} ] ; then
cp -Rp /conf/${bootp_ipa}/etc/* /conf/etc
elif [ -d /conf/${bootp_ipbca} ] ; then
cp -Rp /conf/${bootp_ipbca}/etc/* /conf/etc
else
cp -Rp /conf/default/etc/* /conf/etc
fi
I've found that one can reduce a lot of common file duplication by
reversing that logic, going after "default" first, then
"network-specific", finally followed by "host-specific" files:
if [ -d /conf/default/etc/ ]; then
cp -Rp /conf/default/etc/* /conf/etc
fi
if [ -d /conf/${bootp_ipbca} ] ; then
cp -Rp /conf/${bootp_ipbca}/etc/* /conf/etc
fi
if [ -d /conf/${bootp_ipa} ] ; then
cp -Rp /conf/${bootp_ipa}/etc/* /conf/etc
fi
The idea of this being that most /etc files go into "default", and
only overrides go into the "network" and "host-specific" directories.
Would folks support and agree to a change like this?
-Brian
--
Brian Dean
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sun, Dec 10, 2000 at 10:13:42AM -0600, Mike Meyer wrote: Whether or not it's part of FreeBSD is immaterial. It's part of the distribution that comes from FreeBSD, and is treated differentlyh from locally installed software (whether written locally or by a third party) in every case *except* where it installs - and that's only because it's installed in the wrong place. In other words, "It's not part of FreeBSD" is a rationalization. You are really reaching here. Contributed software that the FreeBSD Project has chosen to integrate, i.e., Perl, Sendmail, just to name a few, are integrated tightly and installed in /usr/bin, etc, not in /usr/local. Ports, on the other hand are installed in /usr/local or /usr/X11R6. You seem to mis-understand that a FreeBSD port is basically a set of patches and a source fetching mechanism that is included with FreeBSD as a convenience for building and installing third party software. The actual software that gets built and installed is _not_ part of FreeBSD. This is not a rationalization. I for one would be really upset if when I installed a Port, it's binaries started getting dropped into /bin, /usr/bin, etc. I suspect many others would too. I'm really not exactly sure what you are complaining about. For example, the last time I built Emacs for Solaris (several years ago admittedly), by default it installed itself into /usr/local. If you install Emacs onto FreeBSD, it goes into /usr/local. The behaviour is the same. Are you proposing that since FreeBSD provides a set of patches so that Emacs builds cleanly, that it should therefore install it somewhere other than /usr/local? -Brian -- Brian Dean [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Package installation location
On Sun, Dec 10, 2000 at 01:02:09PM -0600, Mike Meyer wrote: The problem is that *it doesn't work*. Well, not very well. Part of it is that it's only given lip service: the porters handbook says "make your ports PREFIX clean"; portlint doesn't do any checking about it. The porters handbook doesn't even provide instructions on how to test for whether or not a port is PREFIX clean. Making things LOCALBASE clean isn't even suggested. Just to nitpick this one statement, PREFIX is set to LOCALBASE (see /usr/ports/Mk/bsd.port.mk) so if PREFIX is honoured by the port, then LOCALBASE will be honoured by default. Not doing it this way would not allow you to override PREFIX for one particular port. Thus if you set LOCALBASE to /usr/opt in /etc/make.conf for instance, but for port "foo" you want it to go somewhere else, you can build that with make PREFIX=/usr/local/foo, for instance. If foo honoured LOCALBASE instead, it would ignore your one-time PREFIX override. Thus PREFIX is the correct thing for the ports to worry about, not LOCALBASE, LOCALBASE just being the default value for PREFIX. -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
On Sun, Dec 10, 2000 at 11:42:38AM -0600, Mike Meyer wrote: Ports, on the other hand are installed in /usr/local or /usr/X11R6. What happend to "that's what PREFIX is for"? I was speaking about the default behaviour. If you want the port to go somewhere other than /usr/local, PREFIX or LOCALBASE is available to change that. You should be able to set this in /etc/make.conf to change the site behaviour. I think I finally understand what you are complaining about, and that is that PREFIX is not honoured by all ports. If that is your argument, then yes, obviously that should be fixed if possible. But to say that installing ports into /usr/local is somehow wrong, I have to disagree. This is a site dependent decision, which can be overridden through the use of PREFIX or LOCALBASE. If the override mechanism is broken for a port, then it should be fixed. If you wish to change the default from /usr/local to something else, then you need to present good arguments for doing so, and if your arguments are good enough and directed to the right people, it will happen. [/me scurries off in shame to fix my broken port to honour PREFIX.] -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
really strange problem - extracting X turns my system off, literally
Hi, I'm bewildered and looking for clues ... I'm running -current, cvsup'd and rebuild world as of yesterday: FreeBSD stage.bsdhome.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun Nov 12 18:30:15 EST 2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 I went to install X from Ports and during extraction, my system just turned itself off! Not reboot, mind you, it powered down. I use a serial console so I would be able to tell if any messages printed out just before that final event, but there's nothing. Nothing in /var/log/messages either. Here are the last few messages of the X install via ports: [root@stage]:/XFree86- make install === Extracting for XFree86-3.3.6_4 Checksum OK for xc/X336src-1.tgz. Checksum OK for xc/X336src-2.tgz. Checksum OK for xc/fix-01-r128. Checksum OK for xc/fix-04-s3trio3d2x. Checksum OK for xc/fix-05-s3trio3d. Checksum OK for xc/fix-06-s3trio3d2x. Checksum OK for xc/fix-07-s3trio64v2gx+netfinity. Checksum OK for xc/fix-08-s3savage_ix+mx. [extract for a minute or two, then powerdown] So, I rebuild my world, reboot and try again ... it powered down at the exact same spot! Any ideas? Note that this machine has successfully been completing buildworld/kernel installkernel/world's for the last several months. Thanks, -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Cleanout rebuild of /dev on -current
On Wed, Oct 18, 2000 at 09:50:52PM -0700, John W. De Boskey wrote: So, what would the correct sequence be to wipeout /dev and recreate it? (create /dev in an alternate location and compare the two...??) After mergemastering, and if /dev/MAKEDEV gets updated, I usually just do an 'sh MAKEDEV all', then use 'ls -lt' which will list all the old and non-standard devices at the bottom of the listing for easy identification. Then I selectively MAKEDEV the ones I still need, i.e., you may then need to selectly MAKEDEV devices such as da4 and higher, vn0, ccd0, etc if you use those. I think Doug mentioned that it won't re-create your disk slices. I always do that manually for the disk where the root filesystem is located. With a little scripting, all of this could be automated. -Brian -- Brian Dean [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Review requested for i386 debug register helper functions
On Thu, 24 Aug 2000, Brian Dean wrote: If you have the time, I would very much appreciate any reviews on a couple of helper functions that I've put together for manipulating the i386 debug registers: http://people.freebsd.org/~bsd/i386watch/ Just a note to reviewers, I've simplified the i386_set_watch() function a bit as of Aug 25 @ 5:15 PDT. -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Review requested for i386 debug register helper functions
Hi, If you have the time, I would very much appreciate any reviews on a couple of helper functions that I've put together for manipulating the i386 debug registers: http://people.freebsd.org/~bsd/i386watch/ I've had these in my toolkit for a long time and present them here, slightly modified. They are intended to keep folks from re-inventing the wheel. I've had at least two people ask for these to be committed. My main concern is their location in the tree. I've got them under src/lib/libc/i386/sys, and manual section 2. They are not quite system calls, but this seemed to be the best fit location for these. I'm open to other suggestions as well. Thanks, Brian -- Brian Dean [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DHCP does not honor default router?
On Tue, 4 Jul 2000, Doug Barton wrote:
I updated my dhclient script to handle this case, since it
happens on the roadrunner network as well. I can send you the patch
if you want, but I have a lot of other hacks in my script so it
might be confusing. Starting right around line 106 of the default
script, I have:
A hook is already provided for this kind of thing. You can create a
separate program called /etc/dhclient-exit-hooks, which get run at
various times by dhclient-script. Since /etc/dhclient-exit-hooks is
sourced by /sbin/dhclient-script, you have access to all of its
internal variables, such as '$reason', '$old_ip_address',
'$new_ip_address', etc.
Thus, you don't have to maintain a separate /sbin/dhclient-script like
you do now.
Also, if you run a firewall, you should re-instantiate your rules with
the new IP address here as well. Mine (which is still evolving) looks
something like this:
#!/bin/sh
#
# File: /etc/dhclient-exit-hooks
#
# redirect to syslog
logger="/usr/bin/logger -t dhclient-exit-hooks -i"
checkit ( ) {
/bin/echo "REASON=$reason OLDIP=$old_ip_address NEWIP=$new_ip_address"
if [ -z "$old_ip_address" ] || [ -z "$new_ip_address" ]; then
/bin/echo "old and/or new is empty"
elif [ "$old_ip_address" != "$new_ip_address" ]; then
/bin/echo "flushing ARP tables"
/usr/sbin/arp -d -a
/bin/echo "re-establishing firewall rules"
. /etc/rc.firewall.local
fi
}
checkit | $logger
I notice you also flush the routing table. Is that necessary - it
appears that dhclient-script does this when it's needed?
I found this exit hook feature by looking at the source for
dhclient-script, but, oddly enough, it is even documented in the man
page.
-Brian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: FW: GDB 5.0 is released!
On Fri, 26 May 2000, David O'Brien wrote: GDB 5.0 is released! Do you have any forecasts as to when we will see this baby in the -current? Its priority is behind GCC 2.96 I haven't had a chance to examine this yet ... do you know if it includes support for our new hardware debug register support on IA32? -Brian -- Brian Dean [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Mon, 24 Apr 2000, David O'Brien wrote: I've often traced files back to the begining of FreeBSD time (and then continued in the CSRG SCCS tree). ^^ I've wanted to do this on occasion. Where are these pre-FreeBSD history records available? -Brian -- Brian Dean [EMAIL PROTECTED] SAS Institute Inc. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Vinum breakage (was: 2nd call for reviews and tests: buf-bio patch)
Greg Lehey wrote: Technical explanation: A buffer header gets corrupted between the time the top half of the driver issues the request to the disk driver, and when the I/O completes. Currently, the evidence is pointing towards the disk driver, but the corruption is of such an unusual nature that it's difficult to guess what's going on. This type of bug sounds like a perfect candidate for using the kernel's hardware debug support (on IA32), and would allow you to take a trace trap and drop to the kernel debugger when anyone modifies the buffer header, assuming you can cover the corrupted area with the 4 debug registers available, which can cover a range of 16 bytes, in 4 byte chunks. This is exactly the type of situation that inspired me to add the support in the first place. Hopefully, when I get a little bit of time, I can merge the code that I use so that we can do this in a straight forward way from within the kernel debugger. -Brian -- Brian Dean [EMAIL PROTECTED] SAS Institute Inc. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Load average calculation?
Donn Miller wrote: Patrick Mau wrote: On all Unix-like systems I know, the load average is the average mumber of processes running during a given time interval. I can't see what use it may have to count load for _waiting_ processes. I/O load is not process load, if a process waits for I/O completion it does not use up its timeslice. I think we ought to re-examine the definition of load average. By load, we mean an actual load on the cpu, and waiting processes aren't really exerting a cpu load. So, by that reasoning I say waiting processes don't count. In this case, the "waiting" refers to the processes waiting in the _run_ queue, i.e., if the system wasn't so busy, they'd be running more often instead of waiting. In a uniprocessor system, only one process can be running at a time. When that currently running process is swapped away from the cpu, another process from the run queue is selected to run (which is actually an array of queues, lower indexes meaning higher priority). Load average is the average number of processes that are runnable, i.e., sitting in the run queue, over a certain period of time, usually computed for the most recent 1 minute, 5 minute, and 15 minute intervals. I think you guys are mixing up I/O wait with the run queue. The processes are indeed waiting, but they are waiting for a chance to get the CPU, not for someone to press a key on the keyboard or some other external event, without which, the process could not correctly continue until that event occurs. There is a _huge_ difference between the two. And yes, it is a pretty good, simple indicator of system load, and that is all it is really meant to be. If you need something fancier, or more specific to a particular load type, you'd need to roll your own using the abundant statistics that the kernel keeps and makes available. -Brian -- Brian Dean [EMAIL PROTECTED] SAS Institute Inc. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Odd problem with ppp0 in -current
Just to follow up - this has been tracked down and fixed. The recent delayed checksum code was not compatible with IPDIVERT. Thanks for the fix, Jonathan! -Brian Brian Dean wrote: The symptoms are that I cannot telnet out though my ppp0 interface. Ktrace indicates that the connect() to the remote system never returns (it may eventually timeout - I didn't wait a really long time). However, I run natd and have several other boxes here that I _can_ use to establish a connection with a remote system, via my ppp0 interface (my gateway) . Very odd indeed. Does this ring a bell with anyone as far as what recent commit (last few days) might have resulted in such behaviour? [...] For reference, this is with last night's cvs update, and kernel with IPFIREWALL, IPDIVERT, and natd. I use 'pppd' and 'ppp0'. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Odd problem with ppp0 in -current
Hi, I'm trying to track down the change that broke my ppp. The symptoms are that I cannot telnet out though my ppp0 interface. Ktrace indicates that the connect() to the remote system never returns (it may eventually timeout - I didn't wait a really long time). However, I run natd and have several other boxes here that I _can_ use to establish a connection with a remote system, via my ppp0 interface (my gateway) . Very odd indeed. Does this ring a bell with anyone as far as what recent commit (last few days) might have resulted in such behaviour? My previous kernel of about a week ago is fine. Telnet works fine through my xl0 interface to my local machines. It's just my ppp0 interface that has this problem. Looking through the commit messages, I didn't see anything that jumped out as being the culprit. Any ideas? Is anyone else seeing this? For reference, this is with last night's cvs update, and kernel with IPFIREWALL, IPDIVERT, and natd. I use 'pppd' and 'ppp0'. Thanks, -Brian -- Brian Dean [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMI MegaRAID lockup? not accepting commands.
Mike Smith wrote: Just recently (this evening), I was able to get our controller to lock up with the latest patch. Previously, with that patch installed, I must not have been able to tickle the bug just right, and I believe that Mike based his decision to make that mod based on my lack of a lockup, which always happened quickly. That's what made me think that we'd solved it, but I guess I just got "lucky" on the previous lockups that happened very quickly, making me think it was more easily reproduceable that it actually is. I'm not entirely sure about that; I think there are probably several sets of problems here. Can you be more specific about "locking up" though? The "controller wedged" bug is almost certainly not the same as the "lost interrupt" bug. Here's a snippet of the messages from my syslog file: [...] Mar 24 12:35:19 cvsstage /kernel: amr0: controller wedged (not taking commands) Mar 24 12:35:19 cvsstage /kernel: amr0: I/O error - dead Mar 24 12:35:19 cvsstage /kernel: amr0: cmd 2 ident 17 drive 0 Mar 24 12:35:19 cvsstage /kernel: amr0: blkcount 12 lba 129695792 Mar 24 12:35:19 cvsstage /kernel: amr0: virtaddr 0xd1a5d000 length 6144 Mar 24 12:35:19 cvsstage /kernel: amr0: physaddr 7800 nsg 2 Mar 24 12:35:19 cvsstage /kernel: amr0: 1a11e000/4096 Mar 24 12:35:19 cvsstage /kernel: amr0: 1993f000/2048 Mar 24 12:35:19 cvsstage /kernel: amr0: controller wedged (not taking commands) Mar 24 12:35:19 cvsstage /kernel: amr0: I/O error - dead Mar 24 12:35:19 cvsstage /kernel: amr0: cmd 2 ident 17 drive 0 Mar 24 12:35:19 cvsstage /kernel: amr0: blkcount 12 lba 129826864 Mar 24 12:35:19 cvsstage /kernel: amr0: virtaddr 0xd1a4d000 length 6144 Mar 24 12:35:19 cvsstage /kernel: amr0: physaddr 7800 nsg 2 Mar 24 12:35:19 cvsstage /kernel: amr0: 71ce000/4096 Mar 24 12:35:19 cvsstage /kernel: amr0: 402f000/2048 Mar 24 12:35:19 cvsstage /kernel: amr0: controller wedged (not taking commands) Mar 24 12:35:19 cvsstage /kernel: amr0: I/O error - dead Mar 24 12:35:19 cvsstage /kernel: amr0: cmd 2 ident 17 drive 0 Mar 24 12:35:19 cvsstage /kernel: amr0: blkcount 12 lba 129630256 Mar 24 12:35:19 cvsstage /kernel: amr0: virtaddr 0xd1a3d000 length 6144 Mar 24 12:35:19 cvsstage /kernel: amr0: physaddr 7800 nsg 2 Mar 24 12:35:19 cvsstage /kernel: amr0: 1befe000/4096 Mar 24 12:35:19 cvsstage /kernel: amr0: 1869f000/2048 [...] In a separate lock up, there are no messages to syslog, but all accesses to the card are hung. A ps shows my 26 bonnie processes are in either in 'wswbuf0' or 'biord' (going from memory here, I may not have the exact state text correct). This is the one I believe we are calling the "lost interrupt" bug. I'm running a patched 3/13 on this machine which I can't readily do a full cvs update on it. I believe that 3/13 was before Poul made his B_READ changes, so I did not incorporate Poul's 1.8 revision for amr.c (because I assume it would be incorrect to do so without getting all of his changes throughout the rest of the kernel). However, I did get all of your changes at 1.9. I also incorporated Markus' patch, with the exception that I set maxio to 253 instead of 127 or 254 like the card reports (thinking possibly that there was an off by one issue, i.e., 254 available, 0-253). It is this kernel that produced the messages above. Just for sanity's sake, I'll try Markus' maxio of 127 and verify whether or not my 26 simultaneous bonnie processes can finish without locking it up. I agree that we are probably chasing more than one problem. Also, I don't necessarily think you should back out the "volatile" change; even though it did not fix this problem, I think it should still be there. It sounds like Markus may be onto something. I'm somewhat corralled here today, but I might get some time to apply his suggestions on Monday, especially if you're happy it works for you as well. What we're thinking about doing here is that if scaling back the number of outstanding io requests hides/avoids the problem, then we may do that here as a temporary fix, especially if we can still get good performance. We have the need to get this machine into production soon. Ultimately, I'd like to get another card that we can play with and experiment with a bit more so that we can diagnose the real cause, and then be able to run the card a full steam. I am still able to work on this, though, at least for a few days. One area I thought about spending some time was where you maintain whether the card has interrupts enabled or not and based on this info, you issue commands with the expectation of getting an interrupt back or use polled mode. The next thing I was going to check was to review that part of the code thinking maybe that the software state might possibly have gotten out of sync with reality at some point. Also, I'm open to other suggestions if you think there's a more productive area I should spend time on. Thanks for your help on
Re: AMI MegaRAID lockup? not accepting commands.
Mike Smith wrote: I've played around changing the spinloop to using DELAY (like the Linux model), but this didn't prevent the controller from either "just" locking up or crashing the whole machine with it. Changing various other places in a similar manner (like replacing the bcopy() in amr_quartz_get_work() with similar code as in the linux driver to wait for 0xFF to clear) didn't do the trick either. Can you try instead the changes that I just committed to -current? I think that the problem shows up when the controller is heavily loaded; your patch will keep the load on the controller down, which may mask the 'real' bug. Just recently (this evening), I was able to get our controller to lock up with the latest patch. Previously, with that patch installed, I must not have been able to tickle the bug just right, and I believe that Mike based his decision to make that mod based on my lack of a lockup, which always happened quickly. That's what made me think that we'd solved it, but I guess I just got "lucky" on the previous lockups that happened very quickly, making me think it was more easily reproduceable that it actually is. It sounds like Markus may be onto something. -Brian -- Brian Dean [EMAIL PROTECTED] SAS Institute Inc. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Streamlining FreeBSD Installations
Daniel C. Sobral wrote: Brian Dean wrote: Forrest Aldrich wrote: Someone mentioned that sysinstall could be scripted... is this the way to go, then? I use scripted sysinstalls here. It's really easy, however, you still have to interact with a few dialogs, namely: 1) of course, you have to specify your config file from the "Load Config" main menu option Huh? AFAIK, sysinstall accept script commands from the command line, so this could be skipped. I was referring to the use of sysinstall for the initial installation of the OS. I don't see how you can do what you say unless you create a custom boot floppy (or CD) for _each_ machine you want to install. And since we are talking on the order of 100 machines here, I don't think that is practical. Perhaps you could get by with one boot image if your machines were configured via DHCP (mine are not, and in my case, it is not practical to do so, at least not right now). And just so I'm not misinterpretted, I'm not complaining about having to specify the config file. It's not that big of a deal. In fact, I think Jordan has made it just about as simple as it can reasonably get. I was just pointing out that it's not _entirely_ hands off, and merely listed that interaction with sysinstall for the sake of completeness. For the remaining four, we can probably code appropriately via the scripting mechanism to avoid the prompts: 1) dhcp yes/no 2) crypto yes/no/which ones 3) ports yes/no 4) are you sure you want to really do this? yes/no -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Streamlining FreeBSD Installations
Forrest Aldrich wrote: Someone mentioned that sysinstall could be scripted... is this the way to go, then? I use scripted sysinstalls here. It's really easy, however, you still have to interact with a few dialogs, namely: 1) of course, you have to specify your config file from the "Load Config" main menu option 2) you need to say whether or not you want to use DHCP 3) you need to interact with the crypto questions 4) you need to say whether or not you want to install the ports I think it would be worthwhile to modify sysinstall to so that you only have to do #1 above, but I haven't found it so painful to interact with the remaining three to submit patches to Jordan yet. Eventually, I will probably do this, unless someone else beats me to it. Everything else can be automated. Here's a sample config file that I put together: # scratchy.cfg # # FreeBSD Installation Config file for scratchy.unx.sas.com # # This file generated on 03/17/00 09:36:00 # debug=yes ipaddr=10.26.1.74 hostname=scratchy.unx.sas.com domainname=unx.sas.com defaultrouter=10.26.0.1 netmask=255.255.0.0 # - End of generated information - netDev=fxp0 ftp=ftp://freebsd2.unx.sas.com/pub/FreeBSD _ftpPath=ftp://freebsd2.unx.sas.com/pub/FreeBSD nameserver=10.16.149.6 mediaSetFTP distSetEverything dists=local X9set distUnsetCustom disk=ad0 partition=exclusive diskPartitionEditor # 128 Meg /root partition ad0s1-1=ufs 262144 / # 256 Meg swap partition ad0s1-2=swap 524288 none # 1 Gig /tmp partition ad0s1-3=ufs 2097152 /tmp # 256 Meg /var partition ad0s1-4=ufs 524288 /var # all remaining space for /usr partition ad0s1-5=ufs 0 /usr diskLabelEditor installCommit # pkg dir = /nfs/freebsd/pub/FreeBSD/packages/All package=bash-2.03 noError=TRUE packageAdd package=elm-2.4ME+68 noError=TRUE packageAdd package=emacs-20.6 noError=TRUE packageAdd package=hexedit-1.1.0 noError=TRUE packageAdd package=less-352 noError=TRUE packageAdd package=linux_base-6.1 noError=TRUE packageAdd package=lsof-4.48 noError=TRUE packageAdd package=mm-1.0.12 noError=TRUE packageAdd package=netscape-communicator-4.72 noError=TRUE packageAdd package=pdksh-5.2.14 noError=TRUE packageAdd package=procmail-3.14 noError=TRUE packageAdd package=rdate-1.0 noError=TRUE packageAdd package=sudo-1.6.2p1 noError=TRUE packageAdd package=tcsh-6.09.00 noError=TRUE packageAdd package=tkcvs-6.0 noError=TRUE packageAdd package=tkdiff-3.04 noError=TRUE packageAdd package=unzip-5.40 noError=TRUE packageAdd package=xv-m17n-3.10a noError=TRUE packageAdd package=zip-2.3 noError=TRUE packageAdd This script uses a local snap machine that we keep current and build snaps nightly from which to do an FTP install. I've got a script that I use to generate these config files. Essentially, I just specify the machine name, and my config generatator figures out the IP address, default router, and netmask, that is required for configuring the ethernet interface. Everything below the line "# - End of generated information -" is the same for all hosts, only the stuff above that line is different for each host. So, I end up with a config file per host. -Brian -- Brian Dean [EMAIL PROTECTED] SAS Institute Inc. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make release failing in /usr/ports/www/w3m/work/w3m
Hi, I am building a release and am getting a failure during the doc phase due to a port problem, (/usr/ports/www/w3m to be exact). This port is built during make release, and it builds a program called 'mktable', which core dumps, causing the whole make release to fail: [...] cc -O -pipe -I/usr/local/include -I. -c indep.c cc -O -pipe -I/usr/local/include -I. -c regex.c cc -O -pipe -I/usr/local/include -I. -c textlist.c cc -O -pipe -I/usr/local/include -I. -c parsetag.c ar rv libindep.a Str.o indep.o regex.o textlist.o parsetag.o a - Str.o a - indep.o a - regex.o a - textlist.o a - parsetag.o ranlib libindep.a cc -O -pipe -I/usr/local/include -I. -o mktable mktable.o hash.o -L/usr/local/ lib -L. -lindep -lgc -lm -lncurses ./mktable 100 tagtable.tab tagtable.c Segmentation fault - core dumped *** Error code 139 Stop in /usr/ports/www/w3m/work/w3m. *** Error code 1 Stop in /usr/ports/www/w3m/work/w3m. *** Error code 1 Stop in /usr/ports/www/w3m. *** Error code 1 Stop in /usr/ports/www/w3m. *** Error code 1 Stop in /usr/ports/www/w3m. *** Error code 1 Stop in /usr/ports/www/w3m. *** Error code 1 Stop in /usr/ports/textproc/docproj. *** Error code 1 Stop in /usr/ports/textproc/docproj. *** Error code 1 Stop in /usr/ports/textproc/docproj. *** Error code 1 Stop in /usr/src/release. *** Error code 1 Stop in /usr/src/release. The core dump is optimization related, i.e., if I go in and manually build 'mktable' without optimization, it works. Is anyone else seeing this? Thanks, -Brian -- Brian Dean [EMAIL PROTECTED] SAS Institute Inc. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make world error.....
John Polstra wrote: I don't believe I've ever used any special options, and my make.conf file is "normal" except that it has "USA_RESIDENT=YES" in it. I know for certain that when I ran into this that I did not do anything other than a "make world" on a standard -current system, i.e., nothing special in make.conf or elsewhere, except that I too had USA_RESIDENT=YES in my environment. Since all my worlds worked fine afterwards, I suspect it is what Kris suggested originally which was that the perl script was perhaps running before the openssl/*.h files (or at least openssl/des.h) were installed, and was thus a sort of bootstrapping issue. But I must admint, I have not investigated it further. -Brian -- Brian Dean [EMAIL PROTECTED] SAS Institute Inc. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keyboard troubles
Ryan Thompson wrote: Thanks for the info. When I have another $500 burning a hole in my checkbook, I will probably order another keyboard, just so I have another one, if nothing else. :-) Why not just get a decent monitor/keyboard switch? Belkin makes a nice 4-port in the $200 range that makes your motherboard think there's a keyboard attached even if you are not currently switched onto the system. Just a thought ... and it's a lot cheaper than more convenient that swapping your $500 keyboards (which must be _really_ impressive BTW :). -Brian -- Brian Dean [EMAIL PROTECTED] SAS Institute Inc. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make world error.....
William Woods wrote: vm/vnode_pager.h - vm/vnode_pager.ph *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl/utils/h2ph. *** Error code 1 Ideas about what died and why? I got the same thing here. h2ph does not like /usr/include/des.h which is a symlink to /usr/include/openssl/des.h, complaining about "no such file or directory". I fixed mine by hacking h2ph in /usr/obj/usr/src/gnu/usr.bin/perl/utils/h2ph to ignore this, i.e., not return 1 in this case, then redo the installworld part only. I'm sure there is a better fix, but this allowed me to complete the installworld and get on with life. -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! IPC security (Re: cvs commit: src/sys/kern sysv_ipc.c(fwd))
Bruce Evans wrote:
It had rotted further since then (as half threatened in rev.1.9) to
passing the process pointer so that it can mess up p-p_acflag. This
results in the ASU flag always being set in p-p_acflag for root,
although no special privilege is required for root to operate on ipc
objects owned by root, and especially, no special privilege is required
to determine whether an operation is permitted. The ASU flag should
only be set if root privilege is used. Most callers of ipcperm() are
committed to doing the operation that they check for using ipcperm()
if ipcperm() succeeds, so rearrangement of ipcperm() to check for root
privilege last would fix most cases.
[...]
Now the code has rotted to having an almost unused variable and one
other style bug:
int error;
...
error = suser(p);
if (!error)
This should be written much like the check in rev.1.8:
if (suser(p) == 0)
I believe the following patch does what you are asking. Essentially,
it only calls suser() if it was about to return a permission error,
thus the ASU flag should only be set when superuser privileges are
actually used.
Let me know if this looks OK, and if Jordan approves, I'll commit it.
Thanks,
-Brian
--
Brian Dean [EMAIL PROTECTED]
SAS Institute Inc. [EMAIL PROTECTED]
Index: sysv_ipc.c
===
RCS file: /usr00/mirror/ncvs/src/sys/kern/sysv_ipc.c,v
retrieving revision 1.13
diff -u -r1.13 sysv_ipc.c
--- sysv_ipc.c 2000/02/29 22:58:59 1.13
+++ sysv_ipc.c 2000/03/02 14:39:41
@@ -51,16 +51,15 @@
int mode;
{
struct ucred *cred = p-p_ucred;
- int error;
- error = suser(p);
- if (!error)
- return (0);
-
/* Check for user match. */
if (cred-cr_uid != perm-cuid cred-cr_uid != perm-uid) {
- if (mode IPC_M)
- return (EPERM);
+if (mode IPC_M) {
+if (suser(p) == 0)
+return (0);
+else
+return (EPERM);
+}
/* Check for group match. */
mode = 3;
if (!groupmember(perm-gid, cred)
@@ -71,7 +70,14 @@
if (mode IPC_M)
return (0);
- return ((mode perm-mode) == mode ? 0 : EACCES);
+
+if ((mode perm-mode) == mode)
+return (0);
+
+if (suser(p) == 0)
+return (0);
+
+return EACCES;
}
#endif /* defined(SYSVSEM) || defined(SYSVSHM) || defined(SYSVMSG) */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys/i386/machdep.c breaks kernel build
Thanks for the fix - it has been committed.
-Brian
--
Brian Dean
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Seigo Tanimura wrote:
On Sun, 20 Feb 2000 23:48:01 -0500,
Ray Kohler [EMAIL PROTECTED] said:
Ray cc -c -march=pentium -O3 -pipe -fno-builtin -Wall -Wredundant-decls
Ray -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
Ray -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi
Ray -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include
Ray opt_global.h -elf -mpreferred-stack-boundary=2
Ray ../../i386/i386/machdep.c
Ray {standard input}: Assembler messages:
Ray {standard input}:2772: Error: operands given don't match any known
Ray 386 instruction
Ray *** Error code 1
Could you try the following patch(sent to bsd personally)? It prevents
movl between a debug register and memory.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: gcc code generation bug (optimisation related)
This was my mistake. Seigo Tanimura found the problem and sent me a patch which I committed as soon as I saw it. I had a bad contraint on the destination operand of an __asm inline that did not trigger when I built the kernel at the default optimization level, but does at other optimization levels. -Brian -- Brian Dean [EMAIL PROTECTED] [EMAIL PROTECTED] Maxim Sobolev wrote: Hi, When I'm trying to compile kernel from just cvsup'ed sources on system builded/installed last evening I have following error message. This problem could be solved by lowering optimisation to -O, but previously I have no problems with -O2 for kernels. cc -c -O2 -march=pentium -Wall -Wredundant-decls -Wnested-externs -Wstrict-proto types -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-exten sions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include op t_global.h -elf -mpreferred-stack-boundary=2 ../../i386/i386/machdep.c /tmp/ccfL2694.s: Assembler messages: /tmp/ccfL2694.s:3563: Error: operands given don't match any known 386 instruction *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
please commit this before -RELEASE
Hi,
Back in July, I added support in the kernel for hardware debug
registers on the ix86 platform which allows for hardware watchpoints,
etc. I just realized that these are not documented in the ptrace and
procfs man pages. It would be real nice to get this in the doc for
4.0-RELEASE so that the gdb folks (and other debugger writers) will
have easy access to the information they need to implement the
necessary support bits in their debugger(s).
I've also added a comment in machine/reg.h.
Could someone please commit this doc addition?
If you think it would be helpful, I will follow up this patch in a few
days with a standalone program that demonstrates the use of these
registers for setting up a watchpoint for a process. Maybe this could
go into /usr/share/examples or something. Does anyone have any
opinions on this or think it might be useful?
Thanks,
-Brian
--
Brian Dean [EMAIL PROTECTED]
Enterprise Server Technology
"If we knew what we were doing, it wouldn't be called
research." - A.Einstien
Here's the patch:
Index: share/man/man5/procfs.5
===
RCS file: /usr00/mirror/ncvs/src/share/man/man5/procfs.5,v
retrieving revision 1.12
diff -u -r1.12 procfs.5
--- share/man/man5/procfs.5 1999/08/28 00:20:49 1.12
+++ share/man/man5/procfs.5 2000/02/11 15:51:52
@@ -74,6 +74,13 @@
in which case that signal is delivered to the process
(see
.Xr sigaction 2 ).
+.It Pa dbregs
+The debug registers as defined by
+.Dv "struct dbregs"
+in
+.Pa machine/reg.h .
+.Pa dbregs
+is currently only implemented on the i386 architecture.
.It Pa etype
The type of the executable referenced by the
.Pa file
Index: libc/sys/ptrace.2
===
RCS file: /usr00/mirror/ncvs/src/lib/libc/sys/ptrace.2,v
retrieving revision 1.11
diff -u -r1.11 ptrace.2
--- libc/sys/ptrace.2 1999/08/28 00:02:30 1.11
+++ libc/sys/ptrace.2 2000/02/11 15:40:28
@@ -202,6 +202,23 @@
.Aq Pa machine/reg.h )
pointed to by
.Fa addr .
+.It Dv PT_GETDBREGS
+This request reads the traced process' debug registers into
+the
+.Dq Li "struct dbreg"
+(defined in
+.Aq Pa machine/reg.h )
+pointed to by
+.Fa addr .
+.It Dv PT_SETDBREGS
+This request is the converse of
+.Dv PT_GETDBREGS ;
+it loads the traced process' debug registers from the
+.Dq Li "struct dbreg"
+(defined in
+.Aq Pa machine/reg.h )
+pointed to by
+.Fa addr .
.El
.Sh RETURN VALUES
Some requests can cause
@@ -250,8 +267,10 @@
.Dv PT_GETREGS ,
.Dv PT_SETREGS ,
.Dv PT_GETFPREGS ,
+.Dv PT_SETFPREGS ,
+.Dv PT_GETDBREGS ,
or
-.Dv PT_SETFPREGS
+.Dv PT_SETDBREGS
was attempted on a process with no valid register set. (This is
normally true only of system processes.)
.El
Index: i386/include/reg.h
===
RCS file: /usr00/mirror/ncvs/src/sys/i386/include/reg.h,v
retrieving revision 1.21
diff -u -r1.21 reg.h
--- i386/include/reg.h 1999/12/29 04:33:07 1.21
+++ i386/include/reg.h 2000/02/11 15:42:34
@@ -118,6 +118,9 @@
unsigned char fpr_pad[64];
};
+/*
+ * Register set accessible via /proc/$pid/dbregs.
+ */
struct dbreg {
unsigned int dr0; /* debug address register 0 */
unsigned int dr1; /* debug address register 1 */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Printer fiascos.
This patch fixes the problem for me. Thanks!!!
-Brian
On Sun, Jan 30, 2000 at 02:42:39PM -0500, Brian Dean wrote:
For what its worth, I am able to reproduce this problem on my system.
Would you mind trying this patch before I send it to Jordan?
Index: lpt.c
===
RCS file: /home/ncvs/src/sys/dev/ppbus/lpt.c,v
retrieving revision 1.13
diff -u -r1.13 lpt.c
--- lpt.c 2000/01/25 22:23:47 1.13
+++ lpt.c 2000/02/02 23:10:36
@@ -865,12 +865,12 @@
/*
* No more data waiting for printer.
-* Wakeup is not done if write call was interrupted.
+* Wakeup is not done if write call was not interrupted.
*/
sc-sc_state = ~OBUSY;
if(!(sc-sc_state INTERRUPTED))
- wakeup((caddr_t)sc);
+ wakeup((caddr_t)lptdev);
lprintf(("w "));
return;
} else { /* check for error */
--
[EMAIL PROTECTED] / [EMAIL PROTECTED]
FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Printer fiascos.
For what its worth, I am able to reproduce this problem on my system. Simply submit something to lpr, wait for the printer light to blink, and pull the paper tray. The system hangs hard as described and does not return to normal until the paper tray is put back in. I haven't been able to make it do anything while the printer has the system hung, so I haven't been able to track it down, yet. However, I haven't had much time to spend on this problem, but thought I'd chime in a "me too" when I saw someone had the (apparently) same problem. I have an HP LaserJet 4 connected to the parallel port. I am running -current, and a buildworld as of about a week ago. -Brian -- Brian Dean [EMAIL PROTECTED] Here's my dmesg: 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 4.0-CURRENT #0: Sun Jan 23 09:10:33 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/VGER Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 300682757 Hz CPU: Pentium II/Xeon/Celeron (300.68-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 201326592 (196608K bytes) avail memory = 192131072 (187628K bytes) Preloaded elf kernel "kernel" at 0xc02f3000. Pentium Pro MTRR support enabled md0: Malloc disk npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ata-pci0: Intel PIIX4 ATA-33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 pci0: Intel 82371AB/EB (PIIX4) USB controller (vendor=0x8086, dev=0x7112) at 7.2 irq 11 chip1: Intel 82371AB Power management controller port 0x5000-0x500f at device 7.3 on pci0 vga-pci0: NVidia Riva128 graphics accelerator mem 0xe500-0xe5ff,0xe400-0xe4ff irq 10 at device 9.0 on pci0 xl0: 3Com 3c905-TX Fast Etherlink XL port 0xc400-0xc43f irq 5 at device 10.0 on pci0 xl0: Ethernet address: 00:60:08:17:67:f9 miibus0: MII bus on xl0 nsphy0: DP83840 10/100 media interface on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ahc0: Adaptec 2940 Ultra SCSI adapter port 0xc800-0xc8ff mem 0xe900-0xe9000fff irq 9 at device 11.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs pci0: unknown card (vendor=0x1102, dev=0x0002) at 12.0 irq 11 pci0: unknown card (vendor=0x1102, dev=0x7002) at 12.1 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 ata-isa0: already registered as ata0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 IP packet filtering initialized, divert enabled, rule-based forwarding disabled, unlimited logging Waiting 15 seconds for SCSI devices to settle acd0: BCD-40XH CD-ROM/VER 3.1 CDROM drive at ata0 as master acd0: 128KB buffer, PIO4 acd0: Reads: CD-R, CD-RW, CD-DA stream, packet acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked Mounting root from ufs:/dev/da0a da2 at ahc0 bus 0 target 2 lun 0 da2: SEAGATE ST32550N 0021 Fixed Direct Access SCSI-2 device da2: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da2: 2047MB (4194058 512 byte sectors: 255H 63S/T 261C) da1 at ahc0 bus 0 target 1 lun 0 da1: SEAGATE ST32550N 0019 Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da1: 2047MB (4194058 512 byte sectors: 255H 63S/T 261C) da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST32550N 0019 Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 2047MB (4194058 512 byte sectors: 255H 63S/T 261C) da4 at ahc0 bus 0 target 6 lun 0 da4: iomega jaz 1GB H.72 Removable Direct Access SCSI-2 device da4: 10.000MB/s transfers (10.000MHz, offset 15) da4: Attempt to query device size failed: NOT REA
Re: tip features (cdelay and ldelay)?
Hi,
(replying to myself)
Since no one seems to recall why these features were removed, and I
don't see any reference to them in the CVS log, would someone please
consider applying the included patch to re-enable them?
This patch also includes a fix I made to correct PR bin/15847 that I
opened. If you wish to submit these separately so that it makes
backing out easier, just edit out the stuff related to eofchars in
this included patch. I included a patch in the PR that fixes the core
dump and can be applied on its own.
Thanks,
-Brian
--
Brian Dean [EMAIL PROTECTED]
Brian Dean wrote:
Subject: tip features (cdelay and ldelay)?
To: [EMAIL PROTECTED]
Date: Sun, 2 Jan 2000 17:40:36 -0500 (EST)
I have a couple of really dumb devices that I use 'tip' to talk to.
One is a Motorola 6811 microcontroller and the other is an old EEPROM
burner. I find that 'tip' overflows these devices when I'm sending
Motorola s-record and Intel Hex formatted files.
It looks like tip's 'cdelay' and 'ldelay' features do just the trick.
However, they are disabled, surrounded by '#ifdef notdef' sequences.
Just to make sure, I re-enabled them locally, and re-implemented the
apparently lost 'nap()' function to make sure that these features work
for my application, and they do.
My question is: does anyone remember why these were disabled in the
first place? Is there an equivalent replacement feature that I can
use instead to pace the outgoing characters so that I don't overrun
dumb devices with no flow control?
Here's the patch:
--
Index: cmds.c
===
RCS file: /usr02/mirror/ncvs/src/usr.bin/tip/tip/cmds.c,v
retrieving revision 1.10
diff -u -r1.10 cmds.c
--- cmds.c 1999/08/28 01:06:32 1.10
+++ cmds.c 2000/01/04 15:04:31
@@ -48,6 +48,7 @@
#include err.h
#include libutil.h
#include stdio.h
+#include unistd.h
/*
* tip
@@ -513,7 +514,7 @@
out:
if (lastc != '\n' !boolean(value(RAWFTP)))
send('\r');
- for (pc = eofchars; *pc; pc++)
+ for (pc = eofchars; pc *pc; pc++)
send(*pc);
stop_t = time(0);
fclose(fd);
@@ -560,6 +561,24 @@
transmit(fd, "\04", line);
}
+
+static int
+nap ( int microsec )
+{
+int rc;
+
+rc = usleep ( microsec );
+if (rc != 0) {
+fprintf ( stderr,
+ "warning: ldelay or cdelay interrupted, "
+ "delay time cut short: %s\n",
+ strerror(errno) );
+}
+
+return 0;
+}
+
+
/*
* FTP - send single character
* wait for echo handle timeout
@@ -573,15 +592,11 @@
cc = c;
xpwrite(FD, cc, 1);
-#ifdef notdef
if (number(value(CDELAY)) 0 c != '\r')
nap(number(value(CDELAY)));
-#endif
if (!boolean(value(ECHOCHECK))) {
-#ifdef notdef
if (number(value(LDELAY)) 0 c == '\r')
nap(number(value(LDELAY)));
-#endif
return;
}
tryagain:
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: tip features (cdelay and ldelay)?
Bruce Evans wrote:
Date: Wed, 5 Jan 2000 02:54:50 +1100 (EST)
consider applying the included patch to re-enable them?
+static int
+nap ( int microsec )
+{
+int rc;
+
+rc = usleep ( microsec );
+if (rc != 0) {
+fprintf ( stderr,
+ "warning: ldelay or cdelay interrupted, "
+ "delay time cut short: %s\n",
+ strerror(errno) );
+}
+
+return 0;
+}
usleep() has a resolution of 2/HZ seconds (normally 20msec), so the above
gives very slow output (50-100 cps). Using a low baud rate (500-1000 bps)
give the same result. If you want a shorter delay/faster output, then
there is nothing better than a busy-wait loop for implementing nap().
Using a not so low baud rate (1200+ bps) may work better. Perhaps nap()
was dropped because it can't be implemented reasonably.
This explains why setting cdelay below a certain value seemed to have
no additional affect in my tests. I was suspicious of the microsecond
resolution, though I had not verified it by code examination. I did
implement nap() with nanosleep() and saw no difference in resolution
so it must be based on the same underlying facilities as usleep().
For my microcontroller (9600 baud), setting cdelay=0 and ldelay=70ms
while using 80 character per line S-Record files does the trick. Any
lower and it overflows my device and I don't get reliable data
transfer. However, I must use 'cdelay' for my EEPROM burner (fixed at
1200 baud) set set ldelay=0; I can only surmize that it does not
buffer much if at all while writing the data to the chip (50 ms burn
time per byte for the EEPROM chip I worked with last). Thus, for my
slow EEPROM burner, enforcing a 50ms delay per character vs no other
flow control means the difference between being able to use FreeBSD
and tip for burning my EEPROMs (which is very convenient) or having to
come up with some other alternative.
Perhaps re-enabling 'cdelay' and 'ldelay' but changing 'nap()' to accept
its argument in milliseconds so that it does not misrepresent itself
to badly would be more reasonable? For me this change makes the
difference between working acceptably well and not working at all.
Would you consider committing a patch to that effect? It would save
me from having to maintain local mods to my source tree, and it would
probably be useful to others as well. If not, please let me know what
changes you would consider taking and I'll do my best to get you
patches.
Here a modified patch which:
1) closes PR bin/15847
2) enables 'cdelay' and 'ldelay'
3) makes 'nap()' take milliseconds instead of microseconds
so that it does not misrepresent it's resolution too
badly
Thanks,
-Brian
--
Brian Dean [EMAIL PROTECTED]
Index: cmds.c
===
RCS file: /usr00/mirror/ncvs/src/usr.bin/tip/tip/cmds.c,v
retrieving revision 1.10
diff -r1.10 cmds.c
516c516
for (pc = eofchars; *pc; pc++)
---
for (pc = eofchars; pc *pc; pc++)
562a563,579
static int
nap(msec)
int msec; /* msec is milliseconds */
{
int rc;
rc = usleep ( msec*1000 );
if (rc != 0) {
fprintf ( stderr,
"warning: ldelay or cdelay interrupted, "
"delay time cut short: %s\n",
strerror(errno) );
}
return 0;
}
576d592
#ifdef notdef
579d594
#endif
581d595
#ifdef notdef
584d597
#endif
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
tip features (cdelay and ldelay)?
Hi, I have a couple of really dumb devices that I use 'tip' to talk to. One is a Motorola 6811 microcontroller and the other is an old EEPROM burner. I find that 'tip' overflows these devices when I'm sending Motorola s-record and Intel Hex formatted files. It looks like tip's 'cdelay' and 'ldelay' features do just the trick. However, they are disabled, surrounded by '#ifdef notdef' sequences. Just to make sure, I re-enabled them locally, and re-implemented the apparently lost 'nap()' function to make sure that these features work for my application, and they do. My question is: does anyone remember why these were disabled in the first place? Is there an equivalent replacement feature that I can use instead to pace the outgoing characters so that I don't overrun dumb devices with no flow control? Thanks, -Brian -- Brian Dean [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
emacs / ncurses - problem somewhere
Hi, Ever since the libtermcap / libncurses consolidation, change emacs has problems positioning the cursor and properly updating the screen for character-only devices like the console. It also affects the display in an xterm in non-X mode, i.e., when DISPLAY is *not* set. This is emacs 20.4, by the way on current as of yesterday. I've tried emacs from packages as well as a freshly built one from the ports and both exhibit the problem. Note that emacs works fine when it brings up is own window due to DISPLAY being set. Has anyone else seen this and already have a fix or know for sure whether this is an emacs bug or a FreeBSD bug? Thanks, -Brian -- Brian Dean [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall network performance
Bill Paul wrote: Of all the gin joints in all the towns in all the world, Brian Dean had to walk into mine and say: I was wondering what to attribute this better performance to. Could this be due to the new network driver / newbus integration? Well, since you didn't tell us what kind of network card(s) you have, that's impossible to say. Sorry ... I'm using the fxp driver. Thanks, -Brian -- Brian Dean SAS Institute Inc [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
a fix for a harmless but annoying sysinstall bug ...
Hi, This following is a patch that eliminates the sysinstall prompt that informs you that a distribution has failed to install, when really everything worked OK. This problem can be a real pain on FTP installs when you have packages following the normal install (like you can set up for a scripted install), but you aren't there to hit "OK", and then your ftp session times out, and the rest of your package installs fail when you finally come back and press "OK" because the ftp session has since timed out. Could someone please consider committing this patch? Index: dist.h === RCS file: /mirror/ncvs/src/release/sysinstall/dist.h,v retrieving revision 1.35 diff -u -r1.35 dist.h --- dist.h 1999/05/14 07:15:04 1.35 +++ dist.h 1999/07/01 21:43:20 @@ -21,7 +21,7 @@ #define DIST_DES 0x04000 #define DIST_CATPAGES 0x08000 #define DIST_PORTS 0x1 -#define DIST_ALL 0xF +#define DIST_ALL 0x1 /* Canned distribution sets */ #define _DIST_DEVELOPER \ Thanks, -Brian -- Brian Dean The SAS Institute Inc [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
can't install on machine with 8 Meg
Hi, I'm installing 4.0-19990610-SNAP onto a machine with 8 Meg of memory and it fails as follows: pid 6 (sh), uid 0, was killed: out of swap space The handbook claims that you can run the system in as little as 4 meg. It is very misleading to claim this if you can't install it. Or maybe I've missed some special instructions for installing the system on a low-memory machine? Thanks, -Brian -- Brian Dean brd...@mindspring.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: scripted install( was sysinstall manpage inst)
Pete, I am usually installing many machines at a time, and to save time, I've put together a simple script that generates the included config file based on the machine's name. We can do this because our machines are all configured identically with the exception of the name and IP address. Once you have the config file(s), you need to put them on a UFS floppy. I usually just copy them onto the same floppy that I dd'd the mfsroot.flp image onto, i.e., dd the mfsroot.flp image onto the floppy, mount the floppy, then copy your config files onto it. After you boot the install process, at the main menu, just select the Load Config File option (or something like that), and enter the name of the config file you want to use, which in my case is machine_name.cfg. -Brian -- Brian Dean brd...@unx.sas.com Process Engineering The SAS Institute Inc. On 08-Jun-99 John W. DeBoskey wrote: Hi, I have a -current machine which I use to run a: cd /usr/src make world cd release make release every night. On this machine, the sysinstall manpage is not installed onto the system during make world. % man sysinstall No manual entry for sysinstall % chroot /snap/release /bin/sh # man sysinstall SYSINSTALL(8) FreeBSD System Manager's Manual SYSINSTALL(8) NAME sysinstall - system installation and configuration tool etc, etc, etc. It seems to me, that during a make world, we should build sysinstall into /stand(or elsewhere), and install the manpage in the appropriate location. comments? critiques? Thanks, John ps: I am a heavy user of the scripted install process. I beleive we could help our cause by better documenting how the process works and providing some examples. Along those lines, here is a .cfg file I use for a machine that I use to test SNAPs on. This is an incredible time saving facility. John, Could you elaborate on where this file needs to be during the make release and if it is then automatically run by sysinstall or what else needs to be done to enable the script to be run. I'm running 3.2 but I assume it's similar. Also, can it be named *.cfg as the above seems to indicate or does it need to be named install.cfg. Thanks much Pete Notes: noError=True is not documented. See dispatch.c line 311 _ftpPath= is not documented. Appears to be an internal vs. external naming scheme. Not sure... See 1.157 of sysinstall.h, int dirty;. # gigabit1.cfg # # FreeBSD Installation Config file for gigabit1.unx.sas.com # # This file generated on 05/06/99 15:23:16 # debug=yes ipaddr=10.26.1.231 hostname=gigabit1.unx.sas.com domainname=unx.sas.com defaultrouter=10.26.0.1 netmask=255.255.0.0 # - End of generated information - netDev=fxp0 ftp=ftp://freebsd.pc.sas.com/pub/FreeBSD _ftpPath=ftp://freebsd.pc.sas.com/pub/FreeBSD nameserver=10.16.149.6 mediaSetFTP distSetEverything disk=wd0 partition=exclusive diskPartitionEditor # 512 Meg swap partition wd0s1-1=swap 1048576 none # 1 Gig /tmp partition wd0s1-2=ufs 2097152 /tmp # 256 Meg /root partition wd0s1-3=ufs 524288 / # 256 Meg /var partition wd0s1-4=ufs 524288 /var # all remaining space for /usr partition wd0s1-5=ufs 0 /usr diskLabelEditor installCommit package=bash-2.03 noError=TRUE packageAdd package=elm-2.4ME+54 noError=TRUE packageAdd package=emacs-20.3 noError=TRUE packageAdd package=jpeg-6b noError=TRUE packageAdd package=less-337 noError=TRUE packageAdd package=linux_lib-2.6.1 noError=TRUE packageAdd package=mm-2.7 noError=TRUE packageAdd package=pdksh-5.2.13 noError=TRUE packageAdd To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- E-Mail: Pete Mckenna pmcke...@uswest.net Date: 08-Jun-99 Time: 16:33:03 This message was sent by XFMail -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: swap-related problems
I do not see how they can guarantee the usability of the returned memory with the current kernel. There apparently is no way of knowing at malloc time if the memory can be used. Worse then that, it may be possible to use it at malloc time, but unless your program runs and touches every page, the memory may not be available later. Check the man page (and the source). It looks as if export MALLOC_OPTIONS=Z will cause malloc to touch every page and zero it out. This may be in part what you are wanting. Also, you can compile in malloc_options = Z to acheive the same affect without having to always export the environment variable. Of course, when you do this, your process will (might) still be killed immediately or at some point in the future, which I think is what you are trying to avoid :( -Brian -- Brian Dean brd...@unx.sas.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
aio_read panics SMP kernel
Hi, I'm using a dual 350MHz Dell Precision 410 with 4.0-19990130-SNAP (SMP enabled) to prototype a program that uses asynchronous read and write (aio_read() and aio_write()), and found that the following simple and not very useful program (it's for demonstration purposes only!) causes the system to do one of three things: 1) panic - page fault in the kernel ... I don't have any other specifics, I will follow up with the details provided by the console as soon as I can make this occur again (I should have written it down the first time). 2) reset - no panic or anything, just a system reset and subsequent reboot 3) hang - everything totally unresponsive, machine does not respond to pings or anything else, no keyboard response. Below, please find the output of 'mptable' for the SMP experts and the program that I used to cause the panic. Any help on fixing this and/or suggestions on what I might be doing wrong are much appreciated. Thanks, -Brian -- Brian Dean Process Engineering brd...@unx.sas.com Following is the output of 'mpinfo' on this machine: [r...@mrose]:/brdean- mptable === MPTable, version 2.0.15 --- MP Floating Pointer Structure: location: BIOS physical address: 0x000fe710 signature:'_MP_' length: 16 bytes version: 1.4 checksum: 0x91 mode: Virtual Wire --- MP Config Table Header: physical address: 0x000f signature:'PCMP' base table length:468 version: 1.4 checksum: 0x33 OEM ID: 'DELL' Product ID: 'WS 410 ' OEM table pointer:0x OEM table size: 0 entry count: 50 local APIC address: 0xfee0 extended table length:0 extended table checksum: 0 --- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model StepFlags 0 0x11BSP, usable 6 5 2 0x183fbff 1 0x11AP, usable 6 5 2 0x183fbff -- Bus:Bus ID Type 0 PCI 1 PCI 2 PCI 3 ISA -- I/O APICs: APIC ID Version State Address 2 0x11usable 0xfec0 -- I/O Ints: TypePolarityTrigger Bus ID IRQAPIC ID PIN# ExtINT active-hiedge3 0 20 INT conformsconforms3 1 21 INT conformsconforms3 0 22 INT conformsconforms3 3 23 INT conformsconforms3 4 24 INT conformsconforms3 5 25 INT conformsconforms3 6 26 INT conformsconforms3 7 27 INT conformsconforms3 8 28 INT conformsconforms3 9 29 INT conformsconforms310 2 10 INT conformsconforms311 2 11 INT conformsconforms312 2 12 INT conformsconforms314 2 14 INT conformsconforms315 2 15 INT conformsconforms0 13:A 2 16 INT conformsconforms0 14:D 2 16 INT conformsconforms0 16:B 2 16 INT conformsconforms1 0:A 2 16 INT conformsconforms2 6:C 2 16 INT conformsconforms2 9:D 2 16 INT conformsconforms0 13:B 2 17 INT conformsconforms0 14:A 2 17 INT conformsconforms0 16:C 2 17 INT conforms
