Re: How to force a kernel panic?
Mike Harding wrote: > ...so I can test my debugging kernel? If you just need a debugger breakpoint, rather than a panic, then try one of these: sysctl debug.enter_debugger=ddb sysctl debug.enter_debugger=gdb -Archie __ Archie Cobbs *Halloo Communications* http://www.halloo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw?
Guido van Rooij wrote: > > The problem is that while ESP packets arrive to be processed by > > IPsec just fine thru my ipfw rules, when the packets are de-encrypted > > and re-inserted into the kernel they appear to ipfw to be coming from > > my external interface (the one they arrived on via ESP). tcpdump can't > > find them (decrypted) on the external interface. I think the bug is that in esp4_input() the "detunneled" packet is placed back onto the IP input queue 'ipintrq' without the 'm->m_pkthdr.rcvif' being updated to point to the gif interface. -Archie __________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
stdio.h patch
Hi,
Does anyone object to the patch below? It fixes this warning when
compiling with -Wnested-externs and -D_THREAD_SAFE (am I the only
one who ever does that??)
/usr/include/stdio.h: In function `__getc_locked':
/usr/include/stdio.h:418: warning: nested extern declaration of `__isthreaded'
/usr/include/stdio.h: In function `__putc_locked':
/usr/include/stdio.h:430: warning: nested extern declaration of `__isthreaded'
The fix is to declare '__isthreaded' at the top level. My understanding
of things is that this should be OK because the name begins with two
underscores (but I could be wrong about that).
Also, it removes a bunch of backslash contiunations that are not needed.
FYI, this is not an issue in -current.
Thanks,
-Archie
______
Archie Cobbs * Packet Design * http://www.packetdesign.com
Index: stdio.h
===
RCS file: /home/ncvs/src/include/stdio.h,v
retrieving revision 1.24.2.2
diff -u -r1.24.2.2 stdio.h
--- stdio.h 5 Dec 2001 20:48:07 - 1.24.2.2
+++ stdio.h 22 Aug 2002 05:01:24 -
@@ -415,29 +415,28 @@
#else
#define _FLOCKFILE(x) flockfile(x)
#endif
-static __inline int\
-__getc_locked(FILE *_fp) \
-{ \
- extern int __isthreaded;\
- int _ret; \
- if (__isthreaded) \
- _FLOCKFILE(_fp);\
- _ret = getc_unlocked(_fp); \
- if (__isthreaded) \
- funlockfile(_fp); \
- return (_ret); \
+extern int __isthreaded;
+static __inline int
+__getc_locked(FILE *_fp)
+{
+ int _ret;
+ if (__isthreaded)
+ _FLOCKFILE(_fp);
+ _ret = getc_unlocked(_fp);
+ if (__isthreaded)
+ funlockfile(_fp);
+ return (_ret);
}
-static __inline int\
-__putc_locked(int _x, FILE *_fp) \
-{ \
- extern int __isthreaded;\
- int _ret; \
- if (__isthreaded) \
- _FLOCKFILE(_fp);\
- _ret = putc_unlocked(_x, _fp); \
- if (__isthreaded) \
- funlockfile(_fp); \
- return (_ret); \
+static __inline int
+__putc_locked(int _x, FILE *_fp)
+{
+ int _ret;
+ if (__isthreaded)
+ _FLOCKFILE(_fp);
+ _ret = putc_unlocked(_x, _fp);
+ if (__isthreaded)
+ funlockfile(_fp);
+ return (_ret);
}
#definegetc(fp)__getc_locked(fp)
#defineputc(x, fp) __putc_locked(x, fp)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: libc_r (-pthread) linking problem
Joe Marcus Clarke writes: > > I'm trying to link an application with a library (libpdel) that itself > > links against libc_r. However, the application fails to link: > > > > cc -O -pipe -D_THREAD_SAFE ... -pthread -o ... -L/usr/local/lib -lpdel -lexpat >-lssl -lcrypto -lcrypt > > lws_tmpl_misc.o: In function `lws_tf_crypt_hash': > > lws_tmpl_misc.o(.text+0x3c3): undefined reference to `__pthread_read' > > main.o: In function `main': > > main.o(.text+0x21c): undefined reference to `__pthread_sigwait' > > /usr/local/lib/libpdel.so: undefined reference to `pthread_yield_np' > > /usr/local/lib/libpdel.so: undefined reference to `__pthread_connect' > > /usr/local/lib/libpdel.so: undefined reference to `__pthread_accept' > > /usr/local/lib/libpdel.so: undefined reference to `__pthread_detach' > > /usr/local/lib/libpdel.so: undefined reference to `__pthread_poll' > > /usr/local/lib/libpdel.so: undefined reference to `__pthread_write' > > *** Error code 1 > > > > This is on FreeBSD 4.6-stable as of today. This works fine on FreeBSD 4.5. > > I think you need to recompile libpdel for -stable. This should fix your > problem. Those symbols don't even exist in -stable. I built libpdel on Ack! You're right.. must be brain-dead today.. libpdel hasn't been rebuilt since upgrading this particular machine to -stable. Thanks & sorry for the noise... -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
libc_r (-pthread) linking problem
Hi, I'm trying to link an application with a library (libpdel) that itself links against libc_r. However, the application fails to link: cc -O -pipe -D_THREAD_SAFE ... -pthread -o ... -L/usr/local/lib -lpdel -lexpat -lssl -lcrypto -lcrypt lws_tmpl_misc.o: In function `lws_tf_crypt_hash': lws_tmpl_misc.o(.text+0x3c3): undefined reference to `__pthread_read' main.o: In function `main': main.o(.text+0x21c): undefined reference to `__pthread_sigwait' /usr/local/lib/libpdel.so: undefined reference to `pthread_yield_np' /usr/local/lib/libpdel.so: undefined reference to `__pthread_connect' /usr/local/lib/libpdel.so: undefined reference to `__pthread_accept' /usr/local/lib/libpdel.so: undefined reference to `__pthread_detach' /usr/local/lib/libpdel.so: undefined reference to `__pthread_poll' /usr/local/lib/libpdel.so: undefined reference to `__pthread_write' *** Error code 1 This is on FreeBSD 4.6-stable as of today. This works fine on FreeBSD 4.5. FYI, none of my code ever calls pthread_yield_np(), so I don't know where that symbol is coming from. Any ideas what the problem is? Thanks, -Archie __________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: asr driver & INVARIANT & M_WAITOK
Fabien THOMAS writes: > the kernel crash with M_WAITOK in INVARIANT mode. > it seems that M_WAITOK is the problems is it possible to replace with > M_DONTWAIT ? Yes, as long as you check for a NULL return value (not normally possible with M_WAITOK). -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.5 and mpd "no buffer space available on high load" ??
Karl M. Joch writes:
> ->> when box 1 sends the file via cp command to box 2 (1 mounts 2 via
> nfs) after it is created i immedialy get "no bufferspace available" on
> every action box 1 does. the strange thing is, when letting the same
> file being picked up by box 2 (box2 mounting box1 via nfs and running
> the same cp command) it works just great.
The ENOBUFS error is probably coming from the ng_pptpgre(4) netgraph
node. When the PPTP transmit pipe overflows (can easily happen with
UDP packets such as with NFS) then you get this error. It can be safely
ignored (although the packet is still dropped).
Try the patch below and see if it helps any..
-Archie
______
Archie Cobbs * Packet Design * http://www.packetdesign.com
Index: ng_pptpgre.c
===
RCS file: /home/cvs/freebsd/src/sys/netgraph/ng_pptpgre.c,v
retrieving revision 1.2.2.9
diff -u -r1.2.2.9 ng_pptpgre.c
--- ng_pptpgre.c2001/04/21 20:43:13 1.2.2.9
+++ ng_pptpgre.c2002/05/17 05:13:56
@@ -483,7 +483,7 @@
>= a->xmitWin) {
priv->stats.xmitDrops++;
NG_FREE_DATA(m, meta);
- return (ENOBUFS);
+ return (0);
}
/* Sanity check frame length */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Bug in pthread_cancel()
Hi, Any comments positive or negative to the patch in bin/37614 ? I'd like to commit this soon... http://www.freebsd.org/cgi/query-pr.cgi?pr=37614 Thanks, -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: mpd-netgraph problem.
David Gilbert writes: > I'm using mpd-netgraph to attempt to connect an encrypted tunnel. It > appears to connect (according to the messages), but the following is > spit out for most packets I try to put down the tunnel: > > [vpn] LCP: rec'd Protocol Reject #1 link 0 (Opened) > [vpn] LCP: protocol 0x0029 was rejected > [vpn] LCP: rec'd Protocol Reject #2 link 0 (Opened) > [vpn] LCP: protocol 0x00a1 was rejected > > (on the one end) > > [strikeppp] rec'd unexpected protocol 0x0029 on link -1, rejecting > [strikeppp] rec'd unexpected protocol 0x00a1 on link -1, rejecting > [strikeppp] rec'd unexpected protocol 0x0001 on link -1, rejecting > > (on the other) > > The second log also contains lines of the form: > > [strikeppp] rec'd proto 0xee53 on MP link! (ignoring) > [strikeppp] rec'd proto 0xcc0d on MP link! (ignoring) > > ... any ideas? This is usually because one side is sending encrypted traffic that the other is thinking is not encrypted... i.e., it's a side-effect of a negotiation problem. I've just heard from another person with this problem. Check your logs for something like ``"enable chap" required for MPPE'' on one side. As a workaround, if you are doing CHAP in both directions, try turning it off in one direction. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: kernel panic when bringing up a VLAN interface (netgraph?)
Yar Tikhiy writes: > Why does gdb report the values of "ifp" and "mp" inconsistently? > The kernel crashed at the first line of ng_ether_output(), so > the arguments couldn't be modified... I'm confused. Optimization.. it's probably reusing the same variable/register for both 'ifp' and 'node'. So 'node' is NULL, which indicates that ether_ifattach() was probably never called on this interface. -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: kernel panic when bringing up a VLAN interface (netgraph?)
Mike Tancsa writes: > >>On a new machine I am trying to bring up a trunked port to my vlan > >>interface. This is with the most recent fxp patches and STABLE as of > >>this afternoon > > > >4.4-RC FreeBSD 4.4-RC #0: Mon Aug 27 16:46:47 EDT 2001 > > > >OK, here is a backtrace. If there is more info required, let me know. > > It seems something to do with netgraph. If I remove all of the netgraph > options from the kernel, I am ok. It appears the problem is that some ethernet interface has been created (presumably a VLAN interface), yet ether_ifattach() was never called.. so ng_ether crashes because there's no node associated with the interface (which there would be had ether_ifattach() been called). Maybe a VLAN expert can shed some light? -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Broken module loading and kernel dependencies
Boris Popov writes: > > I took a look through a whole bunch of kernel code (hoping to do a MFC on my > > own -STABLE machines), but it looks like the fix for this will involve much > > of the code to be updated to revs that include "First round implementation > > of a fine grain enhanced module to module version dependency system.", > > committed by peter. Sources that need to be updated include: > [skip] > > These changes are too intrusive (at least Peter don't let get 'em > into 4.3). In addition, -current handles modules in a different way. The > much more simple fix which doesn't break binary compatibility is attached. Great! What's the commit strategy for these? Would you mind submitting the patch as a followup to ports/21584? http://www.freebsd.org/cgi/query-pr.cgi?pr=21584 -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: mbuf leak? fxp?
Bosko Milekic writes: > NMBUFS accordingly. Chances are, if you are explicitly declaring > `NMBCLUSTERS ' in your kernel configuration file, that you are > actually lowering the number of clusters/mbufs that would otherwise be > allowed with your given `maxusers' value (unless you have an unreasonably > low maxusers). Mmm.. I don't understand that.. can you explain? -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Kernel Panic on 4.3-RC #0 using PPPoE
Archie Cobbs writes: > > I am receiving kernel panics under 4.3-RC #0 when trying to bring up PPPoE. > > A copy of the kernel debug, the start up and the actual PPP configuration are > > attached. It appears to be something in the subroutine called fxp_start of > > the actual ethernet card (Which is an Intel Express) trying to use a structure > > which has not yet been initialized. The machine is an SMP machine as well; > > although compiling without SMP support has so far made no difference. The > > problem also occurs under 4.2-RELEASE. Any help on the subject would be > > appreciated. > > I think that the interface has not yet been brought up (IFF_UP) > before the first packet is sent out of it. This can normally only > happen when using netgraph (or raw sockets I suppose)... the > fxp driver seems to assume that it will never see an output packet > without an IFF_UP first, which is no longer true. > > Also, ppp(8) should be setting IFF_UP on the interface before > trying to send out of it. > > Not sure why this hasn't been detected before though. Below is > a possible patch. Actually a better fix is probably to check for IFF_UP at the beginning of ether_output_frame()... -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: PPP/NAT/TCP Question
Sam Zamarripa writes: > I am using FreeBSD 4.2-BETA and PPP NAT to share a dialup connection on my > Lan. My question > is..certain TCP options such as MTU, Path MTU, RFC1323, etc..are they all > independant on the machines on the lan or are they all dependant on the NAT > machine? > > A specific example would be..if I wanted to set an MTU of 576. If I set the > MTU of 576 on a Windows machine but the FreeBSD box doing NAT is still MTU > 1500, is the windows machine using 576 or 1500 in that case? Not sure what you're asking. MTU's apply to network interfaces, such that packets larger than the MTU passing through the interface must be fragmented. If your internal Win98 machine has an MTU of 576, then it will be sending 576 bytes packets out, so the FreeBSD machine will not have to fragment them further. If it was the other way around, they would get fragmented. -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: PCCARD support
> : #1. First, here's a new entry for pccard.conf:
> :
> : # PreMax PE-200 Ethernet Card
> : card "PMX " "PE-200"
> : config auto "ed0" 11 0x10
> : ether 0x7f0
> : insert logger -t pccard:$device -s PREMAX PE-200 inserted
> : insert /etc/pccard_ether $device
> : remove logger -t pccard:$device -s PREMAX PE-200 removed
> : remove /sbin/ifconfig $device delete
>
> OK. I'll add this.
Thanks..
> : Of course, now that the card works again I can see that this is
> : already fixed in -current, pccardd/util.c rev. 1.14.
> :
> : Would someone care to MFC please?
>
> iwasaki-san has plans to MFC it in early June. Both Jordan and I
> approved the changes (he specifically asked us before doing the MFC),
> so he will do it when he has the chance, I think by June 15th IIRC.
OK.. just wanted to make sure it didn't get forgotten.
> : #3. My USR modem card used to work with PAO. Now when I try to talk
> : to it (using 'tip') the laptop completely freezes.. such that
> : only a power cycle wakes it up. Here are the messages that appear:
> :
> : pccardd[66]: Card "U.S. Robotics"("XJ/CC1336") matched "U.S. Robotics"
>("XJ/CC1336")
> : pccardd[66]: Assign sio1, io 0x2f8-0x2ff, mem 0x0, 0 bytes, irq 3, flags 0
> : /kernel: sio1 at port 0x2f8-0x2ff irq 3 slot 1 on pccard1
> : /kernel: sio1: type 8250
> : pccard:sio1: U.S. Robotics XJ/CC1336 inserted
>
> This is odd. You might add 'reset 1000' to the entry and see if that
> helps. This is a 33.6 Modem, yes? I have the 14.4 version as well as
> the 28.8 version and those work w/o a hitch for me. Well, they work
> for me in the pccard adapater on the passive isa backplane on my
> testbox at work to dial into my machines at home and kick them when
> they are being bad, but that setup has been a realiable indication of
> potential problems...
Another person suggested adding 'reset 1000' and options PNPBIOS.
That seemed to make it work, though not sure which.
By the way, 'reset 1000' is not documented in pccard.conf(5)..
Thanks,
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
PCCARD support
Some of this may be old news, but I just thought I'd report my experiences
upgrading my laptop to 4.0-stable yesterday.
#1. First, here's a new entry for pccard.conf:
# PreMax PE-200 Ethernet Card
card "PMX " "PE-200"
config auto "ed0" 11 0x10
ether 0x7f0
insert logger -t pccard:$device -s PREMAX PE-200 inserted
insert /etc/pccard_ether $device
remove logger -t pccard:$device -s PREMAX PE-200 removed
remove /sbin/ifconfig $device delete
#2. This card requires a 1024 memory block, but a bug in pccardd causes
the allocation to always fail...
Of course, now that the card works again I can see that this is
already fixed in -current, pccardd/util.c rev. 1.14.
Would someone care to MFC please?
#3. My USR modem card used to work with PAO. Now when I try to talk
to it (using 'tip') the laptop completely freezes.. such that
only a power cycle wakes it up. Here are the messages that appear:
pccardd[66]: Card "U.S. Robotics"("XJ/CC1336") matched "U.S. Robotics"
("XJ/CC1336")
pccardd[66]: Assign sio1, io 0x2f8-0x2ff, mem 0x0, 0 bytes, irq 3, flags 0
/kernel: sio1 at port 0x2f8-0x2ff irq 3 slot 1 on pccard1
/kernel: sio1: type 8250
pccard:sio1: U.S. Robotics XJ/CC1336 inserted
Thanks,
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Help: interrupt timeout
My laptop running 3.4-RELEASE decided it doesn't want to boot. It was uncleanly shut down via the power switch by someone who thought they were shutting down a different machine. Now when it boots, running fsck gives this result: > chip0: rev 0x01 on pci0.0.0 > chip1: rev 0x02 on pci0.7.0 > ide_pci0: rev 0x01 on pci0.7.1 > ... > wdc0 at 0x1f0-0x3f7 irq 14 on isa > wdc0: unit 0 (wd0): > wd0: 6194MB (12685680 sectors), 13424 cyls, 15 heads, 63 S/T 512 B/S > wdc1 at 0x170-0x177 irq 15 on isa > wdc1: unit 0 (atapi): , removable, accel, dma, iordis > ... > # fsck / > *** /dev/rwd0s3a > *** Last Mounted on / > *** Root file system > *** Phase 1 - Check Blocks and Sizes > wd0: interrupt timeout (status 58 error 0) > wd0: wdtimeout DMA status 4 > wd0: interrupt timeout (status 50 error 1) > wd0: wdtimeout DMA status 4 > wd0: interrupt timeout (status 50 error 1) > wd0: wdtimeout DMA status 4 > wd0: interrupt timeout (status 50 error 1) > wd0: wdtimeout DMA status 4 > wd0: interrupt timeout (status 50 error 1) > wd0: wdtimeout DMA status 4 > wd0: Last time I say: interrupt timeout. Probably a portable PC. (status >50 error 1) Well, yes in fact it is a portable PC :-) It just seems to hang at this point, even though there seems to be disk activity (like it's continuously retrying). This machine has run fine under this kernel since I installed 3.4-REL a month ago or so. This same problem happens with the 3.4-REL GENERIC kernel. Before this, it was running fine with a 3.0++ kernel and never had this problem after many power cycles. Is there any hope in getting this machine to work again?? Howabout disabling DMA? Is there some way to do that? Thanks for any pointers.. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
