From: Vishwanath Pai
Date: Wed, 29 Apr 2015 16:30:44 -0400
> Since the patch has been applied already - should I send a V2 with the
> suggested changes? Or submit a new patch that applies on top of the
> first patch?
You should always send me a relative patch in this situation.
--
To unsubscribe
On 04/29/2015 03:45 PM, Nikolay Aleksandrov wrote:
> On 04/29/2015 08:24 PM, Pai wrote:
>> This patch fixes a Kernel Panic in bonding driver debugfs file:
>> rlb_hash_table.
>>
>> $> modprobe bonding mode=6
>> $> cat /sys/kernel/debug/bonding/bond0/rlb_hash
On 04/29/2015 08:24 PM, Pai wrote:
> This patch fixes a Kernel Panic in bonding driver debugfs file:
> rlb_hash_table.
>
> $> modprobe bonding mode=6
> $> cat /sys/kernel/debug/bonding/bond0/rlb_hash_table
>
> This will crash the kernel. The struct alb_bond_info is
From: Andy Gospodarek
Date: Wed, 29 Apr 2015 14:51:07 -0400
> On Wed, Apr 29, 2015 at 02:24:23PM -0400, Pai wrote:
>> This patch fixes a Kernel Panic in bonding driver debugfs file:
>> rlb_hash_table.
>>
>> $> modprobe bonding mode=6
>> $> cat /sys/ke
On Wed, Apr 29, 2015 at 02:24:23PM -0400, Pai wrote:
> This patch fixes a Kernel Panic in bonding driver debugfs file:
> rlb_hash_table.
>
> $> modprobe bonding mode=6
> $> cat /sys/kernel/debug/bonding/bond0/rlb_hash_table
>
> This will crash the kernel. The struct a
This patch fixes a Kernel Panic in bonding driver debugfs file: rlb_hash_table.
$> modprobe bonding mode=6
$> cat /sys/kernel/debug/bonding/bond0/rlb_hash_table
This will crash the kernel. The struct alb_bond_info is initialized only when
the bonding interface is initialized (ip link set
From: Masanari Iida
Date: Tue, 9 Sep 2014 18:07:55 +0900
> This patch adds missing space between "interface" and "by"
> in bonding module parameter description.
>
> Signed-off-by: Masanari Iida
Applied, thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
This patch adds missing space between "interface" and "by"
in bonding module parameter description.
Signed-off-by: Masanari Iida
---
drivers/net/bonding/bond_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main
On Thu, 2013-04-18 at 15:09 -0400, David Miller wrote:
> Applied and queued up for -stable, but:
>
> > + sizeof(_l4), &_l4);
> >
>
>
From: Eric Dumazet
Date: Mon, 15 Apr 2013 20:03:24 -0700
> [PATCH] bonding: fix l23 and l34 load balancing in forwarding path
>
> Since commit 6b923cb7188d46 (bonding: support for IPv6 transmit hashing)
> bonding doesn't properly hash traffic in forwarding setups.
>
> Vitaly V. Bursov diagnosed
From: Eric Dumazet
Date: Tue, 16 Apr 2013 07:25:17 -0700
> On Tue, 2013-04-16 at 06:51 -0700, Eric Dumazet wrote:
>
>> Perfect, thanks a lot for all this !
>>
>> Tested-by: Vitaly V. Bursov
>>
>>
>
> By the way, we probably should use skb_flow_dissect() to get proper
> hashing for tunnels u
On Tue, 2013-04-16 at 06:51 -0700, Eric Dumazet wrote:
> Perfect, thanks a lot for all this !
>
> Tested-by: Vitaly V. Bursov
>
>
By the way, we probably should use skb_flow_dissect() to get proper
hashing for tunnels users.
--
To unsubscribe from this list: send the line "unsubscribe linu
On Tue, 2013-04-16 at 12:01 +0300, Vitaly V. Bursov wrote:
> Testing under real load for almost 2 hours now, works as expected.
> xmit_hash_policy=layer3+4
>
> I made a few simple test with layer2+3 policy too, looks OK.
>
> Thanks!
Perfect, thanks a lot for all this !
Tested-by: Vitaly V. Bur
16.04.2013 06:03, Eric Dumazet пишет:
From: Eric Dumazet
On Mon, 2013-04-15 at 17:37 -0700, Eric Dumazet wrote:
On Mon, 2013-04-15 at 16:57 +0300, Vitaly V. Bursov wrote:
Hello,
I have a bonding device (mode=802.3ad xmit_hash_policy=layer2+3 miimon=300) and
for kernels <3.7 forwarded IPv4 tr
From: Eric Dumazet
On Mon, 2013-04-15 at 17:37 -0700, Eric Dumazet wrote:
> On Mon, 2013-04-15 at 16:57 +0300, Vitaly V. Bursov wrote:
> > Hello,
> >
> > I have a bonding device (mode=802.3ad xmit_hash_policy=layer2+3 miimon=300)
> > and
> > for kernels <3.7 forwarded IPv4 traffic distributed f
On Mon, 2013-04-15 at 16:57 +0300, Vitaly V. Bursov wrote:
> Hello,
>
> I have a bonding device (mode=802.3ad xmit_hash_policy=layer2+3 miimon=300)
> and
> for kernels <3.7 forwarded IPv4 traffic distributed fine across multiple
> physical
> links. Ethernet cards are Intel 82576 with igb driver
Hello,
I have a bonding device (mode=802.3ad xmit_hash_policy=layer2+3 miimon=300) and
for kernels <3.7 forwarded IPv4 traffic distributed fine across multiple
physical
links. Ethernet cards are Intel 82576 with igb driver (various versions).
3.7 and 3.8 kernels tend to fully utilize only one l
On Thu, Mar 7, 2013 at 10:50 AM, Michael Wang
wrote:
> On 03/07/2013 04:50 PM, Linda Walsh wrote:
>>
>> I am *not* seeing the bug in 3.8.2 with the 2nd patch applied (in
>> addition to the first)...
>
> So that means bond lock is the reason, nice, but this is really not a
> good fix if we just unl
On 03/07/2013 04:50 PM, Linda Walsh wrote:
>
> I am *not* seeing the bug in 3.8.2 with the 2nd patch applied (in
> addition to the first)...
So that means bond lock is the reason, nice, but this is really not a
good fix if we just unlock it...
The better way is to move the cycle wait logical out
On 03/07/2013 03:05 PM, Linda Walsh wrote:
[snip]
> [ 24.820010] BUG: scheduling while atomic: kworker/u:2/109/0x0002
> [ 24.826415] 4 locks held by kworker/u:2/109:
> [ 24.826425] #0: ((bond_dev->name)){..}, at:
> [] process_one_work+0x13d/0x5d0
> [ 24.826428] #1: ((&(&bond->mi
.
> [2.134590] ipmi_si: probing via SMBIOS
> [2.138537] ipmi_si: SMBIOS: io 0xca8 regsize 1 spacing 4 irq 0
> [2.144571] ipmi_si: Adding SMBIOS-specified kcs state machine
> [2.150581] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o
> address 0xca8, slave address
to 255 on gpio_ich
[2.543005] Loading iSCSI transport class v2.0-870.
[2.548103] megasas: 06.504.01.00-rc1 Mon. Oct. 1 17:00:00 PDT 2012
[2.554547] megasas: 0x1000:0x0079:0x1000:0x9275: bus 5:slot 0:func 0
[2.561326] megasas: FW now in Ready state
...
[ 2.844408] scsi 0:0:29:0: Di
On 03/02/2013 01:21 PM, Linda Walsh wrote:
>
>
>
>
> Linda Walsh wrote:
>>
>>
>> This patch is not in the latest kernel. I don't know if it is the
>> 'best' way, but it does stop BUG error messages.
> ---
> Update -- it *used* to stop the messages in 3.6.7.
>
> It no longer stops the messages
Linda Walsh wrote:
>
>
> This patch is not in the latest kernel. I don't know if it is the
> 'best' way, but it does stop BUG error messages.
---
Update -- it *used* to stop the messages in 3.6.7.
It no longer stops the messages in 3.8.1 -- (and isn't present by
default -- tried
adding the un
On Fri, 2013-03-01 at 00:15 -0800, Linda Walsh wrote:
> Just installed 3.8.1
>
> Thought this had been fixed? Note it causes the kernel to
> show up as tainted after the 1st...
>
CC netdev & Jay Vosburgh & Jeff Kirsher
>
>
> As the system was coming up and initializing the bond0 driver:
Just installed 3.8.1
Thought this had been fixed? Note it causes the kernel to
show up as tainted after the 1st...
As the system was coming up and initializing the bond0 driver:
[ 19.847743] ixgbe :06:00.0: registered PHC device on eth_s2_0
[ 20.258245] BUG: scheduling while ato
3.5.7.3 -stable review patch. If anyone has any objections, please let me know.
--
From: Sarveshwar Bandi
commit 0e376bd0b791ac6ac6bdb051492df0769c840848 upstream.
Patch sets the lowest gso_max_size and gso_max_segs values of the slave devices
during enslave and detach.
Sign
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Sarveshwar Bandi
[ Upstream commit 0e376bd0b791ac6ac6bdb051492df0769c840848 ]
Patch sets the lowest gso_max_size and gso_max_segs values of the slave devices
during enslave and detach.
Signe
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Sarveshwar Bandi
[ Upstream commit 0e376bd0b791ac6ac6bdb051492df0769c840848 ]
Patch sets the lowest gso_max_size and gso_max_segs values of the slave devices
during enslave and detach.
Signe
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Sarveshwar Bandi
[ Upstream commit 0e376bd0b791ac6ac6bdb051492df0769c840848 ]
Patch sets the lowest gso_max_size and gso_max_segs values of the slave devices
during enslave and detach.
Signed
Thu, Oct 11, 2012 at 04:28:40PM CEST, jstan...@rmrf.net wrote:
>Since commit cc0e40700656b09d93b062ef6c818aa45429d09a, there is a
>problem if you have the 8021q module loaded and you then attempt to
>enslave a VLAN challenged interface. This is because VLAN 0 is
>automatically added to the bond, an
On Thu, Oct 11, 2012 at 10:28 AM, Jon Stanley wrote:
> This specifically affects IPoIB interfaces in a bond if you do a
> down/up cycle on the bond post-boot (during boot, the bonding module
> is loaded prior to the 8021q module, so everything is fine).
I hate replying to myself, but I've just b
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
diff --git a/MAINTAINERS b/MAINTAINERS
index 3d198df..a21ccf1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1082,6 +1082,8 @@ M:[EMAIL PROTECTED]
L: [EMAIL PROTECTED]
W: http://sourceforge.net/p
Le Thursday 26 April 2007 22:44:59 Jay Vosburgh, vous avez écrit :
> Chris Snook <[EMAIL PROTECTED]> wrote:
> >Vincent ETIENNE wrote:
> >> Hi,
> >>
> >> Summary :
> >>Got this trace when one network interface come down or up in a 2
> >>interfaces bonding. So far, system seems to surviv
Le Sunday 29 April 2007 13:18:31 Jiri Kosina, vous avez écrit :
>
> Hi Vincent,
Hi Jiri,
>
> yes, the device is messed up, but it shouldn't have any consequences for
> you - the HID driver is able to correctly handle that, so as soon as we
> don't need to add any extra quirks for such dev
On Sat, 28 Apr 2007, Vincent ETIENNE wrote:
> > No, it isn't a problem in the USB core. The device itself is messed up;
> > it really does report idVendor and idProduct both equal to 0.
> So is it just a scary trace but without consequence that i could ignored
> ? May i ask you what is the devic
Le Saturday 28 April 2007 00:32:37 Andrew Morton, vous avez écrit :
> On Fri, 27 Apr 2007 22:05:28 +0200
>
> because we thought we'd fixed the rtnl_lock() problems in 2.6.21-rc7-mm2.
> Are you sure that log is from 2.6.21-rc7-mm2?
Yes. I have retested it another time ( for adding the small usb d
Le Saturday 28 April 2007 21:50:30 Alan Stern, vous avez écrit :
> No, it isn't a problem in the USB core. The device itself is messed up;
> it really does report idVendor and idProduct both equal to 0.
>
> Jiri, don't worry about all those other devices in the listing that also
> have idVendor an
On Sat, 28 Apr 2007, Jiri Kosina wrote:
> On Sat, 28 Apr 2007, Vincent ETIENNE wrote:
>
> > > I now don't immediately see how this could happen - the vendor ID
> > > seems to be propagated properly from hid_probe() (nothing has been
> > > changed in this codepath), so this would mean that hid_p
On Sat, 28 Apr 2007, Vincent ETIENNE wrote:
> > I now don't immediately see how this could happen - the vendor ID
> > seems to be propagated properly from hid_probe() (nothing has been
> > changed in this codepath), so this would mean that hid_probe() has
> > been passed usb_interface for which
On Sat, 28 Apr 2007, Vincent ETIENNE wrote:
With your patch it seems like idVendor passed is 0. You could see it there ;
http://mail1.vetienne.net/linux/dmesg.2.6.21-rc7-mm2+patch-usbhid
I could confirm that the keyboard is working ( yesterday i was just behind the
box due to test on the netwo
Le Saturday 28 April 2007 00:42:45 Jiri Kosina, vous avez écrit :
> On Fri, 27 Apr 2007, Greg KH wrote:
> > > BUG: at drivers/hid/usbhid/hid-quirks.c:480 usbhid_exists_dquirk()
>
> [ .. stacktraces stripped .. ]
>
> > Jiri, any thoughts about this? This looks like it comes from your tree
> > as 2
Hi Jiri,
On Sat, 28 Apr 2007, Jiri Kosina wrote:
Paul, do you have any idea? In fact, what was your reason for putting this
WARN_ON() there?
The static quirk list uses idVendor == 0 to mark the end of
hid_blacklist[], so we don't expect any device to have idVendor == 0. If
a device is corr
On Sat, 28 Apr 2007, Jiri Kosina wrote:
> This BUG (it's in fact a warning) is this one:
>WARN_ON(idVendor == 0);
> I now don't immediately see how this could happen - the vendor ID seems
> to be propagated properly from hid_probe() (nothing has been changed in
> this codepath), so this
On Fri, 27 Apr 2007, Greg KH wrote:
> > BUG: at drivers/hid/usbhid/hid-quirks.c:480 usbhid_exists_dquirk()
[ .. stacktraces stripped .. ]
> Jiri, any thoughts about this? This looks like it comes from your tree
> as 2.6.21 doesn't have the drivers/hid/usbhid/ directory...
Paul (author of the co
On Fri, Apr 27, 2007 at 11:25:46AM +0200, VE (HOME) wrote:
> Andrew Morton wrote:
> > On Thu, 26 Apr 2007 20:58:32 +0200 Vincent ETIENNE <[EMAIL PROTECTED]>
> > wrote:
> >
> >
> > This was due to locking bustage in the net tree. It should be fixed
> > in 2.6.21-rc7-mm2.
>
> I have tried this ve
On Fri, 27 Apr 2007 11:25:46 +0200 "VE \(HOME\)" <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Thu, 26 Apr 2007 20:58:32 +0200 Vincent ETIENNE <[EMAIL PROTECTED]>
> > wrote:
> >
> >
> > This was due to locking bustage in the net tree. It should be fixed
> > in 2.6.21-rc7-mm2.
>
> I ha
Andrew Morton wrote:
On Thu, 26 Apr 2007 20:58:32 +0200 Vincent ETIENNE <[EMAIL PROTECTED]>
wrote:
This was due to locking bustage in the net tree. It should be fixed
in 2.6.21-rc7-mm2.
I have tried this version. Same problem ( see
http://mail1.vetienne.net/linux/dmesg-2.6.21-rc7-mm2.log )
On Thu, 26 Apr 2007 20:58:32 +0200 Vincent ETIENNE <[EMAIL PROTECTED]> wrote:
> Apr 26 11:09:34 jupiter2 RTNL: assertion failed at
> net/ipv4/devinet.c
> (1055) Apr 26 11:09:34 jupiter2
> Apr 26 11:09:34 jupiter2 Call Trace:
> Apr 26 11:09:3
Le Thursday 26 April 2007 22:44:59 Jay Vosburgh, vous avez écrit :
> Chris Snook <[EMAIL PROTECTED]> wrote:
> >Vincent ETIENNE wrote:
> >> Hi,
> >>
> >> Summary :
> >>Got this trace when one network interface come down or up in a 2
> >>interfaces bonding. So far, system seems to surviv
Chris Snook <[EMAIL PROTECTED]> wrote:
>Vincent ETIENNE wrote:
>> Hi,
>>
>> Summary :
>> Got this trace when one network interface come down or up in a 2
>> interfaces bonding. So far, system seems to survive to this problem
>> and works fine.
>
>I'm investigating a similar/p
Vincent ETIENNE wrote:
Hi,
Summary :
Got this trace when one network interface come down or up in a 2
interfaces bonding. So far, system seems to survive to this problem
and works fine.
I'm investigating a similar/possibly identical bug. Do you experience
packe
Hi,
Summary :
Got this trace when one network interface come down or up in a 2
interfaces bonding. So far, system seems to survive to this problem
and works fine.
Full description
During testing of bonding of 2 interfaces, i have seen this from
tim
I have been working on a driver similar to the bonding driver and have
come across a bug in the bonding driver code. When the bonding driver
enslaves a device, it modifies the slave's multicast list to be the
master's multicast list. Later, after the master is downed, the kernel
gets
A few bugs still show up in the 2.4.x series with the bonding
(drivers/net/bonding.c / bonding.0) driver. Ive tried all the below
situations in both 2.4.0 and 2.4.1 (both clean/final versions), and on
redhat's default 2.2.16enterprise kernel. the 2.2.16 kernel doesnt have
any of the bugs described
hi,
here's a patch to make the channel bonding driver not try to
transmit on links that are down. there was a patch made to
2.3.x to do this via checking netif_carrier_ok(). this adds
the functionality to the 2.2.x driver code.
please cc: me in response.
brien
--- linux-2.2.17/driver
> Donald's email server has been down for few days, my
> machine was not able to send him e-mail.
ok.
> Regarding your last patch -- it does not include the
> documentation update (ifenslave.c compile problem is
> solved).
yes, it's just what I've discovered yesterday evening.
I'll attach the co
and UP kernels tested).
Machine 3: IBM Thinkpad laptop with one NIC.
Switches: BayStack Switches, 2 trunks were defined (trunks were defined
between ports that belonged to different modules).
Software:
2.2.18-pre15 + updated bonding driver + E820 memory detection + software
raid + nfs v3 serve
willy tarreau wrote:
>
> Hello Thomas,
>
> I've modified the slaves lists as you suggested to me.
> The more I tried to optimize the code, the more it looked like
> 2.4's, so it seems the last one is already optimal. There's no
> slave_queue anymore, and the transmit path in bond_xmit_roundrobin
Hello Thomas,
I've modified the slaves lists as you suggested to me.
The more I
tried to optimize the code, the more it looked like
2.4's, so it
seems the last one is already optimal. There's no
slave_queue
anymore, and the transmit path in bond_xmit_roundrobin
is far
faster.
I have also impleme
willy tarreau wrote:
>
> > rename bond_xmit to bond_xmit_roundrobin, so
> > bond_xmit_xor can be implemented, and used if
> > desired. bond_xmit_xor is what cisco
> > etherchannel/sun trunking really uses, not round
> > robin.
>
> how does their xor method work ? do you know about an
> RFC stat
> rename bond_xmit to bond_xmit_roundrobin, so
> bond_xmit_xor can be implemented, and used if
> desired. bond_xmit_xor is what cisco
> etherchannel/sun trunking really uses, not round
> robin.
how does their xor method work ? do you know about an
RFC stating about this, that I could read ? I'm
nnel/sun trunking really uses, not round robin.
Remove the variable counters from the xmit loop.. Make it more like:
(from the 2.4 bonding driver)
start = slave = bond
do {
if (slave == bond)
continue;
if (blah..blah)
do xmit()
re
Hello Thomas !
I've slightly enhanced the bonding code :
- MII link checking with automatic slave enabling/disabling :
Now the bond interface monitors all its MII-compliant slaves
and disables the ones which have a dead link, and enables those
which have a good one. The link check t
>
It's funny, yesterday I got my hands on mii-diag as well. I reduced it
to just a few lines of code that check the link status and was going to
daemonize it today. I cc'ed Thomas Davis on this. I was thinking though
more in lines of not executing the scripts, but taking the code from
On Sun, 24 Sep 2000, Constantine Gavrilov wrote:
> Hi, I'd like to use channel bonding driver for high availability.
>
> Currenly the bonding driver does not detect a dead slave link. When a
> slave link dies, it causes lots of network retransmits and the effective
> speed o
Hello Constantine !
I also needed to be able to detect a failed link and to remove the
guilty interface from a trunk between a linux box and an Alteon A708
switch. So I've just written a little patch against 2.2.17 to implement
the BOND_RELEASE ioctl (Thomas Davis cc'd for this). I also quickly
m
Thomas Davis wrote:
> Link status is not used at all in v2.2 (and would mean a rewrite of
> drivers to get it)
>
> Link status is used in v2.4. Not all drivers support link status. In
> fact, I don't know of any that do - but it's possible now to do it.
>
> Simply taking down the interface s
Constantine Gavrilov wrote:
>
> 1) How can I check for the link status from the user space?
> 2) Could enslaved interface be released without bringing the master
> interface down? If yes, how? Could we have ifunslave?
>
Link status is not used at all in v2.2 (and would mean a rewrite of
driver
Hi, I'd like to use channel bonding driver for high availability.
Currenly the bonding driver does not detect a dead slave link. When a
slave link dies, it causes lots of network retransmits and the effective
speed of the bonding device drops to almost zero. This has been verified
in th
70 matches
Mail list logo
