* Task blocked on a ext4 partition
From: Felipe Wilhelms Damasio - Taghos @ 2011-08-15 20:51 UTC (permalink / raw)
To: netdev
Hi All,
I'm using a mmap-based file sharing system on an ext4 partition with
epoll on an ISP.
Last night the system got a significant slow down, and dmesg showed a
lot of these:
INFO: task fshare:23798 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
fshare D 0000000000000007 0 23798 17719 0x00000000
ffff88018af29648 0000000000000082 0000000000012500 ffff88018af29fd8
ffff88018af29fd8 ffff88042d371a40 0000000000012500 0000000000012500
0000000000012500 ffff88042d371a40 ffff88042e0d5550 ffff88042d371ce8
Call Trace:
[<ffffffff8102e155>] ? enqueue_entity+0x11f/0x127
[<ffffffff8151c9c7>] schedule_timeout+0x22/0xda
[<ffffffff81035288>] ? get_parent_ip+0x11/0x41
[<ffffffff8103541e>] ? sub_preempt_count+0x92/0xa5
[<ffffffff8151c0fc>] wait_for_common+0xca/0x140
[<ffffffff81037bd1>] ? default_wake_function+0x0/0xf
[<ffffffff8151c20c>] wait_for_completion+0x18/0x1a
[<ffffffff810df950>] writeback_inodes_sb+0xb4/0xbf
[<ffffffff810dfe60>] writeback_inodes_sb_if_idle+0x37/0x4b
[<ffffffff81124b34>] ext4_da_write_begin+0xa5/0x1e6
[<ffffffff8108fdab>] ? find_lock_page+0x1e/0x5d
[<ffffffff8111e263>] ext4_page_mkwrite+0x117/0x168
[<ffffffff810a316b>] __do_fault+0x125/0x388
[<ffffffff81035288>] ? get_parent_ip+0x11/0x41
[<ffffffff810a52d6>] handle_mm_fault+0x429/0x838
[<ffffffff8102211e>] do_page_fault+0x222/0x239
[<ffffffff8151e44f>] page_fault+0x1f/0x30
[<ffffffff8122e1ed>] ? copy_user_generic_string+0x2d/0x40
[<ffffffff81457020>] ? memcpy_toiovec+0x37/0x66
[<ffffffff814578ee>] skb_copy_datagram_iovec+0x4b/0x1cf
[<ffffffff81035288>] ? get_parent_ip+0x11/0x41
[<ffffffff81494fb9>] tcp_recvmsg+0x746/0xa62
[<ffffffff814b09ed>] inet_recvmsg+0x5a/0x78
[<ffffffff8144d89a>] __sock_recvmsg+0x7b/0x87
[<ffffffff8144db5b>] sock_recvmsg+0xa6/0xbf
[<ffffffff814922e2>] ? tcp_poll+0x2b/0x180
[<ffffffff810c584c>] ? fget_light+0x93/0xa9
[<ffffffff8144dcd9>] ? sockfd_lookup_light+0x1b/0x53
[<ffffffff8144f291>] sys_recvfrom+0xb0/0xfe
[<ffffffff810f11c5>] ? sys_epoll_wait+0x28f/0x2a7
[<ffffffff81002a2b>] system_call_fastpath+0x16/0x1b
Do you have any idea what could cause this?
The kernel I'm using is 2.6.35.13. Is there any other info I can provide
to help track this down?
Cheers,
--
Felipe Wilhelms Damasio
TAGHOS - Tecnologia
Rua Prof. Alvaro Alvim, 211
Porto Alegre - RS - (51) 3239-3180
www.taghos.com.br
^ permalink raw reply
* Re: invalid requirement from ethtool?
From: David Miller @ 2011-08-15 20:49 UTC (permalink / raw)
To: bhutchings; +Cc: eli, netdev
In-Reply-To: <1313429040.2731.17.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 15 Aug 2011 18:24:00 +0100
> David, I know you maintained tg3 for some time so I assume you have a
> hardware reference. Can you confirm whether a value of 1 in
> HOSTCC_{RX,TX}MAX_FRAMES results in an interrupt after 1 completion or
> after 2 completions?
A value of 1 results in an interrupt after 1 completion.
If you put a zero there, the packet count comparison never triggers.
^ permalink raw reply
* Re: [PATCH] bnx2x: suppress repeated error messages about Max BW
From: Eilon Greenstein @ 2011-08-15 18:47 UTC (permalink / raw)
To: Michal Schmidt
Cc: netdev@vger.kernel.org, Dmitry Kravkov, Vladislav Zolotarov
In-Reply-To: <4E493798.7010405@redhat.com>
On Mon, 2011-08-15 at 08:13 -0700, Michal Schmidt wrote:
> On 08/15/2011 02:33 PM, Eilon Greenstein wrote:
> > On Mon, 2011-08-15 at 04:59 -0700, Michal Schmidt wrote:
> >> and bnx2x_init_vn_minmax() calls bnx2x_extract_max_cfg() on the given
> >> VN, so it seems that the warning can be produced for a non-current VN.
> >
> > You are right, only one function (the PMF) will call this code for all
> > functions. But I suspect that if you have zero values, you will have
> > them for all VNs - is that the case?
>
> A tester reported getting only these 4 messages with the patch applied:
>
> [bnx2x_extract_max_cfg:1074(eth4)]Illegal configuration detected for Max
> BW on vn 2 - using 100 instead
> [bnx2x_extract_max_cfg:1074(eth5)]Illegal configuration detected for Max
> BW on vn 2 - using 100 instead
> [bnx2x_extract_max_cfg:1074(eth6)]Illegal configuration detected for Max
> BW on vn 3 - using 100 instead
> [bnx2x_extract_max_cfg:1074(eth7)]Illegal configuration detected for Max
> BW on vn 3 - using 100 instead
>
> This suggests that VNs 0 and 1 had non-zero Max BW configuration.
Michal - this is a great point of data! It helped me finding a bug in
that code - the code is not suitable for 4 port devices, it always
assumes 4 VN per PCI function, while in 4 port devices there are only 2
VN per PCI function. I assume that you are seeing this problem on a
57800 with 2x10G + 2x1G - and the 1G devices are in single function mode
and therefore you are seeing this error message. I will send a patch to
fix the problem on 4 port devices soon (after testing it for a while) -
please confirm that you are seeing this issue on 2x10G+2x1G 57800
device.
Now it all makes sense to me - it’s not just misconfigured board
workaround, this is a real issue :)
Thanks for helping in identifying it!
Eilon
^ permalink raw reply
* Re: [RFC PATCH v2 9/9] sfc: Support for byte queue limits
From: Ben Hutchings @ 2011-08-15 18:36 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.00.1108072151500.13386@pokey.mtv.corp.google.com>
On Sun, 2011-08-07 at 21:53 -0700, Tom Herbert wrote:
> Changes to sfc to use byte queue limits.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> drivers/net/sfc/tx.c | 27 +++++++++++++++++++++------
> 1 files changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/sfc/tx.c b/drivers/net/sfc/tx.c
> index 84eb99e..9aa4339 100644
> --- a/drivers/net/sfc/tx.c
> +++ b/drivers/net/sfc/tx.c
> @@ -31,7 +31,9 @@
> #define EFX_TXQ_THRESHOLD(_efx) ((_efx)->txq_entries / 2u)
>
> static void efx_dequeue_buffer(struct efx_tx_queue *tx_queue,
> - struct efx_tx_buffer *buffer)
> + struct efx_tx_buffer *buffer,
> + unsigned int *pkts_compl,
> + unsigned int *bytes_compl)
> {
> if (buffer->unmap_len) {
> struct pci_dev *pci_dev = tx_queue->efx->pci_dev;
> @@ -48,6 +50,8 @@ static void efx_dequeue_buffer(struct efx_tx_queue *tx_queue,
> }
>
> if (buffer->skb) {
> + (*pkts_compl)++;
> + (*bytes_compl) += buffer->skb->len;
We avoid using *buffer->skb on the completion path, as it is liklely to
be cache-cold. I would prefer to add and subtract fragment lengths
(buffer->len) instead. (This will also result in a slightly more
accurate estimate of the queue length when TSO is used.)
> dev_kfree_skb_any((struct sk_buff *) buffer->skb);
> buffer->skb = NULL;
> netif_vdbg(tx_queue->efx, tx_done, tx_queue->efx->net_dev,
> @@ -254,6 +258,8 @@ netdev_tx_t efx_enqueue_skb(struct efx_tx_queue *tx_queue, struct sk_buff *skb)
> buffer->skb = skb;
> buffer->continuation = false;
>
> + netdev_tx_sent_queue(tx_queue->core_txq, 1, skb->len);
> +
> /* Pass off to hardware */
> efx_nic_push_buffers(tx_queue);
>
> @@ -271,10 +277,11 @@ netdev_tx_t efx_enqueue_skb(struct efx_tx_queue *tx_queue, struct sk_buff *skb)
> unwind:
> /* Work backwards until we hit the original insert pointer value */
> while (tx_queue->insert_count != tx_queue->write_count) {
> + unsigned int pkts_compl = 0, bytes_compl = 0;
> --tx_queue->insert_count;
> insert_ptr = tx_queue->insert_count & tx_queue->ptr_mask;
> buffer = &tx_queue->buffer[insert_ptr];
> - efx_dequeue_buffer(tx_queue, buffer);
> + efx_dequeue_buffer(tx_queue, buffer, &pkts_compl, &bytes_compl);
> buffer->len = 0;
> }
>
> @@ -297,7 +304,9 @@ netdev_tx_t efx_enqueue_skb(struct efx_tx_queue *tx_queue, struct sk_buff *skb)
> * specified index.
> */
> static void efx_dequeue_buffers(struct efx_tx_queue *tx_queue,
> - unsigned int index)
> + unsigned int index,
> + unsigned int *pkts_compl,
> + unsigned int *bytes_compl)
> {
> struct efx_nic *efx = tx_queue->efx;
> unsigned int stop_index, read_ptr;
> @@ -315,7 +324,7 @@ static void efx_dequeue_buffers(struct efx_tx_queue *tx_queue,
> return;
> }
>
> - efx_dequeue_buffer(tx_queue, buffer);
> + efx_dequeue_buffer(tx_queue, buffer, pkts_compl, bytes_compl);
[...]
Since efx_deqeueue_buffers() is the only caller of efx_dequeue_buffer()
that actually wants to count the completed packets & bytes, the counting
should be done here.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] net: netdev-features.txt update to Documentation/networking/00-INDEX
From: Willem de Bruijn @ 2011-08-15 18:27 UTC (permalink / raw)
To: netdev; +Cc: mircus, davem
Update netdev-features.txt entry in 00-INDEX to incorporate
feedback by Michał Mirosław. A trivial update to my previous
patch, but I was too late with preparing a v2. Will try to
avoid having to send patches to my own patches in the future.
willem
Signed-off-by: Willem de Bruijn <willemb@gmail.com>
---
Documentation/networking/00-INDEX | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX
index 811252b..bbce121 100644
--- a/Documentation/networking/00-INDEX
+++ b/Documentation/networking/00-INDEX
@@ -135,7 +135,7 @@ multiqueue.txt
netconsole.txt
- The network console module netconsole.ko: configuration and notes.
netdev-features.txt
- - Network interface "feature mess and how to get out from it alive".
+ - Network interface features API description.
netdevices.txt
- info on network device driver functions exported to the kernel.
netif-msg.txt
--
1.7.3.1
^ permalink raw reply related
* Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups
From: Stephen Hemminger @ 2011-08-15 18:25 UTC (permalink / raw)
To: Nick Carter; +Cc: David Lamparter, netdev, Michał Mirosław, davem
In-Reply-To: <CAEJpZP3PHC32i8m74-ML6DDGii8ojJ6v12CqQ+v2MKEMSDU=7A@mail.gmail.com>
On Mon, 15 Aug 2011 17:27:12 +0100
Nick Carter <ncarter100@gmail.com> wrote:
> On 28 July 2011 16:41, Stephen Hemminger
> <shemminger@linux-foundation.org> wrote:
> > On Wed, 27 Jul 2011 13:17:15 +0200
> > David Lamparter <equinox@diac24.net> wrote:
> >
> >> On Fri, Jul 15, 2011 at 06:33:45PM +0200, David Lamparter wrote:
> >> > On Fri, Jul 15, 2011 at 06:03:57PM +0200, David Lamparter wrote:
> >> > > On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:
> >> > > > On 12 July 2011 12:36, David Lamparter <equinox@diac24.net> wrote:
> >> > > > > On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
> >> > > > >> I am still undecided on this. Understand the need, but don't like idea
> >> > > > >> of bridge behaving in non-conforming manner. Will see if IEEE 802 committee
> >> > > > >> has any input.
> >> > > > >
> >> > > > > The patch doesn't make the bridge behave nonconformant. The default mask
> >> > > > > is 0, which just keeps the old behaviour.
> >> >
> >> > P.S.: I'd like to once more stress this. In my opinion the patch should
> >> > be merged because it provides desireable functionality at a small cost
> >> > (one test, one knob) and __does not change any default behaviour__.
> >>
> >> Stephen, anything new on this?
> >
> > No.
> > Don't like adding yet another hack user visible API which will have
> > to be maintained for too long. But on the other hand I don't have
> > a better solution at my finger tips. If better idea doesn't come
> > along, then we can go with yours.
> >
> I have not noticed any other proposals and this thread has been open
> for quite a while. Have we waited long enough ? If so can this patch
> be taken ?
>
I am testing an alternative. The problem with your proposal is that
it relies on the multicast address. It turns out there are people using
other addresses for the STP group address, so using that as a identifier
is incorrect.
^ permalink raw reply
* Re: igb transmit queue timed out, rcu_sched_state detected stall
From: Ben Hutchings @ 2011-08-15 18:07 UTC (permalink / raw)
To: Peter Neal; +Cc: netdev
In-Reply-To: <CALJvf+qGt=GkD2oV8GEz7DWLzpCZGaAE5Gpse8HvPjgpT2Wmxw@mail.gmail.com>
On Mon, 2011-08-15 at 15:33 +0100, Peter Neal wrote:
> I have updated the BIOS, iproute2, e1000e and igb drivers, but am
> still seeing issues, any thoughts?
[...]
This issue doesn't seem network-related. However it might be related to
this regression that I saw discussed just a few minutes ago:
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40092
Subject : RCU stall in linux-3.0.0
Submitter : Philip Armstrong <phil@kantaka.co.uk>
Date : 2011-07-25 21:44 (21 days old)
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: 3.1-rc1-git9: Reported regressions 2.6.39 -> 3.0
From: Rafael J. Wysocki @ 2011-08-15 17:43 UTC (permalink / raw)
To: paulmck
Cc: Linux Kernel Mailing List, Maciej Rutecki, Florian Mickler,
Andrew Morton, Linus Torvalds, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <20110815153759.GF2389@linux.vnet.ibm.com>
On Monday, August 15, 2011, Paul E. McKenney wrote:
> On Sun, Aug 14, 2011 at 09:02:27PM +0200, Rafael J. Wysocki wrote:
> > [NOTE:
> > We already have a bug entry for tracking regressions from 3.0:
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=40982
> >
> > but there are no reports linked to it, mostly because Maciej is on vacation,
> > but also because the frequency of reporting regressions has been low
> > recently. So, if you're seeing a regression from 3.0, please let us know.]
> >
> > This message contains a list of some post-2.6.39 regressions introduced before
> > 3.0, for which there are no fixes in the mainline known to the tracking team.
> > If any of them have been fixed already, please let us know.
> >
> > If you know of any other unresolved post-2.6.39 regressions, please let us know
> > either and we'll add them to the list. Also, please let us know if any
> > of the entries below are invalid.
> >
> > Each entry from the list will be sent additionally in an automatic reply to
> > this message with CCs to the people involved in reporting and handling the
> > issue.
> >
> >
> > Listed regressions statistics:
> >
> > Date Total Pending Unresolved
> > ----------------------------------------
> > 2011-08-14 63 22 19
> >
> >
> > Unresolved regressions
> > ----------------------
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40282
> > Subject : IP forwarding regression since 3.0-rc6
> > Submitter : Stephan Seitz <stse+lkml@fsing.rootsland.net>
> > Date : 2011-07-25 12:51 (21 days old)
> > Message-ID : <20110725T141145.GA.2ae38.stse@fsing.rootsland.net>
> > References : http://marc.info/?l=linux-kernel&m=131159880004908&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40172
> > Subject : lockdep trace from post 3.0.
> > Submitter : Dave Jones <davej@redhat.com>
> > Date : 2011-07-24 1:32 (22 days old)
> > Message-ID : <20110724013257.GA6777@redhat.com>
> > References : http://marc.info/?l=linux-kernel&m=131147120206819&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40092
> > Subject : RCU stall in linux-3.0.0
> > Submitter : Philip Armstrong <phil@kantaka.co.uk>
> > Date : 2011-07-25 21:44 (21 days old)
>
> This one was due the the CPU's idea of the current time getting way
> out of sync (as in more than a minute's worth of disagreement, which is
> pretty impressive when you think about it). So what happened is that
> one CPU decided that the current grace period was a full minute old
> immediately, and thus started screaming piteously. John Stultz provided
> a configuration workaround, and he and Thomas Gleixner would be working
> out the long-term fix.
Thanks for the update!
Rafael
^ permalink raw reply
* Re: invalid requirement from ethtool?
From: Ben Hutchings @ 2011-08-15 17:24 UTC (permalink / raw)
To: Eli Cohen, David Miller; +Cc: netdev
In-Reply-To: <20110726124222.GA4842@mtldesk30>
On Tue, 2011-07-26 at 15:42 +0300, Eli Cohen wrote:
> Hi,
> I see the following text in include/linux/ethtool.h and wonder what is
> the reasoning for requiring that both params cannot be zero. I could
> not track when and who inserted this text as it dates before git was
> used to track kernel code, but my feeling is that is related to a
> specific hardware limitation.
>
> /* How many packets to delay an RX interrupt after
> * a packet arrives. If 0, only rx_coalesce_usecs is
> * used. It is illegal to set both usecs and max frames
> * to zero as this would cause RX interrupts to never be
> * generated.
> */
> __u32 rx_max_coalesced_frames;
>
> /* How many packets to delay a TX interrupt after
> * a packet is sent. If 0, only tx_coalesce_usecs is
> * used. It is illegal to set both usecs and max frames
> * to zero as this would cause TX interrupts to never be
> * generated.
> */
> __u32 tx_max_coalesced_frames;
>
> I found this in tg3 driver:
> /* No rx interrupts will be generated if both are zero */
> if ((ec->rx_coalesce_usecs == 0) &&
> (ec->rx_max_coalesced_frames == 0))
> return -EINVAL;
>
> However, bnx2 for example allows setting both to zero.
>
> I think both params zero should be allowed and mean coalescing is not
> operational, thus we can remove these comments from ethtool.h
If coalescing is not operational, the maximum number of completions
before an interrupt is 1. So logically {rx,tx}_max_coalesced_frames
should be 1, right? Although the comment does say 'How many packets ...
after ...' which implies that the value of the field must be 1 less than
the wanted maximum, i.e. 0, which is supposedly invalid.
The first implementation of ethtool coalescing control was in tg3, so it
should be a useful reference.
David, I know you maintained tg3 for some time so I assume you have a
hardware reference. Can you confirm whether a value of 1 in
HOSTCC_{RX,TX}MAX_FRAMES results in an interrupt after 1 completion or
after 2 completions?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 2/2] net: minor update to Documentation/networking/scaling.txt
From: Rick Jones @ 2011-08-15 16:56 UTC (permalink / raw)
To: Will de Bruijn; +Cc: rdunlap, linux-doc, davem, netdev, therbert
In-Reply-To: <CA+FuTScsrN5=NLeHgyNP+TXL+_auU6p80Lb5JUaMb_o5aGGqww@mail.gmail.com>
On 08/15/2011 09:11 AM, Will de Bruijn wrote:
>> I'd suggest simply "share a particular level in the memory hierarchy (Cache,
>> NUMA node, etc)" and that way you get away from people asking nitpicky
>> questions about where cache hierarchy counting starts, and at what level
>> caches might be shared :)
>>
>> Apart from that, looks fine.
>
> Thanks. It is already applied, so if you don't feel strongly about
> this, I'll leave it as is (and take any nitpicky flak if that comes ;)
Sounds like a plan.
rick
^ permalink raw reply
* Kindly read and reply through my private email... inna.patarkat3@qatar.io
From: Enquiries @ 2011-08-15 15:26 UTC (permalink / raw)
Kindly read and reply through my private email... inna.patarkat3@qatar.io
An Emergency from Mrs. Inna Patarkatsishvil
Greetings in the name of the Lord, I am Mrs. Inna Patarkatsishvili, the widow of late Georgian business tycoon Mr. Badri Patarkatsishvili, I have a business proposal which will be of great benefit to you and myself. I will send you further details once i receive your response back. Please for security reason, i will strongly recommend that you write me through my private email account only.Thanks for your understanding.
Yours truly,
Mrs. Inna Patarkatsishvili
Private Email: inna.patarkat4@qatar.io
-------------------------------------------------------------------------
DISCLAIMER:-
Matheson & Co., Limited is a company registered in England and Wales.
Company Registration Number: 100295.
Registered Office: 3 Lombard Street, London EC3V 9AQ, UK
Matheson & Co., Limited, established in London in 1848, is a wholly owned
subsidiary of Jardine Matheson Holdings Limited.
This email is confidential and intended only for the use
of the individual or entity named above and may contain
information that is privileged. If you are not the intended
recipient, you are notified that any dissemination, distribution
or copying of this email is strictly prohibited.
If you have received this email in error, please notify us immediately by
return email or telephone 020 7816 8100 and destroy the original message.
Thank you.
-------------------------------------------------------------------------
^ permalink raw reply
* [PATCH] dm9000: control debug level of the driver
From: Vladimir Zapolskiy @ 2011-08-15 16:38 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Vladimir Zapolskiy, Ben Dooks
This change allows to get driver specific debug messages output
setting a default value for db->debug_level. As far as the maximum
level of verbosity is too high, it is demoted by default.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
drivers/net/Kconfig | 2 +-
drivers/net/dm9000.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 8d0314d..20e7936 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -988,7 +988,7 @@ config DM9000
config DM9000_DEBUGLEVEL
int "DM9000 maximum debug level"
depends on DM9000
- default 4
+ default 0
help
The maximum level of debugging code compiled into the DM9000
driver.
diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
index 8ef31dc..b8509a8 100644
--- a/drivers/net/dm9000.c
+++ b/drivers/net/dm9000.c
@@ -138,8 +138,7 @@ typedef struct board_info {
/* debug code */
#define dm9000_dbg(db, lev, msg...) do { \
- if ((lev) < CONFIG_DM9000_DEBUGLEVEL && \
- (lev) < db->debug_level) { \
+ if ((lev) < db->debug_level) { \
dev_dbg(db->dev, msg); \
} \
} while (0)
@@ -1381,6 +1380,7 @@ dm9000_probe(struct platform_device *pdev)
db->dev = &pdev->dev;
db->ndev = ndev;
+ db->debug_level = CONFIG_DM9000_DEBUGLEVEL;
spin_lock_init(&db->lock);
mutex_init(&db->addr_lock);
--
1.7.5.1
^ permalink raw reply related
* Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups
From: Nick Carter @ 2011-08-15 16:27 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Lamparter, netdev, Michał Mirosław, davem
In-Reply-To: <20110728084106.22166324@nehalam.ftrdhcpuser.net>
On 28 July 2011 16:41, Stephen Hemminger
<shemminger@linux-foundation.org> wrote:
> On Wed, 27 Jul 2011 13:17:15 +0200
> David Lamparter <equinox@diac24.net> wrote:
>
>> On Fri, Jul 15, 2011 at 06:33:45PM +0200, David Lamparter wrote:
>> > On Fri, Jul 15, 2011 at 06:03:57PM +0200, David Lamparter wrote:
>> > > On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:
>> > > > On 12 July 2011 12:36, David Lamparter <equinox@diac24.net> wrote:
>> > > > > On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
>> > > > >> I am still undecided on this. Understand the need, but don't like idea
>> > > > >> of bridge behaving in non-conforming manner. Will see if IEEE 802 committee
>> > > > >> has any input.
>> > > > >
>> > > > > The patch doesn't make the bridge behave nonconformant. The default mask
>> > > > > is 0, which just keeps the old behaviour.
>> >
>> > P.S.: I'd like to once more stress this. In my opinion the patch should
>> > be merged because it provides desireable functionality at a small cost
>> > (one test, one knob) and __does not change any default behaviour__.
>>
>> Stephen, anything new on this?
>
> No.
> Don't like adding yet another hack user visible API which will have
> to be maintained for too long. But on the other hand I don't have
> a better solution at my finger tips. If better idea doesn't come
> along, then we can go with yours.
>
I have not noticed any other proposals and this thread has been open
for quite a while. Have we waited long enough ? If so can this patch
be taken ?
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH net-2.6] bonding:restore backup and inactive flag of slave
From: WANG Cong @ 2011-08-15 16:18 UTC (permalink / raw)
To: netdev
In-Reply-To: <13dbe805d13bba461e50483c0162ce8bc1366204.1313403625.git.panweiping3@gmail.com>
On Mon, 15 Aug 2011 18:25:16 +0800, Weiping Pan wrote:
>
> diff --git a/drivers/net/bonding/bond_main.c
> b/drivers/net/bonding/bond_main.c index 38a83ac..3ed9827 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -3419,9 +3419,27 @@ static int bond_xmit_hash_policy_l2(struct
sk_buff *skb, int count)
> static int bond_open(struct net_device *bond_dev) {
> struct bonding *bond = netdev_priv(bond_dev);
> + struct slave *slave;
> + int i;
>
> bond->kill_timers = 0;
>
> + // restore slave->backup and slave->inactive
Please use C-style comment.
> + read_lock(&bond->lock);
> + read_lock(&bond->curr_slave_lock);
> + if (bond->slave_cnt > 0) {
You can move the second read_lock() under this if().
^ permalink raw reply
* [PATCH net-next] ipv4: one more case for non-local saddr in ICMP
From: Julian Anastasov @ 2011-08-15 16:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Herbert Xu
May be there is one more case that we can avoid using
non-local source for ICMP errors: xfrm_lookup, num_xfrms = 0 when
reverse "Flow passes untransformed". Avoid using the input route
if xfrm_lookup returns same dst.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
In fact, should we use local IP in all cases when
sending ICMP? I'm asking it for the following case:
Large packet is forwarded but is rejected with ICMP FRAG
NEEDED. We usually send ICMP with local saddr instead of the
original non-local destination. What is the role of
this reverse check? May be after xfrm_decode_session_reverse
we should use 'fl4_dec.saddr = fl4->saddr;' so that xfrm_lookup
works with ICMP from local IP? What is right thing to do here?
I don't see code that looks in the embedded header...
--- net-next/net/ipv4/icmp.c 2011-08-15 18:42:21.289899686 +0300
+++ linux/net/ipv4/icmp.c 2011-08-15 18:38:25.816244111 +0300
@@ -379,7 +379,7 @@ static struct rtable *icmp_route_lookup(
int type, int code,
struct icmp_bxm *param)
{
- struct rtable *rt, *rt2;
+ struct rtable *rt, *rt2, *rt3;
struct flowi4 fl4_dec;
int err;
@@ -440,13 +440,18 @@ static struct rtable *icmp_route_lookup(
if (err)
goto relookup_failed;
+ rt3 = rt2;
rt2 = (struct rtable *) xfrm_lookup(net, &rt2->dst,
flowi4_to_flowi(&fl4_dec), NULL,
XFRM_LOOKUP_ICMP);
if (!IS_ERR(rt2)) {
- dst_release(&rt->dst);
- memcpy(fl4, &fl4_dec, sizeof(*fl4));
- rt = rt2;
+ if (rt2 == rt3 && rt) {
+ dst_release(&rt2->dst);
+ } else {
+ dst_release(&rt->dst);
+ memcpy(fl4, &fl4_dec, sizeof(*fl4));
+ rt = rt2;
+ }
} else if (PTR_ERR(rt2) == -EPERM) {
if (rt)
dst_release(&rt->dst);
^ permalink raw reply
* Re: [PATCH v12 3/6] flexcan: Fix up fsl-flexcan device tree binding.
From: Marc Kleine-Budde @ 2011-08-15 16:13 UTC (permalink / raw)
To: Robin Holt
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, U Bhaskar-B22300,
Kumar Gala, Grant Likely, Scott Wood, PPC list,
Wolfgang Grandegger
In-Reply-To: <20110815150357.GM4926-sJ/iWh9BUns@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1648 bytes --]
On 08/15/2011 05:03 PM, Robin Holt wrote:
> Earlier, you had asked for a more specific name for the compatible
> property of the Freescale flexcan device. I still have not gotten a
> more specific answer. Hopefully Marc can give you more details about
> the flexcan implementations.
There are at least 2 versions of the flexcan ip core in the wild. Due to
lack of version numbers or other names I call them old and new here :).
The newer one supports rx fifo mode, whereas the older one doesn't. The
mainline flexcan driver just supports the new core [1]. The older core
is found on coldfire processors. I don't know if there are coldfire cpus
with the new flexcan core, too. The driver can be adopted to the old
core if needed.
The first cpus with the new core I got in touch with was the mx35
(arm11) and mx25 (arm9) both at the same time. Ask fsl which one was
released first. After this there was mx28 (arm9) and there should be an
mx53 (coretexa8) with flexcan too.
> Other than an agreement on the compatible property, I believe we have
> agreement on all the other code changes in these patches. Is this change
> acceptable as is and if we get a better resolution on the fsl,flexcan
> name later, we can update the documentation and driver then?
cheers, Marc
[1] http://lxr.linux.no/linux+v3.0.1/drivers/net/can/flexcan.c#L871
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH 2/2] net: minor update to Documentation/networking/scaling.txt
From: Will de Bruijn @ 2011-08-15 16:11 UTC (permalink / raw)
To: Rick Jones; +Cc: rdunlap, linux-doc, davem, netdev, therbert
In-Reply-To: <4E45B810.3000501@hp.com>
> I'd suggest simply "share a particular level in the memory hierarchy (Cache,
> NUMA node, etc)" and that way you get away from people asking nitpicky
> questions about where cache hierarchy counting starts, and at what level
> caches might be shared :)
>
> Apart from that, looks fine.
Thanks. It is already applied, so if you don't feel strongly about
this, I'll leave it as is (and take any nitpicky flak if that comes ;)
^ permalink raw reply
* Re: [PATCH] ethtool: RX NFC - Convert ip address to big endian.
From: Ben Hutchings @ 2011-08-15 16:00 UTC (permalink / raw)
To: nirmu; +Cc: netdev, Nir Muchtar
In-Reply-To: <1313422846-6550-1-git-send-email-nirmu@dev.mellanox.co.il>
On Mon, 2011-08-15 at 18:40 +0300, nirmu@dev.mellanox.co.il wrote:
> From: Nir Muchtar <nirmu@dev.mellanox.co.il>
>
> Signed-off-by: Nir Muchtar <nirmu@mellanox.com>
> ---
> Unless there's a reason that I'm missing to why the user
> is expected to specify ip addresses in big endian format.
>
> rxclass.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/rxclass.c b/rxclass.c
> index b227901..98d035b 100644
> --- a/rxclass.c
> +++ b/rxclass.c
> @@ -704,7 +704,7 @@ static int rxclass_get_ulong(char *str, unsigned long long *val, int size)
> return 0;
> }
>
> -static int rxclass_get_ipv4(char *str, __be32 *val)
> +static int rxclass_get_ipv4(char *str, u32 *val)
> {
> if (!inet_pton(AF_INET, str, val))
> return -1;
[...]
inet_pton() does the conversion to big-endian format.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] ethtool: RX NFC - Convert ip address to big endian.
From: nirmu @ 2011-08-15 15:40 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, Nir Muchtar, Nir Muchtar
From: Nir Muchtar <nirmu@dev.mellanox.co.il>
Signed-off-by: Nir Muchtar <nirmu@mellanox.com>
---
Unless there's a reason that I'm missing to why the user
is expected to specify ip addresses in big endian format.
rxclass.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/rxclass.c b/rxclass.c
index b227901..98d035b 100644
--- a/rxclass.c
+++ b/rxclass.c
@@ -704,7 +704,7 @@ static int rxclass_get_ulong(char *str, unsigned long long *val, int size)
return 0;
}
-static int rxclass_get_ipv4(char *str, __be32 *val)
+static int rxclass_get_ipv4(char *str, u32 *val)
{
if (!inet_pton(AF_INET, str, val))
return -1;
@@ -828,11 +828,11 @@ static int rxclass_get_val(char *str, unsigned char *p, u32 *flags,
break;
}
case OPT_IP4: {
- __be32 val;
+ u32 val;
err = rxclass_get_ipv4(str, &val);
if (err)
return -1;
- *(__be32 *)&p[opt->offset] = val;
+ *(__be32 *)&p[opt->offset] = htonl((u32)val);
if (opt->moffset >= 0)
*(__be32 *)&p[opt->moffset] = (__be32)mask;
break;
@@ -929,11 +929,11 @@ static int rxclass_get_mask(char *str, unsigned char *p,
break;
}
case OPT_IP4: {
- __be32 val;
+ u32 val;
err = rxclass_get_ipv4(str, &val);
if (err)
return -1;
- *(__be32 *)&p[opt->moffset] = ~val;
+ *(__be32 *)&p[opt->moffset] = ~htonl((u32)val);
break;
}
case OPT_MAC: {
--
1.7.1
^ permalink raw reply related
* Re: 3.1-rc1-git9: Reported regressions 2.6.39 -> 3.0
From: Paul E. McKenney @ 2011-08-15 15:37 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Maciej Rutecki, Florian Mickler,
Andrew Morton, Linus Torvalds, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <xuTC4jRtHbB.A.l4H.gMCSOB@chimera>
On Sun, Aug 14, 2011 at 09:02:27PM +0200, Rafael J. Wysocki wrote:
> [NOTE:
> We already have a bug entry for tracking regressions from 3.0:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=40982
>
> but there are no reports linked to it, mostly because Maciej is on vacation,
> but also because the frequency of reporting regressions has been low
> recently. So, if you're seeing a regression from 3.0, please let us know.]
>
> This message contains a list of some post-2.6.39 regressions introduced before
> 3.0, for which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
>
> If you know of any other unresolved post-2.6.39 regressions, please let us know
> either and we'll add them to the list. Also, please let us know if any
> of the entries below are invalid.
>
> Each entry from the list will be sent additionally in an automatic reply to
> this message with CCs to the people involved in reporting and handling the
> issue.
>
>
> Listed regressions statistics:
>
> Date Total Pending Unresolved
> ----------------------------------------
> 2011-08-14 63 22 19
>
>
> Unresolved regressions
> ----------------------
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40282
> Subject : IP forwarding regression since 3.0-rc6
> Submitter : Stephan Seitz <stse+lkml-S0d6l+6kcjrOGKtSYHEJQ9HuzzzSOjJt@public.gmane.org>
> Date : 2011-07-25 12:51 (21 days old)
> Message-ID : <20110725T141145.GA.2ae38.stse-S0d6l+6kcjrOGKtSYHEJQ9HuzzzSOjJt@public.gmane.org>
> References : http://marc.info/?l=linux-kernel&m=131159880004908&w=2
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40172
> Subject : lockdep trace from post 3.0.
> Submitter : Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Date : 2011-07-24 1:32 (22 days old)
> Message-ID : <20110724013257.GA6777-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> References : http://marc.info/?l=linux-kernel&m=131147120206819&w=2
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=40092
> Subject : RCU stall in linux-3.0.0
> Submitter : Philip Armstrong <phil-awZZuG094qgqdlJmJB21zg@public.gmane.org>
> Date : 2011-07-25 21:44 (21 days old)
This one was due the the CPU's idea of the current time getting way
out of sync (as in more than a minute's worth of disagreement, which is
pretty impressive when you think about it). So what happened is that
one CPU decided that the current grace period was a full minute old
immediately, and thus started screaming piteously. John Stultz provided
a configuration workaround, and he and Thomas Gleixner would be working
out the long-term fix.
Thanx, Paul
^ permalink raw reply
* [PATCH] net_sched: fix port mirror/redirect stats reporting
From: jamal @ 2011-08-15 15:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev
commit 6a51508a01671114c236602d071d4bff53422c60
Author: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Mon Aug 15 11:17:06 2011 -0400
[PATCH] net_sched: fix port mirror/redirect stats reporting
When a redirected or mirrored packet is dropped by the target
device we need to record statistics.
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index 961386e..d5ef6ec 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -196,8 +196,7 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
skb2->skb_iif = skb->dev->ifindex;
skb2->dev = dev;
- dev_queue_xmit(skb2);
- err = 0;
+ err = dev_queue_xmit(skb2);
out:
if (err) {
^ permalink raw reply related
* Re: [PATCH v12 3/6] flexcan: Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-15 15:25 UTC (permalink / raw)
To: Grant Likely
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, U Bhaskar-B22300,
Kumar Gala, socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
Marc Kleine-Budde, Scott Wood, PPC list, Wolfgang Grandegger
In-Reply-To: <CACxGe6vafc6mYyKCAO+HqkRPsZ3GmeVJnK+z8=BX_wQQMG4LmQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Aug 15, 2011 at 09:13:50AM -0600, Grant Likely wrote:
> On Mon, Aug 15, 2011 at 9:03 AM, Robin Holt <holt-sJ/iWh9BUns@public.gmane.org> wrote:
> > Grant,
> >
> > Earlier, you had asked for a more specific name for the compatible
> > property of the Freescale flexcan device. I still have not gotten a
> > more specific answer. Hopefully Marc can give you more details about
> > the flexcan implementations.
>
> If there is no ip core version, then just stick with the
> fsl,<soc>-flexcan name and drop "fsl,flexcan". Marketing may say
> flexcan is flexcan, but hardware engineers like to change things.
> Trying to be too generic in compatible values will just lead to
> problems in the future.
Thanks,
Robin
^ permalink raw reply
* Re: Fw: [Bug 39132] Starting with 3.0.0-rc6, masquerading seems to be broken.
From: Julian Anastasov @ 2011-08-15 15:27 UTC (permalink / raw)
To: David Hill; +Cc: Florian Mickler, netdev, David Miller, bugzilla-daemon
In-Reply-To: <8A188C9C23A54337A5A276BAE29DC6E0@delorimier>
Hello,
On Fri, 5 Aug 2011, David Hill wrote:
> Hello Julian,
>
> I'm not using TPROXY and I've used a blank firewall with only masquerading
> and reproduced the issue.
> Nothing is in NAT/mangle nor OUTPUT but the rules mentionned in the attached
> files to this bug.
>
> Francis Whittle (Comment #18) has the same issue.
>
> > Hello,
> >
> > On Thu, 4 Aug 2011, Florian Mickler wrote:
> >
> > > Can someone take a look at this regression?
> > >
> > > Begin forwarded message:
> > >
> > > Date: Thu, 28 Jul 2011 04:51:12 GMT
> > > From: bugzilla-daemon@bugzilla.kernel.org
> > > To: florian@mickler.org
> > > Subject: [Bug 39132] Starting with 3.0.0-rc6, masquerading seems to be
> > > broken.
> > >
> > >
> > > https://bugzilla.kernel.org/show_bug.cgi?id=39132
> >
> > So, problem points again to
> > "Fix ip_route_me_harder triggering ip_rt_bug" ? May be
> > David C. Hill or Florian can provide some information, eg. is
> > tproxy used, what NAT rules are used, any rules in OUTPUT
> > hooks (NAT/mangle) and which packets are dropped.
May be it is a sequence of two problems. I now
checked the tcpdump log from Francis Whittle. The
"seq 352:1792" packet at 18:44:29.235154 that is not
SNAT-ed is long, can it be some PMTU event that triggers
ICMP response to the internal host? Because I see changes
in MSS. May be rc5 triggers ICMP FRAG NEEDED while rc6
does not. It can happen because:
1. ICMP uses non-local iph->saddr when XFRM is compiled,
reverse lookup fails with ENOENT but fl4->saddr is
already damaged with the original daddr (non-local).
Fix is here: http://marc.info/?t=131118984300003&r=1&w=2
2. The patched ip_route_me_harder between 3.0-rc5 and
3.0-rc6 expects that sockets always provide local address.
This is wrong for some cases such as TCP (uses different
SOCK_RAW socket for some packets and can cause problem
for tproxy), RAW (can use spoofed sources) and now the
ICMP code that incorrectly provides non-local address.
Fix is here: http://marc.info/?t=131274411600001&r=1&w=2
I hope (any of) these two fixes should solve the
masquerading problems. If that is not true, tcpdump from rc5
would be helpful for comparison.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH v12 3/6] flexcan: Fix up fsl-flexcan device tree binding.
From: Grant Likely @ 2011-08-15 15:13 UTC (permalink / raw)
To: Robin Holt
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, U Bhaskar-B22300,
Kumar Gala, socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
Marc Kleine-Budde, Scott Wood, PPC list, Wolfgang Grandegger
In-Reply-To: <20110815150357.GM4926-sJ/iWh9BUns@public.gmane.org>
On Mon, Aug 15, 2011 at 9:03 AM, Robin Holt <holt-sJ/iWh9BUns@public.gmane.org> wrote:
> Grant,
>
> Earlier, you had asked for a more specific name for the compatible
> property of the Freescale flexcan device. I still have not gotten a
> more specific answer. Hopefully Marc can give you more details about
> the flexcan implementations.
If there is no ip core version, then just stick with the
fsl,<soc>-flexcan name and drop "fsl,flexcan". Marketing may say
flexcan is flexcan, but hardware engineers like to change things.
Trying to be too generic in compatible values will just lead to
problems in the future.
g.
^ permalink raw reply
* Re: [PATCH] bnx2x: suppress repeated error messages about Max BW
From: Michal Schmidt @ 2011-08-15 15:13 UTC (permalink / raw)
To: eilong; +Cc: netdev@vger.kernel.org, Dmitry Kravkov, Vladislav Zolotarov
In-Reply-To: <1313411585.31417.35.camel@lb-tlvb-eilong.il.broadcom.com>
On 08/15/2011 02:33 PM, Eilon Greenstein wrote:
> On Mon, 2011-08-15 at 04:59 -0700, Michal Schmidt wrote:
>> and bnx2x_init_vn_minmax() calls bnx2x_extract_max_cfg() on the given
>> VN, so it seems that the warning can be produced for a non-current VN.
>
> You are right, only one function (the PMF) will call this code for all
> functions. But I suspect that if you have zero values, you will have
> them for all VNs - is that the case?
A tester reported getting only these 4 messages with the patch applied:
[bnx2x_extract_max_cfg:1074(eth4)]Illegal configuration detected for Max
BW on vn 2 - using 100 instead
[bnx2x_extract_max_cfg:1074(eth5)]Illegal configuration detected for Max
BW on vn 2 - using 100 instead
[bnx2x_extract_max_cfg:1074(eth6)]Illegal configuration detected for Max
BW on vn 3 - using 100 instead
[bnx2x_extract_max_cfg:1074(eth7)]Illegal configuration detected for Max
BW on vn 3 - using 100 instead
This suggests that VNs 0 and 1 had non-zero Max BW configuration.
Michal
^ 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