FreeBSD5.0 has the G-NIC(VI/IP) drivers?

2003-01-03 Thread ouyang kai
Hi, everybody,
 My lab wants to buy some G-NICs. I suggest to buy those NIC supported 
VI/IP. But I do not know which G-NIC(VI/IP) drivers supported in FreeBSD5.0 
?

 http://www.emulex.com/products/viip/index.html
 But this NIC is only support Solaris.

 Does FreeBSD have some projects about that?

Best Regards
 Ouyang Kai




_
The new MSN 8 is here: Try it free* for 2 months 
http://join.msn.com/?page=dept/dialup


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


Re: USB and Kodak DC4800 Camera

2003-01-03 Thread Michael Class
Marc Butler wrote:


On Thu, Jan 02, 2003 at 02:11:16PM +0100, Michael Class wrote:

Hello,

I am facing a problem that my Kodak DC4800 Camera is not recognized by a
current FreeBSD-current system (I do not have release systems around, so
I can not test aginst them, but I suspect that it would not work their
either) (and yes, it works on the same system with L***x and W*e :-(

I have compiled a kernel with USB_DEBUG and switched on debugging. The
result from a connection of the camera to the system and a deconnect is
in the enclosed errorlog. Anyone here able to interpret this?



Michael,

I'm not absolutely certain, but I believe the Kodak DC4800 Camera uses
the Picture Transfer Protocol.  I'm not sure it will be recognized as
a storage device, however I have no experience with current and this
particular issue.

You may also want to make sure that the camera is plugged in or in
it's cradle.  The attempts to reset port 2 in your error output may
indicate the device is not responding; it seems to be with a lot of
these devices that they need external power when connected to the
computer.  (I'm not very confident in this as you state it works 
withWindows and Linux, and I assume it is the same setup.)


Thank you for the answer!

Yes, I can download pictures without additional power on Windows and 
Linux, so this does not seem to be the problem.

Yes the device uses the PTP protocol. I do not expect it to appear as 
umass. But: I want to see it as ugen, so that higher level programs can 
access it. On Lx I am using jPhoto (a java program using libusb) to 
access the camera via PTP. And now I have read that recent versions of 
gphoto2 have PTP support too. But unfortunately our USB support drops 
the device totally, so I am stuck here. (Any yes I have, for obvious 
reasons, not yet tested if these programs work on FreeBSD)


Michael

--
-
michael class, viktor-renner str. 39, 72074 tuebingen, frg
E-Mail: [EMAIL PROTECTED]
 Phone: +49 7031 14-3707 (work) +49 7071 81950 (private)
-


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


Re: Two LORs.

2003-01-03 Thread Alfred Perlstein
There's a post to -smp I made about this today:

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=4779+0+current/freebsd-smp

It details the problem and some possible solutions.

* Lars Eggert [EMAIL PROTECTED] [030102 16:10] wrote:
 Juli Mallett wrote:
 
 The first is new to me (I've lagged behind for a while) and the second is
 something I've reported to Cameron, but continually get, so I thought I'd
 post again.
 
 lock order reversal
  1st 0xc12c9b18 process lock (process lock) @ 
 ../../../kern/kern_descrip.c:2099
  2nd 0xc12d3d34 filedesc structure (filedesc structure) @ 
 ../../../kern/kern_descrip.c:2106
 
 Same here, with today's -current. Hadn't updated since mid-December, 
 just noticed it. LOR is reproducible, always happens early during boot:
 
 SMP: AP CPU #1 Launched!
 Mounting root from ufs:/dev/da0s1a
 lock order reversal
 1st 0xc65d53f8 process lock (process lock) @ 
 /usr/src/sys/kern/kern_descrip.c:2099
 2nd 0xc655fa34 filedesc structure (filedesc structure) @ 
 /usr/src/sys/kern/kern_descrip.c:2106
 savecore: no dumps found
 
 
 Lars
 
 -- 
 Lars Eggert [EMAIL PROTECTED]   USC Information Sciences Institute



-- 
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using 1970s technology,
 start asking why software is ignoring 30 years of accumulated wisdom.'

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



buildworld trouble: multiple struct dos_partition.

2003-01-03 Thread Poul-Henning Kamp

I think you need to either #ifdef something here (and there may be
more some similar code in places like truss or the debugger) or
alternatively rename the structure to pc98_partition or similar.

I would advocate the latter.

Poul-Henning

=== usr.bin/kdump
cc -O -pipe -mcpu=pentiumpro -I/bang/src/usr.bin/kdump/../ktrace -I/bang/src/usr
.bin/kdump/../..-c /bang/src/usr.bin/kdump/kdump.c
cc -O -pipe -mcpu=pentiumpro -I/bang/src/usr.bin/kdump/../ktrace -I/bang/src/usr
.bin/kdump/../..-c /bang/src/usr.bin/ktrace/subr.c
gzip -cn /bang/src/usr.bin/kdump/kdump.1  kdump.1.gz
cc -O -pipe -mcpu=pentiumpro -I/bang/src/usr.bin/kdump/../ktrace -I/bang/src/usr
.bin/kdump/../..-c ioctl.c
In file included from ioctl.c:93:
/usr/obj/bang/src/i386/usr/include/sys/diskpc98.h:47: redefinition of `struct do
s_partition'

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

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



alpha tinderbox failure

2003-01-03 Thread Dag-Erling Smorgrav
--
 Rebuilding the temporary build tree
--
 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/alpha/obj/h/des/src/alpha/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
=== usr.bin/vi
*** Error code 1 (ignored)
*** Error code 1 (ignored)
=== usr.bin/vis
=== usr.bin/vmstat
=== usr.bin/w
=== usr.bin/wall
=== usr.bin/wc
=== usr.bin/what
=== usr.bin/whereis
=== usr.bin/which
=== usr.bin/who
=== usr.bin/whois
=== usr.bin/window
=== usr.bin/write
=== usr.bin/xargs
=== usr.bin/xinstall
=== usr.bin/xlint
=== usr.bin/xlint/lint1
yacc: 1 shift/reduce conflict
=== usr.bin/xlint/lint2
=== usr.bin/xlint/xlint
=== usr.bin/xlint/llib
=== usr.bin/xstr
=== usr.bin/yacc
=== usr.bin/yes
=== usr.bin/ypcat
=== usr.bin/ypmatch
=== usr.bin/ypwhich
=== usr.bin/dig
=== usr.bin/dnskeygen
=== usr.bin/dnsquery
=== usr.bin/host
=== usr.bin/vacation
=== usr.bin/uac
=== usr.bin/chkey
=== usr.bin/newkey
=== usr.sbin
=== usr.sbin/IPXrouted
=== usr.sbin/ac
=== usr.sbin/accton
=== usr.sbin/adduser
=== usr.sbin/amd
=== usr.sbin/amd/include
=== usr.sbin/amd/libamu
=== usr.sbin/amd/amd
=== usr.sbin/amd/amq
=== usr.sbin/amd/doc
=== usr.sbin/amd/fixmount
=== usr.sbin/amd/fsinfo
yacc: 2 shift/reduce conflicts
=== usr.sbin/amd/hlfsd
=== usr.sbin/amd/mk-amd-map
=== usr.sbin/amd/pawd
=== usr.sbin/amd/scripts
=== usr.sbin/amd/wire-test
=== usr.sbin/ancontrol
=== usr.sbin/arp
=== usr.sbin/atm
=== usr.sbin/atm/atmarpd
=== usr.sbin/atm/scspd
=== usr.sbin/bootparamd
=== usr.sbin/bootparamd/bootparamd
=== usr.sbin/bootparamd/callbootd
=== usr.sbin/burncd
=== usr.sbin/cdcontrol
=== usr.sbin/chkgrp
=== usr.sbin/chown
=== usr.sbin/chroot
=== usr.sbin/ckdist
=== usr.sbin/config
=== usr.sbin/cron
=== usr.sbin/cron/lib
=== usr.sbin/cron/cron
=== usr.sbin/cron/crontab
=== usr.sbin/crunch
=== usr.sbin/crunch/crunchgen
=== usr.sbin/crunch/crunchide
=== usr.sbin/ctm
=== usr.sbin/ctm/ctm
=== usr.sbin/ctm/ctm_rmail
=== usr.sbin/ctm/ctm_smail
=== usr.sbin/ctm/ctm_dequeue
=== usr.sbin/daemon
=== usr.sbin/dev_mkdb
=== usr.sbin/devinfo
=== usr.sbin/digictl
=== usr.sbin/edquota
=== usr.sbin/extattr
=== usr.sbin/extattrctl
=== usr.sbin/faithd
=== usr.sbin/fdcontrol
=== usr.sbin/fdformat
=== usr.sbin/fdread
=== usr.sbin/fdwrite
=== usr.sbin/fwcontrol
=== usr.sbin/getfmac
=== usr.sbin/getpmac
=== usr.sbin/ifmcstat
=== usr.sbin/inetd
=== usr.sbin/iostat
=== usr.sbin/jail
=== usr.sbin/kbdcontrol
=== usr.sbin/kbdmap
=== usr.sbin/kernbb
=== usr.sbin/kldxref
=== usr.sbin/lastlogin
=== usr.sbin/mailwrapper
=== usr.sbin/manctl
=== usr.sbin/memcontrol
=== usr.sbin/mergemaster
=== usr.sbin/mixer
=== usr.sbin/mld6query
=== usr.sbin/mlxcontrol
=== usr.sbin/mountd
=== usr.sbin/moused
=== usr.sbin/mrouted
=== usr.sbin/mrouted/common
=== usr.sbin/mrouted/mrouted
=== usr.sbin/mrouted/mrinfo
=== usr.sbin/mrouted/map-mbone
=== usr.sbin/mrouted/mtrace
=== usr.sbin/mrouted/testrsrr
=== usr.sbin/mtest
=== usr.sbin/mtree
=== usr.sbin/ndp
=== usr.sbin/newsyslog
=== usr.sbin/nfsd
=== usr.sbin/ngctl
=== usr.sbin/ntp
=== usr.sbin/ntp/libntp
=== usr.sbin/ntp/libparse
=== usr.sbin/ntp/ntpd
Version ntpd 4.1.1b-a Fri Jan  3 02:12:09 PST 2003 (1)
=== usr.sbin/ntp/ntpdc
Version ntpdc 4.1.1b-a Fri Jan  3 02:12:12 PST 2003 (1)
=== usr.sbin/ntp/ntpq
Version ntpq 4.1.1b-a Fri Jan  3 02:12:12 PST 2003 (1)
=== usr.sbin/ntp/ntpdate
Version ntpdate 4.1.1b-a Fri Jan  3 02:12:12 PST 2003 (1)
=== usr.sbin/ntp/ntptrace
Version ntptrace 4.1.1b-a Fri Jan  3 02:12:12 PST 2003 (1)
=== usr.sbin/ntp/ntptimeset
Version ntptimeset 4.1.1b-a Fri Jan  3 02:12:12 PST 2003 (1)
=== usr.sbin/ntp/ntptime
=== usr.sbin/ntp/ntp-genkeys
=== usr.sbin/ntp/doc
=== usr.sbin/nghook
=== usr.sbin/pccard
=== usr.sbin/pccard/pccardc
=== usr.sbin/pccard/pccardd
=== usr.sbin/pciconf
=== usr.sbin/periodic
=== usr.sbin/pkg_install
=== usr.sbin/pkg_install/lib
=== usr.sbin/pkg_install/add
=== usr.sbin/pkg_install/create
=== usr.sbin/pkg_install/delete
=== usr.sbin/pkg_install/info
=== usr.sbin/pkg_install/version
=== usr.sbin/pkg_install/sign
=== usr.sbin/ppp
=== usr.sbin/pppd
=== usr.sbin/pppstats
=== usr.sbin/procctl
=== usr.sbin/pstat
=== usr.sbin/pw
=== usr.sbin/pwd_mkdb
=== usr.sbin/quot
=== usr.sbin/quotaon
=== usr.sbin/rarpd
=== usr.sbin/raycontrol
=== usr.sbin/repquota
=== 

Re: pcm0:play:0: play interrupt timeout, channel dead

2003-01-03 Thread Christian Brueffer
On Thu, Jan 02, 2003 at 08:43:34PM -0700, Scott Long wrote:
 [EMAIL PROTECTED] wrote:
 
 Quoting Christian Brueffer :
 
 
  |
  | Hi,
  |
  | I'm seeing the same on two boxen here.  The errors seem to have been
  | introduced during the latest pcm locking changes in mid-december.
  |
  | A src/dev/sound from the beginning of december works fine.
 
 Christian,
 
 Thanks.  At least I'm not alone,  Misery loves company, they say.  I only
 have one older kernel and it works fine. [cvsup/world/kernel Dec. 20,2002
 +- 4am pst]  Now all we need is a fix :-)
 
 Thanks again,
 
 ed
 
 
 
 -
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
 
 As the co-author of that driver, it pains me that it's broken. 
 Unfortunately,
 my only maestro3 hardware was in a laptop that no longer works.  If anyone
 has the hardware as a PCI add-in board and is willing to loan it to me, I'd
 be very grateful.
 
 Another thing to try would be to edit the driver source and reduce it's play
 channels to 1 by changing M3_PCHANS.  This wouldn't fix the problem, but
 in the past the driver has been very fragile with multiple channels enabled.
 
 Scott
 
 
 

Well, it's not only maestro hardware:

pcm0: Intel 82801CA (ICH3) port 0x18c0-0x18ff,0x1c00-0x1cff irq 11 at device 3
1.5 on pci0

The same with a CMI8738.

I don't have any boards with these chips, but if it helps, I can give
you full root access on one of the machines.

- Christian

-- 
http://www.unixpages.org[EMAIL PROTECTED]
GPG Pub-Key: www.unixpages.org/cbrueffer.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B  B29B 6C76 178C A0ED 982D
GPG Key ID : 0xA0ED982D



msg49577/pgp0.pgp
Description: PGP signature


Re: pcm0:play:0: play interrupt timeout, channel dead

2003-01-03 Thread Scott Long
Christian Brueffer wrote:




Well, it's not only maestro hardware:

pcm0:  port 0x18c0-0x18ff,0x1c00-0x1cff irq 11 at
device 3
1.5 on pci0

The same with a CMI8738.

I don't have any boards with these chips, but if it helps, I can give
you full root access on one of the machines.

- Christian



My new laptop uses the ICH3 sound controller, and it works
fine with 5-current as of this morning.  I can't comment on
the CMI8738

Scott


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



ia64 tinderbox failure

2003-01-03 Thread Peter Wemm
--
 Rebuilding the temporary build tree
--
 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/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== usr.bin/kdump
In file included from ioctl.c:74:
/home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include/sys/diskpc98.h:47: 
redefinition of `struct dos_partition'
*** Error code 1

Stop in /home/tinderbox/ia64/src/usr.bin/kdump.
*** Error code 1

Stop in /home/tinderbox/ia64/src/usr.bin.
*** Error code 1

Stop in /home/tinderbox/ia64/src.
*** Error code 1

Stop in /home/tinderbox/ia64/src.
*** Error code 1

Stop in /home/tinderbox/ia64/src.

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



gdb of C++ program broken due to missing objects from Makefile.

2003-01-03 Thread Peter Edwards
Hi,
Debugging trivial C++ programs in GDB is knackered, complaining about ABI
doesn't define required function XXX when doing operations such as printing
classes and structures which inherit from others, and setting breakpoints in
virtual functions, etc.

Adding gnu-v2-abi.c and gnu-v3-abi.c to XSRCS in
src/gnu/usr.bin/binutils/gdb/Makefile
fixes the problem. 

This seems like a reasonably large problem with GDB as it stands currently.
Does someone fancy committing this? patch and before/after example follow.

Index: Makefile
===
RCS file: /pub/FreeBSD/development/FreeBSD-CVS/src/gnu/usr.bin/binutils/gdb/Makefile,v
retrieving revision 1.62
diff -u -r1.62 Makefile
--- Makefile12 Oct 2002 21:23:53 -  1.62
+++ Makefile3 Jan 2003 11:40:52 -
@@ -37,6 +37,7 @@
ui-file.c ui-out.c wrapper.c cli-out.c \
cli-cmds.c cli-cmds.h cli-decode.c cli-decode.h cli-script.c\
cli-script.h cli-setshow.c cli-setshow.h cli-utils.c cli-utils.h
+XSRCS+= gnu-v2-abi.c gnu-v3-abi.c
 XSRCS+=freebsd-uthread.c kvm-fbsd.c
 SRCS=  init.c ${XSRCS} nm.h tm.h xm.h gdbversion.c xregex.h


petere@rocklobster$  cat  test.cc  .
heredoc 
petere@rocklobster$ cat  test.cc  . 
heredoc #include unistd.h
heredoc 
heredoc struct A {
heredoc const char *fieldOfA;
heredoc A() : fieldOfA(A's field) {}
heredoc };
heredoc 
heredoc struct B : public A {
heredoc const char * fieldOfB;
heredoc B() : fieldOfB(B's field) {}
heredoc };
heredoc 
heredoc main()
heredoc {
heredoc B myB;
heredoc pause();
heredoc }
heredoc .
petere@rocklobster$ g++ -g test.cc
petere@rocklobster$ /usr/bin/gdb ./a.out
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
(gdb) b 16
Breakpoint 1 at 0x80485b7: file test.cc, line 16.
(gdb) run
Starting program: /local/petere/a.out 

Breakpoint 1, main () at test.cc:16
16  pause();
(gdb) p myB
$1 = {ABI doesn't define required function baseclass_offset
(gdb) quit
The program is running.  Exit anyway? (y or n) y
petere@rocklobster$ /tmp/peters_fixed_gdb ./a.out
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
(gdb) b 16
Breakpoint 1 at 0x80485b7: file test.cc, line 16.
(gdb) run
Starting program: /local/petere/a.out 

Breakpoint 1, main () at test.cc:16
16  pause();
(gdb) p myB
$1 = {
  A = {
fieldOfA = 0x8048692 A's field
  }, 
  members of B: 
  fieldOfB = 0x8048688 B's field
}
(gdb) 


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



Re: pcm0:play:0: play interrupt timeout, channel dead

2003-01-03 Thread Christian Brueffer
On Fri, Jan 03, 2003 at 04:22:28AM -0700, Scott Long wrote:
 Christian Brueffer wrote:
 
 
 
 Well, it's not only maestro hardware:
 
 pcm0:  port 0x18c0-0x18ff,0x1c00-0x1cff irq 11 at
 device 3
 1.5 on pci0
 
 The same with a CMI8738.
 
 I don't have any boards with these chips, but if it helps, I can give
 you full root access on one of the machines.
 
 - Christian
 
 
 My new laptop uses the ICH3 sound controller, and it works
 fine with 5-current as of this morning.  I can't comment on
 the CMI8738
 
 Scott
 
 
 

I admit, with the ICH3 it doesn't happen as much as with the CMI8738,
but it still does.

- Christian

-- 
http://www.unixpages.org[EMAIL PROTECTED]
GPG Pub-Key: www.unixpages.org/cbrueffer.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B  B29B 6C76 178C A0ED 982D
GPG Key ID : 0xA0ED982D



msg49581/pgp0.pgp
Description: PGP signature


sshd login

2003-01-03 Thread Daniel C. Sobral
Starting around the end of the year, sshd is taking a LONG time to 
proceed, just a bit after the few first packets.

Here:

11:25:03.624519 172.31.199.17.2058  172.31.199.20.22: S [tcp sum ok] 
2790790408:2790790408(0) win 57344 mss 1460,nop,wscale 
0,nop,nop,timestamp 187450151 0 (DF) (ttl 64, id 17561, len 60)
11:25:03.624771 172.31.199.20.22  172.31.199.17.2058: S [tcp sum ok] 
714515882:714515882(0) ack 2790790409 win 65535 mss 1460,nop,wscale 
1,nop,nop,timestamp 794169 187450151 (DF) (ttl 64, id 6630, len 60)
11:25:03.624825 172.31.199.17.2058  172.31.199.20.22: . [tcp sum ok] 
1:1(0) ack 1 win 57920 nop,nop,timestamp 187450151 794169 (DF) (ttl 
64, id 17562, len 52)
11:25:03.627353 172.31.199.20.22  172.31.199.17.2058: P [tcp sum ok] 
1:40(39) ack 1 win 33304 nop,nop,timestamp 794174 187450151 (DF) (ttl 
64, id 6631, len 91)
11:25:03.627677 172.31.199.17.2058  172.31.199.20.22: P [tcp sum ok] 
1:40(39) ack 40 win 57920 nop,nop,timestamp 187450151 794174 (DF) (ttl 
64, id 17563, len 91)
11:25:03.631703 172.31.199.20.22  172.31.199.17.2058: P [tcp sum ok] 
40:576(536) ack 40 win 33304 nop,nop,timestamp 794183 187450151 (DF) 
(ttl 64, id 6632, len 588)
11:25:03.631786 172.31.199.17.2058  172.31.199.20.22: P [tcp sum ok] 
40:576(536) ack 576 win 57384 nop,nop,timestamp 187450151 794183 (DF) 
(ttl 64, id 17564, len 588)
11:25:03.731944 172.31.199.20.22  172.31.199.17.2058: . [tcp sum ok] 
576:576(0) ack 576 win 33304 nop,nop,timestamp 794384 187450151 (DF) 
(ttl 64, id 6633, len 52)
11:25:03.731990 172.31.199.17.2058  172.31.199.20.22: P [tcp sum ok] 
576:600(24) ack 576 win 57920 nop,nop,timestamp 187450161 794384 (DF) 
(ttl 64, id 17566, len 76)
11:25:03.740924 172.31.199.20.22  172.31.199.17.2058: P [tcp sum ok] 
576:1000(424) ack 600 win 33304 nop,nop,timestamp 794401 187450161 
(DF) (ttl 64, id 6634, len 476)
11:25:03.775190 172.31.199.17.2058  172.31.199.20.22: P [tcp sum ok] 
600:1016(416) ack 1000 win 57920 nop,nop,timestamp 187450166 794401 
(DF) (ttl 64, id 17567, len 468)
11:25:03.826489 172.31.199.20.22  172.31.199.17.2058: P [tcp sum ok] 
1000:1928(928) ack 1016 win 33304 nop,nop,timestamp 794572 187450166 
(DF) (ttl 64, id 6635, len 980)
11:25:03.878175 172.31.199.17.2058  172.31.199.20.22: P [tcp sum ok] 
1016:1032(16) ack 1928 win 57920 nop,nop,timestamp 187450176 794572 
(DF) (ttl 64, id 17570, len 68)
11:25:03.978067 172.31.199.20.22  172.31.199.17.2058: . [tcp sum ok] 
1928:1928(0) ack 1032 win 33304 nop,nop,timestamp 794876 187450176 
(DF) (ttl 64, id 6637, len 52)
11:25:03.978113 172.31.199.17.2058  172.31.199.20.22: P [tcp sum ok] 
1032:1080(48) ack 1928 win 57920 nop,nop,timestamp 187450186 794876 
(DF) (ttl 64, id 17587, len 100)
11:25:03.978519 172.31.199.20.22  172.31.199.17.2058: P [tcp sum ok] 
1928:1976(48) ack 1080 win 33304 nop,nop,timestamp 794876 187450186 
(DF) (ttl 64, id 6638, len 100)
11:25:03.978750 172.31.199.17.2058  172.31.199.20.22: P [tcp sum ok] 
1080:1144(64) ack 1976 win 57920 nop,nop,timestamp 187450186 794876 
(DF) (ttl 64, id 17588, len 116)
11:25:04.078627 172.31.199.20.22  172.31.199.17.2058: . [tcp sum ok] 
1976:1976(0) ack 1144 win 33304 nop,nop,timestamp 795077 187450186 
(DF) (ttl 64, id 6640, len 52)

At this point, ps alx shows:

0  6609  6387   0   4  0  4004 2072 sbwait S ??0:00.02 
/usr/sbin/sshd
   22  6610  6609   0   4  0  4076 2200 kqread S ??0:00.08 
sshd: [net] (sshd)

and then:

0  6609  6387   0   4  0  4004 2072 sbwait I ??0:00.02 
/usr/sbin/sshd
   22  6610  6609   0   4  0  4076 2200 kqread S ??0:00.08 
sshd: [net] (sshd)

It proceeds from there after a while.

11:26:19.030401 172.31.199.20.22  172.31.199.17.2058: P [tcp sum ok] 
1976:2056(80) ack 1144 win 33304 nop,nop,timestamp 944898 187450186 
(DF) (ttl 64, id 11691, len 132)

[etc]

Ok, this is 75 seconds, which is the common timeout for NS. Thing is...

1) No NS queries are made during this process.
2) Nothing changed in the environment, except updating FreeBSD.
3) My sshd is not configured to check for reverse.

Anyone has any clues?

--
Daniel C. Sobral
Gerência de Operações
Divisão de Comunicação de Dados
Coordenação de Segurança
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail:	[EMAIL PROTECTED]
	[EMAIL PROTECTED]
	[EMAIL PROTECTED]



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


Re: sshd login

2003-01-03 Thread Daniel C. Sobral
Daniel C. Sobral wrote:


Starting around the end of the year, sshd is taking a LONG time to
proceed, just a bit after the few first packets.


Ok, I found the query packets, on the loopback:

[root@piratinga root]# tcpdump -ni lo0 -s1500
tcpdump: listening on lo0
11:54:05.602126 127.0.0.1.49202  127.0.0.1.53:  41012+ PTR? 
17.199.31.172.in-addr.arpa. (44)
11:54:10.605353 127.0.0.1.49203  127.0.0.1.53:  41012+ PTR? 
17.199.31.172.in-addr.arpa. (44)
11:54:20.611284 127.0.0.1.49204  127.0.0.1.53:  41012+ PTR? 
17.199.31.172.in-addr.arpa. (44)

Only there is no reason in hell for it to query 127.0.0.1. My 
configuration files:

[root@piratinga root]# cat /etc/resolv.conf
domain intra.tcoip.com.br
nameserver 10.9.35.5
nameserver 10.0.14.20
[root@piratinga root]# cat /etc/nsswitch.conf
hosts: files dns
[root@piratinga root]# cat /etc/host.conf
# Auto-generated from nsswitch.conf, do not edit
hosts
bind

Anyone has suggestions?

--
Daniel C. Sobral
Gerência de Operações
Divisão de Comunicação de Dados
Coordenação de Segurança
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail:	[EMAIL PROTECTED]
	[EMAIL PROTECTED]
	[EMAIL PROTECTED]



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


System freeze running -current

2003-01-03 Thread Trent Nelson

I've experienced -current lock up in exactly the same way twice now;
once with 5.0-RC2, and just now, with sources from 30th December.

The system in question is a Sharp PC-AR50 laptop.  In both instances 
the system was idle and I was editing a file in vim on ttyv0.  Both
systems exhibited the following symptoms:

  1.  Able to switch terminals using alt-F1..F8, but that's it, I'm un-
  able to type anything else (keyboard doesn't respond to letters,
  numbers, but capslock and numlock still turn on lights).
  2.  Responds to pings from other systems on the network.
  3.  Cannot connect to the machine via ssh from other systems.  The
  connection is opened, according to ssh -vvv, but just hangs.
  4.  Mouse cursor not responding to either USB mouse or touchpad.
  5.  The screensaver (blank) still came on after ten minutes, and I
  believe that pressing a key that wasn't previously working turned
  it off.  (I can't be 100% on that one, it was a pretty random bash
  at the keyboard, as you do when you turn off the screen saver.)
  6.  Trying out keys, pressing ctl-alt-break caused the following to be
  printed on ttyv0:
sio4: detached
ad4: removed from config
ata2: detached
  7.  Trying out more keys, I could page up and down ttyv0 with scroll
  lock on.
  8.  When switching terminals or paging up/down, there was a very, very
  small latency between the keypress and the terminal switching or
  the page going up or down.
  9.  ctrl-alt-del did not work, had to hold down the power button for
  five seconds (hard shutdown) to turn the laptop off.

I have not noticed any other problems with my laptop, and successfu-
lly builtworld on it a number of times.

Laptop has the following specs: PIII-850MHz, 20GB, DVD, 256MB RAM,
at the time of the last freeze, had a 3Com 56K PCMCIA (3CCM156)
modem in slot 0, and a CompactFlash PC Card adapter with a 256MB
flash card in it in slot 1 -- which wasn't mounted.  (Actually, 
the modem would have been present in the first freeze as well, but
I doubt the flash card was.)

% uname -a
FreeBSD cherry.limekiln.vcisp.net 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Mon Dec 30 
04:33:27 GMT 2002 
[EMAIL PROTECTED]:/usr/obj/shared/work/BSD/FreeBSD/FreeBSD-CURRENT/src/sys/CHERRY
 i386
  
I've attached a copy of my kernel config. as well as the output from
boot -v (taken from the next boot after the crash).

Regards,

Trent.

Copyright (c) 1992-2002 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.0-CURRENT #1: Mon Dec 30 04:33:27 GMT 2002

[EMAIL PROTECTED]:/usr/obj/shared/work/BSD/FreeBSD/FreeBSD-CURRENT/src/sys/CHERRY
Preloaded elf kernel /boot/kernel/kernel at 0xc0485000.
Preloaded elf module /boot/kernel/acpi.ko at 0xc04850b4.
Calibrating clock(s) ... TSC clock: 846271143 Hz, i8254 clock: 1193112 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter i8254  frequency 1193182 Hz
CLK_USE_TSC_CALIBRATION not specified - using old calibration method
Timecounter TSC  frequency 846324031 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (846.32-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x686  Stepping = 6
  
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real memory  = 268369920 (255 MB)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x004ac000 - 0x0ffe7fff, 263438336 bytes (64316 pages)
avail memory = 255811584 (243 MB)
bios32: Found BIOS32 Service Directory header at 0xc00f71d0
bios32: Entry = 0xfd8a0 (c00fd8a0)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xfd8a0+0x12f
pnpbios: Found PnP BIOS data at 0xc00f7200
pnpbios: Entry = f:abbe  Rev = 1.0
Other BIOS signatures found:
Initializing GEOMetry subsystem
null: null device, zero device
random: entropy source
mem: memory  I/O
Pentium Pro MTRR support enabled
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: SHARP  PC-XJ800 on motherboard
ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15
ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST
ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST
ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST
pci_open(1):mode 1 addr port (0x0cf8) is 0x8000384c
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=71908086)
Using $PIR table, 7 entries at 0xc00fdf50
PCI-Only Interrupts: none
Location  Bus Device Pin  Link  IRQs
embedded10A   0x60  3 4 5 6 7 9 10 11 12 14 15
embedded10B   0x61  3 4 5 6 7 9 10 11 12 14 15
embedded10C   0x62  3 4 5 6 7 9 10 11 12 14 15
embedded10D   0x63  3 4 5 6 7 9 10 11 12 14 15
embedded01A   0x61  3 

current/stable remote gdb interoperability

2003-01-03 Thread ryan beasley
I'm running -CURRENT from around Dec 28th, 2002, 04:00 -0600, on a
testing machine.  While debugging a 3rd party module, I occasionally
find myself in situations where I can't obtain a core dump.  (e.g., a
panic related to a lock assertion occurs just before the dump routine
begins.)  To get around this, I decided I'd use my other RELENG_4_7 box
as a remote GDB master.

