From owner-netdev@oss.sgi.com Sun Apr 1 04:33:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f31BXeb08555 for netdev-outgoing; Sun, 1 Apr 2001 04:33:40 -0700 Received: from mandrakesoft.mandrakesoft.com (IDENT:jgarzik@mandrakesoft.mandrakesoft.com [216.71.84.35]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f31BXdM08552 for ; Sun, 1 Apr 2001 04:33:39 -0700 Received: from localhost (jgarzik@localhost) by mandrakesoft.mandrakesoft.com (8.8.5/8.8.5) with SMTP id GAA22238 for ; Sun, 1 Apr 2001 06:33:32 -0500 Date: Sun, 1 Apr 2001 06:33:32 -0500 (CDT) From: Jeff Garzik To: netdev@oss.sgi.com Subject: RFC: cleaning up net_init.c Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk If you guys didn't see the alloc_etherdev() changes or my RFCs on this list, check out drivers/net/net_init.c in 2.4.3. init_foodev, register_foodev, and unregister_foodev are completely superfluous and should be removed. Further, now that alloc_etherdev is in the kernel, init_foodev especially should go away, because of the race which alloc_etherdev solves. Ideally I would like to work through the drivers in 2.4.x, fixing the race by replacing init_etherdev with alloc_etherdev. However, for older ISA drivers, I don't yet have an alloc_etherdev strategy. Suggestions welcome. Jeff From owner-netdev@oss.sgi.com Sun Apr 1 04:45:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f31Bjmd09049 for netdev-outgoing; Sun, 1 Apr 2001 04:45:48 -0700 Received: from mandrakesoft.mandrakesoft.com (IDENT:jgarzik@mandrakesoft.mandrakesoft.com [216.71.84.35]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f31BjlM09046 for ; Sun, 1 Apr 2001 04:45:47 -0700 Received: from localhost (jgarzik@localhost) by mandrakesoft.mandrakesoft.com (8.8.5/8.8.5) with SMTP id GAA23060 for ; Sun, 1 Apr 2001 06:45:01 -0500 Date: Sun, 1 Apr 2001 06:44:59 -0500 (CDT) From: Jeff Garzik To: netdev@oss.sgi.com Subject: Re: RFC: cleaning up net_init.c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Sun, 1 Apr 2001, Jeff Garzik wrote: > init_foodev, register_foodev, and unregister_foodev are completely > superfluous and should be removed. Sigh -- I shouldn't post at 4am ;-) I should have made it clear that the above quoted RFC is 2.5 material. Removing init_etherdev removes a race, and uses an official API (as of 2.4.3), and so that's 2.4 material. Not urgent, but still 2.4 material since it fixes a race. Jeff From owner-netdev@oss.sgi.com Sun Apr 1 16:44:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f31Ni1A20601 for netdev-outgoing; Sun, 1 Apr 2001 16:44:01 -0700 Received: from smtp102.urscorp.com (smtp102.urscorp.com [38.202.96.105]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f31Ni0M20598 for ; Sun, 1 Apr 2001 16:44:00 -0700 To: netdev@oss.sgi.com Cc: burts@us.ibm.com Subject: NFS/UDP/Token Ring/Sockets dropped X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 From: mike_phillips@urscorp.com Message-ID: Date: Sun, 1 Apr 2001 20:33:14 -0300 X-MIMETrack: Serialize by Router on SMTP102/URSCorp(Release 5.0.5 |September 22, 2000) at 04/01/2001 07:40:33 PM, Serialize complete at 04/01/2001 07:40:33 PM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-netdev@oss.sgi.com Precedence: bulk All, We're getting problems mounting nfs over token-ring (specifically olympic). In olympic we set the buffer size to match the mtu which defaults to 4096. When we receive a packet if it fits all in one buffer the skbuff is just swapped and transferred to the network layers. The problem comes when the skbuff hits the socket layers, there is a test in sock.h for skb->truesize >= sk->rcvbuf. rcvbuf is set to 2048 and truesize is coming in much larger and therefore the test is failing and the packet not getting put on the sk->receive_queue. So, the question is where should the fix for this go ? I can alter olympic to memcpy the packet into a skbuff that is allocated to the length of th packet (which we already do if the packet spans multiple buffers) but then we lose the efficiency from just swapping the buffers or should sock.h test against skb->len rather than skb->truesize or is there a third option ? Mike Linux Token Ring Project http://www.linuxtr.net From owner-netdev@oss.sgi.com Mon Apr 2 05:04:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32C4wO09602 for netdev-outgoing; Mon, 2 Apr 2001 05:04:58 -0700 Received: from dea.waldorf-gmbh.de (u-170-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.170]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32C4UM09585 for ; Mon, 2 Apr 2001 05:04:36 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f32C0ai08537 for netdev@oss.sgi.com; Mon, 2 Apr 2001 14:00:36 +0200 Received: from mandrakesoft.mandrakesoft.com (mandrakesoft.mandrakesoft.com [216.71.84.35]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f31MKHM19544 for ; Sun, 1 Apr 2001 15:20:17 -0700 Received: from localhost (jgarzik@localhost) by mandrakesoft.mandrakesoft.com (8.8.5/8.8.5) with SMTP id RAA28423; Sun, 1 Apr 2001 17:18:50 -0500 Date: Sun, 1 Apr 2001 17:18:50 -0500 (CDT) From: Jeff Garzik To: Krzysztof Halasa cc: Linux-Kernel , netdev@oss.sgi.com Subject: Re: RFC: configuring net interfaces In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On 1 Apr 2001, Krzysztof Halasa wrote: > Jeff Garzik writes: > > I'm not suggesting you modify ethtool for your needs :) But ethtool > > perfectly illustrates the technique of using a single socket ioctl > > (SIOCETHTOOL) to extend a set of standard, domain-specific ioctls > > (ETHTOOL_xxx) to Linux networking drivers. > > I know. The problem is I don't see here any advantages over many SIOCxxx > command codes, while there are disadvantages. > Simple things are IMHO better, and ioctl was designed to handle many > simple commands (instead of one complex). > > Am I missing something? IMHO we should get away from adding hardware-type-specific ioctls from the generic SIOCxxx list. Sure it is easy to dump a bunch of new ioctls into sockios.h. But having "one big header that covers all hardware types and ioctl situations" does not seem like the right solution to me. First of all, you as the HDLC subsystem maintainer have a lot more control over what goes into include/linux/hdlc.h than include/linux/sockios.h. New SIOCxxxx ioctls should not be added on a whim, but after examination of the issues involved. Making a mistake and adding a bad/pointless SIOCxxxx ioctl means you are stuck with it for a long time. The same applies to ioctls in hdlc.h of course -- but the key distinction is that you are 100% sure of the issues involved because changes are localized to your own domain. Further, each change to sockios.h affects a LOT of code, both in and outside the kernel. Localizing your changes also localizes the effects of bad namespace and ioctl choices (and bugs, though in this case that would be rare). Finally, I have this (perhaps crazy) idea that we should move in the direction of removing ALL hardware-related ioctls from sockios.h, making SIOCxxxx the domain of generic network device ioctls. Comments welcome. IMHO domain-specific ioctls are a better direction than the current make-sockios.h-huge-with-new-ioctls approach. Regards, Jeff P.S. It would be awesome if you would consider CC'ing netdev@oss.sgi.com. Some developers who might have valuable input do not subscribe to linux-kernel, or are not able to read all of the net-related linux-kernel messages. From owner-netdev@oss.sgi.com Mon Apr 2 05:05:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32C51K09614 for netdev-outgoing; Mon, 2 Apr 2001 05:05:01 -0700 Received: from dea.waldorf-gmbh.de (u-170-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.170]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32C4sM09599 for ; Mon, 2 Apr 2001 05:04:55 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f32C0hE08541 for netdev@oss.sgi.com; Mon, 2 Apr 2001 14:00:43 +0200 Received: from mandrakesoft.mandrakesoft.com (IDENT:jgarzik@mandrakesoft.mandrakesoft.com [216.71.84.35]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f31MSfM19660 for ; Sun, 1 Apr 2001 15:28:41 -0700 Received: from localhost (jgarzik@localhost) by mandrakesoft.mandrakesoft.com (8.8.5/8.8.5) with SMTP id RAA29666 for ; Sun, 1 Apr 2001 17:28:39 -0500 Date: Sun, 1 Apr 2001 17:28:39 -0500 (CDT) From: Jeff Garzik To: netdev@oss.sgi.com Subject: ethtool interface Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk (this is just an "FYI" type message, to make sure people are all on the same page) Here is the current ethtool interface, as found in 2.4.3 release kernel include/linux/ethtool.h. DaveM has kindly allowed me to take his original ethtool work and start maintaining and improving it. As soon as I add support in ethtool for using the existing net driver MII ioctls, I will be posting tarballs on http://sourceforge.net/projects/gkernel/ (or maybe a new 'ethtool' project) Note that it is my intention to eventually replace mii-tool with ethtool (mii-tool becomes a wrapper calling ethtool, for back compatibility). I also want ethtool to work on 2.2 kernels which don't have the ethtool interface, which is another reason why supporting the existing, working MII ioctls is important to me. Further down the road, I was thinking it would be nice to have driver-specific ioctl support in ethtool. That is a vast convenience for the user, who needs only one tool to tune any NIC. For the Becker-derived drivers this is not immediately useful. For other drivers (acenic, depca, others) with non-MII-related ioctls, this seems like a useful feature. If there are driver-specific tuning items we want to add in the future, this makes it easy to exploit those new items in userland. /* * ethtool.h: Defines for Linux ethtool. * * Copyright (C) 1998 David S. Miller (davem@redhat.com) * Copyright 2001 Jeff Garzik */ #ifndef _LINUX_ETHTOOL_H #define _LINUX_ETHTOOL_H /* This should work for both 32 and 64 bit userland. */ struct ethtool_cmd { u32 cmd; u32 supported; /* Features this interface supports */ u32 advertising; /* Features this interface advertises */ u16 speed; /* The forced speed, 10Mb, 100Mb, gigabit */ u8 duplex; /* Duplex, half or full */ u8 port; /* Which connector port */ u8 phy_address; u8 transceiver; /* Which tranceiver to use */ u8 autoneg; /* Enable or disable autonegotiation */ u32 maxtxpkt; /* Tx pkts before generating tx int */ u32 maxrxpkt; /* Rx pkts before generating rx int */ u32 reserved[4]; }; /* these strings are set to whatever the driver author decides... */ struct ethtool_drvinfo { u32 cmd; char driver[32]; /* driver short name, "tulip", "eepro100" */ char version[32]; /* driver version string */ char fw_version[32]; /* firmware version string, if applicable */ char bus_info[32]; /* Bus info for this interface. For PCI * devices, use pci_dev->slot_name. */ char reserved1[32]; char reserved2[32]; }; /* CMDs currently supported */ #define ETHTOOL_GSET 0x00000001 /* Get settings. */ #define ETHTOOL_SSET 0x00000002 /* Set settings, privileged. */ #define ETHTOOL_GDRVINFO 0x00000003 /* Get driver info. */ /* compatibility with older code */ #define SPARC_ETH_GSET ETHTOOL_GSET #define SPARC_ETH_SSET ETHTOOL_SSET /* Indicates what features are supported by the interface. */ #define SUPPORTED_10baseT_Half (1 << 0) #define SUPPORTED_10baseT_Full (1 << 1) #define SUPPORTED_100baseT_Half (1 << 2) #define SUPPORTED_100baseT_Full (1 << 3) #define SUPPORTED_1000baseT_Half (1 << 4) #define SUPPORTED_1000baseT_Full (1 << 5) #define SUPPORTED_Autoneg (1 << 6) #define SUPPORTED_TP (1 << 7) #define SUPPORTED_AUI (1 << 8) #define SUPPORTED_MII (1 << 9) #define SUPPORTED_FIBRE (1 << 10) /* Indicates what features are advertised by the interface. */ #define ADVERTISED_10baseT_Half (1 << 0) #define ADVERTISED_10baseT_Full (1 << 1) #define ADVERTISED_100baseT_Half (1 << 2) #define ADVERTISED_100baseT_Full (1 << 3) #define ADVERTISED_1000baseT_Half (1 << 4) #define ADVERTISED_1000baseT_Full (1 << 5) #define ADVERTISED_Autoneg (1 << 6) #define ADVERTISED_TP (1 << 7) #define ADVERTISED_AUI (1 << 8) #define ADVERTISED_MII (1 << 9) #define ADVERTISED_FIBRE (1 << 10) /* The following are all involved in forcing a particular link * mode for the device for setting things. When getting the * devices settings, these indicate the current mode and whether * it was foced up into this mode or autonegotiated. */ /* The forced speed, 10Mb, 100Mb, gigabit. */ #define SPEED_10 10 #define SPEED_100 100 #define SPEED_1000 1000 /* Duplex, half or full. */ #define DUPLEX_HALF 0x00 #define DUPLEX_FULL 0x01 /* Which connector port. */ #define PORT_TP 0x00 #define PORT_AUI 0x01 #define PORT_MII 0x02 #define PORT_FIBRE 0x03 #define PORT_BNC 0x04 /* Which tranceiver to use. */ #define XCVR_INTERNAL 0x00 #define XCVR_EXTERNAL 0x01 #define XCVR_DUMMY1 0x02 #define XCVR_DUMMY2 0x03 #define XCVR_DUMMY3 0x04 /* Enable or disable autonegotiation. If this is set to enable, * the forced link modes above are completely ignored. */ #define AUTONEG_DISABLE 0x00 #define AUTONEG_ENABLE 0x01 #endif /* _LINUX_ETHTOOL_H */ From owner-netdev@oss.sgi.com Mon Apr 2 12:18:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f32JI6A03346 for netdev-outgoing; Mon, 2 Apr 2001 12:18:06 -0700 Received: from hq.pm.waw.pl (hq.pm.waw.pl [195.116.170.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f32JI3M03343 for ; Mon, 2 Apr 2001 12:18:04 -0700 Received: (from uucp@localhost) by hq.pm.waw.pl with UUCP id f32JHMm29404; Mon, 2 Apr 2001 21:17:22 +0200 Received: (from khc@localhost) by intrepid.pm.waw.pl (8.11.0/8.11.0) id f32JAwc27453; Mon, 2 Apr 2001 21:10:58 +0200 To: Jeff Garzik Cc: Linux-Kernel , netdev@oss.sgi.com Subject: Re: RFC: configuring net interfaces References: Content-Type: text/plain; charset=US-ASCII From: Krzysztof Halasa Date: 02 Apr 2001 21:10:57 +0200 In-Reply-To: Jeff Garzik's message of "Sun, 1 Apr 2001 17:18:50 -0500 (CDT)" Message-ID: Lines: 111 MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Jeff Garzik writes: > First of all, you as the HDLC subsystem maintainer have a lot more > control over what goes into include/linux/hdlc.h than > include/linux/sockios.h. New SIOCxxxx ioctls should not be added on a > whim, but after examination of the issues involved. Right. The same applies to config_xxx structures. This is why we're talking about it here. > Making a mistake > and adding a bad/pointless SIOCxxxx ioctl means you are stuck with it > for a long time. The same applies to ioctls in hdlc.h of course -- but > the key distinction is that you are 100% sure of the issues involved > because changes are localized to your own domain. I don't see the real difference. SIOCxxx is just a name+value pair, everybody can monitor SIOCxxx changes etc. > Further, each change to sockios.h affects a LOT of code, both in > and outside the kernel. Localizing your changes also localizes the > effects of bad namespace and ioctl choices (and bugs, though in this > case that would be rare). We should then design it the right way :-) > Finally, I have this (perhaps crazy) idea that we should move in the > direction of removing ALL hardware-related ioctls from sockios.h, making > SIOCxxxx the domain of generic network device ioctls. What are these "generic network device ioctls"? Is add-an-IP-address a generic enough? Not all devices use IP. Is set-interface-speed a generic command? Most devices have something like "speed", clock rate or something like this. The question is: where would you like to move these ioctls to? > Comments welcome. IMHO domain-specific ioctls are a better direction > than the current make-sockios.h-huge-with-new-ioctls approach. I think we should separate two things there: - the place (files) where SIOCxxx values are defined - the way we use ioctl call. The first question is less important (files are just files, both sockios.h and protocol header files are acceptable I think). We just have to make sure ioctls are unique across the kernel - current sockios.h does the job, but we can, for example, use a prefix like #define HDLC_PREFIX 0xHD7C0000 and then #define SIOC_add-HDLC-something HDLC_PREFIX | 0x0001 (It looks more complicated and thus we should avoid it I think). The second question looks more important, as it influences the actual code being used. I just believe something like: struct ifreq { name; union { struct ifru_addr; struct ifru_ipv6_something; ... struct hdlc_physical; struct eth_physical; struct fr_protocol; ... }ifru; } and calling ioctl with: ifreq.name = "qwe0"; ifreq.ifru.fr_protocol.t391 = 20; ifreq.ifru.fr_protocol.n293 = 5; ioctl(s, SIOC_SET_FR_PROTO_PARAMETERS, &ifreq); is technically much better than: struct ifreq { name; void *data; } you have to call it with: proto = malloc(); ifreq.name = "qwe0"; ifreq.data = proto; (int*)proto = SIOC_SET_FR_PROTO_PARAMETERS; (fr_protocol)(((int*)proto) + 1).fr_protocol.t391 = 20; (fr_protocol)(((int*)proto) + 1).fr_protocol.n393 = 5; ioctl(s, SIOC_FR_PROTO, &ifreq); and it ends in the protocol driver: do_ioctl(dev, *ifreq, int cmd) { verify_area(..., ifreq.data, sizeof(int)); if (*(int*)ifreq.data == SIOC_SET_FR_PROTO_PARAMETERS) { verify_area(ifreq.data + sizeof(int), sizeof(fr_protocol)); etc. Your comments? In short and general: I think the quality (and thus simplicity) of the actual code is more important than creating mechanisms designed to fight future possible binary incompatibility issues, especially issues with helper utils like ifconfig which can be easily rebuild from source. Of course, we have to design good code and this is why we're all here. -- Krzysztof Halasa Network Administrator From owner-netdev@oss.sgi.com Tue Apr 3 01:28:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f338Se225761 for netdev-outgoing; Tue, 3 Apr 2001 01:28:40 -0700 Received: from se1.cogenit.fr (IDENT:root@se1.cogenit.fr [195.68.53.173]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f338ScM25758 for ; Tue, 3 Apr 2001 01:28:38 -0700 Received: (from romieu@localhost) by se1.cogenit.fr (8.11.1/8.11.1) id f338RY527745; Tue, 3 Apr 2001 10:27:34 +0200 Date: Tue, 3 Apr 2001 10:27:34 +0200 From: Francois Romieu To: Linux-Kernel Cc: netdev@oss.sgi.com Subject: Re: RFC: configuring net interfaces Message-ID: <20010403102734.A27344@se1.cogenit.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from khc@intrepid.pm.waw.pl on Mon, Apr 02, 2001 at 09:10:57PM +0200 X-Organisation: Marie's fan club Sender: owner-netdev@oss.sgi.com Precedence: bulk Krzysztof Halasa écrit : [...] > > Comments welcome. IMHO domain-specific ioctls are a better direction > > than the current make-sockios.h-huge-with-new-ioctls approach. > > I think we should separate two things there: > - the place (files) where SIOCxxx values are defined > - the way we use ioctl call. (1) and (2) may be related: no sub-ioctl (2) + scattered files (1) = *ouch* [...] > you have to call it with: > proto = malloc(); > ifreq.name = "qwe0"; > ifreq.data = proto; > (int*)proto = SIOC_SET_FR_PROTO_PARAMETERS; > (fr_protocol)(((int*)proto) + 1).fr_protocol.t391 = 20; > (fr_protocol)(((int*)proto) + 1).fr_protocol.n393 = 5; > ioctl(s, SIOC_FR_PROTO, &ifreq); Variant: struct sub_req sub; sub.fr_protocol.t391 = 20; sub.fr_protocol.n293 = 5; sub.sub_ioctl = SIOC_SET_FR_PROTO_PARAMETERS; ifreq.name = "qwe0"; ifreq.data = ⊂ ioctl(s, SIOC_FR_PROTO, &ifreq); At least it avoids digging at a special position in a structure to know the expected operation and the underlying structure. struc sub_req { int sub_ioctl; union { struct fr_protocol fr_prot; ... struct xx_protocol xx_prot; } } struct if_req { int name; struct sub_req sub; } It could avoid a flat name-space. Opinion anyone ? -- Ueimor From owner-netdev@oss.sgi.com Tue Apr 3 10:09:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f33H9wX09595 for netdev-outgoing; Tue, 3 Apr 2001 10:09:58 -0700 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f33H9vM09592 for ; Tue, 3 Apr 2001 10:09:57 -0700 Received: from esvir06nok.ntc.nokia.com (esvir06nokt.ntc.nokia.com [172.21.143.38]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f33H9wS04841 for ; Tue, 3 Apr 2001 20:09:59 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 3 Apr 2001 20:09:55 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Tue, 3 Apr 2001 20:09:55 +0300 Message-ID: <2D6CADE9B0C6D411A27500508BB3CBD063CED9@eseis15nok> From: Imran.Patel@nokia.com To: netdev@oss.sgi.com Subject: alloc_skb returns allocated memory!! Date: Tue, 3 Apr 2001 20:09:49 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk hello all, I have been troubled by a problem regarding skbuff allocation. The scenario is that when i get a packet using netfilter hook, i convert it to another packet (more precisely i do ipv4 to ipv6 translation).. for this i just allocate a new buffer and copy the data from the old one to the new packet and drop the old packet (i.e. return NF_STOLEN). However, when i allocate this new buffer using alloc_skb, i get a memory area which is already pointed to by the older skbuff. Again this problem happens only sometimes...and is hard to produce in a particular pattern. Is this something really serious or am i missing something?? regards imran From owner-netdev@oss.sgi.com Tue Apr 3 14:20:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f33LKJv18533 for netdev-outgoing; Tue, 3 Apr 2001 14:20:19 -0700 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f33LKIM18528 for ; Tue, 3 Apr 2001 14:20:18 -0700 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA10115; Tue, 3 Apr 2001 14:20:16 -0700 (MST)] Received: [from em.cig.mot.com ([160.44.107.36]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA07472; Tue, 3 Apr 2001 14:20:16 -0700 (MST)] Received: (from piggy@localhost) by em.cig.mot.com (8.9.3/8.9.3) id QAA06352; Tue, 3 Apr 2001 16:20:16 -0500 Date: Tue, 3 Apr 2001 16:20:16 -0500 Message-Id: <200104032120.QAA06352@em.cig.mot.com> From: "La Monte H.P. Yarroll" To: netdev@oss.sgi.com Cc: becker@scyld.com Subject: Minutes for Linux 2.5 Summit Networking WG Sender: owner-netdev@oss.sgi.com Precedence: bulk These are the notes I took at the Linux 2.5 Summit meeting of the Networking WG. Pardon my liberties, especially if I have misquoted anybody or omitted some important context. I spend most of my time at layer 4 in the networking stack, so sometimes the layer 2 discussions went over my head. I might also admit that my choice of beverages was perhaps not optimal for careful concentration. Please send corrections to and . If I get corrections before Thursday (4 April 2001), I will submit corrected minutes to Rik Farrow for inclusion in the Summit proceedings. Sat Mar 31 23:15:02 CST 2001 new statistics ------------------------------------------------- [We believe this is the least controversial.] DB: "We probably want to support one of the standard MIBs." Do we agree that we need to expand the set of statistics? Yes. We don't distinguish between chips that count collisions and chips that provide only a chip-occured bit. There is also a collision overflow (16 collisions), but we don't have to worry about that case. RFC1643 reports multiple collisions and collided packets separately, but this is not available for all drivers. There were no strong opinions. Jamal thinks we should implement whatever the RFC's recommend. Action Item: Do we put the base set of statistics in the netdevice structure or as its own data structure? There is no performance issue. It LOOKS like it should be in a separate structure. DB: How about we the log flags (formerly debug level) in the per interface level? AC: "I don't care what you call it. Just put it somewhere in proc." DB: "I don't care where it goes, but we should pick a good name." Bitmapped or simply a level? If you have more than 32 things to debug something is WRONG. Consensus: Bitmapped is fine. Suggestion: The procfs interface is the old interface. ioctl() provides the bitmap interface. The mapping is 0->0, 1 -> 0x0001, 2 -> 0x0003, 3 -> 0x0007, etc... (i.e. (1<; Wed, 4 Apr 2001 11:58:09 -0700 Received: from lutchann (helo=localhost) by marduk.litech.org with local-esmtp (Exim 3.22 #1) id 14ksTk-0003EF-00; Wed, 04 Apr 2001 14:58:04 -0400 Date: Wed, 4 Apr 2001 14:58:04 -0400 (EDT) From: Nathan Lutchansky To: "usagi-users@linux-ipv6.org" , "netdev@oss.sgi.com" cc: Pekka Savola , Peter Bieringer Subject: ANNOUNCE: radvd-0.6.2pl1 is available Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Pekka Savola and I have released an updated version of radvd, the Linux IPv6 router advertisement daemon. Lars Fenneberg, the current maintainer of radvd, has not responded to emails regarding patches for radvd, so we have released a patched version of 0.6.2 which we named 0.6.2pl1. Improvements include: - Support for dynamic 6to4 prefixes - Security fixes, including the option to drop root privileges at start - Fixed signal handling - Other misc bugfixes and cleanup We provide version 0.6.2pl1 as a unified diff against the original source, as a complete source package, and as RPMs for RedHat systems. The distribution site for our version of radvd is: http://v6web.litech.org/radvd/ Please contact us if you have any questions or comments. -Nathan -- +-------------------+---------------------+------------------------+ | Nathan Lutchansky | lutchann@litech.org | Lithium Technologies | +------------------------------------------------------------------+ | I dread success. To have succeeded is to have finished one's | | business on earth... I like a state of continual becoming, | | with a goal in front and not behind. - George Bernard Shaw | +------------------------------------------------------------------+ From owner-netdev@oss.sgi.com Fri Apr 6 04:10:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f36BAlP23681 for netdev-outgoing; Fri, 6 Apr 2001 04:10:47 -0700 Received: from blackhole.kfki.hu (blackhole.kfki.hu [148.6.0.114]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f36BAkM23677 for ; Fri, 6 Apr 2001 04:10:46 -0700 Received: by blackhole.kfki.hu (Postfix, from userid 311) id 09F9CD163; Fri, 6 Apr 2001 13:10:47 +0200 (CEST) Date: Fri, 6 Apr 2001 13:10:46 +0200 (CEST) From: Jozsef Kadlecsik To: Subject: 2.4.x crashes due to an IPv6 packet with invalid length Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello, We have been testing the IPv6 implementation of different Linux kernel versions with TAHI (www.tahi.org) and the 56th test from the IPv6 Speficication series causes 2.4.x to crash. The test is to check fragment reassembly when the length is invalid: TEST PROCEDURE Tester Target | | |-------------------------->| | Echo Request (1st) | | | | | |-------------------------->| | Echo Request (2nd) | | | | | |<--------------------------| | ICMP Error | | | | | v v 1. Send Echo Request (1st fragment) 2. Send Echo Request (2nd fragment) 3. Receive ICMP Error Echo Request (1st fragment) is: IPv6 Header Version = 6 Traffic Class = 0 FlowLabel = 0 PayloadLength = 527 (not multiple of 8 octets) NextHeader = 56 (Fragment Header) SourceAddress = Tester Link Local Address DestinationAddress = Target Link Local Address Fragment Header NextHeader = 58 (ICMP) FragmentOffset = 0 (1st fragment) MFlag = 1 (more fragment) The last messages before the oops are: Warning: kfree_skb passed an skb still on a list (from xxxxxx) and it is from the kfree_skb called from ip6_frag_queue in reassemmbly.c I hope this helps to find the bug (2.2.19 is OK). Regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu WWW-Home: http://www.kfki.hu/~kadlec Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary From owner-netdev@oss.sgi.com Fri Apr 6 11:45:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f36Ijlc04209 for netdev-outgoing; Fri, 6 Apr 2001 11:45:47 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f36IjiM04204 for ; Fri, 6 Apr 2001 11:45:45 -0700 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA20988; Fri, 6 Apr 2001 22:45:16 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200104061845.WAA20988@ms2.inr.ac.ru> Subject: Re: 2.4.x crashes due to an IPv6 packet with invalid length To: kadlec@blackhole.kfki.HU (Jozsef Kadlecsik) Date: Fri, 6 Apr 2001 22:45:16 +0400 (MSK DST) Cc: netdev@oss.sgi.com In-Reply-To: from "Jozsef Kadlecsik" at Apr 6, 1 03:45:01 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello! > The test is to check fragment reassembly when the length is invalid: What version of the kernel exaclty? Similar bug was present and has been fixed pretty long ago. Alexey From owner-netdev@oss.sgi.com Sat Apr 7 08:31:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f37FVpX24766 for netdev-outgoing; Sat, 7 Apr 2001 08:31:51 -0700 Received: from hotmail.com (f106.law7.hotmail.com [216.33.237.106]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f37FVpM24763 for ; Sat, 7 Apr 2001 08:31:51 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 7 Apr 2001 08:31:45 -0700 Received: from 212.103.163.125 by lw7fd.law7.hotmail.msn.com with HTTP; Sat, 07 Apr 2001 15:31:45 GMT X-Originating-IP: [212.103.163.125] From: "Ahmed Wageeh" To: netdev@oss.sgi.com Subject: HI Date: Sat, 07 Apr 2001 15:31:45 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Apr 2001 15:31:45.0981 (UTC) FILETIME=[DAD576D0:01C0BF77] Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi I'm a computer science studier and i would like to ask about the IP packet headers. Is there is a way to read these headers to know something like source address, destinatin address ... to have the ability to pass or drop this packet. I work under windows 2000 Os I would be really grateful if you gave me some piece of advice. May you recommend me some source of information (book, web sources,...) in which I could find what I need? Thank you so much in advance... _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-netdev@oss.sgi.com Sat Apr 7 12:27:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f37JR8B28998 for netdev-outgoing; Sat, 7 Apr 2001 12:27:08 -0700 Received: from blackhole.kfki.hu (blackhole.kfki.hu [148.6.0.114]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f37JR7M28995 for ; Sat, 7 Apr 2001 12:27:07 -0700 Received: by blackhole.kfki.hu (Postfix, from userid 311) id 47282CF64; Sat, 7 Apr 2001 21:27:07 +0200 (CEST) Date: Sat, 7 Apr 2001 21:27:07 +0200 (CEST) From: Jozsef Kadlecsik To: Cc: Subject: Re: 2.4.x crashes due to an IPv6 packet with invalid length In-Reply-To: <200104061845.WAA20988@ms2.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Fri, 6 Apr 2001 kuznet@ms2.inr.ac.ru wrote: > > The test is to check fragment reassembly when the length is invalid: > > What version of the kernel exaclty? Similar bug was present and > has been fixed pretty long ago. 2.4.3, 2.4.2, 2.4.0. I didn't test 2.4.1. 2.2.19 was OK. [Thanks the Cc: I'm not on the list.] Regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu WWW-Home: http://www.kfki.hu/~kadlec Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary From owner-netdev@oss.sgi.com Sun Apr 8 00:30:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f387UxK06654 for netdev-outgoing; Sun, 8 Apr 2001 00:30:59 -0700 Received: from laurin.munich.netsurf.de (laurin.munich.netsurf.de [194.64.166.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f387UvM06651 for ; Sun, 8 Apr 2001 00:30:57 -0700 Received: from fred.muc.de (noidentity@ns1110.munich.netsurf.de [195.180.235.110]) by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id JAA13213; Sun, 8 Apr 2001 09:30:43 +0200 (MET DST) Received: by fred.muc.de (Postfix, from userid 500) id 8BD8DE3CCD; Sun, 8 Apr 2001 09:39:30 +0200 (CEST) Date: Sun, 8 Apr 2001 09:39:30 +0200 From: Andi Kleen To: Jozsef Kadlecsik Cc: netdev@oss.sgi.com Subject: Re: 2.4.x crashes due to an IPv6 packet with invalid length Message-ID: <20010408093930.A3149@fred.local> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from kadlec@blackhole.kfki.hu on Fri, Apr 06, 2001 at 01:10:46PM +0200 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Fri, Apr 06, 2001 at 01:10:46PM +0200, Jozsef Kadlecsik wrote: > Echo Request (1st fragment) is: > > IPv6 Header > Version = 6 > Traffic Class = 0 > FlowLabel = 0 > PayloadLength = 527 (not multiple of 8 octets) > NextHeader = 56 (Fragment Header) 44 would be fragment header, 56 is TLSP (whatever that is) > SourceAddress = Tester Link Local Address > DestinationAddress = Target Link Local Address > > Fragment Header > NextHeader = 58 (ICMP) > FragmentOffset = 0 (1st fragment) > MFlag = 1 (more fragment) > > The last messages before the oops are: > > Warning: kfree_skb passed an skb still on a list (from xxxxxx) > > and it is from the kfree_skb called from ip6_frag_queue in reassemmbly.c > > I hope this helps to find the bug (2.2.19 is OK). I tried to reproduce it on 2.4.0, but didn't succeed. Could you send me the decoded oops you get and a tcpdump binary dump of the packet? Also what compiler are you using? -Andi From owner-netdev@oss.sgi.com Mon Apr 9 09:04:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f39G46H10212 for netdev-outgoing; Mon, 9 Apr 2001 09:04:06 -0700 Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f39G45M10209 for ; Mon, 9 Apr 2001 09:04:05 -0700 Received: from esvir07nok.ntc.nokia.com (esvir07nokt.ntc.nokia.com [172.21.143.39]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f39G4MH14880 for ; Mon, 9 Apr 2001 19:04:22 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir07nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 9 Apr 2001 19:03:46 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 9 Apr 2001 19:03:46 +0300 Message-ID: <2D6CADE9B0C6D411A27500508BB3CBD063CF07@eseis15nok> From: Imran.Patel@nokia.com To: netfilter-devel@us5.samba.org Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: skb allocation problems Date: Mon, 9 Apr 2001 19:03:46 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk hello all, For the past week, i am having problems with (possibly BUGGY) memory allocation by the kernel in my NAT-PT module. I posted this to netdev before but did not get any response. So, here i am with some more proof:) In my IPV6-IPV4 translator module, i capture an IPV4 packet by registering at the netfilter pre-routing hook, i translate it to an IPV6 packet and allocate a new skb for the translated packet and put the packet back in the IPV6 stack...but when i allocate the skb for the translated packet, i start getting the problems. A call to alloc_skb gives me the memory area that is already being pointed by the IPV4 packet which came into the hook... I have written a test module which closely mirrors what my code tries to do(attached below). This is what i get: PRE_R: old skb:c371ee40 new skb:c371ee30 <7>NAT: 3 dropping untracked packet c350fa00 1 192.168.102.22 -> 192.168.102.29 The above message was generated by sending a udp packet from a simple udp client on the host 192.168.102.29 to 192.168.102.22. The test module was on the host 192.168.102.22. As you can see the memory allocated to new skb is already being pointed to by the packet that came in (old skb). Isn't that strange/BUGGY ?? And regarding the netfilter message, the packet that is being dropped by netfilter is an ICMP protocol unreachable message since there is no udp server listening on 192.168.102.29. Why conntrack drops the icmp error packet is a question for the netfilter guys:) I have been fighting this bug or whatever it is for a week now and i can't get anywhere. And i cannot produce this behaviour reliably i.e. this test module allocates different memory area most of the time & seems to work fine but when it goes bad, it keeps on allocating the same overlapping addresses...and never stops misbehaving until i reboot the machine.... Any help would be appreciated. PS: I am not on the linux-kernel mailing list & yes, i use the 2.4.1 kernel. TIA, imran ------------------------- #define __KERNEL__ #define MODULE #include #include #include static unsigned int prehook(unsigned int hook, struct sk_buff **pskb, const struct net_device *indev, const struct net_device *outdev, int (*okfn)(struct sk_buff *)) { struct sk_buff *skb; printk("\nPRE_R: old skb:%p", (*pskb)->data); /* translation happens in the real code here */ skb = alloc_skb((*pskb)->len, GFP_ATOMIC); if(!skb) printk("alloc failed"); skb_reserve(skb, 16); printk(" new skb:%p", skb->data); kfree_skb(skb); /* actually it is something like this in my real code: kfree(*pskb); return NF_STOLEN; */ return NF_ACCEPT; } static struct nf_hook_ops pre = { {NULL, NULL}, /* link list */ prehook, /* the hook fn */ PF_INET, /* protocol family */ NF_IP_PRE_ROUTING, /* hook no */ NF_IP_PRI_CONNTRACK /* priority */ }; static int init_module(void) { nf_register_hook(&pre); } static void cleanup_module(void) { nf_unregister_hook(&pre); } From owner-netdev@oss.sgi.com Mon Apr 9 14:09:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f39L9Mo17588 for netdev-outgoing; Mon, 9 Apr 2001 14:09:22 -0700 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f39L9KM17585 for ; Mon, 9 Apr 2001 14:09:20 -0700 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA13393 for ; Mon, 9 Apr 2001 17:09:20 -0400 (EDT) Received: from nc8220exchange.ral.lucent.com (h135-92-100-21.lucent.com [135.92.100.21]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA13387 for ; Mon, 9 Apr 2001 17:09:19 -0400 (EDT) content-class: urn:content-classes:message Subject: Kernel Panic for FTP with FreeBSD MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 9 Apr 2001 17:09:19 -0400 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Linux Hardware/Software IP Stack Integration for a TOE Thread-Index: AcC4ix6lOUkN/tU8SNKH6uWkDYYATQIqVNbQ From: "Gregory Parrott" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f39L9LM17586 Sender: owner-netdev@oss.sgi.com Precedence: bulk I was surprised that I only received a few replies to my original note... oh, well. WARNING: long post follows. I apologize, but I could use some help. I am running mostly vanilla 2.2.14 (I say mostly because I have modified a few routines to be able to printk some useful data.) The scenario is that I am running my TOE in "dumb" packet mode and passing it IP data that it then sends on the network. When we do Linux-to-Linux FTP sessions, everything works great. However, when we try FreeBSD-to-Linux, the Linux machine panics. At the packet layer, FreeBSD has sent a SYN and Linux attempts to send a SYN/ACK back. Once the transmit complete interrupt kicks in, we crash trying to free the skb. The difference between the Linux SYN and the FreeBSD SYN is essentially FreeBSD does not send SACK, timestamp, window scale, and a null that Linux sends for TCP options. Here is a sample of what I get on the serial console... WaveNICHandleRawReceives: TotalPacketLength=60 DataLength=46 WaveNICHandleRawReceives: EnetHdr: 00 00 1d 31 da b8 00 60 1d 09 00 01 08 00 WaveNICHandleRawReceives: 0: 45 00 00 2e 40 15 40 00 40 06 d2 42 0a 0a 0a 1a WaveNICHandleRawReceives: 16: 0a 0a 0a 45 04 00 00 15 72 e8 1a da 00 00 00 00 WaveNIC: Entering wnic_DevStartTransmit line 857 wnic_DevStartTransmit: Socket Buffer Address cea8c370 Next Socket buffer 00000000 Previous Socket buffer 00000000 Socket buffer list 00000000 Socket cf710f70 Pointer to Device ce8a5830 Data length 58 Pointer to Head ce8a5c70 Pointer to Tail ce8a5d20 Pointer to Data ce8a5ce6 Pointer to End ce8a5d20 Protocol 0x8 Data=00-00-1d-31-da-c6-00-00-1d-31-da-b8 Data=08-00-45-00-00-2c-00-b9-40-00-40-06 Data=11-a1-0a-0a-0a-45-0a-0a-0a-1a-00-15 WaveNICSendPackets: Packet from IP, Length=58 VirtualAddress=ce8a5ce6 SegmentLength=176 WaveNICSendPacket: Type = RAW_IP WaveNICSendPacket: FragmentCount=1, Fragment1 VirtualAddress=ce8a5cf0 WaveNICSendPacket: Packet = cea8c370. WaveNICSendPacket: 45 00 00 2c 00 b9 40 00 40 06 11 a1 0a 0a 0a 45 WaveNICSendPacket: 0a 0a 0a 1a 00 15 04 00 19 ae 29 89 72 e8 1a db WaveNICSendPacket: 60 12 7d 78 1d 1c 00 00 02 04 05 b4 01 00 00 00 WaveNICSendPacket: 00 00 00 00 00 00 00 00 4c 00 08 00 3c 00 02 00 WaveNICSendPacket: 63 1d 00 04 10 00 2e 00 00 00 00 08 01 00 00 00 WaveNICCompleteRawSendData: PacketType=RAW_IP OsFreePacket: Socket Buffer Address cea8c370 Next Socket buffer 00000000 Previous Socket buffer 00000000 Socket buffer list 00000000 Socket cf710f70 Pointer to Device ce8a5830 Data length 58 Pointer to Head ce8a5c70 Pointer to Tail ce8a5d20 Pointer to Data ce8a5ce6 Pointer to End ce8a5d20 Protocol 0x8 Data=00-00-1d-31-da-c6-00-00-1d-31-45-00 Data=00-2c-00-b9-40-00-40-06-11-a1-0a-0a Data=0a-45-0a-0a-0a-1a-00-15-04-00-19-ae __kfree_skb_wgp: Entering __kfree_skb(). __kfree_skb_wgp: Calling dst_release(cd1e1400). __kfree_skb_wgp: Calling skb->destructor(cea8c370). __kfree_skb_wgp: Calling skb_headerinit(cea8c370, NULL, 0). __kfree_skb_wgp: Calling kfree_skbmem_wgp(cea8c370). Entering kfree_skbmem_wgp. kfree_skbmem_wgp: calling kfree(ce8a5c70). Unable to handle kernel paging request at virtual address 030a0114 This is meant to illustrate the SYN coming in, the SYN/ACK going out, followed by the attempted kfree_skb. You will notice that the data looks a bit different when I print the skb structure the second time. This is because I have to align the IP data on an 8-byte boundary prior to asking the adapter to move the data over. We do not change any fields in the skb for this. Not a problem for Linux-to-Linux FTP (or more accurately TCP session establishment.) Why does FreeBSD give us a fit? Finally, I'll include the ksymoops output. I have been looking at this for several days now and have not made any real progress (although I have learned an awful lot about setting up a serial console and making kernel routines visible to modules!) Obviously, ecx has a bad value in it. My next steps are to continue digging deeper into kfree(), but I was hoping someone could possibly shed some light to help speed things up if they have previously seen this kind of error. [root@gusgus AdapterDriver]# ksymoops -k symbols.txt ftpwgp2.oops ksymoops 0.7c on i686 2.2.14wgp. Options used -V (default) -k symbols.txt (specified) -l /proc/modules (default) -o /lib/modules/2.2.14wgp/ (default) -m /usr/src/linux/System.map (default) Unable to handle kernel paging request at virtual address 030a0114 current->tss.cr3 = 00101000, %cr3 = 00101000 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010082 eax: 0000010c ebx: cffff1a0 ecx: 030a010c edx: ce8a5d7c esi: ce8a5c70 edi: 00000002 ebp: c023bdb0 esp: c023bd60 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, process nr: 0, stackpage=c023b000) Stack: cea8c3cc c023bdb0 ce8a5d7c c024ef83 c014f1e4 ce8a5c70 c01eb480 ce8a5c70 cea8c370 c014f3ae cea8c370 c01eb680 cea8c370 00000024 00000003 d093fcd0 cea8c370 00000001 cea8c370 cc622000 c023bdc8 d0945a3a cea8c370 ca8bc000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 69 08 81 fd 2b 2f c3 a5 0f 85 d1 00 00 00 8b 69 0c 85 ed >>EIP; c0122770 <===== Trace; c014f1e4 Trace; c01eb480 Trace; c014f3ae <__kfree_skb_wgp+e6/f8> Trace; c01eb680 Trace; d093fcd0 <[wnp1_d]OsFreePacket+160/180> Trace; d0945a3a <[wnp1_d]WaveNICCompleteRawSendData+6a/90> Trace; d094be88 <[wnp1_d]HandleBufReadDone+38/a0> Trace; d094b077 <[wnp1_d]TA1000DequeueOds+2d7/540> Trace; d0994000 <.bss.end+31a1/????> Trace; c016c45d Trace; d0945997 <[wnp1_d]WaveNICISR+87/c0> Trace; d0994000 <.bss.end+31a1/????> Trace; d093f56f <[wnp1_d]wnic_DevInterrupt+f/20> Trace; c010b1dd Trace; c010afa2 Trace; c010b303 Trace; c010afe0 Trace; c016c701 Trace; c0151210 Trace; c01198b9 Trace; c010b31a Trace; c010afe0 Trace; c01086cd Trace; c0106000 Trace; c01086f0 Trace; c010a1a8 Trace; c0106000 Trace; c0106077 Trace; c0106000 Trace; c0100175 Code; c0122770 00000000 <_EIP>: Code; c0122770 <===== 0: 8b 69 08 mov 0x8(%ecx),%ebp <===== Code; c0122773 3: 81 fd 2b 2f c3 a5 cmp $0xa5c32f2b,%ebp Code; c0122779 9: 0f 85 d1 00 00 00 jne e0 <_EIP+0xe0> c0122850 Code; c012277f f: 8b 69 0c mov 0xc(%ecx),%ebp Code; c0122782 12: 85 ed test %ebp,%ebp Aiee, killing interrupt handler Kernel panic: Attempted to kill the idle task! In swapper task - not syncing [root@gusgus AdapterDriver]# -----Original Message----- From: Gregory Parrott Sent: Thursday, March 29, 2001 3:02 PM To: netdev@oss.sgi.com Subject: Linux Hardware/Software IP Stack Integration for a TOE Hello, I have been a lurker on this netdev list for the last 6 months and have learned a lot by simply watching the e-mails go by. I am quite impressed with the knowledge floating around out there. Now I need to ask for some advice on how to approach my current problem. I am developing a device driver that supports an adapter that has its own TCP/UDP/ICMP/IP stack onboard in silicon (some may refer to this as a transport offload engine). My challenge is to have the hardware stack(s) co-exist with the Linux software stack which will have to be used to support "conventional" NICs. Since we want this to be transparent to users at the socket layer (the interface to the chip is actual socket calls - socket, bind, listen, etc. along with support functions and methods for transmitting raw packets), I believe this to be a non-trivial endeavour. Creating my own protocol family is the easy way out, but not very useful to the tons of existing socket software. I have done some research into the 2.2.14 kernel some time back and now need to move forward with hooking in to the kernel to support my "hardware" stack. The driver work that I have done so far in supporting "conventional" NIC operation has been completed for 2.2.14. You are probably asking why I have not graduated to 2.4 kernels.... my responses would be 1) lack of time in trying to get something to work as it is and 2) sticking with commercially available distributions when I started this project. With this background information, my questions are as follows: 1) Has anyone looked into the problem of supporting multiple stacks in Linux (the existing software stack with one or more hardware stacks)? If so, are the research results available? 2) Is now the time to switch from 2.2.14 to 2.4.x to simplify my life? This will involve converting the existing framework that I have for supporting "conventional" mode. 3) Where is the best place to hook in? I could intercept sys_* calls or I could hook in at the specific protocol (tcp, udp, raw). My feeling is it will be a combination of the two. Multiple stacks introduce interesting problems. When a user app opens a socket, a socket has to be opened on all stacks and simultaneous ops have to be done to each until the socket is bound. Once bound, the others need to be cleaned up. I am sure this is just the tip of the iceberg. Any comments and suggestions would be greatly appreciated. Greg Parrott Optical Area Networking Lucent Technologies 919-838-6095 http://www.lucent-optical.com/oan From owner-netdev@oss.sgi.com Mon Apr 9 23:07:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3A67MC27785 for netdev-outgoing; Mon, 9 Apr 2001 23:07:22 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3A67LM27782 for ; Mon, 9 Apr 2001 23:07:21 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 6C5E51E093; Tue, 10 Apr 2001 08:07:20 +0200 (MEST) Date: Tue, 10 Apr 2001 08:07:13 +0200 From: Andi Kleen To: Imran.Patel@nokia.com Cc: netfilter-devel@us5.samba.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: skb allocation problems Message-ID: <20010410080713.B9549@gruyere.muc.suse.de> References: <2D6CADE9B0C6D411A27500508BB3CBD063CF07@eseis15nok> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2D6CADE9B0C6D411A27500508BB3CBD063CF07@eseis15nok>; from Imran.Patel@nokia.com on Mon, Apr 09, 2001 at 07:03:46PM +0300 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Mon, Apr 09, 2001 at 07:03:46PM +0300, Imran.Patel@nokia.com wrote: > I have written a test module which closely mirrors what my code tries to > do(attached below). This is what i get: > > PRE_R: old skb:c371ee40 new skb:c371ee30 I guess oldskb->len is <=0xc, and the slab allocator packs them near together in the same zone. > printk("\nPRE_R: old skb:%p", (*pskb)->data); > > /* translation happens in the real code here */ > > skb = alloc_skb((*pskb)->len, GFP_ATOMIC); > if(!skb) > printk("alloc failed"); I guess you want a return here. > skb_reserve(skb, 16); You cannot do that if you didn't make sure that the old skb had enough room for it (or rather it'll sometimes panic) -Andi From owner-netdev@oss.sgi.com Tue Apr 10 09:28:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3AGS8X08958 for netdev-outgoing; Tue, 10 Apr 2001 09:28:08 -0700 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3AGS6M08955 for ; Tue, 10 Apr 2001 09:28:07 -0700 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3AGRf217778 for ; Tue, 10 Apr 2001 19:27:41 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 10 Apr 2001 19:27:36 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Tue, 10 Apr 2001 19:27:36 +0300 Message-ID: <2D6CADE9B0C6D411A27500508BB3CBD063CF0D@eseis15nok> From: Imran.Patel@nokia.com To: ak@suse.de, Imran.Patel@nokia.com Cc: netfilter-devel@us5.samba.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: RE: skb allocation problems Date: Tue, 10 Apr 2001 19:27:29 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk > On Mon, Apr 09, 2001 at 07:03:46PM +0300, Imran.Patel@nokia.com wrote: > > I have written a test module which closely mirrors what my > code tries to > > do(attached below). This is what i get: > > > > PRE_R: old skb:c371ee40 new skb:c371ee30 > > I guess oldskb->len is <=0xc, and the slab allocator packs > them near together > in the same zone. nope. i have checked it, the length of the older skb is perfectly ok.....and i even found that this weird behaviour happens only when the old skb buffer length is between 80 and 224 bytes. and apart from this problem, i even found out that when i send a packet >= 186 bytes the kernel allocates a lot of memory in the skb...the output from a simple test module is below: PRE_R: skb: c7aa0da0 skblen: 185 headroom: 32 tailroom: 7 total_len: 224 PRE_R: skb: c7a43020 skblen: 186 headroom: 32 tailroom: 1334 total_len: 1552 This was generated by sending ipv4 ping packets of different sizes...I tested it using 2.4.1 and 2.4.3 on two machines (both dual stack). What the hell's going on :( ??? imran From owner-netdev@oss.sgi.com Tue Apr 10 10:23:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3AHNX110483 for netdev-outgoing; Tue, 10 Apr 2001 10:23:33 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3AHNVM10480 for ; Tue, 10 Apr 2001 10:23:32 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 910D01E167; Tue, 10 Apr 2001 19:23:30 +0200 (MEST) Date: Tue, 10 Apr 2001 19:23:28 +0200 From: Andi Kleen To: Imran.Patel@nokia.com Cc: ak@suse.de, netfilter-devel@us5.samba.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: skb allocation problems Message-ID: <20010410192328.A21887@gruyere.muc.suse.de> References: <2D6CADE9B0C6D411A27500508BB3CBD063CF0D@eseis15nok> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2D6CADE9B0C6D411A27500508BB3CBD063CF0D@eseis15nok>; from Imran.Patel@nokia.com on Tue, Apr 10, 2001 at 07:27:29PM +0300 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Tue, Apr 10, 2001 at 07:27:29PM +0300, Imran.Patel@nokia.com wrote: > > On Mon, Apr 09, 2001 at 07:03:46PM +0300, Imran.Patel@nokia.com wrote: > > > I have written a test module which closely mirrors what my > > code tries to > > > do(attached below). This is what i get: > > > > > > PRE_R: old skb:c371ee40 new skb:c371ee30 > > > > I guess oldskb->len is <=0xc, and the slab allocator packs > > them near together > > in the same zone. > > nope. i have checked it, the length of the older skb is perfectly ok.....and > i even found that this weird behaviour happens only when the old skb buffer > length is between 80 and 224 bytes. Well, I don't know then. You have to debug it. It's probably something stupid (if fundamental services like alloc_skb/kfree_skb were completely buggy someone surely would have noticed earlier) -Andi From owner-netdev@oss.sgi.com Tue Apr 10 11:06:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3AI6SZ12148 for netdev-outgoing; Tue, 10 Apr 2001 11:06:28 -0700 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3AI6RM12145 for ; Tue, 10 Apr 2001 11:06:27 -0700 Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA12419 for ; Tue, 10 Apr 2001 14:06:27 -0400 (EDT) Received: from nc8220exchange.ral.lucent.com (h135-92-100-21.lucent.com [135.92.100.21]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA12404 for ; Tue, 10 Apr 2001 14:06:26 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: Kernel Panic for FTP with FreeBSD MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 10 Apr 2001 14:06:26 -0400 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Linux Hardware/Software IP Stack Integration for a TOE Thread-Index: AcC4ix6lOUkN/tU8SNKH6uWkDYYATQIqVNbQACy4jaA= From: "Gregory Parrott" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f3AI6RM12146 Sender: owner-netdev@oss.sgi.com Precedence: bulk A little more information... with code inlined, it made it a bit difficult to pinpoint. The failing instruction is just inside -> if (slabp->s_magic != SLAB_MAGIC_ALLOC) in __kmem_cache_free(). Code; c0122770 00000000 <_EIP>: Code; c0122770 <===== 0: 8b 69 08 mov 0x8(%ecx),%ebp <===== Code; c0122773 3: 81 fd 2b 2f c3 a5 cmp $0xa5c32f2b,%ebp Code; c0122779 9: 0f 85 d1 00 00 00 jne e0 <_EIP+0xe0> c0122850 The question is how is my code or the hardware corrupting the slab? I'll see what I can figure out in Bovet's book. Thanks in advance. Greg From owner-netdev@oss.sgi.com Tue Apr 10 13:45:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3AKjts15562 for netdev-outgoing; Tue, 10 Apr 2001 13:45:55 -0700 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3AKjsM15559 for ; Tue, 10 Apr 2001 13:45:54 -0700 Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA28393 for ; Tue, 10 Apr 2001 16:45:54 -0400 (EDT) Received: from nc8220exchange.ral.lucent.com (h135-92-100-21.lucent.com [135.92.100.21]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA28388 for ; Tue, 10 Apr 2001 16:45:53 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: Kernel Panic for FTP with FreeBSD MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 10 Apr 2001 16:45:53 -0400 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Linux Hardware/Software IP Stack Integration for a TOE Thread-Index: AcC4ix6lOUkN/tU8SNKH6uWkDYYATQIqVNbQACy4jaAABfAb8A== From: "Gregory Parrott" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f3AKjsM15560 Sender: owner-netdev@oss.sgi.com Precedence: bulk Additional... I enabled SLAB_DEBUG_SUPPORT and got no additional printk's regarding slab debug errors. Greg -----Original Message----- From: Gregory Parrott Sent: Tuesday, April 10, 2001 2:06 PM To: netdev@oss.sgi.com Subject: RE: Kernel Panic for FTP with FreeBSD A little more information... with code inlined, it made it a bit difficult to pinpoint. The failing instruction is just inside -> if (slabp->s_magic != SLAB_MAGIC_ALLOC) in __kmem_cache_free(). Code; c0122770 00000000 <_EIP>: Code; c0122770 <===== 0: 8b 69 08 mov 0x8(%ecx),%ebp <===== Code; c0122773 3: 81 fd 2b 2f c3 a5 cmp $0xa5c32f2b,%ebp Code; c0122779 9: 0f 85 d1 00 00 00 jne e0 <_EIP+0xe0> c0122850 The question is how is my code or the hardware corrupting the slab? I'll see what I can figure out in Bovet's book. Thanks in advance. Greg From owner-netdev@oss.sgi.com Wed Apr 11 10:16:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3BHG9010109 for netdev-outgoing; Wed, 11 Apr 2001 10:16:09 -0700 Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3BHG4M10103 for ; Wed, 11 Apr 2001 10:16:05 -0700 Received: from esvir07nok.ntc.nokia.com (esvir07nokt.ntc.nokia.com [172.21.143.39]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3BHGKH17483 for ; Wed, 11 Apr 2001 20:16:21 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir07nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 11 Apr 2001 20:15:51 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Wed, 11 Apr 2001 20:15:51 +0300 Message-ID: <2D6CADE9B0C6D411A27500508BB3CBD063CF2D@eseis15nok> From: Imran.Patel@nokia.com To: ak@suse.de, Imran.Patel@nokia.com Cc: netfilter-devel@us5.samba.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: RE: skb allocation problems (More Brain damage!) Date: Wed, 11 Apr 2001 20:15:49 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk > Well, I don't know then. You have to debug it. It's probably > something stupid > (if fundamental services like alloc_skb/kfree_skb were > completely buggy > someone surely would have noticed earlier) yep, at first i thought it was because of sume stupidity in my module...but now it seems that actually it is not my code which is doing something stupid....just now i have found out that even simple ping faces similar problems ....here is the output that i get when i ping from the host 192.168.102.29 (runs 2.4.1) to 192.168.102.22 (runs 2.4.3) (Note:I don't insert any kernel modules of my own on these machines): PING 192.168.102.22 (192.168.102.22) from 192.168.102.29 : 100(128) bytes of data. 108 bytes from hobbes.sr.ntc.nokia.com (192.168.102.22): icmp_seq=0 ttl=255 time=36.5 ms wrong data byte #36 should be 0x24 but was 0x45 19 45 d4 3a e 7a a 0 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 45 0 0 80 0 0 40 0 ff 1 2d f8 c0 a8 66 16 c0 a8 66 1d 0 0 0 0 4 c 0 0 19 45 d4 3a e 7a a 0 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b --- 192.168.102.22 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 36.5/36.5/36.5 ms Note that the problem starts with byte #36 which goes on like " 45 0 0 80 0 ......." which is in fact the outer IP header!! So certainly there are buffer overruns on the other end (host 192.168.102.22).... And as a I said earlier, only ping packets with size within certain range create this problem......Something is terribly wrong here!! But as I am not a Linux mm guru, i can't tell what is wrong here! regards, imran From owner-netdev@oss.sgi.com Wed Apr 11 10:20:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3BHKhV10332 for netdev-outgoing; Wed, 11 Apr 2001 10:20:43 -0700 Received: from admin.csn.ul.ie (admin.csn.ul.ie [136.201.105.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3BHKfM10329 for ; Wed, 11 Apr 2001 10:20:42 -0700 Received: from holly.csn.ul.ie (holly [136.201.105.4]) by admin.csn.ul.ie (Postfix) with ESMTP id E270B3019; Wed, 11 Apr 2001 18:20:34 +0100 (IST) Received: from skynet.csn.ul.ie (skynet [136.201.105.2]) by holly.csn.ul.ie (Postfix) with ESMTP id 672672B35A; Wed, 11 Apr 2001 18:20:34 +0100 (IST) Received: by skynet.csn.ul.ie (Postfix, from userid 2139) id 89158A867; Wed, 11 Apr 2001 18:20:29 +0100 (IST) Received: from localhost (localhost [127.0.0.1]) by skynet.csn.ul.ie (Postfix) with ESMTP id 7BA0CA866; Wed, 11 Apr 2001 18:20:29 +0100 (IST) Date: Wed, 11 Apr 2001 18:20:29 +0100 (IST) From: Dave Airlie X-X-Sender: To: Cc: , , , Subject: RE: skb allocation problems (More Brain damage!) In-Reply-To: <2D6CADE9B0C6D411A27500508BB3CBD063CF2D@eseis15nok> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk What compiler are you using to compile the kernel? Dave. On Wed, 11 Apr 2001 Imran.Patel@nokia.com wrote: > > Well, I don't know then. You have to debug it. It's probably > > something stupid > > (if fundamental services like alloc_skb/kfree_skb were > > completely buggy > > someone surely would have noticed earlier) > > yep, at first i thought it was because of sume stupidity in my module...but > now it seems that actually it is not my code which is doing something > stupid....just now i have found out that even simple ping faces similar > problems ....here is the output that i get when i ping from the host > 192.168.102.29 (runs 2.4.1) to 192.168.102.22 (runs 2.4.3) (Note:I don't > insert any kernel modules of my own on these machines): > > > PING 192.168.102.22 (192.168.102.22) from 192.168.102.29 : 100(128) bytes of > data. > 108 bytes from hobbes.sr.ntc.nokia.com (192.168.102.22): icmp_seq=0 ttl=255 > time=36.5 ms > wrong data byte #36 should be 0x24 but was 0x45 > 19 45 d4 3a e 7a a 0 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 > 1a 1b 1c 1d 1e 1f > 20 21 22 23 45 0 0 80 0 0 40 0 ff 1 2d f8 c0 a8 66 16 c0 a8 66 1d 0 > 0 0 0 4 c 0 0 > 19 45 d4 3a e 7a a 0 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 > 1a 1b > > --- 192.168.102.22 ping statistics --- > 1 packets transmitted, 1 packets received, 0% packet loss > round-trip min/avg/max = 36.5/36.5/36.5 ms > > > Note that the problem starts with byte #36 which goes on like " 45 0 0 80 0 > ......." which is in fact the outer IP header!! So certainly there are > buffer overruns on the other end (host 192.168.102.22).... > > And as a I said earlier, only ping packets with size within certain range > create this problem......Something is terribly wrong here!! But as I am not > a Linux mm guru, i can't tell what is wrong here! > > > regards, > imran > > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied@skynet.ie pam_smb / Linux DecStation / Linux VAX / ILUG person From owner-netdev@oss.sgi.com Wed Apr 11 10:24:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3BHOlr10783 for netdev-outgoing; Wed, 11 Apr 2001 10:24:47 -0700 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3BHOgM10773 for ; Wed, 11 Apr 2001 10:24:42 -0700 Received: from esvir06nok.ntc.nokia.com (esvir06nokt.ntc.nokia.com [172.21.143.38]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3BHOkS12368 for ; Wed, 11 Apr 2001 20:24:46 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 11 Apr 2001 20:24:38 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 11 Apr 2001 20:24:38 +0300 Message-ID: <2D6CADE9B0C6D411A27500508BB3CBD063CF2E@eseis15nok> From: Imran.Patel@nokia.com To: airlied@csn.ul.ie, Imran.Patel@nokia.com Cc: netfilter-devel@us5.samba.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: RE: skb allocation problems (More Brain damage!) Date: Wed, 11 Apr 2001 20:24:38 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk > -----Original Message----- > From: ext Dave Airlie [mailto:airlied@csn.ul.ie] > Sent: 11. April 2001 20:20 > To: Imran.Patel@nokia.com > Cc: ak@suse.de; netfilter-devel@us5.samba.org; netdev@oss.sgi.com; > linux-kernel@vger.kernel.org > Subject: RE: skb allocation problems (More Brain damage!) > > > > What compiler are you using to compile the kernel? gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) imran From owner-netdev@oss.sgi.com Wed Apr 11 10:47:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3BHlrC12055 for netdev-outgoing; Wed, 11 Apr 2001 10:47:53 -0700 Received: from the.jukie.net (cr502987-a.rchrd1.on.wave.home.com [24.42.47.5]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3BHlpM12052 for ; Wed, 11 Apr 2001 10:47:51 -0700 Received: from localhost (bart@localhost) by the.jukie.net (8.9.3/8.9.3) with ESMTP id NAA32190; Wed, 11 Apr 2001 13:47:18 -0400 Date: Wed, 11 Apr 2001 13:47:18 -0400 (EDT) From: Bart Trojanowski X-Sender: To: cc: , , , LKML Subject: RE: skb allocation problems (More Brain damage!) In-Reply-To: <2D6CADE9B0C6D411A27500508BB3CBD063CF2D@eseis15nok> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Coudl the problem be in the NIC driver not in the alloc_skb? I have used both 2.4.{1,3} for some time and never seen this corruption. I use ping -f with various packet sizes for stress testing my IPSec boxes... these do quite a bit of extra skb creation as an IPSec header sometimes does not fit in the original skb. No problems yet. My gut tells me to blame the NIC driver of the NIC itself. B. On Wed, 11 Apr 2001, Imran.Patel@nokia.com wrote: > > Well, I don't know then. You have to debug it. It's probably > > something stupid > > (if fundamental services like alloc_skb/kfree_skb were > > completely buggy > > someone surely would have noticed earlier) > > yep, at first i thought it was because of sume stupidity in my module...but > now it seems that actually it is not my code which is doing something > stupid....just now i have found out that even simple ping faces similar > problems ....here is the output that i get when i ping from the host > 192.168.102.29 (runs 2.4.1) to 192.168.102.22 (runs 2.4.3) (Note:I don't > insert any kernel modules of my own on these machines): > > > PING 192.168.102.22 (192.168.102.22) from 192.168.102.29 : 100(128) bytes of > data. > 108 bytes from hobbes.sr.ntc.nokia.com (192.168.102.22): icmp_seq=0 ttl=255 > time=36.5 ms > wrong data byte #36 should be 0x24 but was 0x45 > 19 45 d4 3a e 7a a 0 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 > 1a 1b 1c 1d 1e 1f > 20 21 22 23 45 0 0 80 0 0 40 0 ff 1 2d f8 c0 a8 66 16 c0 a8 66 1d 0 > 0 0 0 4 c 0 0 > 19 45 d4 3a e 7a a 0 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 > 1a 1b > > --- 192.168.102.22 ping statistics --- > 1 packets transmitted, 1 packets received, 0% packet loss > round-trip min/avg/max = 36.5/36.5/36.5 ms > > > Note that the problem starts with byte #36 which goes on like " 45 0 0 80 0 > ......." which is in fact the outer IP header!! So certainly there are > buffer overruns on the other end (host 192.168.102.22).... > > And as a I said earlier, only ping packets with size within certain range > create this problem......Something is terribly wrong here!! But as I am not > a Linux mm guru, i can't tell what is wrong here! > > > regards, > imran > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- WebSig: http://www.jukie.net/~bart/sig/ From owner-netdev@oss.sgi.com Wed Apr 11 11:23:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3BIN2a13722 for netdev-outgoing; Wed, 11 Apr 2001 11:23:02 -0700 Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3BIN0M13719 for ; Wed, 11 Apr 2001 11:23:00 -0700 Received: from esvir06nok.ntc.nokia.com (esvir06nokt.ntc.nokia.com [172.21.143.38]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3BIN4S24328 for ; Wed, 11 Apr 2001 21:23:04 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 11 Apr 2001 21:22:37 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 11 Apr 2001 21:22:37 +0300 Message-ID: <2D6CADE9B0C6D411A27500508BB3CBD063CF2F@eseis15nok> From: Imran.Patel@nokia.com To: Imran.Patel@nokia.com Cc: netfilter-devel@us5.samba.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: RE: skb allocation problems (More Brain damage!) Date: Wed, 11 Apr 2001 21:22:36 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk > Coudl the problem be in the NIC driver not in the alloc_skb? No, i don't think so...i got the dump of the packet at the local_out and post routing hooks....& found it in bad shape there. Here it is what it looks like: 45 0 0 80 0 0 40 0 ff 1 2d f8 c0 a8 66 16 c0 a8 66 1d 0 0 e4 48 11 d 0 0 14 5d d4 3a 63 1 a 0 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 45 0 0 80 0 0 40 0 ff 1 2d f8 c0 a8 66 16 c0 a8 66 1d 0 0 0 0 11 d 0 0 14 5d d4 3a 63 1 a 0 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 > My gut tells me to blame the NIC driver of the NIC itself. btw, the card is Intel Ethernet Pro 100.. imran > On Wed, 11 Apr 2001, Imran.Patel@nokia.com wrote: > > > > Well, I don't know then. You have to debug it. It's probably > > > something stupid > > > (if fundamental services like alloc_skb/kfree_skb were > > > completely buggy > > > someone surely would have noticed earlier) > > > > yep, at first i thought it was because of sume stupidity in > my module...but > > now it seems that actually it is not my code which is doing > something > > stupid....just now i have found out that even simple ping > faces similar > > problems ....here is the output that i get when i ping from the host > > 192.168.102.29 (runs 2.4.1) to 192.168.102.22 (runs 2.4.3) > (Note:I don't > > insert any kernel modules of my own on these machines): > > > > > > PING 192.168.102.22 (192.168.102.22) from 192.168.102.29 : > 100(128) bytes of > > data. > > 108 bytes from hobbes.sr.ntc.nokia.com (192.168.102.22): > icmp_seq=0 ttl=255 > > time=36.5 ms > > wrong data byte #36 should be 0x24 but was 0x45 > > 19 45 d4 3a e 7a a 0 8 9 a b c d e f 10 11 12 13 14 15 > 16 17 18 19 > > 1a 1b 1c 1d 1e 1f > > 20 21 22 23 45 0 0 80 0 0 40 0 ff 1 2d f8 c0 a8 66 16 > c0 a8 66 1d 0 > > 0 0 0 4 c 0 0 > > 19 45 d4 3a e 7a a 0 8 9 a b c d e f 10 11 12 13 14 15 > 16 17 18 19 > > 1a 1b > > > > --- 192.168.102.22 ping statistics --- > > 1 packets transmitted, 1 packets received, 0% packet loss > > round-trip min/avg/max = 36.5/36.5/36.5 ms > > > > > > Note that the problem starts with byte #36 which goes on > like " 45 0 0 80 0 > > ......." which is in fact the outer IP header!! So > certainly there are > > buffer overruns on the other end (host 192.168.102.22).... > > > > And as a I said earlier, only ping packets with size within > certain range > > create this problem......Something is terribly wrong here!! > But as I am not > > a Linux mm guru, i can't tell what is wrong here! > > > > > > regards, > > imran > > > > - > > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > > -- > WebSig: http://www.jukie.net/~bart/sig/ > > From owner-netdev@oss.sgi.com Wed Apr 11 11:25:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3BIPIf13990 for netdev-outgoing; Wed, 11 Apr 2001 11:25:18 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3BIPHM13986 for ; Wed, 11 Apr 2001 11:25:17 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id D3CA01E287; Wed, 11 Apr 2001 20:25:16 +0200 (MEST) Date: Wed, 11 Apr 2001 20:25:12 +0200 From: Andi Kleen To: Bart Trojanowski Cc: Imran.Patel@nokia.com, ak@suse.de, netfilter-devel@us5.samba.org, netdev@oss.sgi.com, LKML Subject: Re: skb allocation problems (More Brain damage!) Message-ID: <20010411202512.A15011@gruyere.muc.suse.de> References: <2D6CADE9B0C6D411A27500508BB3CBD063CF2D@eseis15nok> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bart@jukie.net on Wed, Apr 11, 2001 at 01:47:18PM -0400 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Wed, Apr 11, 2001 at 01:47:18PM -0400, Bart Trojanowski wrote: > > Coudl the problem be in the NIC driver not in the alloc_skb? I have used > both 2.4.{1,3} for some time and never seen this corruption. I use ping > -f with various packet sizes for stress testing my IPSec boxes... these do > quite a bit of extra skb creation as an IPSec header sometimes does not > fit in the original skb. No problems yet. > > My gut tells me to blame the NIC driver of the NIC itself. The NIC is not directly involved in alloc_skb() (except maybe if it corrupts internal data structures of the allocator) -Andi From owner-netdev@oss.sgi.com Wed Apr 11 11:29:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3BIT7T14415 for netdev-outgoing; Wed, 11 Apr 2001 11:29:07 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3BIT6M14412 for ; Wed, 11 Apr 2001 11:29:06 -0700 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 30A1B1E29A; Wed, 11 Apr 2001 20:29:05 +0200 (MEST) Date: Wed, 11 Apr 2001 20:28:31 +0200 From: Andi Kleen To: Imran.Patel@nokia.com Cc: ak@suse.de, netfilter-devel@us5.samba.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: skb allocation problems (More Brain damage!) Message-ID: <20010411202831.A15029@gruyere.muc.suse.de> References: <2D6CADE9B0C6D411A27500508BB3CBD063CF2D@eseis15nok> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2D6CADE9B0C6D411A27500508BB3CBD063CF2D@eseis15nok>; from Imran.Patel@nokia.com on Wed, Apr 11, 2001 at 08:15:49PM +0300 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Wed, Apr 11, 2001 at 08:15:49PM +0300, Imran.Patel@nokia.com wrote: > And as a I said earlier, only ping packets with size within certain range > create this problem......Something is terribly wrong here!! But as I am not > a Linux mm guru, i can't tell what is wrong here! What you can try is to turn on slab debugging. Set the FORCED_DEBUG define in mm/slab.c to one and recompile. Does it change any pattern when you dump the data in the skbs or pings? If yes someone is playing with already freed packets. Furthermore you can instrument other parts with good old printk. And what NIC are you using btw? -Andi From owner-netdev@oss.sgi.com Wed Apr 11 12:03:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3BJ3EL15483 for netdev-outgoing; Wed, 11 Apr 2001 12:03:14 -0700 Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3BJ3CM15480 for ; Wed, 11 Apr 2001 12:03:12 -0700 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3BJ3w801746 for ; Wed, 11 Apr 2001 22:03:58 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 11 Apr 2001 22:03:07 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 11 Apr 2001 22:02:47 +0300 Message-ID: <2D6CADE9B0C6D411A27500508BB3CBD063CF32@eseis15nok> From: Imran.Patel@nokia.com To: ak@suse.de, Imran.Patel@nokia.com Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: RE: skb allocation problems (More Brain damage!) Date: Wed, 11 Apr 2001 22:02:46 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk > What you can try is to turn on slab debugging. Set the FORCED_DEBUG > define in mm/slab.c to one and recompile. Does it change any pattern > when you dump the data in the skbs or pings? > If yes someone is playing with already freed packets. I think the dump that i got suggests something more strange than that. This is what i can make of the dump: this is the ip header (with src addr: 192.168.102.22 and dest addr: 192.168.10.29) 45 0 0 80 0 0 40 0 ff 1 2d f8 c0 a8 66 16 c0 a8 66 1d this is the icmp header (echo reply) 0 0 e4 48 11 d 0 0 the regular ping data follows 14 5d d4 3a 63 1 a 0 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 Now, it is expecting 24, 25, 26,.....but the outer ip & icmp header and data (as above) follows again.... 45 0 0 80 0 0 40 0 ff 1 2d f8 c0 a8 66 16 c0 a8 66 1d 0 0 0 0 11 d 0 0 14 5d d4 3a 63 1 a 0 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 it is very hard to imagine the scenario which can lead to this... I will try your suggestion.. > And what NIC are you using btw? as i said earlier, Intel Ethernet Pro 100... imran From owner-netdev@oss.sgi.com Fri Apr 13 03:38:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3DAcpn07068 for netdev-outgoing; Fri, 13 Apr 2001 03:38:51 -0700 Received: from yoda.planetinternet.be (yoda.planetinternet.be [195.95.30.146]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3DAcnM07065 for ; Fri, 13 Apr 2001 03:38:49 -0700 Received: from dialup.planetinternet.be (postfix@u212-239-144-32.dialup.planetinternet.be [212.239.144.32]) by yoda.planetinternet.be (8.11.1/8.11.1) with ESMTP id f3DAcla14938 for ; Fri, 13 Apr 2001 12:38:47 +0200 Received: by dialup.planetinternet.be (Postfix, from userid 501) id 2D6C0261C5; Fri, 13 Apr 2001 12:38:46 +0200 (CEST) Date: Fri, 13 Apr 2001 12:38:45 +0200 From: Kurt Roeckx To: netdev@oss.sgi.com Subject: Error messages Message-ID: <20010413123845.A9963@ping.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i Sender: owner-netdev@oss.sgi.com Precedence: bulk I'm finding some error messages in my logs, which all seem to be related to the network stack. I'm running 2.4.3. Most of the trafic the box deals with is IPv6. Here are the different errors I found: Apr 6 01:40:49 eu kernel: IPv6: sending pkt_too_big to self Apr 7 17:30:16 eu kernel: KERNEL: assertion (tp->lost_out == 0) failed at tcp_input.c(1202):tcp_remove_reno_sacks Apr 7 17:42:16 eu kernel: icmpv6_send: no reply to icmp error/fragment I saw the first of those a few times, the last of that about 50 times. (I also saw a two ICMPv6 checksum failed messages) Kurt From owner-netdev@oss.sgi.com Sun Apr 15 00:03:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3F734h11675 for netdev-outgoing; Sun, 15 Apr 2001 00:03:04 -0700 Received: from havoc.gtf.org (IDENT:postfix@panic.ohr.gatech.edu [130.207.47.194]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3F730M11671 for ; Sun, 15 Apr 2001 00:03:00 -0700 Received: from mandrakesoft.com (adsl-20-73-169.asm.bellsouth.net [66.20.73.169]) by havoc.gtf.org (Postfix) with ESMTP id 8D7D91F6B; Sun, 15 Apr 2001 03:02:57 -0400 (EDT) Message-ID: <3AD94798.2C31537A@mandrakesoft.com> Date: Sun, 15 Apr 2001 03:02:48 -0400 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4-pre3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Linus Torvalds , "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, mike_phillips@urscorp.com Subject: PATCH 2.4.4.3: remove dev_init_buffers users Content-Type: multipart/mixed; boundary="------------1B380F894FF576A810455199" Sender: owner-netdev@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------1B380F894FF576A810455199 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike Phillips was kind enough to look into the history of dev_init_buffers: > It turned up in 2.1.20, when it used to call skb_queue_head_init > (&dev->buffs[i]) and then was changed to DO NOTHING in 2.1.68. So, this patch removes all users, and marks the function as going away in 2.5. -- Jeff Garzik | "Give a man a fish, and he eats for a day. Teach a Building 1024 | man to fish, and a US Navy submarine will make sure MandrakeSoft | he's never hungry again." -- Chris Neufeld --------------1B380F894FF576A810455199 Content-Type: text/plain; charset=us-ascii; name="initbufs-2.4.4.3.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="initbufs-2.4.4.3.patch" diff -urN linux.vanilla/drivers/char/synclink.c linux.buffers/drivers/char/synclink.c --- linux.vanilla/drivers/char/synclink.c Tue Mar 6 22:44:34 2001 +++ linux.buffers/drivers/char/synclink.c Sun Apr 15 02:54:16 2001 @@ -7344,8 +7344,6 @@ d->tx_timeout = mgsl_sppp_tx_timeout; d->watchdog_timeo = 10*HZ; - dev_init_buffers(d); - if (register_netdev(d) == -1) { printk(KERN_WARNING "%s: register_netdev failed.\n", d->name); sppp_detach(info->netdev); diff -urN linux.vanilla/drivers/net/arcnet/arcnet.c linux.buffers/drivers/net/arcnet/arcnet.c --- linux.vanilla/drivers/net/arcnet/arcnet.c Sat Mar 3 13:55:48 2001 +++ linux.buffers/drivers/net/arcnet/arcnet.c Sun Apr 15 02:54:07 2001 @@ -361,8 +361,6 @@ dev->get_stats = arcnet_get_stats; dev->hard_header = arcnet_header; dev->rebuild_header = arcnet_rebuild_header; - - dev_init_buffers(dev); } diff -urN linux.vanilla/drivers/net/eql.c linux.buffers/drivers/net/eql.c --- linux.vanilla/drivers/net/eql.c Tue Mar 20 15:05:01 2001 +++ linux.buffers/drivers/net/eql.c Sun Apr 15 02:52:25 2001 @@ -240,8 +240,6 @@ * eql-generic values. */ - dev_init_buffers(dev); - /* * Now we undo some of the things that eth_setup does * that we don't like diff -urN linux.vanilla/drivers/net/hamradio/6pack.c linux.buffers/drivers/net/hamradio/6pack.c --- linux.vanilla/drivers/net/hamradio/6pack.c Thu Feb 8 19:32:44 2001 +++ linux.buffers/drivers/net/hamradio/6pack.c Sun Apr 15 02:53:48 2001 @@ -798,8 +798,6 @@ memcpy(dev->broadcast, ax25_bcast, AX25_ADDR_LEN); /* Only activated in AX.25 mode */ memcpy(dev->dev_addr, ax25_test, AX25_ADDR_LEN); /* "" "" "" "" */ - dev_init_buffers(dev); - /* New-style flags. */ dev->flags = 0; diff -urN linux.vanilla/drivers/net/hamradio/baycom_epp.c linux.buffers/drivers/net/hamradio/baycom_epp.c --- linux.vanilla/drivers/net/hamradio/baycom_epp.c Mon Dec 11 16:23:31 2000 +++ linux.buffers/drivers/net/hamradio/baycom_epp.c Sun Apr 15 02:53:54 2001 @@ -1379,8 +1379,6 @@ dev->get_stats = baycom_get_stats; /* Fill in the fields of the device structure */ - dev_init_buffers(dev); - bc->skb = NULL; #if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE) diff -urN linux.vanilla/drivers/net/hamradio/bpqether.c linux.buffers/drivers/net/hamradio/bpqether.c --- linux.vanilla/drivers/net/hamradio/bpqether.c Fri Dec 29 17:35:47 2000 +++ linux.buffers/drivers/net/hamradio/bpqether.c Sun Apr 15 02:53:32 2001 @@ -530,8 +530,6 @@ return -EIO; } - dev_init_buffers(dev); - dev->hard_start_xmit = bpq_xmit; dev->open = bpq_open; dev->stop = bpq_close; diff -urN linux.vanilla/drivers/net/hamradio/dmascc.c linux.buffers/drivers/net/hamradio/dmascc.c --- linux.vanilla/drivers/net/hamradio/dmascc.c Tue Jul 18 19:52:35 2000 +++ linux.buffers/drivers/net/hamradio/dmascc.c Sun Apr 15 02:53:51 2001 @@ -593,7 +593,6 @@ dev->tx_queue_len = 64; memcpy(dev->broadcast, ax25_broadcast, 7); memcpy(dev->dev_addr, ax25_test, 7); - dev_init_buffers(dev); rtnl_lock(); if (register_netdevice(dev)) { printk("dmascc: could not register %s\n", dev->name); diff -urN linux.vanilla/drivers/net/hamradio/hdlcdrv.c linux.buffers/drivers/net/hamradio/hdlcdrv.c --- linux.vanilla/drivers/net/hamradio/hdlcdrv.c Tue Feb 13 16:15:05 2001 +++ linux.buffers/drivers/net/hamradio/hdlcdrv.c Sun Apr 15 02:53:35 2001 @@ -791,7 +791,6 @@ dev->get_stats = hdlcdrv_get_stats; /* Fill in the fields of the device structure */ - dev_init_buffers(dev); s->skb = NULL; diff -urN linux.vanilla/drivers/net/hamradio/mkiss.c linux.buffers/drivers/net/hamradio/mkiss.c --- linux.vanilla/drivers/net/hamradio/mkiss.c Mon Jan 22 16:32:10 2001 +++ linux.buffers/drivers/net/hamradio/mkiss.c Sun Apr 15 02:53:42 2001 @@ -935,8 +935,6 @@ memcpy(dev->broadcast, ax25_bcast, AX25_ADDR_LEN); memcpy(dev->dev_addr, ax25_test, AX25_ADDR_LEN); - dev_init_buffers(dev); - /* New-style flags. */ dev->flags = 0; diff -urN linux.vanilla/drivers/net/hamradio/scc.c linux.buffers/drivers/net/hamradio/scc.c --- linux.vanilla/drivers/net/hamradio/scc.c Tue Mar 20 15:05:00 2001 +++ linux.buffers/drivers/net/hamradio/scc.c Sun Apr 15 02:53:45 2001 @@ -1574,8 +1574,6 @@ static int scc_net_init(struct net_device *dev) { - dev_init_buffers(dev); - dev->tx_queue_len = 16; /* should be enough... */ dev->open = scc_net_open; diff -urN linux.vanilla/drivers/net/hamradio/yam.c linux.buffers/drivers/net/hamradio/yam.c --- linux.vanilla/drivers/net/hamradio/yam.c Tue Feb 13 16:15:05 2001 +++ linux.buffers/drivers/net/hamradio/yam.c Sun Apr 15 02:53:58 2001 @@ -1071,7 +1071,6 @@ dev->hard_start_xmit = yam_send_packet; dev->get_stats = yam_get_stats; - dev_init_buffers(dev); skb_queue_head_init(&yp->send_queue); #if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE) diff -urN linux.vanilla/drivers/net/loopback.c linux.buffers/drivers/net/loopback.c --- linux.vanilla/drivers/net/loopback.c Sun Apr 15 02:37:17 2001 +++ linux.buffers/drivers/net/loopback.c Sun Apr 15 02:52:19 2001 @@ -127,7 +127,5 @@ * Fill in the generic fields of the device structure. */ - dev_init_buffers(dev); - return(0); }; diff -urN linux.vanilla/drivers/net/net_init.c linux.buffers/drivers/net/net_init.c --- linux.vanilla/drivers/net/net_init.c Sun Apr 15 02:37:17 2001 +++ linux.buffers/drivers/net/net_init.c Sun Apr 15 02:52:14 2001 @@ -174,8 +174,6 @@ #if defined(CONFIG_HIPPI) || defined(CONFIG_TR) || defined(CONFIG_NET_FC) static int __register_netdev(struct net_device *dev) { - dev_init_buffers(dev); - if (dev->init && dev->init(dev) != 0) { unregister_netdev(dev); return -EIO; @@ -418,8 +416,6 @@ /* New-style flags. */ dev->flags = IFF_BROADCAST|IFF_MULTICAST; - - dev_init_buffers(dev); } EXPORT_SYMBOL(ether_setup); @@ -446,10 +442,6 @@ /* New-style flags */ dev->flags = IFF_BROADCAST | IFF_MULTICAST; - - dev_init_buffers(dev); - - return; } EXPORT_SYMBOL(fddi_setup); @@ -486,8 +478,6 @@ * static ARP tables. ARP is disabled by hippi_neigh_setup_dev. */ dev->flags = 0; - - dev_init_buffers(dev); } EXPORT_SYMBOL(hippi_setup); #endif /* CONFIG_HIPPI */ @@ -525,8 +515,6 @@ dev->broadcast[0] = 0xFF; dev->flags = IFF_BROADCAST|IFF_MULTICAST|IFF_NOARP; - - dev_init_buffers(dev); } EXPORT_SYMBOL(ltalk_setup); @@ -676,7 +664,6 @@ /* New-style flags. */ dev->flags = IFF_BROADCAST; - dev_init_buffers(dev); } /** diff -urN linux.vanilla/drivers/net/ppp_generic.c linux.buffers/drivers/net/ppp_generic.c --- linux.vanilla/drivers/net/ppp_generic.c Sun Feb 4 13:05:30 2001 +++ linux.buffers/drivers/net/ppp_generic.c Sun Apr 15 02:54:04 2001 @@ -848,8 +848,6 @@ dev->tx_queue_len = 3; dev->type = ARPHRD_PPP; dev->flags = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST; - - dev_init_buffers(dev); return 0; } diff -urN linux.vanilla/drivers/net/shaper.c linux.buffers/drivers/net/shaper.c --- linux.vanilla/drivers/net/shaper.c Tue Feb 13 16:15:05 2001 +++ linux.buffers/drivers/net/shaper.c Sun Apr 15 02:54:00 2001 @@ -651,8 +651,6 @@ * Intialise the packet queues */ - dev_init_buffers(dev); - /* * Handlers for when we attach to a device. */ diff -urN linux.vanilla/drivers/net/slip.c linux.buffers/drivers/net/slip.c --- linux.vanilla/drivers/net/slip.c Tue Feb 13 16:15:05 2001 +++ linux.buffers/drivers/net/slip.c Sun Apr 15 02:51:51 2001 @@ -648,8 +648,6 @@ SET_MODULE_OWNER(dev); - dev_init_buffers(dev); - /* New-style flags. */ dev->flags = IFF_NOARP|IFF_POINTOPOINT|IFF_MULTICAST; diff -urN linux.vanilla/drivers/net/tun.c linux.buffers/drivers/net/tun.c --- linux.vanilla/drivers/net/tun.c Tue Feb 13 16:15:05 2001 +++ linux.buffers/drivers/net/tun.c Sun Apr 15 02:54:13 2001 @@ -147,8 +147,6 @@ dev->type = ARPHRD_PPP; dev->flags = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST; dev->tx_queue_len = 10; - - dev_init_buffers(dev); break; case TUN_TAP_DEV: diff -urN linux.vanilla/drivers/net/wan/cycx_x25.c linux.buffers/drivers/net/wan/cycx_x25.c --- linux.vanilla/drivers/net/wan/cycx_x25.c Tue Mar 20 15:05:01 2001 +++ linux.buffers/drivers/net/wan/cycx_x25.c Sun Apr 15 02:52:29 2001 @@ -492,7 +492,6 @@ dev->tx_queue_len = 10; /* Initialize socket buffers */ - dev_init_buffers(dev); set_chan_state(dev, WAN_DISCONNECTED); return 0; diff -urN linux.vanilla/drivers/net/wan/dlci.c linux.buffers/drivers/net/wan/dlci.c --- linux.vanilla/drivers/net/wan/dlci.c Sat Mar 3 13:55:48 2001 +++ linux.buffers/drivers/net/wan/dlci.c Sun Apr 15 02:52:33 2001 @@ -575,8 +575,6 @@ dev->addr_len = sizeof(short); memset(dev->dev_addr, 0, sizeof(dev->dev_addr)); - dev_init_buffers(dev); - return(0); } diff -urN linux.vanilla/drivers/net/wan/hdlc.c linux.buffers/drivers/net/wan/hdlc.c --- linux.vanilla/drivers/net/wan/hdlc.c Tue Mar 6 22:44:36 2001 +++ linux.buffers/drivers/net/wan/hdlc.c Sun Apr 15 02:53:25 2001 @@ -1292,8 +1292,6 @@ pvc->netdev.tx_queue_len = 0; pvc->netdev.flags = IFF_POINTOPOINT; - dev_init_buffers(&pvc->netdev); - pvc->master = hdlc; *(u16*)pvc->netdev.dev_addr = htons(dlci); dlci_to_q922(pvc->netdev.broadcast, dlci); @@ -1393,7 +1391,6 @@ dev->flags = IFF_POINTOPOINT | IFF_NOARP; - dev_init_buffers(dev); return 0; } @@ -1423,7 +1420,6 @@ if (result != 0) return -EIO; - dev_init_buffers(dev); MOD_INC_USE_COUNT; return 0; } diff -urN linux.vanilla/drivers/net/wan/hostess_sv11.c linux.buffers/drivers/net/wan/hostess_sv11.c --- linux.vanilla/drivers/net/wan/hostess_sv11.c Tue Mar 6 22:44:36 2001 +++ linux.buffers/drivers/net/wan/hostess_sv11.c Sun Apr 15 02:52:40 2001 @@ -347,7 +347,6 @@ d->do_ioctl = hostess_ioctl; #ifdef LINUX_21 d->neigh_setup = hostess_neigh_setup_dev; - dev_init_buffers(d); #else d->init = return_0; #endif diff -urN linux.vanilla/drivers/net/wan/lapbether.c linux.buffers/drivers/net/wan/lapbether.c --- linux.vanilla/drivers/net/wan/lapbether.c Mon Jan 22 16:32:10 2001 +++ linux.buffers/drivers/net/wan/lapbether.c Sun Apr 15 02:52:42 2001 @@ -400,8 +400,6 @@ return -EIO; } - dev_init_buffers(dev); - dev->hard_start_xmit = lapbeth_xmit; dev->open = lapbeth_open; dev->stop = lapbeth_close; diff -urN linux.vanilla/drivers/net/wan/sdla.c linux.buffers/drivers/net/wan/sdla.c --- linux.vanilla/drivers/net/wan/sdla.c Tue Feb 13 16:15:05 2001 +++ linux.buffers/drivers/net/wan/sdla.c Sun Apr 15 02:52:45 2001 @@ -1641,8 +1641,6 @@ dev->addr_len = 0; dev->mtu = SDLA_MAX_MTU; - dev_init_buffers(dev); - flp->activate = sdla_activate; flp->deactivate = sdla_deactivate; flp->assoc = sdla_assoc; diff -urN linux.vanilla/drivers/net/wan/sdla_chdlc.c linux.buffers/drivers/net/wan/sdla_chdlc.c --- linux.vanilla/drivers/net/wan/sdla_chdlc.c Sun Apr 15 02:37:19 2001 +++ linux.buffers/drivers/net/wan/sdla_chdlc.c Sun Apr 15 02:53:13 2001 @@ -1025,7 +1025,6 @@ /* Initialize socket buffers */ #if defined(LINUX_2_1) || defined(LINUX_2_4) - dev_init_buffers(dev); #else for (i = 0; i < DEV_NUMBUFFS; ++i) skb_queue_head_init(&dev->buffs[i]); diff -urN linux.vanilla/drivers/net/wan/sdla_fr.c linux.buffers/drivers/net/wan/sdla_fr.c --- linux.vanilla/drivers/net/wan/sdla_fr.c Sun Apr 15 02:37:19 2001 +++ linux.buffers/drivers/net/wan/sdla_fr.c Sun Apr 15 02:52:55 2001 @@ -1276,7 +1276,6 @@ /* Initialize socket buffers */ #if defined(LINUX_2_1) || defined(LINUX_2_4) - dev_init_buffers(dev); #else for (i = 0; i < DEV_NUMBUFFS; ++i) skb_queue_head_init(&dev->buffs[i]); diff -urN linux.vanilla/drivers/net/wan/sdla_ppp.c linux.buffers/drivers/net/wan/sdla_ppp.c --- linux.vanilla/drivers/net/wan/sdla_ppp.c Sun Apr 15 02:37:19 2001 +++ linux.buffers/drivers/net/wan/sdla_ppp.c Sun Apr 15 02:52:58 2001 @@ -789,7 +789,6 @@ /* Initialize socket buffers */ #if defined(LINUX_2_1) || defined(LINUX_2_4) - dev_init_buffers(dev); #else for (i = 0; i < DEV_NUMBUFFS; ++i) skb_queue_head_init(&dev->buffs[i]); diff -urN linux.vanilla/drivers/net/wan/sdla_x25.c linux.buffers/drivers/net/wan/sdla_x25.c --- linux.vanilla/drivers/net/wan/sdla_x25.c Sun Apr 15 02:37:19 2001 +++ linux.buffers/drivers/net/wan/sdla_x25.c Sun Apr 15 02:53:01 2001 @@ -1169,7 +1169,6 @@ /* Initialize socket buffers */ #if defined(LINUX_2_1) || defined(LINUX_2_4) - dev_init_buffers(dev); #else for (i = 0; i < DEV_NUMBUFFS; ++i) skb_queue_head_init(&dev->buffs[i]); diff -urN linux.vanilla/drivers/net/wan/sealevel.c linux.buffers/drivers/net/wan/sealevel.c --- linux.vanilla/drivers/net/wan/sealevel.c Tue Mar 6 22:44:37 2001 +++ linux.buffers/drivers/net/wan/sealevel.c Sun Apr 15 02:53:05 2001 @@ -375,7 +375,6 @@ d->do_ioctl = sealevel_ioctl; #ifdef LINUX_21 d->neigh_setup = sealevel_neigh_setup_dev; - dev_init_buffers(d); #else d->init = return_0; #endif diff -urN linux.vanilla/drivers/net/wan/syncppp.c linux.buffers/drivers/net/wan/syncppp.c --- linux.vanilla/drivers/net/wan/syncppp.c Tue Mar 6 22:44:37 2001 +++ linux.buffers/drivers/net/wan/syncppp.c Sun Apr 15 02:53:08 2001 @@ -1048,7 +1048,6 @@ dev->hard_header_cache = NULL; dev->header_cache_update = NULL; dev->flags = IFF_MULTICAST|IFF_POINTOPOINT|IFF_NOARP; - dev_init_buffers(dev); } EXPORT_SYMBOL(sppp_attach); diff -urN linux.vanilla/drivers/net/wan/wanpipe_multppp.c linux.buffers/drivers/net/wan/wanpipe_multppp.c --- linux.vanilla/drivers/net/wan/wanpipe_multppp.c Sun Apr 15 02:37:20 2001 +++ linux.buffers/drivers/net/wan/wanpipe_multppp.c Sun Apr 15 02:53:29 2001 @@ -720,7 +720,6 @@ /* Initialize socket buffers */ #if defined(LINUX_2_1) || defined(LINUX_2_4) - dev_init_buffers(dev); #else for (i = 0; i < DEV_NUMBUFFS; ++i) skb_queue_head_init(&dev->buffs[i]); diff -urN linux.vanilla/drivers/net/wan/x25_asy.c linux.buffers/drivers/net/wan/x25_asy.c --- linux.vanilla/drivers/net/wan/x25_asy.c Sat Nov 11 22:02:39 2000 +++ linux.buffers/drivers/net/wan/x25_asy.c Sun Apr 15 02:53:10 2001 @@ -874,8 +874,6 @@ dev->type = ARPHRD_X25; dev->tx_queue_len = 10; - dev_init_buffers(dev); - /* New-style flags. */ dev->flags = IFF_NOARP; diff -urN linux.vanilla/drivers/s390/net/ctcmain.c linux.buffers/drivers/s390/net/ctcmain.c --- linux.vanilla/drivers/s390/net/ctcmain.c Sun Apr 15 02:37:22 2001 +++ linux.buffers/drivers/s390/net/ctcmain.c Sun Apr 15 02:54:19 2001 @@ -3252,7 +3252,6 @@ dev->type = ARPHRD_SLIP; dev->tx_queue_len = 100; SET_DEVICE_START(dev, 1); - dev_init_buffers(dev); dev->flags = IFF_POINTOPOINT | IFF_NOARP; for (direction = READ; direction <= WRITE; direction++) { if ((ctc_no_auto == 0) || (devno[direction] == -1)) diff -urN linux.vanilla/drivers/s390/net/netiucv.c linux.buffers/drivers/s390/net/netiucv.c --- linux.vanilla/drivers/s390/net/netiucv.c Sun Apr 15 02:37:22 2001 +++ linux.buffers/drivers/s390/net/netiucv.c Sun Apr 15 02:54:29 2001 @@ -707,7 +707,6 @@ dev->flags = IFF_NOARP | IFF_POINTOPOINT; dev->mtu = 9216; - dev_init_buffers (dev); pr_debug ("%s: iucv_init dev@=%p\n", dev->name, dev); return 0; } diff -urN linux.vanilla/include/linux/netdevice.h linux.buffers/include/linux/netdevice.h --- linux.vanilla/include/linux/netdevice.h Sun Apr 15 02:37:42 2001 +++ linux.buffers/include/linux/netdevice.h Sun Apr 15 02:51:19 2001 @@ -565,7 +565,7 @@ static inline void dev_init_buffers(struct net_device *dev) { - /* DO NOTHING */ + /* WILL BE REMOVED IN 2.5.0 */ } extern int netdev_finish_unregister(struct net_device *dev); diff -urN linux.vanilla/net/atm/clip.c linux.buffers/net/atm/clip.c --- linux.vanilla/net/atm/clip.c Fri Jul 7 00:37:24 2000 +++ linux.buffers/net/atm/clip.c Sun Apr 15 02:51:48 2001 @@ -571,7 +571,6 @@ /* compromise between decent burst-tolerance and protection */ /* against memory hogs. */ dev->flags = 0; - dev_init_buffers(dev); /* is this ever supposed to be used ? */ return 0; } diff -urN linux.vanilla/net/ipv4/ip_gre.c linux.buffers/net/ipv4/ip_gre.c --- linux.vanilla/net/ipv4/ip_gre.c Sun Apr 15 02:37:47 2001 +++ linux.buffers/net/ipv4/ip_gre.c Sun Apr 15 02:51:31 2001 @@ -1147,8 +1147,6 @@ dev->do_ioctl = ipgre_tunnel_ioctl; dev->change_mtu = ipgre_tunnel_change_mtu; - dev_init_buffers(dev); - dev->type = ARPHRD_IPGRE; dev->hard_header_len = LL_MAX_HEADER + sizeof(struct iphdr) + 4; dev->mtu = 1500 - sizeof(struct iphdr) - 4; diff -urN linux.vanilla/net/ipv4/ipip.c linux.buffers/net/ipv4/ipip.c --- linux.vanilla/net/ipv4/ipip.c Sun Apr 15 02:37:47 2001 +++ linux.buffers/net/ipv4/ipip.c Sun Apr 15 02:51:29 2001 @@ -794,8 +794,6 @@ dev->do_ioctl = ipip_tunnel_ioctl; dev->change_mtu = ipip_tunnel_change_mtu; - dev_init_buffers(dev); - dev->type = ARPHRD_TUNNEL; dev->hard_header_len = LL_MAX_HEADER + sizeof(struct iphdr); dev->mtu = 1500 - sizeof(struct iphdr); diff -urN linux.vanilla/net/ipv6/sit.c linux.buffers/net/ipv6/sit.c --- linux.vanilla/net/ipv6/sit.c Sun Apr 15 02:37:49 2001 +++ linux.buffers/net/ipv6/sit.c Sun Apr 15 02:51:37 2001 @@ -747,8 +747,6 @@ dev->do_ioctl = ipip6_tunnel_ioctl; dev->change_mtu = ipip6_tunnel_change_mtu; - dev_init_buffers(dev); - dev->type = ARPHRD_SIT; dev->hard_header_len = LL_MAX_HEADER + sizeof(struct iphdr); dev->mtu = 1500 - sizeof(struct iphdr); diff -urN linux.vanilla/net/irda/irda_device.c linux.buffers/net/irda/irda_device.c --- linux.vanilla/net/irda/irda_device.c Wed Nov 29 00:53:45 2000 +++ linux.buffers/net/irda/irda_device.c Sun Apr 15 02:51:44 2001 @@ -430,7 +430,6 @@ memset(dev->broadcast, 0xff, 4); dev->mtu = 2048; - dev_init_buffers(dev); dev->flags = IFF_NOARP; return 0; } diff -urN linux.vanilla/net/netrom/nr_dev.c linux.buffers/net/netrom/nr_dev.c --- linux.vanilla/net/netrom/nr_dev.c Fri Dec 29 17:35:47 2000 +++ linux.buffers/net/netrom/nr_dev.c Sun Apr 15 02:51:35 2001 @@ -231,7 +231,5 @@ dev->get_stats = nr_get_stats; - dev_init_buffers(dev); - return 0; }; diff -urN linux.vanilla/net/rose/rose_dev.c linux.buffers/net/rose/rose_dev.c --- linux.vanilla/net/rose/rose_dev.c Fri Dec 29 17:35:47 2000 +++ linux.buffers/net/rose/rose_dev.c Sun Apr 15 02:51:41 2001 @@ -200,7 +200,5 @@ dev->get_stats = rose_get_stats; - dev_init_buffers(dev); - return 0; }; --------------1B380F894FF576A810455199-- From owner-netdev@oss.sgi.com Mon Apr 16 08:53:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3GFrke27344 for netdev-outgoing; Mon, 16 Apr 2001 08:53:46 -0700 Received: from smtp102.urscorp.com (smtp102.urscorp.com [38.202.96.105]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3GFrcM27338 for ; Mon, 16 Apr 2001 08:53:38 -0700 To: linux-tr@linuxtr.net, girouard@us.ibm.com Cc: klucke@us.ibm.com, arjanv@redhat.com, netdev@oss.sgi.com Subject: Olympic Updated X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 From: mike_phillips@urscorp.com Message-ID: Date: Mon, 16 Apr 2001 11:46:25 -0400 X-MIMETrack: Serialize by Router on SMTP102/URSCorp(Release 5.0.5 |September 22, 2000) at 04/16/2001 11:49:47 AM, Serialize complete at 04/16/2001 11:49:47 AM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-netdev@oss.sgi.com Precedence: bulk All, The latest olympic drivers are now up on the web site for the 2.4.3 kernels. (At least 2.4.3, it won't work on 2.4.1 or 2.4.2). 4/1/01 Added: alloc_trdev & friends, pci dma api, net init api and other misc. cleanups. Changed: network_monitor is now a kernel parameter, not a compile time option and it add one entry per adapter in /proc/net. 4/16/01 Fixed: Couple of bugs in the pci_unmap calls. Added: Hot-eject support. The adapter doesn't die and take the kernel with it. You can now eject the cardbus adapters when live and the driver will exit gracefully and clean up after itself. (So re-insertion works fine.) I've tested as a module and compiled into the kernel for the regular pci adapters (both 16/4 and 100/16/4) and as a module for the cardbus adapters. Unless someone screams really loudly in the next couple of days, this is going in the kernel as is. Mike Phillips Linux Token Ring Project http://www.linuxtr.net From owner-netdev@oss.sgi.com Tue Apr 17 03:22:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3HAMjo31853 for netdev-outgoing; Tue, 17 Apr 2001 03:22:45 -0700 Received: from mozart (CPE-61-9-150-66.vic.bigpond.net.au [61.9.150.66]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3HAMiM31850 for ; Tue, 17 Apr 2001 03:22:44 -0700 Received: from rustcorp.com.au (really [127.0.0.1]) by rustcorp.com.au via in.smtpd with esmtp id (Debian Smail3.2.0.111) for ; Wed, 11 Apr 2001 20:47:18 +1000 (EST) Message-Id: From: Rusty Russell To: Imran.Patel@nokia.com Cc: netdev@oss.sgi.com Subject: Re: skb allocation problems In-reply-to: Your message of "Mon, 09 Apr 2001 19:03:46 +0300." <2D6CADE9B0C6D411A27500508BB3CBD063CF07@eseis15nok> Date: Wed, 11 Apr 2001 20:47:18 +1000 Sender: owner-netdev@oss.sgi.com Precedence: bulk In message <2D6CADE9B0C6D411A27500508BB3CBD063CF07@eseis15nok> you write: > > PRE_R: old skb:c371ee40 new skb:c371ee30 > <7>NAT: 3 dropping untracked packet c350fa00 1 192.168.102.22 -> > 192.168.102.29 Try poisoning the packet in __kfree_skb() (or skb_headerinit()): skb->head = skb->data = skb->tail = skb->end = NULL; This will catch almost anyone using a freed packet, and you'll get a OOPS in the right place. Hope that helps, Rusty. -- Premature optmztion is rt of all evl. --DK From owner-netdev@oss.sgi.com Tue Apr 17 05:44:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3HCiNu04557 for netdev-outgoing; Tue, 17 Apr 2001 05:44:23 -0700 Received: from shell.cyberus.ca (shell.cyberus.ca [209.195.95.7]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3HCiLM04554 for ; Tue, 17 Apr 2001 05:44:21 -0700 Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.3/666/Cyberus Online Inc.) with ESMTP id IAA20902; Tue, 17 Apr 2001 08:42:59 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Tue, 17 Apr 2001 08:42:59 -0400 (EDT) From: jamal To: cc: , , Andi Kleen Subject: mroute.h patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Seems like a very simple problem and i am being lazy and thinking 'kernel'; looks like i need to do this to get mrouted to compile. Mostly because of conflicts that mrouted likes netinet/in.h This change (include linux/in.h) seems to have taken place sometime around 2.1 something If there's some other way of doing it easily without this patch let me know cheers, jamal --- /usr/src/2.4.3/include/linux/mroute.h.orig Sun Apr 15 17:34:46 2001 +++ /usr/src/2.4.3/include/linux/mroute.h Sun Apr 15 17:19:16 2001 @@ -1,8 +1,10 @@ #ifndef __LINUX_MROUTE_H #define __LINUX_MROUTE_H +#ifdef __KERNEL__ #include #include +#endif /* * Based on the MROUTING 3.5 defines primarily to keep From owner-netdev@oss.sgi.com Tue Apr 17 10:21:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3HHLP617951 for netdev-outgoing; Tue, 17 Apr 2001 10:21:25 -0700 Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f3HHLOM17948 for ; Tue, 17 Apr 2001 10:21:24 -0700 Received: (qmail 336 invoked from network); 17 Apr 2001 17:21:06 -0000 Received: from p3e9b8e41.dip.t-dialin.net (HELO worker.bieringer.de) (62.155.142.65) by mail.bieringer.de with SMTP; 17 Apr 2001 17:21:06 -0000 Message-Id: <5.0.2.1.0.20010417190653.02daa008@mail.bieringer.de> X-Sender: peter@bieringer.de@mail.bieringer.de X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 17 Apr 2001 19:23:15 +0200 To: netdev@oss.sgi.com From: Peter Bieringer Subject: IPv6: behavior of the all/per device forwarding controls in /proc/sys/net/ipv6 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, I have a question regarding the use of the forwarding switches in the IPv6 part of /proc Scenario: Internal host --- native IPv6 --- (eth0)local tunnel server(sit0) --- tunneled IPv6 --- 6bone On my "local tunnel server" (2.2.19pre16) are currently following switches available: # find /proc/sys/net/ipv6 -name 'forward*' /proc/sys/net/ipv6/conf/sit1/forwarding /proc/sys/net/ipv6/conf/sit0/forwarding /proc/sys/net/ipv6/conf/eth1/forwarding /proc/sys/net/ipv6/conf/eth0/forwarding /proc/sys/net/ipv6/conf/lo/forwarding /proc/sys/net/ipv6/conf/default/forwarding /proc/sys/net/ipv6/conf/all/forwarding IPv6 routing from "internal host" to 6bone only works if following forwarding switches are set like /proc/sys/net/ipv6/conf/eth0/forwarding = 1 /proc/sys/net/ipv6/conf/sit0/forwarding = 1 /proc/sys/net/ipv6/conf/all/forwarding = 1 But if I set "/proc/sys/net/ipv6/conf/all/forwarding" to "1", all dedicated device switches are also set to "1". This is the same behavior like in IPv4, but unlike in IPv4, if "/proc/sys/net/ipv6/conf/all/forwarding" = 0, IPv6 routing is generally disabled. Therefore /proc/sys/net/ipv6/conf/eth0/forwarding = 1 /proc/sys/net/ipv6/conf/sit0/forwarding = 1 /proc/sys/net/ipv6/conf/all/forwarding = 0 doesn't route anything. That's bad for security issues, because if someone will only enable dedicated devices for IPv6 routing, he must first globally enable IPv6 routing with /proc/sys/net/ipv6/conf/all/forwarding = 1 and then afterwards for each *do not IPv6 routing device* disable forwarding like /proc/sys/net/ipv6/conf/eth1/forwarding = 0 Therefore 2 questions: a) is this a bug or a feature b) why is it different to IPv4 where routing still works, if /proc/sys/net/ipv4/ip_forward = /proc/sys/net/ipv4/conf/all/forwarding = 0 /proc/sys/net/ipv4/conf/eth0/forwarding = 1 /proc/sys/net/ipv4/conf/ppp0/forwarding = 1 (Tested with masquerading, which take also use of such switches) My opinion is that IPv6 routing should only depends on the "per device" switches and "all" only toggles all "per device" switches in one direction, but do not switch routing capabilities - this is better for security issues. TIA, Peter From owner-netdev@oss.sgi.com Tue Apr 17 10:21:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3HHLTH17962 for netdev-outgoing; Tue, 17 Apr 2001 10:21:29 -0700 Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3HHLSM17959 for ; Tue, 17 Apr 2001 10:21:28 -0700 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3HHLoH06772 for ; Tue, 17 Apr 2001 20:21:50 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 17 Apr 2001 20:21:25 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Tue, 17 Apr 2001 20:21:25 +0300 Message-ID: <2D6CADE9B0C6D411A27500508BB3CBD0013C7923@eseis15nok> From: Imran.Patel@nokia.com To: netdev@oss.sgi.com Subject: frag id byte order (PATCH) Date: Tue, 17 Apr 2001 20:21:25 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk hi all, while going thru the ipv6 source code, i found that the frag_id was not in the network byte order. I guess even in the case of IPv4, the id is not in NBO. Is that intentional??? i checked freebsd and it gives the frag id in NBO. Anycase, i have attached the patch (against ip6_output.c/kernel 2.4.3) below (notice that some people will do anything to get their name in the kernel sources:) regards, imran --- linux-2.4.3/net/ipv6/ip6_output.c Thu Jun 22 17:23:26 2000 +++ linux/net/ipv6/ip6_output.c Tue Apr 17 17:08:26 2001 @@ -22,6 +22,7 @@ * etc. * * H. von Brand : Added missing #include + * Imran Patel : frag id should be in NBO */ #include @@ -55,7 +56,7 @@ static spinlock_t ip6_id_lock = SPIN_LOCK_UNLOCKED; spin_lock_bh(&ip6_id_lock); - fhdr->identification = ipv6_fragmentation_id; + fhdr->identification = htonl(ipv6_fragmentation_id); if (++ipv6_fragmentation_id == 0) ipv6_fragmentation_id = 1; spin_unlock_bh(&ip6_id_lock); From owner-netdev@oss.sgi.com Tue Apr 17 13:40:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3HKeCv26587 for netdev-outgoing; Tue, 17 Apr 2001 13:40:12 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3HKeCM26584 for ; Tue, 17 Apr 2001 13:40:12 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id NAA15043; Tue, 17 Apr 2001 13:40:08 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15068.43560.329884.817170@pizda.ninka.net> Date: Tue, 17 Apr 2001 13:40:08 -0700 (PDT) To: Imran.Patel@nokia.com Cc: netdev@oss.sgi.com Subject: Re: frag id byte order (PATCH) In-Reply-To: <2D6CADE9B0C6D411A27500508BB3CBD0013C7923@eseis15nok> References: <2D6CADE9B0C6D411A27500508BB3CBD0013C7923@eseis15nok> X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Imran.Patel@nokia.com writes: > Anycase, i have attached the patch (against ip6_output.c/kernel 2.4.3) below > (notice that some people will do anything to get their name in the kernel > sources:) I've applied your patch, thanks a lot. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Tue Apr 17 14:08:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3HL8WM28208 for netdev-outgoing; Tue, 17 Apr 2001 14:08:32 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3HL8VM28205 for ; Tue, 17 Apr 2001 14:08:31 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id OAA15283; Tue, 17 Apr 2001 14:08:08 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15068.45240.607852.463576@pizda.ninka.net> Date: Tue, 17 Apr 2001 14:08:08 -0700 (PDT) To: jamal Cc: , , Andi Kleen Subject: Re: mroute.h patch In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk jamal writes: > Seems like a very simple problem and i am being lazy and thinking > 'kernel'; looks like i need to do this to get mrouted to compile. Mostly > because of conflicts that mrouted likes netinet/in.h > This change (include linux/in.h) seems to have taken place sometime around > 2.1 something So how does mroute.h get SIOCPROTOPRIVATE if it does not include sockios.h? Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Tue Apr 17 14:27:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3HLRoE29493 for netdev-outgoing; Tue, 17 Apr 2001 14:27:50 -0700 Received: from mail.noos.fr (verlaine.noos.net [212.198.2.73]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3HLRXM29481 for ; Tue, 17 Apr 2001 14:27:49 -0700 Received: (qmail 13535125 invoked by uid 0); 17 Apr 2001 21:27:31 -0000 Received: from d008.dhcp212-198-118.noos.fr (HELO noos.fr) ([212.198.118.8]) (envelope-sender ) by verlaine.noos.net (qmail-ldap-1.03) with SMTP for ; 17 Apr 2001 21:27:31 -0000 Message-ID: <3ADCB4C3.18BB41CB@noos.fr> Date: Tue, 17 Apr 2001 23:25:24 +0200 From: battata chafik X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: andrewm@uow.edu.au, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: thank's for answering Content-Type: multipart/mixed; boundary="------------EBFD5077213C5B00045965C3" Sender: owner-netdev@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------EBFD5077213C5B00045965C3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit this is my problem i have a 3c595TX card and when i plus it in my hub it at 10base T i tride to put the new modules and nothing changed i have a 2.2.16 kernel and 2.4.1 kenel and it's the same in the too cases , and i have to other computer using a 100base T cards from real tek and they appear at 100 base T in the hub and te rate of any fule transfert is up to 10 mb/s between the to other computer , so is there any upgrade to do for the bios of the nic card or is it normal " i don't think so but why not " sorry for my poor english i try to do my best --------------EBFD5077213C5B00045965C3 Content-Type: text/plain; charset=us-ascii; name="3con595TX" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="3con595TX" 00:0a.0 Ethernet controller: 3Com Corporation 3c595 100BaseTX [Vortex] Flags: bus master, medium devsel, latency 248, IRQ 18 I/O ports at e800 [size=32] Expansion ROM at eb000000 [disabled] [size=64K] 00: b7 10 50 59 07 00 00 02 00 00 00 02 00 f8 00 00 10: 01 e8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 eb 00 00 00 00 00 00 00 00 05 01 03 08 100 base T hubed vortex-diag.c:v2.04 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a 3Com 3c595 Vortex 10/100baseTx adapter at 0xe800. The Vortex chip may be active, so FIFO registers will not be read. To see all register values use the '-f' flag. Initial window 7, registers values by window: Window 0: 0000 0000 0000 0000 0000 00bf 0000 0000. Window 1: FIFO FIFO 0000 2000 8000 00ff 3ffc 2000. Window 2: a000 8a24 1c66 0000 0000 0000 00de 4000. Window 3: 001b 0001 0000 0020 e10a bfff 3fff 6000. Window 4: 0000 00d4 0000 0c80 0001 88c0 0000 8000. Window 5: 1ffc 1ffc 00de 1ffc 0007 02de 00de a000. Window 6: 0000 0000 0000 3000 0000 4e5b 2bb7 c000. Window 7: 0000 0000 0000 0000 8000 00ff 0000 e000. Vortex chip registers at 0xe800 0xE810: **FIFO** 00000000 00008000 *STATUS* 0xE820: ffffffff ffffffff ffffffff ffffffff 0xE830: ffffffff ffffffff ffffffff ffffffff Indication enable is 00de, interrupt enable is 02de. No interrupt sources are pending. Transceiver/media interfaces available: 100baseTx 10baseT. Transceiver type in use: 10baseT. MAC settings: full-duplex. Maximum packet size is 0. Station address set to 00:a0:24:8a:66:1c. Configuration options 00de. EEPROM contents (64 words, offset 0): 0x000: 00a0 248a 661c 5950 c095 0036 5542 6d50 0x008: 0418 0000 00a0 248a 661c bf20 0000 0000 0x010: 11c6 0000 001b 0001 0000 0000 0000 000e 0x018: 0000 0000 0000 0000 0000 0000 0000 0000 0x020: 0000 0000 0000 0000 0000 0000 0000 0000 0x028: 0000 0000 0000 0000 0000 0000 0000 0000 0x030: 0000 0000 0000 0000 0000 0000 0000 0000 0x038: 0000 0000 0000 0000 0000 0000 0000 0000 The word-wide EEPROM checksum is 0xc861. Parsing the EEPROM of a 3Com Vortex/Boomerang: 3Com Node Address 00:A0:24:8A:66:1C (used as a unique ID only). OEM Station address 00:A0:24:8A:66:1C (used as the ethernet address). Manufacture date (MM/DD/YYYY) 4/21/1996, division 6, product BU. Options: force full-duplex. Vortex format checksum is correct (000e vs. 000e). Cyclone format checksum is correct (00 vs. 00). Hurricane format checksum is correct (00 vs. 00). eth0 Link encap:Ethernet HWaddr 00:A0:24:8A:66:1C inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9656 errors:200 dropped:200 overruns:0 frame:311 TX packets:9779 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:5767681 (5.5 Mb) TX bytes:1539404 (1.4 Mb) Interrupt:18 Base address:0xe800 --------------EBFD5077213C5B00045965C3-- From owner-netdev@oss.sgi.com Tue Apr 17 22:32:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3I5W7f12142 for netdev-outgoing; Tue, 17 Apr 2001 22:32:07 -0700 Received: from vaio.greennet (adsl-151-196-236-199.baltmd.adsl.bellatlantic.net [151.196.236.199]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3I5W5M12139 for ; Tue, 17 Apr 2001 22:32:05 -0700 Received: from localhost (becker@localhost) by vaio.greennet (8.9.3/8.8.7) with ESMTP id BAA14448; Wed, 18 Apr 2001 01:32:30 -0400 Date: Wed, 18 Apr 2001 01:31:49 -0400 (EDT) From: Donald Becker X-Sender: becker@vaio.greennet To: battata chafik cc: andrewm@uow.edu.au, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: thank's for answering In-Reply-To: <3ADCB4C3.18BB41CB@noos.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Tue, 17 Apr 2001, battata chafik wrote: > i have a 3c595TX card and when i plus it in my hub it at 10base T i > tride to put the new modules and nothing changed i have a 2.2.16 kernel > and 2.4.1 kenel and it's the same in the too cases , > and i have to other computer using a 100base T cards from real tek and > they appear at 100 base T in the hub and te rate of any fule transfert > is up to 10 mb/s between the to other computer , so is there any > upgrade to do for the bios of the nic card or is it normal " i don't > think so but why not " First problem: the EEPROM is set to forced full duplex. This is almost certainly wrong for your hub. The speed problem is likely because you have a dual speed repeater. The 595 speed autosensing must be done by the driver. In order to not screw up 10baseT repeaters with 100baseTx link beat the driver first sets the speed to 10baseT and checks for link beat. If it finds 10baseT link beat it never tries 100baseTx. The solution is to set the speed to 100baseTx using a driver option. Read http://www.scyld.com/network/vortex.html The 3c595 is a very old card. You will get better performance from any modern card. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From owner-netdev@oss.sgi.com Wed Apr 18 02:14:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3I9Ej319869 for netdev-outgoing; Wed, 18 Apr 2001 02:14:45 -0700 Received: from metastasis.f00f.org (f00f.stub.clear.net.nz [203.167.224.51]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3I9EhM19866 for ; Wed, 18 Apr 2001 02:14:44 -0700 Received: by metastasis.f00f.org (Postfix, from userid 1000) id E8C61A739; Wed, 18 Apr 2001 21:14:40 +1200 (NZST) Date: Wed, 18 Apr 2001 21:14:40 +1200 From: Chris Wedgwood To: "David S. Miller" Cc: Imran.Patel@nokia.com, netdev@oss.sgi.com Subject: Re: frag id byte order (PATCH) Message-ID: <20010418211440.A3894@metastasis.f00f.org> References: <2D6CADE9B0C6D411A27500508BB3CBD0013C7923@eseis15nok> <15068.43560.329884.817170@pizda.ninka.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15068.43560.329884.817170@pizda.ninka.net>; from davem@redhat.com on Tue, Apr 17, 2001 at 01:40:08PM -0700 X-No-Archive: Yes Sender: owner-netdev@oss.sgi.com Precedence: bulk On Tue, Apr 17, 2001 at 01:40:08PM -0700, David S. Miller wrote: Imran.Patel@nokia.com writes: > Anycase, i have attached the patch (against ip6_output.c/kernel 2.4.3) below > (notice that some people will do anything to get their name in the kernel > sources:) I've applied your patch, thanks a lot. I thought frag_id was an opaque value and hence so long as it is consistent it need matter here? --cw From owner-netdev@oss.sgi.com Wed Apr 18 02:20:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3I9KWw20392 for netdev-outgoing; Wed, 18 Apr 2001 02:20:32 -0700 Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3I9KUM20389 for ; Wed, 18 Apr 2001 02:20:31 -0700 Received: from esvir07nok.ntc.nokia.com (esvir07nokt.ntc.nokia.com [172.21.143.39]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3I9KrH28703 for ; Wed, 18 Apr 2001 12:20:53 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir07nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 18 Apr 2001 12:20:28 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 18 Apr 2001 12:20:24 +0300 Message-ID: <2D6CADE9B0C6D411A27500508BB3CBD0013C7925@eseis15nok> From: Imran.Patel@nokia.com To: netdev@oss.sgi.com Subject: RE: frag id byte order (PATCH) Date: Wed, 18 Apr 2001 12:20:22 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk > I thought frag_id was an opaque value and hence so long as it is > consistent it need matter here? well, practically it should work fine as long as it is incremented properly but it might break some things like for example the siit rfc says that while translating from ipv6 to ipv4 : the frag_off field in ipv4 header = lower 16 bits of frag_off in ipv6 frag header.... so if it's not in nbo, then it may create problems in such cases... imran From owner-netdev@oss.sgi.com Wed Apr 18 07:53:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3IEr9G32668 for netdev-outgoing; Wed, 18 Apr 2001 07:53:09 -0700 Received: from smtp1.arnet.com.ar (host191006.arnet.net.ar [200.45.191.6] (may be forged)) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f3IEr8M32665 for ; Wed, 18 Apr 2001 07:53:08 -0700 Received: (qmail 4803 invoked from network); 18 Apr 2001 14:52:51 -0000 Received: from host000020.arnet.net.ar (HELO smtpmcis1.arnet.com.ar) (200.45.0.20) by host191006.arnet.net.ar with SMTP; 18 Apr 2001 14:52:51 -0000 Received: from mail pickup service by smtpmcis1.arnet.com.ar with Microsoft SMTPSVC; Wed, 18 Apr 2001 11:44:23 -0300 Received: from recife.arnet.com.ar ([192.168.202.70]) by mail1.arnet.com.ar with Microsoft SMTPSVC(5.5.1877.677.67); Tue, 17 Apr 2001 17:41:28 -0300 Received: (qmail 32567 invoked from network); 17 Apr 2001 20:41:27 -0000 Received: from oss.sgi.com (216.32.174.190) by recife.arnet.com.ar with SMTP; 17 Apr 2001 20:41:27 -0000 Received: from localhost (mail@localhost) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f3HKemB26692; Tue, 17 Apr 2001 13:40:48 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Tue, 17 Apr 2001 13:40:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3HKeCv26587 for netdev-outgoing; Tue, 17 Apr 2001 13:40:12 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3HKeCM26584 for ; Tue, 17 Apr 2001 13:40:12 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id NAA15043; Tue, 17 Apr 2001 13:40:08 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15068.43560.329884.817170@pizda.ninka.net> Date: Tue, 17 Apr 2001 13:40:08 -0700 (PDT) To: Imran.Patel@nokia.com Cc: netdev@oss.sgi.com Subject: Re: frag id byte order (PATCH) In-Reply-To: <2D6CADE9B0C6D411A27500508BB3CBD0013C7923@eseis15nok> References: <2D6CADE9B0C6D411A27500508BB3CBD0013C7923@eseis15nok> X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Imran.Patel@nokia.com writes: > Anycase, i have attached the patch (against ip6_output.c/kernel 2.4.3) below > (notice that some people will do anything to get their name in the kernel > sources:) I've applied your patch, thanks a lot. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Wed Apr 18 08:13:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3IFD4L01256 for netdev-outgoing; Wed, 18 Apr 2001 08:13:04 -0700 Received: from granch.com (IDENT:root@granch.com [212.109.197.246]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3IFD1M01253 for ; Wed, 18 Apr 2001 08:13:01 -0700 Received: from localhost (xenon@localhost) by granch.com (8.11.2/8.11.2) with ESMTP id f3IFCv944442 for ; Wed, 18 Apr 2001 22:12:58 +0700 (NOVST) (envelope-from xenon@granch.com) Date: Wed, 18 Apr 2001 22:12:56 +0700 (NOVST) From: "Yaroslav S. Polyakov" To: netdev@oss.sgi.com Subject: Re: dev_alloc_skb / kmalloc proble (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi! Can you please point me about where could be problem or may be show me the way I should dig? when porting my sbni network driver from 2.2.x to 2.4.x kernel I've got a problem: dev_alloc_skb (when I creating skb to fill it with packet from network card) sometimes creates skb with skb->head value equal to address of my basic device dev structure. I create dev in my init_module procedure with call dev=kmalloc(sizeof(struct net_device),GFP_KERNEL); BTW, as i've noticed driver works ok for the first time, but after I rmmod/insmod it again problem appears. All the best! . A burnt child dreads the fire. Granch ltd. Security Analyst ---------- Forwarded message ---------- Date: Wed, 18 Apr 2001 15:58:28 +0100 (BST) From: Alan Cox To: Yaroslav S. Polyakov Cc: Alan.Cox@linux.org Subject: Re: dev_alloc_skb / kmalloc proble > dev_alloc_skb(size) sometimes returns skb where skb->head == dev. > dev is value I've got with > dev=kmalloc(sizeof(struct net_device),GFP_KERNEL); > in my init_module(void) function. That sounds like a miscompile more than anything > I think once kmalloced memory should NEVER be kmalloced again if > not kfree()'ed. Correct. If it seems to be the net layer talk to netdev@oss.sgi.com but I suspect what is really going on is not so simple From owner-netdev@oss.sgi.com Wed Apr 18 08:18:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3IFIfx01928 for netdev-outgoing; Wed, 18 Apr 2001 08:18:41 -0700 Received: from smtp1.arnet.com.ar (host191006.arnet.net.ar [200.45.191.6] (may be forged)) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f3IFIdM01924 for ; Wed, 18 Apr 2001 08:18:40 -0700 Received: (qmail 948 invoked from network); 18 Apr 2001 15:18:32 -0000 Received: from host000020.arnet.net.ar (HELO smtpmcis1.arnet.com.ar) (200.45.0.20) by host191006.arnet.net.ar with SMTP; 18 Apr 2001 15:18:32 -0000 Received: from mail pickup service by smtpmcis1.arnet.com.ar with Microsoft SMTPSVC; Wed, 18 Apr 2001 12:09:46 -0300 Received: from recife.arnet.com.ar ([192.168.202.70]) by mail1.arnet.com.ar with Microsoft SMTPSVC(5.5.1877.677.67); Tue, 17 Apr 2001 17:41:28 -0300 Received: (qmail 32567 invoked from network); 17 Apr 2001 20:41:27 -0000 Received: from oss.sgi.com (216.32.174.190) by recife.arnet.com.ar with SMTP; 17 Apr 2001 20:41:27 -0000 Received: from localhost (mail@localhost) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f3HKemB26692; Tue, 17 Apr 2001 13:40:48 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Tue, 17 Apr 2001 13:40:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3HKeCv26587 for netdev-outgoing; Tue, 17 Apr 2001 13:40:12 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3HKeCM26584 for ; Tue, 17 Apr 2001 13:40:12 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id NAA15043; Tue, 17 Apr 2001 13:40:08 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15068.43560.329884.817170@pizda.ninka.net> Date: Tue, 17 Apr 2001 13:40:08 -0700 (PDT) To: Imran.Patel@nokia.com Cc: netdev@oss.sgi.com Subject: Re: frag id byte order (PATCH) In-Reply-To: <2D6CADE9B0C6D411A27500508BB3CBD0013C7923@eseis15nok> References: <2D6CADE9B0C6D411A27500508BB3CBD0013C7923@eseis15nok> X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Imran.Patel@nokia.com writes: > Anycase, i have attached the patch (against ip6_output.c/kernel 2.4.3) below > (notice that some people will do anything to get their name in the kernel > sources:) I've applied your patch, thanks a lot. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Wed Apr 18 08:31:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3IFVjh02715 for netdev-outgoing; Wed, 18 Apr 2001 08:31:45 -0700 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3IFViM02711 for ; Wed, 18 Apr 2001 08:31:44 -0700 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3IFV4221894 for ; Wed, 18 Apr 2001 18:31:04 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 18 Apr 2001 18:31:26 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 18 Apr 2001 18:31:26 +0300 Message-ID: <2D6CADE9B0C6D411A27500508BB3CBD0013C792A@eseis15nok> From: Imran.Patel@nokia.com To: Imran.Patel@nokia.com Cc: netdev@oss.sgi.com Subject: RE: skb allocation problems Date: Wed, 18 Apr 2001 18:31:25 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk > Try poisoning the packet in __kfree_skb() (or skb_headerinit()): > > skb->head = skb->data = skb->tail = skb->end = NULL; > > This will catch almost anyone using a freed packet, and you'll get a > OOPS in the right place. I guess i have figured out what might be causing the problem. Actually i was doing something like this in my NAT-PT module: // get the packet at the pre-routing hook skb_unlink(ipv4_skb); // do the translation ipv6_skb = alloc_skb(..... kfree_skb(ipv4_skb); return NF_STOLEN; When i removed the skb_unlink statement, everything started to work fine....no longer do i get the memory overlap between ipv4_skb and ipv6_skb.....So is it something like that when i unlink the skb it is available for re-use??? If it is not something like that then the problem might be because of something else.... btw, even when i removed my (faulty!) module, the kernel was behaving in a nasty manner and i got corrupted ping packets (as i reported on the list earlier) imran > > Hope that helps, > Rusty. > -- > Premature optmztion is rt of all evl. --DK > From owner-netdev@oss.sgi.com Wed Apr 18 08:44:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3IFiI203490 for netdev-outgoing; Wed, 18 Apr 2001 08:44:18 -0700 Received: from zmailer.org (mail.zmailer.org [194.252.70.162]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3IFiBM03481; Wed, 18 Apr 2001 08:44:12 -0700 Received: (from localhost user: 'mea' uid#500 fake: STDIN (mea@zmailer.org)) by mail.zmailer.org id ; Wed, 18 Apr 2001 18:43:47 +0300 Date: Wed, 18 Apr 2001 18:43:46 +0300 From: Matti Aarnio To: netdev-owner@oss.sgi.com Cc: netdev@oss.sgi.com Subject: Subscriber feeding back to the list... Message-ID: <20010418184346.U805@mea-ext.zmailer.org> References: <2D6CADE9B0C6D411A27500508BB3CBD0013C7923@eseis15nok> <15068.43560.329884.817170@pizda.ninka.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15068.43560.329884.817170@pizda.ninka.net>; from davem@redhat.com on Tue, Apr 17, 2001 at 01:40:08PM -0700 Sender: owner-netdev@oss.sgi.com Precedence: bulk Somebody is using something alike fetchmail, and resending all received email out to the "To:" and "Cc:" headers in the picked up email. Are there many subscribers at arnet.com.ar ?? On Tue, Apr 17, 2001 at 01:40:08PM -0700, David S. Miller wrote: > Received: from oss.sgi.com ([IPv6:::ffff:216.32.174.190]:35078 "EHLO > oss.sgi.com" smtp-auth: TLS-CIPHER: TLS-PEER: ) > by mail.zmailer.org with ESMTP id ; > Wed, 18 Apr 2001 18:19:16 +0300 > Received: from localhost (mail@localhost) > by oss.sgi.com (8.11.3/8.11.3) with SMTP id f3IFIg801950; > Wed, 18 Apr 2001 08:18:42 -0700 > X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs > Received: by oss.sgi.com (bulk_mailer v1.13); Wed, 18 Apr 2001 08:18:41 -0700 > Received: (from majordomo@localhost) > by oss.sgi.com (8.11.3/8.11.3) id f3IFIfx01928 > for netdev-outgoing; Wed, 18 Apr 2001 08:18:41 -0700 > Received: from smtp1.arnet.com.ar (host191006.arnet.net.ar [200.45.191.6] (may be forged)) > by oss.sgi.com (8.11.3/8.11.3) with SMTP id f3IFIdM01924 > for ; Wed, 18 Apr 2001 08:18:40 -0700 > Received: (qmail 948 invoked from network); 18 Apr 2001 15:18:32 -0000 > Received: from host000020.arnet.net.ar (HELO smtpmcis1.arnet.com.ar) (200.45.0.20) > by host191006.arnet.net.ar with SMTP; 18 Apr 2001 15:18:32 -0000 > Received: from mail pickup service by smtpmcis1.arnet.com.ar with Microsoft SMTPSVC; > Wed, 18 Apr 2001 12:09:46 -0300 > Received: from recife.arnet.com.ar ([192.168.202.70]) by mail1.arnet.com.ar with Microsoft SMTPSVC(5.5.1877.677.67); > Tue, 17 Apr 2001 17:41:28 -0300 > Received: (qmail 32567 invoked from network); 17 Apr 2001 20:41:27 -0000 > Received: from oss.sgi.com (216.32.174.190) > by recife.arnet.com.ar with SMTP; 17 Apr 2001 20:41:27 -0000 > Received: from localhost (mail@localhost) > by oss.sgi.com (8.11.3/8.11.3) with SMTP id f3HKemB26692; > Tue, 17 Apr 2001 13:40:48 -0700 > X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs > Received: by oss.sgi.com (bulk_mailer v1.13); Tue, 17 Apr 2001 13:40:13 -0700 > Received: (from majordomo@localhost) > by oss.sgi.com (8.11.3/8.11.3) id f3HKeCv26587 > for netdev-outgoing; Tue, 17 Apr 2001 13:40:12 -0700 > Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) > by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3HKeCM26584 > for ; Tue, 17 Apr 2001 13:40:12 -0700 > Received: (from davem@localhost) > by pizda.ninka.net (8.9.3/8.9.3) id NAA15043; > Tue, 17 Apr 2001 13:40:08 -0700 > From: "David S. Miller" > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Message-ID: <15068.43560.329884.817170@pizda.ninka.net> > Date: Tue, 17 Apr 2001 13:40:08 -0700 (PDT) > To: Imran.Patel@nokia.com > Cc: netdev@oss.sgi.com > Subject: Re: frag id byte order (PATCH) > In-Reply-To: <2D6CADE9B0C6D411A27500508BB3CBD0013C7923@eseis15nok> > References: <2D6CADE9B0C6D411A27500508BB3CBD0013C7923@eseis15nok> > X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid > Sender: owner-netdev@oss.sgi.com > Return-Path: From owner-netdev@oss.sgi.com Wed Apr 18 11:12:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3IICde09739 for netdev-outgoing; Wed, 18 Apr 2001 11:12:39 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3IICXM09730 for ; Wed, 18 Apr 2001 11:12:34 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f3IGmDc03289; Wed, 18 Apr 2001 13:48:13 -0300 Date: Wed, 18 Apr 2001 13:48:13 -0300 From: Ralf Baechle To: Imran.Patel@nokia.com Cc: netdev@oss.sgi.com Subject: Re: skb allocation problems Message-ID: <20010418134813.A2789@bacchus.dhis.org> References: <2D6CADE9B0C6D411A27500508BB3CBD0013C792A@eseis15nok> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2D6CADE9B0C6D411A27500508BB3CBD0013C792A@eseis15nok>; from Imran.Patel@nokia.com on Wed, Apr 18, 2001 at 06:31:25PM +0300 X-Accept-Language: de,en,fr Sender: owner-netdev@oss.sgi.com Precedence: bulk On Wed, Apr 18, 2001 at 06:31:25PM +0300, Imran.Patel@nokia.com wrote: > btw, even when i removed my (faulty!) module, the kernel was behaving in a > nasty manner and i got corrupted ping packets (as i reported on the list > earlier) It's an apparently known ping problem. Conectiv 6's ping is broken; Redhat 7's ping seems to be ok. Ralf From owner-netdev@oss.sgi.com Wed Apr 18 11:13:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3IIDnm09874 for netdev-outgoing; Wed, 18 Apr 2001 11:13:49 -0700 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3IIDdM09851; Wed, 18 Apr 2001 11:13:40 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f3IGYq503195; Wed, 18 Apr 2001 13:34:52 -0300 Date: Wed, 18 Apr 2001 13:34:52 -0300 From: Ralf Baechle To: Matti Aarnio Cc: netdev-owner@oss.sgi.com, netdev@oss.sgi.com Subject: Re: Subscriber feeding back to the list... Message-ID: <20010418133452.A1298@bacchus.dhis.org> References: <2D6CADE9B0C6D411A27500508BB3CBD0013C7923@eseis15nok> <15068.43560.329884.817170@pizda.ninka.net> <20010418184346.U805@mea-ext.zmailer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010418184346.U805@mea-ext.zmailer.org>; from matti.aarnio@zmailer.org on Wed, Apr 18, 2001 at 06:43:46PM +0300 X-Accept-Language: de,en,fr Sender: owner-netdev@oss.sgi.com Precedence: bulk On Wed, Apr 18, 2001 at 06:43:46PM +0300, Matti Aarnio wrote: > Somebody is using something alike fetchmail, and resending > all received email out to the "To:" and "Cc:" headers in > the picked up email. > > Are there many subscribers at arnet.com.ar ?? 0 (was: 1). I only noticed a single dupe, so I suspect it might as well have been a user bouncing a posting back to the list but to be on the safe side I removed him from the list. Ralf From owner-netdev@oss.sgi.com Wed Apr 18 11:43:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3IIhGS13027 for netdev-outgoing; Wed, 18 Apr 2001 11:43:16 -0700 Received: from smtp1.arnet.com.ar (host191006.arnet.net.ar [200.45.191.6] (may be forged)) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f3IIhFM13020 for ; Wed, 18 Apr 2001 11:43:15 -0700 Received: (qmail 12454 invoked from network); 18 Apr 2001 18:43:05 -0000 Received: from host000020.arnet.net.ar (HELO smtpmcis1.arnet.com.ar) (200.45.0.20) by host191006.arnet.net.ar with SMTP; 18 Apr 2001 18:43:05 -0000 Received: from mail pickup service by smtpmcis1.arnet.com.ar with Microsoft SMTPSVC; Wed, 18 Apr 2001 15:33:53 -0300 Received: from recife.arnet.com.ar ([192.168.202.70]) by mail1.arnet.com.ar with Microsoft SMTPSVC(5.5.1877.677.67); Tue, 17 Apr 2001 17:41:28 -0300 Received: (qmail 32567 invoked from network); 17 Apr 2001 20:41:27 -0000 Received: from oss.sgi.com (216.32.174.190) by recife.arnet.com.ar with SMTP; 17 Apr 2001 20:41:27 -0000 Received: from localhost (mail@localhost) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f3HKemB26692; Tue, 17 Apr 2001 13:40:48 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Tue, 17 Apr 2001 13:40:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3HKeCv26587 for netdev-outgoing; Tue, 17 Apr 2001 13:40:12 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3HKeCM26584 for ; Tue, 17 Apr 2001 13:40:12 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id NAA15043; Tue, 17 Apr 2001 13:40:08 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15068.43560.329884.817170@pizda.ninka.net> Date: Tue, 17 Apr 2001 13:40:08 -0700 (PDT) To: Imran.Patel@nokia.com Cc: netdev@oss.sgi.com Subject: Re: frag id byte order (PATCH) In-Reply-To: <2D6CADE9B0C6D411A27500508BB3CBD0013C7923@eseis15nok> References: <2D6CADE9B0C6D411A27500508BB3CBD0013C7923@eseis15nok> X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Imran.Patel@nokia.com writes: > Anycase, i have attached the patch (against ip6_output.c/kernel 2.4.3) below > (notice that some people will do anything to get their name in the kernel > sources:) I've applied your patch, thanks a lot. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Wed Apr 18 11:56:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3IIuAB14148 for netdev-outgoing; Wed, 18 Apr 2001 11:56:10 -0700 Received: from smtp1.arnet.com.ar (host191006.arnet.net.ar [200.45.191.6] (may be forged)) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f3IIu9M14145 for ; Wed, 18 Apr 2001 11:56:09 -0700 Received: (qmail 28712 invoked from network); 18 Apr 2001 18:56:02 -0000 Received: from host000020.arnet.net.ar (HELO smtpmcis1.arnet.com.ar) (200.45.0.20) by host191006.arnet.net.ar with SMTP; 18 Apr 2001 18:56:02 -0000 Received: from mail pickup service by smtpmcis1.arnet.com.ar with Microsoft SMTPSVC; Wed, 18 Apr 2001 15:46:48 -0300 Received: from recife.arnet.com.ar ([192.168.202.70]) by mail1.arnet.com.ar with Microsoft SMTPSVC(5.5.1877.677.67); Tue, 17 Apr 2001 17:41:28 -0300 Received: (qmail 32567 invoked from network); 17 Apr 2001 20:41:27 -0000 Received: from oss.sgi.com (216.32.174.190) by recife.arnet.com.ar with SMTP; 17 Apr 2001 20:41:27 -0000 Received: from localhost (mail@localhost) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f3HKemB26692; Tue, 17 Apr 2001 13:40:48 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Tue, 17 Apr 2001 13:40:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3HKeCv26587 for netdev-outgoing; Tue, 17 Apr 2001 13:40:12 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3HKeCM26584 for ; Tue, 17 Apr 2001 13:40:12 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id NAA15043; Tue, 17 Apr 2001 13:40:08 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15068.43560.329884.817170@pizda.ninka.net> Date: Tue, 17 Apr 2001 13:40:08 -0700 (PDT) To: Imran.Patel@nokia.com Cc: netdev@oss.sgi.com Subject: Re: frag id byte order (PATCH) In-Reply-To: <2D6CADE9B0C6D411A27500508BB3CBD0013C7923@eseis15nok> References: <2D6CADE9B0C6D411A27500508BB3CBD0013C7923@eseis15nok> X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Imran.Patel@nokia.com writes: > Anycase, i have attached the patch (against ip6_output.c/kernel 2.4.3) below > (notice that some people will do anything to get their name in the kernel > sources:) I've applied your patch, thanks a lot. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Wed Apr 18 12:23:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3IJNoC15673 for netdev-outgoing; Wed, 18 Apr 2001 12:23:50 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3IJNoM15670 for ; Wed, 18 Apr 2001 12:23:50 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA20892; Wed, 18 Apr 2001 12:23:40 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15069.59836.489676.910774@pizda.ninka.net> Date: Wed, 18 Apr 2001 12:23:40 -0700 (PDT) To: Chris Wedgwood Cc: Imran.Patel@nokia.com, netdev@oss.sgi.com Subject: Re: frag id byte order (PATCH) In-Reply-To: <20010418211440.A3894@metastasis.f00f.org> References: <2D6CADE9B0C6D411A27500508BB3CBD0013C7923@eseis15nok> <15068.43560.329884.817170@pizda.ninka.net> <20010418211440.A3894@metastasis.f00f.org> X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Chris Wedgwood writes: > On Tue, Apr 17, 2001 at 01:40:08PM -0700, David S. Miller wrote: > > Imran.Patel@nokia.com writes: > > Anycase, i have attached the patch (against ip6_output.c/kernel 2.4.3) below > > (notice that some people will do anything to get their name in the kernel > > sources:) > > I've applied your patch, thanks a lot. > > I thought frag_id was an opaque value and hence so long as it is > consistent it need matter here? It's opaque, sure, but not to things like TCP header compression et al. :-) (TCP header compression expects the network byte order value of the IP header ID field to increase monotonically) Besides, I'd rather all Linux machines spit out IDs in the same way regardless of endianness. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Thu Apr 19 00:27:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3J7RNw13650 for netdev-outgoing; Thu, 19 Apr 2001 00:27:23 -0700 Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f3J7RMM13646 for ; Thu, 19 Apr 2001 00:27:22 -0700 Received: (qmail 26306 invoked from network); 19 Apr 2001 07:27:04 -0000 Received: from p3e9b8e55.dip.t-dialin.net (HELO worker.bieringer.de) (62.155.142.85) by mail.bieringer.de with SMTP; 19 Apr 2001 07:27:04 -0000 Message-Id: <5.0.2.1.0.20010419092037.00af7d28@mail.bieringer.de> X-Sender: peter@bieringer.de@mail.bieringer.de X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 19 Apr 2001 09:29:19 +0200 To: netdev@oss.sgi.com From: Peter Bieringer Subject: IPv6: 2.4.2/3 autoconfiguration sometimes didn't work Cc: pekkas@netcore.fi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, testing the new RedHat 7.1 distribution I ran into a strange problem regarding the work of autoconfiguration: Scenario: worker (RH7.1) [..:9205] --- LAN --- gate (2.2.19pre16, running radvd) [..:b4f5] Tested kernels on worker: 2.4.2-2 (RH 7.1) 2.4.3 vanilla, fresh compiled Kernel on gate: 2.2.19pre16 vanilla Radvd-Version: 0.6.2pl1 After booting, all is ok, IPv6 is autoconfigured. If I run "/etc/rc.d/init.d/network restart", autoconfiguration doesn't work anymore. Packets on the LAN: 09:06:49.887982 :: > ff02::1:ff90:9205: icmp6: neighbor sol: who has fe80::2e0:18ff:fe90:9205 09:06:50.728393 fe80::250:bfff:fe06:b4f5 > ff02::1: icmp6: router advertisement 09:06:53.888279 fe80::2e0:18ff:fe90:9205 > ff02::2: icmp6: router solicitation 09:06:53.898402 fe80::250:bfff:fe06:b4f5 > ff02::1: icmp6: router advertisement 09:07:03.788411 fe80::250:bfff:fe06:b4f5 > ff02::1: icmp6: router advertisement 09:07:12.448429 fe80::250:bfff:fe06:b4f5 > ff02::1: icmp6: router advertisement Nothing happens on worker anymore. If I shut down the interface by hand "ifconfig eth0 down", wait some seconds and put it up again "ifconfig eth0 up" most of the time autoconfiguration works again: 09:07:13.929671 :: > ff02::1:ff90:9205: icmp6: neighbor sol: who has fe80::2e0:18ff:fe90:9205 09:07:17.288425 fe80::250:bfff:fe06:b4f5 > ff02::1: icmp6: router advertisement 09:07:17.929976 fe80::2e0:18ff:fe90:9205 > ff02::2: icmp6: router solicitation 09:07:18.248493 fe80::250:bfff:fe06:b4f5 > ff02::1:ff90:9205: icmp6: neighbor sol: who has fe80::2e0:18ff:fe90:9205 09:07:18.248677 fe80::2e0:18ff:fe90:9205 > fe80::250:bfff:fe06:b4f5: icmp6: neighbor adv: tgt is fe80::2e0:18ff:fe90:9205 09:07:18.248778 fe80::250:bfff:fe06:b4f5 > fe80::2e0:18ff:fe90:9205: icmp6: router advertisement 09:07:18.749995 :: > ff02::1:ff90:9205: icmp6: neighbor sol: who has 2002:d950:249d:f101:2e0:18ff:fe90:92 05 09:07:26.698501 fe80::250:bfff:fe06:b4f5 > ff02::1: icmp6: router advertisement Very strange! As far as I remember, with USAGI patches on 2.4 kernel such problem never occurs. Can someone reproduce this? Is there a timer somewhere which is not cleared on interface shutdown or something else? TIA, Peter From owner-netdev@oss.sgi.com Thu Apr 19 04:32:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3JBWW201814 for netdev-outgoing; Thu, 19 Apr 2001 04:32:32 -0700 Received: from stsl.siemens.com.tw ([192.72.45.189]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3JBWVM01805 for ; Thu, 19 Apr 2001 04:32:31 -0700 Received: from stslex.siemens.com.tw (stslex [192.72.45.13]) by stsl.siemens.com.tw (8.9.1/8.9.1) with ESMTP id TAA17041 for ; Thu, 19 Apr 2001 19:43:24 +0800 (CST) Received: by stslex.siemens.com.tw with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Apr 2001 19:32:04 +0800 Message-ID: <92C0C0AC8AE8D411864300105A835CBB50A5B1@stslex.siemens.com.tw> From: Ra Chen To: netdev@oss.sgi.com Subject: obvious ndisc.c bug Date: Thu, 19 Apr 2001 19:31:54 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C8C4.56169680" Sender: owner-netdev@oss.sgi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0C8C4.56169680 Content-Type: text/plain; charset="windows-1252" net/ipv6/ndisc.c in kernel 2.4.3 line 1076: if ((ipv6_addr_type(saddr)&IPV6_ADDR_MULTICAST) && "saddr" should be "daddr". Regards Ra Chen ------_=_NextPart_001_01C0C8C4.56169680 Content-Type: text/html; charset="windows-1252" obvious ndisc.c bug

net/ipv6/ndisc.c in kernel 2.4.3
line 1076:

if ((ipv6_addr_type(saddr)&IPV6_ADDR_MULTICAST) &&

"saddr" should be "daddr".

Regards

Ra Chen

------_=_NextPart_001_01C0C8C4.56169680-- From owner-netdev@oss.sgi.com Thu Apr 19 05:14:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3JCEj707537 for netdev-outgoing; Thu, 19 Apr 2001 05:14:45 -0700 Received: from peso.dgim.crc.ca (peso.dgim.crc.ca [142.92.39.84]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3JCEiM07533 for ; Thu, 19 Apr 2001 05:14:44 -0700 Received: from cork (cork.dgrc.crc.ca [142.92.38.56]) by peso.dgim.crc.ca (8.11.3/8.11.3) with ESMTP id f3JCEaL29474; Thu, 19 Apr 2001 08:14:36 -0400 (EDT) Message-Id: <4.2.2.20010419075418.0224f5f0@pop.crc.ca> X-Sender: broberts@pop.crc.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 19 Apr 2001 08:14:35 -0500 To: Peter Bieringer , netdev@oss.sgi.com From: Bill Robertson Subject: Re: IPv6: 2.4.2/3 autoconfiguration sometimes didn't work In-Reply-To: <5.0.2.1.0.20010419092037.00af7d28@mail.bieringer.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-netdev@oss.sgi.com Precedence: bulk I have a 2 host network with a 2.2.19 based router running radvd 0.6.2 (not p11) and a 2.2.19 based client and am having the same problem as Peter. Most of the time the client doesn't autoconfigure itself to the site local address being provided in the router advertisements. I tried both "/etc/rc.d/init.d/network restart" and Peter's suggestion of "ifconfig eth0 down" followed about 60 seconds later by "ifconfig eth0 up". Neither seems to work. When autoconfigure fails I see: 08:05:59.643602 fe80::210:5aff:fec8:ca2e > ff02::2: icmp6: router solicitation 08:05:59.692754 fe80::210:5aff:fe9e:2e7a > ff02::1: icmp6: router advertisement 08:06:06.662744 fe80::210:5aff:fe9e:2e7a > ff02::1: icmp6: router advertisement when it works I see: 08:08:12.359210 fe80::210:5aff:fec8:ca2e > ff02::2: icmp6: router solicitation 08:08:12.622758 fe80::210:5aff:fe9e:2e7a > ff02::1: icmp6: router advertisement 08:08:12.622863 fe80::210:5aff:fe9e:2e7a > ff02::1:ffc8:ca2e: icmp6: neighbor sol: who has fe80::210:5aff:fec8:ca2e 08:08:12.623064 fe80::210:5aff:fec8:ca2e > fe80::210:5aff:fe9e:2e7a: icmp6: neighbor adv: tgt is fe80::210:5aff:fec8:ca2e 08:08:12.623093 fe80::210:5aff:fe9e:2e7a > fe80::210:5aff:fec8:ca2e: icmp6: router advertisement 08:08:13.259079 :: > ff02::1:ffc8:ca2e: icmp6: neighbor sol: who has cn.crc.ca 08:08:19.952751 fe80::210:5aff:fe9e:2e7a > ff02::1: icmp6: router advertisement I can usually force address autoconfiguration to work by rebooting the client rather than doing a network restart. Any suggestions would be appreciated. Thanks. -- W.J. (Bill) Robertson voice: (613)998-2819 Communications Research Centre fax: (613)998-9648 http://www.crc.ca/ bill.robertson@crc.ca From owner-netdev@oss.sgi.com Thu Apr 19 12:01:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3JJ1a820859 for netdev-outgoing; Thu, 19 Apr 2001 12:01:36 -0700 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3JJ1XM20856 for ; Thu, 19 Apr 2001 12:01:34 -0700 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3JJ16214083 for ; Thu, 19 Apr 2001 22:01:06 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 19 Apr 2001 22:01:30 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Thu, 19 Apr 2001 22:01:30 +0300 Message-ID: <2D6CADE9B0C6D411A27500508BB3CBD0013C792F@eseis15nok> From: Imran.Patel@nokia.com To: netdev@oss.sgi.com Subject: pmtu discovery [PATCH] Date: Thu, 19 Apr 2001 22:01:29 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk hello everybody, while working with my NAT-PT module, i found that PMTU discovery in Linux doesn't handle a peculiar case - that of having a value of pmtu < 1280 returned by the icmpv6 "pkt too big" message. In a perfectly normal world that should never happen, but it might be the case when the ipv6 host is talking to a ipv4 host across a translator and there is a link of mtu < 1280 on the v4 side....However, rfc 2460 has a solution to this problem: In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used. I've taken a shot in solving this....but i am not sure whether it is the best way to do it....what i do is when i get this mtu < 1280 message, i set the mtu = 1272 (1280 - frag header size; the rfc says it to be 1280)....the other cleaner way would be to define a boolean like RTF_TO_IPV4 and set the mtu = 1280.... But anycase, i set the mtu to be 1272 since 8 bytes are going to be added to every unfragmented packet (except for the packets that will be fragmented).....and it helps in simpler code and helps distinguish this case without defining the boolean... In the case when the packet is going to be fragmented anyway, i pass mtu as 1280....so it is something like: for unfragmented packets: mtu = 1272 & addition of a frag header (so all packets from 0 to 1272 are handled ok) for fragmented packets: mtu = 1280 (all packets with size > 1272 are handled here) i have attached the diffs of ip6_output.c and route.c (latest versions in cvs) against the 2.4.3 versions.....i also am not sure at which other places this may affect (maybe tcp!)...the patch is completely untested (i dunno even if it compiles)...as i am not sure about the approach...comments so that i can improve it??? imran --- /home/pis/route.c Thu Apr 19 13:55:03 2001 +++ net/ipv6/route.c Thu Apr 19 14:08:02 2001 @@ -1002,10 +1002,9 @@ struct rt6_info *rt, *nrt; if (pmtu < IPV6_MIN_MTU) { - if (net_ratelimit()) - printk(KERN_DEBUG "rt6_pmtu_discovery: invalid MTU value %d\n", + pmtu = IPV6_MIN_MTU - sizeof(struct frag_hdr); + printk(KERN_DEBUG "rt6_pmtu_discovery: MTU = %u < IPV6_MIN_MTU", pmtu); - return; } rt = rt6_lookup(daddr, saddr, dev->ifindex, 0); --- net/ipv6/ip6_output.c Thu Apr 19 18:10:19 2001 +++ /home/pis/ip6_output.c Thu Apr 19 13:54:43 2001 @@ -353,9 +353,6 @@ last_len += opt->opt_flen; } - if(mtu < IPV6_MIN_MTU) - mtu = IPV6_MIN_MTU; - /* * Length of fragmented part on every packet but * the last must be an: @@ -626,9 +623,6 @@ err = 0; if (flags&MSG_PROBE) goto out; - - if(mtu < IPV6_MIN_MTU) - pktlength += sizeof(struct frag_hdr); skb = sock_alloc_send_skb(sk, pktlength + 15 + dev->hard_header_len, @@ -647,28 +641,16 @@ skb->nh.ipv6h = hdr; if (!sk->protinfo.af_inet.hdrincl) { - u8 *prev_hdr = &hdr->nexthdr; ip6_bld_1(sk, skb, fl, hlimit, jumbolen ? sizeof(struct ipv6hdr) : pktlength); if (opt || jumbolen) { + u8 *prev_hdr = &hdr->nexthdr; prev_hdr = ipv6_build_nfrag_opts(skb, prev_hdr, opt, final_dst, jumbolen); - - if(mtu < IPV6_MIN_MTU) - prev_hdr = ipv6_build_fraghdr(skb, prev_hdr, 0); - if (opt && opt->opt_flen) ipv6_build_frag_opts(skb, prev_hdr, opt); } - else if(mtu < IPV6_MIN_MTU) { - prev_hdr = ipv6_build_fraghdr(skb, prev_hdr, 0); - } } - - /* drop it ??? */ - else if(mtu < IPV6_MIN_MTU) - goto out; - skb_put(skb, length); err = getfrag(data, &hdr->saddr, From owner-netdev@oss.sgi.com Thu Apr 19 12:21:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3JJLPK21838 for netdev-outgoing; Thu, 19 Apr 2001 12:21:25 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f3JJLLM21831 for ; Thu, 19 Apr 2001 12:21:22 -0700 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id XAA19839; Thu, 19 Apr 2001 23:20:44 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200104191920.XAA19839@ms2.inr.ac.ru> Subject: Re: pmtu discovery [PATCH] To: Imran.Patel@nokia.COM Date: Thu, 19 Apr 2001 23:20:44 +0400 (MSK DST) Cc: netdev@oss.sgi.com In-Reply-To: <2D6CADE9B0C6D411A27500508BB3CBD0013C792F@eseis15nok> from "Imran.Patel@nokia.COM" at Apr 19, 1 11:15:01 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello! > ...as i am not sure about the approach...comments so > that i can improve it??? It looks mostly right. Though, apparently, such routes are to be marked with a flag. > cvs) against the 2.4.3 versions.....i also am not sure at which other places > this may affect (maybe tcp!)... No doubts. Additional header modifies calculation of mss. Though it should contribute to tp->exthdr_len. > the patch is completely untested (i dunno > even if it compiles)... 8) Alexey From owner-netdev@oss.sgi.com Thu Apr 19 14:06:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3JL6NO25784 for netdev-outgoing; Thu, 19 Apr 2001 14:06:23 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3JL6NM25781 for ; Thu, 19 Apr 2001 14:06:23 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id OAA09095; Thu, 19 Apr 2001 14:06:14 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15071.21318.158337.602199@pizda.ninka.net> Date: Thu, 19 Apr 2001 14:06:14 -0700 (PDT) To: Ra Chen Cc: netdev@oss.sgi.com Subject: Re: obvious ndisc.c bug In-Reply-To: <92C0C0AC8AE8D411864300105A835CBB50A5B1@stslex.siemens.com.tw> References: <92C0C0AC8AE8D411864300105A835CBB50A5B1@stslex.siemens.com.tw> X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Ra Chen writes: > net/ipv6/ndisc.c in kernel 2.4.3 > line 1076: > > if ((ipv6_addr_type(saddr)&IPV6_ADDR_MULTICAST) && > > "saddr" should be "daddr". This code looks correct to me, what exactly makes you think it should be testing "daddr"? Similar code above for the solication cases also checks "saddr" for being multicast. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Thu Apr 19 19:08:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3K28oe02970 for netdev-outgoing; Thu, 19 Apr 2001 19:08:50 -0700 Received: from stsl.siemens.com.tw ([192.72.45.189]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3K28mM02967 for ; Thu, 19 Apr 2001 19:08:49 -0700 Received: from stslex.siemens.com.tw (stslex [192.72.45.13]) by stsl.siemens.com.tw (8.9.1/8.9.1) with ESMTP id KAA24915; Fri, 20 Apr 2001 10:19:45 +0800 (CST) Received: by stslex.siemens.com.tw with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Apr 2001 10:08:21 +0800 Message-ID: <92C0C0AC8AE8D411864300105A835CBB50A5B4@stslex.siemens.com.tw> From: Ra Chen To: "'David S. Miller'" Cc: "'netdev@oss.sgi.com'" Subject: RE: obvious ndisc.c bug Date: Fri, 20 Apr 2001 10:08:20 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C93E.C5786150" Sender: owner-netdev@oss.sgi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0C93E.C5786150 Content-Type: text/plain; charset="BIG5" > From: David S. Miller [mailto:davem@redhat.com] > Ra Chen writes: > > net/ipv6/ndisc.c in kernel 2.4.3 > > line 1076: > > > > if ((ipv6_addr_type(saddr)&IPV6_ADDR_MULTICAST) && > > > > "saddr" should be "daddr". > > This code looks correct to me, what exactly makes you think it should > be testing "daddr"? Similar code above for the solication cases also > checks "saddr" for being multicast. I think a multicast packet is a packet with multicast destination address. Am I wrong? It's impossible for a source address to be multicast, right? Where's the "similar code"? As I noticed line 1015 and 1043 both check "daddr" for being multicast. Ra Chen ------_=_NextPart_001_01C0C93E.C5786150 Content-Type: text/html; charset="BIG5" Content-Transfer-Encoding: quoted-printable RE: obvious ndisc.c bug

> From: David S. Miller [mailto:davem@redhat.com]
> Ra Chen writes:
>  > net/ipv6/ndisc.c in kernel = 2.4.3
>  > line 1076:
>  >
>  > if = ((ipv6_addr_type(saddr)&IPV6_ADDR_MULTICAST) &&
>  >
>  > "saddr" should be = "daddr".
>
> This code looks correct to me, what exactly = makes you think it should
> be testing "daddr"?  Similar = code above for the solication cases also
> checks "saddr" for being = multicast.

I think a multicast packet is a packet with multicast = destination address. Am I wrong?
It's impossible for a source address to be = multicast, right?
Where's the "similar code"?  As I = noticed line 1015 and 1043 both check "daddr" for being = multicast.

Ra Chen

------_=_NextPart_001_01C0C93E.C5786150-- From owner-netdev@oss.sgi.com Thu Apr 19 20:57:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3K3vVb06657 for netdev-outgoing; Thu, 19 Apr 2001 20:57:31 -0700 Received: from cs.bu.edu (root@CS.BU.EDU [128.197.10.2]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3K3vUM06654 for ; Thu, 19 Apr 2001 20:57:30 -0700 Received: from csa.bu.edu (dhiman@csa [128.197.12.3]) by cs.bu.edu (8.10.1/8.10.1) with ESMTP id f3K3vGt00550; Thu, 19 Apr 2001 23:57:16 -0400 (EDT) Received: (from dhiman@localhost) by csa.bu.edu (8.10.1/8.10.1) id f3K3vCi22153; Thu, 19 Apr 2001 23:57:12 -0400 (EDT) Date: Thu, 19 Apr 2001 23:57:12 -0400 From: Dhiman Barman To: diffserv-general@lists.sourceforge.net Cc: linux-diffserv@lrc.di.epfl.ch, linux-net@vger.rutgers.edu, netdev@oss.sgi.com Subject: scheduler Message-ID: <20010419235712.A21784@cs.bu.edu> Reply-To: dhiman@cs.bu.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, This is especially for those who wrote network schedulers on Linux. I have added another packet scheduler, but whenever I configure the scheduler using 'tc', the screen dumps and the machines hangs. I cannot figure why that fraction of code should affect the os. Any help ? Is there any other way to test any packet scheduler other than using 'tc'. Thanks, db -- Weinberg's Principle: An expert is a person who avoids the small errors while sweeping on to the grand fallacy. From owner-netdev@oss.sgi.com Thu Apr 19 21:16:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3K4Gr607563 for netdev-outgoing; Thu, 19 Apr 2001 21:16:53 -0700 Received: from almesberger.net (IDENT:root@lsb-catv-1-p021.vtxnet.ch [212.147.5.21]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3K4GqM07560 for ; Thu, 19 Apr 2001 21:16:52 -0700 Received: (from almesber@localhost) by almesberger.net (8.9.3/8.9.3) id GAA20176; Fri, 20 Apr 2001 06:16:24 +0200 Date: Fri, 20 Apr 2001 06:16:24 +0200 From: Werner Almesberger To: diffserv-general@lists.sourceforge.net Cc: dhiman@cs.bu.edu, netdev@oss.sgi.com Subject: Re: [Linux Diffserv] scheduler Message-ID: <20010420061624.E29450@almesberger.net> References: <20010419235712.A21784@cs.bu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010419235712.A21784@cs.bu.edu>; from dhiman@cs.bu.edu on Thu, Apr 19, 2001 at 11:57:12PM -0400 Sender: owner-netdev@oss.sgi.com Precedence: bulk Dhiman Barman wrote: > To: diffserv-general@lists.sourceforge.net > Cc: linux-diffserv@lrc.di.epfl.ch, linux-net@vger.rutgers.edu, > netdev@oss.sgi.com Quite a lot of lists ... > I cannot figure why that fraction of code should affect the os. You're probably crashing somewhere in or near an interrupt. That's fairly lethal, no matter where in the kernel it happens ... > Any help ? See linux/Documentation/oops-tracing.txt > Is there any other way to test any packet scheduler other than using 'tc'. Yep, try ftp://icaftp.epfl.ch/pub/linux/tcng/tcsim-*.tar.gz (* = the latest version, currently 1e) See "Adding new traffic control elements" in the README. - Werner -- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH Werner.Almesberger@epfl.ch / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/ From owner-netdev@oss.sgi.com Thu Apr 19 21:29:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3K4TBv08238 for netdev-outgoing; Thu, 19 Apr 2001 21:29:11 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3K4TBM08235 for ; Thu, 19 Apr 2001 21:29:11 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id VAA10884; Thu, 19 Apr 2001 21:29:04 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15071.47888.905400.657345@pizda.ninka.net> Date: Thu, 19 Apr 2001 21:29:04 -0700 (PDT) To: Ra Chen Cc: "'netdev@oss.sgi.com'" Subject: RE: obvious ndisc.c bug In-Reply-To: <92C0C0AC8AE8D411864300105A835CBB50A5B4@stslex.siemens.com.tw> References: <92C0C0AC8AE8D411864300105A835CBB50A5B4@stslex.siemens.com.tw> X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk > I think a multicast packet is a packet with multicast destination address. > Am I wrong? > It's impossible for a source address to be multicast, right? > Where's the "similar code"? As I noticed line 1015 and 1043 both check > "daddr" for being multicast. You're right, I've made the change. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Fri Apr 20 03:18:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3KAIeC18323 for netdev-outgoing; Fri, 20 Apr 2001 03:18:40 -0700 Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3KAIaM18320 for ; Fri, 20 Apr 2001 03:18:37 -0700 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id LAA11531 for ; Fri, 20 Apr 2001 11:02:40 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id MAA18190 for ; Fri, 20 Apr 2001 12:11:39 +0200 (MET DST) Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id LAA27114 for ; Fri, 20 Apr 2001 11:52:24 +0200 (MET DST) Received: from ms.alcatel.fr (spip [188.9.249.125]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id LAA18279 for ; Fri, 20 Apr 2001 11:52:31 +0200 (MET DST) Message-ID: <3AE0056D.1916DB74@ms.alcatel.fr> Date: Fri, 20 Apr 2001 11:46:21 +0200 From: Gilles Diribarne Organization: Alcatel CRC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.3 i686) X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: Linux net Subject: Proble with sit0 (sit.c) Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi,

I've a TCP bug with sit0. I have two DS IPv4/IPV6 node.
I set up a route on each node for the IPv4-compat V6 address. The routing table is below
We have the same problem with 2002:/16 address.

Kernel IPv6 routing table
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
::1/128                                     ::                                      U     0      0        0 lo
::127.0.0.1/128                             ::                                      U     0      0        0 lo
::192.168.52.2/128                          ::                                      U     0      0        0 lo
::/96                                       ::                                      U     256    0        0 sit0
2002:c0a8:3402:2::2/128                     ::                                      U     0      0        0 lo
2002:c0a8:3402:2:201:2ff:feb1:4fb1/128      ::                                      U     0      0        0 lo
2002:c0a8:3402:2::/64                       ::                                      UA    256    44       0 eth0
2002::/16                                   ::                                      U     1      0        0 sit0
fe80::c0a8:1502/128                         ::                                      U     0      0        0 lo
fe80::c0a8:3402/128                         ::                                      U     0      0        0 lo
fe80::201:2ff:feac:cd72/128                 ::                                      U     0      0        0 lo
fe80::201:2ff:feb1:4fb1/128                 ::                                      U     0      0        0 lo
fe80::/10                                   ::                                      UA    256    0        0 eth0
fe80::/10                                   ::                                      UA    256    0        0 eth1
fe80::/10                                   ::                                      UA    256    0        0 sit1
ff02::1/128                                 ff02::1                                 UAC   0      1        1 eth0
ff00::/8                                    ::                                      UA    256    0        0 eth0
ff00::/8                                    ::                                      UA    256    0        0 eth1
ff00::/8                                    ::                                      UA    256    0        0 sit1
::/0                                        ::                                      UDA   256    0        0 eth1

This route has been set up
route -Ainet6 ::/96 sit0

After, I make a ping
# ping6 ::192.168.46.4
PING ::192.168.46.4 (::192.168.46.4): 56 data bytes
64 bytes from ::192.168.46.4: icmp_seq=0 ttl=64 time=0.745 ms
64 bytes from ::192.168.46.4: icmp_seq=1 ttl=64 time=0.481 ms
64 bytes from ::192.168.46.4: icmp_seq=2 ttl=64 time=0.473 ms
64 bytes from ::192.168.46.4: icmp_seq=3 ttl=64 time=0.434 ms
64 bytes from ::192.168.46.4: icmp_seq=4 ttl=64 time=0.444 ms
64 bytes from ::192.168.46.4: icmp_seq=5 ttl=64 time=0.415 ms
64 bytes from ::192.168.46.4: icmp_seq=6 ttl=64 time=0.438 ms
It runs...

But, when I want to make a TCP connection, it fails
Here is the trace. It was a BGP connection made with Zebra.

Frame 4 (114 on wire, 114 captured)
    Arrival Time: Apr 20, 2001 09:48:38.2649
    Time delta from previous packet: 9.768477 seconds
    Time relative to first packet: 29.788480 seconds
    Frame Number: 4
    Packet Length: 114 bytes
    Capture Length: 114 bytes
Ethernet II
    Destination: 00:01:02:ab:e3:cd (BBN_ab:e3:cd)
    Source: 00:01:02:ac:cd:72 (BBN_ac:cd:72)
    Type: IP (0x0800)
Internet Protocol
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 100
    Identification: 0x0000
    Flags: 0x04
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: IPv6 (0x29)
    Header checksum: 0x571a (correct)
    Source: 192.168.52.2 (192.168.52.2)
    Destination: 192.168.46.4 (192.168.46.4)
Internet Protocol Version 6
    Version: 6
    Traffic class: 0x00
    Flowlabel: 0x00000
    Payload length: 40
    Next header: TCP (0x06)
    Hop limit: 64
    Source address: ::192.168.52.2
    Destination address: ::192.168.46.4
Transmission Control Protocol, Src Port: 1055 (1055), Dst Port: bgp (179), Seq: 2091346880, Ack: 0
    Source port: 1055 (1055)
    Destination port: bgp (179)
    Sequence number: 2091346880
    Header length: 40 bytes
    Flags: 0x0002 (SYN)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...0 .... = Acknowledgment: Not set
        .... 0... = Push: Not set
        .... .0.. = Reset: Not set
        .... ..1. = Syn: Set
        .... ...0 = Fin: Not set
    Window size: 5680
    Checksum: 0xf17b (correct)
    Options: (20 bytes)
        Maximum segment size: 1420 bytes
        SACK permitted
        Time stamp: tsval 5730203, tsecr 0
        NOP
        Window scale: 0 bytes

Frame 5 (106 on wire, 106 captured)
    Arrival Time: Apr 20, 2001 09:48:38.2654
    Time delta from previous packet: 0.000442 seconds
    Time relative to first packet: 29.788922 seconds
    Frame Number: 5
    Packet Length: 106 bytes
    Capture Length: 106 bytes
Ethernet II
    Destination: 00:01:02:ac:cd:72 (BBN_ac:cd:72)
    Source: 00:01:02:ab:e3:cd (BBN_ab:e3:cd)
    Type: IP (0x0800)
Internet Protocol
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 92
    Identification: 0x0000
    Flags: 0x04
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 62
    Protocol: IPv6 (0x29)
    Header checksum: 0x5922 (correct)
    Source: 192.168.46.4 (192.168.46.4)
    Destination: 192.168.52.2 (192.168.52.2)
Internet Protocol Version 6
    Version: 6
    Traffic class: 0x00
    Flowlabel: 0x00000
    Payload length: 32
    Next header: TCP (0x06)
    Hop limit: 64
    Source address: ::192.168.46.4
    Destination address: ::192.168.52.2
Transmission Control Protocol, Src Port: bgp (179), Dst Port: 1055 (1055), Seq: 2250769922, Ack: 2091346881
    Source port: bgp (179)
    Destination port: 1055 (1055)
    Sequence number: 2250769922
    Acknowledgement number: 2091346881
    Header length: 32 bytes
    Flags: 0x0012 (SYN, ACK)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...1 .... = Acknowledgment: Set
        .... 0... = Push: Not set
        .... .0.. = Reset: Not set
        .... ..1. = Syn: Set
        .... ...0 = Fin: Not set
    Window size: 5680
    Checksum: 0xfc43 (correct)
    Options: (12 bytes)
        Maximum segment size: 1420 bytes
        NOP
        NOP
        SACK permitted
        NOP
        Window scale: 0 bytes

Frame 6 (94 on wire, 94 captured)
    Arrival Time: Apr 20, 2001 09:48:38.2654
    Time delta from previous packet: 0.000034 seconds
    Time relative to first packet: 29.788956 seconds
    Frame Number: 6
    Packet Length: 94 bytes
    Capture Length: 94 bytes
Ethernet II
    Destination: 00:01:02:ab:e3:cd (BBN_ab:e3:cd)
    Source: 00:01:02:ac:cd:72 (BBN_ac:cd:72)
    Type: IP (0x0800)
Internet Protocol
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 80
    Identification: 0x0000
    Flags: 0x04
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: IPv6 (0x29)
    Header checksum: 0x572e (correct)
    Source: 192.168.52.2 (192.168.52.2)
    Destination: 192.168.46.4 (192.168.46.4)
Internet Protocol Version 6
    Version: 6
    Traffic class: 0x00
    Flowlabel: 0x00000
    Payload length: 20
    Next header: TCP (0x06)
    Hop limit: 64
    Source address: ::192.168.52.2
    Destination address: ::192.168.46.4
Transmission Control Protocol, Src Port: 1055 (1055), Dst Port: bgp (179), Seq: 2091346881, Ack: 0
    Source port: 1055 (1055)
    Destination port: bgp (179)
    Sequence number: 2091346881
    Header length: 20 bytes
    Flags: 0x0004 (RST)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...0 .... = Acknowledgment: Not set
        .... 0... = Push: Not set
        .... .1.. = Reset: Set
        .... ..0. = Syn: Not set
        .... ...0 = Fin: Not set
    Window size: 0
    Checksum: 0xdf4e (correct)

Can someone help us?
Is it a sit0 bug?

Regards,
Gilles 

-- 
 Gilles Diribarne
 Alcatel Research & Innovation
 Gilles.Diribarne@alcatel.fr
 Tel: +33 (0)1 69 63 46 45      Fax: +33 (0)1 69 63 11 69
  From owner-netdev@oss.sgi.com Fri Apr 20 04:53:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3KBrBV21196 for netdev-outgoing; Fri, 20 Apr 2001 04:53:11 -0700 Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3KBrAM21193 for ; Fri, 20 Apr 2001 04:53:10 -0700 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id MAA23513 for ; Fri, 20 Apr 2001 12:37:13 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id NAA16040 for ; Fri, 20 Apr 2001 13:46:45 +0200 (MET DST) Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id NAA02611 for ; Fri, 20 Apr 2001 13:52:40 +0200 (MET DST) Received: from ms.alcatel.fr (spip [188.9.249.125]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id NAA13156 for ; Fri, 20 Apr 2001 13:52:46 +0200 (MET DST) Message-ID: <3AE0219C.49FDA1C8@ms.alcatel.fr> Date: Fri, 20 Apr 2001 13:46:36 +0200 From: Gilles Diribarne Organization: Alcatel CRC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.3 i686) X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: Linux net Subject: SIT Bug Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, I've the following problem on kernel 2.4.3. I have three interface: eth0, eth1, eth2. I consider that eth0 is IPv6 interface, and eth1, eth2 are IPv4 interface. Here is the ifconfig eth0 Link encap:Ethernet HWaddr 00:01:02:B1:4F:B1 inet addr:192.168.21.2 Bcast:192.168.21.255 Mask:255.255.255.0 inet6 addr: fe80::201:2ff:feb1:4fb1/10 Scope:Link inet6 addr: 3ffe:400:100:21:201:2ff:feb1:4fb1/64 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:608 errors:0 dropped:0 overruns:0 frame:0 TX packets:11585 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:11 Base address:0x1400 eth1 Link encap:Ethernet HWaddr 00:01:02:AC:CD:72 inet addr:192.168.52.2 Bcast:192.168.52.255 Mask:255.255.255.0 inet6 addr: fe80::201:2ff:feac:cd72/10 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:12740 errors:0 dropped:0 overruns:1 frame:0 TX packets:6856 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:11 Base address:0x1480 eth2 Link encap:Ethernet HWaddr 00:08:02:DE:00:53 inet addr:192.168.53.2 Bcast:192.168.53.255 Mask:255.255.255.0 inet6 addr: fe80::201:2ff:fe0c:45ec/10 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:12740 errors:0 dropped:0 overruns:1 frame:0 TX packets:6856 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:11 Base address:0x1480 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16144 Metric:1 RX packets:2040 errors:0 dropped:0 overruns:0 frame:0 TX packets:2040 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 sit0 Link encap:IPv6-in-IPv4 inet6 addr: ::127.0.0.1/96 Scope:Unknown inet6 addr: ::192.168.21.2/96 Scope:Compat inet6 addr: ::192.168.52.2/96 Scope:Compat inet6 addr: ::192.168.53.2/96 Scope:Compat UP RUNNING NOARP MTU:1480 Metric:1 RX packets:21 errors:0 dropped:0 overruns:0 frame:0 TX packets:1118 errors:13 dropped:0 overruns:0 carrier:13 collisions:0 txqueuelen:0 The other nodes don't known how to route to subnetwork 192.168.21.0/24 Because I don't set this route. When you set up a IPv4-compatible IPv6 address to allow routing. # route -Ainet6 ::/96 dev sit0 Now, I want to do a ping, but the ping doesn't work. Indeed, it takes 192.168.21.2 as Src Address in the ping. I think it takes the first declared address as default source address. But, I think it's not logical, because it should take the address according to the output interface. I would like to know why Linux choose this one? Regards, Gilles -- Gilles Diribarne Alcatel Research & Innovation Gilles.Diribarne@alcatel.fr Tel: +33 (0)1 69 63 46 45 Fax: +33 (0)1 69 63 11 69 From owner-netdev@oss.sgi.com Fri Apr 20 06:17:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3KDH4123950 for netdev-outgoing; Fri, 20 Apr 2001 06:17:04 -0700 Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3KDH1M23947 for ; Fri, 20 Apr 2001 06:17:01 -0700 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id OAA10027 for ; Fri, 20 Apr 2001 14:01:03 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id PAA15275 for ; Fri, 20 Apr 2001 15:10:41 +0200 (MET DST) Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id PAA07804 for ; Fri, 20 Apr 2001 15:16:36 +0200 (MET DST) Received: from ms.alcatel.fr (spip [188.9.249.125]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id PAA03161 for ; Fri, 20 Apr 2001 15:16:40 +0200 (MET DST) Message-ID: <3AE03544.85F8C67D@ms.alcatel.fr> Date: Fri, 20 Apr 2001 15:10:28 +0200 From: Gilles Diribarne Organization: Alcatel CRC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.3 i686) X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: Linux net Subject: Problem with sit0 (sit.c) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, I've a TCP bug with sit0. I have two DS IPv4/IPV6 node. I set up a route on each node for the IPv4-compat V6 address. The routing table is below We have the same problem with 2002:/16 address. Kernel IPv6 routing table Destination Next Hop Flags Metric Ref Use Iface ::1/128 :: U 0 0 0 lo ::127.0.0.1/128 :: U 0 0 0 lo ::192.168.52.2/128 :: U 0 0 0 lo ::/96 :: U 256 0 0 sit0 2002:c0a8:3402:2::2/128 :: U 0 0 0 lo 2002:c0a8:3402:2:201:2ff:feb1:4fb1/128 :: U 0 0 0 lo 2002:c0a8:3402:2::/64 :: UA 256 44 0 eth0 2002::/16 :: U 1 0 0 sit0 fe80::c0a8:1502/128 :: U 0 0 0 lo fe80::c0a8:3402/128 :: U 0 0 0 lo fe80::201:2ff:feac:cd72/128 :: U 0 0 0 lo fe80::201:2ff:feb1:4fb1/128 :: U 0 0 0 lo fe80::/10 :: UA 256 0 0 eth0 fe80::/10 :: UA 256 0 0 eth1 fe80::/10 :: UA 256 0 0 sit1 ff02::1/128 ff02::1 UAC 0 1 1 eth0 ff00::/8 :: UA 256 0 0 eth0 ff00::/8 :: UA 256 0 0 eth1 ff00::/8 :: UA 256 0 0 sit1 ::/0 :: UDA 256 0 0 eth1 This route has been set up route -Ainet6 ::/96 sit0 After, I make a ping # ping6 ::192.168.46.4 PING ::192.168.46.4 (::192.168.46.4): 56 data bytes 64 bytes from ::192.168.46.4: icmp_seq=0 ttl=64 time=0.745 ms 64 bytes from ::192.168.46.4: icmp_seq=1 ttl=64 time=0.481 ms 64 bytes from ::192.168.46.4: icmp_seq=2 ttl=64 time=0.473 ms 64 bytes from ::192.168.46.4: icmp_seq=3 ttl=64 time=0.434 ms 64 bytes from ::192.168.46.4: icmp_seq=4 ttl=64 time=0.444 ms 64 bytes from ::192.168.46.4: icmp_seq=5 ttl=64 time=0.415 ms 64 bytes from ::192.168.46.4: icmp_seq=6 ttl=64 time=0.438 ms It runs... But, when I want to make a TCP connection, it fails Here is the trace. It was a BGP connection made with Zebra. Frame 4 (114 on wire, 114 captured) Arrival Time: Apr 20, 2001 09:48:38.2649 Time delta from previous packet: 9.768477 seconds Time relative to first packet: 29.788480 seconds Frame Number: 4 Packet Length: 114 bytes Capture Length: 114 bytes Ethernet II Destination: 00:01:02:ab:e3:cd (BBN_ab:e3:cd) Source: 00:01:02:ac:cd:72 (BBN_ac:cd:72) Type: IP (0x0800) Internet Protocol Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 100 Identification: 0x0000 Flags: 0x04 .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: IPv6 (0x29) Header checksum: 0x571a (correct) Source: 192.168.52.2 (192.168.52.2) Destination: 192.168.46.4 (192.168.46.4) Internet Protocol Version 6 Version: 6 Traffic class: 0x00 Flowlabel: 0x00000 Payload length: 40 Next header: TCP (0x06) Hop limit: 64 Source address: ::192.168.52.2 Destination address: ::192.168.46.4 Transmission Control Protocol, Src Port: 1055 (1055), Dst Port: bgp (179), Seq: 2091346880, Ack: 0 Source port: 1055 (1055) Destination port: bgp (179) Sequence number: 2091346880 Header length: 40 bytes Flags: 0x0002 (SYN) 0... .... = Congestion Window Reduced (CWR): Not set .0.. .... = ECN-Echo: Not set ..0. .... = Urgent: Not set ...0 .... = Acknowledgment: Not set .... 0... = Push: Not set .... .0.. = Reset: Not set .... ..1. = Syn: Set .... ...0 = Fin: Not set Window size: 5680 Checksum: 0xf17b (correct) Options: (20 bytes) Maximum segment size: 1420 bytes SACK permitted Time stamp: tsval 5730203, tsecr 0 NOP Window scale: 0 bytes Frame 5 (106 on wire, 106 captured) Arrival Time: Apr 20, 2001 09:48:38.2654 Time delta from previous packet: 0.000442 seconds Time relative to first packet: 29.788922 seconds Frame Number: 5 Packet Length: 106 bytes Capture Length: 106 bytes Ethernet II Destination: 00:01:02:ac:cd:72 (BBN_ac:cd:72) Source: 00:01:02:ab:e3:cd (BBN_ab:e3:cd) Type: IP (0x0800) Internet Protocol Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 92 Identification: 0x0000 Flags: 0x04 .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 62 Protocol: IPv6 (0x29) Header checksum: 0x5922 (correct) Source: 192.168.46.4 (192.168.46.4) Destination: 192.168.52.2 (192.168.52.2) Internet Protocol Version 6 Version: 6 Traffic class: 0x00 Flowlabel: 0x00000 Payload length: 32 Next header: TCP (0x06) Hop limit: 64 Source address: ::192.168.46.4 Destination address: ::192.168.52.2 Transmission Control Protocol, Src Port: bgp (179), Dst Port: 1055 (1055), Seq: 2250769922, Ack: 2091346881 Source port: bgp (179) Destination port: 1055 (1055) Sequence number: 2250769922 Acknowledgement number: 2091346881 Header length: 32 bytes Flags: 0x0012 (SYN, ACK) 0... .... = Congestion Window Reduced (CWR): Not set .0.. .... = ECN-Echo: Not set ..0. .... = Urgent: Not set ...1 .... = Acknowledgment: Set .... 0... = Push: Not set .... .0.. = Reset: Not set .... ..1. = Syn: Set .... ...0 = Fin: Not set Window size: 5680 Checksum: 0xfc43 (correct) Options: (12 bytes) Maximum segment size: 1420 bytes NOP NOP SACK permitted NOP Window scale: 0 bytes Frame 6 (94 on wire, 94 captured) Arrival Time: Apr 20, 2001 09:48:38.2654 Time delta from previous packet: 0.000034 seconds Time relative to first packet: 29.788956 seconds Frame Number: 6 Packet Length: 94 bytes Capture Length: 94 bytes Ethernet II Destination: 00:01:02:ab:e3:cd (BBN_ab:e3:cd) Source: 00:01:02:ac:cd:72 (BBN_ac:cd:72) Type: IP (0x0800) Internet Protocol Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 80 Identification: 0x0000 Flags: 0x04 .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: IPv6 (0x29) Header checksum: 0x572e (correct) Source: 192.168.52.2 (192.168.52.2) Destination: 192.168.46.4 (192.168.46.4) Internet Protocol Version 6 Version: 6 Traffic class: 0x00 Flowlabel: 0x00000 Payload length: 20 Next header: TCP (0x06) Hop limit: 64 Source address: ::192.168.52.2 Destination address: ::192.168.46.4 Transmission Control Protocol, Src Port: 1055 (1055), Dst Port: bgp (179), Seq: 2091346881, Ack: 0 Source port: 1055 (1055) Destination port: bgp (179) Sequence number: 2091346881 Header length: 20 bytes Flags: 0x0004 (RST) 0... .... = Congestion Window Reduced (CWR): Not set .0.. .... = ECN-Echo: Not set ..0. .... = Urgent: Not set ...0 .... = Acknowledgment: Not set .... 0... = Push: Not set .... .1.. = Reset: Set .... ..0. = Syn: Not set .... ...0 = Fin: Not set Window size: 0 Checksum: 0xdf4e (correct) Can someone help us? Is it a sit0 bug? Regards, Gilles -- Gilles Diribarne Alcatel Research & Innovation Gilles.Diribarne@alcatel.fr Tel: +33 (0)1 69 63 46 45 Fax: +33 (0)1 69 63 11 69 From owner-netdev@oss.sgi.com Fri Apr 20 14:12:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3KLCJC10092 for netdev-outgoing; Fri, 20 Apr 2001 14:12:19 -0700 Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f3KLCHM10085 for ; Fri, 20 Apr 2001 14:12:18 -0700 Received: (qmail 15507 invoked from network); 20 Apr 2001 21:12:14 -0000 Received: from p3e9b8e5c.dip.t-dialin.net (HELO worker.bieringer.de) (62.155.142.92) by mail.bieringer.de with SMTP; 20 Apr 2001 21:12:14 -0000 Message-Id: <5.1.0.14.0.20010420225936.00ad6e80@mail.bieringer.de> X-Sender: list4peter@mail.bieringer.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 X-Priority: 4 (Low) Date: Fri, 20 Apr 2001 23:14:21 +0200 To: Ra Chen , netdev@oss.sgi.com From: Peter Bieringer Subject: Re: obvious ndisc.c bug In-Reply-To: <92C0C0AC8AE8D411864300105A835CBB50A5B1@stslex.siemens.com. tw> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-netdev@oss.sgi.com Precedence: bulk At 13:31 19.04.2001, Ra Chen wrote: >net/ipv6/ndisc.c in kernel 2.4.3 >line 1076: > >if ((ipv6_addr_type(saddr)&IPV6_ADDR_MULTICAST) && > >"saddr" should be "daddr". Looks like that in the USAGI patch this was already fixed some times ago. Does anyone know the current state about migrate of parts of USAGI into vanilla? BTW: Looks like 2.2.19 must be fixed, too (also already fixed in USAGI patch), line 1016: case NDISC_NEIGHBOUR_ADVERTISEMENT: if ((ipv6_addr_type(saddr)&IPV6_ADDR_MULTICAST) && msg->icmph.icmp6_solicited) { BTW: Perhaps this solves the problem reported few days ago. TIA, Peter From owner-netdev@oss.sgi.com Sun Apr 22 02:41:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3M9faN03184 for netdev-outgoing; Sun, 22 Apr 2001 02:41:36 -0700 Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f3M9fZM03181 for ; Sun, 22 Apr 2001 02:41:35 -0700 Received: (qmail 4198 invoked from network); 22 Apr 2001 09:41:17 -0000 Received: from pd95024a4.dip.t-dialin.net (HELO worker.bieringer.de) (217.80.36.164) by mail.bieringer.de with SMTP; 22 Apr 2001 09:41:17 -0000 Message-Id: <5.1.0.14.0.20010422113805.00b0c330@mail.bieringer.de> X-Sender: list4peter@mail.bieringer.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 22 Apr 2001 11:43:35 +0200 To: Bill Robertson , netdev@oss.sgi.com From: Peter Bieringer Subject: Re: IPv6: 2.4.2/3 autoconfiguration sometimes didn't work In-Reply-To: <4.2.2.20010419075418.0224f5f0@pop.crc.ca> References: <5.0.2.1.0.20010419092037.00af7d28@mail.bieringer.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-netdev@oss.sgi.com Precedence: bulk At 15:14 19.04.2001, Bill Robertson wrote: >I have a 2 host network with a 2.2.19 based router running radvd 0.6.2 >(not p11) and a 2.2.19 based client and am having the same problem as >Peter. Most of the time the client doesn't autoconfigure itself to the >site local address being provided in the router advertisements. > >I tried both "/etc/rc.d/init.d/network restart" and Peter's suggestion of >"ifconfig eth0 down" followed about 60 seconds later by "ifconfig eth0 >up". Neither seems to work. Looks like the old (USAGI already knows about) IPv6 multicast bind bug isn't yet fixed. After booting, following route occurs: ff02::1/128 ff02::1 UAC 0 1 1 eth0 If network is restarted *and* network driver module wasn't removed, this route is not setup again by the kernel. If you stop networking, remove the driver module and start networking again, this route is setup again and autoconfiguration works. My randomness experiences perhaps depends on the module-autoremovable mechanism (but don't be shure). Any hints, why this already known bug is still fixed now? Unlike I hoped, the ndisc.c fix doesn't fix this problem. Peter From owner-netdev@oss.sgi.com Mon Apr 23 01:13:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3N8Dj712269 for netdev-outgoing; Mon, 23 Apr 2001 01:13:45 -0700 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3N8DjM12265 for ; Mon, 23 Apr 2001 01:13:45 -0700 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id BAA11111 for ; Mon, 23 Apr 2001 01:13:43 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id BAA11235 for ; Mon, 23 Apr 2001 01:13:43 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r3.mot.com with ESMTP for netdev@oss.sgi.com; Mon, 23 Apr 2001 01:13:33 -0700 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id KAA08487 for netdev@oss.sgi.com.DELIVER; Mon, 23 Apr 2001 10:13:40 +0200 (METDST) Received: from crm.mot.com (varagnat@riri.crm.mot.com [140.101.173.128]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id KAA08457 for ; Mon, 23 Apr 2001 10:13:39 +0200 (METDST) Message-Id: <3AE3E3CF.B9E6C5C5@crm.mot.com> Date: Mon, 23 Apr 2001 10:11:59 +0200 From: Emmanuel Varagnat Organization: Motorola X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: "netdev@oss.sgi.com" Subject: PMTU discovery Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, I would like to know if the PTMU discovery for IPv6 is totally implemented in Linux ? It seems that the kernel only process ICMP 'Packet Too Big' messages and never try to increase the packet size in the case of a change in the route. Am I right or wrong ? Thanks. -Emmanuel Varagnat From owner-netdev@oss.sgi.com Mon Apr 23 05:27:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3NCRM222117 for netdev-outgoing; Mon, 23 Apr 2001 05:27:22 -0700 Received: from roll.cefriel.it (roll.cefriel.it [131.175.53.4]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3NCRJM22104 for ; Mon, 23 Apr 2001 05:27:19 -0700 Received: by roll.cefriel.it with Internet Mail Service (5.5.2650.21) id ; Mon, 23 Apr 2001 14:27:21 +0200 Message-ID: <76D2776C1B442B4C90E1F95FCA217C46866D4C@roll.cefriel.it> From: Paolo Castagna To: "'Networking Team'" Subject: [help] TCP rate control and Linux? Date: Mon, 23 Apr 2001 14:27:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 7189 Lines: 183 --------------------------------------------------------------------- Hi, I'm an Italian student and I'm doing a Master Thesis on TCP rate control. TCP rate control is a new technique for transparently augmenting end-to-end TCP performance by controlling the sending rate of a TCP source. The sending rate of a TCP source is determined by its window size, the round trip time and the rate of acknowledgments. TCP rate control affects these aspects by modifying the ack number and receiver window fields in acknowledgments and by modulating the acknowledgment rate. From a performance viewpoint a key benefit of TCP rate control is to avoid adverse performance effects due to packet losses such as reduced goodput and unfairness or large spread in per-user goodputs. Further, TCP rate control positively affects performance even if the bottleneck is non-local and the end-host TCP implementations are non-conforming. [see article below] I would like to know your opinions about that, and if there is already something similar in the Linux world. I've already see the kernel sources but I didn't find something like that. I'll appreciate suggestion about how to implement such ideas on Linux, specifically in the kernel 2.4.3. There are two algorithms in the TCP rate control technique, as describe in the paper below, may be usefull for you to have the algorithms: --------------------------------------------------------------------- Algorithm 1 - Rate Allocation Algorithm The goal of this algorithm is to allocate max-min fair rates to competing TCP flows. Initially, equal rate allocations are given to all competing flows. Then sending rates of flows are estimated by maintaining an exponential average over a rate sampling interval. When a flow does not to utilize its allocation, it is labeled as bottlenecked. Excess allocation is stripped off from all such bottlenecked flows and allocated to non-bottlenecked or hungry flows. This step is repeated until there is no residual bandwidth to allocate or all flows are bottlenecked. This algorithm is invoked every time a new flow begins, a flow terminates or when the rate sampling interval expires. The resulting rate allocations are stored into a table. --------------------------------------------------------------------- 1. For each flow i, let Ri be the measured rate and Ai be the allocated rate. 2. If N is the total number of flows and B is the bottleneck capacity, the initial allocation for each flow i is Ai = B / N (2) 3. If Ri < (p * Ai) for some satisfaction percentage p (a statically chosen parameter), then mark flow i as bottlenecked, else mark it as hungry. 4. Let U be the aggregate residual bandwidth i.e the bandwidth which remains unutilized by the bottlenecked flows. 5. Distribute this residual bandwidth evenly over all the hungry flows. If H is the total number of hungry flows, the new allocation for a hungry flow j is given by Aj = Aj + (U / H) (3) 6. For each bottlenecked flow k the new allocation is given by Ak = (Ak + Rk) / 2 (4) So for bottlenecked flows, the allocation approaches the measured rate over successive iterations of the algorithm. --------------------------------------------------------------------- About this algorithm, I've a problem... how can I measure the rate Ri for each TCP flow? I've found NeTraMet on this URL: http://www.auckland.ac.nz/net/Accounting/ntm.Release.note.html ... and I've also read the discussion about that on linux-kernel mailing list. Where is the best place to make a such thing? I've thought in /net/core/dev.c in function dev_queue_xmit. And, again, how can I associate the rate Ri to each TCP flow? --------------------------------------------------------------------- Algorithm 2 - Rate Enforcement Algorithm This algorithm enforces the rate allocation by converting the rate to a window value. Additionally, it spaces out the acknowledgments of a flow, so that they are evenly distributed over its RTT. --------------------------------------------------------------------- 1. For each flow i let wi = the calculated window size in units of packets. Di = the inter-ack spacing in seconds. RTTi = the round trip time (RTT) of flow i, ideally not including queuing delays, in seconds. MSSi = the maximum segment size of flow i, in bytes. Ai = the rate allocation in bytes/s. 2. Observe that for each flow i, we have: wi * MSSi = Ai * RTTi (5) So the window value can be calculated as, wi = (Ai * RTTi) / MSSi (6) 3. The inter-ack spacing time (RTTi/wi) can also be obtained from equation (5): Di = RTTi / wi = MSSi / Ai (7) 4. For each flow i, acks (if available) are clocked out at intervals of Di with the receiver window field set to Wi. 5. The receiver window field of the ack of flow i is set as: Wi = min(wi * MSSi , actual receiver window) (8) 6. The ack number field in the header is determined based upon two variables (max and min sequence number) used to denote the ack queue. In the common case, the ack number would be chosen to progress by one MSSi. --------------------------------------------------------------------- About this algorithm, where is, for you, the best place where to do a such thing? In general I'd like to do only minor changes possible in the kernel sources, and I would like to implement a module for TCP rate control. I've also found an usefull paper by Glenn Herrin, I've try the example with the kernel v2.4.3 but I've some problem with it: when I export a symbol from the kernel, using EXPORT_SYMBOL and I try to use it from a module I have the error: "undefined symbol in mymodule" even if it's listed in /boot/System.map --------------------------------------------------------------------- Papers: o Shrikrishna Karandikar, Shivkumar Kalyanaraman, Prasad Bagal, Bob Packer, "TCP Rate Control", Computer Communication Review, a publication of ACM SIGCOMM, volume 30, number 1, January 2000. ISSN # 0146-4833. URL: http://www.acm.org/sigcomm/ccr/archive/2000/jan00/ccr-200001-kara.html o Glenn Herrin, Linux IP Networking, A Guide to the Implementation and Modification of the Linux Protocol Stack TR 00-04, May 31, 2000 URL: http://kernelnewbies.org/documents/ipnetworking/ o Others interesting papers: URL: http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers-rpi.html#tcp --------------------------------------------------------------------- Commercial products based on idea of TCP Rate Control: o Packeteer - http://www.packeteer.com/ [nasdaq: PKTR] o Allot - http://www.allot.com/ --------------------------------------------------------------------- I beg your pardon for the lenght of this message, and also for my bad english :/ I hope this is the right place for a such discussion, if not, please, excuse me, and if you know send me some references. Greetings, Paolo Castagna. From owner-netdev@oss.sgi.com Mon Apr 23 06:59:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3NDxF326601 for netdev-outgoing; Mon, 23 Apr 2001 06:59:15 -0700 Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3NDxDM26598 for ; Mon, 23 Apr 2001 06:59:14 -0700 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id OAA28943; Mon, 23 Apr 2001 14:44:41 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id PAA08738; Mon, 23 Apr 2001 15:52:49 +0200 (MET DST) Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id PAA12641; Mon, 23 Apr 2001 15:58:48 +0200 (MET DST) Received: from ms.alcatel.fr (spip [188.9.249.125]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id PAA23623; Mon, 23 Apr 2001 15:58:55 +0200 (MET DST) Message-ID: <3AE43399.2570AF7A@ms.alcatel.fr> Date: Mon, 23 Apr 2001 15:52:25 +0200 From: Gilles Diribarne Organization: Alcatel CRC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.3 i686) X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: Linux net , Usagi Subject: Problem with sit0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 672 Lines: 28 Hi, If you create a tunnel, there is a problem with TCPv6 connection. Does anyone can help me? # ifconfig sit0 up # route -Ainet6 add ::/96 dev sit0 After, I make a ping6 ::IPv4 address and it works (the ping machine is Dual Stack) But, when using TCPv6, it doesn't work. I try to make with zebra bgpd (a TCP client/server) and it doesn't work. Thanks to Ethereal, I have some traces. (It's TCPv6 -> IPv6 -> IPv4) TCP client makes a SYN. TCP server make SYN,ACK But after, TCP client makes RST? What does it mean? Thanks, Gilles -- Gilles Diribarne Alcatel Research & Innovation Gilles.Diribarne@alcatel.fr Tel: +33 (0)1 69 63 46 45 Fax: +33 (0)1 69 63 11 69 From owner-netdev@oss.sgi.com Mon Apr 23 19:29:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3O2TJf24613 for netdev-outgoing; Mon, 23 Apr 2001 19:29:19 -0700 Received: from shell.cyberus.ca (shell.cyberus.ca [209.195.95.7]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3O2THM24610 for ; Mon, 23 Apr 2001 19:29:18 -0700 Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.3/666/Cyberus Online Inc.) with ESMTP id WAA13812; Mon, 23 Apr 2001 22:27:44 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 23 Apr 2001 22:27:44 -0400 (EDT) From: jamal To: cc: , Andi Kleen , Subject: Re: mroute.h patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 741 Lines: 26 davem> So how does mroute.h get SIOCPROTOPRIVATE if it does not include davem> sockios.h? mrouted doesnt seem to care. But you are right, that was my own overlook; infact sockios.h doesnt cause any conflicts. OTOH, this could be a user-space problem. I have received a couple of emails from people who say that they have managed to get mrouted compiled just fine without the kernel patch using: ftp://parcftp.xerox.com/pub/net-research/ipmulti/beta-test/mrouted-3.9-beta3.tar.gz and the debian patch at: ftp://ftp.debian.org/debian/dists/potato/non-free/source/net/mrouted_3.9-beta3-1.diff.gz Although i tried the debian patch it didnt help me. Could someone else try this out? I use Conectiva (6.0) these days .... cheers, jamal From owner-netdev@oss.sgi.com Mon Apr 23 19:39:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3O2dDt25211 for netdev-outgoing; Mon, 23 Apr 2001 19:39:13 -0700 Received: from shell.cyberus.ca (shell.cyberus.ca [209.195.95.7]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3O2dAM25208 for ; Mon, 23 Apr 2001 19:39:11 -0700 Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.3/666/Cyberus Online Inc.) with ESMTP id WAA13862; Mon, 23 Apr 2001 22:37:46 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 23 Apr 2001 22:37:46 -0400 (EDT) From: jamal To: Paolo Castagna cc: "'Networking Team'" Subject: Re: [help] TCP rate control and Linux? In-Reply-To: <76D2776C1B442B4C90E1F95FCA217C46866D4C@roll.cefriel.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 8299 Lines: 209 Well, normally this kind of activity is considered harmful to the tao of the internet. It breaks the end2end semantics of TCP. But why should you care, right? People are getting stinking rich for breaking end to end principle every day. So there must be something good or right about this. Maybe the end2end principle is too old. Typically, a device like this would sit between end nodes and the network. So you wanna sit in something like a router. You would need to maintain TCP state per-flow; probably look at the stateful netfilter code for starters. Infact, your life would be a lot simpler if you just extended that code. As a word of caution if i was you i'll double check that there are no patents involved with packeteer's work (I woul dbe shocked if there were none). cheers, jamal On Mon, 23 Apr 2001, Paolo Castagna wrote: > --------------------------------------------------------------------- > Hi, > I'm an Italian student and I'm doing a Master Thesis on TCP rate > control. > > TCP rate control is a new technique for transparently augmenting > end-to-end TCP performance by controlling the sending rate of a TCP > source. The sending rate of a TCP source is determined by its window > size, the round trip time and the rate of acknowledgments. > TCP rate control affects these aspects by modifying the ack number > and receiver window fields in acknowledgments and by modulating the > acknowledgment rate. From a performance viewpoint a key benefit of > TCP rate control is to avoid adverse performance effects due to > packet losses such as reduced goodput and unfairness or large spread > in per-user goodputs. Further, TCP rate control positively affects > performance even if the bottleneck is non-local and the end-host > TCP implementations are non-conforming. [see article below] > > I would like to know your opinions about that, and if there is > already something similar in the Linux world. I've already see > the kernel sources but I didn't find something like that. > > I'll appreciate suggestion about how to implement such ideas on > Linux, specifically in the kernel 2.4.3. > There are two algorithms in the TCP rate control technique, as > describe in the paper below, may be usefull for you to have the > algorithms: > > --------------------------------------------------------------------- > > Algorithm 1 - Rate Allocation Algorithm > > The goal of this algorithm is to allocate max-min fair rates to > competing TCP flows. Initially, equal rate allocations are given to > all competing flows. Then sending rates of flows are estimated by > maintaining an exponential average over a rate sampling interval. > When a flow does not to utilize its allocation, it is labeled as > bottlenecked. Excess allocation is stripped off from all such > bottlenecked flows and allocated to non-bottlenecked or hungry flows. > This step is repeated until there is no residual bandwidth to > allocate or all flows are bottlenecked. This algorithm is invoked > every time a new flow begins, a flow terminates or when the rate > sampling interval expires. The resulting rate allocations are > stored into a table. > > --------------------------------------------------------------------- > > 1. For each flow i, let Ri be the measured rate > and Ai be the allocated rate. > > 2. If N is the total number of flows and B is the bottleneck > capacity, the initial allocation for each flow i is > > Ai = B / N (2) > > 3. If Ri < (p * Ai) for some satisfaction percentage p > (a statically chosen parameter), then mark flow i as > bottlenecked, else mark it as hungry. > > 4. Let U be the aggregate residual bandwidth i.e the > bandwidth which remains unutilized by the bottlenecked > flows. > > 5. Distribute this residual bandwidth evenly over all the > hungry flows. If H is the total number of hungry flows, > the new allocation for a hungry flow j is given by > > Aj = Aj + (U / H) (3) > > 6. For each bottlenecked flow k the new allocation is > given by > > Ak = (Ak + Rk) / 2 (4) > > So for bottlenecked flows, the allocation approaches > the measured rate over successive iterations of the > algorithm. > > --------------------------------------------------------------------- > > About this algorithm, I've a problem... how can I measure the rate > Ri for each TCP flow? I've found NeTraMet on this URL: > http://www.auckland.ac.nz/net/Accounting/ntm.Release.note.html > ... and I've also read the discussion about that on linux-kernel > mailing list. Where is the best place to make a such thing? > I've thought in /net/core/dev.c in function dev_queue_xmit. > And, again, how can I associate the rate Ri to each TCP flow? > > --------------------------------------------------------------------- > > Algorithm 2 - Rate Enforcement Algorithm > > This algorithm enforces the rate allocation by converting the rate > to a window value. Additionally, it spaces out the acknowledgments > of a flow, so that they are evenly distributed over its RTT. > > --------------------------------------------------------------------- > > 1. For each flow i let > > wi = the calculated window size in units of packets. > Di = the inter-ack spacing in seconds. > RTTi = the round trip time (RTT) of flow i, ideally > not including queuing delays, in seconds. > MSSi = the maximum segment size of flow i, in bytes. > Ai = the rate allocation in bytes/s. > > 2. Observe that for each flow i, we have: > > wi * MSSi = Ai * RTTi (5) > > So the window value can be calculated as, > > wi = (Ai * RTTi) / MSSi (6) > > 3. The inter-ack spacing time (RTTi/wi) can also be > obtained from equation (5): > > Di = RTTi / wi = MSSi / Ai (7) > > 4. For each flow i, acks (if available) are clocked out > at intervals of Di with the receiver window field set > to Wi. > > 5. The receiver window field of the ack of flow i is set as: > > Wi = min(wi * MSSi , actual receiver window) (8) > > 6. The ack number field in the header is determined based > upon two variables (max and min sequence number) used to > denote the ack queue. In the common case, the ack number > would be chosen to progress by one MSSi. > > --------------------------------------------------------------------- > > About this algorithm, where is, for you, the best place > where to do a such thing? In general I'd like to do only minor > changes possible in the kernel sources, and I would like to > implement a module for TCP rate control. > I've also found an usefull paper by Glenn Herrin, I've try the > example with the kernel v2.4.3 but I've some problem with it: > when I export a symbol from the kernel, using EXPORT_SYMBOL and I > try to use it from a module I have the error: "undefined symbol in > mymodule" even if it's listed in /boot/System.map > > --------------------------------------------------------------------- > > Papers: > > o Shrikrishna Karandikar, Shivkumar Kalyanaraman, > Prasad Bagal, Bob Packer, > "TCP Rate Control", > Computer Communication Review, a publication of ACM SIGCOMM, > volume 30, number 1, January 2000. ISSN # 0146-4833. > URL: > http://www.acm.org/sigcomm/ccr/archive/2000/jan00/ccr-200001-kara.html > > o Glenn Herrin, > Linux IP Networking, > A Guide to the Implementation and > Modification of the Linux Protocol Stack > TR 00-04, May 31, 2000 > URL: http://kernelnewbies.org/documents/ipnetworking/ > > o Others interesting papers: > URL: > http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers-rpi.html#tcp > > --------------------------------------------------------------------- > > Commercial products based on idea of TCP Rate Control: > > o Packeteer - http://www.packeteer.com/ [nasdaq: PKTR] > o Allot - http://www.allot.com/ > > --------------------------------------------------------------------- > > I beg your pardon for the lenght of this message, and also for my > bad english :/ I hope this is the right place for a such discussion, > if not, please, excuse me, and if you know send me some references. > > Greetings, > Paolo Castagna. > From owner-netdev@oss.sgi.com Mon Apr 23 20:13:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3O3DKT26362 for netdev-outgoing; Mon, 23 Apr 2001 20:13:20 -0700 Received: from web14008.mail.yahoo.com (web14008.mail.yahoo.com [216.136.175.124]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f3O3DJM26359 for ; Mon, 23 Apr 2001 20:13:20 -0700 Message-ID: <20010424031319.21022.qmail@web14008.mail.yahoo.com> Received: from [156.153.255.236] by web14008.mail.yahoo.com; Mon, 23 Apr 2001 20:13:19 PDT Date: Mon, 23 Apr 2001 20:13:19 -0700 (PDT) From: Cacophonix Subject: Re: mroute.h patch To: jamal Cc: netdev@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1578 Lines: 50 I can confirm that these compile fine for me (after adding a #include to main.c), debian woody + 2.4.3 (in the recent past I've also tried this on on redhat 6.2 + 2.3.x) I can also confirm that this version did connect to the Mbone, and learn all the DVMRP routes being presented to my gateway (although there were unrelated problems in our MBone ISP that reduced the number of routes being advertised to our gateway by half). Also, I remember running into the Cisco interoperability issues on mrouted versions prior to 3.9 beta-3 (which is the reason for beta 3). cheers, karthik --- jamal wrote: > > > davem> So how does mroute.h get SIOCPROTOPRIVATE if it does not include > davem> sockios.h? > > mrouted doesnt seem to care. But you are right, that was my own overlook; > infact sockios.h doesnt cause any conflicts. > OTOH, this could be a user-space problem. I have received a couple of > emails from people who say that they have managed to get mrouted compiled > just fine without the kernel patch using: > > ftp://parcftp.xerox.com/pub/net-research/ipmulti/beta-test/mrouted-3.9-beta3.tar.gz > > and the debian patch at: > > ftp://ftp.debian.org/debian/dists/potato/non-free/source/net/mrouted_3.9-beta3-1.diff.gz > > Although i tried the debian patch it didnt help me. Could someone else > try this out? > > I use Conectiva (6.0) these days .... > > cheers, > jamal > > __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-netdev@oss.sgi.com Mon Apr 23 20:35:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3O3ZWS27274 for netdev-outgoing; Mon, 23 Apr 2001 20:35:32 -0700 Received: from shell.cyberus.ca (shell.cyberus.ca [209.195.95.7]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3O3ZTM27265 for ; Mon, 23 Apr 2001 20:35:29 -0700 Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.3/666/Cyberus Online Inc.) with ESMTP id XAA14058; Mon, 23 Apr 2001 23:34:05 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 23 Apr 2001 23:34:05 -0400 (EDT) From: jamal To: Cacophonix cc: , Subject: Re: mroute.h patch In-Reply-To: <20010424031319.21022.qmail@web14008.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2098 Lines: 74 On Mon, 23 Apr 2001, Cacophonix wrote: > I can confirm that these compile fine for me (after adding a #include to > main.c), debian woody + 2.4.3 (in the recent past I've also tried this on > on redhat 6.2 + 2.3.x) > Thanks for the info. So thats three people. Note my main contention seems to be linux/in.h since mrouted makes reference to netinet/in.h I just cant seem to get the compile any other way. Acme, can you try the URL i posted? > I can also confirm that this version did connect to the Mbone, and learn all the > DVMRP routes being presented to my gateway (although there were unrelated problems > in our MBone ISP that reduced the number of routes being advertised to our > gateway by half). > DVMRP tunnels seem to work fine over here. > Also, I remember running into the Cisco interoperability issues on mrouted versions > prior to 3.9 beta-3 (which is the reason for beta 3). Would that be the hacks in: ftp://ftp.research.att.com/dist/fenner/mrouted/mrouted-3.9-beta3+IOS12.tar.Z cheers, jamal > > cheers, > karthik > > > --- jamal wrote: > > > > > > davem> So how does mroute.h get SIOCPROTOPRIVATE if it does not include > > davem> sockios.h? > > > > mrouted doesnt seem to care. But you are right, that was my own overlook; > > infact sockios.h doesnt cause any conflicts. > > OTOH, this could be a user-space problem. I have received a couple of > > emails from people who say that they have managed to get mrouted compiled > > just fine without the kernel patch using: > > > > ftp://parcftp.xerox.com/pub/net-research/ipmulti/beta-test/mrouted-3.9-beta3.tar.gz > > > > and the debian patch at: > > > > > ftp://ftp.debian.org/debian/dists/potato/non-free/source/net/mrouted_3.9-beta3-1.diff.gz > > > > Although i tried the debian patch it didnt help me. Could someone else > > try this out? > > > > I use Conectiva (6.0) these days .... > > > > cheers, > > jamal > > > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Auctions - buy the things you want at great prices > http://auctions.yahoo.com/ > From owner-netdev@oss.sgi.com Tue Apr 24 01:31:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3O8ViQ04366 for netdev-outgoing; Tue, 24 Apr 2001 01:31:44 -0700 Received: from zmailer.org (mail.zmailer.org [194.252.70.162]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3O8VgM04355 for ; Tue, 24 Apr 2001 01:31:42 -0700 Received: (from localhost user: 'mea' uid#500 fake: STDIN (mea@zmailer.org)) by mail.zmailer.org id ; Tue, 24 Apr 2001 11:31:10 +0300 Date: Tue, 24 Apr 2001 11:31:10 +0300 From: Matti Aarnio To: Paolo Castagna Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [help] TCP rate control and Linux TCP/IP Stack? Message-ID: <20010424113110.Y805@mea-ext.zmailer.org> References: <76D2776C1B442B4C90E1F95FCA217C46866D65@roll.cefriel.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76D2776C1B442B4C90E1F95FCA217C46866D65@roll.cefriel.it>; from castagna@cefriel.it on Tue, Apr 24, 2001 at 10:11:15AM +0200 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1404 Lines: 38 On Tue, Apr 24, 2001 at 10:11:15AM +0200, Paolo Castagna wrote: > Hi, > I'm an Italian student and I'm doing a Master Thesis on TCP rate > control. You have already posted this very same message to linux-net@vger.kernel.org and: netdev@oss.sgi.com lists. If you don't get reply from those (netdev mainly), the linux-kernel is not going to yield cheers either. People that know the networking code intimately are presently "somewhat" busy, Be patient, repeat this topic at netdev list after about a week. .... > --------------------------------------------------------------------- > About this algorithm, I've a problem... how can I measure the rate > Ri for each TCP flow? I've found NeTraMet on this URL: > http://www.auckland.ac.nz/net/Accounting/ntm.Release.note.html > ... and I've also read the discussion about that on linux-kernel > mailing list. Where is the best place to make a such thing? > I've thought in /net/core/dev.c in function dev_queue_xmit. > And, again, how can I associate the rate Ri to each TCP flow? TCP Timestamps ? (Which Linux does use if the other end supports them too.) Of course, what is "rate" ? Units of something per units of time ? Packets ? Payload bytes ? How does the size of payload data in the packets affect the "rate" ? ... > Greetings, > Paolo Castagna. /Matti Aarnio From owner-netdev@oss.sgi.com Tue Apr 24 01:32:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3O8WMj04445 for netdev-outgoing; Tue, 24 Apr 2001 01:32:22 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3O8WKM04441 for ; Tue, 24 Apr 2001 01:32:21 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f3O8WJt14642 for ; Tue, 24 Apr 2001 11:32:19 +0300 Date: Tue, 24 Apr 2001 11:32:19 +0300 (EEST) From: Pekka Savola To: Subject: PATCH: IPv6: 2.4.2/3 autoconfiguration sometimes didn't work Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2009 Lines: 76 Hello all, Autoconfiguration seems to work after 'ifdown eth0 ; ifup eth0', if you apply USAGI patch: http://www.linux-ipv6.org/cvsweb/usagi/kernel/linux24/net/ipv6/addrconf.c.diff?r1=1.1&r2=1.2 ( I applied this on top of RHL71 kernel, with core/neighbour.c changes, but the latter shouldn't affect this ) That is: --- =================================================================== RCS file: /cvsroot/usagi/usagi/kernel/linux24/net/ipv6/addrconf.c,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- usagi/kernel/linux24/net/ipv6/addrconf.c 2000/08/25 02:29:26 1.1 +++ usagi/kernel/linux24/net/ipv6/addrconf.c 2000/09/01 08:56:22 1.2 @@ -6,7 +6,7 @@ * Pedro Roque * Alexey Kuznetsov * - * $Id: addrconf.c,v 1.1 2000/08/25 02:29:26 yoshfuji Exp $ + * $Id: addrconf.c,v 1.2 2000/09/01 08:56:22 sekiya Exp $ * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -282,8 +282,6 @@ if ((idev = __in6_dev_get(dev)) == NULL) { if ((idev = ipv6_add_dev(dev)) == NULL) return NULL; - if (dev->flags&IFF_UP) - ipv6_mc_up(idev); } return idev; } @@ -1179,6 +1177,8 @@ return; } + ipv6_mc_up(idev); + ifp = ipv6_add_addr(idev, &addr, 128, IFA_HOST, IFA_F_PERMANENT); if (ifp) { spin_lock_bh(&ifp->lock); @@ -1217,6 +1217,8 @@ if (idev == NULL) return; + ipv6_mc_up(idev); + #ifdef CONFIG_IPV6_EUI64 memset(&addr, 0, sizeof(struct in6_addr)); @@ -1255,6 +1257,7 @@ printk(KERN_DEBUG "init sit: add_dev failed\n"); return; } + ipv6_mc_up(idev); sit_add_v4_addrs(idev); --- Please verify if this helps for others? If so, can the modification be checked if it's good, and if so, integrated? HTH, -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Tue Apr 24 07:04:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3OE4pn18733 for netdev-outgoing; Tue, 24 Apr 2001 07:04:51 -0700 Received: from moon.mt.lv (root@moon.mt.lv [159.148.147.194]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3OE4oM18730 for ; Tue, 24 Apr 2001 07:04:50 -0700 Received: from localhost.localdomain (IDENT:root@karlis.dev.mt.lv [10.0.0.16]) by moon.mt.lv (8.9.3/8.9.3) with ESMTP id QAA14236 for ; Tue, 24 Apr 2001 16:04:47 +0200 Date: Tue, 24 Apr 2001 17:04:09 +0200 From: Karlis To: netdev@oss.sgi.com Subject: looks like small bug in fib Message-ID: <20010424170409.A14444@karlis.dev.mt.lv> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.0.1 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 310 Lines: 11 Hello, Kernel 2.2.x. When removing last address from interface that is used as preferred source address for route going to another interface, this route does not dissapear (in all the rest situations removing address that is used as preferred source address for route, silently removes this route). Karlis From owner-netdev@oss.sgi.com Tue Apr 24 08:14:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3OFEMs23018 for netdev-outgoing; Tue, 24 Apr 2001 08:14:22 -0700 Received: from zmailer.org (mail.zmailer.org [194.252.70.162]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3OFEKM23015 for ; Tue, 24 Apr 2001 08:14:21 -0700 Received: (from localhost user: 'mea' uid#500 fake: STDIN (mea@zmailer.org)) by mail.zmailer.org id ; Tue, 24 Apr 2001 18:13:44 +0300 Date: Tue, 24 Apr 2001 18:13:44 +0300 From: Matti Aarnio To: netdev@oss.sgi.com Subject: [benc@hawaga.org.uk: Linux "enable EUI-64 token format"] Message-ID: <20010424181344.C805@mea-ext.zmailer.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="WP/lS5xSWAOC+/uo" Content-Disposition: inline Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1433 Lines: 50 --WP/lS5xSWAOC+/uo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This issue seems to pop up every now and then. Would it not be usefull to switch from "explitely enable this" to "disable this, unless you want to use this obsolete form" Or for that matter, to have e.g. interface specific sysctl or some such to control the behaviour -- if the old form is desirable at all.. USAGI might have done something along these lines as well. /Matti Aarnio --WP/lS5xSWAOC+/uo Content-Type: message/rfc822 Content-Disposition: inline Date: Tue, 24 Apr 2001 11:21:37 +0000 (UTC) From: Ben Clifford To: 6bone@ISI.EDU Subject: Linux "enable EUI-64 token format" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Can anyone explain or provide references to what the linux 2.4 kernel option CONFIG_IPV6_EUI64 "Enable EUI-64 token format" means? The kernel config help says that "6bone ... is moving to a new aggregatable address format and a new link local address assignment (EUI-64)". Is this documented in RFCs for example? If so, which ones? I'm not having any problems - I just want to know what it means :-) Thanks, Ben -- http://www.hawaga.org.uk/travel/ for my rotating world map applet http://www.hawaga.org.uk/benc_key.txt PGP / GPG key 0x30F06950 - please use it! --WP/lS5xSWAOC+/uo-- From owner-netdev@oss.sgi.com Wed Apr 25 07:01:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3PE1FX01898 for netdev-outgoing; Wed, 25 Apr 2001 07:01:15 -0700 Received: from havoc.gtf.org (IDENT:postfix@panic.ohr.gatech.edu [130.207.47.194]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3PE1EM01895 for ; Wed, 25 Apr 2001 07:01:14 -0700 Received: from mandrakesoft.com (adsl-20-73-169.asm.bellsouth.net [66.20.73.169]) by havoc.gtf.org (Postfix) with ESMTP id 8F92E1F6A; Wed, 25 Apr 2001 09:24:21 -0400 (EDT) Message-ID: <3AE6D007.4F519933@mandrakesoft.com> Date: Wed, 25 Apr 2001 09:24:23 -0400 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4-pre6 i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux Kernel Mailing List , netdev@oss.sgi.com Subject: Announce: ECN vendor support page Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 694 Lines: 19 To all-- As ECN deployment increases, people are increasingly noticing that some key web sites are still inaccessible when ECN is enabled. A Web site has been created to assist with this transition, with two key features: (1) ECN-related fixes are posted on this Web page, and (2) vendors whose products are broken are posted on this Web page. The address is http://gtf.org/garzik/ecn/ If you have comments, fixes or updates for this Web page, especially new links to vendor fixes or acknowledged vendor bugs, please e-mail them to ecn@gtf.org. -- Jeff Garzik | You know, I like you Stuart. Building 1024 | You're not like the other kids MandrakeSoft | in the trailer park. From owner-netdev@oss.sgi.com Wed Apr 25 11:27:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3PIRcO12280 for netdev-outgoing; Wed, 25 Apr 2001 11:27:38 -0700 Received: from ns1.serialhacker.net (adsl-216-102-91-127.dsl.snfc21.pacbell.net [216.102.91.127]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3PIRbM12277 for ; Wed, 25 Apr 2001 11:27:37 -0700 Received: from champ.serialhacker.net (IDENT:root@champ.serialhacker.net [192.168.1.5]) by ns1.serialhacker.net (8.11.2/8.8.7) with ESMTP id f3PIRXA23416; Wed, 25 Apr 2001 11:27:33 -0700 Received: (from drew@localhost) by champ.serialhacker.net (8.11.2/8.8.7) id f3PIRWI01384; Wed, 25 Apr 2001 11:27:32 -0700 From: Drew Bertola MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15079.5908.713649.443565@champ.serialhacker.net> Date: Wed, 25 Apr 2001 18:27:32 +0000 () To: Jeff Garzik Cc: Linux Kernel Mailing List , netdev@oss.sgi.com Subject: Re: Announce: ECN vendor support page In-Reply-To: <3AE6D007.4F519933@mandrakesoft.com> References: <3AE6D007.4F519933@mandrakesoft.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Reply-To: drew@drewb.com Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 282 Lines: 13 little typo: >From 5. External resources (notice "Congrestion"): Sally Floyd's page on Explicit Congrestion Notification in TCP/IP. http://www.aciri.org/floyd/ecn.html -- Drew Bertola | Send a text message to my pager or cell ... | http://jpager.com/Drew From owner-netdev@oss.sgi.com Thu Apr 26 10:21:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3QHLZa18814 for netdev-outgoing; Thu, 26 Apr 2001 10:21:35 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3QHLZM18811 for ; Thu, 26 Apr 2001 10:21:35 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA08475 for ; Thu, 26 Apr 2001 10:32:11 -0700 (PDT) mail_from (koneazny@sgi.com) Received: from cheetah.americas.sgi.com (cheetah.americas.sgi.com [137.38.224.48]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA29848; Thu, 26 Apr 2001 12:20:18 -0500 (CDT) Received: from sgi.com (otter.americas.sgi.com [137.38.224.14]) by cheetah.americas.sgi.com (8.8.8/ASC-news-1.4) with ESMTP id MAA1061639; Thu, 26 Apr 2001 12:20:17 -0500 (CDT) Message-ID: <3AE858D1.B51C45CC@sgi.com> Date: Thu, 26 Apr 2001 12:20:17 -0500 From: Mark Koneazny Organization: sgi - asd group X-Mailer: Mozilla 4.75C-SGI [en] (X11; U; IRIX64 6.5 IP25) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: [Fwd: local_loopback disable] Content-Type: multipart/mixed; boundary="------------F59DF636164E02CB1D715F23" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 3584 Lines: 82 This is a multi-part message in MIME format. --------------F59DF636164E02CB1D715F23 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Anyone have any suggestions? Thanks, Mark K. --------------F59DF636164E02CB1D715F23 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by cheetah.americas.sgi.com (8.8.8/ASC-news-1.4) with ESMTP id DAA1011524 for ; Thu, 26 Apr 2001 03:58:05 -0500 (CDT) Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id DAA86887 for ; Thu, 26 Apr 2001 03:58:05 -0500 (CDT) Received: from sunsite.dk (sunsite.dk [130.225.51.30]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id BAA09945 for ; Thu, 26 Apr 2001 01:58:03 -0700 (PDT) mail_from (linux-acenic-return-879-koneazny=sgi.com@sunsite.dk) Received: (qmail 26783 invoked by alias); 26 Apr 2001 08:57:50 -0000 Mailing-List: contact linux-acenic-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes Delivered-To: mailing list linux-acenic@sunsite.dk Received: (qmail 26769 invoked from network); 26 Apr 2001 08:57:50 -0000 X-Authentication-Warning: lxplus001.cern.ch: ppieta owned process doing -bs Date: Thu, 26 Apr 2001 10:57:16 +0200 (CEST) From: Pekka Pietikainen X-Sender: ppieta@lxplus001.cern.ch To: "linux-acenic@sunsite.auc.dk" Subject: Re: local_loopback disable In-Reply-To: <3AE70B5A.F9BCA9BA@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mozilla-Status2: 00000000 On Wed, 25 Apr 2001, Steve Modica wrote: > > Mark> I'm attempting to test a single Alteon GbE card via an external > > Mark> loopback cable. I want to get data out on the cable. In the > > Mark> past, I have accomplished this under Irix (SGI unix) by > > Mark> disabling the following at /var/sysgen/master.d/bsd: > I suspect this is not an issue with the acenic card per se, but rather a > decision made in the ip layer. If it looks like the packet is meant for the > local machine, it probably calls loopback_xmit automagically. > Indeed, in Linux overriding loopback seems impossible by just doing some routing tricks, so you'll need to hack some code to make it work. What might work is compiling in the acenic driver statically, and changing drivers/net/Space.c so that dev_base points to eth0, and loopback is after that. Another possible place for modifications is net/ipv4/devinet.c, in inet_select_addr, just check the destination, and if it's not a loopback addr, ignore the loopback address. A third way of conning the machine to send the packets to the wire is to actually send them to another IP, then have a NAT rule to change the incoming packets to have your IP as the destination. If you're lucky it might even work ;) Anyway, the guys on netdev@oss.sgi.com are the best ones to ask about this, I'm sure they'll know. --------------------------------------------------------------------- To unsubscribe, e-mail: linux-acenic-unsubscribe@sunsite.dk For additional commands, e-mail: linux-acenic-help@sunsite.dk --------------F59DF636164E02CB1D715F23-- From owner-netdev@oss.sgi.com Fri Apr 27 01:43:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3R8hZN10450 for netdev-outgoing; Fri, 27 Apr 2001 01:43:35 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3R8hXM10447 for ; Fri, 27 Apr 2001 01:43:33 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f3R8hV125968; Fri, 27 Apr 2001 11:43:31 +0300 Date: Fri, 27 Apr 2001 11:43:30 +0300 (EEST) From: Pekka Savola To: cc: , Peter Bieringer Subject: IPv6: Autoconfiguring routers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1245 Lines: 37 Hello all, It appears that if you're acting as a router (forwarding on), all router advertisents are discarded (on forwarding interfaces at least), e.g. in net/ipv6/ndisc.c: --- static void ndisc_router_discovery(struct sk_buff *skb) [...] if (in6_dev->cnf.forwarding || !in6_dev->cnf.accept_ra) { in6_dev_put(in6_dev); return; } [...] --- (this can also be verified by enabling forwarding via /proc/sys/net/ipv6/conf/*/forwarding, deleting the autoconfigured address and waiting for the next router advertisement) If IP forwarding is enabled (e.g. router), _default route_ definitely should not be autoconfigured, but I see no reason why the announced prefix + link-local suffix couldn't be combined to form one of the interface addresses (on routers, all interfaces additionally probably have manually assigned addresses too). In FreeBSD Kame stack, sys/netinet6/nd6_rtr.c forwarding is only (apart from router solicitation considerations) considered in defrouter_select and defrtrlist_del functions. Any thoughts? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Fri Apr 27 01:51:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3R8pHk10962 for netdev-outgoing; Fri, 27 Apr 2001 01:51:17 -0700 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3R8pGM10957 for ; Fri, 27 Apr 2001 01:51:17 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id E07564B10; Fri, 27 Apr 2001 17:51:10 +0900 (JST) To: usagi-users@linux-ipv6.org Cc: netdev@oss.sgi.com, Peter Bieringer In-reply-to: pekkas's message of Fri, 27 Apr 2001 11:43:30 +0300. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: (usagi-users 00439) IPv6: Autoconfiguring routers From: itojun@iijlab.net Date: Fri, 27 Apr 2001 17:51:10 +0900 Message-ID: <10740.988361470@itojun.org> Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1150 Lines: 27 >If IP forwarding is enabled (e.g. router), _default route_ definitely >should not be autoconfigured, but I see no reason why the announced prefix >+ link-local suffix couldn't be combined to form one of the interface >addresses (on routers, all interfaces additionally probably have manually >assigned addresses too). RFC2462 talks about "host" autoconfiguration. autoconfiguration of a router is outside of the scope of the document. so i don't agree with you on "no reason why..." portion. btw, if all of your routers on the link is to be autoconfigured, how can you autoconfigure them??? :-) >In FreeBSD Kame stack, sys/netinet6/nd6_rtr.c forwarding is only (apart >from router solicitation considerations) considered in defrouter_select >and defrtrlist_del functions. in KAME stack, the only legal combination is: accept_rtadv=0, forwarding=1 router accept_rtadv=1, forwarding=0 autoconfigured host accept_rtadv=0, forwarding=0 manually configured host 1/1 combination is not prohibited, just for experimental purposes. we are not trying to promote configuration like 1/1. (netbsd /etc/rc.d/network prohibits 1/1). itojun From owner-netdev@oss.sgi.com Fri Apr 27 02:04:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3R942D11693 for netdev-outgoing; Fri, 27 Apr 2001 02:04:02 -0700 Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3R940M11688 for ; Fri, 27 Apr 2001 02:04:00 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f3R93mG26068; Fri, 27 Apr 2001 12:03:48 +0300 Date: Fri, 27 Apr 2001 12:03:48 +0300 (EEST) From: Pekka Savola To: cc: , , Peter Bieringer Subject: Re: (usagi-users 00439) IPv6: Autoconfiguring routers In-Reply-To: <10740.988361470@itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1407 Lines: 35 On Fri, 27 Apr 2001 itojun@iijlab.net wrote: > >If IP forwarding is enabled (e.g. router), _default route_ definitely > >should not be autoconfigured, but I see no reason why the announced prefix > >+ link-local suffix couldn't be combined to form one of the interface > >addresses (on routers, all interfaces additionally probably have manually > >assigned addresses too). > > RFC2462 talks about "host" autoconfiguration. autoconfiguration > of a router is outside of the scope of the document. so i don't > agree with you on "no reason why..." portion. > > btw, if all of your routers on the link is to be autoconfigured, > how can you autoconfigure them??? :-) Perhaps I was being imprecise or used 'autoconfiguration' the wrong way. What I meant, is a mechanism for routers to add address like: inet6 addr: 3ffe:2620:1:4:200:f8ff:fe08:3e0d/64 Scope:Global in the interface configuration if they/some other router on the link is advertising prefix 3ffe:2620:1:4::/64. (As it is, you manually configure e.g. 3ffe:2620:1:4::1/64, but this would be in addition to that). Or is this viewed as a redundant address (link local could be used instead where you know ll-adresses)? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Fri Apr 27 23:14:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3S6EPN15017 for netdev-outgoing; Fri, 27 Apr 2001 23:14:25 -0700 Received: from homer.ka9q.net (24-130-169-53.san.rr.com [24.130.169.53]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3S6EJM15013 for ; Fri, 27 Apr 2001 23:14:19 -0700 Received: (from karn@localhost) by homer.ka9q.net (8.11.1/8.11.1/ka9q 8.11.1) id f3S6EIU01049; Fri, 27 Apr 2001 23:14:18 -0700 Date: Fri, 27 Apr 2001 23:14:18 -0700 Message-Id: <200104280614.f3S6EIU01049@homer.ka9q.net> From: Phil Karn To: netfilter@lists.samba.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Problems with NAT/Masq and ipip on 2.4.[34] Reply-to: karn@ka9q.net Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 22711 Lines: 886 Until recently I had been tracking the 2.2.x kernel series. Since I installed 2.4.3 (and just now 2.4.4) I have been unable to make IP masquerading/NAT work. If I configure policy routing on and netfilter off, I can establish my existing policy tables that deal with my rather complex ipip tunnel & NAT configuration. Everything works as it did under 2.2.19 *except* that policy entries calling for masquerading no longer work. Here is the output of "ip rule list": 0: from all lookup local 10: from 199.106.106.0/28 lookup ka9q 11: from 129.46.253.96/28 lookup qualcomm 20: from 192.168.0.0/24 iif eth0 lookup main map-to 24.130.169.53 32766: from all lookup main 32767: from all lookup default And here are my routing tables and interfaces: bash-2.03$ ip route list 199.106.116.12/30 dev eth0 proto kernel scope link src 199.106.116.14 129.46.253.96/29 dev eth0 proto kernel scope link src 129.46.253.98 199.106.106.0/28 dev eth0 proto kernel scope link src 199.106.106.3 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.2 129.46.0.0/16 via 129.46.253.97 dev eth0 224.0.0.0/8 dev eth0 scope link src 199.106.106.3 default via 24.130.168.1 dev eth1 src 24.130.169.53 onlink bash-2.03$ ip route list table ka9q 199.106.106.0/28 dev eth0 scope link 10.0.0.0/24 dev eth0 scope link default via 192.35.156.12 dev tunl0 onlink bash-2.03$ ip route list table qualcomm default via 129.46.253.97 dev eth0 bash-2.03$ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:03:47:39:74:AE inet addr:199.106.106.3 Bcast:199.106.106.15 Mask:255.255.255.240 UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:352 errors:0 dropped:0 overruns:0 frame:0 TX packets:2846 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:11 Base address:0xe000 bash-2.03$ ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:A0:24:4A:BF:FD inet addr:24.130.169.53 Bcast:24.255.255.255 Mask:255.255.255.255 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4964 errors:0 dropped:0 overruns:0 frame:0 TX packets:5085 errors:0 dropped:0 overruns:0 carrier:0 collisions:16 txqueuelen:100 Interrupt:7 Base address:0xdf80 bash-2.03$ ifconfig tunl0 tunl0 Link encap:IPIP Tunnel HWaddr inet addr:24.130.169.53 Mask:255.255.255.255 UP RUNNING NOARP MTU:1480 Metric:1 RX packets:222 errors:0 dropped:0 overruns:0 frame:0 TX packets:214 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 The "map-to" policy entry worked fine under 2.2.19 but is apparently ignored under 2.4.3 and 2.4.4; packets from 192.168.0.0/24 go out un-NATed. The same happens if I make the map-to address null, in which case the "map-to" keyword is replaced with "masquerade". Is 2.4.x supposed to be backward compatible with the 2.2.x style policy routing and NAT mechanism? Or must I use the ipchains module under netfilter to reimplement this? I tried a kernel with netfilter turned on, but I was then no longer able to load the ipip.o module that I use for tunneling. I get two unresolved symbols from insmod: nf_hooks and nf_hooks_slow. Yet both symbols *are* mentioned in /System.map. Weird. This persisted even after a 'make clean' and remake. Appended is my /usr/src/linux/.config file with netfilter turned off. Following that is the output of /usr/src/linux/scripts/ver_linux. Thanks, Phil Karn # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # # CONFIG_EXPERIMENTAL is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_X86_UP_IOAPIC is not set # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PM=y CONFIG_APM=m # CONFIG_APM_IGNORE_USER_SUSPEND is not set CONFIG_APM_DO_ENABLE=y CONFIG_APM_CPU_IDLE=y # CONFIG_APM_DISPLAY_BLANK is not set CONFIG_APM_RTC_IS_GMT=y CONFIG_APM_ALLOW_INTS=y CONFIG_APM_REAL_MODE_POWER_OFF=y # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # # CONFIG_PNP is not set # CONFIG_ISAPNP is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=y # CONFIG_NETFILTER is not set CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_RTNETLINK=y CONFIG_NETLINK=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_NAT=y # CONFIG_IP_ROUTE_MULTIPATH is not set CONFIG_IP_ROUTE_TOS=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_ROUTE_LARGE_TABLES is not set # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y # CONFIG_IP_PIMSM_V2 is not set CONFIG_INET_ECN=y CONFIG_SYN_COOKIES=y # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set # CONFIG_BLK_DEV_IDEDISK_IBM is not set # CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set # CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set # CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set # CONFIG_BLK_DEV_IDEDISK_WD is not set # CONFIG_BLK_DEV_COMMERIAL is not set # CONFIG_BLK_DEV_TIVO is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=m CONFIG_BLK_DEV_IDETAPE=m CONFIG_BLK_DEV_IDEFLOPPY=m CONFIG_BLK_DEV_IDESCSI=m CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_IDEDMA_PCI is not set # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_IDEDMA_PCI_AUTO is not set # CONFIG_BLK_DEV_IDEDMA is not set # CONFIG_IDEDMA_PCI_WIP is not set # CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_AEC62XX_TUNING is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_WDC_ALI15X3 is not set # CONFIG_BLK_DEV_AMD7409 is not set # CONFIG_AMD7409_OVERRIDE is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_HPT34X_AUTODMA is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_PIIX_TUNING is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_PDC202XX is not set # CONFIG_PDC202XX_BURST is not set # CONFIG_BLK_DEV_OSB4 is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_IDE_CHIPSETS is not set # CONFIG_IDEDMA_AUTO is not set # CONFIG_DMA_NONPCI is not set CONFIG_BLK_DEV_IDE_MODES=y # # SCSI support # CONFIG_SCSI=m CONFIG_BLK_DEV_SD=m CONFIG_SD_EXTRA_DEVS=40 CONFIG_CHR_DEV_ST=m # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_SR_EXTRA_DEVS=2 CONFIG_CHR_DEV_SG=m CONFIG_SCSI_DEBUG_QUEUES=y # CONFIG_SCSI_MULTI_LUN is not set CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AHA1740 is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_AM53C974 is not set # CONFIG_SCSI_MEGARAID is not set CONFIG_SCSI_BUSLOGIC=m # CONFIG_SCSI_OMIT_FLASHPOINT is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_DMA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_NCR53C7xx is not set # CONFIG_SCSI_NCR53C8XX is not set # CONFIG_SCSI_SYM53C8XX is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_SEAGATE is not set # CONFIG_SCSI_SIM710 is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # # I2O device support # # CONFIG_I2O is not set # CONFIG_I2O_PCI is not set # CONFIG_I2O_BLOCK is not set # CONFIG_I2O_LAN is not set # CONFIG_I2O_SCSI is not set # CONFIG_I2O_PROC is not set # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_NET_VENDOR_3COM=y # CONFIG_EL1 is not set # CONFIG_EL2 is not set # CONFIG_ELPLUS is not set # CONFIG_EL16 is not set # CONFIG_EL3 is not set # CONFIG_3C515 is not set # CONFIG_ELMC is not set # CONFIG_ELMC_II is not set CONFIG_VORTEX=m # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_CS89x0 is not set # CONFIG_TULIP is not set # CONFIG_DE4X5 is not set # CONFIG_DGRS is not set # CONFIG_DM9102 is not set CONFIG_EEPRO100=m # CONFIG_EEPRO100_PM is not set # CONFIG_LNE390 is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_NE3210 is not set # CONFIG_ES3210 is not set # CONFIG_8139TOO is not set # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_WINBOND_840 is not set # CONFIG_HAPPYMEAL is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_HAMACHI is not set # CONFIG_SK98LIN is not set # CONFIG_FDDI is not set # CONFIG_PLIP is not set CONFIG_PPP=m # CONFIG_PPP_MULTILINK is not set # CONFIG_PPP_FILTER is not set CONFIG_PPP_ASYNC=m # CONFIG_PPP_SYNC_TTY is not set CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_SLIP=m CONFIG_SLIP_COMPRESSED=y # CONFIG_SLIP_SMART is not set # CONFIG_SLIP_MODE_SLIP6 is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Input core support # # CONFIG_INPUT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=m CONFIG_SERIAL_EXTENDED=y CONFIG_SERIAL_MANY_PORTS=y CONFIG_SERIAL_SHARE_IRQ=y # CONFIG_SERIAL_DETECT_IRQ is not set # CONFIG_SERIAL_MULTIPORT is not set # CONFIG_HUB6 is not set CONFIG_SERIAL_NONSTANDARD=y # CONFIG_COMPUTONE is not set # CONFIG_ROCKETPORT is not set # CONFIG_CYCLADES is not set # CONFIG_DIGIEPCA is not set # CONFIG_DIGI is not set # CONFIG_ESPSERIAL is not set # CONFIG_MOXA_INTELLIO is not set # CONFIG_MOXA_SMARTIO is not set # CONFIG_SYNCLINK is not set # CONFIG_N_HDLC is not set # CONFIG_RISCOM8 is not set # CONFIG_SPECIALIX is not set # CONFIG_SX is not set # CONFIG_RIO is not set # CONFIG_STALDRV is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set # CONFIG_PPDEV is not set # # I2C support # # CONFIG_I2C is not set # # Mice # # CONFIG_BUSMOUSE is not set CONFIG_MOUSE=y CONFIG_PSMOUSE=y # CONFIG_82C710_MOUSE is not set # CONFIG_PC110_PAD is not set # # Joysticks # # CONFIG_JOYSTICK is not set # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set CONFIG_INTEL_RNG=m CONFIG_NVRAM=m CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=m CONFIG_AGP_INTEL=y CONFIG_AGP_I810=y CONFIG_AGP_VIA=y CONFIG_AGP_AMD=y CONFIG_AGP_SIS=y CONFIG_AGP_ALI=y CONFIG_DRM=y CONFIG_DRM_TDFX=m # CONFIG_DRM_GAMMA is not set # CONFIG_DRM_R128 is not set # CONFIG_DRM_RADEON is not set CONFIG_DRM_I810=m # CONFIG_DRM_MGA is not set # # Multimedia devices # CONFIG_VIDEO_DEV=m # # Video For Linux # # CONFIG_VIDEO_PROC_FS is not set # CONFIG_I2C_PARPORT is not set # CONFIG_VIDEO_PMS is not set # CONFIG_VIDEO_BWQCAM is not set # CONFIG_VIDEO_CPIA is not set # CONFIG_VIDEO_SAA5249 is not set # CONFIG_TUNER_3036 is not set # CONFIG_VIDEO_ZORAN is not set # CONFIG_VIDEO_BUZ is not set # CONFIG_VIDEO_ZR36120 is not set # # Radio Adapters # # CONFIG_RADIO_CADET is not set # CONFIG_RADIO_RTRACK is not set # CONFIG_RADIO_RTRACK2 is not set # CONFIG_RADIO_AZTECH is not set # CONFIG_RADIO_GEMTEK is not set # CONFIG_RADIO_MAXIRADIO is not set # CONFIG_RADIO_MAESTRO is not set # CONFIG_RADIO_MIROPCM20 is not set # CONFIG_RADIO_SF16FMI is not set # CONFIG_RADIO_TERRATEC is not set # CONFIG_RADIO_TRUST is not set # CONFIG_RADIO_TYPHOON is not set # CONFIG_RADIO_ZOLTRIX is not set # # File systems # # CONFIG_QUOTA is not set CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=y # CONFIG_REISERFS_FS is not set # CONFIG_REISERFS_CHECK is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m # CONFIG_UMSDOS_FS is not set CONFIG_VFAT_FS=m # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_CRAMFS is not set CONFIG_TMPFS=y # CONFIG_RAMFS is not set CONFIG_ISO9660_FS=m CONFIG_JOLIET=y # CONFIG_MINIX_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_SYSV_FS_WRITE is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set # # Network File Systems # # CONFIG_CODA_FS is not set CONFIG_NFS_FS=m # CONFIG_NFS_V3 is not set # CONFIG_ROOT_NFS is not set # CONFIG_NFSD is not set # CONFIG_NFSD_V3 is not set CONFIG_SUNRPC=m CONFIG_LOCKD=m # CONFIG_SMB_FS is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y # CONFIG_BSD_DISKLABEL is not set # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_SMB_NLS is not set CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="cp437" CONFIG_NLS_CODEPAGE_437=m # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ISO8859_1=m # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Console drivers # CONFIG_VGA_CONSOLE=y # CONFIG_VIDEO_SELECT is not set # # Sound # CONFIG_SOUND=m # CONFIG_SOUND_CMPCI is not set # CONFIG_SOUND_EMU10K1 is not set # CONFIG_SOUND_FUSION is not set # CONFIG_SOUND_CS4281 is not set CONFIG_SOUND_ES1370=m CONFIG_SOUND_ES1371=m # CONFIG_SOUND_ESSSOLO1 is not set # CONFIG_SOUND_MAESTRO is not set # CONFIG_SOUND_MAESTRO3 is not set CONFIG_SOUND_ICH=m # CONFIG_SOUND_SONICVIBES is not set # CONFIG_SOUND_TRIDENT is not set # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set # CONFIG_SOUND_VIA82CXXX is not set CONFIG_SOUND_OSS=m # CONFIG_SOUND_TRACEINIT is not set # CONFIG_SOUND_DMAP is not set # CONFIG_SOUND_SGALAXY is not set # CONFIG_SOUND_ADLIB is not set # CONFIG_SOUND_ACI_MIXER is not set # CONFIG_SOUND_CS4232 is not set # CONFIG_SOUND_SSCAPE is not set # CONFIG_SOUND_GUS is not set # CONFIG_SOUND_VMIDI is not set # CONFIG_SOUND_TRIX is not set # CONFIG_SOUND_MSS is not set # CONFIG_SOUND_MPU401 is not set # CONFIG_SOUND_NM256 is not set # CONFIG_SOUND_MAD16 is not set # CONFIG_SOUND_PAS is not set # CONFIG_PAS_JOYSTICK is not set # CONFIG_SOUND_PSS is not set CONFIG_SOUND_SB=m # CONFIG_SOUND_AWE32_SYNTH is not set # CONFIG_SOUND_WAVEFRONT is not set # CONFIG_SOUND_MAUI is not set # CONFIG_SOUND_YM3812 is not set # CONFIG_SOUND_OPL3SA1 is not set # CONFIG_SOUND_OPL3SA2 is not set # CONFIG_SOUND_YMFPCI is not set # CONFIG_SOUND_YMFPCI_LEGACY is not set # CONFIG_SOUND_UART6850 is not set # CONFIG_SOUND_AEDSP16 is not set # CONFIG_SOUND_TVMIXER is not set # # USB support # # CONFIG_USB is not set # # Kernel hacking # # CONFIG_MAGIC_SYSRQ is not set output of /usr/src/linux/scripts/ver_linux: Linux homer.ka9q.net 2.4.4 #6 Fri Apr 27 22:44:19 PDT 2001 i686 unknown Gnu C 2.95.2 Gnu make 3.79.1 binutils 2.9.5.0.37 util-linux util-linux Note: /usr/bin/fdformat is obsolete and is no longer available. util-linux Please use /usr/bin/superformat instead (make sure you have the util-linux fdutils package installed first). Also, there had been some util-linux major changes from version 4.x. Please refer to the documentation. util-linux mount 2.10p modutils 2.4.5 e2fsprogs 1.18 Linux C Library 2.1.3 ldd: version 1.9.11 Procps 2.0.6 Net-tools 1.54 Kbd 0.99 Sh-utils 2.0 Modules Loaded serial i810_audio soundcore ac97_codec agpgart ipip 3c59x eepro100 From owner-netdev@oss.sgi.com Sat Apr 28 07:20:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3SEKgh26852 for netdev-outgoing; Sat, 28 Apr 2001 07:20:42 -0700 Received: from zero.aec.at (qmailr@zero.aec.at [195.3.98.22]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f3SEKeM26848 for ; Sat, 28 Apr 2001 07:20:41 -0700 Received: (qmail 9236 invoked by uid 99); 28 Apr 2001 14:20:22 -0000 Received: from unknown (HELO fred.muc.de) (unknown) by unknown with SMTP; 28 Apr 2001 14:20:22 -0000 Received: by fred.muc.de (Postfix, from userid 500) id 1E55EE3CCD; Sat, 28 Apr 2001 16:29:27 +0200 (CEST) Date: Sat, 28 Apr 2001 16:29:27 +0200 From: Andi Kleen To: Andi Kleen Cc: Phil Karn , netfilter@lists.samba.org, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Problems with NAT/Masq and ipip on 2.4.[34] Message-ID: <20010428162927.A6417@fred.local> References: <200104280614.f3S6EIU01049@homer.ka9q.net> <20010428155739.A4593@fred.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010428155739.A4593@fred.local>; from ak@muc.de on Sat, Apr 28, 2001 at 03:57:39PM +0200 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1245 Lines: 29 On Sat, Apr 28, 2001 at 08:14:18AM +0200, Phil Karn wrote: > If I configure policy routing on and netfilter off, I can establish my > existing policy tables that deal with my rather complex ipip tunnel & > NAT configuration. Everything works as it did under 2.2.19 *except* > that policy entries calling for masquerading no longer work. Such a policy rule is not really masquerading, just a very simple stateless NAT. It'll probably not do what you want because it has no protocol translation support for ftp etc. Masquerading has always been a different subsystem, controlled by the firewall. In 2.4 masquerading still exists as a compatibility module, but requires netfilter connection tracking. In 2.4 there also is a more generic new NAT subsystem that among other things supports old masquerading. > I tried a kernel with netfilter turned on, but I was then no longer > able to load the ipip.o module that I use for tunneling. I get two > unresolved symbols from insmod: nf_hooks and nf_hooks_slow. Yet both > symbols *are* mentioned in /System.map. Weird. This persisted even > after a 'make clean' and remake. Looks like you didn't turn on CONFIG_NETFILTER in the main kernel. Without it masquerading will not work though. -Andi From owner-netdev@oss.sgi.com Sat Apr 28 13:37:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3SKb1W04809 for netdev-outgoing; Sat, 28 Apr 2001 13:37:01 -0700 Received: from balu.sch.bme.hu (balu.sch.bme.hu [152.66.208.40]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3SKaxM04802 for ; Sat, 28 Apr 2001 13:37:00 -0700 Received: from localhost (bartoki@localhost) by balu.sch.bme.hu (8.9.3+Sun/8.9.2) with ESMTP id WAA01792 for ; Sat, 28 Apr 2001 22:36:48 +0200 (MEST) Date: Sat, 28 Apr 2001 22:36:48 +0200 (MEST) From: Bartok Istvan X-Sender: To: Subject: ECN timeout support in Linux TCP? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1913 Lines: 48 Hi, The short question: Does the Linux TCP implementation support the ECN timeout suggested in rfc2481? Some longer: While experimenting with an ECN-marking queue (BLUE) on Linux I found packet marking probability to reach 1.0 very early, eg. with 100 TCP connections on a 10 Mbit Ethernet with a 50 kB buffer. This seems to me the kind of problem which is mentioned in the BLUE paper (http://www.thefengs.com/wuchang/work/CSE-TR-387-99.pdf, Chapter 3.4, Page 11: "The effects of ECN timeouts"). The above paper states that FreeBSD 2.2.7 + ALTQ 1.1.2 does not implement the timeout. I have tried to seek in the Linux 2.4.3 source to see whether Linux implements it, but have not find traces of that (but I can be wrong, of course). ftp://ftp.ee.lbl.gov/ECN/README.ECN doesn't declare nor supporting, nor ignoring the subject, but anyway it is quite old (isn't it outdated?). To see what timeout I am talking about: rfc2481: ... However, the value of the congestion window is bounded below by a value of one MSS. If the sending TCP were to continue to send, using a congestion window of 1 MSS, this results in the transmission of one packet per round-trip time. We believe it is desirable to still reduce the sending rate of the TCP sender even further, on receipt of an ECN-Echo packet when the congestion window is one. We use the retransmit timer as a means to reduce the rate further in this circumstance. Therefore, the sending TCP should also reset the retransmit timer on receiving the ECN-Echo packet when the congestion window is one. The sending TCP will then be able to send a new packet when the retransmit timer expires. ... Without this mechanism, one should need an (MSS * num_of_connections) size txbuffer on a bottleneck link to totally avoid packet losses even when marking every packet with ECN CE. :( Regards, -- Bartok Istvan From owner-netdev@oss.sgi.com Sun Apr 29 10:00:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3TH0DF06663 for netdev-outgoing; Sun, 29 Apr 2001 10:00:13 -0700 Received: from moon.mt.lv (root@moon.mt.lv [159.148.147.194]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3TH0BM06659 for ; Sun, 29 Apr 2001 10:00:11 -0700 Received: from localhost.localdomain (IDENT:root@karlis.dev.mt.lv [10.0.0.16]) by moon.mt.lv (8.9.3/8.9.3) with ESMTP id TAA26032 for ; Sun, 29 Apr 2001 19:00:09 +0200 Date: Sun, 29 Apr 2001 19:57:33 +0200 (GMT-2) From: Karlis Peisenieks To: netdev@oss.sgi.com Subject: [patch] preferred source for routes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1208 Lines: 46 Below find patch that fixes problem with preferred source address for route (when deleting last address on iface that was used as preferred source address for other route to different interface did not cause that route to dissapear). Please comment on this, Karlis --- fib_frontend.c.orig Sun Apr 29 19:38:09 2001 +++ fib_frontend.c Sun Apr 29 19:41:40 2001 @@ -528,9 +528,9 @@ #undef BRD1_OK } -static void fib_disable_ip(struct device *dev, int force) +static void fib_disable_ip(struct device *dev, u32 addr, int force) { - if (fib_sync_down(0, dev, force)) + if (fib_sync_down(addr, dev, force)) fib_flush(); rt_cache_flush(0); arp_ifdown(dev); @@ -550,7 +550,7 @@ /* Last address was deleted from this interface. Disable IP. */ - fib_disable_ip(ifa->ifa_dev->dev, 1); + fib_disable_ip(ifa->ifa_dev->dev, ifa->ifa_local, 1); } else { fib_del_ifaddr(ifa); rt_cache_flush(-1); @@ -579,10 +579,10 @@ rt_cache_flush(-1); break; case NETDEV_DOWN: - fib_disable_ip(dev, 0); + fib_disable_ip(dev, 0, 0); break; case NETDEV_UNREGISTER: - fib_disable_ip(dev, 1); + fib_disable_ip(dev, 0, 1); break; case NETDEV_CHANGEMTU: case NETDEV_CHANGE: From owner-netdev@oss.sgi.com Sun Apr 29 10:10:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3THALw07265 for netdev-outgoing; Sun, 29 Apr 2001 10:10:21 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f3THAHM07262 for ; Sun, 29 Apr 2001 10:10:17 -0700 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA03686; Sun, 29 Apr 2001 21:09:38 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200104291709.VAA03686@ms2.inr.ac.ru> Subject: Re: ECN timeout support in Linux TCP? To: bartoki@sch.bme.HU (Bartok Istvan) Date: Sun, 29 Apr 2001 21:09:38 +0400 (MSK DST) Cc: netdev@oss.sgi.com In-Reply-To: from "Bartok Istvan" at Apr 29, 1 00:45:00 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 796 Lines: 23 Hello! > The short question: Does the Linux TCP implementation support the ECN > timeout suggested in rfc2481? No. > Without this mechanism, one should need an (MSS * num_of_connections) > size txbuffer on a bottleneck link to totally avoid packet losses even > when marking every packet with ECN CE. :( Grr... goal of ECN is not "avoiding of losses", its goal is preservation of ACK clock in presence of congestion. Artificial timeout has nil impact comparing to normal timeout. Note also one more thing (which makes threshold twice worse and, probably, should be changed unlike above): we do not allow to drop cwnd under 2 segments without real losses. The reason is the same: dropping cwnd under 2 segments also breaks ACK clock due to delacks and therefore it is unacceptable. Alexey From owner-netdev@oss.sgi.com Sun Apr 29 14:55:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3TLtmK17358 for netdev-outgoing; Sun, 29 Apr 2001 14:55:48 -0700 Received: from shell.cyberus.ca (shell.cyberus.ca [209.195.95.7]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3TLthM17351 for ; Sun, 29 Apr 2001 14:55:44 -0700 Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.3/666/Cyberus Online Inc.) with ESMTP id RAA28457; Sun, 29 Apr 2001 17:54:12 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sun, 29 Apr 2001 17:54:12 -0400 (EDT) From: jamal To: cc: Bartok Istvan , Subject: Re: ECN timeout support in Linux TCP? In-Reply-To: <200104291709.VAA03686@ms2.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Sun, 29 Apr 2001 kuznet@ms2.inr.ac.ru wrote: > Hello! > > > The short question: Does the Linux TCP implementation support the ECN > > timeout suggested in rfc2481? > > No. > > > > Without this mechanism, one should need an (MSS * num_of_connections) > > size txbuffer on a bottleneck link to totally avoid packet losses even > > when marking every packet with ECN CE. :( > > Grr... goal of ECN is not "avoiding of losses", its goal is preservation > of ACK clock in presence of congestion. Artificial timeout has nil impact > comparing to normal timeout. > The MSS * num_of_connections arguement is equivalent to the "if you need every flow through the bottleneck link to use their fair share of the bandwidth then you preallocate BW * RTT * num_of_connections buffers" Reality is: loss avoidance is gravy for ECN and that at the level of one packet cwnds, with so many competing flows, it's a lost cause already. > > Note also one more thing (which makes threshold twice worse and, probably, > should be changed unlike above): we do not allow to drop cwnd under 2 segments > without real losses. The reason is the same: dropping cwnd under 2 segments > also breaks ACK clock due to delacks and therefore it is unacceptable. Aye, aye. I dont think you passed this feedback to the RFC which is going proposed standard next week ;-> But we dont wanna delay the publication, one could argue it is a implementation detail which Linux ignores. cheers, jamal From owner-netdev@oss.sgi.com Sun Apr 29 17:20:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3U0KKO20902 for netdev-outgoing; Sun, 29 Apr 2001 17:20:20 -0700 Received: from coruscant.gnumonks.org (coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3U0KJM20899 for ; Sun, 29 Apr 2001 17:20:20 -0700 Received: from uucp by coruscant.gnumonks.org with local-bsmtp (Exim 3.22 #1) id 14u1QJ-0002lC-00 for netdev@oss.sgi.com; Mon, 30 Apr 2001 02:20:19 +0200 Received: from corellia.laforge.distro.conectiva ([192.168.1.11] helo=br.gnumonks.org) by hoth.distro.conectiva with esmtp (Exim 3.22 #1) id 14u1KR-0007np-00; Sun, 29 Apr 2001 21:14:15 -0300 Received: from laforge by br.gnumonks.org with local (Exim 3.22 #1) id 14u1KR-0002vE-00; Sun, 29 Apr 2001 21:14:15 -0300 Date: Sun, 29 Apr 2001 21:14:15 -0300 From: Harald Welte To: jamal Cc: , , Andi Kleen , Subject: Re: mroute.h patch Message-ID: <20010429211415.U1511@corellia.laforge.distro.conectiva> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.14i In-Reply-To: ; from hadi@cyberus.ca on Mon, Apr 23, 2001 at 10:27:44PM -0400 X-Operating-System: Linux corellia.laforge.distro.conectiva 2.4.3 X-Date: Today is Pungenday, the 45th day of Discord in the YOLD 3167 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Mon, Apr 23, 2001 at 10:27:44PM -0400, jamal wrote: > ftp://parcftp.xerox.com/pub/net-research/ipmulti/beta-test/mrouted-3.9-beta3.tar.gz > ftp://ftp.debian.org/debian/dists/potato/non-free/source/net/mrouted_3.9-beta3-1.diff.gz > > Although i tried the debian patch it didnt help me. Could someone else > try this out? > > I use Conectiva (6.0) these days .... Well... I've tested mrouted including the above patch on the following distros: conectiva 6.0 conectiva 6.5 (devel snapshot) redhat 7.0 and it compiles on all three systems without the mentioned include problems. > cheers, > jamal -- Live long and prosper - Harald Welte / laforge@gnumonks.org http://www.gnumonks.org ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ 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+(*) From owner-netdev@oss.sgi.com Sun Apr 29 17:25:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3U0Pd521404 for netdev-outgoing; Sun, 29 Apr 2001 17:25:39 -0700 Received: from shell.cyberus.ca (shell.cyberus.ca [209.195.95.7]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3U0PcM21401 for ; Sun, 29 Apr 2001 17:25:38 -0700 Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.3/666/Cyberus Online Inc.) with ESMTP id UAA28650; Sun, 29 Apr 2001 20:24:08 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sun, 29 Apr 2001 20:24:08 -0400 (EDT) From: jamal To: Harald Welte cc: , , Andi Kleen , Subject: Re: mroute.h patch In-Reply-To: <20010429211415.U1511@corellia.laforge.distro.conectiva> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk It must be related to my environment then or iam on bad crack. I wonder what it is; i have similar problems with a ppc cross compile environment on the same problem as well. Dave, just ignore the patch. cheers, jamal On Sun, 29 Apr 2001, Harald Welte wrote: > On Mon, Apr 23, 2001 at 10:27:44PM -0400, jamal wrote: > > ftp://parcftp.xerox.com/pub/net-research/ipmulti/beta-test/mrouted-3.9-beta3.tar.gz > > ftp://ftp.debian.org/debian/dists/potato/non-free/source/net/mrouted_3.9-beta3-1.diff.gz > > > > Although i tried the debian patch it didnt help me. Could someone else > > try this out? > > > > I use Conectiva (6.0) these days .... > > Well... I've tested mrouted including the above patch on the following > distros: > > conectiva 6.0 > conectiva 6.5 (devel snapshot) > redhat 7.0 > > and it compiles on all three systems without the mentioned include problems. > > > cheers, > > jamal > > -- > Live long and prosper > - Harald Welte / laforge@gnumonks.org http://www.gnumonks.org > ============================================================================ > GCS/E/IT d- s-: a-- C+++ UL++++$ 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+(*) > From owner-netdev@oss.sgi.com Mon Apr 30 08:45:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3UFjbR13483 for netdev-outgoing; Mon, 30 Apr 2001 08:45:37 -0700 Received: from cerberus.hogo.wide.ad.jp (root@cerberus.hongo.wide.ad.jp [203.178.140.182]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3UFjKM13480 for ; Mon, 30 Apr 2001 08:45:20 -0700 Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.hogo.wide.ad.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id AAA15473; Tue, 1 May 2001 00:45:08 +0900 To: netdev@oss.sgi.com CC: usagi-users@linux-ipv6.org Subject: [Patch] DAD interval X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010501004507J.yoshfuji@wide.ad.jp> Date: Tue, 01 May 2001 00:45:07 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 990905(IM130) Lines: 63 Sender: owner-netdev@oss.sgi.com Precedence: bulk Sorry for the delay... We, USAGI Project, will provide you 3 or 4 patches (at least)... This fixes interval between DAD packets. USAGI Branch: bFIX_2_4_3-20010501 References: [1] RFC2042 5.4.2. Sending Neighbor Solicitation Messages : To check an address, a node sends DupAddrDetectTransmits Neighbor Solicitations, each separated by RetransTimer milliseconds. The solicitation's Target Address is set to the address being checked, : [2] RFC2041 6.3.2. Host Variables : RetransTimer The time between retransmissions of Neighbor Solicitation messages to a neighbor when resolving the address or when probing the reachability of a neighbor. Default: RETRANS_TIMER milliseconds : 10. PROTOCOL CONSTANTS : RETRANS_TIMER 1,000 milliseconds : Index: net/ipv6/addrconf.c =================================================================== RCS file: /cvsroot/usagi/kernel/linux24/net/ipv6/addrconf.c,v retrieving revision 1.1.1.4 retrieving revision 1.1.1.4.2.1 diff -u -r1.1.1.4 -r1.1.1.4.2.1 --- net/ipv6/addrconf.c 2001/02/22 12:04:36 1.1.1.4 +++ net/ipv6/addrconf.c 2001/04/30 15:21:42 1.1.1.4.2.1 @@ -22,6 +22,8 @@ * Andi Kleen : kill doube kfree on module * unload. * Maciej W. Rozycki : FDDI support + * yoshfuji@USAGI : Fixed interval between DAD + * packets. */ #include @@ -1505,7 +1507,7 @@ } ifp->probes--; - addrconf_mod_timer(ifp, AC_DAD, ifp->idev->cnf.rtr_solicit_interval); + addrconf_mod_timer(ifp, AC_DAD, ifp->idev->nd_parms->retrans_time); spin_unlock_bh(&ifp->lock); /* send a neighbour solicitation for our addr */ -- Hideaki YOSHIFUJI @ USAGI Project PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 From owner-netdev@oss.sgi.com Mon Apr 30 09:04:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3UG40M14349 for netdev-outgoing; Mon, 30 Apr 2001 09:04:00 -0700 Received: from yue.hongo.wide.ad.jp (postfix@yue.hongo.wide.ad.jp [203.178.140.186]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3UG3xM14346 for ; Mon, 30 Apr 2001 09:03:59 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id E9892A1; Tue, 1 May 2001 01:03:38 +0900 (JST) To: netdev@oss.sgi.com Cc: usagi-users@linux-ipv6.org Subject: Re: [Patch] DAD interval In-Reply-To: <20010501004507J.yoshfuji@wide.ad.jp> References: <20010501004507J.yoshfuji@wide.ad.jp> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-URL: http://www.hongo.wide.ad.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Message-Id: <20010501010338W.yoshfuji@wide.ad.jp> Date: Tue, 01 May 2001 01:03:38 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 20000414(IM141) Lines: 14 Sender: owner-netdev@oss.sgi.com Precedence: bulk In article <20010501004507J.yoshfuji@wide.ad.jp> (at Tue, 01 May 2001 00:45:07 +0900), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: Oops! > References: > [1] RFC2042 ~~~~2462 > [2] RFC2041 ~~~~2461 -- Hideaki YOSHIFUJI @ USAGI Project PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 From owner-netdev@oss.sgi.com Mon Apr 30 09:41:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3UGf7315703 for netdev-outgoing; Mon, 30 Apr 2001 09:41:07 -0700 Received: from yue.hongo.wide.ad.jp (postfix@yue.hongo.wide.ad.jp [203.178.140.186]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3UGf6M15700 for ; Mon, 30 Apr 2001 09:41:06 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 15196A1; Tue, 1 May 2001 01:40:46 +0900 (JST) To: netdev@oss.sgi.com Cc: usagi-users@linux-ipv6.org Subject: [Patch] RS Count X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-URL: http://www.hongo.wide.ad.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010501014046F.yoshfuji@wide.ad.jp> Date: Tue, 01 May 2001 01:40:46 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 20000414(IM141) Lines: 49 Sender: owner-netdev@oss.sgi.com Precedence: bulk linux-2.4.x send too many (more than 3) RS packets. This fixes the problem. USAGI Branch: bFIX_2_4_3-20010501a Reference: RFC2461 6.3.7. Sending Router Solicitations : routers or learn prefixes. To obtain Router Advertisements quickly, a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router Solicitation messages each separated by at least RTR_SOLICITATION_INTERVAL seconds. Router Solicitations may be sent after any of the following events: : 10. PROTOCOL CONSTANTS : MAX_RTR_SOLICITATIONS 3 transmissions Index: net/ipv6/addrconf.c =================================================================== RCS file: /cvsroot/usagi/kernel/linux24/net/ipv6/addrconf.c,v retrieving revision 1.1.1.4 retrieving revision 1.1.1.4.4.1 diff -u -r1.1.1.4 -r1.1.1.4.4.1 --- net/ipv6/addrconf.c 2001/02/22 12:04:36 1.1.1.4 +++ net/ipv6/addrconf.c 2001/04/30 16:12:59 1.1.1.4.4.1 @@ -22,6 +22,8 @@ * Andi Kleen : kill doube kfree on module * unload. * Maciej W. Rozycki : FDDI support + * sekiya@USAGI : Don't send too many RS + * packets. */ #include @@ -1415,7 +1417,7 @@ } spin_lock(&ifp->lock); - if (ifp->probes++ <= ifp->idev->cnf.rtr_solicits) { + if (ifp->probes++ < ifp->idev->cnf.rtr_solicits) { struct in6_addr all_routers; addrconf_mod_timer(ifp, AC_RS, -- yoshfuji@USAGI Project From owner-netdev@oss.sgi.com Mon Apr 30 10:51:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3UHplH18216 for netdev-outgoing; Mon, 30 Apr 2001 10:51:47 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f3UHphM18213 for ; Mon, 30 Apr 2001 10:51:44 -0700 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA18809; Mon, 30 Apr 2001 21:51:04 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200104301751.VAA18809@ms2.inr.ac.ru> Subject: Re: ECN timeout support in Linux TCP? To: hadi@cyberus.ca (jamal) Date: Mon, 30 Apr 2001 21:51:04 +0400 (MSK DST) Cc: bartoki@sch.bme.HU, netdev@oss.sgi.com In-Reply-To: from "jamal" at Apr 29, 1 05:54:12 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hello! > > Note also one more thing (which makes threshold twice worse and, probably, > > should be changed unlike above): ... > I dont think you passed this feedback to the RFC which is going > proposed standard next week ;-> But we dont wanna delay the publication, > one could argue it is a implementation detail which Linux ignores. I said: this should be changed. The issue is minor, no need to bother Sally about this. 8) Though... probably, it is an interesting issue for investigation: when sending ECE receiver could disable delaying ACKs. It is even good to accelerate delivery of congestion notification. Alexey From owner-netdev@oss.sgi.com Mon Apr 30 11:48:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3UImcH20568 for netdev-outgoing; Mon, 30 Apr 2001 11:48:38 -0700 Received: from balu.sch.bme.hu (balu.sch.bme.hu [152.66.208.40]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3UImbM20565 for ; Mon, 30 Apr 2001 11:48:37 -0700 Received: from localhost (bartoki@localhost) by balu.sch.bme.hu (8.9.3+Sun/8.9.2) with ESMTP id UAA09516; Mon, 30 Apr 2001 20:47:46 +0200 (MEST) Date: Mon, 30 Apr 2001 20:47:46 +0200 (MEST) From: Bartok Istvan X-Sender: To: jamal cc: Alexey Kuznetsov , Subject: Re: ECN timeout support in Linux TCP? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Sun, 29 Apr 2001, jamal wrote: > > without real losses. The reason is the same: dropping cwnd under 2 segments > > also breaks ACK clock due to delacks and therefore it is unacceptable. > > Aye, aye. > I dont think you passed this feedback to the RFC which is going > proposed standard next week ;-> But we dont wanna delay the publication, > one could argue it is a implementation detail which Linux ignores. Maybe it would be nice to standardize the Linux behavior, as draft-ietf-tsvwg-ecn-03.txt (which is going to be discussed this week) requires the retransmit timer stuff (it has a MUST). I don't have problems with any of the solutions (RFC vs. Linux), but if not standardized then the Linux TCP is going to be more agressive then RFC says, and it would'n be nice if people started bashing Linux for that.. The even higher bias towards ECN-flows remains my problem in this case. :) -- Bartok Istvan From owner-netdev@oss.sgi.com Mon Apr 30 12:23:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3UJNDo21919 for netdev-outgoing; Mon, 30 Apr 2001 12:23:13 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3UJNDM21916 for ; Mon, 30 Apr 2001 12:23:13 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA03648; Mon, 30 Apr 2001 12:23:00 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15085.48020.820978.113106@pizda.ninka.net> Date: Mon, 30 Apr 2001 12:23:00 -0700 (PDT) To: YOSHIFUJI.Hideaki/$B5HF#1QL@.sgi.com (B ) Cc: netdev@oss.sgi.com, usagi-users@linux-ipv6.org Subject: Re: [Patch] RS Count In-Reply-To: <20010501014046F.yoshfuji@wide.ad.jp> References: <20010501014046F.yoshfuji@wide.ad.jp> X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk B writes: > linux-2.4.x send too many (more than 3) RS packets. > This fixes the problem. Already fixed in 2.4.4 Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Mon Apr 30 12:30:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3UJUdw22481 for netdev-outgoing; Mon, 30 Apr 2001 12:30:39 -0700 Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3UJUcM22478 for ; Mon, 30 Apr 2001 12:30:38 -0700 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA05234; Mon, 30 Apr 2001 12:30:33 -0700 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15085.48473.430408.397111@pizda.ninka.net> Date: Mon, 30 Apr 2001 12:30:33 -0700 (PDT) To: yoshfuji@wide.ad.jp Cc: netdev@oss.sgi.com, usagi-users@linux-ipv6.org Subject: Re: [Patch] DAD interval In-Reply-To: <20010501004507J.yoshfuji@wide.ad.jp> References: <20010501004507J.yoshfuji@wide.ad.jp> X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk B writes: > This fixes interval between DAD packets. I've applied your patch, thanks. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Mon Apr 30 13:09:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3UK9VC23985 for netdev-outgoing; Mon, 30 Apr 2001 13:09:31 -0700 Received: from fsg1.nws.noaa.gov (FSG1.nws.noaa.gov [140.90.20.103]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3UK9MM23971 for ; Mon, 30 Apr 2001 13:09:23 -0700 Received: from localhost (brianm@localhost) by fsg1.nws.noaa.gov (8.9.3/8.8.7) with ESMTP id QAA16515; Mon, 30 Apr 2001 16:08:36 -0400 Date: Mon, 30 Apr 2001 16:08:36 -0400 (EDT) From: Brian McEntire To: cc: , , , , Subject: Abyss.o Token Ring Driver broken after 2.4.1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi there!! Without taking up too many lines, I just want to say thank you all for your great work with Linux! Please forward this message on to the appropriate person/maintainer if I haven't caught the right person already. I've noticed a couple of list postings that talk about the following problem: Madge Smart 16/4 PCI Ringnode Mk2 token ring cards seem to be broken after kernel 2.4.1. I noticed this because I couldn't get the card to load as a module (would complain about IRQs) in 2.4.3. I did a google.com search on "abyss.o Madge" and searched groups.google.com (Usenet archive.) I found several messages discussing this problem and at least one that said the problem presented itself in all kernels > 2.4.1. So I tried to build 2.4.1 with Madge support (via the abyss.o driver, and maybe tms380.o) and sure enough, all worked well! I am running fine now on the 2.4.1 kernel, but I would really like to see this abyss.o driver worked back into the tree so that it works in 2.4.4 and beyond! I'd like to be able to upgrade as security and other fixes are released, but I can't until the card is supported again. Thanks again, Brian From owner-netdev@oss.sgi.com Mon Apr 30 14:34:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3ULYTU27202 for netdev-outgoing; Mon, 30 Apr 2001 14:34:29 -0700 Received: from arnhem.blackstar.nl (IDENT:root@d122251.upc-d.chello.nl [213.46.122.251]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3ULY7M27179 for ; Mon, 30 Apr 2001 14:34:08 -0700 Received: from laptop.blackstar.nl (IDENT:root@laptop.blackstar.nl [192.168.3.2]) by arnhem.blackstar.nl (8.9.3/8.9.3) with ESMTP id XAA09982 for ; Mon, 30 Apr 2001 23:34:13 +0200 Received: from localhost (bvermeul@localhost) by laptop.blackstar.nl (8.9.3/8.9.3) with ESMTP id XAA02155 for ; Mon, 30 Apr 2001 23:34:03 +0200 X-Authentication-Warning: laptop.blackstar.nl: bvermeul owned process doing -bs Date: Mon, 30 Apr 2001 23:34:03 +0200 (CEST) From: Bas Vermeulen To: Subject: Problems writing pcmcia wireless ethernet driver. Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463811581-2040609447-988666443=:2111" Sender: owner-netdev@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463811581-2040609447-988666443=:2111 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I'm writing a driver for a couple of PCMCIA Wireless ethernet drivers. These cards have some quirks, one of them being that they are configured with ethernet packages sent to the card. In order to do that, I use dev_queue_xmit to insert packages into the cards queue. This all works wonderfully well, except when I either bring the card down and up, or when I use cardctl to change the scheme. When I do that, I only have to wait a minute to have my box hang. I've made a stack trace with SysRQ-P, and that points to qdisc_restart: Apr 25 19:26:21 laptop kernel: EIP: 0010:[] CPU: 0 EFLAGS: 00000216 Using defaults from ksymoops -t elf32-i386 Apr 25 19:26:21 laptop kernel: EAX: 00000020 EBX: 00000107 ECX: 00007fa0 EDX: 00000107 Apr 25 19:26:21 laptop kernel: ESI: 00000107 EDI: 00007f96 EBP: c4528000 DS: 0018 ES: 0018 Apr 25 19:26:21 laptop kernel: CR0: 8005003b CR2: 40015000 CR3: 03d63000 CR4: 00000690 Apr 25 19:26:21 laptop kernel: Call Trace: [] [] [] [] [] [] [] [] [] Warning (Oops_read): Code line not seen, dumping what data is available >>EIP; 0000000ccbeaec67 <===== Trace; c011a217 Trace; c011a417 Trace; c022e60e Trace; c92287f7 <_end+8eb468b/c834e94> Trace; c01171ae Trace; c011141c Trace; c02287f7 Trace; c01171ae Trace; c0106ba5 I've been able to narrow it down to my use of dev_queue_xmit in my device event handler. If I don't queue packets there after initialization, the box doesn't hang. It does however cease to function correctly (I don't receive any packets any more). Anyways, if any of you can give me hints/tips/DON'T DO THAT's/do it this ways, I'd be very gratefull. I'm including a patch to 2.4.x with my driver code. Regards, and thanks in advance, Bas Vermeulen ---1463811581-2040609447-988666443=:2111 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="poldhu_cs.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="poldhu_cs.patch" ZGlmZiAtdU5yIGxpbnV4LTIuNC4zLWFjMTMub3JpZy9Eb2N1bWVudGF0aW9u L0NvbmZpZ3VyZS5oZWxwIGxpbnV4LTIuNC4zLWFjMTMvRG9jdW1lbnRhdGlv bi9Db25maWd1cmUuaGVscA0KLS0tIGxpbnV4LTIuNC4zLWFjMTMub3JpZy9E b2N1bWVudGF0aW9uL0NvbmZpZ3VyZS5oZWxwCVRodSBBcHIgMjYgMTU6NDM6 MzIgMjAwMQ0KKysrIGxpbnV4LTIuNC4zLWFjMTMvRG9jdW1lbnRhdGlvbi9D b25maWd1cmUuaGVscAlUaHUgQXByIDI2IDE3OjE4OjM3IDIwMDENCkBAIC03 NjgzLDYgKzc2ODMsMTcgQEANCiAgIGEgbW9kdWxlLCBzYXkgTSBoZXJlIGFu ZCByZWFkIERvY3VtZW50YXRpb24vbW9kdWxlcy50eHQuIElmIHVuc3VyZSwN CiAgIHNheSBOLg0KIA0KK05vIFdpcmVzIE5lZWQgMTFNYnBzIFdpcmVsZXNz IExBTiBQQyBDYXJkIHN1cHBvcnQNCitDT05GSUdfUENNQ0lBX1BPTERIVQ0K KyAgU2F5IFkgaGVyZSBpZiB5b3UgaW50ZW5kIHRvIGF0dGFjaCBhIE5vIFdp cmVzIE5lZWRlZCAxMU1icHMgV2lyZWxlc3MNCisgIExBTiBQQyBDYXJkIHRv IHlvdXIgY29tcHV0ZXIuDQorDQorICBUaGlzIGRyaXZlciBpcyBhbHNvIGF2 YWlsYWJsZSBhcyBhIG1vZHVsZSAoID0gY29kZSB3aGljaCBjYW4gYmUNCisg IGluc2VydGVkIGluIGFuZCByZW1vdmVkIGZyb20gdGhlIHJ1bm5pbmcga2Vy bmVsIHdoZW5ldmVyIHlvdSB3YW50KS4NCisgIFRoZSBtb2R1bGUgd2lsbCBi ZSBjYWxsZWQgcG9sZGh1X2NzLm8uIElmIHlvdSB3YW50IHRvIGNvbXBpbGUg aXQgYXMNCisgIGEgbW9kdWxlLCBzYXkgTSBoZXJlIGFuZCByZWFkIERvY3Vt ZW50YXRpb24vbW9kdWxlcy50eHQuIElmIHVuc3VyZSwNCisgIHNheSBOLg0K Kw0KIFBMSVAgKHBhcmFsbGVsIHBvcnQpIHN1cHBvcnQNCiBDT05GSUdfUExJ UA0KICAgUExJUCAoUGFyYWxsZWwgTGluZSBJbnRlcm5ldCBQcm90b2NvbCkg aXMgdXNlZCB0byBjcmVhdGUgYQ0KZGlmZiAtdU5yIGxpbnV4LTIuNC4zLWFj MTMub3JpZy9kcml2ZXJzL25ldC9wY21jaWEvQ29uZmlnLmluIGxpbnV4LTIu NC4zLWFjMTMvZHJpdmVycy9uZXQvcGNtY2lhL0NvbmZpZy5pbg0KLS0tIGxp bnV4LTIuNC4zLWFjMTMub3JpZy9kcml2ZXJzL25ldC9wY21jaWEvQ29uZmln LmluCVRodSBBcHIgMjYgMTU6NDQ6MjYgMjAwMQ0KKysrIGxpbnV4LTIuNC4z LWFjMTMvZHJpdmVycy9uZXQvcGNtY2lhL0NvbmZpZy5pbglUaHUgQXByIDI2 IDE1OjM3OjIwIDIwMDENCkBAIC0zMSw2ICszMSw3IEBADQogICAgICAgZGVw X3RyaXN0YXRlICcgICAgWGlyY29tIE5ldHdhdmUgQWlyU3VyZmVyIHdpcmVs ZXNzIHN1cHBvcnQnIENPTkZJR19QQ01DSUFfTkVUV0FWRSAkQ09ORklHX1BD TUNJQQ0KICAgICAgIGRlcF90cmlzdGF0ZSAnICAgIEFUJlQvTHVjZW50IFdh dmVsYW4gd2lyZWxlc3Mgc3VwcG9ydCcgQ09ORklHX1BDTUNJQV9XQVZFTEFO ICRDT05GSUdfUENNQ0lBDQogICAgICAgZGVwX3RyaXN0YXRlICcgICAgQWly b25ldCA0NTAwLzQ4MDAgUENNQ0lBIHN1cHBvcnQnIENPTkZJR19BSVJPTkVU NDUwMF9DUyAkQ09ORklHX0FJUk9ORVQ0NTAwICRDT05GSUdfUENNQ0lBDQor ICAgICAgZGVwX3RyaXN0YXRlICcgICAgTm8gV2lyZXMgTmVlZGVkIDExTWJw cyBXaXJlbGVzcyBMQU4gUEMgQ2FyZCBzdXBwb3J0JyBDT05GSUdfUENNQ0lB X1BPTERIVSAkQ09ORklHX1BDTUNJQQ0KICAgIGZpDQogZmkNCiANCkBAIC0z OSw3ICs0MCw3IEBADQogICAgICAiJENPTkZJR19QQ01DSUFfTk1DTEFOIiA9 ICJ5IiAtbyAiJENPTkZJR19QQ01DSUFfU01DOTFDOTIiID0gInkiIC1vIFwN CiAgICAgICIkQ09ORklHX1BDTUNJQV9YSVJDMlBTIiA9ICJ5IiAtbyAiJENP TkZJR19QQ01DSUFfUkFZQ1MiID0gInkiIC1vIFwNCiAgICAgICIkQ09ORklH X1BDTUNJQV9ORVRXQVZFIiA9ICJ5IiAtbyAiJENPTkZJR19QQ01DSUFfV0FW RUxBTiIgPSAieSIgLW8gXA0KLSAgICAgIiRDT05GSUdfUENNQ0lBX1hJUlRV TElQIiA9ICJ5IiBdOyB0aGVuDQorICAgICAiJENPTkZJR19QQ01DSUFfWElS VFVMSVAiID0gInkiIC1vICIkQ09ORklHX1BDTUNJQV9QT0xESFUiID0gInki IF07IHRoZW4NCiAgICBkZWZpbmVfYm9vbCBDT05GSUdfUENNQ0lBX05FVENB UkQgeQ0KIGZpDQogDQpkaWZmIC11TnIgbGludXgtMi40LjMtYWMxMy5vcmln L2RyaXZlcnMvbmV0L3BjbWNpYS9NYWtlZmlsZSBsaW51eC0yLjQuMy1hYzEz L2RyaXZlcnMvbmV0L3BjbWNpYS9NYWtlZmlsZQ0KLS0tIGxpbnV4LTIuNC4z LWFjMTMub3JpZy9kcml2ZXJzL25ldC9wY21jaWEvTWFrZWZpbGUJVGh1IEFw ciAyNiAxNTo0NDoyNiAyMDAxDQorKysgbGludXgtMi40LjMtYWMxMy9kcml2 ZXJzL25ldC9wY21jaWEvTWFrZWZpbGUJVGh1IEFwciAyNiAxNjo0NTozMyAy MDAxDQpAQCAtMzAsNyArMzAsNyBAQA0KIG9iai0kKENPTkZJR19QQ01DSUFf TkVUV0FWRSkJKz0gbmV0d2F2ZV9jcy5vDQogb2JqLSQoQ09ORklHX1BDTUNJ QV9XQVZFTEFOKQkrPSB3YXZlbGFuX2NzLm8NCiBvYmotJChDT05GSUdfQUlS T05FVDQ1MDBfQ1MpCSs9IGFpcm9uZXQ0NTAwX2NzLm8NCi0NCitvYmotJChD T05GSUdfUENNQ0lBX1BPTERIVSkgICAgICAgICArPSBwb2xkaHVfY3Mubw0K ICMgQ2FyZGJ1cyBjbGllbnQgZHJpdmVycw0KIG9iai0kKENPTkZJR19QQ01D SUFfWElSVFVMSVApCSs9IHhpcmNvbV90dWxpcF9jYi5vDQogb2JqLSQoQ09O RklHX1BDTUNJQV9YSVJDT00pCSs9IHhpcmNvbV9jYi5vDQpAQCAtNDUsMyAr NDUsNyBAQA0KIGlibXRyX2NzLm86IHRtcC1pYm10ci5vIGlibXRyX2NzLmMN CiAJJChDQykgJChDRkxBR1MpIC1EUENNQ0lBIC1jIC1vIHRtcC0kQCBpYm10 cl9jcy5jDQogCSQoTEQpIC1yIC1vICRAIHRtcC0kQCB0bXAtaWJtdHIubw0K Kw0KK3BvbGRodV9jcy5vOiBzbndubXAubyBwb2xkaHUubw0KKwkkKExEKSAt ciAtbyAkQCBwb2xkaHUubyBzbndubXAubw0KKw0KZGlmZiAtdU5yIGxpbnV4 LTIuNC4zLWFjMTMub3JpZy9kcml2ZXJzL25ldC9wY21jaWEvcG9sZGh1LmMg bGludXgtMi40LjMtYWMxMy9kcml2ZXJzL25ldC9wY21jaWEvcG9sZGh1LmMN Ci0tLSBsaW51eC0yLjQuMy1hYzEzLm9yaWcvZHJpdmVycy9uZXQvcGNtY2lh L3BvbGRodS5jCVRodSBKYW4gIDEgMDE6MDA6MDAgMTk3MA0KKysrIGxpbnV4 LTIuNC4zLWFjMTMvZHJpdmVycy9uZXQvcGNtY2lhL3BvbGRodS5jCUZyaSBB cHIgIDYgMTU6MDI6MzggMjAwMQ0KQEAgLTAsMCArMSwxNDg1IEBADQorLyo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQorDQorICAgIEEgUENNQ0lB IGV0aGVybmV0IGRyaXZlciBmb3IgdGhlIE5XTiBQb2xkaHUgY2FyZHMuDQor DQorICAgIENvcHlyaWdodCAoQykgMjAwMCBCYXMgVmVybWV1bGVuIC0tIGJ2 ZXJtZXVsQGJsYWNrc3Rhci5ubA0KKw0KKyAgICBwb2xkaHVfY3MuYyAwLjEu MiAyMDAxLzAzLzA3DQorDQorICAgIFZlcnNpb24gMC4xLjIgaXMgZGVzaWdu ZWQgdG8gd29yayB3aXRoIGtlcm5lbCB2ZXJzaW9uIDIuNC4wKywgDQorICAg IHdoZXJlIHRoZSBQQ01DSUEgY29kZSBoYXMgYmVlbiBpbnRlZ3JhdGVkIGlu dG8gdGhlIGtlcm5lbC4NCisNCisgICAgVGhpcyBzb2Z0d2FyZSBtYXkgYmUg dXNlZCBhbmQgZGlzdHJpYnV0ZWQgYWNjb3JkaW5nIHRvIHRoZQ0KKyAgICB0 ZXJtcyBvZiB0aGUgR05VIFB1YmxpYyBMaWNlbnNlLCBpbmNvcnBvcmF0ZWQg aGVyZWluIGJ5DQorICAgIHJlZmVyZW5jZS4NCisNCis9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQorDQorICAgIE5vIFdpcmVzIE5lZWRlZCBwcm92 aWRlcyBOTyBTVVBQT1JUIGZvciB0aGVzZSBkcml2ZXJzLiANCisNCisgICAg SWYgeW91IGhhdmUgYW55IHF1ZXN0aW9ucywgYnVnLXJlcG9ydHMsIHN1Z2dl c3Rpb25zLCBmZWF0dXJlLXJlcXVlc3RzLA0KKyAgICBjb250YWN0IG1lIGF0 IHN3YWxsb3dAYmxhY2tzdGFyLm5sIA0KKw0KKz09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0qLw0KKyNpbmNsdWRlIDxsaW51eC9jb25maWcuaD4NCisj aWZkZWYgX19JTl9QQ01DSUFfUEFDS0FHRV9fDQorI2luY2x1ZGUgPHBjbWNp YS9rX2NvbXBhdC5oPg0KKyNlbmRpZg0KKw0KKyNpbmNsdWRlIDxsaW51eC9p bml0Lmg+DQorI2luY2x1ZGUgPGxpbnV4L21vZHVsZS5oPg0KKyNpbmNsdWRl IDxsaW51eC9wcm9jX2ZzLmg+DQorI2luY2x1ZGUgPGxpbnV4L2tlcm5lbC5o Pg0KKyNpbmNsdWRlIDxsaW51eC9zY2hlZC5oPg0KKyNpbmNsdWRlIDxsaW51 eC9wdHJhY2UuaD4NCisjaW5jbHVkZSA8bGludXgvbWFsbG9jLmg+DQorI2lu Y2x1ZGUgPGxpbnV4L3N0cmluZy5oPg0KKyNpbmNsdWRlIDxsaW51eC90aW1l ci5oPg0KKyNpbmNsdWRlIDxsaW51eC9pbnRlcnJ1cHQuaD4NCisjaW5jbHVk ZSA8bGludXgvaW4uaD4NCisjaW5jbHVkZSA8bGludXgvZGVsYXkuaD4NCisj aW5jbHVkZSA8YXNtL3VhY2Nlc3MuaD4NCisjaW5jbHVkZSA8YXNtL2lvLmg+ DQorI2luY2x1ZGUgPGFzbS9zeXN0ZW0uaD4NCisjaW5jbHVkZSA8YXNtL2Jp dG9wcy5oPg0KKw0KKyNpbmNsdWRlIDxsaW51eC9uZXRkZXZpY2UuaD4NCisj aW5jbHVkZSA8bGludXgvZXRoZXJkZXZpY2UuaD4NCisjaW5jbHVkZSA8bGlu dXgvc29ja2V0Lmg+DQorI2luY2x1ZGUgPGxpbnV4L3NrYnVmZi5oPg0KKyNp bmNsdWRlIDxsaW51eC9pZl9hcnAuaD4NCisjaW5jbHVkZSA8bGludXgvaW9w b3J0Lmg+DQorI2luY2x1ZGUgPGxpbnV4L3dpcmVsZXNzLmg+DQorDQorI2lu Y2x1ZGUgPHBjbWNpYS92ZXJzaW9uLmg+DQorI2luY2x1ZGUgPHBjbWNpYS9j c190eXBlcy5oPg0KKyNpbmNsdWRlIDxwY21jaWEvY3MuaD4NCisjaW5jbHVk ZSA8cGNtY2lhL2Npc3RwbC5oPg0KKyNpbmNsdWRlIDxwY21jaWEvY2lzcmVn Lmg+DQorI2luY2x1ZGUgPHBjbWNpYS9jaXNjb2RlLmg+DQorI2luY2x1ZGUg PHBjbWNpYS9kcy5oPg0KKw0KKyNpbmNsdWRlICJwb2xkaHUuaCINCisjaW5j bHVkZSAic253bm1wLmgiDQorDQorI2RlZmluZSBUWF9USU1FT1VUIAkJKCg1 MDAqSFopLzEwMDApDQorI2RlZmluZSBUWF9DVFNfVElNRU9VVAkJKCgxMDAq SFopLzEwMDApDQorDQorI2RlZmluZSBNQVhfUk9BTVRBQkxFX1NJWkUJCTI1 Ng0KKw0KK3N0cnVjdCBwb2xkaHVfcm9hbV9lbnRyeV90IHsNCisgICAgdW5z aWduZWQgY2hhciBic3NpZFtNQVhfQUREUl9MRU5dOw0KKyAgICBjaGFyIGVz c2lkW0lXX0VTU0lEX01BWF9TSVpFICsgMV07DQorICAgIGludCBic3N0eXBl Ow0KKyAgICBpbnQgY2hhbm5lbDsNCisgICAgaW50IHJvYW1hZ2U7DQorICAg IGludCBxdWFsaXR5Ow0KKyAgICBpbnQgbG9hZDsNCisgICAgaW50IGJlYWNv bnBlcmlvZDsNCisgICAgaW50IGR0aW1wZXJpb2Q7DQorICAgIHUxNiBjYXBp bmZvOw0KKyAgICB1bnNpZ25lZCBjaGFyIHJhdGVzW01BWF9BRERSX0xFTl07 DQorfTsNCisNCitzdHJ1Y3QgcG9sZGh1X3JvYW1fdGFibGVfdCB7DQorICAg IHN0cnVjdCBwb2xkaHVfcm9hbV9lbnRyeV90IGVudHJ5W01BWF9ST0FNVEFC TEVfU0laRV07IA0KKyAgICBpbnQgc2l6ZTsNCit9Ow0KKw0KK3N0cnVjdCBw b2xkaHVfZW5jcnlwdGlvbiB7DQorICAgIGludCBhaXJsb2NrOw0KKyAgICBp bnQgZW5hYmxlOw0KKyAgICBpbnQgcmVzdHJpY3RlZDsNCisgICAgaW50IGlu ZGV4Ow0KKyAgICB1bnNpZ25lZCBjaGFyIGtleXNbU05XTk1QX01BWF9LRVlf U0laRV07DQorfTsNCisNCitzdHJ1Y3QgcG9sZGh1X3ByaXZhdGUgew0KKyAg ICBkZXZfbm9kZV90IG5vZGU7DQorICAgIHN0cnVjdCBuZXRfZGV2aWNlX3N0 YXRzIHN0YXRzOw0KKyAgICBzdHJ1Y3QgcG9sZGh1X3JvYW1fdGFibGVfdCBy b2FtX3RhYmxlOw0KKyAgICBzdHJ1Y3QgcG9sZGh1X2VuY3J5cHRpb24gZW5j Ow0KKyAgICBjaGFyIHNzaWRbSVdfRVNTSURfTUFYX1NJWkUgKyAxXTsNCisg ICAgY2hhciB3YW50ZWRfZXNzaWRbSVdfRVNTSURfTUFYX1NJWkUgKyAxXTsN CisgICAgdW5zaWduZWQgY2hhciBic3NpZFtNQVhfQUREUl9MRU5dOw0KKyAg ICB1bnNpZ25lZCBsb25nIGNhcGluZm87DQorICAgIHN0cnVjdCB0aW1lcl9s aXN0IGJzc2lkX3RpbWVyOw0KKyAgICBzdHJ1Y3QgdGltZXJfbGlzdCByb2Ft X3RpbWVyOw0KKyAgICBzcGlubG9ja190IGxvY2s7DQorICAgIGludCBpc181 NTA7DQorICAgIHVuc2lnbmVkIHNlcXVlbmNlOw0KKyAgICB1bnNpZ25lZCBy ZXNldDsNCit9Ow0KKw0KK3N0YXRpYyBjaGFyICp2ZXJzaW9uID0gIk5vIFdp cmVzIE5lZWRlZCBQb2xkaHUgZHJpdmVyIHYwLjEuMiI7DQorDQorI2lmZGVm IENPTkZJR19QQ01DSUFfUE9MREhVX0RFQlVHDQorc3RhdGljIGludCBwb2xk aHVfZGVidWcgPSBDT05GSUdfUENNQ0lBX1BPTERIVV9ERUJVRzsNCitNT0RV TEVfUEFSTShwb2xkaHVfZGVidWcsICJpIik7DQorI2RlZmluZSBERUJVRyhu LCBhcmdzLi4uKSAgaWYgKHBvbGRodV9kZWJ1Zz4obikpIHByaW50ayhLRVJO X0RFQlVHIGFyZ3MpDQorI2Vsc2UNCisjZGVmaW5lIERFQlVHKG4sIGFyZ3Mu Li4pDQorI2VuZGlmDQorDQorI2RlZmluZSBQUklOVChuLCBhcmdzLi4uKSBw cmludGsoS0VSTl9JTkZPIGFyZ3MpDQorI2RlZmluZSBrZnJlZV9zKG8scykg a2ZyZWUobykNCisNCisvKj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0qLw0K Kw0KKy8qIFBhcmFtZXRlcnMgdGhhdCBjYW4gYmUgc2V0IHdpdGggJ2luc21v ZCcgKi8NCisNCisvKiBCaXRtYXAgb2YgaW50ZXJydXB0cyB0byBjaG9vc2Ug ZnJvbSAqLw0KK3N0YXRpYyB1X2ludCBpcnFfbWFzayA9IDB4ZGViODsNCitz dGF0aWMgaW50IGlycV9saXN0WzRdID0geyAtMSB9Ow0KKy8qIE5ldHdvcmsg cGFyYW1ldGVycyAqLw0KK3N0YXRpYyBjaGFyICpzc2lkID0gImRlZmF1bHQi Ow0KKw0KKy8qIEVuY3J5cHRpb24gcGFyYW1ldGVycyAqLw0KK3N0YXRpYyB1 bnNpZ25lZCBjaGFyIGtleXNbU05XTk1QX01BWF9LRVlfU0laRV0gPSANCisJ eyAwLDAsMCwwLDAsIDAsMCwwLDAsMCwgMCwwLDAsMCwwLCAwLDAsMCwwLDAs IH07DQorc3RhdGljIGludCBrZXlpZCA9IDA7DQorc3RhdGljIGludCBlbmNy eXB0ID0gMDsNCitzdGF0aWMgaW50IHJlc3RyaWN0ZWQgPSAwOw0KKy8qIEFp cmxvY2sgZGVmYXVsdCBkaXNhYmxlZCAqLw0KK3N0YXRpYyBpbnQgYWlybG9j ayA9IDA7DQorTU9EVUxFX0FVVEhPUigiQmFzIFZlcm1ldWxlbiA8c3dhbGxv d0BibGFja3N0YXIubmw+Iik7DQorTU9EVUxFX0RFU0NSSVBUSU9OKCJObyBX aXJlcyBOZWVkZWQgMTFNYnBzIFdpcmVsZXNzIExBTiBQQyBDYXJkIGV0aGVy bmV0IGRyaXZlciIpOw0KK01PRFVMRV9QQVJNKHNzaWQsICJzIik7DQorTU9E VUxFX1BBUk1fREVTQyhzc2lkLCAiRGVmYXVsdCBzZXNzaW9uIHRvIGpvaW4i KTsNCitNT0RVTEVfUEFSTShlbmNyeXB0LCAiaSIpOw0KK01PRFVMRV9QQVJN X0RFU0MoZW5jcnlwdCwgIkVuYWJsZXMgRW5jcnlwdGlvbiIpOw0KK01PRFVM RV9QQVJNKGtleXMsICI1LTIwYiIpOw0KK01PRFVMRV9QQVJNX0RFU0Moa2V5 cywgIldpcmVkIEVxdWl2YWxlbnQgUHJpdmFjeSBrZXlzIik7DQorTU9EVUxF X1BBUk0oa2V5aWQsICJpIik7DQorTU9EVUxFX1BBUk1fREVTQyhrZXlpZCwg IkluZGV4IG9mIHRoZSBkZWZhdWx0IFdFUCBrZXkiKTsNCitNT0RVTEVfUEFS TShyZXN0cmljdGVkLCAiaSIpOw0KK01PRFVMRV9QQVJNX0RFU0MocmVzdHJp Y3RlZCwgIkV4Y2x1ZGUgdW5lbmNyeXB0ZWQgdHJhZmZpYyIpOw0KK01PRFVM RV9QQVJNKGFpcmxvY2ssICJpIik7DQorTU9EVUxFX1BBUk1fREVTQyhhaXJs b2NrLCAiRW5hYmxlcyBBaXJsb2NrICh0bSkgU2VjdXJpdHkiKTsNCisNCitN T0RVTEVfUEFSTShpcnFfbWFzaywgImkiKTsNCitNT0RVTEVfUEFSTShpcnFf bGlzdCwgIjEtNGkiKTsNCisNCisvKj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0qLw0KKy8qIFBDTUNJQSByZWxhdGVkIGRlZmluaXRpb25zICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICovDQorDQorc3Rh dGljIHZvaWQgcG9sZGh1X3BjbWNpYV9jb25maWcoZGV2X2xpbmtfdCAqbGlu ayk7DQorc3RhdGljIHZvaWQgcG9sZGh1X3BjbWNpYV9yZWxlYXNlKHVfbG9u ZyBhcmcpOw0KK3N0YXRpYyBpbnQgcG9sZGh1X3BjbWNpYV9ldmVudChldmVu dF90IGV2ZW50LCBpbnQgcHJpb3JpdHksDQorCQkJIGV2ZW50X2NhbGxiYWNr X2FyZ3NfdCAqYXJncyk7DQorc3RhdGljIGRldl9saW5rX3QgKnBvbGRodV9w Y21jaWFfYXR0YWNoKHZvaWQpOw0KK3N0YXRpYyB2b2lkIHBvbGRodV9wY21j aWFfZGV0YWNoKGRldl9saW5rX3QgKik7DQorDQorc3RhdGljIGRldl9pbmZv X3QgZGV2X2luZm8gPSAicG9sZGh1X2NzIjsNCitzdGF0aWMgZGV2X2xpbmtf dCAqZGV2X2xpc3QgPSBOVUxMOw0KKw0KK3N0YXRpYyB2b2lkIGZsdXNoX3N0 YWxlX2xpbmtzKHZvaWQpOw0KK3N0YXRpYyB2b2lkIGNzX2Vycm9yKGNsaWVu dF9oYW5kbGVfdCBoYW5kbGUsIGludCBmdW5jLCBpbnQgcmV0KTsNCisNCisv Kj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0qLw0KKy8qICBFdGhlcm5ldCBk ZXZpY2UgcmVsYXRlZCBmdW5jdGlvbnMgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICovDQorDQorc3RhdGljIGludCBwb2xkaHVfb3Blbihz dHJ1Y3QgbmV0X2RldmljZSAqZGV2KTsNCitzdGF0aWMgaW50IHBvbGRodV9j bG9zZShzdHJ1Y3QgbmV0X2RldmljZSAqZGV2KTsNCitzdGF0aWMgaW50IHBv bGRodV9jb25maWcoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgc3RydWN0IGlm bWFwICptYXApOw0KK3N0YXRpYyBpbnQgcG9sZGh1X3N0YXJ0X3htaXQoc3Ry dWN0IHNrX2J1ZmYgKnNrYiwgc3RydWN0IG5ldF9kZXZpY2UgKmRldik7DQor c3RhdGljIHZvaWQgcG9sZGh1X3RpbWVvdXQoc3RydWN0IG5ldF9kZXZpY2Ug KmRldik7DQorc3RhdGljIHZvaWQgcG9sZGh1X2ludGVycnVwdChpbnQgaXJx LCB2b2lkICpkZXZfaWQsIHN0cnVjdCBwdF9yZWdzICpyZWdzKTsNCitzdGF0 aWMgc3RydWN0IG5ldF9kZXZpY2Vfc3RhdHMgKnBvbGRodV9nZXRfc3RhdHMo c3RydWN0IG5ldF9kZXZpY2UgKmRldik7DQorc3RhdGljIGludCBwb2xkaHVf cngoc3RydWN0IG5ldF9kZXZpY2UgKmRldik7DQorc3RhdGljIHZvaWQgcG9s ZGh1X3NldF9tdWx0aWNhc3RfbGlzdChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2 KSB7IHJldHVybjsgfTsNCitzdGF0aWMgaW50IHBvbGRodV9kb19pb2N0bChz dHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBzdHJ1Y3QgaWZyZXEgKmlmciwgaW50 IGNtZCk7DQorc3RhdGljIHZvaWQgcG9sZGh1X2h3X3Jlc2V0KHN0cnVjdCBu ZXRfZGV2aWNlICpkZXYpOw0KK3N0YXRpYyBpbnQgcG9sZGh1X2VuY3J5cHQo c3RydWN0IG5ldF9kZXZpY2UgKmRldik7DQorDQorLyo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ki8NCisvKiBTdHVmZiBuZWVkZWQgdG8gaW5pdGlhbGx5 IGNvbmZpZ3VyZSB0aGUgc2Vzc2lvbi9lbmNyeXB0aW9uL2V0YyAgICAgICAq Lw0KKw0KK3N0YXRpYyBpbnQgcG9sZGh1X2RldmljZV9ldmVudChzdHJ1Y3Qg bm90aWZpZXJfYmxvY2sgKnVudXNlZCwgdW5zaWduZWQgbG9uZw0KK2V2ZW50 LCB2b2lkICpwdHIpOw0KKw0KK3N0YXRpYyBzdHJ1Y3Qgbm90aWZpZXJfYmxv Y2sgcG9sZGh1X2Rldl9ub3RpZmllciA9IHsNCisgICAgcG9sZGh1X2Rldmlj ZV9ldmVudCwNCisgICAgTlVMTCwNCisgICAgMA0KK307DQorDQorc3RhdGlj IHN0cnVjdCBuZXRfZGV2aWNlKiBwb2xkaHVzW01BWF9QT0xESFVTXSA9IA0K KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB7IE5VTEws IE5VTEwsIE5VTEwsIE5VTEwgfTsNCisNCisvKj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0qLw0KKy8qIFRpbWVycyBmdW5jdGlvbnMgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICovDQor DQorc3RhdGljIHZvaWQgcG9sZGh1X2Jzc2lkX3RpbWVyKHVuc2lnbmVkIGxv bmcgZGF0YSk7DQorc3RhdGljIHZvaWQgcG9sZGh1X3JvYW1pbmdfdGltZXIo dW5zaWduZWQgbG9uZyBkYXRhKTsNCisNCisvKj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0qLw0KKy8qIFByb2MgZmlsZXN5c3RlbSBmdW5jdGlvbnMgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICovDQor c3RhdGljIGludCBwb2xkaHVfcHJvY19yZWFkKGNoYXIgKmJ1ZiwgY2hhciAq KnN0YXJ0LCBvZmZfdCBvZmYsDQorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBpbnQgY291bnQsIGludCAqZW9mLCB2b2lkICpkYXRhKTsNCisNCitz dGF0aWMgc3RydWN0IHByb2NfZGlyX2VudHJ5KiBwb2xkaHVfcHJvY19kaXIg PSBOVUxMOw0KKw0KKy8qPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSovDQor DQorc3RhdGljIHZvaWQgZmx1c2hfc3RhbGVfbGlua3Modm9pZCkNCit7DQor ICAgIGRldl9saW5rX3QgKmxpbmssICpuZXh0Ow0KKyAgICBmb3IgKGxpbmsg PSBkZXZfbGlzdDsgbGluazsgbGluayA9IG5leHQpIHsNCisgICAgICAgIG5l eHQgPSBsaW5rLT5uZXh0Ow0KKyAgICAgICAgaWYgKGxpbmstPnN0YXRlICYg REVWX1NUQUxFX0xJTkspDQorICAgICAgICAgICAgcG9sZGh1X3BjbWNpYV9k ZXRhY2gobGluayk7DQorICAgIH0NCit9DQorDQorLyo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ki8NCisNCitzdGF0aWMgdm9pZCBjc19lcnJvcihjbGll bnRfaGFuZGxlX3QgaGFuZGxlLCBpbnQgZnVuYywgaW50IHJldCkNCit7DQor ICAgIGVycm9yX2luZm9fdCBlcnIgPSB7IGZ1bmMsIHJldCB9Ow0KKyAgICBD YXJkU2VydmljZXMoUmVwb3J0RXJyb3IsIGhhbmRsZSwgJmVycik7DQorfQ0K Kw0KKy8qPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCisNCisgICAgV2Ug bmV2ZXIgbmVlZCB0byBkbyBhbnl0aGluZyB3aGVuIGEgUG9sZGh1IGRldmlj ZSBpcw0KKyAgICAiaW5pdGlhbGl6ZWQiIGJ5IHRoZSBuZXQgc29mdHdhcmUs IGJlY2F1c2Ugd2Ugb25seSByZWdpc3RlciBhbHJlYWR5LQ0KKyAgICBmb3Vu ZCBjYXJkcy4NCisNCis9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSovDQor DQorc3RhdGljIGludCBwb2xkaHVfaW5pdChzdHJ1Y3QgbmV0X2RldmljZSAq ZGV2KQ0KK3sNCisgICAgcmV0dXJuIDA7DQorfQ0KKw0KKy8qPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQorDQorICAgIHBvbGRodV9hdHRhY2goKSBjcmVh dGVzIGFuICJpbnN0YW5jZSIgb2YgdGhlIGRyaXZlciwgYWxsb2NhdGluZw0K KyAgICBsb2NhbCBkYXRhIHN0cnVjdHVyZXMgZm9yIG9uZSBkZXZpY2UuIFRo ZSBkZXZpY2UgaXMgcmVnaXN0ZXJlZA0KKyAgICB3aXRoIENhcmQgU2Vydmlj ZXMuDQorDQorPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ki8NCisNCitzdGF0 aWMgZGV2X2xpbmtfdCAqcG9sZGh1X3BjbWNpYV9hdHRhY2godm9pZCkNCit7 DQorICAgIGNsaWVudF9yZWdfdCBjbGllbnRfcmVnOw0KKyAgICBkZXZfbGlu a190ICpsaW5rOw0KKyAgICBzdHJ1Y3QgbmV0X2RldmljZSAqZGV2Ow0KKyAg ICBzdHJ1Y3QgcG9sZGh1X3ByaXZhdGUqIGxwOw0KKyAgICBpbnQgaSwgcmV0 Ow0KKw0KKyAgICBERUJVRyg3LCAicG9sZGh1X2NzOiBwb2xkaHVfcGNtY2lh X2F0dGFjaCgpXG4iKTsNCisgICAgZmx1c2hfc3RhbGVfbGlua3MoKTsNCisN CisgICAgLyogQ3JlYXRlIG5ldyBldGhlcm5ldCBkZXZpY2UgKi8NCisgICAg bGluayA9IGttYWxsb2Moc2l6ZW9mKHN0cnVjdCBkZXZfbGlua190KSwgR0ZQ X0tFUk5FTCk7DQorICAgIG1lbXNldChsaW5rLCAwLCBzaXplb2Yoc3RydWN0 IGRldl9saW5rX3QpKTsNCisgICAgbGluay0+cmVsZWFzZS5mdW5jdGlvbiA9 ICZwb2xkaHVfcGNtY2lhX3JlbGVhc2U7DQorICAgIGxpbmstPnJlbGVhc2Uu ZGF0YSA9ICh1X2xvbmcpbGluazsNCisgICAgbGluay0+aW8uTnVtUG9ydHMx ID0gMHgzZjsNCisgICAgbGluay0+aW8uQXR0cmlidXRlczEgPSBJT19EQVRB X1BBVEhfV0lEVEhfMTY7DQorICAgIGxpbmstPmlvLklPQWRkckxpbmVzID0g NjsNCisgICAgbGluay0+aXJxLkF0dHJpYnV0ZXMgPSBJUlFfVFlQRV9FWENM VVNJVkUgfCBJUlFfSEFORExFX1BSRVNFTlQ7DQorICAgIGxpbmstPmlycS5J UlFJbmZvMSA9IElSUV9JTkZPMl9WQUxJRCB8IElSUV9MRVZFTF9JRDsNCisg ICAgaWYgKGlycV9saXN0WzBdID09IC0xKQ0KKyAgICAgICAgbGluay0+aXJx LklSUUluZm8yID0gaXJxX21hc2s7DQorICAgIGVsc2UNCisgICAgICAgIGZv ciAoaSA9IDA7IGkgPCA0OyBpKyspDQorICAgICAgICAgICAgbGluay0+aXJx LklSUUluZm8yIHw9IDEgPDwgaXJxX2xpc3RbaV07DQorICAgIGxpbmstPmly cS5IYW5kbGVyID0gJnBvbGRodV9pbnRlcnJ1cHQ7DQorICAgIGxpbmstPmNv bmYuQXR0cmlidXRlcyA9IENPTkZfRU5BQkxFX0lSUTsNCisgICAgbGluay0+ Y29uZi5WY2MgPSA1MDsNCisgICAgbGluay0+Y29uZi5JbnRUeXBlID0gSU5U X01FTU9SWV9BTkRfSU87DQorICAgIGxpbmstPmNvbmYuQ29uZmlnSW5kZXgg PSAxOw0KKyAgICBsaW5rLT5jb25mLlByZXNlbnQgPSBQUkVTRU5UX09QVElP TjsNCisNCisgICAgZGV2ID0ga21hbGxvYyhzaXplb2Yoc3RydWN0IG5ldF9k ZXZpY2UpLCBHRlBfS0VSTkVMKTsNCisgICAgbWVtc2V0KGRldiwgMCwgc2l6 ZW9mKHN0cnVjdCBuZXRfZGV2aWNlKSk7DQorDQorICAgIC8qIE1ha2UgdXAg YSBQb2xkaHUgc3BlY2lmaWMgZGF0YSBzdHJ1Y3R1cmUuICovDQorICAgIGRl di0+cHJpdiA9IGttYWxsb2Moc2l6ZW9mKHN0cnVjdCBwb2xkaHVfcHJpdmF0 ZSksIEdGUF9LRVJORUwpOw0KKyAgICBtZW1zZXQoZGV2LT5wcml2LCAwLCBz aXplb2Yoc3RydWN0IHBvbGRodV9wcml2YXRlKSk7DQorDQorICAgIGxwID0g KHN0cnVjdCBwb2xkaHVfcHJpdmF0ZSopZGV2LT5wcml2Ow0KKw0KKyAgICAv KiBJbml0aWFsaXplIHRoZSBzcGlubG9jayAqLw0KKyAgICBzcGluX2xvY2tf aW5pdCgmbHAtPmxvY2spOw0KKw0KKyAgICAvKiBJbml0aWFsaXplIHRoZSB0 aW1lcnMgKi8NCisgICAgaW5pdF90aW1lcigmbHAtPmJzc2lkX3RpbWVyKTsN CisgICAgbHAtPmJzc2lkX3RpbWVyLmRhdGEgPSAobG9uZylkZXY7DQorICAg IGxwLT5ic3NpZF90aW1lci5mdW5jdGlvbiA9ICZwb2xkaHVfYnNzaWRfdGlt ZXI7DQorDQorICAgIGluaXRfdGltZXIoJmxwLT5yb2FtX3RpbWVyKTsNCisg ICAgbHAtPnJvYW1fdGltZXIuZGF0YSA9IChsb25nKWRldjsNCisgICAgbHAt PnJvYW1fdGltZXIuZnVuY3Rpb24gPSAmcG9sZGh1X3JvYW1pbmdfdGltZXI7 DQorDQorICAgIC8qIEluaXRpYWxpemUgdGhlIHJvYW1pbmcgdGFibGUgc2l6 ZSAqLw0KKyAgICBscC0+cm9hbV90YWJsZS5zaXplID0gODsNCisNCisgICAg LyogVGhlIFBvbGRodSBzcGVjaWZpYyBlbnRyaWVzIGluIHRoZSBkZXZpY2Ug c3RydWN0dXJlLiAqLw0KKyAgICBkZXYtPmhhcmRfc3RhcnRfeG1pdCAJPSAm cG9sZGh1X3N0YXJ0X3htaXQ7DQorICAgIGRldi0+c2V0X2NvbmZpZyAJCT0g JnBvbGRodV9jb25maWc7DQorICAgIGRldi0+Z2V0X3N0YXRzCQk9ICZwb2xk aHVfZ2V0X3N0YXRzOw0KKyAgICBkZXYtPnNldF9tdWx0aWNhc3RfbGlzdAk9 ICZwb2xkaHVfc2V0X211bHRpY2FzdF9saXN0Ow0KKyAgICBkZXYtPmRvX2lv Y3RsCQk9ICZwb2xkaHVfZG9faW9jdGw7DQorICAgIGRldi0+dHhfdGltZW91 dAkJPSAmcG9sZGh1X3RpbWVvdXQ7DQorICAgIGRldi0+d2F0Y2hkb2dfdGlt ZW8JCT0gVFhfVElNRU9VVDsNCisNCisgICAgZXRoZXJfc2V0dXAoZGV2KTsN CisNCisgICAgZGV2LT5pbml0IAkJCT0gJnBvbGRodV9pbml0Ow0KKyAgICBk ZXYtPm9wZW4JIAkJPSAmcG9sZGh1X29wZW47DQorICAgIGRldi0+c3RvcCAJ CQk9ICZwb2xkaHVfY2xvc2U7DQorICAgIGxpbmstPnByaXYJCQk9IGxpbmst PmlycS5JbnN0YW5jZSA9IGRldjsNCisgICAgbmV0aWZfc3RvcF9xdWV1ZShk ZXYpOw0KKw0KKyAgICAvKiBSZWdpc3RlciB3aXRoIENhcmQgU2VydmljZXMg Ki8NCisgICAgbGluay0+bmV4dCAJCQk9IGRldl9saXN0Ow0KKyAgICBkZXZf bGlzdCAJCQk9IGxpbms7DQorICAgIGNsaWVudF9yZWcuZGV2X2luZm8gCT0g JmRldl9pbmZvOw0KKyAgICBjbGllbnRfcmVnLkF0dHJpYnV0ZXMgCT0gSU5G T19JT19DTElFTlQgfCBJTkZPX0NBUkRfU0hBUkU7DQorICAgIGNsaWVudF9y ZWcuRXZlbnRNYXNrIAk9DQorICAgICAgICBDU19FVkVOVF9DQVJEX0lOU0VS VElPTiB8IENTX0VWRU5UX0NBUkRfUkVNT1ZBTCB8DQorICAgICAgICBDU19F VkVOVF9SRVNFVF9QSFlTSUNBTCB8IENTX0VWRU5UX0NBUkRfUkVTRVQgICB8 DQorICAgICAgICBDU19FVkVOVF9QTV9TVVNQRU5EICAgICB8IENTX0VWRU5U X1BNX1JFU1VNRTsNCisgICAgY2xpZW50X3JlZy5ldmVudF9oYW5kbGVyIAk9 ICZwb2xkaHVfcGNtY2lhX2V2ZW50Ow0KKyAgICBjbGllbnRfcmVnLlZlcnNp b24gCQk9IDB4MDIxMDsNCisgICAgY2xpZW50X3JlZy5ldmVudF9jYWxsYmFj a19hcmdzLmNsaWVudF9kYXRhID0gbGluazsNCisNCisgICAgcmV0ID0gQ2Fy ZFNlcnZpY2VzKFJlZ2lzdGVyQ2xpZW50LCAmbGluay0+aGFuZGxlLCAmY2xp ZW50X3JlZyk7DQorICAgIGlmIChyZXQgIT0gMCkgew0KKyAgICAgICAgY3Nf ZXJyb3IobGluay0+aGFuZGxlLCBSZWdpc3RlckNsaWVudCwgcmV0KTsNCisg ICAgICAgIHBvbGRodV9wY21jaWFfZGV0YWNoKGxpbmspOw0KKyAgICAgICAg cmV0dXJuIE5VTEw7DQorICAgIH0NCisNCisgICAgcmV0dXJuIGxpbms7DQor fQ0KKw0KKy8qPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCisNCisgICAg VGhpcyBkZWxldGVzIGEgZHJpdmVyICJpbnN0YW5jZSIuIFRoZSBkZXZpY2Ug aXMgZGUtcmVnaXN0ZXJlZA0KKyAgICB3aXRoIENhcmQgU2VydmljZXMuIElm IGl0IGhhcyBiZWVuIHJlbGVhc2VkLCBhbGwgbG9jYWwgZGF0YQ0KKyAgICBz dHJ1Y3R1cmVzIGFyZSBmcmVlZC4gT3RoZXJ3aXNlLCB0aGUgc3RydWN0dXJl IHdpbGwgYmUgZnJlZWQNCisgICAgd2hlbiB0aGUgZGV2aWNlIGlzIHJlbGVh c2VkLg0KKw0KKz09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ki8NCisNCitz dGF0aWMgdm9pZCBwb2xkaHVfcGNtY2lhX2RldGFjaChkZXZfbGlua190ICps aW5rKQ0KK3sNCisgICAgZGV2X2xpbmtfdCAqKmxpbmtwOw0KKyAgICBsb25n IGZsYWdzOw0KKw0KKyAgICBERUJVRyg3LCAicG9sZGh1X2NzOiBwb2xkaHVf cGNtY2lhX2RldGFjaCgweCVwKVxuIiwgbGluayk7DQorDQorICAgIC8qIExv Y2F0ZSBkZXZpY2Ugc3RydWN0dXJlICovDQorICAgIGZvciAobGlua3AgPSAm ZGV2X2xpc3Q7ICpsaW5rcDsgbGlua3AgPSAmKCpsaW5rcCktPm5leHQpDQor ICAgICAgICBpZiAoKmxpbmtwID09IGxpbmspIGJyZWFrOw0KKyAgICBpZiAo KmxpbmtwID09IE5VTEwpDQorICAgICAgICByZXR1cm47DQorDQorICAgIHNh dmVfZmxhZ3MoZmxhZ3MpOw0KKyAgICBjbGkoKTsNCisgICAgaWYgKGxpbmst PnN0YXRlICYgREVWX1JFTEVBU0VfUEVORElORykgew0KKyAgICAgICAgZGVs X3RpbWVyKCZsaW5rLT5yZWxlYXNlKTsNCisgICAgICAgIGxpbmstPnN0YXRl ICY9IH5ERVZfUkVMRUFTRV9QRU5ESU5HOw0KKyAgICB9DQorICAgIHJlc3Rv cmVfZmxhZ3MoZmxhZ3MpOw0KKw0KKyAgICBpZiAobGluay0+c3RhdGUgJiBE RVZfQ09ORklHKSB7DQorICAgICAgICBwb2xkaHVfcGNtY2lhX3JlbGVhc2Uo KHVfbG9uZylsaW5rKTsNCisgICAgICAgIGlmIChsaW5rLT5zdGF0ZSAmIERF Vl9TVEFMRV9DT05GSUcpIHsNCisgICAgICAgICAgICBsaW5rLT5zdGF0ZSB8 PSBERVZfU1RBTEVfTElOSzsNCisgICAgICAgICAgICByZXR1cm47DQorICAg ICAgICB9DQorICAgIH0NCisNCisgICAgaWYgKGxpbmstPmhhbmRsZSkNCisg ICAgICAgIENhcmRTZXJ2aWNlcyhEZXJlZ2lzdGVyQ2xpZW50LCBsaW5rLT5o YW5kbGUpOw0KKw0KKyAgICAvKiBVbmxpbmsgZGV2aWNlIHN0cnVjdHVyZSwg ZnJlZSBiaXRzICovDQorICAgICpsaW5rcCA9IGxpbmstPm5leHQ7DQorICAg IGlmIChsaW5rLT5wcml2KSB7DQorICAgICAgICBzdHJ1Y3QgbmV0X2Rldmlj ZSAqZGV2ID0gbGluay0+cHJpdjsNCisgICAgICAgIGludCBpOw0KKw0KKyAg ICAgICAgZm9yIChpID0gMDsgaSA8IE1BWF9QT0xESFVTOyBpKyspDQorICAg ICAgICAgICAgaWYgKHBvbGRodXNbaV0gPT0gZGV2KSBwb2xkaHVzW2ldID0g TlVMTDsNCisNCisgICAgICAgIGlmIChsaW5rLT5kZXYgIT0gTlVMTCkNCisg ICAgICAgICAgICB1bnJlZ2lzdGVyX25ldGRldihkZXYpOw0KKyAgICAgICAg aWYgKGRldi0+cHJpdikgew0KKyAgICAgICAgICAgIHN0cnVjdCBwb2xkaHVf cHJpdmF0ZSogbHAgPSBkZXYtPnByaXY7DQorICAgICAgICAgICAgZGVsX3Rp bWVyKCZscC0+YnNzaWRfdGltZXIpOw0KKyAgICAgICAgICAgIGRlbF90aW1l cigmbHAtPnJvYW1fdGltZXIpOw0KKyAgICAgICAgICAgIGtmcmVlX3MoZGV2 LT5wcml2LCBzaXplb2Yoc3RydWN0IHBvbGRodV9wcml2YXRlKSk7DQorICAg ICAgICB9DQorICAgICAgICBrZnJlZV9zKGxpbmstPnByaXYsIHNpemVvZihz dHJ1Y3QgbmV0X2RldmljZSkpOw0KKyAgICB9DQorICAgIGtmcmVlX3MobGlu aywgc2l6ZW9mKHN0cnVjdCBkZXZfbGlua190KSk7DQorfQ0KKw0KKy8qPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQorDQorICAgIHBvbGRodV9wY21j aWFfY29uZmlnKCkgaXMgc2NoZWR1bGVkIHRvIHJ1biBhZnRlciBhIENBUkRf SU5TRVJUSU9OIGV2ZW50DQorICAgIGlzIHJlY2VpdmVkLCB0byBjb25maWd1 cmUgdGhlIFBDTUNJQSBzb2NrZXQsIGFuZCB0byBtYWtlIHRoZQ0KKyAgICBl dGhlcm5ldCBkZXZpY2UgYXZhaWxhYmxlIHRvIHRoZSBzeXN0ZW0uDQorDQor PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ki8NCisNCisjZGVmaW5lIENT X0NIRUNLKGZuLCBhcmdzLi4uKSBcDQord2hpbGUgKChsYXN0X3JldCA9IENh cmRTZXJ2aWNlcyhsYXN0X2ZuPShmbiksIGFyZ3MpKSAhPSAwKSBnb3RvIGNz X2ZhaWxlZA0KKw0KKyNkZWZpbmUgQ0ZHX0NIRUNLKGZuLCBhcmdzLi4uKSBc DQoraWYgKENhcmRTZXJ2aWNlcyhmbiwgYXJncykgIT0gMCkgZ290byBuZXh0 X2VudHJ5DQorDQorc3RhdGljIHZvaWQgcG9sZGh1X3BjbWNpYV9jb25maWco ZGV2X2xpbmtfdCAqbGluaykNCit7DQorICAgIGNsaWVudF9oYW5kbGVfdCBo YW5kbGU7DQorICAgIHN0cnVjdCBuZXRfZGV2aWNlICpkZXY7DQorICAgIHN0 cnVjdCBwb2xkaHVfcHJpdmF0ZSAqbHA7DQorICAgIHR1cGxlX3QgdHVwbGU7 DQorICAgIGNpc3BhcnNlX3QgcGFyc2U7DQorICAgIHVfY2hhciBidWZbNjRd Ow0KKyAgICBpbnQgbGFzdF9mbiwgbGFzdF9yZXQsaTsNCisgICAgd2luX3Jl cV90IHJlcTsNCisgICAgbWVtcmVxX3QgbWFwOw0KKyAgICBzaG9ydCBpb2Fk ZHIsICpwaHlzX2FkZHI7DQorDQorICAgIGhhbmRsZSA9IGxpbmstPmhhbmRs ZTsNCisgICAgZGV2ID0gbGluay0+cHJpdjsNCisgICAgcGh5c19hZGRyID0g KHNob3J0ICopZGV2LT5kZXZfYWRkcjsNCisNCisgICAgREVCVUcoNywgInBv bGRodV9wY21jaWFfY29uZmlnKDB4JXApXG4iLCBsaW5rKTsNCisNCisgICAg LyogVGhpcyByZWFkcyB0aGUgY2FyZCdzIENPTkZJRyB0dXBsZSB0byBmaW5k IGl0J3MgY29uZmlndXJhdGlvbg0KKyAgICAgKiByZWdpc3RlcnMuDQorICAg ICAqLw0KKyAgICB0dXBsZS5BdHRyaWJ1dGVzIAkJPSAwOw0KKyAgICB0dXBs ZS5EZXNpcmVkVHVwbGUgCQk9IENJU1RQTF9DT05GSUc7DQorICAgIENTX0NI RUNLKEdldEZpcnN0VHVwbGUsIGhhbmRsZSwgJnR1cGxlKTsNCisgICAgdHVw bGUuVHVwbGVEYXRhIAkJPSAoY2lzZGF0YV90KilidWY7DQorICAgIHR1cGxl LlR1cGxlRGF0YU1heCAJCT0gc2l6ZW9mKGJ1Zik7DQorICAgIHR1cGxlLlR1 cGxlT2Zmc2V0CQk9IDA7DQorICAgIENTX0NIRUNLKEdldFR1cGxlRGF0YSwg IGhhbmRsZSwgJnR1cGxlKTsNCisgICAgQ1NfQ0hFQ0soUGFyc2VUdXBsZSwg ICAgaGFuZGxlLCAmdHVwbGUsICZwYXJzZSk7DQorICAgIGxpbmstPmNvbmYu Q29uZmlnQmFzZSAJPSBwYXJzZS5jb25maWcuYmFzZTsNCisgICAgbGluay0+ Y29uZi5QcmVzZW50CQk9IHBhcnNlLmNvbmZpZy5ybWFza1swXTsNCisNCisg ICAgLyogSXMgdGhpcyBhIFBvbGRodT8gKi8NCisgICAgdHVwbGUuRGVzaXJl ZFR1cGxlIAkJPSBDSVNUUExfTUFORklEOw0KKyAgICB0dXBsZS5BdHRyaWJ1 dGVzCQk9IFRVUExFX1JFVFVSTl9DT01NT047DQorICAgIGlmICgoQ2FyZFNl cnZpY2VzKEdldEZpcnN0VHVwbGUsIGhhbmRsZSwgJnR1cGxlKSA9PSBDU19T VUNDRVNTKSAmJg0KKyAgICAgICAgKENhcmRTZXJ2aWNlcyhHZXRUdXBsZURh dGEsIGhhbmRsZSwgJnR1cGxlKSAgPT0gQ1NfU1VDQ0VTUykpIHsNCisgICAg ICAgIGlmICgobGUxNl90b19jcHUoYnVmWzBdKSAhPSAweDA2MDIpICYmIChs ZTE2X3RvX2NwdShidWZbMV0pID09IDB4MDAwMykpDQorICAgICAgICAgICAg cHJpbnRrKEtFUk5fSU5GTyAicG9sZGh1X2NzOiBobW1tLCBpcyB0aGlzIHJl YWxseSBhICINCisgICAgICAgICAgICAgICAgICAgIlBvbGRodSBjYXJkPz9c biIpOw0KKyAgICB9DQorICAgIC8qIENvbmZpZ3VyZSBjYXJkICovDQorICAg IGxpbmstPnN0YXRlIHw9IERFVl9DT05GSUc7DQorDQorICAgIC8qDQorICAg ICAgSW4gdGhpcyBsb29wLCB3ZSBzY2FuIHRoZSBDSVMgZm9yIGNvbmZpZ3Vy YXRpb24gdGFibGUgZW50cmllcywNCisgICAgICBlYWNoIG9mIHdoaWNoIGRl c2NyaWJlcyBhIHZhbGlkIGNhcmQgY29uZmlndXJhdGlvbiwgaW5jbHVkaW5n DQorICAgICAgdm9sdGFnZSwgSU8gd2luZG93LCBtZW1vcnkgd2luZG93IGFu ZCBpbnRlcnJ1cHQgc2V0dGluZ3MuDQorDQorICAgICAgV2UgbWFrZSBubyBh c3N1bXB0aW9ucyBhYm91dCB0aGUgY2FyZCB0byBiZSBjb25maWd1cmVkOiB3 ZSB1c2UNCisgICAgICBqdXN0IHRoZSBpbmZvcm1hdGlvbiBhdmFpbGFibGUg aW4gdGhlIENJUy4gVGhpcyBzaG91bGQgd29yayBmb3INCisgICAgICBhbnkg UG9sZGh1IGNhcmQsIHNpbmNlIHRoYXQgaGFzIGFuIGFjY3VyYXRlIENJUy4N CisgICAgKi8NCisgICAgdHVwbGUuRGVzaXJlZFR1cGxlID0gQ0lTVFBMX0NG VEFCTEVfRU5UUlk7DQorICAgIENTX0NIRUNLKEdldEZpcnN0VHVwbGUsIGhh bmRsZSwgJnR1cGxlKTsNCisgICAgd2hpbGUgKDEpIHsNCisgICAgICAgIGNp c3RwbF9jZnRhYmxlX2VudHJ5X3QgZGZsdCA9IHsgMCB9Ow0KKyAgICAgICAg Y2lzdHBsX2NmdGFibGVfZW50cnlfdCAqY2ZnID0gJihwYXJzZS5jZnRhYmxl X2VudHJ5KTsNCisgICAgICAgIENGR19DSEVDSyhHZXRUdXBsZURhdGEsIGhh bmRsZSwgJnR1cGxlKTsNCisgICAgICAgIENGR19DSEVDSyhQYXJzZVR1cGxl LCBoYW5kbGUsICZ0dXBsZSwgJnBhcnNlKTsNCisNCisgICAgICAgIGlmIChj ZmctPmZsYWdzICYgQ0lTVFBMX0NGVEFCTEVfREVGQVVMVCkgZGZsdCA9ICpj Zmc7DQorICAgICAgICBpZiAoY2ZnLT5pbmRleCA9PSAwKSBnb3RvIG5leHRf ZW50cnk7DQorICAgICAgICBsaW5rLT5jb25mLkNvbmZpZ0luZGV4ID0gY2Zn LT5pbmRleDsNCisNCisgICAgICAgIC8qIERvZXMgdGhpcyBjYXJkIG5lZWQg YXVkaW8gb3V0cHV0PyAqLw0KKyAgICAgICAgaWYgKGNmZy0+ZmxhZ3MgJiBD SVNUUExfQ0ZUQUJMRV9BVURJTykgew0KKyAgICAgICAgICAgIGxpbmstPmNv bmYuQXR0cmlidXRlcyB8PSBDT05GX0VOQUJMRV9TUEtSOw0KKyAgICAgICAg ICAgIGxpbmstPmNvbmYuU3RhdHVzID0gQ0NTUl9BVURJT19FTkE7DQorICAg ICAgICB9DQorDQorICAgICAgICAvKiBVc2UgcG93ZXIgc2V0dGluZ3MgZm9y IFZjYyBhbmQgVnBwIGlmIHByZXNlbnQgKi8NCisgICAgICAgIC8qICBOb3Rl IHRoYXQgdGhlIENJUyB2YWx1ZXMgbmVlZCB0byBiZSByZXNjYWxlZCAqLw0K KyAgICAgICAgaWYgKGNmZy0+dmNjLnByZXNlbnQgJiAoMTw8Q0lTVFBMX1BP V0VSX1ZOT00pKQ0KKyAgICAgICAgICAgIGxpbmstPmNvbmYuVmNjID0gY2Zn LT52Y2MucGFyYW1bQ0lTVFBMX1BPV0VSX1ZOT01dLzEwMDAwOw0KKyAgICAg ICAgZWxzZSBpZiAoZGZsdC52Y2MucHJlc2VudCAmICgxPDxDSVNUUExfUE9X RVJfVk5PTSkpDQorICAgICAgICAgICAgbGluay0+Y29uZi5WY2MgPSBkZmx0 LnZjYy5wYXJhbVtDSVNUUExfUE9XRVJfVk5PTV0vMTAwMDA7DQorDQorICAg ICAgICBpZiAoY2ZnLT52cHAxLnByZXNlbnQgJiAoMTw8Q0lTVFBMX1BPV0VS X1ZOT00pKQ0KKyAgICAgICAgICAgIGxpbmstPmNvbmYuVnBwMSA9IGxpbmst PmNvbmYuVnBwMiA9DQorICAgICAgICAgICAgICAgIGNmZy0+dnBwMS5wYXJh bVtDSVNUUExfUE9XRVJfVk5PTV0vMTAwMDA7DQorICAgICAgICBlbHNlIGlm IChkZmx0LnZwcDEucHJlc2VudCAmICgxPDxDSVNUUExfUE9XRVJfVk5PTSkp DQorICAgICAgICAgICAgbGluay0+Y29uZi5WcHAxID0gbGluay0+Y29uZi5W cHAyID0NCisgICAgICAgICAgICAgICAgZGZsdC52cHAxLnBhcmFtW0NJU1RQ TF9QT1dFUl9WTk9NXS8xMDAwMDsNCisNCisgICAgICAgIC8qIERvIHdlIG5l ZWQgdG8gYWxsb2NhdGUgYW4gaW50ZXJydXB0PyAqLw0KKyAgICAgICAgaWYg KGNmZy0+aXJxLklSUUluZm8xIHx8IGRmbHQuaXJxLklSUUluZm8xKQ0KKyAg ICAgICAgICAgIGxpbmstPmNvbmYuQXR0cmlidXRlcyB8PSBDT05GX0VOQUJM RV9JUlE7DQorDQorICAgICAgICAvKiBJTyB3aW5kb3cgc2V0dGluZ3MgKi8N CisgICAgICAgIGxpbmstPmlvLk51bVBvcnRzMSA9IGxpbmstPmlvLk51bVBv cnRzMiA9IDA7DQorICAgICAgICBpZiAoKGNmZy0+aW8ubndpbiA+IDApIHx8 IChkZmx0LmlvLm53aW4gPiAwKSkgew0KKyAgICAgICAgICAgIGNpc3RwbF9p b190ICppbyA9IChjZmctPmlvLm53aW4pID8gJmNmZy0+aW8gOiAmZGZsdC5p bzsNCisgICAgICAgICAgICBsaW5rLT5pby5BdHRyaWJ1dGVzMSA9IElPX0RB VEFfUEFUSF9XSURUSF9BVVRPOw0KKyAgICAgICAgICAgIGlmICghKGlvLT5m bGFncyAmIENJU1RQTF9JT184QklUKSkNCisgICAgICAgICAgICAgICAgbGlu ay0+aW8uQXR0cmlidXRlczEgPSBJT19EQVRBX1BBVEhfV0lEVEhfMTY7DQor ICAgICAgICAgICAgaWYgKCEoaW8tPmZsYWdzICYgQ0lTVFBMX0lPXzE2QklU KSkNCisgICAgICAgICAgICAgICAgbGluay0+aW8uQXR0cmlidXRlczEgPSBJ T19EQVRBX1BBVEhfV0lEVEhfODsNCisgICAgICAgICAgICBsaW5rLT5pby5C YXNlUG9ydDEgPSBpby0+d2luWzBdLmJhc2U7DQorICAgICAgICAgICAgbGlu ay0+aW8uTnVtUG9ydHMxID0gaW8tPndpblswXS5sZW47DQorICAgICAgICAg ICAgaWYgKGlvLT5ud2luID4gMSkgew0KKyAgICAgICAgICAgICAgICBsaW5r LT5pby5BdHRyaWJ1dGVzMiA9IGxpbmstPmlvLkF0dHJpYnV0ZXMxOw0KKyAg ICAgICAgICAgICAgICBsaW5rLT5pby5CYXNlUG9ydDIgPSBpby0+d2luWzFd LmJhc2U7DQorICAgICAgICAgICAgICAgIGxpbmstPmlvLk51bVBvcnRzMiA9 IGlvLT53aW5bMV0ubGVuOw0KKyAgICAgICAgICAgIH0NCisgICAgICAgIH0N CisNCisgICAgICAgIC8qIFRoaXMgcmVzZXJ2ZXMgSU8gc3BhY2UgYnV0IGRv ZXNuJ3QgYWN0dWFsbHkgZW5hYmxlIGl0ICovDQorICAgICAgICBDRkdfQ0hF Q0soUmVxdWVzdElPLCBsaW5rLT5oYW5kbGUsICZsaW5rLT5pbyk7DQorDQor ICAgICAgICAvKg0KKyAgICAgICAgICBOb3cgc2V0IHVwIGEgY29tbW9uIG1l bW9yeSB3aW5kb3csIGlmIG5lZWRlZC4gVGhlcmUgaXMgcm9vbQ0KKyAgICAg ICAgICBpbiB0aGUgZGV2X2xpbmtfdCBzdHJ1Y3R1cmUgZm9yIG9uZSBtZW1v cnkgd2luZG93IGhhbmRsZSwNCisgICAgICAgICAgYnV0IGlmIHRoZSBiYXNl IGFkZHJlc3NlcyBuZWVkIHRvIGJlIHNhdmVkLCBvciBpZiBtdWx0aXBsZQ0K KyAgICAgICAgICB3aW5kb3dzIGFyZSBuZWVkZWQsIHRoZSBpbmZvIHNob3Vs ZCBnbyBpbiB0aGUgcHJpdmF0ZSBkYXRhDQorICAgICAgICAgIHN0cnVjdHVy ZSBmb3IgdGhpcyBkZXZpY2UuDQorDQorICAgICAgICAgIE5vdGUgdGhhdCB0 aGUgbWVtb3J5IHdpbmRvdyBiYXNlIGlzIGEgcGh5c2ljYWwgYWRkcmVzcywg YW5kDQorICAgICAgICAgIG5lZWRzIHRvIGJlIG1hcHBlZCB0byB2aXJ0dWFs IHNwYWNlIHdpdGggaW9yZW1hcCgpIGJlZm9yZSBpdA0KKyAgICAgICAgICBp cyB1c2VkLg0KKyAgICAgICAgKi8NCisgICAgICAgIGlmICgoY2ZnLT5tZW0u bndpbiA+IDApIHx8IChkZmx0Lm1lbS5ud2luID4gMCkpIHsNCisgICAgICAg ICAgICBjaXN0cGxfbWVtX3QgKm1lbSA9DQorICAgICAgICAgICAgICAgIChj ZmctPm1lbS5ud2luKSA/ICZjZmctPm1lbSA6ICZkZmx0Lm1lbTsNCisgICAg ICAgICAgICByZXEuQXR0cmlidXRlcyA9IFdJTl9EQVRBX1dJRFRIXzE2fFdJ Tl9NRU1PUllfVFlQRV9DTTsNCisgICAgICAgICAgICByZXEuQmFzZSA9IG1l bS0+d2luWzBdLmhvc3RfYWRkcjsNCisgICAgICAgICAgICByZXEuU2l6ZSA9 IG1lbS0+d2luWzBdLmxlbjsNCisgICAgICAgICAgICByZXEuQWNjZXNzU3Bl ZWQgPSAwOw0KKyAgICAgICAgICAgIGxpbmstPndpbiA9ICh3aW5kb3dfaGFu ZGxlX3QpbGluay0+aGFuZGxlOw0KKyAgICAgICAgICAgIENGR19DSEVDSyhS ZXF1ZXN0V2luZG93LCAmbGluay0+d2luLCAmcmVxKTsNCisgICAgICAgICAg ICBtYXAuUGFnZSA9IDA7IG1hcC5DYXJkT2Zmc2V0ID0gbWVtLT53aW5bMF0u Y2FyZF9hZGRyOw0KKyAgICAgICAgICAgIENGR19DSEVDSyhNYXBNZW1QYWdl LCBsaW5rLT53aW4sICZtYXApOw0KKyAgICAgICAgfQ0KKyAgICAgICAgLyog SWYgd2UgZ290IHRoaXMgZmFyLCB3ZSdyZSBjb29sISAqLw0KKyAgICAgICAg YnJlYWs7DQorDQorICAgIG5leHRfZW50cnk6DQorICAgICAgICBDU19DSEVD SyhHZXROZXh0VHVwbGUsIGhhbmRsZSwgJnR1cGxlKTsNCisgICAgfQ0KKw0K KyAgICAvKiBBbGxvY2F0ZSBhbiBpbnRlcnJ1cHQgbGluZS4gKi8NCisgICAg aWYgKGxpbmstPmNvbmYuQXR0cmlidXRlcyAmIENPTkZfRU5BQkxFX0lSUSkN CisgICAgICAgIENTX0NIRUNLKFJlcXVlc3RJUlEsIGxpbmstPmhhbmRsZSwg JmxpbmstPmlycSk7DQorDQorICAgIC8qDQorICAgICAgVGhpcyBhY3R1YWxs eSBjb25maWd1cmVzIHRoZSBQQ01DSUEgc29ja2V0IC0tIHNldHRpbmcgdXAN CisgICAgICB0aGUgSS9PIHdpbmRvd3MgYW5kIHRoZSBpbnRlcnJ1cHQgbWFw cGluZywgYW5kIHB1dHRpbmcgdGhlDQorICAgICAgY2FyZCBhbmQgaG9zdCBp bnRlcmZhY2UgaW50byAiTWVtb3J5IGFuZCBJTyIgbW9kZS4NCisgICAgKi8N CisgICAgQ1NfQ0hFQ0soUmVxdWVzdENvbmZpZ3VyYXRpb24sIGxpbmstPmhh bmRsZSwgJmxpbmstPmNvbmYpOw0KKw0KKyAgICAvKiBSZXBvcnQgd2hhdCB3 ZSd2ZSBkb25lIHNvIGZhciAqLw0KKyAgICBwcmludGsoS0VSTl9JTkZPICJw b2xkaHVfY3M6IGluZGV4IDB4JTAyeDogVmNjICVkLiVkIiwNCisgICAgICAg ICAgIGxpbmstPmNvbmYuQ29uZmlnSW5kZXgsDQorICAgICAgICAgICBsaW5r LT5jb25mLlZjYy8xMCwgbGluay0+Y29uZi5WY2MlMTApOw0KKyAgICBpZiAo bGluay0+Y29uZi5WcHAxKQ0KKyAgICAgICAgcHJpbnRrKCIsIFZwcCAlZC4l ZCIsIGxpbmstPmNvbmYuVnBwMS8xMCwgbGluay0+Y29uZi5WcHAxJTEwKTsN CisgICAgaWYgKGxpbmstPmNvbmYuQXR0cmlidXRlcyAmIENPTkZfRU5BQkxF X0lSUSkNCisgICAgICAgIHByaW50aygiLCBpcnEgJWQiLCBsaW5rLT5pcnEu QXNzaWduZWRJUlEpOw0KKyAgICBpZiAobGluay0+aW8uTnVtUG9ydHMxKQ0K KyAgICAgICAgcHJpbnRrKCIgaW8gMHglMDR4LTB4JTA0eCIsIGxpbmstPmlv LkJhc2VQb3J0MSwNCisgICAgICAgICAgICAgICBsaW5rLT5pby5CYXNlUG9y dDEgKyBsaW5rLT5pby5OdW1Qb3J0czEgLSAxKTsNCisgICAgaWYgKGxpbmst PmlvLk51bVBvcnRzMikNCisgICAgICAgIHByaW50aygiICYgMHglMDR4LTB4 JTA0eCIsIGxpbmstPmlvLkJhc2VQb3J0MiwNCisgICAgICAgICAgICAgICBs aW5rLT5pby5CYXNlUG9ydDIgKyBsaW5rLT5pby5OdW1Qb3J0czIgLSAxKTsN CisgICAgaWYgKGxpbmstPndpbikNCisgICAgICAgIHByaW50aygiLCBtZW0g MHglMDZseC0weCUwNmx4IiwgcmVxLkJhc2UsDQorICAgICAgICAgICAgICAg cmVxLkJhc2UgKyByZXEuU2l6ZSAtIDEpOw0KKyAgICBwcmludGsoIlxuIik7 DQorDQorICAgIGRldi0+aXJxID0gbGluay0+aXJxLkFzc2lnbmVkSVJROw0K KyAgICBkZXYtPmJhc2VfYWRkciA9IGxpbmstPmlvLkJhc2VQb3J0MTsNCisg ICAgaWYgKHJlZ2lzdGVyX25ldGRldihkZXYpICE9IDApIHsNCisgICAgICAg IHByaW50ayhLRVJOX05PVElDRSAicG9sZGh1X2NzOiByZWdpc3Rlcl9uZXRk ZXYoKSBmYWlsZWRcbiIpOw0KKyAgICAgICAgZ290byBmYWlsZWQ7DQorICAg IH0NCisNCisgICAgLyogQ3JlYXRlIHRoZSBkZXZpY2UncyAvcHJvYyBlbnRy eSAqLw0KKyAgICBjcmVhdGVfcHJvY19yZWFkX2VudHJ5KGRldi0+bmFtZSwg DQorICAgICAgICAgICAgICAgICAgICAgICAgICAgU19JRlJFRyB8IFNfSVJV R08gfCBTX0lXVVNSLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHBv bGRodV9wcm9jX2RpciwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICBw b2xkaHVfcHJvY19yZWFkLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICh2b2lkKilkZXYpOw0KKyAgICBscCA9IGRldi0+cHJpdjsNCisNCisgICAg c3RyY3B5KGxwLT5ub2RlLmRldl9uYW1lLCBkZXYtPm5hbWUpOw0KKw0KKyAg ICBpb2FkZHIgPSBkZXYtPmJhc2VfYWRkcjsNCisNCisgICAgLyogU2V0IHRo ZSBSU1QgYml0IGluIENvbW1zOSAqLw0KKyAgICBvdXRiKDB4ODAsIGlvYWRk ciArIDB4MDkpOw0KKyAgICAvKiBXYWl0IGZvciB0aGUgUlNUX0FDSyBiaXQg aW4gQ29tbXM3ICovDQorICAgIHdoaWxlKChpbmIoaW9hZGRyICsgMHgwNykg JiAweDgwKSA9PSAweDAwKQ0KKyAgICAgICAgdWRlbGF5KDEwKTsNCisgICAg LyogUmVzZXQgdGhlIFJTVCBiaXQgaW4gQ29tbXM5ICovDQorICAgIG91dGIo MHgwMCwgaW9hZGRyICsgMHgwOSk7DQorICAgIGxwLT5zZXF1ZW5jZSA9IDA7 DQorICAgIC8qIENoZWNrIGZvciB0aGUgcmlnaHQgdmVyc2lvbiAqLw0KKyAg ICBpZiAoaW5iKGlvYWRkciArIDB4MDYpICE9IDB4YTApDQorICAgICAgICBw cmludGsoInBvbGRodV9jczogV3JvbmcgdmVyc2lvbiFcbiIpOw0KKyAgICAv KiBSZWFkIHRoZSBNQUMgYWRkcmVzcyAqLw0KKyAgICBmb3IgKGkgPSAwOyBp IDwgRVRIX0FMRU47IGkrKykNCisgICAgICAgIGRldi0+ZGV2X2FkZHJbaV0g PSBpbmIoaW9hZGRyICsgaSk7DQorICAgIC8qIEVuYWJsZSBpbnRlcnJ1cHRz ICovDQorICAgIG91dGIoMHg4MCwgaW9hZGRyICsgMHgwOCk7ICAgIA0KKw0K KyAgICBsaW5rLT5kZXYgPSAmKChzdHJ1Y3QgcG9sZGh1X3ByaXZhdGUgKilk ZXYtPnByaXYpLT5ub2RlOw0KKw0KKyAgICBwcmludGsoS0VSTl9JTkZPICIl czogTldOIFBvbGRodSwgcG9ydCAlMDNsWCwgaXJxICVkLCBod19hZGRyICIs IGRldi0+bmFtZSwNCisgICAgICAgICAgIGRldi0+YmFzZV9hZGRyLCBkZXYt PmlycSk7DQorICAgIGZvciAoaSA9IDA7IGkgPCA2OyBpKyspDQorICAgICAg ICBwcmludGsoIiUwMlglcyIsIGRldi0+ZGV2X2FkZHJbaV0sICgoaTw1KSA/ ICI6IiA6ICJcbiIpKTsNCisNCisgICAgZm9yIChpID0gMDsgaSA8IE1BWF9Q T0xESFVTOyBpKyspIA0KKyAgICAgICAgaWYgKHBvbGRodXNbaV0gPT0gTlVM TCkgDQorICAgICAgICB7DQorICAgICAgICAgICAgcG9sZGh1c1tpXSA9IGRl djsNCisgICAgICAgICAgICBicmVhazsNCisgICAgICAgIH0NCisNCisgICAg bHAtPmVuYy5lbmFibGUgPSBlbmNyeXB0Ow0KKyAgICBtZW1jcHkobHAtPmVu Yy5rZXlzLCBrZXlzLCBTTldOTVBfTUFYX0tFWV9TSVpFKTsNCisgICAgbHAt PmVuYy5pbmRleCA9IGtleWlkOw0KKyAgICBscC0+ZW5jLnJlc3RyaWN0ZWQg PSByZXN0cmljdGVkOw0KKyAgICBscC0+ZW5jLmFpcmxvY2sgPSBhaXJsb2Nr Ow0KKyAgICBzdHJjcHkobHAtPndhbnRlZF9lc3NpZCwgc3NpZCk7DQorICAg IHByaW50ayhLRVJOX0lORk8gIiVzOiBTU0lEKCVzKVxuIiwgZGV2LT5uYW1l LCBscC0+d2FudGVkX2Vzc2lkKTsNCisNCisgICAgbmV0aWZfc3RhcnRfcXVl dWUoZGV2KTsNCisNCisgICAgbGluay0+c3RhdGUgJj0gfkRFVl9DT05GSUdf UEVORElORzsNCisgICAgcmV0dXJuOw0KKw0KK2NzX2ZhaWxlZDoNCisgICAg Y3NfZXJyb3IobGluay0+aGFuZGxlLCBsYXN0X2ZuLCBsYXN0X3JldCk7DQor ZmFpbGVkOg0KKyAgICBwb2xkaHVfcGNtY2lhX3JlbGVhc2UoKHVfbG9uZyls aW5rKTsNCisgICAgcmV0dXJuOw0KK30NCisNCisvKj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KKw0KKyAgICBBZnRlciBhIGNhcmQgaXMgcmVtb3Zl ZCwgcG9sZGh1X3JlbGVhc2UoKSB3aWxsIHVucmVnaXN0ZXIgdGhlIG5ldA0K KyAgICBkZXZpY2UsIGFuZCByZWxlYXNlIHRoZSBQQ01DSUEgY29uZmlndXJh dGlvbi4gSWYgdGhlIGRldmljZSBpcw0KKyAgICBzdGlsbCBvcGVuLCB0aGlz IHdpbGwgYmUgcG9zdHBvbmVkIHVudGlsIGl0IGlzIGNsb3NlZC4NCisNCis9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0qLw0KKw0KK3N0YXRpYyB2b2lk IHBvbGRodV9wY21jaWFfcmVsZWFzZSh1X2xvbmcgYXJnKQ0KK3sNCisgICAg ZGV2X2xpbmtfdCAqbGluayA9IChkZXZfbGlua190ICopYXJnOw0KKw0KKyAg ICBERUJVRyg3LCAicG9sZGh1X3BjbWNpYV9yZWxlYXNlKDB4JXApXG4iLCBs aW5rKTsNCisNCisgICAgaWYgKGxpbmstPm9wZW4pIHsNCisgICAgICAgIERF QlVHKDEsICJwb2xkaHVfY3M6IHJlbGVhc2UgcG9zdHBvbmVkLCAnJXMnIHN0 aWxsIG9wZW5cbiIsDQorICAgICAgICAgICAgICBsaW5rLT5kZXYtPmRldl9u YW1lKTsNCisgICAgICAgIGxpbmstPnN0YXRlIHw9IERFVl9TVEFMRV9DT05G SUc7DQorICAgICAgICByZXR1cm47DQorICAgIH0NCisNCisgICAgLyogUmVt b3ZlIHByb2MgZmlsZSAqLw0KKyAgICByZW1vdmVfcHJvY19lbnRyeShsaW5r LT5kZXYtPmRldl9uYW1lLCBwb2xkaHVfcHJvY19kaXIpOw0KKw0KKyAgICBD YXJkU2VydmljZXMoUmVsZWFzZUNvbmZpZ3VyYXRpb24sIGxpbmstPmhhbmRs ZSk7DQorICAgIENhcmRTZXJ2aWNlcyhSZWxlYXNlSU8sIGxpbmstPmhhbmRs ZSwgJmxpbmstPmlvKTsNCisgICAgQ2FyZFNlcnZpY2VzKFJlbGVhc2VJUlEs IGxpbmstPmhhbmRsZSwgJmxpbmstPmlycSk7DQorDQorICAgIGxpbmstPnN0 YXRlICY9IH4oREVWX0NPTkZJRyB8IERFVl9SRUxFQVNFX1BFTkRJTkcpOw0K K30NCisNCisvKj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KKw0KKyAg ICBUaGUgY2FyZCBzdGF0dXMgZXZlbnQgaGFuZGxlci4gTW9zdGx5LCB0aGlz IHNjaGVkdWxlcyBvdGhlcg0KKyAgICBzdHVmZiB0byBydW4gYWZ0ZXIgYW4g ZXZlbnQgaXMgcmVjZWl2ZWQuIEEgQ0FSRF9SRU1PVkFMIGV2ZW50DQorICAg IGFsc28gc2V0cyBzb21lIGZsYWdzIHRvIGRpc2NvdXJhZ2UgdGhlIG5ldCBk cml2ZXJzIGZyb20gdHJ5aW5nDQorICAgIHRvIHRhbGsgdG8gdGhlIGNhcmQg YW55IG1vcmUuDQorDQorPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ki8N CisNCitzdGF0aWMgaW50IHBvbGRodV9wY21jaWFfZXZlbnQoZXZlbnRfdCBl dmVudCwgaW50IHByaW9yaXR5LA0KKyAgICAgICAgICAgICAgICAgICAgICAg ICBldmVudF9jYWxsYmFja19hcmdzX3QgKmFyZ3MpDQorew0KKyAgICBkZXZf bGlua190ICpsaW5rID0gYXJncy0+Y2xpZW50X2RhdGE7DQorICAgIHN0cnVj dCBuZXRfZGV2aWNlICpkZXYgPSBsaW5rLT5wcml2Ow0KKw0KKyAgICBERUJV Ryg3LCAicG9sZGh1X3BjbWNpYV9ldmVudCgweCUwNngpXG4iLCBldmVudCk7 DQorDQorICAgIHN3aXRjaCAoZXZlbnQpIHsNCisgICAgY2FzZSBDU19FVkVO VF9DQVJEX1JFTU9WQUw6DQorICAgICAgICBsaW5rLT5zdGF0ZSAmPSB+REVW X1BSRVNFTlQ7DQorICAgICAgICBpZiAobGluay0+c3RhdGUgJiBERVZfQ09O RklHKSB7DQorICAgICAgICAgICAgbmV0aWZfc3RvcF9xdWV1ZShkZXYpOw0K KyAgICAgICAgICAgIGxpbmstPnJlbGVhc2UuZXhwaXJlcyA9IGppZmZpZXMg KyAoSFovMjApOw0KKyAgICAgICAgICAgIGFkZF90aW1lcigmbGluay0+cmVs ZWFzZSk7DQorICAgICAgICB9DQorICAgICAgICBicmVhazsNCisgICAgY2Fz ZSBDU19FVkVOVF9DQVJEX0lOU0VSVElPTjoNCisgICAgICAgIGxpbmstPnN0 YXRlIHw9IERFVl9QUkVTRU5UIHwgREVWX0NPTkZJR19QRU5ESU5HOw0KKyAg ICAgICAgcG9sZGh1X3BjbWNpYV9jb25maWcobGluayk7DQorICAgICAgICBi cmVhazsNCisgICAgY2FzZSBDU19FVkVOVF9QTV9TVVNQRU5EOg0KKyAgICAg ICAgbGluay0+c3RhdGUgfD0gREVWX1NVU1BFTkQ7DQorICAgICAgICAvKiBG YWxsIHRocm91Z2ggKi8NCisgICAgY2FzZSBDU19FVkVOVF9SRVNFVF9QSFlT SUNBTDoNCisgICAgICAgIGlmIChsaW5rLT5zdGF0ZSAmIERFVl9DT05GSUcp IHsNCisgICAgICAgICAgICBpZiAobGluay0+b3Blbikgew0KKyAgICAgICAg ICAgICAgICBuZXRpZl9zdG9wX3F1ZXVlKGRldik7DQorICAgICAgICAgICAg fQ0KKyAgICAgICAgICAgIENhcmRTZXJ2aWNlcyhSZWxlYXNlQ29uZmlndXJh dGlvbiwgbGluay0+aGFuZGxlKTsNCisgICAgICAgIH0NCisgICAgICAgIGJy ZWFrOw0KKyAgICBjYXNlIENTX0VWRU5UX1BNX1JFU1VNRToNCisgICAgICAg IGxpbmstPnN0YXRlICY9IH5ERVZfU1VTUEVORDsNCisgICAgICAgIC8qIEZh bGwgdGhyb3VnaCAqLw0KKyAgICBjYXNlIENTX0VWRU5UX0NBUkRfUkVTRVQ6 DQorICAgICAgICBpZiAobGluay0+c3RhdGUgJiBERVZfQ09ORklHKSB7DQor ICAgICAgICAgICAgQ2FyZFNlcnZpY2VzKFJlcXVlc3RDb25maWd1cmF0aW9u LCBsaW5rLT5oYW5kbGUsICZsaW5rLT5jb25mKTsNCisgICAgICAgICAgICBp ZiAobGluay0+b3Blbikgew0KKyAgICAgICAgICAgICAgICBwb2xkaHVfaHdf cmVzZXQoZGV2KTsNCisgICAgICAgICAgICAgICAgbmV0aWZfc3RhcnRfcXVl dWUoZGV2KTsNCisgICAgICAgICAgICB9DQorICAgICAgICB9DQorICAgICAg ICBicmVhazsNCisgICAgfQ0KKyAgICByZXR1cm4gMDsNCit9DQorDQorLyo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCisNCisgIFNldCB0aGUgUG9s ZGh1IGludG8gYSBrbm93biBzdGF0ZS4NCisNCis9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0qLw0KKw0KK3N0YXRpYyB2b2lkIHBvbGRodV9od19yZXNl dChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2KQ0KK3sNCisgICAgdXNob3J0IGlv YWRkciA9IGRldi0+YmFzZV9hZGRyOw0KKyAgICBzdHJ1Y3QgcG9sZGh1X3By aXZhdGUgKmxwID0gKHN0cnVjdCBwb2xkaHVfcHJpdmF0ZSAqKWRldi0+cHJp djsNCisNCisgICAgLyogU2V0IHRoZSBSU1QgYml0IGluIENvbW1zOSAqLw0K KyAgICBvdXRiKDB4ODAsIGlvYWRkciArIDB4MDkpOw0KKyAgICAvKiBXYWl0 IGZvciB0aGUgUlNUX0FDSyBiaXQgaW4gQ29tbXM3ICovDQorICAgIHdoaWxl KChpbmIoaW9hZGRyICsgMHgwNykgJiAweDgwKSA9PSAweDAwKQ0KKyAgICAg ICAgdWRlbGF5KDEwKTsNCisgICAgLyogUmVzZXQgdGhlIFJTVCBiaXQgaW4g Q29tbXM5ICovDQorICAgIG91dGIoaW5iKGlvYWRkciArIDB4MDkpICYgfjB4 ODAsIGlvYWRkciArIDB4MDkpOw0KKyAgICAvKiBSZWFkIENvbW1zNiAqLw0K KyAgICBpbmIoaW9hZGRyICsgMHgwNik7DQorICAgIGxwLT5zZXF1ZW5jZSA9 IDA7DQorfQ0KKw0KK3N0YXRpYyBpbnQgcG9sZGh1X2NvbmZpZyhzdHJ1Y3Qg bmV0X2RldmljZSAqZGV2LCBzdHJ1Y3QgaWZtYXAgKm1hcCkNCit7DQorICAg IC8qIFdlIHJlYWxseSBkb24ndCBjYXJlICovDQorICAgIGRldi0+aWZfcG9y dCA9IG1hcC0+cG9ydDsNCisgICAgcmV0dXJuIDA7DQorfQ0KKw0KK3N0YXRp YyBpbnQgcG9sZGh1X29wZW4oc3RydWN0IG5ldF9kZXZpY2UgKmRldikNCit7 DQorICAgIGRldl9saW5rX3QgKmxpbms7DQorDQorICAgIGZvciAobGluayA9 IGRldl9saXN0OyBsaW5rOyBsaW5rID0gbGluay0+bmV4dCkNCisgICAgICAg IGlmIChsaW5rLT5wcml2ID09IGRldikgYnJlYWs7DQorICAgIGlmICghREVW X09LKGxpbmspKQ0KKyAgICAgICAgcmV0dXJuIC1FTk9ERVY7DQorDQorICAg IGxpbmstPm9wZW4rKzsNCisgICAgTU9EX0lOQ19VU0VfQ09VTlQ7DQorDQor ICAgIG5ldGlmX3N0YXJ0X3F1ZXVlKGRldik7DQorDQorICAgIHBvbGRodV9o d19yZXNldChkZXYpOw0KKw0KKyAgICBERUJVRygyLCAiJXM6IG9wZW5lZC5c biIsIGRldi0+bmFtZSk7DQorDQorICAgIHJldHVybiAwOw0KK30NCisNCitz dGF0aWMgdm9pZCBwb2xkaHVfdGltZW91dChzdHJ1Y3QgbmV0X2RldmljZSAq ZGV2KQ0KK3sNCisgICAgcHJpbnRrKEtFUk5fSU5GTyAiJXM6IFRyYW5zbWl0 IHRpbWVvdXRcbiIsIGRldi0+bmFtZSk7DQorDQorICAgIHBvbGRodV9od19y ZXNldChkZXYpOw0KK30NCisNCitzdGF0aWMgaW50IHBvbGRodV9zdGFydF94 bWl0KHN0cnVjdCBza19idWZmICpza2IsIHN0cnVjdCBuZXRfZGV2aWNlICpk ZXYpDQorew0KKyAgICBzdHJ1Y3QgcG9sZGh1X3ByaXZhdGUgKmxwID0gKHN0 cnVjdCBwb2xkaHVfcHJpdmF0ZSAqKWRldi0+cHJpdjsNCisgICAgdW5zaWdu ZWQgbG9uZyB0aW1lb3V0Ow0KKyAgICBpbnQgcmV0dmFsID0gMDsNCisgICAg aW50IGlvYWRkciA9IGRldi0+YmFzZV9hZGRyOw0KKyAgICBpbnQgYnl0ZXNf d3JpdHRlbiA9IDA7DQorICAgIGludCBwa3RfbGVuID0gMDsNCisgICAgdW5z aWduZWQgY2hhciAqcGt0X2RhdGE7DQorICAgIGludCBpOw0KKw0KKyAgICBE RUJVRyg3LCAicG9sZGh1X3N0YXJ0X3htaXQoJXAsJXApXG4iLCBza2IsIGRl dik7DQorICAgIA0KKyAgICBuZXRpZl9zdG9wX3F1ZXVlKGRldik7DQorDQor ICAgIGlmIChza2IgPT0gTlVMTCkgew0KKyAgICAgICAgREVCVUcoMCwgInBv bGRodV9zdGFydF94bWl0OiBza2IgPSBOVUxMXG4iKTsNCisgICAgICAgIHJl dHVybiAwOw0KKyAgICB9IGVsc2Ugew0KKyAgICAgICAgcGt0X2xlbiA9IHNr Yi0+bGVuOw0KKyAgICAgICAgcGt0X2RhdGEgPSBza2ItPmRhdGE7DQorICAg IH0NCisNCisgICAgLyogU2F2ZSB0aGUgdGltZXN0YW1wIHdoZW4gd2UgcmVj ZWl2ZWQgdGhlIHBhY2tldCAqLw0KKyAgICBkZXYtPnRyYW5zX3N0YXJ0ID0g amlmZmllczsNCisNCisgICAgLyogU2V0IFVSRyBiaXQgaWYgc2VuZGluZyBT TldOTVAgcGFja2V0cyAqLw0KKyAgICBpZiAoKChzdHJ1Y3QgZXRoaGRyKilw a3RfZGF0YSktPmhfcHJvdG8gPT0gX19jb25zdGFudF9odG9ucyhFVEhfUF9T TldOTVApKSB7DQorICAgICAgICBvdXRiKGluYihpb2FkZHIgKyAweDA3KSB8 IDB4NDAsIGlvYWRkciArIDB4MDcpOw0KKyAgICB9DQorDQorICAgIC8qIENo ZWNrIGZvciBDVFMgKi8NCisgICAgdGltZW91dCA9IGppZmZpZXMgKyBUWF9D VFNfVElNRU9VVDsNCisgICAgd2hpbGUgKHRpbWVfYmVmb3JlX2VxKGppZmZp ZXMsIHRpbWVvdXQpKSB7DQorICAgICAgICBpZiAoKGluYihpb2FkZHIgKyAw eDA3KSAmIDB4MTApID09IDB4MTApIGJyZWFrOw0KKyAgICB9DQorDQorICAg IGlmICgoaW5iKGlvYWRkciArIDB4MDcpICYgMHgxMCkgPT0gMHgwMCkgew0K KyAgICAgICAgcHJpbnRrKEtFUk5fSU5GTyAiJXM6IEZhaWxlZCB0byBnZXQg Q1RTISIsIGRldi0+bmFtZSk7DQorICAgICAgICBwcmludGsoIiAoMHglMFgp XG4iLCBpbmIoaW9hZGRyICsgMHgwNykpOw0KKyAgICAgICAgbHAtPnN0YXRz LnR4X2Vycm9ycysrOw0KKyAgICAgICAgcmV0dmFsID0gMTsNCisgICAgICAg IGdvdG8gcG9sZGh1X3htaXRfZG9uZTsNCisgICAgfQ0KKw0KKyAgICAvKiBJ bml0aWF0ZSBzZW5kIHNlcXVlbmNlICovDQorICAgIG91dGIoKHBrdF9sZW4g Pj4gMCkgJiAweGZmLCBpb2FkZHIgKyAweDBhKTsNCisgICAgb3V0YigocGt0 X2xlbiA+PiA4KSAmIDB4ZmYsIGlvYWRkciArIDB4MGEpOw0KKyAgICBvdXRi KDB4YTUsIGlvYWRkciArIDB4MGEpOw0KKyAgICBvdXRiKDB4MDMsIGlvYWRk ciArIDB4MGEpOw0KKw0KKyAgICAvKiBXYWl0IGZvciBDVFMgdG8gY2xlYXIg Ki8NCisgICAgdGltZW91dCA9IGppZmZpZXMgKyBUWF9DVFNfVElNRU9VVDsN CisgICAgd2hpbGUgKHRpbWVfYmVmb3JlX2VxKGppZmZpZXMsIHRpbWVvdXQp KSB7DQorICAgICAgICBpZiAoKGluYihpb2FkZHIgKyAweDA3KSAmIDB4MTAp ID09IDB4MDApIGJyZWFrOw0KKyAgICB9DQorICAgIGlmICgoaW5iKGlvYWRk ciArIDB4MDcpICYgMHgxMCkgPT0gMHgxMCkgew0KKyAgICAgICAgcHJpbnRr KEtFUk5fSU5GTyAiJXM6IEZhaWxlZCB0byByZXNldCBDVFMhIiwgZGV2LT5u YW1lKTsNCisgICAgICAgIHByaW50aygiICgweCUwWClcbiIsIGluYihpb2Fk ZHIgKyAweDA3KSk7DQorICAgICAgICBscC0+c3RhdHMudHhfZXJyb3JzKys7 DQorICAgICAgICByZXR2YWwgPSAxOw0KKyAgICAgICAgZ290byBwb2xkaHVf eG1pdF9kb25lOw0KKyAgICB9DQorICAgIA0KKyAgICBERUJVRygyLCAicG9s ZGh1X3N0YXJ0X3htaXQ6IHNlbmRpbmcgJWQgYnl0ZXNcbiIsIHNrYi0+bGVu KTsNCisNCisgICAgZm9yIChpID0gMDsgaSA8IHBrdF9sZW47IGkrKykNCisg ICAgICAgIG91dGIocGt0X2RhdGFbaV0sIGlvYWRkciArIDB4MGEpOw0KKw0K KyAgICAvKiBSZXNldCBVUkcgYml0IGlmIHNlbmRpbmcgU05XTk1QIHBhY2tl dHMgKi8NCisgICAgaWYgKCgoc3RydWN0IGV0aGhkciopcGt0X2RhdGEpLT5o X3Byb3RvID09IF9fY29uc3RhbnRfaHRvbnMoRVRIX1BfU05XTk1QKSkgew0K KyAgICAgICAgb3V0YihpbmIoaW9hZGRyICsgMHgwNykgJiB+MHg0MCwgaW9h ZGRyICsgMHgwNyk7DQorICAgIH0NCisNCisgICAgbHAtPnN0YXRzLnR4X3Bh Y2tldHMrKzsNCisgICAgbHAtPnN0YXRzLnR4X2J5dGVzICs9IGJ5dGVzX3dy aXR0ZW47DQorDQorICAgIERFQlVHKDYsICJwb2xkaHVfc3RhcnRfeG1pdDog U2VudCAlZCBieXRlc1xuIiwgYnl0ZXNfd3JpdHRlbik7DQorDQorICAgIGlm IChza2IpIGRldl9rZnJlZV9za2Ioc2tiKTsNCisNCitwb2xkaHVfeG1pdF9k b25lOg0KKyAgICBuZXRpZl9zdGFydF9xdWV1ZShkZXYpOw0KKyAgICANCisg ICAgcmV0dXJuIHJldHZhbDsNCit9DQorDQorc3RhdGljIGludCBwb2xkaHVf cngoc3RydWN0IG5ldF9kZXZpY2UgKmRldikNCit7DQorICAgIHN0cnVjdCBw b2xkaHVfcHJpdmF0ZSAqbHAgPSAoc3RydWN0IHBvbGRodV9wcml2YXRlICop ZGV2LT5wcml2Ow0KKyAgICB1bnNpZ25lZCBpb2FkZHIgPSBkZXYtPmJhc2Vf YWRkcjsNCisgICAgc3RydWN0IHNrX2J1ZmYgKnNrYjsNCisgICAgdW5zaWdu ZWQgY2hhciAqZnJhbWU7DQorICAgIHVuc2lnbmVkIGxvbmcgc3RhcnRfdHJh bnM7DQorICAgIHVuc2lnbmVkIHBrdF9sZW4sIGJ5dGVzX3JlYWQ7DQorICAg IHVuc2lnbmVkIHZlcnNpb247DQorDQorI2lmZGVmIENPTkZJR19QQ01DSUFf UE9MREhVX0RFQlVHDQorICAgIHVuc2lnbmVkIGk7DQorI2VuZGlmDQorICAg IERFQlVHKDcsICJwb2xkaHVfcngoJXApXG4iLCBkZXYpOw0KKyAgICAvKiBS ZWFkIHRoZSBwYWNrZXQgbGVuZ3RoICovDQorICAgIHBrdF9sZW4gPSBpbmIo aW9hZGRyICsgMHgwYSk7DQorICAgIHBrdF9sZW4gfD0gKGluYihpb2FkZHIg KyAweDBhKSA8PCA4KTsNCisgICAgLyogQ2hlY2sgdGhlIG1hZ2ljIG51bWJl ciAqLw0KKyAgICB2ZXJzaW9uID0gaW5iKGlvYWRkciArIDB4MGEpOw0KKyAg ICB2ZXJzaW9uIHw9IChpbmIoaW9hZGRyICsgMHgwYSkgPDwgOCk7DQorICAg IGlmICh2ZXJzaW9uICE9IDB4YTUwMykNCisgICAgICAgIHByaW50ayhLRVJO X0lORk8gInBvbGRodV9jczogVmVyc2lvbiBtaXNtYXRjaCAoJTBYKVxuIiwg dmVyc2lvbik7DQorDQorICAgIGZyYW1lID0gKHVuc2lnbmVkIGNoYXIgKilr bWFsbG9jKHBrdF9sZW4sIEdGUF9BVE9NSUMpOw0KKyAgICBpZiAoZnJhbWUg PT0gTlVMTCkgew0KKyAgICAgICAgcHJpbnRrKEtFUk5fSU5GTyAicG9sZGh1 X3J4OiBMb3cgb24gbWVtb3J5LlxuIik7DQorICAgICAgICByZXR1cm4gLUVO T01FTTsNCisgICAgfQ0KKw0KKyAgICBieXRlc19yZWFkID0gMDsNCisgICAg c3RhcnRfdHJhbnMgPSBqaWZmaWVzOw0KKyAgICB3aGlsZSAoYnl0ZXNfcmVh ZCA8IHBrdF9sZW4pIHsNCisgICAgICAgIGZyYW1lW2J5dGVzX3JlYWQrK10g PSAodW5zaWduZWQgY2hhcilpbmIoaW9hZGRyICsgMHgwYSk7DQorICAgIH0N CisNCisgICAgLyogVGhpcyBpcyBhbiBTTldOTVAgcGFja2V0LiBXZSBwcm9j ZXNzIGl0IG91cnNlbHZlcywgYW5kDQorICAgICAqIHRoZW4gc2VuZCBpdCBk b3duIHRvIHRoZSBuZXR3b3JrIGxheWVyIHRvIGJlIGRpc2NhcmRlZC4NCisg ICAgICovDQorICAgIGlmICgoKHN0cnVjdCBldGhoZHIqKWZyYW1lKS0+aF9w cm90byA9PSBfX2NvbnN0YW50X2h0b25zKEVUSF9QX1NOV05NUCkpIA0KKyAg ICB7DQorICAgICAgICBzbndubXBfcHJvY2VzcyhkZXYsIGZyYW1lLCBwa3Rf bGVuKTsgDQorICAgIH0NCisNCisgICAgLyogQWxsb2NhdGUgdGhlIHNrYiBi dWZmZXIgKi8NCisgICAgaWYgKChza2IgPSBkZXZfYWxsb2Nfc2tiKHBrdF9s ZW4gKyA1KSkgPT0gTlVMTCkgew0KKyAgICAgICAga2ZyZWUoZnJhbWUpOw0K KyAgICAgICAgcHJpbnRrKEtFUk5fSU5GTyAiJXM6IGNvdWxkbid0IGFsbG9j YXRlIGEgc2tfYnVmZiBvZiINCisgICAgICAgICAgICAgICAiIHNpemUgJWQu XG4iLCBkZXYtPm5hbWUsIHBrdF9sZW4pOw0KKyAgICAgICAgcmV0dXJuIC1F Tk9NRU07DQorICAgIH0NCisgICAgZWxzZSB7DQorICAgICAgICBkZXYtPmxh c3RfcnggPSBqaWZmaWVzOw0KKw0KKyAgICAgICAgc2tiLT5kZXYgPSBkZXY7 DQorICAgICAgICBza2ItPmxlbiA9IHBrdF9sZW47DQorDQorICAgICAgICBz a2JfcmVzZXJ2ZShza2IsIDIpOyAvKiBJUCBoZWFkZXJzIG9uIDE2IGJ5dGUg Ym91bmRhcmllcyAqLw0KKyAgICAgICAgbWVtY3B5KHNrYl9wdXQoc2tiLCBw a3RfbGVuKSwgZnJhbWUsIHBrdF9sZW4pOw0KKyAgICAgICAgc2tiLT5wcm90 b2NvbCA9IGV0aF90eXBlX3RyYW5zKHNrYiwgZGV2KTsNCisNCisgICAgICAg IC8qIEZyZWUgdGhlIGZyYW1lIGJ1ZmZlciAqLw0KKyAgICAgICAga2ZyZWUo ZnJhbWUpOw0KKyAgICB9DQorDQorICAgIGxwLT5zdGF0cy5yeF9wYWNrZXRz Kys7DQorICAgIGxwLT5zdGF0cy5yeF9ieXRlcyArPSBza2ItPmxlbjsNCisN CisgICAgbmV0aWZfcngoc2tiKTsNCisgICAgbmV0aWZfd2FrZV9xdWV1ZShk ZXYpOw0KKw0KKyAgICBERUJVRyg3LCAicG9sZGh1X3J4OiByZWNlaXZlZCAl ZCBvdXQgb2YgJWQgYnl0ZXNcbiIsIGJ5dGVzX3JlYWQsIHBrdF9sZW4pOw0K Kw0KKyAgICByZXR1cm4gMDsNCit9DQorDQorc3RhdGljIHZvaWQgcG9sZGh1 X2ludGVycnVwdChpbnQgaXJxLCB2b2lkICpkZXZfaWQsIHN0cnVjdCBwdF9y ZWdzICpyZWdzKQ0KK3sNCisgICAgc3RydWN0IG5ldF9kZXZpY2UgKmRldiA9 IChzdHJ1Y3QgbmV0X2RldmljZSAqKWRldl9pZDsNCisgICAgc3RydWN0IHBv bGRodV9wcml2YXRlICpscDsNCisgICAgaW50IGlvYWRkcjsNCisgICAgdW5z aWduZWQgY2hhciBzdGF0dXMgPSAwOw0KKw0KKyAgICBpZiAoZGV2ID09IE5V TEwpIA0KKyAgICAgICAgcmV0dXJuOw0KKyAgICBscCA9IChzdHJ1Y3QgcG9s ZGh1X3ByaXZhdGUgKilkZXYtPnByaXY7DQorICAgIGlvYWRkciA9IGRldi0+ YmFzZV9hZGRyOw0KKw0KKyAgICAvKiBEaXNhYmxlIGludGVycnVwdHMgKi8N CisgICAgb3V0YihpbmIoaW9hZGRyICsgMHgwOCkgJiB+MHg4MCwgaW9hZGRy ICsgMHgwOCk7DQorDQorICAgIHN0YXR1cyA9IGluYihpb2FkZHIgKyAweDA3 KTsNCisgICAgaWYgKHN0YXR1cyAmIDB4MDgpIHsNCisgICAgICAgIHBvbGRo dV9od19yZXNldChkZXYpOw0KKyAgICB9IGVsc2Ugew0KKyAgICAgICAgaWYg KHN0YXR1cyAmIDB4ODApIHsNCisgICAgICAgICAgICBpZiAoaW5iKGlvYWRk ciArIDB4MDkpICYgMHg4MCkgew0KKyAgICAgICAgICAgICAgICBvdXRiKGlu Yihpb2FkZHIgKyAweDA5KSAmIH4weDgwLCBpb2FkZHIgKyAweDA5KTsNCisg ICAgICAgICAgICAgICAgbHAtPnNlcXVlbmNlID0gMDsNCisgICAgICAgICAg ICB9DQorICAgICAgICB9DQorICAgICAgICBpZiAoKHN0YXR1cyAmIDB4MjAp ICE9IChscC0+c2VxdWVuY2UgJiAweDIwKSkgew0KKyAgICAgICAgICAgIHBv bGRodV9yeChkZXYpOw0KKyAgICAgICAgICAgIGxwLT5zZXF1ZW5jZSA9IHN0 YXR1cyAmIDB4MjA7DQorICAgICAgICB9DQorICAgIH0NCisNCisgICAgLyog RW5hYmxlIGludGVycnVwdHMgYWdhaW4gKi8NCisgICAgb3V0YihpbmIoaW9h ZGRyICsgMHgwOCkgfCAweDgwLCBpb2FkZHIgKyAweDA4KTsNCisNCisgICAg cmV0dXJuOw0KK30NCisNCitzdGF0aWMgc3RydWN0IG5ldF9kZXZpY2Vfc3Rh dHMgKnBvbGRodV9nZXRfc3RhdHMoc3RydWN0IG5ldF9kZXZpY2UgKmRldikN Cit7DQorICAgIHN0cnVjdCBwb2xkaHVfcHJpdmF0ZSAqbHAgPSAoc3RydWN0 IHBvbGRodV9wcml2YXRlICopZGV2LT5wcml2Ow0KKw0KKyAgICByZXR1cm4g JmxwLT5zdGF0czsNCit9DQorDQorc3RhdGljIGludCBwb2xkaHVfY2xvc2Uo c3RydWN0IG5ldF9kZXZpY2UgKmRldikNCit7DQorICAgIGludCBpb2FkZHIg PSBkZXYtPmJhc2VfYWRkcjsNCisgICAgZGV2X2xpbmtfdCAqbGluazsNCisN CisgICAgZm9yIChsaW5rID0gZGV2X2xpc3Q7IGxpbms7IGxpbmsgPSBsaW5r LT5uZXh0KQ0KKyAgICAgICAgaWYgKGxpbmstPnByaXYgPT0gZGV2KSBicmVh azsNCisgICAgaWYgKGxpbmsgPT0gTlVMTCkNCisgICAgICAgIHJldHVybiAt RU5PREVWOw0KKw0KKyAgICBERUJVRygyLCAiJXM6IHNodXR0aW5nIGRvd24g ZXRoZXJjYXJkLlxuIiwgZGV2LT5uYW1lKTsNCisNCisgICAgaWYgKERFVl9P SyhsaW5rKSkgew0KKyAgICAgICAgb3V0YigweDAwLCBpb2FkZHIgKyAweDA4 KTsNCisgICAgfQ0KKw0KKyAgICBsaW5rLT5vcGVuLS07DQorICAgIGlmIChs aW5rLT5zdGF0ZSAmIERFVl9TVEFMRV9DT05GSUcpIHsNCisgICAgICAgIGxp bmstPnJlbGVhc2UuZXhwaXJlcyA9IGppZmZpZXMgKyAoSFovMjApOw0KKyAg ICAgICAgbGluay0+c3RhdGUgfD0gREVWX1JFTEVBU0VfUEVORElORzsNCisg ICAgICAgIGFkZF90aW1lcigmbGluay0+cmVsZWFzZSk7DQorICAgIH0NCisN CisgICAgTU9EX0RFQ19VU0VfQ09VTlQ7DQorDQorICAgIHJldHVybiAwOw0K K30NCisNCitzdGF0aWMgaW50IHBvbGRodV9kb19pb2N0bChzdHJ1Y3QgbmV0 X2RldmljZSAqZGV2LCBzdHJ1Y3QgaWZyZXEgKnJxLCBpbnQgY21kKQ0KK3sN CisgICAgc3RydWN0IGl3cmVxICoJd3JxID0gKHN0cnVjdCBpd3JlcSAqKSBy cTsNCisgICAgc3RydWN0IHBvbGRodV9wcml2YXRlICogbHAgPSAoc3RydWN0 IHBvbGRodV9wcml2YXRlICopZGV2LT5wcml2Ow0KKyAgICBpbnQgcmV0ID0g MDsNCisgICAgdW5zaWduZWQgY2hhciBrZXlzW1NOV05NUF9NQVhfS0VZX1NJ WkVdOw0KKw0KKyNpZmRlZiBERUJVR19JT0NUTF9UUkFDRQ0KKyAgICBwcmlu dGsoS0VSTl9ERUJVRyAiJXM6IC0+cG9sZGh1X2RvX2lvY3RsKGNtZD0weCVY KVxuIiwgZGV2LT5uYW1lLCBjbWQpOw0KKyNlbmRpZg0KKw0KKyAgICAvKiBD aGVjayBwZXJtaXNzaW9ucyBmb3IgU0VUIGNvbW1hbmRzICovDQorICAgIGlm IChJV19JU19TRVQoY21kKSAmJiAhc3VzZXIoKSkNCisgICAgICAgIHJldHVy biAtRVBFUk07DQorDQorICAgIHN3aXRjaChjbWQpDQorICAgIHsNCisgICAg ICAgIC8qIC0tLS0tLS0tLS0tLS0tLS0tIFdJUkVMRVNTIEVYVEVOU0lPTlMg LS0tLS0tLS0tLS0tLS0tLS0tLSAqLw0KKyAgICAgICAgY2FzZSBTSU9DR0lX TkFNRToNCisgICAgICAgICAgICBzdHJjcHkod3JxLT51Lm5hbWUsICJQb2xk aHUiKTsNCisgICAgICAgICAgICBicmVhazsNCisgICAgICAgIGNhc2UgU0lP Q0dJV0FQOg0KKyAgICAgICAgICAgIG1lbWNweSh3cnEtPnUuYXBfYWRkci5z YV9kYXRhLCBscC0+YnNzaWQsIEVUSF9BTEVOKTsNCisgICAgICAgICAgICB3 cnEtPnUuYXBfYWRkci5zYV9mYW1pbHkgPSBBUlBIUkRfRVRIRVI7DQorICAg ICAgICAgICAgYnJlYWs7DQorICAgICAgICBjYXNlIFNJT0NHSVdNT0RFOg0K KyAgICAgICAgICAgIHdycS0+dS5tb2RlID0gSVdfTU9ERV9JTkZSQTsNCisg ICAgICAgICAgICBicmVhazsNCisgICAgICAgIGNhc2UgU0lPQ0dJV0ZSRVE6 DQorICAgICAgICAgICAgYnJlYWs7DQorICAgICAgICBjYXNlIFNJT0NTSVdF TkNPREU6IC8qIFNldCBlbmNyeXB0aW9uIGtleSAqLw0KKyAgICAgICAgICAg IGlmICh3cnEtPnUuZW5jb2RpbmcucG9pbnRlciAhPSAoY2FkZHJfdCkgMCkg ew0KKyAgICAgICAgICAgICAgICAvKiBDaGVjayB0aGUgbGVuZ3RoIG9mIHRo ZSBrZXkgKi8NCisgICAgICAgICAgICAgICAgaWYgKHdycS0+dS5lbmNvZGlu Zy5sZW5ndGggPiBTTldOTVBfTUFYX0tFWV9TSVpFKSB7DQorICAgICAgICAg ICAgICAgICAgICByZXQgPSAtRUlOVkFMOw0KKyAgICAgICAgICAgICAgICAg ICAgYnJlYWs7DQorICAgICAgICAgICAgICAgIH0NCisNCisgICAgICAgICAg ICAgICAgLyogQ29weSB0aGUga2V5IGZyb20gdXNlcnNwYWNlICovDQorICAg ICAgICAgICAgICAgIGlmIChjb3B5X2Zyb21fdXNlcihrZXlzLCB3cnEtPnUu ZW5jb2RpbmcucG9pbnRlciwgDQorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB3cnEtPnUuZW5jb2RpbmcubGVuZ3RoKSkNCisgICAgICAg ICAgICAgICAgew0KKyAgICAgICAgICAgICAgICAgICAgcmV0ID0gLUVGQVVM VDsNCisgICAgICAgICAgICAgICAgICAgIGJyZWFrOw0KKyAgICAgICAgICAg ICAgICB9DQorICAgICAgICAgICAgICAgIG1lbWNweShscC0+ZW5jLmtleXMs IGtleXMsIFNOV05NUF9NQVhfS0VZX1NJWkUpOw0KKyAgICAgICAgICAgIH0N CisgICAgICAgICAgICANCisgICAgICAgICAgICAvKiBEZWNvZGUgdGhlIGZs YWdzICovDQorICAgICAgICAgICAgbHAtPmVuYy5lbmFibGUgPSAxOw0KKyAg ICAgICAgICAgIGlmICh3cnEtPnUuZW5jb2RpbmcuZmxhZ3MgJiBJV19FTkNP REVfRElTQUJMRUQpDQorICAgICAgICAgICAgICAgIGxwLT5lbmMuZW5hYmxl ID0gMDsNCisgICAgICAgICAgICBpZiAod3JxLT51LmVuY29kaW5nLmZsYWdz ICYgSVdfRU5DT0RFX1JFU1RSSUNURUQpDQorICAgICAgICAgICAgICAgIGxw LT5lbmMucmVzdHJpY3RlZCA9IDE7DQorICAgICAgICAgICAgaWYgKHdycS0+ dS5lbmNvZGluZy5mbGFncyAmIElXX0VOQ09ERV9PUEVOKQ0KKyAgICAgICAg ICAgICAgICBscC0+ZW5jLnJlc3RyaWN0ZWQgPSAwOw0KKyAgICAgICAgICAg IGxwLT5lbmMuaW5kZXggPSAobG9uZykod3JxLT51LmVuY29kaW5nLmZsYWdz ICYgSVdfRU5DT0RFX0lOREVYKTsNCisNCisgICAgICAgICAgICBwb2xkaHVf ZW5jcnlwdChkZXYpOw0KKw0KKyAgICAgICAgICAgIGJyZWFrOw0KKyAgICAg ICAgY2FzZSBTSU9DR0lXRU5DT0RFOiAvKiBHZXQgdGhlIGVuY3J5cHRpb24g a2V5ICovDQorICAgICAgICAgICAgaWYgKCFzdXNlcigpKQ0KKyAgICAgICAg ICAgIHsNCisgICAgICAgICAgICAgICAgcmV0ID0gLUVQRVJNOw0KKyAgICAg ICAgICAgICAgICBicmVhazsNCisgICAgICAgICAgICB9DQorDQorICAgICAg ICAgICAgaWYgKHdycS0+dS5kYXRhLnBvaW50ZXIgIT0gKGNhZGRyX3QpIDAp DQorICAgICAgICAgICAgew0KKyAgICAgICAgICAgICAgICBjb3B5X3RvX3Vz ZXIod3JxLT51LmRhdGEucG9pbnRlciwgbHAtPmVuYy5rZXlzLCBTTldOTVBf TUFYX0tFWV9TSVpFKTsNCisgICAgICAgICAgICAgICAgd3JxLT51LmRhdGEu bGVuZ3RoID0gU05XTk1QX01BWF9LRVlfU0laRTsNCisgICAgICAgICAgICB9 DQorICAgICAgICAgICAgd3JxLT51LmRhdGEuZmxhZ3MgPSAwOw0KKyAgICAg ICAgICAgIHdycS0+dS5kYXRhLmZsYWdzIHw9IGxwLT5lbmMuaW5kZXggJiBJ V19FTkNPREVfSU5ERVg7DQorICAgICAgICAgICAgaWYgKCFscC0+ZW5jLmVu YWJsZSkgd3JxLT51LmRhdGEuZmxhZ3MgfD0gSVdfRU5DT0RFX0RJU0FCTEVE Ow0KKyAgICAgICAgICAgIGlmIChscC0+ZW5jLnJlc3RyaWN0ZWQpIHdycS0+ dS5kYXRhLmZsYWdzIHw9IElXX0VOQ09ERV9SRVNUUklDVEVEOw0KKyAgICAg ICAgICAgIGlmICghbHAtPmVuYy5yZXN0cmljdGVkKSB3cnEtPnUuZGF0YS5m bGFncyB8PSBJV19FTkNPREVfT1BFTjsNCisgICAgICAgICAgICBicmVhazsN CisgICAgICAgIGNhc2UgU0lPQ0dJV1JBTkdFOiAvKiByYW5nZXMgKi8NCisg ICAgICAgICAgICBpZiAod3JxLT51LmRhdGEucG9pbnRlciAhPSAoY2FkZHJf dCkgMCkNCisgICAgICAgICAgICB7DQorICAgICAgICAgICAgICAgIHN0cnVj dCBpd19yYW5nZSByYW5nZTsNCisNCisgICAgICAgICAgICAgICAgLyogVmVy aWZ5IHRoZSB1c2VyIGJ1ZmZlciAqLw0KKyAgICAgICAgICAgICAgICByZXQg PSB2ZXJpZnlfYXJlYShWRVJJRllfV1JJVEUsIHdycS0+dS5kYXRhLnBvaW50 ZXIsDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpemVv ZihzdHJ1Y3QgaXdfcmFuZ2UpKTsNCisgICAgICAgICAgICAgICAgaWYgKHJl dCkgYnJlYWs7DQorDQorICAgICAgICAgICAgICAgIC8qIFNldCB0aGUgbGVu Z3RoIChpdCdzIGNvbnN0YW50KS4gKi8NCisgICAgICAgICAgICAgICAgd3Jx LT51LmRhdGEubGVuZ3RoID0gc2l6ZW9mKHN0cnVjdCBpd19yYW5nZSk7DQor DQorICAgICAgICAgICAgICAgIC8qIFNldCBpbmZvcm1hdGlvbiBpbiB0aGUg cmFuZ2Ugc3RydWN0LiAqLw0KKyAgICAgICAgICAgICAgICByYW5nZS50aHJv dWdocHV0ICAgICA9IDUuNSAqIDEwMjQgKiAxMDI0Ow0KKyAgICAgICAgICAg ICAgICByYW5nZS5taW5fbndpZCAgICAgICA9IDB4MDAwMDsNCisgICAgICAg ICAgICAgICAgcmFuZ2UubWF4X253aWQgICAgICAgPSAweDAwMzI7DQorICAg ICAgICAgICAgICAgIHJhbmdlLm51bV9jaGFubmVscyAgID0gMTM7DQorCQly YW5nZS5udW1fZnJlcXVlbmN5ICA9IDA7DQorICAgICAgICAgICAgICAgIHJh bmdlLnNlbnNpdGl2aXR5ICAgID0gMDsNCisgICAgICAgICAgICAgICAgcmFu Z2UubWF4X3F1YWwucXVhbCAgPSAwOw0KKyAgICAgICAgICAgICAgICByYW5n ZS5tYXhfcXVhbC5sZXZlbCA9IDA7DQorICAgICAgICAgICAgICAgIHJhbmdl Lm1heF9xdWFsLm5vaXNlID0gMDsNCisNCisgICAgICAgICAgICAgICAgLyog Q29weSBzdHJ1Y3R1cmUgdG8gdGhlIHVzZXIgYnVmZmVyLiAqLw0KKyAgICAg ICAgICAgICAgICBjb3B5X3RvX3VzZXIod3JxLT51LmRhdGEucG9pbnRlciwg JnJhbmdlLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2l6ZW9m KHN0cnVjdCBpd19yYW5nZSkpOw0KKyAgICAgICAgICAgIH0NCisgICAgICAg ICAgICBicmVhazsNCisjaWYgV0lSRUxFU1NfRVhUID4gNQ0KKyAgICAgICAg Y2FzZSBTSU9DU0lXRVNTSUQ6DQorICAgICAgICAgICAgaWYgKHdycS0+dS5k YXRhLnBvaW50ZXIgIT0gKGNhZGRyX3QpMCkNCisgICAgICAgICAgICB7DQor ICAgICAgICAgICAgICAgIGNoYXIgZXNzaWRbSVdfRVNTSURfTUFYX1NJWkUg KyAxXTsNCisNCisgICAgICAgICAgICAgICAgLyogQ2hlY2sgdGhlIHNpemUg b2YgdGhlIHN0cmluZyAqLw0KKyAgICAgICAgICAgICAgICBpZiAod3JxLT51 LmRhdGEubGVuZ3RoID4gSVdfRVNTSURfTUFYX1NJWkUgKyAxKQ0KKyAgICAg ICAgICAgICAgICB7DQorICAgICAgICAgICAgICAgICAgICByZXQgPSAtRTJC SUc7DQorICAgICAgICAgICAgICAgICAgICBicmVhazsNCisgICAgICAgICAg ICAgICAgfQ0KKw0KKyAgICAgICAgICAgICAgICAvKiBDb3B5IHRoZSBzdHJp bmcgZnJvbSB1c2Vyc3BhY2UgKi8NCisgICAgICAgICAgICAgICAgaWYgKGNv cHlfZnJvbV91c2VyKGVzc2lkLCB3cnEtPnUuZGF0YS5wb2ludGVyLCANCisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdycS0+dS5kYXRh Lmxlbmd0aCkpDQorICAgICAgICAgICAgICAgIHsNCisgICAgICAgICAgICAg ICAgICAgIHJldCA9IC1FRkFVTFQ7DQorICAgICAgICAgICAgICAgICAgICBi cmVhazsNCisgICAgICAgICAgICAgICAgfQ0KKyAgICAgICAgICAgICAgICBl c3NpZFtJV19FU1NJRF9NQVhfU0laRV0gPSAnXDAnOw0KKw0KKyAgICAgICAg ICAgICAgICBERUJVRygwLCAiJXM6IFNldCBkZXNpcmVkIFNTSUQ6ICVzIiwg ZGV2LT5uYW1lLCBlc3NpZCk7DQorCQltZW1jcHkobHAtPndhbnRlZF9lc3Np ZCwgZXNzaWQsIElXX0VTU0lEX01BWF9TSVpFKTsNCisgICAgICAgICAgICAg ICAgc253bm1wX3NldChkZXYsIE9JRF9ET1QxMV9ET1QxMURFU0lSRURTU0lE LCANCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVzc2lkLCBJ V19FU1NJRF9NQVhfU0laRSk7DQorICAgICAgICAgICAgfQ0KKyAgICAgICAg ICAgIGJyZWFrOw0KKyAgICAgICAgY2FzZSBTSU9DR0lXRVNTSUQ6DQorICAg ICAgICAgICAgLyogQmFzaWMgY2hlY2tpbmcgKi8NCisgICAgICAgICAgICBp ZiAod3JxLT51LmRhdGEucG9pbnRlciAhPSAoY2FkZHJfdCkgMCkNCisgICAg ICAgICAgICB7DQorICAgICAgICAgICAgICAgIGNoYXIgZXNzaWRbSVdfRVNT SURfTUFYX1NJWkUgKyAxXTsNCisNCisgICAgICAgICAgICAgICAgLyogQ29w eSB0aGUgU1NJRCBpbnRvIGEgc3RyaW5nICovDQorICAgICAgICAgICAgICAg IG1lbWNweShlc3NpZCwgbHAtPnNzaWQsIElXX0VTU0lEX01BWF9TSVpFKTsN CisgICAgICAgICAgICAgICAgZXNzaWRbSVdfRVNTSURfTUFYX1NJWkVdID0g J1wwJzsNCisNCisgICAgICAgICAgICAgICAgLyogU2V0IHRoZSBsZW5ndGgg Ki8NCisgICAgICAgICAgICAgICAgd3JxLT51LmRhdGEubGVuZ3RoID0gc3Ry bGVuKGVzc2lkKSArIDE7DQorDQorICAgICAgICAgICAgICAgIC8qIENvcHkg c3RydWN0dXJlIHRvIHRoZSB1c2VyIHBvaW50ZXIgKi8NCisgICAgICAgICAg ICAgICAgaWYgKGNvcHlfdG9fdXNlcih3cnEtPnUuZGF0YS5wb2ludGVyLCBl c3NpZCwgd3JxLT51LmRhdGEubGVuZ3RoKSk7DQorICAgICAgICAgICAgICAg ICAgICByZXQgPSAtRUZBVUxUOw0KKyAgICAgICAgICAgIH0NCisJICAgIGJy ZWFrOw0KKyNlbmRpZg0KKyAgICAgICAgY2FzZSBTSU9DR0lXUFJJVjogLyog UHJpdmF0ZSBpb2N0bCdzICovDQorICAgICAgICAgICAgaWYgKHdycS0+dS5k YXRhLnBvaW50ZXIpDQorICAgICAgICAgICAgew0KKyAgICAgICAgICAgICAg ICBzdHJ1Y3QgaXdfcHJpdl9hcmdzIHByaXZbXSA9IHsNCisgICAgICAgICAg ICAgICAgICAgIHsgU0lPQ0RFVlBSSVZBVEUgKyAweDAwLCANCisgICAgICAg ICAgICAgICAgICAgICAgSVdfUFJJVl9UWVBFX0lOVCB8IDEsIDAsICJhaXJs b2NrIiB9LA0KKyAgICAgICAgICAgICAgICB9Ow0KKyAgICAgICAgICAgICAg ICByZXQgPSB2ZXJpZnlfYXJlYShWRVJJRllfV1JJVEUsIHdycS0+dS5kYXRh LnBvaW50ZXIsDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg c2l6ZW9mKHByaXYpKTsNCisgICAgICAgICAgICAgICAgaWYgKHJldCkNCisg ICAgICAgICAgICAgICAgICAgIGJyZWFrOw0KKyAgICAgICAgICAgICAgICB3 cnEtPnUuZGF0YS5sZW5ndGggPSBzaXplb2YocHJpdikgLyBzaXplb2YocHJp dlswXSk7DQorICAgICAgICAgICAgICAgIGNvcHlfdG9fdXNlcih3cnEtPnUu ZGF0YS5wb2ludGVyLCBwcml2LCBzaXplb2YocHJpdikpOw0KKyAgICAgICAg ICAgIH0NCisgICAgICAgICAgICBicmVhazsNCisgICAgICAgIGNhc2UgU0lP Q0RFVlBSSVZBVEUgKyAweDAwOg0KKyAgICAgICAgICAgIGlmICghc3VzZXIo KSkNCisgICAgICAgICAgICB7DQorICAgICAgICAgICAgICAgIHJldCA9IC1F UEVSTTsNCisgICAgICAgICAgICAgICAgYnJlYWs7DQorICAgICAgICAgICAg fQ0KKyAgICAgICAgICAgIA0KKyAgICAgICAgICAgIGlmICh3cnEtPnUuZGF0 YS5wb2ludGVyICE9IChjYWRkcl90KSAwKQ0KKyAgICAgICAgICAgIHsNCisg ICAgICAgICAgICAgICAgLyogQ2hlY2sgd2hhdCB3ZSBzaG91bGQgZG8gKi8N CisgICAgICAgICAgICAgICAgaWYgKHdycS0+dS5kYXRhLmxlbmd0aCAhPSAw KSAvKiBTZXQgKi8NCisgICAgICAgICAgICAgICAgew0KKyAgICAgICAgICAg ICAgICAgICAgbG9uZyBhaXJsb2NrOw0KKyAgICAgICAgICAgICAgICAgICAg Y29weV9mcm9tX3VzZXIoJmFpcmxvY2ssIHdycS0+dS5kYXRhLnBvaW50ZXIs IHNpemVvZihsb25nKSk7DQorDQorICAgICAgICAgICAgICAgICAgICBscC0+ ZW5jLmFpcmxvY2sgPSBhaXJsb2NrOw0KKw0KKyAgICAgICAgICAgICAgICAg ICAgcG9sZGh1X2VuY3J5cHQoZGV2KTsgDQorICAgICAgICAgICAgICAgIH0N CisgICAgICAgICAgICAgICAgZWxzZSAvKiBHZXQgKi8NCisgICAgICAgICAg ICAgICAgew0KKyAgICAgICAgICAgICAgICAgICAgbG9uZyBhaXJsb2NrID0g bHAtPmVuYy5haXJsb2NrOw0KKyAgICAgICAgICAgICAgICAgICAgY29weV90 b191c2VyKHdycS0+dS5kYXRhLnBvaW50ZXIsICZhaXJsb2NrLCBzaXplb2Yo YWlybG9jaykpOw0KKyAgICAgICAgICAgICAgICB9DQorICAgICAgICAgICAg fQ0KKyAgICAgICAgICAgIGJyZWFrOw0KKyAgICAgICAgZGVmYXVsdDoNCisg ICAgICAgICAgICByZXQgPSAtRU9QTk9UU1VQUDsNCisgICAgICAgICAgICBi cmVhazsNCisgICAgfQ0KKyNpZmRlZiBERUJVR19JT0NUTF9UUkFDRQ0KKyAg ICBwcmludGsoS0VSTl9ERUJVRyAiJXM6IDwtcG9sZGh1X2RvX2lvY3RsKClc biIsIGRldi0+bmFtZSk7DQorI2VuZGlmDQorICAgIHJldHVybiByZXQ7DQor fQ0KKw0KK3N0YXRpYyBpbnQgcG9sZGh1X2VuY3J5cHQoc3RydWN0IG5ldF9k ZXZpY2UgKmRldikNCit7DQorICAgIHN0cnVjdCBwb2xkaHVfcHJpdmF0ZSAq bHAgPSBkZXYtPnByaXY7DQorICAgIHN0cnVjdCBwb2xkaHVfZW5jcnlwdGlv biAqZW5jID0gJihscC0+ZW5jKTsNCisNCisgICAgbG9uZyBhbGdvcml0aG1f ZW5hYmxlWzJdOw0KKyAgICBsb25nIHByaXZhY3lfaW52b2tlZDsNCisgICAg bG9uZyBleGNsdWRlX3VuZW5jcnlwdGVkOw0KKyAgICBsb25nIHB1YmxpY19r ZXlfZW5hYmxlOw0KKyAgICBsb25nIGRlZmF1bHRfa2V5X2lkOw0KKyAgICB1 bnNpZ25lZCBjaGFyIGtleXNbU05XTk1QX01BWF9LRVlfU0laRV07DQorDQor ICAgIC8qIFNldCB0aGUgZGVmYXVsdCB2YWx1ZXMgKi8NCisgICAgbWVtY3B5 KGtleXMsIGVuYy0+a2V5cywgU05XTk1QX01BWF9LRVlfU0laRSk7DQorICAg IGRlZmF1bHRfa2V5X2lkID0gaHRvbmwoZW5jLT5pbmRleCk7DQorICAgIGV4 Y2x1ZGVfdW5lbmNyeXB0ZWQgPSBodG9ubCgyKTsNCisgICAgcHVibGljX2tl eV9lbmFibGUgPSBodG9ubCgyKTsNCisgICAgcHJpdmFjeV9pbnZva2VkID0g aHRvbmwoMik7DQorICAgIGFsZ29yaXRobV9lbmFibGVbMF0gPSBodG9ubCgx KTsgYWxnb3JpdGhtX2VuYWJsZVsxXSA9IGh0b25sKDIpOw0KKw0KKyAgICBp ZiAoZW5jLT5lbmFibGUpDQorICAgIHsNCisgICAgICAgIGlmIChlbmMtPnJl c3RyaWN0ZWQpIGV4Y2x1ZGVfdW5lbmNyeXB0ZWQgPSBodG9ubCgxKTsgDQor ICAgICAgICBpZiAoZW5jLT5haXJsb2NrKSBwdWJsaWNfa2V5X2VuYWJsZSA9 IGh0b25sKDEpOw0KKyAgICAgICAgcHJpdmFjeV9pbnZva2VkID0gaHRvbmwo MSk7DQorICAgICAgICBhbGdvcml0aG1fZW5hYmxlWzBdID0gaHRvbmwoMik7 IGFsZ29yaXRobV9lbmFibGVbMV0gPSBodG9ubCgxKTsNCisgICAgfSBlbHNl IA0KKwlpZiAoZW5jLT5haXJsb2NrKSB7DQorCSAgICBwdWJsaWNfa2V5X2Vu YWJsZSA9IGh0b25sKDEpOw0KKyAgICAgICAgICAgIGFsZ29yaXRobV9lbmFi bGVbMF0gPSBodG9ubCgyKTsgYWxnb3JpdGhtX2VuYWJsZVsxXSA9IGh0b25s KDEpOw0KKyAgICAgICAgfQ0KKwkNCisNCisNCisgICAgLyogU2VuZCBvdXQg dGhlIFNOV05NUCBwYWNrZXRzICovDQorICAgIHNud25tcF9zZXQoZGV2LCBP SURfRE9UMTFfRE9UMTFBVVRIRU5USUNBVElPTkFMR09SSVRITUVOQUJMRSwg DQorICAgICAgICAgICAgICAgKHVuc2lnbmVkIGNoYXIgKilhbGdvcml0aG1f ZW5hYmxlLCBzaXplb2YoYWxnb3JpdGhtX2VuYWJsZSkpOw0KKyAgICBzbndu bXBfc2V0KGRldiwgT0lEX0RPVDExX0RPVDExUFJJVkFDWUlOVk9LRUQsIA0K KyAgICAgICAgICAgICAgICh1bnNpZ25lZCBjaGFyICopJnByaXZhY3lfaW52 b2tlZCwgc2l6ZW9mKHByaXZhY3lfaW52b2tlZCkpOw0KKyAgICBzbndubXBf c2V0KGRldiwgT0lEX0RPVDExX0RPVDExRVhDTFVERVVORU5DUllQVEVELA0K KyAgICAgICAgICAgICAgICh1bnNpZ25lZCBjaGFyICopJmV4Y2x1ZGVfdW5l bmNyeXB0ZWQsIHNpemVvZihleGNsdWRlX3VuZW5jcnlwdGVkKSk7DQorICAg IHNud25tcF9zZXQoZGV2LCBPSURfTldOX1NNVFBVQkxJQ0tFWUVOQUJMRSwN CisgICAgICAgICAgICAgICAodW5zaWduZWQgY2hhciAqKSZwdWJsaWNfa2V5 X2VuYWJsZSwgc2l6ZW9mKHB1YmxpY19rZXlfZW5hYmxlKSk7DQorICAgIHNu d25tcF9zZXQoZGV2LCBPSURfRE9UMTFfRE9UMTFXRVBERUZBVUxUS0VZSUQs DQorICAgICAgICAgICAgICAgKHVuc2lnbmVkIGNoYXIgKikmZGVmYXVsdF9r ZXlfaWQsIHNpemVvZihkZWZhdWx0X2tleV9pZCkpOw0KKyAgICBzbndubXBf c2V0KGRldiwgT0lEX0RPVDExX0RPVDExV0VQREVGQVVMVEtFWSwNCisgICAg ICAgICAgICAgICBrZXlzLCBzaXplb2Yoa2V5cykpOw0KKyAgICByZXR1cm4g MDsNCit9ICAgIA0KKw0KKy8qPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ki8N CisvKiBEZXZpY2UgZXZlbnQgaGFuZGxlciAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICovDQorDQorc3RhdGljIGlu dCBwb2xkaHVfZGV2aWNlX2V2ZW50KHN0cnVjdCBub3RpZmllcl9ibG9jayAq dW51c2VkLCB1bnNpZ25lZCBsb25nIGV2ZW50LCB2b2lkICpwdHIpDQorew0K KyAgICBzdHJ1Y3QgbmV0X2RldmljZSAqZGV2ID0gcHRyOw0KKyAgICBpbnQg aTsNCisNCisgICAgc3dpdGNoIChldmVudCkNCisgICAgew0KKyAgICBjYXNl IE5FVERFVl9ET1dOOg0KKyAgICAgICAgYnJlYWs7DQorICAgIGNhc2UgTkVU REVWX1VQOg0KKyAgICAgICAgZm9yIChpID0gMDsgaSA8IE1BWF9QT0xESFVT OyBpKyspIHsNCisgICAgICAgICAgICBpZiAocG9sZGh1c1tpXSA9PSBkZXYp DQorICAgICAgICAgICAgew0KKyAgICAgICAgICAgICAgICBzdHJ1Y3QgcG9s ZGh1X3ByaXZhdGUqIGxwID0gZGV2LT5wcml2Ow0KKyAgICAgICAgICAgICAg ICAvKiBVcGRhdGUgZW5jcnlwdGlvbiAqLw0KKyAgICAgICAgICAgICAgICBw b2xkaHVfZW5jcnlwdChkZXYpOw0KKw0KKyAgICAgICAgICAgICAgICAvKiBT ZXQgdGhlIFNTSUQgKi8NCisgICAgICAgICAgICAgICAgaWYgKGxwLT53YW50 ZWRfZXNzaWRbMF0gIT0gMCkgDQorICAgICAgICAgICAgICAgICAgICBzbndu bXBfc2V0KGRldiwgT0lEX0RPVDExX0RPVDExREVTSVJFRFNTSUQsIA0KKwkJ CSAgICAgICBscC0+d2FudGVkX2Vzc2lkLCANCisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgSVdfRVNTSURfTUFYX1NJWkUpOw0KKyAgICAgICAg ICAgICAgICBtb2RfdGltZXIoJmxwLT5yb2FtX3RpbWVyLCBqaWZmaWVzICsg SFogKiA1KTsNCisgICAgICAgICAgICB9DQorICAgICAgICB9DQorICAgICAg ICBicmVhazsNCisgICAgZGVmYXVsdDoNCisgICAgfQ0KKyAgICByZXR1cm4g Tk9USUZZX0RPTkU7DQorfQ0KKw0KKy8qPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PSovDQorLyogVGltZXIgZnVuY3Rpb25zICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8NCisNCitz dGF0aWMgdm9pZCBwb2xkaHVfYnNzaWRfdGltZXIodW5zaWduZWQgbG9uZyBk YXRhKQ0KK3sNCisgICAgc3RydWN0IG5ldF9kZXZpY2UqIGRldiA9IChzdHJ1 Y3QgbmV0X2RldmljZSopZGF0YTsNCisgICAgc253bm1wX2dldChkZXYsIE9J RF9OV05fU01UQ1VSUkVOVEJTU0lEKTsNCit9DQorDQorc3RhdGljIHZvaWQg cG9sZGh1X3JvYW1pbmdfdGltZXIodW5zaWduZWQgbG9uZyBkYXRhKQ0KK3sN CisgICAgc3RydWN0IG5ldF9kZXZpY2UqIGRldiA9IChzdHJ1Y3QgbmV0X2Rl dmljZSopZGF0YTsNCisNCisgICAgc253bm1wX2dldChkZXYsIE9JRF9OV05f Uk9BTVRBQkxFTEVOR1RIKTsNCisgICAgc253bm1wX2dldChkZXYsIE9JRF9O V05fUk9BTUJTU0lEKTsNCisgICAgc253bm1wX2dldChkZXYsIE9JRF9OV05f Uk9BTVNTSUQpOw0KKyAgICBzbndubXBfZ2V0KGRldiwgT0lEX05XTl9ST0FN QlNTVFlQRSk7DQorICAgIHNud25tcF9nZXQoZGV2LCBPSURfTldOX1JPQU1D SEFOTkVMKTsNCisgICAgc253bm1wX2dldChkZXYsIE9JRF9OV05fUk9BTUFH RSk7DQorICAgIHNud25tcF9nZXQoZGV2LCBPSURfTldOX1JPQU1RVUFMSVRZ KTsNCisgICAgc253bm1wX2dldChkZXYsIE9JRF9OV05fUk9BTUxPQUQpOw0K KyAgICBzbndubXBfZ2V0KGRldiwgT0lEX05XTl9ST0FNQkVBQ09OUEVSSU9E KTsNCisgICAgc253bm1wX2dldChkZXYsIE9JRF9OV05fUk9BTURUSU1QRVJJ T0QpOw0KKyAgICBzbndubXBfZ2V0KGRldiwgT0lEX05XTl9ST0FNQ0FQQUJJ TElUWUlORk9STUFUSU9OKTsNCisgICAgc253bm1wX2dldChkZXYsIE9JRF9O V05fUk9BTVJBVEVTKTsNCit9DQorDQorLyo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ki8NCisvKiBwcm9jLWZpbGVzeXN0ZW0gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqLw0KKw0K K3N0YXRpYyBpbnQgcG9sZGh1X3Byb2NfcmVhZChjaGFyICpidWYsIGNoYXIg KipzdGFydCwgb2ZmX3Qgb2ZmLA0KKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgaW50IGxlbiwgaW50ICplb2YsIHZvaWQgKmRhdGEpDQorew0KKyAg ICBpbnQgaSxqOw0KKyAgICBzdHJ1Y3QgbmV0X2RldmljZSogZGV2ID0gKHN0 cnVjdCBuZXRfZGV2aWNlKilkYXRhOw0KKyAgICBzdHJ1Y3QgcG9sZGh1X3By aXZhdGUqIGxwID0gKHN0cnVjdCBwb2xkaHVfcHJpdmF0ZSopZGV2LT5wcml2 Ow0KKyAgICBsb25nIGZsYWdzOw0KKyAgICBpbnQgYXNzb2NpYXRlZCA9IDA7 DQorICAgDQorICAgIHNwaW5fbG9ja19pcnFzYXZlKCZscC0+bG9jaywgZmxh Z3MpOyANCisgICAgbGVuID0gMDsNCisgICAgbGVuICs9IHNwcmludGYoYnVm ICsgbGVuLCAiJXNcbiIsIHZlcnNpb24pOw0KKyAgICBsZW4gKz0gc3ByaW50 ZihidWYgKyBsZW4sICJcbiIpOw0KKyAgICBsZW4gKz0gc3ByaW50ZihidWYg KyBsZW4sICJJL08gYWRkcmVzc1x0OiAweCUwM3hcbiIsIGRldi0+YmFzZV9h ZGRyKTsNCisgICAgbGVuICs9IHNwcmludGYoYnVmICsgbGVuLCAiSVJRXHRc dDogJWRcbiIsIGRldi0+aXJxKTsNCisgICAgbGVuICs9IHNwcmludGYoYnVm ICsgbGVuLCAiTUFDIGFkZHJlc3NcdDogIik7DQorICAgIGZvciAoaT0wO2k8 NjtpKyspDQorICAgICAgICBsZW4gKz0gc3ByaW50ZihidWYgKyBsZW4sICIl MDJ4JXMiLCBkZXYtPmRldl9hZGRyW2ldLCANCisgICAgICAgICAgICAgICAg ICAgICAgIGkgPCA1ID8gIjoiIDogIlxuIik7DQorICAgIGxlbiArPSBzcHJp bnRmKGJ1ZiArIGxlbiwgIkN1cnJlbnQgU1NJRFx0OiAlc1xuIiwgbHAtPnNz aWQpOw0KKyAgICBsZW4gKz0gc3ByaW50ZihidWYgKyBsZW4sICJDdXJyZW50 IEJTU0lEXHQ6ICIpOw0KKyAgICBmb3IgKGk9MDtpPDY7aSsrKQ0KKyAgICAg ICAgaWYgKGxwLT5ic3NpZFtpXSAhPSAwKSBhc3NvY2lhdGVkID0gMTsNCisg ICAgaWYgKGFzc29jaWF0ZWQpDQorICAgICAgICBmb3IgKGk9MDtpPDY7aSsr KQ0KKyAgICAgICAgICAgIGxlbiArPSBzcHJpbnRmKGJ1ZiArIGxlbiwgIiUw MnglcyIsIGxwLT5ic3NpZFtpXSwgDQorICAgICAgICAgICAgICAgICAgICAg ICAgICAgaSA8IDUgPyAiOiIgOiAiXG4iKTsNCisgICAgZWxzZQ0KKyAgICAg ICAgbGVuICs9IHNwcmludGYoYnVmICsgbGVuLCAiTm90IEFzc29jaWF0ZWRc biIpOw0KKyAgICBsZW4gKz0gc3ByaW50ZihidWYgKyBsZW4sICJDYXBhYmls aXRpZXNcdDogMHglMDhYXG4iLCBscC0+Y2FwaW5mbyk7DQorDQorICAgIGxl biArPSBzcHJpbnRmKGJ1ZiArIGxlbiwgIlxuIik7DQorICAgIGxlbiArPSBz cHJpbnRmKGJ1ZiArIGxlbiwgIlJvYW1pbmcgVGFibGVcbiIpOw0KKyAgICAN CisgICAgZm9yIChpPSAwO2k8bHAtPnJvYW1fdGFibGUuc2l6ZTtpKyspDQor ICAgIHsNCisgICAgICAgIGludCBwcmludF9lbnRyeSA9IDA7DQorICAgICAg ICBmb3IgKGo9MDtqPDY7aisrKSBpZiAobHAtPnJvYW1fdGFibGUuZW50cnlb aV0uYnNzaWRbal0gIT0gMCkgcHJpbnRfZW50cnkgPSAxOw0KKwlpZiAoc3Ry bGVuKGxwLT5yb2FtX3RhYmxlLmVudHJ5W2ldLmVzc2lkKSA9PSAwKSBwcmlu dF9lbnRyeSA9IDA7DQorDQorICAgICAgICBpZiAocHJpbnRfZW50cnkpIHsN CisgICAgICAgICAgICBsZW4gKz0gc3ByaW50ZihidWYgKyBsZW4sICJcbiIp Ow0KKyAgICAgICAgICAgIGxlbiArPSBzcHJpbnRmKGJ1ZiArIGxlbiwgIkJT U0lEXHRcdDogIik7DQorICAgICAgICAgICAgZm9yIChqPTA7ajw2O2orKykg DQorICAgICAgICAgICAgICAgIGxlbiArPSBzcHJpbnRmKGJ1ZiArIGxlbiwg IiUwMnglcyIsIA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgIGxwLT5y b2FtX3RhYmxlLmVudHJ5W2ldLmJzc2lkW2pdLA0KKyAgICAgICAgICAgICAg ICAgICAgICAgICAgIGogPCA1ID8gIjoiIDogIlxuIik7DQorICAgICAgICAg ICAgbGVuICs9IHNwcmludGYoYnVmICsgbGVuLCAiU1NJRFx0XHQ6ICVzXG4i LCBscC0+cm9hbV90YWJsZS5lbnRyeVtpXS5lc3NpZCk7DQorCSAgICBsZW4g Kz0gc3ByaW50ZihidWYgKyBsZW4sICJDYXBhYmlsaXRpZXNcdDogMHglMDhY XG4iLCBscC0+cm9hbV90YWJsZS5lbnRyeVtpXS5jYXBpbmZvKTsNCisgICAg ICAgICAgICBsZW4gKz0gc3ByaW50ZihidWYgKyBsZW4sICJCU1MgVHlwZVx0 OiAweCUwOFhcbiIsIGxwLT5yb2FtX3RhYmxlLmVudHJ5W2ldLmJzc3R5cGUp Ow0KKyAgICAgICAgICAgIGxlbiArPSBzcHJpbnRmKGJ1ZiArIGxlbiwgIkNo YW5uZWxcdFx0OiAweCUwOFhcbiIsDQorICAgICAgICAgICAgICAgICAgICAg ICAgICAgbHAtPnJvYW1fdGFibGUuZW50cnlbaV0uY2hhbm5lbCk7DQorICAg ICAgICAgICAgbGVuICs9IHNwcmludGYoYnVmICsgbGVuLCAiUm9hbWFnZVx0 XHQ6IDB4JTA4WFxuIiwNCisgICAgICAgICAgICAgICAgICAgbHAtPnJvYW1f dGFibGUuZW50cnlbaV0ucm9hbWFnZSk7DQorICAgICAgICAgICAgbGVuICs9 IHNwcmludGYoYnVmICsgbGVuLCAiUXVhbGl0eVx0XHQ6IDB4JTA4WFxuIiwN CisgICAgICAgICAgICAgICAgICAgICAgICAgICBscC0+cm9hbV90YWJsZS5l bnRyeVtpXS5xdWFsaXR5KTsNCisgICAgICAgICAgICBsZW4gKz0gc3ByaW50 ZihidWYgKyBsZW4sICJMb2FkXHRcdDogMHglMDhYXG4iLCANCisgICAgICAg ICAgICAgICAgICAgICAgICAgICBscC0+cm9hbV90YWJsZS5lbnRyeVtpXS5s b2FkKTsNCisgICAgICAgIH0NCisgICAgfQ0KKw0KKyAgICBzcGluX3VubG9j a19pcnFyZXN0b3JlKCZscC0+bG9jaywgZmxhZ3MpOw0KKw0KKyAgICByZXR1 cm4gbGVuOw0KK30NCisNCisvKj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0q Lw0KKy8qIE1vZHVsZSBpbml0aWFsaXphdGlvbiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICovDQorDQorc3RhdGlj IGludCBfX2luaXQgaW5pdF9wb2xkaHVfY3Modm9pZCkNCit7DQorICAgIHNl cnZpbmZvX3Qgc2VydjsNCisgICAgcHJpbnRrKEtFUk5fSU5GTyAiJXNcbiIs IHZlcnNpb24pOw0KKyAgICBDYXJkU2VydmljZXMoR2V0Q2FyZFNlcnZpY2Vz SW5mbywgJnNlcnYpOw0KKyAgICBpZiAoc2Vydi5SZXZpc2lvbiAhPSBDU19S RUxFQVNFX0NPREUpIHsNCisgICAgICAgIHByaW50ayhLRVJOX05PVElDRSAi cG9sZGh1X2NzOiBDYXJkIFNlcnZpY2VzIHJlbGVhc2UgIg0KKyAgICAgICAg ICAgICAgICJkb2VzIG5vdCBtYXRjaCFcbiIpOw0KKyAgICAgICAgcmV0dXJu IC0xOw0KKyAgICB9DQorICAgIHJlZ2lzdGVyX3BjY2FyZF9kcml2ZXIoJmRl dl9pbmZvLCAmcG9sZGh1X3BjbWNpYV9hdHRhY2gsICZwb2xkaHVfcGNtY2lh X2RldGFjaCk7DQorICAgIC8qIEFkZCBhIG5vdGlmaWVyLCBzbyB3ZSBjYW4g Y29uZmlndXJlIG5ldyBkZXZpY2VzICovDQorICAgIHJlZ2lzdGVyX25ldGRl dmljZV9ub3RpZmllcigmcG9sZGh1X2Rldl9ub3RpZmllcik7DQorDQorICAg IC8qIENyZWF0ZSB0aGUgcHJvYyBlbnRyeSAqLw0KKyAgICBwb2xkaHVfcHJv Y19kaXIgPSBwcm9jX21rZGlyKCJwb2xkaHUiLCBwcm9jX3Jvb3RfZHJpdmVy KTsNCisgICAgLypjcmVhdGVfcHJvY19pbmZvX2VudHJ5KCJyb2FtaW5nIiwg MCwgcG9sZGh1X3Byb2NfZGlyLCANCisgICAgICAgICAgICAgICAgICAgICAg ICAgICBwb2xkaHVfcHJvY19yZWFkKTsqLw0KKyAgICByZXR1cm4gMDsNCit9 DQorDQorc3RhdGljIHZvaWQgX19leGl0IGV4aXRfcG9sZGh1X2NzKHZvaWQp DQorew0KKyAgICBERUJVRygxLCAicG9sZGh1X2NzOiB1bmxvYWRpbmdcbiIp Ow0KKyAgICAvKiBSZW1vdmUgdGhlIHByb2MgZW50cnkgKi8NCisgICAgcmVt b3ZlX3Byb2NfZW50cnkoInBvbGRodSIsIHByb2Nfcm9vdF9kcml2ZXIpOw0K Kw0KKyAgICAvKiBVbnJlZ2lzdGVyIHRoZSBub3RpZmllciAqLw0KKyAgICB1 bnJlZ2lzdGVyX25ldGRldmljZV9ub3RpZmllcigmcG9sZGh1X2Rldl9ub3Rp Zmllcik7DQorDQorICAgIHVucmVnaXN0ZXJfcGNjYXJkX2RyaXZlcigmZGV2 X2luZm8pOw0KKw0KKyAgICB3aGlsZSAoZGV2X2xpc3QgIT0gTlVMTCkNCisg ICAgICAgIHBvbGRodV9wY21jaWFfZGV0YWNoKGRldl9saXN0KTsNCit9DQor DQorbW9kdWxlX2luaXQoaW5pdF9wb2xkaHVfY3MpOw0KK21vZHVsZV9leGl0 KGV4aXRfcG9sZGh1X2NzKTsNCmRpZmYgLXVOciBsaW51eC0yLjQuMy1hYzEz Lm9yaWcvZHJpdmVycy9uZXQvcGNtY2lhL3BvbGRodS5oIGxpbnV4LTIuNC4z LWFjMTMvZHJpdmVycy9uZXQvcGNtY2lhL3BvbGRodS5oDQotLS0gbGludXgt Mi40LjMtYWMxMy5vcmlnL2RyaXZlcnMvbmV0L3BjbWNpYS9wb2xkaHUuaAlU aHUgSmFuICAxIDAxOjAwOjAwIDE5NzANCisrKyBsaW51eC0yLjQuMy1hYzEz L2RyaXZlcnMvbmV0L3BjbWNpYS9wb2xkaHUuaAlUaHUgRmViICA4IDExOjQ1 OjE3IDIwMDENCkBAIC0wLDAgKzEsMjMgQEANCisjaWZuZGVmIFBPTERIVV9I DQorI2RlZmluZSBQT0xESFVfSA0KKw0KKy8qIE1heGltdW0gY2FyZHMgYWxs b3dlZCAqLw0KKyNkZWZpbmUgTUFYX1BPTERIVVMJNA0KKw0KKy8qIFBvbGRo dSByZWdpc3RlcnMgKi8NCisjZGVmaW5lIE1BQyhiYXNlKQkoYmFzZSArIDB4 MDApDQorI2RlZmluZSBNQUMwKGJhc2UpCShiYXNlICsgMHgwMCkJLyogTUFD IEFkZHJlc3MgKi8NCisjZGVmaW5lIE1BQzEoYmFzZSkJKGJhc2UgKyAweDAx KQ0KKyNkZWZpbmUgTUFDMihiYXNlKQkoYmFzZSArIDB4MDIpDQorI2RlZmlu ZSBNQUMzKGJhc2UpCShiYXNlICsgMHgwMykNCisjZGVmaW5lIE1BQzQoYmFz ZSkJKGJhc2UgKyAweDA0KQ0KKyNkZWZpbmUgTUFDNShiYXNlKQkoYmFzZSAr IDB4MDUpDQorI2RlZmluZSBWRVJTSU9OKGJhc2UpCShiYXNlICsgMHgwNikN CisjZGVmaW5lIFNUQVRVUyhiYXNlKQkoYmFzZSArIDB4MDcpDQorI2RlZmlu ZSBJTlRSKGJhc2UpCShiYXNlICsgMHgwOCkNCisjZGVmaW5lIFJFU0VUKGJh c2UpCShiYXNlICsgMHgwOSkNCisjZGVmaW5lIElOKGJhc2UpCShiYXNlICsg MHgwYSkNCisjZGVmaW5lIE9VVChiYXNlKQkoYmFzZSArIDB4MGEpDQorDQor I2VuZGlmIC8qIFBPTERIVV9IICovDQorDQpkaWZmIC11TnIgbGludXgtMi40 LjMtYWMxMy5vcmlnL2RyaXZlcnMvbmV0L3BjbWNpYS9zbndubXAuYyBsaW51 eC0yLjQuMy1hYzEzL2RyaXZlcnMvbmV0L3BjbWNpYS9zbndubXAuYw0KLS0t IGxpbnV4LTIuNC4zLWFjMTMub3JpZy9kcml2ZXJzL25ldC9wY21jaWEvc253 bm1wLmMJVGh1IEphbiAgMSAwMTowMDowMCAxOTcwDQorKysgbGludXgtMi40 LjMtYWMxMy9kcml2ZXJzL25ldC9wY21jaWEvc253bm1wLmMJVGh1IE1hciAg OCAwOToxNjoxMiAyMDAxDQpAQCAtMCwwICsxLDU4NCBAQA0KKy8qPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KKw0KKyAgICBDb3B5cmlnaHQgKEMp IDIwMDAgQmFzIFZlcm1ldWxlbiAtLSBidmVybWV1bEBibGFja3N0YXIubmwN CisNCisgICAgTm8gV2lyZXMgTmVlZGVkIFNOV05NUA0KKw0KKyAgICBzbndu bXAuYyAwLjEuMCAyMDAxLzAyLzA2DQorDQorPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PSovDQorI2luY2x1ZGUgPGxpbnV4L2NvbmZpZy5oPg0KKyNp ZmRlZiBfX0lOX1BDTUNJQV9QQUNLQUdFX18NCisjaW5jbHVkZSA8cGNtY2lh L2tfY29tcGF0Lmg+DQorI2VuZGlmDQorDQorI2luY2x1ZGUgPGxpbnV4L25l dGRldmljZS5oPg0KKyNpbmNsdWRlIDxsaW51eC93aXJlbGVzcy5oPg0KKw0K KyNpbmNsdWRlIDxwY21jaWEvdmVyc2lvbi5oPg0KKyNpbmNsdWRlIDxwY21j aWEvY3NfdHlwZXMuaD4NCisjaW5jbHVkZSA8cGNtY2lhL2NzLmg+DQorI2lu Y2x1ZGUgPHBjbWNpYS9jaXN0cGwuaD4NCisjaW5jbHVkZSA8cGNtY2lhL2Np c3JlZy5oPg0KKyNpbmNsdWRlIDxwY21jaWEvY2lzY29kZS5oPg0KKyNpbmNs dWRlIDxwY21jaWEvZHMuaD4NCisNCisjaW5jbHVkZSAic253bm1wLmgiDQor DQorc3RhdGljIGNoYXIgKnZlcnNpb24gPSAiTm8gV2lyZXMgTmVlZGVkIFNO V05NUCBkcml2ZXIgdjAuMS4wIjsNCisNCisjZGVmaW5lIE1BWF9ST0FNVEFC TEVfU0laRQkJMjU2DQorDQorc3RydWN0IHJvYW1fZW50cnlfdCB7DQorICAg IHVuc2lnbmVkIGNoYXIgYnNzaWRbTUFYX0FERFJfTEVOXTsNCisgICAgY2hh ciBlc3NpZFtJV19FU1NJRF9NQVhfU0laRSArIDFdOw0KKyAgICBpbnQgYnNz dHlwZTsNCisgICAgaW50IGNoYW5uZWw7DQorICAgIGludCByb2FtYWdlOw0K KyAgICBpbnQgcXVhbGl0eTsNCisgICAgaW50IGxvYWQ7DQorICAgIGludCBi ZWFjb25wZXJpb2Q7DQorICAgIGludCBkdGltcGVyaW9kOw0KKyAgICB1MTYg Y2FwaW5mbzsNCisgICAgdW5zaWduZWQgY2hhciByYXRlc1tNQVhfQUREUl9M RU5dOw0KK307DQorDQorc3RydWN0IHJvYW1fdGFibGVfdCB7DQorICAgIHN0 cnVjdCByb2FtX2VudHJ5X3QgZW50cnlbTUFYX1JPQU1UQUJMRV9TSVpFXTsg DQorICAgIGludCBzaXplOw0KK307DQorDQorc3RydWN0IG53bl9lbmNyeXB0 aW9uIHsNCisgICAgaW50IGFpcmxvY2s7DQorICAgIGludCBlbmFibGU7DQor ICAgIGludCByZXN0cmljdGVkOw0KKyAgICBpbnQgaW5kZXg7DQorICAgIHVu c2lnbmVkIGNoYXIga2V5c1tTTldOTVBfTUFYX0tFWV9TSVpFXTsNCit9Ow0K Kw0KK3N0cnVjdCBud25fcHJpdmF0ZSB7DQorICAgIGRldl9ub2RlX3Qgbm9k ZTsNCisgICAgc3RydWN0IG5ldF9kZXZpY2Vfc3RhdHMgc3RhdHM7DQorICAg IHN0cnVjdCByb2FtX3RhYmxlX3Qgcm9hbV90YWJsZTsNCisgICAgc3RydWN0 IG53bl9lbmNyeXB0aW9uIGVuYzsNCisgICAgY2hhciBzc2lkW0lXX0VTU0lE X01BWF9TSVpFICsgMV07DQorICAgIGNoYXIgd2FudGVkX2Vzc2lkW0lXX0VT U0lEX01BWF9TSVpFICsgMV07DQorICAgIHVuc2lnbmVkIGNoYXIgYnNzaWRb TUFYX0FERFJfTEVOXTsNCisgICAgdW5zaWduZWQgbG9uZyBjYXBpbmZvOw0K KyAgICBzdHJ1Y3QgdGltZXJfbGlzdCBic3NpZF90aW1lcjsNCisgICAgc3Ry dWN0IHRpbWVyX2xpc3Qgcm9hbV90aW1lcjsNCisgICAgc3BpbmxvY2tfdCBs b2NrOw0KKyAgICBpbnQgaXNfNTUwOw0KK307DQorDQorI2lmZGVmIENPTkZJ R19TTldOTVBfREVCVUcNCitzdGF0aWMgaW50IHNud25tcF9kZWJ1ZyA9IENP TkZJR19TTldOTVBfREVCVUc7DQorI2RlZmluZSBERUJVRyhuLCBhcmdzLi4u KSAgaWYgKHNud25tcF9kZWJ1Zz4obikpIHByaW50ayhLRVJOX0RFQlVHIGFy Z3MpDQorI2Vsc2UNCisjZGVmaW5lIERFQlVHKG4sIGFyZ3MuLi4pDQorI2Vu ZGlmDQorDQorI2RlZmluZSBQUklOVChuLCBhcmdzLi4uKSBwcmludGsoS0VS Tl9JTkZPIGFyZ3MpDQorI2RlZmluZSBrZnJlZV9zKG8scykga2ZyZWUobykN CisjZGVmaW5lIFNOV05NUF9TVFJJTkcobikgKG4gKyBFVEhfSExFTiArIFNO V05NUF9ITEVOKQ0KKyNkZWZpbmUgU05XTk1QX0xPTkcobikgICAqKChsb25n KikgKG4gKyBFVEhfSExFTiArIFNOV05NUF9ITEVOKSkNCisNCisvKj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0qLw0KKy8qIFNOV05NUCBmdW5jdGlvbnMg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICovDQorDQorDQorLyo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ki8NCisvKiBTTldOTVAgZnVuY3Rpb25zICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqLw0KK2ludCBzbndu bXBfaGFuZGxlX3RyYXAoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgdW5zaWdu ZWQgY2hhciAqZnJhbWUsIHVuc2lnbmVkIGxlbikNCit7DQorICAgIHN0cnVj dCBzbndubXBfaGVhZGVyICpoZWFkZXI9IChzdHJ1Y3Qgc253bm1wX2hlYWRl ciAqKWZyYW1lOw0KKyAgICAgDQorICAgIHN3aXRjaCAobnRvaGwoaGVhZGVy LT5vaWQpKQ0KKyAgICB7DQorICAgIGNhc2UgT0lEX05XTl9CU1NDSEFOR0VU UkFQOg0KKyAgICAgICAgc253bm1wX2dldChkZXYsIE9JRF9OV05fU01UQ1VS UkVOVFNTSUQpOw0KKyAgICAgICAgYnJlYWs7DQorICAgIGRlZmF1bHQ6DQor ICAgICAgICBwcmludGsoS0VSTl9JTkZPICIlczogU05XTk1QIFRSQVAgKG9p ZCAleClcbiIsDQorICAgICAgICAgICAgICAgZGV2LT5uYW1lLCBudG9obCho ZWFkZXItPm9pZCkpOw0KKyAgICB9DQorICAgIHJldHVybiAwOw0KK30NCisN CitpbnQgc253bm1wX2hhbmRsZV9yZXNwb25zZShzdHJ1Y3QgbmV0X2Rldmlj ZSAqZGV2LCB1bnNpZ25lZCBjaGFyICpmcmFtZSwgdW5zaWduZWQgbGVuKQ0K K3sNCisgICAgc3RydWN0IHNud25tcF9oZWFkZXIgKmhlYWRlcj0gKHN0cnVj dCBzbndubXBfaGVhZGVyICopZnJhbWU7DQorICAgIHN0cnVjdCBud25fcHJp dmF0ZSAqbHAgPSAoc3RydWN0IG53bl9wcml2YXRlKilkZXYtPnByaXY7DQor ICAgIGludCBpLCBhc3NvY2lhdGVkID0gMDsgDQorICAgIGludCBwcmludF9i c3NpZCA9IDA7DQorDQorI2lmIGRlZmluZWQoU05XTk1QX0RFQlVHKQ0KKyAg ICBwcmludGsoS0VSTl9JTkZPICIlczogU05XTk1QIHJlc3BvbnNlIHRvIDB4 JWx4IHJlY2VpdmVkOiAiLCBkZXYtPm5hbWUsDQorICAgICAgICAgICBudG9o bChoZWFkZXItPm9pZCkpOw0KKyAgICBmb3IgKGk9MDtpPGxlbjtpKyspDQor ICAgICAgICBwcmludGsoIiUwMnggIiwgZnJhbWVbaV0pOw0KKyAgICBwcmlu dGsoIlxuIik7DQorI2VuZGlmDQorDQorICAgIC8qIEFjcXVpcmUgdGhlIGxv Y2sgKi8NCisgICAgc3Bpbl9sb2NrKCZscC0+bG9jayk7DQorDQorICAgIHN3 aXRjaChudG9obChoZWFkZXItPm9pZCkpDQorICAgIHsNCisgICAgY2FzZSBP SURfTldOX1NNVENVUlJFTlRTU0lEOg0KKyAgICAgICAgaWYgKHN0cmNtcChT TldOTVBfU1RSSU5HKGZyYW1lKSwgbHAtPnNzaWQpID09IDApDQorICAgICAg ICB7DQorICAgICAgICAgICAgUFJJTlQoMCwgIiVzOiBDdXJyZW50IFNTSUQg aXMgJXNcbiIsIA0KKyAgICAgICAgICAgICAgIGRldi0+bmFtZSwgU05XTk1Q X1NUUklORyhmcmFtZSkgKTsNCisgICAgICAgICAgICBzbndubXBfZ2V0KGRl diwgT0lEX05XTl9TTVRDVVJSRU5UQlNTSUQpOw0KKyAgICAgICAgfQ0KKyAg ICAgICAgYnJlYWs7DQorICAgIGNhc2UgT0lEX05XTl9TTVRDVVJSRU5UQlNT SUQ6DQorICAgICAgICBwcmludF9ic3NpZCA9IDA7DQorICAgICAgICBmb3Ig KGk9MDtpPDY7aSsrKSB7DQorICAgICAgICAgICAgaWYgKGxwLT5ic3NpZFtp XSAhPSBmcmFtZVtpICsgRVRIX0hMRU4gKyBTTldOTVBfSExFTl0pIHsNCisg ICAgICAgICAgICAgICAgbHAtPmJzc2lkW2ldID0gZnJhbWVbaSArIEVUSF9I TEVOICsgU05XTk1QX0hMRU5dOw0KKyAgICAgICAgICAgICAgICBwcmludF9i c3NpZCA9IDE7DQorICAgICAgICAgICAgfQ0KKyAgICAgICAgICAgIGlmIChm cmFtZVtpICsgRVRIX0hMRU4gKyBTTldOTVBfSExFTl0gIT0gMCkNCisgICAg ICAgICAgICAgICAgYXNzb2NpYXRlZCA9IDE7DQorICAgICAgICB9DQorICAg ICAgICBpZiAocHJpbnRfYnNzaWQpIHsNCisgICAgICAgICAgICBwcmludGso S0VSTl9JTkZPICIlczogQ3VycmVudCBCU1NJRCBpcyAiLCBkZXYtPm5hbWUp Ow0KKyAgICAgICAgICAgIGZvciAoaT0wO2k8NjtpKyspIA0KKyAgICAgICAg ICAgICAgICBwcmludGsoIiUwMnglcyIsIGZyYW1lW2krIEVUSF9ITEVOICsg U05XTk1QX0hMRU5dLA0KKyAgICAgICAgICAgICAgICAgICAgICAgaSA8IDUg PyAiOiIgOiAiXG4iKTsNCisgICAgICAgIH0NCisgICAgICAgIGlmIChhc3Nv Y2lhdGVkKQ0KKyAgICAgICAgICAgIG5ldGlmX2NhcnJpZXJfb24oZGV2KTsN CisgICAgICAgIGVsc2UNCisgICAgICAgICAgICBuZXRpZl9jYXJyaWVyX29m ZihkZXYpOw0KKyAgICAgICAgYnJlYWs7DQorICAgIGNhc2UgT0lEX05XTl9T TVRDQVBBQklMSVRZSU5GTzoNCisJUFJJTlQoMSwgIiVzOiBDYXBhYmlsaXRp ZXMgKCUwOFgpXG4iLCBkZXYtPm5hbWUsIA0KKwkJbnRvaGwoU05XTk1QX0xP TkcoZnJhbWUpKSk7DQorICAgICAgICBscC0+Y2FwaW5mbyA9IG50b2hsKFNO V05NUF9MT05HKGZyYW1lKSk7DQorICAgICAgICBicmVhazsNCisgICAgY2Fz ZSBPSURfRE9UMTFfRE9UMTFERVNJUkVEU1NJRDoNCisgICAgICAgIFBSSU5U KDAsICIlczogUmVxdWVzdGVkIFNTSUQgKCVzKVxuIiwNCisgICAgICAgICAg ICAgICBkZXYtPm5hbWUsIFNOV05NUF9TVFJJTkcoZnJhbWUpKTsNCisgICAg ICAgIG1lbWNweShscC0+c3NpZCwgU05XTk1QX1NUUklORyhmcmFtZSksIDMy KTsNCisgICAgICAgIGJyZWFrOw0KKyAgICBjYXNlIE9JRF9ET1QxMV9ET1Qx MUFVVEhFTlRJQ0FUSU9OQUxHT1JJVEhNRU5BQkxFOg0KKyAgICAgICAgUFJJ TlQoMCwgIiVzOiBDdXJyZW50IGF1dGhlbnRpY2F0aW9uIGFsZ29yaXRobSAo JWQsJWQpXG4iLA0KKyAgICAgICAgICAgICAgIGRldi0+bmFtZSwgDQorICAg ICAgICAgICAgICAgbnRvaGwoU05XTk1QX0xPTkcoZnJhbWUpKSwNCisgICAg ICAgICAgICAgICBudG9obChTTldOTVBfTE9ORyhmcmFtZSArIHNpemVvZihs b25nKSkpKTsNCisgICAgICAgIGJyZWFrOw0KKyAgICBjYXNlIE9JRF9ET1Qx MV9ET1QxMVBSSVZBQ1lJTlZPS0VEOg0KKyAgICAgICAgUFJJTlQoMCwgIiVz OiBDdXJyZW50IHByaXZhY3kgc2V0dGluZyAoJWQpXG4iLA0KKyAgICAgICAg ICAgICAgIGRldi0+bmFtZSwNCisgICAgICAgICAgICAgICBudG9obChTTldO TVBfTE9ORyhmcmFtZSkpKTsNCisgICAgICAgIGJyZWFrOw0KKyAgICBjYXNl IE9JRF9ET1QxMV9ET1QxMUVYQ0xVREVVTkVOQ1JZUFRFRDoNCisgICAgICAg IFBSSU5UKDAsICIlczogRXhjbHVkaW5nIHVuZW5jcnlwdGVkIHRyYWZmaWMg KCVkKVxuIiwNCisgICAgICAgICAgICAgICBkZXYtPm5hbWUsDQorICAgICAg ICAgICAgICAgbnRvaGwoU05XTk1QX0xPTkcoZnJhbWUpKSk7DQorICAgICAg ICBicmVhazsNCisgICAgY2FzZSBPSURfTldOX1NNVFBVQkxJQ0tFWUVOQUJM RToNCisgICAgICAgIFBSSU5UKDAsICIlczogUHVibGljIGtleSBlbmFibGUg KCVkKVxuIiwNCisgICAgICAgICAgICAgICBkZXYtPm5hbWUsDQorICAgICAg ICAgICAgICAgbnRvaGwoU05XTk1QX0xPTkcoZnJhbWUpKSk7DQorICAgICAg ICBicmVhazsNCisgICAgY2FzZSBPSURfRE9UMTFfRE9UMTFXRVBERUZBVUxU S0VZSUQ6DQorICAgICAgICBQUklOVCgwLCAiJXM6IERlZmF1bHQga2V5IElE ICglZClcbiIsDQorICAgICAgICAgICAgICAgZGV2LT5uYW1lLA0KKyAgICAg ICAgICAgICAgIG50b2hsKFNOV05NUF9MT05HKGZyYW1lKSkpOw0KKyAgICAg ICAgYnJlYWs7DQorICAgIGNhc2UgT0lEX0RPVDExX0RPVDExV0VQREVGQVVM VEtFWToNCisjaWYgQ09ORklHX1BDTUNJQV9TV0FMTE9XX0RFQlVHDQorICAg ICAgICBpZiAoc3dhbGxvd19kZWJ1ZyA+IDApIHsNCisgICAgICAgICAgICBw cmludGsoS0VSTl9JTkZPICIlczogRGVmYXVsdCBrZXkocykgIiwgZGV2LT5u YW1lKTsNCisgICAgICAgICAgICBmb3IgKGk9MDtpPG50b2hsKGhlYWRlci0+ bGVuZ3RoKTtpKyspDQorICAgICAgICAgICAgICAgIHByaW50aygiJTAyeCAi LCBmcmFtZVtpICsgRVRIX0hMRU4gKyBTTldOTVBfSExFTl0pOw0KKyAgICAg ICAgICAgIHByaW50aygiXG4iKTsNCisgICAgICAgIH0NCisjZW5kaWYNCisg ICAgICAgIGJyZWFrOw0KKyAgICAvKiBSb2FtaW5nIE9JRCdzICovDQorICAg IGNhc2UgT0lEX05XTl9ST0FNVEFCTEVMRU5HVEg6DQorCWxwLT5yb2FtX3Rh YmxlLnNpemUgPQ0KKyAgICAgICAgICAgIG50b2hsKFNOV05NUF9MT05HKGZy YW1lKSk7DQorICAgICAgICBtb2RfdGltZXIoJmxwLT5yb2FtX3RpbWVyLCBq aWZmaWVzICsgSFogKiA1ICogNjApOw0KKyAgICAgICAgYnJlYWs7DQorICAg IGNhc2UgT0lEX05XTl9ST0FNU1NJRDoNCisJaWYgKGxwLT5pc181NTApDQor CXsNCisJICAgIGludCBzdGFydCwgZW5kLCBpbmRleCA9IDA7DQorCSAgICBz dGFydCA9IGVuZCA9IEVUSF9ITEVOICsgU05XTk1QX0hMRU47DQorCSAgICB3 aGlsZSAoZW5kIDwgbGVuKSB7DQorCQl3aGlsZSAoZnJhbWVbZW5kKytdKTsN CisJCW1lbWNweShscC0+cm9hbV90YWJsZS5lbnRyeVtpbmRleCsrXS5lc3Np ZCwgDQorCQkJZnJhbWUgKyBzdGFydCwgZW5kIC0gc3RhcnQpOw0KKwkJc3Rh cnQgPSBlbmQ7DQorCSAgICB9DQorCX0NCisJZWxzZQ0KKwl7DQorICAgICAg ICAgICAgZm9yIChpPTA7aTxscC0+cm9hbV90YWJsZS5zaXplO2krKykNCisg ICAgICAgICAgICB7DQorICAgICAgICAgICAgICAgIG1lbWNweShscC0+cm9h bV90YWJsZS5lbnRyeVtpXS5lc3NpZCwgDQorICAgICAgICAgICAgICAgICAg IGZyYW1lICsgRVRIX0hMRU4gKyBTTldOTVBfSExFTiArIGkgKiBJV19FU1NJ RF9NQVhfU0laRSwgDQorICAgICAgICAgICAgICAgICAgIElXX0VTU0lEX01B WF9TSVpFKTsNCisgICAgICAgICAgICAgICAgbHAtPnJvYW1fdGFibGUuZW50 cnlbaV0uZXNzaWRbSVdfRVNTSURfTUFYX1NJWkVdID0gJ1wwJzsNCisgICAg ICAgICAgICB9DQorCX0NCisgICAgICAgIGJyZWFrOw0KKyAgICBjYXNlIE9J RF9OV05fUk9BTUJTU0lEOg0KKyAgICAgICAgZm9yIChpPTA7aTxscC0+cm9h bV90YWJsZS5zaXplO2krKykNCisgICAgICAgIHsNCisgICAgICAgICAgICBt ZW1jcHkobHAtPnJvYW1fdGFibGUuZW50cnlbaV0uYnNzaWQsDQorICAgICAg ICAgICAgICAgICAgIGZyYW1lICsgRVRIX0hMRU4gKyBTTldOTVBfSExFTiAr IGkgKiA2LCA2KTsNCisgICAgICAgIH0NCisgICAgICAgIGJyZWFrOw0KKyAg ICBjYXNlIE9JRF9OV05fUk9BTUNBUEFCSUxJVFlJTkZPUk1BVElPTjoNCisg ICAgICAgIGZvciAoaT0wO2k8bHAtPnJvYW1fdGFibGUuc2l6ZTtpKyspDQor ICAgICAgICB7DQorICAgICAgICAgICAgbHAtPnJvYW1fdGFibGUuZW50cnlb aV0uY2FwaW5mbyA9IG50b2hsKA0KKyAgICAgICAgICAgICAgICBTTldOTVBf TE9ORyhmcmFtZSArIGkgKiBzaXplb2YobG9uZykpKTsNCisgICAgICAgIH0N CisgICAgICAgIGJyZWFrOw0KKyAgICBjYXNlIE9JRF9OV05fUk9BTVFVQUxJ VFk6DQorICAgICAgICBmb3IgKGk9MDtpPGxwLT5yb2FtX3RhYmxlLnNpemU7 aSsrKQ0KKyAgICAgICAgew0KKyAgICAgICAgICAgIGxwLT5yb2FtX3RhYmxl LmVudHJ5W2ldLnF1YWxpdHkgPSBudG9obCgNCisgICAgICAgICAgICAgICAg U05XTk1QX0xPTkcoZnJhbWUgKyBpICogc2l6ZW9mKGxvbmcpKSk7DQorICAg ICAgICB9DQorICAgICAgICBicmVhazsNCisgICAgY2FzZSBPSURfTldOX1JP QU1MT0FEOg0KKyAgICAgICAgZm9yIChpPTA7aTxscC0+cm9hbV90YWJsZS5z aXplO2krKykNCisgICAgICAgIHsNCisgICAgICAgICAgICBscC0+cm9hbV90 YWJsZS5lbnRyeVtpXS5sb2FkID0gbnRvaGwoDQorICAgICAgICAgICAgICAg IFNOV05NUF9MT05HKGZyYW1lICsgaSAqIHNpemVvZihsb25nKSkpOw0KKyAg ICAgICAgfQ0KKyAgICAgICAgYnJlYWs7DQorICAgIGNhc2UgT0lEX05XTl9S T0FNQ0hBTk5FTDoNCisgICAgICAgIGZvciAoaT0wO2k8bHAtPnJvYW1fdGFi bGUuc2l6ZTtpKyspDQorICAgICAgICB7DQorICAgICAgICAgICAgbHAtPnJv YW1fdGFibGUuZW50cnlbaV0uY2hhbm5lbCA9IG50b2hsKA0KKyAgICAgICAg ICAgICAgICBTTldOTVBfTE9ORyhmcmFtZSArIGkgKiBzaXplb2YobG9uZykp KTsNCisgICAgICAgIH0NCisgICAgICAgIGJyZWFrOw0KKyAgICBjYXNlIE9J RF9OV05fUk9BTUJTU1RZUEU6DQorICAgICAgICBmb3IgKGk9MDtpPGxwLT5y b2FtX3RhYmxlLnNpemU7aSsrKQ0KKyAgICAgICAgew0KKyAgICAgICAgICAg IGxwLT5yb2FtX3RhYmxlLmVudHJ5W2ldLmJzc3R5cGUgPSBudG9obCgNCisg ICAgICAgICAgICAgICAgU05XTk1QX0xPTkcoZnJhbWUgKyBpICogc2l6ZW9m KGxvbmcpKSk7DQorICAgICAgICB9DQorICAgICAgICBicmVhazsNCisgICAg Y2FzZSBPSURfTldOX1JPQU1BR0U6DQorICAgICAgICBmb3IgKGk9MDtpPGxw LT5yb2FtX3RhYmxlLnNpemU7aSsrKQ0KKyAgICAgICAgew0KKyAgICAgICAg ICAgIGxwLT5yb2FtX3RhYmxlLmVudHJ5W2ldLnJvYW1hZ2UgPSBudG9obCgN CisgICAgICAgICAgICAgICAgU05XTk1QX0xPTkcoZnJhbWUgKyBpICogc2l6 ZW9mKGxvbmcpKSk7DQorICAgICAgICB9DQorICAgICAgICBicmVhazsNCisg ICAgY2FzZSBPSURfTldOX1JPQU1CRUFDT05QRVJJT0Q6DQorICAgICAgICBm b3IgKGk9MDtpPGxwLT5yb2FtX3RhYmxlLnNpemU7aSsrKQ0KKyAgICAgICAg ew0KKyAgICAgICAgICAgIGxwLT5yb2FtX3RhYmxlLmVudHJ5W2ldLmJlYWNv bnBlcmlvZCA9IG50b2hsKA0KKyAgICAgICAgICAgICAgICBTTldOTVBfTE9O RyhmcmFtZSArIGkgKiBzaXplb2YobG9uZykpKTsNCisgICAgICAgIH0NCisg ICAgICAgIGJyZWFrOw0KKyAgICBjYXNlIE9JRF9OV05fUk9BTURUSU1QRVJJ T0Q6DQorICAgICAgICBmb3IgKGk9MDtpPGxwLT5yb2FtX3RhYmxlLnNpemU7 aSsrKQ0KKyAgICAgICAgew0KKyAgICAgICAgICAgIGxwLT5yb2FtX3RhYmxl LmVudHJ5W2ldLmR0aW1wZXJpb2QgPSBudG9obCgNCisgICAgICAgICAgICAg ICAgU05XTk1QX0xPTkcoZnJhbWUgKyBpICogc2l6ZW9mKGxvbmcpKSk7DQor ICAgICAgICB9DQorICAgICAgICBicmVhazsNCisgICAgY2FzZSBPSURfTldO X1JPQU1SQVRFUzoNCisgICAgICAgIGZvciAoaT0wO2k8bHAtPnJvYW1fdGFi bGUuc2l6ZTtpKyspDQorICAgICAgICB7DQorICAgICAgICAgICAgbWVtY3B5 KGxwLT5yb2FtX3RhYmxlLmVudHJ5W2ldLnJhdGVzLA0KKyAgICAgICAgICAg ICAgICAgICBmcmFtZSArIEVUSF9ITEVOICsgU05XTk1QX0hMRU4gKyBpICog NiwgNik7DQorICAgICAgICB9DQorICAgICAgICBicmVhazsNCisgICAgZGVm YXVsdDoNCisgICAgICAgIHByaW50ayhLRVJOX0lORk8gIiVzOiBSZWNlaXZl ZCB1bmtub3duIG9pZCAlWCB3aXRoIGxlbmd0aCAlZFxuIiwNCisgICAgICAg ICAgICAgICBkZXYtPm5hbWUsIG50b2hsKGhlYWRlci0+b2lkKSwgbnRvaGwo aGVhZGVyLT5sZW5ndGgpKTsNCisgICAgICAgIGJyZWFrOw0KKyAgICB9DQor ICAgIC8qIFJlbGVhc2UgdGhlIGxvY2sgKi8NCisgICAgc3Bpbl91bmxvY2so JmxwLT5sb2NrKTsNCisgICAgcmV0dXJuIDA7DQorfQ0KKw0KKy8qDQorICog VGhpcyBmdW5jdGlvbiByZS1zZW5kcyBmYWlsZWQgU05XTk1QIGdldCBwYWNr YWdlcywgYWZ0ZXIgZml4aW5nIHRoZW0gdXAuDQorICovDQoraW50IHNud25t cF9oYW5kbGVfZXJyb3Ioc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgdW5zaWdu ZWQgY2hhciAqZnJhbWUsIHVuc2lnbmVkIGxlbikNCit7DQorICAgIHN0cnVj dCBza19idWZmICpza2I7DQorICAgIHN0cnVjdCBzbndubXBfaGVhZGVyICpo ZWFkZXI9IChzdHJ1Y3Qgc253bm1wX2hlYWRlciopZnJhbWU7DQorICAgIHVu c2lnbmVkIHBrdF9sZW4gPSAwLCBoZWFkZXJfbGVuID0gMDsNCisjaWYgZGVm aW5lZChTTldOTVBfREVCVUcpDQorICAgIGludCBpOw0KKyNlbmRpZg0KKw0K KyAgICBpZiAoKG50b2hsKGhlYWRlci0+bGVuZ3RoKSA9PSAweDVhNWE1YTVh KSB8fA0KKwkobnRvaGwoaGVhZGVyLT5sZW5ndGgpID09IDB4MDAwMDAwMDAp KQ0KKyAgICB7DQorICAgICAgICBzd2l0Y2gobnRvaGwoaGVhZGVyLT5vaWQp KQ0KKyAgICAgICAgew0KKyAgICAgICAgY2FzZSBPSURfTldOX1NNVENVUlJF TlRTU0lEOg0KKyAgICAgICAgICAgIGhlYWRlci0+bGVuZ3RoID0gaHRvbmwo MzIpOw0KKyAgICAgICAgICAgIGJyZWFrOw0KKyAgICAgICAgY2FzZSBPSURf TldOX1NNVENVUlJFTlRCU1NJRDoNCisgICAgICAgICAgICBoZWFkZXItPmxl bmd0aCA9IGh0b25sKDYpOw0KKyAgICAgICAgICAgIGJyZWFrOw0KKwljYXNl IE9JRF9OV05fUk9BTVRBQkxFTEVOR1RIOg0KKwkgICAgaGVhZGVyLT5sZW5n dGggPSBodG9ubCg0KTsNCisJICAgIGJyZWFrOw0KKwljYXNlIE9JRF9OV05f Uk9BTVNTSUQ6DQorCSAgICBoZWFkZXItPmxlbmd0aCA9IGh0b25sKDEyOCk7 DQorCSAgICBicmVhazsNCisJY2FzZSBPSURfTldOX1JPQU1CU1NJRDoNCisJ ICAgIGhlYWRlci0+bGVuZ3RoID0gaHRvbmwoNDgpOw0KKwkgICAgYnJlYWs7 DQorICAgICAgICBjYXNlIE9JRF9OV05fUk9BTUJTU1RZUEU6DQorICAgICAg ICAgICAgaGVhZGVyLT5sZW5ndGggPSBodG9ubCgzMik7DQorICAgICAgICAg ICAgYnJlYWs7DQorCWNhc2UgT0lEX05XTl9ST0FNQ0FQQUJJTElUWUlORk9S TUFUSU9OOg0KKwkgICAgaGVhZGVyLT5sZW5ndGggPSBodG9ubCgxNik7DQor CSAgICBicmVhazsNCisJY2FzZSBPSURfTldOX1JPQU1BR0U6DQorCSAgICBo ZWFkZXItPmxlbmd0aCA9IGh0b25sKDMyKTsNCisJICAgIGJyZWFrOw0KKwlj YXNlIE9JRF9OV05fUk9BTUNIQU5ORUw6DQorCSAgICBoZWFkZXItPmxlbmd0 aCA9IGh0b25sKDMyKTsNCisJICAgIGJyZWFrOw0KKwljYXNlIE9JRF9OV05f Uk9BTVFVQUxJVFk6DQorCSAgICBoZWFkZXItPmxlbmd0aCA9IGh0b25sKDMy KTsNCisJICAgIGJyZWFrOw0KKwljYXNlIE9JRF9OV05fUk9BTUxPQUQ6DQor CSAgICBoZWFkZXItPmxlbmd0aCA9IGh0b25sKDMyKTsNCisJICAgIGJyZWFr Ow0KKwljYXNlIE9JRF9OV05fUk9BTUJFQUNPTlBFUklPRDoNCisgICAgICAg ICAgICBoZWFkZXItPmxlbmd0aCA9IGh0b25sKDMyKTsNCisgICAgICAgICAg ICBicmVhazsNCisJY2FzZSBPSURfTldOX1JPQU1EVElNUEVSSU9EOg0KKyAg ICAgICAgICAgIGhlYWRlci0+bGVuZ3RoID0gaHRvbmwoMzIpOw0KKyAgICAg ICAgICAgIGJyZWFrOw0KKwljYXNlIE9JRF9OV05fUk9BTVJBVEVTOg0KKyAg ICAgICAgICAgIGhlYWRlci0+bGVuZ3RoID0gaHRvbmwoNDgpOw0KKyAgICAg ICAgICAgIGJyZWFrOw0KKyAgICAgICAgZGVmYXVsdDoNCisJICAgIHByaW50 ayhLRVJOX0lORk8gInN3YWxsb3dfY3M6IFVuc3VwcG9ydGVkIE9JRCgweCV4 KVxuIiwNCisJCW50b2hsKGhlYWRlci0+b2lkKSk7DQorICAgICAgICAgICAg cmV0dXJuIC1FT1BOT1RTVVBQOw0KKyAgICAgICAgfQ0KKyAgICB9DQorDQor ICAgIGhlYWRlcl9sZW4gPSBFVEhfSExFTiArIDEyOw0KKyAgICBwa3RfbGVu ID0gaGVhZGVyX2xlbiArIG50b2hsKGhlYWRlci0+bGVuZ3RoKTsNCisNCisj aWYgZGVmaW5lZChTTldOTVBfREVCVUcpDQorICAgIHByaW50ayhLRVJOX0lO Rk8gIiVzOiBSZXNlbmRpbmcgJWQgYnl0ZXMuXG4iLCBkZXYtPm5hbWUsIHBr dF9sZW4pOw0KKyNlbmRpZg0KKw0KKyAgICBtZW1jcHkoaGVhZGVyLT5oX2Rl c3QsIGRldi0+ZGV2X2FkZHIsIEVUSF9BTEVOKTsNCisgICAgbWVtY3B5KGhl YWRlci0+aF9zb3VyY2UsIGRldi0+ZGV2X2FkZHIsIEVUSF9BTEVOKTsNCisg ICAgaGVhZGVyLT5oX3Byb3RvID0gX19jb25zdGFudF9odG9ucyhFVEhfUF9T TldOTVApOw0KKyAgICBoZWFkZXItPnZlcnNpb24gPSAxOw0KKyAgICBoZWFk ZXItPm9wZXJhdGlvbiA9IFNOV05NUF9HRVQ7DQorDQorICAgIGlmICgoc2ti ID0gZGV2X2FsbG9jX3NrYihwa3RfbGVuICsgNSkpID09IE5VTEwpIHsNCisg ICAgICAgIHByaW50ayhLRVJOX0lORk8gIiVzOiBjb3VsZG4ndCBhbGxvY2F0 ZSBhbiBza19idWZmIG9mIg0KKyAgICAgICAgICAgICAgICIgc2l6ZSAlZCBp biBzbndubXBfaGFuZGxlX2Vycm9yKClcbiIsIGRldi0+bmFtZSwgcGt0X2xl biArIDUpOw0KKyAgICAgICAgcmV0dXJuIC1FTk9NRU07DQorICAgIH0NCisN CisgICAgbWVtY3B5KHNrYl9wdXQoc2tiLCBoZWFkZXJfbGVuKSwgZnJhbWUs IGhlYWRlcl9sZW4pOw0KKyAgICBtZW1zZXQoc2tiX3B1dChza2IsIG50b2hs KGhlYWRlci0+bGVuZ3RoKSksIDAsIG50b2hsKGhlYWRlci0+bGVuZ3RoKSk7 DQorDQorICAgIHNrYi0+ZGV2ID0gZGV2Ow0KKyAgICBza2ItPnByb3RvY29s ID0gX19jb25zdGFudF9odG9ucyhFVEhfUF9TTldOTVApOw0KKyAgICBza2It Pm5oLnJhdyA9IHNrYi0+ZGF0YTsNCisgICAgaWYgKGRldi0+aGFyZF9oZWFk ZXIpDQorICAgICAgICBza2ItPm5oLnJhdyArPSBkZXYtPmhhcmRfaGVhZGVy X2xlbjsNCisNCisgICAgcmV0dXJuIGRldl9xdWV1ZV94bWl0KHNrYik7DQor fQ0KKw0KKy8qDQorICogR2V0IGFsbCB2YWx1ZXMgZm9yIGEgc3BlY2lmaWMg T0lELg0KKyAqIFdlIHNlbmQgYSBwYWNrZXQgdG8gZmluZCBvdXQgaG93IGxh cmdlIHRoZSBidWZmZXIgc2hvdWxkIGJlOw0KKyAqIHRoZSBwcm9jZXNzaW5n IHBhcnQgd2lsbCBtYWtlIHN1cmUgdGhlIHJlcXVlc3QgZ2V0cyBzZW50IG91 dCBhZ2Fpbi4NCisgKi8NCitpbnQgc253bm1wX2dldChzdHJ1Y3QgbmV0X2Rl dmljZSAqZGV2LCB1bnNpZ25lZCBsb25nIG9pZCkNCit7DQorICAgIHN0cnVj dCBza19idWZmICpza2I7DQorICAgIHN0cnVjdCBzbndubXBfaGVhZGVyICpo ZWFkZXI7DQorICAgIHVuc2lnbmVkIGNoYXIgKnBhY2tldDsNCisNCisgICAg dW5zaWduZWQgaW50IHBrdF9sZW4gPSAwOw0KKyNpZiBkZWZpbmVkKFNOV05N UF9ERUJVRykNCisgICAgaW50IGk7DQorI2VuZGlmDQorDQorI2lmIGRlZmlu ZWQoU05XTk1QX0RFQlVHKQ0KKyAgICBwcmludGsoS0VSTl9JTkZPICIlczog R2V0dGluZyBPSUQgMHglbHhcbiIsIGRldi0+bmFtZSwgb2lkKTsNCisjZW5k aWYNCisNCisgICAgcGt0X2xlbiA9IEVUSF9ITEVOICsgU05XTk1QX0hMRU47 IA0KKw0KKyAgICBpZiAoKHBhY2tldCA9ICh1bnNpZ25lZCBjaGFyKikgDQor ICAgICAgICAgICAgICAgICAga21hbGxvYyhwa3RfbGVuLCBHRlBfQVRPTUlD KSkgPT0gTlVMTCkgew0KKyAgICAgICAgcHJpbnRrKEtFUk5fSU5GTyAic253 bm1wX2dldDogTG93IG9uIG1lbW9yeS5cbiIpOw0KKyAgICAgICAgcmV0dXJu IC1FTk9NRU07DQorICAgIH0NCisgICAgbWVtc2V0KHBhY2tldCwgMCwgcGt0 X2xlbik7DQorICAgIGhlYWRlciA9IChzdHJ1Y3Qgc253bm1wX2hlYWRlciAq KXBhY2tldDsNCisNCisgICAgLyogRmlsbCBpbiB0aGUgZXRoZXIgcGFja2V0 IHRvIHNlbmQgdXAgdG8gdGhlIGNhcmQgKi8NCisgICAgbWVtY3B5KGhlYWRl ci0+aF9kZXN0LCBkZXYtPmRldl9hZGRyLCBFVEhfQUxFTik7DQorICAgIG1l bWNweShoZWFkZXItPmhfc291cmNlLCBkZXYtPmRldl9hZGRyLCBFVEhfQUxF Tik7DQorICAgIGhlYWRlci0+aF9wcm90byA9IF9fY29uc3RhbnRfaHRvbnMo RVRIX1BfU05XTk1QKTsNCisgICAgaGVhZGVyLT52ZXJzaW9uID0gMHgwMTsN CisgICAgaGVhZGVyLT5vcGVyYXRpb24gPSBTTldOTVBfR0VUOw0KKyAgICBo ZWFkZXItPm9pZCA9IGh0b25sKG9pZCk7DQorICAgIGhlYWRlci0+aW5kZXgg PSAwOw0KKyAgICBoZWFkZXItPmZsYWdzID0gMDsNCisgICAgaGVhZGVyLT5s ZW5ndGggPSAwOw0KKw0KKyAgICAvKiBBbGxvY2F0ZSBhbiBza19idWZmZXIg Ki8NCisgICAgaWYgKChza2IgPSBkZXZfYWxsb2Nfc2tiKHBrdF9sZW4gKyBk ZXYtPmhhcmRfaGVhZGVyX2xlbiArIDE1KSkgPT0gTlVMTCkgew0KKyAgICAg ICAga2ZyZWUocGFja2V0KTsNCisgICAgICAgIHByaW50ayhLRVJOX0lORk8g IiVzOiBjb3VsZG4ndCBhbGxvY2F0ZSBhbiBza19idWZmIG9mIg0KKyAgICAg ICAgICAgICAgICIgc2l6ZSAlZCBpbiBzbndubXBfZ2V0KClcbiIsIGRldi0+ bmFtZSwgcGt0X2xlbik7DQorICAgICAgICByZXR1cm4gLUVOT01FTTsNCisg ICAgfQ0KKw0KKyAgICBza2JfcmVzZXJ2ZShza2IsIDIpOw0KKw0KKyAgICBt ZW1jcHkoc2tiX3B1dChza2IsIHBrdF9sZW4pLCBwYWNrZXQsIHBrdF9sZW4p Ow0KKw0KKyAgICBza2ItPmRldiA9IGRldjsNCisgICAgc2tiLT5wcm90b2Nv bCA9IF9fY29uc3RhbnRfaHRvbnMoRVRIX1BfU05XTk1QKTsNCisgICAgc2ti LT5uaC5yYXcgPSBza2ItPmRhdGE7DQorICAgIGlmIChkZXYtPmhhcmRfaGVh ZGVyKQ0KKyAgICAgICAgc2tiLT5uaC5yYXcgKz0gZGV2LT5oYXJkX2hlYWRl cl9sZW47DQorDQorICAgIGlmIChza2ItPmxlbiAhPSBwa3RfbGVuKQ0KKyAg ICAgICAgcHJpbnRrKEtFUk5fSU5GTyAiJXM6IEVycm9yISBza2ItPmxlbiAh PSBwa3RfbGVuXG4iLCBkZXYtPm5hbWUpOw0KKw0KKyNpZiBkZWZpbmVkKFNO V05NUF9ERUJVRykNCisgICAgcHJpbnRrKEtFUk5fSU5GTyAiJXM6IFNlbmRp bmcgU05XTk1QIGdldDogIiwgZGV2LT5uYW1lKTsNCisgICAgZm9yIChpID0g MDsgaSA8IHBrdF9sZW47IGkrKykNCisgICAgICAgIHByaW50aygiJTAyeCAi LCAoKHVuc2lnbmVkIGNoYXIqKXBhY2tldClbaV0pOw0KKyAgICBwcmludGso IlxuIik7DQorI2VuZGlmDQorDQorICAgIGtmcmVlKHBhY2tldCk7DQorDQor ICAgIHJldHVybiBkZXZfcXVldWVfeG1pdChza2IpOw0KK30NCisNCitpbnQg c253bm1wX3NldChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCB1bnNpZ25lZCBs b25nIG9pZCwgdW5zaWduZWQgY2hhciAqZGF0YSwgdW5zaWduZWQgbGVuKQ0K K3sNCisgICAgc3RydWN0IHNrX2J1ZmYgKnNrYjsNCisgICAgc3RydWN0IHNu d25tcF9oZWFkZXIgKmhlYWRlcjsNCisgICAgdW5zaWduZWQgY2hhciAqcGFj a2V0Ow0KKw0KKyAgICB1bnNpZ25lZCBpbnQgcGt0X2xlbiA9IDA7DQorI2lm IGRlZmluZWQoU05XTk1QX0RFQlVHKQ0KKyAgICBpbnQgaTsNCisjZW5kaWYN CisNCisgICAgcGt0X2xlbiA9IEVUSF9ITEVOICsgU05XTk1QX0hMRU4gKyBs ZW47DQorDQorI2lmIGRlZmluZWQoU05XTk1QX0RFQlVHKQ0KKyAgICBwcmlu dGsoS0VSTl9JTkZPICIlczogU2V0dGluZyBPSUQgMHglbHhcbiIsIGRldi0+ bmFtZSwgb2lkKTsNCisjZW5kaWYNCisNCisgICAgaWYgKChwYWNrZXQgPSAo dW5zaWduZWQgY2hhciopa21hbGxvYyhwa3RfbGVuLCBHRlBfQVRPTUlDKSkg PT0gTlVMTCkgew0KKyAgICAgICAgcHJpbnRrKEtFUk5fSU5GTyAiJXM6IFVu YWJsZSB0byBhbGxvY2F0ZSAlZCBieXRlcyBpbiBzbndubXBfc2V0KClcbiIs DQorICAgICAgICAgICAgICAgZGV2LT5uYW1lLCBwa3RfbGVuKTsNCisgICAg ICAgIHJldHVybiAtRU5PTUVNOw0KKyAgICB9DQorICAgIG1lbXNldChwYWNr ZXQsIDAsIHBrdF9sZW4pOw0KKyAgICBoZWFkZXIgPSAoc3RydWN0IHNud25t cF9oZWFkZXIgKilwYWNrZXQ7DQorDQorICAgIC8qIEZpbGwgaW4gdGhlIGV0 aGVybmV0IGhlYWRlciAqLw0KKyAgICBtZW1jcHkoaGVhZGVyLT5oX2Rlc3Qs IGRldi0+ZGV2X2FkZHIsIEVUSF9BTEVOKTsNCisgICAgbWVtY3B5KGhlYWRl ci0+aF9zb3VyY2UsIGRldi0+ZGV2X2FkZHIsIEVUSF9BTEVOKTsNCisgICAg aGVhZGVyLT5oX3Byb3RvID0gX19jb25zdGFudF9odG9ucyhFVEhfUF9TTldO TVApOw0KKyAgICAvKiBGaWxsIGluIHRoZSBTTldOTVAgaGVhZGVyICovDQor ICAgIGhlYWRlci0+dmVyc2lvbiA9IDE7DQorICAgIGhlYWRlci0+b3BlcmF0 aW9uID0gU05XTk1QX1NFVDsNCisgICAgaGVhZGVyLT5vaWQgPSBodG9ubChv aWQpOw0KKyAgICBoZWFkZXItPmxlbmd0aCA9IGh0b25sKGxlbik7DQorDQor ICAgIC8qIENvcHkgaW4gdGhlIGRhdGEgKi8NCisgICAgbWVtY3B5KHBhY2tl dCArIEVUSF9ITEVOICsgU05XTk1QX0hMRU4sICBkYXRhLCBsZW4pOw0KKw0K KyAgICAvKiBBbGxvY2F0ZSBhbiBza19idWZmZXIgKi8NCisgICAgaWYgKChz a2IgPSBkZXZfYWxsb2Nfc2tiKHBrdF9sZW4gKyBkZXYtPmhhcmRfaGVhZGVy X2xlbiArIDE1KSkgPT0gTlVMTCkgew0KKyAgICAgICAga2ZyZWUocGFja2V0 KTsNCisgICAgICAgIHByaW50ayhLRVJOX0lORk8gIiVzOiBjb3VsZG4ndCBh bGxvY2F0ZSBhbiBza19idWZmIG9mIg0KKyAgICAgICAgICAgICAgICIgc2l6 ZSAlZCBpbiBzbndubXBfc2V0KClcbiIsIGRldi0+bmFtZSwgcGt0X2xlbik7 DQorICAgICAgICByZXR1cm4gLUVOT01FTTsNCisgICAgfQ0KKw0KKyAgICBz a2JfcmVzZXJ2ZShza2IsIDIpOw0KKw0KKyAgICBtZW1jcHkoc2tiX3B1dChz a2IsIHBrdF9sZW4pLCBwYWNrZXQsIHBrdF9sZW4pOw0KKw0KKyAgICBza2It PmRldiA9IGRldjsNCisgICAgc2tiLT5wcm90b2NvbCA9IF9fY29uc3RhbnRf aHRvbnMoRVRIX1BfU05XTk1QKTsNCisgICAgc2tiLT5uaC5yYXcgPSBza2It PmRhdGE7DQorICAgIGlmIChkZXYtPmhhcmRfaGVhZGVyKQ0KKyAgICAgICAg c2tiLT5uaC5yYXcgKz0gZGV2LT5oYXJkX2hlYWRlcl9sZW47DQorDQorICAg IGlmIChza2ItPmxlbiAhPSBwa3RfbGVuKQ0KKyAgICAgICAgcHJpbnRrKEtF Uk5fSU5GTyAiJXM6IEVycm9yISBza2ItPmxlbiAhPSBwa3RfbGVuXG4iLCBk ZXYtPm5hbWUpOw0KKw0KKyNpZiBkZWZpbmVkKFNOV05NUF9ERUJVRykNCisg ICAgcHJpbnRrKEtFUk5fSU5GTyAiJXM6IFNlbmRpbmcgU05XTk1QIHNldDog IiwgZGV2LT5uYW1lKTsNCisgICAgZm9yIChpPTA7aTxwa3RfbGVuO2krKykN CisgICAgICAgIHByaW50aygiJTAyeCAiLCBwYWNrZXRbaV0pOw0KKyAgICBw cmludGsoIlxuIik7DQorI2VuZGlmDQorDQorICAgIGtmcmVlKHBhY2tldCk7 DQorDQorICAgIHJldHVybiBkZXZfcXVldWVfeG1pdChza2IpOw0KK30NCisN CisNCitpbnQgc253bm1wX3Byb2Nlc3Moc3RydWN0IG5ldF9kZXZpY2UgKmRl diwgdW5zaWduZWQgY2hhciAqZnJhbWUsIHVuc2lnbmVkIGxlbikNCit7DQor ICAgIHN0cnVjdCBzbndubXBfaGVhZGVyKiBoZWFkZXIgPSAoc3RydWN0IHNu d25tcF9oZWFkZXIqKWZyYW1lOw0KKw0KKyAgICBpZiAoaGVhZGVyLT5oX3By b3RvICE9IF9fY29uc3RhbnRfaHRvbnMoRVRIX1BfU05XTk1QKSkgew0KKyAg ICAgICAgcHJpbnRrKEtFUk5fSU5GTyAiJXM6IFdyb25nIGV0aGVyIHR5cGUo MHgleCkgaW4gcHJvY2Vzc19zbndubXAuXG4iLA0KKyAgICAgICAgICAgICAg IGRldi0+bmFtZSwgbnRvaHMoaGVhZGVyLT5oX3Byb3RvKSk7DQorICAgICAg ICByZXR1cm4gLUVPUE5PVFNVUFA7DQorICAgIH0NCisNCisgICAgc3dpdGNo IChoZWFkZXItPm9wZXJhdGlvbikgew0KKyAgICBjYXNlIFNOV05NUF9FUlJP UjoNCisgICAgICAgIHJldHVybiBzbndubXBfaGFuZGxlX2Vycm9yKGRldiwg ZnJhbWUsIGxlbik7DQorICAgIGNhc2UgU05XTk1QX1RSQVA6DQorICAgICAg ICByZXR1cm4gc253bm1wX2hhbmRsZV90cmFwKGRldiwgZnJhbWUsIGxlbik7 DQorICAgIGNhc2UgU05XTk1QX1JFU1BPTlNFOg0KKyAgICAgICAgcmV0dXJu IHNud25tcF9oYW5kbGVfcmVzcG9uc2UoZGV2LCBmcmFtZSwgbGVuKTsNCisg ICAgY2FzZSBTTldOTVBfR0VUOg0KKyAgICBjYXNlIFNOV05NUF9TRVQ6DQor ICAgICAgICBwcmludGsoS0VSTl9JTkZPICIlczogVW5leHBlY3RlZCBvcGVy YXRpb24gcmVjZWl2ZWQgKCVkKVxuIiwNCisgICAgICAgICAgICAgICBkZXYt Pm5hbWUsIGhlYWRlci0+b3BlcmF0aW9uKTsNCisgICAgICAgIGJyZWFrOw0K KyAgICBkZWZhdWx0Og0KKyAgICAgICAgcHJpbnRrKEtFUk5fSU5GTyAiJXM6 IERvbid0IGtub3cgaG93IHRvIGhhbmRsZSBvcGVyYXRpb24gKCVkKVxuIiwN CisgICAgICAgICAgICAgICBkZXYtPm5hbWUsIGhlYWRlci0+b3BlcmF0aW9u KTsNCisgICAgICAgIGJyZWFrOw0KKyAgICB9DQorDQorICAgIHJldHVybiAt RU9QTk9UU1VQUDsNCit9DQpkaWZmIC11TnIgbGludXgtMi40LjMtYWMxMy5v cmlnL2RyaXZlcnMvbmV0L3BjbWNpYS9zbndubXAuaCBsaW51eC0yLjQuMy1h YzEzL2RyaXZlcnMvbmV0L3BjbWNpYS9zbndubXAuaA0KLS0tIGxpbnV4LTIu NC4zLWFjMTMub3JpZy9kcml2ZXJzL25ldC9wY21jaWEvc253bm1wLmgJVGh1 IEphbiAgMSAwMTowMDowMCAxOTcwDQorKysgbGludXgtMi40LjMtYWMxMy9k cml2ZXJzL25ldC9wY21jaWEvc253bm1wLmgJVGh1IEZlYiAgOCAxMTozMDoz MCAyMDAxDQpAQCAtMCwwICsxLDIyOCBAQA0KKyNpZm5kZWYgU05XTk1QX0gN CisjZGVmaW5lIFNOV05NUF9IDQorDQorLyogU05XTk1QIEZ1bmN0aW9ucyAq Lw0KK2V4dGVybiBpbnQgc253bm1wX3Byb2Nlc3Moc3RydWN0IG5ldF9kZXZp Y2UgKmRldiwgdW5zaWduZWQgY2hhciAqZnJhbWUsIHVuc2lnbmVkIGxlbik7 DQorZXh0ZXJuIGludCBzbndubXBfaGFuZGxlX3RyYXAoc3RydWN0IG5ldF9k ZXZpY2UgKmRldiwgdW5zaWduZWQgY2hhciAqZnJhbWUsIHVuc2lnbmVkIGxl bik7DQorZXh0ZXJuIGludCBzbndubXBfaGFuZGxlX3Jlc3BvbnNlKHN0cnVj dCBuZXRfZGV2aWNlICpkZXYsIHVuc2lnbmVkIGNoYXIgKmZyYW1lLCB1bnNp Z25lZCBsZW4pOw0KK2V4dGVybiBpbnQgc253bm1wX2hhbmRsZV9lcnJvcihz dHJ1Y3QgbmV0X2RldmljZSAqZGV2LCB1bnNpZ25lZCBjaGFyICpmcmFtZSwg dW5zaWduZWQgbGVuKTsNCitleHRlcm4gaW50IHNud25tcF9nZXQoc3RydWN0 IG5ldF9kZXZpY2UgKmRldiwgdW5zaWduZWQgbG9uZyBvaWQpOw0KK2V4dGVy biBpbnQgc253bm1wX3NldChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCB1bnNp Z25lZCBsb25nIG9pZCwgdW5zaWduZWQgY2hhciAqZGF0YSwgdW5zaWduZWQg bGVuKTsNCisNCisvKiBTTldOTVAgRXRoZXIgdHlwZSAqLw0KKyNkZWZpbmUg RVRIX1BfU05XTk1QCTB4ODgyOA0KKw0KKy8qIFNOV05NUCBoZWFkZXIgbGVu Z3RoICovDQorI2RlZmluZSBTTldOTVBfSExFTgkxMg0KKw0KKy8qIFNOV05N UCBPcGVyYXRpb25zICovDQorI2RlZmluZSBTTldOTVBfR0VUCTANCisjZGVm aW5lIFNOV05NUF9TRVQJMQ0KKyNkZWZpbmUgU05XTk1QX1JFU1BPTlNFCTIN CisjZGVmaW5lIFNOV05NUF9FUlJPUgkzDQorI2RlZmluZSBTTldOTVBfVFJB UAk0DQorDQorc3RydWN0IHNud25tcF9oZWFkZXIgew0KKyAgICB1bnNpZ25l ZCBjaGFyIGhfZGVzdFtFVEhfQUxFTl07DQorICAgIHVuc2lnbmVkIGNoYXIg aF9zb3VyY2VbRVRIX0FMRU5dOw0KKyAgICB1bnNpZ25lZCBzaG9ydCBoX3By b3RvOw0KKyAgICB1bnNpZ25lZCBjaGFyIHZlcnNpb247DQorICAgIHVuc2ln bmVkIGNoYXIgb3BlcmF0aW9uOw0KKyAgICB1bnNpZ25lZCBsb25nIG9pZCBf X2F0dHJpYnV0ZV9fICgocGFja2VkKSk7DQorICAgIHVuc2lnbmVkIGNoYXIg aW5kZXg7DQorICAgIHVuc2lnbmVkIGNoYXIgZmxhZ3M7DQorICAgIHVuc2ln bmVkIGxvbmcgbGVuZ3RoIF9fYXR0cmlidXRlX18gKChwYWNrZWQpKTsNCit9 Ow0KKw0KKy8qIFNOV05NUCBFbmNyeXB0aW9uICovDQorI2RlZmluZSBTTldO TVBfS0VZX1NJWkUJCTUNCisjZGVmaW5lIFNOV05NUF9NQVhfS0VZUwkJNA0K KyNkZWZpbmUgU05XTk1QX01BWF9LRVlfU0laRQlTTldOTVBfTUFYX0tFWVMg KiBTTldOTVBfS0VZX1NJWkUNCisNCisNCisvKiBPSUQgZGVmaW5lcyAqLw0K KyNkZWZpbmUgT0lEX0RPVDExX0RPVDExU1RBVElPTklEICAgICAgICAgICAg ICAgICAJMHhGRjAxMDEwMAkvKiBXICovDQorI2RlZmluZSBPSURfRE9UMTFf RE9UMTFNRURJVU1PQ0NVUEFOQ1lMSU1JVCAgCQkweEZGMDEwMTAxCS8qIFcg Ki8NCisjZGVmaW5lIE9JRF9ET1QxMV9ET1QxMUNGUE9MTEFCTEUgICAgICAg ICAgICAgICAgCTB4RkYwMTAxMDINCisjZGVmaW5lIE9JRF9ET1QxMV9ET1Qx MUNGUFBFUklPRCAgICAgICAgICAgIAkJMHhGRjAxMDEwMyANCisjZGVmaW5l IE9JRF9ET1QxMV9ET1QxMUNGUE1BWERVUkFUSU9OICAgICAgIAkJMHhGRjAx MDEwNA0KKyNkZWZpbmUgT0lEX0RPVDExX0RPVDExQVVUSEVOVElDQVRJT05S RVNQT05TRVRJTUVPVVQJMHhGRjAxMDEwNQkvKiBXICovDQorI2RlZmluZSBP SURfRE9UMTFfRE9UMTFQUklWQUNZT1BUSU9OSU1QTEVNRU5URUQgIAkweEZG MDEwMTA2DQorI2RlZmluZSBPSURfRE9UMTFfRE9UMTFQT1dFUk1BTkFHRU1F TlRNT0RFICAJCTB4RkYwMTAxMDcJLyogVyAqLw0KKy8qIGFhbnZyYWdlbiBF U1NJRCAqLw0KKyNkZWZpbmUgT0lEX0RPVDExX0RPVDExREVTSVJFRFNTSUQg ICAgICAgICAgICAgICAJMHhGRjAxMDEwOAkvKiBXICovDQorI2RlZmluZSBP SURfRE9UMTFfRE9UMTFERVNJUkVEQlNTVFlQRSAgICAgICAJCTB4RkYwMTAx MDkJLyogVyAqLw0KKyNkZWZpbmUgT0lEX0RPVDExX0RPVDExT1BFUkFUSU9O QUxSQVRFU0VUICAgICAgICAJMHhGRjAxMDEwQQkvKiBXICovDQorI2RlZmlu ZSBPSURfRE9UMTFfRE9UMTFCRUFDT05QRVJJT0QgICAgICAgICAgICAgIAkw eEZGMDEwMTBCCS8qIFcgKi8NCisjZGVmaW5lIE9JRF9ET1QxMV9ET1QxMURU SU1QRVJJT0QgICAgICAgICAgICAgICAgCTB4RkYwMTAxMEMJLyogVyAqLw0K KyNkZWZpbmUgT0lEX0RPVDExX0RPVDExQVNTT0NJQVRJT05SRVNQT05TRVRJ TUVPVVQgCTB4RkYwMTAxMEQJLyogVyAqLw0KKyNkZWZpbmUgT0lEX0RPVDEx X0RPVDExRElTQVNTT0NJQVRFUkVBU09OICAgICAgICAJMHhGRjAxMDEwRSAg DQorI2RlZmluZSBPSURfRE9UMTFfRE9UMTFESVNBU1NPQ0lBVEVTVEFUSU9O ICAJCTB4RkYwMTAxMEYNCisjZGVmaW5lIE9JRF9ET1QxMV9ET1QxMURFQVVU SEVOVElDQVRFUkVBU09OICAJCTB4RkYwMTAxMTANCisjZGVmaW5lIE9JRF9E T1QxMV9ET1QxMURFQVVUSEVOVElDQVRFU1RBVElPTiAgCQkweEZGMDEwMTEx DQorI2RlZmluZSBPSURfRE9UMTFfRE9UMTFBVVRIRU5USUNBVEVGQUlMU1RB VFVTICAgIAkweEZGMDEwMTEyDQorI2RlZmluZSBPSURfRE9UMTFfRE9UMTFB VVRIRU5USUNBVEVGQUlMU1RBVElPTiAgIAkweEZGMDEwMTEzDQorDQorI2Rl ZmluZSBPSURfRE9UMTFfRE9UMTFBVVRIRU5USUNBVElPTkFMR09SSVRITSAg IAkweEZGMDEwMTE0DQorI2RlZmluZSBPSURfRE9UMTFfRE9UMTFBVVRIRU5U SUNBVElPTkFMR09SSVRITUVOQUJMRQkweEZGMDEwMTE1CS8qIFcgKi8NCisN CisjZGVmaW5lIE9JRF9ET1QxMV9ET1QxMVdFUERFRkFVTFRLRVkgICAgICAg IAkJMHhGRjAxMDExNgkvKiBXICovDQorDQorI2RlZmluZSBPSURfRE9UMTFf RE9UMTFXRVBLRVlNQVBQSU5HQUREUkVTUyAgCQkweEZGMDEwMTE3CS8qIFcg Ki8NCisjZGVmaW5lIE9JRF9ET1QxMV9ET1QxMVdFUEtFWU1BUFBJTkdLRVkg ICAgIAkJMHhGRjAxMDExOAkvKiBXICovDQorI2RlZmluZSBPSURfRE9UMTFf RE9UMTFXRVBLRVlNQVBQSU5HV0VQT04gICAgICAgIAkweEZGMDEwMTE5CS8q IFcgKi8NCisNCisjZGVmaW5lIE9JRF9ET1QxMV9ET1QxMVBSSVZBQ1lJTlZP S0VEICAgICAgIAkJMHhGRjAxMDExQQkvKiBXICovDQorI2RlZmluZSBPSURf RE9UMTFfRE9UMTFXRVBERUZBVUxUS0VZSUQgICAgICAgICAgIAkweEZGMDEw MTFCCS8qIFcgKi8NCisjZGVmaW5lIE9JRF9ET1QxMV9ET1QxMVdFUEtFWU1B UFBJTkdMRU5HVEggIAkJMHhGRjAxMDExQwkvKiBXICovDQorI2RlZmluZSBP SURfRE9UMTFfRE9UMTFFWENMVURFVU5FTkNSWVBURUQgICAgICAgIAkweEZG MDEwMTFECS8qIFcgKi8NCisjZGVmaW5lIE9JRF9ET1QxMV9ET1QxMVdFUElD VkVSUk9SQ09VTlQgICAgIAkJMHhGRjAxMDExRQ0KKyNkZWZpbmUgT0lEX0RP VDExX0RPVDExV0VQRVhDTFVERURDT1VOVCAgICAgCQkweEZGMDEwMTFGDQor DQorI2RlZmluZSBPSURfRE9UMTFfRE9UMTFNQUNBRERSRVNTICAgICAgICAg ICAgICAgIAkweEZGMDEwMTIwDQorI2RlZmluZSBPSURfRE9UMTFfRE9UMTFS VFNUSFJFU0hPTEQgICAgICAgICAgICAgIAkweEZGMDEwMTIxCS8qIFcgKi8N CisjZGVmaW5lIE9JRF9ET1QxMV9ET1QxMVNIT1JUUkVUUllMSU1JVCAgICAg ICAgICAgCTB4RkYwMTAxMjIJLyogVyAqLw0KKyNkZWZpbmUgT0lEX0RPVDEx X0RPVDExTE9OR1JFVFJZTElNSVQgICAgICAgCQkweEZGMDEwMTIzCS8qIFcg Ki8NCisjZGVmaW5lIE9JRF9ET1QxMV9ET1QxMUZSQUdNRU5UQVRJT05USFJF U0hPTEQgICAgCTB4RkYwMTAxMjQJLyogVyAqLw0KKyNkZWZpbmUgT0lEX0RP VDExX0RPVDExTUFYVFJBTlNNSVRNU0RVTElGRVRJTUUgICAJMHhGRjAxMDEy NQkvKiBXICovDQorI2RlZmluZSBPSURfRE9UMTFfRE9UMTFNQVhSRUNFSVZF TElGRVRJTUUgICAgICAgIAkweEZGMDEwMTI2CS8qIFcgKi8NCisjZGVmaW5l IE9JRF9ET1QxMV9ET1QxMU1BTlVGQUNUVVJFUklEICAgICAgIAkJMHhGRjAx MDEyNw0KKyNkZWZpbmUgT0lEX0RPVDExX0RPVDExUFJPRFVDVElEICAgICAg ICAgICAgCQkweEZGMDEwMTI4DQorDQorI2RlZmluZSBPSURfRE9UMTFfRE9U MTFUUkFOU01JVFRFREZSQUdNRU5UQ09VTlQgIAkweEZGMDEwMTI5DQorI2Rl ZmluZSBPSURfRE9UMTFfRE9UMTFNVUxUSUNBU1RUUkFOU01JVFRFREZSQU1F Q09VTlQJMHhGRjAxMDEyQQ0KKyNkZWZpbmUgT0lEX0RPVDExX0RPVDExRkFJ TEVEQ09VTlQgICAgICAgICAgICAgICAJMHhGRjAxMDEyQg0KKyNkZWZpbmUg T0lEX0RPVDExX0RPVDExUkVUUllDT1VOVCAgICAgICAgICAgICAgICAJMHhG RjAxMDEyQw0KKyNkZWZpbmUgT0lEX0RPVDExX0RPVDExTVVMVElQTEVSRVRS WUNPVU5UICAgICAgICAJMHhGRjAxMDEyRA0KKyNkZWZpbmUgT0lEX0RPVDEx X0RPVDExRlJBTUVEVVBMSUNBVEVDT1VOVCAgCQkweEZGMDEwMTJFDQorI2Rl ZmluZSBPSURfRE9UMTFfRE9UMTFSVFNTVUNDRVNTQ09VTlQgICAgICAJCTB4 RkYwMTAxMkYNCisjZGVmaW5lIE9JRF9ET1QxMV9ET1QxMVJUU0ZBSUxVUkVD T1VOVCAgICAgICAgICAgCTB4RkYwMTAxMzANCisjZGVmaW5lIE9JRF9ET1Qx MV9ET1QxMUFDS0ZBSUxVUkVDT1VOVCAgICAgICAgICAgCTB4RkYwMTAxMzEN CisjZGVmaW5lIE9JRF9ET1QxMV9ET1QxMVJFQ0VJVkVERlJBR01FTlRDT1VO VCAgCQkweEZGMDEwMTMyDQorI2RlZmluZSBPSURfRE9UMTFfRE9UMTFNVUxU SUNBU1RSRUNFSVZFREZSQU1FQ09VTlQgCTB4RkYwMTAxMzMNCisjZGVmaW5l IE9JRF9ET1QxMV9ET1QxMUZDU0VSUk9SQ09VTlQgICAgICAgIAkJMHhGRjAx MDEzNA0KKyNkZWZpbmUgT0lEX0RPVDExX0RPVDExVFJBTlNNSVRURURGUkFN RUNPVU5UICAJCTB4RkYwMTAxMzUNCisjZGVmaW5lIE9JRF9ET1QxMV9ET1Qx MVdFUFVOREVDUllQVEFCTEVDT1VOVCAgCQkweEZGMDEwMTM2DQorDQorI2Rl ZmluZSBPSURfRE9UMTFfRE9UMTFHUk9VUEFERFJFU1NFUyAgICAgICAJCTB4 RkYwMTAxMzcJLyogVyAqLw0KKw0KKyNkZWZpbmUgT0lEX0RPVDExX0RPVDEx TUFOVUZBQ1RVUkVST1VJICAgICAgICAgICAJMHhGRjAxMDEzOA0KKyNkZWZp bmUgT0lEX0RPVDExX0RPVDExTUFOVUZBQ1RVUkVSTkFNRSAgICAgCQkweEZG MDEwMTM5DQorI2RlZmluZSBPSURfRE9UMTFfRE9UMTFNQU5VRkFDVFVSRVJQ Uk9EVUNUTkFNRSAgCTB4RkYwMTAxM0ENCisjZGVmaW5lIE9JRF9ET1QxMV9E T1QxMU1BTlVGQUNUVVJFUlBST0RVQ1RWRVJTSU9OIAkweEZGMDEwMTNCDQor DQorI2RlZmluZSBPSURfRE9UMTFfRE9UMTFQSFlUWVBFICAgICAgICAgICAg ICAgICAgIAkweEZGMDEwMTNDDQorI2RlZmluZSBPSURfRE9UMTFfRE9UMTFD VVJSRU5UUkVHRE9NQUlOICAgICAJCTB4RkYwMTAxM0QJLyogVyAqLw0KKyNk ZWZpbmUgT0lEX0RPVDExX0RPVDExVEVNUFRZUEUgICAgICAgICAgICAgICAg ICAJMHhGRjAxMDEzRQ0KKyNkZWZpbmUgT0lEX0RPVDExX0RPVDExQ1VSUkVO VFRYQU5URU5OQSAgICAgCQkweEZGMDEwMTNGCS8qIFcgKi8NCisjZGVmaW5l IE9JRF9ET1QxMV9ET1QxMURJVkVSU0lUWVNVUFBPUlQgICAgICAgICAgCTB4 RkYwMTAxNDANCisjZGVmaW5lIE9JRF9ET1QxMV9ET1QxMUNVUlJFTlRSWEFO VEVOTkEgICAgIAkJMHhGRjAxMDE0MQ0KKy8qIFcgKi8NCisjZGVmaW5lIE9J RF9ET1QxMV9ET1QxMU5VTUJFUlNVUFBPUlRFRFBPV0VSTEVWRUxTIAkweEZG MDEwMTQyDQorI2RlZmluZSBPSURfRE9UMTFfRE9UMTFUWFBPV0VSTEVWRUwx ICAgICAgICAJCTB4RkYwMTAxNDMNCisjZGVmaW5lIE9JRF9ET1QxMV9ET1Qx MVRYUE9XRVJMRVZFTDIgICAgICAgIAkJMHhGRjAxMDE0NA0KKyNkZWZpbmUg T0lEX0RPVDExX0RPVDExVFhQT1dFUkxFVkVMMyAgICAgICAgCQkweEZGMDEw MTQ1DQorI2RlZmluZSBPSURfRE9UMTFfRE9UMTFUWFBPV0VSTEVWRUw0ICAg ICAgICAJCTB4RkYwMTAxNDYNCisjZGVmaW5lIE9JRF9ET1QxMV9ET1QxMVRY UE9XRVJMRVZFTDUgICAgICAgIAkJMHhGRjAxMDE0Nw0KKyNkZWZpbmUgT0lE X0RPVDExX0RPVDExVFhQT1dFUkxFVkVMNiAgICAgICAgCQkweEZGMDEwMTQ4 DQorI2RlZmluZSBPSURfRE9UMTFfRE9UMTFUWFBPV0VSTEVWRUw3ICAgICAg ICAJCTB4RkYwMTAxNDkNCisjZGVmaW5lIE9JRF9ET1QxMV9ET1QxMVRYUE9X RVJMRVZFTDggICAgICAgIAkJMHhGRjAxMDE0QQ0KKyNkZWZpbmUgT0lEX0RP VDExX0RPVDExQ1VSUkVOVFRYUE9XRVJMRVZFTCAgCQkweEZGMDEwMTRCCS8q IFcgKi8NCisjZGVmaW5lIE9JRF9ET1QxMV9ET1QxMUNVUlJFTlRDSEFOTkVM ICAgICAgIAkJMHhGRjAxMDE0QwkvKiBXICovDQorI2RlZmluZSBPSURfRE9U MTFfRE9UMTFDQ0FNT0RFU1VQUE9SVEVEICAgICAJCTB4RkYwMTAxNEQNCisj ZGVmaW5lIE9JRF9ET1QxMV9ET1QxMUNVUlJFTlRDQ0FNT0RFICAgICAgIAkJ MHhGRjAxMDE0RQkvKiBXICovDQorI2RlZmluZSBPSURfRE9UMTFfRE9UMTFF RFRIUkVTSE9MRCAgICAgICAgICAgICAgIAkweEZGMDEwMTRGCS8qIFcgKi8N CisjZGVmaW5lIE9JRF9ET1QxMV9ET1QxMVJFR0RPTUFJTlNTVVBQT1JURUQg IAkJMHhGRjAxMDE1MA0KKyNkZWZpbmUgT0lEX0RPVDExX0RPVDExU1VQUE9S VEVEVFhBTlRFTk5BUyAgCQkweEZGMDEwMTUxCS8qIFcgKi8NCisjZGVmaW5l IE9JRF9ET1QxMV9ET1QxMVNVUFBPUlRFRFJYQU5URU5OQVMgIAkJMHhGRjAx MDE1MgkvKiBXICovDQorI2RlZmluZSBPSURfRE9UMTFfRE9UMTFESVZFUlNJ VFlTRUxFQ1RJT05SWCAgICAgIAkweEZGMDEwMTUzCS8qIFcgKi8NCisjZGVm aW5lIE9JRF9ET1QxMV9ET1QxMVNVUFBPUlRFRERBVEFSQVRFU1RYICAJCTB4 RkYwMTAxNTQNCisjZGVmaW5lIE9JRF9ET1QxMV9ET1QxMVNVUFBPUlRFRERB VEFSQVRFU1JYICAJCTB4RkYwMTAxNTUNCisNCisjZGVmaW5lIE9JRF9OV05f U01UQVNTT0NJQVRJT05JRCAgICAgICAgICAgIAkJMHhGRjAxMDFBMA0KKw0K KyNkZWZpbmUgT0lEX05XTl9TTVRDQVBBQklMSVRZSU5GTyAgICAgICAgICAg ICAgICAJMHhGRjAxMDFBMQ0KKyNkZWZpbmUgT0lEX05XTl9TTVRQT1dFUlNB VkVJTlRFUlZBTCAgICAgICAgCQkweEZGMDEwMUEyCS8qIFcgKi8NCisjZGVm aW5lIE9JRF9OV05fU01UTElTVEVOSU5URVJWQUwgICAgICAgICAgICAgICAg CTB4RkYwMTAxQTMJLyogVyAqLw0KKyNkZWZpbmUgT0lEX05XTl9TTVRBVElN V0lORE9XICAgICAgICAgICAgICAgICAgICAJMHhGRjAxMDFBNAkvKiBXICov DQorLyogKi8NCisjZGVmaW5lIE9JRF9OV05fU01UT1BFUkFUSU9OQUxDSEFO TkVMUyAgICAgIAkJMHhGRjAxMDFBNQkvKiBXICovDQorLyogbWFjIGFkcmVz IGFjY2VzcG9pbnQgKi8NCisjZGVmaW5lIE9JRF9OV05fU01UQ1VSUkVOVEJT U0lEICAgICAgICAgICAgIAkJMHhGRjAxMDFBNg0KKw0KKy8qIEVTU0lEICov DQorI2RlZmluZSBPSURfTldOX1NNVENVUlJFTlRTU0lEICAgICAgICAgICAg ICAgICAgIAkweEZGMDEwMUE3DQorI2RlZmluZSBPSURfTldOX1NNVENVUlJF TlRCU1NUWVBFICAgICAgICAgICAgICAgIAkweEZGMDEwMUE4DQorI2RlZmlu ZSBPSURfTldOX1NNVFBVQkxJQ0tFWUVOQUJMRSAgICAgICAgICAgICAgIAkw eEZGMDEwMUE5DQorICAgICAgICAgLyogTm90aWNlIG5vbi1zZXF1ZW50aWFs IG51bWJlcmluZyAqLwkNCisjZGVmaW5lIE9JRF9OV05fU01UUVVBTElUWUxF VkVMMCAgICAgICAgICAgIAkJMHhGRjAxMDFEMCAgICAgICAgDQorICAgICAg ICAgICAgICAgIA0KKyNkZWZpbmUgT0lEX05XTl9TTVRRVUFMSVRZTEVWRUwx ICAgICAgICAgICAgCQkweEZGMDEwMUQxDQorI2RlZmluZSBPSURfTldOX1NN VFFVQUxJVFlMRVZFTDIgICAgICAgICAgICAJCTB4RkYwMTAxRDINCisjZGVm aW5lIE9JRF9OV05fU01UUVVBTElUWVBFTkFMVFkgICAgICAgICAgICAgICAg CTB4RkYwMTAxRDMNCisjZGVmaW5lIE9JRF9OV05fU01UU1RBVElPTkRCVElN RU9VVCAgICAgICAgICAgICAgCTB4RkYwMTAxRDQNCisNCisjZGVmaW5lIE9J RF9OV05fUk9BTVNDQU5UWVBFICAgICAgICAgICAgICAgICAgICAgCTB4RkYw MTAxQUEJLyogVyAqLw0KKyNkZWZpbmUgT0lEX05XTl9ST0FNU0NBTklOVEVS VkFMICAgICAgICAgICAgCQkweEZGMDEwMUFCCS8qIFcgKi8NCisjZGVmaW5l IE9JRF9OV05fUk9BTVBST0JFREVMQVkgICAgICAgICAgICAgIAkJMHhGRjAx MDFBQwkvKiBXICovDQorI2RlZmluZSBPSURfTldOX1JPQU1NSU5DSEFOTkVM VElNRSAgICAgICAgICAJCTB4RkYwMTAxQUQJLyogVyAqLw0KKyNkZWZpbmUg T0lEX05XTl9ST0FNTUFYQ0hBTk5FTFRJTUUgICAgICAgICAgCQkweEZGMDEw MUFFCS8qIFcgKi8NCisjZGVmaW5lIE9JRF9OV05fUk9BTUpPSU5USU1FT1VU ICAgICAgICAgICAgIAkJMHhGRjAxMDFBRgkvKiBXICovDQorI2RlZmluZSBP SURfTldOX1JPQU1CRUFDT05QRVJJT0RUSU1FT1VUICAgICAJCTB4RkYwMTAx QjAJLyogVyAqLw0KKyNkZWZpbmUgT0lEX05XTl9ST0FNRE9OVFNXSVRDSCAg ICAgICAgICAgICAgCQkweEZGMDEwMUIxCS8qIFcgKi8NCisjZGVmaW5lIE9J RF9OV05fUk9BTUJMQUNLT1VUICAgICAgICAgICAgICAgICAgICAgCTB4RkYw MTAxQjIJLyogVyAqLw0KKyNkZWZpbmUgT0lEX05XTl9ST0FNRElTQVNTT0NJ QVRFVElNRSAgICAgICAgCQkweEZGMDEwMUIzCS8qIFcgKi8NCisjZGVmaW5l IE9JRF9OV05fUk9BTUhBTkRPRkZUSU1FICAgICAgICAgICAgIAkJMHhGRjAx MDFCNAkvKiBXICovDQorI2RlZmluZSBPSURfTldOX1JPQU1XRUlHSFRNRVRS SUMxICAgICAgICAgICAgICAgIAkweEZGMDEwMUI1CS8qIFcgKi8NCisjZGVm aW5lIE9JRF9OV05fUk9BTVdFSUdIVE1FVFJJQzIgICAgICAgICAgICAgICAg CTB4RkYwMTAxQjYJLyogVyAqLw0KKyNkZWZpbmUgT0lEX05XTl9ST0FNV0VJ R0hUTUVUUklDMyAgICAgICAgICAgICAgICAJMHhGRjAxMDFCNwkvKiBXICov DQorI2RlZmluZSBPSURfTldOX1JPQU1XRUlHSFRNRVRSSUM0ICAgICAgICAg ICAgICAgIAkweEZGMDEwMUI4CS8qIFcgKi8NCisjZGVmaW5lIE9JRF9OV05f Uk9BTVdFSUdIVE1FVFJJQzUgICAgICAgICAgICAgICAgCTB4RkYwMTAxQjkJ LyogVyAqLw0KKyNkZWZpbmUgT0lEX05XTl9ST0FNV0VJR0hUTUVUUklDNiAg ICAgICAgICAgICAgICAJMHhGRjAxMDFCQQkvKiBXICovDQorI2RlZmluZSBP SURfTldOX1JPQU1XRUlHSFRNRVRSSUM3ICAgICAgICAgICAgICAgIAkweEZG MDEwMUJCCS8qIFcgKi8NCisjZGVmaW5lIE9JRF9OV05fUk9BTVdFSUdIVE1F VFJJQzggICAgICAgICAgICAgICAgCTB4RkYwMTAxQkMJLyogVyAqLw0KKyNk ZWZpbmUgT0lEX05XTl9ST0FNTUlTQzEgICAgICAgICAgICAgICAgICAgICAg ICAJMHhGRjAxMDFCRAkvKiBXICovDQorI2RlZmluZSBPSURfTldOX1JPQU1S U1NJQVZFUkFHRVRJTUUxICAgICAgICAJCTB4RkYwMTAxQkQJLyogVyAqLyAN CisgICAvKiBOb3RlOiBzYW1lIGFzIHByZXZpb3VzIGVudHJ5LCBvbGQgbmFt ZSAqLw0KKyNkZWZpbmUgT0lEX05XTl9ST0FNTUlTQzIgICAgICAgICAgICAg ICAgICAgICAgICAJMHhGRjAxMDFCRQkvKiBXICovDQorI2RlZmluZSBPSURf TldOX1JPQU1SU1NJQVZFUkFHRVRJTUUyICAgICAgICAJCTB4RkYwMTAxQkUJ LyogVyAqLyANCisgICAvKiBOb3RlOiBzYW1lIGFzIHByZXZpb3VzIGVudHJ5 LCBvbGQgbmFtZSAqLw0KKyNkZWZpbmUgT0lEX05XTl9ST0FNVEFCTEVMRU5H VEggICAgICAgICAgICAgCQkweEZGMDEwMUJGDQorDQorI2RlZmluZSBPSURf TldOX1JPQU1CU1NJRCAgICAgICAgICAgICAgICAgICAgICAgIAkweEZGMDEw MUMwDQorI2RlZmluZSBPSURfTldOX1JPQU1TU0lEICAgICAgICAgICAgICAg ICAgICAJCTB4RkYwMTAxQzENCisjZGVmaW5lIE9JRF9OV05fUk9BTUJTU1RZ UEUgICAgICAgICAgICAgICAgIAkJMHhGRjAxMDFDMg0KKyNkZWZpbmUgT0lE X05XTl9ST0FNQ0hBTk5FTCAgICAgICAgICAgICAgICAgCQkweEZGMDEwMUMz DQorI2RlZmluZSBPSURfTldOX1JPQU1BR0UgICAgICAgICAgICAgICAgICAg ICAgICAgIAkweEZGMDEwMUM0DQorI2RlZmluZSBPSURfTldOX1JPQU1RVUFM SVRZICAgICAgICAgICAgICAgICAJCTB4RkYwMTAxQzUNCisjZGVmaW5lIE9J RF9OV05fUk9BTUxPQUQgICAgICAgICAgICAgICAgICAgIAkJMHhGRjAxMDFD Ng0KKyNkZWZpbmUgT0lEX05XTl9ST0FNQkVBQ09OUEVSSU9EICAgICAgICAg ICAgCQkweEZGMDEwMUM3DQorI2RlZmluZSBPSURfTldOX1JPQU1EVElNUEVS SU9EICAgICAgICAgICAgICAgICAgIAkweEZGMDEwMUM4DQorI2RlZmluZSBP SURfTldOX1JPQU1DQVBBQklMSVRZSU5GT1JNQVRJT04gICAgICAgIAkweEZG MDEwMUM5DQorI2RlZmluZSBPSURfTldOX1JPQU1SQVRFUyAgICAgICAgICAg ICAgICAgICAgICAgIAkweEZGMDEwMUNDDQorDQorI2RlZmluZSBPSURfTldO X0JTU0NIQU5HRVRSQVAJCQkJMHhGRjAxMDFENQ0KKw0KKyNkZWZpbmUgT0lE X05XTl9EUklWRVJfVkVSU0lPTiAgICAgICAgICAgICAgICAgICAJMHhGRjAx MDFFMA0KKyNkZWZpbmUgT0lEX05XTl9VUEdSQURFICAgICAgICAgICAgICAg ICAgICAgICAgICAJMHhGRjAxMDFFMQ0KKyNkZWZpbmUgT0lEX05XTl9IQVJE Q09ORklHICAgICAgICAgICAgICAgICAgICAgICAJMHhGRjAxMDFFMg0KKw0K KyNkZWZpbmUgT0lEX05XTl9URVNUUkVHSVNURVIxICAgICAgICAgICAgICAg ICAgICAJMHhGRjAxMDFGMA0KKyNkZWZpbmUgT0lEX05XTl9URVNUUkVHSVNU RVIyICAgICAgICAgICAgICAgICAgICAJMHhGRjAxMDFGMQ0KKyNkZWZpbmUg T0lEX05XTl9URVNUUkVHSVNURVIzICAgICAgICAgICAgICAgICAgICAJMHhG RjAxMDFGMg0KKyNkZWZpbmUgT0lEX05XTl9URVNUUkVHSVNURVI0ICAgICAg ICAgICAgICAgICAgICAJMHhGRjAxMDFGMw0KKyNkZWZpbmUgT0lEX05XTl9U RVNUUkVHSVNURVI1ICAgICAgICAgICAgICAgICAgICAJMHhGRjAxMDFGNA0K KyNkZWZpbmUgT0lEX05XTl9URVNUUkVHSVNURVI2ICAgICAgICAgICAgICAg ICAgICAJMHhGRjAxMDFGNQ0KKyNkZWZpbmUgT0lEX05XTl9URVNUUkVHSVNU RVI3ICAgICAgICAgICAgICAgICAgICAJMHhGRjAxMDFGNg0KKyNkZWZpbmUg T0lEX05XTl9URVNUUkVHSVNURVI4ICAgICAgICAgICAgICAgICAgICAJMHhG RjAxMDFGNw0KKyNkZWZpbmUgT0lEX05XTl9URVNUUkVHSVNURVI5ICAgICAg ICAgICAgICAgICAgICAJMHhGRjAxMDFGOA0KKyNkZWZpbmUgT0lEX05XTl9U RVNUUkVHSVNURVIxMCAgICAgICAgICAgICAgICAgICAJMHhGRjAxMDFGOQ0K KyNkZWZpbmUgT0lEX05XTl9URVNUUkVHSVNURVIxMSAgICAgICAgICAgICAg ICAgICAJMHhGRjAxMDFGQQ0KKyNkZWZpbmUgT0lEX05XTl9URVNUUkVHSVNU RVIxMiAgICAgICAgICAgICAgICAgICAJMHhGRjAxMDFGQg0KKyNkZWZpbmUg T0lEX05XTl9URVNUUkVHSVNURVIxMyAgICAgICAgICAgICAgICAgICAJMHhG RjAxMDFGQw0KKyNkZWZpbmUgT0lEX05XTl9URVNUUkVHSVNURVIxNCAgICAg ICAgICAgICAgICAgICAJMHhGRjAxMDFGRA0KKyNkZWZpbmUgT0lEX05XTl9U RVNUUkVHSVNURVIxNSAgICAgICAgICAgICAgICAgICAJMHhGRjAxMDFGRQ0K KyNkZWZpbmUgT0lEX05XTl9URVNUUkVHSVNURVIxNiAgICAgICAgICAgICAg ICAgICAJMHhGRjAxMDFGRg0KKw0KKyNlbmRpZiAvKiBTTldOTVBfSCAqLw0K Kw0K ---1463811581-2040609447-988666443=:2111-- From owner-netdev@oss.sgi.com Mon Apr 30 16:19:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3UNJtL30641 for netdev-outgoing; Mon, 30 Apr 2001 16:19:55 -0700 Received: from megapathdsl.net (snowbird.megapath.net [216.200.176.7]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3UNJsM30638 for ; Mon, 30 Apr 2001 16:19:54 -0700 Received: from [64.7.20.33] (HELO megapathdsl.net) by megapathdsl.net (CommuniGate Pro SMTP 3.4.3) with ESMTP id 20956297; Mon, 30 Apr 2001 16:19:00 -0700 Message-ID: <3AEDE5BD.F8229E57@megapathdsl.net> Date: Mon, 30 Apr 2001 15:22:53 -0700 From: Miles Lane X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-ac20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Garzik CC: netdev@oss.sgi.com Subject: Re: Announce: ECN vendor support page References: <3AE6D007.4F519933@mandrakesoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Jeff Garzik wrote: > > To all-- > > As ECN deployment increases, people are increasingly noticing that some > key web sites are still inaccessible when ECN is enabled. It would be nice to have a utility that we could use to simulate an connection using ECN without actually having ECN built into our TCP drivers. Then we could quickly check several sites and then fire up a client to try the connection. If the test fails, but the client succeeds, we'd know that that site is using broken routers or whatever. Does this sound doable or worthwhile to you? Miles From owner-netdev@oss.sgi.com Mon Apr 30 18:01:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4111kV02016 for netdev-outgoing; Mon, 30 Apr 2001 18:01:46 -0700 Received: from circuit.moureaux.com (m202-1-p33.warwick.net [208.242.202.38]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4111fM02011 for ; Mon, 30 Apr 2001 18:01:42 -0700 Received: from localhost (IDENT:statux@localhost [127.0.0.1]) by circuit.moureaux.com (8.9.3/8.9.3) with ESMTP id VAA00939; Mon, 30 Apr 2001 21:02:32 -0400 Date: Mon, 30 Apr 2001 21:02:32 -0400 (EDT) From: Statux X-X-Sender: To: Bas Vermeulen cc: Subject: Re: Problems writing pcmcia wireless ethernet driver. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Please.. never ever ever ever ever post something of this size to a mailling list, mmmk? Only send it to select individuals who request it :) -Statux