ld-elf.so.1 broken with world from yesterday

2002-04-08 Thread Alexander Leidinger

Hi,

yesterday I've made a new world. After booting it, ld-elf-so.1 complains 
about every library (libc, libutil, ...). My -current is not usable 
anymore because of this.

Is this fixed in a recent snapshot, and if yes, is it enough to just 
replace ld-elf.so.1, or do I have to replace /usr/lib/ (too) to get a 
working -current?

Bye,
Alexander.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



i386 tinderbox failure

2002-04-08 Thread Dag-Erling Smorgrav

=== nge
=== nmdm
=== ntfs
=== nullfs
=== pcn
=== plip
=== portalfs
=== ppbus
=== ppi
=== pps
=== procfs
=== pseudofs
=== random
=== rl
=== rp
=== sf
=== sis
=== sk
=== sn
=== snp
=== sound
=== sound/pcm
=== sound/driver
=== sound/driver/als4000
=== sound/driver/ad1816
=== sound/driver/cmi
=== sound/driver/cs4281
=== sound/driver/csa
=== sound/driver/ds1
=== sound/driver/emu10k1
=== sound/driver/es137x
=== sound/driver/ess
=== sound/driver/fm801
=== sound/driver/ich
=== sound/driver/maestro
=== sound/driver/maestro3
=== sound/driver/mss
=== sound/driver/neomagic
=== sound/driver/sb16
=== sound/driver/sb8
=== sound/driver/sbc
=== sound/driver/solo
=== sound/driver/t4dwave
=== sound/driver/via82c686
=== sound/driver/vibes
=== sound/driver/driver
=== sppp
=== ste
=== sym
=== syscons
=== syscons/blank
=== syscons/daemon
=== syscons/dragon
=== syscons/fade
=== syscons/fire
=== syscons/green
=== syscons/logo
=== syscons/rain
=== syscons/snake
=== syscons/star
=== syscons/warp
=== syscons/apm
=== sysvipc
=== sysvipc/sysvmsg
=== sysvipc/sysvsem
=== sysvipc/sysvshm
=== ti
=== tl
=== twe
=== tx
=== txp
=== ucom
=== udbp
=== ufm
=== ugen
=== uhid
=== ukbd
=== ulpt
=== umapfs
=== umass
=== umodem
=== ums
=== unionfs
/d/home/des/tinderbox/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:58: 
vm/vm_zone.h: No such file or directory
mkdep: compile failed
*** Error code 1

Stop in /d/home/des/tinderbox/src/sys/modules/unionfs.
*** Error code 1

Stop in /d/home/des/tinderbox/src/sys/modules.
*** Error code 1

Stop in /tmp/des/obj/i386/d/home/des/tinderbox/src/sys/GENERIC.
*** Error code 1

Stop in /d/home/des/tinderbox/src.
*** Error code 1

Stop in /d/home/des/tinderbox/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: i386 tinderbox failure

2002-04-08 Thread Poul-Henning Kamp


Allerede fixet.

In message [EMAIL PROTECTED], Dag-Erling Smorgrav 
writes:
=== nge
=== nmdm
=== ntfs
=== nullfs
=== pcn
=== plip
=== portalfs
=== ppbus
=== ppi
=== pps
=== procfs
=== pseudofs
=== random
=== rl
=== rp
=== sf
=== sis
=== sk
=== sn
=== snp
=== sound
=== sound/pcm
=== sound/driver
=== sound/driver/als4000
=== sound/driver/ad1816
=== sound/driver/cmi
=== sound/driver/cs4281
=== sound/driver/csa
=== sound/driver/ds1
=== sound/driver/emu10k1
=== sound/driver/es137x
=== sound/driver/ess
=== sound/driver/fm801
=== sound/driver/ich
=== sound/driver/maestro
=== sound/driver/maestro3
=== sound/driver/mss
=== sound/driver/neomagic
=== sound/driver/sb16
=== sound/driver/sb8
=== sound/driver/sbc
=== sound/driver/solo
=== sound/driver/t4dwave
=== sound/driver/via82c686
=== sound/driver/vibes
=== sound/driver/driver
=== sppp
=== ste
=== sym
=== syscons
=== syscons/blank
=== syscons/daemon
=== syscons/dragon
=== syscons/fade
=== syscons/fire
=== syscons/green
=== syscons/logo
=== syscons/rain
=== syscons/snake
=== syscons/star
=== syscons/warp
=== syscons/apm
=== sysvipc
=== sysvipc/sysvmsg
=== sysvipc/sysvsem
=== sysvipc/sysvshm
=== ti
=== tl
=== twe
=== tx
=== txp
=== ucom
=== udbp
=== ufm
=== ugen
=== uhid
=== ukbd
=== ulpt
=== umapfs
=== umass
=== umodem
=== ums
=== unionfs
/d/home/des/tinderbox/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:58: 
vm/vm_zone.h: No such file or directory
mkdep: compile failed
*** Error code 1

Stop in /d/home/des/tinderbox/src/sys/modules/unionfs.
*** Error code 1

Stop in /d/home/des/tinderbox/src/sys/modules.
*** Error code 1

Stop in /tmp/des/obj/i386/d/home/des/tinderbox/src/sys/GENERIC.
*** Error code 1

Stop in /d/home/des/tinderbox/src.
*** Error code 1

Stop in /d/home/des/tinderbox/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Kernel debugging - what's the procedure?

2002-04-08 Thread Josef Karthauser

On Sun, Apr 07, 2002 at 01:54:08PM -0700, Terry Lambert wrote:
 Josef Karthauser wrote:
   You use another machine, and connect the serial ports together.
   See the handbook for details.
  
  I'd love to ;) but no additional machine is available at the moment.
 
 Then you install vmware, and Julian's back-to-back serial
 driver, and then run the kernel to be debuged in the vmware
 session.  This lets you debug the kernel on a virtual
 machine (single CPU only).

Yes I do have vmware, but it's not going to help me debug the usb stack
is it?  (I know vmware3 does usb, but not if the underlying usb stack on
the host machine is also hosed).
 
   If this is against a dead kernel, etiher your dump image is
   bad, or it doesn't match the kernel that made the dump.
  
  That's what I'd guess too, but the kernel that crashed is the same as
  the kernel that I'm debugging it on - I'm pretty sure: compiled today.
 
 Well, since this is the -current list... have you updated
 recently?  There were some recent changes by PHK to the dump
 format that may have broken/fixed things, if your answer to
 that question is yes/no, respectively.

Yes, that's what I implied by the above paragraph.  I was up-to-date
with sources yesterday.

Joe



msg37087/pgp0.pgp
Description: PGP signature


Re: Problem with FreeBSD dc driver and Xircom PCMCIA card

2002-04-08 Thread Georg-W. Koltermann

Ah, finally someone else sees what I ran into last year.  Look for my
posting to -current in May 2001, subject dc0 ARP problem with CISCO.

At that time, the only advice I got was to hardwire speed detection 
(which didn't help). My solution then was to switch hardware :-(
So I'm afraid this is of no help to you, except for the mee too
confirmation.

--
Regards,
Georg.


Am Mi, 2002-03-27 um 21.47 schrieb Gavin Atkinson:
 
 [...snip...]
 It's starting to look promising. I even get a (red) link light on the
 card, and once an IP is configured, ifconfig can tell if the link exists
 or not, though cannot establish what the speed of it is (this is into a
 100M switch).  However, I still have almost no network connectivity with
 it.  An outbound ping loses 100% of packets, and hosts trying to ping it
 cannot arp it's MAC address. However, once I have forced an entry into the
 arp table of the second host, I can ping the Xircom card, albeit very
 slowly (snipped down for clarity):
 
 PING epsilon.ury.york.ac.uk (10.0.0.109): 56 data bytes
 64 bytes from 10.0.0.109: icmp_seq=211 ttl=64 time=2020.368 ms
 64 bytes from 10.0.0.109: icmp_seq=216 ttl=64 time=3030.348 ms
 64 bytes from 10.0.0.109: icmp_seq=217 ttl=64 time=2020.406 ms
 64 bytes from 10.0.0.109: icmp_seq=223 ttl=64 time=2020.374 ms
 64 bytes from 10.0.0.109: icmp_seq=229 ttl=64 time=2020.374 ms
 64 bytes from 10.0.0.109: icmp_seq=253 ttl=64 time=7070.335 ms
 64 bytes from 10.0.0.109: icmp_seq=255 ttl=64 time=5050.412 ms
 64 bytes from 10.0.0.109: icmp_seq=286 ttl=64 time=6060.318 ms
 64 bytes from 10.0.0.109: icmp_seq=287 ttl=64 time=5050.348 ms
 64 bytes from 10.0.0.109: icmp_seq=288 ttl=64 time=4040.382 ms
 --- epsilon.ury.york.ac.uk ping statistics ---
 311 packets transmitted, 139 packets received, 55% packet loss
 round-trip min/avg/max/stddev = 614.382/5760.691/9090.237/2161.803 ms
 
 Note the large mean time, and the fact that I consistantly lose 55% of
 packets. Watching the link light, the card seems to receive the packets
 instantly, buffer three or four, then lose the link. WHen the link comes
 back, the replies to these packets all get sent back at once.
 
 I'm now at a loss as to where to go. I have no idea how to progress with
 this, as i'm not a kernel hacker. Has anyone seen this before? If it
 helps, I am using revision 3 of the card (read using
 pci_read_config(dev, DC_PCI_CFRV, 4)  0xff), and it's on a Toshiba ToPIC
 95B cardbus bridge.
 
 If anyone can help, i'd be most greatful...
 
 Thanks,
 
 Gavin
 
 
 
 
 
 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: cvs commit: src/lib/libpam/modules/pam_unix pam_unix.c

2002-04-08 Thread Ruslan Ermilov

On Sun, Apr 07, 2002 at 01:43:27PM -0700, Dag-Erling Smorgrav wrote:
 des 2002/04/07 13:43:27 PDT
 
   Modified files:
 lib/libpam/modules/pam_unix pam_unix.c 
   Log:
   Fix bug in previous commit that passed the wrong default value to
   login_getcapstr(3).  Also fix a longer-standing bug (login_close(3)
   frees the string returned by login_getcapstr(3)) by reorganizing the
   code a little, and use login_getpwclass(3) instead of login_getclass(3)
   if we already have a struct pwd.
   
   Sponsored by:   DARPA, NAI Labs
   
   Revision  ChangesPath
   1.29  +8 -6  src/lib/libpam/modules/pam_unix/pam_unix.c
 
This change also broke the Password: prompt.  The bug is hidden by
the -Wno-uninitialized setting in bsd.sys.mk.  Here's the patch:

%%%
Index: pam_unix.c
===
RCS file: /home/ncvs/src/lib/libpam/modules/pam_unix/pam_unix.c,v
retrieving revision 1.28
diff -u -p -r1.28 pam_unix.c
--- pam_unix.c  6 Apr 2002 19:30:04 -   1.28
+++ pam_unix.c  8 Apr 2002 09:53:12 -
@@ -122,7 +122,8 @@ pam_sm_authenticate(pam_handle_t *pamh, 
struct passwd *pwd;
int retval;
const char *pass, *user;
-   char *encrypted, *password_prompt;
+   char *encrypted;
+   const char *password_prompt;
 
pam_std_option(options, other_options, argc, argv);
 
@@ -141,7 +142,7 @@ pam_sm_authenticate(pam_handle_t *pamh, 
 
lc = login_getclass(NULL);
password_prompt = login_getcapstr(lc, passwd_prompt,
-   password_prompt, NULL);
+   Password:, NULL);
login_close(lc);
lc = NULL;
 
@@ -512,7 +513,8 @@ local_passwd(const char *user, const cha
login_cap_t * lc;
struct passwd *pwd;
int pfd, tfd;
-   char *crypt_type, salt[SALTSIZE + 1];
+   const char *crypt_type;
+   char salt[SALTSIZE + 1];
 
pwd = getpwnam(user);
if (pwd == NULL)
%%%

But this patch won't work without the const poisoning lib/libutil:

%%%
Index: login_auth.c
===
RCS file: /home/ncvs/src/lib/libutil/login_auth.c,v
retrieving revision 1.12
diff -u -p -r1.12 login_auth.c
--- login_auth.c30 Sep 2001 22:35:07 -  1.12
+++ login_auth.c8 Apr 2002 09:58:59 -
@@ -65,7 +65,7 @@ __FBSDID($FreeBSD: src/lib/libutil/logi
 void
 auth_checknologin(login_cap_t *lc)
 {
-  char *file;
+  const char *file;
 
   /* Do we ignore a nologin file? */
   if (login_getcapbool(lc, ignorenologin, 0))
Index: login_cap.3
===
RCS file: /home/ncvs/src/lib/libutil/login_cap.3,v
retrieving revision 1.27
diff -u -p -r1.27 login_cap.3
--- login_cap.3 1 Oct 2001 16:09:18 -   1.27
+++ login_cap.3 8 Apr 2002 09:58:59 -
@@ -52,12 +52,12 @@
 .Fn login_getpwclass const struct passwd *pwd
 .Ft login_cap_t *
 .Fn login_getuserclass const struct passwd *pwd
-.Ft char *
-.Fn login_getcapstr login_cap_t *lc const char *cap char *def char *error
+.Ft const char *
+.Fn login_getcapstr login_cap_t *lc const char *cap const char *def const char 
+*error
 .Ft char **
 .Fn login_getcaplist login_cap_t *lc const char *cap const char *chars
-.Ft char *
-.Fn login_getpath login_cap_t *lc const char *cap char *error
+.Ft const char *
+.Fn login_getpath login_cap_t *lc const char *cap const char *error
 .Ft rlim_t
 .Fn login_getcaptime login_cap_t *lc const char *cap rlim_t def rlim_t error
 .Ft rlim_t
@@ -66,8 +66,8 @@
 .Fn login_getcapsize login_cap_t *lc const char *cap rlim_t def rlim_t error
 .Ft int
 .Fn login_getcapbool login_cap_t *lc const char *cap int def
-.Ft char *
-.Fn login_getstyle login_cap_t *lc char *style const char *auth
+.Ft const char *
+.Fn login_getstyle login_cap_t *lc const char *style const char *auth
 .Ft const char *
 .Fn login_setcryptfmt login_cap_t *lc const char *def const char *error
 .Sh DESCRIPTION
Index: login_cap.c
===
RCS file: /home/ncvs/src/lib/libutil/login_cap.c,v
retrieving revision 1.26
diff -u -p -r1.26 login_cap.c
--- login_cap.c 6 Mar 2002 15:24:51 -   1.26
+++ login_cap.c 8 Apr 2002 09:58:59 -
@@ -344,8 +344,8 @@ login_getuserclass(const struct passwd *
  * an error string on error.
  */
 
-char *
-login_getcapstr(login_cap_t *lc, const char *cap, char *def, char *error)
+const char *
+login_getcapstr(login_cap_t *lc, const char *cap, const char *def, const char *error)
 {
 char*res;
 intret;
@@ -373,7 +373,7 @@ login_getcaplist(login_cap_t *lc, const 
 
 if (chars == NULL)
chars = , \t;
-if ((lstring = login_getcapstr(lc, cap, NULL, NULL)) != NULL)
+if ((lstring = (char *)login_getcapstr(lc, cap, NULL, NULL)) != NULL)
return arrayize(lstring, chars, NULL);
 return NULL;
 }
@@ -387,15 +387,15 @@ login_getcaplist(login_cap_t *lc, const 
  * If there 

Re: cvs commit: src/lib/libpam/modules/pam_unix pam_unix.c

2002-04-08 Thread Dag-Erling Smorgrav

Ruslan Ermilov [EMAIL PROTECTED] writes:
 On Sun, Apr 07, 2002 at 01:43:27PM -0700, Dag-Erling Smorgrav wrote:
Log:
Fix bug in previous commit that passed the wrong default value to
login_getcapstr(3).  Also fix a longer-standing bug (login_close(3)
frees the string returned by login_getcapstr(3)) by reorganizing the
code a little, and use login_getpwclass(3) instead of login_getclass(3)
if we already have a struct pwd.
 This change also broke the Password: prompt.  The bug is hidden by
 the -Wno-uninitialized setting in bsd.sys.mk.  Here's the patch:

The commit you quote *fixed* the bug you're referring to.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Kernel debugging - what's the procedure?

2002-04-08 Thread Terry Lambert

Josef Karthauser wrote:
 
 On Sun, Apr 07, 2002 at 01:54:08PM -0700, Terry Lambert wrote:
  Josef Karthauser wrote:
You use another machine, and connect the serial ports together.
See the handbook for details.
  
   I'd love to ;) but no additional machine is available at the moment.
 
  Then you install vmware, and Julian's back-to-back serial
  driver, and then run the kernel to be debuged in the vmware
  session.  This lets you debug the kernel on a virtual
  machine (single CPU only).
 
 Yes I do have vmware, but it's not going to help me debug the usb stack
 is it?  (I know vmware3 does usb, but not if the underlying usb stack on
 the host machine is also hosed).

It's my understanding that you can assign resources to the
vmware machine, which it can then permit to be accessed
natively.  Thus, if you gave your USB ports to the vmware
virtual machine entirely, this would resolve the problem.

The vmware3 support for usb appears (to me) to be a tunnel
driver, like the standard network driver interface (e.g. it
pretends to be hardware, and uses a host driver to contact
the real hardware, so that its use can be multiplexed and
thus the device accessed by etiher the real or the virtual
machine).

  Well, since this is the -current list... have you updated
  recently?  There were some recent changes by PHK to the dump
  format that may have broken/fixed things, if your answer to
  that question is yes/no, respectively.
 
 Yes, that's what I implied by the above paragraph.  I was up-to-date
 with sources yesterday.

This is probably your problem.

If you can back up to when the problem first appeared, or
back out the kernel dump fule generation modifications,
this would probably fix your problems.  If you look at
the -current list archives, you will see a number of posts
which identify the files which have changed, and are probably
what is breaking you [ comments on policy related to commits
of kernel changes without corresponding commits to user space
utilities elided ].

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: cvs commit: src/lib/libpam/modules/pam_unix pam_unix.c

2002-04-08 Thread Ruslan Ermilov

On Mon, Apr 08, 2002 at 12:15:17PM +0200, Dag-Erling Smorgrav wrote:
 Ruslan Ermilov [EMAIL PROTECTED] writes:
  On Sun, Apr 07, 2002 at 01:43:27PM -0700, Dag-Erling Smorgrav wrote:
 Log:
 Fix bug in previous commit that passed the wrong default value to
 login_getcapstr(3).  Also fix a longer-standing bug (login_close(3)
 frees the string returned by login_getcapstr(3)) by reorganizing the
 code a little, and use login_getpwclass(3) instead of login_getclass(3)
 if we already have a struct pwd.
  This change also broke the Password: prompt.  The bug is hidden by
  the -Wno-uninitialized setting in bsd.sys.mk.  Here's the patch:
 
 The commit you quote *fixed* the bug you're referring to.
 
You're right.  I forgot to relink pam_ssh.so library, and the diff was
against the wrong revision.  I will still commit the const poisoning
patch to libutil, as the impact turned out to be really low.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg37092/pgp0.pgp
Description: PGP signature


Re: cvs commit: src/lib/libpam/modules/pam_unix pam_unix.c

2002-04-08 Thread Dag-Erling Smorgrav

Ruslan Ermilov [EMAIL PROTECTED] writes:
 You're right.  I forgot to relink pam_ssh.so library, and the diff was
 against the wrong revision.  I will still commit the const poisoning
 patch to libutil, as the impact turned out to be really low.

Thanks, const poisoning is a Good Thing [tm].

BTW, could you try to figure out a way we can split up the libpam
build so the modules can depend on libpam.so?  What I'd like is:

 1) build static modules
 2) build static and dynamic libpam
 3) build dynamic modules (with dependency on libpam.so)

or

 1) build dynamic libpam
 2) build modules (with dependency on libpam.so)
 3) build static libpam

or something similar.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Kernel debugging - what's the procedure?

2002-04-08 Thread Josef Karthauser

On Mon, Apr 08, 2002 at 04:25:59AM -0700, Terry Lambert wrote:
 
  Yes, that's what I implied by the above paragraph.  I was up-to-date
  with sources yesterday.
 
 This is probably your problem.
 
 If you can back up to when the problem first appeared, or
 back out the kernel dump fule generation modifications,
 this would probably fix your problems.  If you look at
 the -current list archives, you will see a number of posts
 which identify the files which have changed, and are probably
 what is breaking you [ comments on policy related to commits
 of kernel changes without corresponding commits to user space
 utilities elided ].

Looking at todays commits it looks like the gdb/kernel coredump problem
has been fixed, at bde's bequest.

Joe



msg37094/pgp0.pgp
Description: PGP signature


Re: 5-CURRENT source upgrade path is broken in PAM

2002-04-08 Thread Ruslan Ermilov

On Thu, Mar 07, 2002 at 05:16:52PM +, Mark Murray wrote:
  Mark Murray [EMAIL PROTECTED] writes:
Umm, IIRC 'make world' starts by doing a 'make includes' into
/usr/obj, which should take care of this.
   That is 'make world'. It was broken for make obj  make depend  make,
   [...]
   IMO, the repo-copy is the cleanest, because it solves te above problems
   in the most canonical way.
  
  Please talk to Ruslan about this.  I suggested doing just what you're
  thinking of about a month or two ago, and he rejected it.
 
 Ruslan is not writing this code; we are.
 
But Ruslan might have an idea because he has eaten a few dogs on
make world issues.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg37095/pgp0.pgp
Description: PGP signature


Re: cvs commit: src/lib/libpam/modules/pam_unix pam_unix.c

2002-04-08 Thread Ruslan Ermilov

On Mon, Apr 08, 2002 at 02:49:04PM +0200, Dag-Erling Smorgrav wrote:
 Ruslan Ermilov [EMAIL PROTECTED] writes:
  You're right.  I forgot to relink pam_ssh.so library, and the diff was
  against the wrong revision.  I will still commit the const poisoning
  patch to libutil, as the impact turned out to be really low.
 
 Thanks, const poisoning is a Good Thing [tm].
 
 BTW, could you try to figure out a way we can split up the libpam
 build so the modules can depend on libpam.so?  What I'd like is:
 
  1) build static modules
  2) build static and dynamic libpam
  3) build dynamic modules (with dependency on libpam.so)
 
 or
 
  1) build dynamic libpam
  2) build modules (with dependency on libpam.so)
  3) build static libpam
 
 or something similar.
 