The serial port on the -CURRENT machine is compiled at 38400.  FYI,
jesper == 4.7R-p2 debugging box, and fredrik == 5.0 panic box.  This
instance of gdb was compiled from source w/ the patches found in the
devel/gdb52 port.  (I don't have room for the ports tree locally.)

The problem I'm running into is primarily erratic behavior.  The trace
trap shown below occurs frequently, and while it's only a minor
annoyance, my main concern is gdb randomly freezing when attempting to
get a backtrace.  (Sometimes it'll run to completion, others will hang
between frames.)

Is this a case of user error?  (I've never had a problem w/ serial rates
9600 bps between similarly configured RELENG_4 boxes.)  Is cross-
release debugging taboo?  What do the experts recommend I do?

TIA!

Session output is included below:

ryanb@jesper ~/FREDRIK_DP_INV gdb52 --baud 38400
GNU gdb 5.2 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-unknown-freebsd4.7.
(gdb) target remote /dev/cuaa0
Remote debugging using /dev/cuaa0
0xc02a5aba in ?? ()
(gdb) add-symbol-file kernel.debug
add symbol table from file kernel.debug at
(y or n) y
Reading symbols from kernel.debug...done.
(gdb) dir sys
Source directories searched: /home/ryanb/FREDRIK_DP_INV/sys:$cdir:$cwd
(gdb) dir ipfilter
Source directories searched:
/home/ryanb/FREDRIK_DP_INV/ipfilter:/home/ryanb/FREDRIK_DP_INV/sys:$cdir:$cwd
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
Debugger (msg=0x19 Address 0x19 out of bounds) at atomic.h:260
260 atomic.h: No such file or directory.
in atomic.h
(gdb) bt
#0  Debugger (msg=0x19 Address 0x19 out of bounds) at atomic.h:260
#1  0xc01bc5c7 in witness_lock (lock=0xc1264734, flags=8,
file=0xc02d9e6d /usr/src/sys/kern/kern_descrip.c, line=2108)
at /usr/src/sys/kern/subr_witness.c:720
#2  0xc0190441 in _mtx_lock_flags (m=0x0, opts=0,
file=0xc1264734  \0170ÀU\230-ÀU\230-À, line=-1070255508)
at /usr/src/sys/kern/kern_mutex.c:328
#3  0xc017eba3 in sysctl_kern_file (oidp=0xc02fdfe0, arg1=0x0, arg2=0,
req=0xc5f47c0c) at /usr/src/sys/kern/kern_descrip.c:2108
#4  0xc01a279b in sysctl_root (oidp=0x0, arg1=0xc5f47ca8, arg2=2,
req=0xc5f47c0c) at /usr/src/sys/kern/kern_sysctl.c:1150
(Session just dies here.)

