[PATCH 2/2] 8139cp: add ethtool eeprom support

Implement the ethtool eeprom operations for the 8139cp driver. Tested on x86 and big-endian ARM. Signed-off-by: Philip Craig <[EMAIL PROTECTED]> Index: linux-2.6.17-rc6/drivers/net/8139cp.c === --- linux-2.6.17-rc6.orig/drivers/net/8

[PATCH 1/2] 8139cp: fix eeprom read command length

The read command for the 93C46/93C56 EEPROMS should be 3 bits plus the address. This doesn't appear to affect the operation of the read command, but similar errors for write commands do cause failures. Signed-off-by: Philip Craig <[EMAIL PROTECTED]> Index: linux-2.6.17-rc6/drivers/net/8139cp.c =

Re: [RFC/PATCH 1/2] in-kernel sockets API

Chase, On Tue, 13 Jun 2006, Chase Venters wrote: > > > I don't think that it is fair to say that an unstable API/ABI, in of > > itself, provides an incentive to open an existing proprietary driver. > > Sure it does, depending on your perspective and what you're willing to > consider. The lack o

tcp_slow_start_after_idle

Bringing back up this old topic: http://marc.theaimsgroup.com/?l=linux-netdev&m=114564962420171&w=2 I've decided to add this tunable to the net-2.6.18 tree, patch below. The more I think about it, allowing it to be turned off is reasonable, but it will be left on by default. diff-tree

Re: How can we make more use of memory for TCP properly?

> Accorting to TCP man page, the kernel calculates the values of > sysctl_tcp_mem depending on available physical memory at boot time. > I added 2GB RAM to a machine that had 2GB, and then it has 4GB RAM now. > However, the value of sysctl_tcp_mem[2] has not changed from 196608 > (pages). The

Re: 2.6.17: networking bug??

> Also, as John Heffner mentioned, even if we could detect the broken > boxes you can't just "turn off window scaling" after it's been > negotiated. It's immutably active for the entire connection once > enabled. In theory you could set a bit in the dst entry and not use it next time you connect

Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late

On Tue, Jun 13, 2006 at 08:33:22PM -0400, Jeff Garzik wrote: > Grant Grundler wrote: > >o tulip_stop_rxtx() has to be called _after_ free_irq(). > > ie. v2 patch didn't fix the original race condition > > and when under test, dies about as fast as the original code. > > You made the race window

Re: 2.6.17: networking bug??

Rick Jones wrote: One final word about window sizes. If you have a connection whose bandwidth-delay-product needs an N byte buffer to fill, you actually have to have an "N * 2" sized buffer available in order for fast retransmit to work. Is that as important in the presence of SACK? With SAC

Re: [RFC/PATCH 1/2] in-kernel sockets API

On Tuesday 13 June 2006 19:30, Brian F. G. Bidulock wrote: > Yes, and the long list of open source licenses listed on the FSF website > as incompatible with the GPL. Conceded, I suppose. The usage of EXPORT_SYMBOL() though tends to be for the reason of enabling drivers to offer functionality to

Re: [RFC/PATCH 1/2] in-kernel sockets API

Chase, On Tue, 13 Jun 2006, Chase Venters wrote: > > But I did ask for examples... Perhaps the license isn't a good example, but there are other RTP stacks that are non-GPL compatible. Also, if it includes SSL code for SRTP, SSL license happens to be non-GPL compatible. - To unsubscribe from th

Re: [RFC/PATCH 1/2] in-kernel sockets API

Ben, On Tue, 13 Jun 2006, Ben Greear wrote: > > I got to the flame war late ... I think we're trying to have an honest open discussion here. I certainly don't mean to flame anyone and apologize if my remarks have been taken so. - To unsubscribe from this list: send the line "unsubscribe netdev"

Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late

Grant Grundler wrote: o tulip_stop_rxtx() has to be called _after_ free_irq(). ie. v2 patch didn't fix the original race condition and when under test, dies about as fast as the original code. You made the race window smaller, but it's still there. The chip's DMA engines should be stopped

Re: [RFC/PATCH 1/2] in-kernel sockets API

Chase, On Tue, 13 Jun 2006, Chase Venters wrote: > > It depends on what you mean by "pure-BSD". If you're talking about the > 4-clause license with the advertising clause, then you are correct. Otherwise > (IANAL) but my understanding is that BSD code can even be relicensed GPL by a > third pa

Re: [RFC/PATCH 1/2] in-kernel sockets API

