FreeBSD5.0 has the G-NIC(VI/IP) drivers?
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
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.
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.
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
-- >>> 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 ===> usr.sbin/ntp/ntpdc Version ===> usr.sbin/ntp/ntpq Version ===> usr.sbin/ntp/ntpdate Version ===> usr.sbin/ntp/ntptrace Version ===> usr.sbin/ntp/ntptimeset Version ===> 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 ===> usr.sbin/rip6query ===> usr.sbin/rmt ===> usr.sbin/route6d ===> usr.sbin/rpcbind ===> usr.sbin/rpc.lockd
Re: pcm0:play:0: play interrupt timeout, channel dead
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: 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
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
-- >>> 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.
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
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 = {
= {
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
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
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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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
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
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=0x383f9ff 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: random: mem: Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface acpi0: 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 4 5 6 7 9 10 11 12 14 15 embedded10A 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded07A 0x60 3 4 5 6 7 9 10 11 12 14 15 embe
current/stable remote gdb interoperability
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 ) at atomic.h:260 260 atomic.h: No such file or directory. in atomic.h (gdb) bt #0 Debugger (msg=0x19 ) 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
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
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
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.
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
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
> 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
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.
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
ia64 tinderbox failure
-- >>> 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
Re: buildworld trouble: multiple struct dos_partition.
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. is similarly OK and 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
% 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
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
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
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
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
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 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
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.
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.
>
> is similarly OK and 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
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
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
< 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
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
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.
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
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
-- >>> 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 ===> usr.sbin/ntp/ntpdc Version ===> usr.sbin/ntp/ntpq Version ===> usr.sbin/ntp/ntpdate Version ===> usr.sbin/ntp/ntptrace Version ===> usr.sbin/ntp/ntptimeset Version ===> 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 ===> usr.sbin/rip6query ===> usr.sbin/rmt ===> usr.sbin/route6d ===> usr.sbin/rpcbind ===> usr.sbin/rpc.lockd
Proper -current if_attach locking?
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
-- >>> 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...
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Ø^nr¡ûazg¬±¨
sshd fails with: fatal: ssh_msg_send: write
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 ...
> Good year everybody > > Luigi, I converted your patch to CURRENT, there were only > minor changes to do and it seems to work ! > > sis0: port 0x2000-0x20ff mem > 0xec005000-0xec005fff irq 1$ > at device 4.0 on pci0 > sis0: Ethernet address: 00:00:e2:94:66:99 > miibus0: on sis0 > ukphy0: 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
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)
(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)
"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
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
-- >>> 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
--
>>> 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.
Re: [resolution] Re: sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay)
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
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