ryanb@jesper ~ ps auxww | grep gdb
ryanb   50317  0.0  5.4 22272 21160  p4  S+7:35AM   0:01.87 gdb52 --baud
38400
Its current wait channel is (surprise!) ttyin.

-- 
ryan beasley[EMAIL PROTECTED]
GPG ID: 0x16EFBD48  http://www.goddamnbastard.org   



msg49585/pgp0.pgp
Description: PGP signature


Re: current/stable remote gdb interoperability

2003-01-03 Thread Alexander Kabaev
I've seen similar erratic behaviour myself when using gdb without -k
command switch. Can it be your problem too?

Also, you might want to look for sample .gdbinit files for useful gbd
macros other people are using. These files are in the tree somewhere.

-- 
Alexander Kabaev

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



Re: current/stable remote gdb interoperability

2003-01-03 Thread ryan beasley
On Fri, Jan 03, 2003 at 10:19:03AM -0500, Alexander Kabaev wrote:
 I've seen similar erratic behaviour myself when using gdb without -k
 command switch. Can it be your problem too?

Are you saying that you don't see this problem when using the -k flag?

I don't have the -k option at my disposal.  I could be wrong, but I
think that the -k extension to GDB is found only in changes made to
whatever's included under src/contrib/gdb, not in the patches for the
ports.  (RELENG_4 is still including GDB 4.18, and that can't read the
debugging info in the new 5.0 kernel.  That's why I installed a new
version manually.  :).)

 Also, you might want to look for sample .gdbinit files for useful gbd
 macros other people are using. These files are in the tree somewhere.

