* Re: Synopsys Ethernet QoS Driver
From: Joao Pinto @ 2016-11-23 11:10 UTC (permalink / raw)
To: Giuseppe CAVALLARO, Joao Pinto, Lars Persson
Cc: Rayagond Kokatanur, Rabin Vincent, mued dib, David Miller,
Jeff Kirsher, jiri@mellanox.com, saeedm@mellanox.com,
idosch@mellanox.com, netdev, linux-kernel@vger.kernel.org,
CARLOS.PALMINHA@synopsys.com, Andreas Irestål,
alexandre.torgue@st.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <c37c47e1-8e21-1b11-ed15-6b899ed1dd03@st.com>
Hi Peppe and Lars,
On 23-11-2016 10:59, Giuseppe CAVALLARO wrote:
> Hello Joao, Lars.
>
> On 11/22/2016 3:16 PM, Joao Pinto wrote:
>>> Ok, it makes sense.
>>> > Just for curiosity the target setup is the following:
>>> > https://www.youtube.com/watch?v=8V-LB5y2Cos
>>> > but instead of using internal drivers, we desire to use mainline drivers only.
>>> >
>>> > Thanks!
>> Regarding this subject, I am thinking of making the following adaption:
>>
>> a) delete ethernet/synopsys
>> b) rename ethernet/stmicro/stmmac to ethernet/synopsys
>>
>> and send you a patch for you to evaluate. Both agree with the approach?
>> To have a new work base would be important, because I will add to the "new"
>> structure some missing QoS features like Multichannel support, CBS and later TSN.
>
> IMO, we have to agree on a common strategy making the change for
> net-next; I imaged the following steps:
Yes it makes totally sense.
>
> - to port missing feature or fixes from ethernet/synopsys
> inside the stmmac taking care about the documentation too.
@Lars: You are familiar with the synopsys qos driver. Could you please do this
porting. You can also make an analysis of what to port and I can do the porting
for you if you don't have the availability for it.
> - remove ethernet/synopsys
> - rename ethernet/stmicro/stmmac to ethernet/synopsys
I volunteer to do this task.
>
> These latest two have some relevant impacts.
>
> This change should be propagated to all the platforms that are using:
> CONFIG_SYNOPSYS_DWC_ETH_QOS and CONFIG_STMMAC_ETH
> plus device-tree compatibility.
I volunteer to do this task also.
>
> - enhance the stmmac with new features and new glue (part of these
> can be anticipated for sure).
I have to implement 3 new features for now, but I will take some time for it, so
I would suggest to make the previous task and incrementally add features.
>
> what do you think? does it make sense? If yes, we can also
> understand how/who starts.
>
> Regards,
> Peppe
Thanks and regards.
Joao
>
>> Thanks.
>
^ permalink raw reply
* Re: [PATCH net-next 1/4] net: mvneta: Convert to be 64 bits compatible
From: Jisheng Zhang @ 2016-11-23 11:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Thomas Petazzoni, Andrew Lunn, Jason Cooper,
netdev, linux-kernel, Gregory CLEMENT, Marcin Wojtas,
David S. Miller, Sebastian Hesselbarth
In-Reply-To: <9432400.S1OrxC027t@wuerfel>
Hi Arnd,
On Wed, 23 Nov 2016 11:15:32 +0100 Arnd Bergmann wrote:
> On Wednesday, November 23, 2016 5:53:41 PM CET Jisheng Zhang wrote:
> > On Tue, 22 Nov 2016 22:04:12 +0100 Arnd Bergmann wrote:
> >
> > > On Tuesday, November 22, 2016 5:48:41 PM CET Gregory CLEMENT wrote:
> > > > +#ifdef CONFIG_64BIT
> > > > + void *data_tmp;
> > > > +
> > > > + /* In Neta HW only 32 bits data is supported, so in order to
> > > > + * obtain whole 64 bits address from RX descriptor, we store
> > > > + * the upper 32 bits when allocating buffer, and put it back
> > > > + * when using buffer cookie for accessing packet in memory.
> > > > + * Frags should be allocated from single 'memory' region,
> > > > + * hence common upper address half should be sufficient.
> > > > + */
> > > > + data_tmp = mvneta_frag_alloc(pp->frag_size);
> > > > + if (data_tmp) {
> > > > + pp->data_high = (u64)upper_32_bits((u64)data_tmp) << 32;
> > > > + mvneta_frag_free(pp->frag_size, data_tmp);
> > > > + }
> > > >
> > >
> > > How does this work when the region spans a n*4GB address boundary?
> >
> > indeed. We also make use of this driver on 64bit platforms. We use
> > different solution to make the driver 64bit safe.
> >
> > solA: make use of the reserved field in the mvneta_rx_desc, such
> > as reserved2 etc. Yes, the field is marked as "for future use, PnC", but
> > now it's not used at all. This is one possible solution however.
>
> Right, this sounds like the most straightforward choice.
>
> > solB: allocate a shadow buf cookie during init, e.g
> >
> > rxq->descs_bufcookie = kmalloc(rxq->size * sizeof(void*), GFP_KERNEL);
> >
> > then modify mvneta_rx_desc_fill a bit to save the 64bit pointer in
> > the shadow buf cookie, e.g
> > static void mvneta_rx_desc_fill(struct mvneta_rx_desc *rx_desc,
> > u32 phys_addr, u32 cookie,
sorry, this line should be:
u32 phys_addr, void *cookie
> > struct mvneta_rx_queue *rxq)
> >
> > {
> > int i;
> >
> > rx_desc->buf_cookie = cookie;
> > rx_desc->buf_phys_addr = phys_addr;
> > i = rx_desc - rxq->descs;
> > rxq->descs_bufcookie[i] = cookie;
> > }
> >
> > then fetch the desc from the shadow buf cookie in all code path, such
> > as mvneta_rx() etc.
> >
> > Both solutions should not have the problems pointed out by Arnd.
>
> Wait, since you compute an index 'i' here, can't you just store 'i'
> directly in the descriptor instead of the pointer?
>
we need to store the pointer, it's to store the buffer allocated by
mvneta_frag_alloc()
Thanks,
Jisheng
^ permalink raw reply
* [PATCH] cxgb4: fix memory leak on txq_info
From: Colin King @ 2016-11-23 11:02 UTC (permalink / raw)
To: Hariprasad S, netdev; +Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Currently if txq_info->uldtxq cannot be allocated then
txq_info->txq is being kfree'd (which is redundant because it
is NULL) instead of txq_info. Fix this by instead kfree'ing
txq_info.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c
index 565a6c6..8098902 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c
@@ -532,7 +532,7 @@ setup_sge_txq_uld(struct adapter *adap, unsigned int uld_type,
txq_info->uldtxq = kcalloc(txq_info->ntxq, sizeof(struct sge_uld_txq),
GFP_KERNEL);
if (!txq_info->uldtxq) {
- kfree(txq_info->uldtxq);
+ kfree(txq_info);
return -ENOMEM;
}
--
2.10.2
^ permalink raw reply related
* Re: Synopsys Ethernet QoS Driver
From: Giuseppe CAVALLARO @ 2016-11-23 10:59 UTC (permalink / raw)
To: Joao Pinto, Lars Persson
Cc: idosch@mellanox.com, alexandre.torgue@st.com, saeedm@mellanox.com,
netdev, linux-kernel@vger.kernel.org,
CARLOS.PALMINHA@synopsys.com, Rabin Vincent, mued dib,
jiri@mellanox.com, Rayagond Kokatanur, Jeff Kirsher,
Andreas Irestål, David Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <2eefdb8f-7e87-6009-6e50-c536d4b95dd6@synopsys.com>
Hello Joao, Lars.
On 11/22/2016 3:16 PM, Joao Pinto wrote:
>> Ok, it makes sense.
>> > Just for curiosity the target setup is the following:
>> > https://www.youtube.com/watch?v=8V-LB5y2Cos
>> > but instead of using internal drivers, we desire to use mainline drivers only.
>> >
>> > Thanks!
> Regarding this subject, I am thinking of making the following adaption:
>
> a) delete ethernet/synopsys
> b) rename ethernet/stmicro/stmmac to ethernet/synopsys
>
> and send you a patch for you to evaluate. Both agree with the approach?
> To have a new work base would be important, because I will add to the "new"
> structure some missing QoS features like Multichannel support, CBS and later TSN.
IMO, we have to agree on a common strategy making the change for
net-next; I imaged the following steps:
- to port missing feature or fixes from ethernet/synopsys
inside the stmmac taking care about the documentation too.
- remove ethernet/synopsys
- rename ethernet/stmicro/stmmac to ethernet/synopsys
These latest two have some relevant impacts.
This change should be propagated to all the platforms that are using:
CONFIG_SYNOPSYS_DWC_ETH_QOS and CONFIG_STMMAC_ETH
plus device-tree compatibility.
- enhance the stmmac with new features and new glue (part of these
can be anticipated for sure).
what do you think? does it make sense? If yes, we can also
understand how/who starts.
Regards,
Peppe
> Thanks.
^ permalink raw reply
* stmmac ethernet in kernel 4.4: coalescing related pauses?
From: Pavel Machek @ 2016-11-23 10:51 UTC (permalink / raw)
To: peppe.cavallaro, netdev, kernel list
[-- Attachment #1.1: Type: text/plain, Size: 933 bytes --]
Hi!
I'm debugging strange delays during transmit in stmmac driver. They
seem to be present in 4.4 kernel (and older kernels, too). Workload is
burst of udp packets being sent, pause, burst of udp packets, ...
Test code is attached, I use these parameters for testing:
./udp-test raw 10.0.0.6 1234 1000 100 30
The delays seem to be related to coalescing:
drivers/net/ethernet/stmicro/stmmac/common.h
#define STMMAC_COAL_TX_TIMER 40000
#define STMMAC_MAX_COAL_TX_TICK 100000
#define STMMAC_TX_MAX_FRAMES 256
If I lower the parameters, delays are gone, but I get netdev watchdog
backtrace followed by broken driver.
Any ideas what is going on there?
[I'm currently trying to get newer kernels working on affected
hardware.]
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: CMakeLists.txt --]
[-- Type: text/plain, Size: 589 bytes --]
cmake_minimum_required(VERSION 2.8.7)
project(streaming)
find_package(Boost REQUIRED COMPONENTS system)
set(SOURCES
udp-test.cpp)
add_executable(udp-test ${SOURCES})
if (BUILD_TESTS)
enable_testing()
endif()
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -std=c++11")
set_property(TARGET udp-test PROPERTY CXX_STANDARD 11)
target_link_libraries(udp-test boost_system pthread )
[-- Attachment #1.3: udp-test.cpp --]
[-- Type: text/x-c++src, Size: 6995 bytes --]
#include <boost/asio.hpp>
#include <boost/asio/steady_timer.hpp>
#include <iostream>
namespace asio = boost::asio;
class UdpSendTest
{
public:
UdpSendTest(asio::io_service& io_service, const std::string& dest_ip, int dest_port, int packet_size, int packet_count, int interval)
: io_service_(io_service),
timer_(io_service),
udp_socket_(io_service),
dest_ip_(std::move(dest_ip)),
dest_port_(dest_port),
packet_size_(packet_size),
packet_count_(packet_count),
period_(interval)
{
}
void start()
{
timer_.expires_from_now(period_);
timer_.async_wait(std::bind(&UdpSendTest::handleTimer, this, std::placeholders::_1));
try
{
udp_socket_.connect(asio::ip::udp::endpoint(boost::asio::ip::address::from_string(dest_ip_), dest_port_));
}
catch(boost::system::system_error e)
{
std::cerr<< "Could not connect:"<<e.what()<<std::endl;
}
}
private:
static_assert(std::chrono::steady_clock::is_steady, "steady_clock does not use the monotonic system clock. Please use a toolchain with full support for std::chrono!");
void sendPackets()
{
std::vector<unsigned char> buffer(packet_size_,0);
for (int i=0; i<packet_count_; i++)
{
if (buffer.size() > 1)
{
buffer[0] = i / 255;
buffer[1] = i % 255;
}
else
buffer[0]=i%255;
auto t0 = std::chrono::steady_clock::now();
try
{
udp_socket_.send(asio::buffer(buffer));
}
catch(boost::system::system_error& error)
{
std::cerr<<"Could not send UDP packet, reason: "<<error.what()<<std::endl;
}
auto delta_t = std::chrono::steady_clock::now() - t0;
auto delta_t_us = std::chrono::duration_cast<std::chrono::microseconds>(delta_t).count();
if (delta_t_us > 10000)
{
std::cout<<"Sending UDP packet took >10ms: "<<delta_t_us<<"us"<<std::endl;
}
if (delta_t_us > period_.count() * 1000)
{
std::cout<<"This would lead to a lost frame!"<<std::endl;
}
}
}
void handleTimer(boost::system::error_code ec)
{
if (ec)
{
std::cerr<<"Timer interrupted, exiting!"<<std::endl;
return;
}
sendPackets();
timer_.expires_at(timer_.expires_at() + period_);
timer_.async_wait(std::bind(&UdpSendTest::handleTimer, this, std::placeholders::_1));
}
asio::io_service& io_service_;
asio::steady_timer timer_;
asio::ip::udp::socket udp_socket_;
std::string dest_ip_;
int dest_port_;
int packet_size_;
int packet_count_;
std::chrono::milliseconds period_;
};
class UdpSendTestLowlevel
{
public:
UdpSendTestLowlevel(asio::io_service& io_service, const std::string& dest_ip, int dest_port, int packet_size, int packet_count, int interval)
: io_service_(io_service),
timer_(io_service),
dest_ip_(std::move(dest_ip)),
dest_port_(dest_port),
packet_size_(packet_size),
packet_count_(packet_count),
period_(interval)
{
}
void start()
{
timer_.expires_from_now(period_);
timer_.async_wait(std::bind(&UdpSendTestLowlevel::handleTimer, this, std::placeholders::_1));
socket_fd_ = socket(AF_INET, SOCK_DGRAM, 0);
if (socket_fd_ < 0)
std::cerr<<"could not create socket: " <<strerror(errno)<<std::endl;
auto h = gethostbyname(dest_ip_.c_str());
if (h == nullptr)
std::cerr<<"Could not find host: "<<dest_ip_<<std::endl;
server_addr_.sin_family = h->h_addrtype;
memcpy((char*)&server_addr_.sin_addr.s_addr, h->h_addr_list[0], h->h_length);
server_addr_.sin_port = htons(dest_port_);
client_addr_.sin_family = AF_INET;
client_addr_.sin_addr.s_addr = htonl(INADDR_ANY);
client_addr_.sin_port = htons(0);
auto rc = bind(socket_fd_,reinterpret_cast<sockaddr*>(&client_addr_), sizeof(client_addr_));
if (rc < 0)
std::cerr<<"Could not open Port"<<std::endl;
}
private:
static_assert(std::chrono::steady_clock::is_steady, "steady_clock does not use the monotonic system clock. Please use a toolchain with full support for std::chrono!");
void sendPackets()
{
std::vector<unsigned char> buffer(packet_size_,0);
for (int i=0; i<packet_count_; i++)
{
if (buffer.size() > 1)
{
buffer[0] = i / 255;
buffer[1] = i % 255;
}
else
buffer[0]=i%255;
auto t0 = std::chrono::steady_clock::now();
auto rc = sendto(socket_fd_, buffer.data(), buffer.size(), 0, (sockaddr* )&server_addr_, sizeof(server_addr_));
if (rc<0)
std::cerr<<"Could not send UDP packet"<<std::endl;
auto delta_t = std::chrono::steady_clock::now() - t0;
auto delta_t_us = std::chrono::duration_cast<std::chrono::microseconds>(delta_t).count();
if (delta_t_us > 10000)
{
std::cout<<"Sending UDP packet took >10ms: "<<delta_t_us<<"us"<<std::endl;
}
if (delta_t_us > period_.count() * 1000)
{
std::cout<<"This would lead to a lost frame!"<<std::endl;
}
}
}
void handleTimer(boost::system::error_code ec)
{
if (ec)
{
std::cerr<<"Timer interrupted, exiting!"<<std::endl;
return;
}
sendPackets();
timer_.expires_at(timer_.expires_at() + period_);
timer_.async_wait(std::bind(&UdpSendTestLowlevel::handleTimer, this, std::placeholders::_1));
}
asio::io_service& io_service_;
asio::steady_timer timer_;
std::string dest_ip_;
int dest_port_;
int packet_size_;
int packet_count_;
std::chrono::milliseconds period_;
int socket_fd_;
struct sockaddr_in client_addr_, server_addr_;
};
int main(int argc, char** argv)
{
if (argc < 7)
{
std::cout<<"usage: "<<argv[0]<<" [boost|raw] dest_ip dest_port packet_size packet_count interval_ms"<<std::endl;
return 1;
}
if (std::atoi(argv[4])<1)
{
std::cerr<<"Please select a packet size > 0 bytes!"<<std::endl;
return 1;
}
asio::io_service io_service;
std::string mode(argv[1]);
int dest_port = std::atoi(argv[3]);
int packet_size = std::atoi(argv[4]);
int packet_count = std::atoi(argv[5]);
int frame_interval = std::atoi(argv[6]);
int bytes_per_sec = packet_size * packet_count *(1000.f/frame_interval);
int bytes_per_sec_2 = (packet_size+12) * packet_count *(1000.f/frame_interval);
std::cout<<"Sending "<<packet_count<<" packets ("<<packet_size<<"b each) at an interval of "<<frame_interval<<"ms, expected data rate:"<<bytes_per_sec <<"b/s ("<<bytes_per_sec_2<<"b/s incl udp overhead)"<<std::endl;
if (bytes_per_sec_2 > 1000 * 1000 * 100)
std::cerr<<"Warning: trying to transmit > 100Mb/s"<<std::endl;
if (mode == "boost")
{
UdpSendTest u(io_service,
argv[2],dest_port, packet_size, packet_count, frame_interval);
u.start();
io_service.run();
}
else
{
UdpSendTestLowlevel u(io_service,
argv[2],dest_port, packet_size, packet_count, frame_interval);
u.start();
io_service.run();
}
return 0;
}
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH] cpsw: ethtool: add support for getting/setting EEE registers
From: yegorslists @ 2016-11-23 10:34 UTC (permalink / raw)
To: netdev; +Cc: linux-omap, grygorii.strashko, mugunthanvnm, Yegor Yefremov
From: Yegor Yefremov <yegorslists@googlemail.com>
Add the ability to query and set Energy Efficient Ethernet parameters
via ethtool for applicable devices.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
---
drivers/net/ethernet/ti/cpsw.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index c6cff3d..6856616 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2239,6 +2239,30 @@ static int cpsw_set_channels(struct net_device *ndev,
return ret;
}
+int cpsw_get_eee(struct net_device *ndev, struct ethtool_eee *edata)
+{
+ struct cpsw_priv *priv = netdev_priv(ndev);
+ struct cpsw_common *cpsw = priv->cpsw;
+ int slave_no = cpsw_slave_index(cpsw, priv);
+
+ if (cpsw->slaves[slave_no].phy)
+ return phy_ethtool_get_eee(cpsw->slaves[slave_no].phy, edata);
+ else
+ return -EOPNOTSUPP;
+}
+
+int cpsw_set_eee(struct net_device *ndev, struct ethtool_eee *edata)
+{
+ struct cpsw_priv *priv = netdev_priv(ndev);
+ struct cpsw_common *cpsw = priv->cpsw;
+ int slave_no = cpsw_slave_index(cpsw, priv);
+
+ if (cpsw->slaves[slave_no].phy)
+ return phy_ethtool_set_eee(cpsw->slaves[slave_no].phy, edata);
+ else
+ return -EOPNOTSUPP;
+}
+
static const struct ethtool_ops cpsw_ethtool_ops = {
.get_drvinfo = cpsw_get_drvinfo,
.get_msglevel = cpsw_get_msglevel,
@@ -2262,6 +2286,8 @@ static const struct ethtool_ops cpsw_ethtool_ops = {
.complete = cpsw_ethtool_op_complete,
.get_channels = cpsw_get_channels,
.set_channels = cpsw_set_channels,
+ .get_eee = cpsw_get_eee,
+ .set_eee = cpsw_set_eee,
};
static void cpsw_slave_init(struct cpsw_slave *slave, struct cpsw_common *cpsw,
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net-next 1/4] net: mvneta: Convert to be 64 bits compatible
From: Arnd Bergmann @ 2016-11-23 10:15 UTC (permalink / raw)
To: Jisheng Zhang
Cc: linux-arm-kernel, Thomas Petazzoni, Andrew Lunn, Jason Cooper,
netdev, linux-kernel, Gregory CLEMENT, Marcin Wojtas,
David S. Miller, Sebastian Hesselbarth
In-Reply-To: <20161123175341.4777595f@xhacker>
On Wednesday, November 23, 2016 5:53:41 PM CET Jisheng Zhang wrote:
> On Tue, 22 Nov 2016 22:04:12 +0100 Arnd Bergmann wrote:
>
> > On Tuesday, November 22, 2016 5:48:41 PM CET Gregory CLEMENT wrote:
> > > +#ifdef CONFIG_64BIT
> > > + void *data_tmp;
> > > +
> > > + /* In Neta HW only 32 bits data is supported, so in order to
> > > + * obtain whole 64 bits address from RX descriptor, we store
> > > + * the upper 32 bits when allocating buffer, and put it back
> > > + * when using buffer cookie for accessing packet in memory.
> > > + * Frags should be allocated from single 'memory' region,
> > > + * hence common upper address half should be sufficient.
> > > + */
> > > + data_tmp = mvneta_frag_alloc(pp->frag_size);
> > > + if (data_tmp) {
> > > + pp->data_high = (u64)upper_32_bits((u64)data_tmp) << 32;
> > > + mvneta_frag_free(pp->frag_size, data_tmp);
> > > + }
> > >
> >
> > How does this work when the region spans a n*4GB address boundary?
>
> indeed. We also make use of this driver on 64bit platforms. We use
> different solution to make the driver 64bit safe.
>
> solA: make use of the reserved field in the mvneta_rx_desc, such
> as reserved2 etc. Yes, the field is marked as "for future use, PnC", but
> now it's not used at all. This is one possible solution however.
Right, this sounds like the most straightforward choice.
> solB: allocate a shadow buf cookie during init, e.g
>
> rxq->descs_bufcookie = kmalloc(rxq->size * sizeof(void*), GFP_KERNEL);
>
> then modify mvneta_rx_desc_fill a bit to save the 64bit pointer in
> the shadow buf cookie, e.g
> static void mvneta_rx_desc_fill(struct mvneta_rx_desc *rx_desc,
> u32 phys_addr, u32 cookie,
> struct mvneta_rx_queue *rxq)
>
> {
> int i;
>
> rx_desc->buf_cookie = cookie;
> rx_desc->buf_phys_addr = phys_addr;
> i = rx_desc - rxq->descs;
> rxq->descs_bufcookie[i] = cookie;
> }
>
> then fetch the desc from the shadow buf cookie in all code path, such
> as mvneta_rx() etc.
>
> Both solutions should not have the problems pointed out by Arnd.
Wait, since you compute an index 'i' here, can't you just store 'i'
directly in the descriptor instead of the pointer?
Arnd
^ permalink raw reply
* Re: [PATCH net-next 1/2] samples/bpf: fix sockex2 example
From: Daniel Borkmann @ 2016-11-23 9:58 UTC (permalink / raw)
To: Alexei Starovoitov, David S . Miller; +Cc: netdev
In-Reply-To: <1479862329-2361912-1-git-send-email-ast@fb.com>
On 11/23/2016 01:52 AM, Alexei Starovoitov wrote:
> since llvm commit "Do not expand UNDEF SDNode during insn selection lowering"
> llvm will generate code that uses uninitialized registers for cases
> where C code is actually uses uninitialized data.
> So this sockex2 example is technically broken.
> Fix it by initializing on the stack variable fully.
> Also increase verifier buffer limit, since verifier output
> may not fit in 64k for this sockex2 code depending on llvm version.
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH net-next 2/2] samples/bpf: fix bpf loader
From: Daniel Borkmann @ 2016-11-23 9:57 UTC (permalink / raw)
To: Alexei Starovoitov, David S . Miller; +Cc: netdev
In-Reply-To: <1479862329-2361912-2-git-send-email-ast@fb.com>
On 11/23/2016 01:52 AM, Alexei Starovoitov wrote:
> llvm can emit relocations into sections other than program code
> (like debug info sections). Ignore them during parsing of elf file
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH] net: dsa: mv88e6xxx: egress all frames
From: Stefan Eichenberger @ 2016-11-23 9:56 UTC (permalink / raw)
To: Vivien Didelot; +Cc: Andrew Lunn, Stefan Eichenberger, f.fainelli, netdev
In-Reply-To: <87zikr40w2.fsf@ketchup.i-did-not-set--mail-host-address--so-tickle-me>
Hi Vivien
On Tue, Nov 22, 2016 at 05:15:25PM -0500, Vivien Didelot wrote:
> Hi Andrew, Stefan,
>
> Andrew Lunn <andrew@lunn.ch> writes:
>
> > What you might find useful is
> >
> > https://github.com/vivien/linux.git 161b96bd7d16d21b0f046c935b70c3b2d277ccc2
> >
> > although it might need some changes for recent commits.
> >
> > With that, you can see deeper into the switches registers.
>
> FYI, I have rebased it on top of the latest net-next (f9aa9dc7d2d0):
>
> https://github.com/vivien/linux.git dsa/dev
>
Perfect that is really helpful, thanks a lot!
Stefan
^ permalink raw reply
* Re: [PATCH net-next 1/4] net: mvneta: Convert to be 64 bits compatible
From: Jisheng Zhang @ 2016-11-23 9:53 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Thomas Petazzoni, Andrew Lunn, Jason Cooper, netdev, linux-kernel,
Gregory CLEMENT, Marcin Wojtas, David S. Miller, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <2948812.F3se4ieqO6@wuerfel>
On Tue, 22 Nov 2016 22:04:12 +0100 Arnd Bergmann wrote:
> On Tuesday, November 22, 2016 5:48:41 PM CET Gregory CLEMENT wrote:
> > +#ifdef CONFIG_64BIT
> > + void *data_tmp;
> > +
> > + /* In Neta HW only 32 bits data is supported, so in order to
> > + * obtain whole 64 bits address from RX descriptor, we store
> > + * the upper 32 bits when allocating buffer, and put it back
> > + * when using buffer cookie for accessing packet in memory.
> > + * Frags should be allocated from single 'memory' region,
> > + * hence common upper address half should be sufficient.
> > + */
> > + data_tmp = mvneta_frag_alloc(pp->frag_size);
> > + if (data_tmp) {
> > + pp->data_high = (u64)upper_32_bits((u64)data_tmp) << 32;
> > + mvneta_frag_free(pp->frag_size, data_tmp);
> > + }
> >
>
> How does this work when the region spans a n*4GB address boundary?
indeed. We also make use of this driver on 64bit platforms. We use
different solution to make the driver 64bit safe.
solA: make use of the reserved field in the mvneta_rx_desc, such
as reserved2 etc. Yes, the field is marked as "for future use, PnC", but
now it's not used at all. This is one possible solution however.
solB: allocate a shadow buf cookie during init, e.g
rxq->descs_bufcookie = kmalloc(rxq->size * sizeof(void*), GFP_KERNEL);
then modify mvneta_rx_desc_fill a bit to save the 64bit pointer in
the shadow buf cookie, e.g
static void mvneta_rx_desc_fill(struct mvneta_rx_desc *rx_desc,
u32 phys_addr, u32 cookie,
struct mvneta_rx_queue *rxq)
{
int i;
rx_desc->buf_cookie = cookie;
rx_desc->buf_phys_addr = phys_addr;
i = rx_desc - rxq->descs;
rxq->descs_bufcookie[i] = cookie;
}
then fetch the desc from the shadow buf cookie in all code path, such
as mvneta_rx() etc.
Both solutions should not have the problems pointed out by Arnd.
Thanks,
Jisheng
^ permalink raw reply
* Re: [PATCH net-next 1/1] ipv6: sr: add option to control lwtunnel support
From: David Lebrun @ 2016-11-23 9:28 UTC (permalink / raw)
To: Roopa Prabhu, Alexei Starovoitov
Cc: David Miller, netdev@vger.kernel.org, Lorenzo Colitti,
Eric Dumazet
In-Reply-To: <5835466B.6080405@cumulusnetworks.com>
[-- Attachment #1: Type: text/plain, Size: 2116 bytes --]
On 11/23/2016 08:34 AM, Roopa Prabhu wrote:
> I can't seem to reproduce the problem you are seeing. still trying..
> I don't have CONFIG_LWTUNNEL set nor any of the other SEG6 configs.
> My CONFIG_IPV6 is on and compiled as a module. I have also tried disabling it.
> If you can send me the config, I can try again. Looking back at the patches,
> I do see a few things below ..but they may not fix your problem directly.
>
> Though I had none of the ipv6 segment routing configs turned on,
> I do see the "Segment Routing with IPv6" msg at bootup.
> Was looking at david's patches again, and a few things (I had missed seeing the last version):
>
> In my review comment I was hinting at CONFIG_IPV6_SEG6 to cover all of ipv6 segment routing,
> including the lwtunnel bits.
>
> something like below:
>
> config IPV6_SEG6
> bool "IPv6: Segment Routing Header encapsulation support"
> depends on LWTUNNEL && IPV6
>
> DavidL, do you see a problem doing it this way ?. with this 'seg6.o' will be part of CONFIG_IPV6_SEG6 and not
> get initialized unless it is enabled..which seems like the right thing to do.
Can't reproduce the bug either, with CONFIG_IPV6=y, LWTUNNEL=n and all
SEG6 disabled. Alexei, your .config and dmesg log could help.
Roopa, the reason why seg6.o is compiled by default is that it provides
an interface to control HMAC structures, and that HMAC does not depends
on lwtunnels and can be used in the extension header processing (which
is compiled by default). I could indeed add another option to
conditionnally compile seg6.o if HMAC is enabled etc, and I actually had
something like that in the very first versions of the patch, but I
received comments that too much options is not a good thing (and I agree
with that).
Anyway, I do not see how seg6.o could possibly generate such a bug given
the only thing it does is register a genetlink family and pernet ops
that allocate/deallocate a struct. Genetlink is compiled by default with
NET and register_pernet_subsys does not fail even when namespaces
support is disabled.
David
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]
^ permalink raw reply
* Re: sendfile from 9p fs into af_alg
From: Alexei Starovoitov @ 2016-11-23 8:58 UTC (permalink / raw)
To: Al Viro; +Cc: linux-kernel, netdev, Daniel Borkmann, Martin KaFai Lau
In-Reply-To: <20161123061628.GN1555@ZenIV.linux.org.uk>
On Wed, Nov 23, 2016 at 06:16:28AM +0000, Al Viro wrote:
> On Tue, Nov 22, 2016 at 08:55:59PM -0800, Alexei Starovoitov wrote:
> > On Wed, Nov 23, 2016 at 04:46:26AM +0000, Al Viro wrote:
> > > On Tue, Nov 22, 2016 at 07:58:29PM -0800, Alexei Starovoitov wrote:
> > > > Hi Al,
> > > >
> > > > it seems the following commit 523ac9afc73a ("switch default_file_splice_read() to use of pipe-backed iov_iter")
> > > > breaks sendfile from 9p fs into af_alg socket.
> > > > sendfile into af_alg is used by iproute2/tc.
> > > > I'm not sure whether it's 9p or crypto or vfs problem, but happy to test any patches.
> > >
> > > Could you try -rc6 (or anything that contains 680bb946a1ae04, for that
> > > matter)?
> >
> > already tested with that patch in the latest net-next. Still broken :(
>
> Joy... Which transport are you using there? The interesting part is
> whether it's zerocopy or non-zerocopy path in p9_client_read()...
not sure what's the default is. It's a standard qemu setup:
sudo /usr/bin/qemu-system-x86_64 -enable-kvm -smp 4 -cpu host \
-kernel .../bld_x64/arch/x86/boot/bzImage \
-drive file=....qcow2,if=virtio \
-no-reboot -m 4096 \
--append "root=/dev/vda1 rw mem=GG vga=0 console=ttyS0" -nographic \
-fsdev local,security_model=passthrough,id=fsdev1,path=/data/users \
-device virtio-9p-pci,id=fs1,fsdev=fsdev1,mount_tag=hostshare1
Enabled CONFIG_NET_9P_DEBUG and everything looks normal:
# ./a.out ./a.out
[ 23.894140] 9pnet: -- v9fs_vfs_lookup (235): dir: ffff8801370d87f8 dentry: (a.out) ffff880139ffe600 flags: 0
[ 23.895409] 9pnet: -- v9fs_fid_find (235): dentry: bpf (ffff880139ffc180) uid 0 any 0
[ 23.896451] 9pnet: -- p9_fid_create (235): clnt ffff880136d8f000
[ 23.897225] 9pnet: -- p9_idpool_get (235): id 6 pool ffff880139b76640
[ 23.898052] 9pnet: (00000235) >>> TWALK fids 5,6 nwname 1d wname[0] a.out
[ 23.898919] 9pnet: -- p9_client_prepare_req (235): client ffff880136d8f000 op 110
[ 23.899884] 9pnet: -- p9_idpool_get (235): id 1 pool ffff880139b76c00
[ 23.900738] 9pnet: (00000235) >>> size=24 type: 110 tag: 1
[ 23.901452] 9pnet: -- p9_virtio_request (235): 9p debug: virtio request
[ 23.902332] 9pnet: -- p9_virtio_request (235): virtio request kicked
[ 23.903374] 9pnet: -- req_done (235): : request done
[ 23.903377] 9pnet: -- p9_client_cb (235): tag 1
[ 23.903378] 9pnet: -- p9_client_cb (235): wakeup: 1
[ 23.905213] 9pnet: (00000235) <<< size=22 type: 111 tag: 1
[ 23.905904] 9pnet: -- p9_free_req (235): clnt ffff880136d8f000 req ffff880138eac070 tag: 1
[ 23.906943] 9pnet: -- p9_idpool_put (235): id 1 pool ffff880139b76c00
[ 23.907847] 9pnet: (00000235) <<< RWALK nwqid 1:
[ 23.908446] 9pnet: (00000235) <<< [0] 0.170dd824.58117466
[ 23.909184] 9pnet: (00000235) >>> TGETATTR fid 6, request_mask 6143
[ 23.909980] 9pnet: -- p9_client_prepare_req (235): client ffff880136d8f000 op 24
[ 23.910887] 9pnet: -- p9_idpool_get (235): id 1 pool ffff880139b76c00
[ 23.911737] 9pnet: (00000235) >>> size=19 type: 24 tag: 1
[ 23.912426] 9pnet: -- p9_virtio_request (235): 9p debug: virtio request
[ 23.913266] 9pnet: -- p9_virtio_request (235): virtio request kicked
[ 23.914159] 9pnet: -- req_done (235): : request done
[ 23.914161] 9pnet: -- p9_client_cb (235): tag 1
[ 23.914162] 9pnet: -- p9_client_cb (235): wakeup: 1
[ 23.915982] 9pnet: (00000235) <<< size=160 type: 25 tag: 1
[ 23.916691] 9pnet: (00000235) <<< RGETATTR st_result_mask=6143
<<< qid=0.170dd824.58117466
<<< st_mode=000081ed st_nlink=1
<<< st_uid=572438 st_gid=100
<<< st_rdev=0 st_size=2598 st_blksize=4096 st_blocks=24
<<< st_atime_sec=1479863398 st_atime_nsec=904285549
<<< st_mtime_sec=1479863398 st_mtime_nsec=914285509
<<< st_ctime_sec=1479863398 st_ctime_nsec=914285509
<<< st_btime_sec=0 st_btime_nsec=0
<<< st_gen=1570962252 st_data_version=0[ 23.921484] 9pnet: -- p9_free_req (235): clnt ffff880136d8f000 req ffff880138eac070 tag: 1
[ 23.922536] 9pnet: -- p9_idpool_put (235): id 1 pool ffff880139b76c00
[ 23.923368] 9pnet: -- v9fs_file_open (235): inode: ffff8801370d0568 file: ffff88013a566500
[ 23.924451] 9pnet: -- v9fs_fid_find (235): dentry: a.out (ffff880139ffe600) uid 0 any 0
[ 23.925483] 9pnet: -- p9_fid_create (235): clnt ffff880136d8f000
[ 23.926263] 9pnet: -- p9_idpool_get (235): id 7 pool ffff880139b76640
---skip---
[ 24.044275] 9pnet: -- req_done (123): : request done
[ 24.044278] 9pnet: -- p9_client_cb (123): tag 1
[ 24.044278] 9pnet: -- p9_client_cb (123): wakeup: 1
[ 24.047135] 9pnet: (00000235) <<< size=4107 type: 117 tag: 1
[ 24.047879] 9pnet: (00000235) <<< RREAD count 4096
[ 24.048520] 9pnet: -- p9_free_req (235): clnt ffff880136d8f000 req ffff880138eac070 tag: 1
[ 24.049609] 9pnet: -- p9_idpool_put (235): id 1 pool ffff880139b76c00
[ 24.050462] 9pnet: -- p9_client_prepare_req (235): client ffff880136d8f000 op 116
[ 24.051431] 9pnet: -- p9_idpool_get (235): id 1 pool ffff880139b76c00
[ 24.052283] 9pnet: (00000235) >>> size=23 type: 116 tag: 1
[ 24.052984] 9pnet: -- p9_virtio_zc_request (235): virtio request
[ 24.053774] 9pnet: -- p9_virtio_zc_request (235): virtio request kicked
[ 24.053834] 9pnet: -- req_done (123): : request done
[ 24.053836] 9pnet: -- p9_client_cb (123): tag 1
[ 24.053836] 9pnet: -- p9_client_cb (123): wakeup: 1
[ 24.056496] 9pnet: (00000235) <<< size=4107 type: 117 tag: 1
[ 24.057211] 9pnet: (00000235) <<< RREAD count 4096
[ 24.057820] 9pnet: -- p9_free_req (235): clnt ffff880136d8f000 req ffff880138eac070 tag: 1
[ 24.058857] 9pnet: -- p9_idpool_put (235): id 1 pool ffff880139b76c00
[ 24.059800] 9pnet: -- v9fs_dir_release (235): inode: ffff8801370d0568 filp: ffff880139ab2800 fid: 8
Error from sendf[ 24.060938] 9pnet: (00000235) >>> TCLUNK fid 8 (try 0)
ile (8192 vs 962[ 24.061731] 9pnet: -- p9_client_prepare_req (235): client ffff880136d8f000 op 120
4 bytes): Succes[ 24.062787] 9pnet: -- p9_idpool_get (235): id 1 pool ffff880139b76c00
s
[ 24.063715] 9pnet: (00000235) >>> size=11 type: 120 tag: 1
[ 24.064461] 9pnet: -- p9_virtio_request (235): 9p debug: virtio request
[ 24.065335] 9pnet: -- p9_virtio_request (235): virtio request kicked
[ 24.065410] 9pnet: -- req_done (0): : request done
[ 24.065412] 9pnet: -- p9_client_cb (0): tag 1
[ 24.065413] 9pnet: -- p9_client_cb (0): wakeup: 1
[ 24.068025] 9pnet: (00000235) <<< size=7 type: 121 tag: 1
[ 24.068695] 9pnet: (00000235) <<< RCLUNK fid 8
[ 24.069253] 9pnet: -- p9_free_req (235): clnt ffff880136d8f000 req ffff880138eac070 tag: 1
[ 24.070269] 9pnet: -- p9_idpool_put (235): id 1 pool ffff880139b76c00
[ 24.071120] 9pnet: -- p9_fid_destroy (235): fid 8
[ 24.071735] 9pnet: -- p9_idpool_put (235): id 8 pool ffff880139b76640
hash 0
if I read it correctly 9p actually responded with 8192 bytes of requests...
whereas the file size was 9624.
For large file sizes (in megabytes) the difference between what
sendfile is reporting and actual file size can be 3x.
In the small file case (like above dump) it looks rounded to page size for some reason.
^ permalink raw reply
* Re: [LKP] [net] 34fad54c25: kernel BUG at include/linux/skbuff.h:1935!
From: Ye Xiaolong @ 2016-11-23 8:55 UTC (permalink / raw)
To: Linus Torvalds
Cc: Fengguang Wu, David Miller, Eric Dumazet, Alexander Duyck,
Willem de Bruijn, Network Development, LKML, Alexei Starovoitov,
LKP
In-Reply-To: <CA+55aFx9q2xi1oi2j5QcYhMV490oj9CQ4N_OEXzC-3b6GeUQug@mail.gmail.com>
On 11/22, Linus Torvalds wrote:
>On Tue, Nov 22, 2016 at 10:44 PM, Fengguang Wu <fengguang.wu@intel.com> wrote:
>>
>> On Tue, Nov 22, 2016 at 02:04:42PM -0800, Linus Torvalds wrote:
>>
>>> I also noticed that the kernel test robot had screwed up the
>>> participants list for some reason, and had
>>>
>>> "Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>, David S.
>>> Miller" <davem@davemloft.net>
>>>
>>> as one of the participants. So there's some odd commit parsing issue
>>> there somewhere. But Alexander seems to have seen this report despite
>>> that, it just never went anywhere that I can tell.
>>
>>
>> Yeah the robot will CC all "Acked-by" people in the bug reports.
>>
>> Shall we limit it to the below TO/CC list?
>
>No. We do want to keep the Acked-by's on the cc.
>
>But you missed the real problem.
>
>It *didn't* cc the acked-by. Look closer. What happened was that it cc'd this:
>
> "Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>, David S. Miller"
>
> <davem@davemloft.net>
>
Seems that the robot failed to parse the commit log correctly due to
the "Reported-by: xxx" line missed '>' in the end, the robot got fooled
by it and generated wrong result, we'll try to improve it to handle this
kind of case.
net: __skb_flow_dissect() must cap its return value
After Tom patch, thoff field could point past the end of the buffer,
this could fool some callers.
If an skb was provided, skb->len should be the upper limit.
If not, hlen is supposed to be the upper limit.
Fixes: a6e544b0a88b ("flow_dissector: Jump to exit code in __skb_flow_dissect")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Yibin Yang <yibyang@cisco.com
Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Thanks,
Xiaolong
>ie there is only _one_ email address (that of davem@davemloft.net),
>and the whole "Acked-by: Alexander Duyck <...>" part is quoted as the
>_name_ of that email address.
>
>At least that's what the headers look like for me in the original report:
>
> From: kernel test robot <xiaolong.ye@intel.com>
> To: Eric Dumazet <edumazet@google.com>
> Cc: lkp@01.org, Linus Torvalds <torvalds@linux-foundation.org>,
>LKML <linux-kernel@vger.kernel.org>, Alexei Starovoitov
><ast@kernel.org>, Willem de Bruijn <willemb@google.com>, "Acked-by:
>Alexander Duyck <alexander.h.duyck@intel.com>, David S. Miller"
><davem@davemloft.net>
>
>Notice the quoting of that last "name".
>
> Linus
^ permalink raw reply
* Re: [LKP] [net] 34fad54c25: kernel BUG at include/linux/skbuff.h:1935!
From: Fengguang Wu @ 2016-11-23 8:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: kernel test robot, David Miller, Eric Dumazet, Alexander Duyck,
Willem de Bruijn, Network Development, LKML, Alexei Starovoitov,
LKP
In-Reply-To: <CA+55aFx9q2xi1oi2j5QcYhMV490oj9CQ4N_OEXzC-3b6GeUQug@mail.gmail.com>
On Tue, Nov 22, 2016 at 11:07:16PM -0800, Linus Torvalds wrote:
>On Tue, Nov 22, 2016 at 10:44 PM, Fengguang Wu <fengguang.wu@intel.com> wrote:
>>
>> On Tue, Nov 22, 2016 at 02:04:42PM -0800, Linus Torvalds wrote:
>>
>>> I also noticed that the kernel test robot had screwed up the
>>> participants list for some reason, and had
>>>
>>> "Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>, David S.
>>> Miller" <davem@davemloft.net>
>>>
>>> as one of the participants. So there's some odd commit parsing issue
>>> there somewhere. But Alexander seems to have seen this report despite
>>> that, it just never went anywhere that I can tell.
>>
>>
>> Yeah the robot will CC all "Acked-by" people in the bug reports.
>>
>> Shall we limit it to the below TO/CC list?
>
>No. We do want to keep the Acked-by's on the cc.
>
>But you missed the real problem.
>
>It *didn't* cc the acked-by. Look closer. What happened was that it cc'd this:
>
> "Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>, David S. Miller"
>
> <davem@davemloft.net>
>
>ie there is only _one_ email address (that of davem@davemloft.net),
>and the whole "Acked-by: Alexander Duyck <...>" part is quoted as the
>_name_ of that email address.
>
>At least that's what the headers look like for me in the original report:
>
> From: kernel test robot <xiaolong.ye@intel.com>
> To: Eric Dumazet <edumazet@google.com>
> Cc: lkp@01.org, Linus Torvalds <torvalds@linux-foundation.org>,
>LKML <linux-kernel@vger.kernel.org>, Alexei Starovoitov
><ast@kernel.org>, Willem de Bruijn <willemb@google.com>, "Acked-by:
>Alexander Duyck <alexander.h.duyck@intel.com>, David S. Miller"
><davem@davemloft.net>
>
>Notice the quoting of that last "name".
Ah thanks! Xiaolong just root caused the parse error and will fix it.
Interestingly we didn't see that problem -- the CC list looks correct
in our emails -- perhaps Intel's email system auto fixed up the header.
Thanks,
Fengguang
^ permalink raw reply
* Re: net/arp: ARP cache aging failed.
From: Julian Anastasov @ 2016-11-23 8:33 UTC (permalink / raw)
To: yuehaibing; +Cc: davem, netdev
In-Reply-To: <957c2a80-7302-1ce9-726e-1e7512a941f4@huawei.com>
Hello,
On Wed, 23 Nov 2016, yuehaibing wrote:
> As to my topo,HOST1 and HOST3 share one route on HOST2, tcp connection between HOST2 and HOST3 may call tcp_ack to set dst->pending_confirm.
>
> So dst_neigh_output may wrongly freshed n->confirmed which stands for HOST1,however HOST1'MAC had been changed.
>
> The possibility of this occurred Significantly increases ,when ping and TCP transaction are set the same processor affinity on the HOST2.
>
> It seems that the issue is brought in commit 5110effee8fde2edfacac9cd12a9960ab2dc39ea ("net: Do delayed neigh confirmation.").
Bad news. Problem is not in delayed confirmation but
in the mechanism to use same dst for different neighbours on
LAN. We don't have a dst->neighbour reference anymore.
For IPv4 this is related to rt->rt_uses_gateway but
also to DST_NOCACHE. In the other cases we can not call
dst_confirm, may be we should lookup the neigh entry instead.
But we need a way to reduce such lookups on every packet,
for example, by remembering in struct sock and checking if
some bits of jiffies (at least 4-5) are changed from
previous lookup.
Regards
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Arend Van Spriel @ 2016-11-23 8:24 UTC (permalink / raw)
To: Pali Rohár, Michal Kazior
Cc: Kalle Valo, Pavel Machek, Ivaylo Dimitrov, Sebastian Reichel,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel
In-Reply-To: <201611221805.13606@pali>
On 22-11-2016 18:05, Pali Rohár wrote:
> On Tuesday 22 November 2016 17:14:28 Michal Kazior wrote:
>> On 22 November 2016 at 16:31, Pali Rohár <pali.rohar@gmail.com> wrote:
>>> On Tuesday 22 November 2016 16:22:57 Michal Kazior wrote:
>>>> On 21 November 2016 at 16:51, Pali Rohár <pali.rohar@gmail.com>
>>>> wrote:
>>>>> On Friday 11 November 2016 18:20:50 Pali Rohár wrote:
>>>>>> Hi! I will open discussion about mac address and calibration
>>>>>> data for wl1251 wireless chip again...
>>>>>>
>>>>>> Problem: Mac address & calibration data for wl1251 chip on
>>>>>> Nokia N900 are stored on second nand partition (mtd1) in
>>>>>> special proprietary format which is used only for Nokia N900
>>>>>> (probably on N8x0 and N9 too). Wireless driver wl1251.ko
>>>>>> cannot work without mac address and calibration data.
>>>>
>>>> Same problem applies to some ath9k/ath10k supported routers. Some
>>>> even carry mac address as implicit offset from ethernet mac
>>>> address. As far as I understand OpenWRT cooks cal blobs on first
>>>> boot prior to loading modules.
>>>
>>> So... wl1251 on Nokia N900 is not alone and this problem is there
>>> for more drivers and devices. Which means we should come up with
>>> some generic solution.
>>
>> This isn't particularly a problem for ath9k/ath10k.
>>
>> Let me give you more background on ath10k.
>>
>> ath10k devices can come with caldata and macaddr stored in their
>> OTP/EEPROM. In that case a generic "template" board file is used.
>> Userspace doesn't need to do anything special.
>>
>> Some vendors however decide to use flash partition to store caldata.
>> In that case ath10k expects userspace to prepare
>> cal-$bus-$devname.bin files, each for a different radio (you can
>> have multiple radios on a system).
>>
>> Now translating this for wl1251 I would expect it should also use
>> something like wl1251-nvs-sdio-0x0001.bin for devices like N900 that
>> have caldata on flash partition (instead of the generic
>> wl1251-nvs.bin). I'm not sure if wl1251-nvs.bin is something
>> comparable to (the generic) board.bin ath10k has though. Maybe the
>> entire idea behind wl1251-nvs.bin is flawed as it's supposed to be
>> device specific and is oblivious to possibility of having multiple
>> wl1251 radios on one system (probably sane assumption from practical
>> standpoint but still).
>
> Basically nvs data are device specific, in ideal case they should be
> generated in factory by some calibration process (or so).
For brcmfmac we have what we call nvram data, which is determined during
manufacturing. We use the firmware_class API to obtain that file, but on
router it may be stored in flash. So an API was created for that router
architecture and brcmfmac calls that API [1]. Not a generic solution but
it gets the job done. Personally, I would have liked this to be handled
behind the firmware_class API to hide the storage details from the driver.
Regards,
Arend
[1]
http://lxr.free-electrons.com/source/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c#L449
^ permalink raw reply
* Re: [RFC net-next 0/3] net: bridge: Allow CPU port configuration
From: Jiri Pirko @ 2016-11-23 8:21 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, Ido Schimmel, netdev, davem, bridge, stephen,
vivien.didelot, jiri, idosch
In-Reply-To: <6e1bce5a-3bc6-ad7b-6cc0-ca80c0f86f55@gmail.com>
Wed, Nov 23, 2016 at 01:24:30AM CET, f.fainelli@gmail.com wrote:
>On 11/22/2016 02:08 PM, Jiri Pirko wrote:
>> Tue, Nov 22, 2016 at 06:48:29PM CET, andrew@lunn.ch wrote:
>>> Hi Ido
>>>
>>>> First of all, I want to be sure that when we say "CPU port", we're
>>>> talking about the same thing. In mlxsw, the CPU port is a pipe between
>>>> the device and the host, through which all packets trapped to the host
>>>> go through. So, when a packet is trapped, the driver reads its Rx
>>>> descriptor, checks through which port it ingressed, resolves its netdev,
>>>> sets skb->dev accordingly and injects it to the Rx path via
>>>> netif_receive_skb(). The CPU port itself isn't represented using a
>>>> netdev.
>>>
>>> With DSA, we have a real physical ethernet network interface for the
>>> 'cpu' port. It connects to one of the ports of the switch. Frames on
>>
>> Every port should be visible as a netdevice, including cpu port.
>> Would it make sence to have representors for those?
>
>The CPU port is kind of already visible with DSA since you need the
>switch to be attached to a normal Ethernet MAC driver (later referenced
>as eth0 for simplicity). Since eth0 is going to potentially receive/send
>switch tagged traffic, and the model is to terminate the interfaces at
>the port level, this interface does not really have any meaningful use
>from a data exchange, apart from multiplexing/demultiplexing switch tags
>(when enabled).
But this is not the switch port, but the counterpart on the other end of
MII. There should be 2 netdevices, one for each.
>
>If we did create a "cpu" network device, this interface would not be
>able to send/receive traffic either, because the per-port network
>interfaces are terminated at their level, and the conduit interface is
>just used for transmitting/receiving switch tagged traffic. It does have
>value as a controlling interface only though.
In this case, yes.
>
>As a controlling interface, this can be helpful, but we need to decide
>which side of the switch this CPU interface would represent, is it the
>switch's view of the CPU port, or is the Ethernet MAC view's of the
>switch's CPU port, attached to it (especially true with discrete switch
>chips).
>
>If we did use eth0 as a controlling interface, we need to somehow be
>able to overload (in an objected oriented fashioned) the netdev_ops,
>ethtool_ops and switchdev_ops for that interface so as to make it
>participate in the switch configuration (we actually do this already for
>ethtool statistics, but this is ugly).
>--
>Florian
^ permalink raw reply
* Re: Synopsys Ethernet QoS Driver
From: Giuseppe CAVALLARO @ 2016-11-23 8:02 UTC (permalink / raw)
To: Ozgur Karatas, Joao Pinto, Rayagond Kokatanur, Rabin Vincent
Cc: andreas.irestal@axis.com, alexandre.torgue@st.com,
saeedm@mellanox.com, netdev, linux-kernel@vger.kernel.org,
CARLOS.PALMINHA@synopsys.com, idosch@mellanox.com, mued dib,
jiri@mellanox.com, Jeff Kirsher, David Miller,
linux-arm-kernel@lists.infradead.org, lars.persson@axis.com
In-Reply-To: <1806171479803900@web16j.yandex.ru>
Hello Ozgur
On 11/22/2016 9:38 AM, Ozgur Karatas wrote:
> Hello all,
>
> I think, ethtool and mdio don't work because the tool's not support to "QoS", right?
>
> Maybe, need a new API. I'm looking for dwceqos code but "tc" tools is very idea.
>
> I hope to be me always helpful.
tools work but indeed should be extended to support more for QoS.
This is another task we have to keep in mind, well spot.
Peppe
>
> Regards,
>
> Ozgur
>
> 21.11.2016, 16:38, "Giuseppe CAVALLARO" <peppe.cavallaro@st.com>:
>> Hello Joao
>>
>> On 11/21/2016 2:48 PM, Joao Pinto wrote:
>>> Synopsys QoS IP is a separated hardware component, so it should be reusable by
>>> all implementations using it and so have its own "core driver" and platform +
>>> pci glue drivers. This is necessary for example in hardware validation, where
>>> you prototype an IP and instantiate its drivers and test it.
>>>
>>> Was there a strong reason to integrate QoS features directly in stmmac and not
>>> in synopsys/dwc_eth_qos.*?
>>
>> We decided to enhance the stmmac on supporting the QoS for several
>> reasons; for example the common APIs that the driver already exposed and
>> actually suitable for other SYNP chips. Then, PTP, EEE,
>> S/RGMII, MMC could be shared among different chips with a minimal
>> effort. This meant a lot of code already ready.
>>
>> For sure, the net-core, Ethtool, mdio parts were reused. Same for the
>> glue logic files.
>> For the latter, this helped to easily bring-up new platforms also
>> because the stmmac uses the HW cap register to auto-configure many
>> parts of the MAC core, DMA and modules. This helped many users, AFAIK.
>>
>> For validation purpose, this is my experience, the stmmac helped
>> a lot because people used the same code to validate different HW
>> and it was easy to switch to a platform to another one in order to
>> verify / check if the support was ok or if a regression was introduced.
>> This is important for complex supports like PTP or EEE.
>>
>> Hoping this can help.
>>
>> Do not hesitate to contact me for further details
>>
>> peppe
>
^ permalink raw reply
* [PATCH iproute2 v2] macsec: Nr. of packets and octets for macsec tx stats were swapped.
From: daniel.hopf @ 2016-11-23 7:34 UTC (permalink / raw)
To: netdev
Resent from other mail address due to our company mail
[clients|servers] stupidly forcing
line-breaks on plain-text e-mails. Also changed the subject format as
suggested by Sabrina
and Rami.
Acked-by: Rami Rosen <roszenrami@gmail.com>
Acked-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Daniel Hopf <daniel.hopf@continental-corporation.com>
---
ip/ipmacsec.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/ip/ipmacsec.c b/ip/ipmacsec.c
index c9252bb..aa89a00 100644
--- a/ip/ipmacsec.c
+++ b/ip/ipmacsec.c
@@ -634,10 +634,10 @@ static void print_one_stat(const char **names,
struct rtattr **attr, int idx,
}
static const char *txsc_stats_names[NUM_MACSEC_TXSC_STATS_ATTR] = {
- [MACSEC_TXSC_STATS_ATTR_OUT_PKTS_PROTECTED] = "OutOctetsProtected",
- [MACSEC_TXSC_STATS_ATTR_OUT_PKTS_ENCRYPTED] = "OutOctetsEncrypted",
- [MACSEC_TXSC_STATS_ATTR_OUT_OCTETS_PROTECTED] = "OutPktsProtected",
- [MACSEC_TXSC_STATS_ATTR_OUT_OCTETS_ENCRYPTED] = "OutPktsEncrypted",
+ [MACSEC_TXSC_STATS_ATTR_OUT_PKTS_PROTECTED] = "OutPktsProtected",
+ [MACSEC_TXSC_STATS_ATTR_OUT_PKTS_ENCRYPTED] = "OutPktsEncrypted",
+ [MACSEC_TXSC_STATS_ATTR_OUT_OCTETS_PROTECTED] = "OutOctetsProtected",
+ [MACSEC_TXSC_STATS_ATTR_OUT_OCTETS_ENCRYPTED] = "OutOctetsEncrypted",
};
static void print_txsc_stats(const char *prefix, struct rtattr *attr)
^ permalink raw reply related
* Re: [PATCH net 1/1] net sched filters: fix filter handle ID in tfilter_notify_chain()
From: Daniel Borkmann @ 2016-11-23 7:34 UTC (permalink / raw)
To: Roman Mashak, davem; +Cc: netdev, jhs, xiyou.wangcong
In-Reply-To: <1479866224-12285-1-git-send-email-mrv@mojatatu.com>
On 11/23/2016 02:57 AM, Roman Mashak wrote:
> Should pass valid filter handle, not the netlink flags.
>
> Fixes: 30a391a13ab92 ("net sched filters: pass netlink message flags in event notification")
> Signed-off-by: Roman Mashak <mrv@mojatatu.com>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH net-next 1/1] ipv6: sr: add option to control lwtunnel support
From: Roopa Prabhu @ 2016-11-23 7:34 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David Miller, david.lebrun, netdev@vger.kernel.org,
Lorenzo Colitti, Eric Dumazet
In-Reply-To: <CAADnVQ+MdPeZv1FpzD=omH1ftr2vW3uYiqdLL3Y_teaZj=tEbQ@mail.gmail.com>
On 11/22/16, 4:16 PM, Alexei Starovoitov wrote:
> On Wed, Nov 16, 2016 at 8:32 AM, David Miller <davem@davemloft.net> wrote:
>> From: David Lebrun <david.lebrun@uclouvain.be>
>> Date: Tue, 15 Nov 2016 16:14:04 +0100
>>
>>> This patch adds a new option CONFIG_IPV6_SEG6_LWTUNNEL to enable/disable
>>> support of encapsulation with the lightweight tunnels. When this option
>>> is enabled, CONFIG_LWTUNNEL is automatically selected.
>>>
>>> Fix commit 6c8702c60b88 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
>>>
>>> Without a proper option to control lwtunnel support for SR-IPv6, if
>>> CONFIG_LWTUNNEL=n then the IPv6 initialization fails as a consequence
>>> of seg6_iptunnel_init() failure with EOPNOTSUPP:
>>>
>>> NET: Registered protocol family 10
>>> IPv6: Attempt to unregister permanent protocol 6
>>> IPv6: Attempt to unregister permanent protocol 136
>>> IPv6: Attempt to unregister permanent protocol 17
>>> NET: Unregistered protocol family 10
>>>
>>> Tested (compiling, booting, and loading ipv6 module when relevant)
>>> with possible combinations of CONFIG_IPV6={y,m,n},
>>> CONFIG_IPV6_SEG6_LWTUNNEL={y,n} and CONFIG_LWTUNNEL={y,n}.
>>>
>>> Reported-by: Lorenzo Colitti <lorenzo@google.com>
>>> Suggested-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>>> Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
>> Applied.
> ipv6 seems to be still broken in the latest net-next
> when CONFIG_LWTUNNEL is not set:
> # ping 127.0.0.1
> ping: socket: Address family not supported by protocol
> # ping -4 127.0.0.1
> PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
> 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.067 ms
>
> it works with CONFIG_LWTUNNEL=y
>
> Roopa, David, please take a look.
>
I can't seem to reproduce the problem you are seeing. still trying..
I don't have CONFIG_LWTUNNEL set nor any of the other SEG6 configs.
My CONFIG_IPV6 is on and compiled as a module. I have also tried disabling it.
If you can send me the config, I can try again. Looking back at the patches,
I do see a few things below ..but they may not fix your problem directly.
Though I had none of the ipv6 segment routing configs turned on,
I do see the "Segment Routing with IPv6" msg at bootup.
Was looking at david's patches again, and a few things (I had missed seeing the last version):
In my review comment I was hinting at CONFIG_IPV6_SEG6 to cover all of ipv6 segment routing,
including the lwtunnel bits.
something like below:
config IPV6_SEG6
bool "IPv6: Segment Routing Header encapsulation support"
depends on LWTUNNEL && IPV6
DavidL, do you see a problem doing it this way ?. with this 'seg6.o' will be part of CONFIG_IPV6_SEG6 and not
get initialized unless it is enabled..which seems like the right thing to do.
DaveM had suggested compiling LWTUNNEL in by default. I can submit a patch for that.
But it is not clear to me yet why the right depends will not fix it.
thanks.
^ permalink raw reply
* pull request: bluetooth 2016-11-23
From: Johan Hedberg @ 2016-11-23 7:29 UTC (permalink / raw)
To: davem; +Cc: linux-bluetooth, netdev
[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]
Hi Dave,
Sorry about the late pull request for 4.9, but we have one more
important Bluetooth patch that should make it to the release. It fixes
connection creation for Bluetooth LE controllers that do not have a
public address (only a random one).
Please let me know if there are any issues pulling. Thanks.
Johan
---
The following changes since commit c9b8af1330198ae241cd545e1f040019010d44d9:
flow_dissect: call init_default_flow_dissectors() earlier (2016-11-22 14:44:01 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git for-upstream
for you to fetch changes up to 39385cb5f3274735b03ed1f8e7ff517b02a0beed:
Bluetooth: Fix using the correct source address type (2016-11-22 22:50:46 +0100)
----------------------------------------------------------------
Johan Hedberg (1):
Bluetooth: Fix using the correct source address type
include/net/bluetooth/hci_core.h | 2 +-
net/bluetooth/6lowpan.c | 4 ++--
net/bluetooth/hci_conn.c | 26 ++++++++++++++++++++++++--
net/bluetooth/l2cap_core.c | 2 +-
net/bluetooth/rfcomm/tty.c | 2 +-
net/bluetooth/sco.c | 2 +-
6 files changed, 30 insertions(+), 8 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [LKP] [net] 34fad54c25: kernel BUG at include/linux/skbuff.h:1935!
From: Linus Torvalds @ 2016-11-23 7:07 UTC (permalink / raw)
To: Fengguang Wu
Cc: kernel test robot, David Miller, Eric Dumazet, Alexander Duyck,
Willem de Bruijn, Network Development, LKML, Alexei Starovoitov,
LKP
In-Reply-To: <20161123064421.cewko2msg7mdawco@wfg-t540p.sh.intel.com>
On Tue, Nov 22, 2016 at 10:44 PM, Fengguang Wu <fengguang.wu@intel.com> wrote:
>
> On Tue, Nov 22, 2016 at 02:04:42PM -0800, Linus Torvalds wrote:
>
>> I also noticed that the kernel test robot had screwed up the
>> participants list for some reason, and had
>>
>> "Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>, David S.
>> Miller" <davem@davemloft.net>
>>
>> as one of the participants. So there's some odd commit parsing issue
>> there somewhere. But Alexander seems to have seen this report despite
>> that, it just never went anywhere that I can tell.
>
>
> Yeah the robot will CC all "Acked-by" people in the bug reports.
>
> Shall we limit it to the below TO/CC list?
No. We do want to keep the Acked-by's on the cc.
But you missed the real problem.
It *didn't* cc the acked-by. Look closer. What happened was that it cc'd this:
"Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>, David S. Miller"
<davem@davemloft.net>
ie there is only _one_ email address (that of davem@davemloft.net),
and the whole "Acked-by: Alexander Duyck <...>" part is quoted as the
_name_ of that email address.
At least that's what the headers look like for me in the original report:
From: kernel test robot <xiaolong.ye@intel.com>
To: Eric Dumazet <edumazet@google.com>
Cc: lkp@01.org, Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>, Alexei Starovoitov
<ast@kernel.org>, Willem de Bruijn <willemb@google.com>, "Acked-by:
Alexander Duyck <alexander.h.duyck@intel.com>, David S. Miller"
<davem@davemloft.net>
Notice the quoting of that last "name".
Linus
^ permalink raw reply
* Re: [LKP] [net] 34fad54c25: kernel BUG at include/linux/skbuff.h:1935!
From: Fengguang Wu @ 2016-11-23 6:44 UTC (permalink / raw)
To: Linus Torvalds
Cc: kernel test robot, David Miller, Eric Dumazet, Alexander Duyck,
Willem de Bruijn, Network Development, LKML, Alexei Starovoitov,
LKP
In-Reply-To: <CA+55aFxV7Bq583QOdYauuo2jY9EkAmgnceBukrN27ArjzFszYg@mail.gmail.com>
Hi Linus,
On Tue, Nov 22, 2016 at 02:04:42PM -0800, Linus Torvalds wrote:
[snip]
>I also noticed that the kernel test robot had screwed up the
>participants list for some reason, and had
>
> "Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>, David S.
>Miller" <davem@davemloft.net>
>
>as one of the participants. So there's some odd commit parsing issue
>there somewhere. But Alexander seems to have seen this report despite
>that, it just never went anywhere that I can tell.
Yeah the robot will CC all "Acked-by" people in the bug reports.
Shall we limit it to the below TO/CC list?
TO: author
CC: committer (maintainer)
CC: all Signed-off-by
CC: all Reviewed-by
CC: mailing lists, if the bug is found in a maintainer/well known tree
Regards,
Fengguang
>On Tue, Nov 15, 2016 at 1:20 PM, kernel test robot
><xiaolong.ye@intel.com> wrote:
>>
>> FYI, we noticed the following commit:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>> commit 34fad54c2537f7c99d07375e50cb30aa3c23bd83 ("net: __skb_flow_dissect() must cap its return value")
>>
>> in testcase: pbzip2
>> with following parameters:
>>
>> nr_threads: 25%
>> blocksize: 900K
>> cpufreq_governor: performance
>>
>>
>>
>> on test machine: 48 threads 2 sockets Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz with 64G memory
>>
>> caused below changes:
>>
>>
>> +------------------------------------------------------------------+------------+------------+
>> | | 79774d6bfa | 34fad54c25 |
>> +------------------------------------------------------------------+------------+------------+
>> | boot_successes | 0 | 2 |
>> | boot_failures | 2 | 20 |
>> | invoked_oom-killer:gfp_mask=0x | 2 | 2 |
>> | Mem-Info | 2 | 2 |
>> | Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 2 | 2 |
>> | kernel_BUG_at_include/linux/skbuff.h | 0 | 16 |
>> | invalid_opcode:#[##]SMP | 0 | 16 |
>> | RIP:eth_type_trans | 0 | 16 |
>> | Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 0 | 15 |
>> | calltrace:hub_event | 0 | 1 |
>> | WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup | 0 | 2 |
>> | calltrace:parport_pc_init | 0 | 2 |
>> | calltrace:SyS_finit_module | 0 | 2 |
>> | WARNING:at_lib/kobject.c:#kobject_add_internal | 0 | 2 |
>> +------------------------------------------------------------------+------------+------------+
>>
>>
>>
>> [ 19.375251] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
>> [ 19.388892] Sending DHCP requests .
>> [ 19.388892] ------------[ cut here ]------------
>> [ 19.388894] kernel BUG at include/linux/skbuff.h:1935!
>> [ 19.388895] invalid opcode: 0000 [#1] SMP
>> [ 19.388896] Modules linked in:
>> [ 19.388897] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-rc3-00320-g34fad54 #1
>> [ 19.388898] Hardware name: Intel Corporation S2600WP/S2600WP, BIOS SE5C600.86B.02.02.0002.122320131210 12/23/2013
>> [ 19.388899] task: ffffffff81e0e4c0 task.stack: ffffffff81e00000
>> [ 19.388904] RIP: 0010:[<ffffffff81837c48>] [<ffffffff81837c48>] eth_type_trans+0xe8/0x140
>> [ 19.388904] RSP: 0000:ffff88081e803db8 EFLAGS: 00010297
>> [ 19.388905] RAX: 0000000000000152 RBX: ffff88080221f200 RCX: 0000000000001073
>> [ 19.388905] RDX: ffff8808013afdc0 RSI: ffff880801114000 RDI: ffff880819407c00
>> [ 19.388906] RBP: ffff88081e803e20 R08: ffff880801114000 R09: 0000000000000800
>> [ 19.388907] R10: ffff8808013afec0 R11: ffffea003fd5a880 R12: ffff880819407c00
>> [ 19.388907] R13: ffff881033408000 R14: ffffc9000843e000 R15: 0000000000000158
>> [ 19.388908] FS: 0000000000000000(0000) GS:ffff88081e800000(0000) knlGS:0000000000000000
>> [ 19.388909] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [ 19.388910] CR2: ffff88103ffff000 CR3: 0000000001e07000 CR4: 00000000001406f0
>> [ 19.388910] Stack:
>> [ 19.388912] ffffffff816905a7 ffffea003fd5a880 ffffea0000000008 ffff88080221f050
>> [ 19.388913] ffff88080221f000 0000004000000160 ffffea003fd5a880 0000000000000000
>> [ 19.388915] 0000000000000040 0000000000000000 ffff88080221f050 ffff88100d216000
>> [ 19.388915] Call Trace:
>> [ 19.388919] <IRQ>
>> [ 19.388919] [<ffffffff816905a7>] ? igb_clean_rx_irq+0x6a7/0x7d0
>> [ 19.388921] [<ffffffff81690a52>] igb_poll+0x382/0x700
>> [ 19.388922] [<ffffffff81690a67>] ? igb_poll+0x397/0x700
>> [ 19.388925] [<ffffffff8180f2d7>] net_rx_action+0x217/0x360
>> [ 19.388928] [<ffffffff81957fb4>] __do_softirq+0x104/0x2ab
>> [ 19.388931] [<ffffffff81086961>] irq_exit+0xf1/0x100
>> [ 19.388932] [<ffffffff81957cf4>] do_IRQ+0x54/0xd0
>> [ 19.388935] [<ffffffff81955b8c>] common_interrupt+0x8c/0x8c
>> [ 19.388938] <EOI>
>> [ 19.388938] [<ffffffff817c1d12>] ? cpuidle_enter_state+0x122/0x2e0
>> [ 19.388939] [<ffffffff817c1f07>] cpuidle_enter+0x17/0x20
>> [ 19.388942] [<ffffffff810c64c3>] call_cpuidle+0x23/0x40
>> [ 19.388944] [<ffffffff810c66f4>] cpu_startup_entry+0x114/0x200
>> [ 19.388946] [<ffffffff81947675>] rest_init+0x85/0x90
>> [ 19.388950] [<ffffffff81ffbf5c>] start_kernel+0x407/0x414
>> [ 19.388952] [<ffffffff81ffb120>] ? early_idt_handler_array+0x120/0x120
>> [ 19.388953] [<ffffffff81ffb2d6>] x86_64_start_reservations+0x2a/0x2c
>> [ 19.388955] [<ffffffff81ffb415>] x86_64_start_kernel+0x13d/0x14c
>> [ 19.388968] Code: 00 04 00 00 c9 c3 48 33 86 70 03 00 00 48 c1 e0 10 48 85 c0 0f b6 87 90 00 00 00 75 28 83 e0 f8 83 c8 01 88 87 90 00 00 00 eb 82 <0f> 0b 0f b6 87 90 00 00 00 83 e0 f8 83 c8 03 88 87 90 00 00 00
>> [ 19.388970] RIP [<ffffffff81837c48>] eth_type_trans+0xe8/0x140
>> [ 19.388970] RSP <ffff88081e803db8>
>> [ 19.388996] ---[ end trace 107996155a43a15c ]---
>> [ 19.393422] Kernel panic - not syncing: Fatal exception in interrupt
>>
>>
>> To reproduce:
>>
>> git clone git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
>> cd lkp-tests
>> bin/lkp install job.yaml # job file is attached in this email
>> bin/lkp run job.yaml
>>
>>
>>
>> Thanks,
>> Kernel Test Robot
>_______________________________________________
>LKP mailing list
>LKP@lists.01.org
>https://lists.01.org/mailman/listinfo/lkp
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox