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
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 survive to this problem
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
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
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
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,
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
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
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
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
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
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
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
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
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, 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
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
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
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
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
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
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
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 )
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 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 have tried this
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 version. Same
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
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
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
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
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
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
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
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
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
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
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/possibly
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 survive to this problem
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:34
40 matches
Mail list logo