Will do.

Thanks for the reply.

-- 
ryan beasley[EMAIL PROTECTED]
GPG ID: 0x16EFBD48  http://www.goddamnbastard.org   



msg49587/pgp0.pgp
Description: PGP signature


Re: sshd login

2003-01-03 Thread Gregory Neil Shapiro
dcs Ok, I found the query packets, on the loopback:

dcs [root@piratinga root]# tcpdump -ni lo0 -s1500
dcs tcpdump: listening on lo0
dcs 11:54:05.602126 127.0.0.1.49202  127.0.0.1.53:  41012+ PTR? 
dcs 17.199.31.172.in-addr.arpa. (44)
dcs 11:54:10.605353 127.0.0.1.49203  127.0.0.1.53:  41012+ PTR? 
dcs 17.199.31.172.in-addr.arpa. (44)
dcs 11:54:20.611284 127.0.0.1.49204  127.0.0.1.53:  41012+ PTR? 
dcs 17.199.31.172.in-addr.arpa. (44)

dcs Only there is no reason in hell for it to query 127.0.0.1.

I can't guarantee this will work, but give it a try.  Put a copy of your
resolv.conf in /var/empty/etc/ and restart sshd.


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



Re: buildworld trouble: multiple struct dos_partition.

2003-01-03 Thread Takahashi Yoshihiro
In article [EMAIL PROTECTED]
Poul-Henning Kamp [EMAIL PROTECTED] writes:

 I think you need to either #ifdef something here (and there may be
 more some similar code in places like truss or the debugger) or
 alternatively rename the structure to pc98_partition or similar.

I think that the name dos_partition is not suitable for both i386
and pc98.  I wonder what does dos mean here.  For example, it should
be renamed to mbr_partition for i386 and pc98_partition for pc98,
respectively.

---
TAKAHASHI Yoshihiro [EMAIL PROTECTED]

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



Re: sshd login

2003-01-03 Thread Daniel C. Sobral
Gregory Neil Shapiro wrote:


dcs Ok, I found the query packets, on the loopback:

dcs [root@piratinga root]# tcpdump -ni lo0 -s1500
dcs tcpdump: listening on lo0
dcs 11:54:05.602126 127.0.0.1.49202  127.0.0.1.53:  41012+ PTR?
dcs 17.199.31.172.in-addr.arpa. (44)
dcs 11:54:10.605353 127.0.0.1.49203  127.0.0.1.53:  41012+ PTR?
dcs 17.199.31.172.in-addr.arpa. (44)
dcs 11:54:20.611284 127.0.0.1.49204  127.0.0.1.53:  41012+ PTR?
dcs 17.199.31.172.in-addr.arpa. (44)

dcs Only there is no reason in hell for it to query 127.0.0.1.

I can't guarantee this will work, but give it a try.  Put a copy of your
resolv.conf in /var/empty/etc/ and restart sshd.


That doesn't work.

--
Daniel C. Sobral
Gerência de Operações
Divisão de Comunicação de Dados
Coordenação de Segurança
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail:	[EMAIL PROTECTED]
	[EMAIL PROTECTED]
	[EMAIL PROTECTED]



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



Re: Status of NEWCARD for IBM ThinkPad 600s

2003-01-03 Thread Kevin Oberman
 Date: Thu, 2 Jan 2003 23:21:56 -0500 (EST)
 From: Matthew N. Dodd [EMAIL PROTECTED]
 
 On Thu, 2 Jan 2003, Kevin Oberman wrote:
  After DP2 was released, PCCARDs were no longer recognized by IBM
  ThinkPads in the 600 series. I just get:
 
  pccard1: Card has no functions!
  cbb1: PC Card card activation failed
 
 either set from the loader or add to /boot/device.hints
 
 hw.cbb.start_memory=536870912
 
 (or some other memory address  physical)
 
 -- 
 | Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
 | [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
 | http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
 

Victory???

Thanks, Matthew. My system now sees the card. 

Any reason you chose to provide the value in decimal instead of hex? I
can remember 0x2000 a lot easier.

The next issue is getting the card to actually work! I can manually
run pcard_ether and dhclient and it works, but I suspect that devd is
supposed to handle this.

I have read the man pages, but they seem to have only a little to do
with reality. (no /etc/devd-generic,for example.) Nor are there any
exampled in the man page for devd.conf nor a devd.conf file.

Is there anywhere I can find documentation?

Thanks,

R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]  Phone: +1 510 486-8634


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



Re: sshd login

2003-01-03 Thread Daniel C. Sobral
ryan beasley wrote:


On Fri, Jan 03, 2003 at 11:57:53AM -0200, Daniel C. Sobral wrote:

Daniel C. Sobral wrote:


Starting around the end of the year, sshd is taking a LONG time to
proceed, just a bit after the few first packets.

Ok, I found the query packets, on the loopback:
17.199.31.172.in-addr.arpa. (44)

*snip*

Only there is no reason in hell for it to query 127.0.0.1. My
configuration files:

*snip*

Anyone has suggestions?


Are you using privilege separation?  Have you always used privilege
separation?  If the answer to the first is yes and the second no,
then I'm betting that it's the forked pre-auth process that's chroot'd
to /var/empty (or whatever you set the chroot dir to).  You'd need to
stick a hosts/resolv.conf in the chroot environment. (e.g.,
/var/empty/etc/resolv.conf)


Alas, that *did* work. My first attempt (replying to another message) 
was done with wrong permissions.

Question... it did not have this trouble before Dec 13, but Dec 30 it 
had (no worlds in between). The sshd_config I use is the standard one. 
So... why?

--
Daniel C. Sobral
Gerência de Operações
Divisão de Comunicação de Dados
Coordenação de Segurança
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail:	[EMAIL PROTECTED]
	[EMAIL PROTECTED]
	[EMAIL PROTECTED]



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


Re: buildworld trouble: multiple struct dos_partition.

2003-01-03 Thread phk
In message [EMAIL PROTECTED], Takahashi Yoshihiro 
writes:
In article [EMAIL PROTECTED]
Poul-Henning Kamp [EMAIL PROTECTED] writes:

 I think you need to either #ifdef something here (and there may be
 more some similar code in places like truss or the debugger) or
 alternatively rename the structure to pc98_partition or similar.

I think that the name dos_partition is not suitable for both i386
and pc98.  I wonder what does dos mean here.  For example, it should
be renamed to mbr_partition for i386 and pc98_partition for pc98,
respectively.

You are correct in principle.

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

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



Re: buildworld trouble: multiple struct dos_partition.

2003-01-03 Thread Bruce Evans
On Fri, 3 Jan 2003 [EMAIL PROTECTED] wrote:

 In message [EMAIL PROTECTED], Takahashi Yoshihiro
 writes:
 In article [EMAIL PROTECTED]
 Poul-Henning Kamp [EMAIL PROTECTED] writes:
 
  I think you need to either #ifdef something here (and there may be
  more some similar code in places like truss or the debugger) or
  alternatively rename the structure to pc98_partition or similar.
 
 I think that the name dos_partition is not suitable for both i386
 and pc98.  I wonder what does dos mean here.  For example, it should
 be renamed to mbr_partition for i386 and pc98_partition for pc98,
 respectively.

 You are correct in principle.

pc98_partition is OK, but mbr_partition is bogus since partition tables
are not restricted to the MBR -- there is one in every extended partition.

sys/diskpc98.h is similarly OK and sys/diskmbr.h is similarly bogus.

at386 would be a better prefix/suffix than mbr for the non-pc98 pc's.
It is used for the main bus space header.

The normal prefix for partition table seems to be  according to google.
FreeBSD has dos_partition and NetBSD has mbr_partition.

Bruce


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



aligned_nblks calculations broken in vm_swap.c

2003-01-03 Thread Bruce Evans
% Index: vm_swap.c
% ===
% RCS file: /home/ncvs/src/sys/vm/vm_swap.c,v
% retrieving revision 1.127
% retrieving revision 1.128
% diff -u -1 -r1.127 -r1.128
% --- vm_swap.c 3 Jan 2003 09:55:05 -   1.127
% +++ vm_swap.c 3 Jan 2003 14:30:46 -   1.128
% ...
% @@ -353,3 +352,3 @@
%*/
% - aligned_nblks = (nblks + (dmmax - 1))  ~(u_long)(dmmax - 1);
% + aligned_nblks = (nblks + dmmax_mask)  ~(u_long)dmmax_mask;
%
% @@ -472,3 +471,3 @@
%
% - aligned_nblks = (nblks + (dmmax - 1))  ~(u_long)(dmmax - 1);
% + aligned_nblks = (nblks + dmmax_mask)  ~(u_long)dmmax_mask;
%   nswap = aligned_nblks * nswdev;

dmmax_mask is ~(dmmax - 1) not (dmmax - 1), so all of these changes are
wrong.

(New) nearby style bugs: removing the use of dmmax bogotifies a comment
which refers to dmmax.

