It kind of surprised me that sending 254 arp packets by using the arp-scan
tool (http://www.nta-monitor.com/tools/arp-scan/) on a /24 consistently
triggers a burst of "eth0: excessive work at interrupt."
This is a 600 MHz PIII, 2.6.22-rc4, via-velocity driver.
model name : Pentium III (Katma
[EMAIL PROTECTED] wrote:
> I wonder if it at some time will be included in the standard Linux kernel?
> I am of course interested because my main board has it built in, so I
> would be willing to test it.
"Me, too!"
This has been discussed sporadically for the last year, and
> Use the 'sundance' driver that's been in the kernel for quite a while.
Er... that driver specifically does not list the IP1000's PCI device ID
(13f0:1023), nor does it support anything over 100 Mbit/s.
Are you *quite* sure that adding 13f0:1023 to the sundance_pci_tbl is
all that's required?
-
The following hacks to bring it up to date got the vendor-supplied
driver working for me. This is just fixing the things the compiler
complained about; there may be other issues, but they don't seem to
interfere with basic funtionality.
diff --git a/Makefile b/Makefile
index c91b384..31e4172 100
(Resend to netdev; already sent to relevant individuals.)
Here's a possible fix for the p[] array issues akpm noticed.
This replaces them with calls to a new mdio_write_bits function.
Boot-tested, passes net traffic, and mii-tool and mii-diag produce sensible
output (including noticing link statu
Uniprocessor Althlon 64, 64-bit kernel, 2G ECC RAM,
2.6.23-rc8 + linuxpps (5.0.0) + ip1000a driver.
(patch from http://marc.info/?l=linux-netdev&m=118980588419882)
After a few hours of operation, ntp loses the ability to send packets.
sendto() returns -EAGAIN to everything, including the 24-
> ntpd. Sounds like pps leaking to me.
That's what I'd think, except that pps does no allocation in the normal
running state, so there's nothing to leak. The interrupt path just
records the time in some preallocated, static buffers and wakes up
blocked readers. The read path copies the latest d
dev_kfree_skb), but was presumably useful to someone during development.
> Where did you get your ipg.c from, btw? davem's tree? rc8-mm1? rc8-mm2??
As I wrote originally, I got it from
http://marc.info/?l=linux-netdev&m=118980588419882
which was a reuqest for mainline submission.
I
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
a black-screen lockup with
>> keyboard LEDs blinking, but that was with X running so I couldn't see a
>> console oops. But given that I installed 2.6.24-rc6 about 24 hours ago,
>> that's a disturbing pattern.
> It is probably this one:
>
> http://marc.info/?t=11978279
>> Thanks! I got the patch from
>> http://marc.info/?l=linux-netdev&m=119756785219214
>> (Which didn't make it into -rc7; please fix!)
>> and am recompiling now.
> Jeff is busy so he's asked me to pick up the more important
> driver bug fixes that g
It doesn't look like you need a test report, but here's one anyway...
I grabbed the patch series from git and am running it successfully
right now.
--
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.
Just to keep the issue open, drivers/net/ipg.c currently in 2.6.24-rc6
still leaks skbuffs like a sieve. Run it for a few hours with network
traffic and the machine swaps like crazy while the oom killer goes nuts.
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index d9107e5..4fa392c 10064
Prompted by davem, this attempt at fixing the memory leak
actually appears to work. At least, leaving ping -f -s1472 -l64
running doesn't drop packets and doesn't show up in /proc/slabinfo.
---
diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
index dbd23bb..a0dfba5 100644
--- a/drivers/net/ipg.c
akpm noticed that this code was awful.
ipg.c | 158
+- 1 file
changed, 43 insertions(+), 115 deletions(-)
should be sufficient justification all by itself.
---
diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
index 3860fcd..b3d3fc
This is a fairly basic code cleanup that annoyed me while working
on the first patch.
---
diff --git a/drivers/net/ipg.h b/drivers/net/ipg.h
index d5d092c..5d7cc84 100644
--- a/drivers/net/ipg.h
+++ b/drivers/net/ipg.h
@@ -789,11 +789,6 @@ struct ipg_rx {
__le64 frag_info;
};
-struct SJu
I take that back. This patch does NOT fix the leak, at least if
ping: sendmsg: No buffer space available
is any indication...
I think I was reading slabinfo wrong.
kmalloc-2048 42111 42112 204842 : tunables000 :
slabdata 10528 10528 0
Sorry for the false hope
>> +do {
>> +/* IPG_PC_MGMTDATA is a power of 2; compiler knows to shift */
>> +u8 d = ((data >> --len) & 1) * IPG_PC_MGMTDATA;
>> +/* + rather than | lets compiler microoptimize better */
>> +ipg_drive_phy_ctl_low_high(ioaddr, d + otherbits);
>>
> Can you try the patch below ?
Testing now... (I presume you noticed the one-character typo in my
earlier patch. That should be "mc = mc->next", not "mv = mc->next".)
That doesn't seem to do it. Not entirely, at least. After downloading
and partially re-uploading an 800M file, slabtop reports
Just some idle brainstorming on the subject...
It seems the only way to handle network pipes sigificantly larger (delay *
bandwidth product) than the processor cache is to make freeing retransmit
data o(n).
Now, there are some ways to reduce the constant factor. The one that
comes to mind first
I'm just about to test that second memory leak patch, but I gave the
original code a careful reading, and found a few problems:
* Huge monstrous glaring bug
In ipg_interrupt_handler the code to habdle a shared interrupt
not caused by this device:
if (!(status & IPG_IS_RSVD_MASK))
Thank you very much, this appears to work.
> The driver is still a POMS but it seems better now.
I notice that the vendor-supplied driver doesn't have these bugs.
Now, it does have a bug in that it doesn't have an "is this
interrupt for me?" test at all (and always returns "I handled it"),
but th
I noticed in an LCA talk mention that apprently extensible hashing
with RCU access is an unsolved problem. Here's an idea for solving it.
I'm assuming the table is a power of 2 in size with open chaining
for collisions. When the chains get too long, the table is doubled.
When the chains get too
> For purposes of discussion, I've attached a "toy" implementation
> for doing dynamic resizing of a hashtable. It is useless, except
> as a proof of concept.
>
> I think this is very similar to what you are describing, no?
Er... not quite; that has a lot more overhead than what I was
thinking ab
> I think you misunderstood me. If you are trying to DoS me from
> outside with a hash collision attack, you are trying to feed me
> packets that fall into the same hash bucket. The Jenkins hash does
> not have to be artifact-free, and does not have to be
> cryptographically strong. It just has
-speed timestamp counters are widely available, as
are > 1 GHz clock rates, making for a rich source of clock jitter.
Oh, and on the theoretical front, there's been a lot of research
into so-called "randomness extraction functions". In particular,
it's been shown that Shanno
I have a machine (x86-32, 2.6.20.3) with two ethernet interfaces:
a 100M Tulip and a 1G VIA Velocity. Both are connected to a common
VLAN-capable switch. The eventually desired configuration is VLAN
support on the Gbit interface.
If I set the Tulip's switch port to tagged, and configure a VLAN o
>> Or should I just get a different gigabit card ?
>
> This one probably got answered the 2005/11/29. :o)
Ah, that's where I asked before. I misplaced the e-mail.
I hope you don't mind my asking every year or two.
But I don't see any suggestions for an alternative gigabit
card anywhere. I had a
> Result with jenkins:
> 1 23880
> 2 12108
> 3 4040
> 4 1019
> 5 200
> 6 30
> 7 8
> 8 1
>
> Xor:
> 1 65536
Precisely. This means that the Xor hash SUCKS, because its output is
conspicuously
non-random.
What you expect is a Poisson distribution, where the chance that a chain will
contain
k ele
I've got a rather awkward debugging situation.
I helped a friend in another city set up a dual-boot Linux/Windows box
a while ago, and it just got a motherboard upgrade. Unfortunately, I
had followed my usual instincts and built a custom kernel which didn't
include the new motherboard
changed now.
(Of course, I have only recently gotten my fingers to stop auto-completing
"vger.rutgers.edu", so that might have been a while ago...)
> If you can put the card in a crashme/testme computer, feel free to try
> the patches at:
> http://www.zoreil.com/~romieu/linux/kernel
> I expect the worst behavior to simply translate into a mute interface
> with or without VLAN but...
Actually, I upgraded to 2.6.15-rc3 plus your patches, and the behaviour
is simply exactly the same. (I've only compiled one 2.6.15-rc3 kernel,
so I can't have possibly booted the wrong one.) Tcp
L.S.,
Just tested 4.8.0-rc1, but i get the stack trace below, everything seems
to continue fine afterwards though
(haven't tried to bisect it yet, hopefully someone has an insight
without having to go through that :) )
My network config consists of a bridge and NAT.
--
Sander
[10469.336815]
Hi,
Running on Xen testing a 4.2-rc4 kernel it got the crash below.
Could this be related to the changes in
3bb475a3446facd0425d3f2fe7e85bf03c5c6c05 ?
It crashes dom0 when i put some strain onto the network + bridge.
--
Sander
[ 2108.078763] general protection fault: [#1] SMP
[ 2108.1
Hi,
On my box running Xen with a 4.2-rc6 kernel i still get this splat in
dom0,
which crashes the box.
(i reported a similar splat before (at rc4) here,
http://www.spinics.net/lists/netdev/msg337570.html)
Never seen this one on 4.1, so it seems a regression.
--
Sander
[81133.193439] gener
ion in
interrupt
This looks like the bug fixed in David Miller net tree :
http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=2235f2ac75fd2501c251b0b699a9632e80239a6d
Will pull the net-tree in and re-test.
But since it only seems to crash after a day or two, that will take some
vmsg api to access ptr ring
tuntap: remove usage of ptr ring in vhost_net
drivers/net/tap.c | 44 ++-
drivers/net/tun.c | 45 +++-
drivers/vhost/net.c| 79 ++
include/linux/if_tun.h | 9 +++--
4 files
++---
drivers/net/tun.c | 8 ++--
drivers/vhost/net.c| 4 ++--
include/linux/if_tun.h | 6 +++---
4 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index 3ae70c7e6860..01bd260ce60c 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
batch processed in
tun_recvmsg.
Signed-off-by: Prashant Bhole
---
drivers/net/tap.c | 22 +++-
drivers/net/tun.c | 24 +-
drivers/vhost/net.c| 46 +-
include/linux/if_tun.h | 3 +++
4 files changed, 83 inser
From: Prashant Bhole
Remove usage of ptr ring of tuntap in vhost_net and remove the
functions exported from tuntap drivers to get ptr ring.
Signed-off-by: Prashant Bhole
---
drivers/net/tap.c | 13 -
drivers/net/tun.c | 13 -
drivers/vhost/net.c | 31 ---
when it's working.
I will write some pages into the Wiki for these versions, so everyone
can test them.
I am not a big kernel hacker but I want to learn it too.
Hauke Mehrtens
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enig
Hi,
I want to make a bond with my wireless card. The ipw driver create two
interfaces (wlan0 and wmaster0). When i switch the rf_kill button,
ifplug detect wlan0 unplugged but not wmaster0. If i down wlan0 (while
rf_kil ), bonding detect the inactivity when i up the interface.
Have you some id
I'm doing a bonding with my eth0(e1000 driver) and my wlan
card(iwl4965). It work like i want, when i'm in wifi the dhcp give me my
ethernet
adress. When i unplug the cable, my wlan card become in charge of
network. My problem is when i disconnect the wlan card, the bonding does not
detect it
I ignore it, but it seems like it prevent bonding detect link of wlan0. I
enslave wlan0 and i already use use_carrier=1;
I use bond to have my etherenet ip in wifi at office, else the wireless
connection give temporary and you must pass through proxy then.
I'll try arp monitoring but this is anno
t.
In general, though, I have not tested bonding with wireless
adapters, so I'm unfamiliar with how well it does or does not work.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED]
_
ooked into the
details of doing that, but in theory it sounds straightforward.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED]
>
>- Message d'origine
>De : Jay Vosburgh <[EMAIL PROTECTED]>
>À : [EMAIL PROTECTED]
>Cc : John W. Linville &
ip_target
echo -20.0.0.1 > /sys/class/net/bond0/bonding/arp_ip_target
You can check out Documentation/networking/bonding.txt (in the
kernel source code) for more details.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED]
>- Message d'origine
&g
hi, everybody
my name is Mariusz, I am newbie to linux kernel,
For several weeks I have been writing kernel driver for network card based on
rtl8139c chip. I am writing this driver for micrococontrollers technology
course in my university
I have some problems with DMA, i suppose.
there is a
MV88E6085 switch not passing IPv6 multicast packets to CPU.
Seems to be related to interface not being in promiscuous mode.
This issue has been ongoing since at least July 2020. Latest v5.10-rc3
still suffers the issue on a Turris Mox with mv88e6085. We've not been
able to reproduce it on the Tur
On 14/11/2020 15:56, Andrew Lunn wrote:
>> 1) with isc-dhcp-server configured with very short lease times (180
>> seconds). After mox reboot (or systemctl restart systemd-networkd)
>> clients successfully obtain a lease and a couple of RENEWs (requested
>> after 90 seconds) but then all goes silent
On 14/11/2020 18:49, Vladimir Oltean wrote:
> On Sat, Nov 14, 2020 at 03:39:28PM +, Tj (Elloe Linux) wrote:
>> MV88E6085 switch not passing IPv6 multicast packets to CPU.
> Is there a simple step-by-step reproducer for the issue, that doesn't
> require a lot of configura
[On 15/11/2020 16:02, Andrew Lunn wrote:
> What might be interesting is running
>
> ip monitor
>
> and
>
> bridge monitor
>
> Look for neighbours being timed out do to inactivity.
Funny you write that! This afternoon I've narrowed it down although I
still don't understand the 'why'.
Watching
On 15/11/2020 17:27, Andrew Lunn wrote:
> So check if you have an IGMP querier in the network. If not, try
> turning it on in the bridge,
>
> ip link set br0 type bridge mcast_querier 1
Thanks Andrew - that does indeed seem to have solved the issue.
I'm relieved this isn't a hardware or driver
On 15/11/2020 17:27, Andrew Lunn wrote:
> So check if you have an IGMP querier in the network. If not, try
> turning it on in the bridge,
>
> ip link set br0 type bridge mcast_querier
Thankfully it turns out this is totally unrelated to Linux - our TP-Link
Jetstream T1600G
On a recent build (5.10.0) we've seen several hard-to-pinpoint complete
lock-ups requiring power-off restarts.
Today we found a small clue in the kernel log but unfortunately the
complete backtrace wasn't captured (presumably system froze before log
could be flushed) but I thought I should share i
> As another thought do you know what DHCPv6 client/server is being
> used.
> There was a fairly recent bugfix for busybox that was needed because
>the v6 code was using the wrong MAC address.
I'm the customer experiencing this issue. It appears unrelated to the
DHCP server software. On the Turris
Is this patch submitted into kernel tree? What version of kernel will have
this patch applied (thinking on 2.6.x and 2.4.x branchs)?
Thanks
El Jue, 12 de Octubre de 2006, 20:24, Stephen Hemminger escribió:
> Flush the forwarding table when carrier is lost. This helps for
> availability because we
On Fri, May 04, 2018 at 03:56:32PM +0200, Antoine Tenart wrote:
> SFP connectors can be solder on a board without having any of their pins
> (LOS, i2c...) wired. In such cases the SFP link state cannot be guessed,
> and the overall link status reporting is left to other layers.
>
> In order to ach
On Fri, May 04, 2018 at 03:56:33PM +0200, Antoine Tenart wrote:
> In case no Tx disable pin is available the SFP modules will always be
> emitting. This could be an issue when using modules using laser as their
> light source as we would have no way to disable it when the fiber is
> removed. This p
On Fri, May 04, 2018 at 05:10:54PM +0200, Antoine Tenart wrote:
> In an SFP EEPROM values can be read to get information about a given SFP
> module. One of those is the bitrate, which can be determined using a
> nominal bitrate in addition with min and max values (in %). The SFP code
> currently co
On Fri, May 04, 2018 at 05:21:03PM +0200, Antoine Tenart wrote:
> When computing the bitrate using values read from an SFP module EEPROM,
> we use the nominal BR plus BR,min and BR,max to determine the
> boundaries. But in some cases BR,min and BR,max aren't provided, which
> led the SFP code to en
bootlin
Comphy code instead.
Of course, the perfect solution would be to get the whole series merged,
but I'm just thinking about the situation where we're still discussing
points when the next merge window opens.
Thanks.
> ---
> include/linux/phy/phy.h | 1 +
> 1 file changed,
On Sat, May 05, 2018 at 01:35:34PM -0700, Florian Fainelli wrote:
> On May 4, 2018 8:21:03 AM PDT, Antoine Tenart
> wrote:
> >When computing the bitrate using values read from an SFP module EEPROM,
> >we use the nominal BR plus BR,min and BR,max to determine the
> >boundaries. But in some cases B
On Sat, May 05, 2018 at 10:52:42PM +0200, Andrew Lunn wrote:
> On Sat, May 05, 2018 at 01:38:31PM -0700, Florian Fainelli wrote:
> > On May 4, 2018 10:14:25 AM PDT, Andrew Lunn wrote:
> > >On Fri, May 04, 2018 at 10:07:53AM -0700, Florian Fainelli wrote:
> > >> On 05/04/2018 06:56 AM, Antoine Tena
On Thu, May 10, 2018 at 01:17:31PM -0700, Florian Fainelli wrote:
> From: Russell King
>
> When using a fixed link with a link GPIO, we need to poll that GPIO to
> determine link state changes. This is consistent with what fixed_phy.c does.
>
> Signed-off-by: Florian Fainelli
I'd like this to
drivers/net/ethernet/marvell/mvneta.c | 4 +++-
> drivers/net/phy/phylink.c | 6 +-
> include/linux/phylink.h | 10 --
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvneta.c
> b/drivers/ne
On Wed, Mar 28, 2018 at 03:33:57AM -0700, Joe Perches wrote:
> On Wed, 2018-03-28 at 11:18 +0100, Russell King wrote:
> > Cotsworks modules fail the checksums - it appears that Cotsworks
> > reprograms the EEPROM at the end of production with the final product
> > information (serial, date code, an
On Wed, Mar 28, 2018 at 09:19:01AM -0700, Joe Perches wrote:
> On Wed, 2018-03-28 at 11:41 +0100, Russell King - ARM Linux wrote:
> > On Wed, Mar 28, 2018 at 03:33:57AM -0700, Joe Perches wrote:
> > > On Wed, 2018-03-28 at 11:18 +0100, Russell King wrote:
> > > &
Florian Fainelli
Similar comments to previous version wrt documentation, but...
Acked-by: Russell King
> ---
> drivers/net/ethernet/marvell/mvneta.c | 4 +++-
> drivers/net/phy/phylink.c | 4 +++-
> include/linux/phylink.h | 10 --
> 3 files
---
> drivers/net/phy/phylink.c | 28
> drivers/net/phy/sfp-bus.c | 6 ++
> include/linux/netdevice.h | 3 +++
> include/linux/phylink.h | 3 ---
> net/core/ethtool.c| 7 +++
>
cess into netdev core
> ethtool
>
> drivers/net/ethernet/marvell/mvneta.c | 22 +++---
> drivers/net/phy/phylink.c | 32 +++-
> drivers/net/phy/sfp-bus.c | 6 ++
> include/linux/netdevice.h | 3 +++
> include/linux/phylink.h
On Thu, Aug 10, 2017 at 05:21:12PM +0200, Andrew Lunn wrote:
> On Thu, Aug 10, 2017 at 12:35:50AM +0300, Dan Carpenter wrote:
> > "ret" isn't necessarily initialized here.
> >
> > Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
> > Signed-off-by: Dan Carpenter
>
> Reviewed-by: Andrew
On Sun, Aug 20, 2017 at 01:28:06PM +0300, Baruch Siach wrote:
> Add device-tree binding documentation SFP transceivers. Support for SFP
> transceivers has been recently introduced (drivers/net/phy/sfp.c).
>
> Signed-off-by: Baruch Siach
> ---
>
> The SFP driver is on net-next.
>
> Not sure abou
On Mon, Aug 21, 2017 at 02:10:33PM -0500, Rob Herring wrote:
> On Sun, Aug 20, 2017 at 5:28 AM, Baruch Siach wrote:
> > Add device-tree binding documentation SFP transceivers. Support for SFP
> > transceivers has been recently introduced (drivers/net/phy/sfp.c).
> >
> > Signed-off-by: Baruch Siach
On Mon, Aug 21, 2017 at 02:12:42PM -0500, Rob Herring wrote:
> On Mon, Aug 21, 2017 at 10:06 AM, Baruch Siach wrote:
> > Hi Russell,
> >
> > On Mon, Aug 21, 2017 at 01:53:17PM +0100, Russell King - ARM Linux wrote:
> >> On Sun, Aug 20, 2017 at 01:28:06PM +0300,
On Mon, Aug 21, 2017 at 06:06:53PM +0300, Baruch Siach wrote:
> Hi Russell,
>
> On Mon, Aug 21, 2017 at 01:53:17PM +0100, Russell King - ARM Linux wrote:
> > Note that I didn't expect the SFP code to just get merged with very
> > little in the way of real in-d
On Thu, Aug 24, 2017 at 04:56:09PM +0200, Andrew Lunn wrote:
> On Thu, Aug 24, 2017 at 10:38:19AM +0200, Antoine Tenart wrote:
> > This patch adds logic to reconfigure the comphy/gop when the link status
> > change at runtime. This is very useful on boards such as the mcbin which
> > have SFP and E
On Thu, Aug 24, 2017 at 06:57:43PM +0200, Andrew Lunn wrote:
> > I see what could be the issue but I do not understand one aspect though:
> > how could we switch from one PHY to another, as there's only one output
> > between the SoC (and so a given GoP#) and the board. So if a given PHY
> > can ha
On Thu, Aug 24, 2017 at 07:45:19PM +0200, Andrew Lunn wrote:
> > The 88x3310 driver in the kernel knows about these combinations and
> > sets the phy interface parameter correctly depending on whether the
> > PHY has configured itself for copper at whatever speed or SFP+.
>
> So when the PHY decid
On Thu, Aug 24, 2017 at 07:14:18PM +0200, Antoine Tenart wrote:
> On Thu, Aug 24, 2017 at 05:08:29PM +, Stefan Chulski wrote:
> > > > Imagine phylib is using the copper Ethernet PHY, but the MAC is using
> > > > the SFP port. Somebody pulls out the copper cable, phylib says the
> > > > link is
On Fri, Aug 25, 2017 at 04:48:12PM +0200, Antoine Tenart wrote:
> The link mode (speed, duplex) was forced based on what the phylib
> returns. This should not be the case, and only forced by ethtool
> functions manually. This patch removes the link mode enforcement from
> the phylib link_event call
On Fri, Aug 25, 2017 at 04:48:16PM +0200, Antoine Tenart wrote:
> This patch adds logic to reconfigure the comphy/gop when the link status
> change at runtime. This is very useful on boards such as the mcbin which
> have SFP and Ethernet ports connected to the same MAC port: depending on
> what the
On Mon, Aug 28, 2017 at 10:38:37AM +0200, Marcin Wojtas wrote:
> Hi Antoine,
>
> Can you be 100% sure that when using SGMII with PHY's (like Marvell
> Alaska 88E1xxx series), is in-band link information always available?
> I'd be very cautious with such assumption and use in-band management
> only
On Mon, Aug 28, 2017 at 11:40:51AM +0200, Antoine Tenart wrote:
> On Mon, Aug 28, 2017 at 09:51:52AM +0100, Russell King - ARM Linux wrote:
> > On Mon, Aug 28, 2017 at 10:38:37AM +0200, Marcin Wojtas wrote:
> > >
> > > Can you be 100% sure that when using SGM
On Mon, Oct 09, 2017 at 02:55:27PM +0200, Antoine Tenart wrote:
> Hi Russell,
>
> On Mon, Sep 25, 2017 at 11:55:14AM +0200, Antoine Tenart wrote:
> > On Fri, Sep 22, 2017 at 12:07:31PM +0100, Russell King - ARM Linux wrote:
> > > On Thu, Sep 21, 2017 at 03:45:22PM +02
ast tests the crypto users via testmgr and
> tcrypt but I do note that I do not have access to some
> of the HW whose drivers are modified nor do I claim I was
> able to test all of the corner cases.
>
> The patch set is based upon linux-next release tagged
> next-20171013.
Has
Subject says offlist, but this isn't...
On Wed, Jul 04, 2018 at 08:33:20AM +0100, Peter Robinson wrote:
> Sorry for the delay on this from my end. I noticed there was some bpf
> bits land in the last net fixes pull request landed Monday so I built
> a kernel with the JIT reenabled. It seems it's i
On Thu, Jul 05, 2018 at 12:41:54AM +0100, Russell King - ARM Linux wrote:
> Subject says offlist, but this isn't...
>
> On Wed, Jul 04, 2018 at 08:33:20AM +0100, Peter Robinson wrote:
> > Sorry for the delay on this from my end. I noticed there was some bpf
> > bits
Hi,
This series improves the ARM BPF JIT compiler by:
- enumerating the stack layout rather than using constants that happen
to be multiples of four
- rejig the BPF "register" accesses to use negative numbers instead of
positive, which could be confused with register numbers in the bpf2a32
a
On Tue, Jul 10, 2018 at 10:03:33AM -0700, Olof Johansson wrote:
> Hi Russell,
> > @@ -663,13 +679,27 @@ static inline void emit_a32_mov_r(const s8 dst, const
> > s8 src,
> > static inline void emit_a32_mov_r64(const bool is64, const s8 dst[],
> > const s8 src[],
On Tue, Jul 10, 2018 at 08:30:04PM +0200, Daniel Borkmann wrote:
> Hi Russell,
>
> thanks a lot for your work on the arm32 JIT!
>
> On 07/10/2018 02:36 PM, Russell King wrote:
> > Enumerate the contents of the JIT scratch stack layout used for storing
> > some of the JITs 64-bit registers, tail c
Hi,
This series improves the ARM BPF JIT compiler by:
- enumerating the stack layout rather than using constants that happen
to be multiples of four
- rejig the BPF "register" accesses to use negative numbers instead of
positive, which could be confused with register numbers in the bpf2a32
a
Four further jit compiler improves for 32-bit ARM.
arch/arm/net/bpf_jit_32.c | 120 --
1 file changed, 73 insertions(+), 47 deletions(-)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia:
On Thu, Jul 12, 2018 at 09:02:41PM +0200, Daniel Borkmann wrote:
> Applied to bpf-next, thanks a lot Russell!
Thanks, I've just sent four more patches, which is the sum total of
what I'm intending to send for BPF improvements for the next merge
window.
--
RMK's Patch system: http://www.armlinux.
On Thu, Jul 12, 2018 at 11:12:45PM +0200, Daniel Borkmann wrote:
> On 07/12/2018 11:02 PM, Russell King - ARM Linux wrote:
> > On Thu, Jul 12, 2018 at 09:02:41PM +0200, Daniel Borkmann wrote:
> >> Applied to bpf-next, thanks a lot Russell!
> >
> > Thanks, I've
On Fri, Mar 16, 2018 at 11:33:43AM +0100, Antoine Tenart wrote:
> The PHY mode 10GKR can use in-band negotiation. This patches allows this
> mode to be used with MLO_AN_INBAND in phylink.
>
> Signed-off-by: Antoine Tenart
> ---
> drivers/net/phy/phylink.c | 3 ++-
> 1 file changed, 2 insertions(
On Fri, Mar 16, 2018 at 11:33:44AM +0100, Antoine Tenart wrote:
> +static void mvpp2_phylink_validate(struct net_device *dev,
> +unsigned long *supported,
> +struct phylink_link_state *state)
> +{
> + __ETHTOOL_DECLARE_LINK_MODE_MA
On Mon, Mar 19, 2018 at 09:52:52AM +0100, Antoine Tenart wrote:
> Hi Russell,
>
> On Fri, Mar 16, 2018 at 03:53:07PM +, Russell King - ARM Linux wrote:
> > On Fri, Mar 16, 2018 at 11:33:43AM +0100, Antoine Tenart wrote:
> > > The PHY mode 10GKR can use in-band negotiat
On Mon, Mar 19, 2018 at 01:01:07PM +, Yan Markman wrote:
> The DTS-patch for this board (in "old" format) is attached
>
>
> Yan Markman
> Tel. 05-44732819
>
>
> -Original Message-
> From: Stefan Chulski
> Sent: Monday, March 19, 201
On Mon, Mar 19, 2018 at 02:10:09PM +0100, Antoine Tenart wrote:
> Hi Andrew,
>
> On Mon, Mar 19, 2018 at 01:59:53PM +0100, Andrew Lunn wrote:
> >
> > If they don't have PHYs, how are the connected to the outside world?
>
> On 7k/8k you have the following scheme for 10G only interfaces:
>
>M
1 - 100 of 1206 matches
Mail list logo
