[...]
With code commented out I have 1 error / 3 transmitted packets from
DP83815C. I have 1 error / 10 transmitted packets to DP83815C. Maybe
it works at all because I have short cable, only 10m long.
I don't remember any errors with plain 2.6.21.1.
Sorry. I mean transmition errors,
On 5/1/07, Rafal Bilski [EMAIL PROTECTED] wrote:
2.6.21.1 is first kernel which I'm using at this device. Earlier it was
WindowsCE terminal. It is hardware fault. Commenting out the code is my
way to avoid wakeup messages in log, but I don't want to change anything
in vanilla kernel. I'm lucky
Michael Chan wrote:
[BNX2]: Block MII access when ifdown.
The device may be in D3hot state and should not allow MII register
access.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
ACK 1-2
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
Michael Chan wrote:
[BNX2]: Add 40-bit DMA workaround for 5708.
The internal PCIE-to-PCIX bridge of the 5708 has the same 40-bit DMA
limitation as some of the tg3 chips. Use the same workaround used in
tg3. On 64-bit systems without IOMMU, linearize the SKB if any
address is 40-bit.
Michael Chan wrote:
[BNX2]: Fix race conditions when calling register_netdev().
Hot-plug scripts can call bnx2_open() as soon as register_netdev() is
called in bnx2_init_one(). We need to call pci_set_drvdata() and
setup everything before calling register_netdev(). netif_carrier_off()
Michael Chan wrote:
[BNX2]: Save PCI state during suspend.
This is needed to save the MSI state which will be lost during
suspend.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
ACK
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
Michael Chan wrote:
[PATCH 6/20][BNX2]: Update 5708 firmware.
[PATCH 7/20][BNX2]: Update 5709 firmware part 1.
[PATCH 8/20][BNX2]: Update 5709 firmware part 2.
[PATCH 9/20][BNX2]: Update 5709 firmware part 3.
[PATCH 10/20][BNX2]: Update 5709 firmware part 4.
[PATCH 11/20][BNX2]: Update 5709
Michael Chan wrote:
[BNX2]: Put MII register offsets in the bnx2 struct.
The 5709 Serdes device uses non-standard MII register offsets. This
re-structuring will make it easier to support 5709 Serdes.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
ACK patches 12-13
-
To unsubscribe from
From: Jeff Garzik [EMAIL PROTECTED]
Date: Wed, 02 May 2007 03:06:43 -0400
Second, CONFIG_HIGHMEM is a bad test for IOMMU presence. I don't
think you /can/ test for IOMMU presence. Maybe DaveM knows a way
that I do not?
You really can't.
We have platforms that are both IOMMU and non-IOMMU
From: Jeff Garzik [EMAIL PROTECTED]
Date: Wed, 02 May 2007 03:10:05 -0400
NAK. Multiple patches for a single changes means you broke git bisect.
The 5709 firmware update should be in a single changeset (thus, single
patch).
Mailing list limitations aren't even an excuse for this one
any
Michael Chan wrote:
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index c6310ae..f2d248f 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -434,6 +434,7 @@ struct ethtool_ops {
#define SUPPORTED_1baseT_Full (1 12)
#define SUPPORTED_Pause
Michael Chan wrote:
[BNX2]: Add support for 5709 Serdes.
Add PCI ID and code to support the 5709 Serdes PHY.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
ACK patches 15-16
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
Michael Chan wrote:
[BNX2]: Enhance the heartbeat.
In addition to the periodic heartbeat, we're adding a heartbeat
request interrupt when the heartbeat is late. This is useful
especially in -rt kernels where the timer frequently runs late.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
Michael Chan wrote:
[BNX2]: Update version and reldate.
Update version to 1.5.10.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
ACK patches 18-20
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From: Jeff Garzik [EMAIL PROTECTED]
Date: Wed, 02 May 2007 03:17:20 -0400
Michael Chan wrote:
[BNX2]: Enhance the heartbeat.
In addition to the periodic heartbeat, we're adding a heartbeat
request interrupt when the heartbeat is late. This is useful
especially in -rt kernels where
David Miller wrote:
From: Jeff Garzik [EMAIL PROTECTED]
Date: Wed, 02 May 2007 03:17:20 -0400
Michael Chan wrote:
[BNX2]: Enhance the heartbeat.
In addition to the periodic heartbeat, we're adding a heartbeat
request interrupt when the heartbeat is late. This is useful
especially in -rt
From: Jeff Garzik [EMAIL PROTECTED]
Date: Wed, 02 May 2007 03:38:53 -0400
* adding code for a situation that never occurs in the upstream kernel.
What we could do is simply have Ingo carry this bnx2 driver patch in
his -rt patch series, and then it will propagate into upstream as soon
as it
David Miller wrote:
From: Jeff Garzik [EMAIL PROTECTED]
Date: Wed, 02 May 2007 03:38:53 -0400
* adding code for a situation that never occurs in the upstream kernel.
What we could do is simply have Ingo carry this bnx2 driver patch in
his -rt patch series, and then it will propagate into
On Tue, May 01, 2007 at 11:51:41PM -0700, Tim Hockin wrote:
I'm not sure what the right answer is. The code was designed to do
the right thing, and yet in your case it's broken. Does it need to be
a build option to work around broken hardware? Yuck.
Without a system that really needs the
On Wed, May 02, 2007 at 03:38:53AM -0400, Jeff Garzik wrote:
David Miller wrote:
From: Jeff Garzik [EMAIL PROTECTED]
Date: Wed, 02 May 2007 03:17:20 -0400
Michael Chan wrote:
[BNX2]: Enhance the heartbeat.
In addition to the periodic heartbeat, we're adding a heartbeat
request interrupt
On Tue, May 01, 2007 at 10:48:11PM +0200, Beschorner Daniel ([EMAIL PROTECTED])
wrote:
Since 2.6.21 I often got a 2 seconds delay when closing a telnet session
to such a machine (even to localhost).
I was at least not aware of this with older versions, but maybe I'm
wrong?!?
Server with
The order that the two 32-bit words written to the Hash Address (Low,
High) Registers for matching of multicast addresses is incorrect.
Signed-off-by: Lars Reemts [EMAIL PROTECTED]
Signed-off-by: Andrew Victor [EMAIL PROTECTED]
diff -urN linux-2.6.21/drivers/net/arm/at91_ether.c
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
Mainly it allows to communicate between network namespaces but
it can be used as is as well.
Eric recently sent a similar driver
The new command is called veth with the following syntax:
* ip veth add dev1 dev2
creates interconnected pair of veth devices.
* ip veth del dev
destroys the pair of veth devices, where dev is either
dev1 or dev2 used to create the pair.
One question that is to be solved is whether or not
On Tue, 1 May 2007, Samuel Ortiz wrote:
But I will definitely spend some time this week running my IrDA stack
with this patch applied. I didn't bother to do that earlier as you first
reported some oops with this patch applied.
I think, what I reported was not an Oops, but the race that we're
On Tue, 2007-05-01 at 09:54 -0400, John W. Linville wrote:
On Tue, May 01, 2007 at 07:53:38AM -0400, Dan Williams wrote:
On Sat, 2007-04-28 at 20:28 -0400, John W. Linville wrote:
Need to change the libertas Kconfig entry to match changes made for
other wireless drivers.
Pavel Emelianov wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
Mainly it allows to communicate between network namespaces but
it can be used as is as well.
Eric
Daniel Lezcano wrote:
Pavel Emelianov wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
Mainly it allows to communicate between network namespaces but
it can be used as
Pavel Emelianov wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
Mainly it allows to communicate between network namespaces but
it can be used as is as well.
Eric
On Tue, 2007-01-05 at 16:04 -0700, Waskiewicz Jr, Peter P wrote:
I am just gonna delete stuff you had above here because i think you
repeat those thoughts below. Just add back anything missed.
I will try to make this email shorter, but i am not sure i will
succeed;-
1) You want to change the
jamal wrote:
On Wed, 2007-02-05 at 14:34 +0200, Patrick McHardy wrote:
Thats a lot better than using sysfs, but I think it would be
preferrable to use rtnetlink instead of genetlink for network
configuration.
or you can just hold rtnl while using genl.
I do agree it would be easier to
Hi ,
this is the second version of patches I have sent already two days ago.
I removed the kthread_run patch (3/5) .
Patches 1-3 contain fixes,patch 4 includes some
kind of a new feature although it is just an adaption
to the latest OSA hardware specification
and just prints out human readable
From: Ursula Braun [EMAIL PROTECTED]
Frank Pavlic [EMAIL PROTECTED]
Connection hangs when using EDDP mode because sk_protocol is NULL
when skb has been copied via skb_copy. This results in dropping
packets.
Also keep MAC address after recovery of Virtual NICs so that
traffic can flow
From: Ursula Braun [EMAIL PROTECTED]
Free sent skbs in some finite amount of time. Affected are
asynchronous queue of Hipersockets devices and the output
queues of all eth-devices respectively.
Signed-off-by: Ursula Braun [EMAIL PROTECTED]
Signed-off-by: Frank Pavlic [EMAIL PROTECTED]
---
Herbert Xu wrote:
[NETFILTER] sip: Fix RTP address NAT
I needed to use this recently to talk to a Cisco server. In my case
I only did SNAT while the Cisco server used a different address for
RTP traffic than the one for SIP. I discovered that nf_nat_sip NATed
the RTP address to the SIP
From: Peter Tiedemann [EMAIL PROTECTED]
s390: qeth driver hardware specs adaptions
- according to the latest OSA hardware specification
incorporate actual IPA command and return codes into qeth.
- whitespaces removed from qeth_mpc.h
Signed-off-by: Peter Tiedemann [EMAIL PROTECTED]
Cleanup of dev_base list use, with the aim to simplify making
device list per-namespace. In almost every occasion, use of
dev_base variable and dev-next pointer could be easily replaced
by for_each_netdev loop. A few most complicated places were
converted to using first_netdev()/next_netdev().
On Wed, May 02, 2007 at 08:10:55AM -0400, Dan Williams wrote:
On Tue, 2007-05-01 at 09:54 -0400, John W. Linville wrote:
On Tue, May 01, 2007 at 07:53:38AM -0400, Dan Williams wrote:
Will apply, we need to pull in wireless-dev first to get the NET_RADIO
name change.
No, that is
Patrick McHardy [EMAIL PROTECTED] writes:
jamal wrote:
On Wed, 2007-02-05 at 14:34 +0200, Patrick McHardy wrote:
Thats a lot better than using sysfs, but I think it would be
preferrable to use rtnetlink instead of genetlink for network
configuration.
or you can just hold rtnl while
Eric W. Biederman wrote:
The consensus from the last thread was pretty much that we need
to implement RTM_NEWLINK and RTM_DELLINK, if it is at all possible.
Yes, as I said, I can take care of this for 2.6.23.
So that we can get code reuse between different virtual devices.
Although I
Kumar Gala wrote:
On Apr 28, 2007, at 10:47 PM, David Miller wrote:
From: Stephen Rothwell [EMAIL PROTECTED]
Date: Sun, 29 Apr 2007 11:44:46 +1000
So can I take this as a future OK for architecture specific network
drivers changes to go through the architecture trees (cc'd to you)?
It's
On Wed, 2 May 2007 09:12:36 -0500
Kumar Gala [EMAIL PROTECTED] wrote:
I'll pull patches 1, 3, 4 and wait on the dts changes until you sort
of the ucc driver issues with Jeff.
sounds good. I was waiting for the get_property - of_get_propery
patches for ucc_geth before I submitted the
On Apr 28, 2007, at 10:47 PM, David Miller wrote:
From: Stephen Rothwell [EMAIL PROTECTED]
Date: Sun, 29 Apr 2007 11:44:46 +1000
So can I take this as a future OK for architecture specific network
drivers changes to go through the architecture trees (cc'd to you)?
It's been my experience
On Apr 30, 2007, at 2:51 PM, Kim Phillips wrote:
On Fri, 27 Apr 2007 21:25:19 +1000
Paul Mackerras [EMAIL PROTECTED] wrote:
If anyone has patches that I haven't picked up yet which they think
should go into 2.6.22, please send me either a pointer to the
these were missed:
[PATCH 1/4 v5]
hi All,
I will be sending 2 patches for NetXen 1/10G Ethernet driver in
subsequent mails. These patches are wrt netdev#upstream.
Regards,
Mithlesh Thukral
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
NetXen: Fix for driver on System-p
This patch will fix an initialization and ping issue on system-p.
Signed-off by: Milan Bag [EMAIL PROTECTED]
Signed-off by: Adhiraj Joshi [EMAIL PROTECTED]
Acked-by: Mithlesh Thukral [EMAIL PROTECTED]
---
drivers/net/netxen/netxen_nic_init.c |2 +-
NetXen: Changes related to registers and their access routines
This patch updates the various access routines to access different
control and status settings present in different register locations.
This will fix problems related to working of different ports in
multi Port card.
Signed-off
David Miller wrote:
From: Jeff Garzik [EMAIL PROTECTED]
Date: Wed, 02 May 2007 03:06:43 -0400
Second, CONFIG_HIGHMEM is a bad test for IOMMU presence. I don't
think you /can/ test for IOMMU presence. Maybe DaveM knows a way
that I do not?
You really can't.
We have platforms that
On Wed, May 02, 2007 at 08:23:40AM -0700, Michael Chan wrote:
A non-IOMMU system using 64-bit dma_addr_t will always set
CONFIG_HIGHMEM, right?
No.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Michael Chan wrote:
A non-IOMMU system using 64-bit dma_addr_t will always set
CONFIG_HIGHMEM, right?
No.
Jeff
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On May 2, 2007, at 9:17 AM, Jeff Garzik wrote:
Kumar Gala wrote:
On Apr 28, 2007, at 10:47 PM, David Miller wrote:
From: Stephen Rothwell [EMAIL PROTECTED]
Date: Sun, 29 Apr 2007 11:44:46 +1000
So can I take this as a future OK for architecture specific network
drivers changes to go
Kumar Gala wrote:
On May 2, 2007, at 9:17 AM, Jeff Garzik wrote:
Kumar Gala wrote:
On Apr 28, 2007, at 10:47 PM, David Miller wrote:
From: Stephen Rothwell [EMAIL PROTECTED]
Date: Sun, 29 Apr 2007 11:44:46 +1000
So can I take this as a future OK for architecture specific network
drivers
Segher Boessenkool wrote:
The hardware must not see that is given ownership of a buffer until it is
completely written, and when the driver receives ownership of a buffer,
it must ensure that any other reads to the buffer reflect its final
state. Thus, I/O barriers are added where required.
On Wed, 2 May 2007, Jeff Garzik wrote:
Kumar Gala wrote:
On May 2, 2007, at 9:17 AM, Jeff Garzik wrote:
Kumar Gala wrote:
On Apr 28, 2007, at 10:47 PM, David Miller wrote:
From: Stephen Rothwell [EMAIL PROTECTED]
Date: Sun, 29 Apr 2007 11:44:46 +1000
So can I
On Wed, 02 May 2007 14:54:51 +0400
Pavel Emelianov [EMAIL PROTECTED] wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
Mainly it allows to communicate between network
Pavel Emelianov wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
Mainly it allows to communicate between network namespaces but
it can be used as is as well.
Eric
Having looked at the code a bit further, I have a theory that it was
impossible to reach the zlib_inflateSyncPacket call ppp deflate needs.
The patch below fixes that and also adds some debugging so if that isn't
the problem, we might get some further clues as to what the problem
is...
Yup. Works fine. The randomly changing interface order is proving to
be a challenge!
udev should be your friend to do a BUS/ID based rename.
True, but so far I have to force link addrs, force promisc mode, and
now add a udev work-around ;-|
Strange thing is, when the interfaces get
On Wed, 2007-05-02 at 11:29 -0400, Jeff Garzik wrote:
Michael Chan wrote:
A non-IOMMU system using 64-bit dma_addr_t will always set
CONFIG_HIGHMEM, right?
No.
May be I misunderstood the code in illegal_highdma() in net/core/dev.c
where it is checking to see if it needs to linearize the
Does the kernel have any protection against ARP spoofing? If not, does
anybody know why not? (As in, nobody has done anything, or because of A,
B, and C).
Thanks,
--
Topher Fischer
GnuPG Fingerprint: 3597 1B8D C7A5 C5AF 2E19 EFF5 2FC3 BE99 D123 6674
[EMAIL PROTECTED] |
On Wed, 02 May 2007 04:01:04 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
David Miller wrote:
From: Jeff Garzik [EMAIL PROTECTED]
Date: Wed, 02 May 2007 03:38:53 -0400
* adding code for a situation that never occurs in the upstream kernel.
What we could do is simply have Ingo carry
On 5/2/07, Tim Durack [EMAIL PROTECTED] wrote:
Yup. Works fine. The randomly changing interface order is proving to
be a challenge!
udev should be your friend to do a BUS/ID based rename.
Okay, the udev workaround isn't too painful.
Would be great if I could do something like
AFAICS you need stronger barriers though; {w,r,}mb(),
to prevent _any_ reordering of those memory accesses,
not just the compiler-generated ones.
My impression was that the eieio used by iobarrier would be sufficient
for that, as we're not trying to synchronize between accesses to
different
Michael Chan wrote:
On Wed, 2007-05-02 at 11:29 -0400, Jeff Garzik wrote:
Michael Chan wrote:
A non-IOMMU system using 64-bit dma_addr_t will always set
CONFIG_HIGHMEM, right?
No.
May be I misunderstood the code in illegal_highdma() in net/core/dev.c
where it is checking to see if it needs
Topher Fischer wrote:
Does the kernel have any protection against ARP spoofing? If not, does
anybody know why not? (As in, nobody has done anything, or because of A,
B, and C).
Thanks,
If by arp spoofing you mean receiving arp replies from multiple sources and
trusting all of them, then
It was agreed that phy-connection-type was a better name for
the interface-type property, so this patch renames it.
Also, the max-speed property name was determined too generic,
and is therefore eliminated in favour of phy-connection-type
derivation logic.
includes corrections to copyright text.
From: Michael Chan [EMAIL PROTECTED]
Date: Wed, 2 May 2007 08:23:40 -0700
A non-IOMMU system using 64-bit dma_addr_t will always set
CONFIG_HIGHMEM, right?
Nope, IA-64 is at least one example.
IA-64 has both IOMMU and non-IOMMU configurations, and
never sets HIGHMEM.
-
To unsubscribe from
(Gerd, Herbert: there's some questions directed to you down there.)
Rusty Russell wrote:
/*
* {tx,rx}_skbs store outstanding skbuffs. The first entry in tx_skbs
* is an index into a chain of free entries.
*/
struct sk_buff *tx_skbs[NET_TX_RING_SIZE+1];
The hardware must not see that is given ownership of a buffer until it is
completely written, and when the driver receives ownership of a buffer,
it must ensure that any other reads to the buffer reflect its final
state. Thus, I/O barriers are added where required.
Without this patch, I have
On Wed, 2007-05-02 at 14:24 -0400, Jeff Garzik wrote:
Michael Chan wrote:
On Wed, 2007-05-02 at 11:29 -0400, Jeff Garzik wrote:
Michael Chan wrote:
A non-IOMMU system using 64-bit dma_addr_t will always set
CONFIG_HIGHMEM, right?
No.
May be I misunderstood the code in
On May 2, 2007, at 2:57 PM, Scott Wood wrote:
The hardware must not see that is given ownership of a buffer until
it is
completely written, and when the driver receives ownership of a
buffer,
it must ensure that any other reads to the buffer reflect its final
state. Thus, I/O barriers are
Kumar Gala wrote:
I'd rather see a wmb() instead of eieio() to keep this code non-ppc
specific. (also, we implement wmb as eieio, so I don't keep the
comment about it being too heavy, unless you mean generically).
wmb() is a sync, smp_wmb() is an eieio. Andy told me he would not
accept a
David Acker wrote:
Milton Miller wrote:
In commit d52df4a35af569071fda3f4eb08e47cc7023f094, the description
talks about emulating another driver by setting addtional bits and
the being unable to test when submitted. Seeing the operator to
set more bits made me suspicious, and indeed the bits
On May 2, 2007, at 3:12 PM, Scott Wood wrote:
Kumar Gala wrote:
I'd rather see a wmb() instead of eieio() to keep this code non-
ppc specific. (also, we implement wmb as eieio, so I don't keep
the comment about it being too heavy, unless you mean generically).
wmb() is a sync,
Michael Chan wrote:
If CONFIG_HIGHMEM is not set,
wouldn't the device get 32-bit DMA addresses that it cannot handle?
No -- presuming your PCI device's DMA mask is set correctly.
I know that there are 64-bit systems without IOMMUs. That's why we need
[...]
needed or not. These systems
Mithlesh Thukral [EMAIL PROTECTED] :
[...]
diff --git a/drivers/net/netxen/netxen_nic.h
b/drivers/net/netxen/netxen_nic.h
index ad6688e..71edb5c 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -302,29 +302,28 @@ #define FLAGS_IPSEC_SA_ADD 0x04
Kumar Gala wrote:
On May 2, 2007, at 3:12 PM, Scott Wood wrote:
wmb() is a sync, smp_wmb() is an eieio. Andy told me he would not
accept a sync in those spots.
Sorry, was looking at the iobarrier code.
And the driver is already ppc-specific; it uses in/out_be32.
True, but its hidden
On Wed, 2007-05-02 at 12:40 -0700, David Miller wrote:
From: Michael Chan [EMAIL PROTECTED]
Date: Wed, 2 May 2007 08:23:40 -0700
A non-IOMMU system using 64-bit dma_addr_t will always set
CONFIG_HIGHMEM, right?
Nope, IA-64 is at least one example.
IA-64 has both IOMMU and non-IOMMU
Chris Friesen wrote:
Vlad Yasevich wrote:
If by arp spoofing you mean receiving arp replies from multiple
sources and
trusting all of them, then I haven't seen anything.
I don't know the history as to why nothing has has been done.
This concept is a valuable tool to allow for fast
On May 2, 2007, at 3:40 PM, Scott Wood wrote:
Kumar Gala wrote:
On May 2, 2007, at 3:12 PM, Scott Wood wrote:
wmb() is a sync, smp_wmb() is an eieio. Andy told me he would
not accept a sync in those spots.
Sorry, was looking at the iobarrier code.
And the driver is already ppc-specific;
Kumar Gala wrote:
Why doesn't marking the bdp pointer volatile resolve the issue in
gfar_clean_rx_ring() to ensure load ordering?
Because that only addresses compiler reordering (and does so in a rather
clumsy way -- not all accesses need to be strongly ordered), not
hardware reordering.
On Wed, May 02, 2007 at 10:05:31PM +0200, Rafał Bilski wrote:
What about module option?
That would work, though you crossed in the post with me writing a patch
adding a sysfs file; I merged the two for overkill (below). I also have
a patch which changes the log message for the workaround so
From: Michael Chan [EMAIL PROTECTED]
Date: Wed, 02 May 2007 14:27:49 -0700
I see. So IA64 always uses the SWIOTLB when it doesn't have IOMMU then?
I'm a bit confused. Is it enough to just set the DMA mask to 40-bit and
forget about all this checking? I thought that wasn't enough. A tx
Thanks a lot for your response.
However, it is still unclear, since the allocated memory for TCP socket
buffers, which I saw via sockstat, shows zero when calling send() after
recv() as shown in the previous email.
Do you mean that it is necessary to hold the receive buffer allocation
for
Dave,
against net-2.6.22.
I am keeping the thin 32 bit header, but other than that everything is
in one TLV. SPD info one to follow..
cheers,
jamal
[XFRM] SAD info TLV aggregationx
Aggregate the SAD info TLVs.
Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
---
commit
And heres the SPD version also against latest net-2.6
cheers,
jamal
[XFRM] SPD info TLV aggregation
Aggregate the SPD info TLVs.
Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
---
commit 3ff6ef841a7d6c55de1e5e362779d0210be85920
tree cfde9356d22d6a9da1b859cbcf245f3fd0899b62
parent
Stephen,
You need to pull the latest net-2.6 include/linux/xfrm.h for this
(and the earlier migrate stuff from Nakamura-san)...
cheers,
jamal
[XFRM] see SAD info
i.e instead of something like ip xfrm state ls | grep -i src | wc -l
do:
ip xfrm state count
And you get the count; you can also
Please don't trim the Cc:. The bugs must be processed publicly to feed
the oracle.
Jelle Foks [EMAIL PROTECTED] :
Francois Romieu wrote:
[...]
Can you:
- send the output of a 'lspci -vvx'
See attached lspci.txt, the ethernet card chip, obviously, at 00:0b.0
Plain old 8169. Ok.
[...]
Looks like new RXRPC code depends on key storage but doesn't
select it.
CC [M] net/rxrpc/af_rxrpc.o
net/rxrpc/af_rxrpc.c: In function ‘rxrpc_kernel_begin_call’:
net/rxrpc/af_rxrpc.c:302: error: dereferencing pointer to incomplete type
net/rxrpc/af_rxrpc.c: In function ‘af_rxrpc_init’:
Stephen,
This depends on the SAD info patch (and the net-2.6 xfrm.h)
cheers,
jamal
[XFRM] see SPD info
i.e instead of something like ip xfrm policy ls | grep -i src | wc -l
do:
ip xfrm policy count
And you get the count; you can also pass -s or -s -s to see more
details
Signed-off-by: Jamal
On Wed, 2007-05-02 at 14:45 -0700, David Miller wrote:
From: Michael Chan [EMAIL PROTECTED]
Date: Wed, 02 May 2007 14:27:49 -0700
I see. So IA64 always uses the SWIOTLB when it doesn't have IOMMU then?
I'm a bit confused. Is it enough to just set the DMA mask to 40-bit and
forget
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 2 May 2007 15:34:18 -0700
Looks like new RXRPC code depends on key storage but doesn't
select it.
Yes I have some patches from David Howells to deal with this,
will push those soon.
Thanks for reporting.
-
To unsubscribe from this list:
On Tue, 01 May 2007 09:58:28 -0400
Daniel Drake [EMAIL PROTECTED] wrote:
Hi Stephen,
Stephen Hemminger wrote:
This fixes the regression in 2.6.21 for users with 88e8056 on motherboard.
Allow all but the Gigabyte motherboard has some unresolved bus problems.
+ /* Some Gigabyte
From: Michael Chan [EMAIL PROTECTED]
Date: Wed, 02 May 2007 16:28:22 -0700
Is it correct to assume that all 64-bit systems using 64-bit
dma_addr_t will either have real IOMMUs or will use SWIOTLB? If
this is true, we can just set the DMA mask to what is supported by
the hardware and let
On Wed, May 02, 2007 at 01:02:41PM -0700, Michael Chan wrote:
Let's say I have a 32-bit card that cannot do dual address cycle on a
64-bit dma_addr_t system without IOMMU. If CONFIG_HIGHMEM is not set,
wouldn't the device get 32-bit DMA addresses that it cannot handle?
It needs to set it's
From: Christoph Hellwig [EMAIL PROTECTED]
Date: Wed, 2 May 2007 23:48:58 +0100
On Wed, May 02, 2007 at 01:02:41PM -0700, Michael Chan wrote:
Let's say I have a 32-bit card that cannot do dual address cycle on a
64-bit dma_addr_t system without IOMMU. If CONFIG_HIGHMEM is not set,
wouldn't
On Wed, 2007-05-02 at 15:44 -0700, David Miller wrote:
Chrstopher, I really really would like you to post these patches early
and often to netdev@vger.kernel.org especially because you are
touching the TCP code.
You're right, I should have sent this to netdev as well. I'm Sorry.
As for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Friesen wrote:
Vlad Yasevich wrote:
If by arp spoofing you mean receiving arp replies from multiple
sources and
trusting all of them, then I haven't seen anything.
I don't know the history as to why nothing has has been done.
This
And the driver is already ppc-specific; it uses in/out_be32.
True, but its hidden behind the gfar_read/write accessors.
Your change is a bit more blatant.
Well, Segher doesn't want me to use iobarrier (because it's not I/O).
Andy doesn't want me to use wmb() (because it's sync).
You should
These patches fix two bugs introduced by the RXRPC patches. While looking
at the other code that came in with these patches, I noticed it includes
an entire rtnetlink client in the kernel, which doesn't seem to make much
sense since all the information is available in much easier ways, so I've
1 - 100 of 114 matches
Mail list logo
