Re: FreeBSD 5.1-R kernel panic

2003-07-22 Thread Stephane Raimbault
Hi Thanks for your response,

I do not have PAE enabled... I've been hesitant of turning it on, I'm not
sure if it's too stable, I noticed that the asr driver is in the nodriver
list in the PAE kernel config file and I use the asr driver for my Adaptec
2015S raid card.  If you think its safe to enable PAE with my current setup,
please let me know, I do have 2 more gig's of ram in this particular box
that I'd like to enable if it doesn't compromise system stability.

I will re-compile the kernel with the kern_malloc.c as you suggested,
however I see that 1.126 fixes a PAE issue, so I'm not sure if that's going
to help me out much.

Where can I get information on how to get my kernel to provide a stack
trace?  I have done little of this type of troubleshooting, but would like
to provide as much info before I'm forced to revert to 4.8-R in hopes to
return stability to our system.  If the new kernel with the updated
kern_malloc.c doesn't help, I'll look at increasing the values you
suggested.

Thanks for the info, and I'll keep you posted with what I find.

Thanks again,
Stephane Raimbault

- Original Message - 
From: Bosko Milekic [EMAIL PROTECTED]
Newsgroups: mailing.freebsd.current
Sent: Monday, July 21, 2003 16:36
Subject: Re: FreeBSD 5.1-R kernel panic



 On Mon, Jul 21, 2003 at 03:01:24PM -0600, Stephane Raimbault wrote:
  I'm running FreeBSD 5.1-RELEASE with the SMP kernel and ran across the
  following kernel panic.
 
  panic: kmem_malloc(4096): kmem_map too small: 275251200 total allocated
 
  I'm trying to figure out what could be causing this, what kind of
  information that I could provide to this group (or other group?) to see
if
  this is a bug in FreeBSD that needs to be looked into?
 
  The box is basically a busy apache server... the kernel panic seemed to
  occur during the periodic daily was running.  It seems to complete the
  440.status-mailq part of periodic daily , but doesn't do
  450.status-security.
 
  This isn't the first time the box has crashed at aprox. 3:01 am (when
daily
  runs)... however this is the first time I've seend the kernel panic
message
  quoted above in the /var/run/dmesg.boot file.
 
  I have attached the entire /var/run/dmesg.boot file to this message.
 
  What can I do to assist in identifiying and resolving this problem?
 
  Thanks,
  Stephane Raimbault.

   Just a few things:

   1) Do you have PAE enabled?

   2) Can you upgrade to src/sys/kern/kern_malloc.c version 1.126 or
   upgrade to HEAD?

   If you have PAE enabled and (2) does not fix your problem, then please
   post a stack trace that resulted in the panic.  You also have a lot of
   RAM so if (2) above does not fix your problem, try setting the
   kern.vm.kmem.size bootable to approximately 350,000,000 or so (even
   400,000,000 is OK as long as NMBCLUSTERS is not too-too high).

 -- 
 Bosko Milekic  *  [EMAIL PROTECTED]  *  [EMAIL PROTECTED]
 TECHNOkRATIS Consulting Services  *  http://www.technokratis.com/
 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: [-CURRENT tinderbox] failure on i386/pc98

2003-07-22 Thread Harti Brandt

Sorry, I failed to commit one of the files. Should work now.

harti

On Mon, 21 Jul 2003, Tinderbox wrote:

