On Wed, 2 May 2007, Michal Piotrowski wrote:
> Please take a look at this bug
>
> [15236.638092] kernel BUG at /mnt/md0/devel/linux-git/include/net/tcp.h:739!
> [15236.644860] invalid opcode: [#1]
> [15236.648514] PREEMPT SMP
> [15236.651075] Modules linked in: ipt_MASQUERADE iptable_nat nf
[BNX2]: Print bus information for PCIE devices.
Fix the code to print PCI or PCIE bus information for all devices.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 97ed400..85760f7 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
[BNX2]: Update version and reldate.
Update version to 1.5.10.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 85760f7..605347f 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -1,6 +1,6 @@
/* bnx2.c: Broadcom NX2 network driv
[BNX2]: Restructure PHY event handling.
Restructure by adding bnx2_phy_event_is_set() to make code cleaner
and easier to understand.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index cb74f12..f072028 100644
--- a/drivers/net/bnx2.c
+++ b/d
[BNX2]: Add 1-shot MSI handler for 5709.
The 5709 supports the one-shot MSI handler similar to some of the tg3
chips. In this mode, the MSI disables itself automatically until it
is re-enabled at the end of NAPI poll.
Put the request_irq/free_irq logic in common procedures.
Signed-off-by: Micha
[BNX2]: Add support for 5709 Serdes.
Add PCI ID and code to support the 5709 Serdes PHY.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 944f547..ab58909 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -84,6 +84,7 @@ typedef
[BNX2]: Add indirect spinlock.
The indirect register access method will be used by more than one
caller in BH context (NAPI poll and timer), so a spinlock is required.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index ab58909..cb74f12 1006
[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]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 01977de.
[BNX2]: Re-structure the 2.5G Serdes code.
Add some common procedures to handle enabling and disabling 2.5G.
Add some missing code to resolve flow control.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index a634315..944f547 100644
--- a/dri
[BNX2]: Add ipv6 TSO and checksum for 5709.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 89681b3..01977de 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -4537,35 +4537,49 @@ bnx2_start_xmit(struct sk_buff *skb, struct net_
[BNX2]: Fix register and memory test on 5709.
Tweak registers and memory test range for 5709.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 9f0a067..6d05397 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -3763,10 +3763,11
[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. Set dma_mask and persistent DMA
mask to 40-bit to workaround.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/d
[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()
also needs to be moved to b
[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]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index cffdec3..89681b3 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -
Add 2.5G Serdes support to ethtool user program and ethtool.8 man
page. The missing pause bits are also added to keep ethtool-copy.h
in sync with the kernel's version.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/ethtool-copy.h b/ethtool-copy.h
index 30f5e05..4615ef6 100644
--- a
Version 2 of the BNX2 patchset. I've modified the 40-bit workaround to
just set the dma masks, combined the 5709 firmware into 1 patch which is
now 500K, pulled out the heartbeat chnages, and separated the patch for
ethtool.h. Earlier, I sent 1 patch for ethtool.h for the kernel, and
another patc
[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]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index f98a220..9f0a067 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@
[ETHTOOL]: Add 2.5G bit definitions.
Add 2.5G supported and advertising bit definitions. 2.5G is supported
by the bnx2 driver.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index c6310ae..f2d248f 100644
--- a/include/linux/ethtool
>> 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 that it is
> displayed by default in order to make this
Francois Romieu wrote:
> Please don't trim the Cc:. The bugs must be processed publicly to feed
> the oracle.
Ok.
>
> Jelle Foks <[EMAIL PROTECTED]> :
>> Francois Romieu wrote:
> [...]
>>> Can you:
>>> - send the output of a 'lspci -vvx'
>>>
>> See attached lspci.txt, the ethernet card chip, obv
Robert P. J. Day wrote:
> again, this list contains some CONFIG_ variables that aren't
> technically dead, but *really* should be renamed to not be confused
> with Kconfig variables. there are, however, legitimately dead ones in
> the following in places:
Please post to netdev for networking re
On Wed, 2 May 2007, Scott Wood wrote:
> 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
David Miller wrote:
> From: Patrick McHardy <[EMAIL PROTECTED]>
> Date: Thu, 03 May 2007 02:07:14 +0200
>
>
>>Oops, typo in David's address.
>>
>>David, please look at these patches (especially the last one) on netdev.
>
>
> Sure, no problem.
>
> This netlink stuff is my fault, David H. came t
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 03 May 2007 02:07:14 +0200
> Oops, typo in David's address.
>
> David, please look at these patches (especially the last one) on netdev.
Sure, no problem.
This netlink stuff is my fault, David H. came to the list
asking how to do this and tha
On Wed, 2007-05-02 at 03:07 -0400, Jeff Garzik wrote:
> Michael Chan wrote:
> >
> > @@ -6195,6 +6197,18 @@ bnx2_init_one(struct pci_dev *pdev, const struct
> > pci_device_id *ent)
> > dev->poll_controller = poll_bnx2;
> > #endif
> >
> > + pci_set_drvdata(pdev, dev);
> > +
> > + memcpy
On Wed, 2007-05-02 at 18:59 +0200, Stefan Wenk wrote:
> The situation now is similar as without any modifications. Instead of -5
> (Z_BUF_ERROR)
> we get back -3 (Z_DATA_ERROR) from zlib_inflate. Here is the kernel log
>
> kernel: PPP generic driver version 2.4.2
> pppd[6101]: pppd 2.4.4 started
On Wed, 02 May 2007 17:45:05 -0600
Topher Fischer <[EMAIL PROTECTED]> wrote:
> -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, th
jamal wrote:
> I am keeping the thin 32 bit header, but other than that everything is
> in one TLV. SPD info one to follow..
I think using attributes here wasn't a bad idea since this exports
things that are implementation details and might need to be changed
or extended at some point.
> enum x
Oops, typo in David's address.
David, please look at these patches (especially the last one) on netdev.
Thanks.
Patrick McHardy wrote:
> 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
[NET]: Add __dev_getfirstbyhwtype
Add __dev_getfirstbyhwtype for callers that don't want a reference but
some data from the device and thus need to take the rtnl anyway.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 3c87ab894405bb9997ff07ceb7dde4902762596a
tree 2d2dfae5b5cacaeb4d
[AFS]: Replace rtnetlink client by direct dev_base walking
Replace the large and complicated rtnetlink client by two simple
functions for getting the MAC address for the first ethernet device
and building a list of IPv4 addresses.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 66a
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
repl
[NETLINK]: Fix use after free in netlink_recvmsg
When the user passes in MSG_TRUNC the skb is used after getting freed.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 831e920626706afd5ced0c72ca15c8af340bc157
tree 1320e7a446a55e826f671d32e6b9f35e302eeb0d
parent dc87c3985e9b442c6099
[AFS]: Fix memory leak in SRXAFSCB_GetCapabilities
The interface array is not freed on exit.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit cef7f64469d521dd1dcb991e247ad02e84c3051c
tree bf5b8cd7a7e31053eaf826037c0b9fc97a69cd93
parent 831e920626706afd5ced0c72ca15c8af340bc157
author
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
-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.
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
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,
> >
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'
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 l
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 Giga
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 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
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 Ha
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’:
net/rxrp
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 pass
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 48d8642f
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 48d8642f8e49b2c4e24
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 fu
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.
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 th
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 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;
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 f
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 be
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 a
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 publishing of IP
address takeov
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 0x
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
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, smp_wmb()
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
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
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
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 c
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 obse
(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];
>>
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 fro
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.
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,
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 t
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 ty
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
ATT
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
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] | http://www.thetopher.com
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 lineari
> 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 initial
> 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...
>
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 recently
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 net
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 +10
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.
Wit
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
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 throu
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 http://vger.kernel.org/majordomo-i
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 http:/
> +#ifndef CONFIG_PPC
> if (pdev->class != 0x02) {
> printk(KERN_ERR"NetXen function %d, class %x will not"
> "be enabled.\n",pci_func_id, pdev->class);
> return -ENODEV;
> }
> +#endif
This looks rather wrong. Why would yo
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
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 by:
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 +-
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
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]
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 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
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
Adapt to new skb header access functions.
Signed-off-by: Thomas Klein <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index c7a5614..7211648 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -1803,10 +1803,10 @@ stati
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 sus
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,
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 j
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().
F
1 - 100 of 135 matches
Mail list logo