(Old) related type bugs: dmmax_mask has the bogus type `int', so it is not
clear how it works as a mask on machines with 32-bit ints and 64-bit
block numbers.  I think it works because all supported machines are 2's
complement; this makes the negative value obtained by complementing the
bits of (dmmax - 1) right for masking with ints, and C's integral promotion
rules then make it right for masking with larger integral types too.
~(u_long)(dmmax - 1) in the old code was more careful about this, except it
only works for u_long and smaller block numbers (which is enough for
aligned_nblks).

Bruce


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



Re: current/stable remote gdb interoperability

2003-01-03 Thread Nate Lawson
On Fri, 3 Jan 2003, ryan beasley wrote:
 The serial port on the -CURRENT machine is compiled at 38400.  FYI,
 jesper == 4.7R-p2 debugging box, and fredrik == 5.0 panic box.  This
 instance of gdb was compiled from source w/ the patches found in the
 devel/gdb52 port.  (I don't have room for the ports tree locally.)
 
 The problem I'm running into is primarily erratic behavior.  The trace
 trap shown below occurs frequently, and while it's only a minor
 annoyance, my main concern is gdb randomly freezing when attempting to
 get a backtrace.  (Sometimes it'll run to completion, others will hang
 between frames.)

The bt command causes a lot of serial io and so you are probably running
into problems with siointr() not being fast.  Try backing down to 9600 and
see if that works.  I've had a similar problem before.  Everything else
you are doing seems ok.

-Nate


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



Re: alpha tinderbox failure

2003-01-03 Thread Ollivier Robert
According to Dag-Erling Smorgrav:
 Date: Wed, 1 Jan 2003 03:42:27 -0800 (PST)
 From: Dag-Erling Smorgrav [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: alpha tinderbox failure
 
It is still generating multi-thousands mails, please fix des.
-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun  4 22:44:19 CEST 2000

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



Re: System freeze running -current

2003-01-03 Thread Nate Lawson
On Fri, 3 Jan 2003, Trent Nelson wrote:
 I've experienced -current lock up in exactly the same way twice now;
 once with 5.0-RC2, and just now, with sources from 30th December.
 
 The system in question is a Sharp PC-AR50 laptop.  In both instances 
 the system was idle and I was editing a file in vim on ttyv0.  Both
 systems exhibited the following symptoms:
 
   1.  Able to switch terminals using alt-F1..F8, but that's it, I'm un-
   able to type anything else (keyboard doesn't respond to letters,
   numbers, but capslock and numlock still turn on lights).
   2.  Responds to pings from other systems on the network.

Sounds like an atkbd or syscons problem.  Did you suspend the laptop and
resume before this happens?  How does unset acpi_load at the boot prompt
change things?

-Nate


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



Re: aligned_nblks calculations broken in vm_swap.c

2003-01-03 Thread phk
In message [EMAIL PROTECTED], Bruce Evans writes:
% Index: vm_swap.c
% ===
% RCS file: /home/ncvs/src/sys/vm/vm_swap.c,v
% retrieving revision 1.127
% retrieving revision 1.128
% diff -u -1 -r1.127 -r1.128
% --- vm_swap.c3 Jan 2003 09:55:05 -   1.127
% +++ vm_swap.c3 Jan 2003 14:30:46 -   1.128
% ...
% @@ -353,3 +352,3 @@
%   */
% -aligned_nblks = (nblks + (dmmax - 1))  ~(u_long)(dmmax - 1);
% +aligned_nblks = (nblks + dmmax_mask)  ~(u_long)dmmax_mask;
%
% @@ -472,3 +471,3 @@
%
% -aligned_nblks = (nblks + (dmmax - 1))  ~(u_long)(dmmax - 1);
% +aligned_nblks = (nblks + dmmax_mask)  ~(u_long)dmmax_mask;
%  nswap = aligned_nblks * nswdev;

dmmax_mask is ~(dmmax - 1) not (dmmax - 1), so all of these changes are
wrong.

damn!

Fixed, thanks!

(Old) related type bugs:

I'm actually more than a bit of mind to rip out the entire bogus
swap-stripe code:  If you want swap on a striped disk, you should
use hardware, controller, vinum, ccd or raidframe to stripe.

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

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



Re: current/stable remote gdb interoperability

2003-01-03 Thread Bruce Evans
On Fri, 3 Jan 2003, Nate Lawson wrote:

 On Fri, 3 Jan 2003, ryan beasley wrote:
  The serial port on the -CURRENT machine is compiled at 38400.  FYI,
  jesper == 4.7R-p2 debugging box, and fredrik == 5.0 panic box.  This
  instance of gdb was compiled from source w/ the patches found in the
  devel/gdb52 port.  (I don't have room for the ports tree locally.)
 
  The problem I'm running into is primarily erratic behavior.  The trace
  trap shown below occurs frequently, and while it's only a minor
  annoyance, my main concern is gdb randomly freezing when attempting to
  get a backtrace.  (Sometimes it'll run to completion, others will hang
  between frames.)

 The bt command causes a lot of serial io and so you are probably running
 into problems with siointr() not being fast.  Try backing down to 9600 and
 see if that works.  I've had a similar problem before.  Everything else
 you are doing seems ok.

Er, the debugging machine runs 4.7, so siointr() shouldn't be broken.
The debuggee machine does serial i/o using polling when in gdb, so
siointr() is not involved.  It's not clear if/how polled mode actually
works.  The debuggee may be in a loop sending; if it spends more than
size of input fifo character times in its output look then it will
miss input.  The protocol may be carefully designed to limit problems,
but it would be easier to poll for input and output concurrently.  I
don't know if the protocol is so designed; the i/o routines certainly
aren't smart.  I've never seen problems at 115200 bps in practice, but
I rarely use gdb for kernel debugging.

Another possible problem is using the same serial line for gdb as for
the console and mixing speeds.  If the userland speed differs from the
low level speed, then the i/o routines switch back and forth between
the speeds for every character and this tends to lose some.  The
userland speed is locked to the low level speed initially but userland
unlock it.  Losing a character or two is almost unnoticable in ddb but
is fatal in gdb.  I normally set all speeds to 115200 so I only see this
problem when I look for it.

Bruce


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



subscribe

2003-01-03 Thread Jeff Adams
subscribe


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



Re: buildworld trouble: multiple struct dos_partition.

2003-01-03 Thread Terry Lambert
Bruce Evans wrote:
 pc98_partition is OK, but mbr_partition is bogus since partition tables
 are not restricted to the MBR -- there is one in every extended partition.
 
 sys/diskpc98.h is similarly OK and sys/diskmbr.h is similarly bogus.
 
 at386 would be a better prefix/suffix than mbr for the non-pc98 pc's.
 It is used for the main bus space header.
 
 The normal prefix for partition table seems to be  according to google.
 FreeBSD has dos_partition and NetBSD has mbr_partition.

The PReP specification (PPC Reference Platform) goes into great
gory detail on DOS Partition Tables, as does the DEC Alpha boot
documentation.  The fact is that DOS Partition tables are used in
a lot of places that are unrelated to x86.

PS: The PReP documentation is probably the finest documentation
for the DOS partition table format available anywhere.

-- Terry

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



Re: mount_portalfs broken in 5.0-RC2

2003-01-03 Thread Michael Ranner
Am Donnerstag, 2. Januar 2003 10:44 schrieb Tim Robbins:
 On Mon, Dec 30, 2002 at 10:51:20PM +0100, Michael Ranner wrote:
  After mounting the portalfs,
 
  # cat /p/tcp
 
  portalfs hangs instead of expected cat: /p/telnet: No such file or
  directory

Ok, I have to correct this. The first access to a file within /p
works as expected, but the second access locks the portalfs.

e.x.

# cat /p/tcp/1.2.3.4/110

works as expected for the first time an returns what you expect from
an pop3 server.

and

# cat /p/xyz

returns cat: /p/xyz: No such file or directory for the first time.

But if you try once again to access portalfs with /cat/tcp/1.2.3.4/110
or cat /p/xyz the portalfs hangs.

 I tried but failed to fix this. I think that the vnode locking in
 portalfs is hosed. From memory, I think that portal_lookup() was
 part of the problem. Try building a kernel with DEBUG_VFS_LOCKS and
 watch for the warnings from portalfs.

Attached the dmesg output from my kernel with DEBUG_VFS_LOCKS

-- 
/\/\ichael Ranner

[EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED]
--
JAWA Management Software GmbH - http://www.jawa.at/
  Liebenauer Hauptstrasse 2oo - A-8041 Graz
Tel +43 316 403274 21 - Fax +43 316 403274 10
--
 Mariazell Online - http://www.mariazell.at/
--

-BEGIN GEEK CODE BLOCK-
GIT/CS/AT dx(-) s+:(++:) a- C++ UBLVS$ P+$ L-(+)$ E---
W+++$ N+(++) o-- K- w--()$ O-(--) M@ V-(--) PS+++ PE(-) Y+ PGP(-)
t+ 5+ X+++() R* tv++ b+(++) DI++ D-(--) G- e h--(*) r++ y?
--END GEEK CODE BLOCK--

VOP_LOOKUP (dvp): 0xc4482ce4 is locked but should not be
Debugger(Lock violation.
) called.
lookup: 0xc4482960 is not locked but should be
Debugger(Lock violation.
) called.
VOP_CREATEVOBJECT: 0xc4482960 is not locked but should be
Debugger(Lock violation.
) called.
VOP_GETATTR: 0xc4482960 is not locked but should be
Debugger(Lock violation.
) called.
VOP_GETATTR: 0xc4482960 is not locked but should be
Debugger(Lock violation.
) called.
vnode_pager_alloc: 0xc4482960 is not locked but should be
Debugger(Lock violation.
) called.
VOP_CREATEVOBJECT: 0xc4482960 is not locked but should be
Debugger(Lock violation.
) called.
VOP_ACCESS: 0xc4482960 is not locked but should be
Debugger(Lock violation.
) called.
VOP_ACCESS: 0xc4482960 is not locked but should be
Debugger(Lock violation.
) called.
VOP_GETATTR: 0xc4482960 is not locked but should be
Debugger(Lock violation.
) called.
VOP_GETATTR: 0xc4482960 is not locked but should be
Debugger(Lock violation.
) called.
VOP_OPEN: 0xc4482960 is not locked but should be
Debugger(Lock violation.
) called.
VOP_OPEN: 0xc4482960 is not locked but should be
Debugger(Lock violation.
) called.
VOP_INACTIVE: 0xc4482960 is not locked but should be
Debugger(Lock violation.
) called.
VOP_UNLOCK: 0xc4482960 is not locked but should be
Debugger(Lock violation.
) called.



Re: aligned_nblks calculations broken in vm_swap.c

2003-01-03 Thread David Schultz
Thus spake [EMAIL PROTECTED] [EMAIL PROTECTED]:
 I'm actually more than a bit of mind to rip out the entire bogus
 swap-stripe code:  If you want swap on a striped disk, you should
 use hardware, controller, vinum, ccd or raidframe to stripe.

Ccd is a nice simple solution, but by using it you lose the
ability to dynamically add and remove swap and play other tricks
like swap device prioritization.  (Actually, prioritization would
require a better abstraction for the swap subsystem anyway.)  On
the other hand, the static limit on the number of devices is
annoying.  But the point is that the swap striping code isn't
entirely redundant.

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



Re: ep0 hard lockup during install

2003-01-03 Thread Garrett Wollman
On Tue, 31 Dec 2002 00:34:04 -0500 (EST), Matthew N. Dodd [EMAIL PROTECTED] said:

 I just installed RC2 using a 3C574B with the 'ep' driver; worked just fine
 aside from needing to re-roll kern.flp and mfsroot.flp to support OLDCARD.

My 3C589D works just fine in 5-current with NEWCARD.

-GAWollman


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



Jail detection

2003-01-03 Thread Julian Elischer

We have some software we'd like to behave slightly differently if it is
in a jail.

What methods do people use to detect they are in a jail?
procfs/curproc might work but I don't want to depend on procfs.
ps aux can be used but seems rather heavyweight.
Something like a sysctl would be best. I could implement it
(unless there's already something I missed), if it was considered 
the right answer.


Also, does anyone wnow the mechanism for ping failing (in 4.x systems)
from jails?

Julian



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



Re: Jail detection

2003-01-03 Thread phk
In message [EMAIL PROTECTED], Ju
lian Elischer writes:

We have some software we'd like to behave slightly differently if it is
in a jail.

What methods do people use to detect they are in a jail?
procfs/curproc might work but I don't want to depend on procfs.
ps aux can be used but seems rather heavyweight.
Something like a sysctl would be best. I could implement it
(unless there's already something I missed), if it was considered 
the right answer.

Use sysctl to pick up your own proc, look for the jail flag.  It takes
less than 10 lines of C.

Also, does anyone wnow the mechanism for ping failing (in 4.x systems)
from jails?

Yes.  raw sockets are blanket denied in jails.  Not because it is impossible
to properly filter them, but because nobody has written the code it takes.

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

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



Lock order reversal in if_tl device.

2003-01-03 Thread Pawel Jakub Dawidek
Hello...

tl0: device timeout
lock order reversal
 1st 0xc0331020 ifnet (ifnet) @ /usr/src/sys/net/if.c:1181
 2nd 0xc2576ab8 tl0 (network driver) @ /usr/src/sys/pci/if_tl.c:2067

Driver is loaded via kld module from /boot/loader.conf.
To get interface up I need to unload and load module again.

Here is my kernel config and dmesg.boot:

http://prioris.mini.pw.edu.pl/~nick/dmesg.boot
http://prioris.mini.pw.edu.pl/~nick/SLAYER

-- 
Pawel Jakub Dawidek
UNIX Systems Administrator
http://garage.freebsd.pl
Am I Evil? Yes, I Am.

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



Re: Jail detection

2003-01-03 Thread Julian Elischer


On Fri, 3 Jan 2003 [EMAIL PROTECTED] wrote:

 In message [EMAIL PROTECTED], Ju
 lian Elischer writes:
 
 We have some software we'd like to behave slightly differently if it is
 in a jail.
 
 What methods do people use to detect they are in a jail?
 procfs/curproc might work but I don't want to depend on procfs.
 ps aux can be used but seems rather heavyweight.
 Something like a sysctl would be best. I could implement it
 (unless there's already something I missed), if it was considered 
 the right answer.
 
 Use sysctl to pick up your own proc, look for the jail flag.  It takes
 less than 10 lines of C.

I can't see anything relevant in sysctl -a. I didn't say it was a C
program. (for that matter what are those 10 lines?) I 've often wondered
how to get the proc info out of sysctl.. I guess it's whatever libkvm
does. (I'll go hunting)\

I was thinking of something like:

static int
sysctl_jail_status(SYSCTL_HANDLER_ARGS)
{
int val;

val = (curproc-p_flag  P_JAIL)? 1 : 0 ;
return (sysctl_handle_int(oidp, NULL, val, req));
}
SYSCTL_PROC(_jail, OID_AUTO, status, CTLTYPE_INT|CTLFLAG_RD,
0, sizeof val, sysctl_jail_status, I, Are we in a jail?);

in kern_jail.c
(in 4.x) 
this would work better for things like shell and perl as well as for C

 
 Also, does anyone wnow the mechanism for ping failing (in 4.x systems)
 from jails?
 
 Yes.  raw sockets are blanket denied in jails.  Not because it is impossible
 to properly filter them, but because nobody has written the code it takes.

I'll take a look.
For me I'd allow it if a sysctl said so.. there are other reasons for
making jails than just securing things..
For example I need to have a 4.3 environment in a 4.7++ system
(differnt sets of ports needed for the application)
I completely trust the code in the jail. I just need it to
be partitionned so it doesn't interfere with the ports and system
running the main system. One of the things it does is
to ping peers to see if they are available..

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


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



alpha tinderbox failure

2003-01-03 Thread Dag-Erling Smorgrav
--
 Rebuilding the temporary build tree
--
 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/alpha/obj/h/des/src/alpha/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
=== usr.bin/vi
*** Error code 1 (ignored)
*** Error code 1 (ignored)
=== usr.bin/vis
=== usr.bin/vmstat
=== usr.bin/w
=== usr.bin/wall
=== usr.bin/wc
=== usr.bin/what
=== usr.bin/whereis
=== usr.bin/which
=== usr.bin/who
=== usr.bin/whois
=== usr.bin/window
=== usr.bin/write
=== usr.bin/xargs
=== usr.bin/xinstall
=== usr.bin/xlint
=== usr.bin/xlint/lint1
yacc: 1 shift/reduce conflict
=== usr.bin/xlint/lint2
=== usr.bin/xlint/xlint
=== usr.bin/xlint/llib
=== usr.bin/xstr
=== usr.bin/yacc
=== usr.bin/yes
=== usr.bin/ypcat
=== usr.bin/ypmatch
=== usr.bin/ypwhich
=== usr.bin/dig
=== usr.bin/dnskeygen
=== usr.bin/dnsquery
=== usr.bin/host
=== usr.bin/vacation
=== usr.bin/uac
=== usr.bin/chkey
=== usr.bin/newkey
=== usr.sbin
=== usr.sbin/IPXrouted
=== usr.sbin/ac
=== usr.sbin/accton
=== usr.sbin/adduser
=== usr.sbin/amd
=== usr.sbin/amd/include
=== usr.sbin/amd/libamu
=== usr.sbin/amd/amd
=== usr.sbin/amd/amq
=== usr.sbin/amd/doc
=== usr.sbin/amd/fixmount
=== usr.sbin/amd/fsinfo
yacc: 2 shift/reduce conflicts
=== usr.sbin/amd/hlfsd
=== usr.sbin/amd/mk-amd-map
=== usr.sbin/amd/pawd
=== usr.sbin/amd/scripts
=== usr.sbin/amd/wire-test
=== usr.sbin/ancontrol
=== usr.sbin/arp
=== usr.sbin/atm
=== usr.sbin/atm/atmarpd
=== usr.sbin/atm/scspd
=== usr.sbin/bootparamd
=== usr.sbin/bootparamd/bootparamd
=== usr.sbin/bootparamd/callbootd
=== usr.sbin/burncd
=== usr.sbin/cdcontrol
=== usr.sbin/chkgrp
=== usr.sbin/chown
=== usr.sbin/chroot
=== usr.sbin/ckdist
=== usr.sbin/config
=== usr.sbin/cron
=== usr.sbin/cron/lib
=== usr.sbin/cron/cron
=== usr.sbin/cron/crontab
=== usr.sbin/crunch
=== usr.sbin/crunch/crunchgen
=== usr.sbin/crunch/crunchide
=== usr.sbin/ctm
=== usr.sbin/ctm/ctm
=== usr.sbin/ctm/ctm_rmail
=== usr.sbin/ctm/ctm_smail
=== usr.sbin/ctm/ctm_dequeue
=== usr.sbin/daemon
=== usr.sbin/dev_mkdb
=== usr.sbin/devinfo
=== usr.sbin/digictl
=== usr.sbin/edquota
=== usr.sbin/extattr
=== usr.sbin/extattrctl
=== usr.sbin/faithd
=== usr.sbin/fdcontrol
=== usr.sbin/fdformat
=== usr.sbin/fdread
=== usr.sbin/fdwrite
=== usr.sbin/fwcontrol
=== usr.sbin/getfmac
=== usr.sbin/getpmac
=== usr.sbin/ifmcstat
=== usr.sbin/inetd
=== usr.sbin/iostat
=== usr.sbin/jail
=== usr.sbin/kbdcontrol
=== usr.sbin/kbdmap
=== usr.sbin/kernbb
=== usr.sbin/kldxref
=== usr.sbin/lastlogin
=== usr.sbin/mailwrapper
=== usr.sbin/manctl
=== usr.sbin/memcontrol
=== usr.sbin/mergemaster
=== usr.sbin/mixer
=== usr.sbin/mld6query
=== usr.sbin/mlxcontrol
=== usr.sbin/mountd
=== usr.sbin/moused
=== usr.sbin/mrouted
=== usr.sbin/mrouted/common
=== usr.sbin/mrouted/mrouted
=== usr.sbin/mrouted/mrinfo
=== usr.sbin/mrouted/map-mbone
=== usr.sbin/mrouted/mtrace
=== usr.sbin/mrouted/testrsrr
=== usr.sbin/mtest
=== usr.sbin/mtree
=== usr.sbin/ndp
=== usr.sbin/newsyslog
=== usr.sbin/nfsd
=== usr.sbin/ngctl
=== usr.sbin/ntp
=== usr.sbin/ntp/libntp
=== usr.sbin/ntp/libparse
=== usr.sbin/ntp/ntpd
Version ntpd 4.1.1b-a Fri Jan  3 14:15:24 PST 2003 (1)
=== usr.sbin/ntp/ntpdc
Version ntpdc 4.1.1b-a Fri Jan  3 14:15:26 PST 2003 (1)
=== usr.sbin/ntp/ntpq
Version ntpq 4.1.1b-a Fri Jan  3 14:15:27 PST 2003 (1)
=== usr.sbin/ntp/ntpdate
Version ntpdate 4.1.1b-a Fri Jan  3 14:15:27 PST 2003 (1)
=== usr.sbin/ntp/ntptrace
Version ntptrace 4.1.1b-a Fri Jan  3 14:15:27 PST 2003 (1)
=== usr.sbin/ntp/ntptimeset
Version ntptimeset 4.1.1b-a Fri Jan  3 14:15:27 PST 2003 (1)
=== usr.sbin/ntp/ntptime
=== usr.sbin/ntp/ntp-genkeys
=== usr.sbin/ntp/doc
=== usr.sbin/nghook
=== usr.sbin/pccard
=== usr.sbin/pccard/pccardc
=== usr.sbin/pccard/pccardd
=== usr.sbin/pciconf
=== usr.sbin/periodic
=== usr.sbin/pkg_install
=== usr.sbin/pkg_install/lib
=== usr.sbin/pkg_install/add
=== usr.sbin/pkg_install/create
=== usr.sbin/pkg_install/delete
=== usr.sbin/pkg_install/info
=== usr.sbin/pkg_install/version
=== usr.sbin/pkg_install/sign
=== usr.sbin/ppp
=== usr.sbin/pppd
=== usr.sbin/pppstats
=== usr.sbin/procctl
=== usr.sbin/pstat
=== usr.sbin/pw
=== usr.sbin/pwd_mkdb
=== usr.sbin/quot
=== usr.sbin/quotaon
=== usr.sbin/rarpd
=== usr.sbin/raycontrol
=== usr.sbin/repquota
=== 

Proper -current if_attach locking?

2003-01-03 Thread Nate Lawson
I was looking into some could sleep messages and found some bogus
locking in the attach routine of many drivers.  Several init a mtx in
their softc and then lock/unlock it in their attach routine.  This, of
course, does nothing to provide exclusive access to a device.  I assume
there is going to be a global IF_LOCK or something to be used in attach
routines.  Can someone fill me in on the intended design?

-Nate


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



ia64 tinderbox failure

2003-01-03 Thread Peter Wemm
--
 Rebuilding the temporary build tree
--
 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/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== usr.bin/kdump
In file included from ioctl.c:74:
/home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include/sys/diskpc98.h:47: 
redefinition of `struct dos_partition'
*** Error code 1

