Alan Cox | 1 Jun 2004 01:01
Picon
Favicon

Re: [PATCH] Re: VIA "Velocity" Gigabit ethernet driver

On Tue, Jun 01, 2004 at 12:35:03AM +0200, Francois Romieu wrote:
> Some polish attached. I'll probably do the rx_copybreak thing as well as
> some pci_dma_sync_single_for_{cpu/device} if nobody beats me.
> 
> Apparently there's no documentation available for the chipset, right ?

I have some documentation but its not what I would call complete. The docs are
marked NDA etc etc but identical to the ones you'll find included with the
current driver zip (the .exe is also a zip) on viaarena ;)

Jeff Garzik | 1 Jun 2004 05:02
Picon
Favicon

Re: [PATCH] farsync needs <asm/io.h>

applied

Herbert Xu | 1 Jun 2004 14:25
Picon
Picon

[IPSEC] Fix xfrm_tunnel leak

Hi Dave:

I recently managed to create a mode=tunnel state that I couldn't get rid
of:

192.168.0.6 192.168.0.178 
	unspec mode=tunnel spi=3232235526(0xc0a80006) reqid=0(0x00000000)
	seq=0x00000000 replay=0 flags=0x00000000 state=mature 
	created: May 29 13:20:10 2004	current: Jun  1 22:23:15 2004
	diff: 291785(s)	hard: 0(s)	soft: 0(s)
	last:                     	hard: 0(s)	soft: 0(s)
	current: 0(bytes)	hard: 0(bytes)	soft: 0(bytes)
	allocated: 0	hard: 0	soft: 0
	sadb_seq=0 pid=19776 refcnt=0

Turns out that the IPIP tunnel used by IPCOMP states are only freed
if the IPCOMP state is deleted by xfrm_state_delete.

This is not the case for all states.  For example, an immature IPCOMP
state that dies in add_sa will not go through xfrm_state_delete.

The following patch moves the delete_tunnel call into IPCOMP's
destructor.  I think it makes more sense there as IPCOMP is the
only user of the tunnel anyway.

Cheers,
--

-- 
Visit Openswan at http://www.openswan.org/
Email:  Herbert Xu ~{PmV>HI~} <herbert <at> gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
(Continue reading)

Stephen Hemminger | 1 Jun 2004 18:13
X-Face

Re: Bug#251215: kernel-image-2.6.6-1-k7: pppd locks up, cannot be killed, during ppp shutdown

On Sat, 29 May 2004 12:48:33 -0700
"David S. Miller" <davem <at> redhat.com> wrote:

> On Sat, 29 May 2004 15:17:36 +1000
> Herbert Xu <herbert <at> gondor.apana.org.au> wrote:
> 
> > Why do we need to call free_netdev after unregistering the netdev
> > from the drivers at all? What's wrong with calling it from run_todo
> > itself?
> 
> Because the driver is the only agent which knows when it is safe
> to free up the structure.  It may still have some attached memory
> to free, for example, ala:
> 
> 	unregister_netdev(dev);
> 	kfree(dev->priv);
> 	free_netdev(dev);
> 
> This is common, for example in drivers/net/tg3.c:tg3_remove_one() we
> have:
> 
> 		struct tg3 *tp = netdev_priv(dev);
> 
> 		unregister_netdev(dev);
> 		iounmap((void *)tp->regs);
> 		free_netdev(dev);
> 
Also, for those device that don't want to do anything in between:
	dev->destructor = free_netdev;

(Continue reading)

Bogdan Costescu | 1 Jun 2004 18:48
Picon

[3c59x] Add support for ATI Radeon 9100 IGP


Hi!

[ I don't know if Andrew (3c59x maintainer) still reads the vortex
mailing list where I just posted the same patch, so I thought
mentioning it on netdev as well would be a good idea. ]

The patch adds support for the 3Com networking core found in the ATI
Radeon 9100 IGP southbridge used on boards like Asus P4R800-VM. The
patch is against the 3c59x driver from 2.6.6; it should apply cleanly
to most other 2.6 versions and applies with some offsets also for
2.4.2x.

A bit of discussion about the patch can be found on the vortex list 
archives, like:

http://marc.theaimsgroup.com/?l=linux-vortex&m=108610754614149&w=2

