Hi,
this are the changes to the smc911x driver, which were necessary
to get it running on the Magic Panel R2 (smsc9115).
It is a SH3-DSP based board. The other patches are available on
the linuxsh-dev mailinglist.
http://marc.info/?l=linuxsh-dev&r=1&b=200708&w=2
It was necessary to set the irq s
Hi Arnaldo Carvalho de Melo:
Em Mon, Aug 20, 2007 at 09:28:27AM +0800, Wei Yongjun escreveu:
If ICMP6 message with "Packet Too Big" is received after send SCTP DATA,
kernel panic will occur when SCTP DATA is send again.
This is because of a bad dest address when call to skb_copy_bits().
The
In article <[EMAIL PROTECTED]> (at Mon, 20 Aug 2007 09:28:27 +0800), Wei
Yongjun <[EMAIL PROTECTED]> says:
> If ICMP6 message with "Packet Too Big" is received after send SCTP DATA,
> kernel panic will occur when SCTP DATA is send again.
>
> This is because of a bad dest address when call to skb
Em Mon, Aug 20, 2007 at 09:28:27AM +0800, Wei Yongjun escreveu:
> If ICMP6 message with "Packet Too Big" is received after send SCTP DATA,
> kernel panic will occur when SCTP DATA is send again.
>
> This is because of a bad dest address when call to skb_copy_bits().
>
> The messages sequence is l
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andi Kleen
> Sent: Sunday, August 19, 2007 4:28 PM
> To: Felix Marti
> Cc: David Miller; [EMAIL PROTECTED]; netdev@vger.kernel.org;
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject:
> -Original Message-
> From: David Miller [mailto:[EMAIL PROTECTED]
> Sent: Sunday, August 19, 2007 6:06 PM
> To: Felix Marti
> Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: [ofa-general] Re: [P
On Sat, Aug 18, 2007 at 11:36:24AM -0500, Kumar Gala wrote:
> This patch seems to mix moving to using the device tree directly w/o
> some other modifications. Can it be broken into those two changes as
> they'd be easier to review.
The last iteration of these patches, I got complaints that I
If ICMP6 message with "Packet Too Big" is received after send SCTP DATA,
kernel panic will occur when SCTP DATA is send again.
This is because of a bad dest address when call to skb_copy_bits().
The messages sequence is like this:
Endpoint A Endpoint B
Someone wrote me with a solution to try and so far
it's working. They suggested I try the driver up on
Marvell's website but to make sure I powered off the
machine completely and when it rebooted to not have
any of the regular kernel drivers for the Marvell
chipset to load. They had found that le
From: "Felix Marti" <[EMAIL PROTECTED]>
Date: Sun, 19 Aug 2007 17:47:59 -0700
> [Felix Marti]
Please stop using this to start your replies, thank you.
> David and Herbert, so you agree that the user<>kernel
> space memory copy overhead is a significant overhead and we want to
> enable zero-copy
> -Original Message-
> From: David Miller [mailto:[EMAIL PROTECTED]
> Sent: Sunday, August 19, 2007 5:40 PM
> To: Felix Marti
> Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: [ofa-general] Re: [P
From: "Felix Marti" <[EMAIL PROTECTED]>
Date: Sun, 19 Aug 2007 17:32:39 -0700
[ Why do you put that "[Felix Marti]" everywhere you say something?
It's annoying and superfluous. The quoting done by your mail client
makes clear who is saying what. ]
> Hmmm, interesting... I guess it is impossib
> -Original Message-
> From: David Miller [mailto:[EMAIL PROTECTED]
> Sent: Sunday, August 19, 2007 4:04 PM
> To: Felix Marti
> Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: [ofa-general] Re: [P
Felix Marti <[EMAIL PROTECTED]> wrote:
>
> [Felix Marti] Aren't you confusing memory and bus BW here? - RDMA
> enables DMA from/to application buffers removing the user-to-kernel/
> kernel-to-user memory copy with is a significant overhead at the
> rates we're talking about: memory copy at 20Gbps
From: "John W. Linville" <[EMAIL PROTECTED]>
Date: Tue, 14 Aug 2007 20:34:10 -0400
> Johannes Berg (1):
> radiotap parser: accept all other fields
>
> Larry Finger (1):
> mac80211: Add SIOCGIWTXPOWER routine
I've rebased net-2.6.24 and added in these two wireless
patches, thanks!
-
T
From: Andi Kleen <[EMAIL PROTECTED]>
Date: 20 Aug 2007 01:27:35 +0200
> "Felix Marti" <[EMAIL PROTECTED]> writes:
>
> > what benefits does the TSO infrastructure give the
> > non-TSO capable devices?
>
> It improves performance on software queueing devices between guests
> and hypervisors. This
From: "Felix Marti" <[EMAIL PROTECTED]>
Date: Sun, 19 Aug 2007 12:49:05 -0700
> You're not at all addressing the fact that RDMA does solve the
> memory BW problem and stateless offload doesn't.
It does, I just didn't retort to your claims because they were
so blatantly wrong.
-
To unsubscribe fro
On 19-Aug-07, at 2:34 PM, Stephen Hemminger wrote:
The driver prints some chip version info at startup, that might
be helpful in disambiguating good/bad versions:
dmesg | grep sky2
sky2 :03:00.0: v1.16 addr 0xfa00 irq 16 Yukon-EC Ultra (0xb4)
rev 2
sky2 eth0: addr XX:XX:XX
"Felix Marti" <[EMAIL PROTECTED]> writes:
> what benefits does the TSO infrastructure give the
> non-TSO capable devices?
It improves performance on software queueing devices between guests
and hypervisors. This is a more and more important application these
days. Even when the system running th
> -Original Message-
> From: David Miller [mailto:[EMAIL PROTECTED]
> Sent: Sunday, August 19, 2007 12:32 PM
> To: Felix Marti
> Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: [ofa-general] Re: [
From: "Felix Marti" <[EMAIL PROTECTED]>
Date: Sun, 19 Aug 2007 10:33:31 -0700
> I know that you don't agree that TSO has drawbacks, as outlined by
> Roland, but its history showing something else: the addition of TSO
> took a fair amount of time and network performance was erratic for
> multiple k
--- Stephen Hemminger
<[EMAIL PROTECTED]> wrote:
> The driver prints some chip version info at startup,
> that might
> be helpful in disambiguating good/bad versions:
>
> dmesg | grep sky2
Here's the output from the working MB:
sky2 :04:00.0: v1.14 addr 0xf800 irq 16
Yukon-EC Ult
The driver prints some chip version info at startup, that might
be helpful in disambiguating good/bad versions:
dmesg | grep sky2
-
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
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:general-
> [EMAIL PROTECTED] On Behalf Of David Miller
> Sent: Sunday, August 19, 2007 12:24 AM
> To: [EMAIL PROTECTED]
> Cc: netdev@vger.kernel.org; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Sub
--- Stephen Hemminger
<[EMAIL PROTECTED]> wrote:
> The working board has a different version of the
> Marvell chip:
>
> $ grep Marvell working-MB
> 04:00.0 Ethernet controller: Marvell Technology
> Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller
> (rev 14)
> $ grep Marvell broken-MB
> 04:
On Sat, 18 Aug 2007 06:59:08 -0700 (PDT)
Kevin E <[EMAIL PROTECTED]> wrote:
> --- Willy Tarreau <[EMAIL PROTECTED]> wrote:
>
> > OK, in this trace, both controllers are on the same
> > bus. The broken
> > one has 'Capabilities: [100] Advanced Error
> > Reporting' the other
> > does not have, and
I noticed that FreeBSD has a useful SOL_SOCKET option, SO_NOSIGPIPE, which
is a "sticky" version of MSG_NOSIGNAL. Particularly useful for libraries,
it disables SIGPIPE on a particular socket without disabling it globally.
Anyway, this led me to look at the implementation of SIGPIPE and
MSG_NOSIG
From: "Sean Hefty" <[EMAIL PROTECTED]>
Date: Sun, 19 Aug 2007 00:01:07 -0700
> Millions of Infiniband ports are in operation today. Over 25% of the top 500
> supercomputers use Infiniband. The formation of the OpenFabrics Alliance was
> pushed and has been continuously funded by an RDMA customer
>Just be realistic and accept that RDMA is a point in time solution,
>and like any other such technology takes flexibility away from users.
All technologies are just point in time solutions. While management is
important, shouldn't the customers decide how important it is relative to their
proble
29 matches
Mail list logo