Stop in /home/tinderbox/ia64/src/usr.bin/kdump.
*** Error code 1

Stop in /home/tinderbox/ia64/src/usr.bin.
*** Error code 1

Stop in /home/tinderbox/ia64/src.
*** Error code 1

Stop in /home/tinderbox/ia64/src.
*** Error code 1

Stop in /home/tinderbox/ia64/src.

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



panic with panic: kmem_malloc(4096): kmem_map too small...

2003-01-03 Thread Willem Jan Withagen
Which seems a problem sticking up it's head once so often.
I had it happen to me now 3 times over the last day. It just drops into the debugger.
And I've foun little extra info in the archive.

What dows this actually mean? Is something leaking in the kernel.
IF so how do I help it go away.

I'm copy 100G from a W2K system to my vinum file server with a 170G raid5.
Current is as of 28 dec...

System has 96Mb and runs on a P-II 200Mhz/realtek ethernet.
It just runs: kernel/nfs/ssh/samba/sendmail

The other problem the system suffers from is running a backgrounded fsck on
the vinum raid. That is a shure way to freeze the system.
Running it in the forground always works fine. So that problem could be the one that 
was discussed on the list before??

Regards,
--WjW




N…'²æìr¸›zǧvf¢–Új:+v‰¨·ž è®¶§²æìr¸›yúÞy»rêëz{bžØ^n‡r¡ûazg¬±¨