--- linux-2.6.6-orig/drivers/net/3c59x.c	2004-05-10 04:31:55.000000000 +0200
+++ linux-2.6.6/drivers/net/3c59x.c	2004-05-25 23:45:29.000000000 +0200
 <at>  <at>  -446,6 +446,7  <at>  <at> 
 	CH_3C905B_2,
 	CH_3C905B_FX,
 	CH_3C905C,
+	CH_3C9202,
 	CH_3C980,
 	CH_3C9805,

 <at>  <at>  -521,6 +522,8  <at>  <at> 
 	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_HWCKSM, 128, },
(Continue reading)

David S. Miller | 1 Jun 2004 21:35
X-Face
Picon
Favicon

Re: [IPSEC] Fix xfrm_tunnel leak

On Tue, 1 Jun 2004 22:25:59 +1000
Herbert Xu <herbert <at> gondor.apana.org.au> wrote:

> Turns out that the IPIP tunnel used by IPCOMP states are only freed
> if the IPCOMP state is deleted by xfrm_state_delete.
> 
> This is not the case for all states.  For example, an immature IPCOMP
> state that dies in add_sa will not go through xfrm_state_delete.
> 
> The following patch moves the delete_tunnel call into IPCOMP's
> destructor.  I think it makes more sense there as IPCOMP is the
> only user of the tunnel anyway.

Looks perfect, patch applied.

Thanks Herbert.

Eugene Surovegin | 1 Jun 2004 22:17

Re: [IPSEC] fix ref counting in __xfrm4_bundle_create()

On Sat, May 29, 2004 at 01:27:13PM +1000, Herbert Xu wrote:
> However, can you see if the following patch fixes this problem as well?
> It moves the dst->xfrm assignment to a spot where errors cannot occur.

Yes, your version is OK. We haven't got the crash during our testing.

Thanks a lot, Herbert.

Eugene

David Stevens | 1 Jun 2004 22:19
Picon
Favicon

Re: Fw: F_SETSIG broken/changed in 2.6 for UDP and TCP sockets?

> In the udp case, I when I listen for multicast packets my app only
> receives them when I am running a tcpdump (bizarre!).

Russ,
        This piece (which I expect has nothing to do with the other
problems you mentioned) sounds like you haven't joined the groups on
the interface on which you're receiving the multicast packets.
"tcpdump" will place the interface in "promiscuous mode" which will
receive all packets, and ordinary packet delivery will allow
the application to receive them, even if you haven't joined the group
on the relevant interface.
        To verify if the group joins is broken, you can look at
/proc/net/igmp. If the groups you're joining are not listed on the
interface you want, the program isn't joining the groups correctly.
Group membership is per-interface, so joining a group on one interface
does not join it on another.
        Feel free to contact me if you need some help debugging the
multicast problem.

                                                        +-DLS

Russell Leighton | 2 Jun 2004 00:48
Favicon

Re: Fw: F_SETSIG broken/changed in 2.6 for UDP and TCP sockets?

Thanks for the suggestion.

I tried using the interface itself and INADDR_ANY...the signals are not being received under 2.6 (FedoraCore2) UNLESS tcpdump is running...note this works fine under 2.4.

