libl.a in libipsec
These days I've cvsup-ed to current and start to 'make world' from my 3.4 RELEASE. Everything was ok, till making /usr/src/lib/libipsec where some dependencies of /usr/src/lib/libl.a was not found? Any ideas? I'm not subscribed to freebsd-current, thats please reply and to me! thanks Dimitar Peikov Get free email and a permanent address at http://www.netaddress.com/?N=1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please test for 8G-OVER-Booting with /boot/loader
John Baldwin wrote: Looks good to me, but I need to test it to make sure. I will also look at seeing if I can squeeze the int 13 extension installation check into boot1 and boot0 so that they will use packet mode automatically as well. I recall comments (by rnordier/msmith) to the effect that packet mode support might break things. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] The size of the pizza is inversely proportional to the intensity of the hunger. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libl.a in libipsec
These days I've cvsup-ed to current and start to 'make world' from my 3.4 RELEASE. Everything was ok, till making /usr/src/lib/libipsec where some dependencies of /usr/src/lib/libl.a was not found? Any ideas? I am checking it now, but not yet clear why it happens. In old environments, libl.a seemed to be already installed at that time, but now it doesn't exist at libipsec build time. Yoshinobu Inoue To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libl.a in libipsec
In [EMAIL PROTECTED] Yoshinobu Inoue
[EMAIL PROTECTED] wrote:
These days I've cvsup-ed to current and start to 'make world' from my
3.4 RELEASE. Everything was ok, till making /usr/src/lib/libipsec where some
dependencies of /usr/src/lib/libl.a was not found? Any ideas?
I am checking it now, but not yet clear why it happens. In
old environments, libl.a seemed to be already installed at
that time, but now it doesn't exist at libipsec build time.
libl.a isn't necessary for libipsec building at all.
The error now is the result of adding ${LIBL} to DPADD by bde
in the ver 1.3 of the Makefile in the src/lib/libipsec.
N.Dudorov
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure
On Tue, 28 Mar 2000, Yoshinobu Inoue wrote: Any idea? [...] /usr/src/lib/libipsec/ipsec_get_pol icylen.c -o ipsec_get_policylen.So cc -fpic -DPIC -O -pipe -I/usr/obj/usr/src/lib/libipsec -DIPSEC_DEBUG -DIPSEC -D INET6 -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libipsec/../../sys/net key/key_debug.c -o key_debug.So make: don't know how to make /usr/obj/usr/src/i386/usr/lib/libl.a. Stop *** Error code 2 What is your src/lib/libipsec/Makefile version? It might have been fixed by recent commit from bde which adds define of DPADD. [...] Mine is: # $FreeBSD: src/lib/libipsec/Makefile,v 1.3 2000/03/27 15:16:06 bde Exp $ which seems to be the one with the 'fix' you mention... I had the same build failure. There is a suggestion to fix the build failure in cvs messages. Is that the way to solve it? -- Marc Schneiders --- [EMAIL PROTECTED] --- [EMAIL PROTECTED] FreeBSD propro.freebeastie.org 5.0-CURRENT To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure
I had the same build failure. There is a suggestion to fix the build failure in cvs messages. Is that the way to solve it? I am trying buildworld again with no libl in libipsec Makefile, as previous Dimitar's message. If it is OK(and will be OK), I'll commit the fix. Yoshinobu Inoue To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cvs repository nits and gnats
Greetings, I'm working on a new project and had the need for a clean set of sources on a new machine. In the course of setting it all up I neglected to copy over my .cvsrc file which has (amongst other things) 'co -P'. In checking out the sources for RELENG_4 I ended up with a large number of empty directories. Some of them were obviously relics of the past, like src/TODO-2.1, src/usr.sbin/xntpd, etc. There were a large number in contrib, probably detritus from imports, etc. I'm not sure if this is significant, it obviously doesn't do any harm. I just thought I'd mention it. Slightly more serious was the presence of various lock files/directories. Specifically, one in src/games/primes killed my co as an unpriviliged user because it was set 700 and owned by root. The co failed because it couldn't create a lock file. I did a 'find . -name \*\#\* in my CVSROOT and found several other files like this. Deleting them did no harm, and they didn't return when I ran cvsup again. Finally, a question. I'm doing my cvs co/update on this machine remotely via rsh (within our secure network of course). When I start the update it creates an entire src directory tree in /tmp. This takes a great deal of time, so I'm wondering if this can be avoided somehow? I'm doing the cvs rsh as root on the client machine, and as an unpriviliged user on the cvs server machine. Hope this is helpful, Doug -- "So, the cows were part of a dream that dreamed itself into existence? Is that possible?" asked the student incredulously. The master simply replied, "Mu." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DDB and dumping disk
On Mon, 27 Mar 2000 14:50:12 +0200, Jeroen Ruigrok van der Werven wrote: I wasn't complaining, on the contrary! I was happily surprised it was way faster than the SCSI dump. =) So now the only question is whether our existing bootstrapping infrastructure already has some way to use your ddb magic to set dumpdev. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DDB and dumping disk
-On [2328 12:55], Sheldon Hearn ([EMAIL PROTECTED]) wrote: On Mon, 27 Mar 2000 14:50:12 +0200, Jeroen Ruigrok van der Werven wrote: I wasn't complaining, on the contrary! I was happily surprised it was way faster than the SCSI dump. =) So now the only question is whether our existing bootstrapping infrastructure already has some way to use your ddb magic to set dumpdev. :-) Well, I can set dumpdev in ddb, but the problem is that when I reboot that savecore doesn't detect a dump. If I boot the system completely and manually panic and let it dump savecore will detect the dump and put it in /var/crash. So I wonder what I forgot in DDB. I do: db show disk/ad0s1b 0xc0NN I then use this value to: db write dumpdev 0xc0NN dumpdev = - 0x0cNN I can then dump when typing: db panic But after the reboot savecore doesn't recognise the dump. savecore: no coredump Hope this makes it a bit more clear. -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED] VIA NET.WORKS The Netherlands BSD: Technical excellence at its best http://www.bart.nl To desire immortality is to desire the eternal perpetuation of a great mistake... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DDB and dumping disk
On Tue, 28 Mar 2000 13:02:06 +0200, Jeroen Ruigrok van der Werven wrote: I can then dump when typing: db panic Damnit. So I've just committed bogus advice in dumpon(8). :-( Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DDB and dumping disk
-On [2328 13:15], Sheldon Hearn ([EMAIL PROTECTED]) wrote: On Tue, 28 Mar 2000 13:02:06 +0200, Jeroen Ruigrok van der Werven wrote: I can then dump when typing: db panic Damnit. So I've just committed bogus advice in dumpon(8). :-( No not really. Your patch is a step in the right direction. I am currently only trying to figure out why the DDB way doesn't trigger savecore to recognise the dump. -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED] VIA NET.WORKS The Netherlands BSD: Technical excellence at its best http://www.bart.nl How are the mighty fallen... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libl.a in libipsec
I am checking it now, but not yet clear why it happens. In
old environments, libl.a seemed to be already installed at
that time, but now it doesn't exist at libipsec build time.
libl.a isn't necessary for libipsec building at all.
The error now is the result of adding ${LIBL} to DPADD by bde
in the ver 1.3 of the Makefile in the src/lib/libipsec.
N.Dudorov
Thanks, after removing libl related dependency from libipsec
Makefile, buildworld just passed libipsec part.
libl.a was not used on the first place. :-
I'll commit the fix.
Yoshinobu Inoue
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Please test for 8G-OVER-Booting with /boot/loader
On 28-Mar-00 Daniel C. Sobral wrote: John Baldwin wrote: Looks good to me, but I need to test it to make sure. I will also look at seeing if I can squeeze the int 13 extension installation check into boot1 and boot0 so that they will use packet mode automatically as well. I recall comments (by rnordier/msmith) to the effect that packet mode support might break things. Oh, I remember. This just checks if the controller supports LBA. You also need to check if the drive supports LBA. The problem is with older drives. Hmm, I'll look around to see if you can ask the BIOS for drive capabilities. -- 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: DDB and dumping disk
Jeroen Ruigrok van der Werven writes: I am currently only trying to figure out why the DDB way doesn't trigger savecore to recognise the dump. Maybe because kern.dumpdev has a different value and savecore can't find a dump on it ? Have you tried setting kern.dumpdev by hand and then manually invoking savecore ? --- Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libl.a in libipsec
In [EMAIL PROTECTED] Yoshinobu Inoue
[EMAIL PROTECTED] wrote:
I am checking it now, but not yet clear why it happens. In
old environments, libl.a seemed to be already installed at
that time, but now it doesn't exist at libipsec build time.
libl.a isn't necessary for libipsec building at all.
The error now is the result of adding ${LIBL} to DPADD by bde
in the ver 1.3 of the Makefile in the src/lib/libipsec.
N.Dudorov
Thanks, after removing libl related dependency from libipsec
Makefile, buildworld just passed libipsec part.
libl.a was not used on the first place. :-
I'll commit the fix.
It seems to me (and my buildworld agree with this)
that 'liby' is also not necessary for building of 'libipsec'.
N.Dudorov
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: libl.a in libipsec
Thanks, after removing libl related dependency from libipsec Makefile, buildworld just passed libipsec part. libl.a was not used on the first place. :- I'll commit the fix. It seems to me (and my buildworld agree with this) that 'liby' is also not necessary for building of 'libipsec'. N.Dudorov I'll also commit that change after one more check. Thanks, Yoshinobu Inoue To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DDB and dumping disk
On Tue, 28 Mar 2000, Gary Jennejohn wrote: Jeroen Ruigrok van der Werven writes: I am currently only trying to figure out why the DDB way doesn't trigger savecore to recognise the dump. Maybe because kern.dumpdev has a different value and savecore can't find a dump on it ? Have you tried setting kern.dumpdev by hand and then manually invoking savecore ? Also, dumplo must have a consistent value. dumpdev should be set using ddb before the SYSINIT for the dump device is called, or better, never set dumpdev with ddb, but call setdumpdev(desired_dumpdev) directly at a suitable time. When setdumpdev() is not called, some sanity checks are bypassed, and dumplo is only statically initialized (to 0). This means that dumps go to the start of the dumpdev device instead of to the end. I think savecore will find the dump provided dumplo is consistently initialized, so the only problem with starting dumps at the start of the device is that this will clobber the label if the device contains the label. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DDB and dumping disk
On Tue, 28 Mar 2000 22:51:54 +1000, Bruce Evans wrote: I think savecore will find the dump provided dumplo is consistently initialized, so the only problem with starting dumps at the start of the device is that this will clobber the label if the device contains the label. Given that the moment at which dumpdev is set seems important, I think it's probably better for me to back these isntructions out of the dumpon(8) manual page and wait for something less tricky. Do you agree? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libl.a in libipsec
Sorry I broke the world.
old environments, libl.a seemed to be already installed at
that time, but now it doesn't exist at libipsec build time.
It was never installed in the temporary build tree, except possibly
in old, broken versions of /usr/src/Makefile* which built and installed
it as part of making lex as a build-tool (non-broken versions had
complications to avoid making lex/lib in the build-tool case, since
making it caused other problems). When the dependency was missing,
-ll caused the linker to find libl.a in the wrong place.
I don't see how liby can get built before libipsec either.
libl.a isn't necessary for libipsec building at all.
The error now is the result of adding ${LIBL} to DPADD by bde
in the ver 1.3 of the Makefile in the src/lib/libipsec.
N.Dudorov
Thanks, after removing libl related dependency from libipsec
Makefile, buildworld just passed libipsec part.
libl.a was not used on the first place. :-
I'll commit the fix.
It seems to me (and my buildworld agree with this)
that 'liby' is also not necessary for building of 'libipsec'.
liby is used. Linking to the static version of it isn't good.
I think it results in functions from liby.a being included in
libipsec.so. Since liby.a isn't compiled with -fpic, it's not
clear how this can work. I think the linker prints RRS warnings
when it doesn't work. I haven't seen those, so maybe it does
work.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
kernel trap 9
I am having a serious problem trying to build a new kernel for my machine. I was running 'current' and have now 'downgraded' to 4.0-RELEASE to try and fix the problem. When I try to boot my machine, it goes into the bootstrap loader okay, and waits 10 seconds, then the screen flashes and the following message pops up on the screen: kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault in kernel mode pointers, etc processor eflags = resume, IOPL = 0 current process = Idle interrupt mask = net tty bio cam trap number = 9 panic: general protection fault Uptime: 0s My machine is a PIII-500 on an Asus P2B-S motherboard. I have 128MB of RAM and 2 Video Cards installed. I am using using a 'dc0' type NIC. I suspect the problem is in the build process (or some residual flag), because I can boot kernel.GENERIC from the 4.0-RELEASE without a hitch. If someone would be interested in giving me a hand with this, I would be happy to send them my config files, etc. brian +---+--+ He rides a cycle of mighty days, and \ Wm Brian and Lori McCane represents the last great schizm among\ McCane Consulting the gods. Evil though he obviously is, \ [EMAIL PROTECTED] he is a mighty figure, this father of \ http://bmccane.maxbaud.net/ my spirit, and I respect him as the sons \ http://www.sellit-here.com/ of old did the fathers of their bodies. \ http://kidsearch.maxbaud.net/ Roger Zelazny - "Lord of Light"\ http://www.maxbaud.net/ +---+--+ 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: libl.a in libipsec
It seems to me (and my buildworld agree with this) that 'liby' is also not necessary for building of 'libipsec'. liby is used. Linking to the static version of it isn't good. I think it results in functions from liby.a being included in libipsec.so. Since liby.a isn't compiled with -fpic, it's not clear how this can work. I think the linker prints RRS warnings when it doesn't work. I haven't seen those, so maybe it does work. Bruce In the build after the trial change of removing liby dependency from libipsec Makefile, misteriously libipsec is not built as if it is just neglected, and buildworld continues. :-\ Yoshinobu Inoue To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'machine/param.h' required for 'sys/socket.h'
sys/socket.h: #ifdef _NO_NAME_SPACE_POLLUTION #include machine/param.h #else #define _NO_NAME_SPACE_POLLUTION #include machine/param.h #undef _NO_NAME_SPACE_POLLUTION #endif I like this for a quick fix. Only define _ALIGN() like the current ALIGN(). Don't define all the variants given in your previous mail. I created the patches. It become a little bit more complicated than I expected, to avoid duplicated inclusion independently in each of namespace polluted part and non polluted part. Please give me comments if any. Thanks, Yoshinobu Inoue Index: sys/socket.h === RCS file: /home/ncvs/src/sys/sys/socket.h,v retrieving revision 1.39 diff -u -r1.39 socket.h --- sys/socket.h2000/03/11 19:51:04 1.39 +++ sys/socket.h2000/03/28 12:02:12 @@ -37,6 +37,14 @@ #ifndef _SYS_SOCKET_H_ #define_SYS_SOCKET_H_ +#ifdef _NO_NAMESPACE_POLLUTION +#include machine/param.h +#else +#define_NO_NAMESPACE_POLLUTION +#include machine/param.h +#undef _NO_NAMESPACE_POLLUTION +#endif + /* * Definitions related to sockets: types, address families, options. */ Index: i386/include/param.h === RCS file: /home/ncvs/src/sys/i386/include/param.h,v retrieving revision 1.54 diff -u -r1.54 param.h --- i386/include/param.h1999/12/11 10:54:06 1.54 +++ i386/include/param.h2000/03/28 12:02:13 @@ -37,8 +37,16 @@ * $FreeBSD: src/sys/i386/include/param.h,v 1.54 1999/12/11 10:54:06 peter Exp $ */ -#ifndef _MACHINE_PARAM_H_ -#define_MACHINE_PARAM_H_ +#ifndef _MACHINE_PARAM_H_NO_NAMESPACE_POLLUTION +#define_MACHINE_PARAM_H_NO_NAMESPACE_POLLUTION + +/* + * Round p (pointer or byte index) up to a correctly-aligned value + * for all data types (int, long, ...). The result is unsigned int + * and must be cast to any desired pointer type. + */ +#define _ALIGNBYTES(sizeof(int) - 1) +#define _ALIGN(p) (((unsigned)(p) + _ALIGNBYTES) ~_ALIGNBYTES) /* * Machine dependent constants for Intel 386. @@ -46,12 +54,23 @@ #ifndef _MACHINE #define_MACHINEi386 #endif -#ifndef MACHINE -#define MACHINE"i386" -#endif #ifndef _MACHINE_ARCH #define_MACHINE_ARCH i386 #endif + +#endif /* !_MACHINE_PARAM_H_NO_NAMESPACE_POLLUTION */ + +#ifndef _NO_NAMESPACE_POLLUTION + +#ifndef _MACHINE_PARAM_H_ +#define_MACHINE_PARAM_H_ + +/* + * Machine dependent constants for Intel 386. + */ +#ifndef MACHINE +#define MACHINE"i386" +#endif #ifndef MACHINE_ARCH #defineMACHINE_ARCH"i386" #endif @@ -70,13 +89,8 @@ #define NCPUS 1 #endif -/* - * Round p (pointer or byte index) up to a correctly-aligned value - * for all data types (int, long, ...). The result is unsigned int - * and must be cast to any desired pointer type. - */ -#define ALIGNBYTES (sizeof(int) - 1) -#define ALIGN(p) (((unsigned)(p) + ALIGNBYTES) ~ALIGNBYTES) +#define ALIGNBYTES _ALIGNBYTES +#define ALIGN(p) _ALIGN(p) #define PAGE_SHIFT 12 /* LOG2(PAGE_SIZE) */ #define PAGE_SIZE (1PAGE_SHIFT) /* bytes/page */ @@ -158,3 +172,5 @@ #definepgtok(x)((x) * (PAGE_SIZE / 1024)) #endif /* !_MACHINE_PARAM_H_ */ +#endif /* !_NO_NAMESPACE_POLLUTION */ + Index: alpha/include/param.h === RCS file: /home/ncvs/src/sys/alpha/include/param.h,v retrieving revision 1.17 diff -u -r1.17 param.h --- alpha/include/param.h 2000/02/29 08:48:10 1.17 +++ alpha/include/param.h 2000/03/28 12:02:14 @@ -43,18 +43,47 @@ * @(#)param.h 8.1 (Berkeley) 6/10/93 */ +#ifndef _MACHINE_PARAM_H_NO_NAMESPACE_POLLUTION +#define_MACHINE_PARAM_H_NO_NAMESPACE_POLLUTION + +/* + * Round p (pointer or byte index) up to a correctly-aligned value for all + * data types (int, long, ...). The result is u_long and must be cast to + * any desired pointer type. + * + * ALIGNED_POINTER is a boolean macro that checks whether an address + * is valid to fetch data elements of type t from on this architecture. + * This does not reflect the optimal alignment, just the possibility + * (within reasonable limits). + * + */ +#define _ALIGNBYTES7 +#define _ALIGN(p) (((u_long)(p) + _ALIGNBYTES) ~ _ALIGNBYTES) +#define _ALIGNED_POINTER(p,t) u_long)(p)) (sizeof(t)-1)) == 0) + /* * Machine dependent constants for the Alpha. */ #ifndef _MACHINE #define_MACHINEalpha #endif -#ifndef MACHINE -#defineMACHINE "alpha" -#endif #ifndef _MACHINE_ARCH #define_MACHINE_ARCH alpha #endif + +#endif /* !_MACHINE_PARAM_H_NO_NAMESPACE_POLLUTION */ + +#ifndef _NO_NAMESPACE_POLLUTION + +#ifndef _MACHINE_PARAM_H_ +#define_MACHINE_PARAM_H_ + +/* + * Machine dependent constants for the Alpha. + */
Re: DDB and dumping disk
On Tue, 28 Mar 2000, Sheldon Hearn wrote: Given that the moment at which dumpdev is set seems important, I think it's probably better for me to back these isntructions out of the dumpon(8) manual page and wait for something less tricky. Do you agree? Yes. The man page is also misleading about single user mode. dumpon(8) works fine in single user mode. The problem case is when the system crashes before reaching user mode. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DDB and dumping disk
-On [2328 17:40], Bruce Evans ([EMAIL PROTECTED]) wrote: On Tue, 28 Mar 2000, Sheldon Hearn wrote: Given that the moment at which dumpdev is set seems important, I think it's probably better for me to back these isntructions out of the dumpon(8) manual page and wait for something less tricky. Do you agree? Yes. The man page is also misleading about single user mode. dumpon(8) works fine in single user mode. The problem case is when the system crashes before reaching user mode. Exactly. And that is what I am now slowly trying to work on. Brian's addition of show disk in ddb was one step ahead. Now to get the functionality in one way or the other in either the loader or ddb or another thing. -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED] VIA NET.WORKS The Netherlands BSD: Technical excellence at its best http://www.bart.nl That's your Destiny, the only chance, take it, take it in your hands... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SMP patch breaks non SMP kernel build
. astpending is now undefined (/usr/src/sys/kern/kern_sig.c:1168) . some calls to get_mplock and rel_mplock are made without #define SMP conditionnal compile in following modules: kern_exec kern_exit kern_sig kern_sync mfs_vfsops mem trap To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP patch breaks non SMP kernel build
:. astpending is now undefined (/usr/src/sys/kern/kern_sig.c:1168) : :. some calls to get_mplock and rel_mplock are made without #define SMP : conditionnal compile in following modules: : : kern_exec : kern_exit : kern_sig : kern_sync : mfs_vfsops : mem : trap Hoya!... ok, I'll compile up a UP kernel and fix those problems -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SMP kernel broken at cvsup Tue Mar 28 11:56:07 BST 2000
Hi, Appears to boot OK, but then won't answer to network or console, not even CtlAltEsc to DDB. Screen saver kicks in OK though. -- Bob Bishop (0118) 977 4017 international code +44 118 [EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP kernel broken at cvsup Tue Mar 28 11:56:07 BST 2000
:Hi, : :Appears to boot OK, but then won't answer to network or console, not even :CtlAltEsc to DDB. Screen saver kicks in OK though. : :-- :Bob Bishop (0118) 977 4017 international code +44 118 :[EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK Make sure you haven't confused it between the patch set and the commit I made last night. Do a cvs update and then a cvs diff to make sure things haven't gotten confused. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Strange new ppp warnings
Hi, After upgrading my box to the 4.0-STABLE, I've discovered that ppp started produce regular warnings I've never seen before: Warning: nat_LayerPull: Dropped a packet What does it mean and what implications may it have? -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP patch breaks non SMP kernel build
:. astpending is now undefined (/usr/src/sys/kern/kern_sig.c:1168) : :. some calls to get_mplock and rel_mplock are made without #define SMP : conditionnal compile in following modules: : : kern_exec : kern_exit : kern_sig : kern_sync : mfs_vfsops : mem : trap Ok, should be fixed soon as the cvsup mirrors update. I didn't see anything in mfs_vfsops and I have no idea what 'mem' or 'trap' is, but I can compile up a UP kernel now. If you come across more compilation/options combinations that don't work send me email. Since we are probably going to be using get_mplock()/rel_mplock() and other mutex/locking functions more and more in the mainline kernel code, I've decided to turn them into __inline dummies for the UP kernel rather then attempt to #ifdef them out. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel trace question (kernel doesn't compile _without_ -O)
I'm puzzled over the following kernel trace. 'm' in frame 6 is
clearly not null... but in frame 5, it is. I have compiled the
ng_l2tp module without -O... just in case that was the problem, but
line 391 (the for loop) explicitly tests m for NULLness anyways.
Also... I have noticed that several modules don't want to compile in
the kernel without -O, including kern_synch.c (undefined reference to
__cursig) and atomic.c (inconsistent operand constraints in an `asm').
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1 0xc0155ed5 in panic (fmt=0xc026010f "page fault")
at ../../kern/kern_shutdown.c:554
#2 0xc022557a in trap_fatal (frame=0xc0269d58, eva=16)
at ../../i386/i386/trap.c:924
#3 0xc022522d in trap_pfault (frame=0xc0269d58, usermode=0, eva=16)
at ../../i386/i386/trap.c:817
#4 0xc0224db3 in trap (frame={tf_fs = -1071251440, tf_es = 9502736,
tf_ds = 16, tf_edi = 96, tf_esi = 1, tf_ebp = -1071211080,
tf_isp = -1071211132, tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 0,
tf_trapno = 12, tf_err = 0, tf_eip = -1072237390, tf_cs = 8,
tf_eflags = 66054, tf_esp = -1038559808, tf_ss = -1072044908})
at ../../i386/i386/trap.c:423
#5 0xc016f4b2 in m_dup (m=0x0, how=1) at ../../kern/uipc_mbuf.c:763
#6 0xc019e4f3 in ngl2tp_ctrlq_timeout (arg=0xc218d5c0)
at ../../netgraph/ng_l2tp.c:393
#7 0xc015b245 in softclock () at ../../kern/kern_timeout.c:131
(kgdb) frame 6
#6 0xc019e4f3 in ngl2tp_ctrlq_timeout (arg=0xc218d5c0)
at ../../netgraph/ng_l2tp.c:393
393 n = m_dup(m, M_NOWAIT);
(kgdb) l
388 int i, error = 0;
389 u_char *d;
390
391 for(m=p-ctrlq, i=0; m i p-Swin; m = m-m_nextpkt, i++)
392 {
393 n = m_dup(m, M_NOWAIT);
394 if(n)
395 {
396 d = mtod(n, u_char *);
397 *((u_int16_t *)(d+10)) = htons(p-Nr); /* update window recd */
(kgdb) p m
$1 = (struct mbuf *) 0xc0752280
--
|David Gilbert, Velocet Communications. | Two things can only be |
|Mail: [EMAIL PROTECTED] | equal if and only if they |
|http://www.velocet.net/~dgilbert | are precisely opposite. |
=GLO
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs repository nits and gnats
On Tue, 28 Mar 2000, Doug Barton wrote: src/TODO-2.1, src/usr.sbin/xntpd, etc. There were a large number in contrib, probably detritus from imports, etc. I'm not sure if this is significant, it obviously doesn't do any harm. I just thought I'd mention it. CVS has no concept of removing a directory (possibly excepting repository surgery), so unless you pass the -P option (prune empty directories) you get stuck with all of the old ones. Slightly more serious was the presence of various lock files/directories. Specifically, one in src/games/primes killed my co as an unpriviliged user because it was set 700 and owned by root. The co failed because it couldn't create a lock file. I did a 'find . -name \*\#\* in my CVSROOT and found several other files like this. Deleting them did no harm, and they didn't return when I ran cvsup again. I havent seen this. Finally, a question. I'm doing my cvs co/update on this machine remotely via rsh (within our secure network of course). When I start the update it creates an entire src directory tree in /tmp. This takes a great deal of time, so I'm wondering if this can be avoided somehow? I'm doing the cvs rsh as root on the client machine, and as an unpriviliged user on the cvs server machine. I ran into this the other day and was advised to mount the CVS repository via NFS instead of accessing it via rsh. This indeed solves the problem. Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP kernel broken at cvsup Tue Mar 28 11:56:07 BST 2000
At 09:52 -0800 28/3/00, Matthew Dillon wrote: Make sure you haven't confused it between the patch set and the commit I made last night. Do a cvs update and then a cvs diff to make sure things haven't gotten confused. Just blew /sys away and checked it out afresh. Same result I'm afraid, although I did get into DDB this time. Nothing obviously wrong, but the backtrace didn't go back past the keyboard interrupt. -- Bob Bishop (0118) 977 4017 international code +44 118 [EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Resource allocation error in new pnp code
Hi, I already mentioned this bug a few months ago but didn't got a reply. Maybe I'm the only one who is affected by this bug. I have several PnP cards in my system (see attached output of pnpinfo). Especially one card requests a resource: I/O Range 0x100 .. 0x3ff, alignment 0x1, len 0x1 [16-bit addr] My ISDN controller also requests a resource from this range: I/O Range 0x100 .. 0x3f0, alignment 0x8, len 0x8 [not 16-bit addr] Now the following happens: first card gets assigned: Mar 28 21:12:00 gate /kernel: unknown10: EEPROM at port 0x100 on isa0 and the ISDN card gets assigned: Mar 28 21:12:00 gate /kernel: isic0: Sedlbauer WinSpeed at port 0x101-0x108 irq 11 on isa0 which is wrong since it requests an alignment of 8. The code in /sys/isa/isa_common.c, which should prevent this is useless, since most work is done in /sys/kern/subr_rman.c which automatically tries to find an alternate region, but without honouring any alignment. Also attached is my (ugly) hack for this problem, but I think the problem should be addressed elsewhere (in the resource manager), since it may affect any type of resource allocation which requires different alignment. -- Daniel Checking for Plug-n-Play devices... Card assigned CSN #1 Vendor ID AZT3002 (0x02305407), Serial Number 0x PnP Version 1.0, Vendor Version 1 Device Description: AZT3002 PnP SOUND DEVICE Logical Device ID: AZT0500 0x00055407 #0 Device supports I/O Range Check Device Description: IDE CDROM DISABLED TAG Start DF Good Configuration I/O Range 0x0 .. 0x0, alignment 0x8, len 0x0 [16-bit addr] I/O Range 0x0 .. 0x0, alignment 0x2, len 0x0 [16-bit addr] IRQ: IRQ: High true edge sensitive TAG End DF Logical Device ID: AZT1004 0x04105407 #1 Device supports I/O Range Check Device Description: AUDIO TAG Start DF Good Configuration I/O Range 0x220 .. 0x220, alignment 0x10, len 0x10 [16-bit addr] I/O Range 0x388 .. 0x388, alignment 0x8, len 0x8 [16-bit addr] I/O Range 0x534 .. 0x534, alignment 0x4, len 0x4 [16-bit addr] IRQ: 5 IRQ: High true edge sensitive DMA: channel(s) 1 8-bit, not a bus master, count by byte, , Compatibility mode DMA: channel(s) 3 8-bit, not a bus master, count by byte, , Compatibility mode TAG Start DF I/O Range 0x220 .. 0x240, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0x388 .. 0x388, alignment 0x8, len 0x8 [16-bit addr] I/O Range 0x534 .. 0x608, alignment 0xd4, len 0x4 [16-bit addr] IRQ: 5 9 10 IRQ: High true edge sensitive DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode TAG Start DF I/O Range 0x220 .. 0x240, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0x388 .. 0x388, alignment 0x8, len 0x8 [16-bit addr] I/O Range 0xe84 .. 0xf44, alignment 0xc0, len 0x4 [16-bit addr] IRQ: 5 9 10 IRQ: High true edge sensitive DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode TAG Start DF I/O Range 0x100 .. 0x3f0, alignment 0x10, len 0x10 [16-bit addr] I/O Range 0x100 .. 0x3f8, alignment 0x8, len 0x8 [16-bit addr] I/O Range 0x100 .. 0xffc, alignment 0x4, len 0x4 [16-bit addr] IRQ: 5 9 10 11 15 IRQ: High true edge sensitive DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode TAG Start DF I/O Range 0x100 .. 0x3f0, alignment 0x10, len 0x10 [16-bit addr] I/O Range 0x100 .. 0x3f8, alignment 0x8, len 0x8 [16-bit addr] I/O Range 0x100 .. 0xffc, alignment 0x4, len 0x4 [16-bit addr] IRQ: 5 9 10 11 15 IRQ: High true edge sensitive DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode TAG End DF Logical Device ID: AZT2001 0x01205407 #2 Device supports I/O Range Check Device Description: MPU401 MIDI TAG Start DF Good Configuration I/O Range 0x330 .. 0x330, alignment 0x2, len 0x2 [16-bit addr] IRQ: 9 IRQ: High true edge sensitive TAG Start DF I/O Range 0x300 .. 0x330, alignment 0x30, len 0x2 [16-bit addr] IRQ: 5 9 10 11 15 IRQ: High true edge sensitive TAG Start DF I/O Range 0x100 .. 0x3fe, alignment 0x2, len 0x2 [16-bit addr] IRQ: 5 9 10 11 15 IRQ: High true edge sensitive TAG End DF Logical Device ID: AZT3001 0x01305407 #3 Device supports I/O Range Check Device Description: GAME PORT TAG Start DF Good Configuration I/O Range 0x200 .. 0x200, alignment 0x8, len 0x8 [16-bit addr] TAG Start DF I/O Range 0x208 .. 0x208,
Warnings when linking against libc_r
I'm seeing the following diagnostics with applications linked against libc_r cc -O -pipe -I/usr/local/include -D_REENTRANT -D_THREAD_SAFE -g -Wall -o .libs/structs structs.o -L/usr/local/lib ../../ggi/.libs/libggi.so -lc_r /usr/local/lib/libgg.so /usr/local/lib/libgii.so -Wl,--rpath -Wl,/usr/local/lib /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider using mkstemp() /usr/lib/libc.so: warning: tempnam() possibly used unsafely; consider using mkstemp() /usr/lib/libc.so: warning: this program uses gets(), which is unsafe. /usr/lib/libc.so: WARNING! setkey(3) not present in the system! /usr/lib/libc.so: WARNING! des_setkey(3) not present in the system! /usr/lib/libc.so: WARNING! encrypt(3) not present in the system! /usr/lib/libc.so: WARNING! des_cipher(3) not present in the system! /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider using mkstemp() /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid. Can these be ignored? From what I gathered from the mailing list archives this issue has reared its head before. goku.cl.msu.edu:dervish uname -a FreeBSD goku.cl.msu.edu 5.0-CURRENT FreeBSD 5.0-CURRENT #33: Tue Mar 14 11:25:48 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/GOKU i386 #;^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please test for 8G-OVER-Booting with /boot/loader
I have a Thinkpad 600X here that I installed freebsd on the third partition, but couldn't boot because of the 1024 cylinder bit, so I booted a Fixit floppy mounted my freebsd partitions, installed this patch, patched boot1 to always try packet mode and copied it over to the ntfs boot partition and used it from the NT Loader, and it booted right up, both natively and under VMware. I had to do a lot of mucking around to get things to the point where I could mount slice 3, the FreeBSD partition, and build the new boot code. -Charlie On Tue, Mar 28, 2000 at 02:21:36PM +0900, NAKAJI Hiroyuki wrote: How can I test this with FreeBSD which is installed over-8GB area and can't boot? I have a PC on which Solaris7 is installed within 8GB from the start of disk and FreeBSD 3.3-RELEASE is installed after(?) it. The installation was successfull. But I can't boot it. How can I install this patched /boot/loader in this dead system? -- NAKAJI Hiroyuki To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Charles Anderson[EMAIL PROTECTED] No quote, no nothin' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs repository nits and gnats
Thanks for the response... On Tue, 28 Mar 2000, Kris Kennaway wrote: On Tue, 28 Mar 2000, Doug Barton wrote: src/TODO-2.1, src/usr.sbin/xntpd, etc. There were a large number in contrib, probably detritus from imports, etc. I'm not sure if this is significant, it obviously doesn't do any harm. I just thought I'd mention it. CVS has no concept of removing a directory Hrrmm... cool! I've always used the -P option, so I've not seen this before. Having always been a "customer" of cvs rather than an administrator I'm learning new things at a rapid pace. Slightly more serious was the presence of various lock files/directories. Specifically, one in src/games/primes killed my co as an unpriviliged user because it was set 700 and owned by root. The co failed because it couldn't create a lock file. I did a 'find . -name \*\#\* in my CVSROOT and found several other files like this. Deleting them did no harm, and they didn't return when I ran cvsup again. I havent seen this. My gut feeling is that it's a timing issue. I happened to have been cvsup'ing when someone actually had a lock on something in the repository. Still I think it's odd that A) the cvsup "mirrors" of the master repository picked up these files, B) that my cvsup of the repository picked them up, and C) having picked them up, it didn't delete them when they were deleted from the real respository. FWIW, I always use cvsup7, and I found these lock files in both my home and work copies. I ran into this the other day and was advised to mount the CVS repository via NFS instead of accessing it via rsh. This indeed solves the problem. Yes, that's what I do everywhere _else_, but this particular machine's network position within our firewall makes that impossible at this time. We've outgrown a class C for our internal machines so we're blending a new one in and haven't gotten all the filtering in place yet. rsh was one "hole" that was available to me, and with proper wrapping it's pretty safe on our internal network. Thanks, Doug -- "So, the cows were part of a dream that dreamed itself into existence? Is that possible?" asked the student incredulously. The master simply replied, "Mu." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
periodic daily output (passwd diffs)
When I changed my passwords from DES to MD5, I noticed this little thing with periodic daily output. Backup passwd and group files: passwd diffs: 1,2c1,2 root:(password):0:0::0:0:Superuser:/root:/bin/csh toor:(password):0:0::0:0:Bourne-again Superuser:/root:/usr/local/bin/bash --- root:(password):0:0::0:0:Superuser:/root:/bin/csh toor:(password):0:0::0:0:Bourne-again Superuser:/root:/usr/local/bin/bash At first glimpse, everything seems identical.. so, where is the difference? I realized that I had changed ONLY the password, and this was shown in the diffs in this strange way--since the password is clipped from the output of diff. Is this done on purpose, to show who has changed their password, or is it a side-effect of the way things are done until now, and we should attempt to change it some time? -- Giorgos Keramidas, keramida @ ceid . upatras . gr See the headers of this message for my public key fingeprint. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
UP kernel performance and Matt Dillon's patches
I'm running a UP machine with Matt's latest changes. I was just compiling a new kernel and noticed the my PS/2 mouse under X was very sluggish. I never noticed this sort of behavior before the changes, even while doing ``make -j8 buildworld''. The compile was running on a UW SCSI disk on an Adaptec aic7880 Ultra SCSI adapter on my motherboard, in case it matters. Looks like something has been verschlimmbessert (a wonderful German word which means "made worse through improvement" :) Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please test for 8G-OVER-Booting with /boot/loader
Thanks, Charlie. In [EMAIL PROTECTED] "Charles Anderson" [EMAIL PROTECTED] wrote: C I have a Thinkpad 600X here that I installed freebsd on the third C partition, but couldn't boot because of the 1024 cylinder bit, so C I booted a Fixit floppy mounted my freebsd partitions, installed C this patch, patched boot1 to always try packet mode and copied it C over to the ntfs boot partition and used it from the NT Loader, and C it booted right up, both natively and under VMware. I'll try. This is my first time to use Fixit floppy. :) -- NAKAJI Hiroyuki To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Warnings when linking against libc_r
On Tuesday, March 28, 2000, Bush Doctor wrote: I'm seeing the following diagnostics with applications linked against libc_r ... Do not directly link with libc_r. Instead, use the -pthread gcc flag. It will properly compile and link your program with the correct thread bits. -- |Chris Costello [EMAIL PROTECTED] |I/O, I/O, it's off to work we go... ` To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel trap 9
On Tuesday, March 28, 2000, Wm Brian McCane wrote: Fatal trap 9: general protection fault in kernel mode pointers, etc Why did you remove the vital information needed to track down and fix the problem? -- |Chris Costello [EMAIL PROTECTED] |A paperless office has about as much chance as a paperless bathroom. ` To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UP kernel performance and Matt Dillon's patches
Alfred Perlstein writes: * Gary Jennejohn [EMAIL PROTECTED] [000328 14:04] wrote: I'm running a UP machine with Matt's latest changes. I was just compiling a new kernel and noticed the my PS/2 mouse under X was very sluggish. I never noticed this sort of behavior before the changes, even while doing ``make -j8 buildworld''. The compile was running on a UW SCSI disk on an Adaptec aic7880 Ultra SCSI adapter on my motherboard, in case it matters. Looks like something has been verschlimmbessert (a wonderful German word which means "made worse through improvement" :) This is unlikely as a UP kernel doesn't seem to compile after Matt's changes (no offence Matt, I know you're getting to it), when was the last time you didn't see this sluggish behavior, how are you compiling your kernel? What's your Id line for sys/i386/i386/mplock.s ? Mine is: * $FreeBSD: src/sys/i386/i386/mplock.s,v 1.30 2000/03/28 07:16:15 dillon Exp $ I have * $FreeBSD: src/sys/i386/i386/mplock.s,v 1.31 2000/03/28 18:06:37 dillon Exp $ Matt fixed the bug which was preventing compilng a UP kernel. So I guess it is likely, after all. --- Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UP kernel performance and Matt Dillon's patches
I havn't noticed this behavior... or any other performance hits and I'm running a kernel that was cvsupped about 5 10 minutes ago.. and recompiled about 5 minutes ago... = | Kenneth Culver | FreeBSD: The best OS around.| | 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 Wed, 29 Mar 2000, Gary Jennejohn wrote: Alfred Perlstein writes: * Gary Jennejohn [EMAIL PROTECTED] [000328 14:04] wrote: I'm running a UP machine with Matt's latest changes. I was just compiling a new kernel and noticed the my PS/2 mouse under X was very sluggish. I never noticed this sort of behavior before the changes, even while doing ``make -j8 buildworld''. The compile was running on a UW SCSI disk on an Adaptec aic7880 Ultra SCSI adapter on my motherboard, in case it matters. Looks like something has been verschlimmbessert (a wonderful German word which means "made worse through improvement" :) This is unlikely as a UP kernel doesn't seem to compile after Matt's changes (no offence Matt, I know you're getting to it), when was the last time you didn't see this sluggish behavior, how are you compiling your kernel? What's your Id line for sys/i386/i386/mplock.s ? Mine is: * $FreeBSD: src/sys/i386/i386/mplock.s,v 1.30 2000/03/28 07:16:15 dillon Exp $ I have * $FreeBSD: src/sys/i386/i386/mplock.s,v 1.31 2000/03/28 18:06:37 dillon Exp $ Matt fixed the bug which was preventing compilng a UP kernel. So I guess it is likely, after all. --- Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: periodic daily output (passwd diffs)
On Tue, Mar 28, 2000 at 07:49:23PM +0300, Giorgos Keramidas wrote: At first glimpse, everything seems identical.. so, where is the difference? I realized that I had changed ONLY the password, and this was shown in the diffs in this strange way--since the password is clipped from the output of diff. It's on purpose. The password is masked out for obvious reasons. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DDB and dumping disk
On Tue, 28 Mar 2000, Jeroen Ruigrok van der Werven wrote: Your patch is a step in the right direction. I am currently only trying to figure out why the DDB way doesn't trigger savecore to recognise the dump. Did you try "call setdumpdev(0xf00)" with the proper show disk/ yet? It's probably worth documenting the procedure even if it will be later be replaced with a loader functionality... however, we should still support the way it is now for people who want to get a dump but don't have the ability to use loader(8) fully (Alpha?). -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED] VIA NET.WORKS The Netherlands BSD: Technical excellence at its best http://www.bart.nl How are the mighty fallen... -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Warnings when linking against libc_r
Out of da blue Chris Costello aka ([EMAIL PROTECTED]) said: On Tuesday, March 28, 2000, Bush Doctor wrote: I'm seeing the following diagnostics with applications linked against libc_r ... Do not directly link with libc_r. Instead, use the -pthread gcc flag. It will properly compile and link your program with the correct thread bits. Thanxs Chris. If this was discussed on -current, I apologise for missing the discussion. :( A question why can we not link directly with libc_r? If this was discussed on -current I can look it up in the archives. Looks like gnats will be seeing some send-pr's about this. Thanxs again! -- |Chris Costello [EMAIL PROTECTED] |I/O, I/O, it's off to work we go... ` #;^) -- So ya want ta hear da roots? bush doctor [EMAIL PROTECTED] Of course I run FreeBSD!! http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Dual Pathing to SCSI/FC devices.
Is anyone working on/considering this? I'm about to start hooking FreeBSD boxes up to a *big* disk array which has the ability to make LUNS appear on multiple interfaces. Being able to access LUNS via multiple paths could be a reasonable performance gain, as well as enhancing reliability. Carl. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Strange new ppp warnings
Hi, After upgrading my box to the 4.0-STABLE, I've discovered that ppp started produce regular warnings I've never seen before: Warning: nat_LayerPull: Dropped a packet What does it mean and what implications may it have? This is pretty strange. I've just added a diagnostic to nat_LayerPull(). Can you update your sources (or get the latest archive from my web site in about an hour) and tell me what return value it's receiving ? The error shouldn't happen -Maxim Thanks. -- 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: Dual Pathing to SCSI/FC devices.
Yes, we very much has considered this. What's your issue about this, per se? Right now there's no framework code to directly exploit or prohibit multiple paths to the same disk, whether via Fibre Channel or SCSI. On Wed, 29 Mar 2000, Carl Makin wrote: Is anyone working on/considering this? I'm about to start hooking FreeBSD boxes up to a *big* disk array which has the ability to make LUNS appear on multiple interfaces. Being able to access LUNS via multiple paths could be a reasonable performance gain, as well as enhancing reliability. Carl. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: periodic daily output (passwd diffs)
At 6:33 PM -0500 3/28/00, Thimble Smith wrote: On Tue, Mar 28, 2000 at 07:49:23PM +0300, Giorgos Keramidas wrote: At first glimpse, everything seems identical.. so, where is the difference? I realized that I had changed ONLY the password, and this was shown in the diffs in this strange way--since the password is clipped from the output of diff. It's on purpose. The password is masked out for obvious reasons. yes, but it would be nice if the masking out process noticed if a password changed, and did something like "(oldpw)" "(newpw)" when masking out lines with password changes. (the literal strings, "oldpw" and "newpw"...). my guess is that's easier said than done, but still it would be nice if it WERE done... :-) --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Major # please :)
I am just about finished with a device driver for PCI DIO boards based around the 8C255 (number may be wrong ;). Specifically this is for the ComputerBoards DIO-24H DIO board. I have been using the 'development' major #, and I am ready to go about getting it committed into the CVS tree for whoever else may find it of use. Currently the system is used in conjunction with a home-brew card-access system, but future could include robotics and related fields. Thank you -- David Cross | email: [EMAIL PROTECTED] Acting Lab Director | NYSLP: FREEBSD Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dual Pathing to SCSI/FC devices.
Hi Matthew, On Tue, 28 Mar 2000, Matthew Jacob wrote: Yes, we very much has considered this. What's your issue about this, per se? Well, the driver for asking was my management asking if FreeBSD supported this, as we're going to do it on AIX (with the Dual Pathing Option) and with Solaris (running Veritas which I need to investigate more). We're reasonably big on redundancy here and we're running a number of critical systems on FreeBSD (DNS, WINS, DHCP, primary webserver, PDF server, etc). Right now there's no framework code to directly exploit or prohibit multiple paths to the same disk, whether via Fibre Channel or SCSI. Ok, but I suspect it would get a trifle upset if I started duplicating LUNS. :) I really don't know how much work this would be but would be interested in helping. I'm not a kernel hacker but I can offer testing resources (well, in about a month or so when the box arrives) for SCSI and possibly Fibre Channel if someone has code. Carl. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Warnings when linking against libc_r
In message [EMAIL PROTECTED] Bush Doctor writes: : I'm seeing the following diagnostics with applications linked against libc_r Don't link against -lc_r. Use -pthread. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dual Pathing to SCSI/FC devices.
On Tue, 28 Mar 2000, Matthew Jacob wrote: Yes, we very much has considered this. What's your issue about this, per se? Well, the driver for asking was my management asking if FreeBSD supported this, as we're going to do it on AIX (with the Dual Pathing Option) and with Solaris (running Veritas which I need to investigate more). We're reasonably big on redundancy here and we're running a number of critical systems on FreeBSD (DNS, WINS, DHCP, primary webserver, PDF server, etc). Umm, okay. Is this with Veritas DMP or VCS? Right now there's no framework code to directly exploit or prohibit multiple paths to the same disk, whether via Fibre Channel or SCSI. Ok, but I suspect it would get a trifle upset if I started duplicating LUNS. :) I really don't know how much work this would be but would be interested in helping. No, it wouldn't get upset, but it wouldn't know to not get upset either :-). Formally speaking, the current non-cognizant arrangement of FreeBSD would be an active-active configuration. If you use Greg Lehey's VINUM in FreeBSD, I'm not clear about what it's role in terms of recognizing redundant paths might be, but other than that there are no particular volume or spindle identification restrictions that could cause an upset. The CAM midlayer does track Vital Product Data (like drive serial numbers), but this is put together with a bus address (e.g, HBA, bus on HBA, target, lun) to track whether particular device has changed at that location or not- not whether that particular spindle is replicated elsewhere. I'm not a kernel hacker but I can offer testing resources (well, in about a month or so when the box arrives) for SCSI and possibly Fibre Channel if someone has code. Absolutely. I mean, we do have a supported Fibre Channel card (Qlogic 2100 and Qlogic 2200), but not as much testing as one would like. You should note that there isn't, for fibre channel, any particular address wiring enforced except by that which the target device does (e.g., if the target does hard loop addressing). I've been mulling over some persistent device attribute stuff for the next round of changes (e.g., binding a particular WWN to a particular 'target'), probably stored in card NVRAM, and I've had on my 'futures' list a 'WWN' extension to devfs, but this is all futures. Let me know if this is enough info to help. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Major # please :)
Meaning no offense, but I can't think of a single good reason to write a device driver for one of these cards. (Unless you're trying to do pattern generation, and an 8255 is a terrible choice for that.) Worse than that though, there's _no_ standard for these cards' implementation, so a driver isn't going to be even vageuly portable. Use i386_set_ioperm() and just bit-bash it in userspace. I am just about finished with a device driver for PCI DIO boards based around the 8C255 (number may be wrong ;). Specifically this is for the ComputerBoards DIO-24H DIO board. I have been using the 'development' major #, and I am ready to go about getting it committed into the CVS tree for whoever else may find it of use. Currently the system is used in conjunction with a home-brew card-access system, but future could include robotics and related fields. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Major # please :)
Meaning no offense, but I can't think of a single good reason to write a device driver for one of these cards. (Unless you're trying to do pattern generation, and an 8255 is a terrible choice for that.) Worse than that though, there's _no_ standard for these cards' implementation, so a driver isn't going to be even vageuly portable. Use i386_set_ioperm() and just bit-bash it in userspace. The bit-bashing in userspace will make this even less portable. The idea is liked by those around here of being able to do a 'set register 0', or 'clear register 0' with an ioctl() and leaving the implementation to "something else", which can key on what type of board it is and DtRT. Also, how would you trap interrupts from such a card (for when using it as a digital input) from userland? Since it is already written, and in operation. Unless we are low on major numbers, or this could be better merged with another interface, it seems to be a waste to not give it a major number. Bringing it into the base CVS tree is another question entirely, but it would appear at least one has already expressed an interest. BTW: the URL for the card that was given to me for this project is at: http://www.computerboards.com/cbicatalog/cbiproduct.asp?dept%5Fid=224pf%5Fid=668mscssid=50A6V97GWTSH2J6N000JU4JKRUFAAEGB Product descriptions and a technical manual are linked from that page. -- David Cross | email: [EMAIL PROTECTED] Acting Lab Director | NYSLP: FREEBSD Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current.freebsd.org ftp misconfig ?
Good luck getting an answer. Nobody seems willing to answer this question. :( Tom Veldhouse [EMAIL PROTECTED] On Tue, 28 Mar 2000, James FitzGibbon wrote: 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UP kernel performance and Matt Dillon's patches
:I'm running a UP machine with Matt's latest changes. I was just :compiling a new kernel and noticed the my PS/2 mouse under X was very :sluggish. I never noticed this sort of behavior before the changes, :even while doing ``make -j8 buildworld''. : :The compile was running on a UW SCSI disk on an Adaptec aic7880 Ultra :SCSI adapter on my motherboard, in case it matters. : :Looks like something has been verschlimmbessert (a wonderful German :word which means "made worse through improvement" :) : : :Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Ok, I'll take a look at it... the most likely cause is that I somehow broke need_resched. Not impossible, I'll check it out. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UP kernel performance and Matt Dillon's patches
On Tue, Mar 28, 2000 at 11:37:55PM +0200, Gary Jennejohn wrote: I'm running a UP machine with Matt's latest changes. I was just compiling a new kernel and noticed the my PS/2 mouse under X was very sluggish. I never noticed this sort of behavior before the changes, even while doing ``make -j8 buildworld''. The compile was running on a UW SCSI disk on an Adaptec aic7880 Ultra SCSI adapter on my motherboard, in case it matters. Looks like something has been verschlimmbessert (a wonderful German word which means "made worse through improvement" :) I have noticed this too. Except on an SMP kernel with IDE drives. My keyboard is lagging in the same manner with high cpu loads. Abit bp6 + 2xceleron 500 IBM DJNA 13.5gig drive on the HPT366 -Chris -- [EMAIL PROTECTED] [EMAIL PROTECTED] Abbotsford, BC, Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP kernel broken at cvsup Tue Mar 28 11:56:07 BST 2000
:At 09:52 -0800 28/3/00, Matthew Dillon wrote: :Make sure you haven't confused it between the patch set and the :commit I made last night. Do a cvs update and then a cvs diff to :make sure things haven't gotten confused. : :Just blew /sys away and checked it out afresh. Same result I'm afraid, :although I did get into DDB this time. Nothing obviously wrong, but the :backtrace didn't go back past the keyboard interrupt. : :-- :Bob Bishop (0118) 977 4017 international code +44 118 :[EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK Hmm. If you can get into DDB, type 'ps'. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs repository nits and gnats
In article [EMAIL PROTECTED], Doug Barton [EMAIL PROTECTED] wrote: Slightly more serious was the presence of various lock files/directories. Specifically, one in src/games/primes killed my co as an unpriviliged user because it was set 700 and owned by root. The co failed because it couldn't create a lock file. I did a 'find . -name \*\#\* in my CVSROOT and found several other files like this. Deleting them did no harm, and they didn't return when I ran cvsup again. I havent seen this. My gut feeling is that it's a timing issue. I happened to have been cvsup'ing when someone actually had a lock on something in the repository. Still I think it's odd that A) the cvsup "mirrors" of the master repository picked up these files, B) that my cvsup of the repository picked them up, and C) having picked them up, it didn't delete them when they were deleted from the real respository. FWIW, I always use cvsup7, and I found these lock files in both my home and work copies. I think you may be misinterpreting the symptoms, because I don't know of any way for lock files to propagate off of freefall with CVSup. All lock files are specifically excluded in the server's config files -- they won't even make it to cvsup-master, let alone to the mirrors such as cvsupN.freebsd.org. What were the names of the files you thought were lock files? It sounds to me like maybe they were created by something on your local system -- not mirrored via CVSup. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Very weird assembly failure (was Re: UP kernel performance and Matt Dillon's patches)
I found a couple of minor nits, but only one real bug. In i386/swtch.s I forgot to change out a WANT_RESCHED for AST_RESCHED: sw1a: call_chooseproc /* trash ecx, edx, ret eax*/ testl %eax,%eax CROSSJUMP(je, _idle, jne) /* if no proc, idle */ movl%eax,%ecx xorl%eax,%eax andl$~WANT_RESCHED,_astpending The problem is that a kernel build is not reporting any errors! WANT_RESCHED does not exist at all, anywhere. If I change it to a garbage name the kernel still builds. I don't get it. In anycase, please try changing WANT_RESCHED to AST_RESCHED in i386/i386/swtch.s and see if that fixes the reported performance problems. If WANT_RESCHED defaults to 0 by being undefined, then the reschedule flag is never cleared when a context switch is made and this could certainly lead to problems. I also found a movb that had to be a movl, but since only the low bits were being used anyway this would not have caused any problems. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UP kernel performance and Matt Dillon's patches
Matthew Dillon writes : :I'm running a UP machine with Matt's latest changes. I was just :compiling a new kernel and noticed the my PS/2 mouse under X was very :sluggish. I never noticed this sort of behavior before the changes, :even while doing ``make -j8 buildworld''. : :The compile was running on a UW SCSI disk on an Adaptec aic7880 Ultra :SCSI adapter on my motherboard, in case it matters. : :Looks like something has been verschlimmbessert (a wonderful German :word which means "made worse through improvement" :) : : :Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Ok, I'll take a look at it... the most likely cause is that I somehow broke need_resched. Not impossible, I'll check it out. I'm seeing the same symptoms while doing a make - my console performance is very jumpy and sluggish. Geoff. -- Geoff Rehmet, The Internet Solution [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] tel: +27-83-292-5800 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dual Pathing to SCSI/FC devices.
On Tue, 28 Mar 2000, Matthew Jacob wrote: Umm, okay. Is this with Veritas DMP or VCS? Good question. DMP I think. I'm not sure what VCS is. an active-active configuration. If you use Greg Lehey's VINUM in FreeBSD, I'm not clear about what it's role in terms of recognizing redundant paths might There doesn't seem much point in using VINUM with an external RAID5 box (although we use VINUM a lot on other machines). identification restrictions that could cause an upset. The CAM midlayer does track Vital Product Data (like drive serial numbers), but this is put together with a bus address (e.g, HBA, bus on HBA, target, lun) to track whether particular device has changed at that location or not- not whether that particular spindle is replicated elsewhere. Would it be hard to add intelligence to this layer that would detect if a drive (via it's VPD info) is visible on multiple busses? If so is there a point in CAM where it could be modified to handle, at the minimum, a redundant path or better yet, use multiple paths to a device? The box to which I'm hooking this up has sufficient performance to handle 16 U2W SCSI links running hard. Being able to utilise multiple paths could be a big performance win. Absolutely. I mean, we do have a supported Fibre Channel card (Qlogic 2100 and Qlogic 2200), but not as much testing as one would like. I have a Qlogic 2200 on order to test this out. You should note that there isn't, for fibre channel, any particular address wiring enforced except by that which the target device does (e.g., if the Would this be similar to the situation that we had with FreeBSD before you could wire down devices? Let me know if this is enough info to help. I'm getting a little beyond my depth in CAM internals here. But it is *very* interesting. :) Thanks, Carl. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Very weird assembly failure (was Re: UP kernel performance and Matt Dillon's patches)
On Tue, Mar 28, 2000 at 07:48:00PM -0800, Matthew Dillon wrote: I found a couple of minor nits, but only one real bug. In i386/swtch.s I forgot to change out a WANT_RESCHED for AST_RESCHED: The problem is that a kernel build is not reporting any errors! WANT_RESCHED does not exist at all, anywhere. If I change it to a garbage name the kernel still builds. I don't get it. In anycase, please try changing WANT_RESCHED to AST_RESCHED in i386/i386/swtch.s and see if that fixes the reported performance problems. If WANT_RESCHED defaults to 0 by being undefined, then the reschedule flag is never cleared when a context switch is made and this could certainly lead to problems. Changing it to AST_RESCHED did not fix the problem for me. -Chris -- [EMAIL PROTECTED] [EMAIL PROTECTED] Abbotsford, BC, Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Very weird assembly failure (was Re: UP kernel performance and Matt Dillon's patches)
: problems. If WANT_RESCHED defaults to 0 by being undefined, then : the reschedule flag is never cleared when a context switch is made : and this could certainly lead to problems. : :Changing it to AST_RESCHED did not fix the problem for me. : :-Chris Ok. I'm seeing the same behavior here too over an ssh link. I'm pretty sure I broke need_resched and the processes are incorrectly getting too much cpu in the face of a wakeup. I just have to find out where. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UP kernel performance and Matt Dillon's patches
Yeah, I was wrong before.. I just had to really hit the system hard before I noticed this behavior... it get's pretty bad... the mouse get's jumpy, and the keyboard input is really slow... = | Kenneth Culver | FreeBSD: The best OS around.| | 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 Wed, 29 Mar 2000, Geoff Rehmet wrote: Matthew Dillon writes : :I'm running a UP machine with Matt's latest changes. I was just :compiling a new kernel and noticed the my PS/2 mouse under X was very :sluggish. I never noticed this sort of behavior before the changes, :even while doing ``make -j8 buildworld''. : :The compile was running on a UW SCSI disk on an Adaptec aic7880 Ultra :SCSI adapter on my motherboard, in case it matters. : :Looks like something has been verschlimmbessert (a wonderful German :word which means "made worse through improvement" :) : : :Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Ok, I'll take a look at it... the most likely cause is that I somehow broke need_resched. Not impossible, I'll check it out. I'm seeing the same symptoms while doing a make - my console performance is very jumpy and sluggish. Geoff. -- Geoff Rehmet, The Internet Solution [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] tel: +27-83-292-5800 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
New SMP changes
I just noticed something with a new kernel with a Fresh world as of 1 hour ago. I'm running 2 setiathome's one for each CPU (Pentium pro) and the machine has suddenly turned into a slug It's worse than a 286 machine I used to own. It's amazing !!! It worked with this setup before the changes fine and if I kill the setiathome's everything is back to normal. Top: PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 539 nobody 66 1 15092K 14336K CPU1 1 0:45 97.87% 90.62% setiathome 536 nobody -6 1 15092K 14336K RUN0 0:50 97.45% 90.23% setiathome I did a make world with the new changes an it worked fine. I running setiathome version 2 Manfred = ||[EMAIL PROTECTED] || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dual Pathing to SCSI/FC devices.
On Tue, 28 Mar 2000, Matthew Jacob wrote: Umm, okay. Is this with Veritas DMP or VCS? Good question. DMP I think. I'm not sure what VCS is. Veritas Cluster Server an active-active configuration. If you use Greg Lehey's VINUM in FreeBSD, I'm not clear about what it's role in terms of recognizing redundant paths might There doesn't seem much point in using VINUM with an external RAID5 box (although we use VINUM a lot on other machines). Well, you get volume (plex) identification out of it, which is of help when you don't want to try and keep track of where disks end up over time manually. identification restrictions that could cause an upset. The CAM midlayer does track Vital Product Data (like drive serial numbers), but this is put together with a bus address (e.g, HBA, bus on HBA, target, lun) to track whether particular device has changed at that location or not- not whether that particular spindle is replicated elsewhere. Would it be hard to add intelligence to this layer that would detect if a drive (via it's VPD info) is visible on multiple busses? If so is there a point in CAM where it could be modified to handle, at the minimum, a redundant path or better yet, use multiple paths to a device? The box to which I'm hooking this up has sufficient performance to handle 16 U2W SCSI links running hard. Being able to utilise multiple paths could be a big performance win. You can indeed add intelligence, but it's a very wide open question how and where the intelligence should be used. And the "why" is of importance as well. You essentially need to coordiante object and path identification with volume and filesystem usage. Right now there's no problem about having multiple paths to the same disk- the only piece that's really missing is some moderately easy method to export this information out of any specific layer- but this isn't that hard to do, and could, in fact, be done via a user daemon without any kernel modifications, so I don't view this as a hard problem. What's harder is *how* to use it. There are no particular hooks in FFS to handle the multiple paths simultaneously with any coherency (for performance reasons, should you want to do so and could prove that it'd be worthwhile), nor are there any particular hooks that I'm aware of to do dynamic multipathing for failover reasons at the volume or device level- if there were in FreeBSD, I suspect VINUM in conjunction with a completed DEVVS might be the place for them, but that's just random speculation on my part. Absolutely. I mean, we do have a supported Fibre Channel card (Qlogic 2100 and Qlogic 2200), but not as much testing as one would like. I have a Qlogic 2200 on order to test this out. Good! You'll find that this is better with respect to full fabric support if you happen to have, e.g., a Brocade switch on order. You should note that there isn't, for fibre channel, any particular address wiring enforced except by that which the target device does (e.g., if the Would this be similar to the situation that we had with FreeBSD before you could wire down devices? Yes, somewhat, but not quite as bad. Let me know if this is enough info to help. I'm getting a little beyond my depth in CAM internals here. But it is *very* interesting. :) Thanks, You're welcome. Lemme know how it goes. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Newbie question...
Hi, I'm just starting to work with FreeBSD-Current so I can add some software back into the mix. I've read the handbook, and the FAQ (and I've been a Unix, and Real Time developer for many years so I'm not new to programming) but I have a few questions that don't seem to be in the documentation: 1) How do I do development and not overwrite my work when cvsup'ing? 2) How do I know when cvsuping will NOT trash my current setup? It would be cool if a "last known good source tree" were stored somewhere. I ask this because I sup'd this morning and got toasted and had to sup/build again. 3) Is there a guide on using CVS with CVSup (the man page is not particularly helpful) so that I can have a CVS tree that is updated by cvsup? Thanks, George To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Reading from bad disk ?
It seems Warner Losh wrote: ... mount it in front of the drive to get it to run at a reasonable temperature. W/o the fan, it was running at 58C or so. With the fan it runs at 39C or so. I've included the script that I use to find this information out. Ken Merry sent it to me. It works on some IBM drives. Warner #!/bin/sh TEMPC=`camcontrol cmd -v -n da -u 0 -c "4D 0 76 0 0 0 0 0 20 0" -i 32 "s9 i1"` TEMPF=`echo " 2 k $TEMPC 9 * 5 / 32 + p" | dc` echo "The temperature is: $TEMPF F $TEMPC C" Tried this: #!/bin/sh TEMPC=`camcontrol cmd -v -n da -u 2 -c "4D 0 76 0 0 0 0 0 20 0" -i 32 "s9 i1"` TEMPF=`echo " 2 k $TEMPC 9 * 5 / 32 + p" | dc` echo "The temperature is: $TEMPF F $TEMPC C" I.e. replaced -u 0 with -u 2, because unit 2 is an IBM: ncr0: ncr 53c810 fast10 scsi port 0xd100-0xd1ff mem 0x2000-0x20ff irq 11 at device 1.0 on pci0 ncr0: driver is using old-style compatability shims da1 at ncr0 bus 0 target 1 lun 0 da0 at ncr0 bus 0 target 0 lun 0 da2 at ncr0 bus 0 target 2 lun 0 da2: IBM DCAS-34330 S65A Fixed Direct Access SCSI-2 device da2: 10.000MB/s transfers (10.000MHz, offset 8) da2: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) But I get this: camcontrol: error sending command (pass2:ncr0:0:2:0): LOG SENSE. CDB: 4d 0 76 0 0 0 0 0 20 0 (pass2:ncr0:0:2:0): ILLEGAL REQUEST asc:24,0 (pass2:ncr0:0:2:0): Invalid field in CDB dc: stack empty The temperature is: 33.80 F C Does this simply mean this drive does not support temperature measurement, or should something more be changed to use dev da2 instead of da0? I'm running a week or so old current. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sound broken on ViBRA16X?
with a recently compiled kernel (cvsupped about 5 minutes ago..) sounds play for less than half a second... then just completely stop... Maybe this is related to Matt Dillon's recent work? I'm not sure... = | Kenneth Culver | FreeBSD: The best OS around.| | 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/| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Strange new ppp warnings
Brian Somers wrote: Hi, After upgrading my box to the 4.0-STABLE, I've discovered that ppp started produce regular warnings I've never seen before: Warning: nat_LayerPull: Dropped a packet What does it mean and what implications may it have? This is pretty strange. I've just added a diagnostic to nat_LayerPull(). Can you update your sources (or get the latest archive from my web site in about an hour) and tell me what return value it's receiving ? Ok, here it is using latest libalias and ppp from -current just compiled with safe -O optimisation. Warning: nat_LayerPull: Dropped a packet (2) -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Vibra16x
OK, I'm not sure what was wrong before, but after a recompile of the kernel, all seems well again with sound at least. = | Kenneth Culver | FreeBSD: The best OS around.| | 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/| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sound broken on ViBRA16X?
On Wed, Mar 29, 2000 at 02:05:17AM -0500, Kenneth Wayne Culver wrote: with a recently compiled kernel (cvsupped about 5 minutes ago..) sounds play for less than half a second... then just completely stop... Maybe this is related to Matt Dillon's recent work? I'm not sure... I doubt it; I've been unable to use anything but the mixer with my ViBRA16X for several months. It works in 3.4, but not in 4.0 (and, I guess, 5.0). Here's my previous messages about this, in case you're interested: http://marc.theaimsgroup.com/?m=95048589613417 http://marc.theaimsgroup.com/?m=95078238528385 Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UP kernel performance and Matt Dillon's patches
: :Yeah, I was wrong before.. I just had to really hit the system hard before :I noticed this behavior... it get's pretty bad... the mouse get's jumpy, :and the keyboard input is really slow... : := :| Kenneth Culver | FreeBSD: The best OS around.| I definitely blew the need_resched stuff. I found it. I was clearing the 'astpending' variable in doreti, which used to be just fine, but now that we have two flags in it instead of one it was clearing the need-resched flag bit as well as the astpending flag bit. If you don't want to wait, here it is (it's really the last bit that fixes the problem. The first two bits are incidental). I've committed the fix. I would appreciate others testing it as well. It seems to solve the problem I was able to reproduce on my systems. Index: isa/ipl.s === RCS file: /home/ncvs/src/sys/i386/isa/ipl.s,v retrieving revision 1.33 diff -u -r1.33 ipl.s --- isa/ipl.s 2000/03/28 07:16:23 1.33 +++ isa/ipl.s 2000/03/29 06:00:29 @@ -123,10 +123,10 @@ andl_ipending,%ecx /* set bit = unmasked pending INT */ jne doreti_unpend movl%eax,_cpl - MPLOCKED decb _intr_nesting_level + decb_intr_nesting_level /* Check for ASTs that can be handled now. */ - cmpb$0,_astpending + cmpl$0,_astpending je doreti_exit testb $SEL_RPL_MASK,TF_CS(%esp) jne doreti_ast @@ -271,7 +271,7 @@ ALIGN_TEXT doreti_ast: - movl$0,_astpending + andl$~AST_PENDING,_astpending sti movl$T_ASTFLT,TF_TRAPNO(%esp) call_trap To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs repository nits and gnats
John Polstra wrote: [My silly speculation about cvs lockfiles and cvsup deleted] I think you may be misinterpreting the symptoms, That's entirely possible. because I don't know of any way for lock files to propagate off of freefall with CVSup. All lock files are specifically excluded in the server's config files -- they won't even make it to cvsup-master, let alone to the mirrors such as cvsupN.freebsd.org. What were the names of the files you thought were lock files? It sounds to me like maybe they were created by something on your local system -- not mirrored via CVSup. Well, I don't make any commits to this cvs tree, only checkouts. Unfortunately I didn't save the filename of any of the really incriminating files. The one that killed my checkout was a directory in src/games/primes. I also found these files in the logs I did keep, from the /usr/src that was checked out with cvsup, not cvs: -rw-r- 1 root wheel7.0k Mar 22 09:55 .#Makefile.1.232 -rw-r- 1 root wheel 23k Mar 8 22:28 .#Makefile.inc1.1.120 -rw-r- 1 root wheel 24k Mar 24 12:21 .#UPDATING.1.58 I also found this file in my CVSROOT on one of my repositories: ./sup/src-all/#cvs.cvsup-749.0 It's actually dated March 24 1998, which predates the creation of this repository. Hrrrmm Aha! Part of the mystery solved at least. I started this repository from the snapshot CD dated 7/5/99. I just untarred that repository snapshot into a new directory and found the above file, and the lock directory I mentioned earlier: drwxr-x--- 2 doug wheel 512 Jul 30 1999 ./src/games/primes/#cvs.rfl.scratch1.cdrom.com.381 -rw-r- 1 doug wheel2.0M Mar 24 1998 ./sup/src-all/#cvs.cvsup-749.0 In any case, my purpose for posting was to notify the PTB in case there was a problem. If anyone is qualified to state categorically that there is no problem it's probably you. :) The actual lock directory above was my chief concern, and now that I know I didn't inherit it from cvsup, I'm happy. Thanks for taking the time to help me learn... Doug -- "So, the cows were part of a dream that dreamed itself into existence? Is that possible?" asked the student incredulously. The master simply replied, "Mu." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