On Tuesday 13 June 2006 19:17, Brian F. G. Bidulock wrote: > Chase, > > On Tue, 13 Jun 2006, Chase Venters wrote: > > I'm trying to imagine what kind of legitimate non-GPL modules might > > use them. > > Example: in-kernel RTP implementation derived from AT&T rtp-lib > implementation (non-GPL compa

Re: [RFC/PATCH 1/2] in-kernel sockets API

Chase Venters wrote: On Tuesday 13 June 2006 18:42, Ben Greear wrote: Chase Venters wrote: At least some of us feel like stable module APIs should be explicitly discouraged, because we don't want to offer comfort for code that refuses to live in the tree (since getting said code into the tree

Re: [RFC/PATCH 1/2] in-kernel sockets API

Chase, On Tue, 13 Jun 2006, Chase Venters wrote: > I'm trying to imagine what kind of legitimate non-GPL modules might > use them. Example: in-kernel RTP implementation derived from AT&T rtp-lib implementation (non-GPL compatible license) utilizing this kernel interface for UDP socket access. -

Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late

On Tue, Jun 13, 2006 at 05:55:31PM -0600, Grant Grundler wrote: > On Thu, Jun 08, 2006 at 11:01:20AM -0600, Grant Grundler wrote: > > Here is a new patch that moves free_irq() into tulip_down(). > > The resulting code is structured the same as cp_close(). > > Val, > Two details are wrong in versio

Re: [RFC/PATCH 1/2] in-kernel sockets API

On Tuesday 13 June 2006 17:46, Brian F. G. Bidulock wrote: > Daniel, > > On Tue, 13 Jun 2006, Daniel Phillips wrote: > > You probably meant "non-GPL-compatible non-proprietary". If so, then by > > definition there are none. > > Well, being GPL compatible is not a requirement for an open source lic

Re: [RFC/PATCH 1/2] in-kernel sockets API

On Tuesday 13 June 2006 18:42, Ben Greear wrote: > Chase Venters wrote: > > At least some of us feel like stable module APIs should be explicitly > > discouraged, because we don't want to offer comfort for code that > > refuses to live in the tree (since getting said code into the tree is > > often

Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late

On Thu, Jun 08, 2006 at 11:01:20AM -0600, Grant Grundler wrote: > Here is a new patch that moves free_irq() into tulip_down(). > The resulting code is structured the same as cp_close(). Val, Two details are wrong in version 2 and are fixed in v3 (appended below): o we don't need synchronize_irq()

Re: [RFC/PATCH 1/2] in-kernel sockets API

Chase Venters wrote: At least some of us feel like stable module APIs should be explicitly discouraged, because we don't want to offer comfort for code that refuses to live in the tree (since getting said code into the tree is often a goal). Some of us write modules for specific features tha

Re: 2.6.17: networking bug??

On Tue, Jun 13, 2006 at 05:49:21PM -0400, Mark Lord wrote: > > > David Miller wrote: > >.. > >First, you are getting window scaling by default with the older > >kernel too. It's just a smaller window scale, using a shift > >value of say 1 or 2. > > > >What these broken middle boxes do is ignore

RE: [PATCH] s2io: netpoll support

I don't think we should disable and enable all interrupts in the poll_controller entry point. With the current patch, at the end of the routine _all_ interrupts get enabled which is not desirable. Maybe you should just do disable_irq() at start of function and enable_irq() before exiting, the way s

[PATCH] DM9000 - minor code cleanups

Ensure the driver's module owner field is initialised for when this is being built and loaded as a module. Also change make the dm9000_tx_done function static, as it is not exported elsewhere. Signed-off-by: Ben Dooks <[EMAIL PROTECTED]> --- ../linux-2.6.17/linux-2.6.17-rc5/drivers/net/dm9000.c

[PATCH] DM9000 - do no re-init spin lock

The DM9000 initialisation sequence for the hardware re-initialise the board spin-lock, which is in my view wrong. This patch removes the extra spin lock initialisation Signed-off-by: Ben Dooks <[EMAIL PROTECTED]> --- ../linux-2.6.17/linux-2.6.17-rc5/drivers/net/dm9000.c 2006-03-20 05:53:29

Re: 2.6.17: networking bug??

From: Rick Jones <[EMAIL PROTECTED]> Date: Tue, 13 Jun 2006 15:40:53 -0700 > > One final word about window sizes. If you have a connection whose > > bandwidth-delay-product needs an N byte buffer to fill, you actually > > have to have an "N * 2" sized buffer available in order for fast > > retran