Below is the code fragment that sets up the socket (the previous email had the code fragment that sets up the posix rt signals on the fd), any help would be greatly appreciated:

  /* mc_fd */
  {

    /* make it */
    if ( (h->state.mc_fd = socket(AF_INET, SOCK_DGRAM, 0)) == -1 ) {
      aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, "mcrxhandler cannot create socket: %s", strerror(errno));
      goto error;
    }

    /* set it to nonblocking so that this can be async */
    if ( fcntl(h->state.mc_fd,  F_SETFL, O_NONBLOCK)  == -1) {
      aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, "mcrxhandler cannot set socket nonblocking: %s", strerror(errno));
      goto error;
    }

    /* set the mc interface */
    if ( setsockopt(h->state.mc_fd, IPPROTO_IP, IP_MULTICAST_IF, &(h->mcast_if_addr), sizeof(h->mcast_if_addr)) < 0 ) {
      u_int8_t
    *ip = (u_int8_t *)&(h->mcast_if_addr);

      aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL,
         "mcrxhandler cannot set socket IP_MULTICAST_IF for %u.%u.%u.%u: %s",
         ip[0],ip[1],ip[2],ip[4],
         strerror(errno));
      goto error;
    }

    { /* debugging where packets are going when you have many interfaces is a pain, you want to log this! */
      u_int8_t
    *ip = (u_int8_t *)&(h->mcast_if_addr);
      aw_log(h->handler_header.logger,  AW_INFO_LOG_LEVEL, "mcrxhandler running multicast on interface %u.%u.%u.%u",
         ip[0],ip[1],ip[2],ip[3]);
    }

    /* use setsockopt() to request that the kernel join a multicast group */
    {
      struct ip_mreq
    mreq;

      /* set up */
      memset(&mreq, 0 , sizeof(mreq));
      mreq.imr_multiaddr.s_addr= h->mcast_grp_addr.sin_addr.s_addr;
      mreq.imr_interface.s_addr= h->mcast_if_addr.s_addr;

      if (setsockopt(h->state.mc_fd, IPPROTO_IP,IP_ADD_MEMBERSHIP, (char *)&mreq, sizeof(mreq)) < 0) {
    aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL,
           "mcrxhandler cannot set socket IPPROTO_IP,IP_ADD_MEMBERSHIP: %s", strerror(errno));
    goto error;
      }
    }

    /* so we can have many processes listening to mcast */
    {
      int32_t
    itmp = 1;
      if ( setsockopt(h->state.mc_fd, SOL_SOCKET, SO_REUSEADDR , (char *)&itmp, sizeof(itmp)) < 0 ) {
    aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, "mcrxhandler cannot set socket SO_REUSEADDR: %s", strerror(errno));
      }
    }

    /* bind to receive messages */
    if (bind(h->state.mc_fd, (struct sockaddr *)&(h->mcast_grp_addr), sizeof(h->mcast_grp_addr)) < 0) {
      aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, "mcrxhandler cannot bind to multicast socket", strerror(errno));
      goto error ;
    }

    /* add callback to handle packets on mc_fd */
    aw_add_handler_fdcallback(mon, (aw_handler_t *)h, h->state.mc_fd, do_read);

  } /* end mc_fd */




David Stevens wrote:
In the udp case, I when I listen for multicast packets my app only receives them when I am running a tcpdump (bizarre!).
Russ, This piece (which I expect has nothing to do with the other problems you mentioned) sounds like you haven't joined the groups on the interface on which you're receiving the multicast packets. "tcpdump" will place the interface in "promiscuous mode" which will receive all packets, and ordinary packet delivery will allow the application to receive them, even if you haven't joined the group on the relevant interface. To verify if the group joins is broken, you can look at /proc/net/igmp. If the groups you're joining are not listed on the interface you want, the program isn't joining the groups correctly. Group membership is per-interface, so joining a group on one interface does not join it on another. Feel free to contact me if you need some help debugging the multicast problem. +-DLS

Russell Leighton | 2 Jun 2004 01:08
Favicon

Re: Fw: F_SETSIG broken/changed in 2.6 for UDP and TCP sockets?


I forgot to answer your question, I confirmed via the proc interface 
that the group has been joined.

I am thinking the issue is related to F_SETSIG. I don't read() until I 
get a signal and I am not getting ANY signals for the multicast data.

Googling around a little I saw changes in the futex code around FUTEX_FD 
... perhaps there is a bug?

Cobbling together a small test piece of code is the next thing to do...

Russell Leighton wrote:

