Michael Buesch wrote:
> On Friday 21 July 2006 21:49, Brice Goglin wrote:
>
>> +myri10ge_pio_copy(mgp->sram + MYRI10GE_FW_OFFSET + i,
>> + fw->data + i,
>> + min(256U, (unsigned)(fw->size - i)));
>> +mb();
>> +
On Fri, 21 Jul 2006 08:22:38 -0700
Auke Kok <[EMAIL PROTECTED]> wrote:
> > And if someone who understands all of these details could put a note
> > in the thinkwiki (say, here:
> > http://www.thinkwiki.org/wiki/Ethernet_Controllers#Intel_Gigabit_.2810.2F100.2F1000.29)
> > it would be greatly appre
From: [EMAIL PROTECTED]
Date: Fri, 21 Jul 2006 15:45:50 +0200
> From: Panagiotis Issaris <[EMAIL PROTECTED]>
>
> Removing useless casts
>
> Signed-off-by: Panagiotis Issaris <[EMAIL PROTECTED]>
Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a
From: Rick Jones <[EMAIL PROTECTED]>
Date: Fri, 21 Jul 2006 09:26:42 -0700
> > All this talk reminds me of one thing, how expensive tcp_ack() is.
> > And this expense has nothing to do with TCP really. The main cost is
> > purging and freeing up the skbs which have been ACK'd in the
> > retransmi
On Friday 21 July 2006 21:49, Brice Goglin wrote:
> When writing the firmware to the NIC, the FIFO is 256-bytes long,
> so we use 256-bytes chunks and a read to wait until the previous
> write is done.
>
> Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>
> ---
> drivers/net/myri10ge/myri10ge.c |
On Fri, Jul 21, 2006 at 09:27:23PM +0200, Michael Buesch wrote:
> What is a major change? Why only on major change? Why not on
> simple changes, too? Simple changes sometimes introduce bugs, too.
the version number has whatever meaning you choose to assign to it.
Including none, if you so choose.
When writing the firmware to the NIC, the FIFO is 256-bytes long,
so we use 256-bytes chunks and a read to wait until the previous
write is done.
Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>
---
drivers/net/myri10ge/myri10ge.c | 20
1 file changed, 8 insertions(+), 12 de
Hi,
The following patches fix 2 minor issues in the myri10ge driver:
1) Always do a dummy RDMA after loading the firmware
2) Write the firmware in 256-bytes chunks
Please apply.
thanks,
Brice
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL P
Always do a dummy RDMA after loading the firmware to work around
buggy PCIe chipsets which do not implement resending properly.
This is so cheap as to be almost free, and should never have been
conditional on the tx boundary != 4096.
Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>
---
drivers/net
On Friday 21 July 2006 21:13, Jason Lunz wrote:
> On Fri, Jul 21, 2006 at 09:03:23PM +0200, Michael Buesch wrote:
> > I am not going to maintain a bogus version number.
> > What about simply returning 1.0 and be done with it.
> > I don't think it matters. 1.0 is as bogus as any other value.
>
> Pu
On Fri, Jul 21, Michael Buesch wrote:
> On Friday 21 July 2006 20:59, Olaf Hering wrote:
> >
> > bcm43xx_get_drvinfo in 2.6.18-rc2 unfortunately uses UTS_RELEASE as
> > driver version. I think this specific info can be obtained by other
> > ways.
> > Can you give bcm43xx a real version number an
On Fri, Jul 21, 2006 at 09:03:23PM +0200, Michael Buesch wrote:
> I am not going to maintain a bogus version number.
> What about simply returning 1.0 and be done with it.
> I don't think it matters. 1.0 is as bogus as any other value.
Put it to use! Increment it whenever there's a major change in
On Friday 21 July 2006 20:59, Olaf Hering wrote:
>
> bcm43xx_get_drvinfo in 2.6.18-rc2 unfortunately uses UTS_RELEASE as
> driver version. I think this specific info can be obtained by other
> ways.
> Can you give bcm43xx a real version number and provide it via the
> ethtool ioctl?
I am not goin
bcm43xx_get_drvinfo in 2.6.18-rc2 unfortunately uses UTS_RELEASE as
driver version. I think this specific info can be obtained by other
ways.
Can you give bcm43xx a real version number and provide it via the
ethtool ioctl?
It will trigger a rebuild if the uname -r of the kernel to build
changes.
-
On 7/21/06, Ralf Baechle <[EMAIL PROTECTED]> wrote:
Aside of wanrouter AX.25 has also been the last member of struct
sock.sk_protinfo. With net/wanrouter being considered hopeless code and
an application-level solution being prefered these days this means we now
can delete sk_protinfo.
/me sh
On Fri, Jul 21, 2006 at 09:14:39AM -0700, Ben Greear ([EMAIL PROTECTED]) wrote:
> >>Out of curiosity, is it possible to have the single producer logic
> >>if you have two+ ethernet interfaces handling frames for a single
> >>TCP connection? (I am assuming some sort of multi-path routing
> >>logic.
All this talk reminds me of one thing, how expensive tcp_ack() is.
And this expense has nothing to do with TCP really. The main cost is
purging and freeing up the skbs which have been ACK'd in the
retransmit queue.
So tcp_ack() sort of inherits the cost of freeing a bunch of SKBs
which haven't b
Evgeniy Polyakov wrote:
On Thu, Jul 20, 2006 at 02:21:57PM -0700, Ben Greear ([EMAIL PROTECTED]) wrote:
Out of curiosity, is it possible to have the single producer logic
if you have two+ ethernet interfaces handling frames for a single
TCP connection? (I am assuming some sort of multi-path ro
With struct sock and ax25_cb in a unified data structure it now is
possible to fix the reference counting by using the sk_reset_timer
and sk_stop_timer helper function - the previous implementation was
based simply on "principle hope".
Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
include/net/
Upto now AX.25 was using two separate structures for it's sockets. One,
ax25_cb described the entire actual AX.25 connection. The other was
the standard struct sock.
This patch combines both into struct ax25_sock which is more in line with
current practice. An AX.25 speciality was that a ax25_c
Theodore Tso wrote:
On Fri, Jul 21, 2006 at 06:41:05AM -0700, Andrew Morton wrote:
It's completely not acceptable to run when the EEPROM checksum fails - you
might even be running with the wrong MAC address, or worse. Lets fix this the
right way instead.
A printk which helps the user to unders
On Fri, Jul 21, 2006 at 06:41:05AM -0700, Andrew Morton wrote:
> > It's completely not acceptable to run when the EEPROM checksum fails - you
> > might even be running with the wrong MAC address, or worse. Lets fix this
> > the
> > right way instead.
>
> A printk which helps the user to underst
On Thu, 20 Jul 2006 10:34:23 -0700
Auke Kok <[EMAIL PROTECTED]> wrote:
> > Okay, perhaps this should be inserted as a comment into the driver,
> > and printk should be fixed to point at this explanation?
> >
> > Can't we enable the driver with the bad checksum, then read the _real_
> > data?
>
>
From: Panagiotis Issaris <[EMAIL PROTECTED]>
Removing useless casts
Signed-off-by: Panagiotis Issaris <[EMAIL PROTECTED]>
---
net/tipc/discover.c |2 +-
net/tipc/ref.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/tipc/discover.c b/net/tipc/discover.c
ind
Hi Francois,
Francois Romieu wrote:
Despite the fact that the newer 8168 has been reported to only work with an
extra alignment (gross hack: s/NET_IP_ALIGN/8/), the serie seems otherwise
fine.
I'll submit an updated serie to correctly support the 8168.
Any word on the updated 8168 patch? Wou
Igor V. Liferenko <[EMAIL PROTECTED]> wrote:
>
> Would you please say why it's 60, and not 52?
The header length / 4 must fit within a single hexadecimal
digit. Therefore the maximum is 15 * 4 = 60.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTE
Compiling (an exotic ?) config I got:
...
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
drivers/built-in.o: In function `bnx2_set_rx_mode':
bnx2.c:(.text+0xd741e): undefined reference to `crc32_le'
drivers/built-in.o: In function `bnx2_test_nvram':
bnx2.c:(.text+0xd9a5
We apologize for multiple receipts.
Eighth Real-Time Linux Workshop
October 12-15, 2006
Lanzhou University - SISE
On Fri, Jul 21, 2006 at 02:46:23AM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> > sk_stream_rmem_schedule(), sk_rmem_alloc and friends...
>
> sk_stream_rmem_schedule() allocates bytes from the global memory pool
> quota for TCP sockets. It is not something will trigger when, for
> example, a
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Fri, 21 Jul 2006 13:39:09 +0400
> On Fri, Jul 21, 2006 at 02:19:55AM -0700, David Miller ([EMAIL PROTECTED])
> wrote:
> > From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> > Date: Fri, 21 Jul 2006 13:06:11 +0400
> >
> > > Receiving side, nor matter if
On Fri, Jul 21, 2006 at 02:19:55AM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> Date: Fri, 21 Jul 2006 13:06:11 +0400
>
> > Receiving side, nor matter if it is socket or netchannel, will drop
> > packets (socket due to queue overfull, netchannels w
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Fri, 21 Jul 2006 13:06:11 +0400
> Receiving side, nor matter if it is socket or netchannel, will drop
> packets (socket due to queue overfull, netchannels will not drop, but
> will not ack (it's maximum queue len is 1mb)).
>
> So both approaches be
On Fri, Jul 21, 2006 at 12:47:13AM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> > > Correct, and too large delay even results in retransmits. You can say
> > > that RTT will be adjusted by delay of ACK, but if user context
> > > switches cleanly at the beginning, resulting in near immediate A
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Fri, 21 Jul 2006 11:10:10 +0400
> On Thu, Jul 20, 2006 at 09:55:04PM -0700, David Miller ([EMAIL PROTECTED])
> wrote:
> > Correct, and too large delay even results in retransmits. You can say
> > that RTT will be adjusted by delay of ACK, but if u
On Fri, Jul 21, 2006 at 09:40:32AM +1200, Ian McDonald ([EMAIL PROTECTED])
wrote:
> >If we consider netchannels as how Van Jackobson discribed them, then
> >mutext is not needed, since it is impossible to have several readers or
> >writers. But in socket case even if there is only one userspace
>
On Fri, Jul 21, 2006 at 11:19:00AM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> On Thu, Jul 20, 2006 at 02:21:57PM -0700, Ben Greear ([EMAIL PROTECTED])
> wrote:
> > Out of curiosity, is it possible to have the single producer logic
> > if you have two+ ethernet interfaces handling frames
On Thu, Jul 20, 2006 at 02:21:57PM -0700, Ben Greear ([EMAIL PROTECTED]) wrote:
> Out of curiosity, is it possible to have the single producer logic
> if you have two+ ethernet interfaces handling frames for a single
> TCP connection? (I am assuming some sort of multi-path routing
> logic...)
I d
On Thu, Jul 20, 2006 at 09:55:04PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> From: Alexey Kuznetsov <[EMAIL PROTECTED]>
> Date: Fri, 21 Jul 2006 02:59:08 +0400
>
> > > Moving protocol (no matter if it is TCP or not) closer to user allows
> > > naturally control the dataflow - when user can
38 matches
Mail list logo
