Mylex eXtremeRAID 2000 timeout/hang
We are trying to install a Mylex eXtreme 2000 card with a Dell Powervault 12 drive SCA housing. The drives in the array are numbered 0-5 and 8-13. The backplane of the array is id 15. During the kernel probe, we see the message mly0: drive at 03:15 not responding five times after the "waiting 15 seconds for SCSI devices to spin up" message, and then nothing else. The system doesn't hang, but it never goes anywhere from there. This is with F/W 6.00-00 and BIOS 6.00-01. Any ideas ? -- j. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fixed - pthread altsigstack problem
Both of the patches below fix the problem mentioned in PR bin/25110. The
first one fixes it inside of kern_fork.c and would appear to apply the
corrective behaviour regardless of whether the process uses libc_r or not.
The second patch fixes the problem inside of uthread_fork.c. Whether the
first approach imposes an extra cost on non-threaded applications I'm not
kernel-experienced enough to say, but hopefully between two of you gents you
can decide which is the better fix to apply.
As I mentioned in my original post, this is a bug that we are experiencing
in 4.3-BETA, so if this could make it into 4.3-RELEASE it would be of great
help. One note regarding the second (libc_r) patch: the reference to
__sys_sigaltstack needs to be changed to _thread_sys_sigaltstack in order to
prevent undefined symbols on 4.x systems.
Patch #1 (kernel fix):
--- kern_fork.c.origSat Mar 10 12:17:40 2001
+++ kern_fork.c Sat Mar 10 12:20:39 2001
@@ -434,7 +434,7 @@
* Preserve some more flags in subprocess. P_PROFIL has already
* been preserved.
*/
- p2-p_flag |= p1-p_flag P_SUGID;
+ p2-p_flag |= p1-p_flag (P_SUGID | P_ALTSTACK);
if (p1-p_session-s_ttyvp != NULL p1-p_flag P_CONTROLT)
p2-p_flag |= P_CONTROLT;
if (flags RFPPWAIT)
Patch #2 (libc_r fix):
--- uthread_fork.c 2001/01/24 13:03:33 1.21
+++ uthread_fork.c 2001/03/09 17:53:37
+
@@ -32,6 +32,7 @@
* $FreeBSD: src/lib/libc_r/uthread/uthread_fork.c,v 1.21 2001/01/24 13:03:33
deischen Exp $
*/
#include errno.h
+#include signal.h
+
#include string.h
#include stdlib.h
#include unistd.h
@@ -110,7 +111,16 @@
else if (_pq_init(_readyq) != 0) {
/* Abort this application: */
PANIC("Cannot initialize priority ready queue.");
- } else {
+ } else if ((_thread_sigstack.ss_sp == NULL)
+
+ ((_thread_sigstack.ss_sp = malloc(SIGSTKSZ)) == NULL))
+
+ PANIC("Unable to allocate alternate signal stack");
+
+ else {
+
+ /* Install the alternate signal stack: */
+
+ _thread_sigstack.ss_size = SIGSTKSZ;
+
+ _thread_sigstack.ss_flags = 0;
+
+ if (__sys_sigaltstack(_thread_sigstack, NULL) != 0)
+
+ PANIC("Unable to install alternate signal stack");
+
+
+
/*
* Enter a loop to remove all threads other than
* the running thread from the thread list:
Thanks for the help guys.
--
j.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
sysinstall option for softupdates
Are there any issues/plans to let users enable softupdates from inside of sysinstall ? Softupdates are already enabled in the GENERIC kernel, but to turn them on you have to run tunefs with the filesystem unmounted. Too often I find myself doing an onsite install then doing all my customization remotely only to realize that I've forgotten to enable softupdates. My machines all run in securelevel 3, so the only fix I've come up with is to horribly twist the purpose of the rc.diskless scripts, as they are the only 'hooks' I've found in /etc/rc that can be executed before the r/w mounts take place. It works, but damn is it ugly. If this is a good idea[tm], this could go either in the label editor (probably more trouble than it's worth, as there is no code in sysinstall to manipulate superblocks.) There is also the issue of cramping in the label editor screen. What might make more sense is to have this on the Configuration menu, and provide a dialog-driven interface to executing tunefs. There might be issues surrounding the dismount/remount sequence that would be required here. A more extensible option would be to add a facility to /etc/rc to execute user scripts from a directory on the root partition upon boot. This technique could then be applied to other purposes, such as this hack I use for installing a new kernel on a remote box running at securelevel 3: -- START -- #!/bin/sh # cd /sys/compile/MYKERNEL if [ -x kernel ] then /usr/bin/make install /bin/rm /etc/rc.local /sbin/reboot fi --- END --- I install this script as /etc/rc.local.kerninst and hardlink it to /etc/rc.local in lieu of running 'make installkernel' or 'make install' (if I'm using the old kernel build method.) This isn't all that clean because it requires two reboots for a kernel install, and the reboot happens after everything has been brought up (but just before kern.securelevel gets bumped.) Again, it works but it's ugly. Having a facility for running these 'early' config scripts, optimally with a way of deleting them or flagging them as having been run already would be of great help. Thoughts ? -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall option for softupdates
* Jordan Hubbard ([EMAIL PROTECTED]) [010310 14:52]: H. OK, you intrigued me enough by this that I just went ahead and did it in -current. :) Let me know what you think, come tomorrow's snapshot. And that, in a nutshell, is why I love FreeBSD I've got a box that is in desperate need of an upgrade from 3.x.. I'll give it a shot tommorrow and report back. Thanks. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PR bin/25110 - pthreads signal handling problem
I'm wondering if anyone has the time or inclination to take a look at a fix for PR bin/25110. We're having problems using a freshly-built 4.2-stable box (technically 4.3 rc at this point), and the bug is still present. I'm not sure how many people would see this problem (we see it because we have to compile Apache 1.x with the -pthread switch due to add-on modules that are threaded). Under 4.1-stable, everything was fine. At some point between 4.1-stable and 4.2-release, something changed, but my hunt through the CVS repository hasn't revealed anything obvious. In any case, it's a repeatable bug (the PR includes a code sample) and unless looked at, it will be a bug in 4.3-release. If there's any clarification needed, please let me know. TIA. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ftp and /etc/services...
* Donn Miller ([EMAIL PROTECTED]) [000816 14:43]:
This is on a recently-built -current box. When I try to move ftp from
port 21 to port 2121 in /etc/services, I get a "Connection
refused" message when I try to login to anonymous ftp sites. Should ftp
be this dependent on /etc/services? What if you _have_ no services
running, e.g. inetd portmap? Returning ftp to port 21 in services fixes
this problem. I posted earlier about my problems with ftp recently.
The name to port mapping for a service is used by two processes on your
system: the ftpd daemon and the ftp client. Modifying the port in
/etc/services did move the daemon, but it also makes the client look up the
new port when it wants to establish an outbound connection.
Possible solutions:
1. If your FTP daemon can run in standalone mode, it may offer an option to
change the port it listens on.
2. You can create an alternate service name with the new port in
/etc/services ("myftp" for example), then change the entry in inetd.conf to
make the daemon run on the alternate port.
--
j.
James FitzGibbon [EMAIL PROTECTED]
Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Journaling Filesystem ?
* Thomas T. Veldhouse ([EMAIL PROTECTED]) [000721 16:01]: Hello. I was wondering if there is any work on a Journaling filesystem to possible replace, or as an alternative to UFS. I have been following ReiserFS for Linux quite closely, and I have had the chance to experiment with it. It seems to be coming along nicely and the performance is great. Are there plans for something along this line for FreeBSD? Is there a project underway? At the Usenix 2000 Conference, a paper comparing Softupdates to a Journalling Filesystem was presented. The author said that the tests were performed on a FreeBSD box. AFAIK, the code is not yet available, but one of the other attendees mentioned that it would be 'some time in the near future'. The journally system allowed for the journal to exist as a file on the filesystem in question, or on a separate partition (which would be mounted synchronously to provide a level of protection from crashes). That having been said, the performance of the filesystem was not significantly different from softupdates. You can get at the paper if you're a Usenix member. The authors included Margo Selzer and Kirk McKusick, but the talk was given by another of the authors whose name I can't recall at the moment. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
rndcontrol with 16 interrupts
Are there any plans to allow rndcontrol to accept greater than 16 interrupts on SMP machines ? On my ASUS XG-DLS board, all the interesting interrupts that I want to use to stir the entropy pool are greater than 16. Examination of sys/i386/i386/mem.c on RELENG_3, RELENG_4 and HEAD all have this comment and code snippet: /* * XXX the data is 16-bit due to a historical botch, so we use * magic 16's instead of ICU_LEN and can't support 24 interrupts * under SMP. */ intr = *(int16_t *)data; if (cmd != MEM_RETURNIRQ (intr 0 || intr = 16)) return (EINVAL); I don't exactly understand what ICU_LEN refers to or if there are technical reasons that we can't support 24 interrupts, but the present situation leaves me with a powerful machine that can't take advantage of /dev/random at all (the pool has so little to feed off of that reads of even small amounts of data block). Can anyone shed some light ? TIA. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current.freebsd.org ftp misconfig ?
* Jordan K. Hubbard ([EMAIL PROTECTED]) [000329 02:34]: Temporarily down; "engineers are working on the problem." :) Does anyone have a semi-recent 3.4-STABLE snapshot available for public consumption ? The latest I have lying around is 2303. Thanks. Is this a transient situation, or is current down for maintainance ? [central-01:james] ~ (2) ftp -a current.freebsd.org Connected to usw2.freebsd.org. 220 usw2.freebsd.org FTP server (Version wu-2.6.0(1) Tue Jan 25 00:05:38 CST 2000) ready. 331 Guest login ok, send your complete e-mail address as password. 530 Can't set guest privileges. ftp: Login failed. ftp quit 221 Goodbye. [central-01:james] ~ (3) -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
current.freebsd.org ftp misconfig ?
Is this a transient situation, or is current down for maintainance ? [central-01:james] ~ (2) ftp -a current.freebsd.org Connected to usw2.freebsd.org. 220 usw2.freebsd.org FTP server (Version wu-2.6.0(1) Tue Jan 25 00:05:38 CST 2000) ready. 331 Guest login ok, send your complete e-mail address as password. 530 Can't set guest privileges. ftp: Login failed. ftp quit 221 Goodbye. [central-01:james] ~ (3) -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why not gzip iso images?
* Jeffrey J. Mountin ([EMAIL PROTECTED]) [000315 17:35]: However, if you consider the size of the file and the possibility of corruption, then it should be archived with gzip and forget the compression (gzip -1). Now it can be checked for errors. Isn't there a CHECKSUMS.MD5 file in the directory where the ISO image is placed on the FTP site ? Another issue is the size. Many factors determine how quickly one can obtain the ISO. It would be nice if it were broken into smaller volumes. About 10-20 MB each would be good. That way should something fail, there less time and bandwidth wasted should one need to start over. It might be nice if there were a utility that could pull the ISO in small slices just like any distribution and then put it back together. For that matter, couldn't the ISO image be made into a distribution that sysinstall would understand ? To download it, you would : - run sysinstall - change the installation direction in the options dialog to match the one you want to download (4.0-RELEASE in this case) - select a custom distribution with just the "ISO image" dist - select "commit" sysinstall could then download the dist as many small chunks, and the "install" procedure would just be to glue the chunks back together and stick it in a known place on the HD. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Suggested change to rc.network
There is already a precedent for allowing users to use drop-in replacements
for certain network daemons by specifying the path to the daemon in rc.conf.
Examples include the ${ntpdate_program} and ${xtnpd_program} variables that
are used in /etc/rc.network.
Wietse Venema has for some time had a replacement portmapper that uses
libwrap to control access using hosts.allow. It doesn't protect the
daemons, but it can help disguise what RPC services you are running.
I'm suggesting to have rc.network use a ${portmap_program} variable, with a
suitable default in /etc/defaults/rc.conf of /usr/sbin/portmap.
Any comments appreciated.
--
j.
James FitzGibbonja...@ehlo.com
EHLO Solutions Voice/Fax (416)410-0100
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