sshd fails with: fatal: ssh_msg_send: write

2003-01-03 Thread Craig Rodrigues
Hi,

I've seen similar posts about this problem but with no
solution here:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=212876+0+archive/2002/freebsd-current/20021222.freebsd-current



I've recently cvsup'd and rebuilt the world, and now I cannot
access my machine with ssh.  In the console, I am seeing these
messages when I try to login:

sshd[2168]: fatal: ssh_msg_send: write
sshd[2171]: fatal: ssh_msg_send: write


If I restart my server with:
sshd -d -d -d

I get the following output:

debug3: mm_pam_init_ctx
debug3: mm_request_send entering: type 42
debug3: monitor_read: checking request 42
debug3: mm_answer_pam_init_ctx
debug3: mm_pam_init_ctx: waiting for MONITOR_ANS_PAM_INIT_CTX
debug3: mm_request_receive_expect entering: type 43
debug3: mm_request_receive entering
debug3: ssh_msg_send: type 1
ssh_msg_send: write
debug1: Calling cleanup 0x8061180(0x0)
debug1: PAM: cleanup
debug3: mm_request_receive entering
debug3: monitor_read: checking request 44
debug3: mm_answer_pam_query
debug3: ssh_msg_recv entering


This is the same backtrace posted by Segey Osokin:
 
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=248381+0+/usr/local/www/db/text/2002/freebsd-current/20021222.freebsd-current
  



The error messages are being printed here inside /usr/src/crypto/openssh/msg.c:

 33 void
 34 ssh_msg_send(int fd, u_char type, Buffer *m)
 35 {
 36 u_char buf[5];
 37 u_int mlen = buffer_len(m);
 38
 39 debug3(ssh_msg_send: type %u, (unsigned int)type  0xff);
 40
 41 PUT_32BIT(buf, mlen + 1);
 42 buf[4] = type;  /* 1st byte of payload is mesg-type */
 43 if (atomicio(write, fd, buf, sizeof(buf)) != sizeof(buf))
 44 fatal(ssh_msg_send: write);
 45 if (atomicio(write, fd, buffer_ptr(m), mlen) != mlen)
 46 fatal(ssh_msg_send: write);
 47 }
 48


I really don't know what the problem is.is this a PAM problem?

Thanks.
-- 
Craig Rodrigues
http://home.attbi.com/~rodrigc
[EMAIL PROTECTED]

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



RE: SIS 962 chipset, problems ...

2003-01-03 Thread Luoqi Chen
 Good year everybody
 
 Luigi, I converted your patch to CURRENT, there were only
 minor changes to do and it seems to work !
 
 sis0: SiS 900 10/100BaseTX port 0x2000-0x20ff mem 
 0xec005000-0xec005fff irq 1$
 at device 4.0 on pci0
 sis0: Ethernet address: 00:00:e2:94:66:99
 miibus0: MII bus on sis0
 ukphy0: Generic IEEE 802.3u media interface on miibus0
 ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 
 http://people.freebsd.org/~mbr/patches/ifsis-luigi.diff
 
 and added the Linux way of reading the eeprom. I guess
 we should make this the default for accessing the eeprom (for 
 this chipset),
 since it is not only the mac address which gets read.
 
 Luigi: Or isn't this neccessary ?
 
 http://people.freebsd.org/~mbr/patches/ifsis-mbr.diff
 
 Martin
 
Yes, I think it is neccesary, but all my machines have 0x90
revisions. I've discovered another issue with the integrated
device, the dma burst size should be limited to 64 bytes.
This is in the Linux driver, search for EDB_MASTER_EN,
if this bit is set in config register, dma burst size can
be no larger than 64, otherwise data errors would sometimes
appear at 64 byte data boundaries.

There's also a bug exists in almost all Bill's network drivers:
when reading PHY regs over the i2c bus, the turnaround ACK bit
is read one clock edge too late. This bit is driven low by
slave (as any other input data bits from slave) when the clock
is LOW. The current code reads the bit after the clock is driven
high again.

-lq

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



Re: Jail detection

2003-01-03 Thread Scot Hetzel
From: Julian Elischer [EMAIL PROTECTED]
 We have some software we'd like to behave slightly differently if it is
 in a jail.

 What methods do people use to detect they are in a jail?

There's a program called in.jail (/usr/ports/sysutils/jailer) that is
capable of detecting if it is running in a jail.

Scot



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



[resolution] Re: sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay)

2003-01-03 Thread Gary W. Swearingen
(cc'd to -questions, where I first post my problem, with no luck)

Valentin Nechayev [EMAIL PROTECTED] writes:

 I fix it with:
 define(`confDIRECT_SUBMISSION_MODIFIERS',`CC u')dnl
 For now I has no such problem at my home machine.
 Yes, this solution isn't intuitive.

Thanks.  I tried that and some other things (eg service.switch).  Even
read the book and help files some more.  Terry's suggestion regarding
expensive seemed like the opposite of what I needed (I was trying to
keep the msg out of the queues) and I had no luck trying to disable some
DNS which he hinted at.

I got my first good clue after adding level 15 logging to see an 80-sec
delay between MUA-launched sendmail and the MTA daemon.  I then used
level-99 logging to find

Jan  3 13:43:56 localhost sendmail[63611]: h03Lgf6p063607:\
makeconnection (localhost.localdomain. [IPv6:::1]) \
failed: Operation timed out with localhost.localdomain.

I shoulda considered that one big config difference between my 4.7
config and 5.0 is custom kernel without IPv6 on 4.7 and still using
GENERIC kernel with IPv6 on 5.0!  I do have
::1 localhost localhost.localdomain
in my /etc/hosts, but there's apparently something else wrong.

Is there a quick way to disable IPv6?  While I figure that out or
rebuild my kernel, I got a quick fix by changing, in my submit.mc,
this
FEATURE(`msp')
to this
FEATURE(`msp',`[127.0.0.1]')

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



Re: [resolution] Re: sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay)

2003-01-03 Thread Terry Lambert
Gary W. Swearingen wrote:
 Thanks.  I tried that and some other things (eg service.switch).  Even
 read the book and help files some more.  Terry's suggestion regarding
 expensive seemed like the opposite of what I needed (I was trying to
 keep the msg out of the queues) and I had no luck trying to disable some
 DNS which he hinted at.
 
 I got my first good clue after adding level 15 logging to see an 80-sec
 delay between MUA-launched sendmail and the MTA daemon.  I then used
 level-99 logging to find

The book is pretty useless.  The reason the fix you are using
works is because you have an IPv6 connection by default, and by
explicitly specifying an IPv4 address, IPv4 is used.

The issue here is the .in-addr.arpa. delegation for localhost
is considered to be local.  When the getpeername() happens, it
gets an IPv6 address instead of an IPv4, and the the gethostbyaddr()
hangs looking for ::1.in-addr.arpa., but has no problem finding
1.0.0.127.in-addr.arpa..

You can fix this by disabling the DNS cross-check in the file
sendmail.cf, and by getting rid of the peer name lookup in the
loopback case.  What you did with the IPv4 just took advanatage
of the fact that the in-addr.arpa. IPv4 delegations existed, when
the IPv6 loopback address ones did not.


 Is there a quick way to disable IPv6?  While I figure that out or
 rebuild my kernel, I got a quick fix by changing, in my submit.mc,
 this
 FEATURE(`msp')
 to this
 FEATURE(`msp',`[127.0.0.1]')

This isn't the correct fix.  The correct fix is to add an IPv6 address
and in-addr.arap. delegation for the loopback in your local DNS.


As far as the HoldExpensive I recommended, the way you stated the
problem seemed to indicate that it was a failure to connect, not
a failure to validate a connection was going through.  In general,
ou want to queue up any mail that can bring up a link, if your link
is transiently connected, and then control the link with a seperate
queue interval.  The other DNS statements I made were to ensure that
the interface did not end up bouncing up when sendmail was started,
for local mail delivery, or for remote mail delivery, outside the
administratively controlled queueing intervals (which could be on
the order of seconds, if you wanted).

-- Terry

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



buildworld failure in usr.bin/kdump

2003-01-03 Thread Michael C. Ferguson

Hi all,

I just subscribed to the mailing lists today after upgrading to
5.0RC2, so I'm not sure if this has been reported or not. I'm relatively
new to FreeBSD (although I'm a long time Linux user), so I'll report how
I installed, just in case I missed something that might be causing this
problem.

1) Booted via floppies and did a minimal install via FTP.

2) pkg_added cvsup, and used it to get ports and the main source tree.
For the main source tree, I used
ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvs
up/standard-supfile, with tag=. For the ports, I used the example
ports-supfile.

3) Edited my /etc/make.conf for optimization

4) Installed editors/joe, kde_base (started last night, finished this
afternoon, I think), and the other necessary dependencies from ports.

4) Did 'make -j4 buildworld' in /usr/src. It failed.

5) Did 'make clean' in /usr/src.

5) Did 'make buildworld' in /usr/src, which failed again with the same
error; this time I saved the output. If you want to see the entire log,
it's at ftp://129.110.23.84/mw.out.bz2, along with the other relevant
files (dmesg, make.conf). 

Anyway, now that that's out of the way, here is the error:

-- start error section --

