Re: aliasing a point-to-point interface
On Thu, 21 Oct 1999, Ruslan Ermilov wrote: > On Thu, Oct 21, 1999 at 06:50:07PM +0200, Graham Wheeler wrote: > > Hi all > > > > Is it possible to assign an IP alias to a point to point interface (in my case, > > a sync PPP interface)? It doesn't seem to be possible, but perhaps I'm > > missing something... > > Yup, that's possible but is somewhat tricky: > > # ifconfig ptpN inet X.X.X.X X.X.X.X alias > # route delete -host X.X.X.X > # route add -host X.X.X.X -gateway 127.1 > # ping X.X.X.X I should have mentioned that ip forwarding is turned off so that routing via the loopback interface is not an option... -- Dr Graham WheelerE-mail: [EMAIL PROTECTED] Cequrux Technologies Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax:+27(21)24-3656 Data/Network Security SpecialistsWWW:http://www.cequrux.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aliasing a point-to-point interface
On Fri, Oct 22, 1999 at 09:58:44AM +0200, Graham Wheeler wrote: > On Thu, 21 Oct 1999, Ruslan Ermilov wrote: > > On Thu, Oct 21, 1999 at 06:50:07PM +0200, Graham Wheeler wrote: > > > Hi all > > > > > > Is it possible to assign an IP alias to a point to point interface (in my case, > > > a sync PPP interface)? It doesn't seem to be possible, but perhaps I'm > > > missing something... > > > > Yup, that's possible but is somewhat tricky: > > > > # ifconfig ptpN inet X.X.X.X X.X.X.X alias > > # route delete -host X.X.X.X > > # route add -host X.X.X.X -gateway 127.1 > > # ping X.X.X.X > > I should have mentioned that ip forwarding is turned off so that routing > via the loopback interface is not an option... > The above commands do not rely on the host's forwarding capabilities. The first `route' command will remove the weird `X.X.X.X via X.X.X.X' entry. The second `route' command will install the route allowing you to communicate with X.X.X.X from this host itself. Look: : relay# ifconfig sl9 inet 1.1.1.1 1.1.1.1 alias : relay# netstat -rn | grep ^1.1.1.1 : 1.1.1.11.1.1.1UH 00 sl9 : relay# ping 1.1.1.1 : PING 1.1.1.1 (1.1.1.1): 56 data bytes : ^C : --- 1.1.1.1 ping statistics --- : 2 packets transmitted, 0 packets received, 100% packet loss : relay# route delete -host 1.1.1.1 : delete host 1.1.1.1 : relay# route add -host 1.1.1.1 127.1 : add host 1.1.1.1: gateway 127.1 : relay# netstat -rn | grep ^1.1.1.1 : 1.1.1.1127.0.0.1 UGHS00 lo0 : relay# ping 1.1.1.1 : PING 1.1.1.1 (1.1.1.1): 56 data bytes : 64 bytes from 1.1.1.1: icmp_seq=0 ttl=255 time=0.108 ms : 64 bytes from 1.1.1.1: icmp_seq=1 ttl=255 time=0.170 ms : 64 bytes from 1.1.1.1: icmp_seq=2 ttl=255 time=0.208 ms : ^C : --- 1.1.1.1 ping statistics --- : 3 packets transmitted, 3 packets received, 0% packet loss : round-trip min/avg/max/stddev = 0.108/0.162/0.208/0.041 ms -- Ruslan Ermilov Sysadmin and DBA of the [EMAIL PROTECTED]United Commercial Bank, [EMAIL PROTECTED] FreeBSD committer, +380.652.247.647Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aliasing a point-to-point interface
> The above commands do not rely on the host's forwarding capabilities. > The first `route' command will remove the weird `X.X.X.X via X.X.X.X' entry. > The second `route' command will install the route allowing you to communicate > with X.X.X.X from this host itself. Look: > > : relay# ifconfig sl9 inet 1.1.1.1 1.1.1.1 alias > : relay# netstat -rn | grep ^1.1.1.1 > : 1.1.1.11.1.1.1UH 00 sl9 > : relay# ping 1.1.1.1 > : PING 1.1.1.1 (1.1.1.1): 56 data bytes > : ^C > : --- 1.1.1.1 ping statistics --- > : 2 packets transmitted, 0 packets received, 100% packet loss > : relay# route delete -host 1.1.1.1 > : delete host 1.1.1.1 > : relay# route add -host 1.1.1.1 127.1 > : add host 1.1.1.1: gateway 127.1 > : relay# netstat -rn | grep ^1.1.1.1 > : 1.1.1.1127.0.0.1 UGHS00 lo0 > : relay# ping 1.1.1.1 > : PING 1.1.1.1 (1.1.1.1): 56 data bytes > : 64 bytes from 1.1.1.1: icmp_seq=0 ttl=255 time=0.108 ms > : 64 bytes from 1.1.1.1: icmp_seq=1 ttl=255 time=0.170 ms > : 64 bytes from 1.1.1.1: icmp_seq=2 ttl=255 time=0.208 ms > : ^C > : --- 1.1.1.1 ping statistics --- > : 3 packets transmitted, 3 packets received, 0% packet loss > : round-trip min/avg/max/stddev = 0.108/0.162/0.208/0.041 ms I still get no echo replies after doing this. My sequence: ifconfig ar0 inet up ifconfig ar0 inet alias route delete -host route add -host 127.1 ping -- Dr Graham WheelerE-mail: [EMAIL PROTECTED] Cequrux Technologies Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax:+27(21)24-3656 Data/Network Security SpecialistsWWW:http://www.cequrux.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aliasing a point-to-point interface
On Fri, Oct 22, 1999 at 11:53:48AM +0200, Graham Wheeler wrote: > > > The above commands do not rely on the host's forwarding capabilities. > > The first `route' command will remove the weird `X.X.X.X via X.X.X.X' entry. > > The second `route' command will install the route allowing you to communicate > > with X.X.X.X from this host itself. Look: > > > > : relay# ifconfig sl9 inet 1.1.1.1 1.1.1.1 alias > > : relay# netstat -rn | grep ^1.1.1.1 > > : 1.1.1.11.1.1.1UH 00 sl9 > > : relay# ping 1.1.1.1 > > : PING 1.1.1.1 (1.1.1.1): 56 data bytes > > : ^C > > : --- 1.1.1.1 ping statistics --- > > : 2 packets transmitted, 0 packets received, 100% packet loss > > : relay# route delete -host 1.1.1.1 > > : delete host 1.1.1.1 > > : relay# route add -host 1.1.1.1 127.1 > > : add host 1.1.1.1: gateway 127.1 > > : relay# netstat -rn | grep ^1.1.1.1 > > : 1.1.1.1127.0.0.1 UGHS00 lo0 > > : relay# ping 1.1.1.1 > > : PING 1.1.1.1 (1.1.1.1): 56 data bytes > > : 64 bytes from 1.1.1.1: icmp_seq=0 ttl=255 time=0.108 ms > > : 64 bytes from 1.1.1.1: icmp_seq=1 ttl=255 time=0.170 ms > > : 64 bytes from 1.1.1.1: icmp_seq=2 ttl=255 time=0.208 ms > > : ^C > > : --- 1.1.1.1 ping statistics --- > > : 3 packets transmitted, 3 packets received, 0% packet loss > > : round-trip min/avg/max/stddev = 0.108/0.162/0.208/0.041 ms > > I still get no echo replies after doing this. > > My sequence: > > ifconfig ar0 inet up > ifconfig ar0 inet alias > route delete -host > route add -host 127.1 > ping > What does `netstat -rn | grep ' show you after each command? Are you running some routing software? GateD? routed? -- Ruslan Ermilov Sysadmin and DBA of the [EMAIL PROTECTED]United Commercial Bank, [EMAIL PROTECTED] FreeBSD committer, +380.652.247.647Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aliasing a point-to-point interface
G'day folks, I used to do this on my permanent link at home a while ago -- my ISP provided me with a /30 network address with which to run the point- to-point link, and then they routed my class C via my end of the /30, and I was told to default via their end of the /30. This meant that when originating connections from my FreeBSD system, it would be sourced on the /30 address at my end - and therefore subject to my ISPs reverse mappings, not my own class C's. So to force my connections to originate from one of my IPs, I would delete the PPP address that was negotiated with PPP (after pppd was completely connected), and added one of my own with ifconfig, ala: ifconfig ppp0 delete ifconfig ppp0 10.1.1.1 netmask 255.255.255.255 192.168.1.1 alias route delete default route add default 192.168.1.1 now while 192.168.1.1 doesn't exist, and I can't ping it, sending my default traffic via that address forces it to be sent out via the ppp link, and the router at the other end doesn't give a hoot about the fact that I sent the packet to the wrong address, all it cares about is where to send the packet next :) And yes, I can ping 10.1.1.1 from outside my network, so all works as expected. Cheers Leigh -- | "By the time they had diminished | Leigh Hart, [EMAIL PROTECTED] | | from 50 to 8, the other dwarves | CCNA: http://www.cisco.com | | began to suspect 'Hungry' ..." | PO Box 3057 Newton SA 5074 | | -- Gary Larson, "The Far Side" | http://www.dotat.com/hart/ | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aliasing a point-to-point interface
On Fri, Oct 22, 1999 at 08:56:19PM +0930, Leigh Hart wrote: > G'day folks, > > I used to do this on my permanent link at home a while ago -- my ISP > provided me with a /30 network address with which to run the point- > to-point link, and then they routed my class C via my end of the /30, > and I was told to default via their end of the /30. > > This meant that when originating connections from my FreeBSD system, it > would be sourced on the /30 address at my end - and therefore subject to > my ISPs reverse mappings, not my own class C's. > > So to force my connections to originate from one of my IPs, I would > delete the PPP address that was negotiated with PPP (after pppd was > completely connected), and added one of my own with ifconfig, ala: > > ifconfig ppp0 delete > ifconfig ppp0 10.1.1.1 netmask 255.255.255.255 192.168.1.1 alias > route delete default > route add default 192.168.1.1 > > now while 192.168.1.1 doesn't exist, and I can't ping it, sending > my default traffic via that address forces it to be sent out via > the ppp link, and the router at the other end doesn't give a hoot > about the fact that I sent the packet to the wrong address, all it > cares about is where to send the packet next :) > > And yes, I can ping 10.1.1.1 from outside my network, so all works > as expected. > If you execute `route add 10.1.1.1 127.0.0.1' you will also be able to ping it from the host itself. -- Ruslan Ermilov Sysadmin and DBA of the [EMAIL PROTECTED]United Commercial Bank, [EMAIL PROTECTED] FreeBSD committer, +380.652.247.647Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aliasing a point-to-point interface
On Fri, Oct 22, 1999 at 02:33:59PM +0200, Graham Wheeler wrote: > On Fri, 22 Oct 1999, you wrote: > > > What does `netstat -rn | grep ' show you after each command? > > Are you running some routing software? GateD? routed? > > Before I begin, with the link configured with > >ifconfig ar0 inet 192.96.22.18 196.7.70.1 up: > > Routing tables > > Internet: > DestinationGatewayFlags Refs Use Netif Expire > default196.7.70.1 UGSc 520 ar0 > 127.0.0.1 127.0.0.1 UH 17 516 lo0 > 196.7.70.1 192.96.22.18 UH 530 ar0 > > > > > After ifconfig ar0 inet 192.96.22.21 192.96.22.21 alias: > You should be using `netmask 255.255.255.255' here, BTW. > Routing tables > > Internet: > DestinationGatewayFlags Refs Use Netif Expire > default196.7.70.1 UGSc 131 ar0 > 127.0.0.1 127.0.0.1 UH 15 106 lo0 > 192.96.22.21 192.96.22.21 UH 00 ar0 > 196.7.70.1 192.96.22.18 UH 140 ar0 > > > > After route delete -host 192.96.22.21: > > Routing tables > > Internet: > DestinationGatewayFlags Refs Use Netif Expire > default196.7.70.1 UGSc 131 ar0 > 127.0.0.1 127.0.0.1 UH 15 106 lo0 > 196.7.70.1 192.96.22.18 UH 140 ar0 > > > > After route add -host 192.96.22.21 127.1: > > Routing tables > > Internet: > DestinationGatewayFlags Refs Use Netif Expire > default196.7.70.1 UGSc 171 ar0 > 127.0.0.1 127.0.0.1 UH 17 118 lo0 > 192.96.22.21 127.0.0.1 UGHS00 lo0 > 196.7.70.1 192.96.22.18 UH 180 ar0 > Looks OK, the ping(8) should work. Something wrong with ipfw(8)? -- Ruslan Ermilov Sysadmin and DBA of the [EMAIL PROTECTED]United Commercial Bank, [EMAIL PROTECTED] FreeBSD committer, +380.652.247.647Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aliasing a point-to-point interface
On Fri, 22 Oct 1999, Ruslan Ermilov wrote: > > > Internet: > > DestinationGatewayFlags Refs Use Netif Expire > > default196.7.70.1 UGSc 171 ar0 > > 127.0.0.1 127.0.0.1 UH 17 118 lo0 > > 192.96.22.21 127.0.0.1 UGHS00 lo0 > > 196.7.70.1 192.96.22.18 UH 180 ar0 > > > Looks OK, the ping(8) should work. Something wrong with ipfw(8)? Tried that; made no difference (also, that would usually result in a sendto: permission denied response rather than silently losing the packets). -- Dr Graham WheelerE-mail: [EMAIL PROTECTED] Cequrux Technologies Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax:+27(21)24-3656 Data/Network Security SpecialistsWWW:http://www.cequrux.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aliasing a point-to-point interface
On Fri, 22 Oct 1999, you wrote: > What does `netstat -rn | grep ' show you after each command? > Are you running some routing software? GateD? routed? Before I begin, with the link configured with ifconfig ar0 inet 192.96.22.18 196.7.70.1 up: Routing tables Internet: DestinationGatewayFlags Refs Use Netif Expire default196.7.70.1 UGSc 520 ar0 127.0.0.1 127.0.0.1 UH 17 516 lo0 196.7.70.1 192.96.22.18 UH 530 ar0 After ifconfig ar0 inet 192.96.22.21 192.96.22.21 alias: Routing tables Internet: DestinationGatewayFlags Refs Use Netif Expire default196.7.70.1 UGSc 131 ar0 127.0.0.1 127.0.0.1 UH 15 106 lo0 192.96.22.21 192.96.22.21 UH 00 ar0 196.7.70.1 192.96.22.18 UH 140 ar0 After route delete -host 192.96.22.21: Routing tables Internet: DestinationGatewayFlags Refs Use Netif Expire default196.7.70.1 UGSc 131 ar0 127.0.0.1 127.0.0.1 UH 15 106 lo0 196.7.70.1 192.96.22.18 UH 140 ar0 After route add -host 192.96.22.21 127.1: Routing tables Internet: DestinationGatewayFlags Refs Use Netif Expire default196.7.70.1 UGSc 171 ar0 127.0.0.1 127.0.0.1 UH 17 118 lo0 192.96.22.21 127.0.0.1 UGHS00 lo0 196.7.70.1 192.96.22.18 UH 180 ar0 I'm not running any routing daemons; all routes are static. -- Dr Graham WheelerE-mail: [EMAIL PROTECTED] Cequrux Technologies Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax:+27(21)24-3656 Data/Network Security SpecialistsWWW:http://www.cequrux.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aliasing a point-to-point interface
What exactly are you trrying to achieve..? I think I missed the mail that stated what the goal was.. On Thu, 21 Oct 1999, Ruslan Ermilov wrote: > On Thu, Oct 21, 1999 at 06:50:07PM +0200, Graham Wheeler wrote: > > Hi all > > > > Is it possible to assign an IP alias to a point to point interface (in my case, > > a sync PPP interface)? It doesn't seem to be possible, but perhaps I'm > > missing something... > > Yup, that's possible but is somewhat tricky: > > # ifconfig ptpN inet X.X.X.X X.X.X.X alias > # route delete -host X.X.X.X > # route add -host X.X.X.X -gateway 127.1 > # ping X.X.X.X > > > Cheers, > -- > Ruslan ErmilovSysadmin and DBA of the > [EMAIL PROTECTED] United Commercial Bank, > [EMAIL PROTECTED]FreeBSD committer, > +380.652.247.647 Simferopol, Ukraine > > http://www.FreeBSD.orgThe Power To Serve > http://www.oracle.com Enabling The Information Age > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aliasing a point-to-point interface
On Fri, 22 Oct 1999, Julian Elischer wrote: > What exactly are you trrying to achieve..? > > I think I missed the mail that stated what the goal was.. We use aliased addresses to support separate TCP relays to different web servers in a DMZ for HTTP/1.0 (where we can't determine the server from the headers). This was fine while we only supported Ethernet on the outside interface. Now we have a server with a Digi Sync/570 card on the outside, and we are struggling to assign these aliases (or rather, we seem to be able to assign the aliases using Ruslan's suggested method, but we can't seem to connect to the aliased addresses). -- Dr Graham WheelerE-mail: [EMAIL PROTECTED] Cequrux Technologies Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax:+27(21)24-3656 Data/Network Security SpecialistsWWW:http://www.cequrux.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: profile of tcp
> I'm wondering if anyone in this group has done or knows of a good profile > of a tcp send going from user mode to bits on the wire. Reason I'm asking > is the old "put TCP/IP on the NIC" is once again rearing its head, and I'm > hoping there are numbers I can point to (ones that aren't old, that is) > about why this may not be the best idea in the world. FreeBSD seems a good > choice since it has a pretty reasonable implementation. one of the main motivations for _not_ having TCP on the NIC is that you won't see the same progress in performance for NICs as you see for general purpose CPUs. Or, maybe it is more correct to say that you might see a more coarse-grained progress so the NIC speed might be 1-2 yrs behind the state of art in CPUs, thus any gain in having the protocol implemented in hardware (actually microcode, i think) is probably eaten by this lag. Also there is the usual lack of flexibility in having things done in hw/microcode vs. software. And finally, i think having the proto in the NIC may be useful for maybe a router or a box doing traffic switching, but for things like a web server or a cache you also have to look at optimizing the datapath between disk and the NIC. cheers luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ First International Workshop on Networked Group Communication ---+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLDs
Mike Smith writes: > > I expect as much, but when I tried to make an IPX KLD, it paniced the > > system on unload. I will test the FFS KLD soon though. > > Panic on unload usually means that the code in question isn't designed > to unload. 8) Such code should return an error instead of allowing the unload to proceed :-) -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: profile of tcp
> I'm wondering if anyone in this group has done or knows of a good profile > of a tcp send going from user mode to bits on the wire. Reason I'm asking > is the old "put TCP/IP on the NIC" is once again rearing its head, and I'm > hoping there are numbers I can point to (ones that aren't old, that is) > about why this may not be the best idea in the world. FreeBSD seems a good > choice since it has a pretty reasonable implementation. I'd start with "the NIC will require insane amounts of memory to deal with links with large bandwidth/delay products". And when people tell you that the NIC can just use system memory, you should slap them around the head. The thought of a piece of hardware screwing with the kernel memory allocator gives me the creeps. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: profile of tcp
> Also there is the usual lack of flexibility in having things done > in hw/microcode vs. software. > > And finally, i think having the proto in the NIC may be useful for maybe > a router or a box doing traffic switching, but for things like a > web server or a cache you also have to look at optimizing the > datapath between disk and the NIC. > There is however some validity in implimenting particular aspects on the NIC. Specifically the TCP checksum off loading that a number of gigabit NIC's have in silicon. glenn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: profile of tcp
Ron, Didn't see you at FreeBSDcon.. Som if it's on the card how do you do things like ipfw? And how do you route between cards? Who keeps the routing table? how does routed (or whatever) communicate with it? how do you set tcp options? you can do all these but it get's really complicated.. You have to associate a socket (even on win-nt) in the OS with a session on the card.. The approach works if you have some very specialised applications but if you're talking General purpose systems... On Fri, 22 Oct 1999, Mike Smith wrote: > > I'm wondering if anyone in this group has done or knows of a good profile > > of a tcp send going from user mode to bits on the wire. Reason I'm asking > > is the old "put TCP/IP on the NIC" is once again rearing its head, and I'm > > hoping there are numbers I can point to (ones that aren't old, that is) > > about why this may not be the best idea in the world. FreeBSD seems a good > > choice since it has a pretty reasonable implementation. > > I'd start with "the NIC will require insane amounts of memory to deal > with links with large bandwidth/delay products". And when people tell > you that the NIC can just use system memory, you should slap them > around the head. The thought of a piece of hardware screwing with the > kernel memory allocator gives me the creeps. 8) > > -- > \\ Give a man a fish, and you feed him for a day. \\ Mike Smith > \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] > \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Make question
Am I confused or is there a bug in make(1).. ? Why is 'make foo' failing but 'gmake foo' succeeding? $ cat makefile foo: var1=yes; test "$$var1" = "no" && var2=". $$var2"; echo OK $ make foo var1=yes; test "$var1" = "no" && var2=". $var2"; echo OK *** Error code 1 Stop in /root. $ gmake foo var1=yes; test "$var1" = "no" && var2=". $var2"; echo OK OK This happens on -current and -stable. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: profile of tcp
> There is however some validity in implimenting particular aspects on the > NIC. Specifically the TCP checksum off loading that a number of gigabit > NIC's have in silicon. absolutely, as it is useful that the NIC is able to follow linked list of arbitrarily aligned/sized blocks etc, but that is about it. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ahc (2940UW) driver in 3.3
Some time ago I reported corruption using 2.2.8 with an DDRS-39130 connected to a 2940UW. I've done some testing today with 3.3, on a totally different box, with a brand new scsi cable (never before used). Still I see corruption. It's not in the same place every time. My test involves dd'ing /dev/zero to create a 300MB file and then outputting that file in hex, looking for non-zero bytes. What surprised me was it even passed a couple of times. Before I go blaming the drive, can anyone categorically confirm that parity is enabled and enforced in the FreeBSD driver for the 7880 ? For example, has anyone actually seen evidence that it handles parity errors ? Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
replacing grep (again) and regex speed ups
I submitted a PR (bin/14342) which adds a lot of speed to mismatches in Henry Spencer's regex code. Who knows a lot about regex whom I can bug? Also, grep has gone through a lot of changes since the last time it was talked about on this list. The current version can be found in the ports collection under textproc/freegrep. It is still slower than GNU, but not as bad as it was. If people'd be willing to look at it again and offer any speed ups, that would be great. Thanks, Jamie -- Jamie Howard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SMP/interrupt problems..
I recently got an AMI Megaraid controller, and although it works perfectly with a single processor kernel, SMP is causing some problems. After doing a little debugging, it appears that the interrupts are possibly being lost. I'm wondering if this is somehow related to the APIC, and interrupt remapping that happens with SMP. I have included the output of mptable, and a verbose dmesg at the end. Also, LINT mentions some problems with MP tables not properly supporting bridged pci cards. Are there still issues with this? My motherboard (Intel pr440fx) is listed as one with "good" mptable support--at least by the linux kernel. :\ Is there a chance that this combination will simply not work? Any ideas at all on how to isolate the problem would be appreciated. I am at whits end wrt this problem. Thanks, Chris Csanady To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SMP/interrupt problems..
Ugh, I forgot to attach said info. Chris - === MPTable, version 2.0.15 mptable: option requires an argument -- v usage: mptable [-dmesg] [-verbose] [-grope] [-help] friley-160-235# mptable -verbose === MPTable, version 2.0.15 looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009fc00 searching CMOS 'top of mem' @ 0x0009f800 (638K) searching default 'top of mem' @ 0x0009fc00 (639K) searching BIOS @ 0x000f MP FPS found in BIOS @ physical addr: 0x000f80f0 --- MP Floating Pointer Structure: location: BIOS physical address: 0x000f80f0 signature:'_MP_' length: 16 bytes version: 1.4 checksum: 0x10 mode: Virtual Wire --- MP Config Table Header: physical address: 0x000f8100 signature:'PCMP' base table length:260 version: 1.4 checksum: 0x52 OEM ID: 'INTEL ' Product ID: 'PR440FX ' OEM table pointer:0x OEM table size: 0 entry count: 24 local APIC address: 0xfec08000 extended table length:120 extended table checksum: 15 --- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model StepFlags 0 0x11BSP, usable 6 1 9 0xfbff 12 0x11AP, usable 6 1 9 0xfbff -- Bus:Bus ID Type 0 PCI 1 PCI 18 ISA -- I/O APICs: APIC ID Version State Address 13 0x11usable 0xfec0 -- I/O Ints: TypePolarityTrigger Bus ID IRQAPIC ID PIN# ExtINT active-hiedge 18 0 130 INT active-hiedge 18 1 131 INT active-hiedge 18 3 133 INT active-hiedge 18 4 134 INT active-hiedge 18 5 135 INT active-hiedge 18 6 136 INT active-hiedge 18 7 137 INT active-hiedge 18 8 138 INT active-hiedge 18 9 139 INT active-hiedge 1812 13 12 INT active-hiedge 1814 13 14 INT active-hiedge 1815 13 15 INT active-lo level0 19:A 13 19 INT active-lo level0 17:A 13 18 INT active-lo level0 9:A 13 17 INT active-lo level0 6:A 13 18 -- Local Ints: TypePolarityTrigger Bus ID IRQAPIC ID PIN# ExtINT active-hiedge 18 02550 NMI active-hiedge0 0:A2551 --- MP Config Extended Table Entries: -- bus ID: 0 address type: memory address address base: 0xd4000 address range: 0x4000 -- bus ID: 0 address type: memory address address base: 0xd8000 address range: 0x4000 -- bus ID: 0 address type: memory address address base: 0xdc000 address range: 0x4000 -- bus ID: 0 address type: memory address address base: 0xa address range: 0x2 -- bus ID: 0 address type: memory address address base: 0x800 address range: 0xf800 -- bus ID: 0 address type: I/O address address base: 0x0 address range: 0x1 --- # SMP kernel config file options: # Required: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optional (built-in defaults will work in most cases): #optionsNCPU=2 # number of CPUs #optionsNBUS=3 # number of busses #optionsNAPIC=1 # number of IO APICs #options
Re: ahc (2940UW) driver in 3.3
Darren Reed wrote... > > Some time ago I reported corruption using 2.2.8 with an DDRS-39130 > connected to a 2940UW. I've done some testing today with 3.3, on > a totally different box, with a brand new scsi cable (never before > used). Still I see corruption. It's not in the same place every > time. My test involves dd'ing /dev/zero to create a 300MB file and > then outputting that file in hex, looking for non-zero bytes. What > surprised me was it even passed a couple of times. > > Before I go blaming the drive, can anyone categorically confirm that > parity is enabled and enforced in the FreeBSD driver for the 7880 ? > > For example, has anyone actually seen evidence that it handles parity > errors ? Yes, it handles parity errors: (da0:ahc0:0:0:0): parity error during Data-In phase. SEQADDR == 0x10f SCSIRATE == 0x88 (da0:ahc0:0:0:0): parity error during Data-In phase. SEQADDR == 0x110 SCSIRATE == 0x88 (da0:ahc0:0:0:0): parity error during Data-In phase. SEQADDR == 0x110 SCSIRATE == 0x88 (da0:ahc0:0:0:0): parity error during Data-In phase. SEQADDR == 0x10f SCSIRATE == 0x88 (da0:ahc0:0:0:0): parity error during Data-In phase. SEQADDR == 0x10f SCSIRATE == 0x88 (da0:ahc0:0:0:0): READ(10). CDB: 28 0 0 31 d9 80 0 0 4 0 (da0:ahc0:0:0:0): ABORTED COMMAND asc:48,0 (da0:ahc0:0:0:0): Initiator detected error message received That's from a mid-August -stable machine that most likely has a bad cable. I'm not sure, however, whether the driver pays attention to the parity setting in the Adaptec BIOS, or what effect that has on things. You should make sure that you have parity checking enabled in your BIOS. I haven't seen any corruption problems with the driver, and yours is the first report I've seen. Do you have parity memory, and is parity checking or ECC enabled? It may be unlikely for the same problem to happen on two different machines, but it is possible. Since the drive is the common element, I would be inclined to place the blame there. Do you have trouble with any other SCSI hard disks and the same machine/controller/cable combination? Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
cvsup not being updated?
I checked in stuff about 3 hours ago but it's still not showing up on either of cvsup2 or svsup3 anything funny going on? julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