[PATCH] DM9000 - check for MAC left in by bootloader

The DM9000 driver does not deal with the case where there is no serial EEPROM to store the configuration, and the bootloader has placed an MAC address into the device already. If there is no valid MAC in the EEPROM, read the one already in the chip and check to see if that one is valid. Signed-of

[PATCH] DM9000 - better checks for platform resources

The current DM9000 driver cannot cope if it is given more than 3 resources (for example, if it is being passed an wake-up irq that it is not using yet). Check that we have been given at-least one IRQ resource. Also fix the minor type-casting for the case of 2 resources. Signed-off-by: Ben Dooks

Re: [RFC/PATCH 1/2] in-kernel sockets API

Daniel, On Tue, 13 Jun 2006, Daniel Phillips wrote: > > You probably meant "non-GPL-compatible non-proprietary". If so, then by > definition there are none. Well, being GPL compatible is not a requirement for an open source license. IANAL, but last I checked, pure-BSD is not compatible with GP

Re: [RFC/PATCH 1/2] in-kernel sockets API

Chase, On Tue, 13 Jun 2006, Chase Venters wrote: > > Look out for that word (stable). Judging from history (and sanity), > arguing /in favor of/ any kind of stable module API is asking for it. I was really just using Daniel's words. I am all too aware that kernel APIs are unstable. To some it

Re: [PATCH 1/2] AES-XCBC-MAC

On Wed, Jun 14, 2006 at 12:44:00AM +0900, Kazunori MIYAZAWA wrote: > This is preparation to introduce AES-XCBC-MAC. > - introducing common interface "keyed hash" > - making HMAC use the interface I'm sorry guys, but this seems to duplicate what I've been doing as generic parameterised algorithms.

Re: [PATCH 2.6.18 3/6] bnx2: Use CPU native page size

From: "Michael Chan" <[EMAIL PROTECTED]> Date: Tue, 13 Jun 2006 11:19:42 -0700 > Use CPU native page size to determine various ring sizes. This allows > order-0 memory allocations on all systems. > > Added check to limit the page size to 16K since that's the maximum rx > ring size that will be us

Re: 2.6.17: networking bug??

One final word about window sizes. If you have a connection whose bandwidth-delay-product needs an N byte buffer to fill, you actually have to have an "N * 2" sized buffer available in order for fast retransmit to work. Is that as important in the presence of SACK? rick jones - To unsubscribe

Re: [RFC/PATCH 1/2] in-kernel sockets API

Chase Venters wrote: can you name some non-GPL non-proprietary modules we should be concerned about? You probably meant "non-GPL-compatible non-proprietary". If so, then by definition there are none. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe netdev" in the b

Re: 2.6.17: networking bug??

From: Mark Lord <[EMAIL PROTECTED]> Date: Tue, 13 Jun 2006 17:49:21 -0400 > I suppose the most important objection to our current behaviour > is that this behaviour *changes* when something totally unrelated > (to Joe User) happens: adding or removing a stick of RAM. We are pretty much required

Re: 2.6.17: networking bug??

From: Chase Venters <[EMAIL PROTECTED]> Date: Tue, 13 Jun 2006 17:09:16 -0500 (CDT) > Does anyone have any interesting statistics on how often end-users > are likely to run into this crap? I think it's much less likely than the ECN stuff, by a long shot. - To unsubscribe from this list: send the

Re: [RFC/PATCH 2/2] update sunrpc to use in-kernel sockets API

On Tue, 13 Jun 2006, Sridhar Samudrala wrote: > My patch doesn't touch this section of the code and this is called > after the assignment we are talking about. So we should be using the > right sendpage in the actual call. Ok. Acked-by: James Morris <[EMAIL PROTECTED]> (for both patches). --

Re: 2.6.17: networking bug??