=== usr.bin/kdump
cc -O2 -pipe -march=pentium3 -I/usr/src/usr.bin/kdump/../ktrace
-I/usr/src/usr.bin/kdump/../..-c /usr/src/usr.bin/kdump/kdump.c
cc -O2 -pipe -march=pentium3 -I/usr/src/usr.bin/kdump/../ktrace
-I/usr/src/usr.bin/kdump/../..-c ioctl.c
In file included from ioctl.c:92:
/usr/obj/usr/src/i386/usr/include/sys/diskpc98.h:47: redefinition of
`struct dos_partition'
*** Error code 1

Stop in /usr/src/usr.bin/kdump.
*** Error code 1

Stop in /usr/src/usr.bin.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.

-- end error section --

I will cvsup tomorrow and try to build world again to see if it has been
fixed. My source was current as of around 2:00 PM CST today.



-- mcf





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



ia64 tinderbox failure

2003-01-03 Thread Peter Wemm
--
 Rebuilding the temporary build tree
--
 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/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== usr.bin/kdump
In file included from ioctl.c:74:
/home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include/sys/diskpc98.h:47: 
redefinition of `struct dos_partition'
*** Error code 1

Stop in /home/tinderbox/ia64/src/usr.bin/kdump.
*** Error code 1

Stop in /home/tinderbox/ia64/src/usr.bin.
*** Error code 1

Stop in /home/tinderbox/ia64/src.
*** Error code 1

Stop in /home/tinderbox/ia64/src.
*** Error code 1

Stop in /home/tinderbox/ia64/src.

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



i386 tinderbox failure

2003-01-03 Thread Dag-Erling Smorgrav
--
 Rebuilding the temporary build tree
--
 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/i386/obj/local0/scratch/des/src/i386/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
=== usr.bin/vi
*** Error code 1 (ignored)
*** Error code 1 (ignored)
=== usr.bin/vis
=== usr.bin/vmstat
=== usr.bin/w
=== usr.bin/wall
=== usr.bin/wc
=== usr.bin/what
=== usr.bin/whereis
=== usr.bin/which
=== usr.bin/who
=== usr.bin/whois
=== usr.bin/window
=== usr.bin/write
=== usr.bin/xargs
=== usr.bin/xinstall
=== usr.bin/xlint
=== usr.bin/xlint/lint1
yacc: 1 shift/reduce conflict
=== usr.bin/xlint/lint2
=== usr.bin/xlint/xlint
=== usr.bin/xlint/llib
=== usr.bin/xstr
=== usr.bin/yacc
=== usr.bin/yes
=== usr.bin/ypcat
=== usr.bin/ypmatch
=== usr.bin/ypwhich
=== usr.bin/dig
=== usr.bin/dnskeygen
=== usr.bin/dnsquery
=== usr.bin/host
=== usr.bin/vacation
=== usr.bin/doscmd
=== usr.bin/ncplist
=== usr.bin/ncplogin
=== usr.bin/sasc
=== usr.bin/smbutil
/local0/scratch/des/src/contrib/smbfs/smbutil/dumptree.c:74:62: warning: pasting ( 
and state:%s\n does not give a valid preprocessing token
/local0/scratch/des/src/contrib/smbfs/smbutil/dumptree.c:76:50: warning: pasting ( 
and flags:0x%04x %s\n does not give a valid preprocessing token
/local0/scratch/des/src/contrib/smbfs/smbutil/dumptree.c:77:51: warning: pasting ( 
and usecount: %d\n does not give a valid preprocessing token
/local0/scratch/des/src/contrib/smbfs/smbutil/dumptree.c:78:93: warning: pasting ( 
and dialect:  %d (%s)\n does not give a valid preprocessing token
/local0/scratch/des/src/contrib/smbfs/smbutil/dumptree.c:79:53: warning: pasting ( 
and smode:%d\n does not give a valid preprocessing token
/local0/scratch/des/src/contrib/smbfs/smbutil/dumptree.c:81:58: warning: pasting ( 
and caps: 0x%04x %s\n does not give a valid preprocessing token
/local0/scratch/des/src/contrib/smbfs/smbutil/dumptree.c:82:57: warning: pasting ( 
and maxmux:   %d\n does not give a valid preprocessing token
/local0/scratch/des/src/contrib/smbfs/smbutil/dumptree.c:83:57: warning: pasting ( 
and maxvcs:   %d\n does not give a valid preprocessing token
/local0/scratch/des/src/contrib/smbfs/smbutil/dumptree.c:91:46: warning: pasting ( 
and Share:%s does not give a valid preprocessing token
/local0/scratch/des/src/contrib/smbfs/smbutil/dumptree.c:98:50: warning: pasting ( 
and flags:0x%04x %s\n does not give a valid preprocessing token
/local0/scratch/des/src/contrib/smbfs/smbutil/dumptree.c:99:51: warning: pasting ( 
and usecount: %d\n does not give a valid preprocessing token
=== usr.bin/chkey
=== usr.bin/newkey
=== usr.sbin
=== usr.sbin/IPXrouted
=== usr.sbin/ac
=== usr.sbin/accton
=== usr.sbin/adduser
=== usr.sbin/amd
=== usr.sbin/amd/include
=== usr.sbin/amd/libamu
=== usr.sbin/amd/amd
=== usr.sbin/amd/amq
=== usr.sbin/amd/doc
=== usr.sbin/amd/fixmount
=== usr.sbin/amd/fsinfo
yacc: 2 shift/reduce conflicts
=== usr.sbin/amd/hlfsd
=== usr.sbin/amd/mk-amd-map
=== usr.sbin/amd/pawd
=== usr.sbin/amd/scripts
=== usr.sbin/amd/wire-test
=== usr.sbin/ancontrol
=== usr.sbin/arp
=== usr.sbin/atm
=== usr.sbin/atm/atmarpd
=== usr.sbin/atm/scspd
=== usr.sbin/bootparamd
=== usr.sbin/bootparamd/bootparamd
=== usr.sbin/bootparamd/callbootd
=== usr.sbin/burncd
=== usr.sbin/cdcontrol
=== usr.sbin/chkgrp
=== usr.sbin/chown
=== usr.sbin/chroot
=== usr.sbin/ckdist
=== usr.sbin/config
=== usr.sbin/cron
=== usr.sbin/cron/lib
=== usr.sbin/cron/cron
=== usr.sbin/cron/crontab
=== usr.sbin/crunch
=== usr.sbin/crunch/crunchgen
=== usr.sbin/crunch/crunchide
=== usr.sbin/ctm
=== usr.sbin/ctm/ctm
=== usr.sbin/ctm/ctm_rmail
=== usr.sbin/ctm/ctm_smail
=== usr.sbin/ctm/ctm_dequeue
=== usr.sbin/daemon
=== usr.sbin/dev_mkdb
=== usr.sbin/devinfo
=== usr.sbin/digictl
=== usr.sbin/edquota
=== usr.sbin/extattr
=== usr.sbin/extattrctl
=== usr.sbin/faithd
=== usr.sbin/fdcontrol
=== usr.sbin/fdformat
=== usr.sbin/fdread
=== usr.sbin/fdwrite
=== usr.sbin/fwcontrol
=== usr.sbin/getfmac
=== usr.sbin/getpmac
=== usr.sbin/ifmcstat
=== usr.sbin/inetd
=== usr.sbin/iostat
=== usr.sbin/jail
=== usr.sbin/kbdcontrol
=== usr.sbin/kbdmap
=== usr.sbin/kernbb
=== usr.sbin/kldxref
=== usr.sbin/lastlogin
=== usr.sbin/mailwrapper
=== usr.sbin/manctl
=== 

Re: [resolution] Re: sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay)

2003-01-03 Thread Gary W. Swearingen
Terry Lambert [EMAIL PROTECTED] writes:

 The book is pretty useless.  The reason the fix you are using
 works is because you have an IPv6 connection by default, and by
 explicitly specifying an IPv4 address, IPv4 is used.
 
 The issue here is the .in-addr.arpa. delegation for localhost
 is considered to be local.  When the getpeername() happens, it
 gets an IPv6 address instead of an IPv4, and the the gethostbyaddr()
 hangs looking for ::1.in-addr.arpa., but has no problem finding
 1.0.0.127.in-addr.arpa..

I guess you're saying IPv6 is a sendmail default and not a OS default;
ping localhost says it's pinging 127.0.0.1, not ::1.  I didn't see
much IPv6 stuff (like a default choice) in the README file,
unsuprisingly.  BTW, I was suprised to find several help files only
under /usr/src and the Sendmail Installation and Operation only under
that and not yet built from the source op.me.  (PR worthy?)

Why isn't ::1.in-addr.arpa. built into the resolver (or something)
like 1.0.0.127.in-addr.arpa. seems to be?  (Rhetorical question.)
 
 You can fix this by disabling the DNS cross-check in the file
 sendmail.cf, and by getting rid of the peer name lookup in the
 loopback case.  What you did with the IPv4 just took advanatage
 of the fact that the in-addr.arpa. IPv4 delegations existed, when
 the IPv6 loopback address ones did not.

Repairing sendmail config rot only once or twice a year, I can barely
deal with the .mc file; I try to stay out of the .cf file.  And in quite
a lot of reading, I've not run across cross-check or peer name
lookup or loopback case or delegations and would be unlikely to
determine the implementation of your spec if I had.  But don't bother
explaining; you have better things to do, I'm sure.  I sounds like you
have a better fix below anyway, and I'm happy with my kludge.  I do
think I get the gist of what you're saying about the DNS issues.
 
  Is there a quick way to disable IPv6?  While I figure that out or
  rebuild my kernel, I got a quick fix by changing, in my submit.mc,
  this
  FEATURE(`msp')
  to this
  FEATURE(`msp',`[127.0.0.1]')
 
 This isn't the correct fix.  The correct fix is to add an IPv6 address
 and in-addr.arap. delegation for the loopback in your local DNS.

My local DNS is the resolver and /etc/hosts with
::1 localhost localhost.localdomain
127.0.0.1   localhost localhost.localdomain
I'm not even caching.  Nowhere to do your fix (outside C code), AFAIK.

Would I have had this problem in 4.7 with the GENERIC kernel?  Should
the docs say that you must run at least a caching DNS server and say
that you must set up this ::1.in-addr.arpa. thing, in order to run
sendmail with the GENERIC (or any IPv6) kernel?

 As far as the HoldExpensive I recommended, the way you stated the
 problem seemed to indicate that it was a failure to connect, not
 a failure to validate a connection was going through.  In general,
 ou want to queue up any mail that can bring up a link, if your link
 is transiently connected, and then control the link with a seperate
 queue interval.  The other DNS statements I made were to ensure that
 the interface did not end up bouncing up when sendmail was started,
 for local mail delivery, or for remote mail delivery, outside the
 administratively controlled queueing intervals (which could be on
 the order of seconds, if you wanted).

Uh huh.  I gathered that from my reading, and maybe I'll try that sort
of queuing someday.  I'm off the net most of the time and have a gut
objection to a queue runner banging on a closed door so often and just
feel more comfortable with the simple do-it-now method.  But it would
be nice to be able to send mail while offline, I suppose.

Thanks for the info (both times), even if some of it went over my head.
:-)

-- 

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



Re: Jail detection

2003-01-03 Thread phk
In message [EMAIL PROTECTED], Ju
lian Elischer writes:

 Use sysctl to pick up your own proc, look for the jail flag.  It takes
 less than 10 lines of C.

I can't see anything relevant in sysctl -a. 

We don't return binary blobs from sysctl -a.

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

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