[PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1

[PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1

[Vincent ETIENNE]

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
	time to time in my log file ( the problem doesn't arrive each
	time but one in 3 or 4 try ). 

	SYSTEM :	 2 NIC card bond on interface bond0 : 
				intel PRO/1000 (e1000 )
				Broadcomm ( tg3 )
	I have also try a 2.6.20 and 2.6.19 vanilla kernel ( identical problem but in 
	onecase the system doesn't survive : that the reason the problem catch my 
	attention )
 
	Keywords	; network, bonding
 
	Version : Linux version 2.6.21-rc6-mm1 (root@jupiter2) (gcc version 4.1.1
	(Gentoo 4.1.1-r3)) #3 SMP Thu Apr 26 08:45:06 CEST 2007
 
	Output of /var/log/messages
 
		Apr 26 11:09:34 jupiter2 e1000: eth0: e1000_watchdog_task: NIC Link
		is Down Apr 26 11:09:34 jupiter2 bonding: bond0: link status
		definitely down for interface eth0, disabling it
		Apr 26 11:09:34 jupiter2 bonding: bond0: making interface eth1 the new
		active one.
		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:34 jupiter2 <IRQ>  [<ffffffff8049b49e>] 
inetdev_event+0x48/0x283
		Apr 26 11:09:34 jupiter2 [<ffffffff804c8731>] _spin_lock_bh+0x9/0x19
		Apr 26 11:09:34 jupiter2 [<ffffffff80473df1>] rt_run_flush+0x7e/0xaf
		Apr 26 11:09:34 jupiter2 [<ffffffff8022bdd0>] notifier_call_chain+0x29/0x56 
		Apr 26 11:09:34 jupiter2 [<ffffffff804560cc>] dev_set_mac_address+0x53/0x59 			
		Apr 26 11:09:34 jupiter2 [<ffffffff88006d8d>] 
bonding:alb_set_slave_mac_addr+0x41/0x6c
		Apr 26 11:09:34 jupiter2 [<ffffffff88007215>] 
bonding:alb_swap_mac_addr+0x91/0x165
		Apr 26 11:09:34 jupiter2 [<ffffffff88002029>] 
bonding:bond_change_active_slave+0x227/0x382
		Apr 26 11:09:34 jupiter2 [<ffffffff880024c9>]
		bonding:bond_select_active_slave+0xb7/0xe5
		Apr 26 11:09:34 jupiter2 [<ffffffff88004182>] 
bonding:bond_mii_monitor+0x3cd/0x41e
		Apr 26 11:09:34 jupiter2 [<ffffffff88003db5>] 
bonding:bond_mii_monitor+0x0/0x41e
		Apr 26 11:09:34 jupiter2 [<ffffffff80228714>]
 run_timer_softirq+0x130/0x19f
		Apr 26 11:09:34 jupiter2[<ffffffff8022618a>] __do_softirq+0x55/0xc4 
		Apr 26 11:09:34 jupiter2 [<ffffffff8020a5ac>] call_softirq+0x1c/0x28
		Apr 26 11:09:34 jupiter2 [<ffffffff8020bead>] do_softirq+0x2c/0x7d
		Apr 26 11:09:34 jupiter2 [<ffffffff80213b2a>] 
smp_apic_timer_interrupt+0x49/0x5f
		 Apr 26 11:09:34 jupiter2 [<ffffffff802088a3>] mwait_idle+0x0/0x45
		Apr 26 11:09:34 jupiter2 [<ffffffff8020a056>] apic_timer_interrupt+0x66/0x70
		 Apr 26 11:09:34 jupiter2 <EOI>  [<ffffffff802088e5>] mwait_idle+0x42/0x45 
		Apr 26 11:09:34 jupiter2 [<ffffffff8020883f>] cpu_idle+0x51/0x70 
		Apr 26 11:09:34 jupiter2 [<ffffffff806369bd>] start_kernel+0x242/0x24e
		Apr 26 11:09:34 jupiter2 [<ffffffff80636146>] _sinittext+0x146/0x14a
 
 
other  informations (ver_linux, lspci, ...  ) available at 
http://mail1.vetienne.net/linux

I'm a bit worried by the message so any help will be greatly appreciated

	Vincent

Re: [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1

[Chris Snook]

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 
packet loss or throughput stalls, beyond just the loss of the interface 
that went down, when this happens?

	-- Chris

>  Full description
>  
> 	During testing of bonding of 2 interfaces, i have seen this from
> 	time to time in my log file ( the problem doesn't arrive each
> 	time but one in 3 or 4 try ). 
> 
> 	SYSTEM :	 2 NIC card bond on interface bond0 : 
> 				intel PRO/1000 (e1000 )
> 				Broadcomm ( tg3 )
> 	I have also try a 2.6.20 and 2.6.19 vanilla kernel ( identical problem but in 
> 	onecase the system doesn't survive : that the reason the problem catch my 
> 	attention )
>  
> 	Keywords	; network, bonding
>  
> 	Version : Linux version 2.6.21-rc6-mm1 (root@jupiter2) (gcc version 4.1.1
> 	(Gentoo 4.1.1-r3)) #3 SMP Thu Apr 26 08:45:06 CEST 2007
>  
> 	Output of /var/log/messages
>  
> 		Apr 26 11:09:34 jupiter2 e1000: eth0: e1000_watchdog_task: NIC Link
> 		is Down Apr 26 11:09:34 jupiter2 bonding: bond0: link status
> 		definitely down for interface eth0, disabling it
> 		Apr 26 11:09:34 jupiter2 bonding: bond0: making interface eth1 the new
> 		active one.
> 		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:34 jupiter2 <IRQ>  [<ffffffff8049b49e>] 
> inetdev_event+0x48/0x283
> 		Apr 26 11:09:34 jupiter2 [<ffffffff804c8731>] _spin_lock_bh+0x9/0x19
> 		Apr 26 11:09:34 jupiter2 [<ffffffff80473df1>] rt_run_flush+0x7e/0xaf
> 		Apr 26 11:09:34 jupiter2 [<ffffffff8022bdd0>] notifier_call_chain+0x29/0x56 
> 		Apr 26 11:09:34 jupiter2 [<ffffffff804560cc>] dev_set_mac_address+0x53/0x59 			
> 		Apr 26 11:09:34 jupiter2 [<ffffffff88006d8d>] 
> bonding:alb_set_slave_mac_addr+0x41/0x6c
> 		Apr 26 11:09:34 jupiter2 [<ffffffff88007215>] 
> bonding:alb_swap_mac_addr+0x91/0x165
> 		Apr 26 11:09:34 jupiter2 [<ffffffff88002029>] 
> bonding:bond_change_active_slave+0x227/0x382
> 		Apr 26 11:09:34 jupiter2 [<ffffffff880024c9>]
> 		bonding:bond_select_active_slave+0xb7/0xe5
> 		Apr 26 11:09:34 jupiter2 [<ffffffff88004182>] 
> bonding:bond_mii_monitor+0x3cd/0x41e
> 		Apr 26 11:09:34 jupiter2 [<ffffffff88003db5>] 
> bonding:bond_mii_monitor+0x0/0x41e
> 		Apr 26 11:09:34 jupiter2 [<ffffffff80228714>]
>  run_timer_softirq+0x130/0x19f
> 		Apr 26 11:09:34 jupiter2[<ffffffff8022618a>] __do_softirq+0x55/0xc4 
> 		Apr 26 11:09:34 jupiter2 [<ffffffff8020a5ac>] call_softirq+0x1c/0x28
> 		Apr 26 11:09:34 jupiter2 [<ffffffff8020bead>] do_softirq+0x2c/0x7d
> 		Apr 26 11:09:34 jupiter2 [<ffffffff80213b2a>] 
> smp_apic_timer_interrupt+0x49/0x5f
> 		 Apr 26 11:09:34 jupiter2 [<ffffffff802088a3>] mwait_idle+0x0/0x45
> 		Apr 26 11:09:34 jupiter2 [<ffffffff8020a056>] apic_timer_interrupt+0x66/0x70
> 		 Apr 26 11:09:34 jupiter2 <EOI>  [<ffffffff802088e5>] mwait_idle+0x42/0x45 
> 		Apr 26 11:09:34 jupiter2 [<ffffffff8020883f>] cpu_idle+0x51/0x70 
> 		Apr 26 11:09:34 jupiter2 [<ffffffff806369bd>] start_kernel+0x242/0x24e
> 		Apr 26 11:09:34 jupiter2 [<ffffffff80636146>] _sinittext+0x146/0x14a
>  
>  
> other  informations (ver_linux, lspci, ...  ) available at 
> http://mail1.vetienne.net/linux
> 
> I'm a bit worried by the message so any help will be greatly appreciated
> 
> 	Vincent

Re: [Bonding-devel] [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1

[Jay Vosburgh]

Chris Snook <csnook@redhat.com> 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/possibly identical bug.  Do you experience 
>packet loss or throughput stalls, beyond just the loss of the interface 
>that went down, when this happens?

	This problem looks to be one of the known locking issues with
bonding.

	Andy Gospodarek <andy@greyhouse.net> and I have been working
offline on the locking issues in bonding over the last several weeks.
At the moment, we have a generally stable (but ugly with debug fluff and
other yuckies) patch that seems to resolve at least the majority of the
various issues.  I'm thinking to clean it up for general posting early
next week, and address additional problems from there (since it's
hopefully at least a big step forward).

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

Re: [Bonding-devel] [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1

[Vincent ETIENNE]

Le Thursday 26 April 2007 22:44:59 Jay Vosburgh, vous avez écrit :
> Chris Snook <csnook@redhat.com> 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/possibly identical bug.  Do you experience
> >packet loss or throughput stalls, beyond just the loss of the interface
> >that went down, when this happens?
>
> 	This problem looks to be one of the known locking issues with
> bonding.
>
> 	Andy Gospodarek <andy@greyhouse.net> and I have been working
> offline on the locking issues in bonding over the last several weeks.
> At the moment, we have a generally stable (but ugly with debug fluff and
> other yuckies) patch that seems to resolve at least the majority of the
> various issues.  I'm thinking to clean it up for general posting early
> next week, and address additional problems from there (since it's
> hopefully at least a big step forward).
>
> 	-J
>
> ---
> 	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Will be more than happy to test it and report the result with the new patch.

Thanks for your work,

Re: [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1

[Andrew Morton]

On Thu, 26 Apr 2007 20:58:32 +0200 Vincent ETIENNE <ve@vetienne.net> 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:34 jupiter2 <IRQ>  [<ffffffff8049b49e>] 
> inetdev_event+0x48/0x283
> 		Apr 26 11:09:34 jupiter2 [<ffffffff804c8731>] _spin_lock_bh+0x9/0x19
> 		Apr 26 11:09:34 jupiter2 [<ffffffff80473df1>] rt_run_flush+0x7e/0xaf
> 		Apr 26 11:09:34 jupiter2 [<ffffffff8022bdd0>] notifier_call_chain+0x29/0x56 
> 		Apr 26 11:09:34 jupiter2 [<ffffffff804560cc>] dev_set_mac_address+0x53/0x59 			
> 		Apr 26 11:09:34 jupiter2 [<ffffffff88006d8d>] 
> bo

This was due to locking bustage in the net tree.  It should be fixed in 2.6.21-rc7-mm2.

Re: [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1

[VE (HOME)]

Andrew Morton wrote:
> On Thu, 26 Apr 2007 20:58:32 +0200 Vincent ETIENNE <ve@vetienne.net>
> 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 )
But also a new problem with USB keyboard/mouse

BUG: at drivers/hid/usbhid/hid-quirks.c:480 usbhid_exists_dquirk()

Call Trace:
[<ffffffff8044bbcb>] usbhid_lookup_quirk+0x63/0xea
[<ffffffff8044ab12>] hid_probe+0x4d/0xbad
[<ffffffff8021d7cd>] default_wake_function+0x0/0xe
[<ffffffff8029d0b6>] sysfs_new_dirent+0x79/0xaa
[<ffffffff80403411>] usb_match_one_id+0x26/0x82
[<ffffffff80403fe6>] usb_probe_interface+0x7d/0xa5
[<ffffffff80391cb9>] driver_probe_device+0xf6/0x17f
[<ffffffff80391de4>] __driver_attach+0x0/0x93
[<ffffffff80391e3e>] __driver_attach+0x5a/0x93
[<ffffffff8039110c>] bus_for_each_dev+0x43/0x6e
[<ffffffff80391433>] bus_add_driver+0x7b/0x19d
[<ffffffff80403b06>] usb_register_driver+0x7e/0xe1
[<ffffffff8064d2d3>] hid_init+0x28/0x4e
[<ffffffff8063460b>] kernel_init+0x162/0x2d2
[<ffffffff8020a338>] child_rip+0xa/0x12
[<ffffffff80343d5c>] acpi_ds_init_one_object+0x0/0x7c
[<ffffffff806344a9>] kernel_init+0x0/0x2d2
[<ffffffff8020a32e>] child_rip+0x0/0x12

input: ServerEngines SE USB Device as 
/devices/pci0000:00/0000:00:1d.2/usb4/4-2/4-2:1.0/input/input2
input: USB HID v1.11 Keyboard [ServerEngines SE USB Device] on 
usb-0000:00:1d.2-2
BUG: at drivers/hid/usbhid/hid-quirks.c:480 usbhid_exists_dquirk()

Call Trace:
[<ffffffff8044bbcb>] usbhid_lookup_quirk+0x63/0xea
[<ffffffff8044ab12>] hid_probe+0x4d/0xbad
[<ffffffff8029d0b6>] sysfs_new_dirent+0x79/0xaa
[<ffffffff80403411>] usb_match_one_id+0x26/0x82
[<ffffffff80403fe6>] usb_probe_interface+0x7d/0xa5
[<ffffffff80391cb9>] driver_probe_device+0xf6/0x17f
[<ffffffff80391de4>] __driver_attach+0x0/0x93
[<ffffffff80391e3e>] __driver_attach+0x5a/0x93
[<ffffffff8039110c>] bus_for_each_dev+0x43/0x6e
[<ffffffff80391433>] bus_add_driver+0x7b/0x19d
[<ffffffff80403b06>] usb_register_driver+0x7e/0xe1
[<ffffffff8064d2d3>] hid_init+0x28/0x4e
[<ffffffff8063460b>] kernel_init+0x162/0x2d2
[<ffffffff8020a338>] child_rip+0xa/0x12
[<ffffffff80343d5c>] acpi_ds_init_one_object+0x0/0x7c
[<ffffffff806344a9>] kernel_init+0x0/0x2d2
[<ffffffff8020a32e>] child_rip+0x0/0x12


And also a strange problem : dhcp server and dns server was started before 
bond0 was completly up ( eth0 and eth1 was declared down at this time and 
up a few times later : was not the case with later 2.6.21-rc6-mm1 )

Vincent 

Re: [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1

[Andrew Morton]

On Fri, 27 Apr 2007 11:25:46 +0200 "VE \(HOME\)" <ve@vetienne.net> wrote:

> Andrew Morton wrote:
> > On Thu, 26 Apr 2007 20:58:32 +0200 Vincent ETIENNE <ve@vetienne.net>
> > 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 )

That file has disappeared.

> But also a new problem with USB keyboard/mouse
> 

USB problem - let's handle that separately.

> 
> And also a strange problem : dhcp server and dns server was started before 
> bond0 was completly up ( eth0 and eth1 was declared down at this time and 
> up a few times later : was not the case with later 2.6.21-rc6-mm1 )
> 

USB HID bug (was [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1)

[Greg KH]

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 <ve@vetienne.net>
> > 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 )
>  But also a new problem with USB keyboard/mouse
> 
>  BUG: at drivers/hid/usbhid/hid-quirks.c:480 usbhid_exists_dquirk()
> 
>  Call Trace:
>  [<ffffffff8044bbcb>] usbhid_lookup_quirk+0x63/0xea
>  [<ffffffff8044ab12>] hid_probe+0x4d/0xbad
>  [<ffffffff8021d7cd>] default_wake_function+0x0/0xe
>  [<ffffffff8029d0b6>] sysfs_new_dirent+0x79/0xaa
>  [<ffffffff80403411>] usb_match_one_id+0x26/0x82
>  [<ffffffff80403fe6>] usb_probe_interface+0x7d/0xa5
>  [<ffffffff80391cb9>] driver_probe_device+0xf6/0x17f
>  [<ffffffff80391de4>] __driver_attach+0x0/0x93
>  [<ffffffff80391e3e>] __driver_attach+0x5a/0x93
>  [<ffffffff8039110c>] bus_for_each_dev+0x43/0x6e
>  [<ffffffff80391433>] bus_add_driver+0x7b/0x19d
>  [<ffffffff80403b06>] usb_register_driver+0x7e/0xe1
>  [<ffffffff8064d2d3>] hid_init+0x28/0x4e
>  [<ffffffff8063460b>] kernel_init+0x162/0x2d2
>  [<ffffffff8020a338>] child_rip+0xa/0x12
>  [<ffffffff80343d5c>] acpi_ds_init_one_object+0x0/0x7c
>  [<ffffffff806344a9>] kernel_init+0x0/0x2d2
>  [<ffffffff8020a32e>] child_rip+0x0/0x12
> 
>  input: ServerEngines SE USB Device as 
>  /devices/pci0000:00/0000:00:1d.2/usb4/4-2/4-2:1.0/input/input2
>  input: USB HID v1.11 Keyboard [ServerEngines SE USB Device] on 
>  usb-0000:00:1d.2-2
>  BUG: at drivers/hid/usbhid/hid-quirks.c:480 usbhid_exists_dquirk()
> 
>  Call Trace:
>  [<ffffffff8044bbcb>] usbhid_lookup_quirk+0x63/0xea
>  [<ffffffff8044ab12>] hid_probe+0x4d/0xbad
>  [<ffffffff8029d0b6>] sysfs_new_dirent+0x79/0xaa
>  [<ffffffff80403411>] usb_match_one_id+0x26/0x82
>  [<ffffffff80403fe6>] usb_probe_interface+0x7d/0xa5
>  [<ffffffff80391cb9>] driver_probe_device+0xf6/0x17f
>  [<ffffffff80391de4>] __driver_attach+0x0/0x93
>  [<ffffffff80391e3e>] __driver_attach+0x5a/0x93
>  [<ffffffff8039110c>] bus_for_each_dev+0x43/0x6e
>  [<ffffffff80391433>] bus_add_driver+0x7b/0x19d
>  [<ffffffff80403b06>] usb_register_driver+0x7e/0xe1
>  [<ffffffff8064d2d3>] hid_init+0x28/0x4e
>  [<ffffffff8063460b>] kernel_init+0x162/0x2d2
>  [<ffffffff8020a338>] child_rip+0xa/0x12
>  [<ffffffff80343d5c>] acpi_ds_init_one_object+0x0/0x7c
>  [<ffffffff806344a9>] kernel_init+0x0/0x2d2
>  [<ffffffff8020a32e>] child_rip+0x0/0x12

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...

thanks,

greg k-h

Re: USB HID bug (was [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1)

[Jiri Kosina]

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 corresponding patch) added to CC. 

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 would mean that hid_probe() has been passed 
usb_interface for which 
le16_to_cpu(interface_to_usbdev(intf).dev->descriptor.idVendor) is equal 
to zero ...  and this definitely shouldn't happen for any sane device 
(could the original poster please verify with lsusb, just to be 100% 
sure?).

It would also help if the original poster, who is able to reproduce this 
WARN_ON, would verify whether hid_probe() is really being passed such 
strange usb_interface from upper USB layer ... please see the patch below, 
and send me the output if possible.

Paul, do you have any idea? In fact, what was your reason for putting this 
WARN_ON() there? Did you ever meet any condition when idVendor == 0 
appears there?

Thanks.

diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index f929dee..2a77d8b 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -984,6 +984,8 @@ static int hid_probe(struct usb_interfac
 	dbg("HID probe called for ifnum %d",
 			intf->altsetting->desc.bInterfaceNumber);
 
+	printk(KERN_DEBUG "DEBUG - hid_probe: idVendor: %x\n", 
+			le16_to_cpu(interface_to_usbdev(intf)->descriptor.idVendor));
 	if (!(hid = usb_hid_configure(intf)))
 		return -ENODEV;
 

Re: USB HID bug (was [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1)

[Jiri Kosina]

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 would mean that hid_probe() has been passed 
> usb_interface for which 
> le16_to_cpu(interface_to_usbdev(intf).dev->descriptor.idVendor) is equal 
> to zero ...  and this definitely shouldn't happen for any sane device 
> (could the original poster please verify with lsusb, just to be 100% 
> sure?).

BTW do I guess correctly that your keyboard is useful without problems 
after that, you only see this BUG and stacktraces in your logs, right?

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: USB HID bug (was [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1)

[Paul Walmsley]

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 correctly presenting with idVendor == 0, we need a different 
way to terminate that blacklist.  Either that or there's an upper-layer 
bug, as you write.

Regarding its placement: that WARN_ON() belongs in the static quirk lookup 
code, rather than where it is now.  Its current location must be a relic 
of an earlier patchset.

> Did you ever meet any condition when idVendor == 0 appears there?

No.  There shouldn't be any functional problem with removing that 
WARN_ON(), and also removing the initial if() in usbhid_lookup_dquirk().


- Paul

Re: USB HID bug (was [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1)

[Vincent ETIENNE]

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.6.21 doesn't have the drivers/hid/usbhid/ directory...
>
> Paul (author of the corresponding patch) added to CC.
>
> 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 would mean that hid_probe() has been passed
> usb_interface for which
> le16_to_cpu(interface_to_usbdev(intf).dev->descriptor.idVendor) is equal
> to zero ...  and this definitely shouldn't happen for any sane device
> (could the original poster please verify with lsusb, just to be 100%
> sure?).

You could download the result of lsusb -vvv from 
http://mail1.vetienne.net/linux/lsusb.log

>
> It would also help if the original poster, who is able to reproduce this
> WARN_ON, would verify whether hid_probe() is really being passed such
> strange usb_interface from upper USB layer ... please see the patch below,
> and send me the output if possible.
>
> Paul, do you have any idea? In fact, what was your reason for putting this
> WARN_ON() there? Did you ever meet any condition when idVendor == 0
> appears there?
>
> Thanks.
>
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index f929dee..2a77d8b 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -984,6 +984,8 @@ static int hid_probe(struct usb_interfac
>  	dbg("HID probe called for ifnum %d",
>  			intf->altsetting->desc.bInterfaceNumber);
>
> +	printk(KERN_DEBUG "DEBUG - hid_probe: idVendor: %x\n",
> +			le16_to_cpu(interface_to_usbdev(intf)->descriptor.idVendor));
>  	if (!(hid = usb_hid_configure(intf)))
>  		return -ENODEV;

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 network ). But i don't remember if the keyboard is USB 
or PS2 (i only have ssh access to the box for the next 3/4 days)

  Vincent

Re: USB HID bug (was [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1)

[Paul Walmsley]

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 network ). But i don't remember if the keyboard is USB
> or PS2 (i only have ssh access to the box for the next 3/4 days)

It seems that OpenBSD users are reporting similar problems:

http://article.gmane.org/gmane.os.openbsd.misc/122526

http://www.mail-archive.com/misc@openbsd.org/msg38200.html


- Paul

Re: USB HID bug (was [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1)

[Jiri Kosina]

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 
> > le16_to_cpu(interface_to_usbdev(intf).dev->descriptor.idVendor) is 
> > equal to zero ...  and this definitely shouldn't happen for any sane 
> > device (could the original poster please verify with lsusb, just to be 
> > 100% sure?).
> You could download the result of lsusb -vvv from 
> http://mail1.vetienne.net/linux/lsusb.log

Hi Vincent,

thanks for the report. It's pretty awesome though - all the USB devices 
seem to have vendor and product id set to 0x0000. Greg, have you ever met 
this? 

linux-usb-devel added to CC (full thread here: 
http://lkml.org/lkml/2007/4/27/496)

So this definitely isn't a HID-specific problem, something is confusing 
the USB VID/PIDs.

-- 
Jiri Kosina
SUSE Labs

Re: [linux-usb-devel] USB HID bug (was [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1)

[Alan Stern]

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_probe() has 
> > > been passed usb_interface for which 
> > > le16_to_cpu(interface_to_usbdev(intf).dev->descriptor.idVendor) is 
> > > equal to zero ...  and this definitely shouldn't happen for any sane 
> > > device (could the original poster please verify with lsusb, just to be 
> > > 100% sure?).
> > You could download the result of lsusb -vvv from 
> > http://mail1.vetienne.net/linux/lsusb.log
> 
> Hi Vincent,
> 
> thanks for the report. It's pretty awesome though - all the USB devices 
> seem to have vendor and product id set to 0x0000. Greg, have you ever met 
> this? 
> 
> linux-usb-devel added to CC (full thread here: 
> http://lkml.org/lkml/2007/4/27/496)
> 
> So this definitely isn't a HID-specific problem, something is confusing 
> the USB VID/PIDs.

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 and idProduct set to 0.  They aren't real devices at all; 
they are virtual root hubs.  You'll see what I mean if you look at their 
iManufacturer, iProduct, and iSerial strings.

Alan Stern

Re: [linux-usb-devel] USB HID bug (was [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1)

[Vincent ETIENNE]

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 and idProduct set to 0.  They aren't real devices at all;
> they are virtual root hubs.  You'll see what I mean if you look at their
> iManufacturer, iProduct, and iSerial strings.
>
> Alan Stern


So is it just a scary trace but without consequence that i could ignored ? 
May i ask you what is the device which is messed up ? ( Maybe should i change 
it ? )

Re: [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1

[Vincent ETIENNE]

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 debug 
message ) and get the same message a new time.

Maybe a tiny difference : only eth0 was setup during boot ( bond0 and eth1 was 
not setup - volontary  - to avoid problem that could interfere with usb ). 
Ony after having done my usb test, i have stopped the eth0, setup bond 
interface and restart bond interface and got the same problem with the same 
back trace.

Is there anything i can do to get you more precise information ?


Resend to the list : i have stripped lklm from the recipients......

Re: [linux-usb-devel] USB HID bug (was [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1)

[Jiri Kosina]

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 device which is messed up ? ( Maybe should i 
> change it ? )

Hi Vincent,

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 device, everything should be 
fine. I have removed the WARN_ON from the code in my tree. I think we 
still don't want users to add quirks for such broken devices (as it would 
collide with hid_blakclist[] terminator), so I have left the initial 
condition in usbhid_modify_dquirk() untouched.


From: Jiri Kosina <jkosina@suse.cz>

USB HID: don't warn on idVendor == 0

It turns out that there are broken devices out there that incorrectly
report VID/PID as 0x000, see http://lkml.org/lkml/2007/4/27/496

Therefore we should not confuse users by dumping warnings and stacktraces
in such situation. It is not possible to add quirks for such horribly
broken devices, but currently that's not needed.

Signed-off-by: Jiri Kosina <jkosina@suse.cz>

diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 27188bd..17a8755 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -477,8 +477,6 @@ static struct hid_blacklist *usbhid_exis
 	struct quirks_list_struct *q;
 	struct hid_blacklist *bl_entry = NULL;
 
-	WARN_ON(idVendor == 0);
-
 	list_for_each_entry(q, &dquirks_list, node) {
 		if (q->hid_bl_item.idVendor == idVendor &&
 				q->hid_bl_item.idProduct == idProduct) {

Re: [linux-usb-devel] USB HID bug (was [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1)

[Vincent ETIENNE]

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 device, everything should be
> fine. I have removed the WARN_ON from the code in my tree. I think we
> still don't want users to add quirks for such broken devices (as it would
> collide with hid_blakclist[] terminator), so I have left the initial
> condition in usbhid_modify_dquirk() untouched.
>

Thanks a lot for the explanation and the patch, now i better understand 
the "problem". Sorry to have bother you with just noise. The patch will 
certainly be of some help with dumb user (who have dump hardware ) 
like me.

I have very appreciate the attention you ( and all other from this feed ) have 
take with me. So a big thanks for your work and the next time (if any), i 
will try to better analyse the problem to avoid unnecessary work.

Vincent

Re: [Bonding-devel] [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1

[Vincent ETIENNE]

Le Thursday 26 April 2007 22:44:59 Jay Vosburgh, vous avez écrit :
> Chris Snook <csnook@redhat.com> 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.
> >

> 	This problem looks to be one of the known locking issues with
> bonding.
>
> 	Andy Gospodarek <andy@greyhouse.net> and I have been working
> offline on the locking issues in bonding over the last several weeks.
> At the moment, we have a generally stable (but ugly with debug fluff and
> other yuckies) patch that seems to resolve at least the majority of the
> various issues.  I'm thinking to clean it up for general posting early
> next week, and address additional problems from there (since it's
> hopefully at least a big step forward).
>
> 	-J


Any news and/or patch concerning this problem ?. Not intended to stress you 
but time goes on... Do you think a solution could be found in a relatively 
short timeframe (and i will delay a bit final installation) or is it better 
to go without bonding and do an upgrade later ?.

	Vincent

>
> ---
> 	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com