That should be as simple as that:

%%%
Index: Makefile.inc
===
RCS file: /home/ncvs/src/lib/libpam/modules/Makefile.inc,v
retrieving revision 1.10
diff -u -r1.10 Makefile.inc
--- Makefile.inc6 Apr 2002 19:32:37 -   1.10
+++ Makefile.inc8 Apr 2002 14:03:39 -
@@ -9,11 +9,7 @@
 CFLAGS+=   -I${.CURDIR}/../../libpam
 WARNS?=4
 
-# This is nasty.
-# For the static case, libpam.a depends on the modules.
-# For the dynamic case, the modules depend on libpam.so.N
-# Punt for the time being until I can figure out how to do it.
-#DPADD+=   ${LIBPAM}
-#LDADD+=   -lpam
+# Break `checkdpadd' deliberately.
+LDADD+=-lpam
 
 .include   ../Makefile.inc
%%%

For the static case (Mark probably means building of libpam.a here),
libpam.a indeed depends on the modules, but in the make(1) sense of
dependency, which we (sorry, _you_ Mark :-) handle nicely with the
STATIC_MODULES thingie.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg37096/pgp0.pgp
Description: PGP signature


Re: cvs commit: src/lib/libpam/modules/pam_unix pam_unix.c

2002-04-08 Thread Dag-Erling Smorgrav