TTB --- 2003-07-21 19:01:13 - starting CURRENT tinderbox run for i386/pc98
TTB --- 2003-07-21 19:01:13 - checking out the source tree
TTB --- cd /home/des/tinderbox/CURRENT/i386/pc98
TTB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TTB --- 2003-07-21 19:03:15 - building world
TTB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src
TTB --- /usr/bin/make -B buildworld
T Rebuilding the temporary build tree
T stage 1: legacy release compatibility shims
T stage 1: bootstrap tools
T stage 2: cleaning up the object tree
T stage 2: rebuilding the object tree
T stage 2: build tools
T stage 3: cross tools
T stage 4: populating 
/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include
T stage 4: building libraries
T stage 4: make dependencies
T stage 4: building everything..
TTB --- 2003-07-21 20:02:20 - building generic kernel
TTB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src
TTB --- /usr/bin/make buildkernel KERNCONF=GENERIC
T Kernel build for GENERIC started on Mon Jul 21 20:02:20 GMT 2003
T[...]
T/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: 
error: initializer element is not constant
T/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: 
error: (near initialization for `map_devs[13].dev')
T/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: 
error: initializer element is not constant
T/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: 
error: (near initialization for `map_devs[13]')
T/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c: In 
function `harp_attach':
T/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:412: 
error: `MEDIA_UTP25' undeclared (first use in this function)
T/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:412: 
error: (Each undeclared identifier is reported only once
T/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:412: 
error: for each function it appears in.)
T*** Error code 1
T
TStop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules/harp.
T*** Error code 1
T
TStop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules.
T*** Error code 1
T
TStop in 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC.
T*** Error code 1
T
TStop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
T*** Error code 1
T
TStop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
TTB --- 2003-07-21 20:09:36 - /usr/bin/make returned exit code  1
TTB --- 2003-07-21 20:09:36 - ERROR: failed to build generic kernel
TTB --- 2003-07-21 20:09:36 - tinderbox aborted
T
T___
T[EMAIL PROTECTED] mailing list
Thttp://lists.freebsd.org/mailman/listinfo/freebsd-current
TTo unsubscribe, send any mail to [EMAIL PROTECTED]
T

-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: [-CURRENT tinderbox] failure on i386/i386

2003-07-22 Thread Terry Lambert
Dag-Erling Smørgrav wrote:
 Peter Wemm [EMAIL PROTECTED] writes:
  Hmm. I thought it was gzip that was dying. Looks like its make instead, and
  is rather consistent.
 
 told you so
 
  So, who has been messing with make(1) lately?
 
 I believe that the problem is in the kernel, not in make(1); it just
 happens to be triggered by make(1) because it is a big (if not the
 biggest) vfork(2) consumer.

It's pretty evil, too.  It makes all sorts of system calls that
it ought not to be making (i.e. it's permitted to call execve(2)
or _exit(2), and that's all, period: all other system calls have
undefined behaviour, according to the standards).

It's really *very* tempting to set up a vfork(2) system call
table that has only those two system calls in it, and returns
ENOSYS for everything else, to catch the idiots who think that
vfork() is just like fork(), only faster.

Most likely, it's hitting a race in dup2(2) or write(2) or close(2)
or one of the other system calls it calls between the vfork(2) and
the execve(2)/_exit(2).

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Stop in /usr/src/sys/modules/harp

2003-07-22 Thread Harti Brandt

I have commited the missing file just now. Sorry for that.

harti

On Mon, 21 Jul 2003, Xaos wrote:

X-BEGIN PGP SIGNED MESSAGE-
XHash: SHA1
X
XI keep getting this error when compiling a freshly cvsup'd source. 5.1-Current
X
X/usr/src/sys/dev/harp/if_harp.c:128: `VENDAPI_FORE_2' undeclared here (not in
Xa function)
X/usr/src/sys/dev/harp/if_harp.c:128: initializer element is not
Xconstant/usr/src/sys/dev/harp/if_harp.c:128: (near initialization for
X`map_devs[2].api')
X/usr/src/sys/dev/harp/if_harp.c:128: `DEV_FORE_HE155' undeclared here (not in
Xa function)
X/usr/src/sys/dev/harp/if_harp.c:128: initializer element is not
Xconstant/usr/src/sys/dev/harp/if_harp.c:128: (near initialization for
X`map_devs[2].dev')
X/usr/src/sys/dev/harp/if_harp.c:128: initializer element is not
Xconstant/usr/src/sys/dev/harp/if_harp.c:128: (near initialization for
X`map_devs[2]')
X/usr/src/sys/dev/harp/if_harp.c:130: `VENDAPI_FORE_2' undeclared here (not in
Xa function)
X/usr/src/sys/dev/harp/if_harp.c:130: initializer element is not
Xconstant/usr/src/sys/dev/harp/if_harp.c:130: (near initialization for
X`map_devs[3].api')
X/usr/src/sys/dev/harp/if_harp.c:130: `DEV_FORE_HE622' undeclared here (not in
Xa function)
X/usr/src/sys/dev/harp/if_harp.c:130: initializer element is not
Xconstant/usr/src/sys/dev/harp/if_harp.c:130: (near initialization for
X`map_devs[3].dev')
X/usr/src/sys/dev/harp/if_harp.c:130: initializer element is not
Xconstant/usr/src/sys/dev/harp/if_harp.c:130: (near initialization for
X`map_devs[3]')
X/usr/src/sys/dev/harp/if_harp.c:132: initializer element is not
Xconstant/usr/src/sys/dev/harp/if_harp.c:132: (near initialization for
X`map_devs[4]')
X/usr/src/sys/dev/harp/if_harp.c:134: initializer element is not
Xconstant/usr/src/sys/dev/harp/if_harp.c:134: (near initialization for
X`map_devs[5]')
X/usr/src/sys/dev/harp/if_harp.c:136: `DEV_FORE_LE25' undeclared here (not in a
Xfunction)
X/usr/src/sys/dev/harp/if_harp.c:136: initializer element is not
Xconstant/usr/src/sys/dev/harp/if_harp.c:136: (near initialization for
X`map_devs[6].dev')
X/usr/src/sys/dev/harp/if_harp.c:136: initializer element is not
Xconstant/usr/src/sys/dev/harp/if_harp.c:136: (near initialization for
X`map_devs[6]')
X/usr/src/sys/dev/harp/if_harp.c:138: `DEV_FORE_LE155' undeclared here (not in
Xa function)
X/usr/src/sys/dev/harp/if_harp.c:138: initializer element is not
Xconstant/usr/src/sys/dev/harp/if_harp.c:138: (near initialization for
X`map_devs[7].dev')
X/usr/src/sys/dev/harp/if_harp.c:138: initializer element is not
Xconstant/usr/src/sys/dev/harp/if_harp.c:138: (near initialization for
X`map_devs[7]')
X/usr/src/sys/dev/harp/if_harp.c:140: `DEV_IDT_25' undeclared here (not in a
Xfunction)
X/usr/src/sys/dev/harp/if_harp.c:140: initializer element is not
Xconstant/usr/src/sys/dev/harp/if_harp.c:140: (near initialization for
X`map_devs[8].dev')
X/usr/src/sys/dev/harp/if_harp.c:140: initializer element is not
Xconstant/usr/src/sys/dev/harp/if_harp.c:140: (near initialization for
X`map_devs[8]')
X/usr/src/sys/dev/harp/if_harp.c:142: initializer element is not
Xconstant/usr/src/sys/dev/harp/if_harp.c:142: (near initialization for
X`map_devs[9]')
X/usr/src/sys/dev/harp/if_harp.c:144: `VENDAPI_IDT_2' undeclared here (not in a
Xfunction)
X/usr/src/sys/dev/harp/if_harp.c:144: initializer element is not
Xconstant/usr/src/sys/dev/harp/if_harp.c:144: (near initialization for
X`map_devs[10].api')
X/usr/src/sys/dev/harp/if_harp.c:144: `DEV_IDTABR_25' undeclared here (not in a
Xfunction)
X/usr/src/sys/dev/harp/if_harp.c:144: initializer element is not
Xconstant/usr/src/sys/dev/harp/if_harp.c:144: (near initialization for
X`map_devs[10].dev')
X/usr/src/sys/dev/harp/if_harp.c:144: initializer element is not
Xconstant/usr/src/sys/dev/harp/if_harp.c:144: (near initialization for
X`map_devs[10]')
X/usr/src/sys/dev/harp/if_harp.c:146: `VENDAPI_IDT_2' undeclared here (not in a
Xfunction)
X/usr/src/sys/dev/harp/if_harp.c:146: initializer element is not
Xconstant/usr/src/sys/dev/harp/if_harp.c:146: (near initialization for
X`map_devs[11].api')
X/usr/src/sys/dev/harp/if_harp.c:146: `DEV_IDTABR_155' undeclared here (not in
Xa function)
X/usr/src/sys/dev/harp/if_harp.c:146: initializer element is not
Xconstant/usr/src/sys/dev/harp/if_harp.c:146: (near initialization for
X`map_devs
X
X- -Tom
X- --
XDeath is merciful, for there is no return
Xtherefrom, but with him who has come back
Xout of the nethermost chambers of night,
Xhaggard and knowing, peace rests nevermore
X- -Lovecraft
X-BEGIN PGP SIGNATURE-
XVersion: GnuPG v1.2.2 (FreeBSD)
X
XiD8DBQE/HKwQ4yFLRHBUZMwRAtAKAKC+DXMotlpa/s7c5R50WfvFneQ/HQCgkH9e
Xw/az+o+YtNHT95L9apqLPq8=
X=Kewt
X-END PGP SIGNATURE-
X
X___
X[EMAIL PROTECTED] mailing list
Xhttp://lists.freebsd.org/mailman/listinfo/freebsd-current
XTo unsubscribe, send any mail to [EMAIL PROTECTED]
X

-- 
harti brandt,

[-CURRENT tinderbox] failure on i386/i386

2003-07-22 Thread Tinderbox
TB --- 2003-07-22 06:13:03 - starting CURRENT tinderbox run for i386/i386
TB --- 2003-07-22 06:13:03 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/i386
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-22 06:15:09 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1: legacy release compatibility shims
 stage 1: bootstrap tools
 stage 2: cleaning up the object tree
 stage 2: rebuilding the object tree
 stage 2: build tools
 stage 3: cross tools
 stage 4: populating 
 /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include
 stage 4: building libraries
 stage 4: make dependencies
 stage 4: building everything..
TB --- 2003-07-22 07:19:03 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Tue Jul 22 07:19:04 GMT 2003
[...]
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/harp/if_harp.c:150: error: 
initializer element is not constant
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/harp/if_harp.c:150: error: 
(near initialization for `map_devs[13].dev')
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/harp/if_harp.c:150: error: 
initializer element is not constant
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/harp/if_harp.c:150: error: 
(near initialization for `map_devs[13]')
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/harp/if_harp.c: In 
function `harp_attach':
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/harp/if_harp.c:412: error: 
`MEDIA_UTP25' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/harp/if_harp.c:412: error: 
(Each undeclared identifier is reported only once
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/harp/if_harp.c:412: error: 
for each function it appears in.)
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/modules/harp.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/modules.
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/GENERIC.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
TB --- 2003-07-22 07:27:50 - /usr/bin/make returned exit code  1 
TB --- 2003-07-22 07:27:50 - ERROR: failed to build generic kernel
TB --- 2003-07-22 07:27:50 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


'su' problem

2003-07-22 Thread DvG
Hi,

 

Im having problem using ’su’: pam_unix: pam_sm_authenticate: UNIX authentication 
refused

in any other account except root. Where could be the problem ?

 

Thank you in advance .

 

Here is what i use in pam 

/etc/pam.d$cat su

#

# $FreeBSD: src/etc/pam.d/su,v 1.15 2003/06/14 12:35:05 des Exp $

#

# PAM configuration for the su service

#

 

# auth

#auth   sufficient  pam_rootok.so   no_warn

#auth   sufficient  pam_self.so no_warn

#auth   requisite   pam_group.sono_warn group=wheel root_only 
fail_safe

authrequiredpam_unix.so try_first_pass 

 

authinclude system

 

 

# account

account include system

 

# session

session include system

 

---

/etc/pam.d$cat login

#

# $FreeBSD: src/etc/pam.d/login,v 1.16 2003/06/14 12:35:05 des Exp $

#

# PAM configuration for the login service

#

 

# auth

#auth   sufficient  pam_skey.so

authrequisite   pam_cleartext_pass_ok.so

#auth   sufficient  pam_kerberosIV.so   try_first_pass

authrequiredpam_unix.so try_first_pass

 

# account

account requiredpam_unix.so

 

# session

session requiredpam_permit.so

 

# password

passwordrequiredpam_permit.so


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[-CURRENT tinderbox] failure on i386/pc98

2003-07-22 Thread Tinderbox
TB --- 2003-07-22 07:27:50 - starting CURRENT tinderbox run for i386/pc98
TB --- 2003-07-22 07:27:50 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-22 07:33:00 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1: legacy release compatibility shims
 stage 1: bootstrap tools
 stage 2: cleaning up the object tree
 stage 2: rebuilding the object tree
 stage 2: build tools
 stage 3: cross tools
 stage 4: populating 
 /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include
 stage 4: building libraries
 stage 4: make dependencies
 stage 4: building everything..
TB --- 2003-07-22 08:32:02 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Tue Jul 22 08:32:03 GMT 2003
[...]
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: error: 
initializer element is not constant
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: error: 
(near initialization for `map_devs[13].dev')
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: error: 
initializer element is not constant
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: error: 
(near initialization for `map_devs[13]')
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c: In 
function `harp_attach':
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:412: error: 
`MEDIA_UTP25' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:412: error: 
(Each undeclared identifier is reported only once
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:412: error: 
for each function it appears in.)
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules/harp.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules.
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
TB --- 2003-07-22 08:39:15 - /usr/bin/make returned exit code  1 
TB --- 2003-07-22 08:39:15 - ERROR: failed to build generic kernel
TB --- 2003-07-22 08:39:15 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Does linux-sun-jdk_1.4.2 work?

2003-07-22 Thread Sheldon Hearn
On (2003/07/21 23:41), Adam wrote:

 Perhaps you should try working with Java 1.4.x on FreeBSD before you
 assume something about me that's highly inaccurate. I think you'll find
 very quickly that it doesn't work nicely unless the process is running
 as root. 

So that this doesn't stick in people's minds as the status quo, let me
just add that several of us are very happy with the native jdk14 port on
FreeBSD, both -CURRENT and -STABLE.

However, this kind of discussion (sans Mr Migus unacceptable rudeness)
would be more valuable on the freebsd-java mailing list.

Ciao,
Sheldon.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[-CURRENT tinderbox] failure on ia64/ia64

2003-07-22 Thread Tinderbox
TB --- 2003-07-22 08:39:16 - starting CURRENT tinderbox run for ia64/ia64
TB --- 2003-07-22 08:39:16 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-22 08:41:25 - building world
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1: legacy release compatibility shims
 stage 1: bootstrap tools
 stage 2: cleaning up the object tree
 stage 2: rebuilding the object tree
 stage 2: build tools
 stage 3: cross tools
 stage 4: populating 
 /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include
 stage 4: building libraries
 stage 4: make dependencies
 stage 4: building everything..
TB --- 2003-07-22 09:46:38 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Tue Jul 22 09:46:38 GMT 2003
[...]
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:150: error: 
initializer element is not constant
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:150: error: 
(near initialization for `map_devs[13].dev')
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:150: error: 
initializer element is not constant
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:150: error: 
(near initialization for `map_devs[13]')
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c: In 
function `harp_attach':
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:412: error: 
`MEDIA_UTP25' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:412: error: 
(Each undeclared identifier is reported only once
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:412: error: 
for each function it appears in.)
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/modules/harp.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/modules.
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src.
TB --- 2003-07-22 09:56:34 - /usr/bin/make returned exit code  1 
TB --- 2003-07-22 09:56:34 - ERROR: failed to build generic kernel
TB --- 2003-07-22 09:56:34 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: FreeBSD 5.1-R kernel panic

2003-07-22 Thread Josef Karthauser
On Tue, Jul 22, 2003 at 12:18:31AM +0100, Bruce Cran wrote:
 
 It sounds like the same or similar problem reported in the 'USB crappiness'
 thread - the system slows down, and then any command crashes the system with
 the error about kmem.  I posted a backtrace to the problem in usb_mem.c, and
 the developer has posted a temporary fix - it was a problem with bus_dma,
 it was allocating too much memory and running out of kernel memory.
 

That temporary fix was committed to the tree yesterday, so a
cvsup/rebuild should alleviate the symptoms.

Joe
-- 
Josef Karthauser ([EMAIL PROTECTED])   http://www.josef-k.net/
FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/
Physics Particle Theory (student)   http://www.pact.cpes.sussex.ac.uk/
 An eclectic mix of fact and theory. =
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


libmap.conf kudos

2003-07-22 Thread Sheldon Hearn
Hi Matthew,

Dude, your libmap.conf work ROCKS!  Finally, a painless way to play
around with the impact of various threading implementations on Java
without tearing any hair out over symlinks and such.

Thanks!
Sheldon.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Porting networking code from -STABLE to -CURRENT

2003-07-22 Thread Craig Rodrigues
Hi,

I am interested in using the SCTP protocol implementation ( http://www.sctp.org )
on -CURRENT.  Currently it works on -STABLE, and is integrated with the
current KAME snapshots ( http://www.kame.net ).

Has anyone ported networking code from -STABLE to -CURRENT?

What is involved?  Right now the code uses splnet() / splx()
is there a guideline for how to migrate to the macros in
mutex(9)?

Thanks.
-- 
Craig Rodrigues
http://crodrigues.org
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Adaptec AIC7902 Ultra320 Problems

2003-07-22 Thread Lawrence Farr
I have a Supermicro SuperServer 6013P-8, with:

ahd0: Adaptec AIC7902 Ultra320 SCSI adapter port
0x4000-0x40ff,0x4400-0x44ff mem 0xfc30-0xfc301fff irq 5 at device 2.0 on
pci3
aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs
ahd1: Adaptec AIC7902 Ultra320 SCSI adapter port
0x4800-0x48ff,0x4c00-0x4cff mem 0xfc302000-0xfc303fff irq 5 at device 2.1 on
pci3
aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs

Trying to install 5.1-CURRENT-20030709-JPSNAP or 4.8-STABLE on the
box gives a timeout error that will hang the disk in a state that
resetting the machine does not clear, and only power cycling will
clear. Ive replaced the disks with no change, but installed and
ran Redhat 7.3 on the box with no timeouts or errors.

The full dmesg is here:
http://aticatac.epcdirect.co.uk/~l.farr/6013P8_dmesg.txt

And timeout is here:
http://aticatac.epcdirect.co.uk/~l.farr/AIC7902_timeout.txt

Lawrence Farr
EPC Direct Limited 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Fixing gcc 3.3 compile failures

2003-07-22 Thread Simon Barner
--- midimountain/mvcSongProperties.cpp.orig Tue Jul 22 04:23:32 2003
+++ midimountain/mvcSongProperties.cpp  Tue Jul 22 04:25:22 2003
@@ -42,7 +42,8 @@
 //=
 void TMvcSongProperties::SetData( void )
 {
-   int* tmpInt = new int = 0;
+   int* tmpInt = new int;
+   *tmpInt = 0;
 
gtk_editable_insert_text( GTK_EDITABLE( FindWidget( txtName )),
fSequence-GetSequenceName(),
@@ -111,4 +112,4 @@
 void CancelClickedSongProp( GtkButton *button, gpointer user_data )
 {
gtk_widget_hide( ((TMvcSongProperties*)user_data)-GetWidget() );
-}
\ No newline at end of file
+}


signature.asc
Description: Digital signature


Re: Fixing gcc 3.3 compile failures -- fix for net/netmap

2003-07-22 Thread Simon Barner
--- belgolib/dirs.c.origTue Jul 22 04:58:32 2003
+++ belgolib/dirs.c Tue Jul 22 04:58:46 2003
@@ -1,5 +1,6 @@
 #include stdio.h
 #include dirent.h
+#include assert.h
 
 #include list
 


signature.asc
Description: Digital signature


Re: Fixing gcc 3.3 compile failures -- fix for net/netsaint-plugins

2003-07-22 Thread Simon Barner
--- plugins/check_by_ssh.c.orig Mon Apr 23 09:43:11 2001
+++ plugins/check_by_ssh.c  Tue Jul 22 05:05:52 2003
@@ -191,7 +191,7 @@
if (commands1)
remotecmd=strscat(remotecmd,;echo STATUS CODE: $?;);
 
-   if (strlen (remotecmd) = 1)
+   if (remotecmd==NULL)
usage (No remotecmd\n);
 
comm = ssprintf(comm,%s %s '%s',comm,hostname,remotecmd);
@@ -369,6 +369,8 @@
list of netsaint service names, separated by ':' [optional]\n
 -n, --name=NAME\n
short name of host in netsaint configuration [optional]\n
+-v, --verbose\n
+   short name of host in netsaint configuration [optional]\n
 \n
 The most common mode of use is to refer to a local identity file 
with\n
 the '-i' option. In this mode, the identity pair should have a 
null\n
@@ -388,7 +390,7 @@
 
 
 #define OPTIONS \
--H host [-P port] [-f] [-y] [-t timeout] [-i identity]\n
+-H host -C command [-fyv] [-P port] [-t timeout] [-i identity]\n\
  [-l user] [-n name] [-s servicelist] [-O outputfile]
 
 void print_usage(void)


signature.asc
Description: Digital signature


Re: Fixing gcc 3.3 compile failures -- fix for www/mod_index_rss

2003-07-22 Thread Simon Barner
--- mod_index_rss.c.origTue Jul 22 04:37:54 2003
+++ mod_index_rss.c Tue Jul 22 04:39:22 2003
@@ -11,18 +11,18 @@
 
 #define TIME_FORMAT %a %b %d %H:%M:%S %Y
 /* This is the XML header file */
-#define HEADER ?xml version=\1.0\ encoding=\UTF-8\?
-
-!DOCTYPE rss PUBLIC \-//Netscape Communications//DTD RSS 0.91//EN\
-\http://www.scripting.com/dtd/rss-0_91.dtd\;
-
-rss version=\0.91\
-
-channel
+#define HEADER ?xml version=\1.0\ encoding=\UTF-8\?\n\
+\n\
+!DOCTYPE rss PUBLIC \-//Netscape Communications//DTD RSS 0.91//EN\\n\
+\http://www.scripting.com/dtd/rss-0_91.dtd\;\n\
+\n\
+rss version=\0.91\\n\
+\n\
+channel\n\
 
 
-#define FOOTER /channel
-/rss
+#define FOOTER /channel\n\
+/rss\n\
 
 
 


signature.asc
Description: Digital signature


sockstat -6

2003-07-22 Thread David Hill
Hello -
I get a mismatch error when i run sockstat -6.  kernel and userland are in sync.


FreeBSD localhost 5.1-CURRENT FreeBSD 5.1-CURRENT #3: Tue Jul 22 07:49:10 EDT 2003 
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/WIND  i386

(david wind:/home/david)% sockstat -6 
sockstat: struct xtcpcb size mismatch
USER COMMANDPID   FD PROTO  LOCAL ADDRESS FOREIGN ADDRESS 




___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Fixing gcc 3.3 compile failures -- patch for graphics/gsculpt

2003-07-22 Thread Simon Barner
patch-Makefile is in order to make the port respect the CC and CXX
variables.

gsculpt-gcc33-patches.tar.gz contains a whole bunch of patches, mostly
'using std::foo' stuff.

Cheers,
 Simon
--- Makefile.orig   Mon Jul 21 19:59:12 2003
+++ MakefileMon Jul 21 19:59:38 2003
@@ -27,7 +27,6 @@
 
 # C
 
-CC := gcc
 CFLAGS  = ${DEPENDFLAGS}
 
 %.o : %.c
@@ -35,7 +34,6 @@
 
 # C++
 
-CXX  := g++
 CXXFLAGS  = ${DEPENDFLAGS}
 
 %.o : %.cc
@@ -57,7 +55,7 @@
 
 # linker
 
-LINKER:= g++
+LINKER:= ${CXX}
 LDFLAGS= 
 LOADLIBES := -O3 -lm `gtk-config --libs`
 


signature.asc
Description: Digital signature


Re: mergemaster broken

2003-07-22 Thread Ruslan Ermilov
On Sun, Jul 06, 2003 at 08:21:14PM -0700, Gregory Neil Shapiro wrote:
   mergemaster -dv
  
  [snip]
  
  cd /usr/src/etc/sendmail; make distribution
  install -o root -g wheel -m 644  /usr/src/etc/sendmail/freebsd.mc freebsd.cf 
  /var/tmp/temproot.0707.11.55/etc/mail
  install: freebsd.cf: No such file or directory
  *** Error code 71
 
 Thanks, I just committed a fix for this.
 
Er,

The correct fix would be to revert this change from sendmail/Makefile,
and fix mergemaster(8) instead, as shown in the attached patch.  The
distribution target of src/etc/Makefile is part of the standard
distribute target, and as such it's just a specialized version of
the install target that should not _build_ anything (and that was
fixed in rev. 1.23).  To build things, one needs to call the all
target, which the attached patch simply does.  It's just a pure
coincidence that the distribution part of src/etc/Makefile does
not need to build anything (in the object directory).

Can you please test it and commit?


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer
Index: mergemaster.sh
===
RCS file: /home/ncvs/src/usr.sbin/mergemaster/mergemaster.sh,v
retrieving revision 1.46
diff -u -r1.46 mergemaster.sh
--- mergemaster.sh  3 May 2003 06:35:19 -   1.46
+++ mergemaster.sh  22 Jul 2003 12:31:23 -
@@ -508,6 +508,7 @@
   esac
   make DESTDIR=${TEMPROOT} distrib-dirs 
   make MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj obj 
+  make MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj all 
   make MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj DESTDIR=${TEMPROOT} \
   distribution;} ||
 { echo '';


pgp0.pgp
Description: PGP signature


Re: Fixing gcc 3.3 compile failures -- patch for graphics/gsculpt

2003-07-22 Thread Simon Barner
 gsculpt-gcc33-patches.tar.gz contains a whole bunch of patches, mostly
 'using std::foo' stuff.

Since the file was cut by the mailing list system: You can find it here:

http://www.leo.org/~barner/freebsd/gsculpt-gcc33-patches.tar.gz


signature.asc
Description: Digital signature


Re: Adaptec AIC7902 Ultra320 Problems

2003-07-22 Thread Sergey A. Osokin
On Tue, Jul 22, 2003 at 01:23:18PM +0100, Lawrence Farr wrote:
 I have a Supermicro SuperServer 6013P-8, with:
 
 ahd0: Adaptec AIC7902 Ultra320 SCSI adapter port
 0x4000-0x40ff,0x4400-0x44ff mem 0xfc30-0xfc301fff irq 5 at device 2.0 on
 pci3
 aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs
 ahd1: Adaptec AIC7902 Ultra320 SCSI adapter port
 0x4800-0x48ff,0x4c00-0x4cff mem 0xfc302000-0xfc303fff irq 5 at device 2.1 on
 pci3
 aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs
 
 Trying to install 5.1-CURRENT-20030709-JPSNAP or 4.8-STABLE on the
 box gives a timeout error that will hang the disk in a state that
 resetting the machine does not clear, and only power cycling will
 clear. Ive replaced the disks with no change, but installed and
 ran Redhat 7.3 on the box with no timeouts or errors.
 
 The full dmesg is here:
 http://aticatac.epcdirect.co.uk/~l.farr/6013P8_dmesg.txt
 
 And timeout is here:
 http://aticatac.epcdirect.co.uk/~l.farr/AIC7902_timeout.txt

Try to switch your adapter from Ultra320 to Ultra160 mode, then
try to install again.

-- 

Rgdz,/\  ASCII RIBBON CAMPAIGN
Sergey Osokin aka oZZ,   \ /AGAINST HTML MAIL
http://ozz.pp.ru/ X  AND NEWS
 / \
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


RE: Adaptec AIC7902 Ultra320 Problems

2003-07-22 Thread Lawrence Farr
OK, gave that a go, and still the same. Im assuming you meant
to set it to 160 in the Adaptec bios? It shows up as 160Mb 
transfers in the dmesg now.

Any other ideas I can try?

Lawrence Farr
EPC Direct Limited 

 -Original Message-
 From: Sergey A. Osokin [mailto:[EMAIL PROTECTED] 
 Sent: 22 July 2003 13:43
 To: Lawrence Farr
 Cc: [EMAIL PROTECTED]
 Subject: Re: Adaptec AIC7902 Ultra320 Problems
 
 
 On Tue, Jul 22, 2003 at 01:23:18PM +0100, Lawrence Farr wrote:
  I have a Supermicro SuperServer 6013P-8, with:
  
  ahd0: Adaptec AIC7902 Ultra320 SCSI adapter port
  0x4000-0x40ff,0x4400-0x44ff mem 0xfc30-0xfc301fff irq 5 
 at device 2.0 on
  pci3
  aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 
 101-133Mhz, 512 SCBs
  ahd1: Adaptec AIC7902 Ultra320 SCSI adapter port
  0x4800-0x48ff,0x4c00-0x4cff mem 0xfc302000-0xfc303fff irq 5 
 at device 2.1 on
  pci3
  aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 
 101-133Mhz, 512 SCBs
  
  Trying to install 5.1-CURRENT-20030709-JPSNAP or 4.8-STABLE on the
  box gives a timeout error that will hang the disk in a state that
  resetting the machine does not clear, and only power cycling will
  clear. Ive replaced the disks with no change, but installed and
  ran Redhat 7.3 on the box with no timeouts or errors.
  
  The full dmesg is here:
  http://aticatac.epcdirect.co.uk/~l.farr/6013P8_dmesg.txt
  
  And timeout is here:
  http://aticatac.epcdirect.co.uk/~l.farr/AIC7902_timeout.txt
 
 Try to switch your adapter from Ultra320 to Ultra160 mode, then
 try to install again.
 
 -- 
 
 Rgdz,/\  ASCII RIBBON CAMPAIGN
 Sergey Osokin aka oZZ,   \ /AGAINST HTML MAIL
 http://ozz.pp.ru/ X  AND NEWS
  / \
 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Does linux-sun-jdk_1.4.2 work?

2003-07-22 Thread Dag-Erling Smørgrav
Adam [EMAIL PROTECTED] writes:
 Perhaps you should try working with Java 1.4.x on FreeBSD before you
 assume something about me that's highly inaccurate. I think you'll find
 very quickly that it doesn't work nicely unless the process is running
 as root. 

I use it daily and have never had any trouble (except for the broken
Xalan in 1.4.1).

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Adaptec AIC7902 Ultra320 Problems

2003-07-22 Thread Scott Long
Lawrence Farr wrote:
I have a Supermicro SuperServer 6013P-8, with:

ahd0: Adaptec AIC7902 Ultra320 SCSI adapter port
0x4000-0x40ff,0x4400-0x44ff mem 0xfc30-0xfc301fff irq 5 at device 2.0 on
pci3
aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs
ahd1: Adaptec AIC7902 Ultra320 SCSI adapter port
0x4800-0x48ff,0x4c00-0x4cff mem 0xfc302000-0xfc303fff irq 5 at device 2.1 on
pci3
aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs
Trying to install 5.1-CURRENT-20030709-JPSNAP or 4.8-STABLE on the
box gives a timeout error that will hang the disk in a state that
resetting the machine does not clear, and only power cycling will
clear. Ive replaced the disks with no change, but installed and
ran Redhat 7.3 on the box with no timeouts or errors.
The full dmesg is here:
http://aticatac.epcdirect.co.uk/~l.farr/6013P8_dmesg.txt
And timeout is here:
http://aticatac.epcdirect.co.uk/~l.farr/AIC7902_timeout.txt
Lawrence Farr
EPC Direct Limited 
Timeouts usually point to interrupt routing problems.  Try booting with
ACPI turned off.
Scott

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Does linux-sun-jdk_1.4.2 work?

2003-07-22 Thread Evan Dower
I have certainly had some frustration with Java on FreeBSD, but for the most 
part it works for me. In fact, I wrote a pure Java program that only seems 
to work on FreeBSD. On Windows, it crashes inside Java's regex code, so 
there's one place where FreeBSD works better ;-)
Evan Dower


From: [EMAIL PROTECTED] (Dag-Erling Smørgrav)
To: Adam [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: Does linux-sun-jdk_1.4.2 work?
Date: Tue, 22 Jul 2003 16:29:57 +0200
Adam [EMAIL PROTECTED] writes:
 Perhaps you should try working with Java 1.4.x on FreeBSD before you
 assume something about me that's highly inaccurate. I think you'll find
 very quickly that it doesn't work nicely unless the process is running
 as root.
I use it daily and have never had any trouble (except for the broken
Xalan in 1.4.1).
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
_
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


RE: Adaptec AIC7902 Ultra320 Problems

2003-07-22 Thread Lawrence Farr
It still does the same timeout and hangs the disc. Theres the option
of Installed OS which you can set to Other, Win95, Win98, WinME
or Win2000. (I've only tried Other and Win2000 in all honesty).

Lawrence Farr
EPC Direct Limited 

 -Original Message-
 From: Scott Long [mailto:[EMAIL PROTECTED] 
 Sent: 22 July 2003 16:12
 To: Lawrence Farr
 Cc: [EMAIL PROTECTED]
 Subject: Re: Adaptec AIC7902 Ultra320 Problems
 
 
 Lawrence Farr wrote:
  I have a Supermicro SuperServer 6013P-8, with:
  
  ahd0: Adaptec AIC7902 Ultra320 SCSI adapter port
  0x4000-0x40ff,0x4400-0x44ff mem 0xfc30-0xfc301fff irq 5 
 at device 2.0 on
  pci3
  aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 
 101-133Mhz, 512 SCBs
  ahd1: Adaptec AIC7902 Ultra320 SCSI adapter port
  0x4800-0x48ff,0x4c00-0x4cff mem 0xfc302000-0xfc303fff irq 5 
 at device 2.1 on
  pci3
  aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 
 101-133Mhz, 512 SCBs
  
  Trying to install 5.1-CURRENT-20030709-JPSNAP or 4.8-STABLE on the
  box gives a timeout error that will hang the disk in a state that
  resetting the machine does not clear, and only power cycling will
  clear. Ive replaced the disks with no change, but installed and
  ran Redhat 7.3 on the box with no timeouts or errors.
  
  The full dmesg is here:
  http://aticatac.epcdirect.co.uk/~l.farr/6013P8_dmesg.txt
  
  And timeout is here:
  http://aticatac.epcdirect.co.uk/~l.farr/AIC7902_timeout.txt
  
  Lawrence Farr
  EPC Direct Limited 
 
 Timeouts usually point to interrupt routing problems.  Try 
 booting with
 ACPI turned off.
 
 Scott
 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Does linux-sun-jdk_1.4.2 work?

2003-07-22 Thread Adam Migus

Adam said:
 Eh, there's no need to flaming here. I never said
 maintaining Java on
 FreeBSD was easy. I said that Java support on FreeBSD
 is dodgy, which is
 really a well-known public fact, for anyone that's ever
 done any reading
 on the subject. In fact, when the core developers give
 a public
 interview, this is frequently a topic of discussion.

I was addressing the fact that you took it upon
yourself to _tell_ the mailing-list readers that the
port was released to early.  You aren't the maintainer
of this or any other port.  Therefor unless you stick
an in my opinion in there you kind of sound like an
ass...
I made no comments about the reliability of Java on
FreeBSD although I have read there are issues (thanks
for assuming I didn't) but I use it routinely without
problems.

 Perhaps you should try working with Java 1.4.x on
 FreeBSD before you
 assume something about me that's highly inaccurate. I
 think you'll find
 very quickly that it doesn't work nicely unless the
 process is running
 as root.

My apologies for being highly inaccurate.  Why don't
you tell me _why_ Java 1.4.x only works nicely on
_your_ system when running as root?  Hint: ktrace is
your friend.

-- 
Adam Migus - Research Scientist
Network Associates Laboratories (http://www.nailabs.com)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


USB umass data corruption

2003-07-22 Thread Jan-Espen Pettersen
These two commits seems to have introduced a data corruption problem
with my digital camera (USB umass device):

http://lists.freebsd.org/pipermail/cvs-src/2003-July/007150.html
http://lists.freebsd.org/pipermail/cvs-src/2003-July/007153.html

I was able to read valid jpeg images from the camera before the first
commit. Between those two commits umass was completely broken, TIMEOUTs,
etc. After the second commit the files were just garbage (or garbage
mixed with parts of the real image).


dmesg and uname -a:

You have mail.
endeavour.sigsegv# dmesg
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights
reserved.
FreeBSD 5.1-CURRENT #15: Tue Jul 22 17:22:12 CEST 2003
   
[EMAIL PROTECTED]:/usr/obj/usr/src/FreeBSD-CURRENT/sys/ENDEAVOUR
Preloaded elf kernel /boot/kernel/kernel at 0xc04a9000.
Preloaded elf module /boot/kernel/linux.ko at 0xc04a9244.
Timecounter i8254  frequency 1193182 Hz
Timecounter TSC  frequency 2102998575 Hz
CPU: AMD Athlon(tm) XP (2103.00-MHz 686-class CPU)
  Origin = AuthenticAMD  Id = 0x681  Stepping = 1
 
Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
  AMD Features=0xc040AMIE,DSP,3DNow!
real memory  = 528416768 (503 MB)
avail memory = 508133376 (484 MB)
Pentium Pro MTRR support enabled
npx0: math processor on motherboard
npx0: INT 16 interface
pcibios: BIOS version 2.10
Using $PIR table, 11 entries at 0xc00fdeb0
pcib0: Host to PCI bridge at pcibus 0 on motherboard
pci0: PCI bus on pcib0
pci0: memory, RAM at device 0.1 (no driver attached)
pci0: memory, RAM at device 0.2 (no driver attached)
pci0: memory, RAM at device 0.3 (no driver attached)
pci0: memory, RAM at device 0.4 (no driver attached)
pci0: memory, RAM at device 0.5 (no driver attached)
isab0: PCI-ISA bridge at device 1.0 on pci0
isa0: ISA bus on isab0
pci0: serial bus, SMBus at device 1.1 (no driver attached)
ohci0: OHCI (generic) USB controller mem 0xef003000-0xef003fff irq 11
at device 2.0 on pci0
usb0: OHCI version 1.0, legacy support
usb0: OHCI (generic) USB controller on ohci0
usb0: USB revision 1.0
uhub0: (0x10de) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
ohci1: OHCI (generic) USB controller mem 0xef004000-0xef004fff irq 5
at device 2.1 on pci0
usb1: OHCI version 1.0, legacy support
usb1: OHCI (generic) USB controller on ohci1
usb1: USB revision 1.0
uhub1: (0x10de) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 3 ports with 3 removable, self powered
pci0: serial bus, USB at device 2.2 (no driver attached)
pci0: network, ethernet at device 4.0 (no driver attached)
pci0: multimedia, audio at device 6.0 (no driver attached)
pcib1: PCIBIOS PCI-PCI bridge at device 8.0 on pci0
pci1: PCI bus on pcib1
pci_cfgintr: 1:10 INTA BIOS irq 10
rl0: RealTek 8139 10/100BaseTX, rev. D port 0xc000-0xc0ff mem
0xee00-0xeeff irq 10 at device 10.0 on pci1
rl0: Ethernet address: 00:0a:cd:05:58:21
miibus0: MII bus on rl0
rlphy0: RealTek internal media interface on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
atapci0: nVidia nForce2 UDMA133 controller port 0xf000-0xf00f at
device 9.0 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pcib2: PCI-PCI bridge at device 30.0 on pci0
pci2: PCI bus on pcib2
pci2: display, VGA at device 0.0 (no driver attached)
pmtimer0 on isa0
atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port
0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5 drive on fdc0 drive 0
sc0: System console at flags 0x100 on isa0
sc0: VGA 16 virtual consoles, flags=0x300
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on
isa0
unknown: PNP0303 can't assign resources (port)
unknown: PNP0f13 can't assign resources (irq)
unknown: PNP0700 can't assign resources (port)
Timecounters tick every 10.000 msec
ad0: 76319MB ST380011A [155061/16/63] at ata0-master UDMA100
acd0: CDROM CD-ROM 56X/AKH at ata1-master PIO4
Mounting root from ufs:/dev/ad0s1a
pcm0: Nvidia nForce2 port 0xd800-0xd87f,0xd400-0xd4ff mem
0xef001000-0xef001fff irq 11 at device 6.0 on pci0
pcm0: Avance Logic ALC650 AC97 Codec
malloc() of 16 with the following non-sleepablelocks held:
exclusive sleep mutex pcm0 (sound cdev) r = 0 (0xc41bc1c0) locked @
/usr/src/FreeBSD-CURRENT/sys/dev/sound/pcm/sound.c:163
malloc() of 128 with the following non-sleepablelocks held:
exclusive sleep mutex pcm0 (sound cdev) r = 0 (0xc41bc1c0) locked @
/usr/src/FreeBSD-CURRENT/sys/dev/sound/pcm/sound.c:163
malloc() of 16 with the following non-sleepablelocks held:
exclusive sleep mutex pcm0 (sound cdev) r = 0 (0xc41bc1c0) locked @

make release broken [FIX]

2003-07-22 Thread Ruslan Ermilov
Hi!

As many of you probably know, recent telnet commit broke snapshot
building.  Since I needed a working make release to go on with
my task on floppy-less make release (for AMD64, etc.), I had to
just fix it.  Attached is the patch.  It also fixes another issue
with this telnet commit: it ensures that crypto telnet[d] do not
end up in the base distribution.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer
Index: release/Makefile
===
RCS file: /home/ncvs/src/release/Makefile,v
retrieving revision 1.787
diff -u -r1.787 Makefile
--- release/Makefile4 Jul 2003 14:39:17 -   1.787
+++ release/Makefile21 Jul 2003 20:14:33 -
@@ -236,7 +236,8 @@
 .if !defined(FIXCRYPTO)
 FIXCRYPTO!=cd ${.CURDIR}/../kerberos5; ${MAKE} -V KPROGS
 FIXCRYPTO+=bin/ed usr.sbin/ppp usr.sbin/pppd usr.sbin/tcpdump/tcpdump \
-   lib/libfetch usr.bin/fetch
+   lib/libfetch usr.bin/fetch \
+   lib/libtelnet libexec/telnetd usr.bin/telnet
 .if !defined(NO_SENDMAIL)
 FIXCRYPTO+=usr.sbin/sendmail
 .endif
Index: lib/libtelnet/Makefile
===
RCS file: /home/ncvs/src/lib/libtelnet/Makefile,v
retrieving revision 1.16
diff -u -r1.16 Makefile
--- lib/libtelnet/Makefile  20 Jul 2003 23:29:46 -  1.16
+++ lib/libtelnet/Makefile  21 Jul 2003 19:58:26 -
@@ -13,10 +13,10 @@
 
 WARNS?=2
 
-.if !defined(NOCRYPT)  !defined(NO_OPENSSL)
+.if exists(${.CURDIR}/../../crypto)  !defined(NOCRYPT)  !defined(NO_OPENSSL)
 SRCS+= encrypt.c auth.c enc_des.c sra.c pk.c
 CFLAGS+=   -DENCRYPTION -DAUTHENTICATION -DSRA
-.if !defined(NO_KERBEROS)
+.if exists(${.CURDIR}/../../kerberos5)  !defined(NO_KERBEROS)
 SRCS+= kerberos5.c
 CFLAGS+=   -DKRB5 -I${KRB5DIR}/lib/krb5 -I${KRB5OBJDIR} -I${ASN1OBJDIR}
 CFLAGS+=   -DFORWARD -Dnet_write=telnet_net_write
Index: libexec/telnetd/Makefile
===
RCS file: /home/ncvs/src/libexec/telnetd/Makefile,v
retrieving revision 1.21
diff -u -r1.21 Makefile
--- libexec/telnetd/Makefile20 Jul 2003 23:29:46 -  1.21
+++ libexec/telnetd/Makefile21 Jul 2003 20:19:17 -
@@ -28,12 +28,13 @@
 DPADD= ${LIBUTIL} ${LIBTERMCAP} ${LIBTELNET}
 LDADD= -lutil -ltermcap ${LIBTELNET}
 
-.if !defined(NOCRYPT)  !defined(NO_OPENSSL)
+.if exists(${.CURDIR}/../../crypto)  !defined(NOCRYPT)  !defined(NO_OPENSSL)
+DISTRIBUTION=  crypto
 SRCS+= authenc.c
 CFLAGS+=   -DAUTHENTICATION -DENCRYPTION
 DPADD+=${LIBMP} ${LIBCRYPTO} ${LIBCRYPT} ${LIBPAM}
 LDADD+=-lmp -lcrypto -lcrypt ${MINUSLPAM}
-.if !defined(NO_KERBEROS)
+.if exists(${.CURDIR}/../../kerberos5)  !defined(NO_KERBEROS)
 CFLAGS+=   -DKRB5 -DFORWARD -Dnet_write=telnet_net_write
 DPADD+=${LIBKRB5} ${LIBASN1} ${LIBROKEN} ${LIBCOM_ERR}
 LDADD+=-lkrb5 -lasn1 -lroken -lcom_err
Index: usr.bin/telnet/Makefile
===
RCS file: /home/ncvs/src/usr.bin/telnet/Makefile,v
retrieving revision 1.23
diff -u -r1.23 Makefile
--- usr.bin/telnet/Makefile 20 Jul 2003 23:29:46 -  1.23
+++ usr.bin/telnet/Makefile 22 Jul 2003 11:41:02 -
@@ -20,25 +20,26 @@
 DPADD= ${LIBTERMCAP} ${LIBTELNET}
 LDADD= -ltermcap ${LIBTELNET}
 
-.if !defined(RELEASE_CRUNCH)
-CFLAGS+=   -DINET6 -DIPSEC
-DPADD+=${LIBIPSEC}
-LDADD+=-lipsec
-.else
+.if defined(RELEASE_CRUNCH)
 .PATH: ${TELNETDIR}/libtelnet
 SRCS+= genget.c getent.c misc.c
 CFLAGS+=   -DHAS_CGETENT
-.endif
+.else
+CFLAGS+=   -DINET6 -DIPSEC
+DPADD+=${LIBIPSEC}
+LDADD+=-lipsec
 
-.if !defined(NOCRYPT)  !defined(NO_OPENSSL)
+.if exists(${.CURDIR}/../../crypto)  !defined(NOCRYPT)  !defined(NO_OPENSSL)
+DISTRIBUTION=  crypto
 SRCS+= authenc.c 
 CFLAGS+=   -DENCRYPTION -DAUTHENTICATION -DIPSEC
 DPADD+=${LIBMP} ${LIBCRYPTO} ${LIBCRYPT} ${LIBIPSEC} ${LIBPAM}
 LDADD+=-lmp -lcrypto -lcrypt -lipsec ${MINUSLPAM}
-.if !defined(NO_KERBEROS)
+.if exists(${.CURDIR}/../../kerberos5)  !defined(NO_KERBEROS)
 CFLAGS+=   -DKRB5 -DFORWARD -Dnet_write=telnet_net_write
 DPADD+=${LIBKRB5} ${LIBASN1} ${LIBCOM_ERR} ${LIBROKEN}
 LDADD+=-lkrb5 -lasn1 -lcom_err -lroken
+.endif
 .endif
 .endif
 


pgp0.pgp
Description: PGP signature


Re: Adaptec AIC7902 Ultra320 Problems

2003-07-22 Thread Justin T. Gibbs
 I have a Supermicro SuperServer 6013P-8, with:
 
 ahd0: Adaptec AIC7902 Ultra320 SCSI adapter port
 0x4000-0x40ff,0x4400-0x44ff mem 0xfc30-0xfc301fff irq 5 at device 2.0 on
 pci3
 aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs
 ahd1: Adaptec AIC7902 Ultra320 SCSI adapter port
 0x4800-0x48ff,0x4c00-0x4cff mem 0xfc302000-0xfc303fff irq 5 at device 2.1 on
 pci3
 aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs
 
 Trying to install 5.1-CURRENT-20030709-JPSNAP or 4.8-STABLE on the
 box gives a timeout error that will hang the disk in a state that
 resetting the machine does not clear, and only power cycling will
 clear. Ive replaced the disks with no change, but installed and
 ran Redhat 7.3 on the box with no timeouts or errors.

The problem you are encountering looks to be a drive firmware issue
exposed when the drive is running at high queue depths.  The linux
driver limites the tag depth to 32 by default.  The FreeBSD driver
does not throttle in this way.  It seems that we just overwhelm the
drive with commands and it just stops doing anything on the bus.  According
to the timeout trace, the target just stopped sending packets while
still sitting on the bus.

I have not tested this particular drive, so I do not know if update
firmware is available for it.  You might try running in non-packetized
mode by toggling this option via SCSI-Select.  You previous test of
running at 160 just reduced the clock rate, but still allowed the use
of the newer, faster, packetized format.

--
Justin

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: make release broken [FIX]

2003-07-22 Thread Mark Murray
This is on my TODO.

Do not commit this - I have a much cleaner fix.

M

Ruslan Ermilov writes:
 
 --v9Ux+11Zm5mwPlX6
 Content-Type: multipart/mixed; boundary=a8Wt8u1KmwUX3Y2C
 Content-Disposition: inline
 
 
 --a8Wt8u1KmwUX3Y2C
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 Hi!
 
 As many of you probably know, recent telnet commit broke snapshot
 building.  Since I needed a working make release to go on with
 my task on floppy-less make release (for AMD64, etc.), I had to
 just fix it.  Attached is the patch.  It also fixes another issue
 with this telnet commit: it ensures that crypto telnet[d] do not
 end up in the base distribution.
 
 
 Cheers,
 --=20
 Ruslan ErmilovSysadmin and DBA,
 [EMAIL PROTECTED] Sunbay Software Ltd,
 [EMAIL PROTECTED] FreeBSD committer
 
 --a8Wt8u1KmwUX3Y2C
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename=p
 Content-Transfer-Encoding: quoted-printable
 
 Index: release/Makefile
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 RCS file: /home/ncvs/src/release/Makefile,v
 retrieving revision 1.787
 diff -u -r1.787 Makefile
 --- release/Makefile  4 Jul 2003 14:39:17 -   1.787
 +++ release/Makefile  21 Jul 2003 20:14:33 -
 @@ -236,7 +236,8 @@
  .if !defined(FIXCRYPTO)
  FIXCRYPTO!=3Dcd ${.CURDIR}/../kerberos5; ${MAKE} -V KPROGS
  FIXCRYPTO+=3Dbin/ed usr.sbin/ppp usr.sbin/pppd usr.sbin/tcpdump/tcpd
 ump \
 - lib/libfetch usr.bin/fetch
 + lib/libfetch usr.bin/fetch \
 + lib/libtelnet libexec/telnetd usr.bin/telnet
  .if !defined(NO_SENDMAIL)
  FIXCRYPTO+=3Dusr.sbin/sendmail
  .endif
 Index: lib/libtelnet/Makefile
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 RCS file: /home/ncvs/src/lib/libtelnet/Makefile,v
 retrieving revision 1.16
 diff -u -r1.16 Makefile
 --- lib/libtelnet/Makefile20 Jul 2003 23:29:46 -  1.16
 +++ lib/libtelnet/Makefile21 Jul 2003 19:58:26 -
 @@ -13,10 +13,10 @@
 =20
  WARNS?=3D2
 =20
 -.if !defined(NOCRYPT)  !defined(NO_OPENSSL)
 +.if exists(${.CURDIR}/../../crypto)  !defined(NOCRYPT)  !defined(NO_OP=
 ENSSL)
  SRCS+=3D encrypt.c auth.c enc_des.c sra.c pk.c
  CFLAGS+=3D   -DENCRYPTION -DAUTHENTICATION -DSRA
 -.if !defined(NO_KERBEROS)
 +.if exists(${.CURDIR}/../../kerberos5)  !defined(NO_KERBEROS)
  SRCS+=3D kerberos5.c
  CFLAGS+=3D   -DKRB5 -I${KRB5DIR}/lib/krb5 -I${KRB5OBJDIR} -I${ASN1OBJDIR}
  CFLAGS+=3D   -DFORWARD -Dnet_write=3Dtelnet_net_write
 Index: libexec/telnetd/Makefile
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 RCS file: /home/ncvs/src/libexec/telnetd/Makefile,v
 retrieving revision 1.21
 diff -u -r1.21 Makefile
 --- libexec/telnetd/Makefile  20 Jul 2003 23:29:46 -  1.21
 +++ libexec/telnetd/Makefile  21 Jul 2003 20:19:17 -
 @@ -28,12 +28,13 @@
  DPADD=3D ${LIBUTIL} ${LIBTERMCAP} ${LIBTELNET}
  LDADD=3D -lutil -ltermcap ${LIBTELNET}
 =20
 -.if !defined(NOCRYPT)  !defined(NO_OPENSSL)
 +.if exists(${.CURDIR}/../../crypto)  !defined(NOCRYPT)  !defined(NO_OP=
 ENSSL)
 +DISTRIBUTION=3D  crypto
  SRCS+=3D authenc.c
  CFLAGS+=3D   -DAUTHENTICATION -DENCRYPTION
  DPADD+=3D${LIBMP} ${LIBCRYPTO} ${LIBCRYPT} ${LIBPAM}
  LDADD+=3D-lmp -lcrypto -lcrypt ${MINUSLPAM}
 -.if !defined(NO_KERBEROS)
 +.if exists(${.CURDIR}/../../kerberos5)  !defined(NO_KERBEROS)
  CFLAGS+=3D   -DKRB5 -DFORWARD -Dnet_write=3Dtelnet_net_write
  DPADD+=3D${LIBKRB5} ${LIBASN1} ${LIBROKEN} ${LIBCOM_ERR}
  LDADD+=3D-lkrb5 -lasn1 -lroken -lcom_err
 Index: usr.bin/telnet/Makefile
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 RCS file: /home/ncvs/src/usr.bin/telnet/Makefile,v
 retrieving revision 1.23
 diff -u -r1.23 Makefile
 --- usr.bin/telnet/Makefile   20 Jul 2003 23:29:46 -  1.23
 +++ usr.bin/telnet/Makefile   22 Jul 2003 11:41:02 -
 @@ -20,25 +20,26 @@
  DPADD=3D ${LIBTERMCAP} ${LIBTELNET}
  LDADD=3D -ltermcap ${LIBTELNET}
 =20
 -.if !defined(RELEASE_CRUNCH)
 -CFLAGS+=3D   -DINET6 -DIPSEC
 -DPADD+=3D${LIBIPSEC}
 -LDADD+=3D-lipsec
 -.else
 +.if defined(RELEASE_CRUNCH)
  .PATH: ${TELNETDIR}/libtelnet
  

Re: Fatal trap 12: page fault while in kernel mode

2003-07-22 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
Bjoern A. Zeeb [EMAIL PROTECTED] writes:
: On Mon, 21 Jul 2003, Noriyoshi Kawano wrote:
: 
:  I have similar problem.
:  disable re-route interrupts.
:  It's works fine.
: 
:  --- /sys/dev/pci/pci.c.orig Tue Jul  1 23:08:32 2003
:  +++ /sys/dev/pci/pci.c  Mon Jul 21 11:04:55 2003
:  @@ -800,7 +800,7 @@
:  }
: 
:  if (cfg-intpin  0  PCI_INTERRUPT_VALID(cfg-intline)) {
:  -#if defined(__ia64__) || (defined(__i386__)  !defined(SMP))
:  +#if defined(__ia64__)
:  /*
:   * Try to re-route interrupts. Sometimes the BIOS or
:   * firmware may leave bogus values in these registers.
: 
: 
: Thanks. This works fine. Is there any global solution to the problem
: so that I won't need to patch again the time 5.2R comes out ?

I'm just catching the tail end of this problem report.  What problem
is solved by not rotuing interrupts?

I'm guessing it is the we don't setup things correctly to call some
BIOSes or some older pci bioses lie to us so we shoot our selves
when we believe the lies or something like that.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: mergemaster broken

2003-07-22 Thread Doug Barton
I'll take a look at this, thanks.

On Tue, 22 Jul 2003, Ruslan Ermilov wrote:

 On Sun, Jul 06, 2003 at 08:21:14PM -0700, Gregory Neil Shapiro wrote:
mergemaster -dv
  
   [snip]
  
   cd /usr/src/etc/sendmail; make distribution
   install -o root -g wheel -m 644  /usr/src/etc/sendmail/freebsd.mc freebsd.cf 
   /var/tmp/temproot.0707.11.55/etc/mail
   install: freebsd.cf: No such file or directory
   *** Error code 71
 
  Thanks, I just committed a fix for this.
 
 Er,

 The correct fix would be to revert this change from sendmail/Makefile,
 and fix mergemaster(8) instead, as shown in the attached patch.  The
 distribution target of src/etc/Makefile is part of the standard
 distribute target, and as such it's just a specialized version of
 the install target that should not _build_ anything (and that was
 fixed in rev. 1.23).  To build things, one needs to call the all
 target, which the attached patch simply does.  It's just a pure
 coincidence that the distribution part of src/etc/Makefile does
 not need to build anything (in the object directory).

 Can you please test it and commit?


 Cheers,


-- 

This .signature sanitized for your protection
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Buildworld fails in 5.1

2003-07-22 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
Tim Kientzle [EMAIL PROTECTED] writes:
: Gordon Tetlow wrote:
:  On Mon, Jul 21, 2003 at 09:36:37AM -0700, Tim Kientzle wrote:
: Hmmm...  Is that what .ORDER is for?  To work around a
: parallel make that gratuitously rebuilds things?
:  
:  Right it serializes build dependencies. The problem with crunchgen ...
: 
: I would argue the problem with make... ;-)  I think it's pretty
: clear that
: 
: a b c: foo
:  buildabc
: 
: does not require that 'buildabc' be run three times.  Make
: should be able to note that 'buildabc' was already spawned
: for 'a' and just add 'b' and 'c' to the wait list for
: that operation, rather than running additional copies.

That's not how make works.

a b c: foo
buildabc

is the same as:

a: foo
buildabc
b: foo
buildabc
c: foo
buildabc
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


RE: make release broken [FIX]

2003-07-22 Thread John Baldwin

On 22-Jul-2003 Ruslan Ermilov wrote:
 Hi!
 
 As many of you probably know, recent telnet commit broke snapshot
 building.  Since I needed a working make release to go on with
 my task on floppy-less make release (for AMD64, etc.), I had to
 just fix it.  Attached is the patch.  It also fixes another issue
 with this telnet commit: it ensures that crypto telnet[d] do not
 end up in the base distribution.

Why not simply enable 'NO_FLOPPIES' on the arch's that don't want
floppies?

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: make release broken [FIX]

2003-07-22 Thread Ruslan Ermilov
On Tue, Jul 22, 2003 at 02:26:34PM -0400, John Baldwin wrote:
 
 On 22-Jul-2003 Ruslan Ermilov wrote:
  Hi!
  
  As many of you probably know, recent telnet commit broke snapshot
  building.  Since I needed a working make release to go on with
  my task on floppy-less make release (for AMD64, etc.), I had to
  just fix it.  Attached is the patch.  It also fixes another issue
  with this telnet commit: it ensures that crypto telnet[d] do not
  end up in the base distribution.
 
 Why not simply enable 'NO_FLOPPIES' on the arch's that don't want
 floppies?
 
Because NO_FLOPPIES doesn't mean like it sounds; it means do not
create floppy _images_, and we want to skip much more than that.
I have a preliminary patch that is currently under the make
release test.  Let me know (or anyone else) if you want to review
it or the final version before I commit it.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: Fatal trap 12: page fault while in kernel mode

2003-07-22 Thread Bjoern A. Zeeb
On Tue, 22 Jul 2003, M. Warner Losh wrote:

Hi,

 In message: [EMAIL PROTECTED]
 Bjoern A. Zeeb [EMAIL PROTECTED] writes:
 : On Mon, 21 Jul 2003, Noriyoshi Kawano wrote:
 :
 :  I have similar problem.
 :  disable re-route interrupts.
 :  It's works fine.
 : 
 :  --- /sys/dev/pci/pci.c.orig   Tue Jul  1 23:08:32 2003
 :  +++ /sys/dev/pci/pci.cMon Jul 21 11:04:55 2003
 :  @@ -800,7 +800,7 @@
 :}
 : 
 :if (cfg-intpin  0  PCI_INTERRUPT_VALID(cfg-intline)) {
 :  -#if defined(__ia64__) || (defined(__i386__)  !defined(SMP))
 :  +#if defined(__ia64__)
 :/*
 : * Try to re-route interrupts. Sometimes the BIOS or
 : * firmware may leave bogus values in these registers.
 :
 :
 : Thanks. This works fine. Is there any global solution to the problem
 : so that I won't need to patch again the time 5.2R comes out ?

 I'm just catching the tail end of this problem report.  What problem
 is solved by not rotuing interrupts?

${SUBJECT}
the machine boots again and doesn't panic at boot time.

for more information please se my initial post.
@see http://lists.freebsd.org/pipermail/freebsd-current/2003-July/007155.html


 I'm guessing it is the we don't setup things correctly to call some
 BIOSes or some older pci bioses lie to us so we shoot our selves
 when we believe the lies or something like that.

I never debugged why this started to happen between 5.1R and HEAD.
The machine is a Compaq DeskPro or s.th. like this; ~ 2 years - so
not that old but perhaps with a strange BIOS. It had run fine with
4.x and 5.0R and booted a 5.1R for building HEAD.

Noriyoshi Kawano came up with the patch that made it boot again so I
am happy but as this doesn't seem to happen for many people and the
patch is not mainline I asked if there is any better solution to make
it work on b0rken machines and mainline.

-- 
Bjoern A. Zeeb  bzeeb at Zabbadoz dot NeT
56 69 73 69 74  http://www.zabbadoz.net/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: make release broken [FIX]

2003-07-22 Thread John Baldwin

On 22-Jul-2003 Ruslan Ermilov wrote:
 On Tue, Jul 22, 2003 at 02:26:34PM -0400, John Baldwin wrote:
 
 On 22-Jul-2003 Ruslan Ermilov wrote:
  Hi!
  
  As many of you probably know, recent telnet commit broke snapshot
  building.  Since I needed a working make release to go on with
  my task on floppy-less make release (for AMD64, etc.), I had to
  just fix it.  Attached is the patch.  It also fixes another issue
  with this telnet commit: it ensures that crypto telnet[d] do not
  end up in the base distribution.
 
 Why not simply enable 'NO_FLOPPIES' on the arch's that don't want
 floppies?
 
 Because NO_FLOPPIES doesn't mean like it sounds; it means do not
 create floppy _images_, and we want to skip much more than that.
 I have a preliminary patch that is currently under the make
 release test.  Let me know (or anyone else) if you want to review
 it or the final version before I commit it.

Are you eliminating the mfsroot?  All the bootable CD's use
that right now, so what more are you doing than eliminating
the floppy images?

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: make release broken [FIX]

2003-07-22 Thread Ruslan Ermilov
On Tue, Jul 22, 2003 at 02:45:52PM -0400, John Baldwin wrote:
 
 On 22-Jul-2003 Ruslan Ermilov wrote:
  On Tue, Jul 22, 2003 at 02:26:34PM -0400, John Baldwin wrote:
  
  On 22-Jul-2003 Ruslan Ermilov wrote:
   Hi!
   
   As many of you probably know, recent telnet commit broke snapshot
   building.  Since I needed a working make release to go on with
   my task on floppy-less make release (for AMD64, etc.), I had to
   just fix it.  Attached is the patch.  It also fixes another issue
   with this telnet commit: it ensures that crypto telnet[d] do not
   end up in the base distribution.
  
  Why not simply enable 'NO_FLOPPIES' on the arch's that don't want
  floppies?
  
  Because NO_FLOPPIES doesn't mean like it sounds; it means do not
  create floppy _images_, and we want to skip much more than that.
  I have a preliminary patch that is currently under the make
  release test.  Let me know (or anyone else) if you want to review
  it or the final version before I commit it.
 
 Are you eliminating the mfsroot?
 
Yes.

 All the bootable CD's use
 that right now, so what more are you doing than eliminating
 the floppy images?
 
Part of the patch for the iso.1 target has this (cut-n-pasted):

@@ -885,10 +873,7 @@
 .if ${TARGET} != pc98
@echo Setting up /boot
@rm -f ${CD_DISC2}/boot/loader.conf
-   @cp ${RD}/mfsroot/mfsroot.gz ${CD_DISC2}/boot/mfsroot.gz
-   @echo 'mfsroot_load=YES'  ${CD_DISC2}/boot/loader.conf
-   @echo 'mfsroot_type=mfs_root'  ${CD_DISC2}/boot/loader.conf
-   @echo 'mfsroot_name=/boot/mfsroot'  ${CD_DISC2}/boot/loader.conf
+   @echo 'init_path=/usr/sbin/sysinstall'  ${CD_DISC2}/boot/loader.conf
@cp -Rp ${CD_DISC2}/boot ${CD_DISC1}
 .endif
 .if !defined(NOPORTS)


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: make release broken [FIX]

2003-07-22 Thread John Baldwin

On 22-Jul-2003 Ruslan Ermilov wrote:
 On Tue, Jul 22, 2003 at 02:45:52PM -0400, John Baldwin wrote:
 
 On 22-Jul-2003 Ruslan Ermilov wrote:
  On Tue, Jul 22, 2003 at 02:26:34PM -0400, John Baldwin wrote:
  
  On 22-Jul-2003 Ruslan Ermilov wrote:
   Hi!
   
   As many of you probably know, recent telnet commit broke snapshot
   building.  Since I needed a working make release to go on with
   my task on floppy-less make release (for AMD64, etc.), I had to
   just fix it.  Attached is the patch.  It also fixes another issue
   with this telnet commit: it ensures that crypto telnet[d] do not
   end up in the base distribution.
  
  Why not simply enable 'NO_FLOPPIES' on the arch's that don't want
  floppies?
  
  Because NO_FLOPPIES doesn't mean like it sounds; it means do not
  create floppy _images_, and we want to skip much more than that.
  I have a preliminary patch that is currently under the make
  release test.  Let me know (or anyone else) if you want to review
  it or the final version before I commit it.
 
 Are you eliminating the mfsroot?
 
 Yes.

Ugh.

 All the bootable CD's use
 that right now, so what more are you doing than eliminating
 the floppy images?
 
 Part of the patch for the iso.1 target has this (cut-n-pasted):
 
 @@ -885,10 +873,7 @@
  .if ${TARGET} != pc98
 @echo Setting up /boot
 @rm -f ${CD_DISC2}/boot/loader.conf
 -   @cp ${RD}/mfsroot/mfsroot.gz ${CD_DISC2}/boot/mfsroot.gz
 -   @echo 'mfsroot_load=YES'  ${CD_DISC2}/boot/loader.conf
 -   @echo 'mfsroot_type=mfs_root'  ${CD_DISC2}/boot/loader.conf
 -   @echo 'mfsroot_name=/boot/mfsroot'  ${CD_DISC2}/boot/loader.conf
 +   @echo 'init_path=/usr/sbin/sysinstall'  ${CD_DISC2}/boot/loader.conf
 @cp -Rp ${CD_DISC2}/boot ${CD_DISC1}
  .endif
  .if !defined(NOPORTS)

How does sysinstall work with this change?  You do realize that we
mount the MFS as /, then mount the disk under /mnt, chroot to /mnt,
then mount the CD in /dist in the chroot and install from there?
Are you going to mount the CD as root or something?  It is probably
a lot simpler to simply let sysinstall always execute in a MFS root.

If you really want to rewrite the installation environment, then you
might want to talk that over on a mailing list first to get some input.
It's not a trivial task.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: where is kern.ca.da.no_6_byte?

2003-07-22 Thread Kenneth D. Merry
On Sun, Jul 20, 2003 at 19:40:58 +0200, Harald Schmalzbauer wrote:
 Andre Guibert de Bruet wrote:
  On Sun, 20 Jul 2003, Harald Schmalzbauer wrote:
 
   Kenneth D. Merry wrote:
 seems that this sysctl doesn't exist any more!
 Is there anything similar?
   
It has been renamed:
kern.cam.da.%d.minimum_cmd_size
   
Where %d is the unit number for the da(4) device.
  
   Thaks a lot! Where can I find such info? I looked via cvsweb
  for scsi_da.c
   but couldn't find anything. Is it possible to list all kernel tunables?
 
  sysctl -a. You'll probably want to pipe it's output to your favorite
  pager. sysctl kern will list just the entries in the kern MIB.
 
 OIC. It's not available until the device is pluged in, which makes it
 absolutely useless.
 When I plug it in the machine behaves abnormal, so I need to set it BEFORE
 connecting USB devices.

Then you can set it in your loader.conf file instead.  It's a loader
tunable as well as a sysctl variable.  The da(4) driver will read that
tunable value and set the variable correctly before your drive is probed.

 Why has this tunable by default a value which makes the machine unstable by
 every umass I plug in which has no qirk entry? And if I look how many
 quirks there are I assume that almost every device needs no_6byte set.
 Why not make it default? Perhaps this would prevent criminal people from
 intentionally crashing servers when intruding my serverroom armed with
 dozends of USB devices;)

The problem is that some devices can't handle 6 byte commands, and some
devices can't handle 10 byte commands.  If we fix things for one set of
devices we'll break things for another.

You're correct that many USB devices need 10 byte CDBs from the outset,
because they're so broken that if they get a CDB they don't recognize, they
hang up.

We have code in the da(4) driver now that detects errors from a device
in response to a 6 byte command and tries a 10 byte command instead, but
that doesn't help if the device hangs the first time it gets a 6 byte
command.

We've got plans to basically quirk all USB devices (and perhaps ATAPI and
firewire if necessary, but USB is the one that causes the most trouble) so
that no 6 byte commands get sent.  So, hopefully this won't be an issue for
too much longer.

Ken
-- 
Kenneth Merry
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[-CURRENT tinderbox] failure on i386/i386

2003-07-22 Thread Tinderbox
TB --- 2003-07-22 18:38:56 - starting CURRENT tinderbox run for i386/i386
TB --- 2003-07-22 18:38:56 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/i386
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-22 18:40:44 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1: legacy release compatibility shims
 stage 1: bootstrap tools
 stage 2: cleaning up the object tree
 stage 2: rebuilding the object tree
 stage 2: build tools
 stage 3: cross tools
 stage 4: populating 
 /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include
 stage 4: building libraries
 stage 4: make dependencies
 stage 4: building everything..
[...]
gzip -cn 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/share/man/man9/device_ids.9  
device_ids.9.gz
gzip -cn 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/share/man/man9/device_printf.9  
device_printf.9.gz
gzip -cn 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/share/man/man9/device_probe_and_attach.9
  device_probe_and_attach.9.gz
gzip -cn 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/share/man/man9/device_quiet.9  
device_quiet.9.gz
gzip -cn 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/share/man/man9/device_set_desc.9  
device_set_desc.9.gz
gzip -cn 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/share/man/man9/device_set_driver.9 
 device_set_driver.9.gz
gzip -cn 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/share/man/man9/device_set_flags.9 
 device_set_flags.9.gz
Bus error (core dumped)
*** Error code 138

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/share/man.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/share.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
TB --- 2003-07-22 19:32:44 - /usr/bin/make returned exit code  1 
TB --- 2003-07-22 19:32:44 - ERROR: failed to build world
TB --- 2003-07-22 19:32:44 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: make release broken [FIX]

2003-07-22 Thread Ruslan Ermilov
On Tue, Jul 22, 2003 at 03:07:01PM -0400, John Baldwin wrote:
 
   Why not simply enable 'NO_FLOPPIES' on the arch's that don't want
   floppies?
   
  Are you eliminating the mfsroot?
  
  Yes.
 
 Ugh.
 
Yes, after looking into this a bit deeper, I must agree that
preserving the mfsroot is much simpler.  And I will probably
do just that.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: Fixing gcc 3.3 compile failures -- fix for net/netsaint-plugins

2003-07-22 Thread Jacques A. Vidrine
On Tue, Jul 22, 2003 at 02:26:08PM +0200, Simon Barner wrote:

 --- plugins/check_by_ssh.c.orig   Mon Apr 23 09:43:11 2001
 +++ plugins/check_by_ssh.cTue Jul 22 05:05:52 2003
 @@ -191,7 +191,7 @@
   if (commands1)
   remotecmd=strscat(remotecmd,;echo STATUS CODE: $?;);
  
 - if (strlen (remotecmd) = 1)
 + if (remotecmd==NULL)
   usage (No remotecmd\n);
  
   comm = ssprintf(comm,%s %s '%s',comm,hostname,remotecmd);

This looks like more than a fix for a `compile failure'.  The
replacement code has different semantics than the new code.
What is the `compile failure' that was being fixed here?

Cheers,
-- 
Jacques Vidrine   . NTT/Verio SME  . FreeBSD UNIX   . Heimdal
[EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Fixing gcc 3.3 compile failures -- fix for net/netsaint-plugins

2003-07-22 Thread Thomas Dickey
On Tue, Jul 22, 2003 at 02:56:37PM -0500, Jacques A. Vidrine wrote:
 On Tue, Jul 22, 2003 at 02:26:08PM +0200, Simon Barner wrote:
 
  --- plugins/check_by_ssh.c.orig Mon Apr 23 09:43:11 2001
  +++ plugins/check_by_ssh.c  Tue Jul 22 05:05:52 2003
  @@ -191,7 +191,7 @@
  if (commands1)
  remotecmd=strscat(remotecmd,;echo STATUS CODE: $?;);
   
  -   if (strlen (remotecmd) = 1)
  +   if (remotecmd==NULL)
  usage (No remotecmd\n);
   
  comm = ssprintf(comm,%s %s '%s',comm,hostname,remotecmd);
 
 This looks like more than a fix for a `compile failure'.  The
 replacement code has different semantics than the new code.
 What is the `compile failure' that was being fixed here?

perhaps the compiler was pointing out that remotecmd may not be initialized.

(I don't see enough context to be sure ;-)

-- 
Thomas E. Dickey [EMAIL PROTECTED] [EMAIL PROTECTED]
http://dickey.his.com
ftp://dickey.his.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: sockstat -6

2003-07-22 Thread Pawel Worach
David Hill wrote:
Hello -
I get a mismatch error when i run sockstat -6.  kernel and userland are in sync.
FreeBSD localhost 5.1-CURRENT FreeBSD 5.1-CURRENT #3: Tue Jul 22 07:49:10 EDT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/WIND  i386

(david wind:/home/david)% sockstat -6 
sockstat: struct xtcpcb size mismatch
USER COMMANDPID   FD PROTO  LOCAL ADDRESS FOREIGN ADDRESS 

No problems here.

darkstar$ uname -a
FreeBSD darkstar 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Jul 22 18:49:18 CEST 
2003 [EMAIL PROTECTED]:/export/data/obj/usr/src/sys/DARKSTAR  i386
darkstar$ sockstat -6
USER COMMANDPID   FD PROTO  LOCAL ADDRESS FOREIGN ADDRESS
root inetd  535   5  tcp6   *:21  *:*
root inetd  535   7  tcp6   *:113 *:*
darkstar$ ls -l `which sockstat`
-r-xr-xr-x  1 root  wheel  10060 Jul 22 20:00 /usr/bin/sockstat

  - Pawel

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Fixing gcc 3.3 compile failures -- fix for net/netsaint-plugins

2003-07-22 Thread Simon Barner
  --- plugins/check_by_ssh.c.orig Mon Apr 23 09:43:11 2001
  +++ plugins/check_by_ssh.c  Tue Jul 22 05:05:52 2003
  @@ -191,7 +191,7 @@
  if (commands1)
  remotecmd=strscat(remotecmd,;echo STATUS CODE: $?;);
   
  -   if (strlen (remotecmd) = 1)
  +   if (remotecmd==NULL)
  usage (No remotecmd\n);
   
  comm = ssprintf(comm,%s %s '%s',comm,hostname,remotecmd);
 
 This looks like more than a fix for a `compile failure'.  The
 replacement code has different semantics than the new code.
 What is the `compile failure' that was being fixed here?

I don't know, either. This patch was part of the port before I touched
it [1]. Perhaps one should write

if ((remotecmd==NULL) || (strlen (remotecmd) = 1))

to be on the safe side?

Cheers,
 Simon
 
[1]:
http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/net/netsaint-plugins/files/patch-check_by_ssh.c?rev=1.1content-type=text/plain


signature.asc
Description: Digital signature


should new-gcc kernels with -CURRENT still be panic()'ing right atboot?

2003-07-22 Thread John Reynolds
Hi all, when the new gcc was imported I spotted a thread saying that the new
kernels *immediately* panicked (trap 12) upon booting. I too saw the same
behavior after a successful buildworld/buildkernel (with a config file
previously working just fine with 5.1-R sources).

Has this been fixed? Can people build working kernels on i386? I just CVSup'ed
this morning after successful builds, test boots into the resulting kernel
panicks immediately still.

My /etc/make.conf is:

   NO_LPR=true
   NO_FORTRAN=  true# do not build g77 and related libraries
   NO_OBJC= true# do not build Objective C support
   NOPROFILE=   true# Avoid compiling profiled libraries
   USA_RESIDENT=YES
   #HAVE_MOTIF=yes
   CPUTYPE=i686
   CFLAGS= -O -pipe

The CPU is a 2.4Ghz Pentium 4 (800FSB) on an ABit IC7 motherboard. 5.1-RELEASE
had no problem installing nor running on this h/w. Any ideas? Pointers?

-Jr

-- 
John  Jennifer Reynolds  johnjen at reynoldsnet.orgwww.reynoldsnet.org
Sr. Physical Design Engineer - WCCG/CCE PDE jreynold at sedona.ch.intel.com
Running FreeBSD since 2.1.5-RELEASE.   FreeBSD: The Power to Serve!
Unix is user friendly, it's just particular about the friends it chooses.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


RE: where is kern.ca.da.no_6_byte?

2003-07-22 Thread Harald Schmalzbauer
Kenneth D. Merry wrote:
  OIC. It's not available until the device is pluged in, which makes it
  absolutely useless.
  When I plug it in the machine behaves abnormal, so I need to
  set it BEFORE
  connecting USB devices.

 Then you can set it in your loader.conf file instead.  It's a loader
 tunable as well as a sysctl variable.  The da(4) driver will read that
 tunable value and set the variable correctly before your drive is probed.

Ok, I didn't know that there is a difference between loader set tunables and
tunables set with sysctl -w!


  Why has this tunable by default a value which makes the machine
 unstable by
  every umass I plug in which has no qirk entry? And if I look how many
  quirks there are I assume that almost every device needs no_6byte set.
  Why not make it default? Perhaps this would prevent criminal people from
  intentionally crashing servers when intruding my serverroom armed with
  dozends of USB devices;)

 The problem is that some devices can't handle 6 byte commands, and some
 devices can't handle 10 byte commands.  If we fix things for one set of
 devices we'll break things for another.

 You're correct that many USB devices need 10 byte CDBs from the outset,
 because they're so broken that if they get a CDB they don't
 recognize, they
 hang up.

 We have code in the da(4) driver now that detects errors from a device
 in response to a 6 byte command and tries a 10 byte command instead, but
 that doesn't help if the device hangs the first time it gets a 6 byte
 command.

Thanky you very much for that explanation. It's always good to know why
things are not working as expected. This expanded my limited knowledge.

Thank you,

-Harry


 We've got plans to basically quirk all USB devices (and perhaps ATAPI and
 firewire if necessary, but USB is the one that causes the most trouble) so
 that no 6 byte commands get sent.  So, hopefully this won't be an
 issue for
 too much longer.

 Ken
 --
 Kenneth Merry
 [EMAIL PROTECTED]


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Fixing gcc 3.3 compile failures -- fix for net/netsaint-plugins

2003-07-22 Thread Jacques A. Vidrine
On Wed, Jul 23, 2003 at 01:57:56AM +0200, Simon Barner wrote:
   --- plugins/check_by_ssh.c.orig   Mon Apr 23 09:43:11 2001
   +++ plugins/check_by_ssh.cTue Jul 22 05:05:52 2003
   @@ -191,7 +191,7 @@
 if (commands1)
 remotecmd=strscat(remotecmd,;echo STATUS CODE: $?;);

   - if (strlen (remotecmd) = 1)
   + if (remotecmd==NULL)
 usage (No remotecmd\n);

 comm = ssprintf(comm,%s %s '%s',comm,hostname,remotecmd);
  
  This looks like more than a fix for a `compile failure'.  The
  replacement code has different semantics than the new code.
  What is the `compile failure' that was being fixed here?
 
 I don't know, either. This patch was part of the port before I touched
 it [1]. 

Oh, well nevermind!  I thought this was a new patch to deal with
`compile failures'.  Cheers!

 Perhaps one should write
 
 if ((remotecmd==NULL) || (strlen (remotecmd) = 1))
 
 to be on the safe side?

Maybe.  The original submittor might recall.

Cheers,
-- 
Jacques Vidrine   . NTT/Verio SME  . FreeBSD UNIX   . Heimdal
[EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Panic in 5.1-R

2003-07-22 Thread Matthew D. Fuller
System runs ppp(8) for a PPPoE DSL connection.  I fired up another copy
of ppp for unrelated purposes (no args, just `ppp`), and got this panic:

panic: Resource  flags out-of-sync
cpuid = 1; lapic.id = 0c00
boot() called on cpu#1

#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:238
#1  0xc0242863 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:370
#2  0xc0242c1f in panic () at /usr/src/sys/kern/kern_shutdown.c:543
#3  0xc02ae257 in tunopen (dev=0xc2818200, flag=3, mode=8192, td=0x0)
at /usr/src/sys/net/if_tun.c:275
#4  0xc02089b9 in spec_open (ap=0xce7d2a64)
at /usr/src/sys/fs/specfs/spec_vnops.c:203
#5  0xc0208778 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:123
#6  0xc02a13b9 in vn_open_cred (ndp=0xce7d2bd8, flagp=0xce7d2cd8, cmode=3456, 
cred=0xc2edd000) at vnode_if.h:213
#7  0xc02a0f79 in vn_open (ndp=0x0, flagp=0x0, cmode=0)
at /usr/src/sys/kern/vfs_vnops.c:85
#8  0xc029a96d in kern_open (td=0xc2a18980, path=0x0, pathseg=UIO_USERSPACE, 
flags=3, mode=134794642) at /usr/src/sys/kern/vfs_syscalls.c:684
#9  0xc029a820 in open (td=0x0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:649
#10 0xc03bb1ce in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 
134883928, tf_esi = 2, tf_ebp = -1077938856, tf_isp = -830657164, tf_ebx = 
-1077938840, tf_edx = 9, tf_ecx = 134794646, tf_eax = 5, tf_trapno = 12, tf_err = 2, 
tf_eip = 405215043, tf_cs = 31, tf_eflags = 531, tf_esp = -1077938900, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1021
#11 0xc03a2c5d in Xint0x80_syscall () at {standard input}:139
---Can't read userspace from dump, or kernel process---



Actual source is at:
#3  0xc02ae257 in tunopen (dev=0xc2818200, flag=3, mode=8192, td=0x0)
at /usr/src/sys/net/if_tun.c:275
275 KASSERT(!(tp-tun_flags  TUN_OPEN), (Resource  flags out-of-sync));
(kgdb) print dev-si_name
$6 = 0xc2818290 tun0


Keeping the dump around, if there's anything else useful I can pull out.



-- 
Matthew Fuller (MF4839)   |  [EMAIL PROTECTED]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/

The only reason I'm burning my candle at both ends, is because I
  haven't figured out how to light the middle yet
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: should new-gcc kernels with -CURRENT still be panic()'ing rightat boot?

2003-07-22 Thread Steve Kargl
On Tue, Jul 22, 2003 at 06:45:01PM +, John Reynolds wrote:
 Hi all, when the new gcc was imported I spotted a thread saying that the new
 kernels *immediately* panicked (trap 12) upon booting. I too saw the same
 behavior after a successful buildworld/buildkernel (with a config file
 previously working just fine with 5.1-R sources).
 
 Has this been fixed? Can people build working kernels on i386?

I've built several kernels without a problem.  You need
to (1) post the exact panic message, (2) read the section of
the Handbook on debugging kernel panics, and (3) provide a
backtrace.

-- 
Steve
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


su and suspend problems with -CURRENT

2003-07-22 Thread Anish Mistry
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've been using -CURRENT for while now and have finally gotten some time to 
come up with a list of problems I'm getting:
When I su to change to the root user I get a Bus Error from su.  This have 
been around for about a month, still happens after multiple build and install 
worlds, I just haven't gotten around to reporting it.
About a week ago I started to have the laptop reboot when is comes out of 
suspend, which it never used to do.
Let me know what further info i need to provide.

- -- 
Anish Mistry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQE/HgT7xqA5ziudZT0RAhD9AJ40fem0ziTcBRxwGLRJffYJcZjkewCgyvim
EpRbn2LK9ZetevQGgSNKyoM=
=7yA0
-END PGP SIGNATURE-
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: should new-gcc kernels with -CURRENT still be panic()'ing rightat boot?

2003-07-22 Thread John Reynolds

[ On Tuesday, July 22, Steve Kargl wrote: ]
 
 I've built several kernels without a problem.  You need
 to (1) post the exact panic message, (2) read the section of
 the Handbook on debugging kernel panics, and (3) provide a
 backtrace.
 

will do.

-Jr

-- 
John  Jennifer Reynolds  johnjen at reynoldsnet.orgwww.reynoldsnet.org
Sr. Physical Design Engineer - WCCG/CCE PDE jreynold at sedona.ch.intel.com
Running FreeBSD since 2.1.5-RELEASE.   FreeBSD: The Power to Serve!
Unix is user friendly, it's just particular about the friends it chooses.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]