> Thanks for the suggestion.
>
> I tried using the interface itself and INADDR_ANY...the signals are 
> not being received under 2.6 (FedoraCore2) UNLESS tcpdump is 
> running...note this works fine under 2.4.
>
> Below is the code fragment that sets up the socket (the previous email 
> had the code fragment that sets up the posix rt signals on the fd), 
> any help would be greatly appreciated:
>
>   /* mc_fd */
>   {
>
>     /* make it */
>     if ( (h->state.mc_fd = socket(AF_INET, SOCK_DGRAM, 0)) == -1 ) {
>       aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, 
> "mcrxhandler cannot create socket: %s", strerror(errno));
>       goto error;
>     }
>
>     /* set it to nonblocking so that this can be async */
>     if ( fcntl(h->state.mc_fd,  F_SETFL, O_NONBLOCK)  == -1) {
>       aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, 
> "mcrxhandler cannot set socket nonblocking: %s", strerror(errno));
>       goto error;
>     }
>
>     /* set the mc interface */
>     if ( setsockopt(h->state.mc_fd, IPPROTO_IP, IP_MULTICAST_IF, 
> &(h->mcast_if_addr), sizeof(h->mcast_if_addr)) < 0 ) {
>       u_int8_t
>     *ip = (u_int8_t *)&(h->mcast_if_addr);
>
>       aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL,
>          "mcrxhandler cannot set socket IP_MULTICAST_IF for 
> %u.%u.%u.%u: %s",
>          ip[0],ip[1],ip[2],ip[4],
>          strerror(errno));
>       goto error;
>     }
>
>     { /* debugging where packets are going when you have many 
> interfaces is a pain, you want to log this! */
>       u_int8_t
>     *ip = (u_int8_t *)&(h->mcast_if_addr);
>       aw_log(h->handler_header.logger,  AW_INFO_LOG_LEVEL, 
> "mcrxhandler running multicast on interface %u.%u.%u.%u",
>          ip[0],ip[1],ip[2],ip[3]);
>     }
>
>     /* use setsockopt() to request that the kernel join a multicast 
> group */
>     {
>       struct ip_mreq
>     mreq;
>
>       /* set up */
>       memset(&mreq, 0 , sizeof(mreq));
>       mreq.imr_multiaddr.s_addr= h->mcast_grp_addr.sin_addr.s_addr;
>       mreq.imr_interface.s_addr= h->mcast_if_addr.s_addr;
>
>       if (setsockopt(h->state.mc_fd, IPPROTO_IP,IP_ADD_MEMBERSHIP, 
> (char *)&mreq, sizeof(mreq)) < 0) {
>     aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL,
>            "mcrxhandler cannot set socket 
> IPPROTO_IP,IP_ADD_MEMBERSHIP: %s", strerror(errno));
>     goto error;
>       }
>     }
>
>     /* so we can have many processes listening to mcast */
>     {
>       int32_t
>     itmp = 1;
>       if ( setsockopt(h->state.mc_fd, SOL_SOCKET, SO_REUSEADDR , (char 
> *)&itmp, sizeof(itmp)) < 0 ) {
>     aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, "mcrxhandler 
> cannot set socket SO_REUSEADDR: %s", strerror(errno));
>       }
>     }
>
>     /* bind to receive messages */
>     if (bind(h->state.mc_fd, (struct sockaddr *)&(h->mcast_grp_addr), 
> sizeof(h->mcast_grp_addr)) < 0) {
>       aw_log(h->handler_header.logger, AW_ERROR_LOG_LEVEL, 
> "mcrxhandler cannot bind to multicast socket", strerror(errno));
>       goto error ;
>     }
>
>     /* add callback to handle packets on mc_fd */
>     aw_add_handler_fdcallback(mon, (aw_handler_t *)h, h->state.mc_fd, 
> do_read);
>
>   } /* end mc_fd */
>
>
>
>
> David Stevens wrote:
>
>>>In the udp case, I when I listen for multicast packets my app only
>>>receives them when I am running a tcpdump (bizarre!).
>>>    
>>>
>>
>>Russ,
>>        This piece (which I expect has nothing to do with the other
>>problems you mentioned) sounds like you haven't joined the groups on
>>the interface on which you're receiving the multicast packets.
>>"tcpdump" will place the interface in "promiscuous mode" which will
>>receive all packets, and ordinary packet delivery will allow
>>the application to receive them, even if you haven't joined the group
>>on the relevant interface.
>>        To verify if the group joins is broken, you can look at
>>/proc/net/igmp. If the groups you're joining are not listed on the
>>interface you want, the program isn't joining the groups correctly.
>>Group membership is per-interface, so joining a group on one interface
>>does not join it on another.
>>        Feel free to contact me if you need some help debugging the
>>multicast problem.
>>
>>                                                        +-DLS
>>
>>
>>
>>  
>>
>


Gmane