Ruslan Ermilov [EMAIL PROTECTED] writes:
 That should be as simple as that:
 [...]

Thank you very much!

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



panic sleeping without a mutex in usb_task_thread

2002-04-08 Thread David Wolfskill

On my laptop (but not the build machine; the latter may not have any USB
devices) I get the following panic after builing, installing,  trying
to boot -CURRENT from today.  (CVSup log below panic trace.)

an0: Ethernet address 00:40:96:32:19:a9
bpf: an0 attached
panic: sleeping without a mutex
Debugger(panic)
Stopped at  Debugger+0x40:  xorl%eax,%eax
db trace
Debugger(c03d647c) at Debugger+0x40
panic(c03d6cac,c021ffec,c8e4e000,c8e4e100,c8e4e000) at panic+0x70
msleep(c0442d98,0,5c,c03c7784,0) at msleep+0x23
usb_task_thread(0,c8e6ad48,c8e4e100,c021ffec,0) at usb_task_thread+0x23
fork_exit(c021ffec,0,c8e6ad48) at fork_exit+0x8c
fork_trampoline() at fork_trampoline+0x37
dbshow locks
dbshow witness [scrolls off screen]
db

[Above was hand-transcribed; I don't have a serial console on my laptop,
and I'm not running VMware.]

Recent CVSup history:
freebeast(4.5-S)[1] tail /var/log/cvsup-history.log
CVSup begin from cvsup14.freebsd.org at Thu Apr  4 03:47:06 PST 2002
CVSup ended from cvsup14.freebsd.org at Thu Apr  4 03:53:56 PST 2002
CVSup begin from cvsup14.freebsd.org at Fri Apr  5 03:47:02 PST 2002
CVSup ended from cvsup14.freebsd.org at Fri Apr  5 03:54:13 PST 2002
CVSup begin from cvsup14.freebsd.org at Sat Apr  6 03:47:02 PST 2002
CVSup ended from cvsup14.freebsd.org at Sat Apr  6 03:54:32 PST 2002
CVSup begin from cvsup14.freebsd.org at Sun Apr  7 03:47:03 PDT 2002
CVSup ended from cvsup14.freebsd.org at Sun Apr  7 03:53:32 PDT 2002
CVSup begin from cvsup14.freebsd.org at Mon Apr  8 03:47:02 PDT 2002
CVSup ended from cvsup14.freebsd.org at Mon Apr  8 03:53:43 PDT 2002
freebeast(4.5-S)[2] 

I can leave it in this condition for a while, if it would be helpful to
poke around at all.

Cheers,
david
-- 
David H. Wolfskill  [EMAIL PROTECTED]
Based on my experience as a computing professional, I consider the use of
Microsoft products as components of computing systems to be just as
advisable as using green wood to frame a house... and expect similar results.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Intel i830 driver?

2002-04-08 Thread moto kawasaki


Hi, all

From: James Satterfield [EMAIL PROTECTED]
Subject: Re: Intel i830 driver?
Date: Fri, 5 Apr 2002 21:35:46 -0800
Message-ID: 01b601c1dd2c$e6ec2620$0feba8c0@sphynx

james I have a Dell Latitude C400 with an Intel i830M graphics chip. Running
james 4.5-stable, the i810 driver complains about not finding the (I assume AGP)
james bridge device. Here's my dmesg.

I am struggling the same issue too, and trying to support i830MG as
/dev/agpgart on FreeBSD 4.5-STABLE.
Unfortunately I have not succeeded but you can take a look at my patches
at http://snowwind.kawasaki3.org/.
# Please note that these patch is NOT completed.

Thank you very much.


moto kawasaki [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: patch: make syslog stop spamming any root it finds...

2002-04-08 Thread George Georgalis

On Sat, Apr 06, 2002 at 08:39:51AM +0200, [EMAIL PROTECTED] wrote:
   I have always hated the three lines in /etc/syslog.conf which spams
   root with far too many and far too irrellevant syslog messages, in
   some cases even with several copies of them.
  
  Amen to that. You got my vote. Usually when I set up a FreeBSD box, it's
  the first thing I turn off. I say commit it.
 
 Likewise, it's the first thing I turn off, as well as the *.emerg line
 that broadcasts to all users.

Same here. First things removed on a fresh FreeBSD install. Please
commit.


Not only the first thing I do with a new FreeBSD box, the first thing I did on 
FreeBSD: remove those 3 lines from syslog.conf that tell you how many people are 
poping their mail etc.

// George

-- 
GEORGE GEORGALIS, System Admin/Architectcell: 347-451-8229 
Security Services, Web, Mail,mailto:[EMAIL PROTECTED] 
File, Print, DB and DNS Servers.   http://www.galis.org/george 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



RE: panic sleeping without a mutex in usb_task_thread

2002-04-08 Thread John Baldwin


On 08-Apr-2002 David Wolfskill wrote:
 On my laptop (but not the build machine; the latter may not have any USB
 devices) I get the following panic after builing, installing,  trying
 to boot -CURRENT from today.  (CVSup log below panic trace.)
 
 an0: Ethernet address 00:40:96:32:19:a9
 bpf: an0 attached
 panic: sleeping without a mutex
 Debugger(panic)
 Stopped atDebugger+0x40:  xorl%eax,%eax
 db trace
 Debugger(c03d647c) at Debugger+0x40
 panic(c03d6cac,c021ffec,c8e4e000,c8e4e100,c8e4e000) at panic+0x70
 msleep(c0442d98,0,5c,c03c7784,0) at msleep+0x23
 usb_task_thread(0,c8e6ad48,c8e4e100,c021ffec,0) at usb_task_thread+0x23
 fork_exit(c021ffec,0,c8e6ad48) at fork_exit+0x8c
 fork_trampoline() at fork_trampoline+0x37
 dbshow locks
 dbshow witness [scrolls off screen]
 db
 
 [Above was hand-transcribed; I don't have a serial console on my laptop,
 and I'm not running VMware.]
 
 Recent CVSup history:
 freebeast(4.5-S)[1] tail /var/log/cvsup-history.log
 CVSup begin from cvsup14.freebsd.org at Thu Apr  4 03:47:06 PST 2002
 CVSup ended from cvsup14.freebsd.org at Thu Apr  4 03:53:56 PST 2002
 CVSup begin from cvsup14.freebsd.org at Fri Apr  5 03:47:02 PST 2002
 CVSup ended from cvsup14.freebsd.org at Fri Apr  5 03:54:13 PST 2002
 CVSup begin from cvsup14.freebsd.org at Sat Apr  6 03:47:02 PST 2002
 CVSup ended from cvsup14.freebsd.org at Sat Apr  6 03:54:32 PST 2002
 CVSup begin from cvsup14.freebsd.org at Sun Apr  7 03:47:03 PDT 2002
 CVSup ended from cvsup14.freebsd.org at Sun Apr  7 03:53:32 PDT 2002
 CVSup begin from cvsup14.freebsd.org at Mon Apr  8 03:47:02 PDT 2002
 CVSup ended from cvsup14.freebsd.org at Mon Apr  8 03:53:43 PDT 2002
 freebeast(4.5-S)[2] 
 
 I can leave it in this condition for a while, if it would be helpful to
 poke around at all.

show witness isn't useful to most people so I would avoid it unless someone
explicitly asks for it.  The problem here is likely due to the
usb_task_thread() not locking Giant when it starts up.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
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: panic sleeping without a mutex in usb_task_thread

2002-04-08 Thread Josef Karthauser

On Mon, Apr 08, 2002 at 12:33:40PM -0400, John Baldwin wrote:
 
 show witness isn't useful to most people so I would avoid it unless someone
 explicitly asks for it.  The problem here is likely due to the
 usb_task_thread() not locking Giant when it starts up.

We probably want this:


Index: usb.c
===
RCS file: /home/ncvs/src/sys/dev/usb/usb.c,v
retrieving revision 1.75
diff -u -5 -r1.75 usb.c
--- usb.c   7 Apr 2002 14:21:32 -   1.75
+++ usb.c   8 Apr 2002 17:58:38 -
 -423,10 +423,14 
 usb_task_thread(void *arg)
 {
struct usb_task *task;
int s;
 
+#ifdef __FreeBSD__
+   mtx_lock(Giant);
+#endif
+
DPRINTF((usb_task_thread: start\n));
 
s = splusb();
for (;;) {
task = TAILQ_FIRST(usb_all_tasks);


Joe



msg37102/pgp0.pgp
Description: PGP signature


Re: panic sleeping without a mutex in usb_task_thread

2002-04-08 Thread John Baldwin


On 08-Apr-2002 Josef Karthauser wrote:
 On Mon, Apr 08, 2002 at 12:33:40PM -0400, John Baldwin wrote:
  
 show witness isn't useful to most people so I would avoid it unless someone
 explicitly asks for it.  The problem here is likely due to the
 usb_task_thread() not locking Giant when it starts up.
 
 We probably want this:

Probably unless some USB specific locks are added instead, but this is the
easier fix for the time being.

 Index: usb.c
 ===
 RCS file: /home/ncvs/src/sys/dev/usb/usb.c,v
 retrieving revision 1.75
 diff -u -5 -r1.75 usb.c
 --- usb.c 7 Apr 2002 14:21:32 -   1.75
 +++ usb.c 8 Apr 2002 17:58:38 -
 @@ -423,10 +423,14 @@
  usb_task_thread(void *arg)
  {
   struct usb_task *task;
   int s;
  
 +#ifdef __FreeBSD__
 + mtx_lock(Giant);
 +#endif
 +
   DPRINTF((usb_task_thread: start\n));
  
   s = splusb();
   for (;;) {
   task = TAILQ_FIRST(usb_all_tasks);
 
 
 Joe

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
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: panic sleeping without a mutex in usb_task_thread

2002-04-08 Thread Josef Karthauser

On Mon, Apr 08, 2002 at 01:37:55PM -0400, John Baldwin wrote:
 
 On 08-Apr-2002 Josef Karthauser wrote:
  On Mon, Apr 08, 2002 at 12:33:40PM -0400, John Baldwin wrote:
   
  show witness isn't useful to most people so I would avoid it unless someone
  explicitly asks for it.  The problem here is likely due to the
  usb_task_thread() not locking Giant when it starts up.
  
  We probably want this:
 
 Probably unless some USB specific locks are added instead, but this is the
 easier fix for the time being.
 

Cool.  I've committed this; where should I look to get a low down on
what to lock, when and how?  Is there anything other than source to
refer to?

Joe



msg37104/pgp0.pgp
Description: PGP signature


Re: ld-elf.so.1 broken with world from yesterday

2002-04-08 Thread David O'Brien

On Mon, Apr 08, 2002 at 11:07:21AM +0100, Alexander Leidinger wrote:
 
 yesterday I've made a new world. After booting it, ld-elf-so.1 complains 
 about every library (libc, libutil, ...). My -current is not usable 
 anymore because of this.

Defined complains.  freebsd-current readers should know to spend EXACT
error messages.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: panic sleeping without a mutex in usb_task_thread

2002-04-08 Thread John Baldwin


On 08-Apr-2002 Josef Karthauser wrote:
 On Mon, Apr 08, 2002 at 01:37:55PM -0400, John Baldwin wrote:
 
 On 08-Apr-2002 Josef Karthauser wrote:
  On Mon, Apr 08, 2002 at 12:33:40PM -0400, John Baldwin wrote:
   
  show witness isn't useful to most people so I would avoid it unless
  someone
  explicitly asks for it.  The problem here is likely due to the
  usb_task_thread() not locking Giant when it starts up.
  
  We probably want this:
 
 Probably unless some USB specific locks are added instead, but this is the
 easier fix for the time being.
 
 
 Cool.  I've committed this; where should I look to get a low down on
 what to lock, when and how?  Is there anything other than source to
 refer to?

Nothing besides the source really.  If it's walking a list you might use a lock
to protect the list for example, but then you might need to conditionally get
Giant while performing an action on the list.

 Joe

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
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



Fatal double fault on -current

2002-04-08 Thread Maksim Yevmenkin

Hackers,

for the last couple of days i was able to crash my -current
laptop with Fatal double fault panic whenever i wanted.

i have created a small spherical cow :) to demonstrate 
the problem (see attached). this is pretty much what my code
does. just compile and load the cow and then try 

# ngctl msg cow: moo

i'm suspecting m_split() and have attached tiny path that
fixes problem for me.

of course it might be just my fault :) and i'm missing some
small thing.

... if you think you found the bug - you don't... 

thanks,
max

/*
 * ng_cow.c
 *
 * Copyright (c) 2001-2002 Maksim Yevmenkin [EMAIL PROTECTED]
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 */

#include sys/param.h
#include sys/systm.h
#include sys/errno.h
#include sys/kernel.h
#include sys/malloc.h
#include sys/mbuf.h
#include netgraph/ng_message.h
#include netgraph/netgraph.h
#include netgraph/ng_parse.h

#define NG_COW_NODE_TYPEcow
#define NGM_COW_COOKIE  1018303300
#define NGM_COW_MOO 1

/* MALLOC define */
#ifdef NG_SEPARATE_MALLOC
MALLOC_DEFINE(M_NETGRAPH_COW, cow, Netgraph spherical cow);
#else
#define M_NETGRAPH_COW M_NETGRAPH
#endif /* NG_SEPARATE_MALLOC */

/* Netgraph node methods */
static ng_constructor_t ng_cow_constructor;
static ng_rcvmsg_t  ng_cow_rcvmsg;
static ng_shutdown_tng_cow_shutdown;
static ng_newhook_t ng_cow_newhook;
static ng_connect_t ng_cow_connect;
static ng_rcvdata_t ng_cow_rcvdata;
static ng_disconnect_t  ng_cow_disconnect;
static int  ng_cow_modevent __P((module_t, int, void *));

/* Netgraph node command list */
static const struct ng_cmdlist  ng_cow_cmdlist[] = {
{
NGM_COW_COOKIE,
NGM_COW_MOO,
moo,
NULL,
NULL
},
{ 0, }
};

/* Netgraph type descriptor */
static struct ng_type   typestruct = {
NG_ABI_VERSION,
NG_COW_NODE_TYPE,   /* typename */
ng_cow_modevent,/* modevent */
ng_cow_constructor, /* constructor */
ng_cow_rcvmsg,  /* control message */
ng_cow_shutdown,/* destructor */
ng_cow_newhook, /* new hook */
NULL,   /* find hook */
ng_cow_connect, /* connect hook */
ng_cow_rcvdata, /* data */
ng_cow_disconnect,  /* disconnect hook */
ng_cow_cmdlist  /* node command list */
};
NETGRAPH_INIT(cow, typestruct);
MODULE_VERSION(ng_cow, 1);

static int  ng_cow_moo  __P((void));
static struct mbuf *ng_cow_prepend  __P((struct mbuf *, int));

/*
 *
 **Netgraph node interface
 *
 */

static node_p   the_node = NULL;

/*
 * Handle loading and unloading for this node type
 */

static int
ng_cow_modevent(mod, event, data)
module_t mod;
int  event;
void*data;
{
int error = 0;

switch (event) {
case MOD_LOAD:
error = ng_make_node_common(typestruct, the_node);
if (error != 0)
break;

error = ng_name_node(the_node, NG_COW_NODE_TYPE);
if (error != 0) {
NG_NODE_UNREF(the_node);
the_node = NULL;
break;
}
break;

case MOD_UNLOAD:
error = EBUSY;
break;

fwiw: nfs loopback still broken in -current

2002-04-08 Thread Matthew Jacob


NFS loopback mounts still periodically gets hung with:

ypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
-fformat-extensions -ansi -g -nostdinc -I-  -I. -I../../.. -I../../../dev
-I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I/usr/include
-D_KERNEL -ffreestanding -include opt_global.h -fno-common   -mno-fp-regs
-ffixed-8 -Wa,-mev56   vers.c
linking kernel.debug
nfs server yorp:/space/compiles: not responding 10  9
.


This has been the case for months and months.

-matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



LOOKUP_SHARED is default now

2002-04-08 Thread Jeff Roberson

This patch has seriously reduced file system deadlocks for several people.
It also makes concurrent file system access much faster in certain cases.
Since I have only heard good reports and no bad reports I'm going to
enable it by default.  If you do experience some file system deadlocks
please let me know.  You may revert to the previous behavior with 'options
LOOKUP_EXCLUSIVE'.  I will take this away after a month or so if there are
no problems.

Thanks,
Jeff


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



boot failure

2002-04-08 Thread Jan Stocker

After a buildworld / buildkernel /installkernel / installworld on my current
system from yesterday sources (about 19:00 CET) my system doesnt boot: The
kernel and the acpi module will be loaded and then nothing happens for a
second, something is accessing the hd and i get a login screen. No hardware
detect and nothing else before the login only kernel and acpi loaded. Of
course you cant login... you cant input anything :)

Jan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message