Re: if_de as a module...
Any file called opt_*.h that is not present is created (empty). ...except the removed opt_*.h are not empty; hence the added headers in my patch. 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: if_de as a module...
On Mon, 10 Jul 2000, Nick Hibma wrote: The opt_ files can be generated by the makefiles, so there is no reason to remove those, see sys/modules/usb/Makefile SRCS = bus_if.h device_if.h usb_if.h usb_if.c \ vnode_if.h \ opt_usb.h \ ... Any file called opt_*.h that is not present is created (empty). The opt_ files are used includes, so removing them breaks certain functionality in both the statically compiled version and the module. Empty ones for the module only break this functionality for the module. Modules shouldn't depend on options. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
if_de as a module...
Hi Bill If I apply the enclosed patch to sys/pci/if_de.c, and make a copy of (say) sys/modules/dc to sys/modules/de (while changing all relevant dc -- de), I can build a loadable module for de. Could you please check that this works in your (no doubt) excellent laboratory and either commit or review for me to commit. Thanks! :-) M Index: sys/pci/if_de.c === RCS file: /home/ncvs/src/sys/pci/if_de.c,v retrieving revision 1.129 diff -u -d -r1.129 if_de.c --- sys/pci/if_de.c2000/05/28 16:06:56 1.129 +++ sys/pci/if_de.c 2000/07/09 08:27:09 @@ -54,10 +54,9 @@ #include sys/bus.h #include sys/rman.h -#include "opt_inet.h" -#include "opt_ipx.h" - #include net/if.h +#include net/if_arp.h +#include net/ethernet.h #include net/if_media.h #include net/if_dl.h #ifdef TULIP_USE_SOFTINTR To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_de as a module...
*I'll* check it too- I'd *love* to have if_de as a loadable since most of the alphas I have use if_de (not dc)! On Mon, 10 Jul 2000, Mark Murray wrote: Hi Bill If I apply the enclosed patch to sys/pci/if_de.c, and make a copy of (say) sys/modules/dc to sys/modules/de (while changing all relevant dc -- de), I can build a loadable module for de. Could you please check that this works in your (no doubt) excellent laboratory and either commit or review for me to commit. Thanks! :-) M Index: sys/pci/if_de.c === RCS file: /home/ncvs/src/sys/pci/if_de.c,v retrieving revision 1.129 diff -u -d -r1.129 if_de.c --- sys/pci/if_de.c 2000/05/28 16:06:56 1.129 +++ sys/pci/if_de.c 2000/07/09 08:27:09 @@ -54,10 +54,9 @@ #include sys/bus.h #include sys/rman.h -#include "opt_inet.h" -#include "opt_ipx.h" - #include net/if.h +#include net/if_arp.h +#include net/ethernet.h #include net/if_media.h #include net/if_dl.h #ifdef TULIP_USE_SOFTINTR 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
Re: if_de as a module...
*I'll* check it too- I'd *love* to have if_de as a loadable since most of the alphas I have use if_de (not dc)! Umm- started okay: de0: Digital 21140A Fast Ethernet port 0x10300-0x1037f mem 0x82083000-0x8208307f irq 3 at device 9.0 on pci0 de0: interrupting at CIA irq 3 de0: 21140A [10-100Mb/s] pass 2.2 de0: address 00:40:05:41:5b:e6 bpf: de0 attached de0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 192.67.166.23 netmask 0xff00 broadcast 192.67.166.255 ether 00:40:05:41:5b:e6 media: autoselect supported media: autoselect 100baseTX full-duplex 100baseTX 10baseT/UTP full-duplex 10baseT/UTP lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00 add net default: gateway 192.67.166.1 Additional routing options: tcp arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt extensions=NO IP gateway=YES TCP keepalive=YES. routing daemons:. ... but then failed with: arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt and then died: rplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt NFS Portmap: RPC: Port mapper failure - RPC: Timed out fatal kernel trap: trap entry = 0x2 (memory management fault) a0 = 0x0 a1 = 0x1 a2 = 0x pc = 0x0 ra = 0xfc4cb4e0 curproc= 0 ddbprinttrap from 0x0 ddbprinttrap(0x0, 0x1, 0x, 0x2) panic: trap panic Stopped at Debugger+0x2c: ldq ra,0(sp) 0xfe0009805a00 ra=0xfc4d0ca0,sp=0xfe0009805a00 db t Debugger() at Debugger+0x2c panic() at panic+0x100 trap() at trap+0x630 XentMM() at XentMM+0x20 swi_net() at swi_net+0x40 (null)() at 0x1 --- *sigh* (whimper) On Mon, 10 Jul 2000, Mark Murray wrote: Hi Bill If I apply the enclosed patch to sys/pci/if_de.c, and make a copy of (say) sys/modules/dc to sys/modules/de (while changing all relevant dc -- de), I can build a loadable module for de. Could you please check that this works in your (no doubt) excellent laboratory and either commit or review for me to commit. Thanks! :-) M Index: sys/pci/if_de.c === RCS file: /home/ncvs/src/sys/pci/if_de.c,v retrieving revision 1.129 diff -u -d -r1.129 if_de.c --- sys/pci/if_de.c2000/05/28 16:06:56 1.129 +++ sys/pci/if_de.c 2000/07/09 08:27:09 @@ -54,10 +54,9 @@ #include sys/bus.h #include sys/rman.h -#include "opt_inet.h" -#include "opt_ipx.h" - #include net/if.h +#include net/if_arp.h +#include net/ethernet.h #include net/if_media.h #include net/if_dl.h #ifdef TULIP_USE_SOFTINTR 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_de as a module...
Umm- started okay: : and then died: rplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt NFS Portmap: RPC: Port mapper failure - RPC: Timed out Bleagh. Fooey. :-( Biiilll!!?? :-) 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: if_de as a module...
The opt_ files can be generated by the makefiles, so there is no reason to remove those, see sys/modules/usb/Makefile SRCS = bus_if.h device_if.h usb_if.h usb_if.c \ vnode_if.h \ opt_usb.h \ ... Any file called opt_*.h that is not present is created (empty). Nick *I'll* check it too- I'd *love* to have if_de as a loadable since most of the alphas I have use if_de (not dc)! On Mon, 10 Jul 2000, Mark Murray wrote: Hi Bill If I apply the enclosed patch to sys/pci/if_de.c, and make a copy of (say) sys/modules/dc to sys/modules/de (while changing all relevant dc -- de), I can build a loadable module for de. Could you please check that this works in your (no doubt) excellent laboratory and either commit or review for me to commit. Thanks! :-) M Index: sys/pci/if_de.c === RCS file: /home/ncvs/src/sys/pci/if_de.c,v retrieving revision 1.129 diff -u -d -r1.129 if_de.c --- sys/pci/if_de.c2000/05/28 16:06:56 1.129 +++ sys/pci/if_de.c 2000/07/09 08:27:09 @@ -54,10 +54,9 @@ #include sys/bus.h #include sys/rman.h -#include "opt_inet.h" -#include "opt_ipx.h" - #include net/if.h +#include net/if_arp.h +#include net/ethernet.h #include net/if_media.h #include net/if_dl.h #ifdef TULIP_USE_SOFTINTR 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 -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_de as a module...
Umm- started okay: : and then died: rplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt NFS Portmap: RPC: Port mapper failure - RPC: Timed out Bleagh. Fooey. :-( Biiilll!!?? :-) I don't think this is Bill. What does the output of netstat -rn | grep 192.67.166.155 look like when the above is occuring? I am having similiar problems here, I just upgraded one of our main boarder routers and started getting this stuff. Is what is happening is a host specific route is getting installed by gated, and this is causing arplookup/arpresolve to have problems when it tries to go create the llinfo. We just upgraded this router from 3.4-stable of January vintage to 4.0-STABLE FreeBSD July 2 vintage. I have seen this in the past, and though it was long gone, but now that I am looking at it again I see what is happening, The message we get is the same as yours: Jul 9 17:37:02 br1 /kernel: arplookup 205.238.40.30 failed: could not allocate llinfo Jul 9 17:37:02 br1 /kernel: arpresolve: can't allocate llinfo for 205.238.40.30 rt Now if I look in my routing table when this is going on (sorry don't have it saved off anyplace I can cut and paste from right now) I see a host route out another interface!!! Yes, we have a large ospf network, yes that route will work, no it is not the right route damn it, there is a direct route via an interface, and we are trying to use it, but something is blowing chunks in rtalloc1. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_de as a module...
This doesn't happen for me except in this (loadable de) case. On Mon, 10 Jul 2000, Rodney W. Grimes wrote: Umm- started okay: : and then died: rplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt NFS Portmap: RPC: Port mapper failure - RPC: Timed out Bleagh. Fooey. :-( Biiilll!!?? :-) I don't think this is Bill. What does the output of netstat -rn | grep 192.67.166.155 look like when the above is occuring? I am having similiar problems here, I just upgraded one of our main boarder routers and started getting this stuff. Is what is happening is a host specific route is getting installed by gated, and this is causing arplookup/arpresolve to have problems when it tries to go create the llinfo. We just upgraded this router from 3.4-stable of January vintage to 4.0-STABLE FreeBSD July 2 vintage. I have seen this in the past, and though it was long gone, but now that I am looking at it again I see what is happening, The message we get is the same as yours: Jul 9 17:37:02 br1 /kernel: arplookup 205.238.40.30 failed: could not allocate llinfo Jul 9 17:37:02 br1 /kernel: arpresolve: can't allocate llinfo for 205.238.40.30 rt Now if I look in my routing table when this is going on (sorry don't have it saved off anyplace I can cut and paste from right now) I see a host route out another interface!!! Yes, we have a large ospf network, yes that route will work, no it is not the right route damn it, there is a direct route via an interface, and we are trying to use it, but something is blowing chunks in rtalloc1. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_de as a module...
This doesn't happen for me except in this (loadable de) case. Well a bit more digging... netstat -rn 205.238.40.30 205.238.40.30 UHW18 2563 dc0860 Now why oh why is gated and/or the kernel creating that route when ifconfig dc0 dc0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 205.238.40.1 netmask 0xffe0 broadcast 205.238.40.31 ether 00:80:c8:57:cc:45 media: autoselect (10baseT/UTP) status: active supported media: autoselect 100baseTX full-duplex 100baseTX 10baseT/UTP full-duplex 10baseT/UTP none Now, 205.238.40.30 is a router, this route is visible in ospf, here on the originating box: 205.238.40.30/32 - local CP 0 0 11049 11702 and here on another gated/FreeBSD box: 205.238.40.30 198.145.92.1 UGH 1 932 de1 and here from a Cisco: O 205.238.40.30/32 [110/440] via 205.238.44.1, 00:07:33, Ethernet0 Now, what in the hell is deleting the normal arp: ? (205.238.40.30) at 0:c0:7b:6a:28:f0 [ethernet] and replacing it with the above 205.238.40.30/205.238.40.30 route. I've even done an ``arp -S 205.238.40.30 0:c0:7b:6a:28:f0'' to create a ``permanant'' entry and IT gets replaced!!! ARGHHH On Mon, 10 Jul 2000, Rodney W. Grimes wrote: Umm- started okay: : and then died: rplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt NFS Portmap: RPC: Port mapper failure - RPC: Timed out Bleagh. Fooey. :-( Biiilll!!?? :-) I don't think this is Bill. What does the output of netstat -rn | grep 192.67.166.155 look like when the above is occuring? I am having similiar problems here, I just upgraded one of our main boarder routers and started getting this stuff. Is what is happening is a host specific route is getting installed by gated, and this is causing arplookup/arpresolve to have problems when it tries to go create the llinfo. We just upgraded this router from 3.4-stable of January vintage to 4.0-STABLE FreeBSD July 2 vintage. I have seen this in the past, and though it was long gone, but now that I am looking at it again I see what is happening, The message we get is the same as yours: Jul 9 17:37:02 br1 /kernel: arplookup 205.238.40.30 failed: could not allocate llinfo Jul 9 17:37:02 br1 /kernel: arpresolve: can't allocate llinfo for 205.238.40.30 rt Now if I look in my routing table when this is going on (sorry don't have it saved off anyplace I can cut and paste from right now) I see a host route out another interface!!! Yes, we have a large ospf network, yes that route will work, no it is not the right route damn it, there is a direct route via an interface, and we are trying to use it, but something is blowing chunks in rtalloc1. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
