Re: ssh not working after upgrading OS?
You are probably using a -CURRENT with a broken randomness device. For more information you can try and search the mailing list archives. No - he has _no_ randomness device. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fetch http://cgi returns -1 size
My current box (make world'ed this morning) fails on fetch(1) for some CGI scripts. % fetch -v -v http://www.FreeBSD.org/cgi/search.cgi/ looking up www.FreeBSD.org connecting to www.FreeBSD.org:80 requesting http://www.FreeBSD.org:80/cgi/search.cgi/ looking up www.FreeBSD.org connecting to www.FreeBSD.org:80 requesting http://www.FreeBSD.org:80/cgi/search.cgi/ Receiving fetch.out -1 bytes transferred in 0.0 seconds (-129.18 Bps) % fetch -v -v http://www.jp.FreeBSD.org/cgi/cvsweb.cgi/ looking up www.jp.FreeBSD.org connecting to www.jp.FreeBSD.org:80 requesting http://www.jp.FreeBSD.org:80/cgi/cvsweb.cgi/ looking up www.jp.FreeBSD.org connecting to www.jp.FreeBSD.org:80 requesting http://www.jp.FreeBSD.org:80/cgi/cvsweb.cgi/ Receiving fetch.out -1 bytes transferred in 0.3 seconds (-3.94 Bps) -- Jun Kuriyama [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fetch http://cgi returns -1 size
Jun Kuriyama [EMAIL PROTECTED] writes: My current box (make world'ed this morning) fails on fetch(1) for some CGI scripts. The bug is only in the status report, check the acutal size of fetch.out. I fixed this in a commit half an hour ago. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: etc/rc.d things...
Cyrille Lefevre wrote: Non-centralized configuration is frowned upon. Having to find which file has something, or having to read through multiple files to understand how the system is configured is a disadvantage wrt to the present system. not so difficult if a command do that for you. (show, change, start and stop) Commands limit you in awkward ways. Hell, AIX has commands to do anything with the configuration you might want, but that has not prevented people from hating it... :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] jkh _DES: The Book of Bruce has only one sentence in it, and it says "the actual directives of my cult are left as an exercise for the reader. Good luck." EE jkh: does it really include the 'good luck' part? jkh EE: OK, I made that part up. jkh EE: I figured it should sound a bit more cheery than how Bruce initially dictated it to me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
**HEADS UP** if you used to cvsup the crypto repo from internat !
I haven't looked into it too deeply yet because of other source tree problems, but if you used to get your crypto ,v files from internat, you will suffer some funny problems unless you nuke the old checked-out files. My apologies if this is old news, but I see nothing in UPDATING. The problem occurs when you cvsup the new crypto-in-src-all sources and replace RCS files with different contents and the same version number. cvs update/checkout compares the repo version number against the checked out version number and considers the file an ``M'' (modified source). The file isn't updated and your world gets corrupted. This is probably a candidate for UPDATING. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ppp-related panic in sbdrop()
I'd like to disclaim all responsibility :-I
I'd normally try to figure out what the problem is or ask for more
info, but seen as ppp caused a kernel panic on me this morning on the
train, and since then cvsup has caused a similar panic, htc panics
and just about anything else interesting I do panics, I tend to
suspect it's nothing to do with (user-land) ppp
I'm trying to rebuild my machine by cvs update -D'ing to before the
snapshot code commit at the moment
Hi,
I've finally managed to capture a crashdump after a panic in sbdrop(). The
machine in question uses ppp/ipfw/natd to connect a small LAN to the
outside world via a DSL link. ppp started to misbehave: NS queries were
sent out but didn't come back (I had tcpdumps running on both tun0 and
ed1). I tried to terminate ppp by sending a SIGTERM. ppp (pid 78) was
still around after a minute, so I send a SIGTERM. The machine crashed
immediately.
The machine world as of 7/7, I've only added the latest type fix to
ppp/bundle.c (rev 1.99).
The point of doom:
bash# gdb -k /sys/compile/UE/kernel.debug /var/crash/vmcore.0
GNU gdb 4.18
Copyright 1998 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-freebsd"...
IdlePTD 3952640
initial pcb at 325320
panicstr: sbdrop
panic messages:
---
panic: sbdrop
syncing disks...
done
Uptime: 1h4m5s
dumping to dev #da/0x20001, offset 190228
dump 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39
38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11
10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:303
303 dumppcb.pcb_cr3 = rcr3();
(kgdb) wwhheerree
#0 boot (howto=256) at ../../kern/kern_shutdown.c:303
#1 0xc01717f4 in poweroff_wait (junk=0xc02b3a26, howto=-946356848)
at ../../kern/kern_shutdown.c:553
#2 0xc01931c8 in sbdrop (sb=0xc797bd90, len=158)
at ../../kern/uipc_socket2.c:793
#3 0xc0193058 in sbflush (sb=0xc797bd90) at ../../kern/uipc_socket2.c:772
#4 0xc0192b11 in sbrelease (sb=0xc797bd90, so=0xc6d59b40)
at ../../kern/uipc_socket2.c:455
#5 0xc0191443 in sorflush (so=0xc6d59b40) at ../../kern/uipc_socket.c:988
#6 0xc01900ad in sofree (so=0xc6d59b40) at ../../kern/uipc_socket.c:262
#7 0xc01901de in soclose (so=0xc6d59b40) at ../../kern/uipc_socket.c:327
#8 0xc018553a in soo_close (fp=0xc0f8fe40, p=0xc74b32a0)
at ../../kern/sys_socket.c:193
#9 0xc0166165 in fdrop (fp=0xc0f8fe40, p=0xc74b32a0) at ../../sys/file.h:212
#10 0xc01660ab in closef (fp=0xc0f8fe40, p=0xc74b32a0)
at ../../kern/kern_descrip.c:1079
#11 0xc0165dfc in fdfree (p=0xc74b32a0) at ../../kern/kern_descrip.c:945
#12 0xc016854d in exit1 (p=0xc74b32a0, rv=9) at ../../kern/kern_exit.c:186
#13 0xc01732d2 in sigexit (p=0xc74b32a0, sig=9) at ../../kern/kern_sig.c:1499
#14 0xc017304c in postsig (sig=9) at ../../kern/kern_sig.c:1402
#15 0xc028e6f0 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077940036, tf_esi = 134920284, tf_ebp = -1077940004,
tf_isp = -946356268, tf_ebx = 672838652, tf_edx = 134909952,
tf_ecx = 2048, tf_eax = 29, tf_trapno = 7, tf_err = 2,
tf_eip = 673074366, tf_cs = 31, tf_eflags = 647, tf_esp = -1077940096,
tf_ss = 47}) at ../../i386/i386/trap.c:164
#16 0xc02838f5 in Xint0x80_syscall ()
#17 0x80781c6 in ?? ()
#18 0x806eaa9 in ?? ()
#19 0x806e1fb in ?? ()
#20 0x8078778 in ?? ()
#21 0x805996f in ?? ()
#22 0x804ccd8 in ?? ()
#23 0x806a776 in ?? ()
#24 0x806a35f in ?? ()
#25 0x804b0a1 in ?? ()
(kgdb) frame 2
#2 0xc01931c8 in sbdrop (sb=0xc797bd90, len=158)
at ../../kern/uipc_socket2.c:793
793 panic("sbdrop");
(kgdb) print sb
$1 = (struct sockbuf *) 0xc797bd90
(kgdb) print *sb
$2 = {sb_cc = 158, sb_hiwat = 20480, sb_mbcnt = 512, sb_mbmax = 163840,
sb_lowat = 1, sb_mb = 0x0, sb_sel = {si_pid = 0, si_note = {
slh_first = 0x0}, si_flags = 0}, sb_flags = 64, sb_timeo = 0}
(kgdb) print len
$3 = 158
(kgdb) print m
$4 = (struct mbuf *) 0xc02b3a26
(kgdb) print *m
$5 = {m_hdr = {mh_next = 0x72646273, mh_nextpkt = 0x4e00706f,
mh_data = 0x63706900 Address 0x63706900 out of bounds,
mh_len = -1377828864, mh_type = -16336, mh_flags = 73}, M_dat = {MH = {
MH_pkthdr = {rcvif = 0x6d6d7564, len = -1373634439,
header = 0x616dc030 Address 0x616dc030 out of bounds,
csum_flags = 1668248440, csum_data = 1718968939, aux = 0xae60},
MH_dat = {MH_ext = {
ext_buf = 0x616dc030 Address 0x616dc030 out of bounds,
ext_free = 0x636f7378, ext_size = 1937007979, ext_ref =
Re: ppp -auto gone again
Udo Erdelhoff schrieb: Hi, ppp -auto stopped working fater I've updated my box from 06/17-Sources to yesterday's version (07/06, approx. 1500 GMT). tcpdump -ni tun0 shows the traffic but that's it. ppp.log doesn't show any obvious problems. -ddial works, sending a manual dial command (via pppctl) brings the link up immediately. IPv6-related breakage again (this is an IPv4-only system) or something new? Found it. Index: bundle.c === RCS file: /data/cvs/src/usr.sbin/ppp/bundle.c,v retrieving revision 1.98 diff -u -r1.98 bundle.c --- bundle.c2000/07/07 14:22:07 1.98 +++ bundle.c2000/07/09 15:56:52 @@ -592,7 +592,7 @@ * *not* be UP and we can't receive data */ pri = PacketCheck(bundle, tun.data, n, bundle-filter.dial, NULL); - if (pri 0) + if (pri = 0) bundle_Open(bundle, NULL, PHYS_AUTO, 0); else /* Sorry... my mistake :-( -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: **HEADS UP** if you used to cvsup the crypto repo from internat !
My apologies if this is old news, but I see nothing in UPDATING. I sent it to ctm-announce... M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh not working after upgrading OS?
suggestion /dev/random now has good entropy collection (from the keyboard and sysmouse drivers). Please ensure that either `options RANDOMDEV' is present in your kernel config file or that `randomdev_load="YES"' is in your /boot/loader.conf. If you do not have the /dev/random driver, OpenSSL (and consequently lots of crypto tools (like SSH)) will fail with strange errors. /suggestion Thanks! -- Mark Murray It works! Thanks for your help! sam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Burned by config changes?
What optimizations did you use when compiling your kernel? (COPTFLAGS) If it's anything more than -O -pipe, then that may very well be your problem. -Dan On Tue, Jul 11, 2000 at 09:28:44PM -0400, Patrick Gardella wrote: I've somehow been burned by the config changes when I build world yesterday. The build went fine, and then I followed the instructions on: http://people.freebsd.org/~imp/config-upd.html But when I rebooted, it freezes right when I type "boot". Typing "boot -v" does not reveal anything more. I've gone in with an old kernel which lets me boot, and tried building a new GENERIC one, with no luck. It freezes at the same place. I have in place my /boot/device.hints, and it looks right. Any pointers to get the system back up and running? (I do have a backup, but I'd rather learn how to fix this!) Patrick Gardella To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
CFR: pccard.conf entries from PAO (130 entries!)
Hi, We, PAO folks in Japan, have prepared the patch for etc/defaults/pccard.conf CURRENT (rev. 1.121) merging more that one hundred of PCCard entries from PAO3. We'd be happy if we could use various cards on the installation. http://people.freebsd.org/~iwasaki/pccard/pccard.conf-MFPAO We'd like you to test them and see if there are any problems on the patch. Of course, You could test on STABLE system bringing etc/defaults/pccard.conf from CURRENT and replace with it. Because of too many entries to be added, please report your problems only to [EMAIL PROTECTED] and [EMAIL PROTECTED] - We are not sure that the card would be supported which has cardio line and just replaced with iosize line or other reasons. Those are marked as # XXX NOT SURE SUPPORTED and disabled. If you have this kind of cards, please enable the entry and test it. IBM Portable 4X Speed CD-ROM Drive CD-400 IBM CD-20XSeries(IDE PC Card) CitiDISK Addonics PocketZIP SONY Memory Stick PC Card Adaptor Xircom CompactCard Ethernet 10 (CFE-10) TDK Multifunctioon Card (as Modem) Toshiba Modem/LAN card IPC5001B Toshiba 10/100 Ethernet PC Card IPC5008A - We are sure that some kind of cards wouldn't be supported and marked as # XXX NOT SUPPORTED YET and disabled because of driver porting issue. But we could be wrong, so please check them. cnw, fe, gp, hss, joy, ncv, nsp, opl, scc, stg and wlp drivers - Please test other kind of generic cards which use ata, ed, ep, sio, sn and xe drivers if you have. We're not sure whether card would work correctly if the entry has ether line. We are going to MFC this patch with following schedule. We would very much appreciate your cooperations. 7/13nomads, current ML review 7/16CURRENT commit 7/19MFC 7/20RELENG_4 freeze Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh not working after upgrading OS?
John Galt wrote: On Wed, 12 Jul 2000, Mark Murray wrote: You are probably using a -CURRENT with a broken randomness device. For more information you can try and search the mailing list archives. No - he has _no_ randomness device. Isn't there an add-on daemon for that, ESD or somesuch? The OpenSSL docs mention it. Yes and no. That daemon is a 'hack' for systems that lack a randomness device. You don't want to use it when you do have a good /dev/random. FreeBSD has a /dev/random except that it has been broken for a while whilst MarkM brought it up to snuff. The mailing list archives ought to contain all of the details one needs to fix this temporary problem. No need to resort to EGD, just tweak some config. Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _ \_ _(_) (_)/_\_| \ _|/' \/ (_)(_) (_)(_) (_)(_)' _\o_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic in sbdrop(), propably not ppp-related
On Wed, Jul 12, 2000 at 02:50:45PM +0100, Brian Somers wrote: I'd like to disclaim all responsibility :-I I'm almost convinced you're innocent. I've managed to restabilize my system by replacing "set device PPPoE:ed1" with "set device /dev/cuaa2". I've been pumping data through ppp for about 10 hours now and everything is perfect. And yes, the sbdrop panic also happens if /etc/malloc.conf is a symbolic link to aj. /s/Udo -- He who findeth sensuous pleasures in the bodies of lush, hot, pink damsels is not righteous, but he can have a lot more fun. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons hangs with -current
I'm afraid I don't quite understand how that desribes the fix to my problem (Freezing on boot after having probed a non-existant vga1 and sc1). What I did do, I went into sys/dev/fb/vga.c and commented out the second vga head detection. Works beautifully now, though it would be better to actually figure out why it was finding another vga card. Still, it's up and running. Now, if I could just figure out why ppp doesn't work (keeps complaining about "tun0: Warning: Add route failed: 0.0.0.0: errno: Network is unreachable", dials, and then sits and does nothing.) On Mon, 10 Jul 2000 10:39:44 MST, Eric Anholt wrote: Nope, same old device sc 1. I've tried unmodified GENERIC, and it does the same thing. Why am I special? I believe that the attached commit message describes the fix to the problem. However, I'd recommend going all the way to rev 1.10 or whatever the latest is by the time you get this mail. :-) Ciao, Sheldon. green 2000/07/10 23:47:38 PDT Modified files: sys/dev/randomdevyarrow.c Log: One should never allocate 4-kilobyte structs and such on the interrupt stack. It's bad for your machine's health. Make the two huge structs in reseed() static to prevent crashes. This is the bug that people have been running into and panic()ing on for the past few days. Reviewed by:phk Revision ChangesPath 1.8 +7 -3 src/sys/dev/randomdev/yarrow.c -- -- Eric Anholt [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CFR: pccard.conf entries from PAO (130 entries!)
In message [EMAIL PROTECTED] Mitsuru IWASAKI writes: : Xircom CompactCard Ethernet 10 (CFE-10) The entry for this that I just committed works great for me :-) : - We are sure that some kind of cards wouldn't be supported and marked as :# XXX NOT SUPPORTED YET :and disabled because of driver porting issue. But we could be wrong, :so please check them. :cnw, fe, gp, hss, joy, ncv, nsp, opl, scc, stg and wlp drivers fe doesn't work w/o iwasaki-san's patches. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh not working after upgrading OS?
Isn't there an add-on daemon for that, ESD or somesuch? The OpenSSL docs mention it. On Wed, 12 Jul 2000, Mark Murray wrote: You are probably using a -CURRENT with a broken randomness device. For more information you can try and search the mailing list archives. No - he has _no_ randomness device. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- There is an old saying that if a million monkeys typed on a million keyboards for a million years, eventually all the works of Shakespeare would be produced. Now, thanks to Usenet, we know this is not true. Who is John Galt? [EMAIL PROTECTED], that's who! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: **HEADS UP** if you used to cvsup the crypto repo from internat !
In article [EMAIL PROTECTED], Brian Somers [EMAIL PROTECTED] wrote: I haven't looked into it too deeply yet because of other source tree problems, but if you used to get your crypto ,v files from internat, you will suffer some funny problems unless you nuke the old checked-out files. [...] The problem occurs when you cvsup the new crypto-in-src-all sources and replace RCS files with different contents and the same version number. cvs update/checkout compares the repo version number against the checked out version number and considers the file an ``M'' (modified source). The file isn't updated and your world gets corrupted. One thing I'd like to stress is that this only affects you if you're getting the CVS files (*,v) and then using the cvs command to check them out and/or update them. If you are using CVSup in checkout mode (*default tag=something) then you don't need to do anything special. This is probably a candidate for UPDATING. That wouldn't hurt. But it actually affects _all_ branches, I believe. So in a way, UPDATING doesn't cover enough ground. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
unaligned access fault panic during boot?
Using a freshly supped -current source tree (2 hours ago) I'm getting a panic on boot: trap entry = 0x4 (unaligned access fault) a0 = 0xfc590a33 a1 = 0x2c a2 = 0x2 pc = 0xfc3a970c ra = 0xfc3a96b8 curproc = 0 This is a Miata GL 600ua. Anybody else seeing this ? I had hoped to build a release overnight to (hopefully) be able to test Lynx support. Wilko -- Wilko Bulte http://www.freebsd.org "Do, or do not. There is no try" [EMAIL PROTECTED] http://www.nlfug.nl Yoda - The Empire Strikes Back To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cvsup deadlock and ssh error
After cvsupping around 1:00 GMT and making world, I got this when doing
cvsup again:
Parsing supfile "/root/standard-supfile"
Connecting to cvsup.dk.FreeBSD.org
***
idThread.T closure rootA* waiting for
2 0x8388400 0x8388740 MeterMaid condition 0x8385778
1 0x8368004 0x0 *main program* A I/O
4 0x838851c 0x8388874 Watchercondition 0x8385f6c
3 0x838874c 0x83889d4 VFontCleanUpThread condition 0x8385d0c
***
***
*** runtime error:
***Deadlock !
***
-- EXCEPTION HANDLER STACK -
0x83be784 RAISES {Thread.Alerted}
0x83be7c0 TRY-FINALLY proc = 0x81e6c70 frame = 0x83be7d0
0x83be7e8 RAISES {}
0x83be820 LOCK mutex = 0x8385768
Also ssh gives this message in /var/log/messages
Jul 13 07:24:50 gina sshd[233]: error: select: Operation not supported by device
Jul 13 07:24:50 gina last message repeated 41 times
Jul 13 07:24:51 gina sshd[233]: error: select: No buffer space available
Jul 13 07:24:52 gina last message repeated 140 times
Leif
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