Mark From everything I have read so far (which admittedly hasn't been everything) it sounds like the firewall in question was a ticking timebomb. If 2.6.17 hadn't set it off, something else might very well have done so. Or, if you prefer another metaphore, 2.6.17 was simply the last in a s

Re: 2.6.17: networking bug??

On Tue, 13 Jun 2006, John Heffner wrote: In the last couple years, we've added code that can automatically size the buffers as appropriate for each connection, but it's completely crippled unless you use a window scale. Personally, I think it's not a question of *whether* we have to start u

Re: [RFC/PATCH 1/2] in-kernel sockets API

On Tue, 13 Jun 2006, Brian F. G. Bidulock wrote: Daniel, On Tue, 13 Jun 2006, Daniel Phillips wrote: This has the makings of a nice stable internal kernel api. Why do we want to provide this nice stable internal api to proprietary modules? Why not? Not all non-GPL modules are proprietary.

Re: 2.6.17: networking bug??

David Miller wrote: .. First, you are getting window scaling by default with the older kernel too. It's just a smaller window scale, using a shift value of say 1 or 2. What these broken middle boxes do is ignore the window scale entirely. So they don't apply a window scale to the advertised

How can we make more use of memory for TCP properly?

Hi all, Although I tried to find similar topics in the maling list, I found no useful clue. If I overlooked, please let me know the pointer. I need to increase the value of sysctl_tcp_mem[2] that limit the total amount of memory allocated for TCP in order to maintain a number of simultateous

RE: [openib-general] [PATCH v2 1/2] iWARP Connection Manager.

On Tue, 2006-06-13 at 14:36 -0700, Sean Hefty wrote: > >> Er...no. It will lose this event. Depending on the event...the carnage > >> varies. We'll take a look at this. > >> > > > >This behavior is consistent with the Infiniband CM (see > >drivers/infiniband/core/cm.c function cm_recv_handler()).

Re: [RFC/PATCH 1/2] in-kernel sockets API

Daniel, On Tue, 13 Jun 2006, Daniel Phillips wrote: > > This has the makings of a nice stable internal kernel api. Why do we want > to provide this nice stable internal api to proprietary modules? Why not? Not all non-GPL modules are proprietary. Do we lose something by making a nice stable a

Re: http://bugzilla.kernel.org/show_bug.cgi?id=6197

Patrick McHardy wrote: [] > He patched his kernel with the IMQ device, which is known to cause all > kinds of weird problems. Wich problems? Known to whom? I was considering using imq for our needs (not done yet), and from the FAQ at http://www.linuximq.net/faq.html (item #3, "Is it stable?") it

RE: [openib-general] [PATCH v2 1/2] iWARP Connection Manager.

>> Er...no. It will lose this event. Depending on the event...the carnage >> varies. We'll take a look at this. >> > >This behavior is consistent with the Infiniband CM (see >drivers/infiniband/core/cm.c function cm_recv_handler()). But I think >we should at least log an error because a lost event

Re: 2.6.17: networking bug??

From: Mark Lord <[EMAIL PROTECTED]> Date: Tue, 13 Jun 2006 15:08:59 -0400 > Err.. no, the networking stack simply decided to become incompatible > with certain sites, as a result of the user adding more RAM to their > machine. Let's discuss some facts. First, you are getting window scaling by de

Re: [RFC/PATCH 1/2] in-kernel sockets API

Brian F. G. Bidulock wrote: Stephen, On Tue, 13 Jun 2006, Stephen Hemminger wrote: @@ -2176,3 +2279,13 @@ EXPORT_SYMBOL(sock_wake_async); EXPORT_SYMBOL(sockfd_lookup); EXPORT_SYMBOL(kernel_sendmsg); EXPORT_SYMBOL(kernel_recvmsg); +EXPORT_SYMBOL(kernel_bind); +EXPORT_SYMBOL(kernel_listen); +EX

Re: 2.6.17: networking bug??

On 6/13/06, John Heffner <[EMAIL PROTECTED]> wrote: Though I haven't gotten my hands on it, I believe Windows will soon have this capability, too. I'm sure Windows is big enough that whenever they turn this on, it will flush out all these boxes pretty quickly. We could wait for them to do it fi

Re: [PATCH] [2.6.17-rc6] Section mismatch in drivers/net/ne.o during modpost

> Probably over enthusiastic gcc inlining. gcc 4 will inline functions > that are not declared as inline. That is not so bad, except that some > versions of gcc will ignore a mismatch in function attributes and > inline a __init function into normal text, generating additional > section mismatc

Re: [PATCH v2 1/2] iWARP Connection Manager.

> > > +static void cm_event_handler(struct iw_cm_id *cm_id, > > > + struct iw_cm_event *iw_event) > > > +{ > > > + struct iwcm_work *work; > > > + struct iwcm_id_private *cm_id_priv; > > > + unsigned long flags; > > > + > > > + work = kmalloc(sizeof(*work), GFP_ATOMIC); > >

[PATCH 3/4] bcm43xx: Port suspend-mac-in-long-pwork from d80211

Port the Suspend MAC In Long Periodic Work patch from bcm43xx-softmac to bcm43xx-d80211. Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Index: wireless-dev-dscapeports/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h === --- wireless

[PATCH 4/4] bcm43xx: Port PIO fixes to d80211

Port the PIO fixes from bcm43xx-softmac to bcm43xx-d80211. Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Index: wireless-dev-dscapeports/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.h === --- wireless-dev-dscapeports.orig/dri

[PATCH 1/4] bcm43xx: Port new locking scheme to d80211

Port the new locking scheme from bcm43xx-softmac to bcm43xx-d80211. Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Index: wireless-dev-dscapeports/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h === --- wireless-dev-dscapeports.orig/

[PATCH 0/4] bcm43xx: Port patches to d80211

Hi John, Please apply this series to wireless-dev. This ports various patches from bcm43xx-softmac to bcm43xx-d80211. -- - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info

[PATCH 2/4] bcm43xx: Port preemptible-periodic-work to d80211

Port the preemptible periodic work patch from bcm43xx-softmac to bcm43xx-d80211. Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Index: wireless-dev-dscapeports/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c === --- wireless-d

Re: 2.6.17: networking bug??

Mark Lord wrote: Linus Torvalds wrote: It's not like there aren't broken boxes out there, and it might be better to make the default buffer sizes just be low enough that window scaling simply isn't an issue. I suspect that the people who really want/need window scaling know about it, and co

Re: 2.6.17: networking bug??

Linus Torvalds wrote: On Tue, 13 Jun 2006, John Heffner wrote: The best thing you can do is try to find this broken box and inform its owner that it needs to be fixed. (If you can find out what it is, I'd be interested to know.) In the meantime, disabling window scaling will work around the p

Re: 2.6.17: networking bug??

Linus Torvalds wrote: On Tue, 13 Jun 2006, John Heffner wrote: The best thing you can do is try to find this broken box and inform its owner that it needs to be fixed. (If you can find out what it is, I'd be interested to know.) In the meantime, disabling window scaling will work around the p

Re: Remove Prism II support from Orinoco

Stephen Hemminger wrote: >use blacklist in module config to block one. >Just put in /etc/modprobe.conf >blacklist orinoco Unfortunately this is not work at least it is not work with FC4. I can blacklist eepro100 and 8139cp. blacklist eepro100 blacklist 8139cp but I can't blacklist orinoco_p

Re: [PATCH 2.6.18 3/6] bnx2: Use CPU native page size

On Mon, 2006-06-12 at 22:20 -0700, David Miller wrote: > From: "Michael Chan" <[EMAIL PROTECTED]> > Date: Mon, 12 Jun 2006 17:17:13 -0700 > > > Use CPU native page size to determine various ring sizes. This allows > > order-0 memory allocations on all systems. > > > > Signed-off-by: Michael Chan

Re: 2.6.17: networking bug??

On Tue, 13 Jun 2006, John Heffner wrote: > > The best thing you can do is try to find this broken box and inform its owner > that it needs to be fixed. (If you can find out what it is, I'd be interested > to know.) In the meantime, disabling window scaling will work around the > problem for yo

Re: 2.6.17: networking bug??

Mark Lord wrote: John / David: Any ideas on what's gone awry here? Yes, you have some sort of a broken middlebox in your path (firewall, transparent proxy, or similar) that doesn't correctly handle window scaling. Check out this thread:

Netchannels: alternative TCP/IP stack?

Hello, developers. I've implemented simple rfc793 TCP/IP stack, which is currently tested in userspace through packet socket. After ISO (~650Mb) transfer over gigabit ethernet between two Linux boxes, file was not corrupted. I would even say that stack is really trivial (1800 lines of code, 42K

Re: 2.6.17: networking bug??

Mark Lord wrote: .. The site www.everymac.com is still not browseable until setting /proc/sys/net/ipv4/tcp_window_scaling===0. There's one other difference I see in the tcpdump traces. The first packets from each trace below show different values for "wscale". The old (working) kernels use "ws

Re: 2.6.17: networking bug??

.. The site www.everymac.com is still not browseable until setting /proc/sys/net/ipv4/tcp_window_scaling===0. There's one other difference I see in the tcpdump traces. The first packets from each trace below show different values for "wscale". The old (working) kernels use "wscale 2", whereas 2

Re: Network Performance Comparison between Linux 2.4 and 2.6

I have included the throughput figures for bridging for both 2.4 and 2.6 kernels in the table below. Packet Size(bytes)2.4.31(Mbps) 2.6.16(Mbps) -- 64

Re: [RFT 0/5] sky2: suspend/resume patchlets

[ Davem - see the final conclusion: this might not be a driver bug as much as a netconsole problem, where netconsole might perhaps continue sendign on a device that really can't take it any more? ] On Tue, 13 Jun 2006, Stephen Hemminger wrote: > > There were a several problems buried in sus

Re: [IPV6]: Fix RTNLGRP_IPV6_IFINFO netlink notifications

In article <[EMAIL PROTECTED]> (at Tue, 13 Jun 2006 18:03:22 +0200), Patrick McHardy <[EMAIL PROTECTED]> says: > Yes, thats better. I also thing we shouldn't return -EINVAL but > -ENOSPC or something like that, -EINVAL usually indicated that > the user sent an invalid message, which isn't the cas

Re: HELP! Slip Interface losing packets. Looking for contractor to fix.

Butler, Gerald wrote: ... a custom compiled Linux Kernel running oh RHEL 3.1 If you post more details (precise description of hardware setup, problem, and method of reproducing) you might get a patch for free. -- Paul Fulghum Microgate Systems, Ltd. - To unsubscribe from this list: send the li

Re: [PATCH 03/16] 64bit resource: fix up printks for resources in networks drivers

On Tue, Jun 13, 2006 at 09:24:55AM -0700, Jesse Brandeburg wrote: > First, added netdev, > > On 6/12/06, Greg KH <[EMAIL PROTECTED]> wrote: > >From: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > > >This is needed if we wish to change the size of the resource structures. > > > >Based on an original pa

Re: [PATCH 03/16] 64bit resource: fix up printks for resources in networks drivers

First, added netdev, On 6/12/06, Greg KH <[EMAIL PROTECTED]> wrote: From: Greg Kroah-Hartman <[EMAIL PROTECTED]> This is needed if we wish to change the size of the resource structures. Based on an original patch from Vivek Goyal <[EMAIL PROTECTED]> Cc: Vivek Goyal <[EMAIL PROTECTED]> Cc: And

Re: [RFC/PATCH 1/2] in-kernel sockets API

On Tue, 2006-06-13 at 16:58 +0200, Jan Engelhardt wrote: > >+extern int kernel_ioctl(struct socket *sock, int cmd, unsigned long arg); > >+ > > I would prefer naming it kernel_sock_ioctl, since (general) ioctl often > done on fds (or struct file * for that matter) rather than sockets. I agree th

Re: [RFC/PATCH 2/2] update sunrpc to use in-kernel sockets API

On Tue, 2006-06-13 at 10:07 -0400, James Morris wrote: > On Mon, 12 Jun 2006, Sridhar Samudrala wrote: > > > > > - sendpage = sock->ops->sendpage ? : sock_no_sendpage; > > > > + sendpage = kernel_sendpage ? : sock_no_sendpage; > > > > > > > > > > This is not equivalent. > > > >

Re: [PATCH 2/2] AES-XCBC-MAC

In article <[EMAIL PROTECTED]> (at Wed, 14 Jun 2006 00:44:06 +0900), Kazunori MIYAZAWA <[EMAIL PROTECTED]> says: > This patch introduces AES-XCBC-MAC using the "keyed hash" interface. > It accordingly depends on the previous patch. > > Signed-off-by: Kazunori MIYAZAWA <[EMAIL PROTECTED]> Acked-b

Re: [PATCH 1/2] AES-XCBC-MAC

In article <[EMAIL PROTECTED]> (at Wed, 14 Jun 2006 00:44:00 +0900), Kazunori MIYAZAWA <[EMAIL PROTECTED]> says: > This is preparation to introduce AES-XCBC-MAC. > - introducing common interface "keyed hash" > - making HMAC use the interface Acked-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> BTW,

Re: http://bugzilla.kernel.org/show_bug.cgi?id=6197

Andrew Morton wrote: > The reporter claims this is a netfilter bug. > ipt_IMQ 1949 36 imq 4023 0 He patched his kernel with the IMQ device, which is known to cause all kinds of weird problems. - To unsubscribe from this list: send the line "unsubscribe netde

HELP! Slip Interface losing packets. Looking for contractor to fix.

Hello, We have a custom compiled Linux Kernel running oh RHEL 3.1 [EMAIL PROTECTED] root]# uname -a Linux st0056_1 2.4.21-32.0.1.ELcustom #12 SMP Wed Sep 14 11:55:22 EDT 2005 i686 i686 i386 GNU/Linux We compiled in SLIP support using the stand

[PATCH 1/2] AES-XCBC-MAC

This is preparation to introduce AES-XCBC-MAC. - introducing common interface "keyed hash" - making HMAC use the interface --- commit 9c6b9affbacf12fc1e32868eaa14fef279b2696c tree 67b19707fae179e20bfb8060444f287d0bda7bb1 parent 650fb8382287f7990d5127a82a54295139224606 author Kazunori MIYAZAWA <[EM

[PATCH 2/2] AES-XCBC-MAC

This patch introduces AES-XCBC-MAC using the "keyed hash" interface. It accordingly depends on the previous patch. Signed-off-by: Kazunori MIYAZAWA <[EMAIL PROTECTED]> --- commit f23d1b52e77f339a9eaa89a1b913d6373fe60fb6 tree bab6efc5808414f13dcefb4bb164c3e111000fa3 parent 9c6b9affbacf12fc1e32868e

[PATCH 0/2] AES-XCBC-MAC

Hello, I send two patches which introduce AES-XCBC-MAC. I changed approach to implement it with introducing abstruct interface "keyed_hash" into crypto_tfm. Both HMAC and XCBC use the interface. I put kht_* outside of crt_u because keyed_hash uses pure digest algorithm or encryption algorithm. I

Re: 2.6.17: networking bug??

Mmm. I notice that 2.6.17 has a new sysctl related to this stuff: /proc/sys/net/ipv4/tcp_workaround_signed_windows It makes no difference whatsoever for me here when varied while /proc/sys/net/ipv4/tcp_window_scaling==1. The site www.everymac.com is still not browseable until setting /proc/sys

Re: [PATCH] [2.6.17-rc6] Section mismatch in drivers/net/ne.o during modpost

On Tue, 13 Jun 2006 15:35:29 +1000 Keith Owens wrote: > Mikael Pettersson (on Sun, 11 Jun 2006 02:51:21 +0200 (MEST)) wrote: > >On Sat, 10 Jun 2006 12:13:35 -0700, Randy.Dunlap wrote: > >>On Sat, 10 Jun 2006 14:11:42 +0200 (MEST) Mikael Pettersson wrote: > >> > >>> While compiling 2.6.17-rc6 for a

Re: 2.6.17: networking bug??

Mark Lord wrote: .. The differences I see are widely varying "window sizes". What would cause this? This is from (working) 2.6.16.18: IP silvy.localnet.56224 > 216-145-246-23.rev.dls.net.www: . ack 1 win 1460 IP silvy.localnet.56224 > 216-145-246-23.rev.dls.net.www: P 1:607(606) ack 1 win 14

Re: [RFC/PATCH 1/2] in-kernel sockets API

>+extern int kernel_ioctl(struct socket *sock, int cmd, unsigned long arg); >+ I would prefer naming it kernel_sock_ioctl, since (general) ioctl often done on fds (or struct file * for that matter) rather than sockets. Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubsc

Re: [RFC/PATCH 2/2] update sunrpc to use in-kernel sockets API

On Mon, 12 Jun 2006, Sridhar Samudrala wrote: > > > - sendpage = sock->ops->sendpage ? : sock_no_sendpage; > > > + sendpage = kernel_sendpage ? : sock_no_sendpage; > > > > > > > This is not equivalent. > > > > > Actually, we could make this a simple assignment as we check for > sock->ops

Re: [RFT 0/5] sky2: suspend/resume patchlets

Stephen Hemminger wrote: There were a several problems buried in suspend/resume. The real failure was caused by the idle timer not being stopped/restarted. But several other races, and cleanups were needed. Since I don't have a machine that will suspend successfully with that hardware, I can't t

Re: IPsec and EAGAIN

James Ring <[EMAIL PROTECTED]> wrote: > > I have a couple of questions: are there any patches out which solve this > problem? This is on our todo list but AFAIK there aren't patches for it yet. > http://sourceforge.net/mailarchive/message.php?msg_id=8621194 This patch can lock up your machine w

[2/2] [BRIDGE]: Add support for NETIF_F_HW_CSUM devices

Hi: [BRIDGE]: Add support for NETIF_F_HW_CSUM devices As it is the bridge will only ever declare NETIF_F_IP_CSUM even if all its constituent devices support NETIF_F_HW_CSUM. This patch fixes this by supporting the first one out of NETIF_F_NO_CSUM, NETIF_F_HW_CSUM, and NETIF_F_IP_CSUM that is sup

[1/2] [NET]: Add NETIF_F_GEN_CSUM and NETIF_F_ALL_CSUM

Hi: These patches are based on your net-2.6.18 tree. They add support for NETIF_F_HW_CSUM on bridges. [NET]: Add NETIF_F_GEN_CSUM and NETIF_F_ALL_CSUM The current stack treats NETIF_F_HW_CSUM and NETIF_F_NO_CSUM identically so we test for them in quite a few places. For the sake of brevity, I'

Re: [RFC/PATCH 1/2] in-kernel sockets API

Stephen, On Tue, 13 Jun 2006, Stephen Hemminger wrote: > > @@ -2176,3 +2279,13 @@ EXPORT_SYMBOL(sock_wake_async); > > EXPORT_SYMBOL(sockfd_lookup); > > EXPORT_SYMBOL(kernel_sendmsg); > > EXPORT_SYMBOL(kernel_recvmsg); > > +EXPORT_SYMBOL(kernel_bind); > > +EXPORT_SYMBOL(kernel_listen); > > +EXP

Re: [RFC/PATCH 1/2] in-kernel sockets API

On 6/13/06, Stephen Hemminger <[EMAIL PROTECTED]> wrote: On Mon, 12 Jun 2006 16:56:01 -0700 Sridhar Samudrala <[EMAIL PROTECTED]> wrote: > This patch makes it convenient to use the sockets API by the in-kernel > users like sunrpc, cifs & ocfs2 etc and any future users. > Currently they get to th

Network Performance Comparison between Linux 2.4 and 2.6

Hi , I performed the routing and bridging tests on Linux kernels 2.4.31 and 2.6.16 on a MIPS(4kc) malta Board , with and without iptables rules. I observed that the routing performance is quite better( 15-20% increase) on 2.6 for shorter packet sizes( 64,128 and 256 bytes) and almost equal to tha

Re: Problem authenticating using WPA with bcm43xx-softmac

> I expect that softmac should be listening to the driver as to whether this > capability is available; > however, I'm now up and running once again. Yeah, I think a patch was floating around too! johannes signature.asc Description: This is a digitally signed message part

[RFT 0/5] sky2: suspend/resume patchlets

There were a several problems buried in suspend/resume. The real failure was caused by the idle timer not being stopped/restarted. But several other races, and cleanups were needed. Since I don't have a machine that will suspend successfully with that hardware, I can't test it. -- - To unsubscri

[RFT 1/5] sky2: suspend/resume patchlets

Subject: [RFT 1/5] sky2: set_power_state should be void The set power state function is cleaner if it doesn't return anything. The only caller that could fail is in suspend() and it can check the argument there. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- test.orig/drivers/net/sky2.

[RFT 3/5] sky2: suspend/resume patchlets

Subject: [RFT 3/5] sky2: fix hotplug detect during poll Linus, doesn't understand NAPI. If the poll routine detects no hardware available, it needs to dequeue it self from the network poll list. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- test.orig/drivers/net/sky2.c +++ test/driver

[RFT 5/5] sky2: suspend/resume patchlets

Subject: [RFT 5/5] sky2: stop/start hardware idle timer on suspend/resume The resume bug was cause not by an early interrupt but because the idle timeout was not being stopped on suspend. Also disable hardware IRQ's on suspend. Will need to revisit this with hotplug? Signed-off-by: Stephen Hemmin

[RFT 4/5] sky2: suspend/resume patchlets

Subject: [RFT 4/5] sky2: save/restore base hardware irq during suspend/resume The hardware should be fully shut off during suspend, and the base irq mask restored during resume. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- test.orig/drivers/net/sky2.c +++ test/drivers/net/sky2.c @@

[RFT 2/5] sky2: suspend/resume patchlets

Subject: [RFT 2/5] sky2: don't hard code number of ports It is cleaner, to not loop over both ports if only one exists. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- test.orig/drivers/net/sky2.c +++ test/drivers/net/sky2.c @@ -3430,7 +3430,7 @@ static int sky2_suspend(struct pci_dev *

  1   